For the sake of argument, let’s assume that such a module actually existed, or that its hardware design would not be difficult. Even assume that the production logistics are solved for a small batch of such boards. Then from my perspective, the key challenge would be the development of the drivers. It’s incredible how much time can be wasted with supposedly trivial AT commands…
The u-blox modules support AT commands for TCP, among other things. But they will not allow using the full bandwidth of the 3G connection - not even close. Even a very slow connection can be fully sufficient for many “sample a couple of sensor values a day and send them to the cloud” applications. Indeed, even SMS are often sufficient.
But if you need more of the module’s speed, then PPP would be the way to go. You’d first need to multiplex the PPP stream with an AT command stream, i.e., implement a non-trivial 3GPP multiplexing protocol first. Then find or write a good PPP implementation. I don’t really trust lwIP for its built-in PPP support. Then we’d need a solid integration into NETMF, preferably a much better one than the job Microsoft did with the TCP and UDP integration of lwIP.
To create a high-quality implementation of the 3GPP/PPP protocol combo, I’d budget three to six person months for an experienced embedded developer, though I could well be wrong in this estimate (or guess, rather). This could easily add $100 per board or more in software engineering costs.
As we’d need a TCP stack on the mainboard for PPP (not necessary with the TCP AT command approach), I wonder how difficult it would be to extend mIP for this…
Don’t get me wrong, I’d love to see such a driver. I’m not at all hesitant regarding the hardware challenges. I’d just like to see where the driver may come from. If this is solved, we may be able to actively help with the other aspects of such a project.