WO2017012654A1 - Predictive procedure handling - Google Patents

Predictive procedure handling Download PDF

Info

Publication number
WO2017012654A1
WO2017012654A1 PCT/EP2015/066669 EP2015066669W WO2017012654A1 WO 2017012654 A1 WO2017012654 A1 WO 2017012654A1 EP 2015066669 W EP2015066669 W EP 2015066669W WO 2017012654 A1 WO2017012654 A1 WO 2017012654A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
message
measure
procedure
probability
Prior art date
Application number
PCT/EP2015/066669
Other languages
French (fr)
Inventor
András HÓCZA
Benedek Kovács
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to PCT/EP2015/066669 priority Critical patent/WO2017012654A1/en
Publication of WO2017012654A1 publication Critical patent/WO2017012654A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W24/00Supervisory, monitoring or testing arrangements

Definitions

  • the invention relates to the handling of network procedures in a telecommunications network.
  • the invention relates to the handling of network procedures using probabilistic techniques.
  • HLR Home Location Register
  • HSS Home Subscriber Service
  • IMS IP Multimedia Subsystem
  • LTE Long Term Evolution
  • Figure 1 shows the layout of a typical mobile telecommunications network
  • Figures 2 and 3 show the signalling involved for a User Equipment (UE) to register with an IMS network
  • UE User Equipment
  • the boxes labelled "initial EPC attach to default APN” (Access Point Name) and "Connect to IMS APN” in Figure 3 each comprise the messages shown in Figure 2).
  • APN Access Point Name
  • Connect to IMS APN each comprise the messages shown in Figure 2
  • blind load phenomena are system loads resulting from procedures which will eventually be rejected. There are two circumstances in which blind loads can occur: a) In a partial network failure, e.g.
  • the registration procedure is shown in Figures 2 and 3. If a failure occurs at a late stage of registration, e.g. if the MMTel AS has failed, and this causes the registration to be dropped, then all of the messages which are part of the procedure are effectively useless, and would be considered blind load. In a mass registration event, if the sheer number of requests causes a node to fail, then the problem is exacerbated, especially as nodes may not have the capacity to re-attempt failing requests as well as handling incoming requests, which could potentially cause nodes earlier in the chain to fail as well.
  • Another countermeasure which may be used to reduce blind load is "blacklisting" nodes for which messages have failed - e.g. if sending messages to a node fails a certain number of times within a certain time period, then no further messages are sent to that node until the time expires. This can cause further issues, as when a node is taken off the blacklist, the sudden rush or requests can cause it to fail again - resulting in oscillatory behaviour where the node repeatedly fails, is blacklisted, is restored, and then fails again.
  • a further countermeasure is throttling traffic on the network - i.e.
  • Priority based throttling is extremely complex and hard to design for a network using equipment from multiple vendors. Partial implementation is possible, but rarely results in enough of a gain in stability to offset the cost or the extra dropped procedures.
  • a method in a telecommunications network Network traffic is monitored, and information about successful and failing network procedures is recorded.
  • a measure of the probability of a network procedure comprising the message being successful on the basis of results of said monitoring is determined; and the network procedure comprising the message is handled in dependence upon said measure of the probability.
  • Each step may be performed at said node of the telecommunications network, or some steps may be performed at different nodes.
  • apparatus configured to operate in a telecommunications network.
  • the apparatus comprises a model builder and a model applicator.
  • the model builder is configured to monitor network traffic through the node, and record successful and failing network procedures.
  • the model applicator is configured to determine, for a message received at the apparatus or another node of the network, a measure of the probability of a network procedure comprising the message being a successful network procedure on the basis of results of said monitoring, and to cause the apparatus or the other node to handle the network procedure comprising the message in dependence upon said measure of the probability.
  • a computer program comprising computer readable code which, when run on an apparatus, causes the apparatus to perform a method according to the first aspect.
  • a system in a telecommunications network comprising an apparatus mentioned above.
  • Figure 1 is a network diagram of a typical telecommunications network
  • Figures 2 and 3 are signalling diagrams showing an exemplary network procedure
  • Figure 4 is a schematic diagram of an apparatus according to an embodiment
  • Figure 5 is an exemplary output of an N-gram model
  • Figure 6 is a flowchart of a method according to an embodiment.
  • nodes of the network record the messages which pass through them, and note which ones result in successful interactions. This would clearly result in a very large dataset very quickly, and so only certain properties of the messages may be noted, e.g. the type of message (INVITE, REGISTER, 200OK, etc), the destination, and the next hop node. This allows the data to be consolidated by keeping a count of how many messages with matching properties result in successful or failing network procedures.
  • the node handling the messages may drop the INVITE requests directed to the external network as they have a low probability of success, and are unlikely to result in actual session establishment.
  • the node handling the requests may route some traffic which is intended to go via the second next hop node instead via the first next hop node in order to improve network reliability.
  • N- grams may be used as a procedure in a telecoms system such as VoLTE is composed of individual messages which may be arranged and executed in various different ways - analogously to words in a sentence.
  • a procedure consists of messages, and machine learning natural language techniques can be adapted to determine the likelihood that a particular sequence of messages results in a successful procedure - i.e. whether the sequence results in an error response or a response indicating success.
  • the feature selection stage involves choosing the parameters on which the model will be based. Selecting irrelevant features will tend to reduce the accuracy of the model, and selecting redundant features will tend to slow down the operation of the model.
  • Message features are those which are intrinsic to the messages, for example:
  • ⁇ message type e.g. REGISTER, INVITE, 200 OK, etc.
  • Network features are those which are related to the network as a whole, rather than to an individual message, for example:
  • the initial feature space will generally be user defined - e.g. by specifying which features are input into the model.
  • the lists above show only a small proportion of an initial feature space - the feature space may contain all possible information which could be useful in the creation of a model.
  • This feature set may be further refined by machine learning algorithms by analysing which features have the best correlation with success or failure of a procedure, for example by Principal Component Analysis. Reducing the feature set in this way will speed up both the training process for the model, and the application of the model, as the complexity of each operation increases rapidly with increased numbers of features.
  • the model building step involves "training" the machine learning software on a corpus of training data which contains all of the features of the initial feature space for a large number of procedures.
  • the corpus may be obtained by monitoring traffic in the network.
  • Each message of the corpus may be represented by a combination of the features identified in the feature selection step. This allows the size of the corpus to be reduced, as information such as timestamps which is not relevant to the selected features can be disregarded.
  • the procedures in the corpus are then used to build up a data set which can be used to compute the probability of newly seen procedures, according to the model used.
  • N-gram models One model which may be applied is an "N-gram" model.
  • sequences of N messages are considered, and the probability of success or failure is computed for that sequence based on appearances of that sequence within the corpus.
  • the probability of unknown sequences may be derived from that of known sequences.
  • N- gram models can handle unknown messages (i.e. messages not included in the corpus), but they will generally be assigned a very low probability.
  • a predetermined number (N-1 ) of previous messages in the same network procedure as the message is identified. Determining a measure of the probability comprises comparing the message and the previous messages to a list of received message sequences from results of monitoring, each consisting of N messages.
  • step of monitoring network traffic through the node, and recording successful and failing network procedures comprises, for each sequence of messages of a specified sequence length (N) received as part of a network procedure, the probability is determined that said sequence results in a successful network procedure.
  • the step of determining a measure of the probability comprises matching the message and the previous messages to one of said sequences, and retrieving the probability that said sequence results in a successful network procedure.
  • the first column shows the identifiers for the messages, which encode various features of the messages.
  • the second column shows the assigned probability for the messages, as well as the number of messages in the sequence on which that probability is based (i.e. the entry [3gram] 0.46786 denotes that the probability of 0.46786 has been assigned based on a 3 message sequence (a 3-gram)).
  • a further set of training may be performed on a second corpus of procedures, to ensure that the probabilities predicted by the model are correct.
  • the model is applied to messages in the second corpus, and the number of errors (i.e. when the model predicts a successful procedure as failing, or a failing procedure as succeeding) is determined. Provided the number of errors is acceptably low, the model may be used.
  • responses based on the computed probabilities must be defined. For example, the system may choose to drop a procedure if the probability of success is below a threshold, in order to reduce blind load in other nodes.
  • the system may modify a message if the probability of success is below a second threshold, but there is an alternate route with a higher probability (e.g. the message is directed to a failing node, but the procedure can be completed using an alternative, more reliable node).
  • the system may raise an alert if the probability is below a third threshold - this alert may be to the network operator, indicating a likely problem, or to the sender of the message, and may indicate a preferred route for the message or a preferred alternative to the procedure.
  • Figure 4 shows a schematic of an apparatus 101 for building and applying the model mentioned above.
  • the model builder 102 performs the model building steps, and the model applicator 103 performs the model application steps.
  • the model builder 102 and model applicator 103 may be implemented as software modules, as processors within a node, as separate nodes, or together in the same node, or as processes in a distributed computing solution.
  • the model builder 102 is configured to monitor network traffic through the node, and record successful and failing network procedures.
  • the model applicator 103 is configured to determine, for a message received at the apparatus 101 or another node of the network, a measure of the probability of a network procedure comprising the message being a successful network procedure on the basis of results of said monitoring, and to cause the apparatus 101 or the other node to handle the network procedure comprising the message in dependence upon said measure of the probability.
  • the model builder and model applicator may be implemented as software modules, as processors within a node, as separate nodes, or together in the same node, or as processes in a distributed computing solution.
  • a particular Wi-Fi network may have a low quality which causes voice and video calls over that network to be frequently dropped. Training the model on training data including such voice and video calls will result in sequences used to establish such voice or video calls being given a low probability (due to the large number of failures). When a session establishment for a voice or video call originating or terminating within the Wi-Fi network is received, the model will predict a low possibility of success. The model applicator can then cause the session establishment to be dropped, for example in a way which would cause it to be reattempted using LTE (or other non-WiFi connectivity).
  • the model applicator may be configured to recognise low probability messages, and to drop any messages which have a probability below a certain threshold in order to reduce blind load.
  • the model applications may be determined by a further machine learning process. Using the training corpus of network procedures, a "correct" decision can be computed for each procedure, and this data can be used to adjust the response thresholds or response types used by the model applicator. For example, if a procedure was allowed to continue at an early stage, but failed at a later stage, this may indicate that the threshold for dropping or modifying that procedure at an early stage should be raised. Similarly, if the model applicator proposed dropping a large number of procedures which are eventually successful, then this may indicate that the threshold probabilities should be lowered.
  • the model may be constantly updated by incorporating live network traffic into the model building.
  • FIG. 6 is a flowchart of a method according to an embodiment.
  • Network traffic in the telecommunications network is monitored, and data about successful and failing network procedures is recorded (S101 ).
  • a measure is determined on the basis of results of the monitoring (S102).
  • the measure is a measure of the probability of a network procedure, comprising the message, being successful.
  • the network procedure comprising the message is then handled in dependence upon the measure.
  • Monitoring network traffic may comprise monitoring a network load level and/or network error states.
  • Determining the measure of the probability may comprise the following steps, a) determining a context of the message and comparing the context of the message to recorded network procedures; b) identifying previous network procedures which match the context of the message, and c) determining a proportion of the previous network procedures which were successful.

Abstract

A method in a telecommunications network. Network traffic is monitored, and data about successful and failing network procedures is recorded. Upon receipt of a message at a node of the telecommunications network, a measure of the probability of a network procedure comprising the message being successful on the basis of results of said monitoring is determined; and the network procedure comprising the message is handled in dependence upon said measure of the probability.

Description

Predictive Procedure Handling
Technical Field
The invention relates to the handling of network procedures in a telecommunications network. In particular, the invention relates to the handling of network procedures using probabilistic techniques.
Background As new telecommunications standards with more features are brought out, the network procedures involved become more complex. For example, attaching to a 2G or 3G network typically requires three Home Location Register (HLR) or Home Subscriber Service (HSS) queries, whereas attachment and registration to an IP Multimedia Subsystem (IMS) enabled Long Term Evolution (LTE) network typically requires eleven or more queries to the HSS. Each particular network procedure (e.g. registration, session initiation, etc.) consists of a particular set of messages (which may vary slightly depending on network configuration, user settings, or current network status).
As an example, Figure 1 shows the layout of a typical mobile telecommunications network, and Figures 2 and 3 show the signalling involved for a User Equipment (UE) to register with an IMS network (the boxes labelled "initial EPC attach to default APN" (Access Point Name) and "Connect to IMS APN" in Figure 3 each comprise the messages shown in Figure 2). While the nodes themselves have been similarly upgraded to cope with the increased demand, the higher signalling requirements for each procedure in new standards can result in greater sensitivity in the network to "blind load phenomena". Blind loads are system loads resulting from procedures which will eventually be rejected. There are two circumstances in which blind loads can occur: a) In a partial network failure, e.g. when a certain node fails, or an interface of a node fails, requests to be served by this node will timeout, and the procedure which the requests relate to may be dropped. b) In mass registration events, where the network is facing a large number of a specific procedure (for example registration). Such behaviour may be triggered when a node restarts, and therefore all users who would normally be assigned to that node attempt to reattach immediately, or when an unexpected event occurs and many users wish to initiate the same procedure (e.g. in the event of a large emergency, where many users attempt to contact others or phone for help).
Taking registrations as an example, the registration procedure is shown in Figures 2 and 3. If a failure occurs at a late stage of registration, e.g. if the MMTel AS has failed, and this causes the registration to be dropped, then all of the messages which are part of the procedure are effectively useless, and would be considered blind load. In a mass registration event, if the sheer number of requests causes a node to fail, then the problem is exacerbated, especially as nodes may not have the capacity to re-attempt failing requests as well as handling incoming requests, which could potentially cause nodes earlier in the chain to fail as well.
Current solutions for addressing the node failure include timeout mechanisms, resending the failed message(s), and/or reselecting the destination node. An example is described in IETF RFC 2543.
Another countermeasure which may be used to reduce blind load is "blacklisting" nodes for which messages have failed - e.g. if sending messages to a node fails a certain number of times within a certain time period, then no further messages are sent to that node until the time expires. This can cause further issues, as when a node is taken off the blacklist, the sudden rush or requests can cause it to fail again - resulting in oscillatory behaviour where the node repeatedly fails, is blacklisted, is restored, and then fails again. A further countermeasure is throttling traffic on the network - i.e. not allowing more than a certain number of requests per unit time over an interface, either by rejecting new requests after a certain limit, or by a priority based throttling approach where procedures at a later stage are allowed through, and procedures at earlier stages are dropped. However, such throttling will often drop sequences which would have been successful if left to run their course. If no throttling is used, then it is very likely that many requests will get rejected and retried until the network is overwhelmed - and then when the network eventually fails and is restored, the UEs all attempt to register again, and it fails again. Static throttling does not consider the procedure in progress - this can often result in procedures being rejected at a late stage, which causes a high level of blind load.
Priority based throttling is extremely complex and hard to design for a network using equipment from multiple vendors. Partial implementation is possible, but rarely results in enough of a gain in stability to offset the cost or the extra dropped procedures.
Summary
In order to reduce blind load in the network more effectively, an approach is proposed in which traffic through the network is monitored, results of this monitoring are used to build up a model, and that model is used to compute a measure of the probability that a message will result in a successful procedure. That measure can then be used to predictively apply throttling to the network where necessary, for example by preferring to terminate network procedures which have a low probability of being successful, or by modifying the procedure onto a more probable path.
According to an aspect of the present invention, there is provided a method in a telecommunications network. Network traffic is monitored, and information about successful and failing network procedures is recorded. Upon receipt of a message at a node of the telecommunications network, a measure of the probability of a network procedure comprising the message being successful on the basis of results of said monitoring is determined; and the network procedure comprising the message is handled in dependence upon said measure of the probability. Each step may be performed at said node of the telecommunications network, or some steps may be performed at different nodes.
According to a further aspect, there is provided apparatus configured to operate in a telecommunications network. The apparatus comprises a model builder and a model applicator. The model builder is configured to monitor network traffic through the node, and record successful and failing network procedures. The model applicator is configured to determine, for a message received at the apparatus or another node of the network, a measure of the probability of a network procedure comprising the message being a successful network procedure on the basis of results of said monitoring, and to cause the apparatus or the other node to handle the network procedure comprising the message in dependence upon said measure of the probability.
According to a further aspect, there is provided a computer program comprising computer readable code which, when run on an apparatus, causes the apparatus to perform a method according to the first aspect.
According to a further aspect, there is provided a system in a telecommunications network comprising an apparatus mentioned above.
Further embodiments of the invention are described in the appended claims.
Brief Description of the Drawings Figure 1 is a network diagram of a typical telecommunications network;
Figures 2 and 3 are signalling diagrams showing an exemplary network procedure; Figure 4 is a schematic diagram of an apparatus according to an embodiment;
Figure 5 is an exemplary output of an N-gram model; and
Figure 6 is a flowchart of a method according to an embodiment.
Detailed Description
In order to reduce the blind load, an approach is proposed below to model the likelihood of success of network procedures, and to apply the model in order to improve network congestion. The modelling and application of the model can be implemented in a variety of ways.
In the simplest embodiment, nodes of the network record the messages which pass through them, and note which ones result in successful interactions. This would clearly result in a very large dataset very quickly, and so only certain properties of the messages may be noted, e.g. the type of message (INVITE, REGISTER, 200OK, etc), the destination, and the next hop node. This allows the data to be consolidated by keeping a count of how many messages with matching properties result in successful or failing network procedures.
For example, it might be determined that 99% of REGISTER requests which are directed to a specific S-CSCF are successful, and that only 10% of INVITE requests directed to a certain external network are successful. When throttling is required, the node handling the messages may drop the INVITE requests directed to the external network as they have a low probability of success, and are unlikely to result in actual session establishment.
As a further example, it may be determined that 99% of requests with a first next hop node are successful, but only 80% of otherwise equivalent requests with a second next hop node. The node handling the requests may route some traffic which is intended to go via the second next hop node instead via the first next hop node in order to improve network reliability.
Other techniques may be used to improve the accuracy of the modelling - for example, techniques from the field of natural language modelling may be used, such as N- grams. Such techniques may be used as a procedure in a telecoms system such as VoLTE is composed of individual messages which may be arranged and executed in various different ways - analogously to words in a sentence. A procedure consists of messages, and machine learning natural language techniques can be adapted to determine the likelihood that a particular sequence of messages results in a successful procedure - i.e. whether the sequence results in an error response or a response indicating success.
There are, broadly speaking, three stages to such modelling: feature selection, model building, and model application.
The feature selection stage involves choosing the parameters on which the model will be based. Selecting irrelevant features will tend to reduce the accuracy of the model, and selecting redundant features will tend to slow down the operation of the model. For modelling of messages in a telecommunications network, there are two classes of features:
Message features are those which are intrinsic to the messages, for example:
· message type (e.g. REGISTER, INVITE, 200 OK, etc.)
• Sender
• Receiver
• Direction (incoming or outgoing)
• State changes caused or requested by the message
· Request and response codes
• User ID
• Message routing (e.g. the next hop and previous hop nodes in the route the message is taking) Network features are those which are related to the network as a whole, rather than to an individual message, for example:
• network topology
• network load (either overall load, or load on each link)
• scheduled maintenance
· known failures or other issues
The initial feature space will generally be user defined - e.g. by specifying which features are input into the model. The lists above show only a small proportion of an initial feature space - the feature space may contain all possible information which could be useful in the creation of a model. This feature set may be further refined by machine learning algorithms by analysing which features have the best correlation with success or failure of a procedure, for example by Principal Component Analysis. Reducing the feature set in this way will speed up both the training process for the model, and the application of the model, as the complexity of each operation increases rapidly with increased numbers of features.
The model building step involves "training" the machine learning software on a corpus of training data which contains all of the features of the initial feature space for a large number of procedures. The corpus may be obtained by monitoring traffic in the network. Each message of the corpus may be represented by a combination of the features identified in the feature selection step. This allows the size of the corpus to be reduced, as information such as timestamps which is not relevant to the selected features can be disregarded. The procedures in the corpus are then used to build up a data set which can be used to compute the probability of newly seen procedures, according to the model used.
One model which may be applied is an "N-gram" model. In N-gram models, sequences of N messages are considered, and the probability of success or failure is computed for that sequence based on appearances of that sequence within the corpus. The probability of unknown sequences may be derived from that of known sequences. N- gram models can handle unknown messages (i.e. messages not included in the corpus), but they will generally be assigned a very low probability.
In one embodiment of using the N-gram model, a predetermined number (N-1 ) of previous messages in the same network procedure as the message is identified. Determining a measure of the probability comprises comparing the message and the previous messages to a list of received message sequences from results of monitoring, each consisting of N messages. In another embodiment of using the N-gram model, wherein step of monitoring network traffic through the node, and recording successful and failing network procedures comprises, for each sequence of messages of a specified sequence length (N) received as part of a network procedure, the probability is determined that said sequence results in a successful network procedure. The step of determining a measure of the probability comprises matching the message and the previous messages to one of said sequences, and retrieving the probability that said sequence results in a successful network procedure.
An exemplary output of the N-gram model is shown in Figure 5. The first column shows the identifiers for the messages, which encode various features of the messages. The second column shows the assigned probability for the messages, as well as the number of messages in the sequence on which that probability is based (i.e. the entry [3gram] 0.46786 denotes that the probability of 0.46786 has been assigned based on a 3 message sequence (a 3-gram)). A further set of training may be performed on a second corpus of procedures, to ensure that the probabilities predicted by the model are correct. The model is applied to messages in the second corpus, and the number of errors (i.e. when the model predicts a successful procedure as failing, or a failing procedure as succeeding) is determined. Provided the number of errors is acceptably low, the model may be used.
In order to apply the model, responses based on the computed probabilities must be defined. For example, the system may choose to drop a procedure if the probability of success is below a threshold, in order to reduce blind load in other nodes. The system may modify a message if the probability of success is below a second threshold, but there is an alternate route with a higher probability (e.g. the message is directed to a failing node, but the procedure can be completed using an alternative, more reliable node). The system may raise an alert if the probability is below a third threshold - this alert may be to the network operator, indicating a likely problem, or to the sender of the message, and may indicate a preferred route for the message or a preferred alternative to the procedure.
Figure 4 shows a schematic of an apparatus 101 for building and applying the model mentioned above. The model builder 102 performs the model building steps, and the model applicator 103 performs the model application steps. The model builder 102 and model applicator 103 may be implemented as software modules, as processors within a node, as separate nodes, or together in the same node, or as processes in a distributed computing solution. The model builder 102 is configured to monitor network traffic through the node, and record successful and failing network procedures. The model applicator 103 is configured to determine, for a message received at the apparatus 101 or another node of the network, a measure of the probability of a network procedure comprising the message being a successful network procedure on the basis of results of said monitoring, and to cause the apparatus 101 or the other node to handle the network procedure comprising the message in dependence upon said measure of the probability. The model builder and model applicator may be implemented as software modules, as processors within a node, as separate nodes, or together in the same node, or as processes in a distributed computing solution.
As a first example, a particular Wi-Fi network may have a low quality which causes voice and video calls over that network to be frequently dropped. Training the model on training data including such voice and video calls will result in sequences used to establish such voice or video calls being given a low probability (due to the large number of failures). When a session establishment for a voice or video call originating or terminating within the Wi-Fi network is received, the model will predict a low possibility of success. The model applicator can then cause the session establishment to be dropped, for example in a way which would cause it to be reattempted using LTE (or other non-WiFi connectivity).
As a second example, the model applicator may be configured to recognise low probability messages, and to drop any messages which have a probability below a certain threshold in order to reduce blind load. The model applications may be determined by a further machine learning process. Using the training corpus of network procedures, a "correct" decision can be computed for each procedure, and this data can be used to adjust the response thresholds or response types used by the model applicator. For example, if a procedure was allowed to continue at an early stage, but failed at a later stage, this may indicate that the threshold for dropping or modifying that procedure at an early stage should be raised. Similarly, if the model applicator proposed dropping a large number of procedures which are eventually successful, then this may indicate that the threshold probabilities should be lowered. The model may be constantly updated by incorporating live network traffic into the model building.
Figure 6 is a flowchart of a method according to an embodiment. Network traffic in the telecommunications network is monitored, and data about successful and failing network procedures is recorded (S101 ). Upon receipt of a message at a node of the telecommunications network, a measure is determined on the basis of results of the monitoring (S102). The measure is a measure of the probability of a network procedure, comprising the message, being successful. The network procedure comprising the message is then handled in dependence upon the measure.
Monitoring network traffic may comprise monitoring a network load level and/or network error states.
Determining the measure of the probability may comprise the following steps, a) determining a context of the message and comparing the context of the message to recorded network procedures; b) identifying previous network procedures which match the context of the message, and c) determining a proportion of the previous network procedures which were successful. Although the invention has been described in terms of preferred embodiments as set forth above, it should be understood that these embodiments are illustrative only and that the claims are not limited to those embodiments. Those skilled in the art will be able to make modifications and alternatives in view of the disclosure which are contemplated as falling within the scope of the appended claims. Each feature disclosed or illustrated in the present specification may be incorporated in the invention, whether alone or in any appropriate combination with any other feature disclosed or illustrated herein.

Claims

CLAIMS:
1 . A method in a telecommunications network, the method comprising:
monitoring network traffic, and recording information about successful and failing network procedures;
upon receipt of a message at a node of the telecommunications network, determining a measure of the probability of a network procedure comprising the message being successful on the basis of results of said monitoring; and handling the network procedure comprising the message in dependence upon said measure of the probability.
2. A method according to claim 1 , wherein each step is performed at said node of the telecommunications network.
3. A method according to claim 1 or 2, wherein handling the network procedure in dependence upon said measure comprises one or more of:
rejecting the network procedure if the measure is below a first threshold;
modifying the message in order to re-route the message or other messages of the network procedure to an alternative path if the measure is below a second threshold; and
alerting a sender of the message and/or a network operator if the measure is below a third threshold.
4. A method according to claim 3, wherein one or more of said thresholds is determined based on a machine learning algorithm applied to a corpus of training data, the corpus of training data comprising a plurality of recorded network procedures.
5. A method according to any one of the preceding claims, wherein determining the measure of the probability comprises:
determining a context of the message and comparing the context of the message to recorded network procedures;
identifying previous network procedures which match the context of the message; and
determining a proportion of the previous network procedures which were successful.
6. A method according to any one of the preceding claims, and comprising identifying a predetermined number (N-1 ) of previous messages in the same network procedure as the message, wherein determining a measure of the probability comprises comparing the message and the previous messages to a list of received message sequences from results of said monitoring, each consisting of N messages.
7. A method according to claim 5, wherein said step of monitoring network traffic through the node, and recording successful and failing network procedures comprises, for each sequence of messages of a specified sequence length (N) received as part of a network procedure, determining the probability that said sequence results in a successful network procedure, and wherein the step of determining a measure of the probability comprises matching the message and the previous messages to one of said sequences, and retrieving the probability that said sequence results in a successful network procedure.
8. A method according to any preceding claim, wherein monitoring network traffic comprises monitoring properties of each message sent and/or received by the node, the properties comprising any one or more of:
message type;
direction of the message;
sender;
receiver;
state changes caused or requested by the message;
request and/or response codes in the message; and
user IDs associated with the message.
9. A method according to any preceding claim, wherein monitoring network traffic comprises monitoring a network load level and/or network error states.
10. Apparatus (101 ) configured to operate in a telecommunications network, the apparatus comprising:
a model builder (102) configured to monitor network traffic through the node, and record successful and failing network procedures; a model applicator (103) configured to determine, for a message received at the apparatus or another node of the network, a measure of the probability of a network procedure comprising the message being a successful network procedure on the basis of results of said monitoring, and to cause the apparatus or the other node to handle the network procedure comprising the message in dependence upon said measure of the probability.
1 1 . Apparatus according to claim 10, wherein the apparatus is configured to handle the network procedure in dependence upon said measure by performing one or more of:
rejecting the network procedure if the measure is below a first threshold;
modifying the message in order to re-route the network procedure to an alternative path if the measure is below a second threshold;
alerting a sender of the message and/or a network operator if the measure is below a third threshold.
12. Apparatus according to claim 10 or 1 1 , wherein the model applicator is configured to determine the measure of the probability by:
determining a context of the message and comparing the context of the message to recorded network procedures;
identifying previous network procedures which match the context of the message; and
determining a proportion of the previous network procedures which were successful.
13. Apparatus according to any of claims 10 to 12, wherein the model applicator is configured to identify a predetermined number (N-1 ) of previous messages in the same network procedure as the message, wherein determining a measure of the probability comprises comparing the message and the previous messages to a list of received message sequences from results of said monitoring, each consisting of N messages.
14. Apparatus according to claim 13, wherein of the model builder is configured to, for each sequence of messages of a specified sequence length (N) received as part of a network procedure, determine the probability that said sequence results in a successful network procedure, and wherein the model applicator is configured to determine the measure of the probability by matching the message and the previous messages to one of said sequences, and retrieving the probability that said sequence results in a successful network procedure.
15. Apparatus according to any of claims 10 to 14, wherein the model builder is configured to monitor properties of each message sent and/or received by the node, the properties comprising any one or more of:
message type;
direction of the message;
sender;
receiver;
state changes caused or requested by the message;
request and/or response codes in the message;
user IDs associated with the message.
16. Apparatus according to any of claims 10 to 15, wherein the model builder is configured to monitor a network load level and/or network error states.
17. A computer program comprising computer readable code which, when run on an apparatus, causes the apparatus to perform a method according to any of claims 1 to 9.
18. A system in a telecommunications network comprising an apparatus according to any of claims 10 to 16.
PCT/EP2015/066669 2015-07-21 2015-07-21 Predictive procedure handling WO2017012654A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2015/066669 WO2017012654A1 (en) 2015-07-21 2015-07-21 Predictive procedure handling

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2015/066669 WO2017012654A1 (en) 2015-07-21 2015-07-21 Predictive procedure handling

Publications (1)

Publication Number Publication Date
WO2017012654A1 true WO2017012654A1 (en) 2017-01-26

Family

ID=53762156

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2015/066669 WO2017012654A1 (en) 2015-07-21 2015-07-21 Predictive procedure handling

Country Status (1)

Country Link
WO (1) WO2017012654A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024018257A1 (en) 2022-07-19 2024-01-25 Telefonaktiebolaget Lm Ericsson (Publ) Early detection of irregular patterns in mobile networks

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1489876A1 (en) * 2003-06-17 2004-12-22 Lucent Technologies Inc. Method of minimizing reverse channel interference caused by an abnormally high number of access attempts in a wireless communications system
US20070153789A1 (en) * 2006-01-03 2007-07-05 Barker Charles R Jr Apparatus and method for multicasting data in a communication network
CN101005688A (en) * 2006-06-23 2007-07-25 华为技术有限公司 Optimizing method for distributing small area resource in mobile communication network and its system
WO2008008412A2 (en) * 2006-07-13 2008-01-17 Lucent Technologies Inc. Managing overload of an access medium for a communication system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1489876A1 (en) * 2003-06-17 2004-12-22 Lucent Technologies Inc. Method of minimizing reverse channel interference caused by an abnormally high number of access attempts in a wireless communications system
US20070153789A1 (en) * 2006-01-03 2007-07-05 Barker Charles R Jr Apparatus and method for multicasting data in a communication network
CN101005688A (en) * 2006-06-23 2007-07-25 华为技术有限公司 Optimizing method for distributing small area resource in mobile communication network and its system
WO2008008412A2 (en) * 2006-07-13 2008-01-17 Lucent Technologies Inc. Managing overload of an access medium for a communication system

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024018257A1 (en) 2022-07-19 2024-01-25 Telefonaktiebolaget Lm Ericsson (Publ) Early detection of irregular patterns in mobile networks

Similar Documents

Publication Publication Date Title
US11882005B2 (en) Predictive scoring based on key performance indicators in telecommunications system
US20210083925A1 (en) Network fault analysis method and apparatus
EP3133492B1 (en) Network service incident prediction
US10339456B2 (en) Machine learning-based troubleshooting of VoLTE calls
US10111121B2 (en) Localizing faults in wireless communication networks
US20060067227A1 (en) Scheduled determination of network resource availability
US9723501B2 (en) Fault analytics framework for QoS based services
EP2222099B1 (en) A method, device and system of disaster recovery and handover control
US20210153042A1 (en) Automated network voice testing platform
US20110122761A1 (en) KPI Driven High Availability Method and apparatus for UMTS radio access networks
US11765266B2 (en) Systems and methods for optimizing cellular network performance
US20220046119A1 (en) Handling sip messages with malformed header fields
JP6544835B2 (en) Message processing method and apparatus
WO2017012654A1 (en) Predictive procedure handling
Theera-Ampornpunt et al. Using big data for more dependability: a cellular network tale
US10742485B2 (en) Method for determining a sequence of events, a determination device for determining a sequence of events, and a providing device
US20220094589A1 (en) Communications methods and apparatus for minimizing and/or preventing message processing faults
US8848657B2 (en) Method and apparatus for detecting silent gaps in wireless network service
EP3736696A1 (en) Early gx/rx session failure detection and response
US7159148B2 (en) Method for performance and fault management in a telecommunication network
KR100693034B1 (en) Network Alarm Management System for Managing Event occurred in Network Element Device and Method for Managing Network Alarm using the same
US11784872B1 (en) Suppressing messages to an out-of-service server
US20140038594A1 (en) Call delivery for a dual mode device
US11843503B1 (en) Providing out-of-service notifications regarding a server
US11330103B1 (en) Call state notification for emergency call processing

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15744521

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15744521

Country of ref document: EP

Kind code of ref document: A1