數據管理系統及方法
2023-10-05 16:07:44
數據管理系統及方法
【專利摘要】本發明公開了一種數據管理系統及方法。其中，該系統包括：數據獲取子系統，用於獲取來自運營支撐系統（OSS）多個不同層中當前層的業務包，並將業務包發送給數據管理子系統，其中，業務包包括業務定義模型和業務邏輯；數據管理子系統，用於對業務包中的業務定義模型和業務邏輯進行數據管理。通過本發明，能夠使管理系統具有易於擴展、穩定性高，維護成本較低等效果。
【專利說明】 數據管理系統及方法
【技術領域】
[0001]本發明涉及通信領域，具體而言，涉及一種數據管理系統及方法。
【背景技術】
[0002]在電信運營商市場中，隨著用戶需求和網絡技術的不斷變化和演進，數據業務逐漸成長為主流的業務，隨之使得電信業務變得更加多樣化。同時，運營商之間的競爭也步入到一個新的時期，比拼更多的是服務質量和用戶體驗，而非傳統的網絡管理。用戶體驗管理(Customer Entertainment Management,簡稱為 CEM)、服務質量管理(Service QualityManagement,簡稱為SQM)等已納入到TMF論壇eTOM域的標準規範和流程中。運營支撐系統(Operation Support System,簡稱為0SS)的管理也逐步從網絡設備層的管理逐漸拓展到業務層、用戶層的管理。目前，OSS的管理領域涵蓋了網絡管理、服務管理和用戶層管理。因此，OSS的整體解決方案及系統的實現也逐漸成為各運營商的迫切需求。
[0003]目前，業界的解決方案通常從不同層面進行系統的開發和整合。由於跨越了多個層面，就存在如下的一些問題:
[0004]首先，整個方案涉及了大量的產品或系統，其數量眾多，接口複雜，穩定性不高。
[0005]其次，該方式耦合性高，不易於新需求的擴展。
[0006]最後，不同系統採用的架構和方式不一致，導致後期的維護成本和代價較高。
【發明內容】
[0007]本發明提供了一種數據管理系統及方法，以至少解決上述問題之一。
[0008]根據本發明的一個方面，提供了一種數據管理系統，包括:數據獲取子系統，用於獲取來自運營支撐系統(OSS)多個不同層中當前層的業務包，並將業務包發送給數據管理子系統，其中，業務包包括業務定義模型和業務邏輯；數據管理子系統，用於對業務包中的業務定義模型和業務邏輯進行數據管理。
[0009]優選地，運營支撐系統的多個不同層具有統一的數據模型，數據模型包括:業務包、數據源、資源類型、資源指標和/或元數據。
[0010]優選地，業務包包括以下組合之一:業務類型子包和業務採集子包；業務類型子包、業務採集子包和業務處理子包；業務類型子包、業務採集子包、業務處理子包和業務顯示子包。
[0011]優選地，業務類型子包包括:用於定義業務的業務定義模型；業務採集子包包括:業務在採集層的採集邏輯；業務處理子包包括:業務在處理層的處理邏輯；業務顯示子包包括:業務在顯示層的顯示邏輯；業務邏輯為以下之一:採集邏輯；採集邏輯和處理邏輯；採集邏輯、處理邏輯和顯示邏輯。
[0012]優選地，運營支撐系統(OSS)的多個不同層包括:用戶層、服務層以及網絡層。
[0013]根據本發明的另一方面，提供了一種數據管理方法，包括:獲取來自運營支撐系統
(OSS)多個不同層中當前層的業務包，其中，業務包包括業務定義模型和業務邏輯；對業務包中的業務定義模型和業務邏輯進行數據管理。
[0014]優選地，運營支撐系統的多個不同層具有統一的數據模型，數據模型包括:業務包、數據源、資源類型、資源指標和/或元數據。
[0015]優選地，業務包包括以下組合之一:業務類型子包和業務採集子包；業務類型子包、業務採集子包和業務處理子包；業務類型子包、業務採集子包、業務處理子包和業務顯示子包。
[0016]優選地，業務類型子包包括:用於定義業務的業務定義模型；業務採集子包包括:業務在採集層的採集邏輯；業務處理子包包括:業務在處理層的處理邏輯；業務顯示子包包括:業務在顯示層的顯示邏輯；業務邏輯為以下之一:採集邏輯；採集邏輯和處理邏輯；採集邏輯、處理邏輯和顯示邏輯。
[0017]優選地，運營支撐系統(OSS)的多個不同層包括:用戶層、服務層以及網絡層。
[0018]通過本發明，採用從業務層面上對運營支撐系統域中的業務數據進行建模，提出數據源、資源類型、資源指標、業務包及元數據等數據模型，將這些數據模型結合在功能層面上的數據採集子系統、數據處理子系統、數據顯示子系統以及管理控制子系統來實現對業務包的管理和控制的系統實現方式，解決了傳統技術中缺乏一種通用的電信領域運營支持系統數據管理系統或方法的問題，進而達到了易於擴展、穩定性高，維護成本較低等效果O
【專利附圖】
【附圖說明】
[0019]此處所說明的附圖用來提供對本發明的進一步理解，構成本申請的一部分，本發明的示意性實施例及其說明用於解釋本發明，並不構成對本發明的不當限定。在附圖中:
[0020]圖1是根據本發明實施例的數據管理系統的結構框圖；
[0021]圖2是根據本發明優選實施例的數據管理系統的結構示意圖；
[0022]圖3是根據本發明優選實施例的業務包的結構示意圖；
[0023]圖4是根據本發明優選實施例的數據源、源數據及業務包的映射關係圖；
[0024]圖5是根據本發明優選實施例的功能平臺的結構示意圖；
[0025]圖6是根據本發明優選實施例的系統形態的結構示意圖；
[0026]圖7是根據本發明優選實施例的CEM管理系統的結構框圖；
[0027]圖8是根據本發明優選實施例的CEM管理系統的系統形態的結構示意圖；
[0028]圖9是根據本發明優選實施例的數據管理方法的流程圖。
【具體實施方式】
[0029]下文中將參考附圖並結合實施例來詳細說明本發明。需要說明的是，在不衝突的情況下，本申請中的實施例及實施例中的特徵可以相互組合。
[0030]圖1是根據本發明實施例的數據管理系統的結構框圖，如圖1所示，該系統主要包括:數據獲取子系統10和數據管理子系統20。其中，數據獲取子系統10，用於獲取來自運營支撐系統(OSS)多個不同層中當前層的業務包，並將業務包發送給數據管理子系統，其中，業務包包括業務定義模型和業務邏輯；數據管理子系統20，用於對業務包中的業務定義模型和業務邏輯進行數據管理。[0031]在本實施例中，運營支撐系統的多個不同層具有統一的數據模型，數據模型可以包括:業務包、數據源、資源類型、資源指標和/或元數據。
[0032]在本實施例中，業務包包括以下組合之一:業務類型子包和業務採集子包；業務類型子包、業務採集子包和業務處理子包；業務類型子包、業務採集子包、業務處理子包和業務顯示子包。
[0033]在本實施例中，業務類型子包包括:用於定義業務的業務定義模型；業務採集子包包括:業務在採集層的採集邏輯；業務處理子包包括:業務在處理層的處理邏輯；業務顯示子包包括:業務在顯示層的顯示邏輯；業務邏輯為以下之一:採集邏輯；採集邏輯和處理邏輯；採集邏輯、處理邏輯和顯示邏輯。
[0034]在本實施例中，運營支撐系統(OSS)的多個不同層包括:用戶層、服務層以及網絡層。
[0035]下面結合圖2至圖6和優選實施例中的優選數據管理系統對上述實施數據管理系統進行進一步的闡述。
[0036]圖2是根據本發明優選實施例的數據管理系統的結構示意圖，如圖2所示，該優選實施例中的數據管理系統主要由四個子系統組成:數據採集子系統、數據處理子系統、數據顯示子系統以及管理控制子系統。其中，數據處理子系統、數據採集子系統以及數據顯示子系統可以採用運營支撐系統(OSS)域中的較為通用的子功能平臺，具體分工分別如下:數據採集子系統負責業務數據的採集功能域，數據處理子系統負責處理功能域，數據顯示子系統負責顯示功能域。至於管理控制子系統，其主要負責對數據模型(例如，業務包、數據源、元數據)的管理以及對三個子系統:數據採集子系統、數據處理子系統以及數據顯示子系統(在實際應用中，可以分別由功能平臺下的三個子功能平臺(其中包括一個或多個功能組件)，後續將結合圖5進行進一步的描述)的管理和控制。
[0037]下面對本發明優選實施例中的數據模型進行詳細介紹。
[0038]本發明優選實施例中的數據模型主要包括:數據源、資源類型、資源指標、業務包以及元數據。以下作分別介紹:
[0039]1、數據源
[0040]數據源是指能夠產生並對外輸出電信數據的系統或設備。在OSS的不同層次上，數據源具有不同含義:在網絡設備層中，網管系統、網元設備、探針系統、資產管理系統(Resource Management System,簡稱為RMS)等均可認為是網絡設備層的數據源；在服務層，服務管理系統、服務提供系統可認為是服務管理層的數據源；在用戶層，客服系統、客戶關係系統(Customer Relation System,簡稱為CRM)系統等可認為是用戶層的數據源。
[0041]2、資源類型
[0042]資源類型是指在OSS中能夠直接或間接作為承載電信數據的載體。資源類型可以分布在OSS的不同層次上:在網絡設備層，設備、鏈路、物理區域、邏輯區域等可認為是網絡設備層上的資源類型；在服務層次上，不同的服務類型(例如，面向用戶的服務、面向資源的服務)可認為是服務層次上的資源類型；在用戶層，個體用戶、用戶群組可認為是用戶層次上的資源類型。
[0043]3、資源指標
[0044]資源指標是對關鍵電信數據的一種提煉，其本身也屬於電信數據。資源指標作為資源的一種度量，是歸屬於某種資源類型上的，不同的資源類型具有不同的資源指標。在網絡設備層，資源指標通常定義為網絡設備的關鍵性能指示(Key Performance Indicator,簡稱為KPI);在服務層中，資源指標通常定義為服務質量的關鍵質量指示(Key QualityIndicator,簡稱為KQI);在用戶層中，資源指標通常定義為用戶感知的用戶體驗指示(Customer Entertainment Indicator,簡稱為CEI )。資源指標本質上來源於數據源，資源指標的定義將反映業務的處理邏輯。
[0045]4、業務包
[0046]業務包是對OSS的不同層次所分管的業務或數據的抽象。業務包實質上是用來定義和描述業務的，從使用者的角度看，業務包與業務包之間是沒有必然聯繫的。通常情況下，業務包由四個子包組成:業務模型子包、業務顯示子包、業務處理子包以及業務採集子包(請參照圖3，圖3是根據本發明優選實施例的業務包的結構示意圖)。
[0047]其中，業務模型子包中包括用於定義業務的業務定義模型；業務顯示子包中包括業務在顯示層的顯示邏輯；業務處理子包中包括業務在處理層的處理邏輯；業務採集子包中包括業務在採集層的採集邏輯。
[0048]5、元數據
[0049]元數據是一種描述數據的數據。在本實例中，為了完成對不同的業務和數據源的管理，系統需要具備足夠的通用性，這要求它不依賴於具體的業務和數據源，因此，需要從業務及數據源中抽象出元數據。元數據是介於數據源和業務包兩個層次中間的，元數據起著承上啟下的紐帶作用。
[0050]在實際應用中，業務包、元數據及數據之間可以存在映射關係(例如，業務包:元數據:數據源之間存在X:y:Z的比例關係，其中，X, y, Z為大於等於I的整數)，此處，請參考圖4 (圖4是根據本發明優選實施例的數據源、源數據及業務包的映射關係圖)。在本實施例中，元數據通常由資源類型、資源指標以及業務邏輯定義構成。
[0051]圖5是根據本發明優選實施例的功能平臺的結構示意圖，如圖5所示，本實施例中使用了運營支撐系統(OSS)域中的較為通用的功能平臺(系統功能的管理容器，由多個子功能平臺組成)，用來統一管理各個子功能平臺，每個子功能平臺按功能域進行劃分，功能平臺採用控制總線和數據總線的交互方式來完成對各個子功能平臺的管理和交互。其中，子功能平臺是功能組件的管理容器，每個子功能平臺包含多個功能組件，子功能平臺負責該平臺內的各個功能組件的管理，其中，功能組件提供某種具體的功能實現，同一子功能平臺內的功能組件屬於同一功能域。
[0052]圖6是根據本發明優選實施例的系統形態的結構示意圖，在圖6中，橫向模塊表示的是功能平臺，縱向模塊表示的是不同的業務包。其中，在業務包和功能組件之間具有通用接口，該接口具有較好的擴展性。通常，業務包的定義採用通用的語言以便功能組件能識另IJ，功能組件首先識別業務包中的業務定義，然後完成功能的執行。在本實施例中，系統支持對業務包進行熱部署，支持對子功能平臺及功能組件的熱插拔。
[0053]下面對本優選實施例中的數據管理系統的運行流程進行簡單的介紹:
[0054](I)系統啟動階段:該階段需要完成各個子系統的初始化，首先是管理控制子系統的初始化；其次，由該子系統中的功能管理器觸發對數據採集子系統、數據處理子系統及數據顯示子系統等子系統的初始化。[0055](2)業務包加載階段:通過業務包管理功能觸發，通過自動或手工的方式進行業務包的加載，首先完成業務包對應的元數據信息加載；其次，進行數據源管理的加載；最後，業務包加載將觸發數據採集子系統、數據處理子系統以及數據顯示等子系統的業務信息加載。
[0056](3)業務包啟動、運行階段:通過業務包管理功能啟動業務包，首先，數據採集子系統根據加載的業務包信息完成數據從數據源的採集，數據採集子系統採集的數據作為數據處理子系統的輸入；其次，數據處理子系統根據加載的業務包信息完成數據的處理，數據處理子系統的輸出作為數據顯示子系統的輸入；最後，數據顯示子系統根據加載的業務包信息完成數據的顯示操作。
[0057](4)業務包停止階段:通過業務包管理功能停止業務包，各子系統根據加載的業務包信息停止相應的採集操作、處理操作及顯示操作。
[0058]下面以典型運營支持系統(OSS)域中無線域的用戶體驗管理系統(CEM)為例，同時結合圖7和圖8，對上述優選實施例進行更加具體的說明。
[0059]圖7是根據本發明優選實施例的CEM管理系統的結構框圖，如圖7所示，該CEM系統主要包括:CEM數據採集子系統、CEM數據處理子系統以及CEM數據顯示子系統。
[0060]其中，CEM數據採集子系統用於通過加載用戶語音服務業務包中的數據採集業務子包、用戶簡訊服務業務包中的數據採集子包等業務子包，在實際應用中，完全可以通過CEM數據採集子平臺中的功能組件完成業務包中定義的採集邏輯。
[0061]CEM數據處理子系統用於通過加載用戶語音服務業務包中的數據處理業務子包、用戶簡訊服務業務包中的數據處理子包等業務子包，在實際應用中，完全可以通過CEM數據處理子平臺中的功能組件完成業務包中定義的處理邏輯。
[0062]CEM數據顯示子系統用於通過加載用戶語音服務業務包中的數據顯示業務子包、用戶簡訊服務業務包中的數據顯示子包等業務子包，在實際應用中，完全可以通過CEM數據顯示子平臺中的功能組件完成業務包中定義的顯示邏輯。
[0063]下面對無線域的CEM系統中的數據模型進行詳細介紹。
[0064]1、數據源的定義
[0065]無線域CEM系統的數據源主要由如下組成:信令數據監控系統、資源管理系統RMS、用戶管理系統CRM、綜合網管系統匪S、業務管理系統SQM、各種主動和被動的探針系統、路測數據、用戶調查問卷數據等。
[0066]2、資源類型的定義
[0067]無線域CEM系統的資源類型包括了各種用戶類型、多種服務類型、行政區域類型、邏輯區域類型、各種網絡設備類型等，具體主要包括:單用戶類型、用戶群類型；語音服務類型、簡訊服務類型、數據服務類型(包括WAP服務、HTTP服務、Streaming流服務、Video服務、麗S服務、FTP服務)；全網類型、省/市/區類型、各種邏輯區域類型；BSC類型、BTS類型、RNC類型、NodeB類型、MSC類型、HLR類型、CELL類型等。
[0068]3、資源指標的定義
[0069]對應於資源類型的定義，資源指標主要包括:VIP用戶類型CEI指標，用戶群類型CEI指標、各種區域類型對應的CEI指標、語音服務類型的KQI指標、簡訊服務類型的KQI指標、各種數據服務類型對應的KQI指標，各種區域類型對應的KQI指標、各種網絡設備類型對應的KPI指標。
[0070]4、業務包的定義
[0071]無線域CEM系統主要是對單用戶(用戶群)/區域(邏輯和物理區域)等資源類型上的服務質量進行管理，改CEM系統中的業務包主要包括:單用戶(用戶群)語音服務業務包、單用戶(用戶群)簡訊服務業務包、單用戶(用戶群)各種數據服務業務包、區域(邏輯和物理區域)語音服務業務包、區域(邏輯和物理區域)簡訊服務業務包、區域(邏輯和物理區域)各數據服務業務包。
[0072]當然，各業務包中定義了資源類型、數據源、資源指標、元數據及業務處理邏輯。以單用戶語音服務業務包為例進行說明:該業務包包含了四個子業務包:模型子包、採集子包、處理子包以及顯示子包，其中，模型子包中定義了資源類型為用戶、數據源為信令數據系統、資源指標為用戶CEI ;採集子包中描述了從信令數據系統中如何採集數據的邏輯；處理子包中描述了如何從信令數據中計算用戶CEI的處理邏輯；顯示子包中描述了用戶CEI數據的顯示邏輯(例如，進行SLA監控，CEI報表等)。
[0073]5、元數據的定義
[0074]無線域的CEM系統中的元數據包括了性能KPI指標、服務KQI指標、用戶感知CEI指標，以及定義的各種資源類型、數據源種類等。
[0075]圖8是根據本發明優選實施例的CEM管理系統的系統形態的結構示意圖，在圖8所示的系統形態結構中，CEM功能平臺包括:CEM數據顯示子平臺、CEM數據處理子平臺以及CEM數據採集子平臺。其中，CEM數據顯示子平臺由SLA監控、VIP監控、報表等功能組件組成；CEM數據處理子平臺由CEI聚合、KQI/KPI計算、數據存儲等功能組件組成；CEM數據採集子平臺由數據採集、數據解析、數據過濾等功能組件構成。
[0076]在實際應用中，CEM業務包主要包括:單用戶語音服務業務包、單用戶簡訊服務業務包等多個業務包。其中，CEM業務包可以通過.xls文件中約定好的格式進行描述，而且，各功能組件通過識別.xls文件中的定義進行處理。
[0077]下面對該CEM系統的業務處理流程進行簡單介紹。
[0078](I)CEM系統啟動階段。該階段完成各個子系統的初始化，首先是管理控制子系統各個模塊的初始化；其次，由該子系統中的CEM功能管理器觸發對CEM數據採集子系統、CEM數據處理子系統及CEM數據顯示子系統等系統的初始化。
[0079](2)業務包加載階段。通過業務包管理功能觸發，在實際應用中，可以通過自動或手工的方式進行業務包的加載，首先，完成業務包對應的元數據信息加載；其次，進行數據源管理的加載；最後，業務包加載將觸發CEM數據採集、CEM數據處理、CEM數據顯示等子系統的業務信息加載。
[0080](3)業務包啟動和運行階段。通過業務包管理功能啟動業務包，首先，CEM數據採集子系統根據加載的業務包信息完成數據從數據源的採集，CEM數據採集子系統採集的數據作為CEM數據處理子系統的輸入；其次，CEM數據處理子系統根據加載的業務包信息完成數據的處理，CEM數據處理子系統的輸出作為CEM數據顯示子系統的輸入；最後，CEM數據顯示子系統根據加載的業務包信息完成數據的顯示操作。
[0081](4)業務包停止階段。通過業務包管理功能停止業務包，在實際應用中，各子系統可以根據加載的業務包信息停止相應的採集、處理及顯示。[0082]採用上述實施例提供的數據管理系統，可以解決傳統技術中缺乏一種通用的電信領域運營支持系統數據管理系統或方法的問題，進而達到了易於擴展、穩定性高，維護成本較低等效果。
[0083]圖9是根據本發明優選實施例的數據管理方法的流程圖，如圖9所示，該方法主要包括以下步驟(步驟S902-步驟S904):
[0084]步驟S902，獲取來自運營支撐系統(OSS)多個不同層中當前層的業務包，其中，業務包包括業務定義模型和業務邏輯；
[0085]步驟S904，對業務包中的業務定義模型和業務邏輯進行數據管理。
[0086]在本實施例中，運營支撐系統的多個不同層具有統一的數據模型，數據模型可以包括:業務包、數據源、資源類型、資源指標和/或元數據。
[0087]在本實施例中，業務包可以包括以下組合之一:業務類型子包和業務採集子包；業務類型子包、業務採集子包和業務處理子包；業務類型子包、業務採集子包、業務處理子包和業務顯示子包。
[0088]在本實施例中，業務類型子包可以包括:用於定義業務的業務定義模型；業務採集子包可以包括:業務在採集層的採集邏輯；業務處理子包可以包括:業務在處理層的處理邏輯；業務顯示子包可以包括:業務在顯示層的顯示邏輯；業務邏輯可以為以下之一:採集邏輯；採集邏輯和處理邏輯；採集邏輯、處理邏輯和顯示邏輯。
[0089]在本實施例中，運營支撐系統(OSS)的多個不同層可以包括:用戶層、服務層以及網絡層。
[0090]採用上述實施例提供的數據管理方法，可以解決傳統技術中缺乏一種通用的電信領域運營支持系統數據管理系統或方法的問題，進而達到了易於擴展、穩定性高，維護成本較低等效果。
[0091]從以上的描述中，可以看出，本發明實現了如下技術效果:採用從業務層面上對運營支撐系統域中的業務數據進行建模，提出數據源、資源類型、資源指標、業務包及元數據等數據模型，將這些數據模型結合在功能層面上的數據採集子系統、數據處理子系統、數據顯示子系統以及管理控制子系統來實現對業務包的管理和控制的系統實現方式，解決了傳統技術中缺乏一種通用的電信領域運營支持系統數據管理系統或方法的問題，進而達到了易於擴展、穩定性高，維護成本較低等效果。
[0092]顯然，本領域的技術人員應該明白，上述的本發明的各模塊或各步驟可以用通用的計算裝置來實現，它們可以集中在單個的計算裝置上，或者分布在多個計算裝置所組成的網絡上，可選地，它們可以用計算裝置可執行的程序代碼來實現，從而，可以將它們存儲在存儲裝置中由計算裝置來執行，並且在某些情況下，可以以不同於此處的順序執行所示出或描述的步驟，或者將它們分別製作成各個集成電路模塊，或者將它們中的多個模塊或步驟製作成單個集成電路模塊來實現。這樣，本發明不限制於任何特定的硬體和軟體結合。
[0093]以上所述僅為本發明的優選實施例而已，並不用於限制本發明，對於本領域的技術人員來說，本發明可以有各種更改和變化。凡在本發明的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本發明的保護範圍之內。
【權利要求】
1.一種數據管理系統，其特徵在於，包括: 數據獲取子系統，用於獲取來自運營支撐系統多個不同層中當前層的業務包，並將所述業務包發送給數據管理子系統，其中，所述業務包包括業務定義模型和業務邏輯； 所述數據管理子系統，用於對所述業務包中的所述業務定義模型和所述業務邏輯進行數據管理。
2.根據權利要求1所述的系統，其特徵在於，所述運營支撐系統的多個不同層具有統一的數據模型，所述數據模型包括:所述業務包、數據源、資源類型、資源指標和/或元數據。
3.根據權利要求2所述的系統，其特徵在於，所述業務包包括以下組合之一: 業務類型子包和業務採集子包； 所述業務類型子包、所述業務採集子包和業務處理子包； 所述業務類型子包、所述業務採集子包、所述業務處理子包和業務顯示子包。
4.根據權利要求3所述的系統，其特徵在於， 所述業務類型子包包括:用於定義業務的所述業務定義模型； 所述業務採集子包包括:業務在採集層的採集邏輯； 所述業務處理子包包括:業務在處理層的處理邏輯； 所述業務顯示子包包括: 業務在顯示層的顯示邏輯； 所述業務邏輯為以下之一: 所述採集邏輯； 所述採集邏輯和所述處理邏輯； 所述採集邏輯、所述處理邏輯和所述顯示邏輯。
5.根據權利要求1至4中任一項所述的系統，其特徵在於，所述運營支撐系統的所述多個不同層包括:用戶層、服務層以及網絡層。
6.一種數據管理方法，其特徵在於，包括: 獲取來自運營支撐系統多個不同層中當前層的業務包，其中，所述業務包包括業務定義模型和業務邏輯； 對所述業務包中的所述業務定義模型和所述業務邏輯進行數據管理。
7.根據權利要求6所述的方法，其特徵在於，所述運營支撐系統的多個不同層具有統一的數據模型，所述數據模型包括:所述業務包、數據源、資源類型、資源指標和/或元數據。
8.根據權利要求7所述的方法，其特徵在於，所述業務包包括以下組合之一: 業務類型子包和業務採集子包； 所述業務類型子包、所述業務採集子包和業務處理子包； 所述業務類型子包、所述業務採集子包、所述業務處理子包和業務顯示子包。
9.根據權利要求8所述的方法，其特徵在於， 所述業務類型子包包括:用於定義業務的所述業務定義模型； 所述業務採集子包包括:業務在採集層的採集邏輯； 所述業務採集子包包括:業務在處理層的處理邏輯； 所述業務顯示子包包括:業務在顯示層的顯示邏輯；所述業務邏輯為以下之一: 所述採集邏輯； 所述採集邏輯和所述處理邏輯； 所述採集邏輯、所述處理邏輯和所述顯示邏輯。
10.根據權利要求6 至9中任一項所述的方法，其特徵在於，所述運營支撐系統的所述多個不同層包括:用戶層、服務層以及網絡層。
【文檔編號】H04L12/24GK103457754SQ201210181262
【公開日】2013年12月18日 申請日期:2012年6月4日 優先權日:2012年6月4日
【發明者】杜賢俊 申請人:中興通訊股份有限公司