Patent Description:
<CIT> discloses a system and computerized method for controlling access to shared spectrum in which access is prioritized among different classes of devices so that top priority devices have immediate access to the shared spectrum and lower priority devices contend for access. In some embodiments, the system and computerized method comprises managing a set of priority classes of devices to use the shared spectrum and granting rights to one or more of the requesting devices to use a portion of the shared spectrum during a requested use period based on a decision making process.

<NPL> presents functional and operational requirements specification created by WlnnForum that standardizes Citizens Broadband Radio Service (CBRS) operation.

<NPL> presents detailed procedures describing the transactions over the SAS-CBSD interface.

The present disclosure is better understood, and its numerous features and advantages made apparent to those skilled in the art by referencing the accompanying drawings.

The Federal Communication Commission (FCC) has begun offering bands of spectrum owned by federal entities for sharing with commercial operations. For example, newly issued FCC rules in <NUM> Code of Federal Regulations (CFR) Part <NUM> allows sharing of the <NUM>-<NUM> Citizens Broadband Radio Service (CBRS) between incumbents and other operators. The CBRS operates according to a tiered access architecture that distinguishes between incumbents, operators that have received a priority access license (PAL) consistent with <NUM> CFR §<NUM>, et seq. , and general authorized access (GAA) operators that are authorized to implement one or more base stations, wireless devices, or wireless access devices such as Citizens Broadband radio Service Devices (CBSDs) consistent with <NUM> CFR §<NUM>, et seq. Incumbents, PAL licensees, and GAA operators are required to request access from a spectrum access system (SAS), which allocates frequency bands to the operators, e.g., for CBRS within the <NUM>-<NUM> band. The SAS is responsible for managing or controlling different types of CBSDs in the CBRS frequency bands.

In current deployments, the CBSD are categorized as:.

The SAS allocates frequency bands to the CBSDs associated with the operators within particular geographical areas and, in some cases, during particular time intervals. The SAS determines whether incumbents are present within corresponding geographical areas using an environmental sensing capability (ESC) that performs incumbent detection, e.g., using radar to detect the presence of a Navy ship in a port.

The tiered access architecture provides priority access to incumbents, which include Grandfathered Wireless Broadband Licensees that are authorized to operate on a primary basis on frequencies designated in <NUM> CFR §<NUM>. When an incumbent is present in a geographical area, the incumbent is granted exclusive access to a portion of the CBRS spectrum within the geographic area. For example, if a Navy ship enters a port, communication systems on the ship are granted exclusive access to a <NUM>-<NUM> band within the <NUM>-<NUM> band. Operators that have received a PAL and GAA operators are required to vacate the band allocated to the ship. A PAL license grants exclusive access to a portion of the <NUM>-<NUM> band within a predetermined geographical area as long as no incumbents have been allocated an overlapping portion of the <NUM>-<NUM> band within the predetermined geographical area. The GAA operators are given access to a portion of the <NUM>-<NUM> band within a geographic area as long as no incumbents or PAL licensees have been allocated an overlapping portion in the same geographic area during a concurrent time interval. The GAA operators are also required to share the allocated portion of the <NUM>-<NUM> band if other GAA operators are allocated the same portion.

The FCC and the National Telecommunications and Information Administration (NTIA) define protection areas that give priority to incumbents or other base stations or users. Examples of protection areas include, but are not limited to, areas associated with incumbents in a Fixed Satellite System (FSS), a grandfathered wireless protection zone (GWPZ), a region associated with a grandfathered wireless broadband license (GWBL), a region associated with a priority access license (PAL), a region associated with an ESC, and dynamic protection areas (DPAs).

The FCC and the NTIA also define a set of DPAs along the east, west, and Gulf coasts of the United States. A DPA is a pre-defined local protection area that is activated or deactivated as necessary to protect Department of Defense (DOD) radar systems. All outdoor (Category B) CBSD within an activated DPA are required to stop transmission or reduce transmission to below a threshold transmit power. One or more ESC sensors deployed within a DPA detect the presence or absence of an incumbent. In some cases, an ESC cloud gathers information from a set of ESC sensors within a DPA and uses this information to detect incumbents. An ESC sensor (or cloud) transmits a report to the SAS for the DPA in response to the ESC sensor (or cloud) detecting the presence of an incumbent. The report includes information identifying the portion (e.g., <NUM>-<NUM>) of the total <NUM> CBRS spectrum that is impacted by the presence of the incumbent. In response to receiving the report, the SAS performs interference management using all the CBSDs within the DPA that are operating within the impacted frequency range. For example, the SAS can move the CBSD to a different channel or instruct the CBSD to operate with a lower transmit power to keep the interference level in compliance with FCC regulations. Lowering the transmit power reduces the transmission coverage area for the CBSD. A DPA can only be deactivated by an operational ESC sensor. Thus, the SAS and the ESC sensor (or cloud) maintain a constant heartbeat exchange to verify that an operational ESC sensor is present within the DPA. If there are no operational ESC sensors deployed within a DPA, the DPA must be activated throughout the entire <NUM> CBRS spectrum. Moreover, no outdoor CBSDs (Category B) can be deployed in a DPA without an ESC sensor.

Regional instances of the SAS operated by different vendors perform Coordinated Periodic Activities Among SASs (CPAS) every <NUM> hours by exchanging status information for the CBSDs that are managed by the SAS instances. The instances of the SAS use the exchanged status information to compute or update channel and power assignments for the CBSDs based on the new snapshot of the CBSDs managed by all SAS instances from all SAS administrators. Accounting to the properties of the different CBSDs allows each instance of the SAS to appropriately protect the incumbents via accurate interference calculations that are performed based on status information for all the CBSDs deployed in the geographic area. If the CBSDs in an edge cloud network fall within a DPA, the instances of the SAS compute backup channel grant lists for the CBSDs in addition to the primary channel grant. Information indicating the backup channel grant list is relayed to the local SAS instantiated by the domain proxy on the edge cloud. The local SAS stores the backup channel grant in case the incumbent appears when the regional instances of the SAS are inaccessible and the primary channel grant is impacted by the incumbent presence in the lower <NUM>. Results obtained from CPAS are valid for a predetermined time interval such as <NUM>-hrs.

The regional instances of the SAS do not typically account for the potential interference caused by any CBSDs that are installed after the last CPAS and before the next CPAS. Consequently, the interference calculations that were previously performed based on status information for the CBSDs that were deployed in the geographic area at the time of the previous CPAS would be invalidated if the newly installed CBSDs were allowed to begin transmission immediately. To avoid disrupting the previously installed CBSDs, the newly installed CBSDs receive a suspended grant from the SAS that includes information indicating a channel allocated to the newly installed CBSD but does not authorize the newly installed CBSD to begin providing service. Following a successful CPAS computation, the SAS converts a provisional suspended grant to a valid grant that allows the CBSD to use the assigned channel with a transmit power that is determined by the CPAS computation.

Technicians are sent into the field to install CBSDs. For example, the FCC requires certified professional installers (CPI) to perform the installation of outdoor (Category B) CBSDs and indoor (Category A) CBSDs that are deployed outside at a height above <NUM> meters (m). The CPI is responsible for installing the CBSD and verifying that the CBSD is operating correctly by performing a series of tests including a power check to verify that the CBSD can power up, a registration check to verify that the CBSD successfully registered with the SAS, a grant check to verify that the CBSD received a grant from the SAS, a radio grant check to verify that the CBSD is authorized for communication on the granted channel, and a walk-through check to verify that user equipment are receiving data transmitted by the CBSD. However, the walk-through check cannot be performed on a CBSD that has only received a suspended grant because the CBSD is not authorized to transmit until the suspended grant is converted to a valid grant. As discussed above, suspended grants are not converted to valid grants until after the next CPAS, which are performed at intervals of <NUM> hours in most cases. The CPI is therefore required to install the CBSD and then wait up to <NUM> hours to perform the testing phase of the installation process. Thus, the CPI would typically have to make two trips (or more if any reconfigurations are needed) out to the installation site to complete installation of the CBSD.

<FIG> disclose embodiments of an SAS that issues a test grant in response to a registration request from a CBSD being installed in a protection area to provide a technician time to complete the testing and installation process for the CBSD. The test grant allocates a channel to the CBSD and authorizes the CBSD to transmit on this channel at the minimum power allocation for a reduced time interval such as <NUM> minutes or <NUM> minutes. The test grant is converted to a suspended grant in response to expiration of the reduced time interval. In some embodiments, a technician requests one or more additional reduced time intervals to complete the testing process after the original request expires. The suspended grant is subsequently converted to a valid grant following the next successfully completed CPAS. In some embodiments, installation and testing of the CBSD is performed according to a framework that coordinates installation and testing of multiple CBSDs by multiple CPIs. In some embodiments, the grants issued by the SAS have two states: granted and authorized. Once granted, a CBSD cannot use the allocated channel until the grant is authorized. Thus, as used herein, the term "valid grant" refers to a grant that has been granted and authorized. The term "suspended grant" refers to a grant that has been granted but not yet authorized. The term "test grant" refers to a grant that has been granted and authorized for a limited amount of time such as the reduced time interval of <NUM> minutes or <NUM> minutes.

Some embodiments of the SAS estimate an updated aggregate interference level within the DPA by combining an aggregate interference level that was computed for the previously installed CBSDs during a previous CPAS with an interference level estimated for the newly installed CBSD based on a minimum power allocation and a path loss associated with the newly installed CBSD. The SAS issues the test grant in response to the updated aggregate interference level being less than a threshold value. If the updated aggregate interference level is greater than a threshold value, the SAS issues a suspended grant to the CBSD. The reduced time interval is selected to provide the technician with sufficient time to perform testing and verification of the CBSD, e.g., to perform a walk-through check to verify that user equipment camp on the CBSD and receive data transmitted by the CBSD. Some embodiments of the SAS perform an on-demand CPAS for the newly installed CBSD to estimate aggregate interference to one or more nearby incumbents based on previously calculated interference from a subset of previously installed CBSDs and estimated interference from the newly installed CBSD. The on-demand aggregate interference is then used to determine the lowest possible power level that can be safely allocated to the CBSD for the duration of the test grant.

<FIG> is a block diagram of a communication system <NUM> according to some embodiments. The communication system <NUM> operates in accordance with the FCC rules set forth in <NUM> Code of Federal Regulations (CFR) Part <NUM>, which allows sharing of the <NUM>-<NUM> Citizens Broadband Radio Service (CBRS) between incumbents and other operators. However, some embodiments of the communication system <NUM> operate in accordance with other rules, standards, or protocols that support sharing of a frequency band between incumbents and other devices such that the frequency band is available for exclusive allocation to an incumbent device if the incumbent device is present in a geographic area. In that case, the other devices are required to vacate any portion of the frequency band that overlaps with another portion of the frequency band that is allocated to the incumbent device. For example, if the communication system <NUM> is deployed (at least in part) proximate a port and a Navy ship such as an aircraft carrier <NUM> arrives in the port, devices in a geographic area proximate the port that are providing wireless connectivity in a portion of the frequency band allocated to the aircraft carrier <NUM> are required to vacate the portion of the frequency band to provide the aircraft carrier <NUM> with exclusive access to the frequency band within the geographic area.

The communication system <NUM> includes a regional cloud <NUM> that provides cloud-based support for a private enterprise network <NUM>. Some embodiments of the regional cloud <NUM> include one or more servers that are configured to provide operations and maintenance (O&M) management, a customer portal, network analytics, software management, and central security for the private enterprise network <NUM>. The regional cloud <NUM> also includes an SAS instance <NUM> to allocate frequency bands to operators, e.g., to the private enterprise network <NUM> for CBRS within the <NUM>-<NUM> band. The communication system <NUM> also includes another regional cloud <NUM> that includes an SAS instance <NUM>. In the illustrated embodiment, the regional clouds <NUM>, <NUM> are located at different geographic locations and are therefore used to provide geo-redundancy. For example, the SAS instance <NUM> can be selected as a primary SAS and the SAS instance <NUM> can be selected as a secondary, geo-redundant SAS. The SASs <NUM>, <NUM> communicate with each other over an SAS-SAS interfaces (not shown in <FIG> in the interest of clarity). If additional SAS instances are present in the communication system <NUM>, the SAS instances communicate with each other over corresponding SAS-SAS interfaces. The SASs <NUM>, <NUM> can serve multiple private enterprise networks, although a single private enterprise network <NUM> is shown in <FIG> in the interest of clarity.

The regional clouds <NUM>, <NUM> are configured via user interface portals to one or more external computers <NUM>, only one of which is shown in <FIG> in the interest of clarity. For example, the external computer <NUM> can provide a customer user interface portal for service management, a digital automation cloud management user interface portal, and an SAS user interface portal that is used to configure the SASs <NUM>, <NUM>.

The private enterprise network <NUM> includes an edge cloud <NUM> that communicates with the regional clouds <NUM>, <NUM> to support a plug-and-play deployment of the private enterprise network <NUM>. Some embodiments of the edge cloud <NUM> support auto configuration and self-service, industrial protocols, local connectivity with low latency, LTE-based communication and local security, high availability, and other optional applications for the private enterprise network <NUM>. In the illustrated embodiment, the edge cloud <NUM> implements a domain proxy <NUM> that provides managed access and policy control to a set of CBSDs <NUM>, <NUM>, <NUM> that are implemented using base stations, base station routers, mini-macrocells, microcells, indoor/outdoor picocells, femtocells, or other wireless devices or wireless access devices. As used herein, the term "base station" refers to any device that provides wireless connectivity in the private enterprise network <NUM>. Some embodiments of the base station operate as a CBSD, e.g., as either category A CBSD (Indoor), Category B CBSD (outdoor), or customer premises equipment (CPE). The CBSDs <NUM>, <NUM>, <NUM> are therefore referred to herein as the base stations <NUM>, <NUM>, <NUM> and collectively as "the base stations <NUM>-<NUM>. " Some embodiments of the domain proxy <NUM> are implemented in one of the regional clouds <NUM>, <NUM>.

The domain proxy <NUM> mediates between the SASs <NUM>, <NUM> and the base stations <NUM>-<NUM>. In order to utilize the shared spectrum, the base stations <NUM>-<NUM> transmit requests towards one of the SASs <NUM>, <NUM> to request allocation of a portion of a frequency band. The other one of the SASs <NUM>, <NUM> is used as a secondary SAS in case of a failure associated with the primary SAS. The requests include information identifying the portion of the frequency band such as one or more channels, a geographic area corresponding to a coverage area of the requesting base station, and, in some cases, a time interval that indicates when the requested portion of the frequency band is to be used for communication. In the illustrated embodiment, the coverage area of the base stations <NUM>-<NUM> corresponds to the area encompassed by the private enterprise network <NUM>. Some embodiments of the domain proxy <NUM> reduce the signal load between the domain proxy <NUM> and the SASs <NUM>, <NUM> by aggregating requests from multiple base stations <NUM>-<NUM> into a smaller number of messages that are transmitted from the domain proxy <NUM> to the SASs <NUM>, <NUM>. The base stations <NUM>-<NUM> provide wireless connectivity to corresponding user equipment <NUM>, <NUM>, <NUM> (collectively referred to herein as "the user equipment <NUM>-<NUM>") in response to the SASs <NUM>, <NUM> allocating portions of the frequency band to the base stations <NUM>-<NUM>.

The requests transmitted by the base stations <NUM>-<NUM> do not necessarily include the same information. Some embodiments of the requests from the base stations <NUM>-<NUM> include information indicating different portions of the frequency band, different geographic areas, or different time intervals. For example, the base stations <NUM>-<NUM> request portions of the frequency band for use in different time intervals if the private enterprise network <NUM> is deployed in a mall or shopping center and the base stations <NUM>-<NUM> are used to provide wireless connectivity within different stores that have different operating hours. The domain proxy <NUM> therefore manages the base stations <NUM>-<NUM> using separate (and potentially different) policies on a per-CBSD basis. In some embodiments, the domain proxy <NUM> accesses the policies for the base stations <NUM>-<NUM> in response to receiving a request from one of the base stations <NUM>-<NUM>. The domain proxy <NUM> determines whether the requesting base station from which the request is received is permitted to access the SAS instance <NUM> based on the policy, e.g., by comparing information in the policy to information in one or more mandatory fields of the request. The domain proxy <NUM> selectively provides the requests to the SASs <NUM>, <NUM> depending on whether the requesting base station is permitted to access the SASs <NUM>, <NUM>. If so, the request is transmitted to the SASs <NUM>, <NUM> or aggregated with other requests for transmission to the SASs <NUM>, <NUM>. Otherwise, the request is rejected.

As discussed herein, the FCC requires certified professional installers (CPI) to perform the installation of outdoor (Category B) CBSDs and indoor (Category A) CBSDs that are deployed outside at a height above <NUM> meters (m). A complete installation includes testing and verification of the newly installed base station (or CBSD) while the base station is authorized to transmit (and receive) signals over one or more channels. For example, the CPI performs testing and verification on the base station <NUM> in response to installing the base station <NUM>. In the illustrated embodiment, the SAS <NUM> (or, in other embodiments, the SAS <NUM>) receives a registration request from the base station <NUM> in response to the base station <NUM> being installed. The SAS <NUM> allocates to the base station <NUM> a channel in the shared spectrum and a transmission power to be used by the base station <NUM>. The SAS <NUM> transmits a test grant authorizing the base station <NUM> to transmit on the channel at the transmission power for a predetermined time interval such as <NUM> minutes or <NUM> minutes. The SAS <NUM> converts the test grant to a suspended grant following the predetermined time interval. In some cases, the SAS <NUM> receives the registration request from the base station <NUM> in response to the base station <NUM> being installed in the DPA <NUM>.

<FIG> is a block diagram of a network function virtualization (NFV) architecture <NUM> according to some embodiments. The NFV architecture <NUM> is used to implement some embodiments of the communication system <NUM> shown in <FIG>. The NFV architecture <NUM> includes hardware resources <NUM> including computing hardware <NUM> such as one or more processors or other processing units, storage hardware <NUM> such as one or more memories, and network hardware <NUM> such as one or more transmitters, receivers, or transceivers. A virtualization layer <NUM> provides an abstract representation of the hardware resources <NUM>. The abstract representation supported by the virtualization layer <NUM> can be managed using a virtualized infrastructure manager <NUM>, which is part of the NFV management and orchestration (M&O) module <NUM>. Some embodiments of the virtualized infrastructure manager <NUM> are configured to collect and forward performance measurements and events that may occur in the NFV architecture <NUM>. For example, performance measurements may be forwarded to an orchestrator (ORCH) <NUM> implemented in the NFV M&O <NUM>. The hardware resources <NUM> and the virtualization layer <NUM> may be used to implement virtual resources <NUM> including virtual computing <NUM>, virtual storage <NUM>, and virtual networking <NUM>.

Virtual networking functions (VNF1, VNF2, VNF3) run over the NFV infrastructure (e.g., the hardware resources <NUM>) and utilize the virtual resources <NUM>. For example, the virtual networking functions (VNF1, VNF2, VNF3) are implemented using virtual machines supported by the virtual computing resources <NUM>, virtual memory supported by the virtual storage resources <NUM>, or virtual networks supported by the virtual network resources <NUM>. Element management systems (EMS1, EMS2, EMS3) are responsible for managing the virtual networking functions (VNF1, VNF2, VNF3). For example, the element management systems (EMS1, EMS2, EMS3) may be responsible for fault and performance management. In some embodiments, each of the virtual networking functions (VNF1, VNF2, VNF3) is controlled by a corresponding VNF manager <NUM> that exchanges information and coordinates actions with the virtualized infrastructure manager <NUM> or the orchestrator <NUM>.

The NFV architecture <NUM> may include an operation support system (OSS)/business support system (BSS) <NUM>. The OSS/BSS <NUM> deals with network management including fault management using the OSS functionality. The OSS/BSS <NUM> also deals with customer and product management using the BSS functionality. Some embodiments of the NFV architecture <NUM> use a set of descriptors <NUM> for storing descriptions of services, virtual network functions, or infrastructure supported by the NFV architecture <NUM>. Information in the descriptors <NUM> may be updated or modified by the NFV M&O <NUM>.

The NFV architecture <NUM> can be used to implement network slices <NUM> that provide user plane or control plane functions. A network slice <NUM> is a complete logical network that provides communication services and network capabilities, which can vary from slice to slice. User equipment can concurrently access multiple network slices <NUM>. Some embodiments of user equipment provide Network Slice Selection Assistance Information (NSSAI) parameters to the network to assist in selection of a slice instance for the user equipment. A single NSSAI may lead to the selection of several network slices <NUM>. The NFV architecture <NUM> can also use device capabilities, subscription information and local operator policies to do the selection. An NSSAI is a collection of smaller components, Single-NSSAIs (S-NSSAI), which each include a Slice Service Type (SST) and possibly a Slice Differentiator (SD). Slice service type refers to an expected network behavior in terms of features and services (e.g., specialized for broadband or massive IoT), while the slice differentiator can help selecting among several network slice instances of the same type, e.g. to isolate traffic related to different services into different network slices <NUM>.

<FIG> is a block diagram illustrating an allocation <NUM> of frequency bands and an access priority <NUM> for incumbents, licensed users, and general access users according to some embodiments. The allocation <NUM> and the access priorities <NUM> are used to determine whether CBSDs such as the base stations <NUM>-<NUM> shown in <FIG> are given permission to establish a wireless communication links in portions of the frequency band. The frequency band extends from <NUM> to <NUM> and therefore corresponds to the spectrum allocated for CBRS. An SAS such as one of the SAS instances <NUM>, <NUM> shown in <FIG> allocates portions of the frequency band to devices for providing wireless connectivity within a geographic area. For example, the SAS can allocate <NUM>-<NUM> portions of the frequency band to different devices for use as communication channels.

Portions of the frequency band are allocated to incumbent federal radio location devices, such as Navy ships, from the block <NUM>, which corresponds to all the frequencies in the available frequency band. Portions of the frequency band are allocated to incumbent FSS receive-only earth stations from the block <NUM>. Portions of the frequency band are allocated to grandfathered incumbent wireless broadband services from the block <NUM>. As discussed herein, the portions of the frequency band are allocated from the blocks <NUM>, <NUM>, <NUM> for exclusive use by the incumbent.

Operators that have received a priority access license (PAL) consistent with <NUM> CFR §<NUM>, et seq. are able to request allocation of portions of the frequency band in the block <NUM>. The portion of the frequency band that is allocated to an operator holding a PAL is available for exclusive use by the operator in the absence of any incumbents in an overlapping frequency band and geographic area. For example, the SAS can allocate a PAL channel in any portion of the entire <NUM> of CBRS band as long as it is not pre-empted by the presence of an incumbent. Portions of the frequency band within the block <NUM> are available for allocation to general authorized access (GAA) operators that are authorized to implement one or more CBSDs consistent with <NUM> CFR §<NUM>, et seq. The GAA operators provide wireless connectivity in the allocated portion in the absence of any incumbents or PAL licensees on an overlapping frequency band and geographic area. The GAA operators are also required to share the allocated portion with other GAA operators, if present. Portions of the frequency band within the block <NUM> are available to other users according to protocols defined by the Third Generation Partnership Project (3GPP).

The access priority <NUM> indicates that incumbents have the highest priority level <NUM>. Incumbents are therefore always granted exclusive access to a request to portion of the frequency band within a corresponding geographic area. Lower priority operators are required to vacate the portion of the frequency band allocated to the incumbents within the geographic area. The access priority <NUM> indicates that PAL licensees have the next highest priority level <NUM>, which indicates that PAL licensees receive exclusive access to an allocated portion of the frequency band in the absence of any incumbents. The PAL licensees are also entitled to protection from other PAL licensees within defined temporal, geographic, and frequency limits of their PAL. The GAA operators (and, in some cases, operators using other 3GPP protocols) received the lowest priority level <NUM>. The GAA operators are therefore required to vacate portions of the frequency band that overlap with portions of the frequency band allocated to either incumbents or PAL licensees within an overlapping geographic area.

<FIG> is a block diagram of a communication system <NUM> that implements tiered spectrum access according to some embodiments. In the illustrated embodiment, the communication system <NUM> implements tiered spectrum access in the <NUM>-<NUM> CBRS band via a WInnForum architecture. The communication system <NUM> includes an SAS instance <NUM> that performs operations including incumbent interference determination and channel assignment, e.g., for CBRS channels shown in <FIG>. In the illustrated embodiment, the SAS instance <NUM> is selected as a primary SAS. An FCC database <NUM> stores a table of frequency allocations that indicate frequencies allocated to incumbent users and PAL licensees. An informing incumbent <NUM> provides information indicating the presence of the incumbent (e.g., a coverage area associated with the incumbent, and allocated frequency range, a time interval, and the like) to the SAS instance <NUM>. The SAS instance <NUM> allocates other portions of the frequency range to provide exclusive access to the informing incumbent <NUM> within the coverage area. An environmental sensing capability (ESC) <NUM> performs incumbent detection to identify incumbents using a portion of a frequency range within the geographic area, e.g., using a radar sensing apparatus <NUM>. Some embodiments of the SAS instance <NUM> are connected to other SAS instance <NUM>, e.g., a secondary SAS instance <NUM>. The primary and secondary SAS instance <NUM>, <NUM> are connected via corresponding interfaces so that the SAS instance <NUM>, <NUM> coordinate allocation of portions of the frequency range in geographic areas or time intervals.

A domain proxy <NUM> mediates communication between the SAS instance <NUM> and one or more CBSDs <NUM>, <NUM>, <NUM> via corresponding interfaces. The domain proxy <NUM> receives channel access requests from the CBSDs <NUM>, <NUM>, <NUM> and verifies that the CBSDs <NUM>, <NUM>, <NUM> are permitted to request channel allocations from the SAS instance <NUM>. The domain proxy <NUM> forwards requests from the permitted CBSDs <NUM>, <NUM>, <NUM> to the SAS instance <NUM>. In some embodiments, the domain proxy <NUM> aggregates the requests from the permitted CBSDs <NUM>, <NUM>, <NUM> before providing the aggregated request to the SAS instance <NUM>. The domain proxy <NUM> aggregates requests based on an aggregation function that is a combination of two parameters: (<NUM>) a maximum number of requests that can be aggregated into a single message and (<NUM>) a maximum wait duration for arrival of requests that are to be aggregated into a single message. For example, if the wait duration is set to <NUM> and the maximum number of requests is <NUM>, the domain proxy accumulates receive requests until the wait duration reaches <NUM> or the number of accumulated requests which is <NUM>, whichever comes first. If only a single request arrives within the <NUM> wait duration, the "aggregated" message includes a single request.

Thus, from the perspective of the SAS instance <NUM>, the domain proxy <NUM> operates as a single entity that hides or abstracts presence of the multiple CBSDs <NUM>, <NUM>, <NUM> and conveys communications between the SAS instance <NUM> and the CBSDs <NUM>, <NUM>, <NUM>. One or more CBSD <NUM> (only one shown in the interest of clarity) are connected directly to the SAS instance <NUM> and can therefore transmit channel access requests directly to the SAS instance <NUM>. Additional discussion of this architecture is provided in Appendix B, from the Wireless Innovation Forum, entitled "<NPL>, which is incorporated by reference herein in its entirety.

<FIG> is a block diagram of a communication system <NUM> that implements a spectrum controller cloud <NUM> to support deployment of private enterprise networks in a shared spectrum according to some embodiments. The spectrum controller cloud <NUM> instantiates multiple instances of domain proxies <NUM> that support one or more private enterprise networks. The spectrum controller cloud <NUM> also instantiates multiple SAS instances <NUM> that support one or more private enterprise networks. Although not shown in <FIG>, the SAS instances <NUM> can be connected to other SAS instances, e.g., in other clouds, via corresponding interfaces. Coexistence management (CXM) functions <NUM> and spectrum analytics (SA) functions <NUM> are also instantiated in the spectrum controller cloud <NUM>.

One or more ESC instances <NUM> are instantiated and used to detect the presence of incumbents. In the illustrated embodiment, standalone ESC sensors <NUM>, <NUM>, <NUM> (collectively referred to herein as "the sensors <NUM>-<NUM>") are used to monitor a frequency band to detect the presence of an incumbent such as a Navy ship. The ESC instances <NUM> notify the corresponding instance of the SAS instance <NUM> in response to detecting the presence of an incumbent in a corresponding geographic area. The SAS instance <NUM> is then able to instruct non-incumbent devices that serve the geographic area to vacate portions of the spectrum overlapping with the spectrum allocated to the incumbent, e.g., by defining a DPA. As discussed herein, some embodiments of the SAS instance <NUM> register with an ESC cloud to provide ESC services for the SAS instance <NUM> (or an SAS administrator for the SAS instance <NUM>). Thus, although <FIG> depicts the SAS instance <NUM> and the ESC instances <NUM> as part of the same spectrum controller cloud <NUM>, the ESC instances <NUM> are not necessarily deployed in the same location or controlled by the same vendor or provider as the SAS instances <NUM>.

One or more base stations <NUM>, <NUM>, <NUM> (collectively referred to herein as "the base stations <NUM>-<NUM>") in a private enterprise network communicate with one or more of the domain proxies <NUM> and the SAS instances <NUM> via an evolved packet core (EPC) cloud <NUM>. The base stations <NUM>-<NUM> have different operating characteristics. For example, the base station <NUM> operates according to a PAL in the <NUM> frequency band, the base station <NUM> operates according to GAA in the <NUM> frequency band, and the base station <NUM> operates according to a PAL and GAA in the <NUM> frequency band. The base stations <NUM>-<NUM> are configured as Category A (indoor operation with a maximum power of <NUM> dBm), Category B (outdoor operation with a maximum power of <NUM> dBm), or CPE. However, in other embodiments, one or more of the base stations <NUM>-<NUM> are configured as either Category A, Category B, or CPE. The EPC cloud <NUM> provides functionality including LTE EPC operation support system (OSS) functionality, analytics such as traffic analytics used to determine latencies, and the like.

The spectrum controller cloud <NUM> also includes a policy control and rules function (PCRF) <NUM> that creates policy rules and makes policy decisions for network subscribers in real-time. The PCRF <NUM> supports service data flow detection, policy enforcement, and flow-based charging. Some embodiments of the PCRF <NUM> determine the policy and charging records for SAS service to the CBRS RAN providers who sign up to receive the SAS service. Policies created or accessed by the PCRF <NUM> for network subscribers are stored in a corresponding database <NUM> in records associated with the different subscribers.

<FIG> is a block diagram of communication system <NUM> including interfaces between CBSDs and an SAS instance <NUM> according to some embodiments. The SAS instance <NUM> is used to implement some embodiments of the SAS instance <NUM> shown in <FIG>, the SAS instance <NUM>, <NUM> shown in <FIG>, and the instances of the SAS instance <NUM> shown in <FIG>. The SAS instance <NUM> includes ports <NUM>, <NUM>, <NUM>, <NUM>, <NUM> (collectively referred to herein as "the ports <NUM>-<NUM>") that provide access to the SAS instance <NUM>.

An interface <NUM> supports communication between the SAS instance <NUM> and CBSDs <NUM>, <NUM> via a network such as the Internet <NUM> and the ports <NUM>, <NUM>. The CBSD <NUM> is connected directly to the SAS instance <NUM> via the interface <NUM>. The CBSD <NUM> is connected to the SAS instance <NUM> via a domain proxy <NUM> that is connected to the SAS instance <NUM> by the interface <NUM>. The domain proxy <NUM> corresponds to some embodiments of the domain proxy <NUM> shown in <FIG>, the domain proxy <NUM> shown in <FIG>, and the instances of the domain proxy <NUM> shown in <FIG>. An interface <NUM> supports communication between the SAS instance <NUM> and one or more other SAS instances <NUM> (only one shown in <FIG> in the interest of clarity) via a network such as the Internet <NUM> and the port <NUM>. The SAS instance <NUM> can be owned and operated by other providers. An interface <NUM> supports communication between the SAS instance <NUM> and one or more other networks <NUM> (only one shown in <FIG> in the interest of clarity) via the port <NUM>. An interface <NUM> supports communication between the SAS instance <NUM> and an ESC cloud <NUM> that provides ESC services to the SAS instance <NUM>, e.g., within a DPA associated with the SAS instance <NUM>.

<FIG> is a map <NUM> of the borders of the United States that illustrates a set of DPAs defined at different geographic locations within the United States according to some embodiments. The DPAs <NUM> (only one indicated by a reference numeral in the interest of clarity) are typically, but not necessarily, defined near coastal regions to protect incumbents such as Navy ships. A DPA <NUM> can only be deactivated by an operational ESC sensor and consequently any communication system that uses the CBRS spectrum must include an ESC sensor, such as the ESC sensor <NUM>, to have full access to the CBRS spectrum. Each ESC sensor <NUM> is also required to maintain an exchange of heartbeat messages with the ESC cloud that in turn connects with one or more SAS instances to verify that the ESC sensors <NUM> within the DPA <NUM> are operational. If there are no operational ESC sensors deployed within a DPA, FCC rules require that the DPA must be activated throughout the entire <NUM> CBRS spectrum. Moreover, no outdoor CBSDs (Category B) can be deployed in a DPA <NUM> without an ESC sensor <NUM> in the DPA <NUM>.

<FIG> is a block diagram of a communication system <NUM> that includes an uninstalled CBSD <NUM> that is to be installed in a DPA <NUM> according to some embodiments. The communication system <NUM> represents some embodiments of the communication system <NUM> shown in <FIG>. The communication system <NUM> also includes other, previously installed CBSDs <NUM>, <NUM> located within the DPA <NUM>.

Initially, the CBSD <NUM> is not installed for operation within the DPA <NUM>, as indicated by the CBSD <NUM> being located outside of the DPA <NUM>. A technician <NUM> such as a verified CPI is tasked with installing the CBSD <NUM>. The technician <NUM> installs the previously uninstalled CBSD <NUM> at a location within the DPA <NUM>, as indicated by the arrow <NUM>. The uninstalled CBSD <NUM> and the installed CBSD <NUM> are given different reference numerals in <FIG> to indicate their different installation statuses but it should be appreciated that substantially the same physical apparatus is indicated by the uninstalled CBSD <NUM> and the installed CBSD <NUM>. After installation, the technician <NUM> provides information indicating the installation parameters of the installed CBSD <NUM>. The installation parameters include, but are not limited to, a latitude and a longitude indicating a location of the installed CBSD <NUM>, a height of the installed CBSD <NUM>, a horizontal accuracy, a vertical accuracy, an effective isotropic radiated power (EIRP) capability (dBm/<NUM>), an antenna azimuth, an antenna down tilt, an antenna gain, an antenna beamwidth, an antenna model, and the like.

The CBSD <NUM> transmits a registration request <NUM> to an SAS <NUM> that coordinates operation of CBSDs including the CBSDs <NUM>, <NUM>, e.g., by granting access, allocating frequency bands, determining transmission powers, and the like. The registration request <NUM> includes information indicating a request for a grant of access to utilize the shared spectrum on a channel and at a power determined by the SAS <NUM>. The SAS <NUM> determines whether the CBSD <NUM> is being deployed within the DPA <NUM> based on latitude and longitude information for the CBSD <NUM>. In response to registration of the CBSD <NUM>, the SAS <NUM> can, in some circumstances, issue a provisional suspended grant that allocates a channel to the CBSD <NUM> but does not authorize the CBSD <NUM> to begin communication operations including transmission of signals over the channel. In that case, the SAS <NUM> does not authorize the CBSD <NUM> to perform communications until a subsequent CPAS computation has been performed by the SAS <NUM> to determine the aggregate interference level to incumbents. In some embodiments, the CPAS computation is performed based on information exchanged between the SAS <NUM> and one or more other SAS instances <NUM> over corresponding interfaces <NUM>. The CPAS computation determines interference caused by CBSDs <NUM>, <NUM>, <NUM> that are deployed within the DPA <NUM> and managed by the SAS <NUM> or one or more other SAS instances <NUM>. In response to completing the CPAS computation, the suspended grant is converted to a valid grant with an assigned power level that is used by the CBSD <NUM> to bring up the cellular carrier on the assigned channel.

However, as discussed herein, the delay between installation of the CBSD <NUM> by the technician <NUM> and the subsequent CPAS computation potentially requires a second site visit by the technician <NUM>. Thus, instead of immediately issuing a suspended grant, the SAS <NUM> responds to the registration request <NUM> with a temporary low power shorter time duration test grant <NUM> that authorizes the CBSD <NUM> for transmission on a channel at the lower power for the shorter time duration. In some embodiments, the technician <NUM> requests the test grant <NUM> for the CBSD <NUM> by causing the CBSD <NUM> to transmit a request or by communicating with the CBSD <NUM> via another interface such as a web-based tool.

Some embodiments of the SAS <NUM> determine whether to grant the request for the test grant <NUM> based on an estimate of the interference produced by the previously installed CBSDs <NUM>, <NUM> and the newly installed CBSD <NUM>. In some embodiments, the SAS <NUM> determines or accesses an aggregate interference level that was previously computed for the CBSDs <NUM>, <NUM> and any other CBSDs that are under the control of the SAS <NUM> to protect the incumbent. The SAS <NUM> then determines the additional interference contribution by the newly installed CBSD <NUM> using a power level and a path loss calculated for the deployed CBSD based on the installation parameters provided by the technician <NUM>. The SAS <NUM> combines the previously calculated aggregate interference with the additional interference contribution to determine an updated aggregate interference. If the updated aggregate interference value remains below a threshold that is required to protect the incumbent, the SAS <NUM> issues the test grant <NUM> to the CBSD <NUM> with the power level. Some embodiments of the SAS <NUM> are allocated a fraction of a 1dB margin (distributed equally among all SAS admins) that is available when calculating interference during CPAS. The SAS <NUM> therefore determines whether to issue a test grant before CPAS based in part on the fraction of the 1dB margin.

The test grant <NUM> remains valid for a duration that is an order of magnitude (or more) lower than the duration of a conventional valid grant issued by the SAS <NUM>. For example, the duration of a conventional valid grant is typically <NUM> hours and the duration of the test grant is <NUM> minutes or <NUM> minutes in some embodiments. The duration of the test grant <NUM> provides sufficient time to allow the CPI to perform the on-the-air testing of CBSD <NUM> to ensure that user equipment camp on the cellular carrier transmitted by the CBSD <NUM> and receive signals from the CBSD <NUM>.

Some embodiments of the SAS <NUM> provide additional test grants to extend the duration of the testing time interval available to the technician <NUM>. For example, if the technician <NUM> fails to complete the on-the-air testing of the CBSD <NUM> within the validity period of the test grant <NUM>, e.g., after expiration of the test grant <NUM>, the CBSD <NUM> asynchronously transmits a refresh request to the SAS <NUM> to issue another test grant. This process can be iterated a predetermined number of times before the SAS <NUM> determines that the testing process has failed and does not issue any further test grants. Once the technician <NUM> completes the installation process, the CBSD state is changed to "Installed" and the SAS <NUM> converts the test grant to a suspended grant, which is in turn converted to a valid grant in response to subsequent performance of a CPAS procedure. The technician <NUM> is therefore able to complete the installation of the CBSD <NUM> within the DPA <NUM> in a single site visit instead of returning the next day to complete the on-the-air testing after the subsequent CPAS computation has been performed.

<FIG> is a flow diagram of a method <NUM> of determining whether to issue a test grant to a newly installed CBSD according to some embodiments. The method <NUM> is implemented in some embodiments of the SAS <NUM>, <NUM> shown in <FIG>, the primary SAS <NUM> shown in <FIG>, the SAS <NUM> shown in <FIG>, the SAS <NUM> shown in <FIG>, and the SAS <NUM>, <NUM> shown in <FIG>. Installation of the CBSD is performed by a technician such as a CPI. In some embodiments, a set of technicians are associated with the CPI master account that manages accounts for the other technicians. The technicians are granted certificates in response to passing an associated certification course. In some cases, the certificates include (or are associated with) private keys that are used to verify data signed by the technicians, e.g., using a corresponding public key.

At block <NUM>, a technician installs a CBSD in a DPA. For example, the technician can install the CBSD as discussed herein in <FIG>. In response to being installed, the CBSD transmits (at block <NUM>) a registration message to an associated SAS. The registration message includes, or is associated with, a request for a test grant that allows the technician to test and verify operation of the newly installed CBSD.

At block <NUM>, the SAS estimates an aggregate interference for the newly installed CBSD in combination with any previously installed CBSDs. As discussed herein, the aggregate interference is estimated by combining a previous estimate of the aggregate interference (e.g., as determined during the previous CPAS) with an interference level determined for the newly installed CBSD. The SAS determines the 'safest" channel that supports the test grant at the lowest possible power allocation. For example, if the CBSD falls in an exclusion zone that contains a GWPZ, the SAS can temporarily use a "GWPZ coordinated flag set" setting and a lowest power allocation to enable a short duration test grant. In some embodiments, the SAS performs an on-demand CPAS for the newly installed CBSD to estimate aggregate interference to one or more nearby incumbents based on previously calculated interference from a subset of previously installed CBSDs and estimated interference from the newly installed CBSD.

At decision block <NUM>, the SAS compares the estimated aggregate interference to a threshold. If the estimated aggregate interference is less than or equal to the threshold, the method <NUM> flows to block <NUM> and the SAS issues the test grant for the predetermined duration, e.g., <NUM> minutes or <NUM> minutes. If the estimated aggregate interference is greater than the threshold, the method <NUM> flows to block <NUM> and the SAS declines to issue the test grant. Instead, the SAS issues a suspended grant at block <NUM>.

<FIG> is a flow diagram of a method <NUM> of testing and verifying operation of a newly installed CBSD during a time interval provided by a test grant according to some embodiments. The method <NUM> is implemented in some embodiments of the SAS <NUM>, <NUM> shown in <FIG>, the primary SAS <NUM> shown in <FIG>, the SAS <NUM> shown in <FIG>, the SAS <NUM> shown in <FIG>, and the SAS <NUM>, <NUM> shown in <FIG>.

At block <NUM>, a CBSD located in a DPA receives a test grant that indicates a transmission power, a channel grant, and a predetermined time interval that determines the duration of the test grant. At block <NUM>, a technician performs testing of the CBSD such as a walk-through check to verify that user equipment camp on the CBSD and receive data transmitted by the CBSD.

At decision block <NUM>, the SAS for the CBSD determines whether the test grant has expired. As long as the test grant has not expired, the technician can continue to perform testing and verification of the CBSD at block <NUM>. In response to the test grant expiring, the method <NUM> flows to the decision block <NUM>.

At decision block <NUM>, the SAS determines whether testing is complete. If so, the method <NUM> flows to block <NUM> and the test grant is converted to a suspended grant. If not, the method <NUM> flows to decision block <NUM>.

At decision block <NUM>, the SAS determines whether the technician has requested a new test grant. If so, and the SAS grants the request, the method <NUM> flows back to block <NUM>. Otherwise, the method <NUM> flows to block <NUM> and the test grant is converted to a suspended grant.

<FIG> is a block diagram illustrating data entry process <NUM> performed by a technician such as a CPI according to some embodiments. The data entry process <NUM> is performed by the technician while installing CBSDs.

The technician enters data at block <NUM>. In some embodiments, the data is entered via a web interface that is filled out by the technician while installing the CBSD. The technician then signs the data (at block <NUM>) using a private key that is provided to the technician in response to the technician being certified as an installer. The signature object is a binary file generated by a processing system used by the technician. The signed data is then provided to an SAS, which can process and store the signed data.

If the data is for a single CBSD, the data entry process <NUM> flows to block <NUM> and the technician pastes the encoded data into an appropriate form for provision to the SAS, which performs data verification at block <NUM>. For example, the SAS can use a public key corresponding to the private key assigned to the technician to verify the signed data. Alternatively, the encoded data file for the single CBSD is uploaded (at block <NUM>) to the SAS, which performs (at block <NUM>) data verification, e.g., using a public corresponding to the private key assigned to the technician.

If the data is for multiple CBSDs, the data entry process <NUM> flows to block <NUM>. A file including the encoded data for the multiple CBSDs is then uploaded and ingested by the SAS at block <NUM>. For example, the SAS can translate an Excel file including the encoded data into a corresponding internal database. The SAS then performs (at block <NUM>) data verification, e.g., using a public corresponding to the private key assigned to the technician.

<FIG> is a flow diagram of a method <NUM> of data verification performed by a technician such as a CPI according to some embodiments. The method <NUM> is performed by an SAS in response to a technician installing one or more CBSDs. The method <NUM> is implemented in some embodiments of the SAS <NUM>, <NUM> shown in <FIG>, the primary SAS <NUM> shown in <FIG>, the SAS <NUM> shown in <FIG>, the SAS <NUM> shown in <FIG>, and the SAS <NUM>, <NUM> shown in <FIG>.

At block <NUM>, the SAS begins verifying data provided by a technician, e.g., as discussed above with regard to the data entry process <NUM> shown in <FIG>. At block <NUM>, the SAS decode the data received from the technician via an appropriate interface. At block <NUM>, the SAS verifies the data using a public key that is associated with a private key that the technician uses to sign the provided data. At decision block <NUM>, the SAS determines whether the verification is successful. If not, the method <NUM> flows to block <NUM> and an error message is generated. If the verification is successful, the method <NUM> flows to block <NUM>.

At block <NUM>, the SAS displays the parsed and verified data that was received from the technician in response to installing the one or more CBSDs. At block <NUM>, the SAS saves the information received from the technician in a database. At block <NUM>, the SAS authorizes the technician to begin installation testing of the one or more CBSDs in response to successfully verifying and storing the received information.

<FIG> is a flow diagram of a method <NUM> of testing and verification of the CBSD performed by a technician such as a CPI according to some embodiments. The method <NUM> is performed by an SAS and a technician in response to installing one or more CBSDs and in response to the SAS verifying CBSD data provided by the technician. The method <NUM> is implemented in some embodiments of the SAS <NUM>, <NUM> shown in <FIG>, the primary SAS <NUM> shown in <FIG>, the SAS <NUM> shown in <FIG>, the SAS <NUM> shown in <FIG>, and the SAS <NUM>, <NUM> shown in <FIG>.

At decision block <NUM>, the SAS provide instructions to the technician to turn on the CBSD. The technician then determines whether the CBSD entered the power down state. If not, the SAS generates an error at block <NUM>. If the CBSD successfully powered up, the method <NUM> flows to decision block <NUM>.

At decision block <NUM>, the SAS instructs the technician to determine whether the CBSD successfully registered with the system. If not, the SAS generates an error at block <NUM>. If the CBSD successfully registered, the method <NUM> flows to decision block <NUM>.

At decision block <NUM>, the SAS instructs the technician to determine whether the CBSD received a grant from the SAS. If not, the SAS generates an error at block <NUM>. If the CBSD successfully received a grant, the method <NUM> flows to decision block <NUM>.

At decision block <NUM>, the SAS instructs the technician to determine whether the CBSD received a grant that authorizes the CBSD to transmit signals on an allocated channel at an allocated transmission power. As discussed herein, the grant authorizing the CBSD to transmit can be a test grant that authorizes transmission for a limited time interval. If the CBSD did not receive the authorization grant, the method <NUM> generates an error at block <NUM>. If the CBSD receives a grant that authorizes the CBSD to transmit, the method <NUM> flows to decision block <NUM>.

At decision block <NUM>, the SAS instructs the technician to perform a walk-through check to verify that user equipment camp on the CBSD and the user equipment are able to receive data transmitted by the CBSD. As discussed herein, performing the walk-through check requires that the CBSD is authorized to transmit on the allocated channel, e.g., by receiving a test grant. If the technician determined that user equipment do not camp on, or receive data transmitted by, the CBSD, the SAS generates an error at block <NUM>. If the user equipment camps on the CBSD and receives data transmitted by the CBSD, the CBSD has passed the testing and verification phase. In response to passing, the method <NUM> flows to block <NUM> and the method <NUM> ends.

Claim 1:
A spectrum access system, SAS, (<NUM>) comprising:
a transceiver configured to receive a registration request from a first base station (<NUM>) in response to the first base station being installed in a dynamic protection area, DPA (<NUM>); and
a processor configured to allocate a channel in a shared spectrum and a transmission power to the first base station (<NUM>),
wherein the SAS is configured to estimate an updated aggregate interference
level within the DPA (<NUM>) by combining an aggregate interference level that was computed for at least one second base station (<NUM>) during a previous Coordinated Periodic Activities Among SASs, CPAS, with an interference level estimated for the first base station (<NUM>) based on the transmission power and a path loss associated with the first base station (<NUM>),
wherein the transceiver is configured to, in response to the updated aggregate interference level being less than a threshold value, transmit a test grant authorizing the first base station (<NUM>) to transmit on the channel at the transmission power for a predetermined time interval, and
wherein the test grant is converted to a suspended grant following the predetermined time interval, wherein the suspended grant is an unauthorized grant.