EP2586214A1 - Notification d'incident sur un acces rnis raccorde a un reseau ip - Google Patents

Notification d'incident sur un acces rnis raccorde a un reseau ip

Info

Publication number
EP2586214A1
EP2586214A1 EP11737992.5A EP11737992A EP2586214A1 EP 2586214 A1 EP2586214 A1 EP 2586214A1 EP 11737992 A EP11737992 A EP 11737992A EP 2586214 A1 EP2586214 A1 EP 2586214A1
Authority
EP
European Patent Office
Prior art keywords
network
isdn access
defect
isdn
noted
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.)
Withdrawn
Application number
EP11737992.5A
Other languages
German (de)
English (en)
Inventor
José DOREE
Jean-Claude Le Rouzic
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
France Telecom 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 France Telecom SA filed Critical France Telecom SA
Publication of EP2586214A1 publication Critical patent/EP2586214A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q11/00—Selecting arrangements for multiplex systems
    • H04Q11/04—Selecting arrangements for multiplex systems for time-division multiplexing
    • H04Q11/0407—Selecting arrangements for multiplex systems for time-division multiplexing using a stored program control
    • H04Q11/0414—Details
    • 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/06—Management of faults, events, alarms or notifications
    • H04L41/0681—Configuration of triggering conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q11/00—Selecting arrangements for multiplex systems
    • H04Q11/04—Selecting arrangements for multiplex systems for time-division multiplexing
    • H04Q11/0407—Selecting arrangements for multiplex systems for time-division multiplexing using a stored program control

Definitions

  • the present invention relates to Integrated Services Digital Network (ISDN).
  • ISDN Integrated Services Digital Network
  • the present invention relates to the connection of an ISDN access to a telecommunications network of IP ("Internet Protocol”) type.
  • IP Internet Protocol
  • the Switched Telephone Network and in particular the public switched telephone network RTCP (in English, PSTN), is a fixed telephony network in which an analogue terminal or a digital installation are connected to a central office by one or more twisted pairs of copper son fed by the network, the assembly constituting what is called the "local loop".
  • the telephone exchanges are themselves linked together by high speed links.
  • the analog or digital telephone terminals can be of various kinds, for example an individual telephone (subscriber station), a payphone, or a PABX (initials of the words “Private Automatic Branch eXchange” meaning "private telephone switch") which serves mainly to connect the telephones of an establishment ("internal” lines) with the public telephone network ("external” lines).
  • the H.323 protocol has been developed by ITU-T. It specifies procedures for signaling, coder-decoder negotiation, and information transport. It is widely used by manufacturers of voice and video conferencing, as well as in several real-time Internet applications such as "NetMeeting".
  • the SIP protocol has been defined by NETF in RFC 3261. This protocol allows the establishment, modification and termination of multimedia sessions in a network using the IP protocol.
  • the SIP protocol also allows for event notification procedures and the sending of information outside the context of a session. It is widely used for instant messaging service orders. Thus, in a SIP environment, there are different types of communications such as session establishment requests and queries exchanged outside any dialog.
  • the invention is particularly suitable for IMS ("IP Multimedia Subsystem") type infrastructures.
  • the IMS has been defined by the 3rd Generation Partnership Project (3GPP) and TISPAN (Telecommunications and Internet Converged Services and Protocols for Advanced Networking). It is a network architecture introduced by 3GPP for mobile networks, then taken over by TISPAN for fixed networks.
  • This architecture which uses the SIP protocol, allows the dynamic establishment and the control of multimedia sessions between two clients as well as the reservation of the resources at the level of the network of transport of the multimedia flows. Thanks to this architecture, Network operators can conveniently implement a management policy, provide a predetermined Quality of Service, and calculate the amounts to be billed to customers.
  • the IMS currently provides access to telephony, video telephony, presence and instant messaging services, which it also manages.
  • VoIP over IP Voice over IP
  • VoIP subscribers While the number of traditional PSTN subscribers is declining, that of VoIP subscribers, who have subscribed to a bundled services offer (Internet / TV / unlimited telephony), is growing strongly.
  • VoIP subscribers are (or will be) connected to IMS network cores, while the PSTN subscribers are currently connected to time switches in the telephone exchanges through the Subscriber Connection Units (URA) ( a "time switch" operates on time multiplexed signals).
  • UUA Subscriber Connection Units
  • RTC emulation The PSTN subscribers are then connected to new types of ARUs that perform the call signaling protocol adaptation for IMS core communication, as well as the encoding / decoding of the media streams: in the context of the present invention these new types of URA will be called "URA-SIP".
  • URA-SIPs examples include home bridges and gateways in ("Residential Gateways” in English), and secondly the gateways located in the network of an operator ("Voice Gateways" in English) such as DSLAM-SIP or DSLAM-H.248 (DSLAM are the initials of "Digital Subscriber Line Access Multiplexer” means “Digital Subscriber Line Access Multiplexer” means devices that collect DSL data traffic over a number of telephone lines.
  • ISDN access offers digital links based on the quality of the RTC, and offering speeds up to 2 Mbit / s.
  • ISDN combines the broad geographic coverage of a telephone network with the transport capacity of a data network carrying voice, data and video.
  • With ISDN for example, smaller regional and international sites can connect to corporate networks at a cost that is better suited to actual consumption than with dedicated lines. A subscriber can thus request ISDN connections either to replace specialized lines, or in addition to increase the bandwidth or ensure redundancy.
  • the International Telecommunication Union has defined ISDN technology so that it can provide digital connectivity with a wide variety of services.
  • Two important features allow the RTC to evolve to offer ISDN services:
  • the network must offer a set of ISDN-compliant user interface / network protocols; in this way, all ISDN equipment uses the same physical connections and signaling protocols to access the services.
  • the local loop allows a single transmission channel; this channel processes only one service at any given time: voice or data.
  • the local loop (comprising one or two pairs of twisted wires) is divided into several logical channels, called B and D, distinguished by their functions and their bit rates.
  • B and D two types of access can be used, characterized by their respective numbers of B and D channels: the basic access access S0 / T0 (Basic Rate Access or BRA), and the primary access S2 / T2 ("Primary Rate Access" or PRA).
  • S0 / T0 Basic Rate Access
  • PRA Primary Rate Access
  • the operator regularly carries out preventive tests which use re-closure mechanisms, as well as procedures error rate calculation (using the CRC - cyclic redundancy check mechanisms specified in the ISDN physical bearer layer). These maintenance procedures are described in the ITU-T 1.430 standards for basic access (ISDN BRA), and ITU-T 1.431 for primary access (ISDN PRA).
  • the ISDN access is deemed to be defective, the interface can then be declared out of service and the operator is obliged (contractually, most often) to remedy as quickly as possible the defects observed. If the fault is located in the client facility, incident reporting and operator intervention are only required under conditions (usually only for primary ISDN access, and under contract conditions).
  • FIG. 1 schematically illustrates, by way of example, the connection of an ISDN access to an IP network, for a basic access (ISDN BRA) or a primary access (ISDN PRA), via a connection device 1 constituted by a URA-SIP or a set consisting of an H.248 gateway and an intermediate entity of the network, such as the AGCF (initials of the words "Access Gateway Control Function” meaning Access Gateway Control Function) .
  • the rest of the IP network is not represented.
  • connection interface of the client-installation to the ISDN access is marked “T”; at the associated end of the ISDN access is a device denoted “NT1" (initials of the words “Network Termination 1”); NT1 equipment is also commonly referred to as TNR (for "Digital Network Termination” in French ISDN access) in the case of basic access connections; and
  • FIG. 2 diagrammatically illustrates, as another example, the connection of a primary ISDN access (ISDN PRA) to an IP network via a connection device 1 constituted by a transit gateway ("Trunking Gateway” or TGW). To simplify the figure, the rest of the IP network is not represented.
  • ISDN PRA primary ISDN access
  • connection point of the client installation to the ISDN access is "T2"; at the associated end of the ISDN access is a device denoted "NT1"; at the associated end of the subscriber installation is a PABX denoted "NT2"; and
  • the need for a mechanism to accurately locate an error in the operator section is particularly important when the ISDN access operator (operating a DSLAM for example) and the service operator (in charge of the control and as a service to the customer) are different, as is the case in some networks: indeed, it is necessary to clearly separate and identify the responsibilities of each.
  • the service operator does not have - unlike the network operator - the ability to query the connection device to obtain information about the status of the ISDN access.
  • the present invention thus relates to a method of incident notification on an ISDN access connected to an IP network.
  • This method is remarkable in that it comprises the following steps: detection of said incident by a connection device of said ISDN access to said IP network, and
  • connection device - sending by said connection device a session control message to a device, called said requestor, of the IP network, having previously subscribed to the connection device, explicitly or implicitly, to the notification of at least one piece of information status of ISDN access.
  • the management of an ISDN access by an operator is considerably improved thanks to the automatic provision of status information concerning this ISDN access.
  • this is particularly advantageous in the case where the requesting state information device is a service operator distinct from the ISDN access operator.
  • This provision of information therefore allows an operator to react quickly and implement an appropriate repair action, so as to minimize the downtime for ISDN customers.
  • said status information advantageously relates to:
  • said session control message contains a specific header ("header"). associated with the subscription to said state information (in the context of the invention, a "header” designates a specific line in a session control message).
  • the invention requires only a modest extension of session control protocols (SIP, or other).
  • the invention relates to various devices.
  • said status information relates to:
  • the invention also relates to a computer program downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor.
  • This computer program is notable in that it includes instructions for performing the steps of any of the incident notification methods succinctly set forth above, when run on a computer.
  • FIG. 1 schematically represents the connection of an ISDN access to an IP network via a URA-SIP
  • FIG. 2 shows schematically the connection of an ISDN access to an IP network via a transit gateway.
  • a device 2 of an IP network requesting status information from an ISDN access connected to the IP network, subscribes, explicitly or implicitly, to the notification of this information to a device connection 1 of the ISDN access to the IP network.
  • This connection device 1, supervisor and generator of the state information can be, for example (see description of FIGS. 1 and 2 above), a URA-SIP (home gateway, enterprise gateway, gateway, etc.). operator such as a DSLAM-SIP or DSLAM-H248, possibly associated with an AGCF, and so on) or a TGW transit gateway.
  • URA-SIP home gateway, enterprise gateway, gateway, etc.
  • operator such as a DSLAM-SIP or DSLAM-H248, possibly associated with an AGCF, and so on
  • TGW transit gateway a TGW transit gateway.
  • the requesting device 2 can be, in particular:
  • An AS server (initials of the English words "application server” meaning “application server”) such as a voicemail server, a presence server or a telephony server,
  • P-CSCF Proxy-Call Server Control Function
  • S-CSCF servers manage the registration procedure of user terminals , as well as the routing of the resulting signaling, or destination, of these user terminals), or
  • IBCF server initials of the English words "Interconnection Border Control Function” meaning the Interconnection Border Control Function) (the IBCF servers serve as gateways to external networks, and in particular act as firewalls).
  • the states of ISDN access that may be useful for notification include:
  • the "network interface failure" status indicates a fault found in the digital operator section of the ISDN access
  • the "grading" state indicates a degradation of quality noted in the digital operator section; this type of degradation allows calls to be disposed of, but can trigger maintenance operations; the conditions for triggering the notification of these states depend on the quality policy of the operator of the ISDN access (crossing an error rate threshold, for example).
  • the state information according to the invention may be conveyed in a new header ("header"), which will be called for example "DigitalSection-Supervision".
  • header which will be called for example "DigitalSection-Supervision”.
  • the "method”, that is the type of session control message that will convey this new header may be of a conventional type (eg NOTIFY, INFO, MESSAGE, INVITE, OPTIONS or other), or of a new type specific to the implementation of the present invention.
  • the "From" header indicates the identity of the ISDN access to which the forwarded information applies.
  • This identity may correspond, according to the operator policies, to a line identifier (according to the format isdn-accessid @ operator ms.com) in accordance with the specification ETSI TS 183 043, or to a routable public identity such as an IMPU (initials of the English words "IP Multimedia Public Identity"), according to the global format number@operator.ims.com, such as +33296123456@operator.ims.com.
  • the notifier may be configured to issue NOTIFY messages to a designated recipient (s).
  • the configuration may be more specific and apply for example only to a subset of the resources managed by the notifier and / or to a subset of the state information.
  • the notifier may be configured with the identity of the recipient (AS, S-CSCF, and so on); alternatively, it will use the domain name of the recipient's attachment network, in which case it will be up to the IMS heart to route the notification messages correctly.
  • the notifier may be configured with the list of ISDN accesses for which supervision is requested; alternatively, it may provide a supervision of all ISDN access, or a lack of supervision.
  • the subscriber may indicate in the header "To" and / or the "Request-URI” the identity (line identifier or routable public identity) of the ISDN access for which supervision is requested.
  • the header "To” and / or the "Request-URI” may contain the temporary public identity used in group registration ("Group Registration") in accordance with ETSI TS 183 043; in this case, all ISDN accesses implicitly associated with the group will be supervised.
  • the subscriber may optionally indicate in the body of the subscription message the list of states for which he wishes to be notified: states of type "user”, “network”, “grading” (as described above), or any combination of these states; we can foresee that, by default, if the list of states is not specified, it is the set of states that will be subscribed.
  • the ISDN access concerned in this example is identified by the French public identity 02 96 05 1 1 1 1.
  • the subscriber, myAS@operator.ims.com, indicates that he wants to be notified for "network” and "grading" events only.
  • EventCategory Network Grading 2 Notification to the requesting device to inform it of a defect in the digital operator section
  • the implementation of the invention within the nodes of a telecommunications network can be achieved by means of software and / or hardware components.
  • the software components can be integrated into a typical network node management computer program. Therefore, as indicated above, the present invention also relates to a computer system.
  • This computer system conventionally comprises a central processing unit controlling signals by a memory, as well as an input unit and an output unit.
  • this computer system can be used to execute a computer program comprising instructions for implementing the incident notification method according to the invention.
  • the invention also relates to a downloadable computer program from a communication network comprising instructions for executing the steps of an incident notification method according to the invention, when it is executed on a computer .
  • This computer program may be stored on a computer readable medium and may be executable by a microprocessor.
  • This program can use any programming language, and present itself as source code, object code, or intermediate code between source code and object code, in a partially compiled form or in any other desirable form.
  • the invention also relates to a computer-readable information medium, comprising instructions of a computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a USB flash drive ("USB flash drive"). in English) or a hard drive.
  • the information 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.
  • the computer program according to the invention can in particular be downloaded to an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the incident notification method according to the invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention concerne un procédé de notification d'incident sur un accès RNIS raccordé à un réseau IP. Ce procédé comprend les étapes suivantes : détection dudit incident par un dispositif de raccordement dudit accès RNIS audit réseau IP; et envoi par ledit dispositif de raccordement d'un message de contrôle de session à un dispositif, dit demandeur, du réseau IP, ayant préalablement souscrit auprès du dispositif de raccordement, de manière explicite ou implicite, à la notification d'au moins une information d'état de l'accès RNIS.

Description

NOTIFICATION D'INCIDENT SUR UN ACCES RNIS RACCORDE A UN RESEAU IP
La présente invention concerne les Réseaux Numériques à Intégration de Services, ou RNIS (« Integrated Services Digital Network » ou ISDN en anglais).
Plus précisément, la présente invention concerne le raccordement d'un accès RNIS à un réseau de télécommunications de type IP (« Internet Protocol »).
On rappelle que le Réseau Téléphonique Commuté (RTC) (en anglais « Switched Téléphone Network » ou STN), et en particulier le réseau téléphonique commuté public RTCP (en anglais, PSTN), est un réseau de téléphonie fixe dans lequel un terminal analogique ou une installation numérique sont raccordés à un central téléphonique par une ou plusieurs paires torsadées de fils de cuivre alimentés par le réseau, l'ensemble constituant ce qu'on appelle la « boucle locale ». Les centraux téléphoniques sont eux-mêmes reliés entre eux par des liens à haut débit. Les terminaux téléphoniques analogiques ou numériques peuvent être de diverses sortes, par exemple un téléphone individuel (poste d'abonné), un publiphone, ou un PABX (initiales des mots anglais « Private Automatic Branch eXchange » signifiant « autocommutateur téléphonique privé ») qui sert principalement à relier les postes téléphoniques d'un établissement (lignes « internes ») avec le réseau téléphonique public (lignes « externes »).
On rappelle également que les protocoles de contrôle de session évolués classiques, tels que les protocoles H.323 et SIP (« Session Initiation Protocol »), utilisent des messages dits « messages de signalisation » pour permettre à un terminal de demander une connexion avec un autre terminal, ou également des messages signalant qu'une ligne téléphonique est occupée, ou signalant que le téléphone appelé sonne, ou encore signalant que tel téléphone est connecté au réseau et peut être joint de telle ou telle manière. Lorsqu'un client enregistré sur un réseau utilisant un protocole de contrôle de session évolué souhaite bénéficier d'un service multimédia offert par le réseau, il émet vers le réseau un message de signalisation précisant sa requête.
Le protocole H.323 a été mis au point par l'UIT-T. Il spécifie des procédures concernant la signalisation, la négociation de codeur- décodeur, et le transport de l'information. Il est largement utilisé par les fabricants d'équipements vocaux et de conférences vidéo, ainsi que dans plusieurs applications Internet en temps-réel telles que « NetMeeting ».
Le protocole SIP a été défini par NETF dans le document RFC 3261 . Ce protocole permet l'établissement, la modification et la terminaison de sessions multimédia dans un réseau utilisant le protocole IP. Le protocole SIP permet également des procédures de notification d'événements et l'envoi d'informations en dehors du contexte d'une session. Il est largement utilisé pour des commandes de services de messagerie instantanée. Ainsi, dans un environnement SIP, il existe différents types de communications telles que des requêtes d'établissement de sessions et des requêtes échangées hors de tout dialogue.
L'invention convient bien en particulier aux infrastructures de type IMS (« IP Multimedia Subsystem »). L'IMS a été défini par les organismes de normalisation 3GPP (« 3rd Génération Partnership Project ») et TISPAN (« Télécommunications and Internet Converged Services and Protocols for Advanced Networking »). C'est une architecture de réseau introduite par le 3GPP pour les réseaux mobiles, puis reprise par TISPAN pour les réseaux fixes. Cette architecture, qui utilise le protocole SIP, permet l'établissement dynamique et le contrôle de sessions multimédia entre deux clients ainsi que la réservation des ressources au niveau du réseau de transport des flux multimédias. Grâce à cette architecture, les opérateurs réseau peuvent commodément mettre en œuvre une politique de gestion, fournir une Qualité de Service prédéterminée, et calculer les montants à facturer aux clients. L'IMS permet actuellement d'accéder à des services de type téléphonie, visiophonie, présence et messagerie instantanée, dont elle gère aussi l'interaction.
Les opérateurs téléphoniques ont commencé la migration de leur réseau de commutation téléphonique vers des réseaux dits de « Voix sur IP » (en anglais, « Voice over IP ») ou VoIP, qui permettent la diffusion de données conversationnelles (voix et fax). Alors que le parc des abonnés RTC traditionnels est en décroissance, celui des abonnés VoIP, qui ont souscrit à une offre de services groupés (Internet/TV/téléphonie illimitée), est en forte croissance. Ces abonnés VoIP sont (ou seront) raccordés à des cœurs de réseau IMS, tandis que les abonnés RTC sont actuellement quant à eux raccordés à des autocommutateurs temporels dans les centraux téléphoniques par le biais d'Unités de Raccordement d'Abonnés (URA) (un « autocommutateur temporel » opère sur des signaux multiplexés dans le temps). Dans ces circonstances, les opérateurs doivent exploiter parallèlement deux réseaux différents, ce qui multiplie les coûts d'exploitation et de maintenance.
II est donc apparu souhaitable de faire converger ces réseaux sans pour autant remplacer les terminaux du parc RTC (en raison de l'attachement de nombre de clients à leur ligne téléphonique classique, et des dépenses que leur remplacement entraînerait), d'où la notion « d'émulation du RTC ». Les abonnés RTC sont alors raccordés à de nouveaux types d'URA qui réalisent l'adaptation protocolaire de signalisation d'appel pour la communication avec le cœur IMS, ainsi que l'encodage/décodage des flux média : dans le cadre de la présente invention, ces nouveaux types d'URA seront appelés « URA-SIP ». Comme exemples de ces URA-SIP, on trouve d'une part les passerelles domestiques et les passerelles situées dans des entreprises (« Residential Gateways » en anglais), et d'autre part les passerelles situées dans le réseau d'un opérateur (« Voice Gateways » en anglais) telles que les DSLAM-SIP ou DSLAM-H.248 (DSLAM sont les initiales des mots anglais « Digital Subscriber Line Access Multiplexer » signifiant « multiplexeur d'accès de lignes d'abonnés numériques » ; il s'agit de dispositifs qui collectent le trafic de données DSL transitant sur un certain nombre de lignes téléphoniques).
Cette convergence concerne également les abonnés aux services de type RNIS. Comme expliqué dans l'encyclopédie en ligne « Wikipedia », un accès RNIS offre des liaisons numériques s'appuyant sur la qualité du RTC, et offrant des débits pouvant atteindre 2 Mbit/s. Le RNIS combine la large couverture géographique d'un réseau téléphonique avec la capacité de transport d'un réseau de données véhiculant la voix, les données et la vidéo. Avec le RNIS, par exemple, les sites régionaux et internationaux de petite taille peuvent se connecter aux réseaux d'entreprises à un coût mieux adapté à la consommation réelle qu'avec des lignes spécialisées. Un abonné peut ainsi demander des liaisons RNIS soit pour remplacer des lignes spécialisées, soit en complément pour augmenter la bande passante ou assurer une redondance.
L'Union Internationale des Télécommunications (UIT) a défini la technologie RNIS de manière à ce qu'elle puisse fournir une connectivité numérique avec une grande variété de services. Deux caractéristiques importantes permettent au RTC d'évoluer pour offrir les services RNIS :
• les connexions doivent pouvoir être numériques de bout en bout ; et
• le réseau doit offrir un jeu de protocoles d'interface utilisateur/réseau conforme aux standards RNIS ; de cette façon, tous les équipements RNIS utilisent les mêmes connexions physiques et les mêmes protocoles de signalisation pour accéder aux services. Dans un réseau téléphonique analogique, la boucle locale autorise un canal de transmission unique ; ce canal ne traite qu'un seul service à tout moment donné : la voix ou les données. Avec le RNIS, la boucle locale (comprenant une ou deux paires de fils torsadées) est divisée en plusieurs canaux logiques, appelés B et D, que l'on distingue par leurs fonctions et leurs débits. En outre, on peut utiliser deux types d'accès, caractérisés par leurs nombres respectifs de canaux B et D : l'accès de base S0/T0 (« Basic Rate Access » ou BRA en anglais), et l'accès primaire S2/T2 (« Primary Rate Access » ou PRA en anglais). Il est naturellement très important que les accès RNIS puissent garantir un transport sans erreur de bout en bout des informations numériques.
Dans le cas d'une installation RNIS connectée au RTC, afin de garantir la haute disponibilité et la haute qualité du service RNIS, l'opérateur procède régulièrement à des tests préventifs qui utilisent des mécanismes de re-bouclages, ainsi qu'à des procédures de calcul de taux d'erreur (grâce aux mécanismes de contrôle de redondance cyclique - CRC - spécifiés dans la couche physique support du RNIS). Ces procédures de maintenance sont décrites dans les normes ITU-T 1.430 pour l'accès de base (ISDN BRA), et ITU-T 1.431 pour l'accès primaire (ISDN PRA).
Si à l'issue de ces tests, ou suite à un incident (rupture ou altération du câble, défaut d'alimentation, et ainsi de suite), l'accès RNIS est jugé défectueux, l'interface peut alors être déclarée hors service et l'opérateur est tenu (contractuellement, le plus souvent) de remédier au plus vite aux défauts observés. Si le défaut est localisé dans l'installation-client, la signalisation d'incident et l'intervention de l'opérateur ne sont requises que sous conditions (généralement seulement pour l'accès RNIS primaire, et sous conditions de contrat).
Considérons à présent le cas d'une installation RNIS raccordée à un réseau IP. La figure 1 illustre schématiquement, à titre d'exemple, le raccordement d'un accès RNIS à un réseau IP, pour un accès de base (ISDN BRA) ou un accès primaire (ISDN PRA), via un dispositif de raccordement 1 constitué par une URA-SIP ou par un ensemble constitué d'une passerelle H.248 et d'une entité intermédiaire du réseau, comme l'AGCF (initiales des mots anglais « Access Gateway Control Function » signifiant Fonction de Contrôle de Passerelle d'Accès). Pour simplifier la figure, le reste du réseau IP n'est pas représenté.
Sur cette figure :
• le port de connexion de l'accès RNIS à l'URA-SIP est noté « LT » (initiales des mots anglais « Line Termination ») ;
• l'interface de raccordement de l'installation-client à l'accès RNIS est notée « T » ; à l'extrémité associée de l'accès RNIS se trouve un équipement noté « NT1 » (initiales des mots anglais « Network Termination 1 ») ; l'équipement NT1 est aussi communément appelé TNR (pour « Terminaison Numérique de Réseau » dans les accès RNIS français) dans le cas des raccordements d'accès de base ; et
• l'équipement-client proprement dit est noté « TE » (initiales des mots anglais « Terminal Equipment »).
On distingue ainsi plusieurs sections :
• la « section numérique d'opérateur » (« Network Digital Section » en anglais), située entre le port LT et l'interface T ; cette section est sous la responsabilité de l'opérateur ; et
• la « section numérique d'usager » (« User Digital Section » en anglais), située entre l'interface T et l'équipement-client TE ; cette section est généralement sous la responsabilité de l'usager, mais peut faire l'objet d'une supervision particulière par l'opérateur de réseau, notamment dans le cas de l'accès primaire (ISDN PRA) mentionné ci-dessus. La figure 2 illustre schématiquement, comme autre exemple, le raccordement d'un accès RNIS primaire (ISDN PRA) à un réseau IP via un dispositif de raccordement 1 constitué par une passerelle de transit (« Trunking Gateway » ou TGW en anglais). Pour simplifier la figure, le reste du réseau IP n'est pas représenté.
Sur cette figure :
• le port de connexion de l'accès RNIS à la TGW est noté « LT » ;
• le point de raccordement de l'installation-client à l'accès RNIS est noté « T2 » ; à l'extrémité associée de l'accès RNIS se trouve un équipement noté « NT1 » ; à l'extrémité associée de l'installation d'abonnés se trouve un PABX noté « NT2 » ; et
• les équipements-client proprement dits sont notés « TE », et sont connectés au PABX via une interface notée « S0/T0 ».
On distingue ainsi plusieurs sections :
· la « section numérique d'opérateur » (« Network Digital Section »), située entre le port LT et le point de raccordement T2 ; cette section est sous la responsabilité de l'opérateur, et bénéficie d'un accès primaire (ISDN PRA) ; et
• la « section numérique d'usager » (« User Digital Section »), située entre le point de raccordement T2 et les équipements-client TE ; cette section est sous la responsabilité du, ou des usager(s), et bénéficie, dans cet exemple, d'un accès de base (ISDN BRA).
De manière générale pour les accès RNIS raccordés à un réseau IP, tels que ceux représentés sur ces figures à titre d'exemples, il n'est pas possible d'indiquer au dispositif de traitement d'appel la nature d'un défaut lorsqu'il est détecté, de manière à discerner si ce défaut est localisé dans la section-opérateur (intervention immédiate requise) ou dans la section-usager (intervention conditionnelle). La norme TISPAN TS 183 036, qui spécifie l'interfonctionnement entre le protocole DSS.1 RNIS et le protocole SIP ne prévoit en effet qu'un seul code d'erreur à l'interface SIP, ledit code (émission d'un BYE/CANCEL avec « Reason Header » contenant une valeur de cause 27 « Destination out of order ») couvrant différents cas sans distinction.
Même si l'on avait recours à des codes d'erreurs différenciés, il ne serait possible, avec la méthode ci-dessus, de communiquer l'information de localisation du défaut que lors d'une tentative d'établissement de session à destination de l'équipement client, ou lors de la rupture d'une session déjà établie (émission de BYE ou CANCEL seulement).
Ces limitations rendent impossible, par exemple, la signalisation préventive d'erreur ou de dégradation suite à des tests de maintenance, et rendent également impossible la détection d'erreur pour des accès « spécialisés départ » (dans lesquels l'abonné peut émettre des appels mais ne peut pas en recevoir).
Il est également impossible pour un opérateur de requérir la mise sous tests d'une section numérique d'usager et/ou d'une section numérique d'opérateur, et tout autant de suspendre un test en cours en cas d'appel entrant ou sortant.
Le besoin de disposer d'un mécanisme permettant de localiser avec précision une erreur dans la section-opérateur est particulièrement important lorsque l'opérateur de l'accès RNIS (exploitant un DSLAM par exemple) et l'opérateur de service (en charge du contrôle d'appel et offrant un service au client) sont différents, comme c'est le cas dans certains réseaux : en effet, il est alors nécessaire de clairement départager et identifier les responsabilités de chacun. De plus, dans ce cas, l'opérateur de service n'a pas - contrairement à l'opérateur réseau - la possibilité d'interroger le dispositif de raccordement pour obtenir des informations concernant l'état de l'accès RNIS.
La présente invention concerne donc un procédé de notification d'incident sur un accès RNIS raccordé à un réseau IP. Ce procédé est remarquable en ce qu'il comprend les étapes suivantes : - détection dudit incident par un dispositif de raccordement dudit accès RNIS audit réseau IP, et
- envoi par ledit dispositif de raccordement d'un message de contrôle de session à un dispositif, dit demandeur, du réseau IP, ayant préalablement souscrit auprès du dispositif de raccordement, de manière explicite ou implicite, à la notification d'au moins une information d'état de l'accès RNIS.
Grâce à l'invention, la gestion d'un accès RNIS par un opérateur est considérablement améliorée grâce à la mise à disposition automatique d'informations d'état concernant cet accès RNIS. Comme expliqué ci- dessus, cela est particulièrement avantageux dans le cas où le dispositif demandeur des informations d'état est un opérateur de services distinct de l'opérateur de l'accès RNIS.
Cette mise à disposition d'informations permet donc à un opérateur de réagir rapidement et de mettre en œuvre une action de réparation appropriée, de façon à réduire au minimum la durée d'indisponibilité de service pour les clients RNIS.
Selon des caractéristiques particulières, ladite information d'état concerne avantageusement :
- un défaut constaté, ou une dégradation de qualité constatée, ou encore une absence de défaut, dans la section numérique d'usager de l'accès RNIS, et/ou
- un défaut constaté, ou une dégradation de qualité constatée, ou encore une absence de défaut, dans la section numérique d'opérateur de l'accès RNIS.
On peut ainsi, en particulier, signaler une dégradation d'une partie de l'accès RNIS sans pour autant interdire les appels ou provoquer un dés-enregistrement de l'usager.
Selon d'autres caractéristiques particulières, ledit message de contrôle de session contient un en-tête (« header » en anglais) spécifique associé à la souscription à ladite information d'état (dans le cadre de l'invention, un « en-tête » désigne une ligne spécifique dans un message de contrôle de session).
Grâce à ces dispositions, l'invention ne nécessite qu'une extension modeste des protocoles de contrôle de session (SIP, ou autre).
Corrélativement, l'invention concerne divers dispositifs.
Elle concerne ainsi, premièrement, un dispositif de raccordement d'un accès RNIS à un réseau IP. Ce dispositif de raccordement est remarquable en ce qu'il possède des moyens pour :
- détecter un incident sur ledit accès RNIS, et
- envoyer un message de contrôle de session à un dispositif, dit demandeur, dudit réseau IP, ayant préalablement souscrit auprès dudit dispositif de raccordement, de manière explicite ou implicite, à la notification d'au moins une information d'état de l'accès RNIS.
Elle concerne aussi, deuxièmement, un dispositif, dit demandeur, d'un réseau IP. Ce dispositif demandeur est remarquable en ce qu'il possède des moyens pour :
- souscrire, de manière explicite ou implicite, à la notification d'au moins une information d'état d'un accès RNIS auprès d'un dispositif de raccordement dudit accès RNIS audit réseau IP, et
- recevoir, de la part dudit dispositif de raccordement, un message de contrôle de session suite à la détection par le dispositif de raccordement d'un incident sur l'accès RNIS.
Selon des caractéristiques particulières de ces deux dispositifs, ladite information d'état concerne :
- un défaut constaté, ou une dégradation de qualité constatée, ou encore une absence de défaut, dans la section numérique d'usager de l'accès RNIS, et/ou - un défaut constaté, ou une dégradation de qualité constatée, ou encore une absence de défaut, dans la section numérique d'opérateur de l'accès RNIS.
Les avantages offerts par ces dispositifs sont essentiellement les mêmes que ceux offerts par les procédés corrélatifs succinctement exposés ci-dessus.
On notera qu'il est possible de réaliser les dispositifs succinctement décrits ci-dessus dans le contexte d'instructions logicielles et/ou dans le contexte de circuits électroniques.
L'invention vise également un programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Ce programme d'ordinateur est remarquable en ce qu'il comprend des instructions pour l'exécution des étapes de l'un quelconque des procédés de notification d'incident succinctement exposés ci-dessus, lorsqu'il est exécuté sur un ordinateur.
Les avantages offerts par ce programme d'ordinateur sont essentiellement les mêmes que ceux offerts par lesdits procédés.
D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-dessous de modes de réalisation particuliers, donnés à titre d'exemples non limitatifs. La description se réfère aux figures qui l'accompagnent, déjà décrites ci-dessus, dans lesquelles :
- la figure 1 représente schématiquement le raccordement d'un accès RNIS à un réseau IP via une URA-SIP, et
- la figure 2 représente schématiquement le raccordement d'un accès RNIS à un réseau IP via une passerelle de transit.
On va maintenant illustrer le fonctionnement et les avantages de l'invention dans le cadre de divers modes de réalisation. On rappelle que la norme RFC 3265 de l'IETF {Internet Engineering Task Force) définit, de manière générale, un mécanisme de souscription/notification appelé « événement » (« event package » en anglais). L'invention propose un nouveau type d'événement, qui sera appelé « DigitalSection-supervision » ci-après.
Selon l'invention, un dispositif 2 d'un réseau IP, demandeur d'informations d'état d'un accès RNIS raccordé au réseau IP, souscrit, de manière explicite ou implicite, à la notification de ces informations auprès d'un dispositif de raccordement 1 de l'accès RNIS au réseau IP.
Ce dispositif de raccordement 1 , superviseur et générateur des informations d'état, peut être, par exemple (cf. description des figures 1 et 2 ci-dessus), une URA-SIP (passerelle domestique, passerelle d'entreprise, passerelle d'opérateur telle qu'un DSLAM-SIP ou DSLAM- H248, éventuellement associée à un AGCF, et ainsi de suite) ou une passerelle de transit TGW.
Dans le cas où le réseau IP est de type IMS, le dispositif demandeur 2 peut être, notamment :
• un serveur AS (initiales des mots anglais « application server » signifiant « serveur d'applications ») tel qu'un serveur de messagerie vocale, un serveur de présence ou un serveur de téléphonie,
• un serveur P-CSCF (initiales des mots anglais « Proxy-Call Server Control Function » signifiant « Fonction de Contrôle de Serveur d'Appels Mandataire ») (les serveurs P-CSCF servent de points de contact entre les terminaux d'usagers et le réseau IMS), ou
• un serveur S-CSCF (initiales des mots anglais « Serving-Call Server Control Function » signifiant « Fonction de Contrôle de Serveur d'Appels de Service ») (les serveurs S-CSCF gèrent la procédure d'enregistrement des terminaux d'usagers, ainsi que le routage de la signalisation issue, ou à destination, de ces terminaux d'usagers), ou encore
• un serveur IBCF (initiales des mots anglais « Interconnection Border Control Function » signifiant Fonction de Contrôle de Frontière d'Interconnexion) (les serveurs IBCF servent de passerelles vers des réseaux externes, et jouent notamment le rôle de pare-feu).
Les états de l'accès RNIS dont la notification peut être utile sont notamment les suivants :
- l'état « user interface failure » indique un défaut constaté dans la section numérique d'usager de l'accès RNIS ;
- l'état « network interface failure » indique un défaut constaté dans la section numérique d'opérateur de l'accès RNIS ;
- l'état « normal condition at user interface » indique une absence de défaut dans la section numérique d'usager (retour : condition normale) ;
- l'état « normal condition at network interface » indique une absence de défaut dans la section numérique d'opérateur (retour : condition normale) ; et
- l'état « grading » indique une dégradation de qualité constatée dans la section numérique d'opérateur ; ce type de dégradation permet d'écouler les appels, mais peut déclencher des opérations de maintenance ; les conditions de déclenchement de la notification de ces états dépendent de la politique de qualité de l'opérateur de l'accès RNIS (franchissement d'un seuil de taux d'erreurs, par exemple).
Les informations d'état selon l'invention peuvent être véhiculées dans un nouvel en-tête {« header »), que l'on appellera par exemple « DigitalSection-Supervision ». La « méthode », c'est-à-dire le type de message de contrôle de session qui véhiculera ce nouveau header pourra être d'un type classique (par exemple NOTIFY, INFO, MESSAGE, INVITE, OPTIONS ou autre), ou d'un type nouveau spécifique à la mise en œuvre de la présente invention.
Dans le cas d'un réseau utilisant le protocole SIP, l'en-tête « From » indique l'identité de l'accès RNIS auquel s'applique l'information remontée. Cette identité pourra correspondre, suivant les politiques opérateurs, à un identifiant de ligne (selon le format isdn-access- id@operator ms.com) conformément à la spécification ETSI TS 183 043, ou à une identité publique routable telle qu'une IMPU (initiales des mots anglais « IP Multimedia Public Identity »), selon le format global number@operator.ims.com, comme par exemple +33296123456@operator.ims.com.
Dans le cas d'une souscription implicite aux informations d'état, il n'y a pas de requête de souscription associée (pas de message SUBSCRIBE). Le notifieur pourra être configuré pour émettre des messages NOTIFY vers un (ou des) destinataires désigné(s). La configuration peut être plus spécifique et ne s'appliquer par exemple qu'à un sous-ensemble des ressources gérées par le notifieur et/ou à un sous- ensemble des informations d'état. Le notifieur pourra être configuré avec l'identité du destinataire (AS, S-CSCF, et ainsi de suite) ; en variante, il utilisera le nom de domaine du réseau d'attachement du destinataire, auquel cas il appartiendra au cœur IMS de router correctement les messages de notification. Par ailleurs, le notifieur pourra être configuré avec la liste des accès RNIS pour lesquels une supervision est demandée ; en variante, on pourra prévoir une supervision de tous les accès RNIS, ou une absence de supervision.
Dans le cas d'une souscription explicite, le souscripteur pourra indiquer dans l'en-tête « To » et/ou la « Request-URI » l'identité (identifiant de ligne ou identité publique routable) de l'accès RNIS pour lequel la supervision est demandée. En variante, l'en-tête « To » et/ou la « Request-URI » pourront contenir l'identité temporaire publique utilisée lors d'un enregistrement de groupe (« Group Registration » en anglais) conformément à la spécification ETSI TS 183 043 ; dans ce cas, l'ensemble des accès RNIS implicitement associés au groupe seront supervisés. Par ailleurs, le souscripteur pourra indiquer optionnellement dans le corps du message de souscription la liste des états pour lesquels il souhaite être notifié : états de type « user », « network », « grading » (tels que décrits ci-dessus), ou toute combinaison de ces états ; on pourra prévoir que, par défaut, si la liste des états n'est pas spécifiée, c'est l'ensemble des états qui sera souscrit.
Ces événements interagissent évidemment avec le traitement d'appel proprement dit, ainsi qu'avec le système d'information ; les détails de ces interactions sont à fixer par chaque opérateur.
On va donner à présent deux exemples de messages SIP échangés en relation avec l'invention. Dans un souci de simplification, les encodages proposés ci-dessous pour le corps de ces messages sont tous en format texte, mais l'on pourra naturellement, en variante, utiliser d'autres types d'encodage, par exemple en langage XML.
1 ) Souscription à l'événement « DigitalSection-Supervision »
L'accès RNIS concerné dans cet exemple est identifié par l'identité publique française 02 96 05 1 1 1 1 . Le souscripteur, myAS@operator.ims.com, indique vouloir être notifié pour les événements de type « network » et « grading » uniquement.
SUBSCRIBE sip: +33296051111 @operator . ims . com SIP/2.0
To : <sip: +33296051111@operator . ims . com >
From : <sip : myASSopérâtor . ims . com> ; tag=78923
Call-Id: [ ...]
CSeq: 1 SUBSCRIBE
Contact : [ ... ]
Event : DigitalSection-Supervision
Expires : [ ... ]
Accept : application/DigitalSection_Supervision-notification Content-Type : application/DigitalSection-Supervision- Notification
Content-Length : 31
EventCategory : Network Grading 2) Notification à destination du dispositif demandeur pour l'informer d'un défaut dans la section numérique d'opérateur
NOTIFY sip : myASgoperator . ims . corn SIP/2.0
To: [ ... ]
From: <sip: +33296051111@operator . ims . corn >;tag=78923
Contact : [ ... ]
Call-ID: [ ... ]
CSeq: 2 NOTIFY
Event : DigitalSection-Supervision
Subscription-State : active ; expires= [ ...]
Content-Type : application/DigitalSection-Supervision- Notification
Content-Length : 51
ISDN-Supervision-event : Network-interface-failure
On notera pour terminer que la mise en œuvre de l'invention au sein des nœuds d'un réseau de télécommunications (plus précisément, les dispositifs demandeurs et les dispositifs générateurs d'informations d'état concernant un accès RNIS) peut être réalisée au moyen de composants logiciels et/ou matériels.
Les composants logiciels pourront être intégrés à un programme d'ordinateur classique de gestion de nœud de réseau. C'est pourquoi, comme indiqué ci-dessus, la présente invention concerne également un système informatique. Ce système informatique comporte de manière classique une unité centrale de traitement commandant par des signaux une mémoire, ainsi qu'une unité d'entrée et une unité de sortie. De plus, ce système informatique peut être utilisé pour exécuter un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de notification d'incident selon l'invention.
En effet, l'invention vise aussi un programme d'ordinateur téléchargeable depuis un réseau de communication comprenant des instructions pour l'exécution des étapes d'un procédé de notification d'incident selon l'invention, lorsqu'il est exécuté sur un ordinateur. Ce programme d'ordinateur peut être stocké sur un support lisible par ordinateur et peut être exécutable par un microprocesseur. Ce programme peut utiliser n'importe quel langage de programmation, et se présenter en tant que code source, code objet, ou code intermédiaire entre code source et code objet, sous une forme partiellement compilée ou sous toute autre forme souhaitable.
L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
Le support d'informations 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 une clé USB (« USB flash drive » en anglais) ou un disque dur.
D'autre part, le support d'informations 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. Le programme d'ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
En variante, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé de notification d'incident selon l'invention.

Claims

R E V E N D I C A T I O N S
1 . Procédé de notification d'incident sur un accès RNIS raccordé à un réseau IP, caractérisé en ce qu'il comprend les étapes suivantes :
- détection dudit incident par un dispositif de raccordement (1 ) dudit accès RNIS audit réseau IP, et
- envoi par ledit dispositif de raccordement (1 ) d'un message de contrôle de session à un dispositif (2), dit demandeur, du réseau IP, ayant préalablement souscrit auprès du dispositif de raccordement (1 ), de manière explicite ou implicite, à la notification d'au moins une information d'état de l'accès RNIS.
2. Procédé de notification d'incident selon la revendication 1 , caractérisé en ce que ladite information d'état concerne :
- un défaut constaté, ou une dégradation de qualité constatée, ou encore une absence de défaut, dans la section numérique d'usager de l'accès RNIS, et/ou
- un défaut constaté, ou une dégradation de qualité constatée, ou encore une absence de défaut, dans la section numérique d'opérateur de l'accès RNIS.
3. Procédé de notification d'incident selon la revendication 1 ou la revendication 2, caractérisé en ce que ledit message de contrôle de session contient un en-tête spécifique (DigitalSection-Supervision) associé à la souscription à ladite information d'état.
4. Dispositif de raccordement (1 ) d'un accès RNIS à un réseau IP, caractérisé en ce qu'il possède des moyens pour :
- détecter un incident sur ledit accès RNIS, et
- envoyer un message de contrôle de session à un dispositif (2), dit demandeur, dudit réseau IP, ayant préalablement souscrit auprès dudit dispositif de raccordement (1 ), de manière explicite ou implicite, à la notification d'au moins une information d'état de l'accès RNIS.
5. Dispositif de raccordement (1 ) selon la revendication 4, caractérisé en ce que ladite information d'état concerne :
- un défaut constaté, ou une dégradation de qualité constatée, ou encore une absence de défaut, dans la section numérique d'usager de l'accès RNIS, et/ou
- un défaut constaté, ou une dégradation de qualité constatée, ou encore une absence de défaut, dans la section numérique d'opérateur de l'accès RNIS.
6. Dispositif de raccordement (1 ) selon la revendication 4 ou la revendication 5, caractérisé en ce qu'il appartient au groupe comprenant une passerelle domestique, une passerelle d'entreprise, une passerelle d'opérateur, et une passerelle de transit.
7. Dispositif (2), dit demandeur, d'un réseau IP, caractérisé en ce qu'il possède des moyens pour :
- souscrire, de manière explicite ou implicite, à la notification d'au moins une information d'état d'un accès RNIS auprès d'un dispositif de raccordement (1 ) dudit accès RNIS audit réseau IP, et
- recevoir, de la part dudit dispositif de raccordement (1 ), un message de contrôle de session suite à la détection par le dispositif de raccordement (1 ) d'un incident sur l'accès RNIS.
8. Dispositif demandeur (2) selon la revendication 7, caractérisé en ce que ladite information d'état concerne :
- un défaut constaté, ou une dégradation de qualité constatée, ou encore une absence de défaut, dans la section numérique d'usager de l'accès RNIS, et/ou
- un défaut constaté, ou une dégradation de qualité constatée, ou encore une absence de défaut, dans la section numérique d'opérateur de l'accès RNIS.
9. Dispositif demandeur (2) selon la revendication 7 ou la revendication 8, caractérisé en ce que, ledit réseau IP étant de type IMS, ledit dispositif demandeur (2) appartient au groupe comprenant un serveur d'applications (AS), un serveur P-CSCF, un serveur S-CSCF, et un serveur IBCF.
10. Moyen de stockage de données inamovible, ou partiellement ou totalement amovible, comportant des instructions de code de programme informatique pour l'exécution des étapes d'un procédé de notification d'incident selon l'une quelconque des revendications 1 à 3.
1 1 . Programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions pour l'exécution des étapes d'un procédé de notification d'incident selon l'une quelconque des revendications 1 à 3, lorsqu'il est exécuté sur un ordinateur.
EP11737992.5A 2010-06-24 2011-06-20 Notification d'incident sur un acces rnis raccorde a un reseau ip Withdrawn EP2586214A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1055049A FR2961987A1 (fr) 2010-06-24 2010-06-24 Procede de notification d'incident sur un acces rnis raccorde a un reseau ip
PCT/FR2011/051408 WO2011161365A1 (fr) 2010-06-24 2011-06-20 Notification d'incident sur un acces rnis raccorde a un reseau ip

Publications (1)

Publication Number Publication Date
EP2586214A1 true EP2586214A1 (fr) 2013-05-01

Family

ID=42985476

Family Applications (1)

Application Number Title Priority Date Filing Date
EP11737992.5A Withdrawn EP2586214A1 (fr) 2010-06-24 2011-06-20 Notification d'incident sur un acces rnis raccorde a un reseau ip

Country Status (3)

Country Link
EP (1) EP2586214A1 (fr)
FR (1) FR2961987A1 (fr)
WO (1) WO2011161365A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114884754B (zh) * 2022-07-11 2022-09-23 深圳特科动力技术有限公司 一种智能分析来实现故障预知的网络安防系统

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
USH1964H1 (en) * 1997-09-26 2001-06-05 Dsc/Celcore, Inc. Resource management sub-system of a telecommunications switching system
US6704287B1 (en) * 1999-02-26 2004-03-09 Nortel Networks Limited Enabling smart logging for webtone networks and services
CN101502076B (zh) * 2006-08-10 2012-09-05 诺基亚公司 与媒体后退进行交互工作
FR2960511B1 (fr) 2010-06-01 2012-05-04 Renault Sa Systeme de reglage de la configuration de position d'un organe de support d'une structure de support d'une caisse de vehicule automobile

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2011161365A1 *

Also Published As

Publication number Publication date
WO2011161365A1 (fr) 2011-12-29
FR2961987A1 (fr) 2011-12-30

Similar Documents

Publication Publication Date Title
EP2504982B1 (fr) Procede de basculement d&#39;un hss primaire sur un hss de secours dans un reseau ip
WO2008040614A2 (fr) Marqueur pour systemes de communication composes d&#39;une pluralite de serveurs sip
US8325905B2 (en) Routing calls in a network
EP3085065B1 (fr) Procédé de mise a jour dynamique d&#39;informations obtenues de la part d&#39;un serveur dns
EP2396950B1 (fr) Procede et systeme de gestion de la signalisation dans un reseau de telecommunications
EP2449745B1 (fr) Procédé de sélection d&#39;une ressource réseau
EP3158709B1 (fr) Sélection dynamique par un appelant parmi une pluralité de terminaux d&#39;un appelé
FR2998991A1 (fr) Routage d&#39;une requete de service visant un abonne ims
WO2011161365A1 (fr) Notification d&#39;incident sur un acces rnis raccorde a un reseau ip
WO2020128258A1 (fr) Procédé de basculement d&#39;une communication de tcp sur udp
EP3646578B1 (fr) Procédé de synchronisation d&#39;état média
FR2969453A1 (fr) Procede de localisation et d&#39;identification d&#39;un abonne connecte a un reseau emulant le rtc/rnis
EP3225006B1 (fr) Procédé de négociation de codecs dans les réseaux ip
EP2801178B1 (fr) Procédé dynamique de détermination d&#39;une liste de services dans un réseau sip
WO2011117513A1 (fr) Procedes et dispositifs de contrôle de passerelles media
FR2968153A1 (fr) Procede contre la formation de boucles dans les renvois d&#39;appel
WO2010149915A1 (fr) Procédé d&#39;émulation des signaux de boucle
WO2012049404A1 (fr) Procede de traitement des flux de presence dans un reseau sip
EP2449746A1 (fr) Supervision de qualite de communication dans une passerelle d&#39;un reseau de telecommunication
FR2974964A1 (fr) Continuite de service inter-terminal dans un reseau de telecommunications

Legal Events

Date Code Title Description
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

17P Request for examination filed

Effective date: 20130122

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

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

DAX Request for extension of the european patent (deleted)
GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

RIC1 Information provided on ipc code assigned before grant

Ipc: H04Q 11/04 20060101AFI20150407BHEP

Ipc: H04L 29/06 20060101ALI20150407BHEP

Ipc: H04L 12/24 20060101ALI20150407BHEP

INTG Intention to grant announced

Effective date: 20150508

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20150919