# Towards Collaborative and Dynamic Spectrum Sharing via Interpretation of Spectrum Access Policies
## 3 Architecture  
The main component of the cognitive radio is a Cognitive Engine, as shown in Figure 2. The architecture of the radio must support the functionality described above, plus it must support the aspects of policy management and policy interpretation and execution. Most of the cognitive system architectures are organized around an iterative processing loop (cf. SOAR [6], ACT-R [7]). Some others, e.g., the [PERSON]'s model [8], are patterned after the OODA loop--Object, Orient, Decide and Act [9]. The OODA loop, in general, and [PERSON]'s model, in particular, have been widely used in the domain of Information Fusion, where it serves as a basis for situational awareness.  
[PERSON] [10] proposed to extend the OODA loop and use it as the basic processing loop of SDR-based cognitive radio. He introduced two more processes to the control loop: Plan and Learn. This model, also known as ideal CR architecture (iCRA), is characterized by the Observe-Orient-Plan--Decide--Learn--Act (OPDLA) loop (see Figure 3). The processes inherited from the original OODA model have the following interpretation in the context of cognitive radio: _Observe_--collect data about the environment using an array of sensors; _Orient_--integrate the observations with policies, goals and preferences, hardware and software limitations and past experience; _Decide_--identify the changes that need to be made in the SDR configuration in order to address the new situation; _Act_--reconfigure the SDR. Furthermore, the added processes are _Plan_--planning decisions for the long run--and _Learn_--machine learning and adaptation based on past experience.  
Figure 2: Cognitive radio—top level.  
One of the possible passes through the OODA loop is as follows:  
1. Receive a request (from Software Control) to transmit a packet of information; the request includes the metadata-frequency, time, power and other items of information, as needed.
2. Identify policies relevant to the current request.
3. Invoke the policy engine (PE) to verify that the transmission request is compliant with at least one of the policies and not forbidden by any of the relevant policies.
4. If the decision is \"allow\", then convey this decision to Software Control.
5. If the decision is \"disallow\", then invoke the function Compute Transmission Opportunities (planning).
6. Send transmission opportunities or the \"disallow\" decision (if no opportunities were found) to Software Control
7. Return to Step 1.  
The architecture of the experimental system used in this work, termed the Cognitive Radio Engine (CRE), is shown in Figure 4. It consists of six components: Policy Manager, Policy Engine, Planner, Learner, Controller and Inference Store (IS). The Controller coordinates the interactions between the first four components and the radio's Software Control. These four components also interact with the domain-independent IS, VIStology's semantic storage. All data within CRE is represented in OWL (Web Ontology Language [4]). A general-purpose OWL Reasoner that can take full advantage of the semantic information encoded in OWL is embedded inside IS (not explicitly shown in the figure).  
Figure 4: The Cognitive Radio Engine architecture described in this work.  
Figure 3: The extended OODA loop.  
The components of this architecture are in a direct relation to the OODA loop, as shown in Table 1. The table shows some functions that have not been discussed so far but are needed for the realization of collaboration among the CRs. In particular, we identify the operation of Schedule Rendezvous as a functionality that is needed for synchronizing collaboration among the radios.  
The functionality of the particular components is described in more detail in the rest of the paper.