1 / 9

M bile M te

M bile M te. Z. Morley Mao, H. Wilson So , Frederick Wong, Shelley Zhuang. http://www.cs.berkeley.edu/~shelleyz/SS00project/. Motivation. Desirable Features: Individual addressability of motes Fine granularity of sensor data High degree of mote mobility

dagan
Download Presentation

M bile M te

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 Request Data Reply 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_AckRecv’d App_SendDone Recv New cell/ Update recvSeq# Done sending/ # retries++ Done Done Cell arrives Ack Recv’d Recv Idle Process cell Idle Radio Start 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. R-M te Mote Application Programming Interface Rmote APIOperation 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(…) Sends 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(…) Uses 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 6 - TCP Data 8 - TCP_Fin B-M te Home Proxy 4 - HTTP Request 9 - HTTP Reply Browser

  7. R-Mote Application in accept(…); 1. The R-Mote receives a BOOTP_Beacon (IP address != home IP address), which means it needs to register with the Foreign Proxy 2. The R-Mote sends a BOOTP_Req to the Foreign Proxy with the home IP address for registration 3. The Foreign Proxy sends a BOOTP_Reply to the R-Mote 4. The R-Mote receives the BOOTP_Reply, saves the information, and sends a BOOTP_Ack asking the Foreign Proxy to accept future connections 5. The Foreign Proxy sets up a tunnel with the Home Proxy, which will forward future connections to the Foreign Proxy’s handler 6. A browser sends a HTTP request to the Home Proxy 7. The Home Proxy’s port handler forwards the data to Foreign Proxy’s port handler 8. The Foreign Proxy sends a TCP_Syn to the R-Mote R-M te Tunnel Handler Mote Port Handler Mote Port Handler Roaming - Foreign Registration Oops, roaming . . . . . . 1 - BOOTP_Beacon 4 - BOOTP_Ack 2 - BOOTP_Req 3 - BOOTP_Reply 8 - TCP_Syn 5 - Setup Tunnel B-M te Hey, forward the connection! Foreign Proxy Home Proxy 7 - Forward TCP Connection 6 - HTTP Request Browser

  8. Range Cell Error Rate Bit Error Rate 2 meters 22.8 % 0.57 % 4 meters 34.9 % 0.58 % Channel Characteristics and Error Correction Error Characteristics (40, 36) Reed-Solomon codes over GF(64) Parity (4 Symbols) 0s (24 Symbols) Encode Data (36 Symbols) 27 Bytes 3 Bytes 18 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

More Related