What new features and enhancements were completed in Release 16?
Mission Critical (MC) standards continue to evolve with further enhancements to Mission Critical Push-to-Talk (MCPTT 4.0), MCData (3.0), LMR/LTE Interworking (2.0), Migration (2.0), Railways (2.0) and the MC MBMS (Multimedia Broadcast Multicast Services) API.
Two study items – MC Isolated E-UTRAN Operation for Public Safety (MCIOPS); and the Study into Discreet Listening and Logging for MC Services (MCLOG) – were completed. Two further studies – Study on MC Services support over 5G System (MCOver5GS); and the Study on location enhancements for mission-critical services (enhMCLoc) – are still ongoing and are expected to complete in Release 17.
What are the most important new mission-critical features or capabilities to be added since Release 15 and what do you think are likely to be the most useful to public safety?
Since Release 15, a significant effort was invested in enhancing MCX (Mission Critical Services) capabilities to support railways. There are several unique features, such as functional addressing of users across all call types, and advanced features including call forwarding and IP connectivity. While these are specifically developed for railways, it is expected that they will benefit all verticals of critical communications.
For public safety, one crucial addition is the support for pre-configured groups. This feature enables group re-group operations in a highly efficient manner, which was not possible in the previous releases. Media server has been introduced to support recording of MCData service-related transaction history (such as short data service and file distribution).
With the completion of Rel-16, interworking with LMR can now be considered as fully supported, which has been a strong requirement for public safety agencies.
What is the significance for public safety of the various study items and what follow-on is planned?
During Release 16, several new studies were initiated – MCIOPS, MCLOG, enhMCLoc and MCOver5GS. Taking these in turn:
- The MCIOPS study enables the support of MC services in the case of a backhaul failure or a nomadic EPS deployment based on the availability of Isolated E-UTRAN Operation for Public Safety (IOPS). The normative work is in progress and expected to be ready in Release 17.
- The MCLOG study enables the support of discreet listening and logging/replay of MC communications. The study considers several scenarios including private and group communications across multiple MC services including voice, video and data. This study is complete in Release 16 and normative work is expected to begin in Release 17.
- The enhMCLoc study identifies new use-cases, key issues and solutions for improvements in the handling of the location information (reporting and sharing), and gaps in the existing MC architecture. The study is expected to be completed in Q1/2020 and normative work is expected during Release 17.
The MCOver5GS study aims to identify the impacts and necessary changes in the existing specifications to ensure MCX services can be supported over 5G. A reasonable progress has been made during Release 16, but due to the lack of essential public safety features such as broadcast and D2D support in 5G, the study has extended its timeline into Release 17. The MCOver5GS study is expected to complete in Release 17, followed by normative work in Release 18.
Is work finished as far as 3GPP is concerned on the LMR-LTE interworking function (IWF)? If not, what still needs to be done?
Yes, we can conclude that 3GPP has a fairly complete set of specifications for interworking with LMR with the completion of Release 16. Certain enhancements are possible in the future – typically when new enhancements are made on the 3GPP side, we want to make sure those are also reflected on the interface towards the IWF.
Work still needs to be done to specify the interfaces between 3GPP IWF and the backend of P25/TETRA systems, doesn’t it?
This activity is generally considered out of the scope of 3GPP, but I understand there is concerted effort in both ATIS and ETSI to solve the other piece of the puzzle, i.e.. the interface between IWF and LMR systems.
There seems to be some confusion in the public safety community as to exactly where the IWF sits – can you clarify this?
Generally speaking, interworking functions or gateways are seen as an implementation matter. However, strictly speaking from 3GPP’s perspective, our responsibility lies in the messages supported on the IWF interface, and this has been fully specified. The IWF implementation must ensure it conforms to the IWF interface as per 3GPP specifications. The implementation of IWF is typically a decision of the MC service provider, who needs to make sure that IWF function is integrated to both the 3GPP system and the LMR system on the other side.
Can you comment on the widening of SA6’s brief to include other mission-critical verticals besides public safety?
The Terms of Reference (ToR) for SA6 were modified during Release 15. Mission Critical Applications continue to be a top priority for SA6. However, the charter now includes extending the application-layer standards to other activities such as northbound APIs and other vertical applications and frameworks. For instance, railways is a good example of a mission-critical vertical beyond public safety, and the V2X (Vehicle to Everything) APP is an example of a vertical we have been working on recently to enable integration of V2X applications to 3GPP systems by creating a V2X application support layer.
How does SA6’s work fit into the development of the Common API Framework (CAPIF); Service Enabler Architecture Layer (SEAL); and Application Architecture of Edge Apps (EDGEAPP)? What is the significance of these developments?
These initiatives are led by SA6 within 3GPP, and can be categorised into “enabling technologies” for new vertical applications. Th ese activities are particularly important given the strong interest in the industry in deploying new verticals with5G.
CAPIF provides a unified API framework for third-party applications to discover and invoke 3GPP network functionality, and similarly provides a way for underlying 3GPP functions to register and publish their APIs such that they are discoverable by the third-party APIs. Having a unified framework will enable operators to expose network functionality to developers in a consistent manner.
SEAL provides a common application support layer for verticals. More specifically, it focuses on defining certain essential capabilities such as management of groups, location, configuration, key/ID management and resource management, which can be leveraged by new verticals. Having such a common layer will significantly reduce the time to market for new vertical applications, and we have already experienced this with V2XAPP, and are seeing interest in reusing SEAL for other verticals such as Factories of the Future (FFAPP), Unmanned Aerial System (UASAPP), and 5GMARCH (5GMSG – Message Service for Massive IoT over 5G System), which are being studied in SA6.
EDGEAPP provides an application layer framework or enabling layer for hosting of Edge applications both at the device and the network edge, and interactions between them. Th e activity focuses on aspects such as service provisioning, discovery, registration, and service continuity across multiple edge networks.
What will be the main areas of focus for SA6 in the next few meetings?
With Release 16 behind us, our top focus will be to progress the Release 17 stage-2 work towards completion in Q3/2020. From mission-critical applications, emphasis will be on the completion of normative work on Railways 3.0, MCIOPS, and MCData 4.0, as well as the recently agreed MCPTT 5.0 work item, which will also address the conclusions from the enhMCLoc study.
We can expect to conclude on the MCOver5GS study as well. Outside MC, we are actively engaged and on track to complete EDGEAPP 1.0, which is a top priority for 3GPP in Release 17 and has been receiving significant interest from the industry. We will also be making progress on other studies such as FFAPP, UASAPP, 5GMARCH and V2XAPP 2.0.
In a nutshell, there is a lot of work riding on Release 17, and we can expect another solid outcome from SA6! Finally, I would like to thank all the delegates and their companies for their commitment and high-quality contributions.
