For the purposes of the present document, the terms given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905. MC gateway UE: MC client: MC server: Non-3GPP device: CSC client: CSC server: MC gateway client: MC gateway UE server:

For the purposes of the present document, the following symbols apply:

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.

The MC gateway UE may provide several sub-functions like an MC gateway UE user device connecting function, an MC gateway UE network function, an MC gateway UE user QoS handling function, an MC gateway UE exposure function, an MC gateway UE MBMS support function and other functions. A functional architecture for the MC gateway UE may help to develop proper mechanisms and procedures. List of key issues:

• Clarify the need to define a functional architecture for the MC gateway UE.
• Describe the overall functional architecture and the details of the single elements from that architecture.

A control mechanism for connecting non-3GPP devices with an MC gateway UE is needed as not all devices should be connected with all MC gateway UEs. An authorized usage of an MC gateway UE by clients and users is needed as well as a control mechanism on how many MC gateway UEs can be used by the same MC service user/client. If a connection related temporary identifier and an explicit login procedure is required (e.g. for traffic routing) needs to be clarified. List of key issues:

• Clarify how to authorize the use of non-3GPP devices by the MC gateway UE.
• Clarify how to control MC service user/client use of multiple MC gateway UEs and to control the related traffic aggregation.
• Clarify whether there is a need for an explicit login procedure and assignment of a connection related temporary non-3GPP device ID.

The mission critical user identity (or MC ID) is the identity that an MC service user presents to the identity management server during a user authentication transaction (not necessarily tied to a single mission critical service). The MC service user identity (or MC service ID) is used as a globally unique identifier within the MC service that identifies an MC service user. The MC ID and the MC service ID may be the same. The SIP signalling control plane uses a private user identity to authenticate the signalling user agent and one or more public user identities for routing of signalling messages in the SIP core. There are several relationships between the MC service ID(s) and the public user identity(ies). List of key issues:

• Clarify whether the MC ID can be used on non-3GPP devices connected to the MC system via an MC gateway UE. Identify impacts to existing authentication procedures.
• Clarify whether the MC service ID can be used on non-3GPP devices connected to the MC system via an MC gateway UE. Identify impacts or limitations on existing procedures in the application plane.
• Elaborate how and if SIP signalling plane identities can be used by non-3GPP devices connected to the MC system via an MC gateway UE.
• Elaborate the impacts regarding the current relationships between SIP signalling plane identities and application plane identities.
• Investigate whether there is a need for additional application plane identities to support non-3GPP devices connected to network via an MC gateway UE.

If non-3GPP devices are connected to the MC system via an MC gateway UE, then MBMS support should be supported. MBMS support is required for both, MC service clients residing on a UE acting as MC gateway UE and for MC service clients residing on a non-3GPP device. List of key issues:

• Clarify how MBMS transmissions can be supported for MC service clients operating on non-3GPP devices via an MC gateway UE.
• Clarify whether there any implications on switching between unicast and multicast.
• Clarify how the MC gateway UE forwards the MBMS downlink traffic to the corresponding MC service clients behind the MC gateway UE.
• Clarify whether the MBMS support for MC service client residing on a non-3GPP devices should be transparent for network, i.e. the network need not consider whether the MC service client residing on a non- 3GPP device is connected via an MC gateway UE or not while using MBMS bearers, to minimize the impact on the existing MC system.

User data traffic and signalling information needs to be routed to/from user/clients residing on non-3GPP devices. The MC gateway UE needs to deal with multiple non-3GPP devices on one side and with multiple bearers (LTE) and 5G QFIs on the network side. The communication content should be unchanged, E2E encryption should be supported. List of key issues:

• Clarify how the MC gateway UE routes and maps the traffic data and signalling information between non-3GPP devices and the network.
• Clarify whether there are any limitations in the MC gateway UE network connectivity aspects like max. number of PDU sessions, max. QFIs per PDU session etc.
• Elaborate how independent QoS and priority treatment of each communication per MC service client is enabled for a MC service user behind an MC gateway UE.
• Clarify how the content of a MC service user/client communication beyond an MC gateway UE remains unchanged.
• Clarify how end-to-end encryption (E2EE) is enabled for MC service users/clients residing on non-3GPP devices.

An MC service client can use multiple MC gateway UEs that are bound to the same MC system while using the associated MC service per gateway. Potential impacts to the functional architecture and/or the MC service client capabilities are to be studied to develop proper mechanisms and procedures. List of key issues:

• Clarify the potential impact to the MC service client capabilities when using multiple MC gateway UEs.
• Clarify the potential impact to the MC gateway UE capabilities in a multi MC gateway UE environment.
• Describe the functional architecture supporting more than one MC gateway UE, as extension of the single MC gateway UE functional architecture.

Location management server may not be aware whether the MC service clients are residing on 3GPP devices or non 3GPP-devices when providing the location reporting configuration and when requesting the location information from the location management client. The MC clients residing on the non-3GPP devices may get the Location reporting configuration containing the trigger criteria related to 3GPP access network related location parameters. There may be some issues if the MC clients detects that it cannot handle the location reporting trigger criteria related to the 3GPP access network information or if it cannot provide the requested location information related to the 3GPP access network. List of key issues:

• Whether and how the 3GPP access network related location trigger criteria are handled
• Clarify how the 3GPP access network related location information of MC service clients residing on non-3GPP devices is known to the MC system when required.