c© 20XX by the authors; licensee RonPub, Lubeck, Germany. This article is an open access article distributed under the terms and conditions ofthe Creative Commons Attribution license (http://creativecommons.org/licenses/by/4.0/).

Open Access

Open Journal of Internet of Things (OJIOT)Volume X, Issue X, 20XX

http://www.ronpub.com/ojiotISSN 2364-7108

Data lifetime estimation in a multicast-basedCoAP proxy

Jelena Misic A, Vojislav B. Misic A, Xiaolin Chang B

A Ryerson University, 350 Victoria St., Toronto, ON, Canada, {jmisic, vmisic}@ryerson.caB Beijing Key Laboratory of Security and Privacy in Intelligent Transportation

Beijing Jiaotong University, Shangyuancun no. 3, Haidian District, Beijing, China, xlchang@bjtu.edu.cn

ABSTRACT

In this work we consider kernel-based record lifetime estimation in a proactive Internet of Things (IoT) proxywith multicast based cache management. Multicast refreshment requests were based on lifetime expiration for apredefined number of records. To reduce the traffic volume in the IoT domain, we assume that only nodes wherethe observed physical variable has changed its value will respond to the multicast request. For estimating the datalifetime at the proxy, we use Gaussian kernels, assuming that the intrinsic data lifetime probability distribution wastaken from Erlang-k family of sub-exponential distributions. In this setup, we consider that the proxy connects tothe IoT domain using an IEEE 802.15.4-compatible wireless network. Results indicate that narrow and symmetricallifetime probability distributions require more frequent multicasting refreshments compared to wider and asymmetricones. This increases traffic intensity and energy consumption in IoT domain. We quantify finding with numericalresults.

TYPE OF PAPER AND KEYWORDS

Regular research paper: Internet of Things, CoAP, multicast proxy, cache maintenance

1 INTRODUCTION

The introduction of Constrained Application Protocol(CoAP) [15] has led to the proliferation of versatileapplications over a large number of smart devices. CoAPacts as the application layer protocol that works over theUDP/IP protocol stack which facilitates evolution andintegration of sensor and actuator networks to bring theInternet-of-Things (IoT) vision to life. CoAP supportsthis vision through asynchronous message exchangewith optional reliability, publish-subscribe paradigm,multicasting, and resource discovery in both IPv4 andIPv6-based network environments. It thus allows theubiquitous Web paradigm in which servers providecontent to Internet clients to be replicated in an IoTnetwork environment comprised of smart nodes that

provide sensed data on demand to clients from theInternet [6].

However, IoT networks and applications face a setof challenges that differ from those encountered intraditional web scenarios. First, IoT server nodes havelimited computational capabilities and they typicallyoperate on battery power; this severely constrains thechoices available to the designers of IoT networks.Second, most IoT applications require a certain level offreshness of sensed data in order to function correctly;this complicates the data collection protocols. Finally,allowing IoT server nodes to be contacted directly byclients opens security vulnerabilities. All of thosechallenges can be addressed through the use of proxiesthat interconnect low power, low data rate wirelessnetworks of IoT devices to other, higher capacity

1

Open Journal of Internet of Things (OJIOT), Volume X, Issue X, 20XX

wireless or even wired networks and provides thenecessary protocol translation. The clients thus seethe proxy as a traditional web server where the data isactually created by the IoT servers behind it.

The proxy typically maintains a cache to store datareadings sent by the IoT server nodes. The use ofcache reduces latency for the clients, but also savescommunication bandwidth in the IoT domain and energyexpenditure of IoT server nodes. In the simplest case,proxy will respond to client requests with cached data,if it is fresh, or request data from the appropriate IoTserver node, if not. In the proactive mode, proxy willmonitor the freshness of cached data and issue requeststo refresh it when needed, without an explicit clientrequest. The proxy can also operate in reverse mode inwhich IoT server nodes send data to the proxy when thedata becomes stale (i.e., obsolete) or when the monitoredphysical variable changes. Oftentimes these operationmodes are combined in the so-called hybrid proxies.

In all cases, the notion of data freshness is crucialfor the timely operation of the proxy. To supportmonitoring of data freshness, CoAP allows IoT servernodes to annotate the data they send with a Max Agevalue indicating the data lifetime. This allowsthe proxy to decide whether to service a client’srequest with cached data or to request the datafrom the server node. However, in many scenariossensed data is parameterized: for example, insteadof periodically reporting the exact data reading, theserver node can report whether the value has crossedsome threshold. This approach reduces the number ofmessages exchanged between the IoT server and theproxy, and further reduces communication bandwidthand energy.

In both periodic and parameterized reporting, theproxy can use the data lifetime value to refresh its cache.However, parameterization turns the data lifetime intoa random variable and effectively precludes the servernode from providing information about data lifetime.The latter case requires estimation of the probabilitydistribution of the data lifetime. Estimation has to bedone at the proxy since server nodes typically do notpossess the required computational resources [19]. Theuse of multicasting [12] enables the proxy to wait untilan entire group of data records become stale and refreshthem using a single multicast GET request, which wasfound to be most efficient in terms of communicationsbandwidth and latency [7].

The focus of the present work is lightweight datacollection and cache refreshment by a CoAP proxyoperating in reverse mode, with the objective of reducingthe volume of wireless traffic on the IoT side. It buildsupon our previous work [8] but extends it significantly inseveral directions, as follows.

• We assume that data lifetime follows asubexponential probability distribution fromErlang-k family which is more realistic than theexponential distribution used in the earlier work.

• We deploy data lifetime estimation at the proxy anduse it to estimate when data record might becomestale i.e. when it exceeds threshold value.

• The proxy performs data lifetime estimation usingkernel smoothing [17] which is a computationallyefficient technique to find structure in data setswithout a predefined parametric model.

• Data coming from IoT nodes present a group-based observation stream combining the conceptsof multicasting [12] and observations [3]. Namely,multicast requests are sent when a number ofcached data values exceed their estimated lifetimethreshold, and IoT server nodes reply to multicastrequests after a random leisure period. As theresult, this approach provides adhoc and implicitmulticast subgroups within the IoT domain, sinceonly a limited number of nodes will send their replyto a multicast request.

This scheme distributes node replies over time andalleviates potential congestion in the domain. Tothe best of our knowledge this scenario has not beenconsidered in the earlier work. We model and analyzethe IoT domain performance under variable distributionsof lifetime, size of stale record group, and number ofnodes in the domain.

The paper is organized as follows. Section 2 givesbasic notions about CoAP and multicasting, whileSection 3 describes in detail the operation of themulticasting proxy at the IoT gateway. In Section 4we present kernel based technique for data lifetimeestimation and use it to estimate data lifetime andanalyze the stale time of a record in Section 5, followedby the estimation of the period between multicastingrequests in Section 6. Section 7 presents the results ofperformance evaluation within the IoT domain, precededby a short discussion of communications in IoT domain.Finally, Section 8 concludes the paper.

2 COAP AND MULTICAST COAP

Constrained Application Protocol (CoAP) is alightweight replacement for HTTP that follows theRepresentational State Transfer (REST) paradigm[2] and implements a subset of HTTP methods,namely GET, PUT, POST and DELETE. CoAP isspecifically tailored to support machine to machinecommunications (M2M) in IoT networks by providing

2

Jelena Misic, Vojislav B. Misic, Xiaolin Chang: Data lifetime estimation in a multicast-based CoAP proxy

resource discovery, asynchronous communications,multicasting and observation streams of data [15].Unlike HTTP which operates using TCP as its transportprotocol, CoAP uses UDP for efficiency reasons:UDP provides basic functions such as protocol portmultiplexing and error checking, contrary to TCP whichhas built-in reliability, congestion control and flowcontrol. Congestion and flow control are not (yet) theparamount issues in IoT due to comparatively smalltraffic volume, but reliability is a crucial propertythat could not be left to the applications – it had tobe provided within CoAP itself. Therefore CoAParchitecture may be considered to have two layers: theupper layer deals with requests and responses througha number of methods, while the lower one implementsreliable message transfer over UDP.

To this end, the messaging layer labels eachmessage as confirmable (CON) or non-confirmable(NON). CON messages must be acknowledged withan acknowledgement message (ACK). UnrecognizedCON messages will provoke the recipient to send areset message (RST). Reliability is achieved using asimple stop-and-wait protocol with exponential backoffmechanism that will repeat the message in case an ACKmessage is not received within the predefined timeout.CON message and its ACK are related through themessage ID which is part of the regular message header.

The upper, method layer uses services of themessaging layer to transmit CoAP methods andresponses. In the simplest case, request will be sentas a CON message and response will be piggybackedonto the ACK message. However, it is possible that theIoT server node cannot provide the response as part ofthe acknowledgement. In such cases, response will besent later in a separate CON message which needs to beacknowledged by the recipient (client or proxy). As themessage ID of the response message is different fromthat of the CON request, the asynchronous request andresponse are linked through the value of a token that wasprovided in the header of the initial request message. Atoken is valid until the response is received, or its lifetime(the default value of which is 250 seconds) expires.

Requests and responses can also be sent as non-confirmable messages, again linked by the same tokenvalue. This approach makes perfect sense if there are fewhops between the message source and recipient, and theunderlying data link layer supports reliable messaging.For example, in IEEE 802.15.4 and IEEE 802.11ahstandards, in acknowledgement mode, a packet can bere-transmitted several times before failure is declared [9].

2.1 On proxy operation and multicasting

CoAP encourages proxying with caching since thisreduces network traffic, facilitates access to devices inpower saving mode (sleep) and provides resource hidingtowards the rest of Internet which improves security.Moreover, it is simpler and more secure if the IoT nodeperforms (mutual) authentication with the proxy thanwith an arbitrary client.

To reduce bandwidth usage and energy consumptionof IoT server nodes which are, more often than not,battery operated, CoAP provides two special features.One of these is the observation mode [3] which isessentially a publish-subscribe relationship in whichthe proxy subscribes to notifications from a single IoTserver node using a GET method with the appropriateoption (-observe). The server’s positive responseindicates a promise to send notifications whenever thevalue of the observed physical variable changes. Theproxy may request the data repeatedly; the server cansend the data more often or even periodically. Eitherside may terminate the relationship, but the proxy mustoccasionally confirm its continuing interest in receivingthe notifications. Note that this feature enables thereverse-mode operation of the proxy described above.

The other special feature is multicasting [12, 15]which may be considered as a CoAP extension that aimsto improve scalability and efficiency. Multicast can berun in link-local mode over the IoT domain reachableover single hop, or over multiple hops beyond link-local scope provided forwarding nodes are capable ofmulticast routing.

Multicast request is sent as a multicast GET (mGET)method addressed to the IP multicast address and it iscarried in a non-confirmable message. Servers reply innon-confirmable unicast with data, in which case theresponse token must match the request token. If therequested resource is not found, the server may replyaccordingly or simply withhold the response [12].

Application based multicast groups can be pre-configured or created and deleted dynamically. Dynamiccreation of groups can be done by special configurationnode (e.g proxy). Information about group membershipin link-local environment can be created/updated/deletedby special node (proxy) and communicated to thenode(s) using PUT method. Addition of new multicastgroup for the node(s) can be done using POST method.Differentiation among multicast groups can be doneby different IPv4/IPv6 multicast addresses or by UDPprotocol ports different from the default one (5683).

Forming multicast groups is crucial for furthermulticast operation. Membership of multicast groups iscreated according to the application needs, to performresource discovery, or to access physical variables sensed

3

Open Journal of Internet of Things (OJIOT), Volume X, Issue X, 20XX

in locations defined with Universal Resource Identifier(URI). Clients can have a pre-configured list of groupsor they can learn about multicast groups using servicediscovery, either using the default multicast group ‘AllCoAP nodes’ [1] or via DNS-based service discoveryat default UDP protocol port 5863 [11, 12, 13, 14].Servers that have joined the multicast group then respondwith links that correspond to entry points to resourceinterfaces they host. Resource discovery needs to berepeated periodically because nodes may join or leavethe multicast group. Core link format described in[11, 14] also supports query filtering but we do not modelthis feature in the present work.

Token management is an important issue whenmulticasting is used. Namely, in unicast mode, receptionof reply from IoT node frees the token value, but inmulticast it can be released when ‘most’ of the replieshave been received. Also, the token lifetime limits thenumber of tokens that can be kept ‘alive’ at any giventime.

3 MULTICASTING PROXY WITH DATALIFETIME ESTIMATION

We assume that nodes in the IoT domain estimatehomogeneous variables and that the proxy has anestimate of data freshness, initially obtained when thenodes (some of them, at least) begin by using POSTmethod to update the corresponding records in the cache.In case IoT nodes report readings of heterogeneousvariables or several distinct physical variables (e.g.,temperature and humidity), the model has to be extendedwith multiple traffic classes, but the operation of themodel would remain the same for each traffic class.

3.1 Proxy operation

Operation of a multicasting proxy with estimation of datalifetime is schematically shown in Fig. 1 for the IoTnetwork with five nodes. Circles with inscribed numberscorrespond to important events, as described below.

The proxy periodically checks the freshness of cachedata against the current freshness estimate. Event 1corresponds to the moment When the number of stalerecords, i.e., those for which the lifetime has exceededthe current estimate, reaches a predefined threshold θ(equal to 2 in the example shown in the figure). Then,the proxy issues a multicast GET request (mGET) to thelocal IoT domain to refresh the data (event 2) which allnodes receive.

However, nodes do not respond to it immediately.Instead, each node waits for a randomly chosen leisuretime period L [15] and then checks the physical variableof interest. If its value has changed from the last reading,

the node responds to the mGET request with a ‘2.05content’ message containing newly read data (event 3).Upon receiving this value, the proxy updates the cachedrecord and resets the freshness timer (event 4). Thecached data is immediately available to respond to clientrequests.

The leisure time spreads node responses over timewithin a predefined leisure time window (to be explainedin detail below) which reduces the contention andthe resulting transmission failures in the wireless IoTdomain [15]. The original documentation actually asksfor data reading to be performed prior to starting theleisure interval timer countdown. However, switchingthe order of those actions ensures that the datatransmitted is more fresh, as it may change its valueduring the leisure countdown. Furthermore, the wait-then-sense ordering does not affect the latency of datareceived at the proxy as it receives the data only after theleisure period in both scenarios.

It is also possible that the value of the physical variablehas not changed since the last reading (event 5). In thiscase, the IoT server simply ignores the mGET requestand remains silent. This reduces the volume of trafficin the wireless domain and energy expenditure of servernodes.

This procedure is repeated every time the proxy notesthat the number of stale records reaches the threshold θ,as shown in the second and third mGET cycle in Fig. 1.Each multicast request actually presents a differenttoken value to with the objective of synchronizing andrefreshing data values at the cache.

Sometimes a node will record and subsequentlytransmit a new data value even if the freshness periodof the cached data value has not exceeded the lifetimeestimate (event 6). In this case, the proxy simplyoverwrites the cached data value and resets it lifetimeestimate.

In all cases, nodes that reply to a mGET request labeltheir responses using the token of the most recent mGETrequest. As the result, node reports can be groupedby node IP address and, within the group, by tokens.Token value can be numbered sequentially or as afunction of time to further simplify data processing. Thisapproach introduces virtual partitioning of the multicastgroup with evenly distributed replies, compared to thetraditional approach in which every node in the domainhad to reply to a mGET request [8].

3.2 Further observations

It is worth noting that the technique described aboveis somewhat similar to observation mode but with animportant difference. Regular observation mode isa relationship between the proxy and a single IoT

4

Jelena Misic, Vojislav B. Misic, Xiaolin Chang: Data lifetime estimation in a multicast-based CoAP proxy

Reverse Proxyw/ proactive refresh

Cached

data

Server

1refresh process

Server

2

Server

3

Server

4

Server

5

1 2 3 4 5

CoAP OK newdata

CoAP OK newdata

CoAP OK newdataCoAP OK newdata

CoAP OK newdata

CoAP OK newdata

CoAP mGET data

CoAP mGET data

CoAP mGET data

CoAP OK newdata

1

2

34

5

Note: time intervals to the right of activity lines denote leisure times randomly chosen by each IoT server node

1

2

2

34

3

6

5

5

1

Figure 1: Pertaining to the operation of multicast proxy.

server node; in our approach, the entire multicast groupeffectively participates in the observation. Compared toregular CoAP multicast, this scheme actually reduces thevolume of traffic in the IoT domain since only nodeswhich obtain new data values between two consecutivemGET requests with tokens tn and tn+1 will reply to themGET request with token tn. This may be consideredas a form of reply suppression which was recommendedin [12] but without directions how to implement it inpractice. The reply would be sent in a non-confirmablemessage with reply code ‘2.05 content’ and the new datavalue; any other outcome will be suppressed by IoTserver.

3.3 Protocol design

Regarding protocol design of the proxy, we assumethat the protocol stack consists of application, transportand network and data link layers, with the last oneimplemented on the networking adapter. Similar layeredarchitectures were proposed in [6, 18]. Fig. 2 shows thestage that corresponds to proactive cache operation.

Network and protocol layers are each served withone upwards and one downwards thread. Applicationlayer has multiple concurrent threads for record readingand one for record updating. Although time intervalsbetween mGET requests do not follow exponentialdistribution, due to the low request rate and combinationwith replies to POST methods we can approximate

5

Open Journal of Internet of Things (OJIOT), Volume X, Issue X, 20XXb

usi

ne

ss l

og

ic

DATABASE

1 – Pt

PtµBR

proactive refresh

µBRµBR µBW

search / retrieval

update

µBR

user

Figure 2: Queuing stages of the proxy with proactivecache refresh.

downlink traffic as Poisson. Traffic in the uplinkdirection can also be approximated as Poisson due tothe presence of leisure time in replies and existence ofmessages with POST methods. Queuing analysis ofthese three layers is presented in detail in [8] and it willnot be repeated here.

4 KERNEL BASED ESTIMATION OF RANDOMVARIABLES

The proxy performs record lifetime estimation usingkernel based technique [17]. To achieve reliableestimation of probability distribution function (pdf) ofrecord lifetime, the proxy needs to collect a large number(of the order of several hundreds) of inter-POST periodsand find optimal bandwidth for estimation. In thiswork we assume that record lifetime is subexponential,more precisely we assume that it follows family ofErlang-k probability distributions [5]. We considerthis approach to be more realistic compared to theexponential distribution which we used in our previouswork [8, 10]. So far many kernel functions can be usedsuch as Epanechnikov, Biweight, Triweight, Gaussian,triangular and uniform [17]. In this work we useGaussian kernel G(t) = 1√

2πe−

t2

2 due to ease ofanalytical manipulations.

Gaussian kernel has the variance and integral of itssquare value, respectively, given by

µ2(G) =

∫ ∞−∞t2G(t)dt = 1 (1)

R(G) =

∫ ∞−∞

G(t)2dt =1

2√π

(2)

Expression (1) has the variance and standard deviationof one and in practical cases it has to be scaledaround measurement points according to the inter-pointdistance. Therefore we need to work with the gaussian

kernel which has variance equal to b2 as:

Gb(t) =1

b√

2πe−

t2

2b2 =1

bG

(t

b

)(3)

with µ2(Gb) = b2 and R(Gb) = 12b√π

The standarddeviation value b is also known as the estimationbandwidth and it is very important for the quality ofestimation. With the known bandwidth and in thepresence of n measurements, probability distribution ofrandom variable under observation can be obtained asthe sum of kernels positioned around the measurementdata. For example, if we are estimating probabilitydistribution of data lifetime at the proxy and we havecollected n measurements of data lifetime denoted asTl,i, i = 1 . . . n, its pdf can be estimated by

Tl(t) =1

n

n∑i=1

Gb(t− Tl,i)

=1

nb√

2π

n∑i=1

e−(t−Tl,i)

2

2b2 (4)

Quality of estimation is evaluated in two steps.First the mean squared error (MSE) related to singlemeasurement point is calculated:

MSE(Tl) = E(Tl(t)− Tl(t))2

= (ETl(t)− Tl(t))2 + E(Tl(t)− ETl(t))2

= Bias(Tl(t))2 + V ar(Tl(t)) (5)

After that mean integrated squared error (MISE) iscomputed based on whole measurement space:

MISE( ˆTl(t)) =

∫ ∞−∞

MSE(Tl(t))dt (6)

=

∫ ∞−∞Bias(Tl(t))

2dt+

∫ ∞−∞V ar(Tl(t))dt

However, finding appropriate bandwidth requiresfurther calculations. Optimal bandwidth is determinedby minimizing mean integrated squared error (MISE).In order to find minimum in a computationally feasibleway, expression (6) for MISE has to be simplified byperforming a Taylor series expansion from which onlythe most important members are retained:

MISE( ˆTl(t)) ≈1

4b4µ2(G)2R(Tl(t)

′′) +R(G)

bn(7)

which renders itself to derivation of bandwidth that givesthe minimal MISE as

bopt =

(R(G)

nµ2(G)2R(T ′′l )2

)1/5

(8)

6

Jelena Misic, Vojislav B. Misic, Xiaolin Chang: Data lifetime estimation in a multicast-based CoAP proxy

In case of Gaussian kernels previous expressionbecomes:

bopt,g =

(1

2√πnR(T ′′l )2

)1/5

(9)

Optimal bandwidth for data that is distributed close tothe normal distribution is obtained by further substitutingR(T ′′l ) for normal distribution:

bns,g = σ

(8√πR(G)

3µ2(G)2n

)1/5

= σ

(4

3n

)1/5

(10)

where for large number of data points σ denotesstandard deviation. If the data sample is not largethen smaller between standard deviation of data samples2 = 1

n−1∑ni=1(Tl,i − Tl) and scaled interquartile

range R. Interquartile range contains 50% of datasamples. If interquartile range is used instead of standarddeviation then data outliers can not significantly affectthe optimal estimation bandwidth. Therefore we usedσ = min(R/1.34, s).

For example for Erlang-k distribution using Gaussiankernels optimal bandwidth can also be calculated bycomputing R(f ′′) and plugging it in (9).

However, if the original probability distribution is notknown, value R(T ′′l )2 in (8) is not known either andfurther estimation is needed. First step in this estimationis

Tl′′(t) =

1

b3n

n∑i=1

G′′(t− Tl,ib

)(11)

Then we apply biased cross validation (BCV) to findR(Tl

′′) [17], based on computing convolution between

the two kernels, as

R(Tl′′(∆)) =

1

n2

n∑i=1

n∑j=1

∫ ∞w=−∞

G′′b (∆i,j − w)G′′b (w)dw

=1

n2

n∑i=1

n∑j=1,j 6=i

(G′′b ∗G′′b )(∆i,j) (12)

Calculating the minimal value of MISE requires iterativecomputation of expression (12) for a range of bandwidthvalues (starting with well known oversmoothedbandwidth [17]) and computation of MISE as

MISEBCV (b) =1

4b4µ2(G)2R(Tl

′′) +

R(G)

bn(13)

and the bandwidth which results in smallest MISE isselected for estimation as bBCV .

Table 1: Approximations of optimal bandwidth.

distribution bns,g berlangK,g bBCVErlang-2 0.193 0.107 0.134Erlang-3 0.172 0.104 0.124Erlang-4 0.15 0.112 0.119Erlang-5 0.132 0.109 0.119

5 ESTIMATION OF RECORD LIFETIME

In our experiments we have considered Erlang-k, k =2 . . 5, distributions of data lifetime with mean value ofTl = 1 minute (60s). Data samples of lifetime wereobtained using Maple’s Statistics package. Estimationwas done on a sample of 500 measurements.

Fig. 3 shows the estimation of pdf for the data lifetimewhere red circles present mathematical expression, andblack line shows estimation with optimal bandwidthderived from BCV algorithm. Brown dashed linepresents estimation using bandwidth bns,g , appropriatefor normal distribution [17]. We notice that optimalbandwidth provides best estimation but estimation withbns,g (when k > 2) provides estimation close to optimaland leads to lightweight lifetime distribution estimation.Table 1 presents values of bandwidth corresponding tonormal and Erlang-k distributions respectively as wellas optimal bandwidth calculated using BCV approach.The reason why the values become closer as the degreeof distribution increases lies in the fact that Erlang-kdistributions with increasing value of k have smallercoefficients of skewness and kurtosis which means thatthey are reasonably symmetrical around the mean andhave fast decaying tails. From this estimation we cancompute higher moments of data lifetime and use themto determine the threshold Thr after which the recordis considered as outdated. Mean value and standarddeviation can be found as

Tl =

∫ ∞0

tTl(t)dt =

∫ ∞0

1

n

n∑i=1

tGb(t− Tl,i)

σ(Tl) =

(∫ ∞0

1

n

n∑i=1

(t− Tl)2Gb(t− Tl,i)

)1/2

As explained in Section 3 above, we consider therefreshment policy where the proxy checks for θoutdated records and then sends a multicast GET request.Fig. 4 shows the details of data lifetime expirationbetween two subsequent mGET requests for a cache witha limit of θ = 2 records that can become stale beforeissuing the next mGET request. From Fig. 4 we canmake the following observations:

7

Open Journal of Internet of Things (OJIOT), Volume X, Issue X, 20XX

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

–2 –1 1 2 3 4 5 6t

(a) Erlang-2 distributed data lifetime.

0

0.2

0.4

0.6

0.8

–2 –1 1 2 3 4 5 6t

(b) Erlang-3 distributed data lifetime.

0

0.2

0.4

0.6

0.8

–2 –1 1 2 3 4 5 6t

(c) Erlang-4 distributed data lifetime.

0.2

0.4

0.6

0.8

–2 –1 1 2 3 4 5 6t

(d) Erlang-5 distributed data lifetime.

Figure 3: Estimation of pdf for record lifetime.

R1

mGETn

reached

q=2

TL-

mGETn+1

L1

L2

Thr

Thr

R2

Figure 4: Timing of refresh requests and responsesfor threshold of θ = 2 records.

• Moment of generation of data Ri+1 is a randompoint in lifetime of data Ri. Distance between twosuccessive data generation pointsRi andRi+1 fromthe point of view of renewal theory [4] is known aselapsed data lifetime with probability distributionTl,−(y).

• Given that the threshold value is changing slowly,i.e., it is constant over a period of time whichis large compared to the threshold itself, thedistances between two consecutive moments whenvalue of freshness threshold is exceeded have sameprobability distribution of elapsed data lifetimeTl,−(y).

The value of data freshness threshold should bechosen to satisfy two goals. First, it should be largeenough to prevent too frequent refresh requests. Second,it should be low enough so that the group refresh policydescribed below triggers a refresh request while most ofthe data records are still sufficiently fresh so that clientdata requests are still served with valid data. In ourwork, we calculate the threshold value using the meanand standard deviation of estimated data lifetime as

Thr = mTl + lσ(Tl) (14)

where 0 < m ≤ 1 and 0 < l ≤ 3.Probability density function (pdf) of elapsed data

lifetime [16] can be computed as

Tl,−(y) =1

Tl

∫ ∞t=y

Tl(t)dt (15)

with mean value and standard deviation obtained as

Tl,− =

∫ ∞y=0

yTl,−(y)dy (16)

and

σ(Tl,−) =

∫ ∞y=0

(y − Tl,−)2Tl,−(y)dy, (17)

8

Jelena Misic, Vojislav B. Misic, Xiaolin Chang: Data lifetime estimation in a multicast-based CoAP proxy

respectively. The total (threshold based) stale time for θrecords is the sum of θ − 1 elapsed lifetimes, with meanvalue of (θ − 1)Tl,−.

We also need to include the impact of the leisureperiod. As discussed in Section 3, each node will starta leisure period countdown after the mGET request; iffresh data is present at the time the countdown ends,it will be transmitted to the proxy. We assumed thatthe window for leisure period takes a fixed portionWL = (θ − 2)Tl,− of the period between multicastrequests, so that the ratio WL/TMGET = (θ − 2)/θ.The reply window period WL is divided in slots ofduration tboff which match the backoff period of theunderlying medium access control (MAC) protocol (seenext Section), so the number of slots is ns = WL

tboff. Each

node selects its slot – effectively, the leisure time periodL – following a uniform distribution with probabilitygeneration function (PGF) of

N(z) =

ns−1∑i=0

1

ns(z)i (18)

and mean leisure time becomes L = tboffN .Since leisure time is much longer than the backoff at

the MAC layer, the probability that i-th record in groupof θ records is stale can be obtained as

Pst(i) =

∫ Thr+(i−1)Tl,−+L

t=0

Tl(t)dt (19)

and find mean probability that any record is stale, i.e.,that it exceeds the threshold value, as

Past =1

θ

θ∑i=1

Pst(i). (20)

Fig. 5 shows mean value of the total estimatedstale time, expressed in minutes, and its coefficient ofvariation and probability that any record is stale whenThr = Tl. Parameter of Erlangian distribution forlifetime was varied between 1 and 6, and record groupsize was varied from 2 to 10. We notice that mean recordstale time increases with the record group size which isexpected. However it decreases with the parameter ofErlangian distribution since the elapsed record lifetimedecreases with the distribution parameter. Coefficientof variation of total stale time decreases both with theincrease of record group size and parameter of Erlangiandistribution of lifetime. Finally, the probability that anyrecord is stale (according to the threshold) shows a milddecrease when Erlangian parameter is increasing but arapid increase with increase of group size.

6 ESTIMATION OF RATE OF MULTICASTGET REQUESTS

Let us now we look into the situation when groups ofθ records become stale in sequence, and thus result ina sequence of mGET requests. Clearly the time periodbetween two consecutive mGET requests is the sum ofθ elapsed data lifetimes. Probability distribution of thistime can be found as a θ-fold convolution of elapsed datalifetime. Since data records are homogeneous, elapseddata lifetimes are i.i.d. variables, and mean and varianceof the sum is equal to the sum of means and variancesrespectively. Therefore mean period between multicastget requests and rate of requests are

TMGET = θTl,−

λmGET =1

TMGET(21)

Although all nodes in the IoT domain served bythe proxy belong to the same multicast group, onlynodes where the physical variable has changed the valuebetween the previous and current multicast will sendreplies. Given the randomness of data lifetime andimperfection of estimation, it is possible that morethan θ nodes will reply but that number will still beconsiderably smaller than the number of nodes in the IoTdomain.

Possible transmission collisions from IoT nodes(besides the addition of a random leisure periodbefore each transmission) are further resolved using thecontention resolution mechanism(s) of the underlyingMAC protocol. This approach ensures that all responsesarrive at the proxy within a time period equal to thesum of leisure period and maximum backoff periodof the MAC algorithm. Therefore, under unsaturatedMAC operation, it is almost impossible for a reply to amulticast request with token tn to be delayed for so longthat it eventually arrives during the reply period of nextrequest with tn+1. This means that the token tn can besafely released when a new request is issued.

We will now show how to approach modeling ofuplink and downlink packet rates, assuming there arend nodes in the IoT domain. We note that estimationof data lifetime distribution at the proxy requires POSTmethods from small number, e.g., 10% of nodes. Replyto the POST method is CoAP reply ‘2.01 created’. Thedownlink rate from proxy application layer, throughprotocol and network layer, to wireless medium is only

λdsp = λMGET + 0.1ndλl (22)

where λl = 1Tl

is mean data update rate. In theuplink direction, there are estimation POST messagesand replies to multicast request which is non-confirmable

9

Open Journal of Internet of Things (OJIOT), Volume X, Issue X, 20XX

mean total stale time

12

34

56 2

46

810

0

2

4

6

8

parameter of

Erlang distribution

size of the

record group q

(a) Mean total stale time.

coefficient of variation of total stale time

12

34

56

24

68

0.30.40.50.60.70.80.9

1

parameter of

Erlang distribution

size of the

record group q

(b) Coefficient of variation of total stale time.

probability that any

record is stale

12

34

56 2

46

810

0.6

0.7

0.8

0.9

size of the

record group qparameter of

Erlang distribution

(c) Probability that any record in the group isstale according to the threshold.

Figure 5: Descriptors of total record stale time.

as are the replies. (Lack of reliability is not a bigproblem since the MAC layer supports it through re-transmissions.) Their total rate is

λusp = nλMGET + 0.1ndλl. (23)

These values can be used to find upstream anddownstream delays, respectively, in IoT proxy stages.

The downlink rate towards the IoT node contains onlymulticast GET methods and replies to POST methods,while the outgoing rate from the IoT node is comprisedof replies to mGET requests and estimation POSTmethods. Then the rate from IoT node towards the proxyis

λtot = λMGET + 0.1λl. (24)

7 PERFORMANCE EVALUATION

7.1 Model of communications

We consider a single-hop 6LoWPAN over IEEE802.15.4 cluster with acknowledged transfer. Thecluster operates in the ISM band at 2.4GHz withraw data rate 250kbps, set up so that period betweenthe beacons is BI = 0.98s. Thus, IoT nodes canwake up every 0.98s to hear the information fromthe beacon which contains list of nodes with pendingdownlink traffic. Backoff parameters such as theminimum backoff exponent, the maximum value ofthe backoff exponent and the maximum number ofbackoff attempts are set to their default values ofmacMinBE=3, aMaxBE=5 and macMaxCSMABackoffs= 4, respectively, as specified in [9]. Thus we canassume that in the network with a reasonably low biterror rate of BER = 10−5 and nodes that send a singleCoAP message every 1min (60 seconds) on the average,four retransmission attempts should provide sufficientreliability to compensate for the lack of CoAP reliability

due to nonconfirmable messages. Packet size is 127bytes, including 6LoWPAN, UDP and CoAP headers.

The operation of the MAC layer in this setting canbe evaluated using an analytical model, but we do notpresent it here as its detailed derivation is available in [9]and its application to multicasting proxy is presented in[8].

7.2 Performance results

We have evaluated the performance of multicastingproxy with three distributions of data lifetime, namelywith Erlang-2, -3, and -4 distributions with the samemean value of Tl = 60s. Proxy used proactive refreshingof data with multicasting requests. The number of stagesat proxy was three [6], and mean stage execution timewas set to 1

µ = 5ms.IoT proxy sends a mGET request when θ = 2 . . 10)

data records become stale. Threshold for data freshnessis set to Thr = Tl = 60s. The number of IoT devices wasvaried between 100 to 200. We assumed bit error rate of10−5 and 6LoWPAN packet size of 127 bytes. We didnot use any explicit leisure time since its role has beenfulfilled by the elapsed data lifetime.

We present round trip time, probability of successfultransmission and daily energy consumption per sensorfor three probability distributions of data lifetime namelyErlang-2, -3, and -4. Results are shown in Figs. 6,7 and 8, respectively. We observe that the round triptime with included leisure period decreases when theparameter of Erlangian distribution increases. Thisis a consequence of decreased period between mGETrequests due to the decrease of elapsed lifetime value.Related result is increase of daily energy consumptionper device when the parameter of Erlangian distributionis increasing since mGET request rate is increasing.Energy expenditure decreases with the increase of thenumber of IoT devices since one downlink mGET

10

Jelena Misic, Vojislav B. Misic, Xiaolin Chang: Data lifetime estimation in a multicast-based CoAP proxy

100120

140160

180200 2

46

810

1

2

3

4

IoT server nodesq (max. number

of outdated records)

RTT with leisure time

(a) Round trip time (in seconds).

probability that a single

transmission is successful

100120

140160

180200

24

68

10

0.98740.98760.98780.988

0.98820.9884

IoT server nodes

q (max. number

of outdated records)

(b) Transmission success probability.

100120

140160

180200 2

46

810

280

290

300

310

daily energy

expenditure

IoT server nodesq (max. number

of outdated records)

(c) Mean daily energy expenditure (in Joules)by the IoT node.

Figure 6: Proxy performance with Erlang-2 distributed data lifetime for uniformly generated leisure timewithin the leisure period.

100120

140160

180200 2

46

810

1

2

3

4

IoT server nodesq (max. number

of outdated records)

RTT with leisure time

(a) Round trip time (in seconds).

100120

140160

180200

24

68

10

0.98740.98760.98780.988

0.98820.9884

probability that a single

transmission is successful

IoT server nodes

q (max. number

of outdated records)

(b) Transmission success probability.

100120

140160

180200 2

46

810

290

300

310

daily energy

expenditure

IoT server nodesq (max. number

of outdated records)

(c) Mean daily energy expenditure (in Joules)by the IoT node.

Figure 7: Proxy performance with Erlang-3 distributed data lifetime for uniformly generated leisure timewithin the leisure period.

100120

140160

180200 2

46

810

11.5

22.5

33.5

IoT server nodes

q (max. number

of outdated records)

RTT with leisure time

(a) Round trip time (in seconds).

100120

140160

180200

24

68

10

0.98740.98760.98780.988

0.98820.9884

probability that a single

transmission is successful

IoT server nodes

q (max. number

of outdated records)

(b) Transmission success probability.

100120

140160

180200 2

46

810

290

300

310

320

daily energy

expenditure

IoT server nodesq (max. number

of outdated records)

(c) Mean daily energy expenditure (in Joules)by the IoT node.

Figure 8: Proxy performance with Erlang-4 distributed data lifetime for uniformly generated leisure timewithin the leisure period.

transmission serves increasing number of sensors.Probability of successful transmission slightly

decreases when the parameter of Erlangian distributionis increasing due to the increase in multicast requestrate. Due to low traffic in the IoT domain, the diagramspresented do not show significant dependence on thenumber of IoT devices which also means that thistechnique can be applied to domains with 300-400 IoTdevices without severe performance deterioration.

These results show that the probability distributionof data lifetime has a significant impact on the proxymanagement scheme. Data lifetime distributions withsmall values of standard deviation and skewness requiremore frequent cache updates for the same record groupsize. This increases energy consumption in IoT domain.If we combine these results with results from Fig. 5,we see that the record size for multicast refreshmentshould be determined from the limit on total estimated

11

Open Journal of Internet of Things (OJIOT), Volume X, Issue X, 20XX

stale time of data records for known data lifetimedistribution. Alternatively, instead of record size, thevalue of freshness threshold can be manipulated. If thereis additional restriction on energy consumption per IoTnode then limit on the number of IoT devices should beimposed.

8 CONCLUSION

In this paper we have developed the model ofmulticasting based proactive proxy which estimates datalifetime and uses that information to determine momentsto refresh the cache. Cache refreshment decision is basedon a number of stale data records. Results show that acomparatively small number of lifetime measurements,say, 500 or so, are sufficient for reliable estimation. Also,the bandwidth appropriate for the estimation of normaldistribution resulted in estimates that were close to theoptimal result from biased cross validation approach. Inour model we have considered IoT domain consistingof a single hop 6LoWPAN/IEEE 802.15.4 cluster. Ourfindings show that if the standard deviation and skewnessof the data lifetime distribution decrease for the samemean value of the variable and same record size, theperiod of multicast requests decreases. This leads toincreased traffic load and, perhaps more importantly, toincreased energy consumption in the IoT domain. Thissituation can be remedied by decreasing the number ofsensors in the domain or by increasing the data freshnessthreshold.

REFERENCES

[1] C. Bormann and Z. Shelby, “RFC 7959: Block-wise transfer in the constrained applicationprotocol,” https://tools.ietf.org/html/rfc7959, 2016.

[2] R. Fielding, “Architectural styles and the designof network-based software architectures,” Ph.D.dissertation, University of California, Irvine, CA,2000.

[3] K. Hartke, “RFC 7641: Observing resources in theconstrained application protocol,” https://tools.ietf.org/html/rfc7641, 2015.

[4] D. P. Heyman and M. J. Sobel, Stochastic Modelsin Operations Research, Volume I: StochasticProcesses and Operating Characteristics. NewYork: McGraw-Hill, 1982.

[5] L. J. Kleinrock, Queuing Systems. New York:John Wiley and Sons, 1972, vol. I: Theory.

[6] F. M. Kovatch, “Scalable Web Technology forthe Internet of Things,” Ph.D. dissertation, ETHZurich, Switzerland, 2015.

[7] J. Misic, M. Z. Ali, and V. B. Misic, “Protocolarchitectures for CoAP IoT domains,” IEEENetwork, vol. 32, no. 4, pp. 811–817, 2018.

[8] J. Misic and V. Misic, “Proxy cache maintenanceusing multicasting in CoAP IoT domains,” IEEEInternet of Things Journal, 2018.

[9] J. Misic and V. B. Misic, Wireless Personal AreaNetworks: Performance, Interconnections andSecurity with IEEE 802.15.4. Chichester, UK:John Wiley & Sons, Jan. 2008.

[10] J. Misic, V. B. Misic, and X. Chang, “Kernel basedestimation of domain parameters at IoT proxy,” inIEEE Globecom, Abu Dhabi, UAE, Dec. 2018.

[11] M. Nottingham and S. Hammer-Lahav, “RFC5785: Defining well-known uniform resourceidentifiers,” https://tools.ietf.org/html/rfc5785,2010.

[12] A. Rahman and E. Dijk, “RFC 7390: Groupcommunications for the constrained applicationprotocol,” https://tools.ietf.org/html/rfc7390, 2014.

[13] C. Shelby, Z. Bormann and S. Krco, “Coreresource directory,” https://tools.ietf.org/html/draft-ietf-core-resource-directory-09, 2016.

[14] Z. Shelby, “RFC 6690: Constrained RESTfulenvironments (core) link format,” https://tools.ietf.org/html/rfc6690, 2012.

[15] Z. Shelby, “RFC 7252: The constrained applicationprotocol,” https://tools.ietf.org/html/rfc7252, 2014.

[16] H. Takagi, Queueing Analysis. Amsterdam,The Netherlands: North-Holland, 1991, vol. 1:Vacation and Priority Systems.

[17] M. Wand and M. Jones, Kernel Smoothing.Chapman & Hall, Inc., 1995.

[18] M. Welsh, D. Culler, and E. Brewer, “SEDA: anarchitecture for well-conditioned, scalable internetservices,” ACM SIGOPS Operating SystemsReview, vol. 35, no. 5, pp. 230–243, 2001.

[19] D. Zordan, R. Parada, M. Rossi, and M. Zorzi,“Automatic rate-distortion classification for theIoT: Towards signal-adaptive network protocols,”in IEEE GlobeCom, Singapore, Dec. 2017.

12