Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

PLNOG 17 - Marcin Aronowski - Technologie dostępowe dla IoT. Jak się w tym wszystkim połapać?


Published on

BLE, BT, Wifi, Z-Wave, Zigbee, EnOcean, 802.15.4, NB-IoT, EC-GSM, LoRa, SigFox. Lista jest długa a cały czas się jeszcze wydłuża. Która technologia będzie najlepsza dla Twojego projektu IoT? Jak się nie pogubić w tej mnogości i szybkości zmian?

Sesja postara się odpowiedzieć na te i kilka innych pytań związanych z łącznością bezprzewodową w świecie Internet of Things.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

PLNOG 17 - Marcin Aronowski - Technologie dostępowe dla IoT. Jak się w tym wszystkim połapać?

  1. 1. Wireless technologies for IoT How not to get lost? Marcin Aronowski Systems Engineer Cisco Systems / CCIE.PL
  2. 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
  3. 3. 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
  4. 4. 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)
  5. 5. Which one to choose? Product?
  6. 6. 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. 2.
  7. 7. 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)
  8. 8. 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
  9. 9. • Currently not the best for battery operated devices • WiFi HaLow (802.11ah) supposed to fix that • 802.11ah will operate on 900Mhz band WiFi
  10. 10. • Latest spec (4.2) is adding few IoT functionalities: • Low-power IP (IPv6/6LoWPAN) • Bluetooth Smart Internet Gateways (GATT) BT + BLE
  11. 11. • 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)
  12. 12. • 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
  13. 13. • 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
  14. 14. • 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
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. • 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
  19. 19. 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
  20. 20. • 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
  21. 21. 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
  22. 22. 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)
  23. 23. Ø20m high telecom pole ØOmnidirectional antenna 30cm • 18km in directions where antenna is above mean hill level Typical Range: Rural Area with Hills
  24. 24. 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
  25. 25. • 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 • • Du is deploying LoRa for the upcoming IoT World Forum Growing SP interest
  26. 26. • 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
  27. 27. SigFox coverage
  28. 28. • 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
  29. 29. • Data can be accessed via 3 mechanisms: • Web interface on • REST API • Callback mechanism • REST API (details on 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
  30. 30. • 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
  31. 31. 3GPP - Tracks towards IoT
  32. 32. 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
  33. 33. 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
  34. 34. Device Category Comparison deployed available planned LTE LTE-M NB-IOT
  35. 35. • 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
  36. 36. • 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
  37. 37. • 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
  38. 38. 3GPP CIOT Approach Focus on Non-IP Data Delivery (NIDD) Non-roaming Architecture T6a
  39. 39. 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
  40. 40. 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
  41. 41. 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
  42. 42. 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
  43. 43. 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
  44. 44. Evolving Network Architecture for IoT MME SDN IoT Core Policy SDN SAE-GW Policy NB-IoT LTE-eMTC DÉCOR
  45. 45. 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
  46. 46. 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
  47. 47. 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
  48. 48. LPWA Technologies and SP Interest Data Resource - “Machina Research, 2015” SP Technology Activity (likely)