一种用户协议栈运行方法和装置与流程

本发明涉及通信技术领域，具体涉及一种用户协议栈运行方法和装置。

背景技术

在无线基站设备中，基于效率及定制化需求的考虑，很多时候并不采用操作系统中的协议栈与外界进行通信，而是设计一套用户协议栈与外界进行通信。用户协议栈主要是指运行在linux环境下的用户态的协议栈，按照网络协议的分层原理，用户协议栈包括数据链路层、网络层、传输层。其中数据链路层主要是eth(以太网)协议，网络层主要是ip(internetprotocol网络之间互连的协议)，传输层主要包括tcp(transmissioncontrolprotocol传输控制协议)、udp(userdatagramprotocol用户数据报协议)、sctp(streamcontroltransmissionprotocol，流量控制传输协议)等传输协议。传统基站的用户协议栈软件都是运行在设备商(vendor)提供的专有硬件平台上，这种软硬件一体化解决方案中软件的运行严重依赖于硬件，在硬件未完成初始化的情况下软件是没法开始运行的。当系统出现异常复位时，由于底层硬件的长时间初始化导致用户协议栈软件没法第一时间跑起来，使得传输业务等长时间处于中断状态，最终导致基站其他单元的一系列的退服操作，一旦出现退服，基站重新进入服务状态又是一个漫长的过程。

针对此问题，传统基站系统中可采用热备的方式来解决，即同时使用两块接口板(用户协议栈所运行的单板)，一块作为主板一块作为备板，主备之间数据、状态完全同步。当监测到主板出现异常时，由备板接管，实现不间断的为上层业务传输数据。此项技术在理论上可行，但是存在不少问题，如：

1.技术太过复杂：存在主备一致性、主备同步、主备监测、主备竞争、主备切换等一系列问题。

2.传输效率低：为了实现协议状态一致，报文需要经过主备两个单板处理完后才能递交给上层业务。

3.资源消耗高、成本高、占设备空间大：在1+1热备的情况下需要冗余一块硬件单板。

技术实现要素：

本发明实施例要解决的主要技术问题是，提供一种用户协议栈运行方法和装置，解决现有技术中由于用户协议栈运行在专有硬件平台上，导致的初始化费时，用户协议栈异常的恢复方案技术复杂、资源消耗高、成本高的缺点。

在可虚拟化的硬件平台上部署运行用户协议栈需要的虚拟节点；

在所述虚拟节点上运行用户协议栈。

为解决上述技术问题，本发明实施例还提供一种用户协议栈运行装置，包括：

部署模块，用于在可虚拟化的硬件平台上部署运行用户协议栈需要的虚拟节点；

运行模块，用于在所述虚拟节点上运行用户协议栈。

采用本发明实施例提供的用户协议栈运行方法和装置，可以在可虚拟化的硬件平台上部署运行用户协议栈需要的虚拟节点；之后在部署的虚拟节点上运行用户协议栈。由于虚拟节点具有独立于具体硬件设备的特性和优点，故而本发明中的用户协议栈的运行对硬件的依赖性大大降低，避免了硬件平台上运行用户协议栈存在的初始化时间长的问题，并且在本发明中用户协议栈在虚拟节点上运行，意味着当用户协议栈异常时，异常的恢复是在虚拟节点上完成，有效避免了在专有硬件平台上使用热备方法进行异常恢复面临的问题。

进一步的，在用户协议栈的运行过程中，当监测到用户协议栈异常时，启动新的虚拟节点运行该用户协议栈，新的虚拟节点可以在非常短的时间内，正常启动并运行，保证协议栈异常的快速恢复，相比传统基站中的热备方案，本发明避免了主备同步、主备切换、主备监测、一致性等复杂的处理流程，实现更加简单。传统基站中的热备方案中只有一块备份的硬件设备，一旦备份的硬件设备出现问题，热备就失败。而本发明中，虚拟节点独立于具体硬件设备，不会因为某个硬件设备发生故障导致本发明的操作没法实施，所以本发明更加稳定。相比传统基站中的热备方案，本发明不需要对硬件设备进行冗余备份，更加节省资源和成本，且技术简单，易于实现。

进一步地，保存用户协议栈的配置信息可以在用户协议栈需要迁移到新的虚拟节点时，帮助用户协议栈重新快速恢复链接，恢复传输业务，提高用户协议栈异常的恢复速度。

附图说明

图1为本发明实施例一提供的一种用户协议栈运行方法的流程图；

图2为本发明实施例一中将用户协议栈从专业硬件平台上拆分出来独立运行在虚拟节点上的示意图；

图3为本发明实施例二提供的基于kubernetes和docker虚拟化的用户协议栈运行方法的流程图；

图4为本发明实施例二中基于kubernetes和docker虚拟化的用户协议栈运行方案示意图；

图5为本发明实施例三提供的一种用户协议栈运行装置的结构图。

具体实施方式

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

实施例一：

参见图1，本实施例示出一种用户协议栈运行方法，利用虚拟化技术中虚拟机/容器独立于具体硬件及能够快速启动的特点，将基站中用户协议栈软件迁移到虚拟节点上，并及时保存用户协议栈软件的运行状态，利用监控和调度程序及时发现用户协议栈异常，并将用户协议栈迁移到新的虚拟节点上，达到快速恢复用户协议栈异常的目的。

本实施例的方法的过程包括：

s101、在可虚拟化的硬件平台上部署运行用户协议栈需要的虚拟节点；

s102、在虚拟节点上运行用户协议栈。

其中，s101中可虚拟化的硬件平台是可以对硬件进行虚拟化的硬件设备，包括但不限于通用可虚拟化硬件平台例如，基于x86处理器的硬件平台，基于x64处理器的硬件平台等等。虚拟节点(node)可以是虚拟机(vm：virtualmachine)，也可以是容器。进一步的，上述的容器包括但不限于基于docker的容器。

在本实施例中，参见图2所示，基站的用户协议栈软件不再运行在专有硬件(设备商定制的硬件单板)上，而是运行在基于可虚拟化硬件平台的虚拟节点(node)上。

可虚拟化的硬件平台对底层的硬件虚拟化后，虚拟化的底层硬件的初始化已经完成，所以当用户协议栈异常，需要迁移到新的虚拟节点上运行时，可以使用虚拟化的底层硬件，且可以避免底层硬件初始化带来的问题。

通过s101和s102的方案，可以将传统方式中，用户协议栈在专用硬件平台上运行的方式，转变为用户协议栈在虚拟化硬件平台(尤其是通用的虚拟化硬件平台)运行。虚拟节点的使用为用户协议栈的运行带来了益处，但也不能完全避免用户协议栈异常发生，所以还是需要有一种用户协议栈在虚拟节点上的运行过程中发生异常后的异常恢复方案，所以参见图1，本实施例的方法还包括在用户协议栈的运行过程中进行如下的步骤：

s103、监测用户协议栈的状态；

s104、当监测到用户协议栈异常时，启动新的虚拟节点运行用户协议栈。

当用户协议栈在虚拟节点上开始运行后，本实施例会进行s103，对用户协议栈的状态进行监测，以便用户协议栈出现异常时，能尽快解决异常。

本实施例中，用户协议栈的异常可能由两方面导致，第一是用户协议栈所在的虚拟节点异常导致用户协议栈异常，第二是用户协议栈本身异常。所以，进一步的，本申请中用户协议栈异常包括但不限于运行所述用户协议栈的虚拟节点的运行状态异常，和/或所述用户协议栈的服务状态异常。在s103中监测用户协议栈的状态包括：监测运行用户协议栈的虚拟节点的运行状态是否异常，和/或监测用户协议栈的服务状态是否异常。

进一步的，运行该用户协议栈的虚拟节点的运行状态异常包括但不限于：虚拟节点异常退出、虚拟节点异常终止；用户协议栈的服务状态异常包括：用户协议栈服务异常退出、用户协议栈服务异常终止等等。其中，s103可以由专门的监控程序实现。

当在s103中监测到用户协议栈服务异常或用户协议栈所在虚拟节点运行状态异常时，需要进行的下一步是将该用户协议栈迁移到新的虚拟节点上运行。

众所周知，用户协议栈的作用是向它的上层业务传输数据，而数据的传输是需要通过通信链接完成的，当用户协议栈从旧的虚拟节点迁移到新的虚拟节点后，在新虚拟节点上运行的用户协议栈需要尽快恢复之前的数据传输，就需要建立在旧的虚拟节点上运行时建立的链接。所以一般地，需要知道用户协议栈在旧的虚拟节点上时的配置信息，这里的配置信息包括但不限于建立链接的ip地址、端口等信息。

在一实施例中，本实施例中，启动新的虚拟节点运行用户协议栈包括：

启动新的虚拟节点；

在新的虚拟节点上运行该用户协议栈；

获取用户协议栈异常时，在运行所述用户协议栈的虚拟节点(属于上述的旧的虚拟节点)上所述用户协议栈的配置信息；

根据该配置信息在新的虚拟节点上恢复用户协议栈的业务。其中，恢复的用户协议栈的业务包括但不限于传输业务，例如对上层业务的数据传输业务。

本实施例中的上层业务可以为无线基站中的lte、umts、5g等业务，也可以为其他的it应用。本实施例对此没有限定。

根据该配置信息在新的虚拟节点上恢复用户协议栈的业务的方法包括：根据配置信息中的ip地址、端口号等信息建立链接，通过建立的链接向上层业务传输数据。其中根据配置信息建立链接其实就是恢复用户协议栈在旧的虚拟节点上运行时的链接，所以用户协议栈迁移到新的虚拟节点后，还是可以快速地恢复传输业务。

在一实施例中，优选的，在用户协议栈为上层业务传输服务传输数据的同时，及时将用户协议栈的运行状态，如sctp耦连，断开，建立连接，断开连接等及用户协议栈的配置信息(包括但不限于ip，端口)进行保存。该保存的连接状态和配置信息用于用户协议栈在虚拟节点上迁移时，在迁移后运行该用户协议栈的虚拟节点上恢复用户协议栈的业务。

进一步的，为了便于用户协议栈运行状态和配置信息的保存，可以在系统中设置数据库，将用户协议栈的运行状态和配置信息存入该数据库中。

优选的，在本实施例中，当需要启动新的虚拟节点运行用户协议栈时；获取用户协议栈异常时，在运行该用户协议栈的虚拟节点上该用户协议栈的配置信息的方式可以是，从预先保存的用户协议栈的配置信息中获取该用户协议栈的配置信息。具体的可以从数据库中获取该用户协议栈的配置信息。

采用本发明实施例提供的用户协议栈运行方法，用户协议栈运行在基于可虚拟化硬件平台的虚拟节点上；并一直监测用户协议栈的状态；当监测到用户协议栈异常时，启动新的虚拟节点运行该用户协议栈，由于虚拟化中虚拟节点独立于具体硬件及能够快速启动，所以当用户协议栈迁移到新的虚拟节点上后，可以在非常短的时间内，正常启动并运行，保证协议栈异常的快速恢复，相比传统基站中的热备方案，本发明避免了主备同步、主备切换、主备监测、一致性等复杂的处理流程，实现更加简单。传统基站中的热备方案中只有一块备份的硬件设备，一旦备份的硬件设备出现问题，热备就失败。而本发明中，虚拟节点独立于具体硬件设备，不会因为某个硬件设备发生故障导致本发明的操作没法实施，所以本发明更加稳定。相比传统基站中的热备方案，本发明不需要对硬件设备进行冗余备份，更加节省资源和成本。

进一步地，保存用户协议栈的配置信息可以在用户协议栈需要迁移到新的虚拟节点时，帮助用户协议栈重新快速恢复链接，恢复传输业务，提高用户协议栈异常的恢复速度。

实施例二：

参见图3，本实施例示出一种具体的用户协议栈运行方法。

nfv，即网络功能虚拟化，networkfunctionvirtualization。通过使用x86等通用性硬件以及虚拟化技术，来承载很多功能的软件处理，从而降低网络昂贵的设备成本。可以通过软硬件解耦及功能抽象，使网络设备功能不再依赖于专用硬件，资源可以充分灵活共享，实现新业务的快速开发和部署，并基于实际业务需求进行自动部署、弹性伸缩、故障隔离和自愈等，etsi(欧洲电信标准化协会)明确要求下一代(5g)的基站也必须符合虚拟化的标准。

目前主流的虚拟化技术方案有基于openstack的虚拟化方案及基于kubernetes的容器化方案。kubernetes(缩写k8s)是google开源的容器集群管理系统。它构建在docker技术之上，为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等整一套功能。

下面将基于nfv的思想结合附图3和附图4对基于kubernetes技术的用户协议栈运行方法的实施步骤作进一步的详细描述：

s301、新增通用硬件平台，在通用硬件平台上部署docker及kubernetes软件。该步骤相当于在通用硬件平台上部署虚拟节点，即后续描述中的用户协议栈点。

其中，通用硬件平台包括但不限于基于x86处理器的硬件平台。参见图4，dockerengine部署在通用的硬件平台上。另外，本实施例中，在s301中部署的还可以是openstack以及虚拟机，后续过程中，用户协议栈运行在部署的虚拟机上。

s302、将用户协议栈以docker镜像形式部署到kubernetes上。由kubernetes加载镜像并运行容器。即图4中，用户协议栈容器运行在dockerengine上。

s303、用户协议栈为上层业务传输数据的同时，及时将用户协议栈运行状态及配置信息存入数据库。其中，该上层业务如图4中的业务软件，包括但不限于lte、5g、it应用等等。

s304、kubernetes监控部署的用户协议栈容器(即实施例一中的虚拟节点)运行状态，一旦监测到用户协议栈容器异常退出，则进入s305处理流程，重新加载用户协议栈镜像，运行新的用户协议栈容器，若用户协议栈容器和用户协议栈本身都正常则返回s303，继续保存数据。

其中，监控工作可以由图4中的监控程序完成，该监控程序可以由kubernetes提供和实现。

在s304中，kubernetes监控的也可以是用户协议栈服务状态，当用户协议栈服务异常退出，即用户协议栈容器(实施例一中的虚拟节点)还在正常运行，但是用户协议栈退出的情形，进入s305处理流程重新加载用户协议栈镜像，运行新的用户协议栈容器。

s305、启动新的用户协议栈容器运行异常容器上的用户协议栈，用户协议栈进程读取数据库中用户协议栈的配置及状态信息，恢复用户协议栈的数据传输。

其中，参见图4，启动新用户协议栈可由调度程序实现，该调度程序可以由kubernetes提供并实现。

采用本实施例的方法，将基站中用户协议栈软件迁移到容器上，在用户协议栈为上层业务传输数据的同时及时保存软件的运行状态和配置信息，当发现用户协议栈异常时，可以在新的容器中运行用户协议栈，并利用预存的运行状态和配置信息快速恢复异常用户协议栈的传输。与现有技术相比，方法实现更简单，更稳定，更节省资源。

实施例三：

参见图5，本实施例示出一种用户协议栈运行装置，利用虚拟化技术中虚拟机/容器独立于具体硬件及能够快速启动的特点，将基站中用户协议栈软件从专用的硬件平台上迁移到虚拟节点上运行，并在用户协议栈向上层业务传输数据时及时保存用户协议栈软件的运行状态和配置信息，利用监控和调度程序及时发现用户协议栈异常，并将用户协议栈迁移到新的虚拟节点上，达到快速恢复用户协议栈异常的目的。

本实施例中用户协议栈运行装置包括：

部署模块501，用于在可虚拟化的硬件平台上部署运行用户协议栈需要的虚拟节点；

运行模块502，用于在虚拟节点上运行用户协议栈；

监测模块503，用于监测用户协议栈的状态；

调度模块504，用于当监测到用户协议栈异常时，启动新的虚拟节点运行用户协议栈。

部署模块501利用的可虚拟化的硬件平台是可以对硬件进行虚拟化的硬件设备，包括但不限于通用可虚拟化硬件平台例如，基于x86处理器的硬件平台，基于x64处理器的硬件平台等等。虚拟节点(node)可以是虚拟机(vm：virtualmachine)，也可以是容器。该容器包括但不限于基于docker的容器

在本实施例中，新增了通用可虚拟化硬件平台，基站的用户协议栈软件不再运行在专有硬件(设备商定制的硬件单板)上，而是运行在基于可虚拟化硬件平台的虚拟节点(node)上。由于引入了虚拟化方案，本实施例中还需要增加一个虚拟化层，如安装openstack或docker等虚拟化或容器软件作为虚拟节点。

可虚拟化的硬件平台对底层的硬件虚拟化后，虚拟化的底层硬件的初始化已经完成，所以当用户协议栈异常，需要迁移到新的虚拟节点上运行时，可以使用虚拟化的底层硬件，且可以避免底层硬件初始化带来的问题。

当用户协议栈在虚拟节点上开始运行后，本实施例的监测模块503会对用户协议栈的状态进行监测，以便用户协议栈出现异常时，能尽快解决异常。

可以想到的是，用户协议栈的异常可能由两方面导致，第一是用户协议栈所在的虚拟节点异常导致用户协议栈异常，第二是用户协议栈本身异常。所以，进一步的，本申请中监测模块503具体用于监测运行用户协议栈的虚拟节点的运行状态是否异常，和/或监测用户协议栈的服务状态是否异常。调度模块504，用于当运行用户协议栈的虚拟节点的运行状态异常，和/或用户协议栈的服务状态异常时，启动新的虚拟节点运行该用户协议栈。

进一步的，监测模块503监测到的运行用户协议栈的虚拟节点的运行状态异常包括但不限于，虚拟节点异常退出、虚拟节点异常终止；用户协议栈的服务状态异常包括：用户协议栈服务异常退出、用户协议栈服务异常终止等等。其中，监测模块503可由专门的监控程序实现。

当监测模块503监测到用户协议栈服务异常或运行用户协议栈的虚拟节点运行状态异常时，需要调度模块504将该用户协议栈迁移到新的虚拟节点上运行。

众所周知，用户协议栈的作用是向它的上层业务传输数据，而数据的传输是需要通过通信链接完成的，当用户协议栈从旧的虚拟节点迁移到新的虚拟节点后，在新虚拟节点上运行的用户协议栈需要尽快恢复之前的数据传输，就需要建立在旧的虚拟节点上运行时建立的链接。所以一般地，需要知道用户协议栈在旧的虚拟节点上时的配置信息，这里的配置信息包括但不限于建立链接的ip地址、端口等信息。

优选的，本实施例中，调度模块504具体用于当用户协议栈异常时，启动新的虚拟节点；在新的虚拟节点上运行该用户协议栈；获取该用户协议栈异常时，在运行该用户协议栈的虚拟节点上该用户协议栈的配置信息；根据该配置信息在新的虚拟节点上恢复用户协议栈的业务。其中，恢复的用户协议栈的业务包括但不限于传输业务，例如对上层业务的数据传输业务。

本实施例中的上层业务可以为无线基站中的lte、umts、5g等业务，也可以为其他的it应用。本实施例对此没有限定。

进一步的，调度模块504根据该配置信息在新的虚拟节点上恢复用户协议栈的业务的方法包括：根据配置信息中的ip地址、端口号等信息建立链接，通过建立的链接向上层业务传输数据。其中根据配置信息建立链接其实就是恢复用户协议栈异常时，该用户协议栈的虚拟节点运行时的链接，所以用户协议栈迁移到新的虚拟节点后，还是可以快速地恢复传输业务。

在本实施例中，优选的，还包括保存模块505，用于在用户协议栈为上层业务传输数据时，保存用户协议栈的运行状态及配置信息，保存的数据用于用户协议栈在虚拟节点上迁移时，恢复用户协议栈的传输业务。

其中，用户协议栈的运行状态，包括但不限于sctp耦连，断开，建立连接，断开连接等；用户协议栈的配置信息包括但不限于ip，端口。

进一步的，为了便于用户协议栈运行状态和配置信息的保存，可以在系统中设置数据库，保存模块505用于将用户协议栈的运行状态和配置信息存入该数据库中。

优选的，在本实施例中，当调度模块504需要启动新的虚拟节点运行用户协议栈时；调度模块504获取用户协议栈异常时，在运行该用户协议栈的虚拟节点上该用户协议栈的配置信息的方式可以是从保存模块505预先保存的用户协议栈的配置信息中获取该用户协议栈对应的配置信息。具体的可以从数据库中获取该用户协议栈的配置信息。

采用本发明实施例提供的用户协议栈运行装置，用户协议栈运行在基于可虚拟化硬件平台的虚拟节点上；监测模块一直监测用户协议栈的状态；当监测到用户协议栈异常时，调度模块启动新的虚拟节点运行该用户协议栈，由于虚拟化中虚拟节点独立于具体硬件及能够快速启动，所以当用户协议栈迁移到新的虚拟节点上后，可以在非常短的时间内，正常启动并运行，保证协议栈异常的快速恢复，相比传统基站中的热备方案，本发明避免了主备同步、主备切换、主备监测、一致性等复杂的处理流程，实现更加简单。传统基站中的热备方案中只有一块备份的硬件设备，一旦备份的硬件设备出现问题，热备就失败。而本发明中，虚拟节点独立于具体硬件设备，不会因为某个硬件设备发生故障导致本发明的操作没法实施，所以本发明更加稳定。相比传统基站中的热备方案，本发明不需要对硬件设备进行冗余备份，更加节省资源和成本。

进一步地，保存模块保存用户协议栈的配置信息可以在用户协议栈需要迁移到新的虚拟节点时，帮助用户协议栈重新快速恢复链接，恢复传输业务，提高用户协议栈异常的恢复速度。

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

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