边缘计算助力移动直播

移动个人直播中的用户行为表征：迈向边缘计算辅助范式

马明，清华大学张磊和刘江川，西蒙弗雷泽大学王智，清
华大学深圳研究生院庞海天和孙立峰，清华大学李卫华，
北京博威动力科技有限公司侯广岭，北京蜜莱网络科技有限公司 褚凯炎，阿里云计算有限公司

移动个人直播（MPL）服务正在兴起，并受到广泛关注。在MPL中，大量地理分布的普通用户向全 球观众广播他们的视频内容。与Twitter和Facebook等传统社交网络服务不同，个人直播中的交互 （如聊天消息）必须实时进行，并具有较低的反馈延迟。这些独特特性促使我们：（1）深入研究观 众与主播之间的关系（如社交链接和地理位置）如何影响用户行为，而这一点尚未被充分探索； （2）挖掘有助于提升系统性能的洞察。本文对一个典型的MPL系统进行了大规模测量，使用包含 1100万用户的大规模数据集。在当前成本高昂且受限的基于云的MPL系统中，系统面临可扩展性问 题，我们发现：（1）主播与云接入服务器之间较长的内容上传距离导致系统服务质量下降，包括较 高的广播延迟和频繁的缓冲事件；（2）MPL中的大多数主播在地理上呈现本地热门特征（观看次数 主要来自主播所在区域），这消耗了大量云和内容分发网络的计算和带宽资源。幸运的是，边缘计 算的出现——在移动网络边缘提供云计算能力——为MPL系统带来了新的解决思路；即，实现本地化 的内容上传、转码以及本地热门直播内容的分发成为可能。基于这些关键观察，我们提出一种边缘 辅助的MPL系统，协同利用核心云和丰富的边缘计算资源，以提升系统效率与可扩展性。在我们的 框架中，考虑动态广播者分配，在降低广播延迟的同时保持较低的资源租赁成本。我们将主播调度 建模为一个带迁移的稳定匹配问题，以有效求解。与现有的纯云系统相比，我们的边缘辅助分发方 法将广播延迟降低了约35%。

引言

随着内置摄像头及视频处理软/硬件的移动设备的发展以及高速接入网络的普及，近年来，
一种新型社交应用——移动个人直播（MPL）迅速流行起来。通过美国的Periscope[39]
和FacebookLive以及中国的映客1等社交应用，大量地理分布的业余主播可以向全球观 众实时直播他们的视频内容。据报道，中国约有46%的互联网用户正在使用MPL应用 （例如映客、陌陌2和Live.me3）；在Periscope上花费的每日观看时间已达到110年[5]； 而在FacebookLive中，人们观看直播内容的时间比非直播内容更长 3×。[34]。

此类平台具有两个最独特的特征：（1）实时互动：与传统社交网络应用（例如 Twitter中的转发）和媒体内容共享应用（例如Vine中的评论和分享[49]）中可容忍延迟 交互的方式不同，实时互动对MPL系统至关重要。因此，最小化广播延迟，即主播与观众
之间的端到端流媒体延迟，是MPL服务面临的一个重要问题；（2）大规模地理上分布的
主播：直播内容由使用多样的设备和网络的地理上分布的非专业主播产生，并可被全球用 户轻松访问。因此，MPL系统不仅需要考虑内容分发网络(CDN)中的内容分发，还需考虑 针对大量异构主播的直播内容接入工作负载调度[3, 6]。

为了满足这些动态且数量庞大的主播与观众的需求，MPL系统需要立即将大量异构的 直播内容统一为工业标准格式，以供用户观看[3],这带来了巨大的计算密集型转码任务。
由于云的弹性和“按需付费”的租赁模式，大多数MPL平台广泛采用云服务来处理大规模 的视频接入和转码任务[40, 42, 47],例如，Periscope（映客）分别运行在8个亚马逊EC2 （一个阿里云）数据中心上进行内容摄入和转码[39]。然而，纯基于云的框架面临若干关 键问题：（1）成本高昂：近年来，并发直播内容数量的快速增长甚至使得纯基于云的解决 方案变得极为昂贵，导致MPL服务提供商难以承受这一成本。例如，Twitch在2017年拥 有2.5万名并发主播，而根据EC2GPU实例最新公布的定价，最低每小时收费0.9美元（ p2.xlarge），最高达每小时4.56美元（g3.16xlarge）。为此，大多数MPL系统（如 Twitch和映客）仅向优质内容主播提供转码服务，而这类主播仅占全部主播的1.5%至4% [16, 29, 46]；（2）广播延迟高：考虑到

实时互动对移动个人直播（MPL）至关重要，因此对低延迟的要求非常严格。但在基于云 的框架中，由于服务或成本限制，为MPL租用的物理服务器数量有限，且可能距离移动主 播较远，导致向云服务器上传内容时不可避免地产生较高且不稳定的延迟。在本文中，我 们验证了这一问题不容忽视，不能简单忽略。(3)骨干网络流量巨大：全球范围内的主播与 观众为主干网络和内容分发网络产生了海量的数据密集型视频流量。例如，在Twitch平台 上，由100万主播生成的直播内容每月观看时间超过1500亿分钟，使其成为美国第四大互 联网流量来源。[9]为了应对带宽需求的急剧增长，我们期望一种新的MPL系统范式，能够 保证边缘生成的直播内容在边缘被消费，而不会占用过多的骨干网络资源。

为了探索一种能够满足大规模摄入/转码任务和低广播延迟需求的低成本且高效的框架， 不仅研究观众与主播之间的关系（如社交链接和地理位置）如何影响用户行为（这一方向 尚未被深入探讨）具有重要意义，同时也有必要深入分析为设计新型MPL系统架构提供有 益见解，以提升系统性能。为此，我们基于一个涵盖4000万次直播会话和10亿次观看会话 的大规模数据集，在代表性MPL系统映客中开展了细致的研究。

我们之前的工作[29]识别出MPL系统中的大多数本地热门主播。在本文中，我们进一 步发现这些本地热门直播占用了核心云中大量的带宽和计算资源，例如，有45%的计算资 源被那些所有观看次数均来自与主播同一区域的直播所消耗。据我们所知，这种地理流行 性特征尚未被考虑用于优化现有移动个人直播系统。鉴于这些本地热门主播产生的繁重且 动态的工作负载难以管理，我们提出，利用边缘网络的计算和带宽资源，在小范围内对这 些本地热门直播内容进行摄入/转码和分发，是提高系统性能并降低运营预算的一种有效且 经济的方法。

先前的研究已经阐明了边缘计算的强大能力和潜力[33, 35],，它将云计算能力带到了 边缘网络，相较于核心云更靠近移动用户。其中，“边缘”被许多文献定义为内容生产者 与云数据中心之间路径上的任何计算和网络资源[35]。近年来，工业界和学术界都认识到 边缘计算在边缘计算密集型任务[16, 30]和数据密集型任务方面的优势（例如，参考文献 [7, 13]利用边缘计算来辅助内容分发，并从骨干网络和内容分发网络(CDN)服务器卸载流 量）。如今，边缘设备中广泛存在的丰富边缘计算资源，例如台式机中的高性能处理器 （如英特尔酷睿i7或DirectX12显卡）以及专用视频处理核心（如英特尔快速同步技术）， 正成为主流配置[38]；同时，5G基站也部署了专用的边缘计算资源[11, 19, 33]。鉴于这些 丰富且经济的边缘资源，我们因此设计了一种边缘辅助的MPL范式，该范式协同利用核心 云和边缘计算资源，根据主播的地理流行特征高效地调度主播，例如，边缘计算（分别为 核心云）对参与本地热门（分别为全球性流行）直播的用户能提供更优的性能。

在我们的边缘辅助的MPL范式中，如何将主播恰当地调度到不同的接入区域（包括边 缘计算区域和核心云）是一个关键问题。首先，我们设计了一种地理流行度指标，以刻画 主播的初始分配偏好。然后，考虑到严格的延迟需求，我们将动态广播者分配建模为一个 优化问题，旨在最小化主播与

观众之间的广播延迟，同时保持较低的运营成本。我们提出了一种带迁移的稳定匹配算法 （称为StableM‐M），通过两个步骤高效地解决该问题：首先，我们将广播者分配转化为 经典的多对一稳定匹配问题，并获得对广播者最优的匹配结果；其次，为了进一步考虑不 同接入区域间的负载均衡并提升整体系统性能，每个广播者都有动机在接入区域之间迁移， 且不会损害其他用户的体验，直到达到纳什稳定解。基于轨迹的评估表明，我们提出的边 缘辅助的MPL范式及所设计的算法相比静态分配平均可将广播延迟降低35%，运营成本降 低40%。

据我们所知，我们是首次观察到移动个人直播（MPL）中本地热门主播消耗大量资源 的研究。我们提出了一种边缘计算辅助范式，用于内容转码和交付服务。与以往仅关注优 化直播上传链路延迟的工作不同，[6, 47],我们优化了从主播到观众的端到端直播延迟。本 文其余部分组织如下：第2节介绍映客的背景及我们的数据集；第3节展示我们的关键测量 结果，并阐述我们边缘辅助范式设计的动机；第4节介绍系统模型和问题定义；第5节详细 描述我们的算法；第6节展示仿真结果；第7节回顾相关工作；结论在第8节中给出。

2 背景与数据集

本节中，我们简要描述MPL应用并重点介绍其通用系统设置。然后介绍我们的数据收集方法以 及所收集的数据集。

2.1 背景

本文通过对现代MPL应用进行用户行为与系统优化研究，以映客作为代表性案例。[29, 39]
映客是一款成立三年的移动个人直播社交应用，已发展成为领先的平台之一，拥有超过 2.5亿注册用户。在MPL平台上，任何用户均可作为主播发起直播，其他用户则可实时加 入作为观众观看。此类实时观看互动是本文重点探讨的主要用户行为。观众通过发送评论、 “点赞”和虚拟礼物与主播互动，这些内容对主播及其他所有观众均可见。其中，虚拟礼 物是激励主播创作精彩直播内容的重要激励机制。观众从MPL平台购买虚拟礼物并赠送给 主播，代表了一定数量的打赏。[5]为了适应异构用户的需求，类似于Twitch，映客通常 为优质用户提供自适应在线转码服务，即优质用户的直播内容将被转码为多种比特率，其 他优质用户可选择合适的比特率观看视频流。

在社交方面，MPL用户可以关注他人以形成有向社交网络。当用户开始直播时，其所 有关注者都会收到通知。此外，用户还可以浏览来自公开列表的直播，包括最新热门直播 列表和附近直播列表（直播按主播与用户之间的距离排序）。我们将在第3.2.2节探讨地理 影响对用户观看行为的影响。

2.2 数据集

我们的分析中包含三种类型的映客数据集。第一个数据集是由映客公司提供的会话日志， 包含4000万次直播会话和10亿次观看会话（时间跨度为2016年11月15日至12月15日的四周）， 由映客提供。每条直播日志包含用户的全局唯一标识符（GUID）、直播ID、开始时间、 直播时长以及用户的地理位置（包括所有省级区域）

由设备内置的GPS功能报告或通过网络参数（例如蜂窝基站）推断得出）。此外，每条观 看日志包含用户的GUID、所观看的直播ID、设备、连接类型（例如3G、4G和Wi‐Fi）、 开始时间、观看时长、访问的互联网服务提供商（ISP）以及用户的地理位置（仍为中国 境内的省级区域）。

第二个数据集是用户的社交信息，包括用户的关注列表和关注者列表。一个关键的挑战是， 映客并未向开发者或研究人员提供用于收集相关数据的官方API。为了识别可用于社交信息收 集的HTTPAPI，我们在使用映客时捕获了测试移动设备发送的网络流量。随后，我们实现了 一个分布式网络爬虫，并基于第一个数据集中的用户GUID收集了用户信息。

第三组数据集是用户所体验到的系统质量。映客应用配备了一个分析插件，能够在真 正的全球范围内精确测量来自主播与观众的质量指标，尤其是主播端的上传链路延迟和观 众端的缓冲事件。

3 移动个人直播（MPL）用户行为的测量

我们现在探讨以下两个方面：(1)用户活动的基本特征，包括直播受欢迎程度以及社交网络 的影响；(2)地理因素如何影响用户，包括观看体验和观看互动。我们认为这些研究不仅对 于理解用户行为至关重要，也有助于系统改进。

3.1 用户活动

我们观察到，每天的直播和观看次数相对稳定，并呈现出明显的昼夜模式，与参考文献 [39, 46]相似。平均每天有118万次直播和3582万次观看。这些广泛的个人直播活动促使我 们研究用户在MPL系统中观看直播的行为。

3.1.1 直播受欢迎程度

在图1中，我们从数据集中随机选取一部分直播，并展示它们 的观看次数（直播按观看次数降序排列）。我们观察到流行度分布高度偏斜：最受欢迎的 7.6%的直播吸引了超过80%的观看次数（如标有“全部”的曲线所示），这与移动视频 服务中的结果相似[26]。但该图不同于众所周知的幂律排名分布（在对数‐对数尺度下为一 条直线），我们发现其在排名1,000处呈现分段现象。我们推测这是由于优质主播与普通 主播之间的差异所致：（1）回顾前文，优质用户直播通过自适应在线转码获得了更好的服 务质量（QoS）。正如先前研究[10]所验证的，视频质量对观众参与度具有重要影响，因 此我们合理推断这种QoS差异导致了优质用户与普通用户的直播在受欢迎程度上的差异； （2）优质用户通常在直播方面拥有更丰富的经验，能够制作出更有趣、更高质量的内容， 优于其他普通主播，从而使优质主播更受欢迎。因此，在图1中，我们进一步分别绘制了 优质直播和普通直播的流行度分布，以验证我们的推测，并观察到优质用户确实更有可能 产生高度受欢迎的直播。例如，总体上仅有3.6%的直播由优质用户生成，而他们却占据 了最受欢迎的前1,000场直播中的45%。

3.1.2 社会影响

由于映客也是一个社交网络应用，用户之间可以相互关注，因此分析用户行为 如何受到社交链接的影响十分有趣。我们试图回答两个关键问题：（1）社交链接如何影响观看直播 的观众群体或观众集合

观众观看的主播；以及（2）社交链接如何影响观众在遇到问题观看会话时的耐心。

社交影响下的用户行为。 我们观察到一个明显的现象：拥有更多关注者的主播更容易 产生高度受欢迎的直播，这与[39]类似。为了详细量化社交影响，首先我们计算对于一场直 播：（1）有多少观看次数来自该主播的关注者，以及（2）其主播的关注者贡献了多少观 看时长。我们在图2（a）中选取至少有30名观众的直播作为代表。对于大多数直播，我们 发现关注者仅贡献了较小比例的观看次数，但贡献了较大比例的观看时长；例如，仅有 7.5%的直播中，超过60%的观众是主播的关注者；然而，对于73%的直播，其关注者贡献 了超过60%的累计观看时长。总体而言，在MPL系统中，关注者仅贡献了27%的观看次数， 却贡献了82%的观看时长。其原因如下：（1）大量观众在MPL系统中浏览以寻找他们感 兴趣的直播内容，从而产生了大量的观看次数，但每次观看时长较短；（2）社交关系强烈 反映观众兴趣，观众通常会为其关注对象的直播投入更多的观看时间。

粉丝与非粉丝的耐心。 放弃视频会话通常是由失去兴趣或网络连接不佳引起的。直观 上，当遇到有问题的会话时，主播的关注者比非关注者更有耐心。为了验证这一想法，我 们比较了“粉丝—关注对象”会话与其他观众会话的放弃概率。由于我们的数据集未提供 连接性能的信息，我们采用一种启发式方法来检测有问题的会话，如参考文献[27]中所述。
实际上，当观众被直播内容深深吸引时，即使其正在经历较差的网络连接，他们仍可能在 短时间内多次请求直播流，然后才放弃。基于上述观察，如果同一观众在v的请求之后的 时间窗口T秒内再次对同一场直播发起至少一次请求，则我们将观看会话v标记为有问题
的会话。本文中将T设为30秒。连续出现[24] x次有问题会话后的放弃比例
AbandonmentRatio(x)可计算为Im p atient(x) Im p atient(x)+Patient(x)，其中Impatient(x)表示在 经历少于x次连续有问题会话后放弃观看会话的观众数量，而Patient(x)表示在经历至少 x 次连续有问题会话后仍尝试请求直播的观众数量。

图2(b)绘制了随x变化的放弃概率。观众在观看关注对象的直播时更具耐心：当遭遇2次连 续的有问题的会话时，只有30%的关注者选择放弃，而在某些情况下，关注者甚至能容忍多达 20次连续的有问题的会话（见标注为“follower”的曲线）。然而，观众似乎对

当观看非关注对象发布的直播时，非关注者明显更加没有耐心：60%的非关注者在连续经 历2次有问题的会话后就会放弃，即关注者比非关注者耐心程度高出 2×；在连续经历10次有问
题的会话后，超过90%的非关注者会选择放弃（参见标注为“non‐follower”的曲线）。当x
≤ 4时，我们观察到放弃率上升最为剧烈。因此，MPL服务提供商应精心设计初始工作负载调 度方案以降低放弃比例，例如分别为主播与观众从地理分布的数据中心集合中选择合适的服务 器。

3.2 地理影响

3.2.1 地理影响对用户体验的影响：主播的作用

及时通信，即主播与其观众之间的低 广播延迟，对于用户所体验的质量至关重要。[39]与专业内容生产者靠近内容接入服务器 的传统视频流媒体系统不同，地理分布且动态的主播迫使我们必须考虑主播调度，例如降 低主播与接入服务器之间的上传链路延迟。

上传链路延迟。 为了降低上传链路延迟，MPL系统通常会将主播重定向至距离最近的 数据中心。然而，由于预算限制，用于内容接入的物理服务器数量有限，且可能距离主播 较远。例如，在我们的测量中，主要吸引中国人的映客仅在北京数据中心部署了内容接入/ 转码服务器。利用我们数据集中的上传链路延迟信息，我们观察到主播存在不稳定的上传 状况，平均上传链路延迟为735ms，平均标准差为632ms。主播接入网络（如Wi‐Fi和蜂 窝网络）条件的变化直接影响视频接入服务器接收到的直播内容的流畅性和稳定性，从而 进一步影响观众所体验到的流媒体质量。图3(a)对比了不同地理距离下，主播与北京视频 接入数据中心之间的平均延迟。我们观察到，正如预期，距离数据中心越远的主播不可避 免地经历更高的上传链路延迟。一些先前的研究也探讨了距离与内容下载延迟之间的类似 关系[17, 23]。

缓冲事件。 当直播播放器的视频缓冲区变空时，直播播放器将进入缓冲状态。基于所有观 众报告的缓冲事件，我们观察到约50%的观看次数发生了缓冲事件，表明移动个人直播（ MPL）中的观众面临严重且普遍的视频卡顿问题。为了进一步分析哪些缓冲事件是由主播引起 的，我们采用一种启发式方法：排除系统级影响后，若某位主播发生突发问题事件，其所有观 众都将经历缓冲事件，如图3(b)所示。据此，我们识别出总共25%的缓冲事件由主播引起。如 图所示，

图3(c)中可以看出，当采集服务器与主播之间的距离增加时，由主播引起的缓冲事件的平 均比率也呈现出上升趋势。地理分布的主播与观众使得MPL系统难以优化。因此，本文着 重于降低主播与观众之间的总广播延迟，以提升用户体验质量。

3.2.2 地理位置对用户交互的影响

理解地理影响对用户交互的作用有助于系统资源分 配。我们的直觉是，用户的地理位置包含了影响用户行为的社会、经济、文化及语言口音 方面，且用户更可能与邻近区域的其他用户频繁互动。

观众地理分布。 首先，我们分析每场直播的观众地理分布。第k场直播的归一化观众
地理分布熵定义为ek=(−∑n i=1pkilogpki)/ log n[27],，其中pki表示第k场直播在区域i的观众 占比，n为区域数量。对于映客数据，我们有中国34个省级区域，即n= 34。熵值较小 （相应地，较大）的直播表明其观众地理分布更加偏向某一区域（相应地，更均匀），因 此属于区域性热门（相应地，全球性热门）直播。图4（a）绘制了观众地理分布熵的累积 分布函数，呈现出低熵值特征。我们观察到95%的主播其观众熵低于0.5，且48%的直播的 观众熵等于0（所有观众集中在同一区域）。

为了说明直播的观众地理分布熵与其流行度之间的关系。我们在图4(b)中随机采样了 2万场直播，每个样本代表一场直播的观众地理分布熵，以及该直播的平均流行度，即观众 数量。我们观察到一个明显的模式：对于观众地理分布熵= 0（占总直播的48%）的主播， 其观看次数大致分布在较低范围（0,100），表明这些直播不仅在本地热门，而且在全球范 围内不受欢迎；而对于观众地理分布熵为 ≥0.8（占总直播的0.5%）的直播，其观看次数 大致处于较高水平(1000,10万)区间，意味着这些直播在观看地点和观看次数上均具有全球 性流行。

此外，我们观察到，89%的直播最受欢迎的区域与主播所在区域相同，验证了在
MPL系统中大多数直播具有“本地受欢迎”的特性。这种强烈的本地互动表明，“就近服 务”在系统设计中可以发挥重要作用。为了优化系统性能，例如降低直播延迟和缓解骨干网 络流量，我们建议MPL服务提供商（如映客等）可借助边缘计算[2]通过利用边缘计算与 网络资源，在小范围区域内对直播内容进行转码并传输直播内容。

4 边缘辅助系统模型与问题建模

根据之前的测量结果，我们展示了移动个人直播（MPL）服务在使用边缘计算方面的巨大 潜力。在本节中，我们提出了边缘辅助的MPL架构，该架构旨在通过经济高效地将大量本 地热门主播卸载到边缘计算，以减轻核心云工作负载。

4.1 系统模型

在当前纯基于云的MPL系统（如图5所示）中，大量主播被完全分配到昂贵的核心云进行 直播内容采集和转码，同时使用CDN引擎进行直播内容分发。具体而言，在映客场景中， 主播移动摄像头捕捉实时视频，并以25fps的帧率使用H.264对视频进行编码。

然后，视频帧通过实时消息传输协议(RTMP)等协议持续上传到接入服务器。为了支持自 适应比特率流媒体，可独立处理的非重叠图像组(GOP)形成连续的视频片段[14, 18, 28]并产 生转码任务。通过HTTP实时流媒体，由云小片转码的流媒体片段直接传送给附近的观众， 或转发至内容分发网络(CDN)[46]以实现全球内容分发。

受我们在测量工作中观察到的大多数本地热门主播的启发，这些主播符合基于位置感 知的直播分发模式，我们提出了一种边缘辅助MPL架构以提升系统可扩展性，如图6所示。

在这种边缘辅助架构中，用户（即主播与观众）以及可用的边缘资源（即边缘云粒）会定 期向集中式调度器上报其活动和工作负载状态。主播的历史活动和行为数据将用于预测其 在未来一段时间内的广播地理流行度。此外，我们假设该架构本身可通过使边缘云粒相互 监控并持续获取端到端网络延迟，从而形成一个有效的服务质量监控子系统。基于所获取 的全局系统信息（包括主播的地理流行度和边缘云粒的可用资源），集中式调度器决定主 要的调度策略，即将哪些主播的内容摄入和转码任务分配给哪些边缘云粒或核心云。

边缘计算辅助MPL系统的潜力。为了粗略评估将这些本地流行的主播卸载到边缘计算 的潜在优势，我们估算了不同直播所消耗的计算和带宽资源（类似于参考文献[47]中的测 量工作）。在纯核心云MPL系统中，计算资源由核心云提供，用于转码直播内容；带宽资 源由内容分发网络(CDN)提供，用于向观众传输直播内容。图7显示了计算/带宽资源的占 比

本地热门直播在整个系统中的资源消耗情况如下：根据标注为“广播：本地”的数据线， 我们观察到观众与主播位于同一区域的直播消耗了约30%（分别为2.5%）的计算（分别为 带宽）资源。同时，如标注为“广播：本地及相邻”的数据线所示，观众来自主播所在本 地及相邻区域的直播消耗了约45%（分别为10%）的计算（分别为带宽）资源。此外，主 播与观众处于同一区域（分别为同一区域及相邻区域）的总观看次数消耗了约35%（分别 为55%）的带宽资源。

总之，纯核心云MPL系统必须持续从核心云分配昂贵的带宽/计算资源来服务这些本地 热门主播。然而，将这些本地热门主播适当地卸载到成本效益更高的边缘计算，是提高系 统性能并降低运营预算的有效方法。

然后，我们对边缘辅助的MPL系统进行建模。为了便于讨论问题，我们将时间离散化
为时隙。在时隙t中，主播构成一个集合 B t={b1, b2,…,bm}。每个主播b ∈ B t都有一组观
众 V b。根据边缘云粒的地理位置分布，我们定义一组边缘计算区域 R e={r1,r2,…rl}。核
心云Rc位于核心网络，即核心计算区域。因此，我们的系统共有 R= R e ∪{Rc}个区域提 供服务，即直播内容摄取与转码服务。每个区域有nr个可用实例（或云小片），其服务速 率为 μr。主播与区域之间的分配关系用一个二进制 |B t| × |R| 矩阵 X表示。每个主播必须恰 好被调度到一个区域。因此，矩阵X中每一行的元素x(b, r)(b ∈ B t,r ∈ R)之和等于1。

由于MPL中的大部分主播是本地热门的，为了高效利用边缘网络/计算资源并保证本 地热门直播的低广播延迟，我们假设边缘计算区域能够摄取/转码其附近主播上传的直播内 容（步骤 ©1 ©2），并向其附近的观众分发直播内容（步骤© 3）。如果没有其他合适的边缘 资源可用，则这些未分配的直播将被调度到核心云。对于服务观众方面，我们定义平均而 言CDN引擎提供的分发延迟为do。类似地，考虑到边缘计算区域r的上传带宽容量有限， 且观众可能距离r较远，我们仍然使用CDN引擎来服务那些无法由边缘区域r满足的观众的 内容请求（步骤）。具体而言，当一个直播b被区域r摄取，并且从区域r到区域r′的内容
分发延迟d(r, r ′高于（分别低于）CDN分发延迟do时，区域r的云小片将（分别不会）为来 自区域r′的b的观众提供服务。对于由核心云Rc服务的主播（步骤），他们的所有观众均 由CDN引擎服务（步骤）。

为了高效且及时地将主播调度到接入区域，我们系统地设计了包含两个步骤的优化机 制：（1）初始分配：如第3.1.2节所示，初始工作负载调度对用户体验至关重要。因此，对 于具有历史行为/活动（例如粉丝地理分布和历史观众地理分布）的主播，系统根据其地理 流行度指标，从核心云区域或边缘计算区域中为其初始分配一个接入区域；（2）基于主播 的实际流行度进行内容接入/转码和分发的主播调度。

4.2 预测主播的地理流行性以实现初始分配

如图4所示，MPL主播根据观众地理分布熵可分为不同级别的地理受欢迎程度，表明在初始分 配时

将具有历史活动的主播分配到从核心云或边缘计算区域中选择的接入区域是可行的。
我们将观众地理分布熵作为主播的地理流行度指标，简称g‐Indicator：g‐Indicator接近 1表示该主播具有全球性流行特征，倾向于分配到核心云区域进行全球内容分发；g‐Indicator 接近0表示该主播具有高度本地热门特征，适合卸载至边缘计算区域。给定主播的g‐I ndicator后，一种直接的分配决策方法是设定一个阈值S：如果g‐Indicator ≤ S，则将该主播 调度至边缘计算区域，否则分配至核心云。因此，我们基于阈值S将主播划分为两个聚类，即本
地热门主播集合 B t l={b|g‐Indicator(b) ≤S,b∈ B t}和全球性流行主播集合 B t д={b| g‐Indicator(b)> S,b ∈ B t}。随后，我们利用机器学习分类器，基于主播在过去X天（在我们 的数据集中）的早期行为特征来预测其g‐Indicator类别，理想情况下X取值较小。

特征选择。 基于我们的用户行为分析，我们探索了多种不同类型的特征来刻画主播在 过去X天内的特征：（1）主播画像/社交特征：是否为优质用户、关注者数量、关注者地 理分布熵；（2）主播活动特征：收到的虚拟礼物数量、发送的虚拟礼物数量、直播次数、 观看次数；（3）直播互动特征（主要使用平均值）：最大并行观看数、直播时长、观众地 理分布熵。然后，我们利用这些有效特征建立分类器。

分类器。 我们的目标是根据主播在过去X天内的行为/活动，将两组主播进行分类。我们构建了 包括支持向量机（SVM）、贝叶斯网络（BN）、AdaBoost和随机森林（RF）在内的机器学习分类 器，以验证我们的特征具有强大的预测能力，并且地理流行度指标在第6.2节中的初始分配是有效的。

根据图4的结果，我们选择S= 0.8，这表明具有大规模观众的绝对全球性流行主播将 在初始分配时被分配到核心云区域。在初始分配之后，我们根据实时流行度进行主播调度。

4.3 问题建模

4.3.1 用户体验质量模型

主播与观众之间的及时交互对移动个人直播（MPL）至关重要，任何由较长广播 延迟引起的反馈延迟都会产生负面影响，这使得移动个人直播（MPL）成为一个典型的延迟敏感型系统。本文中， 我们希望通过最小化主播与观众之间的广播延迟来优化用户体验质量(QoE)，这一研究令人感兴趣。

我们定义直播 的总广播延迟 ，即 与其观众 b之间的总广播延迟 为 t<(/ , , b<)>，其中 是 的接入区域。该延迟可计算为
D t
(b, r,V b ) = ∑
v∈V b
(dt (b, r) + dt r(in) + dt (r, v)) , (1)
其中，dt(b,r)是主播b与区域r之间的上传链路延迟；dtr(in)是服务响应延迟，即接入 延迟，由区域r中云小片的负载和转码速度决定，具体解释见后文；dt(r,v)是区域r与观
众v之间的内容分发延迟，dt(r,v)=min(d(r, r ′),do)。具体而言，对于来自满足{r′|d(r, r ′)
≤do的区域r的观众v，有dt (r,v)=d(r, r ′)；而对于来自其他区域{r ′|d(r, r ′)>do, R e }的
观众v，有dt (r,v)= do。

主播上传的入站视频帧被动态地划分为离散的转码任务，可由区域 R提供服务。由于 广播者的异构性，各区域的入站服务需求速率可能随时间剧烈波动。因此，我们假设

假设每个区域的传入任务按照泊松过程随机到达。每个区域将传入的任务添加到其自身的 队列中进行处理。因此，类似于之前的研究[20, 50],采用M/M/1队列模型，基于利特尔法 则来评估区域r的平均响应时间：
dt r(in)= 1
nrμ r − λr
, (2)
其中nr是区域r中实例（或云小片）的数量， μ r是每个实例的服务容量。 λr是区域r中的 任务到达率。我们用 λb表示主播b的服务需求，因此 λr=∑b∈B tx(b, r)λb。

然后，边缘辅助的MPL系统中的总传输延迟为
D t= ∑
r ∈
R, b∈B t
x(b, r)D t (b, r,V b). (3)

4.3.2 运营成本模型

边缘辅助的MPL系统的运营成本由多个部分组成，包括边缘/核 心计算区域中的计算资源供应成本、从边缘区域到观众的出站流量成本、内容分发网络 (CDN)服务全球观众的带宽成本，以及从边缘/核心计算区域到CDN引擎的出站流量成本 （该成本与直播次数成正比）。我们定义Ct(b,r)为主播b被分配到区域r时的总运营成本，
其中包括服务供应成本Cp (b,r)、区域r中的出站带宽使用成本Cn (b,r)，以及CDN中的出站
带宽使用成本Co (b,r)。然后，Ct (b,r)的计算公式为
Ct (b, r) = Cp (b, r) + Cn (b, r) + Co (b, r). (4)
首先，Cn (b,r)（分别地，Co (b,r)）与由区域i（分别地，CDN）服务的观众的带宽需求
成正比。然后，如果b需要CDN引擎为其观众提供服务，则Cn (b,r)应加上将转码内容传送 到CDN所产生的额外带宽消耗。因此，系统总运营成本为
Ct= ∑
b∈B t, r ∈R
x(b, r)C t (b, r)
. (5)
为了在保持运营成本Ct较低的同时最小化广播延迟Lt，我们通过采用一个函数 F来将 Lt和Ct进行统一，以定义整体系统性能，例如，采用不同权重的线性组合：
min
x
( b, r)
F(D t, Ct ), (6)
受限于
∑
r ∈R
x(b, r) = 1,∀b, (7)
x (b, r) ∈{0, 1},∀i,j, (8)
∑
b∈B t
x (b, r) λb ≤ δr1nrμ r,∀r, r ∈ R, (9)
∑
b∈B t
x (b, r) η (b, r) ≤ δ r2 W r ,∀r, r ∈ R e . (10)
约束方程（7）确保每个主播在指定时间恰好连接到一个云站点。为了提供高质量的服 务，约束方程（9）确保没有任何区域因接入/转码任务而过载，即在任何给定时间，计算 需求不超过容量。)是区域中主播b的观众的带宽需求
r，且约束方程(9)确保带宽需求不会超过带宽容量。δr1和 δr2右侧的衰减因子用于预留部分 容量以应对突发流量。
该问题是一种多目标分配问题的变体[36],属于NP难问题。具体而言，在边缘辅助的 MPL背景下，该问题规模巨大，例如存在数以万计的并发主播以及可能数百个区域。为了 在用户需求和网络状况变化时动态且高效地将主播映射到区域，在下一节中，我们采用稳 定匹配和博弈论技术，这些技术已被视为解决大规模网络问题的有效替代方案[43, 44]。

5 主播调度：基于稳定匹配的解决方案

在本节中，我们基于带有迁移过程的稳定匹配解决方案设计了主播调度算法，该算法包含 两个阶段：首先，我们基于一对多稳定匹配框架将主播调度到不同区域，从而解决诸如大 学录取问题之类的经典分配问题[12]。在此匹配阶段，由区域工作负载决定的不同区域的 响应延迟dt r(in)无法被有效纳入考虑；因此，在第二阶段，为了进一步考虑负载均衡因素并 提升整体系统性能，我们让集中式调度器持有匹配结果，然后在区域之间迁移主播，以降 低公式(4)中定义的系统总成本，从而做出最终分配决策。

5.1 主播‐区域稳定匹配

为了将大规模主播分配到各区域，我们采用了一种高效的多对一稳定匹配解决方案，即延 迟接受（DA）[32]算法。类似于大学录取问题，存在 |B t| 主播（作为学生）申请 |B| 区域 （作为高校）的计算和带宽资源。首先，我们分别定义主播和区域的偏好。

主播对区域的偏好列表： 为了获得更好的用户体验质量(QoE)，主播更倾向于选择能 够以低广播延迟处理其内容接入/转码任务的区域。我们将第i位主播bi的偏好列表表示为 L
(bi)={rj ∗,...}。主播bi根据公式(1)中定义的主播bi与区域rj ∗之间的广播延迟Dt(bi,r j ∗,V b)， 对所有区域建立偏好列表，并按升序排列。

在大多数现有的多对一稳定匹配问题中，偏好列表是固定的且相互独立。然而，内容
摄入的dt r(in)响应延迟依赖于不同计算区域的工作负载，导致主播对区域的偏好列表彼此之 间相互依赖。具体而言，最多存在|R t| | B t |种分配方案，使得可能的响应延迟分布数量也呈 指数级增长。如参考文献[22],所述，鉴于在一组相互依赖的偏好列表下获得稳定匹配的复 杂性，要在短时间内确定所有指数级可能情况下的响应延迟和偏好列表是具有挑战性且不
切实际的。为解决这一技术问题，我们采用一个区域能提供的最差响应延迟来估算dt r(in)。
根据公式(2)，当一个区域承载最大负载 δ j nrμ r时，可计算其最大响应延迟。该方法的合理 性基于两个方面：第一，容量更大的计算区域可以服务更多的主播，从而充分利用计算资 源；第二，主播倾向于选择在最坏情况下响应延迟最低的区域（如果这些邻近区域提供的 内容上传链路延迟和内容分发延迟相似）。

云站点对主播的偏好列表： 考虑到为主播分配计算和带宽资源所带来的运营成本，一 个区域更倾向于服务成本较低且不超出其资源容量的主播。因此，我们定义第j个区域rj对 主播的偏好列表为 L(rj)={bi∗,...,}，其中包含需求不超过该区域容量的主播，即满足 约束公式(9)和(10)的主播。偏好列表 L(rj)中的项也根据将主播bi∗分配给区域rj时产生的 运营成本Ct(bi∗,rj)按升序排列，该成本由公式(4)定义。

与传统的大学录取问题[12],不同，在传统的大学录取问题中，每个学生需要占用一所 学校的一个配额，而在主播调度问题中，每个主播具有不同的资源需求。因此，我们必须 考虑一些新的维度。具体而言，在给定的匹配 ϕ中，当主播bi偏好区域rj胜于其当前被分 配的区域 ϕ(bi)时，我们需检查区域rj是否拥有可用资源，或者通过拒绝一些排名较低的已 分配主播，区域rj是否能腾出可用资源。如果主播bi有可能被分配到区域rj，那么涉及的 区域rj和主播bi将分别有动机脱离当前匹配，以降低直播延迟和降低运营成本。为方便表 示，我们定义x>z y表示z偏好x胜于y。我们在主播‐区域稳定匹配问题中对阻塞对的定义 如下。

定义1（阻塞对）。 在一个匹配 ϕ中，主播‐区域对（bi，rj）如果满足以下两个条件中的 任意一个，则称为阻塞对：
(1)类型1阻塞对：rj>bi ϕ(bi)，且将bi匹配到rj不违反约束公式(9)和(10)。(2)类型2
阻塞对：rj>bi ϕ(bi)，bi>r j bi′和 ϕ(bi′)=rj。在将bi分配给rj并从rj移除bi′后，约束 公式(9)和(10)不被违反。
根据稳定匹配的约定，如果上述阻塞对不存在，则匹配 ϕ是稳定的。我们使用DA [32]算法来生成主播与区域之间的稳定匹配。在我们的解决方案中，主播作为提议方，这 将产生在所有可能的稳定匹配中为主播带来最佳广播延迟的稳定匹配。该算法在算法1中 进行了描述。首先，主播和区域都生成各自的偏好列表（第1行）。然后，主播开始向其最 偏好的区域提出提案（第3行）。在接收到提案后，每个区域在容量约束下选择其最偏好的 一组主播，并拒绝其余的（第4到第10行）。此过程重复进行，直到不再有新的提案产生为 止。考虑到当前MPL系统中所有主播均由核心云Rc服务，我们同样假设在边缘辅助的 MPL系统中核心云具有足够的容量。因此，每个主播b都可以被匹配到一个区域 R。

定理1. 算法1产生一个稳定匹配解。
证明：主播对区域的偏好仅与式(1)中定义的广播延迟相关。在每一轮中，所有主播依 次向其偏好的区域提出申请，然后各区域决定接受最偏好的主播。一方面，如果存在类型
1阻塞对(bi, r j)，则在rj中必然存在可用资源，这与区域资源耗尽前持续接受主播的流程相 矛盾；
另一方面，如果存在类型2阻塞对(bi , rj)，这表明区域rj在迭代轮次中接受了偏好较低 的主播。然而，在每一轮中，每个区域在接收所有提案后仅保留最偏好的一组主播。因此， 上述情况不会发生。故该过程不会产生任何阻塞对。因此，算法1得到的解是一个稳定匹 配。

算法1： 主播‐区域稳定匹配过程 输入：主播集合 Bt 和区域R； 每个区域的计算容量和衰减因子：∀r,nr，μr，δ r。
输出：将主播分配到区域： ϕ，x(b,r)，∀b,r
1每个主播和区域建立自己的偏好列表：∀i， L(bi)，∀j， L(rj)
2重复
3 每个主播根据其偏好列表向最偏好的区域提出申请。
4 如果所有提案都不会违反公式(9)和(10)中的容量约束那么
5 每个区域暂时保留所有申请。
6 end
7 else
8 根据区域的偏好列表，该区域将保留最受欢迎的提案 不违反容量约束。
9 该区域拒绝其他不可接受的提案。
10 end
11 until主播尚未提出任何提案。
12将获得的匹配 ϕ转换为x(b,r)，∀b,r。
13返回 ϕ, xij;

为了弄清边缘辅助的MPL系统潜力，我们考察了一天中偏好核心云而非所有其他边缘 区域的主播所占比例。通过将我们的区域间延迟数据集作为D(b, r)的输入（具体数据集见第 6节），结果表明，平均只有0.5%的广播者属于全球性流行类别，说明边缘计算区域将在 我们的系统中发挥重要作用。

5.2 主播迁移

算法1产生一个主播最优稳定匹配，即对于每个主播b， ϕ(b)是b所能获得的最偏好的区域。
但算法1存在两个局限性：（1）主播无法确定确切的响应延迟；（2）在主播提出提案后， 区域只能被动接受主播。受参考文献[43],中方法的启发，我们采用一种主播迁移策略来 缓解上述局限性，该策略进一步考虑了负载均衡问题，并提升了整体系统性能。

我们定义 Br为分配给区域r的主播集合，该集合可通过匹配 ϕ获得。为了降低直播延 迟和减少运营成本，主播有动力根据公式(6)中定义的效用来在不同区域之间迁移。

定义2（迁移规则）。 在匹配 ϕ中，若主播b满足以下两个条件，则有动机从Bx（即区
域x）迁移到By（即区域y），并为区域x和区域y形成两个新的主播集合Bx ∗= Bx{b}和
By ∗= B y ∪{b}：（1）该迁移不违反区域ry的资源容量约束（公式(9)和(10)）；（2）如公
式(1)和(4)所定义，迁移值满足Mд(b,x,y)=(D(Bx) +D(B y) −D(B x ∗) −D(B y ∗) −)+ α(C
(b,x) −C(b, y))> 0, α ∈[0, 1]，其中D(B x) （分别对应D(B y) /D(B x ∗)/D(B y ∗)）表示将主播集合
Bx（分别对应Bx ∗/By ∗/By）分配给区域x（分别对应y/x/y）时的总广播延迟， α是广播 延迟与运营成本之间的权重因子。迁移值Mд(b,x,y)越高，表示将主播b从区域x迁移到区 域y的动作越有价值。

算法2: 主播迁移流程
输入:主播分配P={Br1, Br2,…, Br|R|}由算法1获得；
广播延迟组件dt(b,r),dtr(in),dtr(tr),dt(r,v): ∀b,∀r; 运营成本Ct(b,r): ∀b,∀r; 每个区域的计算容量和衰减因子：∀r,nr,μr,δ r。
输出：广播者与云站点之间的映射：xi,j，∀i，j
1重复
2 每位主播计算其有效迁移（b，x，y）。
3 找到使Mд(b,x,y)最大的迁移(b,x,y)；
4 接受迁移(b,x,y)并更新广播者分配P。
5直到主播分区P收敛。

定理2。 根据从算法Pstart 1获得的主播划分1，算法2收敛到一个纳什划分Pend。
证明：我们定义Pm为经过m次迭代后的主播划分。根据算法2，给出了一系列划分：
Pstart→P1→P2…→Pend。迁移操作(b,x,y)仅影响广播集合Bx和By（形成新的划分B
x ∗= Bx{b}和By ∗= By ∪{b}），以提升系统性能。每一次相邻的迁移，例如Pl→ Pl+1， 构成一个传递且反自反序。
D(Bx ∗)+ D(By ∗)+ α C(b, y)< D(Bx)+ D(By))+ α C(b,x).
由于广播分区的数量是有限的，算法2收敛到一个最终的分区Pend。此外，假设Pend不是纳 什稳定的，并且存在一个迁移操作(b, x,y)能够带来更好的系统性能。那么算法2将继续执行， P不会收敛，这与之前证明的算法2的收敛性相矛盾。因此，算法2收敛到一个纳什稳定解。

然后，我们分析上述两个算法的算法复杂度。对于算法2，它最多在 |R||B t | 次迭代后
终止。在每次迭代中，一个区域接受其最偏好的主播。对主播进行排序需要O(|B t|loд2(|B t|))
的计算量。因此，对 |R| 个区域的主播进行排序需要O(|R||B t|loд2(|B t|))的计算量。因此，
算法1的时间复杂度为O(|R|2|B t|2loд2(|B t|) ∼ |B t|2loд2(|B t|))。由于第4.2节验证了广播者 区域流行度的可预测性，我们的评估将根据观众地理分布熵将广播者聚合到区域组中，这 大大减小了 |B t| 的量级，并提高了我们算法的效率。对于算法2，在每一轮中，可能的迁 移空间为O(|B t||R|)。

6 性能评估

在本节中，我们进行了广泛的基于轨迹的仿真，并给出了数值结果。具体而言，我们使用 真实世界数据集来表征所提算法的有效性，并将其与其他传统的调度方案进行比较。

6.1 仿真默认设置与方法

基于来自映客的数据集和轨迹，我们通过考虑主播和观众的行为、广播延迟、服务器租赁成本 以及调度，开发了一种事件驱动仿真
将决策作为事件来驱动实验。我们根据收集到的轨迹设置实验，并将我们的设计与四种基线方案进 行比较。具体细节如下。

用户与计算区域。我们选择了一个包含48.5万名主播和249.8万名观众的丰富数据集， 这些用户在中国全部34个省级行政区产生了112.6万场直播和3684万次观看次数。因此， 默认情况下，边缘云节点区域的数量为 R e= 34。此外，映客将其推流/转码任务部署在位 于北京的阿里云，即我们的核心云Rc。由于官方邀请的主播和以自我表达为目的的主播通 常都有规律的日常直播时间安排以吸引更多观众，我们假设每个区域中主播的行为及其受 欢迎程度是可预测的，并且可以事先获知，也就是说，下一时间段内主播与观众的数量及 其地理分布可以通过多种预测算法（如回归模型ARIMA[48]）进行学习。

服务容量。在本实验中，我们假设核心云能够提供的计算容量（即实例）等于整个 主播数量的4%，这是映客的设置，且CDN引擎能够提供无限的带宽资源，从而满足所有 观众的请求。我们假设每个边缘区域能够提供的计算（分别指带宽）容量范围为整个主播 数量（分别为整个观众数量）的1.5%到4.5%。

广播延迟。(1)主播的上传延迟D t (b,r)从我们的映客数据集中获得；(2)服务响应延 迟由服务速率（即转码速度）和转码任务到达速度决定。我们将每个实例的服务速率设置 为 μr= 80fps，该值是使用ffmpeg在阿里云实例ecs.sn1.medium(Ubuntu 14.04 LTS)上将源 映客视频分别从1.2kbps转码至1kbps、0.8kbps和0.6kbps的平均转码速度。根据映客 的设置，我们将每个主播的转码需求速率设为 λb= 20fps。衰减因子 δr= 0.9；(3)为了获
得观众的下载延迟D t (r,vb)，我们分析了来自腾讯CDN的另一数据集4，该数据集包含不同 区域的用户从不同区域的CDN服务器下载时的延迟轨迹。这些区域间下载延迟被用作我们 实验中的输入。

运营成本。我们根据阿里云成本(Rc)的商业定价标准进行调整，例如每实例每小时 0.13美元，每GB0.12美元。对于边缘计算区域租赁成本，由于目前尚无商业定价标准。鉴 于边缘网络中存在近乎免费且丰富的边缘计算资源5,，我们将边缘区域的租赁成本设为较 低水平，平均为0.5 ·成本(Rc)，随机在0.1 ·成本(Rc)到0.9 ·成本(Rc)之间。

我们将我们的算法与现实中常用的以下方案进行比较：
中心方案：当前MPL系统中使用的方案，所有广播者都被调度到核心云，并由CDN引擎分发。
StableM-M：我们的带迁移的稳定匹配算法。除非另有说明， α= 0在迁移定义2中， 以便我们首先将广播延迟视为最关键的目标。
随机方案：主播根据容量被随机调度，超出容量的主播将被调度至核心云。
最近方案：根据主播与区域之间的上传链路延迟，定义主播对区域的偏好列表。主 播被调度到其本地区域，这些区域根据容量接受主播。然后被拒绝的主播被迭代地调度到 下一个区域。

贪心背包方案：采用了一种贪心背包算法[15, 47]应用于我们的场景。所有在主播和
区域之间的可能分配对(b,r)都被一起推入一个队列中。该队列根据单位成本分配效用U tility(b,r)/Ct(b,r)按降序排列，其中Utility(b,r)指广播延迟增益（定义为loд(u −vD t(b,r)),u
= 100,v= 0.0011)。在容量约束下，该算法按照此排序后的队列贪心地接受分配。
StableM方案：仅在主播与区域之间进行稳定匹配。

6.2 默认设置下的仿真结果

基于g‐指示器的初始分配的有效性。 首先，我们检验了为分类器选择的特征是否是预测g‐ 指示器的有力指标。为了构建分类器的训练集，我们从g‐指示器 ≤ S(S= 0.8）的主播中随 机抽取6万个作为本地热门集合，并选取g‐指示器> S的另外6万个主播组成全球热门集合。
我们使用第X天X= 1,3和第7天的数据。每次实验均进行五折交叉验证，并报告分类准确 率和F分数。如图8(a)所示，我们观察到：（1）我们的行为/活动特征能够有效预测主播的 地理流行度类别。即使仅使用最后1天（分别地，7天）的数据，准确率也较高，例如随机 森林达到78%（分别地，96%），这证实了主播的早期状态是其未来直播地理流行度的良 好指标；（2）当使用较少数据（例如1天）时，不同分类器的结果存在差异，而当使用7天 数据时，所有分类器性能接近，最高可达96%。F分数的结果与图8(a)非常接近，因此为 简洁起见省略展示。

图8(b)显示了全球热门直播的百分比和总广播数量随时间的变化。我们得出两个关键 观察结果。首先，在初始分配中，仅有少量全球热门直播（5%）被调度到核心云区域。我 们在第5.1节进一步证明，这对应于偏好核心云而非所有边缘区域的主播比例的模式，表 明初始分配具有有效性；其次，观察到一个明显相反的每日模式：全球热门直播百分比的 峰值出现在凌晨4–6点，而此时总广播数量处于低谷。其原因是清晨时段进行直播的主播 较少，导致观众转向其他地方寻找主播。

StableM‐M算法的有效性。 我们通过模拟来研究StableM‐M策略相较于上述其他先 进方法的表现。为了便于比较，总广播延迟和运营成本均以中心方案的相应值进行归一化 处理。图9 a显示了总广播延迟的结果。

大致上，我们观察到：（1）我们的StableM‐M算法具有最低的广播延迟，优于其他四种 方案。具体而言，StableM‐M相较于原始的中心方案实现了65%的广播延迟降低（即延迟 减少了35%），分别比随机方案、最近方案和贪婪方案低约50%、40%和17%；（2）我 们的主播迁移流程成功带来了约10%的广播延迟下降。通过进一步分析每种调度方案，我 们发现：（1）随机方案虽然在一定程度上考虑了负载均衡（即摄入响应延迟），但完全忽 略了主播的上传链路延迟和观众的内容分发延迟；最近方案关注上传链路延迟，却忽略了 大规模观众的内容分发延迟，导致边缘区域出现严重的负载不平衡。这些缺陷使得随机方 案和最近方案的表现甚至不如当前的中心方案；（2）贪婪方案和StableM方案均考虑了不 包含响应延迟的广播延迟，且明显优于随机方案和最近方案；（3）我们的StableM‐M算 法通过聚焦综合广播延迟，有效地对广播者进行调度。

图9(b)展示了总运营成本。在默认设置下，边缘区域的平均成本等于0.5 × Cost(Rc)， 与当前的中心方案相比，我们的StableM‐M的运营成本降低了47%。由于其他方案在大 多数情况下也将主播调度到经济性更优的边缘计算区域，图9(b)显示了类似的结果，与 StableM相比，我们的StableM‐M为降低直播延迟牺牲了一小部分运营成本。

6.3 参数影响分析

为了研究边缘计算动态性的影响，我们改变了实验设置，引入了显著的振荡。

6.3.1 边缘区域容量的影响

为了了解边缘区域中实例供给能力的影响，我们将每个边 缘区域的实例数量从主播数量的0.6%变化到100%。如图10(a)所示，我们观察到，在每个 区域的实例限制等于主播数量的3%之前，广播延迟下降最为显著。这是因为本地热门主播 可用的边缘资源不足，且边缘区域的过载现象更为严重。当边缘实例超过3%后，广播延迟 趋于收敛并几乎保持不变，达到66%。其原因是，边缘区域更多的容量使得更多的本地热 门主播被调度到边缘，从而减少广播延迟，直到所有本地热门主播都被边缘区域容纳为止。
随着容量增加，运营成本也持续降低，仅

达到93%。这进一步证实了我们的StableM‐M是一种对主播最优的算法，该算法优先优化广播 延迟，其次才是运营成本。这是合理的，因为当今的系统运营商更加重视用户体验的服务质量。

6.3.2 边缘区域租赁成本的影响

接下来，我们研究边缘区域中不同资源租赁成本的影响。
我们将边缘区域的租赁成本设置为Cost(Re)= θ · Cost(Rc)，并改变 θ从 10−3到 103。如图 10(b)所示，可以看出，当 θ增大时，广播延迟和租赁成本持续增加。值得注意的是，当 θ= 10时，仍有一些主播出于低广播延迟的考虑而选择边缘区域。这些值会持续增加，直 到所有主播都被调度至核心云，即当边缘区域的租赁成本过高而不适用于实际应用时，边 缘辅助的MPL系统退化为仅包含核心云的当前范式。然而，通常情况下，我们可以使用可 用且高性价比的边缘设备（如高性能个人计算机）作为云小片，从而产生较低的运营成本， 可能如图10(b)中的0.2。

6.3.3 边缘区域数量的影响

图10(c)揭示了总广播延迟与边缘区域数量K之间的关系。
我们在拥有最多主播的前K个区域部署边缘计算区域，观察到随着边缘区域数量的增加， 总广播延迟逐渐降低。当边缘区域数量达到≤5时，曲线迅速下降至0.7，随后逐渐收敛到 0.65，表明服务提供商只需部署少量边缘区域以提供本地化服务，即可显著提升服务质量。

7 相关工作

视频流系统中的用户行为和内容消费模式已在多种场景中被研究，例如直播电视[25, 27],
点播视频[8, 10, 45],和移动流媒体[25, 27, 49]。个人直播中的用户特征也已被探讨，例如 游戏直播平台Twitch[31, 46, 47]和MPL系统Periscope[39]。然而，极少有研究关注与 社交关系和地理因素相关的用户行为，而这正是本文所研究的内容。

然后，我们调研了近年来在移动个人直播（MPL）中的资源分配以及边缘计算进展方面的相关 工作。

动态资源分配。 鉴于来自异构且地理上分布的主播和观众的大量动态直播需求，云自 然成为承担移动个人直播（MPL）视频接入和转码服务的一种成本高效的方案[6, 39]。视 频处理（例如转码）通常是一项计算密集型任务，而计算和网络资源始终有限。因此，持 续有研究聚焦于
视频流系统中的资源分配问题。[6]提出了一种通用的云租赁框架，通过任务迁移来平衡 主播上传延迟和租赁成本。参考文献[3, 15]强调了在考虑系统运营成本或资源容量约束的
情况下，为直播转码选择合适的视频表示集以最大化观众满意度的重要性。参考文献[47]
通过利用公有云和私有数据中心优化广播上传延迟。这些研究假设每个视频转码任务必须 使用一个专用服务器，并主要通过贪心求解经典的0‐1背包问题来进行资源分配。然而，移 动个人直播（MPL）中巨大的计算需求使得基于云的解决方案特别昂贵。与这些研究不同， 我们专注于降低主播与观众之间的总广播延迟。此外，得益于一些现代视频压缩技术可以 将视频流划分为不重叠的图像组(GOP)，许多视频转码工作表明[18, 28]这些GOP可以彼此 独立地进行转码，从而提高每个计算节点的利用率。因此，我们假设每个云小片中的一个 服务器可以处理来自多个主播的并发直播内容。因此，在边缘计算辅助的MPL中，边缘云 粒上的负载均衡和响应延迟也是一个重要的关注点。

边缘计算。 与我们的文章类似，参考文献[16, 51]也利用边缘计算作为云的补充组件， 其中终端观众贡献其计算资源用于视频转码任务。参考文献[51]设计了一种拍卖机制， 以激励观众贡献其可用的计算资源。这些工作聚焦于现有的观众组织，并将转码任务分配 给附近的观众。近年来，边缘计算在学术界和工业界都经历了快速增长[1, 21, 33],，其中 小型服务器（称为云小片）的资源被部署在网络边缘。例如，使用P2P协议来组织边缘资 源[4]；移动应用卸载系统将可远程在云小片上执行的计算密集型任务进行卸载，以克服移 动设备的局限性；众包视频CDN部署边缘云粒以预取并分发视频内容给用户[7, 13]。在本 文中，我们研究发现，边缘云粒可以被有效利用于具有大量本地热门直播的MPL系统，从 主播处摄取/转码直播内容，并向终端观众分发内容，从而提升用户体验的直播传输质量。

8 结论

近年来，MPL服务已达到主流规模。全球范围内涌现出大量移动应用程序，从Facebook Live到映客、Meerkat、Periscope等。在本文中，我们研究了新一代移动直播服务的特 征。以映客为案例，我们识别出MPL与传统流媒体服务之间的关键差异，包括偏斜且分段 的广播流行度分布、用户参与中的显著社交网络影响、用户体验中的明显地理影响，以及 大量本地热门主播消耗巨量计算和带宽资源的现象。受上述观察结果的启发，为了应对由 本地热门主播带来的不可预测的工作负载，我们构想了一种潜在的MPL框架，以提升系统 效率与可扩展性，即边缘辅助的MPL范式，其中边缘计算[1, 11, 41]协助本地热门直播的 内容摄取/转码/分发，以实现低广播延迟和低运营成本的目标。我们通过将主播动态调度 至不同的边缘/核心计算区域，在保持低运营成本的同时优化端到端直播延迟。该问题通过 带迁移的稳定匹配方案求解。基于轨迹驱动的仿真表明了我们方案的有效性；例如，我们 的方案将直播延迟降低了约35%。