Analytical Model of Large Data Transactions in CoAP Networks
Identifieur interne : 000549 ( Pmc/Corpus ); précédent : 000548; suivant : 000550Analytical Model of Large Data Transactions in CoAP Networks
Auteurs : Alessandro Ludovici ; Piergiuseppe Di Marco ; Anna Calveras ; Karl H. JohanssonSource :
- Sensors (Basel, Switzerland) [ 1424-8220 ] ; 2014.
Abstract
We propose a novel analytical model to study fragmentation methods in wireless sensor networks adopting the Constrained Application Protocol (CoAP) and the IEEE 802.15.4 standard for medium access control (MAC). The blockwise transfer technique proposed in CoAP and the 6LoWPAN fragmentation are included in the analysis. The two techniques are compared in terms of reliability and delay, depending on the traffic, the number of nodes and the parameters of the IEEE 802.15.4 MAC. The results are validated trough Monte Carlo simulations. To the best of our knowledge this is the first study that evaluates and compares analytically the performance of CoAP blockwise transfer and 6LoWPAN fragmentation. A major contribution is the possibility to understand the behavior of both techniques with different network conditions. Our results show that 6LoWPAN fragmentation is preferable for delay-constrained applications. For highly congested networks, the blockwise transfer slightly outperforms 6LoWPAN fragmentation in terms of reliability.
Url:
DOI: 10.3390/s140815610
PubMed: 25153143
PubMed Central: 4179025
Links to Exploration step
PMC:4179025Le document en format XML
<record><TEI><teiHeader><fileDesc><titleStmt><title xml:lang="en">Analytical Model of Large Data Transactions in CoAP Networks</title>
<author><name sortKey="Ludovici, Alessandro" sort="Ludovici, Alessandro" uniqKey="Ludovici A" first="Alessandro" last="Ludovici">Alessandro Ludovici</name>
<affiliation><nlm:aff id="af1-sensors-14-15610"> Wireless Network Group (WNG), Department of Telematics Engineering, Universitat Politècnica de Catalunya, C/Jordi Girona 1-3, Mòdul C3, 08034 Barcelona, Spain; E-Mail:<email>alessandro.ludovici@antel.upc.edu</email>
</nlm:aff>
</affiliation>
<affiliation><nlm:aff id="af2-sensors-14-15610"> i2CAT Foundation, Gran Capità 2-4 (Nexus Building), 08034 Barcelona, Spain</nlm:aff>
</affiliation>
</author>
<author><name sortKey="Di Marco, Piergiuseppe" sort="Di Marco, Piergiuseppe" uniqKey="Di Marco P" first="Piergiuseppe" last="Di Marco">Piergiuseppe Di Marco</name>
<affiliation><nlm:aff id="af3-sensors-14-15610"> School of Electrical Engineering, Royal Institute of Technology, 100 44 Stockholm, Sweden; E-Mails:<email>pidm@kth.se</email>
(P.D.M.);<email>kallej@kth.se</email>
(K.H.G.)</nlm:aff>
</affiliation>
</author>
<author><name sortKey="Calveras, Anna" sort="Calveras, Anna" uniqKey="Calveras A" first="Anna" last="Calveras">Anna Calveras</name>
<affiliation><nlm:aff id="af1-sensors-14-15610"> Wireless Network Group (WNG), Department of Telematics Engineering, Universitat Politècnica de Catalunya, C/Jordi Girona 1-3, Mòdul C3, 08034 Barcelona, Spain; E-Mail:<email>alessandro.ludovici@antel.upc.edu</email>
</nlm:aff>
</affiliation>
<affiliation><nlm:aff id="af2-sensors-14-15610"> i2CAT Foundation, Gran Capità 2-4 (Nexus Building), 08034 Barcelona, Spain</nlm:aff>
</affiliation>
</author>
<author><name sortKey="Johansson, Karl H" sort="Johansson, Karl H" uniqKey="Johansson K" first="Karl H." last="Johansson">Karl H. Johansson</name>
<affiliation><nlm:aff id="af3-sensors-14-15610"> School of Electrical Engineering, Royal Institute of Technology, 100 44 Stockholm, Sweden; E-Mails:<email>pidm@kth.se</email>
(P.D.M.);<email>kallej@kth.se</email>
(K.H.G.)</nlm:aff>
</affiliation>
</author>
</titleStmt>
<publicationStmt><idno type="wicri:source">PMC</idno>
<idno type="pmid">25153143</idno>
<idno type="pmc">4179025</idno>
<idno type="url">http://www.ncbi.nlm.nih.gov/pmc/articles/PMC4179025</idno>
<idno type="RBID">PMC:4179025</idno>
<idno type="doi">10.3390/s140815610</idno>
<date when="2014">2014</date>
<idno type="wicri:Area/Pmc/Corpus">000549</idno>
<idno type="wicri:explorRef" wicri:stream="Pmc" wicri:step="Corpus" wicri:corpus="PMC">000549</idno>
</publicationStmt>
<sourceDesc><biblStruct><analytic><title xml:lang="en" level="a" type="main">Analytical Model of Large Data Transactions in CoAP Networks</title>
<author><name sortKey="Ludovici, Alessandro" sort="Ludovici, Alessandro" uniqKey="Ludovici A" first="Alessandro" last="Ludovici">Alessandro Ludovici</name>
<affiliation><nlm:aff id="af1-sensors-14-15610"> Wireless Network Group (WNG), Department of Telematics Engineering, Universitat Politècnica de Catalunya, C/Jordi Girona 1-3, Mòdul C3, 08034 Barcelona, Spain; E-Mail:<email>alessandro.ludovici@antel.upc.edu</email>
</nlm:aff>
</affiliation>
<affiliation><nlm:aff id="af2-sensors-14-15610"> i2CAT Foundation, Gran Capità 2-4 (Nexus Building), 08034 Barcelona, Spain</nlm:aff>
</affiliation>
</author>
<author><name sortKey="Di Marco, Piergiuseppe" sort="Di Marco, Piergiuseppe" uniqKey="Di Marco P" first="Piergiuseppe" last="Di Marco">Piergiuseppe Di Marco</name>
<affiliation><nlm:aff id="af3-sensors-14-15610"> School of Electrical Engineering, Royal Institute of Technology, 100 44 Stockholm, Sweden; E-Mails:<email>pidm@kth.se</email>
(P.D.M.);<email>kallej@kth.se</email>
(K.H.G.)</nlm:aff>
</affiliation>
</author>
<author><name sortKey="Calveras, Anna" sort="Calveras, Anna" uniqKey="Calveras A" first="Anna" last="Calveras">Anna Calveras</name>
<affiliation><nlm:aff id="af1-sensors-14-15610"> Wireless Network Group (WNG), Department of Telematics Engineering, Universitat Politècnica de Catalunya, C/Jordi Girona 1-3, Mòdul C3, 08034 Barcelona, Spain; E-Mail:<email>alessandro.ludovici@antel.upc.edu</email>
</nlm:aff>
</affiliation>
<affiliation><nlm:aff id="af2-sensors-14-15610"> i2CAT Foundation, Gran Capità 2-4 (Nexus Building), 08034 Barcelona, Spain</nlm:aff>
</affiliation>
</author>
<author><name sortKey="Johansson, Karl H" sort="Johansson, Karl H" uniqKey="Johansson K" first="Karl H." last="Johansson">Karl H. Johansson</name>
<affiliation><nlm:aff id="af3-sensors-14-15610"> School of Electrical Engineering, Royal Institute of Technology, 100 44 Stockholm, Sweden; E-Mails:<email>pidm@kth.se</email>
(P.D.M.);<email>kallej@kth.se</email>
(K.H.G.)</nlm:aff>
</affiliation>
</author>
</analytic>
<series><title level="j">Sensors (Basel, Switzerland)</title>
<idno type="eISSN">1424-8220</idno>
<imprint><date when="2014">2014</date>
</imprint>
</series>
</biblStruct>
</sourceDesc>
</fileDesc>
<profileDesc><textClass></textClass>
</profileDesc>
</teiHeader>
<front><div type="abstract" xml:lang="en"><p>We propose a novel analytical model to study fragmentation methods in wireless sensor networks adopting the Constrained Application Protocol (CoAP) and the IEEE 802.15.4 standard for medium access control (MAC). The blockwise transfer technique proposed in CoAP and the 6LoWPAN fragmentation are included in the analysis. The two techniques are compared in terms of reliability and delay, depending on the traffic, the number of nodes and the parameters of the IEEE 802.15.4 MAC. The results are validated trough Monte Carlo simulations. To the best of our knowledge this is the first study that evaluates and compares analytically the performance of CoAP blockwise transfer and 6LoWPAN fragmentation. A major contribution is the possibility to understand the behavior of both techniques with different network conditions. Our results show that 6LoWPAN fragmentation is preferable for delay-constrained applications. For highly congested networks, the blockwise transfer slightly outperforms 6LoWPAN fragmentation in terms of reliability.</p>
</div>
</front>
<back><div1 type="bibliography"><listBibl><biblStruct><analytic><author><name sortKey="Miorandi, D" uniqKey="Miorandi D">D. Miorandi</name>
</author>
<author><name sortKey="Sicari, S" uniqKey="Sicari S">S. Sicari</name>
</author>
<author><name sortKey="De Pellegrini, F" uniqKey="De Pellegrini F">F. de Pellegrini</name>
</author>
<author><name sortKey="Chlamtac, I" uniqKey="Chlamtac I">I. Chlamtac</name>
</author>
</analytic>
</biblStruct>
<biblStruct></biblStruct>
<biblStruct><analytic><author><name sortKey="Chebrolu, K" uniqKey="Chebrolu K">K. Chebrolu</name>
</author>
<author><name sortKey="Raman, B" uniqKey="Raman B">B. Raman</name>
</author>
<author><name sortKey="Mishra, N" uniqKey="Mishra N">N. Mishra</name>
</author>
<author><name sortKey="Valiveti, P K" uniqKey="Valiveti P">P.K. Valiveti</name>
</author>
<author><name sortKey="Kumar, R" uniqKey="Kumar R">R. Kumar</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Kim, S" uniqKey="Kim S">S. Kim</name>
</author>
<author><name sortKey="Pakzad, S" uniqKey="Pakzad S">S. Pakzad</name>
</author>
<author><name sortKey="Culler, D" uniqKey="Culler D">D. Culler</name>
</author>
<author><name sortKey="Demmel, J" uniqKey="Demmel J">J. Demmel</name>
</author>
<author><name sortKey="Fenves, G" uniqKey="Fenves G">G. Fenves</name>
</author>
<author><name sortKey="Glaser, S" uniqKey="Glaser S">S. Glaser</name>
</author>
<author><name sortKey="Turon, M" uniqKey="Turon M">M. Turon</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Werner Allen, G" uniqKey="Werner Allen G">G. Werner-Allen</name>
</author>
<author><name sortKey="Lorincz, K" uniqKey="Lorincz K">K. Lorincz</name>
</author>
<author><name sortKey="Ruiz, M" uniqKey="Ruiz M">M. Ruiz</name>
</author>
<author><name sortKey="Marcillo, O" uniqKey="Marcillo O">O. Marcillo</name>
</author>
<author><name sortKey="Johnson, J" uniqKey="Johnson J">J. Johnson</name>
</author>
<author><name sortKey="Lees, J" uniqKey="Lees J">J. Lees</name>
</author>
<author><name sortKey="Welsh, M" uniqKey="Welsh M">M. Welsh</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Montenegro, G" uniqKey="Montenegro G">G. Montenegro</name>
</author>
<author><name sortKey="Kushalnagar, N" uniqKey="Kushalnagar N">N. Kushalnagar</name>
</author>
<author><name sortKey="Hui, J" uniqKey="Hui J">J. Hui</name>
</author>
<author><name sortKey="Culler, D" uniqKey="Culler D">D. Culler</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Shelby, Z" uniqKey="Shelby Z">Z. Shelby</name>
</author>
<author><name sortKey="Hartke, K" uniqKey="Hartke K">K. Hartke</name>
</author>
<author><name sortKey="Bormann, C" uniqKey="Bormann C">C. Bormann</name>
</author>
<author><name sortKey="Frank, B" uniqKey="Frank B">B. Frank</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Bormann, C" uniqKey="Bormann C">C. Bormann</name>
</author>
<author><name sortKey="Shelby, Z" uniqKey="Shelby Z">Z. Shelby</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Mesrinejad, F" uniqKey="Mesrinejad F">F. Mesrinejad</name>
</author>
<author><name sortKey="Hashim, F" uniqKey="Hashim F">F. Hashim</name>
</author>
<author><name sortKey="Noordin, N K" uniqKey="Noordin N">N.K. Noordin</name>
</author>
<author><name sortKey="Rasid, M F A" uniqKey="Rasid M">M.F.A; Rasid</name>
</author>
<author><name sortKey="Raja Abdullah, R S A" uniqKey="Raja Abdullah R">R.S.A. Raja Abdullah</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Weigel, A" uniqKey="Weigel A">A. Weigel</name>
</author>
<author><name sortKey="Turau, V" uniqKey="Turau V">V. Turau</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Potsch, T" uniqKey="Potsch T">T. Potsch</name>
</author>
<author><name sortKey="Kuladinithi, K" uniqKey="Kuladinithi K">K. Kuladinithi</name>
</author>
<author><name sortKey="Becker, M" uniqKey="Becker M">M. Becker</name>
</author>
<author><name sortKey="Trenkamp, P" uniqKey="Trenkamp P">P. Trenkamp</name>
</author>
<author><name sortKey="Goerg, C" uniqKey="Goerg C">C. Goerg</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Sammarco, C" uniqKey="Sammarco C">C. Sammarco</name>
</author>
<author><name sortKey="Iera, A" uniqKey="Iera A">A. Iera</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Hartke, K" uniqKey="Hartke K">K. Hartke</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Di Marco, P" uniqKey="Di Marco P">P. Di Marco</name>
</author>
<author><name sortKey="Pangun, P" uniqKey="Pangun P">P. Pangun</name>
</author>
<author><name sortKey="Fischione, C" uniqKey="Fischione C">C. Fischione</name>
</author>
<author><name sortKey="Johansson, K H" uniqKey="Johansson K">K.H. Johansson</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Pollin, S" uniqKey="Pollin S">S. Pollin</name>
</author>
<author><name sortKey="Ergen, M" uniqKey="Ergen M">M. Ergen</name>
</author>
<author><name sortKey="Ergen, S C" uniqKey="Ergen S">S.C. Ergen</name>
</author>
<author><name sortKey="Bougard, B" uniqKey="Bougard B">B. Bougard</name>
</author>
<author><name sortKey="Van Der Perre, L" uniqKey="Van Der Perre L">L. van der Perre</name>
</author>
<author><name sortKey="Moerman, I" uniqKey="Moerman I">I. Moerman</name>
</author>
<author><name sortKey="Bahai, A" uniqKey="Bahai A">A. Bahai</name>
</author>
<author><name sortKey="Varaiya, P" uniqKey="Varaiya P">P. Varaiya</name>
</author>
<author><name sortKey="Catthoor, F" uniqKey="Catthoor F">F. Catthoor</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Park, P" uniqKey="Park P">P. Park</name>
</author>
<author><name sortKey="Di Marco, P" uniqKey="Di Marco P">P. di Marco</name>
</author>
<author><name sortKey="Fischione, C" uniqKey="Fischione C">C. Fischione</name>
</author>
<author><name sortKey="Johansson, K H" uniqKey="Johansson K">K.H. Johansson</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Gao, J" uniqKey="Gao J">J. Gao</name>
</author>
<author><name sortKey="Hu, J" uniqKey="Hu J">J. Hu</name>
</author>
<author><name sortKey="Min, G" uniqKey="Min G">G. Min</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Ludovici, A" uniqKey="Ludovici A">A. Ludovici</name>
</author>
<author><name sortKey="Calveras, A" uniqKey="Calveras A">A. Calveras</name>
</author>
<author><name sortKey="Casademont, J" uniqKey="Casademont J">J. Casademont</name>
</author>
</analytic>
</biblStruct>
</listBibl>
</div1>
</back>
</TEI>
<pmc article-type="research-article"><pmc-dir>properties open_access</pmc-dir>
<front><journal-meta><journal-id journal-id-type="nlm-ta">Sensors (Basel)</journal-id>
<journal-id journal-id-type="iso-abbrev">Sensors (Basel)</journal-id>
<journal-title-group><journal-title>Sensors (Basel, Switzerland)</journal-title>
</journal-title-group>
<issn pub-type="epub">1424-8220</issn>
<publisher><publisher-name>MDPI</publisher-name>
</publisher>
</journal-meta>
<article-meta><article-id pub-id-type="pmid">25153143</article-id>
<article-id pub-id-type="pmc">4179025</article-id>
<article-id pub-id-type="doi">10.3390/s140815610</article-id>
<article-id pub-id-type="publisher-id">sensors-14-15610</article-id>
<article-categories><subj-group subj-group-type="heading"><subject>Article</subject>
</subj-group>
</article-categories>
<title-group><article-title>Analytical Model of Large Data Transactions in CoAP Networks</article-title>
</title-group>
<contrib-group><contrib contrib-type="author"><name><surname>Ludovici</surname>
<given-names>Alessandro</given-names>
</name>
<xref ref-type="aff" rid="af1-sensors-14-15610"><sup>1</sup>
</xref>
<xref ref-type="aff" rid="af2-sensors-14-15610"><sup>2</sup>
</xref>
</contrib>
<contrib contrib-type="author"><name><surname>Di Marco</surname>
<given-names>Piergiuseppe</given-names>
</name>
<xref ref-type="aff" rid="af3-sensors-14-15610"><sup>3</sup>
</xref>
</contrib>
<contrib contrib-type="author"><name><surname>Calveras</surname>
<given-names>Anna</given-names>
</name>
<xref ref-type="aff" rid="af1-sensors-14-15610"><sup>1</sup>
</xref>
<xref ref-type="aff" rid="af2-sensors-14-15610"><sup>2</sup>
</xref>
<xref rid="c1-sensors-14-15610" ref-type="corresp"><sup>*</sup>
</xref>
</contrib>
<contrib contrib-type="author"><name><surname>Johansson</surname>
<given-names>Karl H.</given-names>
</name>
<xref ref-type="aff" rid="af3-sensors-14-15610"><sup>3</sup>
</xref>
</contrib>
</contrib-group>
<aff id="af1-sensors-14-15610"><label>1</label>
Wireless Network Group (WNG), Department of Telematics Engineering, Universitat Politècnica de Catalunya, C/Jordi Girona 1-3, Mòdul C3, 08034 Barcelona, Spain; E-Mail:<email>alessandro.ludovici@antel.upc.edu</email>
</aff>
<aff id="af2-sensors-14-15610"><label>2</label>
i2CAT Foundation, Gran Capità 2-4 (Nexus Building), 08034 Barcelona, Spain</aff>
<aff id="af3-sensors-14-15610"><label>3</label>
School of Electrical Engineering, Royal Institute of Technology, 100 44 Stockholm, Sweden; E-Mails:<email>pidm@kth.se</email>
(P.D.M.);<email>kallej@kth.se</email>
(K.H.G.)</aff>
<author-notes><corresp id="c1-sensors-14-15610"><label>*</label>
Author to whom correspondence should be addressed; E-Mail: <email>anna.calveras@antel.upc.edu</email>
; Tel.: +34-934-016-013; Fax: +34-934-011-058.</corresp>
</author-notes>
<pub-date pub-type="collection"><month>8</month>
<year>2014</year>
</pub-date>
<pub-date pub-type="epub"><day>22</day>
<month>8</month>
<year>2014</year>
</pub-date>
<volume>14</volume>
<issue>8</issue>
<fpage>15610</fpage>
<lpage>15638</lpage>
<history><date date-type="received"><day>26</day>
<month>6</month>
<year>2014</year>
</date>
<date date-type="rev-recd"><day>07</day>
<month>8</month>
<year>2014</year>
</date>
<date date-type="accepted"><day>13</day>
<month>8</month>
<year>2014</year>
</date>
</history>
<permissions><copyright-statement>© 2014 by the authors; licensee MDPI, Basel, Switzerland.</copyright-statement>
<copyright-year>2014</copyright-year>
<license><license-p>This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution license (<ext-link ext-link-type="uri" xlink:href="http://creativecommons.org/licenses/by/3.0/">http://creativecommons.org/licenses/by/3.0/</ext-link>
).</license-p>
</license>
</permissions>
<abstract><p>We propose a novel analytical model to study fragmentation methods in wireless sensor networks adopting the Constrained Application Protocol (CoAP) and the IEEE 802.15.4 standard for medium access control (MAC). The blockwise transfer technique proposed in CoAP and the 6LoWPAN fragmentation are included in the analysis. The two techniques are compared in terms of reliability and delay, depending on the traffic, the number of nodes and the parameters of the IEEE 802.15.4 MAC. The results are validated trough Monte Carlo simulations. To the best of our knowledge this is the first study that evaluates and compares analytically the performance of CoAP blockwise transfer and 6LoWPAN fragmentation. A major contribution is the possibility to understand the behavior of both techniques with different network conditions. Our results show that 6LoWPAN fragmentation is preferable for delay-constrained applications. For highly congested networks, the blockwise transfer slightly outperforms 6LoWPAN fragmentation in terms of reliability.</p>
</abstract>
<kwd-group><kwd>CoAP</kwd>
<kwd>6LoWPAN</kwd>
<kwd>analytical model</kwd>
<kwd>fragmentation</kwd>
<kwd>Internet of Things</kwd>
<kwd>IEEE 802.15.4</kwd>
</kwd-group>
</article-meta>
</front>
<body><sec sec-type="intro"><label>1.</label>
<title>Introduction</title>
<p>In the recent years, the Internet of Things (IoT) has emerged as one of the most promising developments of the Internet of the future. According to the IoT vision [<xref rid="b1-sensors-14-15610" ref-type="bibr">1</xref>
], devices with Internet connectivity will be embedded in the physical environment and in everyday objects. Wireless Sensor Networks (WSNs) constitute a key element of the IoT. The small size, low cost and low energy consumption of sensor devices, in fact, allows WSNs to be easily deployed in a variety of environments.</p>
<p>Monitoring and sensing of common physical variables as temperature, pressure or humidity are typical application of WSNs. They are characterized by having slow changes of state and, therefore, require a sensor node to sample their value at low rates. Generally, the information collected by each node is constituted by few bytes and fits the data frames defined by most common WSNs standard protocols such as the IEEE 802.15.4 protocol [<xref rid="b2-sensors-14-15610" ref-type="bibr">2</xref>
], which is the <italic>de facto</italic>
standard for MAC and physical layers of WSNs. A Maximum Transferable Unit (MTU) of 127 bytes is allowed for IEEE 802.15.4 data frames. The presence of the header as well as of security mechanisms reduces the payload to 87 bytes. Further overhead is created by upper layer protocols, which can reduce significantly the space available for application data.</p>
<p>Monitoring applications of physical variables that have frequent changes of state could not be compatible with the constraint of the IEEE 802.15.4 MTU. Typically sensor nodes sample and store the information in a data log that is later sent to a sink node. The size of the data log, however, does not fit with the packet constraints of WSN protocols. Example of such applications can be found in [<xref rid="b3-sensors-14-15610" ref-type="bibr">3</xref>
–<xref rid="b5-sensors-14-15610" ref-type="bibr">5</xref>
]. In [<xref rid="b3-sensors-14-15610" ref-type="bibr">3</xref>
] a WSN has been deployed to monitor railway vibrations and produces packets of 7 KB per node. In [<xref rid="b4-sensors-14-15610" ref-type="bibr">4</xref>
] the authors present a WSN application for structure health monitoring where each node produces data logs of 512 KB. A WSN used to monitor a volcano activity [<xref rid="b5-sensors-14-15610" ref-type="bibr">5</xref>
] produces data logs of 256 bytes per node. IoT protocols, therefore, should be able to deal with large packets.</p>
<p>The IETF has standardized the use of the IPv6 protocol in IEEE 802.15.4 networks. The resulting standard is known as IPv6 over Low Power Personal Area Networks (6LoWPAN) [<xref rid="b6-sensors-14-15610" ref-type="bibr">6</xref>
]. 6LoWPAN introduces an adaptation layer that allows IPv6 datagrams to meet the requirements of the IEEE 802.15.4. This layer provides a fragmentation mechanism for the packets that exceed the MTU of the IEEE 802.15.4 standard. 6LoWPAN fragmentation allows splitting a packet into many fragments, which are sent individually in 802.15.4 data frames. The reception of each frame relies on the link layer acknowledgment (MAC ACK) as defined in [<xref rid="b2-sensors-14-15610" ref-type="bibr">2</xref>
]. The link layer, however, is not able to distinguish if a data frame is part of a fragmented packet or not. Consequently, if a fragment is lost, then the subsequent fragments are sent, although it is not possible to reconstruct the packet. As a consequence, the whole fragmented packet has to be retransmitted. The Constrained Application Protocol (CoAP) [<xref rid="b7-sensors-14-15610" ref-type="bibr">7</xref>
] instead allows overcoming this drawback by enabling reliable transmission at application layer.</p>
<p>CoAP is a protocol defined by the IETF for WSN applications such as smart energy and building automation. CoAP implements the key features of HTTP while adding its own mechanisms to best adapt to WSN characteristics. Among them, CoAP defines an alternative to 6LoWPAN fragmentation, which is called CoAP blockwise transfer [<xref rid="b8-sensors-14-15610" ref-type="bibr">8</xref>
] to enhance reliability in large data transactions and avoid 6LoWPAN fragmentation. A packet is divided into blocks and the data transfer into multiple request/response transactions. In this sense, the transmission of a single block corresponds to a single CoAP request/response transaction. This provides reliable data transactions using CoAP confirmable (CON) messages. A node receiving a CON message must acknowledge its reception to the source node. Should the source node not receive a CoAP acknowledgment (CoAP ACK), it retransmits the request. Then, the failure of a single block causes only the retransmission of the relative request. Instead, a fragmented 6LoWPAN packet is sent in a unique CoAP request/response transaction. The CoAP ACK, therefore, is sent after that all the fragments have been received.</p>
<p>Although the blockwise transfer is designed to improve the reliability and reduce the number of retransmitted packets for a dedicated client-server transmission, its effect on reliability and delay in a contention-based network scenario may not be always positive. In fact, due to the transmission of a CoAP ACK for each block, the CoAP blockwise transfer causes a higher traffic in the network and therefore a higher level of contention at MAC layer.</p>
<p>In the literature there are only few works that focus on CoAP blockwise transfer and 6LoWPAN fragmentation. The study in [<xref rid="b9-sensors-14-15610" ref-type="bibr">9</xref>
] evaluates the effects of 6LoWPAN fragmentation on the energy consumption. An analytical model of 6LoWPAN route-over forwarding mechanism is considered in [<xref rid="b10-sensors-14-15610" ref-type="bibr">10</xref>
], which includes the presence of 6LoWPAN fragmentation. CoAP blockwise transfer is considered in [<xref rid="b11-sensors-14-15610" ref-type="bibr">11</xref>
,<xref rid="b12-sensors-14-15610" ref-type="bibr">12</xref>
]. In [<xref rid="b11-sensors-14-15610" ref-type="bibr">11</xref>
], an experimental assessment of the performance of CoAP with blockwise transfer is illustrated. As a preliminary result, it is shown that the medium access contention has a strong impact on the performance. In [<xref rid="b12-sensors-14-15610" ref-type="bibr">12</xref>
], the authors present a service management system that seeks to reduce the energy consumed by blockwise transfer. However, to the best of our knowledge, there is no analytical study available that assesses the performance and the fundamental limits of 6LoWPAN fragmentation and CoAP blockwise transfer when used in contention-based scenarios. A thorough study of both techniques is therefore needed to understand their behavior and optimize their use in WSNs.</p>
<p>In this paper, we propose a novel analytical model to study the CoAP blockwise transfer and 6LoWPAN fragmentation in WSNs. The main contribution is the possibility to understand and compare the behavior of both techniques with different network conditions.</p>
<p>We consider reliability and delay as performance indicators. Both techniques are evaluated using the CoAP observe model [<xref rid="b13-sensors-14-15610" ref-type="bibr">13</xref>
]. This allows a client node to register to a resource exposed by a server node and to receive updates of its states. The application of this model helps to reduce the request/response interaction and it is particularly useful in WSN monitoring applications.</p>
<p>Our model considers the presence of the Carrier-Sense Multiple Access with Collision Avoidance (CSMA/CA) mechanism defined by the IEEE 802.15.4 standard. The inclusion of this mechanism is instrumental to understand the interaction between higher-layer protocols such as 6LoWPAN and CoAP with the IEEE 802.15.4. In particular, it allows evaluating the packet losses caused by collisions and channel access failures. The study in [<xref rid="b14-sensors-14-15610" ref-type="bibr">14</xref>
] is used as a basis for the analysis of the CSMA/CA mechanism. Its application to our study presents several challenges. Although it is typically assumed that the application layer generates packets following a known traffic distribution (e.g., the Poisson distribution), the subsequent fragmentation or block division implies a bursty transmission at MAC layer. We refer to this traffic condition as ‘mixed’ traffic. At MAC layer, in fact, only the arrival of the first fragment or block follows a Poisson distribution. The arrival of the remaining fragments or blocks is characterized by a saturated traffic condition. Therefore, moving forward from the assumption made in [<xref rid="b14-sensors-14-15610" ref-type="bibr">14</xref>
], the busy channel probability and the collision probability depend on the transmission stage. The analysis of this behavior requires adapting the original CSMA/CA model to the new traffic conditions. Existing works on the IEEE 802.15.4 MAC protocol have considered both saturated traffic (<italic>i.e.</italic>
, when node queues are always non-empty) and unsaturated traffic conditions (e.g., [<xref rid="b14-sensors-14-15610" ref-type="bibr">14</xref>
–<xref rid="b16-sensors-14-15610" ref-type="bibr">16</xref>
]). Bursty ON-OFF traffic conditions have only been considered in [<xref rid="b17-sensors-14-15610" ref-type="bibr">17</xref>
]. None of the existing works focus on the presence of mixed traffic conditions in the analysis of the IEEE 802.15.4 MAC protocol, which is a further contribution of this paper.</p>
<p>In the next section we review 6LoWPAN fragmentation, CoAP blockwise transfer and the unslotted CSMA/CA mechanism as defined by the IEEE 802.15.4 standard. The rest of the paper is organized as follows: in Section 3 we review and present the adaptation of the analytical model presented in [<xref rid="b14-sensors-14-15610" ref-type="bibr">14</xref>
]. The proposed model of 6LoWPAN fragmentation and blockwise transfer is illustrated in Section 4. In Section 5 we validate the model by Monte Carlo simulations and present the results of the performance evaluation. Finally, in Section 6 we conclude the paper and give some guidelines for future works.</p>
</sec>
<sec><label>2.</label>
<title>Background</title>
<p>In this section, we present 6LoWPAN fragmentation and CoAP blockwise transfer. Both techniques can be used in CoAP data transactions. As mentioned, they allow transmitting packets that do not fit in a single IEEE 802.15.4 frame. Finally, we review the unslotted CSMA/CA mechanism as defined by the IEEE 802.15.4 standard.</p>
<sec><label>2.1.</label>
<title>6LoWPAN Fragmentation</title>
<p>6LoWPAN introduces an adaptation layer between network and data link layers. Its primary function is to encode the IPv6 header and to fragment the packets that exceed the MTU of the MAC layer. Should a packet need to be fragmented, 6LoWPAN appends a fragmentation header [<xref rid="b6-sensors-14-15610" ref-type="bibr">6</xref>
] to each fragment of the original packet. Two distinct headers are used to indicate whether the fragment is the first or it is one of the subsequent. The main difference relies in the presence of a header field that indicates the offset of the fragmentation. This is present only in subsequent fragments. <xref rid="f1-sensors-14-15610" ref-type="fig">Figure 1</xref>
shows the fragmentation header for the first fragment and the subsequent fragments.</p>
<p>The destination node of the fragments uses the source and destination addresses of the 802.15.4 header plus the <italic>datagram_size</italic>
and <italic>datagram_tag</italic>
to identify the fragments that belong to a given 6LoWPAN packet. The fragment reassembling process will produce the original packet with the size specified in the <italic>datagram_size</italic>
field. In the reassembling process, the node uses the <italic>datagram_offset</italic>
field to determine the location of the fragment within the original packet.</p>
<p>As mentioned, in this paper we consider CoAP data transactions that uses the observe model. <xref rid="f2-sensors-14-15610" ref-type="fig">Figure 2</xref>
shows the transfer of an observe update using 6LoWPAN fragmentation. The server sends the update using CoAP CON messages. Each update is composed by <italic>F</italic>
= <italic>2</italic>
fragments. The destination node acknowledges the correct reception of a fragment with a MAC ACK. Moreover, it sends a CoAP ACK to acknowledge the reception of the whole fragmented update. This is sent only after the client receives correctly the last fragment. Should the destination node not receive one of the <italic>F</italic>
fragments or the CoAP ACK transmission fails, the source node retransmits all the <italic>F</italic>
fragments up to four times, as specified in [<xref rid="b7-sensors-14-15610" ref-type="bibr">7</xref>
]. In the rest of this paper, we indicate with <italic>c</italic>
the maximum number of retransmissions allowed in CoAP.</p>
<p>With reference to <xref rid="f2-sensors-14-15610" ref-type="fig">Figure 2</xref>
, the server retransmits the second update after the expiration of the CoAP retransmission timeout (RTO) [<xref rid="b7-sensors-14-15610" ref-type="bibr">7</xref>
], which is consequent to the failure of both the transmission of the second fragment and that of the relative MAC retransmissions. The update is then retransmitted successfully. The third update instead, is retransmitted after all the MAC retransmissions of the CoAP ACK fail.</p>
</sec>
<sec><label>2.2.</label>
<title>CoAP Blockwise Transfer</title>
<p>Blockwise transfer enables the transmission of large CoAP packets in separated blocks. It is activated including the block option [<xref rid="b8-sensors-14-15610" ref-type="bibr">8</xref>
] in the CoAP header. CoAP defines two block options: <italic>block_1</italic>
and <italic>block_2</italic>
. Their use depends whether the payload is present in a response to a GET request (block_2) or in the POST or PUT request (block_1).</p>
<p>As illustrated in <xref rid="f3-sensors-14-15610" ref-type="fig">Figure 3</xref>
, the block option contains three kind of information: the size of the block (SZX), a flag to indicate if more blocks are following (M) and the sequence number of the block (NUM). The SZX and M fields have fixed size. The NUM field can have three different sizes: 4, 12 or 24 bits.</p>
<p>The observe update is divided in <italic>B</italic>
blocks that are transferred in multiples request/response transactions. The transmission of a block is consequent to the reception of the relative request. Each request must contain the <italic>block_1</italic>
option. In this case, the NUM field indicates the number of the block that the client is expecting to receive. The M field is equal to zero while the SZX field is used to indicate the desired size of the block. The size of the blocks, in fact, can be negotiated between the client and server. In the proposed model, we consider a block size that allows filling an entire IEEE 802.15.4 frame. This size corresponds to that of a single 6LoWPAN fragment. A greater size implies the use of 6LoWPAN fragmentation to send a single block, which would not allow analysing the behavior of CoAP blockwise transfer. On the other hand, a smaller block size does not allow comparing equally 6LoWPAN fragmentation and CoAP blockwise transfer. Please note that 6LoWPAN fragmentation could be considered as a generalization of blockwise transfer with a block size equal to the size of the un-fragmented packet.</p>
<p>Blockwise transfer can be used in combination with the observe option. In this case, the first block of an observe update is sent without the initial request of the client. Then, the server sends the subsequent block after the client acknowledges the previous one. Both the initial observe registration request and the relative response can contain the block option. The client, in fact, can request the use of blockwise transfer including the block option in the observe request. The server could acknowledge an observe request including the block option to indicate that it could send updates using the blockwise transfer.</p>
<p><xref rid="f4-sensors-14-15610" ref-type="fig">Figure 4</xref>
shows the use of the blockwise transfer in an observe transaction composed by three updates. The transmission of the CoAP ACK relative to the second block of the second update fails as well as the MAC retransmission. Therefore, the server retransmits the CoAP ACK after the expiration of the RTO. In the transmission of the third update, the second block transmission and the relative MAC retransmissions fail. As a consequence, the block is retransmitted after the expiration of the RTO.</p>
</sec>
<sec><label>2.3.</label>
<title>Overview of the Unslotted CSMA/CA</title>
<p>The unslotted CSMA/CA mechanism is located at MAC layer. Its process is regulated by three variables, which are the number of backoff <italic>NB</italic>
, the backoff exponent <italic>BE</italic>
, and the retransmissions counter <italic>RT</italic>
. When a node wishes to transmit a packet, <italic>BE</italic>
is settled to its minimum value (<italic>macMinBE)</italic>
while <italic>NB</italic>
and <italic>RT</italic>
are initialized to zero. The channel access is divided in two steps: a backoff period and the Clear Channel Assessment (CCA). In the backoff period, the MAC layer delays for a random number of <italic>aUnitBackoffPeriod</italic>
units in the range [0, <italic>W<sub>k</sub>
</italic>
] = [0, 2<italic><sup>BE</sup>
</italic>
− 1] where <italic>W<sub>k</sub>
</italic>
is the boundary of the backoff window and <italic>k</italic>
the index representing the backoff stage. At the end of this period, the node performs the CCA. This is used to sense if the channel is busy or idle. During CCA, the node is in listening mode. It takes <italic>aTurnaroundTime</italic>
units to switch to transmitting mode. Should the CCA fails, the values of NB and BE are incremented by one and up to a maximum value of <italic>macMaxCSMABackoffs</italic>
and <italic>macMaxBE</italic>
respectively. Should <italic>BE</italic>
reach <italic>macMaxBE</italic>
, it remains at this value until it is resettled. If <italic>NB</italic>
exceeds <italic>macMaxCSMABackoffs,</italic>
the transmission is aborted and packet is discarded due to channel access failure. In the other cases, the CSMA/CA algorithm generates a random number of backoff periods and repeats the process. If the channel is sensed to be clear, the node starts the transmission of the packet. After it is completed, the node waits for the MAC ACK. The reception of the MAC ACK is interpreted as a successful transmission. Should the node not receive the MAC ACK due to collision or MAC ACK timeout, the variable <italic>RT</italic>
is increased by one up to <italic>macMaxFrameRetries</italic>
. If <italic>RT</italic>
is less than this values, the MAC layer initializes <italic>BE</italic>
to its default value of macMinBE and repeats the CSMA/CA mechanism. The packet is discarded due to the retry limit when <italic>RT</italic>
reaches its maximum value. In the rest of the paper, we denote by <italic>m<sub>0</sub>
</italic>
= <italic>macMinBE</italic>
, <italic>m<sub>B</sub>
</italic>
= <italic>macMaxBE</italic>
, <italic>m</italic>
= <italic>macMaxCSMABackoffs</italic>
and <italic>n</italic>
= <italic>macMaxFrameRetries</italic>
. A list of the main symbols used in this paper is reported in <xref rid="t1-sensors-14-15610" ref-type="table">Table 1</xref>
.</p>
</sec>
</sec>
<sec><label>3.</label>
<title>Traffic Generation Model and CSMA/CA Model</title>
<p>In this section we present the adaptation of the analytical model presented in [<xref rid="b14-sensors-14-15610" ref-type="bibr">14</xref>
]. The IEEE 802.15.4 standard defines the use of unslotted CSMA/CA in non beacon-enabled networks and slotted CSMA/CA in beacon-enabled networks. In this paper, we focus on non beacon-enabled networks using unslotted CSMA/CA. This MAC modality is of major interest in the standardization of IETF protocols [<xref rid="b6-sensors-14-15610" ref-type="bibr">6</xref>
]. We evaluate the protocol equations for a star topology, since this is the reference scenario recommended for CoAP application such as building automation and smart energy. A contention-based multiple access star topology allows for data collection from sensors to a gateway (network coordinator), that is reached with one-hop communication. Data communication through a multi-hop topology is envisioned in CoAP, but this is typically handled by using scheduled-based multiple access protocols. The extension of the model to this general scenario is interesting but not trivial and it is left as a future work. In particular, the performance of both 6LoWPAN fragmentation and CoAP blockwise transfer depend on the forwarding technique through relay nodes [<xref rid="b18-sensors-14-15610" ref-type="bibr">18</xref>
].</p>
<sec><label>3.1.</label>
<title>Traffic Generation Model</title>
<p>A major contribution of our model, with respect to [<xref rid="b14-sensors-14-15610" ref-type="bibr">14</xref>
] and the related literature, is the analysis of the performance of the MAC layer under bursty traffic conditions introduced along with 6LoWPAN fragmentation and CoAP blockwise transfer, as we detail as follows.</p>
<p>We assume that the CoAP layer generates observe updates with a Poisson distribution with rate λ. This is typical assumption in the related literature (e.g., [<xref rid="b14-sensors-14-15610" ref-type="bibr">14</xref>
–<xref rid="b17-sensors-14-15610" ref-type="bibr">17</xref>
]) to model traffic generation in WSN scenarios. As mentioned, each update is divided into <italic>F</italic>
fragments or <italic>B</italic>
blocks. Each fragment or block is included into a MAC frame of length <italic>L</italic>
while the CoAP ACK has length <italic>L<sub>ACK</sub>
</italic>
. Both frames are transmitted using the unslotted CSMA/CA mechanism of the IEEE 802.15.4 standard. Moreover, we consider low traffic generation, <italic>i.e.</italic>
, the traffic generation period for each node is long compared to the time it takes to forward an update, λ<sub>1</sub>
≪ 1/(L × F), which is consistent with the minimum RTO of 1 s recommended by CoAP [<xref rid="b7-sensors-14-15610" ref-type="bibr">7</xref>
]. With higher rates the retransmission mechanism of CoAP could not be used. The RTO, therefore, represents a lower bound to the traffic generation period.</p>
<p>At MAC layer, the traffic arrival is characterized by a Poisson distribution of parameter λ<italic><sub>l</sub>
</italic>
for the first fragment and by bursty traffic for the following <italic>F-1</italic>
fragments or <italic>B-1</italic>
blocks. The probability of generating the first fragment or block of an update at node <italic>l</italic>
in a unit time <italic>S<sub>b</sub>
</italic>
is derived as:
<disp-formula id="FD1"><label>(1)</label>
<mml:math id="mm1"><mml:mrow><mml:msub><mml:mi>q</mml:mi>
<mml:mi>l</mml:mi>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>−</mml:mo>
<mml:msup><mml:mi>e</mml:mi>
<mml:mrow><mml:mo stretchy="false">(</mml:mo>
<mml:msub><mml:mi>λ</mml:mi>
<mml:mi>l</mml:mi>
</mml:msub>
<mml:mo>/</mml:mo>
<mml:msub><mml:mi>S</mml:mi>
<mml:mi>b</mml:mi>
</mml:msub>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
</mml:msup>
</mml:mrow>
</mml:math>
</disp-formula>
</p>
<p>In the rest of the paper we consider <italic>S<sub>b</sub>
</italic>
= <italic>aUnitBackoffPeriod</italic>
as the basic unit time as in [<xref rid="b14-sensors-14-15610" ref-type="bibr">14</xref>
]. We recall that it corresponds to the transmission time of 20 symbols [<xref rid="b2-sensors-14-15610" ref-type="bibr">2</xref>
].</p>
<p>The probability of generating a new fragment or block after the previous one has been acknowledged or discarded is 1, until the last fragment or block has been acknowledged.</p>
</sec>
<sec><label>3.2.</label>
<title>Analytical Model of the CSMA/CA Mechanism</title>
<p>In this section, we develop a generalized model of the IEEE 802.15.4 MAC considering the presence of 6LoWPAN fragmentation and CoAP blockwise transfer. The analysis aims at deriving the reliability as the probability of successful frame reception and the delay for successfully received frames. Both are relative to the MAC layer and will be included in performance indicator expressions for the CoAP layer, which are presented in the next section.</p>
<p>The analysis is based on the Markov chain model presented in [<xref rid="b14-sensors-14-15610" ref-type="bibr">14</xref>
] that accounts for the presence of heterogeneous traffic with different node packet generation rates and hidden terminals.</p>
<p>We first determine the CCA probability <italic>τ<sub>l</sub>
</italic>
, namely the probability that node <italic>l</italic>
performs the carrier sensing procedure in a randomly chosen time unit. For each generated fragment, the CCA probability accounts for the number of times the CCA procedure is repeated due to busy channel and retransmissions, <italic>i.e.</italic>
,
<disp-formula id="FD2"><label>(2)</label>
<mml:math id="mm2"><mml:mrow><mml:msub><mml:mi>τ</mml:mi>
<mml:mi>l</mml:mi>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:munderover><mml:mo>∑</mml:mo>
<mml:mrow><mml:mi>i</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>0</mml:mn>
</mml:mrow>
<mml:mi>m</mml:mi>
</mml:munderover>
<mml:mrow><mml:munderover><mml:mo>∏</mml:mo>
<mml:mrow><mml:mi>j</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>0</mml:mn>
</mml:mrow>
<mml:mi>i</mml:mi>
</mml:munderover>
<mml:mrow><mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:msub><mml:mi>α</mml:mi>
<mml:mrow><mml:mi>l</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>j</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:mrow>
<mml:msup><mml:mrow><mml:munderover><mml:mo>∑</mml:mo>
<mml:mrow><mml:mi>k</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>0</mml:mn>
</mml:mrow>
<mml:mi>n</mml:mi>
</mml:munderover>
<mml:mrow><mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mn>1</mml:mn>
<mml:mo>−</mml:mo>
<mml:munderover><mml:mo>∑</mml:mo>
<mml:mrow><mml:mi>j</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>0</mml:mn>
</mml:mrow>
<mml:mi>m</mml:mi>
</mml:munderover>
<mml:mrow><mml:msub><mml:mi>α</mml:mi>
<mml:mrow><mml:mi>l</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>j</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">coll</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:mrow>
<mml:mi>k</mml:mi>
</mml:msup>
<mml:msubsup><mml:mi>b</mml:mi>
<mml:mrow><mml:mn>0</mml:mn>
<mml:mo>,</mml:mo>
<mml:mn>0</mml:mn>
<mml:mo>,</mml:mo>
<mml:mn>0</mml:mn>
</mml:mrow>
<mml:mrow><mml:mrow><mml:mo>(</mml:mo>
<mml:mi>l</mml:mi>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:msubsup>
</mml:mrow>
</mml:math>
</disp-formula>
where α<italic><sub>l,j</sub>
</italic>
is the busy channel probability of node <italic>l</italic>
during the <italic>j-th</italic>
backoff stage,
<inline-formula><mml:math id="mm31"><mml:mrow><mml:msubsup><mml:mtext>b</mml:mtext>
<mml:mrow><mml:mn>0</mml:mn>
<mml:mo>,</mml:mo>
<mml:mn>0</mml:mn>
<mml:mo>,</mml:mo>
<mml:mn>0</mml:mn>
</mml:mrow>
<mml:mrow><mml:mo stretchy="false">(</mml:mo>
<mml:mtext>l</mml:mtext>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
</mml:msubsup>
</mml:mrow>
</mml:math>
</inline-formula>
is the MAC frame generation probability, and P<sub>coll,l</sub>
is the collision probability, which we derive next.</p>
<p>The first sum determines the expected number of accesses for each transmission, the second sum accounts for the expected number of re-transmissions for each packet.</p>
<p>For unsaturated traffic conditions, the frame generation probability at MAC layer is:
<disp-formula id="FD3"><label>(3)</label>
<mml:math id="mm3"><mml:mrow><mml:msup><mml:mrow><mml:msub><mml:mi>b</mml:mi>
<mml:mrow><mml:mn>0</mml:mn>
<mml:mo>,</mml:mo>
<mml:mn>0</mml:mn>
<mml:mo>,</mml:mo>
<mml:mn>0</mml:mn>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:mrow><mml:mrow><mml:mo>(</mml:mo>
<mml:mi>l</mml:mi>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:msup>
<mml:mo>=</mml:mo>
<mml:mspace width="0.2em"></mml:mspace>
<mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:msub><mml:mi>q</mml:mi>
<mml:mi>l</mml:mi>
</mml:msub>
<mml:mo>×</mml:mo>
<mml:mi>F</mml:mi>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</disp-formula>
</p>
<p>When traffic gets saturated, the MAC frame generation probability is calculated by the normalization condition of the corresponding Markov chain, as detailed in Proposition 4.1 in [<xref rid="b14-sensors-14-15610" ref-type="bibr">14</xref>
].</p>
<p>The busy channel probability due to packet transmission for the first fragment or block is the probability that no other node accessed the channel and found it idle in the previous <italic>L</italic>
time units. After the previous fragment or block has been acknowledged at MAC layer, the node generates a random backoff in the window [0 − <italic>W</italic>
<sub>0</sub>
] before sensing the carrier. The busy channel probability for the following fragment, block, or CoAP ACK is given by the probability that no other node accesses the channel during (<italic>W</italic>
<sub>0</sub>
+ 1)/2 time units. In average terms, the channel will be busy if no other nodes accessed and found it idle in the previous <italic>L<sub>eq</sub>
</italic>
time units:
<disp-formula id="FD4"><label>(4)</label>
<mml:math id="mm4"><mml:mrow><mml:msub><mml:mi>L</mml:mi>
<mml:mrow><mml:mi>e</mml:mi>
<mml:mi>q</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>L</mml:mi>
<mml:mo>+</mml:mo>
<mml:mi>F</mml:mi>
<mml:mo>×</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub><mml:mi>W</mml:mi>
<mml:mn>0</mml:mn>
</mml:msub>
<mml:mo>+</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>/</mml:mo>
<mml:mn>2</mml:mn>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>/</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>F</mml:mi>
<mml:mo>+</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo stretchy="false">)</mml:mo>
<mml:mspace width="0.2em"></mml:mspace>
<mml:mtext mathvariant="italic">for</mml:mtext>
<mml:mspace width="0.2em"></mml:mspace>
<mml:mn>6</mml:mn>
<mml:mtext mathvariant="italic">LoWPAN Fragmentation</mml:mtext>
</mml:mrow>
</mml:math>
</disp-formula>
<disp-formula id="FD5"><label>(5)</label>
<mml:math id="mm5"><mml:mrow><mml:msub><mml:mi>L</mml:mi>
<mml:mrow><mml:mi>e</mml:mi>
<mml:mi>q</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mi>L</mml:mi>
<mml:mo>+</mml:mo>
<mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mn>2</mml:mn>
<mml:mspace width="0.2em"></mml:mspace>
<mml:mi>B</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:mo>×</mml:mo>
<mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:msub><mml:mi>W</mml:mi>
<mml:mn>0</mml:mn>
</mml:msub>
<mml:mo>+</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:mo>/</mml:mo>
<mml:mn>2</mml:mn>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:mo>/</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:mn>2</mml:mn>
<mml:mspace width="0.2em"></mml:mspace>
<mml:mi>B</mml:mi>
<mml:mo stretchy="false">)</mml:mo>
<mml:mspace width="0.2em"></mml:mspace>
<mml:mtext mathvariant="italic">for Blockwise transfer</mml:mtext>
<mml:mspace width="0.2em"></mml:mspace>
</mml:mrow>
</mml:math>
</disp-formula>
</p>
<p>We recall that the MAC ACK is transmitted right after the reception of a MAC frame. Its transmission does not undergo the backoff procedure. Instead, this procedure applies for the CoAP ACK. For 6LoWPAN Fragmentation there are F packets and 1 potential CoAP ACK, while for CoAP blockwise transfer there are B blocks and B potential CoAP ACKs.</p>
<p>The busy channel probability at the first CCA can be evaluated as:
<disp-formula id="FD6"><label>(6)</label>
<mml:math id="mm6"><mml:mrow><mml:msub><mml:mi>α</mml:mi>
<mml:mrow><mml:mi>l</mml:mi>
<mml:mo>,</mml:mo>
<mml:mn>0</mml:mn>
</mml:mrow>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:mspace width="0.2em"></mml:mspace>
<mml:msub><mml:mi>L</mml:mi>
<mml:mrow><mml:mi>e</mml:mi>
<mml:mi>q</mml:mi>
</mml:mrow>
</mml:msub>
<mml:munderover><mml:mo>∑</mml:mo>
<mml:mrow><mml:mi>i</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mrow><mml:mi>N</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:munderover>
<mml:munderover><mml:mo>∑</mml:mo>
<mml:mrow><mml:mi>q</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mrow><mml:msub><mml:mi>C</mml:mi>
<mml:mrow><mml:mi>l</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>i</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:munderover>
<mml:msubsup><mml:mo>∏</mml:mo>
<mml:mrow><mml:mi>k</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mi>i</mml:mi>
</mml:msubsup>
<mml:mrow><mml:msub><mml:mi>τ</mml:mi>
<mml:mrow><mml:msub><mml:mi>k</mml:mi>
<mml:mi>q</mml:mi>
</mml:msub>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:msubsup><mml:mo>∏</mml:mo>
<mml:mrow><mml:mi>h</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>+</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mrow><mml:mi>N</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:msubsup>
<mml:mrow><mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mn>1</mml:mn>
<mml:mo>−</mml:mo>
<mml:msub><mml:mi>τ</mml:mi>
<mml:mrow><mml:msub><mml:mi>h</mml:mi>
<mml:mi>q</mml:mi>
</mml:msub>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
<mml:mspace width="0.2em"></mml:mspace>
<mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mn>1</mml:mn>
<mml:mo>−</mml:mo>
<mml:msubsup><mml:mo>∏</mml:mo>
<mml:mrow><mml:mi>k</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mi>i</mml:mi>
</mml:msubsup>
<mml:mrow><mml:msub><mml:mover accent="true"><mml:mi>α</mml:mi>
<mml:mo>¯</mml:mo>
</mml:mover>
<mml:mrow><mml:msub><mml:mi>k</mml:mi>
<mml:mi>q</mml:mi>
</mml:msub>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:mspace width="0.2em"></mml:mspace>
</mml:mrow>
</mml:math>
</disp-formula>
</p>
<p>The double sum in <italic>i</italic>
and <italic>q</italic>
enumerates the combinations of events in which <italic>i</italic>
nodes access the channel in a given time unit (excluding the transmitting node l). The term
<inline-formula><mml:math id="mm32"><mml:mrow><mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mn>1</mml:mn>
<mml:mo>−</mml:mo>
<mml:msubsup><mml:mo>∏</mml:mo>
<mml:mrow><mml:mtext>k</mml:mtext>
<mml:mo>=</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mtext>i</mml:mtext>
</mml:msubsup>
<mml:mrow><mml:msub><mml:mover accent="true"><mml:mi>α</mml:mi>
<mml:mo>¯</mml:mo>
</mml:mover>
<mml:mrow><mml:msub><mml:mtext>k</mml:mtext>
<mml:mtext>q</mml:mtext>
</mml:msub>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula>
considers the events of successful CCAs.</p>
<p>Given <italic>N</italic>
nodes in the network, the subscript <italic>k<sub>q</sub>
</italic>
refers to the node in the <italic>k</italic>
-th position in the <italic>q</italic>
-th combination of <italic>i</italic>
out of <italic>N-1</italic>
elements.</p>
<p>Should the channel be busy during the first backoff, there is a higher probability that the channel will be still busy after the backoff in the window [0 − <italic>W</italic>
<sub>1</sub>
]. This behavior is due to the bursty traffic generation. Under this condition, the channel will be busy at the second CCA with a probability:
<disp-formula id="FD7"><label>(7)</label>
<mml:math id="mm7"><mml:mrow><mml:msub><mml:mi>α</mml:mi>
<mml:mrow><mml:mi>l</mml:mi>
<mml:mo>,</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>−</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub><mml:mi>W</mml:mi>
<mml:mn>1</mml:mn>
</mml:msub>
<mml:mo>+</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>/</mml:mo>
<mml:mn>2</mml:mn>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>/</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:mover accent="true"><mml:mi>L</mml:mi>
<mml:mo>¯</mml:mo>
</mml:mover>
<mml:mo>+</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub><mml:mi>W</mml:mi>
<mml:mn>1</mml:mn>
</mml:msub>
<mml:mo>+</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>/</mml:mo>
<mml:mn>2</mml:mn>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
</mml:math>
</disp-formula>
where:
<disp-formula id="FD8"><label>(8)</label>
<mml:math id="mm8"><mml:mrow><mml:mtable><mml:mtr><mml:mtd><mml:mrow><mml:mover accent="true"><mml:mi>L</mml:mi>
<mml:mo>¯</mml:mo>
</mml:mover>
<mml:mo>=</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>F</mml:mi>
<mml:mo>×</mml:mo>
<mml:mi>L</mml:mi>
<mml:mo>+</mml:mo>
<mml:msub><mml:mi>L</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">ACK</mml:mtext>
</mml:mrow>
</mml:msub>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>/</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>F</mml:mi>
<mml:mo>+</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo stretchy="false">)</mml:mo>
<mml:mspace width="0.2em"></mml:mspace>
<mml:mtext mathvariant="italic">for</mml:mtext>
<mml:mspace width="0.2em"></mml:mspace>
<mml:mn>6</mml:mn>
<mml:mtext mathvariant="italic">LoWPAN fragmentation</mml:mtext>
</mml:mrow>
</mml:mtd>
</mml:mtr>
<mml:mtr><mml:mtd><mml:mrow><mml:mover accent="true"><mml:mi>L</mml:mi>
<mml:mo>¯</mml:mo>
</mml:mover>
<mml:mo>=</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>L</mml:mi>
<mml:mo>+</mml:mo>
<mml:msub><mml:mi>L</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">ACK</mml:mtext>
</mml:mrow>
</mml:msub>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>/</mml:mo>
<mml:mn>2</mml:mn>
<mml:mspace width="0.2em"></mml:mspace>
<mml:mtext mathvariant="italic">for blockwise transfer</mml:mtext>
</mml:mrow>
</mml:mtd>
</mml:mtr>
</mml:mtable>
</mml:mrow>
</mml:math>
</disp-formula>
</p>
<p>This condition holds for all the backoff attempts in which the backoff window is lower than the size of the burst. Therefore, <xref rid="FD7" ref-type="disp-formula">Equation (7)</xref>
can be generalized for a generic backoff stage <italic>j</italic>
such that for <italic>W<sub>j</sub>
</italic>
< <italic>L</italic>
× <italic>F</italic>
or <italic>W<sub>j</sub>
</italic>
< <italic>L</italic>
× <italic>B</italic>
.</p>
<p>For <italic>W<sub>j</sub>
</italic>
> <italic>L</italic>
× <italic>F</italic>
or <italic>W<sub>j</sub>
</italic>
> <italic>L</italic>
× <italic>B</italic>
the busy channel probability α<italic><sub>l,j</sub>
</italic>
can be calculated in asynchronous fashion, as in the original model in [<xref rid="b14-sensors-14-15610" ref-type="bibr">14</xref>
].</p>
<p>In conclusion, the busy channel probability is written as for <italic>j</italic>
> 0
<disp-formula id="FD9"><label>(9)</label>
<mml:math id="mm9"><mml:mrow><mml:mo>=</mml:mo>
<mml:mmultiscripts><mml:mrow><mml:mrow><mml:mo>{</mml:mo>
<mml:mrow><mml:mtable><mml:mtr><mml:mtd><mml:mrow><mml:msub><mml:mi>L</mml:mi>
<mml:mrow><mml:mi>e</mml:mi>
<mml:mi>q</mml:mi>
</mml:mrow>
</mml:msub>
<mml:munderover><mml:mo>∑</mml:mo>
<mml:mrow><mml:mi>i</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mrow><mml:mi>N</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:munderover>
<mml:munderover><mml:mo>∑</mml:mo>
<mml:mrow><mml:mi>q</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mrow><mml:msub><mml:mi>C</mml:mi>
<mml:mrow><mml:mi>l</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>i</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:munderover>
<mml:msubsup><mml:mo>∏</mml:mo>
<mml:mrow><mml:mi>k</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mi>i</mml:mi>
</mml:msubsup>
<mml:mrow><mml:msub><mml:mi>τ</mml:mi>
<mml:mrow><mml:msub><mml:mi>k</mml:mi>
<mml:mi>q</mml:mi>
</mml:msub>
</mml:mrow>
</mml:msub>
<mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mn>1</mml:mn>
<mml:mo>−</mml:mo>
<mml:msubsup><mml:mo>∏</mml:mo>
<mml:mrow><mml:mi>k</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mi>i</mml:mi>
</mml:msubsup>
<mml:mrow><mml:msub><mml:mover accent="true"><mml:mi>α</mml:mi>
<mml:mo>¯</mml:mo>
</mml:mover>
<mml:mrow><mml:msub><mml:mi>k</mml:mi>
<mml:mi>q</mml:mi>
</mml:msub>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
<mml:msubsup><mml:mo>∏</mml:mo>
<mml:mrow><mml:mi>h</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>+</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mrow><mml:mi>N</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:msubsup>
<mml:mrow><mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mn>1</mml:mn>
<mml:mo>−</mml:mo>
<mml:msub><mml:mi>τ</mml:mi>
<mml:mrow><mml:msub><mml:mi>h</mml:mi>
<mml:mi>q</mml:mi>
</mml:msub>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:mspace width="0.2em"></mml:mspace>
<mml:mtext mathvariant="italic">for</mml:mtext>
<mml:mspace width="0.2em"></mml:mspace>
<mml:msub><mml:mi>W</mml:mi>
<mml:mi>j</mml:mi>
</mml:msub>
<mml:mo>></mml:mo>
<mml:mi>F</mml:mi>
<mml:mi>λ</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>B</mml:mi>
<mml:mi>λ</mml:mi>
</mml:mrow>
<mml:mspace width="0.2em"></mml:mspace>
</mml:mrow>
</mml:mtd>
</mml:mtr>
<mml:mtr><mml:mtd><mml:mrow><mml:mn>1</mml:mn>
<mml:mo>−</mml:mo>
<mml:mfrac><mml:mrow><mml:mo stretchy="false">(</mml:mo>
<mml:msub><mml:mi>W</mml:mi>
<mml:mi>j</mml:mi>
</mml:msub>
<mml:mo>+</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
<mml:mn>2</mml:mn>
</mml:mfrac>
<mml:msup><mml:mrow><mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mover accent="true"><mml:mi>L</mml:mi>
<mml:mo>¯</mml:mo>
</mml:mover>
<mml:mo>+</mml:mo>
<mml:mfrac><mml:mrow><mml:mo stretchy="false">(</mml:mo>
<mml:msub><mml:mi>W</mml:mi>
<mml:mi>j</mml:mi>
</mml:msub>
<mml:mo>+</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
<mml:mn>2</mml:mn>
</mml:mfrac>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
<mml:mrow><mml:mo>−</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:msup>
<mml:mspace width="0.2em"></mml:mspace>
<mml:mtext mathvariant="italic">otherwise</mml:mtext>
</mml:mrow>
</mml:mtd>
</mml:mtr>
</mml:mtable>
</mml:mrow>
</mml:mrow>
</mml:mrow>
<mml:mprescripts></mml:mprescripts>
<mml:none></mml:none>
<mml:mrow><mml:msub><mml:mi>α</mml:mi>
<mml:mrow><mml:mi>l</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>j</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:mmultiscripts>
</mml:mrow>
</mml:math>
</disp-formula>
where
<inline-formula><mml:math id="mm33"><mml:mrow><mml:msub><mml:mi>C</mml:mi>
<mml:mrow><mml:mi>l</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>i</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mtable><mml:mtr><mml:mtd><mml:mi>l</mml:mi>
</mml:mtd>
</mml:mtr>
<mml:mtr><mml:mtd><mml:mi>i</mml:mi>
</mml:mtd>
</mml:mtr>
</mml:mtable>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula>
and
<inline-formula><mml:math id="mm34"><mml:mrow><mml:msub><mml:mover accent="true"><mml:mi>α</mml:mi>
<mml:mo>¯</mml:mo>
</mml:mover>
<mml:mi>l</mml:mi>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:mfrac><mml:mrow><mml:msubsup><mml:mo>∑</mml:mo>
<mml:mrow><mml:mi>j</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>0</mml:mn>
</mml:mrow>
<mml:mi>m</mml:mi>
</mml:msubsup>
<mml:mrow><mml:msub><mml:mi>α</mml:mi>
<mml:mrow><mml:mi>l</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>j</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:mrow>
<mml:mrow><mml:mi>m</mml:mi>
<mml:mo>+</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:mfrac>
</mml:mrow>
</mml:math>
</inline-formula>
is the average busy channel probability for all backoff stages.</p>
<p>Notice that this expression is an approximation for the busy channel probability when W<sub>j</sub>
≈ L×F or W<sub>j</sub>
≈ L×B.</p>
<p>The collision probability is the probability that a contending node performs the CCA in the same time unit, <italic>i.e.</italic>
:
<disp-formula id="FD10"><label>(10)</label>
<mml:math id="mm10"><mml:mrow><mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">coll</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:msub><mml:mover accent="true"><mml:mi>α</mml:mi>
<mml:mo>¯</mml:mo>
</mml:mover>
<mml:mi>l</mml:mi>
</mml:msub>
<mml:mo>/</mml:mo>
<mml:msub><mml:mi>L</mml:mi>
<mml:mrow><mml:mi>e</mml:mi>
<mml:mi>q</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</disp-formula>
</p>
<p>The expressions of the CCA probability, the busy channel probability and the collision probability form a system of non-linear equations that can be solved through numerical methods as specified in [<xref rid="b14-sensors-14-15610" ref-type="bibr">14</xref>
].</p>
<p>The IEEE 802.15.4 protocol does not distinguish between higher layer packets. Therefore, the probability that the transmission of a block, fragment or CoAP ACK fails has the same expression for each of them. We refer to it as P<sub>frame,l</sub>
:
<disp-formula id="FD11"><label>(11)</label>
<mml:math id="mm11"><mml:mrow><mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">frame</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:mi>c</mml:mi>
<mml:mi>f</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>+</mml:mo>
<mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:mi>c</mml:mi>
<mml:mi>r</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</disp-formula>
where P<sub>cf,l</sub>
corresponds to the probability for node <italic>l</italic>
that the frame is discarded due to channel access failure and P<sub>cr,l</sub>
to the probability for node <italic>l</italic>
of a packet to be discarded due to retry limit. Therefore we have
<disp-formula id="FD12"><label>(12)</label>
<mml:math id="mm12"><mml:mrow><mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:mi>c</mml:mi>
<mml:mi>f</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:msubsup><mml:mo>∏</mml:mo>
<mml:mrow><mml:mi>j</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>0</mml:mn>
</mml:mrow>
<mml:mi>m</mml:mi>
</mml:msubsup>
<mml:mrow><mml:msub><mml:mi>α</mml:mi>
<mml:mrow><mml:mi>l</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>j</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:munderover><mml:mo>∑</mml:mo>
<mml:mrow><mml:mi>k</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>0</mml:mn>
</mml:mrow>
<mml:mi>n</mml:mi>
</mml:munderover>
<mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">coll</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mn>1</mml:mn>
<mml:mo>−</mml:mo>
<mml:msubsup><mml:mo>∏</mml:mo>
<mml:mrow><mml:mi>j</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>0</mml:mn>
</mml:mrow>
<mml:mi>m</mml:mi>
</mml:msubsup>
<mml:mrow><mml:msub><mml:mi>α</mml:mi>
<mml:mrow><mml:mi>l</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>j</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</disp-formula>
</p>
<p>Once the CCA probability, the busy channel probability, and the collision probability are derived, the delay for successfully received frames D<italic><sub>frame,l</sub>
</italic>
and CoAP ACKs D<italic><sub>ACK,l</sub>
</italic>
are obtained as follows.
<disp-formula id="FD13"><label>(13)</label>
<mml:math id="mm13"><mml:mrow><mml:msub><mml:mrow><mml:mrow><mml:mspace width="0.2em"></mml:mspace>
<mml:mtext>D</mml:mtext>
</mml:mrow>
</mml:mrow>
<mml:mrow><mml:mtext mathvariant="italic">frame</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:mfrac><mml:mrow><mml:msubsup><mml:mo>∑</mml:mo>
<mml:mi>n</mml:mi>
<mml:mrow><mml:mi>h</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>0</mml:mn>
</mml:mrow>
</mml:msubsup>
<mml:msubsup><mml:mi>P</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">coll</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
<mml:mi>h</mml:mi>
</mml:msubsup>
<mml:msup><mml:mrow><mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mn>1</mml:mn>
<mml:mo>−</mml:mo>
<mml:msubsup><mml:mo>∏</mml:mo>
<mml:mi>m</mml:mi>
<mml:mrow><mml:mi>j</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>0</mml:mn>
</mml:mrow>
</mml:msubsup>
<mml:msub><mml:mi>α</mml:mi>
<mml:mrow><mml:mi>l</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>j</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
<mml:mi>h</mml:mi>
</mml:msup>
<mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:msubsup><mml:mo>∑</mml:mo>
<mml:mi>h</mml:mi>
<mml:mrow><mml:mi>x</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>0</mml:mn>
</mml:mrow>
</mml:msubsup>
<mml:mi>E</mml:mi>
<mml:mrow><mml:mo>⌈</mml:mo>
<mml:mrow><mml:msub><mml:mi>T</mml:mi>
<mml:mi>x</mml:mi>
</mml:msub>
</mml:mrow>
<mml:mo>⌉</mml:mo>
</mml:mrow>
<mml:mo>+</mml:mo>
<mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mi>h</mml:mi>
<mml:mo>+</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:msub><mml:mi>T</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">frame</mml:mtext>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
<mml:mrow><mml:msubsup><mml:mo>∑</mml:mo>
<mml:mrow><mml:mi>k</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>0</mml:mn>
</mml:mrow>
<mml:mrow><mml:mi>n</mml:mi>
<mml:mi>r</mml:mi>
</mml:mrow>
</mml:msubsup>
<mml:mrow><mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">coll</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mn>1</mml:mn>
<mml:mo>−</mml:mo>
<mml:msubsup><mml:mo>∏</mml:mo>
<mml:mi>m</mml:mi>
<mml:mrow><mml:mi>j</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>0</mml:mn>
</mml:mrow>
</mml:msubsup>
<mml:msub><mml:mi>α</mml:mi>
<mml:mrow><mml:mi>l</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>j</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
<mml:mi>k</mml:mi>
</mml:mrow>
</mml:mfrac>
</mml:mrow>
</mml:math>
</disp-formula>
where <italic>T<sub>x</sub>
</italic>
is the backoff stage delay, whereas <italic>T<sub>frame</sub>
</italic>
is the time periods in number of time units for MAC frame and MAC ACK transmission.</p>
<p>The denominator of <xref rid="FD13" ref-type="disp-formula">Equation (13)</xref>
is a normalization factor with respect to the probability of successful reception. Since the backoff time in each stage k is uniformly distributed in [0, W<sub>k</sub>
− 1], the expected total backoff delay is:
<disp-formula id="FD14"><label>(14)</label>
<mml:math id="mm14"><mml:mrow><mml:mi>E</mml:mi>
<mml:mrow><mml:mo>⌈</mml:mo>
<mml:mrow><mml:msub><mml:mi>T</mml:mi>
<mml:mi>l</mml:mi>
</mml:msub>
</mml:mrow>
<mml:mo>⌉</mml:mo>
</mml:mrow>
<mml:mo>=</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>+</mml:mo>
<mml:mfrac><mml:mrow><mml:msubsup><mml:mo>∑</mml:mo>
<mml:mrow><mml:mi>r</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>0</mml:mn>
</mml:mrow>
<mml:mi>m</mml:mi>
</mml:msubsup>
<mml:msubsup><mml:mover accent="true"><mml:mi>α</mml:mi>
<mml:mo>¯</mml:mo>
</mml:mover>
<mml:mrow><mml:msub><mml:mi>l</mml:mi>
<mml:mi>l</mml:mi>
</mml:msub>
</mml:mrow>
<mml:mi>r</mml:mi>
</mml:msubsup>
<mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mn>1</mml:mn>
<mml:mo>−</mml:mo>
<mml:msub><mml:mover accent="true"><mml:mi>α</mml:mi>
<mml:mo>¯</mml:mo>
</mml:mover>
<mml:mi>l</mml:mi>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mi>r</mml:mi>
<mml:mo>+</mml:mo>
<mml:msubsup><mml:mo>∑</mml:mo>
<mml:mrow><mml:mi>k</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>0</mml:mn>
</mml:mrow>
<mml:mi>r</mml:mi>
</mml:msubsup>
<mml:mfrac><mml:mrow><mml:msub><mml:mi>W</mml:mi>
<mml:mi>k</mml:mi>
</mml:msub>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mn>2</mml:mn>
</mml:mfrac>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
<mml:mrow><mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mn>1</mml:mn>
<mml:mo>−</mml:mo>
<mml:msubsup><mml:mo>∏</mml:mo>
<mml:mrow><mml:mi>j</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>0</mml:mn>
</mml:mrow>
<mml:mi>m</mml:mi>
</mml:msubsup>
<mml:msub><mml:mi>α</mml:mi>
<mml:mrow><mml:mi>l</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>j</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:mfrac>
</mml:mrow>
</mml:math>
</disp-formula>
</p>
<p>The expression of D<sub>ACK,l</sub>
is obtained by replacing T<sub>frame</sub>
with TACK, being the time periods in number of time units for CoAP ACK and MAC ACK transmission. The denominator of <xref rid="FD14" ref-type="disp-formula">Equation (14)</xref>
is a normalization factor with respect to the probability of idle channel within the maximum number of backoff.</p>
</sec>
</sec>
<sec><label>4.</label>
<title>Analytical Model</title>
<p>In this section we present the analytical model of CoAP data transactions that use 6LoWPAN fragmentation and CoAP blockwise transfer. We also derive the expression of the transition probabilities that characterize the model. The reference WSN topology is a star network. In this scenario, a client is in direct communication (single-hop) with the servers that are in the network. The analytical model is present only in the Client and Server nodes. As explained next, we model these nodes with two separate Markov chains.</p>
<p>The analytical model of the client is shown in <xref rid="f5-sensors-14-15610" ref-type="fig">Figure 5</xref>
. It is composed by two states, which are the same for the CoAP blockwise transfer and 6LoWPAN fragmentation. The only difference is the transition probabilities between the states.</p>
<p>The first state is the IDLE, which means that the client is waiting for the reception of a block or for the F fragments of an update. The client visits the acknowledgment transmission state (CoAP ACK_TX) after it receives successfully a block or all the F fragments. In both cases it sends the relative CoAP ACK.</p>
<p>The transition probabilities of each chain are equivalent to the probability of receiving correctly a block or all the fragments of an update.</p>
<p>The probability P<sub>block,l</sub>
that a single block fails at node <italic>l</italic>
is therefore equal to:
<disp-formula id="FD15"><label>(15)</label>
<mml:math id="mm15"><mml:mrow><mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">block</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">frame</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</disp-formula>
where <italic>P<sub>frame,l</sub>
</italic>
is derived in <xref rid="FD11" ref-type="disp-formula">Equation (11)</xref>
.</p>
<p>Instead, the probability P<sub>frag,l</sub>
that the transmission of a fragmented update fails is equal to:
<disp-formula id="FD16"><label>(16)</label>
<mml:math id="mm16"><mml:mrow><mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">frag</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>−</mml:mo>
<mml:msup><mml:mrow><mml:mo stretchy="false">(</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>−</mml:mo>
<mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">frame</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
<mml:mi>F</mml:mi>
</mml:msup>
</mml:mrow>
</mml:math>
</disp-formula>
</p>
<p><xref rid="f6-sensors-14-15610" ref-type="fig">Figure 6</xref>
shows the server's Markov chains for CoAP blockwise transfer and 6LoWPAN fragmentation. <xref rid="f6-sensors-14-15610" ref-type="fig">Figure 6b</xref>
considers the transmission of an observe update composed by two blocks. Both chains have four retransmission states, which correspond to the maximum number of retransmissions defined by CoAP. The blockwise transfer model has a transmission and a retransmission stage for each block that composes the update. The CoAP layer, in fact, controls the transmission of each block and sends the subsequent only after the previous one has been acknowledged by the client. The CoAP layer, instead, has a single transmission and retransmission stage when the update is transmitted with 6LoWPAN fragmentation.</p>
<p>The server is in the IDLE state when it is waiting for the generation of the next update. The transition probability from the IDLE to the transmission state of the fragmented update (TX) or the first block (BLOCK_1 TX) is the probability <italic>q<sub>l</sub>
</italic>
that we derived in <xref rid="FD1" ref-type="disp-formula">Equation (1)</xref>
. The server goes back to IDLE state after it receives the CoAP ACK relative to the last block or fragmented update. The failure of the update transmission also causes the server to go back to the IDLE state.</p>
<p>The retransmission states are visited after the failure of the transmission of a block, fragment or CoAP ACK. The transition probability between the transmission state and the first retransmission state of the blockwise and fragmentation models are expressed as
<inline-formula><mml:math id="mm35"><mml:mrow><mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:msub><mml:mtext mathvariant="italic">err</mml:mtext>
<mml:mrow><mml:mtext mathvariant="italic">block</mml:mtext>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>
and
<inline-formula><mml:math id="mm36"><mml:mrow><mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:msub><mml:mtext mathvariant="italic">err</mml:mtext>
<mml:mrow><mml:mtext mathvariant="italic">frag</mml:mtext>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>
, respectively. These probabilities are also valid for the transition between the retransmission states.</p>
<p>The probabilities at node <italic>l</italic>
<inline-formula><mml:math id="mm37"><mml:mrow><mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:msub><mml:mtext mathvariant="italic">err</mml:mtext>
<mml:mrow><mml:mtext mathvariant="italic">block</mml:mtext>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>
and
<inline-formula><mml:math id="mm38"><mml:mrow><mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:msub><mml:mtext mathvariant="italic">err</mml:mtext>
<mml:mrow><mml:mtext mathvariant="italic">frag</mml:mtext>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>
that a block or a fragmented update is retransmitted are defined as follows:
<disp-formula id="FD17"><label>(17)</label>
<mml:math id="mm17"><mml:mrow><mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:msub><mml:mtext mathvariant="italic">err</mml:mtext>
<mml:mrow><mml:mtext mathvariant="italic">block</mml:mtext>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">block</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>+</mml:mo>
<mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:msub><mml:mtext mathvariant="italic">ack</mml:mtext>
<mml:mrow><mml:mtext mathvariant="italic">block</mml:mtext>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</disp-formula>
<disp-formula id="FD18"><label>(18)</label>
<mml:math id="mm18"><mml:mrow><mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:msub><mml:mtext mathvariant="italic">err</mml:mtext>
<mml:mrow><mml:mtext mathvariant="italic">frag</mml:mtext>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">frag</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>+</mml:mo>
<mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:msub><mml:mtext mathvariant="italic">ack</mml:mtext>
<mml:mrow><mml:mtext mathvariant="italic">frag</mml:mtext>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</disp-formula>
where
<inline-formula><mml:math id="mm39"><mml:mrow><mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:msub><mml:mtext mathvariant="italic">ack</mml:mtext>
<mml:mrow><mml:mtext mathvariant="italic">block</mml:mtext>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>
and
<inline-formula><mml:math id="mm40"><mml:mrow><mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:msub><mml:mtext mathvariant="italic">ack</mml:mtext>
<mml:mrow><mml:mtext mathvariant="italic">frag</mml:mtext>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>
are the probabilities at node <italic>l</italic>
that the transmission of the CoAP ACK relative to a block or to the fragmented update fails, respectively. These are equal to:
<disp-formula id="FD19"><label>(19)</label>
<mml:math id="mm19"><mml:mrow><mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:msub><mml:mtext mathvariant="italic">ack</mml:mtext>
<mml:mrow><mml:mtext mathvariant="italic">block</mml:mtext>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">frame</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>×</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>−</mml:mo>
<mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">block</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
</mml:math>
</disp-formula>
<disp-formula id="FD20"><label>(20)</label>
<mml:math id="mm20"><mml:mrow><mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:msub><mml:mtext mathvariant="italic">ack</mml:mtext>
<mml:mrow><mml:mtext mathvariant="italic">frag</mml:mtext>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">frame</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>×</mml:mo>
<mml:mspace width="0.2em"></mml:mspace>
<mml:mrow><mml:mo>(</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mo>−</mml:mo>
<mml:mrow><mml:mrow><mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">frag</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</disp-formula>
</p>
<p>The unsuccessful retransmission of a block or of the fragmented update for <italic>c</italic>
consecutive times causes the update transmission to fail and the server to visit the FAIL state.</p>
<p>The probabilities
<inline-formula><mml:math id="mm41"><mml:mrow><mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:msub><mml:mtext mathvariant="italic">fail</mml:mtext>
<mml:mrow><mml:mtext mathvariant="italic">block</mml:mtext>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>
and
<inline-formula><mml:math id="mm42"><mml:mrow><mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:msub><mml:mtext mathvariant="italic">fail</mml:mtext>
<mml:mrow><mml:mtext mathvariant="italic">frag</mml:mtext>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>
that an update transmission fails is equal to the probability that the transmission as well as the retransmissions of the update fail. These are equal to:
<disp-formula id="FD21"><label>(21)</label>
<mml:math id="mm21"><mml:mrow><mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:msub><mml:mtext mathvariant="italic">fail</mml:mtext>
<mml:mrow><mml:mtext mathvariant="italic">block</mml:mtext>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:munderover><mml:mo>∑</mml:mo>
<mml:mrow><mml:mi>i</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mi>B</mml:mi>
</mml:munderover>
<mml:mrow><mml:msup><mml:mrow><mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:msub><mml:mtext mathvariant="italic">err</mml:mtext>
<mml:mrow><mml:mtext mathvariant="italic">block</mml:mtext>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:mrow><mml:mi>c</mml:mi>
<mml:mo>+</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:msup>
</mml:mrow>
<mml:mo>×</mml:mo>
<mml:msup><mml:mrow><mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mn>1</mml:mn>
<mml:mo>−</mml:mo>
<mml:msup><mml:mrow><mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:msub><mml:mtext mathvariant="italic">err</mml:mtext>
<mml:mrow><mml:mtext mathvariant="italic">block</mml:mtext>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:mrow><mml:mi>c</mml:mi>
<mml:mo>+</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:msup>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
<mml:mrow><mml:mi>i</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:msup>
</mml:mrow>
</mml:math>
</disp-formula>
<disp-formula id="FD22"><label>(22)</label>
<mml:math id="mm22"><mml:mrow><mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:msub><mml:mtext mathvariant="italic">fail</mml:mtext>
<mml:mrow><mml:mtext mathvariant="italic">frag</mml:mtext>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:msup><mml:mrow><mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:msub><mml:mtext mathvariant="italic">err</mml:mtext>
<mml:mrow><mml:mtext mathvariant="italic">frag</mml:mtext>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:mrow><mml:mi>c</mml:mi>
<mml:mo>+</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:msup>
</mml:mrow>
</mml:math>
</disp-formula>
</p>
<p>In the rest of this section we present the expressions for the performance metrics that we use to evaluate CoAP blockwise transfer and 6LoWPAN fragmentation.</p>
<sec><label>4.1.</label>
<title>Reliability</title>
<p>WSN applications that monitor a critical environment or a critical physical variable require that the data collected by sensor nodes must be delivered reliably to destination. However, wireless links are error prone and ensuring end-to-end reliable data transfer is one of the major challenges in WSNs. In the proposed model we define reliability as the probability that the update sent by a CoAP server arrives correctly at destination.</p>
<p>In the previous section we derived the probability that the transmission of an update fails. Next we derive the expression of the end-to-end reliability for the CoAP blockwise transfer R<sub>block,l</sub>
and the 6LoWPAN fragmentation R<sub>frag,l</sub>
.
<disp-formula id="FD23"><label>(23)</label>
<mml:math id="mm23"><mml:mrow><mml:msub><mml:mi>R</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">block</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>−</mml:mo>
<mml:mspace width="0.2em"></mml:mspace>
<mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:msub><mml:mtext mathvariant="italic">fail</mml:mtext>
<mml:mrow><mml:mtext mathvariant="italic">block</mml:mtext>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</disp-formula>
<disp-formula id="FD24"><label>(24)</label>
<mml:math id="mm24"><mml:mrow><mml:msub><mml:mi>R</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">frag</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>−</mml:mo>
<mml:mspace width="0.2em"></mml:mspace>
<mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:msub><mml:mtext mathvariant="italic">fail</mml:mtext>
<mml:mrow><mml:mtext mathvariant="italic">frag</mml:mtext>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</disp-formula>
</p>
</sec>
<sec><label>4.2.</label>
<title>Latency</title>
<p>The latency that can be tolerated by an application is of paramount importance to choose the appropriate data transfer technique. WSN applications could have strict deadline requirements on the data sensed by a device. Scenarios such as e-Health or industrial monitoring are an example of those applications. In this paper, we define latency as the time required to complete a data transaction between server and client. The reception of the CoAP ACK relative to the fragmented update or the last block determines the end of the transaction.</p>
<p>The latency of a CoAP transaction has to consider the delay caused by an unsuccessful frame transmission. The value of the RTO includes this delay. The expression of the delay of a frame transmission was derived in the previous section. Next we present the latency for each case:</p>
<sec><label>4.2.1.</label>
<title>Latency for 6LoWPAN fragmentation</title>
<p>The latency of an update transmission that uses 6LoWPAN fragmentation is equal to the sum of the transmission delay of the CoAP ACK and that of each fragment. We define the latency for 6LoWPAN fragmentation D<sub>frag,l</sub>
as:
<disp-formula id="FD25"><label>(25)</label>
<mml:math id="mm25"><mml:mrow><mml:msub><mml:mi>D</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">frag</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:munderover><mml:mo>∑</mml:mo>
<mml:mrow><mml:mi>j</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>0</mml:mn>
</mml:mrow>
<mml:mi>c</mml:mi>
</mml:munderover>
<mml:mtext>Pr</mml:mtext>
<mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:msub><mml:mi>ℱ</mml:mi>
<mml:mi>j</mml:mi>
</mml:msub>
<mml:mrow><mml:mo>|</mml:mo>
</mml:mrow>
<mml:mi>ℱ</mml:mi>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:mspace width="0.2em"></mml:mspace>
<mml:msub><mml:mi>D</mml:mi>
<mml:mi>j</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</disp-formula>
where Pr(
<inline-graphic xlink:href="sensors-14-15610i1.jpg"></inline-graphic>
) is the probability of successful update transmission at the <italic>(j + 1)th</italic>
attempt given a successful update transmission within <italic>(c + 1)</italic>
attempts.
<disp-formula id="FD26"><label>(26)</label>
<mml:math id="mm26"><mml:mrow><mml:mi>Pr</mml:mi>
<mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:msub><mml:mi>ℱ</mml:mi>
<mml:mi>j</mml:mi>
</mml:msub>
<mml:mo>|</mml:mo>
<mml:mi>ℱ</mml:mi>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:mo>=</mml:mo>
<mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mn>1</mml:mn>
<mml:mo>−</mml:mo>
<mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:msub><mml:mtext mathvariant="italic">err</mml:mtext>
<mml:mrow><mml:mtext mathvariant="italic">frag</mml:mtext>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:msub><mml:mtext mathvariant="italic">err</mml:mtext>
<mml:mrow><mml:mtext mathvariant="italic">frag</mml:mtext>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:msub>
<mml:msup><mml:mrow></mml:mrow>
<mml:mi>j</mml:mi>
</mml:msup>
<mml:mo>/</mml:mo>
<mml:msub><mml:mi>R</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">frag</mml:mtext>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</disp-formula>
</p>
<p><italic>D<sub>j</sub>
</italic>
is the delay of an update that is successfully transmitted at the <italic>(j + 1)th</italic>
attempt, <italic>i.e.</italic>
,
<disp-formula id="FD27"><label>(27)</label>
<mml:math id="mm27"><mml:mrow><mml:msub><mml:mi>D</mml:mi>
<mml:mi>j</mml:mi>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:msub><mml:mi>D</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">ACK</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>+</mml:mo>
<mml:mi>f</mml:mi>
<mml:mo>*</mml:mo>
<mml:msub><mml:mi>D</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">frame</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>+</mml:mo>
<mml:mi>j</mml:mi>
<mml:mo>×</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:mrow><mml:mrow><mml:mtext mathvariant="italic">RTO</mml:mtext>
<mml:mo>+</mml:mo>
<mml:msub><mml:mi>D</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">ACK</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>+</mml:mo>
<mml:mi>f</mml:mi>
<mml:msub><mml:mi>D</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">frame</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</disp-formula>
where D<sub>CoAP ACK,l</sub>
is the delay of the CoAP ACK transmission, D<sub>frame,l</sub>
is the delay of a fragment at node <italic>l</italic>
and RTO is the value of the CoAP retransmission timeout.</p>
</sec>
<sec><label>4.2.2.</label>
<title>Latency for Blockwise transfer</title>
<p>The latency of an update transmission using the CoAP blockwise transfer is defined as follows:
<disp-formula id="FD28"><label>(28)</label>
<mml:math id="mm28"><mml:mrow><mml:msub><mml:mi>D</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">block</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:mi>B</mml:mi>
<mml:munderover><mml:mo>∑</mml:mo>
<mml:mrow><mml:mi>j</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>0</mml:mn>
</mml:mrow>
<mml:mi>c</mml:mi>
</mml:munderover>
<mml:mtext>Pr</mml:mtext>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub><mml:mi>L</mml:mi>
<mml:mi>j</mml:mi>
</mml:msub>
<mml:mo>|</mml:mo>
<mml:mi>L</mml:mi>
<mml:mo stretchy="false">)</mml:mo>
<mml:mspace width="0.2em"></mml:mspace>
<mml:msub><mml:mi>D</mml:mi>
<mml:mi>j</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</disp-formula>
where Pr(ℒ<sub>j</sub>
|ℒ) is the probability of successful block transmission at the <italic>(j</italic>
+ <italic>1)th</italic>
attempt given a successful block transmission within <italic>(c</italic>
+ <italic>1)</italic>
attempts.
<disp-formula id="FD29"><label>(29)</label>
<mml:math id="mm29"><mml:mrow><mml:mi>Pr</mml:mi>
<mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:msub><mml:mi>ℒ</mml:mi>
<mml:mi>j</mml:mi>
</mml:msub>
<mml:mo>|</mml:mo>
<mml:mi>ℒ</mml:mi>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:mo>=</mml:mo>
<mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mn>1</mml:mn>
<mml:mo>−</mml:mo>
<mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:msub><mml:mtext mathvariant="italic">err</mml:mtext>
<mml:mrow><mml:mtext mathvariant="italic">block</mml:mtext>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:msub><mml:mi>P</mml:mi>
<mml:mrow><mml:msub><mml:mtext mathvariant="italic">err</mml:mtext>
<mml:mrow><mml:mtext mathvariant="italic">block</mml:mtext>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:msub>
<mml:msup><mml:mrow></mml:mrow>
<mml:mi>j</mml:mi>
</mml:msup>
<mml:mo>/</mml:mo>
<mml:msub><mml:mi>R</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">block</mml:mtext>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</disp-formula>
<italic>D<sub>j</sub>
</italic>
is the delay of a block that is successfully transmitted at the <italic>(j</italic>
+ <italic>1)th</italic>
attempt, <italic>i.e.</italic>
,
<disp-formula id="FD30"><label>(30)</label>
<mml:math id="mm30"><mml:mrow><mml:msub><mml:mi>D</mml:mi>
<mml:mi>j</mml:mi>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:msub><mml:mi>D</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">ACK</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>+</mml:mo>
<mml:msub><mml:mi>D</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">frame</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>+</mml:mo>
<mml:mi>j</mml:mi>
<mml:mo>×</mml:mo>
<mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mtext mathvariant="italic">RTO</mml:mtext>
<mml:mo>+</mml:mo>
<mml:msub><mml:mi>D</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">ACK</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>+</mml:mo>
<mml:msub><mml:mi>D</mml:mi>
<mml:mrow><mml:mtext mathvariant="italic">frame</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</disp-formula>
</p>
</sec>
</sec>
</sec>
<sec><label>5.</label>
<title>Performance Evaluation</title>
<p>In this section we validate the model by Monte Carlo simulations and present the results of the performance evaluation. We base the simulation parameters on the specification of the IEEE 802.15.4 [<xref rid="b2-sensors-14-15610" ref-type="bibr">2</xref>
] and CoAP [<xref rid="b7-sensors-14-15610" ref-type="bibr">7</xref>
] protocols. We evaluate our models with different values of the traffic pattern and for CoAP updates composed by a variable number of fragments and blocks. The MAC parameters are selected as <italic>m<sub>0</sub>
</italic>
= <italic>3</italic>
, <italic>m<sub>B</sub>
</italic>
= <italic>5</italic>
, <italic>m</italic>
= <italic>4</italic>
, <italic>n</italic>
= <italic>0</italic>
, in accordance with the 802.15.4 standard [<xref rid="b2-sensors-14-15610" ref-type="bibr">2</xref>
]. The MAC frames have size <italic>L</italic>
= <italic>L<sub>ACK</sub>
</italic>
= <italic>127 bytes</italic>
and the MAC ACK frame <italic>L<sub>MAC ACK</sub>
</italic>
= <italic>11 byt</italic>
es. We study various traffic and fragmentation scenarios by considering <italic>N</italic>
= <italic>[10, 15, 20]</italic>
nodes with update generation rates <italic>λ</italic>
= <italic>[0.1… 1]</italic>
pkt/s ad updates divided into <italic>B</italic>
= <italic>[<xref rid="b1-sensors-14-15610" ref-type="bibr">1</xref>
, <xref rid="b3-sensors-14-15610" ref-type="bibr">3</xref>
, <xref rid="b5-sensors-14-15610" ref-type="bibr">5</xref>
, <xref rid="b7-sensors-14-15610" ref-type="bibr">7</xref>
]</italic>
blocks (in CoAP blockwise transfer) or <italic>F</italic>
= <italic>[<xref rid="b1-sensors-14-15610" ref-type="bibr">1</xref>
, <xref rid="b3-sensors-14-15610" ref-type="bibr">3</xref>
, <xref rid="b5-sensors-14-15610" ref-type="bibr">5</xref>
, <xref rid="b7-sensors-14-15610" ref-type="bibr">7</xref>
]</italic>
fragments (in 6LoWPAN fragmentation). As previously mentioned, the generation rate <italic>λ</italic>
is constrained by the value of the minimum RTO recommended by CoAP [<xref rid="b7-sensors-14-15610" ref-type="bibr">7</xref>
]. In this sense, the timeout is <italic>RTO</italic>
= <italic>1s</italic>
with a random backoff of 0.5s. The number of retransmission is set as <italic>c</italic>
= <italic>1</italic>
.</p>
<sec><label>5.1.</label>
<title>Reliability</title>
<p><xref rid="f7-sensors-14-15610" ref-type="fig">Figures 7</xref>
, <xref rid="f8-sensors-14-15610" ref-type="fig">8</xref>
and <xref rid="f9-sensors-14-15610" ref-type="fig">9</xref>
show the average reliability of CoAP blockwise transfer computed over all the links for a star topology network with mixed traffic conditions. <xref rid="f10-sensors-14-15610" ref-type="fig">Figures 10</xref>
, <xref rid="f11-sensors-14-15610" ref-type="fig">11</xref>
and <xref rid="f12-sensors-14-15610" ref-type="fig">12</xref>
show the average reliability of 6LoWPAN fragmentation for the same scenario. A good agreement between simulations and analytical results of the model is observed. The reliability performance of 6LoWPAN fragmentation and CoAP blockwise transfer is very similar in the considered scenarios. The difference between the reliability values is lower than 2%. In particular, CoAP blockwise transfer has a slightly better reliability when the traffic conditions congest the WSN, which is the case for <italic>N</italic>
= 20, <italic>B</italic>
= 5 and λ greater than 0.8 pkt/s. In these conditions blockwise improves reliability by the 0.96% respect to 6LoWPAN fragmentation.</p>
<p>However, 6LoWPAN fragmentation is slightly more reliable than blockwise when the traffic conditions do not congest the WSN. However, for <italic>N</italic>
= 10 the trends of both solutions are very close and differ by the 0.2% for λ = 1 pkt/s and <italic>F</italic>
= 3. This difference grows up to the 0.7% for <italic>F</italic>
= 5 with the same traffic rate. For <italic>N</italic>
= 15 6LoWPAN fragmentation has a maximum improvement of the 1% over blockwise, which is obtained for λ = 1 pkt/s and <italic>F</italic>
= 5. A similar difference is observed for <italic>N</italic>
= 20, <italic>F</italic>
= 3 and the same traffic rate.</p>
<p>The same behavior can be observed in <xref rid="f13-sensors-14-15610" ref-type="fig">Figure 13</xref>
, which shows the average reliability of CoAP blockwise transfer and 6LoWPAN fragmentation according to the variation of the number of blocks or fragments that compose an update. The average reliability is computed over all the links for a star topology network of <italic>N</italic>
= 15 nodes and λ = 1 pkt/s. 6LoWPAN fragmentation improves slightly reliability for a number of fragments lower than five. The reliability trend of 6LoWPAN fragmentation undergoes a pronounced drop when the number of fragments grows and the WSN becomes more congested. In this situation, CoAP blockwise transfer has a less pronounced drop, which allows outperforming 6LoWPAN fragmentation. In particular, for <italic>B</italic>
= 7 blockwise transfer improves reliability by the 10.7% respect to fragmentation. In congested WSNs, in fact, the probability that a fragment or block is retransmitted is high. Therefore, consecutive failures of blocks belonging to the same update do not cause the failure of the update transmission, as it would happen in 6LoWPAN. CoAP Blockwise transfer, therefore, is able to reduce the number of lost updates establishing a reliable transfer for each single block.</p>
<p>In CoAP blockwise transfer, the transmission of a CoAP ACK for each block causes an increase of the channel occupancy. This has a counter-effect on the reliability that is more evident when the network is not congested. In this situation, CoAP blockwise transfer increases the average network traffic augmenting the collision probability. 6LoWPAN fragmentation requires the transmission of fewer messages for a single update. It is able, therefore, to reduce the network traffic and the retransmission probability of an update. A node using 6LoWPAN fragmentation is able to reduce significantly the occupancy of the channel. Thereby, the probability that a concurrent node finds the channel busy when attempting the transmission is lower respect to CoAP blockwise transfer. Besides the higher probability of finding the channel idle, a fragment has less chance to collide with the transmission of another one or with a CoAP ACK. 6LoWPAN fragmentation is able, therefore, to improve reliability under these traffic conditions.</p>
</sec>
<sec><label>5.2.</label>
<title>Latency</title>
<p><xref rid="f14-sensors-14-15610" ref-type="fig">Figures 14</xref>
, <xref rid="f15-sensors-14-15610" ref-type="fig">15</xref>
and <xref rid="f16-sensors-14-15610" ref-type="fig">16</xref>
show the average latency of CoAP blockwise transfer computed over all the links for a star topology network with mixed traffic conditions. <xref rid="f17-sensors-14-15610" ref-type="fig">Figures 17</xref>
, <xref rid="f18-sensors-14-15610" ref-type="fig">18</xref>
and <xref rid="f19-sensors-14-15610" ref-type="fig">19</xref>
show the average latency for 6LoWPAN fragmentation. A good agreement between simulations and analytical results of the model is observed.</p>
<p>According to our performance evaluation, 6LoWPAN fragmentation outperforms CoAP blockwise transfer in terms of latency independently from the update generation rate and the number of nodes. The difference between both techniques becomes higher with the growth of the update generation rate and the number of fragments or blocks involved in the communication. As mentioned, 6loWPAN fragmentation requires the interchange of fewer messages than CoAP blockwise transfer. Consequently, the latency of an update transmission is significantly lower than that experienced by CoAP blockwise transfer. The performance of CoAP blockwise transfer, however, could be improved by considering block sizes that allow sending a single block in more than one frame. This would reduce the number of CoAP ACKs and consequently the latency performance would improve. However, its performance would be always lower than that of 6LoWPAN fragmentation, which represents an upper bound to the performance of CoAP blockwise transfer. 6LoWPAN fragmentation could be considered as a particular case of CoAP blockwise transfer with a block size that allows sending a single CoAP ACK.</p>
<p>The latency of CoAP blockwise transfer has a sharp rise for increasing values of the traffic rate, which further augments the difference with that of 6LoWPAN fragmentation. The same behavior can be observed in <xref rid="f20-sensors-14-15610" ref-type="fig">Figure 20</xref>
, which shows the latency trend according to the number of blocks or fragments of an update in a WSN composed by 15 nodes and traffic rate of 1 pkt/s. The growth of the traffic rate as well as that of the number of fragments (6LoWPAN fragmentation) or blocks (CoAP blockwise transfer) congest the WSN and augment the retransmission probability of an update. Although in case of congestion CoAP blockwise transfer shows a slightly better reliability, the cost in terms of latency of block-to-block retransmission does not allow improving its performance. The retransmission of the entire update in 6LoWPAN fragmentation has less effect on the average latency.</p>
<p>This behavior can be explained analyzing the Probability Density Function (PDF) of the latency, which is shown in <xref rid="f21-sensors-14-15610" ref-type="fig">Figure 21</xref>
. It is evaluated in a star topology WSN composed by 15 nodes with a traffic rate of 1 pkt/s and updates composed by five fragments or blocks. The distribution of both solutions presents a long tail, which is due to the effect of retransmissions. The presence of block-to-block retransmissions causes the tail of CoAP blockwise transfer to be the longest one. This further worsens its average latency and causes the rapid growth of its curve. In CoAP blockwise transfer each block of an update could be retransmitted. The overall latency would be higher than that of retransmitting the entire update as done by 6LoWPAN fragmentation. We remark that reliability and latency can be competing requirements and a trade-off is needed to guarantee low energy consumption. The model can be used within a constrained optimization framework for the selection of protocol parameters and fragmentation techniques.</p>
</sec>
<sec><label>5.3.</label>
<title>Model Limitations</title>
<p>Here, we discuss the fundamental limitations of the analytical model developed and analyzed in the previous sections. First, we remark that the Markov chain model requires the solution of systems of non-linear equations to derive MAC indicators such as the CCA probability, the busy channel probability and the collision probability in Section 3.3. For the use of such a model for online computation in real sensors, the complexity is a critical factor since the typical micro-controller does not support well a complex computing. In heterogeneous network conditions, a Markov chain has to be solved for each link, and the complexity increases with the number of links. The use of approximated model equations is advocated in [<xref rid="b14-sensors-14-15610" ref-type="bibr">14</xref>
], when the number of nodes exceeds 15, to guarantee bounded computation times in the order of seconds for typical sensor platforms.</p>
<p>The model includes the effects of bursty traffic on the busy channel probability in different backoff stages. However, we assume an average CCA probability <italic>τ<sub>l</sub>
</italic>
in each time unit. As we see from the simulation results, this is a fair approximation when the number of blocks (or fragments) is limited. When the traffic in the network becomes saturated, the performance of the MAC layer is influenced also by higher order statistics of <italic>τ<sub>l</sub>
</italic>
.</p>
<p>A practical limitation with high traffic conditions is also given by the retransmission mechanism of CoAP that defines a minimum RTO in the order of 1 s. This is specified by the standard to guarantee support for multi-hop communications. However, that limits the derivation of the offered traffic in the network, since the packet service time increases quickly with the update generation time, especially for block-wise transfer, where the retransmission is performed on a block-level, as we saw in <xref rid="f20-sensors-14-15610" ref-type="fig">Figure 20</xref>
.</p>
</sec>
</sec>
<sec sec-type="conclusions"><label>6.</label>
<title>Conclusions</title>
<p>In this paper, we have analyzed CoAP data transactions with large payloads in WSN with star topology. We have proposed a novel analytical model to study the performance of 6LoWPAN fragmentation and CoAP blockwise transfer. We have adopted reliability and latency as performance indicators. We have used Monte Carlo simulation to validate our model. The results demonstrate accuracy to estimate the performance of CoAP blockwise transfer and 6LoWPAN fragmentations.</p>
<p>As for reliability, we have observed a good performance of both techniques with small differences between them. However, depending on the traffic conditions a technique could be preferred to the other. In particular, CoAP blockwise transfer is a more reliable solution when traffic conditions lead to a congestion of the WSN, which is the case of applications with high traffic rates or that produce updates composed by many blocks. 6LoWPAN fragmentation is preferable when the WSN links are less congested.</p>
<p>A clear disadvantage of CoAP blockwise transfer is the latency introduced by acknowledging each single block, which worsen the performance of CoAP blockwise transfer. According to our results 6LoWPAN fragmentation outperforms CoAP blockwise transfer in terms of latency also in congested WSN.</p>
<p>In conclusion, applications that have strict requirements in terms of latency, <italic>i.e.</italic>
, real-time applications, should adopt 6LoWPAN fragmentation. With more relaxed constraints on latency, <italic>i.e.</italic>
, applications that use data logging, CoAP blockwise transfer should be adopted when the traffic conditions are close to saturation. A good trade-off could be reached using an algorithm able to choose dynamically which technique use depending from the traffic conditions.</p>
</sec>
</body>
<back><ack><p>This work has been supported by the Spanish Government, MINECO, under research grants TEC2012-32531 and FEDER, by the Catalan Government (Commissionat per a Universitat I Recerca del DIUE), the European Social Budget and the Swedish research Council.</p>
</ack>
<notes><title>Author Contributions</title>
<p>This paper is part of a Ph.D Thesis written by Alessandro Ludovici under the supervision of Anna Calveras. Piergiuseppe Di Marco helped with the definition of the analytical and developed the simulation code. Anna Calveras and Karl H. Johansson reviewed the paper and provided valuable comments for improvements.</p>
</notes>
<notes><title>Conflict of Interest</title>
<p>The authors declare no conflict of interest.</p>
</notes>
<ref-list><title>References</title>
<ref id="b1-sensors-14-15610"><label>1.</label>
<element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Miorandi</surname>
<given-names>D.</given-names>
</name>
<name><surname>Sicari</surname>
<given-names>S.</given-names>
</name>
<name><surname>de Pellegrini</surname>
<given-names>F.</given-names>
</name>
<name><surname>Chlamtac</surname>
<given-names>I.</given-names>
</name>
</person-group>
<article-title>Internet of things: Vision, applications and research challenges</article-title>
<source>Ad Hoc Netw.</source>
<year>2012</year>
<volume>10</volume>
<fpage>1497</fpage>
<lpage>1516</lpage>
</element-citation>
</ref>
<ref id="b2-sensors-14-15610"><label>2.</label>
<note><p>IEEE 802.15.4 Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs). IEEE Std. 802.15.42006</p>
</note>
</ref>
<ref id="b3-sensors-14-15610"><label>3.</label>
<element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Chebrolu</surname>
<given-names>K.</given-names>
</name>
<name><surname>Raman</surname>
<given-names>B.</given-names>
</name>
<name><surname>Mishra</surname>
<given-names>N.</given-names>
</name>
<name><surname>Valiveti</surname>
<given-names>P.K.</given-names>
</name>
<name><surname>Kumar</surname>
<given-names>R.</given-names>
</name>
</person-group>
<article-title>Brimon: A sensor network system for railway bridge monitoring</article-title>
<conf-name>Proceedings of the 6th International Conference on Mobile Systems, Applications, and Services, (MobiSys)</conf-name>
<conf-loc>Breckenridge, CO, USA</conf-loc>
<conf-date>10–13 June 2008</conf-date>
</element-citation>
</ref>
<ref id="b4-sensors-14-15610"><label>4.</label>
<element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Kim</surname>
<given-names>S.</given-names>
</name>
<name><surname>Pakzad</surname>
<given-names>S.</given-names>
</name>
<name><surname>Culler</surname>
<given-names>D.</given-names>
</name>
<name><surname>Demmel</surname>
<given-names>J.</given-names>
</name>
<name><surname>Fenves</surname>
<given-names>G.</given-names>
</name>
<name><surname>Glaser</surname>
<given-names>S.</given-names>
</name>
<name><surname>Turon</surname>
<given-names>M.</given-names>
</name>
</person-group>
<article-title>Health monitoring of civil infrastructures using wireless sensor networks</article-title>
<conf-name>Proceedings of the International Conference on Information Processing in Sensor Networks (ACM/IEEE IPSN)</conf-name>
<conf-loc>St. Louis, MO, USA</conf-loc>
<conf-date>22–24 April 2007</conf-date>
<fpage>254</fpage>
<lpage>263</lpage>
</element-citation>
</ref>
<ref id="b5-sensors-14-15610"><label>5.</label>
<element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Werner-Allen</surname>
<given-names>G.</given-names>
</name>
<name><surname>Lorincz</surname>
<given-names>K.</given-names>
</name>
<name><surname>Ruiz</surname>
<given-names>M.</given-names>
</name>
<name><surname>Marcillo</surname>
<given-names>O.</given-names>
</name>
<name><surname>Johnson</surname>
<given-names>J.</given-names>
</name>
<name><surname>Lees</surname>
<given-names>J.</given-names>
</name>
<name><surname>Welsh</surname>
<given-names>M.</given-names>
</name>
</person-group>
<article-title>Deploying a wireless sensor network on an active volcano</article-title>
<source>IEEE Internet Comput.</source>
<year>2006</year>
<volume>10</volume>
<fpage>18</fpage>
<lpage>25</lpage>
</element-citation>
</ref>
<ref id="b6-sensors-14-15610"><label>6.</label>
<element-citation publication-type="webpage"><person-group person-group-type="author"><name><surname>Montenegro</surname>
<given-names>G.</given-names>
</name>
<name><surname>Kushalnagar</surname>
<given-names>N.</given-names>
</name>
<name><surname>Hui</surname>
<given-names>J.</given-names>
</name>
<name><surname>Culler</surname>
<given-names>D.</given-names>
</name>
</person-group>
<article-title>RFC 4944. Transmission of IPv6 Packets over IEEE 802.15.4 Networks</article-title>
<comment>Available online: <ext-link ext-link-type="uri" xlink:href="http://tools.ietf.org/html/rfc4944">http://tools.ietf.org/html/rfc4944</ext-link>
</comment>
<date-in-citation>(accessed on 6 August 2014)</date-in-citation>
</element-citation>
</ref>
<ref id="b7-sensors-14-15610"><label>7.</label>
<element-citation publication-type="webpage"><person-group person-group-type="author"><name><surname>Shelby</surname>
<given-names>Z.</given-names>
</name>
<name><surname>Hartke</surname>
<given-names>K.</given-names>
</name>
<name><surname>Bormann</surname>
<given-names>C.</given-names>
</name>
<name><surname>Frank</surname>
<given-names>B.</given-names>
</name>
</person-group>
<article-title>RFC 7252. Constrained Application Protocol (CoAP)</article-title>
<comment>Available online: <ext-link ext-link-type="uri" xlink:href="http://tools.ietf.org/html/rfc7252">http://tools.ietf.org/html/rfc7252</ext-link>
</comment>
<date-in-citation>(accessed on 6 August 2014)</date-in-citation>
</element-citation>
</ref>
<ref id="b8-sensors-14-15610"><label>8.</label>
<element-citation publication-type="webpage"><person-group person-group-type="author"><name><surname>Bormann</surname>
<given-names>C.</given-names>
</name>
<name><surname>Shelby</surname>
<given-names>Z.</given-names>
</name>
</person-group>
<article-title>Blockwise transfers in CoAP</article-title>
<comment>Available online: <ext-link ext-link-type="uri" xlink:href="http://tools.ietf.org/html/draft-ietf-core-block-18">http://tools.ietf.org/html/draft-ietf-core-block-18</ext-link>
</comment>
<date-in-citation>(accessed on 6 August 2014)</date-in-citation>
</element-citation>
</ref>
<ref id="b9-sensors-14-15610"><label>9.</label>
<element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Mesrinejad</surname>
<given-names>F.</given-names>
</name>
<name><surname>Hashim</surname>
<given-names>F.</given-names>
</name>
<name><surname>Noordin</surname>
<given-names>N.K.</given-names>
</name>
<name><surname>Rasid</surname>
<given-names>M.F.A;</given-names>
</name>
<name><surname>Raja Abdullah</surname>
<given-names>R.S.A.</given-names>
</name>
</person-group>
<article-title>The effect of fragmentation and header compression on IP-based sensor networks (6LoWPAN)</article-title>
<conf-name>Proceedings of the 17th Asia-Pacific Conference on Communications (APCC)</conf-name>
<conf-loc>Sabah, Malaysia</conf-loc>
<conf-date>2–5 October 2011</conf-date>
<fpage>845</fpage>
<lpage>849</lpage>
</element-citation>
</ref>
<ref id="b10-sensors-14-15610"><label>10.</label>
<element-citation publication-type="book"><person-group person-group-type="author"><name><surname>Weigel</surname>
<given-names>A.</given-names>
</name>
<name><surname>Turau</surname>
<given-names>V.</given-names>
</name>
</person-group>
<article-title>An Analytical Model of 6LoWPAN Route-Over Forwarding Practices</article-title>
<source>Ad-hoc, Mobile and Wireless Networks</source>
<publisher-name>Springer</publisher-name>
<publisher-loc>Switzerland</publisher-loc>
<year>2014</year>
<fpage>279</fpage>
<lpage>289</lpage>
</element-citation>
</ref>
<ref id="b11-sensors-14-15610"><label>11.</label>
<element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Potsch</surname>
<given-names>T.</given-names>
</name>
<name><surname>Kuladinithi</surname>
<given-names>K.</given-names>
</name>
<name><surname>Becker</surname>
<given-names>M.</given-names>
</name>
<name><surname>Trenkamp</surname>
<given-names>P.</given-names>
</name>
<name><surname>Goerg</surname>
<given-names>C.</given-names>
</name>
</person-group>
<article-title>Performance Evaluation of CoAP Using RPL and LPL in TinyOS</article-title>
<conf-name>Proceedings of the 2012 5th International Conference on New Technologies, Mobility and Security (NTMS)</conf-name>
<conf-loc>Istanbul, Turkey</conf-loc>
<conf-date>7–10 May 2012</conf-date>
<fpage>1</fpage>
<lpage>5</lpage>
</element-citation>
</ref>
<ref id="b12-sensors-14-15610"><label>12.</label>
<element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Sammarco</surname>
<given-names>C.</given-names>
</name>
<name><surname>Iera</surname>
<given-names>A.</given-names>
</name>
</person-group>
<article-title>Improving Service Management in the Internet of Things</article-title>
<source>Sensors</source>
<year>2012</year>
<volume>12</volume>
<fpage>11888</fpage>
<lpage>11909</lpage>
</element-citation>
</ref>
<ref id="b13-sensors-14-15610"><label>13.</label>
<element-citation publication-type="webpage"><person-group person-group-type="author"><name><surname>Hartke</surname>
<given-names>K.</given-names>
</name>
</person-group>
<article-title>Observing Resources in CoAP</article-title>
<comment>Available online: <ext-link ext-link-type="uri" xlink:href="http://tools.ietf.org/html/draft-ietf-core-observe-13">http://tools.ietf.org/html/draft-ietf-core-observe-13</ext-link>
</comment>
<date-in-citation>(accessed on 6 August 2014)</date-in-citation>
</element-citation>
</ref>
<ref id="b14-sensors-14-15610"><label>14.</label>
<element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Di Marco</surname>
<given-names>P.</given-names>
</name>
<name><surname>Pangun</surname>
<given-names>P.</given-names>
</name>
<name><surname>Fischione</surname>
<given-names>C.</given-names>
</name>
<name><surname>Johansson</surname>
<given-names>K.H.</given-names>
</name>
</person-group>
<article-title>Analytical Modeling of Multi-hop IEEE 802.15.4 Networks</article-title>
<source>IEEE Trans. Veh. Technol.</source>
<year>2012</year>
<volume>61</volume>
<fpage>3191</fpage>
<lpage>3208</lpage>
</element-citation>
</ref>
<ref id="b15-sensors-14-15610"><label>15.</label>
<element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Pollin</surname>
<given-names>S.</given-names>
</name>
<name><surname>Ergen</surname>
<given-names>M.</given-names>
</name>
<name><surname>Ergen</surname>
<given-names>S.C.</given-names>
</name>
<name><surname>Bougard</surname>
<given-names>B.</given-names>
</name>
<name><surname>van der Perre</surname>
<given-names>L.</given-names>
</name>
<name><surname>Moerman</surname>
<given-names>I.</given-names>
</name>
<name><surname>Bahai</surname>
<given-names>A.</given-names>
</name>
<name><surname>Varaiya</surname>
<given-names>P.</given-names>
</name>
<name><surname>Catthoor</surname>
<given-names>F.</given-names>
</name>
</person-group>
<article-title>Performance analysis of slotted carrier sense IEEE 802.15.4 medium access layer</article-title>
<source>IEEE Trans. Wireless Commun.</source>
<year>2008</year>
<volume>7</volume>
<fpage>3359</fpage>
<lpage>3371</lpage>
</element-citation>
</ref>
<ref id="b16-sensors-14-15610"><label>16.</label>
<element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Park</surname>
<given-names>P.</given-names>
</name>
<name><surname>di Marco</surname>
<given-names>P.</given-names>
</name>
<name><surname>Fischione</surname>
<given-names>C.</given-names>
</name>
<name><surname>Johansson</surname>
<given-names>K.H.</given-names>
</name>
</person-group>
<article-title>Modeling and optimization of the IEEE 802.15.4 protocol for reliable and timely communications</article-title>
<source>IEEE Trans. Parallel Distrib. Syst.</source>
<year>2013</year>
<volume>24</volume>
<fpage>550</fpage>
<lpage>564</lpage>
</element-citation>
</ref>
<ref id="b17-sensors-14-15610"><label>17.</label>
<element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Gao</surname>
<given-names>J.</given-names>
</name>
<name><surname>Hu</surname>
<given-names>J.</given-names>
</name>
<name><surname>Min</surname>
<given-names>G.</given-names>
</name>
</person-group>
<article-title>Performance Modelling of IEEE 802.15.4 MAC in LR-WPAN with Bursty ON-OFF Traffic</article-title>
<conf-name>Proceedings of the Ninth IEEE International Conference on Computer and Information Technology</conf-name>
<conf-loc>Xiamen, China</conf-loc>
<conf-date>11–14 October 2009</conf-date>
<volume>Volume 2</volume>
<fpage>58</fpage>
<lpage>62</lpage>
</element-citation>
</ref>
<ref id="b18-sensors-14-15610"><label>18.</label>
<element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Ludovici</surname>
<given-names>A.</given-names>
</name>
<name><surname>Calveras</surname>
<given-names>A.</given-names>
</name>
<name><surname>Casademont</surname>
<given-names>J.</given-names>
</name>
</person-group>
<article-title>Forwarding Techniques for IP Fragmented Packets in a Real 6LoWPAN Network</article-title>
<source>Sensors</source>
<year>2011</year>
<volume>11</volume>
<fpage>992</fpage>
<lpage>1008</lpage>
<pub-id pub-id-type="pmid">22346615</pub-id>
</element-citation>
</ref>
</ref-list>
</back>
<floats-group><fig id="f1-sensors-14-15610" position="float"><label>Figure 1.</label>
<caption><p>6LoWPAN Fragment headers. (<bold>a</bold>
) First Fragment; (<bold>b</bold>
) Second Fragment.</p>
</caption>
<graphic xlink:href="sensors-14-15610f1"></graphic>
</fig>
<fig id="f2-sensors-14-15610" position="float"><label>Figure 2.</label>
<caption><p>Each update is composed by two fragments. The client fails to send the CoAP ACK at the third update while a fragment transmission fails in the second one. Both failures cause the retransmission of the entire fragmented update.</p>
</caption>
<graphic xlink:href="sensors-14-15610f2"></graphic>
</fig>
<fig id="f3-sensors-14-15610" position="float"><label>Figure 3.</label>
<caption><p>Encoding of the block option.</p>
</caption>
<graphic xlink:href="sensors-14-15610f3"></graphic>
</fig>
<fig id="f4-sensors-14-15610" position="float"><label>Figure 4.</label>
<caption><p>Blockwise transfer in observe data transaction. Two blocks compose each update. In the second update the CoAP ACK sent by the client fails while in the third one the second block fails. Both failures cause the retransmission of the relative block.</p>
</caption>
<graphic xlink:href="sensors-14-15610f4"></graphic>
</fig>
<fig id="f5-sensors-14-15610" position="float"><label>Figure 5.</label>
<caption><p>Blockwise transfer in observe data transaction. Two blocks compose each update. In the second update the CoAP ACK sent by the client fails while in the third one the second block fails. Both failures cause the retransmission of the relative block.</p>
</caption>
<graphic xlink:href="sensors-14-15610f5"></graphic>
</fig>
<fig id="f6-sensors-14-15610" position="float"><label>Figure 6.</label>
<caption><p>Markov chains for the server. (<bold>a</bold>
) 6LoWPAN Fragmentation case (<bold>b</bold>
) Blockwise transfer case. (<bold>a</bold>
) The server retransmits all the fragments if the transmission of any of them fails or it does not receive the CoAP ACK; (<bold>b</bold>
) The server retransmits a single block if its transmission fails or it does not receive the relative CoAP ACK. The Markov chain represents the transmission of an observe update composed by two blocks.</p>
</caption>
<graphic xlink:href="sensors-14-15610f6"></graphic>
</fig>
<fig id="f7-sensors-14-15610" position="float"><label>Figure 7.</label>
<caption><p>Blockwise reliability <italic>versus</italic>
traffic rate for a star topology network composed by 10 nodes.</p>
</caption>
<graphic xlink:href="sensors-14-15610f7"></graphic>
</fig>
<fig id="f8-sensors-14-15610" position="float"><label>Figure 8.</label>
<caption><p>Blockwise reliability <italic>versus</italic>
traffic rate for a star topology network composed by 15 nodes.</p>
</caption>
<graphic xlink:href="sensors-14-15610f8"></graphic>
</fig>
<fig id="f9-sensors-14-15610" position="float"><label>Figure 9.</label>
<caption><p>Blockwise reliability <italic>versus</italic>
traffic rate for a star topology network composed by 20 nodes.</p>
</caption>
<graphic xlink:href="sensors-14-15610f9"></graphic>
</fig>
<fig id="f10-sensors-14-15610" position="float"><label>Figure 10.</label>
<caption><p>6LoWPAN fragmentation reliability <italic>versus</italic>
traffic rate for a star topology network composed by 10 nodes.</p>
</caption>
<graphic xlink:href="sensors-14-15610f10"></graphic>
</fig>
<fig id="f11-sensors-14-15610" position="float"><label>Figure 11.</label>
<caption><p>6LoWPAN fragmentation reliability <italic>versus</italic>
traffic rate for a star topology network composed by 15 nodes.</p>
</caption>
<graphic xlink:href="sensors-14-15610f11"></graphic>
</fig>
<fig id="f12-sensors-14-15610" position="float"><label>Figure 12.</label>
<caption><p>6LoWPAN fragmentation reliability <italic>versus</italic>
traffic rate for a star topology network composed by 20 nodes.</p>
</caption>
<graphic xlink:href="sensors-14-15610f12"></graphic>
</fig>
<fig id="f13-sensors-14-15610" position="float"><label>Figure 13.</label>
<caption><p>Blockwise and 6LoWPAN reliability <italic>versus</italic>
the number of blocks or fragments that compose an update. The network is composed by 15 nodes and the traffic rate is fixed to 1 pkt/s.</p>
</caption>
<graphic xlink:href="sensors-14-15610f13"></graphic>
</fig>
<fig id="f14-sensors-14-15610" position="float"><label>Figure 14.</label>
<caption><p>Blockwise Latency <italic>versus</italic>
traffic rate for a star topology network composed by 10 nodes.</p>
</caption>
<graphic xlink:href="sensors-14-15610f14"></graphic>
</fig>
<fig id="f15-sensors-14-15610" position="float"><label>Figure 15.</label>
<caption><p>Blockwise Latency <italic>versus</italic>
traffic rate for a star topology network composed by 15 nodes.</p>
</caption>
<graphic xlink:href="sensors-14-15610f15"></graphic>
</fig>
<fig id="f16-sensors-14-15610" position="float"><label>Figure 16.</label>
<caption><p>Blockwise Latency <italic>versus</italic>
traffic rate for a star topology network composed by 20 nodes.</p>
</caption>
<graphic xlink:href="sensors-14-15610f16"></graphic>
</fig>
<fig id="f17-sensors-14-15610" position="float"><label>Figure 17.</label>
<caption><p>6LoWPAN Fragmentation Latency <italic>versus</italic>
traffic rate for a star topology network composed by 10 nodes.</p>
</caption>
<graphic xlink:href="sensors-14-15610f17"></graphic>
</fig>
<fig id="f18-sensors-14-15610" position="float"><label>Figure 18.</label>
<caption><p>6LoWPAN Fragmentation Latency <italic>versus</italic>
traffic rate for a star topology network composed by 15 nodes.</p>
</caption>
<graphic xlink:href="sensors-14-15610f18"></graphic>
</fig>
<fig id="f19-sensors-14-15610" position="float"><label>Figure 19.</label>
<caption><p>6LoWPAN Fragmentation Latency <italic>versus</italic>
traffic rate for a star topology network composed by 20 nodes.</p>
</caption>
<graphic xlink:href="sensors-14-15610f19"></graphic>
</fig>
<fig id="f20-sensors-14-15610" position="float"><label>Figure 20.</label>
<caption><p>Blockwise and 6LoWPAN latency <italic>vs.</italic>
the number of blocks or fragments for a star topology network composed by 20 nodes and a traffic rate of 1 pkt/s.</p>
</caption>
<graphic xlink:href="sensors-14-15610f20"></graphic>
</fig>
<fig id="f21-sensors-14-15610" position="float"><label>Figure 21.</label>
<caption><p>PDF of the latency for a star topology network with 15 nodes and a traffic rate of 1 pkt/s. 6LoWPAN. Each update is composed by five fragments or blocks. For the sake of clarity, the <italic>x</italic>
-axis is shown in logarithmic scale.</p>
</caption>
<graphic xlink:href="sensors-14-15610f21"></graphic>
</fig>
<table-wrap id="t1-sensors-14-15610" position="float"><label>Table 1.</label>
<caption><p>Main symbols used in this paper.</p>
</caption>
<table frame="hsides" rules="groups"><thead><tr><th valign="middle" align="center" rowspan="1" colspan="1"><bold>Symbols</bold>
</th>
<th valign="middle" align="center" rowspan="1" colspan="1"><bold>Meaning</bold>
</th>
</tr>
</thead>
<tbody><tr><td valign="top" align="center" rowspan="1" colspan="1">λ<italic><sub>l</sub>
</italic>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Traffic generation probability at CoAP layer</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1">α<italic><sub>l,j</sub>
</italic>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Busy channel probability of node l at the backoff stage j</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1"><inline-formula><mml:math id="mm43"><mml:mrow><mml:msub><mml:mover accent="true"><mml:mi>α</mml:mi>
<mml:mo>¯</mml:mo>
</mml:mover>
<mml:mi>l</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Average busy channel probability for all backoff stages</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1"><italic>τ<sub>l</sub>
</italic>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Channel access probability of node l</td>
</tr>
<tr><td valign="top" align="left" rowspan="1" colspan="1"><inline-formula><mml:math id="m44"><mml:mrow><mml:msubsup><mml:mtext>b</mml:mtext>
<mml:mrow><mml:mn>0</mml:mn>
<mml:mo>,</mml:mo>
<mml:mn>0</mml:mn>
<mml:mo>,</mml:mo>
<mml:mn>0</mml:mn>
</mml:mrow>
<mml:mrow><mml:mo stretchy="false">(</mml:mo>
<mml:mtext>l</mml:mtext>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
</mml:msubsup>
</mml:mrow>
</mml:math>
</inline-formula>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Idle probability of node l</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1">c</td>
<td valign="top" align="left" rowspan="1" colspan="1">Maximum number of CoAP retransmissions</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1">m<sub>0</sub>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Initial backoff exponent macMinBE</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1">m<sub>B</sub>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Maximum backoff exponent macMaxBE</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1">m</td>
<td valign="top" align="left" rowspan="1" colspan="1">Maximum number of backoff macMaxCSMABackoffs</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1">n</td>
<td valign="top" align="left" rowspan="1" colspan="1">Maximum number of MAC retransmissions macMaxFrameRetries</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1"><italic>q<sub>l</sub>
</italic>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Probability of generating the first fragment or block of an update at node l</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1"><italic>S<sub>b</sub>
</italic>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Backoff unit time aUnitBackoffPeriod</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1">N</td>
<td valign="top" align="left" rowspan="1" colspan="1">Number of nodes in the network</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1">F</td>
<td valign="top" align="left" rowspan="1" colspan="1">Number of 6LoWPAN fragments composing an update</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1">B</td>
<td valign="top" align="left" rowspan="1" colspan="1">Number of CoAP blocks composing an update</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1">L</td>
<td valign="top" align="left" rowspan="1" colspan="1">Fragment or block size</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1">L<sub>ACK</sub>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">CoAP ACK size</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1">L<sub>MAC ACK</sub>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">MAC ACK size</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1"><italic>L<sub>eq</sub>
</italic>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Vulnerability window for the CCA</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1"><italic>P<sub>coll,l</sub>
</italic>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Collision probability of node l</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1">P<sub>frame,l</sub>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Probability that the transmission of a block, fragment or CoAP ACK for node l fails</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1">P<sub>cf,l</sub>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Probability for node l that the frame is discarded due to channel access failure</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1">P<sub>cr,l</sub>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Probability for node l of a frame to be discarded due to MAC retry limit</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1">P<sub>block,l</sub>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Probability that a single block fails at node l</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1">P<sub>frag,l</sub>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Probability that a 6LoWPAN fragmented update fails at node l</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1">P<sub>errblock,l</sub>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Probability that a block is retransmitted at node l</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1">P<sub>errfrag,l</sub>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Probability that a 6LoWPAN fragmented update is retransmitted at node l</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1">P<sub>ackblock,l</sub>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Probability that the transmission of the CoAP ACK relative to a block transmission fails</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1">P<sub>ackfrag,l</sub>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Probability that the transmission of the CoAP ACK relative to a 6LoWPAN fragmented update fails</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1"><italic>P<sub>failblock,l</sub>
</italic>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Probability that an update sent using blockwise transfer fails</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1"><italic>P<sub>failfrag,l</sub>
</italic>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Probability that an update sent using 6LoWPAN fragmentation fails</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1"><italic>R<sub>block,l</sub>
</italic>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">End-to-end reliability for blockwise transfer</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1"><italic>R<sub>frag,l</sub>
</italic>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">End-to-end reliability for 6LoWPAN fragmentation</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1"><italic>D<sub>frag,l</sub>
</italic>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Delay of a successful received 6LoWPAN fragmented update</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1"><italic>D<sub>block,l</sub>
</italic>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Delay of a successful received update using blockwise transfer</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1"><italic>D<sub>frame,l</sub>
</italic>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Delay for successfully received frame</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1"><italic>D<sub>ACK,l</sub>
</italic>
</td>
<td valign="top" align="left" rowspan="1" colspan="1">Delay for successfully received CoAP ACK</td>
</tr>
<tr><td valign="top" align="center" rowspan="1" colspan="1">RTO</td>
<td valign="top" align="left" rowspan="1" colspan="1">CoAP retransmission timeout</td>
</tr>
</tbody>
</table>
</table-wrap>
</floats-group>
</pmc>
</record>
Pour manipuler ce document sous Unix (Dilib)
EXPLOR_STEP=$WICRI_ROOT/Ticri/CIDE/explor/TelematiV1/Data/Pmc/Corpus
HfdSelect -h $EXPLOR_STEP/biblio.hfd -nk 000549 | SxmlIndent | more
Ou
HfdSelect -h $EXPLOR_AREA/Data/Pmc/Corpus/biblio.hfd -nk 000549 | SxmlIndent | more
Pour mettre un lien sur cette page dans le réseau Wicri
{{Explor lien |wiki= Ticri/CIDE |area= TelematiV1 |flux= Pmc |étape= Corpus |type= RBID |clé= PMC:4179025 |texte= Analytical Model of Large Data Transactions in CoAP Networks }}
Pour générer des pages wiki
HfdIndexSelect -h $EXPLOR_AREA/Data/Pmc/Corpus/RBID.i -Sk "pubmed:25153143" \ | HfdSelect -Kh $EXPLOR_AREA/Data/Pmc/Corpus/biblio.hfd \ | NlmPubMed2Wicri -a TelematiV1
![]() | This area was generated with Dilib version V0.6.31. | ![]() |