CN103457754B - 数据管理系统及方法 - Google Patents

Abstract

本发明公开了一种数据管理系统及方法。其中，该系统包括：数据获取子系统，用于获取来自运营支撑系统（OSS）多个不同层中当前层的业务包，并将业务包发送给数据管理子系统，其中，业务包包括业务定义模型和业务逻辑；数据管理子系统，用于对业务包中的业务定义模型和业务逻辑进行数据管理。通过本发明，能够使管理系统具有易于扩展、稳定性高，维护成本较低等效果。

Description

数据管理系统及方法

技术领域

本发明涉及通信领域，具体而言，涉及一种数据管理系统及方法。

背景技术

在电信运营商市场中，随着用户需求和网络技术的不断变化和演进，数据业务逐渐成长为主流的业务，随之使得电信业务变得更加多样化。同时，运营商之间的竞争也步入到一个新的时期，比拼更多的是服务质量和用户体验，而非传统的网络管理。用户体验管理（Customer Entertainment Management，简称为CEM）、服务质量管理（Service QualityManagement，简称为SQM）等已纳入到TMF论坛eTOM域的标准规范和流程中。运营支撑系统（Operation Support System，简称为OSS）的管理也逐步从网络设备层的管理逐渐拓展到业务层、用户层的管理。目前，OSS的管理领域涵盖了网络管理、服务管理和用户层管理。因此，OSS的整体解决方案及系统的实现也逐渐成为各运营商的迫切需求。

目前，业界的解决方案通常从不同层面进行系统的开发和整合。由于跨越了多个层面，就存在如下的一些问题：

首先，整个方案涉及了大量的产品或系统，其数量众多，接口复杂，稳定性不高。

其次，该方式耦合性高，不易于新需求的扩展。

最后，不同系统采用的架构和方式不一致，导致后期的维护成本和代价较高。

发明内容

本发明提供了一种数据管理系统及方法，以至少解决上述问题之一。

根据本发明的一个方面，提供了一种数据管理系统，包括：数据获取子系统，用于获取来自运营支撑系统（OSS）多个不同层中当前层的业务包，并将业务包发送给数据管理子系统，其中，业务包包括业务定义模型和业务逻辑；数据管理子系统，用于对业务包中的业务定义模型和业务逻辑进行数据管理。

优选地，运营支撑系统的多个不同层具有统一的数据模型，数据模型包括：业务包、数据源、资源类型、资源指标和/或元数据。

优选地，业务包包括以下组合之一：业务类型子包和业务采集子包；业务类型子包、业务采集子包和业务处理子包；业务类型子包、业务采集子包、业务处理子包和业务显示子包。

优选地，业务类型子包包括：用于定义业务的业务定义模型；业务采集子包包括：业务在采集层的采集逻辑；业务处理子包包括：业务在处理层的处理逻辑；业务显示子包包括：业务在显示层的显示逻辑；业务逻辑为以下之一：采集逻辑；采集逻辑和处理逻辑；采集逻辑、处理逻辑和显示逻辑。

优选地，运营支撑系统（OSS）的多个不同层包括：用户层、服务层以及网络层。

根据本发明的另一方面，提供了一种数据管理方法，包括：获取来自运营支撑系统（OSS）多个不同层中当前层的业务包，其中，业务包包括业务定义模型和业务逻辑；对业务包中的业务定义模型和业务逻辑进行数据管理。

优选地，运营支撑系统的多个不同层具有统一的数据模型，数据模型包括：业务包、数据源、资源类型、资源指标和/或元数据。

优选地，业务包包括以下组合之一：业务类型子包和业务采集子包；业务类型子包、业务采集子包和业务处理子包；业务类型子包、业务采集子包、业务处理子包和业务显示子包。

优选地，业务类型子包包括：用于定义业务的业务定义模型；业务采集子包包括：业务在采集层的采集逻辑；业务处理子包包括：业务在处理层的处理逻辑；业务显示子包包括：业务在显示层的显示逻辑；业务逻辑为以下之一：采集逻辑；采集逻辑和处理逻辑；采集逻辑、处理逻辑和显示逻辑。

优选地，运营支撑系统（OSS）的多个不同层包括：用户层、服务层以及网络层。

通过本发明，采用从业务层面上对运营支撑系统域中的业务数据进行建模，提出数据源、资源类型、资源指标、业务包及元数据等数据模型，将这些数据模型结合在功能层面上的数据采集子系统、数据处理子系统、数据显示子系统以及管理控制子系统来实现对业务包的管理和控制的系统实现方式，解决了传统技术中缺乏一种通用的电信领域运营支持系统数据管理系统或方法的问题，进而达到了易于扩展、稳定性高，维护成本较低等效果。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的数据管理系统的结构框图；

图2是根据本发明优选实施例的数据管理系统的结构示意图；

图3是根据本发明优选实施例的业务包的结构示意图；

图4是根据本发明优选实施例的数据源、源数据及业务包的映射关系图；

图5是根据本发明优选实施例的功能平台的结构示意图；

图6是根据本发明优选实施例的系统形态的结构示意图；

图7是根据本发明优选实施例的CEM管理系统的结构框图；

图8是根据本发明优选实施例的CEM管理系统的系统形态的结构示意图；

图9是根据本发明优选实施例的数据管理方法的流程图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

图1是根据本发明实施例的数据管理系统的结构框图，如图1所示，该系统主要包括：数据获取子系统10和数据管理子系统20。其中，数据获取子系统10，用于获取来自运营支撑系统（OSS）多个不同层中当前层的业务包，并将业务包发送给数据管理子系统，其中，业务包包括业务定义模型和业务逻辑；数据管理子系统20，用于对业务包中的业务定义模型和业务逻辑进行数据管理。

在本实施例中，运营支撑系统的多个不同层具有统一的数据模型，数据模型可以包括：业务包、数据源、资源类型、资源指标和/或元数据。

在本实施例中，业务包包括以下组合之一：业务类型子包和业务采集子包；业务类型子包、业务采集子包和业务处理子包；业务类型子包、业务采集子包、业务处理子包和业务显示子包。

在本实施例中，业务类型子包包括：用于定义业务的业务定义模型；业务采集子包包括：业务在采集层的采集逻辑；业务处理子包包括：业务在处理层的处理逻辑；业务显示子包包括：业务在显示层的显示逻辑；业务逻辑为以下之一：采集逻辑；采集逻辑和处理逻辑；采集逻辑、处理逻辑和显示逻辑。

在本实施例中，运营支撑系统（OSS）的多个不同层包括：用户层、服务层以及网络层。

下面结合图2至图6和优选实施例中的优选数据管理系统对上述实施数据管理系统进行进一步的阐述。

图2是根据本发明优选实施例的数据管理系统的结构示意图，如图2所示，该优选实施例中的数据管理系统主要由四个子系统组成：数据采集子系统、数据处理子系统、数据显示子系统以及管理控制子系统。其中，数据处理子系统、数据采集子系统以及数据显示子系统可以采用运营支撑系统（OSS）域中的较为通用的子功能平台，具体分工分别如下：数据采集子系统负责业务数据的采集功能域，数据处理子系统负责处理功能域，数据显示子系统负责显示功能域。至于管理控制子系统，其主要负责对数据模型（例如，业务包、数据源、元数据）的管理以及对三个子系统：数据采集子系统、数据处理子系统以及数据显示子系统（在实际应用中，可以分别由功能平台下的三个子功能平台（其中包括一个或多个功能组件），后续将结合图5进行进一步的描述）的管理和控制。

下面对本发明优选实施例中的数据模型进行详细介绍。

本发明优选实施例中的数据模型主要包括：数据源、资源类型、资源指标、业务包以及元数据。以下作分别介绍：

1、数据源

数据源是指能够产生并对外输出电信数据的系统或设备。在OSS的不同层次上，数据源具有不同含义：在网络设备层中，网管系统、网元设备、探针系统、资产管理系统（Resource Management System，简称为RMS）等均可认为是网络设备层的数据源；在服务层，服务管理系统、服务提供系统可认为是服务管理层的数据源；在用户层，客服系统、客户关系系统（Customer Relation System，简称为CRM）系统等可认为是用户层的数据源。

2、资源类型

资源类型是指在OSS中能够直接或间接作为承载电信数据的载体。资源类型可以分布在OSS的不同层次上：在网络设备层，设备、链路、物理区域、逻辑区域等可认为是网络设备层上的资源类型；在服务层次上，不同的服务类型（例如，面向用户的服务、面向资源的服务）可认为是服务层次上的资源类型；在用户层，个体用户、用户群组可认为是用户层次上的资源类型。

3、资源指标

资源指标是对关键电信数据的一种提炼，其本身也属于电信数据。资源指标作为资源的一种度量，是归属于某种资源类型上的，不同的资源类型具有不同的资源指标。在网络设备层，资源指标通常定义为网络设备的关键性能指示（Key Performance Indicator，简称为KPI）；在服务层中，资源指标通常定义为服务质量的关键质量指示（Key QualityIndicator，简称为KQI）；在用户层中，资源指标通常定义为用户感知的用户体验指示（Customer Entertainment Indicator，简称为CEI）。资源指标本质上来源于数据源，资源指标的定义将反映业务的处理逻辑。

4、业务包

业务包是对OSS的不同层次所分管的业务或数据的抽象。业务包实质上是用来定义和描述业务的，从使用者的角度看，业务包与业务包之间是没有必然联系的。通常情况下，业务包由四个子包组成：业务模型子包、业务显示子包、业务处理子包以及业务采集子包（请参照图3，图3是根据本发明优选实施例的业务包的结构示意图）。

其中，业务模型子包中包括用于定义业务的业务定义模型；业务显示子包中包括业务在显示层的显示逻辑；业务处理子包中包括业务在处理层的处理逻辑；业务采集子包中包括业务在采集层的采集逻辑。

5、元数据

元数据是一种描述数据的数据。在本实例中，为了完成对不同的业务和数据源的管理，系统需要具备足够的通用性，这要求它不依赖于具体的业务和数据源，因此，需要从业务及数据源中抽象出元数据。元数据是介于数据源和业务包两个层次中间的，元数据起着承上启下的纽带作用。

在实际应用中，业务包、元数据及数据之间可以存在映射关系（例如，业务包：元数据：数据源之间存在x：y：z的比例关系，其中，x，y，z为大于等于1的整数），此处，请参考图4（图4是根据本发明优选实施例的数据源、源数据及业务包的映射关系图）。在本实施例中，元数据通常由资源类型、资源指标以及业务逻辑定义构成。

图5是根据本发明优选实施例的功能平台的结构示意图，如图5所示，本实施例中使用了运营支撑系统（OSS）域中的较为通用的功能平台（系统功能的管理容器，由多个子功能平台组成），用来统一管理各个子功能平台，每个子功能平台按功能域进行划分，功能平台采用控制总线和数据总线的交互方式来完成对各个子功能平台的管理和交互。其中，子功能平台是功能组件的管理容器，每个子功能平台包含多个功能组件，子功能平台负责该平台内的各个功能组件的管理，其中，功能组件提供某种具体的功能实现，同一子功能平台内的功能组件属于同一功能域。

图6是根据本发明优选实施例的系统形态的结构示意图，在图6中，横向模块表示的是功能平台，纵向模块表示的是不同的业务包。其中，在业务包和功能组件之间具有通用接口，该接口具有较好的扩展性。通常，业务包的定义采用通用的语言以便功能组件能识别，功能组件首先识别业务包中的业务定义，然后完成功能的执行。在本实施例中，系统支持对业务包进行热部署，支持对子功能平台及功能组件的热插拔。

下面对本优选实施例中的数据管理系统的运行流程进行简单的介绍：

（1）系统启动阶段：该阶段需要完成各个子系统的初始化，首先是管理控制子系统的初始化；其次，由该子系统中的功能管理器触发对数据采集子系统、数据处理子系统及数据显示子系统等子系统的初始化。

（2）业务包加载阶段：通过业务包管理功能触发，通过自动或手工的方式进行业务包的加载，首先完成业务包对应的元数据信息加载；其次，进行数据源管理的加载；最后，业务包加载将触发数据采集子系统、数据处理子系统以及数据显示等子系统的业务信息加载。

（3）业务包启动、运行阶段：通过业务包管理功能启动业务包，首先，数据采集子系统根据加载的业务包信息完成数据从数据源的采集，数据采集子系统采集的数据作为数据处理子系统的输入；其次，数据处理子系统根据加载的业务包信息完成数据的处理，数据处理子系统的输出作为数据显示子系统的输入；最后，数据显示子系统根据加载的业务包信息完成数据的显示操作。

（4）业务包停止阶段：通过业务包管理功能停止业务包，各子系统根据加载的业务包信息停止相应的采集操作、处理操作及显示操作。

下面以典型运营支持系统（OSS）域中无线域的用户体验管理系统（CEM）为例，同时结合图7和图8，对上述优选实施例进行更加具体的说明。

图7是根据本发明优选实施例的CEM管理系统的结构框图，如图7所示，该CEM系统主要包括：CEM数据采集子系统、CEM数据处理子系统以及CEM数据显示子系统。

其中，CEM数据采集子系统用于通过加载用户语音服务业务包中的数据采集业务子包、用户短信服务业务包中的数据采集子包等业务子包，在实际应用中，完全可以通过CEM数据采集子平台中的功能组件完成业务包中定义的采集逻辑。

CEM数据处理子系统用于通过加载用户语音服务业务包中的数据处理业务子包、用户短信服务业务包中的数据处理子包等业务子包，在实际应用中，完全可以通过CEM数据处理子平台中的功能组件完成业务包中定义的处理逻辑。

CEM数据显示子系统用于通过加载用户语音服务业务包中的数据显示业务子包、用户短信服务业务包中的数据显示子包等业务子包，在实际应用中，完全可以通过CEM数据显示子平台中的功能组件完成业务包中定义的显示逻辑。

下面对无线域的CEM系统中的数据模型进行详细介绍。

1、数据源的定义

无线域CEM系统的数据源主要由如下组成：信令数据监控系统、资源管理系统RMS、用户管理系统CRM、综合网管系统NMS、业务管理系统SQM、各种主动和被动的探针系统、路测数据、用户调查问卷数据等。

2、资源类型的定义

无线域CEM系统的资源类型包括了各种用户类型、多种服务类型、行政区域类型、逻辑区域类型、各种网络设备类型等，具体主要包括：单用户类型、用户群类型；语音服务类型、短信服务类型、数据服务类型（包括WAP服务、HTTP服务、Streaming流服务、Video服务、MMS服务、FTP服务）；全网类型、省/市/区类型、各种逻辑区域类型；BSC类型、BTS类型、RNC类型、NodeB类型、MSC类型、HLR类型、CELL类型等。

3、资源指标的定义

对应于资源类型的定义，资源指标主要包括：VIP用户类型CEI指标，用户群类型CEI指标、各种区域类型对应的CEI指标、语音服务类型的KQI指标、短信服务类型的KQI指标、各种数据服务类型对应的KQI指标，各种区域类型对应的KQI指标、各种网络设备类型对应的KPI指标。

4、业务包的定义

无线域CEM系统主要是对单用户（用户群）/区域（逻辑和物理区域）等资源类型上的服务质量进行管理，改CEM系统中的业务包主要包括：单用户（用户群）语音服务业务包、单用户（用户群）短信服务业务包、单用户（用户群）各种数据服务业务包、区域（逻辑和物理区域）语音服务业务包、区域（逻辑和物理区域）短信服务业务包、区域（逻辑和物理区域）各数据服务业务包。

当然，各业务包中定义了资源类型、数据源、资源指标、元数据及业务处理逻辑。以单用户语音服务业务包为例进行说明：该业务包包含了四个子业务包：模型子包、采集子包、处理子包以及显示子包，其中，模型子包中定义了资源类型为用户、数据源为信令数据系统、资源指标为用户CEI；采集子包中描述了从信令数据系统中如何采集数据的逻辑；处理子包中描述了如何从信令数据中计算用户CEI的处理逻辑；显示子包中描述了用户CEI数据的显示逻辑（例如，进行SLA监控，CEI报表等）。

5、元数据的定义

无线域的CEM系统中的元数据包括了性能KPI指标、服务KQI指标、用户感知CEI指标，以及定义的各种资源类型、数据源种类等。

图8是根据本发明优选实施例的CEM管理系统的系统形态的结构示意图，在图8所示的系统形态结构中，CEM功能平台包括：CEM数据显示子平台、CEM数据处理子平台以及CEM数据采集子平台。其中，CEM数据显示子平台由SLA监控、VIP监控、报表等功能组件组成；CEM数据处理子平台由CEI聚合、KQI/KPI计算、数据存储等功能组件组成；CEM数据采集子平台由数据采集、数据解析、数据过滤等功能组件构成。

在实际应用中，CEM业务包主要包括：单用户语音服务业务包、单用户短信服务业务包等多个业务包。其中，CEM业务包可以通过.xls文件中约定好的格式进行描述，而且，各功能组件通过识别.xls文件中的定义进行处理。

下面对该CEM系统的业务处理流程进行简单介绍。

（1）CEM系统启动阶段。该阶段完成各个子系统的初始化，首先是管理控制子系统各个模块的初始化；其次，由该子系统中的CEM功能管理器触发对CEM数据采集子系统、CEM数据处理子系统及CEM数据显示子系统等系统的初始化。

（2）业务包加载阶段。通过业务包管理功能触发，在实际应用中，可以通过自动或手工的方式进行业务包的加载，首先，完成业务包对应的元数据信息加载；其次，进行数据源管理的加载；最后，业务包加载将触发CEM数据采集、CEM数据处理、CEM数据显示等子系统的业务信息加载。

（3）业务包启动和运行阶段。通过业务包管理功能启动业务包，首先，CEM数据采集子系统根据加载的业务包信息完成数据从数据源的采集，CEM数据采集子系统采集的数据作为CEM数据处理子系统的输入；其次，CEM数据处理子系统根据加载的业务包信息完成数据的处理，CEM数据处理子系统的输出作为CEM数据显示子系统的输入；最后，CEM数据显示子系统根据加载的业务包信息完成数据的显示操作。

（4）业务包停止阶段。通过业务包管理功能停止业务包，在实际应用中，各子系统可以根据加载的业务包信息停止相应的采集、处理及显示。

采用上述实施例提供的数据管理系统，可以解决传统技术中缺乏一种通用的电信领域运营支持系统数据管理系统或方法的问题，进而达到了易于扩展、稳定性高，维护成本较低等效果。

图9是根据本发明优选实施例的数据管理方法的流程图，如图9所示，该方法主要包括以下步骤（步骤S902-步骤S904）：

步骤S902，获取来自运营支撑系统（OSS）多个不同层中当前层的业务包，其中，业务包包括业务定义模型和业务逻辑；

步骤S904，对业务包中的业务定义模型和业务逻辑进行数据管理。

在本实施例中，运营支撑系统的多个不同层具有统一的数据模型，数据模型可以包括：业务包、数据源、资源类型、资源指标和/或元数据。

在本实施例中，业务包可以包括以下组合之一：业务类型子包和业务采集子包；业务类型子包、业务采集子包和业务处理子包；业务类型子包、业务采集子包、业务处理子包和业务显示子包。

在本实施例中，业务类型子包可以包括：用于定义业务的业务定义模型；业务采集子包可以包括：业务在采集层的采集逻辑；业务处理子包可以包括：业务在处理层的处理逻辑；业务显示子包可以包括：业务在显示层的显示逻辑；业务逻辑可以为以下之一：采集逻辑；采集逻辑和处理逻辑；采集逻辑、处理逻辑和显示逻辑。

在本实施例中，运营支撑系统（OSS）的多个不同层可以包括：用户层、服务层以及网络层。

采用上述实施例提供的数据管理方法，可以解决传统技术中缺乏一种通用的电信领域运营支持系统数据管理系统或方法的问题，进而达到了易于扩展、稳定性高，维护成本较低等效果。

从以上的描述中，可以看出，本发明实现了如下技术效果：采用从业务层面上对运营支撑系统域中的业务数据进行建模，提出数据源、资源类型、资源指标、业务包及元数据等数据模型，将这些数据模型结合在功能层面上的数据采集子系统、数据处理子系统、数据显示子系统以及管理控制子系统来实现对业务包的管理和控制的系统实现方式，解决了传统技术中缺乏一种通用的电信领域运营支持系统数据管理系统或方法的问题，进而达到了易于扩展、稳定性高，维护成本较低等效果。

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

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种数据管理系统，其特征在于，包括：

数据获取子系统，用于获取来自运营支撑系统多个不同层中当前层的业务包，并将所述业务包发送给数据管理子系统，其中，所述业务包包括业务定义模型和业务逻辑；

所述数据管理子系统，用于对所述业务包中的所述业务定义模型和所述业务逻辑进行数据管理；

其中，所述运营支撑系统的多个不同层具有统一的数据模型，所述数据模型包括：所述业务包、数据源、资源类型、资源指标和/或元数据。

2.根据权利要求1所述的系统，其特征在于，所述业务包包括以下组合之一：

业务类型子包和业务采集子包；

所述业务类型子包、所述业务采集子包和业务处理子包；

所述业务类型子包、所述业务采集子包、所述业务处理子包和业务显示子包。

3.根据权利要求2所述的系统，其特征在于，

所述业务类型子包包括：用于定义业务的所述业务定义模型；

所述业务采集子包包括：业务在采集层的采集逻辑；

所述业务处理子包包括：业务在处理层的处理逻辑；

所述业务显示子包包括：业务在显示层的显示逻辑；

所述业务逻辑为以下之一：

所述采集逻辑；

所述采集逻辑和所述处理逻辑；

所述采集逻辑、所述处理逻辑和所述显示逻辑。

4.根据权利要求1至3中任一项所述的系统，其特征在于，所述运营支撑系统的所述多个不同层包括：用户层、服务层以及网络层。

5.一种数据管理方法，其特征在于，包括：

获取来自运营支撑系统多个不同层中当前层的业务包，其中，所述业务包包括业务定义模型和业务逻辑；

对所述业务包中的所述业务定义模型和所述业务逻辑进行数据管理；

其中，所述运营支撑系统的多个不同层具有统一的数据模型，所述数据模型包括：所述业务包、数据源、资源类型、资源指标和/或元数据。

6.根据权利要求5所述的方法，其特征在于，所述业务包包括以下组合之一：

业务类型子包和业务采集子包；

所述业务类型子包、所述业务采集子包和业务处理子包；

所述业务类型子包、所述业务采集子包、所述业务处理子包和业务显示子包。

7.根据权利要求6所述的方法，其特征在于，

所述业务类型子包包括：用于定义业务的所述业务定义模型；

所述业务采集子包包括：业务在采集层的采集逻辑；

所述业务采集子包包括：业务在处理层的处理逻辑；

所述业务显示子包包括：业务在显示层的显示逻辑；

所述业务逻辑为以下之一：

所述采集逻辑；

所述采集逻辑和所述处理逻辑；

所述采集逻辑、所述处理逻辑和所述显示逻辑。

8.根据权利要求5至7中任一项所述的方法，其特征在于，所述运营支撑系统的所述多个不同层包括：用户层、服务层以及网络层。