CN109862557A - 通道建立方法以及基站 - Google Patents

Abstract

本申请涉及通信技术领域，更具体的说涉及建立运维管理通道的技术。在一种通道建立方法中，基站获取该基站与运营支撑系统OSS服务器之间的运维管理通道的连接状态，如果该连接状态表明该运维管理通道存在连接异常的情况下，获取基站中在当前时刻之前存储的，该基站与OSS服务器建立运维管理通道所采用的历史通道建立参数，这样，可以利用当前时刻之前基站成功与OSS建立运维管理通道所采用该历史通道建立参数，成功建立基站与该OSS服务器之间的运维管理通道的连接，从而在基站与OSS服务器之间的运维管理通道出现异常的情况下，也可以保证基站与OSS服务器之间的运维管理通道的可靠建立，提高了基站与OSS服务器之间的运维管理通道的可靠性和稳定性。

Description

通道建立方法以及基站

技术领域

本申请涉及通信技术领域，更具体地说，涉及运维管理通道建立技术。

背景技术

在通信网络中，运营支撑系统(Operation Support System，OSS)用于对基站进行远程运维管理，以对基站进行正常运维以及故障诊断等。为了实现对基站的远程运维管理，基站与运营支撑系统的服务器之间需要建立通信连接通道，该通信连接通道称为运维管理通道(Operation and Management Channel，OMCH)。

然而，当由于基站侧存在操作失误或者出现某些故障的情况下，就可能会使得基站与OSS的服务器之间的OMCH通道处于中断状态，如，基站由于启动异常，而导致基站无法与OSS服务器建立OMCH通道；或者是，基站运行中出现故障，而导致基站与OSS服务器之间的OMCH通道中断，而一旦基站与OSS的服务器之间的OMCH通道处于中断状态，就会影响到OSS对基站的远端运维，从而需要运维人员前往各个基站端进行问题处理，耗费了较多的人力资源。因此，如何在基站与OSS的服务器之间的OMCH通道处于中断状态的情况下，建立或者恢复基站与OSS的服务器之间的OMCH通道连接，以保证基站与OSS的服务器之间OMCH通道的稳定连接是本领域技术人员迫切需要解决的技术问题。

发明内容

有鉴于此，本申请实施例提供了一种通道建立方法以及基站，以更为可靠的建立基站与OSS服务器之间的OMCH通道，保证基站与OSS服务器之间的OMCH通道的可靠连通。

为实现上述目的，本申请的第一方面提供了一种通道建立方法，在该方法中，基站获取该基站与运营支撑系统OSS服务器之间的运维管理通道的连接状态，其中，该运维管理通道用于实现该基站与OSS服务器之间的通信连接；在运维管理通道存在连接异常的情况下，基站可以获取该基站中存储的历史通道建立参数，而该历史通道建立参数为在当前时刻之前，该基站与OSS服务器建立运维管理通道所采用的通道建立参数；这样，基于所述历史通道建立参数，可以建立基站与所述OSS服务器之间的运维管理通道的连接，从而可以减少由于基站无法获取到建立运维管理通道所需的通道建立参数，而无法构建或者恢复基站与OSS服务器之间的运维管理通道的情况，从而有利于保证基站与OSS服务器之间运维管理通道的可靠连通。

在一种可能的设计中，基站在获取到的连接状态表明基站与OSS服务器之间已建立的所述运维管理通道中断的情况下，获取该基站中存储的历史通道建立参数，以便依据该历史通道建立参数，重建该运维管理通道。

在一种可能的设计中，在基站检测到基站与所述OSS服务器之间已建立的所述运维管理通道中断的情况下，获取所述基站中存储的历史通道建立参数之前，还可以执行基站的初始化，并利用初始化过程中获取到的通道建立参数，建立所述基站与所述OSS服务器之间的运维管理通道的连接；同时，当基站检测到所述运维管理通道连接成功时，将初始化过程中获取到的通道建立参数作为历史通道建立参数存储到所述基站中，以便后续该运维管理通道中断时，可以基于该历史通道建立参数重建基站与OSS服务器之间的运维管理通道。

在一种可能的设计中，基站在检测到基站在初始化过程中无法获取到建立所述运维管理通道所需的通道建立参数，或者，基站基于当前已配置的通道建立参数无法成功建立与OSS服务器之间的运维管理通道的情况下，可以获取基站中存储的历史通道建立参数，以基于该历史通道建立参数，实现基站与OSS服务器的运维管理通道的连通。

在一种可能的设计中，基站在获取所述基站中存储的历史通道建立参数之前，还可以先以广播形式发送动态主机配置协议DHCP探测消息；当基站接收到DHCP服务器针对所述DHCP探测消息返回的通道建立参数时，可以依据从该DHCP服务器获取到的通道建立参数，建立该基站与所述服务器之间的运维管理通道的连接；当未接收到针对所述DHCP探测消息的响应消息时，则执行所述获取所述基站中存储的历史通道建立参数的操作。

又一方面，本申请还提供了一种基站，该基站包括：处理器、存储器和通信接口；

其中，处理器，用于获取基站与运营支撑系统OSS服务器之间的运维管理通道的连接状态，其中，所述运维管理通道用于实现所述基站与所述OSS服务器之间的通信连接；在所述运维管理通道存在连接异常的情况下，从所述存储器中获取存储的历史通道建立参数，所述历史通道建立参数为在当前时刻之前，所述基站与所述OSS服务器建立运维管理通道所采用的通道建立参数；

通信接口，用于基于所述历史通道建立参数，建立所述基站与所述OSS服务器之间的运维管理通道的连接；

存储器，用于存储所述历史通道建立参数。

在一种可能的设计中，所述处理器在所述运维管理通道存在连接异常的情况下，从所述存储器中获取存储的历史通道建立参数时，具体用于，在检测到基站与所述OSS服务器之间已建立的所述运维管理通道中断的情况下，获取所述基站中存储的历史通道建立参数。

在一种可能的设计中，所述处理器还用于在执行所述在检测到基站与所述OSS服务器之间已建立的所述运维管理通道中断的情况下，从所述存储器中获取存储的历史通道建立参数之前，执行所述基站的初始化；

所述通信接口，还用于利用初始化过程中获取到的通道建立参数，建立所述基站与所述OSS服务器之间的运维管理通道的连接；

所述处理器，还用于当检测到所述运维管理通道连接成功时，将初始化过程中获取到的通道建立参数作为历史通道建立参数存储到所述存储器中。

在一种可能的设计中，所述基站在所述运维管理通道存在连接异常的情况下，从所述存储器中获取存储的历史通道建立参数时，具体用于，在检测到基站无法获取到建立所述运维管理通道所需的通道建立参数，或者，基站利用当前已配置的通道建立参数无法成功建立与OSS服务器之间的运维管理通道的情况下，从所述存储器中获取存储的历史通道建立参数。

在一种可能的设计中，所述处理器，还用于在获取所述基站中存储的历史通道建立参数之前，通过所述通信接口以广播形式发送动态主机配置协议DHCP探测消息；

所述通信接口，还用于以广播形式发送动态主机配置协议DHCP探测消息；当接收到DHCP服务器针对所述DHCP探测消息返回的通道建立参数时，依据从所述DHCP服务器获取到的通道建立参数，建立所述基站与所述服务器之间的运维管理通道的连接；

所述处理器在以广播形式发送动态主机配置协议DHCP探测消息时，具体用于，在所述通信接口未接收到针对所述DHCP探测消息的响应消息时，从所述存储器中获取所述基站中存储的历史通道建立参数。

本申请实施例的第二方面与第一方面的设计思路一致，技术手段类似，技术方案带来的具体有益效果请参考第一方面，不再赘述。

附图说明

图1示出了本申请实施例的通道建立方法所适用的一种应用场景的组成结构示意图；

图2示出了本申请实施例的基站的一种组成结构示意图；

图3示出了本申请实施例的通道建立方法一个流程示意图；

图4示出了本申请实施例的通道建立方法又一个流程示意图；

图5示出了本申请实施例的通道建立方法又一个流程示意图。

具体实施方式

本申请实施例的通道建立方法以及网元，适用于多种不同的通信系统。为了便于理解，以一种应用场景为例进行介绍。

如，参见图1，其示出了本申请的通道建立方法所适用的一种应用场景的组成结构示意图。

该场景可以包括：基站101以及运营支撑系统(Operation Support System，OSS)102。

需要说明的是，该基站也可以认为是一个基站子系统，基站可以为无线基站，也可以为其他类型的基站，在此不加以限制。该运营支撑系统也可以称为运行管理系统，其可以由至少一台服务器构成。如，在图1中示出了该运营支撑系统包括一台运营支撑系统服务器(OSS服务器)的情况，但是当运营支撑系统为由多台OSS服务器组成的服务器集群的情况，也同样适用于本申请实施例。

其中，基站可以与OSS服务器建立运维管理通道(Operation and ManagementChannel，OMCH)，通过该OMCH通道实现基站与OSS服务器的通信，从而使得OSS服务器可以对基站进行远程的运维管理。

可以理解的是，基站与OSS服务器建立OMCH通道之前，基站需要获取到建立OMCH所需的通道建立参数，如，该通道建立参数可以包括：基站的IP地址，OSS服务器的IP地址等。当然，通道建立参数还可以包括路由表，在该路由表中可以包括下一跳节点的IP地址。

如，参见如下表1，在表1中示出了用于建立OMCH通道的通道建立参数所包含的多种参数信息。

表1

当然，表1仅仅是一种示例，在实际应用中，通道建立参数可以包括比表1更多或者更少的参数。

为了便于理解本申请的方案，先对基站与OSS服务器之间出现OMCH中断的几种可能情况进行介绍：

在一种可能情况中，在基站开机并初始化之后，基站会与OSS服务器建立OMCH通道，但是如果基站初始化异常，导致基站无法获取到建立OMCH通道所需的通道建立参数，或者，基站利用当前数据库中的配置信息无法成功建立稳定的OMCH通道，则会使得基站与OSS服务器之间的OMCH通道处于中断状态。在该种情况下，如果基站由于缺少通道建立参数而无法实现与OSS服务器之间的OMCH通道的连通。

在又一种可能的情况中，在基站与OSS服务器之间的OMCH通道连通之后，如果基站侧出现内部缺陷或者人为的操作失误，就可能会导致基站侧与OSS服务器之间的OMCH通道连接中断。在该种情况下，如果是操作失误，可以通过回退操作，来恢复基站与OSS服务器之间的OMCH通道，但是前提是基站中必须保存操作失误之前，基站中的运行数据，否则，则会导致回退失败，从而导致恢复OMCH的复杂度较高。同时，回退操作也仅仅适用于部分操作失误，而不适用所有操作失误，也不适用基站的内部缺陷而导致的OMCH中断。

当然，导致基站与OSS服务器之间的OMCH通道处于中断状态的原因还可能有其他情况，在此不一一列举。

发明人经过对基站与OSS服务器之间出现OMCH通道中断的多种情况进行研究发现，在基站与OSS服务器之间出现OMCH通道中断之后，基站由于无法获取到用于与该OSS服务器建立OMCH通道的通道建立参数，而导致基站无法建立或者恢复与该OSS服务器之间的OMCH通道。为了进一步解决该问题，发明人经研究发现，如果在基站与OSS服务器之间的OMCH通道处于中断时，基站内保存有通道建立参数，则基站仍可以基于该通道建立参数，与OSS服务器建立OMCH连接。

基于以上研究发现，本申请在基站与OSS服务器之间的OMCH通道处于中断状态时，获取基站在当前时刻之前与OSS服务器建立OMCH通道所采用的历史通道建立参数，并基于该历史通道建立参数与OSS服务器建立通信连接。其中，为了便于区分，将当前时刻之前历史OMCH通道所采用的通道建立参数称为历史通道建立参数。

为了便于理解本申请的方案，先对基站的组成结构进行介绍。

如，参见图2，其示出了本申请一种基站的组成结构示意图。如图2，该基站200包括：处理器201、存储器202和通信接口203。

其中，处理器201用于获取基站与运营支撑系统OSS服务器之间的运维管理通道的连接状态，其中，所述运维管理通道用于实现所述基站与所述OSS服务器之间的通信连接；在所述运维管理通道存在连接异常的情况下，从所述存储器中获取存储的历史通道建立参数，所述历史通道建立参数为在当前时刻之前，所述基站与所述OSS服务器建立运维管理通道所采用的通道建立参数。

具体的，该处理器用于执行以下图3至图5所示流程中基站侧的相关操作。

存储器202用于将基站与OSS服务器建立OMCH通道所采用的通道建立参数存储为历史通道建立参数。该存储器202还可以存储通道建立参数的存储时刻以及失效时间等等。为了保证历史通道建立参数的可靠存储，该存储器可以为非易失性存储器。

其中，该存储器还可以存储处理器执行通道建立方法所需的程序，以及操作系统相关的参数，以及其他数据等。

该通信接口203用于在处理器的控制下，依据从存储器获取到的历史通道建立参数，或者通过其他方式获取并配置的通道建立参数，建立基站与OSS服务器之间的OMCH通道的连接。

同时，该通信接口还用于接收或发送基站所需的一些消息。

在一种可能的实现方式中，基站的存储器、处理器以及通信接口可以通过通信总线204相连。

当然，基站还可以包括输入装置205，如该输入装置可以为触摸屏，鼠标、键盘等等。输入单元，用于接收用户输入的指令，或者配置的参数等等。

需要说明的是，图2仅仅是基站的一种简单示意，在实际应用中，基站可以包括比图2所示的基站更多或者更少的部件，在此不加以限制。

下面结合以上共性，对本申请实施例的通道建立方法进行详细介绍。

参见图3，其示出了本申请一种通道建立方法一个实施例的流程示意图，本实施例的方法应用于基站，该方法可以包括：

S301，获取基站与运营支撑系统OSS服务器之间的运维管理通道的连接状态。

其中，该运维管理通道OMCH用于实现基站与OSS服务器之间的通信连接。

可以理解的是，OMCH的连接状态可以是基站与OSS服务器之间的OMCH处于连通状态，基站与OSS服务器之间的OMCH通道处于中断状态，或者是，基站与OSS服务器之间的OMCH未成功连接。

其中，基站的处理器获取该运维管理通道的连接状态的方式可以有多种，如，在基站初始化过程中，可以检测基站与OSS服务器之间是否成功建立OMCH通道；又如，在基站与OSS服务器之间已建立OMCH通道的情况下，监控该OMCH是否处于正常的连接状态等。

S302，在该运维管理通道存在连接异常的情况下，获取基站中存储的历史通道建立参数。

其中，该历史通道建立参数为在当前时刻之前，基站与OSS服务器建立运维管理通道所采用的通道建立参数。如，在当前时刻之前，如果基站与OSS服务器之间成功建立了运维管理通道，那么基站在检测到该运维管理通道建立成功时，会将当前成功建立该运维管理通道所采用的通道建立参数作为历史通道建立参数进行存储。

可以理解的是，通过获取基站与OSS服务器之间的运维管理通道的连接状态，可以检测出基站与该OSS服务器之间的连接异常。其中，该连接异常可以包括未成功建立运维管理通道，或者已建立的运维管理通道出现中断。

在获取到的运维管理通道的连接状态表明该运维管理通道存在连接异常的情况下，基站可以获取到当前时刻之前成功建立运维管理通道所采用的历史通道建立参数，以使得基站可以基于该历史通道建立参数，重新与OSS服务器建立运维管理通道。

可以理解的是，基站中可以仅仅保存最近一次成功与OSS服务器建立运维管理通道所采用的历史通道建立参数，也可以是保存一段时间内的历史通道建立参数。在基站中保存有多个历史通道建立参数的情况下，基站可以仅获取最近一次存储的历史通道建立参数。

S303，基于该历史通道建立参数，建立基站与该OSS服务器之间的运维管理通道的连接。

可以理解的是，由于历史通道建立参数为当前时刻之前基站与OSS服务器成功建立运维管理通道所采用的通道建立参数，因此，基站利用该历史通道建立参数，仍可以重新建立该基站与OSS服务器之间的该运维管理通道的连接。

可见，在本申请实施例中，由于基站中预先存储了当前时刻之前基站与OSS服务器建立运维管理通道所采用的历史通道建立参数，这样，在基站与OSS服务器之间的运维管理通道存在异常的情况下，基站也可以获取自身存储的该历史通道建立参数，并基于该历史通道建立参数，重新建立或者恢复该基站与OSS服务器之间的运维管理通道的连接，从而减少了由于基站无法获取到建立运维管理通道所需的通道建立参数，而无法构建或者恢复基站与OSS服务器之间的运维管理通道的情况，从而有利于保证基站与OSS服务器之间运维管理通道的可靠连通。

可以理解的是，在基站的不同运行状态下，基站检测到该基站与OSS服务器之间的OMCH通道连接异常的具体方式也会有所不同，下面分别对基站在不同运行状态的情况下出现的OMCH通道连接异常的处理过程进行介绍。

首先对在基站运行中，且在基站与OSS服务器建立了OMCH通道之后，该OMCH通道中断的情况进行介绍，如，参见图4，其示出了本申请一种通道建立方法又一个实施例的流程交互示意图，本实施例的方法可以包括：

S401，基站启动并完成初始化。

S402，基站基于初始化过程中获取到的通道建立参数，与OSS服务器建立OMCH通道连接。

其中，该通道建立参数为用于建立OMCH通道连接所需的参数，该通道建立参数可以包括：该基站的IP地址，OSS服务器的IP地址，还可以包括路由表。当然，该通道建立参数还可以包括其他参数，如，可以包括表1中所示出的部分或者全部参数。

可以理解的是，在基站启动之后，基站的处理器可以获取用户配置基站的相关数据，，并利用配置数据对基站进行配置，以完成基站的初始化。其中，在基站初始化过程中，基站配置的数据可以包括用于建立OMCH通道所需的相关参数，这样，在基站初始化完成之后，基站的处理器获取到已配置的用于建立OMCH所需的相关参数，并完成相关配置，这样，处理器可以控制通信接口利用这些相关参数，建立与OSS服务器之间的OMCH链路连接。

如，基站进行初始化的过程中，基站会获取配置表，例如，从数据库中获取配置表或者获取自身保存的配置表，其中，该配置表中可以包括该通道建立参数，这样，在基站的处理器可以在基站中配置通道建立参数，以及其他相关配置，如，在基站中配置该基站的IP地址以及路由表等，以使得基站可以接收向该基站的IP地址发送的消息，并依据路由表向OSS服务器发送消息。相应的，当通道建立参数以及相关配置完成之后，基站具备与OSS服务器建立OMCH通道的条件，从而可以通过通信接口与OSS服务器建立OMCH通道。

可以理解的是，基站基于通道建立参数与OSS服务器建立OMCH通道连接的方式可以有多种，为了便于理解，以一种可能的情况进行举例说明：

如，OSS服务器可以依据基站的IP地址周期性向该基站发送OMCH建链请求，其中，该OMCH建链请求用于指示基站建立与该OSS服务器之间的OMCH通道；在基站完成用于建立OMCH的通道建立参数的配置之后，基站便可以接收到该OMCH建链请求，这样，基站会响应该OMCH建链请求，并向OSS服务器返回OMCH建链响应，从而在基站与OSS服务器之间成功建立OMCH通道。

需要说明的是，以上仅仅是基站基于通道建立参数与OSS服务器建立OMCH通道连接的一种可能的实现方式，在实际应用中，还可以有其他方式，对于基站基于该通道建立参数与OSS服务器建立OMCH通道的其他方式也同样适用于本申请。

S403，基站将当前建立该OMCH通道所采用的该通道建立参数作为历史通道建立参数，保存到该基站中指定存储区。

在本申请实施例中，基站完成与OSS服务器的OMCH通道的建立之后，基站的存储器会存储该通道建立参数，以便后续由于基站中存在人为操作失误或者故障，而导致基站与OSS服务器之间的OMCH通道中断时，利用备份的该通道建立参数重新建立OMCH通道。

可以理解是，由于该通道建立参数为当前时刻之前建立OMCH通道所采用的参数，因此，基站将该通道建立参数存储为历史建立OMCH通道所采用的历史通道建立参数。

其中，该指定存储区可以根据需要设定，为了避免基站由于断电等原因而导致历史通道建立参数的丢失，该指定存储区可以为基站的非易失性存储器中的指定存储区。如，可以在非易失性存储器中目标文件，并能够将该历史通道建立参数存储到该目标文件中。

可以理解的是，考虑到不同时刻基站与OSS服务器建立OMCH通道所采用的通道建立参数有可能会有所差异，如，网络系统更新、基站或者OSS服务器存在更新的情况下，通道建立参数也会有所更新，因此，在基站保存了该历史通道建立参数之后，如果后续基站检测到该基站利用自身配置的通道建立参数再次与该OSS服务器建立OMCH通道连接时，则重新获取当前建立OMCH通道所用的通道建立参数，并将当前获取到的通道建立参数作为最新的历史通道建立参数，并利用最新的历史通道建立参数覆盖该历史通道建立参数。如，删除当前时刻之前保存的历史通道建立参数，并保存当前获取到的最新的历史通道建立参数。

需要说明的是，以上步骤S401至步骤S403并非是本申请在基站与OSS服务器之间的OMCH通道中断的情况下，基站所需执行的操作，而仅仅是为了便于理解，在基站与OSS服务器之间的OMCH中断之前所进行的准备操作。在实际应用中，无需每次都执行以上步骤S401至S403。

S404，当基站检测到基站与OSS服务器之间建立的该OMCH通道中断的情况下，基站以广播形式发送动态主机配置协议(Dynamic HostConfigurationProtocol，DHCP)探测消息。

可以理解的是，基站检测该OMCH通道中断的方式可以有多种，如，基站可以定期通过OMCH通道向OSS服务器发送心跳消息，OSS服务器接收到心跳消息之后可以反馈一个连通指示，如果基站连续预设次数发送心跳消息失败，或者基站指定时长内无法接收到OSS发送的连通指示，则可以确定基站与OSS服务器之间的OMCH通道连接中断。当然，对于基站通过其他方式检测出该OMCH通道中断的情况也同样适用于本申请实施例。

其中，该DHCP探测消息为用于向DHCP服务器请求通道建立参数。其中，DHCP服务器可以为OSS服务器，也可以是单独设置的独立于OSS服务器之外的服务器。

其中，该DHCP探测消息携带有用于标识该基站的唯一标识。如，该基站的唯一标识可以为基站的设备编号；又如，在基站的IP地址未丢失的情况下，该基站的唯一标识为该基站的IP地址。

其中，基站通过通信接口以广播形式向外发送DHCP探测消息实际上就是基站发起DHCP探测。为了便于理解，对DHCP探测的一种可能方式进行简单介绍：以DHCP探测消息为DHCP报文为例，在基站启动DHCP过程之后，基站向外广播DHCP报文，其中，该DHCP报文中携带有该基站的唯一标识，例如，该基站的唯一标识可以为基站的电子序列号(ElectronicSerial Numbe，ESN)。如果DHCP服务器接收到基站广播的该DHCP报文，则根据该基站的唯一标识，从该DHCP服务器关联的数据库中查询是否维护有该基站的唯一标识对应的基站的IP地址以及OSS服务器的IP地址等通道建立参数，如果查询到该基站的唯一标识对应通道建立参数，则该DHCP服务器向该基站发送DHCP响应报文，该DHCP响应报文中携带有该通道建立参数，如，该基站的IP地址，以及OSS服务器的IP地址、路由表等。

其中，该DHCP服务器中预先存储有多个不同基站的标识对应的通道建立参数，如，可以由管理人员将包含通道建立参数的配置文件导入到该DHCP服务器。该配置文件中可以包括基站、OSS服务器的IP地址以及路由表，还可以包括硬件参数、传输参数等等。

可以理解的是，在该DHCP服务器中查询不到与该基站的唯一标识对应的通道建立参数，则说明DHCP服务器中尚未配置该基站对应的通道建立参数，在该种情况下，DHCP服务器可以输出提示信息，以提示管理人员输入该基站对应的通道建立参数。

S405，基站检测是否接收到DHCP服务器针对该DHCP探测消息返回通道建立参数，如果是，则执行步骤S406；如果否，则执行步骤S407。

可以理解的是，DHCP服务器上预先配置了通信网络中不同基站对应的通道建立参数，如，DHCP服务器中可以存储不同基站的唯一标识与通道建立参数之间的映射关系，在DHCP接收到该探测消息之后，可以向外发送该基站对应的通道建立参数，以使得基站可以通过通信接口接收到该通道建立参数。

S406，基站基于探测到的通道建立参数，建立基站与该OSS服务器之间的OMCH通道。

如果基站的通信接口接收到针对该探测消息返回的通道建立参数，则说明DHCP探测成功，从而使得基站的处理器可以利用探测到的通道建立参数，控制通信接口与OSS服务器建立OMCH通道。

如，基站可以加载探测到的通道建立参数，以完成建立OMCH相关的配置，然后基于该通道建立参数与OSS服务器建立OMCH通道。

可以理解的是，在基站基于通道建立参数与OSS服务器建立OMCH通道的方式，与基站利用自身配置的通道建立参数与OSS服务器建立OMCH通道的过程相似，具体可以参见前面步骤S402的相关介绍，在此不再赘述。

需要说明的是，在OMCH通道中断的情况下，基站以广播形式发送DHCP探测消息，以进行DHCP探测的过程仅仅是为了进一步提高获取通道建立参数的可靠性。但是可以理解的是，在实际应用中，也可以根据需要不执行以上步骤S404到S406的探测过程，而执行直接步骤S407，以获取用于建立OMCH通道的通道建立参数。

S407，基站从指定存储区获取存储的历史通道建立参数。

在基站通过DHCP探测未探测到通道建立参数，或者DHCP探测失败，则基站的处理器可以从指定存储区中获取存储的历史通道建立参数，由于历史通道建立参数为当前时刻之前，基站与OSS服务器建立OMCH通道所采用的通道建立参数，如，该历史通道建立参数可以为基站最近一次成功与OSS服务器建立OMCH通道所采用的通道建立参数，因此，基站可以利用存储的该历史通道建立参数作为当前恢复OMCH通道连通所需的通道建立参数。

S408，基站基于该历史通道建立参数，建立与该OSS服务器之间的OMCH连接。

如，基站将历史通道建立参数作为建立OMCH通道所需的通道建立参数，并加载该历史通道参数，从而基于加载的历史通道建立参数与OSS服务器建立OMCH连接。

其中，基站利用历史通道建立参数与OSS服务器建立OMCH的链路连接的过程与前面基站初始化之后，利用获取到的通道建立参数与OSS服务器建立OMCH通道的过程相似。如，基站可以在检测到OSS服务器的OMCH建链请求之后，响应该OMCH建链请求，并向OSS服务器返回OMCH建链响应，以使得OSS服务器连通基站与该OSS之间的OMCH通道。具体可以参见前面的相关介绍，在此不再赘述。

可以理解的是，在以上实施例中任意建立OMCH连接的步骤中，基站在基于历史通道建立参数、实时获取的已配置的通道建立参数或者探测到的通道建立参数，与OSS服务器建立OMCH连接之前，基站可以检测基站中用于建立OMCH的物理端口(即出物理端口)是否正常，如果该物理端口正常，则激活该物理端口，并加载通道建立参数的配置，然后在向OSS服务器返回OMCH建链响应时，通过该物理端口向外传输该OMCH建链响应。

可见，在本实施例中，在基站与OSS服务器建立的OMCH通道之后，基站可以将建立OMCH通道所采用的通道建立参数存储为历史通道建立参数，这样，该基站与OSS之间的OMCH连接中断时，基站可以获取基站中保存的历史通道建立参数，并利用历史通道建立参数重新与OSS服务器建立OMCH通道，从而有利于保证了基站与OSS服务器之间OMCH的可靠连接，减少了由于基站中人为操作失误或者基站内部故障，而导致基站无法重新与OSS服务器建立OMCH连接的情况，从而可以减少运维人员亲临基站进行运维管理的次数，有利于减少人力资源的耗费。

下面对在基站由于初始化异常，而导致基站无法与OSS服务器建立OMCH通道，使得基站与OSS服务器之间的OMCH存在连接异常的情况下，基站建立OMCH通道的过程进行介绍。如，参见图5，其示出了本申请一种通道建立方法又一个实施例的流程交互示意图，本实施例的方法可以包括：

S501，基站启动并进行初始化。

S502，当基站检测到初始化异常时，检测基站是否完成用于建立OMCH所需的通道建立参数的配置，如果是，则执行步骤S503；如果否，则执行步骤S504。

可以理解的是，在基站初始化异常的情况下，可能会导致基站配置用于建立OMCH通道的通道建立参数的配置错误或者配置失败，从而使得基站无法与OSS服务器建立OMCH连接，使得基站与OSS服务器之间的OMCH通道存在连接异常。

需要说明的是，步骤S502仅仅是以基站由于初始化异常而导致基站无法与OSS服务器建立OMCH连接的一种情况为例进行说明，但是可以理解的是，在基站由于初始化异常而导致基站无法与OSS服务器成功建立OMCH连接的原因还可以有其他可能，如，由于初始化异常，对于其他可能情况，也同样适用于本实施例。

S503，基站基于已配置的通道建立参数，与OSS服务器建立OMCH连接。

该步骤S503可以参见前面实施例的相关介绍，在此不再赘述。

S504，基站检测当前是否具备DHCP探测的条件，如果是，则执行步骤S505；如果否，则执行步骤S508。

如果基站由于初始化异常，而导致基站无法执行DHCP探测，或者基站本身不具备DHCP探测的功能，则基站不具备DHCP探测的条件。

可以理解的是，在基站具备DHCP探测条件的情况下，基站可以发起后续步骤S505的DHCP探测；如果基站不具备DHCP探测的条件，基站仍可以通过执行后续的步骤S508的操作，来完成基站与OSS服务器之间OMCH通道的建立。

需要说明的是，在实际应用中，如果也可以不执行该步骤S504，而直接执行DHCP探测也同样适用于本实施例。

S505，基站以广播形式发送DHCP探测消息。

S506，基站检测是否接收到DHCP服务器针对该探测消息返回通道建立参数，如果是，则执行步骤S507；如果否，则执行步骤S508。

S507，基站基于探测到的通道建立参数，建立基站与该OSS服务器之间的OMCH通道。

其中，该步骤S505至步骤S507的操作可以参见前面实施例的相关介绍，在此不再赘述。

S508，基站从指定存储区获取存储的历史通道建立参数。

在本申请实施例中，该历史通道建立参数可以为当前时刻之前，基站与OSS服务器建立OMCH通道所采用的通道建立参数。如，在基站本次启动之前，基站之前与OSS服务器建立OMCH通道所采用的通道建立参数，又如，在基站本次启动之前，基站最近一次与OSS服务器建立OMCH通道所采用的通道建立参数。

其中，该指定存储区可以根据需要设定，如该指定存储区可以为非易失性存储器的存储区。

S509，基站基于该历史通道建立参数，建立与该OSS服务器之间的OMCH连接。

其中，该步骤S509可以参见前面实施例的相关介绍，在此不再赘述。

可见，在本申请实施例中，在基站由于初始化异常等原因，而导致基站无法与OSS服务器建立OMCH通道的情况下，基站可以利用DHCP探测探测到通道建立参数，或者是预先存储的历史通道建立参数，来实现基站与OSS服务器之间OMCH通道的建立，从而可以减少基站无法与OSS服务器建立OMCH连接的情况，进而可以减少运维人员亲临基站进行运维管理的次数，有利于减少人力资源的耗费。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可能全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介绍传输。例如，所述计算机指令可以从一个网站站点、计算机、服务器或者数据中心通过有线(例如同轴电缆、光纤、数字用户(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如DVD)、或者半导体介质(例如固态硬盘(Solid State Disk(SSD))等。

以上所述的具体实施方式，对本申请的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本申请的具体实施方式而已，并不用于限定本申请的保护范围，凡在本申请的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本申请的保护范围之内。

Claims (10)

1.一种通道建立方法，其特征在于，包括：

获取基站与运营支撑系统OSS服务器之间的运维管理通道的连接状态，其中，所述运维管理通道用于实现所述基站与所述OSS服务器之间的通信连接；

在所述运维管理通道存在连接异常的情况下，获取所述基站中存储的历史通道建立参数，所述历史通道建立参数为在当前时刻之前，所述基站与所述OSS服务器建立运维管理通道所采用的通道建立参数；

基于所述历史通道建立参数，建立所述基站与所述OSS服务器之间的运维管理通道的连接。

2.根据权利要求1所述的通道建立方法，其特征在于，所述在所述运维管理通道存在连接异常的情况下，获取所述基站中存储的历史通道建立参数，包括：

在检测到基站与所述OSS服务器之间已建立的所述运维管理通道中断的情况下，获取所述基站中存储的历史通道建立参数。

3.根据权利要求1所述的通道建立方法，其特征在于，在所述在检测到基站与所述OSS服务器之间已建立的所述运维管理通道中断的情况下，获取所述基站中存储的历史通道建立参数之前，还包括：

执行所述基站的初始化，并基于初始化过程中获取到的通道建立参数，建立所述基站与所述OSS服务器之间的运维管理通道的连接；

当检测到所述运维管理通道连接成功时，将初始化过程中获取到的通道建立参数作为历史通道建立参数存储到所述基站中。

4.根据权利要求1所述的通道建立方法，其特征在于，所述在所述运维管理通道存在连接异常的情况下，获取所述基站中存储的历史通道建立参数，包括：

在检测到基站在初始化过程中无法获取到建立所述运维管理通道所需的通道建立参数，或者，基站利用当前已配置的通道建立参数无法成功建立与OSS服务器之间的运维管理通道的情况下，获取所述基站中存储的历史通道建立参数。

5.根据权利要求1至4任一项所述的通道建立方法，其特征在于，在所述获取所述基站中存储的历史通道建立参数之前，还包括：

以广播形式发送动态主机配置协议DHCP探测消息；

当接收到DHCP服务器针对所述DHCP探测消息返回的通道建立参数时，依据从所述DHCP服务器获取到的通道建立参数，建立所述基站与所述服务器之间的运维管理通道的连接；

当未接收到针对所述DHCP探测消息的响应消息时，执行所述获取所述基站中存储的历史通道建立参数。

6.一种基站，其特征在于，包括：

处理器、存储器和通信接口；

其中，所述处理器，用于获取基站与运营支撑系统OSS服务器之间的运维管理通道的连接状态，其中，所述运维管理通道用于实现所述基站与所述OSS服务器之间的通信连接；在所述运维管理通道存在连接异常的情况下，从所述存储器中获取存储的历史通道建立参数，所述历史通道建立参数为在当前时刻之前，所述基站与所述OSS服务器建立运维管理通道所采用的通道建立参数；

所述通信接口，用于基于所述历史通道建立参数，建立所述基站与所述OSS服务器之间的运维管理通道的连接；

所述存储器，用于存储所述历史通道建立参数。

7.根据权利要求6所述的基站，其特征在于，所述处理器在所述运维管理通道存在连接异常的情况下，从所述存储器中获取存储的历史通道建立参数时，具体用于，在检测到基站与所述OSS服务器之间已建立的所述运维管理通道中断的情况下，获取所述基站中存储的历史通道建立参数。

8.根据权利要求6所述的基站，其特征在于，所述处理器还用于在执行所述在检测到基站与所述OSS服务器之间已建立的所述运维管理通道中断的情况下，从所述存储器中获取存储的历史通道建立参数之前，执行所述基站的初始化；

所述通信接口，还用于基于初始化过程中获取到的通道建立参数，建立所述基站与所述OSS服务器之间的运维管理通道的连接；

所述处理器，还用于当检测到所述运维管理通道连接成功时，将初始化过程中获取到的通道建立参数作为历史通道建立参数存储到所述存储器中。

9.根据权利要求6所述的基站，其特征在于，所述基站在所述运维管理通道存在连接异常的情况下，从所述存储器中获取存储的历史通道建立参数时，具体用于，在检测到基站无法获取到建立所述运维管理通道所需的通道建立参数，或者，基站利用当前已配置的通道建立参数无法成功建立与OSS服务器之间的运维管理通道的情况下，从所述存储器中获取存储的历史通道建立参数。

10.根据权利要求6至9任一项所述的基站，其特征在于，所述处理器，还用于在获取所述基站中存储的历史通道建立参数之前，通过所述通信接口以广播形式发送动态主机配置协议DHCP探测消息；

所述通信接口，还用于以广播形式发送动态主机配置协议DHCP探测消息；当接收到DHCP服务器针对所述DHCP探测消息返回的通道建立参数时，依据从所述DHCP服务器获取到的通道建立参数，建立所述基站与所述服务器之间的运维管理通道的连接；

所述处理器在以广播形式发送动态主机配置协议DHCP探测消息时，具体用于，在所述通信接口未接收到针对所述DHCP探测消息的响应消息时，从所述存储器中获取所述基站中存储的历史通道建立参数。