Content for TR 23.700-47 Word version: 18.0.0

...

1 Scope p. 10

This Technical Report studies and evaluates further enhancements to the 5G Multicast/Broadcast Architecture in order to provide the following features.

Enabling UE's receiving Multicast MBS Session data in RRC Inactive state.
Study feasible and efficient resource utilization for the same broadcast content to be provided to 5G MOCN network sharing scenarios (i.e. multiple CNs are connected to the same NG-RAN).
Study whether and how to support on demand multicast MBS session triggered by AF, and efficient resource utilization via 5GC choosing multicast and/or unicast delivery for a certain service.
Study whether and how to support group message delivery for capability-limited devices, including NEF enhancement, coexistence of existing power saving mechanisms and MBS.
Study whether there are any identified performance issues for high number of public safety UEs, and if yes study necessary enhancements to 5MBS for that scenario.

2 References p. 10

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

[1]

TR 21.905: "Vocabulary for 3GPP Specifications".

[2]

TS 23.501: "System Architecture for the 5G System; Stage 2".

[3]

TS 23.502: "Procedures for the 5G system; Stage 2".

[4]

TS 23.247: "Architectural enhancements for 5G multicast-broadcast services; Stage 2".

[5]

TR 26.850: "MBMS for Internet of Things (IoT)".

[6]

TS 23.682: "Architecture enhancements to facilitate communications with packet data networks and applications".

[7]

TS 23.280: "Common functional architecture to support mission critical services; Stage 2".

[8]

TS 24.379: "Mission Critical Push To Talk (MCPTT) call control; Protocol specification".

[9]

TS 22.179: "Mission Critical Push To Talk (MCPTT); Stage 1".

[10]

TS 23.288: "Architecture enhancements for 5G System (5GS) to support network data analytics services".

[11]

TS 26.502: "5G Multicast-Broadcast User Service Architecture".

[12]

TS 23.468: "Group Communication System Enablers for LTE (GCSE_LTE); Stage 2".

[13]

TS 38.300: "NR; Overall description; Stage-2".

[14]

TS 33.501: "Security architecture and procedures for 5G system".

[15]

TS 36.300: "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access (E-UTRAN); Overall description; Stage 2".

[16]

TS 36.321: "Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification".

[17]

TS 29.532: "5G System; 5G Multicast-Broadcast Session Management Services; Stage 3".

[18]

TS 29.522: "5G System; Network Exposure Function Northbound APIs; Stage 3".

3 Definitions of terms and abbreviations p. 11

3.1 Terms p. 11

For the purposes of the present document, the terms given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 and TS 23.247.

3.2 Abbreviations p. 11

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905 and TS 23.247.

4 Architectural Assumptions and Principles p. 12

4.1 Common architectural requirements and principles p. 12

Solutions shall build on the 5G System architectural principles as in TS 23.501, including flexibility and modularity for newly introduced functionalities.
The system shall provide an efficient transport for a variety of multicast and broadcast services.
Only NR of NG-RAN connected to 5GC is considered as RAT.
Architecture reference models defined in clause 5.1 of TS 23.247 are used as the baseline architecture for this study. Enhanced Architecture and Solutions in this study shall enable UEs with Rel-17 MBS capability to receive MBS data from Rel-18 architecture/solutions.

4.2 Specific architectural requirements and principles for public safety service in a cell with large number of UEs p. 12

Public Safety specific architectural requirements and principles:

Solutions shall enable simultaneous reception of MBS session data for a higher number of UEs in a cell than can be operating in RRC_CONNECTED state, to participate in public safety group calls using MBS-based service.
Solutions shall ensure that the pre-emption and admission control mechanisms result in public safety UEs being able to complete the setup of the MBS services and then operate according to regulation and operator policy, when a mix of UEs participating in one or more services and/or one or more sessions within each service is present in the cell.

NOTE 1:
This issue, which involves other Working Groups, deals with aspects like recognizing which UEs may be moved to RRC_INACTIVE (service continues via MBS) vs. moved to RRC_IDLE (service may fail), not impacting the UE while the UE is setting up connections or waiting for the floor (permission to talk), ability to override user settings in order to be able to pre-empt, if necessary, etc.
Solutions shall enable provision of assistance information to NG-RAN from the application function (AF) via 5GC, if required/needed.
Solutions may require information to NG-RAN and application function (AF) to enable proper provisioning. This includes, e.g. the SA6 and RAN WGs deciding on, what information to be provided on, which members of a public safety group should stay in RRC_CONNECTED and which one(s) are candidates for being transitioned to RRC_INACTIVE.
If MBS sessions are temporarily deactivated and are subject to subsequent (re)activation, resulting in UEs in e.g. RRC_INACTIVE state which need to be (re)-awakened to receive MBS service, solutions may enable simultaneously wake up (for MBS reception) for all the UEs associated with the session.

NOTE 2:
For active MBS Session, it is assumed that public safety applications (under the remit of SA6) will initiate minimum number and frequency of requests to transition to RRC_CONNECTED state to perform uplink transmissions, while Public Safety UEs are in RRC_INACTIVE state.
Whether there is a need for additional solutions to minimize packet loss during MBS reception, this should be addressed together with RAN WGs.