文 涛，谭 蓓，孙元涛，刘 扬（中讯邮电咨询设计院有限公司郑州分公司，河南郑州 450007）

1 MEC概念及边缘引流需求

1.1 MEC基本概念

移动多接入边缘计算（MEC）是指在靠近人、物或数据源头的网络边缘节点，进行网络能力及平台能力的下沉部署，业务流量本地出口、业务功能本地实现，从而使低时延、大带宽业务成为可能，充分提升用户业务体验。MEC 作为运营商发展5G 2B/2C 高价值业务的重要战略，以CT 的连接能力和IT 的计算能力为切入点，创造性地赋能垂直行业，提供丰富、低时延的边缘能力及应用，从而帮助运营商构建“云、网、边、端、业”一体化的5G MEC 能力，为用户提供真正具备价值的5G和行业的融合模式。

1.2 MEC边缘引流需求

MEC 业务的实现依赖于业务流量在本地边缘的分流和响应，因此边缘业务的引流方案是MEC 部署场景中的核心内容，需要根据客户不同的需求来选择相应的网络引流方案进行适配。

结合当前各行业的总体情况，行业客户对边缘业务的引流需求一般可以归纳为如下几类场景。

场景1：封闭场景。行业客户采用提前签约的特定卡/终端，仅在固定区域内接入，仅需访问本地内网业务。

场景2：半封闭场景。行业客户采用提前签约的特定卡/终端，仅在固定区域内接入，内网及公网均需访问。

场景3：开放/混合场景。不限定卡/终端，可以是非提前签约用户，仅在固定区域接入，内网及公网均需访问。

场景4：漫游支持类场景。行业客户采用提前签约的特定卡/终端，需支持漫游后回归属区域接入访问内网业务。

面向行业客户不同的接入方式及不同的边缘业务场景需求，网络侧应采用不同的签约、配置和路由策略，来对客户业务进行按需引流。

本文将在研究分析相关引流技术的基础上对不同的客户需求场景提出相应的网络侧解决方案建议。

2 4G/NSA场景下边缘引流方案

2.1 概述

由于NSA 核心网一般采用4G 核心网升级建设的方式，因此4G/NSA场景下的引流建设方案，主要有CU分离模式、U 面下沉；SGW 下沉+LBO（Local Breakout）；S1 接口TOF（Traffic OffLoad）/DP（Data Plane）引流3 种方案。

另外，APN 方案应用广泛，且可应用于CU 分离或不分离模式，就不单独赘述了。

2.2 CU分离模式U面下沉

CU分离是4G/NSA核心网的一种标准网络架构形态，通过SAW-GW 的控制面（Control Plane）和用户面（User Plane）分离，并将用户面下沉，来实现业务的本地疏通，降低业务时延和骨干承载网的流量压力。CU分离方案组网如图1所示。

图1 CU 分离U面下沉引流组网

对于用户有本地引流需求的场景，可以将SAEGW 的用户面部署在客户侧，对特定业务引导至本地来进行疏通，满足用户需求。CU分离模式一般会基于用户的签约APN（Access Point Name）、位置、负荷等情况来进行U 面选择，其中APN 方式优先级最高，因此，CU 分离模式更适用于用户有特定的APN 签约属性，针对特定的APN 业务需要本地引流的情况。对照客户的引流需求场景，该方案更适用于场景1/2/4。

2.3 SGW下沉+LBO

SGW 下沉+LBO，是通过核心网SGW 下沉并部署流量分析功能，对流量进行引导。SGW+LBO 按照配置的分流策略，将符合过滤规则的上行数据包卸载到本地数据网络或者边缘计算平台，并将本地下行数据包按照承载映射规则映射到相应的承载上。SGW 下沉+LBO方案组网如图2所示。

图2 SGW+LBO下沉引流组网

该方案中，SGW 的功能包括解析上行数据包、完成下行数据报文的封装、将报文传递给LBO 进行识别和分流、实现本地分流流量的计费和合法监听功能；LBO 的功能包括对SGW 接收的数据报文进行识别和匹配、将符合分流策略的报文引流到本地、将从本地来的下行数据流封装到对应承载上以GTP-U 隧道包传递给SGW。

由于SGW 下沉+LBO 是通过流量解析的模式来实现业务引流，因此对客户是否提前签约无特殊要求；同时由于SGW 一般有固定的无线覆盖范围，因此仅能对固定区域接入的终端业务进行引流。对照客户的引流需求场景，该方案更适用于场景3。

2.4 S1接口TOF引流

在某些企业园区场景，如果不需要计费和监听且可以满足相关运维运营要求，可以采用S1接口TOF 引流方案，该方案对无线基站和核心网可以不感知。S1接口TOF引流方案组网如图3所示。

从逻辑组网上看，TOF/DP 是串接在S1 接口之上，根据本地的分流规则进行分流。TOF主要的功能有：

a）S1 接口封装与解封装：本地网络下发给UE 的报文，在TOF 进行GTP 封装后发给eNodeB；UE 发出的上行报文，匹配上行分流规则后需要分流到本地网络，进行GTP解封装。

图3 S1接口TOF引流组网

b）上行本地分流：TOF 配置上行分流规则，针对GTP 封装里的内层IP 报文，将匹配规则的报文分流到规则指定的目的平台或应用。规则一般是下列元素的组合：＜源IP，协议类型，目的IP，目的端口＞。

c）NAT 映射：可以根据需求对UE IP 进行NAT 转换，再发给本地网。

d）DNS 劫持：TOF 可以对特定URL 进行劫持和响应，DNS 响应返回为本地网IP，以支持UE 按域名的本地解析和引流。

e）TOF采用S1接口串接模式，因此核心网和无线侧均无感知。

TOF方式同样是通过流量解析的模式来实现业务引流，因此对客户是否提前签约无特殊要求；同时由于TOF 也需要与固定无线覆盖范围内基站的S1 接口进行对接，因此仅能对固定区域接入的终端业务进行引流。对照客户的引流需求场景，TOF 方案更适用于场景3。

2.5 方案应用小结

目前，场景1/2/4 均可应用CU 分离和APN 相结合的方案来解决，在无法提供CU分离的初期，已有SAEGW 下沉和APN 相结合的方案解决案例；而同时适用于场景3的S1接口TOF引流方案和SGW 下沉+LBO 方案，前者由于无需特定的SGW 功能，因此比后者实现相对简单，应用也相对广泛。

3 SA场景下边缘引流方案

3.1 概述

SA 场景下，用户面采用标准的UPF 网元，3GPP R15/R16 对于边缘场景也有充分的引流需求分析，因此SA场景下网络引流方案相对4G/NSA更为完善且比较标准，主要包括DNN、ULCL/BP和LADN。

从网络角度来看，上述几种分流模式可以涵盖用户基本的引流需求，但是面向运营商复杂的网络组网（如ToB、ToC分别建网）、客户侧业务复杂的需求（如黑白名单、带宽管理）等，网络侧仍需要采用相应的方案来进行应对。本章在介绍3GPP 标准分流方案的基础上对特殊的需求场景的解决方案进行分析和建议。

3.2 DNN签约引流

在4G/NSA 场景下，基站和SGW 之间的S1-U 接口是相对固定的连接，基站将业务流量无差别地送至1个或几个SGW（轮询）；而在SA 场景下，基站和UPF 之间的N3 接口可以由网络侧根据业务来动态选择，基站/终端和UPF 不再是固定连接，网络侧根据业务签约的DNN、位置等来为用户/终端/连接进行动态的UPF选择，DNN 优先级最高，采用DNN 方案，可以在N3 接口层面实现相应的业务引流。DNN 方案的组网如图4所示。

图4 DNN签约引流组网

终端特定业务签约特定DNN，网络针对特定DNN设置专用UPF（如园区专用UPF），5GC 在为业务选择UPF 时即可根据DNN 来选择。DNN 方式与4G/NSA 的APN 方式类似，终端签约特殊DNN，针对特定的业务采用本地UPF 引流；同时，终端还可以签约通用的DNN（如公网业务DNN），网络对于通用业务选择核心层UPF，从而在无线侧上行时即实现不同业务的不同流向引流。对照客户的引流需求场景，DNN 签约可对应于场景1/2/4。

3.3 ULCL/BP引流

与DNN 签约方式在无线上行N3 接口即可实现引流不同，ULCL/BP 方式则不需要终端签约特殊DNN，ULCL/BP本身需要依赖于边缘侧部署UPF自身的流量解析能力，UPF根据业务流量的IP五元组、DNS请求等方式来进行上行分流，将业务目的地址或DNS 域名请求是本地业务的流量，分流至本地内网/边缘平台，其他流量仍通过本地UPF 与核心层UPF 之间的N9 接口送至核心UPF来访问公网业务。ULCL/BP方案的组网如图5所示。

图5 ULCL/BP引流组网

在此种模式下，由SMF 通过N4 接口或者由MEC平台通过MP2 接口，将某些业务特定的流量分流规则传递给UPF，并由UPF对流量进行解析和规则适配，符合特定规则的流量会被引流至本地，其余流量仍由核心层UPF疏通。

ULCL/BP 由于不签约特殊的DNN，无法在N3 接口分流，因此一般在特定TA（Tracking Area）覆盖区域内的流量都会被引流至边缘侧部署的UPF，并由该UPF 实现ULCL/BP 功能。对照客户的引流需求场景，ULCL/BP方式比较适用于场景3。

ULCL/BP方式可以根据业务需求来灵活采用不同的分流策略，因此可以更敏捷地适应5G行业的多样化需求，可以实时将业务需求转化为可执行的网络策略而不需要提前签约，该种方式也是5G MEC 行业发展的主要推荐方式。

3.4 LADN引流

LADN 方式是通过终端签约相应的LADN 业务，并在特定的TA区内设置下沉的UPF，当签约终端移动到该TA区内时，网络侧感知终端位置并发起和终端的联动，终端可选择由该TA 区内的UPF 为业务提供服务。下沉的LADN UPF 一般连接至本地内网，从而实现特定终端在特定区域内的本地业务访问。LADN 方式组网如图6所示。

根据上述业务逻辑可以看出，LADN 需要终端提前签约并处于固定的TA 区内，因此整体灵活性比ULCL/BP 差，其业务实现逻辑与DNN 模式相似，但LADN一般服务于本地接入，对漫游场景无法提供支持，对照客户的引流需求场景，LADN 方式比较适用于场景1/2。

3.5 ToB、ToC核心网络分设场景的引流

图6 LADN引流组网

5G SA 阶段，中国联通和中国移动选择了ToB、ToC 核心网络分别建设的模式，5GC、UPF 网元均单独建设。这种模式可以更好地满足网络和业务分别管理的需求，业务逻辑更加简单清晰。

在实际业务发展过程中，很多行业客户既有ToB业务需求，又有ToC 的业务需求且要求业务均通过本地UPF 疏通，如果ToB UPF、ToC UPF 分别下沉，不仅给客户带来了更高的建网成本，也带来了更加复杂的组网及维护工作量，客户往往无法接受。如何采用一套UPF 既能满足ToB、又能满足ToC 需求是运营商亟需解决的问题。

结合核心网设备的接口解耦情况，本文提出2 种方式供参考。

3.5.1 UPF双跨方式

UPF 双跨方式，即一套UPF 同时对接ToB、ToC 的5GC SMF，UPF 可以同时接受不同SMF 下发的面向不同Session 的业务策略。UPF 双跨方式的组网如图7所示。

图7 UPF双跨引流组网

当前主流CT厂家UPF均可以支持双跨方式，采用双跨方式可以解决客户ToB、ToC采用同一套UPF接入的需求。当前，由于商用的SA 网络暂时无法支持N4接口解耦，因此双跨只能在同厂家的5GC/UPF 之间实现，如果ToB、ToC采用不同厂家的5GC设备，则双跨方式无法解决ToB、ToC同时接入的问题。

3.5.2 客户卡重新签约方式

当前MEC 业务仍以ToB 为主，当客户同时存在ToC 需求且要求通过同一套边缘UPF 接入时，也可以将客户的ToC 卡重新签约在ToB UDM 里，使其在网络侧呈现为ToB 用户，从而能够通过边缘UPF 来使用业务。

该种方式适用于用户已经有ToC 卡，且卡号相对固定的情况，通过散号修改签约的方式来保障用户业务的同一套UPF接入。

3.6 其他特殊的边缘引流需求

在实际的业务发展过程中，行业客户往往还有一些特殊的引流需求，当前比较常见的有黑/白名单管理、带宽管理、流量管理等。相关的管理一般由MEC平台和UPF 配合实现，运营商为行业客户提供相应的网络能力增值服务，避免流量管道化，提升运营商自身的价值。

3.6.1 黑/白名单管理

黑/白名单管理，即客户需要网络侧能够对访问边缘业务的终端进行黑白名单认证，黑名单内的终端不允许访问某边缘应用、白名单内的终端可以访问某边缘应用。

黑/白名单管理一般可以由MEC 平台和UPF 配合实现，MEC 平台将特定应用+黑白名单列表通过MP2接口传递给UPF，由UPF 对流量进行解析，并按照黑/白名单规则执行相应的流量的拒绝/允许访问边缘应用的操作。

在该业务逻辑中，特定应用一般由平台和UPF 之间传递的应用名称+应用IP 地址来进行标识定义，黑/白名单列表则一般通过终端的MSISDN、IMSI、SUPI、GPSI等来进行标识。

3.6.2 带宽管理

带宽管理，即客户需要网络侧能够对特定的应用、Session 进行UPF 上下行带宽管理控制，从而面向应用或Session实现不同带宽优先级。

带宽管理一般也由MEC 平台和UPF 配合实现，MEC 平台将特定应用或特定Session 的列表和带宽管理指标通过MP2 接口传递给UPF，由UPF 对流量进行解析，并匹配执行相应的带宽管理操作。

在该业务逻辑中，特定应用一般由平台和UPF 之间传递的应用名称+应用IP地址来进行标识定义，Session 则一般由业务流量的IP 五元组来进行标识，带宽管理指标由平台传递给UPF，并由UPF执行带宽控制。

3.6.3 流量管理

流量管理与带宽管理的业务逻辑类似，只不过带宽管理是对特定的应用、Session 的上下行带宽进行管理，而流量管理则是对特定的应用、Session 的可用流量进行限制。

流量管理一般由MEC 平台通过MP2 接口将流量门禁传递给UPF，由UPF 针对特定的应用和Session 实行流量记录和门禁管理，当已用业务流量达到了门禁时，后续流量将被UPF拒绝转发。

3.7 方案应用小结

目前，场景1/2 可应用DNN 或LADN 方案来解决，鉴于LADN 的支持终端仍需进一步推动，DNN 方案应用比较广泛；其他场景及特殊需求均为单一解决方案，不再赘述。

4 结束语

综上所述，从行业客户对本地业务的不同类别引流需求，到MEC 在4G、5G 网络下各种主要的引流方案，本文针对当前运营建网情况以及客户实际需求进行了详细分析和方案建议。运营商可以结合本文进行相应的方案选择，行业客户也可以结合自身现在需求选择不同的网络方案，并了解到更多特殊需求，总之，本文既推动了网业协同、边网协同的方案建设，又对MEC满足各类行业需求具备良好的借鉴意义。