WO2025264896A1 - Groupe monofréquence dynamique pour cbsds - Google Patents

Groupe monofréquence dynamique pour cbsds

Info

Publication number
WO2025264896A1
WO2025264896A1 PCT/US2025/034324 US2025034324W WO2025264896A1 WO 2025264896 A1 WO2025264896 A1 WO 2025264896A1 US 2025034324 W US2025034324 W US 2025034324W WO 2025264896 A1 WO2025264896 A1 WO 2025264896A1
Authority
WO
WIPO (PCT)
Prior art keywords
cbsd
cbsds
controller
operator
sfg
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/US2025/034324
Other languages
English (en)
Inventor
Rangsan Leelahakriengkrai
Abhilash Dev
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mavenir Systems Inc
Original Assignee
Mavenir Systems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mavenir Systems Inc filed Critical Mavenir Systems Inc
Publication of WO2025264896A1 publication Critical patent/WO2025264896A1/fr
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W16/00—Network planning, e.g. coverage or traffic planning tools; Network deployment, e.g. resource partitioning or cells structures
    • H04W16/14—Spectrum sharing arrangements between different networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0231—Traffic management, e.g. flow control or congestion control based on communication conditions
    • H04W28/0236—Traffic management, e.g. flow control or congestion control based on communication conditions radio quality, e.g. interference, losses or delay
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/54—Allocation or scheduling criteria for wireless resources based on quality criteria
    • H04W72/541—Allocation or scheduling criteria for wireless resources based on quality criteria using the level of interference
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/12—Access point controller devices

Definitions

  • CBRS Code Division Multiple Access Network
  • CBRS is designed to support a wide range of applications, e.g., broadband access, Internet of Things (IoT) devices, and private wireless networks.
  • SAS Spectrum Access System
  • CBSDs CBRS devices
  • DP Domain Proxy
  • FIG. 1 illustrates the CBRS architecture
  • the CBRS devices (CBSDs) 103 and Domain Proxy (DP) 102 have an interface (referenced as “WinnForum SAS-CBSD/DP Interface” in FIG.1) with the SAS 101 for this function.
  • the interface is defined by WinnForum standard.
  • Base Station (BS) is the RAN implementation that manages RAN protocol and operations facilitating communication between mobile devices and the network's core infrastructure.
  • the DP is a logical entity engaging in communications with the SAS on behalf of multiple individual CBSDs or networks of CBSDs.
  • the DP can also provide a translational capability to interface legacy radio equipment in the 3650-3700 MHz band with a SAS to ensure compliance with the regulations specified in Title 47 of the Code of Federal Regulations (CFR), ⁇ 96 (hereinafter referred to as 47 CFR ⁇ 96).
  • CFR Code of Federal Regulations
  • ⁇ 96 hereinafter referred to as 47 CFR ⁇ 96.
  • the DP presents a consistent and secure interface to the SAS that can convey all messages pertaining to the SAS-CBSD interface for client CBSDs.
  • CBSD aggregation and proxy function for large networks can be integrated within a Service Management and Orchestration (SMO) system or in a standalone node.
  • SMO Service Management and Orchestration
  • SAS 101 is a system that authorizes and manages use of spectrum for the CBRS in accordance with the regulations specified in 47 CFR ⁇ 96.
  • the CBSD acquires Grants from the SAS, it can use LTE, NR or any wireless protocol to communicate with its UE.
  • LTE CBRS is the CBRS system that uses LTE as the wireless protocol
  • NR CBRS is the CBRS system that uses NR as the wireless protocol.
  • a CBSD is part of the BS mapped to the radio unit (RU) and operates within the CBRS band, and the CBSD is further responsible for accessing, managing, and utilizing the spectrum resources.
  • the CBRS spectrum is divided into three tiers: 1) Incumbent Access; 2) Priority Access License (PAL); and 3) General Authorized Access (GAA).
  • Incumbent Access tier is reserved for the existing government and military users in the 3.5 GHz band.
  • Priority Access License (PAL) tier which is designed for commercial users who have obtained a license for the frequency band, is used for large-scale wireless networks and high-speed broadband.
  • General Authorized Access (GAA) tier which is available for unlicensed users who can access the frequency band on a non- interference basis, is designed for small-scale wireless networks and IoT devices.
  • FIG. 2 shows an example Grant State Machine for CBRS.
  • Each Grant represented by a GrantId, has its own state machine.
  • the Grant State Machine is in the Idle state 201 if a Grant has not been approved by the SAS.
  • a CBSD can send the SAS a GrantRequest object. If a Grant request is approved by the SAS, the SAS will send a GrantResponse object.
  • the Grant State Machine transitions to Granted state 202.
  • Granted state a GrantId is assigned, operational parameters are defined, and a channel is allocated.
  • RF radio frequency
  • the SAS approves a Heartbeat Request
  • the SAS sends a HeartBeatResponse object authorizing the transmission.
  • the Grant State Machine transitions to the Authorized state 203.
  • the CBSD is permitted to commence RF transmission and operate in the CBRS band using the operational parameters specific to that Grant. If a CBSD receives multiple Grants, individual state machines are kept for each Grant, and individual heartbeat requests need to be sent for each Grant, possibly aggregated in a single transmission to the SAS.
  • FIG. 3 is a signal-flow diagram illustrating an example CBRS procedure.
  • the CBSD 103 e.g., O-RU
  • it will register with the SAS 101 by sending a RegistrationRequest object, as shown by 301a.
  • the RegistrationRequest object includes operational parameters of the CBSD (e.g., O-RU), including identity of the CBSD and its physical location (latitude, longitude, altitude).
  • the SAS 101 will accept the registration by sending a RegistrationResponse object, as shown by 301b.
  • the CBSD 103 performs the Spectrum Inquiry procedure, as shown by 302a and 302b.
  • the CBSD 103 sends the SpectrumInquiry object to the SAS 101 (as shown by 302a) with a list of channels of interest.
  • the SpectrumInquiryResponse sent by the SAS 101 includes all available channels in the transmission area, which transmission area is defined based on the physical location of the CBSD. [0009] Continuing with the signal-flow diagram of FIG. 3, based on the available channels, the CBSD now chooses one or more channels (as shown by 303) and requests a Grant via the Grant Request procedure, which involves sending a Grant Request 304a and receiving a Grant Response 304b. If the request is Granted by the SAS 101, after the reception of the GrantResponse 304b, the CBSD 103 starts a first Heartbeat procedure, which involves sending a first Heartbeat Request 305a to the SAS 101 and receiving a first Heartbeat Response 305b from the SAS 101.
  • the GrantResponse 304b will also include the maximum power that the CBSD (e.g., O-RU) can transmit, which limits possible interference in the CBRS band.
  • the CBSD 103 e.g., O-RU
  • the CBSD 103 keeps sending HeartbeatRequest object periodically to the SAS 101, as exemplified by a subsequent Heartbeat Request 306a (to which the SAS 101 sends a subsequent Heartbeat Response 306b), as a form of “keep alive” mechanism.
  • a Domain Proxy is the entity that can handle the above-described CBRS procedures with the SAS 101 on behalf of the CBSDs 103.
  • the basic functionality of the DP is to be a “proxy” for the CBSD 103 (accordingly, the exchange of information with the SAS 101 in FIG.
  • the DP can be handled by the DP, instead of the CBSD 103). Part of this includes the aggregation of the information coming from/to several CBSDs to/from the SAS. This reduces the number of messages and the number of connections that need to be established between the SAS 101 and the CBSDs 103. Additionally, this helps by offloading the CBRS functionality from the O-RU (i.e., CBSD 103) to the DP. As an example, the O-RU (i.e., CBSD 103) does not need to keep sending periodic HeartbeatRequest objects to the SAS 101, since the DP will handle that procedure on behalf of the O-RU. Accordingly, the CBSD 103 shown in FIG.3 should be interpreted as also encompassing a DP for the information exchange with the SAS 101.
  • the O-RU i.e., CBSD 103
  • Conventional RANs were built employing an integrated unit where the entire RAN was processed.
  • Conventional RANs implement the protocol stack (e.g., Physical Layer (PHY), Media Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Control (PDCP) layers) at the base station (also referred to as the evolved node B (eNodeB or eNB) for 4G LTE, or next generation node B (gNodeB or gNB) for 5G NR).
  • PHY Physical Layer
  • MAC Media Access Control
  • RLC Radio Link Control
  • PDCP Packet Data Convergence Control
  • eNodeB evolved node B
  • gNodeB or gNB next generation node B
  • 5G NR next generation node B
  • conventional RANs use application-specific hardware for processing, which makes the conventional RANs difficult to upgrade and evolve.
  • Cloud-based Radio Access Networks are networks where a significant portion of the RAN layer processing is performed at a baseband unit (BBU) located in the cloud on commercial off-the-shelf servers, while the radio frequency (RF) interface and real-time critical functions can be processed in the remote radio unit (RRU), also referred to as the radio unit (RU).
  • BBU baseband unit
  • RF radio frequency
  • RRU remote radio unit
  • the BBU can be split into two parts: centralized unit (CU) and distributed unit (DU).
  • the CUs are usually located in the cloud on commercial off the shelf servers, while DUs can be distributed.
  • the BBU may also be virtualized, in which case it is also known as vBBU.
  • the O-RAN architecture is a Cloud-based architecture specified by the O-RAN Alliance.
  • the logical architecture of the O-RAN system is specified in [O-RAN.WG1.O-RAN- Architecture-Description-v010.00] and depicted in FIG.4.
  • the components of the architecture include the Service Management and Orchestrator (SMO) Framework 401, the Non-Real Time (Non-RT) Radio Intelligent Controller (RIC) 402, the Near-Real Time (Near-RT) Radio Intelligent Controller (RIC) 407, the O-RAN Centralized Unit Control Plane (O-CU-CP) 409, the O-RAN Centralized Unit User Plane (O-CU-UP) 411, the O-RAN Distributed Unit (O-DU) 415, and the O-RAN Radio Unit (O-RU) 418.
  • SMO Service Management and Orchestrator
  • RIC Non-Real Time
  • RIC Near-Real Time
  • RIC Radio Intelligent Controller
  • the Service Management and Orchestrator (SMO) Framework 401 is responsible for the management of the O-RAN components (O-CU-CP, O-CU-UP, O-DU and O-RU for 5G, and O- eNB for 4G).
  • the SMO Framework 401 uses the O2 interface 403 to connect with the O-Cloud 419.
  • the management interface between the SMO Framework 401 and the O-RAN components is the O1 interface 404 to O-eNB and O1 interface 406 to 5G components.
  • the RAN Intelligent Controller (RIC) contains Radio Resource Management (RRM) functions that help control and optimize the components and the utilization of radio resources. It is divided into Non-RT RIC 402 and Near-RT RIC 407.
  • RRM Radio Resource Management
  • the Non-RT RIC 402 is the functionality internal to the SMO 401. Its primary goal is to support intelligent RAN optimization, e.g., by providing policy-based guidance, Machine Learning (ML) model management, and enrichment information to the Near-RT RIC function, supporting Radio Resource Management (RRM) optimizations of the Near-RT RIC.
  • the Non-RT RIC 402 can also perform intelligent RRM functions in non-real-time fashion (i.e., greater than 1 second).
  • the Non-RT RIC 402 communicates with the Near-RT RIC 407 via the A1 interface 405.
  • the Near-RT RIC 407 is a logical function that enables near real-time control and optimization of radio components and resources via fine-grained data collection and actions over the E2 interface.
  • the Near-RT RIC 407 control loop operates in the order of 10 milliseconds (10ms) to 1 second (1s).
  • the Near-RT RIC 407 hosts one or more applications that use E2 interface 408 to collect near real-time information (e.g., on a UE-basis or a cell-basis) and provide value added services.
  • the control over the radio components by the Near-RT RIC 407 is steered via the policies and the enrichment data provided via A1 interface 405 from the Non-RT RIC 402. [0017]
  • the data between the O-CU-CP 409 and O-CU-UP 411 is carried over the 3GPP interface E1410.
  • the data between O-CU-CP 409 and O-DU 415 is carried over the 3GPP interface F1-c 413, and data between O-CU-UP 411 and O-DU 415 is carried over the F1-u interface 414.
  • the O-DU 415 is responsible for scheduling the data transmission over the air, and the O-DU scheduler runs a control loop in the order of milliseconds ( ⁇ 10ms).
  • the data between O-DU 415 and O-RU 418 is sent over the open fronthaul Control-User-Synchronization-Plane (Open FH CUS-Plane) 416 and open fronthaul Management-Plane (Open FH M-Plane) interface 417.
  • the data between SMO 401 and O-RU 418 is sent over Open FH M-Plane interface 412.
  • Other 3GPP interfaces (collectively referenced as 420 in FIG.4) are also included, e.g., X2-c, X2-u, Xn-c, and Xn-u, which interfaces carry data between O-CU-CP/O-CU-UP to other O-CU- CP/O-CU-UP, as well as NG-u interface to carry data to the 5G Core.
  • the Near-RT RIC decisions are based on its internal functions or applications, the configuration received over the O1 interface, and the temporary policies received over A1405 from the Non-RT RIC 402.
  • FIG. 5 illustrates the SMO and Non-RT RIC Framework Services.
  • the Non-RT RIC 402 has an interface A1508 to the Near-RT RIC (not shown). Being part of the SMO Framework 401, the Non-RT RIC 402 may also indirectly utilize the O1 506, O2505 and Open FH M-Plane 507 interfaces.
  • the Non-RT RIC Framework 504 and the rApps 501 are provided within the Non-RT RIC 402 domain.
  • Non-RT RIC Framework 504 functions and services include providing policy-based guidance and enrichment information to the Near-RT RIC, data analytics, AI/ML training, inference for RAN optimization, and recommendations for configuration management actions over O1 interface.
  • the rApps 501 are modular applications that leverage the functionality exposed by the Non-RT RIC 402 to provide value-added services relative to intelligent RAN optimization and operation.
  • the Non-RT RIC framework 504 functions provide services to rApps via the R1 interface 502 (which services are labeled “services that enable rApps 503” in FIG.5).
  • the R1 interface is an Open API interface and provides a level of abstraction such that an rApp that is a producer of data (“producer rApp”) does not need to know whether there exists one or multiple consumers for that data, or the nature of that consumer. In other words, the “producer rApp” does not need to know if the consumer of the data is a “consumer rApp” or is an entity external to the Non-RT RIC 402 or SMO Framework 401.
  • the R1 interface 502 provides functionality such that a “consumer rApp” does not need to know if the data consumed is the product of a single entity (e.g., a single “producer rApp”), or the combined output of a complex chain of entities (e.g., a chain of rApps each consuming the value-added product of another).
  • a CBSD is a radiation point, so it is mapped to the O- RU. From the perspective of the O-RAN, it is not practical to have the O-RU communicate directly to the SAS, as the O-RU is designed to be a low-cost component.
  • a CBSD Controller 601 implements the DP functionality, where the DP is a proxy for CBSD and interfaces (as referenced by 603) with the SAS 604.
  • the CBSD Controller 601 can be a rApp in the non-RT RIC 402 and communicates with the Cloud Management System (CMS) 602 which is a part of the SMO Framework 401 for the configuration of the RAN components.
  • CMS Cloud Management System
  • CMS 602 manages O-RAN components including O-RU/CBSD, i.e., CMS 602 also acts as a proxy for the CBSD Controller 601 to control O-RU/CBSD so that the CBSD Controller does not need to communicate to the O- RU/CBSD directly, and hence, re-use the same functionality for non-CBRS/generic O-RAN. This helps to simplify and reduce the cost of the CBRS in O-RAN deployments.
  • a CBSD Controller 701 can be provided in the SMO Framework 401, such that the CBSD Controller 701 can communicate directly with the CMS 702.
  • FIG.7 which illustrates yet another example alternative architecture of CBRS in O- RAN, a CBSD Controller 801 can be provided as part of the CMS 802.
  • the remaining portions of the architecture shown in FIG.8 are substantially the same as those shown in FIGS.6 and 7, i.e., SMO Framework 401; Non-RT RIC 402; SAS 804 interfacing (as shown by 803) the CBSD Controller 801; rApps 501; R1 interface 502; services that enable rApps 503; and Non-RT RIC framework 504.
  • SMO Framework 401 SMO Framework 401
  • Non-RT RIC 402 Non-RT RIC 402
  • SAS 804 interfacing as shown by 803 the CBSD Controller 801; rApps 501; R1 interface 502; services that enable rApps 503; and Non-RT RIC framework 504.
  • the CBRS users (operators) can request the same frequency grant from the SAS, thereby causing interference to each other.
  • the SAS administrators ensure that Incumbent and PAL users are protected so that there is minimal interference to
  • FIG. 9 illustrates an example scenario in which a CBRS operator A 911 experiences interference from three other CBRS operators (which can be Incumbent, PAL, or GAA operators).
  • the operator A 911 which is a CBRS GAA operator, deploys CBSDs A1901, A2 902, A3903, and A4904.
  • CBSDs B1910, C1920, and D1930 are also shown, which operators and the deployed CBSDs create interference for the CBRS operator A 911.
  • the line between CBSDs of different operators indicate potential interference (if they operate on the same channel) due to the radio path between the CBSDs being lower than a certain threshold. That is, CBSD B1910 could create interference 941 to CBSD A1901 if both CBSDs are using the same channel.
  • CBSD C1920 could create interference 942 and 943 to CBSD A1901 and CBSD A2902, respectively.
  • CBSD D1 930 could create interference 944 to CBSD A3903.
  • the interference can render the CBRS unable to service its users (UEs). For example, if the received power at CBSD A1901 from the UE is -100 dBm/PRB and the combined received power from CBSD B1910 and C1920 is -80 dBm/PRB, then the signal-to-noise-ratio (SINR) is -20 dB/PRB. This condition is not sufficient to support operation in a 4G or 5G wireless system. This is also due to the fact that the UE’s transmit power is usually much less than the one used at the CBSD.
  • SINR signal-to-noise-ratio
  • Another requirement is to use the same frequency in all CBSDs, i.e., deployed CBSDs A1 901, A2902, A3903, and A4904 operate on the same CBRS channel(s).
  • This has several benefits when using 4G LTE and 5G NR.
  • One of them is to avoid inter-frequency handover.
  • the serving base station (BS) eNB or gNB
  • BS serving base station
  • the serving BS sends the handover command to the UE to switch to that frequency. This measurement gap causes the UE to stop the service with the serving BS.
  • OnGo Alliance (OnGoA) standard, TS-2003 Collaborative GAA Coexistence Specification, serves as the framework for the GAA Users (wireless operators) to coexist with one another while causing minimum interference to each other. This requires the CBRS Users to report the excessive interference caused by other users, based on which reporting the SAS administrators provide a frequency allocation plan to minimize the interference among all CBRS Users in the GAA Coordination Area (GCA).
  • GAA GAA Coordination Area
  • the frequency allocation plan which is the only part that can be done through an algorithm such as Graph Coloring algorithm, is mostly based on RF channel model which could differ from the actual one in the field, particularly for CBSDs deployed indoor.
  • the TS-2003 nor the SAS administrators can force the CBRS Users to accept the frequency plan. If one of the CBRS Users in the GCA decides to opt out, then the SAS administrators will not enforce the frequency plan, which leads to the interference issue not being resolved. In this case, the individual CBRS User may still need an alternative plan to either avoid initiating the GAA Coexistence process or to mitigate the interference issue by the CBRS User itself.
  • a Single Frequency Group is dynamically configured for all or a subset of CBSDs while avoiding interference from other CBRS operators.
  • the Channel Selector requests, via CBSD Controller, spectrum (channel) availability from the SAS for each CBSD.
  • the CS requests each CBSD to measure interference from other CBSDs belonging to other operators on said spectrum availability and report to the CS.
  • the CS identifies the list of low-interference channels and selects common channels for all CBSD’s from the said list, up to the required minimum bandwidth, and reports to the CBSD Controller to acquire them from the SAS to form an SFG.
  • the following is additionally implemented: 4) If the CS cannot find common channels with low interference that satisfies the required minimum bandwidth, it splits the CBSDs into smaller multiple SFGs such that each SFG satisfies the above requirements. [0035] According to an example system and method of the present disclosure, at least one of the following is additionally implemented: 5) If the CS determines the interference landscape has changed, it modifies the number of SFGs by either combining some SFGs into one or splitting them further.
  • the CS goes through the procedure from requesting for Spectrum Inquiry, measurement report for some of existing and new CBSDs to determine the SFG for the new CBSD(s) and possible new SFG for existing CBSDs.
  • the operator removes existing CBSD(s) the CS goes through the procedure from requesting for Spectrum Inquiry, measurement report to determine the SFG for the remaining CBSDs for a chance to consolidate SFGs, if applicable, into a smaller number of SFGs.
  • the CBSD Controller measures the interference by one of the following: i) requesting CBSDs to measure its interference; ii) requesting CMS to be a proxy to request and forward the measured interference from CBSDs; or iii) requesting other node to be a proxy to request and forward the measured interference from CBSDs.
  • the CS in O-RAN architecture, can be implemented in SMO Framework in one of the following ways depending on the location of the CBSD controller: 1) in the case the CBSD Controller is in the Real-Time RIC (RT-RIC): a) the CS is in the CBSD Controller.
  • the CS is not in the CBSD Controller but in the RT-RIC.
  • the CS is in the SMO Framework and outside the CMS.
  • the CS is in the CMS.
  • the CBSD Controller is in the SMO Framework and outside the CMS: a) the CS is in the RT-RIC.
  • the CS is in the SMO Framework but not in either the CBSD Controller or the CMS.
  • the CS is in the CBSD Controller but not in the CMS.
  • the CS is not in the CBSD Controller but in the CMS.
  • the CBSD Controller in the CMS a) the CS is in the RT-RIC.
  • the CS is in the SMO Framework but not in either the CBSD Controller or the CMS.
  • the CS is in the CBSD Controller.
  • the CS is in the CMS but not in the CBSD Controller.
  • Coupled means a relationship between or among two or more devices, apparatus, files, programs, applications, media, components, networks, systems, subsystems, and/or means, constituting any one or more of (a) a connection, whether direct or through one or more other devices, apparatus, files, programs, applications, media, components, networks, systems, subsystems, or means, (b) a communications relationship, whether direct or through one or more other devices, apparatus, files, programs, applications, media, components, networks, systems, subsystems, or means, and/or (c) a functional relationship in which the operation of any one or more devices, apparatus, files, programs, applications, media, components, networks, systems, subsystems, or means depends, in whole or in part, on the operation of any one or more others thereof.
  • FIG. 1 is a block diagram illustrating the CBRS architecture.
  • FIG. 2 is a schematic diagram illustrating the CBRS Grant State Machine.
  • FIG. 3 illustrates an example CBRS procedure.
  • FIG. 4 illustrates the logical architecture of the O-RAN system.
  • FIG. 5 shows SMO and Non-RT RIC Framework Services.
  • FIG. 6 shows an example architecture of CBRS in O-RAN. [0049] FIG.
  • FIG. 7 shows an alternative example architecture of CBRS in O-RAN.
  • FIG. 8 shows yet another alternative example architecture of CBRS in O-RAN.
  • FIG. 9 illustrates an example scenario in which a CBRS operator experiences interference from three other CBRS operators.
  • FIG. 10 illustrates the message flow diagram of an example method according to the present disclosure.
  • FIG. 11 shows an example of interference reports from all CBSDs of operator A.
  • FIG. 12 shows another example of interference reports from all CBSDs of operator A.
  • FIG. 13 shows an example implementation of the CS as part of the CBSD Controller rApp.
  • FIG. 14 shows another example implementation of the CS as an individual rApp in the Non-RT RIC, similar to the CBSD Controller.
  • FIG. 15 shows another example implementation of the CS in the SMO Framework and outside the CMS.
  • FIG. 16 shows another example implementation of the CS in the CMS.
  • FIG. 17 shows another example implementation of the CS as an individual rApp in the Non-RT RIC.
  • FIG. 18 shows another example implementation of the CS in the SMO Framework.
  • FIG. 19 shows another example implementation of the CS inside the CBSD Controller in the SMO Framework.
  • FIG. 20 shows another example implementation of the CS inside the CMS and outside the CBSD Controller.
  • FIG. 21 shows another example implementation of the CS as an individual rApp where the CBSD Controller is a part of the CMS.
  • FIG. 22 shows another example implementation of the CS in SMO Framework where the CBSD Controller is a part of the CMS.
  • FIG. 23 shows another example implementation of the CS as part of the CBSD Controller, which in turn is a part of the CMS.
  • FIG. 24 shows another example implementation of the CS as part of the CMS and outside the CBSD Controller.
  • DETAILED DESCRIPTION [0067]
  • FIG. 10 illustrates the message flow diagram of an example method according to the present disclosure.
  • the Channel Selector (CS) 1001 sends CS Spectrum Inquiry Request 1004 the CBSD Controller 601 to send Spectrum Inquiry Request 1005 to the SAS 101.
  • CS Channel Selector
  • the SAS 101 responds with Spectrum Inquiry Response 1006 that contains spectrum availability, and the CBSD Controller 601 forwards Spectrum Inquiry Response to the CS 1001 (as shown by the process step 1007).
  • the CS 1001 sends the Measurement Request 1008 to the CBSD Controller 601 to request each CBSD to measure interference (as referenced by 1009) from other CBSDs belonging to other operators on said spectrum availability. If this is the first time the CBSDs have been activated (i.e., startup), then the CBSD Controller 601 can request each CBSD to measure the interference from other operators. This can be done through CMS. If the CBSDs have already been operational, see the procedure described below.
  • the CS creates a SFG by the procedure described in detail below.
  • the CS 1001 then sends the SFG Request 1012 to the CBSD Controller 601 to configure and send the Grant Request with SFG (as referenced by the process step 1013) to the SAS 101.
  • the SFG configuration in the Grant Request is per WinnForum standard, and it also depends on whether the SAS administrator supports the configuration. If it does not, it simply recognizes the requested frequency range in each CBSD as per WinnForum standard.
  • the CBSD Controller 601 and the SAS 101 exchange several messages based on WinnForum CBRS for channel authorization (as referenced by the process step 1014).
  • the CBSD Controller 601 configures SFG with the authorized channels to all CBSDs (as referenced by the process step 1015). This can be done by communicating with the CMS.
  • the CBSD Controller 601 confirms the configuration by sending SFG Response 1016 to the CS 1001.
  • the CS 1001 determines whether a given channel has high or low interference, i.e., i) if the interference power is less than a specified low interference threshold, lowIntfTh, then the channel is considered a low interference channel, and ii) if the interference power is higher than lowIntfTh, then the channel is considered a high interference channel.
  • FIG. 11 shows an example set of interference reports from the CBSDs of operator A 911 illustrated in FIG.9. Let’s assume that the SAS indicates in the Spectrum Inquiry Response that channels 1-7 have been used by PAL users (and hence these channels are marked as “P” in FIG.11). The remaining channels 8-15 are available for GAA users, and therefore the CBSDs report interference on channels 8-15.
  • the CS 1001 selects a single frequency that is common among all CBSDs (A1901 - A4904 shown in FIG.9) up to the required minimum bandwidth, e.g., 30 MHz or 3 channels. In such a case, the CS selects channels 8-10 for CBSDs (A1901 - A4904 shown in FIG.9). The CS 1001 then informs the CBSD Controller 601 (shown in FIG.10) to send the Grant Request to the SAS with channels 8-10.
  • the SAS 101 sends Grant Response and ii) both the CBSD Controller 601 and the SAS 101 have exchanged the first Heartbeat Request and Heartbeat response, the channels 8-10 shown in FIG.11 are authorized to be used.
  • the CS 1001 monitors the interference from the other operators (e.g., Operators B, C and D shown in FIG.9). The monitoring can be triggered periodically, based on specified events, or triggered manually by the operator. Once the monitoring is triggered, the CS 1001 requests all CBSDs of operator A to measure and report interference from other operators on the operating channels (channels 8-15 in the example above) and other channel availability (the CS could obtain a new Spectrum Inquiry Response from the SAS).
  • the CS 1001 can start from sending CS Spectrum Inquiry Request 1004 or start from sending Measurement Request 1008.
  • CBSDs A1901 – A4904 are transmitting on the same channels 8-15, the measurements could be tainted by their own CBSDs, i.e., CBSD A1901 will receive signal transmitted by CBSDs A2902 – A4904.
  • the operator A can optimize its network by keeping the inter-CBSD interference to the minimum, e.g., by implemented measures such as 1) interference measurement with coordinated blanking, or 2) utilizing UE measurements of neighbouring cells for optimal channel selection within CBRS network.
  • CBSDs A2902 – A4904 stop serving their UEs or implement blanking, and allow SBSD A1901 to measure the interference from CBSD B1910 and CBSD C1920. This procedure will rotate for all CBSDs A1-A4, i.e., CBSDs A1, A3 and A4 blank to allow CBSD A2902 to measure its interference, followed by CBSDs A1, A2 and A4 blanking, and so on.
  • CBSDs A1901 measures and reports interference to CBSD A1901.
  • This reports include inter-CBSD interferences, which will be ignored by the CS, and inter-operator interferences, e.g., due to CBSD B1910 and CBSD C1 920, which will be taken into consideration.
  • inter-CBSD interferences which will be ignored by the CS
  • inter-operator interferences e.g., due to CBSD B1910 and CBSD C1 920, which will be taken into consideration.
  • the CS determines that no significant change in interference conditions has occurred to the current operating frequency, then the CS does not change anything. However, if there is a change in interference conditions, e.g., as illustrated by the example set of interference reports shown in FIG.12 for the CBSDs of operator A, then the CS needs to act.
  • the change in the interference reports shown in FIG.12 is due to CBSD D1930 in FIG.9Error! Reference source not found. having changed its channels to 8-10.
  • the CS cannot select channels 8-10 for CBSD A3. In fact, there is no common channel suitable to be used for all CBSDs. In this example, the CS needs to split the CBSDs into two groups (e.g., SFG1 and SFG2), each with at least one common channel. [0074] To search for the new common channels, the operator can perform this task manually if the number of CBSDs are small and manageable. The operator can use a proprietary algorithm or use an Artificial Intelligence/Machine Learning engine that is available through the Non-Real Time RIC. The CS continues to monitor the interference conditions by requesting measurement reports from the CBSDs for a chance to combine the above-referenced SFG1 and SFG2 into a single group.
  • the CS can execute a search algorithm through the interference report to derive a single SFG.
  • the operator adds new CBSD(s)
  • the CS goes through the procedure from requesting for Spectrum Inquiry, requesting measurement report for some or all of the preexisting CBSDs and the new CBSD(s) to determine the SFG for the new CBSD(s) and possible new SFG for the preexisting CBSDs.
  • the CS can be implemented in the SMO Framework in different ways, depending on the location of the CBSD controller. Various options are summarized below: A) CBSD Controller is in the Real-Time RIC (RT RIC): i) CS is in the CBSD Controller (e.g., shown in FIG.13). ii) CS is not in the CBSD Controller, but in the RT RIC (e.g., shown in FIG.14).
  • RT RIC Real-Time RIC
  • iii) CS is in the SMO, but not in the CMS (e.g., shown in FIG.15).
  • iv) CS is in the CMS (e.g., shown in FIG.16).
  • B) CBSD Controller is in the SMO, but not in the CMS: i) CS is in the RT RIC (e.g., shown in FIG.17).
  • ii) CS is in the SMO, but not in either the CBSD Controller or the CMS (e.g., shown in FIG.18).
  • iii) CS is in the CBSD Controller, but not in the CMS (e.g., shown in FIG.19).
  • iv) CS is not in the CBSD Controller, but in the CMS (e.g., shown in FIG.20).
  • FIG. 13 is a block diagram illustrating an example embodiment in which the CS 1305 is implemented as an rApp in the CBSD Controller 1301.
  • FIG. 14 is a block diagram illustrating an example embodiment in which the CS 1405 is implemented as a rApp in the Non-RT RIC 1408, similar to the CBSD Controller 1401.
  • the CS 1405 communicates with the CBSD Controller 1401 via the R1 interface 1406.
  • FIG. 15 is a block diagram illustrating an example embodiment in which the CS 1505 is implemented in the SMO Framework 1507.
  • the CS 1505 communicates with the CBSD Controller 1501 via the R1 interface 1506.
  • FIG.15 are: SAS 1504; CMS 1502; interface 1503 linking SAS 1504 and CBSD Controller 1501; R1 interface 1506; Non-RT RIC 1508; Non-RT RIC Framework 504; and services that enable rApps 503.
  • FIG. 15 is a block diagram illustrating an example embodiment in which the CS 1505 is implemented in the SMO Framework 1507.
  • the CS 1505 communicates with the CBSD Controller 1501 via the R1 interface 1506.
  • FIG.15 are: SAS 1504; CMS 1502; interface 1503 linking SAS 1504 and CBSD Controller 1501; R1 interface 1506; Non-RT RIC 1508; Non-RT RIC Framework 504; and services that enable rApps 503.
  • FIG. 15 is a block diagram illustrating an example embodiment in which the CS 1505 is implemented
  • FIG. 16 is a block diagram illustrating an example embodiment in which the CS 1605 is implemented in the CMS 1602.
  • the CS 1605 communicates with the CBSD Controller 1601 via the CMS 1602 and the R1 interface 1606. Also shown in FIG.16 are: SAS 1604; interface 1603 linking SAS 1604 and CBSD Controller 1601; R1 interface 1606; Non-RT RIC 1608; Non-RT RIC Framework 504; and services that enable rApps 503.
  • FIG. 17 is a block diagram illustrating an example embodiment in which the CS 1705 is implemented as a rApp in the Non-RT RIC 1708, and the CBSD Controller 1701 is implemented in the SMO Framework 1707.
  • the CS 1705 communicates with the CBSD Controller 1701 via the R1 interface 1706.
  • FIG. 18 is a block diagram illustrating an example embodiment in which the CS 1805 is implemented in the SMO Framework 1807.
  • the CS 1805 communicates directly with the CBSD Controller 1801 as both are in the SMO Framework 1807.
  • FIG.18 are: SAS 1804; CMS 1802; interface 1803 linking SAS 1804 and CBSD Controller 1801; R1 interface 1806; Non-RT RIC 1808; Non-RT RIC Framework 504; and services that enable rApps 503.
  • FIG. 18 is a block diagram illustrating an example embodiment in which the CS 1805 is implemented in the SMO Framework 1807.
  • the CS 1805 communicates directly with the CBSD Controller 1801 as both are in the SMO Framework 1807.
  • FIG.18 are: SAS 1804; CMS 1802; interface 1803 linking SAS 1804 and CBSD Controller 1801; R1 interface 1806; Non-RT RIC 1808; Non-RT RIC Framework 504; and services that enable rApps 503.
  • FIG. 18 is a block diagram illustrating an example embodiment in
  • FIG. 19 is a block diagram illustrating an example embodiment in which the CS 1905 is implemented as part of (inside) the CBSD Controller 1901 (which, in turn, is implemented in the SMO Framework 1907). As the CS 1905 is part of the CBSD Controller 1901, the functionality and data from the CS 1905 can be called and retrieved by the CBSD Controller 1901 internally. Also shown in FIG.19 are: SAS 1904; CMS 1902; interface 1903 linking SAS 1904 and CBSD Controller 1901; R1 interface 1906; Non-RT RIC 1908; Non-RT RIC Framework 504; and services that enable rApps 503. [0085]
  • FIG. 20 is a block diagram illustrating an example embodiment in which the CS 2005 is implemented in the CMS 2002, but not in the CBSD Controller 2001.
  • FIG. 21 is a block diagram illustrating an example embodiment in which the CS 2105 is implemented as a rApp, and the CBSD Controller 2101 is a part of the CMS 2102.
  • the CS 2105 communicates with the CBSD Controller 2101 through the R1 interface 2106 and through the CMS 2102, as the CMS 2102 is a part of the SMO Framework 2107.
  • FIG. 22 is a block diagram illustrating an example embodiment in which the CS 2205 is implemented in the SMO Framework 2207, and the CBSD Controller 2201 is a part of the CMS 2202.
  • the CS 2205 communicates with the CBSD Controller 2201 via the CMS 2202, as both the CS 2205 and the CMS 2202 are in the SMO Framework 2207.
  • FIG. 23 is a block diagram illustrating an example embodiment in which the CS 2305 is implemented as part of the CBSD Controller 2301, which, in turn, is a part of the CMS 2302. Also shown in FIG.23 are: SMO Framework 2307; SAS 2304; interface 2303 linking SAS 2304 and CBSD Controller 2301; R1 interface 2306; Non-RT RIC 2308; Non-RT RIC Framework 504; and services that enable rApps 503. [0089] FIG.
  • FIG. 24 is a block diagram illustrating an example embodiment in which the CS 2405 is implemented in the CMS 2402, but not as a part of the CBSD Controller 2401. Also shown in FIG.24 are: SMO Framework 2407; SAS 2404; interface 2403 linking SAS 2404 and CBSD Controller 2401; R1 interface 2406; Non-RT RIC 2408; Non-RT RIC Framework 504; and services that enable rApps 503. [0090] The following are messages exchanged between the CS and the CBSD Controller if the CS is not a part of CBSD Controller: 1) CS Spectrum Inquiry Request; 2) CS Spectrum Inquiry Response; 3) Measurement Request; 4) Measurement Response; 5) SFG Request; and 6) SFG Response.
  • CS Spectrum Inquiry Request message This message, which is sent from the CS to the CBSD Controller, is for the CS to request the CBSD Controller to send Spectrum Inquiry Request to the SAS.
  • This message includes the Spectrum Inquiry Request defined in Wireless Innovation Forum Standard’s Interface Technical Specification WINNF-TS-016 and conditioned on the csSpectrumRequestAll parameter (which is used to reduce the messaging traffic load between the CS and the CBSD Controller) and the csSpectrumRequestShallRespond parameter (which is used to re-synchronize the CBSD database between the CS and the CBSD Controller), as explained below:
  • P arameter R/O/C Description NAME: csSpectrumRequestAll Required If the flag is true, the CBSD Controller shall DATA TYPE: Boolean send spectrum inquiry for all CBSDs.
  • a rray of SpectrumInquiryRequest objects Each SpectrumInquiryRequest object represents a spectrum inquiry request of a CBSD.
  • SpectrumInquiryRequest object Parameter R/O/C Description NAME: cbsdId Required The CBSD shall set this parameter to the value DATA TYPE: string of its CBSD identity. N AME: inquiredSpectrum Required This field describes the spectrum for which the DATA TYPE: array of object: CBSD seeks information on spectrum FrequencyRange availability.
  • FrequencyRange object Parameter R/O/C Description NAME: lowFrequency Required The lowest frequency of the frequency range in DATA TYPE: number Hz.
  • CS Spectrum Inquiry Response message This message, which is sent from the CBSD Controller to the CS, is for the CBSD Controller to forward the spectrum inquiry response from the SAS to the CS.
  • This message includes the Spectrum Inquiry Response message defined in Wireless Innovation Forum Standard’s Interface Technical Specification WINNF-TS-016, and conditioned on the csSpectrumInquiryResponseNoChange parameter (which is used to reduce the messaging traffic load between the CS and the CBSD Controller) or the csSpectrumRequestShallRespond parameter (which is used to re-synchronize the CBSD status between the CS and the CBSD Controller) in the CS Spectrum Inquiry Request Message, as explained below: Parameter R/O/C Description NAME: Required If set to true, it indicates there is no change from csSpectrumInquiryResponseNoChange the last response.
  • DATA TYPE Boolean N AME: spectrumInquiryResponse Conditional If the csSpectrumInquiryResponseNoChange DATA TYPE: array of object: is set to false or the SpectrumInquiryResponse csSpectrumRequestShallRespond in the CS Spectrum Inquiry Request Message is true, this field is required, otherwise, this field can be omitted.
  • a rray of SpectrumInquiryResponse objects Each SpectrumInquiryResponse object represents a spectrum inquiry response to a spectrum inquiry request of a CBSD.
  • SpectrumInquiryResponse object Parameter R/O/C Description NAME: cbsdId Conditional This parameter is included if and only if the DATA TYPE: string cbsdId parameter in the SpectrumInquiryRequest object contains a valid CBSD identity. If included, the SAS shall set this parameter to the v alue of the cbsdId parameter in the corresponding SpectrumInquiryRequest object.
  • N AME response Required This parameter includes information on whether D ATA TYPE: object: Response the corresponding CBSD request is approved or disapproved for a reason. See Table 14 of WINNF-TS-016: Response Object Definition. [0096] Response Object Definition (from Table 14 of WINNF-TS-016) Parameter R/O/C Description NAME: responseCode Required An integer to indicate the type of result. The DATA TYPE: number value 0 means the corresponding CBSD request is successful. This shall be one of the values in Table 39 Response Code Definition in WINNF- TS-016 as shown also below. N AME: responseMessage Optional A short description of the result.
  • DATA TYPE string N AME: responseData Optional Additional data can be included to help the DATA TYPE: Dependent on CBSD resolve failures.
  • responseCode see Table 40 in For spectrum inquiry response message, the W INNF-TS-016: responseData field is Not Present. Definitions (as shown also below). [0097] Response Code Definitions (from Table 39 in WINNF-TS-016) Only the code related to Spectrum Inquiry Response Message is applicable. r esponseCode Value Name Description 0 SUCCESS CBSD request is approved by SAS 300 UNSUPPORTED_SPECTRUM The frequency range indicated in the spectrum inquiry request or grant request is at least partially outside of the CBRS band.
  • responseData related to the SFG Response message.
  • responseCode Name responseData Data Description of Value Type error data 0 SUCCESS Not present 300 UNSUPPORTED_SPECTRUM Not present
  • Measurement Request message This message, which is sent from the CS to the CBSD Controller, is for the CS to request the CBSD Controller to request for RF measurement.
  • P arameter R/O/C Description NAME: measRequest Required Array of MeasRequest objects. Each DATA TYPE: array of object: MeasRequest object represents a measure inquiry MeasRequest request of a CBSD.
  • MeasRequest object Parameter R/O/C Description NAME: cbsdId Required The CBSD shall set this parameter to the value DATA TYPE: string of its CBSD identity. N AME: inquiredSpectrum Required This field describes the spectrum for which the DATA TYPE: array of object: CS requests for RF measurement of the CBSD. FrequencyRange (FrequencyRange object is as defined above in connection with CS Spectrum Inquiry Request message).
  • Measurement Response message This message, which is sent from the CBSD Controller to the CS, is for the CBSD Controller to send the measurement of the CBSDs to the CS.
  • MeasResponse Required Array of MeasResponse objects Each DATA TYPE: array of object: MeasResponse object represents a measurement MeasResponse inquiry response to a measurement inquiry request of a CBSD.
  • the CBSD Controller shall set this parameter to the v alue of the cbsdId parameter in the corresponding MeasRequest object.
  • FrequencyRange This field describes the spectrum for which the CS requests for RF measurement of the CBSD.
  • N AME: measReport Conditional This parameter is included if the cbsdId is DATA TYPE: array of object: included.
  • MeasReport The CBSD Controller uses this parameter to r eport measurements to the CS, one MeasReport object for each FrequencyRange object.
  • MeasReport object The format of the MeasReport object is defined below.
  • SFG Request message This message, which is sent from the CS to the CBSD Controller, is for the CS to request the CBSD Controller to create or modify SFG for each CBSD.
  • SfgRequest object Parameter R/O/C Description NAME: cbsdId Required The CS shall set this parameter to the value of DATA TYPE: string the CBSD identity. N AME: sfgId Required The CS shall set this parameter to the value to DATA TYPE: string the SFG of this CBSD. N AME: inquiredSpectrum Required This field describes the spectrum for which the DATA TYPE: array of object: CS requests for spectrum of the CBSD. FrequencyRange (FrequencyRange object is as defined above in connection with CS Spectrum Inquiry Request message).
  • SFG Response message This message, which is sent from the CBSD Controller to the CS, is for the CBSD Controller to respond to the SFG request of the CS. The response is successful if the SAS grants and authorizes the inquired spectrum of the CBSD. Otherwise, the CBSD Controller includes the responseCode from the SAS in the message.
  • SfgResponse object Parameter R/O/C Description NAME: cbsdId Conditional This parameter is included if and only if the DATA TYPE: string cbsdId parameter in the SfgRequest object contains a valid CBSD identity. If included, the CBSD Controller shall set this parameter to the v alue of the cbsdId parameter in the corresponding SfgRequest object. NAME: inquiredSpectrum Conditional This parameter is included if the cbsdId is DATA TYPE: array of object: included. FrequencyRange This field describes the spectrum for which the CS requests for SFG of the CBSD.
  • N AME response Required This parameter includes information on whether DATA TYPE: object: Response the corresponding CBSD request is approved or disapproved for a reason. See Table 14 and 39 in WINNF-TS-016. (Response object is as defined above in connection with CS Spectrum Inquiry Response message). [00108] Response Code Definitions (from Table 39 in WINNF-TS-016) Only the grant-related codes below are applicable to the SFG Response Message (related to the Grant procedure). r esponseCode Value Name Description 0 SUCCESS CBSD request is approved by SAS 400 INTERFERENCE Requested operation parameters cause too much interference. This responseCode value indicates that the Grant request is unlikely to be successful if retried by the CBSD.
  • responseData 4 01 GRANT_CONFLICT Conflict with an existing Grant of the same CBSD.
  • the CBSD should be able to remediate this using the data r eturned in the responseData structure, by synchronizing its Grant state with the SAS and relinquishing any out-of-sync Grants.
  • Response Data Definitions (From Table 40 in WINNF-TS-016) responseData: related to the SFG Response message.
  • responseCode Name responseData Data Type Description of Value error data 0 SUCCESS Not present 400 INTERFERENCE Not present 401 GRANT_CONFLICT array of string The Grant ID of an existing Grant that causes the conflict.
  • 4G 4th Generation wireless networks 5G 5th Generation wireless networks CBRS citizens Broadband Radio Service CBSD CBRS Device CS Channel Selector DP Domain Proxy EIRP Equivalent isotropic radiated power GAA General Authorized Access LTE Long-Term Evolution NR New Radio OnGoA OnGo Alliance PAL Priority Access License PRB Physical Resource Block RSRP Received Signal Reference Power RSRQ Reference Signals Received Quality SFG Single Frequency Group SINR Signal to Interference plus Noise Ratio SAS Spectrum Access System UE User Equipment

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Un système d'optimisation de réseau de service radio à large bande publique (CBRS) ayant un système d'accès au spectre (SAS) et une pluralité de dispositifs CBRS (CBSD) comprend : un dispositif de commande CBSD ; et un sélecteur de canal (CS) conçu pour : i) demander, par l'intermédiaire du dispositif de commande CBSD, des CBSD d'un premier opérateur pour rapporter une interférence provoquée par des CBD d'autres opérateurs sur une pluralité de canaux ; ii) identifier, sur la base des rapports provenant des CBD du premier opérateur, une liste de canaux à faible interférence disponibles présentant des niveaux d'interférence inférieurs à un niveau de seuil spécifié ; iii) déterminer, à partir de la liste de canaux à faible interférence, au moins un canal commun satisfaisant une largeur de bande minimale requise pour servir de groupe monofréquence (SFG) pour tous les CBD du premier opérateur ; et iv) demander au dispositif de commande CBSD d'acquérir le ou les canaux communs à partir du SAS pour configurer le SFG.
PCT/US2025/034324 2024-06-19 2025-06-19 Groupe monofréquence dynamique pour cbsds Pending WO2025264896A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202463661655P 2024-06-19 2024-06-19
US63/661,655 2024-06-19

Publications (1)

Publication Number Publication Date
WO2025264896A1 true WO2025264896A1 (fr) 2025-12-26

Family

ID=98214199

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2025/034324 Pending WO2025264896A1 (fr) 2024-06-19 2025-06-19 Groupe monofréquence dynamique pour cbsds

Country Status (1)

Country Link
WO (1) WO2025264896A1 (fr)

Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180035301A1 (en) * 2016-08-01 2018-02-01 Spidercloud Wireless, Inc. System and method for cbrs dual cell radio node
US20190245740A1 (en) * 2018-02-07 2019-08-08 Mavenir Networks, Inc. Management of radio units in cloud radio access networks
US20190335336A1 (en) * 2017-09-21 2019-10-31 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for handling interference connection types in citizens broadband radio service devices band
US20190373610A1 (en) * 2017-05-18 2019-12-05 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for evaluating and ranking channels using constraining factors imposed by incumbent and ppa protection
US20200213862A1 (en) * 2018-12-27 2020-07-02 Charter Communications Operating, Llc Methods and apparatus for allocating spectrum in citizens broadband radio service networks
US20200305159A1 (en) * 2019-03-20 2020-09-24 Commscope Technologies Llc Cloud radio access network implementing a citizens broadband radio service system
US20210345352A1 (en) * 2018-10-24 2021-11-04 Sony Group Corporation Electronic device and method for wireless communication, and computer-readable storage medium
US20220345896A1 (en) * 2021-04-22 2022-10-27 Mavenir Systems, Inc. Systems and methods for enabling communications over shared spectrum using o-ran fronthaul interface in radio access networks
US20230040563A1 (en) * 2021-06-23 2023-02-09 Mavenir Systems, Inc. Supporting cbrs operation using non-real time ran intelligent controller (non-rt ric) applications
US20230254103A1 (en) * 2022-02-07 2023-08-10 Celona, Inc. Method and Apparatus for Using a Probe UE to Measure Interference Using Dynamic Time Division Duplex (TDD) Configuration
US20230262473A1 (en) * 2017-08-15 2023-08-17 Charter Communications Operating, Llc Methods and apparatus for dynamic control and utilization of quasi-licensed wireless spectrum
US20240015778A1 (en) * 2022-07-11 2024-01-11 Celona, Inc. Method and apparatus for determining channel quality and assisting operation of a cbrs wireless communication network
US20240187931A1 (en) * 2021-08-06 2024-06-06 Dell Products L.P. Adaptive spectrum as a service

Patent Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180035301A1 (en) * 2016-08-01 2018-02-01 Spidercloud Wireless, Inc. System and method for cbrs dual cell radio node
US20190373610A1 (en) * 2017-05-18 2019-12-05 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for evaluating and ranking channels using constraining factors imposed by incumbent and ppa protection
US20230262473A1 (en) * 2017-08-15 2023-08-17 Charter Communications Operating, Llc Methods and apparatus for dynamic control and utilization of quasi-licensed wireless spectrum
US20190335336A1 (en) * 2017-09-21 2019-10-31 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for handling interference connection types in citizens broadband radio service devices band
US20190245740A1 (en) * 2018-02-07 2019-08-08 Mavenir Networks, Inc. Management of radio units in cloud radio access networks
US20210345352A1 (en) * 2018-10-24 2021-11-04 Sony Group Corporation Electronic device and method for wireless communication, and computer-readable storage medium
US20200213862A1 (en) * 2018-12-27 2020-07-02 Charter Communications Operating, Llc Methods and apparatus for allocating spectrum in citizens broadband radio service networks
US20200305159A1 (en) * 2019-03-20 2020-09-24 Commscope Technologies Llc Cloud radio access network implementing a citizens broadband radio service system
US20220345896A1 (en) * 2021-04-22 2022-10-27 Mavenir Systems, Inc. Systems and methods for enabling communications over shared spectrum using o-ran fronthaul interface in radio access networks
US20230040563A1 (en) * 2021-06-23 2023-02-09 Mavenir Systems, Inc. Supporting cbrs operation using non-real time ran intelligent controller (non-rt ric) applications
US20240187931A1 (en) * 2021-08-06 2024-06-06 Dell Products L.P. Adaptive spectrum as a service
US20230254103A1 (en) * 2022-02-07 2023-08-10 Celona, Inc. Method and Apparatus for Using a Probe UE to Measure Interference Using Dynamic Time Division Duplex (TDD) Configuration
US20240015778A1 (en) * 2022-07-11 2024-01-11 Celona, Inc. Method and apparatus for determining channel quality and assisting operation of a cbrs wireless communication network

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ABBASS WASEEM, AHMAD KHAN MUZAMMIL, HUSSAIN FAROOQI ASHFAQ, NAWAZ WAQAS, ABBAS NASIM, ALI ZULFIQAR: "Optimizing Spectrum Utilization and Security in SAS-Enabled CBRS Systems for Enhanced 5G Performance", IEEE ACCESS, IEEE, USA, vol. 12, 1 January 2024 (2024-01-01), USA , pages 165992 - 166010, XP093388124, ISSN: 2169-3536, DOI: 10.1109/access.2024.3495972 *
SHASHIKA MANOSHA K, JOSHI S, HÄNNINEN T, JOKINEN M, PIRINEN P, POSTI H, HORNEMAN K, YRJÖLÄ S, LATVA-AHO M: "A Channel Allocation Algorithm for Citizens Broadband Radio Service/Spectrum Access System", EUROPEAN CONFERENCE ON NETWORKS AND COMMUNICATIONS (EUCNC), 1 January 2017 (2017-01-01), XP093388126, Retrieved from the Internet <URL:https://oulurepo.oulu.fi/bitstream/handle/10024/23161/nbnti-fe2018080833526.pdf?sequence=1> *

Similar Documents

Publication Publication Date Title
US20230037701A1 (en) Dynamic shared cell groups
US11856411B2 (en) Method and apparatus for determining spectrum availability and allocating spectrum in a spectrum controlled network
US10701751B2 (en) Signaling for multiple radio access technology dual connectivity in wireless network
EP3146779B1 (fr) Coordination d&#39;interférence intercellulaire améliorée
EP3506718B1 (fr) Procédés et appareils de sélection de tranches de réseau d&#39;accès radio
US10624107B2 (en) System and method for network controlled dynamic small cell management
US9504036B2 (en) Configuring cellular connectivity
CN119906985A (zh) 无线电接入网络智能控制器、e2节点及其方法
TWI756382B (zh) 通訊管理裝置、通訊管理方法及記錄媒體
WO2013127343A1 (fr) Procédé et appareil pour utiliser une technologie de radio cognitive
US11356499B1 (en) Universal domain proxy for SAS
JP2023529445A (ja) Ｎｗｄａｆの機能を改善してｓｍｆが重複送信を効果的にするための方法
US20250016785A1 (en) Reduced spectrum allocation in cbrs networks
US12362897B2 (en) TDD configuration coordination for networks using adjacent bands
JP5334918B2 (ja) 無線通信システム、セル最適化方法、サーバ装置および基地局
US20250119373A1 (en) Wireless-centric enterprise networks based on service-level agreements
US20230262715A1 (en) Adaptive unlicensed spectrum revocation
US12309618B2 (en) Telecommunication systems
US12537579B2 (en) Media access control (MAC) control element (CE) (MAC-CE) and physical layer (PHY) channel state information (CSI) enhancements
WO2025264896A1 (fr) Groupe monofréquence dynamique pour cbsds
WO2023231468A1 (fr) Procédé et appareil de communication
US20250323740A1 (en) Interference measurement with coordinated blanking
US20240007865A1 (en) Methods and Apparatus for Peer Network Communication in Wireless Networks
WO2025073094A1 (fr) Transfert (ho) cellulaire tenant compte de mesures de trafic
US20260040147A1 (en) Identification of radio access network (ran) resources for ai/ml computation availability

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 25831515

Country of ref document: EP

Kind code of ref document: A1