LoRaWAN Overview
===
[TOC]
## Specification

### Selecting a LoRaWAN Specification
At the moment, there are a few different versions of the LoRaWAN® specification that are available to developers. Each supports slightly different functionality. So, which version should you use when developing LoRaWAN-based solutions? Check this [Link](https://tech-journal.semtech.com/selecting-a-lorawan-specification)

### [v1.0.4](https://lora-alliance.org/resource_hub/lorawan-104-specification-package/) - Oct. 2020

### [v1.0.3](https://lora-alliance.org/resource_hub/lorawan-specification-v1-0-3/) - July 2018
Fully supports unicast & multicast classB devices. For devices operating in classA or classC, there is no need to upgrade to LoRaWAN1.0.3

### [v1.1](https://lora-alliance.org/resource_hub/lorawan-specification-v1-1/) - Oct. 2017
Added support for handover roaming, Class B and security enhancements

### [v1.0.2](https://lora-alliance.org/resource_hub/lorawan-specification-v1-0-2/) - July 2016

## LoRaWAN Network Topology
Typical LoRaWAN network implementation from end to end.

* **End Nodes** transmit directly to all gateways within range, using LoRa.
* **Gateways** relay messages between end-devices and a central network server using IP.
* **Backend Server**
* Network Server
* servers that route messages from End Devices to the right Application, and back.
* Join Server
* Its role is to store root keys, generate session keys and to send those securely to the Network Server and Application Server of choice.
* Application Server
* Application Server handles the LoRaWAN application layer, including uplink data decryption and decoding, downlink queuing and downlink data encoding and encryption.
* Specification
* [TS002-1.1.0](https://lora-alliance.org/sites/default/files/2020-10/TS002-1.1.0_LoRaWAN_Backend_Interfaces.pdf) - Oct 19, 2020
* [1.0](https://lora-alliance.org/sites/default/files/2018-04/lorawantm-backend-interfaces-v1.0.pdf) - Oct 11, 2017

## LoRaWAN Protocol Stack

## LoRaWAN Classes

The LoRaWAN specification defines three device types. All LoRaWAN devices must implement Class A, whereas Class B and Class C are extensions to the specification of Class A devices.


### Class A
Devices support bi-directional communication between a device and a gateway. Uplink messages (from the device to the server) can be sent at any time (randomly). The device then opens two receive windows at specified times (1s and 2s) after an uplink transmission.

### Class B
Devices extend Class A by adding scheduled receive windows for downlink messages from the server. Using time-synchronized beacons transmitted by the gateway, the devices periodically open receive windows.

### Class C
Devices extend Class A by keeping the receive windows open unless they are transmitting, as shown in the figure below. This allows for low-latency communication but is many times more energy consuming than Class A devices.

### Energy Consumption



## End-Device Activation
Activation of an end-device can be achieved in two ways, either via **Over-The-Air Activation(OTAA)** when an end-device is deployed or reset, or via **Activation By Personalization (ABP)** in which the two steps of end-device personalization and activation are performed in one step.

### Over-The-Air Activation (OTAA)
End-Devices follow a Join Procedure prior to participating in data exchanges with a Network Server. An end-device SHALL initiate a new Join Procedure every time it loses the session context information.

#### The Join Procedure
* Security keys generated during the Join procedure

* Sending a join request message to the join server

* Sending a join accept message to an end device

* Session keys are shared with the network server and the application server

* Secure transmission of data packets

### Activation By Personalization (ABP)
Activation by personalization ties an end-device directly to a specific network, thus bypassing the Join-Request – Join-Accept procedure.

Activating an end-device by personalization means that the *DevAddr* and the two session keys *NwkSKey* and *AppSKey* are stored directly in the end-device instead of being derived from *DevEUI* , *JoinEUI* and the *AppKey* .

### Data Stored in End-Device after Activation
After activation, the following information is stored in the end-device: a device address(**DevAddr**), a network session key(**NwkSKey**), and an application session key(**AppSKey**).

#### End-device address
The *DevAddr* consists of 32 bits and identifies the end-device within the current network. The *DevAddr* is allocated by the Network Server of the end-device.
* DevAddr fields

#### Network session key
NwkSKey is a network session key specific to the end-device. It is used by both the Network Server and the end-device to calculate and verify the MIC(message integrity code) of all data frames to ensure data integrity.

#### Application session key
AppSKey is an application session key specific to the end-device. It is used by both the Application Server and the end-device to encrypt and decrypt the payload field of application-specific data frames.

## Modulation and Data Rate
The LoRa modulation characteristics for each region are defined in the LoRaWAN Regional Parameters document.

In North America, there are 64, 125 kHz LoRa uplink channels defined, centered on a 200 kHz and eight 500 kHz uplink channels as well as eight, 500 kHz downlink channels defined.


## Security
LoRaWAN has all the fundamental building blocks required and used by any modern wireless communications technology, and does so at AES-128 strength.

- Using a unique 128-bit network session key shared between the end-device and network server
- Using a unique 128-bit application session key (AppSKey) shared end-to-end at the application level
- AES algorithms are used to provide authentication and integrity of packets to the network server and end-to-end encryption to the application server.




# Backend Interfaces
## Radio Gateway
The Radio Gateway forwards all received LoRaWAN radio packets to the Network Server that is connected through an IP back-bone. The Radio Gateway operates entirely at the physical layer. Its role is simply to decode uplink radio packets from the air and forward them unprocessed to the Network Server. Ror downlinks, the Radio Gateway simply executes transmission requests coming from the Network Server without any interpretation of the payload.

There is a program which running on a gateway, that interacts with **LoRa chip** to receive and transmits LoRa packet and with **network** to tramsmit them for applications.

### Packet Forwarder
* [Communication protocol between Lora gateway and server](https://github.com/Lora-net/packet_forwarder/blob/master/PROTOCOL.TXT)

* UDP port 1700

### Basicstation
LoRa Basics™ Station is an implementation of a LoRa® packet forwarder.

#### LNS Protocol
* WebSocket

#### CUPS Protocol
* HTTP/REST, using the client/server authentication methods

## Network Server
The Network Server (NS) terminates the LoRaWAN MAC layer for the End-Devices connected to the network. It is the center of the star topology.
Generic features of NS are:
- End-Device address check
- Frame authentication and frame counter checks
- Acknowledgements
- Data rate adaptation
- Responding to all MAC layer requests coming from the End-Device
- Forwarding uplink application payloads to the appropriate Application Servers
- Queuing of downlink payloads coming from any Application Server to any End-Device connected to the network
- Forwarding Join-request and Join-accept messages between the End-Devices and the Join Servers

## Join Server
The Join Server (JS) manages the Over-the-Air (OTA) End-Device activation process. There may be several JSs connected to a NS, and a JS may connect to several NSs.
For that purpose the JS SHALL contain the following information for each End-Device under its control
- DevEUI
- AppKey
- NwkKey (only applicable to LoRaWAN 1.1 End-Device)
- Home Network Server identifier
- Application Server identifier
- A way to select the preferred network in case several networks can serve the End-Device
- LoRaWAN version of the End-device (LoRaWAN 1.0, 1.0.2, or 1.1)

The root keys NwkKey and AppKey are only available in the JS and the End-Device, and they are never sent to the NS nor the AS.

## Application Server
The Application Server (AS) handles all the application layer payloads of the associated End-Devices and provides the application-level service to the end-user. It also generates all the application layer downlink payloads towards the connected End-Devices.