课题信息

课题任务

 

课题负责公司：华为，中国移动

 

广播多播简介

我们一般意义说上的移动通信系统，如2G、3G、4G和5G，通常指的都是单播通信系统。所谓单播，即信息是点对点传输的，比如基站给用户A传输一个数据包。广播和多播都属于点对多点传输。区别在于，广播是对所有用户进行信息传输而组播是对组内用户进行信息传输。一般来说，区域内所有用户都能接收广播信息，而只有在对应分组内的用户才能接收组播信息。单播、广播和组播的示意图如下图所示。

 

 

 

LTE系统标准化过一些广播多播系统，如MBMSF、SC-PTM和LTE EN-TV等。但是在NR系统中，Rel-15和Rel-16都没有对广播多播做标准化。所以，这个课题是NR的第一个广播多播课题。

 

Rel-15和Rel-16系统中也有广播功能，但该广播功能主要是用来发送系统消息的，比如SIBx和Paging消息，这个还不能成为广播多播系统。因为我们通常意义上说的广播多播系统指的是以广播多播方式传输用户数据的系统，而不是以广播多播传输系统消息的系统。但是，Rel-17的广播多播系统设计可以参考Rel-15/Rel-16的广播功能。

 

大家可能会想，广播多播相比单播到底有什么优势呢，为什么NR要定义广播多播功能呢？广播多播相比单播最大的优势就是资源利用率高。一个数据包，如果以单播的形式发给10个用户，系统需要使用10份资源；而如果以广播多播的形式将这个数据包发给这个10个用户，可能只需要1份资源，这就极大的提高了系统资源的利用率。

 

 

广播多播标准化

下面分别介绍Rel-17广播多播标准化的具体功能

 

• Specify a group scheduling mechanism to allow UEs to receive Broadcast/Multicast service [RAN1, RAN2]
  • This objective includes specifying necessary enhancements that are required to enable simultaneous operation with unicast reception.

解读：

标准化怎么实现组调度。传统的调度方式是一对一的调度，即每个调度针对一个用户，而组调度是一个调度针对一组用户，比如一个DCI调度给多个用户调度数据。

同时，Rel-17希望UE能同时处理广播业务和单播业务，而不仅仅是只能接收广播业务。这个主要是希望在单播系统的基础上添加广播多播的功能而不影响现有单播的功能。

 

 

• Specify support for dynamic change of Broadcast/Multicast service delivery between multicast (PTM) and unicast (PTP) with service continuity for a given UE [RAN2, RAN3]

解读：

一个特定的业务，根据条件的不同，有时候适合用单播传输，有时候适合用广播多播传输。比如，如果某个时刻同时接收该业务的用户量比较大，则系统用广播多播的方式比较合适；如果下一个时刻，接收该业务的用户量非常少，则系统可转为单播传输。Rel-17要求单播和广播多播之间可以动态转换并且保证业务的连续性。比如，业务在前一段时间一直在用广播多播传输，随着接收该业务的用户量减少，网络将该业务转为单播，业务在广播/多播和单播的转换过程中仍然能保证连续性。

 

 

• Specify support for basic mobility with service continuity [RAN2, RAN3]

解读：

广播多播的移动性管理。比如正在接收广播多播的用户，从一个小区切换到另一个小区时，如何保证业务的连续性等等。

 

 

• Assuming that the necessary coordination function (like functions hosted by MCE, if any) resides in the gNB-CU, specify required changes on the RAN architecture and interfaces, considering the results of the SA2 SI on Broadcast/Multicast (SP-190625) [RAN3]

解读：

对广播多播的网络架构做适当的适配。基本原则是尽量在单播网络架构的基础上，做尽量少的改动。SA2已经对网络架构做了一些研究，具体可以参考SP-190625。

 

 

• Specify required changes to improve reliability of Broadcast/Multicast service, e.g. by UL feedback. The level of reliability should be based on the requirements of the application/service provided.[RAN1, RAN2]

解读：

LTE的广播多播系统都是纯下行的广播多播系统，没有为广播多播定义上行反馈，这就导致基站不能很好地保证广播多播业务的可靠性。例如，如果基站给一组用户传输多个数据包，但是其中部分用户没有解对部分数据包，但是用户却没有办法告诉基站其没成功接收。而在NR广播多播系统设计中需要标准化一些上行反馈机制，用来提高广播多播业务的可靠性。目前，大部分公司比较认可的反馈包括HARQ-ACK反馈和CSI反馈等。通过HARQ-ACK反馈，用户可以告知网络数据包的接收情况（解对/解错）；通过CSI反馈，用户可以告知网络当前的信道条件，网络侧根据用户上报的信息可以做到更加合理化的调度，提高业务可靠性。

 

 

• Study the support for dynamic control of the Broadcast/Multicast transmission area within one gNB-DU and specify what is needed to enable it, if anything [RAN2, RAN3]

解读：

广播多播区域管理，用户控制广播多播的受众用户。

 

• Specify RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/ RRC_INACTIVE states [RAN2, RAN1]:
  • Specify required changes to enable the reception of Point to Multipoint transmissions by UEs in RRC_IDLE/ RRC_INACTIVE states, with the aim of keeping maximum commonality between RRC_CONNECTED state and RRC_IDLE/RRC_INACTIVE state for the configuration of PTM reception. [RAN2, RAN1].

解读：

RRC IDLE/INACTIVE态下的广播多播。对于单播，用户只有进入了RRC 连接态才能开始接收单播数据。

 

但对于广播多播，有一种可能是用户无需进入连接态也可以接收广播多播数据。在IDLEINACTIVE态时，用户/网络是不需要维护该用户的信道信息，也就是说网络侧并不知道用户的信道信息，网络也不知道到底有哪些用户在接收广播多播信息。如果网络连用户的信道信息都没有，那么网络就难以保证广播多播业务的可靠性，或者只能牺牲系统性能来保证可靠性；如果网络侧连哪些用户在收广播多播数据都不知道的化，网络侧就很难为用户做一些定制化的服务、收费等。

 

小结

Rel-17广播多播课题是NR的第一个广播多播版本，意义重大。

 

但是受全球疫情的影响，3GPP预计Rel-17大部分会议都将改为线上会议，影响了Rel-17标准化的进展。预计Rel-17广播多播将会是一个基础版本的广播多播系统，后续可能会进一步演进。