
We Can Stop Pretending LTE-M Is a Low-Power WAN - peburns
https://medium.com/@patburns/the-joke-is-over-we-can-stop-pretending-lte-m-is-a-lpwan-683020fcb3b5
======
mrlambchop
I'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.

------
diamondo25
We 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
We would like to evaluate this. Currently looking at Sigfox, space.fleet and
others. I sent a message via the Hiber contact page.

~~~
bborud
If 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/)

~~~
MrQuincle
Nice!! Cool that it's open hardware. What's your business model considering
you don't want someone buying large numbers from you? :-)

~~~
bborud
You have no idea how often I am asked that :-)

We work for a telco, and this was just a learning exercise to understand the
opportunities and challenges with LPWA. While waiting for NB-IoT chipsets and
network rollout. We mostly set up the shop to have a orderly way for people to
get the devices from us if they want to experiment (free stuff has a tendency
to end up lining people's drawers unused)

We built everything from (and including) the devices to the applications, and
everything inbetween minus the LoRa gateway. The attitude being "okay we can
read a bunch of datasheets and PPT-decks, but we're not going know anything
unless we get hands on". So we did.

The modules were just to get the radio and MCU bits into a reusable module
which we then used for about a dozen or so prototypes. We run Apache MyNewt on
them (the EE-02 was actually used to develop LoRa support for MyNewt).

Since Nordic Semiconductor are in the same building the nRF52 was a pretty
obvious choice (I think we might have been the first customer). They make
lovely chips. And I'm not getting paid to say that :-).

We did think about building a gateway as well, but we felt it didn't add much
to the exercise.

And now? Now we are doing the whole exercise again for NB-IoT, but this time
it is to apply what we've learnt. That being said: we plan to open source
stuff in the future. Both hardware and software.

~~~
MrQuincle
Nice! How can we stay up to date?

~~~
bborud
We have a blog where the team occasionally posts updates.

[https://blog.exploratory.engineering/](https://blog.exploratory.engineering/)

------
chrisfinazzo
Let'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.

~~~
rayiner
I’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
That'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.

------
bsder
This 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
Intel 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
Actually, 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
Excellent 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
> 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.

------
dfox
The 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
A 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
Your claim (1) looks a lot like hubris to me unless you're imagining a product
that sends only a single payload during its lifetime.

------
jsjohnst
I’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
If 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-mini...](https://devzone.nordicsemi.com/f/nordic-q-a/1657/how-
to-minimize-current-consumption-for-ble-application-on-nrf51822). It can be as
low as 20 uA. Between advertisements 4 uA.

~~~
KaiserPro
its down to duty cycle. That figure is the average consumption. I can make
most chipsets consume 20uA, its trivial, just don't take them out of
hibernation.

LTE-M is a high(well couple of kilobytes per second) bandwidth, full duplex,
high duty cycle transport layer. Not only that, its relatively long distance
(well kinda)

Bluetooth is short range < 30m, and at high bandwidth shorter range. yes it
can be full duplex, but not at low power (I've not validated that claim
though) The BLE beacons don't emit a location every 4 seconds, they also don't
have a GPS on all the time eating 35mah.

Lora has a maximum duty cycle of something like 5% (ie it has to be not
transmitting 95% of the time) not only that, its not designed for realtime two
way communications, It's niche is a sensor reporting the state of a sensor
every n minutes.

~~~
MrQuincle
You won't be able to achieve the BLE figures with cellular technology. (Even
without GPS. )

You just basically say so by explaining how much higher the bandwidth is.

The thesis of the author of this article still stands. It's not just GPS.

~~~
KaiserPro
I can, if I don't turn it on, which is where the 20uA figure comes from,
keeping the device in hibernation

~~~
jsjohnst
Exactly. Duty cycle is something we had to be very aggressive about even on
the BLE side.

------
keithnz
No 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
Hi Keith, I am interested, who is "we"?

------
ausjke
that'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.

------
barbegal
I 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.

~~~
jpnorair
That'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
On 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
No, 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.

------
PaulHoule
I'd be amazed that anything with a GPS in it would last seven days, never mind
any other radios that are in it.

~~~
peburns
How about a LPWAN endpoint with GPS that last 2+ years? Like this:
[http://bit.ly/2pBcYqp](http://bit.ly/2pBcYqp)

------
HIPisTheAnswer
If it isn't open source, it can't optimize power efficiency up and down the
stack.

