Dynamic Spectrum Access Decisions. George F. Elmasry
the design of DSA services must address the fact that reachability is not always guaranteed. For that reason, DSA as a set of cloud services should always work independently of the control plane status.
Using Figure 5.1, DSA decisions can be made in the following ways:
1 At the root DSA central arbitrator, which can make DSA decisions based on spectrum sensing information fused and propagated up the hierarchy to this central arbitrator. This central arbitrator can also obtain information from external sources, such as what frequencies to avoid and which network can be assigned a static frequency. Rule sets for policy automation can also be entered at the central arbitrator.
2 At the network gateway. We assume that each network has a gateway and this gateway can make DSA decisions under different scenarios as follows:(a) Decisions local to this gateway node itself. The gateway node can make local decisions such as which frequency the network should attempt connectivity through first and the order of frequencies that can be used to attempt connectivity to other nodes in the network (the order of using backup frequency bands). The gateway can also decide how long it will attempt connectivity on one frequency band before trying the next frequency band in the backup frequency bands list.(b) Network distributed cooperative DSA decisions where the gateway node communicates with other nodes within a network for the network cooperative distributed DSA decisions.(c) Global distributed cooperative DSA decisions with peer gateway nodes. This scenario assumes that the gateway node may not be able to reach the central arbitrator but can reach peer gateway nodes through the solid line control plane in Figure 5.1. The gateway nodes can reach all or a subset of peer gateway nodes. Distributed cooperative DSA decisions under this scenario are taken with regard to a group of networks and can be an alternative (fallback solution) to the decisions made by the central arbitrator. When the central arbitrator is not reachable, this capability can make the gateway a proxy for the central arbitrator's services.(d) Deferred decision where the gateway node defers a DSA decision to the central arbitrator when it is reachable.
3 The third entity that can make DSA decision is the network node. Network nodes can make DSA decisions under different scenarios as follows:(a) Local decisions to the node. An example of such decision is the resorting to a backup list of frequency bands if connectivity to other peer nodes through the assigned frequency band fails.(b) Distributed cooperative DSA decisions with peer network nodes. This scenario assumes that the gateway node is not reachable.(c) Deferred decisions where the network node defers a decision to the network gateway node. Notice that the network gateway nodes can execute 2(c) or 2(d) above in order to make this decision.
In addition to offering DSA services seamlessly, a cloud architecture of DSA services should also allow for policy propagation such that policies set at the central arbitrator by the network manager can propagate seamlessly to the lower hierarchical entities. Policy automation is a core part of seamless DSA services. In addition to policies, some configuration parameters can be entered at the central arbitrator and processed to create configuration parameters for the networks. Network gateways can use the network configuration parameters it receives from the central arbitrator to create configuration parameters specific for each node in its network and send each node its configuration parameters. This hierarchical propagation of policies, rules, and configuration parameters can minimize the bandwidth used for DSA control traffic as it makes entities such as gateways process one network configuration message to produce many node configuration messages. The network gateway can use the network's waveform multiple access capabilities to send one message to more than one node using only one over‐the‐air transmission. The configuration message from the central arbitrator to the network gateway will have less impact on control traffic volume than having the central arbitrator attempt to configure each node in each network with a separate message.
Other considerations of this generic model include:
1 Reducing or eliminating the need for a human in the loop.
2 Creating harmony between the heterogeneous networks through consistent updates of policies and configuration parameters.
3 Utilizing the processing power of the upper hierarchy to process and disseminate global policies, rule sets, and configuration parameters.
4 In addition to reducing DSA control traffic volume going downward carrying policies, rules sets, and configuration parameters, this model reduces DSA control traffic going upward carrying spectrum sensing information where nodes and gateways fuse (and abstract) spectrum sensing information messages before forwarding them to upper networks entities.
5 Most importantly, make the best DSA decision available at any level of this hierarchy regardless of the control plane connectivity status.
5.2 The Generic DSA Cognitive Engine Skeleton
This section presents a generic construct of a DSA cognitive engine that can be followed at any of the hierarchical levels explained in the previous section. Although this book is not focused on cognitive engine design, it is appropriate to demonstrate that a common (skeleton) DSA cognitive engine concept can be followed at all entities of the hierarchy presented in this chapter in order to facilitate DSA as a set of cloud services. A DSA cognitive engine is responsible for many tasks, including spectrum sensing information fusion, offering DSA services and the propagation of policies, rule sets, and configuration parameters to the lower hierarchy entities.
Figure 5.2 shows this generic representation of the DSA cognitive engine. At the center of this DSA cognitive engine is an information repository. This information repository can differ from one entity to another based on its hierarchy and place in the hierarchical networks. The information repository can receive real‐time input from local sensors, from peer DSA engines or from other hierarchic DSA engines. The information repository can also be affected by automation inputs such as policies, rules, and configurations. The information repository is coupled with an information fusion and evolver. The DSA engine also has a resource monitor that can create recommendations and warnings to external entities and can disseminate messages to other entities as needed. The resource monitor can trigger policy updates, rules updates or configuration parameter updates that propagate from higher DSA entities to lower DSA entities. The DSA decision maker is a separate process that receives DSA services requests and responds to these requests. A request can be a local request or a dissemination request as explained above. The resource monitor can create internally triggered decisions (as a result of spectrum sensing information fusion) and pass them to the decision maker for consideration.
Figure 5.2 The generic cognitive engine representation that can be used at any network hierarchical entity offering DSA services.
As Chapter 8 explains, the decision maker can consider the impact of co‐site interference before disseminating a response to a service request.
Notice that:
this skeleton architecture applies for all hierarchical DSA decision making entities.
local response should be instantaneous.
dissemination based response should be slower and can depend on the control plane state.
fusion and information evolver is a continual process that can update the information repository. The information repository can be updated based on external messages or based on local analysis. An example of this internal update is the ROC model hypothesizing threshold explained in Chapter 3. For example, local analysis at a gateway can update this threshold value and create a message that disseminates to the network nodes to update the value of this threshold in