M C O P

Dr. Fidel Liberal

fidel.liberal@ehu.eus

Open Ecosystems in Public Safety 

Communications: MCOP Lessons 

Learned and Future Steps
2

DISCLAIMER

This presentation was produced by guest speaker(s) and 

presented at the National Institute of Standards and 

Technology’s 2019 Public Safety Broadband Stakeholder 

Meeting. The contents of this presentation do not 

necessarily reflect the views or policies of the National 

Institute of Standards and Technology or the U.S. 

Government.

Posted with permission
3/27

MCOP project

Outline

Problem addressed

MCOP Approach

Main expected outcomes

– Technical

– Others

Foster innovation...

– Company interest mainly

Build a community
4/27

MCOP project

Problems addressed

Vo LTE e MBMS

Pro SE MC QCI

Ge ne ra l Purpo s e

LTE c a p a b ilit ie s

Operating 

System

Connection 

Manager

Public API

eMBMS

Vendor specific Radio Access

Radio Layer Access 

SIM

operations eMBMS operations

ProSE

ProSE operations

Monolithic

MCPTT Application

No SIM

access

No APN Proprietary Proprietary access

Proprietary Proprietary OS vendor

Proprietary

OS vendor

OAM

(OTA)

Proprietary

OS vendor

defined

OAM

(OTA)

Hardened

Platform

LTE

IMSI AUTH Different OAM &

OTA procedures

Monolithic proprietary apps 

Proprietary APIs to MC capabilities

Dependence on internal OS APIsó OEM only

Challenge 1

UE 

architecture vs.

Challenge 2

complex

ecosystem

EUTRAN eMBMS EPC

IMS/SIP CORE

MVNO

Multi-vendor

Innovative

Developers

Community

MCPTT

SERVICE

PROVIDER

MCPTT ASs

EMBMS MIDDLEWARE

OEM INTEGRATION

APP

VENDOR

MCPTT CLIENT

GENERAL PURPOSE OS

LTE CHIPSET

CHIPSET

MANUFACTURER

UE

VENDOR

OS

VENDOR

PSOs

Vendors

UE

VENDOR
5/27

MCOP project

Summary: UE Integration burden

Hundreds of combinations (different release cycles)

Never-ending expensive effort

EMBMS MIDDLEWARE

LTE CHIPSET CHIPSET

MANUFACTURER

OS

VENDOR

LTE CHIPSET LTE CHIPSET <10s

10s

<10s

10s

EMBMS MIDDLEWARE Other UE capabilities

MCPTT CLIENT A MCPTT CLIENT B MCPTT CLIENT C

UE

VENDOR

1

UE

VENDOR

n

UE

VENDOR

2

No SIM

access

No APN

access

Proprietary Proprietary Proprietary

No SIM

access

10s

GENERAL PURPOSE OS1 GENERAL PURPOSE OS GENERAL PURPOSE OS GENERAL PURPOSE OS2

MC UE Telco OS Chipset M(V)NO

Relative size of MC and commercial industries

X

Con$nuous	

tes$ng	of	live	

systems	

Responder	

prac$$oner	

acceptance		

Terminal	

tes$ng	and	

cer$fica$on	

Applica$on	

tes$ng	and	

cer$fica$on		

Service	

tes$ng	&	

cer$fica$on	

Protocol	

tes$ng	&	

cer$fica$on			

Wireless	

tes$ng	&	

cer$fica$on		 Con$nuous	

tes$ng	of	live	

systems	

Responder	

prac$$oner	

acceptance		

Terminal	

tes$ng	and	

cer$fica$on	

Applica$on	

tes$ng	and	

cer$fica$on		

Service	

tes$ng	&	

cer$fica$on	

Protocol	

tes$ng	&	

cer$fica$on			

Wireless	

tes$ng	&	

cer$fica$on		

Con$nuous	

tes$ng	of	live	

systems	

Responder	

prac$$oner	

acceptance		

Applica$on	

tes$ng	and	

cer$fica$on		

Protocol	

tes$ng	&	

cer$fica$on			

Wireless	

tes$ng	&	

cer$fica$on		

Con$nuous	

tes$ng	of	live	

systems	

Responder	

prac$$oner	

acceptance		

Applica$on	

tes$ng	and	

cer$fica$on		

Protocol	

tes$ng	&	

cer$fica$on			

Wireless	

tes$ng	&	

cer$fica$on		

Con$nuous	

tes$ng	of	live	

systems	

Responder	

prac$$oner	

acceptance		

Terminal	

tes$ng	and	

cer$fica$on	

Applica$on	

tes$ng	and	

cer$fica$on		

Service	

tes$ng	&	

cer$fica$on	

Protocol	

tes$ng	&	

cer$fica$on			

Wireless	

tes$ng	&	

cer$fica$on		

Con$nuous	

tes$ng	of	live	

systems	

Responder	

prac$$oner	

acceptance		

Terminal	

tes$ng	and	

cer$fica$on	

Applica$on	

tes$ng	and	

cer$fica$on		

Service	

tes$ng	&	

cer$fica$on	

Protocol	

tes$ng	&	

cer$fica$on			

Wireless	

tes$ng	&	

cer$fica$on		

Con$nuous	

tes$ng	of	live	

systems	

Responder	

prac$$oner	

acceptance		

Applica$on	

tes$ng	and	

cer$fica$on		

Protocol	

tes$ng	&	

cer$fica$on			

Wireless	

tes$ng	&	

cer$fica$on		

Lose-Lose for MC industry and users

Unbalanced relationship

Cross (re)certification
6/27

MCOP project

MCOP approach

Open APIs

Apache 2 

License

MCPTT SDK

Free/Open

Online

Testing

System

Vo LTE e MBMS

Pro SE MC QCI

Ge ne ra l Purpo s e

LTE c a p a b ilit ie s

Operating 

System

Connection 

Manager

Public API

eMBMS

Vendor specific Radio Access

Radio Layer Access 

SIM

operations eMBMS operations

ProSE

ProSE operations

Monolithic

MCPTT Application

No SIM

access

No APN Proprietary Proprietary access

Proprieta

ry

Proprieta

ry

OS vendor

Proprieta

ry

OS vendor

OAM

(OTA)

Proprietary

OS vendor

defined

OAM

(OTA)

LTE

IMSI AUTH Different OAM &

OTA procedures

Vo LTE e MBMS

Pro SE MC QCI

Ge ne ra l Purpo s e

LTE c a p a b ilit ie s

Operating 

System

Connection Manager

Public API

eMBMS

Vendor specific Radio Access

Radio Layer Access 

eMBMS operations

ProSE

ProSE operations

Hardened

Platform

MCOP Open Source SDK

Demo APP 3rd Party App 

MCOP Unified Open Application API 

OAM

(OTA)

OAM

(OTA)

MCOP OAM/OTA OPEN ACCESS 

Clear single interface

MCOP Integration API 
7/27

MCOP project

How it works

• Technology neutral API definition OPEN, for ANY platform

• De-coupling/isolation for different business models

• Every component seamlessly provided by a different vendor

• Licensing and release cycles

• No constraint

• Access to prioritized resources

• OEM only if needed

• Mutual authentication framework

• Alignment with Android and under-standardization APIs

• Future-proof

«IRemoteService AIDL» «IRemoteService AIDL»

«Binder framework»

MCPTT Application MCOP SDK Plugin i,j,k...

Stub.Proxy Stub Stub.Proxy

IBinder

Kernel binder driver

Stub

OAM Certificate Whitelist

provisioning
8/27

MCOP project

MCOP APIs

Open & free

– Apache 2

Technology 

Neutral
9/27

MCOP project

MCOP project, Objectives

Fostering innovation by targeting common needs of the industry

Traditional telco

Former OTT PTT solutions providers

Small integrators

PSOs’ IT departments

Newcomers

Mission

Critical

Open

Platform

• O1. Gather and agree on common requirements for the platform from 

industry fora 

• O2. Analyze architecture problems. 

• O3. Define an open platform including different level APIs. 

• O4. Validate the architecture and intermediate APIs 

• O5. Deploy and maintain a sustainable live on-site and online testbed 

• O6. Disseminate the results

Possible

enhancements
10/27

MCOP project

Current status

• Comprehensive 3GPP MCPTT Rel14 support

• 4th ETSI MCX Plugtest

• Multivendor

• Different GUIs

• Different SDKs

• Different eMBMS/Connectivity/Configuration

• Quick prototyping: Tailored app

• Head-up-display for firefighters

• Quick prototyping 

GUI

SDK

plugins

GUI

SDK

XP8

plugins

XP8 plugins

APP
11/27

MCOP project

Expected Impact

PSOs

– Improve MCPTT Awareness and encourage informed

decisions/purchases

– Easier and planned product integration

– Avoid single vendor dependence

– Hands on trial and training

MC Apps developers & new practitioners

– Open Community and standard troubleshooting platform

– Standardization/normalization/certification/conformance testing

– Shared knowledge, reference implementation and MC-grade 

experimentation platform

– Reduce production costs and open integration possibilities

– Un-tie APP level from specific HW platform

Events, advocacy

APIs vs. SDK

NEM, SONIM
MCOP: Lessons Learned and Next 

Steps

Jani Lyrintzis - Bittium
MCOP – Lessons Learned and Next Steps

Lessons Learned

• Bittium and other MCOP partners have already realized and leveraged 

tangible benefits achieved by using MCOP APIs and SDK in integrating and 

testing Mission Critical applications, the overall integration, testing and 

verification effort is significantly reduced and simplified.

• With MCOP the focus can be placed in optimization of value-added functions 

such as user experience and system reliability, rather than in creating and 

integrating proprietary APIs and other tedious tasks.

13 © Bittium - 2019
MCOP – Lessons Learned and Next Steps

Next Steps

• Bittium is a strong proponent of open technologies such as MCOP, whose biggest (and 

perhaps the only) problem currently is wider industry adoption.

• We see that in the future open APIs for Mission Critical Communications could and 

should be integrated in the work of standardization and industry bodies such as 3GPP, 

TCCA and PSTA.

• Moreover, it should be adopted by certification bodies such as GCF and PTCRB, so that 

testing of the APIs would be part of the normal device certification process.

• Yet another way to promote open APIs and provide wider interoperability of mission 

critical applications could be BroadWay, a joint initiative between 11 European 

countries for pan-European PPDR (Public Protection and Disaster Relief) system.

14 © Bittium - 2019
MCOP Southbound API for MBMS

Bartolo Scanavino

ENENSYS/Expway Telecom Market Product Director

15
MBMS Critical Communication Use Cases

Situation Awareness with

MC Data

Firemen can receive building 

layouts and floor plans on 

their devices including the 

live positions of their 

teammates.

eMBMS pushes maps and 

location updates 

continuously to the team in 

the field.

Managers can see in realtime which members of the 

team need assistance.

Enriched details with MC

Video

When there is an accident 

the first responder arrives 

and few people go inside to 

check the situation and 

report back to the team. 

The live camera stream is 

streamed via eMBMS in the 

surrounding area.

With the support of video 

the team can make a better 

assessment of the actual 

situation.

Mining communications

with MC-PTT

A push-to-talk group is 

created between groups or 

all the people working in the 

mine.

MCPTT over eMBMS is 

activated to send the 

downlink audio stream.

Improved reception quality 

enhances the communication 

between teammates, with 

no network congestion 

16
Southbound API for MBMS

• delivery of Public Safety services with MBMS is : 

• Congestion Free (MBMS spectrum is allocated and not subject to contention 

with Unicast traffic)

• Highly Reliable (improved coverage thanks to SFN and NoACK)

• Efficient (single bearer from the MBMBS server to all users of the group)

• Synchronized (all UEs receive data at the same time)

• The MBMS Client exposes an API to the MCOP Open Source SDK, enabling 

MBMS reception and monitoring

• The MBMS Client runs as a standalone service in UE and can handle multiple 

applications 

17

BM-SC MBMSGW

MME

E-UTRAN SGi-mb

SGmb

Sm

M1

Application

Service

Provider xMB

M3

MBMSaware

Application

UE

Modem

MBMS

Client MBMS-API

Application Service Discovery

TS26.346 including broadcast and unicast
What the MBMS Client provides

• The MBMS Client monitors the MBMS reception quality and notifies it to the application

• It provides an API to get EGCI and list of MBMS SAI for location reporting, and notifies the 

application whenever there is a change

• It provides an asynchronous API to open/close MBMS bearers and access the embedded 

group communications

• The received IP packets are made available on a network interface

18
MCOP eMBMS API

• MCPTT and MCVideo can both be managed by current version of the APIs

• In release 15, FEC and ROHC were added, the MCOP APIs will be updated to support 

these important features 

• In release 16 MBMS MCData was defined using the File Download delivery method, the 

MCOP APIs will be extended to control and monitor file reception

What’s next?

19
20/27

MCOP project

Lessons learned

Technical entry barriers still exist

– SIM storage

– IPSEC

– Need to involve UE vendors / SIM manufacturers

Conveying the right message

– Inmediate needs vs long time benefits

SDK vs. APIs

What is your business model?

How to build a (Public Safety) real community

– Open source...
21/27

MCOP project

Lessons learned

Open APIs message
22/27

MCOP project

What’s next!!!!

• Next steps in MCOP

• Focusing on API definition

• Creating MCOP API steering committee

• Evolution / convergence of MCOP APIs

• MCData/MCVideo APIs COMING SOON

• Pushing supporter program
23/27

MCOP project

Coming soon

Hackathon
Critical communications for all professional users

TCCA

www.tcca.info

Contact: admin@tcca.info, +44 191 231 4328
Critical communications for all professional users

25

The Critical Communications Association

Supporting open and 

standardised mobile 

critical communications 

technologies and 

complementary 

applications. 

Catalysing competitive 

multivendor markets

worldwide through open 

standards and 

harmonised spectrum.

Members are end users, 

operators, industry and 

other stakeholders 

globally sharing 

knowledge and 

experience.

Collaborative working 

across the critical 

communications 

ecosystem to develop 

and drive the most 

effective solutions for all.
Critical communications for all professional users

26

Public Safety Broadband Eco-System

Global LTE 

Eco-System

Global Public 

Safety LTE 

Eco-System

Vendor „C“ LTE 

Eco-System

Vendor „B“ LTE 

Eco-System

Operator „A“ 

LTE Eco-System
Critical communications for all professional users

27

Growing the Eco-System

We can grow the eco-system by:

• Using Common Open Standards

• Using Common Open APIs

MAKE THE PUBLIC SAFTEY 

ECO-SYSTEM GREAT
Dr. Fidel Liberal

fidel.liberal@ehu.eus

M C O P

NIST PSIAP 

FEDERAL AWARD ID: 70NANB17H151 Mission

Critical

Open

Platform