110 likes | 272 Views
Implementing WTRP on QNX. Ruchira S. Datta Berkeley WOW Group. Introduction to WTRP. Medium Access Control protocol for ad-hoc wireless networks Previously developed on simulation, UDP, and Linux kernel platforms Unified codebase Protocol itself encoded in core Core uses library calls
E N D
Implementing WTRP on QNX Ruchira S. Datta Berkeley WOW Group
Introduction to WTRP • Medium Access Control protocol for ad-hoc wireless networks • Previously developed on simulation, UDP, and Linux kernel platforms • Unified codebase • Protocol itself encoded in core • Core uses library calls • Platform-specific library deals with implementation issues
Next Platform: QNX • Microkernel OS for real-time/embedded applications • Integrate into existing communications stack • Being used for communication between unmanned helicopters
Message Passing in QNX • Process A loops waiting for events • Process B wants to send to Process A • Process B causes a proxy to be triggered in Process A • Process A receives the message from Process B
Library Model of Timers • Initialize timer with handler function and data to pass to it • Arm timer to go off at an absolute time in jiffies • When timer goes off, system calls handler function
QNX model of timers • Initialize timer with proxy to trigger • Arm timer to go off at an absolute time in nanoseconds since January 1, 1970 • When timer goes off, system triggers proxy
Implementing library timers in QNX • When first called, timer library sets a startup time • Timer library maintains dictionary of active timers, their handlers and data • Timer library allocates proxy per timer • When system triggers proxy, process event loop calls library function to dispatch timer handler • Timer library looks up proxy in dictionary and dispatches appropriate handler
Refactoring networking stack • Existing networking stack has one process per layer • Physical and link layers separate • However separation not clean • e.g., even physical layer knows application-level information • Put physical and link layers in one process • But encapsulated only layer-specific information in each module
Addressing Packets • Existing link layer addresses packets by helicopter ID • This is application-level information • Instead use MAC address, as is standard • Now need address resolution at networking layer between helicopter ID and MAC address
Mesh Discovery Protocol • Helicopter knows own ID number and how many are in mesh • "I-need" checklist: which ID numbers I need to know • Initially all others in mesh • "They-need" checklist: which other helicopters need my ID • Initally all others in mesh
Mesh Discovery Packets • When needs are unfulfilled, broadcast packets: • Own ID • Own MAC address • "I-need" checklist