policy specification and enforcement for spectrum-agile radios

Policy Specification and Enforcement For Spectrum-Agile Radios

Grit DenkerSRI 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

1. Spectrum scarcity2. 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 Radios1. Radio senses and adapts to local RF

environment and application needsand2. Radios act according to regulatory

policies authored in more than 200 countries

6

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

Policy Wish List

7

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

Radio PolicyRadio

Policy

vs

8

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

Current Status: Software-Defined Radios

Radio

Policy

9

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

Benefits of Policy-Defined Radios

10

Outline




Conclusions

11

Policy Architecture for Policy-Defined Radios

PolicyDB

Policy Reasoner

(PR)System Strategy Reasoner

(SSR)

RF

Sensors

state of spectrum

control msgdata msg

transmission request(un)load policy

(de)activate policyget loaded/activated policies

transmission reply

set of policies

control msgdata 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


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 policiesRestrictive 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 policiesE.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

Ontology ExamplesOntology Name

Type

Operations

message

Message

time

TimeInstantTimeDuration…

timeDifferencetimeBeforetimeAftertimeDurationLessThaninTimeDuration…

geo

LocationGeographicArea…

distancelocatedIncontainsLocation…

basic_types

BandwidthFrequencyPowerThresholdPrecision

EvIdenceTransmitterDetector

message

Message

powermask

Powermask

powermaskLessThanpowermaskGreaterThanpowermaskLessThanOrEqualpowermaskGreaterThanOrEqualpowermaskAdd

use

16

Example: DFS Powermask

17

Powermask Ontology

ontology powermask is use basic_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;

List of Tuples

Constructor

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

Ontology Examples (cont)

signal

Signal RadarSignal TVSignal NTSCSignal PALSignal SECAMSignal BeaconSignal

radio

RadioDetector SignalDetector ContinuousSignalDet PeriodicSignalDetector LocationDetector TimeDetector MessageDetectorRadioCapability ProcessCapability

transmission

Transmission

geo basic_types

timemessage

powermask

request_parameters

radiotransmissionevidence

evidence

Evidence SignalEvidence LocationEvidence TimeEvidence

OntologyName

Type SubType

Operations

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

Ontology Overview II

signal

Signal RadarSignal TVSignal NTSCSignal PALSignal SECAMSignal BeaconSignal

radio

RadioDetector SignalDetector ContinuousSignalDet PeriodicSignalDetector LocationDetector TimeDetector MessageDetectorRadioCapability ProcessCapability

transmission

Transmission

geo basic_types

timemessage

powermask

request_parameters

radiotransmissionevidence

evidence

Evidence SignalEvidence LocationEvidence TimeEvidence

OntologyName

Type SubType

Operations

22

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

Evidence presented to reasoner

Properties of requested transmission

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




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




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”



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


“Restrict XG radios from transmitting if its peak received power sensing is more than -80 dBm.”



end

31


“Restrict XG radios from transmitting if its peak received power sensing is more than -80 dBm.”



end

32

Another Listen-Before-Talk PolicyAllow 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

LBT-2 Policypolicy 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

“…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

…”

34

Example Policies Encoded in CoRaL

Time-dependent Location-dependent Listen-Before-Talk Beacon Signal TV DFS

35

Outline




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

USAregion.

floatfrequency.

0.20. floatfrequency

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

f [Mhz]

p [dBc]

f [Mhz]

p [dBc]

43

Outline




Conclusions

44

PAGODA

Reasoner

Monitor

CoordinatorKB

Hardware Abstraction Layer

Radio

Manager

Goals, Policies, Device Models (knobs/sensors), etc.

Method: Policy-controlled soft constraint solving yield

solutions for application reqs

Knob settingsSensor

readings

Prototypical implementation exists

Current study: Routing policies

45

Outline




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

policy specification and enforcement for spectrum-agile radios

Documents