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.
Most people I've talked to with pre-existing devices have had varying degrees of problems.
edit: I also had no previous Google Voice account to transfer FWIW
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.
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.
Does this double the bandwidth you're using when MPTCP is in effect?
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).
This is what Touch Mobile (www.touch.com) does for their handover, for instance.
> 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 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 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.
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.
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.
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.
Standard smartcards (including SIMs) have a select command, which is used to select applications. If there are two USIM apps (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??)
 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.
 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.
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.
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.
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.
It is possible that they are just competing, but it seems like there is more of a link there.
Basically, you can't test any of the automated functionality using manual codes!
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.
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.
Expecting the manual switch codes to work exactly the same way as the software is .... strange.
In fact, Apple uses this tech for Siri to reduce latency on voice queries.
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.
Does this change with VoLTE?
As per our understanding Sprint doesn't have VoLTE network so if Handoff is supported means Project Fi is VoIP.