Re: [6tsch] report flow contents

[Qin Wang <[e-mail]>]

Hi Diego,

Comparing the per-frequency report with the RSSI/LQI in the per-neighbor
report defined on
https://bitbucket.org/6tsch/meetings/wiki/report_flow_contents, I think the
first one refers to the radio condition in a area, not specific to a
neighbor; and the second one likely focuses on the average  RSSI/LQI of all
frequencies applied in a cell/bundle, not specific to a radio frequency.
Make sense?

Thanks
Qin



On Fri, Sep 13, 2013 at 10:23 PM, Prof. Diego Dujovne <
[e-mail]> wrote:

> 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 <[e-mail]>
>
>> 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 <
>> [e-mail]> 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 <
>>> [e-mail]> 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:* [e-mail] [mailto:[e-mail]] *Per
>>>> conto di *[e-mail]
>>>> *Inviato:* Wednesday, September 11, 2013 10:45 PM
>>>> *A:* [e-mail]; [e-mail]
>>>> *Cc:* [e-mail]
>>>> *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:* [e-mail] [mailto:[e-mail]] *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 <
>>>> [e-mail]> 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, <[e-mail]> 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:* [e-mail] [mailto:[e-mail]] *On
>>>> Behalf Of *Thomas Watteyne
>>>> *Sent:* Saturday, September 07, 2013 7:43 PM
>>>> *To:* Xavi Vilajosana
>>>> *Cc:* Pascal Thubert (pthubert); [e-mail]
>>>> *Subject:* Re: [6tsch] report flow contents****
>>>>
>>>>  ****
>>>>
>>>> Xavi,****
>>>>
>>>> Great, thanks!****
>>>>
>>>> Thomas****
>>>>
>>>>  ****
>>>>
>>>> On Fri, Sep 6, 2013 at 5:01 PM, Xavier Vilajosana Guillen <
>>>> [e-mail]> 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 <
>>>> [e-mail]> 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) <
>>>> [e-mail]> 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:* [e-mail] [mailto:[e-mail]] *On
>>>> Behalf Of *Xavier Vilajosana Guillen
>>>> *Sent:* vendredi 6 septembre 2013 01:17
>>>> *To:* Thomas Watteyne
>>>> *Cc:* [e-mail]
>>>> *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 <
>>>> [e-mail]> 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 <
>>>> [e-mail]> 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 <
>>>> [e-mail]> 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 <
>>>> [e-mail]> 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 <[e-mail]>
>>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/6tsch****
>>>>
>>>>  ****
>>>>
>>>>
>>>> _______________________________________________
>>>> 6tsch mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/6tsch****
>>>>
>>>>  ****
>>>>
>>>>
>>>> _______________________________________________
>>>> 6tsch mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/6tsch****
>>>>
>>>>  ****
>>>>
>>>>  ****
>>>>
>>>>
>>>> _______________________________________________
>>>> 6tsch mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/6tsch****
>>>>
>>>>  ****
>>>>
>>>>  ****
>>>>
>>>>  ****
>>>>
>>>>  ****
>>>>
>>>> ** **
>>>>
>>>>
>>>> _______________________________________________
>>>> 6tsch mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/6tsch****
>>>>
>>>> ** **
>>>>
>>>
>>>
>>> _______________________________________________
>>> 6tsch mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>
>>>
>>
>> _______________________________________________
>> 6tsch mailing list
>> [e-mail]
>> 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
>