Evaluation of congestion control policies for the CoAP protocol through the WiSHFUL platform

(1)

Dipartimento di Ingegneria dell'Informazione MSc in Computer Engineering

Evaluation of congestion control policies

for the CoAP protocol through the

WiSHFUL platform

CANDIDATE

Martina Troscia

SUPERVISORS

Enzo Mingozzi

Carlo Vallati

Anno Accademico 2017/2018

(2)

Abstract

The Internet of Things paradigm has brought many new challenges for the design of protocols and standards to be used by the constrained devices. For this aim, the Constrained Application Protocol (CoAP) has been re-cently standardized by the Internet Engineering Task Force to full all the requirements of the applications running on the IoT. Relying on the UDP transport layer, CoAP has to handle the problem of congestion control ex-plicitly and performs it in a very basic way. Several weaknesses have been identied in this basic congestion control algorithm, thus recently a more advanced version of the protocol, named CoCoA+, has been proposed. The aim of this work is to carry out an extensive performance evaluation of some congestion control policies alternative to CoCoA+ that have been designed to try and overcome some of the drawbacks that are still present in the algorithm. The work takes the distances from many other studies present in the literature as a testbed composed of real devices, provided by the European WiSHFUL project, has been exploited for the analysis of the performance of the algorithms. The software framework running on the devices has been extended to allow the design of the algorithms and the execution of the experiments.

(3)

Chapter 1 Introduction

Nowadays, the Internet of Things (IoT) paradigm is assuming an always greater importance. The term IoT is adopted to convey the idea of an Internet dramatically enlarged to contain any kind of physical object em-bedded with electronics, and able to communicate with any other device without human direct interaction. It is estimated that there will be 26 billion devices by the end of 2020 satisfying a wide range of applications [1] in various application areas, e.g medicine, industrial, civil, military, etc. All these domains are considered as being a unique entity and exchange information to take smart decisions. For this reason, IoT is expected to generate large amounts of data from various locations; this data needs to be aggregated and processed very quickly, so a good throughput, relia-bility and predictarelia-bility are valuable aspects that have to be taken into account.

The World Wide Web is the platform that is generally used to exchange and manage data. Every accessible resource is identied through the Uni-form Resource Identier (URI) and can be accessed through the HTTP application protocol. Although the URI addressing method is exible enough to be used also for the identication of the IoT devices, traditional Internet protocols may not be directly applicable to the constrained en-vironment that the Internet-of-Things devices are expected to deal with. This devices usually have great limitations in terms of memory and com-putational power, and must perform all the operations very eciently to save as much energy as possible.

(7)

Many eorts have been made to dene new IoT standards that could ensure interoperability. Among them, the activities of the Internet En-gineering Task Force (IETF) have been considered the leading ones in encouraging the integration of smart objects into the existing IPv6 net-working infrastructure [2]. A complete stack of communication protocols has been designed, explicitly tailored for constrained devices that operate in the Low Power and Lossy Networks, and that are characterised by a low radio bandwidth and a high bit error rate. On top of this communica-tion stack, IETF has standardized the Constrained Applicacommunica-tion Protocol (CoAP) [3], an application protocol that aims at enabling the communi-cation with the IoT devices while maintaining a common interface with HTTP for the interaction with the applications.

Considering the width of this network of devices and the limited band-width that is available, the phenomenon of congestion is a relevant issue. Network congestion can be observed whenever the trac generated by the applications gets close to the network capacity, or when the queueing and storing capabilities of nodes are exceeded. Trac loads that can cause such congestion are expected in CoAP communications, where a large number of messages is exchanged among the nodes in small intervals of time. In this context, a congestion control mechanism is extremely important to prevent or recover from conditions of congestion.

In traditional networks, the HTTP protocol works above the Transmis-sion Control Protocol (TCP), which already embeds a congestion control mechanism. To reduce the complexity and the overhead introduced by the TCP communications, CoAP employs the User Datagram Protocol (UDP), which does not ensure a reliable delivery of data nor a conges-tion control mechanism. For this reason, CoAP specicaconges-tions also dene an optional type of messages, the CON messages, which support reliable delivery through retransmissions, allowing the denition of a basic conges-tion control policy. Several weaknesses have been identied in this basic

(8)

algorithm, so new more advanced policies have been proposed, such as the CoCoA algorithm [4] that is currently under standardization by the Inter-net Engineering Task Force (IETF). More recently, an improved version of this congestion control mechanism has been introduced, CoCoA+ [5], with the objective of addressing the shortcomings observed in the classical CoCoA policy.

Most of the recent researches takes CoCoA+ as starting point. Although the algorithm has been conceived to outperform the standard CoCoA, it still presents some drawbacks, as identied in many works present in literature [6] [7]. The greater power saving exhibited by CoCoA+ with respect of the CoCoA algorithm comes at the price of a lower throughput and a worse usage of the network resources. This is why there is the interest in designing novel algorithms alternative to CoCoA+.

The design of these policies requires the presence of tools that can facil-itate the test of the obtained solutions. In most cases, the performance of the algorithms is veried through simulation. Although each simulator usually includes additional components to mimic the real world phenom-ena, such as irregular radio propagation and interference, it can happen that the algorithms do not work correctly when run on real devices. This is why there is the need of suitable hardware platforms for rapid test and experimentation. They need to be exible and reusable, as it is not cost eective to build a new platform for each new scenario to be investigated. The WiSHFUL project provides such hardware and software frameworks to facilitate the implementation of the algorithms.

1.1 Research aims and objectives

The aim of this work of thesis is to carry out an extensive performance evaluation of some novel congestion control algorithms that have been designed as an alternative to CoCoA+, taking into account a wide set of

(9)

performance metrics. The eectiveness of these algorithms in reducing the congestion of the network is veried through experiments carried out on testbeds composed of real constrained devices.

The main objectives of the thesis are:

to build a centralized congestion control algorithm, exploiting the presence of a component into the WiSHFUL platform that knows everything about the network, and compare the performance of the algorithm with the one of CoCoA+;

to analyse some improved versions of the CoCoA+ congestion con-trol algorithm and verify if they are successful in solving some of the shortcomings identied in CoCoA+;

to test all the proposed solutions on testbeds composed of real de-vices and verify if the results are in line with those obtained through simulation, and eventually identify possible issues due to the usage of real testbeds;

to verify if the centralized congestion control algorithm is more ef-fective in mitigating congestion than the distributed policies.

1.2 Thesis outline

The rest of the thesis is structured as follows:

Chapter 2 summarizes the main characteristics of the CoAP protocol and describes the adopted default congestion control policy. More-over, it shows some of the issues that have brought to the design of a more advanced algorithm, CoCoA+, that is briey presented. Chapter 3 presents the main reasons that lead to the design of the

(10)

introduces the major modications that needed to be performed on the framework in order to run the experiments carried out in this thesis.

Chapter 4 describes the centralized version of the CoAP-R conges-tion control algorithm, a rate-based algorithm whose objective is to pursue a fair allocation of the available resources to the nodes of the network.

Chapter 5 presents the performance evaluation of CoAP-R against Default CoAP and CoCoA+. After presenting the experimental scenarios and the characteristics of the trac that is injected into the network, a certain number of dierent metrics is analysed to explain the dierent behaviour of the real devices with respect to simulated ones.

Chapter 6 summarizes the motivations that lead to the design of en-hancements for the CoCoA+ congestion control algorithm, CoCoA-E and CoCoA 4-state-Strong, and presents the implementation of these algorithms.

Chapter 7 presents the performance evaluation of CoCoA-E and CoCoA 4-state-Strong against CoCoA+. The behaviour of the al-gorithms under dierent trac loads is analysed according to the metrics adopted for CoAP-R to test the eectiveness of the novel policies in reducing the congestion with respect to CoCoA+.

Chapter 8 contains a nal performance evaluation where the be-haviour of CoCoA-E and CoCoA 4-state-Strong is compared against the CoAP-R congestion control algorithm. The data conrms the greater eectiveness of the global congestion control in limiting the situations of congestion.

(11)

Chapter 2 Background and related work

2.1 The Contrained Application

Protocol (CoAP)

The Constrained Application Protocol (CoAP) [3] is a web transfer pro-tocol specically conceived to be used with constrained nodes and con-strained networks. The protocol has been designed by the IETF CoRE (Constrained RESTful Environments) group for machine-to-machine (M2M) applications. In fact, HTTP, that is commonly employed in the Internet today, is a powerful protocol, but it is relatively expensive both in imple-mentation code space and network resource usage. For this characteristics, the IoT devices have diculties in using it and a new protocol was needed. However, the goal of CoAP is not to blindly compress HTTP, but rather to realize a subset of REST APIs in common with HTTP but optimized for M2M applications. Although CoAP could be used for refashioning simple HTTP interfaces into a more compact protocol, more importantly it also oers additional features such as built-in discovery, multicast support, low header overhead and parsing complexity, simple proxy and caching capa-bilities, and asynchronous message exchange.

2.1.1 The CoAP interaction model

The interaction model in CoAP is similar to the client/server model of HTTP. However, machine-to machine interactions typically result in a CoAP implementation acting in both client and server roles, depending

(12)

Figure 2.1: Abstract layering in CoAP

on the application requirements. CoAP message interchanges are asyn-chronous and run over a datagram-oriented transport layer such as UDP. To make up for the lack of guarantees, such as the support for reliabil-ity, congestion control and ow control, an additional message layer has been introduced, in addition to the request/response layer (gure 2.1). However, CoAP is a single protocol, with messaging and request/response being just features of the CoAP header.

The CoAP protocol denes four types of messages:

Conrmable (CON ): messages requiring an acknowledgement. When no packets are lost, each Conrmable message elicits exactly one re-turn message of type Acknowledgement or type Reset.

Non-conrmable (NON ): messages not requiring the acknowledge-ment. This kind of messages is usually exploited for messages that are repeated regularly, such as repeated readings from a sensor, and whose sporadic loss is not critical for the application requirements. Acknowledgement (CON ): messages acknowledging that a specic

Conrmable message has arrived. By itself, an Acknowledgement message does not indicate the success or the failure of any request incapsulated in the Conrmable message. The Acknowledgement message may also carry a piggybacked response.

(13)

Figure 2.2: Format of the CoAP messages

Reset (CON ): message indicating that a specic Conrmable or Non-conrmable message has been received, but some context is missing to properly process it. This condition is usually caused when the receiving node has rebooted and has forgotten some state that would be required to interpret the message.

Method Codes and Response Codes included in some of these messages make them carry requests or responses. The basic exchanges of the four type of messages are orthogonal to the request/response interactions: re-quests can be carried in CON and NON messages, and responses can be carried in these two kind of messages as well as piggybacked in ACK messages.

The format of the CoAP messages

CoAP uses a short xed-length binary header (4 bytes) that may be fol-lowed by a variable-length Token value (0-8 bytes). Following the Token value comes a sequence of zero or more CoAP options in Type-Length-Value (TLV) format, optionally followed by a payload that takes up the rest of the datagram. The eld in the header (gure 2.2) are dened as follows:

(14)

Version (Ver): 2-bit unsigned integer, indicating the CoAP version number. Messages with unknown version are silently ignored. Type (T): 2-bit unsigned integer, indicating if the message is

Con-rmable (0), Non-conCon-rmable (1), Acknowledgement (2), or Reset (3).

Token Length (TKL): 4-bit unsigned integer, indicating the length of the variable-length Token Field.

Code: 8-bit unsigned integer, split into a 3-bit class (most signicant bits) and a 5-bit detail (least signicant bits). The class can indicate a request (0), a success response (2), a client error response (4), or a server error response (5). In case of a request, the Code eld indicated a Request Method; in case of a response, a Response Code. Message ID: 16-bit unsigned integer in network byte order, used to detect message duplication and to match messages of type Acknowl-edgement/Reset to messages of type Conrmable/Non-conrmable. The header is followed by the Token value, whose length may be 0 to 8 bytes, as given in the Token Length eld. The Token value is used to correlate requests and responses.

The CoAP messaging model

The CoAP messaging model is based on the exchange of messages over the UDP layer between endpoints. The reliability is provided by marking a message as Conrmable (CON). A conrmable message is retransmitted using a default time-out and exponential back-o between retransmissions (section 2.2 on page 12 provides further details), until the recipient sends and Acknowledgement message (ACK) with the same Message ID from the corresponding endpoint (gure 2.3a on the next page). When a recipient is not able to process the Conrmable message (it is not even able to

(15)

(a) Reliable message transmission (b) Unreliable message transmission

Figure 2.3: CoAP messaging model

provide a suitable error response), it replies with a Reset message (RST), instead.

A message that does not require reliable transmission can be sent as a Non-conrmable message (NON). These kind of messages are not acknowl-edged, but still have a Message ID for duplicate detection (gure 2.3b). When a recipient is not able to process a Non-conrmable message, it may reply with a Reset message (RST).

The request/response model

CoAP request and response semantics are carried in CoAP messages, which include either a Method Code or a Response Code, respectively. Optional (or default) request and response information, such as the URI and payload media type, is carried as CoAP options. A Token is used to match responses to requests independently from the underlying messages. A request is carried in a Conrmable (CON) or Non-conrmable (NON) message. If immediately available, the response to a request carried in a CON message can be carried in the resulting Acknowledgement (ACK) message. This is called piggybacked response, and the message exchange is illustrated in gure 2.4a on the following page. There is no need to sep-arately acknowledge a piggybacked response, as the client will retransmit the request if the ACK message carrying the response gets lost.

(16)

(a) Request with piggybacked response (b) Request with separate response

Figure 2.4: Request and response carried in a Conrmable message

If the server is not able to respond immediately to a request carried in a CON message, it simply responds with an empty ACK so that the client can stop retransmitting the request. When the response is ready, the server sends it in a new Conrmable message, which in turn needs to be acknowledged by the client. This is called a separate response, and the message exchange is illustrated in gure 2.4b.

If a request is sent in a Non-conrmable message, the response may be sent using a new Non-conrmable message or a new Conrmable message. This type of exchange is illustrated in gure 2.5 on the following page. CoAP makes use of GET, PUT, POST, and DELETE methods in a man-ner similar to HTTP:

GET : the method retrieves a representation for the information that currently corresponds to the resource identied by the request URI. The GET method is safe and idempotent.

(17)

Figure 2.5: Request and response carried in a Non-conrmable message

POST : the method expects that the receiver processes the represen-tation enclosed in the request. The actual function performed by the POST method is determined by the origin server and depends on the target resource, but it usually results in a new resource being created or in the target resource being updated. POST is neither safe nor idempotent.

PUT : the method requests that the resource identied by the request URI is updated or created with the enclosed representation. PUT is not safe but is idempotent.

DELETE: the method requests that the resource identied by the request URI is deleted. DELETE is not safe but is idempotent.

2.2 The basic congestion control

algorithm in CoAP

The default congestion control included in the CoAP specication [3] lim-its the trac in the network by imposing a restriction on the number of allowed parallel message exchanges, and on the rate of outgoing messages. Firstly, the algorithm xes the maximum number of outstanding CoAP

(18)

transactions toward a particular destination endpoint, named NST ART,

to limit the number of concurrent messages that can be sent by a node without receiving an acknowledgement. NST ART default value is set to 1,

that is enough for most of the applications running CoAP. CoAP allows a total of four retransmissions of a specic message, before considering the exchange to have failed.

Secondly, the standard limits the rate of outgoing messages by using an exponential back-o between the retransmissions of the lost messages. Specically, for each new CON message, CoAP randomly chooses an initial Retransmission Time-Out (RTO) value from the interval [2000, 3000] ms for the initial message transmission (randomness is introduced to avoid synchronization eects among nodes). If the timer set to this RTO value expires and the source of the CoAP message has not received an ACK from the destination endpoint, a loss is assumed and the CoAP message needs to be retransmitted. For this purpose, a Binary Exponential Back-o (BEB) is applied, doubling the RTO interval every time a retransmission occurs.

2.3 CoCoA+: an advanced congestion

control algorithm for CoAP

The CoCoA algorithm has been designed to overcome some of the issues that arise while using the Default CoAP congestion control policy. In this master thesis, only the last version of the algorithm named CoCoA+ [5] has been taken into account as term of comparison during the performance evaluation of the novel algorithms.

In CoCoA+, the basic mechanisms that make up the congestion control for CoAP have been improved. In particular,

(19)

1. the policy to calculate the Retransmission Time-Out (RTO) has changed. Two dierent estimators, a weak and a strong estimator, are used in parallel to update the RTO values more accurately. 2. the back-o policy to set the Retransmission Time-Out for

retrans-missions has been modied. The RTO value is not simply doubled at each retransmission.

3. an ageing policy for the status information has been introduced. The Retransmission Time-Out in CoCoA+ is computed adopting the same algorithm used by TCP: the RTO value is updated based on the measured Round Trip Times (RTTs). If only measurements of transmissions that have been correctly delivered without retransmissions were considered, the probability of obtaining valid RTT measurements would be reduced. For this reason, CoCoA+ also considers the transactions that experienced retransmissions to obtain a more accurate RTT estimation. Specically, two RTO values are calculated: a strong RTO, estimated using RTT sam-ples from transactions that have not required any retransmission, and a weak RTO, estimated using RTT values of transactions that required at least one retransmissions. Considering that it is not possible to know for an ACK to which transmission it belongs to, RTT samples are collected measuring the time between the rst transmission and the arrival of a response.

Summarizing, a node maintains the following quantities for each destina-tion:

two smoothed mean RTT estimators, called RT Tstrong and RT Tweak;

two smoothed mean variance estimators, called RT T V ARstrong and

RT T V ARweak;

two RTO estimators, called RT Ostrong and RT Oweak, derived from

(20)

a comprehensive RTO, called RT Ooverall, which keeps track of changes

to both RT Ostrong and RT Oweak estimators.

At the beginning, the RTO estimators are initialized with a default value of 2000ms. The values of the other RT Tx and RT T V ARx parameters

are initialized when the rst corresponding RTT value R is measured, as follows:

RT Tx = R, RT T V ARx = R/2 (2.1)

Every time a new RTT sample R is measured, the corresponding strong or weak estimators are updated, based on the number of retransmissions, as follows:

RT Tx = (1 − α) · RT Tx+ α · R (2.2)

RT T V ARx = (1 − β) · RT T V ARx+ β · |RT Tx− R| (2.3)

RT Ox = RT Tx+ Kx· RT T V ARx (2.4)

RT Ooverall = λx· RT Ox+ (1 − λx) · RT Ooverall (2.5)

where the following values are recommended: α = 0.25, β = 0.125, Kstrong = 4, Kweak = 1, λstrong=0.5, and λweak = 0.25.

RT Ooverall is used to set the initial RTO (RT Oinit) for the next CON

transmission. The actual value of RT Oinitis selected using a dithering

ap-proach, i.e. RT Oinit is randomly chosen from the interval [RT Ooverall, 1.5 ·

RT Ooverall].

CoCoA+ introduces a back-o mechanism that is dierent from the one adopted by Default CoAP. The new RTO value to use for the following retransmission is not obtained by simply doubling the previous value, but it is computed according to a Variable Back-o Factor (VBF) that de-pends on the initial RTO value RT Oinit. This is done to avoid frequent

retransmissions in a short time, when the value of the Retransmission Time-Out is low, and to avoid long delays in retransmissions, when the RTO value is very large instead. Specically, the new value of the RTO

(21)

for the retransmissions, RT Onew, is evaluated as follows:

RT Onew = RT Oprevious· V BF (RT Oinit) (2.6)

where V BF (RT Oinit) is dened as:

V BF (RT Oinit) =            3, RT Oinit < 1s 2, 1s ≤ RT Oinit ≤ 3s 1.3, RT Oinit > 3s (2.7)

Finally, CoCoA+ introduces a mechanism to age RTO values, when RTT updates are not received for a certain time. The rationale behind this is that the RTO estimation becomes obsolete after a certain time and should converge towards the initial value. Specically, if RT Ooverall is larger than

the base RTO dened in CoAP, which is set by default to 2s, and it is not updated for more than 30s, when a new measurement is obtained, the following formula is applied:

RT Ooverall =

2 + RT Ooverall

2 (2.8)

If RT Ooverall is less than 1s instead, and it is not updated for a time that

(22)

Chapter 3 Wireless Software and Hardware

platforms for Flexible and

Uni-ed radio and network controL

(WiSHFUL)

3.1 Introduction

Considering the emerging wireless ecosystem, an always increasing number of new technologies, operators, and service providers attempt to coexist in the same environment. The high heterogeneity of the device capabilities combined with the limited vendor-independent conguration interfaces makes it very dicult to provide a coherent service. This is why wire-less testbeds are fundamental for testing innovative technologies such as protocols, hardware, and several other modules of any wireless solution. For sake of maintainability and experiment repeatability, the testbed in-frastructure is often xed, even if the operating environment is highly dynamic. As the testbed environment is thus more rigid and the condi-tions are more stable, the evaluation of experimental wireless solucondi-tions results to be less realistic. It is clearly necessary a portable testbed that can be easily deployed on remote, real-world locations and a wireless mesh backbone that ensures connectivity between the nodes.

In addition, performance optimization cannot only rely on advanced hard-ware platforms and radio capabilities, but has to depend on the availability of software platforms able to control and coordinate the radio

(23)

cation and the network protocols. As it is not practical and cost eective to construct custom platforms for each future network scenario to be in-vestigated, they should be suciently general and exible. However, the problem with most of the existing platforms is that they typically lack of high-level specications and programming tools as well as standard APIs for code development, resulting not suciently open to allow the gradual integration of technologies.

To overcome these shortcomings, a novel approach is proposed within the European project WiSHFUL [8]. It is a project coordinated in Bel-gium and started in 2015, that has been nanced to bring contribution to the FIRE+ (Future Internet Research and Experimentation) plan. The WiSHFUL's aim is to construct a new architecture to address the require-ments of the real scenarios and to make it extensible in an easy way. Specically, WiSHFUL introduces mechanisms to provide developers a complete control of the physical and medium access components without requiring a deep knowledge of the hardware platform, and to allow the rapid creation and modication of new protocols across the entire stack. These abstractions facilitate the experiments, enabling intelligent node-level or network-wide decisions on the radio and network operation modes and settings. The test facilities follow the current standards in FIRE for testbed interoperability, so that standard tools are employed for the discovery of nodes, the control of experiments and the collection of mea-surements. In this way, experimenters are attracted with the possibility of validating the innovative wireless solutions they produced by using the provided hardware and software platforms and interfaces.

3.2 The WiSHFUL architecture

The WiSHFUL architecture has been designed to dene adaptations of the radio operations and to introduce automated run-time intelligence by

(24)

means of a exible and unied radio and network control. With exi-ble control they mean the possibility to maximize the conguration space of devices, exploiting all the radio functionalities and programmable pro-tocol logics supported by the platform hardware. With unied control they mean the possibility to expose platform-independent programming interfaces over very heterogeneous radio platforms, including standardized technologies and Software Dened Radio (SDR) platforms.

Figure 3.1 on the next page summarizes the general project vision. Ex-isting devices feature radio driver software, including the physical and some low-level MAC functionalities, and a network stack, including some higher-level MAC and upper layer functionalities depending on the imple-mentation. This software is further extended with control functionalities, and the extension also exposes the corresponding conguration interfaces, that can be used for the interaction with both local and global entities, i.e. intelligent control engines or application layer services.

3.2.1 Unied Programming Interfaces (UPIs)

The Unied Programming Interfaces (UPIs) proposed in WiSHFUL enable easy and exible radio and network control. Using the UPIs, intelligent engines can optimize towards specic network requirements and ne-tune the behaviour of any networking layer. They distinguish two types of UPIs, one for radio control and one for network control, as depicted in gure 3.2 on the following page [9].

The radio interface (UP IR) consists of a set of functions that ensures

uni-form control of the radio hardware and lower MAC behaviour across het-erogeneous devices. For instance, the intelligent engine is able to retrieve information such as binary spectrum occupancy value, raw I/Q samples, RSSI, duty cycle information and error statistics. The engine can also control the behaviour of the radio, such as setting modulation and coding

(25)

Figure 3.1: The WiSHFUL concept

(26)

type, power levels, beam forming parameters and transmission timings. These functions take a generic form so that consistent operations are pro-vided over a great variety of hardware-specic implementations. Apart from the utilization of a simple parametric control model, there is also the possibility to dene more advanced congurations based on novel abstrac-tions of the radio.

The network interface (UP IN) parallels the radio interface with a set of

functions that provides uniform control over the behaviour of the upper MAC layer and higher layer protocols across various devices. Examples of network information are the topology, the congestion level of links or paths, the selected routing algorithm, the available trac classes and ow-level statistics. Network congurations enabled by UP IN involve the

set-up of logical associations or links among the nodes, the mapping of trac ows into queues with dierent priorities and specic radio congurations, ow control among multiple real or virtual radio interfaces, network coding of dierent trac ows. They also envision the possibility to introduce behavioural abstractions to specify the network conguration in a compact domain-specic language for the network control.

The global interface (UP IG) extends the control provided by both the

ra-dio and the network interfaces across several devices in a coordinated and generic manner. The functions are supported by Monitoring and Cong-uration Engines (MCEs) that contain and manage the platform specic implementation of UPIs within WiSHFUL empowered facilities. These local or global intelligent engines can gather node-local or network-wide information and dynamically select the most optimal radio and network congurations.

Finally, the hierarchical control interface (UP IHC) enables hierarchical

control between control programs structured in a standard manner. This interface does not directly interact with hardware, but rather provides experimenters with tools for inter-control communication.

(27)

Figure 3.3: WiSHFUL architecture, UPIs and supported platforms

The interfaces of the WiSHFUL architecture are designed to support the user in controlling wireless hardware and the protocol stacks. WiSHFUL views user control as being embodied in control programs, which are ei-ther global or local. In general, Control Programs (CPs) are user dened software that implements the controlling logic for a wireless experiment and makes use of the radio and/or network interfaces for hardware and protocol control. Local Control Programs (LCPs) are those that use the local information and the abilities of a single device, while Global Control Programs (GCPs) interact with a group of devices. The WiSHFUL archi-tecture supports a two-tier control hierarchy. These two tiers work in a coordinated manner, being orchestrated at global level.

3.2.2 Hardware interfacing

The WiSHFUL radio control can work on three dierent platforms, namely the Iris SDR framework, TAISC and WMP, as shown in gure 3.3. Each of

(28)

the WiSHFUL-enabled nodes runs a local Monitoring and Conguration Engine that oers the same local services and the same UPI functions on dierent platforms by means of a specic Connector Module. This unied approach unloads the experimenter from the burden of dealing with a multiplicity of conguration and utility tools (indicated in gure 3.3 as Local Control Services), that are heterogeneous upon platforms and operating systems and depend on the hardware and software conguration of the device under test.

The Connector Modules operate in conjunction with local Monitoring and Conguration Engines to expose the uniform UPI functions on dierent hardware and software radio platforms. The local MCE delegates each UPI call to the appropriate Connector Module that executes the call using platform-specic sub-modules.

3.2.3 Basic services oered by WiSHFUL

Alongside the UPIs themselves, the WiSHFUL framework oers a number of basic services that are summarized below:

Node discovery: a Global Control Program often requires an auto-matic way to discover the nodes that are present in the network. WiSHFUL provides the protocol developer an easy way to dene the set of nodes he wants to control. Any wireless node belonging to the same experiment group can be controlled by the Global Control Program using the WiSHFUL UPIs.

Execution semantics: the WiSHFUL local and global MCEs support two execution semantics. The rst is a synchronous blocking UPI call where the caller, i.e. the Control Program, is blocked until the callee, i.e. any UPI function, returns. The second option is an asynchronous non-blocking UPI function call. As the UPI call

(29)

returns immediately in this case, the caller has the possibility to register a callback function so that he can receive the return value of the call at a later point in time. MCEs also oer the possibility for time-scheduled execution of UPI functions at a particular point in time.

Remote execution of UPI functions: WiSHFUL provides a full loca-tion transparency, any UPI funcloca-tion can be executed either locally by a Local Control Program or remotely by a Global Control Pro-gram. To enable the remote usage of the UPI functions through the U P IGinterface, a system is required that supports remote procedure

calls. For this purpose, the UPI functions must have a generic sig-nature that facilitates the serialization of function arguments during the UPI calls. Such types of function denitions are very exible but error-prone in usage. For this reason, more user-friendly versions are also required that shield the end-users from the complexity by of-fering strongly typed interface descriptions. This second version is oered in Python by helper classes and in C by helper functions. Deployment of new UPI functions: WiSHFUL provides an open and

extensible architecture, which can be easily extended by new UPI functions. Any new UPI function can be implemented in a dierent way for dierent platform and software architectures.

3.3 The w-iLab.t testbed

As mentioned before, one of the objective of the WiSHFUL project is to attract experimenters with the possibility of validating their wireless solutions on hardware platforms and interfaces. The w-iLab.t testbed is an experimental, generic, heterogeneous wireless testbed deployed in the iMinds building and at a second, remote location, providing a permanent testbed for the development and testing of the wireless applications via

(30)

an intuitive web-based interface. w-iLab.t hosts dierent types of wireless nodes such as sensor nodes, Wi-Fi based nodes, sensing platforms, and cognitive radio platforms. Each of these devices can be fully congured by the experimenters. The wireless nodes are also connected over a wired interface for management purposes. As these Ethernet interfaces can also be used during experiments, heterogeneous wireless and wired experiments are possible.

A tool, namely JFed, has been added to help the experimenter in his interaction with the nodes of the testbed. JFed provides a GUI that provides assistance in preparing the experiments, booking the required resources and controlling the execution. As the sensor nodes are only equipped with an IPv6 IP address, JFed also provides a proxy mechanism to enable the communication between IPv4 devices and the nodes.

3.4 The ECOAP project

The University of Pisa gave its contribution to WiSHFUL through the ECOAP project. The ECOAP experiments aimed at carrying out a per-formance evaluation of dierent congestion control strategies for CoAP under realistic conditions. Some of these new policies have been imple-mented and analysed in this work of thesis.

The WiSHFUL framework needed to be extended to create the proper experimentation scenario for the ECOAP studies. Firstly, a new CoAP module has been developed to allow the instantiation of the CoAP end-points that generate the trac. Moreover, the WiSHFUL basic set of UPIs has been extended to allow the implementation of the dierent congestion control policies as Local and Global Control programs.

The scenario that has been considered in the ECOAP experiments is a typ-ical Internet-of-Things network where several sensor nodes are deployed

(31)

Figure 3.4: Scenario for the ECOAP experiments

randomly in the environment, as depicted in gure 3.4. Each of the sensor nodes is assumed to be equipped with a low-power wireless transceiver, e.g. an IEEE 802.15.4 wireless radio, for low-power wireless communica-tion. The sensors adopt the standard protocol stack dened within IETF, i.e. IPv6 for communication through the 6LoWPAN adaptation layer and the RPL [10] routing protocol to implement multi-hop communication capabilities.

Each sensor node behaves as a CoAP client, i.e. it issues a POST request to a CoAP server. The server is assumed to be external to the Wireless Sensor Network and executed on a powerful host, e.g. an embedded system or a cloud server, which runs a fully functional operating system. A sensor node belonging to the network is congured as border router to enable the communication with the external CoAP server.

As said before, the implementation of this scenario has required a set of extensions to the WiSHFUL platform. A new CoAP module has been added to allow the generation of CoAP trac in the experiments through the instantiation of CoAP endpoints on both embedded PCs and sensor nodes. Specically, COAPthon, a Python library that implements the CoAP protocol [11], has been exploited for the instantiation of the CoAP

(32)

Figure 3.5: The WiSHFUL overall conguration after the modications

endpoints on the embedded PCs. The instantiation of the CoAP servers and clients on the wireless sensor nodes has been realized by exploiting the CoAP implementation already available on the Contiki OS, instead. The original UP IN interface has been modied to allow the conguration

of CoAP servers and clients by means of the WiSHFUL platform. In particular, a new set of functions has been added to control the trac generation process, e.g. the size of request messages, the time interval between subsequent requests, and the type of trac, and to measure the CoAP-related metrics, such as the overall number of requests, the Round Trip Time (RTT), the number of retransmissions of each request, the number of failed transactions, etc.

The WiSHFUL platform has been congured to execute the experiment scenario described above with the set-up shown in gure 3.5. An agent is instantiated on the embedded system to which each sensor is attached and is congured to run the GITAR software required for the management and the control of the device using the Contiki module. The experiment is controlled via a Global Control Program and a custom Local Control Program that is run by each agent. The Global Controller is programmed to trigger the CoAP client running on each sensor at the beginning of the

(33)

Figure 3.6: The implementation schema of any congestion control algorithm

experiment. One sensor node is congured as network border router, and the agent that is attached to it has been congured to run a CoAP server through the instantiation of the CoAPthon module. The tunslip inter-face that connects the border router to the embedded system is exploited to enable the communication between the Wireless Sensor Network and the external CoAP server. Specically, the interface is congured to let the CoAP trac ow from the WSN to the local CoAP server and vice versa, in addition to the WiSHFUL control trac between the agent and the border router. The Local Control Program is congured to collect statistics and events that occur on each sensor node. Such metrics are forwarded to the Global Control Program that stores the data on les for o-line analysis.

The execution of the experiments has also required the introduction of additional events and parameters with the specic goal of allowing the implementation of the dierent congestion control strategies within the WiSHFUL framework as Local Controllers. The implementation of these algorithms has been moved out from the actual device to the Local Control Program for three main reasons:

(34)

1. The standard interface exposed by the WiSHFUL platform allows to retrieve heterogeneous information and set dierent parameters in an easy way. On the other hand, the direct implementation on the device would require several modications to the code of the CoAP library and the network module of the Operating System.

2. The implementation of the congestion control algorithms is indepen-dent from the devices, i.e. the same code can control the behaviour of a sensor node or an embedded system.

3. The WiSHFUL framework enables the implementation of congestion control policies that have a centralized component. Specically, the global and hierarchical interfaces UP IGand UP IHC can be exploited

to deploy a Global Control Program that implements centralized congestion control policies based on the global network knowledge. Each congestion control policy that has been implemented basically follows a common schema, shown in gure 3.6 on the previous page. As can be seen, the logic of the algorithm is implemented within the Local Control Program. A set of specic new events has been added to the network interface UP IN to capture some meaningful changes occurring within the

device. Each event reports information regarding the CoAP transaction, specically the Message Identier eld (MID), the measured Round Trip Time (RTT) and the number of retransmissions. For each of these events, a callback function has been added to the algorithm implementation. This skeleton also includes a set of abstract functions, each one corresponding to the basic functionalities required for the implementation of a congestion control algorithm, in addition to the specic code.

Each algorithm computes the Retransmission Time-Out (RTO) value to be adopted for the subsequent transmissions and retransmissions. Whenever a new RTO value is produced, as consequence of an event or because an internal timer red, the congestion control noties the new value to the

(35)

sensor node. Moreover, a function to set a maximum transmission rate has been introduced to control the rate at which new CoAP transactions are generated. If set, the maximum transmission rate is enforced by the sensor node by monitoring the actual transmission rate and enabling idle periods between two subsequent CoAP transactions when it is needed to reduce the rate.

(36)

Chapter 4 CoAP-R: A centralized congestion

control algorithm

4.1 Introduction

The CoCoA algorithm [4], recently extended in CoCoA+ [5], has been de-signed to provide an eective mechanism in CoAP to deal with the problem of congestion inside the network. The algorithm exploits continuous mea-surements of the Round Trip Time (RTT) between CoAP endpoints to regulate the retransmission rate and avoid frequent retransmissions that can lead to network congestion. Although it is widely acknowledged that CoCoA+ can ensure a higher throughput than basic CoAP congestion control algorithm in several situations, many research works highlighted its limitations and shortcomings [6] [7]. For instance, in [6], the authors identied some possible causes for this behaviour:

IoT communications are expected to be subject to large and variable Round Trip Times due to the radio duty cycling and the presence of lossy links. Moreover, IoT trac is typically sporadic, which makes it more dicult to maintain the state information always up to date. Thus, CoCoA+ makes use of all the available trac, including the retransmitted packets, to collect the RTT measurements. However, collecting reliable RTT measurements from retransmitted packets is dicult in CoAP because the Message ID (MID) is maintained unchanged during the retransmissions and the CoAP source node cannot establish the correct RTT of request/response interactions.

(37)

The RTT values vary signicantly in an IoT network, even when the network conditions are relatively stable. Small RTT estimates can easily cause unnecessary retransmissions, because they lead to small RTOs, which reduce the ability of the retransmission timer to eciently cope with uctuations of the Round Trip Time.

By default, the CoCoA+ source nodes transmit a single message at a time. This behaviour can create potential ineciencies, as the source node can be blocked waiting for ACKs that will never arrive due to packet losses. Similarly, long messages can cause long retransmission delays that reduce the throughput.

The RTO estimators may not work properly with trac bursts (e.g trac that is generated when an event is simultaneously detected by multiple monitoring nodes in the network). In this case, the selected RTO value may underestimate the real RTT, causing unnecessary retransmissions.

The issues described above are linked to the fact that the sending rate of the nodes has only slight and temporary slowdowns that are not sucient to maintain the network working point far form the saturation zone. In fact, CoCoA+ is window-based. Basically, the window size is the amount of data the sender is allowed to have in transit in the network, not yet acknowledged by the receiver. The sources increase or decrease the window size based on the feedback of received ACKs, and in this way indirectly regulate the sending rate.

For this reason, successive research works consider an alternative approach to implement trac and congestion control, based on directly limiting the rate at which the sources can send. CoAP-R [12] is an example of rate-based congestion control algorithm. A certain rate is allocated to each CoAP client to regulate its data transmission, and the allocation lever-ages the tree-based routing structure built by the RPL routing protocol.

(38)

Firstly, the algorithm estimates the maximum throughput that can be obtained on the bottleneck link of every upward route. After that, based on the knowledge of the bottleneck rates, a fair allocation of the available network capacity is performed and the sending rate of the CoAP sources is regulated accordingly. The goal of the algorithm is to minimize the overall maximum transmission delay in the network, which could be desirable in applications in which multiple nodes report its data concurrently. This is a novel aspect of CoAP-R with respect to CoCoA+, that cannot ensure fairness among dierent trac sources, and thus neither similar through-puts.

In this master thesis, a further step has been made. Leveraging the fact that the WiSHFUL framework also includes a centralized component, the Global Controller, that has an overall vision of the network and is able to know the routing topology, a centralized version of the CoAP-R algorithm has been designed. In this case, it is the controller that computes the optimal sending rate for each CoAP source after receiving an estimate of the link quality. The congestion control is expected to be more ecient, as the Global Controller takes decisions considering the overall state of the network.

4.2 Centralized COAP-R design

The centralized version of CoAP-R assumes a tree routing topology rooted at the sink node, e.g. the tree built by the RPL network protocol, in which each sensor node receives and forwards packets from the down-stream neighbours to its parent node, named preferred parent. Each sen-sor estimates the capacity of the link to its preferred parent by measuring the packet service time. Then, all these measurements are sent by each Local Controller to the Global Controller that uses them to identify the bottleneck links inside the network. The bottleneck bandwidth denes an

(39)

upper bound on the transmission rate of all ows that share that partic-ular link. The rate allocation is triggered assuming that each sensor node has data to send and demands an equal share of the bottleneck link. A progressive lling algorithm is applied to determine a max-min fair rate allocation. Then, the Global Controller sends back to each Local Con-troller the computed rate allocation and, upon receiving it, the sources modify their sending rate. In the following sections, all the steps followed by the Local or Global Controllers are explained in more detail.

4.2.1 Link capacity estimation

As said before, the maximum available link bandwidth is estimated by measuring the packet service time Si, dened as the time between the

instant in which the packet reaches the head of the MAC transmission queue and the time instant in which the packet is successfully received by the next hop. The packet service time is measured at the MAC layer of the sensor and reported periodically to the Local Controller.

Every 30 seconds, the Local Controller estimates the link capacity. In particular, it computes the instantaneous link throughput Li as:

Li =

b Si

(4.1) where b = 35 is the packet size. Clearly, the measurements of the in-stantaneous link throughput Li are very noisy due to the bursty nature

of the trac, the random back-o procedures of the MAC layer, and time-varying channel conditions. For this reason, a classical exponentially weighted moving-average approach is used to lter out the uctuations in the measurements and to obtain a long-term forecast. Specically, at the nth _{transmission, the average capacity of the link is computed as:}

LA_i (n) = αA· Li(n) + (1 − αA) · L A

i (n − 1) (4.2)

(40)

However, for eective congestion control, it is also important to quickly identify localised trends and rises of network congestion due to temporary conditions such as very large back-o times or increments of queue lengths. For this reason, CoAP-R employs a second estimator of the link capacity, LW_i (n), for estimating the link throughput when the channel is performing sensibly worse than usual. More formally, the average capacity of the link is obtained through the formula:

LW_i (n) = αW · Li(n) + (1 − αW) · L W

i (n − 1) (4.3)

where αW is dened as:

αW =      αA, Li(n) ≥ L A i (n) β · αA, otherwise (4.4) and β > 1. The rationale behind the above selection is to assign a higher weight to samples of link throughput that may indicate the network con-gestion or a degradation of the link performance. Finally, the maximum capacity of the link between the node i and its parent is dened as:

ci = L W

i (4.5)

This information is sent by each Local Controller to the Global Controller and is used to compute the correct rate allocation for each node.

4.2.2 Rate allocation

The key design principle of CoAP-R is to pursue a max-min fair allocation of sending rates. A feasible allocation of rates is said to be max-min fair if and only if it is not possible to increase the allocated rate of any connection without decreasing an already smaller rate of some other connection. The problem can be formulated as follows.

(41)

Assume that there are n nodes in the tree network. Let: di be the maximum rate demanded by node i;

ai be the sending rate allocated to node i;

Ai be the overall sending rate allocated to all the nodes in the

sub-tree rooted by i, STi;

cibe the maximum capacity of the link between node i and its parent

node.

The problem of nding a max-min fair allocation can be formulated as to nd a solution for the following constrained problem:

           max{miniai} Ai ≤ ci, 1 ≤ i ≤ n ai ≤ di, 1 ≤ i ≤ n (4.6)

A solution to the equation 4.6 is provided by the Progressive Filling algo-rithm. As a rate allocation is max-min fair if and only if every connection has a bottleneck link, i.e. a link that is fully saturated, CoAP-R tries to determine the bottleneck link of each connection and to limit the sending rate of ows to not violate the constraints.

According to the principles explained above, upon receiving the capacity estimations from the Local Controllers, the Global Controller builds a tree of the nodes based on the RPL routing information received from the network layer. Then, it visits the tree following a Breadth-First Search (BFS) strategy: it starts from the root of the tree and explores the rst level before moving to nodes at the next level, and so on. Each node i is allocated a share of the capacity of the link to the parent, proportional to the number of nodes belonging to the sub-tree STi rooted by it.

A pseudo-code representing the Progressive Filling algorithm run on each node of the tree is shown in listing 4.1 on the following page. As long as

(42)

Listing 4.1: The rate allocation algorithm Define :

S: s e t o f nodes r e q u i r i n g a l l o c a t i o n R: r e s i d u a l a l l o c a b l e r a t e

ai: r a t e a l l o c a t e d to the node i by i t s parent

ri: r e s i d u a l demand o f node i

ci: capacity estimated by the node i

ni: nodes in the subtree rooted by i

S =ID of the node i and of its children R = ai ri= ai for a l l c h i l d r e n j o f node i rj = cj/nj while S 6= 0 and R > 0 k = argminl∈S{rl} i f Pl∈Snlrk≤ R then δ = rk to_remove = k else δ = P R l∈Snl for a l l l ∈ S do i f l = i then al= al+ δ else al= al+ δnl rl= rl− δ R = R −P l∈Snlδ i f to_remove 6= 0 then S = S \ {to_remove}

(43)

there is at least one source with unsatised demand, and there is still some residual rate to allocate, the minimum residual rate that can be provided to any source rk is found. Then, the algorithm searches the incremental

rate δ that can be allocated depending on whether the residual rate R is sucient to allocate rk to all the sources or not. Finally, the allocated

rates, the residual demands, the residual rate and the set S are updated accordingly. After computing the rate allocation for each node of the tree, the Global Controller sends it back to the Local Controllers.

4.2.3 Rate control mechanism

Upon receiving the rate allocation from the Global Controller, the Lo-cal Controllers of each node implement a trac control mechanism to identify the beginning of network congestion and mitigate it. Congestion detection is performed using the present and past channel loading con-ditions. Specically, if the source's current sending rate acurr is greater

than the rate ai allocated by the Global Controller, CoAP-R decreases the

sending rate for the next transmission to avoid congestion. However, to improve the stability of the system, the congestion mitigation procedures are triggered only when the ratio between the current sending rate and the allocated rate is greater than a margin, named hysteresis margin, ωH > 1.

In this case, the new sending rate is updated following a multiplicative decrease strategy:

anew = acurr−

|acurr− ai|

η (4.7)

where η = 5. On the other hand, if the adopted sending rate is lower than the fair rate recommended by the Global Controller, it is always increased following a multiplicative increase strategy:

anew = acurr+

|acurr− ai|

η (4.8)

CoAP retransmissions are handled using the same rate-based trac con-trol scheme adopted for the regular transmissions. The Retransmission

(44)

Time-Out (RTO), set to detect a lost transmission, is set as in legacy CoAP: it is randomly picked from the interval [2000, 3000] ms and, sub-sequently, a binary exponential back-o is applied, doubling the RTO in-terval every time a retransmission occurs. A total of four retransmissions of a specic CoAP message is allowed, before considering the exchange to have failed.

Finally, an ageing policy is introduced to avoid that, at the beginning of a new trac burst, a node uses an initial sending rate that is too aggressive. For this purpose, a time-out Tf is introduced to determine the freshness

of the rate information. More formally, if a node does not generate new packets or does not forward any packet received from its neighbours before the expiration of the timer, the sending rate acurr is reset to the minimum

value that has been used in the last burst. In this way, each node can probe the available bandwidth at the beginning of the new burst of trac.

(45)

Chapter 5 CoAP-R simulation results

5.1 The experiment set-up

5.1.1 Analysed congestion control algorithms

The CoAP-R congestion control algorithm presented in the previous sec-tion has been compared against the standard congessec-tion control algorithm adopted in CoAP [3] and the improved version of this algorithm, CoCoA+ [5]. Both the algorithms are distributed and executed locally at each node of the network, so the analysis focused on demonstrating if an algorithm with a global knowledge of the status of the network such as the cen-tralized version of CoAP-R can outperform the local congestion control algorithms. The main characteristics of Default CoAP and CoCoA+ con-gestion control algorithms have been presented in section 2.2 and 2.3 on page 13.

5.1.2 Experimentation scenarios

The experiments have been run on two dierent scenarios, Floor 11 and PINT. The latter has been mainly used during the phase of design of the algorithms for a quick test of the functionalities. The results that are presented in this thesis have been collected from the Floor 11 testbed, instead, as it contains a greater number of nodes and so the eectiveness of the dierent policies can be tested more accurately.

(46)

Figure 5.1: Floor 11 - W-iLab.t testbed

Floor 11 - W-iLab.t

The Floor 11 scenario is executed on the W-iLab.t testbed deployed in Belgium. The scenario, depicted in gure 5.1, includes all the nodes avail-able at the oor 11 of the iMinds building. All the nodes are connected through an Ethernet LAN to a server that is used to manage and control the experiments. The WiSHFUL agent has been deployed on each NUC mini OC, while the WiSHFUL controller has been deployed on NUC 11-25. The Zolertia Zoul attached to NUC 25-11 has been congured as RPL border router, consequently the corresponding agent has been congured to deploy the CoAP server.

PINT

The PINT scenario is executed on the Pisa IoT Network Testbed (PINT). The testbed is deployed in the two-oor building of the Department of In-formation Engineering of the University of Pisa, within oces, laboratories and classrooms. The core infrastructure of the testbed is a Wireless Sen-sor Network composed of 22 nodes installed in dierent rooms, as shown

(47)

Figure 5.2: PINT testbed

in gure 5.2. Each node is composed of a Raspberry PI II to which two sensor boards, one Zolertia Zoul and one TelosB sensor, are connected. All the nodes are linked together through an Ethernet LAN to a server that is used to manage and control the experiments. The controller is installed in the same room of node 21. It is also attached to one Zolertia Zoul and one TelosB board, which can be programmed as border router to connect the Wireless Sensor Network with external networks.

Considering that the PINT architecture presents similarities to the W-iLab.t architecture, running the WiSHFUL platform on PINT have not implied signicant issues. The version of the Contiki OS that has been modied by the WiSHFUL project has been deployed on the Zoul sensors, while the WiSHFUL agent has been instantiated on each Raspberry PI. The WiSHFUL controller has been instantiated on the PINT controller. The controller also runs an instance of the WiSHFUL agent to manage the Zoul sensor selected as RPL border router, and instantiate the CoAP server to which all the requests are directed.

(48)

5.1.3 Trac characterization

In this master thesis, all the experiments that have been run to assess the performance of the congestion control policies adopt bursty CoAP trac. Each CoAP endpoint alternates between an ON phase, in which the CoAP trac is generated, and an OF F phase, in which the node does not issue any CoAP transaction. CoAP clients start from an OF F phase so that the RPL topology can stabilize. During the ON phases, each node issues a certain number m of conrmable POST requests towards the server in a back-to-back manner, i.e. a new request is issued right after the reception of the ACK of the previous request, or its denitive failure when the maximum number of retransmissions is reached. The CoAP sources are enabled after a random time between 1s and 5s to avoid the synchronization eects. The length of each ON and OF F phase is set to 600s. In this case, each experiment has a duration of 3300s. This type of trac has been adopted to assess the performance of the congestion control algorithms with a trac that mimics the one originated from a Wireless Sensor Network where sensors are congured to detect a certain event (e.g. an alarm system). As the event is detected simultaneously by all the sensors, a burst of trac is originated. The challenge for the congestion control algorithm in this case is to deliver all the data of the burst from all the sensors to the sink in the shortest time possible, so that all data can be analysed quickly.

5.1.4 Analysed metrics

Dierent metrics have been collected by the Global Controller during the execution of the experiments and have been stored on les for o-line analysis. The analysed metrics are specied below:

Data collection delay (milliseconds): under the assumption that the sensed data is generated in response to a detected event, it is the

(49)

time needed to complete the collection at the sink node of the data transmitted by all the sensors that detected the same event;

Overall number of preferred parent resets: it is the number of times a node needed to reset its preferred parent because of inconsistencies in the routing tree, triggering the RPL Local Repair Procedure [10]; IPv6 overows (number of packets): it is the total number of IPv6 packets that are dropped by all the sensors because of the lack of space in the buers at IP layer;

Network reliability ratio (%): it is the ratio between the number of CoAP transactions that have been completed successfully and the number of CoAP transactions that have been issued;

Average number of transmissions per transaction: it is the average number of transmissions (rst transmissions or retransmissions) re-quired for each CoAP transaction;

Throughput (b/s): it is the number of information bits delivered by the network at a certain destination per unit of time;

Goodput (b/s): it is the number of useful information bits deliv-ered by the network at a certain destination per unit of time (the amount of considered data excludes protocol overhead bits as well as retransmitted data packets).

Each scenario has been replicated eight times to obtain statistically signif-icant results. For each metric, the average value and the 95% condence intervals have been computed.

The network has been congured with the parameters reported in table 5.1 on the following page. For the sake of brevity, only a subset of the results obtained in the experiments, i.e. the results obtained with the underlined values, is presented. The omitted results have not presented signicant

(50)

Parameter Values Routing protocol RPL

RPL Objective Function OF0, MRHOF RPL DIO interval doublings 4, 20

CoAP request size 35, 95 CoAP requests buer size 4 CoAP NSTART 1

MAC layer CSMA/CA MAC buer size 8 packets MAC level max retransmissions 8

Table 5.1: Values for the experiment parameters

Parameter Value αA 0.05 β 10 ωH 1.2 η 5 Tf 300s

Table 5.2: Values for CoAP-R parameters

variations from the included results and lead to the same conclusions. Table 5.2 shows how the CoAP-R parameters have been tuned.

5.2 Preliminary analysis

Before running the actual experiments, an initial set of tests has been per-formed with the goal of evaluating the possible inuence of the WiSHFUL framework itself on the results. Specically, the evaluation focused on the consequences of moving the implementation of the congestion control poli-cies from the sensor node, i.e. inside the Contiki OS, to a program that runs externally. The communication overhead introduced by the

(51)

WISH-FUL framework (e.g. control messages and measurements) could poten-tially impair the performance of the congestion control on the network, producing biased results.

In order to measure the impact of the framework, the results of the exper-iments obtained using WiSHFUL have been compared against the results obtained with the traditional implementation, in which the congestion control policy (only the Default CoAP policy has been considered in this case) is implemented directly in Contiki OS and the metrics are collected simply using serial line printouts without the WiSHFUL framework. This preliminary experiments have been run on the PINT testbed using a constant rate trac. All the CoAP clients periodically send conrmable POST requests towards the server. For each request that is received suc-cessfully, the server replies with a response piggybacked into a CoAP ACK message. Before starting to transmit CoAP requests, the CoAP clients wait for 60s to let the network topology stabilize, and then for a further random time between 1s and 30s to avoid any synchronization eect. Af-ter that, nodes start sending requests with a common period T injecting an increasing amount of data into the network. The results showed that the dierence in terms of carried load between the scenarios with and without WiSHFUL are negligible, and this conrmed that the results of the experiments are not biased because of the use of the framework.

5.3 Experimental results

As said before, the performance of CoAP-R is compared against the De-fault CoAP congestion control algorithm and CoCoA+. Experiments have been run on the Floor 11 - W-iLab.t testbed and RPL has been adopted as routing protocol. In order to evaluate the performance under dierent conditions, the number of messages in a burst m has been set considering the following values: 10, 20, 30, 40.

(52)

5.3.1 Data collection delay

A particular attention has been reserved to the analysis data collection delay, as the objective of the CoAP-R algorithm is to ensure a fair access to the network resources to all the nodes and so it is expected to reduce the variability of the collection delays with respect to the other policies. The distribution of the delays have been analysed through box-plot graphs: the bottom and the top of the boxes are the 25th _{and 75}th _{percentiles, the}

band in the middle of the box is the median (50thpercentile), and the ends

of the whiskers represent the minimum and the 95th _{percentile. As can be}

seen in gure 5.3 and 5.4 on the following pages, the CoAP-R congestion control algorithm succeeds into reducing the overall data collection delay for every burst size.

CoAP-R results to be more eective with large burst sizes. For a burst size m = 10 (gure 5.3a), all the three algorithms behave similarly, and the average data collection delay is very small. This behaviour is expected, as a smaller number of active sources implies a lower network conges-tion, independently from the congestion control policy that is adopted. Default CoAP and CoCoA+ do not waste network resources with spuri-ous retransmissions or unnecessarily long retransmission time-outs, while CoAP-R is not required to limit consistently the transmission rates of the nodes. When a larger burst size m = 40 is considered (gure 5.4b), CoAP-R is oered the possibility to show all its capabilities. It has a deeper control over the trac injected into the network and so it is able to control the congestion more eectively. In this case, it clearly outper-forms the other two congestion control policies. This results are line with the ones obtained with the distributed version of CoAP-R [12].

Evaluation of congestion control policies for the CoAP protocol through the WiSHFUL platform