Research ArticleTRILO A Traffic Indication-Based DownlinkCommunication Protocol for LoRaWAN

Youngjune Oh 1 Jongwon Lee2 and Chong-Kwon Kim 1

1Department of Computer Science amp Engineering Seoul National University Seoul 08826 Republic of Korea2Department of Computer Science amp Electrical Engineering Handong Global University Pohang Z37554 Republic of Korea

Correspondence should be addressed to Chong-Kwon Kim ckimsnuackr

Received 27 April 2018 Revised 23 July 2018 Accepted 27 August 2018 Published 10 September 2018

Academic Editor Andrea Zanella

Copyright copy 2018 Youngjune Oh et al This is an open access article distributed under the Creative Commons Attribution Licensewhich permits unrestricted use distribution and reproduction in any medium provided the original work is properly cited

LPWAN (Low-Power Wide Area Network) technologies such as LoRa and SigFox are emerging as a technology of choice for theInternet ofThings (IoT) applications where tens of thousands of untethereddevices are deployed over a wide area In such operatingenvironments energy conservation is one of the most crucial concerns and network protocols adopt various power saving schemesto lengthen device lifetimes For example to avoid idle listening LoRaWAN restricts downlink communications However theconfined design philosophy impedes the deployment of IoT applications that require asynchronous downlink communicationsIn this paper we design and implement an energy efficient downlink communication mechanism named TRILO for LoRaWANWe aim to make TRILO be energy efficient while obeying an unavoidable trade-off that balances between latency and energyconsumption TRILO adopts a beacon mechanism that periodically alerts end-devices which have pending downlink frames Weimplement the proposed protocol on top of commercially available LoRaWAN components and confirm that the protocol operatesproperly in real-world experiments Experimental results show that TRILO successfully transmits downlink frames without losseswhile uplink traffic suffers from a slight increase in latency because uplink transmissions should halt during beacons and downlinktransmissions Computer simulation results also show that the proposed scheme is more energy efficient than the legacy LoRaWANdownlink protocol

1 Introduction

The Internet of Things (IoT) interconnects ldquoallrdquo things in-cluding sensors actuators gateways and everyday productssuch as watches and various wearable devices The IoTecosystem includes heterogeneous applications with diversi-fied performance and functional requirements To supportdiversified IoT applications operating on a broad spectrum ofdevices multiple heterogeneous technologies should be har-moniously applied The exigency of applying plural enablingtechniques is particularly apropos in the area of networkinga single network technique cannot satisfy contradictive net-working requirements of diverse IoT applications In additionto traditional wireless network technologies such as cellularand WiFi networks a plethora of WPAN (Wireless PersonalArea Network) schemes including ZigBee Z-Wave IETF6LowPAN and Bluetooth Low Energy (BLE) can easily findareas of applications in the IoT ecosystem Equipped withlow-cost and power conserving capabilities these network

technologies compensate functional or economical cracksengendered by cellular or WiFi networks However mostWPAN technologies are designed for short range communi-cations and consume abundant energy to support low latencyasynchronous bidirectional communications

Recent years have witnessed explosive attentions onLow-Power Wide Area Network (LPWAN) technology as ameans to fill the gap that existing network technologies leavebehind LPWAN targets to provide low-rate high-latencycommunication capabilities to large numbers of IoT devicesthat are scattered over expanded areas such as campus townor city [1 2] Because it is difficult to manage widely scattereddevices LPWAN protocols are designed to sustain the life-times of devices more than ten years with a coin cell batteryTo achieve both the long-range transmission and energyconservation goals LPWAN adopts robust modulation andsimple one-way communication protoscols respectively

Among many LPWAN alternatives this paper deals withthe LoRa [3] and LoRaWAN [4 5] technologies LPWAN

HindawiWireless Communications and Mobile ComputingVolume 2018 Article ID 6463097 14 pageshttpsdoiorg10115520186463097

2 Wireless Communications and Mobile Computing

technologies can be classified into two categories one oper-ating in licensed bands and another in unlicensed bands The3GPP [6ndash9] has standardized two open standard protocolscalled LTE-M and NB-IoT [10 11] that utilize the cellularinfrastructure Recently Lauridsen et al [12] reported exten-sive experimental performance results which show that NB-IoT and LTE-M schemes have contradictive characteristicsand each has an advantage over the other depending onapplication areas LoRa [3] SigFox [13] RPMA [14] andWeightless [15] are examples of noncellular technologies thatoperate in unlicensed spectrums In addition to the free useof wireless spectrum resources LPWAN technologies pro-vide the advantages of network ownership and autonomousoperation of networks However most of the LPWANsare proprietary techniques and cannot leverage the widelydeployed cellular infrastructure

Employing robust and less efficient modulation andsacrificing transmission speed LoRa achieves long-rangetransmissions over 10 km In addition LoRaWANachieves anunprecedented energy conservation capability by restrictingdownlink communications LoRAWAN Class A end-devicesstay in the sleep state as a norm and wake up only whenthey need to transmit uplink traffic While LoRaWAN sup-ports uplink transmissions like other protocols downlinktransmissions are allowed only as a response to uplinkpackets As a result LoRaWAN eliminates idle listeninga root cause of energy consumption in communicationsThese characteristics and limitations of LoRa and LoRaWANindicate that they are optimized for applications that donot require high throughput or low latency data deliv-ery

In this paper we embark on the design of an energyconservative downlink communication protocol on top of theLoRaWAN protocol Let us start with a brief introductionof the LoRaWAN protocol LoRaWAN forms a star-of-starstopology consisting of end-devices gateways and servers Aserver is connected to multiple gateways each of which againis connected to multiple end-devices A gateway assumesa role similar to a WiFi Access Point (AP) A gateway isconnected tomultiple end-devices via the LoRawireless tech-nology Note that a LoRaWAN does not support multihopwireless transmissions all end-devices are directly connectedto gateways LoRa is particularly designed for massive IoTsover a wide area and a single LoRaWANnetwork can supporttens of thousands of end-devices each of which emits shortpackets infrequently

LoRaWANdefines three classes of end-devices dependingon the level of energy conservation and the demands fordownlink transmissions A Class A node abnegates the recep-tion of asynchronous downlinks by staying mostly in a sleepmode turning off its radio It only wakes up for uplinktransmissions as such demands occur Class C end-devicesoperate in an always-on mode which allows asynchronousdownlinks as well as uplinks Class C end-devices assume thecontinuous supply of power or their lifetimes would bemuchshorter than those of Class A devices Class B end-devicesalso support downlinks in addition to uplink transmissionsUnlike uplink transmission that can be initiated at any timedownlinks should be synchronously scheduled according to

the requests from end-devices They use beacons to maintaintime synchronization between a server and end-devicesClass B nodes wake up at scheduled intervals periodicallyeven if there are no downlinks for them We aim to devise anew downlink protocol which aims to be more energy effi-cient and flexible than the LoRaWANrsquos Class B downlinkscheme

The proposed downlink protocol named TRILO is basedon the beacon mechanism Like the IEEE 80211 WLANswhere an AP coordinates communications ofmultiple mobilestations a gateway in a LoRaWAN can broadcast frames to allend-devices Beacons are an efficient signalling mechanismbecause a broadcast beacon can alert multiple end-deviceswith a single message In addition to beacons a pollingmechanism to announce the readiness to receive downlinksmust be provided A polling scheme should be designedcarefully such that it fully exploits the physical characteristicsof the underlying LoRa protocol We consider two pollingalternatives concurrent polling and sequential polling Wechoose sequential polling because a performance comparisonindicates that sequential polling is more effective in powersaving than concurrent polling (see Figure 6)

We implemented TRILO on commercially availableLoRaWAN components For a gateway we used a RAK831board which contains a SX1301 concentrator chip The con-centrator board is attached to a Raspberry Pi 3 board Anend-device is implemented on a NUCLEO-L073RZ boardwith an embedded LoRaWAN chip using 915Mhz antennaThe SX1272MB2DAS component is attached to a NUCLEO-L073RZ board with a modified LoRaMAC that includesour proposed scheme Note that a network server andend-devices are communicating entities in the LoRaWANarchitecture gateways assume a passive role relaying framesbetween end-devices and a server

We confirmed that the devised downlink protocol workscorrectly via real-world experiments Extensive experimentswere also conducted to collect important performance mea-sures such as PDR (PacketDeliveryRatio) latency and powerconsumption An experimental network which consists ofone gateway and 15 end-devices is deployed to our officebuilding Experimental results show that TRILO operatescorrectly All end-devices receive beacons and downlinkframes successfully The PDR of downlinks is almost 100 inmost experiment setups Under an assumption that downlinktraffic to each end-device is not heavy the extra wake-uptimes required for maintaining and supporting downlinkframe transmissions are minimal

We also compare the performance of TRILO with thatof Class B downlink protocol via computer simulationsPower consumption is an important performance metric inLoRaWANWe measure the efficiency of downlink protocolswhich is the ratio of the actual data transmission time to theduty cycle Simulation results show that the proposed proto-col performs significantly better than the Class B schemeTheproposed scheme shows 37 times to about 146 times betterefficiency than the Class B downlink protocol

The contributions of this paper are as follows(i) We propose a new energy efficient downlink protocol

called TRILO for LoRaWAN TRILO is customized to the

Wireless Communications and Mobile Computing 3

physical and network properties of LoRa and LoRaWAN Inparticular we aim to devise a protocol that is more energyefficient than synchronous downlink mechanism developedfor LoRaWANrsquos Class B

(ii) We devise two polling mechanisms called con-current polling and sequential polling Concurrent pollingbest exploits the LoRarsquos capability that supports simultane-ous receptions of multiple packets However the analysisindicates that sequential polling is more energy efficientthan concurrent polling and we adopt sequential poll-ing

(iii) TRILO is implemented on commercially availableLoRaWAN components Modified LoRaWAN componentsoperate properly in real-world experiments

(iv) We conduct experiments with modified LoRaWANdevices Our performance study shows that PDR is almost100 for both uplink and downlink traffic and the extrawake-up times to maintain and support beacons and downlinkpackets are minimal

(v)We conduct computer simulations to compare the per-formances of TRILO and the LoRaWANrsquos Class B downlinkprotocol Our performance study shows that the proposedscheme which minimizes unnecessary receive window allo-cations is significantly more energy efficient than the legacyLoRaWAN

The rest of the paper is organized as follows We beginwith the related work highlighting several low-power MACmechanisms We then give a brief primer on LoRa andLoRaWAN focusing on the features of LoRa and LoRaWANthat are closely related to the design of downlink protocolsNext we describe the proposed beacon based downlink pro-tocol Two polling methods concurrent polling and sequen-tial polling are explained We compare the wake-up timesof the two polling methods and show that sequential pollingis more energy efficient than concurrent polling Then theimplementation details of TRILO and performance resultsobtained from real-world experiments are described Wealso illustrate the performance comparison of TRILO andthe LoRaWANrsquos downlink protocol Lastly conclusion sum-marizes the paper and discusses several future researchproblems

2 Related Work

Energy is one of the precious resources that should bemanaged carefully in battery powered mobile devices Manyresearchers have studied energy conservation schemes invarious scenarios This section reviews several exemplarypower saving schemes

Basically almost all energy conservation schemes try tominimize the duty cycleThe literature can be partitioned intotwo categories depending on the type of communicationsone to one communications and one to many communica-tions Usually one to one communication is between twodevices of the equal capabilities On the other hand in mostone to many networks a central node enjoys unlimitedpower supply from a powerline while many others arebattery poweredmobile devices For example aWiFi networkconsists of one AP (Access Point) and many mobile stations

Asmost prior works we focus on the energy conservation forbattery powered devices

Many clever low-power MAC mechanisms have beendesigned forWSNs (Wireless Sensor Networks) which imple-ment multihop wireless networks over WiFi networks or theIEEE 802154 standard protocols Even though base networktechnologies support one to many communications neigh-bour nodes in mesh networks assume peer to peer commu-nications The energy conservation mechanisms for WSNscan be classified by several criteria such as synchronicity andsender- or receiver-initiated The two most widely deployedprotocols ContikiMAC [16 17] and TinyOS LPL [17 18]are asynchronous sender-initiated protocols and are imple-mented on two de facto standard operating systems Contiki[16] and TinyOS [18] respectively In sender-initiated proto-cols a sender transmits a packet repeatedly for a time longerthan a predetermined duty cycle interval A receiver oper-ates in the duty cycling mode it wakes up at every dutycycle interval and listens for a possible transmission from thesender

Bluetooth Low Energy (BLE) [19] is another networktechnology that requires one to one energy conserving MACBLE aims for the lifetime from several months to years with acoin cell battery [19] The BLE neighbour (device) discoverymechanism is an asymmetric scheme where each deviceplays the role of either an advertiser or a scanner To bindwith another BLE device an advertiser transmits advertisingpackets periodically at every scheduled advertising eventA scanner also turns its radio on repeatedly at every scan-ning events Applying the Chinese Remainder TheoremKandhalu Xhafa and Hosur [20] devised a BLE neighbourdiscovery mechanism that guarantees eventual rendezvousof advertisers and scanners To avoid the ill-fated case thatboth advertiser and scanner choose the same prime numbereach device selects two prime numbers and wakes up at everyinteger multiples of the primes

Several researchers have proposed newneighbour discov-ery schemes that reduce discovery latency power consump-tion and reliability of the BLE device discovery mechanismUnlike the legacy BLE devices whose roles are fixed to eitheradvertiser or scanner at the production time [21] assumedthat devices could change their roles dynamically Theydevised a new neighbour discovery protocol customized forsuch environments Contrary to the prior methods that usetime slots BLEnd [22] demises the slot structure and reducesthe discovery delay Nihao [23] improves the latency andreduces energy consumption by increasing advertisementsand decreasing scanning times

One notable energy conservation protocol for one tomany communications is the IEEE 80211 PSM (Power SavingMode) An Access Point (AP) periodically broadcasts bea-cons to notify mobile stations that have pending downstreamframes Inspecting a beacon frame idle stations withoutbuffered downlinks turn their radio off immediately untilthe next beacon interval Backlogged stations request fordownstream packet transmissions by sending poll messagesto the AP Upon the delivery of downlink frames backloggedstations also fall back to the sleep state until the nextbeacon

4 Wireless Communications and Mobile Computing

EU868

EU433 hellipKR

920AS430

US915

LoRa Modulation

Applications

LoRa MAC

Class A Class B Class C

LoRa Specifications

LoRaWAN specifications

Figure 1 LoRa and LoRaWAN specifications

Table 1 Frequency bands and bandwidths allocated for LoRa

Location Europe North America Korea China JapanFrequencyband(MHz)

867-869 902-928 920-923 470-510779-787 920-925

Channels 10 64+8+8 13 - -Uplink CH BW(KHz) 125250 125500 125 - -Downlink CHBW(KHz)

125 125 125 - -

Tx power Up(dBm) +14 dBm +20sim+30 dBm +10sim+14 dBm - -

Tx power Down(dBm) +14 dBm +27 dBm +23 dBm - -

3 A Primer on LoRa and LoRaWAN

This section contains a brief overview of LoRa and LoRaWANtechnologies Specifically technical properties that influenceor limit the design space of LoRaWAN based downlinkprotocol will be addressed

Figure 1 shows the protocol stack of LoRa and LoRaWAN[4] LoRa developed and owned by Semtech [3] is a proprietytechnique that defines a physical layer customized for LPWAcommunications LoRaWAN which defines a MAC layer ontop of LoRa is an open standard developed by a nonprofitorganization called LoRa alliance LoRa operates on the900MHz ISM spectrum and adopts the CSS (Chirp SpreadSpectrum) modulation technique CSS [24 25] based onchirped-FM modulation yields high processing gains andenables long transmissions at the expense of data rates LoRasupports Adaptive Data Rate (ADR) which varies data ratesadapting to transmission distances and channel conditionsWhen the SNRs are low LoRa lowers the data rate to severalhundred bits per second by using large SF (Spreading Factor)and robust CR (Coding Rate)When SF and bandwidth (BW)are selected the data rate 119877119878119865 is determined as 1198781198652119878119865 ∙119861119882 The lowest data rate of LoRa determined at SF=12 andBW=125 KHz is approximately 300 bits per second Thehighest data rate is approximately 11 Kbps and is obtained atSF=7 and BW=250 KHz High data rates can be achievablewhen channel conditions are good SF=7 requires -120 dBmwhile SF=12 requires only -136 dBm

Each country allocates different frequency bands andbandwidth for LoRa Table 1 illustrates the frequency bandsbandwidth and transmission powers defined by the regula-tory bodies at several regions and countries It is worthwhileto note that a device that locks on one SF can successfullyreceive a signal even though signals of different SF exist atthe same time on the same subchannel Moreover gatewayscan simultaneously receive multiple transmissions if eithersubchannels or SFs are different Currently the SX1301 basedgateway supports concurrent demodulations up to 8 signals

LoRarsquos CSS modulation enables packet receptions evenwhen the signal power is much less than the absolute noisefloor The high reception sensitivity makes carrier sensingpractically impossible Lack of carrier sensing forces theoriginal LoRa to use the Aloha MAC that suffers fromexcessive collisions Even though some countries require LBT(Listen Before Talk) it is quite difficult to sense on-goingLoRa signals without synchronizing with preambles Thispaper assumes that all devices use the Aloha MAC

The LoRaWAN end-devices are classified into threeclasses Classes A B and C A Class A devicemdashbidirectionalend-devicesmdashcan initiate uplink transmissions only It canreceive downlink frames but only as a response to uplinkframes that it has initiated Figure 2 describes the timingof an initial uplink transmission and following downlinktransmissions The timing of downlink transmissions shouldbe carefully coordinated the server should schedule adownlink such that its transmission interval is coincident

Wireless Communications and Mobile Computing 5

Gateway

End-device

Time

Uplink RX1 RX2

RECEIVE_DELAY2

RECEIVE_DELAY1

Downlink

Figure 2 Class A end-device initiated uplink and responding downlinks

Gateway

End-device

Time

4

Beacon_Window

Beacon_Guard Beacon_Reserved

Beacon_Period

7 265 516

Beacon

Ping slots for node X

Ping slots for node Y

Figure 3 Beacon based Class B downlink scheme

with predetermined receive windows Class A end-nodessacrifice asynchronous downlink transmissions but attainlong lifetimes as a reward It is expected that battery poweredClass A end-devices enjoy ten to twenty years of lifetimes inreasonable use cases Class A is suitable for sensor nodes thatreport sensing data periodically or when the readings satisfypredetermined criteria

Unlike a Class A end-device Class B and C devices sup-port downlink communications A Class C end-device oper-ates in an always-on mode and wastes significant amountsof energy for idle listening required for the receptions ofasynchronous downlinks Class B end-devicesmdashbidirectionalend-devices with scheduled receive slotsmdashsupport syn-chronous server-initiated downlinks Class B end-devicesmust be time synchronized with the gateway which transmitsbeacons at every beacon period of 128 seconds Once beingsynchronized Class B end-devices wake up at each beaconperiod to maintain the synchronization LoRa discretizes thetime into so-called ping slots each of which is 30 mSec longOne beacon period contains 4096 ping slots and a devicecan request 2119896 (0 le 119896 le 7) ping slots per beacon periodThe first ping slot position is determined randomly and p-th ping slot starts at 119905119861119864119860119862119874119873 119877119864119878119864119877119881119864119863 + (1199030 + (119901 minus 1) ∙212minus119896) ∙ 30 where 119905119861119864119860119862119874119873 119877119864119878119864119877119881119864119863 is the time when theBEACON RESERVED finishes 1199030 is the first offset randomlyselected Figure 3 shows the beacon timing and an example

of Class B end-devicesrsquo ping slot schedules (nodes X and Y)whose parameters are 119896 = 3 and 1199030 = 4 and 119896 = 4 and 1199030 = 7respectively

The downlink protocol for Class B end-devices incurssignificant overheads In addition to beacons they mustblindly wake up at their reserved ping slots regularly eventhough there are no buffered frames for them Also devicesconsume energy to maintain a precise clock to catch theinterrupts during ping slots We design and implement a newdownlink scheme to reduce such overheads

4 Downlink Communications Scheme

There can be many alternative methods for downlink trans-missions One simple method is to utilize the Class A uplink-downlink transaction an end-device periodically transmitsprobe messages to the server and if there is a downlinkmessage for the device the server sends it as a responseto the uplink probe This method is effective and energyefficient if end-devices can guess the existence of downlinkmessages correctly However exact prediction of downlinksis practically impossible Because end-devices cannot predictwhen downlink packets are ready they can issue either toomany unnecessary probes when the probing interval is shortor suffer from long latencies when the probing interval islong

6 Wireless Communications and Mobile Computing

Preamble PHDR

MHDR MACPayload MIC

1

1

1 25 4

4

TimeStamp DevAddr

PHYPayloadPHDR_CRC

(a)

Preamble PHDR_CRCPHDR PHYPayload CRC

MHDR DevAddr MIC

1 44

(b)

Figure 4 Beacon and poll message formats (a) Beacon (b) Poll

Broadcasting is an effective mechanism to disseminatecontrol information in a network that supports one to manycommunications Indeed IEEE 80211 WLANs [26]mdashwherean AP and multiple stations form a one to many networkmdashadopt the periodic broadcast scheme to alert backloggedmobile stations in the Power Saving Mode (PSM) A WLANAPperiodically (usually every 100mSec) broadcasts a beaconmessage that contains Traffic Indication Map (TIM) A TIMenumerates mobile stations that have buffered downlinkpackets Stations in the sleep mode wake up periodically atevery beacon interval to listen TIMs Backlogged stationsthen send PS-Poll frames requesting downlink packet trans-missions As soon as a station receives a buffered frame itfalls back to the sleep mode until the next beacon Stationswithout buffered downlink frames immediately return to thesleep state to minimize energy consumption

Because a LoRaWAN forms a star (more precisely astar-of-stars topology) and supports broadcasting like IEEE80211 WLAN it is natural to adopt a downlink mechanismsimilar to the IEEE 80211 PSM In addition as explained inthe previous section on LoRaWAN primer the LoRaWANstandard already supports a beacon mechanism for timesynchronization We can easily modify the structure of aLoRaWANrsquos beacon frame to augment a field that specifiesbacklogged end-devices This additional field is similar tothe TIM field of the WLAN The message formats of beaconand poll frames are shown in Figure 4 Compared to beacontransmission polling mechanisms for LoRaWAN ask for acareful design because the MAC protocols in LoRaWAN arepractically limited to the unslotted Aloha scheme Given thatcarrier sensing is prohibited a beacon triggers synchronizedmedium access from backlogged end-devices and causesexcessive collisions On the other hand a LoRaWAN is robustagainst collisions because it supports multiple simultaneousreceptions of different SFs and different subbands In shortbecause polling can affect the performance of overall systems

significantly it is worthwhile to carefully analyse all aspectsthat may affect the performance

We consider two polling mechanisms concurrent pollingand sequential polling Before delving into the details ofpolling schemes let us first introduce the notations used forthe following analysis (Table 2)

Concurrent polling is designed to best exploit the char-acteristics of the LoRarsquos PHY layer Note that a gatewaycan receive multiple signals simultaneously if their channelsor SFs are different Commercially available gateways sup-port concurrent demodulation up to 8 signals however letus assume that the number of simultaneous receptions isincreased multiplicatively by deploying multiple gatewaysFor example if a LoRa network uses 10 channels and 6different SFs as in Europe then the maximum of 60 pollscan be delivered simultaneously when more than or equalto 8 gateways are deployed Let busy and idle devices beend-devices with and without pending downlink framesrespectively Hearing a beacon all busy end-devices transmitpolls to the server simultaneously as shown in Figure 5(a)Polls that are in the same subchannel and of the same SF willexperience collisions and will be lost For example polls fromdevices 1198641 1198642 119886119899119889 1198643 are transmitted successfully How-ever polls from devices 1198644 119886119899119889 1198645 will collide and will belost

Let n andmbe the number of themaximumsimultaneousframes that the network allows and the number of framesthat arrive during a beacon period (ie the number ofpolls assuming that there is at most one frame per end-device) The expected number of successful polls is m ∙119890minus119898119899 approximately Because collided polls will competeagain at the next beacon interval the actual number of pollscompeting at each beacon is approximated as1198981015840 = 119898+119898(1minus119890minus119898119899)

Idle devices fall back to the sleep state as soon as theyrecognize there are no frames for them The maximum

Wireless Communications and Mobile Computing 7

Table 2 Notations

Notation Meaning

119863119887 Size of a beacon except preamble the minimum size is 17+4∙ m bytes where m is the number of end-devices with buffereddownlinks

119863119901 Size of a poll frame except preamble The minimum size can be 4119863119889 Average size of a downlink frame except preamble119905119888 Time to compensate clock drift According to the LoRaWAN standard it is set to 13 mSec119905119892 Time gap between two consecutive frames during downlink operation Frames include poll and data119903119887 Beacon broadcasting data rateThe standard specifies using SF=12 and the data rate is 250 bps119903119901 Average poll frame transmission data rate119903119889 Average downlink frame transmission data rate

GatewayTime

Channel=3 SF=7

Channel=3 SF=10

Channel=2 SF=7

Channel=4 SF=10

Channel=4 SF=10

E1

E2

E3

E4

E5

(a)

GatewayTime

Channel=3 SF=7

Channel=3 SF=10

Channel=2 SF=7

Channel=4 SF=10

Channel=4 SF=10

E1

E2

E3

E4

E5

(b)

Figure 5 Example of polling mechanisms (a) Concurrent polling (b) Sequential polling

wake-up time of an idle device during a beacon period 119882119862119868 is computed as follows

119882119862119868 = 119905119888 + 119863119887119903119887 (1)

A busy end-device transmits a poll and waits until it receivesits downlink As soon as it receives the downlink it turnsits radio off until the next beacon Because the gatewaytransmits downlinks only to the end-devices whose polls aresuccessfully received on the average 1198981015840 ∙ 119890minus1198981015840119899 downlinkframes will be transmitted The average maximum wake-uptime of a busy device whose poll is delivered successfully tothe gateway is

119882119862119861119878 = 119905119888 + 119863119887119903119887 + 119863119901

119903119901 + 12 ∙ (119905119892 + 119863119889

119903119889 ) ∙ 1198981015840 ∙ 119890minus1198981015840119899 (2)

A busy device whose poll fails to reach to the gateway mustwait until all downlink transmissions are completed and itswake-up time is

119882119862119861119865 = 119905119888 + 119863119887119903119887 + 119863119901

119903119901 + (119905119892 + 119863119889119903119889 ) ∙ 1198981015840 ∙ 119890minus1198981015840119899 (3)

Under a simple assumption that all end-devices are equallyprobable to have a pending downlink frame the sumof wake-up times of all M devices under the synchronous pollingscheme is

(119872 minus 1198981015840) ∙ 119882119862119868 + 1198981015840 ∙ 119890minus1198981015840119899 ∙ 119882119862119861119878 + 1198981015840

∙ (1 minus 119890minus1198981015840119899) ∙ 119882119862119861119865(4)

The average time that a node should turn on its batteryto receive a downlink is derived by dividing (4) by themultiplication of M and the average number of successfuldownlinks per beacon period

Another scheme that we have considered is sequentialpolling Unlike the contention based concurrent polling end-devices poll and receive downlink in the same order that theiraddresses appeared in the DevAddr fields of a beacon frameFigure 5(b) shows an example of sequential polling Receivinga beacon busy devices remember their positions in theDevAddr field and all devices except the first busy device fallback to the sleep state The first busy device transmits a polland receives a downlink frameThe second busy device wakes

8 Wireless Communications and Mobile Computing

Concurrent n = 8Concurrent n = 16Sequential

8 162 1 4 Offered Load

0

50

100

150

200

250

300

350

400

450

500W

ake-

up ti

me (

mse

c)

(a)

Concurrent n = 8Concurrent n = 16Sequential

8 162 1 4 Offered Load

0

5

10

15

Wak

e-up

tim

e (m

sec)

(b)

Figure 6 Performance of concurrent polling and sequential polling (a) Average wake-up time of both idle and busy devices (b) Averagewake-up time of busy devices

up after one poll-data frame exchange time to poll and receiveits downlinkThe sameprocedure repeats for succeeding busydevices Equation (5) is the average maximum wake-up timeof a busy device

119882119878119861 = 119905119888 + 119863119887119903119887 + 119863119901

119903119901 + (119905119892 + 119863119889119903119889 ) (5)

Moreover the sum of all wake-up times during a beaconperiod is

(M minus m) ∙ 119882119878119868 + 119898 ∙ 119882119878119861 (6)

5 Comparison of Two Polling Schemes

We compared the two polling methods by varying the valuesof parameters that may affect performance The performancemetric is the average wake-up time required for the receptionof one downlink frame We varied the total number of end-devices (M) in a network the number of downlink messagesper beacon interval and the network capacity for concurrenttransmissions (n) Figure 6 shows the average wake-up timesof concurrent and sequential polling as functions of theoffered loadThe unit of the offered load is the number of newdownlink frames generated per beacon interval Figures 6(a)and 6(b) are the wake-up time of all end-devices includingboth idle and busy devices and the wake-up time of busydevices only respectively When calculating the wake up timeof busy devices only terms (119872minus1198981015840)∙119882119862119868 and (Mminusm)∙119882119878119868 in(4) and (6) are excluded We used two values (n=8 and n=16)of network capacity to analyse the effect of maximum simul-taneous receptions For simplicity we assume that receptionpaths of gateways are ideally utilized as each gateway does notlock on the same packet In both Figures 6(a) and 6(b) we

can observe that sequential polling is more effective in powerconserving than concurrent polling When the offered load issmall the performance differences are not great However asthe offered load increases the gap increases also and at m=16concurrent polling consumes 3 to 22 times more energy thansequential polling in the case of all devices (Figure 6(a))Moreover in the case of busy devices only (Figure 6(b))concurrent polling consumes 55 to 41 times more energythan sequential polling The number of total end-devices isfixed at 1000We performed the same analysis by varying thevalue of M and obtain the similar results

We also can observe that concurrent polling at n=16 isbetter than that at n=8 As n increases the probability of colli-sion decreases Collisions affect the performance in twowaysA device whose poll fails to reach a gateway wastes energybecause it should wait until all downlinks are completedAlso collisions increase the offered load at the followingbeacon period and an inflated load again increases the col-lision probability Generally the wake-up time of all devicesdecreases as the offered load increases up to 4 (Figure 6(a))However as the offered load exceeds network capacity (n)wake-up time increases sharply

Because our analytic study reveals the performance ad-vantage of sequential polling over concurrent polling weadopt sequential polling for our downlink communicationscheme Figure 7 illustrates TRILO in a greater detailBeacon Window is divided into downlink reception timeand uplink transmission time After a beacon busy devicesreceive downlink frames sequentially during downlink timeAfter that nodes transmit uplink messages like plain ClassA devices One problem is that uplink transmissions orthe downlinks responding to uplinks may overlap with thefollowing beacon To avoid the problem the Beacon Guardis introduced end-devices refrain from initiating new uplink

Wireless Communications and Mobile Computing 9

Gateway

End-device A

Time

Beacon period

Beacon

poll

End-device B

downlink

uplink

Downlink Uplink

Beacon window

Figure 7 Proposed downlink communication scheme

(a) (b)

Figure 8 Devices used for implementation (a) End-device with SX1272MB2DAS attached to a NUCLEO-L073RZ board (b) Gateway withRAK831 attached to a Raspberry Pi 3

transmissions if remaining time to the next beacon is lessthan Beacon Guard Note that LoRaWAN standard limitsmaximum payload size so that beacon payload cannotconvey a large number of DevAddrs however it can be easilyextended depending on network conditions by using low SFsor allocating short network addresses

6 Implementation

We implemented TRILO using commercially available com-ponents We built a gateway on a RAK831 board [27] whichcontains an SX1301 concentrator chip The gateway board isattached to a Raspberry Pi 3 board as shown in Figure 8(b)For our implementation we employed the Semtech librarieswhich contain LoRaWAN packet forwarder and hardwareabstraction layer for SX1301

In the LoRaWAN architecture a gateway plays a simplerole of a bridge between end-devices and a network serverand a network server performs all beacon and poll messageprocessings We utilize an open source project [28] targetedfor private LoRaWAN network production in implementinga network server Figure 9 describes the message handlermodules that we implemented The beacon handler creates

a beacon payload consisting of the timestamp and buffereddownlink frame information Then it passes the payload tothe packet processor which assembles the payload into abeacon packet Since a beacon needs to be transmitted ina greater time precision than data packets we modified thegateway such that beacons are transmitted immediately Thepoll handler sends a pending downlink frame in responseto a poll message Note that this mechanism is transparentto the LoRaWAN MAC processor and the application serverbecause we implement modules at the packet processor level

An end-device is implemented on a NUCLEO-L073RZboard with an embedded LoRaWAN chip using a 915Mhzantenna (see Figure 8(a)) We attached the SX1272MB2DAScomponent to a NUCLEO-L073RZ board with the modifiedLoRa MAC Note that end-device logics are compiled andstored as firmware in an end-device Time synchronizationbetween nodes and a network server is based on the localtime of a network server instead of GPS time because weimplemented the beacon handler at the server not using thebeacon frame of the Class B standard We modified the end-devicersquos software by adding the beacon handling and pollingfunctions Note that each device which has a pending framewaits for its turn and processing times of each downlink vary

10 Wireless Communications and Mobile Computing

Packet forwarderGateway Packet

processorLoRaWAN

MAC processor

Applicationserver

PUSH DATA

PULL RESP

Pollhandler

Beaconhandler

Figure 9 Block diagram of a network server that handles beacon and poll messages

Figure 10 Experiment environment One gateway (yellow dot) and 15 end-devices (blue dots) are deployed in our office building

due to different SFs In a downlink period we configuredthe time for each poll and downlink based on SF 12 whichhas the longest airtime However the experimental resultsshow that the proposed scheme can be deployed with highperformance even with the conservative configuration It ispossible to optimize the waiting times for each downlinkmore compactly based on the information about SFs of eachnode however we leave this issue as future work

We tuned radios of the components to obey the Koreanregulation which allocates frequency bands from 920Mhzto 923Mhz for LoRaWAN We also added the listen beforetalk (LBT) function as the regulation specifies Note thatthe current LoRaWAN specifications for the KR920-923 ISMband do not have duty cycle limits but require adopting theLBT channel access rule [4]

7 Experimental Results

We evaluate the performance of TRILO by deploying modi-fied components in our office buildingWeplaced the gatewayand three end-devices in our lab Also we deploy 12 moreend-devices on the same floor of the building as shown inFigure 10 The beacon periods are set to either 128 sec or256 sec We varied the uplink and downlink offered loadsfrom 1 2 4 to 8 frames per beacon period The offered trafficis unrealistically large for such a small network however notethat we are trying to emulate the operating conditions of large

scale LoRAWAN networks consisting of tens of thousandsof end-devices Testbeds of such scale are not available soour experiment emulates large networks with 15 end-devicesUplink and downlink messages should be interpreted as anaggregated traffic generated by thousands of end-devicesMessage interarrival times of uplink and downlink trafficfollow the exponential distribution and the destinations ofdownlink messages are randomly and uniformly selectedWe used primitive Adaptive Data Rate (ADR) for SF andpower allocation and all nodes converged to SF 8 and defaultEIRP output power (14dBm) The performance of real-worldLoRaWAN networks depends on the distributions of SFand transmission power However we ignore these factorsbecause improvement of uplink transmissions is not a goalof this work

The performance metrics used in this study includePacket Delivery Ratio (PDR) duty cycle and latency Toobtain reliable results we repeat experiments with the sameparameter values ten times The length of each experimentrun is 10 beacon periods (ie 1280 or 2560 sec) Becausethe destinations of downlinks and the origins of uplinks arerandomly selected it is expected that all end-devices andmessages experience the average performance

First of all we measure the PDR of uplink and downlinkframes We observe that all downlink frames are deliveredsuccessfully without exception The result is rather surprisingbecause TRILO employs beacon broadcasting and polling

Wireless Communications and Mobile Computing 11

Table 3 Packet delivery ratio of uplink traffic at various uplink anddownlink offered loads

Packet generation rate 120582119889 = 1 120582119889 = 2 120582119889 = 4120582119906 = 2 9864 9827 9772120582119906 = 8 9674 9603 9510

in addition to downlink data frames A failure in any onecomponent may lead to unsuccessful data transmissionsUnlike downlink frames uplink traffic experiences occa-sional transmission failures Wemeasure the PDR by varyingthe offered loads of both uplink and downlink traffic Notethat all nodes use the same SF and collisions occur if framesare transmitted on the same channel simultaneously Table 3illustrates the PDR of uplink traffic at different offered loadsBoth uplink and downlink traffic affect the PDR of uplinktraffic The PDR decreases as the offered load of downlinktraffic increases at 120582119906 = 2 the PDR decreases from 9864to 9772 as the offered load of downlink traffic increasesfrom 1 to 4 In addition the uplink traffic intensity also affectsthe PDR of uplink traffic for example at 120582119889 = 2 the PDRdecreases from 9827 to 9603 as the offered load of uplinktraffic increases from 2 to 8

Note that uplink transmissions are prohibited duringpolling and following downlink frame transmissions Uplinkframes which arrive during downlink operation should waituntil the current downlink operation is completed Thiswaiting procedure synchronizes backlogged end-devices andmay cause collisions Even though the LoRa PHY supportsmultiple simultaneous transmissions of different SFs or chan-nels multiple attempts increase the collision probabilitiesand the PDR decreases as both uplink and downlink trafficincrease To reduce the bloated collisions due to synchronoustransmissions persistent mechanisms such as 0-persistenceor p-persistence are required However persistence schemesincrease the complexity of the network protocol and maycause other side effects such as increased energy consump-tion

Next we assess the additional power consumed fordownlink communications Because gateways operate in analways-on mode we only measure the energy consumed byend-devices We use the duty cycle additional time requiredfor downlink communications as the performance metricThe duty cycle is the sum of wake-up times used for beaconreception for possible poll transmission and for downlinkdata frame receptions Figure 11 shows the average duty cycleat different downlink traffic loadsThe duty cycle increases asthe downlink offered load increases it increases from 075to 11 as 120582119889 increases from 1 to 4 Note that all end-devicesconsume the minimal fixed duty cycle for beacon receptionregardless of the intensity of downlink traffic In addition tothe fixed duty cycle end-devices with backlogged downlinkscontinue to stay in the wake-up state for polling and datareception

Figure 12 illustrates the average latency of downlink trafficand uplink traffic as functions of offered load respectively Asshown in Figure 12(a) the average latency of downlink trafficincreases in proportion to the offered load As explained

0

02

04

06

08

1

12

Dut

y Cy

cle (

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

Figure 11 Duty cycles required for downlink operation includingbeacon poll and downlink data transmissions

before downlink frames are generated according to a Poissonprocess Therefore the probability that a downlink frameoccurs in a small time period follows uniform distributionand on average each downlink frame waits one-half of thebeacon interval In addition frames that arrive during adownlink processing are postponed to the next beacon InFigure 12(a) we can observe that the effect of uplink traffic onthe average latency of downlink is minimal This result is notsurprising because uplink and downlink communications arewell isolated in the proposed scheme

Like the average downlink latency the average uplinklatency increases as the downlink offered load increasesUplink frames that arrive during downlink periods shouldwait until the end of the current downlink periodThe averagelatency of uplink traffic as well as the duty cycle increase asthe downlink offered load increases Contrary to Figure 12(a)where the average downlink latency is seldom affected bythe uplink offered load the average uplink latency increasesproportionally as the uplink offered load increases As theuplink communication demands increase a queue startsto form and this causes the increase in waiting time Thequeueing time is most distinctive at 120582119889 = 4 when the servicetime for uplink communications is minimal

8 Simulation Results

We also compared the performance of the Class B downlinkscheme and that of TRILO Because commercial LoRaWANdevices do not support Class B functions yet we relied oncomputer simulations for the performance comparison Thesimulation code is written primarily in CC++ and we con-duct extensive simulations in a typical LoRaWAN networkand in a heavy downlink traffic condition respectively Tocompare energy consumed for downlink communicationswe define the efficiency of each protocol as a performancemetric The efficiency defined as the ratio of data transmis-sion time to the duty cycle is the fraction of time used foruseful work

12 Wireless Communications and Mobile Computing

Ｏ = 2

Ｏ = 8

70

75

80

85

90

95

100

105D

ownl

ink

Late

ncy

(sec

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

(a)

1

2

3

4

5

6

7

8

Upl

ink

Late

ncy

(sec

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

Ｏ = 2

Ｏ = 8

(b)

Figure 12 Average latency of traffic (a) Downlink latency (b) Uplink latency

Table 4 Notations used for Class B downlink protocol and TRILO

Notation Meaning119863119879 Duty cycle of TRILO119863119861 Duty cycle of the Class B downlink protocol119879119879119861119890119886119888119900119899 Beacon transmission time of TRILO

119879119861119861119890119886119888119900119899 Beacon transmission time of the Class B downlinkprotocol

119879119901119900119897119897 Average poll frame transmission time119879119889119900119908119899 Average downlink frame transmission time119896 Parameter for the Class Brsquos ping slots

119868119864 Indicator function representing a node is backlogged ornot

According to the LoRaWAN standard implementation ofthe Class B downlink scheme discretizes the time into so-called ping slots Each end-device requests 2119896 (0 le 119896 le 7)ping slots per beacon period We use the average case of theClass B where each end-device randomly selects a value ofthe parameter 119896 between 0 and 7 Let us first introduce thenotations for the analysis of LoRaWAN downlink protocol(Table 4)

We used SF 9 for beacon transmissions according to theLoRaWAN specification KR920-923 [29] The duty cycle ofTRILO119863119879 is

119863119879 =119879119879119861119890119886119888119900119899 + 119868119864 sdot (119879119901119900119897119897 + 119879119889119900119908119899)

119861119890119886119888119900119899 119875119890119903119894119900119889 (7)

Note that unlike 119879119861119861119890119886119888119900119899 119879119879119861119890119886119888119900119899 increases in proportion tothe number of busy end-devices The duty cycle of a Class Bdevice 119863119861 is

119863119861 = 119879119861119861119890119886119888119900119899 + 2119896 sdot 119879119889119900119908119899119861119890119886119888119900119899 119875119890119903119894119900119889 (8)

Class B devices have different duty cycles depending onrandomly selected values of parameter 119896 Then the efficiencyis computed as

119864119891119891119894119888119894119890119899119888119910 = 119863119900119908119899119897119894119899119896 119905119903119886119899119904119898119894119904119904119894119900119899 119905119894119898119890119863119906119905119910 119888119910119888119897119890119904 (9)

We measured the efficiency of TRILO and the Class Bdownlink protocol by varying the number of nodes from 50to 4000 and the downlink offered load from 2 to 32 framesper beacon period Each performance point is the average of10000 runs We limit the maximum downlink traffic to 32frames per beacon interval because uplink traffic is greaterthan downlink traffic in many LoRaWAN applications Notethat at 120582119889 = 32 about a half of beacon period is consumed fordownlink communications if we assume that the downlinktransmission time is 2 seconds on average

The efficiency of each scheme is shown in Figure 13Note that the offered load is aggregated load and the trafficintensity of individual node decreases as the number of nodesincreases The total times for downlink communications arefixed at each given offered load However the sum of dutycycles increases as the number of nodes increases Thereforein both protocols the maximum efficiencies are realized atsmall networks and the efficiency decreases as the networksize increases The results illustrate that efficiencies of TRILOare higher than those of the Class B downlink protocolthroughout all downlink generation ratesTheClass B schemeperforms well in heavy traffic cases However the proposedscheme outperforms the Class B scheme even in heavy trafficconditions In small networks the performance gap decreasesfrom about 139 times to about 33 times as 120582119889 increases from2 to 32 Also each gap in each offered load increases as thenetwork size increases In the case of TRILO the averageduty cycle decreases inversely proportional to the number ofnodes because only busy devices are active during downlink

Wireless Communications and Mobile Computing 13

Number of Nodes500 1000 1500 2000 2500 3000 3500 4000

10minus3

10minus2

Effici

ency

10minus1

100

101

Class B (＞ = 2)

Proposed (＞ = 2)

Class B (＞ = 8)

Proposed (＞ = 8)

Class B (＞ = 32)

Proposed (＞ = 32)

Figure 13 Efficiency of TRILO and Class B downlink protocol

periods On the contrary Class B protocol allocates 31 pingslots on average regardless of downlink demands In shortthe number of receive windows wasted by the Class B schemevaries depending on the amount of downlink traffic howeveronly busy devices use extra duty cycle for downlink traffic inTRILO

The Class B protocol does not coordinate traffic betweenuplinks and downlinks so that several uplinks can be dis-rupted by downlink transmissions due to the half-duplexcharacteristic of a LoRaWAN gateway all reception pathscan be blocked by downlink transmissions It can obstructthe proper operations of typical LoRaWANs where uplinktransmissions are predominant In contrast the proposedscheme is free from this problem because it isolates the timefor uplinks and downlinks periods

9 Conclusions

A plethora of LPWAN techniques such as LoRa SigFoxRPMA and Weightless have emerged as a new enablingnetwork technology for IoT applications that require low-rate low-cost and long lifetimes LPWANs allow end-deviceinitiated uplinks However to maximize the lifetime ofbattery powered end-devices nodes are put into the sleepstate such that rather restricted downlink communicationsare permitted In this paper we proposed a new downlinkprotocol named TRILO for LoRaWAN

Because LoRaWAN assumes a star topology where mul-tiple end-devices are connected to a single gateway weadopted a beacon based downlink mechanism similar to theIEEE 80211 PSM standard A gateway broadcast beaconsperiodically at every beacon period and end-devices are timesynchronized Beacons alert nodes with buffered downlinksin addition to synchronizing end-devicesrsquo clocks Customizedto the physical characteristics of LoRa we designed two

polling schemes concurrent polling and sequential pollingAn analysis indicates that sequential polling is more energyefficient than concurrent polling

We implement the proposed beacon based downlinkprotocol using commercially available components and con-duct experiments with modified devices Our performancestudy shows that Packet Delivery Ratio (PDR) is almost100 for both uplink and downlink traffic and the extrawake-up time to receive beacons and downlinks is minimalSimulation results also show that our proposed protocol canadaptively allocate receive windows resulting in lower energyconsumption

For further work we plan to investigate the impact ofour scheme on the networks with multiple gateways Alsodetailed investigations of impact of the number of downlinksand the certain distributions of SFs on the performanceseem interesting Optimization techniques leveraging SF andpower allocation are expected to affect the performance of theproposed scheme

Data Availability

The data used to support the findings of this study areincluded within the article

Disclosure

The funding sponsors had no role in the study in thecollection analyses or interpretation of data in the writingof the manuscript and in the decision to publish the results

Conflicts of Interest

The authors declare that there are no conflicts of interestregarding the publication of this paper

14 Wireless Communications and Mobile Computing

Acknowledgments

This work was supported by the National Research Founda-tion of Korea (NRF) Grant funded by the Korean Govern-ment (MSIP) (No 2016R1A5A1012966) Institute for Infor-mation amp Communications Technology Promotion (IITP)grant funded by the Korea government (MSIT) (No 2015-0-00557 ResilientFault-Tolerant Autonomic NetworkingBased on Physicality Relationship and Service Semantic ofIoT Devices) and the MSIP (Ministry of Science ICT andFuture Planning) Korea under the ITRC (Information Tech-nology Research Center) support program (IITP-2018-2015-0-00378) supervised by the IITP (Institute for Informationamp Communications Technology Promotion) Also the snu-samsung smart campus research center at Seoul NationalUniversity provides research facilities for this study

References

[1] M Bor U Roedig T Voigt and J M Alonso ldquoDo LoRalow-power wide-area networks scalerdquo in Proceedings of the19th ACM International Conference on Modeling Analysis andSimulation of Wireless and Mobile Systems MSWiM 2016 pp59ndash67 Malta November 2016

[2] DMagrinMCentenaro andLVangelista ldquoPerformance eval-uation of LoRa networks in a smart city scenariordquo inProceedingsof the 2017 IEEE International Conference on CommunicationsICC 2017 France May 2017

[3] LoRa httpswwwlora-allianceorgWhat-Is-LoRaTechnol-ogy

[4] ldquoLoRaWAN 11 specificationrdquo LoRa Alliance 2017 httpslora-allianceorgresource-hublorawantm-specification-v11

[5] M Bor J Vidler and U Roedig ldquoLoRa for the internet ofthingsrdquo in Proceedings of the International Conference onEmbedded Wireless Systems and Networks (EWSN rsquo16) pp 361ndash366 Junction Publishing 2016

[6] 3GPP ldquoStudy on provision of low-cost Machine-Type Commu-nications User Equipments based on LTErdquo TR 36888 V120006 2013

[7] 3GPP ldquoCellular system support for ultra-low complexity andlow throughput Internet of Thingsrdquo TR 45820 V1310 11 2015

[8] J Gozalvez ldquoNew 3GPP Standard for IoTrdquo IEEE VehicularTechnology Magazine vol 11 no 1 pp 14ndash20 2016

[9] R Ratasuk N Mangalvedhe and A Ghosh ldquoOverview ofLTE enhancements for cellular IoTrdquo in Proceedings of the 26thIEEE Annual International Symposium on Personal Indoor andMobile Radio Communications PIMRC 2015 pp 2293ndash2297China September 2015

[10] H Shariatmadari R Ratasuk S Iraji et al ldquoMachine-type com-munications current status and future perspectives toward 5Gsystemsrdquo IEEE CommunicationsMagazine vol 53 no 9 pp 10ndash17 2015

[11] S Landstrom J Bergstrom E Westerberg and D Hammar-wall ldquoNBIoT a sustainable technology for connecting billionsof devicesrdquo Ericsson Technology Review vol 4 pp 2ndash11 2016

[12] M Lauridsen I Z Kovacs P Mogensen M Sorensen andS Holst ldquoCoverage and capacity analysis of LTE-M and NB-IoT in a rural areardquo in Proceedings of the 2016 IEEE 84thVehicular Technology Conference (VTC-Fall) pp 1ndash5 MontrealQC Canada September 2016

[13] Sigfox httpwwwsigfoxcom[14] Weightless open standard httpwwwweightlessorg[15] Ingenu RPMA httpwwwingenucomtechnologyrpma[16] A Dunkels ldquoThe ContikiMAC radio duty cycling protocolrdquo

Technical Report T201113 Swedish Institute of ComputerScience 2011

[17] J Ko J Eriksson N Tsiftes et al ldquoIndustry Beyond interoper-ability - Pushing the performance of sensor network IP stacksrdquoin Proceedings of the 9th ACM Conference on Embedded Net-worked Sensor Systems SenSys 2011 pp 1ndash11 USA November2011

[18] D Moss J Hui and K Klues ldquoTEP 105 low power listeningrdquohttpwwwtinyosnettinyos-2xdocpdftep105pdf 2008

[19] C Gomez J Oller and J Paradells ldquoOverview and evaluationof bluetooth low energy an emerging low-power wirelesstechnologyrdquo Sensors vol 12 no 9 pp 11734ndash11753 2012

[20] A A Kandhalu A E Xhafa and S Hosur ldquoTowards bounded-latency bluetooth low energy for in-vehicle network cablereplacementrdquo in Proceeding of the International Conference onConnected Vehicles and Expo (ICCVE) pp 635ndash640 Las VegasNV USA 2013

[21] A Montanari S Nawaz C Mascolo and K Sailer ldquoA studyof bluetooth low energy performance for human proximitydetection in the workplacerdquo in Proceedings of the 2017 IEEEInternational Conference on Pervasive Computing and Commu-nications PerCom 2017 pp 90ndash99 Kona HI USA March 2017

[22] C Julien C Liu A L Murphy and G P Picco ldquoBLEnd Practi-cal continuous neighbor discovery for bluetooth low energyrdquo inProceedings of the 16th ACMIEEE International Conference onInformation Processing in Sensor Networks IPSN 2017 pp 105ndash116 New York NY USA April 2017

[23] Y Qiu S Li X Xu and Z Li ldquoTalk more listen less energy-efficient neighbor discovery in wireless sensor networksrdquo inProceedings of the 35th Annual IEEE International Conference onComputer Communications IEEE INFOCOM 2016 USA April2016

[24] A J Berni andW D Gregg ldquoOn the utility of chirpmodulationfor digital signalingrdquo IEEE Transactions on Communicationsvol 21 no 6 pp 748ndash751 1973

[25] A Springer W Gugler M Huemer L Reindl C C W Ruppeland R Weigel ldquoSpread spectrum communications using chirpsignalsrdquo in Proceedings of the IEEEAFCEA Information Systemsfor Enhanced Public Safety and Security EUROCOMM2000 pp166ndash170 Germany

[26] IEEE Std 80211-2007 ldquoIEEE Standard for Information Tech-nologymdashTelecommunications and Information Exchange be-tween SystemsmdashLocal and Metropolitan Area NetworksmdashSpecific Requirements Part 11 Wireless LAN Medium AccessControl (MAC) and Physical Layer (PHY) Specifications June2007rdquo

[27] RAK831 httpwwwrakwirelesscomenWisKeyOSHRAK831[28] LoRaWAN network server httpsgithubcomgotthardplor-

awan-server[29] ldquoLoRaWAN 11 Regional Parametersrdquo LoRa Alliance 2017

httpslora-allianceorgresource-hublorawantm-regional-pa-rameters-v11ra

Wireless Communications and Mobile Computing 3

physical and network properties of LoRa and LoRaWAN Inparticular we aim to devise a protocol that is more energyefficient than synchronous downlink mechanism developedfor LoRaWANrsquos Class B

(ii) We devise two polling mechanisms called con-current polling and sequential polling Concurrent pollingbest exploits the LoRarsquos capability that supports simultane-ous receptions of multiple packets However the analysisindicates that sequential polling is more energy efficientthan concurrent polling and we adopt sequential poll-ing

(iii) TRILO is implemented on commercially availableLoRaWAN components Modified LoRaWAN componentsoperate properly in real-world experiments

(iv) We conduct experiments with modified LoRaWANdevices Our performance study shows that PDR is almost100 for both uplink and downlink traffic and the extrawake-up times to maintain and support beacons and downlinkpackets are minimal

(v)We conduct computer simulations to compare the per-formances of TRILO and the LoRaWANrsquos Class B downlinkprotocol Our performance study shows that the proposedscheme which minimizes unnecessary receive window allo-cations is significantly more energy efficient than the legacyLoRaWAN

The rest of the paper is organized as follows We beginwith the related work highlighting several low-power MACmechanisms We then give a brief primer on LoRa andLoRaWAN focusing on the features of LoRa and LoRaWANthat are closely related to the design of downlink protocolsNext we describe the proposed beacon based downlink pro-tocol Two polling methods concurrent polling and sequen-tial polling are explained We compare the wake-up timesof the two polling methods and show that sequential pollingis more energy efficient than concurrent polling Then theimplementation details of TRILO and performance resultsobtained from real-world experiments are described Wealso illustrate the performance comparison of TRILO andthe LoRaWANrsquos downlink protocol Lastly conclusion sum-marizes the paper and discusses several future researchproblems

2 Related Work

Energy is one of the precious resources that should bemanaged carefully in battery powered mobile devices Manyresearchers have studied energy conservation schemes invarious scenarios This section reviews several exemplarypower saving schemes

Basically almost all energy conservation schemes try tominimize the duty cycleThe literature can be partitioned intotwo categories depending on the type of communicationsone to one communications and one to many communica-tions Usually one to one communication is between twodevices of the equal capabilities On the other hand in mostone to many networks a central node enjoys unlimitedpower supply from a powerline while many others arebattery poweredmobile devices For example aWiFi networkconsists of one AP (Access Point) and many mobile stations

Asmost prior works we focus on the energy conservation forbattery powered devices

Many clever low-power MAC mechanisms have beendesigned forWSNs (Wireless Sensor Networks) which imple-ment multihop wireless networks over WiFi networks or theIEEE 802154 standard protocols Even though base networktechnologies support one to many communications neigh-bour nodes in mesh networks assume peer to peer commu-nications The energy conservation mechanisms for WSNscan be classified by several criteria such as synchronicity andsender- or receiver-initiated The two most widely deployedprotocols ContikiMAC [16 17] and TinyOS LPL [17 18]are asynchronous sender-initiated protocols and are imple-mented on two de facto standard operating systems Contiki[16] and TinyOS [18] respectively In sender-initiated proto-cols a sender transmits a packet repeatedly for a time longerthan a predetermined duty cycle interval A receiver oper-ates in the duty cycling mode it wakes up at every dutycycle interval and listens for a possible transmission from thesender

Bluetooth Low Energy (BLE) [19] is another networktechnology that requires one to one energy conserving MACBLE aims for the lifetime from several months to years with acoin cell battery [19] The BLE neighbour (device) discoverymechanism is an asymmetric scheme where each deviceplays the role of either an advertiser or a scanner To bindwith another BLE device an advertiser transmits advertisingpackets periodically at every scheduled advertising eventA scanner also turns its radio on repeatedly at every scan-ning events Applying the Chinese Remainder TheoremKandhalu Xhafa and Hosur [20] devised a BLE neighbourdiscovery mechanism that guarantees eventual rendezvousof advertisers and scanners To avoid the ill-fated case thatboth advertiser and scanner choose the same prime numbereach device selects two prime numbers and wakes up at everyinteger multiples of the primes

Several researchers have proposed newneighbour discov-ery schemes that reduce discovery latency power consump-tion and reliability of the BLE device discovery mechanismUnlike the legacy BLE devices whose roles are fixed to eitheradvertiser or scanner at the production time [21] assumedthat devices could change their roles dynamically Theydevised a new neighbour discovery protocol customized forsuch environments Contrary to the prior methods that usetime slots BLEnd [22] demises the slot structure and reducesthe discovery delay Nihao [23] improves the latency andreduces energy consumption by increasing advertisementsand decreasing scanning times

One notable energy conservation protocol for one tomany communications is the IEEE 80211 PSM (Power SavingMode) An Access Point (AP) periodically broadcasts bea-cons to notify mobile stations that have pending downstreamframes Inspecting a beacon frame idle stations withoutbuffered downlinks turn their radio off immediately untilthe next beacon interval Backlogged stations request fordownstream packet transmissions by sending poll messagesto the AP Upon the delivery of downlink frames backloggedstations also fall back to the sleep state until the nextbeacon

4 Wireless Communications and Mobile Computing

EU868

EU433 hellipKR

920AS430

US915

LoRa Modulation

Applications

LoRa MAC

Class A Class B Class C

LoRa Specifications

LoRaWAN specifications

Figure 1 LoRa and LoRaWAN specifications

Table 1 Frequency bands and bandwidths allocated for LoRa

Location Europe North America Korea China JapanFrequencyband(MHz)

867-869 902-928 920-923 470-510779-787 920-925

Channels 10 64+8+8 13 - -Uplink CH BW(KHz) 125250 125500 125 - -Downlink CHBW(KHz)

125 125 125 - -

Tx power Up(dBm) +14 dBm +20sim+30 dBm +10sim+14 dBm - -

Tx power Down(dBm) +14 dBm +27 dBm +23 dBm - -

3 A Primer on LoRa and LoRaWAN

This section contains a brief overview of LoRa and LoRaWANtechnologies Specifically technical properties that influenceor limit the design space of LoRaWAN based downlinkprotocol will be addressed

Figure 1 shows the protocol stack of LoRa and LoRaWAN[4] LoRa developed and owned by Semtech [3] is a proprietytechnique that defines a physical layer customized for LPWAcommunications LoRaWAN which defines a MAC layer ontop of LoRa is an open standard developed by a nonprofitorganization called LoRa alliance LoRa operates on the900MHz ISM spectrum and adopts the CSS (Chirp SpreadSpectrum) modulation technique CSS [24 25] based onchirped-FM modulation yields high processing gains andenables long transmissions at the expense of data rates LoRasupports Adaptive Data Rate (ADR) which varies data ratesadapting to transmission distances and channel conditionsWhen the SNRs are low LoRa lowers the data rate to severalhundred bits per second by using large SF (Spreading Factor)and robust CR (Coding Rate)When SF and bandwidth (BW)are selected the data rate 119877119878119865 is determined as 1198781198652119878119865 ∙119861119882 The lowest data rate of LoRa determined at SF=12 andBW=125 KHz is approximately 300 bits per second Thehighest data rate is approximately 11 Kbps and is obtained atSF=7 and BW=250 KHz High data rates can be achievablewhen channel conditions are good SF=7 requires -120 dBmwhile SF=12 requires only -136 dBm

Each country allocates different frequency bands andbandwidth for LoRa Table 1 illustrates the frequency bandsbandwidth and transmission powers defined by the regula-tory bodies at several regions and countries It is worthwhileto note that a device that locks on one SF can successfullyreceive a signal even though signals of different SF exist atthe same time on the same subchannel Moreover gatewayscan simultaneously receive multiple transmissions if eithersubchannels or SFs are different Currently the SX1301 basedgateway supports concurrent demodulations up to 8 signals

LoRarsquos CSS modulation enables packet receptions evenwhen the signal power is much less than the absolute noisefloor The high reception sensitivity makes carrier sensingpractically impossible Lack of carrier sensing forces theoriginal LoRa to use the Aloha MAC that suffers fromexcessive collisions Even though some countries require LBT(Listen Before Talk) it is quite difficult to sense on-goingLoRa signals without synchronizing with preambles Thispaper assumes that all devices use the Aloha MAC

The LoRaWAN end-devices are classified into threeclasses Classes A B and C A Class A devicemdashbidirectionalend-devicesmdashcan initiate uplink transmissions only It canreceive downlink frames but only as a response to uplinkframes that it has initiated Figure 2 describes the timingof an initial uplink transmission and following downlinktransmissions The timing of downlink transmissions shouldbe carefully coordinated the server should schedule adownlink such that its transmission interval is coincident

Wireless Communications and Mobile Computing 5

Gateway

End-device

Time

Uplink RX1 RX2

RECEIVE_DELAY2

RECEIVE_DELAY1

Downlink

Figure 2 Class A end-device initiated uplink and responding downlinks

Gateway

End-device

Time

4

Beacon_Window

Beacon_Guard Beacon_Reserved

Beacon_Period

7 265 516

Beacon

Ping slots for node X

Ping slots for node Y

Figure 3 Beacon based Class B downlink scheme

with predetermined receive windows Class A end-nodessacrifice asynchronous downlink transmissions but attainlong lifetimes as a reward It is expected that battery poweredClass A end-devices enjoy ten to twenty years of lifetimes inreasonable use cases Class A is suitable for sensor nodes thatreport sensing data periodically or when the readings satisfypredetermined criteria

Unlike a Class A end-device Class B and C devices sup-port downlink communications A Class C end-device oper-ates in an always-on mode and wastes significant amountsof energy for idle listening required for the receptions ofasynchronous downlinks Class B end-devicesmdashbidirectionalend-devices with scheduled receive slotsmdashsupport syn-chronous server-initiated downlinks Class B end-devicesmust be time synchronized with the gateway which transmitsbeacons at every beacon period of 128 seconds Once beingsynchronized Class B end-devices wake up at each beaconperiod to maintain the synchronization LoRa discretizes thetime into so-called ping slots each of which is 30 mSec longOne beacon period contains 4096 ping slots and a devicecan request 2119896 (0 le 119896 le 7) ping slots per beacon periodThe first ping slot position is determined randomly and p-th ping slot starts at 119905119861119864119860119862119874119873 119877119864119878119864119877119881119864119863 + (1199030 + (119901 minus 1) ∙212minus119896) ∙ 30 where 119905119861119864119860119862119874119873 119877119864119878119864119877119881119864119863 is the time when theBEACON RESERVED finishes 1199030 is the first offset randomlyselected Figure 3 shows the beacon timing and an example

of Class B end-devicesrsquo ping slot schedules (nodes X and Y)whose parameters are 119896 = 3 and 1199030 = 4 and 119896 = 4 and 1199030 = 7respectively

The downlink protocol for Class B end-devices incurssignificant overheads In addition to beacons they mustblindly wake up at their reserved ping slots regularly eventhough there are no buffered frames for them Also devicesconsume energy to maintain a precise clock to catch theinterrupts during ping slots We design and implement a newdownlink scheme to reduce such overheads

4 Downlink Communications Scheme

There can be many alternative methods for downlink trans-missions One simple method is to utilize the Class A uplink-downlink transaction an end-device periodically transmitsprobe messages to the server and if there is a downlinkmessage for the device the server sends it as a responseto the uplink probe This method is effective and energyefficient if end-devices can guess the existence of downlinkmessages correctly However exact prediction of downlinksis practically impossible Because end-devices cannot predictwhen downlink packets are ready they can issue either toomany unnecessary probes when the probing interval is shortor suffer from long latencies when the probing interval islong

6 Wireless Communications and Mobile Computing

Preamble PHDR

MHDR MACPayload MIC

1

1

1 25 4

4

TimeStamp DevAddr

PHYPayloadPHDR_CRC

(a)

Preamble PHDR_CRCPHDR PHYPayload CRC

MHDR DevAddr MIC

1 44

(b)

Figure 4 Beacon and poll message formats (a) Beacon (b) Poll

Broadcasting is an effective mechanism to disseminatecontrol information in a network that supports one to manycommunications Indeed IEEE 80211 WLANs [26]mdashwherean AP and multiple stations form a one to many networkmdashadopt the periodic broadcast scheme to alert backloggedmobile stations in the Power Saving Mode (PSM) A WLANAPperiodically (usually every 100mSec) broadcasts a beaconmessage that contains Traffic Indication Map (TIM) A TIMenumerates mobile stations that have buffered downlinkpackets Stations in the sleep mode wake up periodically atevery beacon interval to listen TIMs Backlogged stationsthen send PS-Poll frames requesting downlink packet trans-missions As soon as a station receives a buffered frame itfalls back to the sleep mode until the next beacon Stationswithout buffered downlink frames immediately return to thesleep state to minimize energy consumption

Because a LoRaWAN forms a star (more precisely astar-of-stars topology) and supports broadcasting like IEEE80211 WLAN it is natural to adopt a downlink mechanismsimilar to the IEEE 80211 PSM In addition as explained inthe previous section on LoRaWAN primer the LoRaWANstandard already supports a beacon mechanism for timesynchronization We can easily modify the structure of aLoRaWANrsquos beacon frame to augment a field that specifiesbacklogged end-devices This additional field is similar tothe TIM field of the WLAN The message formats of beaconand poll frames are shown in Figure 4 Compared to beacontransmission polling mechanisms for LoRaWAN ask for acareful design because the MAC protocols in LoRaWAN arepractically limited to the unslotted Aloha scheme Given thatcarrier sensing is prohibited a beacon triggers synchronizedmedium access from backlogged end-devices and causesexcessive collisions On the other hand a LoRaWAN is robustagainst collisions because it supports multiple simultaneousreceptions of different SFs and different subbands In shortbecause polling can affect the performance of overall systems

significantly it is worthwhile to carefully analyse all aspectsthat may affect the performance

We consider two polling mechanisms concurrent pollingand sequential polling Before delving into the details ofpolling schemes let us first introduce the notations used forthe following analysis (Table 2)

Concurrent polling is designed to best exploit the char-acteristics of the LoRarsquos PHY layer Note that a gatewaycan receive multiple signals simultaneously if their channelsor SFs are different Commercially available gateways sup-port concurrent demodulation up to 8 signals however letus assume that the number of simultaneous receptions isincreased multiplicatively by deploying multiple gatewaysFor example if a LoRa network uses 10 channels and 6different SFs as in Europe then the maximum of 60 pollscan be delivered simultaneously when more than or equalto 8 gateways are deployed Let busy and idle devices beend-devices with and without pending downlink framesrespectively Hearing a beacon all busy end-devices transmitpolls to the server simultaneously as shown in Figure 5(a)Polls that are in the same subchannel and of the same SF willexperience collisions and will be lost For example polls fromdevices 1198641 1198642 119886119899119889 1198643 are transmitted successfully How-ever polls from devices 1198644 119886119899119889 1198645 will collide and will belost

Let n andmbe the number of themaximumsimultaneousframes that the network allows and the number of framesthat arrive during a beacon period (ie the number ofpolls assuming that there is at most one frame per end-device) The expected number of successful polls is m ∙119890minus119898119899 approximately Because collided polls will competeagain at the next beacon interval the actual number of pollscompeting at each beacon is approximated as1198981015840 = 119898+119898(1minus119890minus119898119899)

Idle devices fall back to the sleep state as soon as theyrecognize there are no frames for them The maximum

Wireless Communications and Mobile Computing 7

Table 2 Notations

Notation Meaning

119863119887 Size of a beacon except preamble the minimum size is 17+4∙ m bytes where m is the number of end-devices with buffereddownlinks

119863119901 Size of a poll frame except preamble The minimum size can be 4119863119889 Average size of a downlink frame except preamble119905119888 Time to compensate clock drift According to the LoRaWAN standard it is set to 13 mSec119905119892 Time gap between two consecutive frames during downlink operation Frames include poll and data119903119887 Beacon broadcasting data rateThe standard specifies using SF=12 and the data rate is 250 bps119903119901 Average poll frame transmission data rate119903119889 Average downlink frame transmission data rate

GatewayTime

Channel=3 SF=7

Channel=3 SF=10

Channel=2 SF=7

Channel=4 SF=10

Channel=4 SF=10

E1

E2

E3

E4

E5

(a)

GatewayTime

Channel=3 SF=7

Channel=3 SF=10

Channel=2 SF=7

Channel=4 SF=10

Channel=4 SF=10

E1

E2

E3

E4

E5

(b)

Figure 5 Example of polling mechanisms (a) Concurrent polling (b) Sequential polling

wake-up time of an idle device during a beacon period 119882119862119868 is computed as follows

119882119862119868 = 119905119888 + 119863119887119903119887 (1)

A busy end-device transmits a poll and waits until it receivesits downlink As soon as it receives the downlink it turnsits radio off until the next beacon Because the gatewaytransmits downlinks only to the end-devices whose polls aresuccessfully received on the average 1198981015840 ∙ 119890minus1198981015840119899 downlinkframes will be transmitted The average maximum wake-uptime of a busy device whose poll is delivered successfully tothe gateway is

119882119862119861119878 = 119905119888 + 119863119887119903119887 + 119863119901

119903119901 + 12 ∙ (119905119892 + 119863119889

119903119889 ) ∙ 1198981015840 ∙ 119890minus1198981015840119899 (2)

A busy device whose poll fails to reach to the gateway mustwait until all downlink transmissions are completed and itswake-up time is

119882119862119861119865 = 119905119888 + 119863119887119903119887 + 119863119901

119903119901 + (119905119892 + 119863119889119903119889 ) ∙ 1198981015840 ∙ 119890minus1198981015840119899 (3)

Under a simple assumption that all end-devices are equallyprobable to have a pending downlink frame the sumof wake-up times of all M devices under the synchronous pollingscheme is

(119872 minus 1198981015840) ∙ 119882119862119868 + 1198981015840 ∙ 119890minus1198981015840119899 ∙ 119882119862119861119878 + 1198981015840

∙ (1 minus 119890minus1198981015840119899) ∙ 119882119862119861119865(4)

The average time that a node should turn on its batteryto receive a downlink is derived by dividing (4) by themultiplication of M and the average number of successfuldownlinks per beacon period

Another scheme that we have considered is sequentialpolling Unlike the contention based concurrent polling end-devices poll and receive downlink in the same order that theiraddresses appeared in the DevAddr fields of a beacon frameFigure 5(b) shows an example of sequential polling Receivinga beacon busy devices remember their positions in theDevAddr field and all devices except the first busy device fallback to the sleep state The first busy device transmits a polland receives a downlink frameThe second busy device wakes

8 Wireless Communications and Mobile Computing

Concurrent n = 8Concurrent n = 16Sequential

8 162 1 4 Offered Load

0

50

100

150

200

250

300

350

400

450

500W

ake-

up ti

me (

mse

c)

(a)

Concurrent n = 8Concurrent n = 16Sequential

8 162 1 4 Offered Load

0

5

10

15

Wak

e-up

tim

e (m

sec)

(b)

Figure 6 Performance of concurrent polling and sequential polling (a) Average wake-up time of both idle and busy devices (b) Averagewake-up time of busy devices

up after one poll-data frame exchange time to poll and receiveits downlinkThe sameprocedure repeats for succeeding busydevices Equation (5) is the average maximum wake-up timeof a busy device

119882119878119861 = 119905119888 + 119863119887119903119887 + 119863119901

119903119901 + (119905119892 + 119863119889119903119889 ) (5)

Moreover the sum of all wake-up times during a beaconperiod is

(M minus m) ∙ 119882119878119868 + 119898 ∙ 119882119878119861 (6)

5 Comparison of Two Polling Schemes

We compared the two polling methods by varying the valuesof parameters that may affect performance The performancemetric is the average wake-up time required for the receptionof one downlink frame We varied the total number of end-devices (M) in a network the number of downlink messagesper beacon interval and the network capacity for concurrenttransmissions (n) Figure 6 shows the average wake-up timesof concurrent and sequential polling as functions of theoffered loadThe unit of the offered load is the number of newdownlink frames generated per beacon interval Figures 6(a)and 6(b) are the wake-up time of all end-devices includingboth idle and busy devices and the wake-up time of busydevices only respectively When calculating the wake up timeof busy devices only terms (119872minus1198981015840)∙119882119862119868 and (Mminusm)∙119882119878119868 in(4) and (6) are excluded We used two values (n=8 and n=16)of network capacity to analyse the effect of maximum simul-taneous receptions For simplicity we assume that receptionpaths of gateways are ideally utilized as each gateway does notlock on the same packet In both Figures 6(a) and 6(b) we

can observe that sequential polling is more effective in powerconserving than concurrent polling When the offered load issmall the performance differences are not great However asthe offered load increases the gap increases also and at m=16concurrent polling consumes 3 to 22 times more energy thansequential polling in the case of all devices (Figure 6(a))Moreover in the case of busy devices only (Figure 6(b))concurrent polling consumes 55 to 41 times more energythan sequential polling The number of total end-devices isfixed at 1000We performed the same analysis by varying thevalue of M and obtain the similar results

We also can observe that concurrent polling at n=16 isbetter than that at n=8 As n increases the probability of colli-sion decreases Collisions affect the performance in twowaysA device whose poll fails to reach a gateway wastes energybecause it should wait until all downlinks are completedAlso collisions increase the offered load at the followingbeacon period and an inflated load again increases the col-lision probability Generally the wake-up time of all devicesdecreases as the offered load increases up to 4 (Figure 6(a))However as the offered load exceeds network capacity (n)wake-up time increases sharply

Because our analytic study reveals the performance ad-vantage of sequential polling over concurrent polling weadopt sequential polling for our downlink communicationscheme Figure 7 illustrates TRILO in a greater detailBeacon Window is divided into downlink reception timeand uplink transmission time After a beacon busy devicesreceive downlink frames sequentially during downlink timeAfter that nodes transmit uplink messages like plain ClassA devices One problem is that uplink transmissions orthe downlinks responding to uplinks may overlap with thefollowing beacon To avoid the problem the Beacon Guardis introduced end-devices refrain from initiating new uplink

Wireless Communications and Mobile Computing 9

Gateway

End-device A

Time

Beacon period

Beacon

poll

End-device B

downlink

uplink

Downlink Uplink

Beacon window

Figure 7 Proposed downlink communication scheme

(a) (b)

Figure 8 Devices used for implementation (a) End-device with SX1272MB2DAS attached to a NUCLEO-L073RZ board (b) Gateway withRAK831 attached to a Raspberry Pi 3

transmissions if remaining time to the next beacon is lessthan Beacon Guard Note that LoRaWAN standard limitsmaximum payload size so that beacon payload cannotconvey a large number of DevAddrs however it can be easilyextended depending on network conditions by using low SFsor allocating short network addresses

6 Implementation

We implemented TRILO using commercially available com-ponents We built a gateway on a RAK831 board [27] whichcontains an SX1301 concentrator chip The gateway board isattached to a Raspberry Pi 3 board as shown in Figure 8(b)For our implementation we employed the Semtech librarieswhich contain LoRaWAN packet forwarder and hardwareabstraction layer for SX1301

In the LoRaWAN architecture a gateway plays a simplerole of a bridge between end-devices and a network serverand a network server performs all beacon and poll messageprocessings We utilize an open source project [28] targetedfor private LoRaWAN network production in implementinga network server Figure 9 describes the message handlermodules that we implemented The beacon handler creates

a beacon payload consisting of the timestamp and buffereddownlink frame information Then it passes the payload tothe packet processor which assembles the payload into abeacon packet Since a beacon needs to be transmitted ina greater time precision than data packets we modified thegateway such that beacons are transmitted immediately Thepoll handler sends a pending downlink frame in responseto a poll message Note that this mechanism is transparentto the LoRaWAN MAC processor and the application serverbecause we implement modules at the packet processor level

An end-device is implemented on a NUCLEO-L073RZboard with an embedded LoRaWAN chip using a 915Mhzantenna (see Figure 8(a)) We attached the SX1272MB2DAScomponent to a NUCLEO-L073RZ board with the modifiedLoRa MAC Note that end-device logics are compiled andstored as firmware in an end-device Time synchronizationbetween nodes and a network server is based on the localtime of a network server instead of GPS time because weimplemented the beacon handler at the server not using thebeacon frame of the Class B standard We modified the end-devicersquos software by adding the beacon handling and pollingfunctions Note that each device which has a pending framewaits for its turn and processing times of each downlink vary

10 Wireless Communications and Mobile Computing

Packet forwarderGateway Packet

processorLoRaWAN

MAC processor

Applicationserver

PUSH DATA

PULL RESP

Pollhandler

Beaconhandler

Figure 9 Block diagram of a network server that handles beacon and poll messages

Figure 10 Experiment environment One gateway (yellow dot) and 15 end-devices (blue dots) are deployed in our office building

due to different SFs In a downlink period we configuredthe time for each poll and downlink based on SF 12 whichhas the longest airtime However the experimental resultsshow that the proposed scheme can be deployed with highperformance even with the conservative configuration It ispossible to optimize the waiting times for each downlinkmore compactly based on the information about SFs of eachnode however we leave this issue as future work

We tuned radios of the components to obey the Koreanregulation which allocates frequency bands from 920Mhzto 923Mhz for LoRaWAN We also added the listen beforetalk (LBT) function as the regulation specifies Note thatthe current LoRaWAN specifications for the KR920-923 ISMband do not have duty cycle limits but require adopting theLBT channel access rule [4]

7 Experimental Results

We evaluate the performance of TRILO by deploying modi-fied components in our office buildingWeplaced the gatewayand three end-devices in our lab Also we deploy 12 moreend-devices on the same floor of the building as shown inFigure 10 The beacon periods are set to either 128 sec or256 sec We varied the uplink and downlink offered loadsfrom 1 2 4 to 8 frames per beacon period The offered trafficis unrealistically large for such a small network however notethat we are trying to emulate the operating conditions of large

scale LoRAWAN networks consisting of tens of thousandsof end-devices Testbeds of such scale are not available soour experiment emulates large networks with 15 end-devicesUplink and downlink messages should be interpreted as anaggregated traffic generated by thousands of end-devicesMessage interarrival times of uplink and downlink trafficfollow the exponential distribution and the destinations ofdownlink messages are randomly and uniformly selectedWe used primitive Adaptive Data Rate (ADR) for SF andpower allocation and all nodes converged to SF 8 and defaultEIRP output power (14dBm) The performance of real-worldLoRaWAN networks depends on the distributions of SFand transmission power However we ignore these factorsbecause improvement of uplink transmissions is not a goalof this work

The performance metrics used in this study includePacket Delivery Ratio (PDR) duty cycle and latency Toobtain reliable results we repeat experiments with the sameparameter values ten times The length of each experimentrun is 10 beacon periods (ie 1280 or 2560 sec) Becausethe destinations of downlinks and the origins of uplinks arerandomly selected it is expected that all end-devices andmessages experience the average performance

First of all we measure the PDR of uplink and downlinkframes We observe that all downlink frames are deliveredsuccessfully without exception The result is rather surprisingbecause TRILO employs beacon broadcasting and polling

Wireless Communications and Mobile Computing 11

Table 3 Packet delivery ratio of uplink traffic at various uplink anddownlink offered loads

Packet generation rate 120582119889 = 1 120582119889 = 2 120582119889 = 4120582119906 = 2 9864 9827 9772120582119906 = 8 9674 9603 9510

in addition to downlink data frames A failure in any onecomponent may lead to unsuccessful data transmissionsUnlike downlink frames uplink traffic experiences occa-sional transmission failures Wemeasure the PDR by varyingthe offered loads of both uplink and downlink traffic Notethat all nodes use the same SF and collisions occur if framesare transmitted on the same channel simultaneously Table 3illustrates the PDR of uplink traffic at different offered loadsBoth uplink and downlink traffic affect the PDR of uplinktraffic The PDR decreases as the offered load of downlinktraffic increases at 120582119906 = 2 the PDR decreases from 9864to 9772 as the offered load of downlink traffic increasesfrom 1 to 4 In addition the uplink traffic intensity also affectsthe PDR of uplink traffic for example at 120582119889 = 2 the PDRdecreases from 9827 to 9603 as the offered load of uplinktraffic increases from 2 to 8

Note that uplink transmissions are prohibited duringpolling and following downlink frame transmissions Uplinkframes which arrive during downlink operation should waituntil the current downlink operation is completed Thiswaiting procedure synchronizes backlogged end-devices andmay cause collisions Even though the LoRa PHY supportsmultiple simultaneous transmissions of different SFs or chan-nels multiple attempts increase the collision probabilitiesand the PDR decreases as both uplink and downlink trafficincrease To reduce the bloated collisions due to synchronoustransmissions persistent mechanisms such as 0-persistenceor p-persistence are required However persistence schemesincrease the complexity of the network protocol and maycause other side effects such as increased energy consump-tion

Next we assess the additional power consumed fordownlink communications Because gateways operate in analways-on mode we only measure the energy consumed byend-devices We use the duty cycle additional time requiredfor downlink communications as the performance metricThe duty cycle is the sum of wake-up times used for beaconreception for possible poll transmission and for downlinkdata frame receptions Figure 11 shows the average duty cycleat different downlink traffic loadsThe duty cycle increases asthe downlink offered load increases it increases from 075to 11 as 120582119889 increases from 1 to 4 Note that all end-devicesconsume the minimal fixed duty cycle for beacon receptionregardless of the intensity of downlink traffic In addition tothe fixed duty cycle end-devices with backlogged downlinkscontinue to stay in the wake-up state for polling and datareception

Figure 12 illustrates the average latency of downlink trafficand uplink traffic as functions of offered load respectively Asshown in Figure 12(a) the average latency of downlink trafficincreases in proportion to the offered load As explained

0

02

04

06

08

1

12

Dut

y Cy

cle (

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

Figure 11 Duty cycles required for downlink operation includingbeacon poll and downlink data transmissions

before downlink frames are generated according to a Poissonprocess Therefore the probability that a downlink frameoccurs in a small time period follows uniform distributionand on average each downlink frame waits one-half of thebeacon interval In addition frames that arrive during adownlink processing are postponed to the next beacon InFigure 12(a) we can observe that the effect of uplink traffic onthe average latency of downlink is minimal This result is notsurprising because uplink and downlink communications arewell isolated in the proposed scheme

Like the average downlink latency the average uplinklatency increases as the downlink offered load increasesUplink frames that arrive during downlink periods shouldwait until the end of the current downlink periodThe averagelatency of uplink traffic as well as the duty cycle increase asthe downlink offered load increases Contrary to Figure 12(a)where the average downlink latency is seldom affected bythe uplink offered load the average uplink latency increasesproportionally as the uplink offered load increases As theuplink communication demands increase a queue startsto form and this causes the increase in waiting time Thequeueing time is most distinctive at 120582119889 = 4 when the servicetime for uplink communications is minimal

8 Simulation Results

We also compared the performance of the Class B downlinkscheme and that of TRILO Because commercial LoRaWANdevices do not support Class B functions yet we relied oncomputer simulations for the performance comparison Thesimulation code is written primarily in CC++ and we con-duct extensive simulations in a typical LoRaWAN networkand in a heavy downlink traffic condition respectively Tocompare energy consumed for downlink communicationswe define the efficiency of each protocol as a performancemetric The efficiency defined as the ratio of data transmis-sion time to the duty cycle is the fraction of time used foruseful work

12 Wireless Communications and Mobile Computing

Ｏ = 2

Ｏ = 8

70

75

80

85

90

95

100

105D

ownl

ink

Late

ncy

(sec

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

(a)

1

2

3

4

5

6

7

8

Upl

ink

Late

ncy

(sec

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

Ｏ = 2

Ｏ = 8

(b)

Figure 12 Average latency of traffic (a) Downlink latency (b) Uplink latency

Table 4 Notations used for Class B downlink protocol and TRILO

Notation Meaning119863119879 Duty cycle of TRILO119863119861 Duty cycle of the Class B downlink protocol119879119879119861119890119886119888119900119899 Beacon transmission time of TRILO

119879119861119861119890119886119888119900119899 Beacon transmission time of the Class B downlinkprotocol

119879119901119900119897119897 Average poll frame transmission time119879119889119900119908119899 Average downlink frame transmission time119896 Parameter for the Class Brsquos ping slots

119868119864 Indicator function representing a node is backlogged ornot

According to the LoRaWAN standard implementation ofthe Class B downlink scheme discretizes the time into so-called ping slots Each end-device requests 2119896 (0 le 119896 le 7)ping slots per beacon period We use the average case of theClass B where each end-device randomly selects a value ofthe parameter 119896 between 0 and 7 Let us first introduce thenotations for the analysis of LoRaWAN downlink protocol(Table 4)

We used SF 9 for beacon transmissions according to theLoRaWAN specification KR920-923 [29] The duty cycle ofTRILO119863119879 is

119863119879 =119879119879119861119890119886119888119900119899 + 119868119864 sdot (119879119901119900119897119897 + 119879119889119900119908119899)

119861119890119886119888119900119899 119875119890119903119894119900119889 (7)

Note that unlike 119879119861119861119890119886119888119900119899 119879119879119861119890119886119888119900119899 increases in proportion tothe number of busy end-devices The duty cycle of a Class Bdevice 119863119861 is

119863119861 = 119879119861119861119890119886119888119900119899 + 2119896 sdot 119879119889119900119908119899119861119890119886119888119900119899 119875119890119903119894119900119889 (8)

Class B devices have different duty cycles depending onrandomly selected values of parameter 119896 Then the efficiencyis computed as

119864119891119891119894119888119894119890119899119888119910 = 119863119900119908119899119897119894119899119896 119905119903119886119899119904119898119894119904119904119894119900119899 119905119894119898119890119863119906119905119910 119888119910119888119897119890119904 (9)

We measured the efficiency of TRILO and the Class Bdownlink protocol by varying the number of nodes from 50to 4000 and the downlink offered load from 2 to 32 framesper beacon period Each performance point is the average of10000 runs We limit the maximum downlink traffic to 32frames per beacon interval because uplink traffic is greaterthan downlink traffic in many LoRaWAN applications Notethat at 120582119889 = 32 about a half of beacon period is consumed fordownlink communications if we assume that the downlinktransmission time is 2 seconds on average

The efficiency of each scheme is shown in Figure 13Note that the offered load is aggregated load and the trafficintensity of individual node decreases as the number of nodesincreases The total times for downlink communications arefixed at each given offered load However the sum of dutycycles increases as the number of nodes increases Thereforein both protocols the maximum efficiencies are realized atsmall networks and the efficiency decreases as the networksize increases The results illustrate that efficiencies of TRILOare higher than those of the Class B downlink protocolthroughout all downlink generation ratesTheClass B schemeperforms well in heavy traffic cases However the proposedscheme outperforms the Class B scheme even in heavy trafficconditions In small networks the performance gap decreasesfrom about 139 times to about 33 times as 120582119889 increases from2 to 32 Also each gap in each offered load increases as thenetwork size increases In the case of TRILO the averageduty cycle decreases inversely proportional to the number ofnodes because only busy devices are active during downlink

Wireless Communications and Mobile Computing 13

Number of Nodes500 1000 1500 2000 2500 3000 3500 4000

10minus3

10minus2

Effici

ency

10minus1

100

101

Class B (＞ = 2)

Proposed (＞ = 2)

Class B (＞ = 8)

Proposed (＞ = 8)

Class B (＞ = 32)

Proposed (＞ = 32)

Figure 13 Efficiency of TRILO and Class B downlink protocol

periods On the contrary Class B protocol allocates 31 pingslots on average regardless of downlink demands In shortthe number of receive windows wasted by the Class B schemevaries depending on the amount of downlink traffic howeveronly busy devices use extra duty cycle for downlink traffic inTRILO

The Class B protocol does not coordinate traffic betweenuplinks and downlinks so that several uplinks can be dis-rupted by downlink transmissions due to the half-duplexcharacteristic of a LoRaWAN gateway all reception pathscan be blocked by downlink transmissions It can obstructthe proper operations of typical LoRaWANs where uplinktransmissions are predominant In contrast the proposedscheme is free from this problem because it isolates the timefor uplinks and downlinks periods

9 Conclusions

A plethora of LPWAN techniques such as LoRa SigFoxRPMA and Weightless have emerged as a new enablingnetwork technology for IoT applications that require low-rate low-cost and long lifetimes LPWANs allow end-deviceinitiated uplinks However to maximize the lifetime ofbattery powered end-devices nodes are put into the sleepstate such that rather restricted downlink communicationsare permitted In this paper we proposed a new downlinkprotocol named TRILO for LoRaWAN

Because LoRaWAN assumes a star topology where mul-tiple end-devices are connected to a single gateway weadopted a beacon based downlink mechanism similar to theIEEE 80211 PSM standard A gateway broadcast beaconsperiodically at every beacon period and end-devices are timesynchronized Beacons alert nodes with buffered downlinksin addition to synchronizing end-devicesrsquo clocks Customizedto the physical characteristics of LoRa we designed two

polling schemes concurrent polling and sequential pollingAn analysis indicates that sequential polling is more energyefficient than concurrent polling

We implement the proposed beacon based downlinkprotocol using commercially available components and con-duct experiments with modified devices Our performancestudy shows that Packet Delivery Ratio (PDR) is almost100 for both uplink and downlink traffic and the extrawake-up time to receive beacons and downlinks is minimalSimulation results also show that our proposed protocol canadaptively allocate receive windows resulting in lower energyconsumption

For further work we plan to investigate the impact ofour scheme on the networks with multiple gateways Alsodetailed investigations of impact of the number of downlinksand the certain distributions of SFs on the performanceseem interesting Optimization techniques leveraging SF andpower allocation are expected to affect the performance of theproposed scheme

Data Availability

The data used to support the findings of this study areincluded within the article

Disclosure

The funding sponsors had no role in the study in thecollection analyses or interpretation of data in the writingof the manuscript and in the decision to publish the results

Conflicts of Interest

The authors declare that there are no conflicts of interestregarding the publication of this paper

14 Wireless Communications and Mobile Computing

Acknowledgments

This work was supported by the National Research Founda-tion of Korea (NRF) Grant funded by the Korean Govern-ment (MSIP) (No 2016R1A5A1012966) Institute for Infor-mation amp Communications Technology Promotion (IITP)grant funded by the Korea government (MSIT) (No 2015-0-00557 ResilientFault-Tolerant Autonomic NetworkingBased on Physicality Relationship and Service Semantic ofIoT Devices) and the MSIP (Ministry of Science ICT andFuture Planning) Korea under the ITRC (Information Tech-nology Research Center) support program (IITP-2018-2015-0-00378) supervised by the IITP (Institute for Informationamp Communications Technology Promotion) Also the snu-samsung smart campus research center at Seoul NationalUniversity provides research facilities for this study

References

[1] M Bor U Roedig T Voigt and J M Alonso ldquoDo LoRalow-power wide-area networks scalerdquo in Proceedings of the19th ACM International Conference on Modeling Analysis andSimulation of Wireless and Mobile Systems MSWiM 2016 pp59ndash67 Malta November 2016

[2] DMagrinMCentenaro andLVangelista ldquoPerformance eval-uation of LoRa networks in a smart city scenariordquo inProceedingsof the 2017 IEEE International Conference on CommunicationsICC 2017 France May 2017

[3] LoRa httpswwwlora-allianceorgWhat-Is-LoRaTechnol-ogy

[4] ldquoLoRaWAN 11 specificationrdquo LoRa Alliance 2017 httpslora-allianceorgresource-hublorawantm-specification-v11

[5] M Bor J Vidler and U Roedig ldquoLoRa for the internet ofthingsrdquo in Proceedings of the International Conference onEmbedded Wireless Systems and Networks (EWSN rsquo16) pp 361ndash366 Junction Publishing 2016

[6] 3GPP ldquoStudy on provision of low-cost Machine-Type Commu-nications User Equipments based on LTErdquo TR 36888 V120006 2013

[7] 3GPP ldquoCellular system support for ultra-low complexity andlow throughput Internet of Thingsrdquo TR 45820 V1310 11 2015

[8] J Gozalvez ldquoNew 3GPP Standard for IoTrdquo IEEE VehicularTechnology Magazine vol 11 no 1 pp 14ndash20 2016

[9] R Ratasuk N Mangalvedhe and A Ghosh ldquoOverview ofLTE enhancements for cellular IoTrdquo in Proceedings of the 26thIEEE Annual International Symposium on Personal Indoor andMobile Radio Communications PIMRC 2015 pp 2293ndash2297China September 2015

[10] H Shariatmadari R Ratasuk S Iraji et al ldquoMachine-type com-munications current status and future perspectives toward 5Gsystemsrdquo IEEE CommunicationsMagazine vol 53 no 9 pp 10ndash17 2015

[11] S Landstrom J Bergstrom E Westerberg and D Hammar-wall ldquoNBIoT a sustainable technology for connecting billionsof devicesrdquo Ericsson Technology Review vol 4 pp 2ndash11 2016

[12] M Lauridsen I Z Kovacs P Mogensen M Sorensen andS Holst ldquoCoverage and capacity analysis of LTE-M and NB-IoT in a rural areardquo in Proceedings of the 2016 IEEE 84thVehicular Technology Conference (VTC-Fall) pp 1ndash5 MontrealQC Canada September 2016

[13] Sigfox httpwwwsigfoxcom[14] Weightless open standard httpwwwweightlessorg[15] Ingenu RPMA httpwwwingenucomtechnologyrpma[16] A Dunkels ldquoThe ContikiMAC radio duty cycling protocolrdquo

Technical Report T201113 Swedish Institute of ComputerScience 2011

[17] J Ko J Eriksson N Tsiftes et al ldquoIndustry Beyond interoper-ability - Pushing the performance of sensor network IP stacksrdquoin Proceedings of the 9th ACM Conference on Embedded Net-worked Sensor Systems SenSys 2011 pp 1ndash11 USA November2011

[18] D Moss J Hui and K Klues ldquoTEP 105 low power listeningrdquohttpwwwtinyosnettinyos-2xdocpdftep105pdf 2008

[19] C Gomez J Oller and J Paradells ldquoOverview and evaluationof bluetooth low energy an emerging low-power wirelesstechnologyrdquo Sensors vol 12 no 9 pp 11734ndash11753 2012

[20] A A Kandhalu A E Xhafa and S Hosur ldquoTowards bounded-latency bluetooth low energy for in-vehicle network cablereplacementrdquo in Proceeding of the International Conference onConnected Vehicles and Expo (ICCVE) pp 635ndash640 Las VegasNV USA 2013

[21] A Montanari S Nawaz C Mascolo and K Sailer ldquoA studyof bluetooth low energy performance for human proximitydetection in the workplacerdquo in Proceedings of the 2017 IEEEInternational Conference on Pervasive Computing and Commu-nications PerCom 2017 pp 90ndash99 Kona HI USA March 2017

[22] C Julien C Liu A L Murphy and G P Picco ldquoBLEnd Practi-cal continuous neighbor discovery for bluetooth low energyrdquo inProceedings of the 16th ACMIEEE International Conference onInformation Processing in Sensor Networks IPSN 2017 pp 105ndash116 New York NY USA April 2017

[23] Y Qiu S Li X Xu and Z Li ldquoTalk more listen less energy-efficient neighbor discovery in wireless sensor networksrdquo inProceedings of the 35th Annual IEEE International Conference onComputer Communications IEEE INFOCOM 2016 USA April2016

[24] A J Berni andW D Gregg ldquoOn the utility of chirpmodulationfor digital signalingrdquo IEEE Transactions on Communicationsvol 21 no 6 pp 748ndash751 1973

[25] A Springer W Gugler M Huemer L Reindl C C W Ruppeland R Weigel ldquoSpread spectrum communications using chirpsignalsrdquo in Proceedings of the IEEEAFCEA Information Systemsfor Enhanced Public Safety and Security EUROCOMM2000 pp166ndash170 Germany

[26] IEEE Std 80211-2007 ldquoIEEE Standard for Information Tech-nologymdashTelecommunications and Information Exchange be-tween SystemsmdashLocal and Metropolitan Area NetworksmdashSpecific Requirements Part 11 Wireless LAN Medium AccessControl (MAC) and Physical Layer (PHY) Specifications June2007rdquo

[27] RAK831 httpwwwrakwirelesscomenWisKeyOSHRAK831[28] LoRaWAN network server httpsgithubcomgotthardplor-

awan-server[29] ldquoLoRaWAN 11 Regional Parametersrdquo LoRa Alliance 2017

httpslora-allianceorgresource-hublorawantm-regional-pa-rameters-v11ra

4 Wireless Communications and Mobile Computing

EU868

EU433 hellipKR

920AS430

US915

LoRa Modulation

Applications

LoRa MAC

Class A Class B Class C

LoRa Specifications

LoRaWAN specifications

Figure 1 LoRa and LoRaWAN specifications

Table 1 Frequency bands and bandwidths allocated for LoRa

Location Europe North America Korea China JapanFrequencyband(MHz)

867-869 902-928 920-923 470-510779-787 920-925

Channels 10 64+8+8 13 - -Uplink CH BW(KHz) 125250 125500 125 - -Downlink CHBW(KHz)

125 125 125 - -

Tx power Up(dBm) +14 dBm +20sim+30 dBm +10sim+14 dBm - -

Tx power Down(dBm) +14 dBm +27 dBm +23 dBm - -

3 A Primer on LoRa and LoRaWAN

This section contains a brief overview of LoRa and LoRaWANtechnologies Specifically technical properties that influenceor limit the design space of LoRaWAN based downlinkprotocol will be addressed

Figure 1 shows the protocol stack of LoRa and LoRaWAN[4] LoRa developed and owned by Semtech [3] is a proprietytechnique that defines a physical layer customized for LPWAcommunications LoRaWAN which defines a MAC layer ontop of LoRa is an open standard developed by a nonprofitorganization called LoRa alliance LoRa operates on the900MHz ISM spectrum and adopts the CSS (Chirp SpreadSpectrum) modulation technique CSS [24 25] based onchirped-FM modulation yields high processing gains andenables long transmissions at the expense of data rates LoRasupports Adaptive Data Rate (ADR) which varies data ratesadapting to transmission distances and channel conditionsWhen the SNRs are low LoRa lowers the data rate to severalhundred bits per second by using large SF (Spreading Factor)and robust CR (Coding Rate)When SF and bandwidth (BW)are selected the data rate 119877119878119865 is determined as 1198781198652119878119865 ∙119861119882 The lowest data rate of LoRa determined at SF=12 andBW=125 KHz is approximately 300 bits per second Thehighest data rate is approximately 11 Kbps and is obtained atSF=7 and BW=250 KHz High data rates can be achievablewhen channel conditions are good SF=7 requires -120 dBmwhile SF=12 requires only -136 dBm

Each country allocates different frequency bands andbandwidth for LoRa Table 1 illustrates the frequency bandsbandwidth and transmission powers defined by the regula-tory bodies at several regions and countries It is worthwhileto note that a device that locks on one SF can successfullyreceive a signal even though signals of different SF exist atthe same time on the same subchannel Moreover gatewayscan simultaneously receive multiple transmissions if eithersubchannels or SFs are different Currently the SX1301 basedgateway supports concurrent demodulations up to 8 signals

LoRarsquos CSS modulation enables packet receptions evenwhen the signal power is much less than the absolute noisefloor The high reception sensitivity makes carrier sensingpractically impossible Lack of carrier sensing forces theoriginal LoRa to use the Aloha MAC that suffers fromexcessive collisions Even though some countries require LBT(Listen Before Talk) it is quite difficult to sense on-goingLoRa signals without synchronizing with preambles Thispaper assumes that all devices use the Aloha MAC

The LoRaWAN end-devices are classified into threeclasses Classes A B and C A Class A devicemdashbidirectionalend-devicesmdashcan initiate uplink transmissions only It canreceive downlink frames but only as a response to uplinkframes that it has initiated Figure 2 describes the timingof an initial uplink transmission and following downlinktransmissions The timing of downlink transmissions shouldbe carefully coordinated the server should schedule adownlink such that its transmission interval is coincident

Wireless Communications and Mobile Computing 5

Gateway

End-device

Time

Uplink RX1 RX2

RECEIVE_DELAY2

RECEIVE_DELAY1

Downlink

Figure 2 Class A end-device initiated uplink and responding downlinks

Gateway

End-device

Time

4

Beacon_Window

Beacon_Guard Beacon_Reserved

Beacon_Period

7 265 516

Beacon

Ping slots for node X

Ping slots for node Y

Figure 3 Beacon based Class B downlink scheme

with predetermined receive windows Class A end-nodessacrifice asynchronous downlink transmissions but attainlong lifetimes as a reward It is expected that battery poweredClass A end-devices enjoy ten to twenty years of lifetimes inreasonable use cases Class A is suitable for sensor nodes thatreport sensing data periodically or when the readings satisfypredetermined criteria

Unlike a Class A end-device Class B and C devices sup-port downlink communications A Class C end-device oper-ates in an always-on mode and wastes significant amountsof energy for idle listening required for the receptions ofasynchronous downlinks Class B end-devicesmdashbidirectionalend-devices with scheduled receive slotsmdashsupport syn-chronous server-initiated downlinks Class B end-devicesmust be time synchronized with the gateway which transmitsbeacons at every beacon period of 128 seconds Once beingsynchronized Class B end-devices wake up at each beaconperiod to maintain the synchronization LoRa discretizes thetime into so-called ping slots each of which is 30 mSec longOne beacon period contains 4096 ping slots and a devicecan request 2119896 (0 le 119896 le 7) ping slots per beacon periodThe first ping slot position is determined randomly and p-th ping slot starts at 119905119861119864119860119862119874119873 119877119864119878119864119877119881119864119863 + (1199030 + (119901 minus 1) ∙212minus119896) ∙ 30 where 119905119861119864119860119862119874119873 119877119864119878119864119877119881119864119863 is the time when theBEACON RESERVED finishes 1199030 is the first offset randomlyselected Figure 3 shows the beacon timing and an example

of Class B end-devicesrsquo ping slot schedules (nodes X and Y)whose parameters are 119896 = 3 and 1199030 = 4 and 119896 = 4 and 1199030 = 7respectively

The downlink protocol for Class B end-devices incurssignificant overheads In addition to beacons they mustblindly wake up at their reserved ping slots regularly eventhough there are no buffered frames for them Also devicesconsume energy to maintain a precise clock to catch theinterrupts during ping slots We design and implement a newdownlink scheme to reduce such overheads

4 Downlink Communications Scheme

There can be many alternative methods for downlink trans-missions One simple method is to utilize the Class A uplink-downlink transaction an end-device periodically transmitsprobe messages to the server and if there is a downlinkmessage for the device the server sends it as a responseto the uplink probe This method is effective and energyefficient if end-devices can guess the existence of downlinkmessages correctly However exact prediction of downlinksis practically impossible Because end-devices cannot predictwhen downlink packets are ready they can issue either toomany unnecessary probes when the probing interval is shortor suffer from long latencies when the probing interval islong

6 Wireless Communications and Mobile Computing

Preamble PHDR

MHDR MACPayload MIC

1

1

1 25 4

4

TimeStamp DevAddr

PHYPayloadPHDR_CRC

(a)

Preamble PHDR_CRCPHDR PHYPayload CRC

MHDR DevAddr MIC

1 44

(b)

Figure 4 Beacon and poll message formats (a) Beacon (b) Poll

Broadcasting is an effective mechanism to disseminatecontrol information in a network that supports one to manycommunications Indeed IEEE 80211 WLANs [26]mdashwherean AP and multiple stations form a one to many networkmdashadopt the periodic broadcast scheme to alert backloggedmobile stations in the Power Saving Mode (PSM) A WLANAPperiodically (usually every 100mSec) broadcasts a beaconmessage that contains Traffic Indication Map (TIM) A TIMenumerates mobile stations that have buffered downlinkpackets Stations in the sleep mode wake up periodically atevery beacon interval to listen TIMs Backlogged stationsthen send PS-Poll frames requesting downlink packet trans-missions As soon as a station receives a buffered frame itfalls back to the sleep mode until the next beacon Stationswithout buffered downlink frames immediately return to thesleep state to minimize energy consumption

Because a LoRaWAN forms a star (more precisely astar-of-stars topology) and supports broadcasting like IEEE80211 WLAN it is natural to adopt a downlink mechanismsimilar to the IEEE 80211 PSM In addition as explained inthe previous section on LoRaWAN primer the LoRaWANstandard already supports a beacon mechanism for timesynchronization We can easily modify the structure of aLoRaWANrsquos beacon frame to augment a field that specifiesbacklogged end-devices This additional field is similar tothe TIM field of the WLAN The message formats of beaconand poll frames are shown in Figure 4 Compared to beacontransmission polling mechanisms for LoRaWAN ask for acareful design because the MAC protocols in LoRaWAN arepractically limited to the unslotted Aloha scheme Given thatcarrier sensing is prohibited a beacon triggers synchronizedmedium access from backlogged end-devices and causesexcessive collisions On the other hand a LoRaWAN is robustagainst collisions because it supports multiple simultaneousreceptions of different SFs and different subbands In shortbecause polling can affect the performance of overall systems

significantly it is worthwhile to carefully analyse all aspectsthat may affect the performance

We consider two polling mechanisms concurrent pollingand sequential polling Before delving into the details ofpolling schemes let us first introduce the notations used forthe following analysis (Table 2)

Concurrent polling is designed to best exploit the char-acteristics of the LoRarsquos PHY layer Note that a gatewaycan receive multiple signals simultaneously if their channelsor SFs are different Commercially available gateways sup-port concurrent demodulation up to 8 signals however letus assume that the number of simultaneous receptions isincreased multiplicatively by deploying multiple gatewaysFor example if a LoRa network uses 10 channels and 6different SFs as in Europe then the maximum of 60 pollscan be delivered simultaneously when more than or equalto 8 gateways are deployed Let busy and idle devices beend-devices with and without pending downlink framesrespectively Hearing a beacon all busy end-devices transmitpolls to the server simultaneously as shown in Figure 5(a)Polls that are in the same subchannel and of the same SF willexperience collisions and will be lost For example polls fromdevices 1198641 1198642 119886119899119889 1198643 are transmitted successfully How-ever polls from devices 1198644 119886119899119889 1198645 will collide and will belost

Let n andmbe the number of themaximumsimultaneousframes that the network allows and the number of framesthat arrive during a beacon period (ie the number ofpolls assuming that there is at most one frame per end-device) The expected number of successful polls is m ∙119890minus119898119899 approximately Because collided polls will competeagain at the next beacon interval the actual number of pollscompeting at each beacon is approximated as1198981015840 = 119898+119898(1minus119890minus119898119899)

Idle devices fall back to the sleep state as soon as theyrecognize there are no frames for them The maximum

Wireless Communications and Mobile Computing 7

Table 2 Notations

Notation Meaning

119863119887 Size of a beacon except preamble the minimum size is 17+4∙ m bytes where m is the number of end-devices with buffereddownlinks

119863119901 Size of a poll frame except preamble The minimum size can be 4119863119889 Average size of a downlink frame except preamble119905119888 Time to compensate clock drift According to the LoRaWAN standard it is set to 13 mSec119905119892 Time gap between two consecutive frames during downlink operation Frames include poll and data119903119887 Beacon broadcasting data rateThe standard specifies using SF=12 and the data rate is 250 bps119903119901 Average poll frame transmission data rate119903119889 Average downlink frame transmission data rate

GatewayTime

Channel=3 SF=7

Channel=3 SF=10

Channel=2 SF=7

Channel=4 SF=10

Channel=4 SF=10

E1

E2

E3

E4

E5

(a)

GatewayTime

Channel=3 SF=7

Channel=3 SF=10

Channel=2 SF=7

Channel=4 SF=10

Channel=4 SF=10

E1

E2

E3

E4

E5

(b)

Figure 5 Example of polling mechanisms (a) Concurrent polling (b) Sequential polling

wake-up time of an idle device during a beacon period 119882119862119868 is computed as follows

119882119862119868 = 119905119888 + 119863119887119903119887 (1)

A busy end-device transmits a poll and waits until it receivesits downlink As soon as it receives the downlink it turnsits radio off until the next beacon Because the gatewaytransmits downlinks only to the end-devices whose polls aresuccessfully received on the average 1198981015840 ∙ 119890minus1198981015840119899 downlinkframes will be transmitted The average maximum wake-uptime of a busy device whose poll is delivered successfully tothe gateway is

119882119862119861119878 = 119905119888 + 119863119887119903119887 + 119863119901

119903119901 + 12 ∙ (119905119892 + 119863119889

119903119889 ) ∙ 1198981015840 ∙ 119890minus1198981015840119899 (2)

A busy device whose poll fails to reach to the gateway mustwait until all downlink transmissions are completed and itswake-up time is

119882119862119861119865 = 119905119888 + 119863119887119903119887 + 119863119901

119903119901 + (119905119892 + 119863119889119903119889 ) ∙ 1198981015840 ∙ 119890minus1198981015840119899 (3)

Under a simple assumption that all end-devices are equallyprobable to have a pending downlink frame the sumof wake-up times of all M devices under the synchronous pollingscheme is

(119872 minus 1198981015840) ∙ 119882119862119868 + 1198981015840 ∙ 119890minus1198981015840119899 ∙ 119882119862119861119878 + 1198981015840

∙ (1 minus 119890minus1198981015840119899) ∙ 119882119862119861119865(4)

The average time that a node should turn on its batteryto receive a downlink is derived by dividing (4) by themultiplication of M and the average number of successfuldownlinks per beacon period

Another scheme that we have considered is sequentialpolling Unlike the contention based concurrent polling end-devices poll and receive downlink in the same order that theiraddresses appeared in the DevAddr fields of a beacon frameFigure 5(b) shows an example of sequential polling Receivinga beacon busy devices remember their positions in theDevAddr field and all devices except the first busy device fallback to the sleep state The first busy device transmits a polland receives a downlink frameThe second busy device wakes

8 Wireless Communications and Mobile Computing

Concurrent n = 8Concurrent n = 16Sequential

8 162 1 4 Offered Load

0

50

100

150

200

250

300

350

400

450

500W

ake-

up ti

me (

mse

c)

(a)

Concurrent n = 8Concurrent n = 16Sequential

8 162 1 4 Offered Load

0

5

10

15

Wak

e-up

tim

e (m

sec)

(b)

Figure 6 Performance of concurrent polling and sequential polling (a) Average wake-up time of both idle and busy devices (b) Averagewake-up time of busy devices

up after one poll-data frame exchange time to poll and receiveits downlinkThe sameprocedure repeats for succeeding busydevices Equation (5) is the average maximum wake-up timeof a busy device

119882119878119861 = 119905119888 + 119863119887119903119887 + 119863119901

119903119901 + (119905119892 + 119863119889119903119889 ) (5)

Moreover the sum of all wake-up times during a beaconperiod is

(M minus m) ∙ 119882119878119868 + 119898 ∙ 119882119878119861 (6)

5 Comparison of Two Polling Schemes

We compared the two polling methods by varying the valuesof parameters that may affect performance The performancemetric is the average wake-up time required for the receptionof one downlink frame We varied the total number of end-devices (M) in a network the number of downlink messagesper beacon interval and the network capacity for concurrenttransmissions (n) Figure 6 shows the average wake-up timesof concurrent and sequential polling as functions of theoffered loadThe unit of the offered load is the number of newdownlink frames generated per beacon interval Figures 6(a)and 6(b) are the wake-up time of all end-devices includingboth idle and busy devices and the wake-up time of busydevices only respectively When calculating the wake up timeof busy devices only terms (119872minus1198981015840)∙119882119862119868 and (Mminusm)∙119882119878119868 in(4) and (6) are excluded We used two values (n=8 and n=16)of network capacity to analyse the effect of maximum simul-taneous receptions For simplicity we assume that receptionpaths of gateways are ideally utilized as each gateway does notlock on the same packet In both Figures 6(a) and 6(b) we

can observe that sequential polling is more effective in powerconserving than concurrent polling When the offered load issmall the performance differences are not great However asthe offered load increases the gap increases also and at m=16concurrent polling consumes 3 to 22 times more energy thansequential polling in the case of all devices (Figure 6(a))Moreover in the case of busy devices only (Figure 6(b))concurrent polling consumes 55 to 41 times more energythan sequential polling The number of total end-devices isfixed at 1000We performed the same analysis by varying thevalue of M and obtain the similar results

We also can observe that concurrent polling at n=16 isbetter than that at n=8 As n increases the probability of colli-sion decreases Collisions affect the performance in twowaysA device whose poll fails to reach a gateway wastes energybecause it should wait until all downlinks are completedAlso collisions increase the offered load at the followingbeacon period and an inflated load again increases the col-lision probability Generally the wake-up time of all devicesdecreases as the offered load increases up to 4 (Figure 6(a))However as the offered load exceeds network capacity (n)wake-up time increases sharply

Because our analytic study reveals the performance ad-vantage of sequential polling over concurrent polling weadopt sequential polling for our downlink communicationscheme Figure 7 illustrates TRILO in a greater detailBeacon Window is divided into downlink reception timeand uplink transmission time After a beacon busy devicesreceive downlink frames sequentially during downlink timeAfter that nodes transmit uplink messages like plain ClassA devices One problem is that uplink transmissions orthe downlinks responding to uplinks may overlap with thefollowing beacon To avoid the problem the Beacon Guardis introduced end-devices refrain from initiating new uplink

Wireless Communications and Mobile Computing 9

Gateway

End-device A

Time

Beacon period

Beacon

poll

End-device B

downlink

uplink

Downlink Uplink

Beacon window

Figure 7 Proposed downlink communication scheme

(a) (b)

Figure 8 Devices used for implementation (a) End-device with SX1272MB2DAS attached to a NUCLEO-L073RZ board (b) Gateway withRAK831 attached to a Raspberry Pi 3

transmissions if remaining time to the next beacon is lessthan Beacon Guard Note that LoRaWAN standard limitsmaximum payload size so that beacon payload cannotconvey a large number of DevAddrs however it can be easilyextended depending on network conditions by using low SFsor allocating short network addresses

6 Implementation

We implemented TRILO using commercially available com-ponents We built a gateway on a RAK831 board [27] whichcontains an SX1301 concentrator chip The gateway board isattached to a Raspberry Pi 3 board as shown in Figure 8(b)For our implementation we employed the Semtech librarieswhich contain LoRaWAN packet forwarder and hardwareabstraction layer for SX1301

In the LoRaWAN architecture a gateway plays a simplerole of a bridge between end-devices and a network serverand a network server performs all beacon and poll messageprocessings We utilize an open source project [28] targetedfor private LoRaWAN network production in implementinga network server Figure 9 describes the message handlermodules that we implemented The beacon handler creates

a beacon payload consisting of the timestamp and buffereddownlink frame information Then it passes the payload tothe packet processor which assembles the payload into abeacon packet Since a beacon needs to be transmitted ina greater time precision than data packets we modified thegateway such that beacons are transmitted immediately Thepoll handler sends a pending downlink frame in responseto a poll message Note that this mechanism is transparentto the LoRaWAN MAC processor and the application serverbecause we implement modules at the packet processor level

An end-device is implemented on a NUCLEO-L073RZboard with an embedded LoRaWAN chip using a 915Mhzantenna (see Figure 8(a)) We attached the SX1272MB2DAScomponent to a NUCLEO-L073RZ board with the modifiedLoRa MAC Note that end-device logics are compiled andstored as firmware in an end-device Time synchronizationbetween nodes and a network server is based on the localtime of a network server instead of GPS time because weimplemented the beacon handler at the server not using thebeacon frame of the Class B standard We modified the end-devicersquos software by adding the beacon handling and pollingfunctions Note that each device which has a pending framewaits for its turn and processing times of each downlink vary

10 Wireless Communications and Mobile Computing

Packet forwarderGateway Packet

processorLoRaWAN

MAC processor

Applicationserver

PUSH DATA

PULL RESP

Pollhandler

Beaconhandler

Figure 9 Block diagram of a network server that handles beacon and poll messages

Figure 10 Experiment environment One gateway (yellow dot) and 15 end-devices (blue dots) are deployed in our office building

due to different SFs In a downlink period we configuredthe time for each poll and downlink based on SF 12 whichhas the longest airtime However the experimental resultsshow that the proposed scheme can be deployed with highperformance even with the conservative configuration It ispossible to optimize the waiting times for each downlinkmore compactly based on the information about SFs of eachnode however we leave this issue as future work

We tuned radios of the components to obey the Koreanregulation which allocates frequency bands from 920Mhzto 923Mhz for LoRaWAN We also added the listen beforetalk (LBT) function as the regulation specifies Note thatthe current LoRaWAN specifications for the KR920-923 ISMband do not have duty cycle limits but require adopting theLBT channel access rule [4]

7 Experimental Results

We evaluate the performance of TRILO by deploying modi-fied components in our office buildingWeplaced the gatewayand three end-devices in our lab Also we deploy 12 moreend-devices on the same floor of the building as shown inFigure 10 The beacon periods are set to either 128 sec or256 sec We varied the uplink and downlink offered loadsfrom 1 2 4 to 8 frames per beacon period The offered trafficis unrealistically large for such a small network however notethat we are trying to emulate the operating conditions of large

scale LoRAWAN networks consisting of tens of thousandsof end-devices Testbeds of such scale are not available soour experiment emulates large networks with 15 end-devicesUplink and downlink messages should be interpreted as anaggregated traffic generated by thousands of end-devicesMessage interarrival times of uplink and downlink trafficfollow the exponential distribution and the destinations ofdownlink messages are randomly and uniformly selectedWe used primitive Adaptive Data Rate (ADR) for SF andpower allocation and all nodes converged to SF 8 and defaultEIRP output power (14dBm) The performance of real-worldLoRaWAN networks depends on the distributions of SFand transmission power However we ignore these factorsbecause improvement of uplink transmissions is not a goalof this work

The performance metrics used in this study includePacket Delivery Ratio (PDR) duty cycle and latency Toobtain reliable results we repeat experiments with the sameparameter values ten times The length of each experimentrun is 10 beacon periods (ie 1280 or 2560 sec) Becausethe destinations of downlinks and the origins of uplinks arerandomly selected it is expected that all end-devices andmessages experience the average performance

First of all we measure the PDR of uplink and downlinkframes We observe that all downlink frames are deliveredsuccessfully without exception The result is rather surprisingbecause TRILO employs beacon broadcasting and polling

Wireless Communications and Mobile Computing 11

Table 3 Packet delivery ratio of uplink traffic at various uplink anddownlink offered loads

Packet generation rate 120582119889 = 1 120582119889 = 2 120582119889 = 4120582119906 = 2 9864 9827 9772120582119906 = 8 9674 9603 9510

in addition to downlink data frames A failure in any onecomponent may lead to unsuccessful data transmissionsUnlike downlink frames uplink traffic experiences occa-sional transmission failures Wemeasure the PDR by varyingthe offered loads of both uplink and downlink traffic Notethat all nodes use the same SF and collisions occur if framesare transmitted on the same channel simultaneously Table 3illustrates the PDR of uplink traffic at different offered loadsBoth uplink and downlink traffic affect the PDR of uplinktraffic The PDR decreases as the offered load of downlinktraffic increases at 120582119906 = 2 the PDR decreases from 9864to 9772 as the offered load of downlink traffic increasesfrom 1 to 4 In addition the uplink traffic intensity also affectsthe PDR of uplink traffic for example at 120582119889 = 2 the PDRdecreases from 9827 to 9603 as the offered load of uplinktraffic increases from 2 to 8

Note that uplink transmissions are prohibited duringpolling and following downlink frame transmissions Uplinkframes which arrive during downlink operation should waituntil the current downlink operation is completed Thiswaiting procedure synchronizes backlogged end-devices andmay cause collisions Even though the LoRa PHY supportsmultiple simultaneous transmissions of different SFs or chan-nels multiple attempts increase the collision probabilitiesand the PDR decreases as both uplink and downlink trafficincrease To reduce the bloated collisions due to synchronoustransmissions persistent mechanisms such as 0-persistenceor p-persistence are required However persistence schemesincrease the complexity of the network protocol and maycause other side effects such as increased energy consump-tion

Next we assess the additional power consumed fordownlink communications Because gateways operate in analways-on mode we only measure the energy consumed byend-devices We use the duty cycle additional time requiredfor downlink communications as the performance metricThe duty cycle is the sum of wake-up times used for beaconreception for possible poll transmission and for downlinkdata frame receptions Figure 11 shows the average duty cycleat different downlink traffic loadsThe duty cycle increases asthe downlink offered load increases it increases from 075to 11 as 120582119889 increases from 1 to 4 Note that all end-devicesconsume the minimal fixed duty cycle for beacon receptionregardless of the intensity of downlink traffic In addition tothe fixed duty cycle end-devices with backlogged downlinkscontinue to stay in the wake-up state for polling and datareception

Figure 12 illustrates the average latency of downlink trafficand uplink traffic as functions of offered load respectively Asshown in Figure 12(a) the average latency of downlink trafficincreases in proportion to the offered load As explained

0

02

04

06

08

1

12

Dut

y Cy

cle (

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

Figure 11 Duty cycles required for downlink operation includingbeacon poll and downlink data transmissions

before downlink frames are generated according to a Poissonprocess Therefore the probability that a downlink frameoccurs in a small time period follows uniform distributionand on average each downlink frame waits one-half of thebeacon interval In addition frames that arrive during adownlink processing are postponed to the next beacon InFigure 12(a) we can observe that the effect of uplink traffic onthe average latency of downlink is minimal This result is notsurprising because uplink and downlink communications arewell isolated in the proposed scheme

Like the average downlink latency the average uplinklatency increases as the downlink offered load increasesUplink frames that arrive during downlink periods shouldwait until the end of the current downlink periodThe averagelatency of uplink traffic as well as the duty cycle increase asthe downlink offered load increases Contrary to Figure 12(a)where the average downlink latency is seldom affected bythe uplink offered load the average uplink latency increasesproportionally as the uplink offered load increases As theuplink communication demands increase a queue startsto form and this causes the increase in waiting time Thequeueing time is most distinctive at 120582119889 = 4 when the servicetime for uplink communications is minimal

8 Simulation Results

We also compared the performance of the Class B downlinkscheme and that of TRILO Because commercial LoRaWANdevices do not support Class B functions yet we relied oncomputer simulations for the performance comparison Thesimulation code is written primarily in CC++ and we con-duct extensive simulations in a typical LoRaWAN networkand in a heavy downlink traffic condition respectively Tocompare energy consumed for downlink communicationswe define the efficiency of each protocol as a performancemetric The efficiency defined as the ratio of data transmis-sion time to the duty cycle is the fraction of time used foruseful work

12 Wireless Communications and Mobile Computing

Ｏ = 2

Ｏ = 8

70

75

80

85

90

95

100

105D

ownl

ink

Late

ncy

(sec

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

(a)

1

2

3

4

5

6

7

8

Upl

ink

Late

ncy

(sec

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

Ｏ = 2

Ｏ = 8

(b)

Figure 12 Average latency of traffic (a) Downlink latency (b) Uplink latency

Table 4 Notations used for Class B downlink protocol and TRILO

Notation Meaning119863119879 Duty cycle of TRILO119863119861 Duty cycle of the Class B downlink protocol119879119879119861119890119886119888119900119899 Beacon transmission time of TRILO

119879119861119861119890119886119888119900119899 Beacon transmission time of the Class B downlinkprotocol

119879119901119900119897119897 Average poll frame transmission time119879119889119900119908119899 Average downlink frame transmission time119896 Parameter for the Class Brsquos ping slots

119868119864 Indicator function representing a node is backlogged ornot

According to the LoRaWAN standard implementation ofthe Class B downlink scheme discretizes the time into so-called ping slots Each end-device requests 2119896 (0 le 119896 le 7)ping slots per beacon period We use the average case of theClass B where each end-device randomly selects a value ofthe parameter 119896 between 0 and 7 Let us first introduce thenotations for the analysis of LoRaWAN downlink protocol(Table 4)

We used SF 9 for beacon transmissions according to theLoRaWAN specification KR920-923 [29] The duty cycle ofTRILO119863119879 is

119863119879 =119879119879119861119890119886119888119900119899 + 119868119864 sdot (119879119901119900119897119897 + 119879119889119900119908119899)

119861119890119886119888119900119899 119875119890119903119894119900119889 (7)

Note that unlike 119879119861119861119890119886119888119900119899 119879119879119861119890119886119888119900119899 increases in proportion tothe number of busy end-devices The duty cycle of a Class Bdevice 119863119861 is

119863119861 = 119879119861119861119890119886119888119900119899 + 2119896 sdot 119879119889119900119908119899119861119890119886119888119900119899 119875119890119903119894119900119889 (8)

Class B devices have different duty cycles depending onrandomly selected values of parameter 119896 Then the efficiencyis computed as

119864119891119891119894119888119894119890119899119888119910 = 119863119900119908119899119897119894119899119896 119905119903119886119899119904119898119894119904119904119894119900119899 119905119894119898119890119863119906119905119910 119888119910119888119897119890119904 (9)

We measured the efficiency of TRILO and the Class Bdownlink protocol by varying the number of nodes from 50to 4000 and the downlink offered load from 2 to 32 framesper beacon period Each performance point is the average of10000 runs We limit the maximum downlink traffic to 32frames per beacon interval because uplink traffic is greaterthan downlink traffic in many LoRaWAN applications Notethat at 120582119889 = 32 about a half of beacon period is consumed fordownlink communications if we assume that the downlinktransmission time is 2 seconds on average

The efficiency of each scheme is shown in Figure 13Note that the offered load is aggregated load and the trafficintensity of individual node decreases as the number of nodesincreases The total times for downlink communications arefixed at each given offered load However the sum of dutycycles increases as the number of nodes increases Thereforein both protocols the maximum efficiencies are realized atsmall networks and the efficiency decreases as the networksize increases The results illustrate that efficiencies of TRILOare higher than those of the Class B downlink protocolthroughout all downlink generation ratesTheClass B schemeperforms well in heavy traffic cases However the proposedscheme outperforms the Class B scheme even in heavy trafficconditions In small networks the performance gap decreasesfrom about 139 times to about 33 times as 120582119889 increases from2 to 32 Also each gap in each offered load increases as thenetwork size increases In the case of TRILO the averageduty cycle decreases inversely proportional to the number ofnodes because only busy devices are active during downlink

Wireless Communications and Mobile Computing 13

Number of Nodes500 1000 1500 2000 2500 3000 3500 4000

10minus3

10minus2

Effici

ency

10minus1

100

101

Class B (＞ = 2)

Proposed (＞ = 2)

Class B (＞ = 8)

Proposed (＞ = 8)

Class B (＞ = 32)

Proposed (＞ = 32)

Figure 13 Efficiency of TRILO and Class B downlink protocol

periods On the contrary Class B protocol allocates 31 pingslots on average regardless of downlink demands In shortthe number of receive windows wasted by the Class B schemevaries depending on the amount of downlink traffic howeveronly busy devices use extra duty cycle for downlink traffic inTRILO

The Class B protocol does not coordinate traffic betweenuplinks and downlinks so that several uplinks can be dis-rupted by downlink transmissions due to the half-duplexcharacteristic of a LoRaWAN gateway all reception pathscan be blocked by downlink transmissions It can obstructthe proper operations of typical LoRaWANs where uplinktransmissions are predominant In contrast the proposedscheme is free from this problem because it isolates the timefor uplinks and downlinks periods

9 Conclusions

A plethora of LPWAN techniques such as LoRa SigFoxRPMA and Weightless have emerged as a new enablingnetwork technology for IoT applications that require low-rate low-cost and long lifetimes LPWANs allow end-deviceinitiated uplinks However to maximize the lifetime ofbattery powered end-devices nodes are put into the sleepstate such that rather restricted downlink communicationsare permitted In this paper we proposed a new downlinkprotocol named TRILO for LoRaWAN

Because LoRaWAN assumes a star topology where mul-tiple end-devices are connected to a single gateway weadopted a beacon based downlink mechanism similar to theIEEE 80211 PSM standard A gateway broadcast beaconsperiodically at every beacon period and end-devices are timesynchronized Beacons alert nodes with buffered downlinksin addition to synchronizing end-devicesrsquo clocks Customizedto the physical characteristics of LoRa we designed two

polling schemes concurrent polling and sequential pollingAn analysis indicates that sequential polling is more energyefficient than concurrent polling

We implement the proposed beacon based downlinkprotocol using commercially available components and con-duct experiments with modified devices Our performancestudy shows that Packet Delivery Ratio (PDR) is almost100 for both uplink and downlink traffic and the extrawake-up time to receive beacons and downlinks is minimalSimulation results also show that our proposed protocol canadaptively allocate receive windows resulting in lower energyconsumption

For further work we plan to investigate the impact ofour scheme on the networks with multiple gateways Alsodetailed investigations of impact of the number of downlinksand the certain distributions of SFs on the performanceseem interesting Optimization techniques leveraging SF andpower allocation are expected to affect the performance of theproposed scheme

Data Availability

The data used to support the findings of this study areincluded within the article

Disclosure

The funding sponsors had no role in the study in thecollection analyses or interpretation of data in the writingof the manuscript and in the decision to publish the results

Conflicts of Interest

The authors declare that there are no conflicts of interestregarding the publication of this paper

14 Wireless Communications and Mobile Computing

Acknowledgments

This work was supported by the National Research Founda-tion of Korea (NRF) Grant funded by the Korean Govern-ment (MSIP) (No 2016R1A5A1012966) Institute for Infor-mation amp Communications Technology Promotion (IITP)grant funded by the Korea government (MSIT) (No 2015-0-00557 ResilientFault-Tolerant Autonomic NetworkingBased on Physicality Relationship and Service Semantic ofIoT Devices) and the MSIP (Ministry of Science ICT andFuture Planning) Korea under the ITRC (Information Tech-nology Research Center) support program (IITP-2018-2015-0-00378) supervised by the IITP (Institute for Informationamp Communications Technology Promotion) Also the snu-samsung smart campus research center at Seoul NationalUniversity provides research facilities for this study

References

[1] M Bor U Roedig T Voigt and J M Alonso ldquoDo LoRalow-power wide-area networks scalerdquo in Proceedings of the19th ACM International Conference on Modeling Analysis andSimulation of Wireless and Mobile Systems MSWiM 2016 pp59ndash67 Malta November 2016

[2] DMagrinMCentenaro andLVangelista ldquoPerformance eval-uation of LoRa networks in a smart city scenariordquo inProceedingsof the 2017 IEEE International Conference on CommunicationsICC 2017 France May 2017

[3] LoRa httpswwwlora-allianceorgWhat-Is-LoRaTechnol-ogy

[4] ldquoLoRaWAN 11 specificationrdquo LoRa Alliance 2017 httpslora-allianceorgresource-hublorawantm-specification-v11

[5] M Bor J Vidler and U Roedig ldquoLoRa for the internet ofthingsrdquo in Proceedings of the International Conference onEmbedded Wireless Systems and Networks (EWSN rsquo16) pp 361ndash366 Junction Publishing 2016

[6] 3GPP ldquoStudy on provision of low-cost Machine-Type Commu-nications User Equipments based on LTErdquo TR 36888 V120006 2013

[7] 3GPP ldquoCellular system support for ultra-low complexity andlow throughput Internet of Thingsrdquo TR 45820 V1310 11 2015

[8] J Gozalvez ldquoNew 3GPP Standard for IoTrdquo IEEE VehicularTechnology Magazine vol 11 no 1 pp 14ndash20 2016

[9] R Ratasuk N Mangalvedhe and A Ghosh ldquoOverview ofLTE enhancements for cellular IoTrdquo in Proceedings of the 26thIEEE Annual International Symposium on Personal Indoor andMobile Radio Communications PIMRC 2015 pp 2293ndash2297China September 2015

[10] H Shariatmadari R Ratasuk S Iraji et al ldquoMachine-type com-munications current status and future perspectives toward 5Gsystemsrdquo IEEE CommunicationsMagazine vol 53 no 9 pp 10ndash17 2015

[11] S Landstrom J Bergstrom E Westerberg and D Hammar-wall ldquoNBIoT a sustainable technology for connecting billionsof devicesrdquo Ericsson Technology Review vol 4 pp 2ndash11 2016

[12] M Lauridsen I Z Kovacs P Mogensen M Sorensen andS Holst ldquoCoverage and capacity analysis of LTE-M and NB-IoT in a rural areardquo in Proceedings of the 2016 IEEE 84thVehicular Technology Conference (VTC-Fall) pp 1ndash5 MontrealQC Canada September 2016

[13] Sigfox httpwwwsigfoxcom[14] Weightless open standard httpwwwweightlessorg[15] Ingenu RPMA httpwwwingenucomtechnologyrpma[16] A Dunkels ldquoThe ContikiMAC radio duty cycling protocolrdquo

Technical Report T201113 Swedish Institute of ComputerScience 2011

[17] J Ko J Eriksson N Tsiftes et al ldquoIndustry Beyond interoper-ability - Pushing the performance of sensor network IP stacksrdquoin Proceedings of the 9th ACM Conference on Embedded Net-worked Sensor Systems SenSys 2011 pp 1ndash11 USA November2011

[18] D Moss J Hui and K Klues ldquoTEP 105 low power listeningrdquohttpwwwtinyosnettinyos-2xdocpdftep105pdf 2008

[19] C Gomez J Oller and J Paradells ldquoOverview and evaluationof bluetooth low energy an emerging low-power wirelesstechnologyrdquo Sensors vol 12 no 9 pp 11734ndash11753 2012

[20] A A Kandhalu A E Xhafa and S Hosur ldquoTowards bounded-latency bluetooth low energy for in-vehicle network cablereplacementrdquo in Proceeding of the International Conference onConnected Vehicles and Expo (ICCVE) pp 635ndash640 Las VegasNV USA 2013

[21] A Montanari S Nawaz C Mascolo and K Sailer ldquoA studyof bluetooth low energy performance for human proximitydetection in the workplacerdquo in Proceedings of the 2017 IEEEInternational Conference on Pervasive Computing and Commu-nications PerCom 2017 pp 90ndash99 Kona HI USA March 2017

[22] C Julien C Liu A L Murphy and G P Picco ldquoBLEnd Practi-cal continuous neighbor discovery for bluetooth low energyrdquo inProceedings of the 16th ACMIEEE International Conference onInformation Processing in Sensor Networks IPSN 2017 pp 105ndash116 New York NY USA April 2017

[23] Y Qiu S Li X Xu and Z Li ldquoTalk more listen less energy-efficient neighbor discovery in wireless sensor networksrdquo inProceedings of the 35th Annual IEEE International Conference onComputer Communications IEEE INFOCOM 2016 USA April2016

[24] A J Berni andW D Gregg ldquoOn the utility of chirpmodulationfor digital signalingrdquo IEEE Transactions on Communicationsvol 21 no 6 pp 748ndash751 1973

[25] A Springer W Gugler M Huemer L Reindl C C W Ruppeland R Weigel ldquoSpread spectrum communications using chirpsignalsrdquo in Proceedings of the IEEEAFCEA Information Systemsfor Enhanced Public Safety and Security EUROCOMM2000 pp166ndash170 Germany

[26] IEEE Std 80211-2007 ldquoIEEE Standard for Information Tech-nologymdashTelecommunications and Information Exchange be-tween SystemsmdashLocal and Metropolitan Area NetworksmdashSpecific Requirements Part 11 Wireless LAN Medium AccessControl (MAC) and Physical Layer (PHY) Specifications June2007rdquo

[27] RAK831 httpwwwrakwirelesscomenWisKeyOSHRAK831[28] LoRaWAN network server httpsgithubcomgotthardplor-

awan-server[29] ldquoLoRaWAN 11 Regional Parametersrdquo LoRa Alliance 2017

httpslora-allianceorgresource-hublorawantm-regional-pa-rameters-v11ra

Wireless Communications and Mobile Computing 5

Gateway

End-device

Time

Uplink RX1 RX2

RECEIVE_DELAY2

RECEIVE_DELAY1

Downlink

Figure 2 Class A end-device initiated uplink and responding downlinks

Gateway

End-device

Time

4

Beacon_Window

Beacon_Guard Beacon_Reserved

Beacon_Period

7 265 516

Beacon

Ping slots for node X

Ping slots for node Y

Figure 3 Beacon based Class B downlink scheme

with predetermined receive windows Class A end-nodessacrifice asynchronous downlink transmissions but attainlong lifetimes as a reward It is expected that battery poweredClass A end-devices enjoy ten to twenty years of lifetimes inreasonable use cases Class A is suitable for sensor nodes thatreport sensing data periodically or when the readings satisfypredetermined criteria

Unlike a Class A end-device Class B and C devices sup-port downlink communications A Class C end-device oper-ates in an always-on mode and wastes significant amountsof energy for idle listening required for the receptions ofasynchronous downlinks Class B end-devicesmdashbidirectionalend-devices with scheduled receive slotsmdashsupport syn-chronous server-initiated downlinks Class B end-devicesmust be time synchronized with the gateway which transmitsbeacons at every beacon period of 128 seconds Once beingsynchronized Class B end-devices wake up at each beaconperiod to maintain the synchronization LoRa discretizes thetime into so-called ping slots each of which is 30 mSec longOne beacon period contains 4096 ping slots and a devicecan request 2119896 (0 le 119896 le 7) ping slots per beacon periodThe first ping slot position is determined randomly and p-th ping slot starts at 119905119861119864119860119862119874119873 119877119864119878119864119877119881119864119863 + (1199030 + (119901 minus 1) ∙212minus119896) ∙ 30 where 119905119861119864119860119862119874119873 119877119864119878119864119877119881119864119863 is the time when theBEACON RESERVED finishes 1199030 is the first offset randomlyselected Figure 3 shows the beacon timing and an example

of Class B end-devicesrsquo ping slot schedules (nodes X and Y)whose parameters are 119896 = 3 and 1199030 = 4 and 119896 = 4 and 1199030 = 7respectively

The downlink protocol for Class B end-devices incurssignificant overheads In addition to beacons they mustblindly wake up at their reserved ping slots regularly eventhough there are no buffered frames for them Also devicesconsume energy to maintain a precise clock to catch theinterrupts during ping slots We design and implement a newdownlink scheme to reduce such overheads

4 Downlink Communications Scheme

There can be many alternative methods for downlink trans-missions One simple method is to utilize the Class A uplink-downlink transaction an end-device periodically transmitsprobe messages to the server and if there is a downlinkmessage for the device the server sends it as a responseto the uplink probe This method is effective and energyefficient if end-devices can guess the existence of downlinkmessages correctly However exact prediction of downlinksis practically impossible Because end-devices cannot predictwhen downlink packets are ready they can issue either toomany unnecessary probes when the probing interval is shortor suffer from long latencies when the probing interval islong

6 Wireless Communications and Mobile Computing

Preamble PHDR

MHDR MACPayload MIC

1

1

1 25 4

4

TimeStamp DevAddr

PHYPayloadPHDR_CRC

(a)

Preamble PHDR_CRCPHDR PHYPayload CRC

MHDR DevAddr MIC

1 44

(b)

Figure 4 Beacon and poll message formats (a) Beacon (b) Poll

Broadcasting is an effective mechanism to disseminatecontrol information in a network that supports one to manycommunications Indeed IEEE 80211 WLANs [26]mdashwherean AP and multiple stations form a one to many networkmdashadopt the periodic broadcast scheme to alert backloggedmobile stations in the Power Saving Mode (PSM) A WLANAPperiodically (usually every 100mSec) broadcasts a beaconmessage that contains Traffic Indication Map (TIM) A TIMenumerates mobile stations that have buffered downlinkpackets Stations in the sleep mode wake up periodically atevery beacon interval to listen TIMs Backlogged stationsthen send PS-Poll frames requesting downlink packet trans-missions As soon as a station receives a buffered frame itfalls back to the sleep mode until the next beacon Stationswithout buffered downlink frames immediately return to thesleep state to minimize energy consumption

Because a LoRaWAN forms a star (more precisely astar-of-stars topology) and supports broadcasting like IEEE80211 WLAN it is natural to adopt a downlink mechanismsimilar to the IEEE 80211 PSM In addition as explained inthe previous section on LoRaWAN primer the LoRaWANstandard already supports a beacon mechanism for timesynchronization We can easily modify the structure of aLoRaWANrsquos beacon frame to augment a field that specifiesbacklogged end-devices This additional field is similar tothe TIM field of the WLAN The message formats of beaconand poll frames are shown in Figure 4 Compared to beacontransmission polling mechanisms for LoRaWAN ask for acareful design because the MAC protocols in LoRaWAN arepractically limited to the unslotted Aloha scheme Given thatcarrier sensing is prohibited a beacon triggers synchronizedmedium access from backlogged end-devices and causesexcessive collisions On the other hand a LoRaWAN is robustagainst collisions because it supports multiple simultaneousreceptions of different SFs and different subbands In shortbecause polling can affect the performance of overall systems

significantly it is worthwhile to carefully analyse all aspectsthat may affect the performance

We consider two polling mechanisms concurrent pollingand sequential polling Before delving into the details ofpolling schemes let us first introduce the notations used forthe following analysis (Table 2)

Concurrent polling is designed to best exploit the char-acteristics of the LoRarsquos PHY layer Note that a gatewaycan receive multiple signals simultaneously if their channelsor SFs are different Commercially available gateways sup-port concurrent demodulation up to 8 signals however letus assume that the number of simultaneous receptions isincreased multiplicatively by deploying multiple gatewaysFor example if a LoRa network uses 10 channels and 6different SFs as in Europe then the maximum of 60 pollscan be delivered simultaneously when more than or equalto 8 gateways are deployed Let busy and idle devices beend-devices with and without pending downlink framesrespectively Hearing a beacon all busy end-devices transmitpolls to the server simultaneously as shown in Figure 5(a)Polls that are in the same subchannel and of the same SF willexperience collisions and will be lost For example polls fromdevices 1198641 1198642 119886119899119889 1198643 are transmitted successfully How-ever polls from devices 1198644 119886119899119889 1198645 will collide and will belost

Let n andmbe the number of themaximumsimultaneousframes that the network allows and the number of framesthat arrive during a beacon period (ie the number ofpolls assuming that there is at most one frame per end-device) The expected number of successful polls is m ∙119890minus119898119899 approximately Because collided polls will competeagain at the next beacon interval the actual number of pollscompeting at each beacon is approximated as1198981015840 = 119898+119898(1minus119890minus119898119899)

Idle devices fall back to the sleep state as soon as theyrecognize there are no frames for them The maximum

Wireless Communications and Mobile Computing 7

Table 2 Notations

Notation Meaning

119863119887 Size of a beacon except preamble the minimum size is 17+4∙ m bytes where m is the number of end-devices with buffereddownlinks

119863119901 Size of a poll frame except preamble The minimum size can be 4119863119889 Average size of a downlink frame except preamble119905119888 Time to compensate clock drift According to the LoRaWAN standard it is set to 13 mSec119905119892 Time gap between two consecutive frames during downlink operation Frames include poll and data119903119887 Beacon broadcasting data rateThe standard specifies using SF=12 and the data rate is 250 bps119903119901 Average poll frame transmission data rate119903119889 Average downlink frame transmission data rate

GatewayTime

Channel=3 SF=7

Channel=3 SF=10

Channel=2 SF=7

Channel=4 SF=10

Channel=4 SF=10

E1

E2

E3

E4

E5

(a)

GatewayTime

Channel=3 SF=7

Channel=3 SF=10

Channel=2 SF=7

Channel=4 SF=10

Channel=4 SF=10

E1

E2

E3

E4

E5

(b)

Figure 5 Example of polling mechanisms (a) Concurrent polling (b) Sequential polling

wake-up time of an idle device during a beacon period 119882119862119868 is computed as follows

119882119862119868 = 119905119888 + 119863119887119903119887 (1)

A busy end-device transmits a poll and waits until it receivesits downlink As soon as it receives the downlink it turnsits radio off until the next beacon Because the gatewaytransmits downlinks only to the end-devices whose polls aresuccessfully received on the average 1198981015840 ∙ 119890minus1198981015840119899 downlinkframes will be transmitted The average maximum wake-uptime of a busy device whose poll is delivered successfully tothe gateway is

119882119862119861119878 = 119905119888 + 119863119887119903119887 + 119863119901

119903119901 + 12 ∙ (119905119892 + 119863119889

119903119889 ) ∙ 1198981015840 ∙ 119890minus1198981015840119899 (2)

A busy device whose poll fails to reach to the gateway mustwait until all downlink transmissions are completed and itswake-up time is

119882119862119861119865 = 119905119888 + 119863119887119903119887 + 119863119901

119903119901 + (119905119892 + 119863119889119903119889 ) ∙ 1198981015840 ∙ 119890minus1198981015840119899 (3)

Under a simple assumption that all end-devices are equallyprobable to have a pending downlink frame the sumof wake-up times of all M devices under the synchronous pollingscheme is

(119872 minus 1198981015840) ∙ 119882119862119868 + 1198981015840 ∙ 119890minus1198981015840119899 ∙ 119882119862119861119878 + 1198981015840

∙ (1 minus 119890minus1198981015840119899) ∙ 119882119862119861119865(4)

The average time that a node should turn on its batteryto receive a downlink is derived by dividing (4) by themultiplication of M and the average number of successfuldownlinks per beacon period

Another scheme that we have considered is sequentialpolling Unlike the contention based concurrent polling end-devices poll and receive downlink in the same order that theiraddresses appeared in the DevAddr fields of a beacon frameFigure 5(b) shows an example of sequential polling Receivinga beacon busy devices remember their positions in theDevAddr field and all devices except the first busy device fallback to the sleep state The first busy device transmits a polland receives a downlink frameThe second busy device wakes

8 Wireless Communications and Mobile Computing

Concurrent n = 8Concurrent n = 16Sequential

8 162 1 4 Offered Load

0

50

100

150

200

250

300

350

400

450

500W

ake-

up ti

me (

mse

c)

(a)

Concurrent n = 8Concurrent n = 16Sequential

8 162 1 4 Offered Load

0

5

10

15

Wak

e-up

tim

e (m

sec)

(b)

Figure 6 Performance of concurrent polling and sequential polling (a) Average wake-up time of both idle and busy devices (b) Averagewake-up time of busy devices

up after one poll-data frame exchange time to poll and receiveits downlinkThe sameprocedure repeats for succeeding busydevices Equation (5) is the average maximum wake-up timeof a busy device

119882119878119861 = 119905119888 + 119863119887119903119887 + 119863119901

119903119901 + (119905119892 + 119863119889119903119889 ) (5)

Moreover the sum of all wake-up times during a beaconperiod is

(M minus m) ∙ 119882119878119868 + 119898 ∙ 119882119878119861 (6)

5 Comparison of Two Polling Schemes

We compared the two polling methods by varying the valuesof parameters that may affect performance The performancemetric is the average wake-up time required for the receptionof one downlink frame We varied the total number of end-devices (M) in a network the number of downlink messagesper beacon interval and the network capacity for concurrenttransmissions (n) Figure 6 shows the average wake-up timesof concurrent and sequential polling as functions of theoffered loadThe unit of the offered load is the number of newdownlink frames generated per beacon interval Figures 6(a)and 6(b) are the wake-up time of all end-devices includingboth idle and busy devices and the wake-up time of busydevices only respectively When calculating the wake up timeof busy devices only terms (119872minus1198981015840)∙119882119862119868 and (Mminusm)∙119882119878119868 in(4) and (6) are excluded We used two values (n=8 and n=16)of network capacity to analyse the effect of maximum simul-taneous receptions For simplicity we assume that receptionpaths of gateways are ideally utilized as each gateway does notlock on the same packet In both Figures 6(a) and 6(b) we

can observe that sequential polling is more effective in powerconserving than concurrent polling When the offered load issmall the performance differences are not great However asthe offered load increases the gap increases also and at m=16concurrent polling consumes 3 to 22 times more energy thansequential polling in the case of all devices (Figure 6(a))Moreover in the case of busy devices only (Figure 6(b))concurrent polling consumes 55 to 41 times more energythan sequential polling The number of total end-devices isfixed at 1000We performed the same analysis by varying thevalue of M and obtain the similar results

We also can observe that concurrent polling at n=16 isbetter than that at n=8 As n increases the probability of colli-sion decreases Collisions affect the performance in twowaysA device whose poll fails to reach a gateway wastes energybecause it should wait until all downlinks are completedAlso collisions increase the offered load at the followingbeacon period and an inflated load again increases the col-lision probability Generally the wake-up time of all devicesdecreases as the offered load increases up to 4 (Figure 6(a))However as the offered load exceeds network capacity (n)wake-up time increases sharply

Because our analytic study reveals the performance ad-vantage of sequential polling over concurrent polling weadopt sequential polling for our downlink communicationscheme Figure 7 illustrates TRILO in a greater detailBeacon Window is divided into downlink reception timeand uplink transmission time After a beacon busy devicesreceive downlink frames sequentially during downlink timeAfter that nodes transmit uplink messages like plain ClassA devices One problem is that uplink transmissions orthe downlinks responding to uplinks may overlap with thefollowing beacon To avoid the problem the Beacon Guardis introduced end-devices refrain from initiating new uplink

Wireless Communications and Mobile Computing 9

Gateway

End-device A

Time

Beacon period

Beacon

poll

End-device B

downlink

uplink

Downlink Uplink

Beacon window

Figure 7 Proposed downlink communication scheme

(a) (b)

Figure 8 Devices used for implementation (a) End-device with SX1272MB2DAS attached to a NUCLEO-L073RZ board (b) Gateway withRAK831 attached to a Raspberry Pi 3

transmissions if remaining time to the next beacon is lessthan Beacon Guard Note that LoRaWAN standard limitsmaximum payload size so that beacon payload cannotconvey a large number of DevAddrs however it can be easilyextended depending on network conditions by using low SFsor allocating short network addresses

6 Implementation

We implemented TRILO using commercially available com-ponents We built a gateway on a RAK831 board [27] whichcontains an SX1301 concentrator chip The gateway board isattached to a Raspberry Pi 3 board as shown in Figure 8(b)For our implementation we employed the Semtech librarieswhich contain LoRaWAN packet forwarder and hardwareabstraction layer for SX1301

In the LoRaWAN architecture a gateway plays a simplerole of a bridge between end-devices and a network serverand a network server performs all beacon and poll messageprocessings We utilize an open source project [28] targetedfor private LoRaWAN network production in implementinga network server Figure 9 describes the message handlermodules that we implemented The beacon handler creates

a beacon payload consisting of the timestamp and buffereddownlink frame information Then it passes the payload tothe packet processor which assembles the payload into abeacon packet Since a beacon needs to be transmitted ina greater time precision than data packets we modified thegateway such that beacons are transmitted immediately Thepoll handler sends a pending downlink frame in responseto a poll message Note that this mechanism is transparentto the LoRaWAN MAC processor and the application serverbecause we implement modules at the packet processor level

An end-device is implemented on a NUCLEO-L073RZboard with an embedded LoRaWAN chip using a 915Mhzantenna (see Figure 8(a)) We attached the SX1272MB2DAScomponent to a NUCLEO-L073RZ board with the modifiedLoRa MAC Note that end-device logics are compiled andstored as firmware in an end-device Time synchronizationbetween nodes and a network server is based on the localtime of a network server instead of GPS time because weimplemented the beacon handler at the server not using thebeacon frame of the Class B standard We modified the end-devicersquos software by adding the beacon handling and pollingfunctions Note that each device which has a pending framewaits for its turn and processing times of each downlink vary

10 Wireless Communications and Mobile Computing

Packet forwarderGateway Packet

processorLoRaWAN

MAC processor

Applicationserver

PUSH DATA

PULL RESP

Pollhandler

Beaconhandler

Figure 9 Block diagram of a network server that handles beacon and poll messages

Figure 10 Experiment environment One gateway (yellow dot) and 15 end-devices (blue dots) are deployed in our office building

due to different SFs In a downlink period we configuredthe time for each poll and downlink based on SF 12 whichhas the longest airtime However the experimental resultsshow that the proposed scheme can be deployed with highperformance even with the conservative configuration It ispossible to optimize the waiting times for each downlinkmore compactly based on the information about SFs of eachnode however we leave this issue as future work

We tuned radios of the components to obey the Koreanregulation which allocates frequency bands from 920Mhzto 923Mhz for LoRaWAN We also added the listen beforetalk (LBT) function as the regulation specifies Note thatthe current LoRaWAN specifications for the KR920-923 ISMband do not have duty cycle limits but require adopting theLBT channel access rule [4]

7 Experimental Results

We evaluate the performance of TRILO by deploying modi-fied components in our office buildingWeplaced the gatewayand three end-devices in our lab Also we deploy 12 moreend-devices on the same floor of the building as shown inFigure 10 The beacon periods are set to either 128 sec or256 sec We varied the uplink and downlink offered loadsfrom 1 2 4 to 8 frames per beacon period The offered trafficis unrealistically large for such a small network however notethat we are trying to emulate the operating conditions of large

scale LoRAWAN networks consisting of tens of thousandsof end-devices Testbeds of such scale are not available soour experiment emulates large networks with 15 end-devicesUplink and downlink messages should be interpreted as anaggregated traffic generated by thousands of end-devicesMessage interarrival times of uplink and downlink trafficfollow the exponential distribution and the destinations ofdownlink messages are randomly and uniformly selectedWe used primitive Adaptive Data Rate (ADR) for SF andpower allocation and all nodes converged to SF 8 and defaultEIRP output power (14dBm) The performance of real-worldLoRaWAN networks depends on the distributions of SFand transmission power However we ignore these factorsbecause improvement of uplink transmissions is not a goalof this work

The performance metrics used in this study includePacket Delivery Ratio (PDR) duty cycle and latency Toobtain reliable results we repeat experiments with the sameparameter values ten times The length of each experimentrun is 10 beacon periods (ie 1280 or 2560 sec) Becausethe destinations of downlinks and the origins of uplinks arerandomly selected it is expected that all end-devices andmessages experience the average performance

First of all we measure the PDR of uplink and downlinkframes We observe that all downlink frames are deliveredsuccessfully without exception The result is rather surprisingbecause TRILO employs beacon broadcasting and polling

Wireless Communications and Mobile Computing 11

Table 3 Packet delivery ratio of uplink traffic at various uplink anddownlink offered loads

Packet generation rate 120582119889 = 1 120582119889 = 2 120582119889 = 4120582119906 = 2 9864 9827 9772120582119906 = 8 9674 9603 9510

in addition to downlink data frames A failure in any onecomponent may lead to unsuccessful data transmissionsUnlike downlink frames uplink traffic experiences occa-sional transmission failures Wemeasure the PDR by varyingthe offered loads of both uplink and downlink traffic Notethat all nodes use the same SF and collisions occur if framesare transmitted on the same channel simultaneously Table 3illustrates the PDR of uplink traffic at different offered loadsBoth uplink and downlink traffic affect the PDR of uplinktraffic The PDR decreases as the offered load of downlinktraffic increases at 120582119906 = 2 the PDR decreases from 9864to 9772 as the offered load of downlink traffic increasesfrom 1 to 4 In addition the uplink traffic intensity also affectsthe PDR of uplink traffic for example at 120582119889 = 2 the PDRdecreases from 9827 to 9603 as the offered load of uplinktraffic increases from 2 to 8

Note that uplink transmissions are prohibited duringpolling and following downlink frame transmissions Uplinkframes which arrive during downlink operation should waituntil the current downlink operation is completed Thiswaiting procedure synchronizes backlogged end-devices andmay cause collisions Even though the LoRa PHY supportsmultiple simultaneous transmissions of different SFs or chan-nels multiple attempts increase the collision probabilitiesand the PDR decreases as both uplink and downlink trafficincrease To reduce the bloated collisions due to synchronoustransmissions persistent mechanisms such as 0-persistenceor p-persistence are required However persistence schemesincrease the complexity of the network protocol and maycause other side effects such as increased energy consump-tion

Next we assess the additional power consumed fordownlink communications Because gateways operate in analways-on mode we only measure the energy consumed byend-devices We use the duty cycle additional time requiredfor downlink communications as the performance metricThe duty cycle is the sum of wake-up times used for beaconreception for possible poll transmission and for downlinkdata frame receptions Figure 11 shows the average duty cycleat different downlink traffic loadsThe duty cycle increases asthe downlink offered load increases it increases from 075to 11 as 120582119889 increases from 1 to 4 Note that all end-devicesconsume the minimal fixed duty cycle for beacon receptionregardless of the intensity of downlink traffic In addition tothe fixed duty cycle end-devices with backlogged downlinkscontinue to stay in the wake-up state for polling and datareception

Figure 12 illustrates the average latency of downlink trafficand uplink traffic as functions of offered load respectively Asshown in Figure 12(a) the average latency of downlink trafficincreases in proportion to the offered load As explained

0

02

04

06

08

1

12

Dut

y Cy

cle (

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

Figure 11 Duty cycles required for downlink operation includingbeacon poll and downlink data transmissions

before downlink frames are generated according to a Poissonprocess Therefore the probability that a downlink frameoccurs in a small time period follows uniform distributionand on average each downlink frame waits one-half of thebeacon interval In addition frames that arrive during adownlink processing are postponed to the next beacon InFigure 12(a) we can observe that the effect of uplink traffic onthe average latency of downlink is minimal This result is notsurprising because uplink and downlink communications arewell isolated in the proposed scheme

Like the average downlink latency the average uplinklatency increases as the downlink offered load increasesUplink frames that arrive during downlink periods shouldwait until the end of the current downlink periodThe averagelatency of uplink traffic as well as the duty cycle increase asthe downlink offered load increases Contrary to Figure 12(a)where the average downlink latency is seldom affected bythe uplink offered load the average uplink latency increasesproportionally as the uplink offered load increases As theuplink communication demands increase a queue startsto form and this causes the increase in waiting time Thequeueing time is most distinctive at 120582119889 = 4 when the servicetime for uplink communications is minimal

8 Simulation Results

We also compared the performance of the Class B downlinkscheme and that of TRILO Because commercial LoRaWANdevices do not support Class B functions yet we relied oncomputer simulations for the performance comparison Thesimulation code is written primarily in CC++ and we con-duct extensive simulations in a typical LoRaWAN networkand in a heavy downlink traffic condition respectively Tocompare energy consumed for downlink communicationswe define the efficiency of each protocol as a performancemetric The efficiency defined as the ratio of data transmis-sion time to the duty cycle is the fraction of time used foruseful work

12 Wireless Communications and Mobile Computing

Ｏ = 2

Ｏ = 8

70

75

80

85

90

95

100

105D

ownl

ink

Late

ncy

(sec

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

(a)

1

2

3

4

5

6

7

8

Upl

ink

Late

ncy

(sec

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

Ｏ = 2

Ｏ = 8

(b)

Figure 12 Average latency of traffic (a) Downlink latency (b) Uplink latency

Table 4 Notations used for Class B downlink protocol and TRILO

Notation Meaning119863119879 Duty cycle of TRILO119863119861 Duty cycle of the Class B downlink protocol119879119879119861119890119886119888119900119899 Beacon transmission time of TRILO

119879119861119861119890119886119888119900119899 Beacon transmission time of the Class B downlinkprotocol

119879119901119900119897119897 Average poll frame transmission time119879119889119900119908119899 Average downlink frame transmission time119896 Parameter for the Class Brsquos ping slots

119868119864 Indicator function representing a node is backlogged ornot

According to the LoRaWAN standard implementation ofthe Class B downlink scheme discretizes the time into so-called ping slots Each end-device requests 2119896 (0 le 119896 le 7)ping slots per beacon period We use the average case of theClass B where each end-device randomly selects a value ofthe parameter 119896 between 0 and 7 Let us first introduce thenotations for the analysis of LoRaWAN downlink protocol(Table 4)

We used SF 9 for beacon transmissions according to theLoRaWAN specification KR920-923 [29] The duty cycle ofTRILO119863119879 is

119863119879 =119879119879119861119890119886119888119900119899 + 119868119864 sdot (119879119901119900119897119897 + 119879119889119900119908119899)

119861119890119886119888119900119899 119875119890119903119894119900119889 (7)

Note that unlike 119879119861119861119890119886119888119900119899 119879119879119861119890119886119888119900119899 increases in proportion tothe number of busy end-devices The duty cycle of a Class Bdevice 119863119861 is

119863119861 = 119879119861119861119890119886119888119900119899 + 2119896 sdot 119879119889119900119908119899119861119890119886119888119900119899 119875119890119903119894119900119889 (8)

Class B devices have different duty cycles depending onrandomly selected values of parameter 119896 Then the efficiencyis computed as

119864119891119891119894119888119894119890119899119888119910 = 119863119900119908119899119897119894119899119896 119905119903119886119899119904119898119894119904119904119894119900119899 119905119894119898119890119863119906119905119910 119888119910119888119897119890119904 (9)

We measured the efficiency of TRILO and the Class Bdownlink protocol by varying the number of nodes from 50to 4000 and the downlink offered load from 2 to 32 framesper beacon period Each performance point is the average of10000 runs We limit the maximum downlink traffic to 32frames per beacon interval because uplink traffic is greaterthan downlink traffic in many LoRaWAN applications Notethat at 120582119889 = 32 about a half of beacon period is consumed fordownlink communications if we assume that the downlinktransmission time is 2 seconds on average

The efficiency of each scheme is shown in Figure 13Note that the offered load is aggregated load and the trafficintensity of individual node decreases as the number of nodesincreases The total times for downlink communications arefixed at each given offered load However the sum of dutycycles increases as the number of nodes increases Thereforein both protocols the maximum efficiencies are realized atsmall networks and the efficiency decreases as the networksize increases The results illustrate that efficiencies of TRILOare higher than those of the Class B downlink protocolthroughout all downlink generation ratesTheClass B schemeperforms well in heavy traffic cases However the proposedscheme outperforms the Class B scheme even in heavy trafficconditions In small networks the performance gap decreasesfrom about 139 times to about 33 times as 120582119889 increases from2 to 32 Also each gap in each offered load increases as thenetwork size increases In the case of TRILO the averageduty cycle decreases inversely proportional to the number ofnodes because only busy devices are active during downlink

Wireless Communications and Mobile Computing 13

Number of Nodes500 1000 1500 2000 2500 3000 3500 4000

10minus3

10minus2

Effici

ency

10minus1

100

101

Class B (＞ = 2)

Proposed (＞ = 2)

Class B (＞ = 8)

Proposed (＞ = 8)

Class B (＞ = 32)

Proposed (＞ = 32)

Figure 13 Efficiency of TRILO and Class B downlink protocol

periods On the contrary Class B protocol allocates 31 pingslots on average regardless of downlink demands In shortthe number of receive windows wasted by the Class B schemevaries depending on the amount of downlink traffic howeveronly busy devices use extra duty cycle for downlink traffic inTRILO

The Class B protocol does not coordinate traffic betweenuplinks and downlinks so that several uplinks can be dis-rupted by downlink transmissions due to the half-duplexcharacteristic of a LoRaWAN gateway all reception pathscan be blocked by downlink transmissions It can obstructthe proper operations of typical LoRaWANs where uplinktransmissions are predominant In contrast the proposedscheme is free from this problem because it isolates the timefor uplinks and downlinks periods

9 Conclusions

A plethora of LPWAN techniques such as LoRa SigFoxRPMA and Weightless have emerged as a new enablingnetwork technology for IoT applications that require low-rate low-cost and long lifetimes LPWANs allow end-deviceinitiated uplinks However to maximize the lifetime ofbattery powered end-devices nodes are put into the sleepstate such that rather restricted downlink communicationsare permitted In this paper we proposed a new downlinkprotocol named TRILO for LoRaWAN

Because LoRaWAN assumes a star topology where mul-tiple end-devices are connected to a single gateway weadopted a beacon based downlink mechanism similar to theIEEE 80211 PSM standard A gateway broadcast beaconsperiodically at every beacon period and end-devices are timesynchronized Beacons alert nodes with buffered downlinksin addition to synchronizing end-devicesrsquo clocks Customizedto the physical characteristics of LoRa we designed two

polling schemes concurrent polling and sequential pollingAn analysis indicates that sequential polling is more energyefficient than concurrent polling

We implement the proposed beacon based downlinkprotocol using commercially available components and con-duct experiments with modified devices Our performancestudy shows that Packet Delivery Ratio (PDR) is almost100 for both uplink and downlink traffic and the extrawake-up time to receive beacons and downlinks is minimalSimulation results also show that our proposed protocol canadaptively allocate receive windows resulting in lower energyconsumption

For further work we plan to investigate the impact ofour scheme on the networks with multiple gateways Alsodetailed investigations of impact of the number of downlinksand the certain distributions of SFs on the performanceseem interesting Optimization techniques leveraging SF andpower allocation are expected to affect the performance of theproposed scheme

Data Availability

The data used to support the findings of this study areincluded within the article

Disclosure

The funding sponsors had no role in the study in thecollection analyses or interpretation of data in the writingof the manuscript and in the decision to publish the results

Conflicts of Interest

The authors declare that there are no conflicts of interestregarding the publication of this paper

14 Wireless Communications and Mobile Computing

Acknowledgments

This work was supported by the National Research Founda-tion of Korea (NRF) Grant funded by the Korean Govern-ment (MSIP) (No 2016R1A5A1012966) Institute for Infor-mation amp Communications Technology Promotion (IITP)grant funded by the Korea government (MSIT) (No 2015-0-00557 ResilientFault-Tolerant Autonomic NetworkingBased on Physicality Relationship and Service Semantic ofIoT Devices) and the MSIP (Ministry of Science ICT andFuture Planning) Korea under the ITRC (Information Tech-nology Research Center) support program (IITP-2018-2015-0-00378) supervised by the IITP (Institute for Informationamp Communications Technology Promotion) Also the snu-samsung smart campus research center at Seoul NationalUniversity provides research facilities for this study

References

[1] M Bor U Roedig T Voigt and J M Alonso ldquoDo LoRalow-power wide-area networks scalerdquo in Proceedings of the19th ACM International Conference on Modeling Analysis andSimulation of Wireless and Mobile Systems MSWiM 2016 pp59ndash67 Malta November 2016

[2] DMagrinMCentenaro andLVangelista ldquoPerformance eval-uation of LoRa networks in a smart city scenariordquo inProceedingsof the 2017 IEEE International Conference on CommunicationsICC 2017 France May 2017

[3] LoRa httpswwwlora-allianceorgWhat-Is-LoRaTechnol-ogy

[4] ldquoLoRaWAN 11 specificationrdquo LoRa Alliance 2017 httpslora-allianceorgresource-hublorawantm-specification-v11

[5] M Bor J Vidler and U Roedig ldquoLoRa for the internet ofthingsrdquo in Proceedings of the International Conference onEmbedded Wireless Systems and Networks (EWSN rsquo16) pp 361ndash366 Junction Publishing 2016

[6] 3GPP ldquoStudy on provision of low-cost Machine-Type Commu-nications User Equipments based on LTErdquo TR 36888 V120006 2013

[7] 3GPP ldquoCellular system support for ultra-low complexity andlow throughput Internet of Thingsrdquo TR 45820 V1310 11 2015

[8] J Gozalvez ldquoNew 3GPP Standard for IoTrdquo IEEE VehicularTechnology Magazine vol 11 no 1 pp 14ndash20 2016

[9] R Ratasuk N Mangalvedhe and A Ghosh ldquoOverview ofLTE enhancements for cellular IoTrdquo in Proceedings of the 26thIEEE Annual International Symposium on Personal Indoor andMobile Radio Communications PIMRC 2015 pp 2293ndash2297China September 2015

[10] H Shariatmadari R Ratasuk S Iraji et al ldquoMachine-type com-munications current status and future perspectives toward 5Gsystemsrdquo IEEE CommunicationsMagazine vol 53 no 9 pp 10ndash17 2015

[11] S Landstrom J Bergstrom E Westerberg and D Hammar-wall ldquoNBIoT a sustainable technology for connecting billionsof devicesrdquo Ericsson Technology Review vol 4 pp 2ndash11 2016

[12] M Lauridsen I Z Kovacs P Mogensen M Sorensen andS Holst ldquoCoverage and capacity analysis of LTE-M and NB-IoT in a rural areardquo in Proceedings of the 2016 IEEE 84thVehicular Technology Conference (VTC-Fall) pp 1ndash5 MontrealQC Canada September 2016

[13] Sigfox httpwwwsigfoxcom[14] Weightless open standard httpwwwweightlessorg[15] Ingenu RPMA httpwwwingenucomtechnologyrpma[16] A Dunkels ldquoThe ContikiMAC radio duty cycling protocolrdquo

Technical Report T201113 Swedish Institute of ComputerScience 2011

[17] J Ko J Eriksson N Tsiftes et al ldquoIndustry Beyond interoper-ability - Pushing the performance of sensor network IP stacksrdquoin Proceedings of the 9th ACM Conference on Embedded Net-worked Sensor Systems SenSys 2011 pp 1ndash11 USA November2011

[18] D Moss J Hui and K Klues ldquoTEP 105 low power listeningrdquohttpwwwtinyosnettinyos-2xdocpdftep105pdf 2008

[19] C Gomez J Oller and J Paradells ldquoOverview and evaluationof bluetooth low energy an emerging low-power wirelesstechnologyrdquo Sensors vol 12 no 9 pp 11734ndash11753 2012

[20] A A Kandhalu A E Xhafa and S Hosur ldquoTowards bounded-latency bluetooth low energy for in-vehicle network cablereplacementrdquo in Proceeding of the International Conference onConnected Vehicles and Expo (ICCVE) pp 635ndash640 Las VegasNV USA 2013

[21] A Montanari S Nawaz C Mascolo and K Sailer ldquoA studyof bluetooth low energy performance for human proximitydetection in the workplacerdquo in Proceedings of the 2017 IEEEInternational Conference on Pervasive Computing and Commu-nications PerCom 2017 pp 90ndash99 Kona HI USA March 2017

[22] C Julien C Liu A L Murphy and G P Picco ldquoBLEnd Practi-cal continuous neighbor discovery for bluetooth low energyrdquo inProceedings of the 16th ACMIEEE International Conference onInformation Processing in Sensor Networks IPSN 2017 pp 105ndash116 New York NY USA April 2017

[23] Y Qiu S Li X Xu and Z Li ldquoTalk more listen less energy-efficient neighbor discovery in wireless sensor networksrdquo inProceedings of the 35th Annual IEEE International Conference onComputer Communications IEEE INFOCOM 2016 USA April2016

[24] A J Berni andW D Gregg ldquoOn the utility of chirpmodulationfor digital signalingrdquo IEEE Transactions on Communicationsvol 21 no 6 pp 748ndash751 1973

[25] A Springer W Gugler M Huemer L Reindl C C W Ruppeland R Weigel ldquoSpread spectrum communications using chirpsignalsrdquo in Proceedings of the IEEEAFCEA Information Systemsfor Enhanced Public Safety and Security EUROCOMM2000 pp166ndash170 Germany

[26] IEEE Std 80211-2007 ldquoIEEE Standard for Information Tech-nologymdashTelecommunications and Information Exchange be-tween SystemsmdashLocal and Metropolitan Area NetworksmdashSpecific Requirements Part 11 Wireless LAN Medium AccessControl (MAC) and Physical Layer (PHY) Specifications June2007rdquo

[27] RAK831 httpwwwrakwirelesscomenWisKeyOSHRAK831[28] LoRaWAN network server httpsgithubcomgotthardplor-

awan-server[29] ldquoLoRaWAN 11 Regional Parametersrdquo LoRa Alliance 2017

httpslora-allianceorgresource-hublorawantm-regional-pa-rameters-v11ra

6 Wireless Communications and Mobile Computing

Preamble PHDR

MHDR MACPayload MIC

1

1

1 25 4

4

TimeStamp DevAddr

PHYPayloadPHDR_CRC

(a)

Preamble PHDR_CRCPHDR PHYPayload CRC

MHDR DevAddr MIC

1 44

(b)

Figure 4 Beacon and poll message formats (a) Beacon (b) Poll

Broadcasting is an effective mechanism to disseminatecontrol information in a network that supports one to manycommunications Indeed IEEE 80211 WLANs [26]mdashwherean AP and multiple stations form a one to many networkmdashadopt the periodic broadcast scheme to alert backloggedmobile stations in the Power Saving Mode (PSM) A WLANAPperiodically (usually every 100mSec) broadcasts a beaconmessage that contains Traffic Indication Map (TIM) A TIMenumerates mobile stations that have buffered downlinkpackets Stations in the sleep mode wake up periodically atevery beacon interval to listen TIMs Backlogged stationsthen send PS-Poll frames requesting downlink packet trans-missions As soon as a station receives a buffered frame itfalls back to the sleep mode until the next beacon Stationswithout buffered downlink frames immediately return to thesleep state to minimize energy consumption

Because a LoRaWAN forms a star (more precisely astar-of-stars topology) and supports broadcasting like IEEE80211 WLAN it is natural to adopt a downlink mechanismsimilar to the IEEE 80211 PSM In addition as explained inthe previous section on LoRaWAN primer the LoRaWANstandard already supports a beacon mechanism for timesynchronization We can easily modify the structure of aLoRaWANrsquos beacon frame to augment a field that specifiesbacklogged end-devices This additional field is similar tothe TIM field of the WLAN The message formats of beaconand poll frames are shown in Figure 4 Compared to beacontransmission polling mechanisms for LoRaWAN ask for acareful design because the MAC protocols in LoRaWAN arepractically limited to the unslotted Aloha scheme Given thatcarrier sensing is prohibited a beacon triggers synchronizedmedium access from backlogged end-devices and causesexcessive collisions On the other hand a LoRaWAN is robustagainst collisions because it supports multiple simultaneousreceptions of different SFs and different subbands In shortbecause polling can affect the performance of overall systems

significantly it is worthwhile to carefully analyse all aspectsthat may affect the performance

We consider two polling mechanisms concurrent pollingand sequential polling Before delving into the details ofpolling schemes let us first introduce the notations used forthe following analysis (Table 2)

Concurrent polling is designed to best exploit the char-acteristics of the LoRarsquos PHY layer Note that a gatewaycan receive multiple signals simultaneously if their channelsor SFs are different Commercially available gateways sup-port concurrent demodulation up to 8 signals however letus assume that the number of simultaneous receptions isincreased multiplicatively by deploying multiple gatewaysFor example if a LoRa network uses 10 channels and 6different SFs as in Europe then the maximum of 60 pollscan be delivered simultaneously when more than or equalto 8 gateways are deployed Let busy and idle devices beend-devices with and without pending downlink framesrespectively Hearing a beacon all busy end-devices transmitpolls to the server simultaneously as shown in Figure 5(a)Polls that are in the same subchannel and of the same SF willexperience collisions and will be lost For example polls fromdevices 1198641 1198642 119886119899119889 1198643 are transmitted successfully How-ever polls from devices 1198644 119886119899119889 1198645 will collide and will belost

Let n andmbe the number of themaximumsimultaneousframes that the network allows and the number of framesthat arrive during a beacon period (ie the number ofpolls assuming that there is at most one frame per end-device) The expected number of successful polls is m ∙119890minus119898119899 approximately Because collided polls will competeagain at the next beacon interval the actual number of pollscompeting at each beacon is approximated as1198981015840 = 119898+119898(1minus119890minus119898119899)

Idle devices fall back to the sleep state as soon as theyrecognize there are no frames for them The maximum

Wireless Communications and Mobile Computing 7

Table 2 Notations

Notation Meaning

119863119887 Size of a beacon except preamble the minimum size is 17+4∙ m bytes where m is the number of end-devices with buffereddownlinks

119863119901 Size of a poll frame except preamble The minimum size can be 4119863119889 Average size of a downlink frame except preamble119905119888 Time to compensate clock drift According to the LoRaWAN standard it is set to 13 mSec119905119892 Time gap between two consecutive frames during downlink operation Frames include poll and data119903119887 Beacon broadcasting data rateThe standard specifies using SF=12 and the data rate is 250 bps119903119901 Average poll frame transmission data rate119903119889 Average downlink frame transmission data rate

GatewayTime

Channel=3 SF=7

Channel=3 SF=10

Channel=2 SF=7

Channel=4 SF=10

Channel=4 SF=10

E1

E2

E3

E4

E5

(a)

GatewayTime

Channel=3 SF=7

Channel=3 SF=10

Channel=2 SF=7

Channel=4 SF=10

Channel=4 SF=10

E1

E2

E3

E4

E5

(b)

Figure 5 Example of polling mechanisms (a) Concurrent polling (b) Sequential polling

wake-up time of an idle device during a beacon period 119882119862119868 is computed as follows

119882119862119868 = 119905119888 + 119863119887119903119887 (1)

A busy end-device transmits a poll and waits until it receivesits downlink As soon as it receives the downlink it turnsits radio off until the next beacon Because the gatewaytransmits downlinks only to the end-devices whose polls aresuccessfully received on the average 1198981015840 ∙ 119890minus1198981015840119899 downlinkframes will be transmitted The average maximum wake-uptime of a busy device whose poll is delivered successfully tothe gateway is

119882119862119861119878 = 119905119888 + 119863119887119903119887 + 119863119901

119903119901 + 12 ∙ (119905119892 + 119863119889

119903119889 ) ∙ 1198981015840 ∙ 119890minus1198981015840119899 (2)

A busy device whose poll fails to reach to the gateway mustwait until all downlink transmissions are completed and itswake-up time is

119882119862119861119865 = 119905119888 + 119863119887119903119887 + 119863119901

119903119901 + (119905119892 + 119863119889119903119889 ) ∙ 1198981015840 ∙ 119890minus1198981015840119899 (3)

Under a simple assumption that all end-devices are equallyprobable to have a pending downlink frame the sumof wake-up times of all M devices under the synchronous pollingscheme is

(119872 minus 1198981015840) ∙ 119882119862119868 + 1198981015840 ∙ 119890minus1198981015840119899 ∙ 119882119862119861119878 + 1198981015840

∙ (1 minus 119890minus1198981015840119899) ∙ 119882119862119861119865(4)

The average time that a node should turn on its batteryto receive a downlink is derived by dividing (4) by themultiplication of M and the average number of successfuldownlinks per beacon period

Another scheme that we have considered is sequentialpolling Unlike the contention based concurrent polling end-devices poll and receive downlink in the same order that theiraddresses appeared in the DevAddr fields of a beacon frameFigure 5(b) shows an example of sequential polling Receivinga beacon busy devices remember their positions in theDevAddr field and all devices except the first busy device fallback to the sleep state The first busy device transmits a polland receives a downlink frameThe second busy device wakes

8 Wireless Communications and Mobile Computing

Concurrent n = 8Concurrent n = 16Sequential

8 162 1 4 Offered Load

0

50

100

150

200

250

300

350

400

450

500W

ake-

up ti

me (

mse

c)

(a)

Concurrent n = 8Concurrent n = 16Sequential

8 162 1 4 Offered Load

0

5

10

15

Wak

e-up

tim

e (m

sec)

(b)

Figure 6 Performance of concurrent polling and sequential polling (a) Average wake-up time of both idle and busy devices (b) Averagewake-up time of busy devices

up after one poll-data frame exchange time to poll and receiveits downlinkThe sameprocedure repeats for succeeding busydevices Equation (5) is the average maximum wake-up timeof a busy device

119882119878119861 = 119905119888 + 119863119887119903119887 + 119863119901

119903119901 + (119905119892 + 119863119889119903119889 ) (5)

Moreover the sum of all wake-up times during a beaconperiod is

(M minus m) ∙ 119882119878119868 + 119898 ∙ 119882119878119861 (6)

5 Comparison of Two Polling Schemes

We compared the two polling methods by varying the valuesof parameters that may affect performance The performancemetric is the average wake-up time required for the receptionof one downlink frame We varied the total number of end-devices (M) in a network the number of downlink messagesper beacon interval and the network capacity for concurrenttransmissions (n) Figure 6 shows the average wake-up timesof concurrent and sequential polling as functions of theoffered loadThe unit of the offered load is the number of newdownlink frames generated per beacon interval Figures 6(a)and 6(b) are the wake-up time of all end-devices includingboth idle and busy devices and the wake-up time of busydevices only respectively When calculating the wake up timeof busy devices only terms (119872minus1198981015840)∙119882119862119868 and (Mminusm)∙119882119878119868 in(4) and (6) are excluded We used two values (n=8 and n=16)of network capacity to analyse the effect of maximum simul-taneous receptions For simplicity we assume that receptionpaths of gateways are ideally utilized as each gateway does notlock on the same packet In both Figures 6(a) and 6(b) we

can observe that sequential polling is more effective in powerconserving than concurrent polling When the offered load issmall the performance differences are not great However asthe offered load increases the gap increases also and at m=16concurrent polling consumes 3 to 22 times more energy thansequential polling in the case of all devices (Figure 6(a))Moreover in the case of busy devices only (Figure 6(b))concurrent polling consumes 55 to 41 times more energythan sequential polling The number of total end-devices isfixed at 1000We performed the same analysis by varying thevalue of M and obtain the similar results

We also can observe that concurrent polling at n=16 isbetter than that at n=8 As n increases the probability of colli-sion decreases Collisions affect the performance in twowaysA device whose poll fails to reach a gateway wastes energybecause it should wait until all downlinks are completedAlso collisions increase the offered load at the followingbeacon period and an inflated load again increases the col-lision probability Generally the wake-up time of all devicesdecreases as the offered load increases up to 4 (Figure 6(a))However as the offered load exceeds network capacity (n)wake-up time increases sharply

Because our analytic study reveals the performance ad-vantage of sequential polling over concurrent polling weadopt sequential polling for our downlink communicationscheme Figure 7 illustrates TRILO in a greater detailBeacon Window is divided into downlink reception timeand uplink transmission time After a beacon busy devicesreceive downlink frames sequentially during downlink timeAfter that nodes transmit uplink messages like plain ClassA devices One problem is that uplink transmissions orthe downlinks responding to uplinks may overlap with thefollowing beacon To avoid the problem the Beacon Guardis introduced end-devices refrain from initiating new uplink

Wireless Communications and Mobile Computing 9

Gateway

End-device A

Time

Beacon period

Beacon

poll

End-device B

downlink

uplink

Downlink Uplink

Beacon window

Figure 7 Proposed downlink communication scheme

(a) (b)

Figure 8 Devices used for implementation (a) End-device with SX1272MB2DAS attached to a NUCLEO-L073RZ board (b) Gateway withRAK831 attached to a Raspberry Pi 3

transmissions if remaining time to the next beacon is lessthan Beacon Guard Note that LoRaWAN standard limitsmaximum payload size so that beacon payload cannotconvey a large number of DevAddrs however it can be easilyextended depending on network conditions by using low SFsor allocating short network addresses

6 Implementation

We implemented TRILO using commercially available com-ponents We built a gateway on a RAK831 board [27] whichcontains an SX1301 concentrator chip The gateway board isattached to a Raspberry Pi 3 board as shown in Figure 8(b)For our implementation we employed the Semtech librarieswhich contain LoRaWAN packet forwarder and hardwareabstraction layer for SX1301

In the LoRaWAN architecture a gateway plays a simplerole of a bridge between end-devices and a network serverand a network server performs all beacon and poll messageprocessings We utilize an open source project [28] targetedfor private LoRaWAN network production in implementinga network server Figure 9 describes the message handlermodules that we implemented The beacon handler creates

a beacon payload consisting of the timestamp and buffereddownlink frame information Then it passes the payload tothe packet processor which assembles the payload into abeacon packet Since a beacon needs to be transmitted ina greater time precision than data packets we modified thegateway such that beacons are transmitted immediately Thepoll handler sends a pending downlink frame in responseto a poll message Note that this mechanism is transparentto the LoRaWAN MAC processor and the application serverbecause we implement modules at the packet processor level

An end-device is implemented on a NUCLEO-L073RZboard with an embedded LoRaWAN chip using a 915Mhzantenna (see Figure 8(a)) We attached the SX1272MB2DAScomponent to a NUCLEO-L073RZ board with the modifiedLoRa MAC Note that end-device logics are compiled andstored as firmware in an end-device Time synchronizationbetween nodes and a network server is based on the localtime of a network server instead of GPS time because weimplemented the beacon handler at the server not using thebeacon frame of the Class B standard We modified the end-devicersquos software by adding the beacon handling and pollingfunctions Note that each device which has a pending framewaits for its turn and processing times of each downlink vary

10 Wireless Communications and Mobile Computing

Packet forwarderGateway Packet

processorLoRaWAN

MAC processor

Applicationserver

PUSH DATA

PULL RESP

Pollhandler

Beaconhandler

Figure 9 Block diagram of a network server that handles beacon and poll messages

Figure 10 Experiment environment One gateway (yellow dot) and 15 end-devices (blue dots) are deployed in our office building

due to different SFs In a downlink period we configuredthe time for each poll and downlink based on SF 12 whichhas the longest airtime However the experimental resultsshow that the proposed scheme can be deployed with highperformance even with the conservative configuration It ispossible to optimize the waiting times for each downlinkmore compactly based on the information about SFs of eachnode however we leave this issue as future work

We tuned radios of the components to obey the Koreanregulation which allocates frequency bands from 920Mhzto 923Mhz for LoRaWAN We also added the listen beforetalk (LBT) function as the regulation specifies Note thatthe current LoRaWAN specifications for the KR920-923 ISMband do not have duty cycle limits but require adopting theLBT channel access rule [4]

7 Experimental Results

We evaluate the performance of TRILO by deploying modi-fied components in our office buildingWeplaced the gatewayand three end-devices in our lab Also we deploy 12 moreend-devices on the same floor of the building as shown inFigure 10 The beacon periods are set to either 128 sec or256 sec We varied the uplink and downlink offered loadsfrom 1 2 4 to 8 frames per beacon period The offered trafficis unrealistically large for such a small network however notethat we are trying to emulate the operating conditions of large

scale LoRAWAN networks consisting of tens of thousandsof end-devices Testbeds of such scale are not available soour experiment emulates large networks with 15 end-devicesUplink and downlink messages should be interpreted as anaggregated traffic generated by thousands of end-devicesMessage interarrival times of uplink and downlink trafficfollow the exponential distribution and the destinations ofdownlink messages are randomly and uniformly selectedWe used primitive Adaptive Data Rate (ADR) for SF andpower allocation and all nodes converged to SF 8 and defaultEIRP output power (14dBm) The performance of real-worldLoRaWAN networks depends on the distributions of SFand transmission power However we ignore these factorsbecause improvement of uplink transmissions is not a goalof this work

The performance metrics used in this study includePacket Delivery Ratio (PDR) duty cycle and latency Toobtain reliable results we repeat experiments with the sameparameter values ten times The length of each experimentrun is 10 beacon periods (ie 1280 or 2560 sec) Becausethe destinations of downlinks and the origins of uplinks arerandomly selected it is expected that all end-devices andmessages experience the average performance

First of all we measure the PDR of uplink and downlinkframes We observe that all downlink frames are deliveredsuccessfully without exception The result is rather surprisingbecause TRILO employs beacon broadcasting and polling

Wireless Communications and Mobile Computing 11

Table 3 Packet delivery ratio of uplink traffic at various uplink anddownlink offered loads

Packet generation rate 120582119889 = 1 120582119889 = 2 120582119889 = 4120582119906 = 2 9864 9827 9772120582119906 = 8 9674 9603 9510

in addition to downlink data frames A failure in any onecomponent may lead to unsuccessful data transmissionsUnlike downlink frames uplink traffic experiences occa-sional transmission failures Wemeasure the PDR by varyingthe offered loads of both uplink and downlink traffic Notethat all nodes use the same SF and collisions occur if framesare transmitted on the same channel simultaneously Table 3illustrates the PDR of uplink traffic at different offered loadsBoth uplink and downlink traffic affect the PDR of uplinktraffic The PDR decreases as the offered load of downlinktraffic increases at 120582119906 = 2 the PDR decreases from 9864to 9772 as the offered load of downlink traffic increasesfrom 1 to 4 In addition the uplink traffic intensity also affectsthe PDR of uplink traffic for example at 120582119889 = 2 the PDRdecreases from 9827 to 9603 as the offered load of uplinktraffic increases from 2 to 8

Note that uplink transmissions are prohibited duringpolling and following downlink frame transmissions Uplinkframes which arrive during downlink operation should waituntil the current downlink operation is completed Thiswaiting procedure synchronizes backlogged end-devices andmay cause collisions Even though the LoRa PHY supportsmultiple simultaneous transmissions of different SFs or chan-nels multiple attempts increase the collision probabilitiesand the PDR decreases as both uplink and downlink trafficincrease To reduce the bloated collisions due to synchronoustransmissions persistent mechanisms such as 0-persistenceor p-persistence are required However persistence schemesincrease the complexity of the network protocol and maycause other side effects such as increased energy consump-tion

Next we assess the additional power consumed fordownlink communications Because gateways operate in analways-on mode we only measure the energy consumed byend-devices We use the duty cycle additional time requiredfor downlink communications as the performance metricThe duty cycle is the sum of wake-up times used for beaconreception for possible poll transmission and for downlinkdata frame receptions Figure 11 shows the average duty cycleat different downlink traffic loadsThe duty cycle increases asthe downlink offered load increases it increases from 075to 11 as 120582119889 increases from 1 to 4 Note that all end-devicesconsume the minimal fixed duty cycle for beacon receptionregardless of the intensity of downlink traffic In addition tothe fixed duty cycle end-devices with backlogged downlinkscontinue to stay in the wake-up state for polling and datareception

Figure 12 illustrates the average latency of downlink trafficand uplink traffic as functions of offered load respectively Asshown in Figure 12(a) the average latency of downlink trafficincreases in proportion to the offered load As explained

0

02

04

06

08

1

12

Dut

y Cy

cle (

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

Figure 11 Duty cycles required for downlink operation includingbeacon poll and downlink data transmissions

before downlink frames are generated according to a Poissonprocess Therefore the probability that a downlink frameoccurs in a small time period follows uniform distributionand on average each downlink frame waits one-half of thebeacon interval In addition frames that arrive during adownlink processing are postponed to the next beacon InFigure 12(a) we can observe that the effect of uplink traffic onthe average latency of downlink is minimal This result is notsurprising because uplink and downlink communications arewell isolated in the proposed scheme

Like the average downlink latency the average uplinklatency increases as the downlink offered load increasesUplink frames that arrive during downlink periods shouldwait until the end of the current downlink periodThe averagelatency of uplink traffic as well as the duty cycle increase asthe downlink offered load increases Contrary to Figure 12(a)where the average downlink latency is seldom affected bythe uplink offered load the average uplink latency increasesproportionally as the uplink offered load increases As theuplink communication demands increase a queue startsto form and this causes the increase in waiting time Thequeueing time is most distinctive at 120582119889 = 4 when the servicetime for uplink communications is minimal

8 Simulation Results

We also compared the performance of the Class B downlinkscheme and that of TRILO Because commercial LoRaWANdevices do not support Class B functions yet we relied oncomputer simulations for the performance comparison Thesimulation code is written primarily in CC++ and we con-duct extensive simulations in a typical LoRaWAN networkand in a heavy downlink traffic condition respectively Tocompare energy consumed for downlink communicationswe define the efficiency of each protocol as a performancemetric The efficiency defined as the ratio of data transmis-sion time to the duty cycle is the fraction of time used foruseful work

12 Wireless Communications and Mobile Computing

Ｏ = 2

Ｏ = 8

70

75

80

85

90

95

100

105D

ownl

ink

Late

ncy

(sec

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

(a)

1

2

3

4

5

6

7

8

Upl

ink

Late

ncy

(sec

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

Ｏ = 2

Ｏ = 8

(b)

Figure 12 Average latency of traffic (a) Downlink latency (b) Uplink latency

Table 4 Notations used for Class B downlink protocol and TRILO

Notation Meaning119863119879 Duty cycle of TRILO119863119861 Duty cycle of the Class B downlink protocol119879119879119861119890119886119888119900119899 Beacon transmission time of TRILO

119879119861119861119890119886119888119900119899 Beacon transmission time of the Class B downlinkprotocol

119879119901119900119897119897 Average poll frame transmission time119879119889119900119908119899 Average downlink frame transmission time119896 Parameter for the Class Brsquos ping slots

119868119864 Indicator function representing a node is backlogged ornot

According to the LoRaWAN standard implementation ofthe Class B downlink scheme discretizes the time into so-called ping slots Each end-device requests 2119896 (0 le 119896 le 7)ping slots per beacon period We use the average case of theClass B where each end-device randomly selects a value ofthe parameter 119896 between 0 and 7 Let us first introduce thenotations for the analysis of LoRaWAN downlink protocol(Table 4)

We used SF 9 for beacon transmissions according to theLoRaWAN specification KR920-923 [29] The duty cycle ofTRILO119863119879 is

119863119879 =119879119879119861119890119886119888119900119899 + 119868119864 sdot (119879119901119900119897119897 + 119879119889119900119908119899)

119861119890119886119888119900119899 119875119890119903119894119900119889 (7)

Note that unlike 119879119861119861119890119886119888119900119899 119879119879119861119890119886119888119900119899 increases in proportion tothe number of busy end-devices The duty cycle of a Class Bdevice 119863119861 is

119863119861 = 119879119861119861119890119886119888119900119899 + 2119896 sdot 119879119889119900119908119899119861119890119886119888119900119899 119875119890119903119894119900119889 (8)

Class B devices have different duty cycles depending onrandomly selected values of parameter 119896 Then the efficiencyis computed as

119864119891119891119894119888119894119890119899119888119910 = 119863119900119908119899119897119894119899119896 119905119903119886119899119904119898119894119904119904119894119900119899 119905119894119898119890119863119906119905119910 119888119910119888119897119890119904 (9)

We measured the efficiency of TRILO and the Class Bdownlink protocol by varying the number of nodes from 50to 4000 and the downlink offered load from 2 to 32 framesper beacon period Each performance point is the average of10000 runs We limit the maximum downlink traffic to 32frames per beacon interval because uplink traffic is greaterthan downlink traffic in many LoRaWAN applications Notethat at 120582119889 = 32 about a half of beacon period is consumed fordownlink communications if we assume that the downlinktransmission time is 2 seconds on average

The efficiency of each scheme is shown in Figure 13Note that the offered load is aggregated load and the trafficintensity of individual node decreases as the number of nodesincreases The total times for downlink communications arefixed at each given offered load However the sum of dutycycles increases as the number of nodes increases Thereforein both protocols the maximum efficiencies are realized atsmall networks and the efficiency decreases as the networksize increases The results illustrate that efficiencies of TRILOare higher than those of the Class B downlink protocolthroughout all downlink generation ratesTheClass B schemeperforms well in heavy traffic cases However the proposedscheme outperforms the Class B scheme even in heavy trafficconditions In small networks the performance gap decreasesfrom about 139 times to about 33 times as 120582119889 increases from2 to 32 Also each gap in each offered load increases as thenetwork size increases In the case of TRILO the averageduty cycle decreases inversely proportional to the number ofnodes because only busy devices are active during downlink

Wireless Communications and Mobile Computing 13

Number of Nodes500 1000 1500 2000 2500 3000 3500 4000

10minus3

10minus2

Effici

ency

10minus1

100

101

Class B (＞ = 2)

Proposed (＞ = 2)

Class B (＞ = 8)

Proposed (＞ = 8)

Class B (＞ = 32)

Proposed (＞ = 32)

Figure 13 Efficiency of TRILO and Class B downlink protocol

periods On the contrary Class B protocol allocates 31 pingslots on average regardless of downlink demands In shortthe number of receive windows wasted by the Class B schemevaries depending on the amount of downlink traffic howeveronly busy devices use extra duty cycle for downlink traffic inTRILO

The Class B protocol does not coordinate traffic betweenuplinks and downlinks so that several uplinks can be dis-rupted by downlink transmissions due to the half-duplexcharacteristic of a LoRaWAN gateway all reception pathscan be blocked by downlink transmissions It can obstructthe proper operations of typical LoRaWANs where uplinktransmissions are predominant In contrast the proposedscheme is free from this problem because it isolates the timefor uplinks and downlinks periods

9 Conclusions

A plethora of LPWAN techniques such as LoRa SigFoxRPMA and Weightless have emerged as a new enablingnetwork technology for IoT applications that require low-rate low-cost and long lifetimes LPWANs allow end-deviceinitiated uplinks However to maximize the lifetime ofbattery powered end-devices nodes are put into the sleepstate such that rather restricted downlink communicationsare permitted In this paper we proposed a new downlinkprotocol named TRILO for LoRaWAN

Because LoRaWAN assumes a star topology where mul-tiple end-devices are connected to a single gateway weadopted a beacon based downlink mechanism similar to theIEEE 80211 PSM standard A gateway broadcast beaconsperiodically at every beacon period and end-devices are timesynchronized Beacons alert nodes with buffered downlinksin addition to synchronizing end-devicesrsquo clocks Customizedto the physical characteristics of LoRa we designed two

polling schemes concurrent polling and sequential pollingAn analysis indicates that sequential polling is more energyefficient than concurrent polling

We implement the proposed beacon based downlinkprotocol using commercially available components and con-duct experiments with modified devices Our performancestudy shows that Packet Delivery Ratio (PDR) is almost100 for both uplink and downlink traffic and the extrawake-up time to receive beacons and downlinks is minimalSimulation results also show that our proposed protocol canadaptively allocate receive windows resulting in lower energyconsumption

For further work we plan to investigate the impact ofour scheme on the networks with multiple gateways Alsodetailed investigations of impact of the number of downlinksand the certain distributions of SFs on the performanceseem interesting Optimization techniques leveraging SF andpower allocation are expected to affect the performance of theproposed scheme

Data Availability

The data used to support the findings of this study areincluded within the article

Disclosure

The funding sponsors had no role in the study in thecollection analyses or interpretation of data in the writingof the manuscript and in the decision to publish the results

Conflicts of Interest

The authors declare that there are no conflicts of interestregarding the publication of this paper

14 Wireless Communications and Mobile Computing

Acknowledgments

This work was supported by the National Research Founda-tion of Korea (NRF) Grant funded by the Korean Govern-ment (MSIP) (No 2016R1A5A1012966) Institute for Infor-mation amp Communications Technology Promotion (IITP)grant funded by the Korea government (MSIT) (No 2015-0-00557 ResilientFault-Tolerant Autonomic NetworkingBased on Physicality Relationship and Service Semantic ofIoT Devices) and the MSIP (Ministry of Science ICT andFuture Planning) Korea under the ITRC (Information Tech-nology Research Center) support program (IITP-2018-2015-0-00378) supervised by the IITP (Institute for Informationamp Communications Technology Promotion) Also the snu-samsung smart campus research center at Seoul NationalUniversity provides research facilities for this study

References

[1] M Bor U Roedig T Voigt and J M Alonso ldquoDo LoRalow-power wide-area networks scalerdquo in Proceedings of the19th ACM International Conference on Modeling Analysis andSimulation of Wireless and Mobile Systems MSWiM 2016 pp59ndash67 Malta November 2016

[2] DMagrinMCentenaro andLVangelista ldquoPerformance eval-uation of LoRa networks in a smart city scenariordquo inProceedingsof the 2017 IEEE International Conference on CommunicationsICC 2017 France May 2017

[3] LoRa httpswwwlora-allianceorgWhat-Is-LoRaTechnol-ogy

[4] ldquoLoRaWAN 11 specificationrdquo LoRa Alliance 2017 httpslora-allianceorgresource-hublorawantm-specification-v11

[5] M Bor J Vidler and U Roedig ldquoLoRa for the internet ofthingsrdquo in Proceedings of the International Conference onEmbedded Wireless Systems and Networks (EWSN rsquo16) pp 361ndash366 Junction Publishing 2016

[6] 3GPP ldquoStudy on provision of low-cost Machine-Type Commu-nications User Equipments based on LTErdquo TR 36888 V120006 2013

[7] 3GPP ldquoCellular system support for ultra-low complexity andlow throughput Internet of Thingsrdquo TR 45820 V1310 11 2015

[8] J Gozalvez ldquoNew 3GPP Standard for IoTrdquo IEEE VehicularTechnology Magazine vol 11 no 1 pp 14ndash20 2016

[9] R Ratasuk N Mangalvedhe and A Ghosh ldquoOverview ofLTE enhancements for cellular IoTrdquo in Proceedings of the 26thIEEE Annual International Symposium on Personal Indoor andMobile Radio Communications PIMRC 2015 pp 2293ndash2297China September 2015

[10] H Shariatmadari R Ratasuk S Iraji et al ldquoMachine-type com-munications current status and future perspectives toward 5Gsystemsrdquo IEEE CommunicationsMagazine vol 53 no 9 pp 10ndash17 2015

[11] S Landstrom J Bergstrom E Westerberg and D Hammar-wall ldquoNBIoT a sustainable technology for connecting billionsof devicesrdquo Ericsson Technology Review vol 4 pp 2ndash11 2016

[12] M Lauridsen I Z Kovacs P Mogensen M Sorensen andS Holst ldquoCoverage and capacity analysis of LTE-M and NB-IoT in a rural areardquo in Proceedings of the 2016 IEEE 84thVehicular Technology Conference (VTC-Fall) pp 1ndash5 MontrealQC Canada September 2016

[13] Sigfox httpwwwsigfoxcom[14] Weightless open standard httpwwwweightlessorg[15] Ingenu RPMA httpwwwingenucomtechnologyrpma[16] A Dunkels ldquoThe ContikiMAC radio duty cycling protocolrdquo

Technical Report T201113 Swedish Institute of ComputerScience 2011

[17] J Ko J Eriksson N Tsiftes et al ldquoIndustry Beyond interoper-ability - Pushing the performance of sensor network IP stacksrdquoin Proceedings of the 9th ACM Conference on Embedded Net-worked Sensor Systems SenSys 2011 pp 1ndash11 USA November2011

[18] D Moss J Hui and K Klues ldquoTEP 105 low power listeningrdquohttpwwwtinyosnettinyos-2xdocpdftep105pdf 2008

[19] C Gomez J Oller and J Paradells ldquoOverview and evaluationof bluetooth low energy an emerging low-power wirelesstechnologyrdquo Sensors vol 12 no 9 pp 11734ndash11753 2012

[20] A A Kandhalu A E Xhafa and S Hosur ldquoTowards bounded-latency bluetooth low energy for in-vehicle network cablereplacementrdquo in Proceeding of the International Conference onConnected Vehicles and Expo (ICCVE) pp 635ndash640 Las VegasNV USA 2013

[21] A Montanari S Nawaz C Mascolo and K Sailer ldquoA studyof bluetooth low energy performance for human proximitydetection in the workplacerdquo in Proceedings of the 2017 IEEEInternational Conference on Pervasive Computing and Commu-nications PerCom 2017 pp 90ndash99 Kona HI USA March 2017

[22] C Julien C Liu A L Murphy and G P Picco ldquoBLEnd Practi-cal continuous neighbor discovery for bluetooth low energyrdquo inProceedings of the 16th ACMIEEE International Conference onInformation Processing in Sensor Networks IPSN 2017 pp 105ndash116 New York NY USA April 2017

[23] Y Qiu S Li X Xu and Z Li ldquoTalk more listen less energy-efficient neighbor discovery in wireless sensor networksrdquo inProceedings of the 35th Annual IEEE International Conference onComputer Communications IEEE INFOCOM 2016 USA April2016

[24] A J Berni andW D Gregg ldquoOn the utility of chirpmodulationfor digital signalingrdquo IEEE Transactions on Communicationsvol 21 no 6 pp 748ndash751 1973

[25] A Springer W Gugler M Huemer L Reindl C C W Ruppeland R Weigel ldquoSpread spectrum communications using chirpsignalsrdquo in Proceedings of the IEEEAFCEA Information Systemsfor Enhanced Public Safety and Security EUROCOMM2000 pp166ndash170 Germany

[26] IEEE Std 80211-2007 ldquoIEEE Standard for Information Tech-nologymdashTelecommunications and Information Exchange be-tween SystemsmdashLocal and Metropolitan Area NetworksmdashSpecific Requirements Part 11 Wireless LAN Medium AccessControl (MAC) and Physical Layer (PHY) Specifications June2007rdquo

[27] RAK831 httpwwwrakwirelesscomenWisKeyOSHRAK831[28] LoRaWAN network server httpsgithubcomgotthardplor-

awan-server[29] ldquoLoRaWAN 11 Regional Parametersrdquo LoRa Alliance 2017

httpslora-allianceorgresource-hublorawantm-regional-pa-rameters-v11ra

Wireless Communications and Mobile Computing 7

Table 2 Notations

Notation Meaning

119863119887 Size of a beacon except preamble the minimum size is 17+4∙ m bytes where m is the number of end-devices with buffereddownlinks

119863119901 Size of a poll frame except preamble The minimum size can be 4119863119889 Average size of a downlink frame except preamble119905119888 Time to compensate clock drift According to the LoRaWAN standard it is set to 13 mSec119905119892 Time gap between two consecutive frames during downlink operation Frames include poll and data119903119887 Beacon broadcasting data rateThe standard specifies using SF=12 and the data rate is 250 bps119903119901 Average poll frame transmission data rate119903119889 Average downlink frame transmission data rate

GatewayTime

Channel=3 SF=7

Channel=3 SF=10

Channel=2 SF=7

Channel=4 SF=10

Channel=4 SF=10

E1

E2

E3

E4

E5

(a)

GatewayTime

Channel=3 SF=7

Channel=3 SF=10

Channel=2 SF=7

Channel=4 SF=10

Channel=4 SF=10

E1

E2

E3

E4

E5

(b)

Figure 5 Example of polling mechanisms (a) Concurrent polling (b) Sequential polling

wake-up time of an idle device during a beacon period 119882119862119868 is computed as follows

119882119862119868 = 119905119888 + 119863119887119903119887 (1)

A busy end-device transmits a poll and waits until it receivesits downlink As soon as it receives the downlink it turnsits radio off until the next beacon Because the gatewaytransmits downlinks only to the end-devices whose polls aresuccessfully received on the average 1198981015840 ∙ 119890minus1198981015840119899 downlinkframes will be transmitted The average maximum wake-uptime of a busy device whose poll is delivered successfully tothe gateway is

119882119862119861119878 = 119905119888 + 119863119887119903119887 + 119863119901

119903119901 + 12 ∙ (119905119892 + 119863119889

119903119889 ) ∙ 1198981015840 ∙ 119890minus1198981015840119899 (2)

A busy device whose poll fails to reach to the gateway mustwait until all downlink transmissions are completed and itswake-up time is

119882119862119861119865 = 119905119888 + 119863119887119903119887 + 119863119901

119903119901 + (119905119892 + 119863119889119903119889 ) ∙ 1198981015840 ∙ 119890minus1198981015840119899 (3)

Under a simple assumption that all end-devices are equallyprobable to have a pending downlink frame the sumof wake-up times of all M devices under the synchronous pollingscheme is

(119872 minus 1198981015840) ∙ 119882119862119868 + 1198981015840 ∙ 119890minus1198981015840119899 ∙ 119882119862119861119878 + 1198981015840

∙ (1 minus 119890minus1198981015840119899) ∙ 119882119862119861119865(4)

The average time that a node should turn on its batteryto receive a downlink is derived by dividing (4) by themultiplication of M and the average number of successfuldownlinks per beacon period

Another scheme that we have considered is sequentialpolling Unlike the contention based concurrent polling end-devices poll and receive downlink in the same order that theiraddresses appeared in the DevAddr fields of a beacon frameFigure 5(b) shows an example of sequential polling Receivinga beacon busy devices remember their positions in theDevAddr field and all devices except the first busy device fallback to the sleep state The first busy device transmits a polland receives a downlink frameThe second busy device wakes

8 Wireless Communications and Mobile Computing

Concurrent n = 8Concurrent n = 16Sequential

8 162 1 4 Offered Load

0

50

100

150

200

250

300

350

400

450

500W

ake-

up ti

me (

mse

c)

(a)

Concurrent n = 8Concurrent n = 16Sequential

8 162 1 4 Offered Load

0

5

10

15

Wak

e-up

tim

e (m

sec)

(b)

Figure 6 Performance of concurrent polling and sequential polling (a) Average wake-up time of both idle and busy devices (b) Averagewake-up time of busy devices

up after one poll-data frame exchange time to poll and receiveits downlinkThe sameprocedure repeats for succeeding busydevices Equation (5) is the average maximum wake-up timeof a busy device

119882119878119861 = 119905119888 + 119863119887119903119887 + 119863119901

119903119901 + (119905119892 + 119863119889119903119889 ) (5)

Moreover the sum of all wake-up times during a beaconperiod is

(M minus m) ∙ 119882119878119868 + 119898 ∙ 119882119878119861 (6)

5 Comparison of Two Polling Schemes

We compared the two polling methods by varying the valuesof parameters that may affect performance The performancemetric is the average wake-up time required for the receptionof one downlink frame We varied the total number of end-devices (M) in a network the number of downlink messagesper beacon interval and the network capacity for concurrenttransmissions (n) Figure 6 shows the average wake-up timesof concurrent and sequential polling as functions of theoffered loadThe unit of the offered load is the number of newdownlink frames generated per beacon interval Figures 6(a)and 6(b) are the wake-up time of all end-devices includingboth idle and busy devices and the wake-up time of busydevices only respectively When calculating the wake up timeof busy devices only terms (119872minus1198981015840)∙119882119862119868 and (Mminusm)∙119882119878119868 in(4) and (6) are excluded We used two values (n=8 and n=16)of network capacity to analyse the effect of maximum simul-taneous receptions For simplicity we assume that receptionpaths of gateways are ideally utilized as each gateway does notlock on the same packet In both Figures 6(a) and 6(b) we

can observe that sequential polling is more effective in powerconserving than concurrent polling When the offered load issmall the performance differences are not great However asthe offered load increases the gap increases also and at m=16concurrent polling consumes 3 to 22 times more energy thansequential polling in the case of all devices (Figure 6(a))Moreover in the case of busy devices only (Figure 6(b))concurrent polling consumes 55 to 41 times more energythan sequential polling The number of total end-devices isfixed at 1000We performed the same analysis by varying thevalue of M and obtain the similar results

We also can observe that concurrent polling at n=16 isbetter than that at n=8 As n increases the probability of colli-sion decreases Collisions affect the performance in twowaysA device whose poll fails to reach a gateway wastes energybecause it should wait until all downlinks are completedAlso collisions increase the offered load at the followingbeacon period and an inflated load again increases the col-lision probability Generally the wake-up time of all devicesdecreases as the offered load increases up to 4 (Figure 6(a))However as the offered load exceeds network capacity (n)wake-up time increases sharply

Because our analytic study reveals the performance ad-vantage of sequential polling over concurrent polling weadopt sequential polling for our downlink communicationscheme Figure 7 illustrates TRILO in a greater detailBeacon Window is divided into downlink reception timeand uplink transmission time After a beacon busy devicesreceive downlink frames sequentially during downlink timeAfter that nodes transmit uplink messages like plain ClassA devices One problem is that uplink transmissions orthe downlinks responding to uplinks may overlap with thefollowing beacon To avoid the problem the Beacon Guardis introduced end-devices refrain from initiating new uplink

Wireless Communications and Mobile Computing 9

Gateway

End-device A

Time

Beacon period

Beacon

poll

End-device B

downlink

uplink

Downlink Uplink

Beacon window

Figure 7 Proposed downlink communication scheme

(a) (b)

Figure 8 Devices used for implementation (a) End-device with SX1272MB2DAS attached to a NUCLEO-L073RZ board (b) Gateway withRAK831 attached to a Raspberry Pi 3

transmissions if remaining time to the next beacon is lessthan Beacon Guard Note that LoRaWAN standard limitsmaximum payload size so that beacon payload cannotconvey a large number of DevAddrs however it can be easilyextended depending on network conditions by using low SFsor allocating short network addresses

6 Implementation

We implemented TRILO using commercially available com-ponents We built a gateway on a RAK831 board [27] whichcontains an SX1301 concentrator chip The gateway board isattached to a Raspberry Pi 3 board as shown in Figure 8(b)For our implementation we employed the Semtech librarieswhich contain LoRaWAN packet forwarder and hardwareabstraction layer for SX1301

In the LoRaWAN architecture a gateway plays a simplerole of a bridge between end-devices and a network serverand a network server performs all beacon and poll messageprocessings We utilize an open source project [28] targetedfor private LoRaWAN network production in implementinga network server Figure 9 describes the message handlermodules that we implemented The beacon handler creates

a beacon payload consisting of the timestamp and buffereddownlink frame information Then it passes the payload tothe packet processor which assembles the payload into abeacon packet Since a beacon needs to be transmitted ina greater time precision than data packets we modified thegateway such that beacons are transmitted immediately Thepoll handler sends a pending downlink frame in responseto a poll message Note that this mechanism is transparentto the LoRaWAN MAC processor and the application serverbecause we implement modules at the packet processor level

An end-device is implemented on a NUCLEO-L073RZboard with an embedded LoRaWAN chip using a 915Mhzantenna (see Figure 8(a)) We attached the SX1272MB2DAScomponent to a NUCLEO-L073RZ board with the modifiedLoRa MAC Note that end-device logics are compiled andstored as firmware in an end-device Time synchronizationbetween nodes and a network server is based on the localtime of a network server instead of GPS time because weimplemented the beacon handler at the server not using thebeacon frame of the Class B standard We modified the end-devicersquos software by adding the beacon handling and pollingfunctions Note that each device which has a pending framewaits for its turn and processing times of each downlink vary

10 Wireless Communications and Mobile Computing

Packet forwarderGateway Packet

processorLoRaWAN

MAC processor

Applicationserver

PUSH DATA

PULL RESP

Pollhandler

Beaconhandler

Figure 9 Block diagram of a network server that handles beacon and poll messages

Figure 10 Experiment environment One gateway (yellow dot) and 15 end-devices (blue dots) are deployed in our office building

due to different SFs In a downlink period we configuredthe time for each poll and downlink based on SF 12 whichhas the longest airtime However the experimental resultsshow that the proposed scheme can be deployed with highperformance even with the conservative configuration It ispossible to optimize the waiting times for each downlinkmore compactly based on the information about SFs of eachnode however we leave this issue as future work

We tuned radios of the components to obey the Koreanregulation which allocates frequency bands from 920Mhzto 923Mhz for LoRaWAN We also added the listen beforetalk (LBT) function as the regulation specifies Note thatthe current LoRaWAN specifications for the KR920-923 ISMband do not have duty cycle limits but require adopting theLBT channel access rule [4]

7 Experimental Results

We evaluate the performance of TRILO by deploying modi-fied components in our office buildingWeplaced the gatewayand three end-devices in our lab Also we deploy 12 moreend-devices on the same floor of the building as shown inFigure 10 The beacon periods are set to either 128 sec or256 sec We varied the uplink and downlink offered loadsfrom 1 2 4 to 8 frames per beacon period The offered trafficis unrealistically large for such a small network however notethat we are trying to emulate the operating conditions of large

scale LoRAWAN networks consisting of tens of thousandsof end-devices Testbeds of such scale are not available soour experiment emulates large networks with 15 end-devicesUplink and downlink messages should be interpreted as anaggregated traffic generated by thousands of end-devicesMessage interarrival times of uplink and downlink trafficfollow the exponential distribution and the destinations ofdownlink messages are randomly and uniformly selectedWe used primitive Adaptive Data Rate (ADR) for SF andpower allocation and all nodes converged to SF 8 and defaultEIRP output power (14dBm) The performance of real-worldLoRaWAN networks depends on the distributions of SFand transmission power However we ignore these factorsbecause improvement of uplink transmissions is not a goalof this work

The performance metrics used in this study includePacket Delivery Ratio (PDR) duty cycle and latency Toobtain reliable results we repeat experiments with the sameparameter values ten times The length of each experimentrun is 10 beacon periods (ie 1280 or 2560 sec) Becausethe destinations of downlinks and the origins of uplinks arerandomly selected it is expected that all end-devices andmessages experience the average performance

First of all we measure the PDR of uplink and downlinkframes We observe that all downlink frames are deliveredsuccessfully without exception The result is rather surprisingbecause TRILO employs beacon broadcasting and polling

Wireless Communications and Mobile Computing 11

Table 3 Packet delivery ratio of uplink traffic at various uplink anddownlink offered loads

Packet generation rate 120582119889 = 1 120582119889 = 2 120582119889 = 4120582119906 = 2 9864 9827 9772120582119906 = 8 9674 9603 9510

in addition to downlink data frames A failure in any onecomponent may lead to unsuccessful data transmissionsUnlike downlink frames uplink traffic experiences occa-sional transmission failures Wemeasure the PDR by varyingthe offered loads of both uplink and downlink traffic Notethat all nodes use the same SF and collisions occur if framesare transmitted on the same channel simultaneously Table 3illustrates the PDR of uplink traffic at different offered loadsBoth uplink and downlink traffic affect the PDR of uplinktraffic The PDR decreases as the offered load of downlinktraffic increases at 120582119906 = 2 the PDR decreases from 9864to 9772 as the offered load of downlink traffic increasesfrom 1 to 4 In addition the uplink traffic intensity also affectsthe PDR of uplink traffic for example at 120582119889 = 2 the PDRdecreases from 9827 to 9603 as the offered load of uplinktraffic increases from 2 to 8

Note that uplink transmissions are prohibited duringpolling and following downlink frame transmissions Uplinkframes which arrive during downlink operation should waituntil the current downlink operation is completed Thiswaiting procedure synchronizes backlogged end-devices andmay cause collisions Even though the LoRa PHY supportsmultiple simultaneous transmissions of different SFs or chan-nels multiple attempts increase the collision probabilitiesand the PDR decreases as both uplink and downlink trafficincrease To reduce the bloated collisions due to synchronoustransmissions persistent mechanisms such as 0-persistenceor p-persistence are required However persistence schemesincrease the complexity of the network protocol and maycause other side effects such as increased energy consump-tion

Next we assess the additional power consumed fordownlink communications Because gateways operate in analways-on mode we only measure the energy consumed byend-devices We use the duty cycle additional time requiredfor downlink communications as the performance metricThe duty cycle is the sum of wake-up times used for beaconreception for possible poll transmission and for downlinkdata frame receptions Figure 11 shows the average duty cycleat different downlink traffic loadsThe duty cycle increases asthe downlink offered load increases it increases from 075to 11 as 120582119889 increases from 1 to 4 Note that all end-devicesconsume the minimal fixed duty cycle for beacon receptionregardless of the intensity of downlink traffic In addition tothe fixed duty cycle end-devices with backlogged downlinkscontinue to stay in the wake-up state for polling and datareception

Figure 12 illustrates the average latency of downlink trafficand uplink traffic as functions of offered load respectively Asshown in Figure 12(a) the average latency of downlink trafficincreases in proportion to the offered load As explained

0

02

04

06

08

1

12

Dut

y Cy

cle (

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

Figure 11 Duty cycles required for downlink operation includingbeacon poll and downlink data transmissions

before downlink frames are generated according to a Poissonprocess Therefore the probability that a downlink frameoccurs in a small time period follows uniform distributionand on average each downlink frame waits one-half of thebeacon interval In addition frames that arrive during adownlink processing are postponed to the next beacon InFigure 12(a) we can observe that the effect of uplink traffic onthe average latency of downlink is minimal This result is notsurprising because uplink and downlink communications arewell isolated in the proposed scheme

Like the average downlink latency the average uplinklatency increases as the downlink offered load increasesUplink frames that arrive during downlink periods shouldwait until the end of the current downlink periodThe averagelatency of uplink traffic as well as the duty cycle increase asthe downlink offered load increases Contrary to Figure 12(a)where the average downlink latency is seldom affected bythe uplink offered load the average uplink latency increasesproportionally as the uplink offered load increases As theuplink communication demands increase a queue startsto form and this causes the increase in waiting time Thequeueing time is most distinctive at 120582119889 = 4 when the servicetime for uplink communications is minimal

8 Simulation Results

We also compared the performance of the Class B downlinkscheme and that of TRILO Because commercial LoRaWANdevices do not support Class B functions yet we relied oncomputer simulations for the performance comparison Thesimulation code is written primarily in CC++ and we con-duct extensive simulations in a typical LoRaWAN networkand in a heavy downlink traffic condition respectively Tocompare energy consumed for downlink communicationswe define the efficiency of each protocol as a performancemetric The efficiency defined as the ratio of data transmis-sion time to the duty cycle is the fraction of time used foruseful work

12 Wireless Communications and Mobile Computing

Ｏ = 2

Ｏ = 8

70

75

80

85

90

95

100

105D

ownl

ink

Late

ncy

(sec

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

(a)

1

2

3

4

5

6

7

8

Upl

ink

Late

ncy

(sec

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

Ｏ = 2

Ｏ = 8

(b)

Figure 12 Average latency of traffic (a) Downlink latency (b) Uplink latency

Table 4 Notations used for Class B downlink protocol and TRILO

Notation Meaning119863119879 Duty cycle of TRILO119863119861 Duty cycle of the Class B downlink protocol119879119879119861119890119886119888119900119899 Beacon transmission time of TRILO

119879119861119861119890119886119888119900119899 Beacon transmission time of the Class B downlinkprotocol

119879119901119900119897119897 Average poll frame transmission time119879119889119900119908119899 Average downlink frame transmission time119896 Parameter for the Class Brsquos ping slots

119868119864 Indicator function representing a node is backlogged ornot

According to the LoRaWAN standard implementation ofthe Class B downlink scheme discretizes the time into so-called ping slots Each end-device requests 2119896 (0 le 119896 le 7)ping slots per beacon period We use the average case of theClass B where each end-device randomly selects a value ofthe parameter 119896 between 0 and 7 Let us first introduce thenotations for the analysis of LoRaWAN downlink protocol(Table 4)

We used SF 9 for beacon transmissions according to theLoRaWAN specification KR920-923 [29] The duty cycle ofTRILO119863119879 is

119863119879 =119879119879119861119890119886119888119900119899 + 119868119864 sdot (119879119901119900119897119897 + 119879119889119900119908119899)

119861119890119886119888119900119899 119875119890119903119894119900119889 (7)

Note that unlike 119879119861119861119890119886119888119900119899 119879119879119861119890119886119888119900119899 increases in proportion tothe number of busy end-devices The duty cycle of a Class Bdevice 119863119861 is

119863119861 = 119879119861119861119890119886119888119900119899 + 2119896 sdot 119879119889119900119908119899119861119890119886119888119900119899 119875119890119903119894119900119889 (8)

Class B devices have different duty cycles depending onrandomly selected values of parameter 119896 Then the efficiencyis computed as

119864119891119891119894119888119894119890119899119888119910 = 119863119900119908119899119897119894119899119896 119905119903119886119899119904119898119894119904119904119894119900119899 119905119894119898119890119863119906119905119910 119888119910119888119897119890119904 (9)

We measured the efficiency of TRILO and the Class Bdownlink protocol by varying the number of nodes from 50to 4000 and the downlink offered load from 2 to 32 framesper beacon period Each performance point is the average of10000 runs We limit the maximum downlink traffic to 32frames per beacon interval because uplink traffic is greaterthan downlink traffic in many LoRaWAN applications Notethat at 120582119889 = 32 about a half of beacon period is consumed fordownlink communications if we assume that the downlinktransmission time is 2 seconds on average

The efficiency of each scheme is shown in Figure 13Note that the offered load is aggregated load and the trafficintensity of individual node decreases as the number of nodesincreases The total times for downlink communications arefixed at each given offered load However the sum of dutycycles increases as the number of nodes increases Thereforein both protocols the maximum efficiencies are realized atsmall networks and the efficiency decreases as the networksize increases The results illustrate that efficiencies of TRILOare higher than those of the Class B downlink protocolthroughout all downlink generation ratesTheClass B schemeperforms well in heavy traffic cases However the proposedscheme outperforms the Class B scheme even in heavy trafficconditions In small networks the performance gap decreasesfrom about 139 times to about 33 times as 120582119889 increases from2 to 32 Also each gap in each offered load increases as thenetwork size increases In the case of TRILO the averageduty cycle decreases inversely proportional to the number ofnodes because only busy devices are active during downlink

Wireless Communications and Mobile Computing 13

Number of Nodes500 1000 1500 2000 2500 3000 3500 4000

10minus3

10minus2

Effici

ency

10minus1

100

101

Class B (＞ = 2)

Proposed (＞ = 2)

Class B (＞ = 8)

Proposed (＞ = 8)

Class B (＞ = 32)

Proposed (＞ = 32)

Figure 13 Efficiency of TRILO and Class B downlink protocol

periods On the contrary Class B protocol allocates 31 pingslots on average regardless of downlink demands In shortthe number of receive windows wasted by the Class B schemevaries depending on the amount of downlink traffic howeveronly busy devices use extra duty cycle for downlink traffic inTRILO

The Class B protocol does not coordinate traffic betweenuplinks and downlinks so that several uplinks can be dis-rupted by downlink transmissions due to the half-duplexcharacteristic of a LoRaWAN gateway all reception pathscan be blocked by downlink transmissions It can obstructthe proper operations of typical LoRaWANs where uplinktransmissions are predominant In contrast the proposedscheme is free from this problem because it isolates the timefor uplinks and downlinks periods

9 Conclusions

A plethora of LPWAN techniques such as LoRa SigFoxRPMA and Weightless have emerged as a new enablingnetwork technology for IoT applications that require low-rate low-cost and long lifetimes LPWANs allow end-deviceinitiated uplinks However to maximize the lifetime ofbattery powered end-devices nodes are put into the sleepstate such that rather restricted downlink communicationsare permitted In this paper we proposed a new downlinkprotocol named TRILO for LoRaWAN

Because LoRaWAN assumes a star topology where mul-tiple end-devices are connected to a single gateway weadopted a beacon based downlink mechanism similar to theIEEE 80211 PSM standard A gateway broadcast beaconsperiodically at every beacon period and end-devices are timesynchronized Beacons alert nodes with buffered downlinksin addition to synchronizing end-devicesrsquo clocks Customizedto the physical characteristics of LoRa we designed two

polling schemes concurrent polling and sequential pollingAn analysis indicates that sequential polling is more energyefficient than concurrent polling

We implement the proposed beacon based downlinkprotocol using commercially available components and con-duct experiments with modified devices Our performancestudy shows that Packet Delivery Ratio (PDR) is almost100 for both uplink and downlink traffic and the extrawake-up time to receive beacons and downlinks is minimalSimulation results also show that our proposed protocol canadaptively allocate receive windows resulting in lower energyconsumption

For further work we plan to investigate the impact ofour scheme on the networks with multiple gateways Alsodetailed investigations of impact of the number of downlinksand the certain distributions of SFs on the performanceseem interesting Optimization techniques leveraging SF andpower allocation are expected to affect the performance of theproposed scheme

Data Availability

The data used to support the findings of this study areincluded within the article

Disclosure

The funding sponsors had no role in the study in thecollection analyses or interpretation of data in the writingof the manuscript and in the decision to publish the results

Conflicts of Interest

The authors declare that there are no conflicts of interestregarding the publication of this paper

14 Wireless Communications and Mobile Computing

Acknowledgments

This work was supported by the National Research Founda-tion of Korea (NRF) Grant funded by the Korean Govern-ment (MSIP) (No 2016R1A5A1012966) Institute for Infor-mation amp Communications Technology Promotion (IITP)grant funded by the Korea government (MSIT) (No 2015-0-00557 ResilientFault-Tolerant Autonomic NetworkingBased on Physicality Relationship and Service Semantic ofIoT Devices) and the MSIP (Ministry of Science ICT andFuture Planning) Korea under the ITRC (Information Tech-nology Research Center) support program (IITP-2018-2015-0-00378) supervised by the IITP (Institute for Informationamp Communications Technology Promotion) Also the snu-samsung smart campus research center at Seoul NationalUniversity provides research facilities for this study

References

[1] M Bor U Roedig T Voigt and J M Alonso ldquoDo LoRalow-power wide-area networks scalerdquo in Proceedings of the19th ACM International Conference on Modeling Analysis andSimulation of Wireless and Mobile Systems MSWiM 2016 pp59ndash67 Malta November 2016

[2] DMagrinMCentenaro andLVangelista ldquoPerformance eval-uation of LoRa networks in a smart city scenariordquo inProceedingsof the 2017 IEEE International Conference on CommunicationsICC 2017 France May 2017

[3] LoRa httpswwwlora-allianceorgWhat-Is-LoRaTechnol-ogy

[4] ldquoLoRaWAN 11 specificationrdquo LoRa Alliance 2017 httpslora-allianceorgresource-hublorawantm-specification-v11

[5] M Bor J Vidler and U Roedig ldquoLoRa for the internet ofthingsrdquo in Proceedings of the International Conference onEmbedded Wireless Systems and Networks (EWSN rsquo16) pp 361ndash366 Junction Publishing 2016

[6] 3GPP ldquoStudy on provision of low-cost Machine-Type Commu-nications User Equipments based on LTErdquo TR 36888 V120006 2013

[7] 3GPP ldquoCellular system support for ultra-low complexity andlow throughput Internet of Thingsrdquo TR 45820 V1310 11 2015

[8] J Gozalvez ldquoNew 3GPP Standard for IoTrdquo IEEE VehicularTechnology Magazine vol 11 no 1 pp 14ndash20 2016

[9] R Ratasuk N Mangalvedhe and A Ghosh ldquoOverview ofLTE enhancements for cellular IoTrdquo in Proceedings of the 26thIEEE Annual International Symposium on Personal Indoor andMobile Radio Communications PIMRC 2015 pp 2293ndash2297China September 2015

[10] H Shariatmadari R Ratasuk S Iraji et al ldquoMachine-type com-munications current status and future perspectives toward 5Gsystemsrdquo IEEE CommunicationsMagazine vol 53 no 9 pp 10ndash17 2015

[11] S Landstrom J Bergstrom E Westerberg and D Hammar-wall ldquoNBIoT a sustainable technology for connecting billionsof devicesrdquo Ericsson Technology Review vol 4 pp 2ndash11 2016

[12] M Lauridsen I Z Kovacs P Mogensen M Sorensen andS Holst ldquoCoverage and capacity analysis of LTE-M and NB-IoT in a rural areardquo in Proceedings of the 2016 IEEE 84thVehicular Technology Conference (VTC-Fall) pp 1ndash5 MontrealQC Canada September 2016

[13] Sigfox httpwwwsigfoxcom[14] Weightless open standard httpwwwweightlessorg[15] Ingenu RPMA httpwwwingenucomtechnologyrpma[16] A Dunkels ldquoThe ContikiMAC radio duty cycling protocolrdquo

Technical Report T201113 Swedish Institute of ComputerScience 2011

[17] J Ko J Eriksson N Tsiftes et al ldquoIndustry Beyond interoper-ability - Pushing the performance of sensor network IP stacksrdquoin Proceedings of the 9th ACM Conference on Embedded Net-worked Sensor Systems SenSys 2011 pp 1ndash11 USA November2011

[18] D Moss J Hui and K Klues ldquoTEP 105 low power listeningrdquohttpwwwtinyosnettinyos-2xdocpdftep105pdf 2008

[19] C Gomez J Oller and J Paradells ldquoOverview and evaluationof bluetooth low energy an emerging low-power wirelesstechnologyrdquo Sensors vol 12 no 9 pp 11734ndash11753 2012

[20] A A Kandhalu A E Xhafa and S Hosur ldquoTowards bounded-latency bluetooth low energy for in-vehicle network cablereplacementrdquo in Proceeding of the International Conference onConnected Vehicles and Expo (ICCVE) pp 635ndash640 Las VegasNV USA 2013

[21] A Montanari S Nawaz C Mascolo and K Sailer ldquoA studyof bluetooth low energy performance for human proximitydetection in the workplacerdquo in Proceedings of the 2017 IEEEInternational Conference on Pervasive Computing and Commu-nications PerCom 2017 pp 90ndash99 Kona HI USA March 2017

[22] C Julien C Liu A L Murphy and G P Picco ldquoBLEnd Practi-cal continuous neighbor discovery for bluetooth low energyrdquo inProceedings of the 16th ACMIEEE International Conference onInformation Processing in Sensor Networks IPSN 2017 pp 105ndash116 New York NY USA April 2017

[23] Y Qiu S Li X Xu and Z Li ldquoTalk more listen less energy-efficient neighbor discovery in wireless sensor networksrdquo inProceedings of the 35th Annual IEEE International Conference onComputer Communications IEEE INFOCOM 2016 USA April2016

[24] A J Berni andW D Gregg ldquoOn the utility of chirpmodulationfor digital signalingrdquo IEEE Transactions on Communicationsvol 21 no 6 pp 748ndash751 1973

[25] A Springer W Gugler M Huemer L Reindl C C W Ruppeland R Weigel ldquoSpread spectrum communications using chirpsignalsrdquo in Proceedings of the IEEEAFCEA Information Systemsfor Enhanced Public Safety and Security EUROCOMM2000 pp166ndash170 Germany

[26] IEEE Std 80211-2007 ldquoIEEE Standard for Information Tech-nologymdashTelecommunications and Information Exchange be-tween SystemsmdashLocal and Metropolitan Area NetworksmdashSpecific Requirements Part 11 Wireless LAN Medium AccessControl (MAC) and Physical Layer (PHY) Specifications June2007rdquo

[27] RAK831 httpwwwrakwirelesscomenWisKeyOSHRAK831[28] LoRaWAN network server httpsgithubcomgotthardplor-

awan-server[29] ldquoLoRaWAN 11 Regional Parametersrdquo LoRa Alliance 2017

httpslora-allianceorgresource-hublorawantm-regional-pa-rameters-v11ra

8 Wireless Communications and Mobile Computing

Concurrent n = 8Concurrent n = 16Sequential

8 162 1 4 Offered Load

0

50

100

150

200

250

300

350

400

450

500W

ake-

up ti

me (

mse

c)

(a)

Concurrent n = 8Concurrent n = 16Sequential

8 162 1 4 Offered Load

0

5

10

15

Wak

e-up

tim

e (m

sec)

(b)

Figure 6 Performance of concurrent polling and sequential polling (a) Average wake-up time of both idle and busy devices (b) Averagewake-up time of busy devices

up after one poll-data frame exchange time to poll and receiveits downlinkThe sameprocedure repeats for succeeding busydevices Equation (5) is the average maximum wake-up timeof a busy device

119882119878119861 = 119905119888 + 119863119887119903119887 + 119863119901

119903119901 + (119905119892 + 119863119889119903119889 ) (5)

Moreover the sum of all wake-up times during a beaconperiod is

(M minus m) ∙ 119882119878119868 + 119898 ∙ 119882119878119861 (6)

5 Comparison of Two Polling Schemes

We compared the two polling methods by varying the valuesof parameters that may affect performance The performancemetric is the average wake-up time required for the receptionof one downlink frame We varied the total number of end-devices (M) in a network the number of downlink messagesper beacon interval and the network capacity for concurrenttransmissions (n) Figure 6 shows the average wake-up timesof concurrent and sequential polling as functions of theoffered loadThe unit of the offered load is the number of newdownlink frames generated per beacon interval Figures 6(a)and 6(b) are the wake-up time of all end-devices includingboth idle and busy devices and the wake-up time of busydevices only respectively When calculating the wake up timeof busy devices only terms (119872minus1198981015840)∙119882119862119868 and (Mminusm)∙119882119878119868 in(4) and (6) are excluded We used two values (n=8 and n=16)of network capacity to analyse the effect of maximum simul-taneous receptions For simplicity we assume that receptionpaths of gateways are ideally utilized as each gateway does notlock on the same packet In both Figures 6(a) and 6(b) we

can observe that sequential polling is more effective in powerconserving than concurrent polling When the offered load issmall the performance differences are not great However asthe offered load increases the gap increases also and at m=16concurrent polling consumes 3 to 22 times more energy thansequential polling in the case of all devices (Figure 6(a))Moreover in the case of busy devices only (Figure 6(b))concurrent polling consumes 55 to 41 times more energythan sequential polling The number of total end-devices isfixed at 1000We performed the same analysis by varying thevalue of M and obtain the similar results

We also can observe that concurrent polling at n=16 isbetter than that at n=8 As n increases the probability of colli-sion decreases Collisions affect the performance in twowaysA device whose poll fails to reach a gateway wastes energybecause it should wait until all downlinks are completedAlso collisions increase the offered load at the followingbeacon period and an inflated load again increases the col-lision probability Generally the wake-up time of all devicesdecreases as the offered load increases up to 4 (Figure 6(a))However as the offered load exceeds network capacity (n)wake-up time increases sharply

Because our analytic study reveals the performance ad-vantage of sequential polling over concurrent polling weadopt sequential polling for our downlink communicationscheme Figure 7 illustrates TRILO in a greater detailBeacon Window is divided into downlink reception timeand uplink transmission time After a beacon busy devicesreceive downlink frames sequentially during downlink timeAfter that nodes transmit uplink messages like plain ClassA devices One problem is that uplink transmissions orthe downlinks responding to uplinks may overlap with thefollowing beacon To avoid the problem the Beacon Guardis introduced end-devices refrain from initiating new uplink

Wireless Communications and Mobile Computing 9

Gateway

End-device A

Time

Beacon period

Beacon

poll

End-device B

downlink

uplink

Downlink Uplink

Beacon window

Figure 7 Proposed downlink communication scheme

(a) (b)

Figure 8 Devices used for implementation (a) End-device with SX1272MB2DAS attached to a NUCLEO-L073RZ board (b) Gateway withRAK831 attached to a Raspberry Pi 3

transmissions if remaining time to the next beacon is lessthan Beacon Guard Note that LoRaWAN standard limitsmaximum payload size so that beacon payload cannotconvey a large number of DevAddrs however it can be easilyextended depending on network conditions by using low SFsor allocating short network addresses

6 Implementation

We implemented TRILO using commercially available com-ponents We built a gateway on a RAK831 board [27] whichcontains an SX1301 concentrator chip The gateway board isattached to a Raspberry Pi 3 board as shown in Figure 8(b)For our implementation we employed the Semtech librarieswhich contain LoRaWAN packet forwarder and hardwareabstraction layer for SX1301

In the LoRaWAN architecture a gateway plays a simplerole of a bridge between end-devices and a network serverand a network server performs all beacon and poll messageprocessings We utilize an open source project [28] targetedfor private LoRaWAN network production in implementinga network server Figure 9 describes the message handlermodules that we implemented The beacon handler creates

a beacon payload consisting of the timestamp and buffereddownlink frame information Then it passes the payload tothe packet processor which assembles the payload into abeacon packet Since a beacon needs to be transmitted ina greater time precision than data packets we modified thegateway such that beacons are transmitted immediately Thepoll handler sends a pending downlink frame in responseto a poll message Note that this mechanism is transparentto the LoRaWAN MAC processor and the application serverbecause we implement modules at the packet processor level

An end-device is implemented on a NUCLEO-L073RZboard with an embedded LoRaWAN chip using a 915Mhzantenna (see Figure 8(a)) We attached the SX1272MB2DAScomponent to a NUCLEO-L073RZ board with the modifiedLoRa MAC Note that end-device logics are compiled andstored as firmware in an end-device Time synchronizationbetween nodes and a network server is based on the localtime of a network server instead of GPS time because weimplemented the beacon handler at the server not using thebeacon frame of the Class B standard We modified the end-devicersquos software by adding the beacon handling and pollingfunctions Note that each device which has a pending framewaits for its turn and processing times of each downlink vary

10 Wireless Communications and Mobile Computing

Packet forwarderGateway Packet

processorLoRaWAN

MAC processor

Applicationserver

PUSH DATA

PULL RESP

Pollhandler

Beaconhandler

Figure 9 Block diagram of a network server that handles beacon and poll messages

Figure 10 Experiment environment One gateway (yellow dot) and 15 end-devices (blue dots) are deployed in our office building

due to different SFs In a downlink period we configuredthe time for each poll and downlink based on SF 12 whichhas the longest airtime However the experimental resultsshow that the proposed scheme can be deployed with highperformance even with the conservative configuration It ispossible to optimize the waiting times for each downlinkmore compactly based on the information about SFs of eachnode however we leave this issue as future work

We tuned radios of the components to obey the Koreanregulation which allocates frequency bands from 920Mhzto 923Mhz for LoRaWAN We also added the listen beforetalk (LBT) function as the regulation specifies Note thatthe current LoRaWAN specifications for the KR920-923 ISMband do not have duty cycle limits but require adopting theLBT channel access rule [4]

7 Experimental Results

We evaluate the performance of TRILO by deploying modi-fied components in our office buildingWeplaced the gatewayand three end-devices in our lab Also we deploy 12 moreend-devices on the same floor of the building as shown inFigure 10 The beacon periods are set to either 128 sec or256 sec We varied the uplink and downlink offered loadsfrom 1 2 4 to 8 frames per beacon period The offered trafficis unrealistically large for such a small network however notethat we are trying to emulate the operating conditions of large

scale LoRAWAN networks consisting of tens of thousandsof end-devices Testbeds of such scale are not available soour experiment emulates large networks with 15 end-devicesUplink and downlink messages should be interpreted as anaggregated traffic generated by thousands of end-devicesMessage interarrival times of uplink and downlink trafficfollow the exponential distribution and the destinations ofdownlink messages are randomly and uniformly selectedWe used primitive Adaptive Data Rate (ADR) for SF andpower allocation and all nodes converged to SF 8 and defaultEIRP output power (14dBm) The performance of real-worldLoRaWAN networks depends on the distributions of SFand transmission power However we ignore these factorsbecause improvement of uplink transmissions is not a goalof this work

The performance metrics used in this study includePacket Delivery Ratio (PDR) duty cycle and latency Toobtain reliable results we repeat experiments with the sameparameter values ten times The length of each experimentrun is 10 beacon periods (ie 1280 or 2560 sec) Becausethe destinations of downlinks and the origins of uplinks arerandomly selected it is expected that all end-devices andmessages experience the average performance

First of all we measure the PDR of uplink and downlinkframes We observe that all downlink frames are deliveredsuccessfully without exception The result is rather surprisingbecause TRILO employs beacon broadcasting and polling

Wireless Communications and Mobile Computing 11

Table 3 Packet delivery ratio of uplink traffic at various uplink anddownlink offered loads

Packet generation rate 120582119889 = 1 120582119889 = 2 120582119889 = 4120582119906 = 2 9864 9827 9772120582119906 = 8 9674 9603 9510

in addition to downlink data frames A failure in any onecomponent may lead to unsuccessful data transmissionsUnlike downlink frames uplink traffic experiences occa-sional transmission failures Wemeasure the PDR by varyingthe offered loads of both uplink and downlink traffic Notethat all nodes use the same SF and collisions occur if framesare transmitted on the same channel simultaneously Table 3illustrates the PDR of uplink traffic at different offered loadsBoth uplink and downlink traffic affect the PDR of uplinktraffic The PDR decreases as the offered load of downlinktraffic increases at 120582119906 = 2 the PDR decreases from 9864to 9772 as the offered load of downlink traffic increasesfrom 1 to 4 In addition the uplink traffic intensity also affectsthe PDR of uplink traffic for example at 120582119889 = 2 the PDRdecreases from 9827 to 9603 as the offered load of uplinktraffic increases from 2 to 8

Note that uplink transmissions are prohibited duringpolling and following downlink frame transmissions Uplinkframes which arrive during downlink operation should waituntil the current downlink operation is completed Thiswaiting procedure synchronizes backlogged end-devices andmay cause collisions Even though the LoRa PHY supportsmultiple simultaneous transmissions of different SFs or chan-nels multiple attempts increase the collision probabilitiesand the PDR decreases as both uplink and downlink trafficincrease To reduce the bloated collisions due to synchronoustransmissions persistent mechanisms such as 0-persistenceor p-persistence are required However persistence schemesincrease the complexity of the network protocol and maycause other side effects such as increased energy consump-tion

Next we assess the additional power consumed fordownlink communications Because gateways operate in analways-on mode we only measure the energy consumed byend-devices We use the duty cycle additional time requiredfor downlink communications as the performance metricThe duty cycle is the sum of wake-up times used for beaconreception for possible poll transmission and for downlinkdata frame receptions Figure 11 shows the average duty cycleat different downlink traffic loadsThe duty cycle increases asthe downlink offered load increases it increases from 075to 11 as 120582119889 increases from 1 to 4 Note that all end-devicesconsume the minimal fixed duty cycle for beacon receptionregardless of the intensity of downlink traffic In addition tothe fixed duty cycle end-devices with backlogged downlinkscontinue to stay in the wake-up state for polling and datareception

Figure 12 illustrates the average latency of downlink trafficand uplink traffic as functions of offered load respectively Asshown in Figure 12(a) the average latency of downlink trafficincreases in proportion to the offered load As explained

0

02

04

06

08

1

12

Dut

y Cy

cle (

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

Figure 11 Duty cycles required for downlink operation includingbeacon poll and downlink data transmissions

before downlink frames are generated according to a Poissonprocess Therefore the probability that a downlink frameoccurs in a small time period follows uniform distributionand on average each downlink frame waits one-half of thebeacon interval In addition frames that arrive during adownlink processing are postponed to the next beacon InFigure 12(a) we can observe that the effect of uplink traffic onthe average latency of downlink is minimal This result is notsurprising because uplink and downlink communications arewell isolated in the proposed scheme

Like the average downlink latency the average uplinklatency increases as the downlink offered load increasesUplink frames that arrive during downlink periods shouldwait until the end of the current downlink periodThe averagelatency of uplink traffic as well as the duty cycle increase asthe downlink offered load increases Contrary to Figure 12(a)where the average downlink latency is seldom affected bythe uplink offered load the average uplink latency increasesproportionally as the uplink offered load increases As theuplink communication demands increase a queue startsto form and this causes the increase in waiting time Thequeueing time is most distinctive at 120582119889 = 4 when the servicetime for uplink communications is minimal

8 Simulation Results

We also compared the performance of the Class B downlinkscheme and that of TRILO Because commercial LoRaWANdevices do not support Class B functions yet we relied oncomputer simulations for the performance comparison Thesimulation code is written primarily in CC++ and we con-duct extensive simulations in a typical LoRaWAN networkand in a heavy downlink traffic condition respectively Tocompare energy consumed for downlink communicationswe define the efficiency of each protocol as a performancemetric The efficiency defined as the ratio of data transmis-sion time to the duty cycle is the fraction of time used foruseful work

12 Wireless Communications and Mobile Computing

Ｏ = 2

Ｏ = 8

70

75

80

85

90

95

100

105D

ownl

ink

Late

ncy

(sec

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

(a)

1

2

3

4

5

6

7

8

Upl

ink

Late

ncy

(sec

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

Ｏ = 2

Ｏ = 8

(b)

Figure 12 Average latency of traffic (a) Downlink latency (b) Uplink latency

Table 4 Notations used for Class B downlink protocol and TRILO

Notation Meaning119863119879 Duty cycle of TRILO119863119861 Duty cycle of the Class B downlink protocol119879119879119861119890119886119888119900119899 Beacon transmission time of TRILO

119879119861119861119890119886119888119900119899 Beacon transmission time of the Class B downlinkprotocol

119879119901119900119897119897 Average poll frame transmission time119879119889119900119908119899 Average downlink frame transmission time119896 Parameter for the Class Brsquos ping slots

119868119864 Indicator function representing a node is backlogged ornot

According to the LoRaWAN standard implementation ofthe Class B downlink scheme discretizes the time into so-called ping slots Each end-device requests 2119896 (0 le 119896 le 7)ping slots per beacon period We use the average case of theClass B where each end-device randomly selects a value ofthe parameter 119896 between 0 and 7 Let us first introduce thenotations for the analysis of LoRaWAN downlink protocol(Table 4)

We used SF 9 for beacon transmissions according to theLoRaWAN specification KR920-923 [29] The duty cycle ofTRILO119863119879 is

119863119879 =119879119879119861119890119886119888119900119899 + 119868119864 sdot (119879119901119900119897119897 + 119879119889119900119908119899)

119861119890119886119888119900119899 119875119890119903119894119900119889 (7)

Note that unlike 119879119861119861119890119886119888119900119899 119879119879119861119890119886119888119900119899 increases in proportion tothe number of busy end-devices The duty cycle of a Class Bdevice 119863119861 is

119863119861 = 119879119861119861119890119886119888119900119899 + 2119896 sdot 119879119889119900119908119899119861119890119886119888119900119899 119875119890119903119894119900119889 (8)

Class B devices have different duty cycles depending onrandomly selected values of parameter 119896 Then the efficiencyis computed as

119864119891119891119894119888119894119890119899119888119910 = 119863119900119908119899119897119894119899119896 119905119903119886119899119904119898119894119904119904119894119900119899 119905119894119898119890119863119906119905119910 119888119910119888119897119890119904 (9)

We measured the efficiency of TRILO and the Class Bdownlink protocol by varying the number of nodes from 50to 4000 and the downlink offered load from 2 to 32 framesper beacon period Each performance point is the average of10000 runs We limit the maximum downlink traffic to 32frames per beacon interval because uplink traffic is greaterthan downlink traffic in many LoRaWAN applications Notethat at 120582119889 = 32 about a half of beacon period is consumed fordownlink communications if we assume that the downlinktransmission time is 2 seconds on average

The efficiency of each scheme is shown in Figure 13Note that the offered load is aggregated load and the trafficintensity of individual node decreases as the number of nodesincreases The total times for downlink communications arefixed at each given offered load However the sum of dutycycles increases as the number of nodes increases Thereforein both protocols the maximum efficiencies are realized atsmall networks and the efficiency decreases as the networksize increases The results illustrate that efficiencies of TRILOare higher than those of the Class B downlink protocolthroughout all downlink generation ratesTheClass B schemeperforms well in heavy traffic cases However the proposedscheme outperforms the Class B scheme even in heavy trafficconditions In small networks the performance gap decreasesfrom about 139 times to about 33 times as 120582119889 increases from2 to 32 Also each gap in each offered load increases as thenetwork size increases In the case of TRILO the averageduty cycle decreases inversely proportional to the number ofnodes because only busy devices are active during downlink

Wireless Communications and Mobile Computing 13

Number of Nodes500 1000 1500 2000 2500 3000 3500 4000

10minus3

10minus2

Effici

ency

10minus1

100

101

Class B (＞ = 2)

Proposed (＞ = 2)

Class B (＞ = 8)

Proposed (＞ = 8)

Class B (＞ = 32)

Proposed (＞ = 32)

Figure 13 Efficiency of TRILO and Class B downlink protocol

periods On the contrary Class B protocol allocates 31 pingslots on average regardless of downlink demands In shortthe number of receive windows wasted by the Class B schemevaries depending on the amount of downlink traffic howeveronly busy devices use extra duty cycle for downlink traffic inTRILO

The Class B protocol does not coordinate traffic betweenuplinks and downlinks so that several uplinks can be dis-rupted by downlink transmissions due to the half-duplexcharacteristic of a LoRaWAN gateway all reception pathscan be blocked by downlink transmissions It can obstructthe proper operations of typical LoRaWANs where uplinktransmissions are predominant In contrast the proposedscheme is free from this problem because it isolates the timefor uplinks and downlinks periods

9 Conclusions

A plethora of LPWAN techniques such as LoRa SigFoxRPMA and Weightless have emerged as a new enablingnetwork technology for IoT applications that require low-rate low-cost and long lifetimes LPWANs allow end-deviceinitiated uplinks However to maximize the lifetime ofbattery powered end-devices nodes are put into the sleepstate such that rather restricted downlink communicationsare permitted In this paper we proposed a new downlinkprotocol named TRILO for LoRaWAN

Because LoRaWAN assumes a star topology where mul-tiple end-devices are connected to a single gateway weadopted a beacon based downlink mechanism similar to theIEEE 80211 PSM standard A gateway broadcast beaconsperiodically at every beacon period and end-devices are timesynchronized Beacons alert nodes with buffered downlinksin addition to synchronizing end-devicesrsquo clocks Customizedto the physical characteristics of LoRa we designed two

polling schemes concurrent polling and sequential pollingAn analysis indicates that sequential polling is more energyefficient than concurrent polling

We implement the proposed beacon based downlinkprotocol using commercially available components and con-duct experiments with modified devices Our performancestudy shows that Packet Delivery Ratio (PDR) is almost100 for both uplink and downlink traffic and the extrawake-up time to receive beacons and downlinks is minimalSimulation results also show that our proposed protocol canadaptively allocate receive windows resulting in lower energyconsumption

For further work we plan to investigate the impact ofour scheme on the networks with multiple gateways Alsodetailed investigations of impact of the number of downlinksand the certain distributions of SFs on the performanceseem interesting Optimization techniques leveraging SF andpower allocation are expected to affect the performance of theproposed scheme

Data Availability

The data used to support the findings of this study areincluded within the article

Disclosure

The funding sponsors had no role in the study in thecollection analyses or interpretation of data in the writingof the manuscript and in the decision to publish the results

Conflicts of Interest

The authors declare that there are no conflicts of interestregarding the publication of this paper

14 Wireless Communications and Mobile Computing

Acknowledgments

This work was supported by the National Research Founda-tion of Korea (NRF) Grant funded by the Korean Govern-ment (MSIP) (No 2016R1A5A1012966) Institute for Infor-mation amp Communications Technology Promotion (IITP)grant funded by the Korea government (MSIT) (No 2015-0-00557 ResilientFault-Tolerant Autonomic NetworkingBased on Physicality Relationship and Service Semantic ofIoT Devices) and the MSIP (Ministry of Science ICT andFuture Planning) Korea under the ITRC (Information Tech-nology Research Center) support program (IITP-2018-2015-0-00378) supervised by the IITP (Institute for Informationamp Communications Technology Promotion) Also the snu-samsung smart campus research center at Seoul NationalUniversity provides research facilities for this study

References

[1] M Bor U Roedig T Voigt and J M Alonso ldquoDo LoRalow-power wide-area networks scalerdquo in Proceedings of the19th ACM International Conference on Modeling Analysis andSimulation of Wireless and Mobile Systems MSWiM 2016 pp59ndash67 Malta November 2016

[2] DMagrinMCentenaro andLVangelista ldquoPerformance eval-uation of LoRa networks in a smart city scenariordquo inProceedingsof the 2017 IEEE International Conference on CommunicationsICC 2017 France May 2017

[3] LoRa httpswwwlora-allianceorgWhat-Is-LoRaTechnol-ogy

[4] ldquoLoRaWAN 11 specificationrdquo LoRa Alliance 2017 httpslora-allianceorgresource-hublorawantm-specification-v11

[5] M Bor J Vidler and U Roedig ldquoLoRa for the internet ofthingsrdquo in Proceedings of the International Conference onEmbedded Wireless Systems and Networks (EWSN rsquo16) pp 361ndash366 Junction Publishing 2016

[6] 3GPP ldquoStudy on provision of low-cost Machine-Type Commu-nications User Equipments based on LTErdquo TR 36888 V120006 2013

[7] 3GPP ldquoCellular system support for ultra-low complexity andlow throughput Internet of Thingsrdquo TR 45820 V1310 11 2015

[8] J Gozalvez ldquoNew 3GPP Standard for IoTrdquo IEEE VehicularTechnology Magazine vol 11 no 1 pp 14ndash20 2016

[9] R Ratasuk N Mangalvedhe and A Ghosh ldquoOverview ofLTE enhancements for cellular IoTrdquo in Proceedings of the 26thIEEE Annual International Symposium on Personal Indoor andMobile Radio Communications PIMRC 2015 pp 2293ndash2297China September 2015

[10] H Shariatmadari R Ratasuk S Iraji et al ldquoMachine-type com-munications current status and future perspectives toward 5Gsystemsrdquo IEEE CommunicationsMagazine vol 53 no 9 pp 10ndash17 2015

[11] S Landstrom J Bergstrom E Westerberg and D Hammar-wall ldquoNBIoT a sustainable technology for connecting billionsof devicesrdquo Ericsson Technology Review vol 4 pp 2ndash11 2016

[12] M Lauridsen I Z Kovacs P Mogensen M Sorensen andS Holst ldquoCoverage and capacity analysis of LTE-M and NB-IoT in a rural areardquo in Proceedings of the 2016 IEEE 84thVehicular Technology Conference (VTC-Fall) pp 1ndash5 MontrealQC Canada September 2016

[13] Sigfox httpwwwsigfoxcom[14] Weightless open standard httpwwwweightlessorg[15] Ingenu RPMA httpwwwingenucomtechnologyrpma[16] A Dunkels ldquoThe ContikiMAC radio duty cycling protocolrdquo

Technical Report T201113 Swedish Institute of ComputerScience 2011

[17] J Ko J Eriksson N Tsiftes et al ldquoIndustry Beyond interoper-ability - Pushing the performance of sensor network IP stacksrdquoin Proceedings of the 9th ACM Conference on Embedded Net-worked Sensor Systems SenSys 2011 pp 1ndash11 USA November2011

[18] D Moss J Hui and K Klues ldquoTEP 105 low power listeningrdquohttpwwwtinyosnettinyos-2xdocpdftep105pdf 2008

[19] C Gomez J Oller and J Paradells ldquoOverview and evaluationof bluetooth low energy an emerging low-power wirelesstechnologyrdquo Sensors vol 12 no 9 pp 11734ndash11753 2012

[20] A A Kandhalu A E Xhafa and S Hosur ldquoTowards bounded-latency bluetooth low energy for in-vehicle network cablereplacementrdquo in Proceeding of the International Conference onConnected Vehicles and Expo (ICCVE) pp 635ndash640 Las VegasNV USA 2013

[21] A Montanari S Nawaz C Mascolo and K Sailer ldquoA studyof bluetooth low energy performance for human proximitydetection in the workplacerdquo in Proceedings of the 2017 IEEEInternational Conference on Pervasive Computing and Commu-nications PerCom 2017 pp 90ndash99 Kona HI USA March 2017

[22] C Julien C Liu A L Murphy and G P Picco ldquoBLEnd Practi-cal continuous neighbor discovery for bluetooth low energyrdquo inProceedings of the 16th ACMIEEE International Conference onInformation Processing in Sensor Networks IPSN 2017 pp 105ndash116 New York NY USA April 2017

[23] Y Qiu S Li X Xu and Z Li ldquoTalk more listen less energy-efficient neighbor discovery in wireless sensor networksrdquo inProceedings of the 35th Annual IEEE International Conference onComputer Communications IEEE INFOCOM 2016 USA April2016

[24] A J Berni andW D Gregg ldquoOn the utility of chirpmodulationfor digital signalingrdquo IEEE Transactions on Communicationsvol 21 no 6 pp 748ndash751 1973

[25] A Springer W Gugler M Huemer L Reindl C C W Ruppeland R Weigel ldquoSpread spectrum communications using chirpsignalsrdquo in Proceedings of the IEEEAFCEA Information Systemsfor Enhanced Public Safety and Security EUROCOMM2000 pp166ndash170 Germany

[26] IEEE Std 80211-2007 ldquoIEEE Standard for Information Tech-nologymdashTelecommunications and Information Exchange be-tween SystemsmdashLocal and Metropolitan Area NetworksmdashSpecific Requirements Part 11 Wireless LAN Medium AccessControl (MAC) and Physical Layer (PHY) Specifications June2007rdquo

[27] RAK831 httpwwwrakwirelesscomenWisKeyOSHRAK831[28] LoRaWAN network server httpsgithubcomgotthardplor-

awan-server[29] ldquoLoRaWAN 11 Regional Parametersrdquo LoRa Alliance 2017

httpslora-allianceorgresource-hublorawantm-regional-pa-rameters-v11ra

Wireless Communications and Mobile Computing 9

Gateway

End-device A

Time

Beacon period

Beacon

poll

End-device B

downlink

uplink

Downlink Uplink

Beacon window

Figure 7 Proposed downlink communication scheme

(a) (b)

Figure 8 Devices used for implementation (a) End-device with SX1272MB2DAS attached to a NUCLEO-L073RZ board (b) Gateway withRAK831 attached to a Raspberry Pi 3

transmissions if remaining time to the next beacon is lessthan Beacon Guard Note that LoRaWAN standard limitsmaximum payload size so that beacon payload cannotconvey a large number of DevAddrs however it can be easilyextended depending on network conditions by using low SFsor allocating short network addresses

6 Implementation

We implemented TRILO using commercially available com-ponents We built a gateway on a RAK831 board [27] whichcontains an SX1301 concentrator chip The gateway board isattached to a Raspberry Pi 3 board as shown in Figure 8(b)For our implementation we employed the Semtech librarieswhich contain LoRaWAN packet forwarder and hardwareabstraction layer for SX1301

In the LoRaWAN architecture a gateway plays a simplerole of a bridge between end-devices and a network serverand a network server performs all beacon and poll messageprocessings We utilize an open source project [28] targetedfor private LoRaWAN network production in implementinga network server Figure 9 describes the message handlermodules that we implemented The beacon handler creates

a beacon payload consisting of the timestamp and buffereddownlink frame information Then it passes the payload tothe packet processor which assembles the payload into abeacon packet Since a beacon needs to be transmitted ina greater time precision than data packets we modified thegateway such that beacons are transmitted immediately Thepoll handler sends a pending downlink frame in responseto a poll message Note that this mechanism is transparentto the LoRaWAN MAC processor and the application serverbecause we implement modules at the packet processor level

An end-device is implemented on a NUCLEO-L073RZboard with an embedded LoRaWAN chip using a 915Mhzantenna (see Figure 8(a)) We attached the SX1272MB2DAScomponent to a NUCLEO-L073RZ board with the modifiedLoRa MAC Note that end-device logics are compiled andstored as firmware in an end-device Time synchronizationbetween nodes and a network server is based on the localtime of a network server instead of GPS time because weimplemented the beacon handler at the server not using thebeacon frame of the Class B standard We modified the end-devicersquos software by adding the beacon handling and pollingfunctions Note that each device which has a pending framewaits for its turn and processing times of each downlink vary

10 Wireless Communications and Mobile Computing

Packet forwarderGateway Packet

processorLoRaWAN

MAC processor

Applicationserver

PUSH DATA

PULL RESP

Pollhandler

Beaconhandler

Figure 9 Block diagram of a network server that handles beacon and poll messages

Figure 10 Experiment environment One gateway (yellow dot) and 15 end-devices (blue dots) are deployed in our office building

due to different SFs In a downlink period we configuredthe time for each poll and downlink based on SF 12 whichhas the longest airtime However the experimental resultsshow that the proposed scheme can be deployed with highperformance even with the conservative configuration It ispossible to optimize the waiting times for each downlinkmore compactly based on the information about SFs of eachnode however we leave this issue as future work

We tuned radios of the components to obey the Koreanregulation which allocates frequency bands from 920Mhzto 923Mhz for LoRaWAN We also added the listen beforetalk (LBT) function as the regulation specifies Note thatthe current LoRaWAN specifications for the KR920-923 ISMband do not have duty cycle limits but require adopting theLBT channel access rule [4]

7 Experimental Results

We evaluate the performance of TRILO by deploying modi-fied components in our office buildingWeplaced the gatewayand three end-devices in our lab Also we deploy 12 moreend-devices on the same floor of the building as shown inFigure 10 The beacon periods are set to either 128 sec or256 sec We varied the uplink and downlink offered loadsfrom 1 2 4 to 8 frames per beacon period The offered trafficis unrealistically large for such a small network however notethat we are trying to emulate the operating conditions of large

scale LoRAWAN networks consisting of tens of thousandsof end-devices Testbeds of such scale are not available soour experiment emulates large networks with 15 end-devicesUplink and downlink messages should be interpreted as anaggregated traffic generated by thousands of end-devicesMessage interarrival times of uplink and downlink trafficfollow the exponential distribution and the destinations ofdownlink messages are randomly and uniformly selectedWe used primitive Adaptive Data Rate (ADR) for SF andpower allocation and all nodes converged to SF 8 and defaultEIRP output power (14dBm) The performance of real-worldLoRaWAN networks depends on the distributions of SFand transmission power However we ignore these factorsbecause improvement of uplink transmissions is not a goalof this work

The performance metrics used in this study includePacket Delivery Ratio (PDR) duty cycle and latency Toobtain reliable results we repeat experiments with the sameparameter values ten times The length of each experimentrun is 10 beacon periods (ie 1280 or 2560 sec) Becausethe destinations of downlinks and the origins of uplinks arerandomly selected it is expected that all end-devices andmessages experience the average performance

First of all we measure the PDR of uplink and downlinkframes We observe that all downlink frames are deliveredsuccessfully without exception The result is rather surprisingbecause TRILO employs beacon broadcasting and polling

Wireless Communications and Mobile Computing 11

Table 3 Packet delivery ratio of uplink traffic at various uplink anddownlink offered loads

Packet generation rate 120582119889 = 1 120582119889 = 2 120582119889 = 4120582119906 = 2 9864 9827 9772120582119906 = 8 9674 9603 9510

in addition to downlink data frames A failure in any onecomponent may lead to unsuccessful data transmissionsUnlike downlink frames uplink traffic experiences occa-sional transmission failures Wemeasure the PDR by varyingthe offered loads of both uplink and downlink traffic Notethat all nodes use the same SF and collisions occur if framesare transmitted on the same channel simultaneously Table 3illustrates the PDR of uplink traffic at different offered loadsBoth uplink and downlink traffic affect the PDR of uplinktraffic The PDR decreases as the offered load of downlinktraffic increases at 120582119906 = 2 the PDR decreases from 9864to 9772 as the offered load of downlink traffic increasesfrom 1 to 4 In addition the uplink traffic intensity also affectsthe PDR of uplink traffic for example at 120582119889 = 2 the PDRdecreases from 9827 to 9603 as the offered load of uplinktraffic increases from 2 to 8

Note that uplink transmissions are prohibited duringpolling and following downlink frame transmissions Uplinkframes which arrive during downlink operation should waituntil the current downlink operation is completed Thiswaiting procedure synchronizes backlogged end-devices andmay cause collisions Even though the LoRa PHY supportsmultiple simultaneous transmissions of different SFs or chan-nels multiple attempts increase the collision probabilitiesand the PDR decreases as both uplink and downlink trafficincrease To reduce the bloated collisions due to synchronoustransmissions persistent mechanisms such as 0-persistenceor p-persistence are required However persistence schemesincrease the complexity of the network protocol and maycause other side effects such as increased energy consump-tion

Next we assess the additional power consumed fordownlink communications Because gateways operate in analways-on mode we only measure the energy consumed byend-devices We use the duty cycle additional time requiredfor downlink communications as the performance metricThe duty cycle is the sum of wake-up times used for beaconreception for possible poll transmission and for downlinkdata frame receptions Figure 11 shows the average duty cycleat different downlink traffic loadsThe duty cycle increases asthe downlink offered load increases it increases from 075to 11 as 120582119889 increases from 1 to 4 Note that all end-devicesconsume the minimal fixed duty cycle for beacon receptionregardless of the intensity of downlink traffic In addition tothe fixed duty cycle end-devices with backlogged downlinkscontinue to stay in the wake-up state for polling and datareception

Figure 12 illustrates the average latency of downlink trafficand uplink traffic as functions of offered load respectively Asshown in Figure 12(a) the average latency of downlink trafficincreases in proportion to the offered load As explained

0

02

04

06

08

1

12

Dut

y Cy

cle (

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

Figure 11 Duty cycles required for downlink operation includingbeacon poll and downlink data transmissions

before downlink frames are generated according to a Poissonprocess Therefore the probability that a downlink frameoccurs in a small time period follows uniform distributionand on average each downlink frame waits one-half of thebeacon interval In addition frames that arrive during adownlink processing are postponed to the next beacon InFigure 12(a) we can observe that the effect of uplink traffic onthe average latency of downlink is minimal This result is notsurprising because uplink and downlink communications arewell isolated in the proposed scheme

Like the average downlink latency the average uplinklatency increases as the downlink offered load increasesUplink frames that arrive during downlink periods shouldwait until the end of the current downlink periodThe averagelatency of uplink traffic as well as the duty cycle increase asthe downlink offered load increases Contrary to Figure 12(a)where the average downlink latency is seldom affected bythe uplink offered load the average uplink latency increasesproportionally as the uplink offered load increases As theuplink communication demands increase a queue startsto form and this causes the increase in waiting time Thequeueing time is most distinctive at 120582119889 = 4 when the servicetime for uplink communications is minimal

8 Simulation Results

We also compared the performance of the Class B downlinkscheme and that of TRILO Because commercial LoRaWANdevices do not support Class B functions yet we relied oncomputer simulations for the performance comparison Thesimulation code is written primarily in CC++ and we con-duct extensive simulations in a typical LoRaWAN networkand in a heavy downlink traffic condition respectively Tocompare energy consumed for downlink communicationswe define the efficiency of each protocol as a performancemetric The efficiency defined as the ratio of data transmis-sion time to the duty cycle is the fraction of time used foruseful work

12 Wireless Communications and Mobile Computing

Ｏ = 2

Ｏ = 8

70

75

80

85

90

95

100

105D

ownl

ink

Late

ncy

(sec

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

(a)

1

2

3

4

5

6

7

8

Upl

ink

Late

ncy

(sec

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

Ｏ = 2

Ｏ = 8

(b)

Figure 12 Average latency of traffic (a) Downlink latency (b) Uplink latency

Table 4 Notations used for Class B downlink protocol and TRILO

Notation Meaning119863119879 Duty cycle of TRILO119863119861 Duty cycle of the Class B downlink protocol119879119879119861119890119886119888119900119899 Beacon transmission time of TRILO

119879119861119861119890119886119888119900119899 Beacon transmission time of the Class B downlinkprotocol

119879119901119900119897119897 Average poll frame transmission time119879119889119900119908119899 Average downlink frame transmission time119896 Parameter for the Class Brsquos ping slots

119868119864 Indicator function representing a node is backlogged ornot

According to the LoRaWAN standard implementation ofthe Class B downlink scheme discretizes the time into so-called ping slots Each end-device requests 2119896 (0 le 119896 le 7)ping slots per beacon period We use the average case of theClass B where each end-device randomly selects a value ofthe parameter 119896 between 0 and 7 Let us first introduce thenotations for the analysis of LoRaWAN downlink protocol(Table 4)

We used SF 9 for beacon transmissions according to theLoRaWAN specification KR920-923 [29] The duty cycle ofTRILO119863119879 is

119863119879 =119879119879119861119890119886119888119900119899 + 119868119864 sdot (119879119901119900119897119897 + 119879119889119900119908119899)

119861119890119886119888119900119899 119875119890119903119894119900119889 (7)

Note that unlike 119879119861119861119890119886119888119900119899 119879119879119861119890119886119888119900119899 increases in proportion tothe number of busy end-devices The duty cycle of a Class Bdevice 119863119861 is

119863119861 = 119879119861119861119890119886119888119900119899 + 2119896 sdot 119879119889119900119908119899119861119890119886119888119900119899 119875119890119903119894119900119889 (8)

Class B devices have different duty cycles depending onrandomly selected values of parameter 119896 Then the efficiencyis computed as

119864119891119891119894119888119894119890119899119888119910 = 119863119900119908119899119897119894119899119896 119905119903119886119899119904119898119894119904119904119894119900119899 119905119894119898119890119863119906119905119910 119888119910119888119897119890119904 (9)

We measured the efficiency of TRILO and the Class Bdownlink protocol by varying the number of nodes from 50to 4000 and the downlink offered load from 2 to 32 framesper beacon period Each performance point is the average of10000 runs We limit the maximum downlink traffic to 32frames per beacon interval because uplink traffic is greaterthan downlink traffic in many LoRaWAN applications Notethat at 120582119889 = 32 about a half of beacon period is consumed fordownlink communications if we assume that the downlinktransmission time is 2 seconds on average

The efficiency of each scheme is shown in Figure 13Note that the offered load is aggregated load and the trafficintensity of individual node decreases as the number of nodesincreases The total times for downlink communications arefixed at each given offered load However the sum of dutycycles increases as the number of nodes increases Thereforein both protocols the maximum efficiencies are realized atsmall networks and the efficiency decreases as the networksize increases The results illustrate that efficiencies of TRILOare higher than those of the Class B downlink protocolthroughout all downlink generation ratesTheClass B schemeperforms well in heavy traffic cases However the proposedscheme outperforms the Class B scheme even in heavy trafficconditions In small networks the performance gap decreasesfrom about 139 times to about 33 times as 120582119889 increases from2 to 32 Also each gap in each offered load increases as thenetwork size increases In the case of TRILO the averageduty cycle decreases inversely proportional to the number ofnodes because only busy devices are active during downlink

Wireless Communications and Mobile Computing 13

Number of Nodes500 1000 1500 2000 2500 3000 3500 4000

10minus3

10minus2

Effici

ency

10minus1

100

101

Class B (＞ = 2)

Proposed (＞ = 2)

Class B (＞ = 8)

Proposed (＞ = 8)

Class B (＞ = 32)

Proposed (＞ = 32)

Figure 13 Efficiency of TRILO and Class B downlink protocol

periods On the contrary Class B protocol allocates 31 pingslots on average regardless of downlink demands In shortthe number of receive windows wasted by the Class B schemevaries depending on the amount of downlink traffic howeveronly busy devices use extra duty cycle for downlink traffic inTRILO

The Class B protocol does not coordinate traffic betweenuplinks and downlinks so that several uplinks can be dis-rupted by downlink transmissions due to the half-duplexcharacteristic of a LoRaWAN gateway all reception pathscan be blocked by downlink transmissions It can obstructthe proper operations of typical LoRaWANs where uplinktransmissions are predominant In contrast the proposedscheme is free from this problem because it isolates the timefor uplinks and downlinks periods

9 Conclusions

A plethora of LPWAN techniques such as LoRa SigFoxRPMA and Weightless have emerged as a new enablingnetwork technology for IoT applications that require low-rate low-cost and long lifetimes LPWANs allow end-deviceinitiated uplinks However to maximize the lifetime ofbattery powered end-devices nodes are put into the sleepstate such that rather restricted downlink communicationsare permitted In this paper we proposed a new downlinkprotocol named TRILO for LoRaWAN

Because LoRaWAN assumes a star topology where mul-tiple end-devices are connected to a single gateway weadopted a beacon based downlink mechanism similar to theIEEE 80211 PSM standard A gateway broadcast beaconsperiodically at every beacon period and end-devices are timesynchronized Beacons alert nodes with buffered downlinksin addition to synchronizing end-devicesrsquo clocks Customizedto the physical characteristics of LoRa we designed two

polling schemes concurrent polling and sequential pollingAn analysis indicates that sequential polling is more energyefficient than concurrent polling

We implement the proposed beacon based downlinkprotocol using commercially available components and con-duct experiments with modified devices Our performancestudy shows that Packet Delivery Ratio (PDR) is almost100 for both uplink and downlink traffic and the extrawake-up time to receive beacons and downlinks is minimalSimulation results also show that our proposed protocol canadaptively allocate receive windows resulting in lower energyconsumption

For further work we plan to investigate the impact ofour scheme on the networks with multiple gateways Alsodetailed investigations of impact of the number of downlinksand the certain distributions of SFs on the performanceseem interesting Optimization techniques leveraging SF andpower allocation are expected to affect the performance of theproposed scheme

Data Availability

The data used to support the findings of this study areincluded within the article

Disclosure

The funding sponsors had no role in the study in thecollection analyses or interpretation of data in the writingof the manuscript and in the decision to publish the results

Conflicts of Interest

The authors declare that there are no conflicts of interestregarding the publication of this paper

14 Wireless Communications and Mobile Computing

Acknowledgments

This work was supported by the National Research Founda-tion of Korea (NRF) Grant funded by the Korean Govern-ment (MSIP) (No 2016R1A5A1012966) Institute for Infor-mation amp Communications Technology Promotion (IITP)grant funded by the Korea government (MSIT) (No 2015-0-00557 ResilientFault-Tolerant Autonomic NetworkingBased on Physicality Relationship and Service Semantic ofIoT Devices) and the MSIP (Ministry of Science ICT andFuture Planning) Korea under the ITRC (Information Tech-nology Research Center) support program (IITP-2018-2015-0-00378) supervised by the IITP (Institute for Informationamp Communications Technology Promotion) Also the snu-samsung smart campus research center at Seoul NationalUniversity provides research facilities for this study

References

[1] M Bor U Roedig T Voigt and J M Alonso ldquoDo LoRalow-power wide-area networks scalerdquo in Proceedings of the19th ACM International Conference on Modeling Analysis andSimulation of Wireless and Mobile Systems MSWiM 2016 pp59ndash67 Malta November 2016

[2] DMagrinMCentenaro andLVangelista ldquoPerformance eval-uation of LoRa networks in a smart city scenariordquo inProceedingsof the 2017 IEEE International Conference on CommunicationsICC 2017 France May 2017

[3] LoRa httpswwwlora-allianceorgWhat-Is-LoRaTechnol-ogy

[4] ldquoLoRaWAN 11 specificationrdquo LoRa Alliance 2017 httpslora-allianceorgresource-hublorawantm-specification-v11

[5] M Bor J Vidler and U Roedig ldquoLoRa for the internet ofthingsrdquo in Proceedings of the International Conference onEmbedded Wireless Systems and Networks (EWSN rsquo16) pp 361ndash366 Junction Publishing 2016

[6] 3GPP ldquoStudy on provision of low-cost Machine-Type Commu-nications User Equipments based on LTErdquo TR 36888 V120006 2013

[7] 3GPP ldquoCellular system support for ultra-low complexity andlow throughput Internet of Thingsrdquo TR 45820 V1310 11 2015

[8] J Gozalvez ldquoNew 3GPP Standard for IoTrdquo IEEE VehicularTechnology Magazine vol 11 no 1 pp 14ndash20 2016

[9] R Ratasuk N Mangalvedhe and A Ghosh ldquoOverview ofLTE enhancements for cellular IoTrdquo in Proceedings of the 26thIEEE Annual International Symposium on Personal Indoor andMobile Radio Communications PIMRC 2015 pp 2293ndash2297China September 2015

[10] H Shariatmadari R Ratasuk S Iraji et al ldquoMachine-type com-munications current status and future perspectives toward 5Gsystemsrdquo IEEE CommunicationsMagazine vol 53 no 9 pp 10ndash17 2015

[11] S Landstrom J Bergstrom E Westerberg and D Hammar-wall ldquoNBIoT a sustainable technology for connecting billionsof devicesrdquo Ericsson Technology Review vol 4 pp 2ndash11 2016

[12] M Lauridsen I Z Kovacs P Mogensen M Sorensen andS Holst ldquoCoverage and capacity analysis of LTE-M and NB-IoT in a rural areardquo in Proceedings of the 2016 IEEE 84thVehicular Technology Conference (VTC-Fall) pp 1ndash5 MontrealQC Canada September 2016

[13] Sigfox httpwwwsigfoxcom[14] Weightless open standard httpwwwweightlessorg[15] Ingenu RPMA httpwwwingenucomtechnologyrpma[16] A Dunkels ldquoThe ContikiMAC radio duty cycling protocolrdquo

Technical Report T201113 Swedish Institute of ComputerScience 2011

[17] J Ko J Eriksson N Tsiftes et al ldquoIndustry Beyond interoper-ability - Pushing the performance of sensor network IP stacksrdquoin Proceedings of the 9th ACM Conference on Embedded Net-worked Sensor Systems SenSys 2011 pp 1ndash11 USA November2011

[18] D Moss J Hui and K Klues ldquoTEP 105 low power listeningrdquohttpwwwtinyosnettinyos-2xdocpdftep105pdf 2008

[19] C Gomez J Oller and J Paradells ldquoOverview and evaluationof bluetooth low energy an emerging low-power wirelesstechnologyrdquo Sensors vol 12 no 9 pp 11734ndash11753 2012

[20] A A Kandhalu A E Xhafa and S Hosur ldquoTowards bounded-latency bluetooth low energy for in-vehicle network cablereplacementrdquo in Proceeding of the International Conference onConnected Vehicles and Expo (ICCVE) pp 635ndash640 Las VegasNV USA 2013

[21] A Montanari S Nawaz C Mascolo and K Sailer ldquoA studyof bluetooth low energy performance for human proximitydetection in the workplacerdquo in Proceedings of the 2017 IEEEInternational Conference on Pervasive Computing and Commu-nications PerCom 2017 pp 90ndash99 Kona HI USA March 2017

[22] C Julien C Liu A L Murphy and G P Picco ldquoBLEnd Practi-cal continuous neighbor discovery for bluetooth low energyrdquo inProceedings of the 16th ACMIEEE International Conference onInformation Processing in Sensor Networks IPSN 2017 pp 105ndash116 New York NY USA April 2017

[23] Y Qiu S Li X Xu and Z Li ldquoTalk more listen less energy-efficient neighbor discovery in wireless sensor networksrdquo inProceedings of the 35th Annual IEEE International Conference onComputer Communications IEEE INFOCOM 2016 USA April2016

[24] A J Berni andW D Gregg ldquoOn the utility of chirpmodulationfor digital signalingrdquo IEEE Transactions on Communicationsvol 21 no 6 pp 748ndash751 1973

[25] A Springer W Gugler M Huemer L Reindl C C W Ruppeland R Weigel ldquoSpread spectrum communications using chirpsignalsrdquo in Proceedings of the IEEEAFCEA Information Systemsfor Enhanced Public Safety and Security EUROCOMM2000 pp166ndash170 Germany

[26] IEEE Std 80211-2007 ldquoIEEE Standard for Information Tech-nologymdashTelecommunications and Information Exchange be-tween SystemsmdashLocal and Metropolitan Area NetworksmdashSpecific Requirements Part 11 Wireless LAN Medium AccessControl (MAC) and Physical Layer (PHY) Specifications June2007rdquo

[27] RAK831 httpwwwrakwirelesscomenWisKeyOSHRAK831[28] LoRaWAN network server httpsgithubcomgotthardplor-

awan-server[29] ldquoLoRaWAN 11 Regional Parametersrdquo LoRa Alliance 2017

httpslora-allianceorgresource-hublorawantm-regional-pa-rameters-v11ra

10 Wireless Communications and Mobile Computing

Packet forwarderGateway Packet

processorLoRaWAN

MAC processor

Applicationserver

PUSH DATA

PULL RESP

Pollhandler

Beaconhandler

Figure 9 Block diagram of a network server that handles beacon and poll messages

Figure 10 Experiment environment One gateway (yellow dot) and 15 end-devices (blue dots) are deployed in our office building

due to different SFs In a downlink period we configuredthe time for each poll and downlink based on SF 12 whichhas the longest airtime However the experimental resultsshow that the proposed scheme can be deployed with highperformance even with the conservative configuration It ispossible to optimize the waiting times for each downlinkmore compactly based on the information about SFs of eachnode however we leave this issue as future work

We tuned radios of the components to obey the Koreanregulation which allocates frequency bands from 920Mhzto 923Mhz for LoRaWAN We also added the listen beforetalk (LBT) function as the regulation specifies Note thatthe current LoRaWAN specifications for the KR920-923 ISMband do not have duty cycle limits but require adopting theLBT channel access rule [4]

7 Experimental Results

We evaluate the performance of TRILO by deploying modi-fied components in our office buildingWeplaced the gatewayand three end-devices in our lab Also we deploy 12 moreend-devices on the same floor of the building as shown inFigure 10 The beacon periods are set to either 128 sec or256 sec We varied the uplink and downlink offered loadsfrom 1 2 4 to 8 frames per beacon period The offered trafficis unrealistically large for such a small network however notethat we are trying to emulate the operating conditions of large

scale LoRAWAN networks consisting of tens of thousandsof end-devices Testbeds of such scale are not available soour experiment emulates large networks with 15 end-devicesUplink and downlink messages should be interpreted as anaggregated traffic generated by thousands of end-devicesMessage interarrival times of uplink and downlink trafficfollow the exponential distribution and the destinations ofdownlink messages are randomly and uniformly selectedWe used primitive Adaptive Data Rate (ADR) for SF andpower allocation and all nodes converged to SF 8 and defaultEIRP output power (14dBm) The performance of real-worldLoRaWAN networks depends on the distributions of SFand transmission power However we ignore these factorsbecause improvement of uplink transmissions is not a goalof this work

The performance metrics used in this study includePacket Delivery Ratio (PDR) duty cycle and latency Toobtain reliable results we repeat experiments with the sameparameter values ten times The length of each experimentrun is 10 beacon periods (ie 1280 or 2560 sec) Becausethe destinations of downlinks and the origins of uplinks arerandomly selected it is expected that all end-devices andmessages experience the average performance

First of all we measure the PDR of uplink and downlinkframes We observe that all downlink frames are deliveredsuccessfully without exception The result is rather surprisingbecause TRILO employs beacon broadcasting and polling

Wireless Communications and Mobile Computing 11

Table 3 Packet delivery ratio of uplink traffic at various uplink anddownlink offered loads

Packet generation rate 120582119889 = 1 120582119889 = 2 120582119889 = 4120582119906 = 2 9864 9827 9772120582119906 = 8 9674 9603 9510

in addition to downlink data frames A failure in any onecomponent may lead to unsuccessful data transmissionsUnlike downlink frames uplink traffic experiences occa-sional transmission failures Wemeasure the PDR by varyingthe offered loads of both uplink and downlink traffic Notethat all nodes use the same SF and collisions occur if framesare transmitted on the same channel simultaneously Table 3illustrates the PDR of uplink traffic at different offered loadsBoth uplink and downlink traffic affect the PDR of uplinktraffic The PDR decreases as the offered load of downlinktraffic increases at 120582119906 = 2 the PDR decreases from 9864to 9772 as the offered load of downlink traffic increasesfrom 1 to 4 In addition the uplink traffic intensity also affectsthe PDR of uplink traffic for example at 120582119889 = 2 the PDRdecreases from 9827 to 9603 as the offered load of uplinktraffic increases from 2 to 8

Note that uplink transmissions are prohibited duringpolling and following downlink frame transmissions Uplinkframes which arrive during downlink operation should waituntil the current downlink operation is completed Thiswaiting procedure synchronizes backlogged end-devices andmay cause collisions Even though the LoRa PHY supportsmultiple simultaneous transmissions of different SFs or chan-nels multiple attempts increase the collision probabilitiesand the PDR decreases as both uplink and downlink trafficincrease To reduce the bloated collisions due to synchronoustransmissions persistent mechanisms such as 0-persistenceor p-persistence are required However persistence schemesincrease the complexity of the network protocol and maycause other side effects such as increased energy consump-tion

Next we assess the additional power consumed fordownlink communications Because gateways operate in analways-on mode we only measure the energy consumed byend-devices We use the duty cycle additional time requiredfor downlink communications as the performance metricThe duty cycle is the sum of wake-up times used for beaconreception for possible poll transmission and for downlinkdata frame receptions Figure 11 shows the average duty cycleat different downlink traffic loadsThe duty cycle increases asthe downlink offered load increases it increases from 075to 11 as 120582119889 increases from 1 to 4 Note that all end-devicesconsume the minimal fixed duty cycle for beacon receptionregardless of the intensity of downlink traffic In addition tothe fixed duty cycle end-devices with backlogged downlinkscontinue to stay in the wake-up state for polling and datareception

Figure 12 illustrates the average latency of downlink trafficand uplink traffic as functions of offered load respectively Asshown in Figure 12(a) the average latency of downlink trafficincreases in proportion to the offered load As explained

0

02

04

06

08

1

12

Dut

y Cy

cle (

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

Figure 11 Duty cycles required for downlink operation includingbeacon poll and downlink data transmissions

before downlink frames are generated according to a Poissonprocess Therefore the probability that a downlink frameoccurs in a small time period follows uniform distributionand on average each downlink frame waits one-half of thebeacon interval In addition frames that arrive during adownlink processing are postponed to the next beacon InFigure 12(a) we can observe that the effect of uplink traffic onthe average latency of downlink is minimal This result is notsurprising because uplink and downlink communications arewell isolated in the proposed scheme

Like the average downlink latency the average uplinklatency increases as the downlink offered load increasesUplink frames that arrive during downlink periods shouldwait until the end of the current downlink periodThe averagelatency of uplink traffic as well as the duty cycle increase asthe downlink offered load increases Contrary to Figure 12(a)where the average downlink latency is seldom affected bythe uplink offered load the average uplink latency increasesproportionally as the uplink offered load increases As theuplink communication demands increase a queue startsto form and this causes the increase in waiting time Thequeueing time is most distinctive at 120582119889 = 4 when the servicetime for uplink communications is minimal

8 Simulation Results

We also compared the performance of the Class B downlinkscheme and that of TRILO Because commercial LoRaWANdevices do not support Class B functions yet we relied oncomputer simulations for the performance comparison Thesimulation code is written primarily in CC++ and we con-duct extensive simulations in a typical LoRaWAN networkand in a heavy downlink traffic condition respectively Tocompare energy consumed for downlink communicationswe define the efficiency of each protocol as a performancemetric The efficiency defined as the ratio of data transmis-sion time to the duty cycle is the fraction of time used foruseful work

12 Wireless Communications and Mobile Computing

Ｏ = 2

Ｏ = 8

70

75

80

85

90

95

100

105D

ownl

ink

Late

ncy

(sec

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

(a)

1

2

3

4

5

6

7

8

Upl

ink

Late

ncy

(sec

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

Ｏ = 2

Ｏ = 8

(b)

Figure 12 Average latency of traffic (a) Downlink latency (b) Uplink latency

Table 4 Notations used for Class B downlink protocol and TRILO

Notation Meaning119863119879 Duty cycle of TRILO119863119861 Duty cycle of the Class B downlink protocol119879119879119861119890119886119888119900119899 Beacon transmission time of TRILO

119879119861119861119890119886119888119900119899 Beacon transmission time of the Class B downlinkprotocol

119879119901119900119897119897 Average poll frame transmission time119879119889119900119908119899 Average downlink frame transmission time119896 Parameter for the Class Brsquos ping slots

119868119864 Indicator function representing a node is backlogged ornot

According to the LoRaWAN standard implementation ofthe Class B downlink scheme discretizes the time into so-called ping slots Each end-device requests 2119896 (0 le 119896 le 7)ping slots per beacon period We use the average case of theClass B where each end-device randomly selects a value ofthe parameter 119896 between 0 and 7 Let us first introduce thenotations for the analysis of LoRaWAN downlink protocol(Table 4)

We used SF 9 for beacon transmissions according to theLoRaWAN specification KR920-923 [29] The duty cycle ofTRILO119863119879 is

119863119879 =119879119879119861119890119886119888119900119899 + 119868119864 sdot (119879119901119900119897119897 + 119879119889119900119908119899)

119861119890119886119888119900119899 119875119890119903119894119900119889 (7)

Note that unlike 119879119861119861119890119886119888119900119899 119879119879119861119890119886119888119900119899 increases in proportion tothe number of busy end-devices The duty cycle of a Class Bdevice 119863119861 is

119863119861 = 119879119861119861119890119886119888119900119899 + 2119896 sdot 119879119889119900119908119899119861119890119886119888119900119899 119875119890119903119894119900119889 (8)

Class B devices have different duty cycles depending onrandomly selected values of parameter 119896 Then the efficiencyis computed as

119864119891119891119894119888119894119890119899119888119910 = 119863119900119908119899119897119894119899119896 119905119903119886119899119904119898119894119904119904119894119900119899 119905119894119898119890119863119906119905119910 119888119910119888119897119890119904 (9)

We measured the efficiency of TRILO and the Class Bdownlink protocol by varying the number of nodes from 50to 4000 and the downlink offered load from 2 to 32 framesper beacon period Each performance point is the average of10000 runs We limit the maximum downlink traffic to 32frames per beacon interval because uplink traffic is greaterthan downlink traffic in many LoRaWAN applications Notethat at 120582119889 = 32 about a half of beacon period is consumed fordownlink communications if we assume that the downlinktransmission time is 2 seconds on average

The efficiency of each scheme is shown in Figure 13Note that the offered load is aggregated load and the trafficintensity of individual node decreases as the number of nodesincreases The total times for downlink communications arefixed at each given offered load However the sum of dutycycles increases as the number of nodes increases Thereforein both protocols the maximum efficiencies are realized atsmall networks and the efficiency decreases as the networksize increases The results illustrate that efficiencies of TRILOare higher than those of the Class B downlink protocolthroughout all downlink generation ratesTheClass B schemeperforms well in heavy traffic cases However the proposedscheme outperforms the Class B scheme even in heavy trafficconditions In small networks the performance gap decreasesfrom about 139 times to about 33 times as 120582119889 increases from2 to 32 Also each gap in each offered load increases as thenetwork size increases In the case of TRILO the averageduty cycle decreases inversely proportional to the number ofnodes because only busy devices are active during downlink

Wireless Communications and Mobile Computing 13

Number of Nodes500 1000 1500 2000 2500 3000 3500 4000

10minus3

10minus2

Effici

ency

10minus1

100

101

Class B (＞ = 2)

Proposed (＞ = 2)

Class B (＞ = 8)

Proposed (＞ = 8)

Class B (＞ = 32)

Proposed (＞ = 32)

Figure 13 Efficiency of TRILO and Class B downlink protocol

periods On the contrary Class B protocol allocates 31 pingslots on average regardless of downlink demands In shortthe number of receive windows wasted by the Class B schemevaries depending on the amount of downlink traffic howeveronly busy devices use extra duty cycle for downlink traffic inTRILO

The Class B protocol does not coordinate traffic betweenuplinks and downlinks so that several uplinks can be dis-rupted by downlink transmissions due to the half-duplexcharacteristic of a LoRaWAN gateway all reception pathscan be blocked by downlink transmissions It can obstructthe proper operations of typical LoRaWANs where uplinktransmissions are predominant In contrast the proposedscheme is free from this problem because it isolates the timefor uplinks and downlinks periods

9 Conclusions

A plethora of LPWAN techniques such as LoRa SigFoxRPMA and Weightless have emerged as a new enablingnetwork technology for IoT applications that require low-rate low-cost and long lifetimes LPWANs allow end-deviceinitiated uplinks However to maximize the lifetime ofbattery powered end-devices nodes are put into the sleepstate such that rather restricted downlink communicationsare permitted In this paper we proposed a new downlinkprotocol named TRILO for LoRaWAN

Because LoRaWAN assumes a star topology where mul-tiple end-devices are connected to a single gateway weadopted a beacon based downlink mechanism similar to theIEEE 80211 PSM standard A gateway broadcast beaconsperiodically at every beacon period and end-devices are timesynchronized Beacons alert nodes with buffered downlinksin addition to synchronizing end-devicesrsquo clocks Customizedto the physical characteristics of LoRa we designed two

polling schemes concurrent polling and sequential pollingAn analysis indicates that sequential polling is more energyefficient than concurrent polling

We implement the proposed beacon based downlinkprotocol using commercially available components and con-duct experiments with modified devices Our performancestudy shows that Packet Delivery Ratio (PDR) is almost100 for both uplink and downlink traffic and the extrawake-up time to receive beacons and downlinks is minimalSimulation results also show that our proposed protocol canadaptively allocate receive windows resulting in lower energyconsumption

For further work we plan to investigate the impact ofour scheme on the networks with multiple gateways Alsodetailed investigations of impact of the number of downlinksand the certain distributions of SFs on the performanceseem interesting Optimization techniques leveraging SF andpower allocation are expected to affect the performance of theproposed scheme

Data Availability

The data used to support the findings of this study areincluded within the article

Disclosure

The funding sponsors had no role in the study in thecollection analyses or interpretation of data in the writingof the manuscript and in the decision to publish the results

Conflicts of Interest

The authors declare that there are no conflicts of interestregarding the publication of this paper

14 Wireless Communications and Mobile Computing

Acknowledgments

This work was supported by the National Research Founda-tion of Korea (NRF) Grant funded by the Korean Govern-ment (MSIP) (No 2016R1A5A1012966) Institute for Infor-mation amp Communications Technology Promotion (IITP)grant funded by the Korea government (MSIT) (No 2015-0-00557 ResilientFault-Tolerant Autonomic NetworkingBased on Physicality Relationship and Service Semantic ofIoT Devices) and the MSIP (Ministry of Science ICT andFuture Planning) Korea under the ITRC (Information Tech-nology Research Center) support program (IITP-2018-2015-0-00378) supervised by the IITP (Institute for Informationamp Communications Technology Promotion) Also the snu-samsung smart campus research center at Seoul NationalUniversity provides research facilities for this study

References

[1] M Bor U Roedig T Voigt and J M Alonso ldquoDo LoRalow-power wide-area networks scalerdquo in Proceedings of the19th ACM International Conference on Modeling Analysis andSimulation of Wireless and Mobile Systems MSWiM 2016 pp59ndash67 Malta November 2016

[2] DMagrinMCentenaro andLVangelista ldquoPerformance eval-uation of LoRa networks in a smart city scenariordquo inProceedingsof the 2017 IEEE International Conference on CommunicationsICC 2017 France May 2017

[3] LoRa httpswwwlora-allianceorgWhat-Is-LoRaTechnol-ogy

[4] ldquoLoRaWAN 11 specificationrdquo LoRa Alliance 2017 httpslora-allianceorgresource-hublorawantm-specification-v11

[5] M Bor J Vidler and U Roedig ldquoLoRa for the internet ofthingsrdquo in Proceedings of the International Conference onEmbedded Wireless Systems and Networks (EWSN rsquo16) pp 361ndash366 Junction Publishing 2016

[6] 3GPP ldquoStudy on provision of low-cost Machine-Type Commu-nications User Equipments based on LTErdquo TR 36888 V120006 2013

[7] 3GPP ldquoCellular system support for ultra-low complexity andlow throughput Internet of Thingsrdquo TR 45820 V1310 11 2015

[8] J Gozalvez ldquoNew 3GPP Standard for IoTrdquo IEEE VehicularTechnology Magazine vol 11 no 1 pp 14ndash20 2016

[9] R Ratasuk N Mangalvedhe and A Ghosh ldquoOverview ofLTE enhancements for cellular IoTrdquo in Proceedings of the 26thIEEE Annual International Symposium on Personal Indoor andMobile Radio Communications PIMRC 2015 pp 2293ndash2297China September 2015

[10] H Shariatmadari R Ratasuk S Iraji et al ldquoMachine-type com-munications current status and future perspectives toward 5Gsystemsrdquo IEEE CommunicationsMagazine vol 53 no 9 pp 10ndash17 2015

[11] S Landstrom J Bergstrom E Westerberg and D Hammar-wall ldquoNBIoT a sustainable technology for connecting billionsof devicesrdquo Ericsson Technology Review vol 4 pp 2ndash11 2016

[12] M Lauridsen I Z Kovacs P Mogensen M Sorensen andS Holst ldquoCoverage and capacity analysis of LTE-M and NB-IoT in a rural areardquo in Proceedings of the 2016 IEEE 84thVehicular Technology Conference (VTC-Fall) pp 1ndash5 MontrealQC Canada September 2016

[13] Sigfox httpwwwsigfoxcom[14] Weightless open standard httpwwwweightlessorg[15] Ingenu RPMA httpwwwingenucomtechnologyrpma[16] A Dunkels ldquoThe ContikiMAC radio duty cycling protocolrdquo

Technical Report T201113 Swedish Institute of ComputerScience 2011

[17] J Ko J Eriksson N Tsiftes et al ldquoIndustry Beyond interoper-ability - Pushing the performance of sensor network IP stacksrdquoin Proceedings of the 9th ACM Conference on Embedded Net-worked Sensor Systems SenSys 2011 pp 1ndash11 USA November2011

[18] D Moss J Hui and K Klues ldquoTEP 105 low power listeningrdquohttpwwwtinyosnettinyos-2xdocpdftep105pdf 2008

[19] C Gomez J Oller and J Paradells ldquoOverview and evaluationof bluetooth low energy an emerging low-power wirelesstechnologyrdquo Sensors vol 12 no 9 pp 11734ndash11753 2012

[20] A A Kandhalu A E Xhafa and S Hosur ldquoTowards bounded-latency bluetooth low energy for in-vehicle network cablereplacementrdquo in Proceeding of the International Conference onConnected Vehicles and Expo (ICCVE) pp 635ndash640 Las VegasNV USA 2013

[21] A Montanari S Nawaz C Mascolo and K Sailer ldquoA studyof bluetooth low energy performance for human proximitydetection in the workplacerdquo in Proceedings of the 2017 IEEEInternational Conference on Pervasive Computing and Commu-nications PerCom 2017 pp 90ndash99 Kona HI USA March 2017

[22] C Julien C Liu A L Murphy and G P Picco ldquoBLEnd Practi-cal continuous neighbor discovery for bluetooth low energyrdquo inProceedings of the 16th ACMIEEE International Conference onInformation Processing in Sensor Networks IPSN 2017 pp 105ndash116 New York NY USA April 2017

[23] Y Qiu S Li X Xu and Z Li ldquoTalk more listen less energy-efficient neighbor discovery in wireless sensor networksrdquo inProceedings of the 35th Annual IEEE International Conference onComputer Communications IEEE INFOCOM 2016 USA April2016

[24] A J Berni andW D Gregg ldquoOn the utility of chirpmodulationfor digital signalingrdquo IEEE Transactions on Communicationsvol 21 no 6 pp 748ndash751 1973

[25] A Springer W Gugler M Huemer L Reindl C C W Ruppeland R Weigel ldquoSpread spectrum communications using chirpsignalsrdquo in Proceedings of the IEEEAFCEA Information Systemsfor Enhanced Public Safety and Security EUROCOMM2000 pp166ndash170 Germany

[26] IEEE Std 80211-2007 ldquoIEEE Standard for Information Tech-nologymdashTelecommunications and Information Exchange be-tween SystemsmdashLocal and Metropolitan Area NetworksmdashSpecific Requirements Part 11 Wireless LAN Medium AccessControl (MAC) and Physical Layer (PHY) Specifications June2007rdquo

[27] RAK831 httpwwwrakwirelesscomenWisKeyOSHRAK831[28] LoRaWAN network server httpsgithubcomgotthardplor-

awan-server[29] ldquoLoRaWAN 11 Regional Parametersrdquo LoRa Alliance 2017

httpslora-allianceorgresource-hublorawantm-regional-pa-rameters-v11ra

Wireless Communications and Mobile Computing 11

Table 3 Packet delivery ratio of uplink traffic at various uplink anddownlink offered loads

Packet generation rate 120582119889 = 1 120582119889 = 2 120582119889 = 4120582119906 = 2 9864 9827 9772120582119906 = 8 9674 9603 9510

in addition to downlink data frames A failure in any onecomponent may lead to unsuccessful data transmissionsUnlike downlink frames uplink traffic experiences occa-sional transmission failures Wemeasure the PDR by varyingthe offered loads of both uplink and downlink traffic Notethat all nodes use the same SF and collisions occur if framesare transmitted on the same channel simultaneously Table 3illustrates the PDR of uplink traffic at different offered loadsBoth uplink and downlink traffic affect the PDR of uplinktraffic The PDR decreases as the offered load of downlinktraffic increases at 120582119906 = 2 the PDR decreases from 9864to 9772 as the offered load of downlink traffic increasesfrom 1 to 4 In addition the uplink traffic intensity also affectsthe PDR of uplink traffic for example at 120582119889 = 2 the PDRdecreases from 9827 to 9603 as the offered load of uplinktraffic increases from 2 to 8

Note that uplink transmissions are prohibited duringpolling and following downlink frame transmissions Uplinkframes which arrive during downlink operation should waituntil the current downlink operation is completed Thiswaiting procedure synchronizes backlogged end-devices andmay cause collisions Even though the LoRa PHY supportsmultiple simultaneous transmissions of different SFs or chan-nels multiple attempts increase the collision probabilitiesand the PDR decreases as both uplink and downlink trafficincrease To reduce the bloated collisions due to synchronoustransmissions persistent mechanisms such as 0-persistenceor p-persistence are required However persistence schemesincrease the complexity of the network protocol and maycause other side effects such as increased energy consump-tion

Next we assess the additional power consumed fordownlink communications Because gateways operate in analways-on mode we only measure the energy consumed byend-devices We use the duty cycle additional time requiredfor downlink communications as the performance metricThe duty cycle is the sum of wake-up times used for beaconreception for possible poll transmission and for downlinkdata frame receptions Figure 11 shows the average duty cycleat different downlink traffic loadsThe duty cycle increases asthe downlink offered load increases it increases from 075to 11 as 120582119889 increases from 1 to 4 Note that all end-devicesconsume the minimal fixed duty cycle for beacon receptionregardless of the intensity of downlink traffic In addition tothe fixed duty cycle end-devices with backlogged downlinkscontinue to stay in the wake-up state for polling and datareception

Figure 12 illustrates the average latency of downlink trafficand uplink traffic as functions of offered load respectively Asshown in Figure 12(a) the average latency of downlink trafficincreases in proportion to the offered load As explained

0

02

04

06

08

1

12

Dut

y Cy

cle (

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

Figure 11 Duty cycles required for downlink operation includingbeacon poll and downlink data transmissions

before downlink frames are generated according to a Poissonprocess Therefore the probability that a downlink frameoccurs in a small time period follows uniform distributionand on average each downlink frame waits one-half of thebeacon interval In addition frames that arrive during adownlink processing are postponed to the next beacon InFigure 12(a) we can observe that the effect of uplink traffic onthe average latency of downlink is minimal This result is notsurprising because uplink and downlink communications arewell isolated in the proposed scheme

Like the average downlink latency the average uplinklatency increases as the downlink offered load increasesUplink frames that arrive during downlink periods shouldwait until the end of the current downlink periodThe averagelatency of uplink traffic as well as the duty cycle increase asthe downlink offered load increases Contrary to Figure 12(a)where the average downlink latency is seldom affected bythe uplink offered load the average uplink latency increasesproportionally as the uplink offered load increases As theuplink communication demands increase a queue startsto form and this causes the increase in waiting time Thequeueing time is most distinctive at 120582119889 = 4 when the servicetime for uplink communications is minimal

8 Simulation Results

We also compared the performance of the Class B downlinkscheme and that of TRILO Because commercial LoRaWANdevices do not support Class B functions yet we relied oncomputer simulations for the performance comparison Thesimulation code is written primarily in CC++ and we con-duct extensive simulations in a typical LoRaWAN networkand in a heavy downlink traffic condition respectively Tocompare energy consumed for downlink communicationswe define the efficiency of each protocol as a performancemetric The efficiency defined as the ratio of data transmis-sion time to the duty cycle is the fraction of time used foruseful work

12 Wireless Communications and Mobile Computing

Ｏ = 2

Ｏ = 8

70

75

80

85

90

95

100

105D

ownl

ink

Late

ncy

(sec

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

(a)

1

2

3

4

5

6

7

8

Upl

ink

Late

ncy

(sec

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

Ｏ = 2

Ｏ = 8

(b)

Figure 12 Average latency of traffic (a) Downlink latency (b) Uplink latency

Table 4 Notations used for Class B downlink protocol and TRILO

Notation Meaning119863119879 Duty cycle of TRILO119863119861 Duty cycle of the Class B downlink protocol119879119879119861119890119886119888119900119899 Beacon transmission time of TRILO

119879119861119861119890119886119888119900119899 Beacon transmission time of the Class B downlinkprotocol

119879119901119900119897119897 Average poll frame transmission time119879119889119900119908119899 Average downlink frame transmission time119896 Parameter for the Class Brsquos ping slots

119868119864 Indicator function representing a node is backlogged ornot

According to the LoRaWAN standard implementation ofthe Class B downlink scheme discretizes the time into so-called ping slots Each end-device requests 2119896 (0 le 119896 le 7)ping slots per beacon period We use the average case of theClass B where each end-device randomly selects a value ofthe parameter 119896 between 0 and 7 Let us first introduce thenotations for the analysis of LoRaWAN downlink protocol(Table 4)

We used SF 9 for beacon transmissions according to theLoRaWAN specification KR920-923 [29] The duty cycle ofTRILO119863119879 is

119863119879 =119879119879119861119890119886119888119900119899 + 119868119864 sdot (119879119901119900119897119897 + 119879119889119900119908119899)

119861119890119886119888119900119899 119875119890119903119894119900119889 (7)

Note that unlike 119879119861119861119890119886119888119900119899 119879119879119861119890119886119888119900119899 increases in proportion tothe number of busy end-devices The duty cycle of a Class Bdevice 119863119861 is

119863119861 = 119879119861119861119890119886119888119900119899 + 2119896 sdot 119879119889119900119908119899119861119890119886119888119900119899 119875119890119903119894119900119889 (8)

Class B devices have different duty cycles depending onrandomly selected values of parameter 119896 Then the efficiencyis computed as

119864119891119891119894119888119894119890119899119888119910 = 119863119900119908119899119897119894119899119896 119905119903119886119899119904119898119894119904119904119894119900119899 119905119894119898119890119863119906119905119910 119888119910119888119897119890119904 (9)

We measured the efficiency of TRILO and the Class Bdownlink protocol by varying the number of nodes from 50to 4000 and the downlink offered load from 2 to 32 framesper beacon period Each performance point is the average of10000 runs We limit the maximum downlink traffic to 32frames per beacon interval because uplink traffic is greaterthan downlink traffic in many LoRaWAN applications Notethat at 120582119889 = 32 about a half of beacon period is consumed fordownlink communications if we assume that the downlinktransmission time is 2 seconds on average

The efficiency of each scheme is shown in Figure 13Note that the offered load is aggregated load and the trafficintensity of individual node decreases as the number of nodesincreases The total times for downlink communications arefixed at each given offered load However the sum of dutycycles increases as the number of nodes increases Thereforein both protocols the maximum efficiencies are realized atsmall networks and the efficiency decreases as the networksize increases The results illustrate that efficiencies of TRILOare higher than those of the Class B downlink protocolthroughout all downlink generation ratesTheClass B schemeperforms well in heavy traffic cases However the proposedscheme outperforms the Class B scheme even in heavy trafficconditions In small networks the performance gap decreasesfrom about 139 times to about 33 times as 120582119889 increases from2 to 32 Also each gap in each offered load increases as thenetwork size increases In the case of TRILO the averageduty cycle decreases inversely proportional to the number ofnodes because only busy devices are active during downlink

Wireless Communications and Mobile Computing 13

Number of Nodes500 1000 1500 2000 2500 3000 3500 4000

10minus3

10minus2

Effici

ency

10minus1

100

101

Class B (＞ = 2)

Proposed (＞ = 2)

Class B (＞ = 8)

Proposed (＞ = 8)

Class B (＞ = 32)

Proposed (＞ = 32)

Figure 13 Efficiency of TRILO and Class B downlink protocol

periods On the contrary Class B protocol allocates 31 pingslots on average regardless of downlink demands In shortthe number of receive windows wasted by the Class B schemevaries depending on the amount of downlink traffic howeveronly busy devices use extra duty cycle for downlink traffic inTRILO

The Class B protocol does not coordinate traffic betweenuplinks and downlinks so that several uplinks can be dis-rupted by downlink transmissions due to the half-duplexcharacteristic of a LoRaWAN gateway all reception pathscan be blocked by downlink transmissions It can obstructthe proper operations of typical LoRaWANs where uplinktransmissions are predominant In contrast the proposedscheme is free from this problem because it isolates the timefor uplinks and downlinks periods

9 Conclusions

A plethora of LPWAN techniques such as LoRa SigFoxRPMA and Weightless have emerged as a new enablingnetwork technology for IoT applications that require low-rate low-cost and long lifetimes LPWANs allow end-deviceinitiated uplinks However to maximize the lifetime ofbattery powered end-devices nodes are put into the sleepstate such that rather restricted downlink communicationsare permitted In this paper we proposed a new downlinkprotocol named TRILO for LoRaWAN

Because LoRaWAN assumes a star topology where mul-tiple end-devices are connected to a single gateway weadopted a beacon based downlink mechanism similar to theIEEE 80211 PSM standard A gateway broadcast beaconsperiodically at every beacon period and end-devices are timesynchronized Beacons alert nodes with buffered downlinksin addition to synchronizing end-devicesrsquo clocks Customizedto the physical characteristics of LoRa we designed two

polling schemes concurrent polling and sequential pollingAn analysis indicates that sequential polling is more energyefficient than concurrent polling

We implement the proposed beacon based downlinkprotocol using commercially available components and con-duct experiments with modified devices Our performancestudy shows that Packet Delivery Ratio (PDR) is almost100 for both uplink and downlink traffic and the extrawake-up time to receive beacons and downlinks is minimalSimulation results also show that our proposed protocol canadaptively allocate receive windows resulting in lower energyconsumption

For further work we plan to investigate the impact ofour scheme on the networks with multiple gateways Alsodetailed investigations of impact of the number of downlinksand the certain distributions of SFs on the performanceseem interesting Optimization techniques leveraging SF andpower allocation are expected to affect the performance of theproposed scheme

Data Availability

The data used to support the findings of this study areincluded within the article

Disclosure

The funding sponsors had no role in the study in thecollection analyses or interpretation of data in the writingof the manuscript and in the decision to publish the results

Conflicts of Interest

The authors declare that there are no conflicts of interestregarding the publication of this paper

14 Wireless Communications and Mobile Computing

Acknowledgments

This work was supported by the National Research Founda-tion of Korea (NRF) Grant funded by the Korean Govern-ment (MSIP) (No 2016R1A5A1012966) Institute for Infor-mation amp Communications Technology Promotion (IITP)grant funded by the Korea government (MSIT) (No 2015-0-00557 ResilientFault-Tolerant Autonomic NetworkingBased on Physicality Relationship and Service Semantic ofIoT Devices) and the MSIP (Ministry of Science ICT andFuture Planning) Korea under the ITRC (Information Tech-nology Research Center) support program (IITP-2018-2015-0-00378) supervised by the IITP (Institute for Informationamp Communications Technology Promotion) Also the snu-samsung smart campus research center at Seoul NationalUniversity provides research facilities for this study

References

[1] M Bor U Roedig T Voigt and J M Alonso ldquoDo LoRalow-power wide-area networks scalerdquo in Proceedings of the19th ACM International Conference on Modeling Analysis andSimulation of Wireless and Mobile Systems MSWiM 2016 pp59ndash67 Malta November 2016

[2] DMagrinMCentenaro andLVangelista ldquoPerformance eval-uation of LoRa networks in a smart city scenariordquo inProceedingsof the 2017 IEEE International Conference on CommunicationsICC 2017 France May 2017

[3] LoRa httpswwwlora-allianceorgWhat-Is-LoRaTechnol-ogy

[4] ldquoLoRaWAN 11 specificationrdquo LoRa Alliance 2017 httpslora-allianceorgresource-hublorawantm-specification-v11

[5] M Bor J Vidler and U Roedig ldquoLoRa for the internet ofthingsrdquo in Proceedings of the International Conference onEmbedded Wireless Systems and Networks (EWSN rsquo16) pp 361ndash366 Junction Publishing 2016

[6] 3GPP ldquoStudy on provision of low-cost Machine-Type Commu-nications User Equipments based on LTErdquo TR 36888 V120006 2013

[7] 3GPP ldquoCellular system support for ultra-low complexity andlow throughput Internet of Thingsrdquo TR 45820 V1310 11 2015

[8] J Gozalvez ldquoNew 3GPP Standard for IoTrdquo IEEE VehicularTechnology Magazine vol 11 no 1 pp 14ndash20 2016

[9] R Ratasuk N Mangalvedhe and A Ghosh ldquoOverview ofLTE enhancements for cellular IoTrdquo in Proceedings of the 26thIEEE Annual International Symposium on Personal Indoor andMobile Radio Communications PIMRC 2015 pp 2293ndash2297China September 2015

[10] H Shariatmadari R Ratasuk S Iraji et al ldquoMachine-type com-munications current status and future perspectives toward 5Gsystemsrdquo IEEE CommunicationsMagazine vol 53 no 9 pp 10ndash17 2015

[11] S Landstrom J Bergstrom E Westerberg and D Hammar-wall ldquoNBIoT a sustainable technology for connecting billionsof devicesrdquo Ericsson Technology Review vol 4 pp 2ndash11 2016

[12] M Lauridsen I Z Kovacs P Mogensen M Sorensen andS Holst ldquoCoverage and capacity analysis of LTE-M and NB-IoT in a rural areardquo in Proceedings of the 2016 IEEE 84thVehicular Technology Conference (VTC-Fall) pp 1ndash5 MontrealQC Canada September 2016

[13] Sigfox httpwwwsigfoxcom[14] Weightless open standard httpwwwweightlessorg[15] Ingenu RPMA httpwwwingenucomtechnologyrpma[16] A Dunkels ldquoThe ContikiMAC radio duty cycling protocolrdquo

Technical Report T201113 Swedish Institute of ComputerScience 2011

[17] J Ko J Eriksson N Tsiftes et al ldquoIndustry Beyond interoper-ability - Pushing the performance of sensor network IP stacksrdquoin Proceedings of the 9th ACM Conference on Embedded Net-worked Sensor Systems SenSys 2011 pp 1ndash11 USA November2011

[18] D Moss J Hui and K Klues ldquoTEP 105 low power listeningrdquohttpwwwtinyosnettinyos-2xdocpdftep105pdf 2008

[19] C Gomez J Oller and J Paradells ldquoOverview and evaluationof bluetooth low energy an emerging low-power wirelesstechnologyrdquo Sensors vol 12 no 9 pp 11734ndash11753 2012

[20] A A Kandhalu A E Xhafa and S Hosur ldquoTowards bounded-latency bluetooth low energy for in-vehicle network cablereplacementrdquo in Proceeding of the International Conference onConnected Vehicles and Expo (ICCVE) pp 635ndash640 Las VegasNV USA 2013

[21] A Montanari S Nawaz C Mascolo and K Sailer ldquoA studyof bluetooth low energy performance for human proximitydetection in the workplacerdquo in Proceedings of the 2017 IEEEInternational Conference on Pervasive Computing and Commu-nications PerCom 2017 pp 90ndash99 Kona HI USA March 2017

[22] C Julien C Liu A L Murphy and G P Picco ldquoBLEnd Practi-cal continuous neighbor discovery for bluetooth low energyrdquo inProceedings of the 16th ACMIEEE International Conference onInformation Processing in Sensor Networks IPSN 2017 pp 105ndash116 New York NY USA April 2017

[23] Y Qiu S Li X Xu and Z Li ldquoTalk more listen less energy-efficient neighbor discovery in wireless sensor networksrdquo inProceedings of the 35th Annual IEEE International Conference onComputer Communications IEEE INFOCOM 2016 USA April2016

[24] A J Berni andW D Gregg ldquoOn the utility of chirpmodulationfor digital signalingrdquo IEEE Transactions on Communicationsvol 21 no 6 pp 748ndash751 1973

[25] A Springer W Gugler M Huemer L Reindl C C W Ruppeland R Weigel ldquoSpread spectrum communications using chirpsignalsrdquo in Proceedings of the IEEEAFCEA Information Systemsfor Enhanced Public Safety and Security EUROCOMM2000 pp166ndash170 Germany

[26] IEEE Std 80211-2007 ldquoIEEE Standard for Information Tech-nologymdashTelecommunications and Information Exchange be-tween SystemsmdashLocal and Metropolitan Area NetworksmdashSpecific Requirements Part 11 Wireless LAN Medium AccessControl (MAC) and Physical Layer (PHY) Specifications June2007rdquo

[27] RAK831 httpwwwrakwirelesscomenWisKeyOSHRAK831[28] LoRaWAN network server httpsgithubcomgotthardplor-

awan-server[29] ldquoLoRaWAN 11 Regional Parametersrdquo LoRa Alliance 2017

httpslora-allianceorgresource-hublorawantm-regional-pa-rameters-v11ra

12 Wireless Communications and Mobile Computing

Ｏ = 2

Ｏ = 8

70

75

80

85

90

95

100

105D

ownl

ink

Late

ncy

(sec

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

(a)

1

2

3

4

5

6

7

8

Upl

ink

Late

ncy

(sec

)

＞ = 2 ＞ = 4＞ = 1

Downlink Generation Rate

Ｏ = 2

Ｏ = 8

(b)

Figure 12 Average latency of traffic (a) Downlink latency (b) Uplink latency

Table 4 Notations used for Class B downlink protocol and TRILO

Notation Meaning119863119879 Duty cycle of TRILO119863119861 Duty cycle of the Class B downlink protocol119879119879119861119890119886119888119900119899 Beacon transmission time of TRILO

119879119861119861119890119886119888119900119899 Beacon transmission time of the Class B downlinkprotocol

119879119901119900119897119897 Average poll frame transmission time119879119889119900119908119899 Average downlink frame transmission time119896 Parameter for the Class Brsquos ping slots

119868119864 Indicator function representing a node is backlogged ornot

According to the LoRaWAN standard implementation ofthe Class B downlink scheme discretizes the time into so-called ping slots Each end-device requests 2119896 (0 le 119896 le 7)ping slots per beacon period We use the average case of theClass B where each end-device randomly selects a value ofthe parameter 119896 between 0 and 7 Let us first introduce thenotations for the analysis of LoRaWAN downlink protocol(Table 4)

We used SF 9 for beacon transmissions according to theLoRaWAN specification KR920-923 [29] The duty cycle ofTRILO119863119879 is

119863119879 =119879119879119861119890119886119888119900119899 + 119868119864 sdot (119879119901119900119897119897 + 119879119889119900119908119899)

119861119890119886119888119900119899 119875119890119903119894119900119889 (7)

Note that unlike 119879119861119861119890119886119888119900119899 119879119879119861119890119886119888119900119899 increases in proportion tothe number of busy end-devices The duty cycle of a Class Bdevice 119863119861 is

119863119861 = 119879119861119861119890119886119888119900119899 + 2119896 sdot 119879119889119900119908119899119861119890119886119888119900119899 119875119890119903119894119900119889 (8)

Class B devices have different duty cycles depending onrandomly selected values of parameter 119896 Then the efficiencyis computed as

119864119891119891119894119888119894119890119899119888119910 = 119863119900119908119899119897119894119899119896 119905119903119886119899119904119898119894119904119904119894119900119899 119905119894119898119890119863119906119905119910 119888119910119888119897119890119904 (9)

We measured the efficiency of TRILO and the Class Bdownlink protocol by varying the number of nodes from 50to 4000 and the downlink offered load from 2 to 32 framesper beacon period Each performance point is the average of10000 runs We limit the maximum downlink traffic to 32frames per beacon interval because uplink traffic is greaterthan downlink traffic in many LoRaWAN applications Notethat at 120582119889 = 32 about a half of beacon period is consumed fordownlink communications if we assume that the downlinktransmission time is 2 seconds on average

The efficiency of each scheme is shown in Figure 13Note that the offered load is aggregated load and the trafficintensity of individual node decreases as the number of nodesincreases The total times for downlink communications arefixed at each given offered load However the sum of dutycycles increases as the number of nodes increases Thereforein both protocols the maximum efficiencies are realized atsmall networks and the efficiency decreases as the networksize increases The results illustrate that efficiencies of TRILOare higher than those of the Class B downlink protocolthroughout all downlink generation ratesTheClass B schemeperforms well in heavy traffic cases However the proposedscheme outperforms the Class B scheme even in heavy trafficconditions In small networks the performance gap decreasesfrom about 139 times to about 33 times as 120582119889 increases from2 to 32 Also each gap in each offered load increases as thenetwork size increases In the case of TRILO the averageduty cycle decreases inversely proportional to the number ofnodes because only busy devices are active during downlink

Wireless Communications and Mobile Computing 13

Number of Nodes500 1000 1500 2000 2500 3000 3500 4000

10minus3

10minus2

Effici

ency

10minus1

100

101

Class B (＞ = 2)

Proposed (＞ = 2)

Class B (＞ = 8)

Proposed (＞ = 8)

Class B (＞ = 32)

Proposed (＞ = 32)

Figure 13 Efficiency of TRILO and Class B downlink protocol

periods On the contrary Class B protocol allocates 31 pingslots on average regardless of downlink demands In shortthe number of receive windows wasted by the Class B schemevaries depending on the amount of downlink traffic howeveronly busy devices use extra duty cycle for downlink traffic inTRILO

The Class B protocol does not coordinate traffic betweenuplinks and downlinks so that several uplinks can be dis-rupted by downlink transmissions due to the half-duplexcharacteristic of a LoRaWAN gateway all reception pathscan be blocked by downlink transmissions It can obstructthe proper operations of typical LoRaWANs where uplinktransmissions are predominant In contrast the proposedscheme is free from this problem because it isolates the timefor uplinks and downlinks periods

9 Conclusions

A plethora of LPWAN techniques such as LoRa SigFoxRPMA and Weightless have emerged as a new enablingnetwork technology for IoT applications that require low-rate low-cost and long lifetimes LPWANs allow end-deviceinitiated uplinks However to maximize the lifetime ofbattery powered end-devices nodes are put into the sleepstate such that rather restricted downlink communicationsare permitted In this paper we proposed a new downlinkprotocol named TRILO for LoRaWAN

Because LoRaWAN assumes a star topology where mul-tiple end-devices are connected to a single gateway weadopted a beacon based downlink mechanism similar to theIEEE 80211 PSM standard A gateway broadcast beaconsperiodically at every beacon period and end-devices are timesynchronized Beacons alert nodes with buffered downlinksin addition to synchronizing end-devicesrsquo clocks Customizedto the physical characteristics of LoRa we designed two

polling schemes concurrent polling and sequential pollingAn analysis indicates that sequential polling is more energyefficient than concurrent polling

We implement the proposed beacon based downlinkprotocol using commercially available components and con-duct experiments with modified devices Our performancestudy shows that Packet Delivery Ratio (PDR) is almost100 for both uplink and downlink traffic and the extrawake-up time to receive beacons and downlinks is minimalSimulation results also show that our proposed protocol canadaptively allocate receive windows resulting in lower energyconsumption

For further work we plan to investigate the impact ofour scheme on the networks with multiple gateways Alsodetailed investigations of impact of the number of downlinksand the certain distributions of SFs on the performanceseem interesting Optimization techniques leveraging SF andpower allocation are expected to affect the performance of theproposed scheme

Data Availability

The data used to support the findings of this study areincluded within the article

Disclosure

The funding sponsors had no role in the study in thecollection analyses or interpretation of data in the writingof the manuscript and in the decision to publish the results

Conflicts of Interest

The authors declare that there are no conflicts of interestregarding the publication of this paper

14 Wireless Communications and Mobile Computing

Acknowledgments

This work was supported by the National Research Founda-tion of Korea (NRF) Grant funded by the Korean Govern-ment (MSIP) (No 2016R1A5A1012966) Institute for Infor-mation amp Communications Technology Promotion (IITP)grant funded by the Korea government (MSIT) (No 2015-0-00557 ResilientFault-Tolerant Autonomic NetworkingBased on Physicality Relationship and Service Semantic ofIoT Devices) and the MSIP (Ministry of Science ICT andFuture Planning) Korea under the ITRC (Information Tech-nology Research Center) support program (IITP-2018-2015-0-00378) supervised by the IITP (Institute for Informationamp Communications Technology Promotion) Also the snu-samsung smart campus research center at Seoul NationalUniversity provides research facilities for this study

References

[1] M Bor U Roedig T Voigt and J M Alonso ldquoDo LoRalow-power wide-area networks scalerdquo in Proceedings of the19th ACM International Conference on Modeling Analysis andSimulation of Wireless and Mobile Systems MSWiM 2016 pp59ndash67 Malta November 2016

[2] DMagrinMCentenaro andLVangelista ldquoPerformance eval-uation of LoRa networks in a smart city scenariordquo inProceedingsof the 2017 IEEE International Conference on CommunicationsICC 2017 France May 2017

[3] LoRa httpswwwlora-allianceorgWhat-Is-LoRaTechnol-ogy

[4] ldquoLoRaWAN 11 specificationrdquo LoRa Alliance 2017 httpslora-allianceorgresource-hublorawantm-specification-v11

[5] M Bor J Vidler and U Roedig ldquoLoRa for the internet ofthingsrdquo in Proceedings of the International Conference onEmbedded Wireless Systems and Networks (EWSN rsquo16) pp 361ndash366 Junction Publishing 2016

[6] 3GPP ldquoStudy on provision of low-cost Machine-Type Commu-nications User Equipments based on LTErdquo TR 36888 V120006 2013

[7] 3GPP ldquoCellular system support for ultra-low complexity andlow throughput Internet of Thingsrdquo TR 45820 V1310 11 2015

[8] J Gozalvez ldquoNew 3GPP Standard for IoTrdquo IEEE VehicularTechnology Magazine vol 11 no 1 pp 14ndash20 2016

[9] R Ratasuk N Mangalvedhe and A Ghosh ldquoOverview ofLTE enhancements for cellular IoTrdquo in Proceedings of the 26thIEEE Annual International Symposium on Personal Indoor andMobile Radio Communications PIMRC 2015 pp 2293ndash2297China September 2015

[10] H Shariatmadari R Ratasuk S Iraji et al ldquoMachine-type com-munications current status and future perspectives toward 5Gsystemsrdquo IEEE CommunicationsMagazine vol 53 no 9 pp 10ndash17 2015

[11] S Landstrom J Bergstrom E Westerberg and D Hammar-wall ldquoNBIoT a sustainable technology for connecting billionsof devicesrdquo Ericsson Technology Review vol 4 pp 2ndash11 2016

[12] M Lauridsen I Z Kovacs P Mogensen M Sorensen andS Holst ldquoCoverage and capacity analysis of LTE-M and NB-IoT in a rural areardquo in Proceedings of the 2016 IEEE 84thVehicular Technology Conference (VTC-Fall) pp 1ndash5 MontrealQC Canada September 2016

[13] Sigfox httpwwwsigfoxcom[14] Weightless open standard httpwwwweightlessorg[15] Ingenu RPMA httpwwwingenucomtechnologyrpma[16] A Dunkels ldquoThe ContikiMAC radio duty cycling protocolrdquo

Technical Report T201113 Swedish Institute of ComputerScience 2011

[17] J Ko J Eriksson N Tsiftes et al ldquoIndustry Beyond interoper-ability - Pushing the performance of sensor network IP stacksrdquoin Proceedings of the 9th ACM Conference on Embedded Net-worked Sensor Systems SenSys 2011 pp 1ndash11 USA November2011

[18] D Moss J Hui and K Klues ldquoTEP 105 low power listeningrdquohttpwwwtinyosnettinyos-2xdocpdftep105pdf 2008

[19] C Gomez J Oller and J Paradells ldquoOverview and evaluationof bluetooth low energy an emerging low-power wirelesstechnologyrdquo Sensors vol 12 no 9 pp 11734ndash11753 2012

[20] A A Kandhalu A E Xhafa and S Hosur ldquoTowards bounded-latency bluetooth low energy for in-vehicle network cablereplacementrdquo in Proceeding of the International Conference onConnected Vehicles and Expo (ICCVE) pp 635ndash640 Las VegasNV USA 2013

[21] A Montanari S Nawaz C Mascolo and K Sailer ldquoA studyof bluetooth low energy performance for human proximitydetection in the workplacerdquo in Proceedings of the 2017 IEEEInternational Conference on Pervasive Computing and Commu-nications PerCom 2017 pp 90ndash99 Kona HI USA March 2017

[22] C Julien C Liu A L Murphy and G P Picco ldquoBLEnd Practi-cal continuous neighbor discovery for bluetooth low energyrdquo inProceedings of the 16th ACMIEEE International Conference onInformation Processing in Sensor Networks IPSN 2017 pp 105ndash116 New York NY USA April 2017

[23] Y Qiu S Li X Xu and Z Li ldquoTalk more listen less energy-efficient neighbor discovery in wireless sensor networksrdquo inProceedings of the 35th Annual IEEE International Conference onComputer Communications IEEE INFOCOM 2016 USA April2016

[24] A J Berni andW D Gregg ldquoOn the utility of chirpmodulationfor digital signalingrdquo IEEE Transactions on Communicationsvol 21 no 6 pp 748ndash751 1973

[25] A Springer W Gugler M Huemer L Reindl C C W Ruppeland R Weigel ldquoSpread spectrum communications using chirpsignalsrdquo in Proceedings of the IEEEAFCEA Information Systemsfor Enhanced Public Safety and Security EUROCOMM2000 pp166ndash170 Germany

[26] IEEE Std 80211-2007 ldquoIEEE Standard for Information Tech-nologymdashTelecommunications and Information Exchange be-tween SystemsmdashLocal and Metropolitan Area NetworksmdashSpecific Requirements Part 11 Wireless LAN Medium AccessControl (MAC) and Physical Layer (PHY) Specifications June2007rdquo

[27] RAK831 httpwwwrakwirelesscomenWisKeyOSHRAK831[28] LoRaWAN network server httpsgithubcomgotthardplor-

awan-server[29] ldquoLoRaWAN 11 Regional Parametersrdquo LoRa Alliance 2017

httpslora-allianceorgresource-hublorawantm-regional-pa-rameters-v11ra

Wireless Communications and Mobile Computing 13

Number of Nodes500 1000 1500 2000 2500 3000 3500 4000

10minus3

10minus2

Effici

ency

10minus1

100

101

Class B (＞ = 2)

Proposed (＞ = 2)

Class B (＞ = 8)

Proposed (＞ = 8)

Class B (＞ = 32)

Proposed (＞ = 32)

Figure 13 Efficiency of TRILO and Class B downlink protocol

periods On the contrary Class B protocol allocates 31 pingslots on average regardless of downlink demands In shortthe number of receive windows wasted by the Class B schemevaries depending on the amount of downlink traffic howeveronly busy devices use extra duty cycle for downlink traffic inTRILO

The Class B protocol does not coordinate traffic betweenuplinks and downlinks so that several uplinks can be dis-rupted by downlink transmissions due to the half-duplexcharacteristic of a LoRaWAN gateway all reception pathscan be blocked by downlink transmissions It can obstructthe proper operations of typical LoRaWANs where uplinktransmissions are predominant In contrast the proposedscheme is free from this problem because it isolates the timefor uplinks and downlinks periods

9 Conclusions

A plethora of LPWAN techniques such as LoRa SigFoxRPMA and Weightless have emerged as a new enablingnetwork technology for IoT applications that require low-rate low-cost and long lifetimes LPWANs allow end-deviceinitiated uplinks However to maximize the lifetime ofbattery powered end-devices nodes are put into the sleepstate such that rather restricted downlink communicationsare permitted In this paper we proposed a new downlinkprotocol named TRILO for LoRaWAN

Because LoRaWAN assumes a star topology where mul-tiple end-devices are connected to a single gateway weadopted a beacon based downlink mechanism similar to theIEEE 80211 PSM standard A gateway broadcast beaconsperiodically at every beacon period and end-devices are timesynchronized Beacons alert nodes with buffered downlinksin addition to synchronizing end-devicesrsquo clocks Customizedto the physical characteristics of LoRa we designed two

polling schemes concurrent polling and sequential pollingAn analysis indicates that sequential polling is more energyefficient than concurrent polling

We implement the proposed beacon based downlinkprotocol using commercially available components and con-duct experiments with modified devices Our performancestudy shows that Packet Delivery Ratio (PDR) is almost100 for both uplink and downlink traffic and the extrawake-up time to receive beacons and downlinks is minimalSimulation results also show that our proposed protocol canadaptively allocate receive windows resulting in lower energyconsumption

For further work we plan to investigate the impact ofour scheme on the networks with multiple gateways Alsodetailed investigations of impact of the number of downlinksand the certain distributions of SFs on the performanceseem interesting Optimization techniques leveraging SF andpower allocation are expected to affect the performance of theproposed scheme

Data Availability

The data used to support the findings of this study areincluded within the article

Disclosure

The funding sponsors had no role in the study in thecollection analyses or interpretation of data in the writingof the manuscript and in the decision to publish the results

Conflicts of Interest

The authors declare that there are no conflicts of interestregarding the publication of this paper

14 Wireless Communications and Mobile Computing

Acknowledgments

This work was supported by the National Research Founda-tion of Korea (NRF) Grant funded by the Korean Govern-ment (MSIP) (No 2016R1A5A1012966) Institute for Infor-mation amp Communications Technology Promotion (IITP)grant funded by the Korea government (MSIT) (No 2015-0-00557 ResilientFault-Tolerant Autonomic NetworkingBased on Physicality Relationship and Service Semantic ofIoT Devices) and the MSIP (Ministry of Science ICT andFuture Planning) Korea under the ITRC (Information Tech-nology Research Center) support program (IITP-2018-2015-0-00378) supervised by the IITP (Institute for Informationamp Communications Technology Promotion) Also the snu-samsung smart campus research center at Seoul NationalUniversity provides research facilities for this study

References

[1] M Bor U Roedig T Voigt and J M Alonso ldquoDo LoRalow-power wide-area networks scalerdquo in Proceedings of the19th ACM International Conference on Modeling Analysis andSimulation of Wireless and Mobile Systems MSWiM 2016 pp59ndash67 Malta November 2016

[2] DMagrinMCentenaro andLVangelista ldquoPerformance eval-uation of LoRa networks in a smart city scenariordquo inProceedingsof the 2017 IEEE International Conference on CommunicationsICC 2017 France May 2017

[3] LoRa httpswwwlora-allianceorgWhat-Is-LoRaTechnol-ogy

[4] ldquoLoRaWAN 11 specificationrdquo LoRa Alliance 2017 httpslora-allianceorgresource-hublorawantm-specification-v11

[5] M Bor J Vidler and U Roedig ldquoLoRa for the internet ofthingsrdquo in Proceedings of the International Conference onEmbedded Wireless Systems and Networks (EWSN rsquo16) pp 361ndash366 Junction Publishing 2016

[6] 3GPP ldquoStudy on provision of low-cost Machine-Type Commu-nications User Equipments based on LTErdquo TR 36888 V120006 2013

[7] 3GPP ldquoCellular system support for ultra-low complexity andlow throughput Internet of Thingsrdquo TR 45820 V1310 11 2015

[8] J Gozalvez ldquoNew 3GPP Standard for IoTrdquo IEEE VehicularTechnology Magazine vol 11 no 1 pp 14ndash20 2016

[9] R Ratasuk N Mangalvedhe and A Ghosh ldquoOverview ofLTE enhancements for cellular IoTrdquo in Proceedings of the 26thIEEE Annual International Symposium on Personal Indoor andMobile Radio Communications PIMRC 2015 pp 2293ndash2297China September 2015

[10] H Shariatmadari R Ratasuk S Iraji et al ldquoMachine-type com-munications current status and future perspectives toward 5Gsystemsrdquo IEEE CommunicationsMagazine vol 53 no 9 pp 10ndash17 2015

[11] S Landstrom J Bergstrom E Westerberg and D Hammar-wall ldquoNBIoT a sustainable technology for connecting billionsof devicesrdquo Ericsson Technology Review vol 4 pp 2ndash11 2016

[12] M Lauridsen I Z Kovacs P Mogensen M Sorensen andS Holst ldquoCoverage and capacity analysis of LTE-M and NB-IoT in a rural areardquo in Proceedings of the 2016 IEEE 84thVehicular Technology Conference (VTC-Fall) pp 1ndash5 MontrealQC Canada September 2016

[13] Sigfox httpwwwsigfoxcom[14] Weightless open standard httpwwwweightlessorg[15] Ingenu RPMA httpwwwingenucomtechnologyrpma[16] A Dunkels ldquoThe ContikiMAC radio duty cycling protocolrdquo

Technical Report T201113 Swedish Institute of ComputerScience 2011

[17] J Ko J Eriksson N Tsiftes et al ldquoIndustry Beyond interoper-ability - Pushing the performance of sensor network IP stacksrdquoin Proceedings of the 9th ACM Conference on Embedded Net-worked Sensor Systems SenSys 2011 pp 1ndash11 USA November2011

[18] D Moss J Hui and K Klues ldquoTEP 105 low power listeningrdquohttpwwwtinyosnettinyos-2xdocpdftep105pdf 2008

[19] C Gomez J Oller and J Paradells ldquoOverview and evaluationof bluetooth low energy an emerging low-power wirelesstechnologyrdquo Sensors vol 12 no 9 pp 11734ndash11753 2012

[20] A A Kandhalu A E Xhafa and S Hosur ldquoTowards bounded-latency bluetooth low energy for in-vehicle network cablereplacementrdquo in Proceeding of the International Conference onConnected Vehicles and Expo (ICCVE) pp 635ndash640 Las VegasNV USA 2013

[21] A Montanari S Nawaz C Mascolo and K Sailer ldquoA studyof bluetooth low energy performance for human proximitydetection in the workplacerdquo in Proceedings of the 2017 IEEEInternational Conference on Pervasive Computing and Commu-nications PerCom 2017 pp 90ndash99 Kona HI USA March 2017

[22] C Julien C Liu A L Murphy and G P Picco ldquoBLEnd Practi-cal continuous neighbor discovery for bluetooth low energyrdquo inProceedings of the 16th ACMIEEE International Conference onInformation Processing in Sensor Networks IPSN 2017 pp 105ndash116 New York NY USA April 2017

[23] Y Qiu S Li X Xu and Z Li ldquoTalk more listen less energy-efficient neighbor discovery in wireless sensor networksrdquo inProceedings of the 35th Annual IEEE International Conference onComputer Communications IEEE INFOCOM 2016 USA April2016

[24] A J Berni andW D Gregg ldquoOn the utility of chirpmodulationfor digital signalingrdquo IEEE Transactions on Communicationsvol 21 no 6 pp 748ndash751 1973

[25] A Springer W Gugler M Huemer L Reindl C C W Ruppeland R Weigel ldquoSpread spectrum communications using chirpsignalsrdquo in Proceedings of the IEEEAFCEA Information Systemsfor Enhanced Public Safety and Security EUROCOMM2000 pp166ndash170 Germany

[26] IEEE Std 80211-2007 ldquoIEEE Standard for Information Tech-nologymdashTelecommunications and Information Exchange be-tween SystemsmdashLocal and Metropolitan Area NetworksmdashSpecific Requirements Part 11 Wireless LAN Medium AccessControl (MAC) and Physical Layer (PHY) Specifications June2007rdquo

[27] RAK831 httpwwwrakwirelesscomenWisKeyOSHRAK831[28] LoRaWAN network server httpsgithubcomgotthardplor-

awan-server[29] ldquoLoRaWAN 11 Regional Parametersrdquo LoRa Alliance 2017

httpslora-allianceorgresource-hublorawantm-regional-pa-rameters-v11ra

14 Wireless Communications and Mobile Computing

Acknowledgments

This work was supported by the National Research Founda-tion of Korea (NRF) Grant funded by the Korean Govern-ment (MSIP) (No 2016R1A5A1012966) Institute for Infor-mation amp Communications Technology Promotion (IITP)grant funded by the Korea government (MSIT) (No 2015-0-00557 ResilientFault-Tolerant Autonomic NetworkingBased on Physicality Relationship and Service Semantic ofIoT Devices) and the MSIP (Ministry of Science ICT andFuture Planning) Korea under the ITRC (Information Tech-nology Research Center) support program (IITP-2018-2015-0-00378) supervised by the IITP (Institute for Informationamp Communications Technology Promotion) Also the snu-samsung smart campus research center at Seoul NationalUniversity provides research facilities for this study

References

[1] M Bor U Roedig T Voigt and J M Alonso ldquoDo LoRalow-power wide-area networks scalerdquo in Proceedings of the19th ACM International Conference on Modeling Analysis andSimulation of Wireless and Mobile Systems MSWiM 2016 pp59ndash67 Malta November 2016

[2] DMagrinMCentenaro andLVangelista ldquoPerformance eval-uation of LoRa networks in a smart city scenariordquo inProceedingsof the 2017 IEEE International Conference on CommunicationsICC 2017 France May 2017

[3] LoRa httpswwwlora-allianceorgWhat-Is-LoRaTechnol-ogy

[4] ldquoLoRaWAN 11 specificationrdquo LoRa Alliance 2017 httpslora-allianceorgresource-hublorawantm-specification-v11

[5] M Bor J Vidler and U Roedig ldquoLoRa for the internet ofthingsrdquo in Proceedings of the International Conference onEmbedded Wireless Systems and Networks (EWSN rsquo16) pp 361ndash366 Junction Publishing 2016

[6] 3GPP ldquoStudy on provision of low-cost Machine-Type Commu-nications User Equipments based on LTErdquo TR 36888 V120006 2013

[7] 3GPP ldquoCellular system support for ultra-low complexity andlow throughput Internet of Thingsrdquo TR 45820 V1310 11 2015

[8] J Gozalvez ldquoNew 3GPP Standard for IoTrdquo IEEE VehicularTechnology Magazine vol 11 no 1 pp 14ndash20 2016

[9] R Ratasuk N Mangalvedhe and A Ghosh ldquoOverview ofLTE enhancements for cellular IoTrdquo in Proceedings of the 26thIEEE Annual International Symposium on Personal Indoor andMobile Radio Communications PIMRC 2015 pp 2293ndash2297China September 2015

[10] H Shariatmadari R Ratasuk S Iraji et al ldquoMachine-type com-munications current status and future perspectives toward 5Gsystemsrdquo IEEE CommunicationsMagazine vol 53 no 9 pp 10ndash17 2015

[11] S Landstrom J Bergstrom E Westerberg and D Hammar-wall ldquoNBIoT a sustainable technology for connecting billionsof devicesrdquo Ericsson Technology Review vol 4 pp 2ndash11 2016

[12] M Lauridsen I Z Kovacs P Mogensen M Sorensen andS Holst ldquoCoverage and capacity analysis of LTE-M and NB-IoT in a rural areardquo in Proceedings of the 2016 IEEE 84thVehicular Technology Conference (VTC-Fall) pp 1ndash5 MontrealQC Canada September 2016

[13] Sigfox httpwwwsigfoxcom[14] Weightless open standard httpwwwweightlessorg[15] Ingenu RPMA httpwwwingenucomtechnologyrpma[16] A Dunkels ldquoThe ContikiMAC radio duty cycling protocolrdquo

Technical Report T201113 Swedish Institute of ComputerScience 2011

[17] J Ko J Eriksson N Tsiftes et al ldquoIndustry Beyond interoper-ability - Pushing the performance of sensor network IP stacksrdquoin Proceedings of the 9th ACM Conference on Embedded Net-worked Sensor Systems SenSys 2011 pp 1ndash11 USA November2011

[18] D Moss J Hui and K Klues ldquoTEP 105 low power listeningrdquohttpwwwtinyosnettinyos-2xdocpdftep105pdf 2008

[19] C Gomez J Oller and J Paradells ldquoOverview and evaluationof bluetooth low energy an emerging low-power wirelesstechnologyrdquo Sensors vol 12 no 9 pp 11734ndash11753 2012

[20] A A Kandhalu A E Xhafa and S Hosur ldquoTowards bounded-latency bluetooth low energy for in-vehicle network cablereplacementrdquo in Proceeding of the International Conference onConnected Vehicles and Expo (ICCVE) pp 635ndash640 Las VegasNV USA 2013

[21] A Montanari S Nawaz C Mascolo and K Sailer ldquoA studyof bluetooth low energy performance for human proximitydetection in the workplacerdquo in Proceedings of the 2017 IEEEInternational Conference on Pervasive Computing and Commu-nications PerCom 2017 pp 90ndash99 Kona HI USA March 2017

[22] C Julien C Liu A L Murphy and G P Picco ldquoBLEnd Practi-cal continuous neighbor discovery for bluetooth low energyrdquo inProceedings of the 16th ACMIEEE International Conference onInformation Processing in Sensor Networks IPSN 2017 pp 105ndash116 New York NY USA April 2017

[23] Y Qiu S Li X Xu and Z Li ldquoTalk more listen less energy-efficient neighbor discovery in wireless sensor networksrdquo inProceedings of the 35th Annual IEEE International Conference onComputer Communications IEEE INFOCOM 2016 USA April2016

[24] A J Berni andW D Gregg ldquoOn the utility of chirpmodulationfor digital signalingrdquo IEEE Transactions on Communicationsvol 21 no 6 pp 748ndash751 1973

[25] A Springer W Gugler M Huemer L Reindl C C W Ruppeland R Weigel ldquoSpread spectrum communications using chirpsignalsrdquo in Proceedings of the IEEEAFCEA Information Systemsfor Enhanced Public Safety and Security EUROCOMM2000 pp166ndash170 Germany

[26] IEEE Std 80211-2007 ldquoIEEE Standard for Information Tech-nologymdashTelecommunications and Information Exchange be-tween SystemsmdashLocal and Metropolitan Area NetworksmdashSpecific Requirements Part 11 Wireless LAN Medium AccessControl (MAC) and Physical Layer (PHY) Specifications June2007rdquo

[27] RAK831 httpwwwrakwirelesscomenWisKeyOSHRAK831[28] LoRaWAN network server httpsgithubcomgotthardplor-

awan-server[29] ldquoLoRaWAN 11 Regional Parametersrdquo LoRa Alliance 2017

httpslora-allianceorgresource-hublorawantm-regional-pa-rameters-v11ra

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom