J.2 Info package for transfer of MCPTT information

24.3793GPPMission Critical Push To Talk (MCPTT) call controlProtocol specificationRelease 18TS

J.2.1 Scope

This clause contains the information required for the IANA registration of info package g.3gpp.mcptt-info in accordance with IETF RFC 6086 [64].

J.2.2 g.3gpp.mcptt-info info package

J.2.2.1 Overall description

The MCPTT client request for MCPTT emergency call origination can also optionally request the origination of an MCPTT emergency alert. Similarly, the MCPTT client request for MCPTT emergency call cancellation can also optionally request the cancellation of an MCPTT emergency alert. A mechanism to inform the MCPTT client that one of the requested actions has been rejected by the controlling MCPTT function is needed to both inform the MCPTT user that one of their requested actions has been rejected and to keep the emergency and imminent peril related state machines maintained by the MCPTT client updated appropriately. Note that a SIP 200 OK has to be sent in the case where the MCPTT emergency call origination request or cancellation request is accepted by the controller to allow the MCPTT user to initiate the MCPTT emergency call and receive updated priority even if the accompanying MCPTT alert request is rejected.

An MCPTT client request for an MCPTT imminent peril call when the targeted MCPTT group is in an in-progress emergency state also needs special handling, as in this case, the call request will be accepted but the MCPTT client needs to be informed that the MCPTT user will be joined to an in-progress MCPTT emergency group call instead of the requested MCPTT imminent peril group call to keep the emergency and imminent peril related state machines maintained by the MCPTT client updated appropriately.

J.2.2.2 Applicability

This package is used to transport emergency call, imminent peril and emergency alert indications from the controlling function to the MCPTT client

J.2.2.3 Appropriateness of INFO Package Usage

A number of solutions were discussed for the transportation of the emergency call, imminent peril and emergency alert indications from the controlling function to the MCPTT client. The solutions were:

1) Use of the session related methods (e.g. SIP 200 (OK) response to the SIP INVITE request).

2) Use of the SIP MESSAGE method.

3) Use of the SIP INFO method as described in IETF RFC 6086, by defining a new info package.

The result of the evaluation of the above solutions were:

1) To include such a large amount of data in a SIP 200 (OK) response to an SIP INVITE request could cause problems with the size of the SIP 200 (OK) response resulting in packet fragmentation.

2) The use of the SIP MESSAGE request would result in that the recommended value of size of the information transferred by the SIP MESSAGE request would be exceeded.

3) The use of SIP INFO request was found as the most appropriate solution since the SIP INFO request could be sent in the existing SIP session.

J.2.2.4 Info package name

g.3gpp.mcptt-info

J.2.2.5 Info package parameters

None defined

J.2.2.6 SIP options tags

None defined

J.2.2.7 INFO message body parts

The MIME type of the message body carrying participant identities is application/vnd.3gpp.mcptt-info+xml. The application/vnd.3gpp.mcptt-info+xml MIME type is defined in 3GPP TS 24.379.

When associated with the g.3gpp.mcptt-info info package, the Content-Disposition value of the message body carrying mcptt information is "info-package".

J.2.2.8 Info package usage restrictions

None defined.

J.2.2.9 Rate of INFO Requests

Single INFO request generated after session set up.

J.2.2.10 Info package security considerations

The security is based on the generic security mechanism provided for the underlying SIP signalling. No additional security mechanism is defined.

J.2.2.11 Implementation details and examples

UAC generation of INFO requests: See 3GPP TS 24.379: "Mission Critical Push To Talk (MCPTT) call control; Protocol specification".

UAS processing of INFO requests: See 3GPP TS 24.379: "Mission Critical Push To Talk (MCPTT) call control; Protocol specification"

EXAMPLE: A controlling MCPTT function will receive a SIP INVITE request or SIP (re-)INVITE request containing a request for an emergency call (with or without an alert) or an imminent peril call. When an emergency call has been authorised but an optional request for an emergency alert has been determined to be unauthorised, the controller will respond with a SIP 200 (OK) response to indicate acceptance of the call request and return an indication of the rejection of the emergency alert request in a SIP INFO request carrying the application/vnd.3gpp.mcptt-info+xml MIME body using the g.3gpp.mcptt-info info package.

Annex K (informative):
IANA UDP port registration form

This annex contains information to be provided to IANA for MCPTT Off-Network Protocol (MONP) UDP port registration. The following information is to be used to register MONP user port number and service name in the "IANA Service Name and Transport Protocol Port Number Registry" and specifically "Service Name and Transport Protocol Port Number Registry". This registration form can be found at: https://www.iana.org/form/ports-services.

Assignee Name

<MCC name>

Assignee E-mail

<MCC email address>

Contact Person

<MCC name>

Contact E-mail

<MCC email address>

Resources required

Port number and service name

Transport Protocols

UDP

Service Code

Service Name

3gpp-monp

Desired Port Number

Description

Mission Critical Push To Talk over LTE (MCPTT) Off-Network Protocol (MONP) is a 3GPP control protocol used by a MCPTT client hosted on a User Equipment (UE). MONP facilitates the MCPTT public safety service between MCPTT clients hosted on UEs communicating using IP using a single physical network segment, separated from Internet and any other IP network. The network segment is wireless network segment and UEs are mobile devices. The MCPTT public safety service offers half-duplex voice communication.

Reference

3GPP TS 24.379

Defined TXT keys

N/A

If broadcast/multicast is used, how and what for?

When performing off-network group calls, the MCPTT client initiates the group call to an MCPTT Group by sending a group call announcement message. The group call announcement message is a Mission Critical Push To Talk over LTE (MCPTT) Off-Network Protocol (MONP) message which is sent as a UDP message to a multicast IP address of the MCPTT group so that it is ensured that the MONP messages sent for the corresponding MCPTT group are only received by the MCPTT group’s members.

If UDP is requested, please explain how traffic is limited, and whether the protocol reacts to congestion.

The number of Mission Critical Push To Talk over LTE (MCPTT) Off-Network Protocol (MONP) messages that need to be sent between MCPTT clients depends upon the number of members of the MCPTT group. MONP employs a back-off mechanism to defer transmission of another MONP message once a MONP message is received. MONP controls the number of messages transmitted within a certain, configurable amount of time, thus averting congestion. At maximum a few MONP messages per second are expected in communication between MCPTT clients. MONP does not support any reaction to congestion.

If UDP is requested, please indicate whether the service is solely for the discovery of hosts supporting this protocol.

Mission Critical Push To Talk over LTE (MCPTT) Off-Network Protocol (MONP) is not used solely for discovery of hosts supporting this protocol.

Please explain how your protocol supports versioning.

Mission Critical Push To Talk over LTE (MCPTT) Off-Network Protocol (MONP) does not support versioning.

If your request is for more than one transport, please explain in detail how the protocol differs over each transport.

N/A

Please describe how your protocol supports security. Note that presently there is no IETF consensus on when it is appropriate to use a second port for an insecure version of a protocol.

Mission Critical Push To Talk over LTE (MCPTT) Off-Network Protocol (MONP) does not support security. MONP relies on the security mechanisms of the lower layers.

Please explain why a unique port assignment is necessary as opposed to a port in range (49152-65535) or existing port.

As a general principle, 3GPP protocols use assigned User Ports, e.g. GTP-C uses UDP port number 2123, GTP-U uses UDP port number 2152, S1AP uses SCTP port number 36412, X2AP uses SCTP port number 36422, WLCP uses 36411. A dynamic port number (i.e. 49152 to 65535) cannot be used for the Mission Critical Push To Talk over LTE (MCPTT) Off-Network Protocol (MONP) because of the nature of communication on a single physical network segment, separated from Internet and any other IP network. The requirement of MONP to continuously listen for incoming messages needs an always active listener port. There is no local server that is administering the use of emphemeral ports in the MONP architecture, so there would be no way for one MCPTT client to know that a port is already being used by another MCPTT client. Communication can potentially be long-lived and MCPTT clients could leave and rejoin the calls.

Please explain the state of development of your protocol.

Protocol Standard definition. No implementation exists yet.

If SCTP is requested, is there an existing TCP and/or UDP service name or port number assignment? If yes, provide the existing service name and port number.

N/A

What specific SCTP capability is used by the application such that a user who has the choice of both TCP (and/or UDP) and SCTP ports for this application would choose SCTP? See RFC 4960 section 7.1.

N/A

Please provide any other information that would be helpful in understanding how this protocol differs from existing assigned services

This protocol is between the UEs communicating using IP over a single physical network segment, separated from Internet and any other IP network. An MCPTT public safety service offered by the MCPTT clients hosted by the UEs is for public safety. The MCPTT public safety service offers half-duplex voice communication.

This differs from existing protocols in 3GPP where UDP ports have been requested, as those protocols have been either between the UE and network or between network elements.

Annex L (normative):
MCPTT session control specific concepts for the support of mission critical services over 5GS