« Feelin' the Flow (NYC Traffic Data, and more) | Main | Urban GPS is Now »

Congestion Pricing, Positioning, and Meshed Wireless Networks

As part of my internship at the Regional Plan Association I was asked to research the applicability of mesh networks to congestion pricing for New York City. What follows is the result of several days of reading, surfing the web, talking on the phone, and stroking my chin. It assumes some knowledge on the topic, most of which can be found in descriptions of London's Congestion Charge, upon which any scheme in New York is likely to be based.

Primary Questions

  • What about London's CC scheme do we not like?
  1. Pricing is not very flexible. No variability of charge over time or space (i.e. path)
  2. For the most part, only charged for crossing the boundary into the zone
  3. Post-payment (i.e. account-based billing) is impossible
  • What would we do the same in a first implementation?
  1. Charge people for driving within a certain area during a certain time period
  2. Use cameras to charge people who opt out of any other system, i.e. cheaters and tourists
  • What would we want to do differently, ?
  1. Charge people with accounts, like EZ Pass
  2. Charge people who do not cross the zone-charging boundary (i.e. remain entirely within the zone)
  • What would it take, from a technologic perspective, to do it as we prefer?
  1. Substantially higher accuracy of detection
  2. Detection within the zone, not just at its edges
  • What technologies and approaches are likely candidates to be considered?
  1. Automatic Number Plate Recognition (ANPR, cameras reading license plates, like london) for enforcement
  2. Dedicated Short Range Communications (DSRC, like EZ Pass) for point detection for account-holders
  3. GPS positioning for area-wide detection
  4. Wireless Positioning System (WPS -- TV/WiFi/GSM) for area-wide detection
  5. Wifi/Mesh Networks for communications
  • What sort of physical footprint or envelope, both in the vehicle and on the streets, would we expect for each different solution?


First, from Transport for London (TfL)'s Technology Trials "it is necessary to keep in mind the distinction between a charging event (where the detection of a vehicle triggers a charge) and an enforcement event (where the detection of a vehicle triggers an enforcement action if payment has not already been made by some other mechanism)... The current CLoCCS uses cameras and ANPR as an enforcement mechanism, rather than as a charging mechanism. In other words, the user of the system pays in some way and the detection of vehicles through the camera system is used only to enforce if a payment has not been made." The primary reason for this situation is the fact that the ANPR is only about 80% accurate. People are expected to pay their charge, which most of them (90%?) do because with very high penalty charges, the expected cost of not paying is much higher than the cost of paying. And under these circumstances, it is feasible to check every enforcement event manually.

Thus, within the context of thinking about a congestion charging scheme for NYC that is not radically different from London's, the primary reasons for looking at new technology are to lower cost and to raise detection rates so as to be able to move from enforcement to charging -- to make the system easier for users. Another important issue is whether we can implement an area-wide charge that does not depend on detection at the edges of the congestion charging zone. As the primary point of this document is to report on the applicability of "Mesh Networks," these issues will be addressed within discussions of various technologies, rather than the other way around.

Before moving on, there is another key distinction to develop. That is, the difference between ''positioning'' and ''communicating'' and ''billing''. Positioning is the process of detecting a vehicle in a specific location at a specific time. Communicating is the process of relaying the positioning information so that charging and/or enforcement can occur. Billing is the process of making use of that information to incur a fincancial transaction. In the ANPR and DSRC schemes described in TfL literature, the first two of these processes are conflated because the position sensing equipment (i.e. cameras and RFID beacons) are part of the networked (i.e. communications) infrastructure installed by the charging authority. However, for other approaches in which the vehicle senses its own position, they are quite distinct.



ANPR, with its relatively low detection rate, is only suitable for enforcement. Note, however, that it is the only technology considered that does not require some sort user opt-in process, and therefor is at all applicable for enforcement. DSRC, as demonstrated with our EZ-Pass system, is suitable for charging. In both cases, positioning and communication are part and parcel.

London seems reasonably convinced that the combination of cameras and RFID sensors is sufficient for supporting both enforcement and automatic charging events along the boundary of a congestion charging zone. How applicable they are to an area-wide charging scheme is up to debate, and is entirely a function of the installation density required to support a desired detection rate ("the relationship between any increase in cameras and the resultant increase in overall detection rates is unknown") which TfL appears to set at over 99% for charging.


GPS is good for positioning, and getting better all the time. As shown in TfL's stage 1 trials, the problems with current GPS implementations, particularly in 'urban canyons,' necessitate unsuitably large buffer zones, on average 60 meters (up to 250M), to guarantee 99% accuracy (i.e. that the car was in fact inside the zone). It is getting better all the time, with a steady evolution of the intelligence of GPS chips and with the forthcoming launch of the European Galileo satellites.

Satellite-based positioning is entirely useless for communicating. Any solution that uses GPS/Galileo to sense position will require other infrastructure to connect with a system for calculating charges. Noting the fact that major GPS providers plan to release chips with integrated WiFi functionality, herein could lie the value of Mesh Networks.

[Update: Urban GPS is better than we think]

Wireless Positioning System (WPS)

There currently exist numerous positioning technologies, in different stages of development and deployment, that depend only on terrestrially installed and detected radio signals. The types of radio signals include TV, WiFi, and GSM (cellular), but the gist is always the same -- triangulation from a number of radio beacons of known location. The primary advantage over GPS is that there are a lot of places terrestrial radio can reach that satellite signals can't (inside, between big buildings, etc). Their accuracy is generally competitive with GPS when a sufficient number of beacons are visible, which is entirely feasible to ensure within a limited area such as a Manhattan. They could possibly be used for charging at a reasonable confidence level of accuracy without the oversized buffer zones TfL has described.

Each radio type has its own pros and cons and none really seem to be in widespread use, least of all for any current road-pricing schemes. What I find particularly compelling is that, to a degree, each of these approaches piggyback on preexisting infrastructure. For example, Skyhook Wireless maintains databases of known WiFi access points for different cities which are then used by mobile devices to calculate their position in the field, regardless of who owns/operates the access points. That is, Skyhook can be used to position off of WiFi nodes in populated places without installing any new infrastructure. And they just announced a deal with one of the bigger/better GPS chip manufacturers.

Because of that piggybacking, none of these positioning implementations also provide for the communication, necessary to calculate road charges based on positions (even if the calculation is as simple as a single daily charge for driving inside a certain single area).

Mesh Networks

"Mesh Networks" seems to have several meanings and offer different possibilities depending who you ask. Skipping for this discussion the Wireless Ad Hoc Network, we consider the possibility of affordably blanketing a large area with sufficient wireless connectivity to meet the needs of a road charging system. While one can already use a cell phone to connect to the internet from anywhere in Manhattan, even in a moving vehicle, using 'cellular' is not a reasonable prospect because of the high cost of equipment and radio spectrum. As such, the question turns to the much lower priced 802.11 WiFi and WiMax technologies.

What seems clear is that while there is much hope, no one is exactly clear on what it would take to enable a large number of moving vehicles to reliably connect to a network using a mesh of installed WiFi (or related) access points. One issue is the amount of area that a single node can cover. Another is the seamless transition from one node to the next for a vehicle in motion. TfL documents a small but inconclusive test in their Stage 2 trials. However, there are many believers who think that large scale WiFi networks offer very compelling options for many things, congestion charging just one among them. The argument would be that if one were thinking about installing a large scale mesh of wireless nodes for congestion pricing, why not make it a larger effort to simply provide free and ubiquitous internet access to everyone (and car) within the same area?

Physical Footprints

Inside the vehicles, the so-called On Board Units (OBU):

  • ANPR: none.
  • DSRC: essentially, the same as EZ Pass
  • GPS: assuming no value added services (i.e. mapping, traffic reports), substantially smaller than current 3rd party GPS navigation units, though still requiring a connection for power.
  • Mesh/WPS: cards/chips/antennas, requiring power, can be even smaller than the current EZ Pass tag. The extra processors and memory necessary to store location data and participate in calculating charges would increase the size but not substantially.

On the street:

  • ANPR/DSRC: same as London. Poles/gantries/etc. Not something you want on every corner.
  • GPS: it's in space, not on the street.
  • Mesh/WPS: WiFi antennas are smaller than a breadbox and could be mounted on street and traffic lights. The access points currently used for WPS systems are inside homes, stores, and offices.


I believe the following to be the two most likely implementations:

  • DSRC (for charging) + ANPR (for enforcement): at a boundary, with scattered, non-thorough, internal positions. This allows for a charging scheme different from London's mostly in that one may pay through an account similar to EZ Pass
  • GPS/WPS + Mesh: The syngergy is apparent. One can use WiFi both for positioning (off your own and other peoples' access points) and for communicating. This allows for more flexible charging schemes, initially non-boundary-dependent area pricing, but does not at all address enforcement.

Some questions and confusions on enforcement:

  • If a Mesh/WPS solution were chosen, how would enforcement work? ANPR cameras are still necessary.
    • Could possibly happen in a more distributed way, similar to current traffic enforcement techniques. For example, TfL's ANPR-equipped roving 'Locust Van.' What does it take to get enough enforcement this way?
    • Otherwise, if cameras were to be mounted at the boundary of the charged area, much of the benefit of using WiFi seems lost.

Neglected in this Discussion

  • Costs
  • Privacy Implications/Possibilities (though I did run across a paper describing how some pretty magical cryptographic techniques could smooth the way here)


(holy snap, I read all this?)


This page contains a single entry from the blog posted on February 28, 2007 4:46 PM.

The previous post in this blog was Feelin' the Flow (NYC Traffic Data, and more).

The next post in this blog is Urban GPS is Now.

Many more can be found on the main index page or by looking through the archives.

Creative Commons License
This weblog is licensed under a Creative Commons License.