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…

 

5  Assumptions and architectural requirements

5.1  Assumptions

5.1.1  Service continuity

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:
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.
Up

5.1.2  Trust domain

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).
Up

5.2  Architectural requirementsWord‑p. 21

5.2.1  General architectural requirements

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.
Up

5.2.2  Roaming requirements

The MC applications can provide MC services to users in various PLMNs. Roaming is supported using EPC-level roaming or IMS-level roaming.
For EPC-level roaming, in order to prioritise 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).
Up

5.2.3  UE-to-network relay MC service requirements

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.
Up

5.2.4  MC service user profile requirements

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.
Up

5.2.5  MC service group affiliation and MC service group de-affiliationWord‑p. 22
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.
Up

5.2.6  GCS AS requirements for the MC servicesWord‑p. 23
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:
(not reproduced yet)
Figure 5.2.6-1: MC service on-network architecture showing MBMS
Up
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.
Up

5.2.7  Bearer management

5.2.7.0  General

The MC service UE shall use the following APNs:
  • an MC services APN for the SIP‑1 reference point;
  • an MC common core services APN for the HTTP‑1 reference point; and
  • an MC identity management service APN for the CSC‑1 reference point.
The value of each of these APNs:
  • may be the same or may differ;
  • may be the same as other non-MC services that have compatible QoS and PDN (see NOTE); and
  • shall be made available to the UE either via UE (pre)configuration or via initial UE configuration (see subclause 10.1.1) on a per HPLMN and optionally also a per VPLMN basis.
The MC service UE may utilise PDN access credentials as specified in TS 23.401 (e.g. PAP, CHAP) to access the PDNs identified by the MC service APN, the MC common core services APN and the MC identity management service APN. If PDN access credentials are required, then they shall be made available to the MC service UE via initial MC service UE configuration (see subclause 10.1.1) on a per APN basis.
The PDN connection to the APNs defined within the present subclause can be of type "IPv4", "IPv6" or "IPv4v6" (see TS 23.401). If a PDN connection to an APN defined within the present subclause is of type "IPv4v6" then the MC service client shall use configuration data to determine whether to use IPv4 or IPv6.
Up

5.2.7.1  MBMS bearer managementWord‑p. 24
When operating in systems that support MBMS functionality, the MC service can provide downlink MBMS delivery of MC service media.
When operating in systems that support MBMS functionality, the MC service can provide downlink MBMS delivery of application level control messages targeted towards multiple MC clients at the same time (e.g. floor idle and floor taken for MCPTT services).
MC service UEs can receive the traffic delivered via MBMS, regardless of whether or not they have any unicast radio bearers available.
When switching between different downlink bearers, the MC service UE shall preserve the reception context in order to eliminate or reduce to a minimum any interruption of service.
The MC service shall enable an MC service UE in an ongoing MC service group session that has just entered an area of media delivery via MBMS bearers to immediately start receiving the media for that MC service group session via MBMS.
The MC service server shall not map MC service group sessions to MBMS bearers that cannot provide the QoS required by the group.
An MC service UE that uses MBSFN transmission should be able to support eight MBSFN areas simultaneously on the same RF carrier.
Up

5.2.7.2  EPS bearer considerations

5.2.7.2.1  Considerations for the EPS bearer to the MC services PDN
If the PDN connection established during the initial attach by the MC service UE is to an APN other than the MC services APN, then prior to user authentication, the MC service UE shall establish another PDN connection to the MC services APN. PDN connection establishment can also be caused by a SIP registration request for one or more MC services.
The QCI value of 69 (as specified in TS 23.203) shall be used for the EPS bearer that transports SIP‑1 reference point messaging.
Up
5.2.7.2.2  Considerations for the EPS bearer to the MC common core services PDN and MC identity management service PDN
The QCI value 8 (as specified in TS 23.203) or better shall be used for the EPS bearer that transports HTTP‑1 reference point messaging.

5.2.8  External applications access to services in a MC systemWord‑p. 25
The MC system shall allow external applications to gain secure access to MC services by supporting authentication and authorization of external applications.

5.2.9  Migration |R15|

5.2.9.1  General

MC service interconnection needs to be provided between MC systems that wish to provide migration of their MC service users.
Migration of MC service users between any two MC systems can be on a bilateral or unilateral basis.
During migration of an MC service user to a partner MC system, media of the MC service user's calls may need to be routed to the MC service user's primary MC system e.g. for logging purposes.
Up

5.2.9.2  PLMN utilisation

Migrated MC service users should utilise the HPLMN of the partner MC system to access MC services in the partner MC system, however, utilising the HPLMN of the primary MC system is not precluded.
MC service users enabled for migration shall be provisioned with configuration that specifies which PLMNs may be used to migrate to different MC systems.
If the HPLMN of a partner MC system is different from the HPLMN of the primary MC system (i.e. migrating MC service users roam onto the HPLMN of the partner MC system), then:
  • EPC level roaming (see subclause 5.2.2) is needed between the HPLMN of the primary MC system and HPLMN of the partner MC system;
  • the HPLMN of the partner MC system needs to enable local break-out for the APNs specified in subclause 5.2.7 that identify the PDNs of the partner MC system; and
  • the EPS subscriptions of the HPLMN of the primary MC system utilised by the MC service users who are allowed to migrate to the partner MC system need to be provisioned with, and local break-out enabled for, the APNs specified in subclause 5.2.7 that identify the PDNs of the partner MC system.
If the HPLMN of the partner MC system and the HPLMN of the primary MC system are the same (i.e. migrating MC service users continue to use the HPLMN of their primary MC system), then:
  • the EPS subscriptions of the HPLMN of the primary MC system utilised by the MC service users who are allowed to migrate to the partner MC system need to be provisioned with the APNs specified in subclause 5.2.7 that identify the PDNs of the partner MC system.
Up

5.2.9.3  SIP core / IMS utilisationWord‑p. 26
Migrated MC service users should utilise the SIP core / IMS of the partner MC system.
Where connectivity and security policies allow, the same SIP core / IMS can be utilised to connect to the primary MC system and one or more partner MC systems.
For each partner MC system, MC service UEs of MC service users enabled for migration shall be provisioned with:
  • configuration that controls whether the MC service UE shall connect to the SIP core / IMS of the primary MC system or a different SIP core / IMS (i.e. SIP core / IMS of the partner MC system); and
  • where a different SIP core / IMS to the primary MC system's SIP core / IMS is to be connected to then the MC service UE shall also be configured with:
  • configuration required for the MC service UE to access the SIP core / IMS; and
  • credentials required for the MC service UE to register with the SIP core / IMS.
Up

5.2.10  Interconnection |R15|

5.2.10.1  General

MC service interconnection allows a first set of MC service users who are receiving MC service from a first MC system to take part in communications with a second set of MC service users, where this second set of MC service users are receiving MC service from a second MC system, and where the second MC system is in a different trust domain to the first MC system.

5.2.10.2  Connectivity

The MC service clients of the MC service users receiving MC service(s) from a first MC system and using MC service interconnection to take part in communication with MC service users in a second MC system require connectivity to only the identity management server in the second MC system.
IP connectivity is required between MC systems wishing to interconnect. The IP connectivity is used to carry the signalling and application plane protocols needed to provide MC service.
Up

5.2.10.3  MigrationWord‑p. 27
Interconnection may be used by a migrated MC service user who is receiving service from a partner MC system to take part in communication with MC service users in the primary MC system of that migrated MC service user.

5.2.10.4  Private calls

Where private calls take place using interconnection between MC service users who are receiving MC service in different MC systems, the MC system providing MC service to the calling MC service user will provide the controlling function for the private call.

5.2.10.5  Group calls

Where MC service users in a partner MC system of the group home MC system of an MC service group take part in group calls in that group, the group home MC system of the MC service group will provide the controlling function for the group call.

5.2.10.6  Group configuration

A partner MC system may apply local configuration to an MC service group configuration received from the primary MC system (i.e. the group home MC system).

5.2.10.7  MC system topology hiding

If an MC system requires internal network topology hiding, then this shall be achieved in the MC system by use of the following:
  • proxies for signalling plane functions; and
  • gateway MC service servers for application plane functions.

5.2.11  Use of priorities |R17|

5.2.11.1  Requested priority

The MC service system may allow the MC service client to request the priority of a communication by selecting the corresponding priority level. The MC service server can enforce the selected priority level in determining the application priority for resource allocation during communication establishment.
The use of the requested priority may vary depending on MC service provider's policy.

6  Involved business relationships

Based on the information in subclause 5.2.1 and subclause 5.2.2, Figure 6-1 shows the business relationships that exist and that are needed to support a single MC service user.
(not reproduced yet)
Figure 6-1: Business relationships for MC services
Up
The MC service user belongs to a single mission critical organization based on a MC service user agreement between the MC service user and the mission critical organization. The MC service user can have MC service user agreement and MC service arrangement directly with a single MC service provider.
The mission critical organization and the MC service provider can be part of the same organization, in which case the business relationship between the two is internal to a single organization. The mission critical organization can have MC service arrangements with several MC service providers. In this case, a MC service user of a mission critical organization is always served by only one MC service provider. The MC service provider can have MC service arrangements with several mission critical organizations. The MC service provider can have MC service user agreements and MC service arrangements with several MC service users.
The MC service provider and the home PLMN operator can be part of the same organization, in which case the business relationship between the two is internal to a single organization.
The home PLMN operator can have PLMN operator service arrangements with multiple MC service providers and the MC service provider can have PLMN operator service arrangements with multiple home PLMN operators. As part of the PLMN operator service arrangement between the MC service provider and the home PLMN operator, PLMN subscription arrangements can be provided which allows the MC service UEs to register with home PLMN operator network.
The home PLMN operator can have PLMN roaming agreements with multiple visited PLMN operators and the visited PLMN operator can have PLMN roaming agreements with multiple home PLMN operators.
Where mutual aid operates between MC service providers, Figure 6-2 shows the required additional relationship. An MC service user can only affiliate to groups of the partner MC service provider:
  • if such a service provider agreement exists; or
  • subject to authorisation for a specific group membership from the partner MC service provider.
(not reproduced yet)
Figure 6-2: Additional business relationships for mutual aid
Up
The primary and partner MC service providers do not need to be served by the same home SIP core operator in order to support mutual communication and mutual aid when interconnection between the SIP cores is available.
An example of the usage of these business relationships is elaborated for two users, one resident on its primary MC service provider and one providing mutual aid within the same group:
User A is a user on MC service provider X in group M. The relationships are as follows:
  1. user A has user configuration established with MC service provider X and forms part of group M;
  2. user A uses a PLMN subscription arrangement with PLMN operator R provided by MC service provider X; and
  3. MC service provider X has a PLMN operator service arrangement with PLMN operator R.
User B is a user on MC service provider Y and joins group M as part of a mutual aid:
  1. user B has user configuration established with MC service provider Y and forms part of its own set of groups relating to MC service provider Y;
  2. user B uses a PLMN subscription arrangement with PLMN operator S provided by MC service provider Y;
  3. MC service provider Y has a PLMN operator service arrangement with PLMN operator S;
  4. MC service provider Y has a service provider agreement with MC service provider X that allows user B to participate within group M; and
  5. PLMN operator S has a PLMN roaming agreement with PLMN operator R allowing user B to roam to PLMN operator R.
Up

Up   Top   ToC