Internet DRAFT - draft-3k1n-6tisch-alice0

draft-3k1n-6tisch-alice0



6TiSCH Working Group                                    Seo Hyang Kim
Internet-Draft                              Seoul National University
Intended status: Standards Track                           Na Eon Kim
Expires: June 17, 2017                      Seoul National University
                                                       Nguyen Duc Lam
                                            Seoul National University
                                                       Chong Kown Kim
                                            Seoul National University
                                                    December 15, 2016


                 Autonomous Link-based TSCH Cell Scheduling
                        draft-3k1n-6tisch-alice0-01

Abstract

   This document describes the limitation of present TSCH cell 
   scheduling methods which use centralized or decentralized approach. 
   It firstly overview pros and cons of various cell scheduling 
   approaches including centralized, decentralized and autonomous TSCH 
   cell scheduling methods. It also suggest design considerations on 
   devising autonomous scheduling approach to avoid unexpected 
   confliction and increase channel utilization. For the last, it 
   provides one example that reflects all design considerations 
   mentioned. 


Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts. The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-Drafts
   as reference material or to cite them other than as
   "work in progress."

   This Internet-Draft will expire on June 17, 2017.











Kim, et al.               Expires June 17, 2017                [page 1]


Internet-Draft                   ALICE                    December 2016

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . .. . . . . .  3
 2.  Requirements Language . . . . . . . . . . . . . . . . . . . . .  3
 3.  Terminology. . . . . . . . . . . . . . . . . . . . . . . .  . .  3
 4.  TSCH Cell Scheduling. . . . . . . .. . . . .  . . . . . . . . .  3
      4.1.  Centralized Approach . . . . . . . . . . . . . . . . . .  4
      4.2.  Decentralized Approach. .  . . . . . . . . . . . . . . .  5
      4.3.  Autonomous Approach . . .  . . . . . . . . . . . . . . .  5
 5.  Design Considerations for Autonomous TSCH Cell Scheduling . . .  6
      5.1.  Link-based scheduling  . . . . . . . . . . . . . . . . .  6
      5.2.  Hop-count-based scheduling . . . . . . . . . . . . . . .  7
      5.3.  SlotframeID . . . . . . .  . . . . . . . . . . . . . . .  7
      5.4.  Upstream: link-based, Downstream: node-based . . . . . .  7
      5.5.  Upstream downstream scheduling . . . . . . . . . . . . .  8
 6.  ALICE overview  . . . . . . . . . .. . . . .  . . . . . . . . .  8
      6.1.  Link-based scheduling  . . . . . . . . . . . . . . . . .  9
      6.2.  Hop-count-based scheduling . . . . . . . . . . . . . . .  9
      6.3.  SlotframeID . . . . . . .  . . . . . . . . . . . . . . .  9
      6.4.  Upstream: link-based, Downstream: node-based . . . . . . 10
      6.5.  Upstream downstream scheduling . . . . . . . . . . . . . 10 
 7.  ALICE details . . . . . . . . . . . . . . . . . . . . . . . . . 10 
      7.1. Upstream cell scheduling. . . . . . . . . . . . . . . . . 11
           7.1.1. Recieve scheduling . . . . . . . . . . . . . . . . 11
           7.1.2. Send scheduling. . . . . . . . . . . . . . . . . . 11
      7.2. Downstream cell scheduling. . . . . . . . . . . . . . . . 11 
           7.2.1. Recieve scheduling . . . . . . . . . . . . . . . . 11
           7.2.2. Send scheduling. . . . . . . . . . . . . . . . . . 11
      7.3. Upstream and Downstream Scheduling. . . . . . . . . . . . 12
 8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 
 9.  Security Considerations . . . . . . . . . . . .  . . .  . . . . 12
10.  Acknowlegement. . . . . . . . . . . . . . . . .  . . .  . . . . 12
11.  References. . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     11.1.  Normative References. . . . . . . . . .. . . . . . . . . 13 
     11.2.  Informative References. . . . . .. . . . .   . . . . . . 13
 Authors' Addresses . . . . . . . . . . . . . . . . . . . . .. . . . 14


Kim, et al.               Expires June 17, 2017                [page 2]


Internet-Draft                   ALICE                    December 2016

1. Introduction

   In the communication using TSCH, multiple channels can be used 
   simultaneously and channel hopping is used. It is different from 
   traditional ZigBee communication. With increasing interest on IoT 
   network, various TSCH cell scheduling method has been provided. This
   document describes the limitation of present TSCH cell scheduling 
   methods which mainly use centralized or decentralized approach. It 
   firstly overview pros and cons of various cell scheduling approaches
   including centralized, decentralized and autonomous TSCH cell 
   scheduling methods. 

   Specifically, this document focus on autonomous approach. The biggest
   benefits of autonomous scheduling method is its simple and light 
   scheduling without any negotiation and its quick response to the 
   sudden network changes. 

   This document also suggest design considerations on devising 
   autonomous scheduling approach to avoid unexpected confliction and 
   increase channel utilization. For the last, it provides one example 
   that reflects all design considerations mentioned: Autonomous Link-
   based TSCH Cell Scheduling (ALICE).


2. Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC 2119].


3. Terminology

   Cell : This document follows the same definition used in [RFC 7554]

   ASN : This document follows the same definition used in [RFC 7554]

   Slotframe : This document follows the same definition used in 
   [RFC 7554]

   LinkNum : In the IoT sensor network, nodes and links form a graph and
   each link has a node at both ends. LinkNum of specific link is 
   defined as the sum of NodeIDs of two connected nodes with that link.

   SlotframeID : ID of the slotframe in the TSCH network. 


4.TSCH cell scheduling

   Regarding TSCH cell scheduling, detailed description is provided in 
   [RFC 7554]. Here, we briefly overview important characteristics used
   in this document.

Kim, et al.               Expires June 17, 2017                [page 3]


Internet-Draft                   ALICE                    December 2016

     chOff	^		Slotframe
	|	
     -	+-----------------------------------------+
     |	|      |   B  |      |      |      |      |
     |	+-----------------------------------------+
     |	|      |      |  C   |      |      |      |
   M |	+-----------------------------------------+
     |	|      |   F  |      |      |  D,G |      |
     |	+-----------------------------------------+
     |	|   A  |      |      |      |      |   E  |
     _	+-----------------------------------------+---> Time
        ___________________________________________
			     Z

         Figure 1: Structure of TSCH slotframe
 
   
   In the communication using TSCH, multiple channels can be used 
   simultaneously and channel hopping is used. It is different from 
   traditional ZigBee communication. In TSCH, slotframe repeats over 
   time and the slotframe length is defined as the number of time 
   offsets. In Figure 1, one example of TSCH slotframe is described. In
   this example, the number of channel offsets is M=4 and the number of 
   time offsets is Z=6. Z is also a slotframe length. The total number 
   of cells that is available in a slotframe is M*Z=24. In the example,
   only 6 cells are scheduled in the slotframe. If two closely located 
   nodes try to send packets in the same cell, it will conflict and the
   transmission of the both users will fail. So to avoid confliction 
   while achieving high channel utilization and energy efficiency, wise
   and canny scheduling method should be used in TSCH cell scheduling. 
   Present method can be mainly categorized by two major approaches: 
   Centralized and decentralized scheduling.


4.1. Centralized approach

   In the IoT sensor network using centralized TSCH cell scheduling 
   approach, one representative node schedules wakeup and sleep of every
   node in the same network. Since only one node schedules the whole 
   communication in the network, for that node, large amount of 
   information is needed. Depending on the algorithm, various 
   information can be used and an optimized scheduling can be realized.
   However, since only one specific node can execute TSCH cell 
   scheduling, quick action cannot be executed when the network topology
   has been changed suddenly. Moreover, every node has to deliver the 
   information that will be used in the scheduling node, which causes 
   communication overhead using additive energy and bandwidth resources.
   Furthermore, centralized approach takes long time for the 
   initialization.

   * We categorize following kinds of scheduling as centralized 
   approach.

Kim, et al.               Expires June 17, 2017                [page 4]


Internet-Draft                   ALICE                    December 2016

   The network is divided into multiple regions. In each region, one 
   centralized scheduler executes centralized TSCH cell scheduling for 
   every node located in the same region with that node. In this 
   network, though multiple schedulers execute TSCH cell scheduling, it
   is not fully decentralized manner. Rather, it can be viewed as a 
   combination of multiple centralized scheduling.


4.2. Decentralized approach

   In the IoT sensor network using decentralized TSCH cell scheduling 
   approach, every node can schedule their own plan for wakeup and sleep
   time. Each node communicate with their neighbors to avoid confliction 
   caused by simultaneous same channel usage among interfering nodes. To
   implement this network, specific negotiation protocol should be 
   decided. Compared to the centralized approach, each node using the 
   decentralized TSCH cell scheduling approach needs only small amount 
   of information received from their close neighbors. As a result, it 
   is robust for a sudden network change compared to the centralized 
   approach. However, because of the scanty information, decentralized 
   approach lacks visibility on the view of the whole network. 


4.3. Autonomous approach

   Though decentralized approach shows quick response for the sudden 
   changes of network topology, it still needs additive communication 
   for the negotiation between neighbors. In the autonomous approach, 
   no negotiation is needed for the TSCH scheduling. One representative
   method has been proposed in [Orchestra-Sensys15]. They only use 
   information received from RPL routing protocol [RFC 6550]. They do 
   not use additive communication for the negotiation among the 
   neighbors in TSCH cell scheduling. They autonomously calculate their
   own plan on cell usage based on the RPL structure. They use NodeID 
   such as MAC address of their RPL parent node. With this method, 
   node-based cell scheduling is executed. For example, in the 
   receiver-based scheduling, receiving nodes are scheduled on the TSCH
   cells. Scheduled node listen at the corresponding cell and any node 
   who wants to send packet to that node wakeup and send packet to the 
   receiving node at the same cell. Sender-based scheduling executes in
   the similar manner.

   Including the above method [Orchestra-Sensys15], though autonomous 
   TSCH cell scheduling approach also lacks other available information,
   the biggest benefits of this approach is its simple and light 
   scheduling without any negotiation and its quick response to the 
   sudden network changes.






Kim, et al.               Expires June 17, 2017                [page 5]


Internet-Draft                   ALICE                    December 2016

5. Design considerations of autonomous TSCH cell scheduling method

   This section describes the design considerations for autonomous TSCH 
   cell scheduling.

   In the design of TSCH cell scheduling, one of the biggest challenge 
   is to make scheduling by avoiding confliction among interfering 
   nodes. However, since autonomous scheduling does not use any 
   negotiation, it lacks information. In this condition, the thing that 
   autonomous scheduler can do is to reduce the probability of 
   confliction.


				     +---+
				     | A |
				     +---+
				    /	  \
				   /	   \
			      +---+ 	   +---+
			      | B |	   | C |
			      +---+	   +---+
			     /    \	  /     \
			    /	   \	 /	 \
			+---+	+---+   +---+	+---+
			| D |	| E |	| F |	| G |
			+---+	+---+   +---+	+---+
			/   \	/   \	/   \	/   \
			H    I  J    K  L    M  N    O

              Figure 2: Nodes and Links in the Tree Topology


5.1. Link-based scheduling

   Consideration 1: One node cannot receive packets from the two 
   different nodes simultaneously at the same timeslot. For example, in
   the topology described in Figure 2, in the upstream transmission, 
   node B is connected to both node D and node E. If these two child 
   nodes send packets to the node B at the same timeslot, B will fail to
   listen both two packets successfully. In this situation, the link D-B
   and the link E-B can be scheduled in the same channel offset or in 
   the different channel offsets. In the former case, if two child node 
   sends packet simultaneously at the same time offset, two transmission
   will be conflict at the same channel and B cannot receive any packet.
   In the latter case, depending on the node B's selection of the 
   channel offset to listen at, one of the packets sent from the node A 
   or the node B can be received successfully. 






Kim, et al.               Expires June 17, 2017                [page 6]


Internet-Draft                   ALICE                    December 2016

5.2. Hop-count-based scheduling

   Consideration 2: One node cannot listen and send packets 
   simultaneously at the same timeslot. For example, in the topology 
   described in Figure 2, in the upstream, node B is connected to both 
   node A and node D. If the link B-A and the link D-B is scheduled at 
   the same timeslot, node D will send to the node B and the node B will
   send to the node A. However, node D cannot listen and send 
   simultaneously at the same timeslot.


5.3. SlotfrmaeID

   Consideration 3: In the view of one specific node, the scheduling of 
   different slotframes should be changed to avoid consistent 
   confliction. If the scheduling result for a slotframe persists, the 
   conflicting nodes in a cell will conflict again at the next 
   slotframe. For example, in the topology described in Figure 2, in the
   upstream, there are two links B-A and C-A. If these links are 
   scheduled in the same cell and node B and node C send packets to the 
   node A at the same timeslot, two packet transmissions will fail. If 
   this scheduling persist at the next slotframe, the same situation 
   will occur again. 


5.4. Upstream: link-based, Downstream: node-based

   Consideration 4: Cell scheduling method of upstream and downstream 
   should be differentiated. In the case of IoT network, the amount of 
   upstream traffic is much larger than that of downstream traffic. 
   Moreover, if tree topology is used for the routing protocol as 
   described in Figure 2, one node has multiple child nodes and only one
   parent node. In this structure, in the case of upstream, every child 
   node has different packets to send to their parent node. So one node 
   should listen from their multiple child using different cells. 
   However, in the case of downstream, the server may request or respond
   to every node in the network or to the one specific node. Moreover, 
   the amount of downstream packets are smaller than that of upstream 
   packets and the scheduled cell for downstream may not be used with 
   high probability. So, in the topology described in Figure 2, when the
   link B-D and the link B-E is scheduled, scheduling these two links at
   the same cell is more efficient than scheduling these links at the 
   different cells. By doing this, in the case where the server sends 
   one packet to every node in the network, node B can forward this 
   message to all their child nodes at only one transmission. In the 
   other case where the node B sends a packet to one of its child nodes,
   it can send the packet to the specific node while multiple child 
   nodes listen at the same timeslot. 





Kim, et al.               Expires June 17, 2017                [page 7]


Internet-Draft                   ALICE                    December 2016

5.5. Upstream downstream scheduling

   Consideration 5: One node cannot receive or send packets from both 
   their parent node and child node simultaneously. In other words, in 
   the view of one specific node, upstream and downstream can not be 
   happen at the same timeslot. For example, in the topology described 
   in Figure 2, the node B is connected to both node A and node D. If 
   both node A and node D is scheduled to send packets to the node B at
   the same timeslot, or the node B is scheduled to send packets to the
   node A and the node D at the same timeslot as a result of cell 
   calculation by using autonomous scheduling method, at least one 
   transmission will fail since node B cannot receive different packets
   from the different nodes and send different packets to the different 
   nodes.


6. ALICE overview

   In this section, we define Autonomous LInk-based tsch CEll 
   scheduling (ALICE). This scheduling method reflects 5 design 
   considerations described above. To use autonomous scheduling 
   approach, ALICE utilizes limited information on the basis of RPL 
   routing topology as shown in [Orchestra-Sensys15]. By using all 3 
   types of RPL messages (DIS, DIO and DAO), each node using ALICE knows
   NodeID (e.g. MAC address) of their parent and child nodes. They use 
   another information such as Absolute Slot Number (ASN) and RPL 
   hop-count.


	  chOff	^		  Slotframe
		|	Even Rank    ||      Odd Rank      |
	 -	+--------------------||--------------------+
	 |	| L->F | C->A | M->F || F->C |      |      |
	 |	|      |      |      ||      |      |      |
	 |	+--------------------||--------------------+
	 |	| I->D |      | J->E ||      | G->C |      |
	 |	|      |      | O->G ||      |      |      |
       M |	+--------------------||--------------------+
	 |	|      | H->D |      ||      | D->B |      |
	 |	|      |      |      ||      |      |      |
	 |	+--------------------||--------------------+
	 |	| B->A |      | N->G ||      |      | E->B |
	 |	| K->E |      |      ||      |      |      |
	 -	+--------------------||--------------------+---> Time
		|__________________________________________|
			              Z

        Figure 3: Autonomous Link-based TSCH Cell Scheduling (ALICE)





Kim, et al.               Expires June 17, 2017                [page 8]


Internet-Draft                   ALICE                    December 2016

6.1. Link-based scheduling

   In ALICE, the tree topology is used for the routing protocol as RPL 
   is used together with TSCH. In its TSCH cell scheduling, every link 
   in the tree topology is scheduled at least once a slotframe. For 
   example, in Figure 2, there are 13 links and each link is scheduled 
   in a cell in a slotframe as described in Figure 3. Since ALICE uses 
   link-based scheduling, we allocate LinkNum to every link. LinkNum is
   the sum of NodeIDs of two connected nodes with that link. For 
   example, in the Figure 2, node A and node B is connected with the 
   link A-B. Then, LinkNum of the link A-B is the sum of NodeID of node
   A and that of node B. By using the value of LinkID, nodes in the 
   network autonomously calculate their plan for wakeup and sleep time.


6.2. Hop-count-based scheduling

   By using hop-count-based scheduling, ALICE avoids the situation where
   one node listens and sends simultaneously. With RPL, every node knows
   their own hop-count. In this document, we call hop-count as rank. 
   Multiple cells in a slotframe is grouped into two different sections.
   Even rank nodes are scheduled in the cells in the first section and 
   the odd rank nodes are scheduled in the the cells in the second 
   section. 


6.3. SlotframeID

   In ALICE scheduling, every slotframe has different cell scheduling 
   results since ALICE uses SlotframeID in their autonomous scheduling 
   algorithm. SlotframeID increases with time. SlotframeID is calculated
   by flooring ASN%Z.

   SlotframeID = floor(ASN%Z)

   As Figure 4 describes, as SlotframeID changes, the result of cell 
   scheduling becomes completely different.

                ^
         chOff  |
                +-----------------------------------------------+
                |   | B |   |   |   |   |F  |   |   |D  |   |   |
                +-----------------------------------------------+
  	        |   |   |C  |   |   |   |   |A  |   |   |   |   |
                +-----------------------------------------------+
	        |   | F |   |   |D,G|   |   |   |   |   |E  |   |
                +-----------------------------------------------+
     #chOff=0   |A  |   |   |   |   |E  |C  |   |B  |   |   |G  |
                +-----------------------------------------------+-->Time
	        |-----------------------|-----------------------|
		  	    Z   		     Z
 Figure 4: Differenct slotframes have different cell scheduling results

Kim, et al.               Expires June 17, 2017                [page 9]


Internet-Draft                   ALICE                    December 2016

6.4. Upstream: link-based, Downstream: node-based

   ALICE uses different scheduling style for uplink and downlink 
   streams. For the upstream, it has link-based scheduling approach and
   for the downstream, it has node-based scheduling approach as 
   [Orchestra-Sensys15].


6.5. Upstream downstream scheduling

   Since the amount of upstream traffic is much more than that of 
   downstream traffic, ALICE give more chance for the upstream traffic 
   compared to the downstream traffic in its cell scheduling. For 
   example, with the length K for a slotframe-cycle, K-1 slotframes are
   allocated for the upstream and 1 slotframe is allocated for the 
   downstream. More specific example is described in Figure 5. If K=3, 
   2 slotframes are allocated for the upstream and 1 slotframe is 
   allocated for the downstream.


        ^				   	  [ K=3 ]
  chOff |
        +-----------+-----------+-----------++-----------+--
        |   | B |   |   | C | D | C |   | B || A |   | E |
        +------------------------------------------------+--
	| E | C |   |   |A,B|   | E |   | A ||   | C |   |
	+------------------------------------------------+--
     0	| A |	| D | E |   | 	|   | D |   ||	 | B | D |
	+-----------+-----------+-----------++-----------+---->Time

	|-----Z-----+-----Z-----|-----Z-----||-----Z-----|--
	|........uplink.........|..downlink.||......uplink..	
     	|______________1cycle_______________||______1cycle__

           Figure 5: Upstream and Downstream Scheduling 


7. ALICE details

   In this section, we define ALICE scheduling details. In the network 
   with ALICE, every node has ALICE scheduler and calculates specific 
   cells for send or receive packets autonomously on the basis of 
   LinkNum, SlotframeID and Rank. As defined above, LinkNum of one link
   is defined on the basis of NodeID of two nodes that is connected with
   that link. SlotframeID is on the basis of ASN. To calculate the 
   specific ChannelOffset and the TimeOffset, ALICE uses hash function 
   as [Orchestra-Sensys15] does. 
   Here, we use M and Z for the number of channel offsets and the number
   of time offsets in a slotframe, respectively. 




Kim, et al.               Expires June 17, 2017               [page 10]


Internet-Draft                   ALICE                    December 2016

7.1. Upstream cell scheduling

   In the upstream traffic, a node receives packets from its child nodes
   and sends packet to its parent node. Upstream cell scheduling is done
   only in the upstream period.


7.1.1. Receive Scheduling

   TimeOffset = (NodeRank%2)*(Z/2) +Hash(NodeID+ChildID+SlotframeID)
                %(Z/2)

   ChannelOffset = Hash(ChildID+SlotframeID)%M


7.1.2. Send Scheduling

   TimeOffset = (ParentRank%2)*(Z/2) + Hash(ParentID+NodeID+SlotframeID)
                 %(Z/2)

   ChannelOffset = Hash(NodeID+SlotframeID)%M


7.2. Downstream cell scheduling

   In the downstream traffic, a node receives packet from its parent 
   node and sends packet to its child nodes. Downstream cell scheduling
   is done only in the downstream period.


7.2.1. Receive Scheduling

   TimeOffset = (ParentRank%2)*(Z/2) + Hash(ParentID+SlotframeID)%(Z/2)
   ChannelOffset = Hash(ParentID+SlotframeID)%M


7.2.2. Send Scheduling

   TimeOffset = (NodeRank%2)*(Z/2) + Hash(NodeID+SlotframeID)%(Z/2)

   ChannelOffset = Hash(NodeID+SlotframeID)%M












Kim, et al.               Expires June 17, 2017               [page 11]


Internet-Draft                   ALICE                    December 2016

7.3. Upstream and Downstream Scheduling

   K is the number of slotframes in a group that is composed multiple 
   slotframes during a pair of one upstream period and one downstream 
   period. In other words, in each cycle, one downstream period and one
   upstream period are shown. Since the amount of upstream traffic is 
   much more than that of downstream traffic, the number of cells for 
   the upstream traffic should be larger than that of downstream 
   traffic. Since the number of cells in a timeslot does not change, 
   longer time is allocated for the upstream period compared to 
   downstream period. During the upstream period, upstream cell 
   scheduling is executed and during the downstream period, downstream 
   cell scheduling is executed. Decision of upstream and downstream 
   period is simple as follows. The algorithm is on the basis of 
   SlotframeID and the parameter K.

  	 If (SlotframeID%K==0) 
    	  	Downstream period
  	 Else
     		Upstream period
  	 End


8. IANA Considerations

   There are no IANA considerations related to this document.


9. Security Considerations

   Autonomous TSCH cell scheduling method has similar requirements on 
   security as [RFC7554].


10. Acknolwedgement

   This work was supported by Institute for Information & communications
   Technology Promotion(IITP) grant funded by the Korea government(MSIP)
   (No.B0190-16-2017,Resilient/Fault-Tolerant Autonomic Networking Based
   on Physicality, Relationship and Service Semantic of IoT Devices), 
   the MSIP(Ministry of Science, ICT and Future Planning), Korea, under
   the ITRC(Information Technology Research Center) support program 
   (IITP-2016-R0992-16-1023) supervised by the IITP(Institute for 
   Information & communications Technology Promotion and the National 
   Research Foundation of Korea(NRF) Grant funded by the Korean 
   Government(MSIP) (No.2016R1A5A1012966).







Kim, et al.               Expires June 17, 2017               [page 12]


Internet-Draft                   ALICE                    December 2016

11. Reference

11.1. Normative References

   [RFC 7554] T. Watteyne, Ed., L. Grieco, "Using IEEE 802.15.4e 
              Time-Slotted Channel Hopping (TSCH) in the Internet of 
              Things (IoT): Problem Statement", RFC 7554, May 2015

   [RFC 6550] T. Winter, Ed., P. Thubert, Ed., A. Brandt, J. Hui, 
              R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur,
              R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power 
              and Lossy Networks", RFC 6550, March 2012


11.2. Informative References

   [Orchestra-Sensys15] Duquennoy, Simon, et al. "Orchestra: Robust mesh
                        networks through autonomously scheduled TSCH." 
                        Proceedings of the 13th ACM Conference on 
                        Embedded Networked Sensor Systems. ACM, 2015.






























Kim, et al.               Expires June 17, 2017               [page 13]


Internet-Draft                   ALICE                    December 2016

Authors' Addresses

Seo Hyang Kim
Department of Computer Science and Engineering
Seoul National University
Seoul, South Korea

Phone: +82 (0)2 880 1858
Email: shkim@popeye.snu.ac.kr


Na Eon Kim
Department of Computer Science and Engineering
Seoul National University
Seoul, South Korea

Phone: +82 (0)2 880 1858
Email: nekim@popeye.snu.ac.kr


Nguyen Duc Lam
Department of Computer Science and Engineering
Seoul National University
Seoul, South Korea

Phone: +82 (0)2 880 1858
Email: lam@popeye.snu.ac.kr


Chong Kwon Kim
Department of Computer Science and Engineering
Seoul National University
Seoul, South Korea

Phone: +82 (0)2 880 1858
Email: ckim@snu.ac.kr

















Kim, et al.               Expires June 17, 2017               [page 14]