How The Cellular Apple Watch Will Impact Carriers (and You)

Nearly a week past the keynote the new hardware is all the rage, iOS 11 is nearly upon us, and controversy runs amok – be it about Face ID, the iPhone X notch, or the naming conventions, everyone has an opinion, or is actively seeking out opinions. Interestingly, the most questions I got were about the Watch, and whether a cellular one picked up in the US next month would work in Europe (spoiler: it won’t), or how it would work. The answers I have aren’t definitive, but they compounded my utter disinterest in getting a cellular model while prompting me to write about the matter at length…

The LTE spectrum allocation throughout Europe (and even inside some countries) is charitably messy, with the formerly 3G 2100Mhz band pretty much completely taken over and allocations growing upwards to 2600MHz for LTE and, in some places, re-using the 900MHz or lower bands for “wide area” LTE (which usually entails replacing network equipment).

Apple has managed to make the US situation a lot more interesting by apparently completely snubbing T-Mobile’s 600MHz network, and given that they seem to be planning multiple SKUs tailored to the available bands in each territory, buying a Watch is going to be an interesting puzzle for any frequent traveler.

For me, locally, current allocations look like this:

What that picture doesn’t tell you, though, is what is actually being used for LTE coverage (because, like I mentioned, some bands are being re-used for other purposes) and where, which is a rather more important factor given that operator coverage maps are largely an exercise in probability theory as applied to the realm of cartography, so the chances of any LTE device working 100% everywhere and at peak efficiency are pretty much nil¹ right now.

Assuming that the Watch is going to be a primarily data-oriented device (we’ll get to calls in a bit), that would be OK if it weren’t for what spotty coverage and constant transitioning between network types does to your battery – because the device keeps having to negotiate network conditions like what base station it’s actually talking to and whether it needs to upgrade or downgrade the data bearer (all of which takes up a fair amount of power when you’re moving around, even if the device is in an otherwise idle state).

That’s called negotiating a radio access bearer, and what the network does (because that’s how tariff plans were originally designed) is to only allow you access to the data bearers you paid for. In practice, though, these days operators allow most devices to use anything up to the stated upper throughput in your plan regardless of whether you’re actually using LTE or falling back to plain 3G or HSPA, because they can’t provide LTE everywhere.

My iPhone will skip from GSM to LTE directly inside most populated areas, and tenously hang on to 3G on most of the rural areas I visit, and Portugal has excellent coverage when compared to just about anywhere (I used to work in network planning, so I can still pinpoint the nearest base station in many places, and even have a feeling to what kind of radio it has based on the economics models we worked with).

All the above is worked out through what is called a signalling radio bearer, which is essentially an always-on, very low bandwidth channel with timings and semantics optimized for handling that negotiation as you move across the network and cross cell boundaries (which is when hand-overs occur). It’s not a battery-intensive thing unless you’re actively moving about, and it’s optimized to bits at both ends of the radio link.

What is intensive, though, is exchanging actual data with the network, and retrying packets in low-coverage or failed hand-over situations when your device is still trying to figure out coverage. But there is worse.

For a long time now, operators have been dealing with the Internet in a fairly haphazard way – DDOS attacks on operator networks are fairly common these days (more so than you might realize), the upshot being that anything you directly hook up to the Internet is going to get hammered with junk data every now and then. Passing that data down the pipe to end devices is extremely costly to both the operator and the end user, because it congests radio bearers and drains device batteries fairly quickly (remember those occasions when your battery ran out suddenly without any apparent reason? there’s an even chance it was junk traffic rather than the Facebook app).

When I worked at Vodafone (back when people were hooking up Windows laptops to mobile broadband and getting holed by worms instantly) we spent years agonizing over the “right” way to protect customers from this kind of thing, and there were multiple ways to tackle this. The simplest is to just use carrier-grade NAT – give everyone a private IP address and take on the toll of managing outbound connections while ignoring inbound junk – but that doesn’t fly in this age of IPv6 and custom protocols (even though 99% of non-gaming mobile applications pretty much just use HTTPS these days), so other techniques were employed, and the tactics keep changing.

Either way, the point here is that the kind of connectivity (and protection) your carrier provides has a tremendous impact on battery life, and this is not anectotal – my current experience since leaving the Vodafone network is that under identical conditions, and left idle, an iPhone on a competitor’s network has around four hours less battery life (and I recently got back my Vodafone number, so I can reproduce this at will).

Imagine what that can do to a Watch, and factor in spotty coverage. Might be indistinguishable from streaming music like the ads show, but it will take a toll.

Let’s talk about voice, which is the really interesting bit. Forget FaceTime Audio, which is not the point here because it goes over the data bearer and has zero relationship with carrier voice switching (and no MSISDNs).

When you’re placing a voice call, most modern devices set up a dedicated bearer for voice data (usually AMR encoding, originally at 12.2Kbps but occasionally bumped up to what passes for “HD voice” on some networks). In the old days, devices would drop or suspend the data bearer due to processing limitations, but these days the only point in doing that would be saving a little power and network capacity (so the Watch might not actually bother, especially given that it’s being positioned as an “always on” device from the moment it decides to go cellular).

Voice always takes precedence over data, though, but it can be quite tricky to ensure call continuity if your network is assembled from different vendors – you might be talking to an Ericsson base station in LTE one millisecond, and have to hand over to a battered Motorola GSM box as soon as you go outside city limits, and your device has to jig and dance and beg and, eventually, downgrade to plain old GSM (and I’m not even taking into account fancy new things like VoLTE here, because if that turns out to be a hard requirement…).

I have no idea how the Watch will handle this, other than saying that it is a solved problem from both a network and device perspective. But it is going to be interesting to figure out how it will handle other situations, like “untethering” from a Bluetooth or Wi-Fi connection to your iPhone (which is how I take calls on my original, Series 0 Watch these days) and telling the network it’s available – the marketing blurb asserts it’s magical, and I know it will work, but I’m curious as to the technical details.

Which takes us to network registration, SIM cards, and the wonderful, wonderful world of vendor and regulatory licensing.

Physical SIM cards are surprisingly complex beasts, and during their heyday were touted as an application platform all by itself, with SDKs and apps and whatnot. But regardless of on-chip features, what they actually do is hold the required information (unique identifiers, PINs and encryption keys) to allow you to get on the network by authenticating both the SIM card and the network.

In practice, each SIM card holds an IMSI (a 64-bit subscriber ID), which is what is actually mapped to your MSISDN (your phone number). The network keeps track of your device through its IMEI, but determines what services the device can access based on the subscriber identity, not the hardware.

The association between your device, your IMSI and your phone number is held on a network node that was originally called the HLR (now an HSS in IMS parlance), which is essentially a database that holds the association between your SIM card, the device you’re using, where it was last seen on the planet, and service information – which includes the phone numbers mapped to it and the radio bearers and roaming networks it’s allowed to use. Gripping stuff, I know, but there are a few interesting nuances here:

The first is that in the dawn of time, HLRs had trouble with keeping track of multiple SIMs that mapped to the same phone number – you could work around it by (legally) cloning² the SIM cards so that they had identical IMSIs, but only the last device to be powered on would take calls, because there were a few fundamental gaps in how device registration and call handling worked – and making two devices ring simultaneously has pretty much nothing to do with the SIM card.

The second is that SIMs have a bunch of direct and indirect licensing and regulatory charges associated with them – vendors used to license their HLRs (and the rest of the network core) on a per-active-subscriber base, and telco regulators license spectrum and set taxes on operators based not just on frequency usage, but also based on their active subscriber count.

Going back to the first point, part of those feature gaps were originally filled by something called an IN (Intelligent Network), that sat between voice switches and the HLR and intercepted (or kept track of) updates to the HLR and did various things – most notably prepaid services, which (incidentally) were pioneered in Europe by Portugal Telecom.

Doing simultaneous ringing or mapping the same number to multiple SIMs could be hacked in there (and was), but that kind of feature was perceived as something for businesses, and (quite often) implemented as a direct translation of corporate PABX features (which, ironically, were almost never integrated with mobile networks, requiring various bits of custom glue).

A lot of this was cleared away by the need for telcos to get their act together and merge their fixed and mobile networks – often by transitioning to IMS, which taken literally would have forced them to gut most of their voice network to transition to VoIP (a costly endeavor, which is still going on in many places as older equipment is phased out).

This enabled telcos to finally have a unified way to deal with (and routing calls to) fixed and mobile numbers, and will some day also make data provisioning somewhat uniform (we’re not quite there yet in the field, but it’s getting easier).

However, formerly business-centric features like simultaneous ringing are still charged extra by many vendors, and thus are not usually included in consumer plans (family voice or data bundles, in comparison, are a lot easier because it’s all about creative post-processing in the billing stages).

The bottom line here is that getting your Apple Watch on a carrier network adds to carrier costs, and all the more so if they are stuck with an ancient subscriber database, haven’t re-negotiated their voice feature licensing or (which is most likely to happen) simply haven’t done the end-to-end integration required to have someone at a call center press a button and provision the services properly for you³.

Which is why I’m not holding my breath for widespread availability of cellular Watch plans.

Many carriers will be able to hack that provisioning flow in somehow (even if it’s done semi-manually for a select few customers), but in an industry that has systematically gutted itself of all significant in-house IT development skills and where packaged software feature roll-outs take the best part of a year, the multiple customizations required to get that off the ground will take a while.

Also, family plans and bundles in Europe have been mostly about quadruple-play (fixed voice, fixed broadband, TV, and mobile), and to boost revenues carriers have shirked away from mobile data bundles with multiple SIMs. As a case in point, I gave up on having a cellular iPad because there was no way I could share a data allotment between my phone and a mobile hotspot or an iPad, and it didn’t take my former colleagues to explain to me that such bundled plans do not maximize revenue.

Getting the SIMs to work is also a solved problem. I kept track of how the iPad’s virtual SIMs were (originally) provisioned through Truphone, and assume the Watch SIM activation will work largely the same.

Still, it’s going to be very interesting to see how carriers will make the voice bits work at their end, because some of them, right now, just can’t. Everything is possible, but buyer beware, because I have no idea what your carrier will actually need to do, or when it will be available.

But what I’m most interested in is not how the Watch’s virtual SIM is provisioned, but (most importantly) what happens if you need to change carriers – I’ve had enough “fun” recently getting my old iPhone 5 unlocked to get back to the Vodafone network, but the prospect of jumping through a lot of exquisitely baroque processes to get a brand new, €400, additional device to go along with me to another network is something that gives me pause.

And that (besides more pressing needs) is why I will hold off on getting a cellular Watch for a while.