ioX-Bridge LoRaWAN Network Server
Connect Your Gateways. Send the Data Where It Needs to Go.
A LoRaWAN network server is the piece between your gateways and your application. It handles the join, keeps track of device sessions, deduplicates the same uplink arriving through three gateways, decodes the payload, and delivers the result somewhere useful. ioX-Bridge is that layer, hosted and managed, with a console for running it.
It is built to the LoRaWAN specification rather than around it. Gateways connect over the ordinary Semtech UDP packet forwarder or over Basics Station with TLS, whichever your hardware speaks. Payloads decode through JavaScript functions or Cayenne LPP. Data leaves over HTTP or MQTT, and the API is available as REST or gRPC. Nothing in that list is proprietary, which means nothing in it locks you in.
- US915, EU868 and AU915, each on its own endpoint
- Basics Station over TLS with a client certificate generated per gateway, or the UDP packet forwarder if that is what your gateway runs
- A vendor template catalog of tested decoders, or write your own in JavaScript
- Uplinks delivered to your endpoint over HTTP, or to your broker over MQTT
- A delivery log showing the endpoint, the HTTP status and the latency of every integration attempt
- REST and gRPC, with a read-only key option for anything that only needs to look
No proprietary anything
Built to the Standard, Not Around It
Every interface ioX-Bridge exposes is one you have seen before. That is deliberate. A network server that invents its own protocols is a network server you cannot leave, and anybody evaluating one for a deployment that has to run for years is right to check.
| Where it connects | What it speaks |
|---|---|
| Gateways in | The Semtech UDP packet forwarder, or Basics Station over a secure WebSocket with a client certificate generated for that gateway. Gateways connecting over plain, unencrypted WebSocket are refused. |
| Regions | US915, EU868 and AU915, each with its own UDP port and its own Basics Station endpoint, so the region a gateway is configured for is unambiguous. |
| Devices | Over-the-air activation with a DevEUI and an application key, the way the specification describes. |
| Payloads | JavaScript decode and encode functions taking the payload bytes and the port, or Cayenne LPP where the device already encodes it. |
| Data out | HTTP POST to your endpoint with your own headers, or MQTT over TLS to a topic per device and event type. |
| Programmatic access | REST over HTTPS, or gRPC, offering the same operations. |
Certificates for Basics Station gateways are generated in the console and are valid for a year. Note the date and generate the next one before it lapses; a certificate that quietly expires is the most common way a healthy gateway goes dark.
Trusted by customers across multiple industries
What ioX-Bridge Handles
The part that saves the site visit
When Data Does Not Arrive, You Can See Where It Stopped
Something not arriving is the normal failure in this business, and the expensive part is not the fix. It is the two days of guessing, and the drive out to a site where the problem turned out to be a typo. ioX-Bridge exposes each stage separately, so you work top down and stop at the first one that is empty.
| Stage | Where you look | What an empty result tells you |
|---|---|---|
| Is the gateway talking? | The gateway's Dashboard tab | Last seen updates roughly every thirty seconds on a healthy gateway. If it says never seen, the address, the port or the region does not match what the gateway is configured for. |
| Is the device transmitting? | The gateway's LoRaWAN frames tab | Power-cycle the device and watch. No join request at all means coverage or the wrong region, not a platform problem. |
| Did it join? | The device's Events tab | A join request in the frames but nothing here means the DevEUI does not match. A join error means the application key does not. |
| Is the payload decoding? | The uplink event's decoded object | Raw payload present but the readings wrong means the profile does not match the hardware or its firmware. |
| Did it get delivered? | The network's Integration events tab | Every attempt with its endpoint, HTTP status and latency, failures tagged, and the full JSON downloadable. A 4xx here is your endpoint, not ours. |
The delivery log keeps recent history rather than an archive, so it is a diagnostic tool rather than a system of record. It expires after at most 31 days. If you need the events themselves kept, keep them at your end.
Where it sits
A Network Server With an Application Layer Already Attached
A network server gets data off the radio and hands it to something. What that something is remains your problem with most of them: accounts, dashboards, alerting and the team to keep it all running. Choosing a network server usually means choosing to build everything above it.
ioX-Bridge does not assume that. Device profiles in the catalog can decode straight into ioX-Connect's own format, so the platform above is already wired to the network server below it. You can take the network server on its own and connect whatever you like to it. You can also take the layer above and skip the integration project.
That layer is ioX-Pulse: device management, dashboards, alerting, and customer accounts you can put your own brand on.
The honest version
What Running Your Own Network Server Costs You
Plenty of teams run their own, and for some of them it is the right answer. It is worth being clear about what the two choices actually differ on.
| Running your own | Hosted with ioX-Bridge | |
|---|---|---|
| Control | Total. The source, the schema, the deployment. | The interfaces, not the internals. |
| Cost shape | Cheap to install, and then a person's attention forever. | A subscription, and nobody's evenings. |
| Upgrades | Yours to schedule, test and roll back. | Handled, and you find out from the changelog. |
| When it breaks | Yours to diagnose at 2am. | Escalate it. |
| Data residency | Wherever you put it. | Where we run it. Ask us before you assume. |
| Leaving | You already have everything. | Standard interfaces throughout, so your gateways and decoders go with you. |
The case for running your own is strongest when the network server is the thing you are selling, or when residency rules decide it for you. If it is plumbing under a service you sell, the operational cost usually outlives the enthusiasm.
Straightforward Plans, Published Prices
Four plans, priced by the number of devices you connect pick a starter plan, and move up a plan when you need more devices; extra capacity is available immediately.
Bridge-Lite
Bridge-Core
Bridge-Edge
Bridge-Pro
Common Questions About LoRaWAN Network Servers
It sits between your gateways and your application. It handles device activation, tracks session state, discards duplicate copies of an uplink that reached several gateways, manages data rates, decodes the payload if you have given it a decoder, and delivers the result to wherever you have told it to. Gateways are radios; the network server is what makes a set of them behave like a network.
A network server moves data off the radio and hands it on. An IoT platform is what people log into: device inventory, dashboards, alerting, reporting and user accounts. They solve different problems and most deployments need both. ioX-Bridge is the network server and ioX-Pulse is the platform.
Any standards-compliant LoRaWAN gateway. If it runs the Semtech UDP packet forwarder, point it at your region's address and port. If it runs Basics Station, generate a client certificate in the console and set the gateway's LNS URI to the secure WebSocket endpoint for your region. No proprietary gateway is required and no specific vendor is preferred.
Use Basics Station if your gateway supports it. It runs over TLS with a client certificate issued for that specific gateway, so the connection is both encrypted and authenticated, and gateways attempting to connect without a certificate are refused. The UDP packet forwarder is supported because a great deal of deployed hardware runs it, not because it is the better choice.
Two ways, configured per network. An HTTP integration posts each event to your endpoint as JSON, with any headers you need, and you can pause and resume it without losing the configuration. Or subscribe over MQTT with TLS to a topic per device and event type. Both carry the same JSON: device identity, the raw payload, the decoded object, and signal quality.
Yes. Write a JavaScript decode function that receives the payload bytes and the port and returns named values, and whatever you return appears as the decoded object on every delivered event. Cayenne LPP is supported where a device already encodes it, and the vendor template catalog carries tested decoders for hardware already in it.
No. ioX-Bridge is a network server in its own right and you can connect whatever application you like to it over HTTP, MQTT or the API. The reverse is also true: if you want the layer above without building it, ioX-Pulse is already wired to it.
US915, EU868 and AU915, each with its own endpoint. A gateway's configured region has to match its frequency plan; when it does not, packets are dropped without an error, which makes it worth checking first when nothing is arriving.
Talk to us. ioX-Bridge environments are provisioned rather than signed up for, so there is no self-serve checkout for it. Tell us your gateway models and your regions and the conversation starts from something concrete.
Ready to Connect?
Tell us what hardware you have and where it is deployed. If ioX-Bridge is not the right fit, we would rather say so on the first call.
Contact Us
Our customer service representative helps you to understand what we offer for your business goals.
