（CWW）5G终端与基站之间无线传输的电磁环境复杂，可能产生反射、折射、绕射、多普勒效应等现象，从而引起多径干扰、信号传播延迟和展宽等问题，为业务传输性能带来一定的不确定性，3GPP的R17和R18版本正在研究增强5G无线接入网切片服务能力和确定性传输技术。由于5G网络的确定性由无线接入网、承载网和核心网共同构建，所以回传网络应尽可能提高传输质量。

　　5G发展进入成熟期，主要业务从to C为主向to B+to C转变，精细化的SLA保证和差异化承载能力更加凸显。5G行业专网的发展，需要在一张物理网络上承载多种业务，而不同行业的业务特点也不同，需要进行差异化承载和定制化的SLA保证，除了通过网络的软、硬切片技术进行传输过程中关键业务的隔离以外，还需要业务感知技术将用户和业务的类别、SLA需求等更丰富的信息传递给网络，实现网络赋能，进一步支撑云网融合及将来的算力网络发展。

　　5G网络由无线接入网（AN）、移动承载网（TN）和核心网（CN）共同构成，在为移动终端提供语音、短信等基础电信服务的过程中，无线接入网和核心网直接参与处理用户的业务信息；从4G网络开始，移动互联网业务已经逐渐成为了业务的主要部分，但是在移动互联网业务处理流程中，5G网络只是提供一个Underlay的“管道”，无法感知业务的SLA需求，导致运营商不能针对不同的用户或业务提供精细化、差异化的服务，从而逐步陷入低价卖流量、增量不增收的困境。从长期来看，这不利于我国5G网络的健康发展。从5G业务端到端处理流程分析，导致5G网络“管道化”的主要原因有以下三方面。

　　GTP-U是3GPP早期定义的用户面传输协议，最初用在GPRS网络节点间用户面数据包的传输，并在后来的3G/4G/5G移动系统中一直被延续使用。GTP-U传输协议的特点是：在同一IP端到端连接上，构建点对点的隧道封装传输协议，提供多路传输复用、路径管理（GTP-U自己还有“带内控制消息”用于隧道Path管理）等能力。GTP-U隧道传输协议从2.5G GPRS系统开始被运用，在传统蜂窝非云化的电信网络中非常经典。GTP-U协议一直由3GPP控制主导，可按需不断地进行内容扩展，但也难以适应未来的云化网络特征。回传网从无线接口接收的用户面数据都是带有GTP-U封装的，这在一定程度上加大了回传网设备识别业务特征的难度。

　　DNS是互联网的一项服务，它作为将域名和IP地址相互映射的一个分布式数据库，用户能够更方便地访问互联网。DNS和业务系统当前确定目的服务器的主要依据是接收到用户终端DNS解析请求的DNS服务器所在的运营商、地域信息，但如果用户终端中配置的DNS服务器地址配置错误，或者配置为公共的DNS服务器，最终用户终端得到的服务器地址就会出现偏差。为了改进这个问题，阿里云等部署了HTTPDNS技术，用户终端通过HTTP向HTTPDNS服务器发出域名解析请求，此时HTTPDNS服务器可以获取终端的精确IP地址，并基于此IP进行调度。但这种调度方式仍然没有将用户终端与目的服务器之间网络的SLA指标纳入考虑范围，如果链路出现拥塞，就可能导致用户的服务质量劣化。

　　在5G回传网络中，传统的IP路由或MPLS技术不感知业务，只负责按照网络层度量值或人工设置的路径约束进行数据报文的转发。通过链路带宽计算得到路由协议中的度量值，也可以手工配置。近年来，随着SDN技术的发展，部分厂商支持在计算转发路径的因子中增加网络时延信息，但网络层与应用层业务依然是割裂的，网络层的路径计算结果无法与应用层的需求实时进行匹配。

　　为了解决数据传输网络无法获取到应用层业务需求信息的问题，业界提出了业务感知技术，当前主要分为以下两类。

　　APN6是在数据平面利用IPv6报文扩展头（Extension Headers），如逐跳选项头（Hop-by-Hop Options Header）、段路由头（Segment Routing Header）的可编程空间，携带应用的相关信息（标识和需求）到网络中，网络设备依据这些信息为其提供相应的网络服务，如将报文映射进相应的能够保障其SLA的SRv6路径等。应用感知信息可以由用户终端设备或应用直接生成，也可以由网络边缘设备生成，分别对应APN6的主机侧方案和网络侧方案。

　　SRN架构和流程如图1所示。在控制平面，基于RFC 6891进行DNS协议扩展，实现了用户终端、服务器与SDN控制器和接入路由器的交互。用户终端通过扩展的DNS协议，将应用SLA需求信息（如带宽和时延等）通过DNS代理转发给DNS解析器，并暂时缓存DNS解析器应答的DNS服务器IP地址信息；DNS代理向SDN控制器发送到DNS服务器的路径请求，由SDN控制器综合网络链路状态和应用需求计算出可到达DNS服务器的SRv6-Policy搬瓦工如何设置代理ip，并下发给接入路由器的路由管理组件进行转发表项的安装；DNS代理将DNS解析器返回的应用服务器IP地址和SDN控制器的路径计算结果BSID一起应答给用户终端。为了防止网络设备的故障导致服务劣化，网络状态监控组件会实时刷新OSPF路由信息，并及时通知SDN控制器进行同步更新。在转发平面，用户终端发送数据包时，携带DNS代理下发的BSID，接入路由器将数据包沿控制器下发的SRv6-Policy转发给网络中的应用服务器。

　　为了提升网络与业务的关联性，APN6和SRN提出了不同的解决思路，它们的数据面转发都基于SRv6技术，但携带业务层信息的方式不用，APN6是在IPv6的扩展头中封装应用信息及SLA需求信息，可用的扩展空间非常丰富（128 bit/SID）。而SRN是基于控制面的DNS协议进行扩展，相对携带信息的空间较少，只能携带带宽、时延等基本的SLA需求信息,它的优势是这是一个轻量级的方案，对企业的DNS服务器和主机（LINUX内核）进行软件升级即可，不需要运营商网络设备升级，也不依赖众多的应用生态的支持，所以实施起来相对更容易，两者详细对比参见表1。

　　从业务发展趋势来看，5G网络中的业务种类，流量模型与3G/4G相比都发生了显著的变化，尤其是行业业务的应用提出了比个人业务更严苛的需求。为了更好地满足这些需求，并加快构建数字化转型的新型基础设施，我国运营商都把云和网的融合确定为网络发展演进的重要方向，期望通过云网融合推动5G应用创新发展。面对长久以来云业务与网络各自独立发展的现状，当前需要思考如何逐渐改变这种解耦的发展方式，在这个过程中，网络对业务的感知技术成为业务层和网络层之间协同发展的纽带。

　　APN和SRN两类技术分别是针对广域和企业场景进行业务感知，但是对于5G网络，由于其业务报文被封装在GTP隧道中的特殊性，这两种技术并不能直接适用，需要进行针对性的优化。结合APN技术的优势，提出面向云网融合的5G回传业务感知方案。如图2所示，与当前的APN6方案相比，其关键的优化点在于针对5G回传的具体场景进行分析，并提出回传边缘PE设备对APN6信息的两种可选获取方式。其主要业务处理流程如下。

　　（1）终端或APP Server在发送业务报文前增加APN6标识，包含应用标识信息（用户组等）和应用需求信息（带宽、时延、抖动、丢包率等），其报文封装格式可与当前APN6中定义的格式保持一致，即在用户报文头后通过IPv6的逐跳选项头（HBH）、目的选项头（DOH）或段路由头（SRH）携带。

　　（2）回传网络中的边缘PE设备收到报文后，获取最终用户业务报文中的APN6标识信息。在这个过程中，具体获取APN6的方式有以下两种选择。

　　一是基站和核心网设备不做特殊处理，由于此时回传边缘PE设备收到的基站或核心网设备发送的报文封装如图3所示，所以回传边缘PE设备需要通过固定字节偏移来获取APN6中的封装信息，此时的偏移量为外层报文头之和（126 字节）：如果对于回传网络的中间P设备需要获取APN6信息，还要考虑在此基础上增加外层IPv6与UDP之间的SRH和SID列表，对设备芯片的转发性能要求更高。

　　二是在基站或核心网设备对收到终端或APP Server发送的用户报文主动进行判断，发现是携带APN6的报文时，则对其做特殊处理，将APN6报文头中的信息复制到外层IPv6与UDP之间，同时删除内层IPv6后的APN6报文；之后发送到回传边缘PE设备，只需偏移ETH+VLAN+外层IPv6的字节数（62 字节）即可获取到APN6信息，相对第一种方式对回传设备硬件的要求更低（见图4）。

　　（4）控制器基于边缘PE设备上送的信息，将带宽、时延、抖动、丢包率等需求信息纳入算路因子（时延、丢包率等需留出无线接入网和核心网的余量），并计算到达外层目的IP（边缘云或核心云中的核心网设备）的路径，下发至边缘PE设备。

　　（5）边缘PE设备收到控制器下发的路径后，根据SRv6 Policy进行SID列表的封装，APN6信息保留用于回传网中P设备进行随流监控等服务，并按照下发路径进行报文转发至相应的边缘云或核心云内核心网设备中。

　　为了提升网络层与业务层的关联性，业界在进行不断的尝试和探索，APN6和SRN是其中的两种典型方案，不排除后续会有更多的方案被提出和验证。基于SRv6的APN6相对于传统的最短路径算法和QoS优先级映射，具有业务级或用户级的细粒度和可量化的多维度SLA保证等优势；相对于SRN又具备更丰富的信息携带能力和扩展空间的优势。面向云网融合的5G回传业务感知方案，在APN6信息的传递和获取方式上进行了优化，在未来算力网络中，还可以通过字段扩展携带业务的算力需求信息，具有更大的发展潜力。但APN6在生态建设和性能验证等方面也还需要继续加大投入，具体有以下三方面建议。

　　（1）主机侧方案要求业务应用支持封装APN6报文头，但当前APP种类众多，生态链支持的难度较大，后续建议加强业界生态建设，吸引APP厂家的共同参与和支持；另外，针对5G回传的场景，在当前GTP隧道封装的报文中实现APN6，需要对报文进行深度检测或基站、核心网设备特殊处理，除了功能上的要求之外，还可能对网络设备转发性能带来较大压力，同时业务时延也会增加，需评估是否在可接受范围内。当然，比较理想的方案是在6G网络中，无线接入侧和核心网侧能去掉GTP封装，或者扩展协议将终端APN6的信息通过标准化的接口传递给回传网络。

　　（2）APN6标准还未成为稳定的工作组文稿或RFC，建议相关厂商和运营商针对典型场景，补充更多的性能测试数据，并进行针对性的优化，增强其可部署性。

　　（3）APN6当前解决的是用户侧需求信息感知的问题，而将来的算力网络，需要网络对用户侧需求和资源侧供给做最优的匹配，所以还需要面向算力网络做相应的扩展，增加感知业务对算力需求字段的支持，并与CFN[7]等新技术结合，既为业务匹配最佳算力资源节点，又能计算出到算力资源节点的最佳路径。

　　在算力网络时代，网络不再是单纯的数据传输，而是集通信、计算、存储为一体的信息系统。算力资源的统一建模度量是算力调度的基础，算力网络中的算力资源将是泛在化、异构化的，通过模型函数将不同类型的算力资源映射到统一的量纲维度，形成业务层可理解、可阅读的零散算力资源池，为算力网络的资源匹配调度提供基础保障。统一的管控体系是关键，传统信息系统中应用、终端、网络相互独立，缺乏统一的架构体系进行集中管控、协同。因此，算力网络的管控系统将由网络进一步向端侧延伸，通过网络层对应用层业务感知，建立云网边端融合一体的新型网络架构，实现算力资源的无差别交付、自动化匹配，以及网络的智能化调度，并解决算力网络中多方协作关系和运营模式等问题。