Ir al contenido principal

LoRaWan Overview

LoRaWAN

  • Network Protocol Candidate Specification
  • Optimized for battery powered end-devices
    • Fixed
    • Mobile (as in, they move, not phones)
  • Network Topology typically is start-of-stars
  • Network Operators can't secretly listen on application data

Communication

All Communication is bidirectional, uplink traffic should dominate:

+---+
|   |
+---+

Device
           LoRa or FSK   +---------+   IP   +---------+
    +---+    (radio)     |         |        |         |
    |   |  <---------->  |         <-------->         |
    +---+                |         |        |         |
                         +---------+        +---------+
    Device
                           Gateway         Network Server
   +---+
   |   |
   +---+

   Device
  • Communication spread out on different frequency channels and data rates
  • Data Rates between 0.3 kbps and 50 kbps
    • Max ~ 45 tweets/s (extended ASCII only ;)
    • Just the text w/o protocol overhead
    • Don't expect audio, video or any kind of streaming
  • Encryption of payload
    • AES 128 bit key length
    • One key for each FPort
  • MAC Commands
    • For Network Management
    • Invisible to Application Layer

Devices Classes

  • Class A: Baseline
    • Uplink transmission
    • Followed by two short downlink receive windows (RX1, RX2)
  • Class B: Beacon
    • Allow more receive slots at scheduled times
    • Synchronize by a beacon from the gateway
  • Class C: Continuous
    • Nearly continuos open receive windows
    • Only closed when transmitting
    • Lower latency, but more energy usage
  • All devices implement at least class A

Receive Windows

  • After uplink at configured periods
  • If msg received for current device on RX1, RX2 doesn't happen
    • Max one downlink per uplink on Class A
  • Can't transmit from last transmit until after RX2 window
+------------------+                  +-----------+              +------------+
|                  |                  |           |              |            |
| Transmit         |                  | RX1       |              | RX2        |
|                  |                  |           |              |            |
+------------------+                  +-----------+              +------------+

<------------------><---------------->
   Transmit Time         Receive
      on Air             Delay 1

                    <------------------------------------------->
                                      Receive
                                      Delay 2

MAC Message Types

  • Join Request/Accept
    • For Over the air Activation
  • Unconfirmed Data Up/Down
    • No ACK required
  • Confirmed Data Up/Down
    • ACK required

MAC Messages

  • Can be standalone messages
    • Always encrypted
  • Or "Piggyback" on next message
    • No encryption
  • Unknown messages ignored

ACK Messages

  • Can be standalone messages
  • Or "Piggyback" on next message

End Device Activation

To participate on a LoRaWAN network

Over the Air Activation

  • Needs join procedure
  • Requires fields set on device
    • DevEUI
    • AppEUI
    • AppKey (AES 128, derived from root AppKey)
  • Network Key provided
    • Allows network roaming

Activation by Personalization

All info stored on device on setup

Information Stored after Activation

  • Device Address
    • Two parts: Network Id and Network Address
  • Application Identifier
    • Global ID, uniquely identifies owner
  • Network Session Key
    • Used for MIC generation
    • Used for MAC only message encryption/decryption
  • Application Session Key
    • Used to encrypt/decrypt payload and for MIC

Class B Devices

  • Devices mobile or fixed that require to open receive windows
    • At fixed time intervals (ping slots)
  • Class B implements Class A
  • All gateways must synchronously broadcast a beacon
  • Provides timing reference to devices
  • Devices start as Class A and can switch to B when detect a beacon
  • If no beacon is detected for 120 minutes, devices switches back to Class A

Class C Devices

  • Used for applications that have suficient power available
    • cannot implement Class B
  • Will listen with RX2 window parameters as often as possible
  • No message to tell the server that it is a class C node
    • App must know
  • Like Class B, can receive multicast downlink frames

Comentarios

Comments powered by Disqus