CN107659424A - 一种业务隧道抢通方法及网管平台 - Google Patents

Abstract

本发明实施例提供一种业务隧道抢通方法及网管平台，网管平台对获取的故障链路信息进行自动分析以获取到需要抢通的隧道作为待抢通隧道，并自动为各待抢通隧道分配临时隧道，然后将待抢通隧道的上的业务移动到临时隧道上运行；通过网管平台自动确定待抢通隧道、同时自动为待抢通隧道计算分配新的路由，然后让待抢通隧道上的业务根据新配置的路由来运行，减少了整个抢通过程中人力的参与，降低了对人力资源的耗费，有利于实现资源的优化配置。

Description

一种业务隧道抢通方法及网管平台

技术领域

本发明涉及通讯技术领域，尤其涉及一种业务隧道抢通方法及网管平台。

背景技术

在通讯过程中，通信信息从起始地址传输至目的地址离不开网络中各个网元与通信线缆间相互配合，在传输过程当中，通信信息可能会经过多个网元及这多个网元之间的传输线缆组成的传输路由之后才会达到目的地。因此，为了保证通信信息经过事先规划的传输路由到达目的地，所以必须保证传输路由中的各个网元及网元之间的通信线缆处于正常工作状态，一旦传输路由中间的任意一个网元或者是传输路由中的任意一段线缆出现故障，都会导致通信信息无法到达目的地，自然也不能为用户提供正常的业务服务。

当今社会城市化的步伐正在加快，在城市发展的过程中，不可避免的会遇到很多人为因素或者自然因素应发的应急状况，例如传输通信信息的光缆因为自然原因或者是被挖断、基站掉电、网络设备故障等，这些应急状况都会导致业务中断，特别是当网络中的核心节点故障的时候，会引发大面积的业务中断。为了避免上述人为因素或者是自然因素影响到用户的正常生活，需要针对这些应急事故给出相应的应对预案。

针对因为无法按照预先规划的路由到达目的地的业务，普遍的做法就是为其配置新的路由，让新配置的路由绕过网络中的故障设备或者故障链路后达到目的地。但是现有的做法通常是由网络管理人员在确定网络中的故障链路之后，分析哪些业务会受到影响，然后对这些在链路故障的情况下无法根据预先规划的路由达到目的地的业务手动路由修改。如果当前出现故障的链路影响范围并不广泛，则这种手动修改的方式还能应对，但是如果是核心设备故障而导致了核心链路出现故障，则大量的业务都会处于中断状态，这时候，如果继续采用手动配置新路由的做法就会显得不现实了。一方面，由于需要配置新路由的业务是大批量的，所以手动配置对人力资源的要求太高，另一方面，由于手动配置新路由的做法耗时太长，无法满足快速业务恢复的要求。因此为了将对用户的影响降到最低，所以需要提供一些更有效率的业务恢复方案。

发明内容

本发明实施例提供的业务隧道抢通方法及网管平台，主要解决的技术问题是：解决现有技术中只能通过手动方式对受到故障链路影响的业务进行路由修改或重新配置的方式来保证业务恢复的做法而导致的人力资源消耗大的问题。

为解决上述技术问题，本发明实施例提供一种业务隧道抢通方法，包括：

网管平台获取故障链路信息，所述故障链路信息中包括当前处于故障状态的链路的标识信息；

所述网管平台对故障链路上的各隧道及各所述隧道承载的业务进行分析以确定待抢通隧道，所述待抢通隧道为确定需要进行抢通的隧道；

所述网管平台为各所述待抢通隧道确定对应的临时隧道，所述临时隧道用于在所述故障链路回复正常之前承载所述待抢通隧道上的业务；

所述网管平台将所述待抢通隧道上的业务移至所述临时隧道上传输。

本发明实施例还提供一种网管平台，包括：

获取模块，用于获取故障链路信息，所述故障链路信息中包括当前处于故障状态的链路的标识信息；

分析模块，用于对故障链路上的各隧道及各所述隧道承载的业务进行分析以确定待抢通隧道，所述待抢通隧道为确定需要进行抢通的隧道；

计算模块，用于为各所述待抢通隧道确定对应的临时隧道，所述临时隧道用于在所述故障链路回复正常之前承载所述待抢通隧道上的业务；

抢通模块，用于将所述待抢通隧道上的业务移至所述临时隧道上传输。

本发明实施例还提供一种计算机存储介质，所述计算机存储介质中存储有计算机可执行指令，所述计算机可执行指令用于执行前述的任一项的业务隧道抢通方法。

本发明的有益效果是：

根据本发明实施例提供的业务隧道抢通方法、网管平台以及计算机存储介质，网管平台对获取的故障链路信息进行自动分析以获取到需要抢通的隧道作为待抢通隧道，并自动为各待抢通隧道分配临时隧道，然后将待抢通隧道的上的业务移动到临时隧道上运行；通过网管平台自动确定待抢通隧道、同时自动为待抢通隧道计算分配新的路由，然后让待抢通隧道上的业务根据新配置的路由来运行，减少了整个抢通过程中人力的参与，降低了对人力资源的耗费。

附图说明

图1为本发明实施例一提供的业务隧道抢通方法的一种流程图；

图2为本发明实施例一中的一种网络拓扑结构图；

图3为本发明实施例一中的另一种网络拓扑结构图；

图4为本发明实施例二提供的网络平台的一种结构示意图；

图5为本发明实施例二提供的网络平台的另一种结构示意图；

图6为本发明实施例二提供的网络平台的又一种结构示意图；

图7为本发明实施例二提供的服务器的一种硬件结构示意图。

具体实施方式

下面通过具体实施方式结合附图对本发明实施例作进一步详细说明。

实施例一：

为了解决现有技术中只能通过手动方式对受到故障链路影响的业务进行路由修改或重新配置的方式来保证业务恢复的做法而导致人力资源消耗大的问题，本实施例提供一种业务隧道抢通方法，请参见图1：

S102、网管平台获取故障链路信息。

故障链路信息中包括当前处于故障状态的链路的标识信息，不同的链路具有不同的标识信息，这些标识信息可以通过任意可以唯一识别故障链路的字符或多个字符的组合来表示。网管平台在获取到故障链路信息之后，根据其中的故障链路标识信息确定当前哪些链路处于故障状态，同时根据故障链路的标识信息确定故障链路上的隧道和各个隧道承载的业务，以便进行后续分析。

本实施例中，网管平台获取的故障链路的信息可以是网管人员手动输入的信息，网管人员输入故障链路信息的来源可以是通过网络运维人员人力上报的故障信息确定的，例如，当前有网络运维人员上报基站A的供电设备处于故障状态，无法为基站A提供正常的供电了，因此，网关人员可以根据网络拓扑结构确定因为基站A处于故障状态而被影响的链路有哪些，并将这些链路都作为故障链路，将这些链路的标识信息输入到网管平台当中。

当然网管人员输入的故障链路信息也可以是其他设备自动检测得到的，例如，OAM(Operation Administration and Maintenance，操作-管理-维护)平台对网络中各链路进行实时监测得到的结果。OAM平台的链路监控功能主要用于在各种环境下检测和发现链路层故障，以太网OAM通过交互Event Notification OAM PDU(事件监控OAM分组数据单元)来监控链路：当一端OAM实体监控到一般链路事件(例如，错误信号事件、错误帧事件、错误帧周期事件、错误帧秒数事件)时，将向其对端发送Event Notification OAM PDU以进行通报，网管人员可以通过观察日志信息动态地掌握网络的状况。

本实施例的一种示例当中，可以直接由OAM平台将检测结果中故障链路的相关信息作为故障链路信息输入至网管平台当中，在OAM自动将故障链路信息输入至网关平台的情况下，可以减少对人力资源的耗费，减轻网络管理人员和网络运维人员的负担。但相对而言，由OAM平台检测出故障链路的相关信息之后，再由网管人员根据检测结果向网管平台输入故障链路信息的做法更准确。虽然由OAM直接将检测结果输入到网管平台的做法并不会遗漏任何信息，但是由于网络中的情况可能会比较复杂，例如有的网元设备或者是线缆可能本来就长期处于故障状态，这些故障的网元设备或者是故障的线缆并没有承载任何业务，自然也就不会影响到用户对业务的正常使用，因此，这些网元和线缆组成的链路可能是不需要进行抢修的。而如果直接由OAM平台输入检测结果的做法可能就会导致网管平台需要对这些链路也进行不必要的分析或者是抢修，占用了对其他更需要抢通的链路的抢通时间。

另外在确定故障链路的时候，如果出现故障的是网络拓扑结构中的某一个网元，如图2所示，在图2当中，网络拓扑结构中，网元设备H出现了故障，因此，将与网元设备H相关的链路l₁、l₂、l₃以及l₄都作为故障链路。

如果出现故障的是网络拓扑结构中的某一线缆，如图3所示，在图3中释出的l₆出现故障，则可以直接将l₆作为故障链路。

S104、网管平台对故障链路上的各隧道及各隧道承载的业务进行分析以确定待抢通隧道。

待抢通隧道，顾名思义，就是确定需要被抢通的隧道。在实际通信过程中，一条线缆，例如一根光纤，可能需要传输很多业务的业务数据，这主要是通过将一根光纤虚拟出多条传输隧道，每一个隧道有可能会承载一个或者多个业务。举个例子来说，这就类似于一条高速公路被划分成多个车道，每个车道上面会行驶着很多的车辆一样，只不过在通信领域中，一个“车道”上的“车辆”不会随便进入其他“车道”中，即一个隧道上运行的业务不会随便移动到其他隧道上运行。或者说，在通信领域中，链路上隧道的虚拟与实际生活中高速公路对于车道的划分还是有些不同的，我们假定，高速公路在划分车道的时候不再是按照快车道、慢车道、应急车道这种划分方式进行划分，因为每辆汽车的行驶速度是可以随机改变的，而汽车行驶速度的不同可能会汽车在不同的车道上进行切换，但是业务在隧道上传输的时候，并不会因为其他因素的改变的而改变，因此，这里举另外一个例子，在该例子当中，我们提出一种对高速公路车道进行划分的新方式——根据汽车的类型进行，将高速公路分为“小型汽车车道”、“中型汽车车道”及“大型汽车车道”，这样，一辆汽车一旦被划分成其中的某一种类型，就不会再发生改变了，在这种实力当中，高速公路类似于本实施例中的链路，而车道则相当于本实施例中的隧道，最后，汽车相当于本实施例中的业务。

对于公路车道而言，可以行驶不计其数的车辆，而对于一条隧道而言，同样也可以承载多个业务，但是对于运营商而言，为了便于对业务的管理，一般一条隧道上仅传输一个业务。

运营商在设置隧道的时候，可能有的隧道会有保护隧道用于在主用隧道(即前面所说的隧道)发生故障的时候，承载主用隧道上的业务，这种方式能够有效降低链路故障时业务中断的可能性，基于同样的理由，针对有的业务也可能设置对应的备用业务，备用业务与主用业务(即前面所说的业务)通过不同的隧道进行传输，一旦承载主用业务的隧道发生了故障，主用业务不能到达目的地，则可以由备用业务经由承载它的隧道到达目的地，这样也能够有效降低业务中断的可能性，提高用户体验。

在确定待抢通隧道的时候，本实施例中筛选出的是那些承载了至少一个当前无法达到目的路由的业务的隧道作为待抢通隧道，当前无法到达本地路由是指在链路故障的情况下，该业务无法达到目的地，会造成用户的业务中断的情况。因此，由于保护隧道与备用业务的设置，使得在确定待抢通隧道的时候，并不是仅仅考虑故障链路上的隧道，即故障链路上的隧道并不一定都是待抢通隧道，因为，故障链路上的某些隧道可能具有保护隧道，或者是故障链路上某些隧道承载的业务具有备用业务，而在该链路出现故障的时候，业务能够通过主用隧道的保护隧道达到目的地，或者是备用业务能够代替主用业务达到目的地继续为用户提供服务。故，在确定待抢通隧道的时候，需要根据各隧道以及隧道上承载的业务进行。下面以一些简单的例子对本实施例中满足作为待抢通隧道的条件的隧道进行说明：

如果故障链路X-X’上的某一条隧道A不具有保护隧道，而且该隧道A上承载了不具有备用业务的业务a，则该隧道A应当作为待抢通隧道，因为在链路X-X’恢复正常的之前，业务a都无法到达目的地为用户提供服务了。

如果故障链路X-X’上的某一条隧道B具有保护隧道B’，但是保护隧道B’也是在故障链路上，同时，隧道B上承载的业务b也不具有备用业务，这时候隧道B也应当列入待抢通隧道的行列中。虽然隧道B具有保护隧道B’，但由于即使是将隧道B上的业务都移动到保护隧道B’上，保护隧道B’也无法将这些业务传输到目的地为用户提供服务，所以，隧道B上依旧承载了无法到达目的路由的业务。不过可以理解的是，在本示例当中，隧道B的保护隧道B’虽然也是在故障链路之上，但这并能说明保护隧道B’处于故障链路X-X’，其也可能是在其他故障链路上。

如果故障链路X-X’上的某一条隧道C具有保护隧道C’，但是保护隧道C’也是在故障链路上，同时，隧道C上承载的业务c虽然具有备用业务c’，但是承载该备用业务c’的隧道D也处于故障状态，同时该隧道D并没有保护隧道，因此，此时隧道C上承载的业务c和隧道C’上承载的备用业务c’都没有办法到达目的地，因此隧道C也应当列入待抢通隧道的行列中。另外承载该备用业务c’的隧道D也应当作为待抢通隧道。

如果故障链路X-X’上的某一条隧道E具有保护隧道E’，但是保护隧道E’也是在故障链路上，同时，隧道E上承载的业务E虽然具有备用业务E’，但是承载该备用业务E’的隧道F也处于故障状态，同时该隧道F虽然具有保护隧道F’，但是该保护隧道F’所在的链路也处于故障状态下，这时隧道E应当列入待抢通隧道的行列中。另外承载该备用业务E’的隧道F也应当作为待抢通隧道。

S106、网管平台为各待抢通隧道确定对应的临时隧道。

临时隧道用于在故障链路回复正常之前承载待抢通隧道上的业务，临时隧道时可以在当前链路故障的情况下，可以将待抢通隧道上的业务传输至目的地的路由，在计算确定临时隧道的过程中，可以根据这样几种原则进行：

首先是路径最短原则，从在当前情况下可以将待抢通隧道上的业务从起始地址传输至目的地址的路由中选择路径最短的那一个作为该待抢通隧道对应的临时隧道，可以理解的是，当前情况下可以将待抢通隧道上的业务从起始地址传输至目的地址的路由可能会有多个，而本实施例中在选择临时隧道的时候，可以从所有这些路由中进行选择，也可以从这些路由中的部分里面进行选择。这种选择原则能够保证对待抢通隧道上的业务的传输速度最快，同时也能将承载待抢通隧道上的业务对网络带来的影响降到最低，因为，在路径最短原则下选择的临时隧道中所影响到的网元和传输线缆是最少的。

另外，还可以根据带宽最大原则进行选择，因为选择的临时隧道可能本身也会需要传输一些业务，因此，为了将待抢通隧道上的业务移动到该临时隧道上进行传输后会过多的影响到该临时隧道对其本来承载的业务，因此，本实施例中在选择临时隧道的时候，可以选择那些带宽较大的路由最为临时隧道，因为当临时隧道本身具备大的带宽的时候，其承载额外业务的传输时才会对原本业务的影响最小。

最后，还可以综合路径最短原则和带宽最大原则两种来进行临时隧道的选择，可以由用户预先为路径最短和带宽最大这两个原则设置对应的权重，由于路径因素中，路径越短越好，而在带宽因素当中，带宽越大越好，因此，如果直接将一条临时隧道的路径与带宽两个值与对应的权重值进行加权计算，可能不能得出正确的结果，因此，可以将路径或者带宽中的一个因素进行转换，以保证计算结果的正确性，例如，将带宽进行转换，让转换后的结果与选择优先级成反比，即转换后的结果越小，则被选择优先级越高。

由于需要确定临时隧道的待抢通隧道的数量可能较多，而网管平台又不可能在同一时间将所有待抢通隧道的临时隧道都计算出来，因此，在本实施例中，网管平台按照预设抢通策略为各待抢通隧道确定对应的临时隧道，在预设策略中可以包括各个待抢通隧道的优先级，让网管平台优先选择为优先级较高待抢通隧道计算临时隧道。在本实施例一些示例当中，待抢通隧道上承载的业务量越多，则优先级越高，而在本实施例中的另外一些示例当中，承载的业务越重要，则抢通隧道的优先级越高，例如，有的待抢通隧道上承载的可能是2G业务，有的承载的是3G或者4G业务，而由于2G业务会影响到用户的电话业务，因此，本实施例中规定承载着2G业务的待抢通隧道的优先级越高。在本实施例中的另外一些示例中，还可以将业务量与业务的重要性综合起来确定待抢通隧道的优先级，例如为业务量和业务的重要性分别设置权重，然后根据计算结果确定各个待抢通隧道的优先级。

在计算出临时隧道之后，可以将计算出来的记过向网管人员进行展示，如果网管人员对选择的临时隧道不满意，则可以输入新的限制条件，然后网管平台根据新的限制条件进行计算，直至得到令网管人员满意的临时隧道为止。

S108、网管平台将待抢通隧道上的业务移至临时隧道运行。

在计算出临时隧道，或者是计算出临时隧道并由网关人员进行确认之后，网管平台可以将各个待抢通隧道上的业务移动到对应的临时隧道上进行传输，本实施例中将这个过程称为“抢通”，和计算临时隧道一样，不可能将所有的待抢通隧道同时抢通，因为“抢通”过程实质上是配置数据的下发，而同时下发大量的配置数据容易导致数据下发失败，从而导致“抢通”失败。因此，“抢通”过程也可以分为多个批次，网管人员可以根据网络性能等因素的实际情况确定出每次抢通的待抢通隧道的数量。例如，如果网管人员下发的抢通数量为5，则网管平台每次抢通5条待抢通隧道。

另外，由于在抢通过程中，极有可能出现抢通失败的情况，因此，本实施例中，可以在实施抢通之前先将各个待抢通隧道的数据进行备份，一旦抢通失败，可以根据备份数据对待抢通隧道的数据进行恢复。在抢通失败后，可以让网管人员对抢通失败的原因进行分析后，对相关数据进行调整，然后重新执行抢通过程，本实施例中将该重新抢通的过程称为“重新抢通”。

在故障链路恢复正常之后，可以将临时隧道承载的那些原本属于待抢通隧道的业务重新切换至待抢通隧道上传输，本实施例中将这个切换过程称为“回退”。

不难看出，从链路故障到故障链路恢复的过程中，待抢通隧道会经历多个过程，处于多种状态。在本实施例中，为了便于网络管理人员查看待抢通隧道的抢通进程，可以在计算出临时隧道之后，针对每一条待抢通隧道制定一个抢通计划，然后通过表格的形式向网管人员展示抢通计划当前的进行以及对于该抢通计划当前可执行的操作。表1中示出的是本实施例中，一个抢通计划在各种状态变迁下可执行的操作：

表1

在该表中，纵列中记载的是一个抢通计划会经历的各种状态，而横坐标指的是在某一个状态下可以对抢通计划执行的操作，表征不能执行，而表示的是可以执行。下面对抢通计划经历的几个状态进行简要说明：

抢通成功：抢通成功指的是，针对待抢通隧道下发的配置数据下发成功，待抢通隧道的上的业务已经由临时隧道来承载了。在该状态下，当故障链路恢复正常之后，可以对该抢通计划执行手动回退，让临时隧道上承载的原本属于待抢通隧道的业务还是由待抢通隧道来承担。

抢通成功回退成功：该状态指的是待抢通隧道抢通成功之后，故障链路恢复正常后，将临时隧道上承担的“额外业务”回退到待抢通隧道上后的状态。

抢通失败自动回滚成功：抢通过程执行失败，但是根据备份数据自动回复到抢通之前的状态。

抢通失败自动回滚失败：抢通过程执行失败，且也没能根据备份数据自动回复到抢通之前的状态。

手工回退成功：待抢通隧道抢通之后，故障链路恢复，网管人员通过手动操作方式将临时隧道上承担的“额外业务”回退到待抢通隧道上成功的状态。

手工回退失败：待抢通隧道抢通之后，故障链路恢复，网管人员通过手动操作方式将临时隧道上承担的“额外业务”回退到待抢通隧道上失败的状态。

本发明实施例提供的业务隧道抢通方法中，网管平台对获取的故障链路信息进行自动分析以获取到需要抢通的隧道作为待抢通隧道，并自动为各待抢通隧道分配临时隧道，然后将待抢通隧道的上的业务移动到临时隧道上运行；通过网管平台自动确定待抢通隧道、同时自动为待抢通隧道计算分配新的路由，然后让待抢通隧道上的业务根据新配置的路由来运行，减少了整个抢通过程中人力的参与，降低了对人力资源的耗费。

实施例二：

本实施例提供一种网管平台，请参考图4：

网管平台40包括获取模块402、分析模块404、计算模块406以及抢通模块408。

获取模块402用于故障链路信息。故障链路信息中包括当前处于故障状态的链路的标识信息，不同的链路具有不同的标识信息，这些标识信息可以通过任意可以唯一识别故障链路的字符或多个字符的组合来表示。获取模块402在获取到故障链路信息之后，根据其中的故障链路标识信息确定当前哪些链路处于故障状态，同时根据故障链路的标识信息确定故障链路上的隧道和各个隧道承载的业务，以便分析模块404进行后续分析。

本实施例中，获取模块402获取的故障链路的信息可以是网管人员手动输入的信息，网管人员输入故障链路信息的来源可以是通过网络运维人员人力上报的故障信息确定的，例如，当前有网络运维人员上报基站A的供电设备处于故障状态，无法为基站A提供正常的供电了，因此，网关人员可以根据网络拓扑结构确定因为基站A处于故障状态而被影响的链路有哪些，并将这些链路都作为故障链路，将这些链路的标识信息输入到获取模块402当中。

当然网管人员输入的故障链路信息也可以是其他设备自动检测得到的，例如，OAM平台对网络中各链路进行实时监测得到的结果。OAM平台的链路监控功能主要用于在各种环境下检测和发现链路层故障，以太网OAM通过交互Event Notification OAM PDU来监控链路：当一端OAM实体监控到一般链路事件(例如，错误信号事件、错误帧事件、错误帧周期事件、错误帧秒数事件)时，将向其对端发送Event Notification OAM PDU以进行通报，网管人员可以通过观察日志信息动态地掌握网络的状况。

本实施例的一种示例当中，可以直接由OAM平台将检测结果中故障链路的相关信息作为故障链路信息输入至获取模块402当中，在OAM自动将故障链路信息输入至网关平台的情况下，可以减少对人力资源的耗费，减轻网络管理人员和网络运维人员的负担。但相对而言，由OAM平台检测出故障链路的相关信息之后，再由网管人员根据检测结果向网管平台输入故障链路信息的做法更准确。虽然由OAM直接将检测结果输入到网管平台的做法并不会遗漏任何信息，但是由于网络中的情况可能会比较复杂，例如有的网元设备或者是线缆可能本来就长期处于故障状态，这些故障的网元设备或者是故障的线缆并没有承载任何业务，自然也就不会影响到用户对业务的正常使用，因此，这些网元和线缆组成的链路可能是不需要进行抢修的。而如果直接由OAM平台输入检测结果的做法可能就会导致网管平台需要对这些链路也进行不必要的分析或者是抢修，占用了对其他更需要抢通的链路的抢通时间。

分析模块404用于障链路上的各隧道及各隧道承载的业务进行分析以确定待抢通隧道。

待抢通隧道，顾名思义，就是确定需要被抢通的隧道。在实际通信过程中，一条线缆，例如一根光纤，可能需要传输很多业务的业务数据，这主要是通过将一根光纤虚拟出多条传输隧道，每一个隧道有可能会承载一个或者多个业务。举个例子来说，这就类似于一条高速公路被划分成多个车道，每个车道上面会行驶着很多的车辆一样，只不过在通信领域中，一个“车道”上的“车辆”不会随便进入其他“车道”中，即一个隧道上运行的业务不会随便移动到其他隧道上运行。或者说，在通信领域中，链路上隧道的虚拟与实际生活中高速公路对于车道的划分还是有些不同的，我们假定，高速公路在划分车道的时候不再是按照快车道、慢车道、应急车道这种划分方式进行划分，因为每辆汽车的行驶速度是可以随机改变的，而汽车行驶速度的不同可能会汽车在不同的车道上进行切换，但是业务在隧道上传输的时候，并不会因为其他因素的改变的而改变，因此，这里举另外一个例子，在该例子当中，我们提出一种对高速公路车道进行划分的新方式——根据汽车的类型进行，将高速公路分为“小型汽车车道”、“中型汽车车道”及“大型汽车车道”，这样，一辆汽车一旦被划分成其中的某一种类型，就不会再发生改变了，在这种实力当中，高速公路类似于本实施例中的链路，而车道则相当于本实施例中的隧道，最后，汽车相当于本实施例中的业务。

对于公路车道而言，可以行驶不计其数的车辆，而对于一条隧道而言，同样也可以承载多个业务，但是对于运营商而言，为了便于对业务的管理，一般一条隧道上仅传输一个业务。

运营商在设置隧道的时候，可能有的隧道会有保护隧道用于在主用隧道(即前面所说的隧道)发生故障的时候，承载主用隧道上的业务，这种方式能够有效降低链路故障时业务中断的可能性，基于同样的理由，针对有的业务也可能设置对应的备用业务，备用业务与主用业务(即前面所说的业务)通过不同的隧道进行传输，一旦承载主用业务的隧道发生了故障，主用业务不能到达目的地，则可以由备用业务经由承载它的隧道到达目的地，这样也能够有效降低业务中断的可能性，提高用户体验。

分析模块404在确定待抢通隧道的时候，本实施例中分析模块404筛选出的是那些承载了至少一个当前无法达到目的路由的业务的隧道作为待抢通隧道，当前无法到达本地路由是指在链路故障的情况下，该业务无法达到目的地，会造成用户的业务中断的情况。因此，由于保护隧道与备用业务的设置，使得分析模块404在确定待抢通隧道的时候，并不是仅仅考虑故障链路上的隧道，即故障链路上的隧道并不一定都是待抢通隧道，因为，故障链路上的某些隧道可能具有保护隧道，或者是故障链路上某些隧道承载的业务具有备用业务，而在该链路出现故障的时候，业务能够通过主用隧道的保护隧道达到目的地，或者是备用业务能够代替主用业务达到目的地继续为用户提供服务。故，分析模块404在确定待抢通隧道的时候，需要根据各隧道以及隧道上承载的业务进行。下面以一些简单的例子对本实施例中满足作为待抢通隧道的条件的隧道进行说明：

如果故障链路X-X’上的某一条隧道A不具有保护隧道，而且该隧道A上承载了不具有备用业务的业务a，则该隧道A应当作为待抢通隧道，因为在链路X-X’恢复正常的之前，业务a都无法到达目的地为用户提供服务了。

如果故障链路X-X’上的某一条隧道B具有保护隧道B’，但是保护隧道B’也是在故障链路上，同时，隧道B上承载的业务b也不具有备用业务，这时候隧道B也应当列入待抢通隧道的行列中。虽然隧道B具有保护隧道B’，但由于即使是将隧道B上的业务都移动到保护隧道B’上，保护隧道B’也无法将这些业务传输到目的地为用户提供服务，所以，隧道B上依旧承载了无法到达目的路由的业务。不过可以理解的是，在本示例当中，隧道B的保护隧道B’虽然也是在故障链路之上，但这并能说明保护隧道B’处于故障链路X-X’，其也可能是在其他故障链路上。

如果故障链路X-X’上的某一条隧道C具有保护隧道C’，但是保护隧道C’也是在故障链路上，同时，隧道C上承载的业务c虽然具有备用业务c’，但是承载该备用业务c’的隧道D也处于故障状态，同时该隧道D并没有保护隧道，因此，此时隧道C上承载的业务c和隧道C’上承载的备用业务c’都没有办法到达目的地，因此隧道C也应当列入待抢通隧道的行列中。另外承载该备用业务c’的隧道D也应当作为待抢通隧道。

如果故障链路X-X’上的某一条隧道E具有保护隧道E’，但是保护隧道E’也是在故障链路上，同时，隧道E上承载的业务E虽然具有备用业务E’，但是承载该备用业务E’的隧道F也处于故障状态，同时该隧道F虽然具有保护隧道F’，但是该保护隧道F’所在的链路也处于故障状态下，这时隧道E应当列入待抢通隧道的行列中。另外承载该备用业务E’的隧道F也应当作为待抢通隧道。

计算模块406用于待抢通隧道确定对应的临时隧道。临时隧道用于在故障链路回复正常之前承载待抢通隧道上的业务，临时隧道时可以在当前链路故障的情况下，可以将待抢通隧道上的业务传输至目的地的路由，计算模块406在计算确定临时隧道的过程中，可以根据这样几种原则进行：

首先是路径最短原则，从在当前情况下可以将待抢通隧道上的业务从起始地址传输至目的地址的路由中选择路径最短的那一个作为该待抢通隧道对应的临时隧道，可以理解的是，当前情况下可以将待抢通隧道上的业务从起始地址传输至目的地址的路由可能会有多个，而本实施例中计算模块406在选择临时隧道的时候，可以从所有这些路由中进行选择，也可以从这些路由中的部分里面进行选择。这种选择原则能够保证对待抢通隧道上的业务的传输速度最快，同时也能将承载待抢通隧道上的业务对网络带来的影响降到最低，因为，在路径最短原则下，计算模块406择的临时隧道中所影响到的网元和传输线缆是最少的。

另外，计算模块406还可以根据带宽最大原则进行选择，因为选择的临时隧道可能本身也会需要传输一些业务，因此，为了将待抢通隧道上的业务移动到该临时隧道上进行传输后会过多的影响到该临时隧道对其本来承载的业务，因此，本实施例中计算模块406在选择临时隧道的时候，可以选择那些带宽较大的路由最为临时隧道，因为当临时隧道本身具备大的带宽的时候，其承载额外业务的传输时才会对原本业务的影响最小。

最后，计算模块406还可以综合路径最短原则和带宽最大原则两种来进行临时隧道的选择，可以由用户预先为路径最短和带宽最大这两个原则设置对应的权重，由于路径因素中，路径越短越好，而在带宽因素当中，带宽越大越好，因此，如果直接将一条临时隧道的路径与带宽两个值与对应的权重值进行加权计算，可能不能得出正确的结果，因此，计算模块406可以将路径或者带宽中的一个因素进行转换，以保证计算结果的正确性，例如，将带宽进行转换，让转换后的结果与选择优先级成反比，即转换后的结果越小，则被选择优先级越高。

由于需要计算模块406确定临时隧道的待抢通隧道的数量可能较多，而计算模块406又不可能在同一时间将所有待抢通隧道的临时隧道都计算出来，因此，在本实施例中，计算模块406按照预设抢通策略为各待抢通隧道确定对应的临时隧道，在预设策略中可以包括各个待抢通隧道的优先级，让计算模块406优先选择为优先级较高待抢通隧道计算临时隧道。在本实施例一些示例当中，待抢通隧道上承载的业务量越多，则优先级越高，而在本实施例中的另外一些示例当中，承载的业务越重要，则抢通隧道的优先级越高，例如，有的待抢通隧道上承载的可能是2G业务，有的承载的是3G或者4G业务，而由于2G业务会影响到用户的电话业务，因此，本实施例中规定承载着2G业务的待抢通隧道的优先级越高。在本实施例中的另外一些示例中，还可以将业务量与业务的重要性综合起来确定待抢通隧道的优先级，例如为业务量和业务的重要性分别设置权重，然后根据计算结果确定各个待抢通隧道的优先级。

在计算模块406计算出临时隧道之后，可以将计算出来的记过向网管人员进行展示，如果网管人员对选择的临时隧道不满意，则可以输入新的限制条件，然后网管平台根据新的限制条件进行计算，直至得到令网管人员满意的临时隧道为止。

抢通模块408用于抢通隧道上的业务移至临时隧道运行。在计算模块406计算出临时隧道，或者是计算模块406计算出临时隧道并由网关人员进行确认之后，抢通模块408可以将各个待抢通隧道上的业务移动到对应的临时隧道上进行传输，本实施例中将这个过程称为“抢通”，和计算模块406计算临时隧道一样，抢通模块408不可能将所有的待抢通隧道同时抢通，因为“抢通”过程实质上是配置数据的下发，而同时下发大量的配置数据容易导致数据下发失败，从而导致“抢通”失败。因此，“抢通”过程也可以分为多个批次，网管人员可以根据网络性能等因素的实际情况确定出抢通模块408每次抢通的待抢通隧道的数量。例如，如果网管人员下发的抢通数量为5，则抢通模块408每次抢通5条待抢通隧道。

另外，由于在抢通过程中，极有可能出现抢通失败的情况，因此，本实施例的一种示例当中，如图5所示，网管平台40除了包括获取模块402、分析模块404、计算模块406以及抢通模块408以外，还包括备份模块410，备份模块410用于对待抢通隧道的数据进行备份，一旦抢通失败，可以根据备份数据对待抢通隧道的数据进行恢复。在抢通失败后，可以让网管人员对抢通失败的原因进行分析后，对相关数据进行调整，然后重新执行抢通过程，本实施例中将该重新抢通的过程称为“重新抢通”。

在本实施例的另一些示例当中，如图6所示，网管平台40除了包括获取模块402、分析模块404、计算模块406、抢通模块408、备份模块410以外，还包括回退模块412。在故障链路恢复正常之后，回退模块412可以将临时隧道承载的那些原本属于待抢通隧道的业务重新切换至待抢通隧道上传输，本实施例中将这个切换过程称为“回退”。

在本实施例中，网管平台40可以部署在服务器上，下面对承载网管平台40的服务器的硬件结构进行说明，请参考图7：

网管平台40部署在服务器70上，由于本实施例中抢通待抢通隧道的过程可以通过计算及程序实现，因此，可以将相应的计算机程序存储在内存当中，由处理器703在内存705当中读取程序并实现对应的功能，其中，获取模块402可以由通信装置701来实现，通信装置701获取OAM平台传输的或者是由用户下发的故障链路信息，让然后将故障链路信息通过输入输出总线702输入到处理器703当中，由处理器703实现分析模块404、计算模块406的功能，即由处理器703对获取的故障链路信息进行自动分析以获取到需要抢通的隧道作为待抢通隧道，并自动为各待抢通隧道分配临时隧道，最后还是由处理器703和通信装置701共同实现抢通模块408的功能，处理器703将实现抢通过程的数据传输至通信装置，由通信装置进行下发，将待抢通隧道上的业务移至所述临时隧道上传输。另外本实施例中的备份模块410可以由处理器703和存储器704共同实现，处理器703将待抢通隧道进行抢通前的数据进行提取并存储到存储器704中，回退模块412同样可以由处理器703来实现。

本实施例中提供的网管平台，通过由获取模块获取故障链路信息，并由分析模块对获取的故障链路信息进行自动分析以获取到需要抢通的隧道作为待抢通隧道，然后由计算模块自动为各待抢通隧道分配临时隧道，最后，让抢通模块将待抢通隧道的上的业务移动到临时隧道上运行，降低了业务隧道抢通过程中人力的参与，降低了人以资源的耗费，有利于实现资源的优化配置。

显然，本领域的技术人员应该明白，上述本发明实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在计算机存储介质(ROM/RAM、磁碟、光盘)中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。所以，本发明不限制于任何特定的硬件和软件结合。

以上内容是结合具体的实施方式对本发明实施例所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。

Claims (10)

1.一种业务隧道抢通方法，包括：

网管平台获取故障链路信息，所述故障链路信息中包括当前处于故障状态的链路的标识信息；

所述网管平台对故障链路上的各隧道及各所述隧道承载的业务进行分析以确定待抢通隧道，所述待抢通隧道为确定需要进行抢通的隧道；

所述网管平台为各所述待抢通隧道确定对应的临时隧道，所述临时隧道用于在所述故障链路回复正常之前承载所述待抢通隧道上的业务；

所述网管平台将所述待抢通隧道上的业务移至所述临时隧道上传输。

2.如权利要求1所述的业务隧道抢通方法，其特征在于，所述网管平台对故障链路上的各隧道及各所述隧道承载的业务进行分析以确定待抢通隧道包括：

筛选出承载了至少一个当前无法达到目的地址的业务的隧道作为待抢通隧道。

3.如权利要求2所述的业务隧道抢通方法，其特征在于，承载了至少一个当前无法达到目的地址的业务的隧道至少满足以下条件中的任意一个：

所述隧道本身不具有保护隧道，且所述隧道承载的至少一个业务无备用业务；

所述隧道的保护隧道所在的链路处于故障状态，且承载的至少一个业务无备用业务；

所述隧道的保护隧道所在的链路处于故障状态，所述隧道承载的业务有备用业务，承载所述备用业务的隧道所在的链路处于故障状态且无保护隧道；

所述隧道的保护隧道所在的链路处于故障状态，所述隧道承载的业务有备用业务，且承载所述备用业务的第二隧道所在的链路处于故障状态，所述第二隧道具有保护隧道，但所述保护隧道所在的链路处于故障状态。

4.如权利要求1所述的业务隧道抢通方法，其特征在于，所述网管平台为各所述待抢通隧道确定对应的临时隧道包括：所述网管平台按照预设抢通策略为各所述待抢通隧道确定对应的临时隧道，所述预设抢通策略中至少包括为各所述待抢通隧道确定临时隧道的顺序。

5.如权利要求1所述的业务隧道抢通方法，其特征在于所述网管平台为各所述待抢通隧道确定对应的临时隧道的方式包括以下任意一种：

将路径作为选择因素，从多个当前可将所述待抢通隧道上的业务从起始地址传输至目的地址的路由中选择路径最短的作为临时隧道；

将带宽作为选择因素，从多个当前可将所述待抢通隧道上的业务从起始地址传输至目的地址的路由中选择带宽最宽的作为临时隧道；

将路径和带宽同时作为选择因素，根据为路径和带宽预设的权重，从多个当前可将所述待抢通隧道上的业务从起始地址传输至目的地址的路由中选择符合权重要求的作为临时隧道。

6.如权利要求1-5任一项所述的业务隧道抢通方法，其特征在于，还包括：

当所述故障链路恢复正常后，所述网管平台将所述临时隧道承载的、原本由待抢通隧道承载的业务回退到修复后的所述待抢通隧道上传输。

7.如权利要求1-5任一项所述的业务隧道抢通方法，其特征在于，还包括：

所述网管平台向用户展示所述待抢通隧道当前的状态和/或当前可对所述待抢通隧道执行的操作。

8.一种网管平台，其特征在于，包括：

获取模块，用于获取故障链路信息，所述故障链路信息中包括当前处于故障状态的链路的标识信息；

分析模块，用于对故障链路上的各隧道及各所述隧道承载的业务进行分析以确定待抢通隧道，所述待抢通隧道为确定需要进行抢通的隧道；

计算模块，用于为各所述待抢通隧道确定对应的临时隧道，所述临时隧道用于在所述故障链路回复正常之前承载所述待抢通隧道上的业务；

抢通模块，用于将所述待抢通隧道上的业务移至所述临时隧道上传输。

9.如权利要求8所述的网管平台，其特征在于，所述分析模块用于筛选出承载了至少一个当前无法达到目的路由的业务的隧道作为待抢通隧道。

10.如权利要求8或9所述的网管平台，其特征在于，还包括：

回退模块，用于当所述故障链路恢复正常后，所述网管平台将所述临时隧道承载的、原本由待抢通隧道承载的业务回退到修复后的所述待抢通隧道上上传输。