CN1964277A - 通讯系统和方法 - Google Patents

Abstract

本发明提供一种通信系统和方法。该通讯系统包括基站和网络控制管理装置，所述基站在接收到来自用户终端的告警信息，或自己产生故障，或接收到来自网络控制管理装置的告警请求时，通过告警通知将相关的告警信息通知网络控制管理装置。

Description

通讯系统和方法

技术领域

本发明涉及一种通讯系统和方法，特别涉及一种WiMAX通讯系统和方法。

背景技术

按照ISO对网络管理功能的划分，网络管理主要由5个部分组成，即FCAPS，它们分别是：故障管理(Fault)、配置管理(Configuration)、计费管理(Accounting)、性能管理(Performance)和安全管理(Security)，这些管理功能通过具体的网络管理系统来实现。网络管理系统的概念模型主要由管理者、管理代理和被管对象等实体及其相互作用组成。

故障/告警管理实现对数据网内所有网元设备的告警监测和故障定位，配合运行管理功能进行故障排除和系统设备复测，还能收集和处理各网元(NE)的各种故障、告警及网络状态异常信息，并具有各种分类统计和指导分析的功能。

告警/故障管理主要包括以下内容：告警数据的采集和存储、定制告警分类和级别、告警数据过滤和相关性分析、告警的实时显示和生成报表、告警/故障处理、告警/故障数据库的维护以及与知识库系统的接口等。故障/告警管理以工作流的方式，提供了网管的自动化功能，通过一系列的工具和接口，帮助系统人员完成日常维护和管理工作。

WiMAX是一项无线城域网接入技术，其最大传输速度75Mbit/秒，信号传输半径达到50公里，基本上能覆盖到城郊。由于这种远距离传输特性，WiMAX将不仅仅是解决无线接入的技术，还能作为有线网络接入(Cable、DSL)的无线扩展，方便地实现边远地区的网络连接。具有广阔的应用前景。

在WiMAX的技术应用场景下，涉及到对接入侧两个新引入网元BS和SS/MSS网元在网管侧的集中管理。实际运行环境中，BS和SS/MSS的数量将随着开户用户数而增长，并且根据使用用户的地理位置分散在广阔的覆盖区域内。在这种情况下，当系统的网管告警管理提出了更高的要求，如果能够从网管中心完成所有的BS/SS/MSS(基站/订户/移动订户)进行有效、可靠的操作，是对人力资源和维护资金的巨大节省。

图1所示的网络接口模型描述了多个FS(固定订户)/MS(SS/MSS)10与BS11的连接，所有BS11与一NCMS(网络控制和管理系统)12相连。FS/MS通过U接口使用首要管理连接或者次要管理连接与BS11进行通信，而MSS通常只会通过U接口使用首要管理连接来进行管理和相关控制功能。

网络的每个层次都要运行与该层次功能相适应的软件或硬件，这个硬件或者软件的运行活动称之为该层次的″实体″。每一个实体都要向它的上一层提供支撑功能，提供支撑服务的方式是通过一个称为“服务访问点”(ServiceAccess Point/简称SAP)的接口来提供的。

SAP实际上是一个确定的数据结构，它定义了两个功能层次之间的交互所需要的所有内容，两个相邻层之间的一切相关的参数都通过这个地方来交换。

在实施通信时，相互通信的计算机节点之间的信息交互都可以借助层间服务来反映，每一层功能层都利用它的紧邻的下一层提供的服务来实现本层次的功能。它可以认为只是它的下一层在为它提供相应的服务。而可以对下一层以下的各个层次的工作不加领会。

NCMS(网络控制和管理系统)由多个网络功能实体构成，这些实体可以在网络中集中化布置，也可以在网络中分布式布置。

SS/MSS与BS使用U接口通信，可以使用首要管理连接(primarymanagement connection)，也可以使用次要管理连接(secondary managementconnection)。

BS与NCMS的接口

该接口由一系列的业务接入点，Service Access Points(SAP)，及其所代表的接口组成，可以分为两部分：管理SAP和控制SAP，管理SAP只用于管理源语，而控制SAP用于控制平面的源语，它支持切换，安全内容管理，无线资源管理、以及低能耗操作(如休闲模式和寻呼功能)。该接口的首要目标是实现接口与协议的分离，源语不定义端到端的具体协议。

管理业务接入点(Management SAP(M_SAP))，包括但不限定于以下的相关源语：系统配置(System configuration)；监控统计(MonitoringStatistics)；通告/触发(Notifications/Triggers)。

控制业务接入点(Control SAP(C_SAP))，可包括但不限定于以下的相关源语：切换(Handovers(例如，来自MS的HO请求通知等))；空闲模式的移动性管理(Idle mode mobility management(例如移动登陆空闲模式))；订户和会话管理(Subscriber and session management(例如，移动请求会话设置))；无线资源管理(Radio resource management，等-AAA服务信令(例如，EAP负载))。

现有技术中还没有NCMS可以对散布在网络中的大量网元(BS/SS/MSS)进行故障/告警管理的技术。

发明内容

本发明的目的在于提供一种NCMS可以对散布在网络中的大量网元(BS/SS/MSS)进行故障/告警管理的通信系统和方法。

依照本发明的通讯系统，包括基站和网络控制管理装置，所述基站在接收到来自用户终端的告警信息，或自己产生故障，或接收到来自网络控制管理装置的告警请求时，通过告警通知将相关的告警信息通知网络控制管理装置。

依照本发明的通讯方法，包括：当基站接收到来自用户终端的告警信息，或自己产生故障，或接收到来自网络控制管理装置的告警请求时，通过告警通知将相关的告警信息从基站通知网络控制管理装置的步骤。

依照本发明，能够实现从NCMS中网络管理实体对散布在网络中的大量网元(BS/SS/MSS)的故障/告警管理的功能，根据本发明提出的BS与NCMS之间告警信息通信的源语及其处理流程，以及BS与SS/MSS之间的告警消息通信方式，解决了WiMax相关SS/MSS/BS的故障/告警管理的问题。

附图说明

图1为802.16g的网络参考模型。

图2为BS将告警源语主动通知NCMS的一种方式的流程图。

图3为BS将告警源语主动通知NCMS的另一种方式的流程图。

图4为BS将告警源语主动通知NCMS的另一种方式的流程图。

图5为BS在接到NCMS的告警请求之后将告警源语通知NCMS的一种方式的流程图。

图6为BS在接到NCMS的告警请求之后将告警源语通知NCMS的另一种方式的流程图。

图7为BS在接到NCMS的告警请求之后将告警源语通知NCMS的另一种方式的流程图。

图8为BS在接到NCMS的告警请求之后将告警源语通知NCMS的另一种方式的流程图。

具体实施方式

依照本发明的WiMax(World Interoperability for Microwave Access，全球微波接入互操作性)通信系统包括一BS(基站)11和一NCMS(NetworkControl and Management System，网络控制和网管系统)12。

如图2-4所示，BS11可以在下述的三种情况下，将告警源语/消息(Fault_Information)主动通知NCMS12。这三种情况为：

1.当BS11收到SS/MSS(接入用户)(图未示)发来的MAC管理告警消息时。

2.当BS11收到SS/MSS发来的SNMP Trap(SNMP自陷)时。

3.当BS11自己产生故障/告警时。

下面，结合附图，对这三种情况进行详细描述。

如图2所示，其描述了SS/MSS通过MAC管理告警消息(NTF_IE_REQ)上报BS11后，BS11将告警源语(Fault_Information)发送给NCMS12中的网络实体的流程图。

在该实施方式中，BS11收到SS/MSS上报的告警消息(NTF_IE_REQ)后，终结SS/MSS的告警报文(NTF_IE_REQ)，将告警应答(NTF_IE_RSP)发送至SS/MSS，并生成告警源语Fault_Information，并通知NCMS12，一个SS/MSS有故障/告警。

当NCMS12收到该告警源语Fault_Information后，不需要作出回应，该源语过程结束。

如图3所示，其描述了SS/MSS通过SNMP Trap将告警消息上报BS11后，BS11将告警源语(Fault_Information)发送给NCMS12中的网络实体。

在该实施方式中，BS11收到SS/MSS上报的告警消息(SNMP Trap)后，终结SS/MSS的告警报文，生成告警源语Fault_Information，并通知NCMS12，一个SS/MSS有故障/告警。

当NCMS12收到该告警源语Fault_Information信息后，不需要作出回应，该源语过程结束。

在本发明中，可以通过设置来确定SS/MSS使用哪一种方式(MAC管理告警消息或SNMP Trap)进行上报，也可以进行动态调整来选择上报的方式。例如，当IP协议不通时，可以自动切换到MAC管理报文的方式。

如图4所示，其描述了BS11自己产生故障/告警后，BS11将告警源语(Fault_Information)发送给NCMS12中的网络实体。

该Fault_Information由BS11发出，通知NCMS12，BS11有故障/告警。

下面，具体描述告警源语(Fault_Information)的结构的一个例子。

Fault_information

(

SS/MSS/BS ID

Transaction ID

AlarmID

AlarmType

AlarmSequenceNo

AlarmSeverityLeve

AlarmProbableCause

AlarmState

AlarmRaisedTime

)

在该Fault_Information中，SS/MSS/BS ID是48比特的SS/MSS/BS标识ID。Transaction ID是由BS11产生的会话标识ID。AlarmID是对应一种告警描述的ID，AlarmType是告警类型，如0表示通信告警，1表示处理错误告警，2表示环境告警，3表示qos告警，4表示设备告警。AlarmSequenceNo是告警序列号，由BS11产生，用于标识每一条告警。AlarmSeverityLeve是告警严重级别，例如：0表示致命告警，1表示重要告警，2表示一般告警，3表示警告告警，4表示未确定，5表示未清除。AlarmProbableCause为告警可能的原因。AlarmState为告警声明，如该告警是否已经恢复等信息。AlarmRaisedTime为告警发生时间。

在本发明中，除了可以由BS11主动将告警通知NCMS12之外，NCMS12还可以通过将告警请求(Fault_List_Request)发送至BS11来获取BS11以及该BS11所辖范围的SS/MSS目前所存在的告警。

BS11中存储的告警信息分为两种情况：

情况1.BS11中存储有所有SS/MSS的当前的所有告警信息；

情况2.BS11中不存储SS/MSS的告警信息，只存储自己本身的告警信息。

如果在情况1中NCMS12期望获得BS11以及所有SS/MSS的告警信息，或者在情况2中NCMS12期望获得BS11的告警信息时，BS11和NCMS12之间的流程如图5所示。

如图5所示，NCMS12生成告警请求(Fault_List_Request)，并将该告警请求发送至BS11。BS11响应该告警请求将相应的告警信息通过告警响应(Fault_List_Response)发送给NCMS12。

Fault_List_Request在NCMS12中的网络管理实体通知BS11上报告警信息时产生，用于通知BS11上报现有的故障/告警。

下面，描述Fault_List_Request的结构的一个例子。

Fault_List_Request

(

SS/MSS/BS ID

Transaction ID

BeginTime

EndTime

)

其中，SS/MSS/BS ID为48比特的SS/MSS/BS标识ID，可以使用一个特殊的标识ID来表示需要上报所有的SS/MSS/BS的告警信息。Transaction ID是由NCMS12产生的会话标识ID。BeginTime表示查询的起始时间。EndTime表示查询的终止时间。

BS11收到该告警请求Fault_List_Request后，根据请求中的告警起始和终止时间通过告警响应(Fault_List_Response)反馈告警信息。

该告警响应Fault_List_Response由BS11发出，上报NCMS12中网管实体，反馈现有的故障/告警。

下面，描述Fault_List_Response的结构的一个例子。

Fault_List_Response

(

SS/MSS/BS ID

Transaction ID

AlarmType

AlarmSequenceNo

AlarmSeverityLeve

AlarmProbableCause

AlarmState

AlarmRaisedTime

)

其中，SS/MSS/BS ID是48比特的SS/MSS/BS标识ID。Transaction ID是由BS11产生的会话标识ID。AlarmType是告警类型，如0表示通信告警，1表示处理错误告警，2表示环境告警，3表示qos告警，4表示设备告警。AlarmSequenceNo是告警序列号，由BS11产生，用于标识每一条告警。AlarmSeverityLeve是告警严重级别，例如：0表示致命告警，1表示重要告警，2表示一般告警，3表示警告告警，4表示未确定，5表示未清除。AlarmProbableCause为告警可能的原因。AlarmState为告警声明，如该告警是否已经恢复等信息。AlarmRaisedTime为告警发生时间。

下面，参照图6-7，描述NCMS12在BS11中存储的信息为情况2时只要求查询SS/MSS的告警信息的流程。

如图6所示，NCMS12发送Fault_List_Request给BS11，BS11收到该Fault_List_Request之后，通过SNMP查询报文(Fault Query)查询SS/MSS中的告警消息，SS/MSS通过SNMP应答报文(Fault RSP)将其告警消息通知BS11。当需要查询多个SS/MSS时，需要分别轮循每个需要查询的SS/MSS，直到完成所有的查询。如果一个SS/MSS有多个告警消息时，则SS/MSS需要多个反馈多个告警消息。当BS11接收到Fault_List_Request所要求的来自SS/MSS的所有告警消息之后，通过Fault_List_Response将相关的告警信息发送至NCMS12。

如图7所示，NCMS12发送Fault_List_Request给BS11，BS11收到该Fault_List_Request之后，通过MAC管理报文(QRY_IE_REQ)查询SS/MSS中的告警消息，SS/MSS通过MAC管理报文(QRY_IE_RSP)将其告警消息通知BS11。当需要查询多个SS/MSS时，需要分别轮循每个需要查询的SS/MSS，直到完成所有的查询。如果一个SS/MSS有多个告警消息时，则SS/MSS需要多个反馈多个告警消息。当BS11接收到Fault_List_Request所要求的来自SS/MSS的所有告警消息之后，通过Fault_List_Response将相关的告警信息发送至NCMS12。

在图6和7所示的例子中，Fault_List_Request和Fault_List_Response的结构与图5所示的例子中的Fault_List_Request和Fault_List_Response相似，在此不在详细描述。

在本发明中，可以由NCMS12通过将告警控制(Fault_Control_Request)发送至BS11来设置SS/MSS/BS的告警状态。SS/MS/BS根据控制信息来进行相应的动作，比如清除告警信息等。

下面，描述Fault_Control_Request的结构的一个例子。

Fault_Control_Request

(

SS/MSS/BS ID

Transaction ID

AlarmType

AlarmSequenceNo

AlarmSeverityLevel

Alarm ProbableCause

AlarmState

AlarmRaiseTime

)

其中，SS/MSS/BS ID是48比特的SS/MSS/BS标识ID。Transaction ID是由BS11产生的会话标识ID。AlarmType是告警类型，如0表示通信告警，1表示处理错误告警，2表示环境告警，3表示qos告警，4表示设备告警。AlarmSequenceNo是告警序列号，由BS11产生，用于标识每一条告警。AlarmSeverityLeve是告警严重级别，例如：0表示致命告警，1表示重要告警，2表示一般告警，3表示警告告警，4表示未确定，5表示未清除。AlarmProbableCause为告警可能的原因。AlarmState为告警声明，如是否恢复该告警等信息。AlarmRaiseTime为告警发生时间。

BS11收到该告警请求Fault_Control_Request后，根据请求中的告警控制信息通过控制响应(Fault_Control_Response)反馈告警操作结果。

下面，描述Fault_Control_Response的结构的一个例子。

Fault_Control_Response

(

SS/MSS/BS ID

Transaction ID

AlarmType

AlarmSequenceNo

AlarmSeverityLeve

AlarmProbableCause

AlarmState

AlarmRaisedTime

)

其中，SS/MSS/BS ID是48比特的SS/MSS/BS标识ID。Transaction ID是由BS11产生的会话标识ID。AlarmType是告警类型，如0表示通信告警，1表示处理错误告警，2表示环境告警，3表示qos告警，4表示设备告警。AlarmSequenceNo是告警序列号，由BS11产生，用于标识每一条告警。AlarmSeverityLeve是告警严重级别，例如：0表示致命告警，1表示重要告警，2表示一般告警，3表示警告告警，4表示未确定，5表示未清除。AlarmProbableCause为告警可能的原因。AlarmState为告警声明，如是否恢复该告警等信息。AlarmRaiseTime为告警发生时间。

如图8所示，NCMS12发送Fault_Control_Request给BS11，BS11收到该Fault_Control_Request之后，通过MAC管理报文(SET_IE_REQ)设置SS/MSS中的告警状态，SS/MSS通过MAC管理报文(SET_IE_RSP)将其更新后的告警状态通知BS11。当BS11接收到SET_IE_RSP消息之后，通过Fault_Control_Response将相关的告警信息发送至NCMS12。

在本发明中，源语/消息中SS/MSS/BS ID可以换为OID(Object ID(MIB(管理信息库)库中)表示对象的ID)来表示。此外，源语/消息Fault_List_Response参数结构可以与Fault_Information参数结构相同，可以用Fault_Information来替代Fault_List_Response。

依照本发明，SS/MSS可以使用两种技术方法来上报告警，SS/MSS通过MAC管理报文的途径上报告警消息方法，SS/MSS通过SNMP的方式上报告警消息，这样可以提高系统的灵活性和可靠性。

本发明提供了BS与NCMS的通信源语和流程，充分考虑到了各种实现方式，方便操作员对系统运行状态的监控。

本发明在提供了从NCMS到SS/MSS的管理方法，在网络维护操作中可以节省大量的人力和资金成本，直接提升客户满意度。

Claims (17)

1.一种通讯系统，其包括基站和网络控制管理装置，其中

所述基站在接收到来自用户终端的告警信息，或自己产生故障，或接收到来自网络控制管理装置的告警请求时，通过告警通知将相关的告警信息通知网络控制管理装置。

2.如权利要求1所述的通信系统，其中.

该通讯系统为WiMAX系统。

3.如权利要求2所述的通信系统，其中，

来自用户终端的告警信息为MAC管理告警消息或SNMP Trap消息。

4.如权利要求2所述的通信系统，其中，

所述基站存储有所有用户终端的当前的所有告警信息。

5.如权利要求2所述的通信系统，其中，

所述基站仅存储其本身的告警信息。

6.如权利要求5所述的通信系统，其中，

当网络控制管理装置请求基站提供特定用户终端或者所有用户终端的告警信息时，基站通过MAC管理报文或SNMP报文请求所述的特定用户终端或者所有用户终端提供告警信息，然后将告警信息通知网络控制管理装置。

7.如权利要求1-6任一项所述的通信系统，其中，

从基站发出的告警通知包括：用户终端/基站的标识ID或OID，会话标识ID，告警类型，告警序列号，告警严重级别，告警可能的原因，告警声明，以及告警发生时间。

8.如权利要求1-6任一项所述的通信系统，其中，

从网络控制管理装置发出的告警请求包括：用户终端/基站的标识ID或OID，会话标识ID，查询的起始时间和终止时间。

9.如权利要求1所述的通信系统，其中，所述网络控制管理装置通过发送告警控制来设置用户终端/基站的告警状态，基站响应该告警控制发送控制响应给网络控制管理装置。

10.如权利要求9所述的通信系统，其中，所述告警控制和控制响应包括：用户终端/基站的标识ID或OID，会话标识ID，告警类型，告警序列号，告警严重级别，告警可能的原因，告警声明，以及告警发生时间。

11.一种通讯方法，其包括：

当基站接收到来自用户终端的告警信息，或自己产生故障，或接收到来自网络控制管理装置的告警请求时，通过告警通知将相关的告警信息从基站通知网络控制管理装置的步骤。

12.如权利要求11所述的通信方法，其中，

来自用户终端的告警信息为MAC管理告警消息或SNMP Trap消息。

13.如权利要求12所述的通信系统，其中，

当基站仅存储其本身的告警信息，且网络控制管理装置请求基站提供特定用户终端或者所有用户终端的告警信息时，进一步包括：

基站通过MAC管理报文或SNMP报文请求所述的特定用户终端或者所有用户终端提供告警信息的步骤。

14.如权利要求11-13任一项所述的通信方法，其中，

从基站发出的告警通知包括：用户终端/基站的标识ID或OID，会话标识ID，告警类型，告警序列号，告警严重级别，告警可能的原因，告警声明，以及告警发生时间。

15.如权利要求11-13任一项所述的通信方法，其中，

从网络控制管理装置发出的告警请求包括：用户终端/基站的标识ID或OID，会话表示ID，查询的起始时间和终止时间。

16.如权利要求11所述的通信方法，其进一步包括：

所述网络控制管理装置通过发送告警控制来设置用户终端/基站的告警状态的步骤，以及

基站响应该告警控制发送控制响应给网络控制管理装置的步骤。

17.如权利要求16所述的通信方法，其中，所述告警控制和控制响应包括：用户终端/基站的标识ID或OID，会话标识ID，告警类型，告警序列号，告警严重级别，告警可能的原因，告警声明，以及告警发生时间。

Images