XG Communications Program Overview January 2002 doc.: IEEE 802.11-02/xxxr0 XG Industry Workshop July 2004 XG Communications Program Overview Preston Marshall DARPA ATO Program Manager 30 June 2004 Peter Ecclesine, Cisco Systems John Doe, His Company

Provide Program Progress & Plans Establish Understanding of XG July 2004 Purpose Provide Program Progress & Plans Establish Understanding of XG What We’re Doing Where We’ll Be at DARPA’s Completion Discuss Features and Technology Maturity Levels Needed for Implementations Policy Community Commercial Radio Community Military Radio & Radar Community Peter Ecclesine, Cisco Systems

January 2002 doc.: IEEE 802.11-02/xxxr0 DARPA XG Program July 2004 All Spectrum May Be Assigned, But… XG is Developing the Technology and System Concepts for DoD to Dynamically Access All Available Spectrum …Most Spectrum Is Unused! Goal: Demonstrate Factor of 10 Increase in Spectrum Access Peter Ecclesine, Cisco Systems John Doe, His Company

January 2002 doc.: IEEE 802.11-02/xxxr0 July 2004 XG Program Components The Primary Product XG Program is Not a New Radio, but a Set of Advanced Technologies for Dynamic Spectrum Access Peter Ecclesine, Cisco Systems John Doe, His Company

Collected RF Environment For Many Scenarios Accomplishments July 2004 Collected RF Environment For Many Scenarios Data Being Used As Basis For Phase 2 Design Evaluations First Version Of Sensor Completed Provides Needed Capability For Rapid Wideband Sensing Next Revision To Explore High-Risk/High-Payoff Enhancements Three Feasible Designs For Interference Avoidance, Network Operation, And Rendezvous Nearing Phase 2 Evaluations And Competition For Phase 3 Participation Policy Language And Radio Interface Defined Policy Language RFC v1 Composed And Released Extensible to Future “Cognitive” Technology Peter Ecclesine, Cisco Systems

Top-Level Functional Architecture January 2002 doc.: IEEE 802.11-02/xxxr0 July 2004 Top-Level Functional Architecture System Policy Policy Reasoner Sense Radio Platform System Strategy Reasoner Transmit Accredited Policy Device Configuration Peter Ecclesine, Cisco Systems John Doe, His Company

Determine Opportunities January 2002 doc.: IEEE 802.11-02/xxxr0 July 2004 Top-Level CONOPS RF Resource Request Develop Request Process Request Determine Opportunities Select Opportunities RF Transmit Plan Bound: Yes/No Unbound: Binding Constraints Peter Ecclesine, Cisco Systems John Doe, His Company

Current XG Program Participants January 2002 doc.: IEEE 802.11-02/xxxr0 July 2004 Current XG Program Participants Peter Ecclesine, Cisco Systems John Doe, His Company

Program Development Plan January 2002 doc.: IEEE 802.11-02/xxxr0 July 2004 Program Development Plan FY02 FY03 FY04 FY05 FY06 Policy Language Development System Integration System Integration XG System End-to-End Mobile Demo Five efforts currently funded under First Phase Protocol development – BBN Technologies System Integration – Raytheon, Shared Spectrum, and Lockheed Martin Advanced Technologies – Raytheon Second Phase starts with FY03 awards Open to all bidders, not just incumbents (i.e., not a downselect) Protocol development – single developer System Integration – anticipate two teams, but may fund three if low-cost approach is bid Sensing Technologies – independent of integration teams High Risk Technologies Number of small technology development efforts Not core to XG success, but provides next version of XG technologies Sensing High Risk Technologies 10X Reuse Possible Lab Demos 10X Reuse (Lab) CDR Final Demo Peter Ecclesine, Cisco Systems John Doe, His Company

January 2002 doc.: IEEE 802.11-02/xxxr0 July 2004 XG Key Principles Suitable for Range of Architectural Implementations Centralized and decentralized Identify “Interference-Preventing” Core Set Extensible to other features (subleasing, microcharging,...) Separate Policies From Engineering Avoid advocacy for specific sharing policies XG Being Developed In Advance of Policy Framework Provide For Richness/Complexity of Policies Regulations neither flat nor hierarchical Allow For Diversity of Policy Sources Peer-Peer and hierarchical policy authorities Enable extension to “cognitive” optimizing logic Policy “Layer” Flexible for Implementations to Use Without Revisiting for Engineering & Policy Changes Peter Ecclesine, Cisco Systems John Doe, His Company

The XG Problem Space How Do We? January 2002 doc.: IEEE 802.11-02/xxxr0 July 2004 The XG Problem Space How Do We? Policy Language Common Approaches that Must Be Agreed on, and Can be Adopted Widely Describe Worst-Case Interference? Infer Ambiguous Policies? Resolve Inconsistent Policies? Reflect Nation -Policies? Reflect Band- Specific Policies? Abstract Capabilities (Behaviors) Implementation Design Specific Approaches that Can be Implemented in Many Ways to Develop Unique Products Infer Potential Interference? Account for Propagation Differences? Protect “Hidden” Nodes? Optimize System Performance? Measure Instantaneous Spectrum Usage? Peter Ecclesine, Cisco Systems John Doe, His Company

Levels of Policy Regulation January 2002 doc.: IEEE 802.11-02/xxxr0 July 2004 Levels of Policy Regulation Interference Prevention QOS, Cost Optimization Regional National Policy Authority Gov’t Non-Gov’t Agencies Commercial & Civil Owners DoD Services Unit User Policy Focus Ontology-Based Policy Controls Enable Combining and Processing Rules From Multiple Authorities Peter Ecclesine, Cisco Systems John Doe, His Company

Dimensions of Policy Definition January 2002 doc.: IEEE 802.11-02/xxxr0 July 2004 Dimensions of Policy Definition Radio-Specific Policies Spectrum Regulatory Policies Network-Specific Policies Peter Ecclesine, Cisco Systems John Doe, His Company

Technology Independent Mathematical Rigor and Logic July 2004 XG Policy Language Need to Express Policies In A Way That The Radio Can Understand Current regulatory policies are implicit in radio hardware – policy and technology are coupled and costly to change Need to be able to select and update policies in situ New locations, updated policies, new authorizations, ... Web Ontology Language (OWL) Being Used For Developing XG Policy Language Basis for semantic web technology – W3C recommendation Provides structure and richness needed to express policies Includes general theorem proving/reasoning engines for deductive inference OWL Is NOT Another Programming Language – structured way to build representations of knowledge, facts, and rules/policies for machine understanding Technology Independent Mathematical Rigor and Logic Peter Ecclesine, Cisco Systems

How Technology and Policy Can Maximize Access January 2002 doc.: IEEE 802.11-02/xxxr0 July 2004 How Technology and Policy Can Maximize Access 1. Enhance Policy Flexibility by Opening Up the Envelope Accept and Manage More Risk 2. Increase Capability to Dynamically Sense and Adapt Faster Spectrum Analyzers, More Instantaneous Bandwidth Operating Area Dimension 2 Operating Area Develop Radios & Waveform Standards that Can Exploit Sharing Policies Wider Coverage, Better Antennas, Adaptive Waveforms Dimension 1 XG Approach Allows the Operating Envelope To Autonomously Change Over Time as Policies and Technologies Evolve Independently Peter Ecclesine, Cisco Systems John Doe, His Company

XG Policy Language Features July 2004 XG Policy Language Features Resolve Multiple Sources Of Policy Without Causing Failure Allows for Multiple Uncoordinated Sources of Policy Approachable Implementation Growing Community Of DAML/OWL Users, Features and Authoring Tools Class Extensible Maximizes Generality and Reduces Complexity Everyone Can Extend Policies To Their Needs Rapid Adoption Of New Policy Concepts And Technologies Provable Structure Set Theory, Logical Reasoning And Theorem Proving Host Implementation Independent All Policies Can Run On Any Compliant Device Transition from Describing Self-Operation to Defining Effects on Others Peter Ecclesine, Cisco Systems

Today’s Charter (After Policy Language Briefing) July 2004 Today’s Charter (After Policy Language Briefing) What Are The Credibility Shortfalls (If Any)? What Additional Technologies Are Needed (If Any)? What Additional Activities Are Needed (If Any)? Demonstrations of Technology Measurements and Analyses Peter Ecclesine, Cisco Systems

January 2002 doc.: IEEE 802.11-02/xxxr0 July 2004 Peter Ecclesine, Cisco Systems John Doe, His Company