Policy Specification and Enforcement For Spectrum-Agile Radios

1. Policy Specification and Enforcement For Spectrum-Agile Radios Grit Denker SRI International Joint work with Daniel Elenius, Mark-Oliver Stehr, Rukman Senanayake, David Wilkins

2. Outline • Policy-Defined Radios • Architecture for Policy-Defined Radios • Cognitive (Policy) Radio Language • Why not OWL? • Policy-Based, Goal-Oriented Distributed Architecture (PAGODA) • Conclusions

3. Outline • Policy-Defined Radios • Motivation, Objectives, Benefits • Architecture for Policy-Defined Radios • Cognitive (Policy) Radio Language • Why not OWL? • Policy-Based Goal-Oriented Distributed Architecture (PAGODA) • Conclusions

4. Motivation Significant problems in wireless communication • Spectrum scarcity • Deployment delays Reasons • Centralized, static nature of current spectrum management procedures and policies • Static policies cannot react to dynamic operational needs • Changes are labor intensive, not real time • Policies assume 100% usage • Reality: most spectrum unused most of the time

5. Objectives “Automatic, dynamic, opportunistic access to unused spectrum” Requirements for Radios • Radio senses and adapts to local RF environment and application needs and • Radios act according to regulatory policies authored in more than 200 countries

6. Policy Wish List • Policies should describe “what” not “how” • Policies should be platform-independent • Policies should have precise meaning • Policy authoring should be distributed • Policies must be customizable • location, user, time, frequency, etc. • Policies can change over time

7. Radio Policy vs Policy Radio Policy-Based Approach to Spectrum Agile Radios • Separation between policies and firmware • Use platform-independent policy engine to regulate spectrum access in changing regulatory and RF environments • SRI developed expressive and extensible Cognitive (Policy) Radio Language (CoRaL) and efficient policy reasoner

8. Policy Radio Current Status: Software-Defined Radios • Policies programmed or hardwired into the radio • Mix of policy control and other radio control software • Written in a procedural language (usually C) • Consequences: • Accessible only to radio engineers • Difficult and time-intensive to change or extend • Accredidation of radios is costly • Non-standardized

9. Benefits of Policy-Defined Radios • Control low-level radio behavior through high-level policies • Choose applicable policies at runtime • Distributed policy authoring (various stakeholders) • Policies can be loaded on different types of radios • Policies and radios can evolve asynchronously • Policies can be composed and extended • Policies are easy to understand and free of implementation details • Precise mathematical meaning of policies avoids misinterpretation and allows accreditation through formal analysis

10. Outline • Policy-Defined Radios • Architecture for Policy-Defined Radios • Cognitive (Policy) Radio Language • Why not OWL? • Policy-Based, Goal-Oriented Distributed Architecture (PAGODA) • Conclusions

11. transmission reply set of policies Policy Architecture for Policy-Defined Radios state of spectrum Sensors transmission request control msg RF Policy Reasoner (PR) (un)load policy data msg System Strategy Reasoner (SSR) (de)activate policy get loaded/activated policies Policy DB control msg data msg Radio

12. SSR – PR Interface • Shared ontologies and domain concepts • Frequency, power, location, maxPower, inBandLeakage, … • SSR-PR conversation • SSR sends transmission request • Radio parameters can be bound, unbound, or partially bound (constrained) • PR sends back “yes”, “no”, or “yes, if …” with additional constraints over the request parameters

13. Outline • Policy-Defined Radios • Architecture for Policy-Defined Radios • Cognitive (Policy) Radio Language • Features, Domain Ontologies, Policy Examples • Why not OWL/SWRL? • Policy-Based Goal-Oriented Distributed Architecture (PAGODA) • Conclusions

14. CoRaL Features • Shared Domain Concepts Frequency, power, location, powermask, signal, … • Permissive and restrictive policies Restrictive takes precedence over permissive (for same priority policies) • Reasoning on numerical constraints E.g., frequency between 5000 and 5500 MHz, power =< 2dB, … • Ability to represent policies about different aspects separately and easily combine them to achieve the desired effect • Mechanisms to conditionally override policies E.g., allow red-cross radios to use GSM band during natural disaster CoRaL is typed first-order language Broader context: Policies for networking, routing, spectrum

15. powermask message Powermask powermaskLessThan powermaskGreaterThan powermaskLessThanOrEqual powermaskGreaterThanOrEqual powermaskAdd Message use basic_types geo time message Bandwidth Frequency Power Threshold Precision EvIdence Transmitter Detector Location GeographicArea … distance locatedIn containsLocation … Message TimeInstant TimeDuration … timeDifference timeBefore timeAfter timeDurationLessThan inTimeDuration … Ontology Name Type Operations Ontology Examples

16. Example: DFS Powermask

17. List of Tuples Constructor Powermask Ontology ontology powermask is usebasic_types; deftype PowermaskValues = [(Frequency,Power)]; type MaskShape; const linear : MaskShape; const step : MaskShape; type Powermask; const pm : MaskShape, PowermaskValues ->Powermask; const powermaskLessThan : Powermask,Powermask -> Bool;

18. Example: DFS Powermask defconst maxInBandLeakage : Powermask = symmetric linear [(0, 0), (9, 0), (11, -20), (20, -28), (30, -40), (180, -40), (180, -42), (216, -42), (216, -47), (inf, -47)]

19. signal Signal RadarSignal TVSignal NTSCSignal PALSignal SECAMSignal BeaconSignal radio Radio Detector SignalDetector ContinuousSignalDet PeriodicSignalDetector LocationDetector TimeDetector MessageDetector RadioCapability ProcessCapability evidence Evidence SignalEvidence LocationEvidence TimeEvidence request_parameters radio transmission evidence transmission Transmission basic_types message powermask geo time OntologyName Type SubType Operations Ontology Examples (cont)

20. Transmission Ontology policy transmission is use time,basic_types; public type Transmission; public const centerFrequency : Transmission -> Frequency; public const bandwidth : Transmission -> Bandwidth; public const maxOnTime : Transmission -> TimeDuration; public const minOffTime : Transmission -> TimeDuration; public const meanEIRP : Transmission -> Power; public const transmittedBy : Transmission -> Transmitter; end

21. signal Signal RadarSignal TVSignal NTSCSignal PALSignal SECAMSignal BeaconSignal radio Radio Detector SignalDetector ContinuousSignalDet PeriodicSignalDetector LocationDetector TimeDetector MessageDetector RadioCapability ProcessCapability evidence Evidence SignalEvidence LocationEvidence TimeEvidence request_parameters radio transmission evidence transmission Transmission basic_types message powermask geo time OntologyName Type SubType Operations Ontology Overview II

22. Properties of requested transmission Evidence presented to reasoner Transmission Request Parameters policy request_params is use radio; public const req_radio : Radio; public const req_transmission : Transmission; public const req_evidence : Pred(Evidence); end • Additional request parameters can be defined. Characteristics of requesting radio

23. Time Policy “Allow radios to transmit between 06:00 and 13:00 local time.” policy time is use request_params; allow if (exists ?te:TimeEvidence, ?t:TimeInstant) req_evidence(?te) and timeStamp(?te) = ?t and hour(?t) in {6 .. 12}; end

24. Time Policy “Allow radios to transmit between 06:00 and 13:00 local time.” policy time is use request_params; allow if (exists ?te:TimeEvidence, ?t:TimeInstant) req_evidence(?te) and timeStamp(?te) = ?t and hour(?t) in {6 .. 12}; end

25. Beacon Policy “Allow radios to transmit if it can hear a permit-use beacon operating at 300 MHz broadcasting a beacon signal continuously for duration of 100 milliseconds every one second” policy beacon is use ssc_params; allow if (exists ?se:SignalEvidence, ?t: TimeInstant) req_evidence(?se) and detectedSignal(?se,permitUse) and 300.0 in scannedFrequencies(?se) and lastCompletedEmptyScanDuration(?se) = td(0,0,0,0,0,0,100) and timeStamp(?se) = ?t and timeDurationLongerThan(timeBetween(?t,lastDetected(?se), td(0,0,0,0,0,1,0)) = true; end

26. Beacon Policy “Allow radios to transmit if it can hear a permit-use beacon operating at 300 MHz broadcasting a beacon signal continuously for duration of 100 milliseconds every one second” policy beacon is use ssc_params; allow if (exists ?se:SignalEvidence, ?t: TimeInstant) req_evidence(?se) and detectedSignal(?se,permitUse) and 300.0 in scannedFrequencies(?se) and lastCompletedEmptyScanDuration(?se) = td(0,0,0,0,0,0,100) and timeStamp(?se) = ?t and timeDurationLongerThan(timeBetween(?t,lastDetected(?se), td(0,0,0,0,0,1,0)) = true; end

27. Beacon Policy “Allow radios to transmit if it can hear a permit-use beacon operating at 300 MHz broadcasting a beacon signal continuously for duration of 100 milliseconds every one second” policy beacon is use ssc_params; allow if (exists ?se:SignalEvidence, ?t: TimeInstant) req_evidence(?se) and detectedSignal(?se,permitUse) and 300.0 in scannedFrequencies(?se) and lastCompletedEmptyScanDuration(?se) = td(0,0,0,0,0,0,100) and timeStamp(?se) = ?t and timeDurationLongerThan(timeBetween(?t,lastDetected(?se), td(0,0,0,0,0,1,0)) = true; end

28. Beacon Policy “Allow radios to transmit if it can hear a permit-use beacon operating at 300 MHz broadcasting a beacon signal continuously for duration of 100 milliseconds every one second” policy beacon is use ssc_params; allow if (exists ?se:SignalEvidence, ?t: TimeInstant) req_evidence(?se) and detectedSignal(?se,permitUse) and 300.0 in scannedFrequencies(?se) and lastCompletedEmptyScanDuration(?se) = td(0,0,0,0,0,0,100) and timeStamp(?se) = ?t and timeDurationLongerThan(timeBetween(?t,lastDetected(?se), td(0,0,0,0,0,1,0)) = true; end

29. Simple Listen-Before-Talk Policy “Restrict radios from transmitting if its peak received power sensing is more than -80 dBm.” policy lbt1 is use request_params; disallow if (exists ?se:SignalEvidence) req_evidence(?se) and peakRxPower(?se) > -80.0; end

30. Simple Listen-Before-Talk Policy “Restrict XG radios from transmitting if its peak received power sensing is more than -80 dBm.” policy lbt1 is use request_params; disallow if (exists ?se:SignalEvidence) req_evidence(?se) and peakRxPower(?se) > -80.0; end

31. Simple Listen-Before-Talk Policy “Restrict XG radios from transmitting if its peak received power sensing is more than -80 dBm.” policy lbt1 is use request_params; disallow if (exists ?se:SignalEvidence) req_evidence(?se) and peakRxPower(?se) > -80.0; end

32. Another Listen-Before-Talk Policy Allow radios • with transmission power control turned on • transmit in the band 5470 MHz to 5725 MHz • if mean EIRP is at most 30 dBm • unwanted emission mask is below a mask represented by a point-based function M, • in-band leakage is below a power mask represented by a point-based function M2, • transmission bandwidth is at most 20 MHz • nominal frequency carrier is one the frequency values in set S, and • the radios did not detect any radar signal while continuously sensing for at least 60 seconds in the last 24 hours or if the last radar detection occurred at least 30 minutes before the latest clear 60-second long scan with power sensing threshold at most -64 dBm.

33. “…the unwanted emission mask is below a mask represented by a point-based function M, the in-band leakage is below a power mask represented by a point-based function M2…” “… the nominal frequency carrier is one of the frequency values in set S…” LBT-2 Policy policy lbt2 is use ssc_params; defconst maxIBL : Powermask = … defconst maxOBL : Powermask = … defconst channels : [Frequency] = [list of frequencies]; allow if powermaskLessThan(inBandLeakage(transmittedBy (req_transmission)), maxIBL) and powermaskLessThan(outOfBandLeakage(transmittedBy (req_transmission)),maxOBL) and centerFrequency(req_transmission) in channels

34. Example Policies Encoded in CoRaL • Time-dependent • Location-dependent • Listen-Before-Talk • Beacon Signal • TV • DFS

35. Outline • Policy-Defined Radios • Architecture for Policy-Defined Radios • Cognitive (Policy) Radio Language • Why not OWL? • Policy-Based, Goal-Oriented Distributed Architecture (PAGODA) • Conclusions

36. Using OWL for XG Policies • How far can we get with OWL reasoning? • How should the ontologies be structured to enable this? • Describe each policy and each candidate as an OWL class (using restrictions on properties) • OWL classes are sets • Each member (individual) of the set is a transmission • Policy is a set of allowed transmissions • Candidate is a set of wanted transmissions

37. Policies and Candidates • If a policy covers (subsumes) a candidate, then the transmission is allowed • If a policy intersects with a candidate, then the transmission is allowed with some further restrictions • Send to more powerful reasoner (e.g., FOL reasoner) • If there is no intersection, disallow the transmission • OWL subsumption and OWL satisfiability checks • Hopefully very efficient

38. Numerical reasoning in OWL • Many Spectrum Policies require reasoning on numerical ranges • Frequency range, time interval, region in lat-long, received power, transmission power, power leakage, continuous on time, sensing time/threshold, etc. • We want OWL subsumption to see that • “float less than 10.0” is a subclass of “float less than 20.0”

39. OWL datatype reasoning • Uses XML Schema datatypes • We can say • and • but not • Support of custom XML Schema datatypes in progress

40. Limitation: Functions “The peak value of the power envelope shall be measured and noted. The span shall be reduced and the marker moved in a positive frequency increment until the upper, (relative to the centre frequency), -10 dBc point is reached. This value shall be noted as f1. The marker shall then be moved in a negative frequency increment until the lower, (relative to the centre frequency), -10 dBc point is reached. This value shall be noted as f2. The center frequency is calculated as (f1 +f2)/2.” -DFS document

41. Limitation: Powermask Specification

42. Limitation: Powermask Specification • We can approximate on the safe side p [dBc] p [dBc] f [Mhz] f [Mhz]

43. Outline • Policy-Defined Radios • Architecture for Policy-Defined Radios • Cognitive (Policy) Radio Language • Why not OWL? • Policy-Based, Goal-Oriented Distributed Architecture (PAGODA) • Conclusions

44. PAGODA Goals, Policies, Device Models (knobs/sensors), etc. Manager Reasoner KB Coordinator Monitor Hardware Abstraction Layer Method: Policy-controlled soft constraint solving yield solutions for application reqs Knob settings Sensor readings Radio Prototypical implementation exists Current study: Routing policies

45. Outline • Policy-Defined Radios • Architecture for Policy-Defined Radios • Cognitive (Policy) Radio Language • Why not OWL? • Policy-Based, Goal-Oriented Distributed Architecture (PAGODA) • Conclusions

46. Conclusions - Achievements • CoRaL result of specific spectrum policy requirements • Can express complex policies (such as DFS) • Efficient prolog-based policy reasoner demonstrated on real-life sensor data • ~200 requests per second • 5ms reasoning time supports rapid frequency abandonment time • Policies can be changed dynamically • Policies written independent of radio type • Limitation: Reasoner gives on yes/no answers

47. Conclusions – Future Work • Policy reasoner that • works for underspecified requests & • returns more detailed information why transmission request was not granted (“Yes, if constraints” replies) • Prototypical implementation exists • Middle ground between theorem-proving and logic programming • Innovative combination several successful and powerful techniques • Forward chaining to incrementally prune/filter policies • Partial evaluation based on conditional rewriting • Backward chaining to deal with defined predicates • Constraint propagation and simplification to deal with built-in predicates and detect inconsistencies as early as possible

48. ? Thanks again to my colleagues Daniel Elenius, Mark-Oliver Stehr, Rukman Senanayake, David Wilkins who did all the hard work. Questions