
Network handover in Google Fi - ndrarmst
http://nicholasarmstrong.com/2015/08/network-handover-google-fi/
======
KirinDave
"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.

~~~
lsdafjklsd
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.

~~~
KirinDave
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.

~~~
lsdafjklsd
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

~~~
KirinDave
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.

------
jewel
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.

~~~
toomuchtodo
> 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?

~~~
mjevans
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).

------
a-dub
"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.

~~~
ndrarmst
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.

~~~
a-dub
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](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.

------
Bedon292
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.

~~~
ndrarmst
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.

~~~
Bedon292
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.

------
dgulino
[https://republicwireless.com](https://republicwireless.com) provides seamless
wifi->cell and cell->wifi handover of calls.

~~~
chrisBob
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.

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

------
arkieguy
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!

------
adovenmuehle
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.

~~~
mynameisvlad
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?

------
zw123456
Another interesting future aspect of HetNet technology
[http://www.netmanias.com/en/post/blog/7388/kt-korea-lte-h-
lt...](http://www.netmanias.com/en/post/blog/7388/kt-korea-lte-h-lte-u-
mwc-2015/netmanias-interview-with-kt-at-mwc-2015-kt-s-demonstrations-of-lte-h-
and-lte-u)

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.

------
Animats
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.

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

~~~
DannyBee
He's testing with manual switch codes :)

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

~~~
arkieguy
Technically UNDOCUMENTED manual switch codes! ;)

------
edude03
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.

~~~
ndrarmst
(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.

~~~
toomuchtodo
> but calls over cellular are not data

Does this change with VoLTE?

[https://en.wikipedia.org/wiki/VoLTE](https://en.wikipedia.org/wiki/VoLTE)

~~~
ndrarmst
Yes - with VoLTE, calls are also data.

------
danhash
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.

------
thrownaway2424
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.

