12 Mission Critical, Public Warning

21.9163GPPRelease 16Release descriptionTS

12.1 Enhancements of Public Warning System

780003

Enhancements of Public Warning System

ePWS

 

SP-170998

Hyounhee Koo, SyncTechno Inc.

730005

Study on enhancements of Public Warning System

FS_ePWS

S1

SP-160733

SyncTechno Inc., Hyounhee Koo

800052

Stage 1 of ePWS

ePWS

S1

SP-170998

Hyounhee Koo, SyncTechno Inc.

810012

CT aspects of enhancements of Public Warning System

ePWS

ct

CP-191155

Hyounhee Koo, SyncTechno Inc.

810053

Study on stages 2 and 3 of enhancements of ePWS

ePWS

C1

CP-191155

Hyounhee Koo, SyncTechno Inc.

810047

CT1 aspects of ePWS

ePWS

C1

CP-191155

Hyounhee Koo, SyncTechno Inc.

810048

CT4 aspects of ePWS (Possible impacts)

ePWS

C4

CP-191155

Hyounhee Koo, SyncTechno Inc.

Summary based on the input provided by SyncTechno Inc. in SP-200343.

The ePWS feature enhances the Public Warning System by defining behaviours for UEs with no user interface or with a user interface that is incapable of displaying text-based Warning Notifications and providing how to improve the comprehension of a Warning Notification to users with disabilities who have UEs supporting assistive technologies beyond text assistive technologies and users who are not fluent in the language of the Warning Notifications. In addition, additional requirements are specified for PWS-UEs and ePWS-UEs that play the role of a relay UE or a remote UE to conform behaviours when receiving a Warning Notification via the relay functionality. The requirements can be found in TS 22.268 [1] and corresponding solutions in TS 23.041 [2].

Additional requirements for an enhanced Public Warning System (ePWS) are specified as an update to Technical Specification (TS) 22.268 [1].

3GPP Public Warning Systems were first specified in Release 8, allowing for direct warnings to be sent to mobile users on conventional User Equipment (PWS-UE), capable of displaying a text-based and language-dependent Warning Notification.

Since that time, there has been a growth in the number of mobile devices with little or no user interface – including wrist bands, sensors and cameras – many of which are not able to display Warning Notifications. The recent growth in the number of IoT devices – not used by human users – also highlights the need for an alternative to text based Warning Notifications. If those devices can be made aware of the type of incident (e.g. a fire or flood) in some other way than with a text message, then they may take preventive actions (e.g. lift go to ground floor automatically).

The ePWS feature also specifies how graphical symbols or images can now be used to better disseminate Warning Notifications, specifically aimed at the following categories of users:

– Users with disabilities who have UEs supporting assistive technologies beyond text assistive technologies; and

– Users who are not fluent in the language of the Warning Notifications.

Much of the work on enhancing the Public Warning System is set out in the ePWS requirements in TS 22.268 [1] and in ePWS protocol solutions in TS 23.041 [2] in Release 16, covering:

– Specifying Message Identifiers for ePWS-UE, especially IoT devices that are intended for machine type communications

– Enabling language-independent content to be included in Warning Notifications

The work on ePWS in TS 22.268 [1] and TS 23.041 (Release 16) is expected to help manufacturers of User Equipment meet any future regulatory requirements dedicated to such products.

Requirements defined for PWS-UEs in clause 4 of TS 22.268 [1] are applicable for ePWS-UEs unless dedicated ePWS-UE requirements described in clause 9 of TS 22.268 [1] supersede them.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=780003,730005,800052,810012,810053,810047,810048

[1] TS 22.268, Public Warning System (PWS) requirements

[2] TS 23.041, Technical realization of Cell Broadcast Service (CBS)

12.2 MBMS APIs for Mission Critical Services

800053

MBMS APIs for Mission Critical Services

MBMSAPI_MCS

S6

SP-180380

Ling Zhang, TD Tech Ltd.

760051

Study on MBMS APIs for MC Services

FS_MBMSAPI_MC

S6

SP-180237

Ling Zhang, TD Tech Ltd

800020

Stage 2 of MBMS APIs for MC Services

MBMSAPI_MCS

S6

SP-180380

Ling Zhang, TD Tech Ltd.

Summary based on the input provided by CATT, TD-Tech in SP-201001.

This WI defines the system architecture and a set of UE API functions that allow the Mission Critical applications to access the MBMS capabilities without implementing the logic of MBMS operations. The MBMSAPI_MCS intends to offer the API within the UE to ease the development of Mission Critical Services across different phone platforms, and to provide decoupling between the platform MBMS functions and the mission critical application call control functions.

The WI defines the system architecture for the UE API that complies with GCSE as defined in TS 23.468 [2], and the API functions that support the use of MBMS transmission for Mission Critical services as defined in TS 23.280 [3], TS 23.379 [4], TS 23.281 [5] and TS 23.282 [6].

The following API functions have been specified with the corresponding procedures and parameters for the Mission Critical applications to:

– Obtain the MBMS SAI or cell information of the UE and the relevant updates;

– Perform registration or deregistration for a Mission Critical application for its access to the MBMS service on the UE;

– Exchange information about an announced or de-announced MBMS bearer with the API provider on the UE;

– Get notified about events related to the MBMS bearer availability and quality;

– Start or close the reception of a given media delivered over MBMS;

– Retrieve the capabilities (e.g. FEC and ROHC) from the API provider on the UE.

References

[1] SP-180380: "New WID on MBMS APIs for Mission Critical Services".

[2] TS 23.468: "Group Communication System Enablers for LTE (GCSE_LTE); Stage 2".

[3] TS 23.280: "Common functional architecture to support mission critical services; Stage 2".

[4] TS 23.379: "Functional architecture and information flows to support Mission Critical Push To Talk (MCPTT); Stage 2".

[5] TS 23.281: "Functional architecture and information flows to support Mission Critical Video (MCVideo); Stage 2".

[6] TS 23.282: "Functional architecture and information flows to support Mission Critical Data (MCData); Stage 2".

[7] TR 23.792: "Study on MBMS APIs for Mission Critical Services".

12.3 Mission Critical Services Security Enhancements

800032

Mission Critical Services Security Enhancements

MCXSec

S3

SP-180596

Woodward, Tim, Motorola Solutions, Inc

Summary based on the input provided by Qualcomm Incorporated in SP-190865.

Mission critical (MC) services security enhancements provide the confidentiality, integrity, user authentication, service authorization and overall security architecture for the Release 16 mission critical features (MCPTT, MCVideo, MCData, MC Location, MC Interworking, MC Interconnection, and MC Railway).

Release 16 expands on the mission critical security architecture already defined in previous releases along with various mission critical security clarifications and corrections.

In this release, mission critical security adds user service authorization for the mission critical location service. Similar to user service authorization for the other MC services, an appropriately scoped access token is obtained from the Identity Management server which permits only authorized users to access the MC location service.

MCData payload protection is enhanced to support separate algorithm types for the MCData payload field and the signalling parameters field, Data signalling payload field and end to end security parameters fields. This allows the architecture to meet varying security needs of the mission critical operator for both on and off network MCData operational scenarios.

Security for interconnection now combines the MC gateway, Interconnection Signalling (IS) proxy and HTTP proxy to provide topology hiding, HTTP protection and signalling protection for inter-domain MCPTT, MCData and MCVideo communications between two disparate mission critical systems for a complete interconnection security solution.

The security foundation for dynamic rekeying of 3GPP interworking mission critical users across the IWF from a Land Mobile Radio system is further enhanced to support pre-provisioning of interworking key management records. The KMS provides these records to the UE (i.e. mission critical user) during service authorization to establish the initial key material needed to support protection of interworking communications.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=800032

[1] TS 33.180, Security of the mission critical service; (Release 16)

12.4 Other Mission critical improvements

12.4.1 MCData File Distribution support over xMB

810004

MCData File Distribution support over xMB

MC_XMB

S4

SP-180665

Thiénot Cédric, Expway

Summary based on the input provided by Expway.

This work item summary reports on standardization of the “xMB extension for mission critical services (MC_XMB)” specified in [1].

To deliver group communications over MBMS, MCPTT and MCVideo make use of GCSE (Group Communication System Enabler), where MBMS bearers are activated and managed over MB2-C by the mission critical applications servers to transparently transport any packets pushed over MB2-U.

To ensure reliable and efficient transport of files over a unidirectional and lossy channel such as MBMS requires a dedicated protocol stack. SA4, in the conclusion of the TR 26.881 [4], recommends reuse of the MBMS download delivery method for MCData file distribution, which is supported by the xMB/MBMS API interfaces.

In the context of this for MCData file distribution, different extensions have been required.

First of all, in TS 26.348 [2], several functions to the xMB interfaces have been added:

– QOS management: The ability for a mission critical solution provider to control precisely the allocation of network resources has been added.

– Target geographical management: Geographical area semantics in xMB have be aligned with the MB2-C AVP for mission critical services

– TMGI exposure: the TMGI allocated during the MBMS session creation has been exposed.

Moreover, in TS26.346 [3] a new service announcement mode named “self-contained” mode has been added, indicating that the service announcement metadata for this service is delivered in-band with the data (i.e. in the same MBMS bearer).

All these functions have been integrated to ensure an efficient usage of the MBMS download delivery method for MCData file distribution

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=810004

[1] SP-180665, ” New WID on xMB extension for mission critical services (MC_XMB)”

[2] TS 26.348, “Northbound Application Programming Interface (API) for Multimedia Broadcast/Multicast Service (MBMS) at the xMB reference point”

[3] TS 26.348, “Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs”.

[4] TR 26.881, “Forward Error Correction (FEC) for Mission Critical Services”

12.4.2 Enhanced Mission Critical Communication Interworking with Land Mobile Radio Systems

800021

Enhanced Mission Critical Communication Interworking with Land Mobile Radio Systems

eMCCI

S6

SP-180680

Derek Wells, L3Harris (was Peter Monnes, Harris Corporation)

Summary based on the input provided by L3Harris.

This Stage 2 work item provides architectural features to support interworking between Mission Critical systems and Land Mobile Radio systems in the specific areas of Group Calls, Emergency Calls, Group Regroups, Unit to Unit Calls, user location, functional aliases and encryption.

The main impacts to the 3GPP MC system architecture introduced by this work item are the enhancements to enable users engaged in public safety scenarios to interwork between MC systems and LMR Radio Systems. Features such as Group Call (one to many), group emergency notifications, grouping of users and grouping of groups (for gathering many users on the same group), and functional aliases are all common in Land Mobile Radio systems and novel to 3GPP MC systems. Features such as unit to unit call, user location and traffic encryption are common to both types of systems but needed integration. This eMCCI work item provides the means to utilize these features across the two types of systems. Other work performed in TS 23.280 and TR 23.379 and various work items enable the features in the 3GPP MC system architecture.

Note: Stage 3 was not completed at the time when this summary was introduced in the present document (Dec. 2020).

References

[1] TS 23.283, Mission Critical Communication Interworking with Land Mobile Radio Systems

12.4.3 MBMS APIs for Mission Critical Services

800053

MBMS APIs for Mission Critical Services

MBMSAPI_MCS

S6

SP-180380

Ling Zhang, TD Tech Ltd.

760051

Study on MBMS APIs for MC Services

FS_MBMSAPI_MC

S6

SP-180237

Ling Zhang, TD Tech Ltd

800020

Stage 2 of MBMS APIs for MC Services

MBMSAPI_MCS

S6

SP-180380

Ling Zhang, TD Tech Ltd.

Summary based on the input provided by CATT, TD-Tech in SP-201001.

The WI defines the system architecture and a set of UE API functions that allow the Mission Critical applications to access the MBMS capabilities without implementing the logic of MBMS operations. The MBMSAPI_MCS intends to offer the API within the UE to ease the development of Mission Critical Services across different phone platforms, and to provide decoupling between the platform MBMS functions and the mission critical application call control functions.

The WI defines the system architecture for the UE API that complies with GCSE as defined in TS 23.468 [2], and the API functions that support the use of MBMS transmission for Mission Critical services as defined in TS 23.280 [3], TS 23.379 [4], TS 23.281 [5] and TS 23.282 [6].

The following API functions have been specified with the corresponding procedures and parameters for the Mission Critical applications to:

– Obtain the MBMS SAI or cell information of the UE and the relevant updates;

– Perform registration or deregistration for a Mission Critical application for its access to the MBMS service on the UE;

– Exchange information about an announced or de-announced MBMS bearer with the API provider on the UE;

– Get notified about events related to the MBMS bearer availability and quality;

– Start or close the reception of a given media delivered over MBMS;

– Retrieve the capabilities (e.g. FEC and ROHC) from the API provider on the UE.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=800053,760051,800020

[1] SP-180380: "New WID on MBMS APIs for Mission Critical Services".

[2] TS 23.468: "Group Communication System Enablers for LTE (GCSE_LTE); Stage 2".

[3] TS 23.280: "Common functional architecture to support mission critical services; Stage 2".

[4] TS 23.379: "Functional architecture and information flows to support Mission Critical Push To Talk (MCPTT); Stage 2".

[5] TS 23.281: "Functional architecture and information flows to support Mission Critical Video (MCVideo); Stage 2".

[6] TS 23.282: "Functional architecture and information flows to support Mission Critical Data (MCData); Stage 2".

[7] TR 23.792: "Study on MBMS APIs for Mission Critical Services".

12.4.4 Enhancements to Functional architecture and information flows for Mission Critical Data

830051

Enhancements to Functional architecture and information flows for Mission Critical Data

eMCData2

S6

SP-180378

Shih, Jerry, AT&T

800018

Stage 2 of eMCData2

eMCData2

S6

SP-180378

Shih, Jerry, AT&T

830014

CT aspects of eMCData2

eMCData2

C1

CP-190199

Val Oprescu (AT&T)

Summary based on the input provided by at&t in SP-201083.

The following Mission Critical Data functionalities have been introduced in Rel-16:

(a) A new network-based MCData message store has been added to allow a MCData user to store its MCData communication history permanently by providing secured storage area for each authorized MCData user having a user account. A user (i.e. a dispatcher) other than the user account holder shall be able to access the account holder’s storage area if authorized. A user can synchronize his MCData message store account with his devices (UEs) to get consistent user experience across all his devices.

(b) A new network based MCData content server has been added to allow file distribution indirectly; this function was implemented in the MCData server in R15. As a standalone network entity, the MCData content server provides complete functions of shared file cycle management and takes away processing burden from the MCData server and increasing its MCData communication capacity.

(c) IP Connectivity is now supported. The non MCData clients can use the IP connectivity feature between two MCData client to exchange data payloads.

(d) Introduction of MC Gateway server for flexible interconnection.

(e) Supports of functional alias. A MCData user can connect to other MCData users based on the functional alias they are registered.

(f) Supports of emergency alert function for all MCData services.

(g) MBMS supports for file distribution. With file has been uploaded to the MCData content server, the MCData server uses MBMS to efficiently deliver the file to the recipients. For any missing parts of the file, the recipient can retrieve it directly from the MCData content server where the file was uploaded.

(h) Share of user location information. The sender’s location information can be shared with the recipient for all MCData services.

The architecture, protocol, and security aspects of the MCData service related to these enhancements are described in the following specifications:

1. The architecture (including information flows, procedures, and configuration) is specified in TS 23.282 and TS 23.280;

2. The security aspects are specified in TS 33.180;

3. The protocol aspects for call control and media plane are specified in TS 24.282 and TS 24.582 respectively;

4. The protocol aspects for group configuration, identity management, and general configuration are specified in TS 24.481, TS 24.482, TS 24.483, and TS 24.484 respectively;

5. The protocol aspects for policy and charging control are specified in TS 29.213 and TS 29.214;

6. The protocol aspects for data management related to MC service user profile are specified in TS 29.283;

7. The stage 2 aspects of the Proximity-based services (ProSe) enabler are specified in TS 23.303.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=830051,800018,830014

[1] TS 22.282 Mission Critical Data services; Stage 1;

[2] TS 22.280 Mission Critical Services Common Requirements (MCCoRe); Stage 1;

[3] TS 23.282 Functional architecture and information flows to support Mission Critical Data (MCData); Stage 2;

[4] TS 23.280 Common functional architecture to support mission critical services; Stage 2;

[5] TS 23.303 Proximity-based services (ProSe); Stage 2;

[6] TS 23.468 Group Communication System Enablers for LTE (GCSE_LTE); Stage 2;

[7] TS 24.282 Mission Critical Data (MCData) signalling control; Protocol specification;

[8] TS 24.582 Mission Critical Data (MCData) media plane control; Protocol specification;

[9] TS 24.481 Mission Critical Services (MCS) group management; Protocol specification;

[10] TS 24.482 Mission Critical Services (MCS) identity management; Protocol specification;

[11] TS 24.483 Mission Critical Services (MCS) Management Object (MO);

[12] TS 24.484 Mission Critical Services (MCS) configuration management; Protocol specification;

[13] TS 29.213 Policy and Charging Control signalling flows and Quality of Service (QoS) parameter mapping;

[14] TS 29.214: Policy and Charging Control over Rx reference point;

[15] TS 29.283: Diameter data management applications;

[16] TS 33.180: Security of the mission critical service.

12.4.5 MC Communication Interworking

800016

Stage 3 for MC Communication Interworking with Land Mobile Radio Systems

MCCI_CT

C1

CP-190203

Monnes, Peter, Harris Corporation -> Derek Wells (of I3Harris

820040

Mission Critical system migration and interconnection

MCSMI_CT

C1

CP-190143

Dom Lazara, Motorola Solutions

760050

MC Communication Interworking between LTE and non-LTE Systems

Summary based on the input provided by Sepura Ltd; L3Harris Technologies in SP-201111.

For Release 16 implementation, the MCCI work was contained in two work items: MCCI for stage 2 and MCCI_CT for stage 3.

Interworking between MC systems and LMR systems allows the systems to be connected for the purpose of carrying calls and data messaging between the participants in both systems.

For Release 16, the purpose of the LMR interworking enhancements to the MC system was to enable interconnection of a MCPTT or MCData system to an LMR system to support MCPTT and MCData SDS interworking, based on Stage 3 implementation of the Stage 2 TS 23.283 architectures, procedures and functional flows developed during Release 15. The general architectural principle was to define a logical Interworking Function (IWF) (representing an LMR system) on a Mission Critical (MCPTT or MCData) server to allow a server – server based connection between the IWF and the MC system, and develop the procedures and functional flows for an IWF by basing them on those already identified for the corresponding server-server communication within the MC system.

An IWF is composed of two parts: the first is an interface to the relevant MC server: IWF-1 (based on a subset of the MCPTT reference points described in TS 23.379), IWF-2 (based on a subset of the MCData reference points described in TS 23.282) and IWF-3 between the IWF and the Group Management Server. The second part of the IWF is an interface to the LMR system based on reference points defined by the LMR system. This provides a generic architecture to interwork between LMR systems such as TETRA, P25 and DMR, as well as a framework for interworking with other non-MC systems – e.g. GSM-R. An illustration of this for MCData interworking is in Figure 1.

Figure 1: Illustration of Interworking architecture for MCData SDS

The subsequent documentation approach in Stage 3 was to document the differences between existing relevant MCPTT / MCData functionality and the primitives & process needed for the same purpose in interworking. The late completion of the Stage 2 meant that the Release-16 Stage 3 developed initially based on the Release 15 Stage 2 described in TS 23.283.

The features that have been completed are :

a) affiliation;

b) group calls;

c) private calls;

d) broadcast calls;

e) temporary calls;

f) emergency calls and alerts;

g) talker location;

h) floor control;

i) codec negotiation;

j) short data service, including status;

k) 3GPP encryption; and

l) messaging and configuration support for LMR based key management and end-to-end encryption.

The architecture, protocol, and security aspects of MCCI are described in the following specifications:

1. The architecture (including information flows, procedures, and configuration) is specified in TS 23.283.

2. The protocol aspects for MCPTT call control and media plane are specified in TS 29.379 and TS 29.380 respectively;

3. The protocol aspects for MCData call control are specified in TS 24.952;

4. The security aspects are specified in TS 33.180.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=800016,820040,760050

[1] TS 22.179: "Mission Critical Push to Talk (MCPTT); Stage 1";

[2] TS 23.283: "Mission Critical Communication Interworking with Land Mobile Radio Systems; Stage 2";

[3] TR 24.883: "Mission Critical Systems Connection to LMR";

[4] TS 29.379: "Mission Critical Push To Talk (MCPTT) call control interworking with Land Mobile Radio (LMR) systems; Stage-3";

[5] TS 29.380: "Mission Critical Push To Talk (MCPTT) media plane control interworking with Land Mobile Radio (LMR) systems; Stage 3";

[6] TS 29.582: "Mission Critical Data (MCData) interworking with Land Mobile Radio (LMR) systems; Stage 3";

[7] TS 23.282: "Functional architecture and information flows to support Mission Critical Data (MCData); Stage 2";

[8] TS 23.280: "Common functional architecture to support mission critical services; Stage 2";

[9] TS 23.282: "Functional architecture and information flows to support Mission Critical Data (MCData); Stage 2".

[10] TS 24.379: "Mission Critical Push To Talk (MCPTT) call control; Protocol specification";

[11] TS 24.282: "Mission Critical Data (MCData) signalling control; Protocol specification";

[12] TS 33.180: "Security of the mission critical service".

12.4.6 Enhanced Mission Critical Push-to-talk architecture phase 2

800022

Enhanced Mission Critical Push-to-talk architecture phase 2

enh2MCPTT

S6

SP-190068

Dom Lazara; Motorola Solutions

Summary based on the input provided by Motorola Solutions in SP-201114.

For Release 16, the enhancements to the MCPTT service were contained in three work items: enh2MCPTT for stage 2 (SA6), Enhanced Mission Critical Push-to-talk architecture phase 2; enh2MCPTT-CT for stage 3 (CT1), CT aspects of enh2MCPTT; and MCXSec for stage 2 and 3 (SA3), Mission Critical Services Security Enhancements. The corresponding items which have been completed in Release 16 are described in the following clause.

These enhancements to the MCPTT service impact the following areas of the architecture and protocols: call control and media handling, configuration, and security.

The following features have been newly introduced or enhanced.

Group and user regrouping using preconfigured group

– Regroup using a preconfigured group refers to the creation of a user or group regroup based on the configuration information associated with an existing group that is referred to as the preconfigured group. This type of regroup takes its entire configuration from the preconfigured group, including initial security information. Since all MCPTT clients participating in the regroup operation are already configured with the preconfigured group information, this allows immediate use of the regroup for a group call upon initiation of the regroup.

– A regroup using a preconfigured group is initiated without the creation of a new group document in the group management server. The advantage of regroup using a preconfigured group is speed of setup of the regroup, especially when large numbers of users (e.g. hundreds) may be involved. Control of the regroup using a preconfigured group is contained in the MCPTT server (namely the controlling MCPTT function). Creation and removal of a regroup is initiated by an authorized MCPTT client. Removal of the regroup can also be initiated by the MCPTT server based on certain criteria.

– A group regroup may be achieved by regrouping MCPTT groups into a new MCPTT regroup group which uses the configuration of a separate preconfigured MCPTT group.

– A user regroup may be achieved by regrouping MCPTT users into a new regroup group which uses the configuration of a separate preconfigured MCPTT group.

– The MCPTT regroup group can be specified to be a broadcast or non-broadcast type according to the configuration of the MCPTT group specified in the regroup request.

– The broadcast type of regroup is used for one-way communication where only an authorized MCPTT user is allowed to transmit and all other regroup users are only allowed to receive the communication (e.g. a call from a dispatcher to all regroup members).

– The non-broadcast type is used for two-way communication where all regrouped users can transmit and receive (i.e. a normal group call).

Location enhancements for current talker and ambient listening

– Location of a current talker is a feature that allows the initiator of a group or private call transmission to share his current location via the media plane with every transmission (floor request that is granted). Based on privacy settings, the talker’s location is delivered to the other affiliated members of the group, or to the receiving user in the private call.

– The ambient listening call is a type of a private MCPTT call that only allows a "listened to" user to transmit media to a "listening" user such that there is no indication on the MCPTT UE of the "listened to" user about the call and the media transmission.

– Remotely initiated ambient listening is initiated by the authorized user (e.g., dispatcher) who wants to listen to another user. In this case, the "listened to" user is the called party, and shall automatically accept the call without causing any indication about the call and transmit the media to the "listening" user.

– Locally initiated ambient listening is initiated by an authorized user who wants another user to listen to the MCPTT UE communication. In this case, the "listened to" user is the calling party and shall automatically transmit the media to the "listening" user without causing any indication about the call processing and media transmission.

– Enhancements have been made to more reliably deliver location via the media plane in the scenarios listed above.

Enhancements for entering or existing a geographic area

– Geographical affiliation and de-affiliation is a feature that allows an authorized MCPTT user to define a geographical area for the purposes of causing the target MCPTT client to affiliate to a group when within this geographic area. Upon leaving the geographic area the target MCPTT client is sent an indication to de-affiliate. The MCPTT system keeps track of the target MCPTT user’s location and sends an indication to the MCPTT client upon entering or exiting the geographic area.

– Geographical sending of an emergency alert is a feature that allows an authorized MCPTT user to define a geographical area for the purposes of causing the target MCPTT client to send an emergency alert when within this geographic area. Upon leaving the geographic area the target MCPTT client sends an emergency alert cancel. The MCPTT system keeps track of the MCPTT user’s location and sends an indication to the target MCPTT client upon entering or exiting the emergency alert area.

– Enhancements have been made to the polygon and ellipsoid-arc definition of area to more reliably define location when entering or existing the geographic area of interest.

Secure tunnel between key management server and key management client

– The establishment of a direct secure tunnel between the mission critical key management server and the mission critical key management client is required. Such a direct TLS tunnel needs to be an option for mission critical agencies that require stronger security.

The requirements, architecture, protocol, and security aspects related to these enhancements are described in the following specifications:

1. The MCPTT service requirements are specified in TS 22.179 and TS 22.280;

2. The MCPTT service architecture (including information flows, procedures, and configuration) is specified in TS 23.379 and TS 23.280;

3. The security aspects of the MCPTT service are specified in TS 33.180;

4. The protocol aspects of the MCPTT service for call control and media plane are specified in TS 24.379 and TS 24.380 respectively;

5. The protocol aspects of the MCPTT service for group configuration, identity management, and general configuration are specified in TS 24.481, TS 24.482, TS 24.483, and TS 24.484 respectively;

6. The protocol aspects of the MCPTT service for codecs and media handling are specified in TS 26.179;

7. The protocol aspects of the MCPTT service for policy and charging control are specified in TS 29.213 and TS 29.214;

8. The protocol aspects of the MCPTT service for data management related to MC service user profile are specified in TS 29.283;

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=800022

[1] TS 22.179 Mission Critical Push To Talk (MCPTT) over LTE; Stage 1

[2] TS 22.280 Mission Critical Services Common Requirements (MCCoRe); Stage 1

[3] TS 23.379 Functional architecture and information flows to support Mission Critical Push-To-Talk (MCPTT); Stage 2

[4] TS 23.280 Common functional architecture to support mission critical services; Stage 2

[5] TS 24.379 Mission Critical Push To Talk (MCPTT) call control; Protocol specification

[6] TS 24.380 Mission Critical Push To Talk (MCPTT) media plane control; Protocol specification

[7] TS 24.481 Mission Critical Services (MCS) group management; Protocol specification

[8] TS 24.482 Mission Critical Services (MCS) identity management; Protocol specification

[9] TS 24.483 Mission Critical Services (MCS) Management Object (MO)

[10] TS 24.484 Mission Critical Services (MCS) configuration management; Protocol specification

[11] TS 26.179 Mission Critical Push-To-Talk (MCPTT); Codecs and media handling

[12] TS 29.213 Policy and Charging Control signalling flows and Quality of Service (QoS) parameter mapping

[13] TS 29.214: Policy and Charging Control over Rx reference point

[14] TS 29.283: Diameter data management applications

[15] TS 33.180: Security of the mission critical service.

12.4.7 Other Mission Critical activities

800019

Enhanced Mission Critical System Migration and Interconnection

eMCSMI

S6

SP-180379

Chater-Lea, David; Motorola Solutions

eMCSMI: Stage-3 for eMCSMI not started after the completion of deadline for Rel-16 Stage 3. Awaiting clarifications on whether this all Feature can be moved to Rel-17.