Re: [6tsch] report flow contents

[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
>
>