The document provides a comprehensive overview of Low Power Wide Area (LPWA) technologies and their characteristics, focusing on various connectivity options for Internet of Things (IoT) applications. It details the specifications and performance of different LPWA solutions like LoRa, Sigfox, and cellular-based options (NB-IoT, LTE-M), while highlighting their pros and cons related to deployment, cost, energy consumption, and network efficiency. Additionally, it discusses the need for tailored networks to support numerous low-power, constrained devices as the IoT landscape evolves.

1. Wireless technologies for IoT
How not to get lost?
Marcin Aronowski
Systems Engineer
maaronow@cisco.com
Cisco Systems / CCIE.PL

2. Action points for today…
• Give an overview of LPWA landscape
• Provide short info on current status of most important technologies and their roadmaps
• Get into more details on SP related ones
• Not to talk about anything at layer3 and above (so no IPv6,6LowPAN,MQTT,AQMP,XMPP,
REST security and so on… ;) )
• Answer your questions

4. LPWA Characteristics
Characteristic Order of magnitude Typical value
Spectrum Unlicensed <1GHz
2.4 Ghz
Range Long 10-50+ km (rural)
0-5 km (urban)
Objects Many Many thousands
Data volume Small Up to 10’s kB per day
Data rate Low From 100 to 100kb/s
Latency Low to high Up to minutes
Battery life Long Up to 20 years
Module cost Low <$5
Service cost Low <$10 per year

5. Many sensors are low cost, low power, constrained devices
Battery/solar/scavenger energy
Wireless
Low CPU
Autonomous
Huge scale
Cellular & WiFi not Suitable for Constrained Devices
New type of network is
required
Low Power Wide Area
(LPWA)

6. Which one to choose?
Product?

7. Licensed or Unlicensed?
Licensed Pros
1. NB-IoT can fit into existing
PRB structure
2. Will be an upgrade to
existing eNBs Important
3. MNOs will be able to hit
KPIs in owned spectrum
4. Can be integrated with
existing EPC
Licensed Cons
1. Will NB-IoT scale? PRACH
considerations1
2. Will it REALLY just be a
software upgrade ?
3. This is true, but do we have
enough spectrum?
4. Yes, but do we have the
correct EPC2 ?
1. http://www.3gpp.org/ftp/Meetings_3GPP_SYNC/RAN2/Docs/R2-161141.zip
2. http://networks.nokia.com/sites/default/files/document/nokia_lte-m_-_optimizing_lte_for_the_internet_of_things_white_paper.pdf

8. Wireless IOT Connectivity Options
Technology 2G 3G LTE WIFI Zigbee Wireless
Hart
802.15.4g LPWA
(Lora/Sigfox,
etc.)
Long Range Yes Yes Yes No No No Limited (1.5
Km)
Yes (10s Km)
Tx Current
Consumption (3V)
30mA to
400mA
500 to
1000mA
600 to
1100 mA
19 to
400 mA
34mA 28mA ~ 35mA 20-70mA
Topology P2P P2P P2P P2P/Mesh Mesh Mesh Mesh P2P
Standby Current
Consumption (3V)
0.35 mA 1.2 to 3.5mA 1.5 to
5.5mA
1.1 mA 0.003mA 0.008mA ~.005mA 0.005mA
Operating Life on
battery (2000mAh)
A=Active
I=Idle
4-8 hours (A)
36 days (I)
5 years with
1 msg/day
2-4 hours (A)
20 days (I)
2-3 hours (A)
12 days (I)
4-8 hours (A)
50 hours (I)
60 hours (A) 8-10 years Variable 10-20 Years
Module Cost $12 $35-$50 $40-$80 $5-$8 $6-$12 NC $3 $2-$5
Spectrum Costs Yes Yes Yes No
(Unlicensed)
No
(Unlicensed)
No
(Unlicensed)
No
(Unlicensed)
No (Unlicensed)

9. Technology LORAWAN Sigfox Weightless-N ONRAMP/Ingenu LTE-M/NB-IOT
Frequency Sub-Ghz ISM Sub-Ghz ISM Sub-Ghz ISM 2.4 Ghz LTE band
RF PHY CSS and FSK UNB UNB DSSS LTE
True Bi-Directional Yes No No Yes Yes
BW 300 bps-50kbps 100 bps (EU)
600 bps (US)
100 bps 1 Mbps/
10s kbps
Tx Current Low Low Low Low High
Rx Current Low Low Low Low Moderate
Interference immunity Good Bad Bad Good Moderate
Mobile/Nomadic Yes/Yes No/Yes No/Yes No/Yes No/Yes
Module Cost Low Low Low Low High
Maturity Yes Yes No No No
LPWA Technologies Comparison

10. • Currently not the best for battery operated devices
• WiFi HaLow (802.11ah) supposed to fix that
• 802.11ah will operate on 900Mhz band
WiFi

11. • Latest spec (4.2) is adding few IoT functionalities:
• Low-power IP (IPv6/6LoWPAN)
• Bluetooth Smart Internet Gateways (GATT)
BT + BLE

12. • Specific physical layer (PHY) for address LPWA requirements
• Secure Sub-Ghz (ISM bands) bi-directional point-to-point wireless link
• Proprietary chirp spread-spectrum (CSS) modulation and Forward Error Correction
• Low data rates between 0.3 kbps (SF12) and 10 kbps (SF7), 50 kbps via FSK
• Packet size up to 250 Bytes
• Dynamically trades data rate against range, up to +20dBm TX power, 157 dB link budget
• 10 mA RX current, < 200 nA sleep current
• supported in all ISM bands (915/868/433/169)
• Semtech provides chipsets and reference designs to build a LoRa gateway
• chipset SX127x & SX13XX
• Semtech license the LORA modulation to other vendors: Microchip
Semtech Long Range (LoRa)

13. • Non profit organisation aiming at
standardising LPWA networks with a
focus on LoRaWAN
• Main contributors
• Semtech
• Actility
• IBM
• Sagemcom
• Cisco part of the board of Directors
LORA Alliance
http://lora-alliance.org

14. • Authored by Semtech, Actility, IBM
• Current specification includes:
• Identifiers definition
(Network and Application Ids)
• Security procedures
• Join procedure for OTA provisioning
• Data and Control messages (MAC layer)
• PHY layer for sub-Ghz ISM bands(*)
LoRaWAN 1.0 Specification
(Jan 2015)
(*) includes 433, 868, 915MHz band; 169MHz also supported but not specifed in LoRaWAN

15. • Gateways act as transparent bridge
relaying messages between devices and a
network server (NS)
• Sensors use single-hop wireless
communication to one (or many)
gateway(s)
• Communication between sensors and
Gateway is spread using different channels
and rates
• Network Server manages the data rate
and RF output for each sensor using ADR
scheme
• Any device can transmit to any channel at any
time
• No synchronization between devices required
• Node changes channel randomly for each
transmission
• Robust to interferers and collisions
• Piggy-backing for gateway to node
communication
• Predictable battery-life
LoRaWAN Principles

16. AppData
LoRaWAN
Radio PHY
LoRa End-to-End Architecture
LORAWAN Device
Standards Compliant
Low power sensor/actuator
Gateway
RF Termination
Transparently forward
packet
to NetWork Server
Network Server
MAC decaps, Security
Network/Radio
management
Message scheduling, ZTD
etc…
Application Server
Platform for ASP
e.g., Parking, Air quality,
Meter reading
Cloud Based LoRa Platform
RF Backhaul
LoRaWAN MAC
IP
Tunnel
IP Transport
Cloud
AppData

17. LoRaWAN Device Classes
A
B
C
rx1
rx2
Class A Bi-directional
Device UL TX followed by 2 short DL RX windows (TX from NS)
Class A must initiate a TX before listening on RX windows
Very suitable for lowest powered devices
Class B Bi-directional with scheduled receive slots (Beacons)
Implements Class A plus…
Open extra receive windows at scheduled times
Scheduled time synchronised with Beacon frames from gateway
Suitable for battery operated device
B B B
slot+1
Class C Bi-directional with maximum receive slots (Continuous RX)
Implements Class A RX1 window plus…
Continually listens on RX2 channel, only closed when TX
Uses most power, provides low latency
Suitable for powered device and actuators
slot+2
rx1
rx2rx2

18. Key LoRa Parameters
4/5
00001
Modulation Bandwidth
(125 to 500kHz)
Spreading Factor
(SF7 to 12)
Coding Rate
Defines
Link Budget
Interference Immunity
Spectral Occupancy
Nominal data rate

19. • Spread Spectrum technique is very immune to interference
• allows operating at very low SNR ranges (down to -20dB)
• Chirp Spread Spectrum (CSS) is adopted by LoRa modulation
• spreading is achieved by generating a chirp signal that continuously
varies in frequency
Spread Spectrum technique
Chirp Signal
reference pattern
Chips

20. Receiver : incoming signal is multiplied by the known pattern
ž Spreading sequence chips add up while noise chips cancel each
other
à Information is recovered with negative SNR (-22dB)
ž High complexity (synchronization, Doppler effect…)
reference pattern
« 1 »
Chips +1/-1
Rx chips =
spreading sequence
chips + noise chips
Spread Spectrum - 2

21. • Different Spreading Factors yield different bit rates, shown below for 125KHz transmission bandwidth
• LoRaWAN specifications also support ADR (Adaptive Data Rate), by which the network instructs an end-device
to perform rate adaptation as a function of its radio conditions:
• Devices in good radio conditions use higher data rates to send their packets compared to devices in bad radio conditions
• ADR optimizes the device battery and reduces radio pollution
• Note that ADR is only suitable for stationary devices (fixed), but it should be disabled for mobile devices
LoRaWAN Data Rates
Spreading Factor Data Rate (bit/s) Chips/symbol LoRa Demod SNR dB
SF12 293 4096 -20
SF11 540 2048 -17.5
SF10 980 1024 -15
SF9 1760 512 -12.5
SF8 3125 256 -10
SF7 5470 128 -7.5

22. SF12 11 10 9 8 7
ADR
Adaptive Data Rate is the procedure by which the network instructs a
node to perform a rate adaptation by using a requested DR (e.g.
DR0), a requested TX Power (e.g. 11 dBm)
14km 10km 8km 6km 4km
290bps 530 970
Avg bitrate ~1300bps
2D simulation (flat environment)
Adaptive Data Rate Mechanism

23. Typical Range: Dense City
Ø8th floor of building
Øfacing NE, omni
antenna 30cm
ØNoise level >-110dBm
• 3km in directions where antenna is above
mean rooftop level
• 1km in directions where antenna is about
10m below roof level
• About 600m behind and on sides of
building (shielding by Base station building)

24. Ø20m high telecom pole
ØOmnidirectional antenna 30cm
• 18km in directions where antenna is
above mean hill level
Typical Range: Rural Area with Hills

25. LoRa reach Examples
Area type Outdoor (m) Light indoor (m) Deep indoor (m)
Rural 10 000 4 600 3 300
Suburban 4 000 2 000 1 300
Urban 2 500 1 000 700
Dense Urban 2 000 600 500
Assumptions:
• SF12 / 125 kHz
• Antenna height : 30m – Antenna gain : 3dBi (Omni)
• Considered Cable losses : 0,5 dB
• End-device antenna height: 1,5m
• End-device Max Tx Power : 19 dBm / Antenna Gain : 0 dBi
• Applicable regulatory rules : EU 868 MHz
Warning: please note these values are only indicative values. Real results will depend on radio propagation conditions.
Cell range at 125 kHz / SF12

26. • Large participation of several SP in LORA Alliance with a goal to have convergence around
LORAWAN specification and interoperability for devices and networks
• Swisscom, KPN, Proximus are deploying LORAWAN network in 2015
• In France, both Orange and KPN have made official commitments to LoRa
• http://www.fiercewireless.com/europe/story/bouygues-telecom-launches-iot-network-based-lora-technology/2015-03-30
• Du is deploying LoRa for the upcoming IoT World Forum
Growing SP interest

27. • Sigfox is the first LPWA SP
• Country covered include France (w/ TDF), Spain (w/ Abertis), UK (w/ Arqiva), Netherlands, Russia
• Sigfox business model is based on subscription fee (e.g. 12$/year to <1$/year per device)
• Radio Technology based on proprietary UNB in unlicensed ISM band
• End-to-end service
• Customer access data from devices using APIs
• Ecosystem of partners for vertical applications
• Devices – no proprietary hardware
• Off the shelf wireless (Silabs, Semtech, ST or ATMEL) can be used
• Sigfox license for free his patents to reduce price effects on chipset/device side
SIGFOX
Alternative LPWA SP

28. SigFox coverage

29. • Sigfox techology is licensed at no cost to module/device vendors
• Telit, Atmel, TST, Adenuis, Telecom Design, TI
• Supported on sub-Ghz ISM bands: 868, 915, 433 Mhz
• Battery usage:
• Tx(@14Bm) = Typical 65mA
• Rx = max 40mA
• Standby < 5μA
• Link Budget/Receivier Sensitivity: 162 dB/-125 dB
• Message Size: max 12 bytes
• Message per day: max 140(*)
Sigfox Characteristics
(*) On ISM bands a device is not allowed to emit more than 1% of the time each hour and since emission of a message
can take up to ~6 seconds, this allows up to 6 messages per hour

30. • Data can be accessed via 3 mechanisms:
• Web interface on http://backend.sigfox.com
• REST API
• Callback mechanism
• REST API (details on http://makers.sigfox.com) allows to:
• Retrieve the list of devices associated to a device type
• Retrieve the messages of a given device
• Get metrics about a device's messages
• Callback can be registered via HTTP: message with device id,time, data, rssi
are sent everytime a device send a message
Sigfox Data Access

31. • No Adaptive Link mechanism for different type of environment, devices
• Fixed packet size for uplink and downlink: very limiting for certain
applications or FW upgrade
• Many parameters are fixed which prevents Over the Air Provisioning or
flexible mechanism to optimize battery life or change modulations when
wireless conditions are good
• Only one mode of operation with limited downlink capabilities preventing
device reconfiguration
• Feedback from SP trials on performance are not so positive in terms of
coverage and interferences management
Sigfox Limitations

32. 3GPP - Tracks towards IoT

33. App
• 2G/GSM has its own evolution with EC-
GSM
• LTE comes with two flavours:
• eMTC (existing RAT)
• NB-IOT (new RAT)
• CIoT enhancements for control and
user plane
• PSM
• eDRX
• Long Latency
3GPP IoT Evolution
GPRS CN
Gb*
S1*
RAN Core Network
App
App
S1
LTE CN
(inc. CIoT
enhancements)
E-UTRAN
NB-IOT
EC-GSM

34. Core Network Optimizations
§ Cellular IoT (CIoT) – core network supporting IoT
optimizations
§ CIoT supports both LTE-eMTC and NB-IoT
• LTE-eMTC (CAT-M) - 1.4 MHz BW, served as
normal UE in the core network
• NB-IoT- 200 kHz BW
• new RAT type
• Ultra low UE power consumption
• Large number of devices per cell
• Applied in narrowband spectrum
• Increased coverage
CIoT
RAN
S1*
CIoT CN
(EPC)
CIoT UE TBD
CIoT Architectural Reference Model
LTE
LTE eMTC/CAT-M
(Rel 12/13)
NB-IoT (Rel 13)
2016 2017 2018

35. Device Category Comparison
deployed
available
planned
LTE LTE-M NB-IOT

36. • New work item agreed in 3GPP in Sept. by all parties (HW, E///, QCOM, VF)
• NB-IOT – Narrow Band IoT
• Part of 3GPP R13 (March 2016) – TR 45.820
• Objective is to define an optimized radio for low power low throughput clients
• 100s bytes per day, Large nb of clients, etc.
• 180 kHz UE RF bandwidth for both downlink and uplink
• Compatible with GSM, LTE and LTE guard band spectrum
• Downlink modulation
• OFDMA with 15 kHz sub-carrier spacing (with normal or extended CP) and/or 3.75 kHz sub-carrier spacing
• Uplink modulation
• FDMA with GMSK and/or SC-FDMA
• MAC, RLC, PDCP and RRC procedures based on existing LTE procedures and protocols and relevant
optimisations to support the selected physical layer
CIoT – Radio Aspect
CIoT
RAN
S1*
CIoT CN
(EPC)
CIoT UE TBD

37. • Key assumptions for the specification:
• Low user plane data rate requirements
• New/altered control plane shall be efficient to allow large nb of devices
• Applications expected to be delay tolerant
• No or low mobility; no inter-RAT mobility
• Support for IP and non-IP communications
• Different approaches depending: modified EPC vs new elements (C-SGN)
• Key is to keep compatibility with existing packet core
CIoT – Core Network CIoT
RAN
S1*
CIoT CN
(EPC)
CIoT UE TBD
Non-roaming Roaming

38. • CIoT Serving Gateway Node (C-SGN) optimizations
• User plane optimization for small data transmission
• Necessary security procedures for efficient small data transmission
• SMS without combined attach for NB-IoT only UEs
• Paging optimisations for coverage enhancements
• Support for non-IP data transmission via SGi tunnelling and/or SCEF
• Support for Attach without PDN connectivity
CIoT - Core Network
CIoT
UE
E-UTRAN C-SGN
HSS
SCEF
CIoT Services
S1CIoT Uu
S6a
T6a
SGi
SMS-GMSC/
IWMSC/
SMS Router
SGd
MME
SAEGW
CSGN
Non-roaming

39. 3GPP CIOT Approach
Focus on Non-IP Data Delivery (NIDD)
Non-roaming Architecture
T6a

40. IoT Core
IoT Core
WiFi
CAT-M
Access
• Multi-access Core with unified policy, charging and service capability layer.
• Additional capabilities – analytics, data exposure provide monetization opportunities
• Network Service Capabilities (NSC) based on ETSI framework exposes various network capabilities
to the applications and includes adapters for different access types (Cat-M, NB-IOT, LTE-M, LPWA)
vCSGN IoT vNSC
vSCEF
Billing Authentication Policy
Analytics
Monetization
Server
NBIoT
LPWA
LPWA
Adapter
LTE IOT
Adapter
Orchestration
MME SAEGW
IoT App
Servers

41. Application
Multi-access – Single API for the Applications
SDN
IoT Core
Policy
Smart metering
Lighting
Application
ApplicationAPIs
Waste mgmt
• Problem Statement: IoT Customer needs data from different type
of sensors (i.e. city, tracking company, integrator)
• IoT Core Solution: SP collects the data and routes it to subscribed
applications via Restful APIs. Applications call the same API to
receive the data
• Benefits: Time to market and monetization opportunity

42. Application
Data Sharing Among Multiple Applications
SDN
IoT Core
Policy
Building monitoring
Application
• Problem Statement: Typically one to one relationship between the device and the application;
however single sensor can monitor multiple parameters and there is no easy way to post endpoint
data to multiple applications
• IoT Core Solution: NSC allows more then one application to subscriber and receive endpoint data
• Benefits: eco-system stimulation, monetization

43. Application
Endpoint Status Change Notification
SDN
IoT Core
Policy
Alarm
Healthcare monitors
Application
Triggers
• Problem Statement:
1. End device connects infrequently (once a day) and the application needs to push
updates once the device is connected.
2. Application needs to know when the end device is not working properly
• IoT Core Solution: Application subscribes to the device status change trigger; packet core
notifies NSC when the device is connects (#1) or device disconnected (#2); NSC send trigger to
the application which sends the trigger to the application
• Benefits: less chatter in the network – applications don’t have to continuously query the end
device

44. Application
Application Requests High QoS
SDN
IoT Core
Policy
Flood monitoring
Fault Management
Application
ApplicationAPIs
Healthcare
• Problem Statement: Occasionally applications need guaranteed bandwidth or
higher QoS (response to alarm, pull ample health monitoring data, etc)
• IoT Core Solution: IoT Core exposes APIs for the application to request higher
QoS
• Benefits: Business agility and monetization opportunity

45. Evolving Network Architecture for IoT
MME
SDN
IoT Core
Policy
SDN
SAE-GW
Policy
NB-IoT
LTE-eMTC
DÉCOR

46. LTE-M Details
aka eMTC
IOT technology
migration
RAN Core Network
LTE-> LTE-M (eMTC) Existing RAT
• R12:
Cat-0: 20MHz BW, 23 dBm
• R13:
Cat-M: 1.4 MHz BW, 20 DBm
MME:
• PSM
• eDRX
• HLCom
• Storage of extended coverage information to be used for paging
• Storage of list eBNs /cells to page
SGW:
• extended buffering and HLCom,
• Re-routing the buffered packets to target node during mobility,
• Taking bearer / PDN restoration decision based on delay tolerant connection
indication (DTCI) of the PDN during restoration procedures.
PGW:
• Support for latency sensitive PDN and
• buffering of signaling message till UE makes radio contact

47. IOT technology
migration
RAN Core Network
NB-IoT New RAT – NB-IoT
Data over SRB
Data over DRB
New CIoT architecture
• Non-IP data
• Data over NAS
• Attach w/o PDN
• SMS support w/o combined attach
• Small data using U-plane
• PGW/SGW selection based on NB-IOT Rat
• Non-IP data delivery w/ and w/o PDN
• Header compression for IP small data over NAS
• Ciphering and integrity protection of user data
• LI of user data
• Uplink/downlink UE-AMBR enforcement
• S1-AP uplink NAS carrying both RATs (NB-IoT or E-UTRAN)
• NB-IoT UE: Don’t detach UE after the last PDN release
• Access restriction per RAT
• Negotiation of PDN with UE (IP and non-IP)
• Negotiate delivery method for non IP PDN
• DÉCOR
• HLCOM, eDRX, PSM
• SMS over MME (w/o SGs/CS attach)
• Data buffering
NB-IOT Solution

48. EC-GSM Evolution
IOT technology
migration
RAN Core Network
GSM -> EC-GSM Existing RAT
GERAN - GSM spectrum w/ a
base block size of 200Khz
SGSN:
• PSM
• eDRX
• Gb coverage class info storage and sending in paging messages
• extended buffering for High Latency

49. LPWA Technologies and SP Interest
Data Resource - “Machina Research, 2015”
SP Technology Activity (likely)