George F. Elmasry - Dynamic Spectrum Access Decisions

The National Institute of Standards and Technology (NIST) defines cloud computing as “a model for enabling ubiquitous, convenient, on‐demand network access to a shared pool of configurable computing resources – e.g., networks, servers, storage, applications, and services – that can be rapidly provisioned and released with minimal management effort or service provider interaction”. The goal of this chapter is to present a case for DSA to be designed as a collection of cloud services that are ubiquitous, convenient, and on‐demand for a shared pool of spectrum resources or frequency bands. Spectrum resources can be provisioned and released at different speeds depending on the hierarchy of heterogeneous networks with minimal management effort from a human in the loop. In addition to offering DSA services from provisioned spectrum resources, DSA cloud services can tap into opportunistic spectrum resources as well.

When interference is detected 3by any entity, a service request for a new frequency band to operate on can be triggered. The client for DSA cloud services here is not an actual person. The client is a network entity that is suffering from interference. The service is to re‐provision spectrum resources to accommodate all networks and nodes needed for seamless wireless communications.

NIST provides different service models for cloud computing that include infrastructure as a service (IaaS). DSA services can follow the IaaS model.

Figure 5.1shows a hierarchical heterogeneous network with a central network manager that is peered with a central spectrum arbitrator. The figure illustrates network gateways as another hierarchical layer where each network gateway has nodes within the network that are a lower hierarchical level. This hierarchy can grow to more layers 4but for the sake of simplifying this generic concept we will adhere to these three layers. Within this construct, there are two distinct control planes, as shown by the solid and dotted lines. The solid line is a control plane between the peer gateway nodes and between the peer gateway nodes and the central spectrum arbitrator. The dotted line is the control plane within a network. Each gateway can be a gateway of a different network that has its own control plane.

Figure 5.1The construct of DSA as a set of cloud services in network hierarchy.

This generic architecture construct has a goal: DSA services should be available as a set of cloud services for any entity that needs it regardless of the control planes' conditions. A system that offers DSA as a set of cloud services that optimize the use of spectrum resources will follow a hybrid approach that is a mix of local, distributed cooperative, and centralized DSA services. Notice that local DSA services can happen at any entity in this hierarchy. Distributed cooperative DSA can be between the peer nodes in the network or between the peer gateways. Each of these distributed cooperative techniques has a place in a hybrid design. Centralized services can happen at the central arbitrator or at the network gateway acting as a proxy of the central arbitrator's services. As Chapter 8 explains, co‐site interference considerations can be another type of DSA cloud services that can be added to the collection of DSA services as a subset of services. The system's specifications and requirements can guide the designer on how to mix and match these DSA services in the system.

As the reader goes through the next chapter, the concept of 5G cellular dynamic spectrum management being a derivative of this generic construct should become clearer. The lowest hierarchical entity in 5G cellular that can seek DSA services is the end user device or user equipment (UE). The UE has access to different hierarchical cells (equivalent to gateways) and the higher tier DSA decision (e.g., from a macro‐cell) can override the lower tier DSA decision (e.g., from a femtocell).

DSA decisions are often needed when wireless networks are suffering from interference and reduced connectivity. As a result, 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.