# A Survey of LoRaWAN for IoT: From Technology to Application
## 2 Introduction to LoRa and LoRaWAN
### LoRaWAN MAC Layer
#### 2.2.2 Network Joining Mechanism and Security Context
\begin{table}
\begin{tabular}{c c c c c} \hline \hline \multicolumn{1}{c}{**Key**} & \multicolumn{1}{c}{**Description**} & \multicolumn{1}{c}{**Required in Joining Type**} & \multicolumn{1}{c}{**Generated from**} \\  & & & **or Stored Beforehand** \\ \hline \multicolumn{1}{c}{**OTAA**} & \multicolumn{1}{c}{**ABP**} & \\ \hline \multicolumn{1}{c}{LoRaWAN v\(1.1\)} & & & \\ \hline \multicolumn{1}{c}{Keys needed before activation} & & & \\ \hline \multirow{4}{*}{NwkKey} & Is used to calculate MIC & & & \\  & for join-request packets, & & & \\  & encrypt join-accept packets, & & & \\  & and derive all NTW session keys. & & & \\ AppKey & Is used to derive AppSKey & Yes & No & Stored beforehand \\ JSIntKey & Is used for MIC of rejoin-request & & & & Generated from \\  & and join accept packets & & & & NwkKey and DevEUI \\ JSEncKey & Is used to encrypt join-accept & & & & Generated from \\  & triggered by rejoin-request & & & & NwkKey and DevEUI \\ \hline \multicolumn{1}{c}{Keys needed after activation} & & & \\ \hline \multirow{2}{*}{FNwkSIntKey} & Is used for calculate MIC of part & & & & Generated from NwkKey \\  & of it of all uplink data packets & & & & and join-accept message \\  & Is used to verify MIC of all & & & & Generated from NwkKey \\ SNwkSIntKey & downlink data packets and calculate & & & & and join-accept message \\  & part of MIC of uplink packets & & & & and join-accept message \\  & Is used to encrypt all & & & & Generated from NwkKey \\  & downlink and uplink MAC packets & & & & and join-accept message \\ AppSKey & Is used to encrypt/decrypt & & & & Generated from AppKey \\  & payload of data packets & & & & and join-accept message \\ \hline \multicolumn{1}{c}{Identifiers} & & & & \\ \hline \multirow{2}{*}{JoinEUI} & 64-bit globally unique application ID & & & & \\  & that identifies the join server & & & & \\  & 64-bit globally unique device ID & & & & \\  & by the network server & & & & Stored beforehand \\ \multirow{2}{*}{DevAddr} & 32-bit unique device address & & & & Received by \\  & in the current network & & & & join-accept message \\ \hline \multicolumn{1}{c}{LoRaWAN v\(1.0\)} & & & \\ \hline \multicolumn{1}{c}{Keys needed before activation} & & & & \\ \hline \multirow{4}{*}{AppKey} & Is used to derive AppSKey & & & & \\  & and NwkSKey and to calculate MIC & Yes & No & Stored beforehand \\ \cline{1-1}  & for join-request message. & & & & \\ \hline \hline \end{tabular}
\end{table} 
Table 1: LoRaWAN keys. The previous LoRaWAN standard v1.0 [9] specified another way to perform OTAA. We describe the old standard too, as both are currently in use. According to the old standard [9], a join-request message consists of a DevEUI, AppEUI, and a random 2 bytes DevNonce. The join-request is not encrypted, but the MIC is calculated using AppKey. The join-request is accepted by the network server if the integrity check is correct and the DevNonce was not used previously by the end device. If accepted, the network server will reply with a join-accept message. The join-accept message will contain DevAddr and 3 bytes of AppNonce among other communication parameters. AppKey is used by the end node to generate all the rest of session keys, AppSKey and NwkSKey, respectively. Contrary to OTAA, in case of ABP, all the session keys are saved beforehand. There is no need for activation process and exchange of join-request and join-accept packets.