[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

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.

[yuubi]

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