8 ms·
We Can Stop Pretending LTE-M Is a Low-Power WAN
- bsder 8y agoThis is the kind of blather I expect from business types without hardware experience. The issue with NB-IoT right now is chicken vs egg. NB-IoT stuff currently is limited to expensive modules. Why? Because the carriers aren't rolling this out yet and when it is it's expensive. So, nobody is going to make a chip for it since the volume isn't going to be there for a while (Intel, for example, just pulled out of making NB-IoT chips). So, the badly integrated systems are going to be battery hungry and expensive, which means that the carriers don't see any volume and consequently don't feel the need to work very hard rolling it out. Once the carriers finally get NB-IoT stuff universally deployed (even if it's expensive) then the silicon vendors will go to work on integrating everything into a single chip. Once that happens, someone will say: "Hi, T-Mobile, I have 10 million devices I would like to activate and connect. Would you like to do this or should I go talk to Verizon, AT&T, etc." and the prices will come down. This will follow the same trajectory as cellular data vs cellular voice.
- StudentStuff 8y agoIntel pulling out is far from a canary in the coal mine. The rest of your post is fairly accurate though! Background: Intel has serious production issues with their latest 10nm process, meaning their x86 chips and LTE modems for Apple are filling most of their capacity to manufacture chips on the existing 14nm process. I doubt Intel has LTE modem designs that work on older processes, and NB-IOT being unproven, low volume and needing low power chips means it could really use the best process available. Thus, with no slack capacity to build chips, why spend engineering time on something you can't build in quantity? If 10nm were usable, Intel would likely have numerous side projects filling their older 14nm fabs. Sadly this won't be the case for Intel anytime soon.
- evancox100 8y agoActually, ultra-low power devices (ie months-/years-long battery life) are probably better suited for older technology nodes, say 40+ nm for bulk, or 22+ nm for SoI. Standby leakage power is going to be too high on the lower nodes. Lasting months/years on a coin cell means sub-1 uA standby combined with infrequent, short-lived wake cycles. There's no real way around this until you go to energy harvesting, and right now that's limited to very very low power, single-function devices.
- jpnorair 8y agoExcellent post -- a rarely understood truth. For low power wireless systems, still, though, the bulk of the energy is spent in TX and RX. But realistically the quiescent power drain still needs to be in the sub 5uW range to deliver long life on a small battery. A lot of GNSS and LTE SoC's standby in the 50uW range, which is just too much. Most of the LTE devices I've surveyed (M1, NB-IoT) are expected to be attached to MCUs, but they implement internally a small linux platform. Obviously, that makes it hard to get down to 5 uW.
- bsder 8y ago> For low power wireless systems, still, though, the bulk of the energy is spent in TX and RX. That is very highly dependent upon the system. Some systems are all about leakage--these spend most of their lifetime on a shelf and a couple of days actually active. Some systems are all about sensors or actuators and the communication is in the noise. Some systems are all about calling home, and those require good TX consumption.
- jessaustin 8y agoWhat will prompt carriers to roll this out?
- anmorgan 8y agoI am excited to see this come out: https://www.nordicsemi.com/eng/Products/Low-Power-Cellular-IoT/nRF91-SiP-Series https://www.nordicsemi.com/eng/Products/Low-Power-Cellular-I... Seems promising, but I don't see the current consumption documented anywhere yet.
- diamondo25 8y agoWe at Hiber [0] are working on an actual low-power solution, which will give the device a way to transmit once a day to a sattelite with a custom 144 bytes user payload. The device location is already encoded, so you can focus on filling those 144 bytes with anything you'd like. You'll have global coverage and a central system to extract the data. [0] https://hiber.global/ https://hiber.global/
- sgt 8y agoWe would like to evaluate this. Currently looking at Sigfox, space.fleet and others. I sent a message via the Hiber contact page.
- femto 8y agoYou might also be interested in http://myriota.com/ http://myriota.com/ It's essentially a long life "tag" (10 years depending on duty cycle) that can read sensors and go direct to satellite. Funded by Boeing. I'm not involved in the company, but in the last 20 years have regularly crossed paths with one of the founders at Information Theory conferences. He's a very smart guy.
- bborud 8y agoIf you want to experiment with LoRaWAN, we open sourced our Network Service: https://github.com/exploratoryengineering/congress https://github.com/exploratoryengineering/congress We also open sourced our module design (EE-02) that uses nRF52 as the MCU: https://github.com/ExploratoryEngineering/ee0x-hardware https://github.com/ExploratoryEngineering/ee0x-hardware You can buy the modules here, but I think stocks might be running low. (However, if anyone needs larger numbers of modules we can put you into contact with the factory we use for manufacturing them): https://shop.exploratory.engineering/ https://shop.exploratory.engineering/
- orion138 8y agoCan you recommend a good write up on LoraWan architecture? (Curious about the need for a network service). Cheers!
- barbegal 8y agoI would love to see an actual low power, long range system: a cross between Bluetooth low energy and LTE. Allow devices to transmit at a higher power than Bluetooth and with much smaller receiver on time than LTE.
- gh02t 8y agoIsn't that exactly what Sigfox and LoRaWAN are?
- Steltek 8y agoDuplex? Scheduled or unscheduled transmissions? What about LoRaWAN?
- jpnorair 8y agoThat's a really hard problem to solve, which is why you don't see lots of solutions. DASH7 has been around for a few years, and it addresses the technical aspects of this problem, although it still probably needs another year to mature to the point where it's easy to integrate. But if you have a high volume application, it's an option.
- dfox 8y agoThe thing is that LTE-M allows you to have real IP connectivity in contrast to other true LPWAN technologies built on datagrams that are sufficiently small that any real cryptography is non-trivial challenge and can be transmited once each minute/hour/day. If there is any unserviced niche it is in duplex bursts of realtime traffic (ie. what you usually get for satellite telematics, but for IoT it has to be few orders of magnitude cheaper)
- jpnorair 8y agoA few things. (1) If the payload is shorter than the key length (e.g. 128 bits) then crypto is actually really strong (and easy). For long payloads, you need to work a lot harder. (2) For doing a public key handshake, you can do it without a huge packet using one of the elliptical curve algos, but for any public key handshake you need a reasonably short duration of the handshake in order for it to be adequately secure. That's a bigger challenge than the data size. Low power LTE Cat M1 or NB-IoT systems aren't any better at practically serving low latency sessions than most LPWANs are. (3) "secure elements" should be called "insecure elements" when the items they are installed in are remotely operated in public environments. (4) Carriers tend to use TCP/IP with LTE, which is more of a limitation than a benefit, because it prevents any manner of broadcasting. There are a lot of applications that can be low power if they are broadcasted, but will never be low power (or easy) via TCP. (5) The direction LTE has gone, in my opinion, makes it undesirable for a lot of applications. It is nice for low-volume monitoring applications. So in a sense I think LTE as a LPWAN is really the great solution for niche use-cases.
- tialaramex 8y agoYour claim (1) looks a lot like hubris to me unless you're imagining a product that sends only a single payload during its lifetime.
- dfox 8y agoOn another note, GPS tracker is probably wrong application for this assesment as I would believe that GPS receiver has significantly larger power consumption than LTE-M radio.
- jpnorair 8y agoNo, it's usually much less for GNSS. The secret to low power GNSS is to find a way not to have the receiver on much of the time, but that's very possible. LTE has less flexibility in overhead energy, because there's overhead enforced by the network.
- HIPisTheAnswer 8y agoIf it isn't open source, it can't optimize power efficiency up and down the stack.
- chrisfinazzo 8y agoLet's be honest, LTE was always oversold in terms of its technical limitations. The first reference to it that I can recall seeing (years ago) actually was describing LTE Advanced (~150 Mb/s), but conveniently left out that information. I know that it had been shown in testing to reach 200 Mb/s - call me when real world usage data can show that kind of result. In reality, the kind of progress that @barbegal mentions has done more to advance device capabilities, but for something that was initially sold as a 10x speed improvement over 3GPP, it hasn't really panned out. The telecom folks make a bunch of noise about how you can replace a home connection with these kinds of technologies, but until prices come down and speeds go (way) up, the wireline people don't have much to worry about.
- Shelnutt2 8y agoLTE Advanced with carrier aggregation can certainly deliver on speeds. Here is a fresh speedtest taken just now, were I'm getting 185Mbps down. I'm inside a building but only 1 block from the cell site and I'm getting 3x Carrier Aggregation on 2.5GHz (band 41) on Sprint. I'll admit these are pretty ideal circumstances for a speed test but I just opened the app an ran it to show the speeds are possible. I've often found the most limiting factor (beside RF interference) is not LTE directly but the backhaul connections at cell sites. If you only have a 1 gig ethernet link, that limits your speeds when you get a handful of active users. http://www.speedtest.net/my-result/a/4239773416 http://www.speedtest.net/my-result/a/4239773416
- rayiner 8y agoI’ve gotten 150 mbps down using the Ookla Speedtest app on my iPhone 6s at the strip mall nearest to me. (Nowhere special, suburban Annapolis.) Tried it just now at my house on my iPhone SE: 29 mbps down, 28 msec ping. One floor right above my Wifi router, I’m getting just 30 mbps (7 msec ping however) over Wifi, so the LTE performance isn’t too shabby.
- chrisfinazzo 8y agoThat's fair, although I suspect the infrastructure is more developed in certain areas because the Naval Academy is there. The SE result is pretty typical from what I've seen. When I only had 25/5, I'd be really excited by such a thing, but 100/35 has ruined me.
- keithnz 8y agoNo idea why this article takes the view it does on LTE based on 1 device? ... We do low power data loggers on 3G and now just starting doing LTE, and power usage is really good for LTE compared to 3G. We aren't rechargeable (though we do have options for that), and we do 3+ years depending on the scenario. We have 1000s of devices in the field and have been doing this for quite a number of years. LTE is going to let us do more for the same life span, or the same for a longer lifespan.
- mahesh_rm 8y agoHi Keith, I am interested, who is "we"?
- mrlambchop 8y agoI'm just in the middle of launching an LTE-M based device that contains a primary power source (a 12v vehicle battery) with a supercap for backup power when the battery dies. Average power at the moment is around ~3mA to keep an LTE-M module (using a QCOM chipset) connected to the network in DRX mode. Bandwidth wise, LTE-M gives us between 500bytes and 3.5KBs per second on the AT&T network - its not terrible and the byte cost is also "low" from AT&T. LTE-M network coverage is good - same as AT&T LTE as far as we can tell (as LTE-M is just an extension to the basestation feature set and doesn't need new infrastructure). Only when AT&T starts to support eDRX and PSM will "a month long" battery be realizable for portable products like this.
- ausjke 8y agothat's absolutely true, the real low-power is LoRA technically, it's just that LORA is too small comparing to all these cellular giants. maybe Amazon or some other big guy interested in IoT should acquire LoRA, then for low-power use cases, LTE-M has absolutely no chance.
- jsjohnst 8y agoI’ve done a lot of prototyping with LTE, GPRS, LTE-M, and NB-LTE chipsets (along with having previously worked for a Bluetooth tracker company) and I think this article is making a false conclusion. The terrible battery life of these example products is much more caused by the power devouring GPS or a lack of adequate battery capacity in these products than by the LTE-M chipset.
- MrQuincle 8y agoIf you think so, you've to state what the power use was of the chipsets you've used. For example the well-known nRF51: https://devzone.nordicsemi.com/f/nordic-q-a/1657/how-to-minimize-current-consumption-for-ble-application-on-nrf51822 https://devzone.nordicsemi.com/f/nordic-q-a/1657/how-to-mini.... It can be as low as 20 uA. Between advertisements 4 uA.
- ctz 8y agoEr, what relevance does BLE power consumption have to LTE-M, NBIOT, etc.?
- MrQuincle 8y agoMmm. That's the thesis of the article? "This mobile tracker is seemingly designed to resemble a popular Bluetooth tracker and sports a LTE-M radio and GPS receiver. But as mentioned here and here, a leopard can’t change its spots." They try to be as low power as a Bluetooth tracker, but they just can't. It will never be actually low power.
- PaulHoule 8y agoI'd be amazed that anything with a GPS in it would last seven days, never mind any other radios that are in it.
- peburns 8y agoHow about a LPWAN endpoint with GPS that last 2+ years? Like this: http://bit.ly/2pBcYqp http://bit.ly/2pBcYqp