George F. Elmasry - Dynamic Spectrum Access Decisions

1 Disseminate frequency change to all nodes in the network with a frequency change time that is dependent on the waveform characteristics. For example, if the waveform uses TDMA with EPOCH time, the frequency change time defined by the gateway DSA engine can be at the start of the next EPOCH or it can be after N EPOCHs from the current time. It is critical to ensure that the frequency change message will reach all nodes before the actual change of frequency can occur and that all nodes synchronously switch to the new frequency. 5

2 Schedule for a frequency change locally to the gateway node so that the gateway and all the nodes in the network can continue the same network formation with the new frequency.

3 If the frequency change message is for a network that uses cooperative distributed DSA techniques, the frequency change message will contain a new pool of frequency bands for the network. The gateway DSA engine will have more work to do as it will have to disseminate the new pool and continue to perform cooperative distributed DSA within the network so that all the nodes in the network collectively try to optimize the use of the new pool of frequencies.

Figure 5.4Gateway DSA cognitive engine thread for a frequency change.

Note that Figure 5.4is one possible thread the gateway DSA cognitive engine may execute. This is an example of a thread that propagates down the hierarchy. The next section gives an example of a thread that propagates up the hierarchy.

This is an upward thread that can occur in the gateway DSA cognitive engine. With this thread, the gateway can be receiving spectrum sensing information from the following sources:

1 Local, if the gateway has augmented spectrum sensors or the gateway can be sensing the frequencies in use as explained in the previous chapters.

2 From peer gateway nodes. As explained earlier in this chapter, gateway nodes can be sharing their fused spectrum sensing information with peer gateway nodes.

3 From the network nodes. The gateway node can be a member node of one or more networks. These networks can have augmented sensors configured to sense (probe) certain frequency bands and can be forwarding spectrum sensing information of the used frequencies to the gateway.

Figure 5.5shows the progress of this thread to the fusion part. Collected spectrum sensing information from the different sources 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.5Gateway DSA engine upward propagation of spectrum sensing information.

As Figure 5.5shows, 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 heuristics 6algorithms, 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.5shows 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.

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. 7Intuitively, 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.

In this section, we apply the cloud services model to DSA services. Figure 5.6shows 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.6The DSA cloud services model.

The first step in the Figure 5.6model 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.