FR2961987A1 - Procede de notification d'incident sur un acces rnis raccorde a un reseau ip - Google Patents

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

PROCEDE DE 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 (« lntegrated 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 Telephone 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. II 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 I'IETF 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 Generation Partnership Project ») et TISPAN (« Telecommunications 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 oeuvre 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 coeurs 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.

Il 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 coeur 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 SO/TO (« 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 I'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 « SO/TO ». 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). II 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 30 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 oeuvre 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 30 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 5 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 : 10 - 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. 15 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 20 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, 25 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 25 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 DSLAMH248, é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-Cail 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 oeuvre 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-accessid@operator.ims.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 ldentity »), 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 coeur 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 11 11. 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 25 To: <sip: +33296051111@operator.ims.com From: <sip:myAS@operator.ims.com>;tag=78923 Cali Id: [ ...] CSeq: 1 SUBSCRIBE Contact: [ ...] 30 Event: DigitalSection-Supervision Expires:[ ] Accept: application/DigitalSection_Supervision-notification Content-Type: application/DigitalSection-Supervision-Notification 35 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:myAS@operator.ims.com SIP/2.0 To: [ ...] From: <sip: +33296051111@operator.ims.com >;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 oeuvre de l'invention au sein des noeuds 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 noeud 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 oeuvre 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 (11)

1. REVENDICATIONS1. 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 5 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 10 d'état de l'accès RNIS.
2. 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 15 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. 3. Procédé de notification d'incident selon la revendication 1 ou la 20 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. 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 : 25 - 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. 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. 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. 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. 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. 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. 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.
11. 11. 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.