URLLC超低时延解决方案和关键技术

陆威，方琰崴，陈亚权

（中兴通讯股份有限公司，江苏 南京 210012）

0 引言

工信部发放5G 牌照后，电信运营商就紧锣密鼓地加紧推动5G 商用进程。2019 年11 月，5G 商用套餐正式商用，这标志着中国正式跨入5G 商用时代。和以往的通信制式明显不同的是，5G 在面向电信终端用户的同时，还面向工业化、自动化的应用。这标志着我国开启了第四次工业革命的序幕，5G 技术将极大促进工业互联网的发展，推动人类进入智能化时代[1]。工业互联网对5G 提出了很高的网络可靠性和低时延要求，例如工业控制、远程医疗、车联网等要求5G 网络能提供小于10 ms 的端到端超低时延能力[2]。3GPP 对此场景定义为URLLC，并从R15 开始研究相关技术，制定一系列技术标准。当前3GPP 的重点是改善5G 无线部分的通信时延[3]，对承载网、核心网等网络架构方面的超低时延技术研究较少，本文从5G 网络架构的角度[4]，介绍了URLLC 超低时延的解决方案和关键技术，并提供了部署方面的建议。

1 URLLC 解决方案架构

工业自动化控制通常要求端到端时延达到毫秒级别[5]，这个端到端时延由多个部分构成[6]，公式如下：

T_E2E 指端到端时延，是数据报文在UE 和APP 之间的单向时延。

T_RAN 指无线时延，是UE 和RAN 之间产生的时延。其中，电磁波在空间传播速度是光速，引起的时延极低，可以忽略不计。时延主要来自设备的信道编码、调制解调、算法计算、资源分配等的处理时间。在4G 网络中，无线时延在5 ms 左右，在5G 网络中，无线时延要求低于0.5 ms。3GPP 标准组对如何降低无线时延有大量研究，本文不做具体介绍。

T_Transmission+T_CN+T_Internet 指回传、核心网、互联网的叠加时延，这是光纤传输网络、路由器节点、核心网用户面网元、应用服务器的IP 报文处理产生的时延。一个原因是传输距离比较大，中间存在多个网络节点，每个节点转发数据时都产生一部分时延；另一个原因是网络虚拟化[7-9]带来的性能下降，产生一部分时延。

图1 是端到端URLLC 超低时延解决方案，采用多种技术实现超低时延的效果，包括云网融合的边缘计算[10-11]、增强型用户面硬件加速、最优路径的多维协同、端到端的时延监控。这些技术可根据部署需要，选择部分或所有技术进行组合使用。

URLLC 超低时延的网络架构遵循3GPP 定义的5G网架构[12-16]，在实际部署时应该基于几个原则来实现超低时延的建网目标。

原则1：最短路径。即用户面UPF（User Plane Function，用户面功能）网元下沉部署到靠近用户的边缘节点[17]。需要引入云网融合的边缘计算和用户面硬件加速技术。

原则2：预留资源。即在建网初期做话务模型预测时，预留一定比例的冗余量，让网络在实际运行时处于比较轻载的状态，避免频繁的网络拥塞带来的高时延[18]。在网络运行阶段，能监控时延指标，动态调整资源分配，为超低时延的应用预留资源。需要引入端到端的时延监控技术。

原则3：云网协同。即APP 也下沉部署到靠近用户的边缘节点。当用户移动时，5G 网络的UPF 会跟随用户切换到靠近用户的新位置，同时云内的APP 也能协同跟随用户切换到新的UPF 位置。需要引入最优路径的多维协同技术[19]。

图1 端到端URLLC超低时延解决方案

2 URLLC 关键技术

2.1 云网融合的边缘计算

5G 时代以前，移动用户的流量比较少，运营商为节约建设成本，一般把用户面网元（EPC PGW）部署在省会城市，流量先汇聚到省会EPC PGW，然后再进入Internet的云端处理。用户和云端应用之间有很长的空间距离，IP 报文会经过很多路由节点和光纤传输设备，带来较大的时延。3GPP 和ETSI 针对5G 的低时延高带宽需求特点，设计了MEC（Multi-access Edge Computing，多接入边缘计算）解决方案，把用户面设备UPF 部署到靠近边缘的MEC 中，缩短UE 到UPF 间的传输距离并减少路由跳数，从而降低时延[20]。这个解决方案解决了网（UEUPF 的路径）的低时延问题，未解决网和云（UPF-APP）之间的低时延问题。原因是云端的应用不属于运营商资产，运营商从网络安全的角度会采用防火墙等安全设备隔离云端的应用，而且云端的APP 和运营商的网络一般也不在同一个站点，网和云间存在的路由器、防火墙、光纤等传输路径增大了时延。采用云网融合的边缘计算技术，可以解决云网之间的时延问题，从而提供端到端毫秒级的超低时延能力。

云网融合的边缘计算，核心网思想是把运营商的网（UPF）和云端低时延需求的APP 融合在同一个MEC 站点的局域网内，UPF 和APP 间的报文传输不需要绕到外部网络做路由迂回，大大降低了UE 和APP 间的报文传输路径，从而降低时延。但这个方案的UPF 和APP 间存在安全隐患，需要采用如下几个技术保证云网融合后的安全可靠性[21-23]。

技术1：MEC 内部的局域网内划分不同的VLAN（Virtual Local Area Network，虚拟局域网）并建立DMZ（Demilitarized Zone，隔离区），让APP 处在DMZ 中，避免非授权许可的端口报文侵入到本网内。

技术2：UPF 和APP 间增加虚拟防火墙。由于UPF和APP 间的报文端口比较单一，虚拟防火墙的配置和业务处理比较简单，增加的虚拟防火墙带来的极低时延（微秒级别）对端到端时延影响非常小。

技术3：对APP 做安全认证。运营商对进入MEC的APP 提前做软件安全扫描，避免该APP 携带病毒或被植入不明软件。一旦安全扫描通过，运营商向该APP 发放证书，用于后续的鉴权认证，只有认证通过的APP 才被允许在MEC 内运行。

技术4：对APP 做安全加固。当APP 部署到MEC时，运营商需对APP 的操作系统、数据库等做安全加固，确保不用的端口、服务和协议栈都被关闭。

技术5：运营商在MEC 中部署一套APP 鉴权认证系统。APP 在MEC 内启动时，该系统对APP 进行鉴权认证，确保APP 的完整性和一致性。如果APP 未通过鉴权认证，就被隔离删除。

以上技术在实际应用中有着良好的效果，MEC 内UPF 和APP 的综合时延能控制在10 μs 级别，而且安全性也得到了保障。

2.2 增强型用户面硬件加速

电信网络功能虚拟化（NFV）后，通过使用通用COTS（Commercial Off-The-Shelf）服务器以及虚拟化技术来转发IP 报文，从而提升资源利用率，降低网络设备成本。但NFV 技术采用的通用硬件也带来了一个缺点，即用户面的数据除了经过网卡的收发外，还需要CPU 和应用层软件介入处理，涉及的模块多，而且CPU 并不是专为报文转发设计的，转发性能低，导致IP 报文转发时延大，不能很好地满足5G 网络超低时延的性能要求。

可以在通用COTS 服务器中加入FPGA 智能网卡硬件[25]，让该智能网卡专门处理用户面IP 报文转发，从而显著提高转发效率，使UPF 网元级的转发时延从毫秒级降低到10 μs 级别。

图2 是UPF 带有智能网卡的数据处理架构，有两个关键的处理流程即建立流表流程和智能网卡本地卸载流程。

图2 用户面硬件加速数据处理架构

（1）建立流表流程。智能网卡从无线侧收到信令面的会话建立请求报文，智能网卡把该报文发送给UPF 的信令模块，UPF 信令模块解包获得TEID（Tunnel Endpoint Identifier，隧道端点标识），并返回给智能网卡，智能网卡把此TEID 记录在本地。后续智能网卡收到用户面的业务首包时，解析GTP（GPRS Tunnelling Protocol）内层用户IP 的源地址端口等五元组，查找智能网卡内的流表，由于这是首包，流表中没有对应的转发规则，智能网卡就把报文上传给UPF 的DPI，DPI 剥离GTP 头，处理CRC校验和，获得流表信息，并下发给智能网卡。智能网卡后续收到报文时，就可以通过本地流表的转发规则，把报文直接转发出去。

（2）智能网卡本地卸载流程。智能网卡从无线侧收到用户面报文后，根据物理端口和报文（源地址和端口）判断是否来自无线侧的GTP 报文，智能网卡查找本地TEID 表，如果存在则说明报文合法。智能网卡再获取GTP 内层用户IP 真实地址和源地址端口等五元组信息，查找智能网卡本地的流表，查找成功后，根据流表内的转发规则，把报文送到Gi 口直接转发出去。

UPF 植入智能网卡后，把大部分的IP 报文处理（解包、查流表、转发等）卸载到智能网卡本地处理，大幅减轻CPU 的处理负荷，减少内存读取次数，降低PCIe 总线负荷，从而提升整个COTS 服务器的处理性能。

2.3 最优路径的多维协同

IP 报文传输路径的距离长短和路由跳数多少，都会影响时延的大小。一般APP 会在地理位置上分布式部署到边缘位置，缩短APP 和UE 之间的路径。UE 在发起会话时，URLLC 网络会根据UE 所在位置、APP 分布式部署的地理位置，选择一个UPF 为该UE 服务，确保UERAN-回传网络-UPF-APP 是一条时延最优路径。

由于UE 会移动，当UE 从一个基站切换到另一个基站时，UE-RAN（新）-回传网络（新）-UPF-APP 的路径就发生了变化，该路径并不是时延最优路径，会加大UE和APP 间的时延。为了能在UE 发生移动切换时，持续获得低时延，需要及时根据UE 最新的位置信息和APP分布式部署位置信息，更新传输路径[24]。

3GPP 已经定义了UE 的切换流程，由SMF 根据UE的位置和UPF 的网络拓扑，选择新的UPF 为UE 提供服务。在引入URLLC 超低时延需求后，SMF 还需要综合考虑UE 位置和APP 地理位置拓扑信息，来选择最优路径上的新的UPF 和新的APP 节点。SMF 还需要通知APP，让APP 调度原节点的状态信息给新的APP 节点。后续该UE 的IP 报文就在“ UE-RAN（新）-回传网络（新）-UPF（新）-APP（新）”新的最优路径上传输。

2.4 端到端的时延监控

URLLC 网络在正常情况下能提供超低时延的数据传输能力，但有时因用户接入太多，或突发大流量等原因，网络也会发生数据拥塞或丢包，因此需要有机制能实时监控时延状态，当时延高于某个阈值时，URLLC 网络能调整网络资源的分配，抢占低优先级应用的资源，并预留给高优先级的低时延应用，能尽快解决高时延的问题。同时也能及时把高时延告警发送给应用，让应用能及时应对处理。例如车联网为了保障车辆行驶安全，需要采用超低时延的URLLC 网络来保障车辆能及时获取到周边环境的信息，否则容易发生事故[26]。URLLC 网络一旦检测到时延低于车联网要求，就要及时通知车辆降低车速，以便车辆在紧急情况时有更多的缓冲时间完成刹车等动作。

应用一般更关注单向时延，即IP 报文在UE-基站（NR）-回传网络-核心网UPF 间的整个传输路径上的时延。在该路径的关键节点上设置时延监控点，这些节点间通过微秒级别的高精度时钟同步保证时间一致性[27]，每个节点转发IP 报文时都会把本节点的当前时间戳插入该IP 报文。UPF 作为监控的汇总点，对收到的IP 报文中的时间戳进行计算，获得该IP 报文在URLLC 网内的端到端传输时延。由于不同的应用对时延的要求是不同的，需要能针对特定对象进行监控，例如针对业务类型，或者某个UE，或者某个切片进行监控。一般需要3个步骤完成时延监控。

第一步，由APP 向URLLC 网络发起时延监控激活请求，后续URLLC 网络就能周期性监控时延状态。具体流程为：

APP 向PCF 发送“时延监控请求”消息，内带“被监控对象（例如IMSI）”“时延阈值Tmax-delay（例如50 ms）”。

PCF 收到“时延监控请求”消息后，对APP 进行鉴权认证，确保该APP 是合法应用。并把“时延监控请求”消息转发给SMF。

SMF 收到“时延监控请求”消息后，根据消息中的“被监控对象”，确定在哪些UPF 上设置监控点。如果“被监控对象”是某个APP，SMF 会向它管理的所有UPF发送“时延监控请求”消息。如果“被监控对象”是某个UE 的IMSI，SMF 会向UE 当前所在的UPF 发送“时延监控请求”消息。后续UE 发生UPF 间切换时，SMF 还需把该请求消息发送给新的UPF。如果“被监控对象”是某个切片，SMF 会向该切片所在的UPF 发送“时延监控请求”消息。

UPF 收到“时延监控请求”消息后，记录该时延监控请求携带的参数。后续UPF 收到IP 报文时，会计算IP报文携带的各个节点插入的时间戳，获得UE 到UPF 间的单向时延数据。

第二步，UPF 收到IP 报文时，执行时延检测。具体流程为：

UE 向RAN 发送IP 报文时插入UE 的时间戳T1。RAN 收到IP 报文后插入RAN 的时间戳T2，并转发给UPF。UPF 收到IP 报文后插入UPF 的时间戳T3。

UPF 根据公式Tdelay=T3-T1，计算获得UE 到UPF间的时延Tdelay，如果Tdelay 大于Tmax-delay 的值，说明该报文时延超过了阈值。如果后续连续10（该值可以根据应用场景需要更改大小）个报文时延都大于阈值，就认为当前网络时延不满足应用的要求。此时UPF 执行2 个动作：一个是通知URLLC 网络内的瓶颈节点（通过“T2-T1”和“T3-T2”的值判断哪些节点产生了高时延），调整节点内资源分配策略，提升本IP 流的转发速度；另一个是通知APP，由APP 根据本地策略调整动作，例如高速自动驾驶中的车辆能降低车速。

第三步，APP 向URLLC 网络发送“去激活时延监控”的请求，后续URLLC 停止对该APP 指定对象的时延监控。本步骤在实际应用中是必不可少的，原因是时延监控也耗费了URLLC 网络的资源消耗，在UE 的应用结束后，尽快通知URLLC 网络停止对该UE 的监控，可以降低URLLC 网络后续的处理负荷。

3 URLLC 部署建议

URLLC 有很多应用场景，不同的应用场景对时延的指标要求是有差异的，有的要求50 ms，有的要求10 ms，有的可能要求小于1 ms。

表1 是3GPP 定义的部分应用场景的时延要求[28-31]，有的时延甚至严格到0.5 ms，这是非常高的要求，目前该类应用还非常少。因此运营商在建设URLLC 网络时，要综合考虑建网成本和应用的要求。可以采用“架构一步到位，边缘节点逐步扩展”的原则。按照应用需求的节奏，分阶段完成部署。初期先集中建设URLLC 控制面网元，并在部分工业园区部署URLLC 用户面网元，满足部分客户的部分应用需求。发展后期再根据应用类型和客户数量的增多，部署更多的MEC 边缘站点，并利用最优路径的多维协同技术，让用户在移动过程中一直保持超低时延的通信状态。

表1 URLLC典型业务的时延要求

3.1 URLLC 部署初期

在建网初期，URLLC 应用的需求比较少，主要是一些工业园区的工业控制有这样的需求。可在省会中心城市集中建设一套URLLC 核心网控制面网络，例如AMF、SMF、PCF 等，这些控制面网元对应用的时延没什么影响，集中部署可以降低建设成本。而用户面网元UPF 和园区应用APP 以及URLLC 无线专网，采用按需部署的策略逐步建设[32-33]。

这个阶段的用户数少，园区应用也不多，无需采用网络切片建网，可以针对每个园区建设专网。当园区有URLLC 需求时，运营商就在该园区内部署URLLC 无线专网，在园区内建设MEC，并把UPF 和园区APP 下沉部署在该MEC 中。

MEC 内的UPF 和园区APP 在部署初始阶段就需要做好安全隔离和安全加固措施，避免在初期引入安全风险。针对MEC 内的UPF，需要配置好本地分流策略，把需要极低时延的流量分流到本地APP，把其他流量路由到Internet 云端。

URLLC 网络建好后，不能因为规模不大而降低网络性能指标的要求。从某个工业园区的视角看，他的应用和时延要求是完整和确定的。因此运营商为某个园区建好URLLC 网络后，应对该网络启动时延监控功能，统计分析时延表现，及时发现问题并调优网络。

3.2 URLLC 部署中后期

在建网中期，URLLC 应用的需求数量逐步增加，为了能灵活地为不同的园区和一些关键性的应用提供差异化性能指标的网络，需要采用网络切片的方式进行建网。可以为某个园区建设一个端到端的切片，也可以为某个应用建设端到端的切片。建设什么样的切片，需要运营商和园区客户谈，综合考虑成本、灵活性、指标要求，再决定是否采用切片建网[34]。

在建网后期，预计车联网等超低时延要求的应用也成熟了，这些应用服务的地理范围比较广，需要考虑用户跨MEC 移动时的超低时延问题。因此这个阶段首先要建设广覆盖的URLLC 无线网络，确保用户在漫游和移动过程中保持业务连续性。随着基站的广泛部署，相应地也需要增加MEC 的分布式部署规模，做到基站部署到哪里，MEC 跟到哪里，MEC 内的UPF 和APP 也跟到哪里。由于UE 会在大的地理范围内移动，需要APP 和UPF 支持最优路径的动态协同，确保UE 和APP 间的业务流量一直处在最短传输路径上，能持续地获得超低时延通信连接。

4 结束语

URLLC 的超低时延需求，必须通过系统性的端到端解决方案来满足。从架构层面的UPF 和APP 分布式下沉边缘计算技术，到硬件层面的用户面加速技术，到应用层面的最短路径优化提升，最终到总体层面的端到端时延监控技术，完整地构建了一套解决方案[35]。而基于此方案的横向由易到难，纵向由点到面的部署方案，让URLLC 的部署更加有序和科学。

URLLC 是5G 应用的核心技术，为工业4.0 变革、远程医疗、自动驾驶等应用提供了高质量的通信基础设施，它的成熟商用和广泛部署，必将对未来世界产生深远的影响。