are fused to produce actions such as the following:
1 Spectrum awareness map. This map shows what frequency bands in the area of operation of this network suffer from interference, what probed frequency bands can be used, and what probed frequency bands should be avoided because they are occupied. As explained earlier, this spectrum awareness map at the gateway is more accurate than the spectrum awareness map at the network nodes and the spectrum awareness map can be more accurate if peer gateways share spectrum sensing information with each other in a distributed cooperative manner.
2 Reprioritizing of backup frequencies. The probing of unused frequency within the network can lead to changes in the backup frequency order of use. Also for a network that uses cooperative distributed DSA internal to the net, spatial use of the assigned frequency pool can be altered with time.
Figure 5.5 Gateway DSA engine upward propagation of spectrum sensing information.
As Figure 5.5 shows, fusion will result in updates in the gateway DSA engine information repository and this can trigger upward updates to the following entities:
1 The central arbitrator. Now the gateway DSA engine sees a different spectrum awareness map than the last time the gateway DSA engine updated the central arbitrator DSA engine. The gateway updates the central arbitrator with the new spectrum map.
2 The updates to the central DSA engine, which are sent over the same control plane, will reach the peer gateways.
Notice the asynchronous aspects of using cognitive engines where each cognitive engine works based on what information it collects and decisions occur as a result of fusion. Although these engines are not timely synchronized with each other, they work collectively, and sometimes using heuristics6 algorithms, to optimize the use of spectrum resources. In the meantime, DSA is offered as a set of cloud services at any point of the heterogeneous networks hierarchies regardless of the status of the control plane. If some spectrum awareness propagation messages are lost, DSA services will always be available when a service is requested.
The thread in Figure 5.5 shows one possible gateway cognitive DSA engine flow. Fusion can always trigger an action at any entity and this action can trigger a message flow that leads to other cognitive DSA engine fusions and triggers. The DSA design of large‐scale systems has to consider the amount of control traffic that can be generated from all of this information propagation upward, downward, and to peers. The design has to consider the tradeoffs mentioned in this book, which include the thresholds that trigger information dissemination. These thresholds must be selected and updated dynamically based on bandwidth availability.
5.3 DSA Cloud Services Metrics
A cloud service has to be evaluated by certain metrics per the NIST explanations of cloud services. The previous chapters have introduced metrics in areas such as the time between detecting interference (service request) and the time of overcoming interference and showed how this time as a metric can depend on the entity hierarchy and the specific mix and match of this hybrid approach to DSA. It is important to note that with IaaS, there may be direct metrics and indirect metrics. For example, measuring control traffic volume as a metric may not be used because measuring throughput efficiency or quality of service (QoS) metrics can indirectly consider control traffic volume impact.7 Intuitively, the lower the control traffic volume impact, the higher the throughput efficiency achieved, and thus measuring throughput efficiency indirectly measures the impact of control traffic volume.
5.3.1 DSA Cloud Services Metrics Model
In this section, we apply the cloud services model to DSA services. Figure 5.6 shows the standard cloud services model applied to DSA with three distinct stages:
1 The pre‐run stage defines the service and the service agreement.
2 The runtime stage, represented by the gray rectangle, where the service is monitored and enforced to meet the service agreement.
3 Post processing, where service accountability is measured.
Figure 5.6 The DSA cloud services model.
The first step in the Figure 5.6 model application to DSA services is simple. One of the DSA cloud services, such as response time, is selected. In typical cloud services, customer response time can be defined in the service agreement and the customer can know the response time before purchasing the service. DSA also needs a service agreement. The definition of a service agreement with DSA can be driven from system requirements and analysis. Response time can be the time between an entity reporting suffering from interference above a certain threshold (that can render connectivity to be lost or bandwidth to be below a certain value) and the time a new frequency band is assigned to overcome interference.
The gray rectangle in Figure 5.6 shows the runtime aspects of a cloud service where the service is monitored and policies, rule sets, and configuration parameters are adapted in order to force the service to adhere to the defined agreement. With DSA as a cloud service, policies, rule sets, and configuration parameter updates can be triggered by the DSA cognitive engine resource monitor, as shown in Figure 5.2, or by the decision maker, as shown in Figure 5.3. These actions are made in order to enforce the service to adhere to the service agreement during runtime. With DSA as a service, the design can create log files that can be analyzed as post processed in order to evaluate the DSA service accountability over a long period of time.
With DSA as a set of cloud services, while service agreements can be driven from system requirements, the design of DSA cloud services has to create metrics to help force the services to conform to the agreement and use metrics for measuring services accountability. The cognitive engine‐based design would have to gain understanding of the properties of the metrics used to force the service to adhere to the service agreement and scripted scenarios must be used to assess service accountability before system deployment.
5.3.2 DSA Cloud Services Metrology
Metrology is the scientific method used to create measurements. With cloud services, we need to create measurements to:
1 quantify or measure properties of the DSA cloud services
2 obtain a common understanding of these properties.
A DSA cloud services metric provides knowledge about a DSA service property. Collected measurements of this metric help the DSA cognitive engine estimate the property of this metric during runtime. Post‐processing analysis can provide further knowledge of the metric property.
It
