> The patents are referred to as Standards Essential Patents, or SEPs. Because of this arrangement, a vendor like Nordic probably can’t open source their modem firmware even if they wanted to.
Why would a SEP license forbid publishing modem firmware? The IP[0] involved with the modem firmware is copyrighted and trade secret material; publishing the firmware does not (and cannot) grant a patent license to those licensed standards-essential patents. It only imperils your implementation of the modem firmware, not the whole patent spec.
To wit, Cisco publishes an H.264 codec with BSD-licensed code, even though H.264 is under a shitload of patents that they are licensing. OpenH264 does ship with an additional patent sublicense that applies if you are using their build and installing it in a specific way, but that is particular to MPEG-LA's licensing structure[1]. Publishing an implementation of a patent you are licensing does not automatically sublicense the patent.
[0] Laws that grant the ability to dictate the conduct of your competitors
[1] Cisco is abusing(?) the MPEG-LA royalty fee cap to shield FOSS entities from having to take a license, basically, by paying for them.
> Why would a SEP license forbid publishing modem firmware?
Contracts and money.
> The IP[0] involved with the modem firmware is copyrighted and trade secret material; publishing the firmware does not (and cannot) grant a patent license to those licensed standards-essential patents. It only imperils your implementation of the modem firmware, not the whole patent spec.
Publishing the source to the firmware would allow people to make use of patented tech without paying for it even though it would be illegal to do so. Also, your license may simply stipulate that you cannot publish or share your code in anyway outside the company.
> To wit, Cisco publishes an H.264 codec with BSD-licensed code, even though H.264 is under a shitload of patents that they are licensing.
> Cisco is abusing(?) the MPEG-LA royalty fee cap to shield FOSS entities from having to take a license, basically, by paying for them.
As you point out here, Cisco is paying for it. They publish open code, and to ensure the LA doesn't come after them, they're paying additional money.
Cisco is paying for the binary provided. Not the source code. There are plenty of patented and open source. Every H.264, H.265, H.266 Encoder and Decoder in existence and used.
There are also plenty of open source 4G and 5G software implementation.
I sometimes wonder if I should just give up the fight for patent misinformation. On HN it is very binary, either good or bad. And all patents and Ads are evil.
There's also the possibility of trade secrets being involved. An example hypothetical: Maybe Qualcomm has tons of lab data showing signal performance and integrity for any given channel, band, power level, general environment (urban, suburban, rural), device position, device altitude, etc.
You might want to use that data, and algorithms derived from it, to improve your device's battery life. That data obviously cannot be patented, and while the lab data would be copyrighted and not part of the finished product, Qualcomm would understandably be mighty particular about any open-source code implementing the conclusions.
I suspect a big reason is that there’s middleware: some of this stuff is so complex, that like video games, there’s probably a cottage industry of companies selling partially implemented bits and pieces, or licensing across companies of source code, or companies only licensing the patents if you agree to never release code. There’s also the IP angle: if you do manage to figure it out, there’s no honor helping Huawei.
> I suspect a big reason is that there’s middleware
I’d bet it’s simpler. Saying “yes” to the ‘can we share this outside of this company?’ Question means a lot of work and meetings and red tape and somebody is going to have to rope in legal and … and … and …
True, but who owns most of the patents? Some of the most litigious companies on earth (Qualcomm, Broadcom, Cisco). How many legal cases are more expensive than patent litigation?
Also, it’s very simple: Imagine you approach Qualcomm. The script probably goes something like this:
“Sure, we’ll license you that patent, for $0.92 per device, a $25K per month maintenance fee, and compliance with our terms and conditions - chiefly, don’t license this patent to anyone else, and don’t share the source code of your implementation.”
Middleware certainly seems plausible; see also the state of x86 UEFI firmware, which is basically just one company (AMI) selling customized firmware outside of the FOSS coreboot/libreboot world. With how complicated most cellular standards are, I imagine a lot of modem firmware is just one company we've never heard of selling a basic implementation that gets customized for each modem vendor.
Keeping the implementation secret as a condition of licensing the patent is not entirely unimaginable. It would be, however, very, very stupid (if you aren't outright evil), and not provide any extra licensing rents to the SEP holders. In the video world they don't do this; because everyone expects that anyone actually shipping a codec is going to pay[0].
But then again this is also cellular firmware; implementing standards owned by Qualcomm. And Qualcomm loves pushing the boundaries of how anticompetitive you can be with legal monopolies before actually violating competition law. They're the ones that saddled the US with "CDMA" "standards"[1] that put half of America's carriers on incompatible networks with phones you couldn't migrate to other networks. (Even other CDMA networks!) If Qualcomm had their way, they'd own LTE and 5G lock, stock, and barrel with the only modems you can buy being buried in a Qualcomm Snapdragon SoC.
[0] That's not to say that video SEP owners are particularly happy right now. The head of MPEG insists he was sacked for, among other things, complaining about MPEG's inability to standardize a royalty-free codec under ISO's patent disclosure rules.
[1] Including a competing standards body to 3GPP called, I shit you not, 3GPP2.
I honestly just figured it was spectrum licensing. You can’t sell devices that can broadcast at power on just any old frequency. At a hardware level these modems are capable of going well outside the bounds of mobile device regulations. See all the ‘turn xyz into a software defined radio’ hacks that have been done before on other devices on the market.
So the firmware is locked down. To do otherwise will break spectrum licensing as the device then becomes capable of doing things outside the original licensed purpose.
That's probably it, the FCC won't let you sell a device that has a user-accessible method to violate wireless regulations. At most, they could release the source code but not the signing keys so end-users could inspect but not change the firmware.
I'm not too keen on this topic, but router firmware usually asked YOU, what country you (it, the router) resides in to allow or block additional frequencies. No source required.
And then Intel still goes and makes their "automatic geolocation for frequency policy based on neighboring APs" mechanism the default and only policy in their wireless Wi-Fi drivers.
I assume that you're outside of US. Outside of professional FCC-licensed-per-AP equipment, no, you cannot. There is a reason why OpenWRT has a weird limitation on some routers where an EU model is perfectly okay while simultaneously not working with a US model.
Wouldn't the FCC come into play at a later level? We're talking about providing source code to device developers, not end users. As long as the device developers ensure the products they release are locked down, the FCC shouldn't care about it - they only look at the final product as sold to end users.
Both the modem module and the device incorporating the modem module have to be FCC licensed. When I said "FCC won't let you sell a device that has a user-accessible method to violate wireless regulations", I was referring to the modem company selling the modem module to device developers. Sorry for being unclear there.
> So the firmware is locked down. To do otherwise will break spectrum licensing as the device then becomes capable of doing things outside the original licensed purpose.
So what. Take pretty much any older transceiver, swap out the quartz(es) and suddenly what used to be a ham radio can now communicate with police radios, or a commercial radio can be converted for ham use.
Yes, of course the former case is illegal and the latter legal as long as you don't transmit without a callsign and a ham license. But still, radio manufacturers were not required to stop people from doing such mods - to the contrary, up until the 90s it was commonplace to have detailed schematics and BOMs in radios, and it was just as commonplace for people to mod their radios.
I don't get why the FCC is putting up so much pressure on locking down devices ffs.
The FCC generally requires finished devices aimed at the commercial market to be locked down from arbitrary modification. See 47 CFR 15.212(a)(2)(iv) ( https://www.ecfr.gov/current/title-47/part-15#p-15.212(a)(2)... ) As far as I can tell, that basically applies to any transmitter intended for market use.
You have a similar requirement for DFS handling on 5-7Ghz wifi as well, specifically for radar detection and transmission disable when an operating radar is detected: 47 CFR 15.407(i)(1) ( https://www.ecfr.gov/current/title-47/part-15#p-15.407(i)(1) ) -- This version of the requirement is what triggered the wifi aps lockdown issues back in 2016.
The communicated view of the FCC is generally that devices that easily permit operation outside the 'licensed boundaries' essentially become radio nuisances. A plurality of vendors will then essentially act aggressively to lock down their devices. If they don't, the FCC will and has leveraged the FTC to prevent import and impound shipping of such devices. Some other nations do something similar as well.
All that is probably ripe for a Chevron challenge, but even if you have a case that could win in court, taking the FCC to court is fraught, at best. It's definitely not for the faint of heart. In the case of big companies and vendors, where most of the IP for 4G/LTE/5G lives anyway, it would be pretty strictly a commercial mistake to pick that fight.
As for the political reasons they do it, it boils down to funding and the political fights that produced the system of auctioned spectrum and gatekept spectrum we have today. Tearing some of that system down is more likely to succeed. I have no idea what the second and third order effects of that would be though.
As part of our IoT offerings, we tried quite hard to build devices with mobile connectivity about 7 years ago. This was just as low power 5G, NB-IoT and similar technologies were going to become a thing. We gave up because it was too much effort for little return, and it was better to focus on doing things with data, rather than collecting it. Even getting prototypes up with powered fanless PCs (SBCs) and Mini-PCIe or M.2 modems was harder than it should have been - you would think it would be easy with off-the-shelf devices and drivers.
Small Internet connected devices are still needed, despite the perception that IoT is dead. Mobile networks and the modem supply chain are definitely holding the market back. On the plus side, for stationary powered devices most people are happy to connect to wi-fi. For low power devices, LoRa, with private gateways, seems to be a standard. Mobile that is used in outdoor vehicle and asset tracking is still stuck with fighting with modems as per OP.
You might want to take another look, I went through a similar process a couple of years ago, and am now doing it again because our original equipment supplier decided they'd like a life (RIP PC Engines). There's a thriving industry of companies providing fanless ARM based machines either shipping with LTE modems, or with M2 & SIM slots on the board to provide your own.
We install in industrial environments where an accessible internet connection is far from a given, having LTE on all our devices means that we can almost always give the device a way to call home. I can strongly recommend Compulab's devices, which you can purchase as a fully assembled unit that just needs a SIM card put in it (I can't recommend the Linux distribution they run, but you're free to flash them with whatever you'd like).
> There's a thriving industry of companies providing fanless ARM based machines either shipping with LTE modems, or with M2 & SIM slots on the board to provide your own
When I did this about 10 years ago we had quite a number to pick from. Build your own was possible. But that was only because of our organization had the capability and expertise to do it. We settled on 3 off the shelf ones. That was dependent on cost and number of I/O the customer was needing.
DiY basically is 'first make your own computer with the ARM/MIPS/x86 chipsets' then 'spin your own special firmware for it'. Then 'build your own ground up linux distro or similar with compiler chain and SDK to work with it'. You may be able to get someone to sell/give you a reference layout/SDK. Then after all of that. You are now ready to add in a modem. Also prepare for the certifications of all the mobile networks you want to run on. Plus software for you to interact with the cell modem. Oh also you need to work on getting yourself provisioned correctly in the mobile networks. When you do for five devices it is a couple hours of playing with an API. But you probably want hundreds of them so be prepared for managing that, plus billing. Oh also you need to manage EoL for your parts. Many IoT installations are looking at you hanging around for 10+ years.
> Also prepare for the certifications of all the mobile networks you want to run on
AFAIK the modem maker actually does this. You would rather check that the chip is certified for what you need before you buy.
> also you need to work on getting yourself provisioned correctly in the mobile networks
AFAIK also, this is a service provided by "virtual operators", companies that pass deals with the main operators and provide advanced services for machine-to-machine uses, for instance.
But perhaps these didn't exist 10 years ago. Things really started to move where I operate when they EoL'd copper wires.
Yeah, this is all true in my experience. We buy devices with the appropriate Quectel modem for the region, stick a SIM card in from a provider who has relationships with operators worldwide, then ship it to site. Once it gets given some power the device will connect to whatever mobile network has best signal and call home - we don't actually do a lot of international deployments but even within the country it's hugely useful to have SIMs that will happily roam between all the major operators.
Thanks... I'll have another look. I always assumed that device/modem supply would catch up, but they always seemed held back by the established mobile network operators. Also, covid-related supply-chain issues stopped a lot of products in their tracks. We would waited up to a year for modems in some cases. I suppose that has all flushed through the system by now.
Because these aren't regular consumer gadgets. Think more like "lamppost mounted traffic counter", Bluetooth connectivity to a smartphone would be completely useless.
> The number one reason we see customers opt to not use cellular when
> another connectivity option is on the table is due to concerns around
> cost and reliability.
For "reliability" read "availability". Cellular networks are profitable because carriers serve customers that are easy to serve and leave the rest alone. Vehicle 2 Vehicle communications mediated by cellular is a non-starter because people drive a lot in places where cell phones don't work. Wireless internet has been a false hope that's spoiled realistic plans for universal service because it's only affordable in markets that are already served. Large-scale government and corporate IoT programs find that 20% or more of stations are in places without service, etc.
On top of this, there are markets that are not well covered due to local politics. I can go just a few blocks away into a neighborhood that has plenty of density to be interesting to the major carriers but has basically no usable cellular data. A couple years ago, there was a big fight between Crown Castle (big cellular network contractor) and the local government. Crown Castle wanted to build cell towers. The residents wanted service but didn’t want cell towers in their back yard. The government tried, and failed, to avoid issuing permits, because federal law sensibly prevents local government from effectively prohibiting the construction of cell towers.
Win? No! The local government is very proud of itself for having pulled a rabbit out of its hat. It turns out that a cell tower is useless without backhaul, and the government rolled out so much red tape that Crown Castle determined that they would never recover the costs of installing the backhaul and abandoned the entire project. The local government somehow considers this to be a victory.
What I remember in the 3G era was that my MVNO phone [1] worked great in medium sized cites like Rochester, NY but poorly in places with lower density and even worse in the highest density places like NYC and Hollywood. 4G had the capacity to serve super density urban areas really well.
[1] I've got a suspicion that Tracfones ride the back of the bus and get worse service than you'd get with a premium-priced plan.
> Other TracFone brands are up in the air. I have gotten reports of priority data (and seen it myself on SafeLink, a TracFone brand) but I’ve also gotten reports of deprioritized data, complete with screenshots. It seems to be random what people get so if you absolutely require priority data, it might be best to look outside of the TracFone brands.
I think the miserable state of cellular modems ultimately comes from the power dynamics of private spectrum. The 3GPP protocols are complex because they're not really beholden to the implementers, but rather to the network operators. The operators are fine with additional complexity if it serves their interests, and the cost will just be passed on to the OEMs. The network operators have all the power because they're the ones with the licenses.
WiFi tends to be simpler in part because the protocol authors are working more in the interest of the implementers, since it's really they who decide whether to adopt or not. Obviously a gross simplification but I think it's at the heart of the problem.
When GSM was created by the European telcos (at the time they were still monopolies) a lot of care went into making the different parts decoupled with defined standards between the different parts, so that they could pit vendors against each other to avoid getting locked into vendor silos. This contributes a lot to the standards bloat since every interface needs to be defined.
In contrast there were the Qualcomm CMDA standards which were all proprietary and in-house, which had some upsides, but in the end carriers preferred the open standard with vendor competition.
There's a book called "GSM and UMTS: The Creation of Global Mobile Communication" about the history which is really interesting.
Long time ago i worked on WiMAX devices which was a competing standard for the term “4g” from ieee and while it was simpler it wasn’t a whole lot simpler and performance sucked, so there’s that
Hey folks, author here. Appreciate the comments and discussion on the post! Happy to continue the discussion or answer any follow-on questions folks have about our investigation and resolution.
Would just be easier to implement an open source one from scratch given that most IOT modems are just (poorly written) software with an SDR anyway. CEVAwaves or RivieraWaves certainly is.
If it can be done for BLE, 802.15.4 and WiFi, it can be done for cellular; ORAN is enough for base-stations so it's not totally secret. But at the end of the day, aside from the stupid ITU protocols, LTE/5g isn't rocket science. It's bog standard OFDMA radio -- nothing fancy these days.
I ended up reverse engineering parts of Sony's Altair derived modems but got bored, maybe I should publish that
Good read thanks. To the point of having a open platform, they would probably lose their monopoly. I could then just spin up my own mobile network and provide service like a wifi network with any credentials and do what I want.
I guess there needs to be a big initial effort with lots of maintaining afterwards. If everything goes as expected the AIs could provide that in the future.
The complaint is that people cannot connect, and that hardware vendors dont want to go down the pit of other peoples sh*(blobs).
Magnificent article. Clearly shows his expertise going down the sh*/rabbit hole, the more I read, the more dismal it got.
Clearly the way to get around the technical side of the DNS bug, is to do what cell providers do: Start the device in the office of the provider, and let the DNS resolve there, and if it does not work, get a ticket started right then and there.
Out in the field... use another devices Wifi, and do the same thing.
If you cannot get cell phone service or Wifi, then ( I literally took about 45 mins on the phone to T-Mobile, which immediately refused to take responsibility, and also refused to put anything in writing: Then their recommendation is to get a satellite link with, StarLink!. I would rather be slapped in the face with a cold fish.
Cell phone service providers all let this happen, until of course they almost all sold out to T-Moble. ( LifeLine, Assurnace, etc.. )
Second, it made me think about the new Apple C1 modem. They must have had to comb through those specs as well, and it makes me wonder if will allow them to better integrate the modem in the kernel in the end?
> The patents are referred to as Standards Essential Patents, or SEPs. Because of this arrangement, a vendor like Nordic probably can’t open source their modem firmware even if they wanted to.
Why would a SEP license forbid publishing modem firmware? The IP[0] involved with the modem firmware is copyrighted and trade secret material; publishing the firmware does not (and cannot) grant a patent license to those licensed standards-essential patents. It only imperils your implementation of the modem firmware, not the whole patent spec.
To wit, Cisco publishes an H.264 codec with BSD-licensed code, even though H.264 is under a shitload of patents that they are licensing. OpenH264 does ship with an additional patent sublicense that applies if you are using their build and installing it in a specific way, but that is particular to MPEG-LA's licensing structure[1]. Publishing an implementation of a patent you are licensing does not automatically sublicense the patent.
[0] Laws that grant the ability to dictate the conduct of your competitors
[1] Cisco is abusing(?) the MPEG-LA royalty fee cap to shield FOSS entities from having to take a license, basically, by paying for them.
> Why would a SEP license forbid publishing modem firmware?
Contracts and money.
> The IP[0] involved with the modem firmware is copyrighted and trade secret material; publishing the firmware does not (and cannot) grant a patent license to those licensed standards-essential patents. It only imperils your implementation of the modem firmware, not the whole patent spec.
Publishing the source to the firmware would allow people to make use of patented tech without paying for it even though it would be illegal to do so. Also, your license may simply stipulate that you cannot publish or share your code in anyway outside the company.
> To wit, Cisco publishes an H.264 codec with BSD-licensed code, even though H.264 is under a shitload of patents that they are licensing. > Cisco is abusing(?) the MPEG-LA royalty fee cap to shield FOSS entities from having to take a license, basically, by paying for them.
As you point out here, Cisco is paying for it. They publish open code, and to ensure the LA doesn't come after them, they're paying additional money.
MPEG-LA also explicitly used to (I do not know current state) consider open source "some assembly required" releases to be non-infringing.
It was product incorporating the patented tech, i.e. ready to use binaries, that required licensing.
Cisco paid the licensing fees to enable easily downloadable h.264 codec for certain projects, but you could legally build it from source yourself.
IIRC h.265 had similar licensing
Exactly.
Cisco is paying for the binary provided. Not the source code. There are plenty of patented and open source. Every H.264, H.265, H.266 Encoder and Decoder in existence and used.
There are also plenty of open source 4G and 5G software implementation.
I sometimes wonder if I should just give up the fight for patent misinformation. On HN it is very binary, either good or bad. And all patents and Ads are evil.
There's also the possibility of trade secrets being involved. An example hypothetical: Maybe Qualcomm has tons of lab data showing signal performance and integrity for any given channel, band, power level, general environment (urban, suburban, rural), device position, device altitude, etc.
You might want to use that data, and algorithms derived from it, to improve your device's battery life. That data obviously cannot be patented, and while the lab data would be copyrighted and not part of the finished product, Qualcomm would understandably be mighty particular about any open-source code implementing the conclusions.
I suspect a big reason is that there’s middleware: some of this stuff is so complex, that like video games, there’s probably a cottage industry of companies selling partially implemented bits and pieces, or licensing across companies of source code, or companies only licensing the patents if you agree to never release code. There’s also the IP angle: if you do manage to figure it out, there’s no honor helping Huawei.
> I suspect a big reason is that there’s middleware
I’d bet it’s simpler. Saying “yes” to the ‘can we share this outside of this company?’ Question means a lot of work and meetings and red tape and somebody is going to have to rope in legal and … and … and …
Or, “no, get back to work”.
True, but who owns most of the patents? Some of the most litigious companies on earth (Qualcomm, Broadcom, Cisco). How many legal cases are more expensive than patent litigation?
Also, it’s very simple: Imagine you approach Qualcomm. The script probably goes something like this:
“Sure, we’ll license you that patent, for $0.92 per device, a $25K per month maintenance fee, and compliance with our terms and conditions - chiefly, don’t license this patent to anyone else, and don’t share the source code of your implementation.”
Middleware certainly seems plausible; see also the state of x86 UEFI firmware, which is basically just one company (AMI) selling customized firmware outside of the FOSS coreboot/libreboot world. With how complicated most cellular standards are, I imagine a lot of modem firmware is just one company we've never heard of selling a basic implementation that gets customized for each modem vendor.
Keeping the implementation secret as a condition of licensing the patent is not entirely unimaginable. It would be, however, very, very stupid (if you aren't outright evil), and not provide any extra licensing rents to the SEP holders. In the video world they don't do this; because everyone expects that anyone actually shipping a codec is going to pay[0].
But then again this is also cellular firmware; implementing standards owned by Qualcomm. And Qualcomm loves pushing the boundaries of how anticompetitive you can be with legal monopolies before actually violating competition law. They're the ones that saddled the US with "CDMA" "standards"[1] that put half of America's carriers on incompatible networks with phones you couldn't migrate to other networks. (Even other CDMA networks!) If Qualcomm had their way, they'd own LTE and 5G lock, stock, and barrel with the only modems you can buy being buried in a Qualcomm Snapdragon SoC.
[0] That's not to say that video SEP owners are particularly happy right now. The head of MPEG insists he was sacked for, among other things, complaining about MPEG's inability to standardize a royalty-free codec under ISO's patent disclosure rules.
[1] Including a competing standards body to 3GPP called, I shit you not, 3GPP2.
I honestly just figured it was spectrum licensing. You can’t sell devices that can broadcast at power on just any old frequency. At a hardware level these modems are capable of going well outside the bounds of mobile device regulations. See all the ‘turn xyz into a software defined radio’ hacks that have been done before on other devices on the market.
So the firmware is locked down. To do otherwise will break spectrum licensing as the device then becomes capable of doing things outside the original licensed purpose.
That's probably it, the FCC won't let you sell a device that has a user-accessible method to violate wireless regulations. At most, they could release the source code but not the signing keys so end-users could inspect but not change the firmware.
I'm not too keen on this topic, but router firmware usually asked YOU, what country you (it, the router) resides in to allow or block additional frequencies. No source required.
And then Intel still goes and makes their "automatic geolocation for frequency policy based on neighboring APs" mechanism the default and only policy in their wireless Wi-Fi drivers.
I assume that you're outside of US. Outside of professional FCC-licensed-per-AP equipment, no, you cannot. There is a reason why OpenWRT has a weird limitation on some routers where an EU model is perfectly okay while simultaneously not working with a US model.
Wouldn't the FCC come into play at a later level? We're talking about providing source code to device developers, not end users. As long as the device developers ensure the products they release are locked down, the FCC shouldn't care about it - they only look at the final product as sold to end users.
Both the modem module and the device incorporating the modem module have to be FCC licensed. When I said "FCC won't let you sell a device that has a user-accessible method to violate wireless regulations", I was referring to the modem company selling the modem module to device developers. Sorry for being unclear there.
> So the firmware is locked down. To do otherwise will break spectrum licensing as the device then becomes capable of doing things outside the original licensed purpose.
So what. Take pretty much any older transceiver, swap out the quartz(es) and suddenly what used to be a ham radio can now communicate with police radios, or a commercial radio can be converted for ham use.
Yes, of course the former case is illegal and the latter legal as long as you don't transmit without a callsign and a ham license. But still, radio manufacturers were not required to stop people from doing such mods - to the contrary, up until the 90s it was commonplace to have detailed schematics and BOMs in radios, and it was just as commonplace for people to mod their radios.
I don't get why the FCC is putting up so much pressure on locking down devices ffs.
The FCC generally requires finished devices aimed at the commercial market to be locked down from arbitrary modification. See 47 CFR 15.212(a)(2)(iv) ( https://www.ecfr.gov/current/title-47/part-15#p-15.212(a)(2)... ) As far as I can tell, that basically applies to any transmitter intended for market use.
You have a similar requirement for DFS handling on 5-7Ghz wifi as well, specifically for radar detection and transmission disable when an operating radar is detected: 47 CFR 15.407(i)(1) ( https://www.ecfr.gov/current/title-47/part-15#p-15.407(i)(1) ) -- This version of the requirement is what triggered the wifi aps lockdown issues back in 2016.
The communicated view of the FCC is generally that devices that easily permit operation outside the 'licensed boundaries' essentially become radio nuisances. A plurality of vendors will then essentially act aggressively to lock down their devices. If they don't, the FCC will and has leveraged the FTC to prevent import and impound shipping of such devices. Some other nations do something similar as well.
All that is probably ripe for a Chevron challenge, but even if you have a case that could win in court, taking the FCC to court is fraught, at best. It's definitely not for the faint of heart. In the case of big companies and vendors, where most of the IP for 4G/LTE/5G lives anyway, it would be pretty strictly a commercial mistake to pick that fight.
As for the political reasons they do it, it boils down to funding and the political fights that produced the system of auctioned spectrum and gatekept spectrum we have today. Tearing some of that system down is more likely to succeed. I have no idea what the second and third order effects of that would be though.
As part of our IoT offerings, we tried quite hard to build devices with mobile connectivity about 7 years ago. This was just as low power 5G, NB-IoT and similar technologies were going to become a thing. We gave up because it was too much effort for little return, and it was better to focus on doing things with data, rather than collecting it. Even getting prototypes up with powered fanless PCs (SBCs) and Mini-PCIe or M.2 modems was harder than it should have been - you would think it would be easy with off-the-shelf devices and drivers.
Small Internet connected devices are still needed, despite the perception that IoT is dead. Mobile networks and the modem supply chain are definitely holding the market back. On the plus side, for stationary powered devices most people are happy to connect to wi-fi. For low power devices, LoRa, with private gateways, seems to be a standard. Mobile that is used in outdoor vehicle and asset tracking is still stuck with fighting with modems as per OP.
You might want to take another look, I went through a similar process a couple of years ago, and am now doing it again because our original equipment supplier decided they'd like a life (RIP PC Engines). There's a thriving industry of companies providing fanless ARM based machines either shipping with LTE modems, or with M2 & SIM slots on the board to provide your own.
We install in industrial environments where an accessible internet connection is far from a given, having LTE on all our devices means that we can almost always give the device a way to call home. I can strongly recommend Compulab's devices, which you can purchase as a fully assembled unit that just needs a SIM card put in it (I can't recommend the Linux distribution they run, but you're free to flash them with whatever you'd like).
> There's a thriving industry of companies providing fanless ARM based machines either shipping with LTE modems, or with M2 & SIM slots on the board to provide your own
When I did this about 10 years ago we had quite a number to pick from. Build your own was possible. But that was only because of our organization had the capability and expertise to do it. We settled on 3 off the shelf ones. That was dependent on cost and number of I/O the customer was needing.
DiY basically is 'first make your own computer with the ARM/MIPS/x86 chipsets' then 'spin your own special firmware for it'. Then 'build your own ground up linux distro or similar with compiler chain and SDK to work with it'. You may be able to get someone to sell/give you a reference layout/SDK. Then after all of that. You are now ready to add in a modem. Also prepare for the certifications of all the mobile networks you want to run on. Plus software for you to interact with the cell modem. Oh also you need to work on getting yourself provisioned correctly in the mobile networks. When you do for five devices it is a couple hours of playing with an API. But you probably want hundreds of them so be prepared for managing that, plus billing. Oh also you need to manage EoL for your parts. Many IoT installations are looking at you hanging around for 10+ years.
> Also prepare for the certifications of all the mobile networks you want to run on
AFAIK the modem maker actually does this. You would rather check that the chip is certified for what you need before you buy.
> also you need to work on getting yourself provisioned correctly in the mobile networks
AFAIK also, this is a service provided by "virtual operators", companies that pass deals with the main operators and provide advanced services for machine-to-machine uses, for instance.
But perhaps these didn't exist 10 years ago. Things really started to move where I operate when they EoL'd copper wires.
Yeah, this is all true in my experience. We buy devices with the appropriate Quectel modem for the region, stick a SIM card in from a provider who has relationships with operators worldwide, then ship it to site. Once it gets given some power the device will connect to whatever mobile network has best signal and call home - we don't actually do a lot of international deployments but even within the country it's hugely useful to have SIMs that will happily roam between all the major operators.
> I can strongly recommend Compulab
Thanks for the rec. This board looks promising, including Debian/Yocto support, and they apparently have an option for hardware customization, https://www.compulab.com/products/sbcs/sbc-iot-imx8plus-nxp-...
Thanks... I'll have another look. I always assumed that device/modem supply would catch up, but they always seemed held back by the established mobile network operators. Also, covid-related supply-chain issues stopped a lot of products in their tracks. We would waited up to a year for modems in some cases. I suppose that has all flushed through the system by now.
Seconding this about Compulab. If they made a box with a Marvell CN9130 it would be really nice.
Agreed, would be good to have an alternative to Solidrun.
On the consumer side, QNAP offers both a NAS and network switch based on Marvell CN9130.
Why mobile connectivity instead of Bluetooth?
As an end user, I prefer my devices use Bluetooth and a hub device like a phone or laptop, rather than each one have a direct mobile connection.
Because these aren't regular consumer gadgets. Think more like "lamppost mounted traffic counter", Bluetooth connectivity to a smartphone would be completely useless.
Heh, thanks for that oddly-specific example that is an exact device that I worked on a few years back :)
> The number one reason we see customers opt to not use cellular when > another connectivity option is on the table is due to concerns around > cost and reliability.
For "reliability" read "availability". Cellular networks are profitable because carriers serve customers that are easy to serve and leave the rest alone. Vehicle 2 Vehicle communications mediated by cellular is a non-starter because people drive a lot in places where cell phones don't work. Wireless internet has been a false hope that's spoiled realistic plans for universal service because it's only affordable in markets that are already served. Large-scale government and corporate IoT programs find that 20% or more of stations are in places without service, etc.
On top of this, there are markets that are not well covered due to local politics. I can go just a few blocks away into a neighborhood that has plenty of density to be interesting to the major carriers but has basically no usable cellular data. A couple years ago, there was a big fight between Crown Castle (big cellular network contractor) and the local government. Crown Castle wanted to build cell towers. The residents wanted service but didn’t want cell towers in their back yard. The government tried, and failed, to avoid issuing permits, because federal law sensibly prevents local government from effectively prohibiting the construction of cell towers.
Win? No! The local government is very proud of itself for having pulled a rabbit out of its hat. It turns out that a cell tower is useless without backhaul, and the government rolled out so much red tape that Crown Castle determined that they would never recover the costs of installing the backhaul and abandoned the entire project. The local government somehow considers this to be a victory.
What I remember in the 3G era was that my MVNO phone [1] worked great in medium sized cites like Rochester, NY but poorly in places with lower density and even worse in the highest density places like NYC and Hollywood. 4G had the capacity to serve super density urban areas really well.
[1] I've got a suspicion that Tracfones ride the back of the bus and get worse service than you'd get with a premium-priced plan.
https://www.reddit.com/r/NoContract/comments/1cyfjpp/data_pr...
> Other TracFone brands are up in the air. I have gotten reports of priority data (and seen it myself on SafeLink, a TracFone brand) but I’ve also gotten reports of deprioritized data, complete with screenshots. It seems to be random what people get so if you absolutely require priority data, it might be best to look outside of the TracFone brands.
https://en.wikipedia.org/wiki/QoS_Class_Identifier
I think the miserable state of cellular modems ultimately comes from the power dynamics of private spectrum. The 3GPP protocols are complex because they're not really beholden to the implementers, but rather to the network operators. The operators are fine with additional complexity if it serves their interests, and the cost will just be passed on to the OEMs. The network operators have all the power because they're the ones with the licenses.
WiFi tends to be simpler in part because the protocol authors are working more in the interest of the implementers, since it's really they who decide whether to adopt or not. Obviously a gross simplification but I think it's at the heart of the problem.
Vendors wrote those standards though, not the operators. They are complex because it’s a defensive moat against competition imho
They are complex because, usually, they are a union of everything every vendor in the consortium has done and/or wants to do.
Looking at the overview of the architecture on the network side [1] tells the tale, I think.
My take is that telecom operators forcefully had to evolve from Morse and copper to IP and radio, hacking stuff left and right every step of the way.
[1] https://en.wikipedia.org/wiki/IP_Multimedia_Subsystem#Archit...
When GSM was created by the European telcos (at the time they were still monopolies) a lot of care went into making the different parts decoupled with defined standards between the different parts, so that they could pit vendors against each other to avoid getting locked into vendor silos. This contributes a lot to the standards bloat since every interface needs to be defined.
In contrast there were the Qualcomm CMDA standards which were all proprietary and in-house, which had some upsides, but in the end carriers preferred the open standard with vendor competition.
There's a book called "GSM and UMTS: The Creation of Global Mobile Communication" about the history which is really interesting.
Long time ago i worked on WiMAX devices which was a competing standard for the term “4g” from ieee and while it was simpler it wasn’t a whole lot simpler and performance sucked, so there’s that
Hey folks, author here. Appreciate the comments and discussion on the post! Happy to continue the discussion or answer any follow-on questions folks have about our investigation and resolution.
Would just be easier to implement an open source one from scratch given that most IOT modems are just (poorly written) software with an SDR anyway. CEVAwaves or RivieraWaves certainly is.
If it can be done for BLE, 802.15.4 and WiFi, it can be done for cellular; ORAN is enough for base-stations so it's not totally secret. But at the end of the day, aside from the stupid ITU protocols, LTE/5g isn't rocket science. It's bog standard OFDMA radio -- nothing fancy these days.
I ended up reverse engineering parts of Sony's Altair derived modems but got bored, maybe I should publish that
Good read thanks. To the point of having a open platform, they would probably lose their monopoly. I could then just spin up my own mobile network and provide service like a wifi network with any credentials and do what I want.
I guess there needs to be a big initial effort with lots of maintaining afterwards. If everything goes as expected the AIs could provide that in the future.
The complaint is that people cannot connect, and that hardware vendors dont want to go down the pit of other peoples sh*(blobs).
Magnificent article. Clearly shows his expertise going down the sh*/rabbit hole, the more I read, the more dismal it got.
Clearly the way to get around the technical side of the DNS bug, is to do what cell providers do: Start the device in the office of the provider, and let the DNS resolve there, and if it does not work, get a ticket started right then and there.
Out in the field... use another devices Wifi, and do the same thing.
If you cannot get cell phone service or Wifi, then ( I literally took about 45 mins on the phone to T-Mobile, which immediately refused to take responsibility, and also refused to put anything in writing: Then their recommendation is to get a satellite link with, StarLink!. I would rather be slapped in the face with a cold fish.
Cell phone service providers all let this happen, until of course they almost all sold out to T-Moble. ( LifeLine, Assurnace, etc.. )
Wow that was quite the technical deep dive! I bet there's not one person in the world who understands all the interactions in this system.
I too greatly enjoyed the article. Love those deep troubleshooting write-ups!
First, it was quite interesting!
Second, it made me think about the new Apple C1 modem. They must have had to comb through those specs as well, and it makes me wonder if will allow them to better integrate the modem in the kernel in the end?
It's [almost] always DNS :)
[dead]