5G multicast-broadcast for group communication: Why it matters and how it works

The last time you made a phone call or accessed the internet on your smartphone, those data packets were ‘cast’ over a single dedicated channel from the source node to your mobile device. This, what we call one-to-one or unicast communication, forms the basis of most mobile use cases today.

However, what happens when there is a need to transmit the same data packets to many receiving devices at the same time in scenarios where latency and reliability could be decisive? For example, across mobile use cases such as mission critical group communication, linear/live TV broadcasting, or even multi-device software downloads. Here, we rely on one-to-many communication, what we call broadcasting and multicasting communication services. And today, with 5G, there are many emerging and advanced use case opportunities for reliable and efficient 5G multicast-broadcast technologies. One of those is public safety use cases using mission-critical push-to-talk (MCPTT) technologies.

In this blogpost, we explain how the new functionalities of 3GPP Rel-17/18 multicast-broadcast services (MBS) can help improve group communication in general and MCPTT in particular, with an emphasis on radio-related improvements.

While mission critical group communication may now also include video and/or data, in this post we will focus on voice-centric MCPTT mission critical communication. However, the key takeaways for MCPTT can also typically be generalized to other types of mission critical group communication.

3GPP and multicast-broadcast: Why it matters

Up until recent years, group communication use cases have primarily been served through land mobile radio (LMR) systems for push-to-talk (PTT), such as terrestrial trunked radio (TETRA), with limitations when it comes to data load capacity and range.

Performance was increased with 4G, supporting a combination of LTE unicast and broadcast, with the application layer handling which of these to use.  

The introduction of 5G New Radio (NR) multicast-broadcast services as part of 3GPP Rel-17 and 18 offer communication service providers the ability to serve one-to-many use cases, such as MCPTT, using 3GPP mobile network infrastructures, in a better way.

Why is this significant? Firstly, multicast-broadcast solutions can offer improved efficiency potential, where a single downlink radio signal can be reached by multiple devices, known in 3GPP as user equipment (UE). This can also be referred to as point-to-multipoint (PTM) distribution.

Secondly, and equally important, is the underlying mobile network’s ability to provide the required reliability, coverage, latency, mobility, and scalability.

Thirdly, the new functionalities allow for implementation of multicast-broadcast service features with little or no hardware impact on network and user equipment. This means that CSPs can utilize the same spectrum band as used for unicast services and support implementations even without dedicated broadcast bands.

Mission critical use case example: Unicast or multicast-broadcast?

Public safety incidents are often not possible to predict from a geographical or temporal perspective. When they happen, it is critical that rescue teams can coordinate their efforts. For this, they typically use MCPTT group calls as an important tool, with one characteristic being that the downlink data is the same for all users in the call.

MCPTT for public safety can be delivered via unicast, where the network addresses each recipient device independently simply by duplicating the transmission. However, the downside to this is that inevitably efficiency will suffer owing to potentially many people participating in group calls – limiting the network capacity for MCPTT group calls and other simultaneous traffic. Another downside is the limited scalability. Since public safety MCPTT use cases often comprise many users in a limited area, with a tendency for unpredictable geographies, it would be unrealistic to design a mobile network for massive unicast capacity everywhere. Therefore, using unicast alone for MCPTT would not be a scalable solution.

What is Rel-17 NR multicast-broadcast?

Rel-17 NR MBS specifies both:

• a broadcast communication service, in which data is transmitted to all users in a broadcast service area, and
• a multicast communication service, in which data is transmitted to a dedicated set of users (i.e., not all users within coverage of the multicast service are authorized to receive the data).

The broadcast service is received without the UE using the uplink, which is always possible, as long as the UE is within coverage. To receive multicast, the UE however needs to be “connected” and will therefore also need to use the uplink, as with unicast.

NR multicast inherits most of the functionalities from NR unicast - including those that address reliability, coverage, latency, and mobility. Efficiency and scalability, which we identified as missing for unicast group communications, are addressed in Rel-17 NR multicast, which makes it a perfect solution for public safety MCPTT services.

When NR broadcast is used, the reliability and efficiency is reduced compared to multicast because the UEs do not send feedback to the 5G network. However, the upside for broadcast is its scalability and the fact that devices can always receive the signals. With Rel-17, since multicast reception requires the UE to be connected and use the uplink, if multicast scalability reaches a limit due to uplink congestion, the broadcast option can instead be used to allow some or all UEs to receive transmission without being connected.

As we will see, with Rel-18, multicast reception in RRC INACTIVE will be supported, which provides improved scalability also with multicast, along with the mobility and coverage features.

Unicast, broadcast or multicast: What’s the best solution for group communication?

Rel-17 and 18 multicast-broadcast functionalities are generic, meaning that with the large similarities between the unicast and multicast-broadcast functionalities, it’s expected that UEs will be able to support NR multicast-broadcast with little or no hardware impact. The same may also be applicable for the network side.

Services that are suitable for group transmission often have “peaky” traffic characteristics in terms of number of simultaneous users receiving the same service. Such peaks may be temporal, geographical, or a combination of the two, for example a live video transmission of an important sports game.

For unicast, this implies varying degrees of irregular capacity requirements across different geographies. This means that while traffic may be sufficiently low to allow for unicast to provide such services at some times, at other times the exclusive use of unicast services could cause congestion, which may be unacceptable since services with many users are often considered very important. This is again a scalability issue which may not be best addressed by designing the network for using unicast to support such worst-case events.

To support scalability, PTM functionality is instead required. With broadcast, the 5G network cannot keep track of which UEs are receiving the broadcast MBS session, so cannot adapt the transmission to this. Instead, the broadcast transmission needs to be “always on”, with some possible adaptation via the application layer. But always using broadcast, even when no one is receiving, just to support congestion cases, is wasteful.

In the other extreme, always using unicast, also for extreme capacity situations, also seems irrational, since it will either be very expensive or will not support the scalability requirements due to congestion.

However, with multicast, group services could be efficiently delivered irrespective of the size of the user group. Thanks to the UE feedback, the network always knows the number of users in a cell that need to receive (i.e. UEs have joined) the multicast session. If there is no such user, nothing is transmitted of the MBS session in the cell. If there is one user, the multicast transmission can be performed as efficiently as with unicast. When the number of users increases, the multicast transmission can gradually adapt to the actual number and reception conditions of UEs and in extreme cases of congestion (with Rel-18) many of them will receive multicast in RRC INACTIVE.

This means that with 5G multicast, the requirements of reliability, coverage, latency, mobility, efficiency, and scalability can be fulfilled for any number of UEs ranging from zero to extremely many, in a better way than with either of unicast and broadcast, or combinations of these.

The technical overview: Multicast and broadcast service sessions

With Rel-17, 3GPP introduced support for 5G NR MBS. The 5G Core network (5GC) may provide IP multicast data to UEs over MBS sessions, which are established and released, as per service requirements. These MBS sessions are the MBS counterpart to the protocol data unit (PDU) sessions the 5GC uses for unicast services. 

Following the analogy with PDU sessions, associated with each MBS session are also Quality of Service (QoS) requirements. In the radio access network (RAN), each MBS session is carried to UEs over one or more Multicast Radio Bearers (MRBs), which are set up to provide the needed IP multicast communication within the QoS requirements, as provided by the 5GC (see Fig. 1). These MRBs are the MBS counterpart to the Data Radio Bearers (DRBs) used to carry the unicast data of a PDU session in the RAN. If the 5G next generation base station, referred to as gNB, does not support 5G-MBS, the IP multicast service can instead be provided via a DRB, as in legacy unicast services.

An MBS session may be either a multicast session or a broadcast session. For the public safety MCPTT application, one MCPTT group call may be carried over such an MBS session.

There are several fundamental differences between multicast and broadcast MBS sessions:

• One such difference is that the UE needs to contact the network and “join” a multicast session to participate, whereas this is not necessary for a broadcast session. A multicast session therefore has a well-defined set of UEs with admission control and security, known by the network, whereas in the case of broadcast the 5G network (5GC/NG-RAN) does not know which UEs receive the broadcast session.
• Another fundamental difference is that with multicast sessions, the UE is always connected, that is, it’s in the RRC CONNECTED state, and can therefore provide different types of feedback to the network, which enables the network to dynamically adapt the transmission to the reception conditions of the targeted UEs, thereby ensuring that the required QoS is fulfilled. Broadcast sessions, lacking UE feedback, may however be received in all RRC states, including the unconnected RRC INACTIVE and RRC IDLE states.
• Yet another difference is that, for multicast, the network layer can support seamless mobility, while for broadcast this is not supported, and it is instead the application layer that is required to handle mobility between broadcast areas.

Regardless of whether multicast or broadcast MBS sessions are used for content delivery, from the application level, communication between the MCPTT client of the UE and the MCPTT application server is common. The application-level procedures, for example, group affiliation, request floor control, listen report, service key distribution, etc., are the same, regardless of whether the content is distributed via multicast, broadcast, or unicast. Note that the application-layer interactions are performed via unicast in most cases.

Figure 1: Delivery of MBS traffic via MRB or DRB radio bearer

Handover of multicast MBS sessions between MBS supporting cells, i.e. between a source cell and a target cell, builds on NR legacy handover mechanism for unicast. During the handover preparation phase, the source and target gNBs (if different) exchange UE context information related to MBS sessions the UE has joined and the target gNB decides MBS configuration to provide to the UE via the source gNB during the handover execution phase. To minimize the data loss, data forwarding and exchange of MRB packet data convergence protocol (PDCP) sequence number between source and target gNBs may be performed. If the target gNB does not already provide the MBS session, with data forwarding, the target gNB temporarily receives the user data via the source gNB, which can be faster than getting the user data directly from the 5GC.

To join and receive an MBS session, the UE is also always required to have an associated PDU session for legacy unicast, which is used for certain operations such as Non-Access Stratum (NAS) signaling between UE and 5GC. A special case is when a UE that has joined an MBS session enters a cell that does not support MBS. It can then still receive the MBS session data over unicast via an associated PDU session, using so-called individual delivery of the MBS session (see Fig. 1).

Multicast MRBs

With multicast, the MRB typically provides PTM functionality to all UEs that have joined the MBS session (PTM-only MRB) but can alternatively provide Point-To-Point (PTP) functionality to one or more UEs (PTP-only MRB). As a further option, a UE may also be configured to support both PTM and PTP (split-MRB), which means that the network can dynamically schedule MBS session data via either PTM or PTP, as appropriate (see Fig. 2). The characteristics of the PTP-only MRB, and the PTP part of the split-MRB, are mostly the same as those of regular unicast (which however uses PDU session/DRB).

Unlike DRBs, multicast (and broadcast) MRBs do not support Access Stratum (AS) security i.e., ciphering and/or integrity protection for user data transmission over air. The reason is that for group communication, such security protection is normally provided by the application layer instead.

Figure 2: Split multicast radio bearer (MRB) for a multicast broadcast service session

The PTM MRB reuses functionalities that already exist for unicast but adds some functionalities that are specific for multicast. For unicast (and PTP MRB) the UE monitors a known identity, which is the cell radio network temporary identifier (C-RNTI), in the downlink signal. The C-RNTI is UE specific, so only the targeted UE can receive data transmitted on a downlink scheduled using a particular C-RNTI. For multicast, a group identity, called the group radio network temporary identifier (G-RNTI), is instead used, where UEs that have joined a particular MBS session are configured with the same G-RNTI to receive this MBS session. The G-RNTI is therefore common for all UEs that participate in the same group call.

The split MRB allows the network to schedule MBS session data flexibly and dynamically via either PTM or PTP transmission. As shown in Figure 2, a given PDCP PDU can be delivered via either the PTM leg with UM RLC mode targeting a group of UEs or the PTP leg with AM/UM RLC mode targeting individual UEs. In addition, within the PTM leg, hybrid automatic repeat request (HARQ) retransmission of a medium access control (MAC) PDU can also be scheduled with either G-RNTI or C-RNTIs, targeting the group of UEs or individual UEs, respectively.

Like unicast, the UE may be configured with discontinued reception (DRX) for reception of multicast, which means the UE only monitors a subset of all possible time occasions a PTM transmission can occur and can sleep between these. The configuration of DRX for unicast and multicast are independent.

Like unicast/PTP, link adaptation, MIMO and beamforming may also be provided for PTM. Link adaptation may e.g., include dynamic choice of modulation and coding (MCS) as well as power control. For scheduling, multicast supports both dynamic scheduling and semi-persistent scheduling (SPS), like unicast.

Reliability support for multicast

Multicast supports the same functionalities as unicast for reliability, i.e., HARQ-based retransmissions and blind repetitions.

With HARQ retransmission, a data packet may be transmitted with successively increasing amounts of accumulated redundancy to allow decoding by the UE. This allows both efficiency and reliability. Efficiency, due to “just enough” provisioning of redundancy for the UE, which avoids unnecessary retransmission overhead. Reliability is provided thanks to the UE HARQ feedback after each transmission, which triggers a retransmission or not, depending on whether the HARQ feedback response bit acknowledges (ACK) or not (NACK) the correct reception of the transmitted data packet (Transport Block).

With blind repetition, the same message is retransmitted multiple times, without feedback between repetitions, and HARQ feedback is only provided by the UE after the last repetition.

Like NR unicast, with NR multicast HARQ transmissions for different transport blocks may go on in parallel, using multiple so-called HARQ processes, as many as 16. Multicast in Rel-17 also supports the ultra-reliable low latency communication (URLLC) framework developed for unicast since Rel-15.

Multicast supports retransmission to the same group of UEs originally scheduled in the initial transmission, either via PTM or PTP retransmission. The latter may be more efficient when few UEs need retransmission.

There may however be scenarios where such UE-specific ACK/NACK capacity cannot be provided, due to uplink congestion, i.e., there are too many UEs in the cell that need to independently send HARQ and other feedback to the gNB.  A unique feature of multicast HARQ feedback is that the network may in that case configure UEs to use so-called NACK-only HARQ feedback, where multiple UEs (potentially all) use a shared uplink resource.

With NACK-only HARQ feedback, only UEs that have not received the transmitted data correctly send HARQ feedback, so UEs with ACK stay silent. Since the uplink resource is shared, all UEs that need to send HARQ feedback do so by transmitting on the same radio resources, e.g., in time/frequency. In this way the amount of required uplink transmission capacity for HARQ feedback can be radically reduced and a higher number of UEs can stay in RRC CONNECTED and receive the multicast. A downside of the solution is that NACK-only feedback cannot be traced back to a specific UE, since the feedback is over a shared resource. Therefore, retransmission based on NACK-only feedback always uses PTM.

Finally, with Rel-17, it is also possible to completely switch-off HARQ feedback for UEs in RRC CONNECTED. These UEs will however still use the uplink to send Channel State Information to the network and to maintain the correct uplink timing (Timing Advance), so uplink congestion will not be entirely solved with this.

Broadcast MRBs

In congestion situations, the network may not be able to admit some UEs to RRC CONNECTED or needs to force some UEs, already in RRC CONNECTED, to RRC INACTIVE/IDLE. Hence in Rel-17, UEs which have joined a multicast session will end up losing the service, if released to RRC INACTIVE/IDLE.

As mentioned above, Rel-17 also supports broadcast MBS sessions with NR broadcast used in NG-RAN. A broadcast MRB is then used, and the UE is configured to receive the broadcast MBS session via two broadcast signaling means: system information block (SIB) and the logical channel multicast control channel (MCCH). The user data of the MBS session is transmitted over the logical channel multicast traffic channel (MTCH).

The SIB framework is a core functionality of 5G NR which allows broadcast of system information to UEs for all sorts of services (eMBB, positioning, etc). SIB has in Rel-17 been extended to support NR broadcast, providing the configuration for MCCH and basic configurations of MTCH. MCCH provides information about the broadcast MBS sessions that are available and additional configurations to receive the MBS data on MTCH (see Fig. 3).

Figure 3 – The sequential acquisition and use of SIB, MCCH and MTCH

NR broadcast may be received in any RRC state (CONNECTED, INACTIVE, IDLE) but due to the absence of feedback from the UE to the 5G network, there is no possibility for retransmissions based on such feedback. Like multicast, there is however a possibility for retransmissions based on pre-determined (blind) “repetitions”, i.e. not dependent on prior UE feedback. These repetitions convey the same information but use different forward error correction (FEC) redundancy versions, which allows the UE to combine (like HARQ retransmissions) successive repetitions. Such repetitions can be used for example to provide extended coverage or some time diversity for time-selective interference, but also increase overhead. Broadcast only supports dynamic scheduling.

Downlink/uplink duplex and unicast/multicast multiplexing

Like unicast, multicast may be transmitted in frequency division duplex (FDD) or time division duplex (TDD) spectral deployments. In such scenarios, unicast and multicast may be multiplexed in time and/or frequency.

The transmitted signal (downlink or uplink) is divided into a sequence of so-called slots, each consisting of 14 consecutive OFDM symbols. A given UE may receive unicast and multicast multiplexed in different slots (inter-slot TDM) or multiplexed in different OFDM symbols of the same slot (intra-slot TDM) or frequency multiplexed (FDM). With frequency multiplexing, unicast and multicast are transmitted in the same OFDM symbol, at least partially (see Fig. 4).

Figure 4: Multiplexing of NR unicast and multicast in the DL

Outlook: Rel-18 multicast-broadcast – multicast reception in RRC INACTIVE

Rel-17 provides a solid foundation for support of multicast and broadcast in 5G. Mission critical group communication can use multicast for RRC CONNECTED UEs, with mentioned benefits.

For the next step in the evolution of NR MBS, one of the most important enhancements, targeted for Rel-18, is to extend the support of multicast to UEs in RRC INACTIVE. This will be an important enhancement to better support extreme congestion, where the number of UEs is too large to keep all of these in RRC CONNECTED, even if they use NACK-only feedback (or no feedback). With this functionality, the scalability of multicast will be greatly enhanced and could, for MCPTT, in practice exceed that of broadcast. It should be noted that although MCPTT UEs receiving broadcast do not provide broadcast session-related feedback to the 5G network, they still need to regularly provide feedback to the application, so need part of the time to be in RRC CONNECTED using the uplink.

3GPP Rel-18 is in its early stages, with a lot of work still in the study phase, and a target date for completion by the end of 2023. However, two scenarios for multicast reception in RRC INACTIVE can already be foreseen:

1. Initially, the UE receives multicast in RRC CONNECTED, but is released to RRC INACTIVE due to, for example, congestion. The UE can continue receiving the multicast MBS session in RRC INACTIVE state, just continuing receiving the same PTM MRB, but stop using the UL for feedback. Alternatively, a UE may be admitted to the cell after the Multicast session has been activated. The UE is then RRC configured and immediately released to RRC INACTIVE, where it can receive the multicast session.
2. When a UE has joined an MBS session, but the MBS session has not been activated yet, due to the unavailability of data, it may be that the UE is released to RRC INACTIVE to wait for session to be activated. If configured to do so, a Rel-18 UE may stay in RRC INACTIVE and start receiving the service in this state. When there is congestion, the UE would typically stay in RRC INACTIVE to receive the multicast rather than resuming to RRC CONNECTED.

PTM transmission to RRC INACTIVE UEs via multicast MRBs is a totally new thing in 5G NR. Among many design aspects, 3GPP is discussing, we find for example:

• when and which UE in the multicast group to be transitioned to RRC INACTIVE and when/how to move them back to RRC CONNECTED;
• how to configure RRC INACTIVE UEs for receiving multicast data, i.e., what are Layer2/Layer1 configuration parameters and how different or common they are from configuration for RRC CONNECTED UEs;
• how to notify RRC INACTIVE UE of a multicast session status change such as activation, deactivation, and release;
• possible enhancements to support mobility for RRC INACTIVE multicast UEs;
• any security issues with transmission of multicast data to RRC INACTIVE as well as provisioning of MRB configuration information to RRC INACTIVE multicast UEs.

Final remarks

Release 17 of NR paved the way for group communication in 5G with 5G-MBS. This means that group communication use cases in general, and Public Safety Mission Critical Communication in particular, can now benefit from the support of 5G networks. 5G-MBS is a key enabler that provides reliable, scalable group communications and further enhancements are already in the works within Release-18 and planned for other future releases.

Further reading

Read Ericsson’s overview of 3GPP Rel 17 and 18.

Learn more about the journey to mission critical 4G and 5G communications.

Explore emerging public safety use cases within the telecom sector.

Learn more about Ericsson’s mission critical push-to-talk portfolio solution.

Find out more about Ericsson’s leading role in 3GPP standardization.