You don't need eUICC or anything of the sort to do roaming, which is just what he's describing. Even the behavior with the international prefix on numbers.
Also, the simultaneous data + voice story is kinda more complicated. You couldn't do simultaneous voice+data on 2G phones. You could do it on UMTS/HSDPA for sure (it was one of the marketing points...). Then when LTE came, for a time phones could not do phone calls over LTE (VoLTE) (something which I was told was just a "missing software thing") so they had to drop down to some 3G standard during any phone call. If your 3G standard didn't have support for simultaneous voice+data, like it used to be on CDMA networks, then you just didn't have data (see CDMA iPhone 5). But it was just fine on GSM ones.
> You don't need eUICC or anything of the sort to do roaming, which is just what he's describing. Even the behavior with the international prefix on numbers.
I don’t think the author made this claim at all. He just mentioned that he thinks that Google are using eUICC to make roaming on Google Fi cheaper than traditional roaming agreements. And he’s basing this on the fact that the dat connection can drop out for a little while as the phone roams internationally, presumably because it’s reprogramming the eUICC.
I would assume that if you’re running a service like GoogleFi, where the phone number isn’t associated with an actual phone network, then you can do international roaming cheaper because you just setup direct agreements with local telecoms to provide local data access, and then route the “shadow number” assigned to the SIM to a local Google endpoint. Thus you can create a setup where international roam is achieved by having local only carrier agreements, and doing clever call routing to local Google forwarding numbers, which Google then routes over its own network to the destination country, where a local Google endpoint then pushes the call back into the local telco network.
Doing this completely removes the need to have a traditional roaming agreement where carrier backhaul alien subscribes back to their home carrier, charging a hefty fee for the privilege. And instead replaces it all with local only call and data routing, with Google infrastructure providing international transit, and Google software masquerading the local subscriber identities, so GoogleFi customers don’t see the messy details underneath.
Yeah, I really don't know for sure, I just know that my Fi phone behaves oddly when crossing into Mexico and Canada compared to my Verizon phone a bit ago and I'm guessing it has to do with some of the less typical cost optimization Google does wrt carriers. I don't know a lot of technical detail about how Fi does that and I don't think there's much info about it out there in general, but my theory at least makes sense to me... well-standardized VoLTE and eUICC are pretty recent developments (the same capabilities have existed for much longer but in the form of various proprietary solutions). So this could explain why, early on, Fi was limited to only a few Android devices with bespoke kernels, while nowadays (as VoLTE and eUICC have become much better supported) it works correctly on a much broader range of devices.
VoLTE, for example, has been around in concept for longer than LTE, but it has had a complex standards history that I did not try to really explain because it would get lengthy. "VoLTE" and "IMS" can actually refer to different systems (not all VoLTE uses IMS) but it all gets sort of vague and contextual. LTE phones with VoLTE capability have been around basically as long as LTE has been in service in the US, but for a long time were mostly proprietary systems that required per-carrier support. This is still true to some extent but US carriers and device vendors are now much more converged on an IMS-esque architecture than they were even just a few years ago, so it's now a lot more likely that you can e.g. switch to a different carrier and still have VoLTE work... although not guaranteed!
One hint that might help reveal how Google Fi handles this is the source of web traffic on my phone... web requests from my phone in Mexico are coming from an IPv4 address registered via ARIN to Airlinq with a contact address in the UK! Airlinq has some kind of relationship to Hong Kong ISP Hutchison and it seems like the takeaway is that they offer a "global cellular mobility" solution. My guess is that Telcel is being used as the mobile provider (I did some checking of intercept recordings which confirms my voice calls at least are going via Telcel) and IP traffic is being routed via Airlinq, whom Google presumably contracts to handle international IP connectivity. Normally, in the US, my traffic emerges via IPv6 from T-Mobile. This is an indication that my traffic is not being tunneled back to the "home" provider as is the typical case with roaming.
It has been a few years, but when I last used Google Fi, all international roaming was handled by the T-Mobile SIM profile, except when using Three UK, which had it's own profile/shadow number.
VoLTE roaming agreements do not exist everywhere, so it is still very common to fall back to 3g for calls when roaming.
> I don’t think the author made this claim at all. He just mentioned that he thinks that Google are using eUICC to make roaming on Google Fi cheaper than traditional roaming agreements.
Maybe, but as far as I can tell Google Fi is just a T-mobile MVNO (they used to also use Sprint, but T-mobile bought Sprint ~2 years ago). My direct-with-Tmobile service also includes free international roaming in a ton of countries, so it would make sense if Google just took advantage of the agreements T-mobile already has in place.
The lack of VoLTE early on was not quite as simple as missing software as there was, at the time, not really any agreed upon VoLTE architecture or implementation. IMS has existed since before LTE, but carriers have been very reticent to implement it because the choice to architect around existing internet protocols actually leads to a relatively high degree of complexity from the perspective of legacy telcos. For most of the early years of LTE, most carriers just didn't support VoLTE as an intentional business decision, to avoid the expense of deploying infrastructure. Those that did mostly deployed "lite" VoLTE stacks that were simpler and less capable than the IMS architecture, and this is the big issue that leads to the situation we still have today in some cases were given phone models are only capable of VoLTE with specific carriers, due to those carriers using a non-standard architecture.
Most LTE phones could do HSDPA+ during voice calls but some couldn't. I'm not sure why, it may have just been a simplifying decision by the vendors. This was more of an issue in the very early days of LTE, e.g. my hazy memory is that the HTC Thunderbolt completely dropped data during voice calls.
Yes, when roaming, VoWiFi or VoLTE can have quite unexpected results due to your 'data' being backhauled to your 'home' provider, for both billing and dialing. Former you can't do much about, except complain when things go wrong, but as for numbers: always store (and dial) these in +countrycode-subscribernumber (minus the leading 0, unless it's an Italian number, +39) format, and you'll be mostly* fine.
*Unless visiting countries that have providers with woefully misconfigured dial plans, say, Nigeria...
Always storing contacts using the full international phone number is definitely the way to go. As someone who, at least before the pandemic, used to travel a fair amount this basically eliminates all issues and makes everything "just work" everywhere.
To be honest I'm surprised that phones doesn't do this automatically when you type in a local number.
I was also surprised by this. I moved country and was shocked that none of my phonebook worked and I needed to run a script to add a +1 to all of the non-international numbers in my phonebook.
Maybe phones don't necessarily know the current international prefix?
This is not related to LTE, just to roaming itself. In fact, even the manual of the first GSM phone I ever bought said as much (to store your numbers with the international prefix on the address book -- otherwise, they could fail to be matched while roaming).
Well, it is related to LTE, in the sense that VoLTE calls are treated as 'data' (and thus backhauled to your 'home' provider, as per your (e)SIM), whereas 'voice' calls are handled by whichever provider you happen to be connected to.
But the advice to always dial calls in 'international' format is helpful.
In fact the author is describing the opposite situation, where his "LTE calls" require the international prefix while the "Wi-Fi" calls do not require it (not sure if VoWifi or plain VoIP, it's not clear from the description, and I don't know of any phone provider which allows true VoWifi while roaming).
Note most modern dialing programs (and likely all of the VoLTE-capable ones) will silently add some prefix to your calls anyway, so it's really hard to know what's going on behind the scenes. But you usually can't dial your provider's special phone numbers "as if your calls where backhauled to their network through VoIP" when you are roaming, even with VoLTE. To e.g. check voicemail you will still need to dial your provider's roaming-specific number, which will come with an international prefix.
The fact that iOS (not sure about Android) doesn't automatically add the local international prefix when you store a new contact is surprising. Seems like an easy quality of life win.
Tangentially related, does anybody have experience with libre SIP over LTE (eg native Android VoIP dialer)? With the partial 4G shutdown in the US, I'm reluctant to buy a new pocket communicator. LTE data continues to work just fine, and I've already got an Asterisk setup for my home phones. VoLTE seems like it's doing the exact same thing just with the carrier's blessing, and the less proprietary crap in my life the better. My current plan is to try out SIP over wireguard [0] over LTE, and see how that treats me. The biggest problem I foresee is a lack of QoS, but given that carriers' main concern seems to be streaming video, I'm hoping that best effort on a lower bandwidth stream will work alright.
[0] Wireguard is to solve the NAT issues, make QoS predictable on different networks, and gain secure calls to home as a bonus.
I had a friend try VoIP on a dataplan a few years ago.
> The biggest problem I foresee is a lack of QoS,
Bingo. QoS for voice is about jitter and consistency of your stream.
> I'm hoping that best effort on a lower bandwidth stream will work alright.
Lets put it this way: you don't care if your webpage loads 0.2 seconds slower. But a few random 0.2 second delay in your conversations will make them utterly, and completely unintelligible. Low QoS is something data can afford because little "sprints" of high bandwidth is good for webpages and streaming video.
But "live", and "realtime" voice communications, the jitter is just too awful.
If no one else is on the cell-tower, you might be fine. But every now and then, you'll just get completely terrible phone calls that are unusable.
I've been using SIP on my Android phone for a couple of months now, and QoS hasn't been an issue at all. I'm using Voip.ms so I can have SMS and MMS. There's a SMS app but it doesn't support MMS; MMS messages are emailed to me and I just log on the Voip.ms portal and message there. I use Linphone as the client, and Strongswan for VPN.
The main difference VoLTE provides is preferential network access for voice calls. In times of congestion, voice calls will still work when data might not.
VoLTE calls also have a coverage advantage to them over data. Cellular networks have different handover settings for VoLTE (QCI 1/5) where the device can hold onto its RF longer while a call is ongoing and still allow the call to work using techniques like TTI bundling. The codecs used for VoLTE require very little bandwidth and thus can still operate in extremely poor conditions.
And if you're wondering why carriers don't just offer the same for data, it's because customers using data in cell-edge cases would be disappointed with the experience even with the extra handover settings and TTI bundling. That combined with the extra PHY resources being allocated to a situation where data just might not arrive 70% of the time makes it more worth it to allocate those resources to VoLTE specifically especially when they might be critical like in E911 scenarios.
I knew there would be some layer cross-cutting prioritization. It's interesting to hear the exact details.
I assume there's no way to specify different QCIs for data packets or even the whole connection ? That's all specified by the closed source radio firmware?
If I'm reading things right, it implies that IMS (eg modern SMS/MMS running over IP) actually uses a different data channel that gets a higher priority? So when one is entering hostnames in say APN setup, all that traffic is going on a different channel? And thus one probably can't just enter their own server info to self-host text messages (modulo obtaining network identity/connectivity) ?
>I assume there's no way to specify different QCIs for data packets or even the whole connection ? That's all specified by the closed source radio firmware?
From the application layer? I don't believe so outside of the phone's native dialer/closed source firmware.
>If I'm reading things right, it implies that IMS (eg modern SMS/MMS running over IP) actually uses a different data channel that gets a higher priority?
I believe all IMS traffic is going to be higher priority regardless of if that's voice or SMS. They're both carrier-provided SIP messaging so if SMS over IMS is configured, it would use the same APN, go through the same CSCFs, and get priority. It's all the same PHY connection though. There's not a fully separate set of wireless channels for voice and data like it was in the CDMA standard where there were CDMA carriers for voice and EVDO carriers for 3G data.
You wouldn't be able to just host your own SMS though. You'd need a private APN from the network operator to do anything like that. Other systems hosted by the operator (HSS and MME) are what allow you onto the network.
Thank you for the reply! I'm trying to tease out what the limits of code on the application processor can do. By "data channel", I meant logical IP network.
Is it correct to say that IMS runs completely on/behind the locked down radio firmware, with the application processor then just getting access to an API that deals in high level "text messages" ? As opposed to the alternative where the servers I set in APN->MMSC/MMS Proxy are used directly by software on the application processor... Which I assume is not the case? And if I set MMSC to my own server, the resulting IP packets wouldn't be routed to the Internet because they're transmitted on a separate IP network from the application-processor-facing Internet access?
So barring some feature of the BP<->AP API to do so, there would be no way for software running on the AP to set various priorities on its own Internet-bound packets?
the biggest issue i ran into when trying voip with a cell phone is lack of functioning mms (and therefore also group sms). that ended up being the dealbreaker.
I wasn't aware Mexico had intended to join NANA and use the NANP. It's a shame they didn't.
For non North Americans: the telephone networks use an international numbering plan so Canada, the US, and about 18 smaller countries use a single numbering scheme and issue area codes out of the same pool. So for me in the US dialing Canada or Bermuda is the same as dialing somewhere in the US.
It is much nicer than the international dialing system where each country has its own rules about what parts of the number are area, local exchange, etc. I wish the old ATT had designed a larger scale numbering plan that could have been worldwide and everyone could have adopted it.
(Imagine if IP addresses were different lengths and subnets were described differently based on the country of connection)
Hard disagree - it's actually pretty awful from a mobile user's perspective.
You dial a number that is +1 and looks like a normal 10 digit phone number.... and bam, you're paying $3/minute to call Canada (back when everyone charged more for Canada) or Bermuda that is still expensive I think on every carrier.
Everyone could use 10 digit dialing and have their own country codes still... it's silly that 19 countries are sitting behind +1 and that they might have a significant surcharge to call.
For those of us in the VoIP industry, VoWiFi offers no surprises. The phone establishes an IPSEC tunnel back to the provider for secure calling using the SIP/IMS stack. Much of the time when I am at home and not planning to go out, I turn on airplane mode then enable WiFi. Calling, SMS, MMS, etc. all work fine. It's a battery saver.
> It seems to be a general trend that countries with variable-length area codes lack well agreed upon phone number formatting conventions. In the UK, for example, there is also variability (albeit much less of it). This speaks to one of the disadvantages of variable-length area codes: they make digit grouping more difficult, as there's a logical desire to group around the "area code" but it's not obvious what part of the number that is.
It’s trivial for computers. For example, using Google’s libphonenumber [0]. For example, Poland uses `000 000 000` for mobiles, and `00 000 00 00` for landlines. libphonenumber knows how to handle this [1]:
<!-- Mobile, pager and a few fixed-line numbers.
(70 numbers are formatted as per mobile numbers, based on information from some Polish people). -->
<numberFormat pattern="(\d{3})(\d{3})(\d{3})">
<leadingDigits>
21|
39|
45|
5[0137]|
6[0469]|
7[02389]|
8(?:
0[14]|
8
)
</leadingDigits>
<format>$1 $2 $3</format>
</numberFormat>
<!-- 9-digit fixed-line numbers. -->
<numberFormat pattern="(\d{2})(\d{3})(\d{2})(\d{2})">
<leadingDigits>
1[2-8]|
[2-7]|
8[1-79]|
9[145]
</leadingDigits>
<format>$1 $2 $3 $4</format>
</numberFormat>
I also find it annoying that basically all roaming works by tunneling traffic back home. I guess it kinda makes sense for calls where it needs to be routed by the home carrier but for data it adds a lot of latency and cost.
In Canada our data is stupidly expensive such that as a fairly small data user I was considering getting a PAYG "global data plan" instead of a monthly local phone plan (I don't use a local number anyways, so I just need data). And while it would be cheaper for me (and be extraordinarily cheaper when traveling) basically all of these sims have a "home" country that traffic is routed to. Not only is this slower but it also results in funny behaviour for sites that try to optimize/block users based on GeoIP.
If one of these global sim providers could do local egress I would be all over that plan.
This behavior can make your internet on the phone really slow, especially if your SIMs home country is on the other end of the world.
But with 5G there is a mode for routing IP traffic directly to the internet during roaming, without sending it „home“ first. Let’s see if providers will implement that.
For Xiaomi, ##869434##, I'm not sure about other devices. Mine doesn't work, for some reason, but everyone else's works fine. I think my SIM is somehow misconfigured.
Also, the simultaneous data + voice story is kinda more complicated. You couldn't do simultaneous voice+data on 2G phones. You could do it on UMTS/HSDPA for sure (it was one of the marketing points...). Then when LTE came, for a time phones could not do phone calls over LTE (VoLTE) (something which I was told was just a "missing software thing") so they had to drop down to some 3G standard during any phone call. If your 3G standard didn't have support for simultaneous voice+data, like it used to be on CDMA networks, then you just didn't have data (see CDMA iPhone 5). But it was just fine on GSM ones.