This use case demonstrates how the RIF leads to increased flexibility in matching the needs and goals of end-users of a service or a service-delivery device, such as a cell phone, with the needs and goals of providers and/or regulators of such services. The RIF can do that by enabling deployment of third party systems designed to allow service providers and regulatory agencies to write the rules defining and governing their services once, leaving it to the third-party service to generate suitable interpretations and/or translations of those rules for any consumer process or device interested in using the service. There are at least two broad areas in which such third-party services could be deployed:
- Wireless Communications
- 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 given 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. This use case is developed in detail below.
- Web Services and Service Oriented Architecture
- The advent of web-based service architectures offers the possibility of a more dynamic and flexible approach in which differentiated service definitions, or Service Level Agreements (SLAs), can be matched to particular circumstances automatically as required. For example, what constitutes a certain level of service, or an acceptable premium for such a level, might vary depending upon the laws in the region in which the service is provided or contracted. The ability of a consumer process to understand the rules defining and governing differentiated SLAs is contingent upon those rules being in a form that the consumer process can use.
Suppose a region or nation adopts a policy that allows certain wireless devices to opportunistically use frequency bands that are normally reserved for certain high-priority users (e.g. government). 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 that such a device can transmit on such a band if no priority user is currently using that band. From the point of view of the device (and its designers) the question is how does it know that no priority user is currently using a band it wants to use? The answer will generally depend on the specific capabilities of the device. For example, one type of device may only be able to answer this question by means of sensing the amount of energy it is receiving on that band. If it senses no energy on the desired band it assumes no other device is using the band. However, a more sophisticated type of device, may be able to get information from another control channel that lets it know whether the desired band is ok to use at a given time or not. So each class of device will need to employ different "interpretations" of the policy in question.
Now assume that there are 10 manufacturers of the these 2 different classes of wireless devices. Suppose that each of these manufacturers uses a distinct rule-based platform in designing the "policy engines" of its devices. Each manufacturer needs to write 2 interpretations of the policy (for each of the two classes 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 such 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 general classes of device - those that only use energy sensing to determine band use versus those that can use the control channel. 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 for their device architectures. That is because the manufacturer only needs to develop such a compiler once for every architecture it owns. Contrast that investment (plus the cost of its membership in the consortium) with having to produce, test, and maintain different versions of various policies over the lifetime of a product. Moreover, this arrangement also allows the overall process to be organized in a fashion that follows and maintains the natural division of labor and the division of artifacts produced by that labor. In other words, the policy and its various interpretations are written and maintained in platform-independent artifacts. The 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 artifacts where it should be, possible operational interpretations of that change are inserted at the next level down, and then the implications for the various device architectures is generated automatically at the lowest level.