Janus: 基于eBPF的5G实时AI控制器

O-RAN定义的RIC模型并不能很好支持对实时性有很高要求的用例，本文定义了一套基于eBPF的内联执行架构，从而可以将RIC的支持扩展到实时场景。原文: Taking 5G RAN Analytics and Control to a New Level^[1]

摘要

Open RAN为5G无线接入网(RAN)引入了模块化和解耦的设计范式，并承诺通过O-RAN定义的RAN智能控制器(RIC, RAN Intelligent Controller)实现完全的可编程性。然而，由于延迟和安全方面的挑战，RIC提供的遥测和控制主要局限于较高层面以及较长的时间尺度(>10𝑚𝑠)，同时还依赖于难以改变的预定义服务模型。为了解决这些问题，我们提出了一个完全可编程的监测控制系统--Janus，考虑到RAN的特殊性，该系统专注于灵活性、高效率和安全性。Janus建立在eBPF基础上，允许第三方以可证明的安全方式在RAN的功能组件中直接加载小程序(codelet)。我们用一种新的字节码修补算法来扩展eBPF，该算法可强制保证小程序运行时的阈值，并以安全的方式收集用户定义的遥测数据。我们建立了3个不同类别的应用(共17个应用，大多数在现有的RIC上无法实现)，并在不影响RAN性能的情况下部署在100MHz的4x4 MIMO 5G小区上，从而可以证明Janus的灵活和高效。

1. 简介

5G无线接入网(RAN)的一个关键转变是迁移到Open RAN架构，即RAN功能的虚拟化(vRAN)和解耦。这种方法允许供应商以更快的速度为不同组件提出独特的解决方案，从而促进创新。此外，无线智能控制器(RIC)[27, 31]允许第三方通过O-RAN[19]标准化开放接口建立数据驱动的、与供应商无关的监测和控制应用[9, 20]，从而更好的优化网络。

尽管愿景引人注目，但相关创新很大程度上仍处于非常早期的阶段，主要有两个原因。首先，RAN以很高频率产生大量数据，为RIC应用捕获、传输和处理数据会给计算和网络带来巨大压力。为了克服这个问题，由3GPP[13，14]标准化的传统方案是定义一小套关键性能指标(KPI)集合，每几秒钟或几分钟收集一次。O-RAN RIC通过提供一套新的标准化聚合KPI和数据源[25]，扩展了这一方案。每个KPI都通过服务模型(一种静态API形式，作为嵌入vRAN功能的RIC代理的一部分[24])定义，并规定了哪些数据可以被收集、以何种颗粒度收集。然而，这种方法发展缓慢，而且不能灵活扩展，任何不适合现有服务模型的用例，都需要指定定义了不同KPI集的新服务模型，并与选定的RIC和RAN供应商合作，增加对这种服务模型的支持，然后经历漫长的标准化过程，说服所有O-RAN供应商支持并实施这种模型。

其次，许多关键的RAN操作，如用户无线资源调度和功率控制必须在期限内完成，通常是几十𝜇s到几ms不等。为了满足最后期限，任何相关控制逻辑和推理必须在vRAN功能内部运行，而不是在RIC上，RIC的设计是为了处理时间尺度>10ms[78]的应用。现有RIC方法通过指定针对特定用例的服务模型来处理这个问题，每个模型都有一套支持策略(例如，从𝑁个可用无线资源调度算法中选择一种)。然而，与数据收集的情况类似，由于无法灵活引入新的控制和推理算法，因此很难扩展。此外，许多vRAN操作具有实时性要求，意味着为了支持新服务模型而增加的任何新功能必须在vRAN处理期限内完成，超出期限可能会导致性能下降[45]，甚至使vRAN崩溃(正如第7.2节中所示)，这使得RAN供应商不愿意增加新的功能和服务模型。

为了解决这些问题，我们提出了Janus，一个提供动态监测和控制vRAN功能的系统。Janus扩展了RIC，允许运营商和受信任的第三方编写自己的遥测、控制和推理代码(我们称之为小程序codelet)，这些代码可以在运行时部署在不同的vRAN组件上，不需要供应商的任何帮助，也不会干扰vRAN的运行。小程序通常在vRAN关键路径上内联执行，直接访问所有重要的原始内部数据结构，收集任意统计数据，并做出实时推理和控制决策。

虽然Janus通过将vRAN实现和数据收集、控制操作解耦，大大增强了RIC的能力，但也带来了一系列挑战。第一个挑战与灵活性有关，目前还不清楚构建有用的应用需要哪些以及多少RAN监控数据，以及哪些控制功能应该暴露给小程序开发者。我们通过识别标准vRAN架构中的关键位置和接口(称之为钩子hook)来解决这个问题，接口可以从若干收集点(collection point)收集丰富多样的数据，从而实现广泛的实时控制应用。我们还建立了一个工具链，允许开发者定义任意的数据输出结构，将收集的数据发送给RIC。最后，我们确定了一小部分精心选择的控制功能(我们称之为执行器功能actuator functions)，可以由加载在控制钩子中的小程序调用，实时改变RAN的行为(如改变功率、资源块分配等)。通过第4节中展示的用例，可以证明O-RAN服务模型可以作为Janus小程序，实现快速有效的控制和推理操作(例如，无线资源分配和干扰检测)，而这在O-RAN RIC中是不可能的。

第二个挑战是执行的安全性。虽然小程序是由受信任的各方提供的，但仍然可能出现无效内存访问或过长执行时间，从而导致错误和低效，造成数据损坏，超过实时完成时间，最终导致vRAN功能崩溃。我们通过提供基于eBPF[3, 92]的沙盒执行环境来解决这一挑战，eBPF解决了Linux内核[2]中的类似问题。小程序由C语言编写，被编译成eBPF字节码，字节码在vRAN控制和数据路径中通过内联的eBPF虚拟环境运行，可以直接访问选定的内部RAN数据结构和控制功能。在加载小程序之前，eBPF执行环境会对字节码[48, 92]进行静态检查，只允许运行内存访问安全的小程序。

我们进一步扩展该模型，使其符合vRAN要求，通过一种新颖的eBPF字节码修补机制，我们为小程序的执行时延加入了硬性的𝜇s级控制，该机制允许强制中断运行超过一定时间阈值的小程序。此外，我们还扩展了小程序的静态验证过程，以覆盖新引入的灵活的输出数据结构。我们还做了一些优化，确保在fastpath(Janus小程序运行的地方)支持当前还不知道的设计，使Janus对vRAN的性能影响最小。最后，我们将Janus与CapGemini公司[35]的商业5G vRAN协议栈(基于英特尔FlexRAN参考设计[57])和OpenAirInterface(OAI)[26]的开源4G/5G协议栈集成。

综上所述，我们做了如下工作:

• 提出了第一个安全、可编程框架，以最小的计算开销为vRAN动态引入灵活的监测和控制能力(第3节)，并通过在其上开发新的遥测、控制和推理应用来说明其功能(共17个应用)(第4节)。
• 提出并构建强制限制小程序运行时间和数据安全收集的机制，以确保vRAN满足安全和延迟要求(第5节)。
• 实现并优化了Janus(第6节)，并进行了全面评估(第7节)。

我们希望将来Janus能与O-RAN RIC集成，以进一步加强Open RAN架构，实现可观察、可编程和自动化的最终目标。

2. 背景及动机

2.1. vRAN架构

如图1所示，5G RAN由若干层组成(如PHY、MAC、RLC)，每一层负责一组不同的控制和/或数据平面操作。例如，PHY负责信号处理，MAC负责用户设备(UE, User Equipment)之间的无线资源实时调度。这些层分布在三个网络功能中，称为无线电单元(RU, Radio Unit)、分布式单元(DU, Distributed Unit)和集中式单元(CU, Centralized Unit)，CU又被进一步分解为控制面和用户面组件(CU-CP和CU-UP)。RU通常基于ASIC或FPGA，而CU和DU是虚拟化的(即vCU和vDU)，运行在带有通用处理器和加速器的商品硬件上[56, 90]。不同组件和层有不同的时延要求(参见[32])，并以不同速率产生事件和数据，如图1所示。

vRAN组件之间的通信是通过O-RAN[19]和Small Cell Forum[41]等标准化组织定义的开放接口实现的，而可编程性是通过近实时RIC[47]来实现。网络运营商在RIC上安装应用程序(O-RAN术语中的xApps)，以收集数据并进行推理、闭环网络优化或以近实时(>10ms)的反应速度报告问题。vRAN组件的数据收集和控制是通过供应商嵌入vRAN功能的服务模型来实现的，这些模型定义了每个xApp的数据报告类型和频率以及RIC可以执行的控制策略列表。

2.2. vRAN可编程性的限制

RIC用例最初的重点是网络自我优化、异常检测和粗粒度无线资源分配[60, 75, 78, 85]。在这样的用例中，重要的网络事件和控制决策以较低频率发生(每秒10次到100次)。xApp可以收集所需的遥测数据，执行推理并通过预先确定的控制策略集调整vRAN功能。不幸的是，该方案有以下严重限制:

数据量限制。 许多应用，如定位[62]、信道估算[66, 71]、干扰检测[63]和波束成形[72]都需要来自PHY的上行IQ样本。将所有IQ样本传送到RIC是不可行的(对于100MHz的4×4 MIMO来说，每个小区需要超过5Gbps的数据)。目前RIC通过在每个xApp服务模型中指定所需数据类型和频率(例如[37，38])来克服这一问题。数据格式及其所需的预处理(例如，子采样和平均数)取决于服务模型，vRAN供应商必须实现和支持每个专有服务模型，因此对互操作性构成了严重限制。

实时性限制。 一些vRAN控制回路(如UE无线资源分配和功率控制)有严格的时间限制(几十𝜇s到几ms)。不幸的是，目前的RIC设计无法满足这种时间限制，预期时延>10ms[78]。与遥测的情况一样，xApps通过使用服务模型提供的一组策略来克服这个问题，这些策略可以在vRAN功能内运行。然而，随着可用策略数量的增加，这种方法并不能扩展。例如，已经为网络切片提出了几种控制算法(例如，[42, 49, 52, 61, 74, 87])，每一种都是为特定情况量身定做的。将这种算法作为服务模型的一部分来实施将会非常困难，因为不得不要求所有RAN供应商都采用这些算法。

2.3. vRAN可编程性的需求

基于上述的局限性，我们认为需要新的解决方案来释放RIC的真正能力，该解决方案应满足以下要求:

(1)提供灵活的遥测机制，受信任的开发者可以访问原始vRAN数据，并根据应用要求和基础设施限制选择输出数据的类型、频率和粒度。

(2)实现任意控制和推理逻辑的能力，并且可以在RAN内部实时运行。

(3)安全的执行环境，保证任何(受信任的)代码在vRAN功能内运行时不会因为执行无效的内存访问而使vRAN崩溃，或超出实时处理的最后期限。

3. Janus概述

为了克服上述限制，Janus引入了一个内联代码执行框架，允许在vRAN的沙盒环境中动态加载自定义遥测或控制/推理代码。

3.1. 内联代码执行框架

图2显示了Janus的高层架构，下面介绍其主要组件。

Janus设备(Janus device)。 Janus设备是任何允许执行自定义代码的vRAN组件(即vCU或vDU进程)。Janus在用户空间的eBPF VM实例内执行自定义代码[59]。我们在vRAN中选定的地方引入Janus调用点或钩子(hook) ，这些地方可以调用自定义eBPF代码，与vRAN代码内联，使eBPF代码可以只读访问选定的vRAN内部上下文和辅助函数，包括各种3GPP定义的数据结构(见表1和第3.2节)。自定义代码可以在运行时从Janus设备上动态加载和卸载，而不会影响设备性能。我们选择eBPF作为沙箱技术，该技术可以支持内联、快速执行，并支持用高级语言(C)编写小程序，而且提供静态代码验证。其他方法，如Sandbox2[50]和SAPI[51]，需要在单独进程中运行自定义代码，有较高的IPC时延。WebAssembly[53]也是内联的，但缺乏静态验证，会导致异常内存问题[64]。

表1: 商业级vCU/vDU网络功能和OpenAirInterface中引入的Janus监控钩子。

Janus小程序(Janus codelets)。 Janus小程序是可以在运行时动态部署在Janus设备上的自定义代码。开发人员用C语言编写小程序，使用eBPF编译器将其编译成字节码。与任何eBPF程序类似，Janus小程序必须通过静态验证(例如，必须引入内存检查，只能有有界循环)。任何可能不安全的操作(例如，访问允许范围之外的内存)，只能通过一组白名单辅助函数(helper) 来执行。小程序在两次调用之间不保留任何状态，所有状态必须存储在一个叫做map的外部位置。小程序通过一个特殊的map将遥测数据发送到设备上运行的Janus输出线程，后者将其转发给Janus控制器。小程序集(codeletset) 是一组小程序的集合，在Janus设备的多个钩子上运行，并通过共享map以非常低的延迟进行协同。如果需要，跨设备的小程序可以通过控制器协调。

Janus控制器(Janus controller)和SDK。 Janus控制器负责控制Janus设备和小程序集，在O-RAN背景下，可以作为RIC xApp来实现。开发人员将小程序集上传到控制器，并为一个或多个Janus设备提供加载/卸载指令。在控制器允许加载小程序集之前，验证每个小程序集的安全性并确保其能终止。为此，我们增强了开源PREVAIL eBPF验证器[48]，对Janus辅助函数和输出模式进行验证。该控制器进一步用额外的控制代码对经过验证的字节码进行处理，如果运行时间超过了某个阈值，就会强制终止(见第5.1节)。打过补丁的小程序被JIT编译并通过网络推送到Janus设备上，同时还有基于protobuf灵活定义数据输出格式所需的元数据文件(见第5.2节)。控制器提供数据收集器，收集并反序列化从Janus小程序发送的数据。Janus还提供了SDK，允许开发者在开发周期早期对Janus小程序进行本地测试，该SDK包括编译器、验证器和调试器，以及Janus设备支持的所有辅助函数和map定义。

3.2. vRAN RIC新功能

我们通过一个简单而现实的例子(示例1)来介绍Janus实现的新的监测和控制能力。这个例子是为OpenAirInterface[26]的vDU开发的Janus小程序，被FAPI接口钩子所调用([88]，图1)。FAPI消息是C结构，有发给UE的关于无线资源的调度信息。在这个小程序中，每隔1000个事件，就会有一个维护获取的FAPI消息数量的计数器被发送到数据采集器。虽然很简单，但这个小程序提供了重要特征，证明Janus比传统RIC的设计更强大。

 1 struct janus_load_map_def SEC (" maps ") countermap = {
 2   . type = JANUS_MAP_TYPE_ARRAY ,
 3   . key_size = sizeof ( uint32_t ) ,
 4   . value_size = sizeof ( uint32_t ) ,
 5   . max_entries = 1 ,
 6 };
 7
 8 struct janus_load_map_def SEC (" maps ") outmap = {
 9   . type = JANUS_MAP_TYPE_RINGBUF ,
10   . max_entries = 1024 ,
11   . proto_msg_name = " output_msg ",
12   . proto_name = " output_msg ",
13   . proto_hash = PROTO_OUTPUT_MSG_HASH ,
14 };
15
16 SEC (" janus_ran_fapi ")
17 uint64_t bpf_prog ( void * state ) {
18   void * c ;
19   uint32_t index = 0 , counter ;
20   nfapi_dl_config_request_pdu_t *p , * pend ;
21   output_msg s ;
22
23   struct janus_ran_fapi_ctx * ctx = state ;
24   p = ( nfapi_dl_config_request_pdu_t *) ctx - > data ;
25   pend = ( nfapi_dl_config_request_pdu_t *) ctx - > data_end ;
26
27   if ( p + 1 > pend ) return 1;
28
29   if (p - > ndlsch_pdu > 0) {
30     c = janus_map_lookup_elem (& countermap , & index ) ;
31     if (! c ) return 1;
32     counter = (*( int *) c + p - > ndlsch_pdu ) ;
33     if ( counter == 1000) {
34       s . counter = counter ;
35       janus_ringbuf_output (& outmap , &s , sizeof ( s ) ) ;
36       counter = 0;
37     }
38   }
39   return 0;
40 }

示例1: Janus小程序示例

安全访问丰富的vRAN数据。 示例1第17行的状态参数是传递给Janus钩子的上下文，包含指向vRAN FAPI结构的指针[41, 81] (第24行)。该结构含有特定下行链路时隙的调度分配信息，每个用户信息有多达20多个字段，包括调制和编码方案、传输块大小、分配的资源块、MIMO等。验证器确保对内部vRAN上下文信息的只读访问。由于vRAN的模块化设计，不同标准(3GPP，Small cell论坛)规定了少量类似接口，这些接口在vRAN组件中携带所有相关状态。通过在这些接口上添加钩子，可以让Janus开发者访问大量vRAN遥测数据。我们已经确定并实现了这些钩子(表1)，在第4节中将演示如何利用这些数据实现多个RIC应用，而不需要修改vRAN的代码。请注意，不同vRAN供应商对接口的实现可能有所不同(例如，不同的C结构内存布局)。由于Janus的灵活性，我们能够根据观察到的差异进行调整，通过少量代码修改来保证相同的小程序功能。

状态维护。 Janus小程序依靠被称为map的共享内存区域来存储状态，并与其他小程序交换状态(参见第4节和附录A.1)。Janus提供了各种存储数据的map类型，包括数组、hashmap和布隆过滤器。在这个例子中，我们使用单元素数组来维护FAPI数据包计数器(第1-6行)。每次调用时，通过辅助函数从内存中恢复计数器引用(第30行)，根据新收到的数据包数量递增(第32行)，同时进行各种安全检查以实现静态验证(例如第27行和第31行)。

灵活的输出格式。 Janus小程序可以通过一个特殊类型的环形缓冲区map(第8-14行)，使用灵活的输出格式向数据采集器发送任意遥测数据，该map被关联到一个由小程序开发人员定义的特定protobuf格式(见第5.2节)。这个例子使用了一个名为output_msg的自定义protobuf格式(第21行)，包含一个计数器字段(第34行)，通过辅助函数(第35行)将数据导出到数据收集器。这种灵活性使我们能够基于Janus vRAN钩子实现O-RAN RIC规范中目前可用的数据模型，而无需修改vRAN中的任何一行代码。

安全、丰富的自定义控制操作。 Janus小程序不能直接修改vRAN状态，相反，对vRAN行为的修改是通过由vRAN供应商提供的执行器辅助功能(actuator helper function) 完成的，执行器负责应用小程序决定的变更。鉴于vRAN功能中只有少量实时控制回路，只修改符合标准的3GPP参数(存在于所有RAN供应商的实现中)，我们认为使用执行器辅助功能是合理的方式。在此基础上，我们确定并实现了一些控制钩子(列在表2中)，这些钩子控制了大多数关键控制回路，可用于新的控制应用。我们使用切片间无线资源调度钩子作为示例，实现OAI中的3种网络切片算法(见第4节)，通过使用allocate_slice_rbs()执行器辅助函数修改分配给每个切片的资源块数量。

表2: 在商用级vDU网络功能和OpenAirInterface中引入Janus控制钩子。

4. Janus创新用例

我们在这节介绍几个有代表性的遥测、推理和控制应用示例，说明Janus的价值(关于评估见第7节)。

表3: Janus的监控(M)、控制(C)、推理(I)用例，LOC为代码行数。

灵活监控。 基于Janus实现的小程序可以帮助我们提取O-RAN KPM模型[21]中指定的KPI(表3 1-8行)，以及原始调度数据(9-10行)，而无需改变vRAN功能中的任何一行代码。这表明Janus有能力动态建立新的或者改变现有O-RAN服务模型[31, 47]，无需经历漫长的标准化过程。例如，我们能够收集下行链路总物理资源块(PRB, Physical Resource Block)使用量KPI[13]，方法是利用表1的Janus FAPI钩子，并获取示例1中提到的nfapi_dl_config_request_pdu_t结构，其中包含每个用户调度决策分配的PRB数量。该结构被保存在Janus map中，取0.5ms内的平均值，并发送给Janus数据采集器。

低成本实时推理。 为了证明Janus如何克服第2.2节所述的数据量限制，我们开发了一个小程序集，通过将正在运行的5G RU转化为频谱传感器来检测外部无线干扰。小程序集由两个通过map进行协调的小程序组成，第一个检测没有5G传输时的空闲时段(挂在表1的FAPI钩子上)，第二个在空闲时段对干扰进行采样(挂在表1的IQ采样钩子上)。Janus的灵活性使我们能够根据需要指定参数调整干扰检测器的保真度和开销，比如基于哪些天线端口和symbol收集IQ样本，以什么样的频率(例如每个接收槽或每10ms)和粒度(例如原始IQ样本与每个资源块平均能量比值)收集。正如第7.2节所示，在vRAN中内联执行这一推理，而不是将原始IQ样本导出到RIC，能够将遥测带宽减少40倍。类似方法可以用来实现其他需要不同格式的无线电信道遥测数据的推理用例(例如，无线定位[62，86]和信道估算[37，38])。

此外，许多RAN控制回路需要实时参数预测，预测的及时性对网络性能有直接影响[28, 29, 40, 46, 66, 83, 89, 98, 100]。由于O-RAN RIC的延迟，xApp只能提供10几毫秒前的预测，不支持实时推理[23, 77]。通过Janus的小程序，可以在预测延迟低于10毫秒的情况下在vRAN功能内进行推理，我们通过构建表3第12-14行所列的推理模型来验证这一功能。第一个是用于预测用户信号质量的ARIMA时间序列模型，采用的方法类似于[33]。第二个是用于预测信号处理任务运行时间的量化决策树，采用的是[45]的方法。更复杂的模型，如[98]中的随机森林，在Janus C代码中更难实现，会导致大量字节码指令(> 100K)，使验证过程变得缓慢(> 20分钟)。为了克服这一问题，我们以map(JANUS_MAP_TYPE_ML_MODEL)的形式增强了对随机森林的支持，预先训练好的序列化随机森林模型可以被传递给Janus，并在小程序加载过程中链接到这个map，Janus解析序列化的模型并验证，然后在内存中重建这一模型，小程序可以通过辅助函数janus_model_predict()访问该模型进行推理。这种方法类似于Tensorflow等框架为微控制器提供的序列化功能[91]，并可以扩展到其他常用的ML模型(例如LSTM)。关于这个过程的更多细节，请见附录A.4。

实时控制。 许多企业应用需要网络切片以保证更严格的服务QoS[39, 44]。现有O-RAN服务模型允许预先定义一组切片调度策略[34, 60, 85]，以10秒粒度控制调度。使用Janus，我们实现了任意调度策略的实时分片，粒度为0.5-10ms，这在今天的RIC模型中是不可能的。依靠表2中Janus的片间无线资源调度钩子，由MAC调度器在每个调度周期开始时调用，该钩子接收基站的调度状态作为上下文(设备数量、所属切片、缓冲区大小、信号质量等)。通过这个钩子，我们用Janus小程序实现了三个网络切片调度器，如表3所列(第15-17行)，这三个调度器都使用表2的allocate_slice_rbs()执行器将调度决策应用于基站。

5. 系统设计挑战

5.1. 运行时控制

现有eBPF验证器可以确认内存安全和终止条件，如果小程序不能有效终止(例如由于无限循环)，将被拒绝执行。然而，正如第2.3节所提到的，当前无法对小程序在最差情况下的执行时间给予足够严格的保证。

5.1.1. 运行时间估算的挑战

估算最差情况下的执行时间的简单方法是分析小程序可以执行的最大eBPF指令数，这一信息可以通过对小程序最长路径的静态分析推断出来，并同时考虑有界循环的情况。然而，将指令数转化为预期运行时间是非常困难的，因为这取决于许多因素，包括CPU时钟、内存和缓存、eBPF指令向JIT代码的转化等[36, 94]。另一个挑战是辅助函数，其执行时间在不同函数和不同参数值之间可能有很大差异。

为了说明这些挑战，请看示例2和3中的小程序。两者都执行了一个1000次的迭代循环，其中第一个循环调用了一个辅助函数。验证器显示，与示例2相比，示例3的小程序需要多执行64条指令。然而，对于参考硬件Xeon Platinum 8168 CPU @ 2.7GHz，我们看到示例2小程序运行开销更大(运行时间为4.3𝜇s，示例3为2.4𝜇s)。这是因为与小程序的乘法和加法指令相比，辅助函数产生了更大的开销，表明每个小程序的最大指令数并不能很好的表示最大运行时间。

1 for (int k = 0; k < 1000; k ++) {
2   index = 0;
3   c = janus_map_lookup_elem (& counter , & index ) ;
4   s . counter = k + 10;
5 }

示例2: 带辅助函数的循环(平均运行时间4.3𝜇s)

1 for ( volatile int k = 0; k < 1000; k ++) {
2   counter += i ;
3   counter2 = counter * i ;
4   s . counter += counter2 ;
5   i ++;
6 }

示例3: 没有辅助函数的循环(平均运行时间2.4𝜇s)

5.1.2. 通过字节码动态增强运行时

为了应对这些挑战，Janus在eBPF字节码中注入指令，在运行时测量小程序的执行时间，并在超过阈值时进行抢占。如图3所示，一个辅助函数(mark_init_time())被添加到小程序头部，将当前时间(基于Inte rdtsc指令)存储在线程局部变量中。补丁程序在选定位置引入检查点，调用辅助函数(runtime_limit_exceeded()，图3第18行)，检查自mark_init_time()以来小程序的运行时间，并将其与阈值进行比较。如果超过了阈值，小程序将被迫退出并返回错误(图3第19-21行)。运行时阈值是在加载小程序集时为每个小程序指定的(见附录A.1和示例6)。最后，由于注入了指令，补丁程序需要更新所有跳转偏移量。这种方法使我们能够验证修补后的字节码的安全性，确保补丁程序所做的任何修改都不会影响小程序集的安全性。

时间检查是作为辅助函数实现的，调用了Intel rdtsc指令，而这在eBPF指令集中没有对应的指令。辅助函数的调用使eBPF寄存器r0-r5失效，这些寄存器可能保存了小程序正常执行流程的状态。为了确保可验证性，Janus存储并重新加载这些寄存器的值(图3第17和22行)，这要求小程序在其内存栈中至少有48字节的存储空间(eBPF函数有512字节的栈)。我们认为这是一个合理的要求，小程序总是可以使用map来存储更多状态。

注入点。 打补丁的关键问题是在哪里注入检查点。我们想限制两个连续检查点之间的最大指令数𝑁，以减少运行时抖动的影响(如示例2-3所示)。然而，每个检查点都会产生开销(调用辅助函数runtime_limit_exceeded()，保存和恢复寄存器，等等)。所有这些加起来，对于参考硬件Xeon Platinum 8168 CPU @ 2.7GHz来说，每个检查点开销超过24ns。为了保持低开销，Janus使用算法1分散检查点。Janus一开始在调用被供应商标记为长效辅助函数之后添加检查点，因为如果这些函数被经常调用，可能会不安全(第2行)。接下来使用验证器的静态分析来穷举(从最短到最长)从小程序的第一条指令到最后一条指令的所有简单路径，以及所有循环。对于每个路径，Janus每隔𝑁条指令添加一个检查点(第11-14行)。该算法考虑到了在遍历其他路径时已经添加的检查点。如果发现一个检查点，则以现有检查点为起点，对重置指令计数(第8-9行)。即使距离小于𝑁，每个周期也至少增加一个检查点(第17-19行)，从而保证每隔𝑁条指令总有一个检查点。

算法1: 检查点注入决策

数据: 𝑁 > 0，小程序指令列表𝐹，其中调用了长期辅助函数，从第一条指令到最后一条指令的所有简单小程序路径的有序列表𝑃和循环(长度增加)
结果: 检查点指令位置列表𝐶
 1 𝐶 ← { };
 2 foreach instruction 𝑓 in 𝐹 do 𝐶 ← 𝐶 + 𝑓;
 3 foreach 𝑝 in 𝑃 do
 4     ins ← 0;
 5     fins ← first instruction of 𝑝;
 6     foreach instruction 𝑖 in 𝑝 do
 7         ins ← ins + 1;
 8         if 𝑖 has already checkpoint then
 9             ins ← 0;
10         else
11             if ins = 𝑁 then
12                 𝐶 ← 𝐶 + 𝑖;
13                 ins ← 0;
14             end
15         end
16     end
17     if 𝑝 is cycle and no checkpoint was added then
18         𝐶 ← 𝐶 + fins;
19     end
20 end

为了进行更精细的控制，Janus允许供应商使用宏(RUNTIME_LIMIT_EXCEEDED)在长效辅助函数中设置检查点，执行与图3补丁类似的操作。例如，在第4节中讨论的随机森林模型的情况下，我们在模型的每个估算器(树)的推断后添加这样的检查。

即使是几个检查点，开销也会变得很大(例如在有紧密循环的小程序中)。为了进一步减少开销，补丁代码以抽样的频率进行检查(在𝑀个检查点中抽一个)。补丁程序在eBPF堆栈中增加了一个32位计数器，只有当这个计数器达到某个值时才进行检查(图3的第15行，右图)，否则执行流程将跳回原始字节码指令，从而保证每𝑀×𝑁条指令至少进行一次检查。

抢占式控制循环。 每个控制钩子必须提供默认控制决策，如果加载的控制小程序被抢占而没有做出决策，被抢占的小程序会返回CONTROL_FAILED错误码，并执行RAN供应商提供的默认动作(如示例4所示)。例如，表2的切片间无线资源调度钩子的供应商默认动作可能是在切片间平均分配无线资源块。同样，对于链路适配钩子，可以设置一个强大的调制和编码方案，无论接入UE的信号条件如何，都能提供低错误率。最后，Janus提供了一个辅助函数check_preemption()，允许小程序检查在上一次运行中是否被抢占，如果小程序保存了错误状态，可以进行重新设置。

1 decision = hook_custom_janus_control_operation ( ctx ) ;
2 if ( decision != CONTROL_SUCCESS )
3   decision = call_default_control_operation ( ctx ) ;

示例4: Janus自定义控制钩子伪代码

5.2. 灵活可验证的输出格式

Janus可以定义任意输出格式，在运行时与小程序一起加载，通过网络将输出数据传输到集中式控制器(更多细节见附录A.2)。Janus基于protobufs实现数据序列化。但是支持任意格式不利于安全性。具体来说，Janus必须处理两个挑战。

1 message Example {
2   repeated int32 element = 1;
3 }
4 Example.element max_count:16

示例5: 带有可变大小字段(最多16个元素)的输出格式定义示例。

首先是确保小程序不能生成任意大的可序列化消息，因为这可能不利于内存安全。Protobuf消息由开发者定义，可以包含可变大小的字段(如重复字段或字符串)。Janus验证器在编译时不知道消息的实际大小，因此不能静态验证。为了克服这个问题，Janus要求在消息规范中对所有具有可变大小字段的protobuf定义设定一个上限，如示例5所示。Janus根据消息的最大大小为小程序C代码分配内存，并向验证器报告(在示例中，16 × sizeof(int32) + sizeof(int16) = 66B)，代价是内存消耗略有增加(在vRAN系统中不是瓶颈)。

其次是确保格式不正确的消息不会导致内存问题。考虑这种情况: 程序员分配了一个30B的内存块，作为Example的一个实例，设置element数量为16，并调用protobuf编码器。由于内存块对于16个element来说太小了，编码器将试图从分配的内存块之外的地方进行编码，这可能会导致segfault。为了确保内存访问安全，我们修改了验证器，以断言传递给protobuf编码器的内存总是等于可能的最大大小(在本例中为66B)。像上面这样的问题仍然会造成逻辑错误，会发送乱码，但不违反安全性。

6. 实现及集成

我们在这一节提供更多关于Janus组件的实现及其与真实vRAN集成的细节。

Janus设备(Janus device)。 Janus设备是用C语言实现的，可以动态链接到vRAN的库。它基于eBPF[59]的用户模式(usermode)实现，我们对其进行了扩展，以增加对Janus map、辅助函数和输出数据机制的支持。总的来说，我们不得不在基本实现的基础上增加了5000行代码。开发Janus设备代码时没有对vRAN函数的线程模型做任何假设(例如，调用钩子的线程的亲和性，线程调度策略和优先级等)。然而，如果知道这些信息，Janus可以对库实现进一步优化。我们已经非常小心确保Janus的快速路径(钩子可能在vRAN功能的时间敏感部分被调用)永远不会被阻塞或抢占。附录A.5中有更多关于实时优化的细节。

Janus控制器(Janus controller)。 Janus控制器是用Go(数据收集器)和Python(小程序加载器/补丁程序)编写的，有4000行代码。控制器通过基于TCP的protobuf API与Janus设备进行通信，也可以使用其他接口，如O-RAN RIC E2接口。对于小程序的验证，我们使用开源PREVAIL验证器[48]，并添加了1000行左右的扩展代码，以增加对Janus特定功能的支持(即辅助函数、map等)。最后，Janus补丁程序依靠pyelftools[1]和LLVM[8]来处理小程序的ELF文件内容。

Janus SDK。 Janus SDK用Python编写(1000行代码)，与Janus控制器共享部分代码库，通过LLVM将小程序编译成eBPF字节码，用eBPF[59]将字节码转换为x86 JIT代码，利用nanopb[6]为小程序编译protobuf输出消息格式。

vRAN集成。 将Janus集成到vRAN非常简单快捷。为了证明这一点，我们将Janus设备集成到两个vRAN软件实现中，以此作为概念验证。一个是CapGemini公司[35]开发的商业级5G vCU/vDU实现，基于英特尔FlexRAN PHY设计[57]。另一个是开源OAI[26]。两者都是用C/C++编写的，可以很简单的集成和链接Janus代码。对于Janus的集成，我们不得不在测试的每个vRAN功能中增加大约50行初始化代码，以及为引入的每个新钩子增加大约30行代码。

7. 性能评估

7.1. 实验设备

软硬件配置: 为了评估Janus性能，我们使用了一台配备48个物理核心(Intel Xeon Platinum 8168 @ 2.7GHz)和196GB内存的服务器，禁用超线程，运行Linux v5.15，应用了PREEMPT_RT实时补丁[82]，并对实时性能进行了优化，包括禁用P和C-States以及1GB hugepages。我们选择该配置是因为这是部署vRAN功能的典型配置[45, 58, 93]。

我们用了三套配置进行评估。第一套是端到端配置，由CapGemini[35]的商业级5G vRAN堆栈组成，集成了Janus设备(见第6节)，一个商业级5G核心网，一个100MHz的4×4富士康RU和5G OnePlus Nord智能手机(图4a)。vRAN基于x86，除了LDPC[55]，所有任务都在x86处理器上运行。使用这种配置，我们能够产生最大1Gbps的下行链路和45Mbps的上行链路流量。Janus基于这一配置收集IQ样本、FAPI和RLC数据(见表1)。在第二套配置中，我们用RRC/F1和FAPI数据的钩子，以及表2的切片间无线资源分配钩子对4G OAI进行检测。第三套也就是最后一套配置中，我们提供了一个假的Janus设备，这是个循环运行的单线程进程，调用连接到Janus钩子的小程序，我们基于这个配置进行微观测试(第7.3节)。

在所有配置中，Janus钩子被线程调用，这些线程的亲和性被设置为单核，并使用SCHED_FIFO策略(不可抢占)进行调度，其调度优先级为94。我们基于[76]的时间测量框架作为指导方针对运行时间进行测量。

vRAN小程序时间预算: 基于5G RAN设置确定可以分配多少时间给Janus小程序，而不会影响RAN性能。我们专注于vRAN DU的PHY层，因为其他层对时间要求都不太严格。PHY中数据包的传输和接收发生在固定传输时间间隔(TTI)内[45]。基于CapGemini vRAN设置，我们测量了15分钟内4x4 MIMO流量(1Gbps下行和45Mbps上行)完全饱和时，每个TTI的PHY运行时间。图4b显示了上行链路和下行链路的最大运行时间与所需CPU核数的关系，以及基于供应商给定配置的处理期限。差值(橙色)是Janus小程序的最大运行时间预算，从200𝜇s到600𝜇s不等。

虽然看起时间很长，但在实践中，由于某些原因，限制要小得多。一些小程序可能在每个TTI中被执行多次，例如第4节中的IQ样本处理在每个TTI中被调用14次(每个OFDM符号一次)。此外，多个小程序可以被加载到不同的钩子上，分享整体的时间预算。最后，更高要求的PHY配置，如大规模MIMO(目前无法评估)，将可能给Janus钩子留下更少的空闲CPU时间。我们的设计目标是假设小程序的运行时间预算可以低至20𝜇s。

7.2. 端到端系统评估

本节我们将展示Janus提取遥测数据的灵活性以及加载小程序集的安全性，来探索Janus在实际端到端部署中的行为和优势。对于安全部分，评估集中在第5.1节中介绍的运行时控制机制，Janus控制器基于eBPF验证器的静态分析的有效性在[48]中得到了广泛研究。同时，可以参考表3的参考文献，了解我们用于实现小程序的算法性能。

我们用第4节介绍的干扰检测作为小程序集分析示例。我们部署USRP软件定义无线电作为外部干扰，产生重复的干扰模式，包括5s的干扰和5s沉默。图5a显示了在真实5G下行链路传输过程中干扰的频谱图(细尖峰)。我们在一台OnePlus Nord 5G手机和5G vRAN之间用iperf测量下行链路，当干扰活跃时，看到有大约30%的丢包。测量的同时，我们加载Janus小程序进行干扰检测，细节在第4节中介绍。我们在控制器上实现了一个简单的干扰检测器，连续跟踪每个资源块的输入信号的平均值和方差，如果输入大于平均值加3倍标准差，则认为存在干扰。如图5b中所示，这种方法成功检测到了所有干扰期。

通过补丁防止RAN崩溃: 因此我们接下来会展示Janus如何有效处理那些虽然可以通过验证，但由于执行时间长而造成vRAN运行安全隐患的小程序。我们为同一个实验写了另一个逻辑正确但更低效的小程序，在一个临时结构里分配13KB内存，在for循环中逐字节对内存进行memset，然后在第二个for循环中逐个复制由钩子传递的IQ样本，并发送到控制器。

我们故意写的低效代码通过了验证，因为没有内存访问方面的安全问题，并且运行可以完结(有界循环)。然而，一旦这个小程序被加载到端到端vRAN，就会使vRAN崩溃。如图6a中的CDF所示，该小程序的运行时间中位数为51.4𝜇s，99.999百分位为52.2𝜇s。考虑到原始IQ样本钩子在每个TTI被调用14次(每个OFDM符号一次)，小程序的平均总运行时间为719.6𝜇s，大于vRAN的上行链路的600𝜇s时间预算(如图4b所示)。

然后，我们用Janus补丁程序修补小程序，并以5𝜇s的运行时阈值将其重新加载到vRAN。如图6a所示，小程序的修补版本很早就被抢占了，因此运行时中位数现在正好变成了5𝜇s, 99.999百分位数变成了5.04𝜇s。虽然修补后的小程序不再发送IQ样本(因为运行被抢占了)，但vRAN受到了保护，没有违反最后期限。

减少数据采集带宽: 在相同的干扰检测示例中，两个小程序协调其输出以降低总体数据采集带宽，如第4节所述。为了评估协调的好处，我们还用更加集中的方式(协调发生在RIC中)实现相同的场景。在这种方法中，两个小程序独立将所有调度数据和原始IQ样本发送到控制器(每个符号约13KB数据)，而不是在本地关联，并仅为空闲slot发送IQ样本。

我们基于这些配置测量了将输出数据发送到Janus收集器的吞吐量，以及两个小程序的运行时间，如图6b所示。在图的上半部分可以看到，原始干扰检测方法消耗了172Mbps的数据带宽，而基于vRAN内联预处理方法消耗的带宽只有4.5Mbps，几乎减少了40倍。尽管有额外的预处理工作，但与原始方法相比，预处理小程序的运行时间减少了3.5秒。原始方法在每次小程序发送原始IQ样本时需要执行一次memset和拷贝13KBs的内存，而预处理方法每次调用只需要拷贝约400B内容。当前O-RAN RIC为用例指定了服务模型，并由RAN供应商集成，因此不可能提供自定义预处理程序。

小程序运行时。 由于篇幅所限，我们没法详细讨论第4节中的每个场景，但图7提供了表3中17个小程序的中位数和尾部(99.999)运行时间，其中小程序名使用了表3中的缩写，并考虑了每个小程序在最差情况下的执行情况(即最大设备数量，最大带宽等)。报告的时间基于打过补丁的小程序，我们通过补丁确保检查点距离𝑁=60以及采样频率𝑀=10(关于参数选择细节，见第7.3节)。可以看到，所有小程序的运行时间都远低于7.1节中讨论的20𝜇s的时间预算(最差的小程序也小于8𝜇s)，其中要求最高的是切片调度器(SL1和SL3)、干扰检测(ID)和原始调度数据监测(RAW1和RAW2)。通过在5G vRAN部署中同时部署表3中标记为监测的所有小程序作为进一步演示，同时让网络流量达到饱和(1Gbps下行和45Mbps上行)，没有看到加载小程序后链路性能的任何影响。

7.3. 微基准测试

补丁的开销和敏感性。 我们通过研究表3中对计算要求最高的小程序(即RAW1、ID、SL1和SL3)，根据7.2节的运行时间结果，探索补丁过程的行为(5.1节)。由于篇幅所限，表3中其余小程序呈现出类似的修补行为，不做赘述。

首先，不同的检查点距离𝑁会引入不同的检查点数量，我们以此着手研究算法1。正如图8a中看到的，小程序的指令越多(列在每个小程序标签下)，引入的检查点就越多。此外，当我们增大𝑁时，检查点数量会下降。检查点数量几乎在所有情况下都略高于指令数除以𝑁，这意味着如果代码按顺序执行，有一些检查点的距离会小于𝑁。对字节码的检查显示，额外的检查点主要是在紧密循环(<𝑁条指令)中引入的，如果展开循环，就会形成一个超过𝑁个指令的代码块，这表明我们的补丁算法可以有效处理这种情况。

然后，我们研究了小程序在不同补丁距离(参数𝑁)和采样频率(参数𝑀)下的行为。图8b中的结果显示了未打补丁的版本与打了补丁但没有运行时间阈值的小程序运行时间比较。对于𝑁比较小的情况，运行时间开销会变得很高(比如对于ID来说超过了100%)，因为运行时间检查执行得非常频繁，而减少采样频率会有所帮助(如ID的𝑁=10和𝑀=30的情况所示)。另一方面，较大的𝑁值和较小的采样频率会体现为更少的运行时间检查，导致抢占式小程序的平均和尾部延迟更高，如图8c所示(运行时间阈值设置为400ns)。对于𝑁=60和𝑀=30，RAW1和ID的尾部运行时间几乎比运行时间阈值多100%。基于对表3中所有小程序的评估，我们发现𝑁=60和𝑀=10在运行时间开销和抢占延迟之间取得了最佳平衡。

最后，我们将算法1的检查点方法与[95, 96]中提出的另一种方法进行比较，即在被修补代码的控制流图的每个基本块上引入检查点。对于基本块方法，我们使用𝑀=30的采样频率，在𝑁=60和𝑀=10的情况下，产生与Janus修补器相似的抢占尾部延迟结果。如图8d所示，与Janus修补器相比，基本块方法在大多数情况下的运行时间开销(99.999尾部运行时间)会更高(例如，SL1小程序的开销高出2倍以上)。开销增加的原因是，在许多情况下，基本块可能非常小(2-3条指令)，如果基本块经常被访问(热代码)，那么即使使用了基于采样率的检查，检查点增加的指令也会使其运行时间增加一倍以上。Janus采取的方法更加规范，允许RAN运营商或供应商选择两个检查点之间的确切指令数量。

Janus钩子开销。 为了测量空闲Janus钩子的开销，我们使用假的Janus设备，并测量在没有加载任何小程序的情况下，在2百万迭代中调用一个或10个Janus钩子的耗时。表4列出了中位数、99.9和99.999百分位数的结果。可以看到，在单个钩子调用的情况下，所有情况下的开销都可以忽略不计(<1ns)。在10个钩子的情况下，99.9和99.999百分位数的差异上升到10ns(每个钩子调用1ns∼)。结论是，在vRAN代码中增加钩子对其性能的影响可以忽略不计。

表4: Janus空钩子的中位数和尾部运行时间。

数据输出开销。 接下来评估将数据复制到输出消息并将其放入输出map的开销(不包括输出线程和protobuf序列化开销)。我们以protobuf消息SizeMessage1为基准，定义为protobuf库[79]基准测试套件的一部分。这个消息总共包含62个字段，既有基础字段(如int32、int64、bool)，也有可变大小字段(字符串和可重复字段)。我们写了一个小程序，用随机内容和不同的消息大小来填充SizeMessage1，并将其发送出去。正如图9a所示，对于小数据包(<2KB)，中位数和尾部运行时间都保持在1𝜇s以下，执行时间随着数据包大小逐渐增加，但始终保持在2𝜇s以下，最高达到9KB的大数据包。实践中，我们为第4节中的用例编写的小程序都不需要发送超过2KB的监控数据，这意味着大多数实际场景的输出开销非常低。

网络开销。 最后，我们测量输出线程的开销，该线程将protobuf消息序列化，并通过网络将其发送给控制器。我们基于之前实验相同的配置，并测量最大可实现的数据包发送率，结果用图9b中的蓝线表示。对于小数据包(<500𝐵)，Janus可以在单个输出线程中序列化并发送超过80kpps，在发送9KB的大数据包时，速度下降到20kpps。根据遥测小程序(第4节)，即使在最苛刻的情况下，单个cell的数据包数量和大小也落在图9b的橙色区域内。这意味着单个Janus设备可以处理多达4个cell(浅蓝色和橙色区域)的苛刻用例，而对于轻量级监测，则可以处理超过一倍的cell。目前，主要瓶颈是输出信息的序列化，可以从图9b的橙色线看出，因为即使我们丢弃数据包，也只看到输出速率增加了25%，这可以通过基于bypass kernel(例如DPDK)的解决方案取代基于套接字的UDP操作来进一步优化。

8. 讨论及相关工作

向vRAN推送任意代码 -- [43, 73]中的工作通过在运行时在vRAN中加载任意代码，论证了实时RAN可编程性的需求。虽然这些工作在概念上与Janus相似，但并没有提出实现这种功能的安全方法，并承认安全问题是在真实部署中引入相关工作的障碍。他们只显示了在低端配置上的操作(高达20MHz的SISO，吞吐量比我们为Janus展示的少10倍)，并且没有提供对高吞吐量数据流(如IQ样本)的访问。

检查点补丁代码 -- 文献中研究了通过编译器辅助添加检查点，并通过定期保存软件状态来提高容错性的方法(例如，在间歇性能源系统中)[67, 68, 80, 99, 101]。在这类系统中，检查点的选择通常是以不影响可恢复性的情况下最大限度减少能耗为目标，这导致了与Janus的抢占目标相比不同的设计选择。与Janus更接近的是，[95, 96]中的工作侧重于添加检查点，以断言实时系统在最差情况下的执行是否已经超时。与Janus相反，这种检查需要硬件辅助，而且检查点被添加到正在运行的程序的每个基本块中，正如第7.3节所示，与Janus修补器相比，它的开销更大。

RAN数据收集 -- vRAN领域的一些工作提供了数据收集的解决方案，从API规范(例如O-RAN RIC E2服务模型[24, 85]和FlexRAN API[43])到精心设计的日志系统(例如OAI T-tracer[7]，SCOPE数据收集模块[30])。然而，这些解决方案缺乏灵活性，无法根据应用需要来调整收集数据的类型、数量和频率，而这正是Janus的主要设计目标之一。对于eBPF空间的数据收集解决方案也可以得出类似的结论，它们要么提供一套固定指标(如Hubble[5])，要么数据只能以特定格式导出(如ebpf_exporter[4]中的计数器和直方图)。

通过Janus map支持复杂ML模型 -- 如第4节所述，在Janus C代码中内联开发大型ML模型(例如，随机森林)是具有挑战性的工作，主要由于生成的字节码大小及其对验证的影响。我们相信，考虑到RAN的大量用例都依赖于相同模型(如随机森林、LSTM和RNN[18, 40, 54, 66, 84, 89, 97, 98])，我们提出的基于map的方法以序列化格式加载ML模型并通过辅助函数进行推理是非常强大的。因此，我们正计划扩展这种方法，以支持随机森林以外的其他广泛使用的ML模型。

9. 结论

我们在本文中提出了Janus，一个完全可编程、安全的5G RAN监测和控制框架，允许运营商实时加载具有自定义数据模型的自定义小程序，大大增加了现有O-RAN RIC提供的灵活性。我们通过构建和评估4个不同类别的17个应用(大多数是O-RAN RIC无法实现的)来证明这种灵活性。Janus使用静态验证和小程序执行预估来实现安全性，其模块化的设计使得很容易添加到现有vRAN产品中。我们希望Janus最终会被O-RAN社区采用，以帮助加速Open RAN的创新。

参考文献

[1] 2021. pyelftools. https://github.com/eliben/pyelftools.

[2] 2022. Awesome eBPF. https://github.com/zoidbergwill/awesomeebpf.

[3] 2022. eBPF. https://ebpf.io/.

[4] 2022. ebpf_exporter. https://github.com/cloudflare/ebpf_exporter.

[5] 2022. Hubble exported metrics. https://docs.cilium.io/en/stable/operations/metrics/#hubble-exported-metrics.

[6] 2022. nanopb. https://github.com/nanopb/nanopb.

[7] 2022. OAI T Tracer. https://gitlab.eurecom.fr/oai/openairinterface5g/-/wikis/T.

[8] 2022. The LLVM compiler infrastructure. https://llvm.org/.

[9] O-RAN Working Group 3. 2021. Use Cases and Requirements. ORAN.WG3.UCR-v01.00 (2021).

[10] 3GPP. 2018. 3GPP TS 38.410: NG general aspects and principles. (2018).

[11] 3GPP. 2018. 3GPP TS 38.463: E1 Application protocol (E1AP). (2018).

[12] 3GPP. 2019. 3GPP TS 38.470: F1 general aspects and principles. (2019).

[13] 3GPP. 2020. 3GPP TS 28.552: Management and orchestration: 5G performance measurements. (2020).

[14] 3GPP. 2020. 3GPP TS 32.425: Performance Management (PM); Performance measurements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN). (2020).

[15] 3GPP. 2020. 3GPP TS 38.322: Radio Link Control (RLC) protocol specification. (2020).

[16] 3GPP. 2020. 3GPP TS 38.331: Radio Resource Control (RRC) protocol specification . (2020).

[17] 3GPP. 2020. 3GPP TS 38.420: Xn general aspects and principles. (2020).

[18] Javed Akhtar, Krunal Saija, Narayanan Ravi, Shekar Nethi, and Saptarshi Chaudhuri. 2021. Machine Learning-based Prediction of PMI Report for DL-Precoding in 5G-NR System. In 2021 IEEE 4th 5G World Forum (5GWF). IEEE, 105–110.

[19] ORAN Alliance. 2019. O-RAN WhitePaper-Building the Next Generation RAN. O-RAN Alliance, Tech. Rep., Oct (2019).

[20] ORAN Alliance. 2020. O-RAN use cases and deployment scenarios. White Paper, Feb (2020).

[21] ORAN Alliance. 2020. O-RAN Working Group 3: Near-Real-time RAN Intelligent Controller-E2 Service Model (E2SM). ORAN-WG3. E2SM-KPM-v01. 00.00 (2020).

[22] ORAN Alliance. 2021. O-RAN Fronthaul Control User and Synchronization Plane Specification v7.0.

[23] ORAN Alliance. 2021. O-RAN Working Group 2: “O-RAN AI/ML workflow description and requirements 1.03. O-RAN.WG2.AIMLv01.03 Technical Specification (2021).

[24] O-RAN Alliance. 2021. O-RAN E2 Application Protocol (E2AP) v2.0. ORAN-WG3.E2AP-KPM-v02.00 (2021).

[25] O-RAN Alliance. 2021. O-RAN Minimum Viable Plan and Acceleration towards Commercialization. White Paper, June (2021).

[26] OpenAir Software Alliance. 2022. Open Air Interface Project. https://openairinterface.org/about-us/.

[27] Bharath Balasubramanian, E Scott Daniels, Matti Hiltunen, Rittwik Jana, Kaustubh Joshi, Rajarajan Sivaraj, Tuyen X Tran, and Chengwei Wang. 2021. RIC: A RAN intelligent controller platform for AIenabled cellular networks. IEEE Internet Computing 25, 2 (2021), 7–17.

[28] Andson Balieiro, Kelvin Dias, and Paulo Guarda. 2021. A Machine Learning Approach for CQI Feedback Delay in 5G and Beyond 5G Networks. In 2021 30th Wireless and Optical Communications Conference (WOCC). IEEE, 26–30.

[29] Gilberto Berardinelli, Saeed R Khosravirad, Klaus I Pedersen, Frank Frederiksen, and Preben Mogensen. 2016. Enabling early HARQ feedback in 5G networks. In 2016 IEEE 83rd Vehicular Technology Conference (VTC Spring). IEEE, 1–5.

[30] Leonardo Bonati, Salvatore D’Oro, Stefano Basagni, and Tommaso Melodia. 2021. SCOPE: an open and softwarized prototyping platform for NextG systems. In Proceedings of the 19th Annual International Conference on Mobile Systems, Applications, and Services. 415–426.

[31] Leonardo Bonati, Salvatore D’Oro, Michele Polese, Stefano Basagni, and Tommaso Melodia. 2021. Intelligence and learning in O-RAN for data-driven NextG cellular networks. IEEE Communications Magazine 59, 10 (2021), 21–27.

[32] Gabriel Brown and HEAVY READING. 2018. New Transport Network Architectures for 5G RAN. White Paper. Available online: https://www.fujitsu. com/us/Images/New-Transport-Network-Architectures-for-5GRAN. pdf (accessed on 29 June 2021) (2018).

[33] Nicola Bui and Joerg Widmer. 2018. Data-driven evaluation of anticipatory networking in LTE networks. IEEE Transactions on Mobile Computing 17, 10 (2018), 2252–2265.

[34] Cambridge Consultants. 2022. Wireless breakthrough for the Ocado Smart Platform. https://www.cambridgeconsultants.com/case-studies/wireless-breakthrough-ocado-smart-platform.

[35] CapGemini Engineering. 2022. 5G gNodeB. https://capgeminiengineering.com/nl/en/services/next-core/wireless-frameworks/.

[36] Francisco J Cazorla, Leonidas Kosmidis, Enrico Mezzetti, Carles Hernandez, Jaume Abella, and Tullio Vardanega. 2019. Probabilistic worst-case timing analysis: Taxonomy and comprehensive survey. ACM Computing Surveys (CSUR) 52, 1 (2019), 1–35.

[37] Cellwize and Intel. 2022. Cellwize Announces Collaboration to Accelerate Deployment of 5G vRAN Networks With AI. https://www.sdxcentral.com/articles/press-release/cellwizeannounces-collaboration-to-accelerate-deployment-of-5g-vrannetworks-with-ai/2021/06/.

[38] Cohere Technologies. 2022. With Vodafone and Partners, VMWare demonstrates how to accelerate innovation in the RAN. https://www.cohere-tech.com/press-releases/with-vodafone-and-partnersvmware-demonstrates-how-to-accelerate-innovation-in-the-ran.

[39] Salah Eddine Elayoubi, Sana Ben Jemaa, Zwi Altman, and Ana Galindo-Serrano. 2019. 5G RAN slicing for verticals: Enablers and challenges. IEEE Communications Magazine 57, 1 (2019), 28–34.

[40] Capgemini Engineering. 2021. Intelligent 5G L2 MAC Scheduler. White Paper, Feb (2021).

[41] Small Cell Forum. 2021. 5G FAPI: PHY API Specification.

[42] Xenofon Foukas, Mahesh K Marina, and Kimon Kontovasilis. 2019. Iris: Deep reinforcement learning driven shared spectrum access architecture for indoor neutral-host small cells. IEEE Journal on Selected Areas in Communications 37, 8 (2019), 1820–1837.

[43] Xenofon Foukas, Navid Nikaein, Mohamed M Kassem, Mahesh K Marina, and Kimon Kontovasilis. 2016. FlexRAN: A flexible and programmable platform for software-defined radio access networks. In Proceedings of the 12th International on Conference on emerging Networking EXperiments and Technologies. 427–441.

[44] Xenofon Foukas, Georgios Patounas, Ahmed Elmokashfi, and Mahesh K Marina. 2017. Network slicing in 5G: Survey and challenges. IEEE communications magazine 55, 5 (2017), 94–100.

[45] Xenofon Foukas and Bozidar Radunovic. 2021. Concordia: teaching the 5G vRAN to share compute. In Proceedings of the 2021 ACM SIGCOMM 2021 Conference. 580–596.

[46] Gines Garcia-Aviles, Andres Garcia-Saavedra, Marco Gramaglia, Xavier Costa-Perez, Pablo Serrano, and Albert Banchs. 2021. Nuberu: Reliable RAN virtualization in shared platforms. In Proceedings of the 27th Annual International Conference on Mobile Computing and Networking. 749–761.

[47] Andres Garcia-Saavedra and Xavier Costa-Perez. 2021. O-RAN: Disrupting the virtualized RAN ecosystem. IEEE Communications Standards Magazine (2021).

[48] Elazar Gershuni, Nadav Amit, Arie Gurfinkel, Nina Narodytska, Jorge A Navas, Noam Rinetzky, Leonid Ryzhyk, and Mooly Sagiv. 2019. Simple and precise static analysis of untrusted linux kernel extensions. In Proceedings of the 40th ACM SIGPLAN Conference on Programming Language Design and Implementation. 1069–1084.

[49] David Ginthör, René Guillaume, Maximilian Schüngel, and Hans D Schotten. 2021. 5G RAN slicing for deterministic traffic. In 2021 IEEE Wireless Communications and Networking Conference (WCNC). IEEE, 1–6.

[50] Google. 2022. Sandbox2. https://developers.google.com/codesandboxing/sandbox2.

[51] Google. 2022. Sandboxed API. https://developers.google.com/codesandboxing/sandboxed-api.

[52] Tao Guo and Alberto Suárez. 2019. Enabling 5G RAN slicing with EDF slice scheduling. IEEE Transactions on Vehicular Technology 68, 3 (2019), 2865–2877.

[53] Andreas Haas, Andreas Rossberg, Derek L Schuff, Ben L Titzer, Michael Holman, Dan Gohman, Luke Wagner, Alon Zakai, and JF Bastien. 2017. Bringing the web up to speed with WebAssembly. In Proceedings of the 38th ACM SIGPLAN Conference on Programming Language Design and Implementation. 185–200.

[54] Sahar Imtiaz, Georgios P Koudouridis, Hadi Ghauch, and James Gross. 2018. Random forests for resource allocation in 5G cloud radio access networks based on position information. EURASIP Journal on Wireless Communications and Networking 2018, 1 (2018), 1–16.

[55] Intel. 2020. Unleash the Speed of 4G and 5G Virtualized Radio Access Networks (vRAN). Product Brief, Intel vRAN Dedicated Accelerator ACC100 (2020).

[56] Intel. 2020. Virtual RAN (vRAN) with Hardware Acceleration. White Paper, Jan (2020).

[57] Intel. 2022. FlexRAN Reference Architecture for Wireless Access. https://www.intel.com/content/www/us/en/developer/topictechnology/edge-5g/tools/flexran.html.

[58] Intel. 2022. Smart Edge Open Radio Access Network. https://smart-edge-open.github.io/ido-specs/doc/referencearchitectures/ran/smartedge-open_ran/.

[59] iovisor. 2022. Userspace eBPF VM. https://github.com/iovisor/ubpf.

[60] David Johnson, Dustin Maas, and Jacobus Van Der Merwe. 2022. NexRAN: Closed-loop RAN slicing in POWDER-A top-to-bottom open-source open-RAN use case. In Proceedings of the 15th ACM Workshop on Wireless Network Testbeds, Experimental evaluation & CHaracterization. 17–23.

[61] Ravi Kokku, Rajesh Mahindra, Honghai Zhang, and Sampath Rangarajan. 2011. NVS: A substrate for virtualizing wireless resources in cellular networks. IEEE/ACM transactions on networking 20, 5 (2011), 1333–1346.

[62] Manikanta Kotaru, Kiran Joshi, Dinesh Bharadia, and Sachin Katti. 2015. Spotfi: Decimeter level localization using wifi. In Proceedings of the 2015 ACM Conference on Special Interest Group on Data Communication. 269–282.

[63] Merima Kulin, Tarik Kazaz, Ingrid Moerman, and Eli De Poorter. 2018. End-to-end learning from spectrum data: A deep learning approach for wireless signal identification in spectrum monitoring applications. IEEE Access 6 (2018), 18484–18501.

[64] Daniel Lehmann, Johannes Kinder, and Michael Pradel. 2020. Everything Old is New Again: Binary Security of {WebAssembly}. In 29th USENIX Security Symposium (USENIX Security 20). 217–234.

[65] liburcu. 2022. Userspace RCU. https://liburcu.org/.

[66] Changqing Luo, Jinlong Ji, Qianlong Wang, Xuhui Chen, and Pan Li. 2018. Channel state information prediction for 5G wireless communications: A deep learning approach. IEEE Transactions on Network Science and Engineering 7, 1 (2018), 227–236.

[67] Kiwan Maeng, Alexei Colin, and Brandon Lucia. 2017. Alpaca: Intermittent execution without checkpoints. Proceedings of the ACM on Programming Languages 1, OOPSLA (2017), 1–30.

[68] Kiwan Maeng and Brandon Lucia. 2018. Adaptive dynamic checkpointing for safe efficient intermittent computing. In 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 18). 129–144.

[69] Paul E McKenney, Silas Boyd-Wickizer, and Jonathan Walpole. 2013. RCU usage in the linux kernel: One decade later. Technical report (2013).

[70] Paul E McKenney and Jonathan Walpole. 2007. What is RCU, fundamentally? Linux Weekly News (LWN. net) (2007).

[71] Mehrtash Mehrabi, Mostafa Mohammadkarimi, Masoud Ardakani, and Yindi Jing. 2019. Decision Directed Channel Estimation Based on Deep Neural Network 𝑘-Step Predictor for MIMO Communications in 5G. IEEE Journal on Selected Areas in Communications 37, 11 (2019), 2443–2456.

[72] Mustafa Mohsin, Jordi Mongay Batalla, Evangelos Pallis, George Mastorakis, Evangelos K Markakis, and Constandinos X Mavromoustakis. 2021. On Analyzing Beamforming Implementation in O-RAN 5G. Electronics 10, 17 (2021), 2162.

[73] Navid Nikaein, Chia-Yu Chang, and Konstantinos Alexandris. 2018. Mosaic5G: Agile and flexible service platforms for 5G research. ACM SIGCOMM Computer Communication Review 48, 3 (2018), 29–34.

[74] Daisuke Nojima, Yuki Katsumata, Takuya Shimojo, Yoshifumi Morihiro, Takahiro Asai, Akira Yamada, and Shigeru Iwashina. 2018. Resource isolation in RAN part while utilizing ordinary scheduling algorithm for network slicing. In 2018 IEEE 87th Vehicular Technology Conference (VTC Spring). IEEE, 1–5.

[75] O-RAN SC projects . 2022. RAN Intelligent Controller Applications. https://docs.o-ran-sc.org/en/latest/projects.html#ranintelligent-controller-applications-ricapp.

[76] Gabriele Paoloni. 2010. How to benchmark code execution times on Intel IA-32 and IA-64 instruction set architectures. Intel Corporation 123 (2010), 170.

[77] Michele Polese, Leonardo Bonati, Salvatore D’Oro, Stefano Basagni, and Tommaso Melodia. 2022. Understanding O-RAN: Architecture, Interfaces, Algorithms, Security, and Research Challenges. arXiv preprint arXiv:2202.01032 (2022).

[78] Michele Polese, Rittwik Jana, Velin Kounev, Ke Zhang, Supratim Deb, and Michele Zorzi. 2020. Machine learning at the edge: A datadriven architecture with applications to 5G cellular networks. IEEE Transactions on Mobile Computing 20, 12 (2020), 3367–3382.

[79] Protocol Buffers. 2022. Protobuf benchmark proto file. https://github.com/protocolbuffers/protobuf/blob/fb77cc9d9f066a8ce4f12e8d5f76188d48101444/benchmarks/google_size.proto.

[80] Benjamin Ransford, Jacob Sorber, and Kevin Fu. 2011. Mementos: System support for long-running computation on RFID-scale devices. In Proceedings of the sixteenth international conference on Architectural support for programming languages and operating systems. 159–170.

[81] Raymond Knopp. 2022. OAI Layer 2 Protocol Stack. https://www.openairinterface.org/docs/workshop/1stOAINorthAmericaWorkshop/Training/KNOPP-OAI-L2.pdf.

[82] Rohde & Schwarz. 2022. PREEMPT_RT patch versions. https://www.rohde-schwarz.com/uk/solutions/aerospace-defensesecurity/security/spectrum-monitoring/efficient-interferencehunting/huntinginterferences_91389.html.

[83] Peter Rost and Athul Prasad. 2014. Opportunistic hybrid ARQ—Enabler of centralized-RAN over nonideal backhaul. IEEE Wireless Communications Letters 3, 5 (2014), 481–484.

[84] Krunal Saija, Shekar Nethi, Saptarshi Chaudhuri, and RM Karthik. 2019. A machine learning approach for SNR prediction in 5G systems. In 2019 IEEE International Conference on Advanced Networks and Telecommunications Systems (ANTS). IEEE, 1–6.

[85] Robert Schmidt, Mikel Irazabal, and Navid Nikaein. 2021. FlexRIC: an SDK for next-generation SD-RANs. In Proceedings of the 17th International Conference on emerging Networking EXperiments and Technologies. 411–425.

[86] Souvik Sen, Božidar Radunovic, Romit Roy Choudhury, and Tom Minka. 2012. You are facing the Mona Lisa: Spot localization using PHY layer information. In Proceedings of the 10th international conference on Mobile systems, applications, and services. 183–196.

[87] Weisen Shi, Junling Li, Peng Yang, Qiang Ye, Weihua Zhuang, Xuemin Shen, and Xu Li. 2021. Two-level soft RAN slicing for customized services in 5G-and-beyond wireless communications. IEEE Transactions on Industrial Informatics 18, 6 (2021), 4169–4179.

[88] Small Cell Forum. 2022. 5G FAPI: PHY API Specification. http://scf.io/en/documents/222_5G_FAPI_PHY_API_Specification.php.

[89] Nils Strodthoff, Barış Göktepe, Thomas Schierl, Cornelius Hellge, and Wojciech Samek. 2019. Enhanced machine learning techniques for early HARQ feedback prediction in 5G. IEEE Journal on Selected Areas in Communications 37, 11 (2019), 2573–2587.

[90] Telefonica. 2021. Telefonica views on the design, architecture, and technology of 4G/5G Open RAN networks. White Paper, Jan (2021).

[91] TensorFlow. 2022. TensorFlow Lite for Microcontrollers. https://www.tensorflow.org/lite/microcontrollers.

[92] Marcos AM Vieira, Matheus S Castanho, Racyus DG Pacífico, Elerson RS Santos, Eduardo PM Câmara Júnior, and Luiz FM Vieira. 2020. Fast packet processing with ebpf and xdp: Concepts, code, challenges, and applications. ACM Computing Surveys (CSUR) 53, 1 (2020), 1–36.

[93] OpenAirInterface Wiki. 2022. OpenAirKernelMainSetup. https://gitlab.eurecom.fr/oai/openairinterface5g/-/wikis/OpenAirKernelMainSetup.

[94] Reinhard Wilhelm, Jakob Engblom, Andreas Ermedahl, Niklas Holsti, Stephan Thesing, David Whalley, Guillem Bernat, Christian Ferdinand, Reinhold Heckmann, Tulika Mitra, et al. 2008. The worst-case execution-time problem—overview of methods and survey of tools. ACM Transactions on Embedded Computing Systems (TECS) 7, 3 (2008), 1–53.

[95] Julian Wolf, Bernhard Fechner, Sascha Uhrig, and Theo Ungerer. 2012. Fine-grained timing and control flow error checking for hard real-time task execution. In 7th IEEE International Symposium on Industrial Embedded Systems (SIES’12). IEEE, 257–266.

[96] Julian Wolf, Bernhard Fechner, and Theo Ungerer. 2012. Fault coverage of a timing and control flow checker for hard real-time systems. In 2012 IEEE 18th International On-Line Testing Symposium (IOLTS). IEEE, 127–129.

[97] Hao Yin, Xiaojun Guo, Pengyu Liu, Xiaojun Hei, and Yayu Gao. 2020. Predicting Channel Quality Indicators for 5G Downlink Scheduling in a Deep Learning Approach. arXiv preprint arXiv:2008.01000 (2020).

[98] Qi Zhang, Alexandros Nikou, and Marios Daoutis. 2022. Predicting Buffer Status Report (BSR) for 6G Scheduling using Machine Learning Models. In 2022 IEEE Wireless Communications and Networking Conference (WCNC). IEEE, 632–637.

[99] Ying Zhang and Krishnendu Chakrabarty. 2003. Energy-aware adaptive checkpointing in embedded real-time systems. In 2003 Design, Automation and Test in Europe Conference and Exhibition. IEEE, 918–923.

[100] Yadan Zheng, Shubo Ren, Xiaoyan Xu, Ying Si, Mingke Dong, and Jianjun Wu. 2012. A modified ARIMA model for CQI prediction in LTE-based mobile satellite communications. In 2012 IEEE International Conference on Information Science and Technology. IEEE, 822–826.

[101] Avi Ziv and Jehoshua Bruck. 1997. An on-line algorithm for checkpoint placement. IEEE Transactions on computers 46, 9 (1997), 976–985.

附录

附录.1 加载Janus小程序集及小程序调度

正如第3.1节所解释的，Janus小程序通过Janus控制器提供的网络API进行JIT编译并加载到Janus设备上。开发者可以使用Janus SDK提供的工具将开发的小程序上传到Janus控制器并加载到Janus设备，如图10所示。将小程序上传到Janus控制器并加载到Janus设备所需的指令被编码在一个以YAML格式编写的描述符文件中，其结构和属性在示例6中列出。

 1 codelet1:
 2   codelet: codelet1.o
 3   hook_name: hook_name1
 4   priority: codelet1_running_priority
 5   runtime_threshold: codelet1_max_runtime
 6 codeletN:
 7   codelet: codeletN.o
 8   hook_name: hook_nameN
 9   priority: codeletN_running_priority
10   runtime_threshold: codeletN_max_runtime
11   linked_maps:
12     codeletN_map:
13       codelet: codelet1
14       map_name: codelet1_map

示例6: 小程序YAML格式

YAML文件指定了小程序集中所有小程序的名称(ELF格式的eBPF字节码对象文件)，被链接到Janus设备中的钩子名称以及调度优先级(多个小程序可以被链接到同一个钩子)。YAML文件为进一步配置小程序提供了额外的可选配置参数，例如，在利用5.1节的运行时控制机制时，为每个打补丁的小程序设置运行时阈值。

同一小程序集的小程序可以共享状态并协调执行，这在执行监测或控制操作时特别有用，这些操作需要获取跨vRAN堆栈不同层的事件和数据(例如，在第4节干扰检测的情况下)。小程序之间的状态共享是通过共享map实现的，为了使这种机制发挥作用，想要共享状态的小程序必须在其type、key_size、value_size和max_entries方面使用完全相同的共享map定义，而map名称可以不同。然后，开发者可以在用于加载小程序集的YAML描述符文件的linked_maps部分指定要链接的map，如示例6所示。当小程序集被加载时，共享map的内存在Janus设备上只被分配一次，所有共享map的小程序都会得到一个指向相同内存的指针，然后可以通过辅助函数调用该内存来存储和加载状态。

附录.2 灵活的Janus输出格式

输出格式可以被多个小程序复用。通过Janus SDK，输出格式定义和小程序被分别上传到Janus控制器，小程序在其环形输出缓冲区map的定义中指定使用哪种输出格式，包括三个字段，如示例1的第11-13行所示。proto_name字段包含名称，表示已经上传到Janus控制器的唯一的protobuf规范文件。proto_msg_name字段表示proto_name规范的根消息，用于通过这个环形缓冲区发送数据(一个proto规范可以包含多个消息定义)。最后，proto_hash字段包含哈希值，用来确保开发小程序时使用的protobuf规范文件的内容与上传到Janus控制器的文件内容相同。

图11说明了带有输出格式定义的小程序集的加载过程。Janus控制器解析小程序对象(ELF)文件，识别map部分中JANUS_MAP_TYPE_RINGBUF类型，然后基于map定义中的proto_name值，将小程序与先前上传到控制器的一些.proto规范文件联系起来。一旦找到规范定义，控制器将map的proto_hash字段与.proto文件的哈希值进行比较。如果匹配，控制器会给小程序的环形缓冲区map分配唯一的stream-id(一个16字节的UUID)。接下来，控制器自动生成编码器(encoder) 和解码器(decoder) 函数，负责对小程序发送至Janus输出数据收集器的proto_msg_name类型的消息进行序列化和反序列化。控制器通过网络API将自动生成的编码器函数与经过验证的小程序字节码和输出map的stream-id一起发送到Janus设备。控制器还将stream-id与自动生成的解码器函数一起发送给输出数据收集器。收集器维护一个键值结构，将stream-id(键)映射到解码器函数(值)。

每次有JANUS_MAP_TYPE_RINGBUF类型输出map的小程序被加载到Janus设备上，一个单生产者/单消费者(SPSC)的环形缓冲区数据结构就会被创建并链接，其中小程序是生产者，输出线程是消费者。如图12所示，每次小程序调用janus_ringbuf_output()辅助函数(例如示例1的第42行)，输出数据就被推送到环形缓冲区。输出线程消费这些数据，并调用相应的编码器函数对其进行序列化。在通过UDP将序列化数据发送到输出收集器之前，会附加一个头域，其中包括16字节的stream-id和2字节的序列号。一旦输出收集器收到输出信息，就会将stream-id与对应的解码器函数相匹配，用来反序列化该信息。最后，反序列化的消息被转换为JSON格式，然后可以被输送到流水线上的其他组件(如存储、ML处理等)。

附录.3 编写Janus钩子函数

为了简化编写Janus钩子的过程，Janus SDK提供了一套用于声明和运行新钩子的宏。简而言之，调用DECLARE_JANUS_HOOK()宏，并将新钩子的名称、传递给钩子的小程序上下文类型、钩子函数签名(名称和参数类型)以及用于填充将被传递给小程序的上下文赋值列表作为输入参数。示例7是示例1中小程序的钩子示例。

 1 DECLARE_JANUS_HOOK(fapi_dl_config_req ,
 2         struct janus_ran_fapi_ctx ctx ,
 3         ctx ,
 4         HOOK_PROTO (
 5             nfapi_dl_config_request_pdu_t * dl_config_req ,
 6             int ctx_id ,
 7             int frame ,
 8             int subframe ,
 9             int cell_id ,
10             int fapi_list_size
11             ) ,
12         HOOK_ASSIGN (
13             ctx.ctx_id = ctx_id ;
14             ctx.cell_id = cell_id ;
15             ctx.slot = subframe ;
16             ctx.frame = frame ;
17             ctx.data = ( void *) dl_config_req ;
18             ctx.data_end = ( void *) ( dl_config_req +
fapi_list_size ) ;
19             )
20         )

示例7: 示例1中小程序的钩子定义

基于这些输入，宏会自动生成构成钩子API的函数模板代码，包括钩子加载和卸载小程序的函数，以及运行与钩子链接的所有小程序的函数。表5显示了示例7自动生成的函数列表。

表5: 示例7中通过DECLARE_JANUS_HOOK()宏自动生成的函数

一旦声明了钩子，开发者可以通过DEFINE_JANUS_HOOK()这个宏来实例化钩子，将钩子名称作为参数传入vCU/vDU代码中。最后，通过调用自动生成的函数hook_#hook_name()，可以在代码的任何地方调用该钩子，其中#hook_name是声明该钩子时使用的名称。例如，在示例7中，会生成钩子hook_fapi_dl_config_req()。

附录.4 基于Janus进行推理

接下来我们详细解释Janus如何通过map使用更复杂的ML模型进行推理。示例8中显示了一个简单的小程序例子，用于第4节中讨论的随机森林模型。这个小程序对一个预先训练好的模型进行推理，然后返回。

 1 struct janus_load_map_def SEC("maps") model_map = {
 2   .type = JANUS_MAP_TYPE_ML_MODEL ,
 3   .max_entries = 16 ,
 4   .ml_model = "random_forest",
 5 };
 6
 7 struct features {
 8   int f1 ;
 9   int f2 ;
10   int f3 ;
11   int o1 ;
12 };
13
14 SEC("janus_ran_fapi")
15 uint64_t bpf_prog(void *state) {
16
17   struct features feats ;
18   int res ;
19
20   feats.f1 = 1;
21   feats.f2 = 1;
22   feats.f3 = 1;
23
24   /* We store inference result in output */
25   res = janus_model_predict(&model_map , &feats);
26
27   if (res) return 1;
28
29   return 0;
30 }

示例8: ML模型使用示例

加载ML模型 -- 从示例8第2行可以看出，我们定义了一个JANUS_MAP_TYPE_ML_MODEL类型的map，该模型必须由控制器以序列化格式从一个名为random_forest的输入文件中加载(第4行)。序列化的模型以char数组的形式表示，并获取janus所需的所有重要信息，以便在内存中重新创建训练好的模型。例如，对于随机森林模型，序列化包含关于模型类型(随机森林)、估算器(树)数量、对每个估算器的每个节点进行检查的条件以及树的叶子节点的推理值等信息。Janus只支持一组预先确定的模型类型(目前是随机森林和SVM)，每个模型都有自己的序列化参数集。在加载小程序的过程中，验证器将检查加载的序列化模型是否有效，包括检查模型类型以及模型参数的有效性(即模型是否可以在内存中重构)。如果任何一项检查失败，那么小程序就不会被加载到Janus设备中。

程序内推理 -- 加载的模型希望有一组输入特征以及确定数量和大小的输出，输入特征和输出所需的内存在ML模型map定义中指定。比如示例8有3个输入特征和1个输出(第7-12行)，总内存大小为16字节(第3行)。输入特征和输出的确切内存布局取决于训练好的模型，因此是由小程序决定的。有了输入特征，可以通过调用辅助函数janus_model_predict()进行推理，如第25行所示。

附录.5 实时运算

还有更多为Janus所作的优化的细节，以确保实时性能:

输出map -- 对于每个输出流，创建一个无锁的单生产者/单消费者环形缓冲区，将数据从小程序推送到输出线程，避免任何系统调用(见图2)。这确保了小程序永远不会被抢占，并且在最坏情况下可能只是丢掉多余的数据包。

内存分配 -- Janus使用预先分配的内存进行操作(加载小程序的JIT代码，map，数据输出等)。它依赖DPDK mempools和Mbufs在无锁模式下运行(使用rte_stack mempool)，从而确保使用同一mempool的多个线程在被抢占的情况下不会影响其他线程的性能，并且最小化在fastpath中访问内存的抖动。

Janus map的并发性 -- 根据设计，Janus map不使用锁，以保证时间敏感的vRAN功能的实时性能，因此是非线程安全的，并可能会导致并发性问题(例如，在多实例工作线程代码中调用钩子)。然而，根据我们使用商业级vRAN功能的Janus的经验，大多数情况下，只要某种上下文ID作为钩子上下文的一部分被传递，以识别哪个实例正在调用钩子(例如，哪个CPU核心，哪个工作线程等)，就可以用无锁的方式编写小程序。我们正计划在未来适当的时候通过采用线程安全的map解决这一限制。

加载/卸载小程序 -- 我们通过基于用户空间实现的RCU(Read-Copy-Update)[65]将小程序加载(卸载)到Janus钩子上。RCU可以实现无锁访问共享数据结构，代价是写入/更新时间[69, 70]更长。这对Janus很适合，执行小程序的快速vRAN线程会读取数据，而更新钩子小程序列表的(非实时)线程写入/更新该数据。

你好，我是俞凡，在Motorola做过研发，现在在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。
微信公众号：DeepNoMind

参考资料