Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 23.280  Word version:  17.5.0

Top   Top   Up   Prev   Next
1…   5…   7…   7.4…   7.5…   8…   9…   10…   10.1.2…   10.1.3…   10.1.5…   10.2…   10.2.3…   10.2.5…   10.3…   10.7…   10.7.3…   10.7.3.7…   10.7.3.10…   10.8…   10.8.4…   10.9…   10.9.3…   10.9.3.8…   10.10…   10.11…   10.12…   10.13…   10.13.3…   10.14…   10.15…   10.15.3…   A…   B…

 

9  Application of functional model to deploymentsWord‑p. 51

9.1  General

This clause describes the application of the functional model, described in clause 7, to on-network and off-network deployments. It also describes deployment scenarios that highlight some of the possible variations in the way that the functional model can be applied in different situations.

9.2  Architecture model and deployment scenarios for on-network operations

9.2.1  On-network architectural model

9.2.1.1  On-network architectural model diagram

Figure 9.2.1.1-1 below is the on-network architectural model for the MC system solution, where the MC system provides one or more MC services via a single PLMN.
(not reproduced yet)
Figure 9.2.1.1-1: On-network architectural model
Up

9.2.1.2  Application services layerWord‑p. 52
9.2.1.2.1  Overview
The application services layer includes application functions of one or more MC services and any required supporting functions grouped into common services core.
9.2.1.2.2  Common services core
Common services core is composed of the following functional entities:
Up
9.2.1.2.3  MC services
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.

9.2.1.3  SIP coreWord‑p. 53
The SIP core provides rendezvous (contact address binding and URI resolution) and service control (application service selection) functions. It is composed of the following functional entities:
Up

9.2.1.4  EPS

The EPS provides point-to-point and point-to-multipoint bearer services with QoS.

9.2.1.5  UE 1

UE 1 is:
  • an MC service UE in on-network mode supporting bearer services and application(s) related to one or more MC service;
  • an MC service UE that acts as ProSe UE-to-network relay; or
  • both of the above.
When acting as an MC service UE in on-network mode supporting bearer services and application(s) related to one or more MC services, UE 1 is composed of the same functional entities as for UE 2, as described in subclause 9.2.1.6, without the support of ProSe capabilities.
Up

9.2.1.6  UE 2

UE 2 is a device using ProSe UE-to-network relay, and supporting application(s) related to one or more MC services. It is composed of the following functional entities:
Up

9.2.2  Deployment scenarios

9.2.2.1  Administration of MC service, SIP core and EPS

9.2.2.1.1  General
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.
Up
9.2.2.1.2  Common administration of all planes
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.
(not reproduced yet)
Figure 9.2.2.1.2-1: Common administration of all services by one operator
Up
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.
Up
9.2.2.1.3  MC service provider separate from SIP core and EPSWord‑p. 54
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.
(not reproduced yet)
Figure 9.2.2.1.3-1: MC service provider administers MC service separately from SIP core and EPS
Up
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.
9.2.2.1.4  MC service provider administers SIP core, separate from EPSWord‑p. 55
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.
(not reproduced yet)
Figure 9.2.2.1.4-1: MC service provider provision of SIP core, separate domain from EPS
Up
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.
Up
9.2.2.1.5  SIP core partially administered by both PLMN operator and MC service provider
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.
(not reproduced yet)
Figure 9.2.2.1.5-1: MC service provider partial provision of SIP core, separate domain from EPS
Up
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.
9.2.2.1.6  PLMN operator administers SIP core with SIP identities administered by MC service providerWord‑p. 56
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.
(not reproduced yet)
Figure 9.2.2.1.6-1: MC service provider provides identities to PLMN operator SIP core
Up
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.
Up

9.2.2.2  MC service user database, SIP database and HSSWord‑p. 57
Figures 9.2.2.2-1 to 9.2.2.2-4 show the possible deployment scenarios of the MC service user database and SIP database, including collocation with the HSS.
The MC service user database may be combined with an HSS in some deployment scenarios (e.g. when the MC service provider and the PLMN operator are part of the same trust domain).
The MC service user database may be a user data repository (UDR) in deployment scenarios when the UDC architecture is applied (see TS 23.335), in that case the MC service server and the configuration management server are assumed to be application front-ends and the Ud interface is used to access data from the repository.
(not reproduced yet)
Figure 9.2.2.2-1: Collocation of MC service user database and SIP database with HSS
Up
The HSS depicted in Figure 9.2.2.2-1 can be deployed either in the PLMN operator's network or the MC service provider's network.
(not reproduced yet)
Figure 9.2.2.2-2: Shared PLMN operator and MC service provider based deployment of MC service - SIP database collocated with HSS with separate MC service user database
Up
The MC service user database depicted in Figure 9.2.2.2-2 can be deployed in the PLMN operator's network or the MC service provider's network, and the HSS depicted in Figure 9.2.2.2-2 can be deployed in the same or different network to the MC service user database i.e. PLMN operator's network or the MC service provider's network.
(not reproduced yet)
Figure 9.2.2.2-3: Shared PLMN operator and MC service provider based deployment of MC service - MC service user database and SIP database deployed together, with separate HSS
Up
The MC service user database and SIP database depicted in Figure 9.2.2.2-3 can be deployed in the PLMN operator's network or the MC service provider's network, and the HSS depicted in Figure 9.2.2.2-3 can be deployed in the same or different network to the MC service user database i.e. PLMN operator's network or the MC service provider's network.
(not reproduced yet)
Figure 9.2.2.2-4: Shared PLMN operator and MC service provider based deployment of MC service - separate HSS, MC service user database and SIP database
Up
Each of the MC service user database, SIP database and HSS depicted in Figure 9.2.2.2-4 can be deployed in the same or different networks i.e. PLMN operator's network or the MC service provider's network.

9.2.2.3  Control of bearers by SIP core and MC service serverWord‑p. 60
9.2.2.3.1  General
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.
Up
9.2.2.3.2  Control of bearers by SIP core
In this scenario, bearer control is performed by the SIP core alone, as shown in Figure 9.2.2.3.2-1 below.
(not reproduced yet)
Figure 9.2.2.3.2-1: Bearer control by SIP core
Up
9.2.2.3.3  Control of bearers by MC service server
In this scenario, bearer control is performed by the MC service server alone, as shown in Figure 9.2.2.3.3-1 below.
(not reproduced yet)
Figure 9.2.2.3.3-1: Bearer control by MC service server
Up

9.3  Architecture model for off-network operationsWord‑p. 61

9.3.1  Off-network architectural model diagram

Figure 9.3.1-1 shows the off-network architectural model for the MC system solution for inter-UE communication, where no relay function is used.
(not reproduced yet)
Figure 9.3.1-1: Off-network architectural model for inter-UE communication where no relay function is used
Up
Figure 9.3.1-2 shows the off-network architectural model for the MC system solution for configuration management and group management.
(not reproduced yet)
Figure 9.3.1-2: Off-network architectural model for configuration management and group management
Up
The offline common services server could be the same entity (or set of entities) as the common services core. In this case the configuration management server shall not configure to the same user on the same UE, with parameters provisioned by offline and online configuration simultaneously. The configuration management server shall not configure to the same user on the same UE for the same parameters by using CSC‑11 and CSC‑4 reference points simultaneously.
The entities within this model are described in the following subclauses and a full functional model is given in subclause 7.3.2.
Up

9.3.2  UE 3

The UE 3 is a UE using ProSe and supporting application(s) related to off-network MC service, and is composed of the following functional entities:
  • for MC services, MC service clients as described in subclause 7.4.2.3.1 with relevant application functions of the specific MC service defined in the corresponding MC service TS;
  • for signalling control, a signalling user agent as described in subclause 7.4.3.1.1;
  • for configuration management, a configuration management client as described in subclause 7.4.2.2.1; and
  • for group management, a group management client as described in subclause 7.4.2.2.3.
Up

9.3.3  UE 4Word‑p. 62
The UE 4 represents one or more UEs with the same functionality as UE 3.

9.3.4  Offline common services server

The offline common services server supports configuration applications related to MC service, and is composed of the following functional entities:

9.4  Architecture model for roaming

Roaming is achieved using either:

Up   Top   ToC