Let’s start with a bit of context: as I type this, 3GPP’s work on Release 15 is currently between the stage 2 freeze (the functional and dynamic specification of the standard, which occurred in December) and the stage 3 freeze (protocol specification completion, which will take place in June). A further freeze will occur in September – ‘ASN.1 freeze’, which corresponds to binary encoding specification freeze; Erik Guttman adds that this often lags a quarter behind the detailed protocol specification activity.
Guttman says SA6 (the group in 3GPP responsible for developing mission-critical features) completed the stage 2 specifications for all but three features by the December deadline. These are MBMS_Mcservices – MBMS usage for MC communication services; MCSMI – MC system migration and interconnection; and MCCI – MC communication interworking between LTE and non-LTE systems. These features are currently still being worked on, and 3GPP intends to complete at least the most significant components within the Release 15 timeframe.
This means that stage 3 work is under way for enhMCPTT (enhancements to MCPTT functional architecture and information flows) and its equivalents for MCData and MCVideo (eMCData and eMCVideo) and MONASTERY.
Guttman explains that MONASTERY covers the work to replace GSM-R’s protocol suite and is keen to stress that innovation in other areas of critical communications will also benefit public safety organisations. “For example, the MONASTERY feature for mobile communication for railways adds capabilities for functional aliases and multi-talk features. These then will become available for mission-critical applications for public safety if they so desire.”
Another area of work in SA6, which Guttman says will directly complement mission-critical standards, is the common API framework it has developed, which would allow mission-critical and other service providers to employ standardised and harmonised interfaces with the 3GPP system. What could this mean for a public safety organisation using mission-critical LTE? Guttman gives an example: “It would also allow them to use interfaces for machine-type communication or Internet of Things capabilities if they needed to operate or interface with sensors or controllers. Having this uniform API framework allows you to make use of other types of services without having to develop a whole new interaction with the 3GPP service layer.”
Guttman adds that “it’s quite rare” for features to be delayed once stage 2 work has been successfully completed, adding that: “We had a bit of difficulty in Release 14 where we had broad ambitions for MCData and MCVideo and we were only able to complete a fraction of that, but the rest of it has already been added to Release 15.”
We turn to discussing the new and expanded features Release 15 is expected to provide that Guttman feels will most benefit mission-critical users. He highlights a “migration and interconnection [feature] that will enable first-responders to co-operate and work directly in the mission-critical networks of partner agencies”, as well as a feature that will allow standardised “interworking between LTE and non-LTE systems to ease transition from existing installed infrastructure to 3GPP-standardised mission-critical deployments”.
In addition: “MCVideo requirements for flexible adaptation were not supported in Release 14, but were added in Release 15. This will improve the performance and applicability of MCVideo in very practical ways. The mission-critical video QCI for QoS control was also added. So, we can now provide service in a way that is integrated with all the other services that the telecommunication infrastructure provides.”
Guttman adds that Release 15 will significantly expand MCData functions. “For example, we’ve added a variety of capabilities for communication release, which is mainly a resource management enhancement. We’ve also added file distribution capabilities – that’s one of the key use-cases for MCData, sending and retrieving bulk data that’s located within your network – and general application tagging for group data sessions, which will allow different applications to make use of the group data feature at the higher level.”
Joining narrowband and broadband
As Release 15 will be the first to include an LMR/PMR-3GPP interworking function, it is worth delving into this in some detail. This is technically defined by the TS 23.283 specification. Guttman says the approach will be for LMR/PMR to have three interfaces with the 3GPP standard mission-critical system: one with the MCPTT server; another with the MCData server to support interworking between PMR/LMR’s short data services (SDS) and the 3GPP equivalent; and, finally, an interface with the core services for the 3GPP mission-critical standard, such as group, configuration and identity management.
“The idea here is that the interworking function will allow a call to be initiated by a legacy device through the back end of the LMR/PMR system – an implementation that is out of scope of the 3GPP standard – but the actual group and communication will exist and be terminated in the 3GPP domain. Similarly, a 3GPP mission-critical standard UE (user equipment) would be able to communicate back through the interworking function to a legacy terminal.”
Guttman adds that there are “fundamental challenges” to this feature, “even before it was studied in 3GPP”, with the most significant being LMR/PMR’s use of end-to-end encryption and their use of codecs defined by their own standards. He explains that this has led to the creation of two models, with one for “mediated communication, which terminates in the IWF (Interworking Function) with a transcoder that goes from the LMR/PMR codec to a 3GPP codec. So, in the 3GPP system, you only see the 3GPP codec and 3GPP security, while in the LMR/PMR system you would still see the existing legacy codec.
“That approach would have an entity in the middle that you’d have to trust, because you’d no longer have end-to-end encryption, you’d have this point where the protocol would be translated.
“The other model would actually deliver the media stream from the LMR/PMR system to the 3GPP device, terminating both the codec and the security and so on.” He adds that this is still being worked on by the relevant working groups in 3GPP, and they are seeking to allow both models to be deployed.
Guttman says the new interworking feature should include a system that will allow interworking for emergency alerts. “This would mean that an emergency alert could be sent from a legacy LMR/PMR system and be received by devices in the 3GPP system or vice versa.”
The shape of things to come
Moving onto 3GPP Release 16 and beyond, Guttman says 3GPP will continue to enhance the mission-critical core services – MCPTT, MCVideo and MCData – and will work on MONASTERY 2, which will provide “additional capabilities for the mobile rail system that will move us closer or fully to the point where GSM-R can be retired”.
He adds that one of the big things to look out for is that “in Release 15, we have removed the tight pairing of MCServices with LTE; however, none of the implications of that decision have been investigated.
“The project of doing mission-critical service standardisation in 3GPP was predicated on the idea that it would operate on LTE. Now, the question is: how can mission-critical services operate on any access, such as the new radio access which is being developed for 5G?”
Guttman notes that 5G New Radio will be used for massive IoT and for URLLC (not just for enhanced mobile broadband), and that with these “it’s possible that millimetre wave or more familiar frequencies would be used”. He also highlights the fact that public safety organisations’ need for ubiquitous coverage is more easily served by spectrum in the hundreds of megahertz range than the many-GHz range.
He adds: “For some applications, satellite technology may become important and the integration of satellite solutions with terrestrial ones will perhaps play a very important role in providing ubiquitous coverage in very large countries with varied terrain.”
Ask not what 3GPP can do for you…
While 3GPP has done – and continues to do – a great deal for our sector, it can’t do it alone and it is dependent on input from vendors and end-users to ensure that the features it creates are fit for purpose. With this in mind, Guttman concludes by saying: “There are bound to be areas where tighter co-ordinated interworking is considered valuable, so it would be very useful to the continuing success of the 3GPP standard if concerned parties – companies and agencies – come to 3GPP with feedback, their experiences and detailed requirements for improvement in subsequent releases.”
Release 15: What’s in the pipeline for MCPTT?
Release 15 adds a number of enhancements to MCPTT and many of them were completed in time for the stage 2 freeze. They are:
- Entering MCPTT emergency alert area
- Remotely initiated MCPTT call
- Updating the pre-selected MC service user profile
- Temporary group call – user regroup
- Geographically triggered affiliation/de-affiliation
- Location of current talker
- Broadcast group call (updated procedures for set-up of group-broadcast group calls and user-broadcast group calls)
- Further enhancements to location management (new procedures)
- Enhanced MCPTT group call set-up procedure with an MBMS bearer
Samsung Electronics’ Erik Guttman has been actively involved in networking and telecommunications standardisation for more than 20 years. He is the chairman of the 3GPP Service and System Aspects Technical Specification Group. Before this, he held the position of chairman of the 3GPP System Architecture working group for two terms. He has also chaired and contributed to numerous IETF working groups including SVRLOC (Service Location Protocol) and ZEROCONF (Zero Configuration Networking).
