ETSI GR ENI 031 V4.1.1 (2024-05)

Experiential Networked Intelligence (ENI); Construction and application of fault maintenance network knowledge graphs

DGR/ENI-0031v411_Net-know-grap

General Information

• Status: Not Published
• Technical Committee: ENI - Experiential Networked Intelligence
• Current Stage: 12 - Completion
• Due Date: 17-May-2024
• Completion Date: 17-May-2024

Standards Content (Sample)

GROUP REPORT
Experiential Networked Intelligence (ENI);
Construction and application of
fault maintenance network knowledge graphs
Disclaimer
The present document has been produced and approved by the Experiential Networked Intelligence (ENI) ETSI Industry
Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GR ENI 031 V4.1.1 (2024-05)

Reference
DGR/ENI-0031v411_Net-know-grap
Keywords
access, algorithm, wireless ad-hoc network
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
https://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2024.
All rights reserved.
ETSI
3 ETSI GR ENI 031 V4.1.1 (2024-05)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 8
4 Introduction . 8
4.1 Background of network fault management knowledge graph construction . 8
4.2 Values of network fault maintenance knowledge graph . 9
5 Construction of wireless network fault maintenance knowledge graphs . 9
5.1 Framework of network fault maintenance knowledge graph construction process . 9
5.2 Data acquisition and processing for knowledge graph . 12
5.2.1 Content and format of data collection . 12
5.2.2 Data normalization . 12
5.3 Ontology design . 13
5.3.1 Diagram of ontology . 13
5.3.2 Definition of types and attributes of wireless fault maintenance knowledge entities . 14
5.3.3 Definition of relationship of wireless fault maintenance knowledge entities . 17
5.4 Knowledge Graph Quality Evaluation Methods. 17
6 Application of wireless network fault maintenance knowledge graph . 18
6.1 Knowledge reasoning . 18
6.1.1 Motivation. 18
6.1.2 Functional Requirements . 18
6.1.3 Interface requirements . 19
6.2 Knowledge storage and query . 19
6.2.1 Motivation. 19
6.2.2 Functional Requirements . 19
6.2.3 Interface requirements . 20
7 Use Cases . 21
7.1 Cases of knowledge graph construction . 21
7.1.1 Use Case #1-1: Knowledge graph of wireless network quality fault handling . 21
7.1.1.1 Overview . 21
7.1.1.2 Data Acquisition and processing . 21
7.1.1.3 Ontology/schema design . 22
7.1.1.4 Knowledge Extraction and knowledge fusion . 23
7.1.1.5 Knowledge graph quality evaluation . 23
7.2 Cases of knowledge graph application . 24
7.2.1 Use Case #2-1: Fault tracing in Wireless Network . 24
7.2.1.1 Overview . 24
7.2.1.2 Motivation . 24
7.2.1.3 Actors and roles . 24
7.2.1.4 Operational flow of actions . 24
7.2.1.5 Post-conditions . 25
7.2.2 Use Case #3-1: Intelligent Management of Home LAN . 25
7.2.2.1 Overview . 25
7.2.2.2 Motivation . 25
7.2.2.3 Actors and roles . 25
ETSI
4 ETSI GR ENI 031 V4.1.1 (2024-05)
7.2.2.4 Initial context condition . 25
7.2.2.5 Operational flow of actions . 26
7.2.2.6 Post-conditions . 26
8 Research on cross network fields fault maintenance knowledge graphs construction methods (e.g.
access networks) . 27
9 Conclusions . 27
Annex A: Change history . 29
History . 30

ETSI
5 ETSI GR ENI 031 V4.1.1 (2024-05)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) Experiential Networked
Intelligence (ENI).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
6 ETSI GR ENI 031 V4.1.1 (2024-05)
1 Scope
The purpose of the present document is to describe use cases and a construction method of knowledge graphs that are
used for fault maintenance. The present document focus on the following topics:
• defines the data requirements;
• defines a schema design;
• describes the knowledge application interface for fault maintenance knowledge graphs.
In addition to the main target related to the construction of fault maintenance network knowledge graphs, obtaining
computer-readable and writable network fault maintenance domain knowledge and enabling learning and reasoning of
relevant algorithm models of fault self-repair are also envisaged.
The present document will encompass research and investigation activities that will address wireless networks at the
first stage. Subsequent efforts possibly will extend the work into access networks.
NOTE: The general solutions for knowledge graph and knowledge management are out of the scope of the
present document.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long-term validity.
The following referenced documents are not necessary for the application of the present document, but they assist the
user with regard to a particular subject area.
[i.1] ETSI GR ENI 004 (V3.1.1): "Experiential Networked Intelligence (ENI); Terminology".
[i.2] ETSI GS ENI 005 (V3.1.1): "Experiential Networked Intelligence (ENI); System Architecture".
[i.3] ETSI GR ENI 010 (V1.1.1): "Experiential Networked Intelligence (ENI); Evaluation of categories
for AI application to Networks".
[i.4] TM Forum IG1218: "Autonomous Networks Business Requirements and Architecture".
[i.5] "Autonomous Systems - An Architectural Characterization, Joseph Sifakis", Verimag Laboratory,
2019.
[i.6] ETSI GS ENI 019 (V3.1.1): "Experiential Networked Intelligence (ENI); Representing, Inferring,
and Proving Knowledge in ENI".
ETSI
7 ETSI GR ENI 031 V4.1.1 (2024-05)
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GR ENI 004 [i.1] , ETSI GS ENI 005 [i.2], ETSI
GR ENI 010 [i.3] and the following apply:
co-reference resolution: task of finding all expressions in a text that refer to the same real-world entity
data cleansing: process of detecting and correcting (or removing) incomplete, incorrect, inaccurate, or corrupt data
from being further processed
entity disambiguation: process of finding references in a dataset that refer to the same entity
extraction: activity of transforming valuable information into structured data from input data of different sources
and structures:
• attribute extraction: extract detailed features describing entities/relationships/events from input data
• entity extraction: identify named entities from input data
• knowledge extraction: extracting entities, relationships, and new knowledge from patterns or inference from data
extract various semantic associations between different entities from input data
• relationship extraction:
knowledge discovery: finding new knowledge from existing knowledge
knowledge entity: concept of reflecting specific things in the knowledge graph
knowledge fusion: process of combining knowledge from multiple sources to create a more comprehensive and
accurate representation of the system
knowledge graph: structured representation of knowledge that uses a graph data structure and formal logic to represent
entities and their relationships
knowledge integration: combining knowledge from different sources in a way that preserves the semantics of the
knowledge
knowledge reasoning: process of using knowledge to draw new conclusions:
• graph-based knowledge reasoning: embed high-dimensional knowledge graphs into low latitude continuous
vector spaces
NOTE: They represent entities and relationships as numerical vectors for computation, and combine other
algorithms to achieve reasoning, including methods such as distributed feature representation, Graph
Neural Network (GNN) algorithms.
• rule-based knowledge reasoning: mining and reasoning by defining or learning rules that exist in knowledge,
including methods such as predicate logic reasoning, ontology reasoning, and random reasoning
ontology alignment: finding mappings between overlapping concepts in two or more ontologies to align them
3.2 Symbols
Void.
ETSI
8 ETSI GR ENI 031 V4.1.1 (2024-05)
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GR ENI 004 [i.1], ETSI GS ENI 005 [i.2]
and the following apply:
KaaS Knowledge as a Service
KGC Knowledge Graph Completion
KGQA Knowledge Graph Question Answering
LAN Local Area Network
MMKG Multi-Modal Knowledge Graph
MR Measurement Report
NFV Network Function Virtualisation
R&D Research and Development
RCA Root Cause Analysis
RDF Resource Description Framework
SDN Software Defined Networking
SQL Structured Query Language
WQMKG Wireless Quality Maintenance Knowledge Graph
4 Introduction
4.1 Background of network fault management knowledge graph
construction
The telecommunications industry has been exploring digitization, automation and intelligence, from focusing on
customer service and business layer in the early stage of transformation, gradually extending to the internal
management and operation layer, and then to the network layer. Initially, the telecommunications industry looked to
reduce cost and complexity while increasing business and network agility by using SDN, NFV and cloud technologies.
However, network automation based on SDN/NFV technology still cannot completely solve the problems caused by the
large-scale deployment of various applications, such as the introduction and expansion of new network technologies in
the future. A common problem faced by the industry is how to improve efficiency and throughput in a large-scale for
the entire process, and how to continuously, rapidly and iteratively introduce new technologies.
Autonomous Networks (refer to GR ENI 010 [i.3]) was born in this context. By applying a variety of intelligent
technologies and giving full play to the integration advantages, it will drive the telecommunications industry to an era
where intelligence is embedded in the network. In order to achieve the ultimate goal of autonomous networks (refer to
[i.4]), it is essential to transform the existing business models to some new production, business and collaboration
models, including eKnowledge-as-a-Service operations model (KaaS). KaaS is about delivering the right knowledge to
the right person in the right context at the right time via desktop, laptop or any mobile device.
According to the highly autonomous system architecture proposed by Joseph Sifakis, a Greek/French computer scientist
and winner of the Turing Award in 2007, knowledge management is understood to become one of the key technical
features of autonomous networks (refer to [i.5]). Constructing the knowledge graph of a telecommunication domain
could be an important means to improve the level of network intelligence.
With the rapid development of communication networks in recent years, the number of network connections and
network data are growing rapidly, the network structure is becoming more and more complex, and there are more and
more faults. The traditional fault processing approach is difficult to handle the increasing number of network faults,
which is mainly reflected in the following three aspects:
• Traditional OAMP relies on the experience of experts, but the experience of OAMP experts varies greatly. To
accurately derive the root cause of the fault, the required skill level for OAMP personnel is very high.
• Thousands of operation and maintenance personnel deal with a large number of repetitive problems. The
accumulation of operation and maintenance experience is slow and the processing efficiency is low.
ETSI
9 ETSI GR ENI 031 V4.1.1 (2024-05)
• Reference documents, such as vendor manuals and lab documents created by operation and maintenance personnel
based on their experience, do not have standardized terminology. For example, different vendors may name the same
KPI differently, and calculate it using different formulas. This makes it difficult for the operation and maintenance
personnel to use.
Due to the existence of these problems, the automatic and intelligent network fault diagnosis technology has attracted
the attention of researchers, which are examining how to improve the collection of relevant context-aware telemetry to
more rapidly diagnose and repair faults and protect services.
In view of this problem, the present document will describe research work on the application of knowledge graphs in
the domain of telecommunication networks, integrating the experience of experts in the domains of telecommunications
and information knowledge to build knowledge graphs for the telecommunications domain, and intelligently discover
the root cause of faults by using the representation, reasoning and human-computer interaction technology of
knowledge graphs. However, the construction of the whole domain knowledge graph of telecommunication network is a
huge project that cannot be accomplished in a reasonable time frame (refer to ETSI GS ENI 019 [i.6]). Therefore,
taking the wireless access network field as the starting point, the present document puts forward the construction
schema of wireless access network fault maintenance knowledge graphs, so as to provide technical reference for
promoting the cooperation of industrial ecological partners to jointly build the general ability of fault diagnosis in the
telecommunication network domain.
4.2 Values of network fault maintenance knowledge graph
The knowledge graphs play two roles for R&D personnel in the process of fault maintenance:
• Horizontal integration of information. For example, different types of log files collected on site are organized
according to the dimensions of entity objects. This makes it easy to perform Named Entity Recognition (NER).
NER can be used for physical objects (e.g. a router or a geographic area), logical objects (e.g. a device
interface or a VPN), events (e.g. faults and notifications, such as the uploading of a new configuration or that
data is available) and other networking concepts, When troubleshooting, the R&D personnel can intuitively
see some events (alarms and operations) on the knowledge graph corresponding to the instance of a network
element. The knowledge graph can also display the events related to the instance object. After the 5G wireless
access network log file is visualized using the knowledge graph, the time for the R&D personnel to analyse the
log will be reduced.
• Transform the experience of OAMP expert personnel into a knowledge graph, enabling the knowledge from
multiple personnel and reference works to be more easily accumulated, augmented with new information, and
applied. This provides the potential to be edited into reasoning rules and reused in each existing network that
uses similar technologies and devices.
The power of a knowledge graph is its use of logic to manage and represent complex data by creating interconnected
models of entities and their relationships. This provides the ability to reason about ingested telemetry and prove its
conclusions. This in turn helps improve the operator's experience.
NOTE: The reasoning rules transformed from expert experience in the knowledge graphs are for further study.
5 Construction of wireless network fault maintenance
knowledge graphs
5.1 Framework of network fault maintenance knowledge graph
construction process
The framework of the network fault maintenance knowledge graph construction process includes four steps: data
acquisition and processing, ontology/schema design, knowledge extraction and knowledge fusion, knowledge
verification. The main process of building the network fault maintenance knowledge graph is shown in Figure 5-1.
ETSI
10 ETSI GR ENI 031 V4.1.1 (2024-05)

Figure 5-1: The main process of the network fault maintenance knowledge graph construction
An overview of building the fault maintenance knowledge graph is described below.
1) Data acquisition and processing
For data of interest, such as log and alarm data provided by the network, the system will regularly collect data, process
the data (e.g. perform tasks such as data filtering, correlation, cleansing, and deduplication) and normalize the collected
data(refer to [i.5]). After processing, the data is stored in the Network Database for further processing.
2) Ontology design and update
The Base Ontology is a set of ontologies that contain a starting ontology to work with. For example, ontologies defining
information about network entities, people, and other relevant concepts could be used. These are then combined into a
single starting ontology.
The Instantiated Ontology is used for two purposes. First, data and information that has been ingested and processed in
step 1 is incorporated directly in the Instantiated Ontology if it is in a suitable form. If not, then it is first processed in
the Working Ontology, which converts the data into entities, attributes, and relationships between entities, possibly
using the information and/or data models defined in ETSI GS ENI 019 [i.6] as a guide. These entities, attributes, and
relationships are then uploaded to the Instantiated Ontology, which verifies and integrates them, and uploads a new
version of the Ontology to the Base Ontology and also to the Working Ontology. Once this process is complete, the
Working Ontology is then used for further processing. This keeps a backup in the Instantiated Ontology in case of
problems in further processing.
3) Knowledge extraction and knowledge fusion
Knowledge extraction is the secondary processing of data in the database, aiming to extract knowledge entities (i.e. the
entities in the instantiated and working ontologies) and their relationships in the data, and add processed information to
the knowledge graph.
The main tasks of knowledge fusion include three categories of measurements. Exemplary processing tasks of each
category are provided.
• Data Processing
- Tokenization transforms the text into smaller units called tokens. Tokens can be words, punctuation
marks, numbers, symbols, or any other meaningful elements of a text. This is used as the basis for many
natural language processing tasks.
- Lemmatization is a process of finding the base or root form of a word. For example, the words "running",
"runs", and "ran" are all different forms of the word "run". This is used to normalize words for more
complex tasks, such as named entity recognition and co-reference resolution.
ETSI
11 ETSI GR ENI 031 V4.1.1 (2024-05)
- Data Annotation provides additional information to better describe the datum and its purpose and
functionality. This is typically in the form of metadata attached to the datum.
• Entity Processing
- Named Entity Resolution is a process in Natural Language Processing that involves recognizing when
two observations relate semantically to the same entity, despite possibly having been described
differently. It also involves recognizing when two observations do not relate to the same entity, despite
having been described similarly. Named Entity Resolution helps in standardizing entities and improving
the accuracy of information extraction from text data.
- Relation extraction is the task of identifying the relationships between entities. This is essential for
understanding the meaning of the data.
- Co-reference resolution is used to resolve ambiguities when extending knowledge graphs with new facts.
It also aids in semantic integration, helping to model semantic relationships between different structures
so that a coherent global view can be obtained.
• Data Fusion
- Data Alignment is a preprocessing step that ensures the collected data from different sources is in a
format that can be effectively combined or fused. This process often involves the temporal alignment of
multimedia data.
- Semantic Processing determines the meaning of the data elements, the relationships between the data
elements, and the context in which the data is collected.
- Semantic data integration is the process of combining data from disparate sources into a single, unified
dataset in a way that preserves the meaning of the data. This is done by understanding the semantics of
the data, which includes the meaning of the data elements, the relationships between the data elements,
and the context in which the data is collected.
- Semantic Data Fusion combines the different data into a single unified dataset with common semantics.
There are a number of different approaches for achieving this, including:
 Feature-level fusion: This approach involves combining features from different data sources at the
feature level. This can be done using a variety of techniques, such as averaging, weighted
averaging, and principal component analysis.
 Decision-level fusion: This approach involves making separate decisions based on each data source
and then combining the decisions. This can be done using a variety of techniques, such as majority
voting, weighted voting, and Dempster-Shafer theory.
 Model-level fusion: This approach involves combining the models from different data sources to
create a single, unified model. This can be done using a variety of techniques, such as ensemble
learning and Bayesian inference.
 Knowledge-based Fusion: This approach uses knowledge about the domain to fuse data.
Knowledge-based fusion can be used to fuse data from sources that are not directly compatible. For
example, a knowledge-based fusion system could be used to fuse data from a database and a set of
expert rules to create a more complete and accurate view of a system.
NOTE: It is recommended that multiple fusion approaches be used to provide more accurate results and ensure
that varying semantics from each data source are taken into account.
- Define Data Fusion Rules: this defines a set of rules for choosing among the above approaches as well as
handling conflicts and inconsistencies that arise during the fusion process.
ETSI
12 ETSI GR ENI 031 V4.1.1 (2024-05)
4) Knowledge graph quality evaluation
Knowledge graph quality evaluation is the process of measuring the accuracy, completeness, reliability, and consistency
of knowledge graphs. High-quality knowledge graphs are crucial for various intelligent applications and data analysis
tasks, as they rely on accurate and reliable data. The evaluation typically includes multiple dimensions, such as
correctness (accuracy of information), completeness (comprehensiveness of information), consistency (uniformity of
information across different parts), timeliness (frequency of information updates), and credibility (reliability of
information sources).
5) Knowledge graph construction and update
Knowledge graphs and ontologies have different goals, which reflect their different organization of knowledge. The
typical way to overcome this problem is to enrich and refactor the ontology to make it suitable for constructing a
knowledge graph. There are several ways to do this. One way consists of the following five steps:
1) Extract the concepts from the ontologies using either an ontology parser or NLP techniques.
2) Extract the relationships from the ontologies using the same method as in the previous step.
3) Create a schema for the knowledge graph. The schema should define nodes and edges, and optionally,
properties for each.
4) Populate the knowledge graph with data from the ontologies. This can be done using a variety of techniques,
such as graph databases and SPARQL (or similar) queries.
5) Validate the correctness of the knowledge graph.
5.2 Data acquisition and processing for knowledge graph
5.2.1 Content and format of data collection
There are three types of data available for building knowledge graph: structured data, unstructured data, and
semi-structured data. Structured data is data that is organized in a predefined format, such as a table or database.
Unstructured data is data that does not have a predefined format, such as user intent and fault cases. Semi-structured
data is data that has some structure, but it is not as rigid as structured data. Table 5-1 shows the specific data format and
source. In all cases, data is collected using ENI APIs from appropriate ENI External Reference Points (see ETSI
GS ENI 005 [i.2], clause 7).
Table 5-1: Data format and source
Name Data type Data sources
Equipment alarm data Structured data Network telemetry
Operation and maintenance log Semi-Structured data Network telemetry
Expert handbook Semi-structured data Manual
Equipment manual Semi-structured data Manual
Operation and maintenance database Structured data Open source
Operation and maintenance data table from website Semi-structured data Manual
User intent Unstructured data End user or application
Manual or Open
Failure case Unstructured data source//Third party
database
Device profile Structured data UE and Base Station
Manual or Open
Blogs from website Unstructured data source//Third party
database
5.2.2 Data normalization
In all cases, data normalization is realized by using ENI APIs from appropriate ENI External Reference Points (see
ETSI GS ENI 005 [i.2], clause 7).
ETSI
13 ETSI GR ENI 031 V4.1.1 (2024-05)
5.3 Ontology design
5.3.1 Diagram of ontology
Ontology design is a set of specifications necessary for knowledge graph data production, which is used to describe the
structure of normalized data. Figure 5-2 is a partial schematic diagram of the ontology/schema design of the network
fault maintenance knowledge graph, where the yellow block represents the type of entity, the grey block represents the
attribute of entity, cyan blocks represent the relationship between the entities. Blue lines indicate the properties of the
entities, and purple lines represent subclasses. When a new fault event is generated, the technician performs processing
by executing the appropriate troubleshooting process. Each Technician, Antenna and device belong to different cells. In
a 5G network, a base station can cover multiple cells, and each cell is associated with one base station.
Troubleshootings solve multiple root causes, and different root causes are located on different devices. For example, a
faulty access point, misconfiguration of a UE, and interference from other devices in the cell might all be part of the
same performance issue.
Figure 5-2: Ontology design for the network fault maintenance knowledge graph
ETSI
14 ETSI GR ENI 031 V4.1.1 (2024-05)
5.3.2 Definition of types and attributes of wireless fault maintenance
knowledge entities
Entities are the main units that constitute the knowledge graph. The knowledge entities maintained by wireless network
and their attributes are as follows:
• Fault event
Attribute Data type Explain
Unique ID for this event (it disambiguates this event from all other events,
eventID TimeAndDate
even of the same type)
eventType Enum Type of event (e.g. link up/down, service unavailable)
eventSeverity Enum {critical, major, minor, informational}
eventStatus Enum {open, in_progress, closed, etc.}
eventDescription String Optional attribute providing information about the event
workOrderID String ID of the job to distinguish different work order
Location String Look at the Models GS
eventTimeBegin Time Start time of the job
eventTimeEnd Time End time of the job

• Cell
Attribution Data type Explain
cellID String The ID of the cell to distinguish different cells
position String The physical location of the cell
cellType Enum The type of cell (e.g. macro, micro, pico)
cellFrequencyBand String The frequency band that the cell is operating in
Current status of cell (e.g. operational, deployed_but_not_operational,
cellStatus Enum
in_progress, planned)
cellUsers Integer Number of active users of cell
cellErrors Integer Number of errors in a given measurement time period
Data structure that contains the throughput, latency, jitter, packet loss, and
cellPerformance Custom
other key metrics
cellRange String The maximum distance that the cell can support
cellCapacity Integer The maximum number of users that the cell can support
cellTrafficLoad String The current traffic load of the cell
cellSectors Integer The number of sectors that the cell is divided into
cellBeamformingEnabled Boolean TRUE if the cell is using beamforming
TRUE if the cell is using MIMO to transmit and receive multiple data
cellMimoEnabled Boolean
streams simultaneously
cellModulationScheme String The modulation scheme that the cell is using
cellCodingSceme String The coding scheme that the cell is using
cellOutputPowerMax String The maximum output power of the cell
cellOutputPowerCurrent String The current output power of the cell

ETSI
15 ETSI GR ENI 031 V4.1.1 (2024-05)
• Base station
Attribution Data type Explain
baseStationID String ID of base station
The type of base station, such as macro base station, micro base station, or
baseStationType Enum
pico base station
vendor String The responsible manufacturer of the base station
bsFrequencyBands String The frequency bands that the base station is supporting
Current status of the base station (e.g. operational,
baseStationStatus Enum
deployed_but_not_operational, in_progress, planned)
baseStationUsers Integer Number of active users of base station
baseStationErrors Integer Number of errors in a given measurement time period
Data structure that contains the throughput, latency, jitter, packet loss, and
baseStationPerformance Custom
other key metrics
baseStationRange String The maximum distance that the base station can support
baseStationCapacity Integer The maximum number of users that the base station can support
baseStationTrafficLoad String The current traffic load of the base station
baseStationSectors Integer The number of sectors that the base station is divided into
bsBeamformingEnabled Boolean TRUE if the base station is using beamforming
TRUE if the base station is using MIMO to transmit and receive multiple data
bsMimoEnabled Boolean
streams simultaneously
bsModulationScheme String The modulation scheme that the base station is using
bsCodingSceme String The coding scheme that the base station is using
bsOutputPowerMax String The maximum output power of the base station
bsOutputPowerCurrent String The current output power of the base station

• Antenna
Attribution Data type Explain
The ID of Antenna, unambiguously distinguishing different Antennas, even if
Antenna ID String
they are of the same type and made by the same vendor
height Int The height of Antenna, in meters
tiltAngle Int Antenna's tilt angle in degrees
azimuth Int The direction in which the Antenna is pointing, in degrees
antennaType ENUM The type of antenna, such as omnidirectional, directional, or sector
antfrequencyBands String The frequency bands that the antenna is supporting
The beamwidth of the antenna, which is the angle over which the antenna
antennaeamwidth Integer
transmits its signal
The gain of the antenna, which is a measure of how much the antenna
antennaGain Integer
amplifies the signal
The voltage standing wave ratio, which is a measure of how well the
antennaVSWR Integer
antenna is matched to the transmission line
The polarization of the antenna, which is the direction in which the
antennaPolarization Integer
antenna's electromagnetic waves oscillate
antennaPowerMax Integer The maximum power that the antenna can handle
antennaPowerCurrent Integer The current power that the antenna is handling

• Technician
Attribution Data type Explain
employeeFirstName String The first name of the employee
empl
...