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.11 a/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:

Figure 1 is a diagram showing an illustrative parking meter network in accordance with the present disclosure;

Figure 2 is a diagram showing an illustrative sub-system of a parking meter network in accordance with the present disclosure;

Figure 3 depicts in a timing diagram the timing of a device communicating using frequency hopping in accordance with the present disclosure;

Figure 4 is a diagram showing illustrative communication paths of components in a parking meter network in accordance with the present disclosure;

Figure 5 is a diagram showing two illustrative sub-systems of a parking meter network in accordance with the present disclosure;

Figure 6 is a diagram showing illustrative components of a parking meter in accordance with the present disclosure;

Figure 7 is a diagram showing illustrative components of a parking meter in accordance with the present disclosure; Figure 8 is a flow diagram showing an illustrative method of a gateway registering a repeater in accordance with the present disclosure;

Figure 9 is a flow diagram showing an illustrative method of a repeater registering with a gateway in accordance with the present disclosure;

Figure 10 is a flow diagram showing an illustrative method of initializing a parking meter in accordance with the present disclosure;

Figure 11 is a message flow diagram showing illustrative messages for processing an event at a parking meter in accordance with the present disclosure;

Figure 12 is a message flow diagram showing illustrative messages for a backend system communicating with a parking meter in accordance with the present disclosure;

Figure 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

Figure 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

[0012] Figure 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. Figure 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 Figure 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.

[0013] 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 subsystems 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 subsystems 104, 106 are considered to be connected to the back-end system 110 generally through a network 108.

[0014] 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.

[0015] As described further herein, the back-end system 110 may also be used to coordinate 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.

[0016] As shown in Figure 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 subsystems 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.

[0017] 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 subsystems 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.

[0018] 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.

[0019] Figure 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 Figure 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.

[0020] 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 Figure 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).

[0021] The gateway 205 acts as a link between the wireless parking meters 120 and the back end system 110 of Figure 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 Figure 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.

[0022] 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.

[0023] 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.

[0024] 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.

[0025] Figure 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 Figure 3. The dwell time 302, blanking interval 304 and the beacon interval 306 are constant as is illustrated in Figure 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.

[0026] 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.

[0027] 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 gateway205. The NIV may also be received by parking meters in order to determine the channel to use in order to communicate with the gateway.

[0028] 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.

[0029] 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) ] x 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. [0030] 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.

[0031] 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 Figure 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.

[0032] Figure 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. [0033] With reference to Figure 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 Figure 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 Figure 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 Figure 5.

[0034] Figure 5 is a diagram showing two illustrative sub-systems of a parking meter network in accordance with the present disclosure. Figure 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.

[0035] Figure 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.

[0036] 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).

[0037] 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 Figure 6. The RAM 533 may be a fast read-write memory for the temporary storage of variables and the like during software processing.

[0038] 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.

[0039] 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.

[0040] 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 US Patent 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.

[0041] 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.

[0042] 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.

[0043] 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.

[0044] 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.

[0045] 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.

[0046] 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.

[0047] 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.

[0048] 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.4GHz band.

[0049] Figure 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 Figure 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 Figure 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 Figure 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.

[0050] 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.

[0051] 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.

[0052] 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.

[0053] 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.

[0054] 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.

[0055] 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.

[0056] 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.

[0057] Components of the device stack have been described with reference to Figure 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 Figure 7.

[0058] 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.

[0059] 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.

[0060] 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:

- Beacon message sent from either a gateway or repeater. The beacon message may include data such as the NIV of the gateway.

- Meter Transaction messages sent from the meter to the gateway when a transaction, such as a credit card transaction, occurs. - Gateway to Meter messages sent from the gateway to the meter to deliver information, for example from a backend system

- 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

- Gateway to Repeater messages may be used to send information from the gateway to a repeater

- Gateway Transaction messages may be sent from a gateway to a backend system

- Meter to Gateway messages may be sent from the meter to the gateway to send information about the meter to the gateway

- Meter Status Request messages sent from gateways to meters to request the meter to send its status to the gateway

Repeater to Gateway messages may be used to send information from the repeaters to gateways

- Meter Status messages may be sent from the meter to the gateway in response to the meter status request message

Ping messages may be sent by devices to other devices in order to test connectivity with the other devices

Ping Acknowledge messages may be sent from devices in response to a ping message

- Repeater Status Request messages may be sent from gateways to repeaters to request the status of the repeater

- Repeater Status messages may be sent from the repeaters to the gateways in response to a repeater status request message

- Repeater messages may be sent from a repeater to either a gateway or meter and may be forwarding a message received at the repeater

- Join Request messages may be sent from a repeater to a gateway to request being registered with a gateway

- 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

- Join Denial messages may be sent from gateways to repeaters indicating that the repeater was not registered with the gateway Meter Acknowledgement messages may be sent from a meter to acknowledge receiving a message sent from a gateway, and possibly forwarded by a repeater

- Gateway Acknowledgement messages may be sent from a gateway to acknowledge receiving a message from a meter, and possibly forwarded by a repeater

Repeater Acknowledgement messages may be sent from a repeater to acknowledge receiving a message from a gateway

- AMA Acknowledge messages may be sent from a meter to a gateway to acknowledge receiving the AMA message alert.

[0061] 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.

[0062] 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.

[0063] 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.

[0064] 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.

[0065] Repeaters of the illustrative subsystem depicted in Figure 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.

[0066] 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.

[0067] 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.

• Normal Message Completion 1. Parking meter sends a 'Meter to Gateway' message to gateway.

2. gateway sends an acknowledgement message to parking meter.

3. Parking meter receives acknowledgement message.

• Normal Message Completion with Repeater

1. Parking meter sends a 'Meter to Gateway' message to repeater.

2. Repeater receives and forwards the message to the gateway.

3. Gateway sends an acknowledgement to repeater.

4. Repeater receives and forwards the acknowledgement message to parking meter.

5. Parking meter receives acknowledgement message.

• Retry Mode 1

1. Parking meter sends a 'Meter to Gateway' message to gateway.

2. Parking meter did not receive an acknowledgement message. a. Parking meter did not receive the acknowledgement message or b. Gateway did not receive the message

3. Parking meter retries sending the message.

4. If the 3 ^rd retry of sending the message fails then retry mode 2 is used.

• Retry Mode 2 - Try another route

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.

2. Parking meter sends a 'Meter to Gateway' message to gateway using newly selected route.

3. Parking meter did not receive an acknowledgement message . a. Parking meter did not receive the acknowledgement message or b. Gateway did not receive the message

4. Parking meter retries sending the message.

5. If the 3 ^rd retry fails then repeat retry mode 2.

• Retry Mode 3 - Find a new network

1. Parking meter goes through the initialization synchronization routine to identify all possible routes. The routes may have changed since the previous initialization. 2. Parking meter messaging routine is restarted and the message is attempted to be sent again.

[0068] 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.

[0069] 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.

[0070] 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. [0071] 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.

[0072] 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.

[0073] 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.

[0074] 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.

[0075] 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.

[0076] 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.

[0077] 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..

[0078] 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.

[0079] 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.

[0080] 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.

[0081] 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.

[0082] Figure 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.

[0083] Figure 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 Figure 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 Figure 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.

[0084] Figure 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).

[0085] The methods described above with reference to Figures 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 Figure 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 Figure 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.

[0086] Figure 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 Figure 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.

[0087] Figure 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.

[0088] Figure 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 Figure 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.

[0089] 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,

[0090] 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 Figure 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

[0091] Figure 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.