A wireless connectivity SDK is not an MCU SDK with a radio bolted on.

The link layer has real-time deadlines that conflict with general-purpose RTOS scheduling, the radio has to be shared between multiple protocols, and the SDK ships certification artifacts that are themselves part of the commercial value. Three architectural decisions, one coexistence problem, and the certification surface that competitors cannot replicate cheaply.

Most of what is true of MCU SDK design — layered HAL, OSAL boundary, semver discipline, OTA pipeline, security architecture — is also true of wireless connectivity SDKs. The difference is that wireless SDKs face a class of problem that does not exist in pure MCU SDKs at all, and the design decisions required to solve it have no direct analogue in the wired peripheral world.

The root cause is that the RF subsystem is not a peripheral. A UART driver can miss a deadline by a millisecond and the worst that happens is a buffered byte arrives late. A BLE link layer that misses a connection event by a millisecond drops the connection. The link layer has to meet hard real-time deadlines that conflict with general-purpose RTOS scheduling, and it has to do so while sharing the antenna with potentially multiple other protocols, and it has to do so in a way that customers can certify against the relevant standards bodies and reference in their own product filings.

That set of requirements drives architectural decisions that are unique to wireless SDKs. This post walks through them: the three dominant architectures for the protocol stack layering problem, the radio coexistence question that becomes mandatory once a device runs more than one protocol, and the certification surface that turns the SDK from a software deliverable into a commercial moat.

The protocol stack layering problem

In a typical MCU SDK, the firmware stack layers cleanly: peripheral driver, HAL, middleware, application. Each layer calls the one below it, scheduling is handled by the RTOS, and timing is soft enough that millisecond-level jitter is tolerable everywhere except in a few specific peripherals.

In a wireless SDK, this layering breaks down at the radio. The link layer — the lowest software layer above the physical radio — has to meet deterministic deadlines measured in microseconds. A BLE connection event has to be serviced at exactly the right moment in the next connection interval, or the slave’s reception window closes and the connection drops. A Thread MAC frame has to be acknowledged within a fixed window, or the sender retransmits and triggers a cascade of timing-dependent recovery behaviour. These are not soft real-time constraints that an RTOS scheduler can paper over. They are hard deadlines that the link layer has to hit, every time, regardless of what else is running on the device.

There are three dominant architectural solutions in production wireless SDKs, each with a different trade-off between cost, performance, and integration complexity.

Separate controller architecture (dual-core SoC). A dedicated network core — usually a small Cortex-M — runs the link layer and protocol stack in isolation from the application processor. The two cores communicate over a shared-memory IPC channel or a hardware mailbox. The application core’s HAL presents a high-level API that abstracts the real-time radio scheduler entirely: AT commands for modem-type devices, or HCI for BLE radio coprocessors. This is the cleanest architecture from the application developer’s perspective, because the application core never has to know about radio timing. The cost is silicon area: the second core, the IPC fabric, and the dedicated memory regions all have to be paid for in the die.

Time-sliced soft-radio architecture (single-core SoC). The link layer runs as a time-critical foreground task that preempts the application CPU at scheduled slot boundaries. This architecture is cost-effective, because there is no second core, but it imposes strict constraints on application task latency. Long-running callbacks, badly tuned DMA configurations, or interrupt handlers that block for too long can violate link-layer timing and cause dropped connection events. The SDK has to expose enough configuration and diagnostic surface for application developers to find and fix these violations, which is itself a non-trivial documentation and tooling problem.

Integrated RTOS-managed radio architecture. The radio protocol stack is integrated as a high-priority RTOS task. This is the most common architecture for dual-band Wi-Fi/BLE SoCs with a single application-class core, where the application core is large enough to run both the application workload and the protocol stack with appropriate priority assignment. The architectural challenge is task affinity and priority configuration — the radio task has to preempt application code reliably, and the priority scheme has to be designed so that no application code path can starve the radio. This requires careful documentation and validated reference configurations, because customer applications that disregard the priority scheme will see degraded radio performance in ways that are hard to debug.

The choice between the three is a silicon-architecture decision more than an SDK decision, but the SDK has to be designed to fit whichever architecture the silicon ships with. An SDK targeting a dual-core SoC has to expose the IPC channel, the controller versioning, and the controller firmware update path. An SDK targeting a single-core integrated architecture has to expose the priority scheme, the task affinity configuration, and the diagnostic surface for finding latency violations. The architectures are not interchangeable from the SDK’s perspective, and an SDK written for one cannot be cleanly retargeted to another.

Multi-protocol coexistence becomes mandatory

A growing class of IoT devices must simultaneously support multiple radio protocols on the same SoC. The canonical example is a smart-home device that uses BLE for commissioning — the user pairs the device with their phone — and then operates on Thread or Wi-Fi for its core network connectivity. The device has to run both stacks, on the same antenna, concurrently.

This introduces a problem that does not exist in single-protocol designs: contention. Both protocols’ schedulers attempt to access the antenna at arbitrary times, driven by their own internal timing requirements. A BLE connection event and a Thread transmission slot can collide, and without arbitration, the result is dropped frames on whichever protocol lost the race.

The component that solves this is a radio coexistence manager — sometimes called a Radio Scheduler — that sits between the protocol stacks and the physical radio. It arbitrates channel access using configurable priority rules and time-division multiplexing. Both protocol stacks request airtime from the scheduler; the scheduler grants slots based on priority, deadline, and the current state of the other protocols. This component has to be part of the SDK, not the application, because no application developer has the visibility into both protocol stacks needed to build it correctly.

The SDK’s job is to expose the scheduler’s configuration parameters — protocol priorities, slot length budgets, minimum BLE connection interval — so that application developers can tune the trade-offs for their specific use case. A device whose primary function is real-time control over Thread will configure the scheduler to favour Thread; a device whose primary function is real-time audio over BLE will configure it the other way. The scheduler does not have a single correct configuration; it has a configuration surface, and the SDK has to make that surface accessible and well-documented.

Matter adds a further dimension of complexity. A Matter device must simultaneously maintain a BLE commissioning stack, a Thread or Wi-Fi operational network stack, and the Matter application layer with its cluster and attribute models. The three layers have different timing requirements, different memory footprints, and different update cadences, and the integration challenge is non-trivial enough that SDK teams shipping into the Matter ecosystem have to provide validated multi-protocol reference configurations as a first-class deliverable. A customer who is asked to assemble BLE + Thread + Matter integration from scratch is a customer who chose a different SDK.

Certification: the commercial moat that competitors cannot replicate cheaply

The third dimension that distinguishes wireless SDKs from MCU SDKs is certification. Wireless protocols are governed by standards bodies that issue certification listings against specific implementations, and customers shipping wireless products into commercial channels need to reference those listings in their own product filings.

The relevant programmes for the major protocols are concrete:

BLE certification is managed by the Bluetooth SIG Qualification Program (BQRP). The controller and host stack must pass the Profile Tuning Suite (PTS) test cases, and the vendor must hold a valid Qualified Design listing. Without this, no commercial BLE product can ship with the Bluetooth trademark.

Thread certification requires passing the Thread Group’s Thread Test Harness, against the specific Thread version (1.3, 1.4, etc.) the device claims to support. Matter requires its own certification through the Connectivity Standards Alliance, addressed separately from the underlying Thread or Wi-Fi transport certification.

Wi-Fi certification through the Wi-Fi Alliance covers the WPA3 security suite, Protected Management Frames, and version-specific features such as Target Wake Time for Wi-Fi 6. Customers shipping Wi-Fi-capable devices into regulated markets need each of these to be certified against the version they ship.

What this means for the SDK is that a vendor who provides a fully certified protocol stack — with qualification listings the customer can reference directly in their own product filings — provides significant commercial value that competitors cannot replicate cheaply. Without it, every customer must independently qualify the stack, which is expensive (testing fees, lab time, engineering effort) and slow (certification windows of weeks to months).

This is also where SDK versioning meets certification in a way that pure MCU SDKs do not have to handle. A certification listing is issued for a specific software version, including the sub-version and build hash. The SDK documentation has to specify, unambiguously, which exact version corresponds to which certification listing — because a customer who ships a slightly different version is a customer who has invalidated the listing they were planning to reference. This requirement turns the build hash into part of the public-surface contract: it is not just an internal artifact, it is the identifier customers cite in their compliance documentation, and the SDK team has to treat it accordingly.

The implication is that wireless SDK release management is significantly more constrained than MCU SDK release management. A change that would be a routine PATCH in an MCU SDK — a small bug fix in the middleware — may require re-certification of the protocol stack in a wireless SDK, depending on which layer the fix touches and how the certifying body interprets the change. SDK teams shipping certified wireless stacks have to plan their release cadence around certification windows, and the cost of a casual rebuild is materially higher than in an MCU world where the rebuild is just a CI artifact.

Why this matters when picking a wireless SDK

For customers evaluating wireless SDKs, the differences from MCU SDKs are the things that distinguish a product they can ship from a product they cannot. A wireless SDK that does not document its protocol stack architecture clearly forces the customer to reverse-engineer the layering before they can plan their own application. A wireless SDK that does not provide a radio coexistence manager forces the customer to build one themselves, which most customers cannot do correctly. A wireless SDK without certification listings, mapped to specific versions, forces every customer to qualify the stack independently, which is the kind of cost that converts a design-win into a regret.

For SDK teams, the implication is that wireless SDK design is the strongest test of SDK architecture discipline. The MCU SDK virtues — layered abstraction, versioning rigour, OSAL boundary, security architecture — are all necessary. The wireless-specific demands — protocol stack architecture choice, coexistence management, certification artifact discipline — are the additional dimensions that turn a competent MCU SDK team into a connectivity SoC team that can compete commercially. Vendors who treat wireless as MCU-with-a-radio find that their customers route around them at the certification stage, which is far too late to fix.

The wireless SDK is where the strategic value of the SDK shows up most concretely. The certification listings, the coexistence configurations, the validated multi-protocol reference designs — these are the artifacts customers cite in their filings, build their compliance documentation around, and refuse to give up when their next product cycle starts. The competitive moat in connectivity silicon, increasingly, is not the radio. It is the SDK that ships with it.

Wireless certification is not something you plan at the end of the project.

needCode ships wireless SDKs with certified BLE, Thread, and Matter stacks — qualification listings mapped to specific versions, coexistence configurations validated, and multi-protocol reference designs ready to build on. If you’re evaluating wireless SDK partners for a connected product, let’s talk.

Book a free discovery call or get in touch

Further reading

  • Bluetooth Low Energy (BLE) — needCode’s BLE stack implementation, qualification listings, and the SDK integration surface the certification section of this post describes
  • Zigbee / Matter — the Matter certification layer and Thread transport stack covered in the multi-protocol coexistence section
  • Anatomy of a Production OTA Pipeline — the OTA subsystem that wireless SDK release management has to plan around certification windows
  • Security Isn’t a Feature You Add Later — the security architecture layer that sits alongside the wireless stack and shares the same CRA compliance deadline