LoRaWAN

· Frames can only be transmitted at the beginning of synchronized time slot. If any end-device misses that moment, it must wait for the whole time. Reduces vulnerable time tfr.

· CSMA: -

· Vulnerable time is no Tpropogation.

· What you do is you sense the medium before sending data & hence the name Carrier Sense. You avoid collisions using non-persistent (waiting for random time when I find channel idle), 1-persistent (send as soon as I find the Channel idle), p-persistent (you send with probability p when you see the channel idle).

· Hidden Node Problem and Exposed Node Problem: -

· RTS-CTS. If A wants to communicate to B, it first sends an RTS which has the time for which A asks B’s time. CTS is sent with time allocated to A. RTS may not heard, but CTS can!

· Didn’t go deeper into CA/CD.

1.1.2 Class B

· On top of being a Class A device, it also has extra rx windows on scheduled time.

1.1.3 Class C

· Has continuously open windows. Low latency communication with power trade-off.

1.2 Physical Message format

1.2.1 Uplink and downlink difference

· Format of uplink and downlink messages are different.

· Both have CRC for PHDR. Only uplink has CRC for payload.

1.2.2 Receive Window

Figure 3. Device A type Receive Slot Timing(must open 2 rx window after uplink

1.2.2.1 First Receive Window

· Its frequency and data rate are defined by the Uplink frequency and data rate.

· DR is a function of Uplink DR and RX1DROffset [0:5].

· RECEIVE_DELAY1 is the time window for it.

1.2.2.2 Second Receive Window

· Frequency and DR parameters are fixed (869.525 MHz, DR0 (SF12, 125KHz).

· Can be changed using MAC Commands.

1.2.2.3 Duration of Window

· At least more than the time to detect the preamble of downlink.

1.2.2.4 Activities during Window

· If downlink message is properly demodulated in the first window and the frame is was intended to be reached to this address and we are done with mic checks.

· Must not open second window.

1.2.2.5 Network Boundation

· Precise time sync between end device window and Network frame.

· Identical frames to be sent in both windows.

1.2.2.6 Important Notice

· No uplink transmission between these windows.

· Radio can rx and tx any other protocols in this window frame if duty cycle permits.

Chapter 2: MAC Message Format

Figure 4. Hierarchy of Message Frames

2.1 MAC Layer (PHY Payload)

M being maximum length of Payload.

2.2 MAC Header (MHDR)

· MHDR has the info about what is the type of message (in 3 bits)

· According to which Major is encoded.

2.2.1 Message Type (MType bit field)

· We have 8 different message types available.

2.2.1.1 Join Request and Join Accept Messages

Described later.

2.2.1.2 Data Messages

· Can either have MAC commands or application data

· Unconfirmed doesn’t require ack while confirmed does.

· Proprietary messages are non-standard types of which both rx and tx must know about otherwise discard.

2.2.2 Major Version (bit field)

· Leaving it for now, will come back after reading chap 6.2

2.3 MAC Payload

2.3.1 Frame Header (FHDR)

· 4 Octet DevAddr, 1 octet Frame Control, Frame Count, Frame Option which is used to transport MAC Commands.

· Fopts is encrypted using NwkSnkey.

· Difference in FCtrl for Uplink and Downlink Message is.

2.3.1.1 Adaptive Data Rate using FCtrl (SO COOL!)

· Using FCtrl octet, LoRaWAN optimizes tx power and data rate.

· Not possible when Channel Attenuation is erratic. In that case, Application layer handles this & aim is to minimize ToA.

· Flexibility for end device to set ADR=1 for allowing network to handle tx power and data rate for him using MAC Commands ow Network doesn’t attempt it. Frame commands

· When downlink ADR bit is set, end device knows Network is about send ADR Commands.

· If downlink ADR bit is unset, Network wants to inform the end device that channel is abruptly changing (Say a Storm!) and I can’t help you find best data rates. Device can either

1. Unset Uplink ADR bit and finds the solution himself.

2. Ignore and do Normal Data Rate decay in absence of ADR Downlink Commands.

· ADR is good for battery life.

· Default TX Power is max. Start off with this until LinkADRReq command.

· Steps:

1. If optimization, validation of uplink is must.

2. For each new Uplink, ADR_ACK_CNT is incremented.

3. If ADR_ACK_CNT > ADR_ACK_LIMIT and no downlink frame received.

4. ADRACKReq set, Network has to send downlink within ADR_ACK_Delay.

5. If got, reset the ADR_ACK_CNT.

6. If not, first set the TX power to default.

7. Then, lower data rate until connection established, re-enable uplink freq channels.

· An example of this happening: -

2.3.1.2 Message Acknowledgment

· In confirmed uplink, network shall respond with ACK bit set in FCtrl of MHDR in MAC Payload in receiver window slot.

· ACK is only sent for latest message and for only once!

· To keep end-device’s computation less, they only may tx explicit(empty) ack for downlink or differ transmission of ack to piggybacking it with its next data message.

2.3.1.3 Retransmission Procedure

· For downlink confirmed message, may decide to retransmit with incremented frame counter.

· For uplink, limit for both is NbTranstimes except a valid link is received.

· NbTranstimes defines the QoS.

· Uplink retransmission shall stop for confirmed if ack received.

· For B&C, if valid unicast message is received during RX1 slot window, stop.

· Class A does the same for unconfirmed if receives valid downlink message.

· More than NbTrans transmission for same uplink means malfunctioning and can lead to replay attack. They can be overcome by reducing NbTranstimes to 1.

2.3.1.4 Frame Pending Bit

· When network has too much to send and he must ask end device to open a receive window for him.

2.3.1.5 Frame counter (FCnt)

· Three counters to keep account of no. of Uplink (FCntup) and downlink (FCntdown).

· In downlink, if all ports have same Counter (Device as 1.0 => Single Counter Scheme). NFCntDown for port 0 and when FPort missing, AFCntDown for other ports (Device as 1.1 => Double Counter Scheme).

· NFCntDown => Network server while AFCntDown => application server.

· For version, earlier than 1.1, one scheme supported by Network Server.

· Steps:

· On Joint-Accept Message, resetting of counter. ABP devices have same throughout.

· FCntup, NFCntDown, AFCntDown increment on each uplink, port0, other ports, res.

· Never uses the same counter for an uplink unless retransmission case.

· End-device shall not process the same counter downlink frame.

2.3.1.6 Frame Options

· FOptsLen has the size of the of what is FOpts, which transports MAC Commands which are 15 Octet and piggybacked on data frame.

· If FOptsLen=0, FOpts absent, if not, FOpts and FPort not 0 contain MAC Commands

· Commands should not be simultaneously present in FOpts and FRMPayload.

· Annex B to be read.

· Key for Uplink and Downlink for FOpts is NwkSEncKey. Dir=0 for Uplink and 1 for downlink. We call encrypted FOpts as pld.

· Following is Block A which is encrypted to get Block S. Encryption left.

2.3.1.7 Class B

· Class B bit set to 1 in uplink to tell Network that device is ready to switch to class B.

2.3.2 FPort

· Should be present, if Payload field is not empty. If 0, MAC commands in Payload.

· For 1...223- Application specific. Dealt by App layer.

· FPort 224 is for MAC layer test protocol. To be read (Part of App Layer).

· N<=M-1, N=FHDR Len, M=Max MAC Payload Length.

2.3.3 MAC Payload Encryption

· Encrypted before MIC. If FPort=0 NwSEncKey, others AppSKey. Algorithm Steps.

· pld= Frame payload. You generate A blocks for

2.4 Message Integrity Check (MIC)

2.4.1 Downlink Frame

· It is done for all the field be it MHDR, FHDR, FPort, FOpts.

· cmac= aes128cmac (SNwkSIntKey, B0/msg).

· MIC=cmac [0…3].

· For downlink frame, if Ack bit is set than it is acknowledgement frame of confirmed Uplink frame. ConfFCnt is the frame counter of Confirmed Uplink Frames being Ack. Ow 0x0000.

2.4.2 Uplink Frame

· TxDr being Data Rate, TxCh being index of channel, ConfFcnt is counter frame of the downlink frame for which this acknowledgement is, if it is, ow 0x0000.

· For LORAWAN1.0. MIC = cmacS=aes128_cmac (SNwkSIntKey, B1 | msg).

· For LORAWAN1.1 MIC=cmacS | cmacF where cmacF aes128_cmac (SNwkSIntKey, B0 | msg).

Chapter 3: MAC Commands

· We will now discuss about the MAC commands that are being transported OTA and what different commands mean and sent by whom. Communication between Network Server & MAC Layer of the end device. Either sent in FOpts field or FRMPayload with FPort 0.

· If answer to MAC command doesn’t fit in the FOpt field, it goes in FRMPayload with port0.

· B/w App payload and MAC answers, MAC answers are given priority in the frame.

· It may happen that answers to the sequence of MAC commands is greater than the FRMPayload length consequence of truncation of last in sequence commands answers & Network may send the commands again and get no answer.

· The network decides the command wasn’t reached successfully when he sees no answer in the new uplink.

· If end device sends MAC command and doesn’t receive ack in rx window slot, he does the retry mechanism.

· Unknown MAC Commands terminates the processing of MAC command seq. Thus, order of MAC seq. should be such that new to version command are kept last.

3.1 Reset Indication Command (ResetInd, ResetConf)

· Only for ABP devices. OTA Reset commands are discarded.

· Sent by the end-device.

· With ResetInd, ABP indicates network that all its MAC and radio parameters are reset to the ones defined at its fabrication.

· Reason-being battery replacement because of which MAC layer context is lost from RAM.

· NOTE: ABP never resets its frame counters (neither uplink or downlink).

· ResetInd includes the minor of the LoRaWAN version supported by the end device.

· ResetInd is responded by ResetConf with single byte command containing the Serv LoRa version which should match the end device’s version, ow discarded& ResetInd Uplink again.

3.2 Link Check Commands (LinkCheckReq, LinkCheckAns)

· It is to check connectivity in the link. End device sends LinkCheckReq.

· Through one/multiple gateways, it reaches to network server which replies using LinkCheckAns, Link Margin (8-bit unsigned integer to represent link margin in dB, 0 means at noise floor, 20 being how much above it) and no. of gateways in Gwcount it reached.

3.3 Link ADR Commands (LinkADRReq, LinkADRAns)

· Network Server requests an end-device to perform Adaptive data rate.

· Tx output power given in the field is its max. If 15, no changes in this parameter.

· The channel mask field is 2 bytes to choose b/w the 16 channels. If corresponding to the channel, bit is 0 means channel shouldn’t be used, if 1 can be used if provides req. data rate.

· In redundancy, NbTrans field is by default 1 for single tx and can vary b/w 1 to 15.

· ChMaskCntl is defined in PHY.

· Multiple contiguous Lin kADRReq are called atomic block command. Restricted to one and only one LinkADRAns for the whole. If more atomic block in downlink, only first is read and others are sent NAck (All status bits in Ans is 0).

Parameter

Bit=0

Bit=1

Channel Mask ACK

Undefined, all disabled, discarded

Ch mask sent Successful

Data Rate ACK

Unknown, not possible in this channel, discarded

Successfully set or it was 15

Tx Power ACK

Can’t operate below the requested level

Can operate or it was 15

· If anyone is 0, command was unsuccessful.

3.4 End Device Duty Cycle (DutyCycleReq, DutyCycleAns)

· Network Coordinator to restrict

· DutyCycleAns has no payload.

3.5 Receive Window Parameters (RXParamSetupReq, Ans)

· Offset for RX1 window and Frequency and data rate for RX2.

· Offset is 0 by default and changes w.r.t. regulations in areas of base station. For RX2, Channel and frequency parameters are sent.

· Ans is of one-byte status and contains info. If the parameters have changed.

Parameter

Bit=0

Bit=1

Channel ACK

Not usable

Successful

RX2 Data Rate ACK

Unknown data rate

Successful

RX1 Data Rate Offset

Offset out of range

Successful

3.6 End Device Status (DevStatusReq, Ans)

· DevstatusReq has no payload.

· Devstatus answer command has battery (8 bit field: 0 means connected to external source;1-253 are different levels; 255- Unsuccessful) and margin field of the last successfully receive DevStatusReq command (8 bit signed field, -31 to 32 dB).

3.7 Creation/Modification of Channel

3.7.1 NewChannelReq/Ans

· Not applicable in scenarios of fixed channel plan.

· NewChannelReq to modify parameters of existing channels or create new one. Changes centre frequency and data rate range. ChIndex (1), Freq(3), DRRange(1).

· ChIndex defines which channel index you are playing with. Default channels are common to all nodes and is b/w 0 to 15. In some regions, more than 16 is also accepted. [PHY]

· Freq being 24-bit field. Freq*100 (Below 100M RFU, 100M to 1.6GHz). 0 disables channel.

· DRRange= 0x77 => 50kbps GFSK. 0x50 => DR0 to DR5 on 125KHz supported.

· NewChannelAns contains status bits for DataRateOk and ChannelFreqOk

· If bit=0, Exceeding limits/can’t use and bit=1 is good to go for both.

3.7.2 DIChannelReq

· To allow different downlink freq to RX1 slot.

· ChIndex defines channel to change and 24-bit field freq defines its downlink freq change.

· Ans of this of 2-bit and is sent in FOpt unless modified downlink is received. 1^st bit checks if UplinkFreq exist, if not (0), u can’t modify. 2^nd bit is if you can use this frequency.

3.8 Setting Delay b/w tx and rx (RXTimingSetupReq)

· RXTimingSetupReq has is 1-byte field with 3:0 is delay mapped into 0to15seconds.

· Ans in FOpt field until received required downlink.

3.9 End-device TX Parameters (TXParamSetupReq)

· Setting dwell time and EIRP.

Figure 5. EIRP_Dwelltime_payload

· Bits 4 & 5 if 1 dwell-time 400ms ow 0.

· Ans has no payload. If sent in inappropriate region, no ack.

3.10 Rekey indication command (RekeyInd)

· Only for OTA devices, not ABP.

· This command is sent soon after the Join Accept to confirm the keys and the minor. All uplinks should include this until require downlink comes between ADR_ACK_LIMIT otherwise the end device goes back to Join State again.

· In Rekeyconf, server sends its LoRaWAN version in same format that should be <=to device’s LoRaWAN version ow discarded.

3.11 ADR Parameters (ADRParamSetupReq)

· To change ADR_ACK_LIMIT and ADR_ACK_DELAY for ADR-back off algorithm.

Bits

7:4

3:0

ADRParam

Limit_exp

Delay_exp

· ADR_ACK_LIMIT = ; ADR_ACK_DELAY = .

· Ans has no payload.

3.12 Device Time Commands (DeviceTimeReq, Ans)

· End-device asks network to give him the current date and time with no payload.

· Network gives the time of the last received uplink, the GPS Epoch Time.

· Since Jan 6^th, 1980, on 12^th Feb 2016 at 14:24:31, it was 113822288.

3.13 Force Rejoin Request Command

· Network asks the device to immediately transmit RRT 0 or 1 with periodicity, payload, DR.

· Period: Delay b/w retransmission

· Max_Retries: 0=>0+1;1=>1+1=2 retries and so on.

· Rejoin type 0 or 1.

· DR. No answer. Mandatory for end device to answer.

· If device gets NewForceRejoinReq before previous’ Max_Retries, goes with New.

3.14 RejoinParamSetupReq

· This is sent by the network to end device to indicated device that he must RejoinReq type-0 messages after ever X Uplinks and Y Time.

· Being single-byte payload. 3:0 is MaxCountN which has C, making count= ; 7:4 is MaxTimeN which has T, making time= .

· Time bound is optional and is indicated in TimeOk bit field of answer if 1=accepted ow no.

· For lowdatarate and no time capability, LoRaWAN, mechanism to agree on count is not defined.

Chapter 4: End-device Activation

· In order, to get a device into activation in a network, either OTAA or ABP.

4.1 Data Stored in End-Device

4.1.1 Before Activation

4.1.1.1 Join EUI

· Global application ID of Join Server for processing the join-procedure. Must in OTA, not req in ABP.

· Defines the server that assists in the Join-Procedure process and Session keys derivation.

4.1.1.2 Dev EUI

· This is global application ID which identifies end-device. Must there before join procedure.

· Required in OTA, recommended In ABP. Also available on label for device administration.

4.1.1.3 Device root keys

· NwkKey & AppKey are AES-128 root keys specific, at fabrication. NwkKey=> FNwkSIntKey, SNwkSIntKey, NwkSEncKey. AppKey=> AppSKey.

· We can use join procedure to know NwkKey without knowing AppSkey.

· Both NwkKey & AppKey should be stored safe in hardware. For earlier version (<=1.0), don’t support both keys, one root key scheme. Network uses “Optneg” bit of DLSetting to indicate this. NwkKey is used to derive AppSKey and FNwkKey.

· FNwkSIntKey & SNwkSIntKey = FNwkKey for uplink & downlink MIC cal., encryption.

· NwkKey & AppKey must be stored in OTAA procedure, and securely stored.

4.1.1.4 JSIntKey & JSEncKey derivation

· Lifetime keys derived from NwkKey, JSIntKey for MIC of Rejoin-Request type 1 messages and JSEncKey to encrypt Join-Accept triggered by Rejoin-Request.

4.1.2 After Activation

· After activation, device has to store some additional info, device address (DevAddress), triplet of Session Keys (NwkSEncKey/SNwkSIntKey/FNwkSIntKey) and AppSKey.

4.1.2.1 End-Device Address

· N is integer b/w [7:24].

· Var size AddrPrefix represents NetId for assuring the current network while roaming. Some AddrPrefix values are not assigned by LoRa alliance but by any private/exp network.

· NwkAddr is arbitrarily assigned by network.

4.1.2.2 Forwarding Network Session Integrity Key (FNwkSIntKey)

· Used for calculating MIC or part of MIC for uplink Messages. (Store safely)

4.1.2.3 Serving Network Session Integrity Key (SNwkSIntKey)

· To verify MIC of downlink messages and cal. MIC for half of Uplink Messages.

· For LoRaWAN 1.0 and below, one key which FNwkSIntKey handles all.

4.1.2.4 Network Session Encryption Key (NwkSEncKey)

· Specific to device and used to encrypt & decrypt MAC command tx as payload on port-0 or in FOpt field. In LoRaWAN 1.0, FNwkSIntKey for MAC payload encryption and MIC calc.

4.1.2.5 Application Session Key (AppSKey)

· Used by end device and application server to encrypt and decrypt application specific payloads. End-to-end encrypted but hop-to-hop integrity protected.

· First hop, end device to Network Server and Network Server to application server. Network could be malicious, or it can help Network grab some info about data.

· There are end-to-end security solutions for app server but not defined here.

· Network Session (FNwkSIntKey, NwSEncKey, FCntup, FCntdown (1.0) or NFCntDown (1.1), DevAddr.

· Application Session (AppSKey, FCntup, FCntdown (in 1.0) or AFCntDown (int 1.1).

· Both sessions taken together form “Session Context”.

· Upon completion of OTAA and ABP procedure, a new security context exists in which for a fixed duration of time session (FNwkSIntKey, SNwkSIntKey, AppSKey, DevAddr) remains same and counter values are exchanged.

· Same frame counters can not be used for the same keys, therefore new session keys context should be established well before saturation of a frame counter.

· Session should be maintained across power cycling ow activation procedure executed on every power cycle.

Chapter 5: Over-the-air Activation

It requires to first have a join procedure before data transport to facilitate information of session context. If Session context is lost, new join procedure is sent.

Different network keys for different networks for a roaming node.

5.1 Join-Request Message

· Initiated by end-device to connect to a network. Sent with JoinEUI and DevEUI and DevNonce that is the count of such messages which must incremented with every message.

· Network discards Join-Req Message of same JoinEUI and DevNonce.

· Can be used to avoid replay attacks by sending previously recorded joint-req message.

· Both new and old context are saved until first successful uplink is received.

· Not encrypted, any data rate, random frequency hops.

5.2 Join-Accept Message

· Response from Network to Join Request received from end device.

· Like a normal downlink with delays named JOINT_ACCEPT_DELAY1 OR JOINT_ACCEPT_DELAY2. Freq and DR same as that of RX Windows.

· Server Nonce, DL_Set downlink parameters, TX-RX delay, CF: Network Param list.

· JoinNonce is used to derive the Session Keys, incremented every J-A Message. End-device only accept the messages when this is greater than the previous stored one.

· If device is power cycled, this is to be stored in non-volatile memory.

· Alliance allocated 24-bit NetID to all networks other than reserved ones, also a home_netID.

5.2.1 DL Settings

· DL Settings bit fields

· If Optneg bit is unset,

1. you got to use LORAWAN1.0.

2. RekeyInd commands can’t be sent.

3. NwkKey to derive FNwkSIntKey & AppSkey.

4. SNwkSIntKey and NwkSEncKey equal to FNwkSIntKey.

5. Keys and Mic are derived using aes_128(combinations JoinNonce,NetID,NwkKey)

· If Optneg is set

1. Version 1.1 or later and protocol version can be further negotiated using RekeyInd commands. NwkKey to derive FNwkSIntKey & SNwkSIntKey &NwkSEncKey.

2. AppSKey from AppKey.

Figure 6. Depicting difference in encryption for version 1.0 and 1.1

· NOTE: Join Request Messages uses aes_128_decrypt commands so that end-device only must compute aes_128. Why, computation power?

5.2.2 RX1DROffset

Described as before, relation b/w RX1 downlink and uplink.

5.2.3 Procedure

If the Join-Accept Message is received following the tx of:

1. If Join-Request and Rejoin-Request Type 0 or 1. If CF-List is absent, the device will go for default channel definition. If present, overrides all currently defined channels. Even MAC layer parameters are set to default.

2. If Rejoin-Request Type 2, if CF-List is absent, channel & MAC Layer parameters remain unchanged.

3. Successful processing of Join-Accept message should be followed RekeyInd command until Rekeyconf is received. Signal to switch to new security context.

5.3 Rejoin-Request Messages

5.3.1 Introduction

· Periodic Rejoin Messages can be sent by the end-device to initialize new session context.

· Network replies with Join-Accept Messages to be used to hand-over a device b/w two networks, or to rekey or change dev Addr.

· This can also be used to inform the network about some info. say RX2 window DR or DROffset for RX1 window which is not receiving downlink.

· Network responds with Join-Accept Message. Again, store the old security context unless uplink frame with new context is successfully received and then discard it.

· Rejoin byte field describes which type. Different types for different purposes.

Type

Purpose

Contains NetID+DevEUI; Routed to Home Network (coz only he knows MIC of it); to reset all device context

Contains JoinEUI+DevEUI; Equivalent Join-Request Message but need not disconnect device; transmitted on top of applicative traffic; to gain lost session context; MIC with Join Server; Network lost session Key and can’t connect end device with Join Server.

Contains NetID+DevEUI; To rekey; to change device address; radio param kept unchanged; MIC with home network.

5.3.2 Type 0 and 2

· Contains NetID of home network, own DevEUI, RJcount0 is keep account of no. of Rejoin Req. Incremented on every req; to 0 if Join Accept comes; Network has record of RJcount0 and rejects the ones with values lesser or equal to previous.; can’t be more than 2^16-1; if reached stop and go to Join state.

· Replay Attacks are avoided by this mechanism of record of Rejoin-Request Messages.

· Rejoin-request message is not encrypted; its MIC is calculated using cmac; duty cycle less than 0.1%

· Used to reconnect roaming end-devices to new networks.

· Mobile devices need to transmit this more freq than static.

· Type 2 are only for rekeying.

5.3.3 Type 1

· Contains JoinEUI, so can be routed to Join Server, restore connectivity; in case of complete state loss with network server. RJcount1 is just like 0 and used to prevent replay attacks; MIC key is generated using JoinEUI; Message not encrypted; duty cycle < 0.01%; used in complete loss of context; can be transmitted once a week cause this highly unlikely.

5.3.4 Rejoin-Request-Transmission Parameters

· For 0&1, tx on defined Join Channels.

· For 2, on any of the current enabled channels.

· 0&2 by following ForceJoinReq should use data rate specified in MAC commands.

· Periodicity set by RejoinParamSetupReq. 1 shall use data rate and tx power currently used in application payloads if ADR is set. Ow any data rate if ADR not set. Recommended to use a plurality of data rates.

5.3.5 Rejoin-Request Message Processing

· Can reply with Join-Accept message if it wants to modify network parameters or normal downlink containing MAC Commands.

5.4 Activation by Personalization

· Not deriving the DevAddr and four session keys from DevEUI, etc, they are already there stored in the end-device which makes device capable of connecting to the network as it starts.

· This info couldn’t be derived publicly through node address or whatever for security.

· Unique set of keys can’t be changed using Rekey, that’s why OTAA are safer.

· Should send ResetIndSet command in FOpt field until gets ResetConf.

5.5 Retransmission Back-off

· Uplinks that are “confirmed” and retransmit if don’t receive acknowledgement and that can be triggered by an external event causing synchronization can trigger a catastrophic situation.

· For example, all devices will not stop sending join-request command if they reset the MAC layer for some reason until they have join-accept. In such cases,

· RX2 Slot and next uplink time interval should be governed by the PR sequence, so that everyone is able to perform it successfully. Regulations should be kept in mind.

Chapter 6: Class B

6.1 Introduction

· Battery powered mobile or mounted device where required to open RX window periodically.

· Class A follows ALOHA method which doesn’t define a known downlink time for network.

· Purpose is to have end-device available for reception for known times & also followed by random uplink transmission from end-device of Class A.

· Beacon is sent regularly to synch all end-devices in network to have an addition reception window of periodic time during a periodic time slot. (Called ping-slot).

· Managed not by LoRaWAN but application layer. One of device’s uplink is used to send a downlink to the application layer of the end-device which must be there.

6.2 Principle of Synchronous Network Initiated Downlink

· Broadcasting a beacon to give time reference to periodically open rx windows (ping-slots) which can be used by network infrastructure to initiate downlink communication.

· Downlink is called “ping”. Gateway is chosen by network server depending upon last uplink SNR. For moving devices, new uplinks update downlink routing path.

· Prerequisites to network for making end device Class B: Default ping-slot period,dr,channel.

· Every end-device starts with Class A. Procedure to switch to Class B is through application

1. Devices’ application request LoRaWAN layer to switch. LoRaWAN searches for Beacon and either return Beacon_locked or not_found. “DeviceTimeReq” is used to accelerate the beacon discovery. Now in Class B

2. To notify the switch to server, MAC layer of end-device set Class B bit of FCtrl field of uplinks. Automatic ping-slot to receive beacon, LoRaWAN forwards the beacon content to application layer with signal strength and maximum clock drift

3. Periodic updates of location are given by empty uplinks with Class B bit of FCtrl field set of uplinks. More efficiently, if application detects that the node is moving by analysing beacon content.

4. PingSlotChannelReq MAC command to change parameters of Downlink.

5. To change periodicity, B mode paused to send PingSlotInfoReq, after ack of which resume.

6. If beacon is not received b/w defined time-slot. MAC layer informs Application to switch back to Class A. No class-B bit in uplinks, retries to become B periodically from step-1.

· Mostly, preamble is not detected, end-device reception window closed. On preamble detection, transceiver is on until downlink frame is demodulated. MAC layer processes the frame, checks the address field if it matches device address & also MIC.

6.3 Uplink Frames in Class B Mode

· Difference in RFU bits as compared to Class A. (I didn’t see any L)

· Class B bit to indicate network that end-device is ready to receive scheduled downlink pings.

· FPending to indicate device that downlink messages are queued for him to keep window on.

6.4 Downlink Ping Frame Format

6.4.1 Physical Format

· A different channel frequency plan may be followed, otherwise same.

6.4.2 Unicast and Multicast MAC messages

· Unicast for one end-device and multicast for many.

· All multicast devices must share a common multicast address & associated encryption key.

· Not possible to remotely setup a multicast group or securely distribute multicast key material and can only be achieved using node personalization or through application layer.

6.4.3 Unicast MAC Message Format

· Same as class A type but same frame counter whether using Class B ping slot or Class A piggybacked slot.

6.4.4 Multicast MAC Message Format

· Major differences are

1. Can’t put MAC commands in FOpt field or payload on port 0 because multicast downlink does not have the same authentication robustness as a unicast frame.

2. ACK and ADRACKREQ bit must be 0. MType should be Unconfirmed Data Down.

3. FPending indicating more multicast data to be sent.

6.5 Beacon Acquisition & Tracking

· Before switching to class B, end-device must receive a beacon to adjust its time reference with network. Afterwards, periodically receiving beacon to cancel any clock drifts. If can’t receive beacon periodically, gradually widens its beacon and ping slots to check drifts.

6.6 Minimum Beacon-less operation time

· If beacon loss, go for class b type for another 120 minutes, called “becon-less” operation.

· Windows progressively expanded to accommodate end-device’s possible clock drift.

6.7 Minimizing timing drift

· End-device uses beacon to help correct his clock precision.

· Use of temperature sensor to minimize clock drift.

6.8 Class B Downlink Slot timing

· It is must that our reception windows open at precise time w.r.t. beacon.

· Guard-frame in which no other ping-slot can be forcefully inserted and is equal to ToA of the longest allowed frame so as to facilitate timing flexibility to downlink.

· Usable time period for ping-slots is between end of Beacon-reserved and start of guard.

· Beacon frame time is much lesser than reserved frame.

· Beacon window interval is divided into 4096 ping-slots of 30ms each and if end-device wants to listen to beacon at Nth ping-slot, then he must open its receiver after beacon_reserved_time + N*30 ms.

6.9 Slot Randomization

· This is to prevent collisions between different ping-slots.

· Technique used for Slot Randomization:

· At each beacon period, the end-device and the server compute a new pseudo-random offset to align the reception slots. If device is having both unicast and multicast reception slots, then multiple computation are performed for both. On collision, multicast is given priority and on collision between multicasts, FPending bit sets the priority.

Report abuse