Net2WG/Notes/20070608

From TinyOS Wiki
Revision as of 10:49, 1 August 2012 by Gnawali (talk | contribs) (New page: ## page was renamed from Notes/20070608 Present: Razvan, Mike, Kyle, Phil, Om. O: why will grey bit be useful? Across platforms. Suggestion was nbr tbl P: context. big issue in core w...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
    1. page was renamed from Notes/20070608

Present: Razvan, Mike, Kyle, Phil, Om.

O: why will grey bit be useful? Across platforms. Suggestion was nbr tbl

P: context. big issue in core was pkt metadata. acks needed, what about rssi, lqi, ...? discussed a lot, nothing happened. core consensus was that net2 should think about this, tell us requirements.

P: physical layer info: multihoplqi is good, single packet => good routes/links from PHY layer info. low ctl traffic overhead. local interference causes multihoplqi to fail. So use PHY to seed CTP neighbor table.

O: no argument against that idea. Does it have to be HW indep? MultihopRSSI?

P: Only using RSSI not so useful; snr matters.

O: CC1000/RSSI would work well?

P: CTP would improve, more agile with PHY info.

O: specifically for CTP protocols?

P: yes. Why doesn't CTP use LQI? Best if we have a simple abstraction.

O: why one bit?

P: fewer bits are simpler

K: experiments will tell us

P: [Occam's Razor]

P: LQI from CC2420 is not actually 15.4 LQI. 15.4 trying to be vague.

K: how 2420 computes LQI?

P: soft-chip decision

P: in theory can go up to 127, in practice never below 50

O: seems useful. can't hurt CTP if we use it properly.

P: what do we care most about? very good link vs. link on the edge.

K: from one packet, with one bit of information, how would we map that information to a fresh nbr tbl entry? Would we do it with min etx?

O: could not be a number, could be a tag

P: one way: normally never consider nbr entry valid until receive a number of packets (mature). so if value=1, then mature.

K: how about if 1, 0, 1, 0...

O: and etx 100%

P: if receive pkt with 1, then mature, if 0, then may or may not

K: maybe that scenario should be designed to be rare

P: signal of packet 8 dbm > noise floor, then mark with 1

K: hysteresis?

P: apply hysteresis, but data per-packet

O: provider not allowed to use information from more than one packet

O: difficult in 802.11? bit set when link good

P: bit not set when link good, bit set when packet had low BER/high SNR suggesting link not in gray region. measurement per-packet

O: 802.11 -- information

P: need to demonstrate that it's adventagous

P: multihoplqi uses function (poly) of LQI, will cause you to pick links with low BER. In practice is acting like 'is this really good'

O: 2-3 bits of information

K: analyze the values that multihoplqi uses, see how many bits we need.

K: why doesn't mesh networking use lqi?

P: chips give RSSI. They've taken close look at RSSI, rake receivers. ISI.

P: change to how CTP works wrt thresholds. new thresholds for choosing a different route (1.5 ETX smaller). CTP was stuck @ 3.2, multihop @2, ctp couldn't switch over unless it found 1.7.

P: expts for CTP: experiment with lower thresh. second experiment is to run multihoplqi and collect link metrics used for parents, look at set of values.

P: will be network specific

O: if small # bits, one bit good enough

O: in terms of thresh?

P: sent to email list threshold settings. single packet across several intervals will not cause you to switch links, anything more might.