The application services layer includes application functions of one or more MC services and any required supporting functions grouped into common services core.

Common services core is composed of the following functional entities:

• for common services, a configuration management server as described in subclause 7.4.2.2.2, a group management server as described in subclause 7.4.2.2.4, an identity management server as described in subclause 7.4.2.2.6 and a key management server as described in subclause 7.4.2.2.8; and
• for signalling control, an HTTP proxy as described in subclause 7.4.3.3.2 and an HTTP server as described in subclause 7.4.3.3.3.

MC services are composed of the following functional entities:

• an MC service server as described in subclause 7.4.2.3.2 with relevant application functions of the corresponding MC service defined in the corresponding MC service TS.

This subclause describes five different deployment scenarios in which different administration of MC service, SIP core and EPS are described, together with the sensitivities of identities and other forms of signalling in those scenarios. In each of these scenarios, the owner of the devices at each plane may be different from the organisation that administers these devices. For example, the MC service provider may own some RAN components within the EPS even when the EPS is administered by the PLMN operator, and the MC service UE may be owned by an organisation that is independent from PLMN and MC service providers.

In this scenario, all planes (application services layer, SIP core and EPS) are administered by the same party. This is illustrated in Figure 9.2.2.1.2-1 below.

Although the identities in each plane are separate according to clause 8, there is no particular sensitivity of identities and other information at the application plane, and these may be exposed to the SIP core and the EPS. All authorisation and authentication mechanisms at each plane, i.e. the application services layer, SIP core and EPS, shall be separate, but there may be no need for any restrictions in how these are stored and managed; for example the same entity could provide services to each of the application services layer, SIP core and EPS.

In this scenario, as illustrated in Figure 9.2.2.1.3-1, the MC service provider is separate and independent from the PLMN operator, and the MC service is administered independently of the EPS and SIP core. The PLMN operator administers the EPS and the SIP core.

The MC service provider may require that all application services layer identities and other sensitive information are hidden both from the SIP core and the EPS. When required by the MC service provider, all authentication and authorisation mechanisms, including security roots, at the application services layer are hidden from and not available to the PLMN operator.

In this scenario, as illustrated in Figure 9.2.2.1.4-1, the MC service provider administers the SIP core, and the MC services and SIP core are independent of the PLMN operator.

The MC service provider may require that all identities and other sensitive information at the application services layer are hidden from the EPS. The MC service provider need not hide the identities and signalling at the application services layer from the SIP core. However the MC service provider may require that identities and other sensitive information between SIP core and SIP client in the MC service UE are also hidden from the EPS. All authentication and authorisation mechanisms, including security roots, at both application services layer and at SIP signalling plane may need to be hidden from, and not available to, the PLMN operator.

In this scenario, as illustrated in Figure 9.2.2.1.5-1, the SIP core is partially administered by both parties, for example when the SIP core registrar is administered by the MC service provider, but the SIP core registrar finder and proxy is administered by the PLMN operator.

The MC service provider may require that all identities and signalling at the application services layer are hidden from the EPS, and may require identities and other sensitive information to be hidden from the PLMN operator administered part of the SIP core. All authentication and authorisation mechanisms, including security roots, at the application services layer may need to be hidden from, and not available to, the PLMN operator.

In this scenario, the PLMN operator administers the SIP core. However, the identities used by the SIP core (IMPI and IMPU) for MC service UEs served by the MC service provider are provided from the SIP database of the MC service provider.

The MC service provider may require that all identities and signalling at the application services layer are hidden from the SIP core and EPS. When required by the MC service provider, all authentication and authorisation mechanisms, including security roots, at the application services layer may need to be hidden from, and not available to, the PLMN operator. The security roots (authentication keys) required for access to the signalling control plane are not available to the PLMN operator as these are held in the MC service provider's SIP database. However, derived parameters e.g. authentication vectors are provided to the SIP core to allow signalling control plane authentication to take place.

This subclause describes two different scenarios in which bearers are controlled by access to Rx by either the SIP core or the MC service server. These may provide suitable models for each of the scenarios listed in subclause 9.2.2.1. However, there is no direct correlation of any of the scenarios described in this subclause to each of the scenarios described in subclause 9.2.2.1.

In this scenario, bearer control is performed by the SIP core alone, as shown in Figure 9.2.2.3.2-1 below.

In this scenario, bearer control is performed by the MC service server alone, as shown in Figure 9.2.2.3.3-1 below.