FR3102906A1 - network incident treatment method - Google Patents

Abstract

The present invention relates to a method of processing a network incident characterized in that it comprises the implementation by data processing means (31) of a server (3) of steps of: (a) Obtaining from a plurality of network equipment (1a, 1b, 2a, 2b, 2c) of data records, called CDR, each descriptive of a network procedure from the point of view of said network equipment (1a, 1b, 2a, 2b, 2c); (b) For at least one target network procedure related to said network incident, identification of all CDRs descriptive of said target network procedure; (c) Analysis of the identified CDR set (s). Abstract figure: Fig 1

Description

process for dealing with a network incident

GENERAL TECHNICAL AREA

The present invention relates to the field of the management of the quality of service of an operator network.

More specifically, it relates to a method for processing a network incident.

STATE OF THE ART

We call CDR (call detail record) call statistics, i.e. a data file collected by a network operator concerning a call (landline, VoIP, mobile) or any other network procedure (SMS, data). CDRs are sent by all telecommunications equipment involved in the events. This data is generally used for network optimization, billing and also incident detection.

As part of monitoring the quality of service, it is indeed important to monitor and understand network events, with the finest possible vision. An analysis of the CDRs makes it possible in the event of failures to find the origins of the failures in order to restore the network as quickly as possible and degrade the user experience as little as possible.

The difficulty is that precisely, in the event of a network incident, the CDRs that arrive are only fragmentary, which complicates this analysis work. In addition, the volume of data is only increasing with the development of network infrastructures. In particular, in France, an operator has more than 20 billion network events to process.

It would therefore be desirable to have a new universal, reliable, and significantly more efficient CDR analysis solution to deal with network incidents.

According to a first aspect, the present invention therefore relates to a method for processing a network incident characterized in that it comprises the implementation by data processing means of a step server of:

(a) Obtaining from a plurality of network equipment data records, called CDRs, each descriptive of a network procedure from the point of view of said network equipment;

(b) For at least one target network procedure related to said network incident, identification of the set of CDRs descriptive of said target network procedure;

(c) Analysis of the identified CDR set(s).

According to advantageous and non-limiting characteristics:

Each descriptive CDR of a network procedure comprises a plurality of parameters, including at least one parameter linked to a subscriber and at least one parameter of the network procedure.

Two CDRs are identified as descriptive of the same target network procedure if said parameters linked to a subscriber and parameter of the network procedure exhibit a correlation.

Two CDRs are identified as descriptive of the same target network procedure using at least one decision tree.

Step (b) further comprises, for each identified set of CDRs descriptive of the same network procedure, the generation of a global data record, called Meta-CDR, combining the data of all the CDRs of the set, step (c) being implemented based on the generated Meta-CDR(s).

Step (c) includes a classification of possible causes of the incident and/or a geospatial analysis of the incident according to the location of said network equipment having provided the CDRs of the set or sets of CDRs identified.

Said plurality of network equipment comprises at least one operator equipment and at least one mobile terminal of a subscriber of said operator.

Each network device is configured to generate at least one CDR for each network procedure involving it.

According to a second aspect, a network incident processing server is proposed, characterized in that it comprises data processing means configured for:

- Obtain from a plurality of network equipment data records, called CDRs, each descriptive of a network procedure from the point of view of said network equipment;

- For at least one target network procedure related to said network incident, identify all of the CDRs descriptive of said target network procedure;

- Analyze the identified CDR set(s).

According to a second and a third aspect, there are provided a computer program product comprising code instructions for performing a method according to the first aspect of dealing with a network incident; and storage means readable by computer equipment on which a computer program product comprises code instructions for the execution of a method according to the first aspect of processing a network incident.

Other characteristics and advantages of the present invention will appear on reading the following description of a preferred embodiment. This description will be given with reference to the accompanying drawings in which:

FIG. 1 represents a preferred embodiment of an architecture for implementing the method according to the invention;

FIG. 2 illustrates an embodiment of the method according to the invention;

FIG. 3 schematically represents an example of generation of a Meta-CDR during a network procedure.

Global Architecture

Referring to Figure 1 , a method for processing a network incident in a network 20 is proposed.

By "network incident", we mean any network event potentially impacting the quality of service and the user experience during a network procedure, and which it is desirable to treat, i.e. to detect , identify, characterize and/or resolve, as soon as possible. For example, a bad handover (i.e. the change of cell when moving a user) can cause a call to be disconnected unexpectedly. The handling of an incident can thus be seen as the detection, identification, characterization and/or resolution of the network incident. In general, at least one action can be automatically detected depending on the network incident.

The network procedures in question are generally a call, but also an SMS, an MMS, an internet data transmission (data), etc.

In each network procedure, a plurality of network equipment 1a, 1b, 2a, 2b, 2c are always involved, whether personal equipment 1a, 1b to a subscriber (generally "terminals", i.e. say the source or destination equipment of the network procedure, in particular mobile terminals of the smartphone type held by subscribers), and the operator equipment 2a, 2b, 2c which are intermediate equipment of the router type, relay antenna, etc. . involved in signal transmission and routing for said network procedure.

For example, in FIG. 1, two mobile terminals 1a, 1b are connected to the Internet network 20 via an operator network 21 thanks to relay antennas 2a, 2b. A telecom network composed of aggregation equipment, 2c routers and "core" equipment (voice, data, etc.) as well as service platforms interconnects base stations or other routers so that a call between terminals 1 involves five network devices 1a, 1b, 2a, 2b, 2c. In the example shown, antenna 2b has a problem interrupting the connection with terminal 1b.

A remote server 3, typically an operator server, is located in the internet network 20 or the operator network 21 and is thus connected to each of the equipment items 1a, 1b, 2a, 2b, 2c.

As we will see, this server 3 is intended for the collection and processing of network procedure data recordings, called CDRs for Call Detail Record. Note that the term CDR was created at a time when network procedures were only calls (there was no SMS, etc.), but today the term is indeed applicable to any procedure and not just one call.

Conventionally, each piece of equipment 1a, 1b, 2a, 2b, 2c and the server 3 comprise respective data processing means of the processor type (denoted 31 for the server 3), and, where appropriate, data storage means ( a memory, denoted 32 for the server 3), for example a hard disk.

CDR

Typically, each CDR is associated with:

• a network procedure;
• a network equipment 1a, 1b, 2a, 2b, 2c.

More precisely, the CDR is descriptive of this network procedure from the point of view of said network equipment 1, 2a, 2b. By "from his point of view" is meant as the proceedings unfold for him. It is indeed possible that two pieces of equipment involved in the same procedure did not have the same "feel" (i.e. the perception of anomaly) at all, particularly in the event of an incident.

This means that for a given network procedure, there are a plurality of CDRs generated by the different network equipment 1a, 1b, 2a, 2b, 2c involved end-to-end (for example 5 in the case of the telephone call shown in Figure 1). There may nevertheless be fewer CDRs obtained in the end than equipment involved if an item of equipment 1a, 1b, 2a, 2b, 2c is faulty (in FIG. 1, the relay antenna 2b is faulty), the equipment broken down potentially no longer having the capacity to generate and/or transmit the CDRs.

Note that there may possibly be more than one CDR per device for a network procedure, if it lasts, or involves sub-events (for example, in the middle of a telephone call, a handover or an activation of a videoconference via IP), but for convenience it will be assumed in the remainder of the description that for a given procedure each piece of equipment sends a single CDR.

It is assumed that the procedure for automatic generation of CDRs by each equipment item 1a, 1b, 2a, 2b, 2c is known and those skilled in the art will be able to use known CDR mechanisms and formats.

In general, a CDR descriptive of a given network procedure contains all the information relating to this procedure except the content. In particular, the CDR comprises a plurality of parameters, including at least one parameter linked to a subscriber (in this case the subscriber at the origin of the network procedure) and at least one parameter of the network procedure.

For example, the subscriber-related parameter could be an identifier like:

• IMSI/TIMSI;
• MSISDN;
• IMEI.

The subscriber related parameter can be:

• A recipient identifier;
• A timestamp;
• A call duration,
• etc

Note that there is no parameter explicitly identifying the associated network procedure.

Process

Referring to Figure 2 , the method begins with a step (a) of obtaining from the plurality of network equipment 1a, 1b, 2a, 2b, 2c CDRs.

Typically, this collection is passive and continuous, each network device 1a, 1b, 2a, 2b, 2c being content to push its CDRs regularly. It is noted that at this stage the CDRs are obtained indiscriminately, the server 3 only knowing from which equipment 1a, 1b, 2a, 2b, 2c each CDR comes.

In a step (b), for at least one target network procedure linked to said network incident, the set of descriptive CDRs of said target network procedure is identified.

More specifically, "set" means all the CDRs associated with the same network procedure (the said target procedure), regardless of the originating network equipment 1a, 1b, 2a, 2b, 2c. The idea is to reconstitute a procedure thanks to the points of view of the different equipment. As we will see, this step (b) is called "multi-equipment correlation".

By "target network procedure related to said incident", we mean a procedure impacted by the incident, and advantageously some previous procedures (for example the last 10). Indeed, at this stage we do not necessarily know the existence of an incident, and the latter can be detected by the presence of one or more CDRs representative of an incident. It is then sufficient to identify the other CDRs associated with the same procedure.

Note that here step (b) can even be implemented for other network procedures than the target procedure(s), or even all the network procedures (i.e. all the available CDRs will be grouped into sets) if the power of server calculation 3 is sufficient.

Preferably, two CDRs are identified as descriptive of the same target network procedure if said parameters linked to a subscriber and/or parameters of the network procedure exhibit a correlation.

It is indeed important to understand that the parameters of two CDRs will rarely coincide exactly. For example, the IMSI/TIMSI, MSISDN, IMEI identifiers used are not the same depending on the equipment. In addition, the timestamp may be different if the equipment does not have the same clock or take different reference points (for example, during a call, the calling terminal 1a will have the time when the subscriber presses the call button, for a router 2c the time at which the call is received, and for the destination terminal 1b the time at which it picks up). Thus, it is verified that the parameters have a correlation, that is to say are likely to correspond to the same procedure, thanks to conversion rules according to the associated network equipment 1a, 1b, 2a, 1b, 2c. For example, from a first call CDR and logic, one can determine possible timestamp windows for the other correlated CDRs, based on their originating equipment.

Furthermore, it is possible to use at least one decision tree allowing a prioritization of the CDRs and the data that they contain according to the procedure diagram in which one finds oneself and the difference in quality of information offered by the equipment 1a, 1b , 2a, 2b, 2c.

Preferably, step (b) comprises, for each set of CDRs descriptive of the same network procedure (i.e. determined as correlated), the generation of a global data record, called Meta-CDR, combining the data of all the CDRs of the set. In other words, each parameter of a CDR in the set is populated as a parameter of the Meta-CDR.

We can thus see the Meta-CDR as a multi-equipment CDR allowing to have an overview of a network procedure. In addition, this overview is at very different levels since it can go as far as subscriber terminals 1a, 1b and model a feeling of the perceived experience and not only the QoS observed in the operator network.

An example of generating a Meta-CDR is shown in Figure 3 . It can be seen that over the whole of the target network procedure the CDRs 1 to 12 are CDRs determined to be correlated although they come from different equipment items 1a, 1b, 2a, 2b, 2c and have different timestamps. The Meta-CDR gathers all the parameters of these different CDRs.

In a final step (c), the set or sets of identified CDRs (where appropriate in the form of Meta-CDRs) are analyzed, in particular so as to, as explained, detect, identify, characterize and/or resolve the incident. Note that one or more sets of CDRs are involved depending on the number of target network procedures.

This step (c) can be done in many different ways, but in all cases it is understood that analyzing only the CDRs associated with target procedures makes it possible to greatly reduce the number of analyzes (more precisely, we no longer analyze all the blind CDRs, but only relevant and correlated ones) and thus increase processing capacity.

Advantageously, step (c) comprises a classification of the possible causes of the incident, in particular on the basis of said plurality of target procedures, in particular so as to establish a chronology of the network incident, but also in order to better identify the real reason that is causing the problem.

Advantageously, step (c) comprises a geospatial analysis, that is to say relating to the location of the network equipment 1a, 1b, 2a, 2b, 2c concerned by the CDRs associated with the target procedures, whether this is a location known because of the fixed nature of the equipment, for example for a relay antenna 2a, 2b), or thanks to geolocation means (GPS position of a terminal 1a, 1b). In particular, it is possible to create "heat zones" to observe the impact of a network incident on a map, but also to detect false positives related to geographical impossibilities due to quality problems data from network equipment 1a, 1b, 2a, 2b, 2c.

Server and computer program product

According to a second aspect, the invention relates to a server 3 configured for the implementation of this method.

In particular, this server 3 comprises data processing means 31 configured to obtain from a plurality of network equipment 1a, 1b, 2a, 2b, 2c data records, called CDRs, each descriptive of a network procedure of the perspective of said network equipment 1a, 1b, 2a, 2b, 2c; then for at least one target network procedure linked to said network incident, identify all of the CDRs descriptive of said target network procedure (if necessary, generate a Meta-CDR for each set of CDRs identified); and parsing the identified CDR set(s)

According to a third and a fourth aspect, the invention relates to a computer program product comprising code instructions for the execution (in particular on the data processing means 31 of the server 3) of the method for processing an incident network, as well as storage means readable by computer equipment (in particular data storage means 32 of the server 3) on which this computer program product is found.

Claims (11)

Method for processing a network incident, characterized in that it comprises the implementation by data processing means (31) of a server (3) of steps of:
(a) Obtaining from a plurality of network equipment (1a, 1b, 2a, 2b, 2c) data records, called CDRs, each descriptive of a network procedure from the point of view of said network equipment (1a, 1b, 2a, 2b, 2c);
(b) For at least one target network procedure linked to said network incident, identification of all the CDRs descriptive of said target network procedure;
(c) Analysis of the identified CDR set(s). A method according to claim 1, wherein each CDR descriptive of a network procedure comprises a plurality of parameters, including at least one parameter related to a subscriber and at least one parameter of the network procedure. A method according to claim 2, wherein two CDRs are identified as descriptors of the same target network procedure if said subscriber related and network procedure parameter correlate. A method according to claim 3, wherein two CDRs are identified as descriptive of the same target network procedure using at least one decision tree. Method according to one of Claims 1 to 4, in which step (b) further comprises, for each identified set of CDRs descriptive of the same network procedure, the generation of a global data record, called Meta-CDR , combining data from all CDRs in the set, step (c) being implemented based on the generated Meta-CDR(s). Device according to one of Claims 1 to 5, in which step (c) comprises a classification of possible causes of incident and/or a geospatial analysis of the incident according to the location of said network equipment (1a, 1b , 2a, 2b, 2c) having supplied the CDRs of the set or sets of identified CDRs. Method according to one of Claims 1 to 6, in which the said plurality of network equipment items (1a, 1b, 2a, 2b, 2c) comprises at least one operator equipment item (2a, 2b, 2c) and at least one mobile terminal ( 1a, 1b) of a subscriber of said operator. Method according to one of Claims 1 to 7, in which each network device (1a, 1b, 2a, 2b, 2c) is configured to generate one or more CDRs for each network procedure involving it. Network incident processing server (3) characterized in that it comprises data processing means (31) configured to:
- Obtain from a plurality of network equipment (1a, 1b, 2a, 2b, 2c) data records, called CDR, each descriptive of a network procedure from the point of view of said network equipment (1a, 1b, 2a, 2b, 2c);
- For at least one target network procedure linked to said network incident, identify all of the CDRs descriptive of said target network procedure;
- Analyze the identified CDR set(s). Computer program product comprising code instructions for the execution of a method according to one of Claims 1 to 8 for processing a network incident, when the said program is executed by a computer Storage means readable by computer equipment on which a computer program product comprises code instructions for the execution of a method according to one of Claims 1 to 8 for processing a network incident.