Network handover in Google Fi | Hacker News Reader

Network handover in Google Fi

nicholasarmstrong.com

107 pointsndrarmst51 comments

"but that doesn’t change the fact that Google has produced a service that works, is easy to use, switches quickly between networks,"

I've had what can only be described as a hellish experience with Google's Fi service since I got it. My bugs include but are not limited to:

- SIM cards randomly not being associate with both networks, the fix for which is clearing the Fi app data, restarting the phone, and then re-running the app. With wifi, which is tricky when your car breaks down on highway 1.

- Interment and VERY poor data performance, but no interruption in voice service.

- Data service working fine, but all incoming and outgoing calls failing.

In the support category, Project Fi has also been a nightmare. None of the support staff know what to do when you encounter a problem. They don't know why my account (or my friend's account) are broken. They've suggested (just to me) and had me do the following things:

- Reboot the phone.

- Reseat the sim card while the phone is on.

- Factory reset the phone

- Factory reset the phone again without the sim card in.

- Buy a new SIM card. They gave me free shipping, at least?

- Flash the phone to a version of Shamu that is not compatible with other carriers.

- Remove all other user accounts from the phone.

I've been repeatedly asking to cancel my service and get my number ported back to google voice, and I've actually had service reps ignore me claiming they want to explain "[their] side of the story." I have a chat transcript explaining that.

And of course, let's not forget the weird callback system bugs. Like last night 4 hours after I scheduled a call they called me 2 times at 1am, and when I asked them not to call me I was told, "If you don't want us calling then don't schedule a service call!" When I said I didn't, they said, "Well that's odd because I see it right here" then hung up on me.

I still have not successfully cancelled my Fi service. The web form version 500s.

I do not think it is very easy to use, or ready. It seems pretty terrible to me.

This does not match my experience. I've had Fi for a few months now and I have 0 complaints. I'm in NYC and switched from AT&T, but even when visiting New Hampshire I haven't been affected by dropped calls or bad service.

Did you have a pre-existing device, or did you buy a new one.

Most people I've talked to with pre-existing devices have had varying degrees of problems.

Yea I bought a Nexus 6 when I signed up. I thought that was the only supported device though.

edit: I also had no previous Google Voice account to transfer FWIW

I have no doubts that if you greenfield it, Google has that flow tested.

Many of us had pre-existing 6's and I think most people with troubles are there. Be thankful you haven't had to interact with support. Individually they're all nice and want to help, but collectively they have no agency and minimal education.

I switched to Fi and had a pre-existing N^ from Sprint. It has been rock solid except for the delays that were mentioned in the article.

I had a similar experience, getting my GV back was a nightmare.

I am happy so far.

Works great for me, I got the N6 with the service.

I've been saying google declares victory at 80/20 for years now, and haven't fought with them for about 6 months. I wait until they fix it, or someone writes an Xposed app, or I just don't take the update. I'm still on KK4.4. After seeing many of my 'feedback' suggestions get implemented within 2 weeks/the next update, I don't do testing for them anymore. They can pay me to be a Consistency Czar, otherwise my efforts are better spent raising children and in relationships with people.

I haven't had any issues, it works really well for me. I got a new device and didn't switch an existing device.

When Fi was announced they mentioned that public wifi traffic would go through a VPN to google's datacenters. At the time I assumed that they'd just run ALL traffic through the VPN, since that'd make for some very seamless switching. As bad as that would be from a privacy perspective, I trust Google more than T-Mobile or Sprint.

By running everything through the VPN, you'd be able to have TCP connections that didn't break when the network switched, since your device's public IP address would be in a datacenter somewhere.

Also with a VPN you'd be able to send voice traffic over both a carrier connection and the wifi connection at the same time to avoid dropouts.

There is something similar called Multi-path TCP (MPTCP) which uses latency to decide which TCP path to send traffic over.

Precisely - that stable IP between networks is what you need to have completely seamless switches.

This is what Touch Mobile (www.touch.com) does for their handover, for instance.

> Also with a VPN you'd be able to send voice traffic over both a carrier connection and the wifi connection at the same time to avoid dropouts.

Does this double the bandwidth you're using when MPTCP is in effect?

It would obviously send the data out twice; but once would be over the cell network and the other time over WiFi. Doing so would also help with the far more common Cell<>WiFi transition cases. However as the phone still only has once Cell radio set it would not help with transition between communication bands or carriers.

Since the accounting that actually matters (to Google) is at the data center and based on the way that peering agreements work, I suspect Google would actually find /incoming/ data to be either unimportant or even a benefit to their overall cost operations based on bringing their usage closer to equal. The consumer would only normally care about the cell min used; unless their local ISPs have zero competition (see 90%+ of America).

It should be noted that the VPN only turns on when it automatically connects to pre-approved APs. Google didn't disclose to me what those APs are.

It's not pre-approved APs as far as I'm aware, it's any public AP that has no password or landing page, and isn't manually set by you. If you have wifi assistant enabled, it will automatically try to connect to anything that's open from what I've seen.

That's not what Google Fi support told me:

> Thank you for contacting Project Fi Support! My name is Sydney and I will be glad to assist with your issue regarding WiFi services today. First, your phone should connect automatically to open WiFi networks. They have to be Google verified networks to automatically connect. Here is an article regarding our feature known as WiFi assistant and how it works.

And I did try connecting to an open wifi - no VPN automatically activated (but that isn't the only thing that doesn't work...).

The assistant has to make the connection, not the user. I've seen it work against quite a few different APs including some obscure ones, so I'm not sure there's a list or not. The online docs suggest that it does some performance testing before connecting.

By Google "verified", they seem to mean that the phone runs some tests on the network before actually connecting to the VPN, and disconnecting completely if the Wifi isn't up to par. It would be nice for them to confirm exactly how it works, though.

The VPN only works with access points that the phone automatically connects to through wifi assistant (this excludes any you have manually selected at any point in time). The VPN only works when the phone itself finds a hotspot that you have never selected and decides to connect.

"from a privacy perspective, I trust Google more than T-Mobile or Sprint"

From a privacy perspective, I would not trust an advertising company (Google) more than a telecom. Google is perhaps better about disclosure to a Government entity, but they would be worse about exploiting your data for their own ends.

Seems many here do trust Google with their personal data. So, I suppose that implies they are not only a marketing company, but a good one :)

"Given that two different profiles exist on the Fi SIM, the Fi software must have the capability to switch between them. SIM cards are actually little computers, so by developing an application that runs on the SIM card Google could trigger a switch based on any of the information the SIM has access to – the network it is registered on, the receipt of a trigger SMS, or something else.

My guess is that the SIM card contains a small application that can activate a specific profile in response to a command from the Fi software. This profile then remains active until another such command is received. Logically, this makes sense – the algorithms Google will want to use as part of the system are much easier coded as part of an app that can be updated through the Play Store and access any number of data sources; once it decides, it simply instructs the SIM to activate the desired profile."

More likely is that the SIM card just holds a few different profiles and custom software that runs on the baseband processor watches the strength of both networks and sends out of band messages back home to tell recycled Google Voice infrastructure how to find the subscriber. The switchover times you report are consistent with Google's VoIP infrastructure holding a call and silently dialing/connecting it on the other network.

It would be interesting to see if voice handoffs still worked if IP networking was unavailable on the phone.

The counterargument to an all-software solution is that if you switch the profile on the Fi phone, it also remains switched if you move the SIM to another device. So however selection was made, it is 'sticky' across devices.

That's why I guessed it was a paired SIM app + intelligent Android app - but I couldn't verify that, so you could be correct.

Usually radio stuff happens on a dedicated processor which has limited communication with the application processor that runs Linux/Android/Java/Userland. (think like a modem, in some cases they are literally controlled with serial links and AT like text commands).

https://en.wikipedia.org/wiki/Baseband_processor

I believe that profile swaps would be sticky, but actual processing on the SIM is going to be extremely limited and active management of the radios most likely will take place in baseband firmware.

Android talks its baseband processors by interfacing with a daemon called rild (Radio Interface Layer (Library?) daemon) which loads a binary blob library which actually does the talking to the baseband chip.

> My guess is that the SIM card contains a small application that can activate a specific profile in response to a command from the Fi software.

Standard smartcards (including SIMs) have a select command[0], which is used to select applications. If there are two USIM apps[1] (what normal LTE SIMs have one of), they can both be listed in the directory file, and the phone can select either based on whatever it likes. I'm not sure what a plain phone would do with a dual-USIM card (search the app directory for a USIM app and use the first or last? Ask the user? Choose based on the network ID as encoded in the IMSI? Other??)

[0] The relevant 3GPP UMTS/LTE spec, http://www.3gpp.org/DynaReport/31101.htm , defers to an older ETSI spec, http://www.etsi.org/deliver/etsi_ts/102200_102299/102221/08.... for the actual command definitions.

[1] The USIM app, defined in http://www.3gpp.org/DynaReport/31102.htm , contains information like the IMSI (readable), perhaps the phone number (r/w), and the secret shared with the network (inaccessible, but the "authenticate" command can use it to generate a set of session keys that are accessible to the phone).

> More likely is that the SIM card just holds a few different profiles and custom software that runs on the baseband processor watches the strength of both networks and sends out of band messages back home to tell recycled Google Voice infrastructure how to find the subscriber.

Or Google provides a P-GW (as shown in https://en.wikipedia.org/wiki/System_Architecture_Evolution#... ) that both networks use; then the mobile could keep one IP address and the voice services wouldn't have to track anything. The SWn interface shown on that diagram is basically a VPN.

Very interesting. This contradicts how Google advertises the service though. They say the transition is seamless. Unless they are playing fast and loose with the definition of seamless, this does not seem to qualify.

According to their website it is expecting signals to slowly get worse and have time to start transitioning before it drops out. A sudden loss of wifi for whatever reason probably confuses it. I would expect walking down the street away from your wifi would cause a smoother tansition.

I also expect those dialer codes are not meant for use during a call, and that is why a transition is queued up.

Have you tried driving from a Sprint deadzone, where you are on TMobile, to a TMobile deadzone where you would have to transition to Sprint? This would show if it can actually transition between the two during a call. Which others seem to say works.

Driving between dead zones of opposite carriers is surprisingly difficult to do - would have been a great test, though!

I did test walking down the street away from Wi-Fi - the transition is much smoother, but I was only able to get it down to about 2 seconds or so. And that was when I turned around and ran back toward Wi-Fi when it started to switch, so that the call remained good on Wi-Fi until it actually cut over.

Yeah, finding the right dead zones would be pretty hard. Especially if you are somewhere with relatively good signal. Would be a very interested in the results.

Disappointed with that 2 seconds though. I was really hoping for smoother. Though I guess that is why they are still invite only. They are still working on the technology. I was leaning towards getting Fi when the new Nexus comes out, but this makes me think it might not be ready yet.

Thanks for all the info.

His premise that switching isn't seamless is based on his use of manual switching codes (something that Google advises against).

https://republicwireless.com provides seamless wifi->cell and cell->wifi handover of calls.

I can verify. "Seamless" in this case means "I often don't even notice". If I'm directly watching I can sometimes see it and correlate it to a small dropout but it's nothing that doesn't happen all the time on cell phones anyhow; it's below the noise threshold.

Can also confirm, handover is smooth on republic. The 1GB plan is a little lower than Google Fi as well. 2GB is the same cost as Google, 3GB is slightly higher.

There is a connection between Google (or is it Alphabet) and Bandwidth.com (the Republic Wireless parent company) that I can't quite figure out. Google Voice is mostly based on Bandwidth.com technology, and Republic Wireless and Google Fi are very similar products. Republic Wireless even claims they are about to release a dual-carrier option like Project Fi which they call Tempo.

It is possible that they are just competing, but it seems like there is more of a link there.

Republic Wireless is sticking to Motorola phones, there is that connection.

I'm pretty sure the testing methodology in this article is flawed. Using the manual switching codes (which are NOT recommended by Google) shouldn't be used to evaluate the vast majority of situations. For instance, doing timing on a manual network switch isn't necessarily equivalent to the phone automatically switching. Also, doing a manual switch and then extrapolating that the phone doesn't automatically switch back is not valid.

Basically, you can't test any of the automated functionality using manual codes!

I've been keeping track of Google Fi since it was released.

I'm hoping the new Nexus 5 (both LG and Huawei versions) is compatible with Google Fi, although I did call the Fi support number (and talked to a real human) and she said they haven't heard anything about support for the Nexus 5.

Here's hoping.

Well of course they haven't heard anything about support for an unreleased device that at this point is only rumours and leaks. Did you really think that a company representative would just up and reveal any information (which they probably wouldn't even know until maybe a week before release when they get training on it) in an official capacity like that?

Another interesting future aspect of HetNet technology http://www.netmanias.com/en/post/blog/7388/kt-korea-lte-h-lt...

What GoFi is doing is actually not at all new and has been around a while (the wifi / LTE hand off) the third provider is always been possible with multiple SIMS which has been around for quite a while.

T-Mobile does WiFi to GSM handover now. My phone has been doing it for two years. They have to; T-Mobile coverage has so many holes it would be useless otherwise.

Interesting; "Data does not handover between networks" seems to contradict other reports I've seen that the data connection seamlessly hands off.

He's testing with manual switch codes :)

Expecting the manual switch codes to work exactly the same way as the software is .... strange.

Technically UNDOCUMENTED manual switch codes! ;)

I'm surprised that (it seems) google isn't using Multipath TCP to carry the VPN traffic to google. This would allow it to switch seamlessly between LTE and Wifi and in theory even LTE and LTE while maintaining the VPN connection and thus the call.

In fact, Apple uses this tech for Siri to reduce latency on voice queries.

(author here) I didn't have a chance to test how the VPN works, but even if they were using MPTCP the switch wouldn't necessarily be seamless.

Especially how they are using it now - which hands over a Wi-Fi call (which is data) - to a cellular voice call (not data). It's a subtle point, but calls over cellular are not data, so they are not using TCP/UDP/MPTCP/etc.

> but calls over cellular are not data

Does this change with VoLTE?

https://en.wikipedia.org/wiki/VoLTE

Yes - with VoLTE, calls are also data.

I see, for some reason I thought it was Voice over IP tunnelled to google via VPN (over wifi or LTE). My mistake.

Exactly. They are doing VoIP over Wi-Fi (VoWiFi), but not VoIP over 3G/LTE (which is VoLTE if you follow certain standards).

Have you tested HO between Sprint network and WiFi ?

As per our understanding Sprint doesn't have VoLTE network so if Handoff is supported means Project Fi is VoIP.

I remember having UMA on a T-Mobile BlackBerry (8800, I think) and the call handoff from WiFi to mobile really was seamless, no gaps at all. This was in 2007, by the way.

Reply on news.ycombinator.com