By Matt Mariani on 10/06/21 5:34 PM
Winning your bid for a Citizens Broadband Radio Service (CBRS) Priority Access License (PAL) is great news for your business, whether you’re an MNO, cable company, telco operator, or enterprise. With access to 3.5 GHz spectrum, you have new opportunities to enhance wireless coverage and capacity in existing markets and to tap into new markets by offering in-demand 5G and IoT services.
Naturally, you’ll want to get a proof of concept (PoC) for CBRS device deployment and service provisioning going so you can get to field trials and commercial service as quickly as possible. At first glance, an isolated platform that’s dedicated to CBRS technology and devices from a single vendor can look like the most efficient way to accelerate the PoC phase. Unfortunately, that short-term PoC acceleration will cost you significant time, effort, and money down the road.
Single-Vendor Device Management Solutions Are Not Field-Hardened
While a single-vendor, CBRS-only solution can help to accelerate the PoC phase, there are no guarantees the solution will function the same way in your production environment as it did in the segregated PoC environment. There simply hasn’t been enough real-world validation.
CBRS spectrum has only recently become available. That single-vendor solution has only been used by a handful of other customers, and probably only in PoCs. It has almost certainly never been used in production environments, or in conjunction with other network technologies, devices, or systems. What’s more, it may have only been used in a limited number of markets around the world.
Once you move that single-vendor, siloed solution from your PoC environment to your multi-vendor, multi-technology production environment, the number of unknowns, and the risks, skyrocket.
Let’s take interoperation with business support systems (BSS) and operations support systems (OSS) as an example. For efficient device deployment and service provisioning, CBRS platforms must be able to exchange customer information and other network data with these critical back-office systems. If the platform is not field-hardened, this may be the first time anyone has ever tried to make the platform interoperate with your systems, leading to unexpected delays and costs.
The only way to guarantee the CBRS solution will interoperate with your back-end systems is to choose a platform that’s already proven to smoothly interoperate with the systems you use.
A CBRS device management solution that’s not field-hardened can also make it more time-consuming and difficult to add new devices and to change provisioning parameters. The device vendor may need to make firmware changes that require extensive testing, and making those changes may not be the vendor’s top priority.
In contrast, a field-hardened, multi-vendor solution already supports a wide variety of access points and gateways from different vendors. It automatically discovers new devices, and can easily read and write device parameters so new devices can be quickly and easily added to the system and reconfigured when necessary.
These are just a few examples of the challenges you may encounter with a platform that’s not field-hardened. Unfortunately, the solution vendor may not yet have the expertise or experience needed to help resolve these, or other, issues, and the company’s product roadmap may not be rich enough to meet your requirements long-term.
Device Management Gets Messy
Almost every service provider in the world operates in a multi-vendor, multi-technology, and multi-system environment. Adding a solution that supports only a single vendor’s devices and a single technology stack creates device management complexity and silos that can have a significant impact on operational efficiency, effectiveness, and costs.
For example, if CBRS alerts and alarms are captured in an isolated platform and are not fed into your alarm system, there may be delays in learning about CBRS network and device issues. You may miss opportunities to correlate issues in your LTE network with issues in your CBRS network, leaving you unaware of the related CBRS network issues.
Also, at some point, your network operations center (NOC) will need to get involved in managing CBRS deployments. Forcing NOC staff to use a separate, CBRS-only solution adds time and complexity to their jobs. They’re constantly switching platforms, and they lack the unified view needed to quickly detect and resolve issues across all devices and technologies.
A standards-based, carrier-grade device management platform is designed and built for multi-vendor, multi-technology environments, making it easy to optimize device management. To help you better understand those benefits, we’ll take a closer look at what it takes to efficiently manage the large number of devices in CBRS networks in an upcoming blog. Keep an eye out for it.
Proprietary, Single-Vendor Approaches Increase Costs
When you’re locked in to a proprietary, single-vendor, single-technology solution, there’s very little flexibility to lower support costs. You’re tied to the vendor, and to whatever pricing scheme they dictate. If custom adaptors or extensions are needed for proprietary solutions to interoperate with existing systems, costs further escalate. Longer term, there can also be additional development costs to adapt the CBRS platform to support new devices and technologies.
To avoid these types of uncontrollable costs, start thinking about the bigger picture the moment you know you’ll be working with CBRS. Go beyond the idea that CBRS is a technology stack and consider how CBRS network requirements fit into your overall device management system and operations from day one. In our next blog, we explore some of the additional steps you can take to help keep your CBRS operations profitable.