Are you in the driver’s seat? Take control of your managed Wi-Fi software updates

Most service providers want to be at the wheel when deploying software updates to their networking equipment, especially for managed Wi-Fi. But what happens when they get shifted to the back?

Residential and business subscribers expect rigorous service level agreements (SLAs), especially in an era when reliable, always-on connectivity is a must. This requires service providers to manage and control the corresponding network infrastructure and apply software updates to maintain it, including new features and bug fixes. Crucially, they expect to control those updates, having the freedom to apply their approved software versions at their preferred times and to target specific nodes or regions. However, not all suppliers support that expectation.

Beware backseat drivers: Some suppliers dictate your software version

The first issue is that the supplier may require you to always run the latest software version. As we all know, that may not be a good idea. New software may have bugs or run slow because of feature bloat. Having your customers lose connectivity because of an unwanted software update impacts the customer experience. It could also result in loss of customers or churn.

No more “Are we there yet?” Don’t let them tell you when to update

The next issue is that some suppliers may not give you control over when and where software is updated. Service providers typically stage updates over time in separate regions. That gives them a chance to verify that the software that worked in the test lab also works at scale in the field. But why is this important?

Lab tests versus open roads: Why initial test drives aren’t enough

The supplier tests every software update before it’s released. And it’s tested again by the service provider prior to rollout. But there are sometimes issues that don’t turn up before deployment. Here are some prime examples:

• Memory leaks. A memory leak is a defect where memory slowly becomes unavailable. They can occur even when modern languages are used because of the necessity of interfacing with low-level drivers. Memory leaks make the system run slower or possibly crash. Sometimes, this type of issue takes weeks or months to manifest, so it may not show up in lab testing.
• Race conditions and multi-threading issues. This type of error is related to the sharing of resources among multiple threads or tasks. This is often due to what’s called a race condition whereby two or more events may occur unpredictably. This type of software bug may have a low probability of happening in a single device. But a low probability event in a single device becomes more and more likely as hundreds, thousands or even millions of devices are deployed.
• Hardware compatibility problems. Software updates to support new hardware releases can cause problems with older-generation hardware. Suppliers may not test software updates against all older hardware, so problems might not crop up until the software is deployed in a live network. Many service providers are aware of these types of issues. As a result, they prefer to deploy software in a gradual and controlled fashion. That way, any such problems appear in a contained area, and the impact on the network and SLAs is limited.

Adtran puts you in control

With Adtran, you decide the route with complete control over what software comes on your devices and when. If you have multiple networks and service areas with different requirements, Adtran can build a custom configuration that can be deployed across all network environments. And you control when and where software updates are applied. Contact Adtran to discover how we make sure you’re always in the driver’s seat, and never just along for the ride.