U.S. patent application number 13/141983 was filed with the patent office on 2011-12-29 for low power wireless parking meter and parking meter network.
Invention is credited to Josh Michael Bablich, Robert Thomas Buczkiewicz, Darren Scott Cameron, Gregory Emile Chauvin, Donald Wesley Church, Neil Stuart Erskine, Ben Garvey, Matt Gonia, George Allan MacKay, Glenn Eric Pederson.
Application Number | 20110316716 13/141983 |
Document ID | / |
Family ID | 42286819 |
Filed Date | 2011-12-29 |
United States Patent
Application |
20110316716 |
Kind Code |
A1 |
MacKay; George Allan ; et
al. |
December 29, 2011 |
LOW POWER WIRELESS PARKING METER AND PARKING METER NETWORK
Abstract
A parking meter and parking meter network is described as well
as a method of operating the parking meter and parking meter
network. The parking meter network includes a gateway that
transmits a first beacon message that is received at the parking
meter. The parking meter synchronizes an internal timer based on
the receiving of the first beacon message, and then goes to sleep
for a period of time. The gateway transmits a second beacon message
and the parking meter wakes up at the expiration of the sleep
period using the synchronized internal time and receives the second
beacon message.
Inventors: |
MacKay; George Allan; (New
Glasgow, CA) ; Chauvin; Gregory Emile; (Brookside,
CA) ; Erskine; Neil Stuart; (Halifax, CA) ;
Cameron; Darren Scott; (New Glasgow, CA) ; Church;
Donald Wesley; (Halifax, CA) ; Garvey; Ben;
(Halifax, CA) ; Bablich; Josh Michael; (Port
Washington, WI) ; Gonia; Matt; (Hubertus, WI)
; Pederson; Glenn Eric; (Sussex, WI) ;
Buczkiewicz; Robert Thomas; (West Bend, WI) |
Family ID: |
42286819 |
Appl. No.: |
13/141983 |
Filed: |
July 29, 2009 |
PCT Filed: |
July 29, 2009 |
PCT NO: |
PCT/CA2009/001058 |
371 Date: |
September 9, 2011 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61140543 |
Dec 23, 2008 |
|
|
|
Current U.S.
Class: |
340/870.02 |
Current CPC
Class: |
H01Q 1/24 20130101; Y02D
70/162 20180101; Y02D 70/166 20180101; G04C 11/026 20130101; Y02D
70/142 20180101; Y02D 70/26 20180101; G07C 1/30 20130101; H04W
52/0235 20130101; H01Q 1/42 20130101; H01Q 1/225 20130101; G04G
7/026 20130101; G07B 15/02 20130101; Y02D 30/70 20200801; G06Q
30/0284 20130101; H01Q 1/38 20130101 |
Class at
Publication: |
340/870.02 |
International
Class: |
G08C 15/06 20060101
G08C015/06 |
Claims
1. A method of operating a wireless parking meter network
comprising: transmitting from a gateway a first beacon message;
receiving at a parking meter the first beacon message;
synchronizing an internal timer of the parking meter based on
receiving the first beacon message; placing the parking meter in a
sleep mode for a period of time (sleep period); transmitting from
the gateway a second beacon message; placing the parking meter in a
wakeup mode at the expiration of the sleep period using the
synchronized internal timer; and receiving at the parking meter the
second beacon message.
2. The method of claim 1, further comprising: re-synchronizing the
internal timer of the parking meter based on receiving the second
beacon message.
3. The method of claim 1, further comprising: determining the start
of a transmission time slot of the parking meter for transmitting
messages to the gateway, the start determined using the
synchronized internal timer and occurring a length of time after
the transmission of beacon messages including the first and second
beacon messages; and transmitting from the parking meter a message
to the gateway in the transmission time slot.
4. (canceled)
5. The method of claim 1, wherein placing the parking meter in the
sleep mode for the sleep period comprises: setting the length of
time of the sleep period based on an expected length of time
between the gateway transmitting the first and second beacon
messages, the expected length of time is determined based on a
known rate at which the gateway transmits beacon messages and the
number of beacon messages that are to be transmitted by the gateway
between the parking meter receiving the first and second beacon
messages.
6-10. (canceled)
11. The method of claim 1, further comprising attempting to
register a repeater at the gateway comprising: receiving at the
gateway the join request message from the repeater, the join
request message including a repeater ID uniquely identifying the
repeater; determining using the repeater ID if the repeater is
currently registered with the gateway; determining if the maximum
number of repeaters have already been registered with the gateway;
registering the repeater with the gateway by assigning a short
system ID to the repeater when the maximum number of repeaters are
not registered with the gateway and the repeater is not currently
registered with the gateway; determining the short system ID
assigned to the repeater when the repeater is currently registered
with the gateway; sending from the gateway to the repeater the join
acceptance message including the short system ID assigned to the
repeater when the repeater is registered with the gateway; and
sending from the gateway to the repeater join denial message when
the repeater is not registered with the gateway.
12-15. (canceled)
16. The method of claim 11, wherein transmitting from the gateway
the first beacon message comprises: selecting one of the short
system IDs of repeaters registered with the gateway; and
transmitting the first beacon message including the selected short
system ID; and wherein the method further comprises: determining at
the repeater if the first beacon message includes the short system
ID of the repeater; and retransmitting the first beacon message
when the first beacon message includes the short system ID of the
repeater.
17-19. (canceled)
20. The method of claim 19, wherein the spread spectrum technique
for transmission of messages, including the first and second beacon
messages, in the parking meter network, wherein the spread spectrum
technique uses frequency hopping and comprises: transmitting from
the gateway the first beacon message on a first communication
frequency comprising: transmitting the first beacon message
including a network initialization vector (NIV) specifying the
frequencies used by the gateway for communications, the NIV
indicating an order of the frequencies used by the gateway, the NIV
including the first frequency and the second frequency;
transmitting from the gateway the second beacon message on a second
communication frequency, wherein the gateway transmits beacon
messages, including the first and second beacon messages, as the
first message after hopping to another communication frequency; and
transmitting from a second gateway a beacon message including a
second NIV specifying a second order of frequencies used by the
second gateway for communications, the second order of frequencies
orthogonal to the order of frequencies specified in the NIV.
21-24. (canceled)
25. The method of claim 1, further comprising: transmitting from
the parking meter a message to the gateway; receiving at the
gateway a message from the parking meter; sending the message to a
backend server using a network connection; maintaining the parking
meter in the wakeup mode after transmitting the message to the
gateway; processing the message at the backend server; sending a
response message back to the gateway using the network connection,
the response message based on the processing of the message;
transmitting the response message from the gateway to the parking
meter; receiving at the parking meter the response message from the
gateway; and placing the parking meter in the sleep mode.
26-28. (canceled)
29. The method of claim 25, wherein the message is a credit card
transaction message, and the response message is either a
transaction approval message or a transaction declined message.
30. The method of claim 1, further comprising: initiating
communication with an intended parking meter comprising:
transmitting from the gateway a beacon message including: an
indication that the beacon message is an asynchronous message alert
(AMA) beacon message; and a unique parking meter identification
(ID) of the intended parking meter; and receiving at the intended
parking meter the AMA beacon message.
31. (canceled)
32. The method of claim 30, further comprising: sending to the
gateway an AMA acknowledgement message acknowledging receiving the
AMA beacon message at the intended parking meter; maintaining the
intended parking meter in the wakeup mode; receiving at the gateway
the AMA acknowledgement message; transmitting from the gateway an
AMA message to the intended parking meter; receiving at the
intended parking meter the AMA message; and transmitting from the
intended parking meter an AMA message acknowledgement message
acknowledging receiving the AMA message; receiving at the gateway
the AMA message acknowledgement message.
33. (canceled)
34. The method of claim 32, further comprising: receiving an event
at a backend server; processing the event at the backend server;
generating the AMA message based on the processing of the event;
and sending to the gateway the generated AMA message and a unique
parking meter identification (ID) of the intended parking
meter.
35. The method of claim 34, wherein: receiving at the backend
server the event comprises receiving a transaction request for
purchasing parking at the intended parking meter comprising one of:
receiving the transaction request from a telephone; receiving the
transaction request from a mobile phone; receiving the transaction
request as a text message; receiving the transaction request from
an Internet enabled device; and receiving the transaction request
over a communication network; processing the event comprises
processing the transaction request; and generating the AMA message
comprises generating the AMA message including: the result of
processing the transaction request.
36. (canceled)
37. The method of claim 32, further comprising: placing the AMA
message in an AMA message queue of pending AMA messages at the
gateway; processing the pending AMA messages in the queue; and
transmitting from the gateway an AMA message to the intended
parking meter.
38. The method of claim 30, further comprising: controlling the
parking rate of the intended parking meter using the AMA message
comprising: transmitting to the intended parking meter in the AMA
message either: a rate multiplier comprising a decimal number
indicating a multiplication factor to be applied to a base parking
rate of the intended parking meter; or a rate index comprising an
index indicating one of a plurality of pre-programmed parking rates
to be applied as the parking rate of the intended parking meter;
and receiving the AMA message at the intended parking meter and
applying either the rate multiplier or the rate index received in
the AMA message to the parking rate of the intended parking
meter.
39. (canceled)
40. The method of claim 1, further comprising: initiating
communication with a plurality of intended parking meters
comprising: transmitting from the gateway a beacon message
including: an indication that the beacon message is a broadcast
message alert (BMA) beacon message; and BMA information for the
intended parking meters; and receiving at a subset of the plurality
of intended parking meters the BMA beacon message.
41-44. (canceled)
45. A method of operating a wireless parking meter in a parking
meter network, the method comprising: receiving at the parking
meter first beacon message from the parking meter network;
synchronizing an internal timer of the parking meter based on
receiving the first beacon message; placing the parking meter in a
sleep mode for a period of time (sleep period); placing the parking
meter in a wakeup mode at the expiration of the sleep period using
the synchronized internal timer; and receiving at the parking meter
a second beacon message from the parking meter network.
46. The method of claim 45, further comprising: re-synchronizing
the internal timer of the parking meter based on receiving the
second beacon message.
47. The method of claim 45, further comprising: determining at the
parking meter the start of a transmission time slot of the parking
meter for transmitting messages to a gateway of the parking meter
network, the start determined using the synchronized internal timer
and occurring a length of time after the transmission of beacon
messages including the first and second beacon messages comprising:
determining a time slot from a plurality of time slots of the
parking meter network to use as the transmission time slot of the
parking meter; and determining the time at which the transmission
time slot will start based on the number of the time slot in the
parking meter network, the length of the time slots and the length
of the beacon messages; and transmitting from the parking meter a
message to the gateway in the transmission time slot.
48. (canceled)
49. The method of claim 45, wherein placing the parking meter in
the sleep mode for the sleep period comprises: setting the length
of time of the sleep period based on an expected length of time
between receiving the first and second beacon messages, the
expected length of time is determined based on a known rate at
which the parking meter network transmits beacon messages and the
number of beacon messages that are to be transmitted by the parking
meter network between the parking meter receiving the first and
second beacon messages.
50-56. (canceled)
57. The method of claim 45, further comprising: transmitting from
the parking meter a message, including parking meter information,
to the parking meter network; maintaining the parking meter in the
wakeup mode after transmitting the message to the parking meter
network; receiving at the parking meter a response message from the
parking meter network; and placing the parking meter in the sleep
mode.
58-59. (canceled)
60. The method of claim 57, wherein the message is a credit card
transaction message, and the response message is either a
transaction approval message or a transaction declined message.
61. The method of claim 45, further comprising: receiving at the
parking meter an asynchronous message alert (AMA) beacon message
comprising: an indication that the beacon message is an AMA beacon
message; a unique parking meter identification (ID) of the parking
meter; sending to the parking meter network an AMA acknowledgement
message acknowledging receiving the AMA beacon message at the
parking meter; maintaining the parking meter in the wakeup mode;
receiving at the parking meter an AMA message; and transmitting
from the parking meter an AMA message acknowledgement message
acknowledging receiving the AMA message.
62-63. (canceled)
64. The method of claim 61, further comprising: controlling the
parking rate of the parking meter using the AMA message comprising:
receiving at the parking meter in the AMA message either: a rate
multiplier comprising a decimal number indicating a multiplication
factor to be applied to a base parking rate of the intended parking
meter; or a rate index comprising an index indicating one of a
plurality of pre-programmed parking rates to be applied as the
parking rate of the intended parking meter; and applying either the
rate multiplier or the rate index received in the AMA message to
the parking rate of the parking meter.
65. (canceled)
66. The method of claim 45, further comprising: receiving at the
parking meter a broadcast message alert (BMA) beacon message from
the parking meter networking including: an indication that the
beacon message is a broadcast message alert (BMA) beacon message;
and BMA information for the parking meter; and receiving at the
parking meter the BMA beacon message.
67-68. (canceled)
69. The method of claim 45, further comprising initializing the
parking meter including: detecting a beacon message indicating a
communication link; assigning a link quality indicator (LQI) value
to the communication link based on the detected beacon message;
detecting additional beacon messages, each beacon message
indicating an additional communication link; assigning an LQI value
to each additional communication link; ordering the communication
links based on their LQI values; and setting the communication link
with the best LQI value as the link to use when sending messages
from the parking meter.
70. (canceled)
71. A parking meter for use in a parking meter network comprising:
a parking meter mechanism; a radio board for receiving messages; a
processor executing instructions; and a memory storing instructions
executed by the processor; the executed instructions providing in
the parking meter: a radio board module operable to receive a
beacon message; a device module operable to: synchronize an
internal timer of the parking meter based on receiving the beacon
message, place the parking meter in a sleep mode for a period of
time (sleep period); and place the parking meter in a wakeup mode
at the expiration of the sleep period using the synchronized
internal timer.
72-94. (canceled)
95. A parking meter network comprising: a gateway for transmitting
beacon messages; and a parking meter comprising: a parking meter
mechanism; a radio board for receiving messages including the
beacon messages and transmitting messages; a processor executing
instructions; and a memory storing instructions executed by the
processor; the executed instructions providing in the parking
meter: a radio board module operable to receive a beacon message; a
device module operable to: synchronize an internal timer of the
parking meter based on receiving the beacon message, place the
parking meter in a sleep mode for a period of time (sleep period);
and place the parking meter in a wakeup mode at the expiration of
the sleep period using the synchronized internal timer.
96-102. (canceled)
Description
TECHNICAL FIELD
[0001] The present disclosure relates generally to parking meters,
and more particularly to low power wireless parking meters and a
system of low power wireless parking meters.
BACKGROUND
[0002] Cities may deploy thousands of single-space parking meters
throughout their jurisdiction. The management of such a deployment
is labor intensive. Costs of overhead can be larger than necessary
due to the normal inefficiencies in managing large distributed
systems.
[0003] Wireless parking meters have been devised that enable the
parking meter to communicate with enforcement officers or backend
parking meter management systems to make parking enforcement, as
well as management of the parking meters, more efficient. Networked
parking meters have used cellular networks for communication, or
other network communication such as WiFi (802.11a/b/g/n) protocols.
While these communication protocols may provide network
connectivity to the meter, their power requirements do not make
them ideally suited to their use in battery powered parking meters.
In addition the costs for a commercial cellular data plan required
for each module may become prohibitive.
[0004] Some wireless parking meters may use a low power
communication protocol such as ZigBee or SSIPCO for the wireless
communication. However, while these communication protocols are
designed for low powered devices, they may have unnecessary
overhead for use in a battery powered single space parking
meter.
[0005] The use of wireless systems have disadvantages when used in
battery powered parking meters, which may include, for example,
shorter operation time due to increased power consumption, and
communication latency when communicating with a backend system. The
power consumption and communication latency may be affected by the
communication protocol used.
[0006] Current wireless battery powered meters do not provide a
power efficient means for allowing a backend parking management
system to initiate communication with the parking meter in a manner
that provides low latency and low power consumption.
SUMMARY
[0007] In accordance with an embodiment of the present disclosure
there is provided a method of operating a wireless parking meter
network. The method comprises transmitting from a gateway a first
beacon message; receiving at a parking meter the first beacon
message; synchronizing an internal timer of the parking meter based
on receiving the first beacon message; placing the parking meter in
a sleep mode for a period of time (sleep period); transmitting from
the gateway a second beacon message; placing the parking meter in a
wakeup mode at the expiration of the sleep period using the
synchronized internal timer; and receiving at the parking meter the
second beacon message.
[0008] In accordance with a further embodiment of the present
disclosure there is provided a method of operating a wireless
parking meter in a parking meter network. The method comprises
receiving at the parking meter a first beacon message from the
parking meter network; synchronizing an internal timer of the
parking meter based on receiving the first beacon message; placing
the parking meter in a sleep mode for a period of time (sleep
period); placing the parking meter in a wakeup mode at the
expiration of the sleep period using the synchronized internal
timer; and receiving at the parking meter a second beacon message
from the parking meter network.
[0009] In accordance with a still further embodiment of the present
disclosure there is provided a parking meter for use in a parking
meter network. The parking meter comprises a parking meter
mechanism; a radio board for receiving messages; a processor
executing instructions; and a memory storing instructions executed
by the processor. The executed instructions provide in the parking
meter a radio board module operable to receive a beacon message;
and, a device module that is operable to synchronize an internal
timer of the parking meter based on receiving the beacon message,
place the parking meter in a sleep mode for a period of time (sleep
period), and place the parking meter in a wakeup mode at the
expiration of the sleep period using the synchronized internal
timer.
[0010] In accordance with yet a further embodiment of the present
disclosure there is provided a parking meter network. The parking
meter network comprises a gateway for transmitting beacon messages;
and a parking meter. The parking meter comprises a parking meter
mechanism; a radio board for receiving messages including the
beacon messages and transmitting messages; a processor executing
instructions; and a memory storing instructions executed by the
processor. The executed instructions provide in the parking meter a
radio board module that is operable to receive a beacon message;
and, a device module that is operable to synchronize an internal
timer of the parking meter based on receiving the beacon message,
place the parking meter in a sleep mode for a period of time (sleep
period), and place the parking meter in a wakeup mode at the
expiration of the sleep period using the synchronized internal
timer.
BRIEF DESCRIPTION OF THE DRAWINGS
[0011] Embodiments of the present disclosure will be described with
reference to the Figures in which:
[0012] FIG. 1 is a diagram showing an illustrative parking meter
network in accordance with the present disclosure;
[0013] FIG. 2 is a diagram showing an illustrative sub-system of a
parking meter network in accordance with the present
disclosure;
[0014] FIG. 3 depicts in a timing diagram the timing of a device
communicating using frequency hopping in accordance with the
present disclosure;
[0015] FIG. 4 is a diagram showing illustrative communication paths
of components in a parking meter network in accordance with the
present disclosure;
[0016] FIG. 5 is a diagram showing two illustrative sub-systems of
a parking meter network in accordance with the present
disclosure;
[0017] FIG. 6 is a diagram showing illustrative components of a
parking meter in accordance with the present disclosure;
[0018] FIG. 7 is a diagram showing illustrative components of a
parking meter in accordance with the present disclosure;
[0019] FIG. 8 is a flow diagram showing an illustrative method of a
gateway registering a repeater in accordance with the present
disclosure;
[0020] FIG. 9 is a flow diagram showing an illustrative method of a
repeater registering with a gateway in accordance with the present
disclosure;
[0021] FIG. 10 is a flow diagram showing an illustrative method of
initializing a parking meter in accordance with the present
disclosure;
[0022] FIG. 11 is a message flow diagram showing illustrative
messages for processing an event at a parking meter in accordance
with the present disclosure;
[0023] FIG. 12 is a message flow diagram showing illustrative
messages for a backend system communicating with a parking meter in
accordance with the present disclosure;
[0024] FIG. 13 is a message flow diagram showing illustrative
messages for processing a credit card payment at a parking meter in
accordance with the present disclosure; and
[0025] FIG. 14 is a message flow diagram showing illustrative
messages for processing a parking meter payment received at a
backend system in accordance with the present disclosure.
DETAILED DESCRIPTION
[0026] FIG. 1 is a diagram showing an illustrative parking meter
network system 100 in accordance with the present disclosure. A
parking meter network system 100 is depicted that comprises two
sub-systems 104 and 106. As further described herein the
sub-systems 104, 106 provide wireless communication between battery
powered parking meters and a back-end system 110. FIG. 1 depicts a
single illustrative parking meter 120; however it is understood
that multiple parking meters will typically be present in the
parking meter network systems 100. The sub-systems 104, 106 have a
communication coverage range in which they may communicate with
wireless parking meters. The communication range of the sub-systems
may overlap as depicted in FIG. 1, in which both sub-systems 104,
106 can communicate with parking meter 120. The range of the two
sub-systems 104, 106 is depicted as being 200 meters. However as is
well understood the range of wireless communication may be affected
by various factors, including for example the location of obstacles
and other electromagnetic signals. As such the communication ranges
described herein are to be understood as illustrative. Furthermore
the communication ranges may be changed by adjusting the power of
the transmitter in order to obtain the desired communication
coverage.
[0027] The sub-systems 104, 106 are arranged in an area where
wireless parking meters 120 are deployed, for example along city
streets 102, or parking lots. The sub-systems 104, 106 may be
connected to a back-end system 110 through various communication
means, for example, through a wired or wireless internet connection
or a cellular network. Regardless of the specific connection, it is
understood that the sub-systems 104, 106 are considered to be
connected to the back-end system 110 generally through a network
108.
[0028] The back-end system 110 may be a computer or server running
software that allows the parking meter network 100 to be managed.
As is will be understood, the computer or server includes at least
one processor for executing instructions stored in a memory. As is
further understood, the computer or server may comprise multiple
processors and memory units. Furthermore the implementation of the
backend system may be distributed across multiple computers or
servers that may be located in the same or different areas and are
operatively coupled together. The back-end system 110 may provide
auditing of the parking meter network system 100, including, for
example, determining the usage of various parking meters 120 to
help determine parking patterns. The back-end system 110 may also
provide enforcement information such as locations of high activity,
or where parking meters 120 have expired. The back-end system 110
may also provide maintenance information such as which meters are
jammed or require a battery to be replaced. This information may be
sent to enforcement officials or maintenance personnel. The
information may also be used in planning parking regulations.
[0029] As described further herein, the back-end system 110 may
also be used to co-ordinate payment at parking meters 120. For
example the parking meters 120 and parking meter network system 100
as described herein may be used to facilitate the use of a credit
card at a parking meter 120 for making payment, or may facilitate
the use of alternative methods of payment, such as the use of a
cell phone, SMS text messages, or over the Internet or using an
Internet, or other communication network, enabled device.
[0030] As shown in FIG. 1, the communication range of sub-systems
104, 106 may overlap. This may be advantageous for providing more
reliable communication with the parking meter 120, since a parking
meter 120 may be able to communicate with multiple sub-systems 104,
106. In order to avoid the communication signals of the two
sub-systems from interfering with each other, the parking meter
network system 100 uses spread spectrum techniques, such as
frequency hopping, to communicate with the meters 120.
[0031] Each sub-system 104, 106 communicates with meters 120 using
frequency hopping. Each sub-system 104, 106 is provided with a
channel set that determines the frequency channels it will
communicate on. The channel set provided to the sub-systems 104,
106 may be a pseudo-random order list of frequencies as the channel
set. Each channel set is orthogonal to the other channel sets, as
such adjacent sub-systems are able to communicate with parking
meters 120 without interfering with the communication of adjacent
sub-systems 104, 106.
[0032] Although only two sub-systems 104, 106 are depicted, as many
sub-systems may be used as is required to provide sufficient
coverage of the area in which wireless parking meters are
deployed.
[0033] FIG. 2 is a diagram showing an illustrative sub-system 104
of a parking meter network in accordance with the present
disclosure. It is understood that the sub-system 104 described with
reference to FIG. 2 would be similar to additional sub-systems used
in the parking meter network 100; however the additional
sub-systems would use different channel sets.
[0034] The sub-system 104 comprises a gateway 205, a plurality of
repeaters 210, 211, 212, 213, 214, 215, and a plurality of wireless
parking meters 120 deployed about a city street 102. Also depicted
in FIG. 2 are wireless parking meters 222 which are not in
communication with the sub-system 104. These parking meters 222
could be in communication with another sub-system (not shown).
[0035] The gateway 205 acts as a link between the wireless parking
meters 120 and the back end system 110 of FIG. 1. The repeaters
210-215 repeat messages they receive, either from the gateway 205
or from parking meters 120. The communication range of the devices
205, 210-215 and 120 is typically the same range. A repeater 215 is
depicted as having a communication range of 100 meters. As a
result, it will be placed within 100 meters of the gateway 205,
which will result in the 200 meter communication range of the
sub-system 104, depicted in FIG. 1, since a parking meter 120 will
be able to communicate with the repeater 215 from a distance of 100
meters, and the repeater can communicate with the gateway 205 from
a distance of 100 meters.
[0036] Although it is possible to use multiple repeaters 210-215 to
pass a message from a parking meter 120 to the gateway 205, in
order to achieve a low latency for communication only a single
repeater is used when communicating between a parking meter and the
gateway 205. That is, a message may be passed from a parking meter
120 to a repeater 215 to the gateway 205. However, it is not passed
from the parking meter 120 to the repeater 215 then to another
repeater 214 and finally to the gateway 205. This restriction is
made in order to maintain a low latency for communication. It is
understood that in situations where a higher communication latency
is acceptable this restriction may be relaxed.
[0037] As described further herein, messages are passed between the
gateway 205 and the parking meters 120. The repeaters 210-215
forward messages either to the parking meters 120 from the gateway
205, or to the gateway 205 from the parking meters 120 if the
parking meters 120 are out of communication range of the gateway
205. In order to minimize the system requirements of the repeaters,
for example the amount of memory required for storage and/or the
processing power of its processor, they do not store messages and
only forward messages on.
[0038] As set forth above, the sub-systems 104, 106, or more
particularly the gateways, repeaters and parking meters of the
sub-systems, use the spread spectrum technique of frequency hopping
for communication. The carrier frequency used to communicate
between devices of the sub-systems of the parking meter network can
change many times per second. A communication system that uses a
single channel is less robust than a communication system that
changes channels. As required by the FCC, each channel cannot be
used more than 400 ms in a 10 second window. Also, all channels
must be used equally by the system and by every device within the
system. To satisfy these requirements, at least 25 channels should
be used and all sub-system devices should channel hop.
[0039] FIG. 3 depicts in a timing diagram the timing of a
communication device communicating using frequency hopping. The
dwell time 302 is the time the communication device spends
communicating on each channel. The blanking interval 304 is the
unusable time that occurs between channel changes. As described
herein a beacon message may be transmitted at the beginning of each
frequency hop. The time between transmitting beacons is the sum of
the dwell time and the blanking interval and is depicted as the
beacon interval 306 in FIG. 3. The dwell time 302, blanking
interval 304 and the beacon interval 306 are constant as is
illustrated in FIG. 3. The parking meter system dwell time may be
for example 400 ms. The parking meter system blanking interval may
be for example 500 uSec.
[0040] A channel set is an ordered list of channels, also referred
to as frequencies, a radio of a sub-system device will cycle
through as part of its frequency hopping. In the parking meter
network system there may be, for example, 16 channel sets, each
consisting of the same 25 channels in different pseudo-random
orders. The channel sets can be created orthogonally, for example
by having sequences of channels in different directions so that the
channels could only overlap once per channel set cycle, to minimize
the amount of interference between radios using different channel
sets. The number of channel sets is not bound by a firm system
requirement. Sixteen (16) channel sets may be sufficient for a
parking meter network system application. However, the number of
channels sets may be varied depending on the requirements of the
parking meter system. Also, the above has described the 16 channel
sets as using the same 25 channels in differing orders, It is
possible for the parking meter network system to use more channels
than 25; however each channel set would still comprise an ordered
list of 25 channels, or the number of channels used in a channel
set.
[0041] The specific channel set used by a gateway 205 can be
configured during installation of the gateway 205. The gateway 205
may then forward the channel set it is configured to use for
communicating to a repeater when it joins the parking meter system
via a Network Initialization Vector (NIV). The NIV includes the
channel set indicating the frequencies, and their order used by the
gateway 205. The NIV may also be received by parking meters in
order to determine the channel to use in order to communicate with
the gateway.
[0042] When gateway 205 hops to the next frequency in the channel
set it transmits a beacon message that includes the NIV of the
gateway 205. This beacon message may be used by the parking meters
120 and the repeaters 210-215 in order to synchronize their
communication timing and frequency hopping timing. The
communication timing may provide a time window for a sub-system
device to use when communicating with other sub-system devices. The
beacon message may also be used by the meters 120 and repeaters
210-215 in order to determine the channel set used by the gateway
205, through the NIV.
[0043] In order to initially receive a beacon message a repeater or
parking meter 120 may scan through all of the frequencies used in
the collection of channel sets of the parking network system to
detect if a beacon message is being broadcast. These frequencies
may be pre-programmed into the repeaters and parking meters. The
parking meter or repeater may listen on each frequency for a given
period of time to detect a beacon message, for example the dwell
time of 400 ms before switching to another frequency. It is
possible to detect beacon messages being transmitted in different
ways. For example, instead of dwelling on each frequency for the
illustrative dwell time of 400 ms, the parking meter or repeater
may dwell on each frequency only long enough in order to detect if
a beacon is being transmitted, and if a beacon is detected the
receiver or parking meter may remain on the frequency until the
beacon has been received. Alternatively, if the channel sets all
comprise the same frequencies, a repeater or parking meter may
dwell on a single frequency for an entire channel set cycle. The
time may be, for example, [dwell time (500 ms)+blanking interval
(500 us)].times.number of frequencies in channel set (25). This
method may be used even if there is only a single frequency which
is common to all channel set. This may be extended in order to
listen to a first frequency for the channel set cycle to for
example detect beacons from gateways using a first set of channel
sets with the first frequency in common, followed by detecting
beacons on a second frequency common to a second set of channel set
used by gateways in the parking meter network system. Regardless of
the technique used, once a beacon message is detected, the repeater
or parking meter is able to determine the channel set used by the
gateway 205 from the NIV included in the beacon message and no
longer needs to hop through all of the frequencies used by the
parking meter network.
[0044] Each repeater 210-215 registers with the gateway 205. The
number of repeaters that may register with the gateway 205 may vary
depending on the requirements of the system, however as described
herein, the gateway 205 is able to register up to 6 repeaters. When
a repeater registers with a gateway 205 it uses the gateway's
channel set described in the gateway's NIV for communications. Once
a repeater registers with a gateway it begins to send beacon
messages as well. As described further herein the timing of the
sending of beacon messages may occur in a predetermined manner; and
only a single repeater of the possibly 6 registered repeaters
broadcasts a beacon message after the gateway's beacon message.
This may be coordinated by having the gateway broadcast a beacon
message including a short system ID assigned to the repeater that
is to repeat or forward the beacon message.
[0045] Unlike repeaters 210-215, each parking meter 120 may
communicate with different sub-systems comprising a gateway 205 and
any registered repeaters. Each parking meter 120 determines the
best communication path to a gateway 205 and uses that path for its
communications. If the determined best path is broken or
unavailable, the parking meter is able to select and use a
different path, either to communicate with the same gateway, or a
different gateway. In order for the backend system 110 of FIG. 1 to
communicate with individual parking meters 120, each parking meter
is provided with a unique identifier. The unique identifier may be
a 32 bit number.
[0046] FIG. 4 is a diagram showing illustrative communication paths
of components in a parking meter network system in accordance with
the present disclosure. Each parking meter 120 is able to determine
the link quality of messages it receives. For example a radio of
the parking meter 120 may provide a measure of the quality through
a link quality indicator (LQI). During the initialization of a
parking meter 120, the parking meter 120 scans all available
frequencies to determine all available communication paths to
gateways. This is done by receiving beacon messages from gateways
and/or repeaters. A parking meter 120 associates a LQI value with
each beacon message it receives. Each beacon message indicates a
possible communication path from the parking meter to a gateway.
The path may either be direct or through a repeater. Once the
parking meter has received all beacon messages, they are ordered
from highest LQI to lowest LQI. The parking meter will then use the
highest quality communication path available for its subsequent
communication.
[0047] With reference to FIG. 4, parking meter 120 has three
communication paths available for communicating with the gateway
205. The first path is a direct path to the gateway 205 with an LQI
of 60. The second path is through repeater 215 and has an LQI of
10. The third path is through repeater 214 and has an LQI of 30.
The parking meter 120 would preferably use the direct path to the
gateway for communication. If this communication path is unusable,
for example multiple messages sent from the parking meter to the
gateway are not acknowledged, the parking meter 120 will attempt to
use the next best communication path, in the example of FIG. 4 this
would be through repeater 214. If this link is unusable, for
example messages sent through the repeater 214 are not acknowledged
by the gateway 205, the parking meter would use the next best path,
which would be through repeater 215. The example of FIG. 4 depicts
only a single gateway 205, however the parking meters 120 are not
registered with a particular gateway 205, and as such it is
possible to use a communication path to another gateway, as
described below with reference to FIG. 5.
[0048] FIG. 5 is a diagram showing two illustrative sub-systems of
a parking meter network in accordance with the present disclosure.
FIG. 5 depicts two sub-systems 104, 106, each with a gateway 205,
405 respectively. Parking meter 120 is within communication range
of both gateways 205, 405 of the sub-systems 104, 106. This
communication may either be direct or through a repeater (not
shown). When the parking meter 120 is initialized it will determine
all possible communication paths, not just the communication paths
to a single sub system. As such if communication is lost with the
highest quality path, for example with gateway 205, the parking
meter 120 will use the next highest quality link, even if that is
through a different sub-system, in this case through gateway
405.
[0049] FIG. 6 is a diagram showing illustrative components of a
parking meter 120 in accordance with the present disclosure. The
components of the electronic parking meter 120 may be selected to
operate from a 3.3 volt power supply (not shown) in order to
contribute to the energy efficiency of the parking meter 120.
[0050] The electronic parking meter 120 includes a microcontroller
530, which may be used to control its operations. The
microcontroller 530 comprises a number of components that populate
a printed circuit board (PCB) (not shown). It has been found to be
particularly advantageous to have all of the components located on
one side, the front side, of the PCB so that there is sufficient
space on the backside of the PCB for a battery pack (not
shown).
[0051] The microcontroller 530 comprises a processor (CPU) 531
associated with a flash memory 532 and a random access memory (RAM)
533. CPU 531 may be a Texas Instruments--MSP430F449 processor or
any other type of similar processor operating at 3.3 volts. The
flash memory 532 is a rewritable memory in which is stored the
electronic parking meter 120 software and operating parameters, as
well as radio control components as described further with
reference to FIG. 6. The RAM 533 may be a fast read-write memory
for the temporary storage of variables and the like during software
processing.
[0052] The microcontroller 530 clocking system is basically
controlled by a 32.768 kHz crystal clock 534, which drives
frequency locked loop (FLL) 535 to provide an output having a
frequency of 7.3 MHz, the operating frequency for the CPU 531.
However, in addition the clock 534 drives a basic timer 536 that
may be used as an internal timer to periodically wake-up the CPU
531 from a low power or sleep mode as well as to control the CPU
531 to produce a real time clock which may be used to provide
parking meter functionality, such as when to apply particular rate
schedules. In this particular embodiment, the basic timer provides
a 64 Hz output signal. A further 3.58 MHz crystal clock 537, which
is normally powered off, is also adapted to be coupled to FLL 535.
Clock 537 is powered up, when required, to provide an appropriate
clock for a card reader to be described below. In this situation,
clock 534 continues to be coupled to basic timer 536 to provide the
64 Hz signal.
[0053] The microcontroller 530 may include a temperature sensor
538, which measures the actual temperature of the environment of
the microcontroller 531 of the parking meter 120. The temperature
sensor 538 may be polled periodically to log the temperature of the
meter. The temperature may be logged in flash memory 532. The
temperature reading may be used for a number of purposes such as to
adjust a real time clock, to modify the operation of LCD's, to
compensate for battery power level fluctuation due to temperature
change and to compensate coin sensors in a coin chute.
[0054] The parking meter 120 has input and output interfaces 539
that may include a number of devices. A standard input device for
parking meters 120 is a coin chute 540, which receives coins
inserted into a coin slot in the meter 120 housing and which, using
coin sensors 541, recognizes the coins. One form of coin chute is
described in U.S. Pat. No. 6,227,343 issued on May 8, 2001, which
is incorporated in its entirety herein by reference. The coin chute
540 is normally in the sleep mode, however CPU 531 under the
control of the basic timer 536, periodically polls the coils in the
coin sensors 541 to determine if a coin is dropping through the
chute 540. Coin chute 540 may be modified from the chute described
in the above patent regarding the hardware for processing
information. Rather than include a processor within the coin chute,
the present coin chute 540 performs an analog to digital conversion
to digitize the information generated by the coin sensors 541; the
digitized information is transmitted to CPU 531 through the I/O 539
where it is processed to determine the time purchased by a user.
The coin transaction information may also be stored in the
electrical erasable programmable read only memory (EEPROM) 542.
This audit information may therefore remain with the chute 540 if
it is removed for maintenance or for insertion into another parking
meter.
[0055] The chute 540 can further include an RF communications port
543 that is accessed by inserting an antenna into the coin slot of
the coin chute 640 to achieve high speed wireless communications
with the meter 120 CPU 631.
[0056] An optional input device for the parking meter 120 is a card
reader 545 for a smart card 546 that is ISO 7816 compliant. The
standard operating voltage for smart cards 540 is 1.8, 3 or 5
volts. Since the power supply (not shown) output voltage is 3.3
volts, the ISO 7816 interface 547 is used to step up the supply
voltage to 5 volts or step down the voltage to 1.8 or 3 volts. As
with the coin chute 540, the card reader 545 is normally in the
sleep mode consuming insignificant amounts of power. However, in
the case of the card reader 545, a mechanical switch causes an
interrupt when a card 546 is inserted into the reader 545. CPU 531
thus interrogates the card reader 545 through ISO 7816 interface
547 to determine the operating voltage of the card and than starts
the routine for payment by smart card 546.
[0057] With the addition of a SAM socket 548, the parking meter 120
is able to validate the money on the card 546 and decode
information through decryption algorithms and keys, which are
stored on the SAM 548. Using a SAM 548, the meter 120 will be able
to accept higher level card systems, may take money off of the card
and store it in the SAM 548 itself or in memory 532. This money
data may then be taken from the SAM 548 or the memory 532 through
an audit.
[0058] Card reader 545 purchase interfaces fall into two standard
groups. The first is a buttonless approach. A card 546 is inserted
into the card reader 545 and after the card 546 is identified and
read, parking time is incremented automatically on the parking
meter 120, i.e. the longer a card is left in the reader 545 the
greater the amount of time has been purchased. Thus a user has to
watch the time increment on the meter 120 and then remove the card
546 when the desired amount of time is reached. In the second
approach, the card 546 is identified and read in the same manner as
the first, however in this case the user must manually increment
the time desired on the meter 120. This is accomplished by having
the user push a button 550. Thus the time increments with every
push of the button 550, allowing the user greater control.
[0059] The card reader 545 may also include a credit card reader
for reading credit card transactions. The parking meter network
described herein provides a low latency and low power communication
protocol that enables battery powered parking meters to communicate
with a back-end system to process credit card transactions.
[0060] In addition to the parking meter mechanism components
described above, the parking meter 120 includes an RF radio board
560 for communicating with the gateway 205, or repeaters 210-215.
The radio board 560 may include a radio module 562 that includes a
radio transceiver 566 for transmitting and receiving RF signals, a
microcontroller 564 for controlling the transceiver 566, a
plurality of oscillators 570,572 for providing the required timing
signals and an antenna 568 for sending and receiving the RF
signals. The antenna 568 may form part of the RF radio board 560,
or it may be connected to the RF radio board, for example by a wire
or cable which may allow the antenna to be placed in the parking
meter in a location that maximizes the transmission of the signals,
and so reduce the power requirements of the parking meter.
[0061] The RF radio board 560 may be connected to the parking meter
mechanism through an expansion port or other type of connection.
The expansion port may connect the microcontroller of the RF radio
board with the microcontroller of the parking meter mechanism. The
parking meter mechanism may control the operation of the RF radio
board by sending commands to the microcontroller of the RF radio
board over an SPI Bus. The radio board 560 is described in relation
to a parking meter, however substantially similar radio boards may
be included in other devices of the parking meter network system,
including the gateways and repeaters.
[0062] The microcontroller 564 and transceiver 568 may be separate
components or may be provided in a single package. In one
embodiment the microcontroller 564 and the transceiver 568 are
provided in a single package and is a CC1110F16RSP sold by Texas
Instruments. The RF radio board may transmit/receive in the
industrial, scientific and medical (ISM) band in the 902-928 MHz
frequency range. This is often referred to as a 900 MHz system.
Although the 900 MHz band is described, it is understood that a
different band may be required in certain jurisdictions, such as
the 2.4 GHz band.
[0063] FIG. 7 is a diagram showing illustrative components of a
radio device in accordance with the present disclosure. The radio
device may include gateways, repeaters and/or parking meters. The
components of FIG. 7 may be implemented within the hardware of the
device 600. The components may be implemented using instructions
stored in memory of the device. These instructions may include
software code, firmware, hardware or a combination thereof. The
device 600 refers generically to a gateway repeater or parking
meter. The device 600 comprises a radio module which may be
implemented in part or in whole by the RF radio board 560 described
with reference to FIG. 6, and a device module which may be
implemented in part or in whole by the device components, including
a microprocessor and memory. For example, when the device is a
parking meter the device module may comprise the parking meter
mechanism 502 described with reference to FIG. 5, including
operating instructions stored in the memory and executed by the
microprocessor to provide the parking meter functionality. The
device module of a repeater and gateway may only include a
microprocessor and memory. It is understood that the repeaters and
gateways may comprise additional components if it is desirable for
them to perform additional tasks.
[0064] The microcontroller of the radio board 560, or other
components implementing the radio module, may provide, by the
execution of instructions stored in memory, an SPI driver 605. The
SPI driver 605 allows the device to control the radio board, its
microprocessor or its transceiver, by issuing commands that are
implemented by the SPI driver 605. The radio board may be a slave
device to the microcontroller of the device. The SPI driver 605
provides a means for getting command/control and data packets into
and out of the microcontroller of the radio board.
[0065] The microcontroller of the device may provide, by the
execution of instructions stored in memory, a protocol or software
stack to allow the device to perform the required tasks. The
software stack may comprise a device software stack 610 and a radio
control stack 612. The device software stack 610 may be specific to
the type of device, for example a repeater, gateway or parking
meter. The radio control stack 612, which is common to the devices,
may provide basic functionality for controlling the radio board to
the device software stack.
[0066] The radio control stack 612 may comprise an SPI protocol
layer 614 for implementing the synchronous serial protocol (SPI
based) that allows for communications between the microcontroller
of the device and the microcontroller of radio board. This protocol
may also support configuring network and device parameters over the
SPI interface. These parameters may include, for example, RF
channel, Network ID, Device ID, etc.
[0067] The radio control stack 612 may also comprise an RF MAC
Frequency hopper layer 616 for implementing the frequency hopping
MAC layer that upper layers of the radio control stack 612 can
utilize to transport RF messages over the parking meter network.
The RF MAC Frequency hopper provides hopping and synchronizing of
the parking meter network to the hop sequence and timing of the
network.
[0068] The radio control stack 612 may also comprise a synchronizer
layer 618 for providing a timing scheme to keep the various
components of the parking meter network within a tight and
manageable time frame. This allows all devices to synchronize as
quickly as possible, while conserving power. In addition, the
synchronizer layer 618 may implement a method of duty cycling that
puts all devices to sleep in a systematic way to limit the power
consumption.
[0069] The radio control stack 612 may also comprise an RF protocol
layer which includes a high level RF protocol 622 and a low-level
RF driver 620. The high level RF protocol implements parking meter
network functions such as discovering sub-systems, joining
sub-systems, verifying a path to a gateway, finding a path to a
gateway, etc.
[0070] The radio control stack 612 may also comprise an AES
security layer 624 for providing encryption and decryption of
information sent over the parking meter network. This may be used
since the parking meter network may allow credit card payments to
be made at the parking meter, and as such the communication should
be encrypted.
[0071] Components of the device stack have been described with
reference to FIG. 7. Although various components have been
described to provide the functionality of devices of the parking
meter network system, it is understood that the components are one
possible illustrative embodiment. The functionality may be
implemented in devices using more or fewer components that provide
different functionality from the components described in FIG.
7.
[0072] The devices of the parking meter network, namely the
gateways, repeaters and parking meters, may transmit messages that
are formatted in packets. The data field of each packet, depending
on the message type, is divided into message information and
message data. Some messages will not have any message data. All
packets may use sync words to establish the start of packets, a
length byte defining the length of the packet and a 16-bit CRC for
providing error detection/correction. The length of the preamble
sync word, length field and CRC may not be included in the length
field value of the message as their length is constant and known
for a particular message packet.
[0073] Beacon messages will have a preamble of approximately 200
bytes. This length allows any device to scan though all frequencies
to find the channel the transmitting device is on. A non-beacon
message may have a shorter preamble, for example 4 bytes. The
beacon message is a broadcast message sent by the gateway and
repeaters. It allows devices to synchronize to the frequency
hopping and timing of the communication. An LQI value is used by
meters to determine the best route to the gateway.
[0074] The communication protocol used by parking meter system may
use different message types. The message type of a message may be
indicated by a particular field within the message packet.
Illustrative message types may include: [0075] Beacon message sent
from either a gateway or repeater. The beacon message may include
data such as the NIV of the gateway. [0076] Meter Transaction
messages sent from the meter to the gateway when a transaction,
such as a credit card transaction, occurs. [0077] Gateway to Meter
messages sent from the gateway to the meter to deliver information,
for example from a backend system [0078] Meter Transaction
Acceptance messages sent from the gateway to the meter indicating
the acceptance of a transaction, such as the acceptance of a credit
card transaction [0079] Gateway to Repeater messages may be used to
send information from the gateway to a repeater [0080] Gateway
Transaction messages may be sent from a gateway to a backend system
[0081] Meter to Gateway messages may be sent from the meter to the
gateway to send information about the meter to the gateway [0082]
Meter Status Request messages sent from gateways to meters to
request the meter to send its status to the gateway [0083] Repeater
to Gateway messages may be used to send information from the
repeaters to gateways [0084] Meter Status messages may be sent from
the meter to the gateway in response to the meter status request
message [0085] Ping messages may be sent by devices to other
devices in order to test connectivity with the other devices [0086]
Ping Acknowledge messages may be sent from devices in response to a
ping message [0087] Repeater Status Request messages may be sent
from gateways to repeaters to request the status of the repeater
[0088] Repeater Status messages may be sent from the repeaters to
the gateways in response to a repeater status request message
[0089] Repeater messages may be sent from a repeater to either a
gateway or meter and may be forwarding a message received at the
repeater [0090] Join Request messages may be sent from a repeater
to a gateway to request being registered with a gateway [0091] Join
Acceptance messages may be sent from gateways to repeaters once the
repeater has been registered with the gateway. The join acceptance
may include a short system ID assigned to the repeater by the
gateway [0092] Join Denial messages may be sent from gateways to
repeaters indicating that the repeater was not registered with the
gateway [0093] Meter Acknowledgement messages may be sent from a
meter to acknowledge receiving a message sent from a gateway, and
possibly forwarded by a repeater [0094] Gateway Acknowledgement
messages may be sent from a gateway to acknowledge receiving a
message from a meter, and possibly forwarded by a repeater [0095]
Repeater Acknowledgement messages may be sent from a repeater to
acknowledge receiving a message from a gateway [0096] AMA
Acknowledge messages may be sent from a meter to a gateway to
acknowledge receiving the AMA message alert.
[0097] As described above a gateway may broadcast beacon messages
using the RF radio board of the device. A gateway's beacon message
may be used by repeaters and parking meters to synchronize to the
gateway. The parking meters and repeaters may synchronize to both
the communication time, for example the timing window of when to
send messages, as well as the frequency hopping timing, for example
when to hop to the next channel frequency. Once a device is
synchronized with the gateway it may use an internal timer to
maintain close synchronization, reducing the time spent trying to
resynchronize and so reduce power consumption. Each time the device
receives a gateway beacon message, or more particularly receives
the end of the gateway beacon message, an internal timer is reset.
In repeaters the timer is set so that the repeater attempts to
detect the next beacon message at the beginning of the next
frequency hop performed by the gateway. In parking meters, the
timer may be set to a multiple of the frequency hop time. The meter
may go into a sleep mode while waiting for the internal timer to
expire. Once the timer expires the meter may wake up and attempt to
resynchronize with the beacon message. The use of the internal
timer allows the device to go into a low powered sleep mode and
wake up within a limited time shift error of the expected beacon
message. This allows for fast resynchronization and lowers the use
of power.
[0098] If a meter is not within range of a gateway it will
synchronize with a repeater. The meter may follow the same scheme
as if synchronized with a gateway; however, it will synchronize
with the repeater beacon not the gateway beacon. As described
above, repeaters are registered to a single gateway. A repeater
will broadcast a repeater beacon message after the gateway beacon
message. In an illustrative embodiment each repeater registered
with the gateway does not transmit its beacon message after each
gateway beacon. Rather, only one of the repeaters registered with
the gateway broadcasts its beacon after the gateway beacon. The
repeaters registered with a gateway broadcast their beacon messages
in a round robin fashion based on a short system ID assigned to it
by the gateway when registered. Although a repeater does not
broadcast a beacon at each frequency hop, it will resynchronize
with the gateway with every gateway beacon the gateway sends out.
Doing so allows the repeaters to maintain a close synchronization
with the gateway as well as to determine if the gateway is sending
an asynchronous message alert (AMA) notification to a parking meter
as this message will be embedded in the gateway's beacon as
described further herein. Repeaters will forward any AMA
notifications from the gateway to all meters within range.
[0099] The use of the beacon message to synchronize parking meters
with either the gateway or repeater allows the parking meter to
receive messages from the backend system asynchronously with an
acceptably low latency, while maintaining low power consumption.
This may be used advantageously to allow for the display of parking
time purchased via a cell phone or other device. The ability to
communicate asynchronously with parking meters in a low latency and
low power manner may also provide additional or alternative
benefits, which may include, for example, controlling or altering
parking rates of parking meters remotely, requesting information
from parking meters or repeaters as well as other possible
benefits.
[0100] Parking meters do not need to be linked to a single gateway
sub system. They may be able to hop from one sub system to another.
When first synchronizing (initialization synchronization), the
parking meter may determine if it is within range of a gateway by
detecting gateway beacon messages. The parking meter may also try
to detect beacon messages from as many repeaters and gateways as
possible. The ID address, LQI and channel set of these repeaters
and gateways will be stored by the parking meter. The parking meter
may select the best possible route to the gateway once this is
complete. This selection may be based on the LQI determined during
the initialization synchronization. If this link is ever broken the
next best route will be used. This aides in providing a low latency
response at the meter as well as low power consumption.
[0101] Repeaters of the illustrative subsystem depicted in FIG. 2
send a beacon once for every six gateway beacon messages they
receive. This is desirable to prevent beacon messages from
colliding with one another. Repeaters will send beacons based upon
the short system ID Address assigned to them by the gateway when
the repeater registers with the gateway. For example, a repeater
with an assigned short system ID of 1 may transmit a beacon message
following the gateway's beacon message. Following the gateway's
next beacon message the repeater with the short system ID of 1 does
not transmit a beacon message, rather a repeater with a short
system ID of 2 may transmit the beacon message. The gateway may
control which repeater sends the beacon message by including the
short system ID of the repeater that is to transmit the beacon in
the beacon message. All of the repeaters will receive the beacon
message; however, only the repeater with the assigned short system
ID matching that in the beacon message retransmits the beacon
message.
[0102] Gateways, repeaters, and meters may receive a unique 32-bit
address during manufacturing. On each sub system the gateway may
always be assigned a short system address of zero. The repeaters
can be assigned a short system address of 1-6, or the maximum
number of repeaters allowed to be registered with a single gateway,
by the gateway when they initially register with the sub-system.
Once a gateway has allowed six repeaters to register with it all
other repeater requests to join the sub system may be denied.
Gateways and repeaters will not process messages for other
networks. Each subsystem has a unique Network ID that the gateways
and repeaters use for identifying messages for their particular
subsystem. Assigning a short address to the gateway and repeaters
may be done to reduce the number of bytes necessary to
transmit/receive over the radio, which can help save power. Because
meters may be able to hop between subsystems they use their entire
32-bit address in communications.
[0103] In the parking meter network, the source of a message, for
example the gateway or the parking meter, is notified of message
delivery by an acknowledgement message from the message
destination. Repeaters do not acknowledge messages they receive and
forward, they will only forward acknowledgements. If a parking
meter sends a message and it does not receive an acknowledgement
from the gateway, either directly or via a repeater, the parking
meter will resend the message. The scenarios below highlight
different parking meter message transmission possibilities.
[0104] Normal Message Completion [0105] 1. Parking meter sends a
`Meter to Gateway` message to gateway. [0106] 2. gateway sends an
acknowledgement message to parking meter. [0107] 3. Parking meter
receives acknowledgement message.
[0108] Normal Message Completion with Repeater [0109] 1. Parking
meter sends a `Meter to Gateway` message to repeater. [0110] 2.
Repeater receives and forwards the message to the gateway. [0111]
3. Gateway sends an acknowledgement to repeater. [0112] 4. Repeater
receives and forwards the acknowledgement message to parking meter.
[0113] 5. Parking meter receives acknowledgement message.
[0114] Retry Mode 1 [0115] 1. Parking meter sends a `Meter to
Gateway` message to gateway. [0116] 2. Parking meter did not
receive an acknowledgement message. [0117] a. Parking meter did not
receive the acknowledgement message or [0118] b. Gateway did not
receive the message [0119] 3. Parking meter retries sending the
message. [0120] 4. If the 3.sup.rd retry of sending the message
fails then retry mode 2 is used.
[0121] Retry Mode 2--Try Another Route [0122] 1. Parking meter
selects a new route from stored data during initialization
synchronization. If another route does not exist to a sub-system
then retry mode 3 is used. [0123] 2. Parking meter sends a `Meter
to Gateway` message to gateway using newly selected route. [0124]
3. Parking meter did not receive an acknowledgement message. [0125]
a. Parking meter did not receive the acknowledgement message or
[0126] b. Gateway did not receive the message [0127] 4. Parking
meter retries sending the message. [0128] 5. If the 3.sup.rd retry
fails then repeat retry mode 2.
[0129] Retry Mode 3--Find a New Network [0130] 1. Parking meter
goes through the initialization synchronization routine to identify
all possible routes. The routes may have changed since the previous
initialization. [0131] 2. Parking meter messaging routine is
restarted and the message is attempted to be sent again.
[0132] The above message transmission scenarios are for messages
that originate at a parking meter. The use of the beacon message
may be used to provide asynchronous communication between the
back-end system and the parking meter. That is, the back-end system
may send a message to a particular parking meter. The back-end
system sends the message information to a particular gateway, for
example the backend may send the message information to the last
gateway that received a message from the parking meter. The gateway
constructs an Asynchronous Message Alert (AMA) beacon message,
which is a beacon message with the parking meter ID of the parking
meter the backend system is trying to communicate with, as well as
an indication that the beacons message is an AMA beacon message in
it. By embedding the AMA in the beacon all parking meters can be
notified that a message is pending, including the intended parking
meter. Because a parking meter can hop from one system to another,
not directly linked, all Gateways in a particular area may send out
the AMA. For example, the back-end system may determine that there
are three gateways that are in possible communication with the
intended parking meter. The gateways send out the AMA beacon
message; which all repeaters registered with these gateways will
then forward to the parking meters within range.
[0133] Gateways can continue to send the AMA beacon message until
one of the gateways receives an AMA acknowledgement message from
the intended parking meter indicating that the meter has received
the AMA beacon message and is ready to receive the AMA message.
This gateway may then indicate to the back-end system that the AMA
beacon message has been received and no longer needs transmitting
and the actual message may be transmitted. The backend may then
indicate to the other possible gateways that were broadcasting the
AMA beacon message to stop broadcasting the AMA beacon message.
[0134] After receiving the AMA beacon message indicating a gateway
message is waiting for it, a parking meter will send an AMA
acknowledgement message to the gateway to indicate recognition of
the message in waiting. The gateway may then send the AMA message
to the meter. Once the AMA message is received the meter will reply
with an AMA acknowledgement indicating that the message was
received.
[0135] Gateways may include a single meter ID in an AMA beacon
message. As such, if the backend has multiple AMA to send to
different parking meters, the backend queues the AMA messages and
disperses them to the appropriate gateway or gateways. The gateway
then sends an AMA beacon message for the first parking meter in the
queue which will acknowledge the AMA beacon message and receive the
AMA message from the queue. The AMA message is acknowledged by the
parking meter. The backend system will disperse the next AMA
message to the gateway.
[0136] The back end may maintain a database of all parking meters
in the parking meter system along with the gateway and/or repeater
path(s) that have been associated with any traffic to and/or from
those devices.
[0137] The indication that a beacon message is an AMA beacon will
consist of AMA byte (0x01) in an Alert field and 4 destination
address bytes of the parking meter ID of the message packet.
[0138] The system described above for sending a message from the
backend to a specific parking meter may be extended to act as a
broadcast message alert (BMA). By placing a broadcast byte (0x10)
in the Alert field of a beacon message, the parking meter network
can be notified that the beacons sent out contain a system wide
broadcast. The broadcast data is held in the 4 address bytes, since
the message does not require the field to be used for a particular
parking meter's ID. The broadcast message may be time based, for
example it may be sent out for a specified length of time and then
stopped.
[0139] The AMA and BMA messages may be used to provide additional
features to parking meters, such as "congestion parking".
Congestion parking allows the city to dynamically adjust the
pricing paid by parkers in a city based on the traffic patterns,
time of day, in an effort to for example, relieve congestion of
cars on the street, and or increase the revenue stream generated
from the parking meter network. The AMA message may be used to
provide congestion parking to a single parking meter, while the BMA
message may provide congestion parking to all parking meters in the
parking meter system or all parking meters in a specific region or
area of the City; i.e. downtown. The region or area of the city may
be controlled by the sub-system the parking meter is communicating
with. Gateways of sub-systems may broadcast a BMA beacon message,
which will be received by all parking meters in that area. The
backend system may maintain the geographic location of the gateways
of the parking meter system. The backend system may also maintain
the location of individual parking meters. Alternatively, the
region or area of the parking meter may be inferred from the
location of the gateway it is communicating with.
[0140] A complete rate profile describing the parking rates on a
parking meter may be about 2000 bytes. It may not be practical to
send a complete new profile each time it is desired to adjust the
parking rates of the parking meters. Rather than sending a complete
rate profile, a rate multiplier or a rate index number may be sent,
for example in a BMA beacon message, in order to change the rate of
all parking meters in an area or region, or an AMA message in order
to change the rate of a single parking meter.
[0141] Sending a rate multiplier to the parking meter, whether
individually using an AMA message or in a group using a BMA beacon
message, may include sending a 3 digit number representing a
decimal number with two decimal places. This allows the parking
meter rate to both be increased and decreased. With the rate
normally set at 1.00, the range of rate multiplier numbers may be
from 0.00 thru to 9.99. Thus if the rate for a group of meters was
normally $2/hr, sending a multiplier of 1.50 to it will cause its
current effective rate to be $3/hr. So there are 999 possible rate
multiplier numbers to choose from, which provide a large range of
control of the parking rates. It will be appreciated that the
multiplier may have fewer or more digits depending on the desired
granularity of control over the parking meter rates.
[0142] Parking meters may support different rates, although
commonly only one rate is defined in a given rate profile. The
additional rates may be used to define "congestive parking" rates
which escalate in price at some scaling factor. The AMA or BMA
message may send the rate index number to specify which rate, for
example number 1 thru 8, to use.
[0143] How quickly the parking meters are required or desired to
react to congestive parking rate changes may affect the AMA latency
configurations on the meters. The latency settings of the AMA
determines how quickly an individual meter can respond to a remote
command to change its rate or multiplier, or more generally, how
quickly the parking meter can respond or receive an AMA message.
The shorter the latency setting is, the more power that is used by
the parking meter. The AMA latency setting may be determined by the
frequency at which a parking meter makes a resynchronization with
the parking meter network, since the parking meter resynchronizes
with the beacon message which include the AMA indicator indicating
that an AMA message is waiting. This rate may be controlled by the
parking meter network using AMA or BMA messages.
[0144] The communication protocol used by the devices attempts to
mitigate possible collisions. While not all collisions will be
avoidable, a majority may be prevented with a good communication
timing protocol. Like their beacon messages which are scheduled in
a round robin manner to be broadcast after a gateway beacon
message, all repeater communication transmission times may be
scheduled to occur in specific time slots so as to prevent
collisions. This schedule may be based on the repeater's short
Network ID address given to it by the gateway when the repeater
joined the system. Likewise all meters will have a scheduled time
slot in which to transmit messages as well as a time slot to retry
sending messages. These slots may be based upon the unique 32-bit
ID address assigned to the parking meter during manufacturing. A
parking meter's time slot or retry time slot may be based upon its
parking meter ID address. Because each parking meter ID address is
unique the full set of time slots may never overlap completely.
Additionally, or alternatively, to further reduce the possibility
of collisions, all communication devices of the parking meter
system may perform a clear channel assessment (CCA) before
transmitting to ensure the channel is open.
[0145] The synchronizing of the meters and repeaters with the
gateway's beacon message helps to provide a tight synchronization
time frame so that the meters and repeaters may transmit in the
correct time slot and help mitigate the number of possible
collisions.
[0146] FIG. 8 is a flow diagram showing an illustrative method of a
gateway registering a repeater in accordance with the present
disclosure. As descried above, a gateway can limit the number of
repeaters that may communicate with it. The method 700 begins when
the gateway receives a join request message from a repeater (702).
The join request message includes the identifier of the repeater
(repeater ID). The gateway uses the repeater ID from the join
request message to determine if the repeater is already registered
with the gateway (704), for example the repeater ID received in the
join request message matches a repeater ID of a repeater registered
with the gateway. The gateway maintains a list of the repeater IDs
of the repeaters that have been registered with it already. If the
gateway determines that the repeater has already been registered
(Yes at 704), it sends a join acceptance message to the repeater
(706). The join acceptance message includes a short system ID the
gateway assigns to the repeater, which may be for example a number
from 1 to the maximum number of repeaters that can be registered
with a gateway. The short system ID is used by the repeater to
coordinate the communication timing with the gateway. Each repeater
uses the short system ID to determine the time slots it uses for
sending messages including its repeaters beacon message. If the
gateway determines that the repeater has not already been
registered (No at 704), for example the list of registered
repeaters does not contain the repeater's ID, the gateway then
determines if there is a spot for the repeater to register with the
gateway. The gateway determines if there is spot by checking if the
number of registered repeaters is equal to the maximum number of
repeaters that can be registered with the gateway at one time
(708). If there is a spot available for the repeater (No at 708)
the gateway registers the repeater's ID (709), increasing the
number of repeaters that are registered with the gateway (710), and
sends an acceptance message to the repeater (706) including the
short system ID assigned to the repeater by the gateway. If the
gateway has already registered the maximum number of repeaters (Yes
at 708) it sends a join denial message to the repeater indicating
that the repeater was not registered with the gateway (712). Once
the gateway has sent either a join acceptance message or a join
denial message to the repeater the registration process ends. The
gateway may inform the backend system that the repeater has been
registered with it.
[0147] FIG. 9 is a flow diagram showing an illustrative method of a
repeater registering with a gateway in accordance with the present
disclosure. The method 800 begins with the repeater detecting
beacon messages from gateways (802). The repeater may scan through
the different frequencies used by the parking meter network and
determines if a gateway is broadcasting a beacon message on the
frequency. The repeater receives any beacon messages it detects.
The repeater assigns each received beacon message a link quality
index (LQI) value that represents the quality of the communication
channels. Each beacon message sent by a gateway and received by the
repeater includes the gateway's network initialization vector (NIV)
indicating the channel set used by the gateway. The repeater
receives the beacon messages and orders them based on the LQI of
the beacon message. The repeater then sends a join request message
to the gateway with the highest LQI value (804). The gateway
processes the join request message, for example, as described above
with reference to FIG. 8, and sends a response message. The
repeater receives a response message from the gateway (806) and
determines if the response message is either an acceptance message
or a denial message (808). If the response message is an acceptance
message (Yes at 808) the repeater sets the gateway as its
communication point in the parking meter network (810). The
repeater uses the channel set described by the gateway's NIV for
subsequent communications. If the received response message is not
an acceptance message, the repeater sends a join request to the
gateway with the next highest LQI (812) and receives a response
message from the gateway (806), and continues processing the
message as previously described. Although not depicted in the
illustrative method of FIG. 9, if the repeater reaches the end of
the gateway list without being registered, it may start the method
over again, to possibly identify new or additional gateways.
[0148] FIG. 10 is a flow diagram showing an illustrative method of
initializing a parking meter in accordance with the present
disclosure. The method 900 begins with the parking meter
identifying the gateways and repeaters that are within
communication range. The meter detects beacon messages from the
gateways and repeaters (902) and records the network ID, LQI and
NIV of the beacon messages and orders the discovered communication
pathways from the highest LQI to the lowest (904). The parking
meter may detect the beacon messages in a similar manner as
described above for repeaters. The parking meter sets the route
with the highest LQI as the route to use for communicating with the
parking meter network (906).
[0149] The methods described above with reference to FIGS. 8, 9 and
10 may be implemented in various hardware or software combinations.
For example, the methods may be implemented in the device modules
of different devices in the parking meter system. For example, the
method of registering a repeater at a gateway described with
reference to FIG. 8, may be implemented in the device software
stack 610 of the device module of a gateway device, or
alternatively it may be implemented in different components of the
device. Similarly the method used by a repeater to register with a
gateway described with reference to FIG. 9 may be implemented in
the device software stack 610 of the device module of a repeater
device. The parking meter initialization method may be implemented
in the device software stack 610 of the device module of a parking
meter.
[0150] FIG. 11 is a message flow diagram showing illustrative
messages for a parking meter communicating with a backend system
though a gateway in accordance with the present disclosure. The
gateway 205 periodically sends a beacon message (1102) which is
received by parking meters 120. The beacon message is sent each
time the gateway hops to a new frequency. The parking meter
resynchronizes with the beacon message sent from the gateway, or
the repeater if the parking meter is communicating with a repeater.
Once the parking meter resynchronizes with the beacon message, it
can go into a low power sleep mode. In the illustrative scenario of
FIG. 11, the parking meter 120 receives a parking meter event for
example a coin is inserted into the parking meter, which places the
parking meter into a wake up mode and processes the parking meter
event. The processing of the parking meter event may cause the
parking meter to send a message to the gateway. The parking meter
waits for its particular time slot to send the meter message to the
gateway. Once the parking meter's time slot arrives the meter sends
a meter message to the gateway (1104). The gateway receives the
parking meter message and sends an acknowledgement message back to
the parking meter (1106). The parking meter receives the
acknowledgement from the gateway and processes it. Once the
acknowledgement has been processed the parking meter may return to
the low powered sleep mode. Alternatively, the parking meter may
stay awake or in a more active mode awaiting a response to the
message or data that was sent to the gateway, and possibly
processed by the backend. Once the gateway receives the meter
message from the meter, the gateway may send the message on to the
backend system (1108) which may process the information. The
backend system may send a response message to the parking meter
through the gateway. In such a case the parking meter remains in an
awake mode to receive the response message. If the backend has a
message or response destined for a particular parking meter, it can
determine the fastest or lowest latency path by looking at the
received message packet from the parking which will show the IDs of
the gateway and any repeaters used by the parking meter to
communicate with the backend system. This path data may be
maintained and updated in a backend database associated with each
parking meter.
[0151] FIG. 12 is a message flow diagram showing illustrative
messages for a backend system communicating with a parking meter in
accordance with the present disclosure. A backend system may send
asynchronous messages to parking meters. The backend system sends
the message information to a gateway. The message information may
include the unique ID of the parking meter the message is intended
for (1202). The gateway receives the information and creates and
queues an Asynchronous Message Alert (AMA) message. Alternatively
the backend system may create the AMA message and send it to the
gateway and the gateway will queue the AMA message and generate the
AMA beacon message. The AMA beacon message may be a beacon message
with an Alert bit set and including the parking meter's ID the AMA
message is intended for. The gateway sends the AMA beacon and the
parking meter receives the AMA beacon message when it
resynchronizes with the AMA beacon message (1204). If the address
of the AMA beacon message matches that of the parking meter, the
parking meter sends an AMA acknowledgement message (1206)
indicating that the gateway can send the AMA message. Once the AMA
acknowledgement is received by the gateway, the gateway sends the
AMA message (1208) to the parking meter. The parking meter receives
the message and sends an AMA message acknowledgement (1210) to the
gateway indicating that it has received the message information.
The gateway may send a message back to the backend system
indicating that the message has been delivered to the meter.
[0152] FIG. 13 is a message flow diagram showing illustrative
messages for processing a credit card payment at a parking meter in
accordance with the present disclosure. The parking meter
periodically resynchronizes with the beacon message (1302) of the
gateway, or a repeater, as described above. The parking meter wakes
when a credit card event occurs, for example when a credit card is
inserted or swiped at a meter. The parking meter processes the
credit card event, for example by determining the amount of time to
be purchased and encrypting the credit card information for
transmission to the gateway. The parking meter waits for its
transmission time slot and once it occurs, the parking meter sends
a parking meter transaction message (1304), including the credit
card transaction information, to the gateway, and then waits for
the acknowledgement message (1306) from the gateway indicating that
the transaction message has been received by the gateway. Once the
acknowledgement message has been received the parking meter stays
awake or in a more active mode awaiting a response to the credit
card transaction data just sent to the backend system. The gateway
sends the credit card transaction to the backend system (1308). The
backend system receives the credit card transaction information and
processes it, resulting in the transaction being either approved or
denied. Regardless of the results of the processing of the
transaction, the transaction processing response is sent from the
backend system to the gateway (1310). Once received from the
backend the gateway sends the results of the transaction processing
(1312), which in the illustrative example of FIG. 13 is a
transaction approval message to the parking meter. The parking
meter sends an acknowledgement (1314) back to the gateway and
processes the transaction message. This may result in the parking
meter approving the purchase of time, or declining the purchase of
time. Once the parking meter finishes processing the message, it
may return to a low power sleep mode.
[0153] The meter initiated messaging and the AMA messaging may also
be used at parking meters to process credit card transaction. The
AMA method may be desirable to use if the processing of the credit
card transaction by the backend system takes a long period of time.
The AMA technique allows the parking meter to go to sleep until the
transaction processing result is ready from the backend, which can
be indicated to the parking meter using an AMA beacon message.
Although the AMA messaging may be used, it may cause an undesirable
amount of time to pass before the transaction is completed since
the parking meter goes to sleep. To mitigate this, upon going to
sleep while waiting for a transaction response, the parking meter
may modify the resynchronization frequency to resynchronize with
each channel hop, and so detect and receive the AMA message as
quickly as possible using the AMA messaging technique,
[0154] Although the AMA message may be used, it is possible for the
parking meter to remain in the awake state waiting for the
transaction processing result from the backend system, as depicted
in FIG. 13. This type of processing may be desirable to use when
the time required to process the transaction request by the backend
system is low, and the lowest latency time is desirable, since it
can provide the transaction processing response as soon as it is
available from the backend system. The short processing time will
help the parking meter to consume little power
[0155] FIG. 14 is a message flow diagram showing illustrative
messages for processing a parking meter payment received at a
backend system in accordance with the present disclosure. The AMA
beacon message may also be used to provide additional payment
options. For example, payments that originate at the backend system
may be made. These payment options may include for example, paying
using a cell phone, text messaging, or over the Internet or using
an Internet, or other communication network, enabled device. These
payment options are initiated by a person wishing to purchase time
at a particular parking meter. The purchaser contacts the backend
system in some manner (1402), for example using a cell phone and
indicates the meter ID for the parking meter time is being
purchased at. The backend system may then process the payment
request and send the results of the transaction to the parking
meter using an AMA message (1404). The backend system sends the
transaction response to the gateway which sends an AMA beacon
message (1406) for the particular parking meter. Once the parking
meter receives the AMA beacon message when synching with the
gateway, the parking meter sends an AMA acknowledgement to the
gateway (1408). The gateway subsequently sends the transaction
information, depicted as a transaction approval message, to the
parking meter (1412). Depending on if the transaction was approved
or denied the transaction information may indicate the amount of
time purchased and the parking meter may display the amount of time
purchased. The parking meter receives the transaction information
and sends an acknowledgement to the transaction message (1414). The
parking meter may return to a low power sleep state.
* * * * *