sfx2000

Did what I could - a single ballot...

Talking with some folks out here in SoCal - they're like why as Cali is already a given for a particular party/candidate...

Response - it's the popular vote for one as to the Pres/VP slots, but it's also the undercard - the Senate/House on a national level, and the local things like Mayor, Country/City Commision, the judges, even for some governors...

Your local schoolboard needs a hand or two - and in Cali, school bonds...

Fill it out, turn it in to a dropbox, or mail it in - voting in person - that's good as well.

We all have a single ballot - fill it out, and let your voice be heard.

And then take a break...

Gosh, this is almost a replay of LightSquared (Ligado) and the GPS band/guard-bands - one has to consider the public good.

FWIW - Ligado and NextNav - yes, Reston, VA - must be something in the water

900MHz is an unlicensed band, so as long as folks play by the rules, it's fair game. If you look inside that band, there's a lot of different air interfaces running in there already - it's not just LORA.

NextNav, perhaps, wants to deploy a solution that uses those frequencies, and they're ok to do that, as long as they follow the rules.

Meshtastic - well, their business is to sell devices into that band - simply put, so any interference may impact their business.

There's other tech that runs in 900 - Z-Wave for example, which is used extensively with the Home/Commerical Security industry for sensors to base - also we have 802.11ah (WiFi-HaLow).

My position here is don't make any changes - as long as folks follow the rules for that band, you're good to go - If NextNav's tech cannot work within the rules, well, time to find another band...

It should fail soft - e.g. warn user that Private Relay is not available, but don't block connectivity.

This really isn't a client side issue, but the work-around is to disable the feature - which likely means that once service is restored...

Yes, it's like that.

The carrier can ID the device type by the radio layer itself at the PHY layer.

SERO was one of the Sprint Rate Plans, the other was the Pioneer Plan for early adopters on SprintPCS

HTC got into a bit of trouble with the carriers on the whole IMEI/MEID rewrite mess at the end of the day. With Qualcomm, that was an NVITEM that was supposed to be read-only.

Gosh, yes it's a bit of a mess...

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 don't recommend mucking about with the IMEI, as you risk a collision with another device that is already using that IMEI - IMEI's are supposed to be immutable.

I realize that there are some Modem OEM's that might allow the IMEI to be "adjusted", but proper modem vendors will not allow that AT command.

Interesting thread - as someone that used to be in carrier space...

IMEI - we only really cared about the TAC prefix, as this identifies the device type, which is mapped to capabilities for services.

IMSI - this is usually in the SIM card (UICC), and mapped out specifically within the uSIM/SIM application inside the card. This is aligned with the Billing/Rate Plan for services that the subscriber is set up with.

TMSI - this is usually what the network uses to page you and also deliver singaling over the NAS via the SGs interface for devices that do not support IMS/VoLTE

ICCID - this ID's the card itself, for SIM cards, it always starts with 89 as this designates the card as telephony related as a physical UICC - remember, there are other types of UICC's such as CHIP based Credit Cards, which start with a different number.

MSISDN - this is the number that you dial and send SMS to - in legacy systems, it can also be referred to as the MDN

Fun Fact that was skipped in the article - IMEI's that start with 99 are special, as these indicate that the Device is both GSM/UMTS/LTE and CDMA/EVDO capable, and generally those IMEI's will align closely with the CDMA MEID's, but they were not required to. The "99" range wasn't just Apple, but was used in the early days of dual-mode across most vendors as it helped facilitate session handovers from C2K to any 3GPP based service. For C2K, on the IMSI front, most devices would use IMSI_T (True IMSI based on the SIM card IMSIef) but some used IMSI_M which was based on the legacy MIN.

Legacy - there is the ESN in CDMA, but this is very legacy, and was largely superseded by MEID - for Legacy Support, pESN could be derived from MEID, however at the high risk of collisions...

It was interesting - I was pulled into a startup by a friend, and I was the first full-time employee - he joined later, and we were peers - he headed up HW and I led the SW and architecture side - one of the execs was also known, as we worked years back at the same company.

It comes down to the dynamics - if one is asked to join in, it's because one has demonstrated capabilities and the ability to execute in a team environment.