10 likes | 215 Views
Controller node. Core modules. System modules. DB. Channel manager. Reporter. OAM. Routing manager. Dissemi- nator. Communicator. Visualizer. Power manager. Neighbor discovery. Web server. Schedule manager. Topology manager. Monitoring manager.
E N D
Controller node Core modules System modules DB Channelmanager Reporter OAM Routingmanager Dissemi-nator Communicator Visualizer Power manager Neighbor discovery Web server Schedule manager Topologymanager Monitoringmanager CentMesh: Modular and Extensible Wireless Mesh Network Testbed J. Lim, P. H. Pathak, M. Pandian, U. Patel, G. Deuskar, A. Danivasa, R. Dutta, M. SichitiuNorth Carolina State University, Raleigh, NC, USA Software Architecture Hardware Components Motivation • Developing software, controlling testbed resources, and running experiment in a wireless mesh testbed is a challenging task because of: • Dependencies between software • Distributed operations in a multihop topology • Limited abstraction of the testbed environment Mesh node • No customized devices • Off-the-shelf desktop computers • Up to 4 Atheros wireless cards • Autocraft marine batteries • GPS (Garmin 18x) • Indoor deployment with 10-12 mesh nodes • PVC pipe for separation between antennas System modules Core modules Reporter Channelagent Dissemi-nator Routingagent Communicator Neighbor discovery Power agent TCP OAM Requirements Schedule agent Monitoringagent • Loosely coupled system • Modular programming library • Separation of common operations from core modules • No dedicated backhaul network System modules Core modules TCP Reporter Channelagent Dissemi-nator Routingagent Introduction Communicator • Modular and extensible testbed • Clear separation between data, control,and management planes Neighbor discovery Power agent Network Monitoring and Visualization • Inter-process communication via a single process called the Communicator • Plug-and-play of modules • Centralized management via paired managers and agents OAM Schedule agent Monitoringagent Decision making for routing, scheduling, power control etc. (intelligence of network) Management Plane Mesh node MCP MCP Signaling, control messages, neighbor information MCP MCP Control Plane Actual data transfer, queuing, forwardingetc. Programming Structure Data Plane Publish Inter-process Communication Subscriber Internalsession ComClientT Node B remote publish Receive message . virtual incomingMessage(msg) . connect() . subscribe(topic) . publish(msg) . requestDisseminate(msg) . requestReport(msg) Communicator Process Node A TCP Com API local publish Communicator Process Future Work subscribe TCP publish Com API Process switch (topic) case topic1 : case topic2 : default : • Research studies • Coarse-grain TDM scheduling • Back-pressure medium access control • Diverse routing • Joint channel assignment and routing • Ongoing extensions • Outdoor deployment • Release the software suite under open source license Communicator receive Com API Application (subclass) subscribe Process remote publish incomingMessage(msg){ //Handle messages } receive Process Com API Com API Communicator Publish to remote machine TCP • Event-driven programming structure • Asynchronous handling of messages by inheriting from a class calledSubscriber subscribe(topic1); subscribe(topic2); subscribe Process • Publish and receive messages based on the topic • Enable a loosely coupled system receive Com API Node C NC STATE UNIVERSITY | COMPUTER SCIENCE DEPT. |ELECTRICAL & COMPUTER ENGINEERING DEPT. |SECURE OPEN SYSTEM INITIATIVE (SOSI)