Communications

5G MBS – Unleashing the Potential of Multicast and Broadcast Communication in 5G

By Vinay Kumar Shrivastava Samsung R&D Institute India - Bangalore
By Sangkyu Baek Samsung Research
By Varini Gupta Samsung R&D Institute India - Bangalore

We had Television and Radio for broadcast services, and we had Telephones for voice services, each offered on a separate purpose-built network. Then came Internet, giving rise to "on-demand" services.

And then, the technocrats of the world realized they could offer differentiated and value-added services by combining the three worlds on a single wireless network.

5G MBS (Multicast and Broadcast Services) is an attempt at combining the world of broadcast services with the voice/data world of cellular mobile communication. Operators want additional revenue streams and hence, are looking at including broadcast services to their fleet of offerings. Consumers are looking at additional ways of remaining hooked to their mobile screens in a cost-effective manner and live TV is an obvious extension. A win-win situation for both.

This integration of technologies gives rise to a number of useful new and emerging services as well. Enhanced public safety services, autonomous real-time driving information, UHD-TV delivery, AR/VR/MR and 360-degree video, coordinated software updates, enriched experience in stadium and concerts, hyper-local advertisements are some of the intriguing services which are expected to be made possible by 5G MBS. Each of these services require a different level of quality-of-service - reliability and/or latency; and QoS-centric design of 5G system ensures ability to cater to such differentiated requirements. Concurrently, the operators are able to utilize their radio resources more efficiently as a common radio transmission can now serve for delivering data simultaneously to multiple users present in a cell.

Multicast and Broadcast Services

5G MBS is essentially about providing a point-to-multipoint (PTM) transmission, and defines two types of services – a broadcast service which is available in all cells in a planned geographic coverage, and a multicast service which is available to select users and may be transmitted in cells where those users are present. A Live-TV type of service could use broadcast transmission while multicast transmission would be preferred for, say, a conference call with select users.

User's ability to receive a broadcast service depends solely on whether user is present in the area where broadcast is scheduled, and whether user has the required subscription to receive the data much like the satellite TV service. Management of subscription to the service can be maintained by a system outside of 3rd Generation Partnership Project (3GPP) in charge of 5G standardizations.

On the other hand, multicast services require users to explicitly indicate their intention of receiving a scheduled multicast service. The 5G System (5GS) then accordingly schedules the transmission of multicast session in the cells where interested users are present.

It is worth noting that IP-Multicast technology has existed for long in wired networks. It allows delivery of multicast data to interested parties by using an IP-Multicast address as the destination address in IP-packets. Protocols like IGMP/PIM-SSM allow a user to indicate its interest to “Join” a multicast service and set up delivery of data on the network-legs where user is present. In case of 5GS, since the users are on a radio network, MBS extends capability to deliver multicast data over 5G radio links.

Samsung has been an active proponent and lead contributor to the development of MBS technology over cellular networks of LTE and 5G. The history goes quite long, Samsung together with KT launched world’s first commercial LTE eMBMS (evolved Multimedia Broadcast and Multicast Service) in Korea in January 2014.

Requirements and Challenges

The different set of services made possible by MBS, expectedly, have varied requirements. As shown in Figure 1, public safety and mission critical service needs are very different from those of Vehicle-to-Everything (V2X) applications, which are further divergent from the IPTV services. Let's take a closer look at these different requirements and challenges arising from them:

Figure 1.  A simplified and generalized classification of service requirements for MBS

Figure 2.  Table depicting QoS parameters for certain MBS services

Service Area Coverage: Different services have varied requirements in terms of service area coverage. For example, V2X applications have shorter coverage needs than IPTV services. Weather service may require different transmission in each geographic area. MBS allows ability to restrict service transmission area to a single cell or an area of multiple cells based on network configuration to meet different service requirements.

Reliability and QoS: High reliability and low latency services, e.g. mission critical delay-sensitive signalling with packet delay budget of 60ms and packet error rate of 10-6, present extreme service requirements (see Figure 2). 5G MBS facilitates dynamic adaptation of service delivery modes to meet QoS constraints, and novel approaches for UE to provide quick feedback and avail retransmission to ensure reception reliability. Also, MBS service may have multiple streams differing in their QoS requirements and need to be treated differentially. These streams can be mapped to appropriate MBS QoS flows as per their requirements, and to appropriate radio bearers or logical channels at the radio protocol level for enforcement of the QoS requirements.

Service Continuity: When a UE is moving across geographic regions, UE’s serving cell can be changed (i.e. handover), and non-negligible latency due to the cell change may occur. However, longer latency exceeding the packet delay budget degrades the quality of the user’s experience, thus it should be minimized. Special provisions are inevitable to ensure packet-level synchronization and data forwarding across different network nodes, and also considerations for different delivery modes of the UE across handover. As MBS coverage may not be ubiquitous, especially during initial deployments, service continuity across legacy network nodes is an essential requirement and may involve transition in service delivery modes (e.g. unicast based access for MBS services).

Security: To ensure secure communication for certain MBS services (e.g. software delivery, mission critical), a security functionality is required which provides for session security context, access credentials and their maintenance across involved network nodes and UEs. Application/service layer security provisioning transparent to Radio Access Network (RAN) and radio protocols is adopted for MBS, in order to avoid any impact on RAN and provide more deployment flexibility to network operators.

MBS and 5G Standards

In the third phase of the 5G Standards called 3GPP Release 17, functional support of multicast and broadcast services have been introduced within the existing 5G framework from both systems and RAN perspective.

Figure 3.  MBS system architecture is simplified by reusing existing network entities


Core Network

The design principle of 5G systems for MBS is to enable multicast and broadcast services by the existing network entities as much as possible with essential software upgrades, in order to minimize newly added MBS-specific network entities which cause increase of early-stage MBS network construction cost. Similar with User Plane Function (UPF) and Session Management Function (SMF) for unicast, upgraded UPF and SMF called MB(Multicast and Broadcast)-UPF and MB-SMF are introduced, in charge of data delivery anchor to the 5GS and MBS session management based on policy rules, respectively. Figure 3 depicts the MBS system architecture.

For efficient data delivery in the 5G Core Network (CN), Shared Delivery (SD) method has been introduced. In SD, an MB-UPF sends a single copy of MBS data packet to each RAN node (i.e. gNB: base station in 5G). Hence, each packet is not dedicated to a particular UE but shared by multiple UEs which receive the same service. It is even possible for UEs to receive MBS data via RAN nodes without MBS capability. RAN nodes without MBS capability do not understand SD method. Instead, 5G MBS supports Individual Delivery (ID) method where MBS data packets are transmitted in unicast manner over both CN and RAN. From UE perspective, SD and ID can be switched dynamically to support the session-level service continuity.

Figure 4.  Packet-level service continuity with lossless mobility


Radio Access Network

In eMBMS of 4G LTE, data transmission for multicast and broadcast requires tight synchronization among multiple eNBs in the service area, called MBSFN (Multimedia Broadcast/Multicast Single Frequency Network). Since the synchronization requirement limited the scheduling flexibility of each gNB and increased the deployment difficulty, 5G MBS does not rely on MBSFN anymore but uses gNB’s independent scheduling of MBS data where each gNB decides when and how to deliver the data packet by itself.

Various levels of reliability options of data transmission are provided. In 5G MBS, first, Hybrid Automatic Repeat Request (HARQ) is introduced allowing rapid physical layer retransmissions for multicast together with a fast feedback channel. Second, the network can choose either point-to-point (PTP) retransmission or point-to-multipoint retransmission. Third, retransmission mechanism based on a more reliable Automatic Repeat Request (ARQ) is also possible in case that the multicast service requires 100% delivery. Fourth, data bundling, which allows multiple repetitions together in a bundle, can be used for broadcast.

In 5G multicast, packet-level service continuity with lossless mobility is guaranteed (see Figure 4). Instead of MBSFN, packet-level sequence number (SN) synchronization where the same packet has the same SN over the area is supported. Based on the SN synchronization, when a UE hands over to a target cell, the UE sends the list of packets which UE did not successfully receive and the target cell can transmit the packets to the UE to achieve the lossless handover.

Future Directions – 5G Advanced

With the introduction of 5G MBS in Release 17, 3GPP has already started work for MBS enhancements towards 5G Advanced. 3GPP Release 17 provided basic functions to support MBS and now it is required to enable better deployment of MBS. Broadly speaking, resource efficiency and capacity improvements are being pursued in Release 18.

So far, multicast services are only accessible to UEs in RRC (Radio Resource Control) Connected state. Considering the large number of users in the cell that need access to public safety or mission critical services and limited number of active connections in the cell, it is paramount to extend multicast for UEs even in RRC Inactive state.

Another salient improvement target is to enable simultaneous access of unicast and broadcast services that may involve hardware resource sharing for the UE. In this scenario, signalling enhancements make network aware about the UE resource capability changes and its resultant impact to the unicast. This facilitates the network to reconfigure UE with appropriate unicast configurations.

RAN sharing is a common deployment option to lower CAPEX for the network operators. It becomes crucial for resource efficiency that the same MBS service is not redundantly provided utilizing separate transmission resources in the RAN sharing scenario for two or more operators.

These future-oriented technical advancements and standardization steps are significant to bring the benefits of the multicast and broadcast communication to the society at large. Samsung has been playing a pivotal role to standardize the MBS enhancements for 5G and 5G-Advanced across various 3GPP forums, and is committed to the further advancements of 5G MBS.

References

1. 3GPP TS 23.247: “Architectural enhancements for 5G multicast-broadcast services”.

2. 3GPP TS 38.331: “Radio Resource Control (RRC) protocol specification (Release 17)”.

3. 3GPP TS 38.214: “Physical layer procedures for data (Release 17)”.