EP4409864A1 - Procédé de controle d'un accès à un service applicatif mis en oeuvre dans un réseau de télécommunications, procédé de traitement d'un message de controle d'un accès audit service applicatif, dispositifs, équipement de controle, équipement client, système et programmes d'ordinateur correspondants - Google Patents

Procédé de controle d'un accès à un service applicatif mis en oeuvre dans un réseau de télécommunications, procédé de traitement d'un message de controle d'un accès audit service applicatif, dispositifs, équipement de controle, équipement client, système et programmes d'ordinateur correspondants

Info

Publication number
EP4409864A1
EP4409864A1 EP22793193.8A EP22793193A EP4409864A1 EP 4409864 A1 EP4409864 A1 EP 4409864A1 EP 22793193 A EP22793193 A EP 22793193A EP 4409864 A1 EP4409864 A1 EP 4409864A1
Authority
EP
European Patent Office
Prior art keywords
service
equipment
access
processing
control
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
EP22793193.8A
Other languages
German (de)
English (en)
Inventor
Mohamed Boucadair
Christian Jacquenet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
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 Orange SA filed Critical Orange SA
Publication of EP4409864A1 publication Critical patent/EP4409864A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/16—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using machine learning or artificial intelligence
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5009—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/22—Alternate routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions

Definitions

  • TITLE Process for controlling access to an application service implemented in a telecommunications network, process for processing a control message for access to said application service, devices, control equipment, client equipment, system and corresponding computer programs.
  • the invention lies in the field of telecommunications, and in particular in that of telephony over IP.
  • the invention relates to the control of access by client equipment to an application service implemented in a telecommunications network.
  • VoIP Voice over IP
  • IP protocol for "Internet Protocol”
  • IP Telephony must meet customer needs, particularly from the point of view of service quality and availability, which must be at least equivalent to those provided by traditional telephony offers based on the PSTN network.
  • PSTN Switched Telephone Network
  • quality of service, robustness, high availability and resistance to failures are determining factors for users of telephone services, which are by nature real-time stream exchange services.
  • Telecommunications operators, who will also be called service providers, must particularly avoid the phenomena of overloading the elements making up the service and anticipate the anomalies which may disrupt the service as perceived by the customers.
  • overload means the inability of the service, or of certain elements of this service, to process a request to establish an application session, for example an audio, video or instant messaging IM call (or "Instant Messaging”, in English), often because of a lack of resources to process said request.
  • IM call or "Instant Messaging”, in English
  • the management of overloads is all the more delicate as the phenomenon tends to maintain itself. Indeed, the problem of overload is likely to gradually affect the elements of the service involved in the call setup procedure, and which are still trying to clear the traffic: these elements are therefore in turn affected by an overload. of traffic.
  • the dimensioning of telephone networks is based in particular on a statistical distribution of calls, governed by Erlang's laws in particular.
  • this type of dimensioning does not make it possible to deploy a service that can cope with occasional traffic overloads.
  • the origin of a bottleneck at the level of a service platform can be linked to at least two specific situations:
  • This type of situation can generate a large number of sessions made to the number in question over a relatively short period, which causes congestion that degrades the quality of service provided as perceived by users.
  • IP telephony services The engineering of IP telephony services is essentially based on adequate sizing (including oversizing) to respond to requests for access to the service by customers who have subscribed to the service. They also rely on load sharing mechanisms to limit the risk of overload. However, experience has shown that these engineering choices, while suitable for nominal operational operation, are much less suitable for responding to sudden load peaks caused by exceptional events or behavior. unplanned element of service (e.g. partial software failure that results in random session loss).
  • a simple practice implemented today consists of informing customers of the presence of an overload situation in the process of being resolved. This can be done by sending, for example, an error code during an attempt to set up a call, for example according to the SIP protocol, or by real-time communication for the Web or WebRTC (or "Web Real Time Communication”.
  • This error code specifies the problem encountered.
  • the RFC 3261 document defines the "503" response code which must be transmitted by a service element in an overload situation to any client equipment or user agent UA (for "User Agent", in English) who requested this item.
  • Sending a SIP error message with this code means that the requested service element is unable to process the request following a temporary overload or a maintenance operation.
  • the service element in question may on this occasion indicate a period after which the client can make a new attempt (thanks to the "Retry-After" header).
  • a UA client receiving such a response code is expected to solicit another element of the service to fulfill its request, at least until the expiration of the "Retry-After” time (if indicated) and if the possibility of contacting another element of service is offered to him.
  • a procedure for determining such a time limit is difficult to establish. The implementation of such a procedure by the congested service element even risks aggravating the situation and keeping it in a state of permanent overload.
  • FIG. 1 shows an exchange of messages which takes place between an agent UA1 of the user and a service element PS, of the relay element type (or “proxy server”).
  • UA1 sends an INVITE type request to establish a call to PS.
  • PS Public Switched Telephone Network
  • PS Public Switched Telephone Network
  • PS Public Switched Telephone Network
  • Another known practice consists of sending congestion or overload notifications in SIP messages of the OPTIONS or NOTIFY type.
  • a common characteristic of these practices is the involvement of the congested service element in the resolution, notification and management of the overload situation.
  • both have a number of limitations.
  • An alternative consists in the addition by the elements of the service of an information field dedicated to the processing of congestion/overload phenomena.
  • the objective of this alternative is to provide a better qualification of the state of congestion and to minimize the approximations of the mechanisms described previously. It is based on a dedicated SIP header, called "CONGESTION", which can be inserted into any SIP response.
  • CONGESTION a dedicated SIP header
  • RFC7339 defines different control methods and associated algorithms. It describes in particular how an overloaded service element can indicate to the other service elements which request it to reduce the number of messages that they send to it so that they regulate the incoming requests in the event of overload. To do this, SIP parameters dedicated to load management and called “oc” (for "overload control”, in English), “oc-algo”, “oc-validity”, and “oc-seq” have been defined to include various information to characterize the rate and conditions of the overload.
  • oc for "overload control", in English
  • oc-algo for "oc-validity"
  • oc-seq have been defined to include various information to characterize the rate and conditions of the overload
  • elements other than the service platform involved in the implementation of the service suffer failures or encounter anomalies.
  • Such elements are, for example, border elements which relay messages for establishing application sessions between the user terminals and the service platform. These sessions are supported by service access networks through which user agents transmit service access requests, or interconnecting elements to other networks (e.g., PSTN interconnect or PLMN (Public Land Mobile Network).
  • PSTN interconnect or PLMN (Public Land Mobile Network).
  • PLMN Public Land Mobile Network
  • the invention proposes a mechanism making it possible to manage such a situation.
  • the invention meets this need by proposing a method for controlling access by at least one client equipment to an application service in a telecommunications network, said at least one client equipment being configured to access said application service, said method comprising :
  • the invention proposes a completely new and inventive approach to the management of a situation of overload or failure suffered by a system for implementing an application service in a telecommunications network. It consists of observing the operation of the service equipment of this system by collecting information relating to message processing events exchanged during access to this service at the level of this equipment, and, in the event of an anomaly detected with to one or more given service execution criteria, to decide on one or more control actions for the processing of at least one request for access to the service by said client equipment.
  • the control action has the effect of modifying an initial network configuration made when the client equipment is started.
  • it comprises for example one or more parameters for controlling the processing of a request for access to the service by the client equipment.
  • the invention applies to client equipment already configured to access the service and which already has access to it.
  • the mechanism for controlling the processing of a request for access to the application service by the client equipment according to the invention therefore differs from an initial configuration procedure of a client equipment intended to enable it to access the service.
  • processing anomalies that could induce a crisis/overload situation and impact the proper execution of the service as defined by the said criteria are managed in anticipation, at the source of requests for access to the service and outside the system, without impacting the equipment of the service core (or service platform).
  • execution criteria generic to the various services and/or specific to the service considered are defined and taken into account, and used to detect processing anomalies such as deviations from nominal operating conditions, which makes it possible to make a relevant decision on the most appropriate control action(s).
  • control actions are intended for the client equipment themselves so as to act as close as possible to the source of the requests for access to the service while minimizing the impact on the operation of the heart of the system.
  • This makes it possible to modify the way in which they process a service access request or an application session establishment message and offers many more adjustment possibilities than a simple random filtering of traffic at the entrance to the service platform, as proposed by the prior art.
  • the invention makes it possible to adapt the control carried out on the client equipment.
  • control action includes a configuration parameter of the client equipment so that the latter modifies its initial configuration.
  • the invention relies on known signaling mechanisms already used for providing the service, without requiring any particular extension.
  • a network equipment configuration management protocol such as NETCONF or RESTCONF can be used.
  • NETCONF network equipment configuration management protocol
  • RESTCONF RESTCONF
  • a protocol relies on the XML language to code the configuration data as well as the messages of the protocol.
  • a data modeling language such as YANG can be used, by defining a dedicated YANG module.
  • the invention applies to any type of application service, but it is particularly advantageous in the case of a telephony service over IP, in particular when it is faced with a situation of the “Flash Crowds” type.
  • said method comprises the prior learning of a classification model of a system for automatically detecting said processing anomaly from a learning set comprising processing events previously labeled with the aid of at least two classes comprising an anomaly presence class and an anomaly absence class and said detection of an anomaly is carried out by said system from the information of processing events obtained for one or more service equipment involved in the implementation of the service considered, said system producing as output one of the at least two classes.
  • such a system implements a classification model determined using artificial intelligence techniques such as machine learning to collect and classify the observed data and an algorithm (such as reinforcement learning) to assist decision-making relating to the handling of the crisis situation.
  • artificial intelligence techniques such as machine learning to collect and classify the observed data
  • algorithm such as reinforcement learning
  • One advantage is to determine an optimal operating situation of a service equipment item or of a set of service equipment items to render the service considered.
  • said control action belongs to a group comprising at least:
  • a control action of a replacement number of the telephone number associated with the service requested by said client equipment - an action of controlling a priority of the service, comprising the configuration of priority levels assigned to the requested services and to the other services which said client equipment can access;
  • One advantage is that the adjustment of the configuration of the service equipment and/or of the client equipment proposed by the invention makes it possible to regulate, redirect, or even prioritize the traffic according to the service requested.
  • said control action comprises configuring at least one telephone number, called an alias number, to replace a telephone number. telephone associated with the service.
  • an alias number makes it possible to access the switchboard via another network route.
  • the objective is for the service to be provided for all access requests received by the system.
  • An advantage of the invention is to allow the configuration of another telephone number through which the emergency center, although saturated on its main telephone number, can still be reached. This configuration is transparent for the user who can continue to dial the usual telephone number and does not even realize that his request has been redirected.
  • the invention thus proposes a reliable solution for managing an overload peak at the level of an application service, in particular a public safety call center (for "Public Safety Answering Point", in English), without requiring a user in a state of extreme stress to consult a social network to find out about an alternative telephone number set up by the service operator, for example.
  • a public safety call center for "Public Safety Answering Point", in English
  • said control action comprises the automatic programming of an announcement server of a replacement telephone number of a destination telephone number.
  • a destination telephone number e.g. associated with the switchboard, an emergency centre, an international call
  • the programming server announces to the user the replacement number to dial.
  • said at least one service execution criterion comprises a telephone communication establishment failure rate equal to zero and a telephone communication establishment delay less than a predetermined threshold.
  • the invention also relates to a device for controlling access by at least one client equipment to an application service in a telecommunications network, said at least one client equipment being configured to access said application service, said device being configured to implement work :
  • said device configured to implement the steps of the access control method as described previously.
  • said device is integrated into a control equipment of at least one service equipment involved in the implementation of an application service in a telecommunications network.
  • control equipment is included in a system for implementing an application service in a telecommunications network, said system comprising a plurality of service equipment involved in the implementation of said service.
  • the system, the control equipment and the control device have at least the same advantages as those conferred by the aforementioned control method.
  • the invention also relates to a method for processing a control message for access to an application service involving at least one service device in a telecommunications network, said method being executed by a client device configured to access said application service, said method comprising:
  • control message comprising at least one control action of a processing of at least one request for access to said service by said client equipment
  • control equipment acts on the client equipment so as to adjust the way in which it processes the requests for access to the application service. It thus intervenes at the source so as to correct without delay the operating anomalies observed at the level of one or more service equipment constituting the system for implementing the application service.
  • the execution of the action includes:
  • the client equipment performs this replacement in the “Request URI” field of the “To” header of the service access request.
  • An advantage of making this change at the client device level is that the headers are not yet encrypted. Indeed, commonly, service equipment uses protocols for encrypting certain message headers or certain information fields contained in these headers.
  • the invention also relates to a device for processing a message controlling access to an application service involving at least one service device in a telecommunications network, said device being intended to be executed by a client device configured to access said application service, said device being configured to implement:
  • control message coming from a control equipment of said telecommunications network, said control message comprising at least one control action of a processing of at least one request for access to said service by said customer equipment, and
  • said device configured to implement the steps of the method for processing an access control message as described previously.
  • the system, the client equipment and the processing device have at least the same advantages as those conferred by the aforementioned control method.
  • the invention also relates to computer program products comprising program code instructions for implementing the methods as described previously, when they are executed by a processor.
  • a program may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in partially compiled form, or in any other desirable form.
  • the invention also relates to a recording medium readable by a computer on which is recorded a computer program comprising program code instructions for the execution of the steps of the methods according to the invention as described above.
  • Such recording medium can be any entity or device capable of storing the program.
  • the medium may include a storage medium, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording medium, for example a mobile medium (memory card) or a hard drive or SSD.
  • such a recording medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means, so that the program computer it contains is executable remotely.
  • the program according to the invention can in particular be downloaded on a network, for example the Internet network.
  • the recording medium may be an integrated circuit in which the programs are incorporated, the circuit being adapted to execute or to be used in the execution of the aforementioned methods.
  • the present technique is implemented by means of software and/or hardware components.
  • the term "module" may correspond in this document to a software component, a hardware component or a set of hardware and software components.
  • a software component corresponds to one or more computer programs, one or more sub-programs of a program, or more generally to any element of a program or software capable of implementing a function or a set of functions, as described below for the module concerned.
  • Such a software component is executed by a data processor of a physical entity (terminal, server, gateway, set-top-box, router, etc.) and is likely to access the hardware resources of this physical entity (memories, recording media, communication bus, electronic input/output cards, user interfaces, etc.).
  • resources means all sets of hardware and/or software elements supporting a function or a service, whether unitary or combined.
  • FIG. 1 figure 1 (already described) schematically illustrates an example of notification of an overload state by a service equipment involved in the implementation of an application service to a client equipment which wishes to access in the service, according to the prior art;
  • FIG. 2 schematically illustrates an example of architecture of a system for implementing an application service in a telecommunications network accessed by client equipment according to one embodiment of the invention ;
  • FIG. 3 details an example of the structure of control equipment of such a system and of client equipment according to one embodiment of the invention
  • FIG. 4 schematically illustrates an example of architecture of a system for implementing an application service according to another embodiment of the invention
  • FIG. 5 describes in the form of a flowchart the steps of a method for controlling access to an application service implemented in a telecommunications network, according to an exemplary embodiment of the invention ;
  • FIG. 6 describes in the form of a flowchart the steps of a method for processing a message for controlling access to an application service implemented in a telecommunications network, according to an example of carrying out the invention
  • FIG. 7 schematically illustrates an example of nominal operation of the application service
  • FIG. 9 schematically illustrates an example of control performed on client equipment according to one embodiment of the invention
  • FIG. 10 describes an example of the hardware structure of a device for controlling access to an application service according to the invention.
  • FIG U Figure 11 describes an example of hardware structure of a device for processing a control message according to the invention.
  • the general principle of the invention is based on the control of access by at least one client equipment to an application service implemented by a system comprising a plurality of service equipment in a telecommunications network.
  • This control is based on obtaining event information relating to the processing by at least one of the service equipment of the system, of messages exchanged within the framework of the implementation of said application service, the detection, from information obtained, of a processing anomaly by said service equipment with respect to at least one given service execution criterion, and the transmission of at least one control message comprising at least one control action of a processing of said at least one request for access to said service by said client equipment.
  • the invention applies to any type of application service which is accessed by establishing an application session between a requesting client device and such a system, for example an audio, video or instant messaging IM call.
  • equipment or service element will designate without distinction any element requested for the provision of a service (and in particular for the establishment of an application session).
  • Such an item of equipment or element can be involved in the exchange of control messages (for example using the SIP protocol), the exchange of payload data (for example using the RTP protocol), or even both.
  • the implementation of a service may involve one or more service elements.
  • the order of invocation of service elements can be static and service-specific (e.g. conforming to the IMS architecture) or be established on demand (e.g. achieved using a chaining technique). service).
  • a service element can be implemented in software and/or hardware.
  • One or more service elements can be embedded in the same physical equipment.
  • FIG. 2 schematically illustrates an example of the architecture of a system S for the implementation of an IP telephony service deployed by a service provider in a telecommunications network RT, according to an embodiment of the invention.
  • a client device or user agent UA or “User Agent”, in English
  • This user agent can also be embedded in a CPE (or “Customer Premises Equipment”) user terminal. It is typically any equipment installed at or carried by the user to create, route or terminate a communication between the user and the system of the operator or the service provider, for example a residential or professional gateway (or “gateway", in English) or a smart phone (or “smartphone", in English).
  • the UA can also be integrated into dedicated equipment.
  • the latter generally embeds a relay equipment (or “proxy server”, in English), not represented.
  • the client equipment UA, CPE accesses the network RT via an access network AN, for example of the cellular radio, fiber or ADSL type.
  • an access network AN for example of the cellular radio, fiber or ADSL type.
  • System S in Figure 2 includes the following elements:
  • SBE Session Border Element
  • DBE Data Border Element
  • SBE element is responsible for processing signaling messages
  • DBE element is responsible for processing media streams.
  • P-CSCF Proxy-call/session control function
  • BGF Border Gateway Function
  • SBC Session Border Controller
  • these SBE/DBE elements When these SBE/DBE elements are directly connected to the UAs, they are the contact points of the system implementing the service. In this configuration, the UAs have no visibility of the internal structure of a PFC core platform for implementing the service. These elements can also be used for interconnection requirements with other domains (identified by “RLM# r” in FIG. 2, with r an integer between 2 and 5). These areas can be other IP telephony domains, another telecommunications network such as the PSTN network or a mobile network, etc.
  • the PFC core platform composed of elements called CF (“Core Functions”) located in the CN core network, not shown.
  • CF Core Functions
  • the invention can be used generally independently of the architecture of the underlying service, which is for example an IMS (or “IP Multimedia Subsystem”) architecture or any other future architecture. No assumption is made as to the nature of the CFs, their number, or the invocation sequencing of these CFs for the establishment of an application session.
  • the system S also comprises a control equipment, or controller CTR, configured to control the service equipment and the client equipment UA, CPE.
  • a control equipment or controller CTR, configured to control the service equipment and the client equipment UA, CPE.
  • This is for example an SDN (or “Software-Defined Networking”) controller, as illustrated in Figure 3. It is responsible for the management and configuration of service elements.
  • the NETCONF or RESTCONF protocols are used as an example to manage and configure these elements, but other protocols can be used.
  • the control equipment CTR comprises a device 100 for controlling access by at least one client equipment to an application service in a telecommunications network, said at least one client equipment being configured to access said application service. It is configured to obtain event information relating to the processing by at least one service equipment involved in the implementation of the application service, of messages exchanged during at least one access to said application service, to detect, from the information obtained, a processing anomaly by at least one said service equipment with respect to at least one given service execution criterion; and transmitting at least one control message comprising at least one control action for the processing of at least one access request to said service by said client equipment.
  • the device 100 thus implements the method for controlling access to the service according to the invention which will be detailed below in relation to FIG. 5.
  • the device 100 can be independent of the control equipment, but connected to the latter by any link, wired or not.
  • the device 100 can be integrated with other equipment of the telecommunications network, for example a service equipment.
  • controllers can be deployed, as shown in Figure 4.
  • a first controller is responsible for the service provider's service elements, while a second controller is used for managing client equipment (UA, CPE ).
  • client equipment U, CPE
  • the client equipment UA, CPE comprises a device 200 for processing a control message for access to the application service involving at least one service equipment in the telecommunications network RT.
  • This device 200 is configured to receive a control message coming from the control equipment of the telecommunications network, said control message comprising at least one action for controlling processing of at least one request for access to said service by said client equipment, and performing the control action when processing said request.
  • the device 200 thus implements the method for processing an access control message to the application service according to the invention which will be detailed below in relation to FIG. 6.
  • FIG. 5 in the form of a flowchart, an example of implementation of a method for controlling access to an application service by at least one client equipment, according to an embodiment of the invention.
  • this method is implemented by the aforementioned device 100.
  • event information relating to the processing by at least one service equipment involved in an implementation of the application service, of messages exchanged during at least one access to said application service is obtained.
  • control device 100 receives this information (directly or indirectly) from the service equipment that it controls. They reflect the status of such service equipment.
  • a memory M1 structured or not.
  • a memory is organized in the form of a database and indexed by an identifier of the service equipment concerned by the information or information received.
  • the format of the notifications comprising this information is defined using a data modeling language.
  • a data modeling language for modeling data which can be conveyed for example in messages of the NETCONF or RESTCONF protocols.
  • It is a modular language representing data structures in an XML tree format.
  • the data modeling language comes with a number of built-in data types. Other application-specific data types can be derived from the built-in data types.
  • the data types of the information received from the service equipment by the control equipment can be specified in a dedicated Yang module. This processing event information may or may not be solicited.
  • the solicited responses are responses to explicit requests such as GET requests sent by the control device 100, whereas the unsolicited responses are typically notifications sent by a service equipment without a specific request having been sent.
  • NETCONF/RESTCONF notifications are examples of unsolicited responses.
  • notifications can be generated based on filters maintained locally by this service equipment. These notifications may consist of informing the controller:
  • a failure rate for establishing application sessions to a specific destination or service e.g., a server identified by an IP address, a website, an E.164 number, or a SIP alias
  • a specific destination or service e.g., a server identified by an IP address, a website, an E.164 number, or a SIP alias
  • a response time i.e., time between the time of sending a request and the time of receiving a corresponding response
  • a processing anomaly by at least one said service equipment item is detected on the basis of the information obtained and with respect to at least one given service execution criterion.
  • anomalies at the level of the service can also be detected in addition to anomalies at the level of a service equipment.
  • a first criterion can be a call session establishment failure rate equal to zero and a call establishment time of less than one minute, for example. .
  • This or these given execution criteria contribute to defining a nominal operation of the service and also of the service equipment involved and the detection of an anomaly according to the invention comprises the detection of at least one operating deviation of said at least one equipment service compared to nominal operation.
  • the method comprises learning a classification model of an automatic decision system from a learning set comprising processing event information previously labeled using at least two classes comprising an anomaly presence class and an anomaly absence class and the detection is carried out by the decision system which takes as input the processing event information obtained for one or more service equipment involved in the setting implementation of the service considered and outputs a decision of detected anomaly or no anomaly detected.
  • learning implements machine learning techniques ML (or “Machine Learning”) and feeds the calculation logic of the device 100 and determines the classification model.
  • the detection of anomalies can be done by service equipment, for the plurality of service equipment involved in the implementation of the service considered, for the service equipment associated with the same global PFC core platform with several services , etc.
  • an anomaly decision can be taken on the basis of an accumulation of processing anomalies detected at the level of different service equipment.
  • a decision to order the execution of at least one action for controlling a processing of at least one request for access to said service by at least one client equipment UA, CPE is taken.
  • control device 100 decides to proceed:
  • This number can optionally be defined by range of telephone numbers, typically a larger number can be defined for emergency calls than for other application services;
  • Announcement Server an announcement server which makes it possible to announce replacement numbers when the UA calls the abbreviated number of the service
  • control actions are intended for client equipment which requests access to the application service, but that they can also be ordered from service equipment, in particular edge equipment (SBE). This is particularly the case for the action of prioritizing certain telephone numbers by setting up dedicated filters.
  • SBE edge equipment
  • control device 100 can decide, in order to allow the restarting of an application service without the latter being collapsed by the traffic peaks immediately after the restart, to act on the spreading out of the processing of requests establishment of application sessions sent by a UA and/or on the establishment of the relay by edge equipment an SBE/DBE and/or on the redirection of requests to an announcement server, etc.
  • At least one control message comprising at least one control action is transmitted to one or more client equipments UA, CPE.
  • FIG. 6 there is now presented, in relation to FIG. 6, in the form of a flowchart, an example of implementation of a method for processing a message for controlling access to an application service involving at least one service equipment in a telecommunications network.
  • this method is implemented by the aforementioned device 200, integrated into a client equipment UA, CPE configured to access said application service.
  • a control message MC is received from a control equipment CTR of said telecommunications network, said control message comprising at least one control action AC of a processing of at least one request for access to said service by said customer equipment. For example, it saves the control action received in a memory M2.
  • the device 200 modifies its initial configuration to take into account the control action received.
  • the device 200 saves this number alias in a memory and modifies its procedure so as to systematically replace the telephone number associated with the service with this alias.
  • the actions are for example defined using regular expressions (“regexp”).
  • this action of the UA is transparent for the user and it is immediately executed. Having this action performed by the UA is particularly advantageous in the case of the use of encryption protocols (and the "sips" URI) by the service equipment, because it takes place at the source, therefore before the encryption is carried out ).
  • a nominal configuration for a given destination for example an emergency call center located in a destination domain, for example the IP domain RLM#5 and associated to a telephone number, for example the abbreviated number 18.
  • a destination domain RLM#5 can also be reached with another telephone number, called an alias.
  • a call sent by the client equipment UA, CPE is routed to the call center under nominal operating conditions. In other words, the application session is successfully established within a period of less than a maximum authorized period.
  • FIG. 8 illustrates an example of failure to establish an application session requested by the client equipment UA, CPE. It is assumed that the access control method according to the invention implemented by the control equipment CTR has detected an operating failure of an edge equipment SDE5/DBE5, more precisely of interconnection between the core network CN and the RLM#5 IP domain. This failure impacts the implementation of one or more application services, whose call management center is located in this IP domain.
  • control equipment transmits a control message to the client equipment UA, CPE.
  • This message includes a control action which consists of configuring a list of aliases associating an alias number with the telephone number of each of the services concerned.
  • the client equipment UA, CPE modifies its initial configuration so as to use this list to automatically rewrite the "Request URI" (and "To") field of any establishment request an application session to access one of these services, replacing the telephone number associated with the requested service with its alias.
  • the call can be routed successfully via the neighboring RLM#4 IP domain.
  • Said list of aliases can also be associated with a validity date beyond which it is automatically deleted from the memory of the UA, CPE unless a control action is received with a date update request. validity on another date, later or earlier depending on the speed with which the malfunction is corrected.
  • the processing control of an access to the service can also be carried out by the control equipment CTR at the level of the CPE of the user or of the edge equipment SBE1 located in the access network AN.
  • the controller configures the CPE or SBE1 with a list of aliases. This list is used by the edge equipment SBE1 to carry out the rewriting of the “Request URI” (and “To”) field of the request to establish an application session.
  • the emergency call can be successfully routed through the neighboring RLM#4 IP domain.
  • the redirection of all or part of the traffic to the requested destination as implemented according to the invention also makes it possible to reduce the processing load of the faulty service equipment and facilitates the conduct of maintenance operations such as a restart For example.
  • an electronic voting service Each voter is invited to submit his vote (on the occasion of a television program or an election, for example) by accessing a website.
  • the vote validation procedure is based on an acknowledgment mechanism which consists of sending the voter a message confirming that the vote has been taken into account (and that it complies with the electoral rule, if applicable).
  • the submission of such a vote may be subject to strong time constraints, liable to cause a traffic overload at the level of several network resources. These include those of the network used to route the votes, those of the server equipment intended to receive and count the votes, those of the acknowledgment system mentioned above, or any combination of these resources. .
  • the invention is based on processing devices 200 embedded in client equipment, user agents UA or CPE or even in other equipment typically located at the periphery of the network, such as routers of the network of access, core network routers, voting site access equipment or server equipment in charge of processing the votes.
  • These devices 200 are configured to receive control actions decided and transmitted by a control device 100 as previously described, for example embedded in a control equipment CTR of the network. Such control actions are aimed at smoothing the flow of traffic.
  • a traffic conditioning function based for example on a token bucket algorithm (as long as there are tokens in the bucket, the traffic can be routed, when there are no more tokens , the traffic can be stored in a queue (for the time that the volume of traffic falls below the 70% threshold) or else be redirected on another uncongested path but allowing the vote processing site to be reached ),
  • voting traffic is initially tagged with DSCP AF12 (meaning the traffic is stored in a particular queue) and then re-tagged as AF11 or Best Effort (DSCP set to zero) , when traffic has reached the 70% threshold cited as an example,
  • the policy for assigning metrics to interfaces is generally a least cost policy which takes account of the bandwidth associated with each interface. For example, a 10 Gbit/s interface is assigned a metric of 1 while a 100 Mbit/s interface is assigned a metric of 100.
  • the metric of the corresponding interfaces could be increased, for example, to 200.
  • the dynamic routing protocol will select paths at the lowest cost, for example, a path passing through the interface at 100 Mbit/s,
  • control actions make it possible to prevent any risk of overloading the server equipment configured to receive the votes, in particular.
  • These control actions are executed by certain network elements (even CPE client devices) according to information that can be conveyed in messages conforming to the PCEP protocol (or “Path Computation Element Protocol”) for the establishment of new routes, for example.
  • the invention thus makes it possible to anticipate a context of overload and to streamline both the vote submission messages and the acknowledgment messages.
  • a device 100 for controlling access by at least one client equipment to an application service in a telecommunications network said at least one client equipment being configured to access said application service
  • said device comprising a module for obtaining event information relating to the processing by at least one service equipment involved in an implementation of the application service, of messages exchanged during at least one access to said application service, a module for detecting, from the information obtained, a processing anomaly by at least one said service equipment with respect to at least one given service execution criterion; and a module for transmitting at least one control message comprising at least one action for controlling processing of at least one request for access to said service by said client equipment.
  • module can correspond both to a software component and to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or sub-programs or in a more general to any element of a program capable of implementing a function or a set of functions.
  • such a device 100 comprises a random access memory 103 (for example a RAM memory), a processing unit 102 equipped for example with a processor, and controlled by a computer program Pgl, representative of the modules for obtaining, detection and transmission, stored in a read only memory 101 (for example a ROM memory or a hard disk).
  • a read only memory 101 for example a ROM memory or a hard disk.
  • the code instructions of the computer program are for example loaded into the random access memory 103 before being executed by the processor of the processing unit 102.
  • the random access memory 103 can also contain the information of event obtained.
  • FIG. 10 only illustrates one particular way, among several possible, of making the device 100 so that it performs the steps of the method for controlling access to the service as detailed above, in relation to FIG. 5, in its various embodiments.
  • a reprogrammable calculation machine a PC computer, a DSP processor or a microcontroller
  • a program comprising a sequence of instructions
  • a dedicated calculation machine for example a set of logic gates such as an FPGA or an ASIC, or any other hardware module
  • the corresponding program (that is to say the sequence of instructions) could be stored in a removable storage medium (such as for example an SD card , a USB key, a CD-ROM or a DVD-ROM) or not, this storage medium being partially or totally readable by a computer or a processor.
  • a removable storage medium such as for example an SD card , a USB key, a CD-ROM or a DVD-ROM
  • a device 200 for processing an access control message to an application service involving at least one service equipment item in a telecommunications network comprising a module for receiving a control message from a control device of said telecommunications network, said control message comprising at least one control action for processing at least one access request to said service by said client equipment, and a module for executing the control action during the processing of said request.
  • module can correspond both to a software component and to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or sub-programs or in a more general to any element of a program capable of implementing a function or a set of functions.
  • such a device 200 comprises a random access memory 203 (for example, a RAM memory), a processing unit 202 equipped for example with a processor, and controlled by a computer program Pg2, representative of the reception modules and execution, stored in a read only memory 201 (for example, a ROM memory or a hard disk).
  • a random access memory 203 for example, a RAM memory
  • a processing unit 202 equipped for example with a processor
  • a computer program Pg2 representative of the reception modules and execution
  • a read only memory 201 for example, a ROM memory or a hard disk.
  • the code instructions of the computer program are for example loaded into the random access memory 203 before being executed by the processor of the processing unit 202.
  • the random access memory 203 can also contain the action of control received in the control message.
  • FIG. 11 only illustrates one particular way, among several possible, of making the device 200 so that it performs the steps of the method for processing a message for controlling access to an application service as detailed above, in relation to FIG. 6, and in its various embodiments. Indeed, these steps can be carried out either on a reprogrammable calculation machine (a PC computer, a DSP processor or a microcontroller) running a program comprising a sequence of instructions, or on a dedicated calculation machine (for example a set of logic gates such as an FPGA or an ASIC, or any other hardware module).
  • a reprogrammable calculation machine a PC computer, a DSP processor or a microcontroller
  • a dedicated calculation machine for example a set of logic gates such as an FPGA or an ASIC, or any other hardware module.
  • the corresponding program (that is to say the sequence of instructions) can be stored in a removable storage medium (such as for example an SD card , a USB key, a CD-ROM or a DVD-ROM) or not, this storage medium being partially or totally readable by a computer or a processor.
  • a removable storage medium such as for example an SD card , a USB key, a CD-ROM or a DVD-ROM

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • General Business, Economics & Management (AREA)
  • Business, Economics & Management (AREA)
  • Software Systems (AREA)
  • Medical Informatics (AREA)
  • Evolutionary Computation (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Artificial Intelligence (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Procédé de contrôle d'un accès à un service applicatif mis en œuvre dans un réseau de télécommunications, procédé de traitement d'un message de contrôle d'un accès audit service applicatif, dispositifs, équipement de contrôle, équipement client, système et programmes d'ordinateur correspondants. L'invention concerne un procédé de contrôle d'un accès par au moins un équipement client à un service applicatif dans un réseau de télécommunications, ledit au moins un équipement client étant configuré pour accéder audit service applicatif, ledit procédé comprenant : ‐ l'obtention (50) d'informations d'événements relatifs au traitement par au moins un équipement de service impliqué dans une mise en œuvre du service applicatif, de messages échangés lors d'au moins un accès audit service applicatif; ‐ la détection (51), à partir des informations obtenues, d'une anomalie de traitement par au moins undit équipement de service par rapport à au moins un critère donné d'exécution du service; et ‐ la transmission (53) d'au moins un message de contrôle comprenant au moins une action de contrôle d'un traitement d'au moins une demande d'accès audit service par ledit équipement client.

Description

DESCRIPTION
TITRE : Procédé de contrôle d'un accès à un service applicatif mis en œuvre dans un réseau de télécommunications, procédé de traitement d'un message de contrôle d'un accès audit service applicatif, dispositifs, équipement de contrôle, équipement client, système et programmes d'ordinateur correspondants.
1. Domaine de l'invention
L'invention se situe dans le domaine des télécommunications, et notamment dans celui de la téléphonie sur IP.
En particulier, l'invention concerne le contrôle de l'accès par des équipements clients à un service applicatif mis en œuvre dans un réseau de télécommunications.
Elle s'applique notamment mais non exclusivement à un service de voix sur IP.
2. Art antérieur et ses inconvénients
La Téléphonie sur IP, souvent désignée par le sigle VoIP (pour « Voice over IP », en anglais), a pris ces dernières années une place prépondérante au point que tous les fournisseurs de services proposent de telles offres à leurs clients. Ces offres de service reposent sur le protocole IP (pour « Internet Protocol », en anglais) et donc la commutation de paquets de données. Elles diffèrent donc dans leur conception des services de téléphonie traditionnelle qui eux reposent sur le principe de la commutation de circuits.
Néanmoins, la Téléphonie sur IP se doit de satisfaire les besoins des clients, notamment du point de vue de la qualité et de la disponibilité du service qui doivent être au moins équivalentes à celles fournies par les offres de téléphonie traditionnelle et reposant sur le réseau RTC (Réseau Téléphonique Commuté). En particulier, la qualité de service, la robustesse, la haute disponibilité et la résistance aux pannes sont des facteurs déterminants pour les utilisateurs de services téléphoniques, lesquels sont par nature des services d’échange de flux en temps réel. Les opérateurs de télécommunications, qu'on appellera aussi fournisseurs de services, doivent particulièrement éviter les phénomènes de surcharge des éléments composant le service et anticiper les anomalies qui peuvent perturber le service tel que perçu par les clients.
On désigne ici par surcharge l’incapacité du service, ou de certains éléments de ce service, à traiter une demande d'établissement d'une session applicative, par exemple d'un appel audio, vidéo ou de messagerie instantanée IM (ou « Instant Messaging », en anglais), souvent à cause d’une insuffisance de ressources pour traiter ladite demande. La gestion des surcharges est d'autant plus délicate que le phénomène a tendance à s'entretenir lui-même. En effet, le problème de surcharge est de nature à progressivement affecter les éléments du service impliqués dans la procédure d'établissement d'appels, et qui tentent toujours d’écouler le trafic : ces éléments se trouvent donc à leur tour affectés par une surcharge de trafic.
Lorsqu'un élément de service est dans un état de surcharge, une partie de ses ressources est alors utilisée pour envoyer des messages d’erreur, d’alerte, etc., ce qui a pour effet de réduire d’autant plus les ressources disponibles pour résoudre le problème de surcharge. Dans le cas d'un service de Téléphonie sur IP, un facteur dégradant supplémentaire tient à la réémission des requêtes qui est souvent mise en oeuvre, car elle est destinée à pallier d'éventuelles erreurs du transport IP. Par exemple, le document RFC 3261 définissant le protocole de signalisation SIP (pour « Session Initiation Protocol », en anglais) utilisé dans la procédure d'établissement d'appels, décrit une procédure de retransmission pour les messages de type INVITE et les messages non-INVITE. A titre d'exemple, pour les messages de type INVITE, un temporisateur (ou « timer », en anglais) de retransmission Tl est défini. La procédure est reproduite à chaque intervalle correspondant à un double de Tl. Au bout de 7 tentatives, l'équipement client SIP cesse d'exécuter la procédure de retransmission.
Des règles d’ingénierie permettent aux opérateurs de télécommunications d’éviter ce genre de situation de crise dans des conditions normales de fonctionnement, en dimensionnant de manière adéquate leur service, ou en mettant par exemple en oeuvre des mécanismes de partage de charge (ou « load balancing » en anglais) entre les éléments de service constituant le service. Cependant, ces mécanismes s'avèrent la plupart du temps insuffisants pour traiter de nombreuses sessions (par ex., appels) liées à des évènements exceptionnels (tels que, par exemple, l'échange de vœux par SMS à l'occasion de la nouvelle année, une catastrophe naturelle, une émission télévisée reposant sur le vote des téléspectateurs, une coupure d'électricité, une attaque terroriste, etc.) ou bien encore suite à une panne (affectant les équipements clients ou les éléments qui constituent la plateforme de service). Ainsi, c’est surtout dans la gestion de pics de charge (ou « burst », en anglais) que les services conversationnels actuels connaissent des faiblesses. Typiquement, il arrive que les services conversationnels sur IP connaissent de sérieuses défaillances, qui sont amplifiées par la surcharge générée au moment du rétablissement du service et qui retardent ainsi un rétablissement du service. De telles circonstances rendent souvent la reprise du service ingérable au point parfois de provoquer des situations de crise que ne maîtrise pas l'opérateur de télécommunications. A cet égard, la survenue d'une telle crise peut ne pas être prise en compte lors du dimensionnement du service et du réseau sous-jacent. Un des phénomènes de surcharge les moins faciles à appréhender est celui du phénomène de « pics de charge soudains » (ou "Flash Crowds", en anglais). Il se produit notamment lorsque des utilisateurs en nombre trop important tentent simultanément d'établir un appel ou de se connecter à un site Internet, les éléments du service n'ayant pas été dimensionnés pour absorber simultanément cet afflux de trafic (en anglais, « burst »). Par exemple, le dimensionnement des réseaux de téléphonie repose notamment sur une distribution statistique des appels, régie par les lois d'Erlang en particulier. Or ce type de dimensionnement ne permet pas de déployer un service pouvant faire face à des surcharges occasionnelles de trafic. Dans le cas d'un phénomène de type « Flash Crowds », l'origine d'un goulot d'étranglement au niveau d'une plateforme de service peut être liée à au moins deux situations particulières :
(1) un afflux important de sessions vers une destination particulière (par ex. un numéro particulier comme un numéro d'urgence ou une zone géographique particulière) ou
(2) un afflux important provenant d’une région donnée (en termes de raccordement au service) ou encore une combinatoire des deux situations, dans le contexte de catastrophes naturelles, par exemple.
Ce genre de situation peut générer un grand nombre de sessions passées vers le numéro en question sur une période relativement courte, ce qui provoque une congestion qui dégrade la qualité du service rendu telle que perçue par les utilisateurs.
Un autre exemple bien connu est la saturation quasi systématique des réseaux de téléphonie au moment des fêtes de fin d’année, notamment lors du réveillon du Nouvel An. Là encore, le service de l’opérateur est souvent dimensionné pour pouvoir gérer un nombre important d'appels clients dans des conditions de fonctionnement nominal, c'est-à-dire telles que prévues dans un cahier des charges ou dans un contrat spécifiant des conditions générales d'utilisation (CGU) du service, établi avec les clients. En revanche, lorsque surviennent des pics de charge, le système qui met en oeuvre le service est généralement incapable de faire face à la surcharge d'appels, ce qui peut conduire à une forte dégradation du service, voire à son indisponibilité. Un tel afflux de demandes d'établissement d'appels est également de nature à retarder le retour à une situation normale à cause de la persistance dans le temps de cet afflux de trafic.
Les diverses défaillances qui ont affecté les offres de Téléphonie sur IP ces dernières années ont démontré que bien souvent le système qui met en oeuvre le service rencontre de grandes difficultés à absorber une surcharge exceptionnelle.
Les ingénieries de services de téléphonie sur IP reposent essentiellement sur un dimensionnement adéquat (incluant un surdimensionnement) pour répondre aux demandes d'accès au service par les clients ayant souscrit au service. Elles s'appuient aussi sur des mécanismes de partage de charge pour limiter le risque de surcharge. Cependant, l'expérience a prouvé que ces choix d'ingénierie, s'ils sont adaptés dans le cadre d’un fonctionnement opérationnel nominal, le sont beaucoup moins pour répondre à des pics de charge soudains et provoqués par des événements exceptionnels ou un comportement non-prévu d'un élément de service (par ex. défaillance logicielle partielle qui induit une perte de session aléatoire).
En relation avec la figure 1, une pratique simple et mise en oeuvre aujourd'hui consiste à informer les clients de la présence d'une situation de surcharge en cours de résolution. Cela peut se faire via l'envoi par exemple d'un code d’erreur lors d'une tentative d'établissement d'appel par exemple selon le protocole SIP ou par une communication en temps réel pour le Web ou WebRTC (ou « Web Real Time Communication », en anglais). Ce code d'erreur précise le problème rencontré. Dans un environnement SIP par exemple, le document RFC 3261 définit le code de réponse "503" qui doit être transmis par un élément de service en situation de surcharge à tout équipement client ou agent de l'utilisateur UA (pour « User Agent », en anglais) ayant sollicité cet élément. L'envoi d'un message d'erreur SIP avec ce code signifie que l’élément de service sollicité n’est pas en mesure de traiter la requête suite à une surcharge temporaire ou une opération de maintenance. L’élément de service en question peut à cette occasion indiquer un délai à l'issue duquel le client peut effectuer une nouvelle tentative (grâce à l'en-tête "Retry-After"). Un client UA recevant un tel code de réponse est censé solliciter un autre élément du service pour satisfaire sa demande, au moins jusqu'à l'expiration du délai "Retry-After" (s’il est indiqué) et si la possibilité de contacter un autre élément de service lui est offerte. A cet égard, il convient de noter qu'une procédure de détermination d'un tel délai est difficile à établir. La mise en place d'une telle procédure par l'élément de service congestionné risque même d'aggraver la situation et de le maintenir en état de surcharge permanente.
L'exemple de la figure 1 montre un échange de messages qui intervient entre un agent UA1 de l'utilisateur et un élément de service PS, de type élément relais (ou « proxy server » en anglais). Ainsi, UA1 envoie une requête de type INVITE pour établir un appel vers PS. Ce dernier étant indisponible, il génère alors une réponse de type "503 Service Unavailable" pour notifier au client l'impossibilité d'accéder au service. Ceci suppose que la procédure SIP est en mesure de générer un tel message et que l'opérateur a la capacité de procéder au traitement associé en cas de surcharge.
Une autre pratique connue consiste à envoyer des notifications de congestion ou de surcharge dans des messages SIP de type OPTIONS ou NOTIFY.
Une caractéristique commune à ces pratiques est l'implication de l'élément du service congestionné dans la résolution, notification et gestion de la situation de surcharge. Elles présentent cependant l'une comme l'autre un certain nombre de limitations. Une alternative consiste en l'ajout par les éléments du service d'un champ d'information dédié au traitement des phénomènes de congestion/surcharge. L'objectif de cette alternative est de fournir une meilleure qualification de l'état de congestion et de minimiser les approximations des mécanismes décrits précédemment. Elle repose sur un en-tête SIP dédié, dénommé "CONGESTION", qui peut être inséré dans toute réponse SIP. Il permet notamment de caractériser le degré de congestion constaté (valeur allant de 0 à 4), le type de congestion (par ex. CPU, réseau), l'élément de service concerné ainsi qu'un délai au-delà duquel une nouvelle tentative pourra être effectuée. Cette alternative présente toutefois les mêmes inconvénients que l'utilisation du champ "Retry-After" car l'élément de service doit générer un message et exécuter une procédure pour déterminer (voire prédire, compte tenu des demandes présentes et futures) l'échéance de son retour à la normale (c.-à-d. fonctionnement nominal), ce qui n'est pas facilement réalisable lors des phénomènes de surcharge exceptionnels (par ex. crises ou événements importants).
Le document RFC7339 définit différentes méthodes de contrôle et algorithmes associés. Il décrit en particulier comment un élément du service surchargé peut indiquer aux autres éléments de service qui le sollicitent de réduire le nombre de messages qu'ils lui envoient pour qu'ils régulent les sollicitations entrantes en cas de surcharge. Pour ce faire, des paramètres SIP dédiés à la gestion de la charge et dénommés "oc" (pour « overload control », en anglais), "oc-algo, "oc-validity", et "oc-seq" ont été définis pour inclure diverses informations permettant de caractériser le taux et les conditions de la surcharge. Un avantage des méthodes décrites dans le document RFC7339 est de permettre une meilleure gestion des situations de surcharge que la méthode décrite dans le document RFC3261, mais elles ne permettent pas de garantir une éradication rapide du phénomène de surcharge ni de le prévoir. Au contraire, face à un problème de surcharge de type "Flash Crowds", l’élément de service subissant le pic de trafic doit déclencher tous les processus décrits dans le document RFC7339, ce qui augmente d’autant le nombre d'opérations qu'il a à effectuer, et contribue donc à l'aggravation de son état de surcharge. En conséquence, le temps nécessaire pour absorber l’afflux de trafic se trouve augmenté.
On connaît de la demande de brevet internationale publiée sous le numéro W02009/122071, un procédé de gestion préventive d'une situation de surcharge, qui vise à éviter qu’un pic de surcharge n’impacte la plateforme de service de sorte que le service devienne indisponible, par exemple un pic provoqué par un phénomène de type "Flash Crowds ». Ce procédé consiste à instaurer un filtrage des demandes d'accès au service, au niveau des équipements de bordure. Ce filtrage est piloté par la définition et la mesure préalables de seuils pertinents pour caractériser le début d'un phénomène de surcharge. Ces seuils sont définis par l’opérateur du service. Ils prennent en compte une limite maximale supportée par l'élément de service et un ratio par rapport à cette limite qui représente la valeur limite acceptée en situation opérationnelle. Un tel écrêtage du flux de demandes à traiter permet de protéger la plateforme de service et de s'assurer qu'elle soit toujours en mesure d’absorber le trafic qu’elle reçoit. En effet, contrairement aux autres pratiques susmentionnées, cette opération de filtrage permet de réguler les pics de trafic avant que ces pics n'affectent le fonctionnement de la plateforme de service.
Toutefois, il se peut que d'autres éléments que la plateforme de service impliqués dans la mise en oeuvre du service subissent des défaillances ou rencontrent des anomalies. De tels éléments sont, par exemple, des éléments de bordure qui relaient des messages d'établissement de sessions applicatives entre les terminaux utilisateurs et la plateforme de service. Ces sessions sont supportées par des réseaux d'accès au service par l'intermédiaire desquels les agents d'utilisateurs transmettent des demandes d'accès au service, ou des éléments d'interconnexion vers d'autres réseaux (p. ex., interconnexion RTC ou PLMN (« Public Land Mobile Network », en anglais)).
L'invention propose un mécanisme permettant de gérer une telle situation.
3. Présentation de l'invention
L'invention répond à ce besoin en proposant un procédé de contrôle d'un accès par au moins un équipement client à un service applicatif dans un réseau de télécommunications, ledit au moins un équipement client étant configuré pour accéder audit service applicatif, ledit procédé comprenant:
- l'obtention d'informations d'événements relatifs au traitement par au moins un équipement de service impliqué dans une mise en oeuvre du service applicatif, de messages échangés lors d'au moins un accès audit service applicatif;
- la détection, à partir des informations obtenues, d'une anomalie de traitement par au moins undit équipement de service par rapport à au moins un critère donné d'exécution du service; et
- la transmission audit équipement client d'au moins un message de contrôle comprenant au moins une action de contrôle d'un traitement d'au moins une demande d'accès audit service à exécuter par ledit équipement client.
L'invention propose une approche complètement nouvelle et inventive de la gestion d'une situation de surcharge ou de défaillance subie par un système de mise en oeuvre d'un service applicatif dans un réseau de télécommunications. Elle consiste à observer le fonctionnement des équipements de service de ce système en collectant des informations relatives à des événements de traitement de messages échangés lors d'un accès à ce service au niveau de ces équipements, et, en cas d'anomalie détectée par rapport à un ou plusieurs critères donnés d'exécution du service, à décider d'une ou plusieurs actions de contrôle d'un traitement d'au moins une demande d'accès au service par ledit équipement client. Avantageusement, l'action de contrôle a pour effet de modifier une configuration réseau initiale faite au démarrage de l'équipement client. A cet effet, elle comprend par exemple un ou plusieurs paramètres de contrôle du traitement d'une demande d'accès au service par l'équipement client. L'invention s'applique à un équipement client déjà configuré pour accéder au service et qui y a déjà accès. Le mécanisme de contrôle du traitement d'une demande d'accès au service applicatif par l'équipement client selon l'invention diffère donc d'une procédure de configuration initiale d'un équipement client destiné à lui permettre d'accéder au service.
De la sorte, les anomalies de traitement qui pourraient induire une situation de crise/surcharge et impacter la bonne exécution du service telle que définie par lesdits critères, sont gérées en anticipation, à la source des demandes d'accès au service et en dehors du système, sans impacter les équipements du cœur de service (ou plateforme de service).
Contrairement à l'art antérieur, il ne s'agit plus seulement de détecter et d'éviter un état de surcharge d'un équipement de service, mais surtout de détecter voire d'anticiper une anomalie ou une défaillance dans la mise en œuvre du service par un ou plusieurs équipements de service, avant qu'elle ne crée une situation de surcharge et surtout avant qu'elle nuise à la bonne exécution du service considéré.
Selon l'invention, des critères d'exécution génériques aux différents services et/ou spécifiques au service considéré sont définis et pris en compte, et utilisés pour détecter des anomalies de traitement comme des déviations par rapport à des conditions de fonctionnement nominal, ce qui permet de décider de façon pertinente de la ou les actions de contrôle les mieux adaptées.
Selon l'invention, ces actions de contrôle sont destinées aux équipements clients eux-mêmes de façon à agir au plus près de la source des demandes d'accès au service tout en minimisant l'impact sur le fonctionnement du cœur du système. Ceci permet de modifier la façon dont ils traitent une demande d'accès au service ou un message d'établissement d'une session applicative et offre bien plus de possibilités d'ajustements qu'un simple filtrage aléatoire du trafic à l'entrée de la plateforme de service, comme le propose l'art antérieur.
En effet, si un tel filtrage préserve la plateforme de service d'un état de surcharge, il ne prend pas en compte le type de service ni d'éventuels critères pour évaluer si les mesures de filtrage mises en œuvre au niveau des équipements de bordure permettent de rendre le service applicatif dans des conditions de fonctionnement acceptables et satisfaisantes pour l'utilisateur.
Ainsi, en prenant en compte des critères d'exécution spécifiques au service applicatif considéré, l'invention permet d'adapter le contrôle effectué sur les équipements clients.
Avantageusement, l'action de contrôle comprend un paramètre de configuration de l'équipement client de façon à ce que ce dernier modifie sa configuration initiale. L'invention s'appuie sur des mécanismes de signalisation connus et déjà utilisés pour la fourniture du service, sans nécessiter d'extension particulière. Par exemple un protocole de gestion de la configuration des équipements d'un réseau, tel que NETCONF ou RESTCONF peut être utilisé. Un tel protocole s'appuie sur le langage XML pour coder les données de configuration ainsi que les messages du protocole. En ce qui concerne le format et la structure des notifications d'événements de traitement, un langage de modélisation de données tel que YANG peut être utilisé, moyennant la définition d'un module YANG dédié.
L'invention s'applique à tout type de service applicatif, mais elle est particulièrement intéressante dans le cas d'un service de téléphonie sur IP, notamment lorsqu'il se trouve confronté à une situation de type « Flash Crowds ».
Selon au moins un aspect de l'invention, ledit procédé comprend l'apprentissage préalable d'un modèle de classification d'un système de détection automatique d'unedite anomalie de traitement à partir d'un ensemble d'apprentissage comprenant des informations d'événements de traitement préalablement étiquetées à l'aide d'au moins deux classes comprenant une classe de présence d'anomalie et une classe d'absence d'anomalie et ladite détection d'une anomalie est réalisée par ledit système à partir des informations d'évènements de traitement obtenues pour un ou plusieurs équipements de service impliqués dans la mise en oeuvre du service considéré, ledit système produisant en sortie l'une des au moins deux classes.
Par exemple un tel système met en oeuvre un modèle de classification déterminé à l'aide de techniques d'intelligence artificielle telles que l'apprentissage machine (pour « machine learning », en anglais) pour collecter et classer les données observées et un algorithme (tel que l'apprentissage par renforcement) permettant d'assister la prise de décision relative au traitement de la situation de crise.
Un avantage est de déterminer une situation optimale de fonctionnement d'un équipement de service ou d'un ensemble d'équipements de service pour rendre le service considéré.
Selon un autre aspect de l'invention, ladite action de contrôle appartient à un groupe comprenant au moins :
- une action de contrôle d'un étalement temporel d'émissions de demandes d'établissement de sessions applicatives par ledit équipement client ;
- une action de contrôle d'un nombre de tentatives d'établissement d'une session applicative audit service par ledit équipement client ;
- une action de contrôle d'un numéro de remplacement du numéro de téléphone associé au service demandé par ledit équipement client ; - une action de contrôle d'une priorité du service, comprenant la configuration de niveaux de priorité affectés aux services demandés et aux autres services auxquels ledit équipement client peut accéder;
- une action de contrôle d'une programmation automatique d'un serveur d'annonces d'un numéro de remplacement d'un numéro de téléphone associé au service demandé par ledit équipement client.
Un avantage est que l'ajustement de la configuration des équipements de service et/ou des équipements clients proposé par l'invention permet de réguler, rediriger, voire hiérarchiser le trafic en fonction du service demandé.
Selon encore un autre aspect de l'invention, lorsque ledit service applicatif comprend un établissement d'une communication téléphonique, ladite action de contrôle comprend la configuration d'au moins un numéro de téléphone, dit numéro alias, de remplacement d'un numéro de téléphone associé au service.
Avantageusement, un tel numéro alias permet d'accéder au standard téléphonique par une autre route réseau. Pour un service d'urgence par exemple, l'objectif est que le service soit rendu pour toutes les demandes d'accès reçues par le système. Un avantage de l'invention est de permettre la configuration d'un autre numéro de téléphone par l'intermédiaire duquel le centre d'urgence, bien que saturé sur son numéro de téléphone principal, reste joignable. Cette configuration est transparente pour l'utilisateur qui peut continuer à composer le numéro de téléphone habituel et ne se rend même pas compte de la redirection de sa demande.
L'invention propose ainsi une solution fiable pour gérer un pic de surcharge au niveau d'un service applicatif, en particulier un centre d'appel de sécurité publique (pour « Public Safety Answering Point », en anglais), sans exiger d'un utilisateur en état de stress extrême de consulter un réseau social pour prendre connaissance d'un numéro de téléphone alternatif mis en place par l'opérateur du service, par exemple.
En variante, lorsque ledit service applicatif comprend un établissement d'une communication téléphonique, ladite action de contrôle comprend la programmation automatique d'un serveur d'annonce d'un numéro de téléphone de remplacement d'un numéro de téléphone de destination. Alternativement, lorsqu'un utilisateur tente d'établir une communication téléphonique avec un numéro de téléphone de destination (par ex. associé au standard téléphonique, un centre d'urgence, un appel international) et qu'un numéro de remplacement a été mis en place du fait que celui-ci est temporairement injoignable, le serveur de programmation annonce à l'utilisateur le numéro de remplacement à composer. Selon un autre aspect de l'invention, ledit au moins un critère d'exécution du service comprend un taux d'échec d'établissement de communication téléphonique égal à zéro et un délai d'établissement de communication téléphonique inférieur à un seuil prédéterminé.
Pour un service d'urgence, la communication avec le centre d'urgence doit être établie avec succès dans 100% des cas et avec un délai raisonnablement court.
L'invention concerne également un dispositif de contrôle d'un accès par au moins un équipement client à un service applicatif dans un réseau de télécommunications, ledit au moins un équipement client étant configuré pour accéder audit service applicatif, ledit dispositif étant configuré pour mettre en oeuvre :
- l'obtention d'informations d'événements relatifs au traitement par au moins un équipement de service impliqué dans une mise en oeuvre du service applicatif, de messages échangés lors d'au moins un accès audit service applicatif;
- la détection, à partir des informations obtenues, d'une anomalie de traitement par au moins undit équipement de service par rapport à au moins un critère donné d'exécution du service; et
- la transmission audit équipement client d'au moins un message de contrôle comprenant au moins une action de contrôle d'un traitement d'au moins une demande d'accès audit service à exécuter par ledit équipement client.
Avantageusement, ledit dispositif configuré pour mettre en oeuvre les étapes du procédé de contrôle d'un accès tel que décrit précédemment.
Avantageusement, ledit dispositif est intégré dans un équipement de contrôle d'au moins un équipement de service impliqué dans la mise en oeuvre d'un service applicatif dans un réseau de télécommunications.
Avantageusement, ledit équipement de contrôle est compris dans un système de mise en oeuvre d'un service applicatif dans un réseau de télécommunications, ledit système comprenant une pluralité d'équipements de service impliqués dans la mise en oeuvre dudit service.
Le système, l'équipement de contrôle et le dispositif de contrôle présentent au moins les mêmes avantages que ceux conférés par le procédé de contrôle précité.
Corrélativement, l'invention concerne aussi un procédé de traitement d'un message de contrôle d'un accès à un service applicatif impliquant au moins un équipement de service dans un réseau de télécommunications, ledit procédé étant exécuté par un équipement client configuré pour accéder audit service applicatif, ledit procédé comprenant :
- la réception du message de contrôle en provenance d'un équipement de contrôle dudit réseau de télécommunications, ledit message de contrôle comprenant au moins une action de contrôle d'un traitement d'au moins une demande d'accès audit service par ledit équipement client, et
- l'exécution de l'action de contrôle lors du traitement de ladite demande. Avec l'invention, l'équipement de contrôle agit sur l'équipement client de sorte à ajuster la façon dont il traite les demandes d'accès au service applicatif. Il intervient ainsi à la source de sorte à corriger sans délai la ou les anomalies de fonctionnement constatées au niveau d'un ou plusieurs équipements de service constituant le système de mise en oeuvre du service applicatif.
Selon un aspect de l'invention, lorsque le service demandé comprend l'établissement d'une communication téléphonique avec une destination et l'action de contrôle comprend la configuration d'au moins un numéro de téléphone alias d'un numéro de téléphone associé au service demandé, l'exécution de l'action comprend :
- la modification d'un en-tête du message de demande d'accès audit service comprenant le remplacement du numéro de téléphone associé au service demandé par ledit numéro de téléphone alias.
Par exemple l'équipement client effectue ce remplacement dans le champ « Request URI » de l'entête « To » de la demande d'accès au service.
Un avantage d'effectuer cette modification au niveau de l'équipement client est que les en-têtes ne sont pas encore chiffrés. En effet, de façon courante, des équipements de service utilisent des protocoles de chiffrement de certains en-têtes du message ou de certains champs d'information contenus dans ces en-têtes.
L'invention concerne également un dispositif de traitement d'un message de contrôle d'un accès à un service applicatif impliquant au moins un équipement de service dans un réseau de télécommunications, ledit dispositif étant destiné à être exécuté par un équipement client configuré pour accéder audit service applicatif, ledit dispositif étant configuré pour mettre en oeuvre :
- la réception d'un message de contrôle en provenance d'un équipement de contrôle dudit réseau de télécommunications, ledit message de contrôle comprenant au moins une action de contrôle d'un traitement d'au moins une demande d'accès audit service par ledit équipement client, et
- l'exécution de l'action de contrôle lors du traitement de ladite demande.
Avantageusement, ledit dispositif configuré pour mettre en oeuvre les étapes du procédé de traitement d'un message de contrôle d'un accès tel que décrit précédemment.
Avantageusement, ledit dispositif est intégré dans un équipement client d'un domaine client configuré pour accéder à un service applicatif, ledit service étant mis en oeuvre par au moins un équipement de service d'un réseau de télécommunications. Il peut aussi être intégré dans le système de mise en oeuvre d'un service applicatif précité.
Le système, l'équipement client et le dispositif de traitement présentent au moins les mêmes avantages que ceux conférés par le procédé de contrôle précité. L'invention concerne également des produits programme d’ordinateur comprenant des instructions de code de programme pour la mise en oeuvre des procédés tels que décrits précédemment, lorsqu'ils sont exécutés par un processeur.
Un programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise également un support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes des procédés selon l'invention tel que décrits ci-dessus.
Un tel support d’enregistrement peut être n’importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu’une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d’enregistrement magnétique, par exemple un support mobile (carte mémoire) ou un disque dur ou un SSD.
D’autre part, un tel support d’enregistrement peut être un support transmissible tel qu’un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d’autres moyens, de sorte que le programme d'ordinateur qu'il contient est exécutable à distance. Le programme selon l’invention peut être en particulier téléchargé sur un réseau par exemple le réseau Internet.
Alternativement, le support d’enregistrement peut être un circuit intégré dans lequel les programmes sont incorporés, le circuit étant adapté pour exécuter ou pour être utilisé dans l’exécution des procédés précités.
Selon un exemple de réalisation, la présente technique est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu’à un composant matériel ou à un ensemble de composants matériels et logiciels.
Un composant logiciel correspond à un ou plusieurs programmes d’ordinateur, un ou plusieurs sous-programmes d’un programme, ou de manière plus générale à tout élément d’un programme ou d’un logiciel apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d’une entité physique (terminal, serveur, passerelle, set-top-box, routeur, etc.) et est susceptible d’accéder aux ressources matérielles de cette entité physique (mémoires, supports d’enregistrement, bus de communication, cartes électroniques d’entrées/sorties, interfaces utilisateur, etc.). Par la suite, on entend par ressources tous ensembles d'éléments matériels et/ou logiciels support d'une fonction ou d'un service, qu'ils soient unitaires ou combinés. De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (« firmware » en anglais), etc.
Chaque composante du système précédemment décrit met bien entendu en oeuvre ses propres modules logiciels.
Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en oeuvre de la présente technique.
4. Brève description des figures
D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles :
[fig- 1] : la figure 1 (déjà décrite) illustre de façon schématique un exemple de notification d'un état de surcharge par un équipement de service impliqué dans la mise en oeuvre d'un service applicatif à un équipement client qui souhaite accéder au service, selon l'art antérieur;
[fig- 2] : la figure 2 illustre de façon schématique un exemple d'architecture d'un système de mise en oeuvre d'un service applicatif dans un réseau de télécommunications auquel accède un équipement client selon un mode de réalisation de l'invention;
[fig- 3] : la figure 3 détaille un exemple de structure d'un équipement de contrôle d'un tel système et d'un équipement client selon un mode de réalisation de l'invention;
[fig- 4] : la figure 4 illustre de façon schématique un exemple d'architecture d'un système de mise en oeuvre d'un service applicatif selon un autre mode de réalisation de l'invention ;
[fig- 5] : la figure 5 décrit sous forme d'un logigramme les étapes d'un procédé de contrôle d'un accès à un service applicatif mis en oeuvre dans un réseau de télécommunications, selon un exemple de réalisation de l'invention ;
[fig- 6] : la figure 6 décrit sous forme d'un logigramme les étapes d'un procédé de traitement d'un message de contrôle d'un accès à un service applicatif mis en oeuvre dans un réseau de télécommunications, selon un exemple de réalisation de l'invention ;
[fig. 7] : la figure 7 illustre de façon schématique un exemple de fonctionnement nominal du service applicatif ;
[fig- 8] : la figure 8 illustre de façon schématique un exemple d'anomalie de fonctionnement du service ; [fig- 9] : la figure 9 illustre de façon schématique un exemple de contrôle effectué sur un équipement client selon un mode de réalisation de l'invention;
[Fig 10] : la figure 10 décrit un exemple de structure matérielle d'un dispositif de contrôle d'un accès à un service applicatif selon l'invention ; et
[Fig U] : la figure 11 décrit un exemple de structure matérielle d'un dispositif de traitement d'un message de contrôle selon l'invention.
5. Description détaillée de l'invention
Le principe général de l'invention repose sur le contrôle d'un accès par au moins un équipement client à un service applicatif mis en oeuvre par un système comprenant une pluralité d'équipements de service dans un réseau de télécommunications. Ce contrôle s'appuie sur l'obtention d'informations d'événements relatifs au traitement par au moins un des équipements de service du système, de messages échangés dans le cadre de la mise en oeuvre du dit service applicatif, la détection, à partir des informations obtenues, d'une anomalie de traitement par ledit équipement de service par rapport à au moins un critère donné d'exécution du service, et la transmission d'au moins un message de contrôle comprenant au moins une action de contrôle d'un traitement de ladite au moins une demande d'accès audit service par ledit équipement client.
L'invention s'applique à tout type de service applicatif dont l'accès se fait par l'établissement d'une session applicative entre un équipement client demandeur et un tel système, par exemple un appel audio, vidéo ou de messagerie instantanée IM.
Elle concerne tout type de réseau de télécommunications. Dans la suite de la description néanmoins, on s'attache à décrire le cas d'un réseau de télécommunications IP (RT) et un service de téléphonie sur IP. Compte tenu des déploiements actuels en matière de Téléphonie sur IP, les exemples ci-après s'appuieront sur le protocole SIP.
Bien sûr, les modes de réalisation, particulièrement les protocoles envisagés dans ces modes de réalisation, ne sont cités qu'à titre d'exemple.
Dans la suite, on désignera indifféremment par équipement ou élément de service tout élément sollicité pour la fourniture d'un service (et en particulier pour l'établissement d'une session applicative).
Un tel équipement ou élément peut intervenir dans les échanges des messages de contrôle (par exemple à l'aide du protocole SIP), l'échange des données utiles (par exemple à l'aide du protocole RTP), voire les deux.
La mise en oeuvre d'un service peut impliquer un ou plusieurs éléments de service. L'ordre d'invocation des éléments de service peut être statique et spécifique à un service (par exemple conforme à l'architecture IMS) ou être établi à la demande (par exemple, réalisé à l'aide d'une technique de chaînage de service).
Un élément de service peut être mis en oeuvre de manière logicielle et/ou matérielle. Un ou plusieurs éléments de service peuvent être embarqués dans un même équipement physique.
La figure 2 illustre de façon schématique un exemple d'architecture d'un système S pour la mise en oeuvre d'un service de téléphonie IP déployé par un fournisseur de service dans un réseau de télécommunications RT, selon un mode de réalisation de l'invention. Sur cette figure 2, on a aussi représenté un équipement client ou agent d'utilisateur UA (ou « User Agent », en anglais) configuré pour accéder au service. Cet agent utilisateur peut aussi être embarqué dans un terminal utilisateur CPE (ou « Customer Premises Equipment », en anglais). Il s'agit typiquement de tout équipement installé chez ou porté par l'utilisateur pour créer, acheminer ou terminer une communication entre l'utilisateur et le système de l’opérateur ou du fournisseur de service, par exemple une passerelle résidentielle ou professionnelle (ou « gateway », en anglais) ou un téléphone intelligent (ou « smartphone », en anglais). En alternative, l'UA peut aussi être intégré dans un équipement dédié. En cas de présence d'un CPE, ce dernier embarque généralement un équipement relais (ou « proxy server », en anglais), non représenté.
Dans cet exemple, l'équipement client UA, CPE accède au réseau RT par l'intermédiaire d'un réseau d'accès AN, par exemple de type radio cellulaire, fibre ou ADSL.
Le système S de la figure 2 comprend les éléments suivants :
Des éléments ou équipements de service en bordure, appelés ici SBE (« Session Border Element ») et DBE (« Data Border Element »). L'élément SBE est responsable du traitement des messages de signalisation, alors qu'un élément DBE est responsable du traitement des flux média. Ces deux éléments peuvent être embarqués dans un même équipement ou dans des équipements distincts. Un exemple d'implémentation de l'élément SBE est la fonction P-CSCF (ou « proxy- call/session control function », alors que la fonction BGF (« Border Gateway Function ») est un exemple d'implémentation de l'élément SBE. La fonction SBC (« Session Border Controller ») est un autre exemple d'implémentation qui supporte les deux éléments SBE et DBE. On note que :
Lorsque ces éléments SBE/DBE sont directement connectés aux UA, ils sont les points de contact du système mettant en oeuvre le service. Dans cette configuration, les UA n'ont pas de visibilité de la structure interne d'une plateforme cœur PFC de mise en œuvre du service. Ces éléments peuvent aussi être utilisés pour des besoins d'interconnexion avec d'autres domaines (identifiés par « RLM# r» sur la figure 2, avec r entier compris entre 2 et 5). Ces domaines peuvent être d'autres domaines de téléphonie IP, un autre réseau de télécommunications tel que le réseau RTC ou un réseau mobile, etc.
La plateforme cœur PFC, composée d'éléments appelés CF (« Core Functions ») situés dans le réseau cœur CN, non représentés. En effet, l'invention est utilisable de manière générale indépendamment de l'architecture du service sous-jacente, qui est par exemple une architecture IMS (ou « IP Multimedia Subsystem », en anglais) ou toute autre architecture future. Aucune hypothèse n'est faite quant à la nature des CF, leur nombre, ou le séquencement d'invocation de ces CF pour l'établissement d'une session applicative.
Selon ce mode de réalisation de l'invention, le système S comprend aussi un équipement de contrôle, ou contrôleur CTR, configuré pour contrôler les équipements de service et les équipements clients UA, CPE. Il s'agit par exemple d'un contrôleur SDN (ou « Software-Defined Networking », en anglais), comme illustré sur la Figure 3. Il est responsable de la gestion et de la configuration des éléments de service. Les protocoles NETCONF ou RESTCONF sont utilisés à titre d'exemple pour gérer et configurer ces éléments, mais d'autres protocoles peuvent être utilisés.
Dans cet exemple de réalisation de l'invention, l'équipement de contrôle CTR comprend un dispositif 100 de contrôle d'un accès par au moins un équipement client à un service applicatif dans un réseau de télécommunications, ledit au moins un équipement client étant configuré pour accéder audit service applicatif. Il est configuré pour obtenir des informations d'événements relatifs au traitement par au moins un équipement de service impliqué dans la mise en œuvre du service applicatif, de messages échangés lors d'au moins un accès audit service applicatif, détecter, à partir des informations obtenues, une anomalie de traitement par au moins undit équipement de service par rapport à au moins un critère donné d'exécution du service; et transmettre au moins un message de contrôle comprenant au moins une action de contrôle d'un traitement d'au moins une demande d'accès audit service par ledit équipement client.
Le dispositif 100 met ainsi en œuvre le procédé de contrôle d'un accès au service selon l'invention qui sera détaillé ci-après en relation avec la figure 5.
Alternativement, le dispositif 100 peut être indépendant de l'équipement de contrôle, mais connecté à celui-ci par une liaison quelconque, filaire ou non. Par exemple, il peut être intégré à un autre équipement du réseau de télécommunications, par exemple un équipement de service.
Plusieurs contrôleurs peuvent être déployés, comme illustré par la figure 4. Dans ce deuxième exemple, un premier contrôleur est responsable des éléments de service du fournisseur de service, alors qu'un deuxième contrôleur est utilisé pour la gestion des équipements clients (UA, CPE).
En cas de présence de plusieurs contrôleurs, on suppose qu'ils s'interfacent pour des besoins de coordination et de synchronisation d'états, le cas échéant, de façon connue en soi. Selon ce mode de réalisation de l'invention, l'équipement client UA, CPE comprend un dispositif 200 de traitement d'un message de contrôle d'un accès au service applicatif impliquant au moins un équipement de service dans le réseau de télécommunications RT. Ce dispositif 200 est configuré pour recevoir un message de contrôle en provenance de l'équipement de contrôle du réseau de télécommunications, ledit message de contrôle comprenant au moins une action de contrôle d'un traitement d'au moins une demande d'accès audit service par ledit équipement client, et exécuter l'action de contrôle lors du traitement de ladite demande.
Le dispositif 200 met ainsi en oeuvre le procédé de traitement d'un message de contrôle d'un accès au service applicatif selon l'invention qui sera détaillé ci-après en relation avec la figure 6.
On présente désormais, en relation avec la figure 5, sous une forme de logigramme, un exemple de mise en oeuvre d'un procédé de contrôle d'un accès à un service applicatif par au moins un équipement client, selon un mode de réalisation de l'invention. Dans ce qui suit, ce procédé est mis en oeuvre par le dispositif 100 précité.
En 50, des informations d'événements relatifs au traitement par au moins un équipement de service impliqué dans une mise en oeuvre du service applicatif, de messages échangés lors d'au moins un accès audit service applicatif, sont obtenues.
Par exemple, le dispositif de contrôle 100 reçoit ces informations (directement ou indirectement) des équipements de service qu'il contrôle. Elles reflètent l'état d'un tel équipement de service. Avantageusement, il les stocke dans une mémoire Ml, structurée ou non. Par exemple, une telle mémoire est organisée sous la forme d'une base de données et indexée par un identifiant de l'équipement de service concerné par la ou les informations reçues.
A titre d'exemple, le format des notifications comprenant ces informations est défini à l'aide d'un langage de modélisation de données. Par exemple, il s'agit du langage YANG de modélisation des données qui peuvent être véhiculées par exemple dans des messages des protocoles NETCONF ou RESTCONF. Il s'agit d'un langage modulaire représentant des structures de données dans un format d’arbre XML. Le langage de modélisation des données est livré avec un certain nombre de types de données intégrés. D’autres types de données d’application spécifiques peuvent être dérivés des types de données intégrés. En particulier, selon l'invention, les types de données des informations reçues des équipements de service par l'équipement de contrôle peuvent être spécifiés dans un module Yang dédié. Ces informations d'événements de traitement peuvent être sollicitées ou non. Les réponses sollicitées sont des réponses à des requêtes explicites telles que des requêtes GET émises par le dispositif de contrôle 100, alors que les réponses non-sollicitées sont typiquement des notifications envoyées par un équipement de service sans qu'une requête spécifique n'ait été envoyée. Les notifications NETCONF/RESTCONF sont des exemples de réponses non-sollicitées. Par exemple, les notifications peuvent être générées en fonction de filtres maintenus localement par cet équipement de service. Ces notifications peuvent consister à informer le contrôleur :
- d'un taux d'erreurs observé sur une interface donnée de l'équipement de service,
- d'un taux d'échec d'établissement de toutes les sessions traitées par l'équipement de service,
- d'un taux d'échec d'établissement de la moyenne mobile des sessions traitées par un élément de service,
- d'un taux d'échec d'établissement de sessions applicatives vers une destination ou un service spécifique (par ex., un serveur identifié par une adresse IP, un site Web, un numéro E.164, ou un alias SIP),
- d'un délai de réponse (c.-à-d., délai entre le temps d'envoi d'une requête et le temps de réception d'une réponse correspondante),
- d'un taux d'échec d'établissement de sessions vers l'une des destinations (par ex. des numéros E.164 ou des alias SIP) servies par l'équipement de service,
- d'un niveau de charge CPU de l'équipement de service,
- d'un journal des sessions de l'équipement de service,
- etc.
En 51, une anomalie de traitement par au moins undit équipement de service est détectée à partir des informations obtenues et par rapport à au moins un critère donné d'exécution du service. En d'autres termes, des anomalies au niveau du service peuvent aussi être détectées en plus des anomalies au niveau d'un équipement de service.
Ces ou ces critères d'exécution du service peuvent être génériques à tout type de service et/ou spécifiques au service applicatif considéré. Par exemple, pour un service d'urgence tel que le 15, un premier critère peut être un taux d'échec des établissements de sessions d'appel égal à zéro et un délai d'établissement d'un appel par exemple inférieur à une minute.
Ce ou ces critères d'exécution donnés contribuent à définir un fonctionnement nominal du service et aussi des équipements de service impliqués et la détection d'une anomalie selon l'invention comprend la détection d'au moins un écart de fonctionnement dudit au moins un équipement de service par rapport au fonctionnement nominal.
Avantageusement, le procédé comprend l'apprentissage d'un modèle de classification d'un système de décision automatique à partir d'un ensemble d'apprentissage comprenant des informations d'événements de traitement préalablement étiquetées à l'aide d'au moins deux classes comprenant une classe de présence d'anomalie et une classe d'absence d'anomalie et la détection est réalisée par le système de décision qui prend en entrée les informations d'évènements de traitement obtenues pour un ou plusieurs équipements de service impliqués dans la mise en oeuvre du service considéré et fournit en sortie une décision d'anomalie détectée ou d'absence d'anomalie détectée. Par exemple, un tel apprentissage met en œuvre des techniques d'apprentissage machine ML (ou « Machine Learning », en anglais) et alimentent la logique de calcul du dispositif 100 et déterminent le modèle de classification.
On note que la détection d'anomalies peut se faire par équipement de service, pour la pluralité d'équipements de service impliqués dans la mise en œuvre du service considéré, pour les équipements de service associés à une même plateforme cœur PFC globale à plusieurs services, etc.
On note également qu'une décision d'anomalie peut être prise sur la base d'un cumul d'anomalies de traitement détectées au niveau d'équipements de service différents.
En 52, lorsqu'une anomalie de traitement a été détectée au niveau d'un ou plusieurs équipements de service, une décision de commander l'exécution d'au moins une action de contrôle d'un traitement d'au moins une demande d'accès audit service par au moins un équipement client UA, CPE est prise.
En fonction du(es) critère(s) d'exécution donnés utilisé(s) pour détecter une anomalie ou défaillance) de l'anomalie détectée et d'autres informations relatives à l'architecture ou au fonctionnement du système telles que par exemple des travaux de maintenance programmés, le dispositif de contrôle 100 décide de procéder:
- au contrôle de la charge au niveau d'un ou plusieurs équipements clients, avec un certain niveau de granularité, (par exemple, par numéro de téléphone ou plage de numéros de téléphone des équipements clients) ;
- au contrôle de l'étalement temporel de la création de nouvelles sessions applicatives au niveau des équipements clients UA , CPE;
- au contrôle d'un nombre de tentatives prises en compte pour l'établissement d'une session applicative demandée par l'équipement client. Ce nombre peut éventuellement être défini par plage de numéros de téléphone, typiquement, un nombre plus grand peut être défini pour les appels d'urgence que pour d'autres services applicatifs ;
- à la fourniture d'une liste de numéros de téléphone de remplacement ou alias directement à l'équipement client. Par exemple, en cas d'indisponibilité d'une route pour joindre un numéro abrégé (pour le service d'urgence des sapeurs-pompiers 18, par exemple), il s'agit de configurer dynamiquement les équipements clients avec une liste d'alias à utiliser à la place du numéro de téléphone associé au service demandé. Selon une variante d'implémentation, il est aussi possible de configurer des numéros de contournement pour réagir à une indisponibilité d'un équipement d'interconnexion (par. ex. un équipement permettant à un opérateur de se connecter au réseau d'un autre opérateur). L'équipement client UA, CPE remplacera automatiquement le numéro indisponible par un numéro de contournement. Ainsi, les appels seront interceptés par un équipement de contournement associé qui se chargera ensuite de remplacer le numéro de contournement par le numéro d'origine avant transmission ;
- à la priorisation de certains numéros, d'urgence par exemple, grâce à des filtres dédiés communiqués à l'UA,CPE (voire SBE) ;
- à la programmation automatique d'un serveur d'annonces (ou « Announcement Server », en anglais) qui permet d'annoncer des numéros de remplacement lorsque l'UA appelle le numéro abrégé du service ;
- etc.
On note que ces actions de contrôle sont destinées aux équipements clients qui demandent à accéder au service applicatif, mais qu'elles peuvent aussi être commandées à des équipements de service, en particulier des équipements de bordure (SBE). C'est le cas notamment pour l'action de priorisation de certains numéros de téléphone par la mise en place de filtres dédiés.
Bien sûr, ces actions peuvent être combinées. Par exemple, le dispositif de contrôle 100 peut décider, pour permettre le redémarrage d'un service applicatif sans que celui-ci soit écroulé par les pics de trafic immédiatement après la remise en service, d'agir sur l'étalement du traitement de requêtes d'établissement de sessions applicatives envoyées par un UA et/ou sur l'établissement du relais par équipement de bordure un SBE/DBE et/ou sur la redirection des requêtes vers un serveur d'annonce, etc.
En 53, au moins un message de contrôle comprenant au moins une action de contrôle est transmis à un ou plusieurs équipements clients UA, CPE.
On présente désormais, en relation avec la figure 6, sous une forme de logigramme, un exemple de mise en oeuvre d'un procédé de traitement d'un message de contrôle d'un accès à un service applicatif impliquant au moins un équipement de service dans un réseau de télécommunications.
Dans ce qui suit, ce procédé est mis en oeuvre par le dispositif 200 précité, intégré à un équipement client UA, CPE configuré pour accéder audit service applicatif.
En 60, un message de contrôle MC est reçu en provenance d'un équipement de contrôle CTR dudit réseau de télécommunications, ledit message de contrôle comprenant au moins une action de contrôle AC d'un traitement d'au moins une demande d'accès audit service par ledit équipement client. Par exemple, il enregistre l'action de contrôle reçue dans une mémoire M2.
En 61, le dispositif 200 modifie sa configuration initiale pour prendre en compte l'action de contrôle reçue.
Par exemple, lorsque l'action de contrôle comprend un numéro alias à utiliser en remplacement du numéro de téléphone associé au service applicatif considéré, le dispositif 200 enregistre ce numéro alias dans une mémoire et modifie sa procédure de sorte à systématiquement remplacer le numéro de téléphone associé au service par cet alias. Les actions sont par exemple définies à l'aide d'expressions régulières (« regexp »).
En 62, il exécute l'action de contrôle lors du traitement de ladite demande d'accès au service.
Par exemple, à réception d'une demande d'accès au service, il cherche d'abord en mémoire si un numéro alias existe pour cette demande. Si oui, il remplace automatiquement le numéro de téléphone associé au service demandé dans le champ « Request URI» et l'en-tête « To » de la requête d'établissement de session applicative. Contrairement à l'état de l'art, cette action de l'UA est transparente pour l'utilisateur et elle est immédiatement exécutée. Faire exécuter cette action par l'UA est notamment avantageux en cas d'utilisation de protocoles de chiffrement (et de l'URI « sips ») par les équipements de service, car elle intervient à la source, donc avant que le chiffrement soit réalisé).
On présente maintenant, en relation avec la figure 7 l'exemple d'une configuration nominale pour une destination donnée, par exemple un centre d'appel d'urgence situé dans un domaine de destination, par exemple le domaine IP RLM#5 et associé à un numéro de téléphone, par exemple le numéro abrégé 18. Pour les besoins de cet exemple, on suppose que le domaine de destination RLM#5 est aussi joignable avec un autre numéro de téléphone, dit alias. Dans cet exemple, un appel émis par l'équipement client UA, CPE est acheminé jusqu'au centre d'appel dans des conditions de fonctionnement nominal. Autrement dit, la session applicative est établie avec succès dans un délai inférieur à un délai maximum autorisé.
La figure 8 illustre un exemple d'échec d'établissement d'une session applicative demandée par l'équipement client UA, CPE. On suppose que le procédé de contrôle d'accès selon l'invention mis en oeuvre par l'équipement de contrôle CTR a détecté une défaillance de fonctionnement d'un équipement de bordure SDE5/DBE5, plus précisément d'interconnexion entre le réseau cœur CN et le domaine IP RLM#5. Cette défaillance impacte la mise en œuvre d'un ou plusieurs services applicatifs, dont le centre des gestions des appels est situé dans ce domaine IP.
Selon l'invention, l'équipement de contrôle transmet un message de contrôle à l'équipement client UA, CPE.
Ce message comprend une action de contrôle qui consiste en la configuration d'une liste d'alias associant un numéro alias au numéro de téléphone de chacun des services concernés. A réception de la liste d'alias, l'équipement client UA, CPE modifie sa configuration initiale de sorte à utiliser cette liste pour procéder automatiquement à la réécriture du champ « Request URI » (et « To ») de toute requête d'établissement d'une session applicative pour accéder à l'un de ces services, en remplaçant le numéro de téléphone associé au service demandé par son alias. De la sorte et comme illustré par la figure 9, l'appel peut être acheminé avec succès via le domaine IP RLM#4 voisin. Ladite liste d'alias peut aussi être associée avec une date de validité au-delà de laquelle elle est supprimée automatiquement de la mémoire de l'UA, CPE sauf si une action de contrôle est reçue avec une demande de mise à jour de la date de validité à une autre date, ultérieure ou antérieure selon la rapidité avec laquelle la défaillance de fonctionnement est corrigée.
En alternative, le contrôle de traitement d'un accès au service peut aussi être effectué par l'équipement de contrôle CTR au niveau du CPE de l'utilisateur ou de l'équipement de bordure SBE1 localisé dans le réseau d'accès AN. Le contrôleur configure le CPE ou le SBE1 avec une liste d'alias. Cette liste est utilisée par l'équipement de bordure SBE1 pour procéder à la réécriture du champ « Request URI » (et « To ») de la requête d'établissement d'une session applicative. L'appel d'urgence peut être acheminé avec succès via le domaine IP RLM#4 voisin.
La redirection de tout ou partie du trafic vers la destination demandée telle que mise en oeuvre selon l'invention permet aussi de réduire la charge de traitement de l'équipement de service défaillant et facilite la conduite d'opérations de maintenance telles qu'un redémarrage par exemple.
On considère maintenant, selon un deuxième exemple d'application de l'invention, un service de vote électronique. Chaque votant est invité à soumettre son vote (à l'occasion d'une émission télévisée ou d'une échéance électorale, par exemple) en accédant à un site web. La procédure de validation du vote repose sur un mécanisme d'acquittement qui consiste à envoyer au votant un message de confirmation de la prise en compte du vote (et de sa conformité à la règle électorale, le cas échéant). La soumission d'un tel vote peut être soumise à des contraintes temporelles fortes, susceptibles de provoquer une surcharge de trafic au niveau de plusieurs ressources réseau. Il s'agit notamment de celles du réseau utilisé pour acheminer les votes, de celles de l'équipement serveur destiné à réceptionner et comptabiliser les votes, de celles du système d'acquittement évoqué précédemment, ou de n'importe quelle combinatoire de ces ressources.
Dans ce deuxième exemple, l'invention s'appuie sur des dispositifs de traitement 200 embarqués dans des équipements clients, agents utilisateurs UA ou CPE ou encore dans d'autres équipements typiquement situés à la périphérie du réseau, tels que des routeurs du réseau d'accès, des routeurs du réseau cœur, un équipement d'accès au site de vote ou un équipement serveur en charge du traitement des votes. Ces dispositifs 200 sont configurés pour recevoir des actions de contrôle décidées et transmises par un dispositif de contrôle 100 tel que précédemment décrit, par exemple embarqué dans un équipement de contrôle CTR du réseau. De telles actions de contrôle visent à fluidifier l'acheminement du trafic.
Elles consistent par exemple à : (1) surveiller un ensemble de compteurs d'interface qui rendent compte de la volumétrie du trafic transitant par chacune de ces interfaces,
(2) détecter l'atteinte d'un seuil à l'issue d'un relevé de ces compteurs (par exemple, 70% de la bande passante associée à une interface est actuellement utilisée pour acheminer le trafic des votes,
(3) mettre en place une fonction de conditionnement de trafic reposant par exemple sur un algorithme de seaux à jetons (tant qu'il y a des jetons dans le seau, le trafic peut être acheminé, quand il n'y a plus de jetons, le trafic peut être stocké dans une file d'attente (le temps que le volume de trafic repasse en dessous du seuil de 70%) ou bien être redirigé sur un autre chemin non congestionné mais permettant d'atteindre le site de traitement des votes),
(4) (re-) marquer le trafic en excès via un codage DSCP (ou « DiffServ Code Point », en anglais) spécifique, au niveau des équipements UA, CPE ou de périphérie. Par exemple, le trafic du vote est initialement marqué avec un DSCP AF12 (ce qui signifie que le trafic est stocké dans une file d'attente particulière) puis qu'il est re-marqué en AF11 ou Best Effort (DSCP valorisé à zéro), lorsque le trafic a atteint le seuil de 70% cité en exemple,
(5) modifier la ou les métriques associée(s) à une ou plusieurs interface(s) de sorte que de nouvelles routes puissent être spécifiquement établies et utilisées pour acheminer le trafic de soumission des votes et des messages d'acquittement à l'exclusion de tout autre trafic et/ou pour « forcer » le trafic en excès à emprunter un autre chemin, cette modification de métrique pouvant relever d'une décision prise par un contrôleur SDN lequel se chargera d'ordonner à l'équipement concerné de procéder à cette modification, par ex. via une commande NETCONF. On note que la politique d'affectation de métriques à des interfaces est généralement une politique de moindre coût qui tient compte de la bande passante associée à chaque interface. Par exemple, une interface à 10 Gbit/s est affectée d'une métrique de valeur 1 tandis qu'une interface à 100 Mbit/s est affectée une métrique de 100. Si le lien à 10 Gbit/s atteint un taux de charge de 70%, la métrique des interfaces correspondantes pourra être augmentée par exemple à 200. Dans ce cas, le protocole de routage dynamique sélectionnera des chemins au coût moindre, par exemple un chemin transitant par l'interface à 100 Mbit/s,
(6) envoyer une notification d'atteinte ou de dépassement de seuil à un contrôleur SDN, ce qui peut déclencher le calcul de nouveaux chemins selon une architecture PCE (ou « Path Computation Element », en anglais), etc.
De telles actions de contrôle permettent de prévenir tout risque de surcharge de l'équipement serveur configuré pour réceptionner les votes, notamment. Ces actions de contrôle sont exécutées par certains éléments du réseau (voire les équipements clients CPE) selon des informations qui peuvent être véhiculées dans des messages conformes au protocole PCEP (ou « Path Computation Element Protocol », en anglais) pour l'établissement de nouvelles routes, par exemple.
L'invention permet ainsi d'anticiper un contexte de surcharge et de fluidifier aussi bien les messages de soumission des votes que les messages d'acquittement.
Bien entendu les deux exemples d'application ne sont donnés qu'à titre illustratif, et on pourrait envisager encore d'autres contextes d'application de l'invention.
On présente maintenant, en relation avec la figure 10, un exemple de structure matérielle d'un dispositif 100 de contrôle d'un accès par au moins un équipement client à un service applicatif dans un réseau de télécommunications, ledit au moins un équipement client étant configuré pour accéder audit service applicatif, ledit dispositif comprenant un module d'obtention d'informations d'événements relatifs au traitement par au moins un équipement de service impliqué dans une mise en oeuvre du service applicatif, de messages échangés lors d'au moins un accès audit service applicatif, un module de détection, à partir des informations obtenues, d'une anomalie de traitement par au moins undit équipement de service par rapport à au moins un critère donné d'exécution du service; et un module de transmission d'au moins un message de contrôle comprenant au moins une action de contrôle d'un traitement d'au moins une demande d'accès audit service par ledit équipement client.
Le terme « module » peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en oeuvre une fonction ou un ensemble de fonctions.
Plus généralement, un tel dispositif 100 comprend une mémoire vive 103 (par exemple une mémoire RAM), une unité de traitement 102 équipée par exemple d’un processeur, et pilotée par un programme d’ordinateur Pgl, représentatif des modules d'obtention, de détection et de transmission, stocké dans une mémoire morte 101 (par exemple une mémoire ROM ou un disque dur). A l’initialisation, les instructions de code du programme d’ordinateur sont par exemple chargées dans la mémoire vive 103 avant d’être exécutées par le processeur de l’unité de traitement 102. La mémoire vive 103 peut aussi contenir les informations d'événement obtenues. La figure 10 illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le dispositif 100 afin qu'il effectue les étapes du procédé de contrôle d'un accès au service tel que détaillé ci-dessus, en relation avec la figure 5, dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d'instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).
Dans le cas où le dispositif 100 est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une carte SD, une clé USB, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.
Les différents modes de réalisation ont été décrits ci-avant en relation avec un dispositif 100 intégré dans un équipement de contrôle d'un réseau de télécommunications, mais il peut aussi être intégré dans un équipement de service ou tout autre équipement du réseau de télécommunications.
On présente aussi, en relation avec la figure 11, un exemple de structure matérielle d'un dispositif 200 de traitement d'un message de contrôle d'un accès à un service applicatif impliquant au moins un équipement de service dans un réseau de télécommunications, comprenant un module de réception d'un message de contrôle en provenance d'un équipement de contrôle dudit réseau de télécommunications, ledit message de contrôle comprenant au moins une action de contrôle d'un traitement d'au moins une demande d'accès audit service par ledit équipement client, et un module d"exécution de l'action de contrôle lors du traitement de ladite demande.
Le terme « module » peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en oeuvre une fonction ou un ensemble de fonctions.
Plus généralement, un tel dispositif 200 comprend une mémoire vive 203 (par exemple, une mémoire RAM), une unité de traitement 202 équipée par exemple d’un processeur, et pilotée par un programme d’ordinateur Pg2, représentatif des modules de réception et d'exécution, stocké dans une mémoire morte 201 (par exemple, une mémoire ROM ou un disque dur). A l’initialisation, les instructions de code du programme d’ordinateur sont par exemple chargées dans la mémoire vive 203 avant d’être exécutées par le processeur de l’unité de traitement 202. La mémoire vive 203 peut aussi contenir l'action de contrôle reçue dans le message de contrôle.
La figure 11 illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le dispositif 200 afin qu'il effectue les étapes du procédé de traitement d'un message de contrôle d'un accès à un service applicatif tel que détaillé ci-dessus, en relation avec la figure 6, et dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d'instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).
Dans le cas où le dispositif 200 est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une carte SD, une clé USB, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.

Claims

27 REVENDICATIONS
1. Procédé de contrôle d'un accès par au moins un équipement client à un service applicatif dans un réseau de télécommunications, ledit au moins un équipement client étant configuré pour accéder audit service applicatif, ledit procédé comprenant :
- l'obtention (50) d'informations d'événements relatifs au traitement par au moins un équipement de service impliqué dans une mise en oeuvre du service applicatif, de messages échangés lors d'au moins un accès audit service applicatif ;
- la détection (51), à partir des informations obtenues, d'une anomalie de traitement par au moins undit équipement de service par rapport à au moins un critère donné d'exécution du service ; et
- la transmission (53) audit équipement client d'au moins un message de contrôle comprenant au moins une action de contrôle d'un traitement d'au moins une demande d'accès audit service à exécuter par ledit équipement client.
2. Procédé de contrôle selon la revendication 1, caractérisé en ce que ledit procédé comprend l'apprentissage préalable d'un modèle de classification d'un système de détection automatique d'unedite anomalie de traitement à partir d'un ensemble d'apprentissage comprenant des informations d'événements de traitement préalablement étiquetées à l'aide d'au moins deux classes comprenant une classe de présence d'anomalie et une classe d'absence d'anomalie et en ce que ladite détection d'une anomalie est réalisée par ledit système à partir des informations d'évènement de traitement obtenues pour un ou plusieurs équipements de service impliqués dans la mise en oeuvre du service considéré, ledit système produisant en sortie l'une des au moins deux classes.
3. Procédé de contrôle selon l'une des revendications 1 et 2, caractérisé en ce que ladite action de contrôle appartient à un groupe comprenant au moins :
- une action de contrôle d'un étalement temporel d'émissions de demandes d'établissement de sessions applicatives par ledit équipement client ;
- une action de contrôle d'un nombre de tentatives d'établissement d'une session applicative audit service par ledit équipement client ;
- une action de contrôle d'un numéro de remplacement du numéro de téléphone associé au service demandé par ledit équipement client ;
- une action de contrôle d'une priorité du service, comprenant la configuration de niveaux de priorité affectés aux services demandés et aux autres services auxquels ledit équipement client peut accéder; - une action de contrôle d'une programmation automatique d'un serveur d'annonces d'un numéro de remplacement d'un numéro de téléphone associé au service demandé par ledit équipement client.
4. Procédé de contrôle selon l'une des revendications précédentes, caractérisé en ce que lorsque ledit service applicatif comprend un établissement d'une communication téléphonique, ladite action de contrôle comprend la configuration d'au moins un numéro de téléphone, dit numéro alias, de remplacement d'un numéro de téléphone associé au service.
5. Procédé de contrôle selon l'une des revendications précédentes, caractérisé en ce que, lorsque ledit service applicatif comprend un établissement d'une communication téléphonique, ladite action de contrôle comprend la programmation automatique d'un serveur d'annonce d'un numéro de téléphone de remplacement d'un numéro de téléphone de destination.
6. Procédé de contrôle selon l'une des revendications 4 et 5, caractérisé en ce que ledit au moins un critère d'exécution du service comprend un taux d'échec d'établissement de communication téléphonique égal à zéro et un délai d'établissement de communication téléphonique inférieur à un seuil prédéterminé.
7. Procédé de traitement d'un message de contrôle d'un accès à un service applicatif impliquant au moins un équipement de service dans un réseau de télécommunications, ledit procédé étant exécuté par un équipement client configuré pour accéder audit service applicatif, ledit procédé comprenant :
- la réception (60) du message de contrôle en provenance d'un équipement de contrôle dudit réseau de télécommunications, ledit message de contrôle comprenant au moins une action de contrôle d'un traitement d'au moins une demande d'accès audit service par ledit équipement client, et
- l'exécution (62) de l'action de contrôle lors du traitement de ladite demande.
8. Procédé de traitement selon la revendication précédente, caractérisé en ce que, lorsque le service demandé comprend l'établissement d'une communication téléphonique avec une destination et l'action de contrôle comprend la configuration (61) d'au moins un numéro de téléphone alias d'un numéro de téléphone associé au service demandé, l'exécution de l'action comprend :
- la modification d'un en-tête du message de demande d'accès audit service comprenant le remplacement du numéro de téléphone associé au service demandé par ledit numéro de téléphone alias.
9. Dispositif (100) de contrôle d'un accès par au moins un équipement client à un service applicatif dans un réseau de télécommunications, ledit au moins un équipement client étant configuré pour accéder audit service applicatif, ledit dispositif étant configuré pour mettre en oeuvre :
- l'obtention d'informations d'événements relatifs au traitement par au moins un équipement de service impliqué dans une mise en oeuvre du service applicatif, de messages échangés lors d'au moins un accès audit service applicatif ;
- la détection, à partir des informations obtenues, d'une anomalie de traitement par au moins undit équipement de service par rapport à au moins un critère donné d'exécution du service ; et
- la transmission audit équipement client d'au moins un message de contrôle comprenant au moins une action de contrôle d'un traitement d'au moins une demande d'accès audit service à exécuter par ledit équipement client.
10. Dispositif (200) de traitement d'un message de contrôle d'un accès à un service applicatif impliquant au moins un équipement de service dans un réseau de télécommunications, ledit dispositif étant destiné à être exécuté par un équipement client configuré pour accéder audit service applicatif, ledit dispositif étant configuré pour mettre en oeuvre :
- la réception d'un message de contrôle en provenance d'un équipement de contrôle dudit réseau de télécommunications, ledit message de contrôle comprenant au moins une action de contrôle d'un traitement d'au moins une demande d'accès audit service par ledit équipement client, et
- l'exécution de l'action de contrôle lors du traitement de ladite demande.
11. Système (S) de mise en oeuvre d'un service applicatif dans un réseau de télécommunications, ledit système comprenant une pluralité d'équipements de service impliqués dans la mise en oeuvre d'un service applicatif, caractérisé en ce qu'il comprend au moins un dispositif de contrôle (100) selon la revendication 9.
12. Système (S) selon la revendication 11, caractérisé en ce qu'il comprend au moins un dispositif de traitement (200) d'un message de contrôle d'un accès à un service applicatif selon la revendication 10.
13. Programme d'ordinateur comprenant des instructions de code de programme pour la mise en oeuvre d'un procédé selon l’une quelconque des revendications 1 à 8, lorsqu'il est exécuté par un processeur.
EP22793193.8A 2021-09-27 2022-09-26 Procédé de controle d'un accès à un service applicatif mis en oeuvre dans un réseau de télécommunications, procédé de traitement d'un message de controle d'un accès audit service applicatif, dispositifs, équipement de controle, équipement client, système et programmes d'ordinateur correspondants Pending EP4409864A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2110174A FR3127663A1 (fr) 2021-09-27 2021-09-27 Procédé de contrôle d’un accès à un service applicatif, procédé de traitement d’un message de contrôle d’un accès audit service, dispositifs, système et programmes d’ordinateur correspondants.
PCT/FR2022/051802 WO2023047068A1 (fr) 2021-09-27 2022-09-26 Procede de controle d'un acces a un service applicatif mis en œuvre dans un reseau de telecommunications, procede de traitement d'un message de controle d'un acces audit service applicatif, dispositifs, equipement de controle, equipement client, systeme et programmes d'ordinateur correspondants

Publications (1)

Publication Number Publication Date
EP4409864A1 true EP4409864A1 (fr) 2024-08-07

Family

ID=79018293

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22793193.8A Pending EP4409864A1 (fr) 2021-09-27 2022-09-26 Procédé de controle d'un accès à un service applicatif mis en oeuvre dans un réseau de télécommunications, procédé de traitement d'un message de controle d'un accès audit service applicatif, dispositifs, équipement de controle, équipement client, système et programmes d'ordinateur correspondants

Country Status (5)

Country Link
US (1) US20240406175A1 (fr)
EP (1) EP4409864A1 (fr)
CN (1) CN118044170A (fr)
FR (1) FR3127663A1 (fr)
WO (1) WO2023047068A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20250080539A1 (en) * 2023-09-06 2025-03-06 Capital One Services, Llc Systems and methods for dynamic access control for secure systems based on user tuning subject to system controls

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10131561A1 (de) * 2001-06-29 2003-01-16 Nokia Corp Verfahren zur Übertragung von Anwendungspaketdaten
EP1753198A1 (fr) * 2005-08-09 2007-02-14 Alcatel Architecture de réseau de voix sur IP
FR2909823B1 (fr) * 2006-12-06 2012-12-14 Soc Fr Du Radiotelephone Sfr Procede et systeme de gestion de sessions multimedia, permettant de controler l'etablissement de canaux de communication
FR2928801A1 (fr) 2008-03-17 2009-09-18 France Telecom Procede de gestion de charge d'un equipement d'un systeme de mise en oeuvre d'un service applicatif
US11589083B2 (en) * 2014-09-26 2023-02-21 Bombora, Inc. Machine learning techniques for detecting surges in content consumption
CN119420737A (zh) * 2024-10-31 2025-02-11 深圳大道云科技有限公司 基于sip协议的通话方法、设备及存储介质

Also Published As

Publication number Publication date
US20240406175A1 (en) 2024-12-05
FR3127663A1 (fr) 2023-03-31
WO2023047068A1 (fr) 2023-03-30
CN118044170A (zh) 2024-05-14

Similar Documents

Publication Publication Date Title
US9043453B1 (en) Systems and methods for optimizing application data delivery over third party networks
US9432292B2 (en) Overload call control in a VoIP network
EP3503508B1 (fr) Procédé de traitement de requêtes et serveur proxy
EP2591587B1 (fr) Accès confidentiel ou protégé à un réseau de noeuds répartis sur une architecture de communication à l'aide d'un serveur de topoloqie
FR3023108A1 (fr) Procede et dispositif d'orchestration de ressources
EP3357202B1 (fr) Système de restauration de services fournis par une passerelle résidentielle
EP3085065B1 (fr) Procédé de mise a jour dynamique d'informations obtenues de la part d'un serveur dns
EP2366238B1 (fr) Procede et systeme de regulation du trafic de redemarrage dans un reseau de telecommunications
EP2460322B1 (fr) Procede et systeme pour la selection automatique de media de transmission
EP1479203A1 (fr) Correlation des requetes en qualite de service
FR2859588A1 (fr) Dispositif de traitement de mesures de parametres et/ou de trafics, en vue d'une comptabilisation locale de l'utilisation de ressources, pour un equipement de reseau de communications
WO2023047068A1 (fr) Procede de controle d'un acces a un service applicatif mis en œuvre dans un reseau de telecommunications, procede de traitement d'un message de controle d'un acces audit service applicatif, dispositifs, equipement de controle, equipement client, systeme et programmes d'ordinateur correspondants
EP2396950B1 (fr) Procede et systeme de gestion de la signalisation dans un reseau de telecommunications
US10230679B1 (en) Systems and methods for optimizing application data delivery over third party networks
WO2006108989A2 (fr) Procede de lutte contre l'envoi d'information vocale non sollicitee
EP1349319B1 (fr) Dispositif de gestion de service réseau utilisant le protocole cops pour la configuration d'un réseau privé virtuel
WO2009122071A2 (fr) Procede de gestion de charge d'un equipement d'un systeme de mise en oeuvre d'un service applicatif
EP2103055A1 (fr) Procédé d'optimisation du partage d'une pluralité de ressources réseau entre une pluralité de flux applicatifs
EP2801178B1 (fr) Procédé dynamique de détermination d'une liste de services dans un réseau sip
WO2024068725A1 (fr) Procédé de gestion du trafic de données entre une entité source et une entité destinataire, entité et programme d'ordinateur correspondants
EP3231137B1 (fr) Réseau superposé pour reseau de communication connectant des centres de données d'un fournisseur de services en nuage
FR3044195A1 (fr) Procede et dispositif de traitement d'une annonce non legitime d'un bloc d'adresses ip

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20240314

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20260128