> The combination of the ICCID and the IMSI basically tells the mobile network, “hey, this person paid for a plan.”
As far as I remember, the ICCID never actually appears in standard network messaging. It might be possible for the network to request it, but it's not part of a standard 2/3/4/5g attach.
The piece seemed to miss two major uses for the IMEI (or I missed it when reading), which were working around vendor bugs and allowing emergency calling.
Radio firmware and state machines have always had weird bugs, and even when it conforms to standards (some of which are extremely interpretable), does very weird things in the real world. Pre-smartphone, being able to update phone and radio firmware was extremely rare, so it was common for the networks instead to implement workarounds on a manufacturer or handset basis. Having a hardware ID that identified this was extremely useful.
GSM (and onward) actually supports a handset attaching to a network, even without a SIM card, for the sake of emergency calling. It needs some form of unique identifier for this to work. As much as it could (potentially, entirely redefining the stack) generated UUIDs, it makes some sense for these unique IDs to persist across roaming/sessions/reboots.
> Radio firmware and state machines have always had weird bugs, and even when it conforms to standards (some of which are extremely interpretable), does very weird things in the real world. Pre-smartphone, being able to update phone and radio firmware was extremely rare, so it was common for the networks instead to implement workarounds on a manufacturer or handset basis. Having a hardware ID that identified this was extremely useful
Now that it’s common for devices to be updated regularly, they will typically send an extended form of the IMEI to the network called the IMEISV, which is the same as the IMEI except the final check digit is replaced with a two-digit code indicating the current software version (SV = Software Version).
Probably not a lot. It needs to have a fixed length on the wire, and having 100 updates to the radio firmware for any given model of handset... not likely?
> As far as I remember, the ICCID never actually appears in standard network messaging.
Yeah, that would be the IMSI (which a given SIM card can have multiple of, e.g. for switching to a more beneficial home network while roaming!)
The ICCID is useful for identifying a given physical SIM card (e.g. so that the phone can link a given user-selected profile name to it/the associated phone line for a "preferred line for contact" indicator in dual-SIM phones), and probably also as an identifier when dynamically assigning a new IMSI over the air.
> for the sake of emergency calling
The IMEI can indeed be an identifier of last resort for emergency calls. I wonder if some countries use it to block abuse/spam calls to emergency services, or more importantly, why some others aren't?
In Germany, for example, SIM-less emergency calls are no longer possible, supposedly due to many people calling the local emergency number to test whether a used phone is in working condition without inserting a SIM card... I don't know what they're doing with the IMSI in that case, and if it's locking these callers out, why they can't do the same for the IMEI.
At least in the US, the 911 infrastructure is dated.
In older systems, your caller ID is sent using in-band DTMF tones, which are decoded by the dispatch computer.
On newer E-911 systems they get some additional digital address data from the telephone network, but the record format wasn't designed with VoIP or cellular in mind. So in those cases, the telephone network sends a virtual number and the dispatch computer does a seperate out-of-band lookup with the VoIP/cellular company using that number as a key to get your location.
The whole emergency calling system is layers upon layers of hacks. While they can bolt additional functionality on if they're creative, it's more likely a given feature is _not_ implemented. There's a good chance that by the time the call gets to dispatchers, the IMEI/IMSI isn't displayed anywhere and they just see a random virtual number.
The PSAP (E911 end point) likely will receive an MDN/MSISDN (10 digit number you dial for NANP networks) - this is so they can call back if the call is dropped.
E911 is a special service, so in the case of deactivated/missing SIM cards, the carrier assigns a temporary MSISDN for duration of the call when the UE exits E911 mode - there are actually of regulatory and carrier requirements around E911 mode.
E911 Phase 2 required not only the DN, but also if possible the location of the device - whether thru Cell Base Station Triangulation (if possible) or GNSS with a LAT/LONG based on coarse/fine location info.
In any case, as @tjohns mentions, IMSI/IMEI are not typically used outside of the servicing network.
I've had this thought before while studying biology in college while working on legacy code as an intern. There's definitely a "designed by natural selection" feel to some old legacy systems.
Good point, and implementing a "this IMEI calls 911 to ask for the time of day every hour" block on the side of the networks seems risky as well, so I get how it might not be that helpful.
But then I wonder why having an IMSI (as far as I understand, the SIM can be deactivated, foreign etc., i.e. it doesn't need to actually register to the network) improves this in Germany?
Maybe German authorities just hope that having to insert a SIM might deter people, since SIMs are perceived as being personally identifiable more than just phones without a SIM?
I have heard of people calling emergency numbers to test if a phone is working, but never a country making that impossible. Here, I had always assumed that repeated nuisance callers would be investigated to see if there's an actual problem, and charged with a crime if they're doing it for no good reason.
Always thought it would make more sense to have a dedicated "test number" for this purpose. Probably with some rate limiting.
A lot of telcos used to have phone numbers you could call that would just say the number you're calling from (like with a computerized voice). I forget what this was called, but it was talked about in phreaking community or so on. Not sure if these "caller identifier" phone numbers are still around today though.
They're easier to make than ever, all you need is Twillio and a bit of Python code. There are quite a few in the US alone, both provided by carriers as well as enthusiasts and other companies in the industry.
BT in the UK has 17070 which tells you the number and lets you do tests like the "quiet line test". Handy when working out what was going on when I moved into a property with no live phone service (so no normal outgoing calls), lots of phone extension sockets, and (I discovered) two landlines coming in...
The AT commands are usually used at call establish time, but can be used at other times to query the status of the modem. AT commands never go into the network that is a different set of standards. They are only used on the modem in your phone. If you can get on the right serial pin on the modem you can issue AT commands to the modem and it will do all sorts of interesting things. Different companies have their own standards.
Think of the AT commands as just telling the modem to put itself in a particular mode or go do something. After that the serial bits will do different things or output different things. It does not specify what will be said in the data mode (that is the GSM/CDMA/LTE/RS232 standards and a different part of the modem). Just that the modem will do particular things.
Take for example this old command ATDT,,5555555
That tells the modem attention, go into output DMTF sounds, wait 2 seconds, wait 2 seconds, output the DMTF tones on the speaker line for 5555555, then wait for a sound of response on the receiver and negotiate the highest both ends can talk using the S registers to decide what to do. But the AT commands do not go over the wire. They are purely modem commands. The modems in many cell phones still basically do this. But just with different commands and different registers. There is nothing stopping the modem from sending more AT commands to the other side though but that would be something in the standards to declare.
AT commands also don't make it onto your phone line, after all. They're for communication between a host and a modem/baseband, not between a host and another host or even two modems.
> The combination of the ICCID and the IMSI basically tells the mobile network, “hey, this person paid for a plan.”
As far as I remember, the ICCID never actually appears in standard network messaging. It might be possible for the network to request it, but it's not part of a standard 2/3/4/5g attach.
The piece seemed to miss two major uses for the IMEI (or I missed it when reading), which were working around vendor bugs and allowing emergency calling.
Radio firmware and state machines have always had weird bugs, and even when it conforms to standards (some of which are extremely interpretable), does very weird things in the real world. Pre-smartphone, being able to update phone and radio firmware was extremely rare, so it was common for the networks instead to implement workarounds on a manufacturer or handset basis. Having a hardware ID that identified this was extremely useful.
GSM (and onward) actually supports a handset attaching to a network, even without a SIM card, for the sake of emergency calling. It needs some form of unique identifier for this to work. As much as it could (potentially, entirely redefining the stack) generated UUIDs, it makes some sense for these unique IDs to persist across roaming/sessions/reboots.