1. Introduction

1.1 Problem Statement

Today’s emergency responders have many technologically advanced tools at their disposal. These tools allow them to perform their lifesaving duties more efficiently and safely. The tools range from mapping, presence availability, body sensors, secured communications to unmanned vehicles carrying communication stations. Out of all the ways to communicate in the present day, voice communication is still the predominant way of communication for emergency responders. Currently, approximately 80% of communication for emergency responders is voice communication. Out of that, approximately 80% is group communication (rather than private calls and other options). This will continue to be true in the coming years, as voice will still be very important for mission critical communications.

The wireless telecom industry recognized the need for emergency responders to have access to group communications. In response to this need, they created Mission Critical Push-to-Talk, or MCPTT, in the 3GPP standards (3rd Generation Partnership Project) for the next generation of voice communications for emergency responders. MCPTT, which is the only standardized method for Push-To-Talk, was created for many reasons. One is to provide an interoperable solution that will allow emergency responders to communicate via Push-To-Talk which is agnostic to network access, devices, and its application services. Second is to provide mechanisms to ensure Mission Critical communications on 4G networks beyond the existing best effort non-mission critical approaches. But, the MCPTT ecosystem resulting from the 3GPP definition is very complex. There are still too many proprietary interfaces and layers in a user device, such as a smartphone. To get around this, many non-standard solutions have been developed. However, these solutions are not fully mission critical-capable and they probably would not receive the standardized priority on the network. Plus, they are not interoperable across devices, applications, and networks. In other words, every emergency responder participating in a mission needs to have the same application and software version (and possibly even the same hardware) in order to communicate. In summary, the problem is that there are no MCPTT applications available and it is simply too difficult to create them. At least that was the situation until MCOP.

MCOP, or Mission Critical Open Platform, is an ongoing project to eliminate the barriers that prevent people from creating MCPTT applications. MCOP found ways to create APIs to move past proprietary layers in the Android OS, as well as in most hardware situations. MCOP then developed an SDK which utilizes these APIs, so developers can easily and quickly build a functioning MCPTT application. As the name of MCOP implies, the SDK is open source and readily available for download and use by application developers. In addition, MCOP has created a free and openly available online portal and testbed that aids developers in testing their MCPTT application. A person just needs to schedule time on the testbed.

1.2 Objectives

The overall aim of this challenge is to increase the availability of MCPTT standard-compatible applications for emergency responders to use. This will be accomplished by exposing people to the MCOP SDK and testbed. Using the tools of MCOP, any individual or team of people can make a functioning MCPTT application. The expected result from participants of this challenge is a fully functioning and fully compliant MCPTT Android application created using the MCOP SDK that allows emergency responders to communicate while their smartphone is on an LTE network.

In this challenge, many participants will only have access to normal everyday smartphones. When equipped with a standards-compliant MCPTT application created with the MCOP SDK, these everyday smartphones can make MCPTT calls in an excellent manner in many different situations. However, emergency responders may not be able to use a basic smartphone while performing their duties during a life-threatening emergency. Making an MCPTT application that can handle emergency situations is highly encouraged for this challenge as a higher-level endeavor, but participants should focus on making an effective application for non-emergency situations as a first step. To aid participants in this area, two non-emergency scenarios or use cases have been defined. MCPTT applications will be judged based on how well they are able to accommodate these use cases:

1) Firefighters — Of the many duties of firefighters, one is to inspect buildings to ensure that they are up to code. For example, a firefighter may inspect a school to make sure there are adequate fire alarms, functioning fire extinguishers, clutter-free emergency exits, etc. For the “Firefighter” scenario, imagine two firefighters inspecting a large school building. The firefighters split up and go down different areas of the school to save time. They need to be able to communicate in a basic MCPTT private call while performing their duties.

2) Law Enforcement — Many large law enforcement forces have their own Land Mobile Radio, or LMR, systems in order to communicate. However, many officers are also turning to smartphones in addition to their LMR radios. In a typical traffic stop situation, an officer is not going to approach the vehicle while looking down at a smartphone. The officer, for safety reasons, needs to stay alert and watch the passengers in the vehicle. However, there are times when group communications via a smartphone would be beneficial. In the “Law Enforcement” scenario, imagine a group of law enforcement officers that have been assigned to perform security for a popular football game. It is hours before the game starts and fans have not started to arrive. The assigned officers need to meet at Gate 1 of the stadium to go over details of their assignment;. however, the meeting time and location have now changed. The officers need to communicate via an MCPTT group call to inform the team of the new meeting location and time.

The defined use cases are simple; participants are encouraged to expand on the use cases as well as add functionality for other more complex use cases. For example, an MCPTT application may include some form of voice-to-text technology. Or, an MCPTT application adds more standard-based functionality such as the ability to upgrade a basic MCPTT call to an emergency MCPTT call. Participants are not required to include added functionality, and there are no requirements for specific functionality above and beyond the two defined use cases of “Firefighters” and “Law Enforcement” from above. However, applications that include added functionality have the possibility to score more points during the judging process.

1.3 Resources


2. Evaluation criteria

Participants must adhere to the basic application requirements listed below. Failure to do so may result in non-grading of the application.

Criteria #0: Basic Requirements

Rating: Pass/Fail

  • The application must be able to make a standards-compliant MCPTT group call.[1] (Pass/Fail)
  • The application must be able to make a standards-compliant MCPTT private call.[2] (Pass/Fail)

[1] 3GPP TS 24.379: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=2953

[2] 3GPP TS 24.380

Criteria #1

Rating: 20/100

  • Effectiveness: Relevance to the defined use cases and the degree to which emergency responders can recognize how the created application is appropriate or not for their needs in the defined use cases
    • Firefighter — how effective is the application in making a basic MCPTT private call while performing a building inspection
    • Law Enforcement — how effective is the application in making a basic MCPTT group call before meeting at a newly designated location

Criteria #2

Rating: 20/100

  • Innovative use of application style and screen orientation to support use cases
  • Appearance: Degree to which the application utilizes style and screen orientation

Criteria #3[1]

Rating: 20/100

  • Overall usability and design:
    • Learnability (degree to which the created application can be used by emergency responders to achieve specified goals of learning to use the product or system with effectiveness, efficiency, freedom from risk and satisfaction in a specified context of use.)
    • Operability (degree to which the created application has attributes that make it easy to operate and control.)
    • User error protection and permissions (degree to which the application protects users against making errors or exposing sensitive information.)
    • User interface aesthetics (degree to which a user interface enables pleasing and satisfying interaction for the user.)

Accessibility and Ergonomics (degree to which the created application can be used by people with the widest range of characteristics and capabilities to achieve a specified goal in a specified context of use.)

[1] From ISO 25010: https://iso25000.com/index.php/en/iso-25000-standards/iso-25010?limit=3&limitstart=0

Criteria #4

Rating: 40/100

  • Creativity/ Extra functionality (degree that the application adds extra functionality beyond a basic MCPTT application). Participants must list extra functionalities that are implemented and propose how those can be demonstrated. Below is a list of examples of extra functionalities that a participant could possibly consider, but the list is not exhaustive nor is it a list of required extra functionality:
    • Voice to text capability — there are some situations when an emergency responder is not able to talk or to play the incoming audio during an MCPTT call. Example: The emergency responder still needs to be able to understand what is being said by the speaker during an MCPTT call but without the use of audio.
    • Enhancements for use during emergency situations — in some emergency situations, a basic smartphone is not sufficient for MCPTT communications. Example: The emergency responder needs both hands to perform his or her duties, but still needs to communicate during an MCPTT call.
    • Adding location capability — in some situations, knowing the location of the emergency responder is important. Example: A dispatcher needs to deploy an EMT to a location inside a park where there is no specific address. The dispatcher must be able to find nearby EMTs.
    • Upgrading and downgrading MCPTT calls — in some situations, an emergency responder may want to upgrade a basic MCPTT call to an MCPTT emergency call or an MCPPT imminent peril call. After the situation deescalates, the emergency responder may want to downgrade the call back to a basic MCPTT call. Example: A law enforcement officer is communicating in an MCPTT group call while on patrol, but then witnesses a crime. The officer wants to quickly and easily upgrade the call to accommodate the new situation. After the arrest has been made, the officer wants to downgrade the call back to a basic MCPTT call.
    • Creating temporary groups — in some situations, an emergency responder may want to create a temporary MCPTT group or create a group on the fly. Example: 3 types of emergency responders arrive on a scene (fire, law enforcement, EMT) and they want to communicate via an MCPTT group call using a newly formed and/or temporary group. Members of the group need to be added or removed as emergency responders arrive at the scene and leave the scene.
    • Public safety users currently use shared devices for their agency mission critical operations where the phone is used on different shifts. There could be some enhanced capability to identify the user who can receive/originate the call based on the authentication that are already available/supported on the device such as bio-metrics (fingerprint or retina) for locking/unlocking and able to invoke the same credentials for opening MCPTT application for ease of use rather than having multiple login/password access to the MCPTTT application.
    • The application may leverage the existing smartphone address book/contacts list, call logs and dialer functions for MCPTT call and groups origination.
    • The location and presence capability of the MCPTT user can be rendered on map location on the phone contacts list for enhanced usability.
    • The option of MCPTT calls that can be recorded locally and able to store on the device — that is not specific to voice but also text, video with playback capability.
    • The enhanced option of identification of the user with Talker ID or UserID or alias capability on MCPTT and group call scenarios. This use case is applicable on shared devices scenario where the person who is making MCPTT call can be identified by the agency in combination of device ID (IMEI) and SIM (IMSI).
    • Public Safety users can have the option on prioritizing the groups internally on their groups. The MCPTT application should be able to provide enhanced usability on concurrent talk group request to emergency responder.


Review the How to Participate instructions in section 3 of this document to ensure that you are prepared for the in-person Regional Codeathon or Online Contest. The following deliverables will need to be included with the submission:

  • A completed submission form through techtoprotectchallenge.org
  • A 3-minute narrated PowerPoint file or 3-minute narrated video with the following sections:
    • A summary of the submission.
    • Basic information about the participant or participant’s team.
    • Specific requirements of the contest that are being addressed by the participants.
    • Two to four screenshots of the solutions or prototype.
    • Overview of key functions included in the submission.
  • Any available files or links to the developed solution or prototype.

Any additional files based on the contest description.

Tech To Protect
Rules & Guidelines