Not all PoC is the same: app-based PoC vs OMA PoC platforms

In many organisations, push-to-talk over cellular (PoC) starts as a simple idea:    install an app, give users accounts, and they can talk.

During the pilot phase, most PoC solutions look very similar on the surface. Voice goes through, groups can be created, some basic dispatch features are available. If the trial is small enough, almost any PoC solution can “work”. The real difference appears later – when more users, more teams and more sites begin to depend on PoC every day.

This is where it becomes important to recognise that not all PoC is the same.    

Under the same label “PoC”, two very different models are being used in the market today.

Why everything gets called “PoC”

“PoC” has become a broad category. It can refer to:

• a lightweight, app-based PoC service that runs entirely in the cloud, or

• a telecom-grade PoC platform built on OMA PoC standards, designed to be part of an operator or enterprise communication backbone.

On a feature list, these can look similar: group call, individual call, text, maybe video, location, recording.

But underneath, the protocols, architecture, reliability model and integration path are very different. This difference is easy to ignore at the start, yet it has a direct impact on what happens when you move from    PoC testing into live operations.

Two PoC models in practice: app-based PoC vs OMA PoC-based platforms

In real deployments, we broadly see two types of PoC solutions.

1. App-based PoC solutions

These are typically:

• delivered as a cloud service with a mobile app as the main interface

• based on a proprietary protocol specific to the vendor

• optimised for quick onboarding and straightforward push-to-talk usage

• well-suited for small teams or single-site use

They can be a good fit when:

• the number of users is limited

• there is no need for deep integration with existing systems

• PoC is seen mainly as a tool for voice rather than part of a wider operational framework

2. OMA PoC-based telecom-grade platforms

These platforms are built around OMA PoC standards (defined by the Open Mobile Alliance)    and are designed as platforms, not just apps. In general, they:

• follow OMA PoC with SIP interoperability

• are built on scalable, often microservice-based architectures

• support network-level considerations and QoS, not only app-level behaviour

• can be deployed as cloud, private or hybrid solutions

• are designed to integrate with OSS/BSS or enterprise operational systems

• aim to support large-scale, multi-team, multi-site operations

Both models are valid – they simply address different levels of operational demand.

When the difference starts to matter: from pilot to operations

During a trial, it is common to run PoC with:

• one department or a limited group

• a controlled set of devices

• focused, short-term use cases

In this phase, app-based PoC and OMA PoC-based platforms may deliver very similar user experiences.

As soon as you move beyond this, new requirements begin to appear:

• Scaling across teams and sites – adding more users, roles and regions without losing performance

• Operating under real network conditions – maintaining acceptable latency and audio quality even when coverage is weak or unstable

• Integrating with existing workflows – linking PoC with dispatch systems, ticketing tools or other operational platforms

• Managing responsibilities and control – ensuring the right people can speak, listen, monitor and supervise at different levels

• Ensuring traceability and compliance – recording, logging and reporting for critical events or regulated environments

These are not just “extra features”. They decide whether PoC remains a useful communication    tool, or evolves into a reliable part of daily operations.

This is the gap OMA PoC-based, telecom-grade platforms are built to address.

What a telecom-grade PoC platform implies in practice

The term telecom-grade is often used in marketing, but behind it there are some concrete expectations. For PoC platforms, they typically include three main areas.

1. Architecture and standards

A telecom-grade PoC platform is expected to:

• use standardised PoC protocols, such as OMA PoC, for interoperability

• follow a robust, scalable architecture, often using microservices

• support integration with SIP and other telecom or IT systems

This allows the platform to grow with the network and the organisation, instead of being limited by the design of a single monolithic app.

2. Performance and network resilience

In real-world environments, networks are not always perfect. A telecom-grade PoC platform is designed to:

• keep call setup and talk-start times within tight thresholds

• maintain voice quality at an acceptable level under realistic load

• tolerate a defined level of packet loss, especially in challenging radio or LTE/5G conditions

These aspects directly impact how well command, coordination and incident response work in practice.

3. Operational integration and control

Beyond performance, a telecom-grade PoC platform should support:

• hierarchical user structures and role-based dispatch control

• integration with OSS/BSS or enterprise management systems

• centralised monitoring, logging and reporting capabilities

This is what allows communication to be managed as part of an operational system, not just as a set of independent app users.

Questions to ask when evaluating your PoC deployment

If you are planning, running or reviewing a PoC deployment, it may be useful to look beyond the feature list and ask:

• How many users, teams and sites do we expect in the next 1–3 years?

• Do we need our PoC solution to run as a long-term operational platform, or only as a tactical tool?

• What happens to performance if we increase concurrent usage significantly?

• How does the solution behave in weak or fluctuating network conditions?

• Can it integrate with our existing dispatch, OSS/BSS or IT systems?

• What level of control, monitoring and traceability do we need?

There is no single right answer – but the answers can help you decide whether an app-based PoC solution is sufficient, or whether an OMA PoC-based telecom-grade platform is more appropriate.

Where an OMA PoC-based MNO platform fits

An MNO-style PoC platform is a telecom-grade PoC platform built on OMA PoC standards and designed to support operator-level or large enterprise operations.

In the case of POCSTARS MNO (product page), this includes for example:

• OMA PoC protocol with SIP interoperability, running on a microservice-based architecture

• support for up to 20,000 simultaneous voice sessions per node

• optimised performance under weak networks, with continuous voice maintained under high packet loss conditions      (tested up to around 20%) and operational video usable under moderate loss (around 15%)

• latency kept within sub-second call setup and talk-start thresholds in real field conditions

Performance figures are based on POCSTARS’ internal lab and field tests under defined conditions.

These are not just technical parameters – they are what allow PoC to be used as part of an operational backbone, rather than only as a communication tool.

If your organisation is at the stage where PoC is moving from trial to daily operations, this may be a good moment to review which PoC model you are using – and whether your current solution is aligned with your long-term operational needs.

You can learn more about how an OMA PoC-based platform like POCSTARS MNO is designed for operational use: POCSTARS MNO product page

About POCSTARS

POCSTARS Technology Co., Ltd. focuses on mission critical communications and OMA PoC-based platforms for operators and enterprises. The team has been involved in PoC deployments across sectors such as public safety, transportation and other high-demand environments, helping organisations move from project-based PoC to platform-based operation.

Related reading

MCPTT ≠ PMR/LMR: Understanding the Evolution of Mission-Critical Communications