A New Spectrum Sharing Protocol: Towards a more Wireless Future
As the number of wireless devices increases, can we effectively utilize one of our most valuable natural resources?
During the summer of 2017, I had an excellent opportunity to serve as a research intern at the National Institute of Standards and Technology in the Communications Technology Lab, where I was specifically working on Spectrum Sharing. We essentially answered the question: how do we efficiently allocate different frequencies of the radio spectrum for use by different parties so that all are happy?
What is the the spectrum?
To understand Spectrum Sharing, one must first understand what the radio spectrum is. The radio spectrum is a range of frequencies, from approximately 30 hertz to 300 GHz over which information is sent. Most people are familiar with at least a portion of the spectrum — when somebody wants to listen to their favorite radio station, say 94.5, what they are doing is setting their receiver to pick up the frequency of 94.5 MHz.
A variety of different devices need access to the spectrum at different frequencies to communicate. Here is how the Federal Communications Commission (FCC) allocates spectrum access:
What is the problem?
When looking at the chart above, it is clear that the allocation of spectrum is very dense i.e. there are many parties competing for spectrum access and there is a scarcity of spectrum. Another major problem is exclusivity: licenses to use specific portions of the spectrum, say 150–160MHz, are granted to only one party — no one else is allowed to use that spectrum to communicate. And here is the crux of the problem: the number of parties needing the spectrum will increase, but the “amount” of spectrum is finite. Shared spectrum is the only way to ensure that it is available for everyone.
What is the solution?
The FCC has proposed to opening up one specific set of frequencies, from 3550 Hz to 3500 Hz, on a priority sharing basis, with the incumbent (the U.S. Navy) having highest priority to the spectrum, followed by commercial providers (i.e. Verizon, AT&T, etc), and finally amateurs. The WinnForum, a standards body, compiled the FCC rules into a sharing protocol called the Citizens Broadband Radio Service (CBRS) protocol, described below.
Basic Architecture
The CBRS spectrum sharing protocol involves a variety of different entities arranged in a way called the SAS-CBSD Architecture:
- Environmental Sensing Capability (ESC): A set of sensors deployed along the coast of the United States that detects when Naval ships are requesting access to spectrum; sends a signal to SAS temporarily stop communication of lower-tiered users.
- Spectrum Access System (SAS): The “brain” of the protocol. It registers users and determines who gets the spectrum for how long. When the ESC notifies the SAS of an incumbent Naval ship, it notifies all the CBSDs to vacate the channels their spectrum channels.
- Citizens Broadband Radio Service Device (CBSD): These are entities (users) who request access to and communicate over the spectrum.
- Domain Proxy: A device that pools requests of multiple CBSDs into one request.
As shown in the diagram above, the number of CBSDs is much larger than the number of SASs. Once each CBSD has been granted access to the spectrum (a specific set of frequencies for a certain amount of time) it must initiate what is called a heartbeat to continue using the spectrum (and if a SAS must tell a CBSD to vacate a channel because of a Navy radar, it must send that message back in a heartbeat response). Thus, the CBSDs are required to continuously heartbeat, not only to maintain access to the spectrum, but also to receive status updates from the SAS (as required by the rules, if a CBSD does not send a heartbeat request/receive a heartbeast response, it will automatically vacate the channel). Below is a timing diagram that shows the lifetime of a CBSD grant:
As required by FCC rules, from the time that the SAS receives a message from the ESC, CBSDs have five minutes to vacate the channel for the incumbent i.e. the Navy. However, the SAS can not tell a CBSD to vacate a channel until the CBSD itself has sent a heartbeat request message (on the heartbeat response it send the “vacate channel” message). If the CBSD sends the heartbeat request too often, it will overload the SAS and message could be dropped. If it sends the heartbeat infrequently, it may exceed it’s granted spectrum time and automatically vacate the channel, even if an incumbent is not present (leading to inefficiencies in the system). We ran experiments to determine how often the CBSD should heartbeat to maximize throughput in the system.
Simulation
To determine how often to heartbeat, we built a simulator in C++ using the Omnet++ library to model all interactions between the CBSD, SAS, ESC, and Domain Proxy:
Since the heartbeat request messages greatly outweigh all other messages in the system (by several orders of magnitude), we only consider these messages in our model. We represent message processing on the SAS side by an M/M/1 queue, and define the message arrival rate as
and to ensure a stable queue, we make sure that the ratio of the message arrival rate to that of the queue service rate be less than one. That is,
When rearranging this equation, we can determine the maximum number of CBSDs in the system
where G is the number of grants in the system. We see that the heartbeatInterval, queue servicing rate, and the grants in the system affect the number of CBSDs. All the parameters for simulator were stored in a .ned file, with the values shown here below.
Results
Through our experiments, we wanted to look at two specific things: 1) Overloading the SAS with messages (i.e. no incumbent radar present), also called the Unnecessary Timeout and 2) how quickly CBSDs vacate their channels when an incumbent radar appears. We look at the two cases separately.
Unnecessary Timeout
In this experiment, we keep the processing rate of the SAS constant as we increase the number of CBSDs. As this happens, the number of heartbeat messages in the system also increases. This will lead to some messages being dropped, and when a CBSD does not receive a heartbeat response, it will timeout and vacate the channel unnecessarily.
As shown in the figures above, we keep the service rate constant at 40 and 60 requests per second and steadily increase the number of CBSDs. We plot the number of heartbeat timeouts and failed grants as the number of CBSDs increase. The flat-lining that you see of the heartbeat failures is correlated with failed grants — as the more grants get rejected, the number of heartbeat requests more or less stays constant (a CBSD can not heartbeat unless its grant is approved). We see that the maximum number of CBSDs in this system should be limited to around 5000 and 10000 for 40 rps and 60 rps, respectively (this is when the number of heartbeat failures tend to increase significantly).
Time to vacate the channel
This experiment measures the ability of CBSDs to vacate their channel in the appropriate amount of time. When a SAS receives a message from the ESC, it places a signal in heartbeat response messages back to the CBSDs instructing them to vacate their channel. The figures below shows the Cumulative Distribution Function of CBSDs vacating the channel for different heartbeat intervals:
As you can see, as the time between successive heartbeats from the CBSDs increases, those CBSDs vacate closer and closer to the FCC-mandated 300 second timeout for transmission. Since there is randomness in every process, it is not advisable to set the heartbeat interval very high. However, if it is set too low (for example, the 90 second case) then the CBSDs are sending many messages to the SAS, potentially overloading it. We recommend setting the mean heartbeatInterval to 150 seconds, which not only provides adequate time for the CBSDs to vacate the channel in case of incumbent radar, but also does not overload the SAS.
Conclusion
Based on our simulation results, it seemed like setting the heartbeatInterval parameter to 150 seconds provides an optimal provisioning of resources for the SAS and CBSDs. Further steps in this process would include a more practical model of incumbent radar arrival (currently it was just modeled as probability distribution), and implement the move-list algorithm to decide which CBSDs needed to vacate their channels.
After doing this work at NIST in 2017, and after two conference proceeding rejections, our paper A Study of Timing Constraints and SAS Overload
of SAS-CBSD Protocol in the CBRS Band was finally accepted to IEEE GLOBECOM 2019 in Waikoloa, Hawaii. I want to thank my co-authors, Anirudha Sahoo (my NIST mentor) and Naceur El-Ouni for all their help with this!
