Hi, I'm Telleva Heath and I am the Spectrum Engineering Manager in the Wireless Services Team at Google, and this is the third lesson of your CBRS training. In this lesson, we're going to get into some more background on CBSD that you'll need to know. Remember CBSDs, the devices which transmitted the CBRS band and communicate with the spectrum access system also called the SAS, now we're going to cover how a CBSD and a SAS communicate with each other and go over some of the procedures and protocols used by CBRS equipment. We'll also have a quick overview of the CBSD life cycle. But first, let's talk about the larger CBRS ecosystem. You might be asking, who is actually making all these decisions about what happens in the CBRS band? More specifically, who has defined the way CBRS works, the language we use to describe it, and the rules around it? It mostly boils down to three main entities. The FCC, that's the Federal Communications Commission is the government regulatory agency that assigned spectrum and they created the high-level rules for using CBRS. FCC rules, particularly the one called Part 96 define the CBRS band for the general rules for its use. Then there's the Wireless Innovation Forum which it's members call WInnForum. WInnForum is an industry led group that defines requirements and protocols for using the CBRS band. Members of WInnForum include SAS administrators, CBRS equipment manufacturers, network operators, and training program administrators like Google. The FCC and Department of Defense employees also regularly participate in WInnForum to help ensure that incumbent users will be protected. One WInnForum document we recommend you read is the SAS CBSD specification which defines how a CBSD talks to the SAS. That document is the source for a lot of material in this presentation and section 10 is particularly important to read. There will be a second release in the future. So bookmark the WInnForum specification webpage in the resources section and check for updates. Finally, there's the CBRS Alliance, an industry group that manages the ongoing certification program for healthy use in the CBRS band. So those are the big three entities you should know that are making the big decisions about what happens in the CBRS band. Now let's get into the relationship between a SAS and a CBSD. Just for ease right now, we're going to talk about direct communication between the two. But don't forget that in some cases a domain proxy might be needed to talk to the SAS on behalf of one or multiple CBSDs. Even in that case, they'll exchange exactly the same kind of messages. The first thing you should know is that it's always a CBSD which sends a request to the SAS and the SAS which responds. The SAS can't proactively reach out to a CBSD. A response from the SAS always includes a response code. The response code is a number that represents the outcome of that request. If you want to read up on all of the possible codes, you can checkout table 39 in the WInnForum SAS-CBSD specification, but we'll describe some key ones later in this course too. Before we can begin to transmit in the CBRS band, a CBSD needs to send a registration request to the SAS. This is a message that includes information identifying the CBSD, where and how it's been installed, and who owns it. The SAS receives those parameters and if they are approved, the SAS sends back a unique identifier it's going to use to identify this CBSD. This is called the CBSD ID. This registration process is where all the action happens for the CPI. They need to ensure that the parameters sent to the SAS are complete and correct. Remember, the SAS can't do its job without 100 percent correct information, and as a CPI, they're responsible for the accuracy of all information they send to the SAS. The SAS-CBSD specification defines three types of parameters. A required parameter meaning the CBSD absolutely must provide this in registration requests that it sends to the SAS. An optional parameter, meaning CBSD might choose to omit this perimeter, but if it's included, its value will need to be validated by the SAS, and a REG-Conditional parameter. This is a parameter the CPI must provide. We'll go over these perimeters in more detail in the next lesson, including the cases where these perimeters are actually optional. After a CBSD is installed, it registers with the SAS. But just completing registration doesn't mean a CBSD can immediately start transmitting. Once the CBSD is registered, it may ask the SAS about what spectrum is available at its location. That's done with a spectrum inquiry request. The SAS will respond with a list of frequency ranges which are most likely available for this CBSD to use and also the transmit power levels that it could use in each of those ranges. Once the CBSD picks up an available frequency range and transmit power that it would like to use, it will send a grant request to the SAS. The grant the CBSD is asking for is a spectrum release provided by the SAS to the CBSD. It's restricted to a specific set of operating parameters. So to operate on a different frequency, the CBSD would first need to obtain a new grant. If the SAS approves the request, its response will include a grant ID which is a unique identifier for this particular spectrum grant. A CBSD can actually have multiple grants as long as their frequency ranges don't overlap. But a CBSD can't have simultaneous grants from different SASs. Got all that? So now let's say your CBSD is registered and it has its grant. Now it must be able to transmit, right? It's really close, but the CBSD still has to send a heartbeat request. The heartbeat request is checking with the SAS to verify that it's authorized to transmit using its grant. As always, the SAS will respond with a response code. Here are descriptions of the most common ones. Success, means the CBSD could now transmit with this grant. The CBSD is ready to go. Terminated grant means the SAS had to revoke the grant and the CBSD is going to have to start over again and try to get a new one. Suspended grant means the CBSD still has the grant but it just can't use it to transmit right now. In this situation, the CBSD should keep heartbeating on the grant and hopefully it'll be able to transmit soon. If that doesn't work, the CBSD can try to get another grant and use that to transmit. Be aware that some CBSD interfaces will show you these names and others might show you a numeric code. To see the full list, you can reference the WInnForum document we suggested earlier. CBSDs are actually required to heartbeat at least once every four minutes. This is so that SAS can update their permissions in response to shifts and high priority user activity. Remember that the SAS can't reach out to CBSDs, which is why it needs the CBSDs to phone home so frequently. Remember, the SAS's top priority is to protect incumbents. So if a CBSD misses a heartbeat, it has to stop transmitting until it successfully heartbeats again. That's it for module 3. Now that you know more about the CBRS band, CBSDs, and the SAS, go grab a cup of coffee like I've had, take the dog for a walk, and come back here for our next lesson where we'll get into the nitty-gritty details of determining parameters for CBSDs. See you back here real soon.