Lightweight data streaming from IoT devices

Lightweight data streaming from IoT devices Jelena Miˇsi´c and Vojislav B. Miˇsi´c Ryerson University, Toronto, ON, Canada M5B 2K3

Abstract—In this work we have examined aspects of CoAP’s observe feature applied to single IoT domain ended by proxy. In order to maintain freshness of cache records in the presence of random interarrival periods of parameterized observed data we have implemented evaluation of Max Age parameter at the proxy. This estimation involved removing variability coming from random transmission times from IoT nodes to proxy. We have investigated impact of lenient versus more conservative estimations of data freshness on traffic performance in the cluster and energy consumption at IoT nodes. Results show that for exponentially distributed inter observation times with mean of 60s conservative estimations of Max Age run smoothly on clusters with 550 nodes and that cluster could accomodate up to 800 nodes in this regime.

I. I NTRODUCTION Constrained Application Protocol (CoAP) [1], [14] was introduced to facilitate reliable and efficient transfer of data from Internet of Things domains. CoAP is designed according to the Representational State Transfer (ReST) paradigm [2] and is upward compatible with the current Internet. HTTP over TCP is substituted by CoAP running over UDP [14]. UDP on the other hand can run over IPv4/IPv6. Medium Control Access layer (MAC) can cover IEEE 802.15.4 with adaptation for Low power Wireless Personal Area Networks (6LoWPAN) [9], IEEE 802.11ah or Bluetooth LE. IoT nodes are organized in clusters which correspond to IoT domains. Each domain is comprised of nodes that communicate with single MAC technology. In IPv6 terminology, IPv6 addresses within the domain are link local addresses with prefix FE80::/64 and last 64 bits are coming from extened unique identifier of the device’s network interface. Domains communicate with the rest of Internet through access points (APs aka IoT gateways or proxies). Each AP receives data from IoT nodes and stores the data in its cache. It also replies to HTTP/CoAP requests from the clients by supplying data from the cache as shown in Fig. 1. Therefore IoT gateway acts as a brigde by having universal IP address towards the Internet clients and link-local IP address towards the IoT domain. We believe that this design leads to efficient IoT framework since proxies have higer computational, memory and bandwidth resources than IoT nodes. This approach also has good security properties since proxy can control access to physical variables and prevent some attacks to nodes by concealing resources. IoT gateway controls access to a database/cache with collected data. In CoAP data freshenss is supported by the IoT node using Max Age and ETag options [14]. When Max Age value is exceeded proxy needs to validate the data by sending GET request to IoT node potentially using some of ETag(s). These variables are suitable for raw sensor data with periodic transmission or for parameterized sensor data with known

IPv4 cloud

IPv6 IoT cloud

GET -obs resource HTTP GET from URI client

Reverse Cross Proxy HTTP OK val-2 as Origin Server (IoT gateway)

2.05 -obs val-1 2.05 -obs val-2

CoAP node (server)

… 2.05 -obs val-n

Fig. 1. AP with co-located proxy in observing mode

range of inter-generation times. However in some cases times between data generation at IoT nodes are random and data lifetime can be only estimated using moments od probability distribution derived from historical data. Also, although raw sensor data is generated periodically transmission of every reading may not be necessary and will certainly consume bandwidth and contribute to congestion. As noted in [3] it is more efficient to design CoAP resources that change value on certain conditions. However, many complex queries render random inter observation times. If CoAP sensing variables change their state on some conditions then client (proxy) is updated only when these conditions are met as opposite to periodically updating the client (proxy) with raw sensing data. For example query: , changes state to ”cold”, ”warm” and ”hot” whenever the sensed temperature readings is between given thresholds. Estimating data lifetime for physical variable should be performed at proxy rather than at IoT device since estimating data lifetime at IoT node is computationally and memory wise expensive and sending lifetime information consumes some bandwidth in options field. In this work we deploy and model observe feature where single GET request from proxy initiates a stream of observation data from IoT node [3]. We consider the case when observations are parameterized and Max Age can not be sent by the IoT node. Then proxy needs to perform function of keeping cache contents upto date based on estimated data lifetime. This requires estimation of the time period after which data will not be considered as fresh. When freshness limit expires re-registration GET request will be sent. To validate our approach we model proxy running over IEEE 802.15.4 6LoWPAN and point to the critical parameters in observation based proxy design. To the best of our knowledge this is the first work on modeling observe CoAP feature together with proxy based estimation of Max Age. Initial work on IoT domain design was reported in [15]. Experimental evaluation of unicast and multicast communica-

2

tions in CoAP was presented in [5], [4]. Reverse and hybrid proxies using POST and GET methods have been considered in [11]. To the best of our knowledge this is the first model and design of observation based proxy with autonomous estimation of Max Age. The paper is organized as follows. Section II describes features of observe option in CoAP and section III covers opertion of IoT domain with observation operated IoT nodes. Model of observe based proxy is presented in Section IV and interactions with MAC layer are given in Section V. Perfomance evaluation is presented in Section VI and Section VII concludes the paper. II. C ONSTRAINED A PPLICATION P ROTOCOL C OAP Basic CoAP features support methods supported in HTTP namely GET, PUT, DELETE and POST. Messages carrying clients’ requests with methods and responses from IoT node are exchanged asynchronously over an UDP socket. Confirmable transmission is reliable and is achieved using acknowledgements, re-transmissions after timeout and message de-duplications using message ID. Non-confirmable messages will not receive acknowledgement and actually rely to the reliability of MAC layer below. Given that most MACs today provide several re-transmission attempts [10] this mode appears to be very economical especially for IoT domains with single hop between nodes and IoT proxy. Important addition to CoAP is ”observe” feature [3]. In this feature client called ”observer” registers its interest to follow physical variable at the IoT device known as ”subject”. If IoT device (subject) accepts registration it will notify the observer every time when physical variable changes its value. IoT device is responsible to maintain the list of all its regisitered observers. One observer (client) can register to multiple IoT devices (subjects) in order to follow multiple physical variables. Data is flowing from IoT node to the observer as a stream of ”notifications”. IoT device has to send notifications to all observers from the list. Registration request is implemented as GET request with addition of ”observe” option and unique token. Notification stream follows as the reply to registration GET with the ”observe” option and same token. Sequence numbers are provided in notifications so that re-order problem can be resolved. Notifications can be sent in confirmable or nonconfirmable CoAP messages. Confirmable notifications have to be acknowledged by the observer (client). Client can also de-register i.e. cancel its interest in physical variable using GET request with de-register bit set and the same token. III. O PERATION OF OBSERVATION BASED I OT DOMAIN WITH PARAMETERIZED RESOURCES

Components of IoT domain are IoT nodes, proxy and communication primitives. RFC 7252 [14] describes forward and reverse classes of proxy where cache is refreshed by users’ requests or proactively refreshed by actions of IoT nodes. However, many proxies are hybrid in the sense that cache is refreshed by combinations of transmissions from IoT nodes,

refreshement requests from proxy or/and refreshment requests from users. Communication primitives depend on proxy type and can be unicast (POST and GET), multicast (POST and multicast GET) or observation stream combined with GET. Forward proxies can be implemented only using unicast communication primitives like GET. Reverse and hybrid proxies allow combination of primitives which flow from IoT nodes (POST or observe) and cache validation primitives which can be implemented as validation unicast GET, re-registration unicast GET or multicast GET. Communication primitives in observation based proxy are registration GET requests and stream of observation data as shown in Fig. 2. Functional components of IoT domain are algorithms to maintain freshness of the cache placed on proxy and congestion control. They depend on communication primitives, i.e. whether the communication primitives are unicast, multicast or observation based. A. Freshness of data in the cache using parameterized data Freshness of data in the cache depends on the process of data generation at the IoT node. Depending on the query imposed on the IoT device time between data generation can be constant, variable but predictable or random. Use of parameterized resources instead of raw resources saves the bandwidth in IoT domain but it turns lifetime of the data into random variable. In ordinary CoAP caching of raw resources or resources where time between data generation has low variability is supported using Max Age and ETag options [14]. When IoT node sends data to proxy it can supply data lifetime information in the Max Age field. ETag value can also be sent which contains digest of data value. This information is stored in the cache and if it is exceeded, proxy sends validation GET request using stored Etag(s). However, when resources are parameterized [3] time between changes of the resource becomes random and it is difficult to specify Max Age at the IoT node. This requires estimation of Max Age at the proxy since it has more computational resources. For proxy which uses observations another problem raises with use of validation GET when estimated Max Age is exceeded and some Etag(s) exist. The reason is that validation GET request is redundant with next observe packet. Instead if proxy detects that record’s age is larger than the estimation, it will send re-registration GET request with observation bit set to 0. This will cause renewal of observation request and new stream of observations will flow. Period between sending re-registration GET request and first observation packet is used in estimation of round trip time between proxy and IoT node. This value will be used to estimate Max Age at proxy. IV. M ODEL OF OBSERVE BASED PROXY In this model data flows from IoT devices are coming as observe streams from each IoT device. For efficiency of modeling we assume that sensing events have exponentially distributed inter-arrival time at each sensor. Observations are transmitted

3

IPv6 IoT cloud

Proxy

IoT node (server) GET -obs=0 2.05 -obs NON value-1

RTTp Ta1

2.05 -obs NON value-2

Ta2

2.05 -obs NON value-3

Tg1

Tg2 Tg3

Ta3 2.05 -obs CON value-i

Tai

Tgi RTTs

ACK

Fig. 2. Timing of observe process between IoT node and proxy

using combination of unconfirmable and confirmable CoAP messages since some portion of confirmable messages are needed so that IoT device can estimate RT Ts . We assume that IoT device does not send any Max Age information so cache has to estimate it based on interarrival time of packets in observe stream. Proxy monitors time between observe updates and computes its estimation of maximum age parameter. Depending on the computing and memory resources of proxy it is possible to keep histograms of inter observation arrival time and derive its approximate probability distribution. Therefore proxy can determine and keep mean value and standard deviation of time between observation arrivals denoted as Toa and σ(Toa ). However time between received observations is different from interobservation time at IoT device since it includes variability of uplink transmission time from IoT devices. This variability has to be eliminated so that time between observations generated at IoT device can be accurately recovered. As shown in Fig. 2 proxy can get information only about round trip (RT Tp ) time instead of pure uplink transmission time. RT Tp sample is obtained when re-registration GET is sent and CoAP 2.05 (content) reply is received. This event occurs in order to re-confirm proxy’s interest in data when maximum age of data record is exceeded. RT Tp includes time of downlink transmission, IoT device response time which is equal to the time to read the value from memory and time of uplink transmission. Since reading the value from device’s memory is short RT Tp consists mainly of downlink and uplink transmission times. Accuracy of RT Tp estimation depends on the rate of reregistration GET requests. Therefore tighter estimations of round trip time lead to more frequent re-registration GET requests and more accurate estimation of round trip time. On the other hand this leads to increased traffic intensity between proxy and IoT cloud and higher round trip times. In the simplest case when proxy has constrained resources

only mean value and standard deviation can be estimated using exponential moving average [8]. For that we will denote its instanteanous value as RT Tp with mean value and standard deviation equal to RT Tp,av and σ(RT Tp ) as: RT Tp = ωRT Tp + (1 − ω)RT Tp σ(RT Tp ) = ξσ(RT Tp ) + (1 − ξ)|RT Tp − RT Tp |

(1)

Given relatively slow changes in cluster population, parameters ω and ξ should favor mean value of RT Tp with values larger or equal to 0.5 (similarly to recommendation for strong RTT in [13]. According to timing at Fig. 2 time between successive receipts of observed data is influenced by inter observation time at IoT node and difference of consecutive uplink transmission times. If we denote consecutive observation generation times at IoT node as Tg,i and Tg,i+1 and corresponding uplink times as tup,i and tup,i+1 , i = 1..∞, then time between observation arrivals at proxy is equal to: Toa,i = Tg,i+1 − Tg,i + tup,i − tup,i+1

(2)

In previous equation (2) real inter observation time at IoT node in i + 1-th measurement corresponds to To,i = Tg,i+1 − Tg,i . Since all nodes use the same MAC, ujplink transmission times tup,i are independent identically distributed random variables (i.i.d). Then, difference of uplink transmissions times ∆i = tup,i+1 + (−tup,i ) is random variable with zero mean value and variance equal to twice the variance of uplink transmission time since var(∆i ) = var (tup,i + (−tup,i+1 )) = var(tup,i ) + var(tup,i+1 )

(3)

Under stable traffic conditions, i.e. when i → ∞ measurement index can be omitted and inter observation time at IoT device can be presented as To and variance of random variable ∆ can be written as var(∆) = 2var(tup ). From eqn. (2) it follows that mean value of time between observation arrivals is equal to mean real inter observation time generated at IoT device. However its variance is larger due to presence of variability of uplink transmission time and is calculated as: var(Toa ) = var(To ) + var(∆)

(4)

The simplest way to approximate var(∆) is by using variance of round trip time measured at proxy’s side, i.e. var(∆) ≈ σ(RT Tp )2 . This simplification makes sense when MAC does not give any priority to proxy compared to IoT nodes. Then expression (4) renders expression for standard deviation of time between generation of observations as: q (5) σ(To ) = var(Toa ) − σ(RT Tp )2 A. Probability distribution of inter-observation time at the proxy Let f (x) represent probability density function (pdf) of inter observation time at the IoT device which corresponds to arrivals of sensing results to the device’s CoAP layer.

1 (2πσ(RT Tp

)2 )

exp(−

x2 ) 2σ(RT Tp )2 (6)

Then pdf of inter arrival times of observations at the proxy can be obtained using convolution as: g(x) = f (x) ∗ N (0, σ(RT Tp ))

(7)

Laplace Stieltjes Transform (LST)of inter observation times at proxy can be obtained as: Z ∞ ∗ G (s) = e−sx g(x)dx (8) x=0

ar

ar

search / retrieval

ar

ar

protocol layer

N (0, σ(RT Tp ) = p

proactive refresh

Pr

DATABASE

update

aw

c

c

c

network layer

Variability of uplink transmission times will be added as normal probability distribution:

business logic

4

c

n

n

n

n

B. Estimating Max Age parameter at proxy Proxy can have some leniency (slack) in estimation of required value of maximum age of the record. RFC7641 [3] recommends waiting time between 5 and 15s after expiration of Max Age but our opinion is that this value should depend on actual value of Max Age. Leniency allows proxy to control the rate of re-registration GET requests. It can be implemented as slack parameter t which controls how many standard deviations of inter observation time are taken in estimation of Max Age. Then estimation of maximum age includes tunable number of standard deviations of inter sensing events as: Max Age = To + tσ(To ) q Max Age = To + t var(Toa ) − σ(RT Tp )2

(9)

Expression (9) defines algorithmic way to estimate Max Age after which re-registration GET request will be sent. From modelling perspective probability that re-registration GET will be sent becomes: Z ∞ Pr = g(x)dx (10) Max Age Therefore given slack parameter t clients which submit queries to the proxy have the assurance that data they obtain will not be older than To = Max Age + RT Tp q = To + t var(Toa ) − σ(RT Tp )2 + RT Tp + tσ(RT Tp ) (11) RTT measurements may be needed at IoT node as well if some form of congestion control is needed. However, due to shortage of resources estimation algorithm needs to be simpler than the one executed at proxy.

MAC

MAC

usr

usr

MAC

n

n( o+

RGET

user

MAC

RGET)

IoT sensor domain

Fig. 3. Queuing stages of proxy with reactive management

n homogeneous IoT devices with observation data rate λo together with acknowldgement rate λRGET = Pr λo will contribute to the total uplink rate towards the proxy of: λu,tot = n(λo + λRGET )

(12)

However since CoAP acknowledgements are processed at protocol layer uplink rates through application, CoAP and network/transportprotocol layers become: λua = nλo = λuc λun = n(λRGET + λo )

(13)

Downlink traffic contains two components as well. First component corresponds to re-registration GET requests which are sent from application layer down towards each node with rate λRGET = Pr λo and second component contains CoAP acknowledgements to confirmable observed data packets which are sent from protocol layer towards network layer and network. Note that MAC layer acknowledgements are sent from the network adapter following MAC protocol before packet is moved to the network layer. In the presence of n IoT devices downlink rate from application layer towards CoAP layer and rate from CoAP and network/transport layer respectively become: λda = λdc = λdn = nλRGET

(14)

C. Rates through proxy’s IoT side In the uplink every observed data packet needs to be stored in cache. Re-registration GET requests contain the same token so the total sequence of observed packets contain subsequences connected with the same token. Therefore each IoT device has the uplink rate which is the sum of observation rate and acknowledgements to re-registration GET requests.

D. Proxy queing model We assume that IoT gateway has layered architecture similar to Californium [7]. Proxy has two domains one dedicated to communication with users and the other for communications with IoT domain. Domains are executed at separate cores at

5

the proxy. Each proxy domain has four protocol layers; MAC, network/transport, CoAP and application layer as shown in Fig. 3. Protocol layers are decoupled with separate queues which allows queuing analysis using Jackson’s network approach [6]. We assume that thread processing time at each layer is exponentially distributed. Before we deal with specific layer we state that for generic request arrival rate λg and service rate µg response times for M/M/1 and M/M/n servers have Laplace Stieltjes Transform (LST) of µg − λg s + µg − λg mµg − λg ∗ TM M m (s) = s + mµg − λg ∗ TM M 1 (s) =

(15) (16)

respectively. Since request arrival rates per layer are specified in subsection IV-C, response times of all layers can be found by substituting appropriate values of service rates in expr.(15) for M/M/1 queues and in expr.(16) for M/M/m queues at application layer. MAC layer transmits and receives packets from the medium. It is located at the network interface card (NIC) and has its own state machine with receiving and transmitting queues. Network/transport layer receives and transmits packets to MAC layer over UDP. We assume that there is one receiving and one transmitting thread per core (as is the case for Windows). Execution time of network/transport thread is exponentially distributed with parameter µn . CoAP layer deals with transmission reliability, segmentation and multiplexing/demultiplexing. We assume that this time is exponentially distributed with parameter µc . Application layer maintains cache freshness and handles user queries. Reading from the cache may involve multiple threads spawned by the handler while writing involves single thread due to cache consistency issues. We assume that reading and writing to the cache are associated with event queues and are both exponentially distributed. Therefore reading logic can be modeled as M/M/m server with parameter µar and arrival rate of user requests λusr while update logic is modeled as M/M/1 server with parameter µaw . V. M ODEL OF MAC INTERACTIONS We consider single hop over IEEE 802.15.4 cluster with acknowledged MAC transmissions. 6LoWPAN layer may be included but it is not necessary. Cluster operates in the ISM band at 2.4GHz with raw data rate 250kbps, and with SO = 3, BO = 0 so that period between the beacons is BI = 0.98s. Thus IoT nodes can sleep and wake up every 0.98s to hear the information from the beacon which contains list of nodes with pending downlink traffic. Parameters of MAC protocol including minimal backoff exponent, the maximum value of the backoff exponent and the maximum number of backoff attempts are set to macMinBE=3, aMaxBE=5 and macMaxCSMABackoffs = 4 respectively as specified in [10]. Thus we can assume that in network with reasonably low bit error rate of BER = 10−5 and nodes which send single CoAP message over 60s in average, four retransmission attempts should provide sufficient reliability making confirmable CoAP mode optional. Packet size is 127 bytes including 6LoWPAN, UDP and CoAP headers.

We used analytical model for uplink and downlink communications in IEEE 802.15.4 based cluster presented in [10]. Based on that model Probability Generating Functions (PGFs) for duration of uplink data and request transmissions as well as for downlink data transmission denoted as Tud (z), Tur (z) and Tdd (z) respectively will be used. They are functions of number of nodes in the cluster and packet arrival rate in uplink and downlink respectively. Knowledge of these PGFs allows us to derive PGF for round trip time at MAC layer for reregistration GET request and its reply: Tround (z) = Tud (z)Tur (z)Tdd (z)

(17)

However, since proxy has more protocol layers, the LST of proxy’s round trip time between sending re-registration GET and receiving the content from IoT device becomes: ∗ ∗ ∗ RT Tp∗ (s) = Tar (s)Tcd (s)Tnd (s)

(18)

∗ ∗ ∗ ·Tround (exp(−s))Tnu (s)Tcu (s)Taw (s) d RT Tp∗ (s). with mean RT Tp = − ds Since uplink packet rates are higher than downlink rates we need to calculate LST of duration of overall interaction of IoT node with proxy as:

A. Energy considerations For non-confirmable observations whole energy consumption comes from transmitting observations and acknowledgements to re-registrtaion GET requests as well as from receiving re-registration GET requests. LST which corresponds to combined duration of these activities is: λu,tot T ∗ (s) = Tud (exp(−s))+ λu,tot + λRGET λRGET Tur (exp(−s))Tdd (exp(−s)) (19) λu,tot + λRGET We considered energy consumption per backoff period for the cases when node is listening, transmitting or sleeping. For Tmote sky [12] energy consumptions per backoff period (10 bytes) in the ISM band are ωs = 18.2nJ, ωr = 17.9µJ and ωt = 15.8µJ, during sleep, receiving and transmitting (at 0dBm), respectively. Therefore appropriate PGF for node’s and proxy’s energy consumption can be obtained by classifying backoff periods to listen, transmit and sleep [10]. After that variable z which denotes backoff period is substituted with variables xωt , xωr and xωs in expression (19) to obtain energy consumption per observation. VI. P ERFORMANCE E VALUATION We have evaluated observe proxy using analytical model executed in Maple 13 in IEEE 802.15.4 cluster described in Section V. The number of sensors varies between 50 and 550. Time period between transmission of parameterized observations was exponentialy distributed with mean of 1/λo = 60s. Number of protocol layers at proxy was set to k = 3 and thread execution rate (service rate) was set to µn = µc = µaw = µar = µ = 1/0.005 Observations were sent in non-confirmable mode. The slack parameter in computing Max Age i.e. the number of standard deviations

6

of inter observation time at the proxy was taking values t = 0, 0.5, 1, and1.5. Fig. 4(a) shows that probability of record validation by the proxy mostly depends on the number of standard deviations used in computing the threshold for Max Age. The ratio between case where t = 0 and t = 1.5 is almost 6 and contributes considerably to traffic intensity in the IoT domain especially for larger cluster sizes. This is illustrated with Fig. 4(b) which shows single transmission success probability (against MAC collisions and noise). This figure shows that cluster with 50 nodes is almost not sensitive to slack parameter but this sensitivity becomes significant when cluster sizes exceeds 300 nodes. 550 nodes per cluster in observation and re-registration mode achieve worst transmission success probability when slack parameter has value t = 0 which is around γ = 0.89 which in 5 transmission attempts at MAC layer renders failure probability of (1 − γ)5 ≈ 10−5 . Round trip time from proxy to IoT node and its coefficient of variation are shown in Figs. 4(c) and 4(d) respectively. They also show that clusters with less than 300 nodes are not sensitive to intensity of re-registrtaion requests while for 550 nodes there is 10% increase of RTT for cases when t = 0 and t = 1.5. Coefficient of variation for RTT varies between 0.15 and 0.2 which means that slack parameter t = 1.5 captures almost all variability RTT and that most of values are concentrated around the mean. Finally, daily energy consumption of IoT node presented in Fig. 4(e) shows sensitivity to all ranges of cluster sizes and slack parameter. Values range between 30004450J which is lower than POST based proxy described in [11] but still requires some form of re-charging of IoT nodes.

Probability of record validation

0.35 0.3 0.25 0.2 0.15 0.1 0

500

400 300 sensors 200

R EFERENCES [1] C. Bormann, A. P. Castellani, and Z. Shelby. Coap: An application protocol for billions of tiny internet nodes. IEEE Internet Computing, 16(2):62, 2012. [2] R. Fielding. Architectural Styles and the Design of Network-based Software Architectures. PhD thesis, University of California, Irvine, CA, 2000. [3] K. Hartke. RFC 7641: Observing resources in the constrained application protocol. https://tools.ietf.org/html/rfc7641, 2015. [4] I. Ishaq, J. Hoebeke, I. Moerman, and P. Demeester. Experimental evaluation of unicast and multicast CoAP group communication. Sensors, 16(7):1137, 2016.

0.8 1.2

100

num. stdevs

(a) Probability of re-registration for data variable probability that single transmission is successful

0.98 0.96 gama 0.94 0.92 0.9 0 0.4 num. stdevs

0.8 1.2

500

100 200 300 sensors 400

(b) transmission success probability RTT

0.056 0.055 0.054 RTT 0.053 0.052 0.051 500

0

400 300 sensors 200

VII. C ONCLUSION In this work we have developed a model of observation based hybrid cross-proxy IoT over single hop 6LoWPAN/IEEE 802.15.4 cluster in order to assess reliability and scalability of non-confirmbale observations from IoT domains. Since data queries are parameterized, validation of data fresheness at the cache is performed by estimation of Max Age parameter at the proxy. We investigated impact of the conservative versus more lenient estimations of Max Age on the cluster performance. Results show that, for mean inter obesrvation time of 60s, clusters with less than 300 nodes perform well with conservative estimation of Max Age. However, with more than 300 nodes difference between conservative and nore lenient estimations become pronounced especially with respect to energy consumption at the IoT nodes. In our future wokr we plan to develop congestion control algorithm at IoT node and integrate it with estimation of data freshness.

0.4

0.4 0.8 100

1.2

numb. stdevs

(c) Round trip time for IoT node in ms coeff. var. for RTT

0.19 0.18 0.17 0.16 0

500

400 300 sensors 200

0.4 0.8 100

1.2

num. stdevs

(d) coefficient of variation for RTT for IoT node daily energy expenditure

4400 4000 dEn3600 3200 0

500

400 300 sensors 200

0.4 0.8 100

1.2

num.stdevs

(e) Daily energy expenditure in J by the IoT node Fig. 4. IoT proxy performance descriptors for observe mode mode

7

[5] I. Ishaq, J. Hoebeke, F. Van den Abeele, J. Rossey, I. Moerman, and P. Demeester. Flexible unicast-based group communication for coapenabled devices. Sensors, 14(6):9833–9877, 2014. [6] L. J. Kleinrock. Queuing Systems, volume I: Theory. John Wiley and Sons, New York, 1972. [7] F. M. Kovatch. Scalable Web Technology for the Internet of Things. PhD thesis, ETH Z¨urich, Switzerland, 2015. [8] J. F. Kurose and K. W. Ross. Computer Networking: A Top-Down Approach Featuring The Internet. Addison-Wesley Longman, Boston, MA, 2016. [9] N. Kushalnagar, G. Montenegro, C. Schumacher, et al. Ipv6 over low-power wireless personal area networks (6lowpans): overview, assumptions, problem statement, and goals. Technical report, RFC 4919 (Informational), Internet Engineering Task Force, 2007. [10] J. Miˇsi´c and V. B. Miˇsi´c. Wireless Personal Area Networks: Performance, Interconnections and Security with IEEE 802.15.4. John Wiley & Sons, Chichester, UK, Jan. 2008. [11] J. Miˇsi´c, V. B. Miˇsi´c, and F. Banaie. Reliable and scalable data acquisition from IoT domains. In Proceedings of IEEE GlobeCom, Singapore, 2017. [12] tMote sky lowpower wireless sensor module. tMote datasheet 802.15.4, Moteiv Corporation, San Francisco,CA, www.moteiv.com. [13] V. Paxson, M. Allman, J. Chu, and M. Sargent. RFC 6298: Computing tcps retransmission timer. https://tools.ietf.org/pdf/rfc6298.pdf, 2011. [14] Z. Shelby. RFC 7252: The constrained application protocol. https: //tools.ietf.org/html/rfc7252, 2014. [15] A. Zanella, N. Bui, A. Castellani, L. Vangelista, and M. Zorzi. Internet of things for smart cities. Internet of Things Journal, IEEE, 1(1):22–32, 2014.