Metro Vancouver Transit Discussion

[GeeCee]

Metro Vancouver and TransLink should get together and start a wifi project - put an access point at every single bus stop. Use that for the bus Compass readers which would have a much lower latency than cellular. Surely this is a reasonable fix and will not cost an absurd amount of money to set up.

[WarrenC12]

Originally Posted by Spork

I think the issue with going all in right now and figuring out the tap out later down the line is due to the very size of our bus network. Sure, they could just say $1.50pp for the bus and $2 + $0.20/station for train, but how fair would it be for a 1.5 hour bus ride from White Rock to cost $1.50 when a 15 minute ride from Davie+Denman to Robson Square costs the same? While the current fare zones aren't entirely fair, they at least have some resemblance of an effort towards "fairness". Further, I don't know how much or how accurate Translink's data is, but I could see them going all-in with a temporary change like this and royally screwing it up, and magically falling $300m short of revenue expectations due to poor research and planning.

1) Encouraging more bus riding from the burbs is probably worth it.

2) Translink can modify the routes as needed. The bus drops you at a Canada Line Station. Maybe you get 50 cents off your train ride from your recent bus trip.

Bottom line is, some creative thinking combined with plugging data into some financial models can come up with a reasonable solution, rather than years and millions into a technological fix.

[aberdeen5698]

Originally Posted by Meraki

Cubic either did or should have told them tap-out over cellular isn't achievable with today's technology.

In my entire professional career in IT I have never seen a vendor bidding on a competitive contract admit that something the client wants is not achievable.

Originally Posted by GeeCee

Metro Vancouver and TransLink should get together and start a wifi project - put an access point at every single bus stop. ... Surely this is a reasonable fix and will not cost an absurd amount of money to set up.

Really? You think it would be cheap to run power and data connectivity to every bus stop in Greater Vancouver? And to maintain it all once built?

[WBC]

Originally Posted by aberdeen5698

In my entire professional career in IT I have never seen a vendor bidding on a competitive contract admit that something the client wants is not achievable.

Really? You think it would be cheap to run power and data connectivity to every bus stop in Greater Vancouver? And to maintain it all once built?

Knowing how these things go I would venture a guess that Translink RFP said something like: "and vendor shall provide tap-on tap-off system" without ever specifying what that means or the performance requirements. Then Vendors put on a dog and pony show and sales people overrode technical people and said "surely our system can do it, I mean how hard can it be"...and here we are...

[dpogue]

Originally Posted by WBC

Knowing how these things go I would venture a guess that Translink RFP said something like: "and vendor shall provide tap-on tap-off system" without ever specifying what that means or the performance requirements. Then Vendors put on a dog and pony show and sales people overrode technical people and said "surely our system can do it, I mean how hard can it be"...and here we are...

Given the fairly specific number of "target of 0.3 seconds", I'd suspect that was defined somewhere in the RFP.

Although that doesn't subtract any from your point. In IT it always seems to be sales going "Oh yeah, we can do that! It sounds easy!", followed by the technical people going "How do we overcome this technical impossibility that we've been promised to do?".

Reminds me of this:

http://xkcd.com/1425/

[jsbertram]

Originally Posted by GeeCee

Metro Vancouver and TransLink should get together and start a wifi project - put an access point at every single bus stop. Use that for the bus Compass readers which would have a much lower latency than cellular. Surely this is a reasonable fix and will not cost an absurd amount of money to set up.

There was supposed to be free WiFi on Main St a few years ago as part of their fancy bus-arrival times signage for the Main St bus.

No need now that rogers /shaw /telus have sorta-free WiFi all over the city.


When Wifi was the 'new & trendy tech' but nobody knew to lock down their AP, it was possible to 'WiFi hop' all along Broadway from Blanca to Commercial. Service was spotty in areas, but still handy to be reading email &tc on the laptop on the bus to/from school.

[aberdeen5698]

Originally Posted by jsbertram

When Wifi was the 'new & trendy tech' but nobody knew to lock down their AP, it was possible to 'WiFi hop' all along Broadway from Blanca to Commercial. Service was spotty in areas, but still handy to be reading email &tc on the laptop on the bus to/from school.

Unlike cellular radio, WiFi is not designed to seamlessly "hand off" from one access point to another. A WiFi hotspot is also not very large. That means it's impractical to use while in motion. You may be able to do something for the short period of time your bus is stopped to pick up passengers, but having to reconnect to different spots along a route would get old pretty fast, I suspect.

[Meraki]

Originally Posted by aberdeen5698

Unlike cellular radio, WiFi is not designed to seamlessly "hand off" from one access point to another. A WiFi hotspot is also not very large. That means it's impractical to use while in motion. You may be able to do something for the short period of time your bus is stopped to pick up passengers, but having to reconnect to different spots along a route would get old pretty fast, I suspect.

Enterprise gear from Motorola, Cisco etc. have been capable of hand offs for a while. The limitation would be vehicle speeds. Works fine at a walking pace, not too sure about 50 km/h.

[aberdeen5698]

Originally Posted by Meraki

Enterprise gear from Motorola, Cisco etc. have been capable of hand offs for a while. The limitation would be vehicle speeds. Works fine at a walking pace, not too sure about 50 km/h.

Sure, but it can only "hand off" if an access point exists. The celluar network is designed and (usually) built to provide full coverage, especially in urban areas - but WiFi access points are ad hoc and very spotty. Putting an access point at each bus stop, even if economically viable, wouldn't change this because the access points are nowhere near large enough to provide coverage between stops.

[Kisai]

Originally Posted by Meraki

Enterprise gear from Motorola, Cisco etc. have been capable of hand offs for a while. The limitation would be vehicle speeds. Works fine at a walking pace, not too sure about 50 km/h.

Wifi is good for about 1km line of sight. The current version of Seltrac also uses Wifi. But the tap off for the skytrain doesn't appear to be the problem. The bus is.

And for a bus-network-wide rollout of wifi would cost an insane amount of money. May as well propose translink become responsible for a metro-wide fibre network For back haul.

Anyway the problem appears to be latency, and that is likely owing to the radios used. Think about it, LTE to GPRS fallback goes from like 20ms(Telus) to several seconds (Rogers, Bell, Wind, etc with backhaul having to go through central Canada becofore coming back) depending on various conditions. Cubic can't possibly guarantee anything less than 0.3s if the connection isn't LTE. There is already 200ms if it uses HSPA and more if it has to fallback to EDGE.

[aberdeen5698]

Originally Posted by Kisai

Wifi is good for about 1km line of sight.

Not for standard WiFi technologies. To get the kind of ranges you're talking about you need to look at special-purpose solutions such as directional antennas, which are problematic for mobile applications.

[red-paladin]

Unfortunately, if anyone knew about plans to bring wifi to Translink vehicles / properties, they wouldn't be able to talk about them.

[GeeCee]

That is quite unfortunate.

[Kisai]

Originally Posted by aberdeen5698

Not for standard WiFi technologies. To get the kind of ranges you're talking about you need to look at special-purpose solutions such as directional antennas, which are problematic for mobile applications.

That's why I said "line of sight" , which a certain ISP used as backhaul before cable internet was available in the Kootenays. It was also incredibly unreliable due to wind and weather.


Stand outside any tower on a clear day in Metro Vancouver with a laptop and you can likely pick up every AP within 250 meters, and see plenty of ghost AP's that are more than 250m away. Every BSSID would have to be stored on every device, and there are also jamming concerns. This is basically the point I was trying to make. Unlicensed radio is not going to be reliable, ever. Translink options are to pay Telus/Rogers/Bell who have LTE networks. Or to pay through the nose for LEO/MEO satellite modems and service which would be impractical.

Amtrack Cascades no longer offers WiFi on the Canadian side of the border, it was quite unreliable as well, but the U.S. side is no better. If a slow train can't do a low latency connection over cellular, good luck getting buses to.

[MIPS]

For the trolley buses at least they could look into some low bandwidth data solution that operates over the existing overhead power lines.

[deasine]

Originally Posted by MIPS

For the trolley buses at least they could look into some low bandwidth data solution that operates over the existing overhead power lines.

You won't introduce specific technologies for one specific type of fleet unless there was a compelling reason to do so. Thus simply introduces higher complexity and higher costs.

[Spork]

Originally Posted by WBC

Knowing how these things go I would venture a guess that Translink RFP said something like: "and vendor shall provide tap-on tap-off system" without ever specifying what that means or the performance requirements. Then Vendors put on a dog and pony show and sales people overrode technical people and said "surely our system can do it, I mean how hard can it be"...and here we are...

This.

And no, this is not new technology that hasn't been done before. Plenty of existing systems have tap on tap off on bus networks. Here are a couple:

• Opal (Sydney) <- Cubic
• Presto (Toronto-ish)
• UTA (Salt Lake City)

This is either because:

• Rogers' network (are they running on HSPA rather than LTE?) was a bad choice
• The hardware selected was a bad choice (HSPA only rather than LTE?)
• This is some new version of the card and/or readers and/or protocol that the vendor didn't have ready for prime time

It's too bad that we don't know what exactly the problem is and what they are doing to supposedly fix it, as that would alleviate a lot of the frustration, I'm sure.

[bardak]

Originally Posted by Spork

[*]The hardware selected was a bad choice (HSPA only rather than LTE?)[/LIST]

Thats has to be the source of the problem. The original RFP was done before LTE was widespread and embedded systems like the compass readers are not know for using bleeding edge technologies. I wonder if it would be worth the money to just replace the all the bus readers with ones that support LTE.

[quobobo]

It wouldn't be trivial to implement, but one obvious way around the latency of cell networks would be to keep a local cache of card balances on each bus and update it with deltas over the cell network. The amount of data is small enough that it would be manageable even with significantly more riders.

It's technically possible, but it would require a lot more development work than the simple "check the balance on a centralized remote server" approach they seem to have taken.

[aberdeen5698]

Originally Posted by quobobo

It wouldn't be trivial to implement, but one obvious way around the latency of cell networks would be to keep a local cache of card balances on each bus and update it with deltas over the cell network.

It's a little tricky because the card actually stores the value, not the central server. So the balance on the card has to be updated before the customer leaves the bus.

You'd think that they could come up with a scheme where the server could store a debit or credit that would be applied to the card the next time it's tapped (on or off), but that would probably complicate the back-end systems quite considerably and make the presentation of billing information to the customer a lot more convoluted. One would have to account for a lot of potential permutations involving timeouts during multiple tap/on/off events coupled with special cases such as the card running out of value before it can be updated, etc. I have no doubt that it would be challenging to specify, explain to the public, and defend.