One document matched: draft-dujovne-6tisch-on-the-fly-02.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes" ?>

<rfc category="info" ipr="trust200902" docName="draft-dujovne-6tisch-on-the-fly-02">
<front>
   <title abbrev="6tisch-on-the-fly">
      6TiSCH On-the-Fly Scheduling
   </title>
   <author initials="D" surname="Dujovne" fullname="Diego Dujovne" role="editor">
      <organization>Universidad Diego Portales</organization>
      <address>
         <postal>
            <street>Escuela de Informatica y Telecomunicaciones</street>
            <street>Av. Ejercito 441</street>
            <city>Santiago</city>
            <region>Region Metropolitana</region>
            <country>Chile</country>
         </postal>
         <phone>+56 (2) 676-8121</phone>
         <email>diego.dujovne@mail.udp.cl</email>
      </address>
   </author>
   <author initials="LA" surname="Grieco" fullname="Luigi Alfredo Grieco">
      <organization>Politecnico di Bari</organization>
      <address>
         <postal>
            <street>Department of Electrical and Information Engineering</street>
            <street>Via Orabona 4</street>
            <city>Bari</city>
            <code>70125</code>
            <country>Italy</country>
         </postal>
         <phone>00390805963911</phone>
         <email>a.grieco@poliba.it</email>
      </address>
   </author>
   <author initials="MR" surname="Palattella" fullname="Maria Rita Palattella">
      <organization>University of Luxembourg</organization>
      <address>
         <postal>
            <street>Interdisciplinary Centre for Security, Reliability and Trust</street>
            <street>4, rue Alphonse Weicker </street>
            <city>Luxembourg</city>
            <code>L-2721 </code>
            <country>LUXEMBOURG</country>
         </postal>
         <phone>(+352) 46 66 44 5841</phone>
         <email>maria-rita.palattella@uni.lu</email>
      </address>
   </author>
   <author initials="N" surname="Accettura" fullname="Nicola Accettura">
      <organization>Politecnico di Bari</organization>
      <address>
         <postal>
            <street>Electrical and Electronics Department</street>
            <street>Via Orabona 4</street>
            <city>Bari</city>
            <code>70125</code>
            <country>Italy</country>
         </postal>
         <phone>+39 080 5963301</phone>
         <email>n.accettura@poliba.it</email>
      </address>
   </author>
   <date/>
   <area>Internet Area</area>
   <workgroup>6TiSCH</workgroup>
   <keyword>Draft</keyword>
   <abstract>
      <t>
         This document describes the environment, problem statement, and goals of the On-The-Fly (OTF) scheduling approach for the IEEE802.15.4e TSCH MAC protocol in the context of LLNs. The purpose of OTF is to dynamically adapt the aggregate bandwidth, i.e., the number of reserved soft cells between neighbor nodes, based on the specific application constraints to be satisfied. The soft cell and Bundle reservation with OTF is distributed: through the 6top interface, neighbor nodes negotiate the cell(s) to be (re)allocated/deleted, without intervention of a centralized entity. This document aims at defining a module which uses the functionalities provided by the 6top sublayer to (i) extract statistics and (ii) determine when to reserve/delete soft cells in the schedule. The exact reservation and deletion algorithm, and the number and type of statistics to be used in the algorithm are out of scope. OTF deals only with the number of soft cells to be reserved/deleted; it is up to 6top to select the specific soft cells within the TSCH schedule.
      </t>
   </abstract>
</front>
<middle>
   <section title="Introduction">
      <t>
         The IEEE802.15.4e standard <xref target="IEEE802154e"/> was published in 2012 as an amendment to the Medium Access Control (MAC) protocol defined by the IEEE802.15.4-2011 <xref target="IEEE802154"/> standard. The Timeslotted Channel Hopping (TSCH) mode of IEEE802.15.4e is the object of this document.
      </t>
      <t>
         On-The-Fly (OTF) scheduling is a distributed protocol in which a node negotiates the number of soft cells scheduled with its neighbors, without the intervention of a centralized entity (e.g., a PCE). In particular, this document describes the OTF allocation policies and methods used for allocating single soft cell or group of them (i.e. bundle) between two neighbors. It also proposes some potential algorithms for estimating the required bandwidth. In this document, internal interface used between OTF and the 6top sublayer (<xref target="I-D.wang-6tisch-6top"/>) is defined, with a particular focus on the functionalities. Example functionalities are collecting and providing statistic information, or allocating/deleting cells and bundles. To be extensible and applicable to different scenarios, this draft is a generic framework. The exact algorithm and set of statistics used for estimating the requested bandwidth is out of scope. This draft follows the terminology defined in <xref target="I-D.ietf-6tisch-terminology"/> and addresses the open issue related to the scheduling mechanisms raised in <xref target="I-D.ietf-6tisch-tsch"/>.
      </t>
   </section>
   <section title="Allocation policy">
      <t>
         OTF is a distributed scheduling protocol which sends scheduling requests to the 6top sublayer. OTF thereby dynamically increases/decreases the bandwidth allocated between neighbor nodes. 6top takes care of negociating the soft cells between neighbors. Because OTF delegates the selection of the specific cells to 6top, OTF only supports soft cell reservation. Therefore, the term "cell" is synonymous to "soft cell" in this document.
      </t>
      <t>
         OTF is prone to schedule collision. Nodes might not be aware of the cells allocated by other pairs of neighbors nodes. A collision occurs when the same cell is allocated by different pairs in the same interference space. The 6top sublayer cannot differentiate collisions from other sources of packet loss. The probability of having allocation collision may be kept low by grouping cells into chunks (see <xref target="I-D.ietf-6tisch-terminology"/> and  <xref target='I-D.ietf-6tisch-architecture'/> for more details). The use of chunks is outside the scope of this current version of the OTF draft.
         <!-- without the supervision of a PCE that is aware of the whole TSCH network schedule. -->
         <!-- OTF keeps track of the soft cell and Bundle scheduling. -->
      </t>
      <t>
         We call "allocation policy" the approach used by OTF for increasing or decreasing the bandwidth allocated between two nodes in order to satisfy the traffic requirements. These requirements can be expressed in terms of throughput, latency or other constraints.
      </t>
      <t>
         OTF supports 3 different types of allocation policies: Post-allocation, Pre-allocation and Hybrid allocation.
      </t>
      <t>
         Post-allocation policy is based on a "recovery" approach following the increased/decreased need of bandwidth. Upon reception of a bandwidth request, OTF sends soft cell allocation requests to the 6top sublayer. OTF has to estimate the number of cells to be allocated per each neighbor. OTF keeps track of such information. If afterwards, it is possible to free some cells (due for instance to the reduction of traffic exchanged between two neighbors), OTF asks 6top to de-allocate a given number of cells. Once the cells have been deleted and 6top has notified the event to OTF, the latter can update its internal cell allocation tables.
      </t>
      <t>
         Pre-allocation policy is based on a "provision" approach. This implies that the reservation of groups of equivalents cells (i.e., bundles), to a given couple of nodes, is done in advance. When OTF sends a bundle allocation requests to 6top, it has to indicate the desired size of the bundle and the TrackID. These are the only features that can be settled by OTF. 6top selects the soft cells belonging to the bundle. Based on the network traffic condition (e.g. queue utilization), a number of cells within the bundle is used for communication. In any case, allocated cells within a bundle are consecutive, starting from the first cell in the block. The cells which are not currently used, are still reserved for that pair of nodes, for possible future use.
      </t>
      <t>
         OTF keeps track of the scheduled bundles, the bundle size, and the estimated number of allocated cells within a bundle. Based on this information, upon reception of a bandwidth request, OTF may ask 6top to increase or decrease the bundle size.
      </t>
      <t>
         The post-allocation policy compared to the pre-allocation reduces the energy consumption, by allocating the exact number of soft cells when they are needed, but at the expense of increased cell allocation latency. In fact, for each requested soft cell, the 6top layer has to negotiate the request with the 6top layer of the neighbor node. Such negotiation takes some time and induces communication overhead.
         <!-- On the other side, as already said, the post-allocation policy reduce the energy consumption, because the node asking more bandwith, can keep its receiver module ON, only during the allocating soft cells, thus saving energy. -->
      </t>
      <t>
         The pre-allocation policy compared to the post-allocation reduces the cell allocation latency. The soft cells within the bundle are over-provisioned, and a priori scheduled. When needed, the 6top sublayer of the node can allocate them, without going through any negotiation phase with the 6top layer of the neighbor node. Thus, the pre-allocation approach provides a low-delay response after a surge in bandwidth usage. In fact, soft cells within a bundle are already scheduled and become immediately available, upon bandwidth request, without the need of a negotiation phase. The use of bundles does force the receiver module of the node to be active during the whole length of the Bundle, thus implying increased power consumption.
      </t>
      <t>
         The hybrid allocation policy is a mix of the pre- and post- allocation policy. It tries to take advantage of both the "provision" and "recovery" approaches. Some bundles can be reserved in advance for a pair of nodes. After receiving a bandwidth request, OTF can decide if asking to 6top for (new) soft cell allocation (as per post-allocation approach, implying a negotiation phase among the neighbor nodes), or for bundle allocation/resizing (as per pre-allocation approach). In fact, tt is possible that more bandwidth is needed, but there are still some cells within the bundle that have not been allocated yet, and that they can be used for fulfilling the request. If all the cells within the bundle have already been allocated, OTF has to send a bundle size increase request to 6top (that still translates in soft cells allocation request).
      </t>
   </section>
   <section title="Allocation methods">
      <!-- Description of the methods needed for each allocation policy to access the 6top functionalities and the info stored on OTF -->
      <t>
         Beyond the allocation policies that describe the approach used by OTF for fulfilling the node bandwidth requests, the OTF framework also includes Allocation Methods that specify how OTF actually asks the 6top sublayer to satisfy the aforementioned requests. In other words, the allocation methods represent the mechanisms that are used by the allocation policies to pre- or post- allocate extra bandwidth.
      </t>
      <t>
         In detail, OTF includes two distinct allocation methods: soft cell and bundle allocation methods. Each Allocation Policy can use either one or both allocation methods. As specified in <xref target="I-D.wang-6tisch-6top"/>, 6top provides a set of commands that allows to schedule/allocate/delete soft cells. The same set of commands can be used for reserving bundles.
      </t>
      <t>
         With the soft cell allocation method, OTF asks 6top to reserve a single soft cell, for communicating with a specific neighbour node, on a given track. The 6top layer allocates and maintains such cell. It has to be noticed that if a bundle (i.e., a group of cells) was already reserved between the same couple of nodes, on the same track, then, such soft cell allocation request translates into a bundle resize request. In fact, the new allocated cell will increase the size of the already exsisting bundle. In a similar way, when OTF realizes that there is a reduction of traffic exchanged between the two neighbors, it may asks 6top to delete a soft cell, in other words, to decrease the bundle size. Instead, if no bundle with the same TrackID already existed, then the 6top soft cell create command will generate a new bundle of size 1, having the specified TrackID.
      </t>
      <t>
         With the bundle allocation method, OTF sends bundle allocation requests to 6top sublayer, specifying the bundle size (i.e., number of soft cells forming the bundle itself) and the TrackID of the track to which the cells belong. By using the soft cells commands 6top generates the bundle. In fact, the request of scheduling N soft cell is equivalent to asking for a bundle of size N. The cells within the bundle will be allocated by 6top afterwards, according to the nodes bandwith need.
      </t>
      <!-- Once the bundle is allocated, OTF may ask for sizing/re-sizing BW of a bundle, which implies soft cells are reserved. For this purpose, OTF only calculates the required Bandwidth, and 6top maps the BW to the number of soft cells according to some QoS setting, e.g. over-provision ratio, and finally allocates and maintains them.-->
   </section>
   <!-- Since 6top has already included a MIB and YANG, then the algorithm itself should make the requests directly to 6top -->
   <section title="Input parameters: statistics and instant values">
      <t>
         Short summary of a potential set of statistics and instant values that could be used as input parameters. Direct interaction with 6top.
      </t>
      <t>
         List of parameters available from 6top: mainly statistics related to queues
      </t>
      <t>
         Method to configure 6top to provide historical values for each requested parameter
      </t>
      <t>
         Method to ask 6top for instant values for each requested parameter
      </t>
      <t>
         Method for asking for a list of parameters from 6top and thus, for checking if a parameter is available or not
      </t>
   </section>
   <section title="bundle usage management in OTF: TODO">
      <t>
         Methods that trigger the request of increasing/decreasing the bundle, and thus, adding/deleting cells
      </t>
      <section title="Cell Reservation/Deletion">
         <t>
            The commands to reserve/delete soft cells. Direct interaction with 6top
         </t>
      </section>
      <section title="bundle Size Increase/Decrease">
         <t>
            The commands to increase/decrease the bundle size. Direct interaction with 6top
         </t>
      </section>
   </section>
   <section title="Schedule storage on OTF: TODO ">
      <t>
         The description and access to the schedule storage on OTF
      </t>
      <t>
         The commands to retrieve bundle usage values and statistics from OTF (based on previous values obtained by 6top?)
      </t>
      <!--
      <t>
         The commands to retrieve cell usage values and statistics from OTF (based on previous values obtained by 6top?)
      </t>
      -->
   </section>
   <section title="Bandwidth Estimation Algorithms">
      <!-- MR: I propose to call these mechanisms "Bandwidth estimation algorithms, instead of "Scheduling Algorithm container and selection" what do you think? These algorithms should provide information to OTF about the current traffic condition, and the bandwidth usage (and thus about the new cells to be added, or cells not used to be deleted) Moreover, better we avoid to sue the term mechanisms, because we may create confusion with the allocation mechanisms. -->
      <t>
         OTF supports different bandwidth estimation algorithms that can be used by a node in a 6TiSCH network for checking the current traffic condition and thus the actual bandwidth usage. By doing so, it is possible to adapt (increase or increase) the number of scheduled cells/bundles for a given pair of neighbors (e.g., parent node and its child), according to their needs. OTF supports several bandwidth estimation algorithms numbered from 0 to 255 in the OTF implementation. The first algorithm (0) is reserved to the default algorithm that is described below. By using SET and GET commands, it is possible, to set the specific algorithm to be used, and get information about which algorithm is actualy implemented.
      </t>
      <t>
         The default bandwidth estimation algorithm, running over a parent node, is articulated in the following steps:
         <list hangIndent="6" style="hanging">
            <t hangText="Step 1:">Collect the bandwidth requests from child nodes (incoming traffic).</t>
            <t hangText="Step 2:">Collect the node bandwidth requirement from the application (self/local traffic).</t>
            <t hangText="Step 3:">Collect the current outgoing scheduled bandwidth (outgoing traffic).</t>
            <t hangText="Step 4:">If (outgoing < incoming + self) then SCHEDULE soft cells/bundles to satisfy bandwidth requirements.</t>
            <t hangText="Step 5:">If (outgoing > incoming + self) then DELETE the soft cells that are not used.</t>
            <t hangText="Step 6:">Loop to Step 1.</t>
         </list>
      </t>
      <t>
         Based on the allocation policy that is used, at Step 4 new soft cells will be scheduled, using the cell allocation method. If there are free cells in the bundle that can satisfied the current bandwidth request, such cells will be allocated. In the case of pre-allocation policy, it may happen that the number of allocated cells within the bundle is equal to the bundle size. That is, all the cells within the bundle are currently used. In this case, the node asks 6top for increasing the bundle size by using the bundle allocation method. When the hybrid allocation policy has been selected two options are available: (i) the bundle size is increased, and a number of cells larger than those currently needed, can be scheduled - according to post-allocation approach, or (ii) a number of soft cells equal exactly to those currently needed are scheduled, as per post-allocation approach.
      </t>
   </section>
   <section title="Acknowledgements">
      <t>
         Special thanks to Prof. Kris Pister for his valuable contribution in designing the default Bandwidth Estimation Algorithm, and to Qin Wang for her support in defining the interaction between OTF and 6top sublayer.
	  </t>
	  <t>
         Thanks to the Fondecyt 1121475 Project, to INRIA Chile "Network Design" group and to the IoT6 European Project (STREP) of the 7th Framework Program (Grant 288445).
      </t>
   </section>
</middle>
<back>
   <references title="Informative References">
      <?rfc include='reference.I-D.ietf-6tisch-terminology'?>
      <?rfc include='reference.I-D.ietf-6tisch-architecture'?>
      <?rfc include='reference.I-D.ietf-6tisch-tsch'?>
      <?rfc include='reference.I-D.wang-6tisch-6top'?>
   </references>
   <references title="External Informative References">
      <reference anchor="IEEE802154e">
         <front>
            <title>IEEE std. 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) Amendament 1: MAC sublayer</title>
            <author>
               <organization>IEEE standard for Information Technology</organization>
            </author>
            <date month="April" year="2012"/>
         </front>
      </reference>
      <reference anchor="IEEE802154">
         <front>
            <title>IEEE std. 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks</title>
            <author>
               <organization>IEEE standard for Information Technology</organization>
            </author>
            <date month="June" year="2011"/>
         </front>
      </reference>
      <reference anchor="TASA-PIMRC" target=" http://www.cttc.es/resources/doc/120531-submitted-tasa-25511.pdf">
         <front>
            <title>Traffic Aware Scheduling Algorithm for Multi-Hop IEEE 802.15.4e Networks</title>
            <author initials="MR." surname="Palattella" fullname="Maria Rita Palattella">
               <organization abbrev="UL">SnT/University of Luxembourg</organization>
            </author>
            <author initials="N." surname="Accettura" fullname="Nicola Accettura">
               <organization abbrev="PoliBA">Politecnico di Bari</organization>
            </author>
            <author initials="M." surname="Dohler" fullname="Mischa Dohler">
               <organization abbrev="CTTC">Centre Tecnologic de Telecomunicacions de Catalunya</organization>
            </author>
            <author initials="LA." surname="Grieco" fullname="Luigi Alfredo Grieco">
               <organization abbrev="PoliBA">Politecnico di Bari</organization>
            </author>
            <author initials="G." surname="Boggia" fullname="Gennaro Boggia">
               <organization abbrev="PoliBA">Politecnico di Bari</organization>
            </author>
            <date month="Sept." year="2012" />
         </front>
         <seriesInfo name="IEEE PIMRC" value="2012" />
      </reference>
      <reference anchor="DeTAS">
         <front>
            <title>Decentralized Traffic Aware Scheduling for Multi-hop Low Power Lossy Networks in the Internet of Things</title>
            <author initials="N." surname="Accettura" fullname="Nicola Accettura">
               <organization abbrev="PoliBA">Politecnico di Bari</organization>
            </author>
            <author initials="MR." surname="Palattella" fullname="Maria Rita Palattella">
               <organization abbrev="UL">SnT/University of Luxembourg</organization>
            </author>
            <author initials="G." surname="Boggia" fullname="Gennaro Boggia">
               <organization abbrev="PoliBA">Politecnico di Bari</organization>
            </author>
            <author initials="LA." surname="Grieco" fullname="Luigi Alfredo Grieco">
               <organization abbrev="PoliBA">Politecnico di Bari</organization>
            </author>
            <author initials="M." surname="Dohler" fullname="Mischa Dohler">
               <organization abbrev="CTTC">Centre Tecnologic de Telecomunicacions de Catalunya</organization>
            </author>
            <date month="June" year="2013" />
         </front>
         <seriesInfo name="IEEE WoWMoM" value="2013" />
      </reference>
   </references>
</back>
</rfc>