Net2WG/Notes/20070727
Present: Razvan, Om, Phil, Mike, Matus, Rodrigo, Kyle
O: add anything?
P: 2.0.2 about to go out, after that 2.1. what do we want to be in 2.1.
O: will be third; first will be white bit
White bit discussion
O: experiments looking at LQI, CTP; so far white bit bad idea because LQI not performing well. Will run on different testbed (Mirage). If LQI doesn't perform well, white bit not good idea.
P: MultihopLQI is for cc2420; uses ~BER to choose routes. Likes to choose long routes of high quality links rather than shorter routes of intermediate quality links. CTP doesn't use PHY-layer info. USC testbed results now show CTP doing better than LQI. White bit hypothesis had been that if PHY-layer info useful, then pass it up.
O: 70-80% delivery ratio with LQI.
P: if we see reverse in Mirage, then what's different about testbeds?
R: one possible factor -- assymetry not good for LQI.
P: hypothesis would be there are lots of assymetric links on TutorNet.
O: channel shouldn't interfere with 802.11 (channel 26)
O: if Mirage results not different, then tentatively conclude CTP better
P: if Mirage results same as paper, then LQI beats CTP. Question is are good links that CTP wasn't using.
O: beacons still have high LQI values despite high packet drops.
R: performance was comprable wrt delivery
O: all bad wrt LQI now
6lopan discussion
O: Mattus interested in contributing stack. Tell us about status, timeline, help, testing, etc.
M: not doing mesh networking, but can parse headers. Can fragment large packets, reassemble. IPv6 on top. Can process compressed IPv6 pkts. Don't process compressed UDP fields (need bit shifting). Can reply to echo requests. Can connect to UDP ports and exchange datagrams. Can download from homepage.
P: both HT1 and HT2?
M: yes have done both.
P: bit shifting within header or payload?
M: byte alignment issue
P: Draft 13 doesn't specify padding; will be in RFC. Text unfortunately doesn't say this.
M: non-zero flow label 20 bits, byte-alignment helps.
P: emailed 6lopan about this?
M: yes
P: will be cleaned up
M: have to keep track of some offsets in code; shouldn't be much of a problem.
O: timeline, testing? two-mote testing sufficient?
M: motes don't do routing
O: test with >2 motes?
M: no
P: more important to test against other implementations.
M: another impl available which runs on HW don't have.
M: 802.15.4 compliance?
P: 6lopan intends to be above 802.15.4 link layer, but not MAC layer.
R: how are two motes physically connected?
M: computer with 3 usb ports: one to mote, other two motes run 6lopan stack, two motes and computer have IP addrs. Computer is default route for subnet, within subnet all motes use computer for default route. Picture shows this.
O: need SW on computer?
M: no computer with 802.15.4 interface, no 6lopan in computer kernel. Software encapsulates 802.15.4 data frame, decompresses, passes to kernel via virtual tunnel interface. First started with IPv4, can do IPv4 as well. In other direction, kernel sends to tun file descriptor, compresses headers, dispatches to AM header, mote basestation app, sends to mote.
M: problem -- would like to send 802.15.4 pkt; problem how to do via TinyOS. TinyOS AMs use 802.15.4 data frames. Problem is hard to change on per-packet basis AM type field.
P: AM type field is dispatch field in 6lopan packet. Answer is to (1) go below AM layer and send raw packets, or (2) use AM type field as 6lopan dispatch field. Wire to parameterized interface.
M: 6lopan headers all have dispatch values.
P: can show code. Might be better to circumvent AM layer. Will get IANA dispatch value so can have 6lopan stack running in parallel.
M: don't do neighbor discovery; always broadcast to 0xff link layer multicast address.
M: IPv6 address configuration; prefix hardcoded, suffix taken from mote address.
M: part want to ask for help; fragments -- when sending large packet from mote to PC, PC receives all fragments. Not all fragments make it to mote. Lose some fragments. Helps if sleep 10 us between sending subsequent packets. Suggestions?
O: similar to tens of packets to forward, wait time?
P: guess that packets are dropped at base station
M: toggle blue light
P: serial port, not radio. Telos node serial 115Kbits/s TinyOS can't handle telos serial at full speed.
M: README toggle led 2? or just drop?
P: serial packets come too fast, corrupt/drop. Ben Greenstein looking, best hypothesis is interrupt processing speed.
O: help to process interrupts faster?
P: happens on tmote sky running at 8 MHz.
O: default 4 MHz?
P: yes
M: what to do?
P: 10 us sleep between packets is the right thing.
M: still not 100% delivery.
O: another platform to consider is MicaZ. Plan?
M: End of September can look again; would like to try to integrate it into TinyOS.
O: okay to create a directory.
P: will require changes to CC2420 stack to do it right. core planning to do once 6lopan stack appeared. Upcoming release will do that, then much easier to drop stack in.
Plans for 2.1
O: possibly 6lopan. Zigbee stack? problably will take much longer. Just heard about dissemination.
P: 2.1 will include changes to core interfaces. After some use, minor tweaks. No restructuring code, just change lines.
O: 3-5 months dissemination code probably.
O: should definitely put in white bit or not. any other projects? summarized status of projects.
