Content for  TS 23.280  Word version:  19.1.0

Top   Top   Up   Prev   Next
1…   5…   5.2.8…   6   7…   7.3.2   7.4…   7.4.3…   7.5…   8…   9…   9.2.2……   9.3…   10…   10.1.2…   10.1.3………   10.1.5…   10.1.6…   10.2…   10.2.3………   10.2.5…   10.2.7…   10.3…   10.6…   10.7…   10.7.3……………   10.8…   10.8.4…   10.8.5…   10.9…   10.9.3………………………   10.10……   10.10.2…   10.10.3………   10.11…   10.11.5…   10.12…   10.13…   10.13.3…   10.13.7…   10.13.10…   10.14…   10.15…   10.15.3………   10.16…   10.17…   11…   11.3…   11.5…   11.5.2…   11.5.3……   11.5.4…   A…   B…   C…


5  Assumptions and architectural requirementsp. 24

5.1  Assumptionsp. 24

5.1.1  Service continuityp. 24

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.

5.1.2  Trust domainp. 24

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; 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

5.2  Architectural requirementsp. 24

5.2.1  General architectural requirementsp. 24

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.

5.2.2  PLMN change requirementsp. 25

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.3  UE-to-network relay MC service requirementsp. 25

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.

5.2.4  MC service user profile requirementsp. 25

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.

5.2.5  MC service group affiliation and MC service group de-affiliationp. 26

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.

5.2.6  GCS AS requirements for the MC servicesp. 26

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:
Reproduction of 3GPP TS 23.280, Fig. 5.2.6-1: MC service on-network architecture showing MBMS
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.

5.2.7  Bearer managementp. 27  Generalp. 27

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  MBMS bearer managementp. 28

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  EPS bearer considerationsp. 28  Considerations for the EPS bearer to the MC services PDNp. 28
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 MC gateway UE establishes a PDN connection to the MC service APN and utilizes this connection for MC service clients host on non-3GPP devices behind it.
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  Considerations for the EPS bearer to the MC common core services PDN and MC identity management service PDNp. 28
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. If QCI value 8 is not used for HTTP-1 transport, then caution should be used that a higher priority bearer (that is used for signalling or media) is not compromised by combining HTTP-1 traffic on this bearer.

Up   Top   ToC