PREVIOUS
Zebra | What I Have Learned About Leadership as CEO the Past 15 Years
Through 5G NR multicast-broadcast functionality, 5G networks can now be equipped to support efficient, reliable and scalable group communication services. Below, we explore the 3GPP technologies bringing high-performance connectivity to mission critical use cases.
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.
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.
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.
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.
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.
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.
