Breaking News

GLOBAL Wi-Fi NEWS bulletin

Reliable Wi-Fi has become an essential part of the hotel guest experience. Guests expect fast, consistent connectivity that supports streaming, video calls, multiple devices, and the digital services they use throughout their stay.

For hotels, the right network can also support connected operations, guest engagement, and future technology investments.

In this white paper, you’ll learn:

  • Why hotel Wi-Fi has become a critical part of the guest experience
  • What guests expect from a reliable, high-performing hotel network
  • How poor connectivity can affect guest satisfaction and online reviews
  • Why capacity, coverage, and consistency matter as much as internet speed
  • How reliable infrastructure supports hotel operations and connected technology
  • What European hoteliers should consider when planning, upgrading, and managing Wi-Fi

Download the white paper to explore how a stronger connectivity foundation for European hotels can support better guest experiences today and the technology needs of tomorrow.

FULL ARTICLE HERE

Plain language connectivity questions answered in seconds. Increase Uptime

Wi-Fi monitoring with LLM integration is available today, and 7SIGNAL is among the first enterprise Wi-Fi platforms to offer it. Instead of logging into a dashboard to find out why a floor had high roaming-failure rates last Tuesday, ask your AI assistant. Instead of spending an hour building a weekly summary, prompt for one. Here is how it works, what you can do today, and where it is headed.

7SIGNAL makes its live performance data roaming, DHCP, signal quality, and EYERIS AI diagnostics available to AI assistants through the Model Context Protocol (MCP), the open standard Anthropic developed to connect LLMs to live external data. Any MCP-compatible assistant, including ChatGPT, Claude, and Copilot, can query that data to answer questions in plain language, generate reports, and drive agentic workflows grounded in what your network is doing right now, not in training data. It works with the AI assistant and the wireless infrastructure you already use.

“Our platforms allow our customers to extract, analyze, and act on Wi-Fi and other network performance data collected by our software agents and sensors. Now we’re making this data available to LLM platforms including ChatGPT, Claude, and Copilot, which means that anyone with access to a 7SIGNAL solution will be able to leverage the power of some of the world’s most sophisticated AI platforms to understand and analyze network performance.”

— Eric Camulli, VP of Customer Success, 7SIGNAL

Why can’t an AI assistant answer network questions on its own?

Because it wasn’t there. LLMs are trained on historical data with a cutoff; they can’t tell you which device is roaming poorly on your hospital floor today, or what your DHCP offer times looked like during yesterday’s shift change.

LLMs are extraordinary reasoning engines. They analyze complex data, identify patterns, generate structured reports, and explain technical findings in plain language. What they lack is the present tense of your network.

7SIGNAL has exactly that continuously at the device level across close to 1,000 metrics. But that data lives in a specialized dashboard, and most of the people who need to understand network performance operations managers, clinical directors, warehouse supervisors, IT leadership never log in to it. The insight stays trapped. MCP bridges that gap.

What is the Model Context Protocol (MCP)? MCP is an open standard, developed by Anthropic, that connects LLMs to live external data sources through a standardized interface. The 7SIGNAL MCP server exposes performance data, roaming metrics, DHCP telemetry, signal quality, and EYERIS AI diagnostics as tools any compatible LLM can query, so the assistant gets current, environment-specific answers instead of guessing from training data.

How does the 7SIGNAL MCP integration work?

7SIGNAL runs an MCP server that exposes its performance data as a collection of discoverable tools. The AI assistant acts as the client: when you ask a question, it determines which tools are relevant, calls them, receives the live data, and reasons over it in its response.

Nothing is guessed or hallucinated. The assistant retrieves actual metrics from your environment grounded in what 7SIGNAL Agents and 7SIGNAL Sensors measured, not in what a model assumes Wi-Fi behavior generally looks like. Because MCP is a vendor-neutral open standard, it is not tied to any one platform. As the ecosystem matures and more assistants add native MCP support, your network data becomes available across all of them without additional integration work.

Component Role Example
7SIGNAL Agents Collects device-level Wi-Fi telemetry from endpoints Captures roaming failures, DHCP times, and latency on each endpoint
7SIGNAL Sensors Continuous passive RF measurement via hardware sensors Measures signal quality, interference, and coverage across the space
EYERIS AI Analyzes close to 1,000 metrics; diagnoses root causes Flags a DHCP degradation trend 48 hours before users notice
7SIGNAL MCP server Exposes all of the above as LLM-queryable tools The assistant calls get_roaming_failures with site and date
Your AI assistant Reasons over live data; generates answers and reports Returns a plain-language summary or a structured report on demand
ServiceNow / Jira Receives automated tickets with 7SIGNAL context attached Incident created with root cause, affected devices, and suggested fix

What can you do with it today?

​Three capabilities are available the moment the connector is live no add-on, no roadmap wait. They map directly to the core ways teams use network data: asking questions, generating reports, and surfacing anomalies.

​1. Ask your network questions in plain language

No dashboard, no filter configuration, no export. You ask; the assistant retrieves the answer from 7SIGNAL and responds. For teams that previously spent 20–30 minutes navigating dashboards to answer a stakeholder question, that is an immediate and significant reduction in reporting time. Example prompts that work today:

“Which devices on the third floor had the most roaming failures last week?”

“How did DHCP offer times trend during yesterday’s morning shift?”

“Which access points have the highest rate of client disconnections this month?”

“What does EYERIS AI flag as the top three issues across the manufacturing floor right now?”

“Compare signal quality between Site A and Site B for Android devices.”​

2. Generate performance reports on demand

What previously required manual dashboard work pulling data, building tables, writing summaries, and formatting for a non-technical audience now takes a single prompt. Ask for a weekly site performance summary and get a formatted, readable report grounded in your actual metrics for that period, ready to send to IT leadership. Reports that used to take an hour to build take under a minute to generate.

3. Surface anomalies before users notice

EYERIS AI continuously analyzes close to 1,000 metrics for anomalous patterns across your device fleet. Through the MCP, those signals become early warnings an assistant can act on: DHCP offer times climbing on a subnet for 36 hours, a driver-version anomaly across a fleet of scanners, a handoff failure correlating with voice-picking errors on one route. These alerts only surface today after a user calls the help desk. Now they surface before the call.

Does it work with agentic workflows, or just chat?

Both. The 7SIGNAL MCP works inside agentic workflows too, not only questions typed into an assistant.​

The connector exposes the same live performance data to any MCP-compatible agent, which means an automated, multi-step workflow can query the network as one of its steps, with no person in the loop. ServiceNow is the clearest example: an AI agent running there can pull the affected devices, the time range, and the EYERIS AI diagnostic recommendation when an incident opens and attach them to the record so the diagnosis is in the ticket before any user has reported a problem. 7SIGNAL is not only a data source a person prompts; it is a tool surface an agent can act on. Today that means enrichment, triage, and ticket creation with full diagnostic context. The trajectory is autonomous remediation, where the agent assesses severity, opens the incident, and, within a defined scope and approval gates, pushes the fix.

What does this look like in daily operations?

Representative workflows available today with the 7SIGNAL MCP connected to Claude, ChatGPT, or Copilot.

Monday morning brief. A network engineer asks for a summary of Wi-Fi performance across all sites from the previous week. The assistant queries 7SIGNAL, retrieves site-level data, and produces a structured brief on the best- and worst-performing sites, the devices with the highest roaming-failure rates, and any EYERIS AI flags from the period. Under 60 seconds.

Stakeholder question. A hospital IT director asks why nurse satisfaction scores on the third floor dropped last quarter. The engineer queries 7SIGNAL to correlate roaming performance, VoIP call quality, and EHR access latency for that floor and period. The assistant returns a plain-language explanation with supporting metrics ready to share with clinical leadership, no dashboard navigation.​

Incident triage. An alert fires that scanner performance on the warehouse floor has degraded. The engineer asks the assistant to query 7SIGNAL for the affected devices, identify the common factors: access point, driver version, time of day, and cross-reference with EYERIS AI. A root-cause hypothesis comes back in minutes rather than hours, with specific remediation recommendations.

Automated ticket (ServiceNow). A workflow monitoring 7SIGNAL data detects a DHCP offer-time spike on a manufacturing subnet that has been trending upward for 48 hours. It automatically creates a ServiceNow incident with the affected subnet, the time range, the most-impacted devices, and the EYERIS AI diagnostic recommendation attached — before any user has reported a problem.

What changes for the network team?

The operational impact falls into three areas, each of which frees up time for work that requires engineering judgment. The throughline is simple: less time gathering data, more time acting on it.​

Less time on reporting. Performance reporting is one of the highest-time-cost activities that produces the least direct value; the time goes into formatting and presentation, not analysis. Assistant-generated reports grounded in live 7SIGNAL data remove that overhead entirely.

Less time on initial triage. The first 30–60 minutes of investigating a Wi-Fi complaint is typically spent gathering data: which devices, which access points, which time window, what the metrics show. The assistant does that in seconds, presenting a structured summary and a root-cause hypothesis instead of a blank dashboard.

Visibility without new tooling. Operations managers, clinical directors, and IT leadership can query network performance in plain language through the AI assistant they already use — without access to the dashboard or training on it. Network performance becomes part of the operational conversation, not a specialist report delivered on request.

What comes next: from LLM queries to agentic remediation

The current integration of natural-language queries, automated reporting, anomaly alerting, and ServiceNow ticket creation is the first stage. The next involves agentic workflows that not only identify and report issues but take action to address them.

Learn more about 7SIGNAL and ServiceNow

​In practice, that means workflows that detect an anomaly in EYERIS AI output, correlate it with historical patterns to assess severity, create a ServiceNow ticket with full diagnostic context, identify the recommended remediation, and, where the action is within a defined scope of autonomous operation, behind approval gates, push the configuration change to the relevant network controller. All without a network engineer touching the keyboard.

This is not science fiction. The data pipeline from 7SIGNAL’s sensors and agents through the MCP server to the assistant is already operational, and the ServiceNow integration is live. The remaining steps defining agentic action scopes, building remediation workflows, and establishing approval gates are engineering and governance work, not architectural work.

“Ultimately, the goal is to prevent any network disruption, but intermediate steps could, for example, be early warnings and integrating assurance data with support ticket systems like ServiceNow. We’re quickly moving towards much improved automated network assurance using evolving forms of AI.”

— Eric Camulli, VP of Customer Success, 7SIGNAL

SAN JOSE, Calif. – August 21, 2026 – Synaptics Incorporated (Nasdaq: SYNA) today announced that Ken Rizvi has resigned from his position as Chief Financial Officer, effective immediately, to pursue another opportunity. Mr. Rizvi will remain employed in an advisory role through September 30, 2026 to assist with the transition of his responsibilities.

Synaptics has elected not to conduct a search at this time for a successor CFO due to the announcement on June 25, 2026 of the pending merger between Synaptics and onsemi. Rahul Patel, President and CEO, will serve as the principal financial officer through the closing of the merger.

Mr. Kermit Nolan, Synaptics’ former Chief Accounting Officer, is returning as a consultant to advise the internal team through the transition. Over his 20-year tenure, he held several roles at the company, including acting CFO.

“Synaptics has a strong and experienced finance organization, and we are confident in the team’s ability to ensure continuity through the pending transaction,” said Rahul Patel, President and CEO, Synaptics. “Our strategic priorities and focus on driving success across Edge AI and Physical AI markets remain unchanged. I would like to thank Ken for his contributions to our success over the past few years and wish him the best in his new role.”

For a while, many believed working from home was temporary. Today, it’s simply how millions of people work, day in and day out.

The home has become an office, a classroom, an entertainment hub, and increasingly, a place where AI-powered tools are becoming part of the daily workflow. That evolution is changing what subscribers expect from their broadband experience.

In my latest byline for Broadband Breakfast, I explored new research from Plume showing how work-from-home habits continue to shape broadband usage and what that means for Internet Service Providers. The findings reinforce a simple reality: subscribers no longer judge their broadband service by speed alone. They judge it by whether it keeps them productive, connected, and uninterrupted throughout the day.

The Home Network Has Become Mission Critical

When working from home first became widespread, much of the industry’s attention focused on bandwidth.

Could networks handle the demand?

Would upload speeds be sufficient?

How much capacity would households need?

Those were important questions; today’s questions are different.

Can a video meeting remain stable while someone else is streaming?

Can AI applications respond instantly and successfully?

Can multiple users work, learn, and collaborate simultaneously without noticing the network at all?

The conversation has shifted from delivering connectivity to delivering confidence.

Reliability Matters More Than Raw Speed

Our recent research with Parks Associates shows that subscriber expectations continue to evolve.

People rarely celebrate a faster speed test. They notice a frozen video call, poor audio quality, or an unresponsive app when they need it most.

That’s why the industry’s focus is expanding beyond throughput to Quality of Outcome (QoO). Success isn’t measured by how fast the network is in ideal conditions. It’s measured by whether subscribers can accomplish what they set out to do.

For remote workers, that outcome might be leading a customer presentation without interruption.

For someone using AI throughout the day, it might be receiving responses instantly enough to stay productive.

For families, it means all of those experiences happening simultaneously.

AI Raises the Bar Even Higher

The next generation of work-from-home applications won’t simply consume bandwidth.

They’ll depend on low latency, consistent performance, intelligent traffic management, and continuous optimization.

As AI assistants become integrated into everyday workflows, subscribers will expect networks to adapt automatically to changing conditions.

Meeting those expectations requires more than additional capacity.

It requires intelligence.

Orchestration Becomes the Competitive Advantage

Every connected home is different: The number of users changes. The devices change. Applications compete for network resources in different ways throughout the day.

Delivering a consistently great experience increasingly depends on understanding those changing conditions and adapting in real time.

That’s where orchestration becomes critical.

By continuously learning across more than 600 million connected devices, over 50 million homes, 450+ ISP partners, and 58 countries, Plume can recognize patterns that individual networks cannot. Those insights help providers optimize performance proactively rather than reacting after subscribers experience problems.

The Future of Work Is Already Here

The biggest takeaway from this research isn’t that people are still working from home.

It’s that work from home has fundamentally changed what subscribers expect from broadband.

The providers that succeed won’t simply offer faster connections; they’ll deliver networks that are reliable, intelligent, and able to adapt to the realities of modern digital life.

For a deeper look at the research and what it means for broadband providers, I encourage you to read my full article in Broadband Breakfast.

Read the full byline: What ISPs Need to Know About Work-From-Home Habits.

Part One of this research paper covers the technical investigation: how the infection works, how Popanet operates and what traffic flows through subscriber homes without their knowledge or consent. Part 2 will examine how different types of malware are exploiting the presence of already-deployed proxies on these devices. All indicators of compromise are published on Plume Security Lab’s GitHub.

Subscribers buying a SuperBox believe they are paying for content. What they are also buying, without knowing it, is a permanent seat on someone else’s network.

Read Now

What happens when internet connectivity is interrupted at a hospital in the middle of running live diagnostics? What about a retailer processing thousands of transactions? Or a global conference streaming live to millions? In each scenario, business stops. Internet access becomes the single point of failure for the applications and services that keep the business running.

When the internet is the primary path to your applications, a connection failure isn’t just an IT issue. As the standard for connecting branch users and applications, direct internet access (DIA) requires resilient connectivity and robust security to ensure uninterrupted productivity and uptime.

AI-driven workloads, cloud services, and distributed teams are pushing more business-critical traffic directly onto the internet. As that traffic grows, the demand for performance and resilience accelerates.

Bringing networking and security together at the edge, Cisco 8000 Series Secure Routers are built to meet this demand. Independent validation from Miercom confirms that the 8000 series delivers, providing high-performance DIA with integrated security services in a single platform.

Validating DIA with integrated security

Miercom evaluated Cisco 8000 Series Secure Routers on two fronts: how much traffic they can handle and how well they stop threats while doing it. Miercom tested the routers across simulated small, medium, and large branch environments that mimicked real-world enterprise architectures, including cloud applications and SD-WAN controllers.

Across the portfolio, the platforms sustained throughput ranging from 1.0 Gbps to 9.5 Gbps while running next-generation firewall, intrusion prevention, URL filtering, application control, advanced malware protection, and network address translation (NAT) simultaneously. These results demonstrate that high-performance connectivity and comprehensive security can coexist as enterprises scale AI, cloud, and software-as-a-service (SaaS) applications.

Miercom also validated the platform’s integrated security capabilities. The Cisco 8235 Secure Router blocked 98.3% of evaluated attack strikes while sustaining approximately 2 Gbps of bidirectional throughput under load. Combined with identity-based microsegmentation, these capabilities help enterprises securely scale AI and cloud connectivity without sacrificing performance.

Cisco Secure Router with callouts showing 98.3% of attack strikes blocked and up to 9.5 Gbps of direct internet access (DIA) throughput.

Figure 1. Cisco 8235 Secure Router results from Miercom’s independent testing

Make DIA your foundation

Increasing volumes of internet-bound application traffic are reshaping enterprise networks, making DIA a foundational service for modern branches. Cisco 8000 Series Secure Routers combine high-performance routing, integrated security, embedded visibility, and built-in post-quantum cryptography (PQC) in a single platform, simplifying operations and helping organizations securely scale.

  • High-performance DIA: Enables secure access for cloud and bandwidth-intensive applications
  • Converged networking and security: Simplifies operations with one integrated platform
  • Greater cyber resilience: Protects users with advanced security and PQC-ready encryption
  • Operational efficiency: Accelerates troubleshooting with embedded visibility
  • End-to-end visibility and resiliency: Reduces hardware complexity with embedded ThousandEyes application-aware monitoring and automated cellular failover

 The next step

As internet traffic becomes more distributed, bandwidth-intensive, and security-sensitive, enterprises need more than fast connectivity. Edge operations demand high-performance routing, consistent security, and end-to-end visibility. Integrating these capabilities in a single platform makes this manageable. Miercom’s testing confirms that Cisco 8000 Series Secure Routers deliver everything the AI-driven enterprise needs, providing a trusted foundation for secure DIA while helping organizations simplify operations and prepare for future traffic demands.

Your team is getting watched in two different ways right now, and neither one shows up in a security report.

The first is the network. The moment someone opens a laptop in a hotel, an airport, or a conference hall, their outbound traffic is visible to anyone else watching that network.

The second happens everywhere, including on the network you own. The sites your team visits are quietly collecting: Location trackers, mail trackers, data brokers, and ad networks build profiles in the background on every single visit.

We have had tools for the first problem for years. The catch is that most of them only work when the user remembers to turn them on. They forget. They skip it on fast hotel Wi-Fi. They turn it off when it slows something down.

That gap, between “we have a tool for that” and “protection is actually running,” is where traffic gets intercepted and users get profiled.

SecureTransit closes it.

What SecureTransit does

SecureTransit is endpoint privacy, enforced as policy. It does two things.

It encrypts outbound traffic before it leaves the device. Every time your team connects from a hotel, an airport, or a conference, they are on a network you do not own, and traffic on those networks can be observed and intercepted. SecureTransit encrypts it at the device, so what crosses the wire is unreadable to anyone watching locally.

It blocks trackers at the source. Location trackers, mail trackers, data brokers, and ad networks get cut off before data ever leaves the device. This one applies on any network, from the office to home network to hotel Wi-Fi.

SecureTransit ships inside the DNSFilter Roaming Client, the same lightweight agent you already use for filtering and for user activity intelligence through CyberSight. There is no second agent to deploy and no second console to learn.

Admins set the mode per organization or per device: Always-On, Manual, or Disabled. Credentials are provisioned and managed server-side, so your users never configure anything. That means they cannot misconfigure anything, and in Always-On mode, they cannot opt out.

SecureTransit is currently in beta and is available in our existing two-week free trial.

Login or start your free trial today.

“Doesn’t DNSFilter already block trackers?”

Fair question, and yes, at the DNS layer. DNS filtering blocks trackers during DNS resolution, before a connection is ever made, and it runs everywhere your Roaming Clients run.

SecureTransit blocks the tracker connection at the source, as traffic passes through the tunnel. That catches what DNS-layer blocking alone cannot, and it encrypts everything else along the way.

One distinction worth making: DNS-over-TLS and DNS-over-HTTPS encrypt the DNS query itself, but everything that comes after that query is still in the clear. SecureTransit encrypts the whole path, device to internet.

 

 

The two run as complementary layers with a graceful fallback. If the tunnel is disconnected or disabled, the device falls back to DNS-layer tracker filtering. Protection degrades. It never disappears.

Privacy from outsiders, not from your security team

This is the part I want to be clearest about, because “privacy” can sound a lot like “a place my users go that I cannot see.”

SecureTransit shields users from local-network observers and third-party trackers. It never shields them from your own admins. You keep the same DNS query visibility you have today, so there are no blind tunnels and no reporting gaps. Your users get privacy from outsiders, and you keep the audit trail.

One agent, three capabilities

With SecureTransit, the DNSFilter Roaming Client delivers three distinct capabilities through a single lightweight agent:

  • Filtering. DNS-layer protection through our global Anycast network (Classic mode) or local interception through DNS PreCheck, depending on your deployment
  • CyberSight. User behavior analytics at the endpoint, surfacing the applications and services your users are actually running, including the locally installed AI tools that DNS-layer analysis cannot see
  • SecureTransit. Encrypted outbound traffic and tracker blocking, enforced as admin-controlled policy

One deployment. Three capabilities. One place to manage all of them.

Turn it on where the exposure actually is

SecureTransit is a per-device add-on. You license it where the risk lives instead of paying for every endpoint in the building.

For most teams, that is a short list: The people who travel, the executives, the fully remote staff, and honestly, the users who keep failing your phishing simulations. If you are running 100 Roaming Clients and 10 of those users are the ones genuinely working off untrusted networks, you cover those 10.

Cost scales with exposure, not headcount.

For MSPs, that is what makes it sellable. SecureTransit runs inside the same multi-tenant dashboard you already use, so your techs deploy it without adding a vendor, a console, or a new workflow. This way, you can lead the conversation around privacy with: “Privacy is enforced as policy on every device that needs it.”

Why we built it as policy

Enforcement has been a weak point for structural reasons more than technical ones. Most privacy tools are separate products with a separate agent, a separate console, and a separate vendor. That means another deployment to manage, another set of credentials to maintain, and a dependency on users to actually connect.

Every one of those is a place where it can quietly fail. The tool sits in a different workflow than your filtering policy. There is no way to tie enforcement to the organizational hierarchy you already manage. And when a user is off-network on a connection you do not control, you have no way to confirm anything is running at all.

We built SecureTransit for managed environments, where policy enforcement, not user behavior, is the security model.

DNSFilter blocks the threats. SecureTransit handles the privacy. Your data should be yours: On hotel Wi-Fi, on the office network, and inside every site your team visits.

Trying SecureTransit

SecureTransit entered beta on Aug. 17, 2026, and it is available today on the Windows Roaming Client, version 3.7 and up. Support for our other platforms is coming.

You can test it today in our 14-day trial. Then go look at how many trackers it blocked for those people in two weeks. That number tends to be the whole argument.

Every embedded product that needs to talk to the outside world starts with the same question: which radio?

For a long time, the answer was simple, because the product usually only needed to do one thing. A fitness tracker needed BLE to sync with a phone. A factory sensor needed LTE to report back to a server. One job, one radio, done.

Today the answer is more complicated, and more consequential. Because the right answer isn’t just a technical choice, it’s arguably the highest-stakes decision you’ll make on the entire product. 

Get it right and you have a device that works reliably in the field for a decade. Get it wrong and you’re looking at a board respin, a recertification cycle, and a failure mode your customers will find before you do. And unlike most decisions in a product’s life, this one is nearly impossible to undo once silicon is chosen.

So the answer is no longer “which radio.” It’s increasingly “which radios, in what combination, and have you thought through everything that combination is going to cost you — in power, in board space, in firmware complexity, and in the years of maintenance that follow.”

That’s what this article is about.

Why Connectivity Decisions Matter Early

Most engineering decisions in a product’s lifecycle can be revisited. A firmware bug gets patched over the air. A mechanical tolerance gets adjusted in the next molding run. Even a processor choice, painful as it is to change, can often be recovered through a firmware port and board revision, especially when the software is built on a portable platform such as Zephyr.

Radio selection doesn’t work that way, because a radio isn’t really one decision. Radio selection is a stack of decisions that get poured into the board layout and never separated again.

Choosing BLE plus Wi-Fi plus UWB means choosing a chipset (or combination of chipsets) that supports that exact set, an antenna configuration that gives each radio enough isolation to not desensitize the others, a power budget that assumes certain radios are off most of the time, and a certification path that covers every one of those radios in every region the product ships to.

Each of those downstream decisions assumes the radio set is fixed. If a customer asks six months into development for UWB ranging that wasn’t in the original spec, the answer usually isn’t “we’ll add a UWB chip.” It’s closer to “we need a new board revision, a new antenna layout, a new RF coexistence study, and a new certification cycle” — months of work triggered by a requirement that, on paper, looks like adding one part to a BOM.

The reverse is just as costly. Overprovisioning — adding LTE “just in case,” or UWB because a competitor’s spec sheet has it, means paying for certification, power budget, and board space for a radio that may never get used. On a product shipping in volume, that’s not a rounding error; it’s margin, gone, on every unit, for the life of the product.

Understanding the Role of Each Radio

Once the product features are clear, the next step is to match each feature to the radio that solves it, and resist the temptation to make one radio do a job it wasn’t built for. Each of these technologies has a narrow zone (sweet spot) where it’s the ideal answer,  a much wider zone where it’s just ok, and a wide zone where it’s the wrong choice.

1. Bluetooth Low Energy (BLE)

BLE is the default for short-range, low-power interaction between a device and a phone. It’s good at presence detection in a loose sense, pairing, small data exchanges, and running for years on a coin cell. 

What it’s not good at is precision. BLE signal strength (RSSI) can tell you roughly whether something is near or far, but “roughly” can mean several meters of error depending on the environment. A closed door, a person’s body, a metal cabinet can all shift the reading enough to make an access-control decision unreliable. BLE answers “is a known device: somewhere nearby vs at this specific point in space.”

2. Ultra-Wideband (UWB)

UWB exists for the question BLE can’t answer: precise distance and, with the right setup, direction. Using time-of-flight measurements across a wide spectrum band, UWB can resolve position to within centimeters, largely independent of the interference and multipath issues that make BLE’s RSSI unreliable indoors. 

This is why it has become the standard for secure ranging, proving a credential is physically at the door, not just somewhere in the building. It is used for spatial awareness use cases like asset tracking or hands-free unlock. 

The tradeoff is power and cost. UWB radios draw more current than BLE and add bill-of-material cost, so they show up only when the product genuinely needs spatial precision, not as a general-purpose connectivity radio.

3. Wi-Fi

Wi-Fi is the high-bandwidth, infrastructure-dependent option. It’s the right choice when a device needs to move real data, such as firmware updates, video, logs, large configuration syncs, and when it can rely on existing network infrastructure being present and powered. 

Wi-Fi’s weaknesses are exactly its dependencies: it needs an access point in range, it draws meaningfully more power than BLE (especially when maintaining an active connection), and it inherits whatever reliability problems exist on the local network. A device that only has Wi-Fi has no story for “what happens when the network is down,” which is precisely the gap LTE fills.

4. LTE

LTE (or cellular more broadly) is the answer to “this device needs to reach the outside world regardless of what local infrastructure does or doesn’t exist.” It doesn’t depend on a router, a switch, or anyone’s IT configuration. It depends on a SIM and a cell tower. That independence is also its cost. 

Cellular modules are more expensive, carry recurring data plan costs, and consume more power than any of the other three radios discussed here. LTE earns its place on a board when a device going silent because someone unplugged a switch is unacceptable.

5. Thread

Thread is worth understanding separately from BLE and Wi-Fi, even though it often ships on the same combo silicon. It’s a low-power, IPv6-based mesh networking protocol built specifically for IoT devices. Where BLE connects a device to a phone and Wi-Fi connects it to the internet, Thread connects groups of devices to each other and to a border router, forming a self-healing mesh that doesn’t depend on a central access point staying online.

Its sweet spot is dense deployments of battery-powered nodes that need to communicate reliably without individually maintaining a Wi-Fi connection — think building sensors, industrial monitoring arrays, or smart lighting grids.

Many modern Wi-Fi combo chips from Silicon Labs, Nordic, and NXP already include Thread support alongside BLE, so the incremental BOM cost is often minimal. The decision is less about hardware and more about whether your application architecture can take advantage of the mesh.

6. Zigbee

Zigbee occupies similar territory to Thread — low power, mesh networking, short-range IoT — but with a longer installed base and deeper penetration in industrial and building automation markets. Where Thread is IP-native and designed with future interoperability in mind, Zigbee has decades of deployed infrastructure behind it, particularly in smart energy, HVAC, and industrial control environments where ripping out existing infrastructure is not an option.

Like Thread, Zigbee frequently ships bundled on combo chips alongside Wi-Fi and BLE. For products intended for environments where a Zigbee coordinator is already present or where the customer base expects Zigbee compatibility, it earns its place without adding significant BOM cost. For greenfield deployments with no existing Zigbee infrastructure, Thread’s IP-native architecture is generally the more future-proof choice.

Summary Pattern — Which Radio Answers Which Question:

  • BLE answers presence and pairing
  • UWB answers precise location
  • Wi-Fi answers high-bandwidth data movement
  • LTE answers infrastructure independence
  • Thread answers low-power mesh networking in IPv6-native environments
  • Zigbee answers mesh networking in established IoT and building automation ecosystems

There’s a lot more interesting comparisons and contrasts in our previous post – UWB vs BLE vs Wi-Fi for Indoor Location Tracking.

Common Multi-Radio Architectures

In practice, most multi-radio products fall into a handful of recognizable patterns, and which pattern fits depends less on what the radios do individually and more on how tightly they need to be coordinated.  Here are four common multi radio approaches:

i) Single SoC, Multiple Integrated Radios.

Many modern wireless SoCs bundle BLE and Wi-Fi (and sometimes Thread or Zigbee) into a single chip with shared RF front-end logic. This is the simplest path when the radio set aligns with what the SoC vendor offers: one part number, one toolchain, one set of drivers, and coexistence handled to varying degrees by the vendor’s firmware. 

The constraint is that the product’s radio requirements must fit within what the SoC was designed to support. If the access controller needs UWB and the SoC doesn’t include it, this pattern stops being an option for that radio, no matter how convenient it is for the other two.

ii) Host Processor Plus Discrete Radio Modules

Here, a main application processor (often running Linux or a heavier RTOS) talks to separate modules for each radio it doesn’t have natively — a Wi-Fi/BLE combo module over SPI or UART, a UWB module over SPI, an LTE module over a serial AT-command interface. 

This is the most flexible pattern and the one that scales best to four radios, because each module can be sourced, certified, and swapped somewhat independently. The cost is integration complexity: every module has its own driver and power sequencing requirements, and the host processor has to arbitrate between them — including managing which radios can be active at the same time without desensitizing each other.

iii) Tiered Architecture with a Connectivity Co-Processor

In more constrained designs, a small microcontroller is dedicated solely to managing radios — handling BLE and UWB, for instance — while a separate, more capable processor handles the application logic and interfaces with Wi-Fi and LTE. 

This splits the problem along power and real-time boundaries: the radio co-processor can stay in a low-power state managing BLE advertising or UWB ranging windows, while the main processor only wakes for higher-level tasks. 

It adds a second processor and an inter-processor communication layer, but it can meaningfully reduce overall power draw in products where BLE or UWB need to be active far more often than Wi-Fi or LTE.

iv) Cellular-Centric Architecture

For products where LTE is the primary link and everything else is secondary — remote sensors with a BLE configuration interface, for example — the LTE module often becomes the de facto main processor, running application logic on its embedded MCU and treating BLE as a peripheral feature rather than a full radio stack. 

This minimizes part count and cost but constrains how much local processing or radio coordination the product can do, since the cellular module’s MCU is typically far less capable than a dedicated application processor.

Engineering Challenges in Multi-Radio Designs

Picking the right radios and the right architecture pattern gets a design to the starting line. What happens when four radios have to share one board and operate at the same time is where most of the real engineering effort goes, and where most of the surprises show up late.

i) RF Coexistence

BLE, Wi-Fi, and parts of UWB all operate in or near the 2.4 GHz band, and when they’re on the same board, they interfere with each other. A Wi-Fi transmission can desensitize a BLE receiver sitting a few millimeters away on the same PCB, causing dropped connections or missed packets that have nothing to do with either radio’s actual range. 

Solving this isn’t a matter of picking good chips; it requires coexistence schemes — time-division arbitration between radios, frequency planning, and sometimes dedicated coexistence signaling lines between chips — that have to be designed in from the start and validated with real RF measurements.

ii) Antenna Placement and Isolation

Four radios usually means four antennas (or, at minimum, several), and on a small board there often isn’t a clean way to place them all without some degree of mutual coupling. An antenna tuned for UWB’s wide bandwidth has different placement and ground-plane requirements than a BLE antenna, and putting them too close together degrades both. 

This is one of the reasons radio decisions can’t be deferred. Antenna placement is decided at board layout, and a layout designed for three antennas doesn’t have a clean path to “just add a fourth” without redoing the RF design around it.

iii) Power Budget and Duty Cycling

Each radio has a different power profile, and the difference between “available” and “active” matters enormously. UWB ranging and active Wi-Fi connections can draw an order of magnitude more current than BLE in a low-power advertising state. 

A device that needs to run on battery for months, but also needs to maintain a UWB ranging session for security, has to carefully duty-cycle which radios are active when — UWB only during the ranging window, Wi-Fi only during sync windows, LTE only as a fallback — and the firmware managing that duty cycling has to be correct, because a bug that leaves one radio on continuously can turn a multi-month battery life into a multi-day one.

iv) Certification Across Radios and Regions

Every radio on the board needs regulatory certification, such as FCC and CE, for every region the product ships to, and these certifications aren’t independent of each other. Adding a radio, or even changing antenna placement for an existing one, can require recertifying the whole RF system. 

For a product shipping to multiple regions, this multiplies: four radios across, say, North America, Europe, and a few other markets can mean a dozen or more separate certification efforts, each with its own timeline and cost, and each one that has to be redone if the RF design changes after the fact.

v) Software Abstraction

The application layer generally shouldn’t need to know whether a connection came over Wi-Fi or LTE, or whether a presence signal came from BLE or UWB. But someone has to build that abstraction, and it has to handle radios with very different connection models, latencies, and failure modes underneath a single interface. 

Getting this wrong creates products where switching between radios (say, falling back from Wi-Fi to LTE when the network drops) introduces visible delays, dropped data, or inconsistent behavior that the end user experiences as the product simply being unreliable.

None of these is a separate workstream that can be solved in isolation and then assembled; they have to be reasoned about together, from early in the design, by people who understand how each piece constrains the others

Where the Industry Is Heading

A few trends are starting to reshape how these tradeoffs get made, and most of them point toward pushing more of the multi-radio complexity off the board designer’s plate and into silicon, software stacks, and standards that didn’t exist a few years ago.

1. Combo Chips are Absorbing More Radios.

The first wave of combo chips merged BLE and Wi-Fi because they were the most common pairing and shared enough RF infrastructure to make integration worthwhile. The newer wave is starting to add UWB into that mix, and a few vendors are exploring tighter integration with cellular as well. 

As this continues, some of the products described earlier, like the access controller that needs BLE, UWB, Wi-Fi, and LTE, may eventually be built around two chips instead of four, with much of the coexistence work handled inside the combo part rather than designed from scratch on the board.

2. Coexistence is Moving from Board-Level Workaround to Chip-Level Feature

Coexistence between radios was something board designers solved after the fact — adding coexistence signaling lines between separately-sourced chips, tuning time-division schedules in firmware. 

Newer silicon is starting to build coexistence arbitration in as a designed feature, with chips that are aware of each other’s activity and negotiate airtime automatically rather than requiring a board-level protocol to be designed and validated independently for each combination of parts.

3. UWB is Becoming Less of a Specialty Add-on

UWB’s role was usually kept as a radio added only when a product specifically needed that capability. As UWB chips get cheaper and smaller, and as ecosystems (particularly around digital car keys and access control) standardize on UWB for proximity verification, it’s increasingly showing up as a default inclusion in certain product categories. This shifts UWB from “the radio you add if you need precise ranging” toward “the radio you include by default in this category, the way BLE became default a decade ago.”

4.  Software Abstraction Layers are Maturing

The idea of a connectivity manager — a software layer that gives the application a single “connected/disconnected” interface regardless of which radio underneath provides it — isn’t new, but until recently most of these were built in-house, per product, with all the inconsistency that implies. 

Some RTOS vendors and silicon vendors are starting to ship more complete connectivity stacks as part of their SDKs, covering radio selection, fallback logic, and power state management together. This is reducing the amount of glue code a multi-radio product needs to write from scratch.

Closing Thoughts

BLE, Wi-Fi, LTE, and UWB modules are well-documented, widely sourced, and individually well understood. What’s hard is the part that doesn’t show up on any single chip’s datasheet: how they behave once they’re sharing a board, a power budget, and an antenna layout — and how that combination holds up across years of firmware updates and certification cycles in the field.

That’s the gap between a product that works in a lab demo and one that works on a loading dock in winter, on a battery that has to last a year, and on a network connection that drops without warning. Closing that gap isn’t a single decision. It’s dozens of smaller ones, made early, by people who’ve seen where these designs tend to go wrong before they go wrong.

This is the kind of problem embedUR works on with clients — taking a product from “here’s what it needs to do” to a board and firmware architecture that holds up once it’s shipped, across the radios, the power budget, and the years of updates that follow.

If you’re working through a multi-radio architecture decision and want a second set of eyes before it’s locked into silicon, talk to embedUR’s connectivity team. The earlier this conversation happens, the more options stay open.

Energy efficiency has become a key differentiator for hotels and multi-dwelling units (MDUs). Rising utility costs, ambitious sustainability goals, and increasing guest expectations are driving property owners to address this by investing in smarter building automation. According to the International Energy Agency’s (IEA) Energy Efficiency 2025 report, buildings account for around 30% of global energy demand, making hotels and MDUs two of the largest opportunities for improving operational efficiency.

For developers building next-generation connected buildings, meeting this challenge requires creating scalable energy-management solutions. This starts with secure, low-power endpoints that communicate reliably across an entire property. Z-Wave Long Range provides the wireless foundation to connect these endpoints at scale, enabling hotels and MDUs to sense, connect, and respond intelligently.

Why Energy Management Needs Smarter Endpoints

Energy management is becoming a broader priority across the connected-device ecosystem. In smart homes, for example, Matter Energy Management is expanding how devices can share energy information and coordinate their operation. Hotels and MDUs take this challenge to a different scale, where wireless coverage, endpoint scalability, and long-term operation become critical.

Today’s Hotels/MDUs already contain connected thermostats, occupancy sensors, smart locks, lighting controls, and environmental sensors. But many energy-saving opportunities remain untapped because these devices often operate independently rather than as an intelligent system.

Consider a hotel room after a guest checks out. Without occupancy awareness, HVAC systems may continue conditioning an empty room, lights remain on unnecessarily, and housekeeping receives no automated indication that the room is vacant. Similar inefficiencies occur in apartment buildings, where common-area lighting, environmental controls, or vacant units continue consuming energy regardless of actual occupancy.

Energy Management Automation

Solving these problems requires endpoints that can securely exchange information, respond locally to occupancy changes, and scale across hundreds or thousands of devices without increasing deployment complexity.

In other words, scalable energy management starts with scalable wireless endpoints.

Why Z-Wave Long Range for Energy Management Devices?

Hotels and MDUs present unique connectivity challenges. Devices are distributed across multiple floors, concrete walls reduce signal propagation, and many endpoints must operate on batteries for years with minimal maintenance.

Z-Wave Long Range addresses these challenges by extending reliable Sub-GHz communication while supporting significantly larger endpoint populations than traditional residential deployments. The combination of long-range communication, low-power operation, and certified interoperability enables occupancy sensors, thermostats, lighting controls, leak detectors, and smart locks to work together as a coordinated energy-management system.

Similarly, certified interoperability allows manufacturers to develop products that integrate into an established ecosystem, giving building operators greater flexibility when selecting devices while reducing deployment risk and protecting long-term infrastructure investments.

For developers, this means building products that can support both today’s installations and tomorrow’s larger, more intelligent properties without redesigning the underlying wireless architecture.

Designing Better Energy-Management Devices with Z-Wave Long Range

Building intelligent endpoints requires more than selecting a wireless protocol. Developers must balance battery life, security, installation simplicity, application complexity, and long product lifecycles within a single device.

Silicon Labs addresses these challenges through a combination of low-power wireless hardware, integrated security, certified software, and a comprehensive development ecosystem. The EFR32ZG28 demonstrates how these capabilities come together for next-generation Z-Wave Long Range products.

One practical challenge is commissioning hundreds of devices across a large property. The EFR32ZG28 combines Z-Wave Long Range connectivity with optional Bluetooth® Low Energy, enabling installers to use familiar mobile workflows for device commissioning and servicing while maintaining robust connectivity through the Z-Wave network. Part of the Z-Wave 800 family, the ZG28 combines energy-efficient operation, strong RF performance, long-range connectivity, and industry-leading security.

Connected thermostats, locks, and environmental sensors may remain deployed for more than a decade while controlling critical building functions, making security a non-negotiable aspect of development. Secure Vault™ provides hardware-rooted protection for device identities, cryptographic keys, secure boot, and firmware integrity, helping developers build products designed for long-term operation and evolving cybersecurity requirements.

Application complexity also continues to grow. Modern energy-management devices increasingly combine sensing, user interfaces, local control algorithms, firmware updates, and multiple communication interfaces. The EFR32ZG28 provides additional memory and processing resources that give developers room to expand application functionality without requiring a hardware redesign as products evolve.

Edge processing is becoming equally important for practical energy-management applications. Rather than transmitting every sensor event to the cloud, endpoints can locally distinguish between brief movement and sustained room occupancy before triggering HVAC or lighting adjustments. This reduces unnecessary network traffic while enabling faster responses to changing conditions. Integrated AI/ML acceleration provides additional headroom for these evolving endpoint functions as occupancy sensing and environmental monitoring become more sophisticated.

Energy Management Workflow

Accelerating Commercial Energy Management Product Device Development

Developing a commercial energy-management product involves considerably more than selecting a wireless SoC. Engineering teams must integrate protocol software, implement security, complete certification, optimize battery life, validate wireless performance, and maintain products throughout long deployment lifecycles.

Developers building energy-management applications can accelerate their workflow using Silicon Labs’ Simplicity Studio, a unified development platform that brings together SDKs, network analysis, and energy-profiling tools in one place. By handling the complexity of foundational technology integration, Simplicity Studio makes it possible for engineers to focus on building differentiated features that deliver real, measurable value to property operators.

Building the Next Generation of Intelligent Buildings

The next phase of energy management will be defined not by the number of connected devices, but by how intelligently they work together to understand occupancy, anticipate energy demand, and adapt building operations in real time. As buildings continue to evolve, developers will face new questions. How can endpoints make more decisions locally while maintaining ultra-low power consumption? How can thousands of connected devices remain secure throughout decade-long deployments? How can building systems become more autonomous without increasing complexity for installers and operators?

The answers to these questions will shape the next generation of intelligent buildings, and the wireless endpoints being designed today will play a central role in enabling that future.

Conditional Approval supports continued U.S. deployment while reinforcing Zyxel’s commitment to trusted, secure networking solutions

Anaheim, California, (Aug. 25, 2026) — Zyxel Communications today announced that its Wi-Fi 7 gateways (EE4210 and EE6610) and 5G NR Indoor Router (NR5331) have received Conditional Approval, exempting these products from the Federal Communications Commission’s (FCC) Covered List through February 3, 2028.

The Conditional Approval enables service providers and businesses to continue importing, purchasing and deploying these Zyxel broadband solutions in the United States during the approval period.

As broadband providers navigate evolving security and regulatory requirements, Zyxel remains focused on providing customers with trusted, flexible technology choices that support their ability to expand and modernize their networks.

“Trust and security have always been fundamental to how we develop and support our products,” said Edmund Chu, Executive Vice President at Zyxel Communications. “This Conditional Approval provides additional assurance to our customers as they plan their broadband deployments. We will continue investing in product security, long-term support and reliable connectivity that helps our customers confidently grow their networks.”

The Conditional Approval covers three Zyxel solutions designed for next-generation broadband connectivity as part of Zyxel’s broader portfolio of networking solutions:

EE4210: A tri-band BE10000 Wi-Fi 7 gateway with 2.5GbE WAN/LAN connectivity, designed to deliver high-performance connectivity for next-generation broadband services and connected homes.

  • EE6610: A tri-band BE19000 Wi-Fi 7 gateway with 10GbE WAN/LAN connectivity, built to support multi-gigabit broadband services and high-performance connected-home applications.
  • NR5331: A 5G NR indoor router designed for flexible fixed wireless broadband deployments and POTS replacement over 5G

A Continued Commitment to Network Trust

The FCC added certain foreign-produced routers to its Covered List in March 2026 as part of broader efforts to protect U.S. communications infrastructure. Products that receive Conditional Approval through the applicable federal review process are exempt from the Covered List and its associated restrictions for the duration of that approval.

Zyxel maintains a comprehensive approach to product and network security, including ongoing firmware maintenance, vulnerability management, publicly available security advisories and lifecycle support.

Beyond regulatory compliance, Zyxel is committed to helping service providers and businesses build networks they can trust. Zyxel’s comprehensive portfolio spans PON/XGS-PON, Wi-Fi 6 and Wi-Fi 7, 5G FWA, PTMP, Switching, Security, Wireless Access and Cloud-Managed Networking.

For more information about Zyxel and its broadband and networking solutions for service providers and businesses, visit the Zyxel Communications website and follow us on YouTube, Facebook, X and LinkedIn.

About Zyxel:

Zyxel Communications delivers technological innovations and has connected the world to the internet for more than 35 years. Whether establishing access through fixed or mobile broadband solutions, Zyxel Communications offers a comprehensive and flexible portfolio that helps service providers stay ahead of the competition.