idnits 2.17.1 draft-3k1n-6tisch-alice0-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 61 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 15, 2016) is 2688 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2119' is mentioned on line 124, but not defined == Missing Reference: 'RFC7554' is mentioned on line 547, but not defined ** Downref: Normative reference to an Informational RFC: RFC 7554 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 6TiSCH Working Group Seo Hyang Kim 2 Internet-Draft Seoul National University 3 Intended status: Standards Track Na Eon Kim 4 Expires: June 17, 2017 Seoul National University 5 Nguyen Duc Lam 6 Seoul National University 7 Chong Kown Kim 8 Seoul National University 9 December 15, 2016 11 Autonomous Link-based TSCH Cell Scheduling 12 draft-3k1n-6tisch-alice0-01 14 Abstract 16 This document describes the limitation of present TSCH cell 17 scheduling methods which use centralized or decentralized approach. 18 It firstly overview pros and cons of various cell scheduling 19 approaches including centralized, decentralized and autonomous TSCH 20 cell scheduling methods. It also suggest design considerations on 21 devising autonomous scheduling approach to avoid unexpected 22 confliction and increase channel utilization. For the last, it 23 provides one example that reflects all design considerations 24 mentioned. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six 37 months and may be updated, replaced, or obsoleted by other 38 documents at any time. It is inappropriate to use Internet-Drafts 39 as reference material or to cite them other than as 40 "work in progress." 42 This Internet-Draft will expire on June 17, 2017. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . .. . . . . . 3 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 63 3. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. TSCH Cell Scheduling. . . . . . . .. . . . . . . . . . . . . . 3 65 4.1. Centralized Approach . . . . . . . . . . . . . . . . . . 4 66 4.2. Decentralized Approach. . . . . . . . . . . . . . . . . 5 67 4.3. Autonomous Approach . . . . . . . . . . . . . . . . . . 5 68 5. Design Considerations for Autonomous TSCH Cell Scheduling . . . 6 69 5.1. Link-based scheduling . . . . . . . . . . . . . . . . . 6 70 5.2. Hop-count-based scheduling . . . . . . . . . . . . . . . 7 71 5.3. SlotframeID . . . . . . . . . . . . . . . . . . . . . . 7 72 5.4. Upstream: link-based, Downstream: node-based . . . . . . 7 73 5.5. Upstream downstream scheduling . . . . . . . . . . . . . 8 74 6. ALICE overview . . . . . . . . . .. . . . . . . . . . . . . . 8 75 6.1. Link-based scheduling . . . . . . . . . . . . . . . . . 9 76 6.2. Hop-count-based scheduling . . . . . . . . . . . . . . . 9 77 6.3. SlotframeID . . . . . . . . . . . . . . . . . . . . . . 9 78 6.4. Upstream: link-based, Downstream: node-based . . . . . . 10 79 6.5. Upstream downstream scheduling . . . . . . . . . . . . . 10 80 7. ALICE details . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 7.1. Upstream cell scheduling. . . . . . . . . . . . . . . . . 11 82 7.1.1. Recieve scheduling . . . . . . . . . . . . . . . . 11 83 7.1.2. Send scheduling. . . . . . . . . . . . . . . . . . 11 84 7.2. Downstream cell scheduling. . . . . . . . . . . . . . . . 11 85 7.2.1. Recieve scheduling . . . . . . . . . . . . . . . . 11 86 7.2.2. Send scheduling. . . . . . . . . . . . . . . . . . 11 87 7.3. Upstream and Downstream Scheduling. . . . . . . . . . . . 12 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 90 10. Acknowlegement. . . . . . . . . . . . . . . . . . . . . . . . 12 91 11. References. . . . . . . . . . . . . . . . . . . . . . . . . . . 13 92 11.1. Normative References. . . . . . . . . .. . . . . . . . . 13 93 11.2. Informative References. . . . . .. . . . . . . . . . . 13 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . .. . . . 14 96 1. Introduction 98 In the communication using TSCH, multiple channels can be used 99 simultaneously and channel hopping is used. It is different from 100 traditional ZigBee communication. With increasing interest on IoT 101 network, various TSCH cell scheduling method has been provided. This 102 document describes the limitation of present TSCH cell scheduling 103 methods which mainly use centralized or decentralized approach. It 104 firstly overview pros and cons of various cell scheduling approaches 105 including centralized, decentralized and autonomous TSCH cell 106 scheduling methods. 108 Specifically, this document focus on autonomous approach. The biggest 109 benefits of autonomous scheduling method is its simple and light 110 scheduling without any negotiation and its quick response to the 111 sudden network changes. 113 This document also suggest design considerations on devising 114 autonomous scheduling approach to avoid unexpected confliction and 115 increase channel utilization. For the last, it provides one example 116 that reflects all design considerations mentioned: Autonomous Link- 117 based TSCH Cell Scheduling (ALICE). 119 2. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC 2119]. 125 3. Terminology 127 Cell : This document follows the same definition used in [RFC 7554] 129 ASN : This document follows the same definition used in [RFC 7554] 131 Slotframe : This document follows the same definition used in 132 [RFC 7554] 134 LinkNum : In the IoT sensor network, nodes and links form a graph and 135 each link has a node at both ends. LinkNum of specific link is 136 defined as the sum of NodeIDs of two connected nodes with that link. 138 SlotframeID : ID of the slotframe in the TSCH network. 140 4.TSCH cell scheduling 142 Regarding TSCH cell scheduling, detailed description is provided in 143 [RFC 7554]. Here, we briefly overview important characteristics used 144 in this document. 146 chOff ^ Slotframe 147 | 148 - +-----------------------------------------+ 149 | | | B | | | | | 150 | +-----------------------------------------+ 151 | | | | C | | | | 152 M | +-----------------------------------------+ 153 | | | F | | | D,G | | 154 | +-----------------------------------------+ 155 | | A | | | | | E | 156 _ +-----------------------------------------+---> Time 157 ___________________________________________ 158 Z 160 Figure 1: Structure of TSCH slotframe 162 In the communication using TSCH, multiple channels can be used 163 simultaneously and channel hopping is used. It is different from 164 traditional ZigBee communication. In TSCH, slotframe repeats over 165 time and the slotframe length is defined as the number of time 166 offsets. In Figure 1, one example of TSCH slotframe is described. In 167 this example, the number of channel offsets is M=4 and the number of 168 time offsets is Z=6. Z is also a slotframe length. The total number 169 of cells that is available in a slotframe is M*Z=24. In the example, 170 only 6 cells are scheduled in the slotframe. If two closely located 171 nodes try to send packets in the same cell, it will conflict and the 172 transmission of the both users will fail. So to avoid confliction 173 while achieving high channel utilization and energy efficiency, wise 174 and canny scheduling method should be used in TSCH cell scheduling. 175 Present method can be mainly categorized by two major approaches: 176 Centralized and decentralized scheduling. 178 4.1. Centralized approach 180 In the IoT sensor network using centralized TSCH cell scheduling 181 approach, one representative node schedules wakeup and sleep of every 182 node in the same network. Since only one node schedules the whole 183 communication in the network, for that node, large amount of 184 information is needed. Depending on the algorithm, various 185 information can be used and an optimized scheduling can be realized. 186 However, since only one specific node can execute TSCH cell 187 scheduling, quick action cannot be executed when the network topology 188 has been changed suddenly. Moreover, every node has to deliver the 189 information that will be used in the scheduling node, which causes 190 communication overhead using additive energy and bandwidth resources. 191 Furthermore, centralized approach takes long time for the 192 initialization. 194 * We categorize following kinds of scheduling as centralized 195 approach. 197 The network is divided into multiple regions. In each region, one 198 centralized scheduler executes centralized TSCH cell scheduling for 199 every node located in the same region with that node. In this 200 network, though multiple schedulers execute TSCH cell scheduling, it 201 is not fully decentralized manner. Rather, it can be viewed as a 202 combination of multiple centralized scheduling. 204 4.2. Decentralized approach 206 In the IoT sensor network using decentralized TSCH cell scheduling 207 approach, every node can schedule their own plan for wakeup and sleep 208 time. Each node communicate with their neighbors to avoid confliction 209 caused by simultaneous same channel usage among interfering nodes. To 210 implement this network, specific negotiation protocol should be 211 decided. Compared to the centralized approach, each node using the 212 decentralized TSCH cell scheduling approach needs only small amount 213 of information received from their close neighbors. As a result, it 214 is robust for a sudden network change compared to the centralized 215 approach. However, because of the scanty information, decentralized 216 approach lacks visibility on the view of the whole network. 218 4.3. Autonomous approach 220 Though decentralized approach shows quick response for the sudden 221 changes of network topology, it still needs additive communication 222 for the negotiation between neighbors. In the autonomous approach, 223 no negotiation is needed for the TSCH scheduling. One representative 224 method has been proposed in [Orchestra-Sensys15]. They only use 225 information received from RPL routing protocol [RFC 6550]. They do 226 not use additive communication for the negotiation among the 227 neighbors in TSCH cell scheduling. They autonomously calculate their 228 own plan on cell usage based on the RPL structure. They use NodeID 229 such as MAC address of their RPL parent node. With this method, 230 node-based cell scheduling is executed. For example, in the 231 receiver-based scheduling, receiving nodes are scheduled on the TSCH 232 cells. Scheduled node listen at the corresponding cell and any node 233 who wants to send packet to that node wakeup and send packet to the 234 receiving node at the same cell. Sender-based scheduling executes in 235 the similar manner. 237 Including the above method [Orchestra-Sensys15], though autonomous 238 TSCH cell scheduling approach also lacks other available information, 239 the biggest benefits of this approach is its simple and light 240 scheduling without any negotiation and its quick response to the 241 sudden network changes. 243 5. Design considerations of autonomous TSCH cell scheduling method 245 This section describes the design considerations for autonomous TSCH 246 cell scheduling. 248 In the design of TSCH cell scheduling, one of the biggest challenge 249 is to make scheduling by avoiding confliction among interfering 250 nodes. However, since autonomous scheduling does not use any 251 negotiation, it lacks information. In this condition, the thing that 252 autonomous scheduler can do is to reduce the probability of 253 confliction. 255 +---+ 256 | A | 257 +---+ 258 / \ 259 / \ 260 +---+ +---+ 261 | B | | C | 262 +---+ +---+ 263 / \ / \ 264 / \ / \ 265 +---+ +---+ +---+ +---+ 266 | D | | E | | F | | G | 267 +---+ +---+ +---+ +---+ 268 / \ / \ / \ / \ 269 H I J K L M N O 271 Figure 2: Nodes and Links in the Tree Topology 273 5.1. Link-based scheduling 275 Consideration 1: One node cannot receive packets from the two 276 different nodes simultaneously at the same timeslot. For example, in 277 the topology described in Figure 2, in the upstream transmission, 278 node B is connected to both node D and node E. If these two child 279 nodes send packets to the node B at the same timeslot, B will fail to 280 listen both two packets successfully. In this situation, the link D-B 281 and the link E-B can be scheduled in the same channel offset or in 282 the different channel offsets. In the former case, if two child node 283 sends packet simultaneously at the same time offset, two transmission 284 will be conflict at the same channel and B cannot receive any packet. 285 In the latter case, depending on the node B's selection of the 286 channel offset to listen at, one of the packets sent from the node A 287 or the node B can be received successfully. 289 5.2. Hop-count-based scheduling 291 Consideration 2: One node cannot listen and send packets 292 simultaneously at the same timeslot. For example, in the topology 293 described in Figure 2, in the upstream, node B is connected to both 294 node A and node D. If the link B-A and the link D-B is scheduled at 295 the same timeslot, node D will send to the node B and the node B will 296 send to the node A. However, node D cannot listen and send 297 simultaneously at the same timeslot. 299 5.3. SlotfrmaeID 301 Consideration 3: In the view of one specific node, the scheduling of 302 different slotframes should be changed to avoid consistent 303 confliction. If the scheduling result for a slotframe persists, the 304 conflicting nodes in a cell will conflict again at the next 305 slotframe. For example, in the topology described in Figure 2, in the 306 upstream, there are two links B-A and C-A. If these links are 307 scheduled in the same cell and node B and node C send packets to the 308 node A at the same timeslot, two packet transmissions will fail. If 309 this scheduling persist at the next slotframe, the same situation 310 will occur again. 312 5.4. Upstream: link-based, Downstream: node-based 314 Consideration 4: Cell scheduling method of upstream and downstream 315 should be differentiated. In the case of IoT network, the amount of 316 upstream traffic is much larger than that of downstream traffic. 317 Moreover, if tree topology is used for the routing protocol as 318 described in Figure 2, one node has multiple child nodes and only one 319 parent node. In this structure, in the case of upstream, every child 320 node has different packets to send to their parent node. So one node 321 should listen from their multiple child using different cells. 322 However, in the case of downstream, the server may request or respond 323 to every node in the network or to the one specific node. Moreover, 324 the amount of downstream packets are smaller than that of upstream 325 packets and the scheduled cell for downstream may not be used with 326 high probability. So, in the topology described in Figure 2, when the 327 link B-D and the link B-E is scheduled, scheduling these two links at 328 the same cell is more efficient than scheduling these links at the 329 different cells. By doing this, in the case where the server sends 330 one packet to every node in the network, node B can forward this 331 message to all their child nodes at only one transmission. In the 332 other case where the node B sends a packet to one of its child nodes, 333 it can send the packet to the specific node while multiple child 334 nodes listen at the same timeslot. 336 5.5. Upstream downstream scheduling 338 Consideration 5: One node cannot receive or send packets from both 339 their parent node and child node simultaneously. In other words, in 340 the view of one specific node, upstream and downstream can not be 341 happen at the same timeslot. For example, in the topology described 342 in Figure 2, the node B is connected to both node A and node D. If 343 both node A and node D is scheduled to send packets to the node B at 344 the same timeslot, or the node B is scheduled to send packets to the 345 node A and the node D at the same timeslot as a result of cell 346 calculation by using autonomous scheduling method, at least one 347 transmission will fail since node B cannot receive different packets 348 from the different nodes and send different packets to the different 349 nodes. 351 6. ALICE overview 353 In this section, we define Autonomous LInk-based tsch CEll 354 scheduling (ALICE). This scheduling method reflects 5 design 355 considerations described above. To use autonomous scheduling 356 approach, ALICE utilizes limited information on the basis of RPL 357 routing topology as shown in [Orchestra-Sensys15]. By using all 3 358 types of RPL messages (DIS, DIO and DAO), each node using ALICE knows 359 NodeID (e.g. MAC address) of their parent and child nodes. They use 360 another information such as Absolute Slot Number (ASN) and RPL 361 hop-count. 363 chOff ^ Slotframe 364 | Even Rank || Odd Rank | 365 - +--------------------||--------------------+ 366 | | L->F | C->A | M->F || F->C | | | 367 | | | | || | | | 368 | +--------------------||--------------------+ 369 | | I->D | | J->E || | G->C | | 370 | | | | O->G || | | | 371 M | +--------------------||--------------------+ 372 | | | H->D | || | D->B | | 373 | | | | || | | | 374 | +--------------------||--------------------+ 375 | | B->A | | N->G || | | E->B | 376 | | K->E | | || | | | 377 - +--------------------||--------------------+---> Time 378 |__________________________________________| 379 Z 381 Figure 3: Autonomous Link-based TSCH Cell Scheduling (ALICE) 383 6.1. Link-based scheduling 385 In ALICE, the tree topology is used for the routing protocol as RPL 386 is used together with TSCH. In its TSCH cell scheduling, every link 387 in the tree topology is scheduled at least once a slotframe. For 388 example, in Figure 2, there are 13 links and each link is scheduled 389 in a cell in a slotframe as described in Figure 3. Since ALICE uses 390 link-based scheduling, we allocate LinkNum to every link. LinkNum is 391 the sum of NodeIDs of two connected nodes with that link. For 392 example, in the Figure 2, node A and node B is connected with the 393 link A-B. Then, LinkNum of the link A-B is the sum of NodeID of node 394 A and that of node B. By using the value of LinkID, nodes in the 395 network autonomously calculate their plan for wakeup and sleep time. 397 6.2. Hop-count-based scheduling 399 By using hop-count-based scheduling, ALICE avoids the situation where 400 one node listens and sends simultaneously. With RPL, every node knows 401 their own hop-count. In this document, we call hop-count as rank. 402 Multiple cells in a slotframe is grouped into two different sections. 403 Even rank nodes are scheduled in the cells in the first section and 404 the odd rank nodes are scheduled in the the cells in the second 405 section. 407 6.3. SlotframeID 409 In ALICE scheduling, every slotframe has different cell scheduling 410 results since ALICE uses SlotframeID in their autonomous scheduling 411 algorithm. SlotframeID increases with time. SlotframeID is calculated 412 by flooring ASN%Z. 414 SlotframeID = floor(ASN%Z) 416 As Figure 4 describes, as SlotframeID changes, the result of cell 417 scheduling becomes completely different. 419 ^ 420 chOff | 421 +-----------------------------------------------+ 422 | | B | | | | |F | | |D | | | 423 +-----------------------------------------------+ 424 | | |C | | | | |A | | | | | 425 +-----------------------------------------------+ 426 | | F | | |D,G| | | | | |E | | 427 +-----------------------------------------------+ 428 #chOff=0 |A | | | | |E |C | |B | | |G | 429 +-----------------------------------------------+-->Time 430 |-----------------------|-----------------------| 431 Z Z 432 Figure 4: Differenct slotframes have different cell scheduling results 434 6.4. Upstream: link-based, Downstream: node-based 436 ALICE uses different scheduling style for uplink and downlink 437 streams. For the upstream, it has link-based scheduling approach and 438 for the downstream, it has node-based scheduling approach as 439 [Orchestra-Sensys15]. 441 6.5. Upstream downstream scheduling 443 Since the amount of upstream traffic is much more than that of 444 downstream traffic, ALICE give more chance for the upstream traffic 445 compared to the downstream traffic in its cell scheduling. For 446 example, with the length K for a slotframe-cycle, K-1 slotframes are 447 allocated for the upstream and 1 slotframe is allocated for the 448 downstream. More specific example is described in Figure 5. If K=3, 449 2 slotframes are allocated for the upstream and 1 slotframe is 450 allocated for the downstream. 452 ^ [ K=3 ] 453 chOff | 454 +-----------+-----------+-----------++-----------+-- 455 | | B | | | C | D | C | | B || A | | E | 456 +------------------------------------------------+-- 457 | E | C | | |A,B| | E | | A || | C | | 458 +------------------------------------------------+-- 459 0 | A | | D | E | | | | D | || | B | D | 460 +-----------+-----------+-----------++-----------+---->Time 462 |-----Z-----+-----Z-----|-----Z-----||-----Z-----|-- 463 |........uplink.........|..downlink.||......uplink.. 464 |______________1cycle_______________||______1cycle__ 466 Figure 5: Upstream and Downstream Scheduling 468 7. ALICE details 470 In this section, we define ALICE scheduling details. In the network 471 with ALICE, every node has ALICE scheduler and calculates specific 472 cells for send or receive packets autonomously on the basis of 473 LinkNum, SlotframeID and Rank. As defined above, LinkNum of one link 474 is defined on the basis of NodeID of two nodes that is connected with 475 that link. SlotframeID is on the basis of ASN. To calculate the 476 specific ChannelOffset and the TimeOffset, ALICE uses hash function 477 as [Orchestra-Sensys15] does. 478 Here, we use M and Z for the number of channel offsets and the number 479 of time offsets in a slotframe, respectively. 481 7.1. Upstream cell scheduling 483 In the upstream traffic, a node receives packets from its child nodes 484 and sends packet to its parent node. Upstream cell scheduling is done 485 only in the upstream period. 487 7.1.1. Receive Scheduling 489 TimeOffset = (NodeRank%2)*(Z/2) +Hash(NodeID+ChildID+SlotframeID) 490 %(Z/2) 492 ChannelOffset = Hash(ChildID+SlotframeID)%M 494 7.1.2. Send Scheduling 496 TimeOffset = (ParentRank%2)*(Z/2) + Hash(ParentID+NodeID+SlotframeID) 497 %(Z/2) 499 ChannelOffset = Hash(NodeID+SlotframeID)%M 501 7.2. Downstream cell scheduling 503 In the downstream traffic, a node receives packet from its parent 504 node and sends packet to its child nodes. Downstream cell scheduling 505 is done only in the downstream period. 507 7.2.1. Receive Scheduling 509 TimeOffset = (ParentRank%2)*(Z/2) + Hash(ParentID+SlotframeID)%(Z/2) 510 ChannelOffset = Hash(ParentID+SlotframeID)%M 512 7.2.2. Send Scheduling 514 TimeOffset = (NodeRank%2)*(Z/2) + Hash(NodeID+SlotframeID)%(Z/2) 516 ChannelOffset = Hash(NodeID+SlotframeID)%M 518 7.3. Upstream and Downstream Scheduling 520 K is the number of slotframes in a group that is composed multiple 521 slotframes during a pair of one upstream period and one downstream 522 period. In other words, in each cycle, one downstream period and one 523 upstream period are shown. Since the amount of upstream traffic is 524 much more than that of downstream traffic, the number of cells for 525 the upstream traffic should be larger than that of downstream 526 traffic. Since the number of cells in a timeslot does not change, 527 longer time is allocated for the upstream period compared to 528 downstream period. During the upstream period, upstream cell 529 scheduling is executed and during the downstream period, downstream 530 cell scheduling is executed. Decision of upstream and downstream 531 period is simple as follows. The algorithm is on the basis of 532 SlotframeID and the parameter K. 534 If (SlotframeID%K==0) 535 Downstream period 536 Else 537 Upstream period 538 End 540 8. IANA Considerations 542 There are no IANA considerations related to this document. 544 9. Security Considerations 546 Autonomous TSCH cell scheduling method has similar requirements on 547 security as [RFC7554]. 549 10. Acknolwedgement 551 This work was supported by Institute for Information & communications 552 Technology Promotion(IITP) grant funded by the Korea government(MSIP) 553 (No.B0190-16-2017,Resilient/Fault-Tolerant Autonomic Networking Based 554 on Physicality, Relationship and Service Semantic of IoT Devices), 555 the MSIP(Ministry of Science, ICT and Future Planning), Korea, under 556 the ITRC(Information Technology Research Center) support program 557 (IITP-2016-R0992-16-1023) supervised by the IITP(Institute for 558 Information & communications Technology Promotion and the National 559 Research Foundation of Korea(NRF) Grant funded by the Korean 560 Government(MSIP) (No.2016R1A5A1012966). 562 11. Reference 564 11.1. Normative References 566 [RFC 7554] T. Watteyne, Ed., L. Grieco, "Using IEEE 802.15.4e 567 Time-Slotted Channel Hopping (TSCH) in the Internet of 568 Things (IoT): Problem Statement", RFC 7554, May 2015 570 [RFC 6550] T. Winter, Ed., P. Thubert, Ed., A. Brandt, J. Hui, 571 R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, 572 R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power 573 and Lossy Networks", RFC 6550, March 2012 575 11.2. Informative References 577 [Orchestra-Sensys15] Duquennoy, Simon, et al. "Orchestra: Robust mesh 578 networks through autonomously scheduled TSCH." 579 Proceedings of the 13th ACM Conference on 580 Embedded Networked Sensor Systems. ACM, 2015. 582 Authors' Addresses 584 Seo Hyang Kim 585 Department of Computer Science and Engineering 586 Seoul National University 587 Seoul, South Korea 589 Phone: +82 (0)2 880 1858 590 Email: shkim@popeye.snu.ac.kr 592 Na Eon Kim 593 Department of Computer Science and Engineering 594 Seoul National University 595 Seoul, South Korea 597 Phone: +82 (0)2 880 1858 598 Email: nekim@popeye.snu.ac.kr 600 Nguyen Duc Lam 601 Department of Computer Science and Engineering 602 Seoul National University 603 Seoul, South Korea 605 Phone: +82 (0)2 880 1858 606 Email: lam@popeye.snu.ac.kr 608 Chong Kwon Kim 609 Department of Computer Science and Engineering 610 Seoul National University 611 Seoul, South Korea 613 Phone: +82 (0)2 880 1858 614 Email: ckim@snu.ac.kr