Your SlideShare is downloading. ×
Adaptive Dynamic Radio Open-source Intelligent Team (ADROIT): C
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Adaptive Dynamic Radio Open-source Intelligent Team (ADROIT): C

216

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
216
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • ** no current system exposes all these parameters. Current max is approx 100 total, of which 30 are controllable. There are many interesting challenges for AI in networking. The most immediate one is the massive scale involved: there are roughly 600 observable parameters and 400 controllable parameters (possibly continuous-valued) to configure per node 2. We thus have a distributed, low-communication, partially-observable, high-latency optimization problem of approximately ¹PN choices per timestep3; one second would be a large timestep. Characteristics that make this an interesting domain for AI include: Low-communication: Nodes cannot share all knowledge with all other nodes; it would overwhelm the network. Partially-observable: Many factors that affect communication can not be observed. Few radios, for example, have a “fog” sensor. High-latency: Many actions cause a delayed effect. For example, data transmissions from one node may only affect downstream nodes; the result takes time to propagate back to the first transmitter. Ambiguous observations: Detection and understanding of a change in situation is not always simple. For example, how does the system automatically tell the difference between short-term fade versus entering a building? Complex interactions: Networking parameters have deep, poorly-understood interactions with each other and with system performance. In many cases, specific pair-wise interactions can be identified, such as increased power reduces battery life. However, most of these pair-wise interactions are carefully caveatted by the networking community, with conditionals that are rarely observable or computable. Cognitive control in the general case is therefore seldom simple: the level at which symptoms appear may not be the level at which changes to the node configuration must be made; symptoms may be ambiguous at one level or at a given time and require more context; changes at one layer may impact other layers and may cause new issues; and the timing of changes may be critical. Complex temporal feedback loops: Within a node, certain activities occur at very rapid speeds (e.g., between the Medium Access Control (MAC) and Physical layers) requiring very a very tight feedback loop to support cognitive control. Other activities (e.g., at the Routing layer) occur on a longer time-scale and cognitive control algorithms may need to take into account a wider range of factors in a slow feedback loop. Between nodes, there is yet a longer feedback loop between changes that are made and the effects that are observed in network-level performance. The variety of temporal loops and their dramatic speed differences means that correlating
  • Recent developments in software defined radio technology have opened up the opportunity to develop networks that are, in principle, highly adaptable and effective under a much wider range of operating conditions than currently possible. However, while these tools provide new flexibility, none have addressed the issue of how to manage or control them [1; 5; 9], instead expecting the network designer to appropriately exploit the tools. The unfortunate aspect of these approaches is that they rely on APIs that are carefully designed to expose each parameter separately. This approach to network configuration is not maintainable, nor amenable to cognitive control , particularly as protocols are redesigned or new parameters are exposed. Even ECLAIR [14], which claims to be “the first generic architecture for cross layer feedback,” still relies on detailed API function calls for each independent parameter, e.g. set_application_- priority(), set_active_interface(), and get_contention_window(). We need one consistent, generic, interface for all modules to expose their parameters and dependencies. ADROIT is the first architecture that supports changes to existing protocols and the addition of new protocols, without changes to other existing components .
  • Recent developments in software defined radio technology have opened up the opportunity to develop networks that are, in principle, highly adaptable and effective under a much wider range of operating conditions than currently possible. However, while these tools provide new flexibility, none have addressed the issue of how to manage or control them [1; 5; 9], instead expecting the network designer to appropriately exploit the tools. The unfortunate aspect of these approaches is that they rely on APIs that are carefully designed to expose each parameter separately. This approach to network configuration is not maintainable, nor amenable to cognitive control , particularly as protocols are redesigned or new parameters are exposed. Even ECLAIR [14], which claims to be “the first generic architecture for cross layer feedback,” still relies on detailed API function calls for each independent parameter, e.g. set_application_- priority(), set_active_interface(), and get_contention_window(). We need one consistent, generic, interface for all modules to expose their parameters and dependencies. ADROIT is the first architecture that supports changes to existing protocols and the addition of new protocols, without changes to other existing components .
  • Rather than have each module with its own unique set of setMyParam() and getMyParam(), use a generic interface that manages all parameters in the stack. Other modules (like QoS, CLI) can hook in using the same mechanism as the Cognitive Controller
  • The ADROIT architecture provides rich support for cognitive applications, and allows the creation of a system that recognizes that the situation has changed and adapts the node for improved performance; anticipates changes in networking needs and plans appropriate changes in configuration for improved performance; and is able to make the appropriate changes needed in any module within a node, at any level of the networking stack and across multiple nodes of the network.
  • The primary metric improved by about 10% due to learning (Table I). Our improvement of roughly 10% is more significant than it appears. Each of the nodes makes roughly 25% of the observations, and 10% of the minimum observations present is more like 15% of the observations sent from one node to other nodes. The system is stressed, but because the internode ranges vary greatly, the system’s throughput can be expected to vary greatly. Progress made during good times will dominate average progress, and a metric that tries to capture the amount of incremental sharing achieved during the worst 30 seconds might well show much greater (or less) improvement.
  • Benefits and scope of cross-layer design . Most networking people are familiar with “cross-layer design.” However, within the networking community, this concept usually means two layers, and one or two parameters in each layer. Networking people were generally somewhat skeptical about how much benefit multi-layer coordination would bring. Together, we developed detailed drill-down walkthroughs, each focusing on how certain changes in parameters could produce novel changes in networking protocols and behavior under certain observed conditions. The walkthrough process benefitted both groups, with networking people becoming more accepting of systemwide cognitive control, AI people understanding more of the reasons for traditional networking approaches, and everyone having a better understanding of how to make the new approach work better.
  • Reliance on a centralized Broker . Parts of the broker are similar to traditional network management, but the new system architecture called for the broker to be a mandatory part of the system, with failure of the broker having grave consequences. Networking design has tried to minimize the number of components that must be relied upon, and relying on something “cognitive” (and therefore complicated and not entirely predictable) was viewed with particular suspicion. Therefore each network module was expected to have a failsafe default operation that would work, even when the Broker was not functional. Asynchrony and Threading The AI people were used to programming in languages such as Java were threaded operation was the norm, and programs waiting for an answer might make a blocking call in a worker thread. The networking people understood this model, but outright rejected an approach that would require network modules to be written in this manner. Much networking code is written in a single thread that must make only non-blocking code, and it is often in an OS kernel with a reduced programming environment. We implemented the Broker so that the client library to be linked with networking modules could be used by non-threaded programs.
  • Relinquishing control outside the stack. Networking people were very concerned about an outside controller making decisions about performance. AI researchers meanwhile, like to say “give me everything and I’ll give you the answer.” Neither extreme is appropriate. We therefore added several technical modules that helped us meet in the middle, including “failsafe” mechanisms that would allow a network module to reject things that didn’t make sense, and constraint publishing & checking mechanisms that would require the Cognitive Layer to keep settings consistent. The walkthroughs also helped both sides to see the concerns and benefits. e.g. key length = 1 bit. Heterogeneous and non-interoperable nodes. A deeplyheld tenet in networking is conformance to written protocol specifications; all nodes must always follow the protocol, and from this one can conclude that they will interoperate (but one cannot guarantee maximal performance). Further, most nodes are homogeneous. Cognitive controllers enable the network to become heterogeneous to the point of non-interoperability, resulting in possible failure of the nodes to communicate, but also enabling greater performance when managed correctly. To address the mandate of maintaining connectivity, while allowing for heterogeneity, our architecture includes an“orderwire” bootstrap channel to be used when a node can not communicate with the rest of the network. We planned to explore several different mechanisms for coordinating the heterogeneity.
  • Boundaries . In traditional networking approaches, there is a very clear boundary between application and network module—often corresponding to a user/kernel boundary with a widely known API (e.g., “BSD sockets”). Similarly, there is a clear boundary between controller and controllee. With the generic approach to exposing and controlling parameters, these boundaries blur. Any client of the Broker can choose to expose controllable param eters, and any client can choose to set another module’s parameters. Thus, an application can choose to have complete visibility into the stack, or be told to back off by the network. While both groups believed that better performance could be achieved, the AI people focused more on the benefits of flexibility and the networking people more on their concerns that complexity would lead to unreliable systems. We expect that removing traditional restrictions will result in interesting and significant new ideas.
  • Time permitting, worth explaining why we’d want a clearinghouse. Discuss why it Solves an m * n problem (new modules, new management and cognitive tools -- Have them interface to the Broker instead of each other)
  • Modular software surrounded by ancillary systems to manage configuration and cognitive control. Applications can simply send and receive data through the software stack. Or they can get involved in changing the behavior of the stack, either directly (by sending requests through the Broker to effect changes) or indirectly (by asking Cognitive Control to improve performance).
  • Transcript

    • 1. An Architecture to Support Cognitive-Control of SDR Nodes Karen Zita Haigh [email_address]
    • 2. Roles for AI in Networking
      • Cyber Security
      • Network Configuration (which modules to use)
      • Network Control (which parameter settings to use)
      • Policy Management
      • Traffic Analysis
      • Sensor fusion / situation assessment
      • Planning
      • Coordination
      • Optimization
      • Constraint reasoning
      • Learning (Modelling)
        • Complex Domain
        • Dynamic Domain
        • Unpredictable by Experts
      AI enables real-time, context-aware adaptivity
    • 3. Network Control is ready for AI
      • Massive Scale : ~600 observables and ~400 controllables per node.
      • Distributed: each node must make its own decisions
      • Complex Domain:
        • Complex & poorly understood interactions among parameters
        • Complex temporal feedback loops (at least 3: MAC/PHY, within node, across nodes); High-latency
      • Rapid decision cycle: one second is a long time
      • Constrained: Low-communication: cannot share all knowledge
      • Incomplete Observations:
        • Partially-observable: some things can not be observed
        • Ambiguous observations: what caused the observed effect?
      Human network engineers can’t handle this complexity!
    • 4. A Need for Restructuring
      • SDR gives opportunity to create highly-adaptable systems, BUT
        • They usually require network experts to exploit the capabilities!
        • They usually rely on module APIs that are carefully designed to expose each parameter separately.
      • This approach is not maintainable
        • e.g. as protocols are redesigned or new parameters are exposed.
      • This approach is not amenable to real-time cognitive control
        • Hard to upgrade
        • Conflicts between module & AI
      Module 1 Module 2
    • 5. A Need for Restructuring
      • We need one consistent, generic, interface for all modules to expose their parameters and dependencies.
      Module 2 Module 1
    • 6. A Generic Network Architecture exposeParameter( parameter_name , parameter_properties ) setValue( parameter_handle , parameter_value ) getValue( parameter_handle )
      • Broker
      • Assigns handles
      • Provides directory services
      • Sets up event monitors
      • Pass through get/set
      Cognitive Control Command Line Interface Network Management Registering Modules Re/Setting Modules Observing Params Registering Modules & Parameters Re/Setting Modules Observing Params Applications / QoS Network Stack Network Module Network Module
    • 7. Benefits of a Generic Architecture
      • It supports network architecture design & maintenance
        • Solves the n х m problem (upgrades or replacements of network modules)
      • It doesn’t restrict the form of cognition
        • Open to just about any form of cognition you can imagine
        • Supports multiple forms of cognition on each node
        • Supports different forms across nodes
    • 8. An example: Adaptive Dynamic Radio Open-source Intelligent Team (ADROIT) BBN, UKansas, UCLA, MIT
    • 9. ADROIT’s mission
      • DARPA project
      • Create cognitive radio teams with both real-time composability of the stack and cognitive control of the network.
      • Recognize that the situation has changed
      • Anticipates changes in networking needs
      • Adapts the network, in real-time, for improved performance
        • Real-time composability of the stack
        • Real-time Control of parameters
        • On one node or across the network
    • 10. Experimental Testbed Maximize % of shared map of the environment
    • 11. Experiment Description
      • Maximize % of shared map of the environment
      • Goal: Choose Strategy to maximize expected outcome given Conditions.
        • Each node chooses independently, so strategies must be interoperable
      • Measure conditions
        • signal strength from other nodes
        • location of each node
      • Strategies:
        • 2 binary strategy choices for 4 strategies
      • How to send fills to nodes without data?
        • multicast, unicast
      • When to send fills?
        • always
        • if we are farthest (and data is not ours), refrain from sending
    • 12. Experimental Results
      • Training Run:
      • In first run nodes learn about environment
      • Train neural nets with (C,S)  P tuples
        • Every 5s, measure and record progress conditions, strategy
        • Observations are local, so each node has different model!
      • Real-time learning run:
      • In second run, nodes adapt behavior to perform better.
      • Adapt each minute by changing strategy according to current conditions
      Real-time cognitive control of a real-world wireless network
    • 13. Observations from Learning
      • Selected configurations explainable but not predictable
        • Farthest-refraining was usually better
          • congestion, not loss dominated
        • Unicast/Multicast was far more complex
          • close: unicast wins (high data rates)
          • medium: multicast wins (sharing gain)
          • far: unicast wins (reliability)
      System performed better with learning
    • 14. Overcoming Cultural Differences to Get a Good Design
    • 15. Cultural Issues: But why?
      • Benefits and scope of cross-layer design:
        • More than 2 layers!
        • More than 2-3 parameters per layer
        • Drill-down walkthroughs highlighted benefits to networking folks; explained restrictions to AI folks
        • Simulation results for specific scenarios demonstrated the power
      • Traditional network design includes adaptation
        • But this works against cognition: it is hard to manage global scope
        • AI people want to control everything
        • But network module may be better at doing something focussed
        • Design must include constraining how a protocol adapts
    • 16. Cultural Issues: But how?
      • Reliance on centralized Broker:
        • Networking folks don’t like the single bottleneck
        • Design must have fail-safe default operation
      • Asynchrony and Threading:
        • AI people tend to like blocking calls.
          • e.g. to ensure that everything is consistent
        • Networking folks outright rejected it.
        • Design must include reporting and alerting
    • 17. Cultural Issues: But it’ll break!?!
      • Relinquishing control outside the stack:
        • Outside controller making decisions scares networking folks
        • AI folks say “give me everything & I’ll solve your problem”
        • Architecture includes “failsafe” mechanisms to limit both sides
      • Heterogenous and non-interoperable nodes
        • Networks usually have homogeneous configurations to maintain communications
        • AI likes heterogeneity because of the benefit
          • But always assumes safe communications!
        • “ Orderwire” bootstrap channel as backup
    • 18. Cultural Issues: New horizons?
      • Capability Boundaries
        • Traditional Networking has very clear boundary between “network” and “application”
        • Generic architecture blurs that boundary
          • AI folks like the benefit
          • Networking folks have concerns about complexity
      • Removing this conceptual restriction will result in interesting and significant new ideas.
    • 19. Conclusion
      • Traditional network architectures do not support cognition
        • Hardware is doing that now (SDR), but the software needs to do the same thing
      • To leverage the power of cognitive networking, both AI folks & Networking folks need to recognize and adapt
    • 20. Backup
    • 21. Environment Model
      • Signal Strength
        • 12 cart-cart strengths
        • sorted to normalize
          • want to apply learning to similar situations with different cart numbering
      • Position
        • seemed like a good idea (“use more information, let neural net sort it out”), but....
        • in testing, seemed more confounding than helpful
      • On-line estimate required
        • operation uses environment
    • 22. Configuration and Adaptation
      • Configuration Manager
        • Determines what modules are currently running
        • Tracks what modules exists
        • Manager transitions from one configuration to another
        • Provides basic sanity check before enabling a new configuration
      • Broker
        • Changes and monitors the state of active modules
        • Serves as a clearinghouse of information about all the modules in current configuration
    • 23. ADROIT Big Picture Modular Networking And Radio Software Radio Hardware Application Application Configuration Manager Cognitive Control Broker
    • 24. Managing Cognition
      • ADROIT doesn’t choose the form
        • Open to just about any form you can imagine
        • Multiple forms on each node, system wide
        • Operate via standard interface (broker)
      • Coordination manager
        • Coordinates interactions among radios
        • Chooses local radio’s external behavior taking into account needs of other radios in team and in region
        • Manages information sharing (keeps cognitive information exchanges within reasonable limits)
    • 25. Modelling the Radio
      • Need a way to model the radio for cognition
        • A chunk of code (module) is not expressive enough
        • At minimum, cognition needs to know what the chunk of code does
      • A basic object model
        • Each module is an object
        • Two implementations of the same functionality are same object type, or inherit characteristics from the same object type
        • Pieces of hardware, etc, also viewed as objects
    • 26. ADROIT resources
      • Troxel et al. “ Enabling open-source cognitively-controlled collaboration among software-defined radio nodes .” Computer Networks, 52(4):898-911, March 2008.
      • Troxel et al, “Cognitive Adaptation for Teams in ADROIT,” in IEEE Global Communications Conference , Nov 2007, Washington, DC. Invited .
      • Getting the ADROIT Code (Including the Broker)
        • https:// acert.ir.bbn.com /
        • checkout instructions
        • GNU Radio changes are in main GNU Radio repository
    • 27. Learning
      • Karen Zita Haigh, Srivatsan Varadarajan, Choon Yik Tang, “Automatic Learning-based MANET Cross-Layer Parameter Configuration,” in IEEE Workshop on Wireless Ad hoc and Sensor Networks (WWASN) , Lisbon, Portugal 2006.
    • 28. ADROIT Team
      • BBN Technologies:
      • Greg Troxel (PI), Isidro Castineyra (PM)
      • AI : Karen Haigh, Talib Hussain
      • Networking : Steve Boswell, Armando Caro, Alex Colvin, Yarom Gabay, Nick Goffee, Vikas Kawadia, David Lapsley, Janet Leblond, Carl Livadas, Alberto Medina, Joanne Mikkelson, Craig Partridge, Vivek Raghunathan, Ram Ramanathan, Paul Rubel, Cesar Santivanez, Dan Sumorok, Bob Vincent, David Wiggins
      • Eric Blossom (GNU Radio consultant)
      • University of Kansas:
      • Gary Minden, Joe Evans
      • MIT: Robert Morris, Hari Balakrishnan
      • UCLA: Mani Srivastava

    ×