Why Operators Need Data-as-a-Service

A connected coffee machine has sent its first packet. The SIM is active, the roaming agreement works, and the connectivity portal shows data moving. From the mobile network's perspective, the deployment is working.

The customer's application team is still waiting for something it can use.

Someone must receive the device protocol, recognize the device, interpret its payload, validate the data, and deliver an event to the right application. Someone must also keep that path running as devices, firmware, cloud services, and customer requirements change.

For many IoT customers, this is where the difficult work begins. It is also where a Connectivity Service Provider (CSP) can offer substantially more value.

Customers already compare operators on SIM and eSIM capabilities, data plans, roaming partners, coverage, connectivity portals, APIs, and private networking options. Those remain important buying criteria. But an operator that also delivers usable application data can participate in a much larger part of the customer's success.

Data-as-a-service extends the operator's offering from moving packets to delivering the data a customer's application needs. With Tartabit IoT Bridge, that can become a simple managed feed or a richer integration service, creating two additional tiers above internet access and VPN connectivity.

Here, data-as-a-service means managed delivery of the customer's own device data. The customer experience is self-service: turn on the service, configure the supported device and application connections, and start using the data.

Connectivity gets the packet there. Integration makes it useful.

Internet access gives a device a path to a reachable endpoint. The customer generally takes responsibility for that endpoint, its security, and the services behind it. A team with an established IoT platform may have everything it needs to do this well.

A private access point name, or APN, and a VPN interconnect provide another useful model: a controlled network path between the device fleet and designated customer infrastructure. The APN determines the device's network access and routing context; the VPN connects the relevant networks. They are related building blocks with different jobs.

That model is appropriate when a customer needs IP connectivity to its devices or already operates the systems that receive their traffic. But establishing a route does not provide a UDP receiver, a CoAP service, a Lightweight M2M (LwM2M) server, a payload decoder, or an enterprise integration.

The customer still needs to build or buy those capabilities. Its teams must coordinate addressing, routing, firewall policies, protocol handling, identity, monitoring, and the final application handoff. A successful VPN setup can therefore mark the beginning of an integration project rather than its completion.

Many customers would prefer a different purchasing conversation: their devices speak a particular protocol, their application accepts a particular event format, and they want an operator to connect the two as a service.

Four levels of service, with more value at each level

Operators can package this opportunity as a four-tier portfolio. Each tier takes responsibility for more of the work between a connected device and a useful business outcome.

A commercial stack of increasing functionality and value. Customers enable and configure the upper tiers through self-service, without a customer VPN. Select the graphic to view it at full size.

1. Internet access

The operator provides connectivity so devices can communicate with internet-reachable services. The customer chooses and operates its ingestion and application infrastructure.

The value is reach: getting a device online with the appropriate coverage, commercial terms, and connectivity controls.

2. VPN access

The operator adds private network connectivity to designated customer infrastructure. The customer gains a controlled route and continues to operate the device-facing services and integrations at the destination.

The value is network control: supporting customers whose architecture requires private IP access, including those with mature IoT operations.

3. Data-as-a-service, silently powered by Tartabit

The operator provides internal, operator-reachable endpoints for supported device protocols such as UDP, CoAP, and LwM2M. The customer enables the data service, selects a supported profile, points its devices at the appropriate endpoint, and configures an application destination. With the device mapping and destination permissions in place, IoT Bridge handles the path between them.

The customer receives data through an interface its application already understands: an HTTP API secured with HTTPS, Azure Service Bus, AWS SQS, or another supported integration. It does not need to establish a customer VPN or run raw IoT protocol ingestion inside its own network for that flow.

This tier is a self-service product. Customers choose from supported protocol and integration profiles with documented payload handling, validation, and output formatting. A standard profile might deliver a consistent event envelope with device identity, timestamps, and selected decoded fields. The customer configures the feed and runs it, without commissioning a bespoke integration project for a standard supported connection.

The customer buys the operator's data service. Tartabit can remain behind the scenes, providing the technology that makes delivery possible.

The value is managed delivery with self-service activation: a usable data feed without a separate customer project to operate the IoT ingestion layer.

4. IoT Bridge as a service, powered by Tartabit

Some customers will want to control more of the pipeline. They can activate a white-label IoT Bridge environment through the operator's offering, under its service brand and with a “Powered by Tartabit” identity.

Customers can configure protocol decoding, transform and enrich payloads, apply processing logic, and choose enterprise integrations. They can route different events to different destinations and use device-management capabilities supported by their devices and protocols. Where required and supported, controlled command and configuration flows can run back toward devices.

Both tiers are self-service. In the simple data service, the customer configures a predefined feed. In the richer service, the customer uses the IoT Bridge workspace to build and evolve its own decoding, processing, and device-to-application workflows. The CSP operates the underlying service in both cases.

The value is flexibility: deeper integration and control without having to assemble and operate the underlying platform from scratch.

Together, these tiers give an operator a practical expansion path. A customer can begin with connectivity, adopt a managed data feed, and later use the broader platform as its requirements grow. The progression is commercial, not a requirement to route traffic through every tier.

Turn it on, configure it, and run

The offering is designed as a self-service product, not around heavy professional-services engagements. Once the CSP has integrated IoT Bridge into its offering, customers can enable the capabilities they need and configure their own connections.

For a supported device and destination, the customer journey is straightforward:

• Enable the service. Choose the managed data feed or the fuller IoT Bridge workspace.
• Connect the devices. Select the supported protocol or device profile and configure the devices to send data to the service endpoint.
• Connect the application. Choose an integration, supply the destination, and authorize delivery with the appropriate credentials or permissions.
• Verify the flow and run. Check the incoming events, then use them in the application and adjust the configuration as requirements evolve.

Self-service still involves configuring the customer's devices, data format, and application access. Ready-to-use profiles and connectors handle the repeatable work; the IoT Bridge workspace gives customers the tools for custom decoding and logic when they need them.

Specialist assistance can help with unusual requirements. Routine activation and operation should be something customers do themselves. For the CSP, the commercial model is a repeatable product subscription that can grow with usage and functionality, without an engineering engagement attached to every new customer.

The first buyers are companies that know their products

A refrigerator manufacturer understands refrigeration, manufacturing, service networks, and product reliability. A commercial coffee-machine company understands beverage quality, machine utilization, maintenance, and the economics of keeping equipment running.

Both may have capable software teams. Neither necessarily wants to build an institutional specialty in cellular IoT protocols, private network interconnects, and device ingestion infrastructure.

For these companies, connectivity supports a product or a service they already know how to sell. The valuable outputs are equipment status, maintenance events, usage information, and other data that their applications can act on. A product team should be able to focus on what those events mean for its customers.

A managed data service separates the device-facing operational technology, or OT, data path from the enterprise IT application interface. The service handles the protocol and data-processing work specified by the customer's configuration. The product company's application consumes a documented feed through its existing API or messaging infrastructure.

Consider a manufacturer with several generations of connected equipment. Newer devices may use LwM2M while older models send proprietary UDP payloads. The application still needs a stable event structure. By decoding and normalizing those inputs before delivery, the service can keep device differences out of the application's everyday processing.

That is a compelling offer to a company trying to launch a connected-product service: its engineering team can spend more time on the product experience and less on maintaining the machinery that moves data into the application.

Startups and smaller businesses need the same capability

A startup may have strong application developers and very little spare infrastructure capacity. Its team can build a customer portal, consume a queue, and process a webhook, but maintaining a private network interconnect and a set of device protocol servers adds a different operational burden.

Small businesses face a similar constraint. They may understand their equipment and customer workflows extremely well while relying on a small internal team or an external developer for software delivery.

For these customers, an operator-managed data service turns an unfamiliar infrastructure project into a familiar application integration. They enable the service, configure the supported device connection, select an event profile, authorize a destination, and work with the data that arrives.

The repeatable integration work is built into the product's profiles and connectors. Customers can configure those capabilities themselves while the CSP operates the shared service. A small team can get on with its application without first commissioning an infrastructure or professional-services project.

The simple tier also gives these teams somewhere to start. They can adopt the full IoT Bridge service when custom transformations, additional destinations, or device-management workflows justify more control.

A clearer boundary for the security team

The security case begins with the interface the customer must expose and govern.

In a VPN-based architecture, the enterprise manages an allowed network path from a potentially large device population to its ingestion systems. A well-designed deployment restricts that path with segmentation, firewall rules, and authentication. It also requires the customer to operate and monitor the device-facing services reachable through it.

With a managed event pipeline, the raw device protocols terminate in the operator's service environment. The customer authorizes a specific application destination, such as a protected HTTPS endpoint or a cloud queue. Its applications receive the agreed events, and the fleet does not need a routed path into the corporate network for that data flow.

The managed service moves the device-facing protocol boundary to the operator. The customer governs an authenticated event interface. Device-leg security and delivery policies must still be designed explicitly. Select the graphic to view it at full size.

For a CISO, this creates a more focused integration to review: who can publish to the destination, which fields are accepted, how credentials are managed, and how activity is logged. Security teams can apply familiar controls around an API or messaging service while the operator takes responsibility for the agreed device-facing controls.

“Sanitized application events” should have a concrete meaning: data checked against configured rules, with expected fields, formats, sizes, and permitted destinations. Decoding bytes into JSON alone does not make a payload trustworthy. Applications must still authenticate their inputs, authorize actions, and validate the data they consume.

Security also needs to cover both legs of the journey. Raw UDP is not encrypted by default, and a private APN is not a substitute for end-to-end application encryption. Device-to-service protection must match the device's capabilities and the deployment's requirements; service-to-application delivery uses authenticated, encrypted connections.

The architectural benefit is a narrower customer integration boundary and clearer operational ownership. That can make an IoT deployment easier to assess, operate, and support as the fleet grows.

The market is already offering more than connectivity

Operators can see this direction in existing commercial offerings.

1NCE OS includes tools for connected-product development and operations. Its IoT Integrator documents UDP, CoAP, and LwM2M device inputs with HTTPS webhooks and AWS IoT Core on the application side. That makes the device-to-cloud handoff part of the connectivity proposition.

Onomondo's integrations and data routing likewise move integration work into the network. Its Connectors add cloud-facing security and protocol handling in the network core before forwarding data to a selected endpoint. Onomondo also offers VPN options, illustrating how managed delivery and private networking can coexist in an operator's portfolio.

Soracom offers similar building blocks. Soracom Beam can forward UDP device data as HTTP or HTTPS requests, while Soracom Funnel delivers device data to supported cloud services, including AWS IoT Core. Funnel's documented setup lets customers select the destination, configure credentials, and enable the service for a SIM group in the Soracom User Console. It is a practical example of cloud integration packaged as a capability customers can activate and configure themselves.

These offerings provide concrete examples of the opportunity. Our view is that CSPs can make more of the device-to-application path available as a self-service product, so customers can enable useful capabilities as their deployments grow.

Tartabit already participates in this model. 1NCE's documentation for the Tartabit integration plugin describes IoT Bridge integration with Azure, AWS, and GCP. This is an existing example of an operator extending its service through a specialist integration platform.

For another CSP, the opportunity is to shape that capability into its own portfolio: a self-service managed feed for customers who want simplicity, and a branded self-service integration environment for customers who need more control.

Give the sales team something more valuable to sell

Connectivity pricing is easy to compare. The work needed to turn device traffic into a reliable application feed is much harder for a customer to absorb.

Packaging that work creates several commercial opportunities for an operator.

A service attached to an application outcome. The conversation can include the event the customer needs to receive, the backend it uses, and the operational responsibility it wants to hand over. Coverage and price remain relevant, but the operator can also compete on how much work it removes from the customer's deployment.

More paths to recurring revenue. A managed data feed can be offered as a connectivity add-on. A broader IoT Bridge service can support a premium tier. Commercial terms can reflect active devices, processing and message volumes, destinations, and support requirements, with clear allowances that keep the offer understandable.

Repeatable self-service onboarding. Customers activate tested protocol profiles, decoders, and destination templates from the product. The operator can support a growing customer base with reusable integrations and documentation, while reserving specialist assistance for cases that need it.

A relationship that can grow with the customer. A second product line, another cloud destination, or a new device-management requirement creates an opportunity to expand the service. The operator has a reason to stay involved as the customer's application evolves.

These are opportunities to test and measure, rather than guaranteed improvements in margin or retention. The strongest evidence will come from customers reaching production sooner, using the service beyond a pilot, and expanding the scope of their deployments.

Launch a self-service data product

An effective first offer can be deliberately focused: a supported set of device protocols, ready-to-use event profiles, and connectors for the application destinations customers most often request. Package those capabilities with clear setup instructions so customers can turn them on and run.

The customer-facing proposition should be easy to explain: enable the service, point your devices at the operator's endpoint, configure your application destination, and receive events.

The CSP and Tartabit establish the network attachment and service environment behind that experience. That provider-level integration makes the product available across customers. Customers then configure their own supported profiles, device settings, destinations, and delivery permissions through self-service. “Internal endpoint” means an endpoint the device can reach through the CSP's configured network service.

The service definition should also explain what happens when something goes wrong. A destination can be unavailable. A device can send an invalid payload. Credentials can expire. Customers need clear expectations for delivery status, buffering where provided, retry limits, duplicate handling, and escalation. A pipeline cannot recover a UDP packet it never received, so the chosen device protocol and service design must match the application's reliability needs.

Validate the self-service journey with a real device and a real customer destination. Measure how many customers complete setup themselves, time to the first usable event, time to production, and support effort. Use that feedback to improve the product's profiles, documentation, and configuration experience, then expand the supported integrations.

This gives the operator a repeatable product to add to its portfolio while keeping ownership of the brand and the customer relationship. Each new customer can activate an existing capability and get started.

Make usable data part of the operator's offer

The companies building connected refrigerators, coffee machines, and other products already understand the value they want to deliver. Startups and small businesses often have the same clarity. What they lack is the accumulated IoT connectivity knowledge and operational capacity needed to join their devices to their applications.

An operator can make that expertise available through a self-service product customers turn on and run.

Internet access provides reach. VPN access provides a controlled network path. Data-as-a-service provides a managed application feed customers enable and configure themselves. IoT Bridge as a service gives them a self-service workspace to shape that feed into richer integrations and device workflows.

Each step adds functionality and gives the customer another reason to choose the operator. Tartabit IoT Bridge supplies the protocol handling, decoding, and enterprise integration capabilities behind the upper tiers, allowing CSPs to build a value-added offering around the customer outcomes they want to support.

Add self-service data delivery to your connectivity portfolio. Talk to Tartabit about offering managed data feeds and a branded IoT Bridge workspace that your customers can enable, configure, and run.

Explore IoT Bridge for network operators for more on the platform and operator use cases.