POLICY ENGINE Research: Design & Language IRT Lab, Columbia University

Control Middleware IRT Lab, Columbia University2

Current Implementation Issue: Different functions to communicate with different managers Objective: modular extensible design Design: Extensibility IRT Lab, Columbia University 3

Can we leverage MIH design ? Design: Extensibility IRT Lab, Columbia University 4

Leverage MIH Registration Policy Engine (PE) is similar to MIH Function IRT Lab, Columbia University 5

Events and Services Manager provides events and services –Events: Link change Network change Location change –Services Subscriber can query the value of certain attributes (current location, current bandwidth, etc.) Subscriber can send decisions/notifications Policy engine subscribes to events and services (put in tables) IRT Lab, Columbia University 6

Tables in Policy Engine Event Table –Events from each connected manager –Each event will trigger a different evaluation Service Table –Subscribed services from managers or other modules –Methods / API to access the service also recorded IRT Lab, Columbia University 7

POLICY LANGUAGE Research: Design & Language IRT Lab, Columbia University

Why ? Environment –Mobile Devices –Heterogeneous networks/interfaces Network selection and handover –Default rules –Manual switch Control middleware –Unified policy language IRT Lab, Columbia University 9

Use Cases Different network usage for different user scenarios –Different places (office / home) –Different time (morning / evening) –Different activities (working / playing) –Different devices (monitors / phones) –Different security options Application preferences –Some need high throughput –Some need lowest money cost IRT Lab, Columbia University 10

Related Works Policy expression framework –Standard schemas –P3P / SAML / … Rule-based policies –Accountability in RDF (AIR) Custom configurations –For particular applications IRT Lab, Columbia University 11

Language Design Attributes Evaluation Decision Knowledge base IRT Lab, Columbia University 12

Language Semantics Attribute : Network / System Term : Value (Binary evaluation) or range (T/F) Score : Evaluate score from one attribute Eval : Trigger evaluation and generate facts (each event will trigger one eval, which may evaluate several terms and scores) Fact : Predicate Logic unit Rule : Making decisions by forward chaining (facts => actions) IRT Lab, Columbia University 13

Attributes Deterministic –Location –Time –Scenario profiles (meeting / working / traveling) –Security –Devices Non-Deterministic –Quality of Service (QoS) –System Resources –Expense/Cost IRT Lab, Columbia University 14

Attribute Representation Direct attributes –Corresponding entry in the service table Derived attributes –Combination of attributes –Evaluated as a single attribute Attribute table: –Name of the attribute –How to get the value of the attribute Example: derived attr { id: bp_ratio attr: bandwidth (x1) attr: price (x2) func: x1 / x2 } IRT Lab, Columbia University 15

Deterministic Evaluation Binary (Yes/No) Range (In range or not) Term –id –attr : evaluated attribute –values : expected values –low : lowest value –high : highest value Example: term { id: at_home attr: location values: home } term { id: mid_bw attr: bandwidth low: 50 high: 200 } IRT Lab, Columbia University 16

Non-deterministic Evaluation Attribute value -> score (0 ~ 100) Priority (used as weight when evaluating multiple scores) Score –id: name of the score –attr: evaluated attr(s) –how: max, min, order –priority : 0 ~ 1 Example: score { id: bw_score attr: bandwidth order: linear max: 1000 min: 0 priority: 0.7 } bp_ratio 0.7 signal 0.2 latency Example: score { id: price_score attr: price order: linear max: 0 min: 1000 priority: 0.9 } IRT Lab, Columbia University 17

Eval Event triggered –id: used by Event Table Generate facts –attributes: directly turned –terms: which satisfies –scores: highest score Only one score Multiple scores: weighted sum fact: predicate(params) Examples: eval { id: eval1 { attr: location => location(x) } { term: mid_bw => mid_bw(x) } { score: bw_score => highest_bw(x) } { score: price_score => cheapest(x) } { score: bw_score score: price_score => most_worth(x) } } IRT Lab, Columbia University 18

Decision Attribute evaluations -> Facts Rule Engine: Facts -> Actions Actions: decisions / facts Decisions: Leverage service table Example: rule { location(home) cheapest(x) => decide(1, x) history(home, x) } IRT Lab, Columbia University 19

Knowledge Base Taking history into account IRT Lab, Columbia University 20 Data Store

Implementation Policy Language –Syntax abstracted from the examples –LRM to be developed Implementation language: C –More efficient –Inside system –Rule Engine can leverage logic language Prolog IRT Lab, Columbia University 21

Conclusion Structures –attr, term, score, eval, fact, rule Advantages –Configurable & Programmable –Configurations can be simple (XML/JSON) –Programmable rule chains can generate intelligent decisions –Extensible (attributes, evaluations, rules) IRT Lab, Columbia University 22

Next Steps Implementation Evaluation IRT Lab, Columbia University 23