M bile M te

1
M bile M te
Z. Morley Mao, H. Wilson So , Frederick Wong,
Shelley Zhuang
http//www.cs.berkeley.edu/shelleyz/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 Protocol State Diagram
retries exceeded/ Return ERROR!
App_AckRecvd
App_SendDone
Recv
New cell/ Update recvSeq
Done sending/ retries
Done
Done
Cell arrives
Ack Recvd
Recv Idle
Process cell
Start
Idle
Radio
Sending
Duplicate cell
retries not exceeded
Retx timeout
App wants to send/ Seq. number
Done
Done
ACK (piggy-back) sending
ReTx
Receiver Finite State Machine
Sender Finite State Machine
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
(40, 36) Reed-Solomon codes over GF(64)
Error Characteristics
Parity (4 Symbols)
0s (24 Symbols)
Encode
Data (36 Symbols)
27 Bytes
18 Bytes
3 Bytes
Parity (4 Symbols)
Transmit
Data (36 Symbols)
Parity (4 Symbols)
Decode
0s (24 Symbols)
Data (36 Symbols)
Auto-Correlation of Bit Errors
Error probability of the t-th bit (in future)
given that the current bit is corrupted
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