Mission Critical Services – Push to Talk. A case for integration with conventional B2B services?
MCPTT is commonly used in a wide range of different sectors that have stringent safety and service requirements. Integrating MCPTT with B2B services could create additional value and unlock new use cases to support user mobility and role-based assignments. Here’s some of our thinking on the subject.
Push to Talk, or PTT is a long-established service that is commonly found in mission-critical or safety-critical environments – like blue light services, utilities, railways, offshore infrastructure, and other places that have stringent health, safety and security requirements.
It’s essentially a walkie-talkie service, in which an open channel can be maintained – but each device holder must push a button in order to talk with others. Users are typically assigned to groups, which are managed to meet the specific operating requirements of the entity using PTT services.
Not only does PTT have a long history, but it was also an early example of a value-added service that could be delivered over IMS. While it hardly took off as a consumer service, it’s proven to be enduring and essential in those domains with operational safety considerations. 3GPP continues to develop a standardised approach (most recently in R20 – TS 22.179 V20.0.0 / 03/25).
Exploring innovations for vertical use cases
So, with that background, what does this have to do with Gintel? After all, we’re a provider of classical B2B communications services and applications, supporting our MNO and other partners in their different markets.
Well, it’s largely because we’re exploring convergence of non-public networks (NPNs) with public networks (like the PLMN), as well as an emerging class of vertical applications. In this context, classical mobile PBX-based communications can be combined with PTT to support a range of new use cases.
What is PTT? A brief primer.
PTT is essentially a half-duplex service, in which only one party can speak at a time – but all others that are on the same channel or frequency, and in the same groups can hear when someone does. While there are also non-mission critical implementations, our focus is on Mission Critical applications.
Mission Critical Push to Talk (MCPTT) is designed to support services that have safety considerations in contrast to PTT in general, which can also be used in non-critical situations (which means that different level of standards and performance requirements are applicable to those cases).
MCPTT is delivered over mobile networks – which may be private, closed or use privileged access over public networks, sharing infrastructure or being delivered by an MNO as part of a national initiative. Well-known examples include TETRA and GSM-R – both of which are evolving towards 5G. FRMCS, for example, will be the new, 5G-capable version of GSM-R.
Given that delivery over mobile networks, location resolution is also supported, so devices can be tracked and located by the MCPTT service provider. This means that, if for example, a user equipped with an MCPTT-capable device enters a zone that has specific safety requirements, all users can be tracked and monitored. A case in point could be a refinery in which toxic gases represent a hazard. In practice, devices used in such cases may also have detection capabilities.
Similarly, in the railway case, GSM-R has special procedures that include, not only PTT capabilities, but also to support handover requirements between cell towers for the speeds at which trains travel, as well as for interworking with track signalling.
PTT: widely used in different verticals
MCPTT, then, is often a service supported over networks with particular or complex requirements. In general terms, it’s perfect for emergency situations or for those in which background noise would be distracting and, potentially, dangerous, or for when continuous availability is required.
Users include specialists from a wide variety of sectors – not just public safety, blue light and railways, but also sectors like heavy industry, construction and others with significant safety considerations. With MCPTT, every device is reachable because the conversational aspects of the service are temporary, but each device can be in listen mode 100% of the time.
To give another example, some workers on construction sites are equipped with MCPTT devices because they fulfil a specific role. They can communicate when they need to do so, but broadcast capabilities mean controllers can send alerts when action needs to be taken. The device can then be exchanged with the person who takes over this role in the next shift rotation.
So, what does this have to do with traditional B2B communications?
We’ll explore this in more detail in the next article in this series, but a lot of the interest has been driven by alignment between private and public networks. Railway and utility networks are typically closed – and the construction sector has seen considerable investment in private networks that are constructed temporarily to support multi-year projects.
However, a role that may require an MCPTT service may also be a user of a classical business communication service, like our Cloud PBX. They may move between the domains – and, in the critical zone, the MCPTT service could be dominant. So, why not unify the two so that status and availability reflect the real situation? Like this:
- A user belongs to hunt groups (part of a triage team or a department) but when on special duties and in PTT mode, then they must be available for that and no other
- And they can also belong to one or more MCPTT groups – just as they might be assigned to one or more calling (hunt / queue) groups on the conventional network. They should be available when in the restricted domain, but signed out and back into their non-critical groups when they leave it
By doing so, we can set their status as unavailable in the Cloud PBX user groups, so they can’t be disturbed, while ensuring that the MCPTT status is active.
When they leave the zone, or when the PTT device is passed on to another user, the corresponding statuses can be updated. The user can then be reachable in the classical domain when not on critical duties, but unreachable there while available on the PTT device.
It’s all about federating status / availability across devices and domains.
Similarly, roaming into private networks is increasingly discussed. This might not matter when a PLMN is also available in the location covered by the NPN, but there might be good security reasons to switch the connection over. In this case, the services to which the user has access in the PLMN may need to be available in the new domain – which means that policies need to be applied to ensure consistency.
So, there are lots of possibilities – just a few examples of new B2B use cases we’re exploring as we and our partners consider vertical opportunities that go beyond today’s conception of business domains and services.
Interested? Let’s talk.
