[6tisch] cell rules in MSF

Tengfei Chang <tengfei.chang@gmail.com> Fri, 23 August 2019 12:11 UTC

Return-Path: <tengfei.chang@gmail.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6477B120833 for <6tisch@ietfa.amsl.com>; Fri, 23 Aug 2019 05:11:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9hUe4dyX0Up for <6tisch@ietfa.amsl.com>; Fri, 23 Aug 2019 05:11:15 -0700 (PDT)
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00004120823 for <6tisch@ietf.org>; Fri, 23 Aug 2019 05:11:14 -0700 (PDT)
Received: by mail-pf1-x42f.google.com with SMTP id s11so410923pfe.6 for <6tisch@ietf.org>; Fri, 23 Aug 2019 05:11:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=/Yv3Pngm4fkRlY3oa0dco8bcx3zrXjus5/RAsJYbcuA=; b=dZzsI7NClZVs5M3bcYbBmdm17hqhVUgz+q81zno8frffjaFBzKQXEHefuaHGx+2rMa FJE3o/7PNwFkDfArfREcx6hO2aE3WHtgMvFvG2b66QYYx61ci9SHk/S0bkyt9CEf83E1 nHhYK0ESq18Z14XHJ1x1FePdjwtShoDU5gc5VBz2OBSc0O6fnKJ2mrjFUp0y0IpRYtC5 MwKo9IBozX25Z1BSvOCxahpPRn6o4eu0zIDLZdhqvieaRRwGuL8IL7D8/JW1Zzc4qTD2 kp1NdK91TrAEQ1pO+D2SDBtj4ZOVoUQDeMNOm4uwnlLT0u20c6ZVksMJcc307N/n6jO7 OT9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/Yv3Pngm4fkRlY3oa0dco8bcx3zrXjus5/RAsJYbcuA=; b=Phjxveupw1vpgq+COrIYI9MV0AOuO3ZHuzziJw40Bb/YiSAlrNhUYT/sbco3bZu8Cq FSawxF6D/7O0V/y/TTSy/HoP04wQUx1gDOY7iCR5ouV+C+aSw1uAHyHTOnkwfOI126q9 mshtTIuGSSXwKQT5jKo9CEye78AHanweG2CYg9M3+MswotxV0nJsBYxrj7zvSQ8wZMti edtuEGgFPM/YBSB9cK/MmvWooWclYCbvtKNGNbVx1zPYqjh2acFeonsykNHF+cUXmiR5 XG9L+jLNEQ2lMpkLRy0dS/mY6Tiw6s6nnrpN9cNxtbKbSfAs9i4Cy19FgVQ6UHUiI3Qh CuBg==
X-Gm-Message-State: APjAAAVSu27blvmA4q82OdO9twsKbb4Iq4639rSt66hXAmUveU1GaPs1 LUiRp4SVYfFyIr4R0ZnDbArz83M6ieWGykbSvecsf1Qs5qM=
X-Google-Smtp-Source: APXvYqwVfV1/3BrM9aJxs0fkrBULlCHHKuC+LZp72Rw5l2u0NjaQF1AMWTBm4/aCVeVC4Ft8AipE9/jQ+65ErWWJ2qc=
X-Received: by 2002:a17:90a:5d12:: with SMTP id s18mr4703566pji.112.1566562274092; Fri, 23 Aug 2019 05:11:14 -0700 (PDT)
MIME-Version: 1.0
From: Tengfei Chang <tengfei.chang@gmail.com>
Date: Fri, 23 Aug 2019 14:11:02 +0200
Message-ID: <CAAdgstRZrUA4B4cy85S=fUbz2R-sAQVxeahVEMobXOhgd79EUA@mail.gmail.com>
To: 6tisch <6tisch@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ddac240590c7b3e0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/2uUR9DWkpEL5Vv0txrXeBqOnd7Q>
Subject: [6tisch] cell rules in MSF
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Aug 2019 12:11:16 -0000

Hi all,

As we discussed in IETF 105, we may need some way to monitor the candidate
cells to schedule before adding them.

Hence the following paragraph is added in version 06:

 As a consequence of randomly cell selection, there is a non-zero
   chance that nodes in the vicinity installed cells with same
   slotOffset and channelOffset.  An implementer MAY implement a
   strategy to monitor the candidate cells before adding them in
   CellList to avoid collision.  For example, a node MAY maintain a
   candidate cell pool for the CellList.  The candidate cells in the
   pool are pre-configured as Rx cells to listen whether there is any
   incoming frame on those cells.  If any IEEE802.15.4 frames are
   received within a pre-defined duration on one cell, that cell will be
   moved out from the pool and a new cell is selected as a candidate

   cell.  The cells in CellList are picked from the candidate pool

   directly when required.

Please let me know if you have any comments on this fix. Thanks!

Tengfei

-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria