Other articles in this series:

The main technical challenges for 5G Broadcast can be identified by clearly defining what it is and what its objectives are. This immediately raises the key point that those objectives have expanded to include provision of a complete service layer for delivery of video to mobile devices, including both intermittent and highly popular content.

Mobile broadcast in general was originally conceived as a way of delivering established linear TV services to mobile devices while bypassing the traditional gatekeepers, primarily the telcos or cellular operators. This meant allowing reception from devices such as smartphones without a subscription and without needing a SIM card in the device.

Then as smartphones became more ubiquitous and cellular services more reliable, the idea of applying mobile broadcast to other applications apart from video that required simultaneous transmission to multiple users gained purchase. This included transmission of software updates, emergency alerts, and various other forms of public information.

Since effective large scale broadcast transmission was already happening over digital terrestrial TV (DTT) networks, the plan was to implement mobile broadcast over the same infrastructure via the High Tower High Power (HTHP) model. That would involve some form of integration between mobile and DTT networks.

But as the 5G era approached another vista unfolded, that of a unified distribution system supporting broadcast, multicast and unicast transmission simultaneously, with the ability to switch between those modes dynamically on the fly as conditions dictate. While the most popular programming such as major sporting events content might be broadcast at all times, and niche or longtail content as it used to be called - always unicast, as well as on demand material, there is a lot of linear material that is in between.

Then if viewing levels of the latter varied during the scheduled transmission, it might make sense to step down first from broadcast to multicast mode, cutting off mobile cells within which there are few if any viewers. Then it might end up being most efficient in unicast mode on a one-to-one basis, because even maintaining multicast delivery would incur too much processing overhead.

Broadcast mode has already been established over digital terrestrial networks and is well understood, with the same applying for unicast mode over mobile networks. Multicast is more challenging, and in particular switching between that and the other modes on demand, especially unicast. A major challenge arises when a user roams between mobile cells served by different 5G base stations, in the handover process.

Under unicast mode, handover between cells requires re-establishing a connection by a user’s device such as a smartphone, and the base station of the cell that user has just roamed into, identified by identifying where the strongest signal is coming from. But with multicast, it could be that previously nobody in the cell the user has roamed into was previously viewing the relevant content, so the cell would not already be attached to that group. Therefore, the cell just entered would have to be attached to the multicast group without disrupting the user’s session, so that QoS (Quality of Service) is maintained.

Partly because of the complexities involved, proper support for mobile multicast only arrived with the 3GPP Release 17 of the mobile standards around 2022, with the concept of Multicast-Broadcast Service (MBS). The idea was to use as many as possible existing building blocks already established and proven under 5G and 4G LTE before that, and one of those was the legacy handover mechanism for unicast.

This provided the foundation for the more complex process of multicast handover, which involves dynamically updating the delivery tree along which content flows from source to wireless cell and then over the air to the user devices.

An additional layer is required with multicast, because of the need for an upstream configuration change at the source of the delivery tree. Provision has to be made to ensure that data is not lost during the handover phase, which would result in a viewing glitch such as a frame freeze or rebuffering.

This inevitably involves interaction between the source and target mobile cells, or specifically the base stations orchestrating radio transmissions within them. In 5G parlance these are gNodeBs (gNBs) rather than base stations. They often are essentially base stations, but they can also be deployed as Software Defined Radios (SDRs) under 5G, which effectively means they can be implemented on conventional hardware such as an embedded server or even a PC equipped with suitable antennas, instead of the dedicated equipment familiar to passers-by in cell towers. The designation gNB was meant to reflect the greater variety of hardware that could be used, but it merely adds to confusion for those outside the industry.

At any rate during a multicast MBS session handover, the source and target gNBs have to exchange preparatory information in advance to avoid any glitch. This involves various steps, the main point being that if there is a delay attaching the target gNB to the multicast tree, the original source gNB, that is the gNB in the cell the user is just leaving, must temporarily continue receiving the relevant data over its multicast links and deliver it directly to the target gNB, which in turn forwards it to the user device.

Then finally when the target gNB has been fully connected to the multicast tree (in the event it was not already for some user in its cell) switchover can finally occur. As this indicates, full handover between gNBs at the multicast level can be slightly delayed, and occurs after the user has entered the new cell.

There is also the question of when to trigger switches between these modes, which applies to all use cases and not just TV or video distribution. For public safety incidents there may be a need not just to inform the populace but coordinate activities among emergency responders. This can be done via unicast, and often has been until now, but has increasingly run into congestion as it scales up, since each transmission consumes a communications channel. Such applications are ideally suited to multicast, being confined to specific areas, but involving significant numbers of transmissions.

The three modes though require different configuration and operation of the UE (User Equipment). With broadcast, service is received by all devices without any uplink from the UE being necessary. Indeed, that was a major part of the original mobile broadcast mission, to enable delivery of content to all devices without prejudice and without any actions being required, or any software downloaded.

Multicast is more efficient in many scenarios because data is transmitted just to the users who have elected to receive it, or are authorized to do so. This benefits from the same economies of delivery over the core and backhaul networks, requiring just a single stream along each link of the chain. But it does need an uplink since the UE in principle has to be constantly connected to be aware of what multicast sessions are available and then to issue the instruction to join one if required.

Given that 5G multicast is likely to be widely deployed for video and other applications, considerable effort has been invested in making it work as efficiently as possible. There has been particular focus on minimising the overhead of having to keep UE connected, in order not just to save bandwidth and energy, but also scale sustainably to large numbers of users.

The idea of multicast remember is to avoid sending the same content more than once over a given link of the delivery chain, and that includes the final wireless hop over the cellular Radio Access Network (RAN) served by the gNB. This is accomplished on the delivery side by transmitting content as a single stream, just the same as for broadcast. Indeed at the cell level there is no difference between multicast and broadcast as far as delivery goes, while in unicast mode, separate transmissions are made to each user in the cell.

But multicast appears to require separate uplink communication for each user, so that would not scale so well without an additional step. This extra step to avoid having to keep permanent uplinks open for every participating device is being taken by exploiting a cellular mode that was introduced originally under the preceding 4G in 2016. This is called Radio Resource Control (RRC) INACTIVE. RRC is the protocol used in cellular communications to manage use of the available RF (Radio Frequency) spectrum and ensure that communications are maintained between the UE and the core network for accessing services or the internet.

RRC INACTIVE was introduced so that UE such as smartphones could disconnect and go to sleep temporarily to save battery and bandwidth when they were not communicating. That was not employed at first for 5G multicast because it did not appear to be possible to maintain a session without a permanent uplink connection. It became clear though the latter would not scale well to large numbers of users.

A solution to this conundrum was eventually found by the 3GPP standards committee, which would take a full article to dissect in detail. Essentially it

allows the gNB first to trigger devices for switching down from the full RRC CONNECTED state which does require a permanent uplink to RRC INACIVE, which does not require that.

Secondly and crucially, the gNB can wake the device back up from RRC INACTIVE to RRC CONNECTED quickly by sending a short paging message, in the event there is some change to a multicast session. Meanwhile, the device goes on receiving the multicast content in the inactive mode, without requiring an uplink.

Also important, the user’s device can trigger a switch from RRC INACTIVE to RRC CONNECTED in order to issue a change in its status, such as a desire to stop participating in a multicast session, by issuing a resume request even though it did not have an uplink open at that stage.

This change to allow devices to receive multicast content while having an idle uplink, just as they would in broadcast mode, is being introduced with the latest 3GPP Release 18 of the 5G standards in 2024, with commercial availability in products likely to start later in 2025. It is an important step for 5G multicast and one reason why it is still work in progress.

Another important work area concerns integration between DTT infrastructure and mobile networks for future hybrid broadcast and multicast delivery. This has been the subject of some of the trials discussed in other articles of this series, with challenges being as much logistical and commercial as technical.

Indeed, technical challenges associated with broadcast transmission over HTHP infrastructure have already been solved for DTT. These include use of Single Frequency Networks (SFN) for most efficient use of spectrum, which involves having sufficient guard intervals to ensure that transmissions from neighbouring towers over the same frequency do not interfere with each other at slightly offset phases.

5G Broadcast/Multicast will therefore incorporate existing HTHP transmission technologies, but there will be additions from the mobile side, one of which could well be 5G network slicing. This entails partitioning the spectrum logically to allow multiple services with different QoS requirements or traffic profiles to coexist, while allowing some performance guarantees to be provided to more critical ones. In that way live broadcasts could be given priority for latency purposes over on demand programming, for example. Similarly, emergency public service alerts would be allocated a high priority slice on the fly, or have one permanently maintained.

Above all though, effective integration between the DTT infrastructure and mobile networks, referred to sometimes as Low Tower Low Power (LTLP) because of their shorter range, will be required to fulfil this ambition of harmonization between broadcast multicast, and unicast that we discussed earlier. That will require coordinated delivery over the combined infrastructure.

There is plenty to play for then, and work still to be done before we can talk about true hybrid mobile/DTT delivery.