This use case demonstrates how the RIF leads to increased flexibility in matching the goals of end-users of a service/device, with the goals of providers and regulators of such services/devices. The RIF can do that because it enables deployment of third party systems that can generate various suitable interpretations and/or translations of the sanctioned rules governing a service/device.
This use case concerns Dynamic Spectrum Access for wireless communication devices. Recent technological and regulatory trends are converging toward a more flexible architecture in which reconfigurable devices may operate legally in various regulatory and service environments. The ability of a device to absorb the rules defining the policies of a region, or the operational protocols required to dynamically access available spectrum, is contingent upon those rules being in a form that the device can use, as well as their being tailored to work with devices in the same class having different capabilities.
In this use-case we suppose a region adopts a policy that allows certain wireless devices to opportunistically use frequency bands that are normally reserved for certain high-priority users. (The decision by the European Union to allow "Dynamic Frequency Selection" (DFS) use of the 5 GHz frequency band by wireless systems, a band intermittently used by military and weather radar, is a recent example - See http://europa.eu.int/eur-lex/lex/LexUriServ/site/en/oj/2005/l_187/l_18720050719en00220024.pdf.)
Suppose the policy states:
A wireless device can transmit on a 5 GHz band if no priority user is currently using that band.
How does a device know that no priority user is currently using a band it wants to use? The answer will depend on the specific capabilities of the device. One type of device may answer this question by sensing the amount of energy it is receiving on that band. That is, it might employ the rule:
If no energy is detected on a desired band then assume no other device is using the band.
A second type of device, may get information from a control channel that lets it know whether the desired band is being used by a priority user. That is, it might employ the rule:
If no control signal indicating use of a desired band by a priority user is detected then assume the band is available.
So each type of device will need to employ different "interpretations" or "operational definitions" of the policy in question.
Now assume that there are 10 manufacturers of these 2 different types of wireless devices. Suppose that each of these manufacturers uses a distinct rule-based platform in designing its devices. Each manufacturer needs to write 2 interpretations of the policy (for each of the two types of device). That means that 20 different versions of the policy must be written, tested and maintained.
Enter the RIF. The 10 manufacturers form a consortium. This is a third-party group that is responsible for translating regional policies into the RIF. When it does so, however, it provides different versions corresponding to the possible interpretations (operational definitions) of the policy. So in this case, 2 RIF versions of the DFS policy are provided for the 2 types of device mentioned above. Each of these RIF specifications can be automatically translated into the appropriate rule-platform provided a RIF-Compiler for the target device architecture exists. Clearly it will be in the interest of each device manufacturer to develop such compilers. That is because the manufacturer only needs to develop such a compiler once for every architecture it owns. Contrast that investment with having to produce, test, and maintain different versions of various policies over the lifetime of a product.
This arrangement also allows the overall process to be organized in a fashion that maintains the natural division of labor in the corresponding division of artifacts produced by that labor: the policy and its various interpretations are written and maintained in platform-independent artifacts (the RIF); knowledge about how to translate from the RIF to a particular device architecture is maintained in the compilers. A change in policy is inserted at the top level in the policy artifact hierarchy where it should be; possible operational interpretations of that change are inserted at the next level down; the implementation implications for the various device architectures is generated automatically at the lowest level.
Motivates:
The regulatory policies specify certain constraints, e.g., "if radar is sensed on a channel in use, the channel must be evacuated within 10 seconds," which can be viewed as a default for a device to be in compliance. However, the RIF-based specifications promulgated by the consortium will not simply state the constraint, but rather contain a set of implementable rules that make it possible for a suitably configured device to meet this constraint. For some configurations and device types these rules may go beyond simply ceasing transmission on the channel, e.g., the device might send a control message to a master device (an access point) asking if an alternate channel is available, etc. As long as these additional steps do not prevent devices from vacating the channel within 10 seconds (and do not violate any other constraints) they are allowed. So, it would be worthwhile to allow the RIF-based specifications to "point" to a RIF-based version of the general 10-second constraint as a default behavior if the more detailed rules cannot be applied.
Depending upon the needs of an application, there are a number of ways that a formal representation of a policy can be achieved. A device may need to reason about what a policy requires and it may also need to allow its behavior to be guided by the policy. In the former case, deductive logic can be used to formulate statements and draw valid inferences as to what the policy entails. For example, relative to the 10 second channel evacuation requirement mentioned above, it turns out that if a device (or its associated master) checks for radar every 9 seconds then there will be enough time to evacuate the channel if needed. So a RIF-based specification might contain a declarative rule that states "if a channel is in use, and it's last radar check was 9 seconds ago, then a radar check on that channel is due." The important thing to note here is that the rule is a statement (capable of being true or false) of what the implementation requires. In order to utilize such statements to guide the behavior of a device, connections must be forged between conclusions reached and actions to be taken. Production rules, specifically, ECA rules can be used to establish those connections. For example, "if it has been concluded that a radar check for a channel is due, then do <action>!" Since this use case envisions devices that are both capable of reasoning about policy requirements and being guided by them, we expect that these RIF-based specifications will require rules having both declarative and imperative semantics.
As the use case states, RIF-based specifications are beneficial because they allow a group of interested parties (the consortium) to write machine-usable specifications that can be deployed to a wide variety of devices provided the device manufacturer, or other party, writes a "RIF-compiler," i.e., translator, for the given device platform. If RIF-based specifications were themselves allowed to take on many different forms in a non-cohesive fashion, and specifications using them were generated, it is possible that this benefit would be compromised. In other words, a manufacturer or third party might find it necessary to invest too much time in maintaining translators to make use of the RIF worthwhile.
The rules in these applications will utilize concepts that are defined in accordance with the definitions devised by standard organizations. The use of OWL ontologies is likely for that task. Moreover it is possible that future protocol message payloads might contain OWL data.
The rules require support for negation. The rules react to changes in the environment. Features from production rules and ECA rules such as forward chaining, events, and actions will be useful.