Re: [6tsch] report flow contents
"Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl> Fri, 13 September 2013 14:23 UTC
Return-Path: <diego.dujovne@mail.udp.cl>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B4321E8055 for <6tsch@ietfa.amsl.com>; Fri, 13 Sep 2013 07:23:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAob9tK9+NKl for <6tsch@ietfa.amsl.com>; Fri, 13 Sep 2013 07:23:13 -0700 (PDT)
Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5360421E809C for <6tsch@ietf.org>; Fri, 13 Sep 2013 07:23:06 -0700 (PDT)
Received: by mail-wi0-f182.google.com with SMTP id ez12so888589wid.3 for <6tsch@ietf.org>; Fri, 13 Sep 2013 07:23:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iztsCuqTm3uB6ETp8GeV99ynFYYwnf52vnjaVBu/5Z4=; b=bPiGjj/EOmHBCDKYduD9wLzqyPYCa8VtnW1sL+m7g2m4Bs6nt1ciVlK0ylTe/1hbMU pyI3sM1aUfQRTazY+GX+8t137O3yfmh7vfTBhYcbv4PmepLAjAlfocDxjA7W5hTH5MpM xxWy0KHzJOXR9wDlpMkL0Z4jWq4EbIs+l5alkdWUEYFLEf8oAZ4qU7IV8zduqt83Ekbe DRNcdxncIkFup53XxNQfWvpgKtyfJGSvIjUBj0/mytpsZt/n5wc6O2g5q+omiPjGe90K uLd7DTdxSuW2TIRe68tnFlx5iBVvJJrjPdiAeg90IASDRO3zS8z0Ed3cawaECknWI/ln 1oPQ==
X-Gm-Message-State: ALoCoQnTnS5UJPEkgpDfdyPiWOIU7gMRJPttbVOiGSOBywgcguYeUscfffa8fylcbHzny7mVOPLU
MIME-Version: 1.0
X-Received: by 10.180.36.231 with SMTP id t7mr2717614wij.53.1379082183480; Fri, 13 Sep 2013 07:23:03 -0700 (PDT)
Received: by 10.194.122.103 with HTTP; Fri, 13 Sep 2013 07:23:02 -0700 (PDT)
In-Reply-To: <CAAzoce4Up5ar80n-1zr-Opq10QOBVDcvNApBBgPKr+g6UjDENw@mail.gmail.com>
References: <CADJ9OA_XeC7Z5hFxyHhFGqD0aFMcBn=iHzDfRq34sL9qPi2P4A@mail.gmail.com> <CALEMV4YN3rA2OXeAV1akOZhdQrMOQvhN0A+t6vsL9RPVV=VMnQ@mail.gmail.com> <CADJ9OA8Cx3ingeiMdr60zUfMMENiay-Nftv0nMFOTD7=YcKgwg@mail.gmail.com> <CALEMV4ZdgWAFMyA=FtRik96evup-qJPQfTcDQEu99sfC0xFwuQ@mail.gmail.com> <E045AECD98228444A58C61C200AE1BD84145CB61@xmb-rcd-x01.cisco.com> <CALEMV4a=azY5MU00jNmcoek022gS=pUeXK1xVnucG+Zy6NTBOA@mail.gmail.com> <CALEMV4a=DCXV9ra832-5zEtiD7moUmj6GYu7tiosDYsD5v4ObA@mail.gmail.com> <CADJ9OA9OpGRvB1A4j-Byho_m8Zp3z1A5krCVi08U7xWP1Ohk+Q@mail.gmail.com> <76EA352C3C95BB42A2C4F2EE6493AD6E4DA7B88C@EXMBX23.ad.utwente.nl> <CADJ9OA9qb6aqyqonEmfZpqt3NHqm5EWPK-p2BAQf9C9sw8Cp3A@mail.gmail.com> <CALEMV4b4rfoLBWSOW8=wWR2xWy32V_uCXEzJ=5vaebL6g+LpbQ@mail.gmail.com> <76EA352C3C95BB42A2C4F2EE6493AD6E4DA7BC47@EXMBX23.ad.utwente.nl> <52316e72.c7380f0a.73cf.ffffc7a5@mx.google.com> <CADJ9OA9p2jihyn_o2XtLi7X7EBRQFMEADFjW8upKzgD70h3WOg@mail.gmail.com> <CAAzoce4Up5ar80n-1zr-Opq10QOBVDcvNApBBgPKr+g6UjDENw@mail.gmail.com>
Date: Fri, 13 Sep 2013 11:23:02 -0300
Message-ID: <CAH7SZV9-KaAiWOGxstDX3j5exL2EUC=4O_-pfm6tJMwe3kYOhA@mail.gmail.com>
From: "Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl>
To: Qin Wang <qinwang@berkeley.edu>
Content-Type: multipart/related; boundary="e89a8f6466f7a9a54304e64497b3"
Cc: Thomas Watteyne <watteyne@eecs.berkeley.edu>, 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] report flow contents
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
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" <6tsch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:6tsch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>
List-Post: <mailto:6tsch@ietf.org>
List-Help: <mailto:6tsch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:6tsch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2013 14:23:13 -0000
Hello Qin, I think that a per-frequency report will help the PCE to decide which frequency to use, and maybe temporarily black-list them. For example, a dynamic scheme may include sampling the blacklisted frequencies every X minutes to re-enable them once the interference has disappeared. This will require the node to refresh the RSSI and LQI values in a opportunistic way (every time the a cell uses that frequency) to save energy. Any thoughts? Diego 2013/9/13 Qin Wang <qinwang@berkeley.edu> > Hi Thomas and All, > > I think the per-frequency report (or called per-channel report in > ISA100.11a) is important, because PCE can use it to build black frequency > list and update channel hopping sequence. But, I'm not sure if it makes > implementation too complex or not. > > Thought? > > Qin > > > On Fri, Sep 13, 2013 at 8:48 AM, Thomas Watteyne < > watteyne@eecs.berkeley.edu> wrote: > >> Pouria, >> Thanks again for the overview, which complements your first document >> nicely. >> >> Alfredo, >> Could you please elaborate what you mean by in-network processing? Are >> you referring to a distributed way for the nodes to "consume" this data, >> some fusion as the data trickles up the DAG, or something else? >> >> Thomas >> >> >> On Thu, Sep 12, 2013 at 12:34 AM, Alfredo Grieco < >> alfredo.grieco@gmail.com> wrote: >> >>> Hi All,**** >>> >>> ** ** >>> >>> Do you think is it feasible to add a bit/flag that allows some form of >>> in-network processing ? **** >>> >>> ** ** >>> >>> This would be very useful to distributed/decentralized scheduling >>> techniques and should not cost that much.**** >>> >>> ** ** >>> >>> Any thoughts is welcome.**** >>> >>> ** ** >>> >>> Cheers**** >>> >>> ** ** >>> >>> Alfredo**** >>> >>> ** ** >>> >>> *Da:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *Per conto >>> di *P.Zand@utwente.nl >>> *Inviato:* Wednesday, September 11, 2013 10:45 PM >>> *A:* xvilajosana@eecs.berkeley.edu; watteyne@eecs.berkeley.edu >>> *Cc:* 6tsch@ietf.org >>> *Oggetto:* Re: [6tsch] report flow contents**** >>> >>> ** ** >>> >>> Thomas,**** >>> >>> I agree with you that "source route failed" and "graph route failed" are >>> out of scope of 6TiSCH.**** >>> >>> Regarding to you question about the per-channel report, I think they are >>> based on each radio channel supported by the specification (channel 11-26 >>> in 2.4GHz in IEEE 802.15.4), not channel offset. And a channel report >>> generated for all neighbor.**** >>> >>> Regarding to your first question, let me now explain more. I think both >>> of these standard provide a mechanisms to make it possible for >>> System/Network Manager to also read (pull) desired attributes (But not all >>> the feature in 6TiSCH). For example in WirelessHART [1], by “Report >>> Neighbor Health List” request, the network manager might mention the number >>> of neighbors to be read in “Number of Neighbor entries read” field.. *** >>> * >>> >>> I think, ISA100.11a provides more mechanisms for System manager to get >>> the desired attributes from the field devices. And the first two features >>> that you mentioned might also be supported by ISA100.11a.**** >>> >>> In ISA100.11a, three mechanisms are provided for reporting diagnostic >>> information contained in dlmo.NeighborDiag (described in section 1 later) >>> and dlmo.ChannelDiag (described in Section 2 later):**** >>> >>> 1. The health reports concentrator object (HRCO), can be configured >>> to report any attribute in the DL *on a* *periodic basis*. >>> dlmo.NeighborDiag entries (shown in Table 2) and dlmo.ChannelDiag (shown in >>> Table 5) can be reported through that mechanism. Through the HRCO, the >>> system manager can configure the device to report NeighborDiag >>> periodically, such as every 30 minutes. Following each such report, on a >>> per-entry basis, NeighborDiag counts shall be reset to zero. Levels shall >>> use the current value as a starting point for the next period [2].*** >>> * >>> 2. Diagnostic information can be retrieved at any time by the system >>> manager, by reading the applicable attributes. The system manager can read >>> (poll) NeighborDiag as a read-only attribute *on a per-entry basis*. >>> As in an HRCO report, counts shall be reset to zero when read [2].*** >>> * >>> 3. Diagnostic information can be reported by the DL on *an exception >>> basis*, through the DL_Connectivity alert (Described in section >>> 3(a)). The DL can additionally be configured, through the dlmo.AlertPolicy >>> attribute (shown in Table 6), to report NeighborDiag information when >>> diagnostic values exceed a threshold. Only the row triggering the alert is >>> reported. No values are reset [2]. **** >>> >>> ** ** >>> >>> In ISA100.11a, the system manager establishes a DL communication >>> relationship between a device and its neighbor by adding an entry to the >>> device’s dlmo.Neighbor attribute (see Table 1). Each such entry specifies a >>> level of diagnostics to be collected, through the field >>> dlmo.Neighbor[].DiagLevel. For each neighbor, diagnostics may be collected >>> at a baseline level, or a detailed level including clock diagnostics [2]. >>> This levels are described in Section 1.**** >>> >>> *Table **1. dlmo.Neighbor fields [2]* >>> >>> *Field name* >>> >>> *Field encoding* >>> >>> * Index (16-bit address of neighbor)**** >>> >>> ExtDlUint (used as an index)**** >>> >>> EUI64 (EUI-64 identifier of the neighbor)**** >>> >>> Type: Unsigned64**** >>> >>> …**** >>> >>> …**** >>> >>> *DiagLevel* (selection of neighbor diagnostics to collect)**** >>> >>> Type: Unsigned2**** >>> >>> Bit0 = 1 Collect link diagnostics**** >>> >>> Bit1 = 1 Collect clock diagnostics**** >>> >>> …**** >>> >>> …**** >>> >>> ** ** >>> >>> When the dlmo.Neighbor[].DiagLevel field is set for a particular >>> neighbor, the DL shall create corresponding entries in the read-only >>> attribute dlmo.NeighborDiag. NeighborDiag values are accumulated from the >>> time that the dlmo.NeighborDiag entry is created [2].**** >>> >>> ***1. ****dlmo.NeighborDiag:* >>> >>> dlmo.NeighborDiag is an indexed OctetString collection that contains >>> diagnostics for a set of neighbors. The attribute is read-only, with rows >>> created as needed by the DL [2].**** >>> >>> NeighborDiag entries are instantiated by the system manager, by setting >>> dlmo.Neighbor[].DiagLevel bits to non-zero values. Iff (if and only if) >>> Bit0=1, then summary diagnostics shall be collected for the neighbor, >>> consolidated across all channels. Iff Bit1=1, then detailed clock >>> diagnostics shall be collected for the neighbor, consolidated across all >>> radio channels [2].**** >>> >>> *Table **2. dlmo.NeighborDiag fields [2]* >>> >>> Field name**** >>> >>> Field encoding**** >>> >>> * Index**** >>> >>> Type: ExtDlUint (neighbor address, used as an index)**** >>> >>> *Summary* >>> >>> Type: OctetString (see Table 3)**** >>> >>> *ClockDetail* >>> >>> Type: OctetString (see Table 4)**** >>> >>> ** ** >>> >>> *Table **3. Diagnostic Summary OctetString fields [2]* >>> >>> Field name**** >>> >>> Field encoding**** >>> >>> RSSI (level)**** >>> >>> Type: Integer8**** >>> >>> RSQI (level)**** >>> >>> Type: Unsigned8**** >>> >>> RxDPDU (count)**** >>> >>> Type: ExtDlUint**** >>> >>> TxSuccessful (count)**** >>> >>> Type: ExtDlUint**** >>> >>> TxFailed (count)**** >>> >>> Type: ExtDlUint**** >>> >>> TxCCA_Backoff (count)**** >>> >>> Type: ExtDlUint**** >>> >>> TxNACK (count)**** >>> >>> Type: ExtDlUint**** >>> >>> ClockSigma (level)**** >>> >>> Type: Integer16**** >>> >>> ** ** >>> >>> *Table **4. Diagnostic ClockDetail OctetString fields [2]* >>> >>> Field name**** >>> >>> Field encoding**** >>> >>> ClockBias (level, signed)**** >>> >>> Type: Integer16**** >>> >>> ClockCount (count)**** >>> >>> Type: ExtDlUint**** >>> >>> ClockTimeout (count)**** >>> >>> Type: ExtDlUint**** >>> >>> ClockOutliers (count)**** >>> >>> Type: ExtDlUint**** >>> >>> ** ** >>> >>> **2. ***dlmo.ChannelDiag*:**** >>> >>> dlmo.ChannelDiag is a read-only dynamic attribute that reports DPDU >>> transmit failure rates on each radio channel supported by the >>> specification. This enables the system manager to be aware of consistent >>> connectivity problems on a per-channel basis, as a diagnostic for spectrum >>> management in a subnet [2].**** >>> >>> Two diagnostics are reported for each channel, each indicating a >>> different type of failure. **** indicates the percentage of time that >>> unicast DPDU transmissions on channel N did not receive an ACK or a NACK. >>> **** indicates the percentage of time that unicast DPDU transmissions >>> on channel N were aborted due to CCA. [2]**** >>> >>> *Table **5. dlmo.ChannelDiag fields* >>> >>> Field name**** >>> >>> Field encoding**** >>> >>> Count (Number of attempted unicast transmissions for all channels)**** >>> >>> Type:Unsigned16**** >>> >>> **** (Percentage of time transmissions on channel 0 did not receive an >>> ACK)**** >>> >>> Type: Integer8**** >>> >>> **** (Percentage of time transmissions on channel 0 aborted due to CCA)* >>> *** >>> >>> Type: Integer8**** >>> >>> …**** >>> >>> ** ** >>> >>> **** (Percentage of time transmissions on channel 15 did not receive an >>> ACK)**** >>> >>> Type: Integer8**** >>> >>> **** (Percentage of time transmissions on channel 15 aborted due to CCA) >>> **** >>> >>> Type: Integer8**** >>> >>> ** ** >>> >>> ***3. ****Data link layer alerts* >>> >>> 1. *DL_Connectivity alert* >>> >>> DL performance diagnostics are accumulated in the attributes >>> dlmo.NeighborDiag for *per-neighbor* diagnostics, and dlmo.ChannelDiag >>> for *per-channel* diagnostics. Normally the system manager configures >>> the HRCO to report these diagnostics periodically, and the DL automatically >>> resets the diagnostic counters whenever these attributes are so reported. >>> Between such reports, diagnostics may indicate a problem that needs to be >>> reported to the system manager immediately. The DL_Connectivity alert >>> provides the mechanism for the DL to report such issues, and the >>> dlmo.AlertPolicy attribute enables the system manager to set thresholds for >>> such reporting [2].**** >>> >>> The attribute dlmo.AlertPolicy enables/disables the DL_Connectivity >>> alert and provides thresholds to control whether alerts are reported. >>> dlmo.AlertPolicy is an OctetString containing fields as shown in Table 6 >>> [2].**** >>> >>> *Table **6. dlmo.AlertPolicy fields* >>> >>> Field name**** >>> >>> Field scalar type**** >>> >>> Descriptor (Enables or disabled the DL_Connectivity alert.)**** >>> >>> Type Alert report descriptor**** >>> >>> NeiMinUnicast (Minimum number of unicast transactions needed for a >>> neighbor report.)**** >>> >>> Type: ExtDlUint**** >>> >>> NeiErrThresh (Report neighbor diagnostic if the percentage error rate >>> reaches this threshold )**** >>> >>> Type: Unsigned8**** >>> >>> ChanMinUnicast (Minimum number of unicast transactions on a channel >>> needed as a pre-condition for triggering an alert.)**** >>> >>> Type: ExtDlUint**** >>> >>> NoAckThresh (Report ChannelDiag if a NoAck value is greater than this >>> threshold)**** >>> >>> Type: Unsigned8**** >>> >>> CCABackoffThresh (Report ChannelDiag if a CCABackoff value is greater >>> than this threshold)**** >>> >>> Type: Unsigned8**** >>> >>> ** ** >>> >>> 1. *NeighborDiscovery alert*** >>> >>> The NeighborDiscovery alert provides a mechanism for the DL to report >>> the contents of the OctetString in dlmo.Candidates attribute (see Table 7). >>> **** >>> >>> The neighbors in the dlmo.Neighbor attribute are set by the system >>> manager, not by the device itself. The DL autonomously builds a list of >>> candidate neighbors in the dlmo.Candidates attribute. This list is then >>> forwarded to the system manager. The system manager considers the radio >>> connectivity that is reported in dlmo.Candidates, but may also consider >>> other criteria such as resource constraints, historical performance, or >>> subnet topology [2].**** >>> >>> *Table **7. dlmo.Candidates OctetString fields* >>> >>> Field name**** >>> >>> Field encoding**** >>> >>> N (count of discovered neighbors)**** >>> >>> Type: Unsigned8**** >>> >>> Neighbor1 (16-bit address of first candidate)**** >>> >>> Type: ExtDlUint**** >>> >>> RSSI1 (radio signal quality of first candidate)**** >>> >>> Type: Integer8**** >>> >>> RSQI1 (radio signal quality of first candidate)**** >>> >>> Type: Unsigned8**** >>> >>> etc…**** >>> >>> ** ** >>> >>> NeighborN (16-bit address of Nth candidate)**** >>> >>> Type: ExtDlUint**** >>> >>> RSSIN (radio signal quality of Nth candidate)**** >>> >>> Type: Integer8**** >>> >>> RSQIN (radio signal quality of Nth candidate)**** >>> >>> Type: Unsigned8**** >>> >>> ** ** >>> >>> *References* >>> >>> 1. IEC 62591: Industrial Communication Networks - Wireless >>> Communication Network and Communication Profiles - WirelessHART.**** >>> >>> ** ** >>> >>> 2. IEC 62734: Industrial communication networks - Fieldbus >>> specifications - Wireless systems for industrial automation: process >>> control and related applications - ISA100.11a.**** >>> >>> ** ** >>> >>> ** ** >>> >>> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On >>> Behalf Of *Xavier Vilajosana Guillen >>> *Sent:* Wednesday, September 11, 2013 8:54 PM >>> *To:* Thomas Watteyne >>> *Cc:* 6TSCH >>> *Subject:* Re: [6tsch] report flow contents**** >>> >>> ** ** >>> >>> Hi Thomas, **** >>> >>> my 5 cents.**** >>> >>> I agree on adding NACK information and timing differences with other >>> than time source parent neighbors. I will add to the wiki :-)**** >>> >>> As regards to the differences of what we do at 6TiSCH and WHart or >>> ISA100.11a, our proposal is more flexible and has less cohesion with a cost >>> of increased complexity (e.g configurable data and reporting period). We >>> have to analyse carefully what are the implications in terms of protocol >>> complexity and implementation of that mechanism versus how often they would >>> be used. Could we maybe define some "templates" or default configurations >>> so using the 6TiSCH can be done without configuration overhead? Then >>> configuration can be used for those that are really interested on tuning >>> their system. **** >>> >>> just thoughts.. >>> X**** >>> >>> ** ** >>> >>> ** ** >>> >>> On Wed, Sep 11, 2013 at 9:58 AM, Thomas Watteyne < >>> watteyne@eecs.berkeley.edu> wrote:**** >>> >>> Pouria,**** >>> >>> ** ** >>> >>> Wonderful list.**** >>> >>> ** ** >>> >>> Your document clearly highlights that (1) the "report" flows both in >>> WirelessHART and ISA100.11a are strictly periodic and (1) they have a fixed >>> format. From what we have discussed so far, the solutions we are developing >>> is different in the following ways:**** >>> >>> - 6TiSCH offers a mechanism allowing the PCE to configure what data >>> it want to receive, and configure the trigger for a node to generate from >>> data.**** >>> - 6TiSCH offers a mechanism allowing the PCE to query the data, on >>> top of having the nodes push the information**** >>> - In 6TiSCH, the format of the payload is not fixed. In particular, >>> it is possible to add application-specific fields, allowing for extensions. >>> **** >>> - In 6TiSCH, the transport (CoAP?) and formatting (CBOR?) are >>> IETF-friendly and integrate well in the IPv6 stack and associated mechanisms >>> **** >>> >>> Did I get that right?**** >>> >>> ** ** >>> >>> A couple of questions:**** >>> >>> - the WirelessHART "alarms" correspond to a 6TiSCH "events". Yet, I >>> suppose that a "source route failed" and "graph route failed" are out of >>> scope of 6TiSCH, but rather part of RPL. I would expect those to the ICMPv6 >>> messages. Thoughts?**** >>> - About the per-channel report, I assume this is "per frequency", >>> right? Is a channel report generated for each neighbor?**** >>> - When comparing your list to *Xavi*'s >>> https://bitbucket.org/6tsch/meetings/wiki/report_flow_contents:**** >>> >>> >>> - we might want to add a "numNACK" counter to the neighbor >>> information**** >>> - we might want to keep timing statistics for all neighbors, not >>> just time source parents. That is, when I receive a packet from a neighbor >>> which is not my time source neighbor, I do not change my clock, but I still >>> know the timing error.**** >>> >>> Thomas**** >>> >>> ** ** >>> >>> On Wed, Sep 11, 2013 at 7:18 AM, <P.Zand@utwente.nl> wrote:**** >>> >>> Dear All,**** >>> >>> In the following, I listed the performance metrics reported to the >>> Network/System Manager in WirelessHART and ISA100.11a.**** >>> >>> Some reports still need be added, for example the path failure alerts in >>> ISA100.11a.**** >>> >>> Pouria**** >>> >>> **** >>> >>> *WirelessHART performance metrics***** >>> >>> In WirelessHART[1] network the statistics and events are reported to the >>> Network Manager (act like PCE in 6TiSCH) through the following commands: >>> **** >>> >>> 1. Report “Device Health” **** >>> >>> This report is sent periodically toward the Network Manager. The report >>> summaries the communication statistics of a device.**** >>> >>> Byte**** >>> >>> Format**** >>> >>> Description**** >>> >>> 0-1**** >>> >>> Unsigned-16**** >>> >>> Number of packets generated by this device since last report**** >>> >>> 2-3**** >>> >>> Unsigned-16**** >>> >>> Number of packets terminated by this device since last report**** >>> >>> 4**** >>> >>> Unsigned-8**** >>> >>> Number of Data-Link Layer MAC MIC failures detected**** >>> >>> 5**** >>> >>> Unsigned-8**** >>> >>> Number of Network Layer (Session) MIC failures detected**** >>> >>> 6**** >>> >>> Enum-8**** >>> >>> Power Status**** >>> >>> 7**** >>> >>> Unsigned-8**** >>> >>> Number of CRC Errors detected**** >>> >>> **** >>> >>> 1. Report “Neighbor Health List” **** >>> >>> This report is sent periodically toward the Network Manager. The report >>> includes the statistics of linked neighbors.**** >>> >>> Byte**** >>> >>> Format**** >>> >>> Description**** >>> >>> 0**** >>> >>> Unsigned-8**** >>> >>> Neighbor table index**** >>> >>> 1**** >>> >>> Unsigned-8**** >>> >>> Number of Neighbor entries read**** >>> >>> 2**** >>> >>> Unsigned-8**** >>> >>> Total number of neighbors**** >>> >>> 3-4**** >>> >>> Unsigned-16**** >>> >>> Nickname of neighbor**** >>> >>> 5**** >>> >>> Bit-8**** >>> >>> Neighbor Flags**** >>> >>> 6**** >>> >>> Signed-8**** >>> >>> Mean RSL (Receive Signal Level in dBm) since last report**** >>> >>> 7-8**** >>> >>> Unsigned-16**** >>> >>> Number of Packets transmitted to this neighbor**** >>> >>> 9-10**** >>> >>> Unsigned-16**** >>> >>> Number of Packets received from this neighbor**** >>> >>> 11-12**** >>> >>> Unsigned-16**** >>> >>> Packets received from this neighbor**** >>> >>> 13-…**** >>> >>> **** >>> >>> Number of entries based on response byte 1**** >>> >>> **** >>> >>> 1. Report “Neighbor Signal Levels”**** >>> >>> This report is sent periodically toward the Network Manager. The report >>> includes the statistics of discovered (but not linked) neighbors. These >>> neighbors might be discovered when a device has heard the neighbor >>> communication in the discovery links. A device that wish to join a network, >>> send a join request to the Network manager, including this report.**** >>> >>> Byte**** >>> >>> Format**** >>> >>> Description**** >>> >>> 0**** >>> >>> Unsigned-8**** >>> >>> Neighbor table index**** >>> >>> 1**** >>> >>> Unsigned-8**** >>> >>> Number of Neighbor entries read**** >>> >>> 2**** >>> >>> Unsigned-8**** >>> >>> Total number of neighbors**** >>> >>> 3-4**** >>> >>> Unsigned-16**** >>> >>> Nickname of neighbor**** >>> >>> 5**** >>> >>> Signed-8**** >>> >>> RSL of neighbor in dB**** >>> >>> 6-8**** >>> >>> **** >>> >>> Repeats (as needed) based on response byte 1**** >>> >>> **** >>> >>> 1. Alarm “Path Down” **** >>> >>> The alarm is sent upon detecting a path failure. **** >>> >>> Byte**** >>> >>> Format**** >>> >>> Description**** >>> >>> 0-1**** >>> >>> Unsigned-16**** >>> >>> Nickname of neighbor to which path failure was detected**** >>> >>> **** >>> >>> 1. Alarm "Source Route Failed"**** >>> >>> This alarm is sent upon detecting a source route failure.**** >>> >>> Byte**** >>> >>> Format**** >>> >>> Description**** >>> >>> 0-1**** >>> >>> Unsigned-16**** >>> >>> Nickname of unreachable neighbor in the source route**** >>> >>> 2-5**** >>> >>> Unsigned-32**** >>> >>> Network-Layer MIC (i.e., the MIC generated using the session key) from >>> the NPDU that failed routing**** >>> >>> **** >>> >>> 1. Alarm "Graph Route Failed"**** >>> >>> This alarm is sent upon detecting a graph route failure.**** >>> >>> Byte**** >>> >>> Format**** >>> >>> Description**** >>> >>> 0-1**** >>> >>> Unsigned-16**** >>> >>> Graph Id of the failed route**** >>> >>> **** >>> >>> >>> **** >>> >>> **** >>> >>> *ISA100.11a performance metric***** >>> >>> In ISA100.11a[2], the L2 performance metrics are reported to the System >>> Manager (act like PCE in 6TiSCH) and can be classified into (1) >>> DL_Connectivity alert and (2) NeighborDiscovery alert.**** >>> >>> 1. DL_Connectivity alert**** >>> >>> The DL_connectivity alert can be classified into (a) Per-neighbor >>> reports and (b) Per-channel reports. **** >>> >>> - *Per-neighbor report***** >>> >>> Per-neighbor reports are the performance metrics about the neighbors >>> connection and are reported to the System Manager. These statistics are >>> accumulated in the “dlmo.NeighborDiag” attribute, for each neighbor. This >>> report is similar to “Neighbor Health List” report in WirelessHART. **** >>> >>> Each node in ISA100.11a might be asked to report the following >>> statistics about its neighbor:**** >>> >>> **** >>> >>> Octets**** >>> >>> Format**** >>> >>> Description**** >>> >>> 1**** >>> >>> Signed-8**** >>> >>> RSSI (level)**** >>> >>> 1**** >>> >>> Unsigned-8**** >>> >>> RSQI (level)**** >>> >>> 1-2**** >>> >>> ExtDLUint**** >>> >>> RxDPDU(count): Number of valid Packets received from this neighbor **** >>> >>> 1-2**** >>> >>> ExtDLUint**** >>> >>> TxSuccessful (count):Count of successful unicast transmissions to the >>> neighbor **** >>> >>> 1-2**** >>> >>> ExtDLUint**** >>> >>> TxFailed (count): Number of unicast transmission, without getting any >>> ACK or NACK**** >>> >>> 1-2**** >>> >>> ExtDLUint**** >>> >>> TxCCA_Backoff (count): Number of unicast transmission aborted due to CCA >>> **** >>> >>> 1-2**** >>> >>> ExtDLUint**** >>> >>> TxNACK (count): Number of NACKs received**** >>> >>> 2**** >>> >>> Signed-16**** >>> >>> ClockSigma (level): A rough estimate of standard deviation of clock >>> corrections**** >>> >>> **** >>> >>> - *Per-channel report***** >>> >>> In addition, in ISA100.11a, several performance metrics are reported >>> based on channel for all neighbors to the System Manager. These statistics >>> are accumulated in the “dlmo.ChannelDiag” attribute. This report is similar >>> to “Device Health” report in WirelessHART.**** >>> >>> Byte**** >>> >>> Format**** >>> >>> Description**** >>> >>> 0-2**** >>> >>> Unsigned-16**** >>> >>> Count (Number of attempted unicast transmissions for all channels)**** >>> >>> 3**** >>> >>> Integer-8**** >>> >>> (Percentage of time transmissions on channel 0 did not receive an ACK)** >>> ** >>> >>> 4**** >>> >>> Integer-8**** >>> >>> (Percentage of time transmissions on channel 0 aborted due to CCA)**** >>> >>> …**** >>> >>> **** >>> >>> **** >>> >>> 33**** >>> >>> Integer-8**** >>> >>> (Percentage of time transmissions on channel 15 did not receive an ACK)* >>> *** >>> >>> 34**** >>> >>> Integer-8**** >>> >>> (Percentage of time transmissions on channel 15 aborted due to CCA)**** >>> >>> **** >>> >>> 1. NeighborDiscovery alert**** >>> >>> In ISA100.11a, each node sends a report, including a list of candidate >>> (overheard) neighbors, to the System Manager to make a potential new >>> routing decisions. The “dlmo.Candidates” attributed is used to store those >>> information in each node in the L2. This report is similar to the “Neighbor >>> Signal Levels” report in WirelessHART.**** >>> >>> Octets**** >>> >>> Format**** >>> >>> Description**** >>> >>> 1**** >>> >>> Unsigned-8**** >>> >>> N (count of discovered neighbors)**** >>> >>> 0-2**** >>> >>> ExtDlUint**** >>> >>> address**** >>> >>> 0-1**** >>> >>> Signed-8**** >>> >>> **** >>> >>> 0-1**** >>> >>> Unsigned-8**** >>> >>> **** >>> >>> …**** >>> >>> **** >>> >>> **** >>> >>> 0-2**** >>> >>> ExtDlUint**** >>> >>> address**** >>> >>> 0-1**** >>> >>> Signed-8**** >>> >>> **** >>> >>> 0-1**** >>> >>> Unsigned-8**** >>> >>> **** >>> >>> **** >>> >>> * ***** >>> >>> *References***** >>> >>> 1. IEC 62591: Industrial Communication Networks - Wireless >>> Communication Network and Communication Profiles - WirelessHART.**** >>> >>> **** >>> >>> 2. IEC 62734: Industrial communication networks - Fieldbus >>> specifications - Wireless systems for industrial automation: process >>> control and related applications - ISA100.11a.**** >>> >>> **** >>> >>> **** >>> >>> **** >>> >>> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On >>> Behalf Of *Thomas Watteyne >>> *Sent:* Saturday, September 07, 2013 7:43 PM >>> *To:* Xavi Vilajosana >>> *Cc:* Pascal Thubert (pthubert); 6tsch@ietf.org >>> *Subject:* Re: [6tsch] report flow contents**** >>> >>> **** >>> >>> Xavi,**** >>> >>> Great, thanks!**** >>> >>> Thomas**** >>> >>> **** >>> >>> On Fri, Sep 6, 2013 at 5:01 PM, Xavier Vilajosana Guillen < >>> xvilajosana@eecs.berkeley.edu> wrote:**** >>> >>> Hi, >>> I created the scratchpad section in the wiki to keep ideas >>> https://bitbucket.org/6tsch/meetings/wiki/Home >>> >>> >>> and added the flow content information here. >>> >>> https://bitbucket.org/6tsch/meetings/wiki/report_flow_contents**** >>> >>> have a nice weekend!**** >>> >>> X**** >>> >>> **** >>> >>> On Fri, Sep 6, 2013 at 10:43 AM, Xavier Vilajosana Guillen < >>> xvilajosana@eecs.berkeley.edu> wrote:**** >>> >>> Hi Pascal, it is a good idea!**** >>> >>> I will collect that information and as Thomas put it at the wiki so we >>> do not lose it. >>> >>> :-)**** >>> >>> X**** >>> >>> **** >>> >>> On Fri, Sep 6, 2013 at 8:51 AM, Pascal Thubert (pthubert) < >>> pthubert@cisco.com> wrote:**** >>> >>> Hello Xavi:**** >>> >>> **** >>> >>> At the call I mentioned we could use info on tracks and cells as well, >>> probably on demand from the PCE.**** >>> >>> For instance, the PCE could observe energy levels over some cells for a >>> while to make sure they are clean.**** >>> >>> **** >>> >>> What do you think?**** >>> >>> Pascal**** >>> >>> **** >>> >>> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On >>> Behalf Of *Xavier Vilajosana Guillen >>> *Sent:* vendredi 6 septembre 2013 01:17 >>> *To:* Thomas Watteyne >>> *Cc:* 6tsch@ietf.org >>> *Subject:* Re: [6tsch] report flow contents**** >>> >>> **** >>> >>> agreed!**** >>> >>> So the fields become:**** >>> >>> **** >>> >>> **** >>> >>> For each known neighbor:**** >>> >>> -ID**** >>> >>> -AVG RSSI in a running window**** >>> >>> -Latest RSSI**** >>> >>> -AVG LQI in a running window [optional]**** >>> >>> -Latest LQI [optional]**** >>> >>> -Num TX packets (option in case there is communication with that >>> neighbor)**** >>> >>> -Num ACK packets (option in case there is communication with that >>> neighbor)**** >>> >>> -Num RX packets (option in case there is communication with that >>> neighbor)**** >>> >>> -Last ASN when it heart about that neighbor **** >>> >>> -Bundle: Num links in the Schedule to that neighbor**** >>> >>> -PDR per link [Optional -- or maybe best and worst PDR only]**** >>> >>> **** >>> >>> -Option Flag (weather there are optional TLV fields on that category)** >>> ** >>> >>> +(TLV objects)* **** >>> >>> **** >>> >>> -For each Queue:**** >>> >>> - Avg Queue length in a running window**** >>> >>> - Max Queue length in a running window (peak)**** >>> >>> - Current Queue length (?)**** >>> >>> - ASN of the oldest packet in the QUEUE?**** >>> >>> -Option Flag (weather there are optional TLV fields on that category) >>> **** >>> >>> +(TLV objects)* **** >>> >>> **** >>> >>> -Time source parent**** >>> >>> -ID**** >>> >>> -Avg clock drift (correction done) in a running window**** >>> >>> -Latest clock correction**** >>> >>> -Parent changes (counter of how many times I changed my time source >>> parent)**** >>> >>> -Option Flag (weather there are optional TLV fields on that category) >>> **** >>> >>> +(TLV objects)* **** >>> >>> **** >>> >>> -Option Flag (weather there are optional TLV fields in other categories) >>> **** >>> >>> +(TLV objects)* **** >>> >>> **** >>> >>> as regards to this:**** >>> >>> **** >>> >>> "Finally, do you envision a generic mechanism whereby the PCE can turn >>> fields on/off, or triggered independently?"**** >>> >>> **** >>> >>> I see it as CoAP Options, where a set of bytes can be used as "clever >>> bitmap" to tell what options are there, the parsing will decode option by >>> option and will read the fields. In that way any combination of fields is >>> supported.**** >>> >>> **** >>> >>> would that work?**** >>> >>> X**** >>> >>> **** >>> >>> On Thu, Sep 5, 2013 at 4:03 PM, Thomas Watteyne < >>> watteyne@eecs.berkeley.edu> wrote:**** >>> >>> Xavi,**** >>> >>> **** >>> >>> Fantastic!**** >>> >>> **** >>> >>> I believe PDR for each link might be too long to fit in a packet. While >>> the mote will most likely keep that information, we could move that to the >>> query flow, i.e. it is available to the PCE on-demand.**** >>> >>> **** >>> >>> Would you agree that the number of links in a bundle belongs to the >>> neighbor? Of maybe we want a "bundle" category?**** >>> >>> **** >>> >>> In queuing, it might be interesting to see the age of the different >>> packets, to be able to monitor latency.**** >>> >>> **** >>> >>> About LQI, there is no general consensus among vendors on what the >>> definition is, or how exactly it is calculated. I would make it optional. >>> **** >>> >>> **** >>> >>> Also, it might be good to be able to add arbitrary fields to each >>> category: neighbor, queue, time source neighbor.**** >>> >>> **** >>> >>> Finally, do you envision a generic mechanism whereby the PCE can turn >>> fields on/off, or triggered independently?**** >>> >>> **** >>> >>> Thomas**** >>> >>> **** >>> >>> On Thu, Sep 5, 2013 at 12:47 PM, Xavier Vilajosana Guillen < >>> xvilajosana@eecs.berkeley.edu> wrote:**** >>> >>> Hi Thomas, Diego,**** >>> >>> **** >>> >>> I agree that LQI should be there as well. I update here the list with >>> Thomas suggestions. **** >>> >>> **** >>> >>> For each known neighbor:**** >>> >>> -ID**** >>> >>> -AVG RSSI in a running window**** >>> >>> -Latest RSSI**** >>> >>> -AVG LQI in a running window**** >>> >>> -Latest LQI**** >>> >>> -Num TX packets (option in case there is communication with that >>> neighbor)**** >>> >>> -Num ACK packets (option in case there is communication with that >>> neighbor)**** >>> >>> -Num RX packets (option in case there is communication with that >>> neighbor)**** >>> >>> -Last ASN when it heart about that neighbor **** >>> >>> **** >>> >>> Other fields**** >>> >>> -Num links in the Schedule to that neighbor**** >>> >>> -For each link PDR**** >>> >>> -For each Queue:**** >>> >>> - Avg Queue length in a running window**** >>> >>> - Max Queue length in a running window (peak)**** >>> >>> - Current Queue length (?)**** >>> >>> -Time source parent**** >>> >>> -ID**** >>> >>> -Avg clock drift (correction done) in a running window**** >>> >>> -Latest clock correction**** >>> >>> -Parent changes (counter of how many times I changed my time source >>> parent)**** >>> >>> **** >>> >>> -Option Flag (weather there are optional TLV fields)**** >>> >>> +(TLV objects)* **** >>> >>> **** >>> >>> **** >>> >>> Hope this makes sense.**** >>> >>> cheers! >>> Xavi**** >>> >>> **** >>> >>> On Thu, Sep 5, 2013 at 11:41 AM, Thomas Watteyne < >>> watteyne@eecs.berkeley.edu> wrote:**** >>> >>> *[renamed thread]***** >>> >>> **** >>> >>> Xavi,**** >>> >>> **** >>> >>> A few thoughts:**** >>> >>> - the counters (numTx, etc) will only be present for neighbors the node >>> has communicate with, so they should be optional in the packet.**** >>> >>> - you have focused on the topological information (which I think is the >>> right one). It might be useful to gather other data related to >>> synchronization or queuing.**** >>> >>> - I couldn't agree more with your suggestion to make it extensible. This >>> does mean that we will need to state somewhere that a device need to ignore >>> silently fields it does not understand.**** >>> >>> **** >>> >>> Thomas**** >>> >>> **** >>> >>> On Thu, Sep 5, 2013 at 11:15 AM, Xavier Vilajosana Guillen < >>> xvilajosana@eecs.berkeley.edu> wrote:**** >>> >>> Hello, I guess that flows are getting defined and I started to think on >>> the contents of the messages on that flows. Not sure if this is the right >>> time or I am going way far..**** >>> >>> **** >>> >>> According to the previous discussion I assume that the five flows are:** >>> ** >>> >>> **** >>> >>> ME-6TOP - Query Flow**** >>> >>> ME-6TOP - Action Flow**** >>> >>> **** >>> >>> 6TOP - ME - Report Flow**** >>> >>> 6TOP - ME - Event Flow**** >>> >>> 6TOP - ME - Request BW Flow**** >>> >>> **** >>> >>> I'd like to start defining the content of the messages in the Report >>> Flow:**** >>> >>> **** >>> >>> The Report Flow: has to deal with the information that a node knows and >>> has to be sent to the ME so the ME can compute the schedule among others. >>> Here I list the information that we can know in a mote and can be used at >>> the ME to compute the schedule (complete please if I miss something)**** >>> >>> **** >>> >>> For each known neighbor:**** >>> >>> -ID**** >>> >>> -AVG RSSI in a running window**** >>> >>> -Latest RSSI**** >>> >>> -Num TX packets**** >>> >>> -Num ACK packets**** >>> >>> -Num RX packets**** >>> >>> -Last ASN when it heart about that neighbor **** >>> >>> **** >>> >>> Other fields**** >>> >>> -Num links in the Schedule to that neighbor**** >>> >>> -For each link PDR**** >>> >>> **** >>> >>> **** >>> >>> Then we need to have some TLV like objects that can be used for >>> ad-hoc/naive/other extensions of the reporting process. In that way we >>> don't constraint the implementation of the scheduling alg. to that >>> information.**** >>> >>> **** >>> >>> what do you think?**** >>> >>> X**** >>> >>> **** >>> >>> On Fri, Aug 30, 2013 at 10:45 AM, Qin Wang <qinwang@berkeley.edu> wrote: >>> **** >>> >>> Hi all,**** >>> >>> **** >>> >>> In this thread, we will continue the discussion about Confirmation >>> message. Here is some background information.**** >>> >>> **** >>> >>> Context: e.g.**** >>> >>> - node sends a report and want to know if the report is accepted., * >>> *** >>> >>> - ME sends a action request and want to know if/when the action >>> taken.**** >>> >>> Options:**** >>> >>> (1) Nothing**** >>> >>> (2) Rely on transport mechanism (e.g. confirmable CoAP message)**** >>> >>> (3) App-level ACK type**** >>> >>> (4) Use different flow (i.e. action flow)**** >>> >>> **** >>> >>> IMHO, different control flow may have different requirement for >>> confirmation message.**** >>> >>> (1) Action Flow, needs a App-level confirmation, like Succ/Fail**** >>> >>> (2) Query Flow, automatically has the confirmation, i.e. the message >>> packet corresponding to a specific query.**** >>> >>> (3) Report Flow and Event Flow, option (1)-(3) are OK, but I prefer >>> option (1) and (3), i.e. the confirmation message is an option, but if a >>> confirmation message is needed, it should be App-level Ack, instead of >>> transport layer confirmation, which will give 6top more flexibility.**** >>> >>> **** >>> >>> What do you think?**** >>> >>> **** >>> >>> Thanks**** >>> >>> Qin**** >>> >>> **** >>> >>> **** >>> >>> _______________________________________________ >>> 6tsch mailing list >>> 6tsch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tsch**** >>> >>> **** >>> >>> >>> _______________________________________________ >>> 6tsch mailing list >>> 6tsch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tsch**** >>> >>> **** >>> >>> >>> _______________________________________________ >>> 6tsch mailing list >>> 6tsch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tsch**** >>> >>> **** >>> >>> **** >>> >>> >>> _______________________________________________ >>> 6tsch mailing list >>> 6tsch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tsch**** >>> >>> **** >>> >>> **** >>> >>> **** >>> >>> **** >>> >>> ** ** >>> >>> >>> _______________________________________________ >>> 6tsch mailing list >>> 6tsch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tsch**** >>> >>> ** ** >>> >> >> >> _______________________________________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tsch >> >> > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > > -- DIEGO DUJOVNE Académico Escuela de Ingeniería en Informática y Telecomunicaciones Facultad de Ingeniería UDP www.ingenieria.udp.cl (56 2) 676 8125
- [6tsch] report flow contents Thomas Watteyne
- Re: [6tsch] report flow contents Xavier Vilajosana Guillen
- Re: [6tsch] report flow contents Thomas Watteyne
- Re: [6tsch] report flow contents Xavier Vilajosana Guillen
- Re: [6tsch] report flow contents Thomas Watteyne
- Re: [6tsch] report flow contents Qin Wang
- Re: [6tsch] report flow contents Prof. Diego Dujovne
- Re: [6tsch] report flow contents Pascal Thubert (pthubert)
- Re: [6tsch] report flow contents Thomas Watteyne
- Re: [6tsch] report flow contents Xavier Vilajosana Guillen
- Re: [6tsch] report flow contents Xavier Vilajosana Guillen
- Re: [6tsch] report flow contents Thomas Watteyne
- Re: [6tsch] report flow contents P.Zand
- Re: [6tsch] report flow contents Thomas Watteyne
- Re: [6tsch] report flow contents Xavier Vilajosana Guillen
- Re: [6tsch] report flow contents P.Zand
- [6tsch] R: report flow contents Alfredo Grieco
- Re: [6tsch] report flow contents Thomas Watteyne
- Re: [6tsch] report flow contents Qin Wang
- Re: [6tsch] report flow contents Prof. Diego Dujovne
- Re: [6tsch] report flow contents Thomas Watteyne
- Re: [6tsch] report flow contents Qin Wang
- Re: [6tsch] report flow contents Qin Wang
- Re: [6tsch] report flow contents Prof. Diego Dujovne
- Re: [6tsch] report flow contents P.Zand
- Re: [6tsch] report flow contents Qin Wang
- Re: [6tsch] report flow contents Qin Wang
- Re: [6tsch] report flow contents Prof. Diego Dujovne
- Re: [6tsch] report flow contents P.Zand
- Re: [6tsch] report flow contents Qin Wang
- Re: [6tsch] report flow contents P.Zand