(Premier Reference Source) Chung-ming Huang, Chung-ming Huang, Yao-chung Chang - Telematics Communication Technologies and Vehicular Networks Wireless Architectures and Applications (Premier Referenc (2)

Telematics Communication
Technologies and
Vehicular Networks:
Wireless Architectures
and Applications
Chung-Ming Huang
National Cheng Kung University, Tainan, Taiwan, R.O.C.
Yuh-Shyan Chen
National Taipei University, Taipei, Taiwan, R.O.C.
InformatIon scIence reference
Hershey • New York
Director of Editorial Content:
Senior Managing Editor:
Assistant Managing Editor:
Publishing Assistant:
Typesetter: Cover Design:
Printed at:
Kristin Klinger
Jamie Snavely
Michael Brehm
Sean Woznicki
Michael Brehm, Carole Coulson
Lisa Tosheff
Yurchak Printing Inc.
Published in the United States of America by
Information Science Reference (an imprint of IGI Global)
701 E. Chocolate Avenue
Hershey PA 17033
Tel: 717-533-8845
Fax: 717-533-8661
E-mail: [email protected]
Web site: http://www.igi-global.com/reference
Copyright © 2010 by IGI Global. All rights reserved. No part of this publication may be reproduced, stored or distributed in
any form or by any means, electronic or mechanical, including photocopying, without written permission from the publisher.
Product or company names used in this set are for identification purposes only. Inclusion of the names of the products or
companies does not indicate a claim of ownership by IGI Global of the trademark or registered trademark.
Library of Congress Cataloging-in-Publication Data
Telematics communication technologies and vehicular networks : wireless architectures and applications / Chung-Ming Huang
and Yuh-Shyan Chen, editors.
p. cm.
Summary: "This book examines critical issues involved with telematics such as vehicular network infrastructure, vehicular
network communication protocols, and vehicular services and applications"--Provided by publisher.
Includes bibliographical references and index.
ISBN 978-1-60566-840-6 (hardcover) -- ISBN 978-1-60566-841-3 (ebook) 1. Automotive telematics. I. Huang, ChungMing, 1961- II. Chen, Yuh-Shyan.
TL272.58.T45 2010
629.2'77--dc22
2009034903
British Cataloguing in Publication Data
A Cataloguing in Publication record for this book is available from the British Library.
All work contributed to this book is new, previously-unpublished material. The views expressed in this book are those of the
authors, but not necessarily of the publisher.
List of Reviewers
Chih-Yung Chang, Tamkang University, Taipei, Taiwan, R.O.C
Ruay-Shiung Chang, National Dong Hwa University, Hualien, Taiwan, R.O.C.
Tzung-Shi Chen, National University of Tainan, Tainan, Taiwan, R.O.C.
Wei-Kuo Chiang, National Chung Cheng University, Chia-Yi, Taiwan, R.O.C.
Li-Der Chou, National Central University, Chungli, Toayuan, Taiwan, R.O.C.
Chyi-Ren Dow, Feng Chia University, Taichung, Taiwan, R.O.C.
Ren-Hung Hwang, National Chung Cheng University, Chia-Yi, Taiwan, R.O.C.
Guan-Ling Lee, National Dong Hwa University, Hualien, Taiwan, R.O.C.
Wan-Jiun Liao, National Taiwan University, Taipei, Taiwan, R.O.C.
Tsung-Nan Lin, National Taiwan University, Taipei, Taiwan, R.O.C.
Jen-Yi Pan, National Chung Cheng University, Chia-Yi, Taiwan, R.O.C.
Shiao-Li Tsao, National Chiao Tung University, Hsinchu, Taiwan, R.O.C.
Table of Contents
Foreword ............................................................................................................................................ xix
Preface ................................................................................................................................................ xxi
Acknowledgment ............................................................................................................................... xxv
Section 1
Introduction of Vehicular Networks and Intelligent Transporation Systems
Chapter 1
Introduction of Vehicular Network Architectures ................................................................................... 1
Ming-Chiao Chen, National Taitung University, Taitung, Taiwan, R.O.C.
Teng-Wen Chang, National Taiwan University, Taipei, Taiwan, R.O.C.
Chapter 2
Introduction of Vehicular Network Applications .................................................................................. 15
Yao-Chung Chang, National Taitung University, Taiwan, R.O.C.
Chapter 3
Introduction to ITS and NTCIP ............................................................................................................ 32
Da-Jie Lin, Feng Chia University, Taiwan, R.O.C.
Chyi-Ren Dow, Feng Chia University, Taiwan, R.O.C.
Section 2
Embedded System Architecture and Communication Protocols
Chapter 4
Vehicular Embedded System Architecture............................................................................................ 58
Chung-Ping Young, National Cheng Kung University, Taiwan, R.O.C.
Chapter 5
Data Communications Inside Vehicular Environments ........................................................................ 74
Cheng-Min Lin, Nan Kai University of Technology, Taiwan, R.O.C.
Tzong-Jye Liu, Feng Chia University, Taiwan, R.O.C.
Chapter 6
Wireless Access in Vehicular Environments ......................................................................................... 90
Tzong-Jye Liu, Feng Chia University, Taiwan, R.O.C.
Ching-Wen Chen, Feng Chia University, Taiwan, R.O.C.
Section 3
Location Based Services
Chapter 7
Introduction To Global Satellite Positioning System (GPS) ............................................................... 108
Jenq-Muh Hsu, National Chiayi University, Chiayi, Taiwan, R.O.C.
Chapter 8
Vehicle Location and Navigation Systems ......................................................................................... 119
Ben-Jye Chang, National Yunlin University of Science and Technology, Yunlin, Taiwan, R.O.C.
Chapter 9
Design and Implementation of Vehicle Navigation Systems .............................................................. 131
Min-Xiou Chen, National Dong-Hwa University, Hualien, Taiwan, R.O.C.
Section 4
Integrated Vehicular Application
Chapter 10
Vehicular Metropolitan Area Network Systems Architecture: The WiMAX Network
Reference Model ................................................................................................................................. 144
Cheng Hsuan Cho, National Chung Cheng University, Taiwan, R.O.C.
Jen-Yi Pan, National Chung Cheng University, Taiwan, R.O.C.
Chapter 11
Interworking of IP Multimedia Subsystem and Vehicular Communication Gateway ........................ 160
Wei-Kuo Chiang, National Chung Cheng University, Chiaya, Taiwan, R.O.C.
An-Nie Ren, National Chung Cheng University, Chiaya, Taiwan, R.O.C.
Section 5
Vehicular Ad Hoc Networks and Delay Tolerant Vehicular Networks
Chapter 12
MAC Protocols in Vehicular Ad Hoc Networks ................................................................................. 183
Chih-Yung Chang, Tamkang University, Taiwan, R.O.C.
Chapter 13
Routing Protocol in Vehicular Ad Hoc Networks ............................................................................... 206
Yuh-Shyan Chen, National Taipei University, Taipei, Taiwan, R.O.C.
Yun-Wei Lin, National Taipei University, Taipei, Taiwan, R.O.C.
Chapter 14
Applications in Vehicular Ad Hoc Networks ...................................................................................... 229
Tzung-Shi Chen, National University of Tainan, Tainan, Taiwan, R.O.C.
Hua-Wen Tsai, National University of Tainan, Tainan, Taiwan, R.O.C.
Yi-Shiang Chang, National University of Tainan, Tainan, Taiwan, R.O.C.
Chapter 15
DTN Technologies for Vehicular Networks........................................................................................ 252
Kun-Chan Lan, National Cheng Kung University, Tainan, Taiwan, R.O.C.
Section 6
Management and Traffic Control
Chapter 16
Simple Transporation Management Framework................................................................................. 271
Chyi-Ren Dow, Feng Chia University, Taiwan, R.O.C.
Chapter 17
Vehicular System Management Architecture and Application Platform ............................................ 290
Teng-Wen Chang, National Taiwan University of Science and Technology, Taiwan, R.O.C.
Jiann-Liang Chen, National Taiwan University of Science and Technology, Taiwan, R.O.C.
Chapter 18
Remote Vehicular System Management Functions and Information Structure .................................. 310
Teng-Wen Chang, National Taiwan University of Science and Technology, Taiwan, R.O.C.
Jiann-Liang Chen, National Taiwan University of Science and Technology, Taiwan, R.O.C.
Chapter 19
Using Wireless Mesh Network for Traffic Control ............................................................................. 331
Kun-Chan Lan, National Cheng Kung University, Tainan, Taiwan, R.O.C.
Section 7
Mobility Model, Simulation, and Security
Chapter 20
Mobility Models of Vehicular Networks ............................................................................................ 348
Kun-Chan Lan, National Cheng Kung University, Tainan, Taiwan, R.O.C.
Chapter 21
MOVE: A Practical Simulator for Mobility Model in VANET .......................................................... 355
Kun-Chan Lan, National Cheng Kung University, Tainan, Taiwan, R.O.C.
Chapter 22
Security Attacks of Vehicular Networks ............................................................................................. 369
Jen-Chun Chang, National Taipei University, Taiwan, R.O.C.
Chun-I Fan, National Sun Yat-sen University, Taiwan, R.O.C.
Ruei-Hau Hsu, National Sun Yat-sen University, Taiwan, R.O.C.
Compilation of References ............................................................................................................... 380
About the Contributors .................................................................................................................... 398
Index ................................................................................................................................................... 405
Detailed Table of Contents
Foreword ............................................................................................................................................ xix
Preface ................................................................................................................................................ xxi
Acknowledgment ............................................................................................................................... xxv
Section 1
Introduction of Vehicular Networks and Intelligent Transporation Systems
Chapter 1
Introduction of Vehicular Network Architectures ................................................................................... 1
Ming-Chiao Chen, National Taitung University, Taitung, Taiwan, R.O.C.
Teng-Wen Chang, National Taiwan University, Taipei, Taiwan, R.O.C.
A vehicular network organizes and connects vehicles with each other, and with mobile and fixed-locations
resources. This chapter discusses the architectures in the vehicular network environment. We introduce the overview of in-vehicle and out-vehicle network architectures. An automobile in an in-vehicle
network adopts four vehicle bus protocols, CAN (Controller Area Network), LIN (Local Interconnect
Network), MOST (Media Oriented Systems Transport) and FlexRay. However, these protocols cannot
intercommunicate with each other. Therefore, the OSEK operating system is designed as standard software architecture for the various ECUs (Electronic Control Units). In the out-vehicle network, the OBU
(On Board Unit) in the automobile can communicate with the infrastructure via the Internet. We discuss
next-generation vehicular network architecture, the modern in-vehicle networks, on-board computers
and the Internet, mobile telecommunications and telematics applications in the ground vehicles, and
finally, we introduce future desired features. This chapter discusses the architectures in vehicular network
environment. Section 1.1 introduces the overview of in-vehicle and out-vehicle network architectures.
Section 1.2 describes in-vehicle network architecture for disaster communication network by combining
various automotive bus protocols. Section 1.3 describes the out-vehicle network architecture for disaster
communication network by combining various wireless LANs. Section 1.4 discusses next-generation
vehicular network architecture, the modern in-vehicle networks, on-board computers and the Internet,
mobile telecommunications and telematics applications in the ground vehicles, and introduces future
desired features.
Chapter 2
Introduction of Vehicular Network Applications .................................................................................. 15
Yao-Chung Chang, National Taitung University, Taiwan, R.O.C.
Information and Communication Technology (ICT) is concerned with all the technologies that manage,
process, and communicate information. It is also named as telematics, combining two words: telecommunications and informatics, which is widely used in the application of Global Positioning System
technology integrated with computers and in the mobile communications technology for automotive
navigation systems. Table 2.1 and Table 2.2 respectively list the telemetric applications from user’s
point of view and the practical applications of vehicular telematics. Four applications of the vehicular
network are discussed in this chapter. Section 2.1 introduces the vehicular network application services.
Section 2.2 discusses the vehicular network application management. Section 2.3 provides the platform
technologies of vehicular network application. Finally, future vehicular network application and deployments are presented in the Section 2.4.
Chapter 3
Introduction to ITS and NTCIP ............................................................................................................ 32
Da-Jie Lin, Feng Chia University, Taiwan, R.O.C.
Chyi-Ren Dow, Feng Chia University, Taiwan, R.O.C.
Intelligent Transportation Systems (ITS) combines high technology and improvements in information
systems, communication, sensors, and relevant mathematical methods with the conventional world of
surface transportation infrastructure to increase the capacity of transportation systems and to improve
the level of services. There are four major goals of ITS, including safety, environmental protection, efficiency, and economy. NTCIP (NTCIP Standard 9001, 2002; DISA et al., 1997) is a set of communications
protocols and data definition standards designed for various needs of ITS services and applications. The
key goals of the NTCIP open-standards effort are interoperability and interchangeability. Interoperability
refers to the ability for multiple devices to work together as a single system and interchangeability refers
to the ability to use multiple brands of a device on the same communications channel. Accompanying the
social and economic development, traffic congestion and delay have become major issues in most areas
around the world. How to use readily available technologies to increase the capacity of transportation
systems and to improve the level of service has become one of major solutions to solve transportation
problems that people are facing. This is the motivation of Intelligent Transportation Systems development. NTCIP is a set of communications protocols and data definition standards designed for various
needs of ITS services and applications. These standards are intended to handle these needs in the two
areas: Center-to-Field (C2F) and Center-to-Center (C2C) communications.
Section 2
Embedded System Architecture and Communication Protocols
Chapter 4
Vehicular Embedded System Architecture............................................................................................ 58
Chung-Ping Young, National Cheng Kung University, Taiwan, R.O.C.
Transportation of humans and objects have been playing an important role in our daily lives since civilization first formed and needed new means of reaching destinations. The invention of efficient transportation
greatly reduced the time and labor once required and in addition largely extended the living environment
that people can reach. The more time and labor for transportation is saved, the more leisure time people
will have. Animal-power or natural resources have been the driving force of transportation for a long
time. After the steam engine was invented, the automobile started a new era. The mass production of the
Ford model T created the modern automobile industry and made the automobile more affordable. The
basic structure of the automobile has not changed much, but evolving technologies has kept improving
its functions and performance. The construction of traffic networks and mass production of automobiles
have made the automobile the most important land based transportation carrier. The usage of automobiles
is usually associated with the growth of economy and industry of a nation, so the population ratio that
owns automobiles in a developed country is larger than that in a developing country. When the economy
grows, vehicle as a transportation tool becomes more affordable and popular, for instance China or India. When people use automobiles in their daily lives, they demand not only mobility, but also safety,
comfort and convenience. These are some design factors that manufacturers have to put into aspect when
enhancing functions by introducing and developing new technologies.
Chapter 5
Data Communications Inside Vehicular Environments ........................................................................ 74
Cheng-Min Lin, Nan Kai University of Technology, Taiwan, R.O.C.
Tzong-Jye Liu, Feng Chia University, Taiwan, R.O.C.
ZigBee is based on IEEE 802.15.4 which specifies the physical layer and medium access control (MAC)
for low-cost and low-power LR-WPAN. The technology can be applied in intelligent key, A/C operation and steering wheel inside vehicles. There are two types of devices in ZigBee, FFD and RFD. A
FFD can communicate with RFDs and other FFDs, while a RFD can only communicate with a FFD.
In ZigBee physical layer, it follows IEEE 802.15.4 standard and operates in unlicensed RF worldwide
(2.4GHz global, 915MHz Americas or 868 MHz Europe). A superframe contained an active portion and
an inactive portion is used in the MAC layer of ZigBee. The active portion includes CAP and CFP. In
the inactive partition, the coordinator can enter sleep mode to save its power. Three main topologies of
ZigBee are star, mesh, and tree. However, ZigBee is successfully produced into a low-cost controller
applied for automotive applications, including vehicle control and status monitoring. According to the
forecast of ON World in 2005 (ON WORLD, 2009) , the deployed wireless sensing network nodes will
increase to 127 million in 2010 from 1.2 million in 2005. It can be applied in home automation, battlefield
surveillance, health care applications and vehicular environments. A wireless sensor network (WSN)
constitutes a lot of wireless sensing nodes. In addition, a node in WSN consists of one or more sensors,
a radio transceiver, and a microcontroller. The sensor can be used for sensing temperature, pressure,
sound, vibration, motion or position, etc. to collect status from devices or environments. The transceiver
is used to relay the information of the collected status computed by the microcontroller to a center node,
called a gateway or sink. Therefore, a WSN belongs to one type of wireless ad-hoc networks. However,
the nodes in a WSN are usually smaller than that in traditional wireless ad-hoc networks regarding node
size, computing power, memory size, and transmission rage. In other words, the transmission ability,
computing power, and memory size of WSN nodes are limited.
Chapter 6
Wireless Access in Vehicular Environments ......................................................................................... 90
Tzong-Jye Liu, Feng Chia University, Taiwan, R.O.C.
Ching-Wen Chen, Feng Chia University, Taiwan, R.O.C.
The IEEE 1609 standards define communication for wireless access in vehicular environment (WAVE)
services, which enable vehicle-to-vehicle, vehicle-to-roadside, as well as vehicle-to-infrastructure
communications. The standard consists of four parts, which are briefly described in this chapter. IEEE
1609.1 describes the WAVE resource manager which specifies the wireless access method in a WAVE
environment and allows a remote manager application to establish connection with a resource command
processor on an on-board unit. IEEE 1609.2 defines several secure message formats to process messages for WAVE system. The standard covers methods for securing WAVE management messages and
application messages, which protects messages from attacks such as eavesdropping, spoofing, alteration, replay, and linkable information to unauthorized parties. IEEE 1609.3 defines network services for
WAVE systems, whose network services operate at the network and transport layers of the OSI model
and support both the IPv6 traffics and the WAVE short message services. IEEE 1609.4 describes WAVE
multi-channel operations. It specifies the functions of MAC sublayer management entity and WAVE
MAC with channel coordination. The multi-channel operation provides an efficient mechanism that
controls the operation of upper layer across multiple channels.
Section 3
Location Based Services
Chapter 7
Introduction To Global Satellite Positioning System (GPS) ............................................................... 108
Jenq-Muh Hsu, National Chiayi University, Chiayi, Taiwan, R.O.C.
Understanding the right positions and directions of people and objects is a significant issue from the
ancient eras to the present. In the past, people often launched a war in order to satisfy the craving for the
dominating powers and spread their realms. In the recent, Global Satellite Positioning System (GPS) has
become the one of most popular positioning technologies. GPS can provide users precise positioning
information, no matter wherever that may present their own positions. The early GPS positioning technology has been widely used in military, marine use, until recently gradually applied into our daily life, e.g.,
automotive navigation, geodesy surveying, etc. In this chapter, the authors will briefly introduce some
GPS issues including the origins of GPS, GPS system architecture, and related GPS applications.
Chapter 8
Vehicle Location and Navigation Systems ......................................................................................... 119
Ben-Jye Chang, National Yunlin University of Science and Technology, Yunlin, Taiwan, R.O.C.
The most driving purpose is to traverse to the destination safely, efficiently, and comfortably. Two types
of approaches could achieve the goals, including the static and dynamic approaches. In the static aspect,
vehicles use the static road and traffic information to navigate. Conversely, in the dynamic aspect, vehicles adopt the dynamic information instead. However, both of the two approaches first require getting
the vehicle’s location and then map the position on an e-map. Thus, this chapter first introduces some
important vehicle location determination algorithms: the dead reckoning and global position system
algorithms, in which the precision of location technologies are compared. Then, the map-matching algorithm is described in detail. Finally, various vehicle navigation approaches are detailed, in which the
important topics include: the navigation architecture, the navigation routing algorithm, and navigation
applications.
Chapter 9
Design and Implementation of Vehicle Navigation Systems .............................................................. 131
Min-Xiou Chen, National Dong-Hwa University, Hualien, Taiwan, R.O.C.
Vehicle Navigation System (VNS) is a complicated and integrated system. A reliable vehicle navigation
system should integrate the wireless communication technologies, positioning technologies, embedded
computer, geographic information database, and so on. The major purpose of the chapter is to help
understanding the architecture of vehicle navigation system. This chapter first introduces the system requirements and system analysis, and show the system platform of vehicle navigation system. The system
platform can be divided into six components. There are the digital map database, positioning devices,
map-matching process, route planning process, route guidance process, human-machine interface, and
wireless communication interface. The design issues and system communication of these components
are detail illustrated in the chapter. Finally, the authors also present some vehicle navigation systems
proposed in the past few years, and show the difference of these systems. The aim of vehicle navigation
system is to guide the vehicle along the optimal path from the starting point to destination. A reliable
vehicle navigation system can reduce the traffic chaos in the city and improve the transportation delay.
In order to achieve reliable vehicle navigation system, the detail system requirements, system analysis,
and system architecture are shown in the chapter. Each component of vehicle navigation system is briefly
illustrated, and the system communication is also described. They also present the architecture of the
proposed vehicle navigation system, and show the difference of these systems. Therefore this chapter
helps understanding the architecture of vehicle navigation system.
Section 4
Integrated Vehicular Application
Chapter 10
Vehicular Metropolitan Area Network Systems Architecture: The WiMAX Network
Reference Model ................................................................................................................................. 144
Cheng Hsuan Cho, National Chung Cheng University, Taiwan, R.O.C.
Jen-Yi Pan, National Chung Cheng University, Taiwan, R.O.C.
The WiMAX NWG develops a network reference model to serve as an architecture framework for
WiMAX deployments and to ensure interoperability among various WiMAX equipment and operators.
The network reference model envisions unified network architecture for supporting fixed, nomadic, and
mobile deployments and is based on an IP service model. We introduce WiMAX network architecture,
WiMAX network entry, mobility management, QoS functional elements, core network planning and
accounting architecture in this section. However, all of them are significant in deploying WiMAX core
network. The operator tries to reach the goals including system performance, reliability, and so on.
On the other hand, the WiMAX operator should consider and balance such many variables in order to
achieve a better situation.
Chapter 11
Interworking of IP Multimedia Subsystem and Vehicular Communication Gateway ........................ 160
Wei-Kuo Chiang, National Chung Cheng University, Chiaya, Taiwan, R.O.C.
An-Nie Ren, National Chung Cheng University, Chiaya, Taiwan, R.O.C.
In recent years, more and more people dream of experiencing various IP-based multimedia application
services when they are driving through their car. However, those multimedia devices in the car may use
different communication protocols such as X.10, Havi, Jini, UPnP and SIP. In order to provide a variety
of IP-based multimedia services to those users in the car, we mainly investigate the issue of interworking
between IP Multimedia Subsystem (IMS) and telematics of the vehicular industry. A service-integrated
platform, Open Service Gateway Initiative Service Platform (OSGi SP), has been proposed to act as a
Residential Gateway (RGW) and to administer the communication between the vehicular environment
and Internet. Besides, a Home IMS Gateway (HIGA), which can be implemented on a NGN RGW,
has been developed by Home Gateway Initiative (HGI) since 2005 to collect the relevant information
of in-car users, devices and services and to manage the IMS sessions for the in-car devices that do not
support IMS functions. With these techniques, the users can enjoy their digital life by interacting with
the home/vehicular network from anywhere.
Section 5
Vehicular Ad Hoc Networks and Delay Tolerant Vehicular Networks
Chapter 12
MAC Protocols in Vehicular Ad Hoc Networks ................................................................................. 183
Chih-Yung Chang, Tamkang University, Taiwan, R.O.C.
With the rapid development of wireless technologies, the Vehicular Ad Hoc Networks (VANETs) have
recently received much attention. VANETs technologies aim to ensure traffic safety for drivers, provide
comfort for passengers and reduce transportation time and fuel consumption with many potential applications. The achievement of these aims highly relies on efficient MAC protocols which determine the
performance of packet transmission in terms of success rate, delay, throughput and bandwidth utilization.
This chapter reviews the existing MAC protocols developed for VANETs. Initially, the IEEE 802.11p
and DSRC standard are reviewed. Two TDMA-based MAC protocols, called CVIA and VeSOMAC, are
then introduced. In addition, three MAC protocols that cope with the emergency-message broadcasting
problem are proposed. Finally, a reliable MAC protocol which is developed based on the cluster topology is reviewed.
Chapter 13
Routing Protocol in Vehicular Ad Hoc Networks ............................................................................... 206
Yuh-Shyan Chen, National Taipei University, Taipei, Taiwan, R.O.C.
Yun-Wei Lin, National Taipei University, Taipei, Taiwan, R.O.C.
Vehicular Ad hoc Network (VANET), a subclass of mobile ad hoc networks (MANETs), is a promising
approach for the intelligent transportation system (ITS). The design of routing protocols in VANETs is
important and necessary issue for support the smart ITS. The key difference of VANET and MANET
is the special mobility pattern and rapidly changeable topology. It is not effectively applied the existing
routing protocols of MANETs into VANETs. In this chapter, the authors mainly survey new routing
results in VANET. They introduce unicast protocol, multicast protocol, geocast protocol, mobicast protocol, and broadcast protocol. It is observed that carry-and-forward is the new and key consideration for
designing all routing protocols in VANETs. With the consideration of multi-hop forwarding and carryand-forward techniques, min-delay and delay-bounded routing protocols for VANETs are discussed in
VANETs. Besides, the temporary network fragmentation problem and the broadcast storm problem are
further considered for designing routing protocols in VANETs. The temporary network fragmentation
problem caused by rapidly changeable topology influence on the performance of data transmissions.
The broadcast storm problem seriously affects the successful rate of message delivery in VANETs. The
key challenge is to overcome these problems to provide routing protocols with the low communication
delay, the low communication overhead, and the low time complexity.
Chapter 14
Applications in Vehicular Ad Hoc Networks ...................................................................................... 229
Tzung-Shi Chen, National University of Tainan, Tainan, Taiwan, R.O.C.
Hua-Wen Tsai, National University of Tainan, Tainan, Taiwan, R.O.C.
Yi-Shiang Chang, National University of Tainan, Tainan, Taiwan, R.O.C.
The various sensors and wireless communication devices have been extensively applied to daily life
due to the advancements of microelectronics mechanism and wireless technologies. Recently, vehicular
communication systems and applications become more and more important to people in daily life. Vehicular communication systems that can transmit and receive information to and from individual vehicles
have the potential to significantly increase the safety of vehicular transportation, improve traffic flow on
congested roads, and decrease the number of people of deaths and injuries in vehicular collisions effectively. This system relies on direct communication between vehicles to satisfy the communication needs
of a large class of applications, such as collision avoidance, passing assistance, platooning. In addition,
vehicular communication systems can be supplemented by roadside infrastructure to access Internet and
other applications. This system forms a special case of mobile ad hoc networks called Vehicle Ad Hoc
Networks (VANETs). They can be formed between vehicles with vehicle to vehicle (V2V) communication or between vehicles and an infrastructure with vehicle to infrastructure (V2I) communication. The
applications and characteristics of VANETs are introduced and presented in this Chapter.
Chapter 15
DTN Technologies for Vehicular Networks........................................................................................ 252
Kun-Chan Lan, National Cheng Kung University, Tainan, Taiwan, R.O.C.
A Delay Tolerant Network (DTN) is one type of challenged network where network contacts are intermittent or link performance is highly variable or extreme. In such a network, a complete path does not
exist from source to destination for most of the time. In addition, the path can be highly unstable and
may change or break unexpectedly. To make communication possible in a delay tolerant network, the
intermediate nodes need to take custody of data during the blackout and forward it toward the destination when the connectivity resumes. A vehicular network nicely falls into the context of DTN since the
mobility of vehicles constantly causes the disruption of link connectivity’s between vehicles. In this
chapter, the authors discuss some research challenges and issues which might occur in a Delay Tolerant
Network and how they are related to vehicular networks.
Section 6
Management and Traffic Control
Chapter 16
Simple Transporation Management Framework................................................................................. 271
Chyi-Ren Dow, Feng Chia University, Taiwan, R.O.C.
The Simple Transportation Management Framework (STMF) specifies a set of rules and protocols which
can be used to organize, describe, and exchange transportation management information between transportation management applications and equipments. The STMF framework consists of four elements,
including Management Information Base (MIB), Structure and Identification of Management Information (SMI), Simple Network Management Protocol (SNMP), and Simple Transportation Management
Protocol (STMP). MIB is a collection of management objects written in ASN.1 notation. SMI is the
definition of how to create management objects and a hierarchical definition of nodes where management
objects will be attached for unique identification. SNMP is a communications protocol for configuring
and monitoring of network devices. STMP is a variation of SNMP to address low-bandwidth communication links and real-time device monitoring.
Chapter 17
Vehicular System Management Architecture and Application Platform ............................................ 290
Teng-Wen Chang, National Taiwan University of Science and Technology, Taiwan, R.O.C.
Jiann-Liang Chen, National Taiwan University of Science and Technology, Taiwan, R.O.C.
Notably, not all telematics services can be used in telematics terminals as a result of the varied platform
standards. The main issues are that most telematics technologies depend on vertical, proprietary and
closed per-OEM Original Equipment Manufacture (OEM) platforms, forming islands of non-interoperable technology and preventing third-party service providers from creating valuable services. In this
study, the Open Gateway Service Initiative Vehicle Expert Group (OSGi/VEG) was integrated into
an Android platform to generate a vehicular Android/OSGi platform that has the advantages of both
original platforms, such as remote management, rich class sharing, proprietary vehicular applications,
security policies, easy management of application programming interface (APIs), and an environment
with increased openness. Furthermore, this study integrates the cloud computing mechanism into the
Android/OSGi platform, which allows service providers to upload their telematics bundles onto storage
clouds via the provisioning server.
Chapter 18
Remote Vehicular System Management Functions and Information Structure .................................. 310
Teng-Wen Chang, National Taiwan University of Science and Technology, Taiwan, R.O.C.
Jiann-Liang Chen, National Taiwan University of Science and Technology, Taiwan, R.O.C.
Due to the rapid development of information technology, the network has already spread to every corner of
vehicle. With all kinds of ECU devices appear in the vehicle, and it brings the more and more convenient
living. On purpose solving heterogamous technologies that are incompatible with each other, developed
a “WBEM-based Remote Management and Heterogeneous Vehicular Network Diagnosis System” on
OSGi Gateway. This system can focus on a variety of problems come from vehicle network, and find
out what are the problems or where are the problems happened. If the problem still can not be solved
properly, we must to seek for help from remote managers. The users can acquire enough information
without understanding how to control every device, so that the users can help near diagnosis system to
solve vehicle network’s problems and to promote the abilities of near network diagnosis.
Chapter 19
Using Wireless Mesh Network for Traffic Control ............................................................................. 331
Kun-Chan Lan, National Cheng Kung University, Tainan, Taiwan, R.O.C.
Wireless mesh networks (WMN) have attracted considerable interest in recent years as a convenient,
flexible and low-cost alternative to wired communication infrastructures in many contexts. However,
the great majority of research on metropolitan-scale WMN has been centered around maximization
of available bandwidth, suitable for non-real-time applications such as Internet access for the general
public. On the other hand, the suitability of WMN for missioncritical infrastructure applications remains
by and large unknown, as protocols typically employed in WMN are, for the most part, not designed for
real-time communications. In this chapter, the authors describe a real-world testbed, which sets a goal
of designing a wireless mesh network architecture to solve the communication needs of the traffic con-
trol system in Sydney, Australia. This system, known as SCATS (Sydney Coordinated Adaptive Traffic
System) and used in over 100 cities around the world, connects a hierarchy of several thousand devices
-- from individual traffic light controllers to regional computers and the central Traffic Management
Centre (TMC) - and places stringent requirements on the reliability and latency of the data exchanges.
The authors discuss some issues in the deployment of this testbed consisting of 7 mesh nodes placed at
intersections with traffic lights, and show some results from the testbed measurements.
Section 7
Mobility Model, Simulation, and Security
Chapter 20
Mobility Models of Vehicular Networks ............................................................................................ 348
Kun-Chan Lan, National Cheng Kung University, Tainan, Taiwan, R.O.C.
A key component for VANET simulations is a realistic vehicular mobility model that ensures conclusions
drawn from simulation experiments will carry through to real deployments. However, VANET simulations
raise many new questions about suitable levels of details in simulation models. To get accurate results,
the mobility models of Vehicular Networks should be as realistic as possible, and involve road-maps
with all constraints and facilities related to the vehicular movement. In this chapter, the authors provide
an overview of some mobility models that are relevant to VANETs. The criteria of applicability they
consider here is the employment of road maps, and thus limiting the nodes movements into the routes,
instead of moving them in a wide open area. They compare different models based on the parameters
they use. For instance, some models use traffic control mechanisms (stop signs or traffic lights) at route
intersections, and some just assume continuous movement at these points. Some assume routes to be
single-lane, some others support multi-lanes routes. Some define the security distance, while others just
ignore this parameter.
Chapter 21
MOVE: A Practical Simulator for Mobility Model in VANET .......................................................... 355
Kun-Chan Lan, National Cheng Kung University, Tainan, Taiwan, R.O.C.
Vehicular Ad-Hoc Network (VANET) is surging in popularity, in which vehicles constitute the mobile
nodes in the network. Due to the prohibitive cost of deploying and implementing such a system in real
world, most research in VANET relies on simulations for evaluation. A key component for VANET simulations is a realistic vehicular mobility model that ensures conclusions drawn from simulation experiments
will carry through to real deployments. However, VANET simulations raise many new questions about
suitable levels of details in simulation models for nodes mobility. In VANET simulations, the mobility
models used affect strongly the simulation output. The researchers need to decide what level of details
are required for their simulations. In this chapter, the authors introduce a tool MOVE that allows users
to rapidly generate realistic mobility models for VANET simulations. MOVE is built on top of an open
source micro-traffic simulator SUMO. The output of MOVE is a realistic mobility model and can be
immediately used by popular network simulators such as ns-2 and Qualnet. They show that the simulation results obtained when using a realistic mobility model such as MOVE are significantly different
from results based on the commonly used random waypoint model. In addition, they evaluate the effects
of details of mobility models in three case studies of VANET simulations (specifically, the existence of
traffic lights, driver route choice and car overtaking behavior) and show that selecting sufficient level
of details in the simulation is critical for VANET protocol design.
Chapter 22
Security Attacks of Vehicular Networks ............................................................................................. 369
Jen-Chun Chang, National Taipei University, Taiwan, R.O.C.
Chun-I Fan, National Sun Yat-sen University, Taiwan, R.O.C.
Ruei-Hau Hsu, National Sun Yat-sen University, Taiwan, R.O.C.
The application of vehicular ad hoc network (VANET) improves driving safety and traffic management.
Due to the above applications, security attacks on VANET can be serious threats all the time. VANET is a
special form of mobile ad hoc network (MANET). Hence any attacks exist on MANET also can be arisen
on VANET. Moreover, some special attacks can be raised on VANET, which don’t exist on MANET.
Nevertheless, some characteristics of VANET can be positive effects and some can be negative effects
on security issues. Before designing the security mechanism to defend attacks, the authors should take
the positive effects and avoid the negative effects on the security of VANET. Furthermore, they class all
possible attacks of VANET from every network layer. The authors also introduce the reason of forming
every attack and the possible effect on VANET in detail. Therefore this chapter helps understanding the
latent threats and the useful resources of security issues on VANET.
Compilation of References ............................................................................................................... 380
About the Contributors .................................................................................................................... 398
Index ................................................................................................................................................... 405
xix
Foreword
The Human Resource Program for Information and Communication Technology sponsored by the
Ministry of Education (MOE) in Taiwan, lead by myself, has been a key program in the past 10 years
to bridge possible gaps between university education and industrial human resource demands, and to
train and cultivate sufficient as well as high-quality and skilled young professionals in the blooming
global telecommunication market. After a detailed analysis of the ICT industrial trend by a review board
consisted of experts and professionals from both academic and industrial sector around 2006, MOE
in Taiwan decided to focuses the talent cultivation direction only on a few selected areas of emerging
technology. Telematics and Vehicular Networks has emerged as one such important technology since
the research progress in the telematics and vehicular networking was so significant that related industry
has become booming around the world and one can easily expect future drivers can enjoy the benefit
from related smart telematics products and services. We also believe telematics and vehicular networks
can be categorized as a special kind of Green ICT Technologies since it also helps to save energy in
many scenarios.
In the past few decades, Taiwan’s telecommunication and ICT industry has experienced a long period of high growth and fast technology evolution. For example, the communication industry in Taiwan
has increased up to 8 folds around 10 years, with its manufacturing capacity ranging from traditional
LAN switches to 3G smart phones. Without surprises, recent industry trends in smart cars and vehicular networks have also created a strong demand on talent engineers with good hand-on experiences in
related products and services. Again, universities and the academic community have been asked to keep
upgrading key ICT courses and laboratories to link up with the telematics industry in a timely fashion.
In response to this demand, a prestigious team was selected from the academic community in Taiwan
in 2007, to aggregate teaching resources, refine the essential courseware, and enhance experiment environments for training talented students in this field. An intercollegiate telematics promotion center
was also established for completing this task and Professor Chung-Ming Huang, National Cheng-Kung
University, was selected to lead this center for his dedication and the knowledge and research experience
he has accumulated in this field.
This book, Telematics Communication Technologies and Vehicular Networks: Wireless Architectures
and Applications, edited by Prof. Chung-Ming Huang and Prof. Yuh-Shyan Chen, is a work contributed
by such a group of telematics experts and professors in this field. This book has successfully covered a
wide range of technical topics, including vehicular network architecture, related communication protocols, ITS/telematics applications, navigation systems, location based services and embedded systems.
xx
Many chapters in this book is self-guided and can be used a tutorial. In general, it should be a valuable
textbook, guidance and/or reference for students, researchers, engineers, technical managers, and other
professionals in this field. I believe all readers can enjoy reading this book.
Zsehong Tsai, Professor
Human Resource Program Office for ICT
National Taiwan University, Taiwan, R.O.C.
xxi
Preface
TelemaTics communicaTion Technologies and Vehicular
neTworks: wireless archiTecTures and applicaTions
Telematics communication technologies and vehicular networks have been identified as key technologies
for increasing road safety and transport efficiency. Telematics communication technologies and vehicular
networks aim to ensure traffic safety for drivers, provide comfort for passengers and reduce transportation
time and fuel consumption. The development of vehicular communication and networking technologies
are expected to enable many potential applications, including automatic collision notification and prevention, emergency management, assistances for safe driving, real-time traffic congestion notification,
location-based driver information services, high-speed tolling, vehicle tracking, automobile Internet
access, and many others. To facilitate these applications, many different new types of communication
and networking would be involved, including intra-vehicle, vehicle-to-vehicle, vehicle-to-roadside and
vehicle-to-infrastructure communications. This book aims to provide a fast and complete view of all
aspects related to telematics communication technologies and vehicular networks.
This book is intended for graduate students, researchers, engineer, and practitioners who are interested
in acquiring a global view of the set of techniques and protocols that have been referred to as “Telematics communication technologies and vehicular networks: wireless architectures and applications” in the
literature. The book can serve as a reference resource for researchers, engineers, and developers working
in the field of telematics technologies.
This book includes 22 chapters which are classified into 7 Sections. Section 1 introduces the vehicular networks and intelligent transportation systems. Section 2 describes embedded system architecture
and communication protocols. Section 3 reports location based services. Section 4 provides integrated
vehicular applications. Section 5 presents vehicular ad hoc networks and delay tolerant vehicular networks. Section 6 explains management and traffic control. Finally, Section 7 talks about mobility model,
simulation, and security for telematics communication technologies and vehicular networks.
The first section of the book, Introduction of Vehicular Networks and Intelligent Transportation Systems, presents introductory materials that is preparatory for what us described in the rest of the book.
Chapter 1, by Ming-Chiao Chen and Teng-Wen Chang, gives a short introduction to vehicular network architectures. This chapter discusses the architectures in the vehicular network environment, and
introduces the overview of in-vehicle and out-vehicle network architectures. This chapter also discusses
the next-generation vehicular network architecture, the modern in-vehicle networks, on-board computers
and the Internet, mobile telecommunications and telematics applications in the ground vehicles.
Chapter 2, by Yao-Chung Chang, introduces vehicular network applications. Four applications of the
vehicular network are surveyed and discussed in this chapter. They are vehicular network application
xxii
services, vehicular network application managements, the platform technologies of vehicular network
application, and the future vehicular network application and deployment.
Chapter 3, by Da-Jie Lin and Chyi-Ren Dow, explains intelligent transportation systems. Intelligent
Transportation Systems (ITS) combines high technology and improvements in information systems,
communication, sensors, and relevant mathematical methods with the conventional world of surface
transportation infrastructure to increase the capacity of transportation systems and to improve the level
of services. There are four major goals of ITS, including safety, environmental protection, efficiency,
and economy.
The second section of the book, Embedded System Architecture and Communication Protocols, presents the vehicular embedded system architecture, data communication protocols for vehicular network,
and wireless access techniques in vehicular environments.
Chapter 4, by Chung-Ping Young, explains the vehicular embedded system architecture. The car electronics plays an increasingly important role in automobile industry. The embedded system has already
been extensively employed for improving the operation and performance of vehicles, such as safety,
comfort, convenience, and environmental protection. In terms of electronic system, an automobile is a
distributed embedded system, and the control messages to each electronic control unit (ECU), go through
the in-vehicle network. An ECU is an embedded processor or computing system, integrated with a data
acquisition device or an electromechanical driver.
Chapter 5, Cheng-Min Lin, and Tzong-Jye Liu, reports the data communications inside vehicular
environments. ZigBee is based on IEEE 802.15.4 which specifies the physical layer and medium access
control (MAC) for low-cost and low-power LR-WPAN. ZigBee is successfully produced into a low-cost
controller applied for automotive applications, including vehicle control and status monitoring.
Chapter 6, by Tzong-Jye Liu and Ching-Wen Chen, gives the wireless access in vehicular environments.
This chapter describes the IEEE 1609 standard for Wireless Access in Vehicular Environment (WAVE)
services, which enable vehicle-to-vehicle, vehicle-to-roadside, as well as vehicle-to-infrastructure communications. The standard consists of four parts, IEEE 1609.1, IEEE 1609.2, IEEE 1609.3, and IEEE
1609.4, which are described in this chapter.
The third section of the book, Location Based Services, provides the useful knowledge and technique of location based services for supporting telematics communication technologies and vehicular
networks.
Chapter 7, by Jenq-Muh Hsu, provides the introduction of GPS. Global Satellite Positioning System (GPS) recently has become the one of most popular positioning technologies. This chapter briefly
introduces some GPS issues including the origins of GPS, GPS system architecture, and related GPS
applications.
Chapter 8, by Ben-Jye Chang, presents the vehicle location and navigation systems. This chapter
introduces important vehicle location determination algorithms: the dead reckoning and global position
system algorithms, in which the precision of location technologies are compared. The map-matching
algorithm is then described. Various vehicle navigation approaches are explained.
Chapter 9, by Min-Xiou Chen, discusses the design and implementation of vehicle navigation systems. The major purpose of the chapter is to understand the architecture of vehicle navigation system.
This chapter introduces the system requirements and system analysis, and show the system platform
of vehicle navigation system.
In the fourth section of the book, Integrated Vehicular Application, presents the vehicular metropolitan area network systems architecture and the interworking of IP multimedia subsystem and vehicular
communication gateway.
xxiii
Chapter 10, by Cheng Hsuan Cho and Jen-Yi Pan, reports the vehicular metropolitan area network
systems architecture: the WiMAX network reference model. This chapter introduces WiMAX network
architecture, WiMAX network entry, mobility management, QoS functional elements, core network planning and accounting architecture. WiMAX technique is the one of important wireless access techniques
for the vehicular communication.
Chapter 11, by Wei-Kuo Chiang and An-Nie Ren, presents the interworking of IP multimedia subsystem
and vehicular communication gateway. To provide a variety of IP-based multimedia services to those
users in the car, this chapter investigates the issue of interworking between IP Multimedia Subsystem
(IMS) and telematics of the vehicular industry.
Section 5 of the book, Vehicular Ad Hoc Networks and Delay Tolerant Vehicular Networks, presents
MAC, routing protocols, and applications for vehicular ad hoc networks, and DTN technologies for
vehicular networks.
Chapter 12, by Chih-Yung Chang, presents MAC protocols in vehicular ad hoc networks. The
achievement of requirements of VANETs highly relies on efficient MAC protocols which determine the
performance of packet transmission in terms of success rate, delay, throughput and bandwidth utilization.
This chapter reviews existing MAC protocols developed for VANETs.
Chapter 13, by Yuh-Shyan Chen and Yun-Wei Lin, presents routing protocols in vehicular ad hoc
networks. The design of routing protocols in VANETs is important and necessary issue for support the
smart ITS. This chapter discusses existing routing results, including unicast protocol, multicast protocol,
geocast protocol, mobicast protocol, and broadcast protocol, in VANETs.
Chapter 14, by Tzung-Shi Chen, Hua-Wen Tsai, and Yi-Shiang Chang, discusses applications in
vehicular ad hoc networks. Vehicular communication systems and applications become more and more
important to people in daily life. The applications of VANETs are introduced in this Chapter.
Chapter 15, by Kun-Chan Lan, reports DTN technologies for vehicular networks. A Delay Tolerant Network (DTN) is one type of challenged network where network contacts are intermittent or link
performance is highly variable or extreme. This chapter discusses some research challenges and issues
which might occur in a Delay Tolerant Network.
Section 6 of the book, Management and Traffic Control, presents the simple transportation management framework, the vehicular system management architecture and application platform, the remote
vehicular system management function and information structure, and the wireless mesh network for
the traffic control.
Chapter 16, by Chyi-Ren Dow, discusses the simple transportation management framework. The
Simple Transportation Management Framework (STMF) specifies a set of rules and protocols which can
be used to organize, describe, and exchange transportation management information between transportation management applications and equipments.
Chapter 17, by Teng-Wen Chang and Jiann-Liang Chen, reports the vehicular system management
architecture and application platform. In this chapter, the Open Gateway Service Initiative Vehicle
Expert Group (OSGi/VEG) was integrated into an Android platform to generate a vehicular Android/
OSGi platform.
Chapter 18, by Teng-Wen Chang and Jiann-Liang Chen, presents the remote vehicular system management functions and information structure. On purpose solving heterogamous technologies that are
incompatible with each other, this chapter develops a “WBEM-based Remote Management and Heterogeneous Vehicular Network Diagnosis System” on the OSGi Gateway.
Chapter 19, by Kun-Chan Lan, presents the wireless mesh network for traffic control. Wireless mesh
networks (WMN) have attracted considerable interest in recent years. This chapter described a real-world
xxiv
testbed, which sets a goal of designing a wireless mesh network architecture to solve the communication
needs of the traffic control system in Sydney, Australia.
The final section of the book, Mobility Model, Simulation, and Security, provides a detailed description of mobility models of vehicular networks, REALISTIC simulation of vehicular networks, and
security attacks of vehicular networks.
Chapter 20, by Kun-Chan Lan, reports the mobility models of vehicular networks. A key component
for vehicular network simulation is a realistic vehicular mobility model that ensures conclusions drawn
from simulation experiments will carry through to real deployments. To get accurate results, the mobility
models of vehicular networks should be as realistic as possible, and involve road-maps with all constraints
and facilities related to the vehicular movement. Therefore, this chapter provides an overview of some
mobility models that are relevant to vehicular networks.
Chapter 21, by Kun-Chan Lan, presents the realistic simulation of vehicular networks. This chapter
introduces a tool, MOVE, that allows users to rapidly generate realistic mobility models for vehicular
network simulations. MOVE is built on top of an open source micro-traffic simulator SUMO. The output of MOVE is a realistic mobility model and can be immediately used by popular network simulators
such as ns-2 and Qualnet.
Chapter 22, by Jen-Chun Chang, Chun-I Fan, and Ruei-Hau Hsu, discusses the security attacks of
vehicular networks. This chapter classifies all possible attacks of vehicular network from every network layer, and also introduces the reason of forming every attack and the possible effect on vehicular
networks.
Finally, we thank all contributors of the book for their outstanding contributions. We hope you
will enjoy reading this book as we did and you will find this issue informative and helpful in keeping
yourselves up-to-date in the fast changing field of telematics communication technologies and vehicular
networks, from wireless architectures to applications
Chung-Ming Huang
National Cheng Kung University, Taiwan, R.O.C.
Yuh-Shyan Chen
National Taipei University, Taiwan, R.O.C.
July 2009
xxv
Acknowledgment
The editors and authors are working members of The Promotion Center for Telematics Consortium
(PCTC), which is part of the Information and Communication Human Resource Program, Ministry of
Education (MOE), Taiwan, R.O.C. Thanks for the program of MOE such that the editors and authors
can be grouped together. Many thanks to all authors for their hard work and cooperation for delivering
their chapters. We also would like to thank Joel A. Gamon of IGI Global for his help and encouragement
during this period.
Section 1
Introduction of Vehicular
Networks and Intelligent
Transporation Systems
1
Chapter 1
Introduction of Vehicular
Network Architectures
Ming-Chiao Chen
National Taitung University, Taitung, Taiwan, R.O.C.
Teng-Wen Chang
National Taiwan University, Taipei, Taiwan, R.O.C.
absTracT
A vehicular network organizes and connects vehicles with each other, and with mobile and fixed-locations
resources. This chapter discusses the architectures in the vehicular network environment. The authors
introduce the overview of in-vehicle and out-vehicle network architectures. An automobile in an in-vehicle
network adopts four vehicle bus protocols, CAN (Controller Area Network), LIN (Local Interconnect
Network), MOST (Media Oriented Systems Transport) and FlexRay. However, these protocols cannot
intercommunicate with each other. Therefore, the OSEK operating system is designed as standard software
architecture for the various ECUs (Electronic Control Units). In the out-vehicle network, the OBU (On
Board Unit) in the automobile can communicate with the infrastructure via the Internet. The authors
discuss next-generation vehicular network architecture, the modern in-vehicle networks, on-board computers and the Internet, mobile telecommunications and telematics applications in the ground vehicles,
and finally, we introduce future desired features. This chapter discusses the architectures in vehicular
network environment. The first section introduces the overview of in-vehicle and out-vehicle network
architectures. The next section describes in-vehicle network architecture for disaster communication
network by combining various automotive bus protocols. The third section describes the out-vehicle
network architecture for disaster communication network by combining various wireless LANs. The
last section discusses next-generation vehicular network architecture, the modern in-vehicle networks,
on-board computers and the Internet, mobile telecommunications and telematics applications in the
ground vehicles, and introduces future desired features.
DOI: 10.4018/978-1-60566-840-6.ch001
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Introduction of Vehicular Network Architectures
inTroducTion
A vehicular network organizes and connects
vehicles with each other, and with mobile and
fixed-locations resources (Wu et al., 2005).
Many telematics architectures, including navigation services architecture, traffic information
architecture, location-based services architecture,
entertainment services architecture, emergency
and safety services architecture have been provided. In these architectures, traffic information
and navigation services are generally provided
by central TSPs (Telematics Service Providers).
Emergency and safety services are supplied by an
on-board platform, which is likely to be installed
by the individual car manufacturers.
In contrast to these conventionally adopted
architectures, telematics architectures are rarely
applied in public local hotspots such as public
parking lots, hotels, restaurants, airports and
shopping centers. In local hot-spot architecture,
a vehicle is considered as an alternative mobile
computing platform (logically equivalent to a
PDA, laptop or a cellular phone) with short-range
localized WLAN (Wireless LAN) devices such
as Bluetooth and Wi-Fi. This local (hot-spot)
architecture allows the car driver to interact with
many local services. Telematics architectures
will be useful for telematics services only for
vehicles providing traditional services such as
traffic information, navigation services provided
by the central TSP, and local services provided
by distributed third-party service providers that
can supply the appropriate contextual data. For
instance, consider a driver wishing to drive a car
to a convention center. The driver initially finds
routes to the center using a navigator, then selects
a route free from traffic jam based on traffic
information from a TSP. The car automatically
discovers the resources of the convention center,
obtains directions to the designated parking lot,
and makes associated payments using the WLAN
communication, as it enters the premises. The
driver can obtain various local services provided
2
by the convention center even before stepping
out of the car.
Current telematics systems depend on mobile
infrastructures to deliver telematics services to
service users. Therefore, deploying a telematics
service between mobile networks it is a very
expensive task. System developers need to have
strong knowledge about the underlying mobile
network. Additionally, a telematics terminal
cannot be applied for the telematics service
from another telematics service provider, since
telematics service developers devise their own
protocols between telematics terminals and a
service provider.
Figure 1 shows an overview of in-vehicle
network architecture and out-vehicle network
architecture. An automobile in an in-vehicle
network adopts four vehicle bus protocols, CAN
(Controller Area Network), LIN (Local Interconnect Network), MOST (Media Oriented Systems
Transport) and FlexRay. However, these protocols
cannot intercommunicate with each other. Therefore, the OSEK operating system was designed
as standard software architecture for the various
ECUs (Electronic Control Units). In the outvehicle network, the OBU (On Board Unit) in the
automobile can communicate with the infrastructure via the Internet. The remote home service
and remote vehicular service providers provide
particular services to an automotive user. The invehicle and out-vehicle network architectures are
discussed in detail in the next two sections.
in-Vehicle neTwork
archiTecTure
This section introduces an in-vehicle network
architecture for disaster communication network
that combine different automotive bus protocols,
namely Controller Area Network (CAN), Local
Interconnect Network (LIN) and the recently
developed FlexRay protocol standard. Moreover,
the OSEK/VDX operating system, a joint project
Introduction of Vehicular Network Architectures
Figure 1. In-vehicle and out-vehicle network architecture
of the automotive industry, manipulates automotive messages between different bus protocols to
support efficient usage of resources for automotive
control unit application software.
controller area network
German automotive system supplier Robert Bosch
created CAN in the mid-1980s for automotive applications as an effective means of allowing robust
serial communication (Pazul et al., 1999). The goal
was to establish a standard for more reliable and
efficient communication by integrating devices,
sensors and actuators in a system for real-time
control applications. The CAN protocol combines
networks and electronic control units thus reducing both wiring harness and complexity. CAN
has now gained widespread use in automotives
and mobile applications, as well as in industrial
automation applications.
The CAN (Robert Bosch et al., 1991) specification has two parts. Part A describes the CAN
message format as it is defined in CAN specification 1.2, and part B describes both standard and
extended message formats. To achieve design
transparency and implementation flexibility, CAN
is divided into three layers, the object, transfer
and physical layers. Figure 2 Johansson et al.
(2003) illustrates a CAN bus with three nodes.
Johansson et al. (2003) described an application
process example of a node. A temperature sensor
decides when to request the transmission of a message frame. The frame consists of a data field and
overhead, such as the identifier and control fields.
Since the application processes are asynchronous,
the bus has a mechanism called CSMA/CD, carrier sense multiple access/collision avoidance,
for resolving conflicts. The protocol listens to the
network in order to avoid collision.
CAN has four frame types, namely data, remote, error and overload frames. The data frame
is the only frame that is adopted for data transmission. The data frame has two message formats,
base frame format (with 11-bit identifier) and
3
Introduction of Vehicular Network Architectures
Figure 2. Three nodes connected through a CAN
bus
sub-network of a CAN bus to integrate intelligent
sensor devices or actuators in modern cars.
The main features of LIN include:
•
•
•
extended frame format (with 29-bit identifier).
This discussion focuses on the base frame format,
shown in Figure 3 Johansson et al. (2003). The
start-of-frame (SOF) bit denotes the start of the
frame transmission. It is followed by the 11-bit
identifier and the remote transmission request
(RTR) bit. The control field consists of 6 bits, and
denotes the number of bytes of data that follow in
the data field. The data field contains 0-8 bytes. It
is followed by the cyclic redundancy checksum
(CRC) field, which enables the receiver to check
whether the received bit sequence is corrupt. The
transmitter adopts 2-bit acknowledgment (ACK)
field, ACK slot bit, to receive an acknowledgment
of a valid frame from any receiver. The end of a
message frame is a 7-bit end-of-frame (EOF).
local interconnect network
The Local Interconnect Network Bus (LIN-Bus)
is a vehicle bus standard or computer networking bus-system used within current automotive
network architectures. The LIN specification is
enforced by the LIN-consortium, with the first
exploited version 1.1, released in 1999. The specification has since evolved to version 2.1 to satisfy
current networking needs. The LIN bus is a small
and slow network system that is used as a cheap
Figure 3.CAN message frame
4
•
•
•
•
•
•
Mono-master, up to 15 slaves
1 wired bus
Bitrates 1-20 Kbits/s: 2.4Kbits, 9.6Kbits
and 19.2Kbits are usually used in automotive applications
Multicast (broadcast) messages
Self-synchronization of the slave (only the
master has an accurate clock as crystal)
Messages with 2,4 or 8 data bytes, and 3
control bytes
Error detection by 8 bits checksum and 2
parity bits in identifier
Physical layer: ISO9141
Sleep / wake-up capability
The LIN implements serial communication in
a state-machine, with small microcontrollers or
CPLDs. A slave ECU does not need an accurate
clock, so can replace crystals or resonators with an
RC cell. This is a cost-effective means of designing
smart actuators or sensors, or smart connectors.
The specification describes three of the seven
layers of the OSI model namely physical layer,
data link layer and application layer.
A LIN network consists of a LIN master and one
or more LIN slaves. The LIN bus in an automotive
application is generally connected between smart
sensors or actuators and an Electronic Control
Unit (ECU), which is often a gateway with a
CAN bus. A LIN network may have several LIN
buses with no interconnection between them, as
shown in Figure 4. This network markedly dif-
Introduction of Vehicular Network Architectures
Figure 4. LIN bus
fers from other low-cost buses as K-line which
was intended to link all the ECUs to an external
analysis approach for diagnosis purposes.
Flexray
FlexRay is a new communication standard that
provides a high-speed serial communication, timetriggered bus and fault-tolerant communication
between electronic devices for future automotive
applications (FlexRay, 2005; Xu et al., 2008).
FlexRay (2005) was developed for the next generation of automobiles and future applications,
including x-by-wire, by a consortium founded
by BMW, Bosch, DaimlerChrysler and Philips
in 2000 (FlexRay Consortium, 2009).
The FlexRay protocol provides a high-speed,
deterministic and fault-tolerant communications
technology. FlexRay is designed specifically for
in-vehicle networking, and therefore does not
replace existing networks, but instead works in
conjunction with already well-established systems, such as the controller area network (CAN),
local interconnect network (LIN) and media oriented systems transport (MOST). In Figure 5, an
in-vehicle network with FlexRay serving as the
backbone provides determinism for engine control
and fault tolerance for steer-by-wire, brake-bywire and other advanced safety applications.
vasos and osek/VdX
in-Vehicle management system
vASOS (Sun et al., 2006) (Vehicular Application Specific Embedded Operating Systems)
is designed specifically for vehicle use, and is
designed to run on a high-performance user interface computer. It fulfills and provides specific
Figure 5. FlexRay backbone
5
Introduction of Vehicular Network Architectures
device drivers, such as CAN/LIN buses, which
are used to communicate with other ECU nodes
for diagnostic purposes, and other fundamental
network functions for the vehicle domain.
OSEK/VDX (Kim et al., 2007) (Open systems
and corresponding interfaces for automotive
electronics / Vehicle Distributed eXecutive) is an
open vehicular industry standard that was founded
as a French-German joint project, and which is
now drawing attention world-wide. The primary
aims of OSEK/VDX are to address the high cost
in developing and redeveloping Electronic Control
Unit (ECU) software, and to improve the compatibility of those applications. The most important
advantages of OSEK/VDX include portability and
reliability. OSEK/VDX includes specifications for
OSEK Operating System (OS), OSEK Communication (COM), OSEKNetwork Manager (NM)
and OSEK Implementation Language (OIL).
The properties of vASOS are as follows:
•
•
Focusing on system real-time performance,
scalability and robustness.
Small kernel size, small memory footprint,
low-cost and high efficiency.
•
•
•
Plug and play device driver interfaces for
expansibility.
Emphasis on network control methods, especially wireless networks.
Fast boot-up and good power management.
Figure 6 shows the OSEK/VDX In-vehicle
Management System, which consists of three
components:
•
•
vASOS COM: Although OSEK/VDX
COM provides a rich set of communication facilities, many applications, such as
this vASOS prototype model, probably
only require a minimum subset of this
functionality and all observe OSEK/VDX
COM specification.
OSEK/VDX COM module is composed
of:
◦
An Interaction layer: The layer that
provides communication services for
the transfer of application messages.
◦
A Network layer: The layer that
provides services for the unacknowledged and segmented transfer of
Figure 6. OSEK/VDX in-vehicle network management architecture
6
Introduction of Vehicular Network Architectures
•
application messages. The network
layer provides flow control mechanisms to allow interfacing of communication peers featuring different level of performance and capabilities.
◦
A Data link layer interface that provides services for the unacknowledged transfer of individual data
packets over a network to the layers
above it.
vASOS NM: The NM module focuses
mainly on ensuring the safety and the reliability of a communication network for
ECUs. This module provides two alternative mechanisms for network monitoring:
indirect monitoring by monitored application messages and direct monitoring by
dedicated NM communication using the
token principle.
ouT-Vehicle neTwork
archiTecTure
This section introduces out-vehicular network
architecture for disaster communication network
by combining different wireless networks. Currently available wireless technologies, including
IEEE802.11p (2007), IEEE802.16 (WiMAX)
(2006), and cellular networks, are combined with
a mobile router, and loaded on a car to construct
a mobile network node.
ieee 802.11p
A vehicular environment requires a set of new
requirements on modern wireless communication systems. Vehicular safety communications
applications cannot tolerate long connection
establishment delays before communicating with
other vehicles encountered on the road.
The IEEE 802.11p standard, also referred to
as Wireless Access for the Vehicular Environment (WAVE), is designed to solve these issues.
The WAVE protocol provides improvements to
the physical (PHY) and medium access control
(MAC) layers of the existing 802.11 wireless
standards.
The Department of Transportation of the
United States advocates and supports ITS (Intelligent Transportation System) based on dedicated
Figure 7. Vehicle safety communication examples
7
Introduction of Vehicular Network Architectures
short range communications (DSRC (Xiang et al.,
2006)) systems that provide vehicle-to-vehicle and
vehicle-to-roadside information exchanges. ITS
largely focuses on enabling public safety applications that can save lives and improve traffic flow.
Jiang et al. (2006) Two such application scenarios
are shown in Figure 7. Private services are also allowed in order to spread the deployment costs, and
to encourage the quick development and adoption
of DSRC technologies and applications.
The DSRC spectrum, as shown in Figure 8
(Eichler et al., 2007; Jiang et al., 2006), is structured into seven channels, each with a bandwidth of
10-MHz. The control channel (CCH) is restricted
to safety communications only. The two channels
at the ends of the spectrum band are reserved for
special applications. The service channels (SCH) is
available for both safety and non-safety usage.
wimaX
The Mobile WiMAX network consists of the
access services network (ASN) and connectivity services network (CSN). The core elements
in the ASN are the base station (BS) and ASN
gateway (ASN-GW), which are connected over
an IP cloud. The functionality across the ASN-GW
and BS is split and signaled via R6. The ASN-GW
provides security anchoring, traffic accounting,
and mobility anchoring (and proxy) for the mobile
station (MS). The Mobile IP home agent (HA) in
the CSN is used as a global mobility anchor, and
Figure 8. DSRC spectrum band
8
is an optional element depending on deployment
choices. In the simplified form (Simple IP), the
user traffic bypasses the HA in the CSN.
The user traffic is tunneled as payload between
the BS and the ASN-GW. The Proxy Mobile IP
protocol handles mobility between the ASN-GW
and the HA. A WiMAX BS can potentially connect
to any ASN-GW that it can reach via IP connectivity
(flex R6). This flexibility helps decrease mobilityrelated signaling in the network, since the same
ASN-GW can serve the user’s active IP session
while the user is moving across several different BSs
(e.g., ASN-GW relocation is rarely required). The
R8 interface can facilitate the context transfer and
handover optimization when the user moves from
one BS to another. Figure 9 shows the end-to-end
Mobile WiMAX network architecture.
The WiMAX Forum has defined an architecture
that determines how a WiMAX network connects
with other networks, and a variety of other aspects
of operating such a network, including address
allocation and authentication. Figure 10 shows
an overview of the architecture.
•
•
•
•
•
•
•
SS/MS: Subscriber Station/Mobile Station
BS: Base station, part of the ASN
ASN-GW: The ASN Gateway, part of the
ASN
CSN: The Connectivity Service Network
HA: Home Agent, part of the CSN
AAA: AAA Server, part of the CSN
NAP: A Network Access Provider
Introduction of Vehicular Network Architectures
Figure 9. Mobile WiMAX network architecture
neXT-generaTion Vehicular
neTwork archiTecTure
This section discusses the architecture of the
Next-Generation Vehicle Network, which is under
development at the University of Detroit Mercy
by several researchers in collaboration (Mahfoud
et al., 2008).
in-Vehicle personal computer
Automotive manufacturers are planning to provide
new Internet and entertainment services inside vehicles. These services need to monitor and collect
data collection from increasing the requirement for
computing capabilities onboard vehicles (InCode
Telecom Group, 2009; Microsoft drives, 2004;
Mosra et al., 2004). The largest computer hardware and software companies are now developing
suitable platforms that would provide the desired
telematics and Internet services for vehicles.
For instance, the Intel Corporation has announced plans to bring PCs to cars in a project
called Connected Car PC Technology, and has
indicated it at many events, including the Consumer Electronics Show in Las Vegas in 1998
(Machen, 2009), where Intel demonstrated a Ford
Expedition loaded with a Pentium MMX-based
computer. This computer provides voice- activated
satellite-based navigation, Internet access, cellular
phone calls, games and DVD movies.
The IBM infotainment system Imaj provides an
example of on-board computers. Imaj comprises of
three 12-inch LCD screens built into the car seats
facing three rear-seat passengers. These screens
provide access to radio, audio player, video player,
fax, phone, e-mail, calculator, satellite mapping,
local information, word processing, web brows-
9
Introduction of Vehicular Network Architectures
Figure 10. The WiMAX overview of the architecture
ing, and calendar functions all controlled either
by mouse or by speech using IBM via-Voice
technology (Ibm.com).
Software platforms are being developed for
in-vehicle computers to provide voice-activated
commands. For instance, Microsoft Corporation
has launched the .NET Connected Car (Microsoft
drives, 2004), which provides the next generation of software for the melding of computing
and communications in the vehicle (Microsoft.
com, 2009). Microsoft describes Connected Car
as follows: “Tomorrow’s driver can expect better
information through systems built on the Microsoft
.NET Connected Car software, a new generation of
technology that connects individual cars to other
information systems through the Internet. Your
next car may tell you that you should change the
oil sooner than expected. It may also direct you to
the closest dealer, help schedule an appointment,
notify you of oil change specials, and keep you
informed on up-to-date service alerts.” (Microsoft
drives, 2004).
10
The .NET Connected Car uses the Windows
Automotive operating system, which provides
computing services such as voice-activated commands, and video and audio support for entertainment. The .NET Connected Car also includes
built-in support for popular wireless technologies,
including Wi-Fi, General Packet Radio Service
(GPRS), Bluetooth and Code Division Multiple
Access (CDMA) (Microsoft drives, 2004).
system architecture
Figure 11 shows the system architecture, which
consists of three subsystems. The first subsystem
is the vehicle, which includes the various networks
and the on-board PC. Next is the wireless communication network, which provides a telephone
service, as well as a WAN (Wide Area Network)
connection between the PC and the Internet. The
third subsystem is the Internet, which provides a
database server for vehicle information.
Introduction of Vehicular Network Architectures
Figure 11. A block diagram of the next generation vehicle network
Vehicle Network and the On-board PC
This architecture considers that all the intelligent
sensors, actuators and other control units inside
the vehicle are implemented by CAN-capable
microcontrollers. In this case, the CAN protocol
is implemented for networking these devices
together. Networking all these devices together
in one network would enable them to exchange
data among themselves, while also allowing any
device to transmit data to an external network, or
be accessed from it to provide features such as
remote diagnostics, monitoring, data collection
and remote firmware upgrade.
This architecture makes various hardware and
software changes to the vehicle CAN network in
order to make this network Internet-enabled. The
remote firmware upgrade feature of the CAN nodes
requires the most changes. The discussed architecture requires the CAN modules to have Flash
memory for code, and an on-module or on-chip
(built into the micro-controller unit (MCU)) Flash
programming voltage generator. The firmware of
the CAN nodes have a specially-developed Bootloader core in the nonvolatile memory of the MCU,
thus enabling access to the MCU via the CAN bus
through the CAN port of the MCU to reprogram the
Flash memory when required. This new feature is
essential for facilitating and easing the debugging
and reprogramming of the CAN nodes, as well as
for enabling this task to be performed remotely
over the Internet. The CAN nodes should also be
able to operate in Wakeup mode, the nodes would
consume the minimum amount of battery power
when the vehicle is stopped, while still being able
to be woken up remotely, if required, to perform
a diagnosis task.
To reduce the cost and size, and to minimize
technology obsolescence, an on-board computer
generally does not have very high storage and
processing capacity (Encyclopedia.com, 2009).
Additionally, this computer mostly acts as a
client depending on the remote server on the
Internet, and therefore does not require very high
performance.
11
Introduction of Vehicular Network Architectures
The In-vehicle, or on-board, PC plays several
roles in this architecture. It is the master control
unit for the vehicle, the TCU (Telematics Control
Unit) (Ibm.com) and a gateway for the different
networks inside the vehicle. The gateway role provides connectivity among the in-vehicle networks
themselves, and between each of them and the
Internet as necessary. Therefore, the PC requires
an interface to every network that needs to be connected to it. Additionally, the PC should also have
an interface to the Internet to provide connectivity
(gateway) between the vehicle network and the
Internet, as well as to provide regular Internet
access for browsing and entertainment.
The Wireless Network
The wireless network in this architecture exists to
provide communication, phone calls and Internet
access inside the vehicle. In this subsystem, the
on-board PC is connected to the Internet via a
WAN (Wide Area Network) Connection. This
WAN is a wireless Internet connection provided
by any appropriate wireless communications carrier for cellular phones and similar devices. Speed
and availability are the main factors to determine
the suitability of that carrier. The GPRS (General
Packet Radio Service) (Gsmworld.com, 2009),
which is a packet-switching, non-voice service,
can be implemented as the wireless Internet
connection. It allows information to be sent and
received across a mobile telephone network, and
provides actual packet radio access and timedivision multiple access (TDMA) to users.
GPRS is currently adopted to gain wireless
access to many Internet applications and services
wirelessly such as chat, textual and visual information including the download of audio, still and
moving images; web browsing; email; vehicle
positioning with collaboration from GPS; remote
LAN access; and file transfer. These applications can be accessed by several GPRS devices
(terminals), such as web-enabled cellular phone
12
sets and the wireless PCMCIA cards for laptops
and pocket PCs (Gsmworld.com, 2009).
GPRS has a theoretical maximum speed of
171.2 kilobits per second (kbps) when using all
eight timeslots at the same time. The most important feature of the GPRS is immediacy, which a
dialup connection is not required. Users can access
the Internet immediately, since they are always
connected due to the packet-switching technology
adopted by GPRS on the existing circuit-switching
GSM (Gsmworld.com, 2009).
The Internet
An Internet server is required to store uploaded
data from the vehicles. Each vehicle has its own
account on such server. The manufacturer and the
service center can access to the vehicle’s date in that
server. The Internet is also adopted to access the
computer on board the vehicle and, consequently,
to access the vehicle network that is connected to
and monitored by that computer. Accessing the
on-board computer from the Internet requires the
implementation of strict security measures that ensure appropriate access for authorized parties only.
Vehicle data can be protected by implementing
frameworks for data protection based on privacy
and security technologies (Duri et al., 2002).
reFerences
Duri, S., Gruteser, M., Liu, X., Moskowitz, P.,
Perez, R., Singh, M., & Tang, J. M. (2002).
Framework for security and privacy in automotive
telematics. In Mobile Computing and Networking,
(pp. 25-32).
Eichler, S. (2007). Performance evaluation of the
IEEE 802.11p WAVE communication standard.
In Proceedings of IEEE Vehicular Technology
Conference, (pp. 2199-2203).
Introduction of Vehicular Network Architectures
Encyclopedia.com. (2009). Telematics is not a
question of if, but when. Retrieved from http://
www.encyclopedia.com/doc/1G1-94875067.
html
FlexRay Communications System Protocol Specification v2.1 Revision A. (2005).
FlexRay Consortium. (2009). Retrieved from
http://www.flexray.com
Gsmworld.com. (2009). Retrieved from http://
www.gsmworld.com/technology/gprs/index.
shtml
Ibm.com. (n.d.). Focus on the road ahead: IBM
puts practical telematics within reach. Retrieved
from http://www-306.ibm.com/software/pervasive/info/Telematics_within_reach_050404.pdf
IEEE802.16-2005. (2006). Part 16: Air interface
for fixed and mobile broadband wireless access
systems amendment 2: Physical and medium access control layers for combined fixed and mobile
operation in licensed bands and corrigendum 1.
IEEE P802.11p/D3.0. (2007). Draft amendment
for wireless access in vehicular environments
(WAVE).
InCode Telecom Group Inc. (2009). Telematics:
How economic and technological forces will
shape the industry in the U.S. Retrieved from
http://www.incodewireless.com/pdfMailer/files/
Telematics_Position_Paper_v11.pdf
Jiang, D., & Delgrossi, L. (2008). IEEE 802.11p:
Towards an international standard for wireless access in vehicular environments. In IEEE Vehicular
Technology Conference, (pp. 2036-2040).
Johansson, K. H., Torngren, M., & Nielsen. L.
(2003). Vehicle applications of controller area
network. Technical Report Department of Signals,
Sensors and Systems, Royal Institute of Technology, Stockholm, Sweden, Department of Electrical
Engineering, Linkoping University, Sweden.
Kim, J. H., Seo, S. H., & Moon, T. Y. (2007). A
method of improving the reliability of the gateway
system by using OSEK/VDX. In Proceedings of
International Conference on Control, Automation
and System, (pp. 2328-2833).
Machen. L. (2009). Technical marketing engineer,
“Intel drives in-vehicle solutions” handheld
components division. Retrieved from http://
www.intel.com/technology/magazine/computing/
it04001.pdf
Mahfoud, M., Al-Holou, N., & Baroody, R. (2008).
Next generation vehicle network: Web enable. In
Proceedings of 3rd International Conference on
Information and Communication Technologies:
From Theory to Applications, (pp. 1-7).
Microsoft drives to Las Vegas. (2004). Connected
Concept Cars. Retrieved from http://www.windowsfordevices.com/news/NS5155857065.html
Microsoft.com. (2009). Windows Automotive.
Retrieved from http://www.microsoft.com/windowsautomotive/wa5/default.mspx.
Mosra, S. R., Shanker, S., & Mahmud, S. M.
(2004). An intelligent architecture for issuing
intersection collision warnings (pp. 176-183).
National Defense Industries Association (NDIA).
OSEK VEX Portal, (n.d.). Retrieved from http://
www.osek-vdx.org
Pazul. K. (1999). An introduction to the CAN
protocol that discusses the basics and key features.
Microchip Application Note #AN713.
Robert Bosch Gmb, H. Stuttgart, Germany, (1991).
CAN Specification ver. 2.0.
Sun, Y., Wang, F. Y., Wang, Z. X., Qiao, X., &
Wang, K. F. (2006). A scheduling algorithm for
vehicular application specific embedded operating
systems. In Proceedings of IEEE International
Conference on Systems, Man and Cybernetics,
(pp. 2535-2540).
13
Introduction of Vehicular Network Architectures
Wu, H., Fujimoto, R., Hunter, M., & Guensler,
R. (2005). An architecture study of infrastructurebased vehicular networks. In ACM MSWiM,
Montreal, Canada, (pp.36-39).
Xiang, W., Richardson, P., & Guo, J. (2006). Introduction and preliminary experimental results
of wireless access for vehicular environments
(WAVE) systems. In Proceedings of 3rd Annual
International Conference on Mobile and Ubiquitous Systems, (pp.1-8).
14
Xu, Y. N., Kim, Y. E., Cho, K. J., Chung, J. G., &
Lim, M. S. (2008). Implementation of FLexRay
communication controller protocol with application to a robot system. In Proceedings of 15ht
International Conference on Electronics, Circuits
and Systems, (pp. 994-997).
15
Chapter 2
Introduction of Vehicular
Network Applications
Yao-Chung Chang
National Taitung University, Taiwan, R.O.C.
absTracT
Information and Communication Technology (ICT) is concerned with all the technologies that manage,
process, and communicate information. It is also named as telematics, combining two words: telecommunications and informatics, which is widely used in the application of Global Positioning System
technology integrated with computers and in the mobile communications technology for automotive
navigation systems. Table 2.1 and Table 2.2 respectively list the telemetric applications from user’s
point of view and the practical applications of vehicular telematics. Four applications of the vehicular
network are discussed in this chapter. The first section introduces the vehicular network application
services. The second section discusses the vehicular network application management. The third section
provides the platform technologies of vehicular network application. Finally, future vehicular network
application and deployments are presented in the fourth section.
inTroducTion
Service bundle provision systems (Choi et al., 2005;
Han et al., 2005) enable users to search, download
and install service applications that can be operated
on a user terminal in an open telematics environment
(shown in Figure 1). The system has incorporated the
telematics gateway in the service providers including
the wireless optimized TCP, the wireless optimized
HTTP, the SMS gateway, the push module and the
framework, as illustrated in Figure 1. Such a system
has three main components: gateway, framework
and world telematics protocol.
•
Gateway: The gateway allows developers
to write a telematics server application that
DOI: 10.4018/978-1-60566-840-6.ch002
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Introduction of Vehicular Network Applications
Figure 1. Open telematics service
•
•
can be operated irrespective of the gateway
of the mobile network.
Framework: The developers can write
applications, without knowing about the
details of integrating the related servers
distributed in networks, by utilizing APIs
supported by the framework.
World Telematics Protocol (WTP)
(WTP1.0 Specification, 2004): WTP defines a protocol to exchange messages between a telematics terminal in a vehicle and a
telematics service center. Telematics service
developers and service providers can develop and provide telematics services that do
not depend on devices and service carriers.
See Tables 1 and 2.
Table 1. Telematics applications from user’s point
of view
Audio (CD / Radio)
16
Telephone
The telematics portal framework (shown in
Figure 2) is mainly divided into three components.
The first component is a provisioning service part
that provides a telematics terminal with telematics service bundles. The second component is a
service bundle management module that provides
functionality for deploying and managing service
bundles. The third component is a repository module that not only supports other two components
and stores service bundles and related data, but
also allows search and manage service bundles.
Additionally, it supports various software providing protocols including JNLP, MIDP and J2EE
client provisioning.
Table 2. Practical applications of vehicle telematics
Vehicle tracking
Wireless vehicle safety
communications
Trailer tracking
Emergency warning system
for vehicles
Cold store freight logistics
Intelligent vehicle technologies
Telephone
Navigation
Fleet management
Car clubs
Video
Speech recognition
Satellite navigation
Auto insurance
Short messaging (SMS)
User interface for body
electronic
Mobile data and mobile
television
Introduction of Vehicular Network Applications
Proactive services (Gura et al., 2001) describe
a mobile application for traffic telematics based
on the JINI middleware. The main contribution
proactively is the definition of a user agent that
closely interacts with a service discovery and
lookup facility. The lookup service is available in
each vehicle and provides a set of both user-level
services and lower-level services for accumulating,
improving and distributing information obtaind
from various embedded sensors. The low-level
services form the basis for context creation. To
exploit these services proactively, a user agent is
designed to perform the following tasks:
•
•
User agents monitor available services on
other vehicles. They are parameterized by
user profiles, and are selected based on
user settings.
User agents assess the lower-level floating
car data to generate the context based on
which decisions involve services.
•
User agents provide a user-defined appearance of user-level services. Thus, a single
look-and-feel interface encompasses the
various interfaces of various services as
much as possible.
The Road-Look-Ahead (RLA) Service (Gura
et al. 2001) is composed of all relevant elements
of a proactive service listed in the above three
statements. This service dynamically links a car,
e.g. a truck as shown in Figure 3, advertising an
image from the local telematics system. To select
an image that may be offered by many cars in
reach, the user agent needs to perform a selection
according to the context information, including
the speed of the car and the direction, thus filtering out cars that are far away or come from the
opposite direction. The system architecture is
based on Java (Sun Microsystems Inc., 2000) and
JINI (Sun Microsystems Inc., 1999) technologies.
The concept of a service is essential to the JINI
system and gives the system various advantages.
Figure 2. The portal framework overview
17
Introduction of Vehicular Network Applications
First, the low-level context information such as
position, direction and speed can be abstracted
and encapsulated in a JINI location service that
abstracts from all specific details of the navigation
devices. Second, JINI provides several mechanisms linked to mobility.
Growing consumer demand for access information in remote, mobile environments has sparked
interests in In-Vehicle Telematics Systems (IVIS).
This work introduces the EmergeITS project
(Reilly et al., 2002), which focuses on using IVTS
in emergency fire services. In particular, this work
describes a distributed service-based architecture,
based on the JINI middleware technology, which
can be employed to provide fault-tolerant application services to remote in-vehicle computers and
mobile devices including Palm devices and WAP
phones. EmergeITS adopts the JINI middleware
(Figure 4) to provide a service-based architecture
that can manage, configure and provide application services to remote in-vehicle computers and
Palm devices.
Figure 3. Road-look-ahead service
18
Vehicular neTwork
applicaTion managemenT
Communications resources management (Punnoose et al., 2001) for advanced telematics applications is divided into three parts: external
communications, internal communications and
interface to resource manager. The architecture
which supports mechanisms for internal and external communications is shown in Figure 5.
Communications between the in-vehicle
components and the exterior pass through a
router gateway. This routing module selects the
appropriate external communication method for
data connections according to the parameters
such as cost, availability and QoS requirements of
the applications. The resource manager interacts
with this routing module to advise it of the QoS
requirements of applications.
Inter-agent communication within the vehicle
must be flexible in order to facilitate the addition
of new software agents. A model that allows the
Introduction of Vehicular Network Applications
Figure 4. SunLabs’ concept of car software architecture
Figure 5. Management of internal and external communications
transfer of data without strict pre-definition (Rajkumar et al., 1995) is preferred, so that all agents
that tap into this infrastructure can be publishers or
subscribers of information, or both. The information that is being published is transparent to the
underlying infrastructure, which merely transports
it from the publishers to the subscribers. Publishers
post information on logical channels. Other agents
can be subscribers to this information.
19
Introduction of Vehicular Network Applications
The resource manager can be a single or distributed entity. Client applications communicate
with the resource manager via network packets.
Therefore, the interface to the resource manager
can be embedded in the same processor as the
client application or in a different machine within
the vehicle. The only information required by the
client is the location of the resource manager.
A modern vehicle contains many electronic
devices (Nolte et al, 2005), linked by Local Interconnect Network (LIN), Controller Area Network
(CAN) and FlexRay (FlexRay Communications
System Protocol Specification v2.1 Revision
A, 2005), to fulfill the needs of customers and
to enhance the performance of the vehicle. The
smart vehicle management system (SVMS) (Seo
et al., 2007) is composed of a gateway, handset
and vehicle management program (VMP). The
increasing number of electronic devices enables
automatic control and management of vehicles.
In particular, automatic management of a vehicle
provides significant benefits to owners (driv-
ers) by decreasing maintenance and increasing
convenience.
The proposed SVMS adopts CDMA wireless
communication (Chan et al., 2003) to control and
manage a vehicle (Bjic et al., 2002). CDMA allows
vehicle owners to access their vehicles anywhere
anytime. Additionally, a handset can be adopted
as the remote-controller for the vehicle. VMP
provides a graphic user interface that manages the
vehicle and owner. The gateway plays in a relay
role. The developed gateway is an intermediate
among handsets, VMPs and vehicular devices,
since this system supports LIN, CAN, FlexRay
and CDMA interfaces. Thus, the proposed SVMS
not only achieves telematics and a ubiquitous
environment within a vehicle, but also manages
electrical components.
Figure 6 illustrates the VMP running on a PC
with a RS-232 interface. The CDMA modem is
linked to the PC via RS-232. The CDMA modem
transfers the received messages to the VMP, and
the commands sent to the gateway. The handset
Figure 6. Smart vehicle management system prototype design
20
Introduction of Vehicular Network Applications
accesses the gateway directly by using the SMS.
The gateway is linked with three embedded systems. For instance, embedded system #3 operates
several LEDs based on VMP commands or handset messages. Each embedded system is connected
using CAN and LIN. Additionally, all operations
of each process are printed in VMP and saved in
a file by a log writer.
The application presentation of telematics is no
restricted to the classical embedded control system,
but instead it covers a broad range from driver assistance to infortainment and vehicle information
management. Management of various telematic
applications requires new application managers
(Kim et al., 2006) for the automotive domain to
support the specific software components, corresponding to the vehicle status, and eventually
combine the system parts to form a single reliable
and manageable system. This work develops a
novel architecture for application management
in in-vehicle software (shown in Figure 7). This
architecture is based on international standards,
including OSGi (Open Service Gateway Initiative, 2003) framework (two major platforms are
Prosyst’s mBedded Server (Prosyst, 2009) and
Gatespace’s e-Services Platform (Gatespace,
2009) and AMI-C Specification (AMI-C, 2002).
Telematics technology, which adopts various telecommunications such as DMB, CDMA, WRAN
and DSRC, is increasingly used to provide services
for in-vehicle telematics systems or context aware
automotive telematics (Zhang et al., 2004). This
service bundles provide in-vehicle applications
such as vehicle status monitoring service, vehicle
tracking and local advertising, can be realized using. This architecture allows in-vehicle terminals
to provide various telematics services to improve
safety of drivers.
Vehicular neTwork
applicaTion plaTForm
Figure 8 shows the architecture and design of an
OSEK/VDX (O’Donnell, 2003) (includes specifications for OSEK Operating System (OS) (OSEK
Group, 2005), OSEK Communication (COM)
(OSEK Group, 2004), OSEK Network Manager
(NM) (OSEK Group, 2004) and OSEK Implementation Language (OIL) (Zheng et al., 2004)) and
OSGi-based Embedded Software Platform (Sun et
al., 2007). Three components are introduced: The
Figure 7. Architecture of application manager
21
Introduction of Vehicular Network Applications
remote vehicular service platform component has
high computation ability and huge data storage.
The vehicle/home interactive platform component
is another OSGi-based framework gateway. The
vehicle driver can interact with it via the wireless
connection and manage home/office appliances
while driving. The roadside system component
refers to ITS infrastructure such as intelligent
traffic light controllers and communication base
stations.
Figure 9 shows OSGi-based remote vehicular
service platform (Wang et al. 2004). The vehicular
integration services mainly combine diagnostics
and prognostics to form the optimal vehicular
control algorithms download services. These
services are generally provided by automotive
manufacturers or third party developers. Vehicular
correlation services mainly provide facilities such
as GPS location and information transmission
management. Transferring information accurately
in real-time is a key to the quality of service.
Individual information services provide services
including entertainment search and download,
information service and vehicle/home interactive service.
Telematics open portal applications zone
(TOPAZ) (Lee et al. 2005) is under development
by the IBM Ubiquitous Lab. Figure 10 describes
two telematic applications based on TOPAZ platform (Choi et al., 2006). These applications are a
call-taxi service and an emergency rescue service
for patient in u-health scenarios. It builds three
Figure 8. Architecture of the OSEK/VDX and OSGi-based embedded software platform
22
Introduction of Vehicular Network Applications
Figure 9. OSGi-based remote vehicular service platform
different applications end-to-end within a short
time period and minimal manpower. Call taxi
application provides the nearest available taxi to
a customer through vehicle tracking information
until the assigned taxi arrives at the customer’s
location. The main parts of the application service
are service clients, call center server and vehicle
dispatch server (VDS). The call center server does
not directly connect to TOPAZ servers, but instead
interacts with VDS and a customer to transfer the
requested data between them.
Emergency rescue service for patient is a preventive service that monitors biological status of
patient using ubiquitous sensors attached to the
patient body, predicts the critical situation of the
patient, and dispatches the emergency vehicle to
the patient’s location. The Health management
server (HMS) was developed to interact with
patients’ devices using the same VDS adopted
in the call taxi application, but to dispatch emergency vehicles rather than taxis. The proposed
emergency rescue service application adopts
the spatiotemporal event detection environment
STEDE (Munson et al., 2005; Lee et al., 2005)
rule-based engine for event detection in TOPAZ
to determine the critical status of the patient.
The growth in Internet subscribers has accelerated at an exponential pace. Wired Internet
access serves subscribers only at attached points,
while wireless communications provide enjoy
ubiquitous/pervasive Internet access. Recent
advances in wireless inter-vehicle communication systems have generated major opportunities
for the deployment of a wide variety of services
to vehicles (Dikajakos et al., 2008). Telematics
provide innovation and new technology in the
automotive sector, while significantly improving
the driving experience (Grymek et al., 2007).
This investigation combines wireless services
with human-computer interaction to provide a
ubiquitous/pervasive computing environment for
telematics services.
IETF defines mobile IP facilities to provide
roaming methods in wireless computing. The
NEMO (NEtwork MObility) (Emst, 2006; Devarapalli et al., 2005) working group has improved
roaming schemes to enable subscribers to use mobile routers for data transmission without worrying
about service environments (Tseng et al., 2007).
23
Introduction of Vehicular Network Applications
Figure 10. Application deployment in TOPAZ
A mobile router can be installed on any vehicle.
The vehicular router communicates with external
vehicular networks. Telematics application users
within a moving vehicle do not need to perform
handoffs individually. The entire vehicle is a subnetwork and performs handoff procedures using
the installed vehicular router. Figure 11 illustrates
the Mobile telematics computing environment.
This study develops an embedded WiMAXbased network mobility system on an Intel IXP425
network processor platform to deploy vehicular
routers for vehicular network telematics computing (Chen et al., 2009). A mobile router can be
installed on any vehicle. The vehicular router
is responsible for communicating with external
vehicular networks. When a vehicle moves,
telematics users within the vehicle do not need
to perform handoffs individually. The whole
vehicle is a sub-network and performs handoff
procedures using the installed vehicular router.
The concept of mobile telematics computing
environment is shown in Figure 11. The mobile
IPv6 scheme, which includes packet formatting,
24
receiving, sending and processing, is established
in the vehicular router. This work also enhances
mobile IPv6 technology and network mobility.
FuTure Vehicular neTwork
applicaTion and deploymenT
A client-server application and Internet based application were developed. Users performed various
remote experiments on a mobile robot, focusing
on motor control, obstacle avoidance and image
processing, and applying these features to trajectory control using the Common Gateway Interface
(CGI) to access the robots (Backes et al., 2000;
Schilling, 2001). The remote user is connected
via the Internet to a dedicated computer, which
controls and monitors the mobile robot (Popescu
et al. 2008). The client was programmed in Java,
while server was programmed in Visual Basic 6.
The Visual Basic server application handles the
application administration module, which involves
user management, and communication with the
Introduction of Vehicular Network Applications
Figure 11. Mobile telematics computing
control board and microcontroller program editor.
An AXIS 205 network video camera sends live
video of the mobile robot to the user’s browser.
The Internet provides a major opportunity for
robotics education by enabling the development
of remote laboratories, where students can gain
practical experience deploying hardware resources
efficiently. The system reduces the time and space
constraints normally associated with the traditional
laboratory, thus making equipment available to
more students.
The InternetCAR project (Ernst et al., 2003;
InternetCAR Project, 2003) develops the architecture needed to connect a car to the Internet, but
does not address the problems of infrastructure
to enable the services. Telematics functions were
configured on a dedicated device, commonly
called a middlebox (Srisuresh et al., 2002). These
middleboxes adopt programmable network processors in order to attain the required processing
and forwarding speeds, while communicating
with each other and the back-end server using
standard middleware components. Urban traffic
prediction with floating car data is an example of
emerging telematic applications that exploits of
global networking capabilities (Chen et al., 2004).
A middlebox is a device performing a service that
needs application logic, but is executed in the
network (shown in Figure 13). The aggregation
function receives UDP packets, processes them
as described above, and generates asynchronous
XML/RPC messages. The function then sends
these messages to the server. XML/RPC is an
RPC protocol that utilizes HTTP as the transport
protocol and XML for data representation. The
front-end server was implemented as a Servlet
running within the WebSphere Servlet engine.
A Mobile Agent-based Middleware for vehicle telematics is proposed in (Guo et al., 2007).
The JNomad, a framework that integrates JINI
technology with mobile agents, is developed
to meet these deployment challenges. JINI is a
novel technology that considers the pervasive,
ubiquitous, and dynamic distributed computing
requirements within a single architecture. To address the mobility and frequent network partition
25
Introduction of Vehicular Network Applications
Figure 12. Telematics architecture for mobile robot
Figure 13. Overview of middleboxes
problem, this investigation designed and implemented a Code-on-Demand Service Model using
JINI technology, and developed a Mobile-Agent
based Service Model.
JNomad is a mobile agent-based framework
consisting of three major components. The first
component is composed of mobile agents, i.e.,
entities that are expected to perform various tasks.
The second component contains the mobile agent
hosts, which provide the platform executed by the
mobile agents. The third component comprises
lookup and location services that provide dynamic
service discovery and location updates. A typical
26
sequence of interactions among different components within the framework is shown in Figure
14. Using the JINI architecture, virtually any
service may interact freely in a network without
the requirement for complex protocols, messaging
drivers, operating systems or cabling.
Security issues are also very important topics
in vehicular applications. A general architecture
for a trusted context provider is proposed in
(MOSQUITO Project, 2005). Different security
mechanisms can be used in different situations
in this architecture. Information Connector is
presented for vehicular environments. A general
Introduction of Vehicular Network Applications
Figure 14. The agent-based framework using JINI technologies
Figure 15. Vehicular security architecture
27
Introduction of Vehicular Network Applications
architecture for security in vehicular environment
is presented in (Nowey et al., 2006). Figure 15
illustrates the overall architecture of vehicular security architecture (Nowey et al. 2007), including
Service Plane, Security Middleware and Context
Aware Applications.
•
•
•
Service plane: The security layer is
configured using the security manager,
which provides the appropriate interface.
Additionally, the security manager sets the
address of the position based routing entity, thus protecting the location privacy of
the users.
Security middleware: The three major
parts of the security middleware are trust
establishment services, revocation services
and privacy services.
Context aware applications: Contextaware applications perform actions such as
issuing a warning to the driver or peer applications based on the context information.
BMW, in collaboration with Telematics Service
Providers (TSPs) Connexis (Connexis, 2009) and
WirelessCar (WirelessCar, 2009), has developed
a new telematics framework and a technologyneutral telematics protocol to bring new flexibility
and scalability to the automotive sector called Next
Generation Telematics Protocol (Next Generation
Telematics Protocol, 2009). Vehicle manufacturers
have historically provided proprietary services to
customers, and have been dependent on a single
TSP for delivery of these services in a specific
market. This supply chain inflexibility has created
difficulties for providers in gaining economies of
scale and promoting their products and services.
Although an open and standardized approach
to delivering services has clear benefits for the
marketplace, previous standardization efforts
have encountered barriers to adoption, because
they have focused on replacing existing protocols
instead of integrating them. The proliferation of
new technologies suggests that future in-vehicle
28
devices are likely to access services using multiple
methods and technologies.
reFerences
AMI-C. (2002). Software API SpecificationsCORE APIs. retrieved September 20 2009, from
http://www.ami-c.org
Backes, P., Tso, K., Norris, J., Tharp, G., Slostad,
J., Bonitz, R., & All, K. (2000). Internet based
Operations for the Mars Polar Lander Mission.
In The 2000 IEEE International Conference on
Robotics & Automation, (pp. 2025-2032).
Bjic, E., & Chaxel, F. (2002). Auto-ID Mobile
Information System for Vehicle Life Cycle Data
Management. IEEE Systems . Man and Cybernetics, 4, 6.
Chan, Alex Y. M., & Lu, W. P. (2003). Architecture
for Wireless Access in Vehicles. IEEE Vehicular
Technology Conference, 5, 3336-3340.
Chen, A., Jain, N., Perinola, A., Pietraszek, T.,
Rooney, S., & Scotton, P. (2004). Scaling RealTime Telematics Applications using Programmable Middleboxes: A Case Study in Traffic Prediction. In First IEEE Consumer Communications
and Networking Conference, (pp. 388-393).
Chen, J. L., Chang, Y. C., Lin, Y. S., & Du, H.
W. (2009). Embedded WiMAX-based Vehicular
Router for Telematics Computing. In The 11th
International Conference on Advanced Communication Technology, (pp. 1857-1862).
Choi, D. H., Ro, S. H., Lee, K. S., Lee, W. N.,
Choi, S. Y., & Pae, Y. W. (2006). Telematics Applications Based On TOPAZ Platform. In IEEE
6th International Conference on Computer and
Information Technology, (pp.262-268).
Introduction of Vehicular Network Applications
Choi, J. W., Han, W. Y., Kim, C. S., & Kwon, O.
C. (2005). Open Telematics Services Deployment
on the Gateway and Framework Independent on
Mobile Networks. In International Conference
on Wireless Networks, (pp.374-379).
Connexis website. (n.d.). Retrieved September
20, 2009, from http://www.connexis.com/
Devarapalli, V., Wakikawa, R., Petrescu, A., Thubert, P. (2005). Network Mobility (NEMO) Basic
Support Protocol RFC 3963.
Dikajakos, M. D., Florides, A., Nadeem, T., &
Iftode, L. (2008). Location-Aware Services over
Vehicular Ad-Hoc Networks using Car-to-Car
Communications. IEEE Journal on Selected
Areas in Communications, 25(8), 1590–1602.
doi:10.1109/JSAC.2007.071008
Emst, T. (2006). Network Mobility Support Goals
and Requirements.
Ernst, T., Uehara, K., & Mitsuya, K. (2003). Network Mobility from the InternetCAR Perspective.
In 17th International Conference on Advanced
Information Networking and Applications, (pp.
19–26).
FlexRay Communications System Protocol
Specification v2.1 Revision A, (2005). Gatespace
website. (n.d.). Retrieved September 20 2009, from
http://www.gatespacetelematics.com/
Gerlach, M., & Fokus, F. (2007). Trust for Vehicular Applications. In 8th International Symposium on Autonomous Decentralized Systems,
(pp. 295-304).
Grymek, L., Singh, S., & Pattipati, K. (2007).
Vehicular Dependence Adds to Telematics’ Allure. IEEE Potentials, 26(2), 12–16. doi:10.1109/
MP.2007.343053
Guo, J. H., & Xing, G. M. (2007). Using Mobile
Agent-based Middleware to Support Distributed
Coordination for Vehicle Telematics. In 21st International Conference on Advanced Information
Networking and Applications Workshops, (Vol.
2, pp.374-379).
Gura, N., Held, A., & Kaiser, J. (2001). Proactive
Services in a Distributed Traffic Telematics Application. Workshop on Mobile communication
over Wireless LAN: Research and Applications.
Retrieved from http://www.informatik.uni-ulm.
de/rs/projekte/core/
Han, W. Y., Kwon, O. C., Park, J. H., & Kang,
J. H. (2005). A Gateway and Framework for Interoperable Telematics Systems Independent on
Mobile Networks. ETRI Journal, 27(1), 106–109.
doi:10.4218/etrij.05.0204.0038
Internet, C. A. R. Project (2003). InternetCAR
webpage at WIDE. Retrieved September 20, 2009
from http://www.sfc.wide.ad.jp/InternetCAR
Kim, M. J., Choi, Y. J., Moon, Y. B., Kim, S. J., &
Kwon, O. C. (2006). Design and Implementation of
Status based Application Manager for Telematics.
IEEE 8th International Conference on Advanced
Communication Technology, (pp. 20-22).
Lee, S. W., Munson, J., Lee, D. R., Thompson,
G., & Park, J. (2005). A Rule-based System for
Sense-and-Respond Telematics Applications.
In The First Korea/Japan Joint Workshop on
Ubiquitous Computing & Networking Systems,
(pp 109-114).
Lee, W., Tak, Y., Byun, W. H., & Pae, Y. W. (2005).
Toward an Open Telematics Infrastructure. IPSJ
SIG Technical Reports, (pp. 443-448).
MOSQUITO Project. (2005). Mosquito Architecture. White Paper. Retrieved September 20, 2009
from http://www.mosquito-online.org/
29
Introduction of Vehicular Network Applications
Munson, J., Lee, S. W., Lee, D. R., Wood, D.,
Thompson, G., & Cole, A. (2005). A Rule-based
System for Sense-and-Respond Telematics
Services. Workshop on End-to-end, Sense-andRespond Systems, Applications and Services,
(pp. 31-36).
Next Generation Telematics Protocol website.
(n.d.). Retrieved September 20 2009, from http://
www.ngtp.org
Nolte, T., Hansson, H., & Bello, L. L. (2005).
Automotive Communication – Past, Current and
Future. In 10th IEEE Conference on Emerging
Technologies and Factory Automation, 1, 985992.
Nowey, K. P. T., & Mletzko, C. (2006). Towards
a Security Architecture for Vehicular ad hoc Networks. In First International Conference on Availability, Reliability and Security, (pp. 374-381).
O’Donnell, M. (2003). OSEK/VDX: Driving
the Standard for Optimized Embedded Systems.
Embedded Computing Design.
Open Service Gateway Initiative. (2003). OSGi
Specification Release 3. Retrieved September 20
2009, from http://www.osgi.org
OSEK Group (2004). OSEK/VDX Network Management Concept and Application Programming
Interface, Version 2.5.3.
OSEK Group (2004). OSEK Implementation
Language, Version 2.5.
OSEK Group (2005). OSEK/VDX Operation
System, Version 2.2.3.
Popescu, D., & Selisteanu, D. (2008). Web based
Telematics Application for Robotics. In the 3rd International Multi-Conference on Computing in the
Global Information Technology, (pp. 19-24).
Prosyst website. (n.d.). Retrieved September 20
2009, from http://www.prosyst.com/
30
Punnoose, J., Tseng, S., Wang, S., Nikitin, V.,
& Schlesinger, T. E. (2001). Communications
Resources Management for Advanced Telematics
Applications. Transportation Society Conference.
Rajkumar, R., Gagliardi, M., & Sha, L. (1995).
The Real-Time Publisher/Subscriber Inter-Process
Communication Model for Distributed Real-Time
Systems: Design and Implementation. Real-Time
Technology and Applications Symposium, (pp.
66–75).
Reilly, D., & Taleb-Bendiab, A. (2002). A ServiceBased Architecture for In-Vehicle Telematics
Systems. In the 22nd International Conference
on Distributed Computing Systems Workshops,
(pp.741-742).
Schilling, K. (2001). Virtual Laboratories for
Mobile Robots. IFAC Workshop on Internet Based
Control Education, (pp. 115-120).
Seo, S. H., Moon, T. Y., & Kim, J. H. (2007). Smart
Vehicle Management System by using Gateway,
Hand-set and VMP. International Conference on
Control, Automation and Systems, (pp.17-20).
Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor,
A., & Rayhan, A. (2002). Middlebox Communication Architecture and Framework. IETF Internet
Draft, retrieved September 20 2009 from http://
www.jdrosen.net/papers/rfc3303.txt
Sun, Y., Huang, W. L., Tang, S. M., Qiao, X., &
Wang, F. Y. (2007). Design of an OSEK/VDX
and OSGi-based Embedded Software Platform
for Vehicular Applications. IEEE International
Conference on Vehicular Electronics and Safety,
(pp. 1-6).
Sun Microsystems Inc. (1999, November). JINI
Specification v1.0.1. Retrieved from http//:www.
sun.com/JINI/
Introduction of Vehicular Network Applications
Sun Microsystems Inc. (2000). Java Media Framework API Guide, 2000. Retrieved from http://java.
sun.com/products/java-media/jmf/
Tseng, Y. C., Chen, J. J., & Cheng, Y. L. (2007).
Design and Implementation of a SIP-based Mobile and Vehicular Wireless Network with PUSH
Mechanism. IEEE Transactions on Vehicular
Technology, 56(6), 3408–3420. doi:10.1109/
TVT.2007.906986
Wang, F. Y., Li, J. X., & Liu, X. J. (2004). OSEK/
VDX and OSGi-based Embedded Platform for Vehicular Software and its Key Techniques. Chinese
High Technology Letters, (pp.131-136).
WirelessCar website (n.d.). Retrieved September
20 2009, from http://www.wirelesscar.com/
WTP1. 0 Specification (2004). Electronics and
Telecommunications Research Institute (ETRI),
Korea.
Zhang, D., Wang, X. H., & Hackbarth, K. (2004).
OSGi based Service Infrastructure for Context
Aware Automotive Telematics. IEEE 59th Vehicular Technology Conference, 5, 2957-2961.
Zheng, N. N., Tang, S., Cheng, H., Li, Q., Lai, G.,
& Wang, F. W. (2004). Toward Intelligent DriverAssistance and Safety Warning Systems. IEEE
Intelligent Systems, 19(2), 8–11. doi:10.1109/
MIS.2004.1274904
31
32
Chapter 3
Introduction to ITS and NTCIP
Da-Jie Lin
Feng Chia University, Taiwan, R.O.C.
Chyi-Ren Dow
Feng Chia University, Taiwan, R.O.C.
absTracT
Intelligent Transportation Systems (ITS) combines high technology and improvements in information systems, communication, sensors, and relevant mathematical methods with the conventional world of surface
transportation infrastructure to increase the capacity of transportation systems and to improve the level
of services. There are four major goals of ITS, including safety, environmental protection, efficiency, and
economy. NTCIP (NTCIP Standard 9001, 2002; DISA et al., 1997) is a set of communications protocols
and data definition standards designed for various needs of ITS services and applications. The key goals
of the NTCIP open-standards effort are interoperability and interchangeability. Interoperability refers
to the ability for multiple devices to work together as a single system and interchangeability refers to
the ability to use multiple brands of a device on the same communications channel. Accompanying the
social and economic development, traffic congestion and delay have become major issues in most areas
around the world. How to use readily available technologies to increase the capacity of transportation
systems and to improve the level of service has become one of major solutions to solve transportation
problems that people are facing. This is the motivation of Intelligent Transportation Systems development. NTCIP is a set of communications protocols and data definition standards designed for various
needs of ITS services and applications. These standards are intended to handle these needs in the two
areas: Center-to-Field (C2F) and Center-to-Center (C2C) communications.
DOI: 10.4018/978-1-60566-840-6.ch003
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Introduction to ITS and NTCIP
inTroducTion
Intelligent Transportation Systems (ITS) (ITS
Standard et al., 2006; ITE et al., 2003; RITA et
al., 2002) combines high technology and improvements in information systems, communication,
sensors, and relevant mathematical methods with
the conventional world of surface transportation
infrastructure.
definition of intelligent
Transportation systems
Intelligent Transportation Systems are defined
commonly as follow: systems utilizing newly
developed information and communications
technology to transportation infrastructure, management systems, and vehicles to improve safety,
efficiency, travel time and comforts and reduce
vehicle wear, delay, and fuel consumption.
Intelligent transportation systems include several systems using different technologies, such as
traffic signal control systems; vehicle allocation
and navigation systems; container management
systems; changeable message signs (CMS); automatic number plate recognition (ANPR) or law
enforcement equipments (speed cameras, CCTV,
surveillance cameras, ... etc.) to more advanced
applications such as traffic control centers that
integrate live data and feedback from a number
of sources, such as microwave/infrared vehicle
detectors, parking guidance and information
systems; weather information sensors, analyze
all information through different models and
then control the signal systems in the facilities
to improve the traffic condition.
of advanced communication, sensing, and information processing technologies. When integrated
into the transportation system’s infrastructure,
and into vehicles themselves, these technologies
relieve congestion, improve safety, and enhance
productivity.
Overall, the goal of ITS is to utilize advanced
technologies to increase the efficiency of limited
transportation resources, to increase user convenience and the living quality. The content of ITS
includes technologies and policies. The integration
of both technologies and policies and the application of the integration are the core of ITS.
There are four major goals of ITS: safety, environmental protection, efficiency, and economy.
The details of these major goals are listed in
Table 1.
A dedicated website, ITS Benefits, Costs
and Lessons Learned Databases (http://www.
benefitcost.its.dot.gov/) provides updated and
comprehensive information about the benefit and
cost of ITS. The benefit of ITS can be classified
in two application approaches: (1) Intelligent
Table 1. Major goals of ITS
Goals
Objectives
1. Safety
2. reduced incident damages
2. Environmental
Protection
1. less air pollution
2. less greenhouse effects
3. less noise
4. less fuel consumption
5.less new facilities & constructions
3. Efficiency
1. less travel time
2. increased capacity
goals and benefits of intelligent
Transportation systems
Intelligent transportation systems provide a set of
strategies for the transportation problems related
to safety and congestion, while accommodating
travel demands of users and freight through the use
1. reduced incident frequency
3. reduced operating costs
4. higher user satisfaction
4. Economy
1. increased industry production
2. more relevant job opportunities
(Source:Taiwan logistics management yearbook -Intelligent
Transportation Systems, 2001)
33
Introduction to ITS and NTCIP
Infrastructure and (2) Intelligent Vehicles. In
terms of infrastructure part, the benefit of ITS
includes better control in arterial and freeway
management, vehicle crash prevention and safety,
road weather management and warning systems,
transit systems in improved level of service, traffic incident management to reduce any incident
impacts, better emergency management, labor- and
error-free electronic payment and precise pricing,
readily available traveler information to reduce
user costs, ...etc.
On the other hand, intelligent vehicles increase
driving safety through new technologies such as
collision avoidance and driver assistances such
as car navigation systems and driver monitoring
systems.
subsystems of intelligent
Transportation systems
There are commonly discussed nine ITS subsystems that have their own functions and required
technologies. They work either jointly or independently, depending on the scenarios.
Advanced Traffic Management
Systems (ATMS)
Advanced Traffic Management Systems is the
core and foundation of Intelligent Transportation Systems. ATMS uses technologies such as
detecting, sensing, communications, and control
to collect the roadside data that will be transmitted
back to a traffic control center. Data from different
sources will be analyzed and traffic control center
will determine their control strategies based on
the result of analysis in order to systematically
optimize the whole network. The analysis results
will be used to control traffic (kight or signau) and
the analysis results will be relayed to the public.
ATMS increases the efficiency of transportation
networks as well.
ATMS emphasizes the integration with
other systems and real-time traffic data. Related
technologies and applications includes traffic
signal control, ramp control, automatic incident
detections, automatic vehicle locations (AVL),
changeable message signs (CMS), Geographic
Information Systems (GIS), Weigh-in-Motion
(WIM), Automatic Vehicle Classification (AVC),
Electronic Toll Collection (ETC), Automatic
Vehicle Identification (AVI), …etc.
Figure 1. Advanced traffic management systems (Source:ATMS)
34
Introduction to ITS and NTCIP
As shown in Figure 1 illustrates the interactions among control center, infrastructure, and
vehicles.
Advanced Traveler Information
Systems (ATIS)
Advanced Traveler Information Systems are
designed to provide users the information they
need to plan their trips. The factor considered in
trip planning consists of transportation modes,
costs, schedules, accessibilities, connecting transportation, etc.. ATIS utilizes the data collected
from different sources and processes these data
to make them available and understandable to
users. The platform the ATIS uses to deliver the
information to users includes TV at home, radio
in vehicles, changeable message sign (CMS) on
the roadside or in transit stations, internet (Feit
et al., 1993) (wired or wireless connection), cellular phones, etc.. Through this real-time, updated
travel information, the uncertainties in travel have
been greatly reduced and users have better control
of their time to increase their productivity (see
Figures 2 and 3).
Relevant applications and technologies include
Highway Advisory Radio (HAR), Global Positioning Systems (GPS) and Geographic Information
Systems (GIS), On Board Units (OBU), Wireless
communications, and Integrated Service Digital
Network (ISDN), etc..
Advanced Public Transportation
Systems (APTS)
Advanced Public Transportation Systems (APTS)
use the technologies of ATMS, ATIS and AVCSS
and apply them in the field of public transportation to improve the service quality, efficiency, and
attractiveness of existing public transportation
services such as buses or trains. Users, instead
of being delayed due to the uncertainty of the
transit systems, have better utilization of their
time. On the other hand, transit agencies have
a better control over their own fleet to improve
their management.
Figure 2. GPS navigation systems - to provide route guidance (Source: Japan ITS HANDBOOK 20062007)
35
Introduction to ITS and NTCIP
Figure 3. Changeable message sign (Source: http://www.flickr.com/photos/moogal/442796974/)
In the case of buses, dynamic bus information
systems, one APTS system for example, provide
passengers detailed information such as route
information, real-time bus location, estimated
bus arrival time, connecting information (other
bus routes or modes) so passengers can plan their
travel in a more efficient manner.
Related applications and technologies for
APTS include Automatic Vehicle Monitoring
(AVM), Automatic Vehicle Locating (AVL),
wireless communications, Electronic Fare Payment (EFP), bus scheduling systems, etc. See
Figure 4.
Advanced Vehicle Control and
Safety Systems (AVCSS)
Advanced Vehicle Control and Safety Systems
integrate technologies such as sensors, onboard
computers, communications, electronics, and
control to improve the vehicles and transportation facilities in terms of safety, capacity, and
level of service.
The advanced vehicle control and safety technologies have been deployed in vehicles to assist
drivers to improve their driving skills, to reduce
the likelihood of human errors and to increase the
safety, especially fatigue has been one of the major
36
reasons of transportation incidents. Increasing the
level of automation in driving will influentially
reduce the incident possibilities. For example, the
onboard driver monitoring systems will monitor
the physical condition of the driver when he is
executing his driving duty. Another example is
collision avoidance system that will work to slow
down the vehicle when it is too close to the vehicle
in the front and the driver is not responding to this
situation accordingly (Figures 5 and 6).
Related AVCSS technologies and applications
include automatic parking systems, collision
avoidance, communications between vehicle and
facility, driving behavior monitoring, human factor engineering, etc.
Commercial Vehicle Operations (CVO)
Commercial Vehicle Operations applies ATMS,
ATIS, and AVCSS technologies in the commercial
vehicle operations such as trucks, towing trucks,
taxies, paramedics, cranes, and other commercial
fleets. The onboard GPS provide the real-time
vehicle location information and wireless communication transmit the information back to
control centers or dispatching centers. This location information is an important input to a fleet
management system. After processing vehicle
Introduction to ITS and NTCIP
Figure 4. Dynamic bus information systems
Figure 5. Onboard monitoring devices (Source: The Intelligent Transportation Systems of future)
Figure 6. Driver monitoring systems (Source: The Intelligent Transportation Systems of future)
37
Introduction to ITS and NTCIP
location information, the fleet management system
can assign their commercial vehicles in a more
efficient way to improve their productivities.
Logistics companies, for example, see CVO
as a critical system: freight being handled will
be efficiently allocated in proper vehicles and be
precisely tracked once they are en route. CVO
enables them to reduce their costs while providing
better delivery services (Figure 7).
Related CVO technologies and applications
include Automatic Vehicle Monitoring (AVM),
Automatic Vehicle Locating (AVL), Weightin-Motion (WIM), Electronic Toll Collection
(ETC), Automatic Vehicle Identification (AVI)
and Automatic Cargo Identification (ACI), fleet
dispatching systems, etc.
Electronic Payment Systems (EPS)
Electronic Payment Systems or Electronic Toll
Collection (ETC) charges drivers/vehicles through
the communications between onboard units
(OBU) and roadside units. Conventionally tolls
are collected by hands and that requires vehicles
slowing down and preparing exact amount of fares
otherwise incidents or delays will be incurred.
On the contrary, EPS has the following features
Figure 7. Commercial vehicle operations
38
to make itself a better solution such as vehicle
no need to slow down, no incurred delays, lower
long-term operating cost, no need to handle cash,
and increased safety and facility utilization. See
Figure 8.
The other use of EPS is e-tickets for transit
systems such as buses, taxies, parking, and airlines.
If being combined with other payment systems
successfully, users only need to carry one card
to travel around without carrying a lot of cash or
waiting in a manual operation line.
Related EPS technologies include automatic
vehicle identification (AVI), microwave/infrared
Figure 8. EPS (ETC) in Taiwan
Introduction to ITS and NTCIP
sensing, Radio Frequency IDentification (RFID),
electronic money, etc. See Figure 9.
Emergency Management
Systems (EMS)
Emergency Management Systems is a system
designed for emergencies. If an emergency such
as a fire happened, EMS determines the dispatching and routing of fire trucks and ambulances,
and these vehicles will be given priority to go
to the scene. EMS utilizes the real-time traffic
data from control centers, determines the best
Figure 9. Automatic vehicle identification (Source:
CECI, Taiwan, 2007)
route with the minimum delays, and purposely
adjusts the traffic signals along the route. Other
agencies such as police will be notified as well
to assist the rescue actions. EMS also determines
the impact area and evacuates people within the
area if necessary (Figures 10 and 11).
Related EMS applications and technologies
consist of Automatic Vehicle Location (AVL),
Geographic Information Systems (GIS), automatic incident detection, Highway Advisory
Radio (HAR), etc.
Vulnerable Individual Protection
Systems (VIPS)
As shown in Figure 12, Vulnerable Individual
Protection Systems (VIPS) protects the safety
of handicaps, senior people, pedestrians, bikers,
motorcyclists, etc. For example, dedicated traffic
signals are designed for the blinds and handheld
navigation devices on a bicycle or motorcycle
that give warnings when a big truck is close from
the behind.
Related VIPS technologies include navigation
systems, voice-warning traffic signals, etc.
Figure 10. Automatic image detection system to identify incidents
39
Introduction to ITS and NTCIP
Figure 11. Automatic incident detection-tunnel fire (Source: CECI, Taiwan, 2007)
Figure 12. Vulnerable individual protection systems
Information Management
Systems (IMS)
As shown in Figure 13, Information Management
Systems is the backbone of the Intelligent Transportation Systems. IMS use all relevant information and communication technologies to collect,
transmit, archive, process, analyze and share data.
Data such as travel time, travel speed, vehicle
volume, travel origin-destination, ridership, vehicle location, etc. are further analyzed to become
usable information that will be delivered to users
40
and agencies and facilitate decision making. Users
use this information to plan their trips to increase
safety, efficiency, and reduce the travel time and/
or travel expenses. Agencies use this information
to better manage their vehicles, terminals and to
reduce the operating cost. Authorities use this
information to design, modify or fine-tune their
strategies, facilities to optimize the system performance. Without IMS, ITS designs, strategies,
approaches and subsystems cannot be realized to
the extent that they were designed to be.
Introduction to ITS and NTCIP
Figure 13. Traffic control center and IMS interface (Source: CECI, Taiwan, 2007)
Future development of intelligent
Transportation systems
After few decades’ efforts, ITS provides a lot of
benefits to users, agencies, authorities, and the
environment. There are still a lot of issues to be
solved and a lot of improvements to be made.
Along with the development of new advanced
technologies, ITS will provide us a better transportation environment that is also sustainable in
the long run.
nTcip
NTCIP is different from the past practice of transportation management protocols in that it is not a
single communications protocol designed for one
purpose. Rather, it is a whole family of protocols
covering from simple Point-to-Point protocols to
complicate objects oriented techniques. This is due
to several reasons: the diversity of the applications
where NTCIP will be deployed, the resulting diversity of application specific characteristics, such
as type and quantity of data to be transferred, the
criticality of data transfer times, acceptable cost of
communications infrastructure, and the criticality
of data security and integrity issues.
Interoperability and interchangeability are the
key goals of the NTCIP open-standards effort.
The term interoperability refers to the ability for
multiple devices, often of different types, to work
together as a single system for certain common
purposes. For example, using the same communications channel to interconnect a management
system with traffic signal controllers, dynamic
message signs, video surveillance controls, and
other devices. The terms interchangeability generally refers to the ability to use multiple brands of
a device on the same communications channel, as
well as the ability to swap them out. For example,
the ability to put any brand of NTCIP-compatible
traffic signal controller in the same system at the
same time.
41
Introduction to ITS and NTCIP
communications standards
for c2F and c2c
NTCIP provides two different types of ITS communications standards. The first type is between
an ITS management center and multiple control
or monitoring devices managed by that center.
Below are some examples of this type of communications:
•
•
•
•
A traffic signal management system communicating with signal controllers at
intersections;
A traffic management system controlling
dynamic message signs, advisory radio
transmitters, and environmental sensors on
roadways;
A transit management system communicating with passenger information signs on
transit vehicles and at transit stations and
stops;
A highway management system communicating with detectors and ramp meters.
This type of communication is called centerto-field, since most applications of this type
involve a computer system at a management
center communicating with various devices at
the roadside or on vehicles. Protocols intended
for these applications are often used in the environment where a central management station
routinely polls each field device, as in the most
common case of multiple field devices sharing a
communications channel.
The second type of communication involves
messages sent between two or more ITS management centers. Below are some examples of this
type of communications:
•
42
Two or more traffic signal management
centers exchanging information to achieve
coordinated operation of traffic signals
managed by the different centers and to
enable personnel at one center to monitor
•
•
•
the status of signals operated from another
center;
A transit system reporting schedule adherence exceptions, to a transit customer information system or to a traveler information
system, while also asking a traffic signal
management system to instruct its signals
to a behind-schedule transit vehicle;
An emergency management system reporting an incident to a highway management
system, to a traffic signal management system, and to a traveler information system;
and
A highway management system informing an emergency management system of
a warning message in response to its notification of an incident.
Such communication is called center-to-center,
although two or more of the systems may be located within the same location or building. C2C
involves peer-to-peer communications between
any number of systems in an interconnected network which is similar to the Internet where any
center can request information from, or provide
information to, any other centers. It is also possible to use such protocols for communication
to and between field devices, as well as between
computer systems.
Although both C2F and C2C communications can involve an operator making requests
or issuing instructions, one of the features of the
NTCIP protocols is their support for continuous
and automatic functionality using pre-defined
data transmissions.
3.2.1.1 Center-to-Field Protocols
NTCIP provides three application level protocols
for C2F communications: the Internet’s Simple
Network Management Protocol (SNMP) (IEEE
Std 828-1998, 1998; Feit et al., 1995; Stallings
et al., 1996), the Simple Transportation Management Protocol (STMP) and the Simple Fixed
Introduction to ITS and NTCIP
Message Protocol (SFMP), which is currently
under development.
•
•
•
Simple Network Management Protocol:
SNMP provides a simple, but bandwidthinefficient protocol for C2F applications,
based on the Internet protocol of the same
name (SNMP). It is suitable only for networks with high bandwidth, or low volumes
of messages. SNMP has been designed by
the Internet community to run over UDP/
IP, but it can be forced to run over TCP/IP
or T2/NULL.
Simple Transportation Management
Protocol: STMP was developed specifically for use in the transportation industry.
It is an extension of SNMP that allows C2F
messages to be sent more efficiently using
dynamic objects. Stacks based on this protocol are suitable for networks with low
bandwidth and high volumes of messages,
including such traffic signal systems where
a central computer is directly connected to
field devices, without the need to route the
information through some other devices
such as an on-street master in a closed loop
system. STMP has been designed to run
over T2/Null since it supports low bandwidth links, but could also be used over
UDP/IP or TCP/IP if there is sufficient
bandwidth.
Simple Fixed Message Protocol: There
is a need for having a bandwidth efficient
protocol for low-end field devices, like
closed circuit camera controllers. NTCIP
is currently developing SFMP to meet this
need.
These three protocols use the same get/set messaging paradigm as that used in SNMP. Although
with the same base data elements, they differ in
the level of complexity to implement and the types
of services. Table 2 summarizes the comparisons
among SNMP, STMP, and SFMP, while Figure
14 demonstrates the major advantages of these
protocols.
STMP is the most bandwidth efficient option
currently available and includes full support of
SNMP for infrequent messaging demands. It
includes SNMP as a subset, so that any management system that implements STMP can also
communicate with a device that supports SNMP. It
also requires the use of SNMP to define dynamic
objects. Infrequent messages requiring additional
security can be sent using SNMP. STMP is the
most flexible and bandwidth efficient option. The
advantage of STMP is its support for dynamic
objects which are combined with a more efficient
encoding scheme, dramatically reduce the packet
overhead relative to SNMP. Dynamic objects can
also enable the user to define custom messages
that are composed of any number of individual
data elements. However, these data elements will
have to be defined in both the center and the field
devices in order to work properly.
The field devices that use any particular
subnetwork protocol can share the same communications with other devices using the same
Table .2 SNMP, STMP and SFMP comparisons
SNMP
STMP
SFMP
Currently Under
Development
Ease of implementation
Easy
Hard
Message set
Support
Limited to 13
Supports routing and dial-up
Options
Options
Can send any base data element?
Yes
Yes
Bandwidth efficiency-inverse of packet overhead
Worst
Best
43
Introduction to ITS and NTCIP
Figure 14. C2F protocols
protocol. It does not matter whether such devices
are from different manufacturers or are totally different devices, e.g., a light signal and a dynamic
message sign. Each device is assigned an address
that is unique in that channel. The management
system can communicate with any of the devices
at any time by sending a message addressed to
that device. However, when using Point to MultiPoint Protocol (PMPP), the management system
can communicate with only one of the devices
on the channel at a time. As a function of SNMP
and STMP, devices can only send a message to
the management system when requested by the
management system. The NTCIP protocols enable
broadcast messages for all devices, and no devices
can reply to a broadcast message.
When planning a C2F communications network using NTCIP that involves continuous
polling of field devices, e.g., a traffic signal
system or transit fleet system, it is important to
consider the relationship between the following
key variables:
•
•
•
•
•
•
•
•
44
Transmission schemes.
Time between devices or between polling
cycles.
Transmission rate.
Frequency of communication.
Transmission delay.
Response delay in the field device.
Frequency of each type of message.
Length of message to be sent.
•
Number of devices sharing the same line
or channel.
The first seven of these variables will determine
the total time needed to communicate with each
device. Although STMP is designed for use with
communications channels that use a slow transmission rate, it is not as bandwidth-efficient as most
proprietary protocols used in the past. With existing communications infrastructure, it may not be
possible to maintain the same polling period with
the same number of devices per channel. This is due
to the fact that proprietary protocols are optimized
for each manufacturer’s equipment and consist
of very few fixed short messages without any
flexibility in terms of changing these messages,
while standard protocols are flexibly designed
to accommodate all needs and a wide variety of
information and messages in a multi-manufacturer
environment. However, careful design can usually find a reasonable compromise between the
principal variables. Higher available bandwidth,
bit rate, yields fewer compromises or required
trade-offs. If new communications infrastructure
can be provided, it will allow for additional channels and/or higher transmission rates.
Center-to-Center Protocols
NTCIP originally provided two application level
protocols for C2C communications, DATEX
(Data Exchange) and CORBA (Common Object
Requesting Broker Architecture), which were
found necessary to meet the variety of requirements for inter-system data exchanges. Recently,
there has been increased interest in using XML
and Web Service technologies for C2C links due
to its simplicity and the wide accessibility of tools
to provide these services. However, it is important
to determine where to deploy these protocols in
the network, with some centers acting as bridges,
or translators, among different protocols.
DATEX was designed to provide simple and
cost-effective solutions for the following needs:
Introduction to ITS and NTCIP
•
•
•
•
Systems requiring real: time, fast data
transfer;
Systems with limited communications
bandwidth but high data transfer load;
Systems with infrequent event driven exchanges over dial-up links; and
Non-object oriented systems.
DATEX provides a general-purpose C2C data
exchange protocol stack. It uses pre-defined messages transmitted by the base Internet protocols
(TCP/IP and UDP/IP) in a peer-to-peer network.
The base standard at the application level is an
ISO standard.
On the other hand, CORBA provides several
features to support networks connecting object
oriented systems, and assuming sufficient processing power and communications bandwidth
are provided. Object oriented software can take
full advantage of CORBA and implement it easily; this is much more difficult to achieve with
traditional procedural software.
CORBA is a general purpose C2C communications protocol based on the computing industry
standard of the same name. For object-oriented
systems, it enables a higher degree of integration
and some services not provided by DATEX, but it
may not be suitable for near real-time applications
and loosely coupled systems.
The wide availability of XML tools and large
market have generated the market interest in XML.
It is especially suited for systems requiring limited, simple data exchanges over communications
links with sufficient bandwidth and processors
with sufficient processing time available. However, there are no current transportation industry
standards for the use of XML. The NTCIP effort
continues to monitor the maturity of XML in an
effort to determine its suitability for future use in
the transportation industry.
C2C networks allow each system to request
available information from any other systems.
Each system can be configured to either accept
or reject certain requests. The data sent can either
be informational or can constitute a command to
take some actions. Consider a message sent from
one traffic signal system to another and containing a signal timing pattern number. In DATEX,
depending on the message type, it could represent
a command to implement that timing pattern at a
particular traffic signal or group of signals, or it
could represent a status report indicating that this
timing pattern was just implemented at a particular
traffic signal or group of signals.
The user can also establish standing subscriptions for data. In DATEX, these subscriptions can
specify that data be sent one-time-only, periodically, or repeatedly on occurrence of some event
as defined in the subscription. Each subscription
message has a corresponding publication message.
Unless the subscription is a one-time request, the
data will continue to be automatically published
repeatedly until the subscription is cancelled,
or until a predefined end date specified in the
subscription.
A system can use CORBA to automatically
discover data availability and shared control options available from other systems. These other
systems use the CORBA framework to publish
their capabilities and services offered, accept
registration requests from authorized clients, and
then deliver those capabilities and services to
those clients on demand. For example, a CORBA
traffic management system that owns a CCTV
can offer to provide: (1) the images acquired as
(a) snapshot, or (b) streaming video, and/or (2)
allow remote control movement of that CCTV.
The system owning the CCTV is the server and
the system asking for the images, and/or control
of the CCTV is the client. This example also
serves to illustrate a typical use of a subscription
such as “send me a new snapshot image from
CCTV every minute” stated in the proper terms
for that CORBA system- assuming the requester
is authorized that service, the expected result is
fairly obvious.
C2C communications require a peer-to-peer
network connection such as a local area network
45
Introduction to ITS and NTCIP
or a wide area network between the involved
centers. Local area networks typically use agencyowned twisted pair cable or fiber optic cable.
Wide area networks typically use commercial
telecommunications links such as frame-relay,
fractional T1 leased lines, packet radio, leased
“virtual private networks”, ISDN, or similar modems over “plain-old telephone” lines. Any type
of communication link can be used, as long as it
enables use of the Internet transport and routing
protocols (TCP/IP and UDP/IP) and has sufficient
bandwidth for the planned communications load
to achieve the desired operational performance
(this is based upon frequency, size of messages
to be exchanged, and latency issues encountered
when using C2C systems).
For DATEX and CORBA, the base protocols
have been defined, that is, how to exchange
data, but the standards defining the data to be
exchanged have not reached a state of maturity.
The XML approach is even less mature in that
the industry has not agreed on the exact rules on
how to exchange the XML documents. Any recent
Figure 15. NTCIP and the ITS architecture
46
deployment should consider the impacts that this
may have on the long-term maintainability of a
system. The best solution is still likely to deploy
one of the recognized standards, but the agency
should realize that a future project would likely
be required to upgrade the software to address any
included features affected by revisions in order
to achieve the final mature standard.
The role of nTcip in the
iTs architecture
NTCIP defines a family of general-purpose communications protocols and transportation specific
data dictionaries/message sets (IEEE Std 14881999, 2000; IEEE Std 1489- 1999, 1999; IEEE
Std 1512-2000, 2000) that support most types of
computer systems and field devices used in transportation management. Applications for NTCIP
are generally divided into two categories: C2F and
C2C. The former, normally involves devices at
the roadside, communicating with management
software on a central computer.
Introduction to ITS and NTCIP
C2C applications usually involve computer-tocomputer communications where the computers
can be in the same room, in management centers
operated by adjacent agencies, or across the
country. The role of NTCIP in the National ITS
Architecture is illustrated in Figure 15.
For both C2F and C2C applications, NTCIP
supports systems and devices used in traffic, transit, emergency management, traveler information
and planning/data archiving systems. Figure 16
illustrates how various transportation management systems and devices can be integrated using
NTCIP.
The following are examples of systems and
devices that can take advantage of NTCIP:
•
Center-to-Field
◦
Traffic signals
◦
Dynamic message signs
◦
On-board sensors and controllers
◦
Environmental sensors
◦
Ramp meters
•
◦
Vehicle detectors
◦
Highway lighting control
Center-to-Center
◦
Traffic management
◦
Transit management
◦
Incident management
◦
Emergency management
◦
Parking management
◦
Traveler information
◦
Commercial vehicle operations
regulation
Many applications of NTCIP are related to
real-time communications and involve continuous transmissions of data or commands while
historical data can be sent using NTCIP, other
communication standards, especially e-mail and
file transfer protocols developed for the Internet,
may also be used. Human-to-human communications are generally better served by fax/telephone
and Internet protocols, but basic support is also
provided in the NTCIP C2C protocols.
Figure 16. Example of ITS integration using NTCIP
47
Introduction to ITS and NTCIP
The nTcip Framework
When options are available with layered protocols,
the options can be diagramed in a “framework.”
Figure 17 illustrates the framework for NTCIP. The
diagram shows the different protocols that can be
chosen at each level and which ones are compatible. However, not all compatible configurations
make sense, and there are mutually exclusive
choices. A particular message transmission can
use at least one protocol from each level of the
NTCIP framework. The series of protocols used
in the message transmission is called a “protocol
stack.” It is possible for a pair of electronic devices
to exchange some messages using one stack and
other messages using a different stack, though
usually, such stacks will differ only at one or
two levels or sublevels. As shown in Figure 17,
the lines connecting standards at different levels
show optional standards at each level. If there is
a continuous line from one standard to another,
then they are compatible and can be used together
Figure 17. NTCIP standards frameworks
48
as part of a protocol stack. There is also another
way to classify the NTCIP standards: primary,
supporting, and base standards protocols.
•
•
A primary standard applies directly and
specifically to the device or component
subsystem being implemented. For example, standards 1203 and 1204 are primary
NTCIP standards and the Standard 1203
applies specifically to DMS, and 1204 to
ESS.
A supporting standard applies in general
to more than one device or component
subsystem implementation. For example,
the NTCIP Standard 1201 Global Objects
standard applies to all devices and component subsystem implementations that use
or require features such as identification
and location of equipment, global time,
and event detection or scheduling. Thus,
standard like Standard 1201 is a supporting standard. Both primary and supporting
Introduction to ITS and NTCIP
•
standards typically apply at the C2F or
C2C information layer (Figure 17).
A base standard and protocol applies to the
Application, Transport and Sub-network
levels. These standards define NTCIP
unique capabilities for protocol and data
transport choices to complete the design
of an operational deployment. These standards is different from both primary and
supporting standards, since the data being
exchanged is irrelevant. These standards
are unaware and largely unaffected by
their use in a signal control, DMS, and ESS
applications.
When deploying an NTCIP-based system,
protocols have to be chosen. Figure 18 illustrates
an example if C2F protocols stack choice that
can be defined using NTCIP standards. A stack
is a subset of the overall NTCIP framework-a selected route through the levels, given the choices
available. Some stacks include two standards at
some levels, which usually mean the protocol
can use either of the optional standards. NTCIP
protocols generally offer further options within
most of the standards. Examples of sub-options
within a standard are: which subset of messages
are supported, or which bit rate is used at the
physical interface.
nTcip communication levels
NTCIP uses a layered approach to communications
standards, similar to the layering approach adopted
by the Internet and the International Organization
of Standards (ISO). In general, data communications between two computer systems or other
electronic devices can be considered to involve
the following primary layers, called “levels” in
NTCIP, to distinguish them from those defined
by ISO and the Internet. The NTCIP standards
publication numbers are grouped in number ranges
to indicate the standard type and the level where
the standard goes.
•
Information level: This level contains
standards for the data elements, objects
and messages to be transmitted, e.g., TCIP,
Figure 18. Example center-to-field stack
49
Introduction to ITS and NTCIP
•
•
•
•
NTCIP 1200 series Standards Publications,
MS/ETMCC.
Application level: This level contains
standards for the data packet structure and
session management, e.g., SNMP, STMP,
DATEX-ASN, CORBA, FTP.
Transport level: This level contains standards for data flow control, packet reassembly and routing when needed, e.g.,
TCP, UDP, IP.
Subnetwork level: This level contains
standards for the physical interface, e.g.,
modem, CSU/DSU, and the data frame
encapsulation method, e.g., HDLC, PPP,
Ethernet, ATM.
Plant level: This level consists of the
physical transmission media used for communications, e.g., twisted pair copper wire,
coaxial cable, fiber optic cable, wireless. It
should be noted that the plant level is an
infrastructure choice and not a standards
selection choice. However, the plant level
selection will have an impact on the subnetwork level selection to which it must
interface.
Information level standards used in ITS are
unique to the transportation industry. The National
ITS Architecture and much of the standards development effort for ITS involve identification of
required data elements and the definition of their
use for all the different domains and functions
within ITS, e.g., traffic, transit, traveler information, emergency management. At the Application,
Transport and Subnetwork levels, ITS can frequently use existing standards used by the broader
computer and telecommunications industries.
Below the Information level, the NTCIP standards
deal with choosing which existing standards are to
be used in ITS. The Internet standards have been
adopted where possible. The NTCIP standards
specify which options to use where alternatives
are available in some standards. NTCIP has not
had to develop significantly new standards in
50
these areas. The two major exceptions are the
protocols that support:
•
•
•
•
•
Slow speed, high frequency communications links as found in 1200 bps, once-persecond traffic signal systems.
A simplified Publish-Subscribe C2C
protocol.
NTCIP has extended existing standards or
developed entirely new protocols as needed in cases where ITS has special protocol
requirements. The two areas include:
Continuous, automated, real-time exchange
of large volumes of small data packets in a
many-to-many multi-agency network.
Continuous high volumes of real: time data
sent to and from embedded processors in
roadside or on-vehicle equipment sharing
the same, low-speed, data channel and requiring low latency.
Through a layered combination of existing
communications standards and a few new standards developed specifically for ITS, NTCIP
provides a family of communications protocols
that serve many of the common needs in ITS
transportation management.
The levels shown in the framework are somewhat different from communication stack layers
defined by the ISO’s Open Systems Interconnect
seven-layer reference model and other standards
developing organizations. The NTCIP stack
extends beyond the communications stack to
include informational data and interfaces to the
actual communications infrastructure. The levels
and terminology used in NTCIP were chosen for
simplicity and ease of understanding by readers,
and related to typical applications in the transportation industry.
With the many diverse requirements of NTCIP,
it is not surprising that we looked at the ISO OSI
Reference model to help us define the framework
for the new family of standards. Although OSI
communications protocols are not widely used, the
Introduction to ITS and NTCIP
Figure 19. Level mapping of OSI layer to NTCIP level mapping
layered model remains. The OSI model breaks the
communications process into seven well-defined
layers. Each layer has a defined purpose, generally
independent of adjacent layers. Figure 19 shows
how the NTCIP Information, Application, Transport, Subnetwork and Plant Levels loosely relate
to the OSI model and are described as follows:
•
•
NTCIP information level: This level defines the meaning of data and messages
and generally deal with ITS information.
This is similar to defining a dictionary and
phrase list within a language. These standards are above the traditional OSI sevenlayer model. Information level statndards
represent the functionality of the system to
be implemented.
NTCIP application level: This level
defines the rules and procedures for exchanging information data. The rules may
include definitions of proper grammar and
syntax of a single statement, as well as the
sequence of allowed statements. This is
similar to combining words and phrases to
form a sentence, or a complete thought, and
•
•
defining the rules for greeting each other
and exchanging information. These standards are equal to the Session, Presentation
and Application Layers of the OSI model.
NTCIP transport level: This level defines
the rules and procedures for exchanging
the Application data between source and
destination on a network, including any
necessary routing, message disassembly/
re-assembly and network management
functions (Buede et al., 2000). This is
similar to the rules and procedures used by
the telephone company to connect two remotely located telephones. Transportation
level standards are roughly equivalent to
the Transport and Network Layers of the
OSI model.
NTCIP subnetwork level: This level defines the rules and procedures for exchanging data between two devices over some
communications media. This is equivalent
to the rules used by the telephone company
to exchange data over a cellular link versus the rules used to exchange data over a
twisted pair copper wire. These standards
51
Introduction to ITS and NTCIP
•
are roughly equivalent to the Data Link
and Physical Layers of the OSI model.
NTCIP plant level: This level is used to
provide a point of reference to those learning about NTCIP. The Plant level includes
the communications infrastructure over
which NTCIP communications standards
are to be used and will have a direct impact on the selection of an appropriate
Subnetwork Level for use over the selected communications infrastructure. The
NTCIP standards do not prescribe any one
media type over another. To ensure a working system, deployers must specify and/or
select an NTCIP protocol or profile at each
level.
Most of the standards in the lower levels are
existing commercially available standards used
in the telecommunications industry and were not
developed uniquely by NTCIP, although NTCIP
often specifies which sub-options within those
standards are to be used. The majority of standards
unique to Intelligent Transportation Systems are
found in the Information Level and Application
Level shown at the top of Figure 17 and Figure 18.
Each NTCIP protocol stack involves a mixture of
standards, with at least one from each level.
major protocols in nTcip
protocol stacks
The first NTCIP standards developed were those
intended for C2F applications. This involved
a new application level standard called Simple
Transportation Management Protocol, a new
transport level standard called the Transportation
Transport Profile (T2 or T2/NULL), and several
sets of new standard data elements (Michael et al.,
2004; IEEE Std 1489-1999, 1999) called “object
definitions” at the information level. The initial
NTCIP C2F protocol development also involved
references to three existing standards:
52
•
•
•
Point-to-Point Protocol (PPP)
A customization of the High-level Data
Link Control (HDLC) standard at the
subnetwork level, known as the Point-toMultiPoint Protocol and
SNMP standard at the application level.
Each standard specifies one or more protocols
to be used at a given level, and the suboptions allowed or required within each of those standards.
A standard publication will typically reference one
or more “normative standard” publications-other
publications that contain additional relevant specifications for the standard(s). A referred normative
standard may be another NTCIP publication, if the
standard was developed by NTCIP, or a publication developed by any other standards development organization. For a particular application of
NTCIP, the user must select, in the procurement
specifications, which elements are desired at each
level. e.g., select from the options called out in one
or more profile publications for each level. The
set of selections and options for base standards
and protocols for all levels is referred to here as
a “protocol stack.” Each NTCIP protocol stack
will have different characteristics, and a stack that
works well for one application or communications
environment may not suit another.
Application level standards that NTCIP has
defined are briefly described below. As pointed
out in Fig. 3.17 and 3.18, these application profiles
can be combined with certain transport profiles.
Two electronic devices will be better able to
communicate interchangeably with each other, if
they use the same communications protocol stack,
the same information level data dictionaries and
message sets, and implement the same desired
options defined in each of these selected primary,
supporting, and base standards and protocols.
In addition to specifying a protocol stack,
the system designer must also choose between
various options and alternatives available in the
selected stack. These options exist in both C2C
and C2F protocol stacks. Major options, such as
Introduction to ITS and NTCIP
which protocols to support at each level in the
communications stack, are sometimes grouped
according to conformance levels, while others
are individually selectable. Most manufacturers
and system suppliers typically offer features that
go beyond the standard. To make use of such
features, it is necessary to specify the inclusion of
manufacturer-specific data elements or messages
as extensions of the standards when procuring a
management system.
The decision by an agency to use features
above and beyond the standard should be taken
only with the understanding of the potential impacts. These impacts could be considerable in the
long term. These options may, in effect, result in
the purchase of proprietary systems. Part of the
decision must include how many of these features
that will be allowed.
migration from legacy
systems to nTcip
Since interoperability and interchangeability are
two key goads of NTCIP, the inability to update
older equipment should never stop an agency
from replacement or migration strategies to make
full use the benefits of NTCIP conformant implementations. For example, a central system whose
current field devices cannot be updated could be
expanded to run NTCIP protocols on some communications channels while the older equipment
is maintained on others.
There is a model for a three-step migration
from legacy systems to NTCIP. Initially, the
proprietary interface details may or may not be
known. Then, there is some intermediate state
and some period of time where the operational
system consists of a mixture of the legacy systems
and the newer NTCIP hardware. There may be
a common communications channel for legacy
and NTCIP devices. The central control system
may be separate or combined; it may run on the
same computer or on separate computers: this is
determined by the scope of the project to accom-
plish these migration steps. Pursuit of a migration
strategy towards the use of open standards starts to
minimize the use of proprietary communications
and begins to maximize the use of NTCIP. Finally,
at some future point, the migration is completed
and NTCIP is fully deployed, having replaced all
now retired legacy systems.
NTCIP and non-NTCIP devices may be mixed
on the same channel. Thus, all devices sharing
a channel must be upgraded simultaneously. A
center that communicates with both NTCIP and
non- NTCIP devices will need to use a different
communications port for NTCIP devices and for
non-NTCIP devices, and will need to support both
protocols. Therefore, the mixed devices listening
on the shared communications channels must
recognize and react only to those data elements
and commands intended for them individually, and
must also not produce unpredictable results in response to any other data traffic on the channel.
For example, the most likely and simplest solution in the traditional closed-loop traffic signal
systems is to limit each field master to one protocol. Only field masters with NTCIP-compatible
controllers would be upgraded to support NTCIP.
This avoids the need for field masters to simultaneously support two protocols on two separate
ports. The center could communicate with field
masters using a different protocol than that used by
the field master to communicate with controllers.
As with the controllers and the field master, the
center’s software will need to be modified to add
support for an NTCIP protocol, if NTCIP is to be
used for communications with field masters.
Any upgrade of an existing system to add support for NTCIP should be designed in consultation
with the system provider. Each provider should
adopt an upgrade or migration strategy that is
most efficient for the majority of its customers. If a customer wants a unique arrangement,
that customer may have to pay the full cost of
the software modifications, whereas the cost of
the general solution can be spread among many
customers. One approach to the introduction of
53
Introduction to ITS and NTCIP
NTCIP in a C2F system is to operate NTCIP and
non-NTCIP systems during a transition period.
Field devices can gradually be switched over
from one to the other as they are replaced or their
software is upgraded. If the current system is quite
old and upgrading it for NTCIP is not practical,
this transition should be done as part of a general
system upgrade.
nTcip implementation examples
As shown in Figure 20, NTCIP have been deployed across U.S.A in several states. The initial
deployment of NTCIP-conformant equipments
was conducted by the Virginia Department of
Transportation (VDOT), USA in a case study of
their Variable Message Sign implementation in
NTCIP-9002 Version 01.04, in September, 1999.
AASHTO, FHWA, ITE and NEMA are currently
sponsoring this case study update. This effort,
presented as a case study amendment, focuses
on insights gained over the three years of deployment since the initial case study was performed.
Figure 20. NTCIP projects in U.S.A.
54
Specifically, this amendment will address Agency
issues concerning current implementation efforts
and their needs based upon experience gained
through NTCIP deployment experience.
The Washington State Department of Transportation (WSDOT), USA implemented a Variable Message Sign (VMS) system in 1999. The
formal name of this project is the “NTCIP VMS
Software Upgrade.” The purpose of the project
was to modify the existing traffic management
system to support selected protocols from the
NTCIP protocols and to purchase two new NTCIP
compliant variable message signs. The vendor
was American Electronic Sign Co (AES). Additionally, the AGENCY hired a programming
contractor (PROGRAMMER) to enhance the
central system software.
The City of Phoenix, Arizona, USA initiated
a project to enhance their traffic signal system as
shown in Figure 20. This project included two
distinct parts, the replacement of the central traffic
control system, and the upgrade and purchase of
additional traffic signal controllers. The NTCIP
Introduction to ITS and NTCIP
was specified as the communications protocol of
choice for both. The central system, called Phoenix ATMS was also required to control additional
field devices, however, without the requirement to
utilize the NTCIP communications protocol.
The City of Lakewood, Colorado, USA initiated a project to enhance its traffic signal system.
This project included two distinct parts, the replacement of the central traffic control system,
and the upgrade and purchase of additional traffic
signal controllers. The NTCIP was specified as the
communications protocol of choice for both. The
central system, called Lakewood ATMS was also
required to be extensible in order to add future
capabilities for controlling field devices such as
NTCIP Dynamic Message Signs and non-NTCIP
closed circuit television cameras.
The City of Mesa, AZ initiated a Request for
Proposal to upgrade their existing SONEX system, which included a requirement for NTCIP,
i.e., “Support NTCIP for communication to TS-2
controllers”. However, the proposed cost was
so much higher than estimated, that the Agency
withdrew the RFP. In 1997, the Agency again
issued a Request for Proposal, this time requesting to replace the entire signal system including
the central system and the signal controllers. A
phased approach was to be used running temporary
parallel central systems. The NTCIP was specified as the communications protocol of choice
for the new components. The central system,
called Mesa ATMS was also required to control
additional field devices and provide an interface
to the SYNCHRO software.
In England, a project, called UTMC (Urban
Traffic Management and Control) had been
implemented and evaluated. However, the NTCIP
definition cannot support the England metropolis
area at present the material transmission demand.
If NTCIP is applied to the European area, the MIB
file must be revised or established to conform
to the application demands of the England area.
UTMC indentified that SNMP communications
produce serious overhead problem. Instead of
using SNMP, the STMP communication is suggested to be used in England.
reFerences
Buede, D. M. (2000). The engineering and design
of systems: Models and methods. New York:
Wiley, Inc.
Feit, S. (1993). TCP/IP: Architecture, protocols
and implementation. New York: McGraw Hill,
Inc.
Feit, S. (1995). SNMP: A guide to network management. New York: McGraw Hill, Inc.
Institute of Transportation Engineers Management and Operations of Intelligent Transportation
Systems. (2003). ITS standards overview.
Internet Librarian, D. I. S. A. (1997). US-DOD
Internet related standardized profiles. Retrieved
from http://www-library .itsi.disa.mil/
Michael, A. (2004). Guide to the IEEE 1512
family of standards. Washington, DC: Institute
of Electrical & Electronics Engineer.
Research and Innovative Technology Administration (RITA) & U.S. Department of Transportation.
(US DOT). (2002). National ITS architecture.
Retrieved from http://itsarch.iteris.com/itsarch/
Stallings, W. (1996). SNMP, SNMPv2 and RMON.
Reading, MA: Addison-Wesley Publishing Company, Inc.f
NTCIP Standard 9001. (2002). The NTCIP
guide.
ITS Standards Outreach, Education and Training
Program, Institute of Transportation Engineers.
(2006). Center to center communications.
IEEE Std 828-1998. (1998). IEEE standard for
software configuration management plans.
55
Introduction to ITS and NTCIP
IEEE Std 1489-1999. (1999). IEEE standard for
data dictionaries for intelligent transportation
systems.
IEEE Std 1488-1999. (2000). IEEE standard for
message set template for intelligent transportation systems.
56
IEEE Std 1512-2000. (2000). IEEE common
incident management message sets for use by
emergency management centers.
Section 2
Embedded System Architecture
and Communication Protocols
58
Chapter 4
Vehicular Embedded
System Architecture
Chung-Ping Young
National Cheng Kung University, Taiwan, R.O.C.
absTracT
The dramatic advancement of IC technologies makes electronic devices be smaller and run faster, so
they are able to implement more functions in a limited space. The car electronics play an increasingly
important role in automobile industry, and the embedded system has already been extensively employed
for improving the operation and performance of vehicles, such as safety, comfort, convenience, and
energy consumption. In terms of electronic system, an automobile is a distributed embedded system,
and the control messages to each electronic control unit (ECU), go through in-vehicle networks. An
ECU is a computing system, integrated with a data acquisition module or an electromechanical driver.
A variety of ECUs implement versatile functions, such as powertrain, antilock braking system (ABS),
traction control system (TCS), adaptive cruise control (ACC), and electronic stability program (ESP),
etc. Sensors provide measurements of specific vehicle parameters in a format suitable for the digital
microcontroller, while actuators are electrically operated devices that drive electromechanical components. Human machine interface is the input and output of vehicle operations to users.
inTroducTion
Transportation of humans and objects have been
playing an important role in our daily lives since
civilization first formed and needed new means of
reaching destinations. The invention of efficient
transportation greatly reduced the time and labor
once required and in addition largely extended
the living environment that people can reach. The
more time and labor for transportation is saved, the
more leisure time people will have. Animal-power
or natural resources have been the driving force
of transportation for a long time. After the steam
engine was invented, the automobile started a new
era. The mass production of the Ford model T cre-
DOI: 10.4018/978-1-60566-840-6.ch004
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Vehicular Embedded System Architecture
ated the modern automobile industry and made
the automobile more affordable.
The basic structure of the automobile has not
changed much, but evolving technologies has kept
improving its functions and performance. The construction of traffic networks and mass production
of automobiles have made the automobile the most
important land based transportation carrier. The
usage of automobiles is usually associated with
the growth of economy and industry of a nation,
so the population ratio that owns automobiles in a
developed country is larger than that in a developing country. When the economy grows, vehicle
as a transportation tool becomes more affordable
and popular, for instance China or India. When
people use automobiles in their daily lives, they
demand not only mobility, but also safety, comfort
and convenience. These are some design factors
that manufacturers have to put into aspect when
enhancing functions by introducing and developing new technologies.
For a government to provide a modern transportation system, it has to build not only a traffic
network, but also an infrastructure to access more
information to allow drivers and passengers to
drive safer, more comfortably and with better
convenience on the road. This is the vision of an
intelligent transportation system. To achieve this
goal, both the infrastructure and vehicles have
to be facilitated with a modern electronic and
information system.
The evolution of an automobile shows more
signs of adopting electronic devices. To enhance
the features or performance, some mechanical
components are replaced by wires and electronic
devices, or simple electronic devices are enhanced
by complex electronic control systems. An automobile consists of several control systems: power
train, chassis, safety, body and information. Each
system may have several subsystems distributed in
different location of a car and are linked through
in-vehicle networks.
Since most modern electronic devices digitize
signals and process them by software, embedded
systems are employed for data processing and
control in an automobile. The dramatic advancement of IC technology, which is described by
Moore’s law, makes chips smaller, faster, and
able to implement more functions. In terms of
electronic systems, an automobile is a distributed
embedded system, and the control messages to
each distributed device go through the in-vehicle
network. X-by-wire is becoming a new technical
trend.
From a top-down viewpoint, the ultimate
goal of transportation is to develop an intelligent
transportation system. The basic mobile unit is a
vehicle, which is interconnected to other vehicles
or backend service providers through vehicle-tovehicle or vehicle-to-infrastructure communications. The scope of this chapter is limited to the
distributed embedded systems in a vehicle.
A vehicle consists of a variety of electronic
control units interconnected through an in-vehicle
network, while each unit is an embedded system
involving processor and memory along with other
optional sensors, actuators, storage devices or
human machine interface.
saFeTy, comForT and
conVenience
Vehicles were developed for transportation.
When vehicles become mandatory transportation tools in daily life, safety is the first issue.
Road safety is related to the loss of human life
and property and can be categorized into three
areas: human, environment, and vehicle. Human
and environment factors are out of the scope, and
we will focus only on the vehicle. However, the
enhancement for vehicle safety can sometimes
compensate the inappropriate operation caused by
human or environmental factors. Vehicle safety
can be further separated into active safety and
passive safety (Robert Bosch, 2006). The active
safety mechanism is to prevent the happening
of potential accidents, while passive safety is to
59
Vehicular Embedded System Architecture
help drivers and passengers lower injury or death
rates by accidents. Figure 1 shows the different
categories of road safety, and goals for active
safety and passive safety.
Active safety systems, including antilock braking system (ABS), traction control system, and
electronic stability program, enhance the stability and steerability of driving so that corrections
or reductions toward inappropriate operations
caused by humans or the environment can be
made, therefore improving road safety. Adaptive cruise control not only provides the safety
function of maintaining safe headway with the
preceding vehicle, but also relieves the drivers
need to frequently check the speed.
A car accident happens through three phases:
pre-crash, in-crash and post-crash stages. To
prevent the happening of a tragedy, the safety
mechanism must successfully work before the
pre-crash stage. The active safety provides safe
and convenient drivability to reduce accidents,
and the passive safety provides pre-triggering
to the protection device for the impact and postcrash communications. Figure 2 presents three
Figure 1. Road safety categories
60
crash stages and the active/passive safety related
safety mechanism.
The lifetime of market penetration of one automotive system usually begins with an innovative
technology applied to a high-end model vehicle.
Later on this technology is recognized as a major
improvement to environment or safety and required by law, or recognized as a mandatory feature
by the customer. This product then becomes the
standard equipment in all car classes. Seat belts,
airbags, and tire pressure detection are regulated
by legislation to be equipped on a vehicle, while
blind spot detection and adaptive front lighting
are trying to be regulated in Europe.
The comfort and convenience are not as critical as safety for evaluating a vehicle. To provide
a joyful and easy driving environment, there are
important design factors to be considered when
increasing the quality of driving and riding. Sometimes, some features of comfort and convenience
are also correlated with safety improvements. For
example, blind-spot warning produces a visual/
audible signal to notify the driver of potential
dangers: a car approaching in the blind-spot area.
Vehicular Embedded System Architecture
Figure 2. Active and passive safety in different crash stages
The driver can concentrate on the front view of
the forward direction, but not be distracted by the
vehicle on either side.
neTworked embedded sysTems
overview
To fulfill a variety of functions in a vehicle, each
electronic control unit (ECU) independently
implements its designated function. The automotive system is constructed as a server-client
architecture. ECUs can be treated as a peripheral
device of the central console, and the digital data
are communicated via the in-vehicle network. The
central console sends the command to ECU and the
ECU sends the status back to central console.
A vehicle can be categorized by the following
systems on vehicular network: powertrain, chassis,
safety, body, central console, and infotainment.
Figure 3 shows that all vehicle electronic control modules are networked through in-vehicle
network.
powertrain
The powertrain system consists of engine control,
automatic transmissions, traction control system
(TCS) and an adaptive cruise control (ACC). The
engine control is to gain higher engine power at
a lower system cost level, while also offering
improved fuel efficiency and reduced exhaust
Figure 3. Networked vehicle electronic control modules
61
Vehicular Embedded System Architecture
emissions. Transmissions convert the torque
generated by the engine and the engine speed
corresponding to the tractive force requirement.
The automatic transmissions automatically take
on control of starting, selecting the gear ratios and
switching gears. The TCS prevents the wheels
from spinning by reducing the drive torque at
each driven wheel. The ACC system maintains the
constant speed set by the driver, and will reduce
the speed to follow a slower vehicle. It speeds up
by electronically accelerating up to the setting via
the engine management system or decelerates by
electronically activating the brake system.
chassis
Chassis systems enhance vehicle stability and
steerability. Electronic stability program (ESP)
improves vehicle handling and braking response
through programmed intervention in the braking
system and/or powertrain. It integrates both ABS,
preventing from wheel locking when brakes are
applied; and TCS, preventing from wheel spinning when acceleration is applied. The suspension
adjustments compensate the rise and fall of wheels
on cornering or road irregularities to optimize
vehicle stability.
safety
When the automotive system senses an impact,
the passive safety systems activate. Front or side
airbags are triggered and fully inflated in about 40
ms and vehicle occupant detection system drives
the seat belt pretensioner to function in restraining
the occupants in their seats. The ABS prevents
the wheels from locking up when the brakes are
applied by lowering the wheel brake pressures.
body and comfort control
Body and comfort control systems provide occupants convenience and comfort features, such
62
as power windows, power sliding/rear doors, door
lock, wiper, ventilation, heater, air-conditioning,
room lamp, and adaptive front lighting.
central console
Central console is the user interface to the automotive system. It involves dashboard projection of
the vehicle status and button/knob to control the
operation and setting. A concept central console
will have only a graphical LCD display with
touch screen panel integrated. The communication between the central console and other ECUs
relies on the in-vehicle network, such as CAN/
LIN, FlexRay, and MOST (Paret, 2007).
infotainment
Infotainment system provides the contents of
information and entertainment to occupants. Entertainment involves audio, video, radio, digital
TV, or gaming. The infotainment contents can
be retrieved from local mass storage devices or
via radio, mobile communication, or wireless
network to remote service/content providers. The
navigation system provides location awareness
and route planning functions by utilizing multiple
xGPS systems.
X-by-wire
Since each ECU is located separately and connected through in-vehicle networking, the control of an electromechanical device is not by the
conventional mechanical parts, but by the digital
control message on the bus. X-by-wire implies
that the operation on a vehicle is implemented
through electrical wires, where x could be any
operation that you name. This reduces the cost and
space for mechanical parts, and the automotive
system appears as a mobile vehicular network.
Some examples of x-by-wire are steer-by-wire
and brake-by-wire (Paret, 2007).
Vehicular Embedded System Architecture
elecTronic conTrol uniT
overview
During the technical evolution of automobile
development, the relatively straightforward
electromechanical operations in a vehicle cannot
fulfill the complex safety or comfort requirements
in a modern vehicle. The electronic devices have
become more popular in the 1960s, since the dawn
of the semiconductor era. The computing systems
brought signal processing to a brand new digital
world and then enhanced the system control.
Because of the advancement of semiconductor
technology, the market pushed the automotive
systems to a more precise and complicated control
in fuel injection, braking, and traction control.
Electronic Control Unit (ECU) is basically a
processor or computing system, integrated with
a data acquisition device or an electromechanical
driver. Sensors provide measurements of specific
vehicle parameters in a format suitable for the
digital microcontroller. Similarly, actuators are
electrically operated devices that regulate signals
to the device that directly control its output. The
ECU is modeled as a closed-loop control system.
The ECU performs a looped control by sensing
the automotive system parameters, processing
the computation for determination of appropriate
reaction, and then outputting the control signal to
adjust the operation of the automotive system. This
control loop starts again, when the automotive
system parameters change (Robert Bosch, 2006).
Figure 4 demonstrates the closed-loop control
of automobile steering under variable human,
vehicle, or environmental parameters.
Some examples of ECU implementations are
described in the next few subsections. Due to the
strict operation environment in a vehicle, some
factors are carefully considered before developing an ECU.
•
Size: Though the dimensions of a vehicle
seem to be large, it is designed to have most
of the space reserved for driver and passengers. The physical size of an ECU has to
be small and is integrated into the electromechanical module. The advancement of
the semiconductor manufacturing process
Figure 4. Closed-loop control of automobile steering under variable human, vehicle and environment
parameters
63
Vehicular Embedded System Architecture
•
•
•
makes this miniaturization requirement
feasible.
Cost: Cost is always an important factor
in promoting a product on the market. The
electronic components are utilized more
than ever in a modern vehicle where several ECUs can be utilized in an automotive
system, so the cost of the electronic devices is also a concern. All in all, processor
technology, IC technology, or component
specifications determine the cost.
Function: Due to different requirements
for individual subsystems in an automotive
system, ECUs are developed for various
automotive functions. A dedicated computing system embedded in an ECU can
optimize its control performance. Though
the system architecture is similar, the hardware of sensors, actuator components, processor technology, and firmware of data
acquisition, control and signal processing
are different.
Performance: Powertrain or brake controls are time-critical when driving on the
road. A real-time operation, which guarantees the designated tasks can be finished
before the critical deadline, is required.
Vehicle speed is very high on highway and
human reaction time is short, so the system
•
•
performance is required to be efficient to
ensure the appropriate control.
Stability: The implementation of an ECU
does not only require the performance but
also the accuracy. This is to ensure the appropriate functioning of the system. The
conventional mechanical control can be
investigated by vision or instrumentation,
but the operation of an electronic system
with hardware and software is invisible and
has to be tested through a suite of carefully
defined test cases. However, this still does
not guarantee the perfect functions without
any errors. The fault tolerant or self-recovery mechanism must be considered to be
implemented in the system to enhance the
stability.
Robustness: Due to severe operation environments in a vehicle, if the hardware is not
robust enough it may cause the software to
malfunction. The electronic components
and the board design have to be developed
on a stricter industrial standard for tolerating temperature, humidity, electrical noise,
or electromagnetic interference.
Figure 5 depicts the block diagram of an electronic control unit, while the blocks surrounding
the computing platform are optional depending
on the function of the ECU.
Figure 5. A complete block diagram of electronic control unit
64
Vehicular Embedded System Architecture
powertrain
Powertrain management controls the engine and
transmission. From the sensor inputs, the environmental information, driving-conditions, vehicle
and user parameters are obtained for the powertain
controller to determine the operation of the engine
and transmission; then the powertrain controller
commands the engine, traction controller, and
transmission to generate the appropriate torque,
slip, or gear ratio (Robert Bosch, 2006).
antilock braking system
The ABS control system includes ABS ECU,
wheel module, brake pedal module, and hydraulic
modulator (Robert Bosch, 2006). When force is
applied on the brake pedal, the braking operation
works through: brake booster, master cylinder,
hydraulic modulator, wheel-brake cylinder and
then brake. The ECU monitors the wheel speed;
the master cylinder, pressure, calculates the actual and required slip and regulates the hydraulic
modulator. The hydraulic modulator has solenoid
valves, which adjust pressure from the master
cylinder to the wheel-brake cylinder. The ABS,
preventing the wheels from locking up, works
when the wheel brake pressures are lowered.
Figure 6. Block diagram of antilock braking
system
Figure 6 shows the simplified block diagram of
an antilock braking system.
Traction control
When the driver presses the accelerator, the
engine torque is converted to drive axle torque,
and then is distributed to driven wheels via the
transversal differential. If the increased torque can
be transferred completely to the road surface, the
vehicle can stably accelerate. In some low friction
coefficient road surface situation, when the drive
torque can not be transferred completely, the wheel
will spin and the vehicle becomes unstable due
to the loss of lateral stability.
The traction control system (TCS) ECU and
transversal differential lock controller regulates the
slip of the driven wheel by determining a reference
slip value, sensing the differential wheel speed,
calculating distribution ratio of the transversal
differential, and correcting the drive torque and
braking torque (Robert Bosch, 2006). The drive
torque can be adjusted by engine intervention,
while the braking torque regulated for each wheel
is via the expanded ABS hydraulic system. Figure
7 depicts the block diagram of a traction control
system.
adaptive cruise control
The ACC controller includes cruise control, tracking control, and acceleration control (Robert Bosch, 2006). The cruise control adjusts the vehicle
speed until it is equal to the set speed. The tracking
control selects one of the vehicles ahead as the
following target, and calculates the acceleration
based on the distance and relative speed. The
acceleration control sends the acceleration commands to the powertrain or braking system. Figure
8 demonstrates the functional block diagram of
an adaptive cruise control system.
65
Vehicular Embedded System Architecture
Figure 7. Block diagram of traction control system
Figure 8. Block diagram of adaptive cruise control system
electronic stability
The electronic stability program (ESP) improves
vehicle handling and braking response through
programmed intervention in the braking system
and/or powertrain to prevent the linear, lateral, or
yaw velocity from exceeding control limits (Robert
Bosch, 2006). The ESP integrates the capabilities
of both ABS and TCS into a closed-loop control,
and provides each wheel highly precise performance of the dynamic braking and longitudinal
and lateral forces under various circumstances.
66
Figure 9 shows the simplified block diagram of
an ESP control loop. The sensors involve yaw-rate,
steering wheel-angle, pressure, and wheel-speed
sensors, while the actuators include hydraulic
modulators for braking and engine management
ECU for drive torque.
processors
A processor is a semiconductor chip with digital
circuits, which performs computational or logical tasks. It consists of three parts: the controller,
Vehicular Embedded System Architecture
Figure 9. Block diagram of electronic stability
program system
prototyping. The semicustom application-specific
IC (ASIC), like gate array or standard-cell ASIC,
compromises these two IC technologies mentioned
above, so part of the arrays of gates or logic-level
cells have already been built and system developers
just need to connect these predefined components
to implement their design (Vahid et al., 2002).
According to the arrangement of the controller, datapath, and memory in a processor;
processor technology can be categorized into the
following three types: general-purpose processor,
application-specific processor, and single-purpose
processors. The processor technology is relevant
to the hardware and software design of an embedded system, so the application is critical and they
are described below.
general-purpose microcontroller
datapath, and memory. The controller decodes
the logic of software instructions or changes the
transfer among the hardware state machines. Datapath is the component executing computation or
logic functions for the specified data. Memory is
the storage space for data and program. Different
processor technologies emphasize differently on
the structure of these three processor components,
so they are designed for different system architecture development.
The processor is manufactured as an integrated
circuit (IC) component. It is implemented in different IC technologies, which determine the level
that the chip is customized. A full-custom/verylarge-scale integration (VLSI) technology optimizes performance and functions of a processor
from all aspects of digital circuit design. The
manufacturing of a full-custom process has high
nonrecurring engineering (NRE) costs and long
turnaround times. On the other hand, programmable logic device (PLD) is off-the-shelf and is
ready to be used through hardware description
language (HDL) programming and synthesis. It
has a high unit cost, consumes more power, but
it still provides reasonable performance for fast
General-purpose processor or microprocessors
are designed for almost all of the common applications. The logic is implemented by software
programming, which has the maximum flexibility
to alter its implementation, but has the lowest cost
for modification. A microcontroller is a microprocessor along with some peripheral modules,
like memory and I/O, integrated in a single chip
without external circuits, so it provides extensive
functions and is widely used in many embedded
control systems. A more complicated system-onchip (SoC) technology integrates more peripheral
modules in one chip, almost a complete system
even including analog circuits. So the SoC microcontroller is able to implement more sophisticated
functions to act as a full system.
Among the processor technologies, this is the
most common approach. The system implemented
on a general-purpose microprocessor is referred
to as a software approach. According to different applications, many manufacturers or product
families, from low-end 8-bit to high-end 32-bit,
can be chosen. Another issue to be considered is
whether the application program is executed in an
operating system (OS) or non-OS environment.
67
Vehicular Embedded System Architecture
For a low-end microcontroller, the program is
usually implemented in a non-OS foreground/
background mode, because the on-chip memory is
small and the system clock is slow, so usually the
control functions are not complicated. On the other
hand, adopting a high-end 32-bit microcontroller
implies the requirement of faster computations
and complicated functions. Because of larger
memory and a faster clock, the OS environment,
which takes care of system resource management,
is much better and more convenient for application development.
Renesas has several microcontroller families,
for instance: SuperH, H8, and M16/R32 to provide
a variety of automotive functions, like powertrain,
chassis, body, active/passive safety, audio and
navigation. Since the microcontroller is the core
of an electronic control unit and connected on the
in-vehicle network, CAN or FlexRay, the network
physical controller is mandatory in the microcontroller family for automotive applications.
programmable logic device
The system implemented on a programmable
logic device is referred to as a hardware approach,
because the logic is realized on synthesized logic
gates. This approach is usually implemented for
prototype designs and verification, and later the
logic circuits will be manufactured as a full-custom
IC. The throughput, power consumption, and cost
of PLD are usually inferior or more expensive
than that of a full-custom IC, but it is convenient
for prototype development. For example, Xilinx
provides XA products with Spartan-3 FPGA and
IPs to implement image processing, video, or invehicle network solutions.
digital signal processor
The digital signal processor (DSP) is an application
specific processor, which optimizes the datapath
design, so execution of signal processing instructions has a much higher throughput. Moreover,
68
some dedicated hardware is added for specific
applications, and the performance is improved.
DSP is also a software approach, because the
logic is implemented by software. Developments
on DSP have advantages and drawbacks lying
between microprocessor and PLD. Texas Instruments’ TMS320 DSP series with a fixed-point or
floating-point provides solutions to automotive
infotainment, vision control, and digital radio.
sensors
Sensors are applied as the input devices in an
ECU for obtaining environmental and vehicular
parameters. The advanced control of a modern
automobile largely depends on the data acquired
from sensors. Sensors convert a physical parameter
to an electrical signal, and a signal conditioning
circuit adjusts the electrical signal to the voltage
range specified by the analog-to-digital converter
(ADC). After the signal is converted to digital
data, the processor can process it by applying a
simple value comparison or a complicated digital
signal processing algorithm.
The advancement of electronic technology
and material science pushes the innovation of
sensor development. It improves the functions
and decreases the cost of an automotive system,
so vehicle features are greatly enhanced. Sensors play a more and more important role in
the implementation of ECUs in vehicles. The
average number of sensors per vehicle was 40
in 2007, and will be up to 70 in 2013, while the
total sensor production will jump from 640 M to
1100 M in North America. Modern luxury cars
have more than 100 sensors per vehicle, and total
of 167 automotive applications were described.
The applications of sensors in a vehicle can be
categorized into three areas: powertrain, safety,
and comfort (Fleming, 2008).
Some sensors used in automobiles are described more in the following subsections.
Vehicular Embedded System Architecture
accelerometer
The accelerometer, or g-cell, is applied for
crash-detection. A microelectrical mechanical
system (MEMS) accelerometer, which employs
single-point sensing, reduces the dimension and
cost by removing the wiring and harness (Monk
et al., 2003).
Airbag systems, including front airbags, side
airbags, seat belt pretensioners and occupant
sensing systems, become more complicated and
need more sensing requirements. Airbag systems
are required by government safety regulations,
and the accelerometer plays an important role in
the operation.
are coded and transmitted to central console by
radio frequency (RF) communications (Normann
et al., 2003).
Temperature
Several temperature sensors are applied in monitoring engine, coolant, gear-box, fuel, intake-air,
outside-air, passenger compartment, climate
control unit parameter, and exhaust-gas in an
automotive system. There are two temperature
ranges to be measured. The first one covers
-40 to 170°C, and the second range for exhaust
temperature measurement covers -40 to 760°C
(Bojarski, 2003).
yaw-rate
radar
Yaw-rate sensor, angular rate sensor, or gyroscope,
measure the rotation of a body in angle per unit of
time along a specified axis. Typical applications
include electronic stability program, rollover
protection, and navigation. When concerning, the
turning movement is monitored and is compared
with the angle of the steering wheel and vehicle
speed. Rollover accidents usually happen during
high-speed driving, and causes serious injury or
death to the driver and passengers, so the yaw-rate
sensor must recognize the rollover of a vehicle
and thus activating the safety systems appropriate
protection (Schatz et al., 2003).
Radar is employed for collision avoidance by
finding the distance to the preceding vehicle,
and ACC can be implemented by utilizing the
information of distance and relative speed. Since
the vehicle speed is high and response time is
short on highway, a long-range radar (LRR),
up to 120 m, which takes 3.6 s to collide with
the stationary object at the speed 120 km/hr, is
required for ACC. Short-range radars (SRR), up
to 20 m, are applied for both sides of vehicle to
create a safety shield around the car (Knoll, 2003).
Figure 10 demonstrates surround sensing using
radar and video.
pressure
Video
A variety of pressure sensors are employed for
automotive applications. Vaporized gasoline leak
detection is in the low-pressure field (Yokomori
et al., 2003). Suspension pressure detection and
air-conditioner refrigerant pressure detection
are in the high-pressure field. While gasoline
fuel injection is in the very high-pressure field
(Gerbers, 2003). Tire-pressure sensors measure
the air pressure and temperature inside the tire.
The data along with tire ID and battery lifetime
Though radar can easily find the distance of an
object in front, it has a narrow beam and cannot
recognize objects or detect borders. A camera system is used for several applications in automotive
system, like lane departure warning, night-vision
improvement, object detection, blind spot warning, and distance warning.
The video solution seems more feasible, but
some issues need to be addressed. The captured
images are essentially affected by light intensity,
69
Vehicular Embedded System Architecture
Figure 10. Surround sensing using radar and video
so an intelligent high-quality camera is required
for automatic adjustment. A far infrared (FIR)
technology is used for night-vision improvement.
Real-time image processing needs intensive computing power, so a high-speed industrial computer,
which may be expensive and occupies large space,
is required (Knoll, 2003).
wheel-speed
The wheel-speed sensor measures the movement
and circumstance of the tire. The ABS and TCS,
prevents wheel locking and spinning, needs to
know the wheel speed when applying the brake
or accelerator, respectively. ESP for vehicle
stability also needs wheel speed information.
Other applications include transmission control,
odometer, navigation system, stop and go, and
roll over protection (Morbe, 2003).
steering-angle
Steering angle sensor is applied for ESP, which
requires steering angle along with yaw rate, wheel
speed, and lateral acceleration to determine if
the vehicle oversteers or understeers. The sensor
is also used in electric power steering, adaptive
cruise control, forward intelligent lighting, navi-
70
gation system, active front and rear steering, and
steer-by-wire (Kofink, 2003).
Torque
The torque sensors measure the powertrain torque
signals on engine and transmission control units,
which are part of the applications of TCS and ESP.
Electric power steering is another application of
torque sensors, which measure angular displacement,
which is proportional to torque (Morbe, 2003).
chemical
There are several types of chemical sensors, including oxygen detection for air/fuel ratio control
(Riegel et al., 2003), NOx sensors for emission
control (Schmitt, 2003) and liquid media sensor
(Jakoby et al., 2003). The exhaust gas of a vehicle
has to meet emission limits, so a catalyst system is
installed to do the conversion. While oxygen and
NOx sensors are used for after-treatment sensing,
liquid sensors are used to detect the quality of
liquids, such as engine oil, gear-box oil, fuel, and
battery liquid to check if they should be changed
or are in abnormal states.
Vehicular Embedded System Architecture
acTuaTors
ignition
Actuators are output devices to drive electromechanical components. They are either implemented
by a solenoid, which is controlled by duty cycle
or PWM approach, or an electric motor, like the
stepper motor or dc motor (Bonnick, 2001).
Some example applications of actuators are
fuel injectors, exhaust gas recirculation, ignition,
ABS modulators, variable valve timing (VVT),
and electric motors for hybrid/electric vehicles.
The actuators of the ignition system are the combination of the spark plug, the ignition coil, and driver
electronic circuits. When the controller sends a
signal turning on the driver, i.e. a power transistor is
conductive, current flows through the primary coil,
creating a relatively large magnetic field linked to the
secondary coil. The controller instantly switches off
the signal, causing the transistor to be nonconducting.
The sudden rapid drop in the magnetic field of the
secondary coil generates a very high voltage creating
the spark across the spark plug electrodes, igniting
the mixture and, finally, initiating the power stroke
for the engine (Bonnick, 2001).
Fuel injectors
Fuel injectors are electrically driven actuators that
regulate the flow of fuel into an engine for engine
control applications. A fuel injector is a solenoidoperated valve, which opens or closes to permit or
block fuel flow to the engine. The valve is attached
to the movable element of the solenoid and is
switched by the solenoid activation. The quantity
of fuel injected is proportional to the duration when
the valve is opened, so the valve can be controlled
by applying a pulse train with a specified duty cycle
to the solenoid (Bonnick, 2001).
exhaust gas recirculation
Exhaust gas recirculation (EGR) is utilized to
reduce NOx emissions. The engine controller determines the amount of EGR and sends a signal to
EGR actuator. Typically, this actuator is a variableposition solenoid controlled valve that regulates
the EGR as a function of intake manifold pressure
and exhaust gas pressure. When the EGR valve is
open, exhaust gas flows into the intake manifold.
Like the fuel injector, by sending a pulse train with
specified duty cycle to the solenoid, EGR actuator
regulates the pressure to open the valve and then
the amount of EGR (Bonnick, 2001).
abs modulators
Anti-lock braking system modulator contains a
pump driven by an electric motor and various
solenoid-operated valves. Solenoid valves with two
hydraulic connections and two valve positions are
used. At different degrees of brake slip, the solenoid
valves switch to different pressure settings to change
the pressure in the brake (Bonnick, 2001).
sTorage deVices
Storage devices were not commonly used in
conventional vehicle systems, because there were
few applications involving the storage of large
amounts of data. One application for drivers or
passengers to have some entertaining activities
during their drive is playing audio or video from
CDs or DVDs. Today, the navigation systems are
more affordable and popular for eliminating the
map-reading, so a mass storage device for saving
the data of maps and landmark pictures is necessary. More applications for an infotainment system
are developed, while the mass storage devices are
mandatory for storing the multimedia contents.
Hard disks are the most common storage devices in personal computers, but they don’t work
71
Vehicular Embedded System Architecture
in an automotive system, which is operated in
an environment with severe vibration. After the
solid-state storage technology is more established
and the cost is lower, the automotive applications
with mass storage devices are possible.
Flash memory is based on the solid-state
technology and two types of flash memory,
NAND flash and NOR flash, have emerged as the
dominant varieties of non-volatile semiconductor memories utilized in embedded systems. The
characteristics of NAND flash are high density,
medium read speed, high write speed, high erase
speed, and an indirect or I/O like access, so it is
low cost and has been used primarily as a removable high-density data storage medium, which is
appropriate for mass storage applications. The
characteristics of NOR flash are lower density,
high read speed, slow write speed, slow erase
speed, and a random access interface, so it has
typically been used for code storage and direct
execution in portable electronics devices. Flash
memory will increase in demand, since it can
store not only multimedia data and navigation
information, but also the run-time vehicle data
and image as an event data recorder.
human machine inTerFaces
Most ECUs don’t interact with the users directly,
so driver and passengers need to control the vehicle
through either dashboard or other mechanical
devices, like the steering wheel, brake pedal, or
button/knob. Though the electronic components
being used are increasing, the conventional powertrain and brake operation will not change in the
near future, as a result of driving habits and safety
reasons. Steer-by-wire and brake-by-wire haven’t
substituted the steering wheel and brake pedal
yet. However, the user interface to enhance the
convenient infotainment management and comfort
adjustment will be realized and popular.
The human machine interface involves input
and output. The conventional needle instrument
72
and button/knob will be replaced by liquid crystal
display (LCD) and touch screen in the central
console. Due to the limited space on dashboards
and the increased amount of information that
needs to be displayed, the graphic LCD display
will integrate a variety of information modes into
one module and can show the information flexibly.
According to the usage priority or user interaction, the LCD display can show driver functions
and vehicle status, navigation information, and
driving assisted images.
To simplify the central console appearance,
the LCD display and touch screen panel are integrated into one module. The touch screen panel is
mandatory in mobile devices and eliminates the
usage of keyboard and mouse in a conventional
PC environment. This intuitively enhances the human machine interaction on a more user-friendly
graphical presentation. There are two common
types of touch screen: capacitive and resistive.
For security applications, biometric system
and radio-frequency ID (RFID) devices are input
modules for identity confirmation and personalized operation, so they enhance the convenient
features of automobiles. The biometric mechanisms, including fingerprint identification, face
recognition, iris recognition and voice recognition,
verify if the person’s unique biometric characteristics is matching with the enrollment setting
(Robert Bosch, 2006). These approaches have been
researched for a variety of security applications,
but most of them still do not reach a perfect successful rate in various environments or don’t have
a straightforward and friendly operation process.
Fingerprint identification is a more reliable approach and is employed for personalized adjustment functions and configurable favorite settings.
RFID devices, using radio frequency to read and
verify the identification and information, have the
same application as the fingerprint approach. This
technology or similar ones will be the innovative
alternative to the car key and be a personal information storage device in the future.
Vehicular Embedded System Architecture
reFerences
Bojarski, A., & Fichte, W. (2003). Temperature
sensors. In J. Marek, H.P. Trah, Y. Suzuki,& I.
Yokomori, (Ed.), Sensors Application Vol. 4 - Sensors for Automotive Technology (pp. 343-359).
Berlin: Wiley-VCH.
Morbe, M., & Zwiener, G. (2003). Whell-speed
sensors. In J. Marek, H.P. Trah, Y. Suzuki,& I.
Yokomori, (Ed.), Sensors application Vol. 4 Sensors for automotive technology (pp. 403-415).
Berlin: Wiley-VCH.
Bonnick, A. (2001). Automotive computer controlled systems. London: Butterworth Heinemann.
Normann, N., Schulze, G., & Keller, W. (2003).
Tire-pressure sensors. In J. Marek, H.P. Trah, Y.
Suzuki,& I. Yokomori, (Ed.), Sensors application
Vol. 4 - Sensors for automotive technology (pp.
536-544). Berlin: Wiley-VCH.
Fleming, W. J. (2008). New automotive sensors−A
review. IEEE Sensors Journal, 8(11), 1900–1921.
doi:10.1109/JSEN.2008.2006452
Paret, D. (2007). Multiplexed networks for embedded systems – CAN, LIN, FlexRay, Safe-by-Wire.
Hoboken, NJ: Wiley.
Gerbers, J. (2003). High-pressure sensors. In
J. Marek, H.P. Trah, Y. Suzuki,& I. Yokomori,
(Ed.), Sensors Application Vol. 4 - Sensors for
Automotive Technology (pp. 333-342). Berlin:
Wiley-VCH.
Riegel, J., Wiedenmann, H., & Neumann, H.
(2003). Chemical sensors for oxygen detection
and air/fuel ratio contol. In J. Marek, H.P. Trah, Y.
Suzuki,& I. Yokomori, (Ed.), Sensors application
Vol. 4 - Sensors for automotive technology (pp.
480-499). Berlin: Wiley-VCH.
Jakoby, B., & Herrmann, F. (2003). Chemical
sensors for liquid media. In J. Marek, H.P. Trah,
Y. Suzuki,& I. Yokomori, (Ed.), Sensors Application Vol. 4 - Sensors for Automotive Technology
(pp. 516-526). Berlin: Wiley-VCH.
Knoll, P. (2003). Radar sensors. In J. Marek, H.P.
Trah, Y. Suzuki,& I. Yokomori, (Ed.), Sensors
application Vol. 4 - Sensors for automotive technology (pp. 372-385). Berlin: Wiley-VCH.
Knoll, P. (2003). Video sensors. In J. Marek, H.P.
Trah, Y. Suzuki,& I. Yokomori, (Ed.), Sensors
application Vol. 4 - Sensors for automotive technology (pp. 386-402). Berlin: Wiley-VCH.
Kofink, P. (2003). Steering-angle sensors. In J.
Marek, H.P. Trah, Y. Suzuki,& I. Yokomori, (Ed.),
Sensors application Vol. 4 - Sensors for automotive
technology (pp. 428-449). Berlin: Wiley-VCH.
Monk, D., Mladenovic, D., & Skaw, M. (2003).
Accelerometers for automotive applications. In
J. Marek, H.P. Trah, Y. Suzuki,& I. Yokomori,
(Ed.), Sensors application Vol. 4 - Sensors for
automotive technology (pp. 269-296). Berlin:
Wiley-VCH.
Robert Bosch Gmb, H. (2006). Safety, comfort and
convenience systems. Hoboken, NJ: Wiley.
Schatz, O. (2003). Yaw-rate sensors. In J. Marek,
H.P. Trah, Y. Suzuki,& I. Yokomori, (Ed.), Sensors application Vol. 4 - Sensors for automotive
technology (pp. 297-313). Berlin: Wiley-VCH.
Schmitt, D. (2003). Chemical sensors for emission control. In J. Marek, H.P. Trah, Y. Suzuki,&
I. Yokomori, (Ed.), Sensors application Vol. 4 Sensors for automotive technology (pp. 500-508).
Berlin: Wiley-VCH.
Vahid, F., & Givargis, T. (2002). Embedded system
design: A unified hardware/software introduction.
Hoboken, NJ: Wiley.
Yokomori, I., & Suzuki, Y. (2003). Pressure sensors. In J. Marek, H.P. Trah, Y. Suzuki,& I. Yokomori, (Ed.), Sensors application Vol. 4 - Sensors
for automotive technology (pp. 314-332). Berlin:
Wiley-VCH.
73
74
Chapter 5
Data Communications Inside
Vehicular Environments
Cheng-Min Lin
Nan Kai University of Technology, Taiwan, R.O.C.
Tzong-Jye Liu
Feng Chia University, Taiwan, R.O.C.
absTracT
ZigBee is based on IEEE 802.15.4 which specifies the physical layer and medium access control (MAC)
for low-cost and low-power LR-WPAN. The technology can be applied in intelligent key, A/C operation and steering wheel inside vehicles. There are two types of devices in ZigBee, FFD and RFD. A
FFD can communicate with RFDs and other FFDs, while a RFD can only communicate with a FFD.
In ZigBee physical layer, it follows IEEE 802.15.4 standard and operates in unlicensed RF worldwide
(2.4GHz global, 915MHz Americas or 868 MHz Europe). A superframe contained an active portion
and an inactive portion is used in the MAC layer of ZigBee. The active portion includes CAP and CFP.
In the inactive partition, the coordinator can enter sleep mode to save its power. Three main topologies
of ZigBee are star, mesh, and tree. However, ZigBee is successfully produced into a low-cost controller
applied for automotive applications, including vehicle control and status monitoring. According to the
forecast of ON World in 2005 (ON WORLD, 2009), the deployed wireless sensing network nodes will
increase to 127 million in 2010 from 1.2 million in 2005. It can be applied in home automation, battlefield
surveillance, health care applications and vehicular environments. A wireless sensor network (WSN)
constitutes a lot of wireless sensing nodes. In addition, a node in WSN consists of one or more sensors,
a radio transceiver, and a microcontroller. The sensor can be used for sensing temperature, pressure,
sound, vibration, motion or position, etc. to collect status from devices or environments. The transceiver
is used to relay the information of the collected status computed by the microcontroller to a center node,
called a gateway or sink. Therefore, a WSN belongs to one type of wireless ad-hoc networks. However,
the nodes in a WSN are usually smaller than that in traditional wireless ad-hoc networks regarding node
size, computing power, memory size, and transmission rage. In other words, the transmission ability,
computing power, and memory size of WSN nodes are limited.
DOI: 10.4018/978-1-60566-840-6.ch005
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Data Communications Inside Vehicular Environments
inTroducTion
In vehicular environments, a wireless personal area
network (WPAN) is required because a driver is
a master for the vehicle. The driver interacts with
his/her vehicle according to the collected information from WPAN and a controller area network
(CAN). The standard of WPANs is defined in the
15th working group of the IEEE 802.15. There are
six task groups in the working group as shown in
the following.
•
•
•
•
•
•
IEEE 802.15.1: Bluetooth
IEEE 802.15.2: Coexistence
IEEE 802.15.3: High rate WPANs (HRWPAN), UWB
IEEE 802.15.4: Low rate WPANs (LRWPAN), ZigBee
IEEE 802.15.5: Mesh network
IEEE 802.15.6: Body area network
technologies
In this chapter, we will focus on the introduction of ZigBee based on IEEE 802.15.4, a standard
completed in May 2003 which specifies the physical layer and medium access control (MAC) for
low-cost and low-power LR-WPAN. Although
ZigBee-style networks created by the Firefly
Working Group in 1999 become ZigBee later, the
group does not exist now. Today’s ZigBee was
adopted in 2003 and built on the IEEE 802.15.4
LR-WPAN standard and the ZigBee Alliance
ratified the first ZigBee standard in December
2004 (Geer, 2005).
oVerView oF ieee 802.15.4
The IEEE802.15.4 standard is the basis for the
ZigBee specification. It specified the physical
layer and MAC layer for LR-WPAN, providing the
fundamental lower layers of WPAN. Upper layers
of the protocol stack include application profiles
defined by ZigBee Alliance. The architecture
ZigBee/802.15.4 is shown in Figure 1.
The architecture focuses on low-cost, lowspeed ubiquitous communication between devices.
Furthermore, the features of IEEE 802.15.4 are
illustrated as follows according to the mention
of LR-WPAN Task Group (The IEEE 802.15.4
WPAN Task Group, 2009). Its applications are
shown in Figure 2.
•
•
•
•
•
Data rates of 250 kbps, 40 kbps, and 20
kbps
Star or peer-to-peer operation
Dynamic device addressing
Two addressing modes are implemented,
including 16-bit short and 64-bit IEEE
addressing
Support for critical latency devices, such
as joysticks
Figure 1. ZigBee/802.15.4 architecture
75
Data Communications Inside Vehicular Environments
Figure 2. ZigBee applications
•
•
•
•
•
Carrier Sense Multiple Access/Collision
Avoidance (CSMA/CA) channel access is
provided
Automatic network is established by the
coordinator
Fully handshaked protocol for reliability of
transmission
Power management is implemented to ensure low power consumption
27 different channels, including 16 channels in the 2.4GHz ISM band, 10 channels
in the 915MHz band and one channel in
the 868MHz band
Figure 3. FFD vs. RFD
76
Two different types of devices are defined in
an LR-WPAN, a full function device (FFD) and
a reduced function device (RFD). A FFD can
communicate with RFDs and other FFDs, while
a RFD can only communicate with a FFD. FFD
can operate in the device, coordinator, and PAN
coordinator modes, while RFD can only operate
in the device mode. The comparison between FFD
and RFD is shown in Figure 3.
The ZigBee Alliance focuses on the network
layer to the application layer. As shown in Figure
4, a ZigBee Device Object (ZDO) is a special
device in a ZigBee network. It is responsible for
a number of tasks including keeping of device
roles, management of requests to join a network,
Data Communications Inside Vehicular Environments
Figure 4. Outline of the ZigBee stack architecture
device discovery, and security. A ZDO contains
ZDO Management Plane, and also defines the
role of the device in the network such as ZigBee
coordinator or end device. A ZDO can discover
devices on the network and determine which application services they provide. ZDOs also can
initialize or respond to binding requests. The last
function of ZDOs is to establish secure relationship, among network devices. The functionality of
Application Support Sublayer (APS) is to provide
interfaces between application layer and network
layer. The services of the interface are offered
by two entities: data service and management.
The APS data entity (APSDE) provides the data
transmission service, while the APS management
entity (APSME) provides the management service.
The application frame is the environment whose
application objects are hosted in the ZigBee device.
The application objects are responsible for sending
and receiving the data and provide several functions. The first function is to control and manage
the protocol layers. The second function is the
initialization of standard network functions. The
Security Service Provider is responsible for key
establishment, key transport, frame protection,
and device management.
Zigbee physical layer
ZigBee is the technology of a novel WSN that
is designed for the automation and controlling
buildings, consumer electronics, and intra-vehicle
wireless communications. The PHY functionalities of ZigBee are listed below.
•
•
•
•
•
•
Activation and deactivation of radio
transceiver
Energy detection within current channel
Link quality indication for received
packets
Clear channel assessment for CSMA/CA
Channel frequency selection
Data transmission and reception
ZigBee follows IEEE 802.15.4 standard and
operates in unlicensed RF worldwide (2.4GHz
global, 915MHz Americas or 868 MHz Europe).
There are 27 channels allocated in ZigBee standards as shown in Figure 5. Channel 0 uses the
frequency at 868.0 ~ 868.6 MHz, while the data
rate is 20 kbps. Channels 1 ~ 10 use the frequency
at 902.0 ~ 928 MHz, where each channel can
provide 40 kbps data rate. Channels 11 ~ 26 use
the frequency at 2.4 ~ 2.4835 GHz, where each
channel is 250 kbps.
The physical layer of 868/915 MHz and 2.4
GHz uses Direct Sequence Spread Spectrum
77
Data Communications Inside Vehicular Environments
Figure 5. ZigBee channel overview
Figure 6. PHY frame structure
(DSSS) to carry data to the channels. In 868/915
physical layer, the packet error rate must be equal
to or smaller than 1% so that the hardware receiver
sensitivity is required to be equal to or higher than
-92 dBm. In 2.4 GHz physical layer, hardware
receiver sensitivity is required to be equal to or
higher than -85 dBm. The transmission power of
ZigBee must be higher than -3 dBm (0.5 mW).
During normal operations, the transmission power
is 0 dBm (1 mW). When the transmission power
is 0 dBm, the transmission range is about 10 ~ 20
meters. For variant applications, the transmission
power can be adjusted so that the transmission
range can be increased to 30 ~ 75 meters.
The PHY frame structure of ZigBee is shown
in Figure 6. There are three fields in the packet.
The preamble (32 bits) is used for synchronization and the start of packet delimiter (8 bits) shall
be formatted as “11100101”. The PHY header
(8 bits) contains the length (0 to 127 bytes) of
PSDU data field.
78
Zigbee mac layer
In the ZigBee specification, the superframe format
is shown in Figure 7. It is defined by the network
coordinator. The superframe duration is the beacon
interval broadcasted by the network coordinator.
A superframe contains an active portion and an
inactive portion. The active portion can be divided
into 16 time slots, which can be cataloged as contention access period (CAP) and contention free
period (CFP). The coordinator only receives and
sends data with other devices in WPAN at active
portion. In the inactive partition, the coordinator
can enter sleep mode to save its power.
The beacon message is broadcasted at time
slot 0. The purposes of the beacon message are
listed as follows:
•
•
•
•
Starting superframes
Synchronizing with associated devices
Announcing the existence of a PAN
Informing pending data in coordinators
Data Communications Inside Vehicular Environments
Figure 7. The superframe structure
Any device wants to communicate with the
coordinator in the contention access period must
use a slotted CSMA/CA mechanism to access
the time slots. For some applications that devices
require low delay time or fixed transmission rate,
the coordinator can assign some Guarantee Time
Slots (GTS) for them to use. The contention free
period consists of several GTSs. The maximum
number of GTS is limited to seven according to
the standard. This means that only the limited
number of nodes can use GTS.
In ZigBee, there are three data transfer models:
“device to coordinator,” “coordinator to device,”
and “device to device.” The data transfer models
are discussed below.
Device to coordinator. In a beacon-enable
network, devices would find the beacon to synchronize to the superframe structure, and then they
would use slotted CSMA/CA to transmit data. In
a non beacon-enabled network, devices simply
transmit their data using unslotted CSMA/CA.
The procedure is shown in Figure 8.
Coordinator to device. In a beacon-enabled
network, the coordinator indicates in the beacon
that the data is pending. Device periodically listens
to the beacon and transmits a MAC command
request using slotted CSMA/CA if necessary. In
a non-beacon-enabled network, a device transmits
a MAC command request using unslotted CSMA/
CA. If the coordinator has its pending data, the
coordinator transmits data frame using unslotted
CSMA/CA. Otherwise, the coordinator would
transmit a data frame with zero length payload
(Figure 9).
Device to device. In a peer-to-peer topology,
devices may directly communicate with other
devices in the transmission range. In order to
transmission data efficiently, the device transmit-
Figure 8. Data transfer model (Device to coordinator)
79
Data Communications Inside Vehicular Environments
Figure 9. Data transfer model (Coordinator to device)
ting data can not enter the sleep mode. It would
use unslotted CSMA/CA to transmit data.
•
Zigbee network layer
The specification of ZigBee provides three types
of topologies: star topology, mesh topology, and
cluster tree topology as shown in Figure 10. According to the ability of ZigBee devices, we can
divide them into FFDs and RFDs. FFDs have a
lot of resources that include the computing capability, memory, and the power than RFDs. In
addition, these topologies are made up by three
types of devices. First of all, the most important
type of devices is the ZigBee coordinator (ZC).
Any topology can have only one ZC. Furthermore,
the ZC in a ZigBee-based network is also a FFD.
The ZC is responsible for network formation and
maintenance. The second type of devices is the
ZigBee router (ZR). The ZR is a FFD or a RFD.
However, the resource in a RFD has less than that
in a FFD. Moreover, the router is responsible for
forwarding packets in the network. The last type
of devices is the ZigBee end device (ZED). The
ZED is the RFD and it cannot forward packets. In
other words, the ZED cannot relay data from other
devices and only talk to their parent devices.
80
•
To support star topology and cluster-tree
topology, the routing protocol of ZigBee
uses the concept of tree routing. When a
device receives a packet, it first checks
if the device itself or one of its child end
devices is the destination. If so, this device will accept the packet or forward this
packet to the designated child. Otherwise,
it would relay the packet along the tree.
To support mesh topology, the ZigBee
routing protocol uses the concept of Adhoc On-demand Distance Vector (AODV)
(Perkins et al., 1999), an on-demand approach for finding routes. Links with lower
cost will be chosen into the routing path.
The cost of a link is defined based on the
packet delivery probability on that link.
Route discovery procedure was discussed
as follows. The source broadcasts a route
request packet. Intermediate nodes will rebroadcast route request if they have routing discovery table capacities and the cost
is lower. Otherwise, nodes will relay the
request along the tree. The destination will
choose the routing path with the lowest
cost and then send a route reply. The advantages of AODV are no extra traffic for
Data Communications Inside Vehicular Environments
Figure 10. Three topologies of ZigBee
communication along existing links, and
supporting unicast/ multicast.
When a new ZigBee device joins the network,
it has to choose a new suitable parent node. In
ZigBee specification, the new parent must satisfy
three conditions. First, its information is in the
new ZigBee device’s neighbor table. Second, the
link cost between the new ZigBee device and the
parent node must be more than 3. Finally, the new
parent node must have the minimum depth from
coordinator in the neighbor table.
In ZigBee, network addresses are assigned
to devices via a distributed address assignment
scheme. When the network was formed, the ZigBee coordinator would determine three network
parameters.
•
•
•
Cm: Maximum number of children of a
ZigBee router
Rm: Maximum number of child routers of
a parent node
Lm: Depth of the network
ZigBee defines Cm“≥ Rm, so that at least Cm“-Rm
ZigBee devices can connect to a ZigBee router. A
parent device utilizes Cm, Rm, and Lm to compute a
parameter called Cskip, which is used to compute
the size of its children’s address pools. The Cskip
at depth d is computed as follows.
ì
ï
1 + C m × (Lm - d - 1),
ï
ï
L -d -1
C
d) = ï
í
(
1 + C m - Rm - C m × Rm m
skip
ï
,
ï
ï
1 - Rm
ï
î
if
Rm = 1 (a )
otherwise(b )
Address assignment starts from the ZigBee
coordinator. It would first see its address and
depth to 0. If a parent node at depth d has an
address Aparent the nth child router is assigned
t o a d d r e s s Aparent + (n - 1) * C
(d ) + 1
skip
th
and n child end device is assigned to address
Aparent + Rm * C
(d ) + n . An example of
skip
ZigBee network address assignment was shown
in Figure 11. In this example, the ZigBee coordinator assigns Cm = 6, Rm = 4, and Lm = 3. The
Cskip value can be calculated by above equation
and the result is 31. The addresses of the first to
third child router of the coordinator were 0 + (11)31+1=1, 0 + (2-1)31 + 1 = 32 and 0 + (3-1)31
+ 1 = 63. The addresses of the two devices of the
coordinator were 0 + 431 + 1 = 125 and 0 + 431
+ 2 = 126.
The ZigBee Cluster Label
K.K. Lee et al. used ZiCL (Lee et al., 2006) to
improve the shortcoming of the AODV (Perkins
et al., 1999) that has higher routing overhead produced in route discovery phase. ZiCL divides the
ZigBee topology into several logical clusters. A
cluster consists of a clusterhead and some cluster
members. A clusterhead represents a cluster and
81
Data Communications Inside Vehicular Environments
Figure 11. An example for address assignment
cluster members are grouped into a cluster with
a clusterhead. Each cluster has a unique cluster
label that is assigned to each clusterhead. Some
rules must be confirmed for forming a cluster:
•
•
•
•
•
Only the coordinator or routers can generate a logic cluster.
The coordinator must be a clusterhead.
Routers with even depth value can be
clusterheads.
Routers with odd depth value would join
their parent’s cluster.
End devices would join their parent’s
cluster.
To follow the rules, the network will form several clusters. Figure 12 shows a Cluster Labeled
network. Each router node has a routing table (RT)
and a route discovery table (RDT). The address
information of Cluster Label is stored in RT and
route discovery entries are stored in RDT for the
original destination node address. A 16-bits address in ZigBee network is assigned by the ZigBee
specification (Zigbee Alliance, 2006). In Figure
82
12, node Q will send data to node J that node Q
is the source node and node J is the destination
node. First, node Q sends a RREQ packet with
the destination address of node J. The neighbor
nodes of node Q receive an RREQ packet and
rebroadcast it to the network until the RREQ
packet reaches to node J. When intermediate
nodes receive the RREQ packet, they would add
an entry for the Cluster Label 0x0002 in their RT
and add an entry for destination address 0x002C
in their RDT. After node J receives the RREQ
packet, node J would forward the RREP packet
along with the reverse path created by the RREQ
packet. The intermediate node H does not add the
Cluster Label in its RT because the address of the
node H is equal to the destination node’s Cluster
Label 0x0002. Node H can send data packets
through the intra-routing. When node B and node
A receive the RREP packet, they make their routing entries active and forward the RREP packet to
node F. Node F receives the RREP packet and it
has information of adjacent node Q. Node F sends
the RREP to node Q. Finally, node Q establishes
a route for Cluster Label 0x0002. At the same
Data Communications Inside Vehicular Environments
Figure 12. The ZiCL network
time, node Q sends a RNOT packet to notify its
clusterhead G about the Cluster Label 0x0002
information. Node G gets the RNOT packet then
it uses the Cluster Label Broadcasting to broadcast
the RUPT packet to share the routing information
with node T and node S. Node T and node S can
maintain the routing entry for the Cluster Label
0x0002. If node T or node S has child nodes that
want to send data to the destination node J, the
routing path will not be established. The child
nodes of the node T or node S can use the cluster
label information in the RT. The nodes can save
power and send data packet faster.
Shortcut Tree Routing in
ZigBee Networks
In the cluster-tree topology of the ZigBee network,
the routing path used by a tree-based routing protocol may be too long. If the destination node is
near the source node in the cluster-tree network,
the source node must pass packets to its node
parent to the destination node. Figure 13 (a) is
an example of the tree routing. The source node
sends the data packet to destination. The data
packet from the source node goes up to root node
following the parent node, and goes down to the
destination node. The data packet needs 4 hops
to reach the destination node. Taehong Kim et
al. proposed the shortcut tree routing (Kim et al.,
2007) to improve the shortcomings of the ZigBee
tree routing. Figure 13 (b) shows the concept of
the shortcut tree routing, where the source node
can send data packets directly to the destination
node. In this way, just one hop is required to reach
the destination node. The shortcut tree routing can
overcome the routing overhead of the tree routing
algorithm. The shortcut tree routing algorithm
basically follows the ZigBee tree routing algorithm with the neighbor table which is defined
in ZigBee specification.
The shortcut tree routing algorithm first
chooses a node from the neighbor table to be the
next hop node. It computes the remaining hop
counts from the next node to the destination for
all the neighbor nodes, including parent and child
nodes. In the neighbor table, it would choose the
next hop node that can reduce the routing cost.
In Figure 13 (b), it shows that all of the neighbor
nodes of the remaining hops to destination node
were computed. In Figure 13 (b), the source node
transmits data packets to the destination node di-
83
Data Communications Inside Vehicular Environments
Figure 13. Routing protocols
rectly if the route cost is minimized. The ZigBee
tree routing always transmits data packets to the
parent node. However, the shortcut tree routing
can be used to find a low cost route to save power
and efficiently transmit data packets.
applicaTions oF Zigbee
IEEE 802.15 standards have defined three protocols of low cost wireless communications,
including Bluetooth (802.15.1), UWB (802.15.3),
and ZigBee (802.15.4) that can be used to perform automotive functions inside a vehicle. The
comparisons among them are listed in Table 1.
These wireless technologies can be applied in
entertainment devices, handsets, intelligent key,
A/C operation and steering wheel inside vehicles.
Bickel surveyed state-of-the-art technology in
wireless communication technology within vehicles, as well as between vehicles (Bickel et al.,
2006), and pointed out that although information,
telematics, and mobile commerce are the most
prominent application areas for Bluetooth, WiFi,
and WiMax, the fact that there are many different technologies of wireless networks in vehicles
84
should stimulate the market’s growth when the
market matures. Hence, these technologies, such
as ZigBee, are offering automakers and their suppliers many possibilities to enhance the potential
of their products in the future.
Next, we will focus on the technology of
ZigBee for in-vehicular environments. Tsai et
al. (2007) reported the results of a ZigBee-based
case study conducted in a vehicle. According to
their results of the experiments and measurements,
ZigBee was illustrated to be a viable and promising
technology for implementing an intra-car wireless
sensor network. According to Table 5.2, Bluetooth
for voice transmission is better than ZigBee due
to a lager link bandwidth provided. However,
the simulation results proposed by Wang et al.
demonstrate that ZigBee can support a limited
range of voice services (Wang et al., 2008). From
their experimental results, two directly connected
ZigBee nodes can support up to three voice over
IP (VoIP) and 17 half-duplex push-to-talk (PTT)
conversations.
Data Communications Inside Vehicular Environments
Table 1. Comparison among Bluetooth, ZigBee, and UWB (Akingbehin et al, 2005)
Range
Bluetooth
ZigBee
UWB
10m
10m
<10m
Chip Price
$5
$2
$1
Data Rate
Medium
Low
High
Throughput
Medium
Low
High
Interference
Good
Good
Excellent
Media
Voice/Data
Data
Video/Radar
SIG
Consortium
Alliance
Forum
Data Payload
2744
104
Evolving
TxPower
1 mW
< 1 mW
200 µW
Mode
FHSS
DSSS
DS, MBOA
Frequency
2.4 GHz
.8, .9, 2.4 G
3.1-10.6 G
Channels
23 or 79
1, 10, or 16
Evolving
Error Correct
8-bit, 16-bit
16 CRC
Evolving
Security
Good
Good
Excellent
Topology
Star
Star, Mesh, Tree
Peer-to-Peer
# of nodes
7, or more
65534
Evolving
Link BW
1 MHz
20-250 KHz
120M-1GHz
implemenTaTion oF Zigbee
A transceiver is a combination of transmitter and
receiver in a single package. In a radio transceiver,
the receiver is silenced while transmitting. An
electronic switch allows the transmitter and receiver to be connected to the same antenna, and
prevents the transmitter output from damaging
of the receiver. ZigBee chip vendors typically
sell integrated radios and microcontrollers with
60K ~ 128K bytes flash memory, such as the
Maxstream Xbee, the MeshNetics ZigBit and the
CEL ZFSM-100 as shown in Figure 14. Radios
were also used stand-alone with any processors
or microcontrollers. Generally, the chip vendors
also offer the ZigBee software stack, although
independent ones are also available.
The RF transceiver is just one component in
a ZigBee platform solution. A processing device,
such as an MCU, is required to complete the entire
solution by housing the IEEE 802.15.4 MAC and
ZigBee software. A typical ZigBee protocol stack
implementation needs a flash memory from 64K
to 96K bytes. Based on the requirement of applications, there are several special functions, such
as flash memory size, ADC support, GPIO and
operating voltage, need to be considered.
The implemented platform is an autonomous,
Figure 14. ZigBee modules
85
Data Communications Inside Vehicular Environments
Figure 15. The implemented ZigBee platform block diagram
lightweight wireless communication and computing platform based on MaxStream Inc. Xbee
radio module and a microprocessor. The platform
has no integrated sensors, since individual sensor configurations are required depending on
the application. Instead, through predetermined
connector, the platform can be used with various
serial devices, such as digital/analog sensors and
SPI compatible devices.
Figure 15 shows an implemented ZigBee system
block diagram, where Ateml Atmega64L is used
as the system microcontroller. The Atmega64L is a
Figure 16. ZigBee platform implementation
86
high performance 8 bit RISC microcontroller with
64K bytes The peripheral of Atmega64L contains
two 8 bit timers, 8-channel 10-bit ADC, dual programmable serial USARTs and Master/Slave SPI
serial interface.
For the IEEE 802.15.4 transceiver chip selection, we used a MaxStreem incorporated product,
the Xbee OEM RF module. The module of Xbee
supports two operation modes:Transparent mode
and Application Programming Interface (API)
mode. The Xbee module operates in transparent
mode defines a set of AT command for controlling
Data Communications Inside Vehicular Environments
Table 2. Components of implemented platform
Part Type
Designator
Footprint
Part Type
Designator
Footprint
Part Type
Designator
Footprint
0.1uF
C13
402
4.7uF/16V
C14
0805C
6.8uH
L2
C3-Y1.5R
0.1uF/16V
C17
402
10uF/10V
C15
0805C
DB9
CON1
DB-9/M
0.1uF/16V
C20
402
10uF/10V
C16
0805C
DCJACK
J5
DCJACK
22pF/50V
C23
402
104p
C2
0805C
1N4148
D1
DS
400K/1%
R10
402
10uF/10V
C21
0805C
AVR_ISP
Jtag1
FKV10SN
10K
R8
402
10uF/10V
C22
0805C
CON10
J1
IDC-10
100K/1%
R9
402
104p
C3
0805C
CON10
J2
IDC-10
0.1uF/25V
C10
0603C
0.1u/16V
C4
0805C
JUNPER
J4
IDC-3
0.1uF/25V
C11
0603C
10uF/10V
C5
0805C
CON6
J3
IDC-6
0.1uF/25V
C18
0603C
20P
C6
0805C
10uH
L1
L2520
1uF/10V
C19
0603C
20P
C7
0805C
JUMPER
JP2
sip2
0.1uF/25V
C8
0603C
GREEN
LED1
0805LED
JUMPER
JP3
sip2
0.1uF/25V
C9
0603C
GREEN
LED2
0805LED
MAX3232
U3
SO16
27R
R11
0603R
RED
LED3
0805LED
RT8008
U2
SOT-25
27R
R12
0603R
47
R1
0805R
ATMEGA64L
U1
TQFP-64
0R
R6
0603R
47
R2
0805R
8.00MHz
XTAL1
X1
0R
R7
0603R
47
R3
0805R
XBEE
U4
XBEE
0.1u/16V
C1
0805C
10K
R4
0805R
10uF/10V
C12
0805C
4.7K
R5
0805R
the internal ZigBee protocol stack. Via the AT command, the user can quickly establish an application
without the detailed knowledge of ZigBee protocol
stack. In the API mode, the Xbee module acts as
a pure IEEE 802.15.4 RF module. Only a serial
communication protocol is defined in the API
mode. Hence, the full ZigBee stack is required to
be implemented in applications and the protocol is
used to communicate with the Xbee module.
In Figure 16, it shows a ZigBee platform
implementation. The implemented system has two
power sources: mains-power and battery-power.
The power source can be selected from jumper 3.
LED3 is a power indicator. LED2 and LED1 are
connected to GPIO port C of Atmega64L. These
two LEDs can be utilized for general purpose.
The system reserves a 8-bit GPIO port and a 8-bit
ADC connector for extensions. The SPI is also
reserved for changing other IEEE 802.15.4 radio
transceivers, such as AT86RF230.
Table 2 lists the components of the implemented platform. Figure 17 is the platform circuit
diagram which was layout by Protel 99SE. The
connection between MCU and XBee is via the
UART1 of MCU. Regarding the power source,
there are two sources (main and battery power)
that can be switched via jumper 4.
summary
The chapter introduced the standard of low rate
WPANs to be called ZigBee. Two types of devices,
FFD and RFD, are discussed. We have known that a
FFD can communicate with RFDs and other FFDs,
while a RFD can only communicate with a FFD.
87
Data Communications Inside Vehicular Environments
Figure 17. Circuit diagram of the implemented platform
In ZigBee physical layer, ZigBee follows IEEE
802.15.4 standard and operates in unlicensed RF
worldwide (2.4GHz global, 915MHz Americas
or 868 MHz Europe). A superframe contained
an active portion and an inactive portion is used
in the MAC layer of ZigBee. The active portion
includes CAP and CFP. In the inactive partition,
the coordinator can enter sleep mode to save its
power. Three main topologies of ZigBee are star,
mesh, and tree. However, ZigBee is successfully
produced into a low-cost controller applied for
automotive applications, including vehicle control
and status monitoring.
88
reFerences
Akingbehin, K. (2005). Wireless communications
for intra-vehicle use (Wireless harnesses). Institute for Advanced Vehicle Systems, University of
Michigan-Dearborn, Dearborn, MI.
Bickel, G. S. (2006). Inter/intra-vehicle wireless
communication. Retrieved from http://userfs.cec.
wustl.edu/~gsb1/index.html
Geer, D. (2005). Users Make a Beeline for ZigBee
Sensor Technology. Computer, 16–19.
Kim, T., Kim, D., Park, N., Yoo, S., & Lopez, T. S.
(2007). Shortcut tree routing in ZigBee networks.
In . Proceedings of ISWPC, 07, 42–47.
Data Communications Inside Vehicular Environments
Lee, K. K., Kim, S. H., Choi, Y. S., & Park, H.
S. (2006). A mesh routing protocol using cluster
label in the ZigBee network. In Proceedings of
Mobile Ad-hoc and Sensor Systems (MASS), (pp.
801-806).
Perkins, C. E., & Royer, E. M. (1999). Ad-hoc
On-demand distance vector routing. In . Proceedings of WMCSA, 99, 90–100.
The, I. E. E. E. 802.15.4 WPAN Group. (2009).
Retrieved from http://www.ieee802.org/15/pub/
TG4.html
89
90
Chapter 6
Wireless Access in
Vehicular Environments
Tzong-Jye Liu
Feng Chia University, Taiwan, R.O.C.
Ching-Wen Chen
Feng Chia University, Taiwan, R.O.C.
absTracT
The IEEE 1609 standards define communication for wireless access in vehicular environment (WAVE)
services, which enable vehicle-to-vehicle, vehicle-to-roadside, as well as vehicle-to-infrastructure communications. The standard consists of four parts, which are briefly described in this chapter. IEEE 1609.1
describes the WAVE resource manager which specifies the wireless access method in a WAVE environment
and allows a remote manager application to establish connection with a resource command processor on
an on-board unit. IEEE 1609.2 defines several secure message formats to process messages for WAVE
system. The standard covers methods for securing WAVE management messages and application messages, which protects messages from attacks such as eavesdropping, spoofing, alteration, replay, and
linkable information to unauthorized parties. IEEE 1609.3 defines network services for WAVE systems,
whose network services operate at the network and transport layers of the OSI model and support both
the IPv6 traffics and the WAVE short message services. IEEE 1609.4 describes WAVE multi-channel
operations. It specifies the functions of MAC sublayer management entity and WAVE MAC with channel
coordination. The multi-channel operation provides an efficient mechanism that controls the operation
of upper layer across multiple channels.
inTroducTion
The IEEE 1609 standards (IEEE 1609.1TM, 2006;
IEEE 1609.2TM, 2006; IEEE 1609.3TM, 2007;
IEEE 1609.4TM, 2006) define communication for
DOI: 10.4018/978-1-60566-840-6.ch006
wireless access in vehicular environment (WAVE)
services, which enable vehicle-to-vehicle, vehicleto-roadside, as well as vehicle-to-infrastructure
communications. The standard consists of four
parts, which are briefly described in this chapter.
IEEE 1609.1 (IEEE 1609.1TM, 2006) describes the
WAVE resource manager which specifies the wire-
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Wireless Access in Vehicular Environments
less access method in a WAVE environment and
allows a remote manager application to establish
connection with a resource command processor on an on-board unit. IEEE 1609.2 (IEEE
1609.2TM, 2006) defines several secure message
formats to process messages for WAVE system.
The standard covers methods for securing WAVE
management messages and application messages,
which protects messages from attacks such as
eavesdropping, spoofing, alteration, replay, and
linkable information to unauthorized parties. IEEE
1609.3 (IEEE 1609.3TM, 2007) defines network
services for WAVE systems, whose network
services operate at the network and transport layers of the OSI model and support both the IPv6
traffics and the WAVE short message services.
IEEE 1609.4 (IEEE 1609.4TM, 2006) describes
WAVE multi-channel operations. It specifies the
functions of MAC sublayer management entity
and WAVE MAC with channel coordination. The
multi-channel operation provides an efficient
mechanism that controls the operation of upper
layer across multiple channels.
This chapter describes the standards for the
wireless access in vehicular environment (WAVE).
The IEEE 1609 standards define communication for WAVE services, which enable vehicle to
vehicle (V2V), vehicle to roadside, and vehicle
to infrastructure (V2I) communication. The communication system integrates the information of
engine, gearing, brake, roadside unit, and provides
safety services for drivers. In the standard, the
specification of the physical layer is defined in
IEEE 802.11p and the communication protocol for
WAVE network service is IPv6. This chapter also
describes the four parts of the IEEE 1609 standards.
Section 6.2 describes IEEE 1609.4 (2006), the
functions of MAC sublayer management entity
(MLME) and WAVE MAC with channel coordination are introduced. Section 6.3 describes the
IEEE 1609.3 (2007), the WAVE network services
for WAVE systems are introduced. Section 6.4
describes the IEEE 1609.2 (2006), the secure
message formats and the process of the secure
messages for DSRC/WAVE system are defined.
Section 6.5 describes the IEEE 1609.1 (2006), the
WAVE resource management is introduced.
waVe mulTi-channel
operaTions
IEEE 1609.4 (2006) describes WAVE multichannel operations. It specifies the functions of
MAC sublayer management entity (MLME) and
WAVE MAC with channel coordination. Multichannel operation provides an efficient mechanism
that controls the operation of upper layer across
multiple channels. The channel coordination
enhances the mechanism defined in the MAC of
IEEE 802.11 and interacts with IEEE 802.2 logical
link control and IEEE 802.11p PHY.
WAVE devices (on-board units or roadside
units) provide an architecture that supports a single
control channel (CCH) and multiple service channels (SCHs). The control channel is for transmitting WAVE short message and announcing WAVE
services. The service channels are for interactions
and transmissions between applications. WAVE
standard uses the specification of the PHY in IEEE
802.11 and revises to IEEE 802.11p.
The services defined in IEEE 1609.4 (2006) are
for managing the channel coordination and supporting MAC service data unit (MSDU) delivery.
The services include the channel routing, user
priority, channel coordination and MAC service
data unit transfer. In the following of this section,
we will describe these four services.
The channel routing
WAVE supports both the WAVE short message
(WSM) and IP datagram transfer. When an MSDU
is passed from the LLC to the MAC, the MAC
determines whether the MSDU is a WSM or an
IP datagram by checking the EtherType field in
the MSDU. If the value of this field is 0x86DD,
an IPv6 header follows. If the value is 0x88DC,
91
Wireless Access in Vehicular Environments
a WAVE short message protocol (WSMP) header
follows. In the following of this subsection, the
channel routing for WSMP data and IP datagram
is described.
Channel Routing for WSMP Data
As is shown in Figure 1, WSMP header contains
the channel, power level and data rate associated
with the data packet.
The scenario of channel routing for WSMP
data is as follows: First, WSMP data is passed
from the LLC to the MAC. Then, MAC routes
the packet to a proper queue according to the
channel number contained in the WSMP header.
If the channel number does not corresponding to
the control channel number or the current service
channel number, it is invalid. The data packet is
discarded if the channel number is invalid.
Routing for IP Datagram
The transmitter profile must be registered to the
MAC sublayer management entity (MLME) before initializing IP datagram exchanges. The transmitter profile contains a service channel number,
power level, data rate and the adaptable status of
power level and data rate. At any given time, only
one transmitter profile may be active.
Then, IP datagram is passed from the LLC to
the MAC; and the MAC routes the packet to a
Figure 1. Portion of WSMP header used to control
PHY (IEEE 1609.4TM, 2006)
92
data buffer that corresponds to the current service
channel. If there is no transmitter profile registered
or the transmitting WAVE device is not a member
of any WAVE Basic Service Set (discussed in
6.3.2), the datagram is discarded.
user priority
IEEE 802.11e Enhanced Distributed Channel Access (EDCA) mechanism is used to contend for
accessing medium. The MAC buffers the data by
mapping its user priority to access category index
(ACI) is defined in IEEE 802.11.
The general architecture of prioritized access
on one channel for the data transmission is shown
in Figure 2.
When MAC receives a MSDU and completes
the channel routing process, MAC maps its user
priority to access category index. Each access
category has a unique and independent channel
function. The channel function is used to pick a
data packet from the access category to compete
access right. Then, the package being picked
Figure 2. Prioritized access for data transmission
on one channel. (IEEE 1609.4TM, 2006)
Wireless Access in Vehicular Environments
Figure 3. Sync interval, guard interval, CCH interval, SCH interval (IEEE 1609.4TM, 2006)
decides which packet gets the access right according to its back-off. The packet with the smallest
back-off gets the access right.
•
•
channel coordination
Now, we would describe the channel coordination function, which is done mainly according to
the MAC layer synchronizing operation. Based
on the synchronization operation, packets could
be sent from MAC layer into wireless channel.
Shown in Figure 3 is the sync interval, it contains
CCH interval and SCH interval components. A
buffering time interval, called Guard Interval, is
used to synchronize various devices (for example,
synchronization of their time).
For WAVE devices, Coordinated Universal
Time (UTC) is used as the reference time. The
length of the sync interval is dot4SyncInterval;
and sync interval starting at the instant the time
synchronization function timer modulo dot4SyncInterval is zero. All WAVE devices shall monitor
the CCH during the CCH interval.
mac service data unit Transfer
In this subsection, we describe the MAC service
data unit transfer defined in IEEE 1609.4 (2006).
As it was shown in Figure 4, the data transmission
processing flow is as follows:
•
IP or WSM requests for data transmission.
LLC passes an MSDU to MAC; and the
channel router in MAC distinguishes
between IP and WSMP by checking
EtherType field.
◦
If the value of EtherType is WSMP,
the channel router assigns the MSDU
to the access category (AC) based on
the channel number and the user priority in the WSMP header.
◦
If the value of EtherType is IP, the
channel router allocates the service
channel, access category and user priority to the MSDU. Then, the channel
router puts the MSDU to the channel
buffer according to its user priority.
◦
When the data unit wins the contention on the current channel,
◦
If the data unit is WSM, the packet
is transmitted by using the transmit
power and the data rate recorded in
the header.
◦
If the data unit is IP datagram, the
packet is transmitted by using the
transmit power and the data rate
stored in the registered transmitter
profile.
The value of the power level and the data
rate is set in TXVECTOR. TXVECTOR is
a set of parameters that the MAC provides
93
Wireless Access in Vehicular Environments
Figure 4. Data transmission processing flow (IEEE 1609.4TM, 2006)
•
•
•
•
PHY to transmit the data unit. A clear channel is reported by sending an IDLE command from PHY to MAC.
MAC sends a TXVECTOR command for
setting; and a confirmation is replied after
PHY completes the setting. PHY completes the setting according to the power
level and the data rate.
Data is exchanged between PHY and MAC
through a series of actions.
A confirmation is replied after PHY completes the transmission.
At the end, LLC receives an indication
from MAC.
Now, consider the data transfer in the control
channel. WSMs conforming to the WSMP can
be exchanged directly; and the transmission of IP
datagram is not permitted. Now, let us consider
the data transfer in the service channel. In order
to initiate communications on a service channel, a
roadside unit or an on-board unit transmits WAVE
announcement action frames on the control channel to advertise offered services available on that
service channel. An on-board unit receives the announcement on the control channel and generally
94
establishes communications with the provider on
the specified service channel.
waVe neTwork serVices
IEEE 1609.3 (2007) defines network services for
WAVE systems. WAVE network services operate
at the network and transport layers of the OSI
model, supporting a high data rate, low latency
communication between WAVE devices. The
WAVE network services support both the IPv6
traffics and the WAVE short message (WSM)
services.
overview
The WAVE network services provide addressing
and routing services in a WAVE system. It operates
at the network and transport layers and supports
wireless connectivity among vehicle-based devices. It also supports connectivity between fixed
roadside devices and vehicle-based devices. The
wireless communication is based on the 5.9 GHz
DSRC/WAVE mode.
Wireless Access in Vehicular Environments
Figure 5. WAVE protocol stack (IEEE 1609.3TM, 2007)
The scope of IEEE 1609.3 (2007) standard is
shown in Figure 5. The WAVE system supports
both IP and non-IP applications. The communications for non-IP based applications are based
on the WAVE short message protocol (WSMP)
and the IP based applications are based on IPv6.
In IEEE 1609.3 (2007), the standard defines the
management information base (MIB) of the WAVE
management entity (WME). It also specifies the
functions of LLC, UDP/TCP and WAVE short
message protocol.
The WAVE protocol stack consists of data
plane and management plane.
•
Data plane: The data plane consists of
the communication protocol and hardwares for data transfer. The data plane of
the WAVE network services must support
UDP protocol; and the TCP protocol is optimal. The WAVE network services shall
support the IPv6 protocol and the Logical
Link Control (LLC) protocol as specified in IEEE 802.2. The data plane of the
WAVE network services also supports the
WAVE short message. The WAVE short
message can be delivered to multiple destinations. The implementation of the WAVE
•
short message protocol has to support the
forwarding function.
Management plane: The management
plane of the WAVE network services
provides the following services: application registration, WAVE Basic Service
Set (WBSS) management, channel usage
monitoring, IPv6 configuration, Received
Channel Power Indicator (RCPI) monitoring, and the Management Information Base
(MIB) maintenance.
About the communication protocol of the
WAVE system, we can go through the channel type
and two WAVE-supported protocols for explanation. The WAVE-supported protocol contains both
the WAVE short message protocol and standard
IPv6 protocol.
•
Channel types: The WAVE system supports two types of channels: the control
channel (CCH) and the service channel
(SCH). In a WAVE system, there is only
one control channel and multiple service
channels.The control channel is reserved
for system control message and short, but
high-priority applications. The service
95
Wireless Access in Vehicular Environments
•
•
channels support general purpose data
transfer applications.
WAVE short message protocol (WSMP):
The WAVE short message protocol is designed for optimized operation in the
WAVE environment. The WAVE short
message may be sent on both the control
channel and the service channels. In a
WAVE system, the WAVE short message
is used for message transmission. It also allows application to directly control physical layer parameters, such as the channel
number and/or the transmitter power. It is
designed to minimize to channel capacity.
Based on the Provider Service Identifier
(PSID), the WAVE short message may be
sent to the correct destination.
Standard Internet Protocol (IPv6): The
transmission based on the standard IPv6
can be only used on the service channels
(SCH). The protocol is for generic applications and network services.
nel and distributes this information by using the
control channel.
WBSS used role-based for controlling regardless of users’ identity, restricting users’ access
rights. Applications could integrate in the priority
designing, for example if two applications requesting for the accessing of the same channel, WAVE
management entity would give the access according to the application’s access level. The access
rights of lower layer are decided and controlled
by MAC layer.
Data transfer by an application can be operated
both with a WBSS and without a WBSS.
•
wave system operations
In a WAVE system, a WAVE Basic Service Set
(WBSS) is established to support data traffics
between applications. A set of cooperating WAVE
stations consists of a single WBSS provider and
none or multiple WBSS users. Applications based
on the WAVE short message protocol may initiate
a WBSS to allocate a service channel, but this is
not required since the WAVE short messages may
be exchanged on the control channel.
We would move on to the communication
concept of WAVE. Applications themselves can
decide whether WBSS would be employed. When
WBSS is not used, WSMs could use only CCH.
If an application exchanges data with a WBSS,
it may send the information by using WAVE
short message protocol or IPv6 protocol on the
service channel. A WAVE device may announce
a WAVE Basic Service Set on the service chan-
96
•
Operation without a WBSS: Operation
without a WBSS uses WSMP to exchange
data on the control channel. A source application composes the WAVE short message
data and addresses it to the broadcast MAC
address. Then, the application selects appropriate radio channel information to
control the transmission, and requests the
WSMP for delivery the message. A receiving device accepts the packet and passes
it up to the protocol stack. The WSMP
protocol stack delivers it to the registered
application(s), based on PSID. Then, the
receiving application knows the address
of the provider device, and may exchange
data on the CCH if desired.
Operation with a WBSS: There are
two types of WBSS: persistent and nonpersistent. A persistent WBSS may support Internet access; and a non-persistent
WBSS may support on-demand services.
A persistent WBSS is announced during
CCH interval and the usage of the persistent WBSS will offer an ongoing service
to any devices that come into the range
of WBSS. Non-persistent WBSS is announced only on initiation. The usage of
the non-persistent WBSS will support an
on-demand service.
Wireless Access in Vehicular Environments
WAVE applications offer services to potential
user applications by announcing their air interface
via a WAVE service information element (WSIE).
WAVE service information element is inside a
WAVE announcement frame. The process of creating a WSIE and transmitting it is initiated when an
application request to initiate a WBSS and offer
services. On receiving of the WME application
request, the WME starts the WBSS.
Upon receiving of the notification of the WBSS
initiation from the WME, an application is free
to generate data packets (WSM or IPv6 packet)
for transmission on the service channel. Any received packets destined for the application will
be delivered to the application via the WSMP or
IPv6 stack. The WBSS remains active at the local
device until it is ended.
The WME would terminate a WBSS if any of
the following reason holds.
•
•
•
All applications have completed their activities on the WBSS. The WBSS is no
longer being used by locally-registered
applications.
A higher priority application participates
the WBSS and induces the conflict.
If the lower layer indicates that the service
channel is idle, a user device may terminate its participation in the WBSS.
waVe securiTy serVices
IEEE establishes IEEE 1556 to develop the standard for WAVE security service. Later, the standard
was renamed as IEEE 1609.2 (2006). The main
goal of this standard is to define the secure message
formats to process messages for DSRC/WAVE
system. The standard covers methods for securing
WAVE management messages and application
messages. The exception of vehicle-originating
safety messages and the administrative functions
for the core security functions are also described.
The standard protects messages from attacks such
as eavesdropping, spoofing, alteration, replay, and
linkable information to unauthorized parties.
The standard specifies the secure message
format by using a presentation language based
on TLS (IETF RFC 2246). The statement of the
presentation language includes variable names,
data types and functions. Variable names are all
lowercase. Multiple words name is indicated by
underscores. Data types begin with an uppercase
letter; they may contain a mixture of upper and
lowercase.
secured messages
Many of the applications discussed in this standard
use the secured message format in Figure 6. The
generic message format includes the protocol
version and the type. The protocol version is the
current version of the protocol. The type contains
the type of the message; it tells the receiver how
to interrupt the received message. The type value
0 denotes unsecured, the type value 1 denotes
signed, and the type value 2 denotes encrypted.
Type values from 240 to 255 are reserved for
private usage.
The message types are as follows (IEEE
1609.2TM, 2006):
•
•
•
•
SignedMessage, ToBeSignedMessage,
and MessageFlags types: These types are
used when the type field is signed.
S i g n e d W S M & To B e S i g n e d W S M
types: The ToBeSignedWSM is the variant of the ToBeSignedMessage except
that the application field is omitted. The
SignedWSM types is also the variant of
the SignedMessage, expect that the signed
data is a ToBeSignedWSM structure.
PublicKey, PKAlgorithm, & SymmAlg
orithm types: The PublicKey structure is
for encoding a public key and identifies the
algorithm that public key is used.
ECPublicKey type: An ECDSA or ECIES
public key is specified.
97
Wireless Access in Vehicular Environments
Figure 6. Secured message format (IEEE 1609.2TM, 2006)
•
•
•
•
•
•
98
CertID8 & CertID10 types: These types
are used to identify a certificate. The
CertIDx, x is 8 or 10, for a given certificate
is calculated by the SHA-256 hash function and the low-order x bytes of the hash
value is output.
The ApplicationID & FullySpecifiedAp
pID types: The security services use these
types to determine whether a message may
legitimately address a given application.
Time64 & Time32 types: Time64 is a
64-bit integer. It is encoded in big-endian
format and gives the number of microseconds. Time32 is a 32-bit integer. It is also
encoded in big-endian format and gives the
number of seconds.
SignerInfo type: The receiver uses
SignerInfo structure to determine which
keying material is used to authenticate the
message.
Signature type: The actual signature is
contained in the signature field.
ECDSASignature type: The ECDSA signatures are performed.
•
•
•
•
•
EncryptedMessage, EncryptedCont
entInfo, & RecipientInfo types: The
EncryptedMessage type is supported to encrypt a message to one or more recipients
using the recipients’ public keys.
ECIESNISTp256EncryptedKey &
AESCCMCiphertext types: The
ECIESNISTp256EncryptedKey type is
used to transfer the symmetric key. The
symmetric key is encrypted using ECIES
as specified in IEEE Std 1363a-2004.
WAVECertificate, ToBeSignedWAVECe
rtificate, CertSpecificData, SubjectType,
& CRLSeries types: The standard supports many certificate types. The certificate
type corresponding to different roles that
signers can play in the system. All these
certificates use the same structure.
WAVECRL,ToBeSignedCRL, CRLType,
and IDAndDate types: These types are
used for certificate revocation list.
WAVE Certi fi ca teReq u es t & WAV
ECertificateResponse types: The
WAVECertificateRequest type is
used
to
request a WAVECertificate. The
Wireless Access in Vehicular Environments
•
•
•
WAVECertificateResponse is used to return a WAVECertificate.
GeographicRegion & RegionType types:
These types are for defining region.
The 2DLocation & 3DlocationAndConfi
dence types: 2Dlocation is used to define
validity regions using in the certificates.
3DlocationAndConfidence is used to identify the transmission locations and includes
a confidence field.
Certificate scopes: This type defines the
scope of the certificate.
signed messages
When an entity wants to create a signed message
for transmission, it has to contain the following
information and services:
•
•
•
•
•
A key for signing.
The certificate associated with the signing
key.
A random number generator.
A cryptographic implementation.
The current position and time; and the estimated error in that position and time.
Then, the entity signs the message by taking
the following steps:
1.
2.
3.
Fill the ToBeSigned Message structure
and encode it as the unsigned value octet
string.
Sign the unsigned message value.
Create and encode the signed message
value.
An entity may receive a signed message. The
signed message contains:
•
•
•
The recently received message.
The root certificate.
The revoked certificate.
The steps to process the signed message are
as follows:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Decode the received octet string.
If the type of the application field in the
signed message is not correct, discard the
message.
Check and ensure that the message is not a
replay message.
If the transmission location is included in the
signed message, perform the geographical
validity checks.
Use the signer digest to retrieve the certificate
from the message certificate cache.
Verify the message certificate.
Validate the certificate chain.
If needed, verify that the transmission location. Check if it is within the
GeographicRegion of the message signing
certificate.
Verify the application field in the message
consists with that in the certificate.
Verify that none of the certificates in the
certificate chain has been revoked.
Verify the signature on each certificate with
the public key from its issuing certificate.
Verify the signature on the message with
the public key from the message signer’s
certificate.
Cache any previously unseen certificates,
their associated Application IDs and associated Geographic Regions.
encrypted messages
The processes to encrypt messages are as follows.
1.
2.
3.
4.
Retrieve the certificate
Check that the recipient’s certificate has not
been revoked
Select a symmetric encryption algorithm in
the recipient’s certificate
Generate a random key for this algorithm
99
Wireless Access in Vehicular Environments
5.
6.
7.
8.
Retrieve and encode the message to be
encrypted
Encrypt the message
Create a RecipientInfo field
Create and encode the EncryptedMessage.
If an entity wants to send a signed and encrypted
message, first it creates a signed message from the
original message. Then, it creates an encrypted
message from the encoded SignedMessage.
When an entity receipts a signed and encrypted
message, first it decrypts the message. Then, it
forwards the output message to the application
for processing.
waVe resource manager
This section describes the WAVE Resource
manager, which is standardized in IEEE 1609,
specifying the wireless access method in a WAVE
environment. The proposed access method allows
a RMA (remote manager application) to establish
connection with a RCP (resource command processor) on an OBU (on-board unit) through the
RM (resource manager) of a RSU (roadside unit).
A RM in WAVE takes the role of a multiplexer,
directing the information exchange between RMA
and RCP. WAVE specification aims at creating a
completely interoperable communication environment through which vehicles and RSUs could
transfer data effectively.
wave architecture
As shown in Figure 7, a RCP resides as a component in an OBU, while the RM can be a component
of either the OBU or a RSU. RM and a resource
manager application communicate via the security
tunnel in the between. RM, as a the multiplexer
in the WAVE framework, allows each RMA to
perform end-to-end communicate with RCPs on
OBUs through itself, while the link between RM
and RCP is established through wireless (IEEE
802.11p), which might be insecure.
When a RM of a RSU sends respective message to a RCP on an OBU, the command would
be executed by the RCP. Should the need arise; it
could response to the requesting RMA through the
RM. Therefore in Figure 7, RM provides services
for RMAs to access the memory and UIs on the
OBU, which are controlled by RCP. As shown in
Figure 7. Components addressed in IEEE 1609.1 (IEEE 1609.1TM, 2006)
100
Wireless Access in Vehicular Environments
Figure 8. Data transfer in WAVE
Figure 9. Four basic forms for services
Figure 7, if a RM resides in an OBU, this figure
thus then depicts the situation of an inter-vehicle
communication session.
wave data Transfer
As shown in Figure 8, the data transfer of RMA is
done through command and response, which itself
includes a two phase action: the encapsulation of
the information from RMA to RM containing in
the APDU (application protocol data unit), and
the command/response as a whole from RM to
RCP. The steps are detailed below:
1.
2.
3.
RM received commands from a RMA; after
confirmation and execution, the command
is send to the RCP of the OBU via IEEE
802.11p. Message from RM to RMA is
encapsulated in APDU, and those from RM
to RCP in UDP packets.
Command executed by RCP.
RCP responds the execution result as well
as other information back to RMA through
RM.
We will then talk about the data structure of
the message. When the RMA and the RM are not
in the same device, messages will be delivered in
packets, thus APDU; should they be in two stack
protocols of a single identical device, either RSU or
OBU, we would then pass it as ASDU(application
service data unit). The messaging between interfaces of different protocol layers is called SAP
(service access point).
As shown in Figure 9, there are four types of
service indicated in this specification: Request,
Indication, Response, and Conform, each service
can be in one of the following modes: Confirmed
Mode, Non-confirmed Mode, and Locally confirmed Mode (as indicated in Figure 10(a)~(c)).
application components
In application layer, there are several components:
OBU resources, RM commands and response, and
Services provided by the RM.
•
OBU resources: OBU resource covers
both Memory and User Interfaces:
101
Wireless Access in Vehicular Environments
Figure 10.Three modes for services
◦
102
OBU memory: OBU memory is divided into partitions, each further divided into addressable blocks called
pages, which are accessed by RMA
through RM command set. Since each
partition is indexed by a 16-bit integer,
the largest partition is 64k bytes. In
the same fashion, a largest page is also
64k bytes. There must exist partition 0
in an OBU memory, while additional
partitions are optional. Page 0 of partition 0 is reserved for special purpose,
and all access to this page would be
deemed invalid. OBU memory pages
come in three types: storage pages
(type 0), memory-mapped pages (type
1), and transfer pages (type 2), which
are detailed below:
▪
Storage pages (type 0): Generalpurpose pages, type 0 pages are
controlled by applications, providing RMA data storage and
retrieval.
▪
Memory-mapped pages (type
1): OBU integrates many UI devices, which are controlled via
memory-mapped pages. These
pages are treated as buffers for
devices. When a RMA want to
control a UI device, it simply
writes the data to the page of
that device. The command for
Wireless Access in Vehicular Environments
•
such action is Set User Interface
command. To get data from a
UI device, RMA executes Read
Memory Page command.
▪
Transfer pages (type 2): Transfer
pages are the interfaces between onboard equipments and
the network, and are related to
RCP-controlled external interfaces. When RMA writes data
to a transfer page, the data entry
would be sent to the interface it
was related by.
◦
User interface: User interface acts as
bridges between machine and men.
Related GUIs are introduced below:
▪
Visual display: Through which
an OBU could display message.
Acceptable colors in this specification are red, green and blue.
▪
Buzzer: Through an OBU could
notify user of important events.
▪
Enunciator: Through which an
OBU can read messages.
▪
Character readout: Through
which an OBU can display text
messages.
▪
Keypad: Through which a user
can input message.
▪
Other future GUI
RM commands and response: Command
format for RM is shown in Figure 11. Each
command is formed by 5 bytes, transferred
in sequence with the MSB of each byte
sent first. Fields in the command are explained below:
◦
Byte 1: Bit 7 is reserved; next 7 bits
form the Command ID, which is
unique for each command. For instance, the ID for Read Memory Page
is 0x10. Refer to IEEE 1609.1 (2006)
for more information.
◦
Byte 2: Bit 7 is No Response
Indicator, which, for its namesake,
indicates whether the receiver should
reply, TRUE for no and FALSE
for yes. Following 7 bits form the
Command Transaction ID, which is
set by RMA when sending command
to RCP. When replying, this ID will
be included without modification so
that RMA could identify to which
message it was responded.
◦
Byte 3~4: This field is 2-byte long,
used to indicate the length of the following Command parameter field.
◦
Byte 5~: Bytes after byte 5 is for
the parameters which RMA sends to
RCP.
◦
Commands in resource management
of WAVE are passed in the form of
a command sequence. When passing a single command, it would still
be transferred in a sequence with a
single entry. Sequences are processed
in FIFO fashion once received by the
client.
RM in WAVE would then process each
command sequence until a invalid command is met. While executing, if a FALSE
No_Response_Indicator value is met, the
RCP would need to send in a replying
response.
Shown in Figure 12 is the response format
of RM:
•
•
•
•
Byte 1: bit 7 is reserved, with the following 7 bits forming the Command ID.
Byte 2: bit 7 is unused, with the following 7
bits forming the Command Transaction ID.
Byte 3: this is the response status of RCP,
for example Command Success (0x01),
Command Failed (0x02), refer to IEEE
1609.1 for more info.
Byte 4~5: This field is 2-byte long, used
to indicate the length of the following
Response Data. Note that this field and the
103
Wireless Access in Vehicular Environments
Figure 11. Command format. (IEEE 1609.1TM, 2006)
•
following one are used only when making
reply for Read Memory Page command.
Byte 6~: Response Data
Following IDs are further specified in IEEE
1609.1 (2006):
•
•
•
•
•
•
Read Memory Page command (ID: 0x10)
Write Memory Page command (ID: 0x11)
Insert Message command (ID: 0x12)
Sleep Transaction command (ID: 0x30)
Reserve Memory Page command (ID: 0x40)
Release Memory Page command (ID: 0x41)
Figure 12. Response format. (IEEE 1609.1TM, 2006)
104
•
•
Reserve Partition command (ID: 0x43)
Release Partition command (ID: 0x44)
•
Services provided by the RM: RM takes
the role of the application layer in WAVE
by offering related services to RMA, which
are either protocol management services
or protocol data transfer service, which
we are about to detail here. Each service
has a service name in the form of RMA<SERVICE>-<ACTION>, for example
RMA-ACTIVATE-Request.
Wireless Access in Vehicular Environments
◦
Protocol
management
services: Protocol management services
cover
RMA-ACTIVATE-Request,
R M A - A C T I VAT E - R e s p o n s e ,
RMA-NOTIFY-Indication,
RMANOTIFY-Confirmation,
RMATERMINATESESSION-Indicate,
RMATERMINATESESSIONConfirmation,
RMA-DEACTIVERequest, and RMA-DEACTIVATEResponse, which
▪
Activate
request
service:
This service is named RMAACTIVATE-Request. Once the
RMA is ready to communicate
with RCP, it notifies the RMA
through the RMA-ACTIVATERequest service provided by
RM.
▪
Activate response service:
This service is named RMAACTIVATE-Response. When the
RM has completed its activation,
it gives a response to RMA.
▪
Notify indication service: This
service is named RMA-NOTIFYIndication. Once RMA is activated, it would wait for its partner. Through this service, RMA
can be informed once the RCP
of a OBU has entered the communication zone of the service
provider.
▪
Notify confirmation service:
This service is named RMANOTIFY-Confirmation. Once the
RMA received RMA-NOTIFYIndication, it would respond with
a RMA-NOTIFY-Confirmation.
▪
Terminate session indication service: Named RMATERMINATESESSIONIndication. When a transaction
is completed, RMA would
◦
send to RM a RMATERMINATESESSION-Indicate.
▪
Terminate
session
confirmation service: Named
RMA-TERMINATESESSIONConfirmation.
RM
would
notify RMA through RMATERMINATESESSIONIndicate
that
RMATERMINATESESSION-Indicate
has been received.
▪
Deactivate request service:
Named
RMA-DEACTIVERequest. When RMA wishes to
stop the operation, it would send
this service to notify RM.
▪
Deactivate response service:
Named
RMA-DEACTIVATEResponse. When RM received
R MA -DE A C T IV E -R eq u e s t ,
it would respond with RMADEACTIVATE-Response.
Protocol data transfer services:
Protocol data transfer services covered
RMA-EXCHANGE-Request,
RMAEXCHANGE-Response, and RMAEXCHANGE-Confirmation:
▪
Exchange request service:
Named
RMA-EXCHANGERequest. RMA uses to send command sequences to RCP.
▪
Exchange response service:
Named
RMA-EXCHANGEResponse. Once command sequence is sent to RCP and the response sequence is received, RM
would reply to RMA with RMAEXCHANGE-Response.
▪
Exchange confirmation service: Named RMA-EXCHANGEConfirmation. When RMA gets
the response of RM, this message
would be sent back to RM.
105
Wireless Access in Vehicular Environments
reFerences
IEEE1609.1TM (2006). IEEE Trial-Use Standard
for Wireless Access in Vehicular Environments
(WAVE) – Resource Manager.
IEEE1609.2TM (2006). IEEE Trial-Use Standard
for Wireless Access in Vehicular Environments
(WAVE) – Security Services for Applications and
Management Message.
106
IEEE1609.3TM (2006). IEEE Trial-Use Standard
for Wireless Access in Vehicular Environments
(WAVE) – Networking Services.
IEEE1609.4TM (2006). IEEE Trial-Use Standard
for Wireless Access in Vehicular Environments
(WAVE) – Multi-channel Operation.
Section 3
Location Based Services
108
Chapter 7
Introduction to Global Satellite
Positioning System (GPS)
Jenq-Muh Hsu
National Chiayi University, Chiayi, Taiwan, R.O.C.
absTracT
Understanding the right positions and directions of people and objects is a significant issue from the
ancient eras to the present. In the past, people often launched a war in order to satisfy the craving for
the dominating powers and spread their realms. In the recent, Global Satellite Positioning System (GPS)
has become the one of most popular positioning technologies. GPS can provide users precise positioning information, no matter wherever that may present their own positions. The early GPS positioning
technology has been widely used in military, marine use, until recently gradually applied into our daily
life, e.g., automotive navigation, geodesy surveying, etc. In this chapter, we will briefly introduce some
GPS issues including the origins of GPS, GPS system architecture, and related GPS applications.
inTroducTion
Understanding the right positions and directions of
people and objects is a significant issue from the
ancient eras to the present. In the past, people often
launched a war in order to satisfy the craving for the
dominating powers and spread their realms. When
the army is marching during the fighting, it does
not allow the army to get lost in the woods or the
dense fog. It needs a method or a tool to offer the
army to navigate and move to the right place.
DOI: 10.4018/978-1-60566-840-6.ch007
South Pointing Chariot (South Pointing Chariot,
2009) invented in the ancient Chinese civilization
is a complex-gearing mechanism without using
the magnet to point the same direction while the
chariot is around in any movement. South Pointing Chariot only moves on the ground, it can not
be used to point the right direction whiling sealing
due to the no effect of gearing operation on the sea.
The other usual positioning and navigating tool is
the compass.
The compass has the magnet which can interact
with the magnetic field of the earth to always point
the same position in north. Although the actual
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Introduction to Global Satellite Positioning System (GPS)
positioning is a magnetic North Pole, not a true
North Pole, it is enough to use in positioning
and navigation. Therefore, the compass has been
widely used in many positioning and navigating
applications. The compass still has a little accurate positioning problem affected by magnetic
interference in natural environment, but it has no
serious influence on using the compass.
Nowadays, the most famous positioning and
navigation service is Global Satellite Positioning System (GPS) (Global Positioning System,
2009; EI-Rabbany, 2002; Kaplan et al., 2006).
It uses the satellites orbiting around the earth in
space to broadcast positioning signals. A GPS
receiver receives the signals and calculates out its
current position. That is, GPS provide a worldwide positioning and navigation service for any
kind of communication and transportation, such
as aircrafts, vessels, vehicles, pedestrians, etc.
GPS is developed by the U. S. Department of
Defense (DoD) in early 1970s. At the beginning
of constructing GPS, it is only used for military
purpose, but it has freely opened for civilian use
on July 2000s. Therefore, GPS is now a dual-use
system that can be accessed by both military and
civilian users in various positioning precision
for some national security factors considered by
U.S. government.
As mention above, vehicles having built-in
GPS navigation system will be a main trend to
provide the driving assistance and navigation service in the future. In next section, we will describe
the principle of GPS system in detail.
the GPS receivers to receive enough GPS signals
without bidirectional communications among
them. GPS receives will be able to calculate out
the user positions they locate now.
GPS system generally consists of a constellation of 24 operational satellites (Leick, 2004). In
order to ensure continuous worldwide converge
for GPS positioning service, six orbital planes of
satellites are organized and each four satellites
are placed in an orbital plan. There are four to
ten GPS satellites will be visible anywhere in
the world under this constellation geometry. The
sketch map of GPS constellation is shown in Figure 1. A GPS satellite routes around the earth in a
nearby circular orbit, an elliptical shape, with an
inclination of 55 degrees to the equatorial plane.
The maximal radius of GPS orbit is about 26,560
kilometers measured from the earth center. The
orbit period of GPS satellite is approximately 12
sidereal hours, which is about 11 hours and 58
minutes. Thus, GPS satellite will run around the
earth twice per day. In order to ensure the availability of GPS positioning service, the number
of satellites in the GPS constellation has always
been more than 24 operational satellites.
Figure 1. The GPS constellation
principle oF global
posiTioning sysTem
The GPS is a satellite-based positioning and
navigation system. GPS provides continuous positioning and timing information anywhere in the
world under any weather conditions. GPS is also a
passively one-way ranging system and it can serve
unlimited number of users. That is, users only take
109
Introduction to Global Satellite Positioning System (GPS)
The GPS system is comprised of three segments
shown in Figure 2: space (satellite constellation),
control (ground-control/monitoring network), and
user (receiving equipment). The detailed functions
of each segment are listed as follow:
1.
2.
Space segment: It consists of 24-statellite
constellation. It also has some back-up satellites to ensure the full operational capability
(FOC) of GPS positioning service. Each
satellite transmits a unique PRN (Pseudo
Random Noise) ranging signal to measure
the distance from GPS receiver to GPS satellite. The satellite signals are controlled by
atomic clocks with high precision to transmit
through two L-bands, L1 (1,575.42 Hz) and
L2 (1,227.6 Hz). GPS satellite has an S-band
antenna to communicate with control segment in order to maintain the operational
control of GPS service.
Control segment: It consists of a master
control station (MCS) and a worldwide
network of five monitor stations and four
Figure 2. GPS segments
110
3.
ground antennas shown in Figure 3. The
main task of control segment is responsible
for tracking, monitoring, commanding, and
controlling the GPS satellite constellation in
order to determine and predict satellite locations, system integrity, behavior of satellite
atomic clocks, and other considerations. The
observation of GPS satellites collected at the
monitor stations are transmitted to the MCS
for processing. MCS sends the processing
outcome, the fresh navigation data (control
information), to the monitor control stations
with ground antenna uploading them to GPS
satellites through S-band link. Therefore,
the control segment is an important role to
maintain the operational behavior of GPS
positioning service.
User segment: It typically refers to as a GPS
receiver shown in Figure 4. When a user uses
a GPS receiver to receive enough the L-band
signals from GPS satellites under a spacious
area, the GPS receiver can determine user’s
position and related information, including
Introduction to Global Satellite Positioning System (GPS)
Figure 3. Geographic distribution of control segment facilities
Figure 4. Various types of GPS receivers
longitude, latitude, altitude, time, velocity,
etc, anywhere in the world.
gps posiTioning model
The basic idea of GPS positioning model is very
simple. It uses the TOA (Time of Arrival) ranging model to measure user position. That is, the
distances from a point holding a GPS receiver
on the surface of the earth to three GPS satellites
are known along with satellite positions, the position of the point can be determined by triangular
positioning theory. The concept of TOA ranging
model is to measure the propagation time of signal
broadcast from signal emitter at known locations.
Assume that the signal emitter regularly broadcast
the beacon signal and both of signal emitter and
111
Introduction to Global Satellite Positioning System (GPS)
receiver have synchronous clocks. The receiver
can measure the propagation time of beacon
signal from emitter and then propagation time is
multiplied by the speed of the signal to obtain the
distance from the emitter to the receiver.
GPS system provides three-dimensional position information including longitude, latitude,
and altitude. It needs to use the three-dimensional
position determination to calculate the position of
the measured position. In order to simply examine
the GPS positioning model, we first introduce the
two-dimensional position model how it achieve
the point positioning. Consider a mariner at sea
determine his vessel’s position from a foghorn.
Assume that the vessel and the foghorn are
equipped with accurate synchronized clocks, the
foghorn whistle is repeatedly sounded per minute,
and the position of foghorn is known. The marine
measures the elapsed time from minute mark until
the foghorn whistle is heard. Thus, propagation
time (t) of foghorn whistle multiplies speed (v) of
the sound is the distance (R, R = v × t) from the
foghorn to the marine. Let the foghorn be denoted
F1 and the distance from the foghorn F1 to the
marine be denoted R1 respectively. Thus, marine
only knows the vessel is somewhere on a circle
with radius R1 centered about the foghorn, which
is shown in Figure 5-(1). If there is the second
foghorn F2 and the marine can simultaneously
measures the distance R2, the vessel position will
be located at one of the intersections of the range
circles with radius R1 and R2 centered about the
Figure 5. Two-Dimensional Position Determination: (1) All possible positions ranging from a single
source, (2) Two ambiguous positions from measurements to two sources, and (3) Position ambiguity
removal by three sources.
112
Introduction to Global Satellite Positioning System (GPS)
foghorns F1 and F2 respectively, which is shown
in Figure 5-(2). In order to resolve the positioning ambiguity of the vessel, third foghorn F3 is
applied to measure the distance R3 for removing
position ambiguity as shown in Figure 5-(3). In
fact, the TOA measurement would not be perfect
due to the clock drift, sound interference, atmospheric effects, etc. These errors would affect the
measurement and resulting in accurate distance
computations.
GPS also employs TOA ranging and threedimensional positioning model to calculate user
position. The measurement of GPS positioning
model is similar to two-dimensional positioning
model. Assume that each satellite transmits a
unique ranging signal in space. A satellite has a
clocks synchronized with others clocks built on
other satellites. The clock synchronization and
orbit plane of these satellites are monitored and
controlled by the control segment (MCS). A GPS
receiver also has a clock synchronized to GPS
system time. Ranging signals transmitted from
GPS satellites contain time information. It enables
the receiver to measure the propagation time (t1)
of the ranging signal left the satellite (S1) based
on satellite clock time. Thus, the satellite-to-user
distance (R1, R1 = Vlightspeed × t1) can be calculated.
The user would be located somewhere on the
surface of a sphere centered about S1, as shown in
Figure 6-(1), in this ranging measurement. If the
second satellite (S2) is considered into account, the
user would be located somewhere on the surface
of both spheres ranging from S1 and S2, as shown
in Figure 6-(2). That is, the user position is located
at a plane of intersection. The third satellite (S3)
is adopted to measure the user position. The user
would be located at the interaction of the perimeter
of the circle and the surface of the sphere centered
about S3, as shown in Figure 6-(3). We can find
that the user position would be at two possible
points, and only one of the points is the correct
user position. For the user position, it is generally
locates on the surface of the earth. Therefore, the
lower one of two points will be the true position. In
Figure 6. GPS Three-Dimensional Positioning
Model: (1) User located on surface of sphere, (2)
User located on perimeter of plane of intersection,
and (3) User located at one of two points.
order to measure the more accurate user position,
the fourth satellite will be applied to calculate and
fix the user’s altitude.
In addition GPS can determine the user velocity. The most popular used method is based on
estimating the Doppler frequency of the received
GPS signals. GPS also can measure the moving
orientation (direction) of a rigid object, e.g., a
vessel, an aircraft, etc.
gps reFerence
coordinaTe sysTem
Although GPS can measure the user position
anywhere, under any weather conditions. Due to
the irregular topographic surface of the earth, the
determination of the user position is very difficult.
To over this problem, it needs a mathematical
formulation to model the smooth surface of the
113
Introduction to Global Satellite Positioning System (GPS)
earth. Therefore, it needs a reference coordinate
system to represent the states of GPS satellites
and the receiver. A coordinate system is a set of
rules to specify the locations of points. This usually specifies the origin (the central) and a set of
reference lines (the axes) with known orientation. Figure 7 shows a 3-D Cartesian coordinate
system which uses three reference axes, x, y, and
z, intersecting at the origin (C) of the coordinate
system. Coordinate systems can be classified
according to the reference surface, the origin,
and the orientation of the axes. For example, in
a 3-D geodetic coordinate system (Torge, 1991),
the reference surface is an ellipsoid. The orientation of the axes and the origin are specified by
two planes: the meridian plane through the polar
and equatorial plane. It is important to provide an
easy-understanding positioning information for
the GPS users. Thus, positioning information in a
3-D geodetic coordinate system can be described
in the geodetic latitude (ϕ), the geodetic longitude
Figure 7. A sample of 3-D coordinate system
114
(λ), and the altitude (h) above the reference surface.
That is, geodetic coordinate (ϕ, λ, h) of Point P
can be easily transformed to or from Cartesian
coordinate (x, y, z).
The world geodetic system (WGS) (World
Geodetic System, 2009) is a standard coordinate
system used in cartography, geodesy, and navigation. It consists of a standard coordinate frame for
the earth, a standard spherical reference surface
for raw altitude data, and a surface (nominal sea
level) with the same gravitation. That is, The WGS
can provide an ellipsoidal model to represent the
real earth shape. Therefore, the WGS can provide
the means for relating positions on various local
geodetic systems to an Earth-centered, Earth-fixed
(ECEF) coordinate system. A series of WGS
revolution, WGS 60 (developed in 1960), WGS
66, WGS 72, and WGS 84, have been developed
to provide more accurate coordinate system. Currently, the GPS system uses the WGS 84 to be the
standard of coordinate reference system.
Introduction to Global Satellite Positioning System (GPS)
gps daTa proTocol FormaT
Different GPS manufacturers may have their
own data formats to store the GPS measuring
information. It may lead to increase the difficulty
of system integration. Thus, it is necessary to
define the standards of GPS data formats to access the uniform GPS information from various
GPS receivers. A number of standard formats of
GPS information representation for various needs
have been developed, which includes RINET,
NGS-SP3, RTCM SC-104, NMEA 0183, etc.
NMEA 0183 is the most popular GPS data format
in these standards.
The National Marine Electronics Association
(NEMA) has developed a specification defining
the standard, called NMEA 1083, (NMEA Data,
2009) communicating interface among various
marine electronic equipments and application
software. The standard allows marine electronics to send information to computer or to other
marine equipment. GPS receiver communication is also defined within the NMEA standard.
GPS receivers generally use the RS232 protocol
(EIA-422) to communicate with GPS software
through computer serial ports. The interface
speed of NMEA standard is 4800 baud rate with
8 bits of data, no parity, and one stop bit. Thus,
all GPS receivers should support this speed. But
some modern GPS receivers can support higher
interface speeds, e.g., 9600 or 38400 bits per
second, to communicate.
Data stream in the NMEA 0183 standard is an
ASCII format. It includes the complete position,
velocity, and time (PVT) information. The data
is sent in the form of sentences. Each sentence
begins with a ‘$’ character and ends with a carriage return/line feed <CR><LF> sequence. The
maximal length of sentence is less than 80 characters of visible text. The data fields in sentence
formed in a single line are separated by commas.
The first 5 letter prefix following the beginning
character ‘$’ identify the sentence type (first 2 letters) and sentence content (successive 3 letters) in
a sentence. The prefix of sentence type is GP for
GPS receivers. The last field in any sentence is
a checksum field following a delimiter character
‘*’. NMEA standards have defined various GPS
sentences. Table 1 shows some common GPS sentences used in a GPS receiver and an example for
decoding GPGGA sentence is illustrated in Table
2. Besides, we also can visit the web site (http://
gpsinformation.org/dale/nmea.htm) to view the
detailed structures and formats of other common
GPS sentences.
Figure 8. An example of valid GPS sentences generated from a GPS receiver
115
Introduction to Global Satellite Positioning System (GPS)
Table 1. Some common GPS sentences used in
GPS receiver
Name
GPS information can be visualized displayed on
the GPS viewer software or equipment.
Figure 9 depicts an example of GPS viewer
showing GPS information including the longitude,
latitude, height, speed, direction, the number of satellites in view of the sky, their locations of viewed
satellites, and the strength of GPS signals.
Notes
GPGGA
Global positioning system fixed data
GPGSA
GPS DOP and active satellites
GPGSV
Satellites in view shows data about the status of
satellites
GPRMC
Recommended minimum command
GPVTG
Velocity information
GPDLL
Geographical Latitude and Longitude
gsp applicaTion For
Vehicle naVigaTion
Since the price of GPS receiver has become
cheaper, the usage of GPS has also become more
ubiquitous. Thus, many innovative GPS services
including navigation and positioning, tracking,
and surveying, etc., have been widely applied into
various application domains. In this section, a GPS
Figure 8 shows a series of GPS sentences
generated from a GPS receiver, which sentences
contain five main content types: GPGGA, GPGSA,
GPGSV, GPRMC, and GPVTG. After decoding a
series of GPS sentences, which include GPGGA,
GPGSA, GPGSV, GPRMC, and GPVTG, these
Table 2. The decode of GPGGA sentence
GPGGA Sentence
Data Items in Sentence
$GPGGA,040905.000,2333.2209,N,12025.6358,E,1,07,1.2,37.6,M,17.1,M,,0000*61<CR><LF>
$GPGGA,[1],[2],[3],[4],[5],[6],[7],[8],[9],[10],[11],[12],[13],[14],*[15]<CR><LF>
Number
Example
[1]
Time of position in UTC system [hhmmss.ss]
040905.000
[2]
Latitude [lll.ll]
2333.2209
[3]
North or South [N/S]
N
[4]
Longitude [yyyy.yy]
12025.6358
[5]
East or West [E/W]
E
[6]
GPS quality indicator [0=invalid; 1=GPS fix; 2=Diff. GPS fix, …]
1
[7]
Number of satellites in use [xx]
07
[8]
Horizontal dilution of position (HDOP) [x.x]
1.2
[9]
Antenna altitude above/below mean sea level (geoid) [x.x]
37.6
[10]
Meters (Antenna height unit) [M]
[11]
Geoidal separation (Diff. between WGS-84 earth ellipsoid and mean sea level. -=geoid is below WGS-84 ellipsoid) [x.x]
[12]
Meters (Units of geoidal separation) [M]
[13]
Age in seconds since last update from diff. reference station [x.x]
[14]
Diff. reference station ID# [0000-1023]
*
[15]
<CR><LF>
116
Notes
Checksum delimiter character [*]
Checksum (hh)
Sentence terminator [<CR><LF>]
M
17.1
M
(NULL)
0000
*
61
<CR><LF>
Introduction to Global Satellite Positioning System (GPS)
Fgiure 9. An example of GPS viewer virtualizedly
showing GPS information
application concentrating on vehicle navigation
will be discussed.
GPS provides the location, velocity, orientation, and time information that enables many
practical applications to be used in our daily lives.
The first popular application is GPS navigation
service (Drane et al., 1998). A car installed an in-
vehicle GPS navigation system (automotive GPS
navigation system) can assist the driver to follow
a route plan to reach the driving destination s/he
sets. Figure 10 shows an example of using GPS
navigation to be an aid for driving during a trip.
Although GPS navigation system can acquire
the position information from GPS satellite signals, it needs a digital map stored in the system
or retrieved from the Internet to locate the user
or the car on the road in a road network. Thus, a
newest full set of digital map is a very significant
in order to provide an accurate GPS navigation for
matching to the real road network environment,
e.g., a new road has been opened. A friendly userinterface for user is also an important issue in a
GPS navigation system. A modern GPS navigation
system may consist of visual-display interface
(e.g., virtual road network in 3D view), touch
screen (e.g., target input), voice-based interface
(e.g., speech recognition and synthesis), etc., to
satisfy the various requirements of the GPS driving
guidance. Some GPS navigation systems may have
a module, to receive the real-time traffic information to dynamically update the navigating guidance
service fitting the real road network condition via
traffic message channel (TMC) (Traffic Message
Figure 10. Use the GPS navigation system to aid the drive
117
Introduction to Global Satellite Positioning System (GPS)
Channel, 2009) through FM radio broadcasting,
WiFi/GPSR/3G data transmission, inter-vehicle
communication, etc.
In addition to GPS navigation service, the GPS
can also be used in vehicle tracking, GPS security,
fleet management, intelligent public transportation
service, emergency rescue, biological movement,
geodetic surveying, graphic information system,
location-based service, etc. We also find that
a cellular phone with a built-in GPS receiving
module is a trend. It means that cellular phone
will act a portable and personal GPS location and
navigation platform to provide the walker navigation with highly accurate guiding information,
the location-aware services of the four essential
requirements of the people: food, clothing, housing and transportation, in the future.
conclusion
In this chapter we have briefly introduced an
essential principle of the GPS system, including
GPS constellation, GPS segments, GPS positioning model, standard GPS data format, and GPS
application for vehicle navigation. There are still
many issues, such as GPS satellite signal characteristics and acquisition, GPS signal inference
and multipath, error measurement, differential
GPS (D-GPS) (Differential GPS, 2009), assisted
GPS(A-GPS) (Assisted GPS, 2009), other GPS
systems, geodetic/geocentric coordinate system,
map projection, etc., to be discussed.
reFerences
Assisted, G. P. S. (n.d.). Retrieved September
11, 2009, from http://en.wikipedia.org/wiki/Assisted_GPS.
118
Differential, G. P. S. (n.d.). Retrieved September
11, 2009, from http://en.wikipedia.org/wiki/Differential_GPS.
Drane, C., & Rizos, C. (1998). Positioning system
in intelligent transport systems. Boston: Artech
House.
EI-Rabbany. A. (2002). Introduction to GPS –
The Global Positioning System. Boston: Artech
House.
Global Positioning System. (n.d.). Retrieved
September 11, 2009, from http://en.wikipedia.
org/wiki/Global_Positioning_System.
Kaplan, E. D., & Hegarty, C. J. (2006). Understanding GPS – Principle and Applications.
Boston: Artech House.
Leick, A. (2004). GPS Satellite Surveying. New
York: John Wiley & Sons.
NMEA Data. (n.d.). Retrieved September 11, 2009,
from http://gpsinformation.org/dale/nmea.htm.
South Pointing Chariot. (n.d.). Retrieved September 11, 2009, from http://en.wikipedia.org/wiki/
South_Pointing_Chariot.
Torge, W. (1991). Geodesy. Berlin: Walter de
Gruyter.
Traffic Message Channel. (n.d.). Retrieved September 11, 2009, from http://en.wikipedia.org/
wiki/Traffic_Message_Channel.
World Geodetic System. (n.d.). Retrieved September 11, 2009, from http://en.wikipedia.org/wiki/
World_Geodetic_System
Zhao, Y. (1997). Vehicle Location and Navigation
Systems. Boston: Artech House.
119
Chapter 8
Vehicle Location and
Navigation Systems
Ben-Jye Chang
National Yunlin University of Science and Technology, Yunlin, Taiwan, R.O.C.
absTracT
The most driving purpose is to traverse to the destination safely, efficiently, and comfortably. Two types
of approaches could achieve the goals, including the static and dynamic approaches. In the static aspect,
vehicles use the static road and traffic information to navigate. Conversely, in the dynamic aspect, vehicles adopt the dynamic information instead. However, both of the two approaches first require getting
the vehicle’s location and then map the position on an e-map. Thus, this chapter first introduces some
important vehicle location determination algorithms: the dead reckoning and global position system
algorithms, in which the precision of location technologies are compared. Then, the map-matching
algorithm is described in detail. Finally, various vehicle navigation approaches are detailed, in which
the important topics include: the navigation architecture, the navigation routing algorithm, and navigation applications.
inTroducTion
The invention of the vehicles, though it could shorten
the distance from place to place, has brought a lot
of serious issues: traffic jam, car accident, energy
crisis, environmental pollution, etc. Moreover, as
the population rises and living in standard increases
constantly, the vehicles are everywhere and the roads
are even more complicated. Finally, it would not
DOI: 10.4018/978-1-60566-840-6.ch008
only waste our time, but social cost. Therefore, transportation simplification, driving time reduction, and
energy conservation are the top priority concern of
the world. Thus, this chapter, Vehicle Location and
Navigation Systems (Farrell et al., 2008; Zhao et al.,
1997), are what we researched. While the vehicles
are moving, realizing your location, destination and
the shortest path are important. However, most of
all, you know where you are, or other conditions
are useless. The early days of vehicle position are
a driver reads maps and road signs in the meantime
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Vehicle Location and Navigation Systems
and finally reaches its destination. It is inefficient
and dangerous still. Moreover, wasting resources
and other problems could occur by vehicles position. Generally, vehicle position can be divided
into two methods: early days’ dead position and
current used GPS technologies.
For locating a vehicle position, the vehicle with
dead reckoning method must set its coordinates
before moving. Position and distance sensors,
based on the coordinates, could figure out tracking
movement and turning degree. Lastly, the current
position could be located.
For example, as shown in Figure 1, the starting
point (x 0 , y 0 ) , the based point also, multiplied by
each distance di and aspect qi is the terminal point
(x n , yn ) . The formula becomes as follows:
n
x n = x 0 + å diT cosqi
i =0
n
yn = y 0 + å diT sinqi
(1)
i =0
Distance and position sensors are applied by
dead reckoning method. The following contents
in this book would discuss both two common
sensors.
Distance sensor normally applies speedometer
to plot the moving distance. The application makes
use of the sensor device, which can calculate wheel
turns, on the wheel axle. Circumference of the
wheel multiplied by the wheel turns is the distance.
Figure 1. Dead reckoning
Figure 2. Distance sensor device
However, the results could be a huge error due to
different wheel sizes and terrains (e.g., idle running
of wheels on the snow and sand). Distance sensors
are subdivided into mechanical and electronic
ones. Figure 2 is a typical example.
The vehicle position sensors enable position
measurement. It can either be an absolute position
sensor or a relative one. The first one applies the
earth’s magnetic field to get absolute position.
Figure 3 shows that the induction coils can be
affected by the earth’s magnetic field and the
vehicle’s position can be measured can by the
angle q , as demonstrated in equation 2. However,
using earth magnetic field to induct potion has a
disadvantage. That are the results are easily affected by some circumstances: viaducts, bridges,
substation, and high-voltage tower. Conversely,
the relative position is determined in terms of the
original point and angle.
q = tan-1
Vx
Vy
(2)
Dead reckoning was mainly used in the past
with three disadvantages: 1) Based point should
be located well, 2) The sensor has huge error,
and 3) The more distance you move, the more
error could be.
120
Vehicle Location and Navigation Systems
Figure 3. Earth magnetic sensor
global positioning system
Since the first generation GPS chip was presented
to the public, it overcomes some problems: unclear signal of ex-chip, long positioning time,
location drifting, etc. Due to the progress of chip
manufacturing procedure and size reduction, even
PDA, digital camera, cell phone and so on can be
integrated with GPS. The GPS device equipped
on the vehicles is simple and more accuracy than
dead reckoning method. It is getting to be used as
basic vehicle equipment.
Conversely, some disadvantages of GPS
still need to be addressed. For example, if a cell
phone or radio’s wave band is closed to GPS’, it
would cause interference. In addition, tunnels and
weather would affect the accuracy of GPS also.
Thus, adjusting GPS error by a fixed base
station and then conveying it to the vehicles’
GPS for correcting can add accuracy. It is called
Differential GPS (namely D-GPS). As Figure 4
demonstrated, the FM radio can also receive the
positioning signal from the base station.
Figure 4. Differential GPS (D-GPS)
121
Vehicle Location and Navigation Systems
map maTching
The vehicle positioning system is different from
the airplane and ship positioning systems. The
reason is that the vehicle movement tracks must on
roads. Recently, maps have already been digitized;
thus, the error between digital maps and movement tracks can be corrected by computers. As a
result, a more accurate position can be resulted,
as shown in Figure 5.
map matching method
The theorem of map matching is to match a vehicle
moving track on a digital map (Brakatsoulas et
Figure 5. Map matching
Figure 6. Digital network map
122
al., 2005). In a digital map, a road is viewed as a
link and an intersection is viewed as a node, as
shown in Figure 6.
Furthermore, when a vehicle is moving, the
coordinates of the vehicle can be compared with
the digital map, as demonstrated in Figure 7. For
example, the black bold line, namely a road, and
the green one is the vehicle movement track, in
which we could get two vertical lines: L1 and
L2. If L1 is shorter than L2, it means the vehicle
movement track is on road A, and vice versa. This
is the basis theorem of the map matching.
Although the vehicle positioning can use map
matching to correct the movement tracks and to
get accurate position, map matching still has some
Vehicle Location and Navigation Systems
Figure 7. Map matching
drawbacks. For example, if a road is just not on
the digital map or one drives to parking lots or
open ground, how to calculate position with map
matching? Therefore, an error upper and lower
range should be set. Once an error is in the range,
it initiates the correction of the movement tracks;
otherwise, the error can be ignored.
Vehicle Tracking
The GPS device is easy to be carried and easy
to be integrated with other systems. Moreover,
due to the common used and free charge of using
GPS, the vehicle position can be opened another
different applications, e.g., the vehicle tracking,
the transportation online information, etc.
introduction of Vehicle Tracking
The vehicle tracking issue is a vehicle equipped
with GPS and has the capability to report its coordinates to a computer periodically. In Figure
8, a user can trace the target vehicle’s position
through the Internet. Similarly, more and more
new applications of vehicle tracking are being
created, for example, a remote alarm system,
transportation tracking, etc.
Figure 8. Vehicles tracking
123
Vehicle Location and Navigation Systems
model of the Vehicle
Tracking system
Basically, the model of the vehicle tracking system can be divided into two parts: the position
dispatch end and the reception end. In the position dispatch end, the GPS receiver continuously
receives the satellite signal and then locates the
vehicle’s position. Meanwhile, the coordinates can
be dispatched to the Internet through the wireless
network base stations. The position reception end
can receive and match the coordinates from the
Internet and pass current position to the digital
map. Finally, the date can be shown on the screen,
as demonstrated in Figure 9.
The applications of the
Vehicles Tracking
The applications of the vehicle tracking are very
extensive. It is even more than what we can think
about of. Till now new applications are still brought
up. However, normally they can be divided into
several parts.
Security:
•
Cash-carrying vehicle security surveillance: So far the vehicles tracking system, a basic equipment for a cash-carrying vehicle, can track a vehicle’s position
Figure 9. Fame of the vehicles tracking system
124
•
effectively to avoid embezzlement and be
managed easily.
Car alarm system: The best car alarm system equipped also by car rental agencies
now is the vehicles tracking system. Once
the vehicle was stolen, we can find out no
matter wherever it is.
The distribution and management system of
police cars and ambulances through surveillance
center management. If something urgently happened, they can send the nearest police cars or
ambulances to support. Furthermore, the patrolling
position and the public security can be improved
efficiently.
Transportation:
•
Cargo services: Through the vehicles
tracking system, we can know cargo destination, map out a route to avoid wasting
time. A consumer can realize the cargo’s
status through the Internet.
The delivery of dangerous goods and polluted
material, e.g., through the vehicle tracking system,
once chemical or toxic material, stone delivery
and the like are leaking out, we can deal with it
in the very beginning and avoid other vehicles
entering the limited area.
Vehicle Location and Navigation Systems
Public transit:
•
•
Vehicles distribution: Before you head
somewhere, through the Internet, one can
check the nearest taxi or bus current position. Moreover, through the vehicle tracking system, speeding and route time can be
estimated.
The management of a fleet of vehicles: It is
not only for making up for cell phone using
defects, but also avoiding lagging behind
and getting lost.
auTonomous locaTion
and naVigaTion
In the past, the cost of navigation system was very
high, so that it was used on special applications.
In increase of time, the cost is down and drivers
use the navigation system to locate the position
and to navigate without any help. In this section,
we briefly depict the issues of the autonomous
location and the navigation systems.
autonomous location
The autonomous location is that a vehicle can
locate the position by itself. In (Zhao, 1997; Zhao
et al., 1997), authors classified the location technologies to three types: the stand-along location
technology (Chang et al., 2008), the terrestrial
radio technology and the satellite technology. In
the stand-alone location technology, the Dead
Reckoning is an example to use the self ability
to locate the position. The terrestrial radio technology and the satellite technology are similar,
because the terrestrial radio technology adopts the
signals of base stations to locate the position and
the satellite technology uses the satellite signal
to locate position.
The precisions of different technologies are
indicated in Table 1 (Schiller et al., 2004). Based
on the results, only using one location technology
is not enough for some applications, because the
Table 1. The precisions of different location
technologies
Technology
Medium
Precision
GPS
Radio
25 m
DGPS
Radio
3m
WAAS
Radio
3m
MPS
Radio
150 m
coordinates computed by a location technology
may exist significant erroneous. By integrating
with several location technologies is a good approach for reducing errors.
autonomous navigation
Navigation means that a position can be located
on a map and a routing algorithm referring to
the location of the vehicle calculates the path
for a driver. Autonomous navigation means that
navigation is done by self. Figure 10 proposes an
example of the autonomous navigation architecture (Zhao, 1997). The communication devices are
used to receive the radio signals and to calculate
the position. After determining the position, the
user can input the destination for the system to
determine the routing path.
Figure 10. The architecture of a navigation
system
125
Vehicle Location and Navigation Systems
A navigation system not only provides the routing function, but also offers additional functions
such as weather bulletins, restaurant position, etc.
Based on the factors, designing a navigation system must consider what typical kinds of functions
should be included in the navigation system.
cenTraliZed locaTion
and naVigaTion
After describing the navigation and location
technologies in the previous section, this section
details the location and navigation systems based
on a centralized framework. In the centralized
location and navigation systems, all functions
are done in a centralized server for reducing the
computing loading of clients. In this section, we
first introduce the architecture of centralized
systems. Location architecture and navigation
architecture are then depicted.
centralized architecture
Zhao (1997) shows the Centralized architecture,
as shown in Figure 11. Communication devices
are adopted to communicate with the wireless
technology such as WiMAX and GSM in order to
perform the communication between the client and
the server. A client requests a service from server
and the server provides a service to the client.
location architecture
In Figure 12, Zhao (1997) introduced a location
architecture of a centralized system. This architecture consists of three parts including communication devices, a client and a server. The client
uses the GPS device or other methods to get the
coordinates, and then sends it to the server. When
receiving the coordinates of the client, the server
computes the position and locates it on a digital
map. The final result is shown on a graph-based
interface, as demonstrated in Figure 13.
Figure 11. System relation between communication devices, client and server
Figure 12. Location architecture of a centralized system
126
Vehicle Location and Navigation Systems
navigation architecture
In Figure 14, Zhao (1997) introduces a navigation
architecture of a centralized system. In the client,
after keying the destination, the client sends a
navigation request to the server. When the server
receiving a request, the server determines a path
for the client and then sends the determined routing path to the client. According to the received
results, the client drives to the destination via the
central-computed routing path.
auTomaTic Vehicle driVing
and naVigaTion
Automatic vehicle driving technology let user
drives the vehicle without any operations. How to
achieve this goal? In this section, we thus discuss
these technologies that automatic vehicle needs.
Firstly, we introduce automatic vehicle driving and
navigation. The needs of technologies of automatic
vehicle are then discussed in detail.
introduction
In the past, an automatic vehicle was a dream but
now technologies are advanced and can be accomplished. The traffic accidents are often happened
when drivers are scatterbrained or other factors
which are not avoided. By using the automatic
vehicle, it could reduce the probability of accident.
An automatic vehicle also saves us a lot of time
which we could use to do other things.
For realizing an automatic vehicle that can
automatically drive to a destination, some key
technologies such as image process, navigation
system and automatic control system are required.
Figure 13. (a) A scenario of simulation (b) The display result of location
Figure 14. Navigation architecture of a centralized system
127
Vehicle Location and Navigation Systems
These technologies need a powerful computer but
may have some problems. In the increase of time
and advance of technologies, these problems will
be overcome and vehicles will have a function of
automatic driving.
consist of automatic Vehicle
From the descriptions of previous sections, we
know that the automatic vehicle will be the trend
in the future. An automatic vehicle consists of a
computer vision system, a navigation system and
a vehicle control system. The relation of these
systems is demonstrated in Figure 15. First, the
computer vision processes a series of the image,
which is capture by a camera, and then returns
the process result to the vehicle control system.
Second, the vehicle control system controls the
vehicle according to receive an information from
other systems. It only has the computer vision and
vehicle control systems are not enough because
the vehicle is lack of an indicator for the use of
arbitrarily drive. Based on this condition, the
provision of a navigation system for an automatic
vehicle is necessary and important. The navigation system and the computer vision system are
related with each other, because if there is an
error of location in the navigation system, the
computer vision system can be used to correct
Figure 15. The components of automatic vehicle
Figure 16. Computer vision system
128
the vehicle location. For example, the navigation
system instructs the vehicle to turn right in 150m,
but it must turn right in 100m. In order to reduce
the error condition, we use a computer vision
system to correct the error. The combination of
a computer vision system, an automatic vehicle
control system and a navigation system has the
capability to achieve an automatic vehicle.
Navigation System
In previous sections, the navigation system consists of a location system and map information
system which was introduced in Chapter 13.
The navigation system plays a very import role
in the automatic vehicle that instructs the vehicle
when the vehicle makes turns. If a vehicle is lack
of the navigation system, it will drive randomly
and causes it dangerously. That is, a navigation
system is an instructor telling a location with a
small error. The development problem is how to
design a system with high precise location and
how to use other related methods to improve the
decision of automatic driving.
Computer Vision System
A computer vision system consisting of a camera
and image process observes environments and
Vehicle Location and Navigation Systems
responds to the control system. Figure 16 shows
an example of a scenario. Firstly, the camera
captures images converted to digital images, and
then the image process detects some targets. In
consequence, the result of detection is shown in
the original image.
The function of a computer vision system can
be divided into three types: the lane detection,
the vehicle detection and the obstacle detection. First, the lane detection helps an automatic
vehicle to detect a lane which the vehicle drives
on. Second, there are many vehicles driving on
a lane. If a system can’t detect other vehicles, it
will cause accidents. Based on this reason, vehicle
detection is necessary. Finally, a lot of objects
may be on lanes such as people, animals, rocks,
traffic light, etc. The obstacle detection helps the
automatic vehicle to detect these situations and
to respond to the control system immediately. In
this subsection, we first introduce the lane and
vehicle detections.
In the lane detection, Jung et al., (2005) introduced a lane detection technology. The procedures
include edge detection and boundary detection.
In the edge detection, the edge distribution function and Hough transform are adopted to detect
edges. In the boundary detection, a linear model
is adopted to detect boundaries. Figure 17(a) is
an original image. The image shown in Figure
17(b) is grayed and then uses boundary detection
to find the rough sketch of lanes. Finally, the lanes
are drawn in the original image as demonstrated
in Figure 17(c).
In most related studies, they can detect the
marked lanes; however, in the real roads not all of
Figure 18. (a) An original image. (b) A grayed
image. (c) Vehicle detection. (d) A result of detection
roads are marked for each lane. For this reason, how
to handle this exception must be addressed.
In the vehicle detection, the function of the
vehicle detection is to detect other vehicles in front
of the detecting vehicle. The vehicle detection must
consider some impact factors such as the distance
between vehicles, the speed of vehicle, etc. In this
subsection, we only consider the vehicle detection
without other factors.
Broggi et al., (1999) introduced the vehicle detection as indicated in Figure 18. First, it grays the
image and then uses the symmetry detection that
detects a symmetry part of a vehicle for detecting
vehicles. The symmetry detection uses the edge
detection technology, and then uses the results of
vertical and horizontal edge detections to find an
outline of a vehicle. It then uses the bounding box
detection, detecting the left and right box on the
top or foot, to increase the result of detection. If a
Figure 17.
129
Vehicle Location and Navigation Systems
Figure 19. Structure of the vehicle control
reFerences
Brakatsoulas, S., Pfoser, D., Salas, R., & Wenk, C.
(2005). On Map-Matching Vehicle Tracking Data.
In The 31st VLDB Conference, (pp. 853 – 864).
Broggi, A., Bertozzi, M., Fascioli, A., Guarino,
C., Bianco, L., & Piazzi, A. (1999). The Argo Autonomous Vehicle’s Vision And Control Systems.
International Journal of Intelligent Control and
Systems, 3, 409–441.
box is not fined, it will use backtracking to correct
results and repeatedly uses boundary detection to
find vehicles.
Vehicle Control System
The vehicle control system, an important component of the automatic vehicle, receives information
from the computer vision and navigation systems,
and then controls the vehicle. If the control system
design has defects, it will cause accidents. Based
on the reason, providing a stable and robust control
system is required.
Thus, a control system must consider many
impact factors: error correction, speed of driving, etc. However, we only introduce a basic
architecture proposed in (Broggi et al., 1999), in
which the structure of the vehicle control system
is shown in Figure 19. A computer vision system
sends a result of image process to the vehicle
control instructor, controlling the vehicle according to vehicle information, image process and
location. Finally, the vehicle obeys instructor’s
command to drive.
130
Chang, B.-J., Huang, B.-J., & Liang, Y.-H. (2008).
Wireless Sensor Network-based Adaptive Vehicle
Navigation in Multihop-Relay WiMAX Networks.
The 22nd International Conference on Advanced
Information Networking and Applications, (pp.
56-63).
Farrell, J. A. (2008). Aided Navigation: GPS
With High Rate Sensors (pp. 22-80). New York:
Glencoe/McGraw-Hill School Pub Co.
Jung, C. R., & Kelber, C. R. (2005). Lane following
and lane departure using a linear-parabolic model.
Image and Vision Computing, 23, 1192–1202.
doi:10.1016/j.imavis.2005.07.018
Schiller, J., & Voisard, A. (2004). Location-Based
Services. San Francisco: Morgan Kaufmann.
Zhao, Y. (1997). Vehicle Location and Navigation
Systems. Boston: Artech House Publishers.
Zhao, Y., & House, A. (1997). Vehicle Location
and Navigation Systems: Intelligent Transportation Systems (pp. 43-78). Boston: Artech House
Publishers.
131
Chapter 9
Design and Implementation of
Vehicle Navigation Systems
Min-Xiou Chen
National Dong-Hwa University, Hualien, Taiwan, R.O.C.
absTracT
Vehicle Navigation System (VNS) is a complicated and integrated system. A reliable vehicle navigation
system should integrate the wireless communication technologies, positioning technologies, embedded
computer, geographic information database, and so on. The major purpose of the chapter is to help
understanding the architecture of vehicle navigation system. This chapter first introduces the system
requirements and system analysis, and show the system platform of vehicle navigation system. The system
platform can be divided into six components. There are the digital map database, positioning devices,
map-matching process, route planning process, route guidance process, human-machine interface, and
wireless communication interface. The design issues and system communication of these components
are detail illustrated in the chapter. Finally, the authors also present some vehicle navigation systems
proposed in the past few years, and show the difference of these systems. The aim of vehicle navigation
system is to guide the vehicle along the optimal path from the starting point to destination. A reliable
vehicle navigation system can reduce the traffic chaos in the city and improve the transportation delay.
In order to achieve reliable vehicle navigation system, the detail system requirements, system analysis,
and system architecture are shown in the chapter. Each component of vehicle navigation system is briefly
illustrated, and the system communication is also described. The authors also present the architecture of
the proposed vehicle navigation system, and show the difference of these systems. Therefore this chapter
helps understanding the architecture of vehicle navigation system.
DOI: 10.4018/978-1-60566-840-6.ch009
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Design and Implementation of Vehicle Navigation Systems
inTroducTion
system requirements
The aim of navigation system is to detect the position of the vehicle, track the vehicle and control
the movement of the vehicle from one place to
another. The location techniques and the map are
two important components in the navigation system. In Age of Exploration, the shipman records
their position on the chart and pilots their courses
according the compass, sextant, and chronometer.
After World War II, the radar technique is implemented to identify the range, altitude, direction, or
speed of both moving and fixed objects. The radar
technique is also involved in the modem navigation system in order to improve the correctness of
the vehicle position, and sailing safety. In recent
years, with the development of global positioning
technology, electronic technology, and wireless
communication technology, the size of navigation
system becomes smaller and can be carried on a
bus, truck or car. Thus, the automotive navigation
system had been proposed to guide vehicles in its
location using digital map display. Moreover, with
rapid increment of automotives, the urban traffic
becomes much more crowed and the traffic chaos
is a serious problem in many cities. Therefore,
how to design a vehicle navigation system in
order to reduce the traffic chaos and improve the
transportation delay is a critical problem. In the
chapter, the detail architecture of vehicle navigation system is illustrated.
Let’s consider a scenario that a visitor is driving in
a strange city, how can he know his position and
plan the driving path to the targeted place based
on his tourist map? Getting lost is a nightmare
for each visitor. Thus, the system requirements
for the tourist and the strange driver are shown
as below (Zhao, 1997):
The design oF Vehicle
naVigaTion sysTems
k.
The development process of an information system
should involve the system requirements, system
analysis, system design, system construction,
system testing, and system maintenance tasks.
This chapter will focus on the system analysis,
system requirements, and system design of the
vehicle navigation system.
132
a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
l.
m.
n.
Shows the correct position of the current
vehicle or destination on the digital map;
Plans the shortest/fastest route from the current position to the destination and show on
the digital map;
Guides the drivers along the planned
route;
Tracks the vehicle on the digital map;
Easy and safety to use;
Shows the real-time traffic information (emergency or congestion) on the
monitor;
Re-plan routers based on emergency information or congestion information. Moreover,
more system requirements shown as below
had been proposed in the investigation results
for the Taiwanese drivers .
Shows the warning message of the speed
traps or the over speed limit;
Shows the park area and the gas station on
the digital map;
Shows the shopping/restaurant information
on the digital map;
Shows the tourist information on the digital
map;
Shows the Road-Side service;
Reports the traffic accident; Summarize
these system requirements, the basic system requirements can be shown as the
following:
The function to show the location of the
current vehicle or destination on the digital
map;
Design and Implementation of Vehicle Navigation Systems
o.
p.
q.
The functions to plan or re-plan the shortest/
fastest route;
The functions to show the life
information;
Friendly user interface.
e.
system analysis
Analyzing the user requirements, the functions of
the vehicle navigation system can be illustrated
as following:
a.
b.
c.
d.
Needs a digital map library: The digital
map database is the key component for the
vehicle navigation system. The road map
should be digitalized into the digital library,
before the system uses it. The location information of some government institutions and
some famous buildings should be digitalized
into the digital library, which can be denoted
as the landmarks. The system can obtain and
show the relative position of each targeted
object on the map according to the location
information of these landmarks.
Needs the location modules: The location
modules can be divided into the positioning
module and map-matching module. The
major function of the positioning module
is to get the position information from the
position devices and obtain the coordinates
of a vehicle on the surface of the Earth, or
the relative position of a vehicle on the city.
The aim of the map-matching module it to
provide drivers the correctly location information of the vehicle and show the precisely
position of the vehicle on the map.
Needs a route planning module: The route
planning module is a process that provides
the drivers to plan the route from the starting
point to the destination.
Needs a route guidance module: The route
guidance module is a process that guides
the drives along the planned route from
f.
the current position of the vehicle to the
destination.
Needs an interactive interface: The interactive interface involves the input devices
and output devices. The drivers can enter
the information into the system, or select
the information from the system by the input
devices, and see the results from the output
devices.
Needs a communication module: The
communication module can receive the current traffic information, such as emergency
information and congestion information,
from the traffic control center. The system
can re-plan a new route based on that current
traffic information. The vehicle navigation
system also can report the traffic information
to the traffic control center.
The implemenTaTion oF
Vehicle naVigaTion sysTems
According to the system analysis, the system
architecture of the vehicle navigation system can
be shown as the Figure 1. The vehicle navigation
system involves six components. There are the
digital map database, positioning devices, mapmatching process, route planning process, route
guidance process, human-machine interface, and
wireless communication interface. The implementation issues of these components are illustrated
as following section.
system platform
a.
Digital map database: The digital map
database is the key component for the vehicle navigation system. The information
of the road map, the landmarks, such as the
government institutions and the famous
buildings, and the life information, such
as the hotel, park area, restaurant, gas station, and so on, also should be digitalized
and stored in the digital map database. The
133
Design and Implementation of Vehicle Navigation Systems
Figure 1. System platform
basic representations for the digital road
map are nodes, segments, and shape points.
A node can be represented a cross point or
an endpoint of a road. A segment can be
represented the piece of road between two
nodes. A shape points is placed in the segment, and is used to present the shape of the
road. The location information of each node
and each shape point, such as the latitude and
the longitude, are stored in the digital map
database. The landmark points can be used
to denote the landmarks and the life information. The landmark points also contain the
location information, such as the latitude,
the longitude, and the address. These nodes,
shape points, and landmark points are very
useful for the map-matching process. In
order to present the precisely road map, and
provide more useful information, a lot of the
shape points and the landmark points will
be created in the digital map database. The
computation cost of vehicle location and
navigation will increase when the amount of
these points increased. The hierarchical layer
is introduced to improve the computation
complex of vehicle location and navigation.
These nodes, shape points and landmark
points can be classified into different layers
134
b.
according to their importance. For example,
the nodes and shape points placed on the
highways are in the upper layer, the nodes
and shape points placed on the country
roads are in the lower layer, the landmark
points represents the airports, train stations,
and harbors, are in the upper layer, and the
landmark points represents the park areas,
restaurants, and gas stations, are in the lower
layer. The vehicle navigation system can
retrieve these nodes and points according
the drivers requirement. For example, the
route planning process can only retrieve the
nodes on the highways and arterials, and
the map-matching process can retrieve the
landmark points in the lowest layer when the
vehicles is in the city. Moreover, the drivers
can show the information of different layer
on the screen upon their requirement.
Location modules: The positioning devices
and the map-matching function are two vital
components in the location modules. The
major functions of the location modules are
to get the coordinates of a vehicle on the surface of the Earth from the position devices,
obtain and show the precisely position of
a vehicle on the map. The most common
used positioning devices in the positioning
Design and Implementation of Vehicle Navigation Systems
c.
devices can be classified into two groups.
The relative devices, such as transmission
pickup, wheel sensor and gyroscope, can
estimate the approximate position data, such
as the directions and travel distances. The
absolute devices, such as GPS and compass,
can report the precisely position information.
Both these devices can be used on the vehicle
navigation system. The map-matching function receives the location information of the
vehicle from the positioning module, and
retrieves the neighbor landmarks from the
digital map library. Then, according to the
location information of these landmarks, the
map-matching function will obtain the placement of the vehicle relative to landmarks, or
roads, and show the result on the map. The
dead reckoning is the primitive technique
used to determine the vehicle location relative to a reference point. When the starting
location and the previous displacements are
known, the vehicle position will be more
reliable and accurate. The vehicle and distance traverse are widely used to estimate
the changes in the position of the vehicle
relative to the origin. The drivers also can
input a query address into map-matching
function and see the precisely position on
the map.
Route planning process: The route planning process is used to plan a path from the
starting point to destination. The starting
point can be the current position of the
vehicle, or entered by the drivers from the
user interface. The drivers also can select
the landmark from the digital library and
set as the starting point or destination point,
or input the destination information from
the user interface. Then, the route planning
module will retrieve the road map from the
digital library and plan the path from the starting point to destination. The planned route
can be listed on the screen, and used by the
route guidance module. The route planning
d.
process can be classified into the single
vehicle route planning and multi vehicle
routing planning. The single vehicle route
planning can be solved by the shortest path
algorithms, such as Dijkstra’s algorithm and
Bellman-Ford algorithm. The single vehicle
route planning is to determine the optimal
route under the time or fuel constraints. The
all-pairs shortest path algorithms, such as
Floyd-Warshall algorithm and Johnson’s
algorithm, can be used to solve the multi
vehicle routing planning problem. The multi
vehicle routing planning is to determine the
optimal routes for all vehicles through the
minimal total tour length subject to the time
or fuel constraints. The computation complex
of the route planning process is the critical
problem. The hierarchical concept is introduced to improve the computation complex
of route planning. The route planning process
can only retrieve the nodes on the highways
and arterials, and the highways and arterials
segments, and determine the optimal route.
In addition, the divide and conquer method
can also be introduced to improve the complexity of the route planning process. The
road map can be divided into several blocks,
and the route planning process finds the path
in each block. Finally, the route planning
process assembles these block paths into
a complete route from the starting point to
the destination. The drivers can browse each
block paths on the user interface. Moreover,
the route planning process should provide the
re-planning function, when the emergency
event or congestion event occurs.
Route guidance process: The aim of the
route guidance process is to guide the drives
along the planned path from the current position of the vehicle to the destination. The
route guidance process should retrieve all
the road information involved in the planned
route from the digital library, and list that
information, such as the road names, travel
135
Design and Implementation of Vehicle Navigation Systems
e.
136
distances, turns, and landmarks, on the output
devices. The drives can read that information before the trip. The route guidance
process also can present that information
to the drivers in real time while en route.
The route guidance process should retrieve
the current position of the vehicle from the
location modules, and presents the proper
guidance messages, such as turn-by-turn
instructions, to the output devices. The route
guidance process continuously retrieves
the current position and direction of the
vehicle from location the modules, continuously compares the position and direction
with the planned route, and shows the turn
message or some travel messages on the
user interface or provide a series of voice
announcements to warn the drivers. When
the route guidance process finds the drivers off the planned route, a series of voice
announcements should be provide to alert
the drivers driven back to the planned route.
The re-planning function provided by the
route planning process also can be invoked
to determine a proper path from the current
position and direction to planned route, and
the route guidance process guide the drives
back to the original route. Moreover, the replanning function also can determine a new
route from the current position and direction
to destination. When the emergency event or
congestion event occurs, the route guidance
process should alert the drivers to plan the
new route.
Human-machine interface: The humanmachine interface provides a comfortable
and effective human use interface between
the users and vehicle navigation system. The
drivers control the system from the input
devices, and read the information from the
output devices. The input and output devices
can be classified into the visual display based
interfaces and voice based interfaces. The
drivers browse the digital map from the LCD
f.
or touch screen, and enter the command in
the touch panels or touch screen. The drivers also can send the voice commands into
the system by the microphone, and hear the
announce message from the speaker. A good
design of the human-machine interface can
improve the driving safety. The design principles for a good human-machine interface
were proposed in (Ligs et al., 1995).
Wireless communication interface: The
wireless communication interface is an optional component for the vehicle navigation
system. The vehicle navigation system can
provide route planning and route guidance
without the wireless communication interface. However, the wireless communication
interface can improve the driving quality.
The wireless communication interface receives the current traffic information, such
as emergency information and congestion
information, from the traffic control center.
Once these messages sent, the vehicle navigation system may alert to the driver. Then,
the system can re-plan a new route based on
that real time traffic information. The vehicle
navigation system also can report the traffic
information to the traffic control center. The
traffic control center can get more precisely
traffic information, determine the proper
traffic control policy, announce that information to all vehicles, and improve the traffic
quality. Moreover, the traffic information
also can be exchanged between the vehicles
without the traffic control center. This kind
of network is referred as Vehicular ad hoc
network (VANET), which a kind of wireless
ad-hoc network. The VANET includes some
special characters, such as an open peer-topeer network architecture, lack a central
instance, each node is willing to forward
data for other nodes, self-configuration and
self-maintenance capabilities.
Design and Implementation of Vehicle Navigation Systems
system communication
advance
The system platform and system communication
of the vehicle navigation system is shown in the
Figure 1. The digital map database is the kernel
component, which provides the information of
roads and landmarks to the map-matching process,
route planning process, route guidance process,
and human-machine interface. The digital map
database can update the real time traffic data received from the wireless communication interface.
The map-matching process retrieves the roads
and the landmarks from the digital map database.
According that information and the vehicle information provided by the position devices, the
map-matching process provides the precisely location on the map to the route guidance process and
shows on the human-machine interface. The route
planning process retrieves the roads, landmarks
and real time traffic information from the digital
map database, and receives the real time traffic
information from the wireless communication
interface, plans a path from the starting point to
destination, and passes the path to the humanmachine interface and route guidance process. The
route guidance process retrieves current position
from the location modules, compares the position
with the road information and real time traffic
information in the planned route retrieved from
the digital map database, and announces proper
turn-by-turn message to the drivers driven along
the planned path. The drivers also can browse
the map from the digital map database, and use
the route planning process to re-plan the route.
The drivers can use the human-machine interface
to report their known information to the traffic
control center.
ADVANCE (Advanced Driver and Vehicle Advisory Navigation ConcEpt) (Ligs et al., 1995; Boyce
et al., 1994; Boyce 2002) is a project promoted
by the industrial, government and academic of
Illinois, USA in July 1991. The project test was
completed in the end of 1996. The ADVANCE
architecture is shown in Figure 2 (Zhao, 1997).
The Traffic related function is placed on the traffic information center, and can provide history
traffic information and static traffic profiles. The
dynamic traffic information reported from the
mobile navigation assistant (MNA) are aggregated by the traffic related function. The traffic
information center (TIC) has many computers
and devices to monitor the road network traffic,
and report the traffic information to the MNA
through the communication network. Both the
TIC and MNA have the digital map database used
to show the road map. The MNA is carried by the
vehicle, and its architecture is shown in Figure
3 (Zhao, 1997).
The navigation computer is the key component
of MNA. The navigation computer gets the location information from the position devices, and
retrieves the map information from the digital
map database, which is a CD, and is read from
the CD-ROM. The map-matching function, route
planning function and route guidance function
are provided in the navigation computer. The
navigation computer shows the road map on the
touch screen, and announces the voice message
from the speaker. The navigation computer also
reports the traffic data which receives from the
position devices to the TIC, and receives the real
time traffic information from the TIC through RF
modem. Due to the computation complexity, the
route planning function in ADVANCE only can
consider the highway. The tourists are suitable for
the planned route obtained by the ADVANCE, but
the familiar drivers are not suitable.
case sTudy
Some vehicle navigation systems had been proposed in the past few years. Some of these implement architecture are illustrated in the section.
137
Design and Implementation of Vehicle Navigation Systems
Figure 2. ADVANCE architecture
Figure 3. Mobile navigation assistant architecture
papago
PaPaGo is mobile navigation software implemented by the Maction Technologies, Inc. in
Taiwan (PaPaGo SDK). The platform of PaPaGo is
WinCE, and the implement environment is Visual
C++. PaPaGo can be installed on the Pocket PC,
Smartphone, and PDA. PaPaGo can be divided
138
into four components. The map display component is the digital map database, the information
retrieval component used to search the object
from the map component, and the route planning
component is to plan the path from the starting
point to destination. The route guidance function
and human-machine interface are integrated in the
map display component. The position component
Design and Implementation of Vehicle Navigation Systems
of PaPaGo is GPS. Thus, the signal quality of GPS
is very important for PaPaGo.
Figure 4. VETRAC architecture
VeTrac
VETRAC (Thangavelul el al., 2007), as shown in
Figure 4 (Thangavelul el al., 2007), is a vehicle
tracking and navigation project based on the
VANET. VETRAC does use the WiFi but not GPS
to track the vehicles. VETRAC deploy some WiFi
access point in the field, which can be used to receive the data sent from the mobile hosts, and also
can be used to monitor the traffic flow and track
the vehicles. The mobile computer with the client
control panel and display map system is installed
on the vehicle and uses the Mobile IP. The vehicle
will report the traffic information to the vehicle
tracking system and send some requirements to
the navigation server through AP or VANET. As
shown in Figure 5 (Thangavelul el al., 2007), the
navigation server is the core component of VETRAC, and processes the traffic information sent
from the vehicle tracking system, and response
the user requirements. The navigation server also
reports the location information to each vehicle,
and stores the traffic information, digital road map,
and vehicle locations into its database. Four servers
are implemented in the navigation server.
The connection server is used to manage
the connections and the registries between the
navigation server and the connection manager
of the client control panels. The aim of the location server is to response the location query sent
from the location manager of the client control
panels. The traffic service can announce the traffic information retrieved from the client location
database to the traffic information manager of
the client control panels. The positioning server
of the navigation server receives the traffic information sent from the vehicle tracking system,
and updates that information stored in the client
location database.
The vehicle tracking system is used to aggregate the traffic information sent from the AP.
When new vehicle enters, the vehicle tracking
system will automatically report the positioning
server of the navigation server. The drivers see
the location information from the display map
system of client control panel.
dmrg
Dual Mode Route Guidance System (DMRG)
(Muffat el al., 1991; Kuhne el al. 1995) is a
vehicle navigation system promoted by the car
industries in the Europe. The system architecture
of DMRG is shown in Figure 6. DMRG integrates
the individual route guidance systems, and collective route guidance systems. The individual
route guidance systems only plan a single vehicle
route from the starting point to destination. The
collective route guidance systems placed on the
traffic control center, can collect all the traffic
information, and provide the better planned router
for each vehicle. The individual route guidance
systems use the on-board computer to plan the
path according to individual criteria (shortest
139
Design and Implementation of Vehicle Navigation Systems
Figure 5. VETRAC software architecture
Figure 6. DMRG system architecture
way, quickest, simplest, etc). Thus, the several
drivers use the same routing algorithm with the
same criteria and destination will have the same
planned path to follow. Some roads may become
140
congestion due to the case. In contrast, the traffic control center has each vehicle’s location and
destination, the collective route guidance systems
can plan different path for the vehicle with the
Design and Implementation of Vehicle Navigation Systems
same destination, and the traffic congestion can
be reduced. The system architecture of DMRG is
very similar to ADVANCE. The major difference
is the route guidance function. ADVANCE only
considers the individual route guidance systems,
but the DMRG integrates the individual route
guidance systems, and collective route guidance
systems.
conclusion
In this chapter, we have shown the system architecture and system communication of the
vehicle navigation system. The user requirement
is described in the first. After system analysis,
the modules of the vehicle navigation system
are proposed, and the functions of each module
are briefly illustrated. The general operations of
the system communication are also described in
the following section. At last, we elaborate some
architectures of the proposed navigation system,
and describe the difference of these systems. In
recent years, human factors have been included
into navigation systems in order to develop the
intelligent transportation systems (Woodrow et
al., 1998; Lee et al., 2005), and to improve the
safety of drivers (Baldwin, 2002; Transportation
Research Board, 2004). Summarizations these
system architectures, the navigation systems still
have a large scope for development.
reFerences
Baldwin, C. L. (2002). Designing in-vehicle
technologies for older drivers: application of
sensory-cognitive interaction theory. Theoretical Issues in Ergonomics Science, 3(4).
doi:10.1080/1463922021000009029
Boyce, D. (2002). A Memoir of the ADVANCE
Project. Journal of Intelligent Transportation
Systems, 7(2).
Boyce, D. E., Kirson, A. M., & Schofer, J. L.
(1994). ADVANCE-The Illinois Dynamic Navigation and Route Guidance Demonstration Program.
Advance Technology for Road Transport, IVHS
and ATT.
Frost & Sullivan, (2005). Strategic Analysis of the
Taiwan Telematics and Infotainment Market.
Green, P., Levison, W., Paelke, G., & Serafin,
C. (1995). Preliminary Human Factors Design
Guidenlines for Driver Information Systems. Technical Report No. UMTRI-93-21, Transportation
Research Institute, The University of Michigan,
Ann Arbor, MI.
Kuhne, R. D., & Langbein-Euchner, K. (1995).
Calculation of travel time savings by dual mode
route guidance for the South corridor in the Stuttgart test field. Vehicle Navigation and Information
Systems Conference.
Lee, J., Forlizzi, J., & Hudson, S. E. (2005).
Studying the effectiveness of MOVE: a contextually optimized in-vehicle navigation system.
In Conference on Human Factors in Computing
Systems.
Ligs, J. F., & Bowcott, S. (1995). ADVANCE:
Initial Deployment. Annual Meeting of ITS
America.
Muffat, M., Green, P., & Crosnier, S. (1991).
European cooperation on dual mode route
guidance—Perspectives for advanced research
partners. Vehicle Navigation and Information Systems Conference. PaPaGO SDK. (n.d.). Retrieved
from http://www.papagosdk.com/
Thangavelul, A., & Bhuvaneswari, K. Kumar’, K.,
SenthilKumarl, K., & Sivanandam, S.N., (2007).
Location Identification and Vehicle Tracking using VANET (VETRAC). In IEEE International
Conference on Signal Processing, Communications and Networking 2007.
141
Design and Implementation of Vehicle Navigation Systems
Transportation Research Board. (2004). Transportation In An Aging Society: A Decade of Experience. Transportation Research Board.
Woodrow, B., & Thomas, A. (1998). Dingus Human Factors in Intelligent Transportation Systems.
Mahwah, NJ: Lawrence Erlbaum Associates.
Zhao, Y. (1997). Vehicle Location and Navigation
Systems. Boston: Artech House.
142
Section 4
Integrated Vehicular Application
144
Chapter 10
Vehicular Metropolitan Area
Network Systems Architecture:
The WiMAX Network Reference Model
Cheng Hsuan Cho
National Chung Cheng University, Taiwan, R.O.C.
Jen-Yi Pan
National Chung Cheng University, Taiwan, R.O.C.
absTracT
The WiMAX NWG develops a network reference model to serve as an architecture framework for WiMAX
deployments and to ensure interoperability among various WiMAX equipment and operators. The network reference model envisions unified network architecture for supporting fixed, nomadic, and mobile
deployments and is based on an IP service model. The authors introduce WiMAX network architecture,
WiMAX network entry, mobility management, QoS functional elements, core network planning and
accounting architecture in this section. However, all of them are significant in deploying WiMAX core
network. The operator tries to reach the goals including system performance, reliability, and so on.
On the other hand, the WiMAX operator should consider and balance such many variables in order to
achieve a better situation.
inTroducTion
Based on WiMAX Forum Network Architecture
definition (Stage 2: Architecture Tenets, Reference
Model and Reference Points (Juo et al., 2008)) (Stage
3: Detailed Protocols and Procedures (WiChorus,
2009)), the WiMAX network reference model includes the logical functional entities and reference
points. Figure 1 shows the WiMAX network reference model containing reference points, functional
entities, and some important basic elements like
Network Service Provider (NSP) and Network
Access Provider (NAP).
The functional entities contains Subscriber Station (SS)/Mobile station (MS), ASN(Access Service
Network) and CSN(Connectivity Service Network).
As in Fig 10.1, the network reference model depicts
telecommunication’s operations. Access Service
Network is managed by NAP (Network Access
Provider). CSN is managed by NSP (Network
DOI: 10.4018/978-1-60566-840-6.ch010
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Vehicular Metropolitan Area Network Systems Architecture
Figure 1. WiMAX network reference model
Service Provider). CSN provides IP connectivity,
links out with the internet and combines with its
Home-ASP (Application Service Provider). Basically, the overall architecture can be divided into
three parts. The first part (left position in Figure
10.1) is MS/SS equipments, and it’s also called
the end users. The second part (center position
in Figure 10.1) is ASN. ASN supports wireless
communication and air-interface to MS/SS. The
third part is CSN where inner management servers
locate (such as Home Agent, Location Register,
AAA server and so on).
Based on Figure 1, we give an introduction for
these functional entities and reference points:
ASN(Access Service Network): It links with
WiMAX Customer Premises Equipment (CPE)
e.g. MS, SS. Access Service Network (ASN)
functions support WiMAX Layer2 connectivity,
AAA messages forwarding, WiMAX NSP selection, Layer-3 link tunneling (BS-SS) and Radio
Resource Management (RRM). The operations
can be seen in the ASN-GW function.
ASN-GW(ASN Gateway): As in Figure 2,
we can observe the ASN-GW functions which
contain reference points and functional entities
in ASN. ASN-GW not only manages IP Data
Forwarding in ASN, but also links with the other
function entities inside or outside the ASN-GW.
It tunnels data and packets to the suitable BS.
ASN-GW Control plane handles all of the radioindependent control and includes authorization,
authentication, and accounting (AAA), context
management, profile management, service flow
authorization, paging, radio resource management,
and handover. Data plane feature set includes
mapping radio bearer to the IP network, packet
inspection, tunneling, admission control, policing,
QoS and data forwarding.
ASP(Application Service Provider): ASP
provides basic network service and manages
applications with IP-network. An application
service provider (ASP) is a business that provides
computer-based services to customers over a network. Software offered using an ASP model is also
sometimes called On-demand software.
CSN(Connectivity Service Network): The
CSN contains several functional elements and
tasks for supporting IP-Network connectivity to
145
Vehicular Metropolitan Area Network Systems Architecture
Figure 2. ASN-GW reference model
CPE. The following lists the major tasks in CSN
network:
1.
2.
3.
4.
5.
6.
7.
MS/SS IP address assignment.
Internet access.
AAA Server management.
Tunnel supported (between CSN and SS).
Accounting /pricing service.
Users roaming across ASNs/ CSNs.
Mobility management between MS and
ASN.
NAP (Network Access Provider): ASP
provides basic network service and manages applications with IP network. Moreover, it provides
radio link resource to one or more NSPs. One NAP
can also contain one or more ASN network. For
146
example as Figure 10.1 shown, the NAP function
contains two ASN networks.
HA (Home Agent): HA supports mobility
management for MIP registration, de-registration,
and packet tunneling in CSN, and it helps CSN
maintain the IP address table or location area,
e.g. it records MS location where MS attached
the serving BS. So CSN can use this information
to tunnel packets to MS/SS from corresponding
node (CN). In the network reference model, HA
is located in CSN.
FA (Foreign Agent): Foreign agent is a router
serving as a mobility router for a mobile node
(The definition is also in IETF-RFC-2002). A
foreign agent works together with home agent to
support Internet traffic forwarding. For the MS/
SS, it connects to the Internet from any location
other than its home network. The home agent
Vehicular Metropolitan Area Network Systems Architecture
Table 1. Reference points R1~R8
Links
Operation and Task
R1
MS -- ASN
Implementation as the same as IEEE 802.16e-2005 definition
R2
MS -- CSN
Authentication, authorization for MS, IP host configuration and mobility management
R3
ASN -- CSN
Supporting AAA, policy enforcement, and mobility - management capabilities (including tunneling and
forwarding)
R4
ASN-GW -- ASN-GW
R5
CSN -- CSN
R6
BS -- ASN-GW
R7
In ASN-GW
R8
BS – BS
Used for MS mobility across ASNs
For internetworking between home and visited network
Implementation of intra-ASN tunnels and used for control plane signaling
Coordination between data and control plane in ASN-GW
Handover control, ensuring fast and seamless handover
tunnels packets intended for the mobile node to
a care-of address, which is either the IP address
for the foreign agent, or an IP address acquired
through some external equipment or server, such
as Dynamic Host Configuration Protocol (DHCP)
server. However, the foreign agent de-capsulates
packets and delivers them to the mobile node.
(Detailed MIP operations are described in RFC3344-IP Mobility Support for IPv4 (Mustafa
Ergen, 2009)).
LR (Location Register): Location Registers
are database functions storing information typically used in the routing of signaling information.
Typical examples include the HLR (Home Location Register) and VLR (Visitor Location Register)
used in telecommunication.
BS (Base Station): BS serves Subscriber Stations (point-to-multipoint), and provides SS with
first-mile (or last mile) access to public networks.
Besides, BS is directly connected to backbone networks (e.g Ethernet). The complement definitions
of PHY/MAC layer are introduced in IEEE 802.16.
It can also support radio resource management:
call admission control, packet scheduling, power
control and handover control. Base station has the
local control of the network and gets assistance
from ASN-GW for some features and implements
the decision of the gateway for others.
RP (Reference Point): In NRM, Reference
point 1~8 are reference points between different
functional entities. We conclude these and show
their work as in Table 1.
wimaX neTwork enTry
The original network entry procedure is defined
in WiMAX Forum stage2/3. The definitions are
also described in 802.16e. However, the operation
can be separated by the following operations as
shown in Figure 3.
nd&s (network discovery
and selection)
1.
2.
NAP discovery: NAP discovery is the first
step of network entry. At first, an SS/MS
detects available NAP(s) by scanning and
decoding DL-MAP of ASN on detected
channel to find NAP(s). SS/MS will range
with the NAP if the NAP exists, then decode
DL-MAP, UL-MAP, DCD and UCD. (The
detailed operation is defined in IEEE 802.16
d/e)
NSP discovery: The NAP may support more
than one NSP. In Figure 4, if NSP Identifier
Flag LSB in Base station ID equals to 1, it
means there are more than one NSP in NAP.
And also, MS acquires with NSP ID list.
After this process, MS must discover each
147
Vehicular Metropolitan Area Network Systems Architecture
Figure 3. WiMAX network entry
MS indicates its NSP selection by attaching
to an ASN associated with the selected NSP,
and by providing its identity and home NSP
domain in form of NAI (network access
identifier).
authentication
3.
4.
NSP until all of these NSP are founded. On
the contrary, if NSP identifier Flag LSB is
equal to 0, MS will knows there is only one
NSP service behind the NAP.
NSP enumeration and selection: After NSP
discovery, MS produces a list of available
NSPs as discovered through NSP discovery
in the available NAPs, MS uses the list select
NSP by manual or automatic selection.
ASN attachment based on NSP selection:
Following a decision to select an NSP, an
Figure 4. Base station ID format (Juo et al., 2008)
148
This protocol implements 802.16e security with
IETF EAP framework. The protocol is used for
service flow authorization, mobility management
and policy control. AAA framework is based on
pull model in which supplicant sends a request to
ASN, and then ASN forwards it to AAA server.
The AAA returns with appropriate response
to ASN which sets up the service and informs
the MS. The elements are depicted in Figure 5.
The operation applies PKMv1 and PKMv2 by
Extensible Authentication Protocol (EAP) to
authenticate with user. PKMv1 is authentication
for device. In contrast with PKMv1, PKMv2 is
authentication for user and Device between CSN
and MS. In the authentication flow, user Authentication is optional, while device Authentication is
Mandatory. When the authentication procedures
just only include Device Authentication or User
Authentication, Single EAP can support the
procedure. But when user and device both need
Vehicular Metropolitan Area Network Systems Architecture
Figure 5. WiMAX user authentication protocol
authenticated, double EAP is needed, and each
uses different AAA server (e.g. AAA servers is
located in different CSN).
configuration setup
The procedure of Configuration Setup is after
Authentication procedure. In order to support different network architecture (e.g. IPv4 or IPv6, network with or without DHCP), many configuration
processes are proposed: ProxyMIPv4 (PMIP4),
ClientMIPv4 (CMIP4), Proxy PMIPv6 (PMIP6)
and Client MIPv6 (CMIP6). The “Client” means
MS/SS support Mobile IP (MIPv4 / MIPv6) function. It doesn’t need other equipments forward or
tunnel packet. Proxy Mobile IP (MIPv4 / MIPv6)
means Proxy server is located in ASN which helps
MS/SS in charge with registration and signaling
MIP packets to HA. Therefore, although MS/
SS doesn’t have capability to supporting MIP, it
can still roams in the wireless network by using
Proxy-MIP server.
data Transfer
At this stage, MS/SS is able to use WiMAX core
network. The user can use the data link to browse
web-sites and transfer data. But when the user
moving to another BS’s coverage, not only the
attached WiMAX ASN-gateway will change, but
also the IP address will change. We will discuss
the mobility issue in the later paragraph about
moving between ASN/CSN scenarios.
wimaX mobiliTy managemenT
The WiMAX network supports two types of
mobility: (1) ASN-anchored mobility and (2)
CSN-anchored mobility. ASN-anchored mobility
is also referred to as intra-ASN mobility, or micromobility. In this case, the MS moves between
two data paths while maintaining the same anchor
foreign agent at the northbound edge of the ASN
network. The handover in this case happens
across the R8 and/or R6 reference points. ASNanchored handover typically involves migration
of R6, with R8 used for transferring undelivered
packets after handover. It is also possible to keep
149
Vehicular Metropolitan Area Network Systems Architecture
the layer three connection to the same BS (anchor
BS) through the handover and have data traversal
from the anchor BS to the serving BS throughout
the session.
On the other hand, CSN-anchored mobility
is also referred to as inter-ASN mobility, or
macromobility. In this case, the MS changes to a
new anchor FA, this is called FA migration. The
new FA and CSN exchange signaling messages to
establish data-forwarding paths. The handover in
this case happens across the R3 reference point,
with tunneling over R4 to transfer undelivered
packets. Figure 6 illustrates the various possible
handover scenarios supported in WiMAX.
Based on different mobility scenarios (e.g.
ASN-anchored mobility, CSN-anchored mobility), we can see Intra-ASN mobility and
inter-ASN mobility between the WiMAX core
network. WiMAX End-to-End Network Systems
Architecture Stage 3 shows ASN Anchored
Figure 6. Mobilityscenario with multiple ASN-GW
150
Mobility and CSN Anchored Mobility function
and operation:
asn anchored mobility
ASN anchored mobility takes place when MS
moves to a neighboring BS that connects to a
different ASN-GW, which may be within the
serving ASN or not. If the target BS belongs to a
different ASN, the target ASN-GW will establish
a R4 data path to the anchor ASN so that the MS
can avoid data loss and the QoS could also be
guaranteed. During the ASN anchored handoff
procedure, the MS does not change its CoA.
ASN Anchored Mobility divides ASN function
into preparation phase and Action phase. 802.16e
working groups defined MOB MSHO-REQ (when
the network initiated, we called MOB BSHOREQ) message format for preparation phase and
defined MOB HO-IND message format for action
phase, some of preparation’s steps is optional. It
Vehicular Metropolitan Area Network Systems Architecture
can keep these steps on preparation phase until
action phase. On the contrary, if we did these
steps in preparation phase, the action phase leaves
out the operation time that can reduce a part of
handover latency.
For ASN anchored mobility, traffic to MS
comes from the anchor ASN. Figure 10.7 depicts
the data flow of ASN anchored mobility. ASN1 is the serving and anchor ASN to MS. After
handover, the packets from are CSN delivered
from ASN-1 to ASN-2 via a R4 data path. The
anchor ASN to MS remains the ASN-1.
csn anchored mobility
On the contrary, CSN anchored mobility involves
in anchor ASN relocation, which means anchor
ASN is changed after CSN anchored mobility.
Figure 8 describes the data flow after CSN anchored mobility. The packets directly send from
CSN via the new R3 link to ASN-2, unlike in ASN
anchored mobility the traffic comes from ASN-1.
ASN-2 is the new anchor ASN for MS.
Based on these mobility scenarios, we make a
simple conclusion and comparisons in Table 2.
ho Function network Transaction
The handover (HO) allows MSs to handover
between neighboring BSs while moving across
the corresponding coverage areas. Furthermore,
the mechanism can be used by BSs to trigger a
HO in order to optimally balance the traffic load
of cells within a network.
The basic HO function transaction is shown
in Figure 9. HO function contains serving HO,
relaying HO and target HO.
1.
At first, the serving HO function initiates an
HO network transaction by sending HO_Req.
There can be only one serving HO function
for any given HO network transaction. After
Figure 7. ASN anchored mobility scenario
151
Vehicular Metropolitan Area Network Systems Architecture
Figure 8. CSN anchored mobility scenario
Table 2. Comparison with ASN- anchored mobility and CSN- anchored mobility
Mobility type
Handoff latency
ASN- Anchored Mobility
CSN- Anchored Mobility
Faster – handoff process without through FA
Slow– handoff process through FA
FA change or not
ASN-GW’s FA does not change, and the original FA tunnels packets to new BS.
CSN changes FA. MS re-registers with CSN and it’s
HA with MIP registration procedure. Then, new FA will
forward packets.
From HA viewpoint
When MS move to another ASN, HA doesn’t
knows that.
MS will change its CoA on HA’s mapping table when
it re-registers.
Backhaul Link Efficiency
--
Better
2.
152
receiving HO IND from MS, serving HO
function the serving HO function confirms
HO to only one target HO function by sending HO Confirm messages.
The target HO Function responds to the HO
network transaction with HO_Rsp. There
can be one or more target HO functions for
an HO network transaction.
3.
Serving HO Function and target HO functions communicate either directly or with
assistance of one or more relaying HO
function. If the serving and target HO functions cannot communicate directly for any
reason, the relaying HO function takes care
of delivering the relevant information to the
corresponding target HO functions. A single
HO primitive (e.g. HO_req) that is sent
Vehicular Metropolitan Area Network Systems Architecture
Figure 9. HO function transaction
from the serving HO functions may contain
information relevant for several target HO
functions. In this case several behavioral
policies might be applied.
Qos FuncTional elemenTs
Under the IEEE 802.16 specification, a SS could
be associated with a number of service flows
characterized by QoS parameters, and QoS framework for the air interface. The specification also
defines combined scheduling scheme, Resource
allocation and admission control. Besides, the
WiMAX forum also describes QoS framework for
WiMAX Network service, as shown in Figure 10.
The WiMAX Forum has specified a framework
for Service Management and QoS. Service Flow
(SFA) and Service Flow Manager (SFM) are the
entities that act as policy decision and enforcement points respectively for Service Management
and QoS. The following figure depicts the policy
framework for WiMAX networks:
As service flow provide a particular QoS
according to the QoS parameter set defined for
that service flow. The following mechanisms of
the standard are defined to ensure the end-to-end
QoS:
1.
2.
3.
4.
5.
Pre-provisioning of the service flow
parameters.
Signaling function to dynamically establishing the QoS enabled service and traffic
parameters.
Utilization of MAC scheduling and QoS
traffic parameter for uplink service flow
Utilization of QoS traffic parameter for
downlink service flow.
Grouping of service flow properties into
name Service Classes.
Based on Figure 10, we give an introduction
for these functional entities:
1.
SFA (service flow authorization): Is responsible for evaluating any service request
against the subscriber’s QoS profile. SFA
logical entities in the ASN. In case the user
QoS profile is downloaded from the AAA
into the SFA at network entry phase, the SFA
is responsible for evaluating any service
request against user QoS profile. The SFA
153
Vehicular Metropolitan Area Network Systems Architecture
Figure 10. QoS functional elements (Juo et al., 2008)
2.
3.
154
also performs ASN-level policy enforcement
using a local database and an associated local
policy function (LPF). The LPF can also be
used to enforce admission control based on
available resources.
SFM (service flow management, SFM): Is
responsible for the creation, admission, activation, modification, and deletion of 802.16
service flows. It consists of an Admission
Control (AC) function and the associated
local resource information.
PF (policy function, PF): Resides in both
home and the visited network, comprising
4.
5.
their respective databases. The databases
include general policy rules as well as
application-dependant policy rules.
AF (application function, AF): Hosts the
service logic and communicates the application level session information to PCRF
such as classifiers identifying service flows,
on which policy control and differentiated
charging is required.
AAA Server: Holds the subscriber’s QoS
profile and the associated policy rules per
subscriber. At first, when the user enter
WiMAX network,AAAserver will download
Vehicular Metropolitan Area Network Systems Architecture
users QoS parameters for Authentication and
Authorization. After that, AAA server can
also release these QoS parameters to PF that
PF can decide how to handle the message
form AAA server.
wimaX core neTwork planning
We believe that planning and modeling are important things for build a good network structure. In
this section, we suggest some factors needed to
consider in planning a telecommunication network
- 1. Network deployment 2. Quality of Service
management 3. Mobility management 4. Network
management. Based on these aspects, we’ll focus
on those managements and give more details:
1. Network deployment: Network deployment is the first consideration for telecommunication/wireless communication operators. The
WiMAX operator needs to figure out the capital
expenditure and operation expenditure on their
deployment scenario.
A. CAPEX: The capital expenditure (CAPEX)
includes the costs of wireless end device and
WiMAX equipment (e.g. BS/SS/RS), backhaul
link equipment, server and edge equipment. All
of the costs when we set up our environment are
contained in CAPEX. For example, spectrum
license is included in CAPEX, many WiMAX
equipments (802.16e BS/SS) are based on licensed bands (2.5G/3.5G), but some are based
on un-licensed bands. In licensed bands, we
need to consider how much bands that we need
to cover and how much cost we need to pay for
these bands which are differ from continuous or
non-continuous bands. The first WiMAX-certified
products will be operating in the licensed 3.5 GHz
frequency band, followed by systems for both the
2.5 GHz licensed band as well as the 5.8 GHz
license-exempt band. The important thing is to
add all of this payment in our CAPEX.
B. OPEX: An OPEX is an on-going cost
for running a product. For larger systems like
businesses, OPEX may also include the cost of
workers and facility expenses such as rent and
utilities. In the WiMAX core network structure,
OPEX are costs associated with the operation and
maintenance of an income producing property. It
includes accounting expenses, advertising, office
expenses, supplies, attorney fees, insurance and
property management.
C. Matching data density requirements to base
station capacity (Akyildiz et al., 1999)
D. For WiMAX deployment scenarios, data
density is an good metric for matching base station
capacity to market requirements. Demographic
information, including population, households,
and businesses per sq-km or per sq-mile, is readily available from a variety of sources for most
metropolitan areas. With this information and
the expected services to be offered along with
the expected market penetration, data density
requirements are easily calculated. This 6-step
process is summarized in Figure 11.
2. QoS of network management: The 802.16
standard provides some QoS designs in order to
achieve service quality demands, such as voice
and video quality. Also, ISPs have their own
QoS management schemes to provide different
fees for service items, which means the provided
solutions can be customized. Therefore, adequate
collocation of service levels and charges must be
considered so as to satisfy customers with fine
revenue.
3. Mobility management: A user can move
from the serving BS’s coverage to another
target BS’s service coverage. In this scenario,
user’s move involves handover processes. In
fact, Handoff processes consist of three phases:
handoff decision, radio link transfer and channel
assignment (WiMAX Forum, 2007). Considering
in handoff decision, several goals are important
while designing and evaluating mobility management procedures:
A.
Small signal overhead over the air
interface
155
Vehicular Metropolitan Area Network Systems Architecture
Figure 11. Determining market driven capacity requirements (Akyildiz et al., 1999)
Table 3. Factors of handoff decision
Factors
Network
provider
User
B.
C.
D.
E.
Details of factor
Bandwidth
Available bandwidth of a network
Coverage
Coverage of a network
Related service
Academic/ enterprise/ commercial
Connections
Support numbers of user
Mobility
Support mobility management or not
Network structure
WLAN/3G/3.5G/WiMAX
Application
The application running on mobile node(MN)
Power
Power consumption of MN
Price
Offers service’s fee to ISP or network provider
RSS
Received Signal Strength from base stations
Bandwidth
The minimum bandwidth that user needed
Packet loss
Packet loss of the connecting network
Low handover latency
Minimum packet losses during handover
Least handover failure
Efficient use of network resources
For the Network provider and user provider,
those are many factors that we can consider in.
However, we conclude from these observations.
Table 3 shows the factors on handoff decision
(WiMAX Forum, 2007):
4. Network management: While the network
is setup, the operation and management of WiMAX
network are required to handle by WiMAX operator. Those are the key points to maintain network
service. We also divide it into the following parts
in Table 4.
156
wimaX accounTing
archiTecTure
How to account and price in Wimax network?
802.16e working groups defined AAA- Authentication, Authorization and Accounting, and those
are a standard for security pricing system. About
the Authentication, we are already discussed
before. It implements security procedure with
IETF EAP framework. After that, WiMAX operator accounts for MS/SS based on some account
procedure.
Accounting architecture is shown in Figure
10.12. The figure shows network elements for
both postpaid and prepaid services. The figure
also shows the network elements for Hot-lining
support and negative volume count for ASN. A
Vehicular Metropolitan Area Network Systems Architecture
Table 4. Factors of network management
Content
Entity management
Content analysis
BS/ SS/ Router/ Switch management, and so on.
Integration
Integration WiMAX network and backbone network or others
network service (e.q PSTN, 3G)
Inventory management
Includes network resource as IP assignment and account for usage
of bandwidth
Network Planning
Network service
Coverage Ratio, radio resource and related network management
Charge user’s account and deal with permission of user
Billing service
Manage and price service level agreements (SLAs) for differentiated services
that use a simple upper bound for the effective bandwidth of the conforming
traffic as a proxy for resource usage.
customer relationship management (CRM)
Good running of customer relationship management give an
insight for firms to understand the market trend so that firms can
adapt the changing environment and anticipate the future needs
(e.g. web-site, customer service, maintenance)
Data mining
It can be used to uncover hidden patterns in data that have been
collected (e.g. user’s preference)
description of each entity is provided in the following sections.
NWG defined the Accounting Architecture
(Juo et al., 2008). As shown in Figure 10.12, it
contains NAP, Visited NSP and home NSP. All
of the operation and data flows are based on RADUS. The architecture defined offline (post-paid)
accounting, QoS-Based accounting, and online
(prepaid) accounting. These include the delivery
of information for the purpose of billing (both
prepaid and post paid billing) and information
that can be used to charge activity by both the
home NSP and visited NSP. These accounting
procedure are introduced as following:
Figure 12. WiMAX accounting architecture
157
Vehicular Metropolitan Area Network Systems Architecture
offline (post-paid) accounting
online (prepaid) accounting
We describe the off-line (post-paid) accounting
procedures and the Usage Data Records (UDRs) in
this part. The Serving ASN must merge radio specific parameters (number of bytes/packets transmit
at the BS) called Airlink Records with IP network
into the Usage Data Records (UDR). After that, the
Serving ASN uses RADIUS accounting messages
to send UDR information to the home RADIUS
Server (via the visited AAA server if the subscriber
is roaming). The Visited and Home RADIUS server
should be support the Accounting-Request records
as specified in (WiChorus, 2009) specification.
Based on the UDRs, Home AAA server can use
the records manage and account for MS.
This section describes the online (prepaid) billing procedures in the WiMAX core network.
The prepaid packet data service allows a user to
purchase packet data service in advance based on
volume or duration Account status is stored on a
prepaid server (PPS) that is located in the user’s
home network and accessed via the HAAA server.
To provide service to roaming prepaid users, the
visited ASN or CSN needs to support the prepaid
service and the local and broker AAA servers need
to forward the new prepaid accounting attributes
transparently to and from the home AAA server.
The HAAA server and the prepaid server could
be collocated or could be separate entities.
However, the architecture is a definition
for accounting procedure. Mostly, the operator
combines the online, offline, and QoS based accounting method in their service, and they use the
UDRs to charges for subscribers. For example, the
WiMAX operator needs to price for their subscribers. For simply, offline and QoS accounting are
pricing schemes for web surfing or downloading/
uploading of each subscriber. We denote it by
application service fee. Conversely, most operators charge the basic service fee in every month,
and come together with the service fee that we
called basic service fee. However, by using two
-part tariff strategy to subscriber is not always
better. Depending on different strategy of WiMAX
operator, the pricing scheme can be changed or
modified. Regarding the accounting methods, the
important thing is that WiMAX operator should
forecast the profit of a broadband access system
in MRT environment.
Qos-based accounting
The QoS-based accounting is based on user’s SLA.
For the basic service, WiMAX BS supports the
802.16 defined QoS classifications. But when user
bill payment for ensuring connection/bandwidth
thresholds, the UDRs are also includes these parameters for discount if there is a mistake for wireless
connection .for example, if the user chooses the
high bandwidth scheme, the Home AAA server
in CSN should support this pricing scenario for
bandwidth accounting. On the other hand, based on
different classifications, the QoS-based accounting
supports different applications. For example, when
we use the FTP, WiMAX operator may consider
user’s FTP’s UDR and charge activity with the
amount of FTP session’s packet. The scheme
may also consider the time of user’s connection.
For example, WiMAX operator focused on VoIP
application and Video on demand (VOD) application and charge with the time of these applications.
Based on these requirements, the Visited RADUIS,
Home RADIUS, ASN-gw and BS should support
the application’s accounting-Request records. In
this way, QoS-based accounting can be used in
WiMAX core network.
158
reFerences
Akyildiz, I. F., Ho, J., & Wang, W. (1999). Mobility
Management in Next-Generation Wireless Systems . Proceedings of the IEEE, 87(8), 1347–1384.
doi:10.1109/5.775420
Vehicular Metropolitan Area Network Systems Architecture
IETF Network Working Group. (2008). RFC3344IP Mobility Support for IPv4. Retrieved from
http://www.faqs.org/ rfcs/rfc3344.html
WiMAX Forum. (2007). WiMAX End-to-End
Network Systems Architecture Stage 3: Detailed
Protocols and Procedures, Release 1.1.0.
Juo, C. S., & Pan, J. Y. (2008). Software Agent
Framework for Dynamic Handoff Decision. In
APCC 2008, Akihabara, Tokyo, Japan. Ergen, M.
(2009). The Access Service Network in WiMAX:
The Role of ASN-GW.
WiMAX Forum. (2007). WiMAX End-to-End Network Systems Architecture, (Stage 2: Architecture
Tenets, Reference Model and Reference Points),
Release 1.1.0.
WiChorus, Inc. (2009). Retrieved from http://
www.mustafaergen.com/asn_gateway.pdf
WiMAX Forum. (n.d.). Wimax deployment consider for fixed wireless Access in 2.5GHz and
3.5GHz licensed bands.
159
160
Chapter 11
Interworking of IP Multimedia
Subsystem and Vehicular
Communication Gateway
Wei-Kuo Chiang
National Chung Cheng University, Chiaya, Taiwan, R.O.C.
An-Nie Ren
National Chung Cheng University, Chiaya, Taiwan, R.O.C.
Abstract
In recent years, more and more people dream of experiencing various IP-based multimedia application
services when they are driving through their car. However, those multimedia devices in the car may
use different communication protocols such as X.10, Havi, Jini, UPnP and SIP. In order to provide a
variety of IP-based multimedia services to those users in the car, the authors mainly investigate the issue of interworking between IP Multimedia Subsystem (IMS) and telematics of the vehicular industry.
A service-integrated platform, Open Service Gateway Initiative Service Platform (OSGi SP), has been
proposed to act as a Residential Gateway (RGW) and to administer the communication between the
vehicular environment and Internet. Besides, a Home IMS Gateway (HIGA), which can be implemented
on a NGN RGW, has been developed by Home Gateway Initiative (HGI) since 2005 to collect the relevant information of in-car users, devices and services and to manage the IMS sessions for the in-car
devices that do not support IMS functions. With these techniques, the users can enjoy their digital life
by interacting with the home/vehicular network from anywhere.
Introduction
Vehicular network has emerged as a hot research
issue recently. More and more people want to experience a variety of IP-based multimedia application services when they are driving through their
cars. However, those devices on the car may use
DOI: 10.4018/978-1-60566-840-6.ch011
different communication protocols. Due to the lack
of interoperability between all devices on the car,
a service-integrated platform is needed to provide
the characteristic of interoperability. On the respect
of home network environment, it will encounter
this problem as well. With the wide spreading of
the digital home products, Home Networking has
gradually been becoming a popular issue in recent
years. The Home Networking is a way to manage all
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Interworking of IP Multimedia Subsystem and Vehicular Communication Gateway
kinds of network devices or home electrical appliances; it allows the users to operate and manage
theses networking electrical appliances through
a unified interface or platform. These electrical
appliances represent all kinds of facilities that
have specified functions and could be controlled
or administered by using specified network media
or technology, e.g., X.10 device, HAVi device,
Jini device and UPnP device. One of the goals of
the Home Networking is to control the in-house
electrical appliances from the external network by
using hand-held devices (such as mobile phone,
PDA) to connect to the home gateway through
the IP network, and thus to control the electrical
appliances inside the Home Networking (e.g.,
lamps, air-conditioner, TV). Besides, if there happens any status changing to the in-house devices,
it (the networking system) could notify the user
immediately. In addition to the Home Networking
technology, we could also treat a car/vehicle or any
public transportation as a mobile home network
to integrate the home network and telematics of
the vehicle industry. In order to fulfill these goals,
there are yet some issues necessary to be discussed,
e.g., security, mobility, the interoperability among
the communication protocols, etc.
In recent years, because the growth speed of
the mobile devices and in-house network devices
becomes very fast and the communication protocols and home network/vehicular communication
technologies have undergone diversified changes,
these have made the intercommunication among
the-mentioned devices to be more difficult. For
example, the communication protocols adopted
by the in-house/in-car devices could probably
be UPnP, IP and SIP; therefore, an Open Service
Gateway Initiative (OSGi) has been proposed to
construct a service-integrated platform among
the Home Networking, vehicular communication
environment and the Internet.
Because the SIP communication protocol
possesses the capabilities of security mechanism,
event notification, media streaming and mobility
management among the terminals, so, concerning
the applications of remote accessing the home/
vehicular network, we will discuss how to support SIP on OSGi platform, how to utilize SIP as
an unity way for message control, and we will
further probe and discuss the mapping of control
messages between SIP and UPnP in order to solve
the interoperability problems among the devices
that adopt different communication protocols.
Since the IP-based network technology has
become more popular, the future communication
network will move toward the service integration
of the all-IP network and use the IP Multimedia
Subsystem (IMS) as a core network to provide a
variety of multimedia services. Therefore, integrating the IMS and the vehicular communication
environment will be a developing trend for future
network service providers. A user could then
monitor the in-car devices or access the data in
the multimedia storage device through his mobile
device in anytime and anywhere, this will bring
the user a richer experience in vehicular communication network.
relaTed works
sip (session initiation protocol)
SIP (Session Initiation Protocol) (Rosen et al.,
2002) is a communication protocol developed by
the MMUSIC (Multiparty Multimedia Session
Control) task group of IETF (Internet Engineering
Task Force). SIP is an application layer protocol for
session control and signaling control, it could be
used to initiate, modify and terminate sessions. The
SIP application range is very extensive, including
voice and video calls over Internet, video conferencing, presence service, event subscription/
notification and instant messaging. In November
of year 2000, SIP has been accepted by (The Third
Generation Partnership Project [3GPP], 2009) to
become the protocol for conveying communication control _ignaling and has been applied in the
IMS (IP Multimedia Subsystem) infrastructure of
161
Interworking of IP Multimedia Subsystem and Vehicular Communication Gateway
the Next Generation Network (NGN). This SIP
protocol could be used to establish and administer
the sessions in real time among the users, which
includes the application services such as text,
voice, picture, video and interactive gaming,
etc. It could also invite other users to join in an
established communication session to provide
a multicast conference service. SIP is similar to
HTTP (Hyper Text Transmission Protocol), both
are text-based communication protocols; SIP URI
(SIP Uniform Resource Identifier) address is exactly like an e-mail address, e.g., Alice@example.
com.In the following, we will simply introduce
the fundamental elements of SIP:
•
SIP user agents: User Agents are the
terminal equipments in the SIP network,
which could be SIP phone or the SIP client
software in a PC; it includes User Agent
Client (UAC) and User Agent Server
(UAS). UAC is responsible for generating requests, and UAS is responsible for
generating the corresponding responses
with respect to the received requests. Each
Figure 1. Architecture of SIP message flow
162
•
•
•
SIP User Agent will contain both UAC and
UAS functions.
SIP proxy: SIP Proxy is in charge of passing the received request to another SIP
component or SIP UA. When a SIP UA
sends a request, this message will not be
directly sent to the SIP UA at the destination terminal, it could be passed through
multiple SIP proxies before the request
message will be sent to the terminating SIP
UA.
Registrar server: Registrar Server is responsible for processing the SIP UA registration, and it is used to manage the certain
specified service as well as to update the
location information for the SIP UA.
Redirect server: When the Redirect
Server receives a request from SIP UA or
proxy, it will return with a Response of 3xx
to inform the SIP UA or the proxy that this
request should be directed to another SIP
component.
The SIP session establishment flow chart is
shown in Figure 1. Firstly, the terminating UA
Interworking of IP Multimedia Subsystem and Vehicular Communication Gateway
must register with the Registrar Server; the registrar will then save the UA location information
into the Location Server. After that, the originating
UA will send the request to the outgoing proxy;
the proxy will make an enquiry against the DNS
server for the incoming proxy address of the
terminating UA, and then pass this request to the
incoming proxy. The incoming proxy of terminating UA will then interrogate the Location Server
for the terminating UA address, and pass this
request to the terminating UA. When a session has
been established, the caller and the callee could
communicate by using RTP (Real-time Transport
Protocol) or other transmission protocols.
ims (ip multimedia subsystem)
The Next Generation Network (NGN) has integrated all types of heterogeneous networks
to provide the diverse, novel and personalized
multimedia application services. By observing
the past telecom network development, we could
see that, from 2G/2.5G to 3G/B3G and even the
3.5G/4G, the service technology development
has been evolving gradually from the traditional
voice communication service into the nowadays
all-IP network framework that uses the IMS (IP
Multimedia Subsystem) as its core; the system
provides the multimedia services such as video
phone, conference, VoD, OMA service enablers,
etc.
The IMS (3GPP TS 23.228, 2008; 3GPP TS
23.218, 2008) (see Figure 2) formulated by 3GPP
adopts SIP protocol as the communication basis,
it is a multimedia communication platform that
provides functions of session management, security, mobility, QoS and charging. IMS is widely
accepted as a network framework core that could
realize the Fixed Mobile Convergence (FMC) and
Triple Play Services and provide strong service
supports.
The Call Session Control Function (CSCF) of
IMS is the core component of IMS. Its purpose is
to process the signaling control for session set-up
between the users or between the user and the
server; it includes completing registration, basic
call control, SIP signal route control, service
trigger, etc. According to functional difference in
IMS, CSCF could be classified into Proxy Call
Session Control Function (P-CSCF), Interrogating Call Session Control Function (I-CSCF) and
Serving Call Session Control Function (S-CSCF).
The role of P-CSCF is just like a proxy server
that is responsible for forwarding the SIP message in IMS. P-CSCF also acts as an User Agent
(UA) in abnormal condition; I-CSCF is mainly in
Figure 2. 3GPP IP multimedia subsystem
163
Interworking of IP Multimedia Subsystem and Vehicular Communication Gateway
Figure 3. S-CSCF service triggering in IMS
charge of interrogating Home Subscriber Server
(HSS) and selecting a S-CSCF for the user, then
forwarding the SIP message to the S-CSCF; the
role S-CSCF plays is a registrar, it also controls
the execution of the communication (call) and
service triggering.
Home Subscriber Server (HSS) is the main
database of 3G telecom system. It is in charge of
storing the criteria of service triggering for the
user subscribed services. Application Server (AS)
is responsible for executing all kinds of service
logics, such as call forwarding, call waiting, voice
mail, etc. In addition, AS also provides SIP-based
service such as the services formulated by (Open
Mobile Alliance, 2009) ; those include Multimedia
Message Service (MMS), Push to talk over Cellular (PoC), mobile location service, etc. It is able to
provide the user with more extensive multimedia
services. And, S-CSCF could communicate with
AS that supports SIP interface by going through
IP Multimedia Service Control (ISC) that adopts
SIP as the communication protocol.
The IMS service triggering flow has been defined in 3GPP TS 23.218 (see Figure 3). The initial
requests sent by the user will be cross-compared to
initial Filter Criteria (iFC) that corresponds to the
164
added-value service subscribed by the user within
the service call control component (S-CSCF). If
they are conformable, then the application server
(AS) should be added into SIP call control signaling path; AS will monitor the call session set-up
status and decide whether to execute the addedvalue service subscribed by the user.
osgi (open service gateway initiative)
The full name of OSGi is (Open Service Gateway
Initiative, 2009). The generally mentioned OSGi
represents two meanings; it could represent the
OSGi Alliance organization and could also be the
service specification - OSGi service platform.
OSGi service platform is mainly developed basing on Java language; OSGi is a standardization
organization founded by Sun, IBM, Ericsson and
others in March, 1999. Its main goal is to provide
a complete solution for point to point service delivery between remote service provider and local
devices. Therefore, OSGi Alliance has defined a
open platform that allows the application program
and its value-added service of the remote service
provider to be downloaded at any time to the
Gateway nearby the user according to the user
Interworking of IP Multimedia Subsystem and Vehicular Communication Gateway
Figure 4. OSGi framework layering
demands; and it could be automatically installed.
The gateway is a common device used to connect
the home/vehicular network to Internet.
Observing from the framework view, OSGi
could be decomposed into three componenets:
Framework, Bundle and Service. The framework
is constructed on Java virtual machine and the
application program executed on the framework
is called bundle; the interface service provided
by or required by each bundle is called a service.
Bundle could be downloaded from the remote
service provider and be automatically installed
on the framework; after installing, the said bundle
could then be executed. Bundle will register the
service it provides in the OSGi platform and bundle
could also make a request upon OSGi platform
for the services provided by other bundles.
Framework is an integral information service
platform; its main function is to provide bundle
with an environment of execution and dynamically
to adjust the bundle life cycle. When a bundle has
been installed, it will register the service it provides
at the framework; however, when a bundle has
been suspended, the framework will dynamically
remove the services registered by the bundle. The
structure of framework could be divided into several layering; they are respectively security layer,
module layer, life cycle layer, service layer, and
etc.; as shown in Figure 4.
Bundle is an application program on an OSGi
framework, it could be activated and executed by
the OSGi framework. Since it is an application
program, to define the specified file format is required. An OSGi bundle is a Java Archive (JAR)
file; and the componenets included in each JAR
file are respectively Java class, Activator class,
Manifest header and some resource files (such as
HTML web page or some graphic files); in which,
the Manifest header mainly contains the description of that bundle information and will formulate some specifications such as Import-Packet,
Export-Packet, Bundle-Activator, Import-Service,
Export-Service, etc.
Bundle life cycle are mainly managed by
the OSGi framework, its life cycle could be divided into six states: INSTALLED, RESOLVED,
STARTING, ACTIVE, STOPPING and UNINSTALLED. The flow chart of the bundle life cycle
is shown in Figure 5.
After an OSGi bundle has been installed on
the framework, the services it provides could
be presented by a service. A service must be
a well-defined interface service. When each
bundle provides a service, the framework will
165
Interworking of IP Multimedia Subsystem and Vehicular Communication Gateway
Figure 5. Bundle life cycle
reserve a corresponding service reference; and,
when another bundle needs the service provided
by this bundle, an interrogation could be made
upon framework through LDAP (Lightweight
Directory Access Protocol) to acquire that service.
Inside the framework, an effective operation and
application shall be intercommunicated through
a series of services.
Concerning the services presently defined by
the OSGi specifications, those include: standard
services and custom services, the two are shown
in Figure 6. Standard services are provided by
framework itself; comparing to standard services,
custom services belong to the part that are defined
and developed by the vendors on their own. Each
vendor could develop its own bundle and the
corresponding service to segment the market of
the product.
After the above-mentioned introduction, we
could know that OSGi possesses the component
administration function and allows the user to
proceed with administration on components from
remote site; each OSGi framework will even
monitor the privilege of each bundle and differentiate the execution of each bundle. Based on the
viewpoints mentioned above, we may realize that
OSGi provides a safe environment for software
execution. If each bundle has enough privilege,
and the bundle could access the service provided
by the counter-party bundle among one another,
this will be helpful to the modularized program
design. OSGi itself provides automatic bundle
download, dynamic installation, registration and
bundle updating; in which, it is not necessary to
re-activate Java virtual machine and makes the
operation easier and more user-friendly.
For more detailed OSGi, one could refer to
the specifications published by OSGi Alliance.
Figure 6. OSGi standard services and custom services
166
Interworking of IP Multimedia Subsystem and Vehicular Communication Gateway
Release 4 has been developed to be the current
version, those who are interested in could visit
OSGi Alliance official web site to download.
upnp (universal plug and play)
Universal Plug and Play (UPnP, 2009) is a protocol
suite formulated by UPnP™ Forum founded in
October, 1990. The protocol vision is to establish
a seamless connection between the home network
(data sharing, communication and entertainment)
and the all kinds of devices within the enterprise
network, and to simplify the practice of relevant
network. In brief, it is expected that as long as each
device (e.g., computer, TV, fridge, air-conditioner,
alarm clock or lamps, etc.) has been connected to
the network, all the already on-net devices could
sense that there is a new device added in, these
devices could then communicate one another
and could be directly operated and controlled; no
configuration is required for any device; one could
fully enjoy the advantage of Plug and Play.
For example, assuming one has bought a printer
at home, if you expects this printer be shared and
be used by all in-house computers, you will have
to install this printer and set it to be sharable by
all. After that, you will also have to install this
network-shared printer on other computers; will
it cause too much trouble? However, if we adopt
UPnP as the intercommunication bridge for all
in-house devices, as long as both the home printer
and computer support UPnP, the user only needs
to hook up the newly-bought printer, then, all
in-house computers will notice that there is one
printer available; no any configuration is required
and the printer becomes usable. This is exactly
the vision that UPnP wishes to realize. Making
the configuration of the home network environment to be simplified could further enhance our
living quality.
UPnP is a technology realized on an open
point-to-point IP network of Plug and Play. It is a
type of web-based communication protocol; and,
it adopts the present widely used standards like
TCP/IP, UDP, HTTP, XML and SOAP to construct
the UPnP platform. UPnP features also include:
•
•
•
•
•
Media and device independence: UPnP
technology could be applied on many
transmission media including Ethernet,
IrDA, RF (Wi-Fi or Bluetooth), IEEE 1394
and Power lines.
User interface control: UPnP technology
has enabled the device vendors to control
the device and to inter-communicate among
one another through the web browser.
Operating system and programming
language independence: Any operating
system and program language could be adopted to construct UPnP products.
Program control: UPnP architecture also
enables the conventional application program control.
Extensibility: Each UPnP product can
have device-specific services be layered on
top of the basic architecture.
The basic components that the UPnP consists
of are Service, Device and Control Point. Service
is the minimum control unit in UPnP; service provides operative actions and a set of status variables
to record the current status of this service; device
represents an UPnP device, the device is the facility that includes services. For example, a DVD
player provides video-broadcasting service; the
control point is able to control the device found
in the UPnP network.
In the following, we will give a simple introduction to UPnP protocol stack as shown in
Figure 7:
•
•
HTTPU/HTTPMU: These two communication protocols are extensions of HTTP.
They use UDP/IP to transmit the data, and
they are used by SSDP as well.
SSDP: Its full name is Simple Service
Discovery Protocol; it is a communication protocol built in HTTPU/HTTPMU; it
167
Interworking of IP Multimedia Subsystem and Vehicular Communication Gateway
Figure 7. UPnP protocol stack
defines mainly how to make the services
be found out; it includes how the control
point could find out what services exist on
the network and access to the relevant information about these services; that the device itself claim what services it could provide is also completed through this SSDP
protocol.
•
SOAP: Its full name is Simple Object
Access Protocol. It mainly defines how to
use XML and HTTP to execute the remote
procedure call.
•
GENA: The full name is Generic Event
Notification Architecture; it is mainly adopted to process the transmitting and receiving of subscription and notification
messages.
As to the communication between the device
and control point, it could be separated as the
following six phases:
•
168
Addressing: It is the initialization step for
a device to add into the UPnP network. In
order to intercommunicate with the components in UPnP network, each control
point and device must have an IP address.
•
•
The way to get an IP address could be done
by using DHCP or using auto IP to get the
network address.
Discovery: It allows the control point to
find out the service of its interest. When
a device is added into the network, that
the device will broadcast its services to
the control point in the network; when a
control point adds into the network, it will
search the device of its interest in the UPnP
network. Using SSDP via HTTP/HTTPMU
completes all these actions.
Description: When a control point has
found out the device from the step of
Discovery, because the control point has
pretty limited knowledge about that device, if it intends to further understand the
device function or to interact with that device, it will use the device XML address
obtained in the Discovery step to acquire
the XML document of the device description. This document includes the device
name, serial number and manufacturer, the
actions and status variables provided by
the device and the URL web address for
controlling this device.
Interworking of IP Multimedia Subsystem and Vehicular Communication Gateway
•
•
•
Control: When a control point intends to
control a device, it will transmit a proper
control message to the service URL according to the information acquired from
Description phase, this control message is
expressed in XML format by using SOAP
protocol. When a device receives this message, it will act to change the corresponding variables and then forward back to the
control point; if this action fails, it will return an error code.
Event: A control point could subscribe the
status variable of its interesting device.
When the status on a device changes, the
device will issue an Event message, and
use GENA protocol to pass this message
back to the control point. This Event message is also expressed in XML format.
Presentation: If that device has a web GUI
for web page presentation, then the control
point will load that page into the browser,
and then the control point could inspect the
device status and control the device from
that web page.
The above is a simple introduction of UPnP; it
describes the operating environment and features
of UPnP, UPnP protocol stack and every single
phase when being used.
dlna (digital living network alliance)
DLNA is the abbreviation of (Digital Living
Network Alliance, 2009). It is an alliance organization founded in 2003, which consists of
the vendors from consumer electronic products,
mobile phones and computers. The organization
goal is to establish a set of standard specifications that could allow the video/audio facilities
of different manufacturers and different types to
be inter-connectable and mutually adaptive to
one another, and to realize the digital life for the
customers. As long as the user stays anywhere
at home, he could access the photos, music and
video films via the network. Therefore, as long
as the video facilities are conformable to DLNA,
they could be directly connected, synchronized
and adopted for data transmission to one another
without any driver and any interconnecting device.
Till the year of 2008, DLNA alliance members
have been reaching 245 (vendors), it includes
quite a few manufacturing leaders of electronic
products such as HP, Intel, Microsoft, IBM, Panasonic, LG, Philips, SONY, Toshiba, Motorola,
Nokia, Samsung, etc. Till September of 2008,
there are over 3000 kinds of products that have
passed DLNA certification.
The product specifications defined in “Interoperability Guidelines, Version 1.0” by DLNA
in June, 2004 contain the key components as
follows:
•
•
DMS (Digital Media Server): It provides
the functions of media file access, recording/producing, storing and being used as
a source, it is just like a multimedia file
server. This type of device includes set-top
box, video (DVD) player, PC with built-in
media server function, broadcast receiver
and HD-embedded home theatre.
DMP (Digital Media Player): This device
generally represents a device that could
search and play or output any media file
provided by DMS; these types of devices
include TV, printer, home theatre, multimedia cellular, PDA and some specified
game terminal machine. “Interoperability
Guidelines, Version 1.5” is the recent version published in March of 2006, and, it
has been partially expanded in October of
the same year. Inside the v1.5 specification,
several product specifications have been
added in addition to the previous DMS and
DMP. It includes:
◦
M-DMS (Mobile Digital Media
Server): It is the server defined specifically against the electronic products like handheld mobile phone that
169
Interworking of IP Multimedia Subsystem and Vehicular Communication Gateway
◦
◦
◦
is smaller in size, light in weight and
portable; the multimedia format it
supports is somewhat different from
that of the general DMS.
M-DMP (Mobile Digital Media
Player): It is also designed specifically for the player of mobile device;
the multimedia format it supports is
somewhat different from that of the
general DMP.
DMC (Digital Media Controller):
When used as a remote device, it
could search the multimedia files that
could be played on DMS and could
assign the DMP either to play that
multimedia file or to control the multimedia file uploading or downloading to DMS. In addition to remote
device, an intelligent device equipped
with basic operation interface could
also be used as DMC.
DMPr (Digital Media Printer): A
DMPr printer could provide printing
function under the DLNA network
framework. Basically, the DMPr
printer function is similar to the traditional USB printer.
Concerning the mutual detection among one
another facilities, the UPnP standard introduced
in previous section is adopted. DMP facility could
search the mutually matched DMS facilities on
the network via UPnP mechanism, after successful
connection, one could proceed with the following
playing or data transmission actions. These actions
are all automatic, the user needs not to do extra
configuration. As to the media content discovery,
it adopts also the UPnP mechanism. Presently,
it adopts HTTP standard protocol regarding the
transmission. RTP will be then added in the future
version and be used as the protocol for performing
audio and video streaming.
In the multimedia formats that DLNA supports
for transmission, it is divided again into required
170
Figure 8. DLNA certified logo (Source: DLNA
Website)
support and optional support. The graphic file format of required support is JPEG, audio format is
LPCM, video format is MPEG-2; and, the graphic
file formats of optional support are PNG, GIF and
TIFF, audio compression formats are AAC, AC-3,
MP3 and WMA9, the video compression formats
contain MPEG-1, MPEG-4, AVC, WMV9, etc.
For product test and certification, DLNA
provides standard specification and the software
program that allows each vendor to do the selftest. The vendor could do the self-test first and
verify its normal execution, then, sent to DLNA
certifying organization for further certification.
After passing the certification, vendor will be
awarded DLNA certification emblem as shown
in Figure 8.
Every single famous consumer electronic
product manufacturer has seen the DLNA vision relatively promising. The currently adopted
method for solving the mutual communication
among the facilities is also suitable, however, the
present DLNA standard specification may be still
in some way not enough, such as the Digital Right
Management (DRM) of the multimedia file has
been in great short, and at the same time, it also
lacks security protection mechanism; it could
be easily attacked by hackers or virus and thus
causes the hidden concerning about the whole
DLNA environment. Since DLNA has formulated
the key product categories and network protocol
framework, this allows the products made by
different vendors to have a mutually communicative interface and platform, and solidly makes
the vision of digital home/vehicular network be
realizable in the coming years of near future.
Interworking of IP Multimedia Subsystem and Vehicular Communication Gateway
inTerworking archiTecTure
and design
design of osgi gateway
that supports sip
In a car, there could exist many kinds of network
devices and Networked Appliances (NAs), the
communication protocols adopted by different
devices are also not all the same; in order to
make in-car NAs to be able to inter-communicate
with each other and to have a unified interface to
administer and control NAs, OSGi Alliance has
formulated a open service platform named OSGi
Service Platform (abbreviated as OSGi SP) to assist in administering and controlling in-car NAs
(such as X.10 device, HAVi device, Jini device,
UPnP device, etc.).
After having OSGi SP, in order to allow the
user to be able to remotely control the in-car NAs,
one must make some updating and modifications
on the OSGi SP; to allow the user to connect via
the network to OSGi Residential Gateway (RGW)
even out of car and to further control the in-car
NAs (the OSGi SP is practically implemented
on the OSGi RGW). Here, we will discuss the
technology regarding the user’s utilization of SIP
device outside the house to transmit SIP message
to remotely control the in-car devices.
The applied network framework is shown in
Figure 11.9. In order to let the user be able to
communicate with each other while using devices
of different communication protocols (UPnP or
SIP device), except the OSGi Service Bundle that
OSGi already supports, one must depend on SIP
Service Bundle and Bridging Bundle (Bushmitch
et al., 2004; Brown et al., 2006) that have been
provided additionally by OSGi platform. OSGi
Service Bundle provides the methods of device
discovery and communication; the major function of SIP Service Bundle is to enable the device
and the bundles to communicate with each other
through SIP and to fulfill the functions of device
mobility and service mobility, etc. Besides, SIP
Service Bundle could be used to bridge two or
more than two OSGi RGWs on the cars to make the
RGWs to be communicative with each other.
After having SIP Service Bundle and Bridging
Bundle, an outside user could use his SIP device
to transmit SIP message to remotely control the
NAs on the car. Firstly, after the outside user
sends out the SIP message, the message will be
sent to OSGi RGW via the SIP Proxy Server on
the Internet, and then gone through the SIP proxy
Figure 9. OSGi residential gateway supporting SIP
171
Interworking of IP Multimedia Subsystem and Vehicular Communication Gateway
Figure 10. SIP service bundle(Brown et al., 2006)
server provided by SIP Service Bundle, the SIP
message will be sent to a SIP UA. The SIP UA
could probably be the SIP UA built in SIP device,
it could also be the virtual SIP UA offered by SIP
Service Bundle. The former will directly send the
SIP message to that SIP device and let the SIP
device process the received messages by itself;
the latter will be forwarded to Bridging Bundle,
the SIP message will be translated into certain
specific message that is able to control the NAs
(e.g., UPnP message format).
In the following section, we will sequentially
introduce the functional components and their
operation modes of SIP Service Bundle and
Bridging Bundle.
SIP Service Bundle
As shown in Figure 10, SIP Service Bundle exists
in a form of OSGi bundle within the OSGi framework; that responsible for providing SIP support
for OSGi Bundles and the device that registers
in OSGi is its major function. The features of
SIP Service Bundle contain service registration,
messaging, event subscription/notification and
the complete SIP proxy and SIP server functions. Once the bundle activates, it will make a
registration in OSGi service registry to become
172
a SIP service. After the SIP bundle registering,
other bundles could then use this SIP service to
register to become a SIP device. Then, the outside
user could control the in-car SIP device via the
SIP message.
SIP Service consists mainly of three objects;
they are respectively SIPServer, SIPDevice and
SIPUserAgent.
SIPServer – SIPServer, this object represents
the SIP Service server (proxy/registrar) in OSGi
RGW. If being served as a proxy server, it will accept the registration message sent from SIP device
or bundles, and send the received SIP message
to the registered SIP UA. In addition, SIPServer
could serve as a registrar server, allowing SIP
device or the non-SIP device of SIPUserAgent
to register with the registrar, and providing some
additional ways for the non-SIP device to be able
to register with the registrar server located at the
external network. Using SIPServer object could
let SIP Service Bundle have the following several
functions:
1.
Asking a SIPUserAgent to serve as a virtual
SIP UA: When there is a non-SIP device
that intends to register with a registrar
server, the SIP Service Bundle will request
a SIPUserAgent to serve as a virtual SIP
Interworking of IP Multimedia Subsystem and Vehicular Communication Gateway
2.
3.
UA. A virtual SIP UA has all SIP capabilities, but it is not a physical SIP device. Once
SIPUserAgent has been produced, it could
automatically register with the registrar
server.
To acquire a SIPDevice object that represents that device for any virtual or physical SIP device that has registered with the
OSGi framework: the SIP server must be
responsible for doing a service registry on
the OSGi framework for those SIP devices
that have registered with the SIP server, to
register them as the SIPDevice service. After
that, the other bundles in OSGi framework
could then use those SIP devices.
All of the SIP Service Bundle relevant events
that happened in OSGi framework will notify
with the SIP Service Bundle. For example:
the devices registering/unregistering.
SIPDevice: SIPDevice, this object could
represent a physical SIP device and could also
represent a virtual SIP device. A SIP device could
register with the registrar to become a physical
SIP device; a non-SIP device could register as a
virtual SIP device. This virtual SIP device is just
a bundle that requests a SIPUserAgent function.
When a device has finished the registration, the
SIP Service Bundle will produce a SIPDevice
object for that device to represent it. This will
allow other bundles in the OSGi framework to be
able to control the device which the SIPDevice
represents.
SIPUserAgent: When a non-SIP device
intends to register with a registrar server or
communicate with other SIP devices, it must
support the function of SIP UA. The SIP device
itself supports SIP UA, so it could register with
registrar server or communicate with other SIP
devices directly. However, a non-SIP device (such
as air-conditioner, fridge or lamp) must ask SIP
Service Bundle for a SIPUserAgent to serve as a
virtual SIP UA in order to register with registrar
to become a virtual SIP device or to communicate
with other SIP devices.
Bridging Bundle
In order to perform the message translation
between two devices that adopt different com-
Figure 11.SIP-UPnP bridging scenario (Brown et al., 2006)
173
Interworking of IP Multimedia Subsystem and Vehicular Communication Gateway
munication protocols, bridging is a compulsory
process. Bridging is a mechanism of applicationlayer proxying. For example, translating the SIP
message into UPnP message or translating the
UPnP message into the SIP message. The software
developer could use the Application Programming
Interface (API) provided by OSGi platform to
import the required package (such as org.osgi.
service.upnp or org.osgi.framework), he could
then develop his own Bridging Bundles (such as
SIP-UPnP Bridging Bundle).
Bridging Bundle is an OSGi bundle. It possesses the functions of asking a SIP UA from
the SIP Service Bundle and could also ask the
OSGi Service Bundle for an UPnP function. So,
the devices that adopt different communication
protocols could intercommunicate with each other
via different types of Bridging Bundles.
One of the bridging examples is to utilize a portable SIP mobile light control device to remotely
observe and control the in-car UPnP desk lamp
status. Here, we assumed the desk lamps are all
UPnP devices. This kind of application example
is to elucidate that no matter where the users are,
they could remotely control the in-car devices via
the network. This SIP lighting controller could
acquire the UPnP desk lamp relevant information from the vehicular UPnP network environment via Bridging Bundle. The controller cannot
directly use the infrared technology to control
the desk lamp; on the contrary, it has to depend
on the Bridging Bundle to interrogate the UPnP
Service. The controller could also subscribe the
status changes with respect to every desk lamp.
Therefore, Bridging Bundle will listen the event
messages of all in-car desk lamps and utilize the
SIP NOTIFY message to forward the received
event message to controller. In order to control
this UPnP light, controller will send out SIP
MESSAGE to Bridging Bundle, and the Bridging
Bundle will translate the SIP MESSAGE contents
into the function call of UPnP Service API; in
the end, it will produce SOAP control message
and send them to UPnP light (the desk lamp).
174
Please refer to Figure 11 for the flow chart of this
example. This type of bridging is applied on the
same OSGi platform; and for the other type of
application, it belongs to two devices that adopts
different communication protocols; about how to
mutually communicate with each other across the
different OSGi platforms. In the next section, we
will briefly introduce how the bridging operates
across the OSGi platforms.
inter-gateway bridging
In the previous section, we have introduced how to
enable the mutual communication between the SIP
and UPnP device via an OSGi RGW. Therefore,
in this section, what we will discuss is another
situation of application. Assuming the user owns
some UPnP devices and an OSGi RGW in his
house. When he drives his car which equipped
with an OSGi RGW to travel, if he wishes to access the data in his home UPnP device, he must
rely on the assistance of the SIP Service Bundle
and Bridging Bundle embedded on the present
mobile RGW on his car and the in-house home
RGW in order to translate the SIP and UPnP messages properly.
As shown in Figure 12, if a user owns an UPnP
DVD player at home, and this DVD video recording/player has registered with the SIP registrar
server in the SIP Service Bundle to become a
virtual SIP device. Assuming the user wishes to
use the UPnP TV on his car to connect back to
the DVD video player at his home to watch the
film stored in the DVD player.
First, the user will operate this UPnP TV, the
TV sends out UPnP message (SOAP) to the UPnP
Service Bundle. This UPnP Service Bundle is
responsible for providing the relevant information of the service and device that exist on every
registered UPnP device. UPnP service will pass
the message to OSGi service registry via service
API. OSGi service registry will then pass the UPnP
control message to SIP-UPnP Bridging Bundle.
Therefore, UPnP message will be translated into
Interworking of IP Multimedia Subsystem and Vehicular Communication Gateway
Figure 12. Inter-Gateway bridging example
SIP message in SIP-UPnP Bridging Bundle, and,
be sent to virtual SIP UA that the UPnP TV has
registered on the SIP Service Bundle. In the end,
via the SIP Service Bundle on the mobile RGW,
the SIP message is sent back to SIP Service Bundle
on the home RGW. The processing sequence of
this message in the home RGW is contrary to that
in the mobile RGW, and the SIP message will be
translated into the UPnP message in XML format
inside the SIP-UPnP Bridging Bundle of the home
RGW, and sent to UPnP DVD player. Therefore,
the user could establish the RTP package route
between mobile RGW and home RGW, and pass
the RTP stream from the UPnP DVD video player
located at the home RGW to the UPnP TV located
at mobile RGW. This is an example of integrating
home network and vehicular network through
inter-gateway bridging.
sip and upnp mapping
UPnP has adopted many standard communication
protocols in order to make it compatible with the
present network communication protocols; therefore, UPnP could be a cross-platform protocol.
Except the often heard protocols – IP, TCP, UDP
and HTTP, in the following, some examples will
be given regarding the not-often-heard UPnP
protocols:
SSDP (Simple Service
Discovery Protocol)
It is used when the UPnP intends to execute the
Discovery phase. It is exactly the timing when
the control point of the home/vehicular network
(exactly the above-mentioned RGW) interrogates
175
Interworking of IP Multimedia Subsystem and Vehicular Communication Gateway
the device of its interest about what services
are available or when a device is added into the
UPnP network, it will automatically broadcast
the services it provides to inform the control
point or RGW.
SOAP (Simple Object Access Protocol)
It is used when the UPnP intends to execute the
Control phase. Once the control point or RGW has
acquired the relevant description of certain specific
device, it will be known that what actions could
be applied on that device, so, the control point or
RGW will use the SOAP to issue commands to
control the status of that device.
GENA (General Event
Notification Architecture)
It is used when the UPnP intends to execute the
Event phase. The user could subscribe the device
it intends to control via the control point or RGW;
if the status of that device has changed, the device
could use GENA to issue the event notification
to the control point or RGW to inform its present
status of that device.
The mapping way between SIP and UPnP is to
utilize SIP message to control UPnP device and the
event notification. Therefore, regarding the message interchange method between SIP and UPnP,
except the above-mentioned UPnP communication method, it also includes three types of major
SIP communication ways; they are respectively
SUBSCRIBE, NOTIFY and MESSAGE. In the
following, we will introduce how SIP and UPnP
could achieve the messages translation.
SUBSCRIBE/NOTIFY
When an outside user wishes to use the SIP device
registered in the RGW to connect back to the OSGi
RGW on the car and ask to access some functions
provided by the UPnP device of interest and the
detailed information. At this moment, the user will
176
use his SIP device to send out SIP SUBSCRIBE
message to RGW, and the RGW will use the UPnP
device address acquired during the Discovery
phase to execute the Description phase by using
HTTP (please refer to UPnP introduction). That
UPnP device will utilize HTTP to return the detailed information in XML format to OSGi RGW,
and the Bridging Bundle in OSGi RGW will then
translate this message into SIP NOTIFY message
and send it back to the SIP device.
In addition, a user could subscribe the device
status from OSGi RGW in advance. When the
status of that device changes, the OSGi RGW has
to inform the SIP device. First, the user will send
out SIP SUBSCRIBE message to OSGi RGW via
his SIP device, once the status of the UPnP device
that we intend to subscribe has changed, the UPnP
device will use GENA protocol in XML format to
send the event message back to OSGi RGW; then,
the Bridging Bundle in OSGi RGW will translate
this message into SIP NOTIFY message and send
back to the SIP device to inform the status change
of that UPnP device.
MESSAGE
After the SIP device has acquired the detailed
description of the UPnP device one wishes to
control, one could send out the SIP MESSAGE
to OSGi RGW. The Bridging Bundle in OSGi
RGW will again translate this SIP message in
XML format and use SOAP protocol to control
UPnP device.
integrating ims and dlna
connected home
The concept of Connected Home is originated from
the common vision of DLNA alliance and UPnP
organization. No matter what brand the home
devices belong to, they could communicate with
each other, share the multimedia data, the home
surveillance and remote access service. However,
in order to let a user access remotely the device
Interworking of IP Multimedia Subsystem and Vehicular Communication Gateway
at home/car and enjoy the guarantee of security
and quality of service at the same time, it must
need a reliable system to achieve the remote access service.
In order to achieve this goal, Ericsson has
proposed a framework (Fasbender et al., 2008)
that has combined the advantages of IMS, DLNA
and UPnP as shown in Figure 13. The user does
not need to purchase extra specific device; this
architecture utilizes the existing IMS framework
to provide the authentication and authorization of
the user identity, message route, and to establish
the secured multimedia sessions and QoS guarantee. Besides, the design of this framework is
fully conformable to the present standard of the
consumer electronic products for providing multimedia data sharing and service delivering. The
core component in this framework is the Home
IMS Gateway (HIGA) functional component
that Ericsson has continuingly developed on the
Residential Gateway (RGW) since 2005.
higa (home ims gateway)
HIGA is currently formulated by the two organizations of (Home Gateway Initiative, 2007; ETSI
TISPAN, 2008). It is a standard of NGN home
gateway; it can be regarded as a gateway on the
car as well. HIGA is a functional component operating on RGW. It is responsible for collecting
the relevant information of the in-house/in-car
users, devices and services, and managing the IMS
session for the home/ in-car devices that do not
support IMS function. With the HIGA, RGW then
contains an ISIM card (IMS Subscriber Identity
Module Card), it allows the in-car devices to access the services provided by IMS network via
the RGW. HIGA will also perform the translation between the protocols adopted by the in-car
devices and IMS/SIP.
HIGA could use IMS SIM card to register with
IMS core network in the secured authentication
method. The in-car devices could communicate
Figure 13. High-level remote access architecture (Fasbender et al, 2008)
177
Interworking of IP Multimedia Subsystem and Vehicular Communication Gateway
with the IMS network through the HIGA which is
equipped with the functionalities of Back-to-Back
UA (B2BUA) and SIP UA. For example, there
is a SIP VoIP phone on the car, this phone could
then register with HIGA by using the SIP UA it
owns by itself, the B2BUA in HIGA could then
translate this SIP message into the IMS specified
message and forward to IMS network.
In reality, this framework is an extension of
UPnP Remote Access standard; making it be
able to support IMS Remote Access and allowing the concept of DLNA Connected Home to
be extended to the outside of the home. The two
major functional modules of UPnP Remote Access framework are Remote Access Transport
Agent (RATA) and Remote Access Discovery
Agent (RADA). These two kinds of modules will
be implemented on the Remote Access Client
(RAC) and the Remote Access Server (RAS).
RATA is used to establish a secured communication channel between the Remote UE (User
Equipment) and the Vehicular Network; RADA
is used to synchronize the UPnP device message
Figure 14. Functional architecture
178
and inter-changed contents between RAC and
Vehicular Network.
Regarding all of the devices included in this
framework (Remote UE, Residential Gateway
with HIGA and DLNA Devices), one could refer
to Figure 14 for the block diagram of functional
components that are supposed to be equipped.
HIGA could be implemented on any in-car device,
but practically speaking, implementing directly
the HIGA on RGW will be the most simple and
of highest feasibility because RGW itself supports
Network Address Translation (NAT) and Firewall
(FW) functions. If the HIGA function is integrated
into RGW, when a user at outside wishes to access the in-car devices, this HIGA will be like
an end point of the signaling delivering in the
IMS network; and, in the vehicular network, the
HIGA will be like an UPnP device that intends to
send the message to the in-car device. In the very
timing that makes the vehicular network and next
generation all-IP network to be closely integrated,
not only it could provide diverse IMS multimedia
integrated services to the user, it could also allow the user to access any device of his own no
Interworking of IP Multimedia Subsystem and Vehicular Communication Gateway
matter anywhere, this will make our lives more
convenient and digitized.
ims approach for remote access
With the supports of DLNA and UPnP in the
vehicular communication environment, we could
establish the remote access session between the
Remote UE and the RGW that supports HIGA via
the IMS cooperation. Assuming the Remote UE
has a digital multimedia renderer (DMR) which
supports DLNA, the Network Attached Storage
(NAS) supports the function of digital multimedia
server (DMS), and both the Remote UE and HIGA
have registered with IMS and could connect to
IMS network. Therefore, the outside IMS user
could connect to the RGW on the car via the IP
Multimedia Public Identity (IMPU) of the HIGA.
The flow example that uses IMS to proceed with
remote access could be divided into six phases as
shown in Figure 15.
Phase 1: Connection Request
Assuming Alice is traveling outside the country,
she wishes to access the video film stored in the
NAS via her mobile device (in this example, it is
the Remote UE); the Remote-Access application
on her device will send out the IMS INVITE message to the HIGA on her car. When the INVITE
message passes IMS network, the user’s IMS
home network will add a P-Asserted-Identity into
the INVITE message. At this moment, the HIGA
will cross-compare the P-Asserted-Identity and
the permitted user identities to verify the Remote
UE. The SDP (Session Description Protocol)
packed in IMS message will be used to inform the
RAS located in the HIGA and the RAC inside the
Remote UE of the IP address and the port number
of the remote access tunnel. The SDP parameters
are also used to negotiate the administration of
the virtual private network tunnel (VPN tunnel)
and encrypted keys that are established between
Remote UE and HIGA.
Figure 15.Session setup flow between remote UE, HIGA and NAS (Fasbender et al., 2008)
179
Interworking of IP Multimedia Subsystem and Vehicular Communication Gateway
Phase 2: Peer-to-Peer VPN Setup
over the IMS Media Plane
Once the Alice’s device has completed its authentication and authorization procedures, the device
has then established a secured media transmission
mechanism with HIGA. The connection method
adopted by Ericsson will set up the connection
flow according to the IMS standard and will
make HIGA as the VPN server. Therefore, after
the tunnel has been established, the connection
between the Alice’s device and the in-car NAS
will be exactly like the UPnP connection at the
local terminal.
Phase 3: UPnP Discovery
The original design of UPnP is to allow the device
to be able to mutually communicate with each other
in a LAN, if one wishes to extend the UPnP to a
WAN, one will surely be confronted with some
problems. For example, UPnP is using a messageinterchanging method of multicast to find out the
UPnP device. However, these multicast packets
will be discarded by the routers located on the
Internet. Nevertheless, the remote access method
formulated in UPnP Remote Access standard could
allow the UPnP RAS filtering device to dig out
some relevant messages, and using unicast method
to transmit the message of device discovery to the
Alice’s device located outside.
If adopting UPnP RADA mechanism, it could
make the RAC of the Alice’s mobile device to
be synchronized with the RAS on HIGA, then,
Alice could use her device to access those available multimedia servers and the UPnP services
provided by the server. RADA could be used to
dynamically inform the Alice device of what new
devices have been added on the car.
multimedia contents are available, and could
choose to playback the mentioned multimedia file
by downloading or via streaming method. If one
wishes to forward any multimedia data through
the VPN connection built in phase 2 in the IMS
media plane, one could forward the data by using
HTTP (the DLNA default transmission protocol)
or RTP (DLNA extra supported transmission
protocol).
Phase 5: IMS Media
Plane QoS Upgrade
UPnP does not support QoS management in
LAN. But, after integrating the telematics and IP
Multimedia Sub-system, one could use the QoS
supported by IMS standard to make it be able to
support the QoS control and administration between the remote UE (Alice’s device) and HIGA.
If it is expected to update some QoS parameters
for Alice’s device, the device could send out reINVITE or UPDATE message to the IMS network
and HIGA to update the QoS status.
Phase 6: Content Playout
In the last, the multimedia data chosen by Alice
could then be played on her mobile device.
With the IMS-based remote access support,
it could make up some defects that the original
UPnP remote access lacks. Those defects include
some security holes, the authentication of remote
user and the QoS provision. Therefore, the DLNA/
UPnP applications can be extended to the main
system of NGN, it could make the vehicular
network and mobile communication network to
be more diverse and allow the user to have richer
experience in the world of multimedia network.
Phase 4: Content Selection
conclusion
Alice chooses the NAS, using UPnP Content
Directory Service (CDS) to browse what the
In vehicular network applications, in addition to
solving the mutual communication issue among
180
Interworking of IP Multimedia Subsystem and Vehicular Communication Gateway
the devices in every single vehicular network,
one needs to consider the connectivity of several
vehicular networks. This will allow us to make a
connection back to the RGW on the car no matter
where we are to achieve the goals of remote access
control and multimedia data sharing, etc. But, the
above applications do not possess enough security
authentication mechanism with respect to the vehicular network; besides, it lacks certain degree of
QoS guarantee regarding the multimedia contents
that the user wants to transmit. So, in recent years,
there are some organizations of standardization
that are formulating the integration framework
between the digital home and IMS. The design of
this framework requires totally no modification
on the present existing terminal equipments (such
as IP devices, SIP devices, Bluetooth devices
and UPnP devices), it only requires extra adding
of HIGA functional component on RGW, it will
enable the in-house/in-car devices to access IMS
services via RGW, and it also allows the user to
connect to the RGW anywhere via the reliable
authentication mechanism provided by IMS to
perform a further control on the in-house/in-car
devices.
Because the most time of our lives are spent
either out of home, in the office or on the way
to somewhere, so, except to integrate the home/
vehicular network with next generation all-IP
network framework, on the other hand, DLNA
standard is expected to integrate the home network
and telematics of the vehicle industry. We could
treat a car or any public transportation as a mobile
home network, and could also regard a car as a
device for remote accessing to home network;
allowing the user to connect back home to access
any multimedia data while he is on a vehicle and
to administer or control the devices in house. By
allowing the user to be able to interact with the
home/vehicular network no matter at anywhere,
this could then connect more closely our network
world together.
reFerences
Alliance, O. M. (OMA). (2009). Retrieved from
http://www.openmobilealliance.org/
Brown, A., Kolberg, M., Bushmitch, D., Lomako,
G., & Ma, M. (2006). A SIP-based OSGi Device
Communication Service for Mobile Personal
Area Networks. In Consumer Communications
and Networking Conference(CCNC).
Bushmitch, D. Lin, Wanrong., Bieszczad, A., Kaplan, A., Papageorgiou, V., & Pakstas, A. (2004).
A SIP-based device communication service for
OSGi framework. IEEE Consumer Communications and Networking Conference2006.
DLNA. (2009). Retrieved from http://www.dlna.
org/home
ETSI TISPAN. (2008). Retrieved from http://
www.etsi.org/tispan/
Fasbender, A., Gerdes, M., Hjelm, J., Kvarnström,
B., Petersson, J., & Skog, R. (2008). Virtually
at home: High-performance access to personal
media. Ericsson Review, 2.
3GPP. (2008). IP Multimedia Subsystem (IMS);
Stage 2, TS23.228 v8.6.0.
3GPP. (2008). IP Multimedia (IM) Session
Handling; IM Call Model; Stage 2. TS 23.218
v8.3.0.
Home Gateway Initiative. (2007). Retrieved from
http://www.homegatewayinitiative.org/
Open Service Gateway Initiative (OSGi). (2009).
Retrieved from http://www.osgi.org
Rosen, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., et al. (2002). SIP:
Session Initiation Protocol. IETF RFC 3261.
Third Generation Partnership Project [3GPP].
(2009). Retrieved from http://www.3gpp.org
UPnP Forum. (2009). Retrieved from http://www.
upnp.org
181
Section 5
Vehicular Ad Hoc Networks and
Delay Tolerant Vehicular
Networks
183
Chapter 12
MAC Protocols in Vehicular
Ad Hoc Networks
Chih-Yung Chang
Tamkang University, Taiwan, R.O.C.
absTracT
With the rapid development of wireless technologies, the Vehicular Ad Hoc Networks (VANETs) have
recently received much attention. VANETs technologies aim to ensure traffic safety for drivers, provide
comfort for passengers and reduce transportation time and fuel consumption with many potential applications. The achievement of these aims highly relies on efficient MAC protocols which determine
the performance of packet transmission in terms of success rate, delay, throughput and bandwidth
utilization. This chapter reviews the existing MAC protocols developed for VANETs. Initially, the IEEE
802.11p and DSRC standard are reviewed. Three TDMA-based MAC protocols, called CVIA, VeSOMAC
and D*S, are then introduced. In addition, three MAC protocols that cope with the emergency-message
broadcasting problem are proposed. Finally, a reliable MAC protocol which is developed based on the
cluster topology is reviewed.
inTroducTion
This chapter reviews the existing MAC protocols
developed for VANETs. Initially, the IEEE 802.11p
and DSRC standard are reviewed in Section 2. Three
TDMA-based MAC protocols, called CVIA, VeSOMAC and D*S, are then introduced in Section 3. The
CVIA MAC protocol mainly concerns the fairness
DOI: 10.4018/978-1-60566-840-6.ch012
and throughput issues on the demand of Internet access in a multi-hop manner. The VeSOMAC MAC
protocol intends to reduce the transmission latency
for broadcasting a message over the VANETs. The
D*S introduces the data access MAC scheduling
protocol which aims to develop a scheduler in Road
Side Unit (RSU) so that those upload and download requests can be satisfied as more as possible.
In Section 4, three MAC protocols proposed for
broadcasting the emergency message are depicted.
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
MAC Protocols in Vehicular Ad Hoc Networks
These MAC protocols aim at avoiding the packet
collision and achieving high success rate. Finally,
Section 5 reviews a reliable MAC protocol which
is developed based on the cluster topology. The
conclusions are finally given in Section 6.
Figure 1. Protocol stack relating to OSI model
ieee 802.11p and dsrc
sTandards
DSRC (Dedicated Short Range Communications)
(ASTM International E2213-03, 2003) is a well
known standard supports both Public Safety and
Private operations in roadside to vehicle and
vehicle to vehicle communication environments.
DSRC standard at 5.9 GHz band is projected to
support low-latency wireless data communications
between vehicles and from vehicles to roadside
units. The DSRC specification is meant to be an
extension of the IEEE 802.11 technology into the
outdoor high-speed vehicle environment. In fact,
the Physical Layer (PHY) of DSRC is adapted
from IEEE 802.11a PHY based on Orthogonal Frequency Division Multiplex (OFDM) technology.
Moreover, the Multiple Access Control (MAC)
layer of DSRC is very similar to the IEEE 802.11
MAC based on the Carrier Sense Multiple Access
with Collision Avoidance (CSMA/CA) protocol
with some minor modifications.
DSRC is meant to be a complement to cellular communications by providing very high data
transfer rates in circumstances where minimizing
latency in the communication link and isolating
relatively small communication zones are important. DSRC protocol layer is developed based
on physical, data link and applications layers
of traditional OSI model. In the Physical layer,
DSRC defines physical parameters for uplink and
downlink communication and is mainly working in
the 5.9 GHz band (U.S.) or 5.8 GHz band (Japan,
Europe). In the data link layer, DSRC defines
frame format, frame wrapper and the procedures
of MAC and Logical Link Control (LLC). Ap-
184
plication layer includes the fragmentation and
defragmentation of data application service and
service primitive for a variety of applications,
including electronic toll collection, emergency
warning system, vehicle safety service, commerce
transactions via cars, electronic parking payments,
probe data collection and so forth.
The standard of DSRC is comprised of IEEE
802.11p and IEEE 1609 family. Figure 1 shows the
correspondence between DSRC and OSI models.
IEEE 802.11p (Draft 7.0, 2009) is a draft amendment to the IEEE 802.11 standard to add Wireless
Access in the Vehicular Environment (WAVE).
As an extension of IEEE 802.11, IEEE 802.11p
defines how data exchange between high-speed
vehicles and between the vehicles and RSU in
5.9 GHz (5.85-5.925 GHz) band. IEEE 1609 is a
higher layer standard based on IEEE 802.11p. The
IEEE 1609 family is consisted of IEEE 1609.1
(2006), IEEE 1609.2 (2006), IEEE 1609.3 (2007)
as well as IEEE 1609.4 (2006).
IEEE 1609.1 plays the role of WAVE Resource Manager which specifies a DSRC application overlying WAVE and allows remote
site applications to communicate with OBUs or
RSUs. As a standard of application layer, IEEE
1609.1 conducts application-level information
interchanges.
IEEE 1609.2 supports WAVE security services for applications. It defines secure message
MAC Protocols in Vehicular Ad Hoc Networks
Figure 2. The frequence map of DSRC
formats, specifies methods for securing WAVE
management messages and application messages
and processes secure messages of DSRC/WAVE
systems. In addition, it handles exception of
vehicle-originating safety messages and provides
administrative functions necessary for core security functions.
IEEE 1609.3 provides WAVE devices and systems with WAVE networking services. It mainly
defines WAVE networking services operated at
the network and transport layers. In other words,
IEEE 1609.3 represents roughly layers 3 and 4 of
the OSI model and the IP, UDP and TCP elements
of the Internet model.
IEEE 1609.4 supports frequency band coordination and management within the MAC layer,
supplements 802.11 MAC features as well as coordinates operations on both the Control Channel
(CCH) and Service Channels (SCH).
Figure 2 depicts the Frequency band of DSRC.
The frequency band used by DSRC ranges from
5.855GHz to 5.925GHz and is divided into seven
10MHz communicating channels and one 5MHz
reserving channel. The 5.885~5.895GHz is control
and safety emergency channel. The rest of band
is reserved for public safety or private operations.
Furthermore, two specific channel pairs, channel
174 with channel 176 and channel 180 with channel 182, are able to merge to be a 20MHz channel
for special conditions.
Tdma-base mac
proTocols on VaneTs
A number of VANET MAC protocols have been
proposed based on TDMA system. Compared
with probabilistic-based MAC protocol, an obvious advantage of TDMA system is the ease for
avoiding collision and contention with smart assignment for the transmission of each slot. This
subsection reviews some TDMA-based MAC
protocols developed for VANET.
cVia mac protocol for
Vehicular networks
An efficient TDMA-based MAC protocol can assign each transmission with a slot without collision
such that potential parallel transmissions can be
exploited. Korkmaz et al. (2006) proposed a new
cross-layer protocol, called Controlled Vehicular
Internet Access (CVIA), for vehicular Internet
access along highways protocol. The proposed
CVIA protocol can be applied on the application
such as Internet access through RSU in a multihop manner. In the network environment of CVIA,
the service region is not fully covered by the
deployed RSUs due to hardware cost constraint.
As a result, vehicles might need to exchange data
with RSU via multi-hop communication. Since
vehicles with longer distance to the RSU have
fewer opportunities to exchange their data with
the gateway, one major problem considered in this
research is the fairness. Other issues considered in
185
MAC Protocols in Vehicular Ad Hoc Networks
Figure 3. Concepts of slots and segments in CVIA
CVIA include collision avoidance and throughput
enhancement.
As shown in Figure 3, the proposed CVIA
divides service region into a number of equalsized segments. Segment Si closer to the RSU
will be assigned with a smaller identifier number
i. The CVIA protocol assigns a specific time slot
to each segment so that vehicles belonging to the
segment can access the channel with collision. The
objective of CVIA is to increase the end-to-end
throughput while achieving fairness in bandwidth
usage between road segments.
in
In each segment, two vehicles TRi and
TRiout will be selected as temporary routers for
collecting and then forwarding data packets. The
TRiin takes charge of forwarding data sent by
the vehicular in the neighboring segment with
bigger ID whereas TRiout is mainly responsible
for collecting the packets to the forward of next
Figure 4. Packet movement via routers
186
segment closer to RSU. As shown in Figure 4, the
was forwarded by forwarders
data sent by TRiout
+1
in
out
TRi , TRi and TRiin-1 subsequently.
Three major tasks should be performed by
vehicles of some specific segment in the allocated
the time slot. Figure 5 gives an example for illustrating the basic concept of CVIA. As shown
in Figure 5a, the TRiin ,next delivers the packet
train originating from segment Si+1 to TRiout .
After, as shown in Figure 5b, local packets of the
segments Si are gathered by TRiout in a collision
avoidance manner. Finally, the TRiout of segment
Si creates a new packet train based on received
packets and then sends it to TRiin-1 in Si-1 , as
shown Figure 5c.
As shown in Figure 6, the CVIA algorithm
mainly consists of six phases, namely Inactive,
Vehicle Position Update, Temporary Router Selection, Intra-segment Packet Train Movement, Local
MAC Protocols in Vehicular Ad Hoc Networks
Packet Gathering Phase as well as Inter-segment
Packet Train phases. Figure 7 gives an example
that would be used throughout this section for
illustrating the detail operations of each phase.
(a) Inactive Phase. Vehicles in this phase
are not permitted to exchange data for avoiding
collision and contention. For a given time slot,
each vehicle can easily know whether it stays in
inactive state or not. The reason is stated below
using the example shown in Figure 7. We assume
that each RSU serves six segments Si, 1 ≤ I ≤ 6.
In addition, we assume that vehicles are able to
obtain their positions and synchronize their clocks
through the equipped GPS. A set of time slots are
divided into two sets, odd and even sets, depending on the number labeled on the slot is odd or
even. The six segments are also divided two sets,
namely the odd set {S1, S3, S5} and the even set
{S2, S4, S6} Segments belonging to the same set
will be active at the same time slot. Herein, we
assume that the even and odd time slots are allocated to even and odd segment sets, respectively.
For example, vehicles in segments S1, S3, S5 are
active and are permitted to exchange data in the
odd slots. All vehicles can be aware its segment
number according to its location information.
Therefore, each vehicle knows whether or not it
should be active for a given time slot. A vehicle
that stays in inactive phase will do nothing.
(b) Vehicle Position Update Phase. This phase
mainly exchanges the location information of
all vehicles located in the active segment. The
location information will be further used in the
later phases. Each vehicle should first checks if
it stays in active state for a given time slot. If it is
the case, the vehicle should execute the operations
defined in the Vehicle Position Update Phase. Let
time interval tu is the length of this phase. In this
phase, each vehicle picks a Random Waiting Time
(RWT) from 0, tu - tPUP, where tPUP is the time duration required for sending a packet. After an RWT,
vehicles access the channel using the Distributed
Coordination Function (DCF) as defined in the
IEEE 802.11 protocol.
(c) Temporary Router Selection Phase. The
topology of the vehicular network is dynamic.
New temporary routers should be selected periodically, because the router may move to the next
Figure 5. Three important phases in CVIA
187
MAC Protocols in Vehicular Ad Hoc Networks
Figure 6. CVIA protocol state machine
segment. The selected routers are called TRiin ,next
and TRiout ,next until they become active. The TRiin
is responsible for selecting new TRiin ,next and
TRiout ,next after the position update phase. The
TRin uses two parameters, router lifetime and
safe area, to choose the new routers. The router
lifetime represents the time which routers should
stay in the segment. Therefore, the router times
of TRin and TRout will be different because they
have different tasks as described below.
The TRiout is responsible for three tasks in the
active time. First, TRout receives the packet train
sent from TRiin . After, TRout collects the local
packets from all vehicles in the same segment.
Finally, TRout creates a new packet train and
then sends this train to TRi-1 in which is located
in the next segment. Hence the router lifetime of
TRiout should be long enough for executing the
three abovementioned tasks. The router lifetime
of TRiin is quite different from that of TRiout .
188
First, TRiin receives the packet train coming from
segment Si+1. Then it selects and announces the
TRiin ,next and the TRiout ,next at the beginning of the
next active slot. Final, TRiin forwards the packet
train to TRiout in the next active slot. As a result,
the router lifetime of TRiin should be carefully
calculated accordingly.
The candidates of TRiout ,next and TRiin ,next
should exclude the vehicles which will move
out the segment during the router lifetime. The
farthest and closest candidates away from the
RSU will be selected as TRiin ,next and TRiout ,next ,
respectively. Finally the TRiin will broadcast the
result of new inheritors.
(d) Intra-segment Packet Train Movement
Phase. In this phase, a priority policy should be
designed to guarantee that the forwarding packets
can be delivered to the Trout of the same segment.
The priority of TRiin transmission should be highest since it is in charge of forwarding packets sent
MAC Protocols in Vehicular Ad Hoc Networks
Figure 7. Slot allocation of CVIA
from router of previous segments. To achieve this,
TRiin only need to wait for a SIFS period as its
active slot starts.
(e) Local Packet Gathering Phase. In this
phase, TRi-1 aims to receive the data packets of
those vehicles in the same segment. All vehicles
in segment Si have the same priority for accessing channel. Therefore they access channel in a
contention-based manner. To avoid the occurrence of collision, each vehicle should wait for
a random period of time. An awaken sender can
access channel if it detects that the medium is idle.
In case that the medium is busy, the sender will
again wait for another random time period. In this
out
phase, TRi has the highest priority to transmit
in this phase. To maintain the fairness among all
vehicles in different segments, a predefined size
for local packets will be the constraint for data
transmission in each segment. Since Trout is
responsible for receiving all local packets in this
phase, it can be aware whether or not the size
of received packet is larger than the predefined
189
MAC Protocols in Vehicular Ad Hoc Networks
size. If it is the case, the Trout should broadcast
a message to terminate this phase.
(f) Inter-Segment Packet Train Movement
Phase. In the last phase, TRiout will create a new
packet by combining the packets collected in the
Intra-segment Packet Train Movement Phase and
Local Packet Gathering Phase. The new packet
will be sent to the router of next segment. Then
this phase will be terminated. All vehicles move
back to the inactive state and wait for the next
active slot.
In summary, the CVIA protocol improves the
performance of transmission in the environment
which takes into consideration the vehicle-to-vehicle and vehicle-to-roadside communications. The
packet collision ratio of CVIA decreases and the
fairness among segments are achieved. However,
the fairness is achieved between segments, rather
than between vehicles. A particular case that one
segment has light traffic demands and the other
segment has heavy traffic demands, allocating
same bandwidth to all segments is not a good way.
In addition, the bandwidth utilization of CVIA can
be further improved. To avoid packet collision,
each segment is assigned with an equal-length active slot. However, the constraints of packet size
for different segment are different, which results
in unused bandwidth occurred in the segment farer
to the RSU. As a result, bandwidth utilization can
be improved. Besides, the slot-based approach
requires accurate time synchronization which is
difficult to be implemented in the real world.
Vesomac mac protocol
In a VANET, emergency message such as accident information should be broadcasted within
an acceptable time period. To avoid the transmission delay raised by collision and contention, a
TDMA-based system would be a better candidate
than probabilistic-based system. Fan Yu et al. proposed a novel Medium Access Control protocol
for inter-vehicular wireless networking using the
190
emerging DSRC standards. A distinctive feature of
VeSOMAC (Yu et al., 2007) is its distributed design
with fast schedule reconfiguration for coping with
vehicular topology changes. The main contribution
of the paper is the design of a self configuring
TDMA protocol capable of inter-vehicle message delivery with short and deterministic delay
bounds. The most significant contribution of this
protocol is that it allows a set operations running
in a TDMA-based system without strictly clock
synchronization. The proposed Vehicular SelfOrganizing MAC (VeSOMAC) assume that each
vehicle is aware of its own location and velocity.
The following uses an example shown in Figure
8a to illustrate the basic concept of VeSOMAC.
Assume that there are four vehicles, A, B, C, and
D, move in order. After an emergency event (e.g.
an accident) occurred in front of the platoon A-BC-D, the platoon head A periodically broadcasts
warning messages instructing other vehicles to
slow down for avoiding collisions. Such warning
messages are to be forwarded by all vehicles across
the entire platoon with minimum possible delivery
latency. With an example TDMA allocation with
arbitrarily slot placement as shown in Figure 8b,
it will take three TDMA frames for delivering the
messages to all vehicles in the platoon. However,
with a possible VeSOMAC allocation, in which
slots are allocated based on the vehicles’ relative
locations as shown in Figure 8c, the delivery delay
can be significantly reduced. In this example, all
messages can be delivered within a single frame.
This improvement can be much more pronounced
for larger platoons. This way VeSOMAC can effectively enhance highway safety by leveraging its
ability to allocate slots based on location, speed,
and other vehicular contexts.
Information about allocated slots is exchanged
among the vehicles using a Bitmap Vector in each
packet header. Figure 9 depicts an example to illustrate the concept of bit-map. The slot allocated
to vehicle B is marked with blue ink while the
slots occupied by all of B’s one-hop neighbors are
marked with green ink. Although these neighbors’
MAC Protocols in Vehicular Ad Hoc Networks
Figure 8. Basic idea of VeSOMAC
slots are shown with respect to B’s frame, each
neighbor maintains its own asynchronous frame.
The middle of the bitmap vector represents B’s
slot time. The bitmap vector is 4-bit long and each
bit represents the occupancy status of two slots
around B’s own slot. The major reason for using
one bit to represent two slots is that the neighbor’s
slot can partially overlap with two contiguous
slots of B’s frame in the asynchronous mode. For
example, the ‘1’ in “+1” location indicates that at
least one of the two slots immediately following
B’s slot are already fully or partially occupied.
Similarly, a ‘0’ in the “-1” location indicates
that vehicle B perceives both the slots before its
own slot to be free. The bitmap vector length is
a design parameter whose maximum value is the
frame slot count. In Figure 9, the frame size is 12,
whereas the bitmap length is 4, which can convey
the occupancy information about only 8 slots.
With a bitmap size 4, B is unable to represent the
occupancy information about one of its neighbors’
slots-the one in extreme left.
Using this header bitmap, a vehicle continuously informs its 1-hop neighbors about the slots
occupied by its 1-hop neighbors. By listening to
the bitmaps in all received packets, a vehicle can
detect the slot locations of its 1-hop and 2-hop
neighbors. This information can then be used for
choosing a slot which is non-overlapping with
the one and two hops vehicles’ slots.
Slot allocation in VeSOMAC needs to satisfy
the following constraint:
1.
2.
Timing constraint: This constraint indicates
that no two one-hop or two-hop neighbors’
slots can overlap. Overlaps between onehop or two-hop neighbors cause direct and
hidden collisions respectively.
Bitmap constraint: For 1-hop neighbors
i and j, i’s chosen slot should be able to be
represented within the bitmap vector of j.
The same is applicable for vehicle j’s slot.
In the asynchronous case, since each bit
corresponds to two slots, this constraint
means that the slots of vehicles i and j can’t
191
MAC Protocols in Vehicular Ad Hoc Networks
Figure 9. In-band header bitmap for the asynchronous operation
3.
be more than x slots apart, where x is the
bitmap length.
Ordering constraint: If two vehicles i and
j are geographical neighbors and i’s location
is ahead of j in the platoon, then i’s chosen
slot should be earlier than j’s slot in the time
domain. The ordering constraint is optional,
and it is useful when the wireless messages
flowing from the front to the tail of a platoon
are more delay critical than the messages
flowing in the reverse direction.
Figure 10. State machine of VeSOMAC protocol
192
4.
The VeSOMAC protocol state machine
with all three constraints is presented in
Figure 10. The Stable state for a vehicle
indicates the time slot allocation matches
the order of geographic location order of vehicles. The Listen and Evaluate are transient
states. In the Listen state, vehicle overhears
the broadcasting message and look at the bitmap information. Then the vehicle chooses a
slot according to its physical location. After
a vehicle chooses a slot through the Listen
state, it spends a preset (W) number of slots
MAC Protocols in Vehicular Ad Hoc Networks
in the Evaluate state before getting into the
Stable state. In the Evaluate state, the slot
is evaluated for W frames to make sure that
the vehicle monitors its neighborhood activities to decide if its own allocation became
stable. If the assigned slot order is different
with the order of geographic locations of the
vehicle and its neighbors, it stays in Evaluate
state and tries to change its selected slot.
When the state machines for all vehicles in
a neighborhood reach the Stable state, the
protocol is said to have converged.
The VeSOMAC proposes a distributed slot
allocation mechanism to avoid the packet collision between one-hop and two-hop vehicles,
and minimizes the delay of the event delivery
by exchanging the Bitmap among neighboring
vehicles. Furthermore, the proposed mechanism
can be applied in both time synchronous and time
asynchronous scenarios. However, the efficiency
of the proposed mechanism is highly affected by
the frame size, and thus the number of slots in
a frame should be carefully determined. If the
number of slots in a frame exceeds the vehicles,
the chosen slots may be non-continuous and the
bandwidth will be wasted. On the contrary, if the
slots in a frame are fully occupied, a new vehicle
can’t choose an empty slot, which might cause
the new vehicle starvation. Therefore, how to
decide the frame size by estimating the density
of the vehicle network will be an important issue
in the future works.
data access mac scheduling
protocols for rsu
Recently, vehicle-roadside data access has received considerable attention in VANET. VANET
is a special case in MANET (Mobile Ad-hoc
Network) and it is composed of vehicles with
wireless communication devices and RSUs.
Vehicles can upload and/or download data from
RSU. For example, drivers can get lots of traffic
or map information from RSU to improve the
safety in VANET. Therefore, RSU can be treated
as a buffer point (or data island) which can store
a variety of data including the value-added advertisement, real-time traffic as well as digital
map. As shown in Figure 11, the RSUs are often
deployed at the road intersections or areas with
high traffic to improve the serving efficiency to
each vehicle.
In VANET, vehicles often move with high
speed. This implies that the time duration for
exchanging data between a vehicle and RSU is
Figure 11. The scenario considered in RSU scheduler
193
MAC Protocols in Vehicular Ad Hoc Networks
Figure 12. Packets in D-list and S-list are sorted by Deadline and Datasize respectively in RSU
very short. As shown in Figure 12, when a large
number of vehicles intend to exchange data with
RSU simultaneously, an efficient scheduler that
arranges a sequence of uplink and downlink data
access is important. How to decide an efficient
serving sequence for satisfying all the services
requested from vehicles is an imperative issue.
Since each vehicle can only exchanged data
with the RSU within a very short time duration
which highly depends on the vehicle speed and
the communication range of RSU, each request
sent from a particular vehicle would have a time
constraint. This means that the request would be
overdue if the request did not be served within the
time constraint. However, the RSU might receive a
number of requests with different time constraint.
Since the bandwidth resource is limited, how to
maximize the network throughput and prevent
the requests from being overdue will be the major
goal for developing an RSU scheduler.
Zhang et al. (2007) proposed a RSU scheduling mechanism that satisfies the services
requested from many vehicles under the time
and bandwidth constraints. As shown in Figure
12, assume that all of the service requests are
194
buffered in a queue of RSU at the beginning.
Each request is characterized by a 4-tuple:
< u - id, d - id, op, deadline > , where u - id
is the identifier of the vehicle, d - id is the identifier of the requested data item, op is the operation
that the vehicle wants to do (upload or download),
and deadline is the critical time constraint of the
request. In addition to the deadline, the data size
should also be taken into consideration because
that a transmission for a large sized data needs long
service time and may delay other service requests.
As shown in Figure 12, the RSU will initially sort
all the requests according to the deadline and data
size individually and store the sequences as the
D-list and S-list, respectively.
A weighted DS_value, as defined in Equation
1, is used for RSU to decide the services scheduling sequence.
DS _ value = (Deadline - CurrentClock ) ´ DataSize
(1)
The (Deadline - CurrentClock ) represents
the remaining service time. A service with a smaller
MAC Protocols in Vehicular Ad Hoc Networks
time constraint will have a higher priority while a
service with a smaller DataSize will have a higher
priority. Consequently, the DS scheme always
serves the requests with minimum DS _ value
in each scheduling time.
emergency mac
proTocols on VaneTs
broadcast strom mitigation
Techniques in VaneTs
In VANETs, Broadcasting for emergency message
has been widely discussed for a variety of applications. In the application of emergent message
dissemination, the packet broadcasting is critical
in time constraint. However, packet broadcasting
might raise contention and collision phenomenon
which might block the dissemination of emergency
message. How to develop an efficient broadcasting mechanism is an important research issue in
VANETs.
Developing emergency MAC protocols can
help dissemination of emergency messages with
a short propagation delay without packet collision and contention. Wisitpongphan et al. (2007)
assumed that each vehicle is aware of location
information and proposed three different broadcasting approaches. In the first approach, a node
j receiving a packet from node i will check the
packet ID and rebroadcasts with probability pij
if the packet is received first time. Otherwise, it
discards the packet. Let Dij denote the distance
between nodes i and j, and R denote the average
transmission range. The forwarding probability,
pij, can be calculated on a per packet basis using
the following simple Equation. The basic concept
of Equation 2 is that a receiver closer to the sender
will have a larger overlapped communication
range with sender and thus has smaller contribution for forwarding the packet to those receivers
that have not yet received the same message
from the sender. As a result, a receiver that farer
to the sender will have a higher probability for
rebroadcasting the received message.
pij =
Dij
R
(2)
To avoid the occurrence of contention, the
receiver with small probability value should additionally wait for a predefined time duration. In
case of receiving duplicate packets from multiple
sources within the waiting period, it calculates
a probability for each received message and
then selects the smallest probability value as its
re-forwarding probability. If a node decides not
to rebroadcast, it should buffer the message for
another time duration WAITTIME + d , where
d is the one-hop transmission and propagation
delay, which is typically less than WAITTIME as
shown in Figure 13.
The proposed approach prevents the packet
dissemination from collision. However, the first
approach exhibits two drawbacks as described
below. First, the vehicle with low rebroadcast
priority may still broadcast the packets. Second,
Figure 13. Vehicles calculate probability and broadcast
195
MAC Protocols in Vehicular Ad Hoc Networks
if the density of VANET is high, several vehicles
may have the same probability. They will rebroadcast the packets at the same time, resulting
in collisions. The second approach, based on
time-slot calculation, is proposed to improve the
aforementioned drawbacks. Upon receiving a
packet, each receiver checks the packet ID and
rebroadcasts with probability 1 at the assigned
time slot TSij if the packet is received first time.
Otherwise, it discards the packet.
The following discusses how to derive the
value of the allocated transmission slot TSij. Let
the average transmission range and the predetermined number of slots are R and Ns, respectively.
Given the relative distance Dij between nodes i
and j, TSij can be calculated by Equation 4, where
τ is the estimated one-hop delay, which includes
the medium access delay and propagation delay,
and Sij is the assigned slot number.
éN - 1ù ´WAIT
+ dms
êë 8
úû
TIME
(3)
TS = Sij ´ t
(4)
ij
The time slot approach follows the same
concept of the weighted p-persistence scheme,
but instead of calculating the re-forwarding
probability, each node uses the GPS information
to calculate the waiting time to retransmit. For
example, in Figure 13 the broadcast coverage
is spatially divided into four regions. According
to Equation 4, a shorter waiting time will be assigned to the nodes located in the farthest region.
When a node receives duplicate packets from
more than one sender, it takes on the smallest Dij
value. Similar to the p-persistence scheme, this
approach requires transmission range information
in order to agree on a certain value of slot size or
number of slots.
Note that N 8 is a designed parameter that
should be carefully chosen. Although N 8 should
theoretically be a function of the traffic density
(i.e., the denser the traffic, the smaller the slot
196
size and the larger the number of slots), it is very
difficult for each vehicle to predict what the traffic density is and to arrive at a single value of
(
)
é min RSS
, RSSij - RSS min ) ´ N 8 ùú
ê
range (
ú
Sij = N 8 - ê
ê
ú
RSSrange
êë
úû
in practice. Hence, network designers can, at best,
fix this value or adaptively change this value over
time; for example the protocol should use five slots
during morning and evening rush hour, and three
slots during non-rush hours. The second approach
might assign the same slot for two vehicles that
have similar distances far from the sender. As a
result, a collision might be occurred. Another approach is proposed to improve this drawback.
The proposed third approach takes into account
the previously discussed two approaches. That is,
probability-based and slot-based mechanisms are
adopted in this approach. Each node in this scheme
should also buffer the message for a certain period
of time (e.g., éëêN 8 - 1ùûú ´WAITTIME + dms ) and
retransmits with probability 1 if nobody in the
neighborhood rebroadcasts in order to prevent
the message’s dying out.
The abovementioned approaches mainly developed based on the location information which is
obtained from GPS equipment. However, vehicles
may not be able to receive GPS signals in some
areas (e.g., tunnels, shadowed areas, urban areas
with many high-rise buildings). These broadcasting approaches can also be modified by using the
packet Received Signal Strength (RSS) information instead of GPS information. Equations 5 and
6 depict the modifications of approaches 1 and 2,
where RSSrange and RSSmin denote the signal range
and the value of minimum signal strength, respectively, and the RSSij denotes the signal strength
between nodes i and j.
pij =
RSSij - RSS min
RSS range
(5)
MAC Protocols in Vehicular Ad Hoc Networks
(
)
é min RSS
, RSSij - RSS min ) ´ N 8 ùú
ê
range (
ú
Sij = N 8 - ê
ê
ú
RSSrange
úû
ëê
(6)
broadcast methods for interVehicle communications system
Some other studies devoted themselves to develop
broadcast schemes for emergency events such as
traffic accidents and ambulance alarming. The accidents information should be broadcasted to all
vehicles to prevent them from another accident.
Therefore, broadcasting mechanism for emergency information is important and has received much
attention recently. How to efficiently broadcast the
emergency message to all vehicles neighboring to
the accident location will be the key technology
for preventing secondary accidents.
Fukuhara et al. (2005) proposed a novel broadcast method for a vehicular network to timely
notify appreciate drivers. They considered that
the events can be categorized into two types, according to the broadcasting directions. One type
of events is backward-dissemination event which
should be broadcast to those vehicles located at
the backward location of the accident. A typical
example is the traffic collision event. On the other
hand, the forward-dissemination event should
be broadcasted to those vehicles located at the
forward location of the event. For example, the
event message of ambulance alarming should be
disseminated to the vehicles in the forward direction. Therefore, the broadcast areas of these two
types of events should be different.
Based on the concept, the authors proposed
a broadcast scheme to notify the vehicles in a
particular area. Figure 14 shows an example for
an ambulance alarming event. The authors define
three different areas in the road. The first area is
called location offset, which avoids the inaccurate
location obtained from a GPS. The second area is
used for relaying the emergency message along the
forward direction. Vehicles in this area should not
only receive the emergency notice but also deliver
the notice to other vehicles. Finally, the authors
define the area which should be notified. In this
area, the vehicles within a proper range can get the
notification by other vehicles without forwarding.
The following uses an example shown in Figure
15 to discuss how to identify the three areas.
Figure 15 depicts the area which consists of
an available relay range and an available notifi
cation range. Let X and V be vehicle’s location
and velocity vectors, respectively. Equation 7(a)
depicts the relative direction between the vehicle


and the ambulance, where X 1 and X 2 denote
the location vectors of vehicle and ambulance,
Figure 14. The relay and notification zone
197
MAC Protocols in Vehicular Ad Hoc Networks
Figure 15. An example for calculating available relay range


respectively, and V 1 and V 2 denote the velocity
vectors of vehicle and ambulance respectively. A
positive value of Equation 7(a) indicates that the
vehicle and ambulance have the same direction.
Vehicles that satisfy the criteria of Equation 7(b)
should be notified and further relay the emergency
message while vehicles satisfy Equation 7(c) but
not satisfy Equation 7(b) should only be notified.
The calculation procedure in the traffic accidents
scenario is similar except the direction is opposite
to the ambulance alarming event.




X 2 - X 1 + aV 1 ·V 2 > 0
(
p¬
)
(7a)
dis tan ce (m.SenderPosition, localPosition )
m.SenderCommunicationRadius
(7b)



X 2 - X 1 + aV 1 < RNotification (Threshold) (7c)
Towards lightweight
information dissemination in
inter-Vehicular networks
In addition to the traffic accidents and ambulance
alarming handling, some other emergency protocols are developed for general-type emergency
event (Sormani et al., 2006). Davide Sormani et
198
al. intend to reduce the dissemination packets in
a broadcasting operation while achieves high success rate. In their design, the packet only consists
of the position of the accident, sender’s position,
communication range and the propagation function including the target zone. In particular, the
propagation function encodes the information
about target areas and preferred routes.
Figure 16 shows a propagation function associated with a target zone that is reached by a
single major road. The function drives messages
along the main road — the red line below the
function — and towards the target zone — the
black ellipse. It is worth to note that the message
originator does not compute a predefined trajectory using the propagation function before sending
the message. Rather, the route to the destination
is the result of the evaluation of the function at
each routing hop. For example, a message that is
routed outside the black line in Figure 16 does not
have to be routed back towards the line, but it can
continue its route along a new trajectory, which
still ends up on the desired target area. The values
of the propagation function can be viewed as the
values of the potential to achieve the destination
region. Messages should be attracted in the right
direction towards decreasing values of the propagation function that is towards areas of minimum
potential. Several protocols with the propagation
MAC Protocols in Vehicular Ad Hoc Networks
Figure 16. Three-dimension diagram of the
propagation function
function are presented for broadcasting the emergency message with lightweight traffic.
a. One Zero Flooding (OZF). The One Zero
Flooding (OZF) mechanism is proposed for flooding a message with lightweight traffic by using
propagation function. The basic concept of OZF
mechanism is that packets would be transferred
by vehicles with the smaller value of propagation
function. A simple example to illustrate the idea
of OZF is shown in Figure 17. In Figure 17, we
assume that vehicles A and C both are located
within vehicle B’s communication range. We assume that vehicle A and vehicle C calculate the
function value between themselves and vehicle
B separately after getting a packet broadcasted
from vehicle B. If the distance between receiver
and target area is shorter than that between sender
and target area, the function value calculated by
the receiver is smaller than that calculated by the
sender. That is, vehicle C has the smaller function
value than vehicle B and vehicle A has the larger
function value than vehicle B. As a result, vehicle
C in the OZF protocol gets the value “one” to relay
the packet and vehicle A gets the value “zero”
which indicates it does not need to forward the
received packet. The OZF mechanism can reduce
the phenomenon of packet dissemination along the
opposite direction toward the destination. However, several vehicles might forward the received
message at the same time if they are within the
transmission range of a sender and are closed to
the destination. This might raise the contention
and collision problem.
b. Distance-Driven Probabilistic Diffusion
(DDPD). DDPD is proposed for reducing the
collision and contention phenomenon occurred
in OZF. The DDPD propagation protocol adds a
probabilistic choice to OZF. The probability function introduced in DDPD design aims to distribute
those transmissions which might be collided with
each other when applying OZF. Equation 8 takes
into account the distance between the receivers
and the sender. Similar to the concept of OZF,
vehicles do not forward the emergent messages if
these vehicles have larger values of propagation
function than sender. On the contrary, vehicles
with smaller values of propagation function than
sender will forward the emergent messages to the
target area with a probability evaluated according
to Equation 8.
Figure 17. OZF propagation protocol
199
MAC Protocols in Vehicular Ad Hoc Networks
FF (X ) =
dist (X ,Y ) + Du * BB _ REFR
R
(8)
Figure 18 depicts an example of DDPD. Assume that vehicles B and C have smaller function
values than vehicle A and intend to forward the
received message with a probability calculated
by Equation 8. Herein, we assume that vehicle C
has a higher probability value than vehicle B and
will forward the received emergency message.
As a result, vehicle B will not further forward
the message again after it overhears the message
broadcasted from vehicular C. Although the
DDPD mechanism might reduce the probability
of transmission collision, it still has the problem
of redundant transmission. For example, in Figure
19, if vehicles B and C are closed to the edge of
the communication range of vehicle A, vehicle
B will have a high probability for forwarding the
packet sent from vehicle A. However, vehicle C
would be a better candidate for broadcasting the
message than B since it closer to the target area.
c. Function-Driven Probabilistic Diffusion
(FDPD). Though the abovementioned DDPD
mechanism tries to reduce the number of forwarders, however, it does not consider the distance
from forwarding candidates to destination in the
probability design. To further reduce the number
of redundant transmission, FDPD propagation
protocol is proposed. The probability function
proposed in FDPD relies on the function value
by preventing the packet from forwarding in the
wrong direction. Different to DDPD, an enhance
probabilistic Equation is proposed as shown
in Equation 9, where the BEST point denotes
the physical location with the lowest value of
propagation function within the communication
radius of the sender. In the FDPD propagation
protocol, vehicles forward the emergent packet if
they are located at the right position away from
Figure 18. DDPD propagation protocol
Figure 19. Vehicles B and C have the same high probability for forwarding the packet sent from vehicle
A. However, vehicle C would be a better candidate
200
MAC Protocols in Vehicular Ad Hoc Networks
the BestPoint and they are closer to the destination than sender.
p¬
f (m.SenderPosition ) - f (localPosition )
f (m.SenderPosition ) - f (BestPo int)
(9)
As shown in Figure 20, vehicle B and vehicle
C intend to forward the received packet with
probability 0.75 and 0.99, respectively, according
to Equation 9. The key improvement of FDPD
is the consideration of BEST point which leads
the packet to be forwarded in the right direction.
Though FDPD significantly reduce the number
of redundant transmissions, however, it does not
take into consideration the hole problem, which
might occur in a sparse network environment.
d. Feedback-Augmented Store and Forward
Diffusion (FSFD). Compared with the FDPD, the
FSFD further concerns the hole problem which
might occur in the light-traffic environment. The
FSFD mainly adopts the well known store-andforward mechanism where vehicles can store the
emergent packet and move for a period of time,
seeking for the possible forwarder. As shown in
Figure 21, assume that vehicle B can not find
any forward in its transmission range at the time
t after receiving the packet from vehicle A. Thus,
vehicle B has to store the packet in its queue
temporally until it finds forwarder C at the time
t + 2. In the meanwhile, vehicle B forwards the
packet to vehicle C and therefore the packet will
not be blocked at vehicle B.
e. Direction-aware Function Driven Feedbackaugment Store & Forward Diffusion (DFDFSFD)
Although the FSFD can store and forward the
packet for overcoming the hole problem, however,
the transmission direction of packet is not taken
into account. This protocol takes into account the
right direction to target area like the BEST point
and applies the FSFD propagation protocol to
forward the emergent packet. As shown in Figure
Figure 20. FDPD propagation protocol
Figure 21. FSFD propagation protocol
201
MAC Protocols in Vehicular Ad Hoc Networks
Figure 22. DFD-FSFD propagation protocol
22, the vehicles A and B calculate the angles α and
p
implies
β, respectively. The angle α less than
2
that the packet can be forwarded by vehicle A
to the right direction to the target area. On the
p
indicates
contrary, the angle β larger than
2
that the packet forwarded by vehicle B is along
the wrong way.
reliable mac proTocols
on VaneTs
Some other studies took the reliable communication into consideration and aimed to construct a
reliable network topology for data dissemination.
However, in VANETs, the locations of vehicles
change with time, which might cause an existed
link broken. It is an important issue to construct
a reliable backbone topology so that the message
flooding can be achieved by the forwarding of
those nodes in the backbone topology. This subsection introduces a novel reliable MAC protocol
which efficiently constructs a backbone topology
for a given VANET.
Bononi et al. (2007) proposed a fast and efficient broadcast protocol for VANET. The proposed
protocol aims to reduce the influence of vehicles
with high speed on performance. The following
uses an example to illustrate this protocol.
As shown in Figure 23, a distributed clustering
dynamic algorithm is proposed to create a dynamic
virtual backbone in the vehicular network. The
vehicles update their state dynamically. If the
vehicles are in the backbone, their states are set
to be Backbone Member (BM), otherwise their
states are set to be Normal Vehicle (NV). The
vehicles in BM are responsible for relaying the
massages, while the vehicles in the NV state just
need to receive the messages from the vehicles in
the BM. The proposed algorithm can reduce the
overhead of inter-vehicular communication.
Figure 23. The vehicles in BM are responsible for relaying the massages, while the vehicles in the NV
state just need to receive the messages from the vehicles in the BM
202
MAC Protocols in Vehicular Ad Hoc Networks
A backbone creation process starts whenever
a vehicle does not receive backbone beacons for
a predefined time interval. As shown in Figure
24, vehicles A, B, C and D initially implement
the random back-off mechanism without receiving a message from backbone. In this example,
we assume that vehicle A wakes up earliest and
sets itself as a backbone member. Then vehicle
A chooses its next hop backbone member from
neighbors for constructing a robust backbone,
the next hop should be able to stay in the communication range of A for the longest time. As
a result, the backbone member can be selected
subsequently in a hop-by-hop manner. Each vehicle in the BM state should record at most two
backbone members which are called previous hop
and next hop, respectively. Figure 25 shows that
vehicles B and C are the previous hop and next
hop of vehicle A, respectively.
An important factor for a backbone member
to select the next backbone member will be their
connection duration. The following Equation is
used to calculate the residual communication
time between vehicles X and Y. Let RT denote
the Residual Time, R denotes the communication
range of sender vehicle, and dist(X, Y) denotes
the current estimated distance of vehicles X and
Y. Let Du = uY - uX denotes the relative speed
between vehicles X and Y, where uX and uY are
the average speed of vehicles X and Y, respectively.
In Equation 10 gives the estimation of residual
time of vehicles X and Y, where sign() denotes
the function which returns 1 if Du is positive
and -1 otherwise.
(
)
é max 0, sign Du ù R - dist X ,Y
( ) úû
( )
ê
RT (X ,Y ) = ë
Du
(10)
In order to reduce the communication overhead
required for constructing a backbone, the number
of vehicle in BM state should be minimized. To
achieve this goal, Equation 11 calculates the distance of X and Y after a time duration BB_PEFR
which is the time required for constructing the
next backbone topology, normalized with respect
to R.
FF (X ) =
dist (X ,Y ) + Du * BB _ REFR
R
(11)
If the distance between two vehicles increases,
the value of FF would raise. The value of FF
would be used as the random backoff parameter
after all neighbors of vehicle A calculating RT.
Therefore, when a vehicle has the largest value
it will wake up first and response the beacon
Figure 24. Vehicle A, B, C and D do not receive backbone beacons for a time interval. After random
backoff time period, if the first waked vehicle is A, vehicle A will elect itself as a backbone member and
choose its next hop.
203
MAC Protocols in Vehicular Ad Hoc Networks
Figure 25. Each vehicle in the BM state has at most two neighbors that called previous hop and next
hop respectively. Previous hop and next hop are also backbone members.
of vehicle A. We assume that vehicle C wake
up earliest and it responds a packet to A. Upon
receiving the response, Vehicle A records that C
is its next hop, and then sends an ACK_WINNER
packet to vehicle C. Similarly, vehicle C records
that vehicle A is its previous hop and changes the
NV state to BM state. All other vehicles give up
the contention accordingly.
conclusion
Vehicular communication systems that can transmit and receive information to and from individual
vehicles have the potential to significantly increase
the safety of vehicular transportation, improve
traffic flow on congested roads, and decrease
the number of people of deaths and injuries in
vehicular collisions effectively.
This chapter review import MAC protocols for
VANETs. A number of MAC protocols, including
IEEE 802.11p, DSRC standard, TDMA-based
MAC protocols, data access MAC scheduling
protocol, emergency message and reliable MAC
protocols, are reviewed. In this chapter, the basic
concept, strategies, advantages and contributions of the reviewed papers are introduced and
discussed. We believe the reviewed MAC protocols will be the base for further improvement of
protocols in terms of the reliability, scalability,
and efficiency in VANETs. The development of
efficient VANET protocols that integrate MAC
and network layers and the implementation of
204
protocols that meet the requirement of real applications in VANETs will be the future works.
reFerences
ASTM International E2213-03 (2003). Standard
Specification for Telecommunications and Information Exchange Between Road-side and
Vehicle Systems 5 GHz Band Dedicated Short
Range Communications (DSRC) Medium Access Control (MAC) and Physical Layer (PHY)
Specifications.
Bononi, L., & Felice, M. D. (2007). A Cross Layered MAC and Clustering Scheme for Efficient
Broadcast in VANETs. In Proceedings of the IEEE
International Conference on Mobile Ad hoc and
Sensor Systems.
Fukuhara, T., Warabino, T., Ohseki, T., Saito, K.,
Sugiyama, K., Nishida, T., & Eguchi, K. (2005).
Broadcast Methods for Inter-Vehicle Communications System. In Proceedings of the IEEE Wireless
Communications and Networking Conference.
IEEEP802.11p (2009, May). IEEE Draft Standard
for Information Technology – Telecommunications and information exchange between systems
– Local and metropolitan area networks – Specific
requirements – Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY)
specifications Amendment 7: Wireless Access in
Vehicular Environments.
MAC Protocols in Vehicular Ad Hoc Networks
Draft 7.0, IEEE Standard 1609.1 (2006). IEEE Trial-Use Standard for Wireless Access in Vehicular
Environments (WAVE) – Resource Manager.
IEEE Standard 1609.3 (2007). IEEE Trial-Use
Standard for Wireless Access in Vehicular Environments (WAVE) – Networking Services.
Korkmaz, G., Ekici, E., & Ozguner, F. (2006).
A Cross-Layer Multihop Data Delivery Protocol
with Fairness Guarantees for Vehicular Networks.
IEEE Transactions on Vehicular Technology,
55(3), 865–875. doi:10.1109/TVT.2006.873838
Wisitpongphan, N., Tonguz, O. K., Parikh, J. S.,
Mudalige, P., Bai, F., & Sadekar, V. (2007). Broadcast Strom Mitigation Techniques in Vehicular Ad
Hoc Networks. IEEE Wireless Communications,
14(6), 84–94. doi:10.1109/MWC.2007.4407231
Sormani, D., Turconi, G., Costa, P., Frey, D.,
Migliavacca, M., & Mottola, L. (2006). Towards Lightweight Information Dissemination
in Inter-Vehicular Networks. In Proceedings of
the ACM International Workshop on Vehicular
Inter-Networking.
Yu, F., & Biswas, S. (2007). Self-Configuring
TDMA Protocols for Enhancing Vehicle Safety
with DSRC Based Vehicle-to-Vehicle Communications. IEEE Journal on Selected Areas in
Communications, 25(8), 1526–1537. doi:10.1109/
JSAC.2007.071004
IEEEStandard1609.2 (2006). IEEE Trial-Use
Standard for Wireless Access in Vehicular Environments (WAVE) – Security Services for Applications and Management Messages.
Zhang, Y., Zhao, J., & Cao, G. (2007). On Scheduling Vehicle-Roadside Data Access. In Proceedings
of the ACM International Workshop on Vehicular
Inter-Networking.
IEEE Standard 1609.4 (2006). IEEE Trial-Use
Standard for Wireless Access in Vehicular Environments (WAVE) – Multi-channel Operation.
205
206
Chapter 13
Routing Protocols in
Vehicular Ad Hoc Networks
Yuh-Shyan Chen
National Taipei University, Taipei, Taiwan, R.O.C.
Yun-Wei Lin
National Taipei University, Taipei, Taiwan, R.O.C.
absTracT
Vehicular Ad hoc Network (VANET), a subclass of mobile ad hoc networks (MANETs), is a promising
approach for the intelligent transportation system (ITS). The design of routing protocols in VANETs is
important and necessary issue for support the smart ITS. The key difference of VANET and MANET is
the special mobility pattern and rapidly changeable topology. It is not effectively applied the existing
routing protocols of MANETs into VANETs. In this chapter, we mainly survey new routing results in
VANET. The authors introduce unicast protocol, multicast protocol, geocast protocol, mobicast protocol, and broadcast protocol. It is observed that carry-and-forward is the new and key consideration for
designing all routing protocols in VANETs. With the consideration of multi-hop forwarding and carryand-forward techniques, min-delay and delay-bounded routing protocols for VANETs are discussed in
VANETs. Besides, the temporary network fragmentation problem and the broadcast storm problem are
further considered for designing routing protocols in VANETs. The temporary network fragmentation
problem caused by rapidly changeable topology influence on the performance of data transmissions.
The broadcast storm problem seriously affects the successful rate of message delivery in VANETs. The
key challenge is to overcome these problems to provide routing protocols with the low communication
delay, the low communication overhead, and the low time complexity.
inTroducTion
The growth of the increased number of vehicles
are equipped with wireless transceivers to comDOI: 10.4018/978-1-60566-840-6.ch013
municate with other vehicles to form a special
class of wireless networks, known as vehicular ad
hoc networks or VANETs (Saha et al., 2004; Xu
et al., 2004; Yousefi et al., 2004). Vehicular Ad
hoc Network (VANET) is a promising approach
for the intelligent transportation system (ITS)
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Routing Protocols in Vehicular Ad Hoc Networks
(ASTM E2213-03, 2003). Vehicle information
is delivered via the multi-hop wireless transmission over VANETs to provide safety or comfort
applications for drivers. VANETs are expected to
improve the traffic quality and provide the more
convenient driving environment for the general
populace. It is known that VANET (Saha et al.,
2004; Xu et al., 2004; Yousefi et al., 2004) is a
subclass of mobile ad hoc networks (MANETs)
(Briesemeister et al., 2000) . Just like a MANET,
a VANET has no the fixed infrastructure. In addition, vehicles with high speed mobility make
VANETs having quite different characteristics
from MANETs; such as rapidly changed topology
and frequently network fragmentation. VANETs
are mainly realized in city and highway environments. Roads and streets with intersections is the
major scenario in the city environment. Multiple
lanes with single or dual direction are investigated
in the highway environment. These two environments have different impact on VANETs. In the
city environment, packets are difficult to be successfully transmitted since the signals are easily
shielded by buildings. With the obstacles, two
vehicles are not able to be communicated even if
they are very close. In the highway environment,
the temporary network fragmentation problem is
the key issue. Furthermore, VANETs have distinctive features. For example, power constraint is
not the major concern, and location information
is easily obtained from GPS (Global Positioning
System) (Gerten et al., 2005) which is the common equipment in a vehicle. The interest problem
is how to develop the efficient routing protocols
in VANETs with the consideration of distinctive
features of VANETs.
The design of routing protocols of VANETs
is the important issue for supporting the smart
ITS. To enhance the safety of drivers and provide
the comfortable driving environment, messages
for different purposes need to be sent to vehicles
through the inter-vehicle communications. According to the number of receiving vehicles within
a geographic region, the roles of destinations are
divided into three cases: (1) a static destination or a
mobile destined vehicle, (2) more than one vehicle
in a geographic region, and (3) all vehicles within
a geographic region. When the message should be
sent to a static destination or a mobile destined vehicle, unicast routing protocol is utilized. Unicast
routing is a fundamental operation for vehicle to
construct a source-to-destination path in a VANET.
Example of unicast routing is given in Figure
1(a). For the case of the static destination, the
routing path is quite different because the source
vehicle is continuously moving at the different
time period. It is more difficult to continuously
trace the location of destination vehicle if the
destination is a mobile vehicle. Moreover, when
the information is delivered to more than one vehicle in a geographic region, multicast and geocast
routing protocols are performed. For the geocast
routing, if a vehicle receives a geocast packet
from neighbors, the packet should be forwarded
or dropped depended on its current location. If
this vehicle is located in the specific geographic
region, the geocast packet is forwarded; otherwise,
the packet is dropped. Multicast in a VANET is
defined by delivering multicast packets from a
single source vehicle to all members of multicast
in a multi-hop communications as shown in Figure
1(b). The multicast and geocast routing protocol
also are important functions for many useful applications, including collision warning system,
distributed games, replicated file systems, and
teleconferencing. Broadcast protocol is utilized
if the information should be sent to all vehicles
in a network. A source vehicle sends broadcast
message to all other vehicles in the network.
Example is illustrated in Figure 1(c). Broadcast
is an important function in many applications
of VANETs, such as advertisement publicity,
cooperative operations, group discussions, and
route discovery. The design issue of broadcasting is how to effectively prevent packet collision
and reduce the broadcasting overhead during the
broadcasting.
207
Routing Protocols in Vehicular Ad Hoc Networks
Figure 1. Applications for VANET (a) unicast routing, (b) geocast and multicast routing (c) broadcast
routing
Many results (Safa et al., 2009; Sawamura et
al., 2008; Manoharan et al., 2008; Hughes et al.,
2006; Manoharan et al., 2005) on MANETs have
been proposed for unicast, multicast and geocast,
and broadcast protocols. However, VANETs are
fundamentally different to MANETs, such as the
property of mobility and rapid changed topology
(Blum et al., 2004); therefore, VANET is subject
to frequently network fragmentation and a stable
routing path is not easily to establish. This key
differentiation causes the existing routing protocol on MANETs can not be directly applied to
VANETs. In this investigation, the recent new
results for VANET routing mechanism are first
surveyed. As shown in Figure 2, the survey is
structured into three broad categories; unicast,
multicast and geocast, and broadcast approaches.
It is observed that carry-and-forward is the new
and key consideration for designing all routing
protocols in VANETs. The key ideas of representative technologies in each category are described.
In the unicast approaches, existing unicast routing
protocols are classified into min-delay and delaybounded routing protocols. The min-delay routing
protocols (Lochert et al., 2005; Zhao et al., 2006;
Naumov et al., 2007; Chen et al., 2009; Taleb et
al., 2007; Sun et al., 2006; Wan et al., 2008) are to
construct a routing path with the minimum delay
time for a source-to-destination path. The delay-
208
bounded routing protocol (Skordylis et al., 2008) is
to establish a minimum communication overhead
routing path under a constrained delay time. For
the min-delay routing protocol, we review GPCR
(Lochert et al., 2005), VADD (Zhao et al., 2006),
CAR (Naumov et al., 2007), DIR (Chen et al.,
2009), ROMSGP (Taleb et al., 2007), reliable
routing (Wan et al., 2008), and GVGRID (Sun et
al., 2006). For the delay-bounded routing protocol,
we describe delay-bounded routing in (Skordylis
et al., 2008). In multicast and geocast approaches,
two categories of protocol are discussed, spatial
routing protocol and spatiotemporary routing
protocol. For spatial routing protocol, DRG (Joshi
et al., 2007) and IVG (Bachir et al., 2003) are
discussed. For spatiotemporary routing protocol,
a mobicast routing protocol (Chen et al., 2009)
is introduced. Finally, the broadcast approaches
are investigated. The impact of broadcast storm
problem on MANETs has been firstly defined
in (Tseng et al., 2002), then some researchers
(Tonguz et al., 2006) further discusses the impact of broadcast storm problem on VANETs.
Besides, two broadcast approaches for VANETs,
DV-CAST (Tonguz et al., 2007) and broadcast
methods for V2V communications (Fukuhara et
al., 2005), are finally reviewed. The challenges
and perspectives of routing protocols for VANETs
are finally discussed.
Routing Protocols in Vehicular Ad Hoc Networks
The remainder of this paper is organized as follows. Section 13.2 reviews unicast routing protocols in VANETs. Section 13.3 introduces multicast
and geocast routing protocols in VANETs. Section
13.4 describes broadcast routing protocols in
VANETs. Section 13.5 concludes this chapter.
unicasT rouTing proTocol
This section introduces the unicast routing protocols in VANETs. The main goal of unicast routing
in VANETs is to transmit data from a single source
to a single destination via wireless multi-hop
transmission or carry-and-forward techniques. In
the wireless multi-hop transmission, or called as
multi-hop forwarding, technique, the intermediate vehicles in a routing path should relay data as
soon as possible from source to destination. In the
carry-and-forward technique, source vehicle carries data as long as possible to reduce the number
of data packets in the VANETs. The delivery delaytime cost by using carry-and-forward technique
is normally longer than using wireless multi-hop
transmission technique. Two categories of routing
protocol designing are classified, min-delay routing protocol and delay-bounded routing protocol.
Min-delay routing protocol aims to minimize the
delivery delay-time from source to destination.
Delay-bounded routing protocol attempts to maintain a low degree of channel utilization within the
constrained delivery delay-time. Figure 3 gives
the classification of these unicast protocols.
min-delay routing protocol
The goal of min-delay routing protocols is to
transmit data packets to destination as soon as
possible. The transmission delay time is the major
concern and the shortest routing path is usually
adopted. However, the shortest routing path may
be not the quickest path with the minimum delay
time in VANETs. The shortest routing path may
be found in a low density area, packets can not
transmit by the multi-hop forwarding since that
there is no neighboring vehicle can forward
Figure 2. The taxonomy of vehicular ad hoc networks
209
Routing Protocols in Vehicular Ad Hoc Networks
Figure 3. Unicast routing protocols
packets. Packets should be delivered by carryand-forward scheme. The delay time is greatly
growing if the multi-hop forwarding can not be
utilized. Efforts will be made as finding a routing
path with multi-hop forwarding. The min-delay
routing protocols (Lochert et al., 2005; Zhao et
al., 2006; Naumov et al., 2007; Chen et al., 2009;
Taleb et al., 2007; Sun et al., 2006; Wan et al.,
2008) are reviewed as follows.
Greedy Perimeter Coordinator
Routing Protocol
Lochert et al. (2005) proposed GPCR (greedy
perimeter coordinator routing) which is a positionbased routing for urban environment. The basic
idea just likes Greedy Perimeter Stateless Routing
(GPSR) (Karp et al., 2000). The routing path is
established by the greedy method. GPCR protocol
is very well suited for highly dynamic environments such as inter-vehicle communication on the
highway or city. However, urban environment has
the radio obstacles problem (Karp et al., 2001).
Radio obstacles problem has the influence on the
performance of position-based routing. Therefore,
GPCR overcomes this problem by establishing robust routes in the city environment. GPCR adopts
the similar idea of GPSR (Blaevi´c et al., 2002)
for the selection of intermediate nodes. GPSR
needs the global knowledge of the city topology
with the street map. The sender determines which
junctions have to be traversed by some control
210
packets. Forwarding between junctions is then
done in a position-based fashion. Observe that,
GPCR does not need the global knowledge of the
street map. GPCR traverses the junctions by a restricted greedy forwarding procedure, and adjusts
the routing path by the repair strategy which is
based on the topology of streets and junctions.
Figure 4 shows that vehicle Vu tries to send packets
to vehicle VD. Vehicle 1a is selected as the next
hop of Vu if greedy forwarding scheme is used.
After vehicle 1a received the packets, vehicle
1a detects destination VD is not located at north.
Vehicle 1a then moves packets backward vehicle
2a, then the packet is forwarded to VD. It shows
that GPCR not require the global knowledge of
the city map.
Figure 4. Geographic routing protocol
Routing Protocols in Vehicular Ad Hoc Networks
VADD: Vehicle-Assisted Date
Delivery Routing Protocol
Data delivery routing protocol is developed by
Zhao et al. (2006). They proposed a vehicleassisted data delivery protocol, called VADD, in
VANETs. The VADD protocol adopted the idea
of carry-and-forward for the data delivery. The
most important issue is to select a forwarding
path with the smallest packet delivery delay. It
usually chooses the next hop closer to the destination for the data delivery, but this strategy is
not suitable for the sparsely connected vehicular
networks. In the sparsely connected vehicular
networks, transmission loss commonly occurs
in case of disconnection, the packet has to be
carried by the vehicle, while the moving speed is
significantly slower than multi-hop forwarding.
To keep the low data transmission delay, VADD
protocol transmits packets through wireless channels as much as possible, and if the packet has
to be carried through roads, the road with higher
speed is chosen firstly. VADD protocol assumes
that vehicles are equipped with pre-loaded digital
maps, which provide street-level map and traffic statistics such as traffic density and vehicle
speed on roads at different times of the day. According to the information provided by digital
maps, VADD protocol proposed a delay model
to estimate the data delivery delay in different
roads as follows,
(
dij = 1 - e
-R´rij
)´
lij ´ c
R
+e
-R´rij
´
lij
uij
,
where dij is the expected packet forwarding delay from intersection Ii to intersection Ij, R is the
communication range of vehicle, c is a constant
used to adjust expected packet forwarding delay
to a more reasonable value, rij, is the road from
intersection Ii to intersection Ij, ρij is the vehicle
density on rij, lij is the Euclidean distance of rij,
and uij is the average vehicle velocity on rij. This
delay model is very useful to estimate the data
delivery delay in VANETs.
With the delay model, VADD protocol estimates the best road with the lowest data delivery
delay based on the current kept traffic patterns. In
fact, it is difficult to find a road with the minimum
forwarding delay between two arbitrary intersections from unlimited unknown intersections. In
addition, observe that VADD only considers how
to find a path from a mobile vehicle to a fixed
location of destination vehicle. However, it is
not easily collect the in time traffic pattern and
information. From the out-of-date traffic information, VADD may establish the inappropriate
road with the greater data delivery delay. Figure
5 illustrates that vehicle Va tries to send packets
to the coffee shop, while the coffee shop is at the
fixed location. Intersections Ia, Ib, Ic, and Id, are
considered as the candidate intermediate intersections. After evaluating the expected forwarding
delay, intersections Ia, Ic, and Id are chosen. This
is because that the density of vehicle is high between intersections Ia, Ic, and Id, although it is not
the shortest path.
Connectivity-Aware Routing Protocol
To overcome the limitation of the fixed location of
destination vehicle, Naumov et al. (2007) proposed
Connectivity-Aware Routing (CAR) protocol in
VANETs. The CAR protocol is a position-based
routing scheme. CAR protocol establishes a routing path from source to destination by setting the
anchor points at intermediate intersections. Each
vehicle exchanges hello messages to collect the
information of neighboring vehicle, such as moving direction and speed. CAR sends the searching packets by using PGB algorithm (Preferred
Group Broadcast) (Naumov et al., 2006) to find
the destination and a routing path from source to
destination. Each forwarding vehicle records it’s
ID, hop count, and average number of neighbors
211
Routing Protocols in Vehicular Ad Hoc Networks
Figure 5. The environment for VADD routing protocol
in searching packets. Once the searching packets
reach the destination, the destination chooses a
better routing path which has the minimum delivery delay time and sends the reply packet to
source. While destination sends the reply packet
to source, the intersections passed through by the
reply packet are set as the anchor point. After the
path set up, data packets are forwarded in a greedy
method toward the destination through the set of
anchor points using the AGF algorithm (Advanced
Greedy Forwarding) (Naumov et al., 2006). To
maintain the routing path, a guard node is used if
the destination changes the position. The guard
node indicates the routing path to destination.
Figure 6 gives that vehicle VS tries to send data
to vehicle VD, the anchor points are set at I1,1, I2,1,
I2,2, I3,2 and I3,4 . Data is forwarded according to
order in the list of anchor points.
DIR: Diagonal-IntersectionBased Routing Protocol
To improve the CAR protocol, Chen et al. (2009)
developed a diagonal-intersection-based routing
212
(DIR) protocol in VNETS. The key difference
of CAR and DIR protocols is that DIR protocol
(Chen et al., 2009) constructs a series of diagonal
intersections between the source and destination
vehicles. The DIR protocol is a geographic routing protocol. Based on the geographic routing
protocol, source vehicle geographically forwards
the data packet toward the first diagonal intersection, the second diagonal intersection, and so on,
until the last diagonal intersection, and finally
geographically reaches to the destination vehicle.
For given a pair of neighboring diagonal intersections, two or more disjoint sub-paths exist between
them. The novel property of DIR protocol is the
auto-adjustability; while the auto-adjustability is
achieved that one sub-path with low data packet
delay, between two neighboring diagonal intersections, is dynamically selected to forward data
packets. To reduce the data packet delay, the route
is automatically re-routed by the selected sub-path
with lowest delay. Figure 7 shows that DIR protocol constructs a series of diagonal intersections
between vehicles VS and VD. Observe that, DIR
protocol may set the fewer number of anchors
Routing Protocols in Vehicular Ad Hoc Networks
Figure 6. CAR is an anchor-based routing protocol
than CAR protocol (Naumov et al., 2007). DIR
protocol can automatically adjust routing path
for keeping the lower packet delay, compared to
CAR protocol (Naumov et al., 2007).
ROMSGP Routing Protocol
To improve the routing reliability, Taleb et al.
(2007) proposed ROMSGP (Receive on Most
Stable Group-Path) routing protocol in a city
environment. Taleb et al. (2007) indicate that an
unstable routing usually disconnects due to the
loss of connectivity. This dis-connectivity is occurred if one vehicle moves out of the transmission
range of a neighboring vehicle. A large difference
of velocity exists between a pair of two vehicles.
In ROMSGP protocol, all vehicles are split into
four groups based on the velocity vector. A routing is said as a stable routing if the two vehicles
are categorized in the same group. If two vehicles
are categorized in different groups, the routing is
an unstable routing. Each group has a unique ID
and a base vector. A vehicle belongs to a group if
the velocity vector has the maximum projection
vector with this group. The stability of routing
is evaluated by comparing the group ID if other
vehicles receive packets from this sender vehicle.
Figure 8 illustrates the ROMSGP routing protocol.
Two routing paths are established, {VAVB, VBVD}
and {VAVC, VCVD}. If VA, VB, VC, and VD belong to
the same group, the two routing paths are both
stable. Packet is delivered via {VAVB, VBVD} or
{VAVC, VCVD}. If VB turns into another road, the
projection vector is changed. VB belongs to the
other group. Then the routing path {VAVC, VCVD}
is the only choice.
Reliable Routing for Roadside
to Vehicle Communications
In contrast with routing results developed in the
highway or the city environments, it is very interest that Wan et al. (2008) specially proposed
a reliable routing protocol in the rural environment. Wan et al. (2008) proposed two reliable
routing strategies for roadside to vehicle (R2V)
communication. The challenge of R2V communication in the rural environment is the terrain
factor. For instance, a vehicle moving along the
rural highway occasionally loses the line of sight
(LOS) to the neighbor vehicle or to access points
(APs) due to the obstacle-property caused by
213
Routing Protocols in Vehicular Ad Hoc Networks
Figure 7. DIR protocol sets fewer anchors than CAR protocol
Figure 8. ROMSGP routing protocol
the curve roadway and mountains. In addition,
almost no fixed communication infrastructure is
available. Multi-hop inter-vehicle communication connecting to AP is the main solution of the
R2V communication. High mobility causes the
temporary network fragmentation problem. The
link lifetime is very important issue for designing
the reliable routing to overcome the temporary
network fragmentation problem. The link lifetime
is predicted by two conditions. Once the com-
214
munication is established, the link lifetime halts
if (1) LOS between a pair of vehicles is lost, or
(2) one vehicle moves out of the communication
range of the neighboring vehicle.
A link established in a shorter distance usually has longer link lifetime. The link lifetime is
used to predict the lifetime of a route. A route is
constructed by a series of links. The lifetime of a
route is the minimum link lifetime in a route. Long
lifetime of a route improves the routing reliability
Routing Protocols in Vehicular Ad Hoc Networks
if considered the lifetime-bounded shortest path.
In addition to the lifetime of a routing path, the
length-bounded maximum lifetime path is considered. To construct a length-bounded maximum
lifetime path, reducing hops can improve the
delivery delay-time. A routing path with fewer
hops means the links are established in the long
distance. Establishing a routing path with longer
lifetime implies that the length of this routing
path is long.
Figure 9 (a) illustrates the example of lifetimebounded shortest path. The dotted line is current
routing path and the link lifetime is going to
end, where the minimum link lifetime is 9. The
solid line is the candidate path. The link lifetime
of solid line is greater than the threshold (=16).
The routing path changes to solid line by AP
assignment. Figure 9(b) illustrates the example
of length-bounded maximum lifetime path. The
dotted line is the routing path with minimum hops
to AP (hops=4). The solid line is the selected path
(hops=5).
GVGRID: A QoS Routing Protocol
To improve delivery delay-time and routing reliability, Sun et al. proposed GVGrid protocol (Sun
et al., 2006) which is a QoS routing protocol for
VANETs. GVGrid constructs a routing path from
source to destination by grid-based approach.
The goal of GVGrid is to maintain a high quality
routing path between roadsides and vehicles, or
between vehicles. GVGrid assumes each vehicle
has digital map and location information. GVGrid
divides the map into several grids. The RREQ and
RREP packets are delivered through different grid
to find a routing path through minimum number
of grid. A grid is chosen based on the direction
and the distance between vehicle and intersection
and is selected as next grid if the direction of grid
is the same as current grid or the grid is closed
to the intersection. Then the intermediate grids
between source and destination are recorded in
the routing table. An appropriate vehicle which
has the fewest number of disconnections in each
grid is chosen to forward packets to next grid. A
formula of evaluating the expected number of
disconnections is derived in (Sun et al., 2006).
The routing table records in terms of the source
vehicle, destined grid, an appropriate vehicle as
next hop with minimum the expected number
of disconnections, a vehicle as previous hop,
and the grid sequence. Once the routing path is
broken, GVGrid just finds another vehicle in the
grid instead of the previous vehicle. The routing
path does not require finding again. Figure 10 (a)
shows that vehicle VS floods RREQ message to find
vehicle VD and vehicle VD replies RREP message
to VS. Figure 10 (b) demonstrates that not only the
grid sequence but also the information of the next
vehicle are recorded in the routing table.
Figure 9. (a) lifetime-bounded shortest path (b) length-bounded maximum lifetime path
215
Routing Protocols in Vehicular Ad Hoc Networks
Figure 10.(a) An example of GVGrid routing protocol, (b) routing tables on vehicle VA and VD
delay-bounded routing protocol
Delay-bounded routing provides the low overhead in wireless communication. Delay-bounded
routing delivers packet using carry-and-forward
method as much as possible. Delay-bounded routing usually applies to non-real time services, such
as FTP, e-mail, and HTTP services. The benefits
of delay-bounded routing are follows; (1) the
wireless media resource can be reserved for other
real time service and emergency applications,
and (2) packet delivery does not be affected by
the network density. Packets can be delivered by
carry-and-forward method or multi-hop forwarding depended on the constrained delay time. If
the current delay time is less than the constrained
delay time, carry-and-forward method is used.
Otherwise, multi-hop forwarding method is used
to quickly transmit packets.
Skordylis et al. (2008) proposed a delaybounded routing protocol in VANETs, which
provides a routing scheme that satisfy user-defined
delay requirements while at the same time maintaining a low level of channel utilization. The
delay-bounded routing protocol (Skordylis et al.,
216
2008) focuses on the development of carry-andforward schemes that attempts to deliver data
from vehicles to fixed infrastructure access point
in an urban environment. Two routing algorithms,
D-Greedy (Delay-bounded Greedy Forwarding)
and D-MinCost (Delay-bounded Min-Cost Forwarding), evaluate traffic information and the
bounded delay-time to carefully opt between the
Data Muling and Multihop Forwarding strategies to minimize communication overhead while
satisfying with the delay constraints imposed by
the application.
D-Greedy algorithm adopts only local traffic
information to make routing decisions. D-Greedy
algorithm chooses the shortest path to destined AP
form the map information, and then allocates the
constrained delay-time to each street within the
shortest path according to the length of street. If
packets can be delivered under the constrained
delay-time in a street, Data Muling strategy is
utilized. Packets are carried by a vehicle and
forwarded at the vehicle’s speed to destined AP.
Otherwise, Multihop Forwarding strategy is applied if packets cannot be delivered within the
constrained delay-time. Packets are delivered
Routing Protocols in Vehicular Ad Hoc Networks
by multi-hop forwarding. To determine which
strategy is adopted, the bounded delay time Del
is evaluated as follows,
defer_tim e(R ) = MaxDeferTime ´
(r - d )
SR
r
where TTL is the life time of packet, distToInt is
the remaining length, and disToAP is the distance
to AP station. The expected delay time at different
time is evaluated by the equation below,
DelDM =
distToInt
u
A vehicle transmits packets to AP station
by carry-and-forward method if Del>DelDM. If
Del<DelDM, multi-hop forwarding is applied.
D-MinCost algorithm considers the global
traffic information in a city to achieve the minimum channel utilization within the constrained
delay-time. According to the global traffic information, the cost C and delay Del of each street
can be pre-computed. The cost C represents the
number of message transmissions in a street. The
delay Del denotes the time required to forward a
message in a street. The cost C and delay Del of
a street are evaluated as follows,
DelDM =
C MH =
l
,C
= 1,
u DM
1
, DelMH + C MH ´ q ,
R
where DelDM denotes the time required to carryand-forward a message through a street by Data
Muling strategy, and l denotes the length of a street
and u denotes the average vehicle velocity in this
street. When the Data Muling strategy is applied,
the packet is carried by a vehicle to forward, the
vehicle only delivers the packet once at next
intersection. The cost of Data Muling strategy is
1, so CDM = 1. The CMH represents the number of
message transmissions in a street by Multihop
Forwarding strategy. The R denotes the maximum
transmission range of a vehicle. The q denotes the
time required for a vehicle to check its neighbor
list and identify the best next hop.
To achieve the minimum cost C within the
constrained delay Del, DSA (Delay Scaling Algorithm) (Goel et al., 2001) is applied, in order
to efficiently compute delay-constrained least
cost paths from the vehicle’s location to all access points on a network. The best routing path is
opted by DSA (Goel et al., 2001) with minimum
channel utilization under the constrained delaytime. Figure 11 shows that Data Muling strategy
is applied if the packet can be delivered form VA to
AP within the constrained delay-time. Otherwise,
the packet is delivered by Multihop Forwarding
strategy. When Multihop Forwarding strategy
is applied, the packet is transmitted to a vehicle
which is the closest to AP. Vehicle VC is choose
by VA to relay packets to AP station.
mulTicasT and geocasT
rouTing proTocol
Multicast and geocast routings are the other important routing operations in VANETs. Many VANET
applications require disseminating information to
a group of mobile vehicles in a VANET. These
applications include distributed games, replicated
file systems, teleconferencing, etc. The multicast in
VANETs is defined by delivering multicast packets
from a mobile vehicle to all multicast-member
vehicles. The geocast in VANETs is defined by
delivering geocast packets from a source vehicle
to vehicles located in a specific geographic region. One of the challenges is how to develop
the efficient multicast and geocast protocol over
VANETs with the highly changeable topology and
temporary network fragmentation to guarantee that
217
Routing Protocols in Vehicular Ad Hoc Networks
Figure 11. Data muling and multihop forwarding strategies
vehicles can be successfully received the multicast
and geocast packets in VANETs.
Usually, the temporary network fragmentation
problem affects the performance of multicast and
geocast operations. When a vehicle moves under a
highly speed, the velocity variation between each
pair of vehicles is large. The distance between
each pair of vehicles quickly changes. This easily offers the temporary network fragmentation
problem. When a vehicle easily moves out of the
communication range of the sender and no neighboring vehicle is able to forward packets, then
this vehicle fails to receive multicast and geocast
packets. This condition is to lose the connectivity.
Some results (Joshi et al., 2007; Bachir et al., 2003;
Chen et al., 2009) have recently investigated the
multicast and geocast protocols in a VANET. All
of them mainly consider overcoming the temporary network fragmentation problem. It is very
important to consider the factors of temporary
network fragmentation problem when designing
the multicast and geocast protocols. According to
the property of geographic region, existing results
can be classified into multicast, geocast protocol,
and spatiotemporary multicast/geocast routing
protocols as shown in Figure 12. This section
reviews the existing results for VANETs.
distributed robust geocast
multicast routing protocol
The goal of distributed robust geocast multicast
routing protocol is to deliver packets to vehicles
located in a specific geographic region. A vehicle
should receive packets or drop only depended on
its current location. If a vehicle is located in the
specific geographic region, this vehicle receives
packets. Otherwise this vehicle drops packets.
Packet reception in the geocast multicast routing
protocols mainly considers whether vehicles are
located in the specific geographic region. Joshi
et al. (2007) had proposed a distributed robust
Figure 12.Existing multicast and geocast routing protocols
218
Routing Protocols in Vehicular Ad Hoc Networks
geocast protocol for inter-vehicle communication. The zone of relevance (ZOR) is defined in
(Joshi et al., 2007) as a geographic region which
vehicles in this region should receive the geocast
messages. Joshi et al. pointed out that a stable route
is difficult to setup in a VANET due to limited
lifetime of a connectivity and frequently network
fragmentation. To enhance the reliability of receiving geocast messages under frequently changeable topology, the zone of forwarding (ZOF) is
defined in (Joshi et al., 2007) as the geographic
region which vehicles in this region should forward the geocast messages to other vehicles in the
ZOR. Note that, ZOF usually surrounds ZOR to
ensure the geocast messages can be delivered to
vehicles inside ZOR. A periodic retransmission
mechanism is proposed in (Joshi et al., 2007) to
overcome the network fragmentation. Besides, a
distance-based backoff algorithm is used to reduce
the number of hops and redundant broadcasts.
The random backoff time is determined by the
distance to sender vehicle. The longer distance
is, the smaller backoff time will be, the hops
can be reduced. Once a vehicle broadcasts, the
neighboring vehicles may not broadcast, redundant
broadcasts can be reduced. Figure 13 shows that
the temporary network fragmentation problem is
overcame with the assistances of vehicles of ZOF,
for instance, VG and VF.
multicast protocol in ad hoc
networks inter-Vehicle geocast
Bachir et al. (2003) proposed a multicast protocol
in ad hoc networks inter-vehicle geocast, called
IVG protocol (Bachir et al., 2003). The IVG protocol is used to inform all the vehicles in a highway
if any danger is occurred; such as an accident. The
risk area is determined in terms of driving direction
and positioning of vehicles. Vehicles located in
the risk area form a multicast group. The multicast
group is defined temporarily and dynamically
by the location, speed, and driving direction of
vehicles. IVG protocol uses periodic broadcasts
to overcome temporary network fragmentation
for delivering messages to multicast members.
The re-broadcast period is calculated based on the
maximum vehicle speed. Besides, IVG protocol
reduces the hops of delivering message by using
the deferring time, such that
defer_tim e(R ) = MaxDeferTime ´
(r - d )
SR
r
Figure 13. DRG multicast routing protocol
219
Routing Protocols in Vehicular Ad Hoc Networks
where r is the transmission range and dSR is the
distance between sender vehicle VS and receiving
vehicle VR. The farthest vehicle with larger dSR
waits for the less time to re-broadcast. Figure 14
shows an example for the IVG protocol. Vehicle
VA encounters car-function-failure problem and
sends this notification to all vehicles in the risk
area. Vehicles VB, VC, and VD form a multicast group
since they are located in the risk area. Vehicle VC
is the next hop of VA since the VC is farther from
VA than VB. After vehicle VC sending out packets,
vehicle VB not forwards packet.
spatiotemporary multicast/
geocast routing protocol
The spatiotemporary multicast/geocast routing
protocol is a new and very interest routing problem.
Unlike ordinary multicast and geocast routing protocols, the spatiotemporary multicast and geocast
Figure 14. IVG multicast protocol
Figure 15. Applications for mobicast routing
220
routing protocol should take the time factor into
account. The distinctive feature of this new form
of spatiotemporary multicast and geocast routing
protocol is the delivery of information to all nodes
that happen to be in a prescribed region of space
at a particular point in time. Chen et al. (2009)
presents a “spatiotemporary multicast”, called a
“mobicast”, protocol for supporting applications
which require spatiotemporary coordination in
VANETs. The spatiotemporary character of a
mobicast is to forward a mobicast message to
vehicles located in some geographic zone at time
t, where the geographic zone is denoted as zone
of relevance (ZORt). Vehicles located in ZORt at
the time t should receive the mobicast message.
Many interesting and useful applications on
VANETs can be supported by mobicast routing
protocol, such as emergency event (Park et al.,
2006), online game (Palazzi et al., 2007), and
video advertisement (Yoon et al., 2008). Mobicast
routing protocol can be effectively used for those
VANETs applications for emergency warning,
online game invitation, and video advertisement,
as illustrated in Figure 15. Figure 15 (a) shows
vehicle Ve has the control failure problem for a short
period of time, and warning messages are sent to
all nearby vehicles to avoid accident. By mobicast
routing protocol, warning messages can be sent
to vehicles in the warning area to avoid accident.
Figure 15 (b) shows an online game application,
vehicle Ve can invite those nearby vehicles to be
game-playing members for a longer period of
Routing Protocols in Vehicular Ad Hoc Networks
time. Our mobicast routing protocol can make
sure that the game information can disseminate
to all members in ZORt.
To ensure the mobicast message can be sent
to all vehicles in ZORt, vehicles located in ZORt
at the time t must keep the connectivity to maintain the real-time data communication between
all vehicles in ZORt. The connectivity is kept of
all vehicles in ZORt through the vehicular ad hoc
networks. The connectivity of ZORt is lost if any
vehicle in ZORt suddenly accelerates or decelerates
its velocity. The temporal network fragmentation
problem is occurred such that vehicle in ZORt cannot successfully receive the mobicast messages.
To solve the problem, Chen et al. proposed a new
mobicast protocol to successfully disseminate
mobicast messages to all vehicles in ZORt via a
special geographic zone, called as zone of forwarding (ZORt). The proposed mobicast routing
protocol can dynamically estimate the accurate
ZORt. to successfully disseminate mobicast messages to all vehicles in ZORt. As shown in Figure
16, gives a continuous-time example of ZORi,
where i = t…t + 2, with the temporal network
fragmentation problem. The transmission range
of each vehicle is assumed to r. Initially, Ve detects
an emergency event at time t to form a ZORt. V1
and V3 are involved by this event and indicated
to receive the mobicast message by ZORt. V1 and
V3 are located within the transmission range of Ve;
thus Ve directly disseminates the mobicast message
to V1 and V3. At time t + 1, V2 and V4 approach
Ve and they are indicated to receive the mobicast
message by ZORt+1. Observed that although V4. is
out of transmission range of Ve, V4 can receive the
mobicast message by relaying from V1. At time
t + 2, V1 moves away from V4 and V2 moves out
of transmission range of Ve; thus V2 and V4 can
not receive the mobicast message. The temporal
network fragmentation problem occurred on V2
and V4. ZORt is introduced below to solve this
problem.
To overcome the temporal network fragmentation
problem, ZORt is used to disseminate the mobicast
message to all vehicles located in the ZORt. ZORt is
a geographic zone greater than ZORt to involve more
vehicles to forward the mobicast message. Vehicles
in ZORt should forward the mobicast message to
another vehicles located in ZORt. ZORt indicates
which vehicle should forward the mobicast
message to other vehicles located in the ZORt.
All vehicles in ZORt must forward the received
mobicast message; even those vehicles are not
located in ZORt. Figure 17(a) shows V2 and V4 can
not receive the mobicast message due to the temporal network fragmentation problem. Example
of ZORt is illustrated in Figure 17(b), V5 and V6
are located in ZORt and have the responsibility
of forwarding the mobicast message to V2 and V4,
respectively. Normally, the size of ZORt may be
larger or smaller than the optimal size of ZORt . If
the size of ZORt is larger than the optimal size of
ZORt, some irrelevant vehicles are asked to uselessly forward the mobicast message. If the size
Figure 16. Temporal network fragmentation problem
221
Routing Protocols in Vehicular Ad Hoc Networks
of ZORt is smaller than the optimal size of ZORt,
the temporal network fragmentation problem is
incompletely overcome. Observe that, the size of
ZORt is difficult to predict and determined under
the high speed environment, such that it easily
wastes the network resources. Chen et al. proposed
an efficient scheme to estimate the size of ZORt is
near to the optimal size of ZORt. Therefore, zone
V
V
of approaching ZOAt i or Zt i is proposed herein
to accurately predict the ZORt.
V
V
ZOAt i or Zt i is an elliptic zone of approaching to forward the mobicast message more closed
V
to a destined vehicle and Zt i is initiated by vehicle
V
Vi at time t. Any vehicle in the Zt i has the responsibility of forwarding the mobicast message sent
V
from vehicle Ve. Zt i bounds the mobicast message
V
propagation, vehicles in the Zt i can only forward
the mobicast message to other vehicles located in
V
the Zt i . If a vehicle cannot successfully forward
the mobicast message to any neighbor vehicle
V
in the Zt i which is more closed to the destined
vehicle, a new approaching zone is initiated. The
Vi
from
growing of a new zone of approaching Zt +1
V
an existing zone of approaching Zt i is explained as
follows. Given two connected approaching zones
V
V
i
Zt i and ZtV+1
, if Vi+1 in Zt i cannot successfully
forward the mobicast message to any neighbor
vehicle closed to the destined vehicle, then Vi+1
Vi
, where
initiates a new zone of approaching Zt +1
Figure 17. Function of ZORt and ZOFt
222
V
i
. Therefore, multiple zones
Vi+1 is located in Zt +1
of approaching are initiated to forward the mobicast message, such that ZORt is finally formed by
all initiated zones of approaching. Therefore, we
Vi
V
V
∪… ∪
have ZORt = ZORt∪ Zt i ∪… ∪ Zt i ∪ Zt +1
Vn
Zt . Observe that, ZORt is the partial ZORt since
the mobicast message should be transmitted to all
vehicles located in ZORt. Figure 18 demonstrates
an example of the proposed mobicast routing
protocol. At time t, V1, V2, V3, and V4 are located
in ZORt and receive the mobicast message from
vehicle Ve. At time t +1, V2 and V4 can not directly
receive the mobicast messages due to temporal
network fragmentation problem. At time t +1, Ve,
Ve
V5
V1
, Zt +1
, and Zt +1
to forward
V5, and V1 initiate Zt +1
the mobicast messages to vehicles V4 and V2. In
Ve
V5
V1
∪ Zt +1
∪ Zt +1
.
this case, ZORt+1 = ZORt+1∪ Zt +1
broadcasT rouTing proTocol
Broadcast is the last important operation for a
vehicle to disseminate a broadcast message to
all the others in a VANET. To overcome the temporary network fragmentation problem to avoid
some vehicles cannot be successfully received the
broadcast message. This section describes existing
broadcast routing protocols in VANETs, as listed
in Figure 19, as follows.
Routing Protocols in Vehicular Ad Hoc Networks
Figure 18. Zone of approaching ZORt
Figure 19. Existing broadcast routing protocols
on The broadcast storm problem
in ad hoc wireless networks
The broadcast storm problem has been heavily
discussed in MANETs (Tseng et al., 2002). Tonguz
et al. (2006) further demonstrates the broadcast
storm problem occurred in VANETs. The broadcast storm problem causes serious packet collision
and packet loss since too many vehicles simultaneously broadcast messages. A shortest routing
path can be discovered by broadcasting the RREQ
(route request) message. The broadcast routing
strategies developed in (Tonguz et al., 2006) are
1-persistence and p-persistence. However, these
two strategies easily cause the broadcast storm
problem, especially in a high density network.
Tonguz et al. (2006) thus proposed three distributed broadcast suppression techniques, weighted
p-persistence, slotted 1-persistence, and slotted p-
persistence schemes. In the weighted p-persistence
scheme, if vehicle Vj receives a packet form vehicle
Vi, vehicle Vj first checks whether the packet has
been received. If vehicle Vj receives this packet
at the first time, then vehicle Vj has probability
pij to re-broadcast the packet. Otherwise, vehicle
Dij
, where Dij
Vj drops this packet, under pij =
R
is the distance between vehicle Vi and Vj, R is
the transmission range. Neighbors of vehicle Vi
change pij to 1 to ensure that the message must
be broadcasted if they have no received the rebroadcast message after waiting a random time.
In the slotted 1-persistence scheme, If vehicle Vj
firstly receives this packet from vehicle Vi, then
vehicle Vj waits for TS time slots, vehicle Vj has
ij
probability 1 to re-broadcast the packet, where
TS = Sij×τ.
ij
223
Routing Protocols in Vehicular Ad Hoc Networks
ïìïé æ
D öù
ïïêêN ççç1 - ij ÷÷÷úú ,
Sij = íê s çè
R ÷÷øú
ú
ïïê
ïï
0,
ïî
if
dV-casT: broadcasting in VaneT
Dij
if
,
Dij > R
where τ is the propagation time for one hop
transmission and Ns is the default number of
time-slot.
The slotted p-persistence scheme combines the
weighted p-persistence and slotted 1-persistence
schemes. If vehicle Vj firstly receives the packet
from Vi, then vehicle Vj waits for TS time-slots.
ij
Vehicle Vj has probability pij to re-broadcast the
packet. Simulation results show that these three
schemes can achieve up to 90% reduction of
packet loss rate. Figure 20 gives the example of
these three broadcast schemes. In Figure 20(a),
the weighted p-persistence scheme is used. Figure
20(b) illustrates the slotted 1-persistence scheme.
Figure 20(c) shows the slotted p-persistence
scheme.
Tonguz et al. (2007) proposed DV-CAST for a
multi-hop broadcast routing protocol in VANETs.
Tonguz et al. (2007) indicates three traffic scenarios for a vehicular broadcasting; (1) dense
traffic scenario, (2) sparse traffic scenario, and
(3) regular traffic scenario. Tonguz et al. (2007)
integrates previously proposed routing solution
in (Tonguz et al., 2006) to develop DV-CAST
which is suitable for both of dense and sparse
traffic scenarios. The overhead in dense traffic
scenario can be reduced. DV-CAST utilizes the
information form one-hop neighbors to make the
routing decision. Each vehicle records the states of
neighboring vehicles all the time. Three parameters
should be recorded; (1) DFlag (Destination Flag),
(2) MDC (Message Direction Connectivity), and
(3) ODC (Opposite Direction Connectivity). The
DFlag indicates whether the direction of the current vehicle is the same as the source vehicle. The
MDC describes whether a vehicle exists behind
Figure 20. Broadcast suppression techniques (a) weighted p-persistence scheme (b) slotted 1-persistence
scheme (c) slotted p-persistence scheme
224
Routing Protocols in Vehicular Ad Hoc Networks
Figure 21. Well-connected neighborhood
the current vehicle to assist broadcast message
forwarding. The ODC indicates whether a vehicle
exists in the opposite direction. Vehicles can make
decision based on these three parameters. For
example, if a vehicle Vi receives a new broadcast
message, vehicle Vi firstly checks MDC. If there
are vehicles behind vehicle Vi(MDC=1), vehicle Vi
uses broadcast suppression schemes proposed in
(Tonguz et al., 2006) to forwarding the broadcast
message. Otherwise (MDC=0), vehicle Vi checks
ODC. If there are vehicles in the opposite direction
(ODC=1, MDC=0), vehicle Vi forwards the broadcast message to vehicles in the opposite direction.
After vehicle Vi broadcasting message, vehicle
Vi checks DFlag. If the direction of vehicle Vi is
different from source vehicle (DFlag=0), vehicle
Vi overhears for a period of time to ensure that
the message is successfully broadcasted. Figure
21 shows that the broadcast message is initiated
by VS and it is forwarded from group 1 to group
2. Although groups 1, 2, and 3 are dense group,
groups 1 and 2 encounter the temporary network
fragmentation problem. Group 1 cannot directly
forward packets to group 2. In this case, vehicle
VS can forward packets to group 3 which is in the
reverse direction, then vehicle VS forwards packets
to group 2. Observe that, the temporary network
fragmentation problem is also considered in the
design of broadcasting.
broadcast methods for
inter-Vehicle communications
system
Fukuhara et al. (2005) proposed broadcast methods for inter-vehicle communications system to
provide emergency information dissemination in
VANETs. The purpose of emergency information
is to announce an urgent event by broadcasting for
surrounding vehicles. According to the purposes
of emergency information, the proposed broadcast
methods in (Fukuhara et al., 2005) are divided
into two categories, emergency-vehicle-approach
information and traffic accident information.
Emergency-vehicle-approach information is used
to announce the urgent event to those vehicles
in front of the current vehicle, so the emergency
information is only disseminated ahead. Traffic
accident information is used to announce the
urgent event to those vehicles behind the current vehicle; the emergency information is only
disseminated behind. By limiting the broadcast
direction, the proposed broadcast methods (Fukuhara et al., 2005) can provide broadcasts to a
particular area and avoid mistakenly notifying
other areas where the information is not needed.
To decide emergency information should be received, forwarded, or dropped, three conditions
below are examined:

(X
C



- X E + aV F ×V F > 0 ,
)



X C - X E + aV F < Rnotification ,
(1)
(2)
225
Routing Protocols in Vehicular Ad Hoc Networks
Figure 22. The broadcast area for emergency information



X C - X E + aV F < Rrelay ,
(3)
where XC is the location vector of the current vehicle, XE is the location vector of the emergency
vehicle, VF is the forward direction vector of the
emergency information, Rnotification is the available
notification range, and Rrelay is the available relay
range.
If conditions (1) and (2) are true, the current
vehicle receives the emergency information. If
conditions (1) and (3) are true, the current vehicle
re-broadcasts the emergency information. Figure
22 shows that vehicle VA broadcasts the emergency
message to the restricted direction. Vehicle VD does
nothing. Vehicle VD is located in the relay range, it
re-broadcasts the emergency information. Vehicle
VD is located in notification range but not in relay
range, VC just receives the emergency information
and not to re-broadcast.
conclusion
Unicast, multicast, and broadcast routing operations are key issues in the network layer for
VANETs. This chapter surveys existing unicast,
multicast, and broadcast protocols for VANETs.
The unicast routing protocols are split into
min-delay and delay-bound approaches. The
min-delay unicast routing protocols construct
a minimum-delay routing path as soon as pos-
226
sible. The delay-bound routing protocol utilizes
the carry-and-forward technique to minimize the
channel utilization within a constrained delay time.
This chapter also surveys important multicast and
geocast protocols for VANETs. The multicast in
VANETs is defined by delivering multicast packets
from a mobile vehicle to all multicast-member
vehicles. The geocast in VANETs is defined by
delivering geocast packets from a source vehicle
to vehicles located in a specific geographic region.
A mobicast routing protocol in VANETs is also
described. Finally, broadcast protocols in VANETs
are also introduced. We predict the tendency of
the design of routing protocols for VANETs must
be the low communication overhead, the low time
cost, and high adjustability for the city, highway,
and rural environments.
reFerences
Amouris, K. (2005). Position-Based Broadcast
TDMA Scheduling for Mobile Ad-Hoc Networks
(MANETs) with Advantaged Nodes. IEEE Military Communications Conference, 1, 252–257.
ASTM International E2213-03 (2003). Standard Specification for Telecommunications and
Information Exchange Between Roadside and
Vehicle Systems 5 GHz Band Dedicated Short
Range Communications (DSRC) Medium Access Control (MAC) and Physical Layer (PHY)
Specifications.
Routing Protocols in Vehicular Ad Hoc Networks
Bachir, A., & Benslimane, A. (2003). A Multicast Protocol in Ad hoc Networks Inter-Vehicle
Geocast. IEEE Semiannual Vehicular Technology
Conference, 4, 2456-2460.
Blaževi’c, L., Giordano, S., & LeBoudec, J.
Y. (2002). Self Organized Terminode Routing.
Cluster Computing Journal, 5(2), 205–208.
doi:10.1023/A:1013998030317
Blum, J., Eskandarian, A., & Hoffman, L. (2004).
Challenges of inter-vehicle ad hoc networks.
IEEE Transactions on Intelligent Transportation Systems, 5(4), 347–351. doi:10.1109/
TITS.2004.838218
Hughes, L., & Maghsoudlou, A. (2006). An Efficient Coverage-Based Flooding Scheme for
Geocasting in Mobile Ad Hoc Networks. International Conference on Advanced Information
Networking and Applications, 1, 6.
Joshi, H. P., Sichitiu, M., & Kihl, M. (2007).
Distributed Robust Geocast Multicast Routing for
Inter-Vehicle Communication. WEIRD Workshop
on WiMax, Wireless and Mobility.
Karp, B. (2001). Challenges in Geographic Routing: Sparse Networks, Obstacles, and Traffic
Provisioning. In DIMACS Workshop on Pervasive
Networking.
Briesemeister, L., & Hommel, G. (2000). Overcoming Fragmentation in Mobile Ad hoc Networks. Journal of Communications and Networks,
2(3), 182–187.
Karp, B., & Kung, H. T. (2000). GPSR: Greedy
Perimeter Stateless Routing for Wireless Networks. ACM International Conference on Mobile
Computing and Networking, (pp. 243-254).
Chen, Y. S., Lin, Y. W., & Lee, S. L. (2009). A
Mobicast Routing Protocol for Vehicular Ad Hoc
Networks. Mobile Networks and Applications
(MONET).New York: ACM/Springer.
Lochert, C., Mauve, M., Füßler, H., & Hartenstein, H. (2005). Geographic routing in city
scenarios. ACM SIGMOBILE Mobile Computing and Communications, 9(1), 69–72.
doi:10.1145/1055959.1055970
Chen, Y. S., Lin, Y. W., & Pan, C. Y. (2009). A
Diagonal-Intersection-Based Routing Protocol
for Urban Vehicular Ad Hoc Networks. Telecommunication System, (under revision).
Fukuhara, T., Warabino, T., Ohseki, T., Saito, K.,
Sugiyama, K., Nishida, T., & Eguchi, K. (2005).
Broadcast Methods for Inter-vehicle Communications System. IEEE Wireless Communications and
Networking Conference, 4, 2252-2257.
Gerten, G. (2005). Protecting the Global Positioning System. IEEE Aerospace and Electronic
Systems Magazine, 20(11), 3–8. doi:10.1109/
MAES.2005.1576067
Goel, A., Ramakrishnan, K. G., Kataria, D., &
Logothetis, D. (2001). Efficient Computation of
Delay-Sensitive Routes from One Source to All
Destinations. IEEE Conference on Computer
Communications (INFOCOM), (pp. 854–858).
Manoharan, R., & Thambidurai, S. L. P. P. (2008).
Energy Efficient Robust On-Demand Multicast
Routing Protocol for MANETs. [IJAHUC].
International Journal of Ad Hoc and Ubiquitous Computing, 3(2), 90–98. doi:10.1504/
IJAHUC.2008.017002
Naumov, V., Baumann, R., & Gross, T. (2006).
An Evaluation Of Inter-Vehicle Ad Hoc Networks
Based On Realistic Vehicular Traces. In ACM
International Symposium on Mobile Ad Hoc
Networking and Computing, (pp. 108-119).
Naumov, V., & Gross, T. (2007). ConnectivityAware Routing (CAR) in Vehicular Ad Hoc
Networks. IEEE International Conference on
Computer Communications (INFOCOM’07),
(pp. 1919-1927).
227
Routing Protocols in Vehicular Ad Hoc Networks
Palazzi, C. E., Roccetti, M., Pau, G., & Gerla,
M. (2007). Online Games on Wheels: Fast Game
Event Delivery in Vehicular Ad-hoc Networks. In
IEEE Intelligent Transportation Systems Society,
(pp. 42–49).
Park, J. S., Lee, U., Oh, S. Y., Gerla, M., & Lun,
D. (2006). Emergency Related Video Streaming in VANETs using Network Coding. In ACM
International Workshop on Vehicular Ad Hoc
Networks (VANET), (pp. 102-103).
Safa, H., Artail, H., & Shibli, R. (2009). An
Interoperability Model for Supporting Reliability and Power-Efficient Routing in MANETs.
[IJAHUC]. International Journal of Ad Hoc and
Ubiquitous Computing, 4(2), 71–83. doi:10.1504/
IJAHUC.2009.023898
Saha, A. K., & Johnson, D. B. (2004). Modeling
mobility for vehicular ad hoc networks. ACM
International Workshop on Vehicular Ad Hoc
Networks (VANET), (pp. 91-92).
Sawamura, T., Tanaka, K., Atajanov, M., Matsumoto, N., & Yoshida, N. (2008). Adaptive Router
Promotion and Group Forming in Ad-Hoc Networks. [IJAHUC]. International Journal of Ad
Hoc and Ubiquitous Computing, 3(4), 217–223.
doi:10.1504/IJAHUC.2008.018907
Skordylis, A., & Trigoni, N. (2008). DelayBounded Routing in Vehicular Ad-Hoc Networks.
ACM international symposium on Mobile ad hoc
networking and computing, (pp. 341-350).
Sun, W., Yamaguchi, H., Yukimasa, K., &
Kusumoto, S. (2006). GVGrid: A QoS Routing
Protocol for Vehicular Ad Hoc Networks. IEEE
International Workshop on Quality of Service,
(pp. 130-139).
Taleb, T., Sakhaee, E., Jamalipour, A., Hashimoto,
K., Kato, N., & Nemoto, Y. (2007). A Stable Routing Protocol to Support ITS Services in VANET
Networks. IEEE Transactions on Vehicular
Technology, 56(6), 3337–3347. doi:10.1109/
TVT.2007.906873
228
Tonguz, O., Wisitpongphan, N., Bai, F., Mudalige,
P., & Sadekar, V. (2007). Broadcasting in VANET.
Mobile Networking for Vehicular Environments,
(pp. 7-12).
Tonguz, O. K., Wisitpongphan, N., Parikh, J. S.,
Bai, F., Mudalige, P., & Sadekar, V. K. (2006).
On the Broadcast Storm Problem in Ad hoc
Wireless Networks. International Conference
on Broadband Communications, Networks and
Systems, (pp. 1-11).
Tseng, Y. C., Ni, S. Y., Chen, Y. S., & Sheu,
J. P. (2002). The Broadcast Storm Problem
in a Mobile Ad Hoc Network. [WINET].
ACM Wireless Networks, 8(2), 153–167.
doi:10.1023/A:1013763825347
Wan, S., Tang, J., & Wolff, R. S. (2008). Reliable
Routing for Roadside to Vehicle Communications
in Rural Areas. In IEEE International Conference
on Communications, (pp. 3017-3021).
Xu, Q., Mak, T., Ko, J., & Sengupta, R. (2004).
Vehicle-to-Vehicle Safety Messaging in DSRC.
In ACM International Workshop on Vehicular Ad
Hoc Networks (VANET), (pp. 19-28).
Yoon, H., Kim, J., Tan, F., & Hsieh, R. (2008).
On-demand Video Streaming in Mobile Opportunistic Networks. In IEEE International Conference
on Pervasive Computing and Communications
(PerCom), (pp. 80–89).
Yousefi, S., Mousavi, M. S., & Fathy, M. (2006).
Vehicular Ad Hoc Networks (VANETs): Challenges and Perspectives. International conference
on ITS Telecommunications, (pp. 761-766).
Zhao, J., & Cao, G. (2006). VADD: VehicleAssisted Data Delivery in Vehicular Ad Hoc
Networks. IEEE Computer Communications,
(pp. 1-12).
229
Chapter 14
Applications in Vehicular
Ad Hoc Networks
Tzung-Shi Chen
National University of Tainan, Tainan, Taiwan, R.O.C.
Hua-Wen Tsai
National University of Tainan, Tainan, Taiwan, R.O.C.
Yi-Shiang Chang
National University of Tainan, Tainan, Taiwan, R.O.C.
absTracT
The various sensors and wireless communication devices have been extensively applied to daily life due
to the advancements of microelectronics mechanism and wireless technologies. Recently, vehicular communication systems and applications become more and more important to people in daily life. Vehicular
communication systems that can transmit and receive information to and from individual vehicles have
the potential to significantly increase the safety of vehicular transportation, improve traffic flow on congested roads, and decrease the number of people of deaths and injuries in vehicular collisions effectively.
This system relies on direct communication between vehicles to satisfy the communication needs of a
large class of applications, such as collision avoidance, passing assistance, platooning. In addition,
vehicular communication systems can be supplemented by roadside infrastructure to access Internet and
other applications. This system forms a special case of mobile ad hoc networks called Vehicle Ad Hoc
Networks (VANETs). They can be formed between vehicles with vehicle to vehicle (V2V) communication or between vehicles and an infrastructure with vehicle to infrastructure (V2I) communication. The
applications and characteristics of VANETs are introduced and presented in this Chapter.
inTroducTion
Recently, the various sensors and wireless communication devices have been extensively applied
to daily life due to the advancements of microDOI: 10.4018/978-1-60566-840-6.ch014
electronics mechanism and wireless technologies.
Vehicular transportation is one of the main modes
of transportation for millions of U.S. citizens and
hundreds of millions around the world in spite of
increasing oil prices and environmental concerns.
However, 38,252 Americans were killed in 2003
with 2,697,000 seriously injured. Furthermore,
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Applications in Vehicular Ad Hoc Networks
each day the average American spends 2.5 hours
in his/her vehicle, a significant percentage of
this time in traffic jams and at stop lights. The
statistics are similar in many other parts of the
world (Sichitiu et al., 2008). On an average day
in the United States, vehicular collisions kill
116 and injure 7900. More health care dollars
are consumed in the United States treating crash
victims than any other cause of illness or injury;
the situation in the European Union is similar,
with over 100 deaths and 4600 injuries daily, and
the annual cost of € 160 billion. Governments and
automotive companies are responding by making
the reduction of vehicular fatalities a top priority
(Robinson et al., 2006).
Vehicular communication systems that can
transmit and receive information to and from
individual vehicles have the potential to significantly increase the safety of vehicular transportation, improve traffic flow on congested roads,
and decrease the number of people of deaths and
injuries in vehicular collisions effectively. This
system relies on direct communication between
vehicles to satisfy the communication needs
of a large class of applications (e.g., collision
avoidance, passing assistance, platooning, and
so on). Vehicular communication systems can be
supplemented by roadside infrastructure to access
Internet and other applications. This system forms
a special case of mobile ad hoc networks called
Vehicle Ad Hoc Networks (VANETs). They can be
formed between vehicles with vehicle to vehicle
(V2V) communication or between vehicles and
an infrastructure with vehicle to infrastructure
(V2I) communication.
VANETs can increase security, efficiency and
comfortable trip in collecting road traffic. Such
systems can enable a wide range of applications,
such as collision avoidance, emergency message
dissemination, dynamic route scheduling, route
navigation, and real-time traffic condition monitoring. Traditional vehicular networks for reporting accidents or traffic conditions rely on certain
infrastructure, such as road-side traffic sensors
230
reporting data to a central database, or cellular
wireless communication between vehicles and
a monitoring center. The advantage of VANET
is not needed to deploy too many expensive
infrastructures to be installed on every road and
intersections. VANETs are emerging as the preferred network design for intelligent transportation
systems. VANETs are based on short-range wireless communication (e.g., IEEE 802.11) between
vehicles. However, the disadvantage of VANETs is
in supporting complex network protocols. The existing researches focus on medium access control
(MAC) and routing issues, in particular pointing
to the mismatch between the need of inter-vehicle
communication applications for group communications and the services offered by mobile ad hoc
network (MANET) routing protocols.
Several applications enabled by vehicular
communication systems are classified. The most
commonly considered applications are related
to public safety and traffic coordination. Traffic
management applications, traveler information
support, and various comfort applications have
the potential to make travelling more efficient,
convenient and pleasant. For each type of application, we consider its addressing and real-time
requirements and the type of vehicular communication necessary for its implementation.
Generally speaking, vehicular communication
systems are classified into three major types,
inter-vehicle communication (IVC), roadsideto-vehicle communication systems (RVC), and
hybrid vehicular communication (HVC).
IVC systems are completely infrastructure-free
and only need some in-vehicle equipments. Depending on whether the information is retransmitted at intermediate hops or not, we can further distinguish between single-hop and multi-hop IVCs,
SIVCs and MIVCs, respectively. SIVC systems
are useful for applications requiring short-range
communications, e.g., lane merging, automatic
cruise control. MIVC systems are more complex
than SIVCs but can also support applications that
require long-range communications, e.g., traffic
Applications in Vehicular Ad Hoc Networks
monitoring. An MIVC system requires a network
layer capable of multi-hop routing.
In RVC systems, all communications take place
between roadside infrastructure and vehicles.
Depending on the application, two different types
of infrastructure can be classified, sparse RVC
(SRVC) and ubiquitous RVC (URVC) systems.
SRVC systems are capable of supporting communication services at hot spots, for examples,
a busy intersection scheduling its traffic light,
a restaurant advertising its existence and prices,
and parking availability at an airport. An SRVC
system can be deployed gradually, thus not requiring substantial investments before any available
benefits. A URVC system is the holy grail of
vehicular communication in which providing
all roads with high-speed communication would
enable applications unavailable with any of the
other systems. Unfortunately, a URVC system may
require considerable investments for providing
full coverage of existing roadways, especially in
large countries (Sichitiu et al., 2008).
HVC systems are proposed for extending
the range of RVC systems. In HVC systems vehicles communicate with roadside infrastructure
even when they are not in direct wireless range
by using other vehicles as mobile routers. The
main advantage is that it requires less roadside
infrastructure. However, one disadvantage is that
network connectivity may not be guaranteed in
scenarios with low vehicle density.
The Federal Communications Commission
(FCC) has allocated spectrum for IVC and
similar applications (e.g., Wireless Access in
Vehicle Environment, WAVE). Governments and
prominent industrial corporations, such as Toyota,
BMW, and Daimler-Chrysler have launched
important projects for IVC communications.
Some notable projects, e.g., Advanced Driver
Assistance Systems (ADASE2), Crash Avoidance
Metrics Partnership (CAMP), Chauffeur in EU,
CarTALK2000, FleetNet, California Partners
for Advanced Transit and Highways (California
PATH), and DEMO 2000 by Japan Automobile
Research Institute (JSK) are a major step towards
the realization of Intelligent Transport Services
(ITS) (Taleb et al., 2007).
Dedicated short range communications
(DSRC) standard at 5.9 GHz band is projected to
support low-latency wireless data communications
between vehicles and from vehicles to roadside
units. The DSRC specification is meant to be an
extension of the IEEE 802.11 technology into the
outdoor high-speed vehicle environment. In fact,
the physical layer (PHY) of DSRC is adapted from
IEEE 802.11a PHY based on orthogonal frequency
division multiplex (OFDM) technology. Moreover, the multiple access control (MAC) layer of
DSRC is very similar to the IEEE 802.11 MAC
based on the carrier sense multiple access with
collision avoidance (CSMA/CA) protocol with
some minor modifications (Ryu et al., 2004).
MANETs are wireless multi-hop networks,
decentralized and self-organized without infrastructure. VANETs satisfy all these requirements,
and are a special class of MANETs. However, the
followings are several characteristics that differentiate between VANETs and MANETs (Sichitiu
et al., 2008) .
•
Applications: The most common assumption of MANET applications are identical
to those enabled by the Internet. In contrast, VANETs have completely different
applications to increase the safety and
comfortable trip. VANET applications include onboard active safety systems to assist drivers in avoiding collisions and to
coordinate among them at critical points
such as intersections and highway entries.
Safety systems may intelligently disseminate road information, such as incidents,
real-time traffic congestion, high-speed
tolling, or surface condition to vehicles
in the vicinity of the subjected sites. This
helps to avoid platoon vehicles and to accordingly improve the roads capacity. With
such active safety systems, the number of
231
Applications in Vehicular Ad Hoc Networks
•
•
•
•
car accidents and associated damage are
expected to be largely reduced.
Receiver: MANET applications require
point-to-point (unicast) with fixed addressing. The recipient of a message is another
node in the network specified by its IP address. However, VANET applications often
require dissemination of the messages to
many nodes (multicast) that satisfy some
geographical constraints and possibly other criteria (e.g., direction of movement).
The need for this addressing mode requires
a significantly different routing paradigm.
Rate of link changes: The nodes in
MANETs are assumed to have moderate
mobility. This assumption allows MANET
routing protocols to establish end-to-end
paths that are valid for a reasonable amount
of time and only occasionally need repairs.
In VANETs applications, it is shown that
due to the high degree of mobility of the
nodes involved, even multi-hop paths that
only use nodes moving in the same direction on a highway have a lifetime comparable to the time needed to discover the path.
Therefore, the communication of VANETs
has more challenge than that of MANETs.
Mobility model: In MANETs, the random
waypoint (RWP) is the most commonly
employed mobility model. However, for
VANETs, most existing literatures recognized that RWP would be a very poor approximation of real vehicular mobility; instead, detailed vehicular traffic simulators
are used.
Energy efficiency: While in MANETs a
significant body of literatures is concerned
with power-efficient protocols, VANETs
enjoys a practically unlimited power
supply.
In VANETs, the hardware available in each
vehicle is listed below.
232
•
•
•
•
•
A central processing unit (CPU) that implements the applications and communication
protocols;
A wireless transceiver that transmits and
receives data to/from the neighboring vehicles and roadside units;
A GPS receiver that provides relatively accurate positioning and time synchronization information;
Appropriate sensors to measure the various
parameters that have to be measured and
eventually transmitted;
An input/output interface that allows human interaction with the system.
applicaTions in VaneTs
Based on the different types of vehicular communication systems (e.g., IVC and RVC), the
telematics have five different classifications in
the applications shown in Figure 1 (Sichitiu et
al., 2008). The applications in VANETs consist of
the public safety application, traffic management
applications, traffic coordination and traffic assistance, traveler information support, and comfort
applications. The classifications of these applications are not meant to the overall applications in
VANETs. However, the adopted classification can
represent the greater part of the current general
applications in VANETs. The explanations about
the applications will be described as follows in
detail.
Public safety applications are very important
issue in the Telematics. Safety applications are
geared primarily toward avoiding accidents and
loss of life of the occupants of vehicles. Collision
warning systems have been proposed to reduce
the number of vehicle collisions in several scenarios.
On highways, frontal collisions with slow
moving (or stopped) vehicles are one of the most
common types of accidents, often with serious
consequences. A vehicle with its airbags deployed,
Applications in Vehicular Ad Hoc Networks
Figure 1. Telematics applications
or a stopped or rapidly decelerating vehicle can
transmit warning signals to all other approaching
vehicles (shown in Figure 2(a)). Intermediate
relays may be used to increase the dissemination
range of the warning beyond the direct transmission range.
At junctions, vehicles running red stop lights
often result in side crashes. If both vehicles to
be involved in the accident are equipped with
vehicular communication systems, such accidents
can be prevented (shown in Figure 2(b)).
A similar situation may occur with other types
of vehicles (e.g., trains). In some cases, if a collision is imminent, the system may be able to
prepare the vehicles for collision (inflate air bags,
tighten seat belts, etc.). Thus, safety applications
have obvious real-time constraints, as drivers
have to be notified before the information is no
longer useful. In terms of addressing, the destinations in these applications will not be individual
vehicles, but rather any relevant vehicle. The zone
of relevance (ZOR) (also known as the target
area) is determined by the particular application.
Figure 2. Safety applications
233
Applications in Vehicular Ad Hoc Networks
For example, an accident in the right lane of a
highway will only affect vehicles approaching the
accident from behind, while at an intersection the
vehicles with intersecting trajectories and speeds
over a threshold are relevant.
Traffic management applications are focused on improving traffic flow, thus reducing
both congestion as well as accidents resulting
from congestion, and reducing travel time. The
traffic management applications include the
traffic monitoring, traffic light scheduling, and
emergency vehicles.
Traffic monitoring can provide high-resolution
localized timely information regarding the traffic
for several miles around the current location of
the vehicle. For this application each vehicle in
the system will act as a sensor (determining its
current speed), as a relay (if the information is to
travel for more than the direct transmission range)
as well as a destination (using information from
the other vehicles in the system (shown in Figure
3(a))). The information can be used to simply
inform the driver or, in more complex systems, to
reroute, estimate the time to destination, or even
control the traffic by using adaptive speed limits,
ramp metering, and so on.
Emergency vehicles may notify the relevant
vehicles as well as equipped stop lights of their
Figure 3. Traffic management applications
234
presence and intended routes (shown in Figure
3(b)).
Traffic light scheduling can be significantly
improved by using an SRVC (Sparse Roadsideto-Vehicle Communication) system. Currently,
many traffic lights are scheduled either statically
or only considering limited information (e.g., by
sensing the presence or absence of a vehicle in front
of a traffic light). An SRVC system can provide
additional information, such as the length of the
queues at the traffic light as well as the number
of vehicles expected to arrive in the near future,
which can improve the efficiency of schedules.
Applications in this class generally do not
have stringent real-time requirements: the quality of the information degrades gracefully with
the increase of delay and packet loss. Similar to
the case of safety applications, the destinations
of the information are any vehicles in the ZOR.
For traffic monitoring applications the ZOR can
be several miles around the information source.
For traffic light scheduling, traffic lights being
approached are appropriate destinations.
Traffic coordination and traffic assistance
have been the main research topics of many IVC
projects. Platooning (i.e., forming tight columns
of vehicles closely following each other on highways) has the potential to radically increase the
capacity of existing highways. High-speed closed
Applications in Vehicular Ad Hoc Networks
loop control is of paramount importance for this
application (shown in Figure 4(a)). Passing and
lane change assistance may reduce or eliminate
risks during these maneuvers, since they are
often the source of serious accidents (shown in
Figure 4(b)).
Clearly these applications require close-range
IVC with tight real-time constraints and can
be implemented with either an SIVC (Sparse
Roadside-to-Vehicle Communication) or a URVC
(Ubiquitous Roadside-to-Vehicle Communication) system. Both systems can offer similar
real-time guarantees and delays if properly designed, although an SIVC system may have a
slight advantage as it faces reduced contention
and direct links. These applications also have addressing based on ZOR; for example, immediately
behind, in the right lane, or in the reverse direc-
tion. Penetration directly influences the usability
of these systems.
Traveler information support applications
provide updated local information, maps, and in
general messages of relevance limited in space
and/or time. These messages mainly focus on the
local information and road warnings.
Local information such as local updated maps,
the location of gas stations, parking areas, and
schedules of local museums can be downloaded
from selected infrastructure places or from other
“local” vehicles. Advertisements with, for example, gas or hamburger prices may be sent to
approaching vehicles (shown in Figure 5(a)).
Road warnings of many types (e.g., ice, oil,
or water on the road, low bridges, or bumps)
may easily be deployed by authorities simply by
dropping a beacon in the relevant area (shown in
Figure 5(b)).
Figure 4. Traffic coordination and traffic assistance
Figure 5. Traveler information support applications
235
Applications in Vehicular Ad Hoc Networks
Figure 6. Communicate with different targets
Only a few papers consider specific traveler
information support applications. All information
support applications require an SRVC system. IVC
systems may augment the service provided by the
SRVC, but cannot replace it. No special real-time
requirements are necessary, and the penetration
percentage has no impact on usability. A vehicle
equipped with a vehicle communication system
benefits from the applications independent of the
OBU penetration rate. The addressing is once
again based on relevance rather than individual
vehicle IDs.
The main focus of comfort applications is to
make travel more pleasant. This class of applications may be motivated by the desire of passengers
to communicate with either other vehicles or
ground-based destinations such as Internet hosts or
the public service telephone network (PSTN).
Targeted vehicular communications allow
localized communications (potentially multi-hop)
between two vehicles (shown in Figure 6(a)).
Voice, instant messaging, or similar communications may occur between the occupants of vehicle
caravans traveling together for long distances,
or between law enforcement vehicles and their
“victims.” Note that this application does not
scale to large network sizes.
Vehicle to land-based destination communications (shown in Figure 6(b)) is arguably a very
useful capability as it may enable an entire array
236
of applications, from email and media streaming
to Web browsing and voice over IP. Unfortunately,
land-based access requires a URVC system that
may be prohibitively expensive in the near future.
Finally, there are many other comfort applications. Tolls for roads and bridges can be collected
automatically. Many nonstandard systems exist
and work well. Parking payments can be made
promptly and conveniently. Repair and maintenance records can be recorded at the garages
performing them. Multimedia files such as DVDs,
music, news, audiobooks, pre-recorded shows can
be uploaded to the car’s entertainment system
while the car is in the garage.
TraFFic inFormaTion in VaneTs
According to the definition of Hudson Valley
Transportation Management Center (HVTMC)
(“Hudson Valley Transportation Management
Center (HVTMC),”), traffic information means
dynamic information concerning about traffic.
Thus, traffic information in VANETs means the
dynamic information obtained from the on-board
units in the vehicles. Compared to the travel information, like the maps of the streets or the maps
of the bus routes, traffic information in VANETs
is usually more immediate and local. As follow-
Applications in Vehicular Ad Hoc Networks
ing, we will introduce and discuss some reference
papers about the collections, presentations, and
applications of the data, such as immediate road
traffic information and navigation information
etc.
Figure 7. Relevance of spatial-temporal speed
surface street Traffic estimation
Average velocity is the most commonly used
parameter to show the traffic information, such as
the real-time traffic network systems of cities and
counties in Taiwan (“Real-Time Traffic Network
Systems of Cities and Counties in Taiwan,”), all
provide average velocity of road sections as an
immediate reference. And the literature “Surface
Street Traffic Estimation” (Noble et al., 2007)
provides a simple way to determine the current
road conditions by using data analysis through the
GPS and the mobile communication systems. The
approach is as follows: First of all, split the road
section into small segments, and drive a car passing
through the same route repeatedly to collect the
road information (record the relationship between
time and location). Secondly, update each GPS
track data to the central server, and use the spatialtemporal traffic status plot to describe the traffic
characteristics, and then obtained the temporal
velocity- the average speed of the journey and the
spatial velocity- the average speed of the section.
Thirdly, they use Quadrant Clustering to classify
the spatial-temporal traffic status plot to predict
the present traffic condition by the classification
of the data. Then present the traffic condition as
good, normal (spatially good but temporally bad, or
temporally good but spatially bad) and poor. And
then transmit the information acquired through the
internet. (Figure 7) Finally, transmit the packages
through the internet. This method presents the road
traffic situation with the effective spatial-temporal
plot, taking the waiting time of traffic lights and
intersections into account.
estimating Velocity Fields
on a Freeway from lowresolution Videos
This is an approach using low-resolution video
to estimate the velocity fields (Rice et al., 2006).
Nowadays, there are many image processing
techniques used in traffic surveillance (Kastinaki
et al., 2003) . However this algorithm is not only
used to estimate the speed for a single vehicle,
nor to obtain the estimated value of the derivative
through the intensity of each point, but rather to
find out the most matching value by calculating
the “intensity.” It is divided into two parts as
intensity profiles and speed estimation. The first
part, intensity profiles, is to choose four related
fixed objects from the video (Figure 14.8) between
the time interval [t – τ t + τ,], then mark them
out with the frame, next find the best matching
pattern in each frame, strengthen its intensity
and use the centric coordinates to compute the
projection matrix. Repeat the process. After some
time, the intensity flow can be depicted so as to
know the traffic conditions. In the second part,
speed estimation, the basic idea is that the pattern
of the intensity can present the speed of vehicles
237
Applications in Vehicular Ad Hoc Networks
Figure 8. Filtered image and the corresponding intensity profile
in the region. So the same pattern will be found
at the next point in a short period. The processes
are as follows: Fix the chosen frame, find out the
intensify relationship d() between time instant t τk and t + τk, where located x - d and x + d. Then
take Bayesian point to estimate the velocity and
get the global vehicles’ velocity.
local density estimation
and dynamic Transmissionrange assignment (dTra) in
Vehicular ad hoc networks
In addition to speed, density is also a common
parameter of traffic information. Here we will
introduce a method, DTRA, in vehicular network
which can estimate local density and dynamically
adjust transmission radius without other vehicles
or road side unit (RSU) (Artimy, 2007). According to the definition of traffic flow, the number
of vehicles passing through a fixed-point per
unit time could be computed as velocity (driving
distance per unit time) product density (number
of vehicles per unit distance). But as shown in
Figure 14.9, traffic flow can not always reflect
the traffic condition, such as conjunction or free
238
flow will show up at the same traffic flow. Thus,
this paper provides a algorithm which only uses
a single vehicle to estimate local density, and
determine whether it is the case of congestion,
then apply the result on the transmission range
dynamically to meet the need of maintaining the
high-connectivity of the network. Based on the
two-fluid model (Robert et al., 1979), compute
fraction (f) = the stopping time of test vehicle (Ts)
divide the traveling time of the tested vehicle (Tt).
And by NaSch-S2S model (Jost et al., 2003), they
-1
h +1
é
ù
ê (1 - Ts / Tt )
ú
+ 1ú of
get the density K = ê
ê
ú
l¢
êë
úû
neighbor vehicles around, η and λ are given as the
levels of the estimated traffic condition. At least,
although the larger the radius of the inter-vehicle
transmission range, the easier will be the communication; but on the same time, it will be easier to
be intterrupted. Thus, the area of communiction
can be adjusted according to the dynamic traffic
condition mentioned above, reducing the radius
of communication in high intensity condition and
vice versa, so that highly connected network and
data transmission rate can be achieved.
Applications in Vehicular Ad Hoc Networks
evaluation of a neighbor-based
Vehicle density estimation scheme
Most current methods about collecting and
processing traffic information are still based
on centralized communication model. It will be
delivered to every vehicle after the processing of
the central processing unit. However, this article
is collected to predict the density of the vehicles
on the roads based on the inter-vehicle communications (Panichpapibo et al., 2008). It takes two
models to test, One-hop-Neifhbor Scheme and
Two-hop-Neighbor-Scheme. The processes are
as follows: (1) in the case of one-hop senario,
vehicle launched to send “HELLO” packet to the
vehicles which are in the communication range.
And other vehicles send a message back to the
collecting vehicle on receiving the packet. If the
inter-vehicle space shows the exponential distribution, then the number of vehicles will show the
poisson distribution (Wisitpongphan et al., 2007).
At this time, the maximum probability of local
density is the best expression to the global density
estimation ( r̂ * ) equals to the numbers of neighbor
vehicles (k) divide the communication radius of
vehicles (z). (2) In two-hop situation, vehicle V
broadcasts inquiring packets and receive responses
from the vehicles within the communication range.
Then send the packet to the furthest vehicle U
in its communication range, and U become the
probe vehicle doing the same work as vehicle V
in the one-hop situation, collect the data along the
direction and return the result back to vehicle V,
finally the two-hop result is gotten. Evaluating the
inaccuracy between estimation and actual density
by MAE (mean absolute error), the authors find
that the two-hop estimation is the better one. And
the inaccuracy increases if the density is too low.
The reason may due to the lack of vehicles in the
communication range. In the end, the author suggests three ways to improve the estimation of the
density. Firstly, enlarge the communication range
to avoid the shortage of vehicles; secondly, rise
the hops up; last and the most effect, use more
samples for evaluation.
estimating Travel Times and
Vehicle Trajectories on Freeways
using dual loop detectors
There are many physical methods to depict traffic jams before 2002 (Nagatani, 2002). However,
someone did not satisfied in using velocity and
density as the only factor in the traffic information. This article provides a method to estimate
travel time by using Dual Loop Detetor. The
author uses the Dual Loop Detetor to record the
speed of each vehicle and its arriving time at the
Figure 9. Flow-density
239
Applications in Vehicular Ad Hoc Networks
the certain point where the detector is set. Then
draw chords to represent the directions and locations for vehicles. Because there may be free flow
or conjunction at the same time, the situation of
conjunction into consideration need to be taken
(Figure 9), using the slop of conjunction uc to
cut off the chords (Figure 10), then sum up the
cutting chords to get the estimation of vehicles’
path and travel time.
As the traffic information develops rapidly,
the traffic information in VANETs is bound to
become more important. Besides all the traffic
informations mentioned above, which includes
the vehicle speed, vehicle density, and travel
time, there are still other traffic information; for
example, the instant safety information. But no
matter what kind of information is given, the most
important aim is to let the users to arrive at their
destinations safely and swiftly.
Vehicle naVigaTion Technology
In recent years, the expansion of cities scale and
urban population increase as well as the development of automobile industry. Urban traffic problem such as traffic congestion, traffic accidents,
transport environmental degradation, and energy
shortages has become the world facing common
problems. According to statistics, road congestion
has caused a great amount of direct or indirect
economic losses. Thus, in order to improve efficiency and security of transportation, every
country has developed vehicle navigation and
positioning system one after another. To solve the
traffic congestion in a traditional way is to expand
the roads or to construct new roads. But with the
living environment nowadays, the urban population decreasing, the use of traditional methods
is difficult to solve traffic congestion problems.
Undoubtedly, the modern technology comes with
the tide of fashion to solve the traffic problem
effectively. It integrates computer technology,
information technology, data communications
240
Figure 10. Travel time estimation “a” is a chord
transmission technology, automation technology,
artificial intelligence, and electronic technology
etc. And establish a large-scale and all-round play
transportation management system which is on
time, accurate, and efficient.
14.4.1 Vehicle routing
navigation system
Navigation system is usually defined as the instrument which can be used as guidance for routing.
From the early compass even later paper maps, the
recent development of handheld GPS map navigation, on-board navigation systems (mainly can be
divided into two types of portable and embedded),
as well as PDA and Smartphone combined with
navigation systems. Vehicle navigation system
directs vehicle along a path from start position to
the destination in the road network. The system
attempts to generate an optimal path of guidance,
almost all the systems try to find the shortest travel
time for navigation. In other words, it attempts
to search for the fastest route in the road network
for guidance. The key influencing factors of the
vehicle navigation system architecture are vehicle
localization technology and the integrity of the
electronic map.
Global Positioning System is a widely used
satellite localization system. There are 24 satellites
distributed over the Earth. The satellite uses basic
triangulation positioning principle, combined with
the development of satellite and communication
technology to GPS receiver to receive GPS satellite
signals by the wave. It can accurately calculate
Applications in Vehicular Ad Hoc Networks
the time, position, and velocity of the area where
are measured on the surface of the Earth at anytime and anywhere. Its advantages are global,
high precision, real-time positioning speed, can
be used for many users simultaneously, and free
of charge. And the disadvantage is that it can not
receive signals due to the signals obscured in
some areas, such as behind buildings or tunnels,
navigation signal interruption, therefore, must be
again orientation.
The components of vehicle navigation systems
requirement: (1) positioning accuracy, combining different navigation technology to improve
positioning accuracy. (2) Complete the correct
geographic information systems, to update map
data and road network instantly, and continued
to increase the road property and other relevant
information. (3) Friendly user interface. (4) Easily
to operate, concern about the development of voice
recognition capabilities, to provide voice-guided
Service. (5) Price considerations.
Information displayed can be divided into two
categories, (1) Driving geographic information: to
provide users with a wealth of traffic information,
such as gas stations, parking area, restaurants,
amusement parks, financial institutions etc. Most
of the current systems are well build, and the content of the database is increase continuing. And
the parts of the systems also provide users with
custom landmark features. (2) Driving guidance
information: to get the real-time traffic condition
information, such as traffic congestions, traffic accidents, construction or temporary traffic control
measures etc from communications technology.
Users can avoid road congestion or accident location timely, and select one alternative path for
their route planning.
Based on the above classification, comment,
and comparison of vehicle navigation system
today (Schmitt et al., 2006), it will be divided
into four main categories investigate separately
for static and dynamic systems, deterministic and
stochastic system, reactive and predictive system,
as well as centralized and decentralized system
into comparison.
static vs. dynamic system
One important distinction of routing guidance
system is whether the system uses a static or
a dynamic approach. This characteristic of the
system dictates overall operation, no matter what
vehicles receive and react to update path information during roadway propagation.
A static routing algorithm determines and maintains a path for a user from the source to destination
regardless of changing the traffic characteristics in
time. In this system, vehicles already on the road
with assigned paths do not react to any real-time
network changes. Clearly this system represents an
offline routing approach. Several papers investigate
the idea of static path route selection such as in
(Dijkstra, 1959; Dreyfus, 1969).
On the other hand, dynamic path planning
incorporates real-time traffic information and
reacts to the changing conditions of the roadway.
This allows updating of the path of a vehicle as
the user proceeds to the destingtion. This type
of routing provides a more robust solution than
static routing for congestion alleviation. The differences between static and dynamic navigation
system are system design and requirements. Static
routing guidance systems require less roadway
infrastructure and computing power, the system
is vulnerable to events and congestion that occurs
on the roadway. Dynamic routing guidance is a
robust operation during events and congestion, but
the system required more computing power and
roadway infrastructure. Several papers investigate
the idea of dynamic path route selection such as
in (Hall, 1986; Karimi et al., 2004).
deterministic vs. stochastic system
The distinction between these two systems is
mainly due to treating the cost of traveling from the
241
Applications in Vehicular Ad Hoc Networks
origin to destination as a deterministic or stochastic
cost. This cost is usually the travel time.
Deterministic routing systems assume deterministic parameters for roadway links without
regard to any random nature of traffic. These
parameters may be updated frequently in time.
The most commonly used metric for deterministic
routing is the distance traversed by a vehicle along
the route. Calculation of the path using a deterministic approach would yield the total distance.
The total travel time is then calculated using mean
vehicle speed without considering the influence
of any variation due to the stochastic nature of
the traffic. Several papers investigate the idea of
deterministic path of routing selection such as in
(Friesz et al., 1989; Zhan, 1997).
Stochastic routing uses a more complex approach to vehicle routing in which the random
nature of the traffic condition is also considered.
In this approach, traffic along the road may be
considered either as a stationary or non-stationary
stochastic variable. Stationary stochastic routing
guides vehicles along a path determined using only
mathematical expectation of conditions deemed
imporant by the algorithm. These conditions are
assumed to be time invariant; therefore, they are
not changing with time. In most cases of vehicle
routing the mean and variance of travel time are
used. Several papers investigate the idea of stationary stochastic path route selection such as in
(Bertsekas et al, 1991; Alexopoulos, 1997). Nonstationary stochastic routing takes into account the
changing characteristics of time with respect to the
traffic condition. These changing conditions are
familiar with mean travel time and the variance
of the function which is time in one day. Several
papers investigate the idea of stationary stochastic
path route selection such as in (Seongmoon et al.,
2005; Fu, 2001).
Deterministic systems offer the simplest solutions while stochastic non-stationary solutions
offers the most robust answer to the problem
capturing the charateristics of traffic congestion,
242
at the cost of computational complexity. Stochastic
routing systems clearly require a greater amount
of data for routing guidance. Thus, the data requirement, especially historical data, increases
computational time and data storage costs.
reactive vs. predictive system
This classification is very important. It controls
the complexity, robustness, and vulnerability of
events. The main differences between the two
systems are their complexity and reliability.
Reactive navigation routing is also a kind of
feedback routing, which based on the recent situation of the travel network. The routing system
determines the paths by real-time traffic information, but will not predict the coming situation.
This system will provide the best route, which
having least travel time, to the users. The system
has a less complexity, but a greater vulnerability
because of road congestion and unexpected events.
Several papers investigate the idea of reactive
path route selection such as in (Pavlis et al., 1999;
Deflorio, 2003).
Predictability routing of navigation can estimate the routes. It is based on the prediction
models from the predicted situations of the future.
The Predictive System using a repeated model of
traffic information and useful historic information
to predict the coming situations, which is based
on linking or the region of network. The system
will provide the best route with least travel time
according to the estimated traffic conditions.
Several papers investigate the idea of predictive
path route selection such as in (Messmer et al.,
1990; Kotsialos et al., 2002).
Although the reactivity and the predictability
routing are working in different ways, they both
provide the best route to the users. We can say
that the reactive system can be executed in the
environment of lower cost and less complexity,
and the prediction system will be able to avoid
the generation of traffic congestion.
Applications in Vehicular Ad Hoc Networks
centralized vs. decentralized system
Routing navigation can be dominated by a centralized system and monitoring dynamics of the
entire network, or optimize the performance of a
single user himself.
Centralized system is focus on providing
routing selections, and the distributed system
provides personalized real-time road information selections. Centralized routing system uses
a central unit to provide the routing selection.
The system uses a predictive or reactive routing
to guide vehicles for the best route to the destination in the network. Centralized routing is more
complex than distributed system. This method
provides more robust and reliable system to all
hierarchies of the Internet. Centralized system will
provide better network capacity to the network,
the best of the road. It will calculate and deal with
the road side infrastructures. Another concerned
issue of the centralized system is the compliance
rate of Internet users. If the instructions do not
be followed by the drivers, the effectiveness of
navigation systems will reduce while compliance
rate decreasing. Several papers investigate the
idea of centralized path route selection such as in
(Yamashita et al., 2004 ; Tomkewitsch, 1991).
Distributed routing navigation system required
for individual users to determine all the routes
of navigation, and each one can operate by the
machine or man-made to decide the route of
navigation. Road infrastructures can not control
the selected routes of users, but it can provide
current information and the parameters which
has predicted of the network. The system may
not be robust on the Internet hierarchy, because
the optimization is for the situation of each user
rather than to whole network. The critical difference of centralized and distributed routing navigation system is that the computation for users
or infrastructures. Several papers investigate the
idea of decentralized path route selection such
as in (Wunderlich et al., 2000 ; Minciardi et al.,
2001).
In order to expand the commercialization of the
product and to accelerate it into human life from
technology products converted to daily necessities,
related industries should study in market preference actively when technology developed.
daTa disseminaTion in VaneTs
data dissemination
Data dissemination concerns about the transmission of information to intended receivers with
certain design objectives. The design objectives
that considered include low delay, high reliability,
low memory occupancy, and low message passing
overhead (Nadeem et al., 2006).
Four services that have immediate application
are unicast, multicast, anycast and scan. “Unicast
with precise location” means a message should be
delivered to node i in location l before time t . “Unicast with approximate location” means sending a
message to node i before time t1 while that node
was last known to be at location l with mobility
m at time t2. “Multicast” means disseminating a
message to all receivers in region r before time t.
“Anycast” means disseminating a message to one
among a set of possible destinations in region r
before time t. “Scan” is to have a message traverse
region r once before time t.
Data delivery mechanisms define the rules
for moving information through the network, for
example “Node centric”, “Location centric”, “Opportunistic forwarding”, and “Trajectory based
forwarding” .The “Node centric” approach specifies the routing path as a sequence of connected
nodes. However the high vehicle mobility in V2V
networks will quickly render inter-node connections invalid. The “Location centric” approach
decouples the routing path from the intermediate
nodes and the message is forwarded to the next
hop(s) closer to the destination geographically.
If a hole is encountered, efforts are made to find
a path around it. “Opportunistic forwarding,” as
243
Applications in Vehicular Ad Hoc Networks
suggested in, targets networks where an end-toend path cannot be assumed to exist. Messages
are stored and forwarded as opportunities present
themselves. When a message is forwarded to another node, a copy may remain with the original
and be forwarded again later to improve reliability.
“Trajectory based forwarding” directs messages
along predefined trajectories. It was presented to
work well in a dense network. Despite their sparseness, V2V networks should be a natural application
of trajectory based forwarding because messages
are moving along the “road” graph.
mobility-centric data dissemination
algorithm for Vehicular network
MDDV is a “mobility centric” approach that
combines opportunistic forwarding, geographical forwarding, and trajectory based forwarding.
A forwarding trajectory is specified extending
from the source to the destination (trajectory
base forwarding), along which a message will be
moved geographically closer to the destination
(geographical forwarding). With an opportunistic
forwarding approach, rules must be defined to
determine which is eligible to forward a message,
when a copy of the message should be passed to
another vehicle, and when a vehicle should hold/
drop a message. They motivate the design by reference to a test scenario, geographical-temporal
multicast. Geographical-temporal multicast is
formally defined as: deliver a message to all
vehicles in/entering region t before time t while
the data source s is outside of r.
Assume that a vehicle knows the road topology through a digital map and its own location in
the road network via a GPS device. And suppose
vehicles know the existence of their neighbors
through some link level mechanism. But they do
not assume a vehicle knows the location of its
neighbors. The message dissemination information, e.g., source id, source location, generation
time, destination region, expiration time and
244
forwarding trajectory, etc., is specified by the data
source and is placed in the message header.
A forwarding trajectory is specified as a path
extending from the source to the destination region. One of the MDDV objectives is to deliver
messages to their destination regions as soon as
possible. A naive approach would be taking the
path with the shortest distance from the source
to the destination region. However, information
propagation along a road depends largely on the
vehicle traffic on it. A short road distance may not
translate to short information propagation delay.
High vehicle density often leads to fast information propagation. But vehicle traffic conditions
change over time and vary from one road segment
to another. Here, the authors only explore the
static road network topology information since
road networks are typically engineered to match
transportation demands. They define d(A,B) as the
“Dissemination length” of a road segment from
road node A to B, which takes into account the
static road information.
d(A,B) = r(A,B) (m-(m-1)(ip+cjp)), 0< c <
1
where, r(A,B): road length from A to B
i: number of lanes from A to B
j: number of lanes from B to A
But the traffic in the opposite direction of the
desired information flow is less helpful than the
traffic in the same direction of the information flow.
Constant c is used to discount the opposite traffic
flow. In the reference (Wu, Fujimoto, Guensler,
& Hunter, 2004), when i =1, j =0, d(A,B)=r(A,B),
then set m=5, p=0.1, c=0.005.
The dissemination process consists of two
phases: the forwarding phase and propagation
phase. In the forwarding phase, the message is
forwarded along the forwarding trajectory to the
destination region. When the message reaches the
Applications in Vehicular Ad Hoc Networks
destination region, the propagation phase runs and
the message is propagated to every vehicle in an
area centered on the destination region before the
message time terminated. During the forwarding
phase, the authors call the “message head” that
the message holder closest to the destination region along the forwarding trajectory. The vehicle
taking the role of the message head may change
over time as the message propagates. With perfect
knowledge, every vehicle knows the message head
vehicle in real time. When the message head tries
to pass the message to other vehicles that may
be closer to the destination region. During the
propagation phase the message is propagated to
vehicles without the message in the specified area.
With the assumption that vehicles do not know the
location of others, this is difficult to do.
In both cases, the message is lost. To overcome
this problem, they allow a group of vehicles near
the real message head to actively forward the message instead of the message head vehicle only.
The message head pair, the message head
location and its generation time, is contained to
the message. The “message head pair” provides
the more correct knowledge of a message holder
concerning the message head location. The actual
message head can move either toward or away
from the destination region along the forwarding
trajectory within a short period of time. But it
should move toward the destination region in the
long term. For simplicity, the authors require that
the message head location installed by a message
holder never moves backward, which means that
a message holder can only install a new message
head location closer to the destination region
than the one currently installed. To reduce the
publication and dissemination of false information, only some vehicles are allowed to generate
the message head pair. A message holder may
assume either one of two roles: the message head
candidate and non-message head candidate. Only
a message head candidate can actively publish its
current location as the message head location, and
a non-message head candidate can only learn from
received messages.
There are rules for a message holder to transit
between a message head candidate and nonmessage head candidate. Suppose the current
time is tc, a vehicle’s current location is lc, and
a vehicle’s installed message head pair is l, t
where l is the message head location and t is the
generation time.
1.
2.
Non-message head candidate ⇒ message
head candidate: During the forwarding
phase, one important observation is that a
vehicle passing its installed message location
in a shorter period after the generation time is
more likely to be the message head because
after a long period the message may have
already been forwarded far away toward the
destination region along the trajectory. Thus,
they stipulate that a non-message head candidate becomes a message head candidate if
it passes its installed message head location
toward the destination region before t + T1,
where T1 is a system parameter. During the
propagation phase, message holders moving
into the destination region assume the role
of the message head candidate.
Message head candidate ⇒ non-message
head candidate: During the forwarding
phase, there are two transition rules:
1. If the message head candidate leaves
the trajectory or moves away from the
destination region along the trajectory, it becomes a non-message head
candidate;
2. If a message head candidate moves
toward the destination region along the
trajectory, it stays as a message head
candidate until it receives the same
message with another message head
pair l n , tn where ln is closer to the
destination region than lc.
245
Applications in Vehicular Ad Hoc Networks
During the propagation phase, a message head
candidate becomes a non-message head candidate
once it moves out of the destination region.
A message holder updates its installed message
head pair with the information from received messages. Two messages differing only in the message
head pair are two versions of the same message.
One message version with message head pair
li , ti is said to be newer than another message
version with message head pair l j , t j
1.
2.
li is closer to the destination region than lj
li = lj but ti > tj
Data exchange can be triggered by several
types of events. In MDDV, data exchange is triggered by: new messages, newer message versions
or older message versions are received, or new
neighbors appear. Transmissions triggered by
new messages or newer message versions serve
to quickly propagate messages or dissemination
status. Transmissions triggered by older message
versions can help eliminate false/obsolete information. This scheme has both the advantages of fast
delivery and high delivery reliability. It is called
the “full protocol.”
The data exchange algorithm is defined as:
1.
246
Forwarding phase: A message holder can
be either one of following dissemination
states: the active state, the passive state,
and not eligible to transmit at all. A message holder in the active state runs the full
protocol to actively propagate the message
while a message holder in the passive state
only transmits the message if it hears some
older message version. The active propagation can help populate the message, move
the message closer to the destination region
or update dissemination status. The passive
updating serves to eliminate false/obsolete
information only. In the active state, tc < t +
T2, and lc between L2 with l. In the passive
2.
state, tc < t + T3, and lc between L3 with l.
T2, T3, L2, L3 are system parameters and T2
< T3, L2 < L3.
Propagation phase: A message holder can
be either in the active state or not eligible to
transmit. A message holder is in the active
state if tc < t + T2 and lc is within the distance
L2 from l.
An opportunistic forwarding mechanism must
determine when to store/drop a message. The
design decision can affect delivery reliability,
memory usage and message overhead. The decision to store/drop messages can be based on a
vehicle’s knowledge of its future movement trajectory. For example, assume vehicles are aware
of its own near future movement trajectory, a
message holder may decide to drop a message
if it knows that continually holding the message
can no longer contribute to suppress unnecessary message transmissions based on its future
movement trajectory. In MDDV every vehicle
stores whatever it overhears since this is almost
free except occupying memory buffers. A vehicle
drops a message when the vehicle leaves the passive state during the forwarding phase, leaves the
active state during the propagation phase or the
message expiration time elapses.
concept of replication
In the Intelligent Transportation System (ITS), the
car to car wireless network and car’s communication to the infrastructure (C2X communication)
have been given high priority recently. This trend
is corresponding to use basis of the C2X active
safety applications to reduce the traffic accident
or other seriously expected.
The networks constructed by C2X is called
“Vehicular Ad Hoc Networks (VANETS)”, it
runs distributed approach and does not depend on
the existing infrastructure to operate. Because of
the C2X node is generally moving, so the whole
Applications in Vehicular Ad Hoc Networks
network is divided by a number of Ad Hoc network composed.
Due to the region information providing an
appropriate way to describe that region, its applications have various C2X’s characteristics.
For example, in the case of traffic jam alert, the
main of provision will directly affect the situation of information to the vehicles, as vehicles
have nearly the same lane. Other major factors
include the communication between vehicles
and infrastructure. To imagine a case, if the traffic light can broadcast the current signal to the
nearest car. In this case where the vehicles close
to the traffic signal, it can specify the affected
roads and driving directions. However, this assignment is hard to achieve in the reality traffic
situation, because the moving nodes may already
get messages in hundred meters away and roads
are generally not linear. Therefore, to estimate the
information received by vehicles is a challenging
problem. This article introduce about how to deal
with the roads affected that allow changing and
ensure the problem that vehicles can receive the
relevant information.
replication concept of
regional road network
The approaches in real traffic environment describing the region are often unrealistic, because
it ignore the specific situation of the driving
environment. In the affected region may be more
complicated to operate and not at all the nodes in
this area will participate in. In fact, the relationship
about the car direction is an important problem.
The issue of concept is to use some of the challenges faced the basic position of a temporary
mechanism to change the essential part of the
street. This means that each vehicle contains C2X
are required a wireless communication components and similar Global Position System (GPS)
location systems. However, not every vehicle
requires Global Position System.
This method keeps storing their current and
recent location information in a period of time.
Therefore vehicle can accurate to provide their
tracking over the past. It can be every kind of
straight-line (ex: driveway) or curved-line (ex:
driveway exit or highway). If the slippery road
warning occurs, it is necessary to send the warning message to the vehicle. Thus, the position
information of that area must be stored actually.
The saving points are probably in hundred meters
away. All settings can be illustrated that greatly
reduce digital map by the regional road network
in the travel path of vehicles to access. To decide
the location of information storage and the use of
the map are very easy problems, because most of
the locations are dependent on the technology of
current trends (Roessler et al., 2006).
Therefore, it contains the following features:
•
•
Form of the Roads: The form of different
roads will be different number of supporting points. If there is lots of curve in the
road, it is necessary to rebuild the storage
location information. Otherwise, it only
needs two points of information while the
road is straight.
Velocity of the Vehicle: When vehicle
moves with high speed in a short time interval, it generally store high change location information.
To go along with the interpolation points,
the width of the addressing region (corridor), is
needed. This width can be equal to the whole set
of supporting points in order to reduce the amount
of data. However, it might also be necessary to
specify different width parameters in case of
a complicated road form. Figure 11 shows the
example that is from X1/Y1,…,Xn / Yn of supporting points.
It can be found that the distance between two
points are different from the whole addressing
region. To collect this kind of additional information from supporting points, i.e. the expected
247
Applications in Vehicular Ad Hoc Networks
Figure 11. Example for concept of replication
information of driving directions which is form the
addressing area linked to a dedicated road section.
This new method includes several advantages that
are summarized below:
•
•
•
•
248
Low Basic Hardware Necessary: Whole
information needed like current position,
driving direction and time can be got from
a basic positioning system. However, the
memory demand can be constraint by limitation of the maximum number of cached
position data.
Simple Relevance Evaluation: Using
the received information vehicle to make
a first evaluation of the relationship of the
information even if they are not equipped
with a navigation system.
Scalability: There are several method
to improve. For example, if a vehicle is
equipped a navigation system, it may also
solve the problem that address streets were
not on its recent route. But it might also be
affected.
Flexible: This approach can apply to any
mobile and fixed nodes. If an immobile
station like a traffic sign is the sender, the
position information may alternatively be
hard-coded in the device.
As mentioned above, the addressing approach
is not restricted to the vehicle to vehicle scenario
that has been used to describe the technique. It can
be further applied in different C2X-applications
like the communication between a car and a traffic signal system.
reFerences
Alexopoulos, C. (1997). State Space Partitioning
Methods for Stochastic Shortest Path Problems.
Networks, 1(30), 9–21. doi:10.1002/(SICI)10970037(199708)30:1<9::AID-NET2>3.0.CO;2-H
Artimy, M. (2007). Local Density Estimation and
Dynamic Transmission-Range Assignment in
Vehicular Ad hoc Networks. IEEE Transactions
on ITS, 18(3), 400–412.
Applications in Vehicular Ad Hoc Networks
Bertsekas, D. P., & Tsitsiklis, J. N. (1991). An
Analysis of Stochastic Shortest Path Problems.
Mathematics of Operations Research, 16(3),
580–595. doi:10.1287/moor.16.3.580
Deflorio, F. P. (2003). Evaluation of a reactive
dynamic route guidance strategy. Journal of the
Transportation Research Board Transportation,
11(5), 375–388.
Dijkstra, E. W. (1959). A note on two problems in
connection with graphs. Nuerische Mathematik,
1, 269–271. doi:10.1007/BF01386390
Dreyfus, S. E. (1969). An Appraisal of Some
Shortest Path Algorithms. Operations Research,
17, 395–412. doi:10.1287/opre.17.3.395
Friesz, T. L., Luque, J., Tobin, R. L., & ByungWook, W. (1989). Dynamic network traffic assignment considered as a continuous time optimal
control problem. Operations Research, 37(6),
893–901. doi:10.1287/opre.37.6.893
Fu, L. (2001). Adaptive Routing Algorithm for
In-Vehicle Route Guidance Systems with RealTime Information. Transportation Research Part
B: Methodological, 35(8), 749–765. doi:10.1016/
S0191-2615(00)00019-9
Hall, R. (1986). The Fastest Path through a
Network with Random Time- Dependent Travel
Time. Transportation Science, 20(3), 182–188.
doi:10.1287/trsc.20.3.182
Hudson Valley Transportation Management Center (HVTMC) (n.d.). Retrieved from http://www.
hudsonvalleytraveler.com/Glossary.html
Jost, D., & Nagel, K. (2003). Probabilistic traffic flow breakdown in stochastic car following
models. Transportation Research Record, 1852,
152–158. doi:10.3141/1852-19
Karimi, A., Hegyi, A., Schutter, B. D., Hellendoorn, J., & Middelham, F. (2004, Oct.).
Integrated model predictive control of dynamic
route guidance information systems and ramp
metering. Paper presented at the Proceedings
of the 7th International IEEE Conference on
Intelligent Transportation Systems (ITSC 2004),
Washington, DC.
Kastinaki, V., Zervakis, V., & Kalaitzakis, K.
(2003). A survey of video processing techniques
for traffic applications. Image and Vision Computing, 21(4), 359–381. doi:10.1016/S02628856(03)00004-0
Kotsialos, A., Papageorgiou, M., Diakaki, C.,
Pavlis, Y., & Middelham, F. (2002). Traffic flow
modeling of large-scale motorway networks using the macroscopic modeling tool METANET.
Journal of IEEE Transaction on Intelligent Transportation Systems, 3(4), 282–292. doi:10.1109/
TITS.2002.806804
Messmer, & Papageorgiou, M. (1990). METANET: A macroscopic simulation program for motorway networks. Journal of Traffic Engineering
& Control, 31(8-9), 466-470.
Minciardi, R., & Gaetani, F. (2001). A decentralized optimal control scheme for route guidance
in urban road networks. Paper presented at the
Proceeding of IEEE Intelligent Transportation
Systems, Oakland, CA.
Nadeem, T., Shankarand, P., & Iftode, L. (2006,
July). A comparative study of data dissemination
models for vanets. Paper presented at the Proceeding of 3rd Annual International Conference
on Mobile and Ubiquitous Systems (MOBIQUITOUS), San Jose, CA.
Nagatani, T. (2002). The physics of traffic jams.
Reports on Progress in Physics, 65(9), 1331–1386.
doi:10.1088/0034-4885/65/9/203
249
Applications in Vehicular Ad Hoc Networks
Noble, B., Yoon, J., & Liu, M. (2007, June 11-14).
Surface Street Traffic Estimation. Paper presented
at the Proceedings of International conference on
Mobile systems, San Juan, Puerto Rico.
Panichpapibo, S., & Pattara-atikom, W. (2008,
Oct.). Evaluation of a neighbor-based vehicle
density estimation scheme. Paper presented at
the ITST 2008. 8th International Conference,
Phuket.
Pavlis, Y., & Papageorgiou, M. (1999). Simple Decentralized Feedback Strategies for Route Guidance in Traffic Networks. Transportation Science,
33(3), 264–278. doi:10.1287/trsc.33.3.264
Real-Time Traffic Network Systems of Cities and
Counties in Taiwan. (n.d.). Retrieved from http://
www.e-traffic.com.tw
Rice, J., & Cho, Y. (2006). Estimating Velocity Fields on a Freeway From Low-Resolution
Videos. IEEE Transactions on Intelligent Transportation Systems, 7(4), 463–469. doi:10.1109/
TITS.2006.883934
Robert, H., & Ilya, P. (1979). A Two-Fluid Approach to Town Traffic. Science, 204(4389),
148–151. doi:10.1126/science.204.4389.148
Robinson, C. L., Caveney, D., Laberteaux, K.,
& Caminiti, L. (2006, September 29). Efficient
Coordination and Transmission of Data for Cooperative Vehicular Safety Applications. Paper
presented at the Proceedings of the 3rd international workshop on Vehicular ad hoc networks,
Los Angeles, California, USA.
Roessler, B., & Bruns, C. (2006, Mar.). Replication
of Local Road Networks for Regional Information
Dissemination in VANETS. Paper presented at the
Proceedings of the 3rd Workshop on positioning,
Navigation And Communication (WPNC’06),
University of Hannover, Germany.
250
Ryu, B., Yeung, G., Krishnan, H., Yin, J., ElBatt,
T., Habermas, S., et al. (2004). Performance Evaluation of Safety Applications over DSRC Vehicular
Ad Hoc Networks. Paper presented at the Proceedings of the 1st ACM international workshop on
Vehicular ad hoc networks, Philadelphia, PA.
Schmitt, E. J., & Jula, H. (2006, Sep.). Vehicle
Route Guidance Systems: classification and
Comparison. Paper presented at the Proceedings
of the IEEE Intelligent Transportation Systems
Conference (ITSC2006), Toronto.
Seongmoon, K., & Lewis, M. E., & III, C. C. W.
(2005). Optimal vehicle routing with real-time
traffic information. IEEE Transactions on Intelligent Transportation Systems, 6(2), 178–188.
doi:10.1109/TITS.2005.848362
Sichitiu, M. L., & Kihl, M. (2008). Inter-Vehicle
Communication Systems: A Survey. IEEE Communications Surveys & Tutorials, 10(2), 88–105.
doi:10.1109/COMST.2008.4564481
Taleb, T., Sakhaee, E., Jamalipour, A., Hashimoto,
K., Kato, N., & Nemoto, Y. (2007). A Stable Routing Protocol to Support ITS Services in VANET
Networks. IEEE Transactions on Vehicular
Technology, 56(6), 3337–3347. doi:10.1109/
TVT.2007.906873
Tomkewitsch, R. v. (1991). Dynamic route
guidance and interactive transport management
with ALI-SCOUT. Journal of IEEE Transactions on Vehicular Technology, 40(1), 45–50.
doi:10.1109/25.69971
Wisitpongphan, N., Bai, F., Mudalige, P., Sadekar,
V., & Tonguz, O. (2007). Routing in sparse vehicular ad hoc wireless networks. IEEE Journal
on Selected Areas in Communications, 25(8),
1538–1556. doi:10.1109/JSAC.2007.071005
Applications in Vehicular Ad Hoc Networks
Wu, H., Fujimoto, R., Guensler, R., & Hunter,
M. (2004, Oct.). Mddv: a mobility-centric data
dissemination algorithm for vehicular networks.
Paper presented at the Proceedings of ACM Vehicular ad hoc networks (VANET), Philadelphia,
PA.
Yamashita, T., Izumi, K., & Kurumatani, K.
(2004). Car navigation route information sharing for improvement of traffic efficiency. Paper
presented at the Proceeding of 7th international
IEEE conference on Intelligent Transportation
Systems, Washington, D.C., USA.
Wunderlich, K. E., Kaufman, D. E., & Smith, R.
L. (2000). Link travel time prediction for decentralized route guidance architectures. Journal of
IEEE Transaction on Intelligent Transportation
Systems, 1(1), 4–14. doi:10.1109/6979.869017
Zhan, F. B. (1997). Three fastest shortest path
algorithms on real road network: data structure
and procedures. Journal of geographic information and decision analysis, 1(1), 69-82.
251
252
Chapter 15
DTN Technologies for
Vehicular Networks
Kun-Chan Lan
National Cheng Kung University, Tainan, Taiwan, R.O.C.
absTracT
A Delay Tolerant Network (DTN) is one type of challenged network where network contacts are intermittent or link performance is highly variable or extreme. In such a network, a complete path does not
exist from source to destination for most of the time. In addition, the path can be highly unstable and
may change or break unexpectedly. To make communication possible in a delay tolerant network, the
intermediate nodes need to take custody of data during the blackout and forward it toward the destination when the connectivity resumes. A vehicular network nicely falls into the context of DTN since
the mobility of vehicles constantly causes the disruption of link connectivity’s between vehicles. In this
chapter, the authors discuss some research challenges and issues which might occur in a Delay Tolerant
Network and how they are related to vehicular networks.
inTroducTion
Delay/disruption tolerant networks (DTN) can be
used to increase the robustness of the network where
the network protocols must be explicitly designed
to perform despite frequent disruptions. A typical
DTN consists of a set of wireless nodes, some or
all of which are mobile. The nodes can range from
small sensor nodes, to mid-sized devices carried by
people, robots or vehicles, to larger semi-permanent
DOI: 10.4018/978-1-60566-840-6.ch015
installations. Due to node mobility or limited radio
range, end-to-end paths do not always exist between
some or all the nodes. As a result, data are transferred
in a store-carry and forward paradigm. Vehicular
ad hoc networks (VANET) have been envisioned
to be useful in road safety and many commercial
applications. For example, a vehicular network can
be used to alert drivers to potential traffic jams,
providing increased convenience and efficiency. It
can also be used to propagate emergency warning
to drivers behind a vehicle (or incident) to avoid
multi-car collisions. To realize this vision, the FCC
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
DTN Technologies for Vehicular Networks
has allocated 75 MHz of spectrum for dedicated
short range communications (vehicle-vehicle or
vehicle-roadside), and the IEEE is working on
standard specifications for inter-vehicle communication.
As technology advances make it more feasible
and cost-effective to produce vehicles that are
equipped with communication capabilities that
allow for inter-vehicle communication, large
scale vehicular ad hoc networks are expected to
be available in the near future. There are various
kinds of VANETs based on the entities involved,
such as vehicle to vehicle communication (V2V),
vehicle to roadside communication (V2R) or vehicle infrastructure integration (VII), and roadside
to roadside communication (R2R).
There are different ways to look at DTN and
VANET. At one extreme, DTN is more general,
and VANET is a special kind of DTN. At another
extreme, DTN techniques are only used in some
VANET applications when vehicles are far away
from each other, but not in safety related applications which have strict delay requirements.
Nevertheless, DTN and VANET have many common characteristics which present challenges and
opportunities for the research community.
Many unique characteristics of VANET bring
out new research challenges. First, due to fast
vehicle movement, network topology and channel conditions change rapidly. As a result, many
well-studied structures such as tree, clustering,
grid, are extremely hard to set up and maintain.
Second, the network density is highly dynamic.
The traffic load is low in rural areas and during
night, which may result in frequent disconnections
and network partitions.
On the other hand, during rush hours or traffic congestion, the network density is very high,
which may generate data collisions and result in
network congestion. Third, the vehicle mobility
is partially predictable since it is limited by the
traffic pattern and the road layout.
These unique characteristics bring out research issues at different layers of the network
stack. At the physical layer, directional antenna/
MIMO techniques may be applied to increase
the network capacity. At the data link layer,
new MAC protocols should be designed to meet
latency and reliability requirements, especially
for safety related applications. Because vehicles
move along roads, directional-antenna-based
MAC mechanisms might be especially useful for
VANET. At the network layer, protocols should
be designed to exploit the mobility to maintain
the route. At the transport layer, new protocols
should be designed to tolerate routing layer disruptions. From the network perspective, security
and scalability are two significant challenges.
Although power efficiency in VANET is less of
a concern, scalability may still be critical. Due
to the nature of the vehicular applications, there
might be more flooding/broadcasting in VANET
than in traditional ad hoc networks.
This could easily create network congestion
if the communication protocols are not welldesigned.
There are many challenges and opportunities
in DTNs. Many VANET applications can be built
on DTNs, and hence most of the challenges and
opportunities presented in VANET are also valid
in DTNs. As social networking becomes popular,
more applications can be built over DTNs. Also,
a number of non-interactive applications related
to sensor networks can be adapted to DTNs.
Unlike Internet applications, DTNs provide an
opportunity for aggregation, replication, and innetwork processing as data traverses the network.
Traditionally, DTN is treated as an edge solution
for the future Internet paradigm. It is a challenge
to re-think the Internet as a DTN. Further, DTNs
may rely on some level of infrastructure support
to improve their performance, and hence hybrid
DTN/infrastructure networks are another area to
explore.
There are many technical issues to explore in
DTNs. First, how to achieve service discovery,
context awareness and group communication,
which are standard modules in distributed sys-
253
DTN Technologies for Vehicular Networks
tems. Due to inherent delays in DTNs, these
popular services need to be redesigned. Second,
we should define the communication paradigm
in DTN. In traditional networks, the end-to-end
concept is used. In DTN, many issues need further
investigation. For example, what are the network
interfaces? Does DTN have a flow concept? Third,
DTN is based on the idea of store-carry and forward. Although forwarding has been well studied
in traditional networks, we don’t have enough
knowledge on the role of storage and it is not clear
how to manage storage in DTNs. Finally, there are
many other research issues such as security, the
role of network coding for DTNs, and network
characterization (based on e.g. Graph Theory).
One key feature of VANET/DTN is the mobility model, which is very important for future
research in this area. In VANET, the mobility
model can be based on previous work done by researchers in other fields such as civil engineering.
However, more work should be done on porting
these results to our community. This can be in
the form of adding mobility models for VANET
to well known simulation platforms such as ns2.
For general DTN, the mobility model is not that
clear, and is worth further investigation. Further,
communication and data traffic models may be
application-specific.
In summary, VANET/DTN are well outside
traditional networking assumptions and challenge
our thinking about future Internet designs. In
this chapter, we present an overview of existing
research activities in DTN.
dTn
A Delay Tolerant Network (DTN) is a developing system that suffers frequent and long duration network partitions. It is an overlay on top
of multiple network partitions, which may be
challenged by limitations such as intermittent
and possibly unpredictable loss of connectivity,
254
long or variable delay and high error rates. For
the intermittent connectivity, an end-to-end path
between the source and the destination may not
exist. Therefore, TCP/IP protocol will break in
this kind of environment because an end-to-end
path between source and destination may only
exist for brief and unpredictable periods of time.
Furthermore, in DTN, there are long propagation
and variable queuing delays. Many Internet protocols which are designed assuming quick return of
acknowledgements and data fail to work in such
networks. The problems of DTN as mentioned
above are addressed by adopting store-carryforward message switching. Here entire chunks
of message are transferred from one storage place
to a storage place in another node along a path
that is expected to reach the destination.
There are many applications for DTN. For
particular field, this kind of applications is used
in the special environment that is to be tolerant of
long delay and high error rate. The Interplanetary
Internet project must encompass both terrestrial
and interplanetary links. Sami Network Connectivity (SNC) Project (Lindgren et al., 2007)
focuses on establishing Internet communication
for Sami population of reindeer herders who live
in remote areas. DARPA (Krotkov, et al., 1999)
is researching and developing the capability to
perform urban reconnaissance with teams of
small, low-cost, semiautonomous mobile robots.
For developing regions networks, the networks
of developing countries or the outlying area are
not usually perfect, so the foreign networks of a
lot of areas are being developed, even there is no
network at all. In (Brewer et al., 2005), several
applications are developing for this kind of region
from education to health care and government
services. This project is supported by (Tier, 2009).
For environmental monitoring, this application is
to monitor the animals or environment. In (The
zebranet wildlife tracker, 2009), this project is to
track the Wildlife Tracker.
DTN Technologies for Vehicular Networks
Figure 1. The DTN protocol stack
or more DTN regions and may optionally be a
host, so it must have persistent storage and support
custody transfers.
challenges
an oVerView oF delay
ToleranT neTworks
architecture
In a DTN, a network is typically separated into
several network partitions which called regions.
Traditional applications are not suitable for this kind
of environment because they normally assume that
the end-to-end connection must exist from source
to destination. The DTN enables the devices in
different regions to interconnect by operating message in store-carry-forward message fashion. The
intermediate nodes implement store-carry-forward
message switching mechanism by overlaying a new
protocol layer, called the bundle layer (Scott et al.,
2007 ; Segui et al., 2006). The DTN protocol stack
is as shown in Figure 15.1. In a DTN, each node is
an entity with a bundle layer which can act a host,
router or gateway. When node acts a router, the
bundle layer of router requires persistent storage
to queue bundles and forwards the bundles within
a single region. On the other hand, the bundle layer
of gateway is not only provision the store-carryforward mechanism, but provision the conversion
between the lower-layer protocols of the regions
they span, as shown in Figure 15.1. In other words,
a DTN gateway can forward bundles between two
In a DTN, when nodes move away or turn off their
power to conserve energy, links may be disrupted
or shut down periodically. These events result in
intermittent connectivity. When no paths exist
between source and destination, the network partition occurs. Therefore, nodes need to communicate
with each other via opportunistic contacts through
store-carry-forward operation. In this section, we
consider three specific challenges in an opportunistic network: the contact opportunity, the node
storage and the power conserving.
contact
Due to the node mobility or the dynamics of
wireless channel, a node might make contact
with other nodes at an unpredicted time. Since
contacts between nodes are hardly predictable,
they must exploited opportunistically for exchanging messages between some nodes that can move
between remote fragments of the network. Burns
et. al. (2005) classified the routing methods for
DTN based on characteristics of participants’
movement patterns. The patterns are classified
according to two independent properties: their
inherent structure and their adaptiveness to the
demand in the network. Other approaches propose message ferries to provide communication
service for nodes in the deployment areas (Zhao
et al., 2004, May ; Zhang et al., 2007 ; Chen et
al., 2007 ; Tariq et al., 2006). In addition, the
contact capacity needs to be considered. In other
words, how much data can be transferred between
two nodes when two nodes contact? Hui et. al.
(Chaintreau et al., 2005) defined two parameters,
contact duration and inter-contact time, that are
the important factors in determining the capacity
of the networks.
255
DTN Technologies for Vehicular Networks
storage
As the described above, to avoid dropping packets,
the intermediate nodes are require to have enough
storage to store all messages for unpredictable
periods of time until next contact. In other words,
the required storage space increases a function of
the number of messages in the network. Therefore, the routing and replication strategies must
take the storage constraint into consideration.
Vahdat and Becker (Vahdat et al., 2000) used
Epidemic Routing by flooding the network to
exploit the best possible delivery delay brought
by mobility. This scheme achieves the optimal
delay with unlimited relay buffers. However,
such a multiple-copy scheme generally incurs
significant overhead on storage constraint. Ip et.
al. (2007) proposed a buffer-management strategy,
RRFS-with-RandomDrop, to avoid head-of- line
blocking in the FIFO case. They showed that the
proposed strategy can reduce the degradation of
average delivery delay performance.
Device Energy
During opportunistic contacts, the nodes may need
to communicate in order to transfer the data to
destination. For conserving the device energy, the
node may need to know the contact time and the
duration for transfer the complete or segmented
bundle in order to wake up at the contact time. Jun
et. al. (2005) proposed a power management in
DTN depending on knowledge-based mechanisms
similar to the DTN routing algorithms (Jain et al.,
2004). Two extremes of knowledge are complete
knowledge and zero knowledge. The former has
the precise time of contacts, so it can provide the
upper bound on performance. The latter do not has
any knowledge, so a node chooses a random time
and broadcasts a beacon. If it does not receives
a beacon, the node sleeps and wakes up at the
beginning of the next beacon time. In the partial
knowledge, a node knows statistics some information about the contact durations and waiting times
256
between contacts with other nodes. Depending
on the statistical information, a node may expect
to the waiting time before the contact. However,
those methods may be applied to the network that
followed a regular schedule. In (Jun et al., 2006),
the authors propose a hierarchical power management in DTN. The energy in the architecture can
be conserved by using lower-power, long-range,
radio to discover the contacts and then wake the
high-power, short-range, radio to prepare the
data transmission. However, these architecture
may be inefficient because mobile node may not
enter into high-power radio range and do not reduce the cost of other idle hardware components.
Similar to (Jun et al., 2006), a throwboxs with
power management is proposed in (Banerjee et
al., 2007) . In the architecture, the mobile node
beacon their position, direction and speed using
the long-range radio when it moves to the range
of tier-0, long-range radio. If the throwbox hears
a beacon, it predicts how long the mobile node
will contact with the tier-1, short-range radio. By
predicting the trajectory of an oncoming mobile
node, the tier-0 wakes the tier-1 to undertake the
data transmission.
physical layer
In order to operate under the challenged network
(Fall et al., 2003), the concept of long-lived is
an important requirement. For some applications, i.e. underwater sensor network, terrestrial
sensor network, they must design the suitable
communication hardware. Existing underwater
communication systems have some useful physical design for DTN. Freitag et al. (2005) have
developed a compact and low-power acoustic
modem, called Micro-modem. The low-power
design is an enabling factor for long-lived sensor
networks over battery-powered nodes. In (Wills
et al., 2006), authors propose an inexpensive and
low-power hardware modem to save the power
in order to provide long-lived operator. For low-
DTN Technologies for Vehicular Networks
power operation, the power-saving is to use the
wakeup tone receiver to trigger the more expensive
data receiver. Authors also assume the radio will
be duty cycled, alternating on-and-off periods
frequently when active, and with long-term off
periods when inactive.
mac layer
As the section III, the medium access control
(MAC) protocol needs to be modified for the high
latency requirement. The communicating nodes
in DTN may suffer from high latency problem.
Similarly, the underwater acoustic communication
may also suffer from latencies larger than radio
communication. In (Rodoplu et al., 2005), authors
extend S-MAC’s schedule synchronization to
sender-receiver pairs in underwater. This protocol
explains how to achieve a locally synchronized
schedule even in the presence of long propagation
delays. Each node schedules the time to transmit
the next packet, and broadcasts this information
by attaching it to the current data packet. While
hearing the broadcasts, the other nodes will know
when to wake up for the subsequent packet.
However, in order to operate at a low collision
rate, each node requires a small duty cycle, which
makes throughput low.
neTwork layer
In this section, we discuss some routing solutions
for a DTN. Based on the number of copies of a
message forwarded by the node, we can define
two different routing schemes: forwarding-based
(single copy) approach and flooding-based
(multiple copies) approach. In forwarding-based
approach, there is only one single custodian for
each message to help forwarding the message to
destination. When the current custodian forwards
the copy to an appropriate next-hop neighbor, this
neighbor becomes the message’s new custodian.
The same process is repeated until the message
finally reaches its destination. This approach tries
to reduce the buffer usages and the number of
message transferred in the network. But it may
suffer the long delays and low delivery ratios.
On the other hand, flooding-based approach may
generate multiple copies of the same message.
Each message can be routed independently for
increased efficiency and robustness. This approach achieves lower delays and higher delivery
ratio at the cost of a larger buffer space and more
message transfers.
Forwarding g-based approach
In the forwarding-based scheme, based on what
type of knowledge nodes use to select the appropriate or the best path to destination node, the prior
studies can be classified into three categories:
direct transmission, location-based, Knowledgebased and control-movement based.
Direct Transmission
Spyropoulos et. al. (2004) is proposed a simple
single-copy routing called direct transmission
routing. In this approach, after the source node
generates a message, the message is hold by
the source node until it reaches the destination
node. The main advantage of this scheme is that
it incurs minimum data transfers for message
deliveries. On the other hand, although having
minimal overhead, this scheme may incur very
long delays for message delivery since the delivery
delay for this scheme is unbounded (Grossglauser
et al., 2002) .
Location-Based
In the location-based approach, nodes will choose
the neighbors who are closest to the destination to
pass the message. LeBrun et al. (2005) proposed a
method using the motion vector (MoVe) of mobile
nodes to predict their future location. The MoVe
257
DTN Technologies for Vehicular Networks
scheme uses the knowledge of relative velocities
of a node and its neighboring nodes to predict the
closest distance between two nodes. After the
nodes’ future locations are calculated, messages
are passed to nodes that are moving closer to the
destination. As compared to epidemic routing,
this approach has less control packet overhead
and buffer usage. Leguay et al. (2006) presented
a strategy that uses a virtual coordinate routing
called mobility pattern spaces (MobySpace). In
this approach, the node coordinates are composed
of a set of dimensions, each dimension represents the probability that a node will be found
in a specific location that is a virtual expression
of the mobility pattern and does not geographic
coordinate of the node. There are various destination functions are computed on this vector. They
showed that this approach consumes less resource
than epidemic routing when they deliver large
amount of bundles.
Knowledge-Based
In the knowledge-based approaches, based on
certain knowledge about the network, the source
and intermediate nodes decide which nodes to
forward messages as well as whether it should
transmit the message immediately or hold the
message until it meets a better node. Jain et al.
(2004) proposed the knowledge-based routing
scheme which is the first study in this area. Depending on the amount of knowledge about network topology characteristics and traffic demand,
they define four knowledge oracles. Each oracle
presents some particular knowledge of network.
Based on the available oracles, the authors present a corresponding routing algorithm. The first
algorithm is called Minimum Expected Delay
(MED). In this algorithm, when the contact summary oracle, which contains information about
aggregate statistics of the contacts, is available,
Dijkstra with time-invariant edge costs based on
average waiting time is used to find the best route.
The second algorithm is called Earliest Delivery
258
(ED) where the contact oracle is available. The
contacts oracle contains information about contacts between two nodes at any point in time.
When this algorithm assumes the queuing delay
is zero, the modified Dijkstra with time-varying
cost function based on waiting time is used to find
the route. The third algorithm is Earliest Delivery
with Local Queuing (EDLQ), which uses the local
queue occupancy to add an estimate of the queuing delay to the ED algorithm. Final algorithm is
the Earliest Delivery with All Queues (EDAQ)
where the contact oracle and queuing oracle is
available. The queuing oracle gives information
about instantaneous buffer occupancies (queuing)
at any node at any time. This algorithm adds the
queuing oracle to ED. This approach assumes that
the accurate information about the oracle is known
in advance. This assumption may be workable
for some scenarios where the node movement is
predictable, i.e., city bus.
Musolesi et al. (2005) present the ContextAware Routing (CAR) protocol that provides an
asynchronous communication for message delivery. In a DTN, since the receiver is often not in the
same connected network, synchronous delivery
of message is typically not possible. In CAR, if
a message cannot be delivered synchronously,
the message is sent to a host that has the highest
probability of successful delivery and acts as a
message carrier. The delivery probability process is
based on the evaluation and prediction of context
information using kalman filters. The prediction
process is used during temporary disconnection
and the process is continued until it is possible
to guarantee certain accuracy. In addition, the
epidemic routing can be considered optimal in
terms of delivery ratio because each message is
propagated to all accessible nodes which have
large buffers to hold the messages. They showed
in their simulations that if the buffer size is small,
the packet delivery ratio of CAR is batter than
the packet delivery ratio of epidemic routing due
to that CAR only creates a single copy for each
message.
DTN Technologies for Vehicular Networks
Burgess et al. (2006) proposed an effective
routing protocol called MaxProp. A node uses
MaxProp to schedule packets transmission to its
peers and determines which packets should be
deleted when buffer space is almost full. Packets
are scheduled based on the path likelihoods to
peers according to historical data. In addition,
several complementary mechanisms, including
acknowledgments, a head-start for new packets,
and lists of previous intermediaries are used in
this approach. They showed that their approach
performs better than the protocols that have access to an oracle (Jain et al., 2004) that knows the
schedule of meetings between peers. Kun et al.
(Tan et al., 2003) proposed a shortest expected
path routing (SEPR) similar to link-state routing
to maintain a topology map to each other. SEPR
first estimates the link forwarding probability
based on history data. When two nodes meet, they
exchange the link probability update messages
called effective path length (EPL). A smaller EPL
value suggests a higher probability of delivery.
When a node received a smaller EPL, it will
update its local EPL value. EPL is also used in
deciding which nodes to forward the messages.
Using SPER protocol, the same message could be
forwarded to multiple nodes to increase reliability
and reduce delay.
Control-Movement Based
In contrast to letting the mobile host wait passively for reconnection, the mobile hosts actively
modify their trajectories to minimize transmission
delay of messages. Some works have proposed
approaches that try to limit delay by controlling
node mobility. Zhao et al. (2004) propose a Message Ferrying (MF) approach for data delivery in
sparse network. MF is a mobility-assisted approach
which utilized message ferries to provide communication service for nodes in the network. Similar
to their real life, message ferries move around the
deployment area and take responsibility for carrying data between nodes. The main idea behind
the Message Ferrying approach is to introduce
non-randomness in the movement of nodes and
exploit such non-randomness to help deliver data.
Two variations of the MF schemes were developed. In the Node-Initiated MF (NIMF) scheme,
ferries move around the deployed area according
to known specific routes and communicate with
other nodes when they meet. With knowledge of
ferry routes, nodes periodically move close to
a ferry and communicate with the ferry. In the
Ferry-Initiated MF (FIMF) scheme, ferries move
proactively to meet nodes. It is assumed that the
ferry moves faster than nodes. When a node wants
to send packets to other nodes or receive packets,
it generates a service request and transmits it to a
chosen ferry using a long range radio. Upon reception of a service request, the ferry will adjust its
trajectory to meet up with the node and exchange
packets using short range radios. In both schemes,
nodes can communicate with distant nodes that
are out of range by using ferries as relays. Zhao
et al. (2005) also propose multiple ferries with
stationary nodes to deliver data in networks and
design of ferry routes. The route design problem
with multiple ferries is more complicated than the
single ferry case considering the possibility of interaction between ferries. The authors present four
algorithms to generate ferry routes that meet the
traffic demand and minimize the weighted delay.
The authors considered algorithms that assume no
interaction between ferries, either using a single
route (SIRA) or multiple routes (MURA). In the
single ferry, they adapt solutions for the wellstudied traveling salesman problem (TSP). In the
multiple ferries, the algorithm is to assign nodes
to specific ferries. The authors also considered
algorithms that allow data relaying between ferries
directly, ferry relaying algorithm (FRA), or indirectly, node relaying algorithm (NRA). In NRA,
data is relayed between ferries via nodes, so the
NRA adopts a geographic approach for assigning
nodes to ferries. In FRA, data may be forwarded
through multiple ferry routes while being routed
to the destination. But instead of relaying data via
259
DTN Technologies for Vehicular Networks
nodes as in NRA, ferries exchange data directly.
Therefore, ferry routes need to be synchronized for
two ferries to meet each other. Simulation results
are obtained to evaluate the performance of route
assignment algorithms, especially on the effect
of the number of ferries on the average message
delay. Numerical results indicate that when the
traffic load is low, the improvement in delay due
to the increased number of ferries is modest. This
is because the delay is dominated by the distance
between nodes. However, when the traffic load
is high, an increase in the number of ferries can
significantly reduce the delay.
Flooding-based approach
In the flooding-based approach, each node broadcasts the received packet to all of its neighbors,
with the hope that one of these intermediate nodes
will reach the destination.
Epidemic Routing
Epidemic routing is first proposed by Vahdat and
Becker (2000) for forwarding data in a DTN.
Epidemic routing utilizes the epidemic algorithm
(Demers et al., 1987) that was originally proposed
for synchronizing replicated databases. The epidemic algorithm ensures that a sufficient number
of random exchanges of data in the network and
guarantees all nodes will eventually receive all
messages. Epidemic Routing works as follows.
When two nodes come into contact, each node
will exchange the list of all message IDs that they
have in their buffers, called the summary vector, to
see if there are any messages that the other node
has that it has not received. After such pair-wise
exchange of messages, each node will get all the
messages carried by the other node that it has
not received. When this operation completes, the
nodes have the same messages in their buffers.
The Epidemic Routing is similar to the flooding
routing because it tries to send each message to
all nodes using the summary vector in the net-
260
work. For this reason, Epidemic Routing incurs
significant demand on both bandwidth and buffer.
To reduce such overhead, there are many related
paper to make epidemic routing consume fewer
resources (Spyropoulos et al., 2005 ; Lindgren et
al., 2003 ; Tan et al., 2003). To bound the overhead
of delivering a message, Spyropoulos et al. (2005)
proposed a technique called Spray and Wait to
control the level of flooding. In the spray phase,
there are L numbers of copies that are initially
spread over the network by the source node or
other nodes to L distinct relays. In the wait phase,
if the destination was not found during spray
phase, each node that has a copy of message will
perform direct transmission. Binary spray and wait
is a variation of Spray and Wait and produces a
better performance. In this approach, the binary
spray source node sends half of the copies of the
message to the new relay node, and keeps the rest
for itself. The source node and relay nodes repeat
this procedure until there is only one copy left.
When there is only one copy left, it switches to
direct transmission.
Conditional Routing
In conditional routing, nodes are not blindly
forward the messages to all or some neighbors.
Instead, nodes estimate the probability of each link
to destination and use this information to decide
whether it should store the packet and wait for a
better chance as well as to decide which nodes
to forward. Lindgren et al. (2003) proposed a
probabilistic routing protocol, called PROPHET
(Probabilistic Routing Protocol using History of
Encounters and Transitivity). PROPHET estimates
probabilistic metric called delivery predictability.
This metric indicates the probability of successfully delivering a message to the destination from
the local node. PROPHET operates in a similar
way as Epidemic Routing (Vahdat et al., 2000).
When two nodes meet, they exchange summary
vectors containing the delivery predictability vector which is based on the delivery predictability
DTN Technologies for Vehicular Networks
Table 1. The comparison of routing protocols for DTN
Protocol
Buffer Management
Estimation of link
forwarding probability
Complexity of information exchange
or computation for the link state
Reactive or
Proactive
Epidemic
Infinite
No
Don’t need
Reactive
CAR
Infinite
YES, using Kilman filter
Computation only
Reactive
Spray and wait
Infinite
No
Don’t need
Reactive
PROPHET
Infinite
YES, using delivery
predictability vector
Exchange and computation
Reactive
MaxProp
Infinite
YES, estimating the delivery likelihood
Exchange and computation
Reactive
Knowledge
Infinite
YES, using oracle based
Dijkstra algorithm
Exchange and computation
Reactive
SEPR
YES, remove those packets
with smaller EPL
YES
computation
Reactive
Direction transmission
Infinite
Don’t need
Don’t need
Reactive
MoVe
Infinite
Exchange and computation
Exchange and computation
Reactive
NIFM
YES, message time out and
buffer overflow
No
Don’t need
Proactive
FIFN
No
No
Compuation
Proactive
information. In theory, if two nodes are often encountered, they have high delivery predictability
to each other. On the other hand, if a pair of nodes
does not encounter each other in a while, they
are intuitively not good forwarders of message
to each other. Hence, the delivery predictability
values must age (i.e. be reduced) as time goes.
They showed in their simulation results that the
communication overhead of PROPHET is lower
than epidemic routing because PROPHET is only
sent to better nodes.
TransporT layer
The existing transport layer protocols, such as
TCP are not suitable for an environment where
frequent disruption is a norm and end-to-end
paths are typically not available. In (Ramadas
et al., 2007), authors proposed the Licklider
Transmission Protocol (LTP) that provides
retransmission-based reliability over single links
with extremely high latency such as deep space
communications. LTP handles the transmission of
a block of data, which can be split into segments
that match the maximum transmission unit for the
link. In an Interplanetary Internet setting, LTP is
intended to serve as a reliable “convergence layer”
protocol over single hop deep-space RF links.
LTP implements ARQ of data transmissions by
soliciting selective-acknowledgment reception
reports. When a client service transmits the segments of data, some are flagged as checkpoints.
When a checkpoint is received, the receiver
returns a report of cumulative reception for that
block. Reports acknowledge checkpoints and
either signal successful reception or else trigger
retransmission. Farrell et al. (2005) proposed a
generic transport protocol for DTN that use the
LTP extension mechanism (Farrell et al., 2007)
to create an end-to-end capable transport protocol
called LTP transport (LTP-T). The LTP extension
mechanism was originally defined to handle the
addition of authentication fields to LTP and al-
261
DTN Technologies for Vehicular Networks
lows for the addition of both header and trailer
extensions, up to a maximum of 16 (of each). In
this work, authors define a new set of extensions
of LTP about the transport protocol, i.e., source
address, destination address, estimated block size
and congestion notification etc.
Since Bundle Protocol (Scott, K.et al., 2007)
requires the services of a “convergence layer
adapter (CLA)” which is an interface between
the common bundle protocol and a specific
internetwork protocol suite to send and receive
bundles using an underlying Internet protocol,
then in (Demmer et al., 2006) the authors present
one such convergence layer adapter that uses the
well-known Transmission Control Protocol (TCP).
The TCP-based convergence layer (TCPCL) is
used to link two bundle nodes. The lifetime of
a TCPCL connection will match the lifetime of
its underlying TCP connection. In other words,
a TCPCL connection is initiated when a bundle
node initiates a TCP connection to be established
for the purposes of bundle communication. It is
terminated either when the TCP connection ends
due to one or both nodes actively terminating the
TCP connection, or when network errors causes
a failure of the TCP connection. In (Wood et al.,
2007), the authors showed that the TCP protocol
does not make effective use of available link
capacity in a challenged environment like an opportunistic network. In (Wood et al., 2007) the
authors proposed use Saratoga (Wood et al., 2008)
as convergence layer. Saratoga is a UDP based
file transfer protocol that can be used to transfer
bundles. To send a bundle, the local bundle agent
will either place bundles as files for Saratoga to
transfer from its directory that can be accessible
to both the bundle and Saratoga processes, or
otherwise use inter-process communication to
notify Saratoga of and provide a bundle to be
transferred.
262
bundle layer
As mentioned at section II, the bundle layer is
responsible for storing, carrying and forwarding the data in DTN. Except from the unicast
bundle delivery, multicast and anycast delivery
approaches are typically used when there are more
than one destination.
bundle delivery approach
In a DTN, applications utilize nodes to send or
receive data that is carried in bundles which can
be delivered to a group of nodes. When the group
size is greater than one, the delivery semantics
may be either the anycast or multicast. For anycast
delivery, a bundle is delivered to at least one and
preferable only one of the members in a group. On
the other hand, for multicast delivery, the bundle
is intended to be delivered to all members in the
same multicast group.
Anycast
In (Gong et al., 2006), authors defined an anycast
semantics model and propose a routing metric,
called EMDDA (Expected Multi-Destination
Delay for Anycast), for anycast. The semantics
models allow message senders to explicitly
specify the intended receivers of a message. In
this study, the anycast routing algorithm is based
on the metric EMMA which accurately estimates
the delay from a node to the nearest member of
the destined anycast group. EMDDA of a node
to an anycast group is defined as the minimum
value of Practical Expected Delays (PEDs), which
PED is the expected delay of taking different
paths, from the node to all the destination group
members. When a message arrives at a node, but
the node is not an intended receiver of the anycast
message, the node will calculate its EMDDA to
the destination group.
DTN Technologies for Vehicular Networks
Multicast
Due to the network partitions and opportunistic
contacts, nodes are difficult to maintain a sourcerooted multicast tree during the lifetime of a multicast session. The traditional approaches may fail
to deliver a message when the link is unstable. In
(Zhao et al., 2005), the authors investigated four
approaches which are adopted from multicasting
in the Internet or MANET. (1) UBR (UnicastBased Routing) uses unicast transfer to achieve the
multicast service. (2) In Broadcast-Based Routing
(BBR), messages will be flooded throughout the
network in order to reach the intended receivers.
(3) In Tree-Based Routing (TBR), messages are
forwarded along a tree in the DTN graph that is
rooted at the source and reaches all receivers.
Messages are duplicated only at nodes that have
more than one outgoing path. (4) Group-Based
Routing (GBR) uses the concept of forwarding
group which is a set of nodes that are responsible
for forwarding the message. Messages will be
flooded within the forwarding group to increase the
chance of delivery. Based on the above algorithms,
the authors present some algorithms for DTN are
as follows. (1) UBR (Unicast-Based Routing) uses
unicast transfer to each of the estimated intended
receivers by encapsulating the original multicast
message. The source node also buffers the multicast message and sends out new unicast messages
when being informed of new intended receivers
(2) In STBR (Static TreeBased Routing), messages are forwarded along a tree in the graph that
is rooted at the source and reaches all receivers.
Due to that the route is static, the message needs
to wait for the next opportunity to be forwarded
if a message misses a contact opportunity with a
node. This may cause significantly increase the
message delay. (3) In DTBR (Dynamic TreeBased
Routing), nodes can determine the next-hop forwards of a message dynamically based on current
available information. (4) BBR (BroadcastBased
Routing) always includes all nodes in the network,
so messages are flooded throughout the network.
(5) GBR (GroupBased Routing) uses the concept
of forwarding group for each message by computing a shortest path tree as in STBR. The group is
a set of nodes that are responsible for forwarding
the message. Messages are forwarded by flooding
within the forwarding group.
In (Ye et al., 2006), the authors proposed an
on-demand situation-aware multicast (OS-mul-
Table 2. The comparison of multicast protocols for DTN
Protocol
Knowledge
Additional
technologies
Routing Type
Tree Type
UBR
Unicast
N/A
N/A
STBR
Tree, using shortest path
Source-routed, static tree
N/A
DTBR
Tree, using shortest path
Source-routed, dynamic tree
BBR
Broadcast
N/A
GBR
Tree, using shortest path
Source-routed, static path to a
group
OS-multicast
Tree, using shortest path
Source-routed, intermediate node
dynamic rebuild the tree rooted
itself
CAMR
Tree, using the contact probability estimate
Source-routed
Estimate the
neighbor knowledge
High power transmission and message
ferry
EBMR
Tree, using the highest delivery
predictability
Source-routed
delivery predictability
Directional antenna
N/A
Complete knowledge or summary
of the link states
N/A
N/A
N/A
263
DTN Technologies for Vehicular Networks
ticast) approach. Initially, a source-rooted tree is
constructed in the similar way as STBR. When a
node receives a bundle, it will dynamically rebuild
the tree rooted at itself to all the destinations based
on the current network conditions. Their simulation results show that OS-multicast can achieve
smaller delays and better message delivery ratios
than DTBR due to that each node in DTBR only
forwards bundles to downstream nodes to reach
the receivers in its receiver list and OS-multicast
always use all possible chances to forward the
bundles to all the destinations.
In (Yang et al., 2006), the authors proposed a
context-aware multicast routing (CAMR) scheme
where nodes are allowed to use high power transmissions when the node density (which is locally
observed) drops below a certain threshold. Each
node maintains contact probabilities using its
2-hop neighbor information. This allows each
node to deliver traffic without invoking a route
discovery process if all receivers are within its
two-hop neighbor. In addition, nodes are allowed
to act as message ferries when they discover they
are in a very sparse neighborhood and then travel
to closer to the next-hop for delivering bundles.
The combined high-power route discovery process
and message ferrying features allow CAMR to
achieve much higher multicast delivery ratio than
DTBR and OS-multicast schemes.
In (Chuah et al., 2007), the authors build
the multicast scheme on top of the PROPHET
(Lindgren et al., 2003), so this scheme is called
encounter-based multicast routing (EBMR)
scheme. This scheme has several enhancements to
improve the delivery performance. First, each node
selects as many nodes as needed with the highest
delivery predictability to each of the multicast
receivers. If the next-hop can not be found, a node
will cache the data until the timer expires. When
the timer expires, the node simply selects a node
with the highest delivery predictability to multicast
receivers. The second enhancement allows nodes
264
in the boundary region to use directional antenna
to find nodes in other regions if they cannot hear
any such node using omnidirectional antenna.
security
A draft DTNRG document presents the bundle
security protocol specification (Symington et al.,
2007) and an additional draft document (Symington et al., 2007) explains the rationale for the
design choices made in the specification. The
specification describes three security blocks that
can be added to bundles to provide different security services. The Bundle Authentication block
(BAB) is used to provide authentication over a
single hop by adding a message authentication
code or a signature to the bundle. The Payload
Security block (PSB) is used to provide end-toend authentication in a similar fashion and the
Confidentiality block (CB) is used to encapsulate
encrypted payload of a bundle. Different combinations of these three security headers can be used
simultaneously. Seth et al. (2005) propose the use
of hierarchical Identity Based Cryptography (IBC)
(Boneh et al., 2003) to achieve end-to-end security.
The authors observe that traditional PKIbased approach is not suited for disconnected networks,
since in DTN there do not have online access to
an arbitrary receiver’s public key or certificate. In
HIBC, different regions have sub-regions which
maintain their own PKGs. A user sent messages
with one PKG to a user of another PKG. The
messages are authenticated and protected using
the trust relations between PKGs and standard
techniques of HIBC. The identifier of a principal
can be based on existing well-known identifiers
like e-mail addresses. However, in (Asokan et
al., 2007), the authors argue that HIBC is not
necessary because cellular operators already have
roaming agreements intended to enable crossdomain operation.
DTN Technologies for Vehicular Networks
applicaTion layer
In a DTN, traditional applications fail to take
advantage of the communication opportunities
offered by those opportunistic contacts. Hence,
even the application is delay-tolerant in nature,
the overall application performance can still suffer
significantly in a disconnection-prone environment. We will discuss the application in DTN
from the common example, e-mail, to the more
complex example, web service. The well-known
paradigms on the Internet is E-mail because this
application is delay-tolerant by large and e-mail
users are used to wait for hours or days for a reply. However, given that the underlying transport
protocol of e-mail (i.e. TCP) is not designed for a
DTN, supporting e-mail in such an environment
is still quite challenging.
Scott et al. (2005) proposed the use of DTN
SMTP proxies to hide the disruptions between
end users in a challenged network. This proxy
is responsible to help the client to perform its
work and exchanges the corresponding information to a peer proxy. The peer proxy receives the
information and sends it to the SMTP server. The
drawback of this proxy-based approach for SMTP
protocol is that the proxy has to execute the entire
SMTP protocol forwarding the information via
the inter-proxy protocol. In (Hyyrylainen et al.,
2007), the authors describe an architecture to enable mail communication in a heterogeneous environment that combines traditional server-based
mail delivery and opportunistic communications
for different types of devices. In this architecture,
mail messages are sent in bundles into the DTN
and carried toward a DTN mail gateway (DTNMWG). The DTN-MWG is responsible to forward
and receive the mail between the infrastructure
network and the DTN network. The DTN-MWG
and corresponding device could implement the
Bundle Protocol to eliminate unnecessary process
(Scott et al., 2005). In addition, three different
user equipment options can be configured on their
device. (1) To enable the user to continue using
traditional email applications, the user laptop can
have a specialized email proxy to receive email
from traditional and DTN connectivity options.
(2) User equipment may contain separate mail
application for both traditional mail and DTN
mail. (3) User equipment may contain only the
DTN mail application.
Table 3. The comparison of application service for DTN
Protocol
Application
Additional entities
K. Scott
E-mail
DTN SMTP proxies
Don’t modified
Don’t modified
T. Hyyrylainen et al.
E-mail
DTN mail gateway
Add DTN Mail Proxy in client
device
Don’t modified
DTN mail gateway
Add another mail application for
DTN mail
Don’t modified
DTN mail gateway
Only receive the mail from DTN
mail gateway
Don’t modified
Don’t modified
Don’t modified
Bundle router (BR)
Add the bundle protocol
Add the bundle protocol
BR and Proxy
Add the bundle protocol
Add the bundle protocol
Don’t modified
Don’t modified
Add the user query database
Don’t modified
K. Scott
Web
J. Ott et al.
Web
DTN-enable web proxy
BR and Gateway
A. Balasubramanian et al.
Web
Proxy
Client Application
Server
265
DTN Technologies for Vehicular Networks
Supporting e-mail in a DTN system is straightforward since that fits into the characteristics of
the DTN very well. Adding support for Web in
DTN is much more complicated, because highly
interactive application protocols, such as HTTP,
are not well suited for this kind of environments. In
(Scott et al., 2005), Scott proposed an implement
of DTN-enable web proxy by extending the World
Wide Web Offline Explorer (WWWOFFLE,
2009). The authors split the WWWOFFLE proxy
and added client and a server side. The client side
links to the challenged network and uses DTN
bundles to communicate with the server side. The
server side has full connectivity to the Internet,
so that when the server receives requests from
clients, it can use HTTP to retrieve the requested
web pages through the Internet. In (Ott et al.,
2006), authors presented a protocol design and a
system architecture for delay-tolerant access to
web pages. This work uses the bundle protocol
to transport the HTTP payloads in DTN network.
Furthermore, several scenarios are proposed for
retrieving the content. First scenario is End-to-end
HTTP-over-DTN. This scenario requires both client and server implementing HTTP-over-DTN so
that bundles can be sent directly to the respective
server. Second scenario is Proxy-based HTTPover-DTN. Adding proxies into an HTTP-overDTN may support a mobile node in content aggregation from one or more origin servers. Finally,
gatewaying HTTP-over-DTN proposes gateway
entities that communicate with another gateway
through HTTP-over-DTN. The web clients and
web servers communicate with gateway through
HTTP-over-TCP and the intermediary gateway is
required to covert between HTTP-over-DTN and
HTTP-over-TCP operation. Balasubramanian et
al. (2007) proposed a system, called Thedu which
use an Internet proxy to collect search engine result
and prefetch result pages. The mobile node can
receive the user query through web interface and
store it until the mobile node contacts with the
proxy. If the connection is broken, the remaining
web pages will be downloaded at next contact time.
266
Furthermore, when the proxy awaits connection
from a mobile node and has pending response, it
downloads the responses and fetches some relevant
web pages. In addition, the proxy will prioritize
response bundles at next contact time.
conclusion
DTN is an emerging system that is getting growing interest in networking research community.
The DTN places different research challenges on
different layers of a protocol stack. In this chapter,
we provide a quick overview of the state-of-theart work in providing solutions to various issues
in an opportunistic network.
reFerences
Asokan, N., Kostiainen, K., Ginzboorg, P., Ott, J.,
& Luo, C. (2007). Applicability of identity-based
cryptography for disruption-tolerant networking. In . Proceedings of MobiOpp, 07, 52–56.
doi:10.1145/1247694.1247705
Balasubramanian, A., Zhou, Y., Croft, B. W.,
Levine, B. N., & Venkataramani, A. (2007). Web
search from a bus. In Proceedings of the second
workshop on Challenged networks CHANTS
CHANTS ’07, (pp. 59–66).
Banerjee, N., Corner, M. D., & Levine, B. N.
(2007). An energy-efficient architecture for dtn
throwboxes. In . Proceedings of IEEE INFOCOM,
2007, 776–784.
Boneh, D., & Franklin, M. (2003). Identity based
encryption from the weil pairing. In SIAM Journal
of Computing, 586–615.
Brewer, E., Demmer, M., Du, B., Ho, M., Kam,
M., & Nedevschi, S. (2005). The case for technology in developing regions. IEEE Computer,
38, 25–38.
DTN Technologies for Vehicular Networks
Burgess, J., Gallagher, B., Jensen, D., & Levine,
B. N. (2006). Maxprop: Routing for vehicle-based
disruption-tolerant networks. In . Proceedings
of IEEE INFOCOM, 2006, 1–11. doi:10.1109/
INFOCOM.2006.228
Burns, B., Brock, O., & Levine, B. N. (2005). Mv
routing and capacity building in disruption tolerant networks. Proceedings of IEEE INFOCOM,
1, 398–408.
Chaintreau, A., Hui, P., Crowcroft, J., Diot, C.,
Gass, R., & Scott, J. (2005). Pocket switched networks: Real-world mobility and its consequences
for opportunistic forwarding. Technical report,
University of Cambridge Computer Laboratory,
Cambridge, UK.
Chen, Y., Zhao, W., Ammar, M., & Zegura, E.
(2007). Hybrid routing in clustered dtns with message ferrying. In Proceedings of the 1st international MobiSys workshop on Mobile opportunistic
networking MobiOpp ’07, (pp. 75–82).
Chuah, M., & Xi, Y. (2007). An encounter-based
multicast scheme for disruption tolerant networks.
Technical report published by the University of
Lehigh, Lehigh, PA.
Demers, A. A., Greene, D., Hauser, C., Irish, W.,
Larson, J., Shenker, S., et al. (1987). Epidemic
algorithms for replicated database maintenance. In
Proceedings of the Sixth Symposium on Principles
of Distributed Computing, (pp. 1–12).
Demmer, M., & Ott, J. (2006). Delay tolerant
networking tcp convergence layer protocol.
Internet-draft.
Fall, K. (2003). A delay-tolerant network architecture for challenged internets. In Proceedings
of ACM SIGCOMM, (pp. 27–34).
Farrell, S., & Cahill, V. (2005). Ltp-t: A generic
delay tolerant transport protocol. Technical report,
University of Dublin, Dublin.
Farrell, S., Ramadas, M., & Burleigh, S. (2007).
Licklider transmission protocol - extensions.
Internet-draft.
Freitag, L., Grund, M., Singh, S., Partan, J., Koski,
P., & Ball, K. (2005). The whoi micro-modem:
An acoustic communications and navigation
system for multiple platforms. In Proceedings of
the IEEE/MTS OCEANS Conference, Washington
DC, (Vol. 2, pp. 1086–1092).
Gong, Y., Xiong, Y., Zhang, Q., Zhang, Z., Wang,
W., & Xu, Z. (2006). Anycast routing in delay
tolerant networks. In IEEE GLOBECOM (pp.
1–5).
Grossglauser, M., & Tse, D. N. C. (2002). Mobility
increases the capacity of ad-hoc wireless networks.
In IEEE/ACM Transactions on Networking, 10(4),
477–486.
Hyyrylainen, T., Karkkainen, T., & Luo, C. (2007).
Opportunistic email distribution and access in
challenged heterogeneous environments. In Proceedings of the second workshop on Challenged
networks CHANTS (pp.97–100).
Interplanetary internet project (n.d.). Interplanetary internet project. Retrieved from http://www.
ipnsig.org
Ip, Y. K., Lau, W. C., & Yue, O. C. (2007). Forwarding and replication strategies for dtn with resource
constraints. In . Proceedings of IEEE Vehicular
Technology Conference, 1, 1260–1264.
Jain, S., Fall, K., & Patra, R. (2004). Routing in
a delay tolerant network. In Proceedings of ACM
SIGCOMM, (Vol. 34, pp. 145–158).
Jun, H., Ammar, M. H., Corner, M. D., & Zegura,
E. W. (2006). Hierarchical power management in
disruption tolerant networks with traffic-aware
optimization. In Proc. ACM SIGCOMM Workshop on Challenged Networks (CHANTS), (pp.
245–252).
267
DTN Technologies for Vehicular Networks
Jun, H., Ammar, M. H., & Zegura, E. W. (2005).
Power management in delay tolerant networks:
A framework and knowledge-based mechanisms.
In IEEE Communications Society Conference on
Sensor and Ad Hoc Communications and Networks
(SECON), (pp. 418–429, 2005).
Krotkov, E., & Blitch, J. (1999). The defense advanced research projects agency (darpa) tactical
mobile robotics program. In The International
Journal of Robotics Research (pp. 769–776).
LeBrun, J., Chuah, C.-N., Ghosal, D., & Zhang,
M. (2005). Knowledgebased opportunistic forwarding in vehicular wireless ad hoc networks.
In IEEE Vehicular Technology Conference (VTC),
(pp. 2289– 2293).
Leguay, J., Friedman, T., & Conan, V. (2006).
Evaluating mobility pattern space routing for
DTNs. In Proceedings of IEEE INFOCOM.
Lindgren, A., & Doria, A. (2007). Experiences
from deploying a reallife dtn system. In 2007 4th
IEEE Consumer Communications and Networking
Conference, (pp. 217–221).
Lindgren, A., Doria, A., & Schelen, O. (2003).
Probabilistic routing in intermittently connected
networks. ACM SIGMOBILE Mobile Computing and Communications Review, 7(3), 19–20.
doi:10.1145/961268.961272
Musolesi, M., Hailes, S., & Mascolo, C. (2005).
Adaptive routing for intermittently connected
mobile ad hoc networks. In IEEE WoWMoM 2005
(pp. 183–189).
Ott, J., & Kutscher, D. (2006). Bundling the web:
Http over dtn. In Proceeding of WNEPT2006.
Ramadas, M., Burleigh, S., & Farrell, S. (2007).
Licklider transmission protocol - specification.
Internet-draft.
268
Rodoplu, V., & Park, M. K. (2005). An energyefficient mac protocol for underwater wireless
acoustic networks. In Proceedings of the MTS/
IEEE OCEANS’05 Conference.
Scott, K. (2005). Disruption tolerant networking
proxies for on-the-move tactical networks. In IEEE
MILCOM 2005, (Vol. 5, pp. 3226–3231).
Scott, K., & Burleigh, S. (2007). Bundle protocol
specification. Internet- Draft.
Segui, J., & Jennings, E. (2006). Delay tolerant networking v bundle protocol simulation. In Second
IEEE International Conference on Space Mission
Challenges for Information Technology.
Seth, A., & Keshav, S. (2005). Practical security for
disconnected nodes. In Proceeding of Workshop
on Secure Network Protocols (pp. 31–36).
Spyropoulos, T., Psounis, K., & Raghavendra, C.
S. (2004). Single-copy routing in intermittently
connected mobile networks. In 2004 First Annual
IEEE Communications Society Conference on Sensor and Ad Hoc Communications and Networks,
(pp. 235 – 244).
Spyropoulos, T., Psounis, K., & Raghavendra,
C. S. (2005). Spray and wait: An efficient routing scheme for intermittently connected mobile
networks. In Proceeding of the 2005 ACM SIGCOMM workshop on Delay-tolerant networking
WDTN ’05, (pp. 252–259).
Symington, S., Farrell, S., Weiss, H., & Lovell,
P. (2007). Bundle security protocol specification.
Internet-draft.
Symington, S., Farrell, S., Weiss, H., & Lovell,
P. (2007). Delay-tolerant networking security
overview. Internet-draft.
Tan, K., Zhang, Q., & Zhu, W. (2003). Shortest path
routing in partially connected ad hoc networks.
In Proceedings of IEEE Globecom 2003, (Vol. 2,
pp. 1038–1042).
DTN Technologies for Vehicular Networks
Tariq, M. M. B., Ammar, M., & Zegura, E. (2006).
Message ferry route design for sparse ad hoc networks with mobile nodes. In Proceedings of the
seventh ACM international symposium on Mobile
ad hoc networking and computing MobiHoc ’06
(pp. 37–48).
The zebranet wildlife tracker. (2009). Retrieved
from http://www.princeton.edu/ mrm/zebranet.
html
Tier. (2009). Retrieved from http://tier.cs.berkeley.
edu/wiki/Home
Vahdat, V., & Becker, D. (2000). Epidemic routing
for partially connected ad hoc networks. Technical
Report CS-200006, Duke University.
Wills, J., Ye, W., & Heidemann, J. (2006). Lowpower acoustic modem for dense underwater
sensor networks. In Proceedings of the First ACM
International Workshop on UnderWater Networks
(WUWNet), Los Angeles, CA, (pp. 79–85). New
York: ACM. Retrieved from http://www.isi.edu/
ohnh/PAPERS/Wills06a.html
Wood, L., Eddy, W. M., Ivancic, W., McKim, J.,
& Jackson, C. (2007). Saratoga: a delay-tolerant
networking convergence layer with efficient link
utilization. In Proceeding of IWSSC’07.
Wood, L., McKim, J., Eddy, W., Ivancic, W., &
Jackson, C. (2008). Saratoga: a convergence layer
for delay-tolerant networking. Internet draft.
WWWOFFLE. (2009). Retrieved from http://
www.gedanken.demon.co.uk/wwwoffle/
Yang, P., & Chuah, M. C. (2006). Context-aware
multicast routing scheme for disruption tolerant
networks. In Proceedings of ACM international
workshop on PE-WASUN ’06 (pp. 66–73).
Ye, Q., Cheng, L., Chuah, M. C., & Davison, B. D.
(2006). Os-multicast: On-demand situation-aware
multicasting in disruption tolerant networks. In .
Proceedings of IEEE VTC, 1, 96–100.
Zhang, Z., & Fei, Z. (2007). Route design for
multiple ferries in delay tolerant networks. In
Proceedings of IEEE Wireless Communications
and Networking Conference (pp. 3460–3465).
Zhao, W., Ammar, M., & Zegura, E. (2004). A
message ferrying approach for data delivery in
sparse mobile ad hoc networks. In Proceedings of
the 5th ACM international symposium on Mobile
ad hoc networking and computing MobiHoc ’04
(pp. 187–198).
Zhao, W., Ammar, M., & Zegura, E. (2005).
Controlling the mobility of multiple data transport
ferries in delay-tolerant network. In . Proceedings
of IEEE INFOCOM, 2, 1407–1418.
Zhao, W., Ammar, M., & Zegura, E. (2005).
Multicasting in delay tolerant networks: Semantic
models and routing algorithms. In Proceeding of
Sigcomm Workshop in DTN, (pp. 268–275).
Wood, L., Peoples, C., Parr, G., Scotney, B., &
Moore, A. (2007). Tcps protocol radius:the distance where timers prevent communication. In
Proceeding of IWSSC’07.
269
Section 6
Management and Traffic Control
271
Chapter 16
Simple Transportation
Management Framework
Chyi-Ren Dow
Feng Chia University, Taiwan, R.O.C.
absTracT
The Simple Transportation Management Framework (STMF) specifies a set of rules and protocols which
can be used to organize, describe, and exchange transportation management information between transportation management applications and equipments. The STMF framework consists of four elements,
including Management Information Base (MIB), Structure and Identification of Management Information
(SMI), Simple Network Management Protocol (SNMP), and Simple Transportation Management Protocol
(STMP). MIB is a collection of management objects written in ASN.1 notation. SMI is the definition of
how to create management objects and a hierarchical definition of nodes where management objects will
be attached for unique identification. SNMP is a communications protocol for configuring and monitoring of network devices. STMP is a variation of SNMP to address low-bandwidth communication links
and real-time device monitoring.
inTroducTion
The STMF specifies a set of rules and protocols
which can be used to organize, describe and exchange transportation management information
between transportation management applications
and equipments. STMP is based on the Internetstandard Network Management Framework and
its purpose is to provide a high-level compatibility,
DOI: 10.4018/978-1-60566-840-6.ch016
inter-operability, and maintenance of STMF. The
STMF framework consists of the following four
elements. The brief definitions of these elements
are listed below and the detailed descriptions and
relationships of these elements will be given in the
following sections.
•
Management information base (MIB)
(Perkins et al., 1997): A collection of management objects written in ASN.1 (Abstract
Syntax Notation One) (Steedman et al.,
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Simple Transportation Management Framework
Figure 1. Relationships of SMI, MIB, and ASN.1
•
•
•
1993; ITU-T X.680-X.690, 1994) notation,
which is a standard and flexible notation
that describes data structures for representing, encoding, transmitting, and decoding
data.
Structure and identification of management information (SMI): The definition
of how to create management objects and
a hierarchical definition of nodes where
management objects will be attached for
unique identification.
Simple network management protocol
(SNMP) (Stallings et al., 1993; Stallings
et al., 1996; Feit et al., 1995): A communications protocol developed by the IETF
for configuring and monitoring of network
devices.
Simple transportation management protocol (STMP): A variation of SNMP developed by NEMA to address low-bandwidth
communication links and real-time device
monitoring. NEMA is the trade association
of choice for the electrical manufacturing
industry, and it provides a forum for the development of technical standards
relationships of smi,
mib, and asn.1
SMI describes the common structures and identification schemes for the definition of management
information. ASN.1 is used to specify SMI and it
can be compiled by MIB compilers. To do so, SMI
272
definitions (ASN.1 specifications) are included in
a MIB module. As shown in Figure 1, the difference is made because SMI defines how to create
managed objects and how to utilize ASN.1 in order
to create and identify management information
(MIB objects) within a tree-like structure. Management center uses Structure and Identification
of Management Information to define MIB, then
using BER or OER encoding scheme to generate
SNMP or STMP.
smi
Managed objects would be accessed via MIB and
objects in the MIB would be defined using ASN.1
which should be in conformance with IAB STD
16 (RFC 1212). Each object type would have a
name, syntax, and an encoding. The OBJECT
IDENTIFIER would represent a unique name. An
OBJECT IDENTIFIER should be administratively
assigned a name. The administrative policies discussed in RFC 1212 would be used for assigning
names and identifiers. When transmitted on the
network, the encoding of an object type determines
how its instances are represented.
Names
Names are used to identify managed objects.
This sub-clause specifies names that should be
hierarchical in nature. The OBJECT IDENTIFIER
concept is used to model this notion. OBJECT
IDENTIFIERs can be used to identify objects,
Simple Transportation Management Framework
Figure 2. nema of OBJECT IDENTIFIER
In this example, four nodes are assigned under
the nema node. The definitions are listed below.
•
•
•
•
nemaMgmt OBJECT IDENTIFIER::=
{nema 1}
nemaExperimental OBJECT
IDENTIFIER::= {nema 2}
nemaPrivate OBJECT IDENTIFIER::=
{nema 3}
transportation OBJECT IDENTIFIER::=
{nema 4}
SYNTAX
regardless of the semantics associated with the
object (e.g., a network object, a standards document, etc.).
An OBJECT IDENTIFIER is a sequence of
integers which can be used to traverse a global
tree. The tree consists of a root connected to a
number of labeled nodes via edge and each node
may have branches of its own that are labeled.
This process may continue to an arbitrary level
of depth. A label is a pairing of a brief textual
description and an integer. The format used to
show this pairing shall be text (integer).
The IAB has transferred authority for the nema
node to NEMA. As shown in Figure 2, the nema
node is defined below using the ASN.1 syntax.
nema OBJECT IDENTIFIER::=
{ iso(1) org(3) dod(6) internet(1) private(4)
enterprises(1) 1206 }
The SYNTAX is used to define the structure and
it is corresponding to object types. RFC 1155 can
be used to define this structure. The SYNTAX
type consists of primitive types and guidelines
for enumerated INTEGERs and constructor
types.16.1.2.3 Managed Objects
IAB STD 16 specifies a format to be used by
documents that defines objects. All objects would
be defined using the OBJECT-TYPE macro described in RFC 1212.
The OBJECT-TYPE macro definition contains
at least five fields, including object name, syntax,
access, status and description. Figure 3 shows an
example of managed object. The “Access” can be
read-only, read-write, write-only or no-accessible.
The “Status” can be mandatory, optional, obsolete,
or deprecated.
mib
The MIB version 2, published in RFC 1213 in
1991, steped up a number of useful variables
missing from MIB-I. It has four characteristics: the
first one is that has no relationship with network
management protocol (ITS Standards et al., 2003;
Aidarous et al., 1994). The second is each object
has a unique Object Identifier (OID). The third
is that defined by SMI. The final one records the
type and access limits of authority.
273
Simple Transportation Management Framework
Figure 3. ASN.1 Macro
As shown in Figure 4, the Object Naming
Tree is used to record all objects in MIB-II. If we
choose tcpConnState for instance, the location
of tcpConnState is iso(1)→ org(3)→ dod(6)→
internet(1)→ mang(2)→ mib-2(1)→ tcp(6)→ tcpConnTable(4)→ tcpConnState(1), so we can know
that the OID of tcpConnState is 1.3.6.2.1.6.4.1.
From Figure 4, we can also see some groups in
MIB-II, including system(1), interface(2), at(3),
ip(4), icmp(5), tcp(6), udp(7), egp(8), cmot(9)
and transmission(10).
Figure 4. Object naming tree
274
Transportation management protocol
Figure 5 shows the comparison of SNMP, STMP
and SFMP. The STMP is based on SNMP. Several
features are modified so that STMP can provide
more efficient operations. STMP can be used to
save bandwidth and offer all functions of SNMP
under the infrequent information demands. Thus,
STMP is the subset of SNMP and, the STMP managed system can also use SNMP to carry on the
communications. The major advantage of STMP
is that it uses an effective code method that is sup-
Simple Transportation Management Framework
Figure 5. Comparisons of SNMP, STMP and SFMP
ported by dynamic objects to reduce the overhead
of package. The user can also set any information object by herself/himself through dynamic
objects. Thus, STMP is the choice which is more
elasticity and saves more bandwidth. However,
compared with SNMP, it is much more difficult
in practice for STMP.
TMP allows three protocols to coexist while
using the same protocol identifier. This was
achieved as a result of the fact that all SNMP
messages start with an initial byte of 0x30 (e.g.,
SNMP uses Basic Encoding Rules and all SNMP
messages are defined as a SEQUENCE of data).
TMP has been designed to use the value of this
first byte to identify which protocol is being
referenced. 0x30 is a value which identifies an
SNMP message. Both SFMP and STMP messages
use the highest order four bits of the first byte to
determine the type of message (e.g., get request
and set request). The lowest order four bits are
used to identify whether the message is a fixed
message or one of the 13 dynamic objects. The
table in Figure 6 defines the specific mapping of
the first byte value.
snmp
IETF defined SNMP which is a part of the protocol
suite to describe the managed objects contained
in MIB. This simple protocol is used in network
management systems to monitor network-attached
devices for conditions that warrant administrative attention. It consists of a set of standards for
network management such as application layer
protocol, a database schema, and a set of MIB.
snmp architectural model
The SNMP architectural model is a collection of
network management stations and network elements. It consists of three key elements, including
Management stations, multiple network elements,
and Network Management Protocol.
A management station can perform management applications which monitor and control
network elements. Multiple network elements
are devices such as hosts, routers, and gateways
that contain agents to perform the network management functions requested by the network
management stations. The last, Simple Network
Management Protocol is used to exchange network
management information between the network
management stations and the agents.
The SNMP architectural model is shown in
Figure 7. The upper parts of the management
station and network elements are manager and
agents, respectively. The lower part is responsible
for the information exchange between management station and the different network elements.
Each component of SNMP is described in the
next section.
275
Simple Transportation Management Framework
Figure 6. Mapping of the first byte value
management components
There are four management components in SNMP,
including Manager, Agent, Network Protocol and
Management Information Base. The components
are described as follows:
276
•
•
Manager: Manager station that runs management applications to provide an interface. The network manager can monitor
and control the network by the interface.
Agent: The software that responds to request for information from the manager
station and according to the request from
manager station to act. Therefore, network
Simple Transportation Management Framework
Figure 7. SNMP Architectural Model
Figure 8. MIB architectural diagram
•
•
device should be equipped with agent software so that they can be managed from a
manager station.
Network management protocol: The
communication protocol between manager
stations and agents. It provides a standard
way to exchange information between
manager stations and agents.
Management information base: A collection of Manager Objects (MO) that are
managed in remote devices. As shown in
Figure 8, each MO is a data variable and
each agent is a network that maintains an
MIB. A manager action is either “monitor”
or “control”. To monitor resources in a remote device, we can read the value of MOs
in the MIB. In the MIB, we can modify the
values of MOs to “control” resources in a
remote device.
snmp service
SNMP provides four services and five SNMP
Protocol Data Units (PDUs). The four services
are Get, Set, GetNext and Trap. The five SNMP
PDUs are GetRequest, SetRequest, GetNextRe-
quest, GetResponse, and Trap. Figure 9 shows the
relationship between services and management
elements. Manager sends commands such as Get,
Set, GetRequest, SetRequest and GetNextRequest
to agents and then agent responds GetResponse.
If agent occurs error during runtime, agent application submits Trap to manager.
There are two versions of SNMP, including
SNMP v1 and SNMP v2. SNMP v2 provides more
services than SNMP v1.
SNMP v1
As shown in Figure 10, four services provided by
SNMP v1 are Get, Set, GetNext and Trap. Below
277
Simple Transportation Management Framework
Figure 9. Services of SNMP
Figure 10. SNMP v1 services
are detailed descriptions about the five SNMP
PDUs: GetRequest, SetRequest, GetNextRequest,
GetResponse, and Trap.
•
•
•
•
•
Get Request: Used to retrieve the values
of objects in the MIB of an agent.
Get-Next Request: Used to retrieve the
values of the next objects in the MIB of
an agent. The management station can use
this command through all MIB tree paths
to retrieve all variables.
Get Response: When an agent got Get
Request from manager, the agent responds
the value to manager.
Set Request: Used to set or modify the
values in the MIB of an agent.
Trap: Used to report extraordinary events
to the manager if an error occurs on the remote device.
Figure 11. SNMP packet
278
SNMP v2
There are two new services provided by SNMP v2:
GetBulk and Inform. Centers use GetBulk command to retrieve large amount of MIB objects data
while different devices use Inform command to
provide information to the management center.
snmp packet
As shown in Figure 11, the SNMP packet consists
of three fields: Version, Community Name and
Protocol Data Unit.
•
•
Version: The number of SNMP version
that is used by Manger and Agent. The “0”
is used to indicate SNMP v1. The “1” is
used to indicate SNMP v2.
Community name: It is the password of
SNMP. The Manager and Agent should
Simple Transportation Management Framework
Figure 12. PDU for GetRequest, GetNextRequest and SetRequest
•
use the same Community Name or else the
frame will be discarded.
Protocol data unit (PDU): It consists of
some data that would be used in communication such as Request ID, Error Status
and VarBindList.
PDU
As shown in Figure 12, the PDU for Get and Set
service has four fields, including Request ID, Error Status, Error Index and VarBindList and these
fields are described in detail as follows:
•
•
RequestID: An integer type is used as an
identification. It identifies different service actions in communication for SNMP
operation.
Error Status: Used to confirm whether this
PDU is correct. The value will be equal to
zero if this is a “Get-Request” command.
If this command is “Get-Response”, the
value of Error status will have six possible
values as shown in Table 1.
Error Index indicates that the index of VarBindList is wrong. The type of Error Index is integer. For the request from management, the values
of Error Status and Error Index will be 0.
VarBindList is a list that combines Variable
IDs and Variable Values. The architecture of
VarBindList is shown in Figure 13. The variable
ID field is an Object ID and the field of Variable
Value may be an integer, octstring or IP Address.
The Object ID and the type of Variable Value are
defined in MIB as mentioned in MIB earlier in
the chapter.
SNMP Trap PDU
The Trap command is submitted from agent. The
architecture of Trap PDU is shown in Figure 14.
The Trap PDU consists of six fields, including
Enterprise, Agent Address, Generic Trap Number, Specific Trap Number, Time Stamp and
VarBindList. The detailed descriptions of the six
fields are as follows:
•
•
Table 1. Values of error status and its meaning
Value of Error Status
Meaning
0
No Error
1
PDU has too many bytes
2
There is no object with this name
3
Identifying the PDU type is bad
4
Incorrect implementation of SNMP
5
Unspecified errors of other types
•
•
•
Enterprise: Type of object generating
trap.
Agent address: Address of object generating trap.
Generic trap number: Using integer to
represent seven Trap types defined in RFC
1157.
Specific trap number: The specific Trap
type defined by enterprise.
Time stamp: Time elapsed between the
last initialization of the network entity and
the generation of the trap.
279
Simple Transportation Management Framework
Figure 13. VarBindList
Set-Request Command
Set command writes MIB object value. For example, if we have to change the system description
(sysDescr), the command can be set as below:
•
VarBindList: Specific or all information that can be used to solve this trap
problem.
Get-Request Command
SNMP uses index object to select column. The
index object of ipRouteTable is the ipRouteDestination and the entity of ipRouteNextHop is
1.3.6.1.2.1.4.21.1.7.10.3.4.5.
While using SNMP command interface, the
Get-Request command should be inserted as
below:
•
•
Get-Request(1.3.6.1.2.1.4.21.1.7.10.3.4.5)
or
Get-Request(ipRouteNextHop.10.3.4.5)
Get-Next-Request Command
GetRequest command is used to request one object of a device per time. Thus, to request all of
the devices, Get-Next_Request can be used. The
command can be inserted as below:
•
•
Get-Next-Request
(1.3.6.1.2.1.4.21.1.7.10.3.4.5)or
Get-Next-Request
(ipRouteNextHop.10.3.4.5)
Figure 14. SNMP trap PDU
280
Set-Request (sysDescr = name)
Set-Request command in SNMP can be used to
add or delete rows of table. The result of the SetRequest is related to the real implementation.
SNMP Example
Figure 15 shows a SNMP example of a traffic
light controller. The center gets the remaining
time from the traffic light controller. MIB can only
send a request each time. While the traffic center
requests information from the controller, the traffic controller will request a DeviceNum from the
center. Then, the center will send TimePhaseNum
to the controller and wait for response.
The traffic center can request MaxGreenTime, MinGreenTime, YellowTime, GreenTime,
RedTime from the traffic light controller. Each
request will get a response from the controller in
the same way.
sTmp
This section introduces the Simple Transportation Management Protocol and the comparison
between Simple Transportation Management
Protocol and Simple Network Management
Protocol. STMP is based on SNMP and supports
dynamic object that is a group of data elements.
Simple Transportation Management Framework
Figure 15 Example of a traffic light controller
Besides, it also supports PMPP defined in the sub
network of NTCIP.
dynamic object
Dynamic object is a simple grouping of data elements. It consists of a set of related MIB objects.
For example, object name, object phase, and
object time value are dynamic objects of the time
controller of a traffic light. These three objects are
related to each other.
Between management station and the agent,
dynamic object increases control flexibility. A
dynamic object can combine all related objects
into a set. Thus, different tasks can be done easier
using a dynamic object.
To reduce the need of bandwidth during the
transformation, dynamic object is defined at run
time. It is an effective way for the management
station to communicate with different agents.
However, dynamic object can only access using
the STMP protocol.
Dynamic Object Configuration Table
Dynamic object configuration table consists of
three elements: dynObjNumber, dynObjConfigOwner, and dynObjConfigStatus.
The dynObjNumber provides a number for
the frequently used dynamic objects. The main
purpose of the dynObjNumber is to identify which
of the 13 dynamic objects this row of the table
is associated.
Each dynamic object has an owner. Therefore, dynObjConfigOwner is used to indicate the
identity of the owner that defined the dynamic
object.
Dynamic object records status of each managed
objects. Thus, dynObjStatus is used to indicate
the status of the dynamic object.
Table 2 depicts the composite table for dynamic
object configuration and definition. The table includes the three dynamic object (dynObjNumber,
dynObjConfigOwner, and dynObjConfigStatus),
dynObjIndex, and dynObjVariable.
281
Simple Transportation Management Framework
Table 2. Composition table for dynamic object
dynObjNumber
dynObjConfigOwner
1
<Owner of Dynamic Object #1>
dynObjConfigStatus
<Status of Dynamic Object
#1>
2
<Owner of Dynamic Object #2>
<Status of Dynamic Object
#2>
3
<Owner of Dynamic Object #3>
<Status of Dynamic Object
#3>
…
…
13
<Owner of Dynamic Object #13>
…
<Status of Dynamic Object
#13>
The dynamic object is the combination of
managed objects. Each dynamic object is given
an index to represent the sequence of the objects.
The dynObjIndex column indicates the index of
the dynamic objects.
The dynamic object method treats all frequently
used related objects as a set of dynamic objects.
282
dynObjIndex
dynObjVariable
1
<OID of 1st object in
dynObj 1>
2
<OID of 2nd object in
dynObj 1>
3
<OID of 3rd object in
dynObj 1>
…
…
255
<OID of 255th object in
dynObj 1>
1
<OID of 1st object in
dynObj 2>
2
<OID of 2nd object in
dynObj 2>
3
<OID of 3rd object in
dynObj 2>
…
…
255
<OID of 255th object in
dynObj 2>
1
<OID of 1st object in
dynObj 3>
2
<OID of 2nd object in
dynObj 3>
3
<OID of 3rd object in
dynObj 3>
…
…
255
<OID of 255th object in
dynObj 3>
…
…
1
<OID of 1st object in
dynObj 13>
2
<OID of 2nd object in
dynObj 13>
3
<OID of 3rd object in
dynObj 13>
…
…
255
<OID of 255th obj dynObj 13>
Objects in the set have already defined in the ISO
naming tree. Thus, dynObjVariable records each
managed object’s OID, which is the location of
the managed object in the ISO naming tree.
Simple Transportation Management Framework
Dynamic Objects and System Operation
STMP supports 13 dynamic objects for each
agent. With a different set of dynamic objects, the
management station could configure each device.
In practice, most management stations are likely
to configure similar devices with similar dynamic
object definitions.
State Transition for dynObjConfigStatus
Table 3 shows the state transition for dynObjConfigStatus. If no action takes place and response
indicates no Error. When the state changes to
invalid, all entries associated with the ConfigEntryStatus object are deleted or cleared and
response indicates no error.
If no action takes place but response indicates
badValue. If Dynamic Object Validation succeeds
then state changes to valid and response indicates
no error. If Dynamic Object Validation fails then
state remains underCreation and response indicates genErr. The state changes to underCreation
and the response indicates no error.
Set Request-No Reply is similar to Set Request,
but the device will not return any response after
the request is sent.
Get Response and Set Response are used to
response to get and set requests command from
centers. Trap Response is to inform the centers
that some situations occurred on a device.
Get Error Response will response to the
centers that get request command is failed. Set
Error Response will response to the centers that
set request command is failed.
STMP PDU Field
Figure 16 shows the STMP PDU fields. There are
four fields in the STMP PDU: PDU format, message type, object ID and information field.
The PDU Format is 0 or 1 (bit 7). If PDU
format is “1”, it represents the STMP service. If
the data is “0”, it represents a SNMP service or
it might be reserved for future use.
Message type and object ID are header fields.
Message type is represented by bits 6-4. It indicates the STMP service. Below are functions of
different message types:
STMP Service
•
Services provided by STMP are Get Request, Set
Request, and Set Request-No Reply. The service
responses are Get Response, Set Response, Trap
Response, Get Error Response, and Set Error
Response.
Get Request is to get an object’s information.
Set Request is used to set an objects information.
•
•
•
000: An STMP-GetRequest-PDU is contained in the packet.
001: An STMP-SetRequest-PDU is contained in the packet.
010: An STMP-SetRequest-NoReply-PDU
is contained in the packet.
011: An STMP-GetNextRequest-PDU is
contained in the packet.
Table 3. State Transition for dynObjConfigStatus
Requested State
Invalid
Current State
Invalid
UnderCreation
Valid
Invalid (1)
UnderCreation (2)
Invalid (3)
UnderCreation
Invalid (2)
UnderCreation (3)
Valid (2) or
underCreation
Valid
Invalid (2)
Valid (3)
Valid (1)
283
Simple Transportation Management Framework
Figure 16. PDU field
•
•
•
•
100: An STMP-GetResponse-PDU is contained in the packet.
101: An STMP-SetResponse-PDU is contained in the packet.
110: An STMP-ErrorResponse-PDU is
contained in the packet.
111: Reserved by TMP for future use.
The object ID carries the ID of the object. It
is represented by bits 3-0. Below are descriptions
about the data of object ID:
•
0000: Reserved by TMP for SFMP.
Figure 17.Configuring time dynamic object
284
•
•
•
0001-1101: ID of STMP 13 dynamic
objects
1110: Reserved by TMP for future use.
1111: Reserved by TMP for future use.
The information field contains information that
has to send between the server and the agent. It
would be empty for STMP-GetRequest, STMPGetNextRequest, and STMP-SetResponse. The
PDU Information field for STMP-GetResponse,
STMP-SetRequest, and STMPSetRequestNoReply would consist of a series of component fields,
each encoding one Referenced Object. Besides,
Simple Transportation Management Framework
the component fields would be encoded in order.
It is according to the associated dynObjIndex,
with the first field encoding the value of the first
Referenced Object of the Dynamic Object, and the
last field encoding the value of the last Referenced
Object of the dynamic object.
Examples
The examples in the following will provide more
detailed explanation about the STMP and the
dynamic objects.
Example: Configuration
Time Dynamic Object
Before using STMP to transfer object, we should
set Dynamic Object Configuration Table. For
example, we configure the third object as Time
object. As shown in Figure 17, we should set the
third object is “invalid” first, and then we set it as
“underCreation”. Now we just can set the property
of dynamic object as the following:
•
•
Set the owner of this dynamic object to
“FCU”.
Set the variables of the dynamic object with
MIB object. In this example, the dynamic
object includes “GlobalTime” object as
variable 3.1 and “GlobalDayLightSaving”
•
object as variable 3.2 and so on. This can
be shown in Figure 17.
Finally, set this dynamic object to “valid”.
Now we can use this dynamic object to
transfer data.
Example: Getting a Dynamic Object
After finishing the setting of dynamic object, we
can use this dynamic object to transfer data with
services such as “request” service. To continue
above example, we are going to discuss the details
of STMP PDU with request command. As shown in
Figure 18, we can see the actual content of STMP
“GetRequest” and “GetResponse” PDU.
In the Information fields, there are four variables that we set in above example. They are
presented as the following:
•
•
•
•
3A 24 63 20 variable 1 = globalTime.0 =
November 29, 2000 at 2:00 am UTC
03 variable 2 = globalDaylightSaving.0 =
3 = enableUSDST
FF FF B9 B0 variable 3 = controller-standardTimeZone.0 = -18000 = EST
06 53 61 6D 70 6C 65 variable 4 = eventClassDescription.1 (6 bytes) = “Sample”
Figure 18. Actual content of STMP PDU
285
Simple Transportation Management Framework
Application Level: STMP
Figure 19 shows an example of configuring traffic
light controller of dynamic object. First, the traffic
center sends a request to the traffic light controller.
The request demands the traffic light controller
to set the dynObjConfigStatus as “invalid”. The
center sends another request to the controller to
set the dynObjConfigStatus as “underCreation”
when the traffic center gets response from the
traffic light controller. The dynamic object can
be set after the dynObjConfigStatus is set as
“underCreation”.
The traffic center starts setting the dynamic
objects (e.g., dynObjConfigOwner and dynObjVariable) when the traffic light controller sends
a response. After all dynamic objects are set; the
traffic center has to set the dynObjConfigStatus
as “valid”. Finally, setting the dynamic objects
has done.
After the setting of dynamic object is finished,
we can use it to actual applications. An applica-
Figure 19. Example of configuring traffic light controller of dynamic object
Figure 20. Application for traffic light using dynamic object
286
Simple Transportation Management Framework
Figure 21. Comparisons between SNMP and
STMP
tion for traffic light is shown in Figure 20. This
application uses dynamic object to control traffic
light. Figure 20 shows the traffic center submits a
get request to the traffic light controller and then
the traffic light controller returns the value of
traffic light. In Figure 20, the “dynObjVariable”
word is the object number of dynamic object. The
traffic center uses getRequest service with object
number to request the value of traffic light; the
traffic light controller would then responses to the
traffic center with “getResponse” command.
As shown in Figure 21, the difference between SNMP and STMP package is that SNMP
has Version number and Community Name as a
password.
Because SNMP uses more bandwidth than
STMP. SNMP can be used in the environment
that has weak probability of controlling object
and high network bandwidth. In comparison with
SNMP, STMP uses dynamic objects to reduce the
data transfer and efficiently use bandwidth.
Therefore, STMP can be used in the environment and it has low network bandwidth and
frequent control of object value.
In summary, SNMP is simple and easy to implement. STMP uses Dynamic Composite Objects so
that STMP uses bandwidth efficiently.
aTms system for sTmp
The Advanced Traffic Management System
(ATMS) (National Highway Institute, 2001) is
based on an open architecture. It uses the latest ITS
technologies to provide real-time transportation
system control, monitoring, and information.
ATMS can detect the traffic situation and
transport to traffic control center by the Internet
(Rose et al., 1990). It can collect and manage
Figure 22. Operation process between message set and data dictionary
287
Simple Transportation Management Framework
Table 4.
ParameterType
Type
Length
(byte)
MessageType
ObjectName
ObjectID
Range
globalDeviceSysTime
globalDeviceSysTime
ROCYear
DeviceROCYear
Integer
1
0~99
Month
deviceMonth.0
Integer
1
1~12
Day
deviceDay.0
Integer
1
1~31
Wekday
deviceWeekday.0
Integer
1
1~7
Hur
deviceHour.0
Integer
1
0~23
Config
Search
Search
Response
Activily
Response
12H
0F+12
2BH
0F+42
14H
0F+C2
0F+02
0F+41
0F+C1
Minute
deviceMinute.0
Integer
1
0~60
Second
deviceSecond.0
Integer
1
0~60
DeviceState
globalDeviceState
HWReset
deviceHWReset.0
Constant
1
1
10H
0F+10
CommReset
deviceCommReset.0
Constant
1
1
11h
0F+11
LoopTestParameter
deviceLoopTest.0
Integer
32
0~255
2CH
0F+47
2CH
0F+47
2EH
0F+C7
DbLockState
deviceDbLockState.0
Integer
1
0~2
21H
0F+16
0F+46
0F+C6
EquipmentId
deviceEquipmentId.0
Integer
2
0~ffh
18H
0F+40
29H
0F+C0
Password
devicePassword.0
Char
6
ASCII
0F+45
0F+C5
DeviceEvent
globalDeviceEvent
RestartEvent
deviceRestartEvent
RestartMonth
deviceRestartMonth.0
Integer
RestartDay
deviceRestatDay.0
Integer
1EH
0F+00
traffic situation to improve traffic efficiency and
safety.
The major services of ATMS consist of Network Surveillance, Probe Surveillance, Surface
Street Control, Freeway Control, HOV Lane
Management, Traffic Information Dissemination,
Regional Traffic Control, Incident Management
System, Traffic Forecast and Demand Management, Electronic Toll Collection, Emissions
Monitoring and Management, Virtual TMC and
Smart Probe Data, Parking Facility Management,
288
1FH
0F+15
1
1~12
1~31
Reversible Lane Management, and Road Weather
Information System.
ATMS Data Dictionary
Figure 22 shows the operation process between
message set (IEEE Std 1488- 1999, 2000) and
data dictionary (IEEE Std 1489-1999, 1999). It
is based on Open Systems Interconnection (OSI)
communication protocol and supplies the common
data format defined between applications. It can
ensure the communication of systems. The OSI
Simple Transportation Management Framework
Reference Model is an abstract description for
layered communications and computer network
protocol design. It was developed as part of the
OSI initiative. As shown below, in its most basic
form, it divides network architecture into seven
layers which, from top to bottom, are the Application, Presentation, Session, Transport, Network,
Data-Link, and Physical Layers.
ATMS C2F Level Definition
C2F uses the communication protocol standard
of SNMP and STMP. The messages must be defined as data objects and dynamic objects based
on ASN.1.
Example of Global Object Definition
Using global object can setup time, database status
on devices, for example, devices could be setup
month, day, weekday, hour, minute, and second.
reFerences
Aidarous, S., & Plevyak, T. (1994). Telecommunications Network Management into the 21st
Century. New York: IEEE Press.
Perkins, D., & McGinnis, E. (1997). Understanding SNMP MIBS. Upper Saddle River, NJ: Prentice
Hall, Inc.
Rose, M. T. (1990). The Open Book: A Practical
Perspective on OSI. Upper Saddle River, NJ:
Prentice Hall, Inc.
Stallings, W. (1993). SNMP, SNMPv2 and CMIP
The Practical Guide to Network Management
Standards. Reading, MA: Addison-Wesley Publishing Company, Inc.
Stallings, W. (1996). SNMP, SNMPv2 and RMON.
Reading, MA: Addision-Wesley Publishing
Company, Inc.
NTCIP Standard 1103 (2005). TS 3.2-1996 NTCIP
Simple Transportation Management Framework
- Amendment 1.
ITS Standards Outreach, Education and Training
Program, Institute of Transportation Engineers
Management and Operations of Intelligent
Transportation Systems (2003). ITS Standards
Overview.
IEEE Std 1489-1999 (1999). IEEE Standard for
Data Dictionaries for Intelligent Transportation
Systems.
Feit, S. (1995). SNMP: A Guide To Network Management. New York: McGraw Hill, Inc.
IEEE Std 1488-1999 (2000). IEEE Standard for
Message Set Template for Intelligent Transportation Systems.
ITU-T X.680-X.690 (1994). ISO/IEC 8824: Abstract Syntax Notation One (ASN.1).
Steedman, D. (1993). ASN.1: The Tutorial & Reference. London: Technology Appraisals Ltd.
National Highway Institute (2001). Using the
National ITS Architecture for Deployment.
289
290
Chapter 17
Vehicular System
Management Architecture
and Application Platform
Teng-Wen Chang
National Taiwan University of Science and Technology, Taiwan, R.O.C.
Jiann-Liang Chen
National Taiwan University of Science and Technology, Taiwan, R.O.C.
absTracT
Notably, not all telematics services can be used in telematics terminals as a result of the varied platform
standards. The main issues are that most telematics technologies depend on vertical, proprietary and
closed per-OEM Original Equipment Manufacture (OEM) platforms, forming islands of non-interoperable technology and preventing third-party service providers from creating valuable services. In
this study, the Open Gateway Service Initiative Vehicle Expert Group (OSGi/VEG) was integrated into
an Android platform to generate a vehicular Android/OSGi platform that has the advantages of both
original platforms, such as remote management, rich class sharing, proprietary vehicular applications,
security policies, easy management of application programming interface (APIs), and an environment
with increased openness. Furthermore, this study integrates the cloud computing mechanism into the
Android/OSGi platform, which allows service providers to upload their telematics bundles onto storage
clouds via the provisioning server.
inTroducTion
Over the past few years, with the enormous market potentials of telematics industry and the rapid
development information technology, automotive
telematics has been a booming area and indispensable technology, additionally, it also become a hot
R&D area in mobile computing and ITS (Intelligent
DOI: 10.4018/978-1-60566-840-6.ch017
Transport Systems). Telematics is the convergence
of telecommunications and information processing
for automation in cars. So far, quite a number of
telematics services have been developed by automakers and third-party service providers, such as
monitoring, emergency roadside assistance, navigation, diver aids, remote diagnostics, entertainment,
web browsing, and so on. But not all of telematics
services can be deployed into telematics terminal
as a result of various standards of platforms. Be-
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Vehicular System Management Architecture and Application Platform
sides, the telematics market is immature now.
The main critical issues are most of telematics
technologies depend on the vertical, proprietary
and closed per-OEM platforms, forming islands
of no-interoperable technology and preventing
third-party service providers from creating value
added services. Consequently, numerous vehicle
groups have been some working in establishing
and developing open/standard embedded platforms for vehicles, these platforms contain OSGi/
VEG, AUTOSAR, AMI-C, CVIS, OSEK/VDX,
Android, and so on.
Figure 1 illustrates the open Linux operating
system is ported into embedded on-board terminal, which not only provides a variety of device
drivers such as CAN\LIN\FlexRay car buses, outnetworks connection modules and so on, and also
offers resources management. The open/standard
telematics platforms in telematics middleware
layer mainly standardize telematics API’s and
graphic/vocal HMI (human-machine interface), so
that both service providers and car manufacturers
can quickly deliver solutions on time to potential
market and to simplify complexity of development.
Besides, if service providers want to remotely
deploy telematics services to on-board terminal,
or road-side centers need to diagnose the situations
of vehicular devices or set-up configurations of
telematics applications in terminal, they should
use remote management services rely on open/
standard telematics platforms.
Telematics applications can be divided into
four categories, including VANET embedded
system, vehicular multimedia embedded system,
intelligent driver aids embedded system, and Urban Nomadic/Pedestrians Telematics embedded
system. The first part of VANET system which
makes vehicle can communicate with other vehicles or road-side units via DSRC/IEEE 1609,
for example if at front of vehicle have accident,
it would broadcast emergent message to back
vehicles based on VANET embedded system. The
second part of multimedia system which makes
drivers can be able to watch DVB programs, play
on-line games, surveillance home conditions, and
so on. The multimedia embedded system should
take advantages of high-performance graphic SoC
or 3D engines when it performed complicated
operations. The three part of driver aids system
which ensures security of drivers, economizes the
use of power and so on. The final part of Urban
Nomadic/Pedestrians Telematics system which
provides interactive services between users and
service providers in non-automotive environment,
for example how to find neighbor locations of
filling stations in urban. The rest of available
telematics scenario is that vehicular drivers can
download/upload or share information to telematics information platforms in Web servers based
on out-networks connection capability.
In this chapter, we will introduce how to combine OSGi/VEG into Android platform, making
new vehicular Android/OSGi platform has both
advantages of original platforms, such as remote
management/deployment, rich class-sharing,
proprietary vehicular applications, security policies, and so on.
relaTed works
google android open platform
Overview of Android Platform
The Android™ delivers a complete set of software
for mobile devices: an operating system, middleware and key mobile applications. The Windows
Mobile and Apple’s iPhone now provide a richer,
simplified development environment for mobile
applications. However, unlike Android, they’re
built on proprietary operating systems that often
prioritize native applications over those created
by third parties and restrict communication among
applications and native data. Android offers new
possibilities for mobile applications by offering
an open development environment built on an
open source Linux kernel. Real hardware can be
291
Vehicular System Management Architecture and Application Platform
Figure 1. Telematics architecuture
accessed through series of standard API libraries, such as to manage the Wi-Fi, Bluetooth, and
GPS devices. As Figure 2 illustrates the Open
Mobile Alliance (OHA) and Google had supported
Android platform, and hope to reach the goal of
ensuring global mobile services to interoperability
across devices, geographies, service providers,
operators, and networks.
At this stage, Google had released the open
source of Android platform, providing the opportunity to create new adaptive mobile platform
interfaces and applications designed to look, feel
and function exactly as our imagination. Consequently, the Android platform had been ported
in mobile devices, such as notebook, PDA, and
automotive system in recently. In automotive
system fields, the Intel and Wind River Systems companies are actively working on getting
Android-powered infotainment operating system
integrated into vehicles.
in runtime, and native or third-party applications
in application layer. The Android software stack
components are as follows:
•
•
Android Software Stack
The Figure 3 illustrates the Android software
stack, which composed of Linux kernel, a collection of Android libraries, application framework
that provides management of android application
292
•
Linux kernel: Core services (including device hardware drivers, process and memory
management, security, network, and power
management) are managed by a Linux 2.6
kernel. The kernel also provides an abstraction layer between the hardware and the rest
of the stack.
Libraries Running on top of the kernel,
Android includes various C/C++ core libraries such as libc and SSL, as well as:
◦
A media library for playing multimedia resources.
◦
A Surface manager to provide display
management
◦
Graphics libraries that include SGL
and OpenGL for 2D and 3D graphics
◦
SQLite for data storage
◦
SSL and WebKit for integrated web
browser and Internet security
Android runtime: Including the core libraries and the Dalvik virtual machine, the
Android runtime is the runtime environment
for android application to be run in normal.
Vehicular System Management Architecture and Application Platform
Figure 2. Open environment for android platform
•
Core libraries: While Android development is done in Java/C++, Dalvik is not a
standardized Java VM. The core Android
libraries provide most of the functionality
•
available in the core Java libraries as well
as the Android-specific libraries.
Dalvik virtual machine: Dalvik is a
register-based virtual machine that’s been
Figure 3. Architecture of android software stack
293
Vehicular System Management Architecture and Application Platform
•
•
optimized to ensure that devices run multiple instances efficiently and stable. It relies
on the Linux kernel for threading and lowlevel memory/process management.
Application framework: The application framework provides the classes used
to create Android applications. It also provides a generic abstraction for hardware
access and manages the user interface and
application resources.
Application layer: All applications, both
native and third party, are built on the application layer using the same API libraries. The application layer runs within the
Android runtime using the classes and services made available from the application
framework.
Features of Android Platform
The unique features which other mobile platforms
don’t own as follows:
•
•
•
Figure 4. Location-based services for android
platform
•
•
294
Google
map
of
navigation
applications:Figure 4 illustrates Android
platform provides the MapView widget lets
navigation display, manipulate, and annotate a Google Map within your Activities
to build map-based applications using the
familiar Google Maps interface.
Background service and applications:
Background services let android applications that use an event-driven model,
working silently while other applications
are being used and in foreground.
All applications are created equal:
Android does not differentiate between the
core applications and third-party applications. They can all be built to have equal
access to a platform’s capabilities providing users with a broad spectrum of applications and services.
P2P interdevice application messaging:
Android offers peer-to-peer messaging
mechanism that supports presence, instant
messaging, and inter-device/inter-application communication.
Breaking down application boundaries:
Android breaks down the barriers to building new and innovative applications. The
user can combine information from web to
his/her individual’s Android platform, such
as the user’s contacts, calendar, or geographic location to provide a more relevant
user experience. Besides, all of the thirdparty applications can be downloaded to
user’s Android platform from Android
Market on free.
Vehicular System Management Architecture and Application Platform
open services gateway initiative
(osgi) service platform
Overview of OSGi Framework
The OSGiTM specifications define a standardized,
components-oriented, computing environment for
networked services that is the foundation of an
enhanced service-oriented architecture (SOA).
Besides, the OSGi specifications were initially
targeted at residential internet gateway with home
automation applications (Lee et al., 2003; Myoung
et al., 2005); however, the OSGi features of the
standard and extensible that making enterprise
to regard OSGi technology as key solutions. For
example, Nokia and Motorola drove the OSGi
technology standard for the next generation of
smart phone, and the vehicle industry adopted the
OSGi specifications by embedding them into the
global system for telematics (GST) specifications,
which is supported by many car manufactures.
The OSGi framework provides general-purpose,
secure support for deploying extensible and down-
loadable java-based service applications known as
bundles. OSGi bundles are applications packaged
in a standard Java Archive (JAR) file, containing
a manifest file that describes the relationships
among bundles and OSGi framework, a series of
compiled Java classes, and native code. Figure
5 illustrate the OSGi framework run on top of a
Java virtual machine, and the framework provides
a shared execution environment that installs, updates, and uninstall bundles dynamically without
restarting the system.
OSGi-Based Telematics Gateway
The OSGi Alliance whitepaper had pointed out
that the research and development of OSGi have
extended to any networked environment, such
as automobile, which provided some complex
embedded devices and the requirement of deployable services for those devices. The OSGi
framework make it possible to access, download
and use services in automotive mobile environment, creating an enormous potential for automo-
Figure 5. Architecture of OSGi framework
295
Vehicular System Management Architecture and Application Platform
tive manufacturers and service providers to offer
new proactive services to drivers and passengers
(Gun et al., 2001). The open standard-based,
service-oriented automotive infrastructure for the
telematics architecture(Li et al., 2005; Zhang et
al., 2004), including OSGi gateway, service infrastructure and self-automobile. The central control
point of the service infrastructure, which is the
OSGi-based telematics gateway, can be interconnected with various internal and external networks
and buses. It acts as the execution environment
for mobile automotive services. The following
bundles provide great deal of critical services for
OSGi-based telematics gateway:
•
•
•
296
Monitoring bundle: It is the one of basic
intelligent vehicle functions. Though monitoring state and performance of local vehicle devices, driver can acquire information
about vehicles, such as temperature, and
pressure of types, engine levels, etc.
Navigation bundle: It can provide navigation system that offers navigational assistance to drivers. The system receives
GPS position information signals which
are processed to determine current position
latitude and longitude coordinates, moreover the direction of travel.
Communication bundle: It can provide
OSGi-based telematics gateway to connect
with in-vehicle or out-vehicle network.
Besides, this bundle can make OSGi-based
gateway to be extended its functionality
by remote deployment of OSGi bundles
that service provider provided. Through
CAN, LIN or MOST(Zhou et al., 2006),
the OSGi-based telematics gateway realizes local area connection among in-vehicle
devices, and by using GPRS, GSM or even
special ITS FM channels, it realizes wide
area connection among vehicles, home
gateway, remote service center, and roadside systems.
•
•
•
Driver aid bundle: It can provide driver assistance for vehicles, and offering
some warning message to driver by lane
recognition.
Diagnostics bundle: It can provide remote
diagnostic services, and complicated diagnostic information also can be analyzed and
stored in remote systems, in this technique
is similar with MYCAREVENT project
(Weiss et al., 2006), making the telematics
gateway to have the capacities of automatic repair and self-management.
Information/entertainment
bundle:
At present, video and audio equipments
have been widely applied in vehicles.
Consequently, existence of researches that
will shift to provide an infotainment server
system for the in-vehicle users such that
the network-enabled information appliances (IA) can access the information and
perform the entertainment services from
infotainment server (Hsu et al., 2005).
The automotive operating system is also more
significant to the vehicles (Ai et al., 2007), by
supporting specific device drivers such as CAN/
LIN buses, which is used to communicate to other
electronic control units (ECU) nodes for diagnostic
purpose, consequently existence of researches that
embedded OSGi platform to the vASOS automotive operating system (Sun et al., 2007). Figure 6
illustrates the OSGi-based middleware run on top
of the K virtual machine (KVM), which is a compact, portable Java virtual machine intended for
small, resource-constrained devices. In addition,
those researches choose OSGi R3 implementation
of Oscar, to develop its application bundles, such
as navigation and CAN/LIN/MOST access bundle.
In our studies, we had took advantage of OSGi
R4 implementation of Apache Felix to integrate
with Google Android platform, making a variety
of Google APIs to turn into OSGi bundles, such as
location-based, peer-to-peer communications, and
Vehicular System Management Architecture and Application Platform
Figure 6. Architecture of vASOS and OSGi-based middleware for vehicles
network manager, etc. Not only supplying service
providers to deploy its telematics services, but also
enhancing Android runtime layer performance and
remote management functionality.
The goal of the Vehicle Expert Group (VEG)
is to tailor and extend the OSGi specification in
order to meet vehicle-specific requirements. To
achieve this, the VEG will define a list of topics
that cover vehicle-specific issues. Together with
the automotive industries, the VEG will specify
corresponding telematics API’s, so that both service provider and car manufacturers can quickly
deliver solutions on time to market and to increase
customer loyalty. The OSGi-VEG organization
has the following automotive projects:
•
3GT: The 3GT project is to help establish
OSGi-based in-vehicle telematics platforms on the European mass market by ensuring interoperability between the products of different middleware providers,
terminal manufacturers and service providers. This will be done by establishing common telematics interfaces for OSGi-based
•
•
service delivery. More specifically, 3GT
will develop OSGi-based specifications for
the interface between vehicles and control
centers as well as for the interface between
control centers and service providers.
ITEA EAST EEA: This automotive project is funded by the European Union and
consists of major European automotive
manufacturers, first-tier suppliers and research departments. The goal of EASTEEA is to enable hardware and software
interoperability of in-vehicle ECU nodes
through definition of an open, middlewarebased architecture.
Stadtinfokoeln: Stadtinfokoeln is a
Cologne-based project, funded by the
German Ministry of Education and Science
(BMBF), and focused on the delivery of
parking services to the inhabitants or visitors of Cologne, Germany. The goal is to satisfy customer demand and to reduce traffic,
which is related to the availability of parking space. An important role for this is the
rapid development of the information and
297
Vehicular System Management Architecture and Application Platform
•
Communication-Technology in the mobile
environment. To fulfill all requirements the
decision was made to use an OSGi service
platform framework on the vehicle platform. This enables the rapid development
and deployment of new services.
TOP-IQ: The Eureka-project TOP-IQ
(Hackbarth, 2003) focuses on the development of a new generation of on-board computers (OBC) for luxury cars and trucks.
The OBC facilitates telematics services for
transport, logistics, offers the management,
billing, and delivery of new services such
as online navigation, trailer management/
tracking and tracing of cargo, etc.
Safe Deployment of OSGi Bundles
The Security of deployment vehicular services is
crucial issues in telematics environment, supposing vehicle owners would like to install third-party
applications to their on-board vehicle system, but
if those vehicular applications have many bugs,
such as sending mass messages, accessing the
security sensitive parts of vehicles, and causing
Figure 7. Weaving process in vehicular environment
298
high-cost of consumption, they maybe encounter
the hazardous conditions. Therefore, in open environment it is hard to establish meaningful trust
relationships, and even when one can, trust is not
equated with quality. The existence of research
which utilizes the Aspect-Oriented Programming
(AOP) to implement security enforcement policy
to weave into OSGi bundles (Phung et al., 2008).
Additionally, the AOP provide the cross-cutting
functionalities into complicated vehicular applications, and program concerns in a software
system can be captured and encapsulated in to
so-called aspects. Figure 7 illustrates the weaving
process scenario in vehicular environment, which
consists of in-vehicle system, control center, and
third-party service providers.
The vehicle owners would like to install vehicular application bundle by making a corresponding
request in the GST standard. Before installing
this application bundle on the in-vehicle system
through wired/wireless network, the control center
weaves the application with defined aspect such
as security policies, so that the woven bundle can
be operated with enforcement security policies
into the in-vehicle system.
Vehicular System Management Architecture and Application Platform
comparions oF osgi
and android
Figure 8 illustrates both OSGi and Android define
a development platform for developing serviceoriented computing mechanism in mobile devices,
and existence of similar VM technology, service
model, component model and feature of open. But
the main difference is that Android platform utilizes process-based isolation to enhance resource
management, however OSGi platform takes capability of classloader-based isolation model, which
allows OSGi bundles to selectively export some of
their internal packages to other required bundles.
Bundles can declare their package dependencies
and the framework is responsible for managing
dependency relationship between required bundles
and provided bundles. Based on classloaderbased isolation mechanism, OSGi framework
has advantage of rich class sharing. On the other
point of view, Android platform uses background
services to perform time-consuming operations,
but usually these services are heavyweight, and
only can be accessed by utilizing inter-process
communication, which makes service access
slower and more expensive. In OSGi, service
components are lightweight. They are called
directly when finding them in service registry.
Consequently, OSGi services play significant role
in keeping components lightweight and loosely
coupled. In OSGi specification, it defines many
of remote management services, such as SNMP,
CMISE, CIM and OMA DM (Hyun et al., 2008).
By utilizing remote management services, we can
easily remote-manage OSGi framework in many
situations, but these services are non-available
in Android platform. Android platform lack of
class-sharing ability seriously limits the sharing
of components and remote device management.
The lack of versioning and lack of management
APIs is a further limitation. Presumably, OEMs
will provide some solutions for these important
requirements.
open embedded android/osgi
plaTForm For TelemaTics
location of osgi Framework
in android platform
The Dalvik VM use the device’s underlying Linux
kernel to handle low-level functionality including
security, threading, process, and memory management. It’s also possible to read/write C/C++
applications that run directly on the underlying
Figure 8. Comparisons of OSGi and android
299
Vehicular System Management Architecture and Application Platform
Linux OS. But Dalvik VM merely can execute
Dalvik executable files (e.g., classes.dex), a
format optimized to ensure minimal memory
footprint; consequently it can’t perform general
Java packages as well as OSGi bundles, so that
OSGi framework operations to fail when Android
realizes OSGi functionalities in runtime. Besides,
as Figure 9 shows, if the OSGi framework success
to run in Android Runtime layer, it can’t directly
interact with users, because users only can catch the
sight of Android Activities (same as application)
in application layer. For this reason, the Android/
OSGi Activity must to grab the report or log message of OSGi framework, and should to implement
Android UI to present information to the users. We
consider the OSGi R4 implementation of Apache
Felix to integrate with Android platform, because
this container is more portable and light-weight,
and being appropriate for embedded hardware
device such as telematics system.
android/osgi conversion
mechanism
The Android/OSGi conversion mechanism can
assume OSGi framework to dynamically loading bundles through Android Davik VM. In
first, as the Figure 10 shows the Android/OSGi
conversion mechanism, which can make OSGi
framework perform a series of complied Java
classes from OSGi bundles in Android runtime
layer, by means of classes.dex file to referencing
OSGi bundle’s general Java classes. Therefore,
the classes.dex file can be regarded as bridging
role between OSGi framework and bundles. We
had implemented Android/OSGi conversion code
through Dalvik.system.dexFile API, and importing two parameters, such as package name(bundle
API packages) and ClassLoader (reading the Java
classes) objects, and then conversion code will
return the collection of Java classes, so that OSGi
framework can obtain this collection objects to
indirectly perform the functionalities that OSGi
bundles provided.
300
Figure 9. Location of OSGi framework
Figure 10. Android/OSGi conversion mechanism
Vehicular System Management Architecture and Application Platform
After accomplishing the Android conversion
mechanism, we will make sure all OSGi bundles
or general Java packages to contain classes.dex
files, so that OSGi framework can assume any
bundle to work, making API packages to share,
and letting consumer bundles to query the OSGi
services that producer bundles provided. We had
adopted the DEX conversion tool that Android
SDK provided. This tool can easily make Java
complied file to have classes.dex file that Dalvik
VM is able to execute. Figure 11 illustrates the
conversion flow of OSGi bundles to become apk
file (Android executive extension); in originall, we
had made the OSGi bundle projects to be compiled,
and if no exception will generate a series of Java
compiled classes. After making complied classes
to come into being jar file, we took DEX tool to
make jar file containing classes.dex, and then by
using aapt command to transform OSGi bundles
into Android apk files. In the end, by using adb
push command to push converted apk files to
Android platform.
With Finishing Android conversion mechanism
and converted OSGi bundles, we had ported OSGi
framework to Android underlying layer, and other
functional bundles such as telnet, deployment
admin, http, and remote manager bundles etc, so
that Android platform can be assisted and managed
in remote site that original platform doesn’t have
this ability. Figure 12 shows the script of starting OSGi framework in Android runtime layer,
by means of Dalvik VM reading the main class
of OSGi framework, afterward will enter OSGi
console mode, and showing list of some installed
bundles. Nevertheless, in this technique, the users
can’t directly interact with OSGi framework in
real hardware device, so we had implemented Android/OSGi Activity and GUI interface, to acquire
corresponding OSGi information from underlying
layer, and also embedding OSGi framework into
Android application that can enhance it to be more
adaptive and powerful.
development of android/
osgi activity
We had created Android/OSGi Activity in Android
application layer, which can fetch the OSGi corresponding information from Android runtime layer,
and providing interactive environment between
users and OSGi framework. In first integration of
procedure, we must to implement Android Acitivity interface, letting our Android/OSGi application
to have Android Activity properties. Unlike most
traditional environment, Android applications
have no ability of control over their own life
cycles, Instead, Android application framework
must to be in charge of android applications state,
and react accordingly, taking particular care to
be prepared for untimely termination. When
Android/OSGi Activity becomes active state and
need to operate continually, the Android applica-
Figure 11. Conversion flow of OSGi bundles to become apk files
301
Vehicular System Management Architecture and Application Platform
Figure 12. OSGi framework run in android runtime layer
tion framework will pay attention to ensure that
the Android/OSGi Activity remains responsive.
Therefore Android application framework has
the capacity of monitoring platform resources at
any time, if necessary, will kill some empty or
background processes to free resources for highpriority applications.
The Android application is called Activity,
which represents a screen that an application
can present to its users. Android Activity typically includes at least a primary interface screen
that handles the main UI functionality for our
application. This is often supporting additional
by secondary Activities for entering information,
and providing different perspectives on our data.
For example, we had created the Android views
of OSGi console, making users can enter OSGi
commands and catch the sight of OSGi corresponding Information. Every Android Activity
has an initializer method called onCreate(), by
using this initializer method, we can distribute the
memory to perform the launcher thread which can
make OSGi framework to be started. Figure 13
illustrates the cross-communication operation that
Android/OSGi Activity launch the FelixService
(Android background service) which can represent
the GUI interface of OSGi console and to load
302
the main class of OSGi framework after Android/
OSGi Activity onCreate() method had already
been initialized. Android services run without
a dedicated GUI, they usually silently perform
background works that users can’t perceive. Before
Android services to run, they must to be attached
with our Android/OSGi Activity. From different
point of view, the Android/OSGi Activity provides
Android Context object, which makes Android
application framework to be able to manage this
Activity life states, and communication between
Android/OSGi Activity with other native or thirdparty Activities.
To ensure that our Android/OSGi Activity
remains responsive, we move all slow, and timeconsuming operation off the main Activity thread
and onto a child thread, that is continually reading
the main class of OSGi framework, and updating
GUI interface when OSGi console view has been
changed or GUI bundles provide the new screen
services. Consequently, we had implemented the
Felix service to do the above-mentioned operations, as Figure 14 shows that Felix service can
directly find out the location of OSGi framework
in Android runtime layer, and extract the main jar
file of OSGi framework, which is Apache Felix
of R4 OSGi implementation, and by means of
Vehicular System Management Architecture and Application Platform
Figure 13. Cross-communication operation
Dalvik ClassLoader object to read the main class
continually in child thread, so that we can start OSGi
framework in Android application layer. In addition,
we also had implemented the OSGi console view
that can fetch the OSGi corresponding message,
and represent to users. The OSGi console view
has two input/output interfaces that make users to
immediately interact with OSGi framework.
Figure 15 illustrates two-way Communication
Mechanism between OSGi and Android. The
Android/OSGi Activity(described in Figure 13)
can transmit these received information to the
OSGi framework after finishing above-mentioned
operation(First step of Figure 15, sending data such
AP table), so that OSGi framework can regard
these information as permanent properties data
(key/value pairs) stored in OSGi environment(Step
2 in Figure 15), and OSGi bundles can retrieve
these properties through preference service to
implement advanced applications such as network
manager, and navigation bundle, etc(Step 3 in
Figure 15). In the same way, when OSGi bundles
becoming ACITVE state, it also can transmit
some explicitly or implicitly intents to launch
useful Activities. Consequently, on the strength
of this two-way communication mechanism, we
can make Android applications to connect with
OSGi framework and bundles easily.
embedding osgi Framework
to android application
In traditional, the Android/OSGi platform utilizes
the OSGi services and service registry as the extensibility mechanism. This mechanism will let
any application to run completely on top of OSGi
framework, but this is not always possible, in other
words, the components of system should follow
the OSGi standard to be implemented, which
will result in increasing the development times
and costs. Besides, it should spend extra-time to
communicate with OSGi framework in runtime
layer. Therefore, if any Android application wants
to use either the OSGi services or provided APIs
by bundles, it needs complicated Android/OSGi
communication mechanism. We had created extender mechanism that makes OSGi framework
to tightly embed into Android applications in
application layer as Figure 16 shows, in this way,
any android application can host the instance of
OSGi framework by utilizing reflection approach,
and application can externally load the services
which OSGi bundles provided. Nevertheless, the
extender mechanism has some drawbacks about
lack of dynamic changes in OSGi bundles/services
and configuration of OSGi instance. Therefore,
we had combined two potential mechanisms with
303
Vehicular System Management Architecture and Application Platform
Figure 14. Inter-architecture of the Felixservice
Figure 15. Two-way communication mechanism between OSGi and Android
Android platform via cross-communication interface between felixService and OSGi Framework,
management between framework layer and embedded OSGi Activity, to provide more integrated
Android/OSGi environment.
The Felix framework instance doesn’t utilize
ServiceReference array object to get referenced
services, but on the contrary it use Service Tracker
304
interface to monitor services. As a result of utilizing traditional service-oriented mechanism, the
producer bundles should use its BundleContext
object to register services in service registry,
and if services referenced by consumer bundles
had been changed, we must implemented ServiceChanged event to be careful of no exceptions
had been generated, hence this mechanism is more
Vehicular System Management Architecture and Application Platform
Figure 16. Tightly integrated Android/OSGi environment
inconvenient than service tracker mechanism. The
service tracker takes advantages of whiteboard
pattern, making embedded OSGi framework
to utilize server bundle to monitor referenced
services changes in central way. For example,
as Figure 17 shows, if referenced services had
been modified, the server bundle automatically
callback modifiedService method to rebind these
services without implementing ServiceChanged
event handler. For example, the embedded OSGi
Activity has capacity of tracking UI services,
and if UI services have existed, the embedded
OSGi Activity would utilize child thread to call
setContentView method to update the foreground
screen to users.
Vehicular android/
osgi applicaTions
Vehicular Testbed
It is inconvenient and high-cost to test our Android/
OSGi applications to real vehicles, consequently
as Figure 18 illustrates we build a vehicular testbed
to test and verify the functionalities of Android/
OSGi applications. Besides, we regard sensorbased LEGO robots as simulated vehicles, and
vehicular Android/OSGi platform acts as on-board
terminal for simulated vehicles. Instead of utilizing
car buses, this on-board terminal mainly controls
simulated vehicles through Bluetooth like as IBM
Figure 17.Service tracker of embedded OSGi activity
305
Vehicular System Management Architecture and Application Platform
iDrive systems. And communications can be done
via Wi-Fi among different vehicles.
android/osgi applications
We developed various telematics services to
establish intelligent vehicles in mobile environment, which mainly consist of line follow, object
detection, keep distance, and so on. As Figure
19 shows the first part of application is making
vehicles to follow guideline to ensure security
of drivers and no necessary to finding your path
Figure 18. Vehicular testbed
Figure 19. Android/OSGi applications
306
in order to lighten the use of power. The second
part of application is making vehicles to have
visual intelligence that can identify objects like
as traffic signals. The rest part of application
is making vehicles to keep distance with front/
back vehicles. Android/OSGi applications can
be remote-deployed into on-board terminal by
automaker or service providers, but if some of
applications access the significant components
of vehicle, the vehicular Android/OSGi platform
can enforce security policies to avoid accidents
through AOP-based OSGi weaving mechanism.
Vehicular System Management Architecture and Application Platform
Original Android platform can make developer
to create map-based Activities using Google Map
as a user interface element. We have full permissions to access the map, include change the zoom
level, move the centered location, use overlays,
provide map-contextualized information and
functionality, and so on. But if service providers
want to design navigation applications based on
map-based Activities, they must to create many
heavyweight services to perform time-consuming
operations. Besides, Android platform lack of
class-sharing among different applications and
islands of no-interoperable processes, which often limit usage of system resources and remain
non-responsive. Figure 20 illustrates vehicular
Android/OSGi platform has feature of lightweight
applications, which application size is less 4KB
than original application. But vehicular Android/
OSGi platform must to spend about 3 seconds to
start OSGi framework in first time, and additional
memory size of OSGi framework.
remote management
Figure 21 illustrates vehicular Android/OSGi
platform mainly provide three management consoles, which include telnet, web management, and
remote deployment console. The first part of telnet
console can make remote manager to diagnose/
manage Android/OSGi applications though telnet
interface, which extends telnet bundle that Oscar
R3 implementation provided. Original Android
platform can’t utilize telnet services to diagnose/
manage its conditions of applications or system
configuration. The second part of web console
management can make remote manager to diagnose/manage Android/OSGi applications based
on web techniques. The web management console
has been established rely on underlying OSGi
bundles, which contain http service, declaractive
service, log service, configadmin, deployadmin,
metadata, and so on. Although original Android
platform has http service, that can give users
Figure 20. Lightweight Android/OSGi applications
307
Vehicular System Management Architecture and Application Platform
Figure 21. Remote management of vehicular Android/OSGi platform
way to surf internet depend on WebKit browser,
it doesn’t have web server, which allow remote
users to login/logout into platform. The rest part
of remote deployment console can make applications be able to be deployed into remote vehicular
Android/OSGi platform. This way is similar with
Android market deployed mechanism, but has
something differences, such as original Android
platform can’t administrate the identity of users
and automatically validate security and stability
of applications.
308
reFerences
Ai, Y., Sun, Y., Huang, W., & Qiao, X. (2007).
OSGi based integrated service platform for
automotive telematics. In Proceedings of IEEE
International Conference on Vehicular Electronic
and Safety, (pp. 1-6).
Gun, N., Held, A., & Kaiser, J. (2001). Proactive services in a distributed traffic telematics
application. International Workshop on Mobile
Communication over Wireless LAN: Research
and Applications.
Vehicular System Management Architecture and Application Platform
Hackbarth, K. (2003). OSGi – Service-DeliveryPlatform for Car Telematics and Infotainment
Systems. Advanced Microsystems for Automotive Applications 2003 (pp. 497-507). Berlin:
Springer.
Phung, P. H., & Sands, D. (2008). Security Policy
Enforcement in the OSGi Framework Using
Aspect-Oriented Programming. In Proceedings of
the IEEE International Conference on Computer
Software and Applications, (pp.1076-1082).
Hsu, R. C., & Chen, L. R. (2005). Integrated
Embedded System Architecture for In-Vehicle
Telematics and Infotainment System. Proceedings
of the IEEE International Symposium on Industrial
Electronics, 4, 1409–1414.
Sun, Y., Huang, W. L., Tang, S. M., Qiao, X., &
Wang, F. Y. (2007). Design of an OSEK/VDX
and OSGi-based embedded software platform for
vehicular applications. In Proceedings of IEEE
International Conference on Vehicular Electronic
and Safety, (pp.1-6).
Lee, C., Nordstedt, D., & Helal, S. (2003). Enabling Smart Spaces with OSGi. IEEE Pervasive
Computing, 2(3, July-Sept), 89-94.
Li, Y., Wang, F., Feng, H., & Li, Z. (2005). OSGibased service gateway architecture for intelligent
automobiles. In Proceedings of the IEEE International Conference on Vehicles Symposium, (pp.
861-865).
Myoung, K., Heo, J., Kwon, W. H., & Kim, D.
S. (2005, July). Design and implementation of
home network control protocol on OSGi for home
automation. In . Proceedings of the IEEE International Conference on Advanced Communication
Technology, 2, 1163–1168.
Weiss, E., Gehlen, G., Lukas, S., & Rokitansky,
C. (2006). MYCAREVENT- Vehicular Communication Gateway for Car Maintenance and
Remote Diagnosis. In Proceedings of the IEEE
International Conference on Computers and
Comunication, (pp. 318-323).
Zhang, D., Xiao, H. W., & Hackbarth, K. (2004).
OSGi based service infrastructure for context
aware automotive telematics. In . Proceedings
of IEEE International Conference on Vehicular
Technology, 5, 2957–2961.
Zhou, Y., Wang, X., & Zhou, M. (2006). The
Research and Realization for Passenger Car CAN
Bus. In Proceedings of the IEEE International
Forum on Strategic Technology, (pp. 244-247).
309
310
Chapter 18
Remote Vehicular System
Management Functions and
Information Structure
Teng-Wen Chang
National Taiwan University of Science and Technology, Taiwan, R.O.C.
Jiann-Liang Chen
National Taiwan University of Science and Technology, Taiwan, R.O.C.
absTracT
Due to the rapid development of information technology, the network has already spread to every corner of
vehicle. With all kinds of ECU devices appear in the vehicle, and it brings the more and more convenient
living. On purpose solving heterogamous technologies that are incompatible with each other, developed
a “WBEM-based Remote Management and Heterogeneous Vehicular Network Diagnosis System” on
OSGi Gateway. This system can focus on a variety of problems come from vehicle network, and find
out what are the problems or where are the problems happened. If the problem still can not be solved
properly, we must to seek for help from remote managers. The users can acquire enough information
without understanding how to control every device, so that the users can help near diagnosis system to
solve vehicle network’s problems and to promote the abilities of near network diagnosis.
inTroducTion
Due to the vehicular network management system
has not been standardized and lacking interoperability. In addition to the existing network management
system has a simple structure consisting of server,
provider and client, as communication between
admin users and management server. This study
DOI: 10.4018/978-1-60566-840-6.ch018
constructs a remote vehicular network management
and diagnosis system with OSGi platform (Ai et al.,
2007; Sun et al., 2007) and WBEM (Web-Based
Enterprise Management) to speed up the realization of the heterogeneous home network. Usage
of OSGi platform provides several benefits. The
most important one that it integrate different types
of vehicular networking technologies, because currently most available vehicular network middleware
and technology have no compatibility with each
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Remote Vehicular System Management Functions and Information Structure
Figure 1. Remote managing protocols
other, home devices based on these heterogeneous
middleware cannot communicate with one another,
even though they are physically connected.
The OSGi service platform is initially chosen
for its capabilities to integrate components and
services from different providers in the heterogeneous home network. (Marples et al., 2001;
Saito et al., 2000) The OSGi service platform is
specifically designed for devices that can manage
remote devices through remote managers. Figure
1 illustrates these devices that need to be established some of remote managing protocols, such
as SNMP, CMISE, CIM, OMA DM, and more.
The OSGi Alliance decided that no managing
protocol can be preferred over others because
no protocol is suitable for all cases. The OSGi
Alliance now has been working to develop a standardized management API to build functionality
of remote management into unattended devices.
This is a very powerful concept that offers the
same interoperability as a standard protocol. However, the benefits of this concept are not always
immediately obvious. The benefit of a standard
protocol is that any device can be managed by
any manage operators. Consequently, we apply
Web-based Enterprise Management (WBEM)
managing protocol to vehicular network environ-
ment. Using WBEM protocols, remote managers
can easily manage devices through web interfaces,
and operate with any manufacturer’s device, regardless of the underlying protocols.
The proposed system uses the WBEM to provide more effective resource management and a
larger range of services than before. Because the
different types of vehicular network technologies
and management instruction, need the different
technology to manage the each vehicular network,
like SNMP, Telecommunications Management
Network (TMN) and so on. In order to overcome
the situation that WBEM and CIM (common
information model) provide an excellent management environment and promotes the information
exchange across a variety of underlying technologies and platforms supported interoperability. The
WBEM offer extreme flexibility and efficiency
to manage method, that communication with
each other different management type. Figure 2
illustrates overview of integrating OSGi platform
with WBEM these two technologies and Remote
management through Web-based Enterprise Management Architecture to the vehicular gateway.
The WBEM-based Remote Vehicular Network
Management and Diagnosis System can figure out
the status fast and easily, and realize the benefits
311
Remote Vehicular System Management Functions and Information Structure
Figure 2. Integrating OSGi platform with WBEM
of integrating these two technologies, significant
research has been carried out the telematics in
the near future.
relaTed works
We make a brief introduction of vehicular network
system which are popular nowadays, and make
use of scenario situation to state vehicular network
environment in the future, state a lot of technology applied to vehicular network in this chapter.
Besides, related work would also be discussed.
Vehicular network environment
Figure 3 illustrates the vehicular network environment, which can be divided into two categories,
including in-vehicle network architecture and
out-vehicle network architecture. In the in-vehicle
network, the vehicle might include four kinds of
car bus protocols such as CAN (Controller Area
Network), LIN (Local Interconnect Network),
MOST (Media Oriented Systems Transport)
and FlexRay (Mariño et al., 2009). The CAN
bus protocol is main backbone for in-network
environment in current, and it has the goal of
making vehicle more reliable, safe and fuelefficient while decreasing wiring harness weight
and complexity. Besides, CAN bus protocol has
312
applied widespread in industrial automation and
automotive/truck applications. The FlexRay protocol provides high-speed, deterministic and fault
tolerant communications for in-network. It also
can be compatible with existing networks, such
as CAN, LIN, and so on. But above-mentioned
protocols can’t intercommunicate to each other.
Consequently, the OSEK/VDX operating system
acts a role which makes the message communicate between two different car protocols (Kim et
al., 2007).
In the out-vehicle network, the OBU (On
Board Unit) in the vehicle can communicate to
infrastructure via out-network modules, or connect with another vehicles via DSRC/IEEE 1609.
The remote home service provider and remote
vehicular service provider can provide its particular services to automotive user.
open services gateway initiative
(osgi) service platform
The OSGi™ Alliance was founded in March 1999.
Its mission is to create open specifications for the
network delivery of managed services to local
networks and devices. The OSGi organization is
the leading standard for next-generation Internet
services to homes, cars, mobile phones, desktops,
small offices, and other environments. With the
advent of ubiquitous communication, PCs as well
Remote Vehicular System Management Functions and Information Structure
Figure 3. Vehicular network environment
as diverse devices, such as sensors and information
home appliances, are now being linked together,
often using heterogeneous communication protocols. In addition, broadband access has become
much more widespread and it is common to see
homes and offices with always-on connections to
the Internet. Against this backdrop, increased attention is being paid to gateways that provide key
capabilities for functional interworking between
devices and portal capability for using services offered by external networks, including the Internet.
The OSGi Service Platform is delivered in many
Fortune Global 100 company products and services and in diverse markets including enterprise,
mobile, home, telematics and consumer.
The core component of the OSGi specifications
is a framework. It provides a general-purpose, secure, and managed Java framework that supports
the deployment of extensible and downloadable
applications known as bundles. OSGi-compliant
devices can download and install OSGi bundles,
and remove them when they are no longer required.
The Framework manages the installation and
update of bundles in an OSGi environment in a
dynamic and scalable fashion. To achieve this, it
manages the dependencies between bundles and
services in detail. It provides the bundle developer
with the resources necessary to take advantage
of Java’s platform independence and dynamic
code-loading capability in order to easily develop
services for small-memory devices that can be
deployed on a large scale. The OSGi framework
architecture has a number of layers as depicted
as Figure 4.
web-based enterprise
management (wbem)
WBEM stands for Web-Based Enterprise Management. WBEM is an ongoing initiative started by industry leaders such as Compaq, Microsoft, Cisco,
Intel and over 70 others. This initiative proposes a
common method of managing enterprise systems.
It merges existing management solutions with the
latest advances in Web technology. WBEM is a
set of Internet standards which gives the ability
to interconnect between different management
standards and environments. WBEM allows
managing both software (operating systems, applications) and hardware (computers, network
313
Remote Vehicular System Management Functions and Information Structure
Figure 4. OSGi framework architecture
devices) by creating a common layer which unifies and simplifies management through WBEM
compliant applications.
WBEM is an initiative of DMTF and it includes
a set of technologies that enables the interoperable management of an enterprise network. The
DMTF has developed a core set of standards that
make up WBEM, which includes a data model,
the CIM standard; an encoding specification,
CIM-XML encoding specification; and a transport
mechanism, CIM operations over HTTP. Figure
5 illustrates the relationships among WBEM
Standard Technologies architecture.
The CIM specification is the language and
methodology for describing management data.
CIM is an object-oriented schema for modeling
the objects. The CIM schema can be divided to
three areas; the core model, the common model
and the extension model. First, the core model
captures notions that are applicable to all areas of
management. Second, the common model is an
information model that captures notions that are
common to a particular technology. For example,
it includes the model for systems, applications,
networks and devices. Last, the extension model
represents technology-specific extensions of
common models.
Figure 5. Relationships among WBEM standard technologies
314
Remote Vehicular System Management Functions and Information Structure
The CIM-XML encoding specification defines
XML elements, written in Document Type Definition (DTD) that can be used to represent CIM
classes and instances. The CIM operations over
HTTP specification defines a mapping of CIM
operations onto HTTP that allows implementations
of CIM to interoperate in an open, standardized
manner and completes the technologies that support WBEM. Therefore, in the WBEM architecture, the management information is described by
the CIM schema, converted to XML, and finally
embedded in an HTTP payload to transport to
the target node.
Figure 6 illustrates the WBEM architecture
(Thompson et al., 1998), which includes a WBEM
Client, and WBEM Server. WBEM Server has
CIM Object Manager (CIMOM) which is a central
component that routes information about objects
and events between components. The CIMOM
responds to the operations defined in the “CIM
operations” specification such as create, modify,
and delete. It also checks the syntax and semantic
of the messages, and provides security. Providers
are so-called instrumentation agents. Namely,
Providers actually obtain the information from the
resources and forward it to the CIMOM. A WBEM
Client is commonly represented as the management application, and it can get the information by
sending a request message to the CIMOM instead
of directly accessing the providers.
Figure 7 shows the various layers through
which an operator’s request passes and through
which the response returns when a managed object
is accessed.
A command from the operator or higher-level
management system originates with the application logic which handles graphical screens, interpretation of command-line interfaces, etc. The
command is then mapped to the abstract object
model. Fundamentally, the Object Abstraction
layer has to know that, when the operator enters
a command to create a new OSPF service, for
example, then this means the creation of instances
of various CIM classes. This knowledge may
Figure 6. WBEM Architecture
be hard-coded, table-driven or driven from the
model.
Once the actual CIM commands have been determined, they are encapsulated in CIM-XML and
passed to the HTTP client. This is responsible for
any negotiation required with the WBEM server
and the correct transfer of the request. Addition
to traditional CIM operations using XML, CIM
operations using Binary XML (Park et al., 2006)
enhance a performance of message transportation
between WBEM clients and a WEBM server.
Once the request reaches the WBEM server,
it is passed from the HTTP server to have the
CIM-XML reconstituted into CIM commands. The
CIM Object Manager (CIMOM) examines these
and determines how they should be handled: by
the CIMOM itself, with reference to the schema
stored in the repository, or by a provider. If it is
passed to the provider, then the provider accesses
the real device or service to retrieve the requested
information or carry out the requested configura-
315
Remote Vehicular System Management Functions and Information Structure
Figure 7. WBEM Client/WBEM server interactions
tion. The response from the provider follows the
reverse path back to the operator.
WBEM is architecture, not an implementation.
Implementations exist though. Sun Microsystems
has released a Java WBEM and implemented
CIMOM with Java Management Extensions and
Microsoft has its CIMOM implementation called
Windows Management Instrumentation (WMI).
Another similar SDK that facilitates development
of WBEM servers is the SNIA CIMOM, a free
product with open source code that is compatible
with the Sun WBEM SDK API. Table 1 shows
existing WBEM implement.
The WBEM technology has the following
features:
•
•
316
Real Standard: Back by many industry,
like Microsoft, IBM, Sun, HP, and so on.
Mature implementations exist: Reduce
development and maintenance effort.
•
•
•
Standard Interface for different monitoring systems: Much fabric management
uses the WBEM standards.
Standard Interface for information
providers: Future APIs available for
simplicity.
Can replace log file style providers:
Provide CIM repository.
Replacing existing management standards such
as SNMP or CIMP is not WBEM attempt to, but to
provide a framework embracing existing management standards and protocols. This would allow
the integration of distributed management services
provided by different management platforms and
applications. Consolidate and unify the data provided by existing management technologies is the
key purpose of the WBEM initiative.
Remote Vehicular System Management Functions and Information Structure
Table 1. Existing WBEM implement
Producer or
initiator
Platform
Programming
language
License
Elements and
capabilities
Java 1.2 or higher
SISSL (Sun
Industry Standards
Source License)
CIMOM, Client
API, Provider API,
MOF Compiler,
CIM Workshop,
providers for Solaris
OS (only in Solaris)
WBEM Services
Sun Microsystems
Solaris 8 (Spark/
Intel)
open source: platform-independent
(Java)
Pegasus
The Open Group
(IBM, Compaq, HP,
BMC)
Linux, Unix
(AIX, HPUX,
Solaris), Windows
NT/2000/9x
C++
Open Source
CIM Object Broker
(CIMOM), Client
API, Provider API
SNIA WBEM
Storage Networking
Industry Association
(SNIA)
platform-independent (Java)
Java (since 1.1.8)
SNIA Public
License
Open Source
OpenWBEM
Caldera
Unix, Linux, Solaris, other
C++
Open Source
CIMOM, Client
API, Server API,
MOF Compiler,
WQL (WBEM
Query Language)
tools
SBLIM
IBM
Linux
C++ (Native Provider Interface)
Common Public
License
a set of providers
for Linux system
Integrated with MS
Windows operating
system
API (WBEM
Provider DLL),
functionality based
on the operating
system kernel
General Public
License
libCIM, PaulA
(CIMOM API)
WMI
Microsoft
MS Windows
98/2000/XP
any language
capable to use DLL
API
B4WBEM
B4WBEM
Linux
Perl
simple network management
protocol (snmp)
The Simple Network Management Protocol
(SNMP) is an application layer protocol that facilitates the exchange of management information
between network devices. Absolutely this protocol
is used in the IP-based home network environment.
SNMP enables network administrators to manage
IP-based home network performance, find and
solve network problems. SNMP is a request-reply
protocol running over UDP through TCP operation
is possible. SNMP is extensible, allowing vendors
to easily add network management functions to
their existing products. SNMP is not a mere paper
specification, but an implementation that is widely
available today.
SNMP is based on a manager and agent model.
An SNMP-managed network consists of three main
components including: managed devices, agents
and Network-Management Systems (NMSs).
Figure 8 illustrates the relationships of these three
components model. These managed objects are
arranged in a virtual information database known
as a Management Information Base (MIB). The
‘manager’ is the console where network management functions are performed, and the ‘agents’
are the entities or software modules that interface
with the actual devices being managed.
A Management Information Base (MIB) is a
collection of information which defines the properties of managed objects. Managed objects are
comprised of one or more object instances, which
are essentially variables. The SNMP manager and
317
Remote Vehicular System Management Functions and Information Structure
Figure 8. NMS, agents and managed devices model for SNMP
agent use a MIB and relatively small set of commands to exchange information of the managed
devices that contain network nodes or managed
objects. An object identifier or object ID uniquely
identifies a managed object in the MIB hierarchy.
The MIB hierarchy can be depicted as a tree with
a nameless root, the levels of which are assigned
by different organizations. For example of the
Figure 9 illustrates the MIB tree. The top-level
object IDs represent different organizations, while
the lower-level object IDs are allocated by associated organizations. The diagram below illustrates
an MIB tree where the top-level object IDs are
different organizations, and the lower-level object IDs are the associated object. To identify the
‘system’ illustrated in the diagram, a unique ID
for the object can be ‘iso.org.dod.internet.mgmt.
mib-2.system’ or the equivalent numeric object
descriptor, ‘1.3.6.1.2.1.1’.
Addition to IP-base network, as PLC networks
and their applications grow with the advances in
PLC technologies, major PLC chipset and modem
vendors are trying to provide network management capabilities in their devices by defining
their own private management information base
(MIB). Some PLC management researches (Park
et al. 2008; Park et al. 2008) focus on integrated
management of multi-vendor PLC networks by
using SNMP technology.
318
wbem compared to snmp
In this section, WBEM will be compared against
SNMP. Table 2 shows the different between
WBEM and SNMP. As for the conventional
network management protocols, the Simple
Network Management Protocol (SNMP) is the
most popular among the Internet Protocol Based
(IP-BASED) local area network, while no obvious
Figure 9. Example of the MIB tree with various
hierarchies
Remote Vehicular System Management Functions and Information Structure
winner among other types of networks. However,
SNMP is not a suitable protocol for remote home
network diagnosis system because (1) the polling
mechanism used by SNMP may cause network
congestion in a large network or crossing the
boundary of wide area network (WAN), and SNMP
places the burden of data collection entirely on the
management side, (2) SNMP agent cannot provide
the historic record of an equipment or data, and
(3) SNMP cannot use a unified data descriptor to
preserve the flag, state and configuration of all
the managed equipments. Also has follow reasons
besides these. The conventional SNMP network
management approaches have several difficulties
and challenges (Chen et al., 1998). First is incompatibility and platform-dependence in managing
heterogeneous networks. Second is high investment. Comparatively, Web-Based management
approaches provide the following advantages:
lower cost, scalability, platform-independence,
more flexibility and remote access, and easier
dynamic information.
managing archiTecTure
and diagnosTic meThod
For remoTe conFiguraTion
oF heTerogeneous
local neTworks
As the communication and network technologies
progress rapidly, the number of network-related
facilities used in the home and small business is
also increasing. The raising of the information
appliances enables the popularity of easy-to-use,
convenient, and Internet connectable appliances
in the home and small business networks. In addition, the co-existence of different heterogeneous
inter-connection technologies, such as IEEE 802.3,
IEEE 802.11, Bluetooth, IEEE 1394, power line,
home plug, and so on, is becoming a common
phenomenon.
In complicated and heterogeneous network environment, the management of the home and small
business network is both a harsh challenge and an
urgent demand for the users, appliance designers
and service providers. In general, when a home
network or a small business network encounters a
Table 2. Comparison between WBEM and SNMP
Features
SNMP
WBEM
Data encoding format
Binary encoding (BER)
XML (xml/CIM)
Data description model
MIB (Management Information Base)
MOF (Managed Object Format)
Namespace
Defined by OID (ObjectIDentifiers)
Defined by CIM Schema
Data structure
Vendor-based
CIM-based object model
Transportation protocol
UDP
HTTP/TCP
Protocol encapsulation
IP,UDP, SNMP
IP, TCP, (SSL, SHTTP), HTTP, XML
Reliability
UDP is connectionless
by TCP functions
Protocol messages types
SNMPv1: Get, GetNext, Set, Trap
SNMPv2: all from SNMPv1, GetBulk, Inform,
Reply
SNMPv3: all from SNMPv2, new Trap and Report
SimpleReq, SimplerRsp, MultiReq, MultiRsp
Security
SNMPv1, SNMPv2 - only community name SNMPv3 - USM (User-based Security Model
HTTP 1.1
SSL+HTTP
SHTTP
Management flexibility
Low, generally network devices only
High, management model is device independent
Other protocol interconnectivity
Low may be realized by proxy agents.
Mapping to many protocols: SNMP, DMI, CMIP
itd (Mappings are described by DMTF standards)
319
Remote Vehicular System Management Functions and Information Structure
problem, the user usually does not have sufficient
knowledge or expertise to perform diagnosis or
trouble-shooting. Therefore, this service provides
a good business opportunity of potentially lucrative revenue for the telecommunication or Internet
service provider (ISP) companies.
As a result of automotive environment is more
complicated and changeable than home environment, we take our managing system into home
network, to validate and perform the managing
functionalities of proposed architecture. The
proposed managing architecture and diagnostic
method for remote configuration of heterogeneous local networks, which includes at least one
sub-network agent, a local area network (LAN)
management module and a remote LAN module,
as shown in Figure 10. Each sub-network agent
manages its sub-networks via its own management
protocol, and collects the sub-networks’ information. The LAN management module receives
the requests from heterogeneous local networks
via these sub-network agents, and converts the
information associated with each request into a
common information module (CIM) to seek a
solution for each request. The remote LAN module receives the unsolved requests from the LAN
management module via a channel, configures the
heterogeneous local networks and uses compatible interface at a remote side to accomplish the
management and diagnosis for the heterogeneous
local networks.
Figure 11 show the module details of the proposed architecture. In following section, we detail
the proposed architecture of remote managing of
heterogeneous local area network.
sub-network agents
Each sub-network agent manages the sub-network
through its own management protocol, and collects
sub-network information. The LAN management
module is coupled to the sub-network agent and
a cross-internet channel respectively, receives
one or more requests from the heterogeneous
local network through the sub-network agent,
and converts the information accompanying the
Figure 10. Architecture of remote managing of heterogeneous local area network
320
Remote Vehicular System Management Functions and Information Structure
Figure 11. Module details of the proposed architecture
node information inside the sub-network, information between nodes, and other related network
information. Each sub-network agent uses its
own managing protocol, such as SNMP or common management information protocol (CMIP),
to obtain the sub-network information. Each
sub-network build-in, customize or filter out the
analysis of the event relevance. Each sub-network
agent also communicates with LAN management
module through protocol conversion module, and
receives the instruction from LAN management
module to control related sub-networks. The information after sub-network agent filters or integrates
is returned to LAN management module so that
remote LAN module knows the information and
the status of each sub-network.
local area network (lan) module
request into a common information model to find a
solution for the request. The remote LAN module
receives the requests, which the LAN management module fails to solve, through the channel,
accesses and configures the heterogeneous local
network remotely, and uses interface compatible
with the heterogeneous local network to realize the
management and diagnosis of the heterogeneous
local network.
Sub-network act as drivers and interface
between the LAN management module and the
Sub-network. Sub-network agent collect information of sub-network, and warn about or respond to
the related event automatically. The information
provided by the sub-network agent includes the
The LAN module provides internet connection
to the remote LAN module through a channel,
and receives one or more management and network information of one or more heterogeneous
local networks through the sub-network agent
and converts into a common information model
for providing the remote LAN module a unified
management information and operation. When the
heterogeneous local network encounters problems,
the LAN management module searches for solution first, and when the LAN management module
fails to provide solution, the LAN management
module requests the remote LAN module or a
remote manager for assistance so as to realize the
management and diagnosis of the heterogeneous
local network.LAN management module includes
a LAN control module, a network information
module, a network protocol conversion module,
a common information storage media, a user
interface, and a security module.
Network protocol conversion module is responsible for communicating and coordinating
with sub-network agent through related protocol
and mechanism to obtain the basic and management information of sub-network. Network
321
Remote Vehicular System Management Functions and Information Structure
protocol conversion module issue a service,
such as through registration, to notify other
related services of the service content so that
other related services use the new service, such
as through installation pr-executing instruction.
Network protocol conversion module converts the
obtained information into a common information
model or similar format. The common information model is an overall management information
model describing all the computer systems and
network equipments in an enterprise network
environment, including a set of specifications and
a set of schemas. Network protocol conversion
module transmits the converted information to
network information module. The data conversion
is such as converting the sub-network instruction
into common information model. The functions
of network protocol conversion module could be
added flexibly.
Network information module analyzes and
organizes the converted common information
from network protocol conversion module, and
then selects and defines a common information
model suitable for storing network information
for storing in common information storage media.
Network information module is responsible for accessing information stored in common information
storage media required by LAN control module
for diagnosis and management, and receives
the issued diagnosis and managed instructions
and passes the instructions to network protocol
conversion module for performing diagnosis and
management. The common information model has
sufficient expressive capability to represent all the
managed objects, and has sufficient expansion
capability to accommodate new managed objects
as well as accessing the management information
effectively. For example, the common information
model object manager (CIMOM) of the management infrastructure of web-based enterprise
management (WBEM) plays the role of network
information module.
Common information storage media is the actual information storage media to match network
322
information module. Common information storage
media is a database or a specific format file, such
as management object format (MOF) file matching
CIM in the management infrastructure of WBEM.
The information stored in common information
storage media is only accessed through network
information module.
LAN control module is the control center of
LAN management module, providing basic network management functions, network diagnosis
process, algorithm for solving network problems,
network information update process, and communicating with remote LAN control module.
The basic network management functions include
numerous items such as allowing the user to know
through user interface the network internal basic
information, such as network topology, network
traffic, network speed, and node information, or
even the software installation on each node. In the
problem diagnosis, the collected information is
used to analyze the possible cause of the problem,
and forwards the problem to LAN control module.
If LAN control module fails to solve the problem
internally, a request is sent to remote LAN module
for assistance to provide a solution.
When the problem is solved, LAN control
module or remote LAN control module report to
the user or warn the user for preventing similar
events in the future. When the problem is not
completely solved, LAN control module or remote
LAN control module will also inform the user of
the problem handling status. For example, through
the node analysis to obtain the node equipment
information, LAN control module or remote LAN
control module use the information to search for
equipment manufacturer for repairing and post
the information on the user interface to inform the
user. The cause or the solution to the problem is
recorded on common information storage media
or remote common information storage media for
future reference.
User interface show the network information,
such as network topology, each node information,
network traffic, and network speed. Through the
Remote Vehicular System Management Functions and Information Structure
graphic and web-based interface showing the
network status, the user easily use the mouse or
button to process complicated network problem
and issue management instructions with simple
and clear guiding mode. For the user, the interface is simple and effective. Therefore, the user
understands the network internal basic information
through the use of the user interface.
Security module is responsible for related security mechanism, such as security authentication
mechanism, data encryption mechanism, protecting the internal data access mechanism for LAN
control module, and billing mechanism. Security
authentication mechanism is to verify whether
the user is the legitimate user or administrator so
as to protect LAN control module from invasion
by illegitimate remote LAN control module. During information transmission, a data encryption
mechanism is provided to prevent data from theft.
The data encryption mechanism is controlled by
security module and remote security module,
respectively. These two security modules both
encrypt and decrypt the data transmitted and
received on either side. The encrypted data will
not be easily theft or utilized so as to achieve the
security objective.
remote lan management module
Remote LAN management module receives the
unsolved request from LAN management module
through channel, such as request from sub-network, remotely access and configures the heterogeneous local network, and adopts an interface
compatible to the heterogeneous local network
to realize the management and the diagnosis of
the heterogeneous local network. Remote LAN
module includes a remote LAN control module,
a remote network information module, a remote
common information storage media, a remote user
interface, and a remote security module.
Remote LAN control module, remote network
information module and remote common information storage media of remote LAN module basi-
cally operate in a way similar to those modules
in LAN management module. The difference lies
in remote LAN control module is designed for
remote LAN diagnosis and management service
center. Therefore, remote control module monitor, manage, and register LAN, such as all home
network and small business network. In general,
remote LAN module collects and utilizes global
data, such as periodically obtaining the topology
of each LAN. In performing LAN management
and diagnosis, remote LAN control module will
request LAN control module of a certain LAN
management module for detailed information, and
stores the information in remote information storage media for assisting the solving of the problem
that LAN control module of LAN management
module fails to solve.
algorithms
A diagnosis method for remote configuration
of heterogeneous local networks comprises the
steps of: detecting through at least a sub-network
agent whether any sun-network connecting to the
sub-network agent encounters any problem; when
detecting at least a sub-network encountering
problem, collecting the management and network
information of the sub-network with the problem,
and transmitting to a LAN management module;
converting the management and network information of the sub-network with the problem into
a common information model through the LAN
management module, and performing diagnosis
to determine whether a solution can be provided;
when the LAN management module fails to provide a solution, requesting a remote LAN module
or a remote management for assistance to realize
the management and diagnosis of the sub-network
with the problem; and responding the diagnosis
message to a user interface or the sub-network
agent. Figure 12 illustrates diagnosis methods
for remote configuration of heterogeneous local
networks.
323
Remote Vehicular System Management Functions and Information Structure
A method for updating network information for a management architecture for remote
configuration of heterogeneous local network,
comprising the steps of: determining whether
network information is periodic information
or dynamic information; if periodic, using the
extract instruction to obtain the update information; if dynamic, collecting and processing the
network information and converting the processed
network information into a common information
and obtaining the update information; filtering
the updated periodic or dynamic information
and determining whether to store remotely; if to
store remotely, informing a remote LAN module
and storing the updated information to a remote
common information storage; and if not to store
remotely, storing the updated information to a local
common information storage. Figure 13 illustrates
network information update process.
A method for adding a sub-network to a
managing architecture for remote configuration
of heterogeneous local networks, comprising the
steps of detecting a new network through a network protocol conversion module; determining
the attributes of the new network through a LAN
management module; when the LAN management
Figure 12. Diagnosis methods for remote configuration of heterogeneous local networks
324
Remote Vehicular System Management Functions and Information Structure
Figure 13. Network information update process
module fails to provide the support service to the
new network, sending a request to a remote LAN
module; the remote LAN module finding a suitable sub-network agent to the new network and
transmitting to the LAN management module; and
when the new network having a sub-network agent,
performing the registration and announcement of
the new network. Figure 14 illustrates process of
adding a new sub-network.
Vehicular sysTem
archiTecTure
Figure 15 show the system architecture. The
system architecture contains two parts. The left
part is OSGi platform and the right part is WBEM
server. The OSGi platform contains some bundle
build upon OSGi framework; include authentication bundle, vehicular network diagnosis bundle,
IP network agent bundle, Power Line network
agent bundle, IEEE 1394 network agent bundle
and connect interface bundle. The bundles further
describe as follow:
325
Remote Vehicular System Management Functions and Information Structure
Figure 14. Process of adding a new sub-network
•
•
forwards the problem to vehicular network
diagnosis bundle. If vehicular network diagnosis bundle fails to solve the problem
internally, a request is sent to remote manager for assistance to provide a solution.
Connect interface bundle: Connect interface bundle is adapter between OSGi platform and WBEM server. All information
collected by network agent will convert to
CIM model by connect interface bundle
and store on WBEM repository or pass to
remote center. Connect interface bundle
also receive the instance from WBEM
server.
Authentication bundle: Authentication
bundle is to verify whether the user is the
legitimate user or administrator so as to
protect home server from invasion by illegitimate remote client.
The remote client provides a user interface
that manager could watch the vehicular network
information, manage device or sent diagnosis
information to local home server if local don’t
have enough solution.
wbem-based remote Vehicular
network management and
diagnosis system
•
•
326
Network agent bundle: The IP network
agent bundle collects information of IP
network and uses SNMP managing protocol to manage device. Other network agent
do same thing but using its own managing
protocol.
Vehicular network diagnosis bundle:
Vehicular network diagnosis bundle providing basic network management functions, network diagnosis process, algorithm
for solving network problems. In the problem diagnosis, the collected information
by network agent bundle is used to analyze the possible cause of the problem, and
Figure 16 shows the WBEM-based Remote
Vehicular Network Management and Diagnosis
System GUI. The WBEM-based Remote Vehicular Network Management and Diagnosis System
GUI contains three parts: the left panel shows the
vehicular network topology by using tree view;
the top-right panel contains some buttons, and
the bottom-right panel, which display messages
about the detail device information and allow sent
solutions info to WBEM-based Local Vehicular
Network Management and Diagnosis System.
The vehicular network topology is local vehicular network topology include IEEE 1394 network
topology, IP-base network topology, and Lon-
Remote Vehicular System Management Functions and Information Structure
Figure 15. System architecture
Figure 16. WBEM-based remote vehicular network management and diagnosis system GUI
Works network topology. When click the device
on left-panel topology, top-right panel will show
the detail information of this device. For example
in Figure 16, by clicking the Port7 device we could
get the device description is Hardware x86, device
uptime is 1 day 21:29:20.5, location is restroom,
IP address is 192.168.1.50 and some other detail
information show on top-right panel.
All process in WBEM-based Remote Vehicular
Network Management and Diagnosis System are
matching management object format (MOF) file
CIM in the management infrastructure of WBEM.
The MOF of system includes attribute and method
of system process. The lonworksdeviceinfo,
ieee1394deviceinfo, and ipdeviceinfo are the
defined network information model. Information
327
Remote Vehicular System Management Functions and Information Structure
Figure 17. XML for invoking/return the snmpX method
of each sub-network is described in this model.
The topologyX is the method operation that client
could get local sub-network topology. The snmpX
is the method operation that client could get oid-
value by input ipaddress and oid. The findip is the
method that do mac to ip convert. In addition, the
new CIM model could add to repository through
OSGi update or download.
Figure 18. WBEM-based Local Vehicular Network Management and Diagnosis System GUI
328
Remote Vehicular System Management Functions and Information Structure
Figure 19. Diagnosing of the changes of SNMP switch network topology
All information show on remote client is
through WBEM server and is CIM model. It uses
RMI or CIM Operations over HTTP to transmit
information between the residential gateway and
remote manager. The operations and messages are
described abstractly, and then bound to a concrete
network protocol and message format to define an
endpoint. The CIM Operations over HTTP using
an XML format for describing network services.
Figure 17 illustrates invoked and returned operations for transmitting managing message.
wbem-based local Vehicular
network management and
diagnosis system
The WBEM-based Local Vehicular Network
Management and Diagnosis System main GUI and
OSCAR bundle list is shown in Figure 18. The
GUI contains three parts: the top-left panel shows
the vehicular network topology by using tree view;
the top-right panel contains some buttons, and the
bottom panel, which display messages about the
home network situation or receive information
from remote client.
The client GUI shows IEEE1394 network topology, SNMP switch network topology, LonWorks
network topology. In the IEEE1394 network topology that adopts the driver of the libraw1394 to get
the network information because Java language
doesn’t support the IEEE1394 drive.
In the SNMP switch network topology adopts
the SNMP4J API that classes are capable of creating, sending, and receiving SNMPv1/v2c/v3
messages. SNMP4J receives SNMP messages
through the listen port of transport mappings to
get the Ethernet network information.
In the LonWorks network topology adopts the
web page to simulate the i.Lon 100 web page. The
i.Lon 100 web service can control the devices on
and off or set up the time when the devices will be
on and off, and it also shows the device status.
When the topology changes, the text panel will
show the possibility problems to let user fixed the
problem easier. Figure 19 illustrates diagnosing
process and the changes of SNMP switch network
topology after plug in the IP-based device. That
SNMP network topology is changed from three
nodes into the four nodes.
All process on WBEM-based Local Vehicular
Network Management and Diagnosis System are
matching management object format (MOF) file
CIM in the management infrastructure of WBEM.
No matter is topology information or diagnosis
knowledge.
reFerences
Ai, Y., Sun, Y., Huang, W., & Qiao, X. (2007).
OSGi based integrated service platform for automotive telematics. In Proceedings of the IEEE
International Conference on Vehicular Electronic
and Safety, (pp. 1-6).
Chen, J. (1998). A Study of Web-Based SNMP
Network Management with a Simple Java Applet
Network Monitoring Tool. Department of Computer Science and Engineering Auburn University,
Alabama.
329
Remote Vehicular System Management Functions and Information Structure
Kim, J. H., Seo, S. H., Moon, T. Y., Hwang, S. H.,
& Jeon, J. W. (2007). A method of improving the
reliability of the gateway system by using OSEK/
VDX. In Proceedings of IEEE International
Conference on Control, Automation and System,
(pp. 2328-2833).
Mariño, P., Poza, F., Dominguez, M. A., & Otero,
S. (2009). Electronics in automotive engineering:
A top-down approach for implementing industrial
field bus technologies in city buses and coaches.
IEEE Transactions on Industrial Electronics,
589–600. doi:10.1109/TIE.2008.2002723
Marples, D., & Kriens, P. (2001). The Open Services Gateway Initiative: An Introduction Overview. IEEE Communications Magazine, 39(12),
110–114. doi:10.1109/35.968820
Park, C. K., Kang, J. M., Choi, M. J., Hong, J. W.,
Lim, Y. H., & Choi, M. S. (2008, Jan.). An Integrated Network Management System for MultiVendor Power Line Communication Networks. In
Proceedings of the IEEE International Conference
on Information Networking, (pp.23-25).
Park, C. K., Kang, J. M., Choi, M. J., Hong, J. W.,
Lim, Y. H., Ju, S., & Choi, M. S. (2008). Definition of common PLC MIB and design of MIB
Mapper for multi-vendor PLC network management. In Proceedings of the IEEE International
Symposium on Power Line Communications and
Its Applications, (pp.152-157).
330
Park, J. G., Ahn, C. W., Cho, H. N., Byun, I. S.,
Desmons, F., & Kim, S. W. (2006). A method for
representing and transporting CIM operations
using binary XML in the WBEM architecture. In
Proceedings of the 8th International Conference
on Advanced Communication Technology, (Vol.
3, pp.20-22).
Saito, T., Tomoda, I., Takabatake, Y., Arni, J., &
Teramoto, K. (2000). Home gateway architecture and its implementation. IEEE Transactions
on Consumer Electronics, 46(4), 1161–1166.
doi:10.1109/30.920474
Sun, Y., Huang, W. L., Tang, S. M., Qiao, X., &
Wang, F. Y. (2007). Design of an OSEK/VDX
and OSGi-based embedded software platform for
vehicular applications. In Proceedings of the IEEE
International Conference on Vehicular Electronic
and Safety, (pp. 1-6).
Thompson, J. P. (1998). Web-based enterprise management architecture. IEEE Communications Magazine, 36(3), 80–86. doi:10.1109/35.663331
331
Chapter 19
Using Wireless Mesh Network
for Traffic Control
Kun-Chan Lan
National Cheng Kung University, Tainan, Taiwan, R.O.C.
absTracT
Wireless mesh networks (WMN) have attracted considerable interest in recent years as a convenient,
flexible and low-cost alternative to wired communication infrastructures in many contexts. However, the
great majority of research on metropolitan-scale WMN has been centered around maximization of available bandwidth, suitable for non-real-time applications such as Internet access for the general public.
On the other hand, the suitability of WMN for missioncritical infrastructure applications remains by and
large unknown, as protocols typically employed in WMN are, for the most part, not designed for realtime communications. In this chapter, we describe a real-world testbed, which sets a goal of designing
a wireless mesh network architecture to solve the communication needs of the traffic control system in
Sydney, Australia. This system, known as SCATS (Sydney Coordinated Adaptive Traffic System) and used
in over 100 cities around the world, connects a hierarchy of several thousand devices -- from individual
traffic light controllers to regional computers and the central Traffic Management Centre (TMC) - and
places stringent requirements on the reliability and latency of the data exchanges. We discuss some
issues in the deployment of this testbed consisting of 7 mesh nodes placed at intersections with traffic
lights, and show some results from the testbed measurements.
inTroducTion
Adaptive traffic control systems are employed in
cities worldwide to improve the efficiency of traffic flows, reduce average travel times and benefit
DOI: 10.4018/978-1-60566-840-6.ch019
the environment via a reduction in fuel consumption. One of the main and most common functions
of such systems lies in adaptive control of traffic
lights. This ranges from simple lengthening or
shortening of green and red light durations in an
intersection according to the actual presence of cars
in the respective lanes, to coordination of green light
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Using Wireless Mesh Network for Traffic Control
phases among neighboring intersections on main
thoroughfares. This adaptivity is made possible
with the use of sensors (typically in the form of
magnetic loop detectors embedded under the road
pavement) that feed data to roadside traffic light
controllers, and a communications infrastructure
that connects among the intersections and a traffic management centre, as well as, in some cases
(typically in large cities), a hierarchy of regional
computers (RC) that perform the control decisions
for respective portions of the system.
Traditionally, the communications layer of
traffic control systems has been based on wired
connections, either private or leased from public
telecommunications operators. While for many
years such leased lines (operating at 300bps)
have served their purpose well, they have several
shortcomings, such as a significant operating
cost, inflexibility, and difficulty of installation in
new sites. In certain cases, alternative solutions,
operating over public infrastructure, have been
deployed for specific sites where private or leased
lines were not a viable option; these ranged from
ADSL, regular dialup, or cellular (GPRS). However, using public network for traffic control could
suffer from inconsistent delay jitters and reliability
issues. For example, previous experimental studies
(Chakravorty et al., 2002) have shown GPRS links
could have very high RTTs (>1000ms), fluctuating
bandwidths and occasional link outages.
In recent years, there has been considerable
interest in wireless mesh networks and their
deployment in metropolitan areas, from both a
commercial and a research perspective (Lundgren
et al., 2006). Trials in several major cities in the
US (e.g. Philadelphia, New Orleans, and others
(Tropos networks, 2009; Locust world, 2009) and
worldwide (e.g. Taiwan (Mobile Taiwan) have
shown mesh networks to be a viable technology
that can compete well with alternative “last-mile”
connectivity solutions to the public. Correspondingly, most of the research on metropolitan-area
wireless mesh networks (MAWMN) has focused
on maximising the throughput that can be extracted
332
from them, in the anticipation that their major use
will be public, for purposes such as accessing the
Internet or conducting voice calls (Ganguly et al.,
2006). On the other hand, little attention has been
directed to the aspects of reliability and latency,
which are most important if MAWMN are to be
considered for replacement of mission-critical
infrastructure, such as traffic control system
communications.
In this chapter, we describe a wireless mesh
network testbed that has been built. The testbed
physically covers seven traffic lights in the suburban area of Sydney. These intersections are
chosen because they represent a typical suburban
area with lots of traffic, foliages, pedestrians and
high-rise residential buildings. In addition, the
inter-node distance (ranging from 200 to-500m)
is representative of 90% of the distance between
traffic controllers in the Sydney CBD (Central
Business District) area. The testbed nodes have
been custom-built.
The contribution of this paper is three-fold.
First, to the best of our knowledge, our work is
one of the first efforts to study the feasibility of
using wireless mesh networking for traffic control.
Second, we describe the details of our testbed
implementation and some experiences we gained
during the deployment of the testbed in an urban
environment. Finally, we present some initial
measurement studies of link characteristics of
different wireless and wired technologies used in
our testbed (including the use of 900MHz, 2.4GHz
and 3.5GHz radios and Ethernet-over-powerline).
Although our results are still very preliminary,
they are useful to serve as a reality check toward
the goal of applying wireless mesh networking
to traffic control applications.
The rest of this paper is structured as follows.
In section 2, we describe the details of SCATS, the
traffic control system used in Sydney and many
other cities worldwide, and its communication
requirements. We describe related work in Section 3. Section 4 presents a simple analysis of
the topology of traffic lights in the Sydney met-
Using Wireless Mesh Network for Traffic Control
ropolitan area, and in particular the dependence
of the degree of connectivity of the mesh on the
radio range. Section 5 describes the details of our
testbed implementation. We present some initial
measurement results of link characteristics of
different radio technologies used in our testbed
in section 6. Section 7 discusses the experiences
we gained during the deployment of our testbed.
We conclude the paper and discuss the future
work in section 8.
scaTs oVer wireless
In this section, we first describe the details of
SCATS (Sydney Coordinated Adaptive Traffic
System) and its communication requirements.
We then discuss the benefits and research challenges when running SCATS on a wireless mesh
network.
The scaTs Traffic
management system
Developed and maintained by the Roads and
Traffic Authority (RTA, formerly Department of
Main Roads) of the state of New South Wales,
the Sydney Coordinated Adaptive Traffic System
(SCATS) is one of the most popular traffic management systems used worldwide. Its main task is to
adjust, in real time, signal timings in response to
variations in traffic demand and system capacity.
Real-time data from traffic controllers are collected
and transported to a central traffic management
centre (TMC) for analysis and optimum control
of road traffic. The performance of SCATS, therefore, depends critically on the capabilities of the
underlying communication system that transports
roadside data to and from the TMC.
The existing communication system of SCATS
relies strongly on third-party wired infrastructure
(provided by Telstra, Australia’s largest telco). The
bulk of the communications to the intersections,
namely the traffic light controllers and vehicle
detectors, are predominantly made using serial
point-to-point connections over standard voicegrade telephone lines, using 300bps modems. This
is also the most common method of connecting between the TMC and other lowbandwidth devices,
including variable message signs, variable speed
limits, ramp meters, and over-height detectors.
At the core of the SCATS operation is a periodic
exchange of messages between the controlling
computer and each and every intersection (via
the point-to-point links). This exchange happens
every 1sec, and is initiated by the computer which
sends to the intersection’s local controller a command message, instructing it about the next phase
it should switch to and the timing of that switch.
The controller, in turn, is required to reply with
an acknowledgement, which includes information
from the intersection’s sensors. If an acknowledgement is not received within 1sec from the time
the command message is sent, it is retried once;
after the second time an acknowledgement fails
to arrive, the communications link is declared
failed, and SCATS instructs all controllers at the
respective cluster of intersections to fall back into
a ‘default’ self-controlling mode, where decisions
about the timing of green light phases are made
locally and independently. Likewise, a controller
will fall back to this mode upon not receiving a
command message. Once triggered, a controller
will stay in the self-controlling mode for at least
15 minutes; if another communications failure
happens during this time, the duration of this
mode will be extended by another 15 minutes,
and so on. Obviously, the self-controlling mode,
where the decisions at intersections are uncoordinated, can lead to a severely suboptimal traffic
control, particularly in a busy thoroughfare during
rush hour. Accordingly, though the bandwidth
required from the communication links is quite
low (comfortably handled by 300bps modems),
the 1sec latency is critical for an efficient operation of the system.
333
Using Wireless Mesh Network for Traffic Control
The currently used SCATS infrastructure,
based on wired communications, suffers from the
following problems:
•
•
•
Slow installation and inflexibility. In most
cases, installing a new line at a road site
(especially a remote site) involves earth
excavation, which is very slow and with
adverse effects on existing infrastructure.
High capital and operating cost. The installation of a wired connection at a new
site, or repairs at an existing one, carries
a high cost due to the material and labour
required. More importantly, the ongoing
fees for leasing the wires from the telephone company run very high; currently,
RTA pays nearly $40 million annually to
Telstra in leasing fees for connecting the
traffic signals and other roadside devices to
SCATS.
Low bandwidth. Modem-based leased
lines support bandwidth less than 32 Kbps.
While these low-bandwidth telephone lines
are adequate for connecting traffic signal
sensors, they cannot provide adequate support for connecting high-bandwidth applications, e.g. higher solution video cameras,
which increasingly becoming necessary to
effectively monitor traffic pattern on our
roads.
going wireless
With wireless solutions, there is no cabling
involved. Wireless can therefore provide fast installation and exceptional flexibility. Cost can be
reduced significantly by building a private wireless network, because there will be no monthly
charges to be paid to telephone company (some
small license fee may apply). Moreover, the installation cost will be low because there will be
no cabling-related labour. The cost issue is, in
fact, the major concern for most road authorities.
Finally, it should be noted that recent advances
334
in wireless technology provide bandwidth that is
more than adequate for connecting many highresolution roadside cameras to SCATS.
One possible option for going wireless is to
build a dedicated RTA wireless network using
widely available, standards based, low-cost wireless technologies, e.g. IEEE 802.11x and 802.16x.
802.11x equipment is cheaper, less complex, and
operates entirely in the unlicensed spectrum (no
licensing fee). On the other hand, 802.16x is more
reliable (has multiple carrier frequencies to avoid
interference), has longer range, and better features
to cater for a diverse range of communication
needs of future roadside equipment. In addition,
it is possible to operate 802.16x in both license
and unlicensed spectrums.
Despite of its enormous benefits, there are
several challenges when roadside ITS equipment
is connected via wireless media:
•
•
Latency. Wireless can potentially increase
latency. For example, IEEE 802.11x, uses
a common wireless channel (it is cheaper
to share channel) among many contending devices causing potential conflict. To
avoid such conflicts, some form of medium
access control (MAC) is implemented by
these technologies. MAC introduces some
delay before data can be transmitted on the
wireless channel.
Reliability. Wireless signals are susceptible to interference from other signals in
the vicinity operating in the same or adjacent spectrum. Given that ITS equipment
is deployed in public area, such interference will be the norm rather than exception. Interference can corrupt messages
transmitted over the wireless medium.
Some frequencies do not work well (or at
all) if there is no direct line-of-sight between the two communicating end points.
In a dynamic context of public roads,
roadside equipment may frequently face
line-of-sight problems due to transient
Using Wireless Mesh Network for Traffic Control
•
•
obstructions, e.g. a high vehicle carrying a
tall crane etc. Also in vehicle-to-roadside
communications, a car in the near-lane
may obstruct communication between a
far-lane car and the roadside equipment.
Temporary outages, i.e., periods when no
wireless signal is available, therefore, is a
real issue to deal with.
Security. What makes wireless so vulnerable is the fact that the attacker does not
have to gain physical access to the channel
from any predefined access point. Roadside
wireless components are well within the
wireless range of passing motorists and
pedestrians, which make them vulnerable
to intrusion, denial of service, and other
forms of security threats.
Scalability. As mentioned earlier, wireless
systems are sensitive to interference from
other communicating devices operating
in the vicinity. Additionally, if a common
wireless channel is shared among all devices within a given area (cell), the MAC
delay increases rapidly as the number of
competing devices increases. Another
scalability issue arises from the processing overhead that is required at a central
radio base-station. The more remote radios
there are in communication with the central radio, the more processing that must
take place. The radio controller at the basestation will simply not be able to process
all incoming radio signals if there are too
many of them.
relaTed work
Roofnet (Bicket et al., 2005) is an experimental
802.11b/g mesh network built by MIT. Each node
in Roofnet has an antenna installed on the roof
of a building. Aguayo et al. (2004) analyzed the
link layer behavior on the Roofnet testbed and
described the impact of distance, SNR and transmission rate on the packet loss. While Roofnet’s
propagation environment is characterized by
its strong Line-of-Sight component, our work
differs from the prior work in that our links are
generally heavily obstructed 1. In addition, our
planned deployment strategy is different from the
unplanned topology in Roofnet.
For example, our antenna is mounted at a height
of about 4 meters from the ground. But the trees
on the road are typically higher than 7 meters.
Similar to our work, The WAND project
(Weber et al., 2003) has built a multi-hop wireless testbed in the centre of Dublin. They have
11 nodes mounted on traffic lights along a 2km
route in urban area. However, their topology is
simpler than ours (i.e. a chain topology) and the
measurements they performed on their testbed
were relatively limited.
TFA project (Camp et al., 2006) aimed to provide broadband access to low income community
in Houston area via wireless mesh network technology. Their architecture consist of two wireless
tiers: an access tier to connect homes, businesses,
and mobile users to the infrastructure, and a backhaul tier to forward traffic to and from the wired
entry point. Jardosh et al. (2005) discussed the
correlation of link reliability with the frame retransmissions, frame sizes and data rate by collecting trace data from a structured 802.11b network
during a international conference. They concluded
that sending smaller frames and using higher data
rates with a fewer number of frames improves the
performance of congested network.
All the previous studies have been centered
around maximization of available bandwidth for
non-real-time applications such as broadband
access for the general public. On the other hand,
this testbed is the first to focus on using wireless
mesh networking for traffic control which places
stringent requirements on the reliability and latency of the data exchanges.
335
Using Wireless Mesh Network for Traffic Control
a simple analysis oF
The sydney TraFFic
lighT Topology
This analysis was based on data provided by RTA,
indicating the latitude and longitude of traffic
controllers. Figure 1 shows points at each traffic
controller location. As shown in Figure 1, there
are around70 controllers in a 4km × 6km area.
To understand the effect of radio range on the
degree of connectivity when the traffic controllers
are forming a mesh network, we calculate the
shortest distance (assuming that the radio has a
circular radio range and have perfect coverage in
Figure 1.Location of traffic controllers
Figure 2. Map of intersection locations
336
that range) between every pair of traffic controllers,
and the output was then sorted so that for each
controller, its neighbours were listed (from nearest
to furthest) with the distance to each neighbour. We
then processed this data to determine how many
neighbours of each traffic controller were within
a specified range (from 100m to 1250m).
The results of this analysis are shown in Figure
3, which shows on the y-axis how many traffic
controllers had 0, 1, 2, 3, . . . neighbours when a
given radio range is assumed (x-axis). The results
shown in Figure 3 provide a rough indication of
what radio range is needed if we are aiming to
interconnect a certain number of nodes with each
node having a certain degree (number of neighbours within range). For example, if we seek to
interconnect 90% of the nodes (accepting that
some alternative technology may be needed for
the minority 10% of nodes) and require that each
node has three neighbours (to provide redundancy
and hence fault tolerance), then we require a radio
technology with range of at least 1km. Note that,
while city environments may have large densities
of traffic controllers in both (lat/long) dimensions,
in suburban environments controllers (particularly
those that are important to synchronise with communication links) often lie linearly along main
arterial roads, with few controllers in close range
Using Wireless Mesh Network for Traffic Control
orthogonal to the main arteries. Neighbours that
form a line would not provide the same level of
fault tolerance as those that are better separated
angularly around a controller, since the links are
less likely to fail independently.
TesTbed
In this section, we provide the details of this testbed. We first describe the environment that the
testbed is located. Next, the hardware used and
the software installed on each of these nodes are
discussed.
environment
The testbed is located in the Sydney CBD (Central
Business District) area. Seven intersections are
selected to deploy the testbed, as shown in Figure
2 (specifically, intersection number m1 to m7).
A number of custom-build embedded PCs with
multiple wireless interfaces are used. The nodes
are mounted on the traffic lights at a height of
about 2-3m from the ground, and distributed along
the streets in the form of rectangle covering an
area of 500 × 1000 square metres at a distance of
200-500m apart. None of the nodes is in a clear
line of sights of its neighboring nodes. The node
Figure 3.Numbers of neighbours within certain
radio range of RTA controllers
at intersection m1 is connected to a gateway node
in University of Sydney.
The streets where the network is deployed are
about 10- 20m wide and surrounded by building
at least two stories high. The majority of these
buildings are made of concrete and steel that
block the propagation of radio signals into the
neighboring streets. All these streets have busy
public traffic during business hours. Most of the
vehicles on the street have a height of less than
2.5m. But some double-decker buses (such as
Sydney Explorer Bus) or truck can have a height
of more than 5m.
channel characteristics
Wireless channels can be coarsely characterized
by its path loss exponent. Pathloss described the
attenuation experienced by a wireless signal as a
function of distance. The amount of variations in
pathloss between similar propagation scenarios
is called shadowing. In other words, shadowing
represents the difference between the signal power
at different points in the same environment with
the same estimated pathloss. Prior study (Rapport
et al., 1996) showed that shadowing can be modeled as a zero-mean Gaussian random variable.
Specifically, one can predict the received signal
power at a given distance d with the following
formula:PdBm(d ) = PdBm(d 0) - 10a log 10(d
d 0) + _ where a is the pathloss exponent, _ is
the shadowing and d 0 is the reference distance.
The prior work (Rapport et al., 1996) suggested
that the pathloss can range from 2 to 5 for outdoor
urban environment.
Such physical level measurements are important for an efficient deployment (i.e. overestimating pathloss can result in overprovioning network
while underestimating pathloss can produce disconnected network). By using linear regression,
the environment of this testbed is found to have
a pathloss a = 3.1 and shadowing _ = 7.2 .
Note that the observed pathloss in this environment is significantly lower than the suggested
337
Using Wireless Mesh Network for Traffic Control
urban pathloss of 4 in the literature (Rapport et
al., 1996).
hardware
The hardware components used for the nodes
in this testbed are off-the-shelf products including the following, as shown in Figure 4. All the
components are mounted on two sides of a metal
plate for easy maintenance (one can simply swap
an old plate with a new plate when we want to
upgrade the node). A custom-built enclosure is
made to house this component plate.
•
•
Motherboard: A VIA MB720F Mini-ITX
motherboard featuring an 1GHz processor
and 1GHz memory is employed as the core
in our system.
Storage: The traffic pole sometimes vibrates a lot due to the passing traffic. Since
that our node is mounted on a traffic pole,
instead of using a hard-drive, we employ
a 2G USB flash drive for storing OS and
data. Unlike a hard-drive, a flash drive
does not have a high speed spinning platter
and is less failure-prone.
Figure 4. Hardware component
338
•
Wireless interfaces: Each node has two
wireless interfaces to connect to its neighboring nodes, as shown in Figure 5. To allow the testbed users to experiment with
different radio technologies, two different
radio frequencies are currently used on the
testbed: 2.4GHz (802.11b/g) and 900MHz
radios. Specifically, the nodes at intersection m2, m3 and m6 are installed with
two 2.4GHz mini-PCI wireless cards from
Ubiquiti (SR2). The nodes at intersections
m1 and m5 are equipped with one 2.4GHz
Ubiquiti SR2 card (with a transmission
power of 400mW) and one 900MHz
Ubiquiti SR9 card (with a transmission
power of 700mW). Finally, the nodes at
intersections m4 and m7 are installed with
two Ubiquiti SR2 cards. One of these two
SR2 cards is connected to a 2.4GHz-to900MHz converter (from RFlinx) to send
2.4GHz signal output by the wireless card
on 900MHz band. Due to its better penetration rate for buildings and trees, theoretically the use of 900MHz radios could
result in a better connectivity than 2.4GHz
radios (i.e. 802.11x). Hence, 900MHz
Using Wireless Mesh Network for Traffic Control
•
•
radios are used at intersection pairs m1m5 and m4-m7. These two intersection
pairs have a longer distance (i.e. 400m and
500m respectively) than the other intersection pairs.
Back-haul connection: In addition to the
two Ubiquiti wireless cards, each node is
equipped an “Unwired” modem (Unwired
wireless, 2009) to establish a back-haul
link back to NICTA for the purpose of remote management, as shown in Figure 5.
Unwired is a Sydney-based metropolitan
wireless ISP. The Unwired modem uses a
proprietary protocol but claims to be a variant of WiMAX and operates in a licensed
3.5GHz band.
Ethernet router: A Linux-based Ethernet
router (Diamond Digital R100) is installed
in each node. We employ this Ethernet
router for several purposes. First, it is used
as an Ethernet switch to connect the motherboard and the Unwired modem (and any
IP-based devices such as a camera in the
future). The Unwired modem is connected to the WAN port of the router, thus the
router get a public Internet IP address. The
motherboard has an Ethernet connection
with the router’s 4-port switch. Second, the
Diamond Digital router has an USB port
which allows the motherboard to have a serial connection with the router’s USB port
through an USB-to-serial adapter. Being
able to establish a serial link to the motherboard allows the user to remotely login
into the serial console for troubleshooting
when the Ubiquiti wireless interfaces are
not responding. Third, given that the router
is a Linux box itself (runs on openWRT),
we can run all the existing software (e.g.
we are currently running DNS, NTP and
VPN clients on it). Finally, the Diamond
Digital router has an 802.11 wireless interface which can be used as an alternative
•
•
•
•
•
•
link to remotely connect the mesh node in
addition to Unwired and Ubiquiti links.
Power: As shown in Figure 4, an off-theshelf power-board (with surge protector
and fuse) and a PC power-supply are used
to provide the power to all the components in the node. The power-board takes a
240AC power from the traffic light.
Antenna: Nodes on this testbed are all installed with omni-directional antennas due
to the following
Cost: An omni-directional antenna is typically cheaper than a directional antenna. In
addition, for a node which has n neighbors,
n directional antennas are needed. On the
other hand, one omni-directional antenna
per intersection is sufficient to cover all the
neighbors.
Mounting. The space on the traffic light
for the mounting of antennas is quite limited. It is comparatively more difficult to
mount a directional antenna on the traffic
pole in practice. An 8dBi omni-directional
antenna is used for the 2.4GHz wireless
card and an 6dBi omni-directional antenna
is used for the 900MHz wireless card.
Weatherproof: The temperature in the
summer can be above 40 Celsius degree in
Sydney. The temperature inside the node
can be even higher. As shown in Figure 4,
to provide enough air circulation inside the
node, many holes are drilled on the bottom
of the enclosure and made some air louvres
on the side. Two temperature-controlled
fans are used in the node to dissipate the
hot air out through the louvres. In addition,
a roof is mounted on top of the enclosure
to shield the enclosure from direct sunlight
and rain.
Remote recovery: Due to the fact that the
testbed is deployed in an outdoor environment, it is time consuming to visit the
nodes when something goes wrong. In addition, given that nodes are mounted on the
339
Using Wireless Mesh Network for Traffic Control
Figure 5. Testbed topology
traffic lights which are a public asset, visiting any node on the testbed required calling
out the RTA maintenance crew to gain access to the node. Therefore, some means of
remote recovery are necessary. Therefore,
one wireless remote switch is installed on
each node (runs in the unlicensed 433MHz
band), which allows one to reboot the node
on-site when accessing the node via the
2.4GHz or 3.5GHz links fails.
The ultimate goal of this testbed is to control
traffic lights using wireless mesh networks. A
pair of power-over- Ethernet adapters (Netcomm
NP285) is used to connect the node to a traffic
controller board in the curbside housing through
the powerline. The traffic controller board sends
and receives data via a serial interface. Hence, a
serial-to-IP conversion is required for the communication between the traffic controller and the
testbed (which runs IP). The traffic controller
board is mounted inside an embedded PC and
connected to the embedded PC’s motherboard’s
(VIA MB770F) serial port. A serial-to-IP converter software is written and run on the PC to
340
encapsulate the SCATS data from the serial port
of the traffic controller board into an IP packet
as well as to encapsulate the IP packet from the
regional computer and send its payload to the
serial interface.
In order to connect the testbed to the regional
computer, a gateway node at University of Sydney
is deployed. The gateway node has a reasonable
line-of-sight to intersection m1 and connects to the
m1 node with a 802.11 link. Note that the Unwired
links are not used to connect the regional computer
(RC) to the testbed due to the consideration of reliability, latency and cost issues. More details about
the characteristics of Unwired links are described
in Section 6. The RC is connected to the gateway
node via AARNet (Aarnet - australia’s research and
education network, 2009). The round-trip delay
between RC and the gateway is about 1.2ms, and
the throughput is typically over 100Mbps.
software
The testbed node uses a custom-built Linux OS image that consists of the following components:
Using Wireless Mesh Network for Traffic Control
•
•
•
•
The image size is small enough to be fit
into an USB flash drive. And run completely in RAM (1GB). This allows one to
enable ’clean’ reboots uncontaminated by
previous experiments.
Some kernel modifications are added for
various driver supports for USB, madwifi
and PXE reboot.
Grub is used and modified to activate the
watchdog timer at the time of boot-loading
so that the watchdog timer can be started
before any program start. Watchdog timer
is used to reboot the motherboard when the
system fails.
Various tools are used including timesync, Open- VPN, some network support tools and software from Orbit project
(Raychaudhuri et al., 2005) in our image.
The image is built to be Debian-based for
the compatibility with Orbit software.
The OS image is based on DSL-N (Damn small
linux). DSL-N provides most of the software support we need out of the box. The default syslinux
bootloader of DSL-N is replaced with grub. OML
software (Singh et al., 2005) from Orbit project
is used to build the measurement collection infrastructure for the testbed. Two security mechanisms
are currently implemented. First, OpenVPN is used
for the Unwired links to each of the mesh nodes.
Second, ssh and friends are used on all network
interfaces. In addition, root access is disabled on
all the machines.
link latency
The round-trip delay increases as the number of
hops increases on the 802.11 links. In addition, the
variation also increases significantly when there
are more hops. There is no strong correlation between distance and link latency though. As shown
in Figure 6, the latency does not increase from
300m to 400m. However, the variation increase
significantly as the distance increases. It is due to
that there are more retries at 300m than at 400m
due to different line-of-sight conditions.
We next examine the efficiency of power line
communication. As suggested in Figure 7, given
a distance of 100m, the link latency of power
line communication is excellent. The average
round-delay is about 3.6ms and the variations
are very small. In addition, the largest delay for
such a distance is less than 8ms. As described in
Section 5, the Unwired network is used to carry
out our back-haul traffic. To understand the expected latency of running management traffic
over the Unwired network, the round-trip delay
to the mesh node is measured. As shown in Figure
8(a), the average delay of sending traffic over
the Unwired network to the mesh node is about
400ms. However, there is a large variation (the
delay can be as long as 3 seconds) and significant
number of outages. The delay and outages over
Figure 6. Effect of distance on round-trip delay
link characTerisTics
In this section, some results of measured link
characteristics from the testbed are described.
Specifically, some statistics of the wireless link
performance are discussed in terms of round-trip
delay, loss and throughput. Ping is used to measure
the round-trip delay and iperf for the throughput
measurement.
341
Using Wireless Mesh Network for Traffic Control
Figure 7. Latency of powerline communication
the Unwired network are mostly contributed by
the wireless link between the mesh node and the
Unwired ase station. As shown in Figure 8(b), the
average delay of the Unwired wireless link is about
200ms. The large delay variations and significant
number of outages suggest that a public-shared
wireless network like Unwired is not suitable for
operating SCATS traffic.
losses
As shown in Figure 9 and Figure 10, the packet
loss seems to be distributed uniformly over time.
Figure 8. Round-trip delay over the Unwired network
342
However, the loss becomes more bursty as the
number of hops and distance increase. Note that
Figure 9 and Figure 10 are based on the results
from a low probing rate (i.e. one-packet-persecond
ping). The loss pattern might change if we change
the probing rate. In addition, we do not find there
is a strong correlation between packet loss and the
distance. The line-of-sight condition (which is
location-dependent) plays a more important role on
the packet loss. The use of 900MHz radio results in
a much lower loss rate (0.5%) than 2.4GHz radio
(20%), which is not surprising though since
900MHz radio has a better penetration rate than
2.4GHz radio. Finally, for a distance of 100m, the
loss rate of power line communication is almost
negligible (less than 0.1%).
Throughput
As shown in Figure 11, the use of 900MHz radio
results in a better throughput than when 2.4GHz
radio is employed, even for a longer distance.
There is a larger variation when using 900MHz
radio, which might be due to MAC-layer retransmission. The throughput of Ethernet-over-power
line communication is very stable and typically
maintained at about 600Kps.
Using Wireless Mesh Network for Traffic Control
Figure 9. Effect of number of hops on consecutive
packet loss
Figure 10. Effect of distance on consecutive
packet loss
Figure 11. Comparison of throughput for different technologies
deploymenT issues
In this section, we discuss some issues in terms of
the deployment and maintenance of our testbed
in an urban environment.
deployment
•
Hardware. Many antenna connectors were
held on by weak glue or crimp. Gradual
stress (e.g. vibration) could eventually loosen the plug and degrade the signal before it
is transmitted into the air. Some protection
of the antenna plug might be necessary be
necessary for an operational network to
ensure there is no signal leakage from the
antenna connector. In addition, while the
appearance of the hardware might look
identical, it is safer to check if the hardware does comply with the specification
before starting using it. For example, some
of Senao wireless cards used do not output
a transmission power of 200mW as they
should be according to the specification.
343
Using Wireless Mesh Network for Traffic Control
•
•
Software. Most of the wireless measurements are based on readings from the
wireless cards. However, while the hardware can be identical, different firmwares
and drivers could introduce inaccuracy in
the measurement results. If possible, one
should try to validate the readings from
a wireless card against the results from a
spectrum analyser.
Antenna locations. As described in
Section 5, each node is equipped with
three antennas, including two 2.4GHz
(or one 2.4GHz and one 900MHz) omnidirectional antennas and one 3.5GHz directional antenna. To facilitate the ease of
mounting, all three antennas are mounted
on a pole and then mount this pole on the
traffic light. Specifically, one omni-directional antenna is pointing upward and the
other is pointing downward while the directional antenna is mounted in between.
The location of antenna can have an effect
on the link performance. Figure 12 shows
the round-trip delays from node m2 to
its neighboring node m3 using the omnidirectional antennas. The use of the lower
antenna results in a higher loss and a larger
variation. One possible explanation is that
the upper antenna might be less obstructed and hence has a better connectivity. At
2.4GHz, a quarter wavelength is approximately 30cm. Antenna position changes
in the range 10-30 cm can cause dramatic
changes in signal strength, presumably due
to the presence of standing waves in the vicinity of the traffic light pole or more specifically in the vicinity of metal stop signs
and the like! If multiple antennas are deployed, it is essential to have a means for
independently adjusting their position.
maintenance
•
•
Figure 12. Effect of antenna locations on round-trip delay
344
Remote management: Remote management is challenging, the following ways
are provided to allow the user to access the
nodes.
To access the Linux-based Ethernet
router: The router can be connected via the
Unwired link over OpenVPN. In the case
when the OpenVPN connection can not be
established, given that a public IP address
is obtained for each router from Unwired,
one can connect to the router via its public
IP address, although this could introduce a
Using Wireless Mesh Network for Traffic Control
•
dependency on a dynamic DNS lookup. In
addition, one can connect to the mesh node
first and then connect to the router via the
Ethernet or USB-to-serial link between the
router and the motherboard.
To access the mesh node: One can connect
to the mesh node (i.e. the motherboard) by
first connecting to the router and then connect to the motherboard via the Ethernet or
USB-to-serial link. Being able to access the
motherboard via its serial port is important
since the Ethernet link might fail for various reasons. In addition, one can access the
motherboard via its 802.11 interfaces from
any reachable neighboring nodes. In addition, the following mechanisms are implemented to recover the system from failure.
First, and the default way to recover from a
failure is to login to the offending router or
motherboard using one of the above methods, analyse the problem and/or reboot the
node. Second, the watchdog timer support
on the MB720 is used. In addition, Grub is
setup to fall back to a stable backup image
which is installed in a separate partition in
case when the default image fails. Finally,
the BIOS is configured to give top priority
to PXE network boot but DHCP server is
configured in a way that it does not provide
PXE boot information in the default case.
Therefore the node defaults to its second
priority, which is to boot from the USB
flash drive. However, in the event of a node
failure (for example, due to a bad image)
the DHCP server can be quickly reconfigured to support the PXE boot. Having rebooted the node using PXE, a new working
disk image can be distributed to the node
via frisbee or FTP. In practice, one might
use FTP instead of frisbee since that frisbee
introduce more control traffic overhead on
the Unwired links, which charges for every
bits send to the nodes.
•
Security: Security is a major concern especially when the wireless mesh testbed is
sharing public spectrum with an average
of 50+ external APs at each intersection.
Furthermore, the testbed is effectively connected to the Internet via Unwired network,
and exposed to various password attacks.
In a live deployment for traffic control, the
mesh security should be integrated with
the traffic control system security model,
which may include e.g. segmentation to
contain the damage of a denial of service
or break-in attack, combined with multiple
levels of fallback to local control.
conclusion
In this chapter, we discuss some issues in deploying
a testbed as a first step towards creating a fully
functional wireless mesh network-based traffic
control system. In addition, we describe some
initial results of link characteristics of different
technologies used on our testbed. Many research
challenges such as latency, reliability, security and
scalability are need to be addressed.
reFerences
Aarnet - australia’s research and education network. (2009). Retrieved from http://www.aarnet.
edu.au/
Aguayo, D., Bicket, J., Biswas, S., Judd, G., &
Morris, R. (2004). Link-level measurements from
an 802.11b.
Bicket, J., Aguayo, D., Biswas, S., & Morris, R.
(2005). Architecture and evaluation of an unplanned 802.11bmesh network. In Proceedings
of the 11th annual international conference on
Mobile computing and networking(MOBICOM),
Cologne, Germany. Available from http://www.
pdos.lcs.mit.edu/papers/roofnet: mobicom05/
roofnet-mobicom05.pdf
345
Using Wireless Mesh Network for Traffic Control
Camp, J., Robinson, J., Steger, S., & Knightly,
E. (2006). Measurement driven deployment of a
two-tier urban mesh access network. In Proceedings of ACM MobiSys 2006, Uppsala, Sweden.
Available from http://networks.rice.edu/papers/
sys7122-camp.pdf
Chakravorty, R., & Pratt, I. (2002). Performance
issueswith general packet radio service. Journal of
Communications and Networks (JCN), 4(2). Available from http://www.cl.cam.ac.uk/Research/
SRG/netos/papers/comob-web/2002-jcn.pdf
Mobile taiwan applications promotion project
m-taiwan. Retrieved from http://www.pwlan.org.
tw/mp.asp?mp=3
Rapport, T. S. (1996). Wireless communications
principles and practice. Upper Saddle River, NJ:
Prentice Hall.
Damn small linux not (dsl-n), (n.d.). Retrieved
from http://www.damnsmalllinux.org/dsl-n/
Raychaudhuri, D., Seskar, I., Ott, M., Ganu, S.,
Ramachandran, K., Kremo, H., et al. (2005).
Overview of the orbit radio grid testbed for
evaluation of next-generation wireless network
protocols. In Proceedings of the IEEE Wireless
Communications and Networking Conference,
New Orleans, LA, USA.
Ganguly, S., Navda, V., Kim, K., Kashyap, K.,
Niculescu, D., Izmailov, R., et al. (2006). Performance optimizations for deploying voip services in
mesh networks. Retrieved from http://www.wings.
cs.sunysb.edu/%7Eanand/papers/jsac06.pdf
Singh, M., Ott, M., Seskar, I., & Kamat, P. (2005).
Orbit measurements framework and library (oml):
Motivations, design,implementation, and features.
In Proceedings of IEEE Tridentcom 2005, Trento,
Italy.
Jardosh, A., Ramachandran, K., Almeroth, K. C.,
& Belding-Royer, E. M. (2005). Understanding
congestion in ieee 802.11b wireless networks. In
Proceeding of ACM SIGCOMM Internet Measurement Conference, Berkeley, CA. Retrieved
from http://moment.cs.ucsb.edu/amitj/jardoshimc2005.pdf
Tropos networks. (2009). Retrieved from http://
www.tropos.com
Locust world. (2009). Retrieved from http://www.
locustworld.com
Lundgren, H., Ramachandran, K., Belding-Royer,
E., Almeroth, K., Benny, M., Hewatt, A., Touma,
A., & Jardosh, (2006). Experiences from building
and using the ucsb meshnet testbed. IEEE Wireless network. Available from http://user.it.uu.se/
[UNKNOWN ENTITY &tildent;]henrikl/publications.html mesh network.
346
Unwired wireless. (2009). Retrieved from http://
www.unwired.com.au/
Weber, S., Cahill, V., Clarke, S., & Haahr, M.
(2003). Wireless ad hoc network for dublin: A
large-scale ad hoc network test-bed. ERCIM
News, 54. Retrieved from http://www.ercim.org/
publication/ErcimNews/enw54/weber.html
Section 7
Mobility Model, Simulation,
and Security
348
Chapter 20
Mobility Models of
Vehicular Networks
Kun-Chan Lan
National Cheng Kung University, Tainan, Taiwan, R.O.C.
absTracT
A key component for VANET simulations is a realistic vehicular mobility model that ensures conclusions
drawn from simulation experiments will carry through to real deployments. However, VANET simulations
raise many new questions about suitable levels of details in simulation models. To get accurate results,
the mobility models of Vehicular Networks should be as realistic as possible, and involve road-maps
with all constraints and facilities related to the vehicular movement. In this chapter, the authors provide
an overview of some mobility models that are relevant to VANETs. The criteria of applicability they
consider here is the employment of road maps, and thus limiting the nodes movements into the routes,
instead of moving them in a wide open area. They compare different models based on the parameters
they use. For instance, some models use traffic control mechanisms (stop signs or traffic lights) at route
intersections, and some just assume continuous movement at these points. Some assume routes to be
single-lane, some others support multi-lanes routes. Some define the security distance, while others just
ignore this parameter.
inTroducTion
To get accurate results, the model should be as
realistic as possible, and involve road-maps with
all constraints and facilities related to the vehicular
movement. In this chapter, we provide an overview of some mobility models that are relevant to
DOI: 10.4018/978-1-60566-840-6.ch020
VANETs. One of the realistic applications of mobile
Ad hoc Networking (MANET) is Vehicular Ad hoc
Networking (VANET). In VANET, communications between nodes do not rely on any dedicated
infrastructure. Although it is self-organized and easy
to deploy, the infrastructureless vehicular network
introduces many challenges that should be tackled
before real implementations. For instance, to allow
communications between nodes (vehicles) which are
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Mobility Models of Vehicular Networks
out of the power range of each other, some other
intermediaries should act as routers to remedy the
lack of dedicated routers. Thus, a distributed routing protocol needs to be employed. It is mandatory
before passing to the real deployment of a routing
protocol as well as any other protocol or application) to evaluate it by simulation. The faithfulness
of the simulation results depends on the realism
of the parameters and the models used in the
simulation, particularly on the mobility model.
This can be defined as the pattern that establish
the nodes movement within simulation area during
a simulation. The earlier mobility models used
in MANET simulation assume the terrain to be
without obstacles, and nodes to be able to move
freely in the whole rectangular stimulation area.
For example, Random way-point (RWP) (David
et al., 1996) is a typical example of such a kind
of models, which is largely used in the literature,
and available in many network simulators (ns2,
GloMoSim, etc.). This model defines the pausetime parameter, so that each node has phases of
movement and others of pause. At the beginning,
the node selects randomly and uniformly a destination where it goes using a random and constant
speed, which is also selected for each movement
following a uniform distribution. Once it reaches
this destination it stays there for the pause-time
duration, then repeats the process. It has been illustrated that this model engenders, after a given
simulation time, a spatial distribution of nodes
concentrated around the center of the simulation
area (Bettstetter et al., 2001 ; Bettstetter et al.,
2003). Generally speaking, the assumption of an
open terrain is realistic for some applications of
pedestrians, but it is inappropriate for VANET.
More recent studies propose new models constrained to routes and obstacles, and thus are more
suitable for VANET. In (Camp et al., 2002) Camp
et al. discuss a variety of mobility models used to
evaluate ad hoc networks, and split them up into
two categories: entity models and group models.
The authors show by simulation how the choice
of a mobility model can have a significant effect
on the performance results. However, except city
section (Zheng et al., 2004), all the other models
presented in this survey are inappropriate for
VANETs. In (Bettstetter et al., 2001; Zheng et al.,
2004) the authors classify the models according
to the randomness of speeds and directions, and
divide them into i) trace-based (deterministic)
models, ii) constrained topology based models
and iii) statistical (fully random) models. Based on
this classification, (Zheng et al., 2004) provides a
more recent survey of MANET’s mobility models,
presenting some ones that consider obstacles in
the simulation area. These models are suitable to
simulate pedestrian movements, but not vehicles.
In (Boudec et al., 2005), the authors provide a
mathematical and simulation investigations into
some of the statistical (random) models, and
combine them in the so-called random trip. The
most recent research works on mobility models
focus on the vehicular ad hoc network application
of MANET. (Luo et al., 2004) provides a general
survey of VANET, and the existing challenges to
overcome before the real deployment. In (Chisalita
et al., 2004) the authors discuss the usefulness of
VANET to ensure the vehicular traffic safety and
facilities, as well as the advantages it provides
compared to the other centralized technologies.
Some specified applications have been proposed,
such as the discovery of free parking places
(Caliskan et al., 2006). Regarding the mobility
models, some new ones have been specifically
proposed for VANET, such as (Amit Kumar Saha
et al., 2004 ; Choffnes et al., 2006 ; Mahajan et al.,
2006; Gorgorin et al., 2006; Karnadi et al., 2007).
In this manuscript, we first present and discuss
these novel models, as well as those proposed for
the general MANET that apply to VANET. We
also present a new vehicular traffic simulator we
implemented to generate movement trace files
usable by some well-known network simulator,
notably GloMoSim (Zeng et al., 1998) and ns2
(The Network Simulator, 2009), then we use this
tool along with GloMoSim to conduct a simulation
comparative study. Our main contribution here is
349
Mobility Models of Vehicular Networks
the investigation into the overtaking impact on
the network performance.
In the following we provide an overview on
the models that were either specially devoted to
VANETs, or proposed in the general MANET
context but usable in VANET. The criteria of applicability we consider here is the employment
of road maps, and thus limiting the nodes movements into the routes, instead of moving them in
a wide open area. As we will see, the considered
parameters differ from one model to another.
For instance, some models use traffic control
mechanisms (stop signs or traffic lights) at route
intersections, and some just assume continuous
movement at these points. Some assume routes
to be single-lane, some others support multi-lanes
routes. Some define the security distance, while
others just ignore this parameter.
Freeway is a generated-map-based model,
defined in (Bai et al., 2003). The simulation area,
represented by a generated map, includes many
freeways, each side of which is composed of many
lanes. No urban routes, thus no intersections are
considered in this model. At the beginning of the
simulation, the nodes are randomly placed in the
lanes, and move using history-based speeds. The
speed of each vehicle smoothly changes following
a random acceleration. In addition to the realism
related to the acceleration and the history based
speed, the model defines a security distance that
should be maintained between two subsequent
vehicles in a lane. If the distance between two
vehicles is less than this required minimal distance,
the second one decelerates (its acceleration is
forced to be negative) and let the forward vehicle
moves away. The change of lanes is not allowed
in this model. The vehicle moves in the lane it
is placed in until reaching the simulation area
limit, then it is placed again randomly in another
position and it repeats the process. This scenario
is definitely unrealistic.
350
manhaTTan
This is also a generated-map-based model,
introduced in (Bai et al., 2003) to simulate an
urban environment. Before starting a simulation, a map containing vertical and horizontal
roads is generated. Each of these latter includes
two lanes, allowing the movement in two directions (north/south for the vertical roads and east/
west for the horizontal ones). At the beginning
of a simulation, vehicles are randomly put on
the roads. Afterwards, they move continuously
according to history-based speeds (exactly like
Freeway). When reaching a crossroads, the vehicle
randomly chooses a direction to follow. That is,
continuing straightforward, turning left, or turning right. The probability of each decision is set
by the authors respectively to 0.5, 0.25, 0.25. The
security distance is also used in this model, and
nodes follow the same strategy as in the freeway
model to keep this distance. But contrary to the
previous model, a vehicle can change a lane at
a crossroads. Nonetheless, there is no control
mechanism at these points (crossroads), where
nodes continue their movements without stopping,
which is unrealistic.
ciTy secTion mobiliTy (csm)
CSM (Zheng et al., 2004) can be viewed as a
hybrid model between RWP and Manhattan, as
it introduces the principle of RWP, especially
the pause-time and random selection destination,
within a generated-map-based area. At each step of
the vehicle’s movement a random point is selected
from the generated road map, toward which it
moves following the shortest path. After reaching
that destination, it remains there for a pause-time,
then repeats the process. The speeds of nodes are
constrained by the security distance, along with
the maximum speed limit of the road.
Mobility Models of Vehicular Networks
real map model (rmm)
Thus far, we have presented models based on
virtual generated maps. RMM (Amit Kumar
Saha et al., 2004) is very similar to CSM, but
indeed it uses real maps, obtained from the TIGER/Lines database (Amit Kumar Saha et al.,
2004). For each route segment 1, the coordinates
are extracted and converted using the Mercator
projection (Amit Kumar Saha et al., 2004). The
extracted points are then presented by a graph,
where the crossroads are presented by vertices,
and routes by weighted arcs. The weight of each
arc is dynamically calculated in such a way to
mimic the estimated time required for a vehicle
to move over the corresponding segment, which is
proportional to its maximum authorized speed, its
distance, and the number of vehicles it currently
contains. Therefore, the lower the weight, more
the vehicles move freely in the segment. Note that
the maximum authorized speed of a route segment
depends on its type. Finally, we mention that like
all the previous models, RUM defines no control
mechanisms at crossroads.
sTop sign model (ssm)
Contrary to the previous models, SSM (Mahajan
et al., 2006) integrates a traffic control mechanism.
In every crossroads, a stop signal is put, which
obliges vehicles to slow down and make a pause
there. This model is based on real maps of the
TIGER/Lines database, but all roads are assigned
a single lane in each direction. A vehicle should
never overtake its successor (like in all the models
presented before), and should tune its speed to keep
the security distance. If many vehicles arrive at an
intersection at the same time, they make a queue,
and each one waits for its successor to traverse the
crossroads. This results in gathering of nodes, and
hugely affects the network connectivity as well as
the vehicle mobility (average speeds). According
to the authors (Mahajan et al., 2006), the problem
with this model is the unrealistic disposition of the
stop signals, since it is impossible to find a region
with stop signals at each intersection. Therefore,
they proposed TSM (Mahajan et al., 2006), which
we describe hereafter.
TraFFic sign model (Tsm)
In this model, stop signals are replaced by traffic lights. A vehicle stops at a crossroads if it
encounters a red stoplight, otherwise it continues
its movement. When the first vehicle reaches the
intersection, the light is randomly turned red, with
probability p (thus turned green with probability
1 − p). If it turns red, it remains so for a random
delay (pause-time), forcing the vehicle to stop as
well as the ones behind it. After the delay, it turns
green then the nodes traverse the crossroads one
after the other until the queue is empty. When the
next vehicle arrives at the crossroads the process
is repeated. TSM and SSM have been evaluated
by simulation with ns2 (The Network Simulator, 2009). The results show that the two models
are not significantly influenced by the speed of
nodes (maximum speeds). This is due to the traffic control models, which slow down the nodes
and give more stability to the network (Mahajan
et al., 2006). When increasing the pause-time at
the intersections, the authors remarked that the
performances improved for both models, and that
SSM gives better results than TSM when using
the same pause-time. The authors argue this by
the fact that in SSM nodes always stop at the intersections, unlike TSM. Nevertheless, in reality
the pause-time for stop signals is shorter than that
of traffic lights, which makes TSM more stable
indeed (Mahajan et al., 2006).
sTraw TraFFic
STRAW (Choffnes et al., 2006) is also a model
relying on real maps of TIGER/Line. Like the
351
Mobility Models of Vehicular Networks
other models (except freeway), the roads include
one lane in each direction, and is divided into
segments. The model is basically composed of
three modules: intra-segment mobility manager,
inter-segment mobility manager, and finally the
route management and execution module. At the
beginning of the simulation, the nodes are placed
randomly one behind the other. Then they move
using the car following model (Choffnes et al.,
2006) such that they try to accelerate until reaching the maximum speed of the segment. The first
module manages this movement until reaching an
intersection. The security distance is maintained,
and the overtaking is not allowed. At crossroads
the vehicles always slow down, even when they
change a segment and turn without a full stop,
which is realistic. The second module defines the
traffic control mechanism, which includes both
stop signals and traffic lights, put on crossroads
according to the class of the intersected routes.
In addition to this usual control form, the module
makes sure that the next segment to take contains
enough available space before moving the vehicle
toward it. If it is fully busy, the vehicle waits at
the crossroads (at the end of the first segment).
The last module selects the routes to be taken by
each vehicle during the simulation. It implements
two approaches: simple straw and straw OD. In
the first one, the direction is randomly selected
at each intersection. That is, when reaching an
intersection, the vehicle randomly decides whether
to continue straightforward, or to turn and change
the route. On the other hand, in the second approach a destination is selected toward which
the vehicle moves using the shortest path. The
simulation study made by the authors (Choffnes
et al., 2006) show that when using STRAW the
reception ratio decreases from 43% up to 53%
compared to movements in an open area. The
results of this simulation also illustrate that the
routes arrangement has an impact. Scenarios
with a high number of crossroads slow down the
average speeds of nodes, which improves the
reception ratio.
352
moVe
MOVE (Karnadi et al., 2007) is a VANET’s
mobility model that uses as the compiler SUMO
(SUMO Simulation of Urban Mobility, 2009),
which is a realistic vehicular traffic simulation
model. SUMO is an open-source application
implemented with java, that integrates many realistic parameters, such as realistic accelerations,
the usage of real maps reflecting several types
of routes (with multiple lanes), as well as traffic
lights defining priorities between vehicles. Basically, MOVE is composed of two components:
the road map editor and the vehicle movement
editor. The former serves to manually and randomly generate a road map, either from TIGER/
line files or Google earth files, whereas the latter
allows to specify the properties of each vehicle,
like the maximum speed, the acceleration, the
probability of turning at crossroads, the path to
take etc. The information collected by the two
editors is sent to the SUMO compiler, then a trace
file in ns-2 or Qualnet format is generated. MOVE
has been compared by simulation to RWP using
AODV. The results show that MOVE causes a
low reception rate.
gorgorin eT al. model
In addition to all the realistic parameters of the
previous models, this one (Gorgorin et al., 2006)
implements an overtaking mechanism within
multi-lane segments. A vehicle always tries to
move on the most right lane (the lowest rang),
except in case of overtaking during which it moves
left, and intersections in urban environments
where it chooses the lane according to the next
direction. A hierarchy of vehicle states is defined,
respectively: free driving, approaching, following, and braking (in the order). When a vehicle
is in another state than the free driving, it checks
whether higher lanes allow it to pass to a higher
state, and thus moves to the left lane to make an
Mobility Models of Vehicular Networks
Table 1.
Feature\ Model
Real maps
# lanes/direction
Freeway
Manhattan
CSM
RUM
SSM
TSM
STRAW
MOVE
Gorgorin
no
no
no
yes
yes
yes
yes
yes
yes
many
one
one
one
one
one
one
many
many
Intersections
no
yes
yes
yes
yes
yes
yes
yes
yes
Changing lanes
at intersections
no
yes
yes
yes
yes
yes
yes
yes
yes
Traffic control
no
no
no
no
stop signs
traffic
lights
both
traffic
lights+
priority
both
Overtaking
no
no
no
no
no
no
no
no
yes
Security distance
yes
Yes
yes
no
yes
yes
yes
yes
yes
Pause-time
no
No
yes
no
yes
yes
yes
yes
yes
overtaking. Identically, a vehicle in a state different
than braking checks whether the right lane allows
it to at least stay in the same state and then moves
right. Moreover, the model allows to specify the
driver type, which affect many parameters of the
vehicles (speed, acceleration, etc.). Finally, note
that the model includes both traffic lights and stop
signals at intersections. One of these two different
control mechanisms is put at each intersections
according to the types of the intersecting segments. The most important parameter added in this
model is the overtaking mechanism. However, no
study investigating this issue has been done yet.
Table 1 summarizes the features of all the models
presented in this section.
reFerences
Amit Kumar Saha, D. B. J. (2004). Modeling
mobility for vehicular ad-hoc networks. In the 1st
ACM international workshop on Vehicular ad hoc
networks (pp. 91–92). New York: ACM Press.
Bai, F., Sadagopan, N., & Helmy, A. (2003). Important: a framework to systematically analyze
the impact of mobility on performance of routing
protocols for ad hoc networks. In The 22th IEEE
Annual Joint Conference on Computer Communications and Networking INFOCOM’03, (pp.
825–835).
Bettstetter, C. (2001). Smooth is better than
sharp: a random mobility model for simulation
of wireless networks. In Proceedings of the
4th ACM international workshop on Modeling,
analysis and simulation of wireless and mobile
systems (MSWIM ’01) (pp. 19–27). New York:
ACM Press.
Bettstetter, C., Resta, G., & Santi, P. (2003). The
node distribution of the random waypoint mobility
model for wireless ad hoc networks. IEEE Transactions on Mobile Computing, 2(3), 257–269.
doi:10.1109/TMC.2003.1233531
Boudec, J.-Y. L., & Vojnovic, M. (2005). Perfect
simulation and stationarity of a class of mobility
models. In The 24th IEEE Annual Joint Conference
on Computer Communications and Networking
INFOCOM’05, (pp. 2743–2754).
353
Mobility Models of Vehicular Networks
Caliskan, M., Graupner, D., & Mauve, M. (2006).
Decentralized discovery of free parking places. In
Proceedings of the 3rd International ACM Workshop on Vehicular ad hoc networks, VANET’06,
(pp. 30–39). New York: ACM Press.
Camp, T., Boleng, J., & Davies, V. (2002). A
survey of mobility models for ad hoc network
research. Wireless Communications and Mobile
Computing (WCMC): Special issue on Mobile Ad
Hoc Networking: Research . Trends and Applications, 2(5), 483–502.
Chisalita, I., & Shahmehri, E. (2004). Vehicular
communication: A candidate technology for traffic
safety. In IEEE International Conference on Systems, Man and Cybernetics, (pp. 3903–3908).
Choffnes, D. R., & Bustamante, F. E. (2006).
An integrated mobility and traffic model for
vehicular wireless networks. In The 2nd ACM
international workshop on Vehicular ad hoc
networks, VANET’05, (pp. 69–78). New York:
ACM Press.
David, B., & David, A. (1996). Dynamic source
routing in ad hoc wireless networks. In Mobile
Computing, (vol. 35, pp. 153–181). Kluwer
Academic.
Davies, V. (2000). Evaluating mobility models within an ad hoc network. Master’s thesis,
Colorado School of Mines, Colorado, USA,
Tech. Rep.
Gorgorin, C., Gradinescu, V., Diaconescu, R.,
Cristea, V., & Ifode, L. (2006). An integrated
vehicular and network simulator for vehicular
ad-hoc networks. In the 20th European Simulation
and Modelling Conference.
354
Johansson, P., Larsson, T., & Hedman, N. (1999).
Scenario-based performance analysis of routing protocols for mobile ad-hoc networks. In
MOBICOM 99, The Fifth Annual ACM/IEEE
International Conference on Mobile Computing
and Networking, Seattle, WA (pp. 15–19).
Karnadi, F. K., Mo, Z. H., & Lan, K. C. (2007).
Rapid generation of realistic mobility models for
vanet. In IEEE Wireless Communications and
Networking Conference.
Luo, J., & Hubaux, J.-P. (2004). A survey of intervehicle communication. School of computer and
Communication Sciences, EPEL, Tech. Rep.
IC/2004/24.
Mahajan, A., Potnis, N., Gopalan, K., & Wang, A.I. A. (2006). Urban mobility models for vanets. In
Proceedings of the 2nd IEEE International Workshop on Next Generation Wireless Networks.
SUMO Simulation of Urban Mobility. (2009).
Retrieved from http://sumo.sourceforge.net/
The Network Simulator. ns2.(2009). Retrieved
from http://www.isi.edu/nsnam/ns/
Zeng, X., Bagrodia, R., & Gerla, M. (1998).
Glomosim: A library for the parallel simulation of large-scale wireless networks. In The
12th Workshop on Parallel and distributed
Simulation. PADS’98, Banff, Alberta, Canada
(pp. 154–161).
Zheng, Q., Hong, X., & Ray, S. (2004). Recent
advances in mobility modeling for mobile ad hoc
network research. In Proceedings of the 42nd ACM
annual Southeast regional conference (ACM-SE),
(70-75). New York: ACM Press.
355
Chapter 21
MOVE:
A Practical Simulator for
Mobility Model in VANET
Kun-Chan Lan
National Cheng Kung University, Tainan, Taiwan, R.O.C.
absTracT
Vehicular Ad-Hoc Network (VANET) is surging in popularity, in which vehicles constitute the mobile
nodes in the network. Due to the prohibitive cost of deploying and implementing such a system in real
world, most research in VANET relies on simulations for evaluation. A key component for VANET simulations is a realistic vehicular mobility model that ensures conclusions drawn from simulation experiments
will carry through to real deployments. However, VANET simulations raise many new questions about
suitable levels of details in simulation models for nodes mobility. In VANET simulations, the mobility
models used affect strongly the simulation output. The researchers need to decide what level of details
are required for their simulations. In this chapter, the authors introduce a tool MOVE that allows users to rapidly generate realistic mobility models for VANET simulations. MOVE is built on top of an
open source micro-traffic simulator SUMO. The output of MOVE is a realistic mobility model and can
be immediately used by popular network simulators such as ns-2 and Qualnet. The authors show that
the simulation results obtained when using a realistic mobility model such as MOVE are significantly
different from results based on the commonly used random waypoint model. In addition, the authors
evaluate the effects of details of mobility models in three case studies of VANET simulations (specifically,
the existence of traffic lights, driver route choice and car overtaking behavior) and show that selecting
sufficient level of details in the simulation is critical for VANET protocol design.
DOI: 10.4018/978-1-60566-840-6.ch021
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
MOVE
inTroducTion
VEHICULAR Ad-Hoc Network (VANET) communication has recently become an increasingly
popular research topic in the area of wireless
networking as well as the automotive industries.
While it is crucial to test and evaluate protocol
implementations in a real world environment,
simulations are still commonly used as a first step
in the protocol development for VANET research.
Several communication networking simulation
tools already existed to provide a platform to test
and evaluate network protocols, such as ns-2 (T. N.
S. ns 2, 2009), OPNET (O. Simulator, 2009) and
Qualnet (Q. N. Simulator, 2009). However, these
tools are designed to provide generic simulation
scenarios without being particularly tailored for
applications in the transportation environment.
On the other hand, in the transportation arena,
simulations have also played an important role.
A variety of simulation tools such as PARAMICS
(P. M. T. Simulation, 2009), CORSIM (CORSIM,
2009) and VISSIM (P. simulation VISSIM, 2009)
etc have been developed to analyze transportation
scenarios at the micro- and macro-scale levels.
However, there was little effort in integrating communication techniques and scenarios in a realistic
transportation simulation environment.
One of the most important parameters in
simulating ad-hoc networks is the node mobility.
It is important to use a realistic mobility model so
that results from the simulation correctly reflect
the real-world performance of a VANET. A realistic mobility model should consist of a realistic
topological map which reflects different densities
of roads and different categories of streets with
various speed limits. Another important parameter
should be modeled is the obstacles. In the real
world, a vehicle node is typically constrained to
streets which are separated by buildings, trees or
other objects. Such obstructions often increase
the average distance between nodes as compared
to that in an open-field environment. In addition,
each vehicle needs to decide a turning directions
356
at the intersection (e.g. turn left, turn right or go
straight). Such a turning model could have an
effect on the congestion of the road as well as
on the clustering of the vehicles. Furthermore,
a smooth deceleration and acceleration model
should be considered since vehicles do not abruptly
break and move. Some prior studies (Saha et al.,
2004; Heidemann et al., 2001) have shown that
a realistic model is critical for accurate network
simulation results. Selecting appropriate level
of details in the mobility model for a VANET
simulation is a critical decision. Unrealistic
mobility model can produce simulations that are
misleading or incorrect. On the other hand, adding
details requires time to implement and debug. In
addition, it might increase simulation complexity,
slow down simulation, and distract the research
problem at hand.
In this chapter, we develop a tool MOVE (MObility model generator for VEhicular networks)
to facilitate users to rapidly generate realistic
mobility models for VANET simulations. MOVE
provides an environment that allows the user to
quickly pinpoint incorrect details and manage
details overhead. Our tool is built on top of an
open source micro-traffic simulator SUMO (S. S.
of Urban Mobility, 2009). The output of MOVE
is a mobility trace file that contains information
of realistic vehicle movements which can be immediately used by popular simulation tools such
as ns-2 or qualnet. MOVE allows users to rapidly
generate realistic VANET mobility models in two
aspects:- by interfacing with real world map databases such as TIGER (Topologically Integrated
GEographic Encoding and Referencing) (TIGER,
2009) and Google Earth, MOVE allows the user
to conveniently incorporate realistic road maps
into the simulation. In addition, by providing a
set of Graphical User Interfaces that automate
the simulation script generation, MOVE allows
the user to quickly generate realistic simulation
scenarios without the hassle of writing simulation
scripts as well as learning about the internal details
MOVE
Figure 1. The architecture of MOVE
of the simulator. The architecture of MOVE is
shown in Figure 1.
In this chapter, we first describe the architecture implementation of MOVE (Section 2).
We then compare MOVE against the commonly
used random waypoint model and show that a
realistic mobility model is critical for VANET
simulations. We present three case studies that
consider three different scenarios including the
existence of traffic light, driver route choice at
the intersection, and car overtaking behavior. We
discuss how these details affect the network topology and resultingly the performance of VANET
in the simulation (Section 3).
trips of vehicles and the route that each vehicle
will take for one particular trip. We currently support three different methods to define the vehicle
movements– the vehicle movement patterns can
be manually created by the user, generated automatically, or specified based on a bus time table
to simulate the movements of public transport.
The information users input in the Map Editor
and the Vehicle Movement Editor is then fed into
SUMO to generate a mobility trace which can
be immediately used by a simulation tool such
as ns-2 or qualnet to simulate realistic vehicle
movements.
Users can also visualize the generated mobility
trace by clicking on the “Visualization” button
on the main menu, as shown in Figure 3. This is
useful for observing the details of vehicle movement (e.g. cars’ overtaking behavior) and debugging (e.g. to avoid incorrect setting of simulation
parameters).
Figure 2. Mobility model generator
archiTecTure
MOVE is currently implemented in Java and
runs atop an open-source micro-traffic simulator
SUMO. MOVE consists of two main components: the Map Editor and the Vehicle Movement
Editor, as shown in Figure 2. The Map Editor is
used to create the road topology. Currently our
implementation provides three different ways to
create the road map – the map can be manually
created by the user, generated automatically, or
imported from existing real world maps such as
publicly available TIGER database from U.S.
Census Bureau (TIGER, 2009). The Vehicle
Movement Editor allows the user to specify the
357
MOVE
Figure 3. Visualization of vehicle movements
Finally, one of the major overhead before
one can start conducting research using simulations is to learn about the internal details of the
simulator and write customized simulator-specific
scripts to generate various simulation scenarios
for the research problem under study (Floyd et
al., 2001).
To reduce such an overhead, MOVE provides
an interface to automatically generate simulation
scripts on the fly based on the parameters that the
user inputs into MOVE. We currently support
auto-generation of ns-2 and qualnet simulation
scripts, as shown in Figure 4.
Figure 4. Traffic model generation
358
map editor
In MOVE, the road map can be generated manually, automatically or imported from a real world
map. Manual generation of the map requires inputs
of two types of information, nodes and edges. A
”node” is one particular point on the map which
can be either a junction or the dead end of the
roads. Furthermore, the junction nodes can be
either normal road junctions or traffic lights.
The edge is the road that connects two points
(nodes) on a map. The attributes associated with
an edge include speed limit, number of lanes, the
road priority and the road length. Figure 5 shows
snapshots of nodes editor and edge editor. We
have also integrated Google Earth into MOVE to
facilitate the creation of nodes in a realistic setting. Google Earth is a tool that enables its user
to view the satellite image map of any place on
earth. One of the functionality that Google Earth
provides is called “placemark” which allows the
user to put a mark on any location of the Google
Earth map. Each placemark contains the longitude
and latitude information of the selected locations
and can be saved into a file in KML format (K.
tutorial). Hence, one can define the node location
on the Google map and then extract the node
information by processing the saved KML file.
This allows MOVE users to generate a map for
MOVE
Figure 5. Road map generation
any real-world road on earth for their simulations.
Figure 6 shows an example of using Google Earth
to generate nodes for the major intersections in
the Eastern Suburb of Sydney.Figure 5. Road
map generation
The road map can also be generated automatically without any user input. Three types of
random maps are currently available: grid, spider,
and random networks. There are some parameters
associated with different types of random maps
such as number of grids and the number of spider
arms and circles. Finally, one can also generate a
realistic map by importing real world maps from
publicly available database. We currently support the TIGER maps which are available from
U.S. Census Bureau. Figure 7 shows a grid map
generated from the random map generator and a
street map in the Houston area based on a TIGER
database file.
inter-departure time of the vehicles originating
from the starting road. In addition, a MOVE user
can define the probability of turning to different
directions at each junction (e.g. 0.5 to turn left,
0.3 to turn right and 0.2 to go straight) in the
editor. Figure 8(a) shows a snapshot of the Flow
definition Editor.
One can also generate vehicle movement
manually using the Vehicle Movement Editor
which allows users to specify several properties
of vehicle routes including the number of vehicles
in a particular route, vehicle departure time, origin
and destination of the vehicle, duration of the trip,
Figure 6. Generating realistic map using Google
Earth
Vehicular movement editor
The movements of vehicles can be generated
automatically or manually using the Vehicle
Movement Editor. To generate vehicle movement
automatically, one needs to first define a vehicle
flow which describes a fleet of vehicles toward
the same direction. The parameters of each flow
consist of the starting road and destination of the
vehicle fleet, the time to start and end the vehicle
flow, the number of vehicles in the flow and the
359
MOVE
Figure 7. Road map generation using the Map Editor
vehicle speed (including acceleration, deceleration
and maximum speed), etc.
Figure 8(b) shows a snapshot of the Vehicle
Movement Editor. Note that, in addition to simulating vehicle-to-vehicle communication, our tool
is also useful for simulations of vehicleto-infrastructure communication (e.g. the communication
between mobile nodes and road-side static gateway
nodes). A static node can be created in MOVE by
assigning the vehicle with a maximum speed of
zero in the Vehicle Movement Editor.
On-board communication has recently become an increasingly popular research topic. A
new paradigm of Networks in Motion is quickly
attracting interest from the research community
Figure 8. Vehicle movement generation
360
and is also being viewed as a viable commercial
solution for extending Internet services to public
transport passengers. MOVE allows users to enter
the bus time table to simulate the movements of
public transport. We model buses as a group of
vehicles which have similar parameters such as
speeds, routes, etc, associated with it as other vehicles. In addition, to model the bus time table, one
should define the departure times of the first and
the last bus and the bus inter-arrival time (which
is assumed to be constant in our implementation).
Figure 9 shows the editor for entering the bus route
information. MOVE goal is to inject the simulation with as much detail as possible to provide
a ”realistic” mobility model. We find mobility
MOVE
Figure 9. Bus route generation
model acts a leading role in VANET, it determine
the nodes location, density, and direction etcetera
that influence directly VANET performance. Yet
a ”fully realistic” simulation is not possible, in
mobility model aspect due to human behavior is
hardly description (i.e. mood, sex, age, etc.). In
addition, there have a lot of accident in the real
world, it also changed mobility model. Therefore,
simulation designers must restrict the level of detail
in some place. The challenge is to recognize what
level of detail does not influence answers to the
design questions at hand.
eValuaTion
In this section, we evaluate the impact of mobility
models generated by MOVE on the performance
of ad-hoc routing protocol. First, we compare
the performance of AODV (Perkins et al., 2003)
when used with the random waypoint model to
that using the MOVE mobility model.
The simulation experiments were carried out
in ns-2. Each simulation lasts for 900 seconds.
We generated scenarios for 150 nodes moving
in an area of 4 square kilometres. We varied the
number of source nodes from 10 to 50, each of
which is a CBR traffic source transmitting UDP
Figure 10. Comparison between Random Waypoint and model generated by MOVE
packets of a size 64 bytes at the rate of 4 packets
per second. All nodes use 802.11 MAC operating
at 2Mbps. The transmission range is 250m. The
propagation model employed in the simulation
is the log normal shadowing model. We used a
path loss exponent 2.56 with standard deviation
4.0 based on real-world measurement data from
an inter-vehicle experiment we previously carried
out in Sydney suburban area. The road topology
generated by MOVE is based on the TIGER
database data.
Figure 10 shows the packet delivery ratio of
AODV with different number of traffic sources.
Each data point represents the average of six runs
and the error bars represent the range of observed
packet delivery ratios. Overall, the packet delivery
ratios increase as the number of traffic sources
increases, which suggest a higher density of nodes
can increase the network performance as long as
the increasing density does not create more radio
interference. In addition, the packet delivery ratios
of AODV based on MOVE mobility models are
lower than when the Random Waypoint model is
used. The results generated from MOVE also have
larger variations. The larger variance in MOVE
data points is possibly due to unstable network
connectivity imposed by constrained node movements by roads and traffic control mechanisms
(such as traffic lights). Figure 10 clearly shows
361
MOVE
that the simulation results using a more realistic
mobility model can be drastically different from
that using a simplistic open field model. Note that
our results are also consistent with prior work
(Choffnes et al., 2005).
Second, we evaluate the effects of details of
mobility models in three case studies. Specifically,
we set out to understand how the existence of traffic lights, driver route choice and car overtaking
behavior affect the VANET simulation results. The
number of nodes in our simulations is 300 and the
simulation time lasts for 1000 seconds. The roads
created in the simulation have two lanes.
Traffic lights simulation
In real world, traffic lights are used to regulate traffic
flow moving in different directions. The existence
of traffic lights tends to create a “clustering” effect.
In other words, places where there is a traffic light
are likely to have a higher node density due to that
vehicles are forced to stop at the traffic light to wait
for the light to turn green. Intuitively, a high node
density might improve the network connectivity.
On the other hand, a higher node density might
also suggest a higher chance for packet collision
since more nodes might be transmitting at the same
time. In addition, the distance between two adjacent
traffic lights can have a significant effect on the
network connectivity. Specifically, the network
can be “fragmented” by the traffic lights when the
Figure 11. Clustering effect due to the traffic light
362
radio transmission range is smaller than the distance
between two adjacent clusters. In other words, a
link breakage can happen when the inter-cluster
distance is larger than the radio coverage.
Figure 11 shows the distribution of the number
of neighboring nodes when ten traffic lights are
included in the simulations. Our results show that
each node has twice the number of neighboring
nodes when traffic lights are simulated, as compared
to the case when traffic lights are not simulated.
Here we define a “neighboring node” as the node
which is within the radio range of a vehicle. Having a larger number of neighboring nodes typically
suggests a better network connectivity.
As shown in Figure 12, the packet delivery ratio
is improved when the traffic lights are simulated.
Note that in this simulation the distance between
Figure 12. Effect of traffic light
Figure 13. Effect of inter-traffic-light distance
MOVE
two adjacent traffic lights is shorter than the given
radio range. In addition, we observe that the number
of packet collisions increase as we increase the
number of traffic sources. As a result, the packet
delivery ratio decrease when there are more traffic sources.
To understand the effect of inter-cluster distance on the simulations results, we increase the
distance between two adjacent traffic lights (from
200m to 400m) so that the inter-cluster distance is
larger than the effective radio distance. As shown
in Figure 13, in this scenario we observe frequent
link breakage between two adjacent clusters which
significant degrade the network performance.
The effective radio range is around 250m in this
experiment.
overtaking simulation
In real world, a driver normally has to decide his
moving direction at an intersection. He can choose
to either go straight, turn left, or turn right. MOVE
allows a user to define the turning probability to
different directions at each intersection (e.g. 0.5
to turn left,0.3 to go straight and 0.2 to turn left)
in the Vehicle Movement Editor. As shown in
Figure 14, we find that different choices of route
directions can significantly change the simulation
results (the x-y-z notation in Figure 14 means that
the car has x% of chance to turn left, y% to go
straight and z% to turn right).
In real world, a faster vehicle can overtake some
other slower ones when overtaking is allowed on
a multi-lane road. Overtaking behavior can have a
great effect on the network topology and should be
considered. Specifically, when overtaking behavior is not allowed, it usually results in a chain-like
topology and a shorter and uniform inter-vehicle
distance (the uniform distance is due to that the
vehicle needs to maintain a safe distance from
the adjacent cars), which often suggests a better
network connectivity. We observe a dramatic
impact on the network performance when the
overtaking behavior is allowed. In addition, we
find that the effect of overtaking behavior is less
significant when the network density is higher.
As shown in Figure 15, the packet delivery ratios
in overtaking-allowed scenario is close to results
of no-overtaking scenario when we increase the
number of nodes from 250 to 350.
In summary, we show that details of mobility models such as the existence of traffic lights,
driver route choice and car overtaking behavior can
have a drastic impact on the VANET simulation
results. We argue that the faithfulness of simulation results is proportional to the realism of the
parameters and the models used in the simulations.
Therefore, selecting appropriate level of details
in the mobility model for a VANET simulation is
a very important yet challenging task.
Figure 14. Effect of driver route choice
Figure 15. Effect of car overtaking behavior
Turning simulation
363
MOVE
relaTed work
In this section, we have discussed mobile mobility
model with level of different details and VAENT
simulators. Mobility models play a critical role in
VANET. This is because mobility affects routing
and network performance etc. Therefore, the user
should carefully choose suitable mobility model
in applications.
mobility model with level
of different details
Random Way-Point (RWP) (David et al., 1996) is
the earlier mobility models used in MANET simulation. It consider without obstacles topography
and nodes to be able to move freely in simulation
area. RWP is widely to use mobility model in
simulation (Das et al., 2000 ; Holland et al., 1999
; Perkins et al., 1999,; Johansson et al., 1999.),
which only suit mobile nodes in MANET. This is
because VANET environment have obstacles and
each vehicle restrict by street. Authors of (Hong
et al., 1999) present a Reference Point Group
Mobility (RPGM) model to depict the relationship
among mobile hosts. This model based on Random
Waypoint model to use checkpoint for movement.
Although this model without any obstacle, but a
suitable checkpoint scenario can model realistic
mobility patterns. Unfortunate, a common and
realistic mobility model found hard. (Bettstetter et
al., 2001) present an improved Random Direction
Model instead of Random Waypoint Model. It introduces a stop-turn-and-go behavior for vehicles
or bicycles movement patterns that discuss alike
vehicular nodes stop over at intersection. This
model can extend to turning and stopping traffic
light events in VANET. Similar to the previous
literature, authors of (Royer et al., 2001) use simulation to present random direction model. Due to
the simulations focus on mobile ad hoc network
and without considering realistic map. In the other
words, it not suit for VANET. In addition, Hong
et al. (2001) discuss different mobility model as
364
follows: random walk (Zonoozi et al., 1997) (this
model not discuss in the paper), RWP, RPGM,
and their approach, mobility vector model. The
mobility vector model’s advantage can use for
different behavior, such as gravity model, location
dependent model, targeting model, etc. Due to it
have deceleration and change direction behaviors
for more realistic mobility model. This meaning the
model possesses basic characteristic for vehicular
mobility. But this model still hard widely use in
the real world. Although human drivers usually
is intuitive, it yet need consider different traffic
condition, such as traffic congestion or sparse. For
instance, when the traffic condition is congestion,
the vehicles only suit car following. Vice versa,
overtaking most happen at traffic sparse. Therefore, this is important phenomena.
Camp et al. (2002) survey variety of the mobility model in ad hoc networks, such as random
walk mobility, RWP, random direction mobility,
probabilistic random walk etc. This can sort two
main models: entity models and group models
for mobile node. Fortunately, VANET constrain
by street that the mobility model become simple.
But in the real world, the driver has indefinite
behavior with sex, age, mood, habits etc. effects
lead to different mobility pattern (e.g. overtaking,
car following, etc.). The traffic light also affect
vehicles movement in VANET. Bai et al. (2003 ;
2003, November) introduced RWP, group mobility, Freeway, and Manhattan mobility models. Different mobility models have especially application
and characteristics as follows: group mobility use
in military battlefield or motorcade of travel etc.
Generally, this mobility model have cluster and
both speed and direction. Freeway mobility model,
this mobility model should have car-following and
overtaking movement behaviors in general case,
such that usually happen at traffic congestion or
rarefaction. Nevertheless, the authors not mention
car following and overtaking. The urban environment use Manhattan mobility model, the mobility
model is a simple urban mobility model that the
vehicles only move along the grid of horizontal
MOVE
and vertical streets on the map. Actually, the urban
have a lot of traffic light to manage and control
traffic flow, this issue discuss in evaluation section.
Until now, we survey the mobility models that
most use RWP and without considering obstacle.
They are not suitable use on VANET.
Saha et al. (2004) proposed based-on TIGER
maps’ macro mobility model. It is only considering Dijkstra’s single source shortest path algorithm
from source to destination location. Although
use dynamic source routing protocol to evaluate
performance by NS2. However, the scheme lacks
traffic light mechanism and overtaking behavior.
Jardosh et al. (2005) present an obstacle mobility
model that the placement of obstacles that restrict
movement and signal propagation, although it
focuses discussion in mobility model of people,
but the builds can instead of extracting data from
TIGER files. This behavior spreads street restriction and build obstacles in VANET environment.
It also use distance dynamic to adjust propagation
models. This is for realistic simulation and good
idea. (Stepanov et al., 2005) Using probabilities
decide trips and use estimated travel time to
choose movement path. This can increase realistic
of mobility model that the probabilities can draw
trips’ peak and off-peak in duration. In addition,
the scheme hard get accurate travel time. This is
because VANET fast changed. The travel time easy
affect by traffic congestion or accident. In (Sven
Jaap et al., 2005), the authors present city mobility
model that build on IDM (Intelligent-Driver Model)
(Treiber et al., 2000) with probability turning. It
is meaning the model that support car following
and turning. But it cannot provide network simulator traces, without considering traffic light and
overtaking. Therefore, this model not enough call
realistic mobility model. Zimmermann et al. (2005)
proposed a voronoi-based mobility model for urban
environments, this model is using a spatial area
obtained movement paths which are computed by
the multiple application of Voronoi graphs. Due to
the vehicles movement is constrained to street by
the voronoi graph, this phenomenon fit VANET
network. In principle, this mobility model only
show obstacle in VANET network. This result same
as previous literature (Sven Jaap et al., 2005) not
consider traffic light and overtaking.
Street RAndom Waypoint (STRAW) (Choffnes
et al., 2005), it is a random waypoint constraint by
road. The scheme has considered traffic light control
and car following model. It is also use shortest path
algorithm to calculate movement path. The authors
though have considered previous condition. But
it still lack overtaking criterion that cause convey
effect in street. However, it is not realistic and then
only uses random method. Mahajan et al. (2006)
proposed Stop Sign Model (SSM), Probabilistic
Traffic Sign Model (PTSM), and Traffic Light
Model (TLM). This paper focus in traffic control
system. In SSM, each vehicle around the intersection must stop at the stop sign in duration time.
PTSM use a probability p to deice the vehicle stop,
this paper use with an empty street queue, but this
model is not coordinating among different directions. In other words, PTSM can utilize different
traffic condition to adjust traffic light time and
decrease traffic congestion. The TSM similar to
PTSM, it only changed at coordinating among different directions. Anyhow, any types’traffic control
system both has pause time to control vehicle. This
is important factor in traffic control system. When
increasing the pause time at the intersections, each
vehicle waiting time will elongate that increase
traffic congestion. In the other street, this street’s
vehicles not need stop over at intersection and move
forward, this street almost no waiting time. This is a
trade-off in different application. The authors’simulation results point out long pause-time which can
increase packer delivery ratio. This only consider
at street of local. This case is unrealistic. In (Potnis
et al., 2006), the authors have simulated SSM and
TSM mobility model to compare packet delivery
ratio. On the other hand, (Marfia et al., 2007) Using CORSIM (CORSIM, 2009) and TRANSIMS
(TRANSIMS) generate different mobility model
in downtown, and then use Qualnet to compare
network performance with vary transmission range
etc. In addition, the authors also have discussed with
infrastructure (i.e. AP) to improve packet delivery
365
MOVE
ratio. Nevertheless, the context lack more detail of
mobility model discussion, such as overtaking and
lane change impact.
VaneT simulators
Groovesim (Mangharam et al., 2005) is a topography-accurate street-map based vehicle network
simulator and is based on GrooveNet, a geographic
routing protocol for vehicular networks. It provides
several different modes of operation. In Drive
Mode, GrooveSim can process data from a GPS
unit to provide a real-time map of the vehicle’s
current location. It can also be used as an emulator
in Hybrid Simulation Mode where real vehicles on
the road and virtual vehicles in the simulation can
interact with each other. Groovesim also provides
a tool for analyzing the simulation results. One
limitation of Groovesim is that it is strongly tied
to one specific routing protocol (i.e. GrooveNet),
which limits its use for simulating other routing
protocols in a VANET environment. In addition,
GrooveSim does not provide mobility traces for
network simulators.
STRAW is an extension of SWANS (Scalable
Wireless Ad Hoc Network Simulator) (Haas et
al., 2005), a Java-based simulator for wireless
simulations. STRAW contains simulation tools for
generating mobility models and traffic models and
is also able to use real street maps like TIGER data
to build the road topology. However, currently the
mobility models can be supported by STRAW is
limited. For example, while STRAW supports multiple lanes, the vehicles are not allowed to change
lane and the starting position is not configurable.
Another drawback of this tool is its dependency on
SWANS. Finally, STRAW does not provide any
GUI that allows the users to visualize the movements of cars.
BonnMotion (B. A. mobility scenario generation and analysis tool) is a simple tool that can be
used to create and analyses mobility scenarios.
Similar to MOVE, the mobility scenarios created by BonnMotion can be exported to ns-2 and
qualnet. However, BonnMotion only models ba-
366
sic motion constraints and does not consider any
micro-mobility. Furthermore, BonnMotion is a
text-based application that runs on a command shell
and does not provide any graphical user interfaces
as MOVE does. Complementary to these previous
efforts, our work emphasizes on creating a tool that
allows users to rapidly generate realistic mobility
models for VANET simulations.
conclusion and FuTure work
In this chapter, we describe a tool MOVE which
is based on an open source micro-traffic simulator
SUMO. MOVE allows user to quickly generate
realistic mobility models for vehicular network
simulations. In addition, MOVE provides an interface to automatically generate simulation scripts
for ns-2 and qualnet. Finally, we show that the
simulation results using MOVE is significantly
different from that using the commonly used random waypoint model. Moreover, we have offered
traffic light, turning, and overtaking cases studied in
VANET simulation. Each case have different effect
in simulation, thus selecting a suit level of detail
for a simulation is key point. MOVE is publicly
available and can be downloaded via the following
URL - http://lens1.csie.ncku.edu.tw/MOVE/.
reFerences
B. A. mobility scenario generation and analysis tool,
http://web.informatik.uni-bonn.de/iv/mitarbeiter/
dewaal/bonnmotion/.
Bai, F., Sadagopan, N., & Helmy, A. (2003) “Important: a framework to systematically analyze
the impact of mobility on performance of routing
protocols for ad hoc networks,” in The 22th IEEE
Annual Joint Conference on Computer Communications and Networking INFOCOM 2003 (pp.
825–835).
MOVE
Bai, F., Sadagopan, N., & Helmy, A. (2003, November) “The important framework for analyzing
the impact of mobility on performance of routing
for ad hoc networks,” AdHoc Networks Journal Elsevier Science, vol. 1, no. 4 (pp. 383–403).
Bettstetter, C. (2001) “Smooth is better than sharp:
a random mobility model for simulation of wireless
networks,” in Proc. MSWiM01, ACM.
Camp, T., Boleng, J., & Davies, V. (2002). “A survey
of mobility models for ad hoc network research,”
in Wireless Communications and Mobile Computing (WCMC): Special issue on Mobile Ad Hoc
Networking: Research . Trends and Applications,
2(5), 483–502.
Choffnes, D. R., & Bustamante, F. E. (2005) “An
integrated mobility and traffic model for vehicular
wireless networks,” in Proc. of the 2nd ACM International Workshop on Vehicular Ad Hoc Networks
(VANET), Cologne, Germany. [Online]. Available:
http://www.aqualab.cs.northwestern.edu/publications/DChoffnes05vanet.html
CORSIM. (2009). http://www.fhwa-tsis.com/.
CORSIM. http://mctrans.ce.ufl.edu/featured/tsis/
version5/corsim.htm.
Das, S. R., Perkins, C. E., & Royer, E. M. (2000)
“Performance comparison of two on-demand
routing protocols for ad hoc networks,” in Proc.
IEEE Infocom.
David, B., & David, A. (1996) “Dynamic source
routing in ad hoc wireless networks,” in Mobile
Computing, vol. 35, Kluwer Academic (pp.
153–181).
Floyd, S., & Paxson, V. (2001) “Difficulties in simulating the Internet,” ACM/IEEE Transactions on
Networking, vol. 9, no. 4 (pp. 392–403). [Online].
Available: http://www.icir.org/vern/papers.html
Haas, Z. J., & Barr, R. (2005) “Density-independent,
scalable search in ad hoc networks,” in Proceedings
of IEEE International Symposium on Personal Indoor and Mobile Radio Communications. [Online].
Available: http://jist.ece.cornell.edu/docs/050911density.pdf
Heidemann, J., Bulusu, N., Elson, J., Intanagonwiwat, C., Lan, K. C., Xu, Y., et al. (2001) “Effects of
detail in wireless network simulation,” in Proc. of
Communication Networks and Distributed Systems
Modeling and Simulation Conference, Jan. 2001.
[Online]. Available: http://www.isi.edu/johnh/
PAPERS/Heidemann00d.html
Holland, G., & Vaidya, N. H. (1999) “Proc. mobicom, acm intern. conf. on mobile computing and
networking,” in Proc. IEEE Infocom.
Hong, X., Gerla, M., Pei, G., & Chiang, C.-C.
(1999) “A group mobility model for ad hoc wireless networks,” in Proc. ACM MSWiM.
Hong, X., Kwon, T., Gerla, M., Gu, D., & Pei, G.
(2001, January) “A mobility framework for ad
hoc wireless networks,” in Proc. of ACM Second
International Conference on Mobile Data Management (MDM 2001).
Jardosh, A. P., Belding-Royer, E. M., Almeroth,
K. C., & Suri, S. (2005) “Real-world environment
models for mobile network evaluation,” in In the
IEEE Journal on Special Areas in Communications
- Special Issue on Wireless Ad hoc Networks.
Johansson, P., Larsson, T., Hedman, N., Mielczarek,
B., & Degermark, M. (1999) “Routing protocols
for mobile ad-hoc networks - a comparative
performance analysis,” in IEEE MOBICOM, p.
195V206. K. tutorial, http://www.keyhole.com/
kml/kml tut.html.
Mahajan, A., Potnis, N., Gopalan, K., & Wang, A.
A. (2006) “Urban mobility models for vanets,” in
in Proc. of the IEEE Workshop on Next Generation
Wireless Networks (WoNGeN).
367
MOVE
Mangharam, R., Weller, D. S., Stancil, D. D., Rajkumar, R., & Parikh, J. S. (2005) “GrooveSim:
A topography-accurate simulator for geographic
routing in vehicular network,” in Proc. of the 2nd
ACM International Workshop on Vehicular Ad Hoc
Networks(VANET),Cologne,Germany.[Online].
Available: http://www.andrew.cmu.edu/user/rahulm/Research/Pubs/ vanet05 mangharam.pdf
Marfia, G., Pau, G., Giordano, E., Sena, E. D.,
& Gerla, M. (2007) “Evaluating vehicle network
strategies for downtown portland: Opportunistic
infrastructure and importance of realistic mobility
models,” in proc. of MoBiOpp 2007, co-located
with ACM/USENIX International Conference
on Mobile Systems, Applications, and Services
(MobiSys 2007).
P. simulation VISSIM. (2009). http://www.english.
ptv.de/.
Perkins, C., Belding-Royer, E., & Das, S. (2003)
“Ad hoc on demand distance vector (aodv) routing,” rFC 3561.
Perkins, C. E., & Royer, E. M. (1999) “Ad-hoc
on-demand distance vector routing,” in Proc.
IEEE Workshop on Mobile Computing Systems
and Applications.
Potnis, N., & Mahajan, A. (2006) “Mobility models
for vehicular ad hoc network simulations,” in proc.
of the 44th annual Southeast regional conference,
ACM (pp. 746–747).
Royer, E. M., Melliar-Smithy, P. M., & Mosery,
L. E. (2001) “An analysis of the optimum node
density for ad hoc mobile networks,” in Proc. of
the IEEE International Conference on Communications, Jun. 2001.
S. S. of Urban Mobility. (2009). http://sumo.
sourceforge.net/.
Saha, A. K., & Johnson, D. B. (2004) “Modeling
mobility for vehicular ad hoc networks,” in Proc. of
the 2nd ACM International Workshop on Vehicular
Ad Hoc Networks (VANET). [Online]. Available: http://www.cs.rice.edu/amsaha/ Resume/
vanet2004/vanet2004.pdf
368
SimulationP. M. T. (2009). http://www.paramicsonline.com/.
SimulatorO. (2009). http://www.opnet.com/.
SimulatorQ. N. (2009). http://www.scalablenetworks.com/.
Stepanov, I., Marron, P.-J., & Rothermel, K.
(2005l) “Mobility modeling of outdoor scenarios
for manets,” in Proceedings of the 38th annual
Symposium on Simulation ANSS ’05, Apr. 2005
(pp. 312–322).
Sven Jaap, M. B., & Wolf, L. (2005) “Evaluation of
routing protocols for vehicular ad hoc networks in
city traffic scenarios,” in in Proc. of the 5th International Conference on Intelligent Transportation
Systems Telecommunications (ITST).
T. N. S. ns 2.(2009). http://www.isi.edu/nsnam/
ns/index.html.
TIGER (Topologically Integrated GEographic
Encoding and Referencing). (2009). http://www.
census.gov/geo/www/tiger/.
TRANSIMS. http://transims.tsasa.lanl.gov/.
Treiber, M., Hennecke, A., & Helbing, D. (2000)
“Congested traffic states in empirical observations
and microscopic simulations,” IPhys. Rev., vol.
62, no. 2.
Zimmermann, H.-M., Gruber, I., & Roman, C.
(2005) “A voronoi-based mobility model for urban
environments,” in in Proc. Of the European Wireless 2005 (EW05) .
Zonoozi, M. M., & Dassanayake, P. (1997).
User mobility modeling and characterization of
mobility patterns . IEEE Journal on Selected
Areas in Communications, 15(7), 1239–1252.
doi:10.1109/49.622908
369
Chapter 22
Security Attacks of
Vehicular Networks
Jen-Chun Chang
National Taipei University, Taiwan, R.O.C.
Chun-I Fan
National Sun Yat-sen University, Taiwan, R.O.C.
Ruei-Hau Hsu
National Sun Yat-sen University, Taiwan, R.O.C.
absTracT
The application of vehicular ad hoc network (VANET) improves driving safety and traffic management.
Due to the above applications, security attacks on VANET can be serious threats all the time. VANET
is a special form of mobile ad hoc network (MANET). Hence any attacks exist on MANET also can be
arisen on VANET. Moreover, some special attacks can be raised on VANET, which do not exist on MANET.
Nevertheless, some characteristics of VANET can be positive effects and some can be negative effects
on security issues. Before designing the security mechanism to defend attacks, the authors should take
the positive effects and avoid the negative effects on the security of VANET. Furthermore, the authors
class all possible attacks of VANET from every network layer. They also introduce the reason of forming
every attack and the possible effect on VANET in detail. Therefore this chapter helps understanding the
latent threats and the useful resources of security issues on VANET.
inTroducTion
In recent years, people have fixed their eyes upon
traffic-safety topic, because current traffic accident
statistics are notoriously horrific. According to the
European Red Cross Road Safety Campaign report,
approximately 43,000 people die every year on the
roads of the European Union (EU), with around 1.8
DOI: 10.4018/978-1-60566-840-6.ch022
million people injured, and the costs associated with
traffic accidents estimated 160 billion euros. The
annual costs associated with crashes (like hospital
bills and damaged property) total nearly 3 percent
of the world’s gross domestic product (GDP) in
2000, or roughly US $1 trillion. In order to reduce
the traffic accidents, governments and researchers
around the world try to find out effective solutions,
and Vehicular Communication (VC) system, or we
can also call it Vehicular ac hoc network (VANET),
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
Security Attacks of Vehicular Networks
seems to be one of the answers and will be ubiquitous everywhere in the not-too-distant future.
Vehicular ac hoc network (VANET) is likely
to become the most universal and relevant form
of ad hoc networks due to the urgent need of
driving safety. Another reason about the fast
development of VANET is the impact to the
market. There are more than 50 applications have
been submitted by major car manufactures like
BMW, Daimler-Chrysler, Ford, and GM which
are based on Dedicated Short Range Communication (DSRC) technology. DSRC is a short range
wireless protocol specifically for automotive use.
It offers communication between vehicles and
Road Side Units (RSUs). This technology for
VANET applications is working in the 5.9 GHz
band (U.S) or 5.8 GHz band (Japan, Europe).
VC system includes two types of communications:
Inter-vehicle communication (IVC) (or someone call it Vehicle-to-vehicle (V2V) communication) and Roadside-to-vehicle communication
(RVC) (or someone call it Vehicle-to-infrastructure (V2I) communication). All two types are
based on wireless multi-hop communication.
inter-Vehicle communication
•
•
•
Properties that have a negative effect:
•
•
•
IVC systems have some properties that support
security and others that are negative effect.
Properties that have positive effects.
•
•
370
No energy constraints: unlike the sensor node in ad hoc network and/or sensor
network and some mobile device, such as
cellular phone and personal digital assistant (PDA), cars usually provide enough
energy to operate communication system
and related computation of security.
Known position and time: This information is required for most safety application on VANET. This information can also
be used to security application.
Limited physical access: The operator of
IVC usually limited to the owner of car or
authorized personnel.
Periodic maintenance: Cars always
need to be maintained in a period of time.
Therefore, the IVC also can check and update regularly.
Secure computing platform: Automotive
environment it seems inevitable that some
kind of secure computing platform must be
available in the future.
•
•
High mobility: High degree of mobility is
one of properties of vehicles. It means that
the average speed of the node of VANET
will be very high and the average connection
time will be very short. Therefore, when we
design the security mechanism, the communication time and computation time should
be considered.
Large number of nodes: IVC network can
be a huge ad hoc network. Scalable solutions for adequate and sufficient performance should be considered.
No centralized infrastructure: When we
deal with a distributed ad hoc network, the
centralized infrastructure is only available
at specific situations. The design of some
security building block should be adapted
to such kind of infrastructure, such as trust
management and key distribution and requires new concepts.
Privacy concerns: Privacy is a serious
problem in IVC system because cars are
highly personal devices and the owners
will keep it for a long duration. The system
design should reflect the need for flexible
identifiers.
No user interaction: The scenario of IVC
system is that no user interaction possible
since it could distract drivers and reduce the
popularity and usability of IVC system.
Security Attacks of Vehicular Networks
One of famous IVC system model is proposed by the network on wheels (NoW) project.
The NoW system is a generic model for IVC
architecture. This model consists of four major
aspects. First, the radio channel and the protocol
are used on NoW system. Second, the hardware
and the software running on NoW. The three major
kinds of platform are within the NoW system,
one is onboard units (OBU), that are installed
in the vehicles, road side units (RSUs) as parts
of some road infrastructure, and the HomePC or
commercial Access Points providing content or
Internet access. Third, the input of sensor to the
different processing units, that can be all kinds of
physical sensors, such as temperature, oil on the
road and so on. Finally, the security infrastructure
behind the NoW system consists of some elements, like the vehicle manufacturers, certification authorities, traffic authorities, and certified
staff. The following figure (Figure 1) is a generic
system model of NoW.
Roadside-to-vehicle communication (RVC)
is used to complement IVC. If VANET just use
IVC as communication only, all connections must
be established by multi-hop communication, it
is a huge works and consume large amount of
resources. That is the reason we must use IVC
and RVC interchange. We can also connect to
Internet through RVC and get other multimedia
services, like on-line TV, on-line game …etc. That
make everything come true and vehicles are not
just vehicles, they become to be entertainment
centers.
We will introduce VANET characteristics,
architecture, applications and its security attack
separately. VANET is a special or even exceptional case of mobile ad hoc network (MANET).
MANET is one kind of wireless ad-hoc network,
it is not only include the same characteristics as
wireless ad-hoc network, such as an open peer-topeer network architecture, lack a central instance,
each node is willing to forward data for other
nodes, self-configuration and self-maintenance
capabilities. Fully distributed nodes may move
arbitrarily and change their topology frequently
without prior notice.
Figure 1. The architecture of NoW system
371
Security Attacks of Vehicular Networks
The archiTecTure oF
Vehicular neTwork
VANET architecture is composed of two kinds
of communicating nodes, including vehicles
(nodes) and Road Side Units (RSUs). Vehicles
can also be split into two parts: private (belonging
to individuals or private companies) and public
(public transportation vehicles, e.g., buses, and
public services)
The network architecture can roughly split into
three domains (shown in Figure 2): the in-vehicle
domain, the ad hoc domain and the infrastructure
domain. The in-vehicle domain is a sub-network
(of the VANET) with an On Board Unit (OBU) and
several Application Units (AUs), such as Personal
Digital Assistant (PDA), mobile phone… etc.
The ad hoc domain is composed of multiple
OBUs and RSUs along the road. OBUs and RSUs
are equipped with IEEE 802.11-like wireless technology. They can either communicate each other
directly or through multi-hop communication.
Figure 2. VANET architecture
372
The infrastructure domain provides connectivity
to Internet nodes. The vehicles can get applications
like multimedia services through RSUs to Internet. If
the vehicle we want to communicate is out of range
that multi-hop can reach, we can use OBU to connect
to RSU of ad hoc domain we located, and the RSU
will communicate to RSU where the vehicle we want
to connect located, and then we can access to the
vehicle as two RSUs as intermediate nodes.
The applicaTions oF
Vehicular neTwork
VANET could provide several safety applications
(Lin et al., 2007) to protect driver and passenger
and ubiquitous multimedia services. These safety
applications include Electronic Emergency Barke
Light (EEBL), Road Hazard Condition Notification (RHCN), Road Feature Notification (RFN),
Slow Vehicle Alert (SVA), and Post Crash Notification (PCN). These safety applications could
Security Attacks of Vehicular Networks
Figure 3. High-level system architecture view
help driver the dangerous situation or the condition of traffic to void possibly dangers or threats.
EEBL notifies drivers when a vehicle is closed to
them and rapidly decelerates. It could avoid the
chance of accident of rear-end collisions. RHNC
broadcast the information of road hazard, such as
snow accumulation or trash. RFN alerts drivers
the landform or sections with special limitation
they will pass. If drivers approach a steep hill,
school, they may need to slow their speed with a
must lower ones to avoid accidents. SVA and PCN
alert drivers a slow vehicle or a possible crash in
the lanes ahead. The information of such safety
applications are come from all nodes of VANET.
Due to these safety applications, drivers have more
time to reach to avoid some dangers or accidents
that may happen with huge damages.
The aTTacks oF
Vehicular neTwork
VANET is a special or even exceptional case
of MANET, it includes all security attacks that
MANET faced and owned. Watch out – there still
exists some VANET-specific attacks.
There is one thing we MUST keep in mind
that security attack is cross-layer issue rather
single layer issue. We can totally understand the
truth from Table 1 below. The security attacks for
VANETs span the entire network protocol and not
just application layer
VANET security attacks includes
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Viruses, worms and malicious code
Bogus information attack
Message modification attack
ID disclosure of other vehicles
Movement tracking
Denial of Services (DoS)
Impersonation attack
Cheating with positioning information
RSU replication attack:
Unauthorized preemption attack
WEP vulnerability
Routing attack
Data packet forwarding attack
373
Security Attacks of Vehicular Networks
Table 1. The security attacks for VANETs span the entire network protocol stack
Layer
Application Layer
Security Attacks
Viruses, Worms, Malicious Codes, Bogus information attack, message modification attack, Movement tracking, DoS…etc.
Network Layer
Ad hoc routing attack, data packet forwarding attack, ID disclosure attack, Movement tracking, DoS…etc.
Data Link Layer
WEP vulnerability, ID disclosure attack, Movement tracking, DoS…etc
Physical Layer
DoS attacks
We will explain each attack behavior carefully below.
Viruses, worms and malicious code: Viruses,
worms and malicious code are tools used to invade
OBUs or RSUs. After intrusion is successful,
malicious user can get personal information of
OBU owner, and convey some fake information
to disturb the traffic. Therefore, the manager of
VANET system can have some strategy to avoid the
damages caused from virus, worms and malicious
code, such as the choice of operating system, the
periodic update and checking, security policy to
access operating system and so on. It is also helpful
to prevent such kind of threat to break VANET
system by policy or standard procedure.
Bogus information attack: In MANET environment, all messages are broadcast even though
messages which have definitely destination for
private use. Data is transmitted via air interface
through shared wireless medium. It is obviously
Figure 4. The in-vehicle domain
374
a loophole, and malicious user may produce fake
or untrue messages to achieve certain goals. In
VANET circumstance, bogus information may
even cause more critical consequences, like traffic jam or traffic accidents. For example: one
may send a fake traffic jam message to the other
drivers and affect their behavior in order to divert
traffic from a given road and get a better traffic
condition (See Figure 4).
Message modification attack: Some people
might consider that message modification attack
is similar to bogus information attack, but they
are totally different. Bogus information attackers
produce messages which are purely fictitious, but
message modification attackers just alter rather
create messages during or after transmission. The
message modification attacker may wish to change
the source or content of the messages.
ID disclosure of other vehicles: In VANET
architecture, data is transmitted via air interface.
Security Attacks of Vehicular Networks
And multi-hop transmission strategy makes more
and more personal information is available in the
infrastructure. According to the above two reasons,
the probability of personal information disclosure
go up quite substantially. The attackers can get
users’ personal information through eavesdropping or accessing the infrastructure illegally. We
call this attack technique as ID disclosure of other
vehicles, also known as the Big Brother scenario.
We must keep one thing firmly in mind that ID
disclosure attack is cross-layer security issue. In
order to authenticate client’s identity, every application service will execute an authentication
protocol to client. If user lose his identity, make
his identity public or eavesdropped by malicious
users, attackers can masquerade by using this
identity, and make victims to pay high payment
bill or let them as scapegoat. The attack behavior
belongs to application layer of network protocol
stack.
As we mentioned above, vehicular communication is based on IEEE 802.11-like technology.
The applications of VANET can either use wire-
less multi-hop communication or the Internet via
the TCP/IP protocol stack. Every vehicle or RSU
will be allocated a unique and static IP and MAC
addresses by authority. The addresses represent
node’s identity, and researchers try to hide the
information preventing attackers capture it. If
node’s IP and MAC addresses have been disclosed,
user’s privacy no longer exists and user’s movement will be tracked by attackers.
In Figure 5, we show header of routing packets,
it includes immutable and mutable field. Immutable are those fields that unchanged from sender
to destination even through intermediate hops
forward the packet to the destination. Mutable
fields are allocated to be altered by intermediate
nodes. We can see operation on these fields in
Figure 6.
We can induce that immutable fields are used
to store IP addresses, and mutable fields are used
to store MAC addresses. The whole routing packet
is not protected by encryption. Although malicious
user cannot disclose identity of user from application layer message, he can still catch information
Figure 5. Example of bogus information attack, attacker disseminate false information to affect the
decisions of other vehicles and thus clear the way of attacker
375
Security Attacks of Vehicular Networks
Figure 6. Example packet type with mutable and immutable fields (mutable fields are red, and immutable
fields are blue)
from routing packet. We call this attack as IP and
MAC disclosure attack.
movement Tracking
Movement tracking goal can be done by two
ways.
1.
2.
Malicious user gets victim’s identity through
ID disclosure attack first, and then he can
proceed to track victim’s movement.
Malicious user is in the area where victim’s
radio range covered. As victim move, attacker also moves with the victim. If attacker
never moves out of the radio range of victim,
he can track victim’s movement forever. This
way of movement tracking is like ‘physical’
way.
Denial of service (DoS): Denial of service attack or distributed denial of service attack (DDoS
attack) is an attempt to make a computer resource
is unavailable to its clients. We can simply explain
it as an adversary broadcasts irrelevant bulk messages to the VANET where he located in, taking
up the cannel and consume the computational
resource of the other nodes. There is one thing
376
we must keep in mind that DoS is a cross-layer
issue, from message replay attack, layer 2 packet
flooding, Radio-Frequency (RF) interference to
jamming.
A message replay attack means that a valid data
transmission is repeated or delayed maliciously.
An adversary intercepts the data from the originator and retransmits it. It may cause DoS and
paralysis network or the attacker can impersonate
other user successfully.
Every nodes of VANET want to determine
every packet’s source and destination must to
dispatch packet and check MAC address or IP
address. The dispatch action must take computation resource. If a node receives huge amount of
packets, then he will be down due to resources
are exhausted.
RF (or Electromagnetic interference, EMI)
is a disturbance that affects an electrical circuit
due to electromagnetic radiation emitted from an
external source. The disturbance may interrupt,
obstruct, or otherwise degrade or limit the effective performance of the circuit.
Impersonation attack: Impersonation attack
is also known as Masquerade. As implied by the
name, adversary actively pretends to be another
vehicle or even RSU by using false identities to
Security Attacks of Vehicular Networks
fool the others. The attacker may try to achieve
malicious or rational objectives. A malicious attacker seeks no personal benefits from the attacks
and aims to harm the members or mal-function
the network for no reason. That is why a malicious attacker is unpredictable, because his attack
is disregarding costs and profits. All he wants is
just contend to appetite for destruction. On the
contrary, a rational attacker seeks personal profit
and hence is more predictable in terms of the attack means and the attack target.
Cheating with positioning information:
Cheating with positioning information is a special
case of message modification attack. The attackers
just alter the positioning information field of the
message like perceived position, speed, direction,
and so on. Cheating with positioning information
may lead to routing attack, because position-based
routing protocol is the most popular routing algorithm in VANET environment. If routing table
is not correct, data packet cannot be forwarded
correctly, and messages may lost (e.g. sinkhole)
or cause routing loops.
RSU replication attack: Surveying the deployments of VANET, we can find out that there
exist a large number of RSUs to complement
shortcomings of multi-hop communications. If
protection of RSUs is not sufficient, they might
be compromised by malicious users. Afterwards,
attackers can use these captured RSUs to launch
any malicious attack, such as bogus information
attack and unauthorized preemption attack (as
we described below), etc. Maybe we can say
RSU replication attack is basis of unauthorized
preemption attack.
Unauthorized preemption attack: The
adversary may take control a RSU, especially a
traffic light, and then make it to provide special
traffic priority for specific vehicles. It is similar
to RSU replication attack
After introducing upper layer and cross-layer
attacks, we will discuss lower layer (such as network and link layer) attacks below:
WEP: Wired Equivalent Privacy (WEP) is
an algorithm to secure IEEE 802.11 wireless networks. Because wireless networks communication
is based on broadcast through radio, it is easier to
eavesdrop than wired networks. That is why we
need encryptosystem to provide confidentiality as
wired networks, and WEP is named as this reason.
But since 2001, cryptanalysts find several serious
weaknesses which will let WEP to be cracked by
available software about few minutes. Now we
can assure that WEP is vulnerable.
Routing attacks: The family of routing attack
is defined as any action of notifying “wrong” routing updates (which means not follow the specifications of the routing protocol). For example,
spoofing, forging of routing signaling messages
…etc. are routing attacks. These behaviors may
cause some specific attacks which are related to
the VANET, e.g: We will introduce some specific
attack behaviors which are related to the VANET,
e.g.: routing loop and malfunctioning of the network, sinkhole attack…etc. We will describe in
Data packet forwarding attack.
Data packet forwarding attack: The attackers cause the data packets to be delivered in
a way that is intentionally inconsistent with the
routing states. Another type of packet forwarding attack is the Denial-of-service (DoS) attack
via network-layer packet blasting, in which the
attacker injects a large amount of junk packets
into the network.
Because ad hoc routing protocols are various,
we will focus on position-based routing which
is one of most popular used to construct routing
table. The position–based routing protocol policy
is – a node forwards a given packet to one onehop neighbor that is closest to the destination than
others. Although position based routing protocol
(one kind of geographical routing protocols) is
common used, it is still inability to against spoofing and forging of routing signaling messages
like other ad hoc routing protocols and results
in creation of routing loops and mal-function of
the network.
377
Security Attacks of Vehicular Networks
Figure 7. Operations on mutable and immutable fields
Figure 8. Two exemplary attacks in position-based routing protocol
In Figure 7: The left figure shows a regular
forwarding process from the source via forwarders (vehicles) V1, V2 and V3 to the destination.
In the middle figure, the attacker Att forges its
location as Att’. It makes V2 selects the attacker
as next hop as next hop in the forwarding chain
because its position is closer to destination. The
attacker receives messages (that should be sent
to next hop) and drops all messages. It makes all
packets lost, and we call it ‘sinkhole’ attack. In
the right figure, the attacker forges its position as
Att’ and V2 selects the attacker as next hop in the
forwarding chain. The attacker receives all messages and forwards the received messages back
to the previous node V2. It results routing loop.
Messages will be sent back and forth but can’t be
sent to destination.
378
conclusion
In this chapter, we have shown security attacks
in VANET environment. We first briefly describe
VANET characteristics, architectures, applications. After constructing the common sense, we
elaborate all possible security attacks in VANET.
Because VANET is a special case of MANET, it
includes all MANET security attacks and some
special attacks only happened in VANET environment. Maybe someone will ask why we need to
know attacks in VANET, because VANET seems
to become the most relevant network around the
world and VANET includes an important component – human beings. The basis of VANET
development is to protect drivers from accidents,
so that VANET system must be quite reliable.
How to make VANET reliable? This is quite a
complicated question. But there is one thing for
Security Attacks of Vehicular Networks
sure that security of VANET is one of necessaries to construct a reliable VANET system. Before
we design a secure system, we must find out all
possible attacks first. That is what this chapter
shows us.
reFerences
Hubaux, J. P., Capkun, S., & Luo, J. (2004). The
Security and Privacy of Smart Vehicles. Security &
Privacy, 2(3), 49–55. doi:10.1109/MSP.2004.26
Lin, X., Sun, X., Ho, P. H., & Shen, X. (2007).
GSIS: A Secure and Privacy Preserving Protocol
for Vehicular Communications. IEEE Transactions on Vehicular Technology, 56(6), 3442–3456.
doi:10.1109/TVT.2007.906878
Aijz, A., Bochow, B., Dötzer, F., Festag, A.,
Gerlach, M., Kroh, R., & Leinmüller, T. (2006).
Attacks on Inter Vehicle Communication Systems
– an Analysis. In Proc. WIT.
Mauve, M., Widmer, A., & Hartenstein, H. (2001).
A Survey on Position-Based Routing in Mobile
Ad Hoc Networks. IEEE Network, 15(6), 30–39.
doi:10.1109/65.967595
Armknecht, F., Festag, A., Westhoff, D., & Zeng,
K. (2007). Cross-layer Privacy Enhancement and
Non-repudiation in Vehicular Communication.
In 4th Workshop on Mobile Ad-Hoc Networks
(WMAN).
Raya, M., & Hubaux, J. P. (2005). The Security
of Vehicular Ad Hoc Networks. In Proceedings
of the 3rd ACM workshop on Security of ad hoc
and sensor networks, (pp.11-21).
Eichler, S., Dotzer, F., Schwingenscholgl, C.,
Javier, F., Caro, F., & Eberspacher, J, (n.d.). Secure
Routing in a Vehicular Ad Hoc Network.
Golle, P., Greene, D., & Staddon, J. (2004). Detecting and Correcting Malicious Data in VANETs. In
Proceeding of the 1st ACM international workshop
on Vehicular ad hoc networks, Session: Security
in VANET, (pp.27-37).
Studer, A., Luk, M., Perrig, A, (n.d.). Efficient
Mechanisms to Provide Convoy Member and
Vehicle Sequence Authentication in VANETs.
Yang, H., Luo, H., Ye, F., Lu, S., & Zhang, L.
(2004). Security in mobile ad hoc networks:
Challenges and solutions. IEEE Wireless communications, 11(1), 38-47.
Harsch, C., Festag, A., & Papadimitratos, P. (2007).
Secure Position-Based Routing for VANETs. In
IEEE 66th Vehicular Techonology Conference,
(pp. 26-30).
379
380
Compilation of References
3GPP. (2008). IP Multimedia (IM) Session Handling; IM
Call Model; Stage 2. TS 23.218 v8.3.0.
Aarnet - australia’s research and education network. (2009).
Retrieved from http://www.aarnet.edu.au/
Aguayo, D., Bicket, J., Biswas, S., Judd, G., & Morris, R.
(2004). Link-level measurements from an 802.11b.
Ai, Y., Sun, Y., Huang, W., & Qiao, X. (2007). OSGi based
integrated service platform for automotive telematics. In
Proceedings of the IEEE International Conference on
Vehicular Electronic and Safety, (pp. 1-6).
Aidarous, S., & Plevyak, T. (1994). Telecommunications
Network Management into the 21st Century. New York:
IEEE Press.
Aijz, A., Bochow, B., Dötzer, F., Festag, A., Gerlach, M.,
Kroh, R., & Leinmüller, T. (2006). Attacks on Inter Vehicle
Communication Systems – an Analysis. In Proc. WIT.
Akingbehin, K. (2005). Wireless communications for intravehicle use (Wireless harnesses). Institute for Advanced
Vehicle Systems, University of Michigan-Dearborn,
Dearborn, MI.
Akyildiz, I. F., Ho, J., & Wang, W. (1999). Mobility Management in Next-Generation Wireless Systems . Proceedings
of the IEEE, 87(8), 1347–1384. doi:10.1109/5.775420
Alexopoulos, C. (1997). State Space Partitioning Methods
for Stochastic Shortest Path Problems. Networks, 1(30),
9–21. doi:10.1002/(SICI)1097-0037(199708)30:1<9::AIDNET2>3.0.CO;2-H
Alliance, O. M. (OMA). (2009). Retrieved from http://www.
openmobilealliance.org/
AMI-C. (2002). Software API Specifications-CORE APIs.
retrieved September 20 2009, from http://www.ami-c.org
Amit Kumar Saha, D. B. J. (2004). Modeling mobility for
vehicular ad-hoc networks. In the 1st ACM international
workshop on Vehicular ad hoc networks (pp. 91–92). New
York: ACM Press.
Amouris, K. (2005). Position-Based Broadcast TDMA
Scheduling for Mobile Ad-Hoc Networks (MANETs)
with Advantaged Nodes. IEEE Military Communications
Conference, 1, 252–257.
Armknecht, F., Festag, A., Westhoff, D., & Zeng, K. (2007).
Cross-layer Privacy Enhancement and Non-repudiation in
Vehicular Communication. In 4th Workshop on Mobile
Ad-Hoc Networks (WMAN).
Artimy, M. (2007). Local Density Estimation and Dynamic
Transmission-Range Assignment in Vehicular Ad hoc Networks. IEEE Transactions on ITS, 18(3), 400–412.
Asokan, N., Kostiainen, K., Ginzboorg, P., Ott, J., & Luo,
C. (2007). Applicability of identity-based cryptography
for disruption-tolerant networking. In . Proceedings of
MobiOpp, 07, 52–56. doi:10.1145/1247694.1247705
Assisted, G. P. S. (n.d.). Retrieved September 11, 2009, from
http://en.wikipedia.org/wiki/Assisted_GPS.
ASTM International E2213-03 (2003). Standard Specification
for Telecommunications and Information Exchange Between
Roadside and Vehicle Systems 5 GHz Band Dedicated Short
Range Communications (DSRC) Medium Access Control
(MAC) and Physical Layer (PHY) Specifications.
B. A. mobility scenario generation and analysis tool, http://
web.informatik.uni-bonn.de/iv/mitarbeiter/dewaal/bonnmotion/.
Bachir, A., & Benslimane, A. (2003). A Multicast Protocol in
Ad hoc Networks Inter-Vehicle Geocast. IEEE Semiannual
Vehicular Technology Conference, 4, 2456-2460.
Copyright © 2010, IGI Global, distributing in print or electronic forms without written permission of IGI Global is prohibited.
Compilation of References
Backes, P., Tso, K., Norris, J., Tharp, G., Slostad, J., Bonitz,
R., & All, K. (2000). Internet based Operations for the Mars
Polar Lander Mission. In The 2000 IEEE International
Conference on Robotics & Automation, (pp. 2025-2032).
Bai, F., Sadagopan, N., & Helmy, A. (2003). Important: a
framework to systematically analyze the impact of mobility
on performance of routing protocols for ad hoc networks.
In The 22th IEEE Annual Joint Conference on Computer
Communications and Networking INFOCOM’03, (pp.
825–835).
Balasubramanian, A., Zhou, Y., Croft, B. W., Levine, B.
N., & Venkataramani, A. (2007). Web search from a bus.
In Proceedings of the second workshop on Challenged
networks CHANTS CHANTS ’07, (pp. 59–66).
Baldwin, C. L. (2002). Designing in-vehicle technologies
for older drivers: application of sensory-cognitive interaction theory. Theoretical Issues in Ergonomics Science, 3(4).
doi:10.1080/1463922021000009029
Banerjee, N., Corner, M. D., & Levine, B. N. (2007). An
energy-efficient architecture for dtn throwboxes. In . Proceedings of IEEE INFOCOM, 2007, 776–784.
Bertsekas, D. P., & Tsitsiklis, J. N. (1991). An Analysis of Stochastic Shortest Path Problems. Mathematics of Operations
Research, 16(3), 580–595. doi:10.1287/moor.16.3.580
Bettstetter, C. (2001). Smooth is better than sharp: a random
mobility model for simulation of wireless networks. In Proceedings of the 4th ACM international workshop on Modeling, analysis and simulation of wireless and mobile systems
(MSWIM ’01) (pp. 19–27). New York: ACM Press.
Bettstetter, C., Resta, G., & Santi, P. (2003). The node distribution of the random waypoint mobility model for wireless
ad hoc networks. IEEE Transactions on Mobile Computing,
2(3), 257–269. doi:10.1109/TMC.2003.1233531
Bickel, G. S. (2006). Inter/intra-vehicle wireless communication. Retrieved from http://userfs.cec.wustl.edu/~gsb1/
index.html
Bicket, J., Aguayo, D., Biswas, S., & Morris, R. (2005). Architecture and evaluation of an unplanned 802.11bmesh network. In Proceedings of the 11th annual international conference on Mobile computing and networking(MOBICOM),
Cologne, Germany. Available from http://www.pdos.lcs.mit.
edu/papers/roofnet: mobicom05/roofnet-mobicom05.pdf
Bjic, E., & Chaxel, F. (2002). Auto-ID Mobile Information
System for Vehicle Life Cycle Data Management. IEEE
Systems . Man and Cybernetics, 4, 6.
Blaževi’c, L., Giordano, S., & LeBoudec, J. Y. (2002). Self
Organized Terminode Routing. Cluster Computing Journal,
5(2), 205–208. doi:10.1023/A:1013998030317
Blum, J., Eskandarian, A., & Hoffman, L. (2004). Challenges
of inter-vehicle ad hoc networks. IEEE Transactions on Intelligent Transportation Systems, 5(4), 347–351. doi:10.1109/
TITS.2004.838218
Bojarski, A., & Fichte, W. (2003). Temperature sensors. In J.
Marek, H.P. Trah, Y. Suzuki,& I. Yokomori, (Ed.), Sensors
Application Vol. 4 - Sensors for Automotive Technology (pp.
343-359). Berlin: Wiley-VCH.
Boneh, D., & Franklin, M. (2003). Identity based encryption from the weil pairing. In SIAM Journal of Computing,
586–615.
Bonnick, A. (2001). Automotive computer controlled systems. London: Butterworth Heinemann.
Bononi, L., & Felice, M. D. (2007). A Cross Layered MAC
and Clustering Scheme for Efficient Broadcast in VANETs.
In Proceedings of the IEEE International Conference on
Mobile Ad hoc and Sensor Systems.
Boudec, J.-Y. L., & Vojnovic, M. (2005). Perfect simulation
and stationarity of a class of mobility models. In The 24th
IEEE Annual Joint Conference on Computer Communications and Networking INFOCOM’05, (pp. 2743–2754).
Boyce, D. (2002). A Memoir of the ADVANCE Project.
Journal of Intelligent Transportation Systems, 7(2).
Boyce, D. E., Kirson, A. M., & Schofer, J. L. (1994).
ADVANCE-The Illinois Dynamic Navigation and Route
Guidance Demonstration Program. Advance Technology
for Road Transport, IVHS and ATT.
Brakatsoulas, S., Pfoser, D., Salas, R., & Wenk, C. (2005).
On Map-Matching Vehicle Tracking Data. In The 31st VLDB
Conference, (pp. 853 – 864).
Brewer, E., Demmer, M., Du, B., Ho, M., Kam, M., &
Nedevschi, S. (2005). The case for technology in developing
regions. IEEE Computer, 38, 25–38.
381
Compilation of References
Briesemeister, L., & Hommel, G. (2000). Overcoming
Fragmentation in Mobile Ad hoc Networks. Journal of
Communications and Networks, 2(3), 182–187.
Broggi, A., Bertozzi, M., Fascioli, A., Guarino, C., Bianco,
L., & Piazzi, A. (1999). The Argo Autonomous Vehicle’s
Vision And Control Systems. International Journal of
Intelligent Control and Systems, 3, 409–441.
Brown, A., Kolberg, M., Bushmitch, D., Lomako, G., &
Ma, M. (2006). A SIP-based OSGi Device Communication
Service for Mobile Personal Area Networks. In Consumer
Communications and Networking Conference(CCNC).
Buede, D. M. (2000). The engineering and design of systems:
Models and methods. New York: Wiley, Inc.
Burgess, J., Gallagher, B., Jensen, D., & Levine, B. N.
(2006). Maxprop: Routing for vehicle-based disruptiontolerant networks. In . Proceedings of IEEE INFOCOM,
2006, 1–11. doi:10.1109/INFOCOM.2006.228
Burns, B., Brock, O., & Levine, B. N. (2005). Mv routing
and capacity building in disruption tolerant networks.
Proceedings of IEEE INFOCOM, 1, 398–408.
Bushmitch, D. Lin, Wanrong., Bieszczad, A., Kaplan, A.,
Papageorgiou, V., & Pakstas, A. (2004). A SIP-based device
communication service for OSGi framework. IEEE Consumer Communications and Networking Conference2006.
Caliskan, M., Graupner, D., & Mauve, M. (2006). Decentralized discovery of free parking places. In Proceedings
of the 3rd International ACM Workshop on Vehicular ad
hoc networks, VANET’06, (pp. 30–39). New York: ACM
Press.
Camp, J., Robinson, J., Steger, S., & Knightly, E. (2006).
Measurement driven deployment of a two-tier urban mesh
access network. In Proceedings of ACM MobiSys 2006,
Uppsala, Sweden. Available from http://networks.rice.edu/
papers/sys7122-camp.pdf
Camp, T., Boleng, J., & Davies, V. (2002). A survey of
mobility models for ad hoc network research. Wireless
Communications and Mobile Computing (WCMC): Special
issue on Mobile Ad Hoc Networking: Research . Trends and
Applications, 2(5), 483–502.
Chaintreau, A., Hui, P., Crowcroft, J., Diot, C., Gass, R.,
& Scott, J. (2005). Pocket switched networks: Real-world
mobility and its consequences for opportunistic forward-
382
ing. Technical report, University of Cambridge Computer
Laboratory, Cambridge, UK.
Chakravorty, R., & Pratt, I. (2002). Performance issueswith
general packet radio service. Journal of Communications
and Networks (JCN), 4(2). Available from http://www.cl.cam.
ac.uk/Research/SRG/netos/papers/comob-web/2002-jcn.
pdf
Chan, Alex Y. M., & Lu, W. P. (2003). Architecture for
Wireless Access in Vehicles. IEEE Vehicular Technology
Conference, 5, 3336-3340.
Chang, B.-J., Huang, B.-J., & Liang, Y.-H. (2008). Wireless
Sensor Network-based Adaptive Vehicle Navigation in
Multihop-Relay WiMAX Networks. The 22nd International
Conference on Advanced Information Networking and Applications, (pp. 56-63).
Chen, A., Jain, N., Perinola, A., Pietraszek, T., Rooney, S.,
& Scotton, P. (2004). Scaling Real-Time Telematics Applications using Programmable Middleboxes: A Case Study in
Traffic Prediction. In First IEEE Consumer Communications
and Networking Conference, (pp. 388-393).
Chen, J. (1998). A Study of Web-Based SNMP Network
Management with a Simple Java Applet Network Monitoring Tool. Department of Computer Science and Engineering
Auburn University, Alabama.
Chen, J. L., Chang, Y. C., Lin, Y. S., & Du, H. W. (2009).
Embedded WiMAX-based Vehicular Router for Telematics Computing. In The 11th International Conference on
Advanced Communication Technology, (pp. 1857-1862).
Chen, Y. S., Lin, Y. W., & Lee, S. L. (2009). A Mobicast
Routing Protocol for Vehicular Ad Hoc Networks. Mobile
Networks and Applications (MONET).New York: ACM/
Springer.
Chen, Y. S., Lin, Y. W., & Pan, C. Y. (2009). A DiagonalIntersection-Based Routing Protocol for Urban Vehicular
Ad Hoc Networks. Telecommunication System, (under
revision).
Chen, Y., Zhao, W., Ammar, M., & Zegura, E. (2007). Hybrid
routing in clustered dtns with message ferrying. In Proceedings of the 1st international MobiSys workshop on Mobile
opportunistic networking MobiOpp ’07, (pp. 75–82).
Chisalita, I., & Shahmehri, E. (2004). Vehicular communication: A candidate technology for traffic safety. In IEEE
Compilation of References
International Conference on Systems, Man and Cybernetics,
(pp. 3903–3908).
Choffnes, D. R., & Bustamante, F. E. (2006). An integrated
mobility and traffic model for vehicular wireless networks.
In The 2nd ACM international workshop on Vehicular ad
hoc networks, VANET’05, (pp. 69–78). New York: ACM
Press.
Choi, D. H., Ro, S. H., Lee, K. S., Lee, W. N., Choi, S. Y.,
& Pae, Y. W. (2006). Telematics Applications Based On
TOPAZ Platform. In IEEE 6th International Conference on
Computer and Information Technology, (pp.262-268).
Choi, J. W., Han, W. Y., Kim, C. S., & Kwon, O. C. (2005).
Open Telematics Services Deployment on the Gateway and
Framework Independent on Mobile Networks. In International Conference on Wireless Networks, (pp.374-379).
Chuah, M., & Xi, Y. (2007). An encounter-based multicast
scheme for disruption tolerant networks. Technical report
published by the University of Lehigh, Lehigh, PA.
Connexis website. (n.d.). Retrieved September 20, 2009,
from http://www.connexis.com/
CORSIM. (2009). http://www.fhwa-tsis.com/.
CORSIM. http://mctrans.ce.ufl.edu/featured/tsis/version5/
corsim.htm.
Damn small linux not (dsl-n), (n.d.). Retrieved from http://
www.damnsmalllinux.org/dsl-n/
Das, S. R., Perkins, C. E., & Royer, E. M. (2000) “Performance comparison of two on-demand routing protocols for
ad hoc networks,” in Proc. IEEE Infocom.
David, B., & David, A. (1996). Dynamic source routing in
ad hoc wireless networks. In Mobile Computing, (vol. 35,
pp. 153–181). Kluwer Academic.
Deflorio, F. P. (2003). Evaluation of a reactive dynamic route
guidance strategy. Journal of the Transportation Research
Board Transportation, 11(5), 375–388.
Demers, A. A., Greene, D., Hauser, C., Irish, W., Larson, J.,
Shenker, S., et al. (1987). Epidemic algorithms for replicated
database maintenance. In Proceedings of the Sixth Symposium on Principles of Distributed Computing, (pp. 1–12).
Demmer, M., & Ott, J. (2006). Delay tolerant networking
tcp convergence layer protocol. Internet-draft.
Devarapalli, V., Wakikawa, R., Petrescu, A., Thubert, P.
(2005). Network Mobility (NEMO) Basic Support Protocol
RFC 3963.
Differential, G. P. S. (n.d.). Retrieved September 11, 2009,
from http://en.wikipedia.org/wiki/Differential_GPS.
Dijkstra, E. W. (1959). A note on two problems in connection with graphs. Nuerische Mathematik, 1, 269–271.
doi:10.1007/BF01386390
Dikajakos, M. D., Florides, A., Nadeem, T., & Iftode, L.
(2008). Location-Aware Services over Vehicular Ad-Hoc
Networks using Car-to-Car Communications. IEEE Journal
on Selected Areas in Communications, 25(8), 1590–1602.
doi:10.1109/JSAC.2007.071008
DLNA. (2009). Retrieved from http://www.dlna.org/
home
Draft 7.0, IEEE Standard 1609.1 (2006). IEEE Trial-Use
Standard for Wireless Access in Vehicular Environments
(WAVE) – Resource Manager.
Drane, C., & Rizos, C. (1998). Positioning system in intelligent transport systems. Boston: Artech House.
Dreyfus, S. E. (1969). An Appraisal of Some Shortest Path
Algorithms. Operations Research, 17, 395–412. doi:10.1287/
opre.17.3.395
Duri, S., Gruteser, M., Liu, X., Moskowitz, P., Perez, R.,
Singh, M., & Tang, J. M. (2002). Framework for security
and privacy in automotive telematics. In Mobile Computing
and Networking, (pp. 25-32).
Eichler, S. (2007). Performance evaluation of the IEEE
802.11p WAVE communication standard. In Proceedings of
IEEE Vehicular Technology Conference, (pp. 2199-2203).
Eichler, S., Dotzer, F., Schwingenscholgl, C., Javier, F., Caro,
F., & Eberspacher, J, (n.d.). Secure Routing in a Vehicular
Ad Hoc Network.
EI-Rabbany. A. (2002). Introduction to GPS – The Global
Positioning System. Boston: Artech House.
Emst, T. (2006). Network Mobility Support Goals and
Requirements.
Encyclopedia.com. (2009). Telematics is not a question of
if, but when. Retrieved from http://www.encyclopedia.com/
doc/1G1-94875067.html
383
Compilation of References
Ernst, T., Uehara, K., & Mitsuya, K. (2003). Network Mobility from the InternetCAR Perspective. In 17th International
Conference on Advanced Information Networking and
Applications, (pp. 19–26).
ETSI TISPAN. (2008). Retrieved from http://www.etsi.
org/tispan/
Fall, K. (2003). A delay-tolerant network architecture for
challenged internets. In Proceedings of ACM SIGCOMM,
(pp. 27–34).
Farrell, J. A. (2008). Aided Navigation: GPS With High
Rate Sensors (pp. 22-80). New York: Glencoe/McGrawHill School Pub Co.
Farrell, S., & Cahill, V. (2005). Ltp-t: A generic delay
tolerant transport protocol. Technical report, University
of Dublin, Dublin.
Farrell, S., Ramadas, M., & Burleigh, S. (2007). Licklider
transmission protocol - extensions. Internet-draft.
Fasbender, A., Gerdes, M., Hjelm, J., Kvarnström, B., Petersson, J., & Skog, R. (2008). Virtually at home: High-performance access to personal media. Ericsson Review, 2.
munications and navigation system for multiple platforms.
In Proceedings of the IEEE/MTS OCEANS Conference,
Washington DC, (Vol. 2, pp. 1086–1092).
Friesz, T. L., Luque, J., Tobin, R. L., & Byung-Wook, W.
(1989). Dynamic network traffic assignment considered
as a continuous time optimal control problem. Operations
Research, 37(6), 893–901. doi:10.1287/opre.37.6.893
Frost & Sullivan, (2005). Strategic Analysis of the Taiwan
Telematics and Infotainment Market.
Fu, L. (2001). Adaptive Routing Algorithm for In-Vehicle
Route Guidance Systems with Real-Time Information.
Transportation Research Part B: Methodological, 35(8),
749–765. doi:10.1016/S0191-2615(00)00019-9
Fukuhara, T., Warabino, T., Ohseki, T., Saito, K., Sugiyama,
K., Nishida, T., & Eguchi, K. (2005). Broadcast Methods
for Inter-Vehicle Communications System. In Proceedings
of the IEEE Wireless Communications and Networking
Conference.
Feit, S. (1993). TCP/IP: Architecture, protocols and implementation. New York: McGraw Hill, Inc.
Ganguly, S., Navda, V., Kim, K., Kashyap, K., Niculescu,
D., Izmailov, R., et al. (2006). Performance optimizations
for deploying voip services in mesh networks. Retrieved
from http://www.wings.cs.sunysb.edu/%7Eanand/papers/
jsac06.pdf
Feit, S. (1995). SNMP: A Guide To Network Management.
New York: McGraw Hill, Inc.
Geer, D. (2005). Users Make a Beeline for ZigBee Sensor
Technology. Computer, 16–19.
Feit, S. (1995). SNMP: A guide to network management.
New York: McGraw Hill, Inc.
Gerbers, J. (2003). High-pressure sensors. In J. Marek, H.P.
Trah, Y. Suzuki,& I. Yokomori, (Ed.), Sensors Application
Vol. 4 - Sensors for Automotive Technology (pp. 333-342).
Berlin: Wiley-VCH.
Fleming, W. J. (2008). New automotive sensors−A review.
IEEE Sensors Journal, 8(11), 1900–1921. doi:10.1109/
JSEN.2008.2006452
FlexRay Communications System Protocol Specification
v2.1 Revision A. (2005).
Gerlach, M., & Fokus, F. (2007). Trust for Vehicular Applications. In 8th International Symposium on Autonomous
Decentralized Systems, (pp. 295-304).
FlexRay Consortium. (2009). Retrieved from http://www.
flexray.com
Gerten, G. (2005). Protecting the Global Positioning System.
IEEE Aerospace and Electronic Systems Magazine, 20(11),
3–8. doi:10.1109/MAES.2005.1576067
Floyd, S., & Paxson, V. (2001) “Difficulties in simulating
the Internet,” ACM/IEEE Transactions on Networking, vol.
9, no. 4 (pp. 392–403). [Online]. Available: http://www.icir.
org/vern/papers.html
Global Positioning System. (n.d.). Retrieved September 11,
2009, from http://en.wikipedia.org/wiki/Global_Positioning_System.
Freitag, L., Grund, M., Singh, S., Partan, J., Koski, P., &
Ball, K. (2005). The whoi micro-modem: An acoustic com-
384
Goel, A., Ramakrishnan, K. G., Kataria, D., & Logothetis,
D. (2001). Efficient Computation of Delay-Sensitive Routes
from One Source to All Destinations. IEEE Conference on
Computer Communications (INFOCOM), (pp. 854–858).
Compilation of References
Golle, P., Greene, D., & Staddon, J. (2004). Detecting and
Correcting Malicious Data in VANETs. In Proceeding of
the 1st ACM international workshop on Vehicular ad hoc
networks, Session: Security in VANET, (pp.27-37).
Gong, Y., Xiong, Y., Zhang, Q., Zhang, Z., Wang, W., &
Xu, Z. (2006). Anycast routing in delay tolerant networks.
In IEEE GLOBECOM (pp. 1–5).
Gorgorin, C., Gradinescu, V., Diaconescu, R., Cristea, V.,
& Ifode, L. (2006). An integrated vehicular and network
simulator for vehicular ad-hoc networks. In the 20th European Simulation and Modelling Conference.
Green, P., Levison, W., Paelke, G., & Serafin, C. (1995).
Preliminary Human Factors Design Guidenlines for Driver
Information Systems. Technical Report No. UMTRI-93-21,
Transportation Research Institute, The University of Michigan, Ann Arbor, MI.
Grossglauser, M., & Tse, D. N. C. (2002). Mobility increases
the capacity of ad-hoc wireless networks. In IEEE/ACM
Transactions on Networking, 10(4), 477–486.
Grymek, L., Singh, S., & Pattipati, K. (2007). Vehicular
Dependence Adds to Telematics’ Allure. IEEE Potentials,
26(2), 12–16. doi:10.1109/MP.2007.343053
Gsmworld.com. (2009). Retrieved from http://www.gsmworld.com/technology/gprs/index.shtml
Gun, N., Held, A., & Kaiser, J. (2001). Proactive services
in a distributed traffic telematics application. International
Workshop on Mobile Communication over Wireless LAN:
Research and Applications.
Guo, J. H., & Xing, G. M. (2007). Using Mobile Agentbased Middleware to Support Distributed Coordination
for Vehicle Telematics. In 21st International Conference
on Advanced Information Networking and Applications
Workshops, (Vol. 2, pp.374-379).
Gura, N., Held, A., & Kaiser, J. (2001). Proactive Services
in a Distributed Traffic Telematics Application. Workshop
on Mobile communication over Wireless LAN: Research
and Applications. Retrieved from http://www.informatik.
uni-ulm.de/rs/projekte/core/
Haas, Z. J., & Barr, R. (2005) “Density-independent, scalable search in ad hoc networks,” in Proceedings of IEEE
International Symposium on Personal Indoor and Mobile
Radio Communications. [Online]. Available: http://jist.ece.
cornell.edu/docs/050911-density.pdf
Hackbarth, K. (2003). OSGi – Service-Delivery-Platform
for Car Telematics and Infotainment Systems. Advanced
Microsystems for Automotive Applications 2003 (pp. 497507). Berlin: Springer.
Hall, R. (1986). The Fastest Path through a Network with
Random Time- Dependent Travel Time. Transportation
Science, 20(3), 182–188. doi:10.1287/trsc.20.3.182
Han, W. Y., Kwon, O. C., Park, J. H., & Kang, J. H. (2005).
A Gateway and Framework for Interoperable Telematics
Systems Independent on Mobile Networks. ETRI Journal,
27(1), 106–109. doi:10.4218/etrij.05.0204.0038
Harsch, C., Festag, A., & Papadimitratos, P. (2007). Secure
Position-Based Routing for VANETs. In IEEE 66th Vehicular
Techonology Conference, (pp. 26-30).
Heidemann, J., Bulusu, N., Elson, J., Intanagonwiwat, C.,
Lan, K. C., Xu, Y., et al. (2001) “Effects of detail in wireless
network simulation,” in Proc. of Communication Networks
and Distributed Systems Modeling and Simulation Conference, Jan. 2001. [Online]. Available: http://www.isi.edu/
johnh/PAPERS/Heidemann00d.html
Holland, G., & Vaidya, N. H. (1999) “Proc. mobicom, acm
intern. conf. on mobile computing and networking,” in
Proc. IEEE Infocom.
Home Gateway Initiative. (2007). Retrieved from http://
www.homegatewayinitiative.org/
Hong, X., Gerla, M., Pei, G., & Chiang, C.-C. (1999) “A
group mobility model for ad hoc wireless networks,” in
Proc. ACM MSWiM.
Hong, X., Kwon, T., Gerla, M., Gu, D., & Pei, G. (2001,
January) “A mobility framework for ad hoc wireless networks,” in Proc. of ACM Second International Conference
on Mobile Data Management (MDM 2001).
Hsu, R. C., & Chen, L. R. (2005). Integrated Embedded
System Architecture for In-Vehicle Telematics and Infotainment System. Proceedings of the IEEE International
Symposium on Industrial Electronics, 4, 1409–1414.
Hubaux, J. P., Capkun, S., & Luo, J. (2004). The Security
and Privacy of Smart Vehicles. Security & Privacy, 2(3),
49–55. doi:10.1109/MSP.2004.26
385
Compilation of References
Hughes, L., & Maghsoudlou, A. (2006). An Efficient
Coverage-Based Flooding Scheme for Geocasting in Mobile
Ad Hoc Networks. International Conference on Advanced
Information Networking and Applications, 1, 6.
Hyyrylainen, T., Karkkainen, T., & Luo, C. (2007). Opportunistic email distribution and access in challenged
heterogeneous environments. In Proceedings of the second
workshop on Challenged networks CHANTS (pp.97–100).
Ibm.com. (n.d.). Focus on the road ahead: IBM puts
practical telematics within reach. Retrieved from http://
www-306.ibm.com/software/pervasive/info/Telematics_within_reach_050404.pdf
IEEE P802.11p/D3.0. (2007). Draft amendment for wireless
access in vehicular environments (WAVE).
IEEE Standard 1609.3 (2007). IEEE Trial-Use Standard
for Wireless Access in Vehicular Environments (WAVE) –
Networking Services.
IEEE Standard 1609.4 (2006). IEEE Trial-Use Standard
for Wireless Access in Vehicular Environments (WAVE) –
Multi-channel Operation.
IEEE Std 1488-1999 (2000). IEEE Standard for Message
Set Template for Intelligent Transportation Systems.
IEEE Std 1489-1999 (1999). IEEE Standard for Data Dictionaries for Intelligent Transportation Systems.
ment 2: Physical and medium access control layers for
combined fixed and mobile operation in licensed bands
and corrigendum 1.
IEEEP802.11p (2009, May). IEEE Draft Standard for Information Technology – Telecommunications and information
exchange between systems – Local and metropolitan area
networks – Specific requirements – Part 11: Wireless LAN
Medium Access Control (MAC) and Physical Layer (PHY)
specifications Amendment 7: Wireless Access in Vehicular
Environments.
IEEEStandard1609.2 (2006). IEEE Trial-Use Standard
for Wireless Access in Vehicular Environments (WAVE)
– Security Services for Applications and Management
Messages.
IETF Network Working Group. (2008). RFC3344- IP Mobility Support for IPv4. Retrieved from http://www.faqs.
org/ rfcs/rfc3344.html
InCode Telecom Group Inc. (2009). Telematics: How economic and technological forces will shape the industry in
the U.S. Retrieved from http://www.incodewireless.com/
pdfMailer/files/Telematics_Position_Paper_v11.pdf
Institute of Transportation Engineers Management and
Operations of Intelligent Transportation Systems. (2003).
ITS standards overview.
IEEE Std 828-1998. (1998). IEEE standard for software
configuration management plans.
Internet Librarian, D. I. S. A. (1997). US-DOD Internet
related standardized profiles. Retrieved from http://wwwlibrary .itsi.disa.mil/
IEEE1609.1TM (2006). IEEE Trial-Use Standard for Wireless
Access in Vehicular Environments (WAVE) – Resource
Manager.
Internet, C. A. R. Project (2003). InternetCAR webpage at
WIDE. Retrieved September 20, 2009 from http://www.sfc.
wide.ad.jp/InternetCAR
IEEE1609.2TM (2006). IEEE Trial-Use Standard for Wireless Access in Vehicular Environments (WAVE) – Security
Services for Applications and Management Message.
Interplanetary internet project (n.d.). Interplanetary internet
project. Retrieved from http://www.ipnsig.org
IEEE1609.3 (2006). IEEE Trial-Use Standard for Wireless
Access in Vehicular Environments (WAVE) – Networking
Services.
TM
IEEE1609.4TM (2006). IEEE Trial-Use Standard for Wireless Access in Vehicular Environments (WAVE) – Multichannel Operation.
IEEE802.16-2005. (2006). Part 16: Air interface for fixed
and mobile broadband wireless access systems amend-
386
Ip, Y. K., Lau, W. C., & Yue, O. C. (2007). Forwarding and
replication strategies for dtn with resource constraints. In
. Proceedings of IEEE Vehicular Technology Conference,
1, 1260–1264.
ITS Standards Outreach, Education and Training Program,
Institute of Transportation Engineers Management and
Operations of Intelligent Transportation Systems (2003).
ITS Standards Overview.
Compilation of References
ITS Standards Outreach, Education and Training Program,
Institute of Transportation Engineers. (2006). Center to
center communications.
ITU-T X.680-X.690 (1994). ISO/IEC 8824: Abstract Syntax
Notation One (ASN.1).
Jain, S., Fall, K., & Patra, R. (2004). Routing in a delay
tolerant network. In Proceedings of ACM SIGCOMM, (Vol.
34, pp. 145–158).
Jakoby, B., & Herrmann, F. (2003). Chemical sensors for liquid media. In J. Marek, H.P. Trah, Y. Suzuki,& I. Yokomori,
(Ed.), Sensors Application Vol. 4 - Sensors for Automotive
Technology (pp. 516-526). Berlin: Wiley-VCH.
Jardosh, A. P., Belding-Royer, E. M., Almeroth, K. C., &
Suri, S. (2005) “Real-world environment models for mobile
network evaluation,” in In the IEEE Journal on Special
Areas in Communications - Special Issue on Wireless Ad
hoc Networks.
Jardosh, A., Ramachandran, K., Almeroth, K. C., &
Belding-Royer, E. M. (2005). Understanding congestion
in ieee 802.11b wireless networks. In Proceeding of ACM
SIGCOMM Internet Measurement Conference, Berkeley,
CA. Retrieved from http://moment.cs.ucsb.edu/amitj/
jardosh-imc2005.pdf
Jiang, D., & Delgrossi, L. (2008). IEEE 802.11p: Towards
an international standard for wireless access in vehicular
environments. In IEEE Vehicular Technology Conference,
(pp. 2036-2040).
Johansson, K. H., Torngren, M., & Nielsen. L. (2003). Vehicle
applications of controller area network. Technical Report
Department of Signals, Sensors and Systems, Royal Institute
of Technology, Stockholm, Sweden, Department of Electrical Engineering, Linkoping University, Sweden.
Johansson, P., Larsson, T., & Hedman, N. (1999). Scenariobased performance analysis of routing protocols for mobile
ad-hoc networks. In MOBICOM 99, The Fifth Annual ACM/
IEEE International Conference on Mobile Computing and
Networking, Seattle, WA (pp. 15–19).
Johansson, P., Larsson, T., Hedman, N., Mielczarek, B., &
Degermark, M. (1999) “Routing protocols for mobile ad-hoc
networks - a comparative performance analysis,” in IEEE
MOBICOM, p. 195V206. K. tutorial, http://www.keyhole.
com/kml/kml tut.html.
Joshi, H. P., Sichitiu, M., & Kihl, M. (2007). Distributed
Robust Geocast Multicast Routing for Inter-Vehicle Communication. WEIRD Workshop on WiMax, Wireless and
Mobility.
Jost, D., & Nagel, K. (2003). Probabilistic traffic flow breakdown in stochastic car following models. Transportation
Research Record, 1852, 152–158. doi:10.3141/1852-19
Jun, H., Ammar, M. H., & Zegura, E. W. (2005). Power
management in delay tolerant networks: A framework and
knowledge-based mechanisms. In IEEE Communications
Society Conference on Sensor and Ad Hoc Communications
and Networks (SECON), (pp. 418–429, 2005).
Jun, H., Ammar, M. H., Corner, M. D., & Zegura, E. W.
(2006). Hierarchical power management in disruption tolerant networks with traffic-aware optimization. In Proc. ACM
SIGCOMM Workshop on Challenged Networks (CHANTS),
(pp. 245–252).
Jung, C. R., & Kelber, C. R. (2005). Lane following and
lane departure using a linear-parabolic model. Image
and Vision Computing, 23, 1192–1202. doi:10.1016/j.imavis.2005.07.018
Juo, C. S., & Pan, J. Y. (2008). Software Agent Framework
for Dynamic Handoff Decision. In APCC 2008, Akihabara,
Tokyo, Japan. Ergen, M. (2009). The Access Service Network
in WiMAX: The Role of ASN-GW.
Kaplan, E. D., & Hegarty, C. J. (2006). Understanding GPS
– Principle and Applications. Boston: Artech House.
Karimi, A., Hegyi, A., Schutter, B. D., Hellendoorn, J., &
Middelham, F. (2004, Oct.). Integrated model predictive
control of dynamic route guidance information systems and
ramp metering. Paper presented at the Proceedings of the 7th
International IEEE Conference on Intelligent Transportation
Systems (ITSC 2004), Washington, DC.
Karnadi, F. K., Mo, Z. H., & Lan, K. C. (2007). Rapid
generation of realistic mobility models for vanet. In IEEE
Wireless Communications and Networking Conference.
Karp, B. (2001). Challenges in Geographic Routing: Sparse
Networks, Obstacles, and Traffic Provisioning. In DIMACS
Workshop on Pervasive Networking.
Karp, B., & Kung, H. T. (2000). GPSR: Greedy Perimeter
Stateless Routing for Wireless Networks. ACM International Conference on Mobile Computing and Networking,
(pp. 243-254).
387
Compilation of References
Kastinaki, V., Zervakis, V., & Kalaitzakis, K. (2003). A survey of video processing techniques for traffic applications.
Image and Vision Computing, 21(4), 359–381. doi:10.1016/
S0262-8856(03)00004-0
Kim, J. H., Seo, S. H., Moon, T. Y., Hwang, S. H., & Jeon,
J. W. (2007). A method of improving the reliability of the
gateway system by using OSEK/VDX. In Proceedings of
IEEE International Conference on Control, Automation
and System, (pp. 2328-2833).
Kim, M. J., Choi, Y. J., Moon, Y. B., Kim, S. J., & Kwon,
O. C. (2006). Design and Implementation of Status based
Application Manager for Telematics. IEEE 8th International
Conference on Advanced Communication Technology,
(pp. 20-22).
Kim, T., Kim, D., Park, N., Yoo, S., & Lopez, T. S. (2007).
Shortcut tree routing in ZigBee networks. In . Proceedings
of ISWPC, 07, 42–47.
Kofink, P. (2003). Steering-angle sensors. In J. Marek, H.P.
Trah, Y. Suzuki,& I. Yokomori, (Ed.), Sensors application
Vol. 4 - Sensors for automotive technology (pp. 428-449).
Berlin: Wiley-VCH.
Korkmaz, G., Ekici, E., & Ozguner, F. (2006). A CrossLayer Multihop Data Delivery Protocol with Fairness
Guarantees for Vehicular Networks. IEEE Transactions
on Vehicular Technology, 55(3), 865–875. doi:10.1109/
TVT.2006.873838
Kotsialos, A., Papageorgiou, M., Diakaki, C., Pavlis, Y.,
& Middelham, F. (2002). Traffic flow modeling of largescale motorway networks using the macroscopic modeling
tool METANET. Journal of IEEE Transaction on Intelligent Transportation Systems, 3(4), 282–292. doi:10.1109/
TITS.2002.806804
Krotkov, E., & Blitch, J. (1999). The defense advanced
research projects agency (darpa) tactical mobile robotics
program. In The International Journal of Robotics Research
(pp. 769–776).
Kuhne, R. D., & Langbein-Euchner, K. (1995). Calculation
of travel time savings by dual mode route guidance for the
South corridor in the Stuttgart test field. Vehicle Navigation
and Information Systems Conference.
LeBrun, J., Chuah, C.-N., Ghosal, D., & Zhang, M. (2005).
Knowledgebased opportunistic forwarding in vehicular
388
wireless ad hoc networks. In IEEE Vehicular Technology
Conference (VTC), (pp. 2289– 2293).
Lee, C., Nordstedt, D., & Helal, S. (2003). Enabling Smart
Spaces with OSGi. IEEE Pervasive Computing, 2(3, JulySept), 89-94.
Lee, J., Forlizzi, J., & Hudson, S. E. (2005). Studying the
effectiveness of MOVE: a contextually optimized in-vehicle
navigation system. In Conference on Human Factors in
Computing Systems.
Lee, K. K., Kim, S. H., Choi, Y. S., & Park, H. S. (2006).
A mesh routing protocol using cluster label in the ZigBee
network. In Proceedings of Mobile Ad-hoc and Sensor
Systems (MASS), (pp. 801-806).
Lee, S. W., Munson, J., Lee, D. R., Thompson, G., & Park,
J. (2005). A Rule-based System for Sense-and-Respond
Telematics Applications. In The First Korea/Japan Joint
Workshop on Ubiquitous Computing & Networking Systems, (pp 109-114).
Lee, W., Tak, Y., Byun, W. H., & Pae, Y. W. (2005). Toward
an Open Telematics Infrastructure. IPSJ SIG Technical
Reports, (pp. 443-448).
Leguay, J., Friedman, T., & Conan, V. (2006). Evaluating
mobility pattern space routing for DTNs. In Proceedings
of IEEE INFOCOM.
Leick, A. (2004). GPS Satellite Surveying. New York: John
Wiley & Sons.
Li, Y., Wang, F., Feng, H., & Li, Z. (2005). OSGi-based
service gateway architecture for intelligent automobiles.
In Proceedings of the IEEE International Conference on
Vehicles Symposium, (pp. 861-865).
Ligs, J. F., & Bowcott, S. (1995). ADVANCE: Initial Deployment. Annual Meeting of ITS America.
Lin, X., Sun, X., Ho, P. H., & Shen, X. (2007). GSIS: A
Secure and Privacy Preserving Protocol for Vehicular Communications. IEEE Transactions on Vehicular Technology,
56(6), 3442–3456. doi:10.1109/TVT.2007.906878
Lindgren, A., & Doria, A. (2007). Experiences from deploying a reallife dtn system. In 2007 4th IEEE Consumer Communications and Networking Conference, (pp. 217–221).
Lindgren, A., Doria, A., & Schelen, O. (2003). Probabilistic
routing in intermittently connected networks. ACM SIG-
Compilation of References
MOBILE Mobile Computing and Communications Review,
7(3), 19–20. doi:10.1145/961268.961272
Lochert, C., Mauve, M., Füßler, H., & Hartenstein, H. (2005).
Geographic routing in city scenarios. ACM SIGMOBILE
Mobile Computing and Communications, 9(1), 69–72.
doi:10.1145/1055959.1055970
Locust world. (2009). Retrieved from http://www.locustworld.com
Lundgren, H., Ramachandran, K., Belding-Royer, E.,
Almeroth, K., Benny, M., Hewatt, A., Touma, A., & Jardosh, (2006). Experiences from building and using the
ucsb meshnet testbed. IEEE Wireless network. Available
from http://user.it.uu.se/[UNKNOWN ENTITY &tildent;]
henrikl/publications.html mesh network.
Luo, J., & Hubaux, J.-P. (2004). A survey of inter-vehicle
communication. School of computer and Communication
Sciences, EPEL, Tech. Rep. IC/2004/24.
Machen. L. (2009). Technical marketing engineer, “Intel
drives in-vehicle solutions” handheld components division.
Retrieved from http://www.intel.com/technology/magazine/
computing/it04001.pdf
Mahajan, A., Potnis, N., Gopalan, K., & Wang, A.-I. A.
(2006). Urban mobility models for vanets. In Proceedings
of the 2nd IEEE International Workshop on Next Generation Wireless Networks.
Mahfoud, M., Al-Holou, N., & Baroody, R. (2008). Next
generation vehicle network: Web enable. In Proceedings
of 3rd International Conference on Information and Communication Technologies: From Theory to Applications,
(pp. 1-7).
Mangharam, R., Weller, D. S., Stancil, D. D., Rajkumar, R.,
& Parikh, J. S. (2005) “GrooveSim: A topography-accurate
simulator for geographic routing in vehicular network,” in
Proc. of the 2nd ACM International Workshop on Vehicular
Ad Hoc Networks(VANET),Cologne,Germany.[Online].
Available: http://www.andrew.cmu.edu/user/rahulm/Research/Pubs/ vanet05 mangharam.pdf
Manoharan, R., & Thambidurai, S. L. P. P. (2008). Energy
Efficient Robust On-Demand Multicast Routing Protocol
for MANETs. [IJAHUC]. International Journal of Ad
Hoc and Ubiquitous Computing, 3(2), 90–98. doi:10.1504/
IJAHUC.2008.017002
Marfia, G., Pau, G., Giordano, E., Sena, E. D., & Gerla, M.
(2007) “Evaluating vehicle network strategies for downtown
portland: Opportunistic infrastructure and importance
of realistic mobility models,” in proc. of MoBiOpp 2007,
co-located with ACM/USENIX International Conference
on Mobile Systems, Applications, and Services (MobiSys
2007).
Mariño, P., Poza, F., Dominguez, M. A., & Otero, S. (2009).
Electronics in automotive engineering: A top-down approach for implementing industrial field bus technologies
in city buses and coaches. IEEE Transactions on Industrial
Electronics, 589–600. doi:10.1109/TIE.2008.2002723
Marples, D., & Kriens, P. (2001). The Open Services Gateway
Initiative: An Introduction Overview. IEEE Communications Magazine, 39(12), 110–114. doi:10.1109/35.968820
Mauve, M., Widmer, A., & Hartenstein, H. (2001). A Survey
on Position-Based Routing in Mobile Ad Hoc Networks.
IEEE Network, 15(6), 30–39. doi:10.1109/65.967595
Messmer, & Papageorgiou, M. (1990). METANET: A macroscopic simulation program for motorway networks. Journal
of Traffic Engineering & Control, 31(8-9), 466-470.
Michael, A. (2004). Guide to the IEEE 1512 family of
standards. Washington, DC: Institute of Electrical &
Electronics Engineer.
Microsoft drives to Las Vegas. (2004). Connected Concept
Cars. Retrieved from http://www.windowsfordevices.com/
news/NS5155857065.html
Microsoft.com. (2009). Windows Automotive. Retrieved
from http://www.microsoft.com/windowsautomotive/wa5/
default.mspx.
Minciardi, R., & Gaetani, F. (2001). A decentralized optimal
control scheme for route guidance in urban road networks.
Paper presented at the Proceeding of IEEE Intelligent
Transportation Systems, Oakland, CA.
Mobile taiwan applications promotion project m-taiwan.
Retrieved from http://www.pwlan.org.tw/mp.asp?mp=3
Monk, D., Mladenovic, D., & Skaw, M. (2003). Accelerometers for automotive applications. In J. Marek, H.P.
Trah, Y. Suzuki,& I. Yokomori, (Ed.), Sensors application
Vol. 4 - Sensors for automotive technology (pp. 269-296).
Berlin: Wiley-VCH.
389
Compilation of References
Morbe, M., & Zwiener, G. (2003). Whell-speed sensors. In J.
Marek, H.P. Trah, Y. Suzuki,& I. Yokomori, (Ed.), Sensors
application Vol. 4 - Sensors for automotive technology (pp.
403-415). Berlin: Wiley-VCH.
MOSQUITO Project. (2005). Mosquito Architecture. White
Paper. Retrieved September 20, 2009 from http://www.
mosquito-online.org/
Mosra, S. R., Shanker, S., & Mahmud, S. M. (2004). An
intelligent architecture for issuing intersection collision
warnings (pp. 176-183). National Defense Industries Association (NDIA). OSEK VEX Portal, (n.d.). Retrieved
from http://www.osek-vdx.org
Muffat, M., Green, P., & Crosnier, S. (1991). European
cooperation on dual mode route guidance—Perspectives
for advanced research partners. Vehicle Navigation and
Information Systems Conference. PaPaGO SDK. (n.d.).
Retrieved from http://www.papagosdk.com/
Munson, J., Lee, S. W., Lee, D. R., Wood, D., Thompson,
G., & Cole, A. (2005). A Rule-based System for Sense-andRespond Telematics Services. Workshop on End-to-end,
Sense-and-Respond Systems, Applications and Services,
(pp. 31-36).
Musolesi, M., Hailes, S., & Mascolo, C. (2005). Adaptive
routing for intermittently connected mobile ad hoc networks.
In IEEE WoWMoM 2005 (pp. 183–189).
Myoung, K., Heo, J., Kwon, W. H., & Kim, D. S. (2005,
July). Design and implementation of home network control
protocol on OSGi for home automation. In . Proceedings
of the IEEE International Conference on Advanced Communication Technology, 2, 1163–1168.
Nadeem, T., Shankarand, P., & Iftode, L. (2006, July). A
comparative study of data dissemination models for vanets.
Paper presented at the Proceeding of 3rd Annual International Conference on Mobile and Ubiquitous Systems
(MOBIQUITOUS), San Jose, CA.
Nagatani, T. (2002). The physics of traffic jams. Reports on
Progress in Physics, 65(9), 1331–1386. doi:10.1088/00344885/65/9/203
National Highway Institute (2001). Using the National ITS
Architecture for Deployment.
Naumov, V., & Gross, T. (2007). Connectivity-Aware
Routing (CAR) in Vehicular Ad Hoc Networks. IEEE
390
International Conference on Computer Communications
(INFOCOM’07), (pp. 1919-1927).
Naumov, V., Baumann, R., & Gross, T. (2006). An Evaluation
Of Inter-Vehicle Ad Hoc Networks Based On Realistic Vehicular Traces. In ACM International Symposium on Mobile
Ad Hoc Networking and Computing, (pp. 108-119).
Next Generation Telematics Protocol website. (n.d.). Retrieved September 20 2009, from http://www.ngtp.org
NMEA Data. (n.d.). Retrieved September 11, 2009, from
http://gpsinformation.org/dale/nmea.htm.
Noble, B., Yoon, J., & Liu, M. (2007, June 11-14). Surface
Street Traffic Estimation. Paper presented at the Proceedings of International conference on Mobile systems, San
Juan, Puerto Rico.
Nolte, T., Hansson, H., & Bello, L. L. (2005). Automotive
Communication – Past, Current and Future. In 10th IEEE
Conference on Emerging Technologies and Factory Automation, 1, 985-992.
Normann, N., Schulze, G., & Keller, W. (2003). Tire-pressure
sensors. In J. Marek, H.P. Trah, Y. Suzuki,& I. Yokomori,
(Ed.), Sensors application Vol. 4 - Sensors for automotive
technology (pp. 536-544). Berlin: Wiley-VCH.
Nowey, K. P. T., & Mletzko, C. (2006). Towards a Security Architecture for Vehicular ad hoc Networks. In First
International Conference on Availability, Reliability and
Security, (pp. 374-381).
NTCIP Standard 1103 (2005). TS 3.2-1996 NTCIP Simple
Transportation Management Framework - Amendment 1.
NTCIP Standard 9001. (2002). The NTCIP guide.
O’Donnell, M. (2003). OSEK/VDX: Driving the Standard
for Optimized Embedded Systems. Embedded Computing
Design.
Open Service Gateway Initiative. (2003). OSGi Specification Release 3. Retrieved September 20 2009, from http://
www.osgi.org
OSEK Group (2004). OSEK Implementation Language,
Version 2.5.
OSEK Group (2004). OSEK/VDX Network Management
Concept and Application Programming Interface, Version 2.5.3.
Compilation of References
OSEK Group (2005). OSEK/VDX Operation System, Version 2.2.3.
Ott, J., & Kutscher, D. (2006). Bundling the web: Http over
dtn. In Proceeding of WNEPT2006.
P. simulation VISSIM. (2009). http://www.english.ptv.de/.
Palazzi, C. E., Roccetti, M., Pau, G., & Gerla, M. (2007).
Online Games on Wheels: Fast Game Event Delivery in
Vehicular Ad-hoc Networks. In IEEE Intelligent Transportation Systems Society, (pp. 42–49).
Panichpapibo, S., & Pattara-atikom, W. (2008, Oct.).
Evaluation of a neighbor-based vehicle density estimation
scheme. Paper presented at the ITST 2008. 8th International
Conference, Phuket.
Paret, D. (2007). Multiplexed networks for embedded systems
– CAN, LIN, FlexRay, Safe-by-Wire. Hoboken, NJ: Wiley.
Park, C. K., Kang, J. M., Choi, M. J., Hong, J. W., Lim,
Y. H., & Choi, M. S. (2008, Jan.). An Integrated Network
Management System for Multi-Vendor Power Line Communication Networks. In Proceedings of the IEEE International
Conference on Information Networking, (pp.23-25).
Park, C. K., Kang, J. M., Choi, M. J., Hong, J. W., Lim,
Y. H., Ju, S., & Choi, M. S. (2008). Definition of common
PLC MIB and design of MIB Mapper for multi-vendor
PLC network management. In Proceedings of the IEEE
International Symposium on Power Line Communications
and Its Applications, (pp.152-157).
Park, J. G., Ahn, C. W., Cho, H. N., Byun, I. S., Desmons,
F., & Kim, S. W. (2006). A method for representing and
transporting CIM operations using binary XML in the
WBEM architecture. In Proceedings of the 8th International
Conference on Advanced Communication Technology,
(Vol. 3, pp.20-22).
Park, J. S., Lee, U., Oh, S. Y., Gerla, M., & Lun, D. (2006).
Emergency Related Video Streaming in VANETs using
Network Coding. In ACM International Workshop on Vehicular Ad Hoc Networks (VANET), (pp. 102-103).
Pavlis, Y., & Papageorgiou, M. (1999). Simple Decentralized
Feedback Strategies for Route Guidance in Traffic Networks. Transportation Science, 33(3), 264–278. doi:10.1287/
trsc.33.3.264
Pazul. K. (1999). An introduction to the CAN protocol that
discusses the basics and key features. Microchip Application Note #AN713.
Perkins, C. E., & Royer, E. M. (1999). Ad-hoc On-demand
distance vector routing. In . Proceedings of WMCSA, 99,
90–100.
Perkins, D., & McGinnis, E. (1997). Understanding SNMP
MIBS. Upper Saddle River, NJ: Prentice Hall, Inc.
Phung, P. H., & Sands, D. (2008). Security Policy Enforcement in the OSGi Framework Using Aspect-Oriented
Programming. In Proceedings of the IEEE International
Conference on Computer Software and Applications,
(pp.1076-1082).
Popescu, D., & Selisteanu, D. (2008). Web based Telematics Application for Robotics. In the 3rd International
Multi-Conference on Computing in the Global Information
Technology, (pp. 19-24).
Potnis, N., & Mahajan, A. (2006) “Mobility models for
vehicular ad hoc network simulations,” in proc. of the
44th annual Southeast regional conference, ACM (pp.
746–747).
Prosyst website. (n.d.). Retrieved September 20 2009, from
http://www.prosyst.com/
Punnoose, J., Tseng, S., Wang, S., Nikitin, V., & Schlesinger,
T. E. (2001). Communications Resources Management for
Advanced Telematics Applications. Transportation Society
Conference.
Rajkumar, R., Gagliardi, M., & Sha, L. (1995). The RealTime Publisher/Subscriber Inter-Process Communication
Model for Distributed Real-Time Systems: Design and
Implementation. Real-Time Technology and Applications
Symposium, (pp. 66–75).
Ramadas, M., Burleigh, S., & Farrell, S. (2007). Licklider
transmission protocol - specification. Internet-draft.
Rapport, T. S. (1996). Wireless communications principles
and practice. Upper Saddle River, NJ: Prentice Hall.
Raya, M., & Hubaux, J. P. (2005). The Security of Vehicular
Ad Hoc Networks. In Proceedings of the 3rd ACM workshop
on Security of ad hoc and sensor networks, (pp.11-21).
Raychaudhuri, D., Seskar, I., Ott, M., Ganu, S., Ramachandran, K., Kremo, H., et al. (2005). Overview of the orbit
391
Compilation of References
radio grid testbed for evaluation of next-generation wireless
network protocols. In Proceedings of the IEEE Wireless
Communications and Networking Conference, New Orleans, LA, USA.
Real-Time Traffic Network Systems of Cities and Counties in Taiwan. (n.d.). Retrieved from http://www.e-traffic.
com.tw
Reilly, D., & Taleb-Bendiab, A. (2002). A Service-Based
Architecture for In-Vehicle Telematics Systems. In the
22nd International Conference on Distributed Computing
Systems Workshops, (pp.741-742).
Research and Innovative Technology Administration (RITA)
& U.S. Department of Transportation. (US DOT). (2002).
National ITS architecture. Retrieved from http://itsarch.
iteris.com/itsarch/
Rice, J., & Cho, Y. (2006). Estimating Velocity Fields on
a Freeway From Low-Resolution Videos. IEEE Transactions on Intelligent Transportation Systems, 7(4), 463–469.
doi:10.1109/TITS.2006.883934
Riegel, J., Wiedenmann, H., & Neumann, H. (2003). Chemical sensors for oxygen detection and air/fuel ratio contol. In
J. Marek, H.P. Trah, Y. Suzuki,& I. Yokomori, (Ed.), Sensors
application Vol. 4 - Sensors for automotive technology (pp.
480-499). Berlin: Wiley-VCH.
Robert Bosch Gmb, H. (2006). Safety, comfort and convenience systems. Hoboken, NJ: Wiley.
Robert Bosch Gmb, H. Stuttgart, Germany, (1991). CAN
Specification ver. 2.0.
Robert, H., & Ilya, P. (1979). A Two-Fluid Approach to
Town Traffic. Science, 204(4389), 148–151. doi:10.1126/
science.204.4389.148
Robinson, C. L., Caveney, D., Laberteaux, K., & Caminiti, L.
(2006, September 29). Efficient Coordination and Transmission of Data for Cooperative Vehicular Safety Applications.
Paper presented at the Proceedings of the 3rd international
workshop on Vehicular ad hoc networks, Los Angeles,
California, USA.
Rodoplu, V., & Park, M. K. (2005). An energy-efficient
mac protocol for underwater wireless acoustic networks. In
Proceedings of the MTS/IEEE OCEANS’05 Conference.
392
Roessler, B., & Bruns, C. (2006, Mar.). Replication of Local
Road Networks for Regional Information Dissemination
in VANETS. Paper presented at the Proceedings of the 3rd
Workshop on positioning, Navigation And Communication
(WPNC’06), University of Hannover, Germany.
Rose, M. T. (1990). The Open Book: A Practical Perspective
on OSI. Upper Saddle River, NJ: Prentice Hall, Inc.
Rosen, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., et al. (2002). SIP: Session Initiation
Protocol. IETF RFC 3261.
Royer, E. M., Melliar-Smithy, P. M., & Mosery, L. E. (2001)
“An analysis of the optimum node density for ad hoc mobile
networks,” in Proc. of the IEEE International Conference
on Communications, Jun. 2001.
Ryu, B., Yeung, G., Krishnan, H., Yin, J., ElBatt, T., Habermas, S., et al. (2004). Performance Evaluation of Safety
Applications over DSRC Vehicular Ad Hoc Networks. Paper
presented at the Proceedings of the 1st ACM international
workshop on Vehicular ad hoc networks, Philadelphia,
PA.
S. S. of Urban Mobility. (2009). http://sumo.sourceforge.
net/.
Safa, H., Artail, H., & Shibli, R. (2009). An Interoperability
Model for Supporting Reliability and Power-Efficient Routing in MANETs. [IJAHUC]. International Journal of Ad
Hoc and Ubiquitous Computing, 4(2), 71–83. doi:10.1504/
IJAHUC.2009.023898
Saha, A. K., & Johnson, D. B. (2004) “Modeling mobility
for vehicular ad hoc networks,” in Proc. of the 2nd ACM
International Workshop on Vehicular Ad Hoc Networks
(VANET). [Online]. Available: http://www.cs.rice.edu/
amsaha/ Resume/vanet2004/vanet2004.pdf
Saha, A. K., & Johnson, D. B. (2004). Modeling mobility for
vehicular ad hoc networks. ACM International Workshop on
Vehicular Ad Hoc Networks (VANET), (pp. 91-92).
Saito, T., Tomoda, I., Takabatake, Y., Arni, J., & Teramoto,
K. (2000). Home gateway architecture and its implementation. IEEE Transactions on Consumer Electronics, 46(4),
1161–1166. doi:10.1109/30.920474
Sawamura, T., Tanaka, K., Atajanov, M., Matsumoto, N., &
Yoshida, N. (2008). Adaptive Router Promotion and Group
Forming in Ad-Hoc Networks. [IJAHUC]. International
Compilation of References
Journal of Ad Hoc and Ubiquitous Computing, 3(4), 217–223.
doi:10.1504/IJAHUC.2008.018907
Schatz, O. (2003). Yaw-rate sensors. In J. Marek, H.P.
Trah, Y. Suzuki,& I. Yokomori, (Ed.), Sensors application
Vol. 4 - Sensors for automotive technology (pp. 297-313).
Berlin: Wiley-VCH.
Schiller, J., & Voisard, A. (2004). Location-Based Services.
San Francisco: Morgan Kaufmann.
Schilling, K. (2001). Virtual Laboratories for Mobile Robots.
IFAC Workshop on Internet Based Control Education, (pp.
115-120).
Schmitt, D. (2003). Chemical sensors for emission control.
In J. Marek, H.P. Trah, Y. Suzuki,& I. Yokomori, (Ed.), Sensors application Vol. 4 - Sensors for automotive technology
(pp. 500-508). Berlin: Wiley-VCH.
Schmitt, E. J., & Jula, H. (2006, Sep.). Vehicle Route
Guidance Systems: classification and Comparison. Paper
presented at the Proceedings of the IEEE Intelligent Transportation Systems Conference (ITSC2006), Toronto.
Scott, K. (2005). Disruption tolerant networking proxies
for on-the-move tactical networks. In IEEE MILCOM 2005,
(Vol. 5, pp. 3226–3231).
Scott, K., & Burleigh, S. (2007). Bundle protocol specification. Internet- Draft.
Segui, J., & Jennings, E. (2006). Delay tolerant networking
v bundle protocol simulation. In Second IEEE International
Conference on Space Mission Challenges for Information
Technology.
Seo, S. H., Moon, T. Y., & Kim, J. H. (2007). Smart Vehicle
Management System by using Gateway, Hand-set and
VMP. International Conference on Control, Automation
and Systems, (pp.17-20).
Seongmoon, K., & Lewis, M. E., & III, C. C. W. (2005).
Optimal vehicle routing with real-time traffic information.
IEEE Transactions on Intelligent Transportation Systems,
6(2), 178–188. doi:10.1109/TITS.2005.848362
Seth, A., & Keshav, S. (2005). Practical security for disconnected nodes. In Proceeding of Workshop on Secure
Network Protocols (pp. 31–36).
Sichitiu, M. L., & Kihl, M. (2008). Inter-Vehicle Communication Systems: A Survey. IEEE Communications Surveys & Tutorials, 10(2), 88–105. doi:10.1109/
COMST.2008.4564481
SimulationP. M. T. (2009). http://www.paramics-online.
com/.
SimulatorO. (2009). http://www.opnet.com/.
SimulatorQ. N. (2009). http://www.scalable-networks.
com/.
Singh, M., Ott, M., Seskar, I., & Kamat, P. (2005). Orbit
measurements framework and library (oml): Motivations,
design,implementation, and features. In Proceedings of
IEEE Tridentcom 2005, Trento, Italy.
Skordylis, A., & Trigoni, N. (2008). Delay-Bounded Routing in Vehicular Ad-Hoc Networks. ACM international
symposium on Mobile ad hoc networking and computing,
(pp. 341-350).
Sormani, D., Turconi, G., Costa, P., Frey, D., Migliavacca,
M., & Mottola, L. (2006). Towards Lightweight Information
Dissemination in Inter-Vehicular Networks. In Proceedings of the ACM International Workshop on Vehicular
Inter-Networking.
South Pointing Chariot. (n.d.). Retrieved September 11,
2009, from http://en.wikipedia.org/wiki/South_Pointing_Chariot.
Spyropoulos, T., Psounis, K., & Raghavendra, C. S. (2004).
Single-copy routing in intermittently connected mobile
networks. In 2004 First Annual IEEE Communications
Society Conference on Sensor and Ad Hoc Communications
and Networks, (pp. 235 – 244).
Spyropoulos, T., Psounis, K., & Raghavendra, C. S. (2005).
Spray and wait: An efficient routing scheme for intermittently connected mobile networks. In Proceeding of the 2005
ACM SIGCOMM workshop on Delay-tolerant networking
WDTN ’05, (pp. 252–259).
Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., & Rayhan, A. (2002). Middlebox Communication Architecture and
Framework. IETF Internet Draft, retrieved September 20
2009 from http://www.jdrosen.net/papers/rfc3303.txt
Stallings, W. (1993). SNMP, SNMPv2 and CMIP The Practical Guide to Network Management Standards. Reading,
MA: Addison-Wesley Publishing Company, Inc.
393
Compilation of References
Stallings, W. (1996). SNMP, SNMPv2 and RMON. Reading,
MA: Addision-Wesley Publishing Company, Inc.
Steedman, D. (1993). ASN.1: The Tutorial & Reference.
London: Technology Appraisals Ltd.
Stepanov, I., Marron, P.-J., & Rothermel, K. (2005l) “Mobility modeling of outdoor scenarios for manets,” in Proceedings of the 38th annual Symposium on Simulation ANSS
’05, Apr. 2005 (pp. 312–322).
Studer, A., Luk, M., Perrig, A, (n.d.). Efficient Mechanisms
to Provide Convoy Member and Vehicle Sequence Authentication in VANETs.
SUMO Simulation of Urban Mobility. (2009). Retrieved
from http://sumo.sourceforge.net/
Sun Microsystems Inc. (1999, November). JINI Specification
v1.0.1. Retrieved from http//:www.sun.com/JINI/
Sun Microsystems Inc. (2000). Java Media Framework API
Guide, 2000. Retrieved from http://java.sun.com/products/
java-media/jmf/
Sun, W., Yamaguchi, H., Yukimasa, K., & Kusumoto, S.
(2006). GVGrid: A QoS Routing Protocol for Vehicular Ad
Hoc Networks. IEEE International Workshop on Quality
of Service, (pp. 130-139).
Sun, Y., Huang, W. L., Tang, S. M., Qiao, X., & Wang,
F. Y. (2007). Design of an OSEK/VDX and OSGi-based
embedded software platform for vehicular applications.
In Proceedings of the IEEE International Conference on
Vehicular Electronic and Safety, (pp. 1-6).
Sun, Y., Wang, F. Y., Wang, Z. X., Qiao, X., & Wang, K.
F. (2006). A scheduling algorithm for vehicular application specific embedded operating systems. In Proceedings
of IEEE International Conference on Systems, Man and
Cybernetics, (pp. 2535-2540).
Sven Jaap, M. B., & Wolf, L. (2005) “Evaluation of routing protocols for vehicular ad hoc networks in city traffic
scenarios,” in in Proc. of the 5th International Conference
on Intelligent Transportation Systems Telecommunications (ITST).
Symington, S., Farrell, S., Weiss, H., & Lovell, P. (2007).
Bundle security protocol specification. Internet-draft.
Symington, S., Farrell, S., Weiss, H., & Lovell, P. (2007).
Delay-tolerant networking security overview. Internetdraft.
T. N. S. ns 2.(2009). http://www.isi.edu/nsnam/ns/index.
html.
Taleb, T., Sakhaee, E., Jamalipour, A., Hashimoto, K., Kato,
N., & Nemoto, Y. (2007). A Stable Routing Protocol to Support ITS Services in VANET Networks. IEEE Transactions
on Vehicular Technology, 56(6), 3337–3347. doi:10.1109/
TVT.2007.906873
Tan, K., Zhang, Q., & Zhu, W. (2003). Shortest path routing
in partially connected ad hoc networks. In Proceedings of
IEEE Globecom 2003, (Vol. 2, pp. 1038–1042).
Tariq, M. M. B., Ammar, M., & Zegura, E. (2006). Message
ferry route design for sparse ad hoc networks with mobile
nodes. In Proceedings of the seventh ACM international
symposium on Mobile ad hoc networking and computing
MobiHoc ’06 (pp. 37–48).
Thangavelul, A., & Bhuvaneswari, K. Kumar’, K., SenthilKumarl, K., & Sivanandam, S.N., (2007). Location Identification and Vehicle Tracking using VANET (VETRAC).
In IEEE International Conference on Signal Processing,
Communications and Networking 2007.
The Network Simulator. ns2.(2009). Retrieved from http://
www.isi.edu/nsnam/ns/
The zebranet wildlife tracker. (2009). Retrieved from http://
www.princeton.edu/ mrm/zebranet.html
The, I. E. E. E. 802.15.4 WPAN Group. (2009). Retrieved
from http://www.ieee802.org/15/pub/TG4.html
The, O. N. WORLD. (2005). Retrieved from http://www.
onworld.com
Third Generation Partnership Project [3GPP]. (2009).
Retrieved from http://www.3gpp.org
Thompson, J. P. (1998). Web-based enterprise management
architecture. IEEE Communications Magazine, 36(3),
80–86. doi:10.1109/35.663331
Tier. (2009). Retrieved from http://tier.cs.berkeley.edu/
wiki/Home
TIGER (Topologically Integrated GEographic Encoding
and Referencing). (2009). http://www.census.gov/geo/
www/tiger/.
394
Compilation of References
Tomkewitsch, R. v. (1991). Dynamic route guidance and
interactive transport management with ALI-SCOUT.
Journal of IEEE Transactions on Vehicular Technology,
40(1), 45–50. doi:10.1109/25.69971
Tonguz, O. K., Wisitpongphan, N., Parikh, J. S., Bai, F.,
Mudalige, P., & Sadekar, V. K. (2006). On the Broadcast
Storm Problem in Ad hoc Wireless Networks. International
Conference on Broadband Communications, Networks and
Systems, (pp. 1-11).
Tonguz, O., Wisitpongphan, N., Bai, F., Mudalige, P., &
Sadekar, V. (2007). Broadcasting in VANET. Mobile Networking for Vehicular Environments, (pp. 7-12).
Torge, W. (1991). Geodesy. Berlin: Walter de Gruyter.
Traffic Message Channel. (n.d.). Retrieved September
11, 2009, from http://en.wikipedia.org/wiki/Traffic_Message_Channel.
TRANSIMS. http://transims.tsasa.lanl.gov/.
Transportation Research Board. (2004). Transportation In
An Aging Society: A Decade of Experience. Transportation
Research Board.
Treiber, M., Hennecke, A., & Helbing, D. (2000) “Congested
traffic states in empirical observations and microscopic
simulations,” IPhys. Rev., vol. 62, no. 2.
Tropos networks. (2009). Retrieved from http://www.
tropos.com
Tsai, H. M., Tonguz, O. K., Saraydar, C., Talty, T., Ames, M.,
& Macdonald, A. (2007). ZigBee-based intra-car wireless
sensor networks: A case study. IEEE Wireless Communications, (pp. 68-77).
Tseng, Y. C., Chen, J. J., & Cheng, Y. L. (2007). Design and
Implementation of a SIP-based Mobile and Vehicular Wireless Network with PUSH Mechanism. IEEE Transactions
on Vehicular Technology, 56(6), 3408–3420. doi:10.1109/
TVT.2007.906986
Tseng, Y. C., Ni, S. Y., Chen, Y. S., & Sheu, J. P. (2002).
The Broadcast Storm Problem in a Mobile Ad Hoc Network. [WINET]. ACM Wireless Networks, 8(2), 153–167.
doi:10.1023/A:1013763825347
Unwired wireless. (2009). Retrieved from http://www.
unwired.com.au/
UPnP Forum. (2009). Retrieved from http://www.upnp.
org
Vahdat, V., & Becker, D. (2000). Epidemic routing for
partially connected ad hoc networks. Technical Report
CS-200006, Duke University.
Vahid, F., & Givargis, T. (2002). Embedded system design:
A unified hardware/software introduction. Hoboken, NJ:
Wiley.
Wan, S., Tang, J., & Wolff, R. S. (2008). Reliable Routing
for Roadside to Vehicle Communications in Rural Areas.
In IEEE International Conference on Communications,
(pp. 3017-3021).
Wang, C., Sohraby, K., Jana, R., Ji, L., & Deneshmand,
M. (2008). Voice communications over ZigBee networks.
IEEE Communications Magazine, 121–127. doi:10.1109/
MCOM.2008.4427240
Wang, F. Y., Li, J. X., & Liu, X. J. (2004). OSEK/VDX and
OSGi-based Embedded Platform for Vehicular Software
and its Key Techniques. Chinese High Technology Letters,
(pp.131-136).
Weber, S., Cahill, V., Clarke, S., & Haahr, M. (2003). Wireless ad hoc network for dublin: A large-scale ad hoc network
test-bed. ERCIM News, 54. Retrieved from http://www.
ercim.org/publication/ErcimNews/enw54/weber.html
Weiss, E., Gehlen, G., Lukas, S., & Rokitansky, C. (2006).
MYCAREVENT- Vehicular Communication Gateway for
Car Maintenance and Remote Diagnosis. In Proceedings
of the IEEE International Conference on Computers and
Comunication, (pp. 318-323).
WiChorus, Inc. (2009). Retrieved from http://www.mustafaergen.com/asn_gateway.pdf
Wills, J., Ye, W., & Heidemann, J. (2006). Low-power
acoustic modem for dense underwater sensor networks. In
Proceedings of the First ACM International Workshop on
UnderWater Networks (WUWNet), Los Angeles, CA, (pp.
79–85). New York: ACM. Retrieved from http://www.isi.
edu/ohnh/PAPERS/Wills06a.html
WirelessCar website (n.d.). Retrieved September 20 2009,
from http://www.wirelesscar.com/
Wisitpongphan, N., Bai, F., Mudalige, P., Sadekar, V., & Tonguz, O. (2007). Routing in sparse vehicular ad hoc wireless
395
Compilation of References
networks. IEEE Journal on Selected Areas in Communications, 25(8), 1538–1556. doi:10.1109/JSAC.2007.071005
Wisitpongphan, N., Tonguz, O. K., Parikh, J. S., Mudalige,
P., Bai, F., & Sadekar, V. (2007). Broadcast Strom Mitigation Techniques in Vehicular Ad Hoc Networks. IEEE
Wireless Communications, 14(6), 84–94. doi:10.1109/
MWC.2007.4407231
Wood, L., Eddy, W. M., Ivancic, W., McKim, J., & Jackson,
C. (2007). Saratoga: a delay-tolerant networking convergence layer with efficient link utilization. In Proceeding
of IWSSC’07.
Wood, L., McKim, J., Eddy, W., Ivancic, W., & Jackson, C.
(2008). Saratoga: a convergence layer for delay-tolerant
networking. Internet draft.
Wood, L., Peoples, C., Parr, G., Scotney, B., & Moore, A.
(2007). Tcps protocol radius:the distance where timers
prevent communication. In Proceeding of IWSSC’07.
Woodrow, B., & Thomas, A. (1998). Dingus Human Factors in Intelligent Transportation Systems. Mahwah, NJ:
Lawrence Erlbaum Associates.
World Geodetic System. (n.d.). Retrieved September 11,
2009, from http://en.wikipedia.org/wiki/World_Geodetic_System
WTP1. 0 Specification (2004). Electronics and Telecommunications Research Institute (ETRI), Korea.
Wu, H., Fujimoto, R., Guensler, R., & Hunter, M. (2004,
Oct.). Mddv: a mobility-centric data dissemination algorithm for vehicular networks. Paper presented at the
Proceedings of ACM Vehicular ad hoc networks (VANET),
Philadelphia, PA.
Wu, H., Fujimoto, R., Hunter, M., & Guensler, R. (2005).
An architecture study of infrastructure-based vehicular networks. In ACM MSWiM, Montreal, Canada, (pp.36-39).
Wunderlich, K. E., Kaufman, D. E., & Smith, R. L.
(2000). Link travel time prediction for decentralized
route guidance architectures. Journal of IEEE Transaction on Intelligent Transportation Systems, 1(1), 4–14.
doi:10.1109/6979.869017
WWWOFFLE. (2009). Retrieved from http://www.gedanken.demon.co.uk/wwwoffle/
396
Hudson Valley Transportation Management Center (HVTMC) (n.d.). Retrieved from http://www.hudsonvalleytraveler.
com/Glossary.html
Open Service Gateway Initiative (OSGi). (2009). Retrieved
from http://www.osgi.org
WiMAX Forum. (2007). WiMAX End-to-End Network
Systems Architecture Stage 3: Detailed Protocols and
Procedures, Release 1.1.0.
WiMAX Forum. (n.d.). Wimax deployment consider for fixed
wireless Access in 2.5GHz and 3.5GHz licensed bands.
Xiang, W., Richardson, P., & Guo, J. (2006). Introduction
and preliminary experimental results of wireless access for
vehicular environments (WAVE) systems. In Proceedings
of 3rd Annual International Conference on Mobile and
Ubiquitous Systems, (pp.1-8).
Xu, Q., Mak, T., Ko, J., & Sengupta, R. (2004). Vehicle-toVehicle Safety Messaging in DSRC. In ACM International
Workshop on Vehicular Ad Hoc Networks (VANET), (pp.
19-28).
Xu, Y. N., Kim, Y. E., Cho, K. J., Chung, J. G., & Lim, M.
S. (2008). Implementation of FLexRay communication
controller protocol with application to a robot system. In
Proceedings of 15ht International Conference on Electronics, Circuits and Systems, (pp. 994-997).
Yamashita, T., Izumi, K., & Kurumatani, K. (2004). Car
navigation route information sharing for improvement of
traffic efficiency. Paper presented at the Proceeding of 7th
international IEEE conference on Intelligent Transportation
Systems, Washington, D.C., USA.
Yang, H., Luo, H., Ye, F., Lu, S., & Zhang, L. (2004). Security
in mobile ad hoc networks: Challenges and solutions. IEEE
Wireless communications, 11(1), 38-47.
Yang, P., & Chuah, M. C. (2006). Context-aware multicast
routing scheme for disruption tolerant networks. In Proceedings of ACM international workshop on PE-WASUN
’06 (pp. 66–73).
Ye, Q., Cheng, L., Chuah, M. C., & Davison, B. D. (2006).
Os-multicast: On-demand situation-aware multicasting
in disruption tolerant networks. In . Proceedings of IEEE
VTC, 1, 96–100.
Compilation of References
Yokomori, I., & Suzuki, Y. (2003). Pressure sensors. In J.
Marek, H.P. Trah, Y. Suzuki,& I. Yokomori, (Ed.), Sensors
application Vol. 4 - Sensors for automotive technology (pp.
314-332). Berlin: Wiley-VCH.
Zhao, J., & Cao, G. (2006). VADD: Vehicle-Assisted Data
Delivery in Vehicular Ad Hoc Networks. IEEE Computer
Communications, (pp. 1-12).
Yoon, H., Kim, J., Tan, F., & Hsieh, R. (2008). On-demand
Video Streaming in Mobile Opportunistic Networks. In
IEEE International Conference on Pervasive Computing
and Communications (PerCom), (pp. 80–89).
Zhao, W., Ammar, M., & Zegura, E. (2004). A message
ferrying approach for data delivery in sparse mobile ad
hoc networks. In Proceedings of the 5th ACM international
symposium on Mobile ad hoc networking and computing
MobiHoc ’04 (pp. 187–198).
Yousefi, S., Mousavi, M. S., & Fathy, M. (2006). Vehicular
Ad Hoc Networks (VANETs): Challenges and Perspectives.
International conference on ITS Telecommunications, (pp.
761-766).
Zhao, W., Ammar, M., & Zegura, E. (2005). Controlling
the mobility of multiple data transport ferries in delaytolerant network. In . Proceedings of IEEE INFOCOM,
2, 1407–1418.
Yu, F., & Biswas, S. (2007). Self-Configuring TDMA
Protocols for Enhancing Vehicle Safety with DSRC Based
Vehicle-to-Vehicle Communications. IEEE Journal on
Selected Areas in Communications, 25(8), 1526–1537.
doi:10.1109/JSAC.2007.071004
Zhao, W., Ammar, M., & Zegura, E. (2005). Multicasting
in delay tolerant networks: Semantic models and routing
algorithms. In Proceeding of Sigcomm Workshop in DTN,
(pp. 268–275).
Zeng, X., Bagrodia, R., & Gerla, M. (1998). Glomosim: A
library for the parallel simulation of large-scale wireless
networks. In The 12th Workshop on Parallel and distributed Simulation. PADS’98, Banff, Alberta, Canada (pp.
154–161).
Zhan, F. B. (1997). Three fastest shortest path algorithms
on real road network: data structure and procedures.
Journal of geographic information and decision analysis,
1(1), 69-82.
Zhang, D., Xiao, H. W., & Hackbarth, K. (2004). OSGi
based service infrastructure for context aware automotive
telematics. In . Proceedings of IEEE International Conference on Vehicular Technology, 5, 2957–2961.
Zhang, Y., Zhao, J., & Cao, G. (2007). On Scheduling
Vehicle-Roadside Data Access. In Proceedings of the ACM
International Workshop on Vehicular Inter-Networking.
Zhang, Z., & Fei, Z. (2007). Route design for multiple
ferries in delay tolerant networks. In Proceedings of IEEE
Wireless Communications and Networking Conference
(pp. 3460–3465).
Zhao, Y. (1997). Vehicle Location and Navigation Systems.
Boston: Artech House.
Zheng, N. N., Tang, S., Cheng, H., Li, Q., Lai, G., & Wang,
F. W. (2004). Toward Intelligent Driver-Assistance and
Safety Warning Systems. IEEE Intelligent Systems, 19(2),
8–11. doi:10.1109/MIS.2004.1274904
Zheng, Q., Hong, X., & Ray, S. (2004). Recent advances in
mobility modeling for mobile ad hoc network research. In
Proceedings of the 42nd ACM annual Southeast regional
conference (ACM-SE), (70-75). New York: ACM Press.
Zhou, Y., Wang, X., & Zhou, M. (2006). The Research and
Realization for Passenger Car CAN Bus. In Proceedings
of the IEEE International Forum on Strategic Technology,
(pp. 244-247).
Zigbee Alliance. (2006). ZigBee specification: ZigBee
Document 053474r13.
Zimmermann, H.-M., Gruber, I., & Roman, C. (2005) “A
voronoi-based mobility model for urban environments,” in
in Proc. Of the European Wireless 2005 (EW05) .
Zonoozi, M. M., & Dassanayake, P. (1997). User mobility
modeling and characterization of mobility patterns . IEEE
Journal on Selected Areas in Communications, 15(7),
1239–1252. doi:10.1109/49.622908
397
398
About the Contributors
Chung-Ming Huang received the B.S. degree in electrical engineering from National Taiwan University on 1984/6, and the M.S. and Ph.D. degrees in computer and information science from The Ohio
State University on 1988/12 and 1991/6. Currently, he is a Distinguished Professor of Dept. of Computer
Science and Information Engineering, National Cheng Kung University, Taiwan, R.O.C. He also serves as
(i) Director of the Promotion Center for the Telematics Consortium (PCTC), Ministry of Education (MOE),
Taiwan, R.O.C. and (ii) Principal Project Reviewer of Industrial Development Bureau and Department of
Industrial Technology, Ministry of Economic Affairs (MOEA), Taiwan, R.O.C. He has published more than
200 referred journal and conference papers in wireless and mobile communication protocols, interactive
multimedia systems, audio and video streaming and formal modeling of communication protocols. His
research interests include wireless and mobile network protocol design and analysis, media processing
and streaming, web technologies, and network applications and services.
Yuh-Shyan Chen received the B.S. degree in Computer Science from Tamkang University, Taiwan,
R. O. C., in June 1988 and the M.S. and Ph.D. degrees in Computer Science and Information Engineering from the National Central University, Taiwan, R. O. C., in June 1991 and January 1996, respectively.
He joined the faculty of Department of Computer Science and Information Engineering at Chung-Hua
University, Taiwan, R. O. C., as an associate professor in February 1996. He joined the Department of
Statistic, National Taipei University in August 2000, and joined the Department of Computer Science and
Information Engineering, National Chung Cheng University in August 2002. Since 2006, he has been a
Professor at the Department of Computer Science and Information Engineering, National Taipei University,
Taiwan. Prof. Chen is now serving as chair of Institute of Communication Engineering, National Taipei
University, Taiwan, ROC, and Vice Chair of Task Force on “Telecommunications” of Intelligent Systems
Applications Technical Committee, IEEE Computational Intelligence Society from 2007. Prof. Chen
served as Editor-in-Chief of International Journal of Ad Hoc and Ubiquitous Computing (SCIE), Editorial
Board of Telecommunication System Journal (SCIE), EURASIP Journal on Wireless Communications
and Networking (SCIE), and Mobile Information Systems (SCIE). He served as Guest Ed