OmniPark
Offering Optimized Parking Solutions
(www.omnipark.org)
Rajat Dhariwal
Cindy Jen
Suchit Mishra
Divya Ramasahayam
OmniPark
Outline
Topic
Page
1.
Project Abstract
2
2.
Project Requirements
a. High level project specification
b. Infrastructural features
3
3
3
3.
System Design
a. System Overview
b. Hardware Design (Cindy Jen)
c. Ad-Hoc Routing (Suchit Mishra)
d. Software Design (Divya Ramasahayam)
e. Front End (Rajat Dhariwal)
4
4
5
11
23
28
4.
Unique System Innovations
33
5.
Demo Sequences
34
6.
Project Status & Future
36
1
Project Abstract
Locating an expired meter is a common challenge faced by PEO
(parking enforcement officers) every day. As common is the searching
for an empty spot by a patron. Wireless ad hoc networking
technologies offer a new and efficient means to both simplify the
process of parking and collection as well as extending the convenience
for drivers. In this project we describe a multi-hop wireless parking
meter network that when deployed will help PEOs track the expired
meters remotely, issue tickets easily, and boost the revenues in the
process. Our solution is achieved by equipping existing parking meters
with wireless radio frequency (RF) transceivers and auxiliary hardware
and software. We believe that this is a compelling application that
applies wireless ad hoc networking and low-power, short range RF
technologies. In this work, we model a special class of ad hoc
networks characterized by static and immobile nodes (parking meters).
We propose fault tolerant, scalable techniques for satisfying a user's
query to find an empty spot on street through a website.
The centralized parking management system will help streamline the
existing system and increase the revenues for them. The handheld
violation detection machine will be used to identify expiration of time
on meters and automatically notify the officer about the violation. A
web interface depicting all the empty spots on the street will provide
proactive parking for the patrons hence reducing the congestion on the
road to a great extent.
2
Project Requirements
High level project specification
 Help patron locate an empty spot on street through a website
 Notify an expired meter on street to Parking Enforcement Officer
Infrastructural features
***Figure borrowed from www.vehiclesense.com
3
System Design
System Overview
High-Level Architecture Diagram (Details provided later in this
section):
Parking Meter
Node
Parking Meter
Node
MultiHop
Wireless
Communication
Protocol
Parking Meter
Parking Meter
Node
Node
Parking Meter
Node
Parking Meter
Node
USB Port
Hub Base Node
Hub Base Node
Internet
Central Server
(Database)
Web Interface
Parking Registration and Reservation System
Team Member Roles and Responsibilities:
•
•
•
•
Cindy Jen (Hardware Engineer)
– Parking Meter Node Design
– Microcontroller Code
Suchit Mishra (Network Engineer)
– Node Communication Protocol
– HUB Failover Protocol
Divya Reddy (Software Engineer)
– HUB ↔ Central Server Communication
– Database and Web Interface Design
Rajat Dhariwal (Software Engineer)
– Map-Based Search Application
4
Hardware Design (Cindy Jen)
High Level Description
The parking meter nodes require several capabilities- detection of
vehicle presence, communication of status to a base node (hub), and
representation of status to an observer. To control all of these
capabilities, we use the MSP430 microcontroller from Texas
Instruments. This microcontroller comes aboard the extremely low
power Telos wireless sensor modules, from the Moteiv Corporation.
The following is a block diagram of the parking meter node system:
Telos Wireless Module
Banner Magnetic
Sensor
Analog
Input Pin
802.15.4
compliant wireless
transmitter
TI MSP430
Microcontroller
UART
Tx Pin
TTL to RS232
converter
LCD screen
(Serial Input)
Telos Wireless Sensor Module
The following is a functional block diagram of the Telos Wireless
Module:
5
Of interest is the 10-pin expansion connector, which will be used to
take input from the Banner Vehicle Detection Sensor, as well as to
send display data to an external LCD screen. Its pin functionality is as
follows:
Vehicle Detection
Vehicle presence is detected using a magnetic sensor from the Banner
Corporation. Magnetoresistive sensors convert magnetic fields to a
differential output voltage. When a ferromagnetic material (i.e. a
vehicle) is introduced into the magnetic field, the sensor detects the
change in the local magnetic field. The Banner sensor outputs the
equivalent of the voltage used to power it when it detects a vehicle.
The sensor output is connected to one of the analog inputs of the
microcontroller. The sensor’s pins of interest are as follows:
Banner
Magnetic
Sensor
brown
+
blue
-
white
black
10-30 v (input)
outputs
brown
The output voltage of the sensor gets converted to a digital signal onboard, since the analog inputs are connected to analog-to-digital
converters. Thus, we can decide upon the presence or absence of a
vehicle. The sensor is supplied with power through the brown and
blue wires, while either the white or black output wire connects to the
ADC pin.
Serial LCD Display
The Serial LCD Display is used to represent the current status of a
meter’s parking space as either ‘Available’ or ‘Not Available’. The LCD
takes an RS232 input, and is powered using a 5V battery pack. The
6
Telos UART Tx pin provides TTL output. This output is connected to an
RS232 driver chip, which converts TTL to RS232. The RS232 output
from the chip is connected to the serial input of the LCD display. Thus,
we can display the current parking meter status on the LCD at all
times.
Firmware
The TI MSP430 microcontroller uses the TinyOS embedded operating
system, an event-driven OS designed for sensor network nodes with
limited resources. We program the mote using the nesC programming
language, which is an extension to the C programming language
designed for use with TinyOS. In nesC, programs are made up of
various components, which are wired together (combined) to create
the desired functionalities. We use different firmware for the parking
meter nodes, and for the base node (plugged into the hub).
The following is a block diagram of the parking meter node
functionality:
Parking Meter Node
Receive
Messages
from HUB
Receive
Sensor Input
Standard
Control
Send
Messages to
HUB mote
Send
Messages to
LCD
At regular intervals, the sensor input pin is polled for the current
sensor value. If a change in the vehicle presence state occurs, a
message is sent to the HUB mote indicating this change. Meanwhile,
the HUB can send messages to the node indicating the meter status.
The meter sends serial messages to the LCD to display the current
meter status (‘Available’ vs. ‘Not Available’ vs. ‘Illegal’).
The following is a block diagram of the base node functionality:
7
HUB Node
Receive
Messages
from Nodes
Receive
Messages
from HUB
(PC)
Standard
Control
Send
Messages to
HUB (PC)
Send
Messages to
Nodes
The base node is plugged into the USB port of a PC, and is used to
communicate with the PC. When messages are received from the
parking meter nodes at the base node, they are forwarded along to
the services running on the PC (HUB), which then communicate the
appropriate information to the central server. When the HUB receives
messages from the central server, it forwards them along to the base
node, which in turn sends a message out to the appropriate parking
meter node(s).
8
Task Scenarios
Possible tasks that might occur include the following (we will use a
PC to simulate the cellular hub/controller):
Task
User Actions
Summary
Reserve
 Search for and
parking spot
reserve a parking
in
advance
spot using either
and proceed
the web interface
to park in  Provide system
that spot
with payment
information
 Receive pass code
for reserved spot
 Arrive at and park
in reserved spot
 Enter pass code
into parking meter
node
 Leave spot within a
legal amount of
time and have the
parking fee
automatically
charged
Park
in
available spot
without
reserving it
 Locate available
parking spot whose
parking meter node
does not indicate
“reserved”
 Park in spot for a
legal amount of
9
System Actions
 Display available parking
spots based on user’s input
request
 After user selects a spot,
provide a pass code and
update database to reflect the
reserved spot and payment
information
 Central server alerts
appropriate cellular
hub/controller of the reserved
spot
 Cellular hub/controller sends
message to parking meter
through wireless network
 Parking meter node detects
presence of vehicle and
queries for pass code
 Parking meter node validates
pass code and propagates
update back through meter
node network to cellular
hub/controller, to central
server
 Once parking meter node
detects departure of the
vehicle, central server is
alerted, and queries the
database to apply appropriate
parking fee
 Parking meter node detects
presence of a vehicle and
sends the appropriate
message through the wireless
node network, through the
cellular hub/controller, and to
the central server
time
 Be charged for the
appropriate amount
 Vacate parking spot
Park illegally
in an already
reserved spot
 Park
in
parking
spot whose meter
node
indicates
“reserved”
10
 Cellular hub/controller accepts
payment
 Meter node detects that
vehicle is no longer present,
displays unreserved, and
alerts rest of system of
updated node status
 Parking meter node detects
presence of vehicle and
queries for pass code
 After a set period of time,
pass code is not entered and
meter displays “illegal”
 Meter node propagates
update back through meter
node network to cellular hub,
to central server indicating an
illegally parked vehicle
 Database is updated with the
parking violation so that
parking enforcement officers
can take the appropriate
actions
Ad-Hoc Routing (Suchit Mishra)
Introduction
Wireless sensor networks are composed of large numbers of tiny
resource-limited devices (motes). A first application of these networks
is data collection in uncontrolled environments, such as nature
reserves or seismically threatened structures. Four key features have
emerged in networks that have been deployed: interaction with the
local environment though sensors, communication via a wireless
network, lifetime requirements of months to a year, and physical
inaccessibility. Several generations of motes have been designed at UC
Berkeley. Although very resource constrained, motes are very reactive
and participate in complex distributed algorithms, such as data
aggregation or spatial localization. This combination of requirements
makes traditional operating systems and programming models
inappropriate for sensor networks. Luckily, mote hardware has evolved
rapidly:
A sensor network operating system named tinyOS and programming
language nesC made it easy for us to make our hardware and
networking components work together.
TinyOS
TinyOS is an operating system specifically designed for network
embedded systems. TinyOS has a programming model tailored for
event-driven applications as well as a very small footprint (the core OS
requires 400 bytes of code and data memory, combined). TinyOS has
several important features that influenced nesC’s design: a
component-based architecture, a simple event-based concurrency
model, and split-phase operations.
Component-based architecture: TinyOS provides a set of reusable
system components. An application connects components using a
wiring specification that is independent of component implementations;
each application customizes the set of components it uses. Although
most OS components are software modules, some are thin wrappers
around hardware; the distinction is invisible to the developer.
Decomposing different OS services into separate components allows
unused services to be excluded from the application.
Tasks and event-based concurrency: There are two sources of
concurrency in TinyOS: tasks and events. Tasks are a deferred
computation mechanism. They run to completion and do not preempt
11
each other. Components can post tasks; the post operation
immediately returns, deferring the computation until the scheduler
executes the task later. Components can use tasks when timing
requirements are not strict; this includes nearly all operations except
low-level communication. To ensure low task execution latency,
individual tasks must be short; lengthy operations should be spread
across multiple tasks. The lifetime requirements of sensor networks
prohibit heavy computation, keeping the system reactive.
Events also run to completion, but may preempt the execution of a
task or another event. Events signify either completion of a split-phase
operation (discussed below) or an event from the environment (e.g.
message reception or time passing). TinyOS execution is ultimately
driven by events representing hardware interrupts.
Split-phase operations: Because tasks execute non-preemptively,
TinyOS has no blocking operations. All long-latency operations are
split-phase: operation request and completion are separate functions.
Commands are typically requests to execute an operation. If the
operation is split-phase, the command returns immediately and
completion will be signaled with an event; non-split-phase operations
(e.g. toggle an LED) do not have completion events. A typical example
of a split-phase operation is a packet send: a component may invoke
the send command to initiate the transmission of a radio message, and
the communication component signals the sendDone event when
transmission has completed. Each component implements one half of
the split-phase operation and calls the other; the wiring connects both
commands and events across component boundaries. Resource
contention is typically handled through explicit rejection of concurrent
requests. In the example above, if the communication component
cannot handle multiple concurrent send operations, it signals an error
when a concurrent send is attempted.
Alternately, the communication component could queue the request
for future processing.
The simple concurrency model of TinyOS allows high concurrency with
low overhead, in contrast to a thread-based concurrency model in
which thread stacks consume precious memory while blocking on a
contended service. However, as in any concurrent system, concurrency
and non-determinism can be the source of complex bugs, including
deadlock
12
nesC, is a programming language for networked embedded systems
that represent a new design space for application developers. An
example of a networked embedded system is a sensor network, which
consists of (potentially) thousands of tiny, low power “motes,” each of
which execute concurrent, reactive programs that must operate with
severe memory and power constraints. nesC’s contribution is to
support the special needs of this domain by exposing a programming
model that incorporates event-driven execution, a flexible concurrency
model, and component-oriented application design. Restrictions on the
programming model allow the nesC compiler to perform wholeprogram analyses, including data-race detection (which improves
reliability) and aggressive function in lining (which reduces resource
consumption). nesC has been used to implement TinyOS, a small
operating system for sensor networks, as well as several significant
sensor applications. nesC and TinyOS have been adopted by a large
number of sensor network research groups, and so I chose these two
for building the networked parking OmniPark systems.
TinyOS and adhoc routing
TinyOS has a pressing need for a good ad-hoc routing service. Several
protocols have been developed, each of which has acknowledged
problems. One issue that has arisen is separating policies from
mechanisms; it would be a great help to have the ability to easily
experiment with a variety of different algorithmic building blocks, each
of which can be easily interchanged. TinyOS has developed general adhoc protocol component architecture; algorithms could be built in
components that follow this architecture.
Overview
Multi-hop routing has been broken into several components, shown in
Figure 1. At the top of the architecture is an application component.
Between it and the multi-hop component are an arbitrary number of
networking stack components (in the diagram, this is represented by a
possible Transport component). An application interacts with the
network stack through the Send and Receive interfaces; use of the
Intercept interface is optional, for in-network processing.
MultiHopRouter is the top-level configuration for the routing layer;
higher protocol layers interact with the subsystem through
MultiHopRouter’s provided interfaces.
13
Sending a Packet
Before sending a packet, a component should use the getBuffer
command to obtain a pointer to the data region of a packet. This call
allows interface users to remain unaware of the packet format used by
the provider. Calling the Send interface’s getBuffer has the side effect
of initializing protocol fields to denote that the current mote is the
source of the packet.
In the case of end-to-end protocols, such as ad-hoc routing, only the
originator of the packet should call Send.getBuffer. Calling Send.send
on MultiHopRouter calls MultiHopSend’s send command. MultiHopSend
calls the MultiHopRoute component, which chooses a route and fills in
the appropriate fields. Once the route has been selected, the packet
can then be transmitted through the AM SendMsg interface.
MultiHopRoute depends on some number of Estimator components to
make decisions on which route to use (not shown). For example, a
min-hop algorithm (similar to BLESS or Narpro) might have an
estimator that listens for protocol messages and updates routing
tables accordingly. A network link quality estimator might use link
quality broadcasts to communicate with neighbors. A given
RouteSelector uses some set of Estimators, each of which can have its
own specific interface, to decide on a route.
Routing/Receiving a Packet
AM’s message reception signals MultiHopRoute. MultiHopRoute
determines if the packet is destined for the local node. If so, it signals
MultiHopRouter’s Receive interface.
14
If not, it signals MultiHopRouter’s Intercept interface, which allows
higher-level components to peek into and modify packet payloads. The
return code on the Intercept event states whether the multi-hop layer
should send the packet or not; components can aggregate data from
several packets using this mechanism. The default Intercept handler
forwards all packets.
To forward the packet, MultiHopRoute calls Send.send on
MultiHopSend, using the same sending policy as if it was the packet
originator.
Naming
This ad-hoc routing architecture does not deal with the issue of
naming; it is designed for a collection routing scheme, in which many
nodes send to a single root. Naming could, however, be incorporated
by adding additional naming interfaces; for example, MultiHopRouter
could have an interface that fills in a network name given a
geographical location.
Roles
MultiHopSend
MultiHopSend is responsible for sending packets using the
implemented ad-hoc routing protocol. When a packet originates at a
node (as opposed to being forwarded), the application must call
getBuffer() before calling send(). This allows MultiHopSend to set
protocol fields to unique values so that it can distinguish forwarded
from originated packets (this can be important in the presence of
originator fields, etc.). MultiHopSend accomplishes this by calling
RouteSelect.initializeFields on RouteSelector. MultiHopSend does not
have any route selection logic and does not fill in the header fields
necessary to send a packet; this is all performed by RouteSelector. It
is, however, responsible for decisions such as when and how many
times to retransmit, and when alternate parents should be requested.
MultiHopRoute
MultiHopRoute is responsible for receiving protocol messages and
deciding whether it should forward them. If MultiHopRoute decides
that it should forward a message, then it passes the packet to
MultiHopSend.
RouteSelector
RouteSelector maintains routing state, which it uses to choose routes
for packets to send.
15
MultiHopSend passes it a packet buffer, which it fills in with the
necessary header fields to be later understood by MultiHopRoute.
RouteSelector makes its routing decisions using some number of
Estimators, each of which can have different interfaces. For example,
there might be a LinkQualityEstimator, a GeographicPositionEstimator,
and a PowerEstimator, the combination of which are used to choose
power-minimizing high-quality links that make geographic progress to
the desired destination.
Note:
Active messages have remained the basic networking primitive of
TinyOS. An active message is a simple message-based networking
abstraction where messages include an identifier that specifies an
action to be executed upon message reception. Although the
abstraction has changed little, its implementation and features have
changed substantially, due to changing hardware platforms and
emerging needs.
Interfaces
Send.nc
/*
* Authors: Philip Levis
* Date last modified: 8/12/02
*
* The Send interface should be provided by all protocols above layer
* 2 (GenericComm/AM). For example, ad-hoc routing protocols should
* provide this interface for sending packets.
*
* The goal of this interface is to allow applications to take part in
* buffer swapping (avoiding the mbuf problem) on send while being
* unaware of the structure of the underlying packet. When an
* application wants to send a packet, it should call getBuffer(),
* passing the packet buffer it will use. The underlying component,
* aware of the structure of its headers and footers, returns a
* pointer to the area of the packet that the application can fill
* with data; it also provides the length of the usable region within
* the buffer.
*
* The application can then fill this region with data and send it with
* the send() call, stating how much of the region was used.
*
* getBuffer(), when called, should set all protocol fields into a
16
* unique and recognizable state. This way, when a buffer is passed to
* send(), the component can distinguish between packets that are
* being forwarded and those that are originating at the mote.
* Therefore, getBuffer() should not be called on a packet that is
* being forwarded.
*
*/
includes AM;
interface Send {
command result_t send(TOS_MsgPtr msg, uint16_t length);
command uint8_t* getBuffer(TOS_MsgPtr msg, uint16_t* length);
event result_t sendDone(TOS_MsgPtr msg, result_t success);
}
Receive.nc
/*
* Authors: Philip Levis
* Date last modified: 1/30/03
*
* The Receive interface should be provided by all protocols above layer
* 2 (GenericComm/AM). For example, ad-hoc routing protocols should
* provide this interface for receiving packets.
*
* The goal of this interface is to allow network end-points to
* receive packet payloads without having to know about the internal
* structure of the packet or the layers below them in the stack.
*
* The Receive interface is only used at the communication end-point,
* allowing a buffer swap between the top-level application and the
* networking stack. Hops along the way that want to look at the
* internals of the packet (for in-network aggregation, for example),
* should use the Intercept interface.
*
* For example, if a packet takes the route A->B->C->D
*
* A: send();
* B: intercept();
* C: intercept();
* D: receive();
*/
includes AM;
interface Receive {
event TOS_MsgPtr receive(TOS_MsgPtr msg, void* payload, uint8_t
payloadLen);
17
}
Intercept.nc
/*
* Authors: Philip Levis
* Date last modified: 1/30/03
*
* The Intercept interface should be provided by all protocols above
layer
* 2 (GenericComm/AM). For example, ad-hoc routing protocols should
* provide this interface for in-network packet processing.
*
* The goal of this interface is to allow transmission hops to
* process packet payloads without having to know about the internal
* structure of the packet or the layers below them in the stack.
*
* The Interface interface is only used by nodes that are forwarding a
* multihop messages. A protocol layer does not perform a buffer swap,
but
* can tell lower layers to not forward a packet by giving a FAIL return
value.
* Using this, an in-network intermediary can receive multiple packets,
* aggregate their results, then forward them on to the destination.
*
* For example, if a packet takes the route A->B->C->D
*
* A: send();
* B: intercept();
* C: intercept();
* D: receive();
*/
includes AM;
interface Intercept {
/**
*
* Signals that a message has been received, which is supposed to be
* forwarded to another destination. Allows protocol layers above the
* routing layer to perform data aggregation or make applicationspecific
* decisions on whether to forward.
*
* @param msg The complete buffer received.
*
* @param payload The payload portion of the packet for this
18
* protocol layer. If this layer has layers above it, it should signal
* receive() with payload incremented by the size of its header. Payload
* is a pointer into the msg structure.
*
* @param payloadLen The length of the payload buffer. If this layer
* has layers above it, it should signal receive() with payloadLen
* decreased by the size of its headers and footers.
*
* @return SUCCESS indicates the packet should be forwarded, FAIL
* indicates that it should not be forwarded.
*
*/
event result_t intercept(TOS_MsgPtr msg, void* payload, uint8_t
payloadLen);
}
RouteSelect.nc
/*
* Authors: Philip Levis
* Date last modified: 8/12/02
*
* The RouteSelect interface is part of the TinyOS ad-hoc routing
* system architecture. The component that keeps track of routing
* information and makes route selection decisions provides this
* interface. When a Send component wants to send a packet, it passes
* it to RouteSelect for its routing information to be filled in. This
* way, the Send component is entirely unaware of the routing
* header/footer structure.
*/
includes AM;
interface RouteSelect {
command bool isActive();
command result_t selectRoute(TOS_MsgPtr msg);
command result_t initializeFields(TOS_MsgPtr msg, uint8_t id)
command uint8_t* getBuffer(TOS_MsgPtr msg, uint16_t* len);
}
We can broadly divide routing protocol components into three classes:
tree-based collection, where nodes route or aggregate data to an
endpoint, intra-network routing where data is transferred between innetwork end-points, and dissemination, where data is propagated to
entire regions. Essentially all applications use some form of broadcast
or dissemination to convey commands, reconfigure, or control in
network processing. Examining several multi-hop implementations, we
19
see the emergence of two common abstractions: (i) a neighborhood
discovery and link quality estimation service and (ii) an augmented
version of the AM interface that supports packet encapsulation and
monitored forwarding. I summarize the tree based class and common
abstractions, and then talk about the spanning tree algorithm used by
OmniPark.
TreeBased Routing
Tree-based routing is primary based on two pieces of information: a
parent node identifier, and a hop-count or depth from the tree root,
i.e., the parent’s hop-count plus one. A routing tree is built via local
broadcast from the root followed by selective retransmission from its
descendents.
A node routes a packet by transmitting it with the parent as the
designated recipient. The parent does the same to its parent, until the
packet reaches the root of the tree. The key design issues are how the
routing tree is discovered and maintained, as well as how the
forwarding is performed. Surge also uses beaconless tree formation
and maintains a table of candidate parents, but selects its parent
based on a combination of link quality (packet success rate) and hop
count. MultiHopRouter extend this approach by filtering the neighbor
set (based on link quality and other factors) and choosing the parent
based on an estimated cost to the root through each neighbor. Each
node computes quality estimates on incoming links and periodically
transmits these, along with its cost estimate to the root, allowing
neighbors to determine outgoing link quality and total path estimates.
Parent selection algorithms try to minimize either end-to-end packet
loss or, with link-level acknowledgments, total expected transmissions,
including retransmissions.
One reason why many implementations of tree-based protocols exist is
that it is straightforward to construct a basic tree-based topology and
forwarding mechanism. However, substantial care is required to
construct and maintain a stable topology that can provide good
connectivity in a diverse radio environment for weeks or months. The
introduction of parameterized interfaces in NesC, combined with the
development of more mature routing protocols made it possible to
build a robust, encapsulated routing layer that could be easily reused
in many applications.
20
OmniPark multi hop routing protocol
A common application of sensor networks is to sample a sensor
periodically (e.g. vehicle in our case) and report readings to a base
station, which is typically a node with a wired network connection and
power source. The motes organize themselves into a spanning tree
rooted at the base station. Each mote maintains the address of its
parent and its depth in the tree, advertising its depth in each radio
message (either sensor sample or forwarded message) that it
transmits. A node selects an initial parent by listening to messages
and choosing the node with the smallest depth; to seed the creation of
the spanning tree, the base station periodically broadcasts beacon
messages with depth 0. Nodes estimate parent link quality; when the
link quality falls below some threshold, nodes select a new parent from
their neighbor set based on link-quality estimates and depth. Once a
second, each mote samples its vehicle sensor and sends the sample to
its parent. Parents acknowledge received packets. It uses the
acknowledgments to provide a reliable transport layer; parent link
quality is calculated as the fraction of transmitted messages that are
acknowledged. When a node receives a message from another node, it
forwards the message to its parent. Vehicle sensor samples are
collected at the base station.
Some basics of the protocol:






Nodes sample and transmit their vehicle sensor reading
once a second.
Nodes use the message format specified in the header file
Multihop.h.
Nodes do not worry about packet loss
Duplicate messages are suppressed whenever possible
Only the parent node of a given node forwards the
message towards the base station.
Routing loops, if they arise, are rapidly suppressed. For
example, say we have a path in the network that looks like
this:
(Base) <--- A <--- B <--- C
If node "A" were to suddenly select node "C" as its parent,
a routing loop has been induced: node C routes to node B,
which routes to node A, which routes back to node C.
21
If a routing loop does occur, nodes avoid sending multiple
copies of the same message around the loop. This is
accomplished by keeping track of the sequence number of
the last message that was forwarded, and dropping any
incoming messages with a sequence number less than this
value. In addition, a routing loop is "broken" rapidly, by
forcing all nodes on the loop to select a new parent.
Lessons Learned
This entire project has been a great learning experience not only in
terms of the technology but also management. Dealing with people
has been the greatest challenge and technical hurdles seem to be
really simple comparatively in my opinion.
Using nesC was very intimidating given my background in high level
programming languages such as java and C#. nesC is more at the
systems level and requires understanding of most of the hardware
before actually getting into the software code. The multi hop routing
protocol was the next biggest challenge. Although, I managed to get a
simple version of the protocol running using spanning tree algorithm
realistically speaking there’s lot more to it like fault tolerance, security,
and quality of service that I didn’t take into account for this project
and will be covered at a future date.
22
Software Design (Divya Ramasahayam)
Architecture
High Level Design:
23
Enterprise-Relationship Diagram for the Database:
The database contains four tables.
Parking Meter Location Table: This table consists of static
information pertaining to the parking meter.
The parking meters are identified with unique ID’s.
Parking Meter Status Table: This table consists of dynamic data
about a parking meter such as the status of the parking meter (if
occupied or empty). Authorization code given when the spot is booked
by a customer, or an “invalid” entry if the sensor detects a vehicle
parked without authorization.
Validity Table: This table holds entries of the Parking Meters - where
any kind of illegal parking has occurred: overtime or unauthorized
parking
24
API:
The API will provide the following operations:
Search by Zip code:
The user can search for spots available in a certain
area by zip code. The result will be a list of spots
available in the area allowing the user to select an
available spot of his choice.
Search by Street and Avenue:
The user can enter the Street, Avenue and Zip code
he wants to look in. This will show him the available
spots on the street.
Search for earliest available spot by zip code:
The user can search for a spot which is not
available right now but will be available within the
next few hours (by zip code).
Search for earliest available spot by street address:
The user can search for a spot which is not available
right now but will be available within the next few
hours (by address).
Book the available spot:
The user can select a spot which is available and
choose to book it. The system will give the user a
unique authorization code that he will enter at the
spot in order to identify himself.
Register with OmniPark:
The user can create a username and password.
Login to website:
The user can login to the website.
Create Default Settings:
The user can create a few addresses where he
searches most often, so that he does not have to re
enter the address every time he visits the website.
25
Feature Implementation:

Development environment: The development environments
we intend to use are .NET and Visual C++

Programming Language: We plan to use C as
programming language for network protocol development.

Database: The Database we plan to use is SQL Server. The
database stores information about all the parking meters and
their status. The database is updated every time there is a
change in the status of a parking meter/spot.

Operating System: The Operating system proposed for use is
Windows XP and Windows CE for the PDA.
Web Server and Website: We plan to use IIS for the web
server and ASP.Net for the website.

26
the
Task Scenario:
The block diagram above shows a high level view of how the system
will work. The user will use a website to find information about the
parking spots available in the vicinity. The website will require the user
to register with the website in order to use the service. The user has to
log in to view any information. The user enters the zip code of the area
he wants to search for or the street and avenue he wants to look in.
The request for information is sent to the web server. The web server
contacts the middle tier which contains logic to extract the desired
data from the data base. The Data base also interacts with the map
database in order to provide the user with an interactive map to make
selection of the spot simpler.
If the spot is available the user is allowed to book the spot .The user is
given a unique authorization code if the booking is successful .This
information is propagated back to the hub which updates its local
information. The information is sent through a GPRS signal to the
cellular hub, which then transmits this information to the sensor device
through ad-hoc wireless signal.
When the commuter reaches a spot that he has already booked, he
will be required to enter the authorization code he is provided with
before parking. If the commuter does not enter any code and illegally
parks the vehicle, the sensor will detect the presence of the vehicle
without authorization and will send a signal to notify the violation.
The Data base will contain information about the sensors present in all
locations. The table will consist of some static information such as the
street address and zip code. Dynamic content will encompass things
like the status of the spot, the authorization code, check-in time and
check-out time (if the spot has been granted to a customer).
The system will also allow the detection of unauthorized parking. The
system will continually scan for unauthorized parking by checking if
the correct authorization code was entered and if the car checked out
at the correct time or if a vehicle(without a previous reservation) is
parked without paying at the hub. If there is a violation a signal will be
sent to the parking enforcement officer so he can take appropriate
action.
27
Front End (Rajat Dhariwal)
The databases and hardware form a reliable backend for the parking
system. But our front end is what gives us an edge over competition
since it does not involve any off-the-shelf product. The development
work done is unique to this project and beats all existing competing
applications by far. Most other parking providing services have a
simple textual interface with user having to browse a series of
webpages to make a reservation or search for available spots in a
locality. Central Parking Corporation is the biggest player in the
parking industry and it owns around 1700 parking garages all over the
country. http://www.parking.com/LotSearch/default.aspx is their user
interface.
We had two choices for the front-end, either to keep a textual
interface as above or go for a map-based graphical interface. The issue
was speed vs convenience. While the textual interface is extremely
speedy its very unintuitive and unappealing. User looks at the list of
addresses and translates them into visual maps to get an idea of the
distances from his work place or home. Thus on the whole textual
interface is actually more time consuming than graphical ones. Hence
we started looking for map-based services like mapquest, yahoo maps,
tiger maps. Tiger maps database could be used for development
purposes but systems based on it were quite slow and interface was
unattractive. Then we came across a german site which provided very
fast maps which one could scroll down or browse around in real-time
without having to reload like yahoo, mapquest. Then finally google
released it beta version of google maps in February. It had many
advantages over any other mapping services. Besides providing one of
the cleanest interfaces, it was very fast and provided the ‘infinite
scrolling’ feature. It had an easy-to-use interface with the map’s
display area being equal to the screen size.
Though google offered several advantages, it had some disadvantages
from developer’s standpoint. It was a new service, hence their was
hardly any literature / discussion / documentation available. They had
used javascript, xml and xsl for their application. All three of these
were new to our team members, and hence their was a significant
learning curve. Since it used javascript, the client-side script was
available but then the code was almost unreadable and server-side
script was unavailable. So we had to first figure out a way to run it as
a standalone application using custom data. This was the milestone for
the intermediate demo.
28
Google maps uses iframes and XmlHttpRequest object to communicate
with the serer side script. These are the two popular ways to pass
parameters to the server and receive text or xml response from the
server without reloading the page. The search and other parameters
(like pan, zoom) are passed to the server via the XmlHttpRequest
object. The XML response received is then displayed on the map. The
relevant information is also displayed on the side panels using XSL
stylesheets. So our main focus was to create a wrapper around the
XmlHttpRequest object overriding its methods so that instead of the
XML file generated by its search parameters it would display our
custom data. Using Python for CGI scripting we created a program
which simply takes a XML file as parameter and prints out its content
on the response stream. For the intermediate demo we made an
application taking in a custom made XML file and displaying it using
google maps.
For the final demo we had to create the user-interface where user
(commuter or parking enforcement officer) could enter the relevant
information easily and retrieve the available spots, reserve a spot or
check the current violations. Other than this we had to integrate it with
our own database so that a XML file can be generated on the fly based
on our search parameters and displayed on the maps.
We have kept our interface almost identical to google maps since its
already proven and very soon majority of people would get used to it.
Also we focused more on the development side providing essential
features rather than improving on the look-n-feel.
The final version is an easy-to-use interface which works real-time
(with normal spec servers and machines). The main reasons for the
speed and convenience are as follows.





It is based on google maps which provides fast retrieval of queries.
The query results are loaded in the same page due to
XmlHttpRequest and iframes. This not only does away with the
need to reload the static parts of the page but also creates a better
use experience.
Javascript is used to navigate between search, reserve and
violations menus and it makes the interface quite compact.
Although in the final demo only 2 hubs and 4 parking meters were
available, the interface has been tested and found to work
seamlessly with more populated databases too.
Updates tab provided on the right hand side panel indicates if there
have been any “relevant” updates since the time user has been
viewing the map. This prevents unnecessarily reloading of the map
29

in case of each update but at the same time making the user aware
of it without him having to refresh the screen or repeat the search.
In a real world scenario this would be very useful since there are
10-20 streets ~ 150 meters in user’s viewing area. There will be
changes almost every second and most of these are unwanted. For
example consider just a single street, say there are 5 spots
available on a street out of 10 and one of them is taken while the
user is viewing the map. User would not be bothered about it since
he selects spots streetwise and when he reserves a spot system
would automatically assign him the spot according to the current
state of database. Updates uses iframes and thus without reloading
the webpage gets refreshed every minute.
Save link feature is very important since most of the users have few
fixed destinations where they want to search parking for. Also when
you navigate since the changes are made via XmlHttpRequest
object the location on the address bar does not change. So on
pressing the back button you cant retrieve the last result in terms
of pan, zoom etc. Using the save link you can save the current
viewing area of the map in your login area and later you do not
have to go search and adjust the map everytime. The search is
done based on the latitude and longitude recorded.
A lot of javascript coding and moreover ‘code-deciphering’ went into
the project hours. We believe that integrating it with google maps and
enabling aforementioned features, it is going to be extremely useful
and one of its kind application for both the commuters and the parking
enforcement officers for a long time, if deployed.
Fig. 1 (a) and (b) show the differences before and after deployment of
this system.
30
Could be :
Fig 1.(a) Enforcement and maintenance officers
attending every parking meter as

Parking enforcement
officer looking for
expired meters

Metermaid collecting
coins at each meter

Commuter looking
for an empty parking
spot
follow the dotted trail the
current practice.
Parking violation alert
sent remotely to the
parking enforcement
officers’ handheld
Coin box full alert sent
remotely to the
metermaids
31
Fig 1.(b) OmniPark’s SmartMetersTM send remote alerts to the enforcement
and maintenance officers. Only these meters need to be visited.
Future Work
The map also supports integration with a GPS tracking system which
can report commuter’s coordinates on a real-time basis. Thus the
killing app to further this project would be to integrate it with handheld
devices such as PDA, Blackberry, Cell phones, in-car navigation
systems. Imagine driving into downtown being able to see the parking
condition of the whole area, along with your current location, while
driving in your car and of course the ability to ‘look n book’ a spot!
32
Unique System Innovations
None of the parking systems in today’s world have wireless ad-hoc
capable wireless parking meters. This is very unique and innovative
approach as the parking meters will become more intelligent and will
notify their state to a central server and help the end user make clever
decisions. This solution will not only reduce the congestion on the
roads but will also increase the revenues for the government.
Innovative features in the application:
 Sensors built for this application detect the presence of a vehicle
on the street
 Wireless network communication protocol between the parking
meters will relay the information and state of meters to the
central station
 Real time parking information will be available to patrons
 Real time information about expired meters will be available to
the parking enforcement officers
All this capability will be available citywide because of the wireless
distributed infrastructure.
33
Demo Sequences
Scenario 1
Vehicle is present in front of the meter
When a vehicle moves in front of the parking meter and rests, the
vehicle detection unit detects it and sends a signal to the
hub/controller at the end of the street. This happens because of the
wireless multi hop ad hoc present as the communication between them.
Scenario 2
Communication between hub on street to the central database
When a vehicle pulls over as in scenario 1, this information is send
from the hub/controller to the central database or in our case directly
to the central database.
Scenario 3
Patron is searching for an empty spot
Patron/user will surf through our website looking for an empty spot on
street. On discovering an empty space he/she will try to reserve a spot
to their final destination. The system will notify the patron that the
spot has been taken and will give him/her a spot number and a 4-digit
authorization code.
Scenario 4
Patron has reserved a spot
When the patron pulls over to the street for parking he/she will have
to enter the code and that’s when the actual parking meter sends
signal to the database for the clock to start ticking. As soon as the
patron pulls out of the spot the sensor detects this event and sends a
signal to the database that the vehicle checked out and a billing
amount is entered for the patron.
Scenario 5
Patron has exceeded the time limit
Patron has parked the vehicle on street and the time has expired. As
soon as this happens an alert goes out to the parking enforcement
officer and it is visible to him/her through the handheld device. The
patron can glance at the device and can easily determine the location
of the expired meter and issue a ticket to the commuter.
Scenario 6
Patron has parked illegally
34
Patron has parked in a reserved spot but has not paid. The wireless
parking meter sends an alert to the parking enforcement officer.
Scenario 7
HUB Failure
A HUB has failed and can no longer communicate with the parking
meter nodes or the central server. A HUB for a neighboring street
takes over for the failed HUB’s parking meter nodes and the system
continues to operate correctly.
35
Project Status & Future
The project is still in its nascent stages and will need a lot more
research and development to take it to the market.
To start with the most crucial component in the project is the vehicle
sensor. The current sensor used is a magnetic sensor and detects a
vehicle using the amount of the ferrous content in the body. This is not
the best mechanism as people could easily deceive the parking meter
by putting a shopping cart in front of it and generate a lot of false
alarms for the enforcement officer. So, in order to build a commercial
system the existing sensor needs to be changed and replaced with
more reliable and accurate vehicle sensor. This may require a lot more
research in sensor technology and will probably require us to build a
sensor from ground up and the cost of this sensor has to be really
cheap. Cost to manufacture the sensor will make or break the deal in
terms of the customer buying this product. Assuming we have figured
out a way to build a highly accurate and precise vehicle sensor then
the next hurdle is going to build a bullet proof, fault tolerant, and
secure routing protocol that can’t be hijacked by intruders and
malicious users. Building security is a computationally intensive
process and given the power limitation and microcontroller used in the
tmote Sky it is going to be a considerable challenge to accomplish
something in that range. The wireless communication is going to be
absolutely instrumental in how the other parts of the system behave.
For example, the PDA application, in car smart device, and the web
based interface will all fail miserably if the quality of service and if very
high bandwidth is not available to make the transaction. Assuming, we
have that in place the next biggest challenge is going to be
establishing security as there will be credit card transactions that
would be happening on the fly and people need information assurance
before they plan to use this system. So, from a commercial standpoint
the project has miles to go before it can get accepted by the masses.
It is an excellent idea that needs more time and effort to exploit it to
its full potential.
36