When presidents address their nations, they usually do this via television and radio broadcast. They do not call millions of citizens, one by one. “Hello Mr. Smith, this is the President. Would you like to hear my State of the Union address?”, and later “Hello Ms. Lee, this is the President…”.
Presidents do not do this because the message is the same for every recipient. But why transit fare payment hosts send the same data to validators on transit vehicles in the way that resembles the President’s call to Ms. Lee?
In systems with hundreds buses data broadcast may be cheaper, more reliable and more efficient than regular cellular wireless or Wi-Fi one-to-one sessions.
Here is the data that can be broadcast to validators in one-to-many sessions (forget about costly Wi-Fi hubs and idling buses in depots while downloading files):
- Transit system topology data such as stops, transit line configurations, transfer points, routes, and timetables
- Fare tariffs, discount parameters, loyalty policy parameters, etc.
- Validator software such as executable codes, voice messages, and display screens graphics
- Negative card lists which classic open loop systems and closed loop systems use
- Action and download lists which closed loop systems use
- And, of course, fresh up-to-date ridership and payment data which OpenFare uses
Data Broadcast Types
When we are talking on the phone or streaming YouTube or Netflix we are receiving data that is intended to us specifically. We can ask a person who talks to us on the phone to stop, or we can make a pause or replay a movie. It is convenient, to receive information in this way at the time we want, and with the pace we want but it is more expensive because the signal is received in a one-to-one communication session. 30 min of HDTV movie can exhaust our monthly wireless data plan.
Broadcast means that the sender sends the signal only once, and many receivers listen for the signal, all at the same time, with the same pace. The cost of data broadcast is lesser because recipients share the telecom resource. Two or eight thousand validators installed on your buses and streetcars could share the same broadcast channel.
Data broadcasting technologies are known for decades but not all of them are good for our purposes. Let us take a look at the technologies we can use:
Satellite High Definition Television (HDTV) broadcast is more than enough for our goals. Renting one HDTV satellite channel for updating this data could cater for data broadcasting purposes of dozens transit agencies. The cost of this channel is less than the cost of Internet-based Wi-Fi depot infrastructure.
The issue with the HDTV-like satellite-based solution would be a cost of receiving equipment. Basically, you would have to equip each of your vehicles with a receiving satellite antenna plate. In some cases this can be reasonable. Some transit agencies do this anyway, for example, to provide their patrons with on-board Wi-Fi.
City TV Tower
Surprisingly, despite all cable services we have these days. many old TV towers are still functional and transmit several HDTV channels. The cost of receiving equipment is relatively low. As to the broadcast cost, most likely, it is the city who pays for it.
Digital Satellite Radio
An example of digital satellite radio could be XM Radio, well known in North America. Many North American cars have built-in XM Radio sets. XM Radio broadcasts hundreds radio channels using digital data technology. Less than dozen channels can cover the needs of one transit agency.
This is an emerging technology designed to address the needs of cellular phone owners wishing to watch movies on the cellular devices in the places without Wi-Fi. Cellular data broadcast is underused but known technology. You can read more here.
OpenFare and Broadcast
As you can see, when you have many buses or streetcars in the system, data broadcast becomes reasonable for closed loop and classic open loop systems. Data broadcast becomes unavoidable for large transit systems participating in OpenFare. Let us see some examples for rush hour bandwidth:
|Transit System Scale||Small *)||Medium **)||Large ***)|
|Number of patrons (mill.)||0.17||1.8||21|
|Average number of taps/sec in peak period||42||540||8,800|
|Validator Storage (Mbytes)||22||230||2,700|
|Peak data broadcast bandwidth (Mbit/sec)||0.04||0.66||13|
|Bandwidth measured in XM radio channels||2.6||42||N/A|
|Bandwidth measured in HDTV channels||Close to 0||0.04||0.80|
*) e.g. Calgary, Canada
**) e.g. TTC, Toronto, Canada
***) Transport for London, UK
The numbers provided above are estimated under the assumptions that all fares are paid by open loop cards (no closed loop, monthly passes, or cash).
It is estimated that the cost of data broadcast will be still less than projected cost of classic wireless or Wi-Fi data traffic required to support a classic open loop on buses under the same conditions.