Summary based on the input provided by Motorola Solutions in SP-220682 (earlier version provided by FirstNet in CP-220111).
For Release 17, the enhancements to MCPTT (and related services) were contained in two work items: Enhanced Mission Critical Push-to-talk architecture phase 3 -- enh3MCPTT for stage2 (SA6); and enh3MCPTT-CT for stage 3 (CT1). The corresponding items which have been completed in Release 17 are described in the following clause.
These enhancements impact the following areas of the MCPTT, MCVideo, and MCData architecture and protocols: call control and media handling, configuration, and security.
The following features have been enhanced.
Preconfigured group usage:
Certain groups are designated for preconfigured group usage only, and as such, should not be allowed to be the target of a call or alert. Enhancements were made to identify preconfigured groups and protect against their use in call scenarios. The enhancements have been applied to the MCPTT, MCVideo, and MCData services. In addition, enhancements have been made to give parity to the preconfigured regroup feature across all three MC services
Emergency alert area notification handling:
The emergency alert area notification feature allows for an MC user to be notified whenever said user moves into, or moves out, of a predefined area. The functionality is applicable to the MCPTT, MCVideo, and MCData services. Enhancements have been made to give parity of this feature across all three MC services.
Entry / exit from group geographic area handling:
The group geographic area notification feature allows for an MC user to be notified whenever said user moves into, or moves out, of a predefined group geographic area requiring affiliation to, or de-affiliation from, a group. The functionality is applicable to the MCPTT, MCVideo, and MCData services. Enhancements have been made to give parity of this feature across all three MC services.
PDN and APN configuration:
The UE initial config allows for configuration of certain APN parameters such as ServiceServerUri. These APN parameters need to be consistent with the Managed Object definitions. These are applicable for all MC services. Similarly, PDN parameters that provide for PDN connectivity information for each of the MC services need to be consistently specified within the MC UE initial configuration document. Enhancements have been made to align stage 3 with stage 2 specifications.
Location altitude, accuracy and handling:
The handling of location information should provide for an accuracy (uncertainty) that can be given to the various location vectors. These vectors include not just horizontal and vertical location, to support latitude and longitude, but also vertical location to support altitude. Enhancements have been made to the MCPTT, MCVideo, and MCData services to provide for this enhanced location handling.
Clearing the floor request queue:
Previously, an authorized MCPTT user has had the ability to clear a portion of the MCPTT floor request queue for a given call by specifying the list of users to be cleared from the queue. This functionality is further enhanced to allow the authorized MCPTT user to clear the entire floor request queue for all users in the queue for a given call. Enhancements have been made to allow for this new capability. Although this capability will remove all currently queued floor participants, it does not prevent the removed users from immediately retrying to access the floor for the same call.
MCPTT unicast media start and stop:
The MCPTT service has been enhanced to give the capability to the MCPTT client to indicate to the server that a certain unicast media flow for a given group call can be stopped and then resumed at a later time. This capability can reduce radio resources for an MCPTT user who may be participating in other higher priority group calls.
The requirements, architecture, protocol, and security aspects related to these enhancements are described in the following specifications:
The MCPTT service requirements are specified in TS 22.179 and TS 22.280;
The MCVideo service requirements are specified in TS 22.281 and TS 22.280;
The MCData service requirements are specified in TS 22.282 and TS 22.280;
The MCPTT service architecture (including information flows, procedures, and configuration) is specified in TS 23.379 and TS 23.280;
The MCVideo service architecture (including information flows, procedures, and configuration) is specified in TS 23.281 and TS 23.280;
The MCData service architecture (including information flows, procedures, and configuration) is specified in TS 23.282 and TS 23.280;
The security aspects of the MCPTT service are specified in TS 33.180;
The protocol aspects of the MCPTT service for call control and media plane are specified in TS 24.379 and TS 24.380 respectively;
The protocol aspects of the MCVideo service for call control and media plane are specified in TS 24.281 and TS 24.581 respectively;
The protocol aspects of the MCData service for call control and media plane are specified in TS 24.282 and TS 24.582 respectively;
The protocol aspects of MC services 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;
The protocol aspects of the MCPTT service for codecs and media handling are specified in TS 26.179;
The protocol aspects of MC services for policy and charging control are specified in TS 29.213 and TS 29.214;
The protocol aspects of MC services for data management related to MC service user profile are specified in TS 29.283;
Summary based on the input provided by at&t in SP-220089.
For Release 17, the enhancements for the MCData service were defined by the two work items above. The following functionalities have been introduced:
new network-based MCData notification server. The MCData notification server provides the centralized notification function in the network that allows an application (e.g. resident in the UE) to create a communication channel to receive real-time notifications from the network in either Pull or Push mode.
MCData communication (SDS or file distribution) supports using functional alias as target end points, except FD using HTTP.
new "search folder" and "retrieve folder content" operations to MCData message store operations.
Support application specific metadata container in MCData communication for application specific handling.
TS 23.282: Functional architecture and information flows to support Mission Critical Data (MCData) Stage 2 (together with 23.280, it specifies the architecture, including information flows, procedures, and configuration) ;
Summary based on the input provided by Motorola Solutions in SP-220019.
Mission critical (MC) services security enhancements phase 2 defines the confidentiality, integrity, user authentication, service authorization, and overall security architecture for Release 17 mission critical services (MCPTT, MCVideo, MCData, MC Location, MC Interworking, MC Interconnection, and MC Railway).
Release 17 expands on the mission critical security architecture already defined in previous releases and includes some mission critical security clarifications and corrections.
In this release, mission critical user service authorization and security for the mission critical MCData message store service. Similar to user service authorization for the other MC services, an appropriately scoped access token obtained from the Identity Management server permits only authorized users the authorization to access and use the MCData message store service.
Security for Preconfigured Group Regroup and Preconfigured User Regroup calls defines the use of the preconfigured group to establish the security context.
Enhancements to the security architecture to support mission critical security services over a 5G system. This includes the mission critical security architecture, which describes the use and integration of 5G nodes and servers.
Summary based on the input provided by UIC.
MCOver5GS (Mission Critical service over 5GS) aims to enable 5GS for the use by Mission Critical Services supporting on-network as well as off network Mission Critical communication. In a first phase (Rel-17) unicast transmission service are now available for the on-network approach. In consecutive phases multicast/broadcast services and off network are in focus. In the area of off-network communication, the main aim is to align transmission services using 5GS capabilities. Another important aspect is to provide interoperability when Mission Critical Services are supported by both, the EPS and 5GS.
MCover5GC adapts the general Mission Critical Communication functional model so it is applicable when using 5GS. Rel-17 enables the use of unicast based transmission mode for Mission Critical services and the proper use of 5GS Quality of Service categories. Relevant procedures were adapted to be applicable under 5GS conditions.
With use of 5GS, Mission Critical services are now also be used taking the untrusted approach into account so that MC service servers can be operated geographically independently from the IMS/SIP core infrastructure.
MC services can be deployed using different infrastructures, public or non-public. With 5GS, MC services and their traffic can be operated in isolation from others using network slicing. Transport resources are thus virtualized and can be used for MC service, considering predefined bit rates. In this context a minimum amount of bandwidth can also be guaranteed for handling Mission Critical services, e.g. when using public networks.
CT aspects of Enhanced Mission Critical Communication Interworking with Land Mobile Radio Systems
eMCCI_CT
C1
eMCCI_CT
Mike Dolan, FirstNet
Summary based on the input provided by FirstNet in CP-220110.
eMCCI_CT refers to stage 3 aspects of the stage 2 work defined by eMCCI in Rel-16.
It covers enhancements to interworking 3GPP mission critical systems with Land Mobile Radio (LMR, i.e. public safety communication networks) systems in Rel-17 to provide support for a conference event package, affiliation on behalf of a set of users, and private call floor control.
The Rel-17 IWF (interworking function) now supports the ability for the IWF to handle subscriptions to events that may occur in the LMR system, and for the IWF to be able to subscribe on behalf of LMR users to events in the 3GPP mission critical system (MCPTT and MCData).
Affiliation on behalf of a set of users is now handled from the IWF toward the 3GPP mission critical system to potentially reduce the signalling load due to repetitive messaging.
Private call floor control is now supported between an MCPTT system and an IWF.
Mission Critical system migration and interconnection
MCSMI_CT
C1
CP-190143
Dom Lazara, Motorola Solutions
Summary based on the input provided by Motorola Solutions in SP-220683.
MCSMI_CT refers to stage 3 aspects of the stage 2 work defined by MCSMI in Rel-16.
For Release 17, the enhancements to the MC service specifications (MCPTT, MCVideo, and MCData) to support Mission Critical system interconnection were contained in the work items: MCSMI_CT for stage 3 (CT1), and the earlier work items MCSMI (SA6) and eMCSMI (SA6) for stage 2. The latest revised WID for MCSMI_CT in CP 220301 focused only on MC system interconnection. The stage 3 migration aspects for MC systems will be considered in a future release. The corresponding items which have been completed in Release 17 are described in the following clause.
Interconnection between mission critical systems is needed to provide inter-system communication for purposes such as operational support and mutual aid between mission critical systems in different security domains, operated by different mission critical organizations. All of the call types that are available within a single MC system may also be needed when communications between a primary and partner system involves interconnection.
These enhancements for interconnection that follow impact areas of the MCPTT, MCVideo, and MCData service architecture and protocols. The following features have been added or enhanced to support MC system interconnection.
Functional connectivity model and introduction of the MC gateway server: To allow for interconnection of MC systems in different trust domains the MC gateway sever is introduced for each of the MC services to provide topology hiding and an interface between security domains. An MCPTT gateway server can act as a SIP and HTTP proxy for signalling with a partner MCPTT system in a different trust domain. Similarly, an MCVideo gateway server and an MCData gateway server provides the same function for the MCVideo and MCData services, respectively.
MCPTT service changes to support MC system interconnection: The following MCPTT procedures have been enhanced to support MCPTT interconnection: affiliation, emergency alert, pre-arranged group call, chat group call, common procedures, private call, remotely initiated group call, remote change of selected group, group regroup, user regroup, and the corresponding MCPTT gateway server procedures.
MCVideo service changes to support MC system interconnection: The following MCVideo procedures have been enhanced to support MCVideo interconnection: affiliation, ambient viewing, emergency alert, group call, private call, common procedures, remote change of selected group, group regroup, user regroup, and the corresponding MCVideo gateway server procedures.
MCData service changes to support MC system interconnection: The following MCData procedures have been enhanced to support MCData interconnection: affiliation, disposition notifications, emergency alert, Short Data Service procedures, File Download procedures, common procedures, IP connectivity, group regroup, user regroup, and the corresponding MCData gateway server procedures.
The requirements, architecture, protocol, and security aspects related to these enhancements are described in the following specifications:
The MCPTT service requirements are specified in TS 22.179 and TS 22.280;
The MCVideo service requirements are specified in TS 22.281 and TS 22.280;
The MCData service requirements are specified in TS 22.282 and TS 22.280;
The MCPTT service architecture (including information flows, procedures, and configuration) is specified in TS 23.379 and TS 23.280;
The MCVideo service architecture (including information flows, procedures, and configuration) is specified in TS 23.281 and TS 23.280;
The MCData service architecture (including information flows, procedures, and configuration) is specified in TS 23.282 and TS 23.280;
The security aspects of the MCPTT service are specified in TS 33.180;
The protocol aspects of the MCPTT service for call control and media plane are specified in TS 24.379 and TS 24.380 respectively;
The protocol aspects of the MCVideo service for call control and media plane are specified in TS 24.281 and TS 24.581 respectively;
The protocol aspects of the MCData service for call control and media plane are specified in TS 24.282 and TS 24.582 respectively;
The protocol aspects of MC services 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;
The protocol aspects of the MCPTT service for codecs and media handling are specified in TS 26.179;
The protocol aspects of MC services for policy and charging control are specified in TS 29.213 and TS 29.214;
The protocol aspects of MC services for data management related to MC service user profile are specified in TS 29.283;
Summary based on the input provided by Ericsson in SP-220320.
For Release 17, Mission Critical (MC) services support in the Isolated Operation for Public Safety (IOPS) mode of operation defines the features required to support MC services based on the availability of an IOPS MC system, e.g., for the case of a backhaul failure. The stage 2 work has been developed based on the study results captured in TR 23.778, stage 1 service requirements defined in TS 22.346, stage 2 work related to the definition of the IOPS mode of operation in TS 23.401, and the support of MC services defined in TS 23.280, TS 23.379, and TS 23.282.
Those features that have been completed are described in the following clause.
The functional architecture, procedures and information flows to support MC services in the IOPS mode of operation have been specified in TS 23.180. The addressed architecture requirements were focused on the case of a backhaul failure between the radio access network (RAN) and the macro Evolved Packet Core (EPC). For that, the IOPS MC system provides support for MC services in the IOPS mode of operation until the failure is recovered.
In this release, during the IOPS mode of operation the IOPS MC system supports the following MCPTT services: group call, emergency group call, private call and emergency private call. For the case of MCData services, only short data service is supported. MCVideo services are not supported in Release 17.
MC services in the IOPS mode of operation are specified based on the IP connectivity functionality. The IP connectivity functionality enables that MC services are provided by the MC service clients via the IOPS MC connectivity function.
The IP connectivity functionality defines that the IOPS MC connectivity function does not provide MC services to the MC service clients. Instead, it enables that MC service users are discovered by the IOPS MC connectivity function and get notified about the availability of other MC service users within the coverage of the IOPS Evolved Packet System (EPS). The IOPS MC connectivity function distributes then related IP traffic to discovered MC service UEs over IP unicast transmissions and/or multicast transmissions. An MC service UE supporting the IP connectivity functionality in the IOPS mode of operation enables transmitting the IP packets related to an MC service communication over the IOPS MC connectivity function.
Summary based on the input provided by CATT in SP-220899.
Multimedia Priority Service (MPS) to support priority communications by authorized users, i.e., emergency service personnel, during times of emergency situations and network congestion was originally specified in Release 8. In Release 17, a stage 1 feasibility study on MPS Phase 2 identified new priority voice, video, and data communication capabilities. Based on the results of the MPS Phase 2 feasibility study as documented in TR 22.854, the normative stage 1 requirements in TS 22.153 were updated and associated stage 2 and stage 3 features were defined in Release 17.
Stage 1 summary
The following is a summary of the new stage 1 features included in TS 22.153 Release 17:
MPS for MMTEL voice/video
Explicit stage 1 requirements were added for MPS for MMTEL voice and MMTEL voice conference calls for an authorized Service User using a UE with a subscription for MPS; and new requirements for MPS for MMTEL voice and MMTEL voice conference calls for an authorized Service User using a UE that does not have an MPS subscription, and MPS for all participants of an authorized MMTEL voice conference call. The corresponding extensions were also added for MPS for MMTEL video.
MPS for Data Transfer Service (DTS)
A new MPS for DTS feature was defined as a generic priority packet transport service that applies independently of the specific data application being used. In the case of EPS, MPS for DTS enables the prioritization of all traffic on the default bearer upon request. It may also apply to other bearers based on operator policy and regulatory rules. In the case of 5GS, MPS for DTS enables the prioritization of all traffic on the QoS Flow associated with the default QoS rule upon request. It may also apply to other QoS flows based on operator policy and regulatory rules. MPS for DTS is a specific example of Priority Data Bearer Service.
Attestation of Authorized MPS Priority
New stage 1 requirements were added for the attestation and verification of MPS authorization.
Stage 2 summary
The following is a summary of the new stage 2 features included in Release 17:
MPS for MMTEL voice/video
Enhancements were included in TS 23.228 based on the new stage 1 requirements for MPS for MMTEL voice and video conference calls. A conferencing AS permits an authorized host with an MPS (IMS) priority subscription to request an upgrade of the host itself, specific participants, or all participants including the host in the conference, whether participants have an MPS subscription or not.
MPS for DTS
A new MPS for DTS feature was specified in TS 23.401, TS 23.203, TS 23.501, TS 23.502, and TS 23.503 to support priority packet transport service that applies independently of the specific data application being used. MPS for DTS enables the prioritization of all traffic on the EPC default bearer and the 5GC QoS Flow associated with the default QoS rule upon requests received via an AF. Based on additional configuration in the PCF, prioritization may also be applied to other bearers and QoS Flows.
SBI Message Priority
TS 23.501 and TS 23.502 were enhanced to specify that 5GC service based messages carry a priority indication for the UE if the UE has a priority subscription. Specifications already supported the priority indication on service based messages via the AMF based on the receipt of an RRC connection request with a priority establishment cause. The enhancement informs all core network elements with service based interfaces to handle all activity from MPS subscribers with priority.
MPS support in the UE Configuration Update procedure
TS 23.502 was enhanced to support MPS subscription updates in the UE Configuration Update procedure so that a UE that receives an MPS subscription from the network does not have to wait for any re-registration events to obtain priority treatment.
Stage 3 summary
The following is a summary of the new stage 3 features and improvements included in Release 17:
MPS for MMTEL voice/video
TS 24.229 was enhanced to specify that all IMS core elements (e.g., the P-CSCF, I-CSCF, S-CSCF, MGCF, BGCF, MRFC, MRB, IBCF, ISC gateway and AS) adjust priority treatment based upon the most recently received Resource Priority Header field. This allows voice/video calls to be upgraded to MPS while in progress.
MPS for Data Transfer Service (DTS)
The new MPS for DTS feature was defined in support of stage 1 and stage 2 requirements for priority data, along with the associated PCC (Policy and Charging Control) related protocol and information element requirements, for both EPS and 5GS.
Voice Call Continuity (VCC)
In TS 24.237, the VCC procedure in the SCC AS was enhanced to prevent loss of priority for MPS voice calls across mobility events.
SBI Message Priority
TS 29.500 was enhanced to specify that 5GC service based messages carry a priority indication for the UE if either the UE has a priority subscription or has established an RRC connection with priority. The enhancement informs all core network elements on the service based interfaces that the activity is to be handled with priority.
MPS support in the UE Configuration Update procedure
TS 24.501 was enhanced to support MPS subscription updates in the UE Configuration Update procedure so that a UE that receives an MPS subscription from the network does not have to wait for any re-registration events to obtain priority treatment.