CN115150305A - 承载网时延链路确定系统、方法、电子设备及存储介质 - Google Patents

Abstract

本申请涉及通信技术领域，提供了一种承载网时延链路确定系统、方法、电子设备及存储介质，该系统包括：协同层，用于接收应用层下发的业务传输请求，并将业务传输请求发送给控制层；控制层，用于接收协同层发送的业务传输请求，基于业务传输请求调用云网层内互联网协议地址IP承载网中所有链路对应的时延数据，并基于业务传输请求和时延数据确定传输链路，其中，IP承载网包括本地承载网和云骨干承载网，控制层与云网层内的云骨干承载网建立SRv6策略以及BGP‑LS连接，用于下发业务路径和收集时延数据。本申请可适用于多域IP承载网的时延检测，匹配出符合业务需求的传输链路，提高业务传输效率，减少人工参与，提升业务传输准确性。

Description

承载网时延链路确定系统、方法、电子设备及存储介质

技术领域

本申请涉及通信技术领域，尤其涉及一种承载网时延链路确定系统、方法、电子设备及存储介质。

背景技术

随着通信技术的发展，因特网协议(Internet Protocol，IP)承载网络应用越来越广泛，时延是网络的固有属性之一，也是评价网络性能的基本指标。目前各运营商没有开放IP承载网的时延保障能力给客户，但随着第五代移动通信技术(5th Generation MobileCommunication Technology，5G)行业深入纵向发展，各行各业对运营商提出更高的业务时延要求。

现有技术中，运营商IP承载网骨干节点间的组网链路，由不一致的长、短时延路径形成，针对不同业务，通过手工配置在对应时延路径的方式，满足不同业务的需求。

但是，人工调整的手工配置方法，需要先手工收集各层网络中的链路时延，再估算出符合业务时延要求的路由，再把业务配置在对应路由中，效率低且操作复杂，存在影响业务的风险。

发明内容

本申请提供一种承载网时延链路确定系统、方法、电子设备及存储介质，可以适用于多域IP承载网的时延检测，匹配出符合业务需求的传输链路，进而提高业务传输效率，减少人工参与，提升业务传输准确性。

第一方面，本申请提供一种承载网时延链路确定系统，所述系统包括：

协同层，用于接收应用层下发的业务传输请求，并将所述业务传输请求发送给控制层；

控制层，用于接收协同层发送的所述业务传输请求，基于所述业务传输请求调用云网层内互联网协议地址IP承载网中所有链路对应的时延数据，并基于所述业务传输请求和所述时延数据确定传输链路，其中，所述IP承载网包括本地承载网和云骨干承载网，控制层与云网层内的云骨干承载网建立第六代因特网协议的段路由SRv6策略以及边界网关链路状态搜集协议BGP-LS连接，用于下发业务路径和收集时延数据。

可选的，所述控制层基于所述业务传输请求调用云网层内IP承载网中所有链路对应的时延数据，包括：

判断所述业务传输请求在云网层内对应的承载网的类型；

若所述承载网的类型为本地承载网未部署所述SRv6策略但云骨干承载网部署所述SRv6策略，则调用云网层内本地承载网内创建的虚链路对应的时延数据与云骨干承载网内的链路对应的时延数据；

若所述承载网的类型为本地承载网部署所述SRv6策略和云骨干承载网部署所述SRv6策略，则调用云网层内本地承载网和云骨干承载网内的链路对应的时延数据。

可选的，所述控制层调用云网层内本地承载网内创建的虚链路对应的时延数据与云骨干承载网内的链路对应的时延数据，包括：

基于所述本地承载网内创建的虚链路的双向主动测量协议Twamp采集实例，调用所述虚链路对应的时延数据；所述虚链路为提前预设好的包括至少一个节点的虚拟链路；

调用所述云骨干承载网内的链路对应的时延数据。

可选的，所述控制层基于所述业务传输请求和所述时延数据确定传输链路，包括：

基于所述业务传输请求确定所述业务传输请求对应的时延需求；

针对每一链路，基于链路中至少一个节点对应的时延数据利用预定义算法计算该链路对应的时延；

在计算得到的所有链路对应的时延中查找满足所述时延需求对应的传输链路。

可选的，所述控制层还用于：

若查找到满足所述时延需求对应的传输链路有多条，则根据每一传输链路被使用的次数计算多条传输链路的利用率；

选取多条传输链路的利用率中最小值对应的传输链路。

可选的，所述控制层还用于：

获取所述IP承载网内每一条链路中对应的节点信息和链路状态；

判断每一条链路对应的时延数据和\或利用率是否满足预设要求，

若不满足，则基于对应链路的中对应的节点信息、链路状态、时延数据以及业务传输请求创建告警信息，并发送至应用层进行可视化显示，以供用户进行查看。

可选的，所述协同层接收应用层下发的业务传输请求，包括：

获取用户在应用层输入的业务传输请求；所述业务传输请求包括业务开通、业务查询、业务调速、业务取消；

其中，所述业务开通用于为用户提供开通系统检测每一链路对应时延数据的能力；所述业务查询用于为用户提供查询每一链路对应时延数据的能力；所述业务调速用于为用户提供调整每一链路对应时延数据的能力；所述业务取消用于为用户提供取消关闭每一链路对应时延数据的能力。

第二方面，本申请还提供一种承载网时延链路确定方法，所述方法包括：

接收协同层发送的应用层下发的业务传输请求，并基于所述业务传输请求调用云网层内互联网协议地址IP承载网中所有链路对应的时延数据；

基于所述业务传输请求和所述时延数据确定传输链路，其中，所述IP承载网包括本地承载网和云骨干承载网，控制层与云网层内的云骨干承载网建立第六代因特网协议的段路由SRv6策略以及边界网关链路状态搜集协议BGP-LS连接，用于下发业务路径和收集时延数据。

第三方面，本申请还提供一种电子设备，包括：处理器，存储器以及计算机程序；其中，所述计算机程序被存储在所述存储器中，并且被配置为由所述处理器执行，所述计算机程序包括用于执行如第二方面所述的承载网时延链路确定方法的指令。

第四方面，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如第二方面所述的承载网时延链路确定方法。

综上所述，本申请提供一种承载网时延链路确定系统、方法、电子设备及存储介质，可以通过协同层接收应用层下发的业务传输请求，并将业务传输请求发送给控制层；进一步，控制层接收协同层发送的业务传输请求，并基于业务传输请求调用云网层内本地承载网和云骨干承载网中所有链路对应的时延数据，进一步的，控制层基于业务传输请求和时延数据确定传输链路，其中，控制层与云网层内的云骨干承载网建立第六代因特网协议的段路由SRv6策略以及边界网关链路状态搜集协议BGP-LS连接，用于下发业务路径和收集时延数据。这样，本申请可以适用于多域IP承载网的时延检测，即可以获取本地承载网和云骨干承载网内每一链路对应的时延数据，进而匹配出符合业务需求的传输链路，可以提高业务传输效率，且减少人工参与，提升业务传输准确性。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为本申请实施例提供的一种应用场景示意图；

图2为一种业务转发路径示意图；

图3为本申请实施例提供的一种承载网时延链路确定系统的架构示意图；

图4为本申请实施例提供的一种基于IPRAN承载网的管控层示意框图；

图5为本申请实施例提供的一种基于智能城域网的管控层示意框图；

图6为本申请实施例提供的一种完整的承载网时延链路确定系统的功能示意框图；

图7为本申请实施例提供的一种承载网时延链路确定方法的流程示意图；

图8为本申请实施例提供的一种电子设备的结构示意图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

为了便于清楚描述本申请实施例的技术方案，在本申请的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。例如，第一设备和第二设备仅仅是为了区分不同的设备，并不对其先后顺序进行限定。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。

需要说明的是，本申请中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b，或c中的至少一项(个)，可以表示：a，b，c，a-b，a-c，b-c，或a-b-c，其中a，b，c可以是单个，也可以是多个。

下面结合附图对本申请实施例进行介绍。图1为本申请实施例提供的一种应用场景示意图，本申请提供的一种承载网时延链路确定系统可以应用于如图1所示的应用场景中。该应用场景包括：第一终端设备101、控制器102和第二终端设备103，具体的，基于客户对时延等网络资源的严苛要求，各运营商开放IP承载网的时延保障能力给用户，当第一终端设备101向其他区域内的第二终端设备103发送视频通话业务时，相应的，控制器102可以基于第一终端设备101发送的视频通话业务确定相应的符合用户需求的传输链路，如传输链路有节点1-节点2-节点3或节点1-节点3，基于每一链路对应的时延数据选择适合视频通话业务的传输链路，并且还可以将每一链路对应的时延数据通过第二终端设备103显示给用户查看，并提供给用户每一链路对应的时延数据调速、查询等能力。

需要说明的是，可以将每一链路对应的时延数据通过第一终端设备101显示给对应的用户查看并提供相应的能力，用户即客户，本申请实施例对此不作具体限定。

可以理解的是，传输链路的可能性有多种，本申请实施例对传输链路包含的传输节点的数量不作具体限定，以上仅是实例说明。

上述终端设备可以是无线终端也可以是有线终端。无线终端可以是指向用户提供语音和/或其他业务数据连通性的设备，具有无线连接功能的手持式设备、或连接到无线调制解调器的其他处理设备。无线终端可以经无线接入网(Radio Access Network，简称RAN)与一个或多个核心网设备进行通信，无线终端可以是移动终端，如移动电话(或称为“蜂窝”电话)和具有移动终端的计算机，例如，可以是便携式、袖珍式、手持式、计算机内置的或者车载的移动装置，它们与无线接入网交换语言和/或数据。再例如，无线终端还可以是个人通信业务(Personal Communication Service，简称PCS)电话、无绳电话、会话发起协议(Session Initiation Protocol，简称SIP)话机、无线本地环路(Wireless Local Loop，简称WLL)站、个人数字助理(Personal Digital Assistant，简称PDA)等设备。无线终端也可以称为系统、订户单元(Subscriber Unit)、订户站(Subscriber Station)，移动站(MobileStation)、移动台(Mobile)、远程站(Remote Station)、远程终端(Remote Terminal)、接入终端(Access Terminal)、用户终端(User Terminal)、用户代理(User Agent)、用户设备(User Device or User Equipment)，在此不作限定。可选的，上述终端设备还可以是智能手表、平板电脑等设备。

现有技术中，运营商IP承载网骨干节点间的组网链路，由不一致的长、短时延路径形成，针对不同业务，通过手工配置在对应时延路径的方式，满足不同业务的需求。而传统的IP报文转发需要基于负载均衡转发，由于现有哈希算法中没有时延因素，只是考虑了负载分担因素，导致高优先级业务存在时延无法保障的情况。

示例性的，图2为一种业务转发路径示意图；如图2所示，由运营商IP承载网内骨干节点构成的组网链路，为保证主备路由的可靠及安全性，主备平面物理路由不一致形成长短时延路径组成。由A节点向B节点传输业务时，包括低时延路径和长时延路径，均可满足业务转发需求，但是，当时延敏感性客户的转发路径承载在长时延路径上，而普通性客户的转发路径承载在短时延路径上，会对客户造成业务影响。

目前针对有特殊时延要求的客户，可以通过手工配置在低时延路径的方式，满足客户的低时延要求，而确定低时延路径，需要基于承载网链路时延的采集技术，通过边界网关链路状态搜集协议(Border Gateway Protocol-Link state，BGP-LS)，结合双向主动测量协议(Tow-Way Active Measurement Pootocol，TWAMP)协议，基于中间系统到中间系统的路由选择协议(Intermediate System to Intermediate System Routing Protocol，IS-IS)并上报承载网中各链路段时延，进而确定并配置低时延路径。

但是，人工调整的手工配置方法，需要先手工收集各层网络中的链路时延，再估算出符合业务时延要求的路由，再把业务配置在对应路由中，效率低且操作复杂，存在影响业务的风险。

需要说明的是，在手工配置低时延路径之前，还需要通过PING侧等手段判断符合业务需求的路径，即通过用户输入PING指令，在收到一个节点回复的响应后，才可以获取两个节点间的时延数据，使得调整效率大大降低且增加了调整的复杂度。

因此，本申请实施例提供一种承载网时延链路确定系统，可以应用在IP无线电接入网(IP Radio Access Network，IPRAN)、智能城域网、云骨干承载网等支持第六代因特网协议的段路由(Segment Routing Internet Protocol Version 6，SRv6)策略(Policy)技术的承载网络中，可以基于业务需求自动估算出用户到云池的端到端的时延，进而选择可以满足业务需求对应时延要求的传输链路。

示例性的，图3为本申请实施例提供的一种承载网时延链路确定系统的架构示意图；如图3所示，所述承载网时延链路确定系统包括：应用层、协同层、控制层和云网层；

具体的，协同层，用于接收应用层下发的业务传输请求，并将所述业务传输请求发送给控制层；

控制层，用于接收协同层发送的所述业务传输请求，基于所述业务传输请求调用云网层内互联网协议地址IP承载网中所有链路对应的时延数据，并基于所述业务传输请求和所述时延数据确定传输链路，其中，所述IP承载网包括本地承载网和云骨干承载网，控制层与云网层内的云骨干承载网建立第六代因特网协议的段路由SRv6策略以及边界网关链路状态搜集协议BGP-LS连接，用于下发业务路径和收集时延数据。

其中，应用层包含终端设备中的应用程序(Application，APP)、服务器开通系统等，终端设备中的APP可以用于接收用户输入的业务请求，如视频聊天、直播等业务请求，还可以按需定制开发，例如提供业务时延检测能力、时延可调整能力等给客户，便于客户实时了解每一链路的传输状态；服务器开通系统可以用于对接基站子系统(Base StationSubsystem，BSS)侧业务需求，即接收用户输入的业务需求，如业务开通、拆机、调速、查询等业务需求。

协同层包含云网协同器，基于应用层下发的业务传输请求调用承载网以及云资源池对应的控制器，实现本地承载网和云骨干承载网两侧数据的协同。需要说明的是，协同层需要支持SRv6 Policy(即SRv6策略)等功能，从而具备获取时延数据的功能，用于反馈到应用层供用户查看。

控制层包含承载网控制器、云资源池控制器等，用于向下直接收集云网层内设备层级的时延数据、网络层数据等，如IP承载网中所有链路对应的时延数据，并进行封装向上提供给协同层。

具体的，控制层中的控制器通过Netconf&SNMP&Telemetry等南向采集协议，对IP承载网中所有链路进行纳管和还原网络拓扑，用于进行自动下发或采集数据。其中，控制器通过与骨干承载网之间建立BGP-LS第六代因特网协议(Internet Protocol Version 6，IPv6)邻居，用于收集网络拓扑、链路带宽、时延数据等信息，控制器与承载网设备之间建立边界网关协议(Border Gateway Protocol，BGP)段路由(Segment Routing，SR)策略(Policy)邻居，用于业务的下发，即基于传输链路进行业务转发。

云网层包含业务接入点、各个层级的IP承载网、云资源池等，可以用于收集网络侧的基础数据并向控制层提供所述基础数据，所述基础数据包括本地承载网和云骨干承载网内各个链路的时延数据、链路状态、每一链路包含的节点信息等，本层级还可承接控制层的业务调度需求，即将业务进行转发。

示例性的，在图1的应用场景下，控制器102可以接收协同层发送的第一终端设备101发送的视频通话业务，并基于该视频通话业务调用云网层内本地承载网以及云资源池(云骨干承载网)内所有链路对应的时延数据，并基于该视频通话业务和云网层内的时延数据确定符合该视频通话业务的传输链路，进而进行视频通话业务的转发，即通过确定的传输链路将第一终端设备101发送的视频通话业务转发至其他区域内的第二终端设备103中。

因此，本申请实施例提供的承载网时延链路确定系统，可以通过协同层接收应用层下发的业务传输请求，并将业务传输请求发送给控制层；进一步，控制层接收协同层发送的业务传输请求，并基于业务传输请求调用云网层内本地承载网和云骨干承载网中所有链路对应的时延数据，进一步的，控制层基于业务传输请求和时延数据确定传输链路，其中，控制层与云网层内的云骨干承载网建立SRv6策略以及边界网关链路状态搜集协议BGP-LS连接，用于下发业务路径和收集时延数据。这样，本申请可以适用于多域IP承载网的时延检测，即可以获取本地承载网和云骨干承载网内每一链路对应的时延数据，进而匹配出符合业务需求的传输链路，可以提高业务传输效率，且减少人工参与，提升业务传输准确性。

可选的，所述控制层基于所述业务传输请求调用云网层内IP承载网中所有链路对应的时延数据，包括：

判断所述业务传输请求在云网层内对应的承载网的类型；

若所述承载网的类型为本地承载网未部署所述SRv6策略但云骨干承载网部署所述SRv6策略，则调用云网层内本地承载网内创建的虚链路对应的时延数据与云骨干承载网内的链路对应的时延数据；

若所述承载网的类型为本地承载网部署所述SRv6策略和云骨干承载网部署所述SRv6策略，则调用云网层内本地承载网和云骨干承载网内的链路对应的时延数据。

本申请实施例中，IP承载网需要升级并部署SRv6 Policy技术转发能力，才可以自动获取每一链路对应的时延数据，其中，IP承载网中的本地承载网可选择支持部署SRv6Policy技术，也可以不支持部署SRv6 Policy技术，但必须部署双栈支持IPV6报文转发技术，即具备业务转发的能力。结合各运营商内本地承载网现状进行分析，云网层分为2种部署方案，一种是仅云骨干承载网部署SRv6策略但本地承载网未部署SRv6策略的方案，另一种为云骨干承载网及本地承载网均部署SRv6策略的方案，即通过判断业务传输请求在云网层内对应的承载网的类型来获取云骨干承载网内的链路对应的时延数据。

示例性的，云骨干承载网部署SRv6策略但本地承载网未部署SRv6策略的方案，可以以IPRAN承载网为例进行描述，图4为本申请实施例提供的一种基于IPRAN承载网的管控层示意框图；如图4所示，在IPRAN承载网内，由于没有未部署SRv6策略，故用户端设备(Customer Premise Equipment，CPE)和网上运营商边缘路由器(Provider Edge，PE)建立BGP SRv6 Policy虚连接，用于业务转发。其中，控制器基于Netconf&SNMP&Telemetry等南向采集协议收集IPRAN承载网内城域接入路由器(Metro Access Router，MAR)、城域边缘路由器(Metro Edge Router，MER)、城域核心路由器(Metro Core Router，MCR)内的时延数据。进一步的，由于云骨干承载网部署SRv6策略，故控制器基于Netconf&SNMP&Telemetry等南向采集协议可以自动收集云骨干承载网内网上运营商边缘路由器(Provider Edge，PE)、运营商骨干路由器(P)、云上运营商边缘路由器(Provider Edge，PE)内的时延数据。

需要说明的是，路由反射器(RR)用于将从内部边界网关协议(Internal BorderGateway Protocol，IBGP)邻居获得的路由发射给自己的所有IBGP邻居，RR和所有的路由之间建立IBGP邻居，可以收集网络拓扑、链路带宽、时延数据等。其中，控制器与骨干承载网RR之间建立BGP-LS IPv6邻居，骨干承载网RR与CPE之间也建立BGP-LS IPv6邻居。

云骨干承载网及本地承载网均部署SRv6的方案，可以以智能城域网为例进行描述，图5为本申请实施例提供的一种基于智能城域网的管控层示意框图；如图5所示，由于智能城域网和云骨干承载网均部署SRv6策略，则控制器基于Netconf&SNMP&Telemetry等南向采集协议可以收集CPE、MAR、MER、MCR、网PE、云PE、P内的时延数据，其中，每一路由器之间均建立BGP-LS IPv6邻居。

其中，控制器运行BGP-LS协议，采集全网链路时延数据，支持端到端完整的时延拓扑搜集、SRv6 Policy的E2E业务差异化承载、iFIT质量检测能力，并上报链路时延数据给控制层。

需要说明的是，上述承载网的类型的分类结合各运营商本地承载网现状进行分析，分为了2种部署方案，若存在其他部署情况，可支持时延数据的自动采集，也适用于本申请，本申请实施例对承载网对应的各种情况不作具体限定。

因此，本申请实施例可以基于云网层内承载网对应的不同情况，有相应的采集时延数据的方式，适用于多域IP承载网的时延保障方案，适用于部分支持或者全部支持SRv6技术的承载网络，提高收集时延数据的灵活性，适用多种情况。

可选的，所述控制层调用云网层内本地承载网内创建的虚链路对应的时延数据与云骨干承载网内的链路对应的时延数据，包括：

基于所述本地承载网内创建的虚链路的双向主动测量协议Twamp采集实例，调用所述虚链路对应的时延数据；所述虚链路为提前预设好的包括至少一个节点的虚拟链路；

调用所述云骨干承载网内的链路对应的时延数据。

本申请实施例中，因运营商现网IPRAN设备不支持BGP-LS技术，无法采集各网络中链路的时延数据，因此采用创建客户CPE到网PE的SRv6Policy虚链路，部署正反双向的时延、链路可用度等属性，从而支持端到端(End to End，E2E)的时延地图、时延算路等SRv6Policy功能，进而可以收集本地承载网内创建的虚链路对应的时延数据。

其中，虚链路为提前预设好的包括至少一个节点的虚拟链路，可以为基于大量试验人为确定的虚拟链路，也可以为基于系统设定好的虚拟链路，本申请实施例对虚链路的设定以及虚链路内包括的节点数量不做具体限定，所述节点为转发报文的中转节点，如路由器。

需要说明的是，IPRAN网络需要升级第四代因特网协议(Internet ProtocolVersion 4，IPv4)/IPv6双栈，才能支持SRv6封装报文的公网IPv6报文转发功能。

具体的，在本地承载网内，控制器可以通过创建内部网关协议(Interior GatewayProtocols，IGP)链路(Link)的双向主动测量协议Twamp采集实例，用于收集IGP Link时延数据，而在骨干承载网内，控制器可以直接调用每一链路对应的时延数据。

因此，本申请实施例可以通过对未部署SRv6策略的承载网内创建虚链路中的方式，使得控制器可以调用本地承载网内链路对应的时延数据，扩大适用范围，使得承载网内不部署SRv6策略的场景也可以适用于本申请。

可选的，所述控制层基于所述业务传输请求和所述时延数据确定传输链路，包括：

基于所述业务传输请求确定所述业务传输请求对应的时延需求；

针对每一链路，基于链路中至少一个节点对应的时延数据利用预定义算法计算该链路对应的时延；

在计算得到的所有链路对应的时延中查找满足所述时延需求对应的传输链路。

本申请实施例中，预定义算法可以是设定的用于计算每一链路对应的最终所需时延的算法，例如加权算法，在每一链路中，包括至少一个节点，每两个节点之间传输对应有时延数据与相应的权重值，通过计算链路中所有节点与节点之间时延数据与权重值的乘积之和，得到链路对应的时延，如某一链路包括节点1-节点2-节点3，节点1与节点2之间时延数据为0.5s、权重值为0.6，节点2与节点3之间时延数据为1s、权重值为0.4，则该链路对应时延为0.5*0.6+1*0.4＝0.7s。

需要说明的是，本申请实施例对预定义算法不作具体限定，以上仅是示例说明，其可以为其他适用于计算链路时延的任意算法。

示例性的，在图1的应用场景下，当第一终端设备101向其他区域内的第二终端设备103发送视频通话业务，有两条链路节点1-节点2-节点3和节点1-节点3可供选择，节点1与节点2之间时延数据为0.5s、权重值为0.6，节点2与节点3之间时延数据为1s、权重值为0.4，节点1与节点3之间时延数据为1.5s，则控制器102基于视频通话业务确定对应的时延需求为0.8s，则利用加权算法计算得到节点1-节点2-节点3对应的时延为0.7s，节点1与节点3对应的时延为1.5s，则可以确定满足时延需求对应的传输链路为节点1-节点2-节点3。

可以理解的是，本申请通过分段采集不同层级承载网络的时延信息，结合客户接入端、入云池端点，即节点，可计算出符合特定时延需求的网络路径，精确匹配医疗云等有确定时延要求的业务需求。

因此，本申请实施例可以利用预定义算法计算链路时延，进而查找符合业务需求的传输链路，提高确定链路的准确性。

可选的，所述控制层还用于：

若查找到满足所述时延需求对应的传输链路有多条，则根据每一传输链路被使用的次数计算多条传输链路的利用率；

选取多条传输链路的利用率中最小值对应的传输链路。

本申请实施例中，利用率可以用于确定传输链路的使用频率或所使用的带宽率，通过利用率的大小可以选取空闲或带宽较多的链路进行数据传输，提高传输的速率，保证带宽的有效利用。

示例性的，在图1的应用场景下，当第一终端设备101向其他区域内的第二终端设备103发送视频通话业务，若确定有两条链路节点1-节点2-节点3和节点1-节点3均满足对应的时延需求，则通过计算上述两条传输链路被使用的次数计算多条传输链路的利用率，如节点1-节点2-节点3对应的利用率为50％，节点1与节点3对应的利用率为80％，则选取传输链路为节点1-节点2-节点3。

需要说明的是，选取多条传输链路的利用率中最小值作为传输链路为一种可选方案，也可以通过其他方式确定传输链路，如选取利用率位于预设区间内的作为传输链路，选取利用率最大值对应的传输链路，使得传输链路在得到充分利用后，再选取其他链路，由于传输链路利用率高，还可以减少意外链路的发生，经常使用的链路不容易发生故障。

因此，本申请实施例可以通过计算每一传输链路的利用率，查找符合业务场景的传输链路，如业务场景的目的为了提高传输速率，则可以选取多条传输链路的利用率中最小值对应的传输链路。

可选的，所述控制层还用于：

获取所述IP承载网内每一条链路中对应的节点信息和链路状态；

判断每一条链路对应的时延数据和\或利用率是否满足预设要求，

若不满足，则基于对应链路的中对应的节点信息、链路状态、时延数据以及业务传输请求创建告警信息，并发送至应用层进行可视化显示，以供用户进行查看。

本申请实施例中，预设要求可以指的是利用率超过预设阈值和\或时延数据较上一周期发生变化等，本申请实施例对预设要求不作具体限定，其是为了判断链路有无发生异常设定的条件；节点信息可以指的是链路对应节点数量以及节点的基本信息等，如多个不同路由的位置信息、名称信息等，链路状态可以指的是链路的连接状态，告警信息可以用于指示链发生异常或发生变化而发送的提示信息，可以以短信的形式、也可以显示框的形式发送到用户的终端设备上进行显示，本申请实施例对告警信息的发送形式和内容不作具体限定。

具体的，本申请实施例可以提供业务监控、链路质量实时监测的运维能力给用户，通过控制器判断链路是否满足预设要求，若不满足则生成告警信息，通过协同层将告警信息发送到应用层进行可视化显示，如生成的告警信息为“业务请求1在利用传输链路2进行传输时，节点1-节点2连接发生异常，无法进行传输”，将该告警信息以显示框的形式发送至应用层中对应终端设备中的某个APP中，以供用户进行查看。

可以理解的是，在传输业务时，某个链路发生异常后，系统会自动选择其他符合需求的链路进行业务传输，若某个链路发生变化后，不影响业务传输，则系统会发送相应的告警信息以提示用户发生变化，并不会改变链路进行业务传输。

因此，本申请实施例可以向用户开放监测功能，在业务运营过程，可以实时感知业务时延情况，当发送网络故障时，可以实时查看业务时延变化情况，在链路发生异常或改变都可以通知用户，提高便利性，方便用户随时了解情况。

可选的，所述协同层接收应用层下发的业务传输请求，包括：

获取用户在应用层输入的业务传输请求；所述业务传输请求包括业务开通、业务查询、业务调速、业务取消；

其中，所述业务开通用于为用户提供开通系统检测每一链路对应时延数据的能力；所述业务查询用于为用户提供查询每一链路对应时延数据的能力；所述业务调速用于为用户提供调整每一链路对应时延数据的能力；所述业务取消用于为用户提供取消关闭每一链路对应时延数据的能力。

本申请实施例中，协同层可以接收上层外部应用的需求，提供售前、售中、售后三大类场景的网络时延可视可调能力，以及租户电路监控性能数据可查询能力，具体的，协同层通过接收上层外部系统的业务工单，对网络控制器、云控制器下发负荷要求的端到端电路，对外提供网络时延可视可调能力、业务时延检测能力等，包括业务开通能力、业务查询能力、业务调速能力、业务取消能力等。

需要说明的是，控制层需要具备下发SRv6 Policy隧道的功能，且本申请可以基于现有承载网络与网络技术，将承载网时延检测等网络能力转换为业务产品，如转换为其他业务需求，提供行业内差异化服务的增值能力。

可以理解的是，本申请通过软件开发即可实现上述能力，且扩展性好，可以满足医疗云、游戏等要求确定性时延、网络资源等可视可调的业务需求。

结合上述实施例，图6为本申请实施例提供的一种完整的承载网时延链路确定系统的功能示意框图；如图6所示，云网层可以包含业务接入点、IP承载网以及云资源池，本层级可以基于控制层提供业务的基础转发能力，为控制层提供网络侧的基础数据，并承接控制层的业务调度需求，进一步的，控制层包含承载网控制器和云资源池控制器，本层级向云网层直接收集设备层级的时延等数据，采集网络层数据，并封装为北向接口能力向上提供给协同层，还可以对外提供网络告警、性能、存量、配置等功能，通过事件通知消息告知用户，所述事件通知消息包括设备信息、链路信息、业务状态信息以及路径数据等；协同层包含云网协同器，本层级向下调用承载网控制器、云资源池控制器的接口能力，实现云网两侧数据的协同，并基于应用层的外部应用的需求，收集电路监控性能数据反馈给应用层；应用层包含前端APP、服务器开通系统，前端APP可以按需定制开发，例如提供业务时延检测能力给客户，提供时延可调整能力给客户；服务器开通系统可以对接BSS侧业务需求，接收业务开通、拆机、调速、查询等业务需求，应用层通过前端APP等应用，可实现业务监控能力，监测时延、抖动、丢包等指标，当指标超过设定的阈值，可实时上报异常告警。

综上所述，本申请实施例基于多个组件共同实现承载网时延可视可调、租户级监控维护等能力，以及可通过前端应用层提供专线增值服务能力。

需要说明的是，本申请实施例可以应用于政务网、医疗云、教育行业、中小企业等入云业务，可以满足确定性时延、网络资源可视可调、多点入多云、海量节点敏捷部署开通等需求。

可选的，本申请还提供一种承载网时延链路确定方法，图7为本申请实施例提供的一种承载网时延链路确定方法的流程示意图，如图7所示，所述承载网时延链路确定方法包括以下步骤：

S701、接收协同层发送的应用层下发的业务传输请求，并基于所述业务传输请求调用云网层内互联网协议地址IP承载网中所有链路对应的时延数据。

S702、基于所述业务传输请求和所述时延数据确定传输链路，其中，所述IP承载网包括本地承载网和云骨干承载网，控制层与云网层内的云骨干承载网建立第六代因特网协议的段路由SRv6策略以及边界网关链路状态搜集协议BGP-LS连接，用于下发业务路径和收集时延数据。

本申请实施例提供的承载网时延链路确定方法的具体实现原理和效果可以参见上述实施例对应的相关描述和效果，此处不做过多赘述。

本申请实施例还提供了一种电子设备的结构示意图，图8为本申请实施例提供的一种电子设备的结构示意图，如图8所示，该电子设备可以包括：处理器801以及与所述处理器通信连接的存储器802；该存储器802存储计算机程序；该处理器801执行该存储器802存储的计算机程序，使得该处理器801执行上述任一实施例所述的方法。

其中，存储器802和处理器801可以通过总线803连接。

本申请实施例还提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序执行指令，计算机执行指令被处理器执行时用于实现如本申请前述任一实施例中的所述的方法。

本申请实施例还提供了一种运行指令的芯片，该芯片用于执行如本申请前述任一实施例中由电子设备所执行的前述任一实施例中所述的方法。

本申请实施例还提供了一种计算机程序产品，该程序产品包括计算机程序，该计算机程序被处理器执行时可实现如本申请前述任一实施例中由电子设备所执行的前述任一实施例中所述的方法。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案。

另外，在本申请各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个单元中。上述模块成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器执行本申请各个实施例所述方法的部分步骤。

应理解，上述处理器可以是中央处理单元(Central Processing Unit，简称CPU)，还可以是其它通用处理器、数字信号处理器(Digital Signal Processor，简称DSP)、专用集成电路(Application Specific Integrated Circuit，简称ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合申请所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器可能包含高速随机存取存储器(Random Access memory，简称RAM)，也可能还包括非不稳定的存储器(Non-volatile Memory，简称NVM)，例如至少一个磁盘存储器，还可以为U盘、移动硬盘、只读存储器、磁盘或光盘等。

总线可以是工业标准体系结构(Industry Standard Architecture，简称ISA)总线、外部设备互连(Peripheral Component Interconnect，简称PCI)总线或扩展工业标准体系结构(Extended Industry Standard Architecture，简称EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。

上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(Static Random-Access Memory，简称SRAM)，电可擦除可编程只读存储器(Electrically Erasable Programmable Read Only Memory，简称EEPROM)，可擦除可编程只读存储器(Erasable Programmable Read-Only Memory，简称EPROM)，可编程只读存储器(Programmable Read-Only Memory，简称PROM)，只读存储器(Read-OnlyMemory，简称ROM)，磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。

一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于专用集成电路(Application Specific Integrated Circuits，简称ASIC)中。当然，处理器和存储介质也可以作为分立组件存在于电子设备或主控设备中。

以上所述，仅为本申请实施例的具体实施方式，但本申请实施例的保护范围并不局限于此，任何在本申请实施例揭露的技术范围内的变化或替换，都应涵盖在本申请实施例的保护范围之内。因此，本申请实施例的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种承载网时延链路确定系统，其特征在于，所述系统包括：

协同层，用于接收应用层下发的业务传输请求，并将所述业务传输请求发送给控制层；

控制层，用于接收协同层发送的所述业务传输请求，基于所述业务传输请求调用云网层内互联网协议地址IP承载网中所有链路对应的时延数据，并基于所述业务传输请求和所述时延数据确定传输链路，其中，所述IP承载网包括本地承载网和云骨干承载网，控制层与云网层内的云骨干承载网建立第六代因特网协议的段路由SRv6策略以及边界网关链路状态搜集协议BGP-LS连接，用于下发业务路径和收集时延数据。

2.根据权利要求1所述的系统，其特征在于，所述控制层基于所述业务传输请求调用云网层内IP承载网中所有链路对应的时延数据，包括：

判断所述业务传输请求在云网层内对应的承载网的类型；

若所述承载网的类型为本地承载网未部署所述SRv6策略但云骨干承载网部署所述SRv6策略，则调用云网层内本地承载网内创建的虚链路对应的时延数据与云骨干承载网内的链路对应的时延数据；

若所述承载网的类型为本地承载网部署所述SRv6策略和云骨干承载网部署所述SRv6策略，则调用云网层内本地承载网和云骨干承载网内的链路对应的时延数据。

3.根据权利要求2所述的系统，其特征在于，所述控制层调用云网层内本地承载网内创建的虚链路对应的时延数据与云骨干承载网内的链路对应的时延数据，包括：

基于所述本地承载网内创建的虚链路的双向主动测量协议Twamp采集实例，调用所述虚链路对应的时延数据；所述虚链路为提前预设好的包括至少一个节点的虚拟链路；

调用所述云骨干承载网内的链路对应的时延数据。

4.根据权利要求1所述的系统，其特征在于，所述控制层基于所述业务传输请求和所述时延数据确定传输链路，包括：

基于所述业务传输请求确定所述业务传输请求对应的时延需求；

针对每一链路，基于链路中至少一个节点对应的时延数据利用预定义算法计算该链路对应的时延；

在计算得到的所有链路对应的时延中查找满足所述时延需求对应的传输链路。

5.根据权利要求4所述的系统，其特征在于，所述控制层还用于：

若查找到满足所述时延需求对应的传输链路有多条，则根据每一传输链路被使用的次数计算多条传输链路的利用率；

选取多条传输链路的利用率中最小值对应的传输链路。

6.根据权利要求1所述的系统，其特征在于，所述控制层还用于：

获取所述IP承载网内每一条链路中对应的节点信息和链路状态；

判断每一条链路对应的时延数据和\或利用率是否满足预设要求，

若不满足，则基于对应链路的中对应的节点信息、链路状态、时延数据以及业务传输请求创建告警信息，并发送至应用层进行可视化显示，以供用户进行查看。

7.根据权利要求1-6任一项所述的系统，其特征在于，所述协同层接收应用层下发的业务传输请求，包括：

获取用户在应用层输入的业务传输请求；所述业务传输请求包括业务开通、业务查询、业务调速、业务取消；

其中，所述业务开通用于为用户提供开通系统检测每一链路对应时延数据的能力；所述业务查询用于为用户提供查询每一链路对应时延数据的能力；所述业务调速用于为用户提供调整每一链路对应时延数据的能力；所述业务取消用于为用户提供取消关闭每一链路对应时延数据的能力。

8.一种承载网时延链路确定方法，其特征在于，所述方法包括：

接收协同层发送的应用层下发的业务传输请求，并基于所述业务传输请求调用云网层内互联网协议地址IP承载网中所有链路对应的时延数据；

基于所述业务传输请求和所述时延数据确定传输链路，其中，所述IP承载网包括本地承载网和云骨干承载网，控制层与云网层内的云骨干承载网建立第六代因特网协议的段路由SRv6策略以及边界网关链路状态搜集协议连接，用于下发业务路径和收集时延数据。

9.一种电子设备，其特征在于，包括：处理器，存储器以及计算机程序；其中，所述计算机程序被存储在所述存储器中，并且被配置为由所述处理器执行，所述计算机程序包括用于执行如权利要求8所述的承载网时延链路确定方法的指令。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如权利要求8所述的承载网时延链路确定方法。

Images