M bile M te

1
M bile M te
Z. Morley Mao, H. Wilson So , Frederick Wong,
Shelley Zhuang zmao, so, fredwong,
shelleyz_at_CS.Berkeley.EDU CS268 Spring 2000
Computer Networks Professor Anthony
Joseph CS294-8 Spring 2000 Deeply Networked
Systems Professors David Culler and Randy
Katz May 12, 2000 http//www.cs.berkeley.edu/sh
elleyz/SS00project/
2
Motivation

• Desirable Features
• Individual addressability of motes
• Fine granularity of sensor data
• High degree of mote mobility
• Adjustable reliability of sensor data delivery
• Familiar programming interface on motes
• Applications
• Parcel locator (UPS)
• Tracking migrating birds
• Earthquake post mortem analysis
• Dynamic reconfiguration of motes

3
Design Decisions

• Trading off performance for simplicity, ease of
  programming
• simple, familiar programming interface
• simplified transport protocol no congestion
  control
• no route optimization -- triangular routing
• no need for handoffs -- short-lived connections
• stop-and-wait link layer protocol with
  retransmissions, adjustable reliability
• split connection approach ACKs are not
  end-to-end
• Performance, throughput, power consumption
  enhancement
• piggy-backing ACKs
• Error-correction coding for data packets
• Base-station beacons instead of remote mote
• Remote motes do not initiate communication
• Leverage concepts in Mobile IP for roaming
• Addressing remote mote using its home
  basestation IP and its unique port number

4
For example, TCP to RDP TranslationRDP Reliable
Datagram Protocol
Mote Application
TCP Application
Reassembly
Data Request
. . .
Data Reply
Cell
Cell
Data Reply
Data Request
Socket Interface
Translator
Cell
Hdr
Cellularization
RDP
RDP
. . .
Cell
Cell
. . .
Re-transmission Reed-Solomon/CRC
Cell
Hdr
Cell
CRC
Hdr
CRC
RF Channel
5
RDP State Diagram (sender)
APP_AckRecvd
APP_SendDone
Done
Done sending / retries
Done
Ack Recvd
Start
NotSending
Sending
Radio
App wants to send
retries not exceeded
Retx timeout
Retx
retries exceeded / Return ERROR!!
6
Mote Application Programming Interface
Rmote API Operation socket() Creates the
internal data structure and prepares the mote to
send/recv bind() Sends a BOOTP_REQ to proxy and
requests a port number, waiting for the
BOOTP_REPLY to confirm registration listen() Se
nds a BOOTP_ACK to proxy to accept
future connections accept() Blocks until
receipt of TCP_SYN, returns the
file descriptor recv() Uses the file
descriptor to receive TCP data stream send() Use
s the file descriptor to send data close() Sends
a TCP_FIN to close the connection
2 - BOOTP_Reply
1 - BOOTP_Req
3 - BOOTP_Ack
7 - TCP Data
5 - TCP_Syn
8 - TCP_Fin
6 - TCP Data
B-M te
Home Proxy
4 - HTTP Request
9 - HTTP Reply
Browser
7
Roaming - Foreign Registration
Oops, roaming
. . . . . .
1 - BOOTP_Beacon
2 - BOOTP_Req
4 - BOOTP_Ack
3 - BOOTP_Reply
8 - TCP_Syn
5 - Setup Tunnel
B-M te
Hey, forward the connection!
Home Proxy
Foreign Proxy
7 - Forward TCP Connection
6 - HTTP Request
Browser
8
Channel Characteristics and Error Correction
(28, 24) Reed-Solomon codes over GF(256)
Encode
Transmit
2 Bytes (unusable)
4 Bytes Parity
24 Bytes Data
4 Bytes Parity
227 Bytes of 0s . . .
Decode
24 Bytes Data
9
Experience and Conclusion

• Understanding TCP internals
• Mobile IP state transitions
• Error correction on RF link
• Mote programming is extremely hard
• no debugging tools available
• limited memory, no dynamic memory allocation
• send and receive sharing the same buffer sucks!
• Event-based programming model makes sense for
  high-performance, resource-constrained
  environment
• ACKs having small separate buffers really helps!
• Piggy-backed ACKs really helps for
  request-response applications