>The RP destination number, +14047259800, is a normal-looking US number, what a telecom engineer would call an “NANP E.164”. A Google search turns up documents showing that this number is associated with an AT&T “service control point” (a sort of server) that was made by Sun Microsystems. This is most likely a Sun Solaris server running an Oracle SMSC package, physically located in Atlanta, GA. Interestingly, this is not the SMSC number that AT&T uses for normal texting (+13123149810). This is a special SMSC that is used for special applications.
How many SIMs has AT&T around? (I assume millions.)
A single Solaris server (which I imagine to be a little dated) can manage the whole stuff?
It must be pretty much efficient or these data must be transmitted very seldom.
> A single Solaris server (which I imagine to be a little dated) can manage the whole stuff?
I don’t know what they run, but Oracle still sells some quite beefy hardware. SPARC M8-8 servers can have 8 CPUs of 32 cores each, for a total of 256 cores. The CPUs are clocked at 5 GHz and use a 20nm process. Maximum 8TB of RAM. The CPU and the process are somewhat dated but still can do a lot.
Fujitsu has even beefier SPARC servers - the M12-2S has 12 CPUs, 384 cores, max 48TB RAM, albeit only at 4.25GHz. Fujitsu SPARC servers run Solaris too and Oracle resells them.
So I’m sure SPARC can handle this use case, just not very cost-effectively-whatever it can do, an x64-based solution is likely to be able to do the same cheaper. And it is a technological dead-end - Oracle plans no further CPUs or major OS versions, but they’ll keep selling their current lines as long as people are willing to buy them. Fujitsu is moving away from SPARC too. Rumour has it Oracle and Fujitsu were negotiating for Fujitsu to buy the SPARC hardware business, but they couldn’t agree on terms, and now Fujitsu has decided to move away from Solaris/SPARC and towards Linux/ARM instead. Fujitsu still have a new SPARC CPU release this year on their public roadmap, not sure if it is happening, but if it does it is probably their last.
That Oracle-Fujitsu SPARC acquisition rumor is fascinating. Do you think Fujitsu's A64FX line can hold its own against Ampere's stuff and the AWS Graviton CPUs?
In this case, it would be transmitted only when a SIM is turned on in a new device for the first time. Probably still a lot of traffic, but a drop in the bucket compared with the remaining signalling traffic a large mobile network sees every day.
These systems can probably also be scaled almost without limitation for the same reason.
>In this case, it would be transmitted only when a SIM is turned on in a new device for the first time.
But this is seemingly not what happened in the case at hand.
>In this particular case, the phone had recently downloaded an update that included new baseband firmware. That was almost certainly the trigger for this message.
So, every time the baseband firmware is updated, likely millions of devices need to send that SMS to that single server, unlesss the updates are deployed somehow sequentially.
And if these firmware updates happen not very often, which probabilities were that just after such an update the person (suspected of distracted driving) crashed with the car?
Like 0.00000000001 or very, very, very rare chance.
That's a very valid concern, and maybe there was just such an "event flooding prevention" mechanism at play, deferring the IMEISV report by a random time?
>The RP destination number, +14047259800, is a normal-looking US number, what a telecom engineer would call an “NANP E.164”. A Google search turns up documents showing that this number is associated with an AT&T “service control point” (a sort of server) that was made by Sun Microsystems. This is most likely a Sun Solaris server running an Oracle SMSC package, physically located in Atlanta, GA. Interestingly, this is not the SMSC number that AT&T uses for normal texting (+13123149810). This is a special SMSC that is used for special applications.
How many SIMs has AT&T around? (I assume millions.)
A single Solaris server (which I imagine to be a little dated) can manage the whole stuff?
It must be pretty much efficient or these data must be transmitted very seldom.