CN116458118A - Method, apparatus and computer program - Google Patents

Abstract

There is provided an apparatus comprising means for, at a service provider: receiving information from at least one neighboring entity of a network object or a management object, wherein the network object or the management object has generated an alert; determining fault information associated with a network target or management object generating the alert based on the information; and providing a report based on the fault information to the service consumer.

Description

Method, apparatus and computer program

Technical Field

The present application relates to a method, apparatus, system, and computer program, and in particular, but not exclusively, to alarm malfunction detection and resolution.

Background

A communication system may be considered a facility that enables communication sessions between two or more entities, such as user terminals, base stations, and/or other nodes, by providing carriers between the various entities involved in a communication path. For example, the communication system may be provided by means of a communication network and one or more compatible communication devices (also called stations or user equipment) and/or application servers. The communication session may include, for example, communications for carrying data for the communication, such as voice, video, electronic mail (email), text messages, multimedia, content data, time Sensitive Network (TSN) streams, and/or data in industrial applications, such as critical system messages between actuators and controllers, critical sensor data (such as measurements, video feeds, etc.) towards the control system, and the like. Non-limiting examples of services provided include two-way or multi-way calls, data communication or multimedia services, and access to data network systems such as the internet.

In a wireless communication system, for example, at least a portion of a communication session between at least two stations or between at least one station and at least one application server (e.g., for video) occurs over a wireless link. Examples of wireless systems include Public Land Mobile Networks (PLMNs) operating based on 3GPP radio standards, such as E-UTRA, new radio, satellite-based communication systems, and different wireless local area networks, e.g., wireless Local Area Networks (WLANs). A wireless system may be generally divided into cells and is therefore generally referred to as a cellular system.

The user may access the communication system by means of a suitable communication device or terminal. The communication device of a user may be referred to as a User Equipment (UE) or user equipment. The communication device is provided with suitable signal receiving and transmitting means to enable communication, for example to enable access to a communication network or communication directly with other users. A communication device may access one or more carriers provided by a network, such as a base station of a cell, and transmit and/or receive communications on the one or more carriers. In Carrier Aggregation (CA), two or more carriers are combined into one channel. In Dual Connectivity (DC), two carriers from different sites are combined, that is, a user equipment may be dual (or multiple) connected to two (or more) sites.

Communication systems and associated devices typically operate in accordance with a given standard or specification which sets out what the various entities associated with the system are permitted to do and how that should be achieved. Communication protocols and/or parameters which should be used for the connection are also typically defined. One example of a communication system is UTRAN (3G radio). Other examples of communication systems are Long Term Evolution (LTE) of Universal Mobile Telecommunications System (UMTS) based on E-UTRAN radio access technology, and so-called 5G systems (5 GS) comprising a 5G or Next Generation Core (NGC) and a 5G access network based on New Radio (NR) radio access technology. The 5GS including NR is being standardized by the third generation partnership project (3 GPP).

Disclosure of Invention

In a first aspect, there is provided an apparatus comprising means for, at a service provider: receiving information from at least one neighboring entity of a network object or a management object, wherein the network object or the management object has generated an alert; determining fault information associated with the network object or management object generating the alert based on the information; and providing a report based on the fault information to the service consumer.

The report may include an indication of at least one of: fault type, fault location, network object or management object identity, fault severity level, and proposed action to resolve the fault.

The information from the at least one neighboring entity may include metadata identifying a source of the information.

The means for determining may include: means for determining lost or erroneous data based on at least one of the historical data and information from at least one neighboring entity.

The network object or management object may include an alarm proxy or a management service producer.

The management service producer may include a fault supervision function, a fault management function, or a performance management function.

At least one neighboring entity may be at the same or different automation level as the network object or the management object.

The information from at least one neighboring entity may relate to another alert, one of an alert, event, and heartbeat for a given resource or link, or one of an alert and event from a neighboring entity.

The at least one neighboring entity may comprise a network element, a management function, or a management service producer.

In a second aspect, there is provided a method comprising, at a service provider: receiving information from at least one neighboring entity of a network object or a management object, wherein the network object or the management object has generated an alert; determining fault information associated with the network object or management object generating the alert based on the information; and providing a report based on the fault information to the service consumer.

The report may include an indication of at least one of: fault type, fault location, network object or management object identity, fault severity level, proposed action to resolve the fault.

The information from the at least one neighboring entity may include metadata identifying a source of the information.

The determining may include: lost or erroneous data is determined based on at least one of the historical data and information from at least one neighboring entity.

The network object or management object may include an alarm proxy or a management service producer.

The management service producer may include a fault supervision function, a fault management function, or a performance management function.

At least one neighboring entity may be at the same or different automation level as the network object or the management object.

The information from at least one neighboring entity may relate to another alert, one of an alert, event, and heartbeat for a given resource or link, or one of an alert and event from a neighboring entity.

The at least one neighboring entity may comprise a network element, a management function, or a management service producer.

In a third aspect, there is provided an apparatus comprising: at least one processor and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to, at a service provider: receiving information from at least one neighboring entity of a network object or a management object, wherein the network object or the management object has generated an alert; determining fault information associated with the network object or management object generating the alert based on the information; and providing a report based on the fault information to the service consumer.

The report may include an indication of at least one of: fault type, fault location, network object or management object identity, fault severity level, and proposed action to resolve the fault.

The information from the at least one neighboring entity may include metadata identifying a source of the information.

The apparatus may be configured to: lost or erroneous data is determined based on at least one of the historical data and information from at least one neighboring entity.

The network object or management object may include an alarm proxy or a management service producer.

The management service producer may include a fault supervision function, a fault management function, or a performance management function.

At least one neighboring entity may be at the same or different automation level as the network object or the management object.

The information from at least one neighboring entity may relate to another alert, one of an alert, event, and heartbeat for a given resource or link, or one of an alert and event from a neighboring entity.

The at least one neighboring entity may comprise a network element, a management function, or a management service producer.

A computer readable medium comprising program instructions for causing an apparatus to perform at a service provider at least the following: receiving information from at least one neighboring entity of a network object or a management object, wherein the network object or the management object has generated an alert; determining fault information associated with the network object or management object generating the alert based on the information; and providing a report based on the fault information to the service consumer.

The report may include an indication of at least one of: fault type, fault location, network object or management object identity, fault severity level, and proposed action to resolve the fault.

The information from the at least one neighboring entity may include metadata identifying a source of the information.

The apparatus may be caused to: lost or erroneous data is determined based on at least one of the historical data and information from at least one neighboring entity.

The network object or management object may include an alarm proxy or a management service producer.

The management service producer may include a fault supervision function, a fault management function, or a performance management function.

At least one neighboring entity may be at the same or different automation level as the network object or the management object.

The information from at least one neighboring entity may relate to another alert, one of an alert, event, and heartbeat for a given resource or link, or one of an alert and event from a neighboring entity.

The at least one neighboring entity may comprise a network element, a management function, or a management service producer.

In a fourth aspect, there is provided a non-transitory computer readable medium comprising program instructions for causing an apparatus to perform at least the method according to the second aspect.

In the foregoing, many different embodiments have been described. It should be appreciated that additional embodiments may be provided by combining any two or more of the above embodiments.

Drawings

Embodiments will now be described, by way of example only, with reference to the accompanying drawings, in which:

fig. 1 shows a schematic diagram of an example 5GS communication system;

FIG. 2 shows a schematic diagram of an example mobile communication device;

FIG. 3 illustrates a schematic diagram of an example control device;

FIG. 4 shows a schematic diagram of an example MDA functional overview and architecture;

FIG. 5 illustrates example levels of automation in network management;

FIG. 6 shows a flow chart of a method according to an example embodiment;

FIG. 7 illustrates a signaling flow of an example alarm malfunction (malfunction) risk assessment process;

fig. 8 shows a schematic diagram of multi-level data tracking for backtracking alarms of MnS producer mismatch.

Detailed Description

Before explaining examples in detail, some general principles of a wireless communication system and a mobile communication device will be briefly explained with reference to fig. 1 to 3 to help understand a technology underlying the described examples.

An example of a suitable communication system is the 5G system (5 GS). The network architecture in 5GS may be similar to that of LTE-advanced. The base station of the NR system may be referred to as a next generation node B (gNB). Changes to the network architecture may depend on the need to support various radio technologies and finer QoS support, as well as some on-demand requirements for QoS levels such as QoE supporting user angles. Furthermore, network aware services and applications, and service and application aware networks, may bring about changes to the architecture. These are all related to user centric content delivery network (UC-CDN) approaches. NR can use multiple-input multiple-output (MIMO) antennas with many more base stations or nodes than LTE (so-called small cell concept), including macro sites operating in cooperation with smaller stations, and possibly also employ various radio technologies to achieve better coverage and enhanced data rates.

The 5G network may utilize Network Function Virtualization (NFV), a network architecture concept that proposes to virtualize network functions that may be operably connected or linked together to provide services. A Virtualized Network Function (VNF) may comprise one or more virtual network function components that run computer program code in a virtual machine or container using standard or generic types of servers instead of custom hardware. Cloud computing or data storage may also be utilized. In radio communications, this may mean that network function operations are performed at least in part in a server, host, or node operatively coupled to the remote radio head. Network function operations may also be distributed among multiple servers, nodes, or hosts. It should also be appreciated that the labor allocation between core network operation and base station operation may be different from LTE, or even non-existent.

Fig. 1 shows a schematic representation of a 5G system (5 GS) 100. The 5GS may include a User Equipment (UE) 102 (which may also be referred to as a communication device or terminal), a 5G radio access network (5 GRAN) 104, a 5G core network (5 GCN) 106, one or more Application Functions (AFs) 108, and one or more Data Networks (DNs) 110.

An example 5G Core Network (CN) includes functional entities. The 5gcn 106 may include one or more access and mobility management functions (AMFs) 112, one or more Session Management Functions (SMFs) 114, an authentication server function (AUSF) 116, a Unified Data Management (UDM) 118, one or more User Plane Functions (UPFs) 120, a unified data store (UDR) 122, and/or a Network Exposure Function (NEF) 124. The UPF is controlled by an SMF (session management function) which receives policies from a PCF (policy control function).

The CN is connected to terminals, e.g. UEs, via a Radio Access Network (RAN). The 5GRAN may include one or more GNodeB (GNB) distributed cell functions connected to one or more GNodeB (GNB) centralized cell functions. The RAN may include one or more access nodes.

The UPF (user plane function), whose role is called PSA (PDU session anchor), may be responsible for forwarding frames back and forth between DN (data network) and tunnels established through 5G towards the UE(s) exchanging traffic with DN.

One possible mobile communication device will now be described in more detail with reference to fig. 2, fig. 2 showing a schematic partial cross-sectional view of a communication device 200. Such communication devices are often referred to as User Equipment (UE) or terminals. A suitable mobile communication device may be provided by any device capable of transmitting and receiving radio signals. Non-limiting examples include a Mobile Station (MS) or mobile device, such as a mobile phone or so-called "smart phone", a computer equipped with a wireless interface card or other wireless interface facility (e.g., a USB dongle), a Personal Data Assistant (PDA) or tablet equipped with wireless communication capabilities, or any combination of these, etc. For example, a mobile communication device may provide communications for carrying data such as voice, electronic mail (email), text messages, multimedia, and the like. Thus, a user can be provided with many services via his communication device. Non-limiting examples of such services include two-way or multi-way calls, data communications or multimedia services, or simply access to a data communications network system such as the internet. Users may also be provided with broadcast or multicast data. Non-limiting examples of content include downloads, television and radio programming, video, advertisements, various alerts, and other information.

The mobile device is typically provided with at least one data processing entity 201, at least one memory 202, and possibly other components 203 for software and hardware assisted execution of tasks it is designed to perform, including controlling access to and communication with access systems and other communication devices. The data processing, storage, and other associated control means may be provided on a suitable circuit board and/or in a chipset. This feature is indicated by reference numeral 204. The user may control the operation of the mobile device by means of a suitable user interface such as a keypad 205, voice commands, touch sensitive screen or keyboard, combinations thereof, and the like. A display 208, a speaker, and a microphone may also be provided. In addition, the mobile communication device may include suitable connectors (wired or wireless) to other devices and/or for connecting external accessories (e.g., hands-free devices) thereto.

The mobile device 200 may receive signals over the air or radio interface 207 via suitable means for receiving and may transmit signals via suitable means for transmitting radio signals. In fig. 2, the transceiver device is schematically represented by block 206. The transceiver means 206 may be provided, for example, by means of a radio and an associated antenna arrangement. The antenna arrangement may be arranged inside or outside the mobile device.

Fig. 3 shows an example embodiment of a control apparatus for a communication system, e.g. to be coupled to and/or for controlling a station (such as a RAN node, e.g. a base station, eNB or gNB) of an access system, a relay node or core network node (such as an MME or S-GW or P-GW), or a core network function (such as an AMF/SMF), or a server or host. The method may be implemented in a single control device or across more than one control device. The control means may be integrated with or external to a node or module of the core network or RAN. In some embodiments, the base station includes a separate control device unit or module. In other embodiments, the control device may be another network element, such as a radio network controller or a spectrum controller. In some embodiments, each base station may have such a control device, as well as a control device provided in a radio network controller. The control means 300 may be arranged to provide control of the communication in the service area of the system. The control device 300 comprises at least one memory 301, at least one data processing unit 302, 303, and an input/output interface 304. Via this interface, the control means may be coupled to the receiver and transmitter of the base station. The receiver and/or transmitter may be implemented as a radio front-end or a remote radio head.

The following relates to network failure and security management in which a set of alarms of different levels (e.g., automation levels) are deployed to ensure proper network operation. It relates in particular to the following scenarios: in the context of a service-based management architecture (SBMA) in which security and alarm data is collected, network elements may hold alarms and other monitoring agents or management service (MnS) producers, such as Performance Measurements (PM) and fault supervision/fault management (FS/FM). Such data from various sources may achieve varying degrees of data correlation, e.g., correlation with one source to another source, and/or correlation with other data knowledge, e.g., correlation with expected values for a given date and time instance. If the result of such a correlation process exceeds an expected level, an alarm regarding the corresponding fault or safety incident may be triggered.

In 3gpp SA5 data analysis (i.e., management Data Analysis Service (MDAS)), TR 28.809 introduces a use case for alarm incident analysis as part of network fault management, as well as a use case for security analysis.

An overview of example Management Data Analysis (MDA) functions and architecture as shown in fig. 4, fig. 4 shows analysis (i.e., may be a proprietary analysis model), various types of input sources (e.g., mnS producer, MDAs producer, and network data analysis function (NWDAF)), and MDAs producer output towards MDAs consumer.

MDAS can be applied to different levels of management architecture, examples of which are shown in fig. 5, fig. 5 showing Network Element (NE) levels, domain levels, cross-domain levels, and service levels. Each level operates independently in parallel while interacting by exchanging analysis data between immediately adjacent automation levels.

However, when an alarm is triggered, the corresponding alarm agents or producers of PM and FS/FM management services (i.e., FS/FM MnS producers) may not always be trusted.

In some cases, the alarm agent may trigger an alarm (i.e., a false positive alarm) in the event that it is not needed, and in some cases, the alarm is not triggered, although it should. I.e. false negative alarms.

The alarm malfunction may be related to:

a) Wherein the alarm agent is hacked for security breaches. As a result, the output of the correlator is tampered with, resulting in untrusted data.

b) The improper behavior of the alarm proxy due to a non-human fault, i.e. a malfunction of the software/hardware of the alarm proxy and/or a malfunction of the corresponding MnS of NE or MnF.

For the reasons described above, failure and trust of data collected by an alarm proxy may affect the operation, security, and correctness of network automation. Thus, there is a need to increase the level of trust for the alarm agent (or, in general, the correlator in the event) and the corresponding data collected. Such an increased level of trust should be guaranteed to the network in an autonomous manner at different operation levels, i.e. without manual intervention.

The following relates to alarm failure problems, i.e., FM IRPAgent according to TS 28.545, TS 28.517, TS 32.111, alarm failure related to MnS producer in SBMA, and alarm failure related to MDAS (e.g., according to TS 28.809), all considered in the context of autonomous networks.

Fault management is a fundamental problem in mobile network management, which has been solved since the early stages of self-organizing networks (SON) TS 28.628, TS 32.522, TS 28.313, especially in view of self-healing TS 32.541, wherein monitoring from various network elements enables SON functions to autonomously detect and repair/optimize network configuration.

Via the alarm correlation concept in TR 32.832, one further step towards more complex systems is considered, where some alarms are combined together to implement the network failure faced, and root cause analysis may be directed to the root cause of the problem.

Fault management and alarm correlation are also considered in US7525422B2, focusing on alarm combinations with certain alarms to trigger other alarms, creating a comprehensive diagnosis. A topology-based reasoning apparatus for root cause analysis of network faults is proposed in EP1279211B1, wherein the system determines a root cause fault indicated by at least one alarm. Alarm correlation in a network function virtualization environment is discussed in US20170346676A1, by forwarding at least one of the correlated alarms to an entity that manages an upper layer of the network function virtualization environment for further correlation with the upper layer alarms. Event correlation across heterogeneous operations to take security into account is introduced in US20160301709 A1.

All of these efforts consider associating and/or combining alarms to create a comprehensive view of the problem and investigate root cause analysis to identify sources of the problem across different technologies considering both fault management and security. However, none of these solutions consider the case of agent failure providing an alarm or malicious activity related to alarm generation, and how to detect and solve the problem.

Fig. 6 shows a flow chart of a method according to an example embodiment.

In a first step S1, the method comprises: information from at least one neighboring entity of a network object or a management object is received at a service provider, wherein the network object or the management object has generated an alert.

In a second step S2, the method comprises: based on this information, fault information associated with the network object or management object that generated the alert is determined.

In a third step S3, the method comprises: a report based on the fault information is provided to the service consumer.

The method provides an MDAS-based analysis service for evaluating malfunctions of agents or MnS producers that provide alarms or PM, FS/FM due to malfunction or malicious activity. Such an analysis service may identify agents or MnS producer malfunction issues associated with reporting fault alarms, such as fault alarms associated with inconsistent performance and fault information between adjacent Network Elements (NEs) (e.g., cells) or MnS/mnfs.

The network object or management object may include, but is not limited to, an alarm agent or MnS producer, such as a fault supervision function, a fault management function, or a performance management function.

The service provider may be an MDAS provider and the service consumer may be an MDAS consumer.

The at least one neighboring entity may comprise a network element, mnF or MnS producer.

At least one neighboring entity may be at the same or different automation level as the network object or the management object.

Alarm malfunction risk assessment MDAS may select and correlate PM/FS data and/or Key Performance Indicators (KPIs) (based on TS 28.552 and TS 28.554) from a particular NE or management function (MnF) and across different automation levels in order to check consistency between neighboring agents or mnss. For example, if the proxy or MnS reports high mobility towards a particular neighboring cell and the particular cell reports low user density, this may be an indication of failure risk to investigate. Local analysis may be combined with more extensive regional analysis to facilitate root cause analysis.

The information from at least one neighboring entity may relate to another alert, one of an alert, an event, and a heartbeat for a given resource or link in depth, or one of an alert and an event from a neighboring entity. Alarm malfunction risk assessment MDAS may associate alarms or performance information from other alarms, alarms/events/heartbeats related to a particular resource or link, alarms/events from neighboring NEs/NFs and/or MnS/MnF.

Table 1 shows an example of data that information from at least one neighboring entity may include.

TABLE 1

The information from the at least one neighboring entity may include: metadata identifying the source of the information. The multi-level metadata may be used to identify the source of the alert agent or MnS producer, which is used to trace back the malfunctioning alert agent(s) or MnS producer. Multiple levels of metadata in PM, FS/FM and performance KPI reports may be introduced to enable tracking (i.e., backtracking) of sources of malfunctioning agents or MnS producers across various MDAS levels (including domain levels, cross-domain levels, or even service levels), although data processing is done analytically at each individual MDAS level. An alarm agent or MnS producer is associated with the data source such that the point of failure or security incident is tracked.

The means for determining fault information may include: means for determining lost or erroneous data based on at least one of the historical data and information from at least one neighboring entity. That is, a value estimation mechanism may be used to recover lost or erroneous data (e.g., data values) based on the use of historical data, optionally in combination with neighboring data.

The alarm malfunction risk assessment MDAS may associate FS/FM control/report related configurations, such as filters, subscribers, notifications, clear alarms, acknowledge alarms, etc.

The report may include an indication of at least one of: fault type, fault location, network object or management object identity, fault severity level, and proposed action to resolve the fault. For example, an analysis report, i.e., an Application Programming Interface (API), may be generated towards the MDAS consumer that identifies the type, location, network object or management object involved, severity level, and recommended actions, such as quarantine agent, mnS producer, and/or NE of the failure.

Table 2 provides further details of the types of information that may be included in the report. The fault type may be a security incident identifier. The network object or management object identity may be an identifier of the affected object, e.g. NF, mnS, mnF, protocol Data Unit (PDU) session, quality of service (QoS) flow, slice identifier. The severity level may be an incremental indicator, e.g., critical, medium, unimportant. The information may include an indication of the start/stop time of the fault. The information may include an indication of a malfunctioning source agent or MnS producer to isolate and restore the malfunctioning agent or MnS producer. The proposed actions may be, but are not limited to: quarantine/terminate malfunctioning agents or MnS producers and recover data based on neighbor data.

In an example embodiment, the malfunctioning MDAS used to evaluate the agent or MnS may perform failure, virtualization, corresponding data association with NF contexts, and provide the following recommendations to introduce a new interface to the service consumer that contains the attributes shown in table 2.

TABLE 2

FIG. 7 illustrates a flow chart of an example alarm malfunction risk assessment process. The MDAS consumer requests analysis from the MDAS producer, which requests and gathers performance measurements in the corresponding MnS and/or MDAS producer in steps 2 and 3, respectively. In steps 4 and 5, the MDAS performs an analysis and provides a recommendation based on the analysis. Then in step 6, a report is provided to the MDAS consumer using an interface having attributes as described with reference to table 2.

Fig. 8 shows a schematic representation of multi-level data tracking for backtracking alarms or MnS producer mismatches according to an example embodiment. In this example, the multi-level metadata for backtracking is deployed in different spatial regions or domains. The backtracking process is part of the MDAS in the corresponding automation level.

Management agents (e.g., integrated Reference Point (IRP) agents) or MnS producers or MDAS may be deployed on NEs and/or at relatively large areas (i.e., domains), even across domains. The backtracking process portion of the MDAS cross-domain or range area 801 may identify data mismatches in data inputs from data tracking processes from different domains 802 (e.g., different cities). Within each domain, a plurality of local data agents or MnS producers deployed at NE level 803 introduce metadata for backtracking various measurements, such as PM and FS/FM, performance Key Performance Indicators (KPIs), or local data analysis.

The use cases and solutions related to fault management problems recorded in TR 28.809 can be enhanced with the advantages of analysis and new solutions related to alarm agents and/or MnS producer safety can also be introduced. Such a solution can not only identify and avoid false positives and false negatives, but also track and address the "root cause and object" that caused it.

The methods described with reference to fig. 6-8 provide alarm malfunction risk assessment MDAS that can address the problem of a faulty alarm due to agent or MnS producer malfunction or agent or MnS producer malicious activity related to alarm generation.

The method can be applied to various alarm malfunctions, such as false/missing alarms/events, which may be caused by different factors, such as malfunction, man-made, etc., as well as to different phases, such as making alarm subscriptions, generating alarms, generating alarm notifications, reporting alarms, making alarm acknowledgements or clears, etc. Thus, data entry and root cause analysis are considered at each stage.

The method may be implemented in the control device described with reference to fig. 3.

An apparatus may include means for, at a service provider: receiving information from at least one neighboring entity of a network object or a management object, wherein the network object or the management object has generated an alert; determining fault information associated with a network target or management object generating the alert based on the information; and providing a report based on the fault information to the service consumer.

It should be understood that the apparatus may comprise or be coupled to other units or modules etc., such as a radio unit or a radio head for transmission and/or reception. Although these means have been described as one entity, the different modules and memories may be implemented in one or more physical or logical entities.

Note that although embodiments have been described with respect to LTE and 5G NR, similar principles may be applied to other networks and communication systems. Thus, while certain embodiments are described above by way of example with reference to certain example architectures for wireless networks, technologies, and standards, embodiments may also be applied to any other suitable forms of communication systems other than those illustrated and described herein.

It is also noted herein that while the above describes exemplifying embodiments, there are several variations and modifications which may be made to the disclosed solution without departing from the scope of the present invention.

In general, the various example embodiments may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects of the invention may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the invention is not limited thereto. While various aspects of the invention may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

Embodiments of the invention may be implemented by computer software executable by a data processor of a mobile device, such as in a processor entity, or by hardware, or by a combination of software and hardware. Computer software or programs (also referred to as program products, including software routines, applets, and/or macros) can be stored in any apparatus-readable data storage medium and they include program instructions for performing particular tasks. The computer program product may include one or more computer-executable components configured to perform embodiments when the program is run. The one or more computer-executable components may be at least one software code or portion thereof.

Further in this regard, it should be noted that any blocks of the logic flows in the figures may represent program steps, or interconnected logic circuits, blocks and functions, or a combination of program steps and logic circuits, blocks and functions. The software may be stored on a physical medium such as a memory chip or memory block implemented within a processor, a magnetic medium such as a hard disk or floppy disk, and an optical medium such as a DVD and its data variants CD. The physical medium is a non-transitory medium.

The memory may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory, and removable memory. The data processor may be of any type suitable to the local technical environment and may include, by way of non-limiting example, one or more of a general purpose computer, a special purpose computer, a microprocessor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an FPGA, a gate level circuit, and a processor based on a multi-core processor architecture.

Example embodiments of the invention may be practiced in various components such as integrated circuit modules. The design of integrated circuits is generally a highly automated process. Complex and powerful software tools are available for converting a logic level design into a semiconductor circuit design ready to be etched and formed on a semiconductor substrate.

The foregoing description provides a complete and informative description of exemplary embodiments of the invention by way of non-limiting example. However, various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings and the appended claims. However, all such and similar modifications of the teachings of this invention will still fall within the scope of this invention as defined in the appended claims. Indeed, still other embodiments may include combinations of one or more embodiments with any of the other embodiments discussed above.

Claims (12)

1. An apparatus comprising means for, at a service provider:

receiving information from at least one neighboring entity of a network object or a management object, wherein the network object or the management object has generated an alert;

determining fault information associated with the network object or the management object that generated the alert based on the information; and

a report based on the fault information is provided to a service consumer.

2. The apparatus of claim 1, wherein the report includes an indication of at least one of: fault type, fault location, network object or management object identity, fault severity level, and proposed action to resolve the fault.

3. The apparatus of claim 1 or claim 2, wherein the information from at least one neighboring entity comprises metadata identifying a source of the information.

4. A device according to any one of claims 1 to 3, wherein the means for determining comprises: means for determining lost or erroneous data based on at least one of historical data and the information from the at least one neighboring entity.

5. The apparatus of any of claims 1-4, wherein the network object or the management object comprises an alert agent or a management service producer.

6. The apparatus of claim 5, wherein the management service producer comprises a fault supervision function, a fault management function, or a performance management function.

7. The apparatus of any of claims 1 to 6, wherein the at least one neighboring entity is at the same or different level of automation as the network object or the management object.

8. The apparatus of any of claims 1-7, wherein the information from the at least one neighboring entity relates to another alert, one of an alert, an event, and a heartbeat for a given resource or link, or one of an alert and an event from the neighboring entity.

9. The apparatus of any of claims 1 to 8, wherein the at least one neighboring entity comprises a network element, a management function, or a management service producer.

10. A method comprising, at a service provider:

receiving information from at least one neighboring entity of a network object or a management object, wherein the network object or the management object has generated an alert;

determining fault information associated with the network object or the management object that generated the alert based on the information; and

a report based on the fault information is provided to a service consumer.

11. An apparatus, comprising: at least one processor and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to:

receiving information from at least one neighboring entity of a network object or a management object, wherein the network object or the management object has generated an alert;

determining fault information associated with the network object or the management object that generated the alert based on the information; and

a report based on the fault information is provided to a service consumer.

12. A computer readable medium comprising program instructions for causing an apparatus to perform at a service provider at least the following:

receiving information from at least one neighboring entity of a network object or a management object, wherein the network object or the management object has generated an alert;

determining fault information associated with the network object or the management object that generated the alert based on the information; and

a report based on the fault information is provided to a service consumer.