Service continuity shall be supported between on-network MC services and UE-to-network relay MC services. The following TS 23.237 procedures are needed:

• Originating sessions that use only PS media flow(s) as defined in subclause 6.2.1.3 of TS 23.237.
• Terminations sessions that use only PS media flow(s) as defined in subclause 6.2.2.3 of TS 23.237.
• Remote Leg Update as defined in subclause 6.3.1.5 of TS 23.237.
• PS-PS Access Transfer with full media transfer as defined in subclause 6.2.2.1 of TS 23.237.

The MC service UE, prior to going out of E-UTRAN coverage, should attempt to make use of a ProSe UE-to-network relay to support service continuity.

For an MC system, the trust domain consists of one or more MC service functions that are administered by the same or different service providers (e.g. MC service provider, PLMN operator) that have an agreement to share sensitive information. For the MC system architecture, the following rules are implied for functions in different trust domains:

• A public user identity shall not identify an MC service user in a different trust domain (see subclause 8.3.1);
• A public service identity shall not identify an MC service group ID in a different trust domain (see subclause 8.3.2);
• A SIP database shall not pass responses to a registrar or registrar finder in a different trust domain (see subclause 7.4.3.2.1); and
• An HTTP proxy shall not pass requests or responses to another HTTP proxy, an HTTP server or an HTTP client in a different trust domain (see subclause 7.4.3.3.2).

General MC service architectural requirements include:

1. To develop economies of scale, it will be useful if PLMN operators can reuse the MC service architecture for non-public safety customers that require similar functionality. These PLMN operators may want to integrate many components of the MC service solution with their existing network architecture.
   Hence a functional decomposition of MC service architecture into distinct logical functions is required.
2. The MC service architecture should enable an application plane and signalling control plane split for the provisioning of the MC service.
3. To enable parts of the MC service architecture to be shared for other applications, the architecture should enable the group management functions (e.g. admission control; linking of groups;) to be implemented on a separate node from the main application functions of the MC service (e.g. "call" setup/termination; allocation of TMGI to UE; floor control;).
4. There is a need to promptly form (and release) groups of users that span multiple public safety network administrations. To enable this, the MC service architecture should provide the relevant interfaces between public safety networks.

The MC applications can provide MC services to users in various PLMNs. An MC service UE may connect to PLMNs using EPC-level roaming, IMS-level roaming or local subscription. For EPC-level roaming, in order to prioritize for network selection PLMNs that allow migration to partner MC systems, the MC service UE's User Preferred PLMN Selector list (see TS 22.011) may be configured with a list of PLMNs that can be used to migrate to one or more partner MC systems (see subclause 5.2.9.2).

To support the requirement that a public safety ProSe UE-to-network relay shall be able to restrict the relayed group communication on a per group basis, the MC service should be able to provide a means for an MC service administrator to configure a ProSe UE-to-network relay with a list of allowed MC service groups. For each allowed MC service group, a unique associated relay service code should be allocated and it may be provided to the relay UE from MC service server or DPF.

The MC service user profile shall:

• be provisioned subject to the user authentication by the identity management server;
• be available at configuration management server;
• be available at MC service servers with the corresponding user profile information;
• be associated with an MC service user; and
• contain an index to uniquely distinguish the MC service user profile from other MC service user profiles associated to the same MC service user.

For the set of MC service user profiles associated to a single MC service user, one of the MC service user profiles shall be indicated as the pre-selected MC service user profile to the MC service client and the MC service server. The MC service user shall be able to:

• change the pre-selected MC service user profile; and
• change the selected MC service user profile.

The MC service user profile may be modified at the configuration management server.

The MC system shall support affiliation and de-affiliation to an MC service group for one or more MC services. For affiliation and de-affiliation, the MC service client shall indicate interest in one or more MC services for the MC service group. For a single MC service group configured for multiple MC services, the affiliation and de-affiliation shall be performed as per the MC service selected by the MC service user. For individual MC service group affiliation and MCservice group de-affiliation, the requirements are specified in the corresponding MC service TS. MC service group affiliation can be achieved through the following two methods:

1. Explicit affiliation: An MC service client indicates interest in one or many MC service groups to the MC service server. This interest may be initiated either by an MC service user using the MC service UE, or by an automatic procedure within the MC service client that indicates that the MC service user is interested in the MC service group at that MC service client. An authorized MC service user may remotely modify another MC service user's affiliation to an MC service group.
2. Implicit affiliation: An MC service user's affiliations to MC service groups are determined through configurations and policies within the MC service and performed by the associated MC service server.

The MC service server may refuse a request for affiliation from an MC service user to an MC service group, in which case the MC service user will be unable to take part in the requested MC service associated with that MC service group, and the MC service client should make the MC service user aware that the MC service user is not affiliated to the MC service group for the requested MC service. The MC service server may also de-affiliate an MC service client from an MC service group following a relevant trigger condition. MC service group de-affiliation indicates that the MC service user is no longer interested in that MC service group, either at the MC service client, or across all MC service clients depending on MC service group configuration, and therefore is unable to perform any actions that are associated with an affiliated member (e.g. receive media, notifications). MC service group de-affiliation can occur due to either an MC service client's explicit request, or implicitly i.e. changed by the MC service server as the result of another action e.g. the MC service user logging off. When the MC service user is logged off from the MC service, all affiliations shall be revoked in the MC service server even if no explicit de-affiliation signalling is sent.

Point to multipoint broadcast offered by the LTE MBMS technology is well suited to group communications, which form a major part of the public safety related communications. The MC service on-network architecture, is based in part on TS 23.468 with the MC service server assuming the function of the GCS AS and can be represented (in a simplified diagram) as shown in Figure 5.2.6-1:

The MC service server is shown being bundled with the GCS AS within the same network entity. It is illustrated this way for simplicity of the diagram. MC service media content is transmitted via LTE bearers, which are communication pipes with one end in the MC service server and the other end in the MC service UE. The uplink bearers are always allocated as unicast, but the downlink bearers can be allocated as unicast or as MBMS bearers, or both. An MBMS bearer (both network and radio part) is uniquely identified via a TMGI or via a combination of a TMGI and a flow identifier (see TS 23.246). The MC service server is capable, via the MB2 interface, to request the creation of MBMS bearers and associate a unique TMGI or a combination of a TMGI and a flow identifier (see TS 23.468). The MC service server may determine the MBMS broadcast area based on the cell identities of the affiliated group members received over GC1. The MC service server may determine for a user the switching from MBMS bearer to unicast bearer based on the information reported over GC1.