Manuel du Système mondial de télécommunications

Transcription

Manuel du Système mondial
de télécommunications
www.wmo.int
OMM-N° 386
Volume I
(Annexe III du Règlement technique de l’OMM)
Aspects mondiaux
OMM-N° 386
édition 2009
OMM-N° 386
© Organisation météorologique mondiale, 2009
L’OMM se réserve le droit de publication en version imprimée ou électronique ou sous toute autre forme et dans
n’importe quelle langue. De courts extraits des publications de l’OMM peuvent être reproduits sans autorisation,
pour autant que la source complète soit clairement indiquée. La correspondance relative au contenu rédactionnel et
les demandes de publication, reproduction ou traduction partielle ou totale de la présente publication doivent être
adressées au:
Président du Comité des publications
Organisation météorologique mondiale (OMM)
7 bis, avenue de la Paix
Case postale 2300
CH-1211 Genève 2, Suisse
Tél.: +41 (0) 22 730 84 03
Fax.: +41 (0) 22 730 80 40
Courriel: [email protected]
ISBN 978-92-63-20386-1
NOTE
Les appellations employées dans les publications de l’OMM et la présentation des données qui y figurent n’impliquent, de la
part du Secrétariat de l’Organisation météorologique mondiale, aucune prise de position quant au statut juridique des pays,
territoires, villes ou zones, ou de leurs autorités, ni quant au tracé de leurs frontières ou limites.
Les opinions exprimées dans les publications de l’OMM sont celles de leurs auteurs et ne reflètent pas nécessairement
celles de l’OMM. De plus, la mention de certaines sociétés ou de certains produits ne signifie pas que l’OMM les cautionne
ou les recommande de préférence à d’autres sociétés ou produits de nature similaire dont il n’est pas fait mention ou qui ne
font l’objet d’aucune publicité.
TABLE DES MATIèRES
Page
introduction..................................................................................................................................... v
PartIE I — Organisation du Système mondial de télécommunications....................... I-1
1. Fonctions, organisation et principes du Système mondial de télécommunications............................. I-1
2. Fonctions et responsabilités des centres de télécommunications météorologiques.............................. I-2
3. Fonctions et caractéristiques des réseaux du Système mondial de télécommunications...................... I-6
Supplément I-1
Supplément I-2
Supplément I-3
Supplément I-4
Supplément I-5
Procédures et dispositions applicables au rassemblement des messages
météorologiques de navires et des messages d’observation océanographique
(BATHY/TESAC)............................................................................................................... Tracé du réseau principal de télécommunications ...................................................... Responsabilités des centres situés sur le réseau principal de télécommunications
en ce qui concerne la transmission des données d’observation et de l’information
traitée............................................................................................................................. (Non utilisé).................................................................................................................. Plan de contrôle du fonctionnement de la Veille météorologique mondiale . ........... I-1/1
I-2/1
I-3/1
I-4/1
I-5/1
Partie II — Procédures d’exploitation du Système mondial de .
télécommunications . .................................................................................................................... II-1
Explications concernant les termes employés.............................................................................................. II-1
1. Principes d’exploitation applicables au Système mondial de télécommunications ............................. II-1
2. Procédures d’exploitation applicables aux transmissions des données météorologiques sur le
Système mondial de télécommunications . ........................................................................................... II-2
3. Procédures applicables aux transmissions des informations météorologiques sous forme
graphique sur le Système mondial de télécommunications . ................................................................ II-14
4. Qualité des transmissions météorologiques .......................................................................................... II-15
5. Procédures à suivre dans les cas où les publications de l’OMM doivent être amendées et
méthodes de notification des amendements . ....................................................................................... II-15
Supplément II-1
Supplément II-2
Supplément II-3
Supplément II-4
Supplément II-5
Supplément II-6
Supplément II-7
Supplément II-8
Supplément II-9
Supplément II-10
Supplément II-11
Supplément II-12
Supplément II-13
Supplément II-14
Alphabet télégraphique international N° 2 ................................................................. II-1/1
Alphabet international N° 5.......................................................................................... II-2/1
Table de conversion entre les Alphabets internationaux N° 2 et N° 5 et caractères
de commande de l’Alphabet N° 5 non contenus dans la première partie du
tableau et utilisés pour les transmissions météorologiques.......................................... II-3/1
Forme de présentation des messages météorologiques................................................ II-4/1
Indicateurs de données T1T2A1A2ii dans les en-têtes abrégés......................................... II-5/1
Forme de présentation du texte des messages adressés et exemple général
de chaque type.............................................................................................................. II-6/1
Catalogues d’acheminement ....................................................................................... II-7/1
Mire fac-similé de l’OMM ............................................................................................ II-8/1
Transmission d’informations graphiques en fac-similé numérique codé et
non codé........................................................................................................................ II-9/1
Comptes rendus des conditions de réception des transmissions
radiométéorologiques .................................................................................................. II-10/1
Procédures de déroutement pour le réseau principal de télécommunications............ II-11/1
Instructions pour l’utilisation de l’indicateur BBB........................................................ II-12/1
Recommandation X.25 ITU-T (extraits)....................................................................... II-13/1
Utilisation des circuits virtuels commutés (CVC) X.25................................................ II-14/1
iv
TABLE DES MATIèRES
Page
Supplément II-15
Supplément II-16
Pratiques et procédures recommandées pour la mise en œuvre, l’utilisation
et l’application du Transmission Control Protocol/Internet Protocol (TCP/IP)
sur le SMT . ................................................................................................................... II-15/1
Méthodes de transmission et de collecte des bulletins météorologiques
sur l’Internet ................................................................................................................. II-16/1
PARTIE III — Caractéristiques et spécifications techniques du Système mondiaL.
DE TéLéCOMMUNICATIONS.......................................................................................... III-1
1. Caractéristiques du réseau principal de télécommunications................................................................ III-1
2. Applications techniques des CMM et des CRT sur le réseau principal de télécommunications........... III-1
3. Réseaux régionaux ................................................................................................................................. III-1
4. Réseaux nationaux ................................................................................................................................. III-1
5. Caractéristiques techniques de l’équipement pour les transmissions météorologiques par
fac-similé analogique.............................................................................................................................. III-1
6. Caractéristiques techniques de l’équipement pour les transmissions en fac-similé numérique codé ..... III-5
7. Caractéristiques techniques de l’équipement pour les transmissions en fac-similé numérique
non codé................................................................................................................................................. III-6
introduction
Buts
1.
Le Manuel du Système mondial de télécommunications est publié conformément à la décision du
Sixième Congrès.
Les buts du présent Manuel sont les suivants:
2.
a)
Faciliter la coopération en matière de télécommunications météorologiques entre les
Membres;
b)
Déterminer les obligations des Membres dans l’application du Système mondial de télécommunications (SMT) de la Veille météorologique mondiale (VMM);
c)
Assurer, d’une manière adéquate, l’uniformité et la normalisation des pratiques et procédures employées pour atteindre les buts a) et b).
3.
Le Manuel est composé de deux volumes: le Volume I contient les textes réglementaires relatifs
aux aspects mondiaux du Système mondial de télécommunications de la VMM et le Volume II, ceux relatifs
à ses aspects régionaux. Ces textes réglementaires proviennent de recommandations de la Commission des
systèmes de base (CSB) et de résolutions de conseils régionaux, ainsi que des décisions prises par le Congrès
et le Conseil exécutif.
4.
Le Volume I — Aspects mondiaux — fait partie du Règlement technique et il est désigné comme
l’Annexe III du Règlement technique (sous réserve des exceptions mentionnées aux paragraphes 9 à 11
ci-dessous).
Catégories de règles
5.
Le Volume I du Manuel (sous réserve des exceptions mentionnées aux paragraphes 9 à 11
ci-dessous) comprend des pratiques et procédures normalisées et des pratiques et procédures recommandées.
Dans le Manuel, ces deux catégories sont définies de la manière suivante:
Les pratiques et procédures normalisées:
a)
Sont les pratiques et procédures qu’il est nécessaire que les Membres suivent ou appliquent;
et, par conséquent,
b)
Ont la même valeur juridique que les prescriptions d’une résolution technique en vertu de
quoi les dispositions de l’article 9 b) de la Convention leur sont applicables;
c)
Sont invariablement caractérisées par l’emploi du terme “shall” dans la version anglaise et
de formes verbales équivalentes dans les versions française, espagnole et russe.
Les pratiques et procédures recommandées:
a)
Sont les pratiques et procédures qu’il est souhaitable que les Membres suivent ou appliquent;
et, par conséquent,
b)
Ont la même valeur juridique que les recommandations destinées aux Membres, auxquelles
les dispositions de l’article 9 b) de la Convention ne sont pas applicables;
c)
Sont caractérisées par l’emploi du terme “should” dans la version anglaise et de formes
verbales équivalentes dans les versions française, espagnole et russe, sauf lorsque le Congrès
en aura expressément décidé autrement.
6.
Conformément aux définitions ci-dessus, les Membres doivent faire tout leur possible
pour appliquer les pratiques et procédures normalisées. En vertu de l’article 9 b) de la Convention
et conformément aux dispositions de la règle 127 du Règlement général de l’OMM, les Membres
doivent notifier expressément par écrit au Secrétaire général leur intention d’appliquer les “pratiques et
procédures normalisées” du Manuel, à l’exception de celles pour lesquelles ils ont signalé des dérogations
particulières. Les Membres informent également le Secrétaire général, au moins trois mois à l’avance,
de tout changement apporté au degré d’application “d’une pratique ou d’une procédure normalisée”
annoncée précédemment et de la date à laquelle ce changement prend effet.
7.
En ce qui concerne les pratiques et procédures recommandées, les Membres sont instamment
priés de s’y conformer, mais ils ne sont toutefois pas tenus de signaler au Secrétaire général l’inobservation
de l’une ou l’autre des règles de cette catégorie.
Édition 2009
vi
INTRODUCTION
8.
Afin de mettre en lumière la valeur juridique des divers textes réglementaires, les pratiques
et procédures normalisées se distinguent des pratiques et procédures recommandées par une disposition
typographique différente, indiquée dans la Note de l’éditeur ci-dessous.
Notes, suppléments
9.
Certaines notes ont été insérées dans le Manuel; ce sont des notes explicatives qui n’ont pas la
valeur juridique des annexes du Règlement technique.
10.
Un certain nombre de directives détaillées concernant les pratiques et procédures de
télécommunications météorologiques ont été insérées dans le Volume I du Manuel. Pour tenir compte du
développement rapide des techniques de télécommunications et des besoins croissants de la VMM et des
autres programmes de l’OMM, ces directives sont données dans des “suppléments” au Manuel et n’ont pas
la valeur juridique des annexes du Règlement technique. Ceci permettra à la Commission des systèmes de base
de les mettre à jour lorsque la nécessité s’en présentera.
11.
Le Volume II du Manuel — Aspects régionaux — ne fait pas partie du Règlement technique.
12.
Dans la version anglaise des suppléments et du Volume II, les mots “shall” et “should” et
les formes verbales équivalentes dans les versions française, espagnole et russe ont leur signification
ordinaire et n’ont pas le caractère réglementaire mentionné au paragraphe 5 ci-dessus.
Note: à partir du 15 janvier 1975, le Manuel du Système mondial de télécommunications remplace les textes
réglementaires insérés dans les chapitres I et II du Volume C de la publication Messages météorologiques
(OMM-N° 9), conformément à la recommandation 17 (CSB-VI) approuvée par la résolution 3 (EC-XXVI).
NOTE DE L’ÉDITEUR
La disposition typographique suivante a été adoptée:
Les pratiques et procédures météorologiques normalisées ont été imprimées en romain mi-gras.
Les pratiques et procédures météorologiques recommandées ont été imprimées en romain maigre.
Les notes ont été imprimées en petits caractères romain maigre et précédées de l’indication: Note.
Édition 2009
PARTIE I
ORGANISATION DU
SYSTÈME MONDIAL DE TÉLÉCOMMUNICATIONS
PARTIE I
ORGANISATION DU SYSTÈME MONDIAL DE TÉLÉCOMMUNICATIONS
1.
FONCTIONS, ORGANISATION ET PRINCIPES DU SYSTÈME MONDIAL DE TÉLÉCOMMUNICATIONS
1.1
Fonctions
Le Système mondial de télécommunications (SMT) a pour fonction de faciliter
l’acheminement des données d’observation et de l’information traitée afin de répondre en temps
voulu, et de manière fiable et rentable, aux besoins de la Veille météorologique mondiale (VMM),
et de permettre ainsi à tous les Membres d’avoir accès aux données d’observation et aux produits
conformément aux procédures approuvées et dans les limites du système agréé de la VMM.
Note: Il doit également fournir des moyens de télécommunications pour la mise en œuvre d’autres programmes,
en application des décisions prises par le Congrès ou par le Conseil exécutif de l’OMM et dans les limites
de ses objectifs principaux.
1.2
Principes régissant l’organisation du SMT
1.2.1
Le SMT est organisé de manière à permettre l’acheminement du volume de renseignements
météorologiques requis, dans les délais prescrits, pour répondre aux besoins des centres météorologiques
mondiaux, régionaux spécialisés et nationaux qui découlent de la mise en œuvre de la VMM.
1.2.2
Le SMT est conçu à trois niveaux, c’est-à-dire qu’il est constitué:
a) Du réseau principal de télécommunications (RPT), reliant les centres météorologiques mondiaux
(CMM) ainsi que les centres régionaux de télécommunications (CRT) désignés;
b) Des réseaux régionaux de télécommunications;
c) Des réseaux nationaux de télécommunications.
1.3
Principes techniques du SMT
Les principes techniques à retenir pour la planification du SMT sont les suivants:
Principe 1
Le SMT doit être conçu comme un réseau intégré destiné à rassembler, échanger et
distribuer l’information à l’échelle mondiale, de façon à répondre efficacement aux besoins de
tous les Services météorologiques nationaux et à ceux des centres météorologiques mondiaux et
régionaux spécialisés, dans le cadre du système agréé de la VMM.
Principe 2
Le SMT forme un réseau intégré de circuits point à point, de liaisons point à multipoints,
de diffusions et de liaisons multipoints à point, fiables et ayant les caractéristiques techniques et
les modalités d’exploitation requises. Ces liaisons peuvent être établies via une combinaison de
liaisons de télécommunications terrestres et par satellite et de services de réseau de transmission de
données.
Principe 3
Les circuits prévus et les techniques à appliquer pour leur exploitation doivent permettre
d’acheminer et de transmettre, dans les délais requis, l’information météorologique et connexe
dont les centres météorologiques mondiaux, régionaux spécialisés et nationaux ont besoin.
Principe 4
Lors de la planification des circuits et des programmes de transmission, il faut veiller
à ce que le volume des données destinées à être transmises chaque jour sur une liaison donnée ne
dépasse pas 80 % de sa capacité théorique. Les liaisons doivent être conçues de manière à garantir
la réception d’un pourcentage de données aussi élevé que possible dans les meilleures conditions de
fiabilité.
édition 2009
I-2
ORGANISATION DU SMT
Principe 5
Le système doit être fondé principalement sur l’interconnexion d’un certain nombre de
centres, à savoir les centres météorologiques nationaux (CMN), les centres météorologiques régionaux
spécialisés (CMRS), les CRT et les CMM. Il est nécessaire que les CMM, les CMRS et les CRT soient dotés
de l’équipement approprié pour la sélection, la composition et la commutation des bulletins, afin de
fournir aux CMN le choix de données correspondant à leurs besoins.
Principe 6
Des dispositions devront être prises chaque fois que cela sera possible pour acheminer les
données par d’autres voies que celles prévues, de façon à assurer le bon fonctionnement du système
et, en particulier, du réseau principal de télécommunications.
1.4
Responsabilités relatives au SMT
1.4.1
Responsabilités générales des conseils régionaux
Les responsabilités générales des conseils régionaux sont les suivantes:
a) Chaque conseil régional assume la responsabilité de la mise en œuvre et du fonctionnement d’un
système de télécommunication efficace fondé sur une utilisation optimale des moyens de télécommunication terrestres et/ou par satellite. Ce système doit permettre de satisfaire les besoins exprimés
par la Commission des systèmes de base en ce qui concerne l’échange de l’information météorologique et connexe au sein de la Région et avec les Régions adjacentes;
b) Pour que le rassemblement des données d’observation météorologique provenant de toutes les
stations s’effectue dans les conditions de rapidité et de fiabilité voulues, chaque conseil régional
doit, en adoptant son plan de télécommunications, se conformer aux principes techniques et
aux modalités d’exploitation énoncés dans ce Manuel. Ces principes et ces modalités concernent
les centres et les circuits qui, à l’intérieur de la Région, sont situés sur le réseau principal de
télécommunications;
c) Chaque conseil régional décide de l’application, au sein de la Région, des options régionales prévues
dans les spécifications et les procédures mondiales;
d) S’agissant des systèmes de diffusion des données (par liaison terrestre ou par satellite), chaque conseil
régional établit, en consultation avec les destinataires connus ou probables de l’information, tant
à l’intérieur qu’à l’extérieur de la Région, et avec le Membre qui exploite le système en question, le
programme et les horaires des transmissions et assure la coordination générale du système.
1.4.2
Responsabilités générales des Membres
En plus des responsabilités exposées en détail dans la section [A.3.1.] 2.1 du Règlement
technique, les principes suivants doivent être observés:
a) Les Membres veillent à ce que leur système national de rassemblement des messages d’observation permette de répondre à la fois aux besoins nationaux et internationaux;
b) Lors de l’adoption des plans de télécommunications interrégionaux et régionaux, les Membres
veillent à ce que les caractéristiques techniques et les modalités d’exploitation soient compatibles
avec les réseaux régionaux de télécommunications.
Note: Le contenu et les horaires des programmes de transmissions météorologiques sont publiés dans le
Volume C de la publication Messages météorologiques (OMM-N° 9).
2.
FONCTIONS ET RESPONSABILITÉS DES CENTRES DE TÉLÉCOMMUNICATIONS
MÉTÉOROLOGIQUES
2.1
Les centres météorologiques mondiaux (en matière de télécommunications) et les centres
régionaux de télécommunications sont chargés:
a) De rassembler les bulletins d’observation en provenance des CMN associés et de les transmettre,
dans la forme qui convient, sur le réseau principal de télécommunications, soit directement soit
par l’intermédiaire du CMM ou du CRT désigné;
Édition 2009
I-3
ORGANISATION DU SMT
b) De transmettre sur le réseau principal de télécommunications, soit directement soit par l’intermédiaire du CRT désigné, conformément aux accords internationaux et dans la forme qui convient,
les bulletins contenant les produits météorologiques élaborés par le CMM ou le CMRS qui leur est
associé;
c) De retransmettre sélectivement sur les circuits du réseau principal de télécommunications, selon
les modalités convenues, les bulletins qu’ils reçoivent en provenance de ces circuits et/ou de CRT
qui ne sont pas situés sur le RPT;
d) D’assurer la distribution sélective des bulletins vers les CMN associés et les CRT qu’ils desservent
et qui ne sont pas situés sur le RPT;
e) De vérifier les parties relatives aux télécommunications du message de façon que les procédures
de télécommunications normalisées soient appliquées en permanence, avant de retransmettre
un message provenant de leur zone de responsabilité (d’un CRT d’une Région et/ou d’un CRT du
RPT). Le CRT communique au centre associé qui a produit le message ou qui l’a compilé toute
correction qu’il y a lieu d’y apporter. Le CRT et les centres qui lui sont associés prennent les dispositions voulues pour transmettre le message sur le SMT sans erreur de télécommunications. Un
CRT ne corrige pas les messages provenant de l’extérieur de sa zone de responsabilité, sauf s’il y a
des dispositions spéciales concernant la transmission des données sur le SMT;
f) D’établir les services de diffusion de données (par liaison terrestre et/ou par satellite), conformément aux plans régionaux;
g) De contrôler le fonctionnement du SMT de la VMM;
h) Pour les CMM et les CRT du réseau principal de télécommunications, tenir à jour le Catalogue des
bulletins météorologiques en ce qui concerne les bulletins émis par la zone dont ils sont responsables du point de vue de la collecte, de l’échange et de la distribution de données, selon le paragraphe 1 du supplément I-3, y compris des données provenant de l’Antarctique, selon les besoins.
Les CMM et les CRT du réseau principal de télécommunications peuvent, par l’intermédiaire de
dispositions régionales, partager leur responsabilité avec les CRT (ne faisant pas partie du RPT)
inclus dans leur zone de responsabilité.
Note: Le plan de contrôle du fonctionnement de la VMM figure dans le supplément I-5.
2.2
Les centres météorologiques régionaux spécialisés qui ne sont pas associés à des CRT devraient
assurer la distribution de leurs produits selon accord avec un ou des centres appropriés du SMT.
2.3
En matière de télécommunication, chaque centre météorologique national doit:
a) Rassembler les données d’observation en provenance de stations situées sur son territoire ou celui
d’autres Membres, selon des accords bilatéraux, ainsi que celles, en provenance d’aéronefs et de
navires, qui ont été reçues par des centres situés à l’intérieur de la zone qu’il dessert. Il doit être
procédé dès que possible au rassemblement de ces données qui doit être terminé dans les 15 minutes
qui suivent l’heure de dépôt des messages d’observation;
Notes: 1. L’heure de dépôt des messages d’observation est l’heure à laquelle les messages d’observation chiffrés
sont remis pour la première fois au service de télécommunications. En ce qui concerne les messages
d’observation d’aéronefs et de navires, c’est l’heure de réception de ces messages aux stations de
télécommunications appropriées (stations terrestres/stations côtières).
2. Normalement, les messages chiffrés devraient être remis au service de télécommunications cinq
minutes, au plus tard, après leur rédaction.
b) Arranger ces données en bulletins et les transmettre au centre régional de télécommunications
auquel il est associé, selon les procédures de télécommunications normalisées;
Note: Le CMN peut être associé à plusieurs CRT.
c) Recevoir et distribuer pour ses besoins propres et au profit des Membres qui ont demandé à recevoir
ces renseignements, en vertu d’accords bilatéraux, les données d’observation et l’information
traitée correspondant aux besoins de ces Membres;
d) Contrôler le fonctionnement du SMT de la VMM.
Notes: 1. Les CMN responsables, ou les autres centres désignés, selon le cas (voir le paragraphe 2.4), doivent
vérifier le contenu météorologique des données d’observation avant que celles-ci ne soient arrangées
en bulletins pour retransmission sur le SMT.
2. Le plan de contrôle du fonctionnement de la VMM figure dans le supplément I-5.
Édition 2009
I-4
ORGANISATION DU SMT
2.4
Chaque Membre désigne un centre météorologique national, ou tout autre centre
approprié, pour remplir les fonctions mentionnées au paragraphe 2.3 ci-dessus, ainsi que pour
procéder au contrôle météorologique des données nationales d’observation avant que ces dernières
soient présentées aux fins de retransmission sur le SMT.
2.5
Responsabilités générales en matière de rassemblement des messages d’observation
météorologique
Les Membres exploitent des centres chargés d’assurer le rassemblement des messages
d’observation météorologique des stations terrestres et des stations en mer, ainsi que des comptes
rendus d’aéronefs.
2.6
Responsabilité en matière de rassemblement des messages d’observation météorologique provenant de stations en mer par l’intermédiaire de stations côtières et de
stations terriennes côtières
2.6.1
Les Membres devraient prendre, avec les autorités ou administrations compétentes en matière
de télécommunications, les mesures nécessaires pour fixer des procédures pour le rassemblement des
messages d’observation météorologique provenant des navires par l’intermédiaire des stations côtières et
des stations terriennes côtières (INMARSAT), afin d’assurer une liaison de transmission effective entre la
station côtière/station terrienne côtière et le centre collecteur.
2.6.2
II convient d’encourager les Membres à développer l’utilisation de la transmission automatique
des navires aux centres collecteurs désignés sans passer par les opérateurs.
2.6.3
Les Membres chargés du rassemblement des messages d’observation météorologique
provenant de navires communiquent au Secrétariat une liste de leurs stations côtières et de leurs
stations terriennes côtières désignées à cet effet. Cette liste comporte, entre autres, des indications
sur l’emplacement, les indicatifs d’appel, les fréquences de travail (transmission et réception) de ces
stations.
Note: La liste des stations côtières et stations terriennes côtières acceptant les messages météorologiques de
navires figure dans la partie B du Volume D — Renseignements pour la navigation maritime, de la
publication Messages météorologiques (OMM-N° 9).
2.6.4
Les Membres communiquent au Secrétariat les amendements qu’il est nécessaire
d’apporter aux renseignements fournis en vertu du paragraphe 2.6.3 qui précède.
2.6.5
Chaque Membre qui désigne une station côtière pour la réception des messages
d’observation météorologique de navires ou une station terrienne côtière pour la réception des
messages d’observation météorologique de navires dans une zone géographique donnée qui présente
un intérêt pour lui confirme au Secrétariat qu’il prend à sa charge tous les frais de transmission des
messages envoyés à son centre collecteur.
2.6.6
Les Membres fournissent à leurs stations de navires et à leurs stations terriennes de navires
désignées les précisions concernant les procédures relatives à la façon d’adresser et d’acheminer les
messages d’observation météorologique dans les différentes zones maritimes.
Note: Ces procédures sont décrites en détail dans le supplément I-1. Les procédures spéciales complémentaires
adoptées par les conseils régionaux figurent dans le Volume II du présent Manuel.
2.6.7
Les Membres chargés de transmettre sur le SMT les messages d’observation météorologique
de navires s’assurent que les messages sont conformes aux normes de l’OMM et qu’ils sont transmis
avec les en-têtes de bulletins appropriés.
2.6.8
Les Membres chargés de la réception des messages d’observation météorologique de navires
devraient prendre des dispositions pour qu’un nombre suffisant de stations côtières dotées d’un personnel
et d’un équipement de télécommunication satisfaisant s’acquittent de cette tâche.
2.6.9
Les Membres devraient demander aux navires de transmettre leurs messages d’observation
météorologique à une station côtière ou à une station terrienne côtière aussitôt que possible après l’heure
d’observation.
2.6.10
Chaque Membre prend, avec les services responsables de l’exploitation des stations côtières
désignées, les dispositions appropriées pour la réception des messages d’observation météorologique
provenant des navires pour que ces stations:
a) Acceptent ces messages avec un minimum de retard;
b) Les transmettent sans délai aux centres collecteurs désignés.
Édition 2009
ORGANISATION DU SMT
I-5
2.6.11
Les Membres ne devraient pas demander à un navire de transmettre le même message
d’observation météorologique à plusieurs adresses.
2.6.12
Chaque Membre prend, après avoir consulté son administration des télécommunications,
les dispositions nécessaires pour que l’indicateur de service OBS soit utilisé par les navires effectuant
des observations dans leur appel initial aux stations côtières, afin de permettre à celles-ci de répondre
suivant l’ordre de priorité approprié. L’abréviation OBS est aussi insérée, en tant qu’indication de
service taxée, dans le préambule des messages météorologiques transmis aux stations côtières par les
navires effectuant des observations météorologiques, afin que les stations côtières acheminent ces
messages suivant l’ordre de priorité approprié. Cette disposition ne s’applique pas en cas d’utilisation de
codes d’accès automatique dans les transmissions par satellite ou radiotélex automatique.
2.6.13
Les Membres devraient faire en sorte que le mot METEO soit utilisé comme premier mot dans
l’adresse des messages météorologiques de navires. Cette disposition ne s’applique pas en cas d’utilisation
de codes d’accès automatique dans les transmissions par satellite ou radiotélex automatique.
2.6.14
Les Membres devraient prendre des dispositions avec leurs administrations des télécommunications pour inclure, s’il est disponible, l’indicatif d’appel des navires dans le préambule des messages
d’observation météorologique provenant de stations sur navires sélectionnés et supplémentaires, ainsi que
de stations sur navires auxiliaires, lorsque ces messages sont transmis par les stations côtières aux centres
collecteurs.
2.6.15
Les messages d’observation météorologique provenant de navires, lorsqu’ils figurent dans des
transmissions collectives, devraient comporter l’indicatif d’appel du navire.
2.6.16
Chaque fois que les messages d’observation météorologique de navires reçus au centre collecteur
sont insuffisants, ou que leur transmission est indûment retardée, le Membre chargé de les rassembler
devrait d’abord prendre, sur le plan régional ou local, les mesures nécessaires pour essayer de remédier à cet
état de choses et, si ces mesures ne produisent pas les effets désirés, en aviser le Secrétariat.
2.6.17
Les Membres devraient s’efforcer, dans toute la mesure possible, d’encourager les navires qui
se trouvent dans les régions océaniques où la navigation est relativement peu dense à relayer les messages
d’observation météorologique par l’intermédiaire d’autres navires, lorsque le navire qui transmet les données
n’est pas en mesure de communiquer avec des stations côtières ou des stations terriennes côtières ou que les
communications sont difficiles.
2.6.18
Les Membres devraient encourager les navires à échanger, par radio, des messages météorologiques dont ils tireraient mutuellement profit, lorsqu’ils se trouvent dans des régions où la navigation est
peu dense ou dans lesquelles il n’est pas régulièrement diffusé de bulletins météorologiques.
2.7
Responsabilité en matière de rassemblement (réception) des comptes rendus
d’aéronefs
2.7.1
Les centres collecteurs désignés dans les plans régionaux de navigation aérienne de l’OACI
pour assurer le rassemblement des comptes rendus météorologiques d’aéronefs communiquent tous
les comptes rendus météorologiques d’aéronefs disponibles au centre météorologique national du
pays concerné ou aux autres centres météorologiques désignés en vertu d’un accord entre les autorités
aéronautiques et les autorités météorologiques en cause.
2.7.2
Les centres régionaux de télécommunications rassemblent les comptes rendus
météorologiques d’aéronefs en provenance des centres météorologiques nationaux, dans leurs zones
de responsabilité respectives.
2.8
Responsabilité en ce qui concerne les messages d’observation météorologique
provenant des stations synoptiques automatiques en surface
2.8.1
Lorsqu’ils sont chiffrés selon une forme symbolique internationale par une station de mise en
forme, les messages de stations synoptiques automatiques en surface devraient être transmis promptement
aux centres collecteurs appropriés.
2.8.2
Les stations synoptiques automatiques en surface qui transmettent directement des messages
chiffrés dans la forme symbolique prévue pour les échanges internationaux devraient comporter un émetteur
assez puissant pour garantir la réception de ces messages aux centres collecteurs appropriés.
2.8.3
Les Membres qui exploitent des stations automatiques synoptiques en surface sur bouées
dérivantes devraient s’efforcer au maximum de communiquer aux autres Membres intéressés tous les
Édition 2009
I-6
ORGANISATION DU SMT
renseignements dont ils ont besoin (par exemple fréquences radioélectriques, formes symboliques utilisées,
etc.), pour leur permettre de recevoir les émissions des stations automatiques dérivantes qui se seraient
écartées au point de se trouver hors de portée de leurs propres stations radioréceptrices.
2.8.4
D’autres données d’observation provenant de bouées dérivantes, qui sont disponibles dans
les centres de traitement des données satellitaires, devraient être mises à la disposition des CMM/CRT
compétents pour distribution à l’échelon régional et mondial sur le SMT, sous la forme symbolique qui
convient pour les échanges à l’échelon international.
Note: Des directives complémentaires relatives aux fonctions et aux possibilités des centres de télécommunications météorologiques sont fournies dans la partie III du présent volume.
2.9
Responsabilités en ce qui concerne l’échange et la diffusion de l’information
météorologique traitée
Le SMT devrait être en mesure d’assurer l’échange et la diffusion des produits élaborés par les
CMM et les CMRS, ainsi que par les centres mondiaux de prévisions de zone (WAFC) et les centres régionaux
de prévisions de zone (RAFC), selon les besoins.
3.
FONCTIONS ET CARACTÉRISTIQUES
TÉLÉCOMMUNICATIONS
DES
RÉSEAUX
3.1
Réseau principal de télécommunications (RPT)
DU
SYSTÈME
MONDIAL
DE
3.1.1
Le réseau principal de télécommunications est un système intégré de circuits reliant entre
eux les CMM et les CRT désignés. Les circuits reliant directement les CMM et/ou les CRT situés sur le
réseau principal de télécommunications peuvent être désignés, à la demande des Membres concernés,
comme circuits du RPT.
Note: Les noms de ces centres ainsi qu’un schéma indiquant comment sont acheminées les données sur le RPT
sont présentés dans le supplément I-2.
3.1.2
Le réseau principal de télécommunications est conçu de telle manière que le trafic issu
de chaque centre (CMM, CRT désigné) est acheminé sélectivement vers le(s) centre(s) destinataire(s).
Chaque centre du RPT assure le relais sélectif du trafic qu’il reçoit vers le(s) circuit(s) qu’il alimente.
3.1.3
Le RPT a pour fonction de fournir un service efficace et fiable de communication entre les
centres désignés, pour assurer:
a) L’échange des données d’observation requises pour répondre aux besoins du Système mondial
de traitement des données et de prévision (SMTDP), dans les conditions de rapidité et de fiabilité
requises;
b) L’échange, entre les CMM, de l’information traitée, y compris les données reçues des satellites
météorologiques;
c) La transmission des produits élaborés par les CMM pour répondre aux besoins des CMRS et des
CMN;
d) La transmission d’autres données d’observation et produits pour les échanges interrégionaux.
Note: Les responsabilités des centres situés sur le réseau principal de télécommunications en matière de transmission des données d’observation et de l’information traitée sont indiquées dans le supplément I-3.
3.2
Réseaux régionaux de télécommunications météorologiques (RRTM)
3.2.1
Conformément aux plans régionaux de télécommunications météorologiques
pour la VMM établis par les conseils régionaux, les réseaux régionaux de télécommunications
météorologiques sont des réseaux intégrés de liaisons point à point, de liaisons point à multipoints
et de liaisons multipoints à point reliant entre eux des CRT, des CMN et, dans certaines Régions, des
CMM et/ou des CMRS, et, selon les besoins, comprennent aussi des radiodiffusions. Ces réseaux sont
conçus de manière à permettre aux CMM, aux CRT et aux CMN de remplir les fonctions décrites
dans la section 2 ci-dessus.
Note: Les centres qui sont situés sur les réseaux régionaux de télécommunications météorologiques sont désignés
par les conseils régionaux (voir le Volume II du présent Manuel).
Édition 2009
ORGANISATION DU SMT
I-7
3.2.2
Les réseaux régionaux de télécommunications météorologiques comprennent les moyens et
circuits de transmissions météorologiques suivants:
a) Les circuits du réseau principal de télécommunications qui traversent la Région;
b) Les circuits régionaux principaux, constitués par des liaisons point à point (assurées par ligne terrestre
ou par satellite) qui relient entre eux les CRT de la Région;
c) Les circuits régionaux, constitués par des liaisons point à point, des liaisons point à multipoints et des
liaisons multipoints à point (assurées par ligne terrestre, par satellite ou par radio) qui relient les CMN
aux CRT ou à d’autres CMN de la Région;
d) Les circuits interrégionaux, constitués par des liaisons point à point (assurées par ligne terrestre, par
satellite ou par radio) qui relient entre eux des CRT ou des CMM aux CRT d’autres Régions;
e) Des circuits interrégionaux supplémentaires, constitués par des liaisons point à point (assurées par
ligne terrestre, par satellite ou par radio) qui relient entre eux des CMM, des CRT et des CMN à des
CMRS ou des CMN situés dans d’autres Régions;
f) Des radiodiffusions et autres moyens radioélectriques.
3.2.3
Fonctions à remplir dans le cadre du SMT
Pour que les données d’observation et l’information traitée puissent être rassemblées
rapidement et transmises sans délai à tous les Services météorologiques nationaux, les réseaux
régionaux de télécommunications météorologiques sont conçus de manière à assurer:
a) L’échange et la distribution des données d’observation recueillies dans la Région et dont les
Membres de celle-ci ont besoin;
b) La collecte des données d’observation compilées ou reçues dans les stations de la Région (par
exemple comptes rendus d’aéronefs ou messages d’observation de navires);
c) La collecte des données d’observation provenant de CMN associés situés dans des Régions voisines,
à condition que cela se révèle utile pour le SMT et que les Membres intéressés et les conseils
régionaux correspondants en décident ainsi;
d) L’échange et la diffusion de l’information traitée (produits élaborés à partir d’informations
classiques et d’observations par satellite) dont les Membres de la Région ont besoin;
e) L’échange, avec d’autres Régions, de données d’observation et d’information traitée.
3.2.4
Programme des transmissions météorologiques assurées par des liaisons point à point
3.2.4.1
Le programme des transmissions météorologiques assurées sur les circuits régionaux
principaux et sur les circuits régionaux est déterminé par chaque conseil régional en fonction des
besoins des Membres de la Région.
3.2.4.2
Le programme des transmissions météorologiques assurées sur les circuits interrégionaux
et sur les circuits interrégionaux supplémentaires est défini par voie d’accord interrégional et/ou
bilatéral entre les Membres.
3.3
Réseaux nationaux de télécommunications météorologiques
3.3.1
Fonctions générales à remplir dans le cadre de la VMM
3.3.1.1
Les réseaux nationaux de télécommunications météorologiques sont constitués de
manière à permettre aux CMN de remplir les fonctions décrites au paragraphe 2.3 ci-dessus.
3.3.1.2
Le choix des réseaux de télécommunications et des moyens mis en œuvre pour le
rassemblement des informations depuis les stations situées à l’intérieur d’un pays ou d’un territoire
est arrêté par le Membre intéressé.
3.3.1.3
Les dispositions prises pour le rassemblement des informations à l’échelon national devraient
permettre, au moins, de satisfaire aux besoins de la VMM en ce qui concerne les délais de transmission et la
sûreté de réception.
3.3.1.4
Afin de répondre aux besoins de la VMM en ce qui concerne les délais de transmission et la sûreté
de réception, des réseaux de télécommunications exclusivement météorologiques devraient être établis.
3.3.1.5
Lorsque les installations citées au paragraphe 3.3.1.4 ci-dessus ne sont pas disponibles ou ne
sont pas utilisables, des dispositions devraient être prises en vue de l’utilisation d’autres moyens tels que:
a) Des systèmes de télécommunications spécialisés (par exemple des circuits aéronautiques);
Édition 2009
I-8
ORGANISATION DU SMT
b) Les services commerciaux de télécommunications à la disposition du public.
3.3.1.6
Des dispositions devraient être prises pour que, chaque fois que cela est nécessaire, les stations
d’observation puissent, à la demande du CMN, répéter les messages mutilés ou erronés.
3.3.2
Programmes des transmissions des CMN aux CRT
Les transmissions assurées par un CMN à destination d’un ou plusieurs CRT appropriés
doivent comprendre au moins les renseignements suivants:
a) Les messages d’observation synoptique en surface et en altitude provenant des stations terrestres
et des stations sur navires stationnaires qui sont requis par accord régional pour les échanges
régionaux et interrégionaux;
b) Tous les messages en provenance d’aéronefs et de navires faisant route, reçus soit directement,
soit par l’intermédiaire d’autres centres collecteurs situés dans la zone couverte par la transmission du CMN;
c) Les autres renseignements requis par accord régional.
Note: Afin que les données d’observation puissent parvenir à temps aux centres du SMT, la priorité est accordée
d’abord:
a) Au rassemblement, sur le plan national, des données d’observation requises;
b) à la transmission des données ainsi recueillies vers les CRT associés.
3.4
Systèmes de collecte et de distribution de données par satellite
3.4.1
Introduction
3.4.1.1
Les systèmes de collecte et de distribution de données par satellite font partie intégrante du
SMT, à l’échelon mondial, régional et national.
3.4.1.2
Ces systèmes devraient être exploités conformément aux principes qui régissent l’organisation
et le fonctionnement du SMT, notamment en ce qui concerne les fonctions et les responsabilités des centres
de télécommunications météorologiques.
3.4.1.3
Ils font appel aux fonctions de télécommunications des satellites météorologiques et aux
services publics de télécommunications par satellite.
3.4.1.4
Les principes à retenir pour la planification des systèmes de distribution de données par satellite
devraient être les suivants:
a) Un système de distribution par satellite devrait compléter les liaisons point à point du SMT;
b) Les CMRS, les CRT et les CMN devraient avoir les moyens d’injecter (directement ou indirectement)
l’information météorologique dans le système régional ou multirégional de distribution de données
par satellite.
3.4.2
Systèmes de collecte de données assurés par les satellites météorologiques
3.4.2.1
Les systèmes de collecte et de retransmission de données assurés par les satellites météorologiques
géostationnaires et les satellites météorologiques à défilement font partie intégrante du SMT s’agissant
de la collecte des données d’observation météorologique. Les données de base rassemblées par ce moyen
ne peuvent normalement être distribuées par le SMT qu’avec l’aval du centre météorologique national
concerné. Les données non soumises à vérification peuvent être acheminées sur le SMT par un CMN désigné,
aux termes d’un accord conclu dans ce sens.
3.4.2.2
La maintenance des plates-formes de collecte de données (PCD) est assurée par l’exploitant
des PCD. Le contrôle de qualité des produits de ces plates-formes relève de l’exploitant et du CMN
désigné.
3.4.2.3
Sauf décision contraire, l’exploitant du satellite météorologique doit assurer la transmission rapide du message reçu en provenance de la plate-forme de collecte de données vers le CMN chargé
du contrôle de qualité et de la vérification de l’information, avant que celle-ci ne soit acheminée sur
le SMT.
3.4.2.4
Le fonctionnement des plates-formes de collecte de données doit être conforme aux critères
définis par l’exploitant du satellite météorologique.
Édition 2009
ORGANISATION DU SMT
3.4.3
I-9
Systèmes de distribution de données assurés par les satellites météorologiques
3.4.3.1
Les systèmes de distribution de données assurés par les satellites météorologiques géosta-
tionnaires font partie intégrante du SMT s’agissant de la transmission point à multipoints des données
d’observation et de l’information traitée sous forme alphanumérique, binaire et graphique, et sous forme
d’images, dans le cadre du système agréé de la VMM.
3.4.3.2
Le service de transmission point à multipoints assuré par l’exploitant du satellite
météorologique doit faire l’objet d’un accord entre les CMN concernés et les agences participant au
programme. Le CMN qui fournit les données à l’exploitant du satellite météorologique est responsable
de la retransmission des données, que celles-ci soient ou non compilées par lui.
3.4.3.3
Chaque exploitant de satellite doit communiquer le programme et les horaires de
transmission, les fréquences et les caractéristiques orbitales du satellite météorologique, ainsi que des
indications sur la zone desservie.
Notes: 1. Le programme et les horaires des transmissions assurées par les satellites météorologiques figurent
dans le Volume C de la publication Messages météorologiques (OMM-N° 9).
2. Les informations relatives aux programmes des satellites météorologiques exploités par les Membres et
par des organisations figurent dans la publication Information on meteorological and other environmental
satellites (OMM-N° 411).
3.4.4
Transmissions point à multipoints et multipoints à point assurées par les satellites de
télécommunications
3.4.4.1
Les services de télécommunications point à multipoints assurés par les administrations/agences de
télécommunication peuvent être utilisés, dans le cadre du SMT, pour la transmission directe vers les CMN des
données d’observation et de l’information traitée provenant de CMM, de CMRS et de CMN, à l’échelon mondial,
multirégional ou régional.
3.4.4.2
Les services de télécommunications multipoints à point assurés par les administrations/agences
de télécommunication peuvent être utilisés, dans le cadre du SMT, pour la mise en œuvre des réseaux
régionaux de télécommunications météorologiques, conformément aux plans établis par les conseils
régionaux.
3.5
Radiodiffusions en ondes décamétriques
3.5.1
Généralités
En attendant que le réseau intégré, tel qu’il est défini dans le principe 2 (voir le paragraphe 1.3
ci-dessus), soit mis en place, on peut recourir aux radiodiffusions en ondes décamétriques pour la transmission de l’information météorologique, dans le cadre de la VMM.
3.5.2
Responsabilités des Membres
3.5.2.1
Lorsqu’un Membre établit sur son territoire une diffusion météorologique régulière destinée à être utilisée par d’autres Membres, il fait parvenir au Secrétariat les renseignements ci-après,
selon le cas:
a)
b)
c)
d)
e)
f)
g)
Nom et indicatif d’appel, ou autre moyen d’identification, de la station émettrice;
Puissance fournie à l’antenne;
Classe d’émission, largeur de bande nécessaire;
Fréquences;
Contenu, horaire détaillé et catégorie OMM de la diffusion;
Indice de coopération et vitesse(s) du tambour de l’émetteur fac-similé;
Point(s) ou zone(s) de réception prévu(s).
3.5.2.2
Les amendements devant être apportés aux renseignements mentionnés au paragraphe
3.5.2.1 ci-dessus sont adressés au Secrétariat, au moins deux mois avant l’établissement d’une
diffusion météorologique régulière ou avant qu’une modification soit apportée à une diffusion
régulière existante.
3.5.2.3
En plus des renseignements fournis au Secrétariat, conformément au paragraphe 3.5.2.2
ci-dessus, la notification des changements imminents de fréquences ou d’horaires des diffusions
météorologiques régulières par radio est insérée par le Membre intéressé dans les émissions effectuées
Édition 2009
I-10
ORGANISATION DU SMT
aux heures synoptiques principales, au moins pendant les trois jours qui précèdent immédiatement
la mise en application de ces changements.
3.5.2.4
S’il se révèle nécessaire de cesser une diffusion essentiellement destinée à d’autres Membres,
toutes dispositions doivent être prises pour assurer à tous les destinataires la communication des
renseignements dont ils ont besoin.
Note: Les diffusions qui sont principalement destinées à l’usage du Membre qui les effectue ne sont pas visées
par la disposition ci-dessus, même si elles sont utilisées par d’autres Membres.
3.5.2.5
S’il se révèle nécessaire ou souhaitable de modifier le mode d’une diffusion essentiellement
destinée à d’autres Membres, le Membre responsable de cette diffusion en informe les destinataires
par un préavis dont la période est convenue par accord régional ou multilatéral.
Notes: 1. à la fin de cette période, les besoins des destinataires seront supposés satisfaits par le nouveau mode
de diffusion.
2. Les diffusions qui sont principalement destinées à l’usage du Membre qui les effectue ne sont pas
visées par la disposition ci-dessus, même si elles sont utilisées par d’autres Membres.
3.5.2.6
Un Membre éprouvant des difficultés à la réception, ou constatant des insuffisances dans une
diffusion destinée à être reçue conformément aux accords établis, devrait tout d’abord prendre, sur le plan
local, des mesures pour remédier à cet état de choses et, s’il n’obtient pas le résultat souhaité, aviser en détail
le Membre qui effectue la diffusion et également tenir au courant, si nécessaire, le président du conseil
régional intéressé.
3.5.3
Le système de diffusion par radio est le suivant:
3.5.3.1
Diffusions par radiotéléimprimeur
Classification
Contenu
Zone de réception prévue
Responsabilités de
l’exploitation
A. Diffusions territoriales
Renseignements météoro- a) à un ou plusieurs CRT
logiques en provenance
désignés
du ou des territoires d’un b) à l’intérieur de la zone
ou de plusieurs Membres,
d’origine des informaainsi que messages de
tions
navires et comptes rendus c) Dans les pays adjad’aéronefs qui sont reçus
cents conformément
dans ce ou ces territoires
aux accords régionaux
ou interrégionaux
Obligatoires pour les
CMN jusqu’à ce qu’un
système point à point
sûr soit disponible pour
assurer les liaisons avec
le CRT de rattachement.
Autrement, facultatives, à
usage national
B. Diffusions régionales
Sélection de renseignements météorologiques
établie conformément
aux accords régionaux et
en tenant compte, le cas
échéant, des nécessités de
la coordination interrégionale
CMM et CRT, conformément aux plans régionaux
météorologiques
3.5.3.2
à l’intérieur d’une zone
spécifiée d’une Région et
dans une zone convenue
interrégionalement
Diffusions par radio fac-similé
Classification
Diffusions régionales*
Contenu
Produits des CMRS situés
dans la Région, produits
des CMM et d’autres
CMRS, en fonction des
accords régionaux et en
tenant compte, le cas
échéant, des nécessités de la coordination interrégionale
Zone de réception prévue
à l’intérieur d’une zone
spécifiée d’une Région et
dans une zone convenue
interrégionalement
* Cette classification n’empêche aucunement l’établissement de diffusions en fac-similé par des CMN.
Édition 2009
Responsabilités de
l’exploitation
CMM, CMRS et CRT,
conformément aux plans régionaux de
météorologiques
SUPPLéMENT i–1
PROCÉDURES ET DISPOSITIONS APPLICABLES AU RASSEMBLEMENT
DES MESSAGES MÉTÉOROLOGIQUES DE NAVIRES ET DES MESSAGES
D’OBSERVATION OCÉANOGRAPHIQUE (BATHY/TESAC)
1.
ZONES DE RASSEMBLEMENT DES MESSAGES MÉTÉOROLOGIQUES DE NAVIRES
Les mers et les océans sont subdivisés d’abord selon les limites des Régions de l’OMM et de
l’Antarctique et ensuite, au sein de chaque Région, en un petit nombre de zones déterminées par les conseils
régionaux intéressés conformément aux principes suivants:
a) En règle générale, chaque zone devrait être reliée aux CRT chargés d’assurer la diffusion, à l’échelon
international, des messages reçus par les stations côtières et les stations terriennes côtières situées dans
la zone en question;
b) Les zones appartenant à une Région peuvent exceptionnellement se prolonger à l’intérieur de la partie
maritime d’une Région voisine, si les deux conseils régionaux intéressés en ont ainsi décidé;
c) à la limite de deux Régions, les zones qui appartiennent à chacune d’elles peuvent chevaucher si les
deux conseils régionaux intéressés en ont ainsi décidé.
Les zones de rassemblement des messages météorologiques de navires, telles qu’elles ont été adoptées par
les conseils régionaux et le Conseil exécutif, sont indiquées à la figure 1.
2.
TRANSMISSION DES MESSAGES MÉTÉOROLOGIQUES DE NAVIRES AUX STATIONS
CÔTIÈRES ET AUX STATIONS TERRIENNES CÔTIÈRES
2.1
Les messages d’observation météorologique provenant de stations de navires ou de stations
terriennes de navires devraient être transmis à une station côtière ou à une station terrienne côtière aussitôt
que possible après l’heure d’observation.
2.2
Les messages d’observation météorologique provenant de stations de navires devraient être
établis par groupes de dix chiffres, lorsque cela est désirable et approprié. L’indicatif d’appel du navire
devrait figurer seul au début du message. Ensuite, les groupes sont simplement transmis de manière à former
des groupes de dix chiffres. Dans le cas où il reste un groupe de cinq chiffres, il est transmis en tant que tel.
Si le message comporte l’identificateur 333, celui-ci est transmis en même temps que les cinq chiffres voisins
de manière à former un groupe de huit chiffres. Le retour aux groupes à cinq chiffres devrait s’effectuer au
plus tard au point d’insertion dans le SMT – en général dans le CMN intéressé. Les dispositions ci-dessus ne
s’appliquent pas à l’échange des messages météorologiques de navires rédigés en clair.
Exemple:
WLGT 0518499568 7020141498 5231410083 2001640198 5301270282 8323222200
0010320303 3263040907 50805333 8381583360
2.3
Les messages d’observation météorologique provenant de stations de navires ou de stations
terriennes de navires devraient (sans que la demande expresse en soit faite) être adressés à la station côtière
la plus proche ou à la station terrienne côtière appropriée située dans la zone où se trouve le navire.
2.4
S’il n’y a pas de station terrienne de navire ou si l’opérateur radio éprouve des difficultés, par
suite de mauvaises conditions de propagation ou d’autres circonstances, à joindre rapidement la station
côtière la plus proche dans la zone où se trouve son navire, il devrait transmettre le message en appliquant,
dans l’ordre, une des procédures indiquées ci-après:
a)
b)
c)
d)
Transmission du message à toute autre station côtière située dans la zone où se trouve le navire;
Transmission du message à toute station côtière située dans une zone voisine de la même Région;
Transmission du message à toute station côtière située dans une zone quelconque de la même Région;
Transmission du message à une station côtière située dans une zone voisine d’une Région voisine ou, à
défaut, à n’importe quelle autre station située dans une Région voisine;
e) Transmission du message à un autre navire ou à une station météorologique océanique qui doit ou veut
bien servir de station relais.
Édition 2009
I-1/2
ORGANISATION DU SMT
2.5
Dans les zones situées à la limite de deux Régions, l’ordre des procédures de transmission
des messages météorologiques de navires aux stations côtières, tel qu’il est stipulé aux alinéas a), b), c), d)
et e) du paragraphe 2.4 ci-dessus, peut être modifié sous réserve de l’accord des deux conseils régionaux
intéressés. Tout accord conclu à ce sujet devrait préciser les limites de la zone en question.
2.6
Les Membres peuvent donner à leurs stations de navires des instructions les autorisant à transmettre leurs messages d’observation météorologique par l’intermédiaire d’une des stations côtières de leurs
pays respectifs qui est chargée de rassembler les messages d’observation dans la zone considérée, dans les cas
où cette procédure faciliterait l’établissement de liaisons efficaces avec les stations côtières et l’acheminement
des messages d’observation météorologique. Les Membres peuvent aussi donner à leurs stations de navires
des instructions les autorisant à transmettre des messages météorologiques par l’intermédiaire de stations
terriennes côtières particulières dont ils prennent à leur charge les frais de transmission.
3.
CRITÈRES ET FONCTIONS DES STATIONS CÔTIÈRES ET STATIONS TERRIENNES CÔTIÈRES
ACCEPTANT DES MESSAGES MÉTÉOROLOGIQUES DE NAVIRES
3.1
Les Membres devraient veiller à ce que les stations côtières désignées pour recevoir les messages
météorologiques de navires:
a) Acceptent ces messages sans frais pour les navires;
b) En ce qui concerne la réception de ces messages:
i) Demeurent à l’écoute 24 heures sur 24; ou
ii) Demeurent à l’écoute pendant 30 minutes au moins, à partir de 0000, 0600, 1200 et 1800 UTC, tous
les jours; la veille devrait également être maintenue, pendant une durée minimale égale, au cours
de la période “à un seul opérateur” qui suit les heures synoptiques standard en question*; ou
iii) Demeurent à l’écoute pendant des périodes plus courtes (stations ayant des heures de veille limitées) que celles dont il est question à l’alinéa ii) ci-dessus, lorsque ces stations sont considérées
comme particulièrement importantes.
3.2
Si l’on constate qu’une certaine station côtière néglige régulièrement d’accepter sans tarder
les messages météorologiques de navires ou si la retransmission de ces messages se révèle défectueuse, le
président du conseil régional intéressé devrait prendre des dispositions pour améliorer cette situation et,
si aucun progrès n’est enregistré, il devrait prendre des mesures en vue de rayer la station de la liste des
stations côtières désignées.
3.3
Les Membres dont les navires éprouvent des difficultés réitérées pour transmettre les messages
météorologiques de navires par l’intermédiaire de stations côtières dans certaines régions devraient signaler
sans délai ces difficultés aux Membres intéressés en donnant tous les détails nécessaires (date, heure, etc.).
Copie de cette correspondance devrait être adressée aux présidents de la Commission des systèmes de base
et de la Commission technique mixte OMM/COI d’océanographie et de météorologie maritime, ainsi qu’au
Secrétaire général.
3.4
Les Membres devraient veiller à ce que les stations terriennes côtières chargées de recevoir les
messages météorologiques de navires acceptent ces messages sans frais pour les navires.
4.
PROCÉDURES COMPLÉMENTAIRES POUR LES NAVIRES AYANT UN SEUL OPÉRATEUR à BORD
4.1
Par suite des difficultés dues au fait que les opérateurs radio assurent une veille à heures fixes,
les navires ayant un seul opérateur à bord devraient s’efforcer de suivre les procédures indiquées ci-après
pour l’exécution des observations et la transmission des messages météorologiques.
4.2
Lorsque des difficultés d’exploitation à bord empêchent qu’une observation synoptique en
surface soit effectuée et/ou transmise à une heure standard principale (0000, 0600, 1200 et 1800 UTC),
l’heure réelle d’observation devrait se rapprocher le plus possible de l’heure standard principale pour
permettre qu’un message soit transmis à une station côtière avant que l’opérateur radio ne termine sa veille.
En outre, dans certains cas particuliers, les observations peuvent être effectuées une heure avant l’heure
standard principale et l’horaire des observations doit être établi en conséquence (c’est-à-dire 2300, 0500,
1100 ou 1700 UTC, respectivement). Il convient cependant de noter que ces écarts doivent être considérés
comme exceptionnels.
________
* Un tableau indiquant les heures internationales de veille à bord des navires fait l’objet de la figure 2.
Édition 2009
I-1/3
SUPPLéMENT i–1
4.3
Si une observation est effectuée à 0300, 0900, 1500 ou 2100 UTC, afin de pouvoir être transmise
à une station côtière, l’observation à l’heure standard principale suivante (0600, 1200, 1800 ou 0000 UTC)
devrait être effectuée à des fins climatologiques et les données ainsi obtenues devraient être transmises, si
possible, conformément aux indications données au paragraphe 4.4 ci-après.
4.4
Les observations effectuées à l’une quelconque des heures standard 0000, 0600, 1200 et
1800 UTC devraient être transmises, même si la transmission ne peut avoir lieu qu’un certain temps après
l’heure de l’observation, selon les modalités suivantes:
a) Dans la plupart des régions du globe, ces messages devraient être transmis à la première occasion pour
autant que le retard ne dépasse pas 12 heures après l’heure de l’observation;
b) Dans l’hémisphère Sud et les autres régions d’où proviennent peu de messages météorologiques de
navires, ces messages devraient aussi être transmis à la première occasion pour autant que le retard ne
dépasse pas 24 heures après l’heure de l’observation.
Il est important d’observer cette procédure, même lorsque la transmission comporte également des messages
correspondant à des observations faites à une heure plus rapprochée.
5.
RASSEMBLEMENT DES MESSAGES D’OBSERVATION OCÉANOGRAPHIQUE (BATHY/TESAC)
5.1
Les messages BATHY et TESAC devraient être transmis à des adresses METEO ou METEOCEAN
par l’intermédiaire des stations côtières et des stations terriennes côtières désignées.
Note: La liste des stations côtières et des stations terriennes côtières acceptant les messages BATHY et TESAC
sans frais pour les navires figure, avec les adresses radio, dans la partie B du Volume D — Renseignements
pour la navigation maritime, de la publication Messages météorologiques (OMM-N° 9), ainsi que dans le
Fascicule 3 des “Manuels et guides” de la COI, intitulé Guide des procédures opérationnelles de collecte et
d’échange de données océanographiques (BATHY et TESAC).
5.2
Lorsque des messages sont transmis par des opérateurs à des stations côtières, l’abréviation
OBS devrait, en tant qu’indication de service taxée, figurer avant l’adresse dans les messages BATHY et TESAC
transmis par les navires d’observation aux stations côtières. Cette disposition ne s’applique pas en cas
d’utilisation de codes d’accès automatique dans les transmissions par satellite ou radiotélex automatique.
5.3
Les messages BATHY et TESAC devraient faire l’objet d’une transmission distincte de celle des
messages météorologiques (en surface ou en altitude). Ils devraient être transmis à une station côtière
désignée à des heures où ils ne gêneront pas la transmission des messages météorologiques, en évitant,
autant que possible, les heures suivantes:
2330 UTC–0200 UTC; 0530 UTC–0800 UTC;
1130 UTC–1400 UTC; 1730 UTC–2000 UTC.
5.4
Les messages BATHY et TESAC devraient être transmis par les navires aux stations côtières dès
que possible après l’heure d’observation. Ils peuvent toutefois être transmis jusqu’à 30 jours après l’heure
d’observation si des difficultés d’exploitation ne permettent pas de les transmettre plus tôt. Le groupe dateheure international de l’en-tête abrégé de ces bulletins devrait indiquer l’heure d’origine de ceux-ci en UTC
(voir le paragraphe 2.3.2.2 de la partie II de ce volume).
Note: L’heure d’origine des bulletins correspond à celle de leur préparation par les centres du SMT.
5.5
Les indicateurs géographiques de l’en-tête abrégé des bulletins BATHY/TESAC devraient être
conformes aux dispositions du tableau C2 du supplément II-5.
Note: Tous les bulletins BATHY/TESAC devraient être publiés dans le Volume C1 — Catalogue des bulletins
météorologiques, de la publication Messages météorologiques (OMM-N° 9).
5.6
L’échange des messages BATHY/TESAC sur le réseau principal de télécommunications devrait
être spécialement contrôlé en liaison avec les opérations de contrôle différé exécutées dans le cadre du
contrôle international coordonné prescrit dans le supplément I-5.
Édition 2009
I-1/4
ORGANISATION DU SMT
RÉGION VI
ZONE VI–A
ZONE VI–B
RÉGION IV
RÉGION II
(voir Note 1)
(voir Note 3)
ZONE VI–D
ZONE VI–C
ZONE II–C
ZONE II–B
ZONE I–B
ZONE I–C
RÉGION I
ZONE II–A
RÉGION III
(voir Note 2)
ZONE I–E
RÉGION V
RÉGION V
(voir Note 3)
(voir Note 3)
ZONE I–D
Aires de chevauchement entre les zones I–E et II–A
et entre les zones VI–A et la Région IV
Limites des Régions aux fins de rassemblement et de
diffusion des messages météorologiques de navires
ANTARCTIQUE
Les appellations employées dans
cette carte et la présentation des
données qui y figurent n’impliquent
de la part du Secrétariat de
l’Organisation météorologique
mondiale aucune prise de position
quant au statut juridique des pays,
territoires, villes ou zones, ou de
leurs autorités, ni quant au tracé
de leurs frontières ou limites.
Figure 1 — Aperçu général des zones de rassemblement et de diffusion des messages météorologiques de navires
Notes:
1. La zone II-C comprend en principe la partie septentrionale de la mer du Japon et de la portion du Pacifique
Nord située dans la Région II. La zone II-B comprend en principe la partie méridionale de la mer du Japon
et de la portion du Pacifique située dans la Région II. Toutefois, il n’a pas été établi de limite précise entre les
zones II-B et II-C.
2.
Pour ce qui est du rassemblement des messages météorologiques de navires, la Région III constitue une seule
zone. Aussi les navires circulant dans la Région III doivent-ils transmettre leurs messages météorologiques
par l’intermédiaire de la station radio côtière la plus proche qui se trouve dans cette Région. à titre de mesure
provisoire, les navires circulant dans les eaux du Pacifique de cette même Région doivent continuer à envoyer
leurs messages météorologiques par l’intermédiaire de la station radio côtière Balboa-NBA, s’ils se trouvent
dans l’impossibilité d’établir le contact avec d’autres stations radio côtières HF situées dans les limites de la
Région III.
3.
Il n’a pas été considéré nécessaire de subdiviser les Régions IV et V en zones. Aussi les navires circulant dans
la Région IV ou V doivent-ils transmettre leurs messages météorologiques par l’intermédiaire de la station
radio côtière la plus proche située dans la Région intéressée.
4.
Il faut considérer que la limite entre les Régions IV et VI n’a qu’une valeur indicative, en ce sens que les
navires se trouvant à proximité de cette limite ont la faculté de transmettre leurs messages d’observation à
une station radio côtière située dans l’une ou l’autre Région.
Édition 2009
SUPPLéMENT i–1
I-1/5
Figure 2 — Vacations par fuseau horaire des stations de navires
Notes:
1. Le graphique indique les vacations fixes et les vacations à option des stations de navires classées dans la
deuxième ou dans la troisième catégorie, suivant les fuseaux horaires. (Les vacations indiquées ne comprennent
pas celles qui sont fixées par l’administration, le commandant ou la personne responsable du navire.)
Les vacations fixes sont représentées de la manière suivante:
a)
pour les navires classés dans la deuxième catégorie;
b)
pour les navires classés dans la deuxième ou dans la troisième catégorie;
c)
pour les navires classés dans la troisième catégorie, période dans laquelle les deux heures de service
continu peuvent être choisies.
2.
Le graphique indique également (en noir) la période entre 0830-0930 pendant laquelle il est recommandé
aux navires classés dans la quatrième catégorie d’assurer le service.
Édition 2009
CRT
CMM
BUENOS AIRES
BRASILIA
WASHINGTON
TOkYO
EXETER
DAkAR
ALGER
TOULOUSE
MELBOURNE
BEIJING
DJEDDA
NAIROBI
OFFENBACH
NEW DELHI
LE CAIRE
PRAGUE
SOFIA
MOSCOU
SUPPLéMENT i–2
TRACÉ DU RÉSEAU PRINCIPAL DE TÉLÉCOMMUNICATIONS
Édition 2009
supplément i–3
RESPONSABILITÉS DES CENTRES SITUÉS SUR LE RÉSEAU PRINCIPAL DE
TÉLÉCOMMUNICATIONS EN CE QUI CONCERNE LA TRANSMISSION
DES DONNÉES D’OBSERVATION ET DE L’INFORMATION TRAITÉE
1.
RESPONSABILITÉS DES CMM ET DES CRT SITUÉS SUR LE RÉSEAU PRINCIPAL DE
TÉLÉCOMMUNICATIONS EN MATIÈRE DE RASSEMBLEMENT, D’ÉCHANGE ET DE DIFFUSION
DE DONNÉES D’OBSERVATION
Ces responsabilités figurent dans le tableau ci-après:
CMM/CRT
Rassemblement des données d’observation des zones de responsabilité des CRT
suivants
Melbourne
Melbourne (51), Wellington (52)
Tokyo
Tokyo (25), Bangkok (26)
Washington
Washington (41)
Exeter
Exeter (61)
Toulouse
Toulouse (63), Rome (66)
Offenbach
Offenbach (64), Norrköping (62), Vienne (68)
Prague
Prague (67)
Moscou
Moscou (65), Khabarovsk (24), Novosibirsk (23), Tashkent (22)
Le Caire
Le Caire (11)
New Delhi
New Delhi (27), Téhéran (21)
Brasilia
Brasilia (31), Maracay (33)
Buenos Aires
Buenos Aires (32)
Nairobi
Nairobi (12), Lusaka (13), Pretoria (14)
Beijing
Beijing (28)
Dakar
Dakar (15), Brazzaville (17), Niamey (18)
Djedda
Djedda (29)
Sofia
Sofia (69)
Alger
Alger (16)
2.
PRINCIPES DE L’ÉTABLISSEMENT DU PROGRAMME D’ÉCHANGE DE
D’OBSERVATION SUR LE RÉSEAU PRINCIPAL DE TÉLÉCOMMUNICATIONS
DONNÉES
Les types de messages météorologiques contenant des données d’observation à échanger sur le
réseau principal de télécommunications sont donnés ci-après.
2.1
Type d’information
a) Données d’observation en surface recueillies sur terre et en mer, y compris par des navires et des
bouées;
b) Données d’observation en altitude, y compris les données d’aéronef;
c) Données climatologiques;
d) Sélection de données satellite;
e) Données sismiques (niveau 1), données relatives aux tsunamis et autres types de données, selon ce qu’il
est convenu.
Note: L’énumération a) à e) ne correspond pas à un ordre de priorité.
Édition 2009
I-3/2
ORGANISATION DU SMT
2.2
Stations dont les messages devraient figurer dans les bulletins à échanger
La liste de stations dont les messages devraient figurer dans les bulletins qui sont à échanger est
établie comme suit:
a) Toutes les stations en surface. Les messages d’observation SYNOP provenant de stations terrestres qui
sont échangés sur le RPT comprennent au moins les Sections 0 et 1 de la forme symbolique SYNOP. à titre provisoire, la Section 3 de la forme symbolique SYNOP est également incluse dans les messages
d’observation devant être échangés à l’échelle mondiale sur le RPT;
b) Toutes les stations (terrestres ou en mer) effectuant des observations de radiosondage-radiovent;
c) Tous les aéronefs;
d) Toutes les stations climatologiques;
e) Toutes les stations océanographiques.
3.
RESPONSABILITÉS DES CENTRES SITUÉS SUR LE RÉSEAU PRINCIPAL DE
TÉLÉCOMMUNICATIONS EN MATIÈRE D’ÉCHANGE ET DE DIFFUSION DES INFORMATIONS
TRAITÉES ET DES DONNÉES SATELLITE
L’échange des informations traitées et des données satellite sur le RPT devrait être organisé
entre les centres de ce réseau de manière à répondre aux besoins des centres de la VMM.
*
* *
Édition 2009
BRASILIA
11-18,
21-29,
31-33, 41,
61-69
21-28, 51,
52
TOKYO
EXETER
25, 26, 28
31, 32, 33
41, 51, 52
21-27, 29,
31-33, 41,
51, 52
DAKAR
22-25, 31-33,
41, 51,52, 61,
65
51, 52
15, 17, 18
11, 12, 14,
29, 31-33,
41, 61, 63,
64
11-18, 21,
29, 62-69
26-28, 51,
52
BEIJING
NAIROBI
11-14
21, 29
12-14
LE CAIRE
NEW DELHI
21, 25-28,
31-33, 41,
51, 52
69
25, 26, 27
11-14
CRT
14, 15, 16,
17, 22, 23,
24, 41, 61,
62-69
22, 23, 24,
41, 61-69
MOSCOU
CMM
69
11-14,
21-28,
62, 65
11, 21-28,
62, 65
SOFIA
15-18, 28-33,
41, 51, 52, 63,
64, 66-68
16, 41, 61,
63, 64, 67,
68
PRAGUE
11-18, 29
11, 15-17,
27
21-24, 65,
67, 69
21-24, 27,
29
11, 12, 14-16,
61-69
11, 29,
31-33,
41, 61-69
12-18, 28-33,
41, 51, 52, 61,
63, 64, 66
OFFENBACH
11, 12, 21-28,
31-33, 41, 51,
52, 61-69
11-14, 21,
26-29. 62,
64, 67-69
DJEDDA
MELBOURNE
11-18, 28,
61-69
ALGER
16
14, 29, 61,
63, 64
TOULOUSE
15-18, 25-27,
31-33, 41, 51,
52, 61, 63, 68,
69
Figure 1 — Plan d’acheminement des données d’observation sur le réseau principal de télécommunications
RÉGION VI
61. Exeter
62. Norrköping
63. Toulouse
64. Offenbach
65. Moscou
66. Rome
67. Prague
68. Vienne
69. Sofia
RÉGION V
51. Melbourne
52. Wellington
RÉGION IV
41. Washington
11-18, 29,
31-33, 41,
61-69
11-18,
21-24, 29,
61-69
22-24, 65
Note: Les responsabilités des centres et les dispositions d’acheminement pour l’échange de l’information traitée sont les mêmes que celles concernant les données
d’observation.
RÉGION II
21. Téhéran
22. Tachkent
23. Novosibirsk
24. Khabarovsk
25. Tokyo
26. Bangkok
27. New Delhi
28. Beijing
29. Djedda
31, 33
11-18, 21,
22-29, 41,
51, 52, 61,
62-69
WASHINGTON
RÉGION III
31. Brasilia
32. Buenos Aires
33. Maracay
BUENOS AIRES
RÉGION I
11. Le Caire
12. Nairobi
13. Lusaka
14. Pretoria
15. Dakar
16. Alger
17. Brazzaville
18. Niamey
32
25, 27, 41,
51, 52, 61,
65
14, 25-28,
31-33, 41,
51, 52
61
supplément I-3
I-3/3
Édition 2009
supplément i–4
(Non utilisé)
Édition 2009
supplément i–5
plan DE CONTRÔLE DU FONCTIONNEMENT DE
LA VEILLE MéTéOROLOGIQUE MONDIALE
1.
OBJECTIFS
1.1
Le programme de contrôle a pour objet d’améliorer le fonctionnement de la Veille météorologique mondiale (VMM), notamment l’efficacité de l’exploitation du Système mondial d’observation
(SMO), du Système mondial de traitement des données et de prévision (SMTDP) et du Système mondial
de télécommunications (SMT) de la VMM à l’échelon national, régional et mondial. Étant donné l’interdépendance du fonctionnement de ces trois éléments de la VMM (SMO, SMTDP et SMT), il est impossible
de contrôler indépendamment le fonctionnement de chaque élément. Pour exercer un contrôle efficace du
fonctionnement de la VMM en tant que système intégré, il est indispensable d’établir une étroite coordination entre tous les centres intéressés, ainsi qu’avec le Secrétariat de l’OMM, pour déterminer les lacunes
et prendre des mesures correctives aussi rapidement que possible.
1.2
La mise en œuvre du plan de contrôle doit porter sur les trois sous-systèmes de la VMM. Ainsi,
du point de vue du contrôle, le SMO a pour tâche de veiller à ce que les observations soient effectuées
conformément aux normes établies, chiffrées correctement et présentées pour la transmission aux heures
fixées; en outre, le SMO donne suite rapidement aux demandes de vérification, de corrections, etc. Il
revient au SMT d’assurer l’acheminement régulier des informations météorologiques brutes et traitées. Cela
implique de surveiller étroitement la réception et la transmission des informations, d’effectuer les demandes
nécessaires lorsqu’il manque des bulletins ou autres produits, de vérifier les formes de présentation des
messages, d’organiser le déroutement du trafic en cas de panne ou d’autres difficultés, etc. Le SMTDP fournit
l’information traitée en temps voulu pour qu’elle puisse être transmise à l’heure prévue et joue également
un rôle important en ce qui concerne le contrôle de la qualité des données.
1.3
Un des buts principaux de tout système de contrôle est de prévoir les moyens de déceler et
de corriger les défauts de fonctionnement de la VMM, afin d’accroître son efficacité et son rendement. Le
succès d’un tel programme se mesure au nombre des défauts corrigés.
1.4
Conformément à la décision du Septième Congrès, les points suivants devraient figurer dans le
programme de contrôle:
a) Régularité des observations;
b) Qualité des données d’observation et de leur codage;
c) Qualité du rassemblement des données d’observation aux CMN concernés tant en ce qui concerne le
nombre des données rassemblées que le respect des délais prescrits;
d) Conformité aux codes et aux procédures de télécommunications normalisés de l’OMM;
e) Rassemblement des données d’observation aux CRT et aux CMM;
f) Échange des données et de l’information traitée sur les réseaux régionaux de télécommunications
météorologiques, ainsi que sur le réseau principal de télécommunications;
g) Évaluation des observations et de l’information traitée reçues aux CMN, CMRS et CMM, compte tenu
des besoins de ceux-ci en données.
2.
ÉLÉMENTS DE BASE
2.1
Contrôle immédiat
2.1.1
L’expression “contrôle immédiat” est celle utilisée pour désigner les opérations de contrôle
qui sont faites assez rapidement pour qu’il soit possible de prendre toute mesure corrective qui s’impose
en temps voulu pour assurer le bon déroulement des activités météorologiques courantes. Théoriquement,
l’idéal serait que ce contrôle soit effectué dans les délais prescrits par les manuels et guides pertinents pour
la réception des renseignements météorologiques. Dans la pratique, cependant, ce contrôle reste valable s’il
peut être effectué avant que la série suivante de ces renseignements soit reçue à son tour.
2.1.2
Étant donné que l’on dispose de peu de temps, le contrôle immédiat ne devrait s’exercer que
dans le cas d’une situation anormale, par exemple dans le cas de bulletins ou d’observations non reçus à
édition 2009
I-5/2
ORGANISATION DU SMT
l’heure, d’erreurs évidentes ou probables, etc. Ainsi, les observations de contrôle immédiat impliquent la
fourniture de renseignements sur les éléments suivants:
• Bulletins non reçus à l’heure fixée;
• Observations non reçues à l’heure fixée, observations inexactes ou suspectes, ou ne pouvant être
interprétées avec certitude;
• Lacunes dans la réception de l’information traitée.
2.2
Contrôle différé
L’expression “contrôle différé” qualifie les opérations de contrôle portant sur une période de
temps déterminée. Le contrôle différé vise à contrôler la qualité du fonctionnement de la VMM dans son
ensemble, de façon à déceler les lacunes qui pourraient subsister après le contrôle immédiat. Le contrôle
différé nécessite l’établissement de tableaux récapitulatifs et de statistiques diverses qui sont disponibles
dans un délai pouvant aller de quelques heures à quelques mois.
2.3
Activités ultérieures de coordination et d’assistance
En ce qui concerne les mesures immédiates, elles seront prises initialement par les centres
intéressés ou au point d’observation. Pour ce qui est des mesures après coup, elles seront prises par les
Membres désireux de corriger les défauts constatés dans l’application du plan de la VMM. Dans certains
cas, ils devront peut-être demander des avis sur les procédures ou la possibilité d’obtenir une aide extérieure
et des renseignements qui les aideraient à assurer la maintenance et le fonctionnement des moyens et
installations de la VMM qu’ils exploitent. D’autre part, le Secrétaire général prendra les mesures qui sont
prévues au paragraphe 5.6 ci-après.
3.
DÉFINITIONS ET NORMES
Les termes utilisés et les normes minimales à respecter dans le système de contrôle devraient
correspondre à ceux qui sont définis dans le Manuel du Système mondial d’observation, le Manuel du Système
mondial de télécommunications, le Manuel des codes, le Manuel du Système mondial de traitement des données et
de prévision et les chapitres appropriés du Règlement technique.
4.
PRIORITÉS
4.1
Le système de contrôle devrait viser à mettre des contrôles en place pour les informations
suivantes, selon l’ordre de priorité indiqué ci-après:
a)
b)
c)
d)
e)
f)
Messages TEMP, TEMP SHIP et TEMP MOBIL, parties A et B;
Messages PILOT, PILOT SHIP et PILOT MOBIL, parties A et B;
Messages SYNOP (échange mondial);
Messages SHIP et comptes rendus AIREP/AMDAR (destinés à être échangés mondialement);
Messages CLIMAT et CLIMAT TEMP;
Toutes les autres données d’observation et l’information traitée faisant l’objet d’échanges réguliers.
4.2
Le contrôle des données de satellites constitue un cas particulier. Il n’y a que peu de pays qui
exploitent des satellites et les normes de contrôle du fonctionnement des satellites et de la qualité de leurs
données sont déjà élevées. Le contrôle des bulletins de données de satellites et de bulletins présentés sous
forme de valeurs aux points de grille (forme symbolique GRID) fera l’objet d’opérations spéciales portant sur
une période de temps limitée et organisées par le Secrétariat de l’OMM.
4.3
Lors de la mise en œuvre du plan de contrôle, il est important de doter les points d’observation,
ainsi que tous les centres, de moyens leur permettant de répondre rapidement aux demandes de vérification
et de répétition relevant du contrôle immédiat. Il sera également utile d’accorder une attention particulière
aux opérations du plan de contrôle destinées à obtenir le respect:
a) De la forme correcte de présentation des messages transmis sur le SMT;
b) Du chiffrement correct des messages et messages d’observation;
c) De l’horaire, de manière que les données soient disponibles en temps voulu;
Édition 2009
I-5/3
SUPPLéMENT I-5
d) De la qualité du contenu météorologique des messages.
5.
RESPONSABILITÉS
5.1
Membres.
Fondamentalement, la responsabilité du contrôle du fonctionnement de la VMM incombe aux
5.2
Les responsabilités concernant l’exécution du contrôle immédiat et du contrôle différé sont
énoncées dans les tableaux A et B. Un point essentiel du plan de contrôle est que les informations devraient
être échangées entre centres adjacents, sur le SMT, afin que les problèmes de télécommunications puissent
être facilement décelés. Cet échange d’informations se caractérise notamment par le fait qu’il faut élaborer
des procédures permettant de déterminer, sans doute possible, qu’un bulletin contient bien toutes les
observations requises. Le contenu d’un bulletin type composé d’observations courantes devrait toujours
être conforme à la liste figurant dans les publications pertinentes de l’OMM, telles qu’amendées. Lorsque,
pour l’une ou l’autre raison, le bulletin ne contient pas les observations de certaines stations énumérées
dans la publication, les rapports doivent être codés NIL. à titre de vérification supplémentaire, chaque
CMN devrait envoyer au CRT qui lui est associé, de préférence à l’avance, des messages indiquant que les
observations de certaines stations ne sont (ou ne seront) pas disponibles. Il est essentiel que chaque centre
de la VMM (CMN, CMRS, CRT et CMM) contribue à l’effort général de contrôle. Les centres qui ont un
rôle multiple assureront de toute évidence une contribution à plusieurs niveaux. Dans ce contexte, les
points suivants devraient être pris en considération:
a) Pour le contrôle au niveau du bulletin, il convient d’inclure les bulletins supplémentaires ou
subséquents (RRx) et les bulletins corrigés (CCx);
b) Pour le contrôle au niveau du message d’observation, les messages corrigés ne devraient pas être
considérés comme des messages supplémentaires; les messages retard devraient être comptés;
c) Les messages en double et les bulletins en double ne devraient être comptés qu’une seule fois;
d) Les contributions devraient faire mention de la base de données utilisée pour l’opération de contrôle
(télécommunications ou traitement des données);
e) Toute défaillance ou panne des centres et/ou des circuits qui se produirait durant l’opération de
contrôle devra être signalée;
f) Tout devra être mis en œuvre pour respecter les heures figurant dans les en-têtes des tableaux.
5.3
La fréquence à laquelle les rapports de contrôle devraient être établis et/ou échangés est
indiquée dans le tableau ci-dessous:
Chaque jour
— Chaque centre assure en permanence un contrôle immédiat;
Au moins une fois par mois
— Les CMN établissent un résumé des résultats pertinents
des opérations de contrôle destiné à être utilisé à l’échelon
national et international, le cas échéant;
Au moins une fois tous les trois mois — Les CRT/CMRS envoient aux CMN qui leur sont associés un résumé des résultats des opérations de contrôle;
Au moins une fois tous les trois mois — Les CRT/CMRS envoient un résumé des résultats des
opérations de contrôle aux CRT voisins qui leur fournissent des données;
Une fois tous les six mois
— Les CMM envoient un résumé des résultats des opérations de contrôle aux CRT/CMRS voisins qui leur fournissent des données.
Les rapports qui doivent être établis à intervalles de trois mois ou plus devraient toujours être également
adressés au Secrétaire général, sous une forme convenue, pour suite à donner. En ce qui concerne leur
teneur, les rapports devraient inclure autant d’informations du tableau B qu’il est possible et utile.
Édition 2009
I-5/4
ORGANISATION DU SMT
5.4
Les Membres devraient mettre en œuvre le plan de contrôle du fonctionnement de la VMM dès
que possible, en particulier le contrôle immédiat.
5.5
Afin d’évaluer le bon fonctionnement de la VMM, il y aurait lieu d’effectuer régulièrement,
une fois par an, en octobre, avec la participation d’un petit nombre des principaux centres de la VMM,
un contrôle différé coordonné à l’échelon international de toutes les données d’observation. Le reste du
temps, il faudra revoir les problèmes particuliers qui se posent soit à propos de certaines informations,
soit dans certaines régions du globe. Le Secrétaire général déterminera, après consultation des centres
appropriés, le contenu de ces exercices spéciaux de contrôle, ainsi que les périodes durant lesquelles ils
devront avoir lieu, et avisera les intéressés suffisamment à l’avance.
5.6
Le Secrétariat procédera aux analyses des rapports soumis par les centres de la VMM à l’issue
des contrôles différés et fera connaître le résultat de ces analyses aux centres intéressés. Le Secrétaire
général assurera la coordination et donnera des avis quant à l’assistance nécessaire pour remédier aux
déficiences révélées par les résultats du contrôle. Il devra aussi organiser (selon les besoins) les exercices
de contrôle spéciaux mentionnés au paragraphe 5.5 ci-dessus.
6.
PROCÉDURES
6.1
Pour les activités de contrôle immédiat, chaque centre devrait mettre au point les
procédures nécessaires. Ces procédures varieront d’un centre à l’autre, mais devraient être conçues de
façon à faciliter la vérification immédiate de la réception des bulletins et des observations. Dans les
centres pleinement automatisés, on peut envisager de recourir, par exemple, aux valeurs enregistrées
des systèmes de télécommunications, à des dispositifs d’affichage visuel ou à des programmes spéciaux
de télécommunications et de traitement de données sur ordinateur. Dans les centres manuels, il faudra
prévoir des listes ou des feuilles de vérification et y porter des coches, des croix ou des chiffres indiquant
l’heure à laquelle certains bulletins et/ou messages d’observation ont été reçus. Pour éviter tout gaspillage
de papier, il peut être souhaitable de placer sur les feuilles de corrections des transparents de plastique et de
porter les indications au moyen de crayons gras. Ces indications peuvent être ainsi gommées facilement au
bout d’un certain laps de temps et les formulaires être utilisés à nouveau pour des vérifications ultérieures.
Le tableau C contient d’autres directives pour les opérations de contrôle immédiat, ainsi que des exemples
des formulaires à utiliser.
6.2
En ce qui concerne le contrôle différé, il faudrait, pour les exercices spéciaux de contrôle
demandés par le Secrétariat, que les centres indiquent, au moment prescrit pour ces exercices, sous quelle
forme ils y contribueront. Il est important que les centres se conforment autant que possible aux procédures
indiquées, de façon à faciliter la comparaison des résultats communiqués. Cela vaut particulièrement
pour l’exercice annuel de contrôle à l’échelle du globe. Les procédures et les formulaires normalisés pour
la présentation des résultats des contrôles sont décrits dans le tableau D.
6.3
II faut bien considérer que les procédures officielles de contrôle prescrites dans le présent
supplément ne sauraient, en aucun cas, remplacer l’échange quotidien et régulier d’informations et d’avis
entre centres voisins qui, dans la mesure du possible, devrait servir à résoudre tous les problèmes. Seules
les graves difficultés devront, au bout d’un certain temps, apparaître dans les comptes rendus officiels des
opérations de contrôle.
Édition 2009
I-5/5
SUPPLéMENT I-5
Tableau A
Contrôle immédiat
Informations
Système national
CMN
CRT/CMRS
CRT/CMM
1. Bulletins non reçus à temps
2. Observations non reçues à temps
3. Informations traitées non reçues à temps
4. Erreurs dans les observations
(
)
5. Contrôles spéciaux bilatéraux
(Informations mentionnées à titre indicatif)
Notes:
1. Les bulletins non reçus à temps sont des bulletins figurant dans le programme des transmissions, et qui n’ont
pas été reçus à l’heure fixée bilatéralement par deux centres voisins.
2. Les observations non reçues à temps sont des observations figurant dans la teneur publiée des bulletins devant
être transmis, mais qui n’ont pas été reçues à l’heure fixée.
3. Les informations traitées non reçues à temps sont des données figurant dans le programme des transmissions,
mais non reçues à l’heure fixée.
4. Les erreurs dans les observations sont des erreurs constatées ou suspectées dans le chiffrement et/ou dans le
contenu météorologique des messages.
5. Les contrôles spéciaux bilatéraux sont des contrôles portant sur l’un ou l’autre des éléments 1 à 4 ci-dessus, ou
sur d’autres éléments, et qui peuvent avoir été organisés par les centres intéressés, soit provisoirement, soit de
façon plus permanente.
Par système national, on entend ici les systèmes nationaux servant à l’observation, ainsi qu’au
rassemblement et à la diffusion des données.
Les flèches indiquent le sens dans lequel les messages de contrôle sont normalement transmis.
Par exemple, seul le CMN peut, normalement, envoyer aux réseaux d’observation les messages relatifs à
des erreurs suspectées dans les observations, à moins que le CMN intéressé n’ait conclu un accord bilatéral
spécial avec un CMRS le chargeant de procéder à sa place au contrôle immédiat de la qualité des données.
Cette éventualité a été prévue dans les fonctions assignées au CMRS (flèche entre parenthèses).
*
* *
Édition 2009
I-5/6
ORGANISATION DU SMT
Tableau B
Contrôle différé
Informations
CMN
CRT/CMRS
CMM
1. Bulletins non reçus
x
x
x
2. Bulletins reçus tardivement
x
x
x
3. Observations non reçues
x
x
x
4. Observations reçues tardivement
x
x
x
5. Informations traitées non reçues
x
x
6. Informations traitées reçues tardivement
x
x
7. Non-respect de la forme de présentation prescrite pour les télécommunications
x
x
x
8. Données d’observation manquantes dans un message
x
x
x
9. Qualité des données d’observation
x
x
x
10. Défauts constatés dans les informations traitées
x
x
x
11. Vérifications statistiques des prévisions numériques du temps
x
x
x
12. Contrôles spéciaux bilatéraux ou multilatéraux
x
x
x
13. Remarques sur les difficultés récurrentes
x
x
x
14. Rapports de contrôle
x
x
x
(Informations mentionnées à titre indicatif)
Notes:
1.
Les bulletins non reçus sont des bulletins figurant dans le programme des transmissions, mais qui n’ont pas
été reçus.
2.
Les bulletins reçus tardivement sont des bulletins qui ont été reçus après le délai prescrit par l’OMM ou convenu
bilatéralement.
3.
Les observations non reçues sont des observations figurant dans le programme des transmissions, mais qui
n’ont pas été reçues.
4.
La définition des observations reçues tardivement est analogue à celle des bulletins reçus tardivement (voir la
note 2 ci-dessus).
5.
Les informations traitées non reçues sont des produits sous forme alphanumérique ou graphique qui n’ont pas
été reçus, bien qu’ils figurent dans le programme des transmissions.
6.
Les informations traitées reçues tardivement sont définies de la même manière que le sont, dans la note 2
ci-dessus, les bulletins reçus tardivement.
7.
Le non-respect de la forme de présentation prescrite pour les télécommunications correspond à des erreurs importantes ou fréquentes faites par les stations émettrices et qui entravent la transmission régulière des messages.
8.
Données d’observation manquantes dans un message.
9.
Qualité des données d’observation.
10. Les défauts constatés dans les informations traitées sont des défectuosités (par exemple données manquantes,
messages mutilés, produits fac-similé illisibles) qui compromettent gravement l’utilité pratique immédiate
de ces produits.
11. Les vérifications statistiques des prévisions numériques du temps ne devraient être fournies que par les centres
pour lesquels les informations de ce type présentent un intérêt particulier et qui ont les moyens de les
fournir.
12. Les contrôles spéciaux bilatéraux ou multilatéraux sont des contrôles supplémentaires organisés par deux
ou plusieurs centres, soit à titre temporaire, soit de façon permanente, pour tenter de résoudre certaines
difficultés particulières.
Édition 2009
SUPPLéMENT I-5
I-5/7
13. Les remarques sur les difficultés récurrentes se rapportent à des difficultés autres que celles mentionnées dans les
notes 1 à 12 ci-dessus.
14. Les rapports de contrôle sont des rapports établis selon le mode de présentation qui sera défini par le Secrétaire
général, après consultation du président de la CSB et des présidents des groupes de travail compétents.
Les croix portées dans les différentes colonnes désignent les centres normalement chargés de remplir les fonctions
indiquées.
Tableau C
Directives pour le contrôle immédiat
1.
Vérification de la réception de messages d’observation en provenance de stations
terrestres
Pour mettre en œuvre le contrôle immédiat, il faut utiliser les formulaires appropriés pour
vérifier la réception de messages d’observation en provenance de stations terrestres. Il est possible de dresser
des tableaux distincts pour les messages SYNOP destinés à l’échange mondial, pour les messages TEMP
et PILOT destinés à l’échange mondial, pour les messages SYNOP destinés à un échange régional et pour
d’autres échanges, afin de déterminer dans quelle mesure les divers types de données d’observation sont
disponibles. Si un message d’observation en provenance d’une station n’a pas été reçu en temps voulu, il
faudrait en faire immédiatement la demande auprès de la station. Des procédures détaillées doivent être
mises au point pour répondre aux besoins des centres de divers types.
2.
Vérification de la réception de comptes rendus d’aéronefs ou de messages météorologiques de navires en provenance des stations du service mobile aéronautique ou des
stations radio côtières
Chaque centre devrait s’assurer que tous les bulletins ont été bien reçus; des procédures à cette
fin devraient être élaborées pour répondre aux besoins locaux (par exemple en vérifiant l’ordre des numéros
de transmission, etc.).
3.
Vérification du chiffrement des messages d’observation
Avant d’émettre les bulletins, les messages d’observation devraient être vérifiés afin d’éviter
toute erreur de chiffrement. Cette vérification devrait être effectuée une première fois par l’observateur, au
moment de l’observation, puis par du personnel qualifié lors de la préparation des bulletins. Ces vérifications
ne doivent cependant pas entraîner des retards sensibles dans la transmission des bulletins.
4.
Vérification de la forme de présentation normalisée des messages météorologiques
Il conviendra de vérifier les messages météorologiques pour contrôler si la forme de présentation
normalisée a bien été utilisée et d’apporter les corrections nécessaires. Il faudra vérifier en particulier les
points suivants:
a) La ligne préliminaire, l’en-tête abrégé et le signal de fin de message des messages doivent être absolument exempts d’erreurs;
b) Les messages insérés dans un bulletin doivent être séparés par le signal de séparation de message.
Il faut savoir que les messages qui peuvent être manipulés sans difficultés dans les centres
manuels peuvent poser de graves problèmes dans les centres automatisés si l’on n’observe pas scrupuleusement les procédures prescrites. Dans certains cas, il peut suffire d’un seul caractère incorrect pour donner
lieu à de graves difficultés.
5.
Vérification de la réception des bulletins réguliers dans les délais prescrits après
l’heure de l’observation
Chaque CRT devrait vérifier la réception des bulletins provenant de chaque CMN situé dans sa
zone de responsabilité. Il est possible d’utiliser à cet effet les exemples 1 et 2 ci-après. S’il y a une discontinuité
dans les numéros de transmission (nnn), une demande d’explication devrait être immédiatement adressée
au centre concerné. Dans les cas où on n’utilise pas l’ordre des numéros de transmission pour vérifier la
réception des bulletins, il faut prendre d’autres mesures pour s’assurer qu’aucun bulletin n’est manquant
et pour vérifier qu’aucune observation n’est manquante pour diverses raisons (mutilation des messages,
évanouissement, etc.).
Édition 2009
Édition 2009
DATE:
Description du défaut
CENTRE:
En-tête abrégé
Heure de
réception
Heure de
la demande
CIRCUIT:
Heure de réception
de la répétition
Remarques (par exemple durée
de la panne du circuit)
PAGE:
Contrôle immédiat
(Vérification concernant les bulletins météorologiques non reçus, reçus sous une forme incorrecte ou tronqués)
Exemple 1
I-5/8
ORGANISATION DU SMT
En-tête abrégé
Heure de réception
SHIP
Nombre de messages
d’observation
En-tête abrégé
Heure de réception
AIREP
Nombre de comptes
rendus d’observation
Contrôle de la réception des bulletins SHIP/AIREP et nombre de messages d’observation
Exemple 2
SUPPLéMENT I-5
I-5/9
Édition 2009
I-5/10
ORGANISATION DU SMT
Tableau D
Procédures pour assurer la coordination à l’échelon international du contrôle différé du fonctionnement du SMT
1.
Périodes de contrôle
Afin de vérifier périodiquement le bon fonctionnement de la VMM, les données destinées à être
échangées mondialement sont soumises chaque année à un contrôle coordonné à l’échelon international,
qui a lieu au mois d’octobre. Les statistiques devraient être établies sur cinq jours (1er au 5 octobre) pour
les centres où la vérification est faite manuellement, et sur 15 jours (1er au 15 octobre) pour les centres
automatisés. Afin de faciliter la comparaison des résultats, les centres automatisés devraient fournir les
résultats obtenus pour les deux périodes, c’est-à-dire du 1er au 5 octobre et du 1er au 15 octobre.
Note: S’agissant des messages CLIMAT et CLIMAT TEMP, la durée du contrôle devrait être portée à 15 jours, même
si l’on prévoit (pour d’autres observations) une période de cinq jours seulement.
2.
Types de données à contrôler
Le contrôle doit porter sur les types de données énumérées dans le tableau ci-dessous:
Types de données
Messages SYNOP
Messages TEMP, parties A et B
Messages PILOT, parties A et B
Messages SHIP
Messages TEMP SHIP, parties A et B
Messages PILOT SHIP, parties A et B
Messages BUOY
Messages AIREP
Messages AMDAR
Messages BATHY/TESAC/trackob
Messages CLIMAT
Messages CLIMAT TEMP
En-têtes abrégés
des bulletins
T1T2A1A2
Formulaire type
pour la présentation
des résultats
SMA1A2
USA1A2/UKA1A2
UPA1A2/UGA1A2
SMA1A2
USA1A2/UKA1A2
UPA1A2/UGA1A2
SSA1A2
UAA1A2
UDA1A2
SOA1A2
CSA1A2
CUA1A2
A
B1/B2
B1/B2
C1/C2
D1/D2/D3/D4
D5/D6/D7/D8
E
F
G
H
I1
I2
a) Contrôle des messages SYNOP
Pour chaque station soumise à contrôle, identifiée par l’indicatif de la station (IIiii), il convient d’inscrire,
dans les colonnes correspondantes du formulaire A, le nombre de messages d’observation SYNOP
correspondant aux heures synoptiques principales (0000, 0600, 1200 et 1800 UTC) reçus, pendant la
période considérée, dans l’heure, les 2 heures et les 6 heures qui suivent l’heure de l’observation;
b) Contrôle des messages TEMP et PILOT, parties A et B
Pour chaque station soumise au contrôle, identifiée par l’indicatif de la station (IIiii), il convient d’inscrire,
dans les colonnes correspondantes des formulaires B1 et B2, le nombre de messages d’observation TEMP
et PILOT (parties A et B – observation faite par poursuite électronique ou optique d’un ballon libre aux
heures synoptiques principales (0000, 0600, 1200 et 1800 UTC)) reçus, pendant la période considérée,
dans les 2 heures et les 12 heures qui suivent l’heure de l’observation;
c) Contrôle des messages SHIP
Il convient d’inscrire, dans les colonnes correspondantes des formulaires C1 et C2, le nombre de bulletins, identifiés par leurs en-têtes abrégés (T1T2A1A2ii CCCC), contenant des messages d’observation SHIP
pour les heures synoptiques principales (0000, 0600, 1200 et 1800 UTC) reçus, pendant la période
considérée, dans les 2 heures et les 12 heures qui suivent l’heure de l’observation, ainsi que le nombre
de messages d’observation figurant dans ces bulletins;
Édition 2009
SUPPLéMENT I-5
I-5/11
d) Contrôle des messages TEMP SHIP et PILOT SHIP, parties A et B
Il convient d’inscrire, dans les colonnes correspondantes des formulaires D1 à D8, le nombre de bulletins,
identifiés par leurs en-têtes abrégés (T1T2A1A2ii CCCC), contenant des messages d’observation TEMP SHIP et
PILOT SHIP (parties A et B) pour les heures synoptiques principales (0000, 0600, 1200 et 1800 UTC) reçus,
pendant la période considérée, dans les 12 heures et les 24 heures qui suivent l’heure de l’observation,
ainsi que le nombre de messages d’observation figurant dans ces bulletins;
e) Contrôle des messages BUOY, AIREP et AMDAR
Il convient d’inscrire, dans les colonnes correspondantes des formulaires E, F et G, le nombre de
bulletins, identifiés par leurs en-têtes abrégés (T1T2A1A2ii CCCC), contenant des messages d’observation
BUOY, AIREP et AMDAR compilés entre 2100 et 0259 UTC, 0300 et 0859 UTC, 0900 et 1459 UTC, et
1500 et 2059 UTC, qui sont reçus, durant la période considérée, avant 0500, 1100, 1700 et 2300 UTC
respectivement, ainsi que le nombre de messages d’observation figurant dans ces bulletins;
f) Contrôle des messages BATHY/TESAC/TRACKOB
Il convient d’inscrire, dans les colonnes correspondantes du formulaire H, l’heure de réception des
bulletins, identifiés par leurs en-têtes abrégés complets (T1T2A1A2ii CCCC YYGGgg (BBB)), contenant des
messages d’observation BATHY/TESAC/TRACKOB, ainsi que le nombre de messages d’observation figurant dans ces bulletins;
g) Contrôle des messages CLIMAT et CLIMAT TEMP
Pour chaque station soumise au contrôle, identifiée par l’indicatif de la station (IIiii), il convient de
porter “1” dans la colonne correspondante du formulaire I1 si le message CLIMAT de septembre est reçu
entre le 1er et le 5 octobre ou entre le 6 et le 15 octobre, ou la mention “0” si tel n’est pas le cas. La
même procédure est applicable aux messages CLIMAT TEMP de septembre (formulaire I2).
3.
Ensemble de données à échanger mondialement soumises au contrôle
3.1
L’ensemble des données à contrôler est déterminé d’après:
a) La liste des stations en surface constituant les réseaux synoptiques de base régionaux (RSBR), pour les
messages d’observation SYNOP et CLIMAT; la liste des stations de radiosondage-radiovent constituant
les RSBR, pour les parties A et B des messages d’observation TEMP et CLIMAT TEMP; la liste des stations
de radiovent constituant le RSBR pour les parties A et B des messages d’observation PILOT;
b) Les listes des en-têtes abrégés des bulletins contenant les messages SHIP, TEMP SHIP, PILOT SHIP, BUOY,
AIREP/AMDAR et BATHY/TESAC/TRACKOB qui doivent être échangés à l’échelle mondiale; ces listes
figurent dans le Catalogue des bulletins météorologiques. Pour plus de commodité, le Secrétariat établira
les listes d’en-têtes abrégés et les joindra aux formulaires correspondants, lors de chaque contrôle.
3.2
Les références des listes mentionnées (y compris les références de l’amendement correspondant
au Manuel du SMT et de l’édition du Catalogue des bulletins météorologiques) sont reportées sur les formulaires
établis par le Secrétariat pour chaque contrôle.
4.
Données soumises au contrôle — zones géographiques
Le contrôle des données doit se répartir comme suit entre les centres du SMT:
a) Chaque CMN (ou centre exerçant les fonctions similaires) devrait contrôler au moins la réception des
données en provenance de la zone pour laquelle il est responsable du rassemblement des données, ainsi
que leur acheminement sur le SMT;
b) Les CRT qui ne sont pas situés sur le RPT devraient contrôler au moins la réception des données
d’observation en provenance des stations situées dans la zone qu’ils desservent, conformément aux
dispositions prévues dans le Volume II de ce Manuel. Ils devraient aussi vérifier la réception des données
d’observation en provenance de la Région où ils sont situés et de toute autre Région à laquelle ils sont
reliés par un circuit interrégional;
c) Les CMM et les CRT qui sont situés sur le RPT devraient contrôler la réception des données d’observation et de l’information traitée destinées à être échangées mondialement.
Édition 2009
I-5/12
5.
ORGANISATION DU SMT
Application des procédures de contrôle — questionnaires
5.1
Les formulaires J, K et L concernent respectivement les procédures de contrôle appliquées dans
les centres, l’interruption des programmes d’observation aux stations d’observation et les interruptions de
transmission sur les circuits.
5.2
Une réponse positive (“oui”) à toutes les questions posées dans le formulaire J correspond à une
application correcte des procédures de contrôle. Les questions 7, 8 et 10 ne s’appliquent qu’aux messages
SYNOP, TEMP, PILOT, CLIMAT et CLIMAT TEMP.
6.
Formulaires normalisés pour les statistiques
6.1
Pour faciliter la comparaison des résultats du contrôle coordonné à l’échelle internationale,
effectué par les différents centres, ces derniers devront utiliser les formulaires normalisés ci-joints et indiquer
clairement la durée de la période de contrôle. Les centres devraient présenter les résultats pour chaque
Région et pour l’Antarctique et indiquer, dans chaque formulaire, le nombre total de bulletins ou de messages
d’observation reçus pour les heures indiquées en provenance de chaque Région et de l’Antarctique.
6.2
Si la réception du message ou du bulletin mentionné dans la première colonne du formulaire
n’est pas prévue, la mention “N” devrait être portée dans la deuxième colonne du formulaire, et la mention
“S” dans le cas contraire.
6.3
Les statistiques devraient être envoyées aux centres voisins concernés et au Secrétariat de
l’OMM aussitôt que possible après la fin du contrôle, mais pas plus tard que le 15 novembre.
7.
Rôle du Secrétariat de l’OMM
Le Secrétariat veillera à ce que les Membres concernés soient bien conscients de leurs
responsabilités et recueillera les résultats statistiques du contrôle coordonné à l’échelle internationale. Il en
établira la synthèse et évaluera l’efficacité et les lacunes du fonctionnement de la VMM, dans son ensemble
et dans ses différentes parties. Il devra dans ce contexte contrôler le programme d’observation de chaque
station. Les résultats du contrôle seront portés à la connaissance du Conseil exécutif et de la CSB, soit par
correspondance, soit lors des sessions de ces organes. Le Secrétariat prendra, en accord avec les Membres
intéressés, les mesures requises pour combler aussi vite que possible les lacunes que le contrôle aura révélées
dans le fonctionnement du SMO et du SMT.
8.
Types particuliers de contrôle différé du fonctionnement de la VMM
En cas de besoin, le contrôle du fonctionnement de la VMM peut se faire dans différentes
régions et pour différents types de données d’observation. Il a alors pour but de préciser les lacunes
constatées dans le rassemblement et l’échange des données dans différentes parties du SMT, ainsi que leurs
causes. Des contrôles spéciaux devraient être entrepris à l’initiative du Secrétaire général ou de quelques
Membres intéressés. Leurs dates et leur durée seront fixées après entente avec ces derniers.
*
* *
Édition 2009
S/N **
00
06
12
18
HH (UTC) + 1 heure
Total
00
06
12
18
HH (UTC) + 2 heures
* Référence pour la liste des messages d’observation à échanger mondialement: Manuel du SMT — Amendement . . .
** S = données attendues.
N = données non attendues.
Indicatif de
la station*
IIiii
Total
00
06
12
18
HH (UTC) + 6 heures
Total
Période de contrôle: ………………………………………………………………….....
Nombre de messages d’observation SYNOP reçus dans les délais prévus après l’heure de l’observation
Centre de contrôle: …………………………………………………………………
FORMULAIRE A — STATISTIQUES SUR LA RéCEPTION DES MESSAGES D’OBSERVATION SYNOP
DESTINéS à ÊTRE éCHANGéS MONDIALEMENT
SUPPLéMENT I-5
I-5/13
Édition 2009
Édition 2009
S/N **
00
06
12
18
Total
HH (UTC) + 2 heures
00
06
12
18
Total
HH (UTC) + 12 heures
00
06
12
18
Total
HH (UTC) + 2 heures
Indicatif de
la station*
IIiii
00
06
12
18
Total
Nombre de messages d’observation PILOT (partie A) reçus
dans les délais prévus après l’heure de l’observation
Nombre de messages d’observation TEMP (partie A) reçus
FORMULAIRE B1 — STATISTIQUES SUR LA RéCEPTION DES MESSAGES D’OBSERVATION TEMP ET PILOT
(pARTIE A) DESTINéS à ÊTRE éCHANGéS MONDIALEMENT
I-5/14
ORGANISATION DU SMT
S/N **
00
06
12
18
Total
HH (UTC) + 2 heures
00
06
12
18
Total
00
06
12
18
Total
HH (UTC) + 2 heures
Indicatif de
la station*
IIiii
00
06
12
18
Total
Nombre de messages d’observation PILOT (partie B) reçus
Nombre de messages d’observation TEMP (partie B) reçus
FORMULAIRE B2 — STATISTIQUES SUR LA RéCEPTION DES MESSAGES D’OBSERVATION TEMP ET PILOT
(pARTIE B) DESTINéS à ÊTRE éCHANGéS MONDIALEMENT
SUPPLéMENT I-5
I-5/15
Édition 2009
Édition 2009
*
**
S/N **
Bulletins
Messages
d’observation
0000 UTC
Bulletins
Messages
d’observation
0600 UTC
Bulletins
Messages
d’observation
1200 UTC
Bulletins
Messages
d’observation
1800 UTC
Bulletins
Voir la liste jointe des en-têtes abrégés des bulletins SHIP destinés à être échangés mondialement, établie par le Secrétariat de l’OMM pour chaque contrôle
(référence: Catalogue des bulletins météorologiques, édition . . . .).
S = données attendues.
En-tête
abrégé*
T1T2A1A2ii CCCC
Messages
d’observation
Total
Nombre de bulletins et de messages d’observation SHIP reçus dans les 2 heures qui suivent l’heure de l’observation
FORMULAIRE C1 — STATISTIQUES SUR LA RéCEPTION DES MESSAGES D’OBSERVATION SHIP
I-5/16
ORGANISATION DU SMT
*
**
S/N **
Bulletins
Messages
d’observation
0000 UTC
Bulletins
Messages
d’observation
0600 UTC
Bulletins
Messages
d’observation
1200 UTC
Bulletins
Messages
d’observation
1800 UTC
Bulletins
Voir la liste jointe des en-têtes abrégés des bulletins SHIP destinés à être échangés mondialement, établie par le Secrétariat de l’OMM pour chaque contrôle
(référence: Catalogue des bulletins météorologiques, édition . . . .).
En-tête
abrégé*
T1T2A1A2ii CCCC
Messages
d’observation
Total
Nombre de bulletins et de messages d’observation SHIP reçus dans les 12 heures qui suivent l’heure de l’observation
FORMULAIRE C2 — STATISTIQUES SUR LA RéCEPTION DES MESSAGES D’OBSERVATION SHIP
SUPPLéMENT I-5
I-5/17
Édition 2009
Édition 2009
S/N **
Bulletins
Messages
d’observation
0000 UTC
Bulletins
Messages
d’observation
0600 UTC
Bulletins
Messages
d’observation
1200 UTC
Bulletins
Messages
d’observation
1800 UTC
Bulletins
Messages
d’observation
Total
*
Voir la liste jointe des en-têtes abrégés des bulletins TEMP SHIP destinés à être échangés mondialement, établie par le Secrétariat de l’OMM pour chaque contrôle (référence: Catalogue des bulletins météorologiques, édition . . . .).
En-tête
abrégé*
T1T2A1A2ii CCCC
Nombre de bulletins et de messages d’observation TEMP SHIP (partie A) reçus dans les 12 heures qui suivent l’heure de l’observation
FORMULAIRE D1 — STATISTIQUES SUR LA RéCEPTION DES MESSAGES D’OBSERVATION TEMP SHIP
(PARTIE A) DESTINéS à ÊTRE éCHANGéS MONDIALEMENT
I-5/18
ORGANISATION DU SMT
**
*
S/N **
Bulletins
Messages
d’observation
0000 UTC
Bulletins
Messages
d’observation
0600 UTC
Bulletins
Messages
d’observation
1200 UTC
Bulletins
Messages
d’observation
1800 UTC
Bulletins
Messages
d’observation
Total
En-tête
abrégé*
T1T2A1A2ii CCCC
Nombre de bulletins et de messages d’observation TEMP SHIP (partie A) reçus dans les 24 heures qui suivent l’heure de l’observation
SUPPLéMENT I-5
I-5/19
Édition 2009
Édition 2009
**
*
S/N **
Bulletins
Messages
d’observation
0000 UTC
Bulletins
Messages
d’observation
0600 UTC
Bulletins
Messages
d’observation
1200 UTC
Bulletins
Messages
d’observation
1800 UTC
Bulletins
Messages
d’observation
Total
En-tête
abrégé*
T1T2A1A2ii CCCC
Nombre de bulletins et de messages d’observation TEMP SHIP (partie B) reçus dans les 12 heures qui suivent l’heure de l’observation
(PARTIE B) DESTINéS à ÊTRE éCHANGéS MONDIALEMENT
I-5/20
ORGANISATION DU SMT
S/N **
Bulletins
Messages
d’observation
0000 UTC
Bulletins
Messages
d’observation
0600 UTC
Bulletins
Messages
d’observation
1200 UTC
Bulletins
Messages
d’observation
1800 UTC
Bulletins
Messages
d’observation
Total
*
En-tête
abrégé*
T1T2A1A2ii CCCC
Nombre de bulletins et de messages d’observation TEMP SHIP (partie B) reçus dans les 24 heures qui suivent l’heure de l’observation
SUPPLéMENT I-5
I-5/21
Édition 2009
Édition 2009
S/N **
Bulletins
Messages
d’observation
0000 UTC
Bulletins
Messages
d’observation
0600 UTC
Bulletins
Messages
d’observation
1200 UTC
Bulletins
Messages
d’observation
1800 UTC
Bulletins
Messages
d’observation
Total
*
Voir la liste jointe des en-têtes abrégés des bulletins PILOT SHIP destinés à être échangés mondialement, établie par le Secrétariat de l’OMM pour chaque contrôle (référence: Catalogue des bulletins météorologiques, édition . . . .).
En-tête
abrégé*
T1T2A1A2ii CCCC
Nombre de bulletins et de messages d’observation PILOT SHIP (partie A) reçus dans les 12 heures qui suivent l’heure de l’observation
FORMULAIRE D5 — STATISTIQUES SUR LA RéCEPTION DES MESSAGES D’OBSERVATION PILOT SHIP
I-5/22
ORGANISATION DU SMT
S/N **
Bulletins
Messages
d’observation
0000 UTC
Bulletins
Messages
d’observation
0600 UTC
Bulletins
Messages
d’observation
1200 UTC
Bulletins
Messages
d’observation
1800 UTC
Bulletins
Messages
d’observation
Total
*
En-tête
abrégé*
T1T2A1A2ii CCCC
Nombre de bulletins et de messages d’observation PILOT SHIP (partie A) reçus dans les 24 heures qui suivent l’heure de l’observation
SUPPLéMENT I-5
I-5/23
Édition 2009
Édition 2009
S/N **
Bulletins
Messages
d’observation
0000 UTC
Bulletins
Messages
d’observation
0600 UTC
Bulletins
Messages
d’observation
1200 UTC
Bulletins
Messages
d’observation
1800 UTC
Bulletins
Messages
d’observation
Total
*
En-tête
abrégé*
T1T2A1A2ii CCCC
Nombre de bulletins et de messages d’observation PILOT SHIP (partie B) reçus dans les 12 heures qui suivent l’heure de l’observation
I-5/24
ORGANISATION DU SMT
S/N **
Bulletins
Messages
d’observation
0000 UTC
Bulletins
Messages
d’observation
0600 UTC
Bulletins
Messages
d’observation
1200 UTC
Bulletins
Messages
d’observation
1800 UTC
Bulletins
Messages
d’observation
Total
*
En-tête
abrégé*
T1T2A1A2ii CCCC
Nombre de bulletins et de messages d’observation PILOT SHIP (partie B) reçus dans les 24 heures qui suivent l’heure de l’observation
SUPPLéMENT I-5
I-5/25
Édition 2009
Édition 2009
S/N ***
Nombre de
Nombre de messages
bulletins d’observation
Nombre de
bulletins
Nombre de
messages
d’observation
Bulletins
compilés entre
0300* et 0859* UTC
et reçus
avant 1100 UTC
Nombre de
bulletins
Nombre de
messages
d’observation
Bulletins
compilés entre
0900* et 1459* UTC
et reçus
avant 1700 UTC
Nombre de
messages
d’observation
Total
Nombre de
Nombre de
Nombre de
messages
bulletins d’observation bulletins
Bulletins
compilés entre
1500* et 2059* UTC
et reçus
avant 2300 UTC
* Heure de compilation = GGgg inclus dans l’en-tête abrégé.
** Voir la liste jointe des en-têtes abrégés des bulletins BUOY destinés à être échangés mondialement, établie par le Secrétariat de l’OMM pour chaque contrôle (référence: Catalogue des bulletins météorologiques, édition . . . .).
*** S = données attendues.
En-tête
abrégé**
T1T2A1A2ii CCCC
Bulletins
compilés entre
2100* et 0259* UTC
et reçus
avant 0500 UTC
FORMULAIRE E — STATISTIQUES SUR LA RéCEPTION DES MESSAGES D’OBSERVATION BUOY
I-5/26
ORGANISATION DU SMT
S/N ***
Nombre de
Nombre de messages
bulletins
d’observation
Nombre de
bulletins
Nombre de
messages
d’observation
Bulletins
compilés entre
0900* et 1459* UTC
et reçus
avant 1700 UTC
Nombre de
Nombre de
messages
bulletins
d’observation
Bulletins
compilés entre
0300* et 0859* UTC
et reçus
avant 1100 UTC
Nombre de
bulletins
Nombre de
messages
d’observation
Total
Nombre de
Nombre de
messages
d’observation bulletins
Bulletins
compilés entre
1500* et 2059* UTC
et reçus
avant 2300 UTC
** Voir la liste jointe des en-têtes abrégés des bulletins AIREP destinés à être échangés mondialement, établie par le Secrétariat de l’OMM pour chaque contrôle (référence: Catalogue des bulletins météorologiques, édition . . . .).
En-tête
abrégé**
T1T2A1A2ii CCCC
Bulletins
compilés entre
2100* et 0259* UTC
et reçus
avant 0500 UTC
FORMULAIRE F — STATISTIQUES SUR LA RéCEPTION DES COMPTES RENDUS AIREP
SUPPLéMENT I-5
I-5/27
Édition 2009
Édition 2009
S/N ***
Nombre de
Nombre de messages
bulletins
d’observation
Nombre de
bulletins
Nombre de
messages
d’observation
Bulletins
compilés entre
0300* et 0859* UTC
et reçus
avant 1100 UTC
Nombre de
bulletins
Nombre de
messages
d’observation
Bulletins
compilés entre
0900* et 1459* UTC
et reçus
avant 1700 UTC
Nombre de
bulletins
Nombre de
messages
d’observation
Total
Nombre de
Nombre de
messages
d’observation bulletins
Bulletins
compilés entre
1500* et 2059* UTC
et reçus
avant 2300 UTC
** Voir la liste jointe des en-têtes abrégés des bulletins AMDAR destinés à être échangés mondialement, établie par le Secrétariat de l’OMM pour chaque contrôle (référence: Catalogue des bulletins météorologiques, édition . . . .).
En-tête
abrégé**
T1T2A1A2ii CCCC
Bulletins
compilés entre
2100* et 0259* UTC
et reçus
avant 0500 UTC
FORMULAIRE G — STATISTIQUES SUR LA RéCEPTION DES COMPTES RENDUS AMDAR
I-5/28
ORGANISATION DU SMT
S/N**
de réception
Date/Heure
Nombre de
messages
d’observation
T1T2A1A2ii CCCC YYGGgg (BBB)
En-tête abrégé*
S/N**
de réception
Date/Heure
BATHY/TESAC/TRACKOB
Nombre de
messages
d’observation
Voir la liste jointe des en-têtes abrégés des bulletins BATHY/TESAC/TRACKOB destinés à être échangés mondialement, établie par le Secrétariat de l’OMM pour chaque contrôle (référence: Catalogue des bulletins météorologiques, édition . . . .).
*
T1T2A1A2ii CCCC YYGGgg (BBB)
En-tête abrégé*
BATHY/TESAC/TRACKOB
FORMULAIRE H — STATISTIQUES SUR LA RéCEPTION DES MESSAGES D’OBSERVATION BATHY/TESAC/TRACKOB
SUPPLéMENT I-5
I-5/29
Édition 2009
Édition 2009
S/N**
Reçus entre le
1er et le 5 octobre
Reçus entre le
6 et le 15 octobre
Indicatif de la station*
IIiii
S/N**
Reçus entre le
1er et le 5 octobre
Messages CLIMAT
Reçus entre le
6 et le 15 octobre
* Référence pour la liste des messages à échanger mondialement: Manuel du SMT — Amendement . . .
IIiii
Messages CLIMAT
FORMULAIRE I1 — STATISTIQUES SUR LA RéCEPTION DES MESSAGES CLIMAT
I-5/30
ORGANISATION DU SMT
S/N**
Reçus entre le
1er et le 5 octobre
Reçus entre le
6 et le 15 octobre
IIiii
S/N**
Reçus entre le
1er et le 5 octobre
Reçus entre le
6 et le 15 octobre
* Référence pour la liste des messages à échanger mondialement: Manuel du SMT — Amendement . . .
IIiii
FORMULAIRE I2 — STATISTIQUES SUR LA RéCEPTION DES MESSAGES CLIMAT TEMP
SUPPLéMENT I-5
I-5/31
Édition 2009
Édition 2009
2
Les bulletins et
les messages
d’observation
ne sont-ils
comptés que
s’ils sont reçus
ou transmis
sur les voies
du SMT?
3
Les bulletins
en double
sont-ils laissés
de côté?
4
Les bulletins
qui ne
contiennent
que des
messages
d’observation
portant la
mention NIL
sont-ils
comptés?
5
Les bulletins
portant la
mention COR
ou CCx sontils comptés
en plus des
bulletins à
corriger?
6
Les messages
d’observation
en double
contenus dans
les bulletins
comportant
le même entête abrégé
sont-ils laissés
de côté?
7
Les messages
d’observation
en double
contenus dans
les bulletins
ayant des entêtes abrégés
différents
sont-ils laissés
de côté?
8
Les messages
d’observation
portant la
mention NIL
sont-ils laissés
de côté?
9
Les messages
d’observation
contenus dans
les bulletins
portant la
mention COR
ou CCx sontils laissés de
côté en plus
des messages
à corriger?
10
Les comptes
rendus AIREP/
AMDAR
correspondant
à diverses
positions
durant un
même vol
sont-ils
comptés
séparément?
11
Une réponse positive (“oui”) à toutes les questions posées dans le formulaire J correspond à une application correcte des procédures de contrôle. Les questions 7, 8 et 10 ne
s’appliquent qu’aux messages SYNOP, TEMP, PILOT, CLIMAT et CLIMAT TEMP.
Le contrôle Est-il procédé
est-il
au comptage
automatique? des bulletins et
des messages
d’observation
avant le contrôle
de qualité?
1
………………………………………………………………………………………………………………………………………………………………………………………………………...................................
Remarques: ………………………………………………………………………………………………………………………………………………………………………………………....................................
Note:
(oui ou non)
Réponse:
Question:
FORMULAIRE J — QUESTIONNAIRE RELATIF à L’APPLICATION DES PROCéDURES DE CONTRÔLE PAR LES CENTRES
I-5/32
ORGANISATION DU SMT
Motifs et nature de l’interruption
Livraison retardée des ballons
Livraison retardée de la soude caustique
Pénurie de personnel
IIiii
IIiii
IIiii
Motifs et nature de l’interruption
Indicatif de station
IIiii
Exemple:
Indicatif de station
IIiii
0000 UTC
0600 UTC 1200 UTC 1800 UTC
TEMP
PILOT
SYNOP
Type du message
2
5
7
0000 UTC
5
7
0600 UTC
1
5
7
4
7
1200 UTC 1800 UTC
Nombre de messages d’observation (SYNOP, TEMP ou PILOT)
non établis pour chaque heure d’observation
Type du message
Nombre de messages d’observation (SYNOP, TEMP ou PILOT)
non établis pour chaque heure d’observation
FORMULAIRE K — INTERRUPTION DES PROGRAMMES D’OBSERVATION AUX STATIONS D’OBSERVATION
SUPPLéMENT I-5
I-5/33
Édition 2009
Édition 2009
48 heures, à compter du 2 octobre à 0645 UTC
15 heures, à compter du 3 octobre à 0900 UTC
2) CMN – CMN
(CRT – CRT)
Durée de l’interruption
1) IIiii – CMN
Circuit reliant . . . et . . .
Durée de l’interruption
Mauvaise propagation en ondes
radioélectriques
Panne d’émetteur
Remarques
Remarques
Note: Lorsque la cause de l’interruption est connue, prière de l’indiquer dans la colonne “Remarques”.
Exemple:
Circuit reliant . . . et . . .
FORMULAIRE L — INTERRUPTION DE LA TRANSMISSION SUR LES CIRCUITS
I-5/34
ORGANISATION DU SMT
SUPPLéMENT I-5
Note:
I-5/35
Voir la publication Messages météorologiques (OMM-N° 9), Volume C1 — Catalogue des bulletins météorologiques, pour les listes des en-têtes abrégés des bulletins SHIP, TEMP SHIP (parties A et B), PILOT SHIP
(parties A et B), BUOY, AIREP, AMDAR et BATHY/TESAC destinés à être échangés mondialement. Le Secrétariat de l’OMM joindra ces listes à la lettre d’invitation à participer aux contrôles.
–––––––––––––––
Édition 2009
PARTIE II
PROCéDURES D’EXPLOITATION DU
SYSTèME MONDIAL DE TéLéCOMMUNICATIONS
PARTIE II
PROCÉDURES D’EXPLOITATION DU SYSTÈME MONDIAL DE TÉLÉCOMMUNICATIONS
Explications concernant les termes employés
Les termes indiqués ci-après étant fréquemment employés tout au long de cette partie, il
apparaît utile d’en préciser le sens:
Information météorologique Information météorologique sous forme alphanumérique, binaire ou
graphique.
Données météorologiques
■
Information météorologique présentée sous forme alphanumérique ou
binaire.
Message météorologique
Message comportant un seul bulletin météorologique, précédé d’une ligne
préliminaire et suivi de signaux de fin de message.
régulier
Message météorologique transmis suivant un plan de distribution préétabli.
non régulier
Message météorologique transmis en dehors de tout plan de distribution
préétabli.
1.
PRINCIPES D’EXPLOITATION APPLICABLES AU SYSTÈME MONDIAL DE TÉLÉCOMMUNICATIONS
Principe 1
Sur le réseau principal de télécommunications et sur les réseaux régionaux de
télécommunications météorologiques du Système mondial de télécommunications, les données
météorologiques doivent être rassemblées, échangées et distribuées sous forme de bulletins
météorologiques.
Principe 2
La forme de présentation des messages météorologiques dépend de la méthode
d’exploitation et des caractéristiques techniques des circuits et des centres.
Principe 3
Les formes de présentation des messages doivent être telles qu’elles puissent se prêter aux
opérations automatiques de commutation, de sélection et de composition, ainsi qu’à l’exploitation
manuelle dans les centres de télécommunications; elles doivent également tenir compte de la nécessité
de permettre le traitement automatique du contenu des bulletins.
Principe 4
La transmission d’informations météorologiques sur le SMT doit être conforme aux
programmes de transmission qui ont été adoptés.
Principe 5
Les messages météorologiques non réguliers et les messages de service doivent être transmis
sous forme de messages adressés.
Principe 6
priorité.
Les programmes de transmission doivent être établis en fonction de quatre degrés de
Édition 2009
II-
PROCéDURES D’EXPLOITATION DU SMT
2.
PROCÉDURES D’EXPLOITATION APPLICABLES AUX TRANSMISSIONS DES DONNÉES
MÉTÉOROLOGIQUES SUR LE SYSTÈME MONDIAL DE TÉLÉCOMMUNICATIONS
2.1
Forme de présentation des messages météorologiques
2.1.1
Un message météorologique
télécommunications, comprend:
régulier,
transmis
sur
le
Système
mondial
de
Une ligne préliminaire
Un en-tête abrégé
Un texte
Des signaux de fin de message
2.1.2
Chaque message météorologique ne doit comporter qu’un seul bulletin météorologique.
Bulletin
météorologique
Message
météorologique
2.1.3
Un message météorologique non régulier doit être présenté sous forme d’un message
adressé (voir la section 2.4 ci-après).
2.1.4
La ligne préliminaire, l’en-tête abrégé et les signaux de fin de message doivent être
présentés sous forme alphanumérique.
2.2
Jeux de caractères alphanumériques utilisés sur le SMT
2.2.1
Les alphabets devant être utilisés sur le SMT sont les suivants:
a) L’Alphabet télégraphique international N° 2;
b) L’Alphabet international N° 5.
Note: L’Alphabet télégraphique international N° 2 et l’Alphabet international N° 5 sont reproduits dans les
suppléments II-1 et II-2, respectivement.
2.2.2
Seuls les caractères imprimés pour lesquels il existe une correspondance dans les deux
alphabets doivent être utilisés. La conversion doit être faite conformément à la table de conversion
approuvée aux fins d’utilisation sur le SMT. Les caractères de commande de l’Alphabet international
N° 5 dont l’emploi sur le SMT a été approuvé doivent être utilisés.
Note: La table de conversion et les caractères de commande de l’Alphabet international N° 5, dont l’emploi sur
le SMT a été approuvé, figurent dans le supplément II-3.
2.2.3
Lorsqu’il est nécessaire de convertir des caractères de l’Alphabet N° 5 ne figurant pas dans
la table de conversion (supplément II-3) en caractères de l’Alphabet N° 2, on utilise le signal N° 2 (?)
de ce dernier alphabet.
2.2.4
L’Alphabet international N° 5 est utilisé pour la ligne préliminaire, l’en-tête abrégé et les
signaux de fin de message d’un message météorologique contenant de l’information en représentation
binaire.
2.3
Forme de présentation des messages météorologiques réguliers
Les procédures décrites ci-après sont appliquées pour la transmission des messages
météorologiques réguliers sur le SMT.
2.3.1
2.3.1.1
Ligne préliminaire
La ligne préliminaire se présente de la manière suivante:
a) Alphabet télégraphique international N° 2:
<– <– ≡ ↓ ZCZC → ↑nnn → → → → →
b) Alphabet international N° 5:
S
O
H
Édition 2009
C
R
C
R
L nnn
F
II-
Note: On trouvera dans le supplément II-4 des exemples de messages météorologiques réguliers, ainsi que la
signification des symboles utilisés dans l’Alphabet télégraphique international N° 2 et dans l’Alphabet
international N° 5.
2.3.1.2
nnn
La signification des symboles est la suivante:
Numéro de transmission. C’est un groupe de trois chiffres utilisé pour indiquer l’ordre dans lequel se
succèdent les messages transmis par un centre donné, sur une voie particulière, au centre récepteur
situé sur cette voie. On utilise cycliquement la suite des nombres 000 à 999 inclus. (Lorsque l’Alphabet international N° 5 est utilisé, le groupe nnn peut être une combinaison fixe de trois caractères,
conformément à des accords conclus entre les centres intéressés.)
Note: Un groupe de cinq chiffres pourrait être utilisé dans le cadre d’un accord bilatéral, sur des circuits dont la
vitesse devrait être d’au moins 64 kbit/s pour permettre la mise en œuvre de procédures appropriées de
récupération des données.
2.3.2
En-tête abrégé
2.3.2.1
L’en-tête abrégé se présente de la manière suivante:
<– <– ≡ ↓ T1T2A1A2 ↑ ii → ↓ CCCC → ↑YYGGgg (→ ↓ BBB)
C
R
C
R
L
F
T1T2A1A2 ii
S
P
CCCC
S
P
YYGGgg
(
S
P
BBB
)
Note: On trouvera dans le supplément II-4 des exemples de messages météorologiques réguliers, ainsi que la
signification des symboles utilisés dans l’Alphabet télégraphique international N° 2 et dans l’Alphabet
international N° 5.
2.3.2.2
La signification des symboles est la suivante:
T1T2A1A2ii
Indicateurs de données.
Note: Les indicateurs de données normalisés de l’OMM figurent dans le supplément II-5.
T1T2
Indicateurs de type et/ou de forme de données.
A1A2
Indicateurs géographique et/ou de type de données et/ou temporel.
ii
Il s’agit d’un nombre de deux chiffres. Si l’auteur ou le compilateur des bulletins diffuse plusieurs
bulletins avec les mêmes indicateurs T1T2A1A2 et CCCC, chaque bulletin a un nombre ii qui est unique
et qui est utilisé pour différencier les bulletins les uns des autres.
Les messages alphanumériques relatifs aux heures synoptiques principales et provenant de stations
qui font partie des réseaux synoptiques de base régionaux ou des stations des réseaux climatologiques
de base régionaux sont compilés pour former des bulletins dont le nombre ii sera compris entre 01
et 19. Cette règle ne s’applique pas aux bulletins en code CREX.
Les messages alphanumériques contenant des données “supplémentaires” au sens de la résolution 40
(Cg-XII) sont compilés pour former des bulletins dont le groupe ii est supérieur à 19. Cette règle ne
s’applique pas aux bulletins en code CREX.
Pour les bulletins en code GRIB, BUFR ou CREX ou ceux qui contiennent des informations graphiques,
l’utilisation du groupe ii est définie par les tableaux qui figurent dans le supplément II-5. Les auteurs
ou compilateurs de bulletins doivent utiliser les valeurs du groupe ii qui figurent dans ces tableaux
lorsqu’elles sont définies aux fins du bulletin en question.
Pour tous les bulletins, le groupe ii n’est utilisé que pour désigner des données “supplémentaires” au
sens de la résolution 40 (Cg-XII) si le même en-tête n’est jamais employé pour des données essentielles
et qu’il est conforme à l’ensemble des conditions ci-dessus. Si tel n’est pas le cas, un indicateur CCCC
unique est utilisé, comme indiqué ci-après.
CCCC Indicateur d’emplacement international de quatre lettres de la station ou du centre qui a établi le bulletin ou l’a compilé, selon les accords internationaux, publié dans Messages météorologiques (OMM-N° 9),
Volume C1 — Catalogue des bulletins météorologiques.
Pour différencier des ensembles de bulletins qu’il est impossible de distinguer d’après les indicateurs
T1T2A1A2ii, tout centre peut définir des indicateurs CCCC supplémentaires dont les deux derniers caractères
Édition 2009
II-
diffèrent de l’indicateur CCCC d’origine. Les deux premières lettres de tout indicateur CCCC supplémentaire qu’un centre pourrait définir doivent être les mêmes que celles de l’indicateur CCCC d’origine. On peut, par exemple, utiliser des indicateurs CCCC supplémentaires pour indiquer différents satellites,
différents modèles ou pour faire la différence entre des bulletins qui contiennent des données “indispensables” ou des données “supplémentaires” au sens de la résolution 40 (Cg-XII). Tous les indicateurs CCCC
définis par n’importe quel centre doivent être publiés et définis dans le Volume C1 — Catalogue des
bulletins météorologiques, de la publication Messages météorologiques (OMM-N° 9).
Une fois qu’un bulletin a été établi ou compilé, l’indicateur CCCC ne doit pas être modifié. Si pour une
raison quelconque, le contenu d’un bulletin est modifié ou si le bulletin est recompilé, l’indicateur CCCC
devrait être modifié pour indiquer le centre ou la station à l’origine de la modification.
YYGGggGroupe date-heure international.
YY
Jour du mois.
GGgg Pour les bulletins contenant des messages d’observation météorologique correspondant aux heures
standard d’observation, l’heure de l’observation est exprimée en heure UTC.
Pour les prévisions d’aérodrome, de route et de zone (pour l’aviation): heure entière UTC (les deux
derniers chiffres sont 00) précédant l’heure de transmission.
Pour les autres prévisions et analyses: heure standard UTC de l’observation ayant servi de base à la
prévision ou à l’analyse.
Pour les autres messages: heure de rédaction en heure UTC.
BBB
Un en-tête abrégé de la forme T1T2A1A2 ii CCCC YYGGgg ne doit être utilisé qu’une seule fois. En
conséquence, si cet en-tête abrégé doit servir à nouveau pour une adjonction, une correction ou un
amendement, il faut obligatoirement y ajouter un indicateur BBB approprié qui vient immédiatement
après le groupe date-heure.
L’indicateur BBB prend l’une des formes suivantes:
RRx pour la diffusion supplémentaire ou subséquente de bulletins;
CCx pour les corrections apportées à des bulletins retransmis précédemment;
AAx pour les amendements apportés à des bulletins retransmis précédemment;
où x est un caractère alphabétique compris entre A et X, selon les indications du supplément II-12.
La compilation des bulletins contenant des données d’observation ou des données climatiques (de surface
ou aérologiques) provenant de stations terrestres se fera suivant une liste de stations bien définie. Les
en-têtes abrégés et le contenu des bulletins sont publiés dans le Volume C1 — Catalogue des bulletins
météorologiques, de la publication Messages météorologiques (OMM-N° 9).
2.3.3
Contenu des bulletins météorologiques
2.3.3.1
Les procédures suivantes sont appliquées lors de la rédaction du texte d’un bulletin
météorologique:
a) Le texte d’un bulletin ne doit être rédigé que dans une seule forme symbolique;
b) Le texte d’un bulletin ne doit pas contenir à la fois des données “essentielles” et des données
“supplémentaires” telles qu’elles sont définies dans la résolution 40 (Cg-XII);
c) Le texte d’un bulletin doit être représenté sous forme alphanumérique ou binaire. Il doit commencer par la séquence suivante:
i) Quand l’Alphabet international N° 5 est utilisé:
C
R
C
R
L
F
ii) Quand l’Alphabet télégraphique international N° 2 est utilisé:
<– <–
≡ ↑ ou <
– <– ≡ ↓ selon le cas.
d) Lorsque tous les messages que contient normalement un message d’observation météorologique
régulier ne sont pas disponibles au moment normal de transmission, on doit envoyer le message
NIL.
Édition 2009
2.3.3.2
II-
Texte des bulletins météorologiques en représentation alphanumérique
2.3.3.2.1
Chaque message d’observation météorologique individuel commence au début d’une
nouvelle ligne.
2.3.3.2.2
Le signal N° 22 (rangée des chiffres) de l’Alphabet télégraphique international N° 2 ou
le signal 3/13 de l’Alphabet international N° 5 est utilisé comme signal de séparation des messages
d’observation météorologique. Ce signal suit le dernier chiffre du dernier groupe de chaque message,
sans qu’il soit laissé d’espace intermédiaire.
2.3.3.2.3
Forme de présentation des bulletins SYNOP et SHIP
a) La présentation des bulletins contenant des messages d’observation SYNOP et des messages d’observation SHIP dans les formes symboliques FM 12 et FM 13, respectivement, devrait revêtir l’une des deux
formes de présentation a) ou b) qui figurent au paragraphe 4 du supplément II-4.
b) Lors de l’emploi de la forme de présentation a), toutes les Sections 1, 2, 3 et 4 doivent être transmises
consécutivement et sans insertion d’espace, ni de barre oblique dans les groupes d’identification
des Sections 3 et 4. Si l’on emploie la forme de présentation b), les Sections 1, 2, 3 et 4 doivent
commencer au début de la ligne, mais les groupes d’identification des Sections 3 et 4 doivent
commencer à la suite de deux espaces en début de ligne.
Note: On trouvera des exemples de formes de présentation dans le supplément II-4.
2.3.3.2.4 Dans les bulletins de messages d’observation en altitude (TEMP et PILOT), chaque
partie successive (A, B, C et D) est immédiatement précédée d’un signal d’alignement (voir le
point 2.6.1 ci-après) et suivie d’un signal de séparation. Dans les bulletins de messages d’observation
en altitude (TEMP et PILOT), chaque message d’observation se rapportant à une même station est séparé
du message précédent par un signal supplémentaire de changement de ligne. En outre, dans les cas où
les parties A et B ou C et D sont transmises ensemble, elles sont séparées par huit signaux “retour
du chariot”.
2.3.3.2.5
Les comptes rendus AMDAR et AIREP contiennent des informations se rapportant à un seul
point d’observation pendant un vol.
2.3.3.2.6
Lorsque cela est possible et sauf dispositions spéciales contraires, le texte d’un bulletin
météorologique est transmis de manière à utiliser au maximum la capacité d’une ligne de télé-
imprimeur (69 caractères par ligne).
2.3.3.2.7
NIL — Dans le cas d’un message météorologique régulier contenant des messages
d’observation de stations dont la liste est publiée, notamment dans le Catalogue des bulletins
météorologiques, si le message d’observation d’une station n’est pas disponible au moment de la
transmission, l’indicatif de cette station doit figurer à sa place normale dans le bulletin, suivi de
l’indicateur NIL. La même procédure s’applique également aux autres informations codées (par exemple
CLIMAT, CLIMAT TEMP).
2.3.3.2.8
Le signal (/) (barre de fraction ou barre oblique) est utilisé pour indiquer les chiffres ou les
lettres manquants dans le texte des bulletins météorologiques. La barre de fraction ou barre oblique est
représentée par le signal N° 24 dans la rangée des chiffres de l’Alphabet télégraphique international N° 2 et
par le signal 2/15 de l’Alphabet international N° 5.
2.3.3.2.9
Les procédures exposées ci-dessus qui se rapportent aux bulletins contenant des messages
d’observation météorologique sont aussi applicables aux bulletins contenant d’autres renseignements
codés (tels que les messages TAF, CLIMAT, CLIMAT TEMP) provenant d’emplacements déterminés.
2.3.3.3
Texte des bulletins météorologiques en représentation binaire
2.3.3.3.1
Le texte des bulletins météorologiques en représentation binaire doivent se composer
d’un seul message et commencer par la séquence
C
R
C
R
L
F
suivie de l’indicateur de forme symbolique codé en Alphabet international N° 5.
2.3.3.3.2
NIL — Si des bulletins réguliers BUFR contiennent des messages météorologiques, tous les
champs des sous-ensembles pertinents de la Section 4 (Section de données) du message BUFR autres
Édition 2009
II-
que l’indicatif de station et les facteurs de répétition du descripteur doivent prendre la valeur
manquante appropriée lorsque le message émanant de cette station est inclus dans le contenu publié
du bulletin (dans le Catalogue des bulletins météorologiques et ailleurs) mais n’est pas disponible au
moment de la transmission.
2.3.4
Signaux de fin de message
Les signaux de fin de message se présentent de la manière suivante:
↓
<– <–
≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ NNNN ↓↓↓↓↓↓↓↓↓↓↓↓
Note: Les signaux de fin de message servent à assurer l’avancement de la page et de la bande perforée.
C
R
C
R
L
F
E
T
X
2.4
Messages adressés
2.4.1
Catégories de messages adressés
2.4.1.1
Messages de service
Priorité: 1
Messages relatifs au fonctionnement du système (par exemple interruption de service, reprise du service
après une panne, etc.).
2.4.1.2
Demande de bulletins disponibles sur le SMT
Priorité: 2
Messages pour demander l’envoi de bulletins normalement disponibles sur le SMT, y compris
les demandes de répétition.
2.4.1.3
Messages administratifs
Priorité: 4
Messages utilisés pour communiquer d’administration à administration. Dans des circonstances
exceptionnelles, les messages administratifs très urgents pourraient être transmis sous forme de messages de
service.
2.4.1.4
Messages de données
Priorité: 2
Messages contenant des données météorologiques. Ce type de message peut être utilisé soit
pour répondre à une demande de bulletins disponibles sur le SMT lorsque la réponse revêt la forme d’un
message adressé, soit en réponse à un message d’interrogation d’une base de données, soit encore pour
transmettre des données dans le cadre d’accords particuliers.
2.4.1.5
Interrogation d’une base de données
Priorité: 2
Messages utilisés pour interroger une base de données.
2.4.2
En-têtes abrégés des messages adressés
Les spécifications des en-têtes abrégés des messages adressés sont les suivantes:
T1T2A1A2ii CaCaCaCa YYGGgg (BBB)
T1T2 = BM, indicateur de message adressé sous forme alphanumérique
T1T2 = BI, indicateur de message adressé sous forme binaire
A1A2 = AA, message administratif
Édition 2009
II-
BB, message de service
RR, message de demande de bulletins disponibles sur le SMT
RQ, message d’interrogation d’une base de données
DA, message de données
ii = 01
CaCaCaCa = indicateur d’emplacement du centre destinataire
YYGGgg = heure d’insertion sur le SMT.
2.4.3
Texte des messages adressés
La première ligne du texte d’un message adressé doit être constituée de l’indicateur
international d’emplacement du centre d’origine. Le texte du message proprement dit doit commencer
à la deuxième ligne.
2.5
Demandes de messages sur le SMT
2.5.1
Le message est la plus petite unité pouvant faire l’objet d’une demande sur le SMT. Toutes
les demandes de messages disponibles sur le SMT, en particulier les demandes de répétition, doivent
être adressées le plus rapidement possible, sous peine que le ou les message(s) demandé(s) ne soi(en)t
plus disponible(s) (voir aussi le paragraphe 2.10.2.2).
2.5.2
Messages de demande
2.5.2.1
Les demandes de messages disponibles sur le SMT sont faites au moyen de messages adressés de
demande de messages disponibles sur le SMT (voir les paragraphes 2.4.1.2, 2.4.2 pour les en-têtes abrégés et 2.4.3
pour la première ligne du texte du message).
2.5.2.2
Les messages demandés sont identifiés par leurs en-têtes abrégés et tous les indicateurs
sont utilisés pour désigner un message particulier. Un message de demande ne peut pas contenir plus
de huit demandes lorsqu’il est adressé à un centre qui n’est pas directement relié au centre d’origine.
2.5.2.3
Toutes les lignes du texte du message commencent par l’indicateur AHD (sauf la première
ligne, voir le paragraphe 2.4.3). Elles se terminent toutes par le signal de séparation des messages
d’observation météorologique. Chaque ligne ne devrait comprendre qu’un seul en-tête abrégé de message
demandé.
2.5.3
Demandes de répétition
2.5.3.1
Les demandes de répétition de messages disponibles sur le SMT sont faites au moyen de
messages adressés, comme c’est le cas pour les demandes de messages disponibles sur le SMT, transmis
au centre relié situé en amont.
2.5.3.2
Outre les procédures définies aux paragraphes 2.5.2.2 et 2.5.2.3 ci-dessus, les messages dont
la répétition est demandée peuvent être désignés dans la demande par leur numéro de transmission sur le
circuit concerné. Dans ce cas, la deuxième ligne du texte du message doit commencer par l’indicateur
SQN, suivi du numéro de transmission ou d’une série de numéros de transmission séparés par “/”, ou
encore de numéros de transmission consécutifs (nnn - nnn).
2.5.3.3
Un message de demande de répétition ne doit contenir qu’une seule forme d’identification
pour déterminer les messages à répéter, à savoir par exemple les en-têtes abrégés (voir le paragraphe
2.5.2.3) ou les numéros de transmission (voir le paragraphe 2.5.3.2). Le nombre maximal de messages
pouvant être demandés au moyen d’un seul message de demande et identifié par des en-têtes abrégés peut
être décidé par voie d’accord bilatéral entre centres directement reliés.
2.5.4
Réponses aux demandes de messages disponibles sur le SMT
2.5.4.1
Pour les réponses, on doit utiliser la forme de présentation des messages adressés de
données (voir le paragraphe 2.4.1.4). Les centres voisins ont la possibilité de passer des accords bilatéraux
pour pouvoir utiliser la forme de présentation des messages d’observation réguliers pour répondre aux
demandes, en particulier aux demandes de répétition.
2.5.4.2
Un message adressé de données en réponse à une demande de message disponible sur le
SMT ne doit contenir qu’un seul message.
2.5.4.3
Il doit être répondu à toutes les demandes. Si un message demandé n’est pas disponible, un
message adressé de données (voir le paragraphe 2.4.1.4) est envoyé au centre demandeur et comporte
la spécification NIL suivie de l’indicateur servant à l’identification de ce message. Si une demande de
Édition 2009
II-
messages disponibles sur le SMT est incorrecte, un message adressé de données, comportant la spécification
ERR, suivie de l’indicateur incorrect, devrait être envoyé si possible au centre demandeur.
2.5.4.4
Les réponses aux messages de demande de répétition sont transmises dans les 30 minutes
qui suivent l’heure de dépôt des demandes.
Note: S’il n’est pas possible de répondre à toutes les demandes en même temps, les réponses aux demandes
laissées en suspens peuvent être transmises ultérieurement.
2.5.5
Demandes de répétition de transmissions en fac-similé analogique
2.5.5.1
Les demandes de répétition de transmissions en fac-similé analogique sont faites au
moyen de messages adressés (voir le paragraphe 2.4.1.2).
2.5.5.2
Toute demande doit comporter un seul identificateur du document requis et devrait,
de préférence, être adressée selon la forme de présentation utilisée pour les demandes de messages
météorologiques, l’en-tête abrégé servant d’identification.
2.5.5.3
Avant d’adresser une demande de répétition d’une transmission en fac-similé analogique,
il faudrait tenir compte de certains facteurs restrictifs tels que les horaires de transmission établis et les
priorités arrêtées pour d’autres produits.
Note: Lorsqu’une liaison point à point est utilisée, un centre qui demande une répétition peut préciser au centre
émetteur qu’à cette occasion le produit désiré pourrait être substitué à un document déterminé.
2.5.6
Réponses aux demandes de répétition de transmissions en fac-similé analogique
Avant de commencer la répétition d’une transmission en fac-similé analogique, un message
adressé de données devrait être envoyé au demandeur en indiquant l’heure de répétition prévue.
2.5.7
Messages d’accusé de réception
Les procédures d’accusé de réception provenant d’un centre qui reçoit un bulletin, qu’il adresse
à son centre d’origine ou à un autre centre (comme un centre relais) devraient être conformes aux messages
adressés normalisés qui passent par le SMT (voir la section 2.4 ci-dessus) en tant que messages administratifs
très urgents transmis comme messages de service. Un message adressé d’accusé de réception d’un bulletin
devrait se présenter ainsi:
BMBB01 CaCaCaCa YYGGgg (BBB)
CCCC
QSL TTAAii YYGGgg CoCoCoCo (BBB) (DDHHMM)
(texte facultatif)
Notes:
CaCaCaCa = indicateur d’emplacement du centre destinataire, qui est en général le centre d’origine du message
dont on accuse réception
CCCC = indicateur international d’emplacement du centre qui envoie l’accusé de réception
TTAAii CoCoCoCo YYGGgg (BBB) est l’en-tête abrégé du message dont on accuse réception, avec en préfixe le mot QSL.
DDHHMM est le groupe jour-heure (jour, heure et minute UTC) de réception du message dont on accuse réception
dans le centre CCCC, inséré au moment voulu.
La troisième ligne du texte du message est ajoutée selon les besoins.
Exemple:
BMBB01 PHEB 051132
AMMC
QSL WEIO21 PHEB 051130 051132
2.6
Procédures complémentaires applicables à la fois aux messages réguliers et aux messages adressés sous forme alphanumérique
2.6.1
Commande d’alignement
2.6.1.1
Les commandes d’alignement, qui assurent une mise en page correcte des éléments des
messages sur les appareils, sont les suivantes:
Deux signaux “retour du chariot”; Un signal “changement de ligne”.
2.6.1.2
Les signaux de commande d’alignement sont transmis avant chaque ligne du texte.
Édition 2009
II-
2.6.1.3
Lorsqu’on utilise l’Alphabet télégraphique international N° 2 pour annuler l’effet d’un
passage accidentel de la position “chiffres” à la position “lettres”, et vice versa, lors de la transmission
de la commande d’alignement, une impulsion “chiffres” (signal N° 30) ou une impulsion “lettres”
(signal N° 29), selon le cas, suit immédiatement la commande d’alignement.
2.6.2
Procédures de correction
Les procédures de correction, tant avec l’Alphabet télégraphique international N° 2
qu’avec l’Alphabet international N° 5, sont les suivantes:
a) Les erreurs commises lors de la préparation d’une bande et immédiatement détectées sont
corrigées par un recul de la bande, si cela est possible, et la suppression de l’erreur par perforation,
sur la partie erronée, du signal “lettres” dans l’Alphabet télégraphique international N° 2 et du
signal 7/15 (DEL) dans l’Alphabet international N° 5;
b) Si l’équipement ne se prête pas à un recul de la bande, on effectue immédiatement les corrections
en transmettant le signal “erreurs”: lettre E et signal “espace” répétés alternativement trois fois, puis
le dernier mot ou le dernier groupe correct; après quoi, la préparation de la bande est poursuivie;
c) La ligne préliminaire, l’en-tête abrégé et la fin de message d’un message météorologique régulier doivent être exempts de toute erreur de télécommunications. Il est interdit d’y apporter des
corrections sous quelque forme que ce soit, notamment d’utiliser le signal “erreur” ou de recourir
à l’effacement en utilisant le signal “lettres” (signal N° 29 de l’Alphabet N° 2).
2.7
Longueur des messages météorologiques
2.7.1
La longueur des messages est déterminée selon les critères ci-après:
2.7.1.1
Avant le 7 novembre 2007:
a) Les bulletins météorologiques non segmentés pour transmission sur le SMT ne doivent pas dépasser
15 000 octets;
b) Les bulletins météorologiques segmentés en une série de bulletins météorologiques pour transmission
sur le SMT ne doivent pas dépasser 250 000 octets dans leur forme originale ou après avoir été réunis.
2.7.1.2
À compter du 7 novembre 2007:
a) Les bulletins météorologiques transmis sur le SMT sous une forme de représentation alphanumérique
ne doivent pas dépasser 15 000 octets;
b) La limite actuelle de 15 000 octets pour les bulletins météorologiques transmis sous une forme de
représentation binaire ou sous forme graphique passe à 500 000 octets;
c) Les bulletins météorologiques ne seront plus segmentés pour transmission sur le SMT.
Note: Des informations météorologiques peuvent être échangées au moyen de la technique de transfert de fichier
décrite dans le supplément II-15, en particulier lorsque ces informations dépassent 250 000 octets.
2.7.2
La transmission des données d’observation ne devrait pas être inutilement retardée dans le seul
but d’attendre la possibilité de constituer un message ayant la longueur voulue.
2.7.3
II est rappelé que, pour les messages qui transiteront éventuellement sur le réseau du
service fixe des télécommunications aéronautiques (RSFTA), la longueur du texte ne doit pas dépasser
200 groupes.
2.8
Procédures applicables à la transmission des messages d’observation de navires et
d’autres stations maritimes
2.8.1
Les messages d’observation de navires et d’autres stations maritimes, transmis dans
la forme symbolique SHIP, doivent être précédés par l’indicatif d’appel du navire ou par un autre
indicateur approprié.
2.8.2
Dans le cas des navires météorologiques stationnaires, l’indicateur de la station océanique
doit précéder le message sur une ligne distincte.
2.8.3
Dans le cas des messages provenant de navires faisant route, l’indicatif d’appel est placé
au début de la première ligne de chaque message d’observation. Si l’indicatif d’appel n’est pas connu,
il est remplacé par le mot SHIP.
Édition 2009
II-10
2.9
Précision du temps dans les centres de télécommunications
Chaque centre doit prendre les mesures nécessaires pour faire en sorte que l’écart entre
l’heure affichée au centre de télécommunications et le temps universel n’excède jamais les valeurs
suivantes:
a) 30 secondes dans les centres manuels et les centres automatisés utilisant le système câblé;
b) 5 secondes dans les centres automatisés utilisant le système programmé.
2.10
Procédures relatives aux opérations devant être effectuées par les centres de
Les procédures exposées ci-après sont présentées sous forme de directives dont le but est de permettre aux centres chargés d’opérations de télécommunications d’effectuer ces opérations de manière efficace.
2.10.1
Délais
2.10.1.1
Les fonctions des centres de télécommunications météorologiques (voir la section 2 de la
partie I) devraient comprendre la conversion de vitesse et d’alphabet, la vérification des procédures et la
mise en forme de bulletins.
Note: L’exécution de ces opérations nécessite un certain temps qui se traduit par un délai dans l’acheminement.
Le délai est défini comme l’intervalle de temps séparant le moment où le message est reçu en totalité de
celui où il peut être retransmis sur une voie de sortie.
2.10.1.2
Lorsque la commutation des messages est automatique, le délai acceptable ne devrait pas être
supérieur à 15 secondes s’il n’y a conversion ni de vitesse ni d’alphabet, et à trois minutes dans le cas contraire.
2.10.1.3
Le temps mis par les centres pour vérifier les procédures, composer et mettre en forme les
bulletins devrait être de l’ordre de 15 secondes lorsque les renseignements sont acheminés uniquement sur
des circuits à grande vitesse, et de l’ordre de deux minutes lorsqu’il s’agit d’un circuit à vitesse lente.
2.10.2
Stockage de données
Les procédures ci-après devraient être appliquées pour l’emmagasinage de l’information en vue
de sa retransmission.
2.10.2.1
Les centres devraient stocker les données jusqu’à ce que la transmission faite au profit du centre
suivant ait été achevée. à cet effet, lorsque la transmission est faite sur un circuit sur lequel des accusés de
réception sont transmis, le stockage d’un message dans une mémoire à accès rapide n’est nécessaire que
jusqu’au moment où l’accusé de réception du message est reçu. Pour les circuits sur lesquels il n’est pas prévu
de procédures pour accuser réception des messages, il est suffisant de conserver chaque message pendant
30 minutes sur une mémoire à accès rapide. Le message devrait être supposé reçu si aucune demande de
retransmission n’a été reçue au cours de cet intervalle de temps.
2.10.2.2
Pour pouvoir répondre aux demandes de messages, les CMM et les CRT devraient conserver
pendant 24 heures les messages échangés sur le SMT.
2.10.3
Catalogues d’acheminement
2.10.3.1
Les procédures décrites ici sont recommandées pour l’échange des catalogues d’acheminement
des centres du SMT. Le catalogue d’acheminement est échangé sous la forme d’un fichier qui peut être
directement intégré dans la plupart des progiciels de bases de données pour contribuer à l’analyse du flux de
données du SMT. Les fichiers contenant des “catalogues d’acheminement” devraient être obtenus au moyen
d’un transfert de fichier FTP sur Internet, si possible, et devraient être disponibles dans chaque centre ou sur
le serveur de l’OMM. Le serveur de l’OMM devrait contenir une liste (avec des hyperliens) de tous les centres
qui disposent de catalogues d’acheminement à échanger. Tous les centres devraient fournir au Secrétariat de
l’OMM les adresses URL du site où leurs fichiers respectifs se trouvent.
2.10.3.2
Le catalogue d’acheminement d’un centre du SMT devrait indiquer les informations suivantes
pour chaque bulletin identifié par son en-tête abrégé TTAAii CCCC:
a) Le circuit du SMT sur lequel le bulletin est reçu;
b) La liste des circuits du SMT sur lesquels le bulletin est envoyé.
2.10.3.3
Chaque CRT devrait préparer un catalogue d’acheminement et le rendre accessible aux autres
centres du SMT, et en particulier aux CMN auxquels il est associé. Le répertoire d’acheminement devrait être
mis à jour tous les mois si possible, mais au minimum tous les trois mois.
Édition 2009
II-11
2.10.3.4
Un centre du SMT devrait inclure dans son catalogue d’acheminement les en-têtes abrégés de
tous les bulletins reçus et/ou transmis sur tout circuit du SMT relié à ce centre du SMT (circuits SMT point
à point, circuits SMT point-multipoint tels que les systèmes de distribution par satellite, y compris les
diffusions HF restantes). Tout bulletin censé être reçu par le centre du SMT, même s’il n’est pas réellement
transmis sur le SMT, devrait être inclus dans le catalogue d’acheminement.
2.10.3.5
Les bulletins reçus et/ou transmis sur un circuit établi en vertu d’un accord bilatéral d’échange
de données météorologiques devraient être inclus dans le catalogue d’acheminement.
2.10.3.6
La forme de présentation du catalogue d’acheminement et les procédures d’accès aux catalogues
d’acheminement sont indiquées dans le supplément II-7.
2.10.4
Révision du contenu des répertoires d’acheminement
Outre qu’ils doivent actualiser régulièrement les répertoires d’acheminement, tous les centres
automatisés du SMT doivent aussi procéder (tous les six mois par exemple), à la suppression des en-têtes
abrégés des bulletins qui ne doivent plus être échangés sur le SMT.
2.11
Procédures pour le stockage et la retransmission des données
2.11.1
Priorités à observer pour le stockage et la retransmission des données
2.11.1.1
La retransmission des messages doit être effectuée sur la base de quatre niveaux
de priorité. Le niveau de priorité est fondé sur le type de données (T1T2) et est indiqué dans le
tableau A du supplément II-5.
2.11.1.2
Au sein d’un même niveau de priorité, les messages sont transmis conformément au
principe “premier entré, premier sorti”.
2.11.1.3
Les messages d’un niveau de priorité plus élevé doivent être retransmis avant ceux d’un
niveau de priorité plus faible. Toutefois, la transmission d’un message de priorité plus élevée ne doit
pas interrompre la transmission d’un message déjà en cours.
2.11.2
Détection et suppression des messages en double
Tout message en double et, au moins, ceux reçus dans les trois heures après le message initial
devraient être repérés et supprimés.
2.12
Protocoles de communication de données sur le Système mondial de télécommunications
2.12.1
Les protocoles de transmission à utiliser pour le SMT sont des éléments des procédures
indiqués dans la recommandation UIT-T X.25 et le Transmission Control Protocol/Internet Protocol
(TCP/IP).
2.12.2
Procédures selon la recommandation UIT-T X.25
Les méthodes et éléments des procédures définies dans la recommandation UIT-T X.25 à utiliser
pour le SMT sont exposés dans les paragraphes qui suivent et dans le supplément II-13.
Note: Les références aux couches OSI sont tirées du Modèle de référence pour l’interconnexion des systèmes
ouverts (OSI) indiqué dans la Norme internationale ISO 7498 et la recommandation UIT-T X.200.
2.12.2.1
Couche physique (recommandation UIT-T X.25, couche physique, paragraphe 1/couche 1 OSI)
Les dispositions du paragraphe 1 de la recommandation UIT-T X.25 sont applicables aux
circuits point à point et à l’interface entre l’équipement terminal de traitement de données (ETTD) et
l’équipement de terminaison du circuit de données (ETCD).
2.12.2.2
Couche liaison (recommandation UIT-T X.25, couche liaison de données, paragraphe 2/couche 2 OSI)
du SMT.
Les dispositions qui suivent ne sont applicables qu’aux circuits point à point entre centres
Structure de trame:
Le format de trame est celui qui est décrit dans le tableau 1/
X.25 avec les paramètres suivants:
Champ d’adresse: un octet; Champ de commande: un octet.
Note: L’utilisation d’un champ de commande étendu à deux octets ou plus doit être étudiée de manière plus
approfondie.
Édition 2009
II-12
Champ d’information:
éléments de procédure:
259 octets obligatoires, 131 octets facultatifs sous réserve
d’un accord bilatéral entre centres intéressés.
Les éléments de procédures sont décrits dans la section 2.3 —
éléments des procédures LAPB — de la recommandation
UIT-T X.25.
Description des procédures: Les procédures sont décrites dans la section 2.4 — Description
de la procédure LAPB — de la recommandation UIT-T X.25.
Il est recommandé aux centres intéressés de conclure des accords bilatéraux afin que les CMM
et CRT jouent le rôle d’ETTD ou d’ETCD, et les CMN celui d’ETTD.
Les paramètres du système sont les suivants:
Temporisateur T1 : T1 > Durée de transmission de trois trames + durée de propagation
du signal bidirectionnel sur la liaison + durée maximale du
traitement d’une trame par un centre de réception donné.
Note: Exemples de valeurs du temporisateur T1 si la durée du traitement est de 10 millisecondes: Liaison en câble:
9600 bit/s: 0,4 seconde
Liaisons satellitaires: 9600 bit/s: 1,2 seconde
2400 bit/s: 2,4 secondes
Nombre maximal d’émissions N2:10
Nombre k de trames en anticipation: 2 ≤ k ≤ 7
Note: La Norme internationale ISO 7776 — Systèmes de traitement de l’information — Communication de
données — Procédures de commande de liaison de données à haut niveau — Description des procédures
de liaison d’équipement terminal de transmission de données ETTD compatible X.25 LAPB — décrit les
procédures X.25 de la couche 2, du point de vue de l’établissement d’une connexion directe entre un
ETTD et un ETCD et entre deux ETTD, sans l’intervention d’un réseau public de transmission de données
par commutation de paquets.
2.12.2.3
Couche réseau (recommandation UIT-T X.25, couche paquets, sections 3, 4, 5.1 à 5.5/couche 3 OSI)
La couche paquets dont il est question dans la recommandation UIT-T X.25 est utilisée,
conformément aux procédures relatives aux services de circuit virtuel permanent (CVP) et de
communication virtuelle (CV).
La longueur maximale du champ des données d’utilisateur est de 256 octets ou, à titre
facultatif, de 128 octets.
Taille W de la fenêtre: 2 ≤ W ≤ 7 suivant le type de circuit de communications et
l’équipement du système.
Une ou plusieurs voies logiques (CVP et/ou CV) devraient être établies entre deux centres
adjacents. à la technique du multiplexage physique (modems V.29, par exemple), il y a lieu de préférer celle
du multiplexage logique (CVP et/ou CV). Les procédures recommandées pour l’utilisation de CV, également
appelés circuits virtuels commutés (CVC), sont présentées dans le supplément II-14.
Note: Il est possible d’établir, par voie d’accord multilatéral, une ou plusieurs voies logiques (CVP et/ou CV)
entre des centres non adjacents.
Lorsque les procédures de la couche transport ne sont pas mises en œuvre, la “marque:
données à suivre” (élément binaire M) est utilisée pour identifier la séquence de paquets contenant le
message complet.
Note: La Norme internationale ISO 8208 — Systèmes de traitement de l’information — Communication de
données — Protocole X.25 de la couche paquets pour équipement terminal de traitement de données —
décrit les procédures X.25 de la couche paquets, du point de vue de l’établissement d’une connexion directe
entre un ETTD et un ETCD et entre deux ETTD, sans l’intervention d’un réseau public de transmission de
données par commutation de paquets.
2.12.2.4
Couche transport (couche 4 OSI)
Il convient d’utiliser un protocole de transport, conformément à la recommandation UIT-T
X.224. Lorsqu’elles sont appliquées, les procédures du protocole de la classe 2, y compris celles qui
assurent le multiplexage des connexions de transport, le contrôle explicite de flux et le transfert
accéléré de données, doivent être utilisées. On peut utiliser des protocoles des classes 3 ou 4, en plus de
celui de la classe 2, chaque fois que cela semblera nécessaire.
Édition 2009
II-13
2.12.3
Protocole TCP/IP
Les pratiques et procédures recommandées pour la mise en œuvre, l’exploitation et
l’application du Transmission Control Protocol/Internet Protocol (TCP/IP) sur le SMT sont présentées dans le
supplément II-15.
2.13
Transmission et collecte des bulletins météorologiques sur l’Internet
L’Internet peut servir à transmettre et à rassembler des bulletins météorologiques, en tant que
système de communication complémentaire à utiliser à titre d’essai ou dans certains cas particuliers, ou
encore lorsqu’une liaison spécialisée du SMT ne fonctionne pas. Il convient alors d’employer les méthodes
décrites dans le supplément II-16 pour ce qui concerne le courrier électronique (courriel) et/ou l’ingestion
de données Web, de façon à réduire au minimum les risques inhérents en matière de sécurité.
2.14
Procédures supplémentaires applicables aux transmissions par radiotéléimprimeur
En plus des procédures générales de télécommunications qui ont été exposées précé-
demment, certaines procédures particulières sont appliquées dans le cas des transmissions par
radiotéléimprimeur.
2.14.1
d’appel.
Identification
Une diffusion par radiotéléimprimeur doit être précédée de la transmission de signaux
2.14.1.1
Les signaux d’appel doivent comprendre: l’appel général à toutes les stations (transmis
trois fois), le signal conventionnel DE, l’identification de la station émettrice comprenant l’indicatif
radio suivi de l’indice ou des indices de référence de la fréquence (transmis trois fois) et les lettres RY
répétées sans interruption sur une ligne (69 caractères).
Exemple:
CQ
CQ
CQ
DE
WSY21/22
WSY21/22
RYRY --------------------------------------------------------------------------------------------RYRYRYR
69 caractères
2.14.1.2
Transmission des signaux d’appel
Les signaux d’appel doivent être transmis:
WSY21/22
a) Avant les émissions à heure fixe, au moins pendant les deux minutes qui précèdent l’heure officielle du début de l’émission;
b) Chaque fois que la station n’a pas de trafic pendant les périodes prévues pour l’émission;
c) Durant les cinq minutes précédant la première émission consécutive à un changement de
fréquence.
2.14.2
Procédures particulières pour les centres de relais
2.14.2.1
Dans les échanges par radiotéléimprimeur dans lesquels un centre de télécommunications
est chargé de retransmettre des bulletins émis à l’origine par un autre centre, l’en-tête abrégé du
bulletin retransmis ne doit pas être changé.
2.14.2.2
Lorsqu’un message reçu comporte une partie tronquée, le centre de relais retransmet
le message tel qu’il a été reçu et, si possible, essaie d’obtenir une retransmission par le centre
d’origine.
2.14.2.3
II faudrait établir des instructions nationales en ce qui concerne les mesures à prendre en
cas d’altération complète de certaines parties des messages, pour assurer que toutes les données encore
utilisables sont retransmises dans un délai minimal, en éliminant toutefois, lorsque cela se révèle possible,
les parties complètement altérées. Dans tous les cas où l’élimination mentionnée ci-dessus est effectuée,
l’abréviation INC devrait être ajoutée à la fin du bulletin pour indiquer que celui-ci est incomplet; le centre
de relais devrait prendre toutes les dispositions nécessaires pour recevoir du centre d’origine les parties du
bulletin ayant subi une altération et les retransmettre dès que possible.
Édition 2009
II-14
3.
PROCÉDURES APPLICABLES AUX TRANSMISSIONS DES INFORMATIONS MÉTÉOROLOGIQUES
SOUS FORME GRAPHIQUE SUR LE SYSTÈME MONDIAL DE TÉLÉCOMMUNICATIONS
3.1
Forme de présentation des renseignements météorologiques transmis sous forme
graphique
Les éléments d’identification qui devraient figurer dans le cartouche (dans le coin inférieur
gauche de la carte et, si possible, également dans le coin supérieur droit) sont fixés à l’échelon national.
Ces éléments, qui devraient être faciles à identifier, à lire et à interpréter, devraient donc inclure au moins
l’en-tête abrégé du bulletin d’information graphique.
3.2
Besoins en matière de retransmission d’informations en fac-similé analogique
3.2.1
Les retransmissions d’informations en fac-similé analogique devraient être effectuées par
stockage et retransmission ou par transmission directe (commutation directe) des signaux.
3.2.2
minimal.
Dans tous les cas, la retransmission d’informations en fac-similé devrait s’effectuer dans le délai
3.2.3
Des dispositifs de stockage et d’enregistrement de grande qualité, tels que des enregistreurs
sur bandes magnétiques, devraient être utilisés dans le système de stockage et de retransmission utilisé
pour l’acheminement d’informations en fac-similé analogique, afin de préserver la qualité de l’image au
cours des opérations de stockage et de retransmission. Toutes les caractéristiques techniques relatives
aux transmissions qui sont mentionnées à la section 5 de la partie III doivent être respectées lors du
stockage et de la retransmission.
3.2.4
Dans certains centres, le stockage peut être réalisé commodément au moyen d’un ordinateur
équipé d’un dispositif permettant de convertir les signaux analogiques reçus en signaux numériques et de
reconvertir ensuite ceux-ci en signaux analogiques pour leur retransmission.
3.2.5
Dans certains cas, les centres de transit pourraient assurer la retransmission des signaux de
fac-similé analogiques sans avoir besoin de les stocker; dans ces conditions, le temps de transit à travers les
tronçons consécutifs d’un réseau de télécommunications serait réduit au minimum.
3.2.6
Les centres qui ne sont pas équipés pour assurer les opérations de stockage et de
retransmission dans un délai de trois minutes, ou pour assurer la transmission en direct par
commutation, doivent pouvoir assurer le stockage sur bande magnétique ou sur un support équivalent,
de manière à retransmettre ensuite les documents reçus en fac-similé analogique. La capacité de
stockage doit être suffisante pour permettre de stocker au moins une image complète.
3.2.7
Les documents reçus sur papier au moyen des enregistreurs de cartes ne peuvent être
utilisés qu’exceptionnellement, à titre de secours, pour faciliter les opérations de stockage et de
retransmission.
3.3
Transmission périodique de la mire de l’OMM
La mire normalisée de l’OMM devrait être transmise périodiquement, conformément aux
demandes exprimées, sur toutes les parties du Système mondial de télécommunications où des transmissions
en fac-similé analogique sont régulièrement assurées.
Note: La mire normalisée de l’OMM est reproduite dans le supplément II-8.
3.4
Procédures de transmission en fac-similé numérique codé et non codé
La transmission en fac-similé numérique codé ou non codé devrait être effectuée selon l’une
des procédures suivantes:
a) Les données alphanumériques et les informations en fac-similé numérique devraient être transmises en
temps partagé sur une même liaison de données;
b) Les données alphanumériques et les informations en fac-similé numérique devraient être transmises
sur des voies distinctes, multiplexées par un modem conforme à la recommandation UIT-T V.29.
Note: Les procédures devant être appliquées sont indiquées dans le supplément II-9.
Édition 2009
4.
QUALITÉ DES TRANSMISSIONS MÉTÉOROLOGIQUES
4.1
Contrôle
II-15
Toute transmission de renseignements météorologiques doit être contrôlée périodiquement
par le centre d’origine afin d’être sûr que les procédures et spécifications recommandées sont bien
appliquées et que, par la suite, le bon fonctionnement du SMT sera satisfait.
4.2
Comptes rendus des conditions de réception
4.2.1
Les comptes rendus relatifs aux conditions de réception des transmissions météorologiques
par radiotélégraphie sont établis à l’aide de la forme symbolique RECEP.
Note: La forme symbolique RECEP figure dans le supplément II-10.
4.2.2
Les comptes rendus sur les conditions de réception sont transmis périodiquement par les
centres de réception aux centres responsables des émissions radio.
5.
PROCÉDURES À SUIVRE DANS LES CAS OÙ LES PUBLICATIONS DE L’OMM DOIVENT ÊTRE
AMENDÉES ET MÉTHODES DE NOTIFICATION DES AMENDEMENTS
5.1
Responsabilité en matière de notification d’amendements
Les informations figurant dans les publications de l’OMM doivent être constamment à
jour. Tout amendement doit être notifié au Secrétariat deux mois au moins avant la date à laquelle le
changement prévu interviendra effectivement.
5.2
Messages METNO et WlFMA
5.2.1
Les messages contenant des informations relatives aux Volumes A (Stations d’observation)
et C (Catalogue des bulletins météorologiques et Horaires de transmission) de la publication Messages
météorologiques (OMM-N° 9) sont identifiés à l’aide du nom de code METNO, tandis que les messages
contenant des informations relatives au Volume D (Renseignements pour la navigation maritime) de
ladite publication sont identifiés à l’aide du nom de code WlFMA. Les messages METNO contiennent
également, le cas échéant, des informations sur des changements importants dans les codes
météorologiques internationaux et dans les procédures de télécommunications.
Note: Afin de notifier au plus tôt les modifications à apporter aux Volumes A, C et D de la publication
Messages météorologiques (OMM-N° 9), le Secrétariat diffuse des messages METNO et WlFMA qui s’ajoutent
au service normal de suppléments à ces volumes.
5.2.2
Les messages METNO et WlFMA sont transmis de Genève au centre de Zurich qui
les retransmet au CRT associé en vue de leur distribution générale sur le Système mondial de
télécommunications.
5.2.3
Les messages METNO et WIFMA sont compilés selon la forme de présentation normalisée
des messages météorologiques réguliers, les en-têtes abrégés NOXX02 LSSW et NOXX01 LSSW étant
utilisés respectivement pour les modifications relatives au Volume C1 — Catalogue des bulletins
météorologiques, de la publication Messages météorologiques (OMM-N° 9) et pour les modifications
concernant les autres volumes de ladite publication.
Édition 2009
SUPPLéMENT II-1
ALPHABET TÉLÉGRAPHIQUE INTERNATIONAL n° 2*
1.
INTRODUCTION
1.1
La présente Recommandation définit le répertoire de caractères graphiques et de caractères
de commande utilisés dans l’Alphabet télégraphique international N° 2 (ATI N° 2), et leur représentation
codée pour les besoins des communications. Il contient aussi des dispositions sur l’utilisation de certaines
combinaisons particulières.
1.2
Le codage des caractères de l’ATI N° 2 est fondé sur une structure à 5 moments de code par
signal de caractère.
1.3
L’ATI N° 2 est défini également dans la Recommandation F.1 pour le service public international
des télégrammes, et la Recommandation F.60 précise qu’il doit être utilisé aussi pour le service télex. Il peut
être utilisé également pour d’autres usages, tels que liaisons spécialisées ou circuits loués.
1.4
Pour les définitions concernant la télégraphie alphabétique, on se reportera aux définitions de
la Recommandation R.140, et au vocabulaire électrotechnique international (VEI), chapitre 721.
2.
Répertoire des caractères
2.1
Les caractères graphiques auxquels correspond un signal dans l’ATI N° 2 sont les suivants:
les 26 caractères de l’alphabet latin:
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z;
les chiffres décimaux: 0 1 2 3 4 5 6 7 8 9;
les signes de ponctuation et signes divers:
Point
.
Virgule
,
Deux-points ou signe de division
:
Point d’interrogation
?
Apostrophe
’
Croix ou signe d’addition
+
Trait d’union ou tiret ou signe de soustraction
–
Barre de fraction ou signe de division
/
Signe “égal à” ou double trait
=
Parenthèse gauche (ouverture)
(
Parenthèse droite (fermeture)
)
2.2
Trois autres caractères graphiques (tels que lettres accentuées et signes monétaires) peuvent
être appliqués pour les besoins d’une utilisation nationale ou privée (voir le § 4.2).
2.3
La présente Recommandation ne définit pas la typographie particulière, le type de lettres
(lettres majuscules ou minuscules) des caractères graphiques; elle ne définit pas non plus l’agencement des
claviers sur les téléimprimeurs ou les dispositifs terminaux semblables.
2.4
Les caractères de commande de l’ATI N° 2 sont les suivants:
______
“qui êtes-vous ?” (commande de déclenchement de l’indicatif du poste correspondant),
déclenchement d’un signal audible au poste correspondant,
retour du chariot,
changement de ligne,
inversion lettres,
* Extrait du Livre bleu du CCITT, Tome VII, Fascicule VII.1. La Recommandation S.1 est reproduite après
autorisation préalable de l’Union internationale des télécommunications en tant que détentrice des droits de
reproduction.
édition 2009
II-1/2
inversion chiffres,
espace ou blanc,
espaces seulement ou nul (pas de perforation de la bande).
3.
Codage
3.1
Les 32 combinaisons possibles de l’ATI N° 2 se présentent sous la forme d’une séquence de
cinq éléments dont chacun peut représenter l’un de deux états significatifs (A ou Z), comme l’indique le
tableau 1/S.l.
3.2
L’état A correspond à la polarité de départ, à l’absence de perforation de la bande de papier et
au symbole 0 de la notation binaire. L’état Z correspond à la polarité d’arrêt, à la perforation de la bande de
papier et au symbole 1 dans la notation binaire.
En ce qui concerne les modulations de fréquence et d’amplitude équivalentes correspondant aux états A et
Z dans les équipements de téléphonie harmonique, voir la Recommandation V.1 et les Recommandations
pertinentes de la série R.
Remarque 1: Le niveau et la polarité de la tension et du courant correspondant aux états A et Z (par exemple,
dans l’ensemble terminal) sont des options nationales. Ils ne sont par conséquent pas définis sur le
plan international.
Remarque 2: Les termes “départ” et “arrêt” ou “travail” et “repos” ont aussi été utilisés pour désigner respectivement les états A et Z (voir définition 31.37 de la Recommandation R.140).
4.
Combinaisons particulières
4.1
Conformément aux dispositions de la Recommandation S.8 et des Recommandations de la
série U, le signal WRU (Qui êtes-vous?, combinaison N° 4 dans la série des chiffres) est utilisé dans les
services internationaux télex et gentex pour déclencher l’émetteur d’indicatif de l’appareil correspondant,
et peut provoquer l’impression d’un graphisme (voir le tableau 2/S.l).
4.2
étant donné que certaines Administrations font usage de la latitude d’affecter les combinaisons
Nos 6, 7 et 8 de la rangée des chiffres à des usages intérieurs, il est désirable dans ces conditions de réduire
les inconvénients pouvant résulter de cette latitude dans le service international. En conséquence, l’emploi
des combinaisons Nos 6, 7 et 8 de la rangée des chiffres n’est pas défini dans le service international, sauf
arrangement direct entre Administrations, et il est recommandé:
que tous les services marquent ces combinaisons d’une façon spéciale sur leur clavier, et
que les services ne faisant pas usage de ces combinaisons placent sur la position secondaire des
types d’impression (ou du mécanisme équivalent) des lettres F, G et H un signe conventionnel, par exemple, un carré; l’apparition de ce signe sur le papier serait l’indice d’une frappe
anormale.
4.3
La combinaison N° 10 “signal audible” peut également provoquer une impression (voir le
tableau 2/S.l).
4.4
Les combinaisons Nos 29 et 30 d’”inversion lettres” et d’”inversion chiffres” respectivement
sont utilisées pour placer l’appareil terminal en position “lettres” ou “chiffres” de telle sorte que:
toute combinaison N° 1 à 26 reçue donne lieu à un signal imprimé de la série “lettres” (2e colonne
du tableau 1/S.l) si le dernier signal d’inversion reçu est une “inversion lettres”;
toute combinaison N° 1 à 26 reçue donne lieu à un signal imprimé de la série “chiffres” (3e colonne
du tableau 1/S.l) si le dernier signal d’inversion reçu est une “inversion chiffres”, sous réserve des
indications concernant les combinaisons Nos 4 et 10 données aux § 4.1 et 4.3.
4.5
Les combinaisons Nos 29 (inversion lettres), 30 (inversion chiffres) et 32 (espaces seulement,
nul ou absence de perforation de la bande) ne doivent pas affecter la progression des appareils terminaux,
sauf si leur réception est indiquée par l’impression d’un symbole (voir le § 5).
4.6
Emploi des majuscules et minuscules
4.6.1
Il est possible d’utiliser des téléimprimeurs en Alphabet télégraphique N° 2 ayant deux séries de
caractères lettres: majuscules et minuscules.
édition 2009
II-1/3
SUPPLéMENT ii-1
Tableau 1/S.1 — Alphabet télégraphique international N° 2 (ATI N° 2)
Numéro de
combinaison
Rangée des
lettres
Rangée des
chiffres
1
2
3
4
5
-
?
:
Voir § 4.1
3
Voir § 4.2
8
Signal acoustique
(
)
.
,
9
0
1
4
’
5
7
=
2
/
6
+
Z
Z
A
Z
Z
Z
A
A
A
Z
Z
A
A
A
A
A
Z
A
Z
A
Z
A
Z
Z
Z
Z
Z
A
Z
A
A
A
Z
A
Z
Z
Z
Z
A
A
A
Z
Z
Z
A
A
Z
Z
Z
A
A
A
A
A
Z
A
A
Z
A
Z
Z
A
Z
A
Z
Z
A
Z
Z
A
Z
A
Z
Z
A
Z
Z
A
A
Z
Z
Z
A
Z
Z
A
A
Z
Z
A
Z
Z
Z
A
A
Z
A
A
A
Z
A
Z
A
A
A
Z
A
A
A
A
Z
Z
A
A
A
Z
Z
A
Z
Z
Z
A
A
Z
A
Z
Z
Z
Z
Z
A
A
Z
Z
A
A
A
Z
Z
Z
A
A
A
A
Z
A
Z
A
Z
A
Z
Z
A
A
A
A
Z
Z
A
A
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
A
B
C
D
E
F
G H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
27
28
29
30
31
32
Retour du chariot Changement de ligne
Inversion lettres Inversion chiffres Voir § 4.5
Espace
Voir § 4.7
}
Codage
}
4.6.2
Il est possible d’utiliser des séquences des combinaisons d’inversion de l’Alphabet N° 2 pour
passer d’une série à l’autre.
4.6.3
Il est indispensable, si cette possibilité est utilisée, d’avoir la compatibilité avec les télé-
imprimeurs n’ayant qu’une série de caractères lettres.
4.7
Emploi de la combinaison N° 32
4.7.1
La combinaison N° 32 peut être utilisée dans certaines séquences de signalisation de
commutation; ces usages sont précisés dans les Recommandations U.11, U.20, U.22 et S.4.
4.7.2
La combinaison N° 32 ne doit pas être employée en phase de communication (après
l’établissement de la communication) sur le service télex international.
4.7.3
La combinaison N° 32 peut être utilisée en phase de communication (après l’établissement de
la communication) dans un service national intérieur, ou par accord bilatéral entre deux Administrations,
comme signal de commande pour certaines fonctions, par exemple, le passage sur un alphabet national,
différent de l’ATI N° 2.
4.7.4
La combinaison N° 32 ne doit pas être employée pour le passage d’une forme de caractères à
une autre en restant dans l’Alphabet télégraphique international N° 2, ni pour le passage d’un alphabet
télégraphique international à un autre.
édition 2009
II-1/4
5.
Représentation graphique des caractères de commande
Lorsqu’il est nécessaire d’avoir une indication graphique au sujet de la réception ou la
transmission de certains caractères de commande, il convient d’imprimer les symboles indiqués dans le
tableau 2/S.l.
Tableau 2/S.1 — Symboles d’impression pour les caractères de commande
Fonction
Numéro de
Rangée
Symbole
combinaison
Représentation
alphabétique
Qui êtes-vous? (WRU)
4
Chiffres
(voir la remarque 1)
EQ
Signal audible (sonnerie)
10
Chiffres
☊
BL
Retour du chariot
27
Lettres ou chiffres
←
CR
Changement de ligne
28
Lettres ou chiffres
☰
LF
Inversion lettres
29
Lettres ou chiffres
↓
SL ou LS
Inversion chiffres
30
Lettres ou chiffres
↑
SF ou FS
Espace
31
Lettres ou chiffres
∆
SP
Tous les espaces nuls
32
Lettres ou chiffres
≡
NU
Remarque 1: Ce symbole représente schématiquement une croix de Malte (✠) qui peut aussi être utilisée si
l’équipement le permet.
Remarque 2: Toute représentation alphabétique doit être considérée comme un symbole unique. Elle peut
occuper une position de la ligne imprimée ou affichée.
édition 2009
SUPPLéMENT II-2
ALPHABET INTERNATIONAL n° 5*
INTRODUCTION
Les travaux effectués en commun par le CCITT et l’Organisation internationale de normalisation
(ISO) ont abouti à l’établissement d’un alphabet à sept moments capable de répondre aux besoins des
usagers privés des circuits loués et des usagers des transmissions de données au moyen de communications
établies par commutation sur le réseau téléphonique général ou sur les réseaux télégraphiques.
Cet alphabet — l’Alphabet international N° 5 (AI N° 5) — n’est pas destiné à remplacer l’Alphabet
télégraphique international N° 2 (ATI N° 2). C’est un alphabet supplémentaire mis à la disposition des
usagers qui ne pourraient se satisfaire des possibilités plus réduites de l’Alphabet télégraphique international
N° 2. On considère, dans ce cas, que l’Alphabet international N° 5 constitue un langage de base commun
pour les transmissions de données et pour des systèmes complexes de transmission de messages.
L’Alphabet international N° 5 n’est pas exclusif de tout autre alphabet qui pourrait être mieux
adapté à des besoins spéciaux.
1.
Objet et domaine d’application
1.1
La présente Recommandation spécifie un jeu de 128 caractères (caractères de commande et
caractères graphiques tels que lettres, chiffres et symboles) ainsi que leur représentation codée. La plupart de
ces caractères sont obligatoires et ne peuvent être modifiés; mais une certaine marge de liberté a été prévue
pour tenir compte des besoins particuliers, nationaux et autres.
1.2
La présente Recommandation spécifie un jeu de caractères codés à 7 éléments avec certaines
positions optionnelles. Elle donne également des indications sur les choix à faire pour définir des
versions nationales spécifiques et des versions d’applications particulières. Elle spécifie en outre la version
internationale de référence dans laquelle ces choix ont été faits.
1.3
Ce jeu de caractères est principalement destiné à l’échange d’informations entre des systèmes
de traitement de données et appareils associés, ainsi que dans des systèmes de transmission de données.
Les besoins en caractères graphiques et en caractères de commande ont également été pris en considération
pour définir ce jeu de caractères.
1.4
Ce jeu de caractères est applicable à tous les alphabets composés de lettres latines.
1.5
Ce jeu de caractères comprend des caractères de commande d’extension de code pour les cas
où ses 128 caractères ne suffisent pas pour des applications particulières. Les procédures d’utilisation de ces
caractères de commande sont spécifiées dans la norme de l’ISO 2022.
1.6
Dans la présente Recommandation, la définition de certains caractères de commande suppose
que les données qui leur sont associées doivent être traitées en série et vers l’avant. S’ils sont inclus dans
des chaînes de données traitées autrement qu’en série et vers l’avant, ou s’ils sont inclus dans des données
structurées pour être traitées en enregistrements fixes, ils peuvent avoir des effets indésirables ou nécessiter
un traitement supplémentaire approprié pour être sûr qu’ils produisent bien le résultat désiré.
2.
Conformité et matérialisation
2.1
Conformité
Un jeu de caractères codés est en conformité avec la présente Recommandation s’il constitue
une version selon le § 6. Un matériel revendiquant la mise en œuvre de la présente Recommandation doit
être capable d’échanger des informations au moyen d’une version du jeu de caractères codés à 7 éléments,
cette version devant être identifiée dans cette revendication.
______
* Extrait du Livre bleu du CCITT, Tome VII, Fascicule VII.3. La Recommandation T.50 est reproduite après
reproduction.
édition 2009
II-2/2
2.2
Matérialisation
L’emploi de ce jeu de caractères exige des spécifications de matérialisation sur différents
supports. Ceux-ci peuvent comprendre, par exemple, des bandes perforées, des cartes perforées, des supports
magnétiques et des voies de transmission, permettant ainsi d’effectuer des échanges de données soit
indirectement au moyen d’enregistrement intermédiaire sur un support physique, soit par interconnexion
locale entre divers appareils (tels que dispositifs d’entrée/sortie et ordinateurs), soit par équipement de
transmission de données.
La matérialisation de ce jeu de caractères codés sur un support physique et pour la transmission,
tenant compte des nécessités de contrôle d’erreurs, fait l’objet d’autres publications de l’ISO.
3.
Définitions
Dans le cadre de la présente Recommandation, les définitions suivantes sont applicables.
3.1
combinaison binaire
Ensemble ordonné d’éléments binaires utilisé pour la représentation des caractères.
3.2
caractère
élément d’un ensemble employé pour organiser, commander ou représenter des données.
3.3
jeu de caractères codés; code
Ensemble de règles non ambiguës qui définissent un jeu de caractères et établissent une
correspondance biunivoque entre les caractères du jeu et leur combinaison binaire.
3.4
extension de code
donné.
Techniques de codage pour des caractères qui ne font pas partie du jeu de caractères d’un code
3.5
tableau de code
Tableau montrant les caractères alloués à chaque combinaison binaire d’un code.
3.6
caractère de commande
binaire.
Fonction de commande dont la représentation codée est formée d’une seule combinaison
3.7
fonction de commande
Opération qui concerne l’enregistrement, le traitement, la transmission ou l’interprétation des
données et dont la représentation codée est formée d’une ou de plusieurs combinaisons binaires.
3.8
caractère graphique
Caractère, autre qu’une fonction de commande, qui a une représentation visuelle normalement
obtenue par un procédé tel que l’écriture manuelle, l’impression ou l’affichage.
3.9
position
élément d’un tableau de code repéré par ses numéros de colonne et de ligne.
édition 2009
II-2/3
SUPPLéMENT ii-2
4.
Spécification du jeu de caractères codés
Les bits des combinaisons binaires du code à 7 éléments sont désignés par b7, b6, b5, b4, b3, b2 et
b1, b7 étant l’élément de poids le plus fort ou le plus significatif et b1 étant l’élément de poids le plus faible
ou le moins significatif.
On peut considérer les combinaisons binaires comme des nombres entiers compris entre 0 et
127, écrits en notation binaire, en attribuant les poids suivants à chacun de leurs bits:
Bits:
b 7
b 6
b5
b4
b3
b2
b1
Poids:
64
32
16
8
4
2
1
Dans la présente Recommandation, les combinaisons binaires sont identifiées par une notation
de forme x/y, dans laquelle x est un nombre compris entre 0 et 7 et y est un nombre compris entre 0 et 15.
La correspondance entre les notations de la forme x/y et les combinaisons binaires composées des bits b7 à
b1 est la suivante:
x est le nombre représenté par b7, b6 et b5, ces bits ayant respectivement les poids 4, 2 et 1;
y est le nombre représenté par b4, b3, b2 et b1, ces bits ayant respectivement les poids 8, 4, 2 et 1.
La notation de forme x/y est la même que celle utilisée pour identifier les positions des tables
de code, dans laquelle x est le numéro de colonne et y le numéro de ligne (voir le § 7).
Les 128 combinaisons du code à 7 bits représentent des caractères de commande et des caractères
graphiques. L’affectation des caractères aux combinaisons binaires est basée sur les principes suivants:
les combinaisons binaires 0/0 à 1/15 représentent 32 caractères de commande;
la combinaison binaire 2/0 représente le caractère ESPACE, qui est considéré a la fois comme un caractère
de commande et un caractère graphique;
les combinaisons binaires 2/1 à 7/14 représentent un maximum de 94 caractères graphiques étant donné
qu’une ou plusieurs de ces combinaisons binaires peuvent être déclarées inutilisées (voir le § 4.3);
la combinaison binaire 7/15 représente le caractère de commande OBLITÉRATION.
L’affectation de caractères individuels aux combinaisons binaires du code à 7 bits est spécifiée
ci-après aux §4.1, 4.2 et 4.3.
La présente Recommandation attribue au moins un nom à chaque caractère. Elle spécifie en
outre un sigle pour chaque caractère de commande ainsi que pour le caractère ESPACE, et un symbole
graphique pour chaque caractère graphique. Par convention, seuls les lettres majuscules et les tirets sont
utilisés pour écrire les noms des caractères, à l’exception de ceux des lettres minuscules. Pour les sigles,
seuls les lettres capitales et les chiffres sont utilisés. En principe ces sigles doivent être conservés et cette
convention doit être respectée lors de toute traduction de ce texte.
Les noms choisis pour désigner les caractères graphiques en donnent les significations courantes.
Cependant, la présente Recommandation ne définit ni ne restreint la signification des caractères graphiques.
En outre, elle ne spécifie ni le style ni le dessin à employer pour les caractères graphiques lorsqu’ils sont
représentés visuellement.
4.1
Caractères de commande
Les caractères de commande du jeu de caractères codés à 7 éléments sont classés dans les
catégories suivantes:
a) Caractères de commande de transmission
Les caractères de commande de transmission sont destinés à commander ou à faciliter la transmission d’information sur les réseaux de télécommunications. Les procédures d’utilisation des caractères de commande
de transmission sur les réseaux de télécommunications font l’objet d’autres publications de l’ISO.
b) Commandes de mise en page
Les commandes de mise en page sont principalement destinées à commander la disposition et la mise en
page de l’information sur les dispositifs de visualisation de caractères tels que les imprimantes et les visuels.
c) Caractères de commande d’extension de code
Les caractères de commande d’extension de code sont utilisés pour étendre le jeu de caractères du code.
Ils peuvent modifier la signification d’une ou de plusieurs des combinaisons binaires qui les suivent
édition 2009
II-2/4
dans le flot des données. Les procédures d’utilisation de ces caractères de commande d’extension de
code sont spécifiées dans la norme de l’ISO 2022.
d) Commandes d’appareils
Les caractères de commande d’appareils sont destinés à la commande d’appareils ou d’appareils auxiliaires situés sur la place ou distants et reliés à un système de traitement des données ou à un système
de transmission de données. Ces caractères de commande ne sont pas destinés à la commande des
systèmes de transmission de données; ceci doit se faire par l’emploi des caractères de commande de
transmission.
e) Séparateurs d’information
Les séparateurs d’information sont employés pour séparer et qualifier logiquement des données. Il en
existe quatre. Ils peuvent être utilisés dans un ordre hiérarchique ou d’une manière non hiérarchique;
dans ce dernier cas, leur signification spécifique dépend de l’application.
f) Autres caractères de commande
Ce sont les caractères de commande qui ne rentrent pas dans les catégories précédentes.
La composition de chaque catégorie et l’affectation dans chaque catégorie des caractères de
commande particuliers aux combinaisons binaires du code à 7 bits sont spécifiées aux § 4.1.1 à 4.1.6 ciaprès. Chacun de ces paragraphes contient une table ayant trois colonnes. La première colonne spécifie
le sigle de chaque caractère de commande, la seconde colonne spécifie le nom normalisé du caractère
de commande et la troisième colonne, intitulée “Représentation codée”, spécifie la combinaison binaire
représentant le caractère de commande considéré.
au § 8.
Des descriptions fonctionnelles particulières de chaque caractère de commande sont données
4.1.1
Caractères de commande de transmission
Les caractères de commande de transmission et leur représentation codée sont spécifiés dans le
tableau 1/T.50.
Tableau 1/T.50 — Caractères de commande de transmission — Représentation codée
Sigle
SOH
STX
ETX
EOT
ENQ
ACK
DLE
NAK
SYN
ETB
Nom
Début d’en-tête
Début de texte
Fin de texte
Fin de communication
Demande
Accusé de réception
échappement transmission
Accusé de réception négatif
Synchronisation
Fin de bloc de transmission
Représentation codée
0/1
0/2
0/3
0/4
0/5
0/6
1/0
1/5
1/6
1/7
4.1.2
Commandes de mise en page
Les commandes de mise en page et leur représentation codée sont spécifiées dans le
tableau 2/T.50.
Tableau 2/T.50 — Commandes de mise en page — Représentation codée
Sigle
BS
HT
LF
VT
FF
CR
édition 2009
Nom
Espace arrière
Tabulation horizontale
Interligne
Tabulation verticale
Page suivante
Retour du chariot
0/8
0/9
0/10
0/11
0/12
0/13
II-2/5
SUPPLéMENT ii-2
4.1.2.1
Concepts
suivants:
La définition des caractères de commande de mise en page est basée sur les concepts
a) Une page est composée d’un certain nombre de lignes, chacune étant composée d’un certain nombre
de positions de caractères.
b) Chaque position de caractère permet de représenter le caractère ESPACE ou un symbole graphique.
c) Le symbole graphique qui figure à une position de caractère représente un caractère graphique, une
fonction de commande, ou une combinaison de un ou plusieurs caractères graphiques et/ou fonctions de commande.
d) La position active est la position de caractère à laquelle l’action requise par le prochain caractère du
flux de données doit être effectuée. Si le prochain caractère est un caractère graphique, son image
apparaît à cette position; si c’est un caractère de commande, la fonction lui correspondant est exécutée relativement à cette position.
e) Les déplacements de la position active s’effectuent de la manière suivante:
i) La position active avance d’une position de caractère immédiatement après l’apparition de l’image
du caractère ESPACE ou d’un caractère graphique, et lors de l’exécution de la fonction correspondant à un caractère de commande qui doit être représenté par un symbole graphique.
ii) Certains caractères de commande (les commandes de mise en page) ont pour objet de provoquer
un déplacement de la position active et, lors de l’exécution de la fonction leur correspondant, la
position active se déplace pour aller à la position de caractère spécifiée.
f) La position active ne se déplace pas lors de l’exécution de la fonction correspondant à un caractère de
commande qui ne doit ni être représenté par un symbole graphique, ni provoquer un déplacement de
la position active.
g) Les conséquences d’une tentative de déplacement de la position active au-delà des limites d’une ligne
ou d’une page ne sont pas définies par la présente Recommandation.
4.1.2.2
Mouvements combinés horizontaux et verticaux de la position active
Les commandes de mise en page sont spécifiées pour des applications dans lesquelles les mouvements horizontaux et verticaux de la position active s’effectuent séparément. Si un seul caractère de
commande est requis pour effectuer l’action d’un RETOUR CHARIOT combinée avec celle d’un mouvement
vertical, la commande de mise en page de ce mouvement vertical sera employée pour effectuer le mouvement combiné. Par exemple, si l’on a besoin de la fonction “retour à la ligne” (équivalente à la combinaison
de RETOUR CHARIOT et INTERLIGNE) comme caractère de commande unique, la combinaison binaire
0/10 sera employée pour la représenter. Cette substitution exige un accord entre l’émetteur des données et
leur destinataire, et les commandes de mise en page concernées INTERLIGNE, TABULATION VERTICALE
et/ou PAGE SUIVANTE seront identifiées (voir le § 6).
Afin d’éviter la nécessité d’un tel accord préalable, de faciliter l’échange de données et aussi
d’éviter les conflits avec les spécifications d’autres publications de l’ISO, l’usage de commandes de mise en
page pour effectuer des mouvements combinés horizontaux et verticaux par la seule commande de mise
en page du mouvement vertical est déconseillé. Il est fortement recommandé d’utiliser deux commandes
de mise en page, par exemple, RETOUR CHARIOT (CR) et INTERLIGNE (LF) pour obtenir l’effet de “retour
à la ligne”.
4.1.3
Caractères de commande d’extension de code
Les caractères de commande d’extension de code et leur représentation codée sont spécifiés
dans le tableau 3/T.50.
Tableau 3/T.50 — Caractères de commande d’extension de code — Représentation codée
Sigle
SO
SI
ESC
Nom
Hors code
En code
échappement
0/14
0/15
1/11
édition 2009
II-2/6
4.1.4
Commandes d’appareils
Les caractères de commande d’appareils et leur représentation codée sont spécifiés dans le
tableau 4/T.50.
Tableau 4/T.50 — Commandes d’appareils — Représentation codée
Sigle
DC1
DC2
DC3
DC4
4.1.5
Nom
Commande d’appareil un Commande d’appareil deux Commande d’appareil trois Commande d’appareil quatre 1/1
1/2
1/3
1/4
Séparateurs d’information
Les séparateurs d’information et leur représentation codée sont spécifiés dans le tableau 5/T.50.
Tableau 5/T.50 — Séparateurs d’information — Représentation codée
Sigle
Nom
IS4 (FS)
Séparateur d’information quatre (séparateur de fichier)
1/12
IS3 (GS)
Séparateur d’information trois (séparateur de groupe) 1/13
IS2 (RS)
Séparateur d’information deux (séparateur d’article) 1/14
IS1 (US)
Séparateur d’information un (séparateur de sous-article)
1/15
Chaque séparateur d’information a deux noms. Les noms SéPARATEUR D’INFORMATION
QUATRE, SÉPARATEUR D’INFORMATION TROIS, SÉPARATEUR D’INFORMATION DEUX et SÉPARATEUR
D’INFORMATION UN sont les noms généraux. Les noms SÉPARATEUR DE FICHIER, SÉPARATEUR DE
GROUPE, SÉPARATEUR D’ARTICLE et SÉPARATEUR DE SOUS-ARTICLE sont destinés principalement aux
applications dans lesquelles les séparateurs d’information sont utilisés dans un ordre hiérarchique. L’ordre
ascendant est alors US, RS, GS, FS. Dans ce cas, les données normalement délimitées par un séparateur
particulier ne peuvent être divisées par un séparateur d’un ordre hiérarchique supérieur mais seront
considérées comme délimitées par tout séparateur d’un ordre hiérarchique supérieur.
4.1.6
Autres caractères de commande
Les caractères de commande qui ne rentrent pas dans les catégories mentionnées aux
§ 4.1.1, 4.1.2, 4.1.3, 4.1.4 et 4.1.5 sont spécifiés avec leur représentation codée dans le tableau 6/T.50.
Tableau 6/T.50 — Autres caractères de commande — Représentation codée
Sigle
NUL
BEL
CAN
EM
SUB
DEL
4.2
Nom
Nul
Sonnerie
Annulation
Fin de support
Substitution
Oblitération
0/0
0/7
1/8
1/9
1/10
7/15
Caractère ESPACE
Le sigle du caractère ESPACE est SP et sa représentation codée est 2/0. Ce caractère est considéré
à la fois comme un caractère graphique et comme un caractère de commande. En tant que caractère
graphique, il a une représentation visuelle qui consiste en l’absence de tout symbole graphique. En tant que
caractère de commande, il agit comme une commande de mise en page qui fait avancer la position active
d’une position de caractère.
édition 2009
II-2/7
SUPPLéMENT ii-2
4.3
Caractères graphiques
Les 94 combinaisons binaires de 2/1 à 7/14 qui sont destinées à la représentation de caractères
graphiques sont utilisées comme spécifié aux § 4.3.1, 4.3.2 et 4.3.3 ci-après. Chacun des § 4.3.1 et 4.3.2
contient une table ayant trois colonnes. La première colonne est intitulée “Symbole” et spécifie le symbole
graphique de chaque caractère graphique, la seconde colonne spécifie le nom normalisé du caractère
graphique et la troisième colonne, intitulée “Représentation codée”, spécifie la combinaison binaire
représentant le caractère graphique considéré.
Tous les caractères graphiques d’une version du jeu de caractères codés à 7 éléments sont des
caractères espaçants, c’est-à-dire qu’ils font tous avancer la position active.
4.3.1
Affectations uniques
Un seul caractère graphique est affecté à chacune des 82 combinaisons binaires 2/1, 2/2, 2/5
à 3/15, 4/1 à 5/10, 5/15 et 6/1 à 7/10. Ces caractères sont spécifiés avec leur représentation codée dans le
tableau 7/T.50.
Tableau 7/T.50 — Affectations uniques
Symbole
Nom
!
“
%
&
’
(
)
*
+
,
–
.
/
0
1
2
3
4
5
6
7
8
9
:
;
<
=
>
?
A
B
C
D
E
F
G
H
I
J
K
L
Point d’exclamation
Guillemet
Symbole pour cent
Perluète
Apostrophe
Parenthèse gauche
Parenthèse droite
Astérisque
Signe plus
Virgule
Tiret, signe moins
Point
Barre oblique
Chiffre zéro
Chiffre un
Chiffre deux
Chiffre trois
Chiffre quatre
Chiffre cinq
Chiffre six
Chiffre sept
Chiffre huit
Chiffre neuf
Deux-points
Point-virgule
Symbole inférieur à
Symbole égal
Symbole supérieur à
Point d’interrogation
Lettre majuscule A
Lettre majuscule B
Lettre majuscule C
Lettre majuscule D
Lettre majuscule E
Lettre majuscule F
Lettre majuscule G
Lettre majuscule H
Lettre majuscule I
Lettre majuscule J
Lettre majuscule K
Lettre majuscule L
Représentation
Symbole
Nom
codée
2/1
2/2
2/5
2/6
2/7
2/8
2/9
2/10
2/11
2/12
2/13
2/14
2/15
3/0
3/1
3/2
3/3
3/4
3/5
3/6
3/7
3/8
3/9
3/10
3/11
3/12
3/13
3/14
3/15
4/1
4/2
4/3
4/4
4/5
4/6
4/7
4/8
4/9
4/10
4/11
4/12
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
—
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
p
q
r
s
t
u
v
w
x
y
z
Lettre majuscule M
Lettre majuscule N
Lettre majuscule O
Lettre majuscule P
Lettre majuscule Q
Lettre majuscule R
Lettre majuscule S
Lettre majuscule T
Lettre majuscule U
Lettre majuscule V
Lettre majuscule W
Lettre majuscule X
Lettre majuscule Y
Lettre majuscule Z
Trait bas, souligné
Lettre minuscule a
Lettre minuscule b
Lettre minuscule c
Lettre minuscule d
Lettre minuscule e
Lettre minuscule f
Lettre minuscule g
Lettre minuscule h
Lettre minuscule i
Lettre minuscule j
Lettre minuscule k
Lettre minuscule l
Lettre minuscule m
Lettre minuscule n
Lettre minuscule o
Lettre minuscule p
Lettre minuscule q
Lettre minuscule r
Lettre minuscule s
Lettre minuscule t
Lettre minuscule u
Lettre minuscule v
Lettre minuscule w
Lettre minuscule x
Lettre minuscule y
Lettre minuscule z
Représentation
codée
4/13
4/14
4/15
5/0
5/1
5/2
5/3
5/4
5/5
5/6
5/7
5/8
5/9
5/10
5/15
6/1
6/2
6/3
6/4
6/5
6/6
6/7
6/8
6/9
6/10
6/11
6/12
6/13
6/14
6/15
7/0
7/1
7/2
7/3
7/4
7/5
7/6
7/7
7/8
7/9
7/10
édition 2009
II-2/8
4.3.2
Affectations doubles
Chacune des combinaisons binaires 2/3 et 2/4 peut être affectée, au choix, à deux caractères
graphiques. Ces caractères sont spécifiés avec leur représentation codée dans le tableau 8/T.50.
Il faut affecter ou bien le SYMBOLE LIVRE ou bien le SYMBOLE NUMÉRO à la combinaison
binaire 2/3 et il faut affecter ou bien le SYMBOLE DOLLAR ou bien le SYMBOLE MONÉTAIRE à la combinaison binaire 2/4 (voir le § 6).
Tableau 8/T.50 — Affectations doubles
Symbole
Nom
£
Symbole livre 2/3
#
Symbole numéro 2/3
$
Symbole dollar 2/4
Symbole monétaire
2/4
Sauf accord contraire entre l’émetteur des données et leur destinataire, les symboles graphiques
£, $ et € ne désignent pas la monnaie d’un pays déterminé.
4.3.3
Affectations réservées pour des besoins nationaux ou d’applications particulières
Aucun caractère graphique spécifique n’est affecté aux 10 combinaisons binaires 4/0, 5/11 à
5/14, 6/0 et 7/11 à 7/14. Ces combinaisons binaires sont disponibles pour les besoins nationaux et ceux
d’applications particulières. Un seul caractère graphique doit être affecté à chacune de ces combinaisons
binaires, ou bien la combinaison binaire doit être déclarée inutile (voir le § 6).
5.
Caractères graphiques composites
Dans toute version d’un jeu de caractères codés à 7 éléments spécifié conformément à la
présente Recommandation, tous les caractères graphiques sont des caractères espaçants qui provoquent le
déplacement en avant de la position active. Toutefois, en utilisant ESPACE ARRIÈRE ou RETOUR CHARIOT,
il est possible de présenter l’image de deux ou même de plus de deux caractères graphiques à la même
position de caractère.
Par exemple, BARRE OBLIQUE et SYMBOLE ÉGAL peuvent être combinés afin de présenter
l’image du symbole “différent de”. Le caractère TRAIT BAS, qui peut être utilisé seul, peut aussi être combiné
avec un ou plusieurs autres caractères afin de présenter le rendu graphique “souligné”.
Les signes diacritiques peuvent être affectés aux combinaisons binaires spécifiées au § 4.3.3
et être ainsi disponibles pour la composition de lettres accentuées. Pour de telles combinaisons, il est
recommandé d’utiliser une séquence de 3 caractères, dont le premier ou le dernier est la lettre à accentuer et
le second est ESPACE ARRIÈRE. Par ailleurs GUILLEMET, APOSTROPHE ou VIRGULE peuvent être associés à
une lettre au moyen d’ESPACE ARRIÈRE afin de présenter l’image d’une lettre accentuée avec respectivement
un tréma, un accent aigu ou une cédille.
6.
Versions du jeu de caractères codés
6.1
Considérations générales
L’usage du jeu de caractères codés à 7 éléments pour l’échange d’information nécessite d’arrêter
les choix mentionnés au § 4:
— il faut préciser lequel des deux caractères graphiques spécifiés au § 4.3.2 est affecté à la combinaison
binaire 2/3, ainsi qu’à la position binaire 2/4;
— un caractère graphique unique doit être affecté à chacune des combinaisons binaires 4/0, 5/11 à 5/14,
6/0 et 7/11 à 7/14 ou bien cette combinaison binaire doit être déclarée inutilisée;
— il faut préciser pour quelle(s) commande(s) de mise en page, s’il y en a, l’option mentionnée au
§ 4.1.2.2 est valable et peut être utilisée.
édition 2009
II-2/9
SUPPLéMENT ii-2
Un caractère graphique affecté à une combinaison binaire mentionnée aux § 4.3.1 et 4.3.2 ne
peut plus être affecté à une autre position binaire. Par exemple, le SYMBOLE LIVRE, s’il n’est pas affecté à la
combinaison binaire 2/3, ne peut plus être affecté à une autre combinaison binaire.
On appelle “version de l’ISO 646/CCITT T.50” (voir l’appendice I) un jeu de caractères complété
de cette manière.
6.2
Versions nationales
6.2.1
Les organismes nationaux de normalisation ont la responsabilité de la définition des versions
nationales. Ces organismes doivent arrêter les choix qui sont ouverts en fonction des besoins (voir
l’appendice I).
6.2.2
Si cela est nécessaire, un pays peut définir plusieurs versions nationales. Ces différentes
versions doivent être identifiées séparément. En particulier, si pour une combinaison binaire particulière,
par exemple 5/12, une option entre deux caractères graphiques différents doit être offerte, deux versions
différentes doivent être identifiées, même si elles ne diffèrent que par ce seul caractère.
6.2.3
Si un pays n’a pas besoin de caractères spécifiques, il est vivement recommandé que les
caractères de la version internationale de référence (VIR) (voir le § 6.4) soient choisis et affectés aux mêmes
combinaisons binaires.
Lorsque des caractères différents de ceux de la version internationale de référence sont requis,
ces caractères doivent avoir une forme et un nom distincts qui n’introduisent pas de risque de confusion avec
la forme et le nom de l’un quelconque des caractères graphiques de la version internationale de référence.
6.3
Versions d’application particulière
Au niveau d’entreprises industrielles nationales ou internationales, d’organisations ou de
groupes professionnels, il est possible d’utiliser des versions destinées à des applications particulières. Ces
versions nécessitent un accord précis entre les parties intéressées pour arrêter les choix qui sont ouverts en
fonction des besoins.
6.4
Version internationale de référence (VIR)
Cette version est destinée à être utilisée lorsqu’il n’est pas nécessaire d’utiliser une version nationale ou une version d’application particulière. En cas d’échange d’informations, la version internationale de
référence est supposée être utilisée, à moins qu’un accord particulier n’existe entre l’émetteur des données et
leur destinataire. Les caractères graphiques qui lui sont affectés sont spécifiés dans le tableau 9/T.50.
Il est à noter qu’aucune substitution n’est permise lors de l’emploi de la version internationale de
référence et que l’option du § 4.1.2.2 ne peut être utilisée pour aucune des commandes de mise en page.
Tableau 9/T.50 — Affectations des caractères graphiques de la version internationale de référence
Symbole
Nom
#
Symbole numéro
2/3
Symbole monétaire
2/4
@
A commercial
4/0
[
Crochet gauche
5/11
\
Barre oblique inversée
5/12
]
Crochet droit
5/13
^
Accent circonflexe
5/14
`
Accent grave
6/0
{
Accolade gauche
7/11
|
Barre verticale
7/12
}
Accolade droite
7/13
-
Tilde, surligné
7/14
édition 2009
II-2/10
En accord avec le § 5, il est permis d’employer des caractères graphiques composites et leur
nombre n’est pas limité. à cause de cette licence, leur traitement et leur présentation peuvent causer des
difficultés à l’extrémité réceptrice. Aussi un accord entre l’émetteur des données et leur destinataire est-il
recommandé si des caractères composites sont utilisés.
7.
Tableaux de codes
Un tableau de code à 7 éléments est constitué de 128 positions disposées en 8 colonnes et
16 lignes. Les colonnes sont numérotées de 0 à 7, et les lignes sont numérotées de 0 à 15.
Les positions d’un tableau de code sont désignées par des notations de la forme x/y, dans
laquelle, x est le numéro de la colonne et y est le numéro de la ligne.
Les 128 positions d’un tableau de code sont en correspondance avec les combinaisons binaires
du code à 7 éléments. La notation qui désigne une position d’un tableau de code, sous la forme x/y, est la
même que celle de la combinaison binaire correspondante (voir le § 4).
Chaque position d’un tableau de code contient un symbole et/ou une référence à un
paragraphe de la présente Recommandation. Pour les positions d’un tableau de code qui correspondent à
une combinaison binaire représentant un caractère de commande ou le caractère ESPACE, le symbole est le
sigle de caractère de commande; sinon c’est le symbole graphique représentant le caractère affecté à cette
③
position, s’il y en a un. Une référence aux § 4.1.2.2, 4.3.2 ou 4.3.3 est notée respectivement ,
① ② ou .
Le tableau 10/T.50 est le tableau de base du code à 7 éléments. Il montre le jeu de caractères
codés à 7 éléments spécifié au § 4 et indique les options relatives aux commandes de mise en page (voir le
§ 4.1.2.2), aux affectations doubles (voir le § 4.3.2) et aux besoins nationaux ou d’applications particulières
(voir le § 4.3.3).
Tableau 10/T.50 — Tableau de base du code à 7 éléments
①
②
③
Voir le § 4.1.2.2.
Voir le § 4.3.2.
Voir les § 4.3.3 et 6.2.3.
édition 2009
II-2/11
SUPPLéMENT ii-2
Le tableau 11/T.50 est le tableau de code pour la version internationale de référence du jeu de
caractères codés à 7 éléments. Il montre le résultat obtenu en effectuant les choix relatifs aux trois options
de la manière indiquée au § 6.4.
Tableau 11/T.50 — Version internationale de référence
´̀̀
8.
Description des caractères de commande
sigles.
Les caractères de commande sont ordonnés ci-dessous dans l’ordre alphabétique de leurs
8.1
ACK Accusé de réception positif
l’émetteur.
Caractère de commande de transmission transmis par un récepteur comme réponse affirmative à
8.2
BEL Sonnerie
Caractère utilisé lorsqu’il est nécessaire d’attirer l’attention; il peut commander des dispositifs
d’appel ou d’avertissement.
8.3
BS Espace arrière
Caractère de commande de mise en page qui ramène la position active en arrière d’une position
de caractère.
édition 2009
II-2/12
8.4
CAN Annulation
Caractère ou premier caractère d’une suite de caractères indiquant que les données le précédant
sont erronées et que ces données doivent être ignorées. Le sens spécifique de ce caractère doit être défini
pour chaque application et faire l’objet d’un accord entre l’émetteur des données et leur destinataire.
8.5
CR Retour de chariot
Commande de mise en page qui déplace la position active à la première position de caractère
de la même ligne.
8.6
DC1 Commande d’appareil un
Caractère de commande d’appareil principalement destiné à enclencher ou à mettre en marche
un appareil auxiliaire. Si l’on n’en a pas besoin pour cette fonction, il peut être utilisé pour rétablir, dans
un appareil, le mode principal de fonctionnement (voir aussi DC2 et DC3) ou pour toute autre fonction de
commande d’appareil auxiliaire non prévue par les autres DC.
8.7
DC2 Commande d’appareil deux
Caractère de commande d’appareil principalement destiné à enclencher ou à mettre en marche
un appareil auxiliaire. Si l’on n’en a pas besoin pour cette fonction, il peut être utilisé afin que l’appareil
fonctionne d’après un mode spécial (dans ce cas DC1 sera utilisé pour ramener l’appareil au mode principal
de fonctionnement), ou pour toute autre fonction de commande d’appareil auxiliaire non prévue par les
autres DC.
8.8
DC3 Commande d’appareil trois
Caractère de commande d’appareil principalement destiné à déclencher ou à arrêter un appareil
auxiliaire. Cette fonction peut être un arrêt de niveau secondaire, par exemple, attente, pause, mise en
réserve ou halte (dans ce cas DC1 est utilisé pour rétablir l’opération normale). Si l’on n’en a pas besoin pour
cette fonction, il peut être utilisé pour toute autre fonction de commande d’appareil auxiliaire non prévue
par les autres DC.
8.9
DC4 Commande d’appareil quatre
Caractère de commande d’appareil principalement destiné à déclencher, arrêter ou interrompre
un appareil auxiliaire. Si l’on n’en a pas besoin pour cette fonction, il peut être utilisé pour toute autre
fonction de commande d’appareil auxiliaire non prévue par les autres DC.
8.10
DEL Oblitération
Caractère employé principalement pour effacer, ou oblitérer, les caractères erronés ou indésirables
sur une bande perforée. Les caractères DEL peuvent également servir comme caractère de remplissage de
temps ou de support d’information. Ils peuvent être insérés dans une suite de caractères ou en être retirés
sans que le contenu d’information de cette suite en soit affecté; mais ceci peut affecter la disposition des
informations ou la commande des équipements.
8.11
DLE échappement transmission
Caractère de commande de transmission, qui change la signification d’un nombre limité de
combinaisons binaires contiguës qui le suivent. Ce caractère est utilisé exclusivement pour fournir des
commandes supplémentaires de transmission. Seuls des commandes de transmission et des caractères
graphiques peuvent être utilisés dans les séquences DLE.
8.12
EM Fin de support
Caractère de commande qui peut être utilisé pour identifier la fin matérielle du support ou la
fin de la partie utilisée du support ou la fin de la partie désirée des informations enregistrées sur un support.
La position de ce caractère ne correspond pas nécessairement à la fin matérielle du support.
8.13
ENQ Demande
Caractère de commande de transmission employé comme demande de réponse d’une station
distante — la réponse peut inclure l’identification de la station ou l’état de la station, ou les deux. Lorsqu’un contrôle d’identité “Qui est là?” est exigé sur un réseau général de transmission avec commutation, la
édition 2009
SUPPLéMENT ii-2
II-2/13
première utilisation du caractère ENQ après l’établissement de la liaison aura le sens “Qui est là?” (identification de la station). Une nouvelle utilisation du caractère ENQ peut ou non inclure la fonction “Qui est
là?”, selon accord préalable.
8.14
EOT Fin de transmission
Caractère de commande de transmission utilisé pour indiquer la fin de la transmission d’un ou
plusieurs textes.
8.15
ESC échappement
Caractère de commande employé pour fournir des caractères supplémentaires. Il modifie la
signification d’un nombre limité de combinaisons binaires contiguës qui le suivent. L’emploi de ce caractère
est spécifié dans la norme de l’ISO 2022.
8.16
ETB Fin de transmission du bloc
Caractère de commande de transmission utilisé pour indiquer la fin d’un bloc de données
lorsque ces données sont divisées en blocs en vue de leur transmission.
8.17
ETX Fin de texte
Caractère de commande de transmission utilisé pour terminer un texte.
8.18
FF Page suivante
Caractère de mise en page qui déplace la position active jusqu’à la position de caractère
correspondante sur une ligne prédéterminée de l’imprimé ou de la page suivante.
8.19
HT Tabulation horizontale
Commande de mise en page qui fait avancer la position active jusqu’à la position de caractère
prédéterminée suivante.
8.20
IS1 (US) Séparateur d’information un (séparateur de sous-articles)
Caractère de commande employé pour séparer et qualifier des données dans un sens logique;
sa signification spécifique doit être déterminée pour chaque application. Si ce caractère est employé dans
l’ordre hiérarchique indiqué dans la définition générale de IS, il délimite un ensemble de données appelé
sous-article.
8.21
IS2 (RS) Séparateur d’information deux (séparateur d’article)
article.
8.22
IS3 (GS) Séparateur d’information trois (séparateur de groupe)
groupe.
8.23
IS4 (FS) Séparateur d’information quatre (séparateur de fichier)
fichier.
8.24
LF Interligne
Commande de mise en page qui déplace la position active jusqu’à la position de caractère
correspondante sur la ligne suivante.
édition 2009
II-2/14
8.25
NAK Accusé de réception négatif
Caractère de commande de transmission transmis par un récepteur comme réponse négative à
l’émetteur.
8.26
NUL Nul
Caractère de commande destiné au remplissage de temps ou de support d’information. Les
caractères NUL peuvent être insérés dans une suite de caractères ou en être retirés sans que le contenu
d’information de cette suite en soit affecté; mais ceci peut affecter la disposition des informations et/ou la
commande des équipements.
8.27
SI En code
Caractère de commande qui est employé en combinaison avec les caractères SO et ESC pour
étendre le jeu de caractères graphiques du code. Il peut rétablir la signification normalisée des combinaisons
binaires qui le suivent. L’effet de ce caractère dans la mise en œuvre de techniques d’extension de code est
décrit dans la norme de l’ISO 2022.
8.28
SO Hors code
Caractère de commande qui est employé en combinaison avec les caractères SI et ESC pour
étendre le jeu de caractères graphiques du code. Il peut modifier la signification des combinaisons binaires
2/1 à 7/14 qui le suivent jusqu’au caractère SI suivant. L’effet de ce caractère dans la mise en œuvre de
techniques d’extension de code est décrit dans la norme de l’ISO 2022.
8.29
SOH Début d’en-tête
Caractère de commande de transmission employé comme premier caractère d’un en-tête de
message d’information.
8.30
STX Début de texte
en-tête.
Caractère de commande de transmission précédant un texte et employé pour terminer un
8.31
SUB Caractère de substitution
Caractère de commande employé pour remplacer un caractère reconnu non valide ou erroné.
Le caractère SUB est introduit par le système de traitement.
8.32
SYN Synchronisation
Caractère de commande de transmission utilisé par un système de transmission synchrone en
l’absence de tout autre caractère (situation inactive) pour produire un signal à partir duquel le synchronisme
peut être obtenu entre équipements terminaux de données.
8.33
VT Tabulation verticale
Caractère de mise en page qui déplace la position active jusqu’à la position de caractère
correspondante sur la ligne prédéterminée suivante.
édition 2009
SUPPLéMENT ii-2
II-2/15
APPENDICE I (à la Recommandation T.50)
Directives pour normes basées sur la Recommandation T.50 (ISO 646)
I.1
Lorsqu’une norme nationale ou une norme d’application basée sur la Recommandation T.50/
ISO 646 est rédigée, il est recommandé de tenir compte des considérations suivantes.
I.2
Structure de la norme
Il est recommandé d’adopter la même structure de texte et le même style de rédaction que
ceux de la Recommandation T.50/ISO 646. Toutes les dispositions, restrictions et spécifications de la norme
doivent de préférence être exprimées par un texte précis plutôt que résumées par des tables chargées de
notes.
I.2.1
Caractères de commande
La norme doit contenir les définitions complètes des caractères de commande. Même lorsque
ces définitions sont identiques à celles du § 8, elles doivent être reproduites explicitement, une mention
de renvoi à la Recommandation T.50/ISO 646 ne suffisant pas. Les normes d’application doivent définir les
significations spécifiques des séparateurs d’information et des caractères de commande d’appareil.
I.2.2
Caractères graphiques (voir le § 6.2.3)
Lorsque des caractères graphiques spéciaux ne sont pas requis, les caractères graphiques de la
version internationale de référence sont affectés aux mêmes positions et avec le même nom que dans la
Recommandation T.50/ISO 646.
I.2.3
Caractères graphiques composites (voir le § 5)
La Recommandation T.50/ISO 646 permet la construction de caractères graphiques composites
en utilisant les caractères de commande de mise en page ESPACE ARRIÈRE et RETOUR DU CHARIOT de
manière à présenter l’image d’au moins deux caractères à la même position de caractère.
Le nombre total de caractères graphiques qui peut ainsi être obtenu à partir d’une version du jeu de
caractères avec ou sans caractères graphiques composites est appelé le répertoire. La Recommandation T.50/
ISO 646 ne définit pas un répertoire particulier. Toutefois, l’interprétation et/ou la présentation de caractères
composites peuvent causer des difficultés et peuvent requérir un accord préalable entre l’émetteur et le
récepteur des données. Afin d’éviter la nécessité de tels accords et de faciliter l’échange de données, les
normes nationales ou les normes d’application peuvent spécifier un répertoire de caractères graphiques
normalisé et ainsi ne reconnaître qu’un nombre déterminé de caractères graphiques composites. Une telle
limitation est considérée comme parfaitement compatible avec la Recommandation T.50/ISO 646.
I.2.4
Versions
Une norme peut spécifier une ou plusieurs versions. Il y a lieu de remarquer qu’une version
n’est pas une norme, mais seulement une partie de norme. Celle-ci doit comprendre une ou plusieurs
versions parfaitement définies et toutes les clauses mentionnées ci-dessus. La définition d’une version
requiert l’exercice précis de toutes les options mentionnées au § 6.1.
édition 2009
SUPPLéMENT II-3
TABLE DE CONVERSION ENTRE LES ALPHABETS INTERNATIONAUX
N° 2 ET N° 5 ET CARACTÈRES DE COMMANDE DE L’ALPHABET N° 5 NON CONTENUS DANS LA PREMIÈRE PARTIE DU TABLEAU ET UTILISÉS
POUR LES TRANSMISSIONS MÉTÉOROLOGIQUES
Partie I — Table de conversion de l’Alphabet international N° 5 à
l’Alphabet international N° 2 et vice versa
Symboles ou commandes
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
Retour du chariot
Changement de ligne
Lettres
Chiffres
Espace
—
?
:
ENQ - WRU
3
8
Signal acoustique/sonnerie
(
)
.
Alphabet N° 2
Rangée des lettres
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Alphabet N° 5
Rangée des chiffres
27
28
29
30
31
1
2
3
4
5
9
10
11
12
13
Colonne
Ligne
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
5
5
5
5
5
5
5
5
5
5
5
0
0
2
2
3
3
0
3
3
0
2
2
2
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
0
1
2
3
4
5
6
7
8
9
10
13
10
0
13
15
10
5
3
8
7
8
9
14
(à suivre)
édition 2009
II-3/2
Table de conversion (suite)
Symboles ou commandes
Alphabet N° 2
Rangée des lettres
,
9
0
1
4
’
5
7
=
2
/
6
+
Alphabet N° 5
Rangée des chiffres
Colonne
Ligne
14
15
16
17
18
19
20
21
22
23
24
25
26
2
3
3
3
3
2
3
3
3
3
2
3
2
12
9
0
1
4
7
5
7
13
2
15
6
11
Note: Le signal N° 32 de l’Alphabet N° 2 a été omis du fait qu’il n’est pas utilisé.
Partie II — Caractères de commande de l’Alphabet N° 5 non contenus dans
la première partie du tableau et utilisés pour les transmissions météorologiques
Symboles
édition 2009
NUL
SOH
STX
ETX
EOT
ACK
DLE
DC1
DC2
NAK
SYN
ETB
ESC
FS
GS
RS
DEL
Code de l’Alphabet N° 5
Colonne
Ligne
0
0
0
0
0
0
1
1
1
1
1
1
1
1
1
1
7
0
1
2
3
4
6
0
1
2
5
6
7
11
12
13
14
15
SUPPLéMENT II-4
FORME DE PRéSENTATION DES MESSAGES MéTéOROLOGIQUES
1.
EXEMPLE d’observations en surface (SYNOP)
a) Emploi de l’Alphabet télégraphique international N° 2
Ligne préliminaire←
←←≡↓ZCZC→↑345→→→→→
En-tête abrégé
←←≡↓SMYG↑10→↓LYBM→↑280000
Texte
←←≡↓AAXX→↑28001
←←≡↑13131→.....→.....→.....→.....→ etc.*.....=
←←≡↑13272→.....→.....→.....→.....→ etc.*.....=
←←≡↑13333→.....→.....→.....→.....→ etc.*.....=
←←≡↑13462→.....→.....→.....→.....→ etc.*.....=
←←≡↑13586→↓NIL↑=
Signaux de fin de message ↓←←≡≡≡≡≡≡≡≡NNNN↓↓↓↓↓↓↓↓↓↓↓↓
Légende: ← Retour du chariot (signal N° 27)
↓ Impulsion lettres (signal N° 29)
≡ Changement de ligne (signal N° 28)
↑ Impulsion chiffres (signal N° 30)
→ Espace (signal N° 31)
= Signal N° 22 (rangée des chiffres)
b) Emploi de l’Alphabet international N° 5
S
Ligne préliminaire O
C
R
C
R
En-tête abrégé
C
R
C
R
L
F
SMYG 10 P LYBM P 280000
Texte
C
R
C
R
L
F
AAXX
S
28001
P
C
R
C
R
L
F
13131
S
P
.....
S
S
P ..... P
..... P ..... P
C
R
C
R
L
F
13272
S
P
.....
S
S
P ..... P
..... P ..... P
C
R
C
R
L
F
13333
S
P
.....
S
S
P ..... P
..... P ..... P
C
R
C
R
L
F
13462
S
P
.....
S
S
P ..... P
..... P ..... P
C
R
C
R
L
F
13586
S
P
NIL=
Signaux de fin
de message
C
R
C
R
L
F
E
T
X
H
L
F 345
S
S
S
S
S
S
S
S
S
S
etc.*.....=
etc.*.....=
etc.*.....=
etc.*.....=
* Il faudrait utiliser au maximum la capacité d’une ligne de téléimprimeur (69 caractères par ligne). Voir aussi
le paragraphe 2.3.3.2.6 de la partie II.
édition 2009
II-4/2
Légende:
S
O
H
Début d’en-tête (signal 0/1)
C
R
Retour de chariot (signal 0/13)
L
F
Interligne (signal 0/10)
S
P
Espace (signal 2/0)
E
T
X
Fin de texte (signal 0/3)
=
Séparatif (signal 3/13)
2.
Exemple d’observations en surface (SHIP)
Ligne préliminaire←
←←≡↓ZCZC→↑234→→→→→
En-tête abrégé
←←≡↓SMVD↑01→↓KWBC→↑280000
Texte
←←≡↓BBXX**
←←≡↓WLGT**→↓28004→99510→70428→41595
←←≡↑.....→.....→.....→.....→.....etc.*
←←≡↑.....→.....=
Ligne préliminaire← S
C
R
C
R
L 234
F
En-tête abrégé
C
R
C
R
L
F
SMVD 01 S KWBC S 280000
Texte
C
R
C
R
L
F
BBXX**
C
R
C
R
L
F
WLGT** P 28004 P 99510 P 70428 P 41595 P etc.*.....=
C
R
C
R
L
F
.....
C
R
C
R
L
F
E
T
X
O
H
Signaux de fin
de message
P
P
S
S
S
P .....
S
P .....=
S
S
S
* Il faudrait utiliser au maximum la capacité d’une ligne de téléimprimeur (69 caractères par ligne).
Voir aussi le paragraphe 2.3.3.2.6 de la partie II.
** Dans un bulletin composé de messages d’observation SHIP provenant de stations en mer, le groupe MiMiMjMj
constitue la première ligne du texte, et l’indicatif d’appel du navire ou l’identification de la bouée et le groupe
YYGGiw figurent dans chaque message.
édition 2009
II-4/3
SUPPLéMENT ii-4
3.
Exemple d’observations en altitude (TEMP)
Ligne préliminaire
←←≡↓ZCZC→↑248→→→→→
En-tête abrégé
←←≡↓USSN↑01→↓ESWI→↑011200
Texte
←←≡↓TTAA→↑51111→02185→99...→......→.....etc.*
←←≡↑.....→.....→.....→.....→.....=
←←≡
←←≡↓TTAA→↑51111→↓NIL↑=
S
O
H
C
R
C
R
L
F
En-tête abrégé
C
R
C
R
L
F
USSN 01 S ESWI S 011200
Texte
C
R
C
R
L
F
TTAA
S
S
S
P 51111 P 02185 P
C
R
C
R
L
F
.....
S
P
.....
S
P .....
C
R
C
R
L
F
C
R
C
R
L
F
TTAA
S
P
51111
S
NIL=
P
C
R
C
R
L
F
E
T
X
Ligne préliminaire
Signaux de fin
de message
248
P
P
99...
S
P .....
S
S
P ..... P etc.*.....=
S
P
.....=
* Il faudrait utiliser au maximum la capacité d’une ligne de téléimprimeur (69 caractères par ligne). Voir aussi le
paragraphe 2.3.3.2.6 de la partie II.
4.
Exemples de formes de présentation des bulletins SYNOP
a) Toutes les Sections 1, 2, 3 et 4 doivent être transmises consécutivement sans insertion d’espace, ni de
barre oblique dans les groupes d’identification des Sections 3 et 4.
Exemple:
ZCZC 007
SMRS 10 RUMS 220600
AAXX 22061
26298 21/50 82503 11054 21058 40333 57010 71022 8807/ 333 21068 69902 =
26477 21335 82503 11049 21052 40247 57004 77777 886// 333 21049 69902 88706 =
26781 31296 82301 11050 21060 40248 52004 71022 887// 333 21057 88706 =
26997 21450 80000 11068 21/86 40310 52009 72070 886// 333 21146 60002 88712 =
27595 22997 93008 11077 21196 40158 52010 333 21191 69932 =
27612 31950 20000 11132 21145 40233 52002 71000 80001 333 21141 =
27731 22998 62902 11119 21154 40234 52013 80002 333 21117 69902 =
27947 32998 23602 11148 21178 40217 52020 80002 =
27962 22997 03404 11136 21171 40197 52027 333 21126 69992 =
NNNN
édition 2009
II-4/4
b) Les Sections 1, 2, 3 et 4 doivent commencer au début de la ligne mais les groupes d’identification des
Sections 3 et 4 doivent commencer à la suite de deux espaces en début de ligne.
Exemple:
ZCZC 055
SMDD 01 ETPD 110600
AAXX 11061
09393 32996 31704 10015 21027 40244 57005 83030
333 20015 34101 =
09543 32950 11401 11018 21034 40274 53002 81030
333 21018 3/103 41999 =
09184 32960 71905 10038 21006 40215 56003 8707/
333 20038 31003 =
09385 32960 51704 10018 21018 40243 5/005 83046
333 20017 34000 =
NNNN
5.
Exemples de formes de présentation des TEXTES NIL
a) Bulletin SYNOP
SMRS10 RUMS 220600
NIL
b) Bulletin TEMP
USSN01 ESWI 011200
NIL
c) Bulletin CREX
KOMS10 FAPR 220600
NIL
d) Bulletin BUFR
IUKN01 EGRR 221200
NIL
édition 2009
SUPPLéMENT II-5
INDICATEURS DE DONNÉES t1t2a1a2ii DANS LES EN-TÊTES ABRÉGÉS
Tableau A :
Valeur de T2A1A2ii pour l’indicateur de données T1
Tableau B1 :
Indicateur de type de données T2 (lorsque T1 = A, C, F, N, S, T, U ou W)
Tableau B2 :
Indicateur de type de données T2 (lorsque T1 = D, G, H, X ou Y)
Tableau B3 :
Indicateur de type de données T2 (lorsque T1 = I ou J)
Tableau B4 :
Indicateur de type de données T2 (lorsque T1 = O)
Tableau B5 :
Indicateur de type de données T2 (lorsque T1 = E)
Tableau B6 :
Indicateur de type de données T2 (lorsque T1 = P, Q)
Tableau C1 :
Indicateurs géographiques A1A2 à utiliser dans les en-têtes abrégés T1T2A1A2ii CCCC
YYGGgg pour les bulletins contenant des renseignements météorologiques, à l’exclusion
des messages d’observation de navires et des données océanographiques
Tableau C2 :
Indicateurs géographiques A1A2 à utiliser dans les en-têtes abrégés T1T2A1A2ii CCCC
YYGGgg pour les bulletins contenant des messages d’observation de navires et des
données océanographiques ou des messages d’observation de stations maritimes
automatiques
Tableau C3 :
Indicateur de la zone géographique A1 (lorsque T1 = D, G, H, O, P, Q, T, X ou Y) et
indicateur de la zone géographique A2 (lorsque T1 = I ou J)
Tableau C4 :
Indicateur de l’heure de référence A2 (lorsque T1 = D, G, H, J, O, P ou T)
Tableau C5 :
Indicateur de l’heure de référence A2 (lorsque T1 = Q, X ou Y)
Tableau C6 :
Indicateur de type de données A1 (lorsque T1 = I ou J)
Tableau C7 :
Indicateur de type de données T2 et A1 (lorsque T1 = K)
Tableau D1 :
Indicateur de niveau ii (lorsque T1 = O)
Tableau D2 :
Indicateur de niveau ii (lorsque T1 = D, G, H, J, P, Q, X ou Y)
Tableau D3 :
Indicateur de niveau ii (lorsque T1T2 = FA ou UA)
*
* *
édition 2009
II-5/2
Tableau A
Valeur de T2A1A2ii pour l’indicateur de données T1
T 1
Type de données
T 2
A 1
A 2
ii
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
Analyses
Messages adressés
Données climatologiques
Information aux points de grille (GRID)
Imagerie satellitaire
Prévisions
Information aux points de grille (GRID)
Information aux points de grille (GRIB)
Données d’observation binaire (BUFR)
Prévisions en binaire (BUFR)
CREX
–
–
Avertissements
Données océanographiques (GRIB)
Information graphique (en binaire)
Information graphique régionale
–
Données de surface
Données satellitaires
Données en altitude
Données nationales
Avis
GRID, à fins régionales
GRIB, à fins régionales
–
*
B1
***
B1
B2
B5
B1
B2
B2
B3
B3
B3
C1
***
C1
C3
C1
C1
C3
C3
C6
C6
C7
C1
***
C1
C4
C1
C1
C4
C4
C3
C4
C3
**
***
**
D2
**
**
D2
D2
**
D2
**
3
1/2/4*
4
3
3
3
3
3
2
3
2
B1
B4
B2
B2
C1
C3
C3
C3
C1
C4
C4
C5
**
D1
D2
D2
4
3
3
3
B1
B1
B1
(2)
B1
B2
B2
C1/C2
C3
C1/C2
C1
C1
C3
C3
C1/C2
C4
C1/C2
C1
C1
C5
C5
**
**
**
**
**
D2
D2
2/4*
2
2
(1)
1
3
3
Degré de priorité: le degré de priorité 1 est attribué aux messages de service,
le degré 2 aux messages de données et d’interrogation,
le degré 3 aux signaux sismiques de formes d’onde (T1T2 = SY),
le degré 4 aux messages administratifs.
** Définition et utilisation: voir le paragraphe 2.3.2.2.
*** Définition et utilisation: voir le paragraphe 2.4.2.
(1) à définir.
(2) Tableau B2 ou tableau national.
édition 2009
Degré de
priorité
II-5/3
SUPPLéMENT ii-5
Tableau B1
Indicateur de type de données T2 (lorsque T1 = A, C, F, N, S, T, U ou W)
Instructions pour une utilisation correcte des indicateurs de type de données
1.
Les indicateurs de ce tableau doivent être utilisés dans toute la mesure du possible pour préciser la
nature des données contenues dans le corps du bulletin.
2.
S’il n’existe pas d’indicateur correspondant aux données transmises, il conviendrait d’utiliser un des
indicateurs alphabétiques non attribués du tableau et d’en aviser le Secrétariat de l’OMM.
3.
Pour chaque code, seuls le numéro et le nom de la forme symbolique sont indiqués dans le tableau.
Pour éviter toute confusion, il a été décidé de supprimer le numéro, en chiffres romains, de la session
correspondante de la CSB, étant entendu que le code mentionné dans le tableau correspond à la dernière
version approuvée. Pour plus de précisions (nom complet du code, version, etc.), il convient de se référer au
Manuel des codes (OMM-N° 306) . Dans les rares cas où aucun des codes existant ne peut être utilisé, on doit
employer un nom général et une référence, par exemple [OACI] (AIREP). Si nécessaire, on peut joindre une
note explicative à la table utilisée.
4.
Lorsqu’il n’existe pas de forme de représentation normalisée pour un type particulier de données,
mais seulement une forme recommandée, celle-ci est indiquée entre crochets sous la rubrique “Forme
symbolique” (par exemple [TEXTE]). II s’agit d’un code alphanumérique formé librement à partir de
l’Alphabet international N° 2 (supplément II-l) ou N° 5 (supplément II-2).
T1 = A Analyses
Indicateur T2
C
G
H
I
O
R
S
U
W
X
Type de données
Cyclone
Analyses hydrologiques/marines
épaisseur
Glaces
Couche d’ozone
Données de radar
Données de surface
Données en altitude
Résumé du temps
Données diverses
Forme symbolique (nom)
[TEXTE]
[TEXTE]
[TEXTE]
FM 44 (ICEAN)
[TEXTE]
[TEXTE]
FM 45 (IAC)/FM 46 (IAC FLEET)
FM 45 (IAC)
[TEXTE]
[TEXTE]
T1 = C Données climatologiques
Indicateur T2
A
E
H
O
S
U
Type de données
Anomalies climatiques
Moyennes mensuelles (données en altitude)
Moyennes mensuelles (données en surface)
Moyennes mensuelles (zones océaniques)
Moyennes mensuelles (données en surface)
Moyennes mensuelles (données en altitude)
[TEXTE]
FM 76 (CLIMAT TEMP SHIP)
FM 72 (CLIMAT SHIP)
FM 73 (NACLI, CLINP, SPCLI, CLISA, INCLI)
FM 71 (CLIMAT)
FM 75 (CLIMAT TEMP)
édition 2009
II-5/4
T1 = F Prévisions
Indicateur T2
A
B
C
D
E
F
G
H
I
J
K
L
M
O
P
Q
R
S
T
U
V
W
X
Z
Type de données
Prévision de zone pour l’aviation/GAMET
FM 53 (ARFOR)/[TEXT]
Vents et températures en altitude
FM 50 (WINTEM)
Prévision d’aérodrome (VT < 12 heures)
FM 51 (TAF)
Prévision radiologique de trajectoire et de dose
FM 57 (RADOF)
Prévision étendue
[TEXTE]
Prévision pour la navigation maritime
FM 46 (IAC FLEET)
Prévision hydrologique
FM 68 (HYFOR)
épaisseur en altitude
[TEXTE]
Iceberg
[TEXTE]
Services d’avis radioélectrique (y compris les données IUWDS)
[TEXTE]
Messages-avis concernant les cyclones tropicaux [TEXTE]
Prévisions locales/de zone
[TEXTE]
Températures extrêmes
[TEXTE]
Indications
[TEXTE]
Prévision pour le public
[TEXTE]
Autre prévision destinée à la navigation maritime [TEXTE]
Prévision de route pour l’aviation
FM 54 (ROFOR)
Prévision en surface
FM 45 (IAC)/FM 46 (IAC FLEET)
Prévision d’aérodrome (VT ≥ 12 heures)
FM 51 (TAF)
Prévision en altitude
FM 45 (IAC)
Messages-avis concernant les cendres volcaniques [TEXTE]
Prévision pour les sports d’hiver
[TEXTE]
Prévisions diverses
[TEXTE]
FM 61 (MAFOR)
Prévision de zone pour la navigation maritime
T1 = N Notification ou avertissement
Indicateur T2
G
H
N
O
P
T
W
Type de données
Notification hydrologique
Notification maritime
Données relatives à un accident nucléaire
Message METNO/WIFMA
Avis de retard dans l’élaboration d’un produit
Message d’essai [système]
Notification relative aux avis et/ou annulation
[TEXTE]
[TEXTE]
[TEXTE]
[TEXTE]
[TEXTE]
[TEXTE]
[TEXTE]
T1 = S Données de surface
Indicateur T2
A
B
C
D
E
F
G
I
Type de données
Message d’observation météorologique
régulière pour l’aviation
Message d’observation météorologique
par radar (partie A)
Message d’observation météorologique par radar (partie B)
Message d’observation météorologique par radar (parties A et B)
Données sismiques
Messages d’observation des parasites
atmosphériques
Messages de données radiologiques
Heure synoptique intermédiaire
FM 15 (METAR)
FM 20 (RADOB)
FM 20 (RADOB)
FM 20 (RADOB)
* (SEISMIC)
FM 81 (SFAZI)/FM 82 (SFLOC)/
FM 83 (SFAZU)
FM 22 (RADREP)
FM 12 (SYNOP)/FM 13 (SHIP)
________
*
Le code international pour la transmission des données sismiques est décrit dans le Volume I, supplément I
du Manuel des codes (OMM-N° 306).
édition 2009
II-5/5
SUPPLéMENT ii-5
T1 = S Données de surface (suite)
Indicateur T2
Type de données
L
—
—
M
Heure synoptique principale
N
Heure synoptique non standard
FM 63 (BATHY)/FM 64 (TESAC)/
O
Données océanographiques
FM 62 (TRACKOB)
P
Message d’observation météorologique spéciale FM 16 (SPECI)
sélectionné pour l’aviation
R
Message d’observation hydrologique (cours d’eau)FM 67 (HYDRA)
FM 18 (DRIFTER)
S
Messages d’observation de bouées dérivantes
[TEXTE]
T
Glaces de mer
U
épaisseur de la neige
[TEXTE]
[TEXTE]
V
Glaces de lac
FM 65 (WAVEOB)
W
Renseignements sur les vagues
X
Données diverses
[TEXTE]
Y
Données sismiques sur les ondes
(toute forme de présentation)
Z
Données sur le niveau de la mer et (toute forme de présentation
les tsunamis du grand large
alphanumérique)
T1 = T Données satellitaires
Indicateur T2
B
C
H
R
T
W
X
Type de données
Paramètres de l’orbite du satellite
Interprétations des données de nuages
fournies par des satellites
Télésondages en altitude à partir de satellites
Données d’observation de la luminance
énergétique en air clair
Température de la mer en surface
Vent et température des nuages
Données diverses
[TEXTE]
FM 85 (SAREP)
FM 86 (SATEM)
FM 87 (SARAD)
FM 88 (SATOB)
FM 88 (SATOB)
[TEXTE]
T1 = U Données en altitude
Indicateur T2
Type de données
A
Comptes rendus d’aéronef
FM 41 (CODAR), ICAO (AIREP)
FM 42 (AMDAR)
D
Comptes rendus d’aéronef
FM 35 (TEMP)/FM 36 (TEMP SHIP)/
E
Données de pression, de température,
d’humidité et de vent en altitude (partie D)
FM 38 (TEMP MOBIL)
F
Pression, température, humidité et vent en altitude FM 35 (TEMP)/FM 36 (TEMP SHIP)/
(parties C et D) [Options nationales et bilatérales] FM 38 (TEMP MOBIL)
FM 32 (PILOT)/FM 33 (PILOT SHIP)/
G
Vent en altitude (partie B)
FM 34 (TEMP MOBIL)
H
Vent en altitude (partie C)
FM 34 (TEMP MOBIL)
I
Vent en altitude (parties A et B)
FM 34 (TEMP MOBIL)
[Options nationales et bilatérales]
K
Pression, température, humidité et vent
FM 38 (TEMP MOBIL)
en altitude (partie B)
L
FM 38 (TEMP MOBIL)
en altitude (partie C)
M
Pression, température, humidité et vent en altitude FM 35 (TEMP)/FM 36 (TEMP SHIP)/
FM 38 (TEMP MOBIL)
(parties A et B) [Options nationales et bilatérales]
FM 39 (ROCOB)/FM 40 (ROCOB SHIP)
N
Message d’observation provenant d’une
station de sondage par fusée
édition 2009
II-5/6
T1 = U Données en altitude (suite)
Indicateur T2
Type de données
P
Vent en altitude (partie A)
Q
Vent en altitude (partie D)
R
Compte rendu d’aéronef
S
en altitude (partie A)
T
Compte rendu d’aéronef
X
Données diverses
Y
Vent en altitude (parties C et D)
[Options nationales et bilatérales]
Z
Message d’observation en altitude de pression,
température, humidité et vent provenant d’une
sonde larguée d’un ballon porteur ou d’un aéronef
(parties A, B, C et D)
________
*
FM 34 (PILOT MOBIL)
FM 34 (PILOT MOBIL)
[NATIONAL*] (RECCO)
FM 35 (TEMP)/FM 36 (PILOT SHIP)/
FM 38 (TEMP MOBIL)
FM 41 (CODAR)
[TEXTE]
FM 34 (PILOT MOBIL)
FM 37 (TEMP DROP)
Exemple: forme symbolique utilisée aux états-Unis d’Amérique pour les messages provenant de vols de
reconnaissance météorologique (RECCO) — voir le Manuel des codes (OMM-N° 306), Volume II, chapitre IV,
partie F.
T1 = W Avis
Indicateur T2
A
C
E
F
G
H
O
S
T
U
V
W
Type de données
AIRMET
Cyclone tropical (SIGMET)
Tsunami
Avis de tornade
Avis hydrologique/crue
Avis maritime/inondation côtière
Avis divers
Message SIGMET
Avis de cyclone tropical (typhon, ouragan)
Avis d’orage violent
Nuages de cendres volcaniques (SIGMET)
Avis et aperçus météorologiques
[TEXTE]
[TEXTE]
[TEXTE]
[TEXTE]
[TEXTE]
[TEXTE]
[TEXTE]
[TEXTE]
[TEXTE]
[TEXTE]
[TEXTE]
[TEXTE]
Tableau B2
Indicateur de type de données T2 (lorsque T1 = D, G, H, X ou Y)
Instructions à suivre pour utiliser correctement les indicateurs de type de données
1.
Les indicateurs spécifiés dans ce tableau devraient être utilisés dans toute la mesure du possible
pour indiquer le type de données figurant dans le texte du bulletin.
2.
Lorsque ce texte contient plusieurs types de données, il ne faudrait utiliser que l’indicateur
correspondant à l’un des types de données.
3.
Lorsque le tableau ne contient pas d’indicateur approprié pour le type de données, il faudrait
utiliser un indicateur alphabétique qui n’est pas attribué et en aviser le Secrétariat de l’OMM.
édition 2009
II-5/7
SUPPLéMENT ii-5
Tableau B2 (suite)
Indicateur
Type de données
Indicateur
A
B
C
D
E
F
G
H
I
J
K
L
M
Données radar
Nébulosité
Tourbillon
épaisseur (topographie relative)
Précipitation
—
Divergence
Hauteur
—
Hauteur des vagues + combinaisons
de données
Hauteur de la houle + combinaisons
de données
—
Données à usage national
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
Type de données
Rayonnement
Vitesse verticale
Pression
Température potentielle du
thermomètre mouillé
Humidité relative
—
Température
Composante est du vent
Composante nord du vent
Vent
—
—
Non attribué
Tableau B3
Indicateur de type de données T2 (lorsque T1 = I ou J)
1.
pour indiquer le type de données figurant dans le texte du bulletin BUFR.
2.
3.
Indicateur
N
O
P
S
T
U
X
Type de données
Données satellitaires
Données océanographiques/limnigraphiques (propriétés de l’eau)
Données graphiques
Surface/niveau de la mer
Texte (information en langage clair)
Données d’observation en altitude
Autres types de données
Tableau B4
Indicateur de type de données T2 (lorsque T1 = O)
1.
pour indiquer le type de données figurant dans le texte du bulletin GRIB pour les produits océanographiques.
2.
3.
Indicateur
D
E
F
G
H
Type de données
Profondeur
Concentration de glace
épaisseur de la glace
Dérive des glaces
Croissance des glaces
édition 2009
II-5/8
Tableau B4 (suite)
Indicateur
I
Q
R
S
T
U
V
W
X
Type de données
Convergence/divergence (glaces)
Anomalie de température
Anomalie de profondeur
Salinité
Température
Composante de courant
Composante de courant
Réchauffement de la température
Combinaisons de données
Tableau B5
Indicateur de type de données T2 (lorsque T1 = E)
Indicateur
C
F
I
S
V
W
Y
Z
Type de données
Température du sommet des nuages
Brouillard
Infrarouge
Température en surface
Visible
Vapeur d’eau
à définir par l’usager
Non défini
Tableau B6
Indicateur de type de données T2 (lorsque T1 = P, Q)
1.
pour indiquer le type de données figurant dans le texte du bulletin.
2.
3.
Indicateur
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
édition 2009
Type de données
Données radar
Nébulosité
Turbulence en air clair
épaisseur (topographie relative)
Précipitation
Diagrammes aérologiques (nuage de cendres)
Temps significatif
Hauteur
Banquise flottante
Hauteur des vagues + combinaisons de données
Hauteur de la houle + combinaisons de données
Information en langage clair
Données à usage national
Rayonnement
Vitesse verticale
Pression
Température potentielle du thermomètre mouillé
Humidité relative
Enneigement
SUPPLéMENT ii-5
II-5/9
Tableau B6 (suite)
Indicateur
T
U
V
W
X
Y
Z
Type de données
Température
Composante est du vent
Composante nord du vent
Vent
Indice de soulèvement
Carte pointée
Non attribué
Tableau C1
Indicateurs géographiques A1A2 à utiliser dans les en-têtes abrégés T1T2A1A2ii CCCC YYGGgg
pour les bulletins contenant des renseignements météorologiques,
à l’exclusion des messages d’observation de navires et
des données océanographiques
Instructions à suivre pour utiliser correctement les indicateurs géographiques
1.
Ce tableau est divisé en deux parties: la première partie contient les indicateurs géographiques
afférents aux pays ou territoires situés dans la zone de responsabilité allouée à chaque CRT pour le
rassemblement des messages d’observation (observations en surface et en altitude), tandis que la seconde
partie contient les indicateurs géographiques correspondant à de vastes étendues telles que continents,
hémisphères, etc.
2.
Dans le cas de bulletins contenant des messages d’observation (en surface et en altitude) de
stations terrestres, les indicateurs géographiques de la seconde partie du tableau ne devraient être utilisés
que lorsque aucun des indicateurs de la première partie ne convient.
3.
Dans le cas de bulletins contenant des renseignements météorologiques tels que comptes rendus
d’aéronefs, analyses, analyses prévues, avis, données climatologiques, données recueillies par satellite, ainsi
que pour la transmission de renseignements par fac-similé analogique, il peut être fait usage de tous les
indicateurs géographiques figurant dans le tableau. Toutefois, il faudrait autant que possible éviter d’utiliser
l’indicateur géographique XX.
4.
Dans l’en-tête abrégé des messages METNO et WIFMA, il conviendrait d’utiliser XX comme
indicateur géographique.
5.
Les indicateurs géographiques contenus dans ce tableau ne devraient pas être utilisés
dans les en-têtes abrégés de bulletins contenant des messages d’observation de navires et des données
océanographiques.
Notes:
1. Les appellations employées dans ce tableau et la présentation des données qui y figurent n’impliquent de
la part du Secrétariat de l’Organisation météorologique mondiale aucune prise de position quant au statut
juridique des pays, territoires, villes ou zones, ou de leurs autorités, ni quant au tracé de leurs frontières ou
limites.
2. Pour T1T2 = SZ, employer l’indicateur de zone A1A2 du tableau C1.
*
* *
édition 2009
II-5/10
Partie I — Indicateurs de pays ou de territoires
A1A2
Pays
AB
AG
AH
AI
AJ
AK
AL
AN
AT
AU
AY
AZ
Albanie
Argentine
Afghanistan
Île de l’Ascension
Azerbaïdjan
Alaska
Algérie
Angola
Antigua-et-Barbuda, Saint-Kitts-et-Nevis et autres îles britanniques du voisinage
Australie
Arménie
Açores
BA
BC
BD
BE
BH
BI
BJ
BK
BM
BN
BO
BR
BU
BV
BW
BX
BY
BZ
Bahamas
Botswana
Brunéi Darussalam
Bermudes
Belize
Burundi
Bénin
Îles Banks
Myanmar
Bahreïn
Bolivie
Barbade
Bulgarie
Île Bouvet
Bangladesh
Belgique, Luxembourg
Bélarus
Brésil
CD
CE
CG
CH
CI
CM
CN
CO
CR
CS
CT
CU
CV
CY
CZ
Tchad
République centrafricaine
Congo
Chili
Chine
Cameroun
Canada
Colombie
Îles Canaries (Espagne)
Costa Rica
Île Canton
Cuba
Cap-Vert
Chypre
République tchèque
DJ
DL
DN
DO
DR
Djibouti
Allemagne
Danemark
Dominique
République dominicaine
édition 2009
A1A2
Pays
EG
EO
EQ
ER
ES
ET
égypte
Estonie
équateur
émirats arabes unis
El Salvador
éthiopie
FA
FG
FI
FJ
FK
FP
FR
FW
Îles Féroé
Guyane française
Finlande
Fidji
Îles Falkland (Malvinas)
Saint-Pierre-et-Miquelon
France
Wallis-et-Futuna
GB
GC
GD
GE
GG
GH
GI
GL
GM
GN
GO
GQ
GR
GU
GW
GY
Gambie
Îles Caïmanes
Grenade
Île Gough
Géorgie
Ghana
Gibraltar
Groenland
Guam
Guinée
Gabon
Guinée équatoriale
Grèce
Guatemala
Guinée-Bissau
Guyana
HA
HE
HK
HO
HU
HV
HW
Haïti
Sainte-Hélène
Hong Kong, Chine
Honduras
Hongrie
Burkina Faso
Îles Hawaii
IC
ID
IE
IL
IN
IQ
IR
IS
IV
IY
Comores
Indonésie
Irlande
Islande
Inde
Iraq
Iran, République islamique d’
Israël
Côte d’Ivoire
Italie
JD
JM
JP
Jordanie
Jamaïque
Japon
II-5/11
SUPPLéMENT ii-5
Tableau C1 – Partie I (suite)
A1A2
Pays
KA
KB
KI
KK
KN
KO
KP
KR
KU
KW
KY
KZ
Îles Carolines
Kiribati
Île Christmas
Îles Cocos
Kenya
République de Corée
Cambodge
République populaire démocratique de Corée
Îles Cook
Koweït
Kirghizistan
Kazakhstan
LA
LB
LC
LI
LJ
LN
LS
LT
LV
LY
MA
MB
MC
MD
MF
MG
MH
MI
MJ
MK
ML
MN
MO
MR
MS
MT
MU
MV
MW
MX
MY
MZ
NC
NG
NI
NK
République démocratique populaire lao
Liban
Sainte-Lucie
Libéria
Slovénie
Îles méridionales de la Ligne
Lesotho
Lituanie
Lettonie
Jamahiriya arabe libyenne
Maurice
Île Marion
Maroc
Madère
Saint-Martin, Saint-Barthélemy, Guadeloupe et autres îles françaises du voisinage
Madagascar
Îles Marshall
Mali
Ex-République yougoslave
de Macédoine
Monténégro
Malte
St. Maarten, St. Eustatius et Saba
Mongolie
Martinique
Malaisie
Mauritanie
Macao, Chine
Maldives
Malawi
Mexique
Îles Mariannes
Mozambique
Nouvelle-Calédonie
Papouasie-Nouvelle-Guinée
Nigéria
Nicaragua
A1A2
Pays
NL
NM
NO
NP
NR
NU
NV
NW
NZ
Pays-Bas
Namibie
Norvège
Népal
Niger
Antilles néerlandaises (Bonaire, Curaçao) et Aruba
Vanuatu
Nauru
Nouvelle-Zélande
OM
OR
OS
Oman
Îles Orcades du Sud
Autriche
PF
PH
PI
PK
PL
PM
PO
PR
PT
PU
PY
Polynésie française
Philippines
Îles Phœnix
Pakistan
Pologne
Panama
Portugal
Pérou
Pitcairn
Porto Rico
Paraguay
QB
QT
Bosnie-Herzégovine
Qatar
RA
RE
RH
RM
RO
RS
RW
Fédération de Russie (Asie)
Réunion et îles associées
Croatie
Moldova
Roumanie
Fédération de Russie (Europe)
Rwanda
SB
SC
SD
SG
SI
SK
SL
SM
SN
SO
SP
SQ
SR
SU
SV
SW
SX
SY
Sri Lanka
Seychelles
Arabie saoudite
Sénégal
Somalie
Sarawak
Sierra Leone
Suriname
Suède
Îles Salomon
Espagne
Slovaquie
Singapour
Soudan
Swaziland
Suisse
Îles Santa Cruz
République arabe syrienne
édition 2009
II-5/12
Tableau C1 – Partie I (suite)
A1A2
Pays
SZ
TA
TC
TD
TG
TH
TI
TK
TM
TN
TO
TP
TR
TS
TU
TV
Spitzberg
Tadjikistan
Tristan da Cunha
Trinité-et-Tobago
Togo
Thaïlande
Îles Turques et Caïques
Tokelau
Timor-Leste
République-Unie de Tanzanie
Tonga
Sao Tomé-et-Principe
Turkménistan
Tunisie
Turquie
Tuvalu
UG
UK
Ouganda
Royaume-Uni de Grande-Bretagne et d’Irlande du Nord
édition 2009
A1A2
Pays
UR
US
UY
UZ
Ukraine
États-Unis d’Amérique
Uruguay
Ouzbékistan
VG
VI
VN
VS
Saint-Vincent-et-les Grenadines
Îles Vierges
Venezuela
Viet Nam
YE
YG
Yémen
Serbie
ZA
ZB
ZM
ZR
ZW
Afrique du Sud
Zambie
Samoa
République démocratique du Congo
Zimbabwe
II-5/13
SUPPLéMENT ii-5
Partie II — Indicateurs de zones
A1A2
Zone géographique
A1A2
Zone géographique
AA
AC
AE
AF
AM
AO
AP
AS
AW
AX
BQ
CA
EA
EC
EE
EM
EN
EU
EW
Antarctique
Arctique
Asie du Sud-Est
Afrique
Afrique centrale
Afrique occidentale
Afrique méridionale
Asie
Proche-Orient
Zone de la mer d’Oman
Zone de la mer Baltique
Caraïbes et Amérique centrale
Afrique orientale
Zone orientale de la mer de Chine
Europe orientale
Europe centrale
Europe septentrionale
Europe
Europe occidentale
MP
MQ
Zone de la Méditerranée centrale
Zone de la Méditerranée occidentale
NA
NT
Amérique du Nord
Zone de l’Atlantique Nord
OC
OH
Océanie
Mer d’Okhotsk
PA
PE
PN
PQ
PS
PW
PZ
Zone du Pacifique
Zone du golfe Persique
Zone du Pacifique Nord
Pacifique Nord-Ouest
Zone du Pacifique Sud
Zone du Pacifique Ouest
Zone du Pacifique Est
SA
SE
SJ
SS
ST
Amérique du Sud
Zone océanique australe
Zone de la mer du Japon
Zone méridionale de la mer de Chine
Zone de l’Atlantique Sud
FE
GA
GX
IO
ME
MM
Extrême-Orient
Zone du golfe de l’Alaska
Zone du golfe du Mexique
Zone de l’océan Indien
Zone de la Méditerranée orientale
Zone méditerranéenne
XE
XN
XS
XT
XW
XX
Hémisphère oriental
Hémisphère Nord
Hémisphère Sud
Ceinture tropicale
Hémisphère occidental
à utiliser lorsque les autres indicateurs ne conviennent pas
*
* *
édition 2009
II-5/14
Tableau C2
Indicateurs géographiques A1A2 à utiliser dans les en-têtes abrégés T1T2A1A2ii CCCC YYGGgg
pour les bulletins contenant des messages d’observation de navires et des données
océanographiques ou des messages d’observation de stations maritimes automatiques
Instructions à suivre pour utiliser correctement les indicateurs géographiques
1.
La première lettre A1 indique de quel genre de station il s’agit:
Pour les stations météorologiques océaniques:
W
Pour les navires faisant route et les autres stations maritimes: V
F
Pour les flotteurs (T1T2 = SO):
2.
La seconde lettre A2 indique la zone d’où proviennent les messages contenus dans les bulletins.
3.
Chaque fois que cela est possible, il conviendrait d’établir des bulletins distincts pour éviter
l’emploi de la lettre X.
Note: Pour T1T2 = SZ, employer l’indicateur de zone A1A2 du tableau C1.
Indicateur
A
B
C
D
E
F
J
X
Zone géographique
Zone comprise entre 30°N et 60°S, 35°W et 70°E
Zone comprise entre 90°N et 05°N, 70°E et 180°E
Zone comprise entre 05°N et 60°S, 120°W et 35°W
Zone comprise entre 90°N et 05°N, 180°W et 35°W
Zone comprise entre 05°N et 60°S, 70°E et 120°W
Zone comprise entre 90°N et 30°N, 35°W et 70°E
Zone située au sud de 60°S
Plus d’une zone
Tableau C3
Indicateur de la zone géographique A1 (lorsque T1 = D, G, H, O, P, Q, T, X ou Y)
et indicateur de la zone géographique A2 (lorsque T1 = I ou J)
Instructions à suivre pour utiliser correctement les indicateurs de la zone géographique
1.
pour indiquer la zone géographique à laquelle s’appliquent les données figurant dans le texte du bulletin.
2.
Lorsque cette zone géographique ne correspond pas exactement à l’indicateur, on peut utiliser
l’indicateur correspondant à la zone la plus voisine de celle à laquelle s’appliquent les données.
3.
Lorsque le tableau ne contient pas d’indicateur approprié pour la zone géographique, il faudrait
édition 2009
Indicateur
Zone géographique
A
B
C
D
E
F
G
H
I
J
K
L
N
0° – 90°W hémisphère Nord
90°W –180° hémisphère Nord
180° – 90°E hémisphère Nord
90°E – 0° hémisphère Nord
0° – 90°W ceinture tropicale
90°W –180° ceinture tropicale
180° – 90°E ceinture tropicale
90°E – 0°
ceinture tropicale
0° – 90°W hémisphère Sud
90°W –180° hémisphère Sud
180° – 90°E hémisphère Sud
90°E – 0° hémisphère Sud
Hémisphère Nord
II-5/15
SUPPLéMENT ii-5
Tableau C3 (suite)
S
T
X
Hémisphère Sud
45°W –180°
hémisphère Nord
Monde entier (zone non définissable)
Tableau C4
Indicateur de l’heure de référence A2 (lorsque T1 = D, G, H, J, O, P, ou T)
Instructions à suivre pour utiliser correctement les indicateurs de l’heure de référence
1.
pour indiquer l’heure de référence des données figurant dans le texte du bulletin.
2.
Lorsque le tableau ne contient pas d’indicateur approprié pour l’heure de référence, il faudrait
utiliser un indicateur alphabétique qui n’est pas attribué.
Indicateur
A
B
C
D
E
F
G
H
I
J
K
L
Heure de référence
Indicateur
Analyse (00 heure)
Prévision de 6 heures
M
N
O
P
Q
R
S
T
U
V
W. . .Z
Prévision de 120 heures (5 jours)
Prévision de 156 heures (7 jours)
Prévision de 10 jours
Pas d’attribution
Tableau C5
Indicateur de l’heure de référence A2 (lorsque T1 = Q, X ou Y)
Indicateur
A
B
C
D
E
F
G
H
I
Indicateur
Analyse (00 heure)
J
K
L
M
N
O
P
Q
*
* *
édition 2009
II-5/16
Tableau C6
Indicateur de type de données A1 (lorsque T1 = I ou J)
1.
pour indiquer le type de données figurant dans le texte du bulletin BUFR.
2.
3.
T1T2 A1
ii
Type de données
Correspondance
avec les codes
alphanumériques
traditionnels
IN
IN
IN
IN
A
B
H
M
Données-satellite (AMSUA)
Données-satellite (AMSUB)
Données-satellite (HIRS)
Données-satellite (MHS)
IO
IO
IO
IO
IO
IO
IO
IO
B
I
P
R
S
T
W
X
Observations provenant de bouées
Glaces de mer
Profils provenant de flotteurs profonds
Observations à la surface de la mer
Sondages à la surface et sous la surface de la mer
Vagues de la mer en surface
Autres paramètres marins
IP
IP
IP
IP
C
I
R
X
Données d’imagerie radar composite
Données d’imagerie satellitaire
Données d’imagerie radar
à définir
IS A 01-29
IS A 30-59
IS B
IS C 01-45
IS C 46-59
IS D
IS E
IS F
IS I 01-45
IS I 46-59
IS M 01-45
IS M 46-59
édition 2009
Catégorie/sous-
catégorie de données
(Table de code
commune C-13)
003/003
003/004
003/005
003/006
BUOY
001/025
TESAC
TRACKOB
BATHY, TESAC
031/004
031/001
031/005
WAVEOB
031/002
Observations régulières provenant de stations
n.d.
automatiques terrestres (fixes ou mobiles)
(par ex. 0000, 0100, … ou 0220, 0240,
0300, … ou 0715, 0745, ... UTC)
n.d.
Observations sur n minutes provenant de stations automatiques terrestres
(fixes ou mobiles)
Messages d’observation par radar (parties A et B) RADOB
CLIMAT
Observations climatologiques provenant de stations terrestres
CLIMAT SHIP
Observations climatologiques provenant de stations maritimes
RADREP
Observations radiologiques
Mesure de l’ozone en surface
n.d.
SFAZI, SFLOC, SFAZU
Source d’atmosphériques
SYNOP (SIxx)
Observations de stations terrestres fixes faites aux heures synoptiques intermédiaires
SYNOP MOBIL
Observations de stations terrestres mobiles faites aux heures synoptiques intermédiaires
SYNOP (SMxx)
Observations de stations terrestres fixes
faites aux heures synoptiques principales
SYNOP MOBIL
Observations de stations terrestres mobiles faites aux heures synoptiques principales
000/006
000/007
006/003
000/020
001/020
010/001
008/000
000/030
000/001
000/051
000/004
000/002
000/052
000/005
II-5/17
SUPPLéMENT ii-5
Tableau C6 (suite)
T1T2 A1
ii
Type de données
Correspondance
avec les codes
alphanumériques
traditionnels
IS
IS
IS
IS
IS
IS
IS
IS
IS
IS
IS
N 01-45
N 46-59
R S 01-19
S 20-39
S 40-59
T 01-19
T 20-39
V W X Observations synoptiques de stations terrestres fixes faites à des moments autres que les heures standard (par ex. 0100, 0200, 0400,
0500, ... UTC)
Observations synoptiques de stations terrestres
mobiles faites à des moments autres que les heures standard (par ex. 0100, 0200, 0400,
0500, ... UTC)
Messages d’observation hydrologique
Observations synoptiques de stations maritimes
Observations sur une heure provenant de
stations maritimes automatiques
Observations sur n minutes provenant de
Observations provenant de marégraphes
Séries chronologiques du niveau de l’eau
observé
Observations aéronautiques spéciales (SPECI)
Observations aéronautiques régulières (METAR)
Autres données d’observation en surface
IT
IT
IT
IT
A
B
R
X
Messages administratifs
Messages de service
Demandes de données (type compris)
Autres messages ou informations
IU
IU
IU
IU
IU
IU
IU
IU
IU
IU
IU
IU
IU
A
A
B
C
D
E
I
J
J
J
K
K
K
01-19
20-39
40-59
01-19
20-39
40-59
Comptes rendus d’aéronef pour un seul niveau (automatiques)
Comptes rendus d’aéronef pour un seul niveau
(manuels)
Messages d’observation par ballon pour un
seul niveau
(Utilisé pour les messages d’observation dérivés de données satellitaires pour un seul niveau – voir note 3)
Données obtenues par sonde parachutée
Sondages verticaux de l’ozone
Dispersion et transport
Messages d’observation du vent en altitude provenant de stations terrestres fixes
(observations complètes)
Messages d’observation du vent en altitude provenant de stations terrestres mobiles (observations complètes)
Messages d’observation du vent en altitude provenant de stations maritimes (observations complètes)
Messages d’observation de radiosondes provenant de stations terrestres fixes (jusqu’à 100 hPa)
Messages d’observation de radiosondes provenant de stations terrestres mobiles (jusqu’à 100 hPa)
Messages d’observation de radiosondes
provenant de stations maritimes
(jusqu’à 100 hPa)
Catégorie/souscatégorie de données
(Table de code
commune C-13)
SYNOP (SNxx)
000/000
000/050
SYNOP MOBIL
000/003
HYDRA
SHIP
n.d.
000/040
001/000
001/006
n.d.
001/007
n.d.
n.d.
001/030
001/031
SPECI
METAR
IAC, IAC FLEET
000/011
000/010
AMDAR
004/000
AIREP/PIREP
004/001
n.d.
SAREP/SATOB
005/000
TEMP DROP
n.d.
n.d.
PILOT,
002/007
008/001
009/000
002/001
PILOT MOBIL
002/003
PILOT SHIP
002/002
TEMP (parties A et B)
002/004
TEMP MOBIL
(parties A et B)
002/006
TEMP SHIP (parties A et B)
002/005
édition 2009
II-5/18
Tableau C6 (suite)
T1T2 A1
ii
Type de données
Correspondance
avec les codes
alphanumériques
traditionnels
IU
IU
IU
IU
IU
IU
IU
IU
IU
IU
IU
IU
IU
IU
IU
IU
M N O P Q R S 01-19
S 20-39
S 40-59
T U 01-45
U 46-59
W 01-19
W 20-39
W 40-59
X Sondages dérivés de modèles
Données obtenues par fusées-sondes
Profils d’observations d’aéronef en montée/
descente
Profils
Profils de la température provenant de systèmes
de sondage radio-acoustique
(Utilisé pour les données relatives à la luminance énergétique – voir note 3)
Messages d’observation de radiosondes/
ballons-pilotes provenant de stations terrestres
fixes (observations complètes)
Messages d’observation de radiosondes provenant de stations terrestres mobiles (observations complètes)
Messages d’observation de radiosondes provenant de stations maritimes (observations
complètes)
(Utilisé pour les sondages dérivés de données satellitaires – voir note 3)
Statistiques mensuelles provenant de stations d’observation en altitude
Statistiques mensuelles provenant de stations maritimes
Messages d’observation du vent en altitude provenant de stations terrestres fixes (jusqu’à 100 hPa)
Messages d’observation du vent en altitude provenant de stations terrestres mobiles (jusqu’à 100 hPa)
Messages d’observation du vent en altitude provenant de stations maritimes (jusqu’à 100 hPa)
Autres messages d’observation en altitude
JO
JO
JO
JO
JO
I S T W X Glaces de mer
JS
JS
JS
JS
JS
JS
JS
JS
JS
A
D
M
O
P
R
S
T
X
Prévisions de zone en surface (routes aériennes,
par ex.)
RADOF
Prévisions radiologiques
Prévisions de surface (MOS, par ex.)
MAFOR
Prévisions maritimes
Amendements aux prévisions (routes aériennes,
par ex.)
HYFOR
Prévisions hydrologiques
Amendements aux prévisions (TAF)
Prévisions d’aérodrome (TAF)
Autres prévisions de surface
JT
JT
E H édition 2009
Tsunamis
Avis d’ouragans, de typhons, de tempêtes tropicales
(Table de code
commune C-13)
AMDAR
002/020
PILOT
TEMP
002/010
002/011
TEMP (parties A, B, C et D)
002/004
TEMP MOBIL
002/006
TEMP SHIP
002/005
SATEM, SARAD, SATOB
CLIMAT TEMP
002/025
CLIMAT TEMP, SHIP
002/026
PILOT (parties A et B)
002/001
PILOT MOBIL
(parties A et B)
002/003
PILOT SHIP
(parties A et B)
002/002
II-5/19
SUPPLéMENT ii-5
Tableau C6 (suite)
T1T2 A1
ii
Type de données
Correspondance
avec les codes
alphanumériques
traditionnels
JT
JT
JT
S T X Phénomènes météorologiques violents, SIGMET
Avis de tornades
Autres avis
JU
JU
JU
JU
JU
JU
JU
JU
JU
JU
JU
A B C F N O S T V W X Prévisions pour un seul niveau
Messages TEMSI en code binaire, Cumulonimbus noyés
Messages TEMSI en code binaire, Turbulences en air clair
Messages TEMSI en code binaire, Fronts
Messages TEMSI en code binaire, Autres paramètres du temps significatif
Messages TEMSI en code binaire, Turbulences
Sondages prévus
Messages TEMSI en code binaire, Givrage/Tropopause
Messages TEMSI en code binaire, Tempêtes tropicales, tempêtes de sable, volcans
Messages TEMSI en code binaire, Vents à haute altitude
Autres prévisions en altitude
(Table de code
commune C-13)
Notes:
1. Le contenu des messages ISMx, ISIx et ISNx correspond au contenu des messages SYNOP traditionnels SMxx,
SIxx et SNxx.
2. Catégorie/sous-catégorie = 000/000 identifie les données SYNOP à partir de 0100, 0200, 0400, 0500, 0700,
0800, 1000, 1100, 1300, ... UTC. Ainsi, SNxx en SYNOP traditionnel correspond à ISNx en BUFR.
3. Les indicateurs A1 pour T1T2 déjà utilisés pour des données satellitaires (IUC, IUR, IUT, par ex.) ne sont pas affectés
et sont réservés à un futur usage en attendant l’affectation de A1 pour T1T2 = IN (données satellitaires).
Tableau C7
Indicateur de type de données T2 et A1 (lorsque T1 = K)
T1T2 A1
ii
Type de données
KF
KF
KF
KF
KF
KF
KF
KF
KF
A
D
M
O
P
R
S
T
X
KO B
KO I
KO P
Correspondance
avec les codes
alphanumériques
traditionnels
(Table de code
commune C-13)
Prévisions de zone en surface (routes aériennes,
par ex.)
Prévisions radiologiques
Prévisions de surface (MOS, par ex.)
Prévisions maritimes
Amendements aux prévisions (routes aériennes, par ex.)
Prévisions hydrologiques
Amendements aux prévisions (TAF)
Prévisions d’aérodrome (TAF)
Autres prévisions de surface
Observations provenant de bouées
Glaces de mer
Profils provenant de flotteurs profonds
BUOY
001/025
TESAC
031/004
RADOF
MAFOR
HYFOR
édition 2009
II-5/20
Tableau C7 (suite)
T1T2 A1
ii
Type de données
Correspondance
avec les codes
alphanumériques
traditionnels
KO
KO
KO
KO
KO
R
S
T
W
X
Observations à la surface de la mer
TRACKOB
Sondages à la surface et sous la surface de la mer BATHY, TESAC
WAVEOB
KP
KP
KP
KP
KP
I
S
T
W
X
Glaces de mer
KS
KS
KS
KS
KS
KS
KS
KS
KS
KS
KS
KS
KS
KS
KS
KS
KS
KS
KS
KS
KS
A 01-29
A 30-59
B C 01-45
C 46-59
D E F I 01-45
I 46-59
M 01-45
M 46-59
N 01-45
N 46-59
R S 01-19
S 20-39
S 40-59
V W X Observations régulières provenant de stations
automatiques terrestres (fixes ou mobiles)
(par ex. 0000, 0100, … ou 0220, 0240, 0300, … ou 0715, 0745, ... UTC)
Observations sur n minutes provenant de stations automatiques terrestres (fixes ou mobiles)
Messages d’observation par radar (parties A et B)
Observations climatologiques provenant de stations terrestres
Observations climatologiques provenant de stations maritimes
Observations radiologiques
Mesure de l’ozone en surface
Source d’atmosphériques
Observations de stations terrestres fixes faites
aux heures synoptiques intermédiaires
Observations de stations terrestres mobiles faites aux heures synoptiques intermédiaires
Observations de stations terrestres fixes faites
aux heures synoptiques principales
Observations de stations terrestres mobiles faites aux heures synoptiques principales
Observations synoptiques de stations terrestres fixes faites à des moments autres que les heures standard (par ex. 0100, 0200, 0400, 0500, ... UTC)
Observations synoptiques de stations terrestres
mobiles faites à des moments autres que les
heures standard (par ex. 0100, 0200, 0400, 0500, 0700, 0800, 1000, 1100, 1300, ... UTC)
Messages d’observation hydrologique
Observations synoptiques de stations maritimes
Observations sur une heure provenant de stations maritimes automatiques
Observations sur n minutes provenant de
Observations aéronautiques spéciales (SPECI)
Observations aéronautiques régulières (METAR)
Autres données d’observation en surface
KT
KT
E H Tsunamis
Avis d’ouragans, de typhons, de tempêtes tropicales
édition 2009
(Table de code
commune C-13)
031/001
031/005
031/002
n.d.
000/006
n.d.
000/007
RADOB
006/003
CLIMAT
CLIMAT SHIP
000/020
001/020
RADREP
n.d.
SFAZI, SFLOC, SFAZU
SYNOP (SIxx)
SYNOP MOBIL
010/001
008/000
000/030
000/001
000/051
000/004
SYNOP (SMxx)
SYNOP MOBIL
000/002
000/052
000/005
SYNOP (SNxx)
000/000
000/050
SYNOP MOBIL
000/003
HYDRA
SHIP
n.d.
000/040
001/000
001/006
n.d.
001/007
SPECI
METAR
IAC, IAC FLEET
000/011
000/010
II-5/21
SUPPLéMENT ii-5
Tableau C7 (suite)
T1T2 A1
ii
Type de données
KT
KT
KT
S
T
X
KU
KU
KU
KU
KU
KU
KU
KU
KU
KU
KU
KU
KU
KU
KU
KU
KU
KU
KU
KU
KU
KU
KU
KU
KU
KU
KU
KU
A A B C D I J 01-19
J 20-39
J 40-59
K 01-19
K 20-39
K 40-59
L M N O P Q S 01-19
S 20-39
S 40-59
T U 01-45
U 46-59
W 01-19
W 20-39
W 40-59
X Correspondance
avec les codes
alphanumériques
traditionnels
(Table de code
commune C-13)
Phénomènes météorologiques violents, SIGMET
Avis de tornades
Autres avis
Comptes rendus d’aéronef pour un seul niveau (automatiques)
Comptes rendus d’aéronef pour un seul niveau (manuels)
Messages d’observation par ballon pour un seul niveau
Messages d’observation dérivés de données satellitaires pour un seul niveau
Données obtenues par sonde parachutée
Dispersion et transport
Messages d’observation du vent en altitude provenant de stations terrestres fixes Messages d’observation du vent en altitude
provenant de stations terrestres mobiles Messages d’observation du vent en altitude
provenant de stations maritimes Messages d’observation de radiosondes provenant de stations terrestres fixes Messages d’observation de radiosondes provenant de stations terrestres mobiles Messages d’observation de radiosondes provenant de stations maritimes Profils verticaux de l’ozone
Sondages dérivés de modèles
Données obtenues par fusées-sondes
Profils d’observations d’aéronef en montée/
descente
Profils
Profils de la température provenant de systèmes de sondage radio-acoustique
Messages d’observation de radiosondes/
ballons-pilotes provenant de stations terrestres
fixes
Messages d’observation de radiosondes provenant de stations terrestres mobiles Messages d’observation de radiosondes provenant de stations maritimes Sondages dérivés de données satellitaires
Statistiques mensuelles provenant de stations
d’observation en altitude
Statistiques mensuelles provenant de stations
maritimes
Messages d’observation du vent en altitude provenant de stations terrestres fixes Messages d’observation du vent en altitude
provenant de stations terrestres mobiles Messages d’observation du vent en altitude provenant de stations maritimes Autres messages d’observation en altitude
AMDAR
004/000
AIREP/PIREP
004/001
n.d.
SAREP
005/000
TEMP DROP
n.d.
PILOT
PILOT MOBIL
PILOT SHIP
TEMP
(parties A et B)
TEMP MOBIL
(parties A et B)
TEMP SHIP
(parties A et B)
n.d.
002/007
009/000
002/001
002/003
002/002
002/004
002/006
002/005
008/001
AMDAR
002/020
PILOT
TEMP
002/010
002/011
TEMP
002/004
TEMP MOBIL
TEMP SHIP
002/006
CLIMAT TEMP
002/025
CLIMAT TEMP, SHIP
002/026
PILOT
(parties A et B)
PILOT MOBIL
(parties A et B)
PILOT SHIP
(parties A et B)
002/001
002/005
002/003
002/002
édition 2009
II-5/22
Tableau C7 (suite)
T1T2 A1
ii
Type de données
KV
KV
KV
KV
KV
KV
KV
KV
KV
KV
KV
A
B
C
F
N
O
S
T
V
W
X
Correspondance
avec les codes
alphanumériques
traditionnels
(Table de code
commune C-13)
Prévisions pour un seul niveau
Messages TEMSI codés, Cumulonimbus noyés
Messages TEMSI codés CREX, Turbulences en air clair
Messages TEMSI codés CREX, Fronts
Messages TEMSI codés CREX, Autres paramètres du temps significatif
Messages TEMSI codés CREX, Turbulences
Sondages prévus
Messages TEMSI codés CREX, Givrage/Tropopause
Messages TEMSI codés CREX, Tempêtes tropicales, tempêtes de sable, volcans
Messages TEMSI codés CREX, Vents à haute altitude
Autres prévisions en altitude
Note: T1T2 = SZ est affecté aux données sur le niveau de la mer et sur les tsunamis à grande profondeur sous
n’importe quelle forme alphanumérique, y compris le code CREX.
Tableau D1
Indicateur de niveau ii (lorsque T1 = O)
Instructions à suivre pour utiliser correctement les indicateurs de niveau pour les profondeurs océaniques
Les indicateurs de ce tableau devraient être utilisés dans toute la mesure du possible pour
préciser le niveau au-dessous de la surface de la mer dans le corps du bulletin GRIB pour les produits
océanographiques.
Indicateur
98
96
94
92
90
88
86
84
82
80
78
76
74
72
70
68
66
64
62
60
édition 2009
Niveau (en mètres)
Surface
2,5
5,0
7,5
12,5
17,5
25,0
32,5
40,0
50,0
62,5
75,0
100
125
150
200
300
400
500
600
II-5/23
SUPPLéMENT ii-5
Tableau D1 (suite)
Indicateur
58
56
54
52
50
48
46
44
42
40
38
36
34
32
30
01
Niveau (en mètres)
700
800
900
1 000
1 100
1 200
1 300
1 400
1 500
1 750
2 000
2 500
3 000
4 000
5 000
Couche primaire
Tableau D2
Indicateur de niveau ii (lorsque T1 = D, G, H, J, P, Q, X ou Y)
Instructions à suivre pour utiliser correctement les indicateurs de niveau
1.
Les indicateurs de ce tableau devraient être utilisés dans toute la mesure du possible pour
préciser le niveau auquel correspondent les données contenues dans le corps du bulletin.
2.
Lorsque plusieurs niveaux sont en cause, un seul indicateur, correspondant à l’un d’entre eux,
devra être utilisé.
3.
S’il n’existe pas d’indicateur approprié pour le niveau auquel correspondent les données, il
faudrait utiliser l’un des indicateurs non attribués du tableau.
Indicateur
99
98
97
96
95
94
93
92
91
90
89
88
87
86
85
84
83
82
81
80
79
78
77
76
Niveau
1 000 hPa
Propriétés de l’air à la surface de la Terre
Niveau de la tropopause
Niveau du vent maximal
950 hPa
Niveau de l’isotherme de 0 °C
975 hPa
925 hPa
875 hPa
900 hPa
Tout paramètre ramené au niveau de la mer
(par exemple MSLP)
Propriétés du sol ou de l’eau à la surface
(par exemple couverture neigeuse, vague et houle)
1 000–500 hPa épaisseur
Couche limite
850 hPa
840 hPa
830 hPa
825 hPa
810 hPa
800 hPa
790 hPa
780 hPa
775 hPa
760 hPa
Indicateur
75
74
73
72
71
70
69
68
67
66
65
64
63
62
61
60
59
58
57
56
55
54
53
52
51
50
Niveau
750 hPa
740 hPa
730 hPa
725 hPa
710 hPa
700 hPa
690 hPa
680 hPa
675 hPa
660 hPa
650 hPa
640 hPa
630 hPa
625 hPa
610 hPa
600 hPa
590 hPa
580 hPa
570 hPa
560 hPa
550 hPa
540 hPa
530 hPa
520 hPa
510 hPa
500 hPa
édition 2009
II-5/24
Tableau D2 (suite)
Indicateur
49
48
47
46
45
44
43
42
41
40
39
38
37
36
35
34
33
32
31
30
29
28
27
26
25
24
23
Niveau
490 hPa
480 hPa
470 hPa
460 hPa
450 hPa
440 hPa
430 hPa
420 hPa
410 hPa
400 hPa
390 hPa
380 hPa
370 hPa
360 hPa
350 hPa
340 hPa
330 hPa
320 hPa
310 hPa
300 hPa
290 hPa
280 hPa
270 hPa
260 hPa
250 hPa
240 hPa
230 hPa
Indicateur
22
21
20
19
18
17
16
15
14
13
12
11
10
09
08
07
06
05
04
03
02
01
00
Niveau
220 hPa
210 hPa
200 hPa
190 hPa
180 hPa
170 hPa
160 hPa
150 hPa
140 hPa
130 hPa
120 hPa
110 hPa
100 hPa
090 hPa
080 hPa
070 hPa
060 hPa
050 hPa
040 hPa
030 hPa
020 hPa
010 hPa
Ensemble de
l’atmosphère
(par exemple, eau
précipitable)
Tableau D3
Indicateur de niveau ii (lorsque T1T2 = FA ou UA)
T1T2
FA
FA
FA
UA
UA
UA
UA
Indicateur ii
01-49
50-59
60-99
01-59
60-69
70-79
80-99
Type de données
Zone pour l’aviation/bulletins
GAMET
Non attribué
Messages courants d’aéronefs
Messages spéciaux d’aéronefs, sauf en cas de cendres volcaniques
Messages spéciaux d’aéronefs en cas de cendres volcaniques
Messages courants d’aéronefs (voir note)
FM 53 (ARFOR) [texte]
[TEXTE]
AIREP OACI
AIREP OACI
AIREP OACI
AIREP OACI
Note: Notant qu’il n’existe pas d’usage connu de la série 80-99, celle-ci est attribuée aux messages courants
d’aéronefs jusqu’au 1er septembre 2008. Après cette date, la série devrait être réservée à un futur usage.
édition 2009
SUPPLéMENT II-6
FORME DE PRÉSENTATION DU TEXTE DES MESSAGES ADRESSÉS ET
EXEMPLE GÉNÉRAL DE CHAQUE TYPE
Forme de présentation générale
(Les exemples ne sont donnés qu’en Alphabet N° 5)
La forme de présentation de l’en-tête abrégé des messages adressés se compose de deux lignes
d’information.
La forme de présentation de l’en-tête abrégé est la suivante:
T1T2 A1A2 ii CaCaCaCa YYGGgg CCCC
où,
T1T2
A1A2
=
=
ii
CaCaCaCa
YYGGgg
CCCC
=
=
=
=
BM, indicateur de message adressé sous forme alphanumérique
BI, indicateur de message adressé sous forme binaire (utilisé sur les liaisons binaires uniquement)
Type de message adressé
Valeurs:
AA – Message administratif (à adresser à une personne pour information ou action)
BB – Message de service (à adresser à une personne pour action)
RR – Message de demande de bulletin disponible sur le SMT par en-tête ou numéro de
transmission
RQ– Demande d’interrogation d’une base de données (forme de présentation de demande
TBD) en vue d’un traitement par le SMTDP
DA– Message de données utilisées pour répondre à un message adressé RR ou RQ
Toujours 01 (aucune exception admise)
Indicateur d’emplacement du centre du SMT auquel le message est adressé
Heure d’insertion sur le SMT
Indicateur international d’emplacement du centre d’origine
TYPE 1
A1A2
= AA – Message administratif
Le contenu de ce type de message est un texte alphanumérique en clair, destiné à être lu. Il doit donc être
affiché ou imprimé. Il concerne des questions générales d’exploitation et/ou administratives, des échanges
de vues ou des questions de coordination des opérations sur le SMT. T1T2 ne peut prendre que la valeur BM,
car le texte se présente sous forme alphanumérique.
Exemple:
345
BMAA01 EDZW 261215
EGRR
ATTN OFFENBACH DATA MANAGER
THE BULLETINS YOU REQUESTED WILL BE RELAY TO YOUR CENTER
BEGINNING THE FIRST OF THE MONTH
SMVG01 TVSV
SMTD01 TTPP
REGARDS, BMO DATA MANAGER SUPERVISOR=
Note: EDZW est le centre auquel le message est adressé; EGRR est le centre d’origine.
TYPE 2
A1A2
= BB – Message de service
Le contenu de ce type de message est un texte alphanumérique en clair, destiné à être lu. Il doit donc
être affiché ou imprimé. Il concerne des informations d’exploitation et/ou des questions relatives au
règlement de problèmes. T1T2 ne peut prendre que la valeur BM, puisque le texte est présenté sous forme
alphanumérique.
édition 2009
II-6/2
Exemple:
321
BMBB01 EGRR 281425
KWBC
ATTN EXETER COMMUNICATIONS SUPERVISOR
THE GTS LINK BETWEEN WASHINGTON AND BRASILIA IS DOWN FOR
6 HOURS DUE TO LINE RECONFIGURATION AT BRASILIA
REGARDS, WASHINGTON COMMS SUPERVISOR=
Note: EGRR est le centre auquel le message est adressé; KWBC est le centre d’origine.
TYPE 3
A1A2
= RR – Message d’interrogation/réponse
Pour ce type de message, on distingue deux classes pour chacune desquelles existent deux formes de
présentation différentes. Ce type de message adressé est utilisé pour la communication entre centres du
SMT. Pour l’utilisation de la forme de présentation de demandes de la CLASSE 1, les centres du SMT doivent
être adjacents. Pour l’utilisation de la forme de présentation de demandes de la CLASSE 2, les centres du
SMT n’ont pas besoin d’être adjacents. Le message de type interrogation/réponse sert à l’acquisition de
données au niveau bulletin, étant entendu que le bulletin existe déjà. S’il est envoyé sur une voie virtuelle
X.25 établie pour l’échange de données alphanumériques, la valeur BM est recommandée pour T1T2; si la
voie virtuelle X.25 a été établie pour l’échange de données binaires, c’est alors BI qui est recommandée
pour T1T2. S’il n’y a qu’une voie virtuelle entre centres pour l’échange de données tant alphanumériques
que binaires, la valeur BI est recommandée pour T1T2, par défaut. On utilise la valeur BM de T1T2 sur toutes
les liaisons SMT faisant appel à des protocoles de transmission de données alphanumériques (c’est-à-dire
BAUDOT ou PROCÉDURES DE CONTRÔLE D’ERREUR), car tous les messages adressés et les réponses sont
alphanumériques.
CLASSE 1. Demande de répétition — entre centres adjacents uniquement. Pour le texte de la
demande, trois possibilités:
1. Demande d’un seul message caractérisé par son numéro de transmission;
2. Demande d’une série de numéros de transmission consécutifs;
3. Demande d’un groupe de messages particuliers caractérisés par leurs numéros de transmission.
Une ligne de demande seulement par message.
La réponse au message d’interrogation/réponse de la Classe 1 comprend deux parties. La
première concerne la construction et la transmission d’un message d’état présenté sous la forme d’un
message de données de TYPE 5, qui indique que suite a été donnée à la demande adressée. La seconde
concerne la transmission du (des) message(s) demandé(s). II s’agit d’une répétition du (des) message(s)
envoyé(s) initialement, y compris de son (ses) numéro(s) de transmission initial (initiaux). La transmission
qui en résultera ne respectera probablement pas l’ordre initial des numéros de transmission. Le centre
interrogateur saura ainsi qu’il a reçu le (les) message(s) demandé(s).
Possibilité 1 — Demande d’un seul message (déjà transmis)
1. Forme de présentation pour une voie virtuelle alphanumérique ou pour toute liaison SMT non
binaire.
(SOH)(CR)(CR)(LF) nnn
(CR)(CR)(LF) BMRR01 CaCaCaCa YYGGgg
(CR)(CR)(LF) CCCC
(CR)(CR)(LF) SQN nnn =
[un seul bulletin]
(CR)(CR)(LF)(ETX)
2. Forme de présentation pour une voie virtuelle de transmission de données binaires sur le SMT en
X.25.
(CR)(CR)(LF) BIRR01 CaCaCaCa YYGGgg
(CR)(CR)(LF) CCCC
(CR)(CR)(LF) SQN nnn =
[un seul bulletin]
(CR)(CR)(LF)(ETX)
édition 2009
SUPPLéMENT ii-6
II-6/3
Possibilité 2 — Demande d’une série continue de messages (déjà transmis)
1.
Forme de présentation pour une voie virtuelle alphanumérique ou pour toute liaison non binaire.
(CR)(CR)(LF) CCCC
(CR)(CR)(LF) SQN nnn-nnn =
[série de bulletins consécutifs]
(CR)(CR)(LF)(ETX)
2.
Forme de présentation pour une voie virtuelle de transmission de données binaire sur le SMT en X.25.
(CR)(CR)(LF) CCCC
(CR)(CR)(LF) SQN nnn-nnn =
[série de bulletins consécutifs]
(CR)(CR)(LF)(ETX)
Possibilité 3 — Demande de messages particuliers (déjà transmis)
1.
Forme de présentation pour une voie virtuelle alphanumérique ou pour toute liaison non binaire.
(CR)(CR)(LF) CCCC
(CR)(CR)(LF) SQN nnn/nnn/nnn =
[nombre sélectionné de bulletins]
(CR)(CR)(LF)(ETX)
2. Forme de présentation pour une voie virtuelle de transmission de données binaires sur le SMT en
X.25.
(CR)(CR)(LF) CCCC
(CR)(CR)(LF) SQN nnn/nnn/nnn =
[nombre sélectionné de bulletins]
(CR)(CR)(LF)(ETX)
Note: Restriction: une seule ligne de type SQN par demande.
Exemple — CLASSE 1
788
BMRR01 LFPW 301215
DAMM
SQN 212-217=
où LFPW est le centre auquel le message est adressé, et DAMM le centre d’origine.
CLASSE 2. Demande de bulletin — peut être envoyée à tout centre du SMT. Une seule
possibilité en ce qui concerne la forme de présentation du texte de la demande. Cette forme est toujours
alphanumérique; toutefois, pour T1T2, on utilise la valeur BM pour toutes les demandes de messages
alphanumériques, et BI pour toutes les demandes de messages binaires, car la même valeur de T1T2 sera
utilisée dans toutes les réponses pour l’en-tête abrégé, afin de faciliter l’acheminement lorsque des liaisons
X.25 ou équivalentes sont requises.
Forme de présentation de la demande:
Demandes de messages (demande de messages alphanumériques)
(CR)(CR)(LF) CCCC
(CR)(CR)(LF) AHD T1T2A1A2ii CCCC YYGGgg =
(CR)(CR)(LF) AHD T1T2A1A2ii CCCC YYGGgg BBB =
(CR)(CR)(LF)(ETX)
Notes: 1. Restriction: pas plus de 8 en-têtes abrégés dans un message de demande destiné à un centre situé audelà des centre directement reliés.
édition 2009
II-6/4
2. Lorsque le groupe date-heure YYGGgg ou le groupe heure GGgg n’est pas déterminé, ces demandes
peuvent être formulées comme suit:
AHD T1T2A1A2ii CCCCYY//// (BB/) (où BB=RR, CC ou AA)
AHD T1T2A1A2ii CCCCYY//// (P//)
AHD T1T2A1A2ii CCCC //////
où YY//// correspond au message le plus récent pour la journée YY
////// correspond au message le plus récent dans les dernières 24 heures.
Exemples — CLASSE 2
• Message utilisé pour une voie virtuelle X.25 non binaire
051
BMRR01 AMMC 081220
KWBC
AHD SNAU55 AMMC 081100 RRA=
AHD SMID20 WIIX 081200=
où AMMC est le centre auquel le message est adressé, et KWBC le centre d’origine.
• Message utilisé uniquement pour une voie virtuelle X.25 binaire
110
BIRR01 KWBC 081220
AMMC
AHD HTAC30 KWBC 081200=
AHD HHBC85 KWBC 081200=
où KWBC est le centre auquel le message est adressé, et AMMC le centre d’origine.
TYPE 4
A1A2
= RQ – Message d’interrogation d’une base de données
Pour ce type de message, la forme de présentation est particulière. Il est prévu un traitement automatisé. Il
n’y a qu’un type de message d’interrogation d’une base de données (utilisé par le SMTDP).
Forme de présentation de la demande:
(CR)(CR)(LF) BIRQ01 CaCaCaCa YYGGgg
(CR)(CR)(LF) CCCC
(CR)(CR)(LF) [TBD]
(CR)(CR)(LF)(ETX)
[à définir]
TYPE 5
A1A2
= DA – Message de données
Il s’agit du type de message transmis en réponse à une demande. L’en-tête en question est destiné à faire en
sorte que, si le message de données demandé est un bulletin contenant un en-tête OMM abrégé, cet en-tête
abrégé n’est pas utilisé pour l’acheminement de la réponse au centre demandeur. Pour que l’acheminement
se fasse correctement, la valeur BM ou BI de T1T2 doit rendre compte du type de forme de présentation du
message de données. Ce message peut prendre quatre formes différentes:
1.
2.
3.
4.
Message demandé;
Indication que le message n’a pas été trouvé;
Indication que l’en-tête du message n’est pas reconnu; ou
Message d’état, concernant la suite donnée à une demande RR de la Classe 1.
Un message de données transmis en réponse à une demande ne contient qu’un bulletin ou un
fichier de métadonnées. Dans les exemples ci-après, le message de données peut prendre la valeur BM ou BI
pour la Classe 1, selon le type de voie virtuelle. Si les messages alphanumériques et les messages binaires
sont transmis sur une seul voie virtuelle, BI est utilisé par défaut.
édition 2009
SUPPLéMENT ii-6
II-6/5
Exemple de message demandé:
543
BMDA01 KWBC 081550
AMMC
SIID20 WIIX 081500
AAXX 08151
58424 42975 02203 10297 20251 40037 52008=
Exemple de message qui n’a pas été trouvé (réponse NIL):
189
BMDA01 KWBC 081250
AMMC
NIL SNAU55 AMMC 081100 RRB=
Exemple de message non reconnu (réponse ERR):
154
BMDA01 KWBC 081250
AMMC
ERR SIID20 WIIX 081200=
Exemple de message transmis en réponse à une demande de type RR de la Classe 1 (réponse STATUS):
264
BMDA01 RJTD 101255
KWBC
RETRANSMISSION ACTIVATED FOR 212-218=
où RJTD est le centre auquel le message est adressé, et KWBC le centre d’origine adjacent.
Note: Limitation — Les circuits ou les voies virtuelles dotés d’une gestion des priorités permettent d’éviter toute
erreur dans la sélection des messages par leur numéro de transmission, pour la réponse.
Où:
(CR) = Retour du chariot
(LF) = Interligne
(SOH)= Début d’en-tête
(ETX) = Fin de texte
édition 2009
SUPPLéMENT II-7
CATALOGUES D’ACHEMINEMENT
1.
FORME DE PRÉSENTATION D’UN CATALOGUE D’ACHEMINEMENT
1.1
Le catalogue d’acheminement devrait être produit sous forme de fichier ASCII qui puisse être
importé dans des applications de bases de données. L’information devrait donc être présentée dans une
structure de base de données. La structure ci-dessous permet un affichage facile sur un écran, en utilisant
par exemple une commande “visualiser”.
1.2
Le fichier contenant le catalogue d’acheminement d’un centre du SMT devrait être nommé
CCCCROCA.TXT, où CCCC désigne l’indicateur d’emplacement du centre. La date de préparation du
catalogue devrait être indiquée sur la première ligne sous la forme YYYYMMDD (où YYYY désigne l’année,
MM le mois et DD le jour).
1.3
Pour chaque en-tête abrégé, un enregistrement devrait comprendre les zones suivantes:
N° de zone
Contenu
Largeur
1
En-tête abrégé TTAAii CCCC
2
Circuit du SMT d’où le bulletin est reçu (voir le paragraphe 1.4)
4
3
Circuit du SMT où le bulletin est envoyé (voir le paragraphe 1.4)
4
11
Ajouter autant de zones supplémentaires sous la forme de la zone N° 3 que de circuits supplémentaires auxquels le bulletin est envoyé.
1.4
La combinaison suivante de quatre caractères devrait être employée pour désigner les circuits
du SMT et introduite dans les zones N° 2, 3 et suivantes:
a) Lorsque le circuit du SMT est un circuit point à point unique reliant le centre du SMT à un centre
adjacent, l’indicateur d’emplacement CCCC du centre adjacent approprié du SMT devrait être
employé;
b) Dans les autres cas, par exemple lorsque le circuit est un circuit point-multipoint (par exemple, dans
un système de distribution par satellite), une combinaison CCCC spécifique devrait être employée,
par exemple une combinaison de lettres et de chiffres pour les différencier des indicateurs d’emplacement CCCC habituels. La description des circuits du SMT concernés peut être donnée dans le fichier
CCCCRMKS.TXT (voir le paragraphe 2).
Dans la combinaison de caractères CCCC, des caractères génériques (jokers) “*”ne devraient
être employés que si le centre du SMT ne peut fournir d’informations complètes. L’utilisation de caractères
génériques n’est pas conseillée, car elle limite l’information.
1.5
Les zones doivent être entourées de guillemets et séparées par des virgules.
échantillon de structure:
“SMAA01 EGRR”,“RJTD”,“ANOU”,“DEMS”,“NFFN”,“NTAA”,“NZKL”,“PMBY”
“SMAA01 EGRR”,“KWBC”,“NZKL”
“SMAA10 KWBC”,“EGRR”,“DEMS”,“NFFN”,“NTAA”,“NZKL”,“WIIX”
2.
INFORMATIONS SUPPLÉMENTAIRES
Toute information supplémentaire, telle que la date de création du répertoire, les détails sur
d’autres CCCC inclus dans le catalogue d’acheminement, les moyens et les procédures permettant d’accéder
à ce catalogue (par exemple, serveur FTP) et toute autre information qui peut venir en aide à l’utilisateur
devraient figurer dans un fichier appelé CCCCRMKS.TXT, où CCCC désigne l’indicateur d’emplacement du
centre.
édition 2009
II-7/2
3.
ACCÈS AUX CATALOGUES D’ACHEMINEMENT DES CRT
3.1
Chaque CRT devrait présenter son propre catalogue d’acheminement sur le serveur FTP qu’il
exploite. Les fichiers de chaque centre devraient se trouver dans des sous-répertoires GTS_routeing/CCCC
de tous les serveurs. Si un CRT n’a pas la possibilité de présenter son catalogue d’acheminement sur un
serveur local, il devrait transmettre ce catalogue sous le nom CCCCROCA.TXT sur le serveur FTP de l’OMM
dans le sous-répertoire GTS_routeing/CCCC, de préférence par accès direct à ce serveur ou en envoyant des
disquettes au Secrétariat.
3.2
Les CRT devraient transmettre leurs fichiers CCCCRMKS.TXT sur le serveur FTP de l’OMM
(www.wmo.int) dans les sous-répertoires GTS_routeing/CCCC, où CCCC désigne l’indicateur d’emplacement
du CRT. Chaque sous-répertoire GTS_routeing/CCCC est réservé à chaque CRT, qui peut transmettre et
mettre à jour les données selon les besoins. Chaque CRT devrait transmettre son fichier CCCCRMKS.TXT
sur le serveur FTP de l’OMM, de préférence par accès direct à ce serveur ou en envoyant des disquettes
au Secrétariat. En accédant aux informations que contiennent les fichiers CCCCRMKS.TXT se trouvant
sur le serveur FTP de l’OMM, les centres du SMT devraient trouver des informations sur les moyens et les
procédures permettant d’accéder aux répertoires d’acheminement de tous les CRT.
3.3
Le CRT d’Offenbach exploite sur son propre serveur FTP un site reflétant la partie du serveur
FTP de l’OMM relative aux catalogues d’acheminement.
édition 2009
supplément II-8
MIRE FAC-SIMILÉ DE L’OMM
1.
La mire est délimitée par un cadre noir de 1,5 mm de large dont les dimensions extérieures sont de:
longueur 449 mm;
largeur 153 mm.
Le cadre est entouré d’une marge blanche de 15 mm. La mire est divisée en cantons repérés sur le calque
accompagnant les mires.
2.
Canton
1(1):
Échantillon de carte météorologique.
3.
Cantons
2(2):
Traits noirs et blancs pour évaluer la définition de la transmission, selon
différentes périodicités:
2 mm
1 mm
0,5 mm
0,33 mm
0,5 ligne au mm 1 ligne au mm 2 lignes au mm 3 lignes au mm
0,25 mm
4 lignes au mm
0,20 mm
5 lignes au mm
4.
Cantons
3(2):
Sigle “OMM”.
5.
Canton
4(1):
Numéro d’identification de la mire.
6.
Cantons
5(4):
Échelles de nuances comprenant huit échelons de densité progressivement
variable, selon une échelle physiologique, entre le noir et le blanc.
7.
Cantons
6(4):
Traits noirs et blancs pour évaluer la définition de la transmission
progressivement de 2 mm à 0,20 mm (de 0,5 ligne au mm à 5 lignes au
mm).
8.
Cantons
7(2):
Coin blanc sur fond noir avec une ouverture de 2 mm.
9.
Cantons
8(2):
Traits blancs sur fond noir (épaisseur: 2 – 1 – 0,5 – 0,33 – 0,25 – 0,20 mm).
10.
Cantons
9(2):
Traits noirs de différentes épaisseurs (de 0,20 mm à 2 mm) sur fond blanc
pour évaluer la qualité de la reproduction des lignes distinctes.
11.
Cantons
10(2):
Cercle noir de 39,5 mm de diamètre extérieur et de 0,5 mm d’épaisseur et
un carré inscrit avec ses diagonales.
12.
Canton
11(1):
Signes typographiques de 2 – 3 – 4 – 5 mm.
Notes:
1. La constante de précision est égale à ± 0,015 mm (15/1000 de millimètre) tant en ce qui concerne l’épaisseur
des traits de mire rectilignes ou radiaux que la longueur de l’élément périodique considéré.
2. La position des cadres entourant chaque élément est assurée avec une précision de ± 0,15 mm (15/100 de mm).
3. Compte tenu des variations dues aux écarts de température (entre 5 et 30 °C) et d’hygrométrie (de 25 à
85 %), la précision de ± 0,2/1000 est assurée sur les longueurs de 449 mm et 153 mm; la régularité sur toutes
les longueurs intermédiaires reste homogène et dans la limite de la tolérance ci-dessus, les mesures étant faites
à plat.
*
* *
édition 2009
II-8/2
Édition 2009
SUPPLéMENT II-9
TRANSMISSION D’INFORMATIONS GRAPHIQUES EN FAC-SIMILÉ
NUMÉRIQUE CODÉ ET NON CODÉ
I. Procédures de transmission en fac-similé numérique codé ou non codé entre
centres sur une voie équipée pour les procédures X.25
1.
La structure du message contenant un produit sous forme binaire, transmis sur des liaisons
conformes aux dispositions de la recommandation UIT-T X.25, devrait être la suivante:
Début
Identification
Indicateur de
données
Produit fac-similé
Fin
Ce message devrait être transmis selon les procédures conformes à la recommandation UIT-T
X.25, figurant dans la section 2.12 de la partie II.
2.
La ligne préliminaire définie dans la partie II, paragraphe 2.3.1.1 b), devrait constituer le début de
l’enveloppe de transmission; le signal de fin de message devrait être constitué des caractères C C L E
T
définis au paragraphe 2.3.4 b) de la partie II.
R R
F
X
S
O
H
C
R
C
R
L
F
nnn
(identification + indicateur de données + produit)
C
R
C
R
L
F
(- - - - - - - - - - - début - - - - - - - - - - -)
E
T
X
(fin)
(- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - enveloppe OMM - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -)
où
nnn est le numéro de transmission du message.
3.
La structure de l’en-tête abrégé définie dans la partie II, paragraphe 2.3.2.1 b), devrait être
utilisée pour l’identification du produit, à savoir:
où
C
R
C
R
L
F
T1T2A1A2ii
S
P
CCCC
S
P
YYGGgg
(
S
P
)
BBB
T1 = P — Information graphique sous forme numérique.
4.
Le supplément II-5 devrait être utilisé pour décrire les produits transmis en fac-similé. Le
tableau B2 définit T2, tandis que les tableaux C3 et C4 définissent entièrement A1 et A2. Le tableau D décrit
les indicateurs de niveau ii.
5.
La suite de données binaires représentant le produit en fac-similé numérique devrait être
précédée par les groupes d’indicateurs de données chiffrés selon l’Alphabet international N° 5:
C
R
C
R
L
F
DFAX
S1S2S3S4
où
DFAX
indique des données graphiques en fac-similé numérique codé ou non codé;
S1S2S3S4
sont chiffrés conformément au tableau A ci-après pour décrire les caractéristiques
du produit transmis.
6.
Exemple d’identification et de description d’un produit:
S
P
C
R
C
R
L
F
PEDA 98
C
R
C
R
L
F
DFAX 0122 - - - - - - - - - - - données binaires - - - - - - - - - - -
KWBC
S
P
011200
Édition 2009
II-9/2
où
P
E
D
A
98
KWBC
011200
DFAX
0
1
2
2
indique l’information graphique sous forme numérique;
indique les précipitations;
indique l’hémisphère Nord de 90°W à 0°;
indique une analyse (00 heure);
indique la surface de la Terre ou de l’océan;
indique le CMN de Washington;
indique le jour un et l’heure 1200 UTC;
indique “fac-similé numérique codé ou non codé”;
indique “fac-similé numérique non codé”;
indique que les signaux de télécommande (pour le module de coopération, la mise en phase, etc.) sont inclus;
indique une fréquence d’exploration de 120 tours/minute;
indique une résolution verticale de 3,85 lignes par millimètre (pour le module de
coopération).
Par conséquent, le produit se présenterait de la manière suivante:
S
O
H
C
R
C
R
L
F
C
R
C
R
L
F
PEDA 98
C
R
C
R
L
F
DFAX 0122 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
001
S
P
KWBC
S
P
011200
bbbbbbbbbbbbbbbbbbbbbbbbbbb/
/bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
C
R
où
b représente des données binaires.
La longueur du message est variable; elle dépend du produit et de la densité des données.
C
R
L
F
E
T
X
Note: L’enveloppe est utilisée pour reconnaître, mettre en mémoire et rechercher les données. Le nombre d’octets
n’est limité que par le CMN qui transmet ou reçoit le fichier (produit). à l’heure actuelle, la longueur d’une
carte transmise en fac-similé numérique non codé est inférieure à 684 000 octets. Les CMN devraient
s’assurer que des produits de cette longueur passent bien dans leurs systèmes. Si l’on envoyait des produits
en fac-similé numérique sous forme codée, la dimension du fichier serait considérablement réduite, ce qui
permettrait aux centres dont la possibilité de traitement de fichiers est actuellement limitée de mettre en
œuvre plus facilement la nouvelle procédure de commutation des produits fac-similé.
Tableau A — Indicateurs de données S1S2S3S4 pour l’identification des
caractéristiques des informations graphiques en fac-similé numérique
S 1
S 2
S 3
Fac-similé numérique non codé:
0
Pas de signaux de télécommande inclus:
0
Fac-similé numérique codé, conforme aux dispositions de la
rec. UIT-T T.4 – codage
unidimensionnel:
1
Signaux de
télécommande
inclus:
Fac-similé numérique codé, conforme aux dispositions de la
rec. UIT-T T.4 – codage bidimensionnel:
2
S4
Fréquence d’exploration:
60 tr/min:
90 tr/min:
120 tr/min:
1 240 tr/min: ou
Résolution verticale:
0
1
2
3
1,89 ligne/mm: 0
3,79 lignes/mm: 1
3,85 lignes/mm: 2
7,58 lignes/mm: 3
7,7 lignes/mm: 4
Résolution horizontale:
1728 éléments d’image
par ligne:
3456 éléments d’image
par ligne: 6
7
Note: Les procédures applicables à la transmission en fac-similé numérique codé, conformément aux normes du
groupe 4 de l’UIT-T, devront faire l’objet d’un complément d’étude.
Édition 2009
II-9/3
SUPPLéMENT ii-9
II. Procédure de transmission en fac-similé numérique entre centres lorsque des
voies distinctes sont utilisées respectivement pour la transmission des indicateurs
alphanumériques et des informations en fac-similé numérique
1.
La procédure de transmission en fac-similé numérique codé ou non codé est prévue pour
les transmissions en fac-similé sur des voies multiplexées par des modems conformes à la recommandation UIT-T V.29. Elle peut être appliquée aussi bien par des centres automatisés (pour la transmission en
fac-similé) que par des centres non automatisés. La procédure est fondée sur la transmission de messages
adressés d’identification sur la voie alphanumérique et de produits en fac-similé sur l’autre voie.
2.
DESCRIPTION DE LA PROCÉDURE
2.1
En mode multiplex, l’information alphanumérique et le produit en fac-similé sont transmis
séparément sur différentes voies du multiplexeur.
2.2
La voie B est utilisée pour la transmission de l’information alphanumérique et la voie A pour
la transmission du produit en fac-similé.
2.3
Pour la transmission de données sur la voie B, il est possible d’utiliser n’importe laquelle des
procédures de protection contre les erreurs recommandées par l’OMM (système câblé ou programmé, LAPB/
X.25).
Note: Si l’on utilise des procédures relatives au système câblé ou au système programmé, le modem devrait
également être équipé d’une voie de retour.
2.4
Dès qu’un document est prêt pour transmission en fac-similé, le centre émetteur devrait
envoyer un message d’identification du document sur la voie B. Le message d’identification se présente de
la manière suivante:
où S
O
H
C
R
C
R
L
F
C
R
C
R
L
F
T1T2A1A2ii
C
R
C
R
L
F
FAX
C
R
C
R
L
F
E
T
X
T1
T 2
A 1
A 2
ii
CCCC
YY
GGgg
FAX
nnn
S
P
CCCC
S
P
YYGGgg
(
S
P
)
BBB
}
désigne le type de données
désigne le type de données
Supplément II-5, est l’indicateur de la zone géographique tableaux A à D
est l’indicateur de l’heure de référence
est l’indicateur de niveau
est l’indicateur d’emplacement de la station d’origine du message;
est le jour du mois;
est l’heure standard d’observation;
indique la transmission d’informations en fac-similé.
Édition 2009
II-9/4
2.5
Après avoir reçu un message d’identification, le centre récepteur devrait envoyer une réponse
(par la voie B) dans la forme suivante:
S
O
H
C
R
C
R
L
F
C
R
C
R
L
F
T1T2A1A2L1L2 P
C
R
C
R
L
F
DDD
C
R
C
R
L
F
E
T
X
nnn
S
S
CCCC P
YYGGgg
Le message-réponse devrait être élaboré conformément aux règles qui régissent les messages
adressés (section 2.4 de la partie II), compte tenu des modifications suivantes:
a) Adoption d’un nouveau type de message adressé: le message de service pour le contrôle des échanges
en fac-similé (indicateur particulier TT = BF);
b) Les messages de service pour le contrôle des échanges en fac-similé devraient avoir la priorité;
c) Le groupe DDD, qui définit l’instruction de commande (réponse), est adopté dans les messages de
service pour le contrôle des échanges en fac-similé;
d) Dans un message de service envoyé en réponse à un message d’identification, le groupe DDD peut avoir
l’une des significations suivantes:
RDY (prêt)
— Prêt à recevoir le document;
ABO (arrêt)
— Refus de recevoir le document proposé (message envoyé si le centre récepteur n’a
pas besoin du document);
RPT (répétition) — Demande de répétition du message d’identification (message envoyé si le centre
récepteur trouve une erreur dans le message d’identification).
2.6
S’il reçoit une réponse RDY, le centre émetteur commence à envoyer le document en fac-similé
sur la voie A multiplexée.
2.7
Lorsque la réception du document est terminée ou durant cette opération, le centre récepteur
envoie un message de service à des fins de contrôle des échanges en fac-similé. La forme de présentation de
ce message est décrite au paragraphe 2.5 qui précède. Le groupe DDD peut alors avoir l’une des significations
suivantes:
ACK (accusé de réception)
— Accusé de réception du document fac-similé;
NAK (accusé de réception négatif) — Notification de rejet du document fac-similé (ou réception de
mauvaise qualité).
3.
ALGORITHME D’EXPLOITATION DU CENTRE ÉMETTEUR
3.1
L’algorithme d’exploitation du centre émetteur est reproduit dans la figure 1.
3.2
Description de l’algorithme
Phase B–1
Lorsqu’un document fac-similé est prêt pour transmission, le centre émetteur
commence la phase “départ” et passe à la phase B–2.
Phase B–2
Le centre émetteur envoie un message d’identification pour le document, puis
attend une réponse (mise en route du temporisateur T01).
Phases B–3, C–3, D–3, D–4 Le centre émetteur attend une réponse au message d’identification. Lorsque le
temporisateur T01 expire, le centre passe à la phase E–3.
Édition 2009
à la réception d’une des réponses possibles (RDY, RPT, ABO), le centre passe à
la phase correspondante (B–4, E–3, E–4).
II-9/5
SUPPLéMENT ii-9
Phase E–3
Le nombre de tentatives d’envoi d’un message d’identification est enregistré
par le compteur n.
Phase E–2
Lorsque le nombre de tentatives d’envoi d’un message d’identification est égal
à N, le centre passe à la phase E–4.
Si le nombre de tentatives est inférieur à N, le centre passe à la phase B–2.
Phase B–4
Le centre émetteur envoie le document fac-similé sur la voie A, puis attend une
réponse (phases B–5, B–6).
Phase B–5
Si le centre émetteur reçoit le message NAK durant la transmission d’un
document, il passe à la phase A–5.
Phase A–5
Des signaux de commande automatique de fin de transmission fac-similé sont
envoyés et le nombre de tentatives d’envoi du document est enregistré par le
compteur m.
Phase A–4
Lorsque le nombre de tentatives d’envoi du document fac-similé est égal à M,
le centre passe à la phase E–4.
Si le nombre de tentatives d’envoi du document est inférieur à M, le centre
passe à la phase A–5.
Phase B–6
Si le centre émetteur reçoit le message ACK durant la transmission d’un
document, il estime qu’il peut terminer cette transmission et passer à la
phase A–6.
Phase A–6
Des signaux de commande automatique de fin de transmission fac-similé sont
envoyés.
Phase B–7
Lorsque la transmission du document est terminée, le centre émetteur envoie
les signaux de commande automatique de fin de transmission fac-similé, puis
attend une réponse (mise en route du temporisateur T02).
Phases B–8, C–8, D–8
Le centre émetteur attend l’accusé de réception du document.
Lorsque le temporisateur T02 expire, le centre passe à la phase E–4.
Après avoir reçu l’une des réponses possibles (ACK, NAK), le centre passe à la
phase correspondante (A–8, D–7).
Phase D–7
Le nombre de tentatives de retransmission du document est enregistré dans le
compteur k.
Phase D–5
Lorsque le nombre de tentatives de retransmission du document est égal à K,
le centre passe à la phase E–4.
Si le nombre de tentatives est inférieur à K, le centre passe à la phase B–4.
Phase E–4
L’opérateur du système est averti de toute situation anormale.
Phase A–8
Procédures de fin de transmission.
3.3
N
M
K
M
K
Il est proposé d’adopter pour les paramètres de l’algorithme les valeurs suivantes:
=3
=2
= 2
= 5
=5
pour les voies exploitées en mode fac-similé non codé
pour les voies exploitées en mode fac-similé codé
T01 est égal à 40 secondes
T02 est égal à 120 secondes.
Édition 2009
II-9/6
A
B
C
D
E
Départ
1
NON
Envoi
d’un message
d’identification
du document
2
n=N
?
OUI
Réponse
reçue
RDY?
3
NON
Réponse
reçue
RPT?
NON
OUI
Début
transmission
document
m=M
?
5
Envoi signal
«arrêt
compteur»
m = :m + 1
OUI
Réponse
reçue
NAK?
6
Envoi signal
«arrêt»
OUI
Réponse
reçue
ACK?
Compteur
tentatives
n = :n + 1
NON
NON
4
Réponse OUI
reçue
ABO?
Temporisateur
T01
NON
k=K
?
Appel
opérateur
OUI
NON
Arrêt transmission
document –
envoi signal
«arrêt»
7
Compteur
tentatives
k = :k + 1
OUI
8
Fin
OUI
Réponse
reçue
ACK?
NON
Réponse
reçue
NAK?
NON
Temporisateur
T02
Figure 1 — Algorithme d’exploitation du centre émetteur
Édition 2009
OUI
SUPPLéMENT II-10
COMPTES RENDUS DES CONDITIONS DE RÉCEPTION DES
TRANSMISSIONS RADIOMÉTÉOROLOGIQUES
Forme symbolique:
RECEP
Q cL aL aL a
L oL oL oL o
YYG1G1g
YYG1G1g
G2G2gmkmk
G2G2gmkmk
CCC(n)(n)
CCC(n)(n)
SINPO
SINPO
.....
.....
Signification des mots et lettres symboliques:
RECEP
—
Q c
L aL aL a
L oL oL oL o
YY
G1G1g
—
—
—
—
—
G2G2g
—
m km k
CCC(n)(n)
—
—
SINPO
—
Forme symbolique d’un compte rendu des conditions de réception des transmissions
radio.
Quadrant du globe (conformément au Volume I du Manuel des codes).
Latitude, en dixièmes de degré, de la station radio réceptrice.
Longitude, en dixièmes de degré, de la station radio réceptrice.
Jour du mois (UTC).
Heure d’observation du début de la période à laquelle se réfère le compte rendu,
exprimée en heures et dizaines de minutes UTC.
Heure d’observation de la fin de la période à laquelle se réfère le compte rendu, exprimée en heures et dizaines de minutes UTC.
Bande, en mégahertz, dont relève la fréquence à laquelle se réfère le compte rendu;
par exemple: 07 = 7 MHz ou plus, mais moins de 8 MHz;
15 = 15 MHz ou plus, mais moins de 16 MHz.
Indicatif d’appel international de la fréquence interceptée (généralement en trois
lettres ou trois lettres suivies d’un ou de deux chiffres).
Indicateur de code, suivi d’un groupe de cinq chiffres déterminé selon le code
SINPO tel que celui-ci est défini par la recommandation 251 du CCIR et publié dans
l’Appendice 14 au Règlement des radiocommunications de l’UIT, Genève, 1968. Le
code SINPO est reproduit ci-dessous.
Code SINPO
S
I
échelle
N
Effets nuisibles
Force de
Brouillage
Bruit
signal
5
4
3
2
1
P
Excellente
Bonne
Satisfaisante
Médiocre
à peine audible
Nul
Léger
Modéré
Sévère
Très grave
Nul
Léger
Modéré
Sévère
Très grave
Perturbations de
la propagation
Nulles
Légères
Modérées
Sévères
Très graves
O
Appréciation
d’ensemble
Excellent
Bon
Satisfaisant
Médiocre
Inutilisable
édition 2009
SUPPLéMENT II-11
PROCÉDURES DE DÉROUTEMENT POUR
LE RÉSEAU PRINCIPAL DE TÉLÉCOMMUNICATIONS
1.
DÉFINITIONS
Dérangement — Un circuit est en dérangement lorsqu’une défaillance technique s’est produite
sur ce circuit.
Panne — Un centre ou un circuit est en panne lorsque, par suite d’un dérangement ou pour
toute autre raison, il se trouve mis hors service pendant plus de 30 minutes.
Secours — On entend par moyens de secours tout équipement ou tout circuit disponibles pour
remplacer l’équipement et/ou les circuits se trouvant hors service (à cet égard, il ne faut pas utiliser le terme
“réserve” comme synonyme de “secours”).
Déroutement — On entend par déroutement du trafic une transmission et/ou une réception
d’informations météorologiques par l’intermédiaire de circuits ou de moyens autres que ceux normalement
utilisés.
2.
Mesures à prendre préalablement à une panne
Les dispositions suivantes devraient être prises dans le cadre d’accords bilatéraux ou
multilatéraux:
a) Il conviendrait de préparer sans tarder des programmes appropriés pour transmettre les renseignements
météorologiques dont les différents centres ont besoin;
b) Parallèlement, il conviendrait de préparer les tableaux d’acheminement nécessaires, en tenant compte
des différentes possibilités d’acheminement, s’il en existe plusieurs;
c) Des dispositions devraient être prises pour assurer une bonne coordination entre les opérateurs des
différents centres;
d) Chaque centre devrait préparer, à l’intention des opérateurs, des instructions précisant quelles mesures
devraient être prises et dans quelles conditions.
3.
Mesures à prendre durant une panne
3.1
Lorsqu’un circuit tombe en panne, les opérateurs des deux centres concernés devraient tout
mettre en œuvre pour que le trafic puisse reprendre normalement le plus tôt possible.
3.2
Si un centre constate un défaut de fonctionnement, il doit en informer immédiatement tous
les autres centres intéressés et indiquer la nature de la défectuosité, si cela lui est déjà possible.
3.3
Le centre doit ensuite vérifier ses propres équipements et l’état des circuits.
3.4
Après avoir déterminé l’origine du fonctionnement défectueux, le centre doit immédiatement
adresser un deuxième message à tous les centres intéressés. De toute manière, un deuxième message doit
être envoyé au plus lard une heure après la transmission du premier message, même si la cause de la
défectuosité n’a pas encore été trouvée. D’autres messages devront être transmis, suivant les besoins, afin de
tenir tous les centres intéressés au courant de l’évolution de la situation.
3.5
Après un arrêt de trafic d’une heure ou plus, les centres intéressés devraient décider s’il y a lieu
d’appliquer des mesures de déroutement et le moment à partir duquel ces mesures entreront en vigueur. Si
les centres intéressés décident qu’il faut procéder au déroutement, celui-ci devrait être effectué suivant les
procédures mises au point à ce sujet par accords bilatéraux et/ou multilatéraux.
3.6
Lorsqu’un centre cesse de fonctionner normalement, des mesures devraient être prises pour
essayer d’assurer le rassemblement des données de base provenant de la zone de responsabilité de ce centre,
en vue de leur diffusion régionale et globale.
Édition 2009
II-11/2
4.
Mesures à prendre après une panne
4.1
Dès qu’un centre qui a dû interrompre son service normal est en mesure de reprendre ce
service, il doit en informer immédiatement tous les centres intéressés.
4.2
à ce stade, les centres intéressés décideront du délai qui devra s’écouler avant la reprise normale
du trafic. Ce faisant, ils devraient tenir compte des moyens techniques nécessaires à cet effet.
5.
Messages de service concernant les pannes
5.1
Les messages de service peuvent être transmis sur tout circuit disponible du SMT, compte tenu
des dispositions énoncées dans la section 2.4 de la partie II.
5.2
Lorsque aucun circuit du SMT n’est disponible pour la transmission de tels messages de service,
ceux-ci pourront être acheminés sur le RSFTA (dans ce cas, les messages de service devraient être conformes
au modèle prescrit par l’OACI), ou sur tout autre circuit de télécommunications disponible.
Édition 2009
SUPPLéMENT II-12
INSTRUCTIONS POUR L’UTILISATION DE L’INDICATEUR BBB
1.
L’indicateur BBB doit être inclus dans les lignes d’en-tête abrégées des bulletins supplémentaires,
subséquents, corrigés ou modifiés par les centres chargés d’établir ou de compiler les bulletins concernés.
2.
L’indicateur BBB doit être ajouté lorsque la ligne d’en-tête abrégée de la forme T1T2A1A2ii CCCC
YYGGgg a déjà été utilisée pour la transmission d’un bulletin initial correspondant. Une fois le bulletin initial
transmis, le centre chargé d’établir ou de compiler le bulletin utilise l’indicateur BBB pour transmettre des
messages d’observation supplémentaires, subséquents, corrigés ou modifiés ayant le même en-tête T1T2A1A2ii
CCCC YYGGgg. Pour choisir la forme appropriée de l’indicateur BBB, il convient de s’inspirer des directives
suivantes:
a) Pour transmettre les messages d’observation figurant normalement dans un bulletin initial après la
transmission du bulletin initial ou pour la diffusion subséquente ou supplémentaire d’un bulletin dont
l’en-tête T1T2A1A2ii CCCC YYGGgg ne serait pas unique sans un champ BBB et où CCx ou AAx ne s’applique pas, l’indicateur BBB à utiliser est RRx, où x =:
A, pour le premier bulletin suivant la diffusion du bulletin initial;
B, si un autre bulletin doit être diffusé;
et ainsi de suite jusqu’à x = X inclusivement;
b) Pour transmettre un bulletin contenant des informations ou des messages d’observation corrigés qui
ont déjà été diffusés dans un bulletin précédent, l’indicateur BBB à utiliser est CCx, où x =:
A, pour le premier bulletin contenant des messages d’observation ou des informations corrigés;
B, si un deuxième bulletin contenant des messages d’observation ou des informations corrigés est
diffusé;
c) Pour transmettre un bulletin contenant des amendements apportés à l’information figurant dans un
bulletin diffusé précédemment, l’indicateur BBB à utiliser est AAx, où x =:
A, pour le premier bulletin contenant des amendements apportés à l’information;
B, pour un deuxième bulletin contenant des modifications apportées à des informations;
d) Si plus de 24 indicateurs BBB doivent être utilisés pour les séquences indiquées aux alinéas a), b) et c)
ci-dessus, il faudrait continuer d’utiliser l’indice x = X;
e) Pour les séquences a), b) et c) ci-dessus, les valeurs x = Y et x = Z doivent être utilisées aux fins particulières indiquées ci-après:
i) x = Y pour le chiffrement de BBB lorsqu’une panne du système entraîne la perte de la séquence des
valeurs de caractères assignées à x;
ii) x = Z pour le chiffrement de BBB lorsque les bulletins sont établis ou compilés plus de 24 heures
après l’heure d’observation.
3.
Un CRT du SMT devrait assurer la retransmission des bulletins reçus, conformément à ses
programmes d’acheminement, même si les bulletins contenant l’indicateur BBB n’ont pas été reçus en
séquence correcte.
Édition 2009
SUPPLéMENT II-13
RECOMMANDATION X.25 ITU-T (EXTRAITS)*
Les extraits de la Recommandation X.25 ITU-T décrivant les méthodes et éléments des
procédures à utiliser pour le SMT sont donnés dans ce supplément.
_________
* Extrait du Livre bleu du CCITT, Tome VIII, Fascicule VIII.2. La Recommandation X.25 est reproduite après
reproduction.
Édition 2009
II-13/2
Recommandation X.25
Interface entre équipement terminal de traitement de données (ETTD) et
équipement de terminaison du circuit de données (ETCD) pour terminaux
fonctionnant en mode-paquet et raccordés à des réseaux publics
pour données par circuit spécialisé
(Genève, 1976; modifiée à Genève, 1980,
Malaga-Torremolinos, 1984, et Melbourne, 1988)
[...]
SOMMAIRE
1. Caractéristiques de l’interface ETTD/ETCD (couche physique)
1.1Interface conforme à la Recommandation X.21
1.2Interface conforme à la Recommandation X.21 bis
1.3Interface conforme aux Recommandations de la série V
[...]
2.Procédures d’accès à la liaison à travers l’interface ETTD/ETCD
2.1Portée et champ d’application
2.2Structure de trame
2.3éléments des procédures LAPB
2.4Description de la procédure LAPB
[...]
3.Description de l’inteRface ETTD/ETCD à la couche paquets
3.1Voies logiques
3.2Structure de base des paquets
3.3Procédure de reprise
3.4Traitement des erreurs
4.Procédures relatives aux services de circuits virtuels
4.1Procédures pour le service de communication virtuelle
4.2Procédures pour le service de circuits virtuels permanents
4.3Procédures pour le transfert des données et des interruptions
4.4Procédures de contrôle de flux
4.5Effets des procédures de libération, de réinitialisation et de reprise sur le transfert des paquets
4.6Effets de la couche physique et de la couche liaison de données sur la couche paquets
5. Format des paquets
5.1Considérations générales
5.2Paquets d’établissement et de libération de la communication
5.3Paquets de données et d’interruption
5.4Paquets de contrôle de flux et de réinitialisation
5.5Paquets de reprise
[...]
Annexe A — Gamme de voies logiques utilisées pour les communications virtuelles et les circuits virtuels
permanents
Annexe B —Diagrammes d’état de l’interface ETTD/ETCD à la couche paquets
[...]
Annexe D — Temporisations de l’ETCD et temps limites de l’ETTD à la couche paquets
[ . . . ]
Annexe G — Services complémentaires d’ETTD spécifiés par le CCITT utilisés pour pouvoir admettre le
service de réseau OSI
[...]
Édition 2009
SUPPLéMENT ii-13
II-13/3
Appendice I — Exemples de schémas de bits transmis à la couche liaison de données par l’ETCD et par
l’ETTD
Appendice II—Explication de la manière dont sont déterminées les valeurs de N1 au § 2.4.8.5
[...]
1.
Caractéristiques de l’interface ETTD/ETCD (couche physique)
Les Administrations peuvent offrir une ou plusieurs des interfaces spécifiées ci-dessous.
L’utilisation exacte des points pertinents de ces Recommandations est indiquée en détail ci-après.
1.1Interface conforme à la Recommandation X.21
1.1.1
éléments de l’interface physique ETTD/ETCD
Les éléments de l’interface physique ETTD/ETCD doivent être conformes aux § 2.1 à 2.5 de la
Recommandation X.21.
1.1.2
Procédures de passage aux phases opérationnelles
Les procédures de passage aux phases opérationnelles sont celles que décrit le § 5.2 de
la Recommandation X.21, étant entendu que l’échange de données sur les circuits T et R quand
l’interface est à l’état 13S, 13R et 13 de la figure A-3/X.21 a lieu comme indiqué ci-après dans la présente
Recommandation.
Les états non prêt figurant au § 2.5 de la Recommandation X.21 sont considérés comme des
états non opérationnels et peuvent être considérés, aux couches supérieures, comme des états hors service
(voir le § 4.6).
1.1.3
Détection des dérangements et boucles d’essai
Les principes de détection des dérangements sont ceux qui figurent au § 2.6 de la
Recommandation X.21. De plus, i = OUVERT peut être signalé en cas de défaillance momentanée de
la transmission: les couches supérieures peuvent attendre plusieurs secondes avant de considérer que
l’interface est hors service.
Les définitions des boucles d’essai et des principes d’essai pour la maintenance à l’aide de
boucles d’essai font l’objet de la Recommandation X.150.
La description des boucles d’essai et des procédures d’utilisation est donnée au § 7 de la
La mise en place automatique par un ETTD d’une boucle d’essai de type 2 dans l’ETCD du
terminal distant n’est pas possible. Toutefois, certaines Administrations peuvent permettre aux ETTD de
commander l’équivalent d’une boucle d’essai de type 2 au CCD local afin de tester la ligne louée ou la ligne
d’abonné et/ou tout ou partie de l’ETTD ou de l’équipement de terminaison de ligne. La commande de la
boucle par l’usager, si elle est prévue, peut se faire manuellement ou automatiquement, comme indiqué
respectivement dans les Recommandations X.150 et X.21.
1.1.4
X.21.
Base de temps pour les éléments du signal
La base de temps pour les éléments du signal est conforme au § 2.6.3 de la Recommandation
1.2Interface conforme à la Recommandation X.21 bis
1.2.1
X.21 bis.
éléments de l’interface physique ETTD/ETCD
Les éléments de l’interface physique ETTD/ETCD sont conformes au § 1.2 de la Recommandation
1.2.2
Phases opérationnelles
Lorsque le circuit 107 est à l’état FERMÉ, et que les circuits 105, 106, 108 et 109 (s’ils existent)
sont à l’état FERMÉ, l’échange des données sur les circuits 103 et 104 se fait comme indiqué ci-après dans la
présente Recommandation.
Édition 2009
II-13/4
Lorsque le circuit 107 est à l’état OUVERT, ou lorsque l’un quelconque des circuits 105, 106, 108
ou 109 (s’ils existent) est à l’état OUVERT, cela indique un état non opérationnel, qui peut être considéré
comme un état hors service aux couches supérieures (voir le § 4.6).
1.2.3
Détection des dérangements et boucles d’essai
Les principes de détection des dérangements, la description et les procédures d’utilisation des
boucles d’essai sont conformes aux § 3.1 à 3.3 de la Recommandation X.21 bis. De plus, les circuits 106 et
109 peuvent passer à l’état OUVERT par suite de défaillances momentanées de la transmission. Les couches
supérieures peuvent attendre plusieurs secondes avant de considérer que l’interface est hors service.
La mise en place automatique par un ETTD d’une boucle d’essai de type 2 dans l’ETCD du
terminal distant n’est pas possible. Toutefois, certaines Administrations peuvent permettre aux ETTD de
commander l’équivalent d’une boucle d’essai de type 2 au CCD local afin de tester la ligne louée ou la ligne
d’abonné et/ou tout ou partie de l’ETCD ou de l’équipement de terminaison de ligne. La commande de la
boucle par l’usager, si elle est prévue, peut se faire manuellement ou automatiquement, comme indiqué
respectivement dans les Recommandations X.150 et X.21 bis.
1.2.4
X.21 bis.
Base de temps pour les éléments du signal
La base de temps pour les éléments du signal est conforme au § 3.4 de la Recommandation
1.3Interface conforme aux Recommandations de la série V
Le fonctionnement général avec les modems de la série V est décrit au § 1.2 ci-dessus. Toutefois,
on se reportera, pour obtenir des précisions, notamment en ce qui concerne les principes de la détection
des défaillances, les essais en boucle et l’utilisation des circuits 107, 109, 113 ou 114, aux Recommandations
pertinentes de la série V.
Le délai s’écoulant entre la fermeture du circuit 105 et celle du circuit 106 (s’ils existent) doit
être supérieur à 10 ms et inférieur à 1 s. De plus, les circuits 106 ou 109 peuvent passer à l’état OUVERT en
raison de défaillances momentanées de la transmission ou d’un reconditionnement du modem. Les couches
supérieures peuvent attendre plusieurs secondes avant de considérer que l’interface est hors service.
[...]
2.Procédures d’accès à la liaison à travers l’interface ETTD/ETCD
2.1Portée et champ d’application
2.1.1
Les procédures d’accès à la liaison (LAPB et LAP) sont l’élément de couche liaison de données:
elles sont utilisées pour l’échange de données entre un ETCD et un ETTD sur un circuit physique simple
(LAPB et LAP), ou en option, sur plusieurs circuits physiques (LAPB) opérant dans l’une des catégories
d’usager du service 8 à 11 de la Recommandation X.1. L’utilisation de plusieurs circuits physiques, qui peut
être choisie en option au moment de l’abonnement pour l’exploitation multiliaison (LAPB), est nécessaire si
les effets des dérangements de circuit ne doivent pas interrompre le fonctionnement à la couche paquets.
Les procédures à liaison unique (PLU) décrites aux § 2.2, 2.3 et 2.4 (LAPB) et aux § 2.2, 2.6
et 2.7 (LAP) sont utilisées pour l’échange de données sur un circuit physique unique, en conformité avec
la description faite au § 1, entre un ETTD et un ETCD. Lorsqu’une exploitation multiliaison optionnelle
est utilisée avec le LAPB, une procédure à liaison unique (PLU) est utilisée séparément sur chaque circuit
physique et la procédure multiliaison (PML) décrite au § 2.5 est utilisée pour l’échange de données sur
les liaisons de données LAPB multiples parallèles. En outre, lorsqu’un circuit physique unique est utilisé
pour la procédure LAPB, il peut être convenu avec l’Administration d’utiliser cette procédure multiliaison
optionnelle sur la liaison de données unique LAPB.
2.1.2
Les procédures à liaison unique (PLU) utilisent les principes et la terminologie des procédures
de commande de liaison de données à haut niveau (HDLC) définis par l’Organisation internationale de
normalisation (ISO). La procédure multiliaison (PML) utilise les principes et la terminologie des procédures
de commande de multiliaison spécifiées par l’ISO.
2.1.3
Le moyen de transmission est duplex.
2.1.4
La compatibilité de fonctionnement des ETCD avec les classes de procédure symétriques de
l’ISO (classe BA avec les options 2 et 8 et classe BA avec les options 2, 8 et 10) est assurée conformément
Édition 2009
SUPPLéMENT ii-13
II-13/5
à la procédure LAPB décrite aux § 2.3 et 2.4. Parmi ces classes, la classe BA avec les options 2 et 8 (LAPB
modulo 8) constitue le service de base, offert dans tous les réseaux. La classe BA avec les options 2, 8 et 10
(LAPB modulo 128) est un service facultatif de numérotation séquentielle étendue, pouvant être choisi au
moment de l’abonnement et utilisé dans les réseaux qui desservent des ETTD nécessitant une numérotation
séquentielle modulo 128.
Les constructeurs et les installateurs d’ETTD doivent tenir compte du fait que la procédure
désignée ci-après LAPB modulo 8 est la seule offerte dans tous les réseaux.
De même, un ETTD peut continuer à utiliser la procédure LAP décrite aux § 2.2, 2.6 et 2.7
(dans les réseaux utilisant cette procédure), mais, s’agissant d’ETTD nouvellement mis en œuvre, il est
préférable d’utiliser la procédure LAPB. Les procédures LAP ne sont définies que pour le service de base
modulo 8.
Remarque:
Exemples d’autres applications possibles nécessitant un complément d’étude:
– Exploitation bidirectionnelle à l’alternat, mode de réponse asynchrone;
– Exploitation bidirectionnelle simultanée, mode de réponse normal;
– Exploitation bidirectionnelle à l’alternat, mode de réponse normal.
2.1.5
En ce qui concerne les réseaux dans lesquels il a été décidé de mettre en œuvre les services
de numérotation séquentielle de base et étendue LAPB, le choix du mode de base (modulo 8) ou du mode
étendu (modulo 128) peut se faire au moment de l’abonnement. Le choix du mode utilisé pour chaque
procédure de liaison de données est indépendant de tous les autres ainsi que du choix de mode pour
les procédures correspondantes à la couche paquets. Tous les choix font l’objet d’un accord d’une durée
déterminée avec l’Administration.
2.1.6
S’agissant de réseaux qui utilisent à la fois la procédure LAPB et la procédure LAP, l’ETCD
conserve une variable du mode interne B à laquelle il donne:
— La valeur 1 lorsqu’il accepte une commande mise en mode asynchrone symétrique (SABM)/
mise en mode asynchrone symétrique étendu (SABME) provenant de l’ETTD (modulo 8/
modulo 128) ou lorsqu’il émet une commande SABM/SABME;
— La valeur 0 lorsqu’il accepte une commande SARM provenant de l’ETTD.
Quand B = 1, l’ETCD utilise la procédure LAPB décrite aux § 2.2, 2.3 et 2.4 et se trouve alors
dans le mode LAPB (symétrique).
Quand B = 0, l’ETCD utilise la procédure LAP décrite aux § 2.2, 2.6 et 2.7 et se trouve dans le
mode LAP.
L’ETTD ne peut modifier la variable de mode B que si la liaison de données a été déconnectée,
comme indiqué aux § 2.4.4.3 et 2.7.3.3.
En cas de mauvais fonctionnement de l’ETCD annulant la valeur actuelle de la variable de
mode interne B, l’ETCD, au moment du rétablissement du service, n’envoie ni une commande SARM ni une
commande SABM/SABME. Il peut envoyer une commande DISC ou une réponse DM pour informer l’ETTD
que l’ETCD est dans la phase de déconnexion. L’ETTD tentera donc de réinitialiser la liaison de données
avec la commande d’établissement de mode (SARM ou SABM/SABME) qu’il jugera appropriée. L’ETCD sera
alors en mesure de donner sa valeur correcte à la variable de mode B.
2.2Structure de trame
2.2.1
Toutes les transmissions sur les PLU se font à l’intérieur de trames et chaque trame est conforme
à l’un des formats du tableau 1/X.25, pour le fonctionnement de base (modulo 8), ou du tableau 2/X.25
pour un fonctionnement étendu (modulo 128). Le fanion précédant le champ d’adresse est défini comme le
fanion d’ouverture de la trame. Le fanion suivant le champ séquence de contrôle de trame (FCS) est défini
comme le fanion de fermeture de la trame.
2.2.2
Structure de trame
Toutes les trames commencent et finissent par une séquence de fanion. Cette séquence est
formée par un “0” suivi par six “1” consécutifs et un “0”. L’ETTD et l’ETCD n’envoient que des séquences de
fanion complètes (8 bits) lorsqu’ils envoient des séquences multiples de fanions (voir le § 2.2.11). Un même
fanion peut être utilisé à la fois comme fanion de fermeture d’une trame et comme fanion d’ouverture de
la trame suivante.
Édition 2009
II-13/6
Tableau 1/X.25 — Format des trames — Fonctionnement de base (modulo 8)
Ordre de
transmission
des bits
12345678
12345678
12345678
16 à 1
12345678
Fanion
Adresse
Commande
FCS
Fanion
F
A
C
FCS
F
01111110
8 bits
8 bits
16 bits
01111110
FCS Séquence de contrôle de trame (Frame Checking Sequence)
Ordre de
transmission
des bits
12345678
12345678
Fanion
Adresse
Commande
C
F
A
01111110
8 bits
12345678
Information
Info
8 bitsN bits
16 à 1
12345678
FCS
Fanion
FCS
F
16 bits
01111110
Tableau 2/X.25 — Format des trames — Fonctionnement étendu (modulo 128)
Ordre de
transmission
des bits
12345678
12345678
1 à *)
16 à 1
12345678
Fanion
Adresse
Commande
FCS
Fanion
F
A
C
FCS
F
01111110
8 bits
*) bits
16 bits
01111110
Ordre de
transmission
des bits
12345678
12345678
Fanion
Adresse
Commande
C
F
A
01111110
8 bits
1 à *)
Information
Info
*) bitsN bits
16 à 1
12345678
FCS
Fanion
FCS
F
16 bits
01111110
*) 16 pour les trames contenant des numéros de séquence; 8 pour les trames ne contenant pas de
numéros de séquence.
2.2.3
Champ d’adresse
Le champ d’adresse s’étend sur un octet. Il identifie le destinataire prévu d’une trame de
commande et l’expéditeur d’une trame de réponse. Le codage de ce champ est décrit aux § 2.4.2 (LAPB) et
2.7.1 (LAP).
2.2.4
Champ de commande
Pour le fonctionnement modulo 8 (de base), le champ de commande s’étend sur un octet. Pour
le fonctionnement modulo 128 (étendu), il s’étend sur deux octets pour les trames contenant des numéros
Édition 2009
II-13/7
SUPPLéMENT ii-13
de séquence et sur un octet pour les trames ne contenant pas de numéros de séquence. Le contenu de ce
champ est décrit aux § 2.3.2 (LAPB) et 2.6.2 (LAP).
2.2.5
Champ d’information
Le champ d’information d’une trame, s’il existe, suit le champ de commande (voir le § 2.2.4)
et précède le champ de séquence de contrôle de trame (voir le § 2.2.7).
Les codages et groupements d’éléments binaires dans le champ d’information sont indiqués
aux § 2.3.4.9, 2.5.2, 2.6.4.8 et 5.
2.7.7.5.
La longueur maximale du champ d’information est précisée aux § 2.3.4.9, 2.4.8.5, 2.6.4.8 et
2.2.6
Transparence
En émission, l’ETTD ou l’ETCD examine le contenu de la trame entre les deux séquences de
fanion, y compris les champs d’adresse, de commande, d’information et FCS, et insère un bit “0” après toute
séquence de 5 bits “1” consécutifs (y compris les 5 derniers bits de la FCS) afin de s’assurer qu’une séquence
de fanion n’est pas simulée. En réception, l’ETTD ou l’ETCD examine le contenu de la trame et élimine tout
bit “0” qui suit immédiatement 5 bits “1” consécutifs.
2.2.7
Champ de séquence de contrôle de trame (FCS)
La notation employée pour décrire la FCS est fondée sur la caractéristique des codes
cycliques selon laquelle un vecteur de code comme 1000000100001 peut être représenté par le polynôme
P(x) = x12 + x5 + 1. Ainsi les éléments d’un mot de code à n-éléments sont les coefficients d’un polynôme
d’ordre n – 1. Dans cette application, ces coefficients peuvent avoir la valeur 0 ou 1 et les opérations du
polynôme se font en modulo 2. Le polynôme générateur représentant le contenu d’une trame utilise le
premier bit reçu après le fanion d’ouverture de trame comme coefficient du terme le plus élevé.
Le champ FCS est une séquence de 16 bits. Il est le complément à un de la somme modulo 2 du:
1) Reste de la division (modulo 2) de xk (x15 + x14 + x13 + x12 + x11 + x10 + x9 + x8 + x7 + x6 + x5 + x4 + x3 + x2
+ x + 1) par le polynôme générateur x16 + x12 + x5 + 1, où k est le nombre de bits contenu dans la trame
existant entre, mais n’incluant pas, le dernier bit du signal d’ouverture de trame (fanion) et le premier
bit de la FCS, à l’exclusion des bits insérés pour la transparence; et du
2) Reste de la division (modulo 2), par le polynôme générateur x16 + x12 + x5 + 1 du produit de x16 par le
contenu de la trame existant entre, mais n’incluant pas, le dernier bit du signal d’ouverture de trame
(fanion) et le premier bit de la FCS, à l’exclusion des bits insérés pour la transparence.
Comme exemple de réalisation à l’émission, le contenu initial du registre du dispositif qui
calcule le reste est tout d’abord fixé à la valeur représentée par des uns consécutifs. Il est ensuite modifié par
division des champs d’adresse, de commande et d’information par le polynôme générateur (comme décrit
ci-dessus). Le complément à un du reste ainsi obtenu est transmis comme FCS de 16 bits.
à la réception, le contenu initial du registre du dispositif qui calcule le reste est tout d’abord
fixé à la valeur représentée par des uns consécutifs. Le reste définitif, après multiplication par x16 puis
division (modulo 2) par le polynôme générateur x16 + x12 + x5 + 1 de la suite des bits reçus (bits protégés et
FCS) est 0001110100001111 (respectivement de x15 à x0) en l’absence d’erreurs de transmission.
Remarque: L’appendice I donne des exemples de séquences de bits émis par l’ETCD et l’ETTD pour illustrer
l’application du mécanisme de transparence et de la séquence de contrôle de trame pour une
commande SABM et une réponse UA.
2.2.8
Ordre de transmission des éléments binaires
Les adresses, commandes, réponses et numéros de séquence sont transmis en commençant par
le bit de poids faible (par exemple, le premier bit du numéro de séquence transmis a le poids 2°). L’ordre
de transmission des bits dans le champ d’information n’est pas précisé dans le présent § 2. La séquence de
contrôle de trame est transmise sur la ligne en commençant par le coefficient du terme le plus élevé, qui se
trouve dans le bit 16 du champ FCS (voir les tableaux 1/X.25 et 2/X.25).
Remarque: Le bit 1 est défini comme le bit de poids faible dans les tableaux 1/X.25 à 13/X.25.
2.2.9
Trames non valables
La définition d’une trame non valable figure au § 2.3.5.3 (LAPB) et au § 2.6.5.3 (LAP).
Édition 2009
II-13/8
2.2.10
Abandon d’une trame
L’abandon d’une trame est réalisé en transmettant au moins sept bits “1” consécutifs (sans
insertion de zéros).
2.2.11
Remplissage de temps entre trames
Le remplissage de temps entre trames est réalisé en transmettant des fanions consécutifs entre
les trames, c’est-à-dire des séquences multiples de fanion à huit bits (voir le § 2.2.2).
2.2.12
un sens.
états d’une voie de transmission
Une voie de transmission, telle qu’elle est définie ici, est un moyen de transmission dans
2.2.13
Voie active
Une voie d’arrivée ou de départ d’ETCD est à l’état actif quand elle est en train de recevoir ou
de transmettre une trame, un abandon de trame ou un remplissage de temps entre trames.
2.2.14
Voie inactive
Une voie d’arrivée ou de départ d’ETCD est à l’état inactif quand elle est en train de recevoir ou
de transmettre un état “1” permanent pendant une durée de 15 bits au moins.
Voir au § 2.3.5.5 la description de l’action de l’ETCD quand il existe un état inactif d’une durée
excessive sur sa voie d’arrivée.
2.3
éléments des procédures LAPB
2.3.1
On entend par éléments des procédures LAPB les actions qui ont lieu lors de la réception de
trames par un ETTD ou un ETCD.
Les éléments des procédures définis ci-après contiennent une sélection de commandes et
de réponses ayant trait à la liaison de données et à la configuration du système LAPB décrites au § 2.1.
L’ensemble des § 2.2 et 2.3 contient les règles générales nécessaires pour assurer une gestion correcte de la
liaison de données d’accès LAPB.
2.3.2
Formats des champs de commande et paramètres LAPB
2.3.2.1
Formats des champs de commande
Le champ de commande contient une commande ou une réponse ainsi que des numéros de
séquence s’il y a lieu.
Trois types de formats de champ de commande sont utilisés: les trames I numérotées, pour
le transfert d’information; les trames S numérotées, pour les fonctions de supervision; les trames U non
numérotées, pour les fonctions de commande.
Les formats des champs de commande pour le fonctionnement de base (modulo 8) sont donnés
au tableau 3/X.25.
Les formats des champs de commande pour le fonctionnement étendu (modulo 128) sont
donnés au tableau 4/X.25.
2.3.2.1.1
Format I pour le transfert d’information
Le format I est utilisé pour effectuer un transfert d’information. Les fonctions de N(S), N(R) et
P sont indépendantes, ce qui signifie que toute trame I porte un numéro de séquence N(S), un numéro de
séquence N(R) qui peut éventuellement accuser réception de trames I supplémentaires reçues par l’ETTD ou
l’ETCD et un bit P qui peut avoir la valeur “0” ou “1”.
2.3.2.1.2
Format S pour la supervision
Le format S est utilisé pour effectuer les fonctions de commande de supervision de la liaison de
données, comme accuser réception de trames d’information (trame I), demander la retransmission de trames I
et demander un arrêt temporaire de la transmission des trames I. Les fonctions de N(R) et P/F sont indépendantes;
Édition 2009
II-13/9
SUPPLéMENT ii-13
chaque trame de supervision S porte un numéro de séquence N(R) qui peut éventuellement accuser réception
de trames I supplémentaires reçues par l’ETTD ou l’ETCD et un bit P/F qui peut avoir la valeur “0” ou “1”.
2.3.2.1.3
Format U non numéroté
Le format U est utilisé pour exécuter des fonctions supplémentaires de commande de liaison de
données. Il ne contient pas de numéro de séquence, mais un bit P/F qui peut avoir la valeur “0” ou “1”. La
longueur du champ de commande (1 octet) des trames non numérotées U est la même en fonctionnement
de base (modulo 8) et en fonctionnement étendu (modulo 128).
2.3.2.2
Paramètres du champ de commande
Les différents paramètres associés aux formats des champs de commande sont décrits ci-après.
2.3.2.2.1
Le module
Chaque trame I est numérotée séquentiellement. Son numéro prend les valeurs de 0 jusqu’au
module moins 1 (le module étant le module de la suite des numéros). Ce module est égal à 8 ou à 128; les
numéros de séquence varient cycliquement en utilisant la gamme complète des valeurs possibles.
2.3.2.2.2
Variable d’état à l’émission V(S)
La variable d’état à l’émission V(S) indique le numéro de séquence de la prochaine trame I
devant être émise en séquence; elle peut prendre toutes les valeurs de 0 jusqu’au module moins 1. La
valeur de V(S) est incrémentée de 1 à chaque émission successive d’une trame I mais ne peut, dans l’ETCD,
dépasser le numéro N(R) de la dernière trame d’information ou de supervision reçue d’une valeur supérieure
au nombre maximal de trames I en anticipation (k). La valeur de k est définie au § 2.4.8.6.
Tableau 3/X.25 — Format des champs de commande LAPB — Fonctionnement de base (modulo 8)
Bits du champ
de commande
1
2
3
4
5
6
Trame I
0N(S)PN(R)
Trame S
1
0
S
SP/FN(R)
Trame U
1
1
M
MP/F
M
7
M
8
M
N(S)Numéro de séquence en émission (l’élément binaire 2 étant de poids faible)
N(R)Numéro de séquence en réception (l’élément binaire 6 étant de poids faible)
S
Bit de la fonction de supervision
M
Bit de la fonction de modification
P/F Bit d’invitation à émettre lorsqu’il est issu d’une commande, bit de fin lorsqu’il est issu d’une réponse
(1 = invitation à émettre/fin)
P
Bit d’invitation à émettre (1 = invitation à émettre)
Tableau 4/X.25 — Format des champs de commande LAPB — Fonctionnement étendu (modulo 128)
Bits du champ 1
de commande
2
3
4
5
6
7
8
9
10
11
12 13
Trame I
0N(S)PN(R)
Trame S
1
0
S
S
Trame U
1
1
M
MP/F
X
X
X
XP/FN(R)
M
M
M
14
15
16
N(S)Numéro de séquence en émission (l’élément binaire 2 étant de poids faible)
N(R)Numéro de séquence en réception (l’élément binaire 10 étant de poids faible)
S
Bit de la fonction de supervision
M
Bit de la fonction de modification
X
Réservé et mis sur 0
P/F
Bit d’invitation à émettre lorsqu’il est issu d’une commande, bit de fin lorsqu’il est issu d’une
réponse (1 = invitation à émettre/fin)
P
Bit d’invitation à émettre (1 = invitation à émettre)
Édition 2009
II-13/10
2.3.2.2.3
Numéro de séquence à l’émission N(S)
Seules les trames I portent N(S), le numéro de séquence à l’émission des trames émises. Au
moment où une trame I en séquence est désignée pour émission, la valeur de N(S) est mise à jour de telle
façon qu’elle soit égale à la valeur de la variable d’état à l’émission.
2.3.2.2.4
Variable d’état à la réception V(R)
La variable d’état à la réception V(R) indique le numéro de séquence de la prochaine trame I
attendue en séquence à la réception. Elle peut prendre toutes les valeurs entières de 0 jusqu’au module
moins 1. La valeur de V(R) est incrémentée de 1 à la réception d’une trame I reçue sans erreur et en séquence
dont le numéro de séquence à l’émission est égal à la variable d’état à la réception.
2.3.2.2.5
Numéro de séquence à la réception N(R)
Toutes les trames I et toutes les trames de supervision (trame S) portent le numéro de séquence
N(R) de la prochaine trame attendue en séquence à la réception. Au moment où une trame de l’un des
types ci-dessus est désignée pour émission, la valeur de N(R) est mise à jour de telle façon qu’elle soit égale
à la valeur actuelle de la variable d’état à la réception V(R). N(R) indique que l’ETTD ou l’ETCD qui émet
le numéro N(R) a correctement reçu toutes les trames I dont le numéro de séquence est inférieur ou égal à
N(R) – 1.
2.3.2.2.6
Bit d’invitation à émettre/fin (P/F)
Toutes les trames contiennent le bit d’invitation à émettre/fin (P/F). Dans les trames de
commande, il porte la désignation de bit d’invitation à émettre (P) et dans les trames de réponse, celle de
bit de fin (F).
2.3.3
Fonctions du bit d’invitation à émettre/fin (P/F)
Lorsqu’il a la valeur 1, le bit d’invitation à émettre est utilisé par l’ETCD ou par l’ETTD pour
solliciter une réponse de l’ETTD ou de l’ETCD respectivement. Lorsqu’il a la valeur 1, le bit de fin est utilisé
par l’ETCD ou par l’ETTD pour indiquer la trame de réponse respectivement transmise par L’ETTD ou par
l’ETCD à la suite d’une commande d’invitation.
L’utilisation du bit P/F est décrite au § 2.4.3.
2.3.4
Commandes et réponses
Pour le fonctionnement de base (modulo 8), les commandes et réponses indiquées au tableau
5/X.25 sont admises par l’ETCD et l’ETTD.
Pour le fonctionnement étendu (modulo 128), les commandes et les réponses représentées au
tableau 6/X.25 sont admises par l’ETCD et par l’ETTD.
Pour les procédures LAPB, le codage “11” du bit de fonction de supervision et les codages
des bits de fonction de modification dans les tableaux 3/X.25 et 4/X.25 qui ne sont pas identifiés dans le
tableau 5/X.25 ou 6/X.25 sont identifiés comme des champs de commande pour commande et réponse
“non définis ou non mis en œuvre”.
Les commandes et les réponses des tableaux 5/X.25 et 6/X.25 sont les suivantes:
2.3.4.1
Commande d’information (I)
La fonction de la commande d’information (I) est de transmettre sur la liaison de données des
trames numérotées séquentiellement qui contiennent un champ d’information.
2.3.4.2
Commande et réponse prêt à recevoir (RR)
La trame de supervision prêt à recevoir (RR) est utilisée par l’ETTD ou l’ETCD pour :
1) Indiquer qu’elle est prête à recevoir une trame I et
2) Accuser réception des trames I reçues précédemment et dont le numéro de séquence est égal ou inférieur
à N(R) – 1.
Édition 2009
II-13/11
SUPPLéMENT ii-13
Tableau 5/X.25 — Commandes et réponses LAPB — Fonctionnement de base (modulo 8)
Format
Commandes
Réponses
1
2
3
4
5
6
7
8
Codage
Transfert
d’information
I
(information)
0N(S)PN(R)
(prêt RR
à recevoir)
(prêt à recevoir)
1
0
0
0P/FN(R)
RNR (non prêt
à recevoir)
RNR (non prêt
à recevoir)
1
0
1
0P/FN(R)
1
0
0
1P/FN(R)
Supervision
RR
REJ
(rejet)
REJ
(rejet)
Non numéroté SABM
(mise en
mode
asynchrone
symétrique)
1
1
1
1P
1
0
0
DISC
(déconnexion)
1
1
0
0P
0
1
0
DM
(mode
déconnecté)
1
1
1
1
F
0
0
0
UA
(accusé de
réception
non numéroté
1
1
0
0
F
1
1
0
FRMR (rejet de trame) 1
1
1
0
F
0
0
1
Tableau 6/X.25 — Commandes et réponses LAPB — Fonctionnement étendu (modulo 128)
Commandes
Format
Transfert
d’information
I
Réponses
1
2
3
4 5
6
7
8
9 10-16
(information)
0N(S)PN(R)
Supervision
RR
(prêt
RR
à recevoir)
(prêt
à recevoir)
1
0
0
0
0 0
0
0P/FN(R)
RNR
(non prêt
RNR (non prêt
à recevoir)
à recevoir)
1
0
1
0
0 0
0
0P/FN(R)
(rejet)
1
0
0
1
0 0
0
0P/FN(R)
Non numéroté SABME(mise en mode
asynchrone
symétrique
étendu)
1
1
1
1P 1
1
0
DISC
1
1
0
0P 0
1
0
1
1
1
1
F 0
0
0
1
1
0
0
F 1
1
0
FRMR (rejet de trame) 1
1
1
0
F 0
0
1
REJ
REJ
(rejet)
(déconnexion)
DM
(mode
déconnecté)
UA
(accusé de
réception
non numéroté
Une trame RR peut être utilisée pour indiquer la sortie d’un état occupé qui a été signalé
auparavant par l’émission d’une trame RNR, par ce même poste (ETCD ou ETTD). Outre qu’elle indique
l’état de l’ETCD ou de l’ETTD, la commande RR dont le bit P a la valeur 1 peut être utilisée par l’ETTD pour
demander l’état de l’ETCD ou par l’ETCD pour demander l’état de l’ETTD.
Édition 2009
II-13/12
2.3.4.3
Commande et réponse non prêt à recevoir (RNR)
La trame de supervision non prêt à recevoir (RNR) est utilisée par l’ETTD ou l’ETCD pour
indiquer un état d’occupation, c’est-à-dire une incapacité temporaire à accepter les trames I suivantes. La
trame RNR accuse réception des trames I dont le numéro de séquence est inférieur ou égal à N(R) – 1. Elle
n’accuse pas réception de la trame I N(R), ni d’aucune autre trame I qui pourrait être reçue à sa suite; les avis
d’acceptation de ces trames sont indiqués dans des échanges ultérieurs.
Outre l’indication de l’état de l’ETCD et de l’ETTD, la commande RNR dont le bit P a la valeur
1 peut être utilisée par l’ETTD pour demander l’état de l’ETCD ou par l’ETCD pour demander l’état de
l’ETTD.
2.3.4.4
Commande et réponse rejet (REJ)
La trame de supervision rejet (REJ) est utilisée par l’ETTD ou l’ETCD pour demander la
retransmission des trames I numérotées à partir de N(R). La trame REJ accuse réception des trames dont
le numéro de séquence est inférieur ou égal à N(R) – 1. Les trames I suivantes en attente de transmission
peuvent être transmises à la suite de la ou des trame(s) I retransmise(s).
Il ne peut être établi qu’une seule condition d’exception REJ à un instant donné et dans un
sens donné de transmission de l’information. La condition d’exception REJ est annulée (réinitialisée) à la
réception d’une trame I dont le numéro N(S) est égal au numéro N(R) demandé par la trame REJ.
Une trame REJ peut être utilisée pour indiquer la sortie d’un état d’occupation qui a été signalé
auparavant par l’émission d’une trame RNR par ce même poste (ETCD ou ETTD). Outre l’indication de
l’état de l’ETCD et de l’ETTD, la commande REJ dont le bit P a la valeur 1 peut être utilisée par l’ETTD pour
demander l’état de l’ETCD ou par l’ETCD pour demander l’état de l’ETTD.
2.3.4.5
Commande de mise en mode asynchrone symétrique (SABM)/commande de mise en mode
asynchrone symétrique étendu (SABME) (option au moment de l’abonnement)
La commande non numérotée SABM est utilisée pour placer l’ETTD ou l’ETCD appelé à l’état
transfert de l’information, dans le mode asynchrone symétrique (ABM), dans lequel tous les champs de
commande commande/réponse s’étendront sur une longueur de un octet.
La commande non numérotée SABME est utilisée pour placer l’ETCD ou l’ETTD appelé, dans le
mode asynchrone symétrique (ABM) en phase de transfert de l’information, dans laquelle tous les champs
de commande commande/réponse numérotés s’étendront sur une longueur de deux octets et les champs de
commande commande/réponse non numérotés s’étendront sur une longueur de un octet.
Il n’est pas permis d’inclure un champ d’information dans la commande SABM ou SABME.
L’émission d’une commande SABM/SABME indique la sortie d’un état d’occupation qui a été signalé
auparavant par l’émission d’une trame RNR par ce même poste (ETCD ou ETTD). L’ETCD ou l’ETTD confirme
l’acceptation de la commande SABM/SABME [fonctionnement de base (en modulo 8)/fonctionnement
étendu (en modulo 128)] en émettant dès que possible une réponse d’accusé de réception non numérotée
(UA). Suite à l’acceptation de cette commande, la variable d’état en émission V(S) et la variable d’état en
réception V(R) de l’ETTD ou de l’ETCD prennent la valeur 0.
Les trames I transmises auparavant, et pour lesquelles il n’y a pas eu d’accusé de réception
quand cette commande est exécutée, restent sans accusé de réception après l’établissement de la liaison. Il
incombe à une couche supérieure (couche paquets ou PML, par exemple) de récupérer la perte éventuelle
du contenu (paquets, par exemple) de telles trames I.
Remarque: Le mode de fonctionnement d’une liaison de données [mode de base (modulo 8) ou mode étendu
(modulo 128)] est fixé lors de l’abonnement et n’est modifié que moyennant une nouvelle procédure
d’abonnement.
2.3.4.6
Commande de déconnexion (DISC)
La commande non numérotée DISC est utilisée pour demander que prenne fin le mode établi
auparavant. Elle sert à informer l’ETTD ou l’ETCD récepteur de la commande DISC que l’ETCD ou l’ETTD
émetteur de la commande DISC suspend son fonctionnement. Il n’est pas permis d’inclure un champ
d’information dans la commande DISC. Avant d’actionner la commande, l’ETCD ou l’ETTD récepteur de
la commande DISC confirme l’acceptation de la commande DISC en émettant une réponse d’accusé de
réception non numérotée (UA). L’ETTD ou l’ETCD émetteur de la commande DISC passe à la phase de
déconnexion lorsqu’il reçoit cette réponse UA.
Édition 2009
SUPPLéMENT ii-13
II-13/13
Les trames I transmises auparavant, et pour lesquelles il n’y a pas eu d’accusé de réception
quand cette commande est exécutée, restent sans accusé de réception. Il incombe à une couche supérieure
(couche paquets ou PML, par exemple) de récupérer la perte éventuelle du contenu (paquets, par exemple)
de telles trames I.
2.3.4.7
Réponse d’accusé de réception non numérotée (UA)
La réponse non numérotée (UA) est utilisée par l’ETCD ou l’ETTD pour accuser réception et
accepter une commande de mise en mode. Les commandes de mise en mode reçues ne sont pas actionnées
avant que la réponse UA ne soit émise. L’émission d’une réponse UA indique la sortie d’un état d’occupation
qui a été signalé auparavant par l’émission d’une trame RNR sur le même poste (ETCD ou ETTD). Il n’est pas
permis d’inclure un champ d’information dans la réponse UA.
2.3.4.8
Réponse en mode déconnecté (DM)
La réponse non numérotée DM est utilisée pour signaler un état dans lequel l’ETTD ou l’ETCD
est logiquement déconnecté de la liaison de données et se trouve dans la phase de déconnexion. La réponse
DM peut être transmise, pour indiquer que l’ETCD ou l’ETTD est entré dans la phase de déconnexion, sans
avoir reçu une commande DISC ou, si elle est envoyée en réponse à la réception d’une commande de mise
en mode, pour informer l’ETTD ou l’ETCD que l’ETCD ou l’ETTD, respectivement, se trouve toujours en
phase de déconnexion mais n’est pas en mesure d’exécuter la commande de mise en mode. Il n’est pas
permis d’inclure un champ d’information dans la réponse DM.
Un ETTD ou un ETCD en phase de déconnexion contrôle les commandes reçues et réagit à
une commande SABM/SABME comme indiqué au § 2.4.4; il répond DM avec le bit F mis à 1 à toute autre
commande reçue dans laquelle le bit P est à l’état 1.
2.3.4.9
Réponse de rejet de trame (FRMR)
La réponse FRMR non numérotée est utilisée par l’ETTD ou l’ETCD pour indiquer une condition
d’erreur ne pouvant être corrigée par la retransmission de la trame identique; c’est-à-dire que l’une au moins
des conditions suivantes a résulté de la réception d’une trame sans erreur:
1)
2)
3)
4)
La réception d’un champ de commande de commande ou réponse non défini ou non mis en œuvre;
La réception d’une trame I dont le champ d’information dépasse la longueur maximale fixée;
La réception d’un N(R) non valable;
La réception d’une trame contenant un champ d’information, ce qui n’est pas permis, ou la réception
d’une trame de supervision ou d’une trame non numérotée de longueur incorrecte.
Un champ de commande non défini ou non mis en œuvre fait l’objet d’un quelconque des
codages de champ de commande qui ne sont pas identifiés dans les tableaux 5/X.25 et 6/X.25.
Un N(R) valable doit être situé entre le numéro de séquence en émission le plus faible N(S) de
la (des) trame(s) sans accusé de réception et la valeur actuelle de la variable d’état en émission de l’ETCD
incluse (ou la variable x interne actuelle si l’ETCD est dans la condition de reprise par temporisateur décrite
au § 2.4.5.9).
Suivant immédiatement le champ de commande, un champ d’information est joint à cette
réponse. Il consiste en trois ou cinq octets [respectivement, fonctionnement de base (modulo 8) ou
fonctionnement étendu (modulo 128)] qui indiquent la raison pour laquelle la réponse FRMR est émise. Son
format est décrit aux tableaux 7/X.25 et 8/X.25.
2.3.5
Signalisation et récupération de condition d’exception
Le présent § 2.3.5 décrit les procédures de récupération disponibles en cas d’apparition
d’erreur pour effectuer une récupération à la suite de la détection ou de l’apparition d’une condition
d’exception à la couche liaison de données. Les conditions d’exception décrites sont les situations
pouvant résulter d’erreurs de transmission, du mauvais fonctionnement d’un ETTD ou d’un ETCD, ou de
situations opérationnelles.
Édition 2009
II-13/14
Tableau 7/X.25 — Format du champ d’information de FRMR-LAPB — Fonctionnement de base (modulo 8)
Bits du champ d’information
1
2
3
4
5
6
7
8
Champ de commande de trame rejetée
9
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
0 V(S) C/R V(R) W XY
Z
0
0
0
0
— Le champ de commande de la trame rejetée est le champ de commande de la trame reçue qui a causé
le rejet de trame.
— V(S) a la valeur actuelle de la variable d’état en émission de l’ETTD ou de l’ETCD qui signale la condition de rejet (le bit 10 étant le bit de poids faible).
— C/R mis à 1 indique que le rejet de trame est une réponse; mis à 0, C/R signifie que le rejet de trame est
une commande.
— V(R) a la valeur actuelle de la variable d’état en réception de l’ETTD ou de l’ETCD qui signale la condition de rejet (le bit 14 étant le bit de poids faible).
— W mis à 1 indique que le champ de commande reçu et renvoyé (bits 1 à 8) n’est pas défini ou n’est pas
mis en œuvre.
— X mis à 1 indique que le champ de commande reçu et renvoyé (bits 1 à 8) a été considéré comme non
valable car la trame contenait un champ d’information, ce qui n’est pas permis avec cette trame, ou que
la trame était une trame de supervision ou une trame non numérotée de longueur incorrecte. Lorsque
ce bit est mis à 1, le bit W doit aussi être mis à 1.
—Y mis à 1 indique que le champ d’information reçu dépassait la capacité maximale fixée.
— Z mis à 1 indique que le champ de commande reçu et renvoyé (bits 1 à 8) contenait un numéro N(R)
non valable.
Remarque: Les bits 9 et 21 à 24 doivent être mis à 0.
Tableau 8/X.25 — Format du champ d’information de FRMR-LAPB — Fonctionnement étendu (modulo 128)
Bits du champ d’information
1 à 16
17
18 à 24
25
26 à 32
33
34
35
36
37
38
39
40
Champ de
commande de
la trame rejetée
0
V(S)
C/R
V(R)
W
XY
Z
0
0
0
0
— Le champ de commande de la trame rejetée est le champ de commande de la trame reçue qui a causé
le rejet de trame. Lorsque la trame rejetée est une trame non numérotée, le champ de commande de la
trame rejetée occupe la place des bits 1 à 8, les bits 9 à 16 étant mis à 0.
— V(S) a la valeur actuelle de la variable d’état en émission de l’ETTD ou de l’ETCD qui signale la condition de rejet (le bit 18 étant le bit de poids faible).
— C/R mis à 1 indique que le rejet de trame est une réponse; mis à 0, C/R signifie que le rejet de trame est
une commande.
— V(R) a la valeur actuelle de la variable d’état en réception de l’ETTD ou de l’ETCD qui signale la condition de rejet (le bit 26 étant le bit de poids faible).
— W mis à 1 indique que le champ de commande reçu et renvoyé (bits 1 à 16) n’est pas défini ou n’est pas
mis en œuvre.
— X mis à 1 indique que le champ de commande reçu et renvoyé (bits 1 à 16) a été considéré comme non
valable car la trame contenait un champ d’information, ce qui n’est pas permis avec cette trame, ou que
la trame était une trame de supervision ou une trame non numérotée de longueur incorrecte. Lorsque
ce bit est mis à 1, le bit W doit aussi être mis à 1.
—Y mis à 1 indique que le champ d’information reçu dépassait la capacité maximale fixée.
— Z mis à 1 indique que le champ de commande reçu et renvoyé (bits 1 à 16) contenait un numéro N(R)
non valable.
Remarque: Les bits 17 et 37 à 40 doivent être mis à 0.
Édition 2009
SUPPLéMENT ii-13
2.3.5.1
II-13/15
état d’occupation
L’état d’occupation résulte du fait qu’un ETCD ou ETTD est temporairement incapable de
continuer à recevoir des trames I par suite de contraintes internes, par exemple, une limitation de taille des
mémoires tampons de réception. Dans ce cas, une trame de supervision RNR est émise par l’ETTD ou l’ETCD
occupé. L’ETTD ou l’ETCD occupé peut émettre des trames I en attente d’émission avant ou après la trame
RNR.
L’indication de la fin de l’état d’occupation est donnée par l’émission d’une trame UA (seulement
en réponse à une commande SABM/SABME), RR, REJ ou SABM/SABME (modulo 8/modulo 128).
2.3.5.2
Erreur sur le numéro de séquence N(S)
Le champ d’information de toute trame I reçue dont le numéro N(S) n’est pas égal à la variable
d’état à la réception V(R) est mis au rebut.
Une condition d’exception due au numéro de séquence N(S) apparaît lorsque le récepteur
reçoit une trame I, qui porte un numéro de séquence N(S) non égal à la variable d’état à la réception V(R)
du récepteur. Le récepteur n’accuse pas la réception (incrémente sa variable d’état à la réception) de la
trame I qui a causé l’erreur de séquence, ni d’aucune autre trame I qui pourrait la suivre, avant d’avoir reçu
une trame I portant le numéro de séquence correct N(S).
Un ETCD ou ETTD qui reçoit une ou plusieurs trames I valables comportant des erreurs de
séquence ou des trames de supervision suivantes (RR, RNR et REJ) accepte l’information de commande
contenue dans le champ N(R) et le bit P ou F afin d’effectuer les fonctions de supervision de la liaison de
données; par exemple, recevoir des accusés de réception de trames I précédemment émises et provoquer la
réponse de I’ETTD ou l’ETCD (bit P mis à 1).
Les moyens spécifiés aux § 2.3.5.2.1 et 2.3.5.2.2 seront disponibles pour provoquer la
retransmission d’une trame I perdue ou d’une trame I erronée à la suite de l’apparition d’une erreur de
séquence N(S).
2.3.5.2.1
Récupération au moyen de REJ
La trame de rejet REJ est utilisée par un ETCD ou par un ETTD destinataire pour marquer le
début d’une récupération (retransmission) à la suite de la détection d’une erreur de séquence N(S).
à un instant donné, il ne peut s’établir qu’une seule condition d’exception “REJ envoyé” par
un ETCD ou un ETTD vers un ETTD ou un ETCD dans chaque sens de transmission de la liaison de données.
Une condition d’exception “REJ envoyé” est annulée lorsque la trame I demandée est reçue.
Un ETCD ou un ETTD recevant la trame REJ déclenche une transmission (ou une retransmission)
séquentielle de trames I en débutant par la trame I indiquée par le numéro N(R) contenu dans la trame REJ.
Les trames retransmises peuvent contenir un N(R) et un bit P mis à jour et de ce fait différents de ceux des
trames I émises à l’origine.
2.3.5.2.2
Reprise par temporisateur
Si, à cause d’une erreur de transmission, un ETTD ou un ETCD ne reçoit pas (ou bien reçoit et
met au rebut) une trame I unique, ou la ou les dernière(s) trame(s) I d’une séquence de trames I, il ne peut
pas déceler une condition d’erreur de séquence N(S), il n’émet donc pas de trame REJ. L’ETCD ou l’ETTD
qui émet une ou des trames I dont il ne reçoit pas d’accusé de réception entreprend, à l’expiration d’un
délai spécifié par le système (voir les § 2.4.5.1 et 2.4.5.9), une action de récupération appropriée afin de
déterminer à partir de quelle trame I la retransmission doit commencer. La (les) trame(s) retransmise(s) peut
(peuvent) contenir un N(R) et un bit P mis à jour et donc différents de ceux de la (des) trame(s) I émise(s) à
l’origine.
2.3.5.3
Trame non valable
Toute trame non valable est ignorée et aucune action n’est entreprise à la suite de sa réception.
Une trame non valable se définit comme une trame:
a)Qui n’est pas délimitée par deux fanions;
b)Qui, dans le fonctionnement de base (modulo 8), contient moins de 32 bits entre les fanions; dans le
fonctionnement étendu (modulo 128), qui contient moins de 40 bits entre les fanions de trame qui
Édition 2009
II-13/16
contiennent des numéros de séquence ou 32 bits entre les fanions de trame qui ne contiennent pas de
numéro de séquence;
c)Qui contient une erreur signalée par la séquence de contrôle de trame (FCS); ou
d)Qui contient une adresse autre que A ou B (pour le fonctionnement par liaison unique) ou autre que C
ou D (pour le fonctionnement multiliaison).
S’agissant des réseaux fonctionnant par octets, une méthode de détection de non-alignement
des octets peut consister, à la couche liaison de données, à ajouter le contrôle de validité de trame suivant:
le nombre de bits entre les fanions d’ouverture et de fermeture, à l’exclusion des bits insérés pour la
transparence, doit correspondre à un nombre entier d’octets, faute de quoi la trame est considérée comme
non valable.
2.3.5.4
état de rejet de trame
Un état de rejet de trame est établi à la réception d’une trame sans erreur, mais comportant une
des conditions indiquées au § 2.3.4.9.
à l’ETCD ou à l’ETTD, cet état d’exception de rejet de trame est indiqué par une réponse
FRMR pour action appropriée, respectivement, par l’ETTD ou l’ETCD. Une fois que l’ETCD a établi cet état
d’exception, aucune trame I supplémentaire n’est acceptée avant annulation de la condition par l’ETTD,
si ce n’est dans te cas de l’examen du bit P. La réponse FRMR peut être répétée à chaque occasion (comme
spécifié au § 2.4.7.3) jusqu’à ce que la récupération soit effectuée par l’ETTD ou que l’ETCD commence à
effectuer sa propre récupération si l’ETTD ne répond pas.
2.3.5.5
état de voie inactive de durée excessive sur voie entrante
En cas de détection de l’état inactif (voir le § 2.2.12.2) sur la voie entrante, l’ETCD attend
pendant une temporisation T3 (voir le § 2.4.8.3) sans prendre aucune mesure, en attendant la détection
d’un retour à l’état de voie active (c’est-à-dire la détection d’au moins une séquence de fanion). Après ce
délai T3, l’ETCD signale à la couche supérieure (par exemple, la couche paquets ou la PML) l’état de voie
inactive de durée excessive, mais il ne prend aucune mesure qui empêcherait l’ETTD de rétablir la liaison de
données au moyen des procédures normales.
Remarque: Les autres mesures à prendre par l’ETCD à la couche liaison de données, à l’expiration de la
temporisation T3, doivent faire l’objet d’un complément d’étude.
2.4Description de la procédure LAPB
2.4.1
Modes de fonctionnement LAPB de base et étendu
Selon le choix du système fait par l’ETTD lors de l’abonnement, l’ETCD assure soit un
fonctionnement modulo 8 (de base), soit un fonctionnement modulo 128 (étendu). Pour passer du mode
de base au mode étendu, ou vice versa dans l’ETCD, l’ETTD doit obtenir un nouvel abonnement pour le
mode désiré; cette modification n’est pas automatique.
Le tableau 5/X.25 indique le format des champs de commande des commandes et réponses
utilisés en mode de base (modulo 8). La commande de mise en mode utilisée pour initialiser (établir) ou
réinitialiser le mode de base est la commande SABM. Le tableau 6/X.25 indique le format des champs de
commande des commandes et réponses utilisés en mode étendu (modulo 128). La commande de mise en
mode utilisée pour initialiser (établir) ou réinitialiser le mode étendu est la commande SABME.
2.4.2
Procédure LAPB d’adressage
Le champ d’adresse identifie une trame comme étant une commande ou une réponse. Une
trame de commande contient l’adresse de l’ETCD ou de l’ETTD auquel la commande est envoyée. Une
trame de réponse contient l’adresse de l’ETCD ou de l’ETTD qui envoie la trame.
Afin de pouvoir faire la distinction entre l’exploitation par liaison unique et l’exploitation
facultative multiliaison, à des fins de diagnostic et/ou de maintenance, des codages différents de paires
d’adresses sont attribués aux liaisons de données multiliaison et aux liaisons de données par liaison unique.
Les trames qui contiennent des commandes émises par l’ETCD vers l’ETTD contiennent
l’adresse A pour le fonctionnement par liaison unique et l’adresse C pour le fonctionnement multiliaison.
Édition 2009
II-13/17
SUPPLéMENT ii-13
Les trames qui contiennent des réponses émises par l’ETCD vers l’ETTD contiennent l’adresse
B pour le fonctionnement par liaison unique et l’adresse D pour le fonctionnement multiliaison.
Les trames qui contiennent des commandes émises par l’ETTD vers l’ETCD contiennent
l’adresse B pour le fonctionnement par liaison unique et l’adresse D pour le fonctionnement multiliaison.
Les trames qui contiennent les réponses émises par l’ETTD vers l’ETCD contiennent l’adresse A
pour le fonctionnement par liaison unique et l’adresse C pour le fonctionnement multiliaison.
Ces adresses sont codées comme suit:
Adresse
1
2
3
4
5
6
7
8
A
B
1
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
Fonctionnement
C
multiliaisonD
1
1
1
1
1
1
1
0
0
0
0
0
0
0
0
0
Fonctionnement par
liaison unique
Remarque: L’ETCD met au rebut les trames reçues avec une adresse autre que A ou B (fonctionnement par
liaison unique), ou C ou D (fonctionnement multiliaison).
2.4.3
Procédure LAPB d’utilisation du bit P/F
Lorsque l’ETCD ou l’ETTD reçoit une trame de commande SABM/SABME ou DISC, une trame
de commande de supervision ou une trame I dont le bit P est mis à 1, il doit mettre à 1 le bit F dans la
prochaine trame de réponse qu’il émet.
La trame de réponse fournie par l’ETCD à une commande SABM/SABME ou DISC, dont le bit
P est mis à 1, est une réponse UA (ou DM) dont le bit F est mis à 1. La trame de réponse fournie par l’ETCD
en réponse à une trame I dont le bit P est mis à 1, reçue lors de la phase de transfert d’information, est une
réponse RR, REJ, RNR ou FRMR avec le bit F mis à 1. La trame de réponse fournie par l’ETCD à une trame
de commande de supervision, dont le bit P est mis à 1, reçue lors de la phase de transfert d’information,
est une réponse RR, REJ, RNR ou FRMR avec le bit F mis à 1. La trame de réponse fournie par l’ETCD à une
trame I ou à une trame de supervision dont le bit est mis à 1, reçue lors de la phase de déconnexion, est une
réponse DM avec le bit F mis à 1.
§ 2.4.5.9).
Le bit P peut être utilisé par l’ETCD dans les conditions de reprise par temporisateur (voir le
Remarque:D’autres utilisations du bit P par l’ETCD feront l’objet d’études ultérieures.
2.4.4
Procédure LAPB d’établissement et déconnexion de la liaison de données
2.4.4.1
établissement de la liaison de données
L’ETCD indique qu’il est capable d’établir la liaison en émettant des fanions successifs (état de
voie active).
L’ETTD ou l’ETCD peut déclencher l’établissement de la liaison de données. Auparavant, l’ETCD
ou l’ETTD peut déclencher la déconnexion de la liaison de données (voir le § 2.4.4.3) afin de s’assurer que
l’ETCD et l’ETTD sont dans la même phase. L’ETCD peut également émettre une réponse DM non demandée
pour inviter l’ETTD à déclencher l’établissement de la liaison de données.
L’ETTD commence à établir la liaison de données en émettant une commande SABM/SABME
vers l’ETCD. Si, ayant reçu correctement une commande SABM/SABME, l’ETCD estime qu’il peut passer
à la phase de transfert de l’information, il envoie une réponse UA à l’ETTD, remet ses variables d’état à
l’émission V(S) et à la réception V(R) à zéro, et il considère que la liaison de données est établie. Si, ayant
reçu une commande SABM/SABME correcte, l’ETCD estime qu’il ne peut pas passer à la phase de transfert de
l’information, il envoie une réponse DM à l’ETTD pour refuser de déclencher l’établissement de la liaison de
données et considère que la liaison de données n’est pas établie. Afin d’éviter toute interprétation erronée
de la réponse DM reçue, il est proposé que l’ETTD envoie toujours sa commande SABM/SABME avec le
bit P mis à 1. C’est, en effet, le seul moyen de faire la distinction entre une réponse DM qui vise à refuser
Édition 2009
II-13/18
l’établissement d’une liaison de données et une réponse DM qui est émise spontanément à titre de demande
de commande d’établissement de mode (comme décrit au § 2.4.4.4.2).
L’ETCD déclenche l’établissement de la liaison de données en envoyant une commande SABM/
SABME à l’ETTD et en armant son temporisateur T1 qui lui permet de savoir si l’attente d’une réponse
n’est pas trop longue (voir le § 2.4.8.1). à la réception d’une réponse UA de l’ETTD, l’ETCD remet à zéro
ses variables d’état à l’émission V(S) et à la réception V(R), arrête son temporisateur T1 et considère que la
liaison de données est établie. à la réception d’une réponse DM de l’ETTD, pour refuser le déclenchement
de l’établissement de la liaison de données, l’ETCD arrête son temporisateur T1 et considère que la liaison
de données n’est pas établie.
Après avoir envoyé la commande SABM/SABME, l’ETCD ignore et met au rebut toutes les
trames sauf les commandes SABM/SABME et DISC et les réponses UA et DM reçues en provenance de
l’ETTD. La réception d’une commande SABM/SABME ou DISC envoyée par l’ETTD provoque un cas de
collision qui est résolu au § 2.4.4.5. Les trames autres que les réponses UA et DM envoyées en réponse à une
commande SABM/SABME ou DISC reçue sont envoyées seulement quand la liaison de données est établie
et qu’il n’existe pas de commande SABM/SABME en instance.
Après que l’ETCD a envoyé la commande SABM/SABME, si une réponse UA ou DM correcte n’est
pas reçue, le temporisateur T1 arrive en fin de course dans l’ETCD. Celui-ci émet à nouveau la commande
SABM/SABME et redéclenche le temporisateur T1. Après N2 transmissions successives de la commande
SABM/SABME par l’ETCD, une action appropriée de récupération est entreprise à une couche supérieure. La
valeur de N2 est définie au § 2.4.8.4.
2.4.4.2
Phase de transfert de l’information
Après avoir transmis la réponse UA à la commande SABM/SABME ou reçu la réponse UA à une
commande SABM/SABME, l’ETCD accepte et transmet des trames I et de supervision conformément aux
procédures décrites au § 2.4.5.
Quand il reçoit une commande SABM/SABME alors qu’il se trouve à la phase de transfert de
l’information, l’ETCD applique la procédure de réinitialisation de la liaison de données décrite au § 2.4.7.
2.4.4.3
Déconnexion de la liaison de données
Pour déclencher la déconnexion de la liaison de données, l’ETTD transmet à l’ETCD une
commande DISC. Quand il reçoit, pendant la phase de transfert de l’information, une commande DISC
correcte, l’ETCD envoie une réponse UA et passe à la phase de déconnexion. Quand il reçoit une commande
DISC correcte pendant la phase de déconnexion, l’ETCD envoie une réponse DM et reste dans la phase de
déconnexion. Afin d’éviter une interprétation erronée de la réponse DM reçue, il est suggéré que l’ETTD
envoie toujours la commande DISC avec le bit P mis à 1. En effet, c’est le seul moyen pour faire une
distinction entre une réponse DM indiquant que l’ETCD est déjà à la phase de déconnexion et une réponse
DM qui est émise spontanément pour demander une commande de mise en mode (comme décrit au
§ 2.4.4.4.2).
Pour déclencher la déconnexion de la liaison de données, l’ETCD transmet à l’ETTD une
commande DISC et arme son temporisateur T1 (voir le § 2.4.8.1). à la réception d’une réponse UA de l’ETTD,
l’ETCD arrête son temporisateur T1 et passe à la phase de déconnexion. à la réception d’une réponse DM
de l’ETTD indiquant que l’ETTD est déjà à la phase de déconnexion, l’ETCD arrête son temporisateur T1 et
passe à la phase de déconnexion.
Après avoir envoyé la commande DISC, l’ETCD ignore et met au rebut toutes les trames,
à l’exception des commandes SABM/SABME et DISC, et des réponses UA et DM reçues en provenance
de l’ETTD. La réception d’une commande SABM/SABME ou DISC émise par l’ETTD provoque un cas de
collision, dont la solution est indiquée au § 2.4.4.5.
Après que l’ETCD a envoyé la commande DISC, si une réponse UA ou DM correcte n’est pas
reçue, le temporisateur T1 arrive en fin de course dans l’ETCD. L’ETCD envoie de nouveau la commande
DISC et réarme le temporisateur T1. Après N2 transmissions de la commande DISC par l’ETCD, une action
de récupération appropriée est engagée à une couche supérieure. La valeur de N2 est définie au § 2.4.8.4.
2.4.4.4
Phase de déconnexion
2.4.4.4.1
Après avoir reçu une commande DISC en provenance de l’ETTD et renvoyé une réponse UA à
l’ETTD, ou après avoir reçu la réponse UA à une commande DISC émise, l’ETCD entre la phase de déconnexion.
Édition 2009
SUPPLéMENT ii-13
II-13/19
Dans cette phase, l’ETCD peut initialiser l’établissement de la liaison de données. Au cours
de la phase de déconnexion, l’ETCD réagit à la réception d’une commande SABM/SABME, comme il est
indiqué au § 2.4.4,1, et émet une réponse DM lorsqu’il reçoit une commande DISC. Lorsqu’il reçoit toute
autre trame de commande (définie, non définie ou non mise en œuvre) dans laquelle le bit P est mis à 1,
l’ETCD émet une réponse DM dont le bit F est mis à 1. L’ETCD ne tient pas compte des autres trames reçues
pendant la phase de déconnexion.
2.4.4.4.2
Lorsque l’ETCD entre dans la phase de déconnexion après avoir détecté des conditions d’erreur
(énumérées dans le § 2.4.6) ou à la suite d’un mauvais fonctionnement interne, il peut l’indiquer en émettant
une réponse DM au lieu d’une commande DISC. En pareil cas, l’ETCD émet la réponse DM et arme son
temporisateur T1 (voir le § 2.4.8.1).
Si le temporisateur T1 arrive en fin de course avant la réception d’une commande SABM/
SABME ou DISC en provenance de l’ETTD, l’ETCD réémet la réponse DM et redéclenche le temporisateur
T1. Après N2 transmissions de la réponse DM, l’ETCD demeure dans la phase de déconnexion et une action
appropriée de récupération commence. La valeur de N2 est définie au § 2.4.8.4.
Après une défaillance interne, l’ETCD peut aussi, soit déclencher une procédure de réinitialisation de la liaison de données (voir le § 2.4.7), soit déconnecter la liaison de données (voir le § 2.4.4.3) avant
de déclencher une procédure d’établissement de la liaison de données (voir le § 2.4.4.1).
2.4.4.5
Collision de commandes non numérotées
Les cas de collision seront résolus comme suit:
2.4.4.5.1
Si les commandes non numérotées émises et reçues sont les mêmes, l’ETTD et l’ETCD émettent
chacun une réponse UA à la première occasion. L’ETCD entre dans la phase indiquée soit:
1) Après avoir reçu la réponse UA, ou
2) Après avoir envoyé la réponse UA, ou encore
3) Après attente par temporisation de la réponse UA après envoi d’une réponse UA.
Dans le cas 2) ci-dessus, l’ETCD accepte une réponse UA subséquente à la commande de
mise en mode qu’il a envoyée sans causer de condition d’exception si elle parvient avant la fin de la
temporisation.
2.4.4.5.2
Si les commandes non numérotées émises et reçues sont différentes, l’ETTD et l’ETCD entrent
chacun dans la phase de déconnexion et envoient une réponse DM à la première occasion.
2.4.4.6
Collision d’une réponse DM avec une commande SABM/SABME ou DISC
Quand l’ETCD ou l’ETTD émet une réponse DM comme une réponse non demandée,
respectivement à l’ETTD ou à l’ETCD, pour lui demander d’émettre une commande de mise en mode décrite
au § 2.4.4.4, il peut se produire une collision entre une commande SABM/SABME ou DISC et la réponse DM
non demandée. Afin d’éviter une interprétation erronée de la réponse DM reçue, l’ETTD envoie toujours sa
commande SABM/SABME ou DISC avec le bit P mis à 1.
2.4.4.7
Collision de réponses DM
Un conflit peut se produire quand l’ETCD et l’ETTD envoient tous deux une réponse DM pour
demander une commande de mise en mode. En pareil cas, l’ETTD émet une commande SABM/SABME pour
résoudre ce conflit.
2.4.5
Procédures de transfert de l’information (applicables au LAPB)
Les procédures relatives à la transmission des trames I dans les deux sens pendant la phase de
transfert d’information sont décrites ci-après.
Dans les paragraphes qui suivent, la relation “est supérieure d’une unité à” se réfère à une série
faite de séquences continuellement répétées; ce qui signifie que, si 7 est supérieur à 6 d’une unité, 0 est aussi
supérieur à 7 d’une unité dans une série module 8 et que, si 127 est supérieur à 126 d’une unité dans une
série modulo 8 et que si 127 est supérieur à 126 d’une unité, 0 est aussi supérieur à 127 d’une unité dans une
série modulo 128.
Édition 2009
II-13/20
2.4.5.1
émission d’une trame I
Lorsque l’ETCD a une trame I à émettre (c’est-à-dire une trame I qui n’a encore jamais été
transmise ou qui doit être retransmise comme décrit au § 2.4.5.6), il l’émet en donnant au numéro N(S) la
valeur actuelle de sa variable d’état en émission V(S), et au numéro N(R) la valeur actuelle de sa variable
d’état en réception V(R). à la fin de l’émission de la trame I, il incrémente sa variable d’état en émission
V(S) d’une unité.
Si le temporisateur T1 n’est pas en marche au moment de la transmission d’une trame I, l’ETCD
arme celui-ci.
Si la variable d’état en émission V(S) est égale à la dernière valeur de N(R) reçue augmentée de
k (k étant le nombre maximal de trames I en anticipation — voir le § 2.4.8.6), l’ETCD n’envoie plus aucune
nouvelle trame I, mais peut réémettre une trame I ainsi qu’il est décrit au § 2.4.5.6 ou 2.4.5.9.
Lorsque l’ETCD est à l’état d’occupation, il peut toujours émettre des trames I, à condition que
l’ETTD ne soit pas à l’état d’occupation. Lorsque l’ETCD est à l’état de rejet de trame, il cesse d’émettre des
trames I.
2.4.5.2
Réception d’une trame I
2.4.5.2.1
Lorsque l’ETCD n’est pas à l’état d’occupation et reçoit une trame I valable, dont le numéro de
séquence à l’émission N(S) est égal à la variable d’état en réception V(R) de l’ETCD, celui-ci accepte le champ
d’information de cette trame, incrémente d’une unité sa variable d’état en réception V(R) et agit ainsi:
a) Si l’ETCD n’est toujours pas à l’état d’occupation:
i)Dans le cas où l’ETCD a une trame I à transmettre, il peut se comporter conformément au § 2.4.5.1,
et accuser réception de la trame I reçue, en donnant au numéro N(R) contenu dans le champ de
commande de la prochaine trame I émise la valeur de la variable d’état à la réception V(R) de
l’ETCD. L’ETCD peut aussi accuser réception de la trame I reçue en émettant un RR dont le numéro
N(R) est égal à la valeur de la variable d’état à la réception V(R) de l’ETCD;
ii) Si l’ETCD n’a pas de trame I à émettre, il émet un RR dont le numéro N(R) est égal à la valeur de la
variable d’état à la réception V(R) de l’ETCD;
b) Si l’ETCD est maintenant à l’état d’occupation, il transmet une trame RNR dont le numéro N(R) est égal
à la valeur de la variable d’état à la réception V(R) de l’ETCD (voir le § 2.4.5.8).
2.4.5.2.2
Lorsque l’ETCD est à l’état d’occupation, il peut ne pas tenir compte du champ d’information
contenu dans toute trame I reçue.
2.4.5.3
Réception de trames non valables
Lorsque l’ETCD reçoit une trame non valable (voir le § 2.3.5.3), cette trame est mise au rebut.
2.4.5.4
Réception de trames I hors séquence
Lorsque l’ETCD reçoit une trame I valable dont le numéro de séquence à l’émission N(S) est
incorrect, c’est-à-dire dont la valeur n’est pas égale à celle de la variable d’état à la réception V(R) actuelle de
l’ETCD, celui-ci met au rebut le champ d’information contenu dans la trame I et émet une trame REJ dont
le numéro N(R) est supérieur d’une unité au numéro N(S) de la dernière trame I correcte reçue. La trame REJ
est une commande dont le bit P est mis à 1, si l’envoi de la demande de retransmission doit faire l’objet d’un
accusé de réception; dans le cas contraire, la trame REJ peut être une commande ou une réponse. L’ETCD
met alors au rebut le champ d’information de toutes les trames I reçues tant qu’il n’a pas reçu la trame I
correcte qu’il attend. Lorsqu’il reçoit la trame I attendue, l’ETCD accuse réception de cette trame comme
décrit au § 2.4.5.2. L’ETCD utilise l’information donnée par le numéro N(R) et le bit P des trames I au rebut,
comme décrit au § 2.3.5.2.
2.4.5.5
Réception d’un accusé de réception
Lorsqu’il reçoit correctement une trame I ou une trame de supervision (RR, RNR ou REJ), même
s’il se trouve à cet instant à l’état occupé, l’ETCD considère que le numéro N(R) contenu dans cette trame
accuse réception de toutes les trames I qu’il a émises dont le numéro N(S) est inférieur ou égal au numéro
N(R) reçu moins un. L’ETCD réarme son temporisateur T1 quand il reçoit correctement une trame I ou
Édition 2009
SUPPLéMENT ii-13
II-13/21
une trame de supervision avec un numéro N(R) supérieur au dernier numéro N(R) reçu (en fait, accusant
réception de quelques trames I), ou une trame REJ avec un numéro N(R) égal au dernier numéro N(R)
reçu.
Si le temporisateur T1 a été arrêté par la réception d’une trame I, RR ou RNR et s’il reste
en instance des trames I qui n’ont pas encore fait l’objet d’un accusé de réception, l’ETCD redéclenche
le temporisateur T1. Si celui-ci arrive alors en fin de course, l’ETCD suit la procédure de reprise (voir le
§ 2.4.5.9) en ce qui concerne les trames I sans accusé de réception. Si le temporisateur T1 a été arrêté par la
réception d’une trame REJ, l’ETCD suit les procédures de retransmission du § 2.4.5.6.
2.4.5.6
Réception d’une trame REJ
Lorsqu’il reçoit une trame REJ, l’ETCD donne à sa variable d’état à l’émission V(S) la valeur
du numéro N(R) reçu dans le champ de commande de la trame REJ. Il émet la trame I correspondante dès
qu’elle est prête ou bien la retransmet conformément à la procédure décrite au § 2.4.5.1. La (re)transmission
est conforme au paragraphe ci-après:
i) Si l’ETCD est en train d’émettre une commande ou une réponse de supervision au moment où il reçoit
la trame REJ, il achève cette émission avant de commencer l’émission de la trame I demandée;
ii) Si l’ETCD est en train d’émettre une commande ou une réponse non numérotée au moment où il reçoit
la trame REJ, il ne tient pas compte de la demande de retransmission;
iii) Si l’ETCD est en train d’émettre une trame I au moment où il reçoit la trame REJ, il peut abandonner
l’émission de la trame I et commencer l’émission de la trame I demandée immédiatement après cet
abandon;
iv) Si l’ETCD n’est pas en train d’émettre une trame au moment où il reçoit la trame REJ, il commence
immédiatement l’émission de la trame I demandée.
Dans tous les cas, si d’autres trames I pour lesquelles il n’y a pas encore eu accusé de réception
ont déjà été émises à la suite de la trame I demandée par la trame REJ, l’ETCD retransmet ces trames I à la
suite de la trame I demandée. D’autres trames I qui n’ont pas encore été émises peuvent l’être à la suite des
trames I retransmises.
Si la trame REJ a été reçue de l’ETTD comme une commande dont le bit P est mis à 1, l’ETCD
transmet une réponse RR, RNR ou REJ dont le bit F est mis à 1 avant de transmettre, ou de retransmettre, la
trame I correspondante.
2.4.5.7
Réception d’une trame RNR
Après avoir reçu une trame RNR dont le numéro N(R) accuse réception de toutes les trames
précédemment émises, l’ETCD arrête le temporisateur T1 et peut alors transmettre une trame I — avec le
bit P mis à 0 — dont le numéro de séquence à l’émission est égal au N(R) indiqué dans la trame RNR, tout
en redéclenchant le temporisateur. Après avoir reçu une trame RNR dont le numéro N(R) indique une
trame précédemment émise, l’ETCD n’émet ni ne réémet aucune trame I, le temporisateur I étant déjà en
fonction. Dans les deux cas, si la temporisation T1 expire avant la réception de l’indication de sortie de l’état
d’occupation, l’ETCD suit la procédure indiquée au § 2.4.5.9. De toute façon, l’ETCD n’émet aucune autre
trame I tant qu’il n’a pas reçu une trame RR ou REJ, ou avant que soit achevée la procédure de rétablissement
de la liaison.
Autre possibilité: Après avoir reçu une trame RNR, l’ETCD peut attendre pendant un certain
délai (par exemple, la durée de la temporisation T1), émettre ensuite une trame de commande de supervision
(RR, RNR ou REJ) dont le bit P est mis à 1, et déclencher le temporisateur T1 afin de déterminer s’il y a eu un
changement quelconque dans l’état de réception de l’ETTD. L’ETTD répond au bit P mis à 1 par une trame
de réponse de supervision (RR, RNR ou REJ) dont le bit F est mis à 1, pour indiquer que l’état d’occupation
continue (RNR) ou qu’il est terminé (RR ou REJ). à la réception de la réponse de l’ETTD, le temporisateur T1
est arrêté.
1) Si la réponse est une réponse RR ou REJ, l’état d’occupation est supprimé et l’ETCD peut émettre des
trames I en commençant par la trame I identifiée par le N(R) dans la trame de réponse reçue.
2) Si la réponse est une réponse RNR, l’état d’occupation existe toujours et l’ETCD, après un certain délai
(par exemple, la durée de la temporisation T1), répète sa demande relative à l’état de réception de
l’ETTD.
Édition 2009
II-13/22
Si la temporisation T1 expire avant la réception de la réponse concernant cet état, le processus
de demande est répété. Après l’échec de N2 tentatives pour obtenir une réponse sur l’état (c’est-à-dire
si la temporisation T1 expire N2 fois), l’ETCD entreprend la procédure de réinitialisation de la liaison
de données décrite au § 2.4.7.2, ou il transmet une réponse DM pour demander à l’ETTD d’engager la
procédure d’établissement de la liaison de données décrite au § 2.4.4.1 et passe à la phase de déconnexion.
La valeur de N2 est définie au § 2.4.8.4.
Si, à un moment quelconque pendant le processus de demande, une trame RR ou REJ non
requise est reçue de l’ETTD, elle est considérée comme une indication de sortie de l’état d’occupation. Si
la trame RR ou REJ non requise est une trame de commande dont le bit P est mis à 1, la trame de réponse
appropriée dont le bit F est mis à 1 doit être transmise avant que l’ETCD puisse rétablir la transmission
des trames I. Si la temporisation T1 est en cours, l’ETCD attend la réponse de non-occupation dont le bit
F est mis à 1, ou bien il attend que la temporisation T1 expire et il peut alors recommencer le processus
de demande afin de procéder à un échange réussi de bits P/F ou reprendre la transmission des trames I en
commençant par la trame I identifiée par le numéro N(R) de la trame RR ou REJ reçue.
2.4.5.8
ETCD à l’état d’occupation
Quand l’ETCD passe à l’état d’occupation, il transmet une trame RNR dès qu’il le peut.
La trame RNR est une trame de commande dont le bit P est mis à 1 si l’envoi d’une indication d’état
d’occupation avec accusé de réception est requis; dans le cas contraire, la trame RNR peut être une trame
de réponse. à l’état d’occupation, l’ETCD accepte et traite les trames de supervision, accepte et traite le
contenu des champs N(R), des trames I et envoie une réponse RNR dont le bit F est mis à 1 à la réception
d’une trame de commande, de supervision ou I dont le bit P est mis à 1. Pour supprimer l’état “ETCD
occupé”, l’ETCD émet une trame, REJ ou RR, dont le numéro N(R) a la valeur actuelle de la variable d’état
à la réception V(R), selon qu’il a mis ou non au rebut les champs d’information des trames I correctement
reçues. La trame REJ ou la trame RR sont des trames de commande dont le bit P est mis à 1, si l’envoi
avec accusé de réception d’une indication de passage de l’état d’occupation à l’état de non-occupation
est nécessaire; dans le cas contraire, la trame REJ ou RR peut être une trame de réponse ou une trame de
commande.
2.4.5.9
Attente d’accusé de réception
L’ETCD tient à jour une variable interne représentant les tentatives de transmission. Celle-ci est
remise à 0 lorsque l’ETCD envoie une réponse UA, reçoit une réponse UA, une réponse ou une commande
RNR, ou bien lorsque l’ETCD reçoit correctement une trame I ou une trame de supervision dont le numéro
N(R) est supérieur au dernier numéro N(R) reçu (accusant effectivement réception de trames I ayant leur
accusé de réception en suspens).
Si le temporisateur T1 arrive en fin de course alors qu’il attend de l’ETTD l’accusé de réception
d’une trame I qui a été émise, l’ETCD passe à l’état de reprise par temporisateur, ajoute une unité à sa variable
du compteur de transmissions, et donne à une variable interne x la valeur actuelle de sa variable d’état à
l’émission V(S). L’ETCD redéclenche alors le temporisateur T1, donne à sa variable d’état à l’émission V(S)
la valeur du dernier numéro N(R) reçu en provenance de l’ETTD et réémet la trame I correspondante avec
le bit P mis à 1, ou émet une trame de commande de supervision appropriée (RR, RNR ou REJ) avec le bit P
mis à 1.
L’état de reprise par temporisateur est annulé lorsque l’ETCD reçoit une trame de supervision
correcte, avec le bit F mis à 1.
Si, pendant qu’il est à l’état de reprise par temporisateur, l’ETCD reçoit correctement une
trame de supervision dont le bit F est mis à 1 et dont le numéro N(R) appartient à l’intervalle qui va de
sa valeur courante de variable d’état à l’émission V(S) jusqu’à la valeur x incluse, l’ETCD annule l’état de
reprise par temporisateur (et arrête le temporisateur T1) et positionne sa variable d’état à l’émission V(S)
à la valeur du N(R) reçu; il peut alors reprendre la transmission ou la retransmission de trames I selon le
cas.
Si, pendant qu’il est à l’état de reprise par temporisateur, l’ETCD reçoit correctement une trame
I ou de supervision dont le bit P/F est mis à 0 et dont le numéro N(R) est valable (voir le § 2.3.4.9), l’ETCD
n’annule pas l’état de reprise par temporisateur. La valeur du N(R) reçu peut être utilisée pour mettre à jour
la variable d’état à l’émission V(S). Toutefois, l’ETCD peut décider de garder en mémoire la dernière trame
I émise (même s’il en a été accusé réception) afin de pouvoir la réémettre avec le bit P mis à 1 lorsque le
temporisateur T1 arrivera en fin de course ultérieurement.
Édition 2009
SUPPLéMENT ii-13
II-13/23
Si la trame de supervision reçue avec le bit P/F mis à 0 est une trame REJ dont le numéro
N(R) est valable, l’ETCD peut soit provoquer immédiatement la (re)transmission à partir de la valeur de la
variable d’état à l’émission V(S), soit ignorer la demande de retransmission et attendre la réception de la
trame de supervision dont le bit F est mis à 1 avant de provoquer la (re)transmission des trames à partir de la
valeur identifiée dans le champ du numéro N(R) de la trame de supervision dont le bit F est mis à 1. En cas
de retransmission immédiate et afin d’éviter des retransmissions répétées à la suite de l’annulation de l’état
de reprise par temporisateur, l’ETCD interdit la retransmission d’une trame I spécifique [même numéro N(R)
dans le même cycle de numérotation] si l’ETCD a retransmis cette trame I à la suite de la réception d’une
trame REJ dont le bit P/F est mis à 0.
Si, pendant qu’il est à l’état de reprise par temporisateur, l’ETCD reçoit une commande REJ
dont le bit P est mis à 1, il répond immédiatement en envoyant une réponse de supervision appropriée
dont le bit F est mis à 1. L’ETCD peut alors utiliser la valeur du numéro N(R) dans la commande REJ
pour mettre à jour la variable d’état à l’émission V(S) et peut soit commencer immédiatement la
(re)transmission à partir de la valeur du numéro N(R) indiquée dans la trame REJ, soit ignorer la demande
de retransmission et attendre la réception de la trame de supervision dont le bit F est mis à 1 avant de
provoquer la (re)transmission de trames I à partir de la valeur identifiée dans le champ du numéro N(R)
de la trame de supervision dont le bit F est mis à 1. En cas de retransmission immédiate et afin d’éviter des
retransmissions répétées à la suite de l’annulation de l’état de reprise par temporisateur, l’ETCD interdit
la retransmission d’une trame I spécifique [même numéro N(R) dans le même cycle de numérotation]
si l’ETCD a retransmis cette trame I à la suite de la réception d’une commande REJ dont le bit P est mis
à 1.
Si le temporisateur T1 arrive en fin de course pendant l’état de reprise par temporisateur, et si
aucune trame I ou aucune trame de supervision dont le bit P/F est mis à 0 et comportant un numéro N(R)
valable n’a été reçue, ou si aucune commande REJ dont le bit P est mis à 1 et comportant un numéro N(R)
valable n’a été reçue, l’ETCD ajoute une unité à sa variable de tentatives de transmission, redéclenche le
temporisateur et réémet la trame I déjà émise avec le bit P mis à 1 ou émet une commande de supervision
appropriée avec le bit P mis à 1.
Si la variable des tentatives de transmission est égale à N2, l’ETCD entame la procédure de
réinitialisation de la liaison de données décrite au § 2.4.7.2 ou émet une réponse DM pour demander à
l’ETTD d’entamer la procédure de réinitialisation de la liaison de données décrite au § 2.4.4.1 et passe à la
phase de déconnexion. N2 est un paramètre du système (voir le § 2.4.8.4).
Remarque: Bien que l’ETCD puisse utiliser la variable interne x, il existe d’autres mécanismes pour accomplir une
fonction identique.
2.4.6
Conditions LAPB pour la réinitialisation de la liaison de données (établissement de la liaison
de données)
2.4.6.1Quand l’ETCD reçoit, pendant la phase de transfert de l’information, une trame qui n’est pas
invalidée (voir le § 2.3.5.3) par l’une des conditions mentionnées au § 2.3.4.9, l’ETCD demande à l’ETTD
d’entamer une procédure de réinitialisation de la liaison de données en envoyant une réponse FRMR à
l’ETTD, comme indiqué au § 2.4.7.3.
2.4.6.2
Lorsque l’ETCD reçoit, pendant la phase de transfert de l’information, une réponse FRMR de
l’ETTD, il engage lui-même la procédure de réinitialisation de la liaison de données décrite au § 2.4.7.2 ou
envoie une réponse DM pour demander à l’ETTD d’entamer la procédure d’établissement (initialisation)
de la liaison de données décrite au § 2.4.4.1. Après avoir émis une réponse DM, l’ETCD passe à la phase de
déconnexion, comme indiqué au § 2.4.4.4.2.
2.4.6.3
Lorsque l’ETCD reçoit, pendant la phase de transfert de l’information, une réponse UA ou
une réponse non requise dont le bit F est mis à 1, l’ETCD peut soit entamer lui-même les procédures de
réinitialisation de la liaison de données décrites au § 2.4.7.2, soit envoyer une réponse DM pour demander
à l’ETTD d’entamer la procédure d’établissement (initialisation) de la liaison de données décrite au
§ 2.4.4.1. Après avoir émis une réponse DM, l’ETCD passe à la phase de déconnexion, comme indiqué au
§ 2.4.4.4.2.
2.4.6.4
Lorsque l’ETCD reçoit pendant la phase de transfert de l’information une réponse DM
de l’ETTD, il entame lui-même les procédures d’établissement (initialisation) de la liaison de données
décrites au § 2.4.4.1, ou bien il envoie une réponse DM pour demander à l’ETTD d’entamer les procédures
d’établissement (initialisation) de la liaison de données décrites au § 2.4,4.1. Après avoir émis une réponse
DM, l’ETCD passe à la phase de déconnexion comme indiqué au § 2.4.4.4.2.
Édition 2009
II-13/24
2.4.7
Procédure LAPB de réinitialisation de la liaison de données
2.4.7.1
La procédure de réinitialisation de la liaison de données est utilisée pour établir les deux sens
de transfert de l’information, conformément à la procédure ci-dessous. La procédure de réinitialisation de
la liaison de données n’est applicable que pendant la phase de transfert de l’information.
2.4.7.2
L’ETTD ou l’ETCD peuvent entamer la procédure de réinitialisation de la liaison de données.
Celle-ci indique la sortie de l’état d’occupation de l’ETCD et/ou de l’ETTD si cet état existe.
L’ETTD entame une procédure de réinitialisation de la liaison de données en envoyant une
commande SABM/SABME à l’ETCD. Si, à la réception correcte de cette commande, l’ETCD estime qu’il
peut rester à la phase de transfert de l’information, il envoie une réponse UA à l’ETTD, réinitialise ses
variables d’état à l’émission V(S) et à la réception V(R) et reste à la phase de transfert de l’information. Si, à
la réception correcte d’une commande SABM/SABME, l’ETCD décide qu’il ne peut pas rester à la phase de
transfert de l’information, il envoie une réponse DM pour refuser la demande de réinitialisation et passe à
la phase de déconnexion.
L’ETCD entame une procédure de réinitialisation de la liaison de données en envoyant une
commande SABM/SABME à l’ETTD et en déclenchant son temporisateur T1 (voir le § 2.4.8.1). à la réception
d’une réponse UA de l’ETTD, l’ETCD réinitialise ses variables d’état à l’émission V(S) et à la réception
V(R), arrête son temporisateur T1 et reste à la phase de transfert de l’information. à la réception d’une
réponse DM de l’ETTD qui refuse la demande de réinitialisation de la liaison de données, l’ETCD arrête son
temporisateur T1 et passe à la phase de déconnexion.
L’ETCD, après avoir envoyé une commande SABM/SABME, met au rebut toutes les trames, à
l’exception d’une commande SABM/SABME ou DISC, ou d’une réponse UA ou DM de l’ETTD. La réception
d’une commande SABM/SABME ou DISC de l’ETTD entraîne un cas de collision qui est résolu au § 2.4.4.5.
Les trames autres que la réponse UA ou DM envoyées en réponse à une commande SABM/SABME ou DISC
ne sont envoyées qu’une fois que la liaison de données est rétablie et s’il n’existe pas une commande SABM/
SABME en suspens.
Après l’envoi d’une commande SABM/SABME par l’ETCD, si une réponse UA ou DM n’est
pas reçue correctement, le temporisateur T1 arrive en fin de course dans l’ETCD. Celui-ci réémet alors la
commande SABM/SABME et redéclenche le temporisateur T1. Après N2 tentatives pour rétablir la liaison de
données, l’ETCD entreprend une action adéquate de récupération à un niveau supérieur et passe à la phase
de déconnexion. La valeur de N2 est définie au § 2.4.8.4.
2.4.7.3
L’ETCD peut demander à l’ETTD de réinitialiser la liaison de données en émettant une réponse
FRMR (voir le § 2.4.6.1). Après avoir émis une réponse FRMR, l’ETCD passe à l’état rejet de trame.
L’état rejet de trame est annulé lorsque l’ETCD reçoit une commande SABM/SABME, une
commande DISC ou une réponse DM; ou bien si l’ETCD émet une commande SABM/SABME, une commande
DISC ou une réponse DM. Si une autre commande est reçue pendant l’état rejet de trame, l’ETCD réémet la
réponse FRMR avec le même champ d’information que dans la réponse initiale.
L’ETCD peut déclencher le temporisateur T1 à l’émission de la réponse FRMR. Si le temporisateur
T1 arrive en fin de course avant l’annulation de l’état rejet de trame, l’ETCD peut réémettre la réponse FRMR
et redéclencher le temporisateur T1. Après N2 tentatives (temporisations) pour obliger l’ETTD à réinitialiser
la liaison de données, l’ETCD peut le faire lui-même comme indiqué au § 2.4.7.2. La valeur de N2 est définie
au § 2.4.8.4.
Pendant l’état rejet de trame, des trames I et de supervision ne sont pas émises par l’ETCD. De
même, celui-ci met au rebut les trames I et de supervision reçues excepté pour l’observation d’un bit P mis
à 1. Lorsqu’une réponse FRMR supplémentaire doit être émise par l’ETCD comme résultat de la réception
d’un bit P mis à 1 alors que la temporisation T1 est en cours, le temporisateur T1 continue à fonctionner.
à la réception d’une réponse FRMR (même pendant l’état rejet de trame) l’ETCD entame une procédure
de réinitialisation en émettant une commande SABM/SABME, comme indiqué au § 2.4.7.2, ou émet une
réponse DM pour demander à l’ETTD d’entamer la procédure d’établissement de la liaison de données
décrite au § 2.4.4.1 et passe à la phase de déconnexion.
2.4.8
Liste des paramètres du système LAPB
Les paramètres du système de l’ETCD et de l’ETTD sont les suivants:
Temporisateurs T1
2.4.8.1
La valeur du paramètre du système “temporisateur T1 de l’ETTD” peut être différente de celle
du paramètre du système “temporisateur T1 de l’ETCD”. Ces valeurs sont communiquées à l’ETTD et à
l’ETCD et fixées de concert par l’ETTD et l’ETCD pour un laps de temps déterminé.
Édition 2009
SUPPLéMENT ii-13
II-13/25
Pour la temporisation T1, à l’expiration de laquelle peut avoir lieu la retransmission d’une
trame (voir les § 2.4.4 et 2.4.5 pour l’ETCD), il est tenu compte du fait que T1 est déclenché au début ou à
la fin de l’émission d’une trame.
Le fonctionnement correct de la procédure exige que la temporisation T1 de l’émetteur (ETCD
ou ETTD) soit supérieure à la durée maximale qui sépare l’émission des trames (commande SABM/SABME,
DISC, I ou de supervision, réponse DM ou FRMR) de la réception de la trame correspondante donnée en
réponse à ces trames (UA, DM ou trame accusant réception). C’est pourquoi le récepteur (ETCD ou ETTD)
ne doit pas retarder une trame de réponse ou d’accusé de réception donnée en réponse à ces trames, d’une
durée supérieure à T2, où T2 est un paramètre du système (voir le § 2.4.8.2).
L’ETCD ne doit pas retarder la trame de réponse ou d’accusé de réception donnée en réponse à
une trame d’ETTD ci-dessus d’une durée supérieure à T2.
2.4.8.2
Paramètre T2
La valeur du paramètre T2 de l’ETTD peut être différente de la valeur du paramètre T2 de
l’ETCD. Ces valeurs sont communiquées à l’ETTD comme à l’ETCD et fixées de concert par l’ETTD et l’ETCD
pour un laps de temps déterminé.
Le paramètre T2 indique le temps dont dispose l’ETCD ou l’ETTD avant l’émission de la trame
accusant réception afin d’en assurer la réception par l’ETTD ou l’ETCD, respectivement, avant que la
temporisation T1 n’expire dans l’ETTD ou l’ETCD (paramètre T2 < temporisation T1).
Remarque: Le paramètre T2 est établi compte tenu des facteurs de temps suivants: temps de transmission de
la trame accusant réception, temps de propagation sur la liaison de données d’accès, temps de
traitement prévus à l’ETCD et à I’ETTD et temps nécessaire pour achever la transmission de la trame
— ou des trames — existant dans la file en attente d’émission par l’ETCD ou l’ETTD et qui ne sont
ni déplaçables, ni modifiables d’une manière méthodique.
étant donné la valeur de la temporisation T1 pour l’ETTD ou l’ETCD, la valeur du paramètre
T2 à l’ETCD ou à l’ETTD, respectivement, ne doit pas être supérieure à T1 moins deux fois le temps de
propagation sur la liaison de données d’accès, moins le temps de traitement de trame à l’ETCD, moins le
temps de traitement de trame à l’ETTD, et moins le temps de transmission de la trame accusant réception
par l’ETCD ou l’ETTD, respectivement.
2.4.8.3
Temporisateur T3
de l’ETTD.
L’ETCD met en œuvre un paramètre de système “temporisateur T3” dont la valeur est connue
La temporisation T3, à l’expiration de laquelle une indication d’un état de voie inactive de
durée excessive est transmise au niveau de la couche paquets, est accrue suffisamment par rapport à la
temporisation T1 de l’ETCD (soit T3 > T1) de façon que, à l’expiration de T3, il soit suffisamment assuré que
la voie de la liaison est à l’état non actif et non opérationnel et nécessite l’établissement d’une liaison de
données avant que le fonctionnement de données de la liaison de données normale puisse reprendre.
2.4.8.4
Nombre maximal de tentatives N2 pour réussir la transmission
La valeur du paramètre du système N2 de l’ETTD peut être différente de la valeur de ce paramètre
dans l’ETCD. Ces valeurs sont communiquées à l’ETTD et à l’ETCD et fixées de concert par l’ETTD et l’ETCD
pour un laps de temps déterminé.
La valeur de N2 indique le nombre maximal de tentatives faites par l’ETCD ou l’ETTD pour
réussir la transmission d’une trame vers l’ETTD ou l’ETCD, respectivement.
2.4.8.5
Nombre maximal N1 de bits dans une trame I
La valeur du paramètre du système N1 de l’ETTD peut être différente de la valeur de ce paramètre
dans l’ETCD. Ces valeurs sont communiquées à l’ETTD et à l’ETCD.
La valeur de N1 indique le nombre maximal de bits dans une trame I (à l’exclusion des fanions
et des bits “0” insérés pour la transparence) que l’ETCD ou l’ETTD accepte en provenance respectivement
de l’ETTD ou l’ETCD.
Édition 2009
II-13/26
Pour permettre un fonctionnement universel, l’ETTD devrait supporter une valeur de N1 qui
ne soit pas inférieure à 1080 bits (135 octets). Les ETTD devraient savoir que le réseau peut transmettre des
paquets plus longs (voir le § 5.2), ce qui peut entraîner des difficultés à la couche liaison de données.
Tous les réseaux offrent à un ETTD qui l’a demandée une valeur de N1 pour l’ETCD qui est
supérieure ou égale à 2072 bits (259 octets), compte non tenu des champs d’adresse, de commande et FCS,
à l’interface ETTD/ETCD et supérieure ou égale à la longueur maximale des paquets de données qui peuvent
traverser l’interface ETTD/ETCD, compte non tenu des champs d’adresse, de commande et FCS, à l’interface
ETTD/ETCD.
L’appendice II décrit la méthode utilisée pour dériver les valeurs citées ci-dessus.
2.4.8.6
Nombre maximal k de trames I en anticipation
Le paramètre du système k de l’ETTD a la même valeur que celui de l’ETCD. Cette valeur est
fixée de concert par l’ETTD et l’ETCD pour un laps de temps déterminé.
La valeur k indique le nombre maximal de trames I numérotées séquentiellement que l’ETTD
ou l’ETCD peut avoir en attente (c’est-à-dire, sans accusé de réception) à un moment donné. La valeur k ne
peut en aucun cas excéder sept pour le fonctionnement modulo 8, ou cent vingt-sept pour le fonctionnement
modulo 128. Tous les réseaux (ETCD) acceptent la valeur sept. D’autres valeurs k (inférieures et supérieures
à sept) peuvent également être acceptées par les réseaux (ETCD).
[...]
3.Description de l’interface ETTD/ETCD à la couche paquets
Ce paragraphe et les suivants ont trait au transfert de paquets à l’interface ETTD/ETCD. Les
procédures concernent les paquets qui traversent correctement l’interface ETTD/ETCD.
Tout paquet devant être transmis à travers l’interface ETTD/ETCD est placé dans le champ
d’information de la couche liaison de données qui délimite la longueur de ce paquet; ce champ d’information
ne peut contenir qu’un seul paquet.
Remarque: Certains réseaux exigent que les champs de données des paquets contiennent un nombre entier
d’octets. Si l’ETTD transmet vers le réseau des champs de données ne contenant pas un nombre entier
d’octets, il peut en résulter une perte de l’intégrité des données. Si l’on souhaite un fonctionnement
universel, sur tous les réseaux, il faudra que les ETTD transmettent tous leurs paquets avec des
champs de données contenant uniquement un nombre entier d’octets. L’intégrité complète des
données ne peut être assurée que par l’échange de champs de données basés sur les octets, dans les
deux sens de transmission.
Le présent paragraphe contient une description de l’interface à la couche paquets, pour les
services de communication virtuelle et de circuit virtuel permanent.
Les procédures pour les services de circuit virtuel (à savoir les services de communication virtuelle
et de circuit virtuel permanent) sont spécifiées au § 4. Les formats des paquets sont spécifiés au § 5. Les
procédures et les formats pour les services complémentaires facultatifs d’usager sont spécifiés aux § 6 et 7.
3.1
Voies logiques
Afin de permettre la coexistence à un instant donné de plusieurs communications virtuelles
et/ou de plusieurs circuits virtuels permanents, on utilise des voies logiques. Un numéro de groupe de voies
logiques (inférieur ou égal à 15) et un numéro de voie logique (inférieur ou égal à 255) sont attribués à
chaque circuit virtuel permanent et à chaque communication virtuelle. Dans le cas d’une communication
virtuelle, les numéros de groupe de voies logiques et le numéro de voie logique sont attribués pendant la
phase d’établissement de la communication. La gamme des voies logiques utilisées pour les communications
virtuelles est fixée en accord avec l’Administration au moment de l’abonnement au service (voir l’annexe A).
Dans le cas d’un circuit virtuel permanent, le numéro de groupe de voies logiques et le numéro de voie logique
sont attribués au moment de l’abonnement au service, en accord avec l’Administration (voir l’annexe A).
3.2Structure de base des paquets
Chaque paquet transféré à travers l’interface ETTD/ETCD comporte au moins 3 octets. Ces
trois octets contiennent une identification générale de format, une identification de voie logique et une
Édition 2009
II-13/27
SUPPLéMENT ii-13
identification de type de paquet. D’autres champs de paquets peuvent être ajoutés, selon les besoins (voir
le § 5).
Les types de paquets et leur utilisation dans divers services sont indiqués dans le tableau 14/X.25.
3.3Procédure de reprise
La procédure de reprise sert à initialiser ou réinitialiser l’interface ETTD/ETCD à la couche
paquets. Elle est utilisée pour libérer simultanément toutes les communications virtuelles et réinitialiser
tous les circuits virtuels permanents à l’interface ETTD/ETCD (voir le § 4.5).
La figure B-1/X.25 donne le diagramme d’état qui définit les relations logiques entre les
événements relatifs à la procédure de reprise.
Le tableau C-2/X.25 précise les actions entreprises par l’ETCD à la réception de paquets en
provenance de l’ETTD, pour la procédure de reprise.
3.3.1
Reprise par l’ETTD
à tout moment, l’ETTD peut demander une reprise en transmettant un paquet de demande de
reprise à travers l’interface ETTD/ETCD. L’interface se trouve alors, pour toutes les voies logiques, à l’état de
demande de reprise par l’ETTD (r2).
Tableau 14/X.25 — Types de paquets et leur utilisation dans les divers services
Type de paquet
Service
De l’ETCD vers l’ETTD
De l’ETTD vers l’ETCD
CV
CVP
établissement et libération des communications (voir la remarque 1 )
Appel rentrant
Appel
Communication établie
Communication acceptée
Indication de libérationDemande de libération
Confirmation de libération par l’ETCD
Confirmation de libération par l’ETTD
X
X
X
X
Données et interruption (voir la remarque 2)
Données de l’ETCDDonnées de l’ETTD
Interruption par l’ETCD
Interruption par l’ETTD Confirmation d’interruption par l’ETCD
Confirmation d’interruption par l’ETTD
X
X
X
X
X
X
RR de l’ETCD
RR de l’ETTD
RNR de l’ETCD
RNR de l’ETTD
REJ de l’ETTDa)
Indication de réinitialisationDemande de réinitialisation
Confirmation de réinitialisation par l’ETCD Confirmation de réinitialisation par l’ETTD
X
X
X
X
X
X
X
X
X
X
Reprise (voir la remarque 4)
Indication de repriseDemande de reprise
Confirmation de reprise par l’ETCD
Confirmation de reprise par l’ETTD
X
X
X
X
Diagnostic (voir la remarque 5)
Diagnostica)
X
X
Enregistrement (voir la remarque 6)
Confirmation d’enregistrement
Demande d’enregistrement
X
X
X
X
Contrôle de flux et réinitialisation (voir la remarque 3)
a)
N’est pas nécessairement disponible dans tous les réseaux.
CV
Communication virtuelle
CVP Circuit virtuel permanent
Remarque 1— Voir les § 4.1 et 6.16 pour les procédures, et le § 5.2 pour les formats.
Remarque 2— Voir le § 4.3 pour les procédures, et le § 5.3 pour les formats.
Remarque 3— Voir les § 4.4 et 6.4 pour les procédures, et les § 5.4 et 5.7.1 pour les formats.
Remarque 6— Voir le § 6.1 pour les procédures, et le § 5.7.2 pour les formats.
a)
Édition 2009
II-13/28
L’ETCD confirme la reprise en émettant un paquet de confirmation de reprise par l’ETCD et en
plaçant les voies logiques utilisées pour des communications virtuelles à l’état prêt (p1), et les voies logiques
utilisées pour des circuits virtuels permanents à l’état contrôle de flux prêt (d1).
Remarque: Les états p1 et d1 sont spécifiés au § 4.
Le paquet de confirmation de reprise par l’ETCD ne peut être interprété universellement qu’avec
une signification locale. Le temps passé à l’état de demande de reprise par l’ETTD (r2) ne doit pas dépasser
le temps-limite T20 (voir l’annexe D).
3.3.2
Reprise par l’ETCD
L’ETCD peut indiquer une reprise en transmettant un paquet d’indication de reprise à travers
l’interface ETTD/ETCD. L’interface est alors, pour toutes les voies logiques, dans l’état d’indication de reprise
par l’ETCD (r3). à cet état de l’interface ETTD/ETCD, l’ETCD ne tient compte d’aucun paquet sauf ceux de
demande de reprise et de confirmation de reprise par l’ETTD.
L’ETTD confirme la reprise en émettant un paquet de confirmation de reprise par l’ETTD et en
plaçant les voies logiques utilisées pour des communications virtuelles à l’état prêt (p1), et les voies logiques
utilisées pour des circuits virtuels permanents à l’état contrôle de flux prêt (d1).
L’action entreprise par l’ETCD, lorsque l’ETTD ne confirme pas la reprise dans les limites de la
temporisation T10, est décrite dans l’annexe D.
3.3.3
Collision de reprises
Il se produit une collision de reprises lorsqu’un ETTD et un ETCD émettent simultanément un
paquet de demande de reprise et un paquet d’indication de reprise. Dans un tel cas, l’ETCD considère que la
reprise est terminée et n’attend pas de paquet de confirmation de reprise par l’ETTD; il n’émet pas de paquet
de confirmation de reprise par l’ETCD. Il en résulte que les voies logiques utilisées pour les communications
virtuelles sont placées à l’état prêt (p1) et les voies logiques utilisées pour les circuits virtuels permanents à
l’état contrôle de flux prêt (d1).
3.4Traitement des erreurs
Le tableau C-1/X.25 spécifie la réaction de l’ETCD, lorsque des conditions d’erreur particulières
sont rencontrées. D’autres conditions d’erreur sont traitées au § 4.
3.4.1
Paquet diagnostic
Le paquet diagnostic est utilisé par certains réseaux pour indiquer des conditions d’erreur,
dans des circonstances où les méthodes habituelles d’indication (réinitialisation, libération et reprise avec
cause et diagnostic) sont inapplicables (voir les tableaux C-1/X.25 et D-1/X.25). Le paquet diagnostic en
provenance de l’ETCD fournit une information sur les erreurs qui sont considérées comme incorrigibles à la
couche paquets de la Recommandation X.25; l’information fournie permet une analyse des erreurs et une
correction par des couches plus élevées à l’ETTD, si cela est souhaité ou possible.
Un paquet diagnostic est émis une seule fois par apparition particulière d’une condition
d’erreur. Il n’est pas nécessaire que l’ETTD émette une confirmation lorsqu’il reçoit un paquet diagnostic.
4.Procédures relatives aux services de circuits virtuels
4.1Procédures pour le service de communication virtuelle
Les figures B-1/X.25, B-2/X.25 et B-3/X.25 donnent les diagrammes d’état qui définissent les
événements pouvant se produire à l’interface ETTD/ETCD à la couche paquets sur chaque voie logique
utilisée pour les communications virtuelles.
L’annexe C donne les détails de l’action entreprise par l’ETCD à la réception de paquets dans
chacun des états décrits dans l’annexe B.
Les procédures d’établissement et de libération des communications décrites dans les paragraphes qui suivent s’appliquent indépendamment à chaque voie logique attribuée au service de
communication virtuelle, à l’interface ETTD/ETCD.
Édition 2009
SUPPLéMENT ii-13
II-13/29
4.1.1
état prêt
On dit qu’une voie logique est à l’état prêt (p1) lorsqu’il n’y a aucune communication en cours
sur cette voie logique.
4.1.2
Paquet d’appel
L’ETTD appelant indique une demande d’établissement de communication en transmettant
un paquet d’appel à travers l’interface ETTD/ETCD. La voie logique choisie par l’ETTD est alors à l’état ETTD
en attente (p2). Le paquet d’appel contient l’adresse de l’ETTD appelé.
Remarque 1: Une adresse d’ETTD peut être une adresse de réseau de l’ETTD, ou toute autre identification de
l’ETTD faisant l’objet d’un accord pour une période donnée entre l’ETTD et l’ETCD.
Remarque 2: Le paquet d’appel doit utiliser la voie logique ayant le numéro le plus élevé, parmi les voies logiques
à l’état prêt situées dans la gamme qui a été convenue avec l’Administration (voir l’annexe A). Le
risque de collision d’appels se trouve ainsi réduit au minimum.
4.1.3
Paquet d’appel entrant
L’ETCD indique un appel entrant en transmettant à travers l’interface ETTD/ETCD un paquet
d’appel entrant. Ceci place la voie logique à l’état ETCD en attente (p3).
Le paquet d’appel entrant utilise la voie logique ayant le plus petit numéro parmi les voies
logiques qui sont à l’état prêt (voir l’annexe A). Le paquet d’appel entrant contient l’adresse de l’ETTD
appelant.
Remarque:
Une adresse d’ETTD peut être une adresse de réseau de l’ETTD, ou toute autre identification de
l’ETTD faisant l’objet d’un accord pour une période donnée entre l’ETTD et l’ETCD.
4.1.4
Paquet communication acceptée
L’ETTD appelé indique qu’il accepte la communication en transmettant à travers l’interface
ETTD/ETCD un paquet communication acceptée précisant la même voie logique que le paquet d’appel
entrant. Ceci place la voie logique concernée à l’état transfert de données (p4).
Si l’ETTD appelé n’accepte pas la communication au moyen d’un paquet communication
acceptée ou s’il ne rejette pas la communication au moyen d’un paquet de demande de libération, comme
indiqué au § 4.1.7, dans les limites de la temporisation T11 (voir l’annexe D), l’ETCD considère cette situation
comme une erreur de procédure de l’ETTD appelé et libère la communication virtuelle en appliquant la
procédure décrite au § 4.1.8.
4.1.5
Paquet communication établie
La réception par l’ETTD appelant d’un paquet communication établie, précisant la même voie
logique que le paquet d’appel, indique que la communication a été acceptée par l’ETTD appelé, au moyen
d’un paquet communication acceptée. Cela place la voie logique spécifiée à l’état transfert de données
(p4).
Le temps passé à l’état ETTD en attente (p2) ne doit pas dépasser le temps-limite T21 (voir
l’annexe D).
4.1.6
Collision d’appels
Une collision d’appels intervient lorsqu’un ETTD et un ETCD transmettent simultanément
un paquet d’appel et un paquet d’appel entrant indiquant la même voie logique. Dans une telle situation,
l’ETCD traite le paquet d’appel et annule le paquet d’appel entrant.
4.1.7
Libération par l’ETTD
à tout moment, l’ETTD peut indiquer la libération en transmettant à travers l’interface ETTD/
ETCD un paquet de demande de libération (voir le § 4.5). La voie logique est alors à l’état demande de
libération par l’ETTD (p6). Quand l’ETCD s’est préparé à libérer la voie logique, l’ETCD transmet à travers
l’interface ETTD/ETCD un paquet de confirmation de libération par l’ETCD précisant la voie logique. La
voie logique est alors à l’état prêt (p1).
Le paquet de confirmation de libération par l’ETCD ne peut être interprété universellement
que comme ayant une signification locale; toutefois, dans les réseaux de certaines Administrations, la
confirmation de libération peut avoir une signification de bout en bout. Dans tous les cas, le temps passé à
l’état de demande de libération par l’ETTD (p6) n’excède pas le temps-limite T23 (voir l’annexe D).
Édition 2009
II-13/30
Il est possible qu’à la suite de l’émission d’un paquet de demande de libération, l’ETTD reçoive
d’autres types de paquet, selon l’état de la voie logique, avant de recevoir un paquet de confirmation de
libération par l’ETCD.
Remarque:
L’ETTD appelant peut faire échouer une communication en la libérant avant d’avoir reçu un paquet
de communication établie ou d’indication de libération.
L’ETTD appelé peut refuser une communication entrante en la libérant comme indiqué dans le
présent paragraphe, au lieu d’émettre un paquet communication acceptée comme décrit au § 4.1.4.
4.1.8
Libération par l’ETCD
L’ETCD indique la libération en transmettant à travers l’interface ETTD/ETCD un paquet
d’indication de libération (voir le § 4.5). La voie logique est alors à l’état indication de libération par
l’ETCD (p7). L’ETTD répond en transmettant à travers l’interface ETTD/ETCD un paquet de confirmation
de libération par l’ETTD. La voie logique est alors à l’état prêt (p1).
L’annexe D décrit l’action entreprise par l’ETCD lorsque l’ETTD ne confirme pas la libération
dans le temps-limite T13.
4.1.9
Collision de libérations
Une collision de libérations intervient lorsqu’un ETTD et un ETCD transmettent simultanément
un paquet de demande de libération et un paquet d’indication de libération précisant la même voie
logique. Dans une telle situation, l’ETCD considère que la libération est achevée; il n’attend pas de paquet
de confirmation de libération par l’ETTD et ne transmet pas de paquet de confirmation de libération par
l’ETCD. Ceci place la voie logique à l’état prêt (p1).
4.1.10
Appel infructueux
Si une communication ne peut être établie, l’ETCD émet un paquet d’indication de libération
précisant la voie logique mentionnée dans le paquet d’appel.
4.1.11
Signaux de progression d’appel
L’ETCD est à même de transmettre à l’ETTD les signaux de progression d’appel décrits dans la
Les signaux de progression d’appel pour la libération sont transmis au sein des paquets
d’indication de libération qui marquent la fin de l’appel auquel le paquet se réfère. La façon de coder les
paquets d’indication de libération qui contiennent un signal de progression d’appel est exposée en détail
au § 5.2.4.
état de transfert de données
4.1.12
Les procédures de commande des paquets transmis entre l’ETCD et l’ETTD à l’état transfert de
données sont exposées au § 4.3.
4.2Procédures pour le service de circuits virtuels permanents
Les figures B-1/X.25 et B-3/X.25 donnent les diagrammes d’état qui définissent les événements
pouvant se produire à l’interface ETTD/ETCD à la couche paquets sur une voie logique utilisée pour des
circuits virtuels permanents.
L’annexe C donne les détails de l’action entreprise par l’ETCD à la réception de paquets dans
chacun des états décrits dans l’annexe B.
Dans le cas des circuits virtuels permanents, il n’y a pas de phase d’établissement ni de libération
de la communication. Les procédures à appliquer pour la commande des paquets entre l’ETTD et l’ETCD, à
l’état transfert de données, sont décrites au § 4.3.
S’il se produit une défaillance momentanée du réseau, l’ETCD réinitialise le circuit virtuel
permanent, comme décrit au § 4.4.3, avec la cause “saturation du réseau” et continue à écouler le trafic des
données.
Si le réseau est momentanément incapable d’acheminer le trafic des données, l’ETCD réinitialise
le circuit virtuel permanent, avec la cause “réseau en dérangement”. Lorsque le réseau est de nouveau en
mesure d’écouler le trafic de données, l’ETCD doit réinitialiser le circuit virtuel permanent avec la cause
“réseau opérationnel”.
Édition 2009
II-13/31
SUPPLéMENT ii-13
4.3Procédures pour le transfert des données et des interruptions
Les procédures de transfert des données et des interruptions décrites ici s’appliquent
indépendamment à chaque voie logique attribuée pour des communications virtuelles ou pour des circuits
virtuels permanents existant à l’interface ETTD/ETCD.
L’exploitation normale du réseau impose que toutes les données d’usager, dans les paquets de
données et d’interruption, soient transmises en transparence, et sans que le réseau introduise d’altérations
dans le cas de communications entre un ETTD en mode-paquet et un autre ETTD en mode-paquet. L’ordre
des bits dans les paquets de données et d’interruption est préservé. Les séquences de paquets sont transférées
comme des séquences de paquets complètes. Les codes de diagnostic des ETTD sont traités comme indiqué
aux § 5.2.4, 5.4.3 et 5.5.1.
états permettant le transfert de données
4.3.1
Une voie logique de communication virtuelle se trouve à l’état transfert de données (p4)
après l’établissement d’une communication et avant une libération ou une procédure de reprise. Une voie
logique de circuit virtuel permanent est continuellement à l’état transfert de données (p4), sauf pendant
le déroulement d’une procédure de reprise. Les paquets de données, d’interruption, de contrôle de flux et
de réinitialisation peuvent être émis et reçus par un ETTD à l’état transfert de données d’une voie logique
à l’interface ETTD/ETCD. Dans cet état, les procédures de contrôle de flux et de réinitialisation décrites
au § 4.4 s’appliquent à la transmission des données sur la voie logique considérée, à destination et en
provenance de l’ETTD.
Lorsqu’une communication virtuelle est libérée, le réseau peut mettre au rebut les paquets de
données et d’interruption (voir le § 4.5). De plus, les paquets de données, d’interruption, de contrôle de
flux et de réinitialisation transmis par un ETTD ne sont pas pris en considération par l’ETCD lorsque la
voie logique est à l’état indication de libération par l’ETCD (p7). Il appartient donc à l’ETTD de définir les
protocoles d’ETTD à ETTD capables de faire face aux diverses situations qui peuvent se présenter.
4.3.2
Longueur du champ des données d’usager dans les paquets de données
La longueur maximale normalisée du champ des données d’usager est de 128 octets.
De plus, d’autres longueurs maximales du champ des données d’usager peuvent être offertes
par les Administrations, dans la liste suivante: 16, 32, 64, 256, 512, 1024, 2048 et 4096 octets. Une longueur
maximale facultative du champ des données d’usager peut être choisie pour une période déterminée comme
longueur maximale par défaut commune à toutes les communications virtuelles à l’interface ETTD/ETCD
(voir le § 6.9). Pour chaque circuit virtuel permanent, il est possible de choisir une autre valeur que cette
longueur par défaut pendant une période déterminée (voir le § 6.9). Les longueurs maximales du champ
des données d’usager peuvent être négociées, communication par communication, au moyen du service
complémentaire de négociation du paramètre de contrôle de flux (voir le § 6.12).
Le champ des données d’usager des paquets de données émis par un ETTD ou un ETCD peut
contenir un nombre quelconque de bits, inférieur ou égal au maximum fixé.
Remarque: Il existe des réseaux qui exigent que le champ des données d’usager contienne un nombre entier
d’octets (voir la remarque du § 3).
Si, dans un paquet de données, le champ des données d’usager dépasse la longueur de champ
maximale admissible localement, l’ETCD réinitialise la communication virtuelle ou le circuit virtuel
permanent, avec la cause de réinitialisation suivante: erreur de procédure locale.
4.3.3
Bit de confirmation de remise
On fixe une valeur au bit de confirmation de remise (bit D) pour indiquer si l’ETTD souhaite ou
non recevoir un accusé de réception de remise de bout en bout, pour les données qu’il transmet, au moyen
du numéro de séquence de paquets en réception, P(R) (voir le § 4.4).
Remarque:
L’utilisation de la procédure du bit D ne dispense pas de l’utilisation d’un protocole de couche plus
élevée, convenu entre les ETTD en communication; ce protocole peut être utilisé, avec ou sans
la procédure du bit D, pour effectuer la récupération après les réinitialisations et les libérations
générées par l’usager ou le réseau.
L’ETTD appelant peut, pendant l’établissement de la communication, s’assurer que la procédure
du bit D peut être appliquée pour la communication en mettant le bit 7 de l’identification générale de format
du paquet d’appel à 1 (voir le § 5.1.1). Tout réseau, ou toute partie du réseau international, où l’on dispose
Édition 2009
II-13/32
de la procédure du bit D transmet ce bit en transparence. Si l’ETTD distant est capable d’appliquer cette
procédure, il ne doit pas considérer comme non valable le bit D mis à 1 dans le paquet d’appel entrant.
De même, l’ETTD appelé peut mettre le bit 7 de l’identification générale de format du paquet
communication acceptée à 1. Tout réseau, ou toute partie du réseau international, où l’on dispose de
la procédure du bit D transmet ce bit en transparence. Si l’ETTD appelant est capable d’appliquer cette
procédure, il ne doit pas considérer comme non valable le bit D mis à 1 dans le paquet de communication
établie.
L’utilisation, par les ETTD, du mécanisme décrit ci-dessus, dans les paquets d’appel et de
communication acceptée, est recommandée mais elle n’est pas obligatoire pour l’application de la procédure
du bit D pendant la communication virtuelle.
4.3.4
Marque: Données à suivre
Si un ETTD ou un ETCD souhaite indiquer une séquence comportant plus d’un paquet, il
utilise une marque données à suivre (bit M), définie ci-après.
Le bit M peut être mis à 1 dans tout paquet de données. Lorsqu’il est mis à 1 dans un paquet
de données complet ou dans un paquet de données incomplet qui comporte aussi le bit D mis à 1, il
indique que d’autres données vont suivre. La recombinaison avec le paquet de données suivant ne peut être
effectuée dans le réseau que si le bit M est mis à 1 dans un paquet de données complet où le bit D est aussi
mis à 0.
Une séquence de paquets de données dont tous les bits M, sauf le dernier, sont mis à 1 est
remise comme une séquence de paquets de données dont les bits M sont mis à 1, sauf le dernier, lorsque les
paquets originaux ayant le bit M mis à 1 sont complets (quelle que soit la valeur du bit D) ou incomplets
mais avec leur bit D mis à 1.
On définit deux catégories de paquets de données, A et B, comme indiqué au tableau 15/X.25.
Ce tableau indique également de quelle manière le réseau traite les bits M et D aux deux extrémités d’une
communication virtuelle ou d’un circuit virtuel permanent.
Tableau 15/X.25 — Définition des deux catégories de paquets de données et traitement
des bits M et D par le réseau
Paquet de données émis
par l’ETTD d’origine
Catégorie
B
M
0 ou 1
D
La combinaison avec
le ou les paquets suivants
est effectuée par le réseau
lorsque cela est possible
Complet
0NonNon
Paquet de donnéesa)
reçu par l’ETTD
de destination
M
D
0
0
B
0
1NonNon
0
1
B
1
1NonNon
1
1
B
0
0
OuiNon
0
0
B
0
1
OuiNon
0
1
A
1
0
Oui
1
0
B
1
1
OuiNon
1
1
Oui (voir la remarque 2)
Paquet de données remis dans lequel le dernier bit des données d’usager correspond, le cas échéant, au dernier
bit des données d’usager qui était présent dans le paquet de données transmis par l’ETTD d’origine.
a)
Remarque 1: Le réseau d’origine met le bit M à 0.
Remarque 2: Si le paquet de données transmis par l’ETTD d’origine est combiné avec d’autres paquets, jusques et
y compris un paquet de la catégorie B, les valeurs des bits M et D, dans le paquet de données reçu par
l’ETTD de destination, sont les mêmes que dans les deux colonnes de droite pour le dernier paquet
de données transmis par l’ETTD d’origine qui entrait dans la combinaison.
Édition 2009
SUPPLéMENT ii-13
II-13/33
4.3.5
Séquence complète de paquets
On définit une séquence complète de paquets comme étant composée d’un paquet unique
de la catégorie B et de tous les paquets contigus antérieurs éventuels de la catégorie A. Les paquets de la
catégorie A ont la longueur maximale exacte du champ des données d’usager, avec le bit M mis à 1 et le bit
D mis à 0. Tous les autres paquets de données appartiennent à la catégorie B.
Lorsqu’elle est transmise par un ETTD d’origine, une séquence complète de paquets est toujours
remise à l’ETTD de destination comme une séquence complète unique de paquets.
Ainsi, si l’extrémité de réception fonctionne avec des champs des données d’usager ayant
une longueur maximale plus grande qu’à l’extrémité d’émission, les paquets contenus dans une séquence
complète de paquets sont combinés à l’intérieur du réseau. Ils sont remis dans une séquence complète de
paquets, dans laquelle les champs des données d’usager de chaque paquet, le dernier excepté, ont exactement
la longueur maximale et dans laquelle le bit M est mis à 1 et le bit D à 0. Le champ des données d’usager du
dernier paquet de la séquence peut avoir une longueur inférieure à la longueur maximale, les bits M et D
étant mis comme indiqué au tableau 15/X.25.
Si la longueur maximale des champs des données d’usager est la même aux deux extrémités,
les champs des données d’usager des paquets de données sont remis à l’ETTD récepteur exactement dans
la même forme où ils ont été reçus par le réseau, avec l’exception suivante. Si un paquet complet dont le
bit M est mis à 1 et le bit D mis à 0 est suivi d’un paquet vide, ces deux paquets peuvent être fusionnés de
manière à former un paquet complet unique de catégorie B. Si le dernier paquet d’une séquence complète
de paquets transmise par l’ETTD) d’origine comporte un champ de données de longueur inférieure à la
longueur maximale avec le bit M mis à 1 et le bit D mis à 0, le dernier paquet de la séquence complète remise
à l’ETTD de réception aura son bit M mis à 0.
Si la longueur maximale des champs des données d’usager est plus petite à l’extrémité réceptrice
qu’à l’extrémité émettrice, les paquets sont fractionnés dans le réseau, et les bits M et D sont fixés par le
réseau, comme il a été décrit, pour conserver des séquences complètes de paquets.
4.3.6
Bit qualificatif
Dans certains cas, un indicateur peut être nécessaire avec le champ des données d’usager pour
différencier deux types d’information, par exemple les données d’usager et l’information de commande. La
Recommandation X.29 donne un exemple d’un tel cas.
Si un tel mécanisme est nécessaire, on peut utiliser dans l’en-tête du paquet de données un
indicateur appelé bit qualificatif (bit Q).
Le recours au bit Q est facultatif. Si ce mécanisme n’est pas nécessaire, le bit Q est toujours mis
à 0; s’il est utilisé, l’ETTD émetteur doit donner au bit Q une valeur telle que tous les paquets de données
d’une même séquence complète de paquets aient la même valeur (0 ou 1). Une séquence complète de
paquets transmise par l’ETTD à l’ETCD de cette manière est remise à l’ETTD distant comme une séquence
complète de paquets dont le bit Q a, dans tous les paquets, la valeur attribuée par l’ETTD émetteur.
Si le bit Q n’est pas mis par l’ETTD à la même valeur dans tous les paquets de données d’une
séquence complète de paquets, la valeur du bit Q dans l’un quelconque des paquets de données de la
séquence de paquets correspondante transmise à l’ETTD distant n’est pas garantie par le réseau. En outre,
certains réseaux peuvent réinitialiser la communication virtuelle ou le circuit virtuel permanent comme
indiqué dans l’annexe C.
Les paquets de données successifs sont numérotés consécutivement (voir le § 4.4.1.1), quelle
que soit la valeur du bit Q.
4.3.7
Procédure d’interruption
La procédure d’interruption permet à un ETTD de transmettre des données à un ETTD distant,
sans suivre la procédure de contrôle de flux relative aux paquets de données (voir le § 4.4). La procédure
d’interruption ne peut s’appliquer que dans l’état contrôle de flux prêt (d1) à l’intérieur de l’état transfert de
données (p4).
La procédure d’interruption n’a aucun effet sur les procédures de transfert et de contrôle de
flux relatives aux paquets de données sur la communication virtuelle ou le circuit virtuel permanent.
Pour transmettre une interruption, un ETTD transmet à travers l’interface ETTD/ETCD un
paquet d’interruption par l’ETTD. L’ETTD ne doit pas transmettre un deuxième paquet d’interruption par
l’ETTD tant que le premier n’est pas confirmé par un paquet de confirmation d’interruption par l’ETCD
Édition 2009
II-13/34
(voir le tableau C-4/X.25). Après déroulement complet de la procédure d’interruption à l’extrémité distante,
l’ETCD confirme la réception de l’interruption en envoyant un paquet de confirmation d’interruption par
l’ETCD. La réception de ce paquet indique que l’interruption a été confirmée par l’ETTD distant, au moyen
d’un paquet de confirmation d’interruption par l’ETTD.
L’ETCD signale une interruption provenant d’un ETTD distant en envoyant à travers l’interface
ETTD/ETCD un paquet d’interruption par l’ETCD contenant le même champ de données que le paquet
d’interruption par l’ETTD transmis par l’ETTD distant. Un paquet d’interruption de l’ETCD est remis au
point du train de paquets de données où a été émis le paquet d’interruption d’ETTD ou en amont de ce
point. L’ETTD confirme alors la réception du paquet d’interruption par l’ETCD en émettant un paquet de
confirmation d’interruption par l’ETTD.
4.3.8
Délai de transit des paquets de données
Le délai de transit est une caractéristique propre à une communication virtuelle ou à un circuit
virtuel permanent, commune aux deux sens de transmission.
Ce délai de transit est le temps de transfert des paquets de données tel qu’il est défini au § 3.1 de
la Recommandation X.135, mesuré entre les limites B2 et Bn-1, telles que définies à la figure 2/X.135 (c’est-à-dire
lignes d’accès non comprises), moyennant les conditions énoncées au § 3.2 de la Recommandation X.135, et
il s’exprime en valeur moyenne.
Le choix du délai de transit communication par communication et l’indication donnée aux
ETTD appelant et appelé de la valeur du délai de transit concernant une communication virtuelle donnée
peuvent se faire au moyen d’un service complémentaire de sélection et indication du délai de transit (voir
le § 6.27).
4.4Procédures de contrôle de flux
Le § 4.4 ne s’applique qu’à l’état transfert des données (p4) et décrit les procédures relatives
au contrôle de flux des paquets de données et aux réinitialisations sur toute voie logique utilisée pour une
communication virtuelle ou un circuit virtuel permanent.
4.4.1
Contrôle de flux
à l’interface ETTD/ETCD d’une voie logique utilisée pour une communication virtuelle ou un
circuit virtuel permanent, la transmission des paquets de données est contrôlée séparément dans chaque
sens et est fondée sur des autorisations venant de l’extrémité réceptrice.
Dans une communication virtuelle ou un circuit virtuel permanent, le contrôle de flux permet
également à un ETTD de limiter la vitesse à laquelle il accepte les paquets transmis à travers l’interface
ETTD/ETCD. à noter qu’il existe une limite au nombre des paquets de données qui peuvent être présents
dans le réseau, sur une communication virtuelle ou un circuit virtuel permanent; cette limite dépend du
réseau.
4.4.1.1
Numérotation des paquets de données
Chaque paquet de données transmis à l’interface ETTD/ETCD, dans chaque sens de transmission,
sur un circuit virtuel permanent ou une communication virtuelle, est numéroté séquentiellement.
La numérotation des paquets est réalisée modulo 8. Les numéros de séquence des paquets
décrivent le cycle complet de 0 à 7. Certaines Administrations fournissent le service complémentaire de
numérotation séquentielle étendue des paquets (voir le § 6.2); si l’on choisit ce service complémentaire, on
obtient une numérotation séquentielle des paquets qui est réalisée modulo 128. Dans un tel cas, les numéros
de séquence des paquets décrivent le cycle complet de 0 à 127. Le plan du numérotage de la séquence de
paquets modulo 8 ou 128 est le même pour les deux sens de transmission; il est commun à toutes les voies
logiques de l’interface ETTD/ETCD.
Seuls les paquets de données contiennent ce numéro de séquence appelé numéro de séquence
de paquet en émission P(S).
Le premier paquet de données à transmettre à travers l’interface ETTD/ETCD dans un sens de
transmission donné, lorsque la voie logique vient de passer à l’état contrôle de flux prêt (d1), a un numéro
de séquence de paquet en émission P(S) égal à 0.
Édition 2009
SUPPLéMENT ii-13
4.4.1.2
II-13/35
Description de la fenêtre
à l’interface ETTD/ETCD, une fenêtre est définie pour chaque sens de transmission des données
d’une voie logique utilisée pour une communication virtuelle ou un circuit virtuel permanent. La fenêtre
est l’ensemble ordonné de W numéros de séquence de paquet en émission consécutifs des paquets de
données autorisés à traverser l’interface.
Le plus petit numéro de séquence de la fenêtre est appelé limite inférieure de la fenêtre. à
l’instant qui suit l’entrée d’une communication virtuelle ou d’un circuit virtuel permanent dans l’état
contrôle de flux prêt (d1), à l’interface ETTD/ETCD, la limite inférieure de la fenêtre relative à chaque sens
de transmission est égale à zéro.
Le numéro de séquence de paquet en émission du premier paquet de données non autorisé
à traverser l’interface a la valeur de la limite inférieure de la fenêtre augmentée de W (modulo 8 ou 128
lorsque la numérotation est étendue).
La taille normalisée W de la fenêtre est égale à 2 pour chaque sens de transmission des données
à l’interface ETTD/ETCD. De plus, d’autres tailles de fenêtre peuvent être offertes par les Administrations.
Il est possible de choisir une taille de fenêtre optionnelle pendant un intervalle déterminé comme taille de
fenêtre par défaut commune à toutes les communications virtuelles à l’interface ETTD/ETCD (voir le § 6.10).
Il est possible de choisir une valeur autre que la taille par défaut pour un certain temps pour chaque circuit
virtuel permanent (voir le § 6.10). La négociation de la taille de la fenêtre peut se faire communication par
communication avec le service complémentaire de négociation du paramètre de contrôle de flux (voir le
§ 6.12).
4.4.1.3
Principes de contrôle de flux
Lorsque le numéro de séquence P(S) du prochain paquet de données à transmettre par l’ETCD
est à l’intérieur de la fenêtre, l’ETCD est autorisé à transmettre ce paquet de données à l’ETTD. Lorsque le
numéro de séquence P(S) du prochain paquet de données à transmettre par l’ETCD est à l’extérieur de la
fenêtre, l’ETCD ne transmet pas de paquets de données à l’ETTD. L’ETTD doit suivre la même procédure.
Lorsque le numéro de séquence P(S) du paquet de données reçu par l’ETCD est le numéro qui suit
à l’intérieur de la fenêtre, l’ETCD accepte ce paquet de données. Un paquet de données reçu qui contient un
P(S) hors séquence [c’est-à-dire répétition ou trou dans la numérotation du P(S)], à l’extérieur de la fenêtre,
ou qui n’est pas égal à 0 pour le premier paquet de données après le passage à l’état contrôle de flux prêt
(dl), est considéré par l’ETCD comme une erreur de procédure locale. L’ETCD réinitialise la communication
virtuelle ou le circuit virtuel permanent (voir le § 4.4.3). L’ETTD doit suivre la même procédure.
Le numéro de séquence de paquet en réception P(R) est défini comme un nombre (modulo 8,
ou 128 lorsqu’il est étendu) qui achemine à travers l’interface ETTD/ETCD une information provenant du
récepteur et concernant la transmission des paquets de données. Lorsqu’il est transmis à travers l’interface
ETTD/ETCD, un numéro P(R) devient la limite inférieure de la fenêtre. De cette façon, le récepteur peut
autoriser des paquets de données supplémentaires à traverser l’interface ETTD/ETCD.
Le numéro de séquence de paquet en réception P(R) est acheminé par les paquets de données,
prêt à recevoir (RR) et non prêt à recevoir (RNR).
La valeur d’un numéro P(R) reçu par l’ETCD doit rester dans l’intervalle entre le dernier P(R) reçu
par l’ETCD et le numéro de séquence de paquet en émission du prochain paquet de données à transmettre
par l’ETCD y compris ce dernier numéro de séquence. Dans le cas contraire, l’ETCD considère la réception
de ce P(R) comme une erreur de procédure et réinitialise la communication virtuelle ou le circuit virtuel
permanent. L’ETTD doit suivre la même procédure.
Le numéro de séquence en réception P(R) est inférieur ou égal au numéro de séquence du
prochain paquet de données attendu; il implique que l’ETTD ou l’ETCD qui transmet P(R) a accepté au
minimum tous les paquets de données numérotés jusqu’à P(R) – 1, y compris P(R) – 1.
4.4.1.4
Confirmation de remise
Si, dans un paquet de données où P(S) = p, le bit D est mis à 0, la signification du P(R) renvoyé
qui correspond à ce paquet de données [P(R) ≥ p + 1] équivaut à une mise à jour locale de la fenêtre, à
travers l’interface à la couche paquets; de cette manière, le débit que l’on peut atteindre n’est pas limité par
le temps de propagation aller-retour ETTD vers ETTD à travers le ou les réseau(x).
Si le bit D est mis à 0 dans un paquet de données, le P(R) renvoyé qui correspond à ce paquet
de données ne signifie pas qu’un P(R) a été reçu de l’ETTD distant.
Édition 2009
II-13/36
Si, dans un paquet de données où P(S) = p, le bit D est mis à 1, la signification du P(R) renvoyé
qui correspond à ce paquet de données [P(R) ≥ p + 1] constitue une indication qu’un P(R) a été reçu
en provenance de l’ETTD distant pour tous les bits du paquet de données dans lequel le bit D avait été
initialement mis à 1.
Remarque 1: Lorsqu’il reçoit un paquet de données dont le bit D a été mis à 1, un ETTD doit transmettre le P(R)
correspondant des que possible afin d’éviter tout risque de temps mort (par exemple, sans attendre
d’autres paquets de données). Un paquet de données, un paquet RR ou un paquet RNR peut être
utilisé pour transmettre le P(R) (voir la remarque du § 4.4.1.6). De même, l’ETCD doit envoyer le
P(R) à l’ETTD dès que possible après la réception du P(R) provenant de l’ETTD distant. Lorsque
l’ETTD ne met pas en œuvre la procédure du bit D, la réception d’un paquet de données avec le bit
D mis à 1 peut être traitée par l’ETTD comme une erreur.
Remarque 2: Si un P(R) est en instance pour un paquet de données dont le bit D est mis à 1, la mise à jour locale
de la fenêtre sera ajournée pour les paquets de données ultérieurs dont le bit D est mis à 0. Certains
réseaux peuvent aussi différer la mise à jour de la fenêtre pour les paquets de données précédents
(à l’intérieur de la fenêtre) avec le bit D mis à 0 jusqu’au moment où le P(R) correspondant pour le
paquet avec le bit D mis à 1 en instance est transmis à l’ETTD.
Remarque 3: Les valeurs de P(R) correspondant aux données contenues dans des paquets de données dont le bit
D est mis à 1 ne sont pas nécessairement les mêmes aux interfaces ETTD/ETCD, à chaque extrémité
d’une communication virtuelle ou d’un circuit virtuel permanent.
Remarque 4: Si l’ETTD, a émis des paquets de données dont le bit D est mis à 0, l’ETTD n’a pas à attendre la
mise à jour locale de la fenêtre par l’ETCD avant d’entamer une procédure de réinitialisation ou de
libération.
4.4.1.5
Paquets prêt à recevoir (RR) provenant de l’ETTD ou de l’ETCD
Les paquets RR sont utilisés soit par l’ETTD, soit par l’ETCD, pour indiquer qu’il est prêt à
recevoir les W paquets de données qui sont à l’intérieur de la fenêtre, en partant de P(R), P(R) étant le
numéro indiqué dans le paquet RR.
4.4.1.6
Paquets non prêt à recevoir (RNR) provenant de l’ETTD ou de l’ETCD
Les paquets RNR sont utilisés soit par l’ETTD, soit par l’ETCD, pour indiquer une incapacité
temporaire d’accepter des paquets de données supplémentaires pour une communication virtuelle ou un
circuit virtuel permanent donné. Lorsqu’il reçoit un paquet RNR, un ETCD ou un ETTD cesse de transmettre
des paquets de données sur la voie logique concernée, mais la fenêtre est mise à jour par la valeur de P(R) du
paquet RNR. L’état non prêt à recevoir indiqué par la transmission d’un paquet RNR est annulé soit par la
transmission dans le même sens d’un paquet RR, soit par le lancement d’une procédure de réinitialisation.
La transmission d’un paquet RR après un paquet RNR, à la couche paquets, ne doit pas être
considérée comme une demande de retransmission de paquets qui ont déjà été transmis.
Remarque:
Le paquet RNR peut être utilisé pour transférer à travers l’interface ETTD/ETCD la valeur de P(R)
correspondant à un paquet de données dont le bit D était mis à 1, dans le cas où des paquets de
données supplémentaires ne peuvent pas être acceptés.
4.4.2
Caractéristiques de débit et classes de débit
Les définitions du débit et du débit en régime permanent sont indiquées au § 4 de la
Une classe de débit pour un sens de transmission donné est une caractéristique intrinsèque de
la communication virtuelle ou du circuit virtuel permanent, concernant la quantité de ressources attribuées
à cette communication ou à ce circuit. Elle donne la mesure du débit en régime permanent qui peut être
assuré dans les conditions optimales dans la communication virtuelle ou le circuit virtuel permanent.
Toutefois, en raison de la répartition statistique des ressources de transmission et de commutation, il n’est
pas garanti que la classe de débit puisse être réalisée pendant 100 % du temps.
Les relations entre la classe de débit et les paramètres et objectifs de débit décrits dans la
Recommandation X.135 doivent faire l’objet d’un complément d’étude. La définition complète des conditions
optimales dans lesquelles la mesure du débit en régime permanent par rapport à la classe de débit devient
significative doit également faire l’objet d’un complément d’étude. En attendant le résultat de ces études
ultérieures, l’on ne peut garantir ni vérifier qu’un réseau ayant une valeur donnée de classe de débit (64 kbit/s
par exemple) offre une meilleure qualité de fonctionnement à ses usagers qu’un réseau n’ayant pas cette classe
de débit. Toutefois, un réseau peut offrir une garantie à ses usagers sur une base contractuelle.
Édition 2009
SUPPLéMENT ii-13
II-13/37
Les conditions optimales de mesure comprennent les suivantes:
1) Les caractéristiques de la ligne d’accès des ETTD local et distant ne limitent pas la classe de débit;
Remarque: En particulier, compte tenu de la marge due aux en-têtes de trame et de paquet, lorsque la classe de
débit correspondant à la catégorie d’usagers du service de l’ETTD s’applique à une communication
virtuelle ou à un circuit virtuel permanent, un débit en régime permanent égal à cette classe de
débit ne peut jamais être atteint.
2) Les tailles de fenêtre aux interfaces ETTD/ETCD locale et distante ne limitent pas le débit;
3) Les caractéristiques de trafic d’autres voies logiques aux interfaces ETTD/ETCD locale et distante ne
limitent pas le débit;
4) L’ETTD récepteur ne contrôle pas le flux de l’ETCD n’empêchant pas ainsi d’atteindre la classe de
débit;
5) L’ETTD émetteur n’envoie que des paquets de données dont le champ de données a la longueur maximale;
6) Le bit D n’est pas mis à 1.
La classe de débit s’exprime en bits par seconde. La longueur maximale du champ de données
est spécifiée pour une communication virtuelle ou un circuit virtuel permanent; en conséquence, la classe
de débit peut être interprétée par l’ETTD comme étant le nombre de paquets de données complets par
seconde à l’interface ETTD/ETCD.
En l’absence du service complémentaire attribution de classes de débit par défaut (voir le § 6.11),
les classes de débit par défaut pour les deux sens de transmission correspondent à la catégorie d’usager de l’ETTD
(voir le § 7.2.2.2) mais ne dépassent pas la classe de débit maximale assurée par le réseau. La négociation des
classes de débit communication par communication peut être effectuée au moyen du service complémentaire
de négociation de la classe de débit (voir le § 6.13).
Remarque:
La somme des classes de débit de toutes les communications virtuelles et de tous les circuits virtuels
permanents admis à une interface ETTD/ETCD peut dépasser la vitesse de transmission de données
de la ligne d’accès.
4.4.3
Procédure de réinitialisation
Cette procédure est utilisée pour réinitialiser une communication virtuelle ou un circuit virtuel
permanent. Ce faisant, elle supprime, dans les deux sens, tous les paquets de données ou d’interruption
qui peuvent se trouver dans le réseau (voir le § 4.5). Lorsqu’une communication virtuelle ou un circuit
virtuel permanent vient d’être réinitialisé à l’interface ETTD/ETCD, la valeur de la limite inférieure de
fenêtre relative à chaque sens de transmission des données est égale à zéro, et la numérotation des paquets
de données qui traversent par la suite l’interface ETTD/ETCD dans chaque sens de transmission reprend à
partir de zéro.
La procédure de réinitialisation ne peut s’appliquer que dans l’état transfert des données (p4)
de l’interface ETTD/ETCD. Dans tout autre état de l’interface ETTD/ETCD, la procédure de réinitialisation
est abandonnée. Par exemple, lorsqu’une procédure de libération ou de reprise est déclenchée, les paquets
de demande de réinitialisation et d’indication de réinitialisation peuvent être laissés sans confirmation.
Pour ce qui est du contrôle du flux, il y a trois états: d1, d2 et d3 à l’intérieur de l’état transfert
des données (p4). Ce sont: contrôle de flux prêt (d1), demande de réinitialisation par l’ETTD (d2), indication
de réinitialisation par l’ETCD (d3), comme indiqué sur le diagramme d’état de la figure B-3/X.25. Lorsqu’elle
entre dans l’état p4, la voie logique est placée dans l’état d1. Le tableau C-4/X.25 précise les actions entreprises
par l’ETCD à la réception de paquets provenant de l’ETTD.
4.4.3.1
Paquet de demande de réinitialisation
L’ETTD indique une demande de réinitialisation en émettant un paquet de demande de
réinitialisation précisant la voie logique à réinitialiser. Ceci place la voie logique à l’état demande de
réinitialisation par l’ETDD (d2).
4.4.3.2
Paquet d’indication de réinitialisation
L’ETCD signale une réinitialisation en transmettant à l’ETTD un paquet d’indication de
réinitialisation précisant la voie logique en cours de réinitialisation et la raison de la réinitialisation. Ceci
place la voie logique à l’état indication de réinitialisation par l’ETCD (d3). Dans cet état, l’ETCD ne tient pas
compte des paquets de données, d’interruption, RR et RNR.
Édition 2009
II-13/38
4.4.3.3
Collision de réinitialisations
II se produit une collision de réinitialisations lorsqu’un ETTD et un ETCD émettent
simultanément un paquet de demande de réinitialisation et un paquet d’indication de réinitialisation
précisant la même voie logique. Dans ce cas, l’ETCD considère que la réinitialisation est achevée. L’ETCD
n’attend pas de paquet de confirmation de réinitialisation par l’ETTD; il n’émet pas non plus de paquet de
confirmation de réinitialisation par l’ETCD. Ceci place la voie logique à l’état de contrôle de flux prêt (d1).
4.4.3.4
Paquets de confirmation de réinitialisation
Lorsque la voie logique est à l’état demande de réinitialisation par l’ETTD (d2), l’ETCD confirme
la réinitialisation en transmettant à l’ETTD un paquet de confirmation de réinitialisation par l’ETCD. Ceci
place la voie logique à l’état contrôle de flux prêt (d1).
Le paquet de confirmation de réinitialisation par l’ETCD ne peut être interprété universellement
qu’avec une signification locale; toutefois, dans les réseaux de certaines Administrations, la confirmation
de réinitialisation peut avoir une signification de bout en bout. Dans tous les cas, le temps passé à l’état de
demande de réinitialisation par l’ETTD (d2) ne dépasse pas le temps-limite T22 (voir l’annexe D).
Lorsque la voie logique est à l’état d’indication de réinitialisation par l’ETCD (d3), l’ETTD
confirme la réinitialisation en transmettant à l’ETCD un paquet de confirmation de réinitialisation par
l’ETTD. Ceci place la voie logique à l’état contrôle de flux prêt (d1). L’action entreprise par l’ETCD lorsque
l’ETTD ne confirme pas la réinitialisation durant la temporisation T12 est indiquée dans l’annexe D.
4.5Effets des procédures de libération, de réinitialisation et de reprise sur le transfert
des paquets
Tous les paquets de données et d’interruption émis par l’ETTD (ou par le réseau) avant le
déclenchement, par l’ETTD ou par l’ETCD, d’une procédure de libération, de réinitialisation ou de reprise
à l’interface locale sont remis à l’ETTD distant avant que l’ETCD transmette l’indication correspondante à
l’interface distante, ou mis au rebut par le réseau.
Aucun paquet de données ou d’interruption émis par un ETTD (ou le réseau) après l’achèvement
d’une procédure de réinitialisation (ou d’une procédure de reprise s’agissant de circuits virtuels permanents)
à l’interface locale n’est remis à l’ETTD distant avant l’achèvement de la procédure de réinitialisation
correspondante à l’interface distante.
Quand un ETTD déclenche une procédure de libération, de réinitialisation ou de reprise à
son interface locale, tous les paquets de données et d’interruption, qui ont été émis par l’ETTD distant (ou
par le réseau) avant que l’indication correspondante ait été transmise à l’ETTD distant sont remis à l’ETTD
d’origine avant la confirmation par l’ETCD de la demande de libération, de réinitialisation ou de reprise, ou
mis au rebut par le réseau.
Remarque:
Le nombre maximal de paquets qui peuvent être mis au rebut dépend du temps de propagation de
bout en bout dans le réseau et des caractéristiques de débit; d’une manière générale, il ne dépend pas
de la taille de la fenêtre locale. Pour les communications virtuelles et les circuits virtuels permanents
sur lesquels tous les paquets de données sont transférés avec le bit D mis à 1, le nombre maximal de
paquets pouvant être mis au rebut dans un sens de transmission donné ne dépasse pas la taille de la
fenêtre correspondant à ce sens de transmission.
4.6Effets de la couche physique et de la couche liaison de données sur la couche paquets
4.6.1
En général, si un problème est détecté dans une couche (couche physique, couche liaison
de données ou couche paquets) et peut être résolu dans cette couche conformément aux procédures de
correction d’erreur de l’ETCD fournies dans la présente Recommandation sans perte ou répétition de
données, les couches adjacentes ne sont pas impliquées dans la correction d’erreur.
Si une correction d’erreur par l’ETCD implique perte ou répétition de données, la couche
supérieure en est informée.
La réinitialisation d’une couche par l’ETCD n’est exécutée que si un problème ne peut pas être
résolu dans cette couche.
Les changements d’état de fonctionnement subis par la couche physique et la couche liaison
de données de l’interface ETTD/ETCD n’impliquent pas un changement de l’état de chaque voie logique à la
Édition 2009
II-13/39
SUPPLéMENT ii-13
couche paquets. Lorsqu’ils se produisent, ces changements sont explicitement indiqués à la couche paquets
au moyen de procédures de reprise, de libération ou de réinitialisation, selon le cas.
4.6.2
Définition d’une condition hors service
Dans le cas d’une procédure à liaison unique, il y a condition hors service lorsque:
–
Une défaillance de la couche physique et/ou de la couche liaison de données est détectée; cette défaillance se définit comme une condition dans laquelle l’ETCD ne peut pas émettre ou recevoir de trames
en raison de conditions anormales dues, par exemple, à un défaut de ligne entre l’ETTD et l’ETCD;
Remarque:De brèves interruptions à la couche physique (par exemple, perte de la porteuse) ne sont pas
considérées comme des défaillances de la couche physique par l’ETCD et, ni la couche liaison de
données, ni la couche paquets n’en sont informées.
–
L’ETCD a reçu ou émis une commande DISC.
Il peut exister d’autres conditions hors service dépendant du réseau telles que: réinitialisation
de la couche liaison de données, arrivée en fin de course du temporisateur T3 (voir le § 2.4.5.3), réception
ou transmission d’une réponse DM, etc.
Dans le cas de la procédure multiliaison, une condition hors service est censée s’être produite
lorsqu’elle se présente en même temps pour chacune des procédures à liaison unique de l’interface ETTD/
ETCD. Il peut exister d’autres conditions hors service dépendant du réseau telles que l’exécution par l’ETTD
ou l’ETCD de la procédure de réinitialisation multiliaison (voir le § 2.5.4.2), la perte de trame(s) multiliaison
(voir le § 2.5.4.4), etc.
4.6.3
Interventions se produisant à la couche paquets lorsqu’une condition hors service est détectée
Lorsqu’une condition hors service est détectée, l’ETCD transmet à l’extrémité distante:
1) Une réinitialisation avec la cause “hors service” pour chaque circuit virtuel permanent, et
2) Une libération avec la cause “hors service” pour chaque communication virtuelle existante.
4.6.4
Interventions se produisant à la couche paquets pendant une condition hors service
Pendant une condition hors service:
1) L’ETCD libère toute communication virtuelle entrante avec la cause “hors service”;
2)Pour tout paquet de données ou d’interruption reçu de l’ETTD distant sur un circuit virtuel permanent,
l’ETCD réinitialise le circuit, virtuel permanent avec la cause “hors service”;
3) Un paquet de réinitialisation reçu de l’ETTD distant sur un circuit virtuel permanent est confirmé à
l’ETTD distant par un paquet de confirmation de réinitialisation ou d’indication de réinitialisation.
4.6.5
Interventions se produisant à la couche paquets après correction de la condition hors service
Une fois la condition hors service corrigée:
1) L’ETCD envoie un paquet d’indication de reprise avec la cause “réseau opérationnel” à l’ETTD local;
2) Une réinitialisation avec la cause “ETTD distant opérationnel” est transmise à l’extrémité distante de
chaque circuit virtuel permanent.
5.Format des paquets
5.1
Un complément d’étude est nécessaire pour déterminer les possibilités d’extension des formats
de paquets, par adjonction de nouveaux champs.
Remarque:
Ces champs:
a) Seraient fournis exclusivement en tant qu’adjonction à la suite de tous les champs définis précédemment, et
non comme une insertion entre les champs définis précédemment;
b) Seraient transmis à un ETTD seulement dans l’un des deux cas suivants: si l’ETCD a été informé que l’ETTD
est capable d’interpréter ce champ et d’entreprendre une action en réponse à ce champ; ou si l’ETTD peut ne
pas tenir compte du champ, sans pour autant influencer défavorablement le fonctionnement de l’interface
ETTD/ETCD (y compris en matière de taxation);
Édition 2009
II-13/40
c)Ne contiendraient aucune information concernant un service complémentaire d’usager auquel l’ETTD n’a
pas souscrit, sauf dans le cas où l’ETTD peut ne pas tenir compte du service complémentaire sans pour
autant influencer défavorablement le fonctionnement de l’interface ETTD/ETCD (y compris en matière de
taxation).
Les bits d’un octet sont numérotés de 8 à 1, le bit 1 étant le bit de faible poids, transmis en
premier. Les octets d’un paquet sont numérotés à la suite, à partir de 1; ils sont transmis dans cet ordre.
5.1.1
Identificateur général de format (IGF)
Le champ de l’identificateur général de format est un champ codé de quatre bits, qui sert à
indiquer le format général du reste de l’en-tête du paquet. Il est situé dans les bits 8, 7, 6 et 5 de l’octet 1, et
le bit 5 est le bit de faible poids (voir le tableau 16/X.25).
Le bit 8 de l’identificateur général de format est utilisé comme bit qualificatif dans les paquets
de données, comme bit d’adresse dans les paquets d’établissement et de libération de la communication, et
il est mis à 0 dans tous les autres paquets.
Le bit 7 de l’identificateur général de format est utilisé pour la procédure de confirmation de
remise dans les paquets de données et les paquets d’établissement de la communication et il est mis à 0 dans
les autres paquets.
Les bits 5 et 6 sont codés pour quatre indications possibles. Deux des codes permettent de faire
la distinction entre les paquets avec numérotation modulo 8 et les paquets avec numérotation modulo 128.
Le troisième sert à indiquer une extension d’un format pour une famille de codes d’identificateur général de
format qui feront l’objet d’un complément d’étude. Le quatrième code est réservé à d’autres applications.
Remarque 1: L’ETTD doit coder l’IGF différemment selon qu’il est abonné ou non au service complémentaire de
numérotation séquentielle étendue des paquets (voir le § 6.2).
Remarque 2: On envisage que d’autres codes d’identificateur général de format (IGF) permettraient d’identifier
d’autres formats de paquets.
Tableau 16/X.25 — Identification générale de format
Identificateur général de format
Octet 1 Bits
8
7
6
5
Paquets d’établissement de Numérotation modulo 8
la communicationNumérotation modulo 128
X
X
X
X
0
1
1
0
Paquets de libérationNumérotation modulo 8
Numérotation modulo 128
X
X
0
0
0
1
1
0
Paquets de contrôle de fluxNumérotation modulo 8
d’interruption, de réinitialisation,Numérotation modulo 128
de reprise, d’enregistrement et
de diagnostic
0
0
0
0
0
1
1
0
Paquets de donnéesNumérotation modulo 8
Numérotation modulo 128
X
X
X
X
0
1
1
0
Extension de l’identificateur
général de format
0
0
1
1
Réservé à d’autres applications
*
*
0
0
* Non défini.
Remarque:
Un bit noté “X” peut être mis à 0 ou à 1, comme indiqué dans le texte.
5.1.2
Numéro de groupe de voies logiques
Le numéro de groupe de voies logiques apparaît dans chacun des paquets à l’exception des
paquets de reprise, de diagnostic et d’enregistrement dans les bits 4, 3, 2 et 1 de l’octet 1. Pour chaque voie
logique, ce numéro a une signification locale à l’interface ETTD/ETCD.
Édition 2009
II-13/41
SUPPLéMENT ii-13
Ce champ est codé en binaire et le bit 1 est le bit de faible poids du numéro de groupe de voies
logiques. Dans les paquets de reprise, de diagnostic et d’enregistrement, ce champ est codé tout en zéro.
Numéro de voie logique
5.1.3
Le numéro de voie logique apparaît dans tous les paquets à l’exception des paquets de reprise,
de diagnostic et d’enregistrement dans tous les bits de l’octet 2. Pour chaque voie logique, ce numéro a une
signification locale à l’interface ETTD/ETCD.
Le champ est codé en binaire et le bit 1 est le bit de faible poids du numéro de voie logique.
Dans les paquets de reprise, de diagnostic et d’enregistrement, ce champ est codé tout en zéro.
5.1.4
Identificateur de type de paquet
Chaque paquet est identifié dans l’octet 3 du paquet conformément au tableau 17/X.25.
Tableau 17/X.25 — Identificateur de type de paquet
Type de paquet
De l’ETCD vers l’ETTD
De l’ETTD vers l’ETCD
Octet 3
Bits
8
7
6
5
4
3
2
1
0
0
0
0
0
0
0
0
0
0
0
1
1
1
0
0
1
0
1
1
1
1
1
1
0
0
0
1
0
1
1
1
X
0
X
0
X
1
X
0
X
0
X
0
X
1
0
1
0
0
1
0
0
1
1
1
X
0
X
0
X
0
0
X
0
X
0
X
0
0
X
0
X
0
X
0
0
0
0
0
0
0
0
1
0
0
0
0
1
1
1
0
0
1
1
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
0
0
0
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
0
1
1
1
1
1
1
1
1
1
0
0
0
1
1
1
1
1
0
0
1
1
1
1
1
1
0
1
1
1
établissement et libération des communications
Appel entrant
Appel
Communication acceptée
Indicateur de libérationDemande de libération
Confirmation de libération Confirmation de libération
par l’ETCD
par l’ETTD
Données et interruption
Données de l’ETCDDonnées de l’ETTD
Interruption par l’ETCD
Interruption par l’ETTD
Confirmation de Confirmation de l’interruption par l’ETCD
l’interruption par l’ETTD
Contrôle de flux et réinitialisation
RR de l’ETCD (modulo 8)
RR de l’ETTD (modulo 8)
RR de l’ETCD (modulo 128)a) RR de l’ETTD (modulo 128)a)
RNR de l’ETCD (modulo 8) RNR de l’ETTD (modulo 8)
RNR de l’ETCD (modulo 128)a) RNR de l’ETTD (modulo 128)a)
REJ de l’ETTD (modulo 8) a) REJ de l’ETTD (modulo 128)a)
Indication de réinitialisationDemande de réinitialisation
Confirmation de
Confirmation de
réinitialisation par l’ETCD
réinitialisation par l’ETTD
Reprise
Indication de repriseDemande de reprise
Confirmation de reprise
Confirmation de reprise
par l’ETCD
par l’ETTD
Diagnostic
Diagnostica)
Enregistrementa)
Demande d’enregistrement
Confirmation
d’enregistrement
a)
N’est pas nécessairement disponible dans tous les réseaux.
Remarque:
Un bit noté “X” peut prendre la valeur 0 ou 1, comme indiqué dans le texte.
Édition 2009
II-13/42
5.2Paquets d’établissement et de libération de la communication
5.2.1
Format du bloc d’adresse
Les paquets d’établissement et de libération de la communication contiennent un bloc
d’adresse. Ce bloc d’adresse peut avoir deux formats: un format d’adresse NON TOA/NPI et un format
d’adresse TOA/NPI. Ces deux formats se distinguent par le bit 8 de l’identificateur général de format (bit A).
Lorsque le bit A est mis à 0, c’est le format d’adresse NON TOA/NPI qui est utilisé. Lorsque le bit A est mis à
1, c’est le format d’adresse TOA/NPI qui est utilisé.
Le format d’adresse NON TOA/NPI est accepté par tous les réseaux. Le format d’adresse TOA/NPI
peut être mis en œuvre par certains réseaux, et notamment par les réseaux qui souhaitent communiquer avec
des RNIS pour lesquels le format d’adresse NON TOA/NPI n’offre pas une capacité d’adressage suffisante.
Remarque:
Avant 1997, les ETTD en mode-paquet fonctionnant dans les conditions du cas B de la
Recommandation X.31 (service support de circuit virtuel de RNIS) seront appelés au moyen d’une
adresse de 12 chiffres au maximum, empruntée au plan de numérotage E.164. Après 1996, ces ETTD
en mode-paquet pourront avoir une adresse E.164 à 15 chiffres; il faudra recourir à des procédures
d’adresse TOA/NPI pour communiquer avec ces ETTD. Pour plus de renseignements, voir les
Recommandations E.165 et E.166.
Lorsqu’il transmet un paquet d’établissement ou de libération de la communication, un ETCD
utilise le format d’adresse TOA/NPI si l’ETTD s’est abonné au service complémentaire abonnement “adresse
TOA/NPI” (voir le § 6.28), et le format d’adresse NON TOA/NPI s’il n’est pas abonné.
Remarque:Dans la Recommandation X.2, il est indiqué que le service complémentaire d’abonnement “adresse
TOA/NPI” doit faire l’objet d’un complément d’étude. En outre, plusieurs points techniques liés à
ce format d’adresse TOA/NPI seront étudiés ultérieurement.
Lorsqu’il transmet un paquet d’établissement ou de libération de la communication, un ETTD
utilise le format d’adresse TOA/NPI si l’ETTD est abonné au service complémentaire abonnement “adresse
TOA/NPI” (voir le § 6.28) et le format d’adresse NON TOA/NPI s’il n’est pas abonné.
Lorsque le format d’adresse utilisé par un ETTD dans un paquet d’établissement ou de libération
de la communication est différent de celui utilisé par l’ETTD distant, le réseau (s’il fournit le format d’adresse
TOA/NPI) assure la conversion d’un format d’adresse à l’autre (voir le § 6.28).
5.2.1.1
Format du bloc d’adresse quand le bit A est mis à 0 (adresse NON TOA/NPI)
La figure 4/X.25 donne le format du bloc d’adresse quand le bit A est mis à 0.
Bits
8
7
6
5
Longueur de l’adresse de l’ETTD appelant
4
3
2
1
Longueur de l’adresse de l’ETTD appelé
Adresse de l’ETTD appelé
(voir la remarque)
Adresse de l’ETTD appelant
(voir la remarque)
0
Remarque:
0
0
La figure suppose que le nombre des chiffres d’adresses présents dans le champ d’adresse de l’ETTD
appelé est impair et que le nombre des chiffres d’adresses présents dans le champ d’adresse de
l’ETTD appelant est pair.
Figure 4/X.25 — Format du bloc d’adresse quand le bit A est mis à 0.
Édition 2009
0
II-13/43
SUPPLéMENT ii-13
5.2.1.1.1
Champs des longueurs d’adresse des ETTD appelant et appelé
Ces champs ont quatre bits de longueur chacun et se composent d’indicateurs de longueur de
champ pour les adresses des ETTD appelant et appelé. Les bits 4, 3, 2 et 1 indiquent la longueur, exprimée
en demi-octets, de l’adresse de l’ETTD appelé. Les bits 8, 7, 6 et 5 indiquent la longueur, exprimée en demioctets, de l’adresse de l’ETTD appelant. Chaque indicateur de longueur d’adresse est codé en binaire et le bit
1 ou 5 est le bit de poids faible de l’indicateur.
5.2.1.1.2
Champs d’adresse des ETTD appelé et appelant
Chaque chiffre décimal d’une adresse est codé en binaire dans un demi-octet, le bit 5 ou 1 étant
le bit de poids faible de chaque chiffre.
En partant du chiffre décimal de poids fort, l’adresse d’ETTD est codée dans des octets
consécutifs, avec deux chiffres décimaux par octet. Dans chaque octet, le chiffre décimal de poids fort est
codé dans les bits 8, 7, 6 et 5.
Lorsqu’il est présent, le champ d’adresse de l’ETTD appelant commence au premier demi-octet
suivant la fin du champ d’adresse de l’ETTD appelé. Par conséquent, lorsque le nombre des chiffres du
champ d’adresse de l’ETTD appelé est impair, le commencement du champ d’adresse de l’ETTD appelant,
lorsqu’il est présent, contient un nombre non entier d’octets.
Lorsque le nombre total des chiffres des champs d’adresse des ETTD appelé et appelant est
impair, un demi-octet avec des zéros dans les bits 4, 3, 2 et 1 est inséré après le champ d’adresse de l’ETTD
appelant pour maintenir l’alignement des octets.
On trouvera d’autres informations sur le codage des champs d’adresse des ETTD appelé et
appelant à l’appendice IV.
Remarque:
Ces champs peuvent être utilisés pour des services complémentaires facultatifs d’adressage tels que
la numérotation abrégée. Les services complémentaires facultatifs d’adressage utilisés, de même que
le codage de ces services, sont pour étude ultérieure.
5.2.1.2
Format du bloc d’adresse quand le bit A est mis à 1 (adresse TOA/NPI)
La figure 5/X.25 illustre le format du bloc d’adresse quand le bit A est mis à 1.
Bits
8
7
6
5
4
3
2
1
Longueur de l’adresse de l’ETTD appelé
Longueur de l’adresse de l’ETTD appelant
Adresse de l’ETTD appelé
(voir la remarque)
Adresse de l’ETTD appelant
(voir la remarque)
0
Remarque:
0
0
0
La figure suppose que le nombre des demi-octets présents dans le champ d’adresse de l’ETTD appelé
est impair et que le nombre des demi-octets présents dans le champ d’adresse de l’ETTD appelant
est pair.
Figure 5/X.25 — Format du bloc d’adresse quand le bit A est mis à 1
Édition 2009
II-13/44
5.2.1.2.1
Champs des longueurs d’adresse des ETTD appelé et appelant
Ces champs ont un octet de longueur chacun et se composent d’indicateurs de longueur de
champ pour les adresses des ETTD appelé et appelant. Ils indiquent la longueur, exprimée en demi-octets, de
l’adresse de l’ETTD appelé et de l’ETTD appelant, respectivement. Chaque indicateur de longueur d’adresse
d’ETTD est codé en binaire et le bit 1 est le bit de poids faible de l’indicateur.
La valeur maximale d’un indicateur de longueur de champ pour les adresses des ETTD est 17.
5.2.1.2.2
Champs d’adresse des ETTD appelé et appelant
Ces champs se composent respectivement de l’adresse de l’ETTD appelé quand elle est présente,
et de l’adresse de l’ETTD appelant quand elle est présente.
Chaque champ d’adresse de l’ETTD, lorsqu’il est présent, contient trois champs secondaires:
champ secondaire du type d’adresse (TOA), champ secondaire d’identification de plan de numérotage
(NPI), champ secondaire des chiffres de l’adresse. Les deux premiers champs secondaires se trouvent au
commencement de l’adresse et sont codés en binaire avec les valeurs indiquées aux tableaux 18/X.25 et
19/X.25.
Remarque 1:Pour le moment, il n’a pas été attribué de valeurs autres que décimales codées binaires pour les
champs secondaires de type d’adresse et d’identification de plan de numérotage.
Remarque 2: Une adresse d’ETTD contenant les champs secondaires de type d’adresse et d’identification de plan
de numérotage, mais pas celui des chiffres de l’adresse, n’est pas valable.
Les autres demi-octets d’une adresse d’ETTD sont des chiffrés, codés en binaire, le bit 5 ou 1
étant le bit de poids faible de chaque chiffre. En partant du chiffre de poids fort, les chiffres de l’adresse
sont codés en demi-octets consécutifs. Dans chaque octet, le chiffre de poids fort est codé dans les bits 8,
7, 6 et 5.
Lorsqu’il est présent, le champ d’adresse de l’ETTD appelant commence au premier demioctet suivant la fin du champ d’adresse de l’ETTD appelé. Par conséquent, lorsque le nombre des
demi-octets du champ d’adresse de l’ETTD appelé est impair, le commencement du champ d’adresse de
l’ETTD appelant, lorsqu’il est présent, contient un nombre non entier d’octets.
Lorsque le nombre total des demi-octets des champs d’adresse des ETTD appelé et appelant
est impair, un demi-octet avec des zéros dans les bits 4, 3, 2 et 1 est inséré après le champ d’adresse de
l’ETTD appelant pour maintenir l’alignement des octets.
Tableau 18/X.25 — Codage du champ secondaire de type d’adresse
Bits:
8
7
6
5
ou
Bits:
4
3
2
1
(voir remarque 1)
0
0
0
0
0
0
0
0
1
à définir
Autres valeurs
Type d’adresse
0Numéro dépendant du réseau (voir remarque 2)
1Numéro international (voir remarque 3)
0Numéro national (voir remarque 3)
Adresse complémentaire seule (voir remarque 4)
Réservé
Remarque 1: Le champ secondaire de type d’adresse du champ d’adresse de l’ETTD appelé utilise les bits 8, 7, 6 et
5. Le champ secondaire de type d’adresse du champ d’adressé de l’ETTD appelant utilise les bits 4,
3, 2 et 1 si le champ d’adresse de l’ETTD appelé ne se termine pas à la limite d’un octet; si tel n’est
pas le cas, il utilise les bits 8, 7, 6 et 5.
Remarque 2:Dans ce cas, les chiffres d’adresses présents après les champs secondaires de type d’adresse et
d’identification de plan de numérotage sont organisés conformément au plan de numérotage
du réseau. Par exemple, un préfixe ou un code d’échappement pourrait être présent. Ce cas est
équivalent à l’emploi du même point décode dans la Recommandation Q.931, où il est appelé
“inconnu”.
Remarque 3: Comme dans la Recommandation Q.931, le préfixe ou le code d’échappement ne doivent être
inclus dans le champ secondaire des chiffres de l’adresse.
Remarque 4: Voir l’appendice IV pour la définition d’une adresse complémentaire.
Édition 2009
II-13/45
SUPPLéMENT ii-13
Tableau 19/X.25 — Codage du champ secondaire d’identification de plan de numérotage
Bits:
8
7
6
5
ouPlan de numérotage
Bits:
4
3
2
1
(voir remarque 1)
0
0
1
1
X.121 (voir remarque 2)
à définirDépendant du réseau (voir remarque 3)
Autres valeurs
Réservé (voir remarque 4)
Remarque 1: Le champ secondaire d’identification du plan de numérotage du champ d’adresse de l’ETTD appelé
utilise les bits 4, 3, 2 et 1. Le champ secondaire d’identification du plan de numérotage du champ
d’adresse de l’ETTD appelant utilise les bits 8, 7, 6 et 5 si le champ d’adresse de l’ETTD appelé ne se
termine pas à la limite d’un octet; si tel n’est pas le cas, il utilise les bits 4, 3, 2 et 1.
Remarque 2: Un mécanisme équivalant à celui fourni par les chiffres d’échappement, défini dans la Recommandation
X.121, n’est pas encore défini pour servir avec les possibilités TOA/NPI; ce mécanisme n’utilisera
pas le champ secondaire d’identification du plan de numérotage. Jusqu’à ce qu’un mécanisme de ce
type soit disponible (éventuellement, un service complémentaire facultatif d’usager), seul le point
de code X.121 est utilisé. Les codes d’échappement X.121 sont appliqués et, en cas d’utilisation, le
champ secondaire de type d’adresse indique le numéro dépendant du réseau.
Remarque 3:Dans ce cas, le champ secondaire des chiffres d’adresse présent après les champs secondaires de
type d’adresse et d’identification de plan de numérotage est organisé conformément au plan de
numérotage du réseau. Par exemple, un préfixe ou un code d’échappement pourrait être présent.
Remarque 4:Parmi les valeurs réservées, sont comprises celles correspondant aux identificateurs de plan de
numérotage de la Recommandation Q.931 (par exemple, F.69, E.164).
On trouvera d’autres informations sur le codage des champs d’adresse des ETTD appelé et
appelant à l’appendice IV.
Remarque:
Ces champs peuvent être utilisés pour des services complémentaires facultatifs d’adressage tels que
la numérotation abrégée. Les services complémentaires facultatifs d’adressage utilisés, de même que
le codage de ces services, sont pour étude ultérieure.
5.2.2
Paquets d’appel et d’appel entrant
La figure 6/X.25 donne le format des paquets d’appel et d’appel entrant.
Bits
Octets
8
1
7
6
5
(voir la remarque)
2
3
4
3
2
1
0
0
0
0
4
1
0
1
1
Bloc d’adresse (voir le § 5.2.1)
Longueur de services complémentaires
Services complémentaires
Données d’appel d’usager
Remarque:
Codé XX01 (modulo 8) ou XX10 (modulo 128).
Figure 6/X.25 — Format des paquets d’appel et d’appel entrant
5.2.2.1
Le bit 8 de l’octet 1 (bit A) doit être réglé comme décrit au § 5.2.1.
Le bit 7 de l’octet 1 doit être mis à 0 à moins que le mécanisme décrit au § 4.3.3 ne soit utilisé.
Édition 2009
II-13/46
5.2.2.2
Bloc d’adresse
Le bloc d’adresse est décrit au § 5.2.1.
5.2.2.3
Champ de longueur des services complémentaires
L’octet qui suit le bloc d’adresse indique la longueur en octets du champ des services
complémentaires. L’indicateur de longueur des services complémentaires est codé en binaire, et le bit 1 est
le bit de poids faible de l’indicateur.
5.2.2.4
Champ des services complémentaires
Le champ des services complémentaires n’est présent que lorsque l’ETTD utilise un service
complémentaire facultatif d’usager nécessitant une indication dans les paquets d’appel et d’appel entrant.
Le codage du champ des services complémentaires est défini aux § 6 et 7.
Le champ des services complémentaires contient un nombre entier d’octets. La longueur
maximale effective de ce champ dépend des services complémentaires qui sont offerts par le réseau.
Cependant, ce maximum n’excède pas 109 octets.
Remarque:
Le point de savoir si une autre valeur devrait être définie, relativement au nombre total d’octets du
paquet, doit faire l’objet d’un complément d’étude.
5.2.2.5
Champ des données d’appel de l’usager
Faisant suite au champ des services complémentaires, le champ des données d’appel de l’usager
peut être présent, avec une longueur maximale de 128 octets lorsqu’il est utilisé conjointement avec le
service complémentaire de sélection rapide décrit au § 6.16 et de 16 octets dans l’autre cas.
Remarque:
Certains réseaux exigent que le champ des données d’appel de l’usager contienne un nombre entier
Lorsqu’une communication virtuelle est en cours d’établissement entre deux ETTD en modepaquet, le réseau ne réagit à aucune partie du champ des données d’appel de l’usager. Voir la Recommandation
X.244 pour les autres cas.
5.2.3
Paquets de communication acceptée et de communication établie
La figure 7/X.25 donne le format des paquets de communication acceptée et de communication
établie dans le format de base et le format étendu.
Bits
Octets
8
1
7
6
4
4
3
2
1
(voir la remarque)
2
3
5
0
0
0
0
1
1
1
1
Bloc d’adressea) (voir le § 5.2.1)
Longueur des services complémentairesa)
Services complémentairesa)
Données d’appel d’usagerb)
Figure 7/X.25 — Format des paquets de communication acceptée et de communication établie
Ces champs ne sont pas obligatoires dans les paquets de communication acceptée dans le format de base (voir
le § 5.2.3.1).
b)
Ce champ peut être présent seulement dans le format étendu (voir le § 5.2.3.2).
a)
Remarque: Codé XX01 (modulo 8) ou XX10 (modulo 128).
Édition 2009
SUPPLéMENT ii-13
II-13/47
5.2.3.1
Format de base
5.2.3.1.1
Le bit 8 de l’octet 1 (bit A) doit être réglé comme décrit au § 5.2.1.
Le bit 7 de l’octet 1 doit être mis à 0 à moins que le mécanisme décrit au § 4.3.3 ne soit utilisé.
5.2.3.1.2
Bloc d’adresse
L’utilisation des champs de longueur d’adresse des ETTD appelant et appelé dans les paquets
de communication acceptée n’est obligatoire que lorsque le champ de l’adresse de l’ETTD appelé, le champ
de l’adresse de l’ETTD appelant ou le champ de longueur des services complémentaires est présent.
5.2.3.1.3
Champ de longueur des services complémentaires
complémentaires. L’indicateur de longueur de ces services est codé en binaire, et le bit 1 est le bit de poids
faible de l’indicateur.
L’utilisation du champ de longueur des services complémentaires dans les paquets de
communication acceptée n’est obligatoire que lorsque le champ des services complémentaires est présent.
5.2.3.1.4
Le champ des services complémentaires n’est présent que lorsque l’ETTD utilise un service
complémentaire facultatif d’usager nécessitant une indication dans les paquets de communication acceptée
et de communication établie.
Remarque:
5.2.3.2
Format étendu
Le format étendu ne peut être utilisé que conjointement avec le service complémentaire de
sélection rapide décrit au § 6.16. Dans ce cas, le champ des données d’appel de l’usager peut être présent et
sa longueur maximale est de 128 octets.
Les champs de longueur d’adresse des ETTD appelant et appelé et le champ des services
complémentaires doivent être présents lorsque le champ des données d’appel de l’usager est présent.
Remarque:
Certains réseaux exigent que le champ des données d’appel de l’usager contienne un nombre entier
Lorsqu’une communication virtuelle est en cours d’établissement entre deux ETTD en modepaquet, le réseau ne réagit à aucune partie du champ des données d’appel de l’usager. Voir la Recommandation
X.244.
5.2.4
Paquets de demande de libération et d’indication de libération
La figure 8/X.25 donne le format des paquets de demande de libération et d’indication de
libération, dans les formats de base et étendus.
5.2.4.1
Format de base
5.2.4.1.1
Champ de cause de libération
L’octet 4 est le champ de cause de libération; il indique la cause de la libération de la
communication.
Édition 2009
II-13/48
Bits
Octets
8
1
7
6
5
4
(voir la remarque)
2
3
2
1
3
0
0
0
1
0
4
Cause de libération
5
Code de diagnostica)
4
Bloc d’adresseb) (voir le § 5.2.1)
0
1
1
Longueur de service complémentaireb)
Services complémentairesb)
Données de libération de l’usagerb)
a)
Ce champ n’est pas obligatoire dans les paquets de demande de libération du format de base (voir le
§ 5.2.4.1)
b)
Utilisé seulement dans le format étendu (voir le § 5.2.4.2).
Remarque: Codé X001 (modulo 8) ou X010 (modulo 128).
Figure 8/X.25 — Format des paquets de demande de libération et d’indication de libération
Dans les paquets de demande de libération, l’ETTD doit mettre le champ de cause de libération
à l’une des valeurs suivantes:
Bits:
8 7 6 5 4 3 2 1
Valeur:
0 0 0 0 0 0 0 0
ou:
1 X X X X X X
où chaque X indépendamment des autres peut être mis à 0 ou 1 par l’ETTD.
L’ETCD empêche les valeurs du champ de cause de libération autres que celles figurant cidessus d’atteindre l’autre extrémité de la communication, soit en acceptant le paquet de demande de
communication et en mettant tous les bits du champ de cause de libération à 0 dans le paquet d’indication
de libération correspondant, soit en considérant la demande de libération comme une erreur et en suivant
la procédure décrite à l’annexe C.
Le codage du champ de cause de libération contenu dans les paquets d’indication de libération
est indiqué au tableau 20/X.25.
5.2.4.1.2
Code de diagnostic
L’octet 5 est le code de diagnostic et contient l’information supplémentaire sur la cause de la
libération de la communication.
Le code de diagnostic n’est pas obligatoire dans un paquet de demande de libération.
Dans un paquet d’indication de libération, si le champ de cause de libération indique “origine:
ETTD”, le code de diagnostic est transmis sans changement par l’ETTD qui effectue la libération. Si cet
ETTD n’a pas donné de code de diagnostic dans son paquet de demande de libération, les bits du code de
diagnostic, dans le paquet d’indication de libération résultant, sont tous mis à zéro.
Si un paquet d’indication de libération a pour origine un paquet de demande de reprise, la
valeur du code de diagnostic est la valeur précisée dans le paquet de demande de reprise; ou, si aucun
code de diagnostic n’a été spécifié dans le paquet de demande de reprise, tous les bits du code sont mis
à 0.
Édition 2009
II-13/49
SUPPLéMENT ii-13
Tableau 20/X.25 — Codage du champ de cause de libération dans le paquet d’indication de libération
Bits
8
7
6
5
4
3
2
1
Origine: ETTD
Origine: ETTDa)
0
1
0
X
0
X
0
X
0
X
0
X
0
X
0
X
Numéro occupé
Dérangement
Erreur de procédure distante
Acceptation de la taxation à l’arrivée non souscriteb)
Destination incompatible
Acceptation de la sélection rapide non souscriteb)
Navire absentc)
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
1
0
0
1
1
0
0
1
0
1
0
1
1
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
Demande de service complémentaire non valable
Accès interdit
Erreur de procédure locale
0
0
0
0
0
0
0
0
0
0
0
1
0
1
0
0
0
0
1
1
1
1
1
1
Saturation du réseau
Numéro inconnu
EPR en dérangementb)
0
0
0
0
0
0
0
0
0
1
1
1
0
0
1
1
0
0
0
1
0
1
0
1
a)
Lorsque le bit 8 est mis à 1, les bits représentés par X sont ceux inclus par l’ETTD distant dans le champ de cause
de libération ou de reprise, du paquet de libération ou de demande de reprise selon le cas.
b)
Peut être reçu seulement si le service complémentaire facultatif d’usager correspondant est utilisé.
c)
Utilisé dans le service mobile maritime.
Si le champ de cause de libération n’indique pas “origine: ETTD”, le code de diagnostic
contenu dans le paquet d’indication de libération est émis par le réseau. L’annexe E donne la liste des codes
applicables aux diagnostics émis par le réseau. Les bits du code de diagnostic sont tous mis à zéro si aucune
information supplémentaire spécifique n’est fournie pour la libération.
Remarque:
Le contenu du champ de code de diagnostic ne modifie pas la signification du champ de cause. Un
ETTD n’est pas tenu d’entreprendre une action quelconque en réponse au contenu du champ de
code de diagnostic. Des combinaisons de code non précisées, dans le champ de code de diagnostic,
ne provoquent pas le refus du champ de cause par l’ETTD.
5.2.4.2
Format étendu
Le format étendu n’est utilisé pour les paquets de demande de libération et d’indication de
libération que lorsque l’ETTD ou l’ETCD désire utiliser les champs d’adresse des ETTD appelé et appelant, le
champ des services complémentaires et/ou le champ des données de libération de l’usager conjointement
avec un ou plusieurs services complémentaires facultatifs de l’usager décrits aux § 6 et 7. Le champ
d’adresse de l’ETTD appelé n’est utilisé que si le service complémentaire de notification de modification
de l’adresse de la ligne du demandé est utilisé pour la libération, en réponse à un paquet d’appel entrant
ou d’appel.
Si le format étendu est utilisé, le champ de code de diagnostic, les champs des longueurs
d’adresse d’ETTD et le champ de longueur de service complémentaire doivent être présents. Facultativement,
le champ de données de libération de l’usager peut également être présent.
5.2.4.2.1
Bloc d’adresse
5.2.4.2.2
Champ de longueur de service complémentaire
complémentaires. L’indicateur de longueur de service complémentaire est codé en binaire, et le bit 1 est le
bit de poids faible de l’indicateur.
Édition 2009
II-13/50
5.2.4.2.3
Le champ des services complémentaires n’est présent dans le paquet de demande de libération
ou d’indication de libération que lorsqu’il est utilisé conjointement avec un ou plusieurs services
complémentaires facultatifs nécessitant une indication dans ce paquet.
Remarque:
5.2.4.2.4
Champ des données de libération de l’usager
Ce champ ne peut être présent que conjointement avec le service complémentaire de sélection
rapide (voir le § 6.16) ou avec le service complémentaire de choix de détournement des appels (voir le
§ 6.25.2.2). Il a une longueur maximale de 128 octets dans le premier cas, ou de 16 ou 128 octets dans le
second cas; le point de savoir si la longueur maximale est de 16 ou 128 octets en cas d’utilisation du service
complémentaire de choix de détournement des appels est spécifié au § 6.25.2.2.
Remarque 1: Certains réseaux exigent que le champ des données de libération de l’usager contienne un nombre
entier d’octets (voir la remarque du § 3).
Remarque 2: Ce réseau ne réagit à aucune partie du champ de libération de l’usager. Voir la Recommandation
X.244.
5.2.5
Paquets de confirmation de libération par l’ETCD et l’ETTD
La figure 9/X.25 donne le format des paquets de confirmation de libération par l’ETTD ou
l’ETCD dans les formats de base ou étendu.
Le format étendu ne peut être utilisé, pour les paquets de confirmation de libération par l’ETCD,
que conjointement avec le service complémentaire d’information de taxation décrit au § 6.22. Il n’est pas
utilisé pour les paquets de confirmation de libération par l’ETTD.
Bits
Octets
8
1
7
6
5
4
(voir la remarque)
2
3
2
1
3
0
0
0
1
0
1
1
1
Bloc d’adressea) (voir le § 5.2.1)
4
Longueur de services complémentairesa)
Services complémentairesa)
Utilisé seulement dans le format étendu des paquets de confirmation de libération par l’ETCD.
Remarque: Codé X001 (modulo 8) ou X010 (modulo 128).
a)
Figure 9/X.25 — Format des paquets de confirmation de libération par l’ETTD ou l’ETCD
5.2.5.1
Bloc d’adresse
Les champs des longueurs d’adresse des ETTD appelant et appelé sont codés tout en zéro et les
champs d’adresse des ETTD appelé et appelant ne sont pas présents.
Édition 2009
II-13/51
SUPPLéMENT ii-13
5.2.5.2
Champ de longueur de service complémentaire
complémentaires. L’indicateur de longueur de ces services est codé en binaire, et le bit 1 est le bit de poids
faible de l’indicateur.
5.2.5.3
Remarque:
5.3Paquets de données et d’interruption
5.3.1
Paquets de données de l’ETTD et de l’ETCD
La figure 10/X.25 donne le format des paquets de données de l’ETTD et de l’ETCD.
Bits
Octets
8
1
7
6
5
4
QD
0
2
3
2
1
1
3
P(R)
M
P(S)
0
Données de l’utilisateur
(Modulo 8)
Bits
Octets
1
8
7
6
5
QD
2
1
4
3
2
1
0
3
P(S)
0
4
P(R)
M
Données de l’utilisateur
(En cas d’extension à modulo 128)
D
M
Q
Bit de confirmation de remise
Bit “données à suivre”
Bit qualitatif
Figure 10/X.25 — Format des paquets de données de l’ETTD ou l’ETCD
5.3.1.1
Bit (Q) qualificatif
Le bit 8 de l’octet 1 est le bit (Q) qualificatif.
Édition 2009
II-13/52
5.3.1.2
Bit (D) de confirmation de remise
Le bit 7 de l’octet 1 est le bit (D) de confirmation de remise.
5.3.1.3
Numéro de séquence de paquets en réception
Les bits 8, 7 et 6 de l’octet 3, ou les bits 8 à 2 de l’octet 4 en cas d’extension, sont utilisés pour
indiquer le numéro de séquence de paquets en réception, P(R). P(R) est codé en binaire; le bit 6, ou le bit 2
en cas d’extension, est le bit de poids faible.
5.3.1.4
Bit (M) “données à suivre”
Le bit 5 de l’octet 3, ou le bit 1 de l’octet 4 en cas d’extension, est utilisé pour l’indication
“données à suivre”: ces bits prennent la valeur 0 lorsqu’il n’y a pas de données à suivre, la valeur 1 lorsqu’il
y en a.
5.3.1.5
Numéro de séquence de paquets en émission
indiquer le numéro de séquence de paquets en émission, P(S). P(S) est codé en binaire; le bit 2 est le bit de
poids faible.
5.3.1.6
Champ des données de l’usager
l’usager.
Les bits qui suivent l’octet 3, ou l’octet 4 en cas d’extension, contiennent les données de
Remarque:
Certains réseaux exigent que le champ des données de l’usager contienne un nombre entier d’octets
(voir la remarque du § 3).
5.3.2
Paquets d’interruption par l’ETTD ou l’ETCD
La figure 11/X.25 donne le format des paquets d’interruption par l’ETTD ou l’ETCD.
Bits
Octets
8
1
7
6
5
4
3
2
1
(voir la remarque)
2
3
4
Remarque:
0
0
1
0
0
0
1
1
Données d’interruption de l’usager
Codé 0001 (modulo 8) ou 0010 (modulo 128).
Figure 11/X.25 — Format des paquets d’interruption par l’ETTD ou par l’ETCD
5.3.2.1
Champ de données d’interruption de l’usager
L’octet 4 et les octets suivants contiennent des données d’interruption de l’usager. Ce champ
peut contenir de 1 à 32 octets.
Remarque:
Édition 2009
Certains réseaux exigent que le champ de données d’interruption de l’usager contienne un nombre
entier d’octets (voir la remarque du § 3).
II-13/53
SUPPLéMENT ii-13
5.3.3
l’ETCD.
Paquets de confirmation d’interruption par l’ETTD ou l’ETCD
La figure 12/X.25 donne le format des paquets de confirmation d’interruption par l’ETTD ou
Bits
Octets
8
1
7
6
5
4
3
2
1
(voir la remarque)
2
3
Remarque:
0
0
1
0
0
1
1
1
Codé 0001 (modulo 8) ou 0010 (modulo 128).
Figure 12/X.25 — Format des paquets de confirmation d’interruption par l’ETTD ou par l’ETCD
5.4Paquets de contrôle de flux et de réinitialisation
5.4.1
Paquets prêt à recevoir (RR) de l’ETTD ou de l’ETCD
La figure 13/X.25 donne le format des paquets RR de l’ETTD ou de l’ETCD.
Bits
Octets
8
1
7
6
5
4
0
0
0
2
3
2
1
1
3
P(R)
0
0
0
0
4
3
2
1
(Modulo 8)
Bits
Octets
8
1
7
6
0
0
1
2
1
0
3
4
5
0
0
0
0
0
0
0
1
P(R)
0
Figure 13/X.25 — Format des paquets RR de l’ETTD ou l’ETCD
5.4.1.1
indiquer le numéro de séquence de paquets en réception P(R). P(R) est codé en binaire et le bit 6, ou le bit
2 en cas d’extension, est le bit de poids faible.
Édition 2009
II-13/54
5.4.2
Paquets non prêt à recevoir (RNR) de l’ETTD ou de l’ETCD
La figure 14/X.25 donne le format des paquets RNR de l’ETTD ou de l’ETCD.
Bits
Octets
8
1
7
6
5
4
0
0
2
1
0
2
3
1
3
P(R)
0
0
1
0
4
3
2
1
(Modulo 8)
Bits
Octets
8
1
7
6
0
0
1
1
2
0
3
4
5
0
0
0
0
0
0
0
1
P(R)
0
Figure 14/X.25 — Format des paquets RNR de l’ETTD ou l’ETCD
5.4.2.1
indiquer le numéro de séquence de paquets en réception P(R). P(R) est codé en binaire et le bit 6, ou le
bit 2 en cas d’extension, est le bit de poids faible.
5.4.3
Paquets de demande de réinitialisation et d’indication de réinitialisation
La figure 15/X.25 donne le format des paquets de demande de réinitialisation et d’indication
de réinitialisation.
Bits
Octets
8
1
7
6
4
(voir la remarque)
2
3
5
3
2
1
0
0
0
1
1
4
Cause de réinitialisation
5
0
1
1
a)
Ce champ n’est pas obligoire dans les paquets de demande de réinitialisation.
Remarque: Codé 0001 (modulo 8) ou 0010 (modulo 128).
Figure 15/X.25 — Format des paquets de demande de réinitialisation et d’indication de réinitialisation
Édition 2009
II-13/55
SUPPLéMENT ii-13
5.4.3.1
Champ de cause de réinitialisation
Le champ de cause de réinitialisation se situe dans l’octet 4 et contient la raison de la
réinitialisation.
Dans un paquet de demande de réinitialisation, les bits du champ de cause de réinitialisation
doivent être mis aux valeurs suivantes par l’ETTD:
Bits:
8 7 6 5 4 3 2 1
Valeur: 0 0 0 0 0 0 0 0
Ou:
1 X X X X X X X
où chaque X peut être mis à 0 ou 1 par l’ETTD.
L’ETCD empêche que des valeurs du champ de cause de réinitialisation autres que celles figurant
ci-dessus d’atteindre l’autre extrémité de la communication virtuelle ou du circuit virtuel permanent, soit
en acceptant le paquet de demande de réinitialisation et en mettant tous les bits du champ de cause de
réinitialisation à 0 dans le paquet correspondant d’indication de réinitialisation, soit en considérant la
demande de réinitialisation comme une erreur et en suivant la procédure décrite à l’annexe C.
Le codage du champ de cause de réinitialisation contenu dans un paquet d’indication de
réinitialisation est donné dans le tableau 21/X.25.
Tableau 21/X.25 — Codage du champ de cause de réinitialisation contenu dans
le paquet d’indication de réinitialisation
Bits
8
7
6
5
4
3
2
1
Origine: ETTD
Origine: ETTDa)
0
1
0
X
0
X
0
X
0
X
0
X
0
X
0
X
Dérangementsb)
Erreur de procédure distante
ETTD distant opérationnelb)
Réseau opérationnelb )
Destination incompatible
Réseau en dérangementb)
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
0
0
0
0
1
1
0
1
0
0
1
1
0
1
0
1
0
1
0
1
0
1
0
0
1
1
1
1
1
1
1
1
a)
Lorsque le bit 8 est mis à 1, les bits représentés par X sont ceux inclus par l’ETTD distant dans le champ de
cause de réinitialisation (communications virtuelles et circuits permanents) ou dans le champ de cause de
reprise (circuits virtuels permanents seulement) respectivement du paquet de demande de réinitialisation ou
de demande de reprise.
b)
Applicable aux circuits virtuels permanents seulement.
5.4.3.2
Code de diagnostic
L’octet 5 est affecté au code de diagnostic et contient des informations supplémentaires sur la
cause de la réinitialisation.
Le code de diagnostic n’est pas obligatoire dans un paquet de demande de réinitialisation.
Dans un paquet d’indication de réinitialisation, si le champ de cause de réinitialisation indique
“origine: ETTD”, le code de diagnostic a été transmis sans changement à partir de l’ETTD qui effectue
la réinitialisation. Si l’ETTD qui demande une réinitialisation n’a pas fourni un code de diagnostic dans
son paquet de demande de réinitialisation, les bits du code de diagnostic, dans le paquet d’indication de
réinitialisation résultant, sont tous mis à 0.
Lorsqu’un paquet d’indication de réinitialisation a pour origine un paquet de demande de
reprise, la valeur du code de diagnostic est la valeur précisée dans le paquet de demande de reprise; cette
valeur est “tout en zéro” si aucun code de diagnostic n’a été précisé dans la demande de reprise.
Lorsque le champ de cause de réinitialisation n’indique pas “origine: ETTD”, le code de diagnostic
contenu dans un paquet d’indication de réinitialisation est émis par le réseau. L’annexe E donne la liste des
codes pour les diagnostics émis par le réseau. Les bits du code de diagnostic sont tous mis à 0 lorsque aucune
information supplémentaire spécifique n’est fournie pour la réinitialisation.
Édition 2009
II-13/56
Remarque:
code de diagnostic. Des combinaisons de code non précisées, dans le champ de code de diagnostic,
ne provoquent pas la non-acceptation, par l’ETTD, du champ de cause.
5.4.4
Paquets de confirmation de réinitialisation par l’ETTD ou l’ETCD
La figure 16/X.25 donne le format des paquets de confirmation de réinitialisation par l’ETTD
ou l’ETCD.
Bits
Octets
8
1
7
6
5
4
3
2
1
(voir la remarque)
2
3
Remarque:
0
0
0
1
1
1
1
1
Codé 0001 (module 8) ou 0010 (modulo 128).
Figure 16/X.25 — Format des paquets de confirmation de réinitialisation par l’ETTD ou par l’ETCD
5.5Paquets de reprise
5.5.1
reprise.
Paquets de demande de reprise et d’indication de reprise
La figure 17/X.25 donne le format des paquets de demande de reprise et d’indication de
Bits
Octets
8
1
7
6
5
(voir la remarque)
2
0
0
0
3
0
4
3
2
1
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
4
Cause de reprise
5
Ce champ n’est pas obligatoire dans les paquets de demande de reprise.
a)
Figure 17/X.25 — Format des paquets de demande de reprise et d’indication de reprise
5.5.1.1
Champ de cause de reprise
L’octet 4 est affecté au champ de cause de reprise et contient la raison de la reprise.
Dans les paquets de demande de reprise, les bits du champ de cause de reprise doivent être mis
aux valeurs suivantes par l’ETTD:
Édition 2009
II-13/57
SUPPLéMENT ii-13
Bits:
8 7 6 5 4 3 2 1
Valeur: 0 0 0 0 0 0 0 0
Ou:
1 X X X X X X X
où chaque X peut être mis à 0 ou 1 par l’ETTD.
L’ETCD empêche des valeurs autres que celles figurant ci-dessus d’atteindre l’autre extrémité des
communications virtuelles et/ou des circuits virtuels permanents, soit en acceptant le paquet de demande
de reprise et en mettant tous les bits du champ de cause de réinitialisation ou de libération à 0 dans les
paquets correspondants de libération et/ou d’indication de réinitialisation, soit en considérant la demande
de reprise comme une erreur et en suivant la procédure décrite à l’annexe C.
Le codage du champ de cause de reprise contenu dans les paquets d’indication de reprise est
donné dans le tableau 22/X.25.
Tableau 22/X.25 — Codage du champ de cause de reprise contenu dans les paquets d’indication de reprise
Bits
8
7
6
5
4
3
2
1
Réseau opérationnel
Enregistrement/annulation confirméa)
0
0
0
0
0
0
0
1
0
0
0
1
0
0
0
1
0
0
0
1
0
0
1
1
0
1
1
1
1
1
1
1
Peut être reçu seulement si le service complémentaire d’enregistrement en ligne des services complémentaires
est utilisé.
a)
5.5.1.2
Code de diagnostic
L’octet 5 est affecté au code de diagnostic et contient des informations supplémentaires sur la
cause de la reprise.
Le code de diagnostic n’est pas obligatoire dans un paquet de demande de reprise. S’il est
précisé, ce code est transmis aux ETTD correspondants comme code de diagnostic d’un paquet d’indication
de réinitialisation dans le cas de circuits virtuels permanents, ou comme code de diagnostic d’un paquet
d’indication de libération dans le cas de communications virtuelles.
Le codage du champ de code de diagnostic, dans un paquet d’indication de reprise, est indiqué
dans l’annexe E. Les bits du code de diagnostic sont tous mis à 0, lorsque aucune information supplémentaire
spécifique n’est fournie pour la reprise.
Remarque:
code de diagnostic. Des combinaisons de codes non précisées dans le champ de code de diagnostic
ne provoquent pas la non-acceptation, par l’ETTD, du champ de cause.
5.5.2
Paquets de confirmation de reprise par l’ETTD ou l’ETCD
La figure 18/X.25 donne le format des paquets de confirmation de reprise par l’ETTD ou l’ETCD.
Bits
Octets
8
1
7
6
5
4
3
2
1
0
0
0
0
0
0
0
1
1
1
(voir la remarque)
2
0
0
0
1
1
1
3
0
1
1
Figure 18/X.25 — Format des paquets de confirmation de reprise par l’ETTD ou par l’ETCD
[...]
Édition 2009
II-13/58
ANNEXE A
(à la Recommandation X.25)
Gamme de voies logiques utilisées pour les communications virtuelles et
les circuits virtuels permanents
La voie logique 1 est utilisée dans le cas d’un ETTD à une seule voie logique.
Pour chaque interface ETTD/ETCD à plusieurs voies logiques, une gamme de voies logiques est
spécifiée en accord avec l’Administration, comme indiqué à la figure A–1/X.25.
NVL
0
1
Circuits virtuels permanents
VEB
VEH
Unidirectionnelles
entrantes
VBB
VBH
Bidirectionnelles
VSB
VSH
Unidirectionnelles
sortantes
4095
CCITT-34901
Communications virtuelles
NVLNuméro de voie logique
VEB
Voie entrante de numéro le plus bas
VEH
Voie entrante de numéro le plus haut
VBB
Voie bidirectionnelle de numéro le plus bas
VBH Voie bidirectionnelle de numéro le plus haut
VSB
Voie sortante de numéro le plus bas
VSH
Voie sortante de numéro le plus haut
Figure A–1/X.25
Voies logiques 1 à VEB – 1: Gamme des voies logiques qui peuvent être attribuées à des circuits virtuels permanents.
Voies logiques VEB à VEH: Gamme attribuée à des voies logiques unidirectionnelles entrantes pour des communications
virtuelles (voir le § 6.8).
Voies logiques VBB à VBH: Gamme attribuée à des voies logiques bidirectionnelles pour des communications
virtuelles.
Voies logiques VSB à VSH: Gamme attribuée à des voies logiques unidirectionnelles sortantes pour des communications
virtuelles (voir le § 6.7).
Les voies logiques VEH + 1 à VBB – 1, VBH + 1 à VSB –1 et VSH + 1 à 4095 sont des voies logiques non attribuées.
Remarque 1: Les voies logiques sont numérotées au moyen d’un ensemble de numéros consécutifs allant de 0 (le plus
bas) à 4095 (le plus haut) avec utilisation de 12 bits: les 4 bits du numéro de groupe de voies logiques
(voir le § 5.1.2) et les 8 bits du numéro de voie logique (voir le § 5.1.3). La numérotation est effectuée
en binaire, avec utilisation des bits 4 à 1 de l’octet 1, suivis des bits 8 à 1 de l’octet 2, le bit 1 de l’octet 2
étant le bit de poids faible.
Remarque 2: Les limites de toutes les voies logiques font l’objet d’un accord avec l’Administration pour une période
donnée.
Remarque 3: Afin d’éviter de fréquents réaménagements des voies logiques, il n’est pas obligatoire d’attribuer toutes
les voies logiques faisant partie de la gamme destinée aux circuits virtuels permanents.
Remarque 4: En l’absence de circuits virtuels permanents, la voie logique 1 est disponible comme VEB. En l’absence
de circuits virtuels permanents et de voies logiques unidirectionnelles entrantes, la voie logique 1 est
disponible comme VBB. En l’absence de circuits virtuels permanents, de voies logiques unidirectionnelles
entrantes et de voies logiques bidirectionnelles, la voie logique 1 est disponible comme VSB.
Remarque 5:Pour chercher une voie logique destinée à une nouvelle communication entrante, l’ETCD procède par
algorithme en utilisant la voie logique de numéro le plus bas à l’état prêt, dans les gammes de VEB à VEH
et de VBB à VBH.
Remarque 6: Afin de réduire au minimum le risque de collision d’appels, il est suggéré que l’algorithme de recherche
de l’ETTD commence par la voie logique de numéro le plus haut à l’état prêt. L’ETTD pourrait commencer
par la gamme des voies logiques bidirectionnelles ou la gamme des voies logiques unidirectionnelles
sortantes.
Édition 2009
II-13/59
SUPPLéMENT ii-13
ANNEXE B
Diagrammes d’état de l’interface ETTD/ETCD à la couche paquets
B.1Définition des symboles des diagrammes d’état
Transition
Numéro de l’état
Nom de l’état
{ }
ETCD
ETTD
Transition
(Type de
paquet)
Le responsable de la transition
Paquet transmis
CCITT-19172
Remarque 1: Chaque état est représenté par une ellipse dans laquelle le nom et le numéro de l’état sont
indiqués.
Remarque 2: Chaque transition entre états est représentée par une flèche. Le responsable de la transition (ETCD
ou ETTD) et le paquet qui a été transmis sont indiqués à côté de cette flèche.
B.2Ordre de définition des diagrammes d’état
Pour plus de clarté, on décrit ci-après la procédure normale à l’interface au moyen de plusieurs
diagrammes d’état partiels. Pour pouvoir décrire complètement la procédure normale, il faut attribuer une
priorité aux différentes figures et relier un diagramme de rang élevé à un diagramme de rang inférieur. Cela
a été fait de la manière suivante:
— Les figures sont disposées dans l’ordre de priorité, la figure B-1/X.25 (reprise) ayant la priorité la plus
élevée et les figures suivantes une priorité plus basse. Par priorité, on entend ceci: pour le transfert d’un
paquet d’un diagramme de rang le plus élevé, ce diagramme est applicable et le diagramme de rang
inférieur ne l’est pas;
—Pour indiquer la relation avec un état figurant dans un diagramme de rang inférieur, cet état est inscrit
dans une ellipse incorporée au diagramme de rang plus élevé.
Édition 2009
II-13/60
r1
Niveau des paquets prêts
ETC
D
Dem
ise
epr
de r
ion
e
D
icat
pris
ETT
Ind
e re ise
nd
r
D
rep
atio
ETC
e de
firm
e 3)
an d
Con
arqu
dem
rem
ou
r la
(voi
ande
de re
prise
Conf
i r ma
ETT
tion
ou in
D
de re
dicat
p
r
ion d
ise
e rep
rise
Prêt
p1 ou d1
r2
r3
Demande de reprise
par l’ETTD
Indication de reprise
par l’ETCD
ETTD
ETCD
CCITT-34910
Demande de reprise
Indication de reprise
Figure B-1/X.25 — Diagramme d’état pour le transfert des paquets de reprise
Remarque 1: état p1 pour les communications virtuelles ou état d1 pour les circuits virtuels permanents.
Remarque 2: Cette transition s’effectue lorsque le temporisateur T10 arrive en fin de course pour la première
fois.
Remarque 3: Cette transition s’effectue aussi lorsque le temporisateur T10 arrive en fin de course pour la deuxième
fois (sans transmission de paquets, à l’exception, éventuellement, d’un paquet à diagnostic).
Édition 2009
II-13/61
SUPPLéMENT ii-13
p1
Prêt
ETTD
ETCD
Appel
p2
ETTD
en attente
Appel entrant
Appel
entrant
ETCD ETCD
Communication
établie
p3
ETCD
en attente
Appel
ETTD
p5
Collision
d’appels
ETCD
ETTD
Communication
acceptée
d1
Contrôle
de flux
prêt
p4
Transfert de
données
a) Phase d’établissement de la communication
ETTD
Tout état
sauf p6 ou p7
ETCD
Demande de libération
ETCD
p6
Communication
Demande de
établie (voir la
libération par
remarque 1) ou
l’ETTD
appel entrant
ETCD
Indication de libération
ETTD
ETCD
Demande de
libération
Confirmation de
libération par l’ETCD ou
indication de libération
ETTD
p7
Indication de
libération par
l’ETTD
Indication
de libération
(voir la
remarque 3)
p1
Prêt
ETTD
Communication
acceptée (voir la
remarque 2) ou
appel (voir la
remarque 4)
Confirmation de
libération par l’ETTD ou
demande de libération
CCITT-18551
b) Phase de libération de la communication
Figure B-2/X.25 — Diagramme d’état pour la transmission des paquets d’établissement et
de libération de la communication à l’état niveau paquets prêt (r1)
Remarque 1: Cette transition n’est possible que si l’état précédent était ETTD en attente (p2).
Remarque 2: Cette transition n’est possible que si l’état précédent était ETCD en attente (p3).
Remarque 3: Cette transition se produit lorsque le temporisateur T13 arrive en fin de course pour la 1ère fois.
Remarque 4: Cette transition n’est possible que si l’état précédent était prêt (p1) ou ETCD en attente (p3).
Remarque 5: Cette transition n’est possible que si l’état précédent était prêt (p1) ou ETTD en attente (p2).
Remarque 6: Cette transition s’effectue aussi lorsque le temporisateur T13 arrive en fin de course pour la deuxième
fois (sans transmission de paquets, à l’exception, éventuellement, d’un paquet de diagnostic).
Édition 2009
II-13/62
ETTD
Demande de
réinitialisation
ETTD
Demande de
réinitialisation
d1
Contrôle de flux
prêt
Indication de
réinitialisation ou
confirmation de
réinitialisation par l’ETCD
ETCD
d2
Demande de
réinitialisation
par l’ETTD
ETCD
Demande de
réinitialisation ou
confirmation de
réinitialisation par l’ETTD
ETTD
Indication de
réinitialisation
ETCD
d3
Indication de
réinitialisation
par l’ETCD
Indication de
réinitialisation
(voir la remarque)
CCITT-18561
Figure B-3/X.25 — Diagramme d’état pour le transfert des paquets de réinitialisation à
l’état transfert de données (p4)
Remarque:
[...]
Édition 2009
Cette transition se produit lorsque le temporisateur T12 arrive en Fm de course pour la première
fois.
II-13/63
SUPPLéMENT ii-13
ANNEXE D
Temporisations de l’ETCD et temps limites de l’ETTD à la couche paquets
D.1
Temporisations de l’ETCD
Dans certains cas, la présente Recommandation prescrit que l’ETTD doit répondre dans un
délai maximal donné à l’émission d’un paquet par l’ETCD.
Le tableau D-1/X.25 illustre ces cas et indique les actions que l’ETCD entreprend à l’expiration
de ce délai.
Les valeurs de temporisation appliquées par l’ETCD ne sont jamais inférieures à celles qui sont
indiquées au tableau D-1/X.25.
D.2
Temps limites de l’ETTD
Dans certains cas, la présente Recommandation prescrit que l’ETCD doit répondre dans un
délai maximal donné à un paquet provenant de l’ETTD. Le tableau D-2/X.25 indique ces délais maximaux.
Les temps de réponse effectifs de l’ETCD doivent être nettement inférieurs aux temps limites indiqués.
Le dépassement d’un temps limite doit être exceptionnel, et se produire exclusivement en cas de
dérangement.
Pour faciliter la relève de ces dérangements, on peut équiper l’ETTD de temporisateurs. Les
temps limites indiqués dans le tableau D-2/X.25 sont les limites les plus basses pouvant être autorisées par
un ETTD pour un fonctionnement satisfaisant. On peut opérer avec un temps limite supérieur aux valeurs
indiquées. Le tableau D-2/X.25 contient des suggestions en ce qui concerne les actions qui peuvent être
entreprises par l’ETTD à l’expiration de ces temps limites.
Remarque:
Un ETTD peut utiliser une temporisation plus courte que la valeur indiquée pour T21 dans le
tableau D-2/X.25. Cette solution peut être indiquée si l’ETTD connaît le temps de réponse normal
de l’ETTD appelé à un appel entrant. Dans ce cas, la temporisation doit tenir compte du temps de
réponse maximal normal de l’ETTD appelé ainsi que du temps maximal (estimé) d’établissement de
la communication.
Édition 2009
Valeur
de la
temporisation
60 s
180 s
60 s
60 s
Numéro
de la
temporisation
T10
Édition 2009
T11
T12
T13
L’ETCD
émet une
indication
de libération
L’ETCD émet
une indication de réinitialisation
L’ETCD émet
un appel
entrant
L’ETCD
émet une
indication
de reprise
Début de la
temporisation,
lorsque
p7
d3
p3
r3
état de
la voie
logique
L’ETCD quitte
l’état p7 (par
exemple, la
confirmation
de libération ou
la demande de
libération est
reçue)
L’ETCD quitte
l’état d3 (par
exemple, la
confirmation de
réinitialisation
ou la demande
de réinitialisation est reçue)
L’ETCD quitte
l’état p3 (par
exemple, un paquet communication acceptée,
demande de
libération ou
appel est reçu)
L’ETCD quitte
l’état r3 (c’està-dire quand la
confirmation de
reprise ou la
demande de
reprise est reçue)
Fin normale
de la
temporisation,
lorsque
L’ETCD reste à l’état
p7, signale une indication de libération
(erreur de procédure locale # 50) à
nouveau et relance la temporisation
T13
L’ETCD peut passer
à l’état d3 et signaler une indication
de réinitialisation
(erreur de procédure
de l’extrémité
distante # 51)
L’ETCD passe à
l’état p7 et signale
une indication de
libération (erreur
de procédure de
l’extrémité
distante # 49)
L’ETCD passe à l’état
p7 et signale une
indication de
libération (erreur
de procédure locale
# 49)
d3, signale une
indication de réinitialisation (erreur
de procédure locale
# 51) à nouveau et
relance la temporisation T12
Pour les circuits
virtuels permanents, l’ETCD peut
passer à l’état d3 et
signaler une indication de réinitialisation (erreur de
procédure de l’extrémité distante # 52)
Extrémité distante
r3, signale une
indication de reprise
locale # 52) à nouveau et relance la
temporisation T10
Extrémité locale
Actions à entreprendre la première fois que
la temporisation arrive en fin de course
Tableau D-1/X.25 — Temporisations de l’ETCD
p1 et peut émettre
un paquet de
diagnostic (# 50)
Pour les communications virtuelles,
l’ETCD passe à l’état
p7 et signale une
indication de libération (erreur de
procédure locale
# 51). Pour les
circuits virtuels
permanents, il passe
à l’état d1 et peut
émettre un paquet
de diagnostic (# 51)
r1 et peut émettre
un paquet diagnostic
(# 52)
Extrémité locale
Pour les communications virtuelles, l’ETCD
passe à l’état p7 et signale une indication
de libération (erreur de
procédure de l’extrémité distante # 51). Pour
les circuits virtuels permanents, il peut passer à l’état d3 et signale
une indication de
réinitialisation (erreur
de procédure de l’extrémité distante # 51)
Pour les circuits virtuels
permanents, l’ETCD
peut passer à l’état d3
et signaler une indication de réinitialisation
de l’extrémité distante
# 52)
Extrémité distante
Actions à entreprendre la deuxième fois que
la temporisation arrive en fin de course
II-13/64
180 s
200 s
180 s
180 s
300 s
T20
T21
T22
T23
T28
(voir la
remarque 3)
L’ETTD émet
une demande
d’enregistrement
L’ETTD émet une
demande de libération
L’ETTD émet une
demande de
réinitialisation
L’ETTD émet un appel
L’ETTD émet une
demande de reprise
Déclenchement
quand
Quelconque
p6
d2
p2
r2
état de la voie logique
L’ETTD reçoit le paquet
de confirmation
d’enregistrement ou de
diagnostic
L’ETTD quitte l’état p6 (par
exemple, la confirmation de
libération ou l’indication de
libération est reçue)
L’ETTD quitte l’état d2
(par exemple, le paquet de
confirmation de réinitialisation ou d’indication de
réinitialisation est reçu)
L’ETTD quitte l’état p2
(par exemple, le paquet de
communication établie,
d’indication de libération ou
d’appel entrant est reçu)
L’ETTD quitte l’état r2 (c’est-àdire que le paquet confirmation de reprise ou indication
de reprise est reçu)
Fin de la course normale
quand
— Peut retransmettre la
demande d’enregistrement
mais doit, à un moment
donné, reconnaître que le
service complémentaire
d’enregistrement en ligne de
service complémentaire n’est
pas offert
— Retransmettre la demande de
libération (voir la remarque 2)
— Pour les circuits virtuels
permanents, retransmettre la
demande de réinitialisation
— Pour les communications
virtuelles, retransmettre la
demande de réinitialisation
ou transmettre une demande
de libération
— Transmettre une demande de
libération
— Retransmettre la demande de
reprise (voir la remarque 1)
Action à entreprendre de
préférence à l’expiration du
temps limite
[...]
Remarque 3: Les temporisateurs T24 à T27 de l’ETTD ont été affectés par l’ISO dans la spécification de la couche paquets pour les ETTD X.25. Pour éviter toute
ambiguïté ou confusion, le temps limite a reçu le numéro T28.
Remarque 2: Après de nouvelles tentatives infructueuses, la voie logique doit être considérée en dérangement. La procédure de reprise ne doit être mise en œuvre
pour le rétablissement que si la réinitialisation de toutes les voies logiques est acceptable.
Remarque 1: Après de nouvelles tentatives infructueuses, les décisions de rétablissement doivent être prises à des couches plus élevées.
Valeur du
temps limite
Numéro du
temps limite
Tableau D-2/X.25 — Temps limites de l’ETTD
SUPPLéMENT ii-13
II-13/65
Édition 2009
II-13/66
ANNEXE G
Services complémentaires d’ETTD spécifiés par le CCITT
utilisés pour pouvoir admettre le service de réseau OSI
G.1INTRODUCTION
Les services complémentaires décrits dans la présente annexe sont destinés à permettre la
signalisation de bout en bout qu’exige le service de réseau OSI (interconnexion de systèmes ouverts). Ils
suivent le marqueur de services complémentaires d’ETTD spécifiés par le CCITT défini au § 7.1. Ces services
complémentaires sont transmis non modifiés entre les deux ETTD en mode-paquet concernés.
Les procédures d’utilisation de ces services complémentaires par l’ETTD sont spécifiées dans la
norme ISO 8208. La fourniture ultérieure de services complémentaires X.25 traités par les réseaux publics
pour données nécessite un complément d’étude. Le codage des services complémentaires mentionnés
dans la présente annexe est défini ici pour faciliter la mise au point d’un schéma de codage des services
complémentaires compatible avec cette évolution future.
G.2
Codage des champs de code de service complémentaire
Le tableau G-1/X.25 indique le codage du champ de code de service complémentaire pour
chaque service complémentaire d’ETTD spécifié par le CCITT et les types de paquets dans lesquels ils peuvent
être présents. Ces services complémentaires sont transmis après le marqueur de services complémentaires
d’ETTD spécifié par le CCITT.
Tableau G-1/X.25 — Codage du champ de service complémentaire
Types de paquets dans lesquels il peut être utilisé
Code du service complémentaire
Service
Appel Appel Commu- Commu- Demande Indication
Bits
complémentaire
entrant nication nication
de
de
acceptée établie
libération libération 8 7 6 5 4 3 2 1
Extension de l’adresse
X
X
X
du demandeur (voir remarque)
1 1 0 0 1 0 1 1
Extension de l’adresse
du demandé
1 1 0 0 1 0 0 1
X
Négociation de la qualité
de service:
Classe de débit minimale
X
X
X
X
X
X
X
X
(voir remarque)
Temps de transit bout en bout X
0 0 0 0 1 0 1 0
X
X
X
X
(voir remarque)
Priorité
X
X
X
X
X
(voir remarque)
1 1 0 1 0 0 1 0
Protection
X
X
X
X
X
(voir remarque)
1 1 0 1 0 0 1 1
Négociation des données
X
X
X
X
X
exprès (voir remarque)
0 0 0 0 1 0 1 1
1 1 0 0 1 0 1 0
Remarque:
Seulement en cas d’emploi du service complémentaire de choix de détournement des appels (voir le
§ 6.25.2.2).
G.3
Codage du champ de paramètre de service complémentaire
G.3.1
Service complémentaire d’extension de l’adresse du demandeur
L’octet qui suit le champ de code du service complémentaire indique la longueur, en octets, du
champs de paramètre de service complémentaire; sa valeur est n + 1, où n est le nombre d’octets nécessaires
pour contenir l’extension de l’adresse du demandeur. Le champ de paramètre de service complémentaire
vient après la longueur et contient l’extension de l’adresse du demandeur.
Édition 2009
II-13/67
SUPPLéMENT ii-13
Le premier octet du champ de paramètre de service complémentaire indique, dans les bits 8 et
7, l’utilisation de l’extension de l’adresse du demandeur, comme indiqué au tableau G-2/X.25.
Tableau G-2/X.25 — Codage des bits 8 et 7 dans le premier octet du champ de paramètre
de service complémentaire d’extension de l’adresse du demandeur
Bits
8 7
0 0
0 1
1 0
1 1
Utilisation de l’extension de l’adresse du demandeur
Transmettre une adresse de demandeur attribuée conformément à la Recommandation X.213/
ISO 8348 AD2
Réservé
Autre (transmettre une adresse de demandeur non attribuée conformément à la
Recommandation X.213/ISO 8348 AD2)
Réservé
Les bits 6, 5, 4, 3, 2 et 1 de cet octet indiquent le nombre de demi-octets (jusqu’à concurrence
de 40) de l’extension de l’adresse du demandeur. Cet indicateur de longueur d’adresse est codé en binaire,
le bit 1 étant le bit de poids faible.
Les octets suivants contiennent l’extension de l’adresse du demandeur.
Si les bits 8 et 7 du premier octet du champ de paramètre de service complémentaire sont codés
“00”, les octets suivants sont codés au moyen du codage binaire préférentiel préconisé dans la Recommandation
X.213. En partant du chiffre de poids fort du sous-système de domaine initial (IDP), l’adresse est codée dans
l’octet 2 et les octets suivants du champ de paramètre de service complémentaire. Chaque chiffre, avec
application de chiffres de remplissage si nécessaire, est codé en binaire, dans un demi-octet, le bit 5 ou 1 étant
le bit de poids faible du chiffre. Dans chaque octet, le chiffre de poids fort est codé dans les bits 8, 7, 6 et 5.
Le sous-système spécifique de domaine (DSP) de l’adresse du point d’accès pour le service de réseau (NSAP)
OSI appelant suit le sous-système de domaine initial et est codé en décimal ou en binaire, conformément au
codage binaire préférentiel. Par exemple, si la syntaxe du DSP est décimale, chaque chiffre est codé en décimal
codé binaire (en appliquant au DSP les mêmes règles qu’à l’IDP ci-dessus). Si la syntaxe du DSP est binaire,
chaque octet de l’extension de l’adresse du demandeur contient un octet du DSP.
“10”, chaque chiffre de l’extension de l’adresse du demandeur est codé en binaire, dans un demi-octet, le
bit 5 ou 1 étant le bit de poids faible du chiffre. En partant du chiffre de poids fort, l’adresse est codée dans
l’octet 2 et les octets suivants du champ de paramètre de service complémentaire, avec deux chiffres par
octet. Dans chaque octet, le chiffre de poids fort est codé dans les bits 8, 7, 6 et 5. Si nécessaire, pour que le
champ de paramètre de service complémentaire comporte un nombre entier d’octets, on insère des zéros
dans les bits 4, 3, 2 et 1 du dernier octet du champ.
G.3.2
Service complémentaire d’extension de l’adresse du demandé
L’octet qui suit le champ de code du service complémentaire indique la longueur, en octets, du
champ de paramètre de service complémentaire; sa valeur est n + 1, où n est le nombre d’octets nécessaires
pour contenir l’extension de l’adresse du demandé. Le champ de paramètre de service complémentaire
vient après la longueur et contient l’extension de l’adresse du demandé.
Le premier octet du champ de paramètre de service complémentaire indique, dans les bits 8 et
7, l’utilisation de l’extension de l’adresse du demandé, comme indiqué au tableau G-3/X.25.
Tableau G-3/X.25 — Codage des bits 8 et 7 dans le premier octet du champ de
paramètre de service complémentaire d’extension de l’adresse du demandé
Bits
8 7
0 0
0 1
1 0
1 1
Utilisation de l’extension de l’adresse du demandé
Transmettre une adresse de demandé attribuée conformément à la Recommandation X.213/
ISO 8348 AD2
Réservé
Autre (transmettre une adresse de demandé non attribuée conformément à la
Recommandation X.213/ISO 8348 AD2)
Réservé
Édition 2009
II-13/68
Les bits 6, 5, 4, 3, 2 et 1 de cet octet indiquent le nombre de demi-octets (jusqu’à concurrence
de 40) de l’extension de l’adresse du demandé. Cet indicateur de longueur d’adresse est codé en binaire, le
bit 1 étant le bit de poids faible.
Les octets suivants contiennent l’extension de l’adresse du demandé.
“00”, les octets suivants sont codés au moyen du codage binaire préférentiel défini dans la Recommandation
X.213. En partant du chiffre de poids fort du sous-système de domaine initial (IDP), l’adresse est codée dans
l’octet 2 et les octets suivants du champ de paramètre de service complémentaire. Chaque chiffre, avec
application de chiffres de remplissage si nécessaire, est codé en binaire, dans un demi-octet, le bit 5 ou 1
étant le bit de poids faible du chiffre. Dans chaque octet, le chiffre de poids fort est codé dans les bits 8, 7,
6 et 5. Le sous-système spécifique de domaine (DSP) de l’adresse du point d’accès pour le service de réseau
(NSAP) OSI appelé suit le sous-système de domaine initial et est codé en décimal ou en binaire, conformément
au codage binaire préférentiel. Par exemple, si la syntaxe du DSP est décimale, chaque chiffre est codé en
décimal codé binaire (en appliquant au DSP les mêmes règles qu’à l’IDP ci-dessus). Si la syntaxe du DSP est
binaire, chaque octet de l’extension de l’adresse du demandé contient un octet du DSP.
“10”, chaque chiffre de l’extension de l’adresse du demandé est codé en binaire, dans un demi-octet, le bit
5 ou 1 étant le bit de poids faible du chiffre. En partant du chiffre de poids fort, l’adresse est codée dans
l’octet 2 et les octets suivants du champ de paramètre de service complémentaire, avec deux chiffres par
octet. Dans chaque octet, le chiffre de poids fort est codé dans les bits 8, 7, 6 et 5. Si nécessaire, pour que le
champ de paramètre de service complémentaire comporte un nombre entier d’octets, on insère des zéros
dans les bits 4, 3, 2 et 1 du dernier octet du champ.
G.3.3
Services complémentaires de négociation de la qualité de service
G.3.3.1
Service complémentaire de classe de débit minimale
La classe de débit minimale pour le sens de transmission des données à partir de l’ETTD appelant
est indiquée dans les bits 4, 3, 2 et 1. La classe de débit minimale pour le sens de transmission des données
à partir de l’ETTD appelé est indiquée dans les bits 8, 7, 6 et 5.
Les quatre bits qui indiquent chaque classe de débit sont codés en binaire et correspondent aux
classes de débit indiquées au tableau 30/X.25.
G.3.3.2
Service complémentaire de délai de transit de bout en bout
L’octet qui suit le champ de code de service complémentaire indique la longueur, en octets, du
champ de paramètre de service complémentaire et sa valeur est 2, 4 ou 6.
Le premier et le deuxième octet du champ de paramètre de service complémentaire contiennent
le délai de transit cumulé. Les troisième et quatrième octets sont facultatifs et, quand ils sont présents, ils
contiennent le délai de transit de bout en bout demandé. Si les troisième et quatrième octets sont présents,
les cinquième et sixième octets sont aussi facultatifs. Les cinquième et sixième octets, s’ils sont présents,
contiennent le délai de transit de bout en bout maximal admissible. Les octets facultatifs ne sont pas
présents dans les paquets de communication acceptée et de communication établie.
Le délai de transit est exprimé en millisecondes et codé en binaire, le bit 8 de l’octet 1 étant le
bit de poids fort et le bit 1 de l’octet 2, le bit de poids faible. La valeur “tout en 1” pour le délai de transit
cumulé indique que ce délai est inconnu ou qu’il est supérieur à 65 534 millisecondes.
G.3.3.3
Service complémentaire de priorité
champ de paramètre de service complémentaire. Il peut prendre la valeur 1, 2, 3, 4, 5 ou 6.
Les premier, deuxième et troisième octets du champ de paramètre de service complémentaire
contiennent les valeurs “cible” (paquet d’appel), “disponible” (paquet d’appel entrant) ou “choisie”
(paquets de communication acceptée et de communication établie) correspondant respectivement à la
priorité des données concernant la connexion, la priorité d’obtention d’une connexion et la priorité de
conservation d’une connexion. Les quatrième, cinquième et sixième octets du champ de paramètre de service
complémentaire des paquets d’appel et d’appel entrant contiennent respectivement les valeurs minimales
acceptables correspondant à la priorité des données concernant la connexion, la priorité d’obtention
d’une connexion et la priorité de conservation d’une connexion. Lorsque ce service complémentaire est
présent dans les paquets d’appel et d’appel entrant, les octets 2 à 6 du champ de paramètre de service
complémentaire sont facultatifs. Par exemple, si les seules valeurs à être spécifiées sont les valeurs “cible”
Édition 2009
II-13/69
SUPPLéMENT ii-13
et “valeurs minimales acceptables” pour la priorité d’obtention d’une connexion, le champ de paramètre
de service complémentaire contiendra au moins 5 octets, avec les octets 1, 3 et 4 contenant la valeur
“non spécifiée”, et les octets 2 et 5 contenant les valeurs spécifiées. Lorsque le service complémentaire est
présent dans les paquets de communication acceptée et de communication établie, les octets 2 et 3 sont
facultatifs.
La gamme potentielle des valeurs spécifiées pour chaque sous-paramètre va de 0 (priorité la
moins élevée) à 254 (priorité la plus élevée). La valeur 255 (1111 1111) signifie “non spécifié”.
G.3.3.4
Service complémentaire de protection
champ de paramètre de service complémentaire.
Les deux bits de poids le plus fort du premier octet (c’est-à-dire les bits 8 et 7) du champ de
paramètre de service complémentaire spécifient le code du format de protection, comme indiqué au tableau
G-4/X.25.
Tableau G-4/X.25 — Codage des deux bits de poids le plus fort dans le premier octet
du code de format de protection
Bits
8 7
0
0
1
1
0
1
0
1
Code de format de protection
Réservé
Spécifique de l’adresse d’origine
Spécifique de l’adresse de destination
Universel
Les six bits restants de l’octet sont réservés et doivent être mis à zéro.
Le deuxième octet du champ de paramètre de service complémentaire spécifie la longueur
“n”, en octets, du niveau de protection “cible” (paquet d’appel), “disponible” (paquet d’appel entrant) ou
“choisi” (paquets de communication acceptée et de communication établie). La valeur réelle est placée dans
les octets “n” suivants. à titre facultatif, l’octet “n + 3” du champ de paramètre de service complémentaire
spécifie la longueur “m”, en octets, du niveau de protection minimal acceptable dans les paquets d’appel
et d’appel entrant. La valeur réelle est placée dans les octets “m” suivants. Les octets facultatifs ne sont pas
présents dans les paquets de communication acceptée et de communication établie.
Remarque:
Les valeurs de “n” et de “m” sont d’abord délimitées par la longueur totale du service complémentaire
(premier octet), elles se limitent ensuite réciproquement.
G.3.4
Service complémentaire de négociation de données exprès
Le codage du champ de paramètre de service complémentaire est le suivant:
bit 1 = 0 pour “pas d’utilisation des données exprès”
bit 1 = 1 pour “utilisation des données exprès”
Remarque:
Les bits 8, 7, 6, 5, 4, 3 et 2 pourront par la suite être utilisés pour d’autres services complémentaires;
pour le moment, ils sont mis à zéro.
[...]
Édition 2009
II-13/70
APPENDICE I
Exemples de schémas de bits transmis à la couche liaison de
données par l’ETCD et par l’ETTD
Le présent appendice, fourni à titre documentaire, indique les schémas de bits qui existent dans
la couche physique pour certaines trames non numérotées. Il vise à faire mieux comprendre le mécanisme
de transparence et la mise en œuvre de la séquence de contrôle de trame.
I.1
Les exemples ci-après concernent des schémas de bits transmis par un ETCD pour certaines
trames non numérotées:
Exemple 1: Trame de commande SABM avec adresse = A, P = 1
Premier bit transmisDernier bit transmis
0111 1110
Fanion 1100 0000
Adresse = A
1111 1(03))100 SABM(P = 1)
1101 1010 0011 0111 Séquence de contrôle de trame 0111 1110
Fanion
Exemple 2: Trame de réponse UA avec adresse = B, F = 1
0111 1110 Fanion 1000 0000
Adresse = B
1100 1110 UA(F = 1)
1100 0001 1110 1010
Séquence de contrôle de trame 0111 1110
Fanion
I.2
Exemples de schémas de bits qui doivent être transmis par un ETTD pour certaines trames non
numérotées:
Exemple 1: Trame de commande SABM avec adresse = B, P = 1
0111 1110
Fanion 1000 0000
Adresse = B
1111 1(03))100
SABM(P = 1) 1101 0111 11(0(3))11 1011 Séquence de contrôle de trame
0111 1110
Fanion
Exemple 2: Trame de réponse UA avec adresse = A, F = 1
0111 1110 Fanion ________
3)
1100 0000
Adresse = A Zéro inséré pour la transparence.
Édition 2009
1100 1110 UA(F = 1)
1100 1100 0010 0110
Séquence de contrôle de trame
0111 1110
Fanion
II-13/71
SUPPLéMENT ii-13
APPENDICE II
Explication de la manière dont sont déterminées les valeurs de N1 au § 2.4.8.5
INTRODUCTION
Le présent appendice décrit la manière dont sont déterminées les valeurs indiquées pour le
paramètre N1 de couche liaison de données, au § 2.4.8.5.
N1 de l’ETTD
Il est dit au § 2.4.8.5 que, pour permettre un fonctionnement universel, l’ETTD devrait supporter
une valeur de N1 qui ne soit pas inférieure à 1080 bits (135 octets).
Pour permettre un fonctionnement universel, un ETTD doit pouvoir accepter au minimum le
paquet le plus long qui puisse traverser l’interface ETTD/ETCD lorsque aucune option ne s’applique. Cela
implique que l’ETTD peut décider, par exemple, de ne mettre en œuvre aucun service complémentaire
facultatif en exploitation universelle, mais qu’il est obligé de supporter, par exemple, un paquet de données
utilisant la longueur de paquets par défaut standard. Par conséquent, pour déterminer la valeur maximale
de N1 que doit mettre en œuvre un ETTD, le facteur déterminant est la longueur de paquets par défaut
standard d’un paquet de données plutôt que la longueur d’un paquet d’établissement de la communication.
Ainsi, pour permettre un fonctionnement universel, l’ETTD devrait supporter une valeur de N1 qui ne soit
pas inférieure à 135 octets, obtenue comme indiqué dans le tableau suivant.
Tableau II-1/X.25 — Détermination de la valeur minimale de N1 pour un ETTD
Remarque:
Nom du champ Longueur du champ
(octets)
En-tête de paquet (Couche 3) Données d’usager (Couche 3) Adresse (Couche 2)
Commande (Couche 2)
FCS (Couche 2)
3
128
1
1
2
TOTAL
135
En cas d’application de services complémentaires facultatifs, l’ETTD devra pouvoir supporter des
valeurs de N1 plus élevées.
N1 de l’ETCD
Il est également dit au § 2.4.8.5 que tous les réseaux doivent offrir à un ETTD qui le demande
une valeur de N1 de l’ETCD supérieure ou égale à 2072 bits (259 octets) compte non tenu des champs
d’adresse, de commande et FCS.
Lorsque la longueur maximale du champ de données d’un paquet de données est inférieure ou
égale à la valeur par défaut standard de 128 octets, le facteur déterminant (pour la valeur de N1 de l’ETCD)
est le paquet de demande de libération et non le paquet de données. Par conséquent, le réseau doit offrir à
l’ETTD une valeur de N1 de l’ETCD qui ne soit pas inférieure à 263 ou 264 octets, obtenue comme indiqué
dans le tableau ci-après.
Édition 2009
II-13/72
Tableau II-2/X.25 — Détermination de la valeur minimale de N1 pour un ETCD
Nom du champ
En-tête (Couche 3)
Cause de libération (Couche 3)
Code de diagnostic (Couche 3)
Longueur d’adresse de l’ETTD (Couche 3)
Adresse(s) de l’ETTD (Couche 3)
Longueur de service complémentaire (Couche 3)
Services complémentaires (Couche 3)
Données de libération d’usager (Couche 3)
Couche 3 — TOTAL
Adresse (Couche 2)
Commande (Couche 2)
Procédure multiliaison
FCS (Couche 2)
TOTAL
Longueur du champ (octets)
3
1
1
1
15
1
109
128
259
1
1 ou 2*
2**
2
263 ou 264*
ou 265**
ou 266*,**
* S’il y a mise en œuvre d’exploitation modulo 128 de niveau 2.
** Il y a mise en œuvre de procédures multiliaison (PML).
Lorsque la longueur maximale du champ de données d’usager d’un paquet de données supporté
est supérieure à la valeur par défaut standard de 128 octets, le facteur déterminant (pour la valeur de N1 de
l’ETCD) est le paquet de données plutôt que le paquet de demande de libération. Par conséquent, le réseau
doit offrir à l’ETTD une valeur de N1 de l’ETCD supérieure ou égale à:
[la longueur maximale du paquet de données +
la longueur du champ d’adresse (couche 2) +
la longueur du champ de commande (couche 2) +
la longueur du champ FCS (couche 2)].
Calcul de N1 pour un ETCD
selon que:
a)
b)
c)
d)
Le tableau ci-après indique la valeur de N1 pour l’ETCD dans les différents cas envisageables,
Le modulo 128 de couche 2 est utilisé,
Les procédures multiliaison sont utilisées,
Le modulo 128 de couche 3 est utilisé, et/ou
La longueur maximale du champ de données (p) d’un paquet de données est supérieure ou égale à
256 octets.
Édition 2009
II-13/73
SUPPLéMENT ii-13
Tableau II-3/X.25 — Les différents cas et les valeurs minimales correspondantes de N1 pour l’ETCD
Modulo 128
PML
de couche 2
Modulo 128
de couche 3
p ≥ 256
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
N1 de l’ETCD (octets)
259 + 4*
259 + 4* + 2*****
p + 3** + 4*
p + 3** + 4* + 2*****
259 + 4*
259 + 4* + 2*****
p + 3** + 1*** + 4*
p + 3** + 1*** + 4* + 2*****
259 + 4* + 1****
259 + 4* + 1**** + 2*****
p + 3** + 1**** + 4*
p + 3** + 1**** + 4* + 2*****
259 + 4* + 1****
259 + 4* + 1**** + 2*****
p + 3** + 1*** + 4* + 1****
p + 3** + 1*** + 4* + 1**** + 2*****
*Nombre d’octets pour les champs de trame modulo 128 de couche 2.
**Nombre d’octets pour les champs d’en-tête de paquet de couche 3.
***
Octet supplémentaire pour les opérations en modulo 128 de couche 3.
**** Octet supplémentaire pour les opérations en modulo 128 de couche 2.
***** Octets supplémentaires pour support PML.
[...]
Édition 2009
SUPPLéMENT II-14
Utilisation des circuits virtuels commutés (CVC) X.25
Les communications virtuelles X.25, également appelées circuits virtuels commutés (CVC),
sont employées sur le SMT. Les CVC X.25 peuvent être employés dans un environnement purement X.25
ou en association avec d’autres protocoles de communication tels que TCP/IP. Dans tous les cas, l’utilisation
de CVC a les avantages suivants par rapport aux circuits virtuels permanents (CVP):
a) Elle réduit la perte de données sur les circuits avec des commutateurs de paquets;
b) Elle permet d’exploiter des circuits de sauvegarde avec un minimum de perturbations;
c) Elle permet un échange souple de données par négociation de la taille des paquets, de la taille des
fenêtres, de la classe de débit, etc.
On trouvera ci-après la description d’usages caractéristiques et des caractéristiques de
configuration des CVC X.25 sur le SMT. Des recommandations de base pour la mise en place de CVC X.25
sont également présentées.
1.
X.25 pur
1.1
Type de trafic
Trafic SCM traditionnel, c’est-à-dire messages courants continus.
1.2
Caractéristiques de configuration
Une connexion CVC purement X.25 peut être considérée:
a) Comme une connexion X.25 constante entre centres, exploitée de manière semblable à un CVP (circuit
virtuel permanent);
b) Comme une connexion X.25 transitoire entre centres.
1.3
Exploitation recommandée
1.3.1
écoulement du trafic
Comme l’exploitation de CVC individuels pour le trafic entrant et sortant est plus facile à
contrôler et d’une mise en œuvre moins ambiguë sur le SCM, il est recommandé que l’écoulement du trafic
sur un CVC X.25 se fasse dans un seul sens. Dans ce cas, un centre émetteur lance l’établissement de la
communication X.25 pour établir un CVC pour son trafic sortant.
1.3.2
Libération d’une communication X.25
Les CVC peuvent:
a) être laissés ouverts si possible;
b) être libérés par l’un ou l’autre centre au moyen d’un minuteur d’inactivité.
La première solution est la plus simple pour l’échange de messages courants sur une ligne
spécialisée, car elle est semblable à une connexion sur un CVP. Cependant, la deuxième solution peut être
souhaitable dans des conditions telles que l’utilisation de réseaux publics de transmission de données ou
l’existence de restrictions concernant les commutateurs de paquets. Il est recommandé de convenir de la
solution à adopter sur une base bilatérale.
2.
IP sur X.25
2.1
Type de trafic
Données non associées traditionnellement à un SCM (par exemple, images transmises par
satellite), échangées par intermittence en temps réel, généralement par l’intermédiaire du FTP. Ces données
sont généralement transmises par rafales.
Édition 2009
II-14/2
2.2
2.2.1
Un CVC X.25 est généralement intermittent entre centres adjacents.
2.2.2
Les détails précis des connexions (par exemple le nombre de CVC autorisés, un minuteur
de temps d’inactivité pour la libération des communications) peuvent dépendre de la marque et de la
configuration du routeur.
2.3
Les routeurs assurent des fonctions souples de gestion de l’établissement et de la libération
des communications en cas de trafic unidirectionel ou bidirectionnel sur un CVC. Comme les données
ont tendance à être transmises par rafales, il n’est pas souhaitable de garder inutilement les CVC ouverts
pendant de longues périodes. Il est donc recommandé de configurer un minuteur de temps d’inactivité pour
la libération des communications dans les routeurs en vue d’obtenir un fonctionnement efficace.
3.
X.25 sur IP
3.1
Type de trafic
Trafic SCM traditionnel, c’est-à-dire messages courants continus.
3.2
3.2.1
adjacents.
Le protocole X.25 peut établir une connexion constante ou transitoire entre centres
3.2.2
Il n’y a pas de norme pour X.25 sur IP.
3.3
L’exploitation recommandée pour la partie fondée sur le protocole X.25 est la même que celle
indiquée dans la section 1.3. Comme il n’existe pas de norme pour X.25 sur IP, cette solution est particulière
au routeur. Ainsi, tout routeur et toute configuration de celui-ci doivent être adoptés bilatéralement.
Il est à noter que IP sur X.25 et X.25 sur IP ne sont pas aussi efficaces que X.25 pur ou IP pur.
IP sur X.25 est normalisé (avec les avantages connexes que cela implique). Les centres peuvent souhaiter
passer à X.25 sur IP ou à IP pur si la quantité de trafic IP devient importante, car plus le protocole IP doit
être encapsulé dans X.25, moins la liaison est efficace.
Édition 2009
SUPPLéMENT II-15
PRATIQUES ET PROCéDURES RECOMMANDéES POUR LA MISE EN œUVRE,
L’UTILISATION ET L’APPLICATION DU TRANSMISSION CONTROL PROTOCOL/
INTERNET PROTOCOL (TCP/IP) SUR LE SMT
AVANT-PROPOS
Depuis le début des années 80, l’orientation stratégique du développement du SMT, ratifiée
par la CSB, est fondée sur des normes OSI, en particulier la recommandation UIT-T X.25. Cependant, la
CSB considère maintenant qu’à l’avenir, les protocoles TCP/IP utilisés sur Internet devraient remplacer le
protocole X.25 pour la prise en charge des opérations du SMT.
L’orientation stratégique a évolué au sein de la CSB au cours des dernières années. Cette évolution s’est produite pour divers motifs, y compris les besoins fonctionnels en expansion des divers programmes
de l’OMM et la progression d’Internet et des normes techniques afférentes, qui sont devenus une force
dominante dans l’industrie informatique, supplantant les normes OSI dans de nombreux domaines.
Le passage aux protocoles TCP/IP a été considéré comme approprié du fait:
a) Que le soutien des fournisseurs pour la technique X.25 est en déclin et devient plus cher en raison de
la concentration de l’industrie sur les protocoles TCP/IP;
b) Que les protocoles TCP/IP prennent en charge de nombreux programmes utilitaires d’application
grand public qui offrent des solutions aux besoins des Membres en matière de communication d’informations telles que le transfert de fichiers, les explorateurs Web, le courrier électronique et de futures
applications telles que les communications multimédia;
c) Que les protocoles TCP/IP assurent la connectivité entre les Membres de façon plus souple et universelle que l’équivalent fondé sur le protocole X.25.
Ces avantages correspondent à des économies directes en matière de ressources financières et
humaines pour les Membres grâce:
a) à la réduction du coût d’achat et de maintenance du matériel de communication;
b) à la réduction du travail d’élaboration de logiciels par l’emploi de systèmes logiciels aux normes de
l’industrie.
Des efforts considérables ont été consentis pour définir le cadre d’application des protocoles
TCP/IP au SMT et pour effectuer une transition méthodique à partir de la norme OSI/X.25 d’origine du
SMT. Il est entendu en outre que les protocoles TCP/IP seront à la base de toutes les nouvelles fonctions de
télécommunication qui seront mises en œuvre à l’appui du Système d’information de l’OMM (SIO).
Des procédures sont définies pour garantir la fonction principale du SMT, qui est d’assurer un
trafic opérationnel en temps réel avec un minimum de délais. Le problème de la protection du SMT de toute
interférence avec Internet est également abordé en termes généraux. Il faut cependant faire confiance à tous
les Membres reliés au SMT par une connexion fondée sur les protocoles TCP/IP et qui sont également reliés
à Internet pour qu’ils établissent et appliquent des pratiques minutieuses de sécurité.
Le présent supplément constituait à l’origine l’aboutissement des travaux entrepris par la CSB
en 1997 et 1998. Depuis lors, les procédures TCP/IP ont été adoptées par la plupart des centres nationaux.
On a tiré profit de l’expérience pratique de l’emploi des protocoles TCP/IP pour mettre à jour le matériel en
conséquence. En outre, on a mis en place sur le Web une ressource qui donne de plus amples détails sur la
mise en œuvre technique de nombre des principes et des procédures présentés dans ce supplément. Cette
ressource est disponible sur les pages Web suivantes de l’OMM:
http://www.wmo.int/pages/prog/www/manuals.html
http://www.wmo.int/pages/prog/www/documents.html
Il est vivement conseillé aux Membres de tenir compte de l’adoption d’une stratégie fondée sur
les protocoles TCP/IP pour le futur développement du SMT en vue de planifier la future mise au point de
systèmes dans leurs centres nationaux.
édition 2009
II-15/2
1.
INTRODUCTION
Perspective historique
Actuellement, le SMT sert essentiellement à prendre en charge l’application de commutation
de messages en faisant appel à l’échange de messages en format OMM. Cet échange, qui se fait au moyen:
●
des protocoles TCP/IP;
d’un service de transport limité OSI fondé sur le protocole X.25 point à point;
est complété par des diffusions.
Cette mise en œuvre est suffisante pour l’application héritée de commutation de messages,
mais il est reconnu qu’il lui faut des améliorations constantes pour prendre pleinement en charge les divers
programmes de l’OMM et les nouveaux besoins du SIO. Par exemple, le SMT devrait prendre en charge:
●
●
Des bases de données réparties (BDR);
L’échange de données entre centres non adjacents;
L’échange d’informations qui ne peuvent être prises en charge facilement par des systèmes de commutation de messages (SCM).
Objet du supplément
Le présent supplément a pour objet d’aider les centres à mettre en œuvre sur le SMT des
services fondés sur le Transmission Control Protocol/Internet Protocol (TCP/IP). Il est entendu que dans tout ce
document, la mise en œuvre des protocoles TCP/IP comprend l’ensemble des protocoles essentiels qui font
normalement partie de la suite de protocoles TCP/IP décrits dans les documents de référence RFC112 et
RFC1123 de l’Internet Engineering Task Force (IETF). Ces documents sont disponibles sur le site Web de l’IETF,
à l’adresse http://www.ietf.org/.
Ce supplément porte sur les aspects de l’application du TCP/IP qui s’appliquent précisément
au SMT pour faire face à de nouveaux besoins ainsi que sur l’échange régulier de données, établi depuis
longtemps par l’intermédiaire de systèmes de commutation de messages (SCM). Il tient compte de l’évolution
technique du SMT à partir d’un réseau fondé sur le protocole X.25 et part également du principe que les
centres continuent d’être autonomes dans la mesure du possible, sachant que le moment de la mise en
œuvre de nouveaux systèmes est déterminé par chaque Membre au vu des ressources dont il dispose et de
ses priorités relatives, mais sachant également que les nouvelles fonctions du SIO devraient être mises en
œuvre essentiellement par le biais de protocoles TCP/IP.
Ce supplément porte non pas sur les aspects fondamentaux du TCP/IP, mais sur ses aspects
essentiels pour une application réussie sur le SMT. Ces aspects comprennent l’utilisation appropriée du
SMT par rapport à Internet, la coexistence du SMT et d’Internet, l’adressage IP et X.25 et par un système
autonome, la gestion des routeurs, les services d’application du TCP/IP (comme le protocole de transfert de
fichiers FTP) et la gestion des anomalies. Ce supplément donne aussi un aperçu des pratiques recommandées
en matière de sécurité pour le TCP/IP, mais ne décrit pas en détail les questions et les pratiques en matière
de sécurité, sujet complexe en soi. On trouvera à l’appendice 4 certaines références sur les protocoles TCP/IP
et sur la sécurité informatique. La question de la sécurité est traitée de façon plus détaillée dans le Guide
de la sécurité des technologies de l’information, disponible en anglais sur le site Web de l’OMM à l’adresse
http://www.wmo.int/pages/prog/www/manuals.html.
Rapports entre Internet et le SMT
La capacité, la pénétration et la diversité des applications d’Internet ont progressé rapidement.
Les performances d’un jour sur l’autre d’Internet, que l’on considérait autrefois comme une faiblesse,
atteignent désormais des niveaux acceptables de fiabilité dans de nombreux pays. Il est à noter toutefois
qu’étant donné la nature même d’Internet, personne ne pourra jamais édifier un système fondé sur Internet
pour lequel des niveaux de service déterminés pourront être garantis, Internet étant le résultat d’un amalgame
de nombreux systèmes de télécommunication dont aucun prestataire n’est entièrement responsable.
●
●
Il est donc admis qu’Internet peut servir:
De technologie sous-jacente à certains éléments du SMT dans des conditions particulières;
De système de secours du SMT;
De complément du SMT.
Édition 2009
II-15/3
SUPPLéMENT ii-15
Tableau 1 — Usage du SMT et d’Internet
Élément de
communication
SMT
Internet
Technologies sous-jacentes
Fonction
Liaisons spécialisées, nuages de réseaux
à forte disponibilité, réseaux privés
virtuels via Internet en sauvegarde
ou s’il n’existe pas d’autre technologie
Communications en temps voulu pour des
opérations météorologiques, hydrologiques et
climatologiques
Fournies par le fournisseur d’accès
Communications pour des besoins moins essentiels et éventuellement pour de grands volumes de données
La coexistence avec Internet entraîne des problèmes particuliers de sécurité qu’il convient de
résoudre pour que le SMT puisse jouer son rôle. En particulier, les réseaux doivent être conçus de telle façon
que le SMT soit protégé du trafic général d’Internet et que sa sécurité soit garantie contre une utilisation
inopportune et un accès non autorisé. Par exemple, l’emploi du protocole IP et de protocoles de routage
dynamique tels que le BGP4 (Border Gateway Protocol) sur le SMT devra être conçu de manière à autoriser
une communication entre centres non adjacents uniquement au su et avec l’agrément de tous les centres
intermédiaires. Autrement, il existe un risque qu’une quantité importante de la capacité du SMT serve à un
trafic non régulier, au détriment de l’échange opérationnel de données en temps réel.
Évolution du SMT
L’utilisation de la norme ISO/UIT X.25 a été adoptée par l’OMM au début des années 80 pour
faciliter l’échange de données et de produits codés dans les codes binaires de l’Organisation (GRIB, BUFR, etc.)
et pour servir de base à des applications OSI de plus haut niveau. La norme OSI était considérée à l’époque
comme donnant l’orientation stratégique qui commandait l’évolution de la transmission de données, mais
cela a changé. Actuellement, il ne fait pas de doute que les protocoles TCP/IP sont les protocoles les mieux
acceptés et les plus répandus pour l’échange de données.
Les protocoles TCP/IP sont toujours appropriés du fait:
a) Qu’ils sont les protocoles prédominants pour un usage quotidien, étant désormais assortis de la presque
totalité des fonctions Unix et de nombreux systèmes d’exploitation sur PC;
b)● Qu’ils offrent un grand nombre d’applications standard (transfert de fichiers, courrier électronique,
téléouverture de session, Web, etc.) qui vont considérablement réduire la nécessité, pour les utilisateurs
de l’OMM, d’élaborer des procédures et des protocoles spéciaux, comme cela a été le cas par le passé;
c)● Qu’ils possèdent des fonctions utiles telles que l’acheminement automatique par voie auxiliaire (dans
un réseau maillé), qui pourraient améliorer la fiabilité du SMT.
Ce supplément, cependant, tient compte du fait que les centres possèdent des plans architecturés et des systèmes développés conformes aux normes OSI, particulièrement X.25, homologués par
l’OMM et indiqués dans le Manuel du Système mondial de télécommunications. Il convient de réaliser l’adoption de services fondés sur les protocoles TCP/IP en procédant à une transition ordonnée à partir de liaisons
fondées sur X.25 de telle façon que le fonctionnement du SMT ne soit pas perturbé ou menacé.
Ce supplément permet cette opération en définissant des procédures:
a) Pour un hybride provisoire fondé sur:
i) Le passage de services fondés sur les protocoles TCP/IP à un service de réseau X.25; ou
ii) Le passage de données X.25 sur un réseau fondé sur le protocole IP par l’intermédiaire de routeurs
connectés directement;
b) Pour le passage ultérieur à un protocole IP pur en utilisant des routeurs connectés directement, avec
des services d’application fondés sur des protocoles TCP/IP tels que les points de connexion TCP ou le
protocole de transfert de fichiers (FTP).
Le passage à la deuxième étape (IP pur) est souhaitable pour les raisons suivantes:
a) L’exploitation de TCP/IP sur X.25 peut ne pas donner le débit attendu en raison du surdébit des
routeurs chargés de l’encapsulation de paquets de trames IP dans des paquets X.25. La situation semble
s’aggraver lorsque la vitesse de débit des lignes augmente. Des essais limités réalisés entre centres de la
Région VI indiquent une efficacité inférieure à 70 % à 64 Kbps;
Édition 2009
II-15/4
b) On peut éviter les tâches de gestion et de maintenance nécessaires pour le réseau X.25 et les commutateurs de paquets associés;
c) Le passage de X.25 sur IP exige l’utilisation de caractéristiques exclusives selon le type de routeur.
Pour passer à un protocole IP pur, il est nécessaire de modifier les SCM de chaque centre et de
faire appel à des services TCP/IP tels que le FTP et les points de connexion. Cette question est abordée en
détail au chapitre 4.
Autres questions connexes
De nombreux centres ont désormais l’expérience des protocoles TCP/IP sur le SMT. Cette
expérience indique que les principales questions techniques à résoudre pour établir un usage répandu des
protocoles TCP/IP sur le SMT sont:
a) Des méthodes convenues pour l’application de la commutation de messages afin d’utiliser les protocoles TCP/IP soit directement soit par l’intermédiaire d’applications de plus haut niveau telles que le
FTP;
b) Une convention convenue pour nommer les fichiers et une norme pour les métadonnées associées aux
fichiers;
c)● Une convention pour les noms et les adresses à l’échelon de la communauté.
Le présent supplément a pour but de faire progresser ces questions, certaines desquelles
relèvent de la gestion des données autant que des télécommunications. Il faut également reconnaître que
globalement, le SMT actuel n’est pas un réseau homogène, mais plutôt un ensemble de réseaux régionaux
et de liens discrets point à point. Par ailleurs, des réseaux administrés faisant appel au relais de trame et
à la technique MPLS (Multi Protocol Label Switching) font maintenant partie du SMT. Ces questions vont
poser de nouveaux problèmes en ce qui concerne la coopération multilatérale pour l’exploitation du SMT.
Cependant, ces problèmes n’entrent pas dans le cadre de ce supplément.
2.
Principes gouvernant l’utilisation des protocoles TCP/IP sur le SMT
Gestion du trafic sur le SMT et Internet
Les protocoles TCP/IP permettent:
a) De simplifier les connexions entre systèmes informatiques en autorisant l’intégration de plusieurs techniques de télécommunication dans un réseau cohérent pouvant inclure des voies d’acheminement de
sauvegarde automatiques et redondantes;
b) De réduire les coûts en fournissant des solutions standard pour les transmissions;
c)● D’obtenir des applications modernes qui ne soient pas limitées à des règles fixes et strictes de réception
et de transmission du trafic.
Cependant, il faut bien tenir compte de ce qu’impliquent ces avantages et noter en particulier
qu’une plus grande souplesse des connexions et des applications a pour contrepartie une moindre maîtrise
des destinations du trafic. Par exemple, un lien général avec un nuage de réseaux sur le SMT risque d’être
inondé par un trafic moins essentiel émanant d’un site qui, normalement, ne demande pas de données
passant par une liaison précise. Cela peut aussi signifier que le trafic a du mal a atteindre sa destination du
fait qu’il existe plusieurs itinéraires mal définis (passant par le SMT et Internet) pour y arriver.
Pour tenir compte de ces éléments, on peut procéder à un contrôle et à un tri du trafic portant
sur trois points essentiels:
a) Gestion du trafic (en veillant à la transmission en temps voulu de données critiques et en contrôlant la
disponibilité limitée de la bande passante dans certains secteurs);
b)● Sécurité (en protégeant les centres contre des opérations menaçantes et indésirables);
c)● Cohérence de l’acheminement (en veillant à ce que le réseau global résultant puisse acheminer le trafic
sans difficulté vers n’importe quel point).
Il y a plusieurs aspects importants à considérer pour procéder au contrôle et au tri du trafic:
a) Les adresses IP: utiliser des adresses de réseau reconnaissables universellement et cohérentes de façon
que tous les systèmes ne disposent chacun que d’un seul numéro de référence, valable non seulement
sur le SMT, mais aussi sur Internet et sur tout autre réseau susceptible d’être connecté au SMT;
Édition 2009
SUPPLéMENT ii-15
II-15/5
b) Les règles d’acheminement sur réseau IP: employer un ensemble commun de protocoles et de règles
d’acheminement pour que tout trafic puisse être envoyé de façon cohérente vers son point de destination sans délai ni confusion;
c) Le zonage des éléments de réseau de chaque centre: créer diverses zones de réseau avec divers niveaux
de sécurité afin d’isoler les éléments critiques d’un centre par rapport à des zones accessibles au public
et veiller à ce que les données continuent à circuler entre des zones assorties de divers niveaux de
sécurité.
Topologie d’ensemble des connexions
On trouvera à l’appendice 1 un aperçu général des connexions possibles entre centres qui font
appel au SMT et à Internet, ainsi que des flux de données caractéristiques.
On trouvera à l’appendice 2 des détails sur la configuration du matériel permettant de mettre
en œuvre ces fonctions dans la gamme de routeurs Cisco.
Gestion du trafic
La gestion du trafic est un domaine qui, malheureusement, ne se limite pas aux réseaux, mais
qui implique aussi la gestion des données et la configuration des applications. Plusieurs groupes doivent
donc y participer.
On peut dire en général que certaines applications comme le transfert de fichiers et le Web
risquent de charger considérablement les circuits à largeur de bande limitée que comprend le SMT. Il
faut fixer des limites pour que le SMT ne véhicule que le trafic essentiel, comme les données et produits
couramment échangés en temps réel sur le Système, plus les données à transmettre pour répondre à de
nouveaux besoins comme les bases de données réparties (BDR) et les gros fichiers de données régulièrement
échangés tels que les images transmises par satellite.
Le trafic moins important comme l’échange de fichiers ponctuels, le courrier électronique, le
Web en général et les éléments semblables devrait passer par Internet. Il faut restreindre la capacité totale de
connectivité et d’échange d’informations par TCP/IP pour protéger le SMT. Dans la pratique, le trafic TCP/IP
passant par le SMT pourrait être restreint selon:
a) Le type de protocole (par exemple FTP, HTTP, SMTP, etc.);
b) Les adresses IP émettrices et destinataires;
c) Une combinaison des éléments ci-dessus.
Pour que les mesures adoptées donnent un résultat probant, il est nécessaire:
a) Qu’elles ne soient pas limitées à un seul type de routeur, car on ne peut pas supposer que tous les
centres disposeront du même type de routeur;
b) Qu’elles soient suffisamment faciles à configurer afin de réduire au minimum le risque que des erreurs
de configuration ou des omissions compromettent le fonctionnement du SMT.
Questions de sécurité et séparation du trafic Internet et du trafic SMT
Tout centre qui dispose d’une connexion SMT fondée sur les protocoles TCP/IP et d’une
connexion Internet risque d’être un point faible où le SMT peut être exposé à une interférence délibérée
ou accidentelle en raison d’un trafic indésirable ou d’une connexion non autorisée avec des serveurs du
SMT.
Il est fortement conseillé aux centres de mettre en place des barrières protectrices telles que des
pare-feu sur leur connexion avec Internet. Il est important de prendre toutes les mesures pratiques voulues
pour éviter l’utilisation accidentelle ou délibérée des liaisons SMT ou l’accès non autorisé aux centres du
SMT par des utilisateurs d’Internet.
Lorsqu’on installe le protocole IP sur le SMT, il est essentiel de veiller à ce que le SMT NE soit
PAS intégré à Internet et ne devienne pas une voie de transmission non voulue pour le trafic Internet.
Chaque centre doit considérer le SMT et Internet comme deux réseaux distincts et veiller à ce qu’un flux
inopportun de données ne puisse pas passer de l’un à l’autre. Il sera ainsi garanti que le SMT ne servira qu’à
transmettre de bonne foi des données météorologiques opérationnelles entre serveurs autorisés.
La figure A1.2 de l’appendice 1 montre certains principes de base permettant d’appliquer des
mesures de sécurité fondamentales. Elle illustre, de façon générale, comment on peut établir un centre
Édition 2009
II-15/6
ayant une connexion TCP/IP avec le SMT et une connexion Internet. Les fonctions à mettre en place sont
les suivantes:
a) N’autoriser que des serveurs SMT désignés à passer par le routeur SMT;
b) Bloquer par le pare-feu et le routeur Internet l’accès aux serveurs SMT désignés;
c) Concevoir un pare-feu n’autorisant que les serveurs approuvés pour Internet à accéder aux serveurs B
et ce, uniquement pour des applications approuvées telles que le protocole FTP;
d) Empêcher l’accès par Internet aux serveurs A via des serveurs B.
Le choix de fait des routeurs et du pare-feu et leur mise en place demande des connaissances en
matière de conception et de configuration de réseaux et de systèmes de sécurité. Il ne s’agit pas ici de décrire
par le menu la mise en place et la gestion des systèmes de sécurité car c’est là une question complexe aux
multiples aspects. Il importe simplement de souligner que chaque centre se doit de mettre en œuvre des
mesures de sécurité aussi efficaces que possible compte tenu des capacités et du degré de complexité de ses
installations. L’appendice 4 contient un complément d’information qui intéresse plus particulièrement les
centres de petite taille. En plus d’assurer la sécurité des réseaux, il est essentiel de suivre de bonnes pratiques en
matière de sécurité pour la gestion de tous les serveurs d’un centre. La sécurité informatique est un sujet
complexe en soi; les centres sont incités à l’étudier de manière approfondie et à mettre en œuvre des
pratiques appropriées. L’appendice 5 présente quelques références en matière de sécurité informatique. Un
strict minimum consiste à adopter de bonnes pratiques en matière de mots de passe pour la gestion de tous
les serveurs d’un centre. L’appendice 6 présente quelques pratiques recommandées.
Acheminement et gestion du trafic
Algorithmes d’acheminement
Pour pouvoir transmettre un paquet, chaque serveur, routeur ou matériel relié à un réseau IP
doit disposer d’une table d’acheminement. La table indique au système où envoyer les paquets. Cela peut
se faire:
a) Par acheminement statique; ou
b) Par acheminement dynamique.
Acheminement statique
Dans ce cas, chaque destination voulue et chaque étape suivante doivent être entrées dans les
tables d’acheminement par l’administrateur du système. On peut aussi définir un parcours par défaut, bien
que cette option s’applique surtout aux sites n’ayant qu’une seule connexion avec le monde extérieur. Si
un parcours par défaut est défini, il faut établir des filtres pour garantir que seuls les serveurs autorisés aient
accès au SMT.
Chaque fois qu’un nouveau centre est relié au SMT avec un protocole IP, les administrateurs
de site de tous les autres centres ayant une capacité IP doivent ajouter la nouvelle adresse à leur table
d’acheminement. Cela peut devenir une tâche majeure à mesure que la connectivité IP s’étend sur le SMT.
Acheminement dynamique
Dans ce cas, l’information sur l’acheminement est automatiquement échangée entre routeurs.
Le réseau peut ainsi apprendre de nouvelles adresses et utiliser d’autres voies d’acheminement en cas d’anomalie dans une topologie de réseau partiellement maillé. La mise en place initiale d’un acheminement
dynamique est peut-être légèrement plus complexe, mais la tâche de gestion permanente est considérablement réduite.
L’utilisation d’un acheminement dynamique exige la sélection d’un protocole d’acheminement
approprié qui fonctionne sur les liaisons du SMT. Il faut que ce soit un protocole de passerelle extérieure
(EGP ou BGP, par exemple) étant donné que les protocoles de passerelles intérieures (comme IGRP, RIP et
OSPF) sont conçus pour être utilisés dans un seul domaine de gestion. Or, le SMT est la combinaison de
plusieurs domaines de gestion. Il faut donc choisir un protocole de passerelle que chaque centre puisse
gérer de manière autonome pour assurer l’acheminement et, partant, le flux de données, en fonction de ses
besoins.
Deux protocoles de passerelles extérieures sont définis par des documents RFC — EGP et
BGP (actuellement la version 4: RFC1771). Comme le SMT n’a pas une structure arborescente, la mise en
place d’un acheminement avec le protocole EGP peut s’avérer difficile. La version BGP4 ne souffre pas de
contraintes topologiques. Elle est plus puissante, mais un peu plus difficile à configurer.
Édition 2009
II-15/7
SUPPLÉMENT II-15
Le protocole BGP peut répartir des parcours de sous-réseaux. Cette caractéristique peut être
très utile pour le SMT. Au lieu d’établir des parcours dépendant des serveurs ou des parcours sur des réseaux
entiers, on peut les fonder sur des sous-réseaux. Au lieu de déclarer des serveurs autorisés à faire appel au
SMT, un centre peut déclarer un sous-réseau complet de serveurs autorisés. Dans ce cas, l’information sur
l’acheminement consiste simplement en une adresse IP et en un masque de sous-réseau. Si, par exemple, un
centre a des adresses de classe C 193.168.1.0, en déclarant que le sous-réseau 193.168.1.16 avec le masque
255.255.255.248 est autorisé à passer par le SMT, tous les serveurs dont les adresses vont de 193.168.1.17 à
193.168.1.22 peuvent être acheminés sur le SMT.
Méthode d’acheminement recommandée
Selon les facteurs ci-dessus, le protocole d’acheminement BGP4 devrait être utilisé entre
centres du SMT, sauf si l’on a opté pour une solution bilatérale sur des liaisons individuelles. On trouvera à
l’appendice 2 des exemples d’installation BGP4 pour un routeur de type Cisco.
Adresses enregistrées et adresses privées
Il est recommandé aux centres d’utiliser les adresses IP officiellement enregistrées attribuées par
l’Organisme responsable des inscriptions à Internet (Internet Assigned Numbers Authority (IANA)) ou le registre
Internet régional (Regional Internet Registry (RIR)) compétent. Une adresse IP officielle est obligatoire pour tout
système qui communique par Internet. L’emploi de telles adresses est aussi vivement recommandé pour les
systèmes qui communiquent sur tout réseau interorganisation, y compris le SMT, bien entendu.
Comme on sait que des adresses IP officielles sont parfois difficiles à obtenir dans certaines régions
du monde, des compromis ont été trouvés pour atténuer le problème.
L’appendice 7 aborde de façon plus détaillée la question des adresses IP et des solutions
recommandées pour l’emploi de ces adresses sur le SMT.
Si les centres utilisent des adresses IP privées sur leurs réseaux internes, ils doivent recourir
à la conversion d’adresse de réseau (Network Address Translation (NAT)) pour tout serveur ayant besoin
de communiquer via le SMT ou Internet. Le nombre d’adresses officielles obtenues doit être suffisant en
regard du nombre de serveurs qui sont tenus de communiquer avec l’extérieur et du type de conversion
d’adresse de réseau accepté par le routeur d’accès du centre. Si celui-ci adopte une fonction NAT statique,
à chaque adresse interne doit correspondre une adresse officielle. S’il utilise la fonction NAT dynamique,
alors les adresses internes peuvent être plus nombreuses que les adresses officielles, celles-ci étant attribuées
de manière dynamique par le routeur en fonction des besoins. Il convient de consulter la documentation
relative au routeur d’accès du centre pour vérifier le type de conversion d’adresse de réseau utilisé.
Les adresses privées ne doivent pas apparaître sur le SMT ou sur Internet. On trouvera dans la
figure 2.1 des exemples schématiques de configurations autorisées et non autorisées.
SMT
Internet
NAT
Adresses
enregistrées
Serveur
‘A’
Adresses
privées
Web
Serveur
‘B’
Figure 2.1 a) Configuration autorisée
Édition 2009
II-15/8
PROCÉDURES D’EXPLOITATION DU SMT
SMT
Internet
NAT
Adresses
privées
Serveur
‘A’
Serveur
‘B’
Web
Figure 2.1 b) Configuration autorisée
SMT
Internet
NAT
Adresses
privées
Serveur
‘A’
Adresses
privées
Web
Serveur
‘B’
Figure 2.1 c) Configuration non autorisée
Établissement de liaisons du SMT via Internet
La CSB a estimé que l’emploi d’Internet pour les liaisons du SMT peut s’envisager s’il est d’un
bon rapport coût-efficacité, s’il offre un niveau de service suffisant et si des mesures de sécurité adéquates sont
adoptées. En général, les principes d’acheminement et de sécurité décrits ci-dessus s’appliquent lorsqu’on
emploie des liaisons Internet au lieu de liaisons spécialisées. On trouvera à l’appendice 4 un complément
d’information sur l’emploi des liaisons Internet, en particulier pour les centres du SMT de petite taille.
Résumé des tâches permettant d’assurer une utilisation correcte du protocole IP sur le SMT
N’utiliser que des adresses IP officielles pour les communications extérieures sur le SMT.
Établir une liaison IP avec un ou plusieurs centres. Cette connexion sera purement IP si l’on
utilise PPP comme protocole de niveau 2 sur la liaison (ou un protocole propriétaire tel que Cisco HDLC, en
vertu d’un accord bilatéral) ou IP sur X.25 (RFC1356). Dans ce cas, utiliser des adresses X.121, définies dans
le chapitre 3.
Configurer un acheminement dynamique avec le protocole BGP (sauf si votre centre ne
dispose que d’une connexion sur le SMT et si vous avez convenu avec un centre voisin de faire appel à un
acheminement statique).
Édition 2009
SUPPLéMENT ii-15
II-15/9
Vérifier le pare-feu entre Internet et le SMT (pour prévenir toute communication d’Internet
vers le SMT).
Filtrer le trafic entrant et sortant conformément aux indications ci-dessus.
3.
DIRECTIVES DE MISE EN œUVRE
Introduction
On peut mettre en œuvre des services IP sur le SMT au moyen de liaisons IP directes ou en
utilisant conjointement les protocoles X.25 et IP, en raison de l’évolution technique du SMT décrite au
chapitre 1. On peut assurer les services IP sur un réseau X.25 en encapsulant des paquets IP dans des paquets
X.25. Un routeur correctement configuré réalise cette opération dans chaque centre du SMT. Parallèlement,
lorsque des routeurs du même type sont utilisés dans des centres adjacents, on peut faire passer les données
X.25 par une liaison IP en utilisant la capacité de commutation X.25 des routeurs.
Il est souhaitable par la suite que les centres adoptent, par un accord bilatéral, des connexions
IP directes avec les services d’application TCP/IP (FTP, points de connexion) prenant la place d’IP sur X.25
ou d’X.25 sur IP, selon le cas.
Il est nécessaire de disposer d’un cadre d’adressage pour:
a) La commutation de paquets X.25 entre centres;
b) IP sur X.25;
c) IP direct (y compris X.25 sur IP).
L’usage du protocole BGP nous amène à introduire la notion de système autonome (AS)1). Chaque centre gère un numéro de système autonome qui lui permet d’adopter le protocole BGP avec les
centres voisins. Outre la question de l’adressage, le présent chapitre traite du mécanisme d’attribution des
numéros d’AS.
Adressage de commutation de paquets X.25 entre centres
De nombreux centres ont adopté le protocole X.25 pour des connexions point à point entre
systèmes de commutation de messages (SCM). Plusieurs centres ont installé ou prévoient d’installer des
commutateurs de paquets pour pouvoir établir des liaisons entre centres non adjacents. Un plan d’adressage
a été élaboré dans ce but et a été adopté par le Groupe de travail des télécommunications (treizième session,
1994). Il s’agit d’un numéro de 14 chiffres du type:
0101xxxiiyyyzz où:
0101 désigne un pseudo-code d’identification du réseau de données ne correspondant pas à un code réel,
qui garantit que les appels ne peuvent pas être commutés par erreur sur un réseau autre que le SMT;
xxx désigne le code de pays X.121 du centre;
ii désigne un indicateur de protocole, égal à 00 pour le SCM, à 11 pour TCP/IP, à 22 pour OSI CONS et
à 33 pour OSI CLNS;
yyy désigne le numéro de port affecté sur le plan national;
zz
désigne le numéro de sous-adresse affecté sur le plan national.
Ce plan d’adressage est à utiliser pour établir des communications virtuelles (VC) pour les
applications SCM et pour toute autre application du SMT y compris l’acheminement du trafic IP sur X.25.
Adressage du trafic IP sur X.25
Pour acheminer le trafic IP sur X.25, deux plans d’adressage coordonnés globalement sont
nécessaires:
●
Un plan X.25 tel que décrit ci-dessus;
Un plan d’adressage IP s’appliquant à l’interface entre le routeur et le commutateur de paquets pour
permettre au routeur d’encapsuler les paquets IP dans des paquets X.25.
________
1)
Un système autonome est défini dans RFC1630 comme un ensemble de routeurs, sous une administration
technique unique, qui utilisent un protocole de passerelle intérieure et une métrologie commune pour
acheminer des paquets au sein du système autonome et un protocole de passerelle extérieure pour acheminer
des paquets vers d’autres systèmes autonomes.
Édition 2009
II-15/10
La figure 3.1 montre la disposition générale du système.
Pour que le protocole IP sur X.25 fonctionne correctement, il faut que le réseau X.25 sousjacent possède une seule adresse de réseau IP et que chaque centre dispose d’une adresse dans ce réseau
correspondant au point de connexion entre son routeur et son commutateur de paquets. On affecte à
chaque nœud IP du réseau une adresse séquentielle de serveur dans cette adresse IP unique de classe C,
comme l’indique la figure 3.1. L’adresse de classe C permet de relier 254 centres grâce à un masque de sousréseau 255.255.255.0.
CENTREA
X.121 : 0101xxx00yyyzz
IP : 193.105.177.3
Masque : 255.255.255.0
SCM
SCM
Commutateur
de paquets
Routeur
Commutateur
de paquets
Routeur
Serveur
Serveur
CENTREC
IP : 193.105.177.1
Masque : 255.255.255.0
Commutateur
de paquets
Routeur
SCM
IP : 193.105.177.2
Masque : 255.255.255.0
CENTREB
Serveur
Figure 3.1 — IP mis en œuvre sur un réseau X.25
Les routeurs de chaque centre doivent être configurés de façon à produire une demande d’appel
X.25 au port X.25 du centre destinataire final. Cela signifie que le trafic IP passe par le commutateur de
paquets uniquement, et non par le routeur du centre intermédiaire.
Adressage du trafic IP direct
À l’avenir, le mieux sera d’employer des liaisons IP directes. Les centres qui utilisent déjà le
protocole IP sur X.25 devraient songer à mettre à jour leurs liaisons pour passer aux liaisons IP directes. Cette
évolution devrait être envisagée dans un proche avenir. La figure 3.2 illustre, à titre d’exemple, comment un
couple de centres a convenu de mettre en place une liaison IP directe en faisant appel à la première paire
disponible de numéros de “serveurs” du réseau 193.105.178.0.
Affectation d’adresses de classe C pour les liaisons IP directes
Les routeurs doivent être reliés par des liaisons ayant des numéros de sous-réseau uniques. Pour cela,
on utilise une adresse de classe C (par exemple, 193.105.178.0) avec un masque 255.255.255.252. On
obtient ainsi 62 sous-réseaux possédant chacun 2 serveurs. Les deux numéros de ces serveurs sont
affectés aux extrémités de la liaison reliant les routeurs entre les deux centres. Le numéro de réseau le
plus faible utilisable est 193.105.178.4, avec des adresses de serveurs 193.105.178.5 et 6. Le numéro de
réseau suivant est 193.105.178.8, avec les adresses de serveurs 193.105.178.9 et 10, suivi de:
193.105.178.12, avec des adresses de serveurs 193.105.178.13 et 14, suivi de
193.105.178.16, avec des adresses de serveurs 193.105.178.17 et 18, suivi de
193.105.178.20, avec des adresses de serveurs 193.105.178.21 et 22, et ainsi de suite jusqu’à
193.105.178.248, avec des adresses de serveurs 193.105.178.249 et 250.
Édition 2009
II-15/11
SUPPLéMENT ii-15
CENTREA
SCM
SCM
Routeur
Commutateur
de paquets
Routeur
Serveur
Serveur
CENTREC
IP : 193.105.177.1
Masque : 255.255.255.0
IP : 193.105.177.2
Masque : 255.255.255.0
IP : 193.105.178.6
Masque : 255.255.255.252
Commutateur
de paquets
IP : 193.105.178.5
Masque : 255.255.255.252
CENTREB
Routeur
SCM
Serveur
Figure 3.2 — Liaison IP directe entre les centres B et C
Adressage du trafic X.25 sur IP
Lorsque deux centres possèdent un type commun de routeur (par exemple, Cisco) et que le
trafic est essentiellement IP avec un peu de X.25, il peut être approprié de faire passer le trafic X.25 par les
routeurs directement connectés, comme l’indique la liaison entre le centre B et le centre C dans la figure
3.3. Les paquets X.25 sont acheminés dans les paquets IP sur la liaison série établie entre les routeurs: il
peut s’agir d’un protocole exclusif HDLC ou d’un protocole standard tel que PPP. Cette fonctionnalité exige
que les routeurs de chaque centre contiennent un logiciel de commutation de paquets X.25 et que les
détails d’acheminement par X.25 soient inclus dans la configuration du routeur. L’appendice 2 donne des
exemples de configurations caractéristiques.
CENTREA
SCM
SCM
Routeur
Commutateur
de paquets
Interfaces X.25
Routeur
Serveur
Serveur
CENTREC
IP : 193.105.177.1
Masque : 255.255.255.0
IP : 193.105.177.2
Masque : 255.255.255.0
IP : 193.105.178.6
Masque : 255.255.255.252
Routeur
IP : 193.105.178.5
Masque : 255.255.255.252
Commutateur
de paquets
CENTREB
SCM
Serveur
Figure 3.3 — Combinaison d’IP sur X.25 et de X.25 sur IP
Édition 2009
II-15/12
Numéros de système autonome
L’utilisation du protocole BGP4, protocole d’acheminement dynamique recommandé pour le
SMT (section 2), nécessite l’attribution d’un numéro de système autonome (AS) à chaque centre du SMT.
L’organisme responsable IANA (Internet Assigned Numbers Authority) a réservé, dans RFC1930,
les numéros d’AS 64512 à 65535 pour des utilisations privées (à ne pas diffuser sur le réseau Internet). Huit
groupes de 128 numéros AS sont ainsi attribués aux centres du SMT, ce qui permet de satisfaire les besoins
actuels et futurs du SMT pour autant qu’on puisse les prévoir. Les numéros d’AS seront attribués comme
suit:
Centres du RPT et numéros de réserve
Centres de la Région I
Centres de la Région II
Centres de la Région III
Centres de la Région IV
Centres de la Région V
Centres de la Région VI
Antarctique et numéros de réserve
* Centres du SMT (utilisations privées)
64512 à 64639
64640 à 64767
64768 à 64895
64896 à 65023
65024 à 65151
65152 à 65279
65280 à 65407
65408 à 65471
65472 à 65535
* Ces numéros d’AS sont destinés à une utilisation nationale et ne doivent pas être diffusés sur le SMT.
Détails de mise en œuvre
Pour mettre en place des services IP, les centres doivent connaître certains détails des protocoles
IP et X.25 s’adressant à d’autres centres du SMT. Les diagrammes suivants et les tableaux correspondants
expliquent en détail les informations que doivent connaître les divers centres.
CENTREC
CENTREA
X.121 : Cx’
X.121 : Ax’
SCM
SCM
Routeur
Commutateur
de paquets
Commutateur
de paquets
Routeur
Serveur
Serveur
Adresse IP : A
Adresse IP : C
Adresse IP : Ai
X.121 : Ax
Adresse IP : Ci
X.121 : Cx
Adresse IP : Bi
X.121 : Bx
Adresse IP : Di
X.121 : Dx
Adresse IP : B
Adresse IP : D
Serveur
Serveur
Routeur
Commutateur
de paquets
Commutateur
de paquets
Routeur
SCM
SCM
X.121 : Bx’
X.121 : Dx’
CENTREB
CENTRED
Figure 3.4 — Réseau IP sur X.25
Édition 2009
II-15/13
SUPPLéMENT ii-15
Tableau 3.4a — Adresses IP et X.121 à connaître par le Centre A
Destination
Adresses à connaître
Pour communication
Pour communication
entre extrémités
entre routeurs
Parcours correct
CENTRE B
(serveur à serveur)
Adresse IP : B
Adresse IP : Bi
X.121 : Bx
CENTRE A – CENTRE B
CENTRE C
Adresse IP : C
Adresse IP : Ci
X.121 : Cx
CENTRE A – CENTRE C
CENTRE D
Adresse IP : D
Adresse IP : Di
X.121 : Dx
CENTRE A – CENTRE C – CENTRE D
(Serveur [A] – Routeur [A] – Commutateur de paquets [A] – Commutateur de paquets [C] – Commutateur de paquets [D] – Routeur [D] – Serveur [D])
[x] : CENTRE x
CENTRE B (SCM à SCM)
X.121 : Bx’ (trafic X.25)
CENTRE C (SCM à SCM)
X.121 : Cx’ (trafic X.25)
CENTRE D
(SCM à SCM)
X.121 : Dx’ (trafic X.25)
(SCM [A] – Commutateur de paquets [A] –
Commutateur de paquets [C] – Commutateur de paquets [D] – SCM [D])
Tableau 3.4b — Adresses IP et X.121 à connaître par le Centre B
Destination
Pour communication
Pour communication
entre extrémités
entre routeurs
Parcours correct
CENTRE A (serveur à serveur)
Adresse IP : A
Adresse IP : Ai
X.121 : Ax
CENTRE B – CENTRE A
CENTRE C
Adresse IP : C
Adresse IP : Ci
X.121 : Cx
CENTRE B – CENTRE C
CENTRE D
Adresse IP : D
Adresse IP : Di
X.121 : Dx
CENTRE B – CENTRE C – CENTRE D
CENTRE A (SCM à SCM)
X.121 : Ax’ (trafic X.25)
CENTRE D
(SCM à SCM)
Édition 2009
II-15/14
Tableau 3.4c — Adresses IP et X.121 à connaître par le Centre C
Destination
Pour communication
Pour communication
entre extrémités
entre routeurs
Parcours correct
CENTRE A
Adresse IP : A
Adresse IP : Ai
X.121 : Ax
CENTRE C – CENTRE A
CENTRE B (serveur à serveur)
Adresse IP : B
Adresse IP : Bi
X.121 : Bx
CENTRE C – CENTRE B
CENTRE D
Adresse IP : D
Adresse IP : Di
X.121 : Dx
CENTRE C – CENTRE D
CENTRE D
(SCM à SCM)
Tableau 3.4d — Adresses IP et X.121 à connaître par le Centre D
Destination
Pour communication
Pour communication
entre extrémités
entre routeurs
Parcours correct
CENTRE A
Adresse IP : A
Adresse IP : Ai
X.121 : Ax
CENTRE D – CENTRE C – CENTRE A
Adresse IP : B
Adresse IP : Bi
X.121 : Bx
CENTRE D – CENTRE C – CENTRE B
CENTRE C
Adresse IP : C
Adresse IP : Ci
X.121 : Cx
CENTRE D – CENTRE C
CENTRE C
(SCM à SCM)
Édition 2009
II-15/15
SUPPLéMENT ii-15
CENTREC
CENTREA
Adresse IP : A’
Adresse IP : C’
Adresse IP : Ca
Adresse IP : Ac
SCM
SCM
Routeur
Routeur
Adresse IP : Cb
Serveur
Serveur
Adresse IP : A
Adresse IP : C
Adresse IP : Ab
Adresse IP : Cd
Adresse IP : Ba
Adresse IP : Dc
Adresse IP : D’
Adresse IP : B’
SCM
SCM
Adresse IP : Bc
Routeur
Routeur
Serveur
Serveur
Adresse IP : B
Adresse IP : D
CENTREB
CENTRED
Figure 3.5 — Réseau IP direct
Tableau 3.5a — Adresses IP à connaître par le Centre A
Destination
Pour communication
Pour communication
entre extrémités
entre routeurs
Parcours correct
CENTRE B
Adresse IP : B
Adresse IP : Ba
CENTRE C (serveur à serveur)
Adresse IP : C
Adresse IP : Ca
CENTRE D
Adresse IP : D
Adresse IP : Ca
CENTRE A – CENTRE C – CENTRE D –
(Serveur [A] – Routeur [A] – Routeur [C] –
Routeur [D] – Serveur [D])
[x] : CENTRE x
Adresse IP : B’
Adresse IP : Ba
Adresse IP : C’
Adresse IP : Ca
CENTRE D
(SCM à SCM)
Adresse IP : D’
Adresse IP : Ca
Édition 2009
II-15/16
Tableau 3.5b — Adresses IP à connaître par le Centre B
Destination
Pour communication
entre extrémités
Pour communication
entre routeurs
Parcours correct
CENTRE A
Adresse IP : A
Adresse IP : Ab
Adresse IP : C
Adresse IP : Cb
CENTRE D
Adresse IP : D
Adresse IP : Cb
Adresse IP : A’
Adresse IP : Ab
Adresse IP : C’
Adresse IP : Cb
CENTRE D
(SCM à SCM)
Adresse IP : D’
Adresse IP : Cb
Tableau 3.5c — Adresses IP à connaître par le Centre C
Destination
Pour communication
entre extrémités
Pour communication
entre routeurs
Parcours correct
CENTRE A
Adresse IP : A
Adresse IP : Ac
Adresse IP : B
Adresse IP : Bc
CENTRE D
Adresse IP : D
Adresse IP : Dc
Adresse IP : A’
Adresse IP : Ac
Adresse IP : B’
Adresse IP : Bc
CENTRE D
(SCM à SCM)
Adresse IP : D’
Adresse IP : Dc
Tableau 3.5d — Adresses IP à connaître par le Centre D
Destination
Pour communication
entre extrémités
Pour communication
entre routeurs
Parcours correct
CENTRE A
Adresse IP : A
Adresse IP : Cd
Adresse IP : B
Adresse IP : Cd
CENTRE C
Adresse IP : C
Adresse IP : Cd
Adresse IP : A’
Adresse IP : Cd
Adresse IP : B’
Adresse IP : Cd
CENTRE C
(SCM à SCM)
Adresse IP : C’
Adresse IP : Cd
Édition 2009
II-15/17
SUPPLéMENT ii-15
CENTREC
CENTREA
X.121 : Cx’
X.121 : Ax’
SCM
SCM
Routeur
Commutateur
de paquets
Commutateur
de paquets
Routeur
Adresse IP : C’
Adresse IP : Ci
X.121: Cx
Serveur
Serveur
Adresse IP : A
Adresse IP : C
Adresse IP : Ai
X.121 : Ax
Adresse IP : Cb
Adresse IP : Bi
X.121 : Bx
X.121 : Bx’
Adresse IP : Cd
Adresse IP : Dc
Commutateur
de paquets
SCM
SCM
Routeur
Adresse IP : B’
Routeur
Serveur
Adresse IP : D’
Adresse IP : Bc
Serveur
Adresse IP : D
Adresse IP : B
CENTREB
CENTRED
Figure 3.6 — Coexistence d’IP direct avec IP sur X.25
Tableau 3.6a — Adresses IP et X.121 à connaître par le CENTRE A
Destination
Pour communication
Pour communication
entre extrémités
entre routeurs
Parcours correct
CENTRE B
Adresse IP : B
Adresse IP : Bi
X.121 : Bx
Adresse IP : C
Adresse IP : Ci
X.121 : Cx
CENTRE D
Adresse IP : D
Adresse IP : Di
X.121 : Dx
X.121 : Bx’ (trafic X.25) CENTRE A – CENTRE B
CENTRE C
(SCM à SCM)
CENTRE D
(SCM à SCM)
Unique possibilité : mémorisation et transmission via SCM dans le centre C (trafic X.25)
Édition 2009
II-15/18
Tableau 3.6b — Adresses IP et X.121 à connaître par le CENTRE B
Destination
Pour communication
Pour communication
entre extrémités
entre routeurs
Parcours correct
CENTRE A
Adresse IP : A
Adresse IP : Ai
X.121 : Ax
Adresse IP : C
Adresse IP : Cb
CENTRE D
Adresse IP : D
Adresse IP : Cb
CENTRE C
(SCM à SCM)
Adresse IP : C’
Adresse IP : Cb
CENTRE D
(SCM à SCM)
Adresse IP : D’
Adresse IP : Cb
Tableau 3.6c — Adresses IP et X.121 à connaître par le CENTRE C
Destination
Pour communication
Pour communication
entre extrémités
entre routeurs
Parcours correct
CENTRE A
Adresse IP : A
Adresse IP : Ai
X.121 : Ax
Adresse IP : B
Adresse IP : Bc
CENTRE D
Adresse IP : D
Adresse IP : Dc
CENTRE B
(SCM à SCM)
Adresse IP : B’
Adresse IP : Bc
CENTRE D
(SCM à SCM)
Adresse IP : D’
Adresse IP : Dc
Tableau 3.6d — Adresses IP et X.121 à connaître par le CENTRE D
Destination
Pour communication
Pour communication
entre extrémités
entre routeurs
Parcours correct
CENTRE A
Adresse IP : A
Adresse IP : Cd
Adresse IP : B
Adresse IP : Cd
CENTRE C
Adresse IP : C
Adresse IP : Cd
Unique possibilité : mémorisation et transmission via SCM dans le centre C
(trafic X.25)
CENTRE B
(SCM à SCM)
Adresse IP : B’
Adresse IP : Cd
CENTRE C
(SCM à SCM)
Adresse IP : C’
Adresse IP : Cd
Édition 2009
II-15/19
SUPPLéMENT ii-15
CENTREC
CENTREA
X.121 : Cx’
X.121 : Ax’
SCM
SCM
Routeur
Trafic X.25
Commutateur
de paquets
Commutateur
de paquets
Routeur
Adresse IP : C’
Adresse IP : Ci
X.121 : Cx
Serveur
Serveur
Adresse IP : A
Adresse IP : Ai
X.121 : Ax
Adresse IP : C
Trafic X.25
Adresse IP : Bi
X.121 : Bx
X.121 : Bx’
IP direct
Adresse IP : Cb
Adresse IP : Cd
IP direct
Adresse IP : Dc
X.121 : Dx’
SCM
Commutateur
de paquets
SCM
Routeur
Adresse IP : B’
Routeur
Serveur
Adresse IP : Bc
Serveur
Adresse IP : D
Adresse IP : B
CENTREB
CENTRED
Figure 3.7 — Coexistence d’IP direct, d’IP sur X.25 et de X.25 sur IP
Tableau 3.7a — Adresses IP et X.121 à connaître par le centre A
Destination
Pour communication
Pour communication
entre extrémités
entre routeurs
Parcours correct
CENTRE B
Adresse IP : B
Adresse IP : Bi
X.121 : Bx
CENTRE A – CENTRE B (Serveur [A] –
Routeur [A] – “IP sur X.25” – Commuta-
teur de paquets [A] – “IP sur X.25” – Commutateur de paquets [B] –
“IP sur X.25” – Routeur [B] – Serveur [B])
Adresse IP : C
Adresse IP : Ci
X.121 : Cx
CENTRE A – CENTRE C (Serveur [A] –
Routeur [A] – “IP sur X.25” – Commuta-
teur de paquets [A] – “IP sur X.25” –
Commutateur de paquets [C] –
“IP sur X.25” – Routeur [C] – Serveur [C])
CENTRE D
Adresse IP : D
Adresse IP : Di
X.121 : Dx
CENTRE A – CENTRE C – CENTRE D (Serveur [A] – Routeur [A] – “IP sur X.25” –
Commutateur de paquets [A] – “IP sur X.25” – Commutateur de paquets [C] –
“IP sur X.25 – Routeur [C] – “IP direct” –
Routeur [D] – Serveur [D])
X.121 : Bx’ (trafic X.25) CENTRE A – CENTRE B (SCM [A] –
Commutateur de paquets [A] – Commutateur de paquets [B] – SCM [B])
CENTRE C
(SCM à SCM)
CENTRE A – CENTRE C (SCM [A] –
Commutateur de paquets [A] – Commutateur de paquets [C] – SCM [C])
CENTRE D
(SCM à SCM)
CENTRE A – CENTRE C – CENTRE D (SCM [A] – Commutateur de paquets [A] –
Commutateur de paquets [C] – Routeur [C]
– “X.25 sur IP” – Routeur [D] – SCM[B])
Édition 2009
II-15/20
Tableau 3.7b — Adresses IP et X.121 à connaître par le centre B
Destination
Pour communication
Pour communication
entre extrémités
entre routeurs
Parcours correct
CENTRE A
Adresse IP : A
Adresse IP : Ai
X.121 : Ax
Adresse IP : C
Adresse IP : Cb
CENTRE B – CENTRE C (Serveur [B] –
Routeur [B] – “IP direct” – Routeur [C] – Serveur [C])
CENTRE D
Adresse IP : D
Adresse IP : Db
CENTRE B – CENTRE C – CENTRE D (Serveur [B] – Routeur [B] – “IP direct” – Routeur [C] – “IP direct” – Routeur [D] –
Serveur [D])
CENTRE C
(SCM à SCM)
Adresse IP : C’
CENTRE B – CENTRE C (MSS [B] – Routeur [B] – “IP direct” – Routeur [C] – SCM [C])
CENTRE D
(SCM à SCM)
Adresse IP : Cb
CENTRE B – CENTRE C – CENTRE D (MSS [B] – Commutateur de paquets [B] – Routeur [B] – “X.25 sur IP” – Routeur [C] –
“X.25 sur IP” – Routeur [D] – SCM [D])
Tableau 3.7c — Adresses IP et X.121 à connaître par le centre C
Destination
Pour communication
Pour communication
entre extrémités
entre routeurs
Parcours correct
CENTRE A
Adresse IP : A
Adresse IP : Ai
X.121 : Ax
CENTRE B
Adresse IP : B
Adresse IP : Bc
CENTRE D
Adresse IP : D
Adresse IP : Dc
CENTRE C – CENTRE D (Serveur [C] – Routeur [C] – “IP direct” – Routeur [D] – Serveur [D])
CENTRE B
(SCM à SCM)
Adresse IP : B’
CENTRE C – CENTRE B CENTRE D
(SCM à SCM)
Édition 2009
Adresse IP : Bc
CENTRE C – CENTRE D (SCM [C] – Commutateur de paquets [C] – Routeur [C] – “X.25 sur IP” – Routeur [D] – SCM [D])
II-15/21
SUPPLéMENT ii-15
Tableau 3.7d — Adresses IP et X.121 à connaître par le centre D
Destination
Pour communication
Pour communication
entre extrémités
entre routeurs
Parcours correct
CENTRE A
Adresse IP : A
Adresse IP : Cd
Adresse IP : B
Adresse IP : Cd
CENTRE C
Adresse IP : C
Adresse IP : Cd
CENTRE D – CENTRE C CENTRE A (SCM à SCM)
CENTRE B
(SCM à SCM)
X.121 : Bx’ (trafic X.25) CENTRE D – CENTRE C – CENTRE B
CENTRE C
(SCM à SCM)
CENTRE D – CENTRE C Gestion et affectation d’adresses et de numéros AS
Adresses X.25
Le cadre décrit ci-dessus donne aux centres une autonomie complète pour l’affectation de
nombres X.25. Le Secrétariat de l’OMM va tenir à jour une liste des adresses X.25 que les centres ont affectées pour le SMT. Il est demandé aux centres de notifier le chef de la Division du Système d’information et
de télécommunications, Département des systèmes d’observation et d’information, Secrétariat de l’OMM,
par courrier électronique ou par fax, des adresses X.25 affectées.
Adresses IP
Les adresses IP sont à acquérir ou à convenir selon les instructions figurant à l’appendice 7.
Adresses de serveurs et de réseau dans les centres désignés du SMT
Les adresses de serveurs et de sous-réseau IP à employer par les centres désignés du SMT
devraient être notifiées à l’OMM comme décrit ci-dessus.
Numéros AS
Les numéros AS à utiliser sur le SMT sont coordonnés et émis par le Secrétariat de l’OMM au
fur et à mesure des besoins. Les centres doivent adresser leurs demandes de numéros AS à l’OMM, comme
indiqué ci-dessus.
Publication des adresses et des numéros AS
L’OMM va publier des listes à jour d’adresses et de numéros AS dans le bulletin d’exploitation
mensuel de la VMM. Elle les affichera aussi en format ASCII sur le serveur web de l’OMM pour qu’on puisse
y accéder par le protocole FTP, ainsi que sur le World Wide Web à l’adresse http://www.wmo.int.
4.
Adaptation de systèmes de commutation de messages aux protocoles TCP/IP
Introduction
Bien que de nouvelles exigences apparaissent, pour l’instant, l’usage du SMT est dominé par l’application traditionnelle de commutation de messages, qui a été élaborée pour faire appel à la commutation
de paquets X.25. Nous devons maintenant envisager la meilleure façon de faire évoluer la tâche de commutation de messages en faisant appel aux protocoles TCP/IP pour répondre à de nouveaux besoins en offrant
Édition 2009
II-15/22
des dispositifs “de type Internet” sur le SMT et en voyant comment suivre les tendances de la technologie de
l’information. En outre, le passage des systèmes de commutation de messages (SCM) aux protocoles TCP/IP
signifie que l’infrastructure X.25 peut être éliminée, ce qui simplifie grandement la technique du SMT en le
faisant passer à un réseau purement IP pour remplacer un mélange d’IP et de X.25.
Il existe deux approches techniques à ce problème: l’utilisation de points de connexion TCP
et le protocole FTP. à long terme, on estime que l’approche FTP est la plus intéressante du point de vue
stratégique, mais sa mise en œuvre dans des systèmes de commutation de messages pourrait demander
davantage de travail. L’adoption d’une approche fondée sur la mise en place de points de connexion TCP
comme première étape vers un SMT fondé sur les protocoles TCP/IP pourrait convenir à certains centres.
Le passage des SCM aux protocoles TCP/IP n’implique aucun changement dans la mémorisation
de base et l’architecture d’acheminement du SMT. On envisage que la mémorisation et l’architecture d’acheminement, avec acheminement automatique fondé sur des tables d’acheminement, resteront inchangées.
Cependant, l’adoption du protocole FTP signifie une possibilité supplémentaire d’échange de données par
accords bilatéraux, en utilisant la fonction FTP d’extraction des données lancée par le centre récepteur.
SCM fondés sur des points de connexion TCP
Les points de connexion TCP se prêtent bien à une mise en œuvre régie par programme pour
assurer l’échange régulier de messages. En tant que tels, ils devraient être simplement considérés comme
un protocole parallèle au protocole X.25. Un centre va devoir produire des programmes d’application SCM
susceptibles d’émettre et de recevoir en passant par un point de connexion TCP. Les centres disposant
actuellement d’applications susceptibles de gérer un circuit virtuel X.25 devraient pouvoir produire très
rapidement et simplement une version des points de connexion en modifiant quelques appels système (on
trouvera des échantillons de programmes à l’appendice 3). Le travail de programmation exigé est minimal et,
chose plus importante, toutes les autres fonctions du SCM telles que mise en file d’attente, acheminement,
gestion des données, interfaces avec l’opérateur, etc. restent inchangées, car l’échange de transmissions
reste fondé sur le message traditionnel.
Le protocole défini ici est fondé sur l’hypothèse que le circuit physique sur lequel les données
doivent être transmises a un faible taux d’erreur et fait rarement l’objet d’interruptions. Sur de tels circuits,
on peut s’attendre à ce que le protocole TCP produise des données sans erreurs. Cependant, certains circuits
du SMT risquent de ne pas avoir une qualité suffisante pour que le point de connexion TCP standard
fonctionne de façon fiable. La mise au point de protocoles spéciaux à utiliser sur les circuits de faible qualité
pourrait faire l’objet d’une étude plus poussée.
Des données peuvent se perdre en cas d’interruption de la session TCP. Cela peut-être causé
par une défaillance au niveau du matériel SCM, des applications ou des communications, par exemple
lorsqu’un centre disposant d’au moins deux SCM passe du système principal au système de secours. Les
moyens d’éviter ce problème sont exposés ci-dessous.
Une caractéristique utile des transmissions X.25 n’est pas disponible sur les points de connexion
TCP: c’est la possibilité de détecter le début et la fin des messages par référence au bit M dans l’en-tête des
paquets X.25. Ce type de bit ou un dispositif semblable n’existent pas dans le protocole TCP. Ainsi, pour
permettre aux centres récepteurs de détecter la fin d’un message, il faut faire précéder chaque message d’une
chaîne de 8 caractères indiquant la longueur du message, plus deux caractères indiquant le type du message
(binaire, alphanumérique ou fac-similé). Ainsi, le message sera structuré par une enveloppe SOH/ETX, comme
pour l’échange par X.25. La figure 4.1 illustre la structure complète. On notera que la longueur du message
ne comporte ni le message proprement dit ni l’indicateur de type de message. Cette chaîne doit toujours
comprendre 8 caractères et inclure des zéros en tête selon les besoins. L’indicateur de type de message doit
être codé en caractères ASCII: BI pour binaire, AN pour alphanumérique et FX pour fac-similé. Toute nouvelle
connexion établie doit commencer par la longueur du message et la structure du type de message.
Longueur
du message
(8 caractères)
Type de
nnn
message
ou
CR CR LF
SOH CR CR LF
(2 caractères)
nnnnn
En-tête
CR CR LF ETX
Longueur du message
Longueur du message: de SOH à ETX (par exemple: 00001826 = 1826 octets)
Type de message: AN = alphanumérique, BI = binaire, FX = fac-similé
Figure 4.1 — Structure de message pour applications d’échange entre points de connexion
Édition 2009
SUPPLéMENT ii-15
II-15/23
Les règles d’utilisation de l’échange TCP/IP entre points de connexion peuvent se résumer ainsi:
1. Tout nouvelle connexion doit commencer par un nouveau message;
2. Chaque message est précédé d’une zone indiquant la longueur du message de 8 caractères ASCII et
d’une zone indiquant le type de message de 2 caractères ASCII;
3. La longueur du message est comptée de SOH à ETX inclusivement. Le nombre la désignant doit
contenir des zéros en tête selon les besoins;
4. Le type de message doit être codé ainsi: BI pour binaire, AN pour alphanumérique et FX pour
fac-similé;
5. Les centres destinataires doivent vérifier la synchronisation de la façon suivante:
• Vérifier que les 8 premiers caractères sont numériques ASCII,
• Vérifier que les 9e et 10e caractères sont BI, AN ou FX,
• Vérifier que le 11e caractère est SOH,
• Vérifier que le dernier caractère est ETX;
6. Si la synchronisation est rompue, le destinataire doit couper la communication au moyen de la séquence
ci-après de primitives utilisateurs TCP:
• Arrêt (pour s’assurer que toutes les données contenues dans le tampon d’envoi du TCP ont été
transférées),
• Fermeture;
7. Il est recommandé d’utiliser des points de connexion distincts pour les messages en ASCII et les messages en binaire ainsi que des connexions distinctes pour l’envoi et la réception. C’est toujours à l’expéditeur qu’il incombe d’établir la connexion;
8. Une fois établie, une connexion devrait être maintenue;
9. S’il s’avérait nécessaire de fermer un point de connexion, il faudrait suivre la procédure suivante:
• Arrêt (pour s’assurer que toutes les données contenues dans le tampon d’envoi du TCP ont été
transférées),
• Fermeture;
10.Il faut suivre la même procédure pour arrêter un SCM;
11.Si le destinataire reçoit à l’improviste une nouvelle demande de connexion sur un port où existe déjà
un point de connexion, il convient de le fermer et d’accepter le nouveau point de connexion;
12.Les numéros TCP/IP de service et de port pour ces connexions seront établis par accord bilatéral. Il
convient d’éviter l’utilisation de ports de réserve (1 à 1023), celle des ports dont le numéro est supérieur
à 10000 étant recommandée;
13.Pour limiter les pertes de données en cas de défaillance d’une connexion existante, on peut ajuster la
taille des tampons d’envoi et de réception du protocole TCP. Celle-ci peut être fixée par accord bilatéral, la valeur recommandée étant de 4 kilo-octets;
14.Pour détecter la perte d’un message, l’emploi du numéro d’ordre de voie (CSN) est obligatoire, et pour
récupérer les messages manquants, il convient d’utiliser les procédures de demande de répétition de
l’OMM. Il peut être utile d’automatiser ce mécanisme pour éviter les retards causés par l’intervention
humaine. Enfin, pour réduire au minimum les pertes de données, il est vivement recommandé aux
centres d’utiliser à l’avenir un CSN de 5 caractères;
15.Le numéro d’ordre de voie 000 (ou 00000) doit signifier une initialisation et ne devrait pas donner lieu
à des demandes de retransmission.
Procédures FTP
Introduction
Le protocole FTP (File Transfer Protocol) est un moyen pratique et fiable d’échanger des fichiers,
surtout des fichiers volumineux. Le protocole est défini dans RFC959.
Les principales questions à considérer sont les suivantes:
1. Procédures de cumul de messages en fichiers de façon à réduire au minimum le trafic de service FTP des
messages courts (ne s’applique qu’aux types de messages existants);
2. Conventions de désignation des fichiers pour les types de messages existants (AHL existant);
3. Conventions générales de désignation des fichiers;
4. Changement de nom de fichiers;
5. Emploi de répertoires;
Édition 2009
II-15/24
6.
7.
8.
9.
Noms d’utilisateurs et mots de passe;
Sessions FTP;
Exigences FTP locales;
Compression des fichiers.
Cumul de messages dans des fichiers
Le trafic de service est l’un des problèmes que pose l’utilisation du protocole FTP pour envoyer
des messages SMT traditionnels si chaque message est envoyé séparément. Pour résoudre ce problème, il
faudrait regrouper dans un même fichier plusieurs messages avec leur enveloppe SMT standard selon les
règles énoncées ci-dessous. Cette méthode de cumul ne s’applique qu’aux messages auxquels on a affecté
un AHL. Les centres ont la possibilité d’inclure ou de supprimer les séquences de ligne préliminaire et
de fin de message et d’indiquer l’option qu’ils utilisent au moyen de l’identificateur de format (voir les
points 2 et 4 ci-après).
1. Chaque message doit être précédé d’une zone de 8 octets (8 caractères ASCII) indiquant la longueur du
message. Cette longueur inclut la ligne préliminaire et l’en-tête abrégé (le cas échéant), le texte et la fin
de message.
2. Chaque message doit commencer par la ligne préliminaire telle qu’elle est définie actuellement et l’entête abrégé, comme l’indique la figure 4.2.
3. Les messages doivent se présenter dans les fichiers de la manière suivante:
a)
Indicateur de longueur du message 1 (8 caractères);
b)
Identificateur de format (2 caractères);
c)
Message 1;
d) Indicateur de longueur du message 2 (8 caractères);
e)
Identificateur de format (2 caractères);
f)
Message 2;
g)
Et ainsi de suite, jusqu’au dernier message;
h) Au besoin, et sous réserve d’un accord bilatéral, il est possible de faire suivre le dernier message
réel d’un message “fictif” de longueur zéro pour faciliter la détection de la fin du fichier dans
certains systèmes SCM. Il convient de ne recourir à cette possibilité qu’en cas de besoin et après
accord entre centres sachant que dans la plupart des cas le message “fictif” n’est pas nécessaire.
4. L’identificateur de format (2 caractères ASCII) a l’une des valeurs suivantes:
a) 00 si les séquences ligne préliminaire et fin de message sont présentes;
b) 01 si les séquences ligne préliminaire et fin de message sont absentes (non souhaitable, à éliminer).
5. Le centre émetteur ne doit pas accumuler des messages dans le fichier durant plus de 60 secondes pour
minimiser les délais de transmission; il convient de fixer cette limite en fonction des caractéristiques de
la liaison.
6. Le centre émetteur doit limiter à 100 le nombre de messages que contient un fichier; il convient de fixer
cette limite en fonction des caractéristiques de la liaison.
7. Ce format s’applique indépendamment du nombre de messages, c’est-à-dire qu’il s’applique même s’il
n’y a qu’un message dans le fichier.
Longueur
du message 1
(8 caractères)
Identificateur
de format
SOH CR CR LF
00
nnn
ou
CR
nnnnn
Longueur
CR LF
En-tête
Texte
CR CR LF ETX du message 2
(8 caractères)
Longueur du message
Ligne préliminaire et fin de message présents
Longueur du message: de SOH à ETX (par exemple: 00001826 = 1826 octets)
Longueur
Identificateur
du message 1
de format
(8 caractères)
01
CR CR LF
En-tête
Texte
Longueur
Identificateur
du message 2 de format
(8 caractères)
01
Longueur du message
Cette option n'est pas souhaitable (à éliminer): ligne préliminaire et fin de message absents
Longueur du message: du premier CR à la fin du texte (par exemple: 00001826 = 1826 octets)
Figure 4.2 — Structure d’un message caractéristique dans un fichier
Édition 2009
II-15/25
SUPPLéMENT ii-15
Conventions de désignation des fichiers pour les types de messages existants (AHL existant)
La convention de désignation d’un fichier est:
CCCCNNNNNNNN.ext
où:
CCCC désigne l’identificateur d’emplacement international de quatre lettres du centre émetteur, défini
dans le Volume C de la publication Messages météorologiques (OMM-N° 9);
NNNNNNNN est un numéro séquentiel de 1 à 99999999 produit par le centre émetteur pour chaque
type de données déterminé par ext; on utilise 0 pour (ré)initialiser. S’il y a une limite pour la longueur
de la désignation des fichiers, les centres peuvent utiliser NNNN au lieu de NNNNNNNN sous réserve
d’un accord bilatéral;
ext est:
‘ua’ pour l’information alphanumérique urgente,
‘ub’ pour l’information binaire urgente,
‘a’ pour l’information alphanumérique ordinaire,
‘b’ pour l’information binaire ordinaire,
‘f’ pour l’information fac-similé.
Note: On utilise b ou ub si, à la suite d’un accord bilatéral, des centres autorisent la transmission de données
alphanumériques et binaires dans un même fichier.
Conventions générales de désignation des fichiers
La convention suivante de désignation des fichiers est à appliquer au cours d’une période de
transition devant se terminer au plus tard fin 2008. La date d’application peut être modifiée par la CSB.
La procédure est fondée sur la transmission de paires de fichiers, l’un étant le fichier
d’information, l’autre le fichier de métadonnées associé. Le concept de paires de fichiers permet de mettre
en œuvre la fonction de communication indépendamment de la structure de métadonnées nécessaire pour
la gestion des données tout en prévoyant l’acheminement de métadonnées s’il le faut. Il n’est pas obligatoire
de toujours disposer d’un fichier “.met” dans le cas, par exemple, où le fichier d’information se passe
d’explications ou si un seul fichier “.met” décrit plusieurs fichiers d’information (s’il s’agit, par exemple, du
même type de données pour différentes heures). Il existe toutefois toujours une relation claire entre le nom
du fichier d’information et le nom du fichier de métadonnées qui ne devraient différer que par le champ de
l’extension et d’éventuels caractères génériques.
Pour désigner des fichiers contenant de nouveaux types de messages (pas d’AHL existant),
suivre le format suivant. On peut également adopter ce format pour les noms de fichiers pour types de
messages existants (AHL existant).
Le format du nom des fichiers est une combinaison prédéterminée de champs délimités par
le caractère “_” (soulignement), sauf pour les deux derniers champs, qui sont délimités par le caractère
“.”(point).
Chaque champ peut être de longueur variable, sauf celui de la date et de l’heure, qui est
déterminé d’avance.
L’ordre des champs est obligatoire.
Les différents champs du nom de fichier se présentent de la manière suivante:
pflag_productidentifier_oflag_originator_yyyyMMddhhmmss[_freeformat].type[.compression]
où les champs obligatoires sont:
pflag qui est un caractère ou une combinaison de caractères indiquant comment décoder le champ
productidentifier (identificateur de produit). Pour le moment, les seules valeurs acceptables du champ pflag
sont les suivantes:
Édition 2009
II-15/26
Tableau 4.1 — Valeurs pflag acceptables
pflag
Signification
T
Le champ productidentifier se décode comme un indicateur de données standard T1T2A1A2ii (les indicateurs de données standard de l’OMM sont présentés dans le supplément II-5)
A
Le champ productidentifier se décode comme un en-tête abrégé standard, y compris l’indicateur BBB suivant le cas, sans tenir compte des espaces, par exemple T1T2A1A2iiCCCCYYGGgg[BBB]
W
Identificateur de produit OMM
Z
Identificateur de produit local du centre émetteur
productidentifier est un champ de longueur variable qui contient une description de la nature des
données du fichier. Le champ productidentifier se décode conformément à pflag. L’identificateur de produit OMM à utiliser avec pflag = W se décode ainsi:
<indicateur d’emplacement>,<indicateur de données>,<description libre>,<groupe date-heure
international >,<en-tête de modification BBB>
L’identificateur de produit OMM se compose de deux parties: la “partie statique” pour la description
du produit et la “partie facultative” pour définir l’heure et la situation du produit (correction, amendement).
Il n’y a pas de distinction majuscules-minuscules pour l’identificateur de produit OMM. Les
deux parties se définissent ainsi:
Partie statique: <indicateur d’emplacement>,<indicateur de données>,<description libre>
<indicateur d’emplacement> définit le producteur: pays, organisation et centre de production.
Le pays est représenté par le code officiel normalisé ISO 3166 de deux lettres, par exemple
<gb-metoffice-exeter>. Les champs sont séparés par le symbole “-”.
«Le code normalisé ISO 3166 de deux lettres xx est utilisé pour les organisations internationales
et forme les deux premiers caractères de l’indicateur d’emplacement de ces organisations, par
exemple “xx-eumetsat-darmstadt”, “xx-ecmwf-reading”.»
<indicateur de données> indique le type de données dans les catégories et sous-catégories
définies dans la table de codes commune C-13 du Manuel des codes, par exemple <SYNOP>,
<TAF>, <MODEL>, <RADAR>, <SATELLITE>, etc. Si les données sont de type composite, utiliser
le signe “+” pour les concaténer.
Le champ <description libre> est déterminé par le centre de production pour caractériser le
produit.
Partie facultative: [,<groupe date-heure international>,<en-tête de modification BBB>]
<groupe date-heure international> indique par YYYYMMDDHHMMSS la date et l’heure du
produit pour toute la chaîne de caractères, sans caractères de substitution (décimales uniquement). Ce champ est facultatif, car on trouve la date et l’heure dans le champ Nom de fichier:
yyyyMMddhhmmss.
<en-tête de modification BBB> est un groupe complémentaire ayant une vocation semblable à
celle de l’actuel groupe BBB d’AHL.
Note: Pour faciliter l’identification de chaque champ de l’identificateur de produit, on insère deux symboles “,”
dans la partie statique et la partie facultative ―– si on l’utilise –― afin de séparer les champs. Il ne faut porter
aucun symbole “,” à l’intérieur des champs. Si un champ est vide, on n’insère aucun caractère entre les
séparateurs de champs “_” ou “,”.
oflag est un caractère ou une combinaison de caractères indiquant comment il faut décoder le champ
originator. Pour le moment, la seule valeur acceptable du champ oflag est la suivante:
Tableau 4.2 — Valeur oflag acceptable
oflag
C
Édition 2009
Signification
Le champ originator se décode comme un code CCCC de pays standard
SUPPLéMENT ii-15
II-15/27
originator est un champ de longueur variable contenant des renseignements sur l’origine du fichier. Le
champ originator se décode conformément à oflag.
yyyyMMddhhmmss est un champ Date et heure de longueur fixe. L’interprétation de ce champ devrait
être conforme aux règles standard établies pour la description et les types de données spécifiques. Ce champ
peut donc avoir différentes significations comme la date de création du fichier ou la date de collecte des
données. Si un champ donné n’est pas précisé, il convient de le remplacer par un caractère “-” (signe
moins). Par exemple, ------311500-- ne précise que le jour (31), l’heure (15) et les minutes (00). S’il n’y a pas
de règles concernant un type précis de données, ce champ doit représenter la date et l’heure de création du
fichier par l’émetteur.
Type est un champ de longueur variable qui décrit le type général du format du fichier. Il y a une certaine
redondance entre ce renseignement et le champ productidentifier, mais ce champ est conservé pour des
raisons de compatibilité sectorielle. Il convient de noter que le séparateur qui précède le champ type est un
“.” (point) afin de faciliter le découpage du nom de fichier en champs, sachant qu’il est possible d’utiliser
d’autres signes “_” (soulignement) pour délimiter les sous-champs du champ freeformat.
Tableau 4.3 — Valeurs type acceptables
Type
Signification
met
Il s’agit d’un fichier de métadonnées qui décrit le contenu et le format du fichier
d’information du même nom auquel il correspond
Fichier TIFF
Fichier GIF
Fichier PNG
Fichier Postscript
Fichier MPEG
Fichier JPEG
Fichier texte
Fichier HTML
Fichier contenant des données codées selon un code binaire OMM tel que GRIB ou BUFR
Fichier Microsoft Word
Fichier Corel WordPerfect
Fichier HDF
Fichier NetCDF
Fichier PDF (format de document portable)
tif
gif
png
ps
mpg
jpg
txt
htm
bin
doc
wpd
hdf
nc
pdf
Les champs facultatifs sont les suivants:
a) freeformat est un champ de longueur variable contenant d’autres descripteurs, selon les besoins d’un
émetteur donné. Ce champ peut être divisé en sous-champs. Les pays émetteurs devraient faire en sorte
de communiquer aux autres les descriptions de leur champ freeformat;
b) compression est un champ qui précise si le fichier a été comprimé selon une méthode de compression
standard.
Tableau 4.4 — Valeurs compression acceptables
Compression
Signification
Z
Le fichier a été comprimé par la méthode Unix COMPRESS
zip
Le fichier a été comprimé par la méthode PKWare zip
gz
Le fichier a été comprimé par la méthode Unix gzip
bz2
Le fichier a été comprimé par la méthode Unix bzip2
Longueur maximale du nom du fichier: aucune longueur maximale n’a été fixée pour le nom du fichier en
entier, mais les champs obligatoires ne doivent pas dépasser 128 caractères (y compris les séparateurs) pour
que tous les systèmes internationaux puissent les traiter.
Édition 2009
II-15/28
Jeu de caractères: les noms de fichiers se composent par toute combinaison du jeu de caractères
standard (UIT-T Rec. X.4) compte tenu des exceptions mentionnées dans le tableau 4.5. Il n’y a pas de
distinction majuscules-minuscules, ce qui est largement accepté et appliqué par l’industrie (par exemple pour
les adresses électroniques et les adresses URL). Toutefois, il est recommandé d’utiliser la forme canonique
des noms de fichiers lorsque les fichiers sont traités par un système. Ainsi, il est possible:
a) De sauvegarder les noms de fichiers sous leur forme d’origine, tels qu’ils ont été reçus (avec n’importe
quelle combinaison de majuscules et de minuscules ou n’importe quel jeu de caractères);
b)● De sauvegarder les fichiers en minuscules uniquement en vue d’un traitement interne, d’une comparaison, d’une recherche de noms, etc.;
c)● De retransmettre les fichiers avec leur nom d’origine sauvegardé pour conserver le jeu de caractères et
les différences majuscules-minuscules.
On conserve ainsi l’avantage d’une lisibilité majuscules-minuscules dans tous les systèmes sans
que l’emploi des unes ou des autres n’ait une quelconque incidence sur les opérations de traitement et de
référence.
Tableau 4.5 — Symboles pour les noms de fichiers
Symbole
Autorisé
_
Oui
-
Oui
+
Oui
.
Oui
/
Non
\
Non
>
Non
<
Non
|
Non
?
‘
“
*
Non
Non
Non
Non
Espace
,
Non
Oui
A-Z a-z 0-9
Oui
Édition 2009
Signification
Le soulignement est utilisé comme séparateur. À réserver pour la séparation
des champs. Le soulignement est également acceptable dans le champ
freeformat mais pas dans d’autres champs.
Le symbole “moins” est utilisé uniquement comme séparateur de champs
dans les champs <indicateur d’emplacement> et <description libre> de
l’identificateur de produit OMM, dans le champ productidentifier, dans le cas,
par exemple, d’un indicateur d’emplacement: <gb-metoffice-exeter>. Ce symbole n’apparaît pas dans le champ <indicateur de données>.
Le symbole “plus” est utilisé pour concaténer plusieurs mots de
l’identificateur de produit OMM dans le champ productidentifier. Dans le champ <indicateur de données>, par exemple: TEMP+MOBIL ou CLIMAT+TEMP+SHIP.
Le point est utilisé comme séparateur. Ne doit être utilisé que devant les champs type et compression.
La barre oblique d’un fichier a souvent une signification spéciale pour le nom d’accès complet dans certains systèmes d’exploitation.
La barre oblique inversée a souvent une signification spéciale pour le nom
d’accès complet dans certains systèmes d’exploitation.
Le symbole “supérieur à” ne doit pas être utilisé, car il représente souvent
une manipulation spéciale du fichier dans certains systèmes d’exploitation.
Le symbole “inférieur à” ne doit pas être utilisé, car il représente souvent
une manipulation spéciale du fichier dans certains systèmes d’exploitation.
La barre verticale ne doit pas être utilisée, car elle représente souvent une
manipulation spéciale du fichier dans certains systèmes d’exploitation.
Le point d’interrogation ne doit pas être utilisé.
L’apostrophe inversée simple ne doit pas être utilisée.
L’apostrophe inversée double ne doit pas être utilisée.
L’étoile est souvent utilisée comme caractère générique dans les procédures
qui traitent les noms de fichiers.
L’espace ne doit pas être utilisé.
La virgule doit être utilisée comme séparateur de champs de l’identificateur
de produit OMM dans le champ productidentifier, dans la partie statique,
par exemple: <indicateur d’emplacement>, <indicateur de données>,
<description libre>. Elle peut également être utilisée dans le champ
freeformat.
SUPPLéMENT ii-15
II-15/29
La structure du fichier ‵‘.met’ relatif à la norme OMM concernant les métadonnées de l’OMM
n’est pas définie dans ce guide.
Exemples
•
•
•
•
•
•
•
•
•
Exemple de fichier image (carte météorologique Sig) provenant des États-Unis d’Amérique:
T_PGBE07_C_KWBC_20020610180000_D241_SIG_WEATHER_250-600_VT_06Z.tif
Exemple de fichier de sortie de modèle provenant de France:
A_HPWZ89LFPW131200RRA_C_LFPW_20020913160300.bin
Exemple de fichier d’observations synoptiques de surface provenant de France:
W_fr-meteofrance-Toulouse,SYNOP,MAIN+HOURS,,RRA_C_LFPW_20060913030000.txt
Exemple de fichier de sortie de modèle provenant de France:
W_fr-meteofrance-toulouse,GRIB,ARPEGE-75N10N-60W65E_C_LFPW_200610000000.bin
Exemple de fichier image provenant d’Australie:
Z_IDN60000_C_AMMC_20020617000000.gif
On notera que dans ce cas, la date et l’heure s’interprètent 00 heure, 00 minute et 00 seconde.
Exemple de fichier de données satellite TOVS comprimé provenant du Royaume-Uni:
Z_LWDA_C_EGRR_20020617000000_LWDA16_0000.bin.Z
Exemple de fichier d’images radar provenant du Canada:
T_SDCN50_C_CWAO_200204201530--_WKR_ECHOTOP,2-0,100M,AGL,78,N.gif
Exemple de fichier contenant un seul message GRIB provenant du Canada:
Z__C_CWAO_2002032812----_CMC_reg_TMP_ISBL_500_ps60km_2002032812_P036.bin
Exemple de fichier contenant plusieurs messages provenant de Chine:
Z_SM_C_BABJ_20020520101502.txt
Renommage des fichiers
La méthode utilisée par les centres récepteurs pour détecter la présence d’un nouveau fichier
peut dépendre du type d’appareil utilisé, mais la plupart des centres recherchent les nouveaux fichiers en
explorant un répertoire.
Pour éviter qu’un centre récepteur ne traite un fichier avant de l’avoir reçu intégralement, tous
les centres émetteurs doivent renommer à distance les fichiers qu’ils envoient.
Le fichier est envoyé avec l’extension ‘.tmp’, puis renommé dans le domaine approprié défini
ci-dessus lorsque la transmission est achevée.
Exemples:
a)
b)
Mettre xxxxx RJTD00220401.a.tmp (xxxxx = nom local du fichier)
Renommer RJTD00220401.a.tmp
RJTD00220401.a
Mettre xxxxx AMMC09871234.ub.tmp
Renommer AMMC09871234.ub.tmp
AMMC09871234.ub
Utilisation de répertoires
Certains centres récepteurs souhaitent classer les fichiers dans des sous-répertoires précis. Il
convient de limiter ces exigences au classement de tous les fichiers du même type dans le même répertoire. Il est recommandé d’utiliser un répertoire distinct pour chaque ordinateur principal qui lance des sessions
FTP afin d’éviter le risque de duplication de noms de fichiers.
Noms d’utilisateurs et mots de passe
En passant par le FTP, le centre émetteur se connecte à une machine à distance en utilisant un
nom d’utilisateur et un mot de passe précis. Le centre récepteur définit le nom d’utilisateur et le mot de
passe. Il faut prendre des précautions, car l’opération peut avoir des incidences sur la sécurité des centres.
Les règles générales suivantes devraient s’appliquer:
1. Le centre récepteur définit le nom d’utilisateur et le mot de passe du centre émetteur;
2. On peut utiliser un FTP anonyme ou créer un nom d’utilisateur précis. (Si l’on se sert d’un FTP anonyme,
chaque centre émetteur doit posséder son propre sous-répertoire sur le serveur FTP).
Édition 2009
II-15/30
Sessions FTP
Pour limiter la charge imposée aux systèmes émetteurs et récepteurs, il ne faudrait pas qu’il
y ait plusieurs sessions FTP à la fois par type de fichier. Si, par exemple, le centre A souhaite envoyer au
centre B deux fichiers du même type (mettons .ua), il ne doit pas envoyer le deuxième fichier avant que
la transmission du premier soit achevée. Les centres devraient limiter à cinq au maximum le nombre de
sessions simultanées avec un centre donné.
La temporisation de repos pour fermer la session FTP devrait être comprise entre l’heure de la
fin de l’accumulation de messages (maximum 60 secondes) et un délai maximal de 3 minutes.
Exigences locales concernant le protocole FTP
Tous les centres émetteurs doivent prévoir des commandes FTP “statiques” supplémentaires
dans les commandes FTP qu’ils émettent. Par exemple, certains centres utilisant le système MVS peuvent
avoir besoin de commandes “SITE” pour définir la longueur des enregistrements et des blocs. Les centres
devraient accepter les commandes FTP indiquées dans RFC959 à l’exception de celles qui sont exclues par
accord bilatéral. Il se peut qu’il soit également nécessaire de convenir de procédures et de commandes à
l’échelon bilatéral. C’est aux centres récepteurs de supprimer les fichiers une fois qu’ils ont été traités.
Compression de fichiers
Il est souvent souhaitable de comprimer les fichiers volumineux avant de les envoyer. Les centres ne doivent comprimer des fichiers que s’il existe un accord bilatéral à ce sujet.
Sauvegarde sur le SMT fondé sur IP
Une dernière considération est celle de la sauvegarde du SCM. Le nouveau SMT va utiliser
des adresses IP, où une adresse donnée n’est généralement associée qu’à un système. Si un système tombe
en panne et qu’une autre solution est employée, les centres émetteurs doivent considérer des questions de
mise en œuvre. Idéalement, un centre émetteur ne devrait pas être affecté par les dispositions de sauvegarde
d’un centre récepteur. Il s’agit là d’un bon principe, auquel tous les centres devraient s’efforcer d’adhérer. Cependant, il n’est pas toujours possible d’obtenir une transparence IP complète. Si tel est le cas, les centres
émetteurs doivent être en mesure d’essayer une autre adresse IP. Après cela, ils doivent essayer périodiquement
la première adresse. Il est proposé d’établir cette périodicité par accord bilatéral entre centres, car elle sera
fortement influencée par la stratégie de sauvegarde de chaque centre.
5.
Dépannage et solution de problèmes
Outils de couche IP
Dans un grand réseau IP, tous les routeurs qui acheminent des données entre deux serveurs
doivent connaître le prochain point à atteindre afin de gagner l’adresse de destination. Comme tout routeur
et/ou lien peut tomber en panne, il est très important de déterminer rapidement où se situe le problème et
comment le résoudre.
Voici quelques moyens de résoudre ce type de problème (les mesures proposées ne doivent pas
être forcément appliquées dans l’ordre indiqué):
a) Contrôler le fonctionnement du centre éloigné (si les dispositifs de sécurité de ce centre le permettent);
b) Vérifier si la liaison avec le réseau “extérieur” est accessible;
c) Contrôler le réseau local en essayant d’atteindre la passerelle la plus proche ou la passerelle par
défaut;
d) Vérifier l’ensemble des procédures locales liées au protocole IP et leur configuration.
On trouvera ci-dessous une description de quelques outils de base qui peuvent être utilisés tels
que PING, TRACEROUTE et NETSTAT. PING et TRACEROUTE fournissent des informations sur les trajets de
transmission entre serveurs. Ils utilisent tous les deux le protocole ICMP (traceroute a également besoin du
protocole UDP) mais il convient de noter que de nombreux sites bloquent les paquets ICMP dans le cadre
de leurs mesures de sécurité pare-feu. Pour pouvoir localiser les problèmes qui se posent sur un réseau, il est
nécessaire d’avoir une documentation précise sur ce dernier.
Édition 2009
SUPPLéMENT ii-15
II-15/31
PING
PING vérifie si l’adresse de destination IP peut être atteinte. Cet outil est standard dans presque
tous les systèmes d’exploitation associés à TCP/IP. Sur un serveur Unix, le résultat a l’aspect suivant:
zinder# ping -s cadillac
PING cadillac : 56 data bytes
64 bytes from cadillac (193.168.1.17) : icmp_seq= 0. time=3. ms
---- cadillac PING statistics ---7 packets transmitted, 7 packets received, 0% packet loss
round-trip (ms) min/avg/max = 2/3/5
Un test utile consisterait à effectuer un ping sur le SCM du centre voisin. Si ce ping réussit
dans un délai acceptable, cela veut dire que le réseau fonctionne correctement. En revanche, s’il échoue,
il se pourrait que le circuit soit en panne ou que les paquets ping de la procédure ICMP soient bloqués par
le routeur ou le pare-feu du centre voisin, auquel cas il pourrait être utile d’effectuer un ping sur l’interface
série du routeur du centre voisin. Si le résultat est positif, alors la liaison de télécommunication avec le
centre voisin fonctionne et c’est au niveau de ce centre que se situerait un éventuel dysfonctionnement.
Ping permet aussi de vérifier si la performance du réseau est raisonnable. Le temps est le délai
entre l’envoi et le retour du paquet. Il n’est pas vraiment possible de donner une valeur moyenne pour ce
délai. Ce qui est plus important, c’est de remarquer les variations éventuelles.
Enfin, il peut arriver que des paquets se perdent. Dans ce cas, il y a des nombres manquants
dans icmp_seq. La perte de paquets ou la variation des délais nuisent considérablement aux performances.
TRACEROUTE
Cet outil sert à indiquer les routeurs par lesquels passe l’information entre A et B. Comme il
est dit plus haut, traceroute a besoin de paquets UDP et ICMP pour fonctionner, mais les pare-feu ou les
filtreurs de paquets des routeurs peuvent bloquer ce trafic dans le cadre de la politique locale de sécurité
informatique. Traceroute n’est pas disponible sur tous les systèmes, mais il est plutôt facile à compiler. Il
s’agit d’un outil gratuit disponible sur Internet.
Le résultat de traceroute a l’aspect suivant:
cadillac 22: traceroute ftp.inria.fr
traceroute to ftp.inria.fr (192.93.2.54), 30 hops max, 40 byte packets
1 antonio.meteo.fr (137.129.1.5) 3 ms 2 ms 2 ms
2 clara.meteo.fr (137.129.14.249) 1 ms 2 ms 2 ms
3 andrea.meteo.fr (193.105.190.253) 4 ms 3 ms 2 ms
4 octares1.octares.ft.net (193.48.63.5) 30 ms 35 ms 10 ms
5 192.70.80.97 (192.70.80.97) 9 ms 15 ms 27 ms
6 stamand1.renater.ft.net (195.220.180.21) 40 ms 96 ms 29 ms
7 stamand3.renater.ft.net (195.220.180.41) 56 ms 100 ms 108 ms
8 stlambert.rerif.ft.net (195.220.180.10) 63 ms 56 ms 34 ms
9 193.55.250.34 (193.55.250.34) 46 ms 28 ms 26 ms
10 rocq-gwr.inria.fr (192.93.122.2) 21 ms 147 ms 85 ms
11 ftp.inria.fr (192.93.2.54) 86 ms 58 ms 128 ms
Lorsqu’un routeur ne sait pas où envoyer le paquet, le résultat peut avoir l’aspect suivant:
cadillac 22: traceroute 193.105.178.5
traceroute to 193.105.178.5 (193.105.178.5), 30 hops max, 40 byte packets
1 antonio.meteo.fr (137.129.1.5) 2 ms 1 ms 1 ms
2 clara.meteo.fr (137.129.14.249) 1 ms 4 ms 1 ms
3 andrea.meteo.fr (193.105.190.253) 4 ms 11 ms 4 ms
Édition 2009
II-15/32
4
5
6
7
8
9
10
11
12
13
14
15
16
octares1.octares.ft.net (193.48.63.5) 42 ms 39 ms 42 ms
192.70.80.97 (192.70.80.97) 8 ms 7 ms 7 ms
stamand1.renater.ft.net (195.220.180.5) 48 ms 86 ms 113 ms
rbs1.renater.ft.net (195.220.180.50) 63 ms 107 ms 154 ms
Paris-EBS2.Ebone.net (192.121.156.105) 146 ms 167 ms 140 ms
stockholm-ebs-s5-2.ebone.net (192.121.154.21) 100 ms 80 ms 92 ms
Amsterdam-ebs.Ebone.NET (192.121.155.13) 249 ms 227 ms 205 ms
amsterdam1.NL.EU.net (193.0.15.131) 257 ms 249 ms 316 ms
* Amsterdam5.NL.EU.net (134.222.228.81) 300 ms 297 ms
Amsterdam6.NL.EU.net (134.222.186.6) 359 ms 218 ms 304 ms
Paris1.FR.EU.net (134.222.228.50) 308 ms 311 ms 388 ms
* Etoile0.FR.EU.net (134.222.30.2) 177 ms *
Etoile0.FR.EU.net (134.222.30.2) * * *
Dans ce deuxième cas, cadillac ne pourrait pas atteindre 193.105.178.5 du fait que le routeur
Etoile0.fr.eu.net n’a pas envoyé le paquet. Avec traceroute, il est impossible de savoir si l’anomalie vient du
routeur ou de la liaison.
NETSTAT
La plupart des ordinateurs ont cette commande qui permet d’obtenir des informations sur la
configuration des procédures IP du serveur.
On peut utiliser Netstat pour déterminer si l’adresse locale IP et le masque de sous-réseau
sont configurés correctement et si l’information relative à l’acheminement est toujours valable. Netstat a
beaucoup d’autres applications mais ce n’est pas le propos de ce guide de toutes les décrire.
Le résultat de Netstat peut avoir l’aspect suivant:
$ netstat -rn
Routing tables
Internet:
Destination
Gateway
Netmask
Flags
Refs
Use
Interface
default
141.38.48.2
UG
12
4014211
ec0
127.0.0.1
127.0.0.1
UH
9
2321
lo0
141.38.48
141.38.48.12
0xffffff00
U
3
68981
ec0
141.38.48.12
127.0.0.1
UGH
10
253410
lo0
195.37.164.100
141.38.48.5
UGH
2
345
lo0
224
141.38.48.12
0xf0000000
U
1
19848
ec0
$
Il en ressort que le serveur en question a l’adresse IP 141.38.48.12 avec un masque de sous-réseau
de 24 bits (0Xffffff00 ou 255.255.255.0). Cela montre aussi qu’on peut atteindre le serveur 195.37.164.100
via la passerelle 141.38.48.5, les drapeaux indiquant que la route est active (U), qu’elle mène à une passerelle
(G) et que c’est la route vers un serveur (H). La première ligne indique que toutes les autres destinations
peuvent être atteintes via la passerelle par défaut 14.1.38.48.2 du serveur.
Autre résultat possible:
$ netstat -rn
Routing tables
Internet:
Destination
default
127.0.0.1
141.38.48
141.38.48.12
195.37.164.100
224
$
Édition 2009
Gateway
141.38.48.2
127.0.0.1
141.38.48.12
127.0.0.1
141.38.48.2
141.38.48.12
Netmask
0xffffff00
0xf000000
Flags
UG
UH
U
UGH
UGHM
U
Refs
12
9
3
10
2
1
Use
4014211
2321
68981
253410
345
19848
Interface
ec0
lo0
ec0
lo0
lo0
ec0
II-15/33
SUPPLéMENT ii-15
La seule différence par rapport au premier résultat est que la route vers le serveur 195.37.164.100
est désormais signalée par M, c’est-à-dire qu’elle a été modifiée par un message de réacheminement ICMP
à partir de l’ancienne passerelle 141.38.48.5. Cela signifie en général que le routeur dont l’adresse IP est
141.38.48.5 a perdu sa route vers le serveur 195.37.164.100 et qu’il y a peut-être un dysfonctionnement de
la liaison avec le réseau éloigné.
Autres outils de contrôle
Il faut commencer tout d’abord par vérifier que la connectivité IP est correcte. On peut utiliser
d’autres outils pour mieux comprendre ce qui se passe. En effet, les moyens d’agir ne manquent pas: on
peut par exemple employer des analyseurs de protocoles et des outils logiciels fondés sur la structure SNMP. On citera Sun Microsystems, qui partage avec Solaris un outil appelé snoop qui, dans la plupart des cas, peut
remplacer un analyseur de réseau local. D’autres outils tels que TCPDUMP sont disponibles gratuitement
sur Internet et peuvent être installés sur divers systèmes. C’est ainsi que TCPDUMP est souvent inclus dans
l’offre logicielle Linux. Ces outils demandent une assez bonne connaissance du protocole IP. Toutefois,
TCPDUMP peut être employé, par exemple, pour diagnostiquer des problèmes au niveau des applications. L’exemple ci-après montre comment, sur le serveur “pontiac”, l’on peut capter les échanges
ICMP entre zinder et cadillac. pontiac# /usr/local/bin/tcpdump -i nf0 host cadillac and zinder and proto icmp
15:28:06.68 cadillac.meteo.fr>zinder.meteo.fr: icmp: echo request
15:28:06.68 zinder.meteo.fr>cadillac.meteo.fr: icmp: echo reply
SNMP
Le SNMP (Simple Network Management Protocol) a été mis au point à la fin des années 80 pour
offrir aux administrateurs de réseaux un outil standard de contrôle des réseaux. Dans la plupart des cas,
on peut faire appel au SNMP pour remplacer les outils plus primitifs décrits ci-dessus. Malheureusement,
un bon logiciel SNMP coûte cher. Le SNMP est un protocole client-serveur. Pour qu’on puisse obtenir des
informations grâce au SNMP, le matériel relié au réseau doit disposer d’une base d’information de gestion
(MIB). Ces bases sont des catalogues d’entiers, de compteurs, de chaînes, etc. L’administrateur demande aux
agents de lui envoyer certaines valeurs. Ces valeurs peuvent être, par exemple, une table d’acheminement
IP. à titre d’exemple, on obtient le résultat ci-dessous en demandant, avec le progiciel commercial HP Open
View, la table d’acheminement sur le serveur monica.meteo.fr.
Titre: : monica.meteo.fr
Nom ou adresse ip: monica.meteo.fr
IpRouteDest
0.0.0.0
136.156.0.0
137.129.1.0
137.129.2.0
137.129.3.0
137.129.4.0
137.129.5.0
137.129.6.0
137.129.7.0
137.129.8.0
137.129.9.0
ipRouteMask
0.0.0.0
255.255.0.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
ipRouteNextHop
137.129.1.5
137.129.1.5
137.129.1.6
137.129.1.5
137.129.3.254
137.129.4.254
137.129.5.254
137.129.1.62
137.129.7.254
137.129.8.254
137.129.1.5
ipRouteProto
loca
ciscoIgrp
local
ciscoIgrp
local
local
local
local
local
local
ciscoIgrp
ipRouteMetric1
0
8786
0
1110
0
0
0
0
0
0
1110
Les informations indiquées ci-dessus au moyen de TCPDUMP peuvent être obtenues avec
SNMP, mais il faut pour cela que des sondes faisant fonctionner la base d’information de gestion soient
reliées au réseau.
Sur une base bilatérale, il serait utile que les centres autorisent la structure SNMP à accéder à
leur routeur à partir d’un autre centre. Il faudrait cependant éviter l’interrogation régulière des routeurs des
autres centres pour éviter de surcharger les circuits.
Édition 2009
II-15/34
MRTG
Autre logiciel appartenant au domaine public, le Multi Router Traffic Grapher (MRTG) est un
outil très utile qui sert à rassembler des informations relatives au réseau local et aux lignes connectées. Il
surveille la charge de trafic sur les réseaux et les liaisons et génère des pages HTML contenant des images
qui permettent de visualiser ce trafic. MRTG sert aussi à signaler d’éventuelles défaillances des liens de
réseau. Il consiste en un script écrit en Perl qui utilise le protocole SNMP pour lire les compteurs de trafic
des routeurs et en un programme rapide écrit en langage C qui enregistre les données et les présente sous
forme de graphiques représentant le trafic sur les connexions des réseaux qui font l’objet du contrôle. On
trouvera ci-après un résultat type obtenu avec MRTG. Il montre des statistiques du trafic pour une liaison
spécialisée et donne des informations sur la configuration du trafic sur cette liaison. Ce n’est qu’un des
nombreux graphiques que MRTG permet d’obtenir. SYSLOG
Nombre des problèmes éventuels peuvent être localisés si l’on ne se contente pas de regarder
les fichiers SYSLOG sur les ordinateurs hôtes, mais si l’on utilise aussi un serveur SYSLOG et si on laisse le(s)
routeur(s) lui envoyer des messages. On peut ensuite contrôler régulièrement ces fichiers, par exemple pour
voir s’ils contiennent des messages signalant une utilisation intensive de l’unité centrale, des processus qui
utilisent une grande partie de la mémoire ou de l’unité centrale, une activation ou désactivation de liaisons
et des messages concernant des événements relatifs au protocole d’acheminement utilisé. Il existe huit niveaux de messages que le routeur enregistre dans le serveur SYSLOG. Ce sont
les suivants:
Emergencies (urgences)
Alerts (alertes)
Critical (état critique)
Errors (erreurs)
Édition 2009
0
1
2
3
Système inutilisable
Mesures immédiates requises
Conditions critiques
Message d’erreur
SUPPLéMENT ii-15
Warnings (avertissements)
Notifications (notifications)
Informational (informations)
Debugging (mise au point)
4
5
6
7
II-15/35
Message d’avertissement
Conditions normales mais significatives
Messages d’information uniquement
Messages de mise au point
L’état par défaut de l’unité d’enregistrement d’un routeur Cisco est fixé à local 7; c’est important
de le savoir au moment de configurer un ordinateur hôte pour qu’il soit un serveur SYSLOG, ainsi qu’il est
expliqué ci-après.
suivantes:
Les commandes de configuration sur un routeur Cisco, pour activer l’enregistrement, sont les
cisco-gts-1(config)#logging trap level-of-messages-to-log
cisco-gts-1(config)#logging 141.38.48.12
On peut les vérifier au moyen de la commande “show logging”:
cisco-gts-1#sho logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: level debugging, 117892 messages logged
Monitor logging: level debugging, 8317 messages logged
Trap logging: level debugging, 117150 messages lines logged
Logging to 141.38.48.12, 117150 message lines logged
Buffer logging: disabled
cisco-gts-1#
Dans cet exemple, l’enregistrement est positionné au niveau mise au point (“logging trap
debugging”), et tous les messages du niveau 7 au niveau 0 sont envoyés au serveur SYSLOG avec l’adresse
IP 141.38.48.12.
Pour activer le serveur SYSLOG, par exemple sur une machine SGI UNIX, il faut utiliser les
paramètres suivants:
In the file/etc/services: syslog 514/udp
In the file/etc/syslog.conf: local7.debug /usr/ people/cisco/logs/cisco.log
Le paramètre “local7.debug” est l’état par défaut de l’unité d’enregistrement sur un routeur
Cisco. Le fichier ci-dessus est le fichier sur lequel le démon syslog enregistre tous les messages syslog
entrants correspondant à l’état “local7”.
Sur l’ordinateur hôte, la dernière mesure consiste à faire relire son fichier de configuration par
le démon syslog (kill-1 pid-of-syslogd).
Gestion de la largeur de bande
Sur un réseau IP, tous les paquets sont acheminés sur les liaisons sans mécanisme de priorité. Ainsi, un transfert FTP peut occuper toute la largeur de bande disponible et bloquer par conséquent toutes les
autres applications. Lorsque le trafic s’accroît, il pourrait donc être souhaitable d’introduire un mécanisme
de gestion de la largeur de bande dans la configuration du réseau. Pour de plus amples informations à ce
sujet on peut consulter, en ligne, le site http://www.wmo.int/.
AppendiCE 1
Topologie TCP/IP de haut niveau et flux de données TCP/IP
Les schémas suivants donnent une vue de haut niveau de la topologie d’un centre simple et des
principaux flux de données de télécommunication sur le SMT et Internet. On trouvera des configurations
X.25 sur IP plus détaillées dans les appendices ci-après.
Édition 2009
II-15/36
SMT
INTERNET
CENTRE A
CENTRE B
RÉSEAU
DE DIFFUSION
AUTRES LIAISONS CLASSIQUES ET DE SECOURS HORS SMT
Figure A1.1 — Interconnectivité générale entre centres
STATION DE TRAVAIL 1
LIAISON ASSURÉE
PAR L’ENTREPRISE DE
TÉLÉCOMMUNCIATIONS
PORTAIL/
SERVEUR 1
PORTAIL/
SERVEUR 2
INTERFACE VPN
RÉCEPTEUR DE
VIDÉOTRANSMISSION
NUMÉRIQUE
SOUS-RÉSEAU
DE LA DMZ
SERVEUR DE
COMMUTATION
DE MESSAGES 1
SERVEUR DE
COMMUTATION
DE MESSAGES 2
PARE-FEU
LES PARE-FEU BLOQUENT
TOUT LE TRAFIC DANS
LES DEUX SENS, NE
LAISSANT PASSER QUE
LE TRAFIC CONNU
LIAISON ASSURÉE
PAR LE FOURNISSEUR
D’ACCÈS INTERNET
AUTRES SYSTÈMES
ROUTEUR/PARE-FEU
DU DISPOSIF
D’ACCÈS
ROUTEUR/
PARE-FEU INTERNE
SOUS-RÉSEAU
À PROTECTION
INTERNE
CENTRE A
SMT
ROUTEUR/PARE-FEU
DU DISPOSITIF
D’ACCÈS
RÉCEPTEUR SMPZ
INTERNET
SOUS-RÉSEAU
PUBLIC
Figure A1.2 — Topologie d’un réseau TCP/IP dans un centre simple
CONNEXION CARACTÉRISTIQUE AVEC LE SMT
LIAISON ASSURÉE PAR
L’ENTREPRISE DE
PORTAIL/
SERVEUR 1
PORTAIL/
SERVEUR 2
ROUTEUR/PARE-FEU
RÉCEPTEUR SMPZ
INTERFACE VPN
RÉCEPTEUR DE
VIDÉOTRANSMISSION
NUMÉRIQUE
SERVEUR DE
COMMUTATION
DE MESSAGES 1
SOUS-RÉSEAU
DE LA DMZ
SERVEUR DE
COMMUTATION
DE MESSAGES 2
PARE-FEU
LE FOURNISSEUR
D’ACCÈS INTERNET
AUTRES SYSTÈMES
ROUTEUR/
PARE-FEU INTERNE
SMT
DU DISPOSITIF
D’ACCÈS
SOUS-RÉSEAU
À PROTECTION
INTERNE
ROUTEUR/PARE-FEU
DU DISPOSITIF
D’ACCÈS
INTERNET
SOUS-RÉSEAU
PUBLIC
CENTRE A
Figure A1.3 — Flux de données sur le SMT – IP uniquement
Édition 2009
II-15/37
SUPPLéMENT ii-15
CONNEXION CARACTÉRISTIQUE AVEC LE SMT AVEC X.25 SUR IP
(exige aussi un serveur de commutation de messages pouvant prendre en charge X.25 dans l’autre centre)
L’ENTREPRISE DE
PORTAIL/
SERVEUR 1
PORTAIL/
SERVEUR 2
LIAISON SÉRIE
AVEC X.25
SERVEUR DE
COMMUTATION
DE MESSAGES 1
SMT
ROUTEUR/PARE-FEU
RÉCEPTEUR SMPZ
DU DISPOSITIF
D’ACCÈS
INTERFACE VPN
RÉCEPTEUR DE
VIDÉOTRANSMISSION
NUMÉRIQUE
ROUTEUR
D’ENCAPSULATION
X.25
SOUS-RÉSEAU
DE LA DMZ
SERVEUR DE
COMMUTATION DE
MESSAGES 2
PARE-FEU
LE FOURNISSEUR
D’ACCÈS INTERNET
AUTRES SYSTÈMES
ROUTEUR/
PARE-FEU INTERNE
CENTRE A
INTERNET
ROUTEUR/PARE-FEU
DU DISPOSITIF
D’ACCÈS
SOUS-RÉSEAU
À PROTECTION
INTERNE
SOUS-RÉSEAU
PUBLIC
Figure A1.4 — Flux de données sur le SMT – X.25 sur IP
ET ET
CONNEXION
INTERNET
CONNEXIONCARACTÉRISTIQUE
VPN CARACTÉRISTIQUE PAR
PAR INTERNET
L’ENTREPRISE DE
PORTAIL/
SERVEUR 1
PORTAIL/
SERVEUR 2
INTERFACE VPN
RÉCEPTEUR DE
VIDÉOTRANSMISSION
NUMÉRIQUE
SERVEUR DE
COMMUTATION DE
MESSAGES 1
SOUS-RÉSEAU
DE LA DMZ
SERVEUR DE
COMMUTATION DE
MESSAGES 2
PARE-FEU
LIAISON ASSURÉE
PAR LE FOURNISSEUR
D’ACCÈS INTERNET
AUTRES SYSTÈMES
ROUTEUR/
PARE-FEU INTERNE
SOUS-RÉSEAU
À PROTECTION
INTERNE
CENTRE A
SMT
ROUTEUR/PARE-FEU
DU DISPOSITIF
D’ACCÈS
RÉCEPTEUR WAFS
ROUTEUR/PARE-FEU
DU DISPOSITIF
D’ACCÈS
INTERNET
SOUS-RÉSEAU
PUBLIC
Figure A1.5 — Flux de données passant par un réseau privé virtuel sur Internet
AppendiCE 2
CONFIGURATION DES ROUTEURS CISCO
Le présent appendice n’entend pas présenter une description complète de toutes les commandes
disponibles dans un routeur Cisco ni un cours complet sur ce matériel, mais il convient de décrire de
façon plus précise les tâches de configuration afin de respecter la politique définie au chapitre 2 de ce
supplément.
La configuration décrite ci-après respecte les instructions disponibles dans la version 11.1 du
logiciel Cisco IOS. Certaines caractéristiques ne sont pas disponibles dans les versions précédentes et d’autres
vont être modifiées à l’avenir.
Nous allons décrire diverses étapes:
1. Établissement d’une connexion IP
– IP sur PPP
– IP sur X.25
– X.25 sur IP (il s’agit en fait de X.25 sur TCP, le protocole XOT)
Édition 2009
II-15/38
2. Configuration d’acheminement
– Nœud terminal avec acheminement statique (centre A)
– Nœud terminal avec acheminement dynamique (centre C)
– Configuration dans un nœud non terminal (dans le cas présent, deux connexions distinctes sur le
SMT, centre B)
3. Configuration de la sécurité
– Filtrage du trafic fondé sur les adresses IP déclarées
– Contrôle de l’échange d’acheminements entre le SMT et Internet
CENTRE C
CENTRE A
X.121 : Cx’
X.121 : Ax’
Commutateur
de paquets
SCM
Routeur
S0
S0 Commutateur
de paquets
Internet
Routeur
SCM
Adresse IP : C’
S1
Serveur
Serveur
Adresse IP : A
Adresse IP : C
Adresse IP : Ai
X.121 : Ax
Adresse IP : Cb
Adresse IP : Bi
X.121 : Bx
X.121 : Bx’
SCM
Commutateur
de paquets
S0
Adresse IP : B’
Routeur S
1
Serveur
Adresse IP : B
Adresse IP : Bc
Internet
CENTRE B
Dans notre exemple, A est relié à B par une liaison IP sur X.25 et B est relié à C par une liaison
IP sur PPP. Il existe aussi la possibilité que les SCM de B et de C communiquent par X.25 sur TCP/IP. A est
un nœud terminal tandis que B et C sont des nœuds non terminaux. B et C sont également reliés à Internet.
B et son fournisseur Internet utilisent un mode d’acheminement statique1 tandis que C et son fournisseur
Internet utilisent le protocole RIP2.
Les éléments suivants vont être utilisés dans cet appendice:
Adresse du
routeur X.121
Adresse du
routeur IP
Adresse de serveurs IP
pour le SMT
Système
autonome
Centre A
Centre B
Centre C
01016661166666
01017771177777
01018881188888
193.105.177.1
193.105.177.2
193.105.178.5
193.105.178.6
194.168.1.16/255.255.255.248
137.129.9.0/255.255.255.0
Non disponible
65001
195.1.1.0/255.255.255.0
65200
_______
B ne peut pas utiliser les protocoles EGP et BGP sur le même routeur. Un routeur ne peut pas appartenir à plus
d’un AS.
2
Le protocole RIP n’est PAS un choix judicieux pour ce type de configuration. Mais comme RIP est le protocole
le plus simple, il est utilisé dans ce cas également.
1
Édition 2009
SUPPLéMENT ii-15
II-15/39
Les centres A et B utilisent l’interface série 0 pour se connecter aux commutateurs de paquets,
et les centres B et C utilisent l’interface série 1 pour la liaison PPP.
Étape 1: Établissement des connexions
Centre A:
interface serial 0
encapsulation X25
! Selon le montage local (canaux virtuels, fenêtres, … ), une configuration complémentaire peut s’avérer nécessaire
x25 address 01016661166666
ip address 193.105.177.1 255.255.255.0
!
x25 map ip 193.105.177.2 01017771177777
Centre B:
interface serial 0
encapsulation X25
x25 address 01017771177777
ip address 193.105.177.2 255.255.255.0
!
x25 map ip 193.105.177.1 01016661166666
!
interface serial 1
encapsulation PPP
ip address 193.105.178.5 255.255.255.252
!
! Commandes X25 sur TCP
x25 routing
x25 route 010188811* ip 193.105.178.6
x25 route 010177711* interface serial 0
Centre C:
interface serial 0
encapsulation X25
x25 address 01018881188888
interface serial 1
encapsulation PPP
ip address 193.105.178.6 255.255.255.252
!
! Commandes X25 sur TCP
x25 routing
x25 route 010177711* ip 193.105.178.5
x25 route 010188811* interface serial 0
Après cette première étape, la configuration IP entre les routeurs est complète. Le routeur du
centre A peut effectuer un ping sur le routeur du centre B. B peut effectuer un ping sur A et C, mais A et C
ne peuvent pas communiquer du fait qu’aucun itinéraire n’est établi.
Les SCM de B et de C peuvent communiquer avec IP (une fois que l’acheminement de bout
en bout est établi) ou avec X.25 sur TCP. L’expérience indique que tous les paramètres X.25 des routeurs
des centres B et C DOIVENT être les mêmes (volume des paquets, taille des fenêtres) pour éviter toute
anomalie.
Étape 2: acheminement
Centre A:
! Définir simplement un itinéraire par défaut avec un 10 métrique (notion de coût) via B
ip route 0.0.0.0 255.255.255.255 193.105.177.2 10
Édition 2009
II-15/40
Centre B:
! Définir d’abord un itinéraire statique avec A
ip route 194.168.1.16 255.255.255.248 193.105.177.1 10
ip route 0.0.0.0 ip_provider_address 10
! Acheminement BGP
router bgp 65001
network 137.129.9.0 mask 255.255.255.0
neighbour 193.105.178.6 remote-as 65200
! Itinéraire A statique, transmission vers C imposée
redistribute static
Centre C:
! Acheminement BGP
router bgp 65200
network 195.1.1.0
! 196.1.1.0 est l’adresse de réseau pour les serveurs de C n’appartenant pas au SMT
router rip
version 2
network 195.1.1.0
no auto-summary
A définit un itinéraire par défaut. Ainsi, lorsque A souhaite communiquer avec C, le routeur
sait où envoyer les paquets. C va recevoir des informations sur l’acheminement de B, ce qui fait que A peut
également être atteint depuis C. Il est également important de noter que si A cherche à atteindre un site
Internet, des tentatives seront faites par la connexion Internet de B. L’opération va échouer, parce que le
site Internet auquel A tente d’accéder ne peut pas renvoyer les paquets à A (seule l’adresse de B peut être
atteinte sur Internet via la connexion Internet de B). La liaison entre A et B va ainsi acheminer des données
inopportunes. Il convient de noter que c’est la version 2 du protocole RIP qui est utilisée ici.
Étape 3: Sécurité
Centre A:
! Déclarer les serveurs pouvant passer par le SMT
access-list 1 permit 194.168.1.16 0.0.0.7
! Déclarer les serveurs dont les données peuvent émaner du SMT
!
interface serial 0
ip access-group 1 out
ip access-group 2 in
Centre B:
! N’accepter que les mises à jour BGP du voisin dans le cadre de l’AS
ip as-path access-list 3 permit ^$
ip as-path access-list 3 permit ^65200
!
interface serial 0
!
interface serial 1
! Restriction des mises à jour BGP
Édition 2009
SUPPLéMENT ii-15
II-15/41
router bgp 65001
network 137.129.9.0 mask 255.255.255.0
neighbour 193.105.178.6 filter-list 3 in
neighbour 193.105.178.6 filter-list 3 out
redistribute static
Centre C:
! N’accepter que les mises à jour BGP du voisin dans le cadre de l’AS
ip as-path access-list 3 permit ^$
ip as-path access-list 3 permit ^65001
!
interface serial 0
! Restreindre les mises à jour BGP
router bgp 65200
network 195.1.1.0 mask 255.255.255.0
neighbour 193.105.178.5 filter-list 3 in
neighbour 193.105.178.5 filter-list 3 out
Dans ces configurations deux caractéristiques importantes sont employées:
a) Le filtrage BGP
La liste d’accès 3 de B et de C vérifie le numéro de système autonome envoyé par son voisin. En laissant
passer ou non les données dans le processus BGP, cela garantit que tous les itinéraires connus doivent
émaner d’un de ces systèmes autonomes (AS);
b) Le filtrage IP
La liste d’accès 1 autorise les adresses IP émanant de chaque centre. Cette liste doit être stable. La liste
d’accès 2 vérifie les adresses IP en entrée. à mesure que de nouveaux centres s’ajoutent au réseau IP, les
adresses correspondantes doivent être ajoutées à ces listes d’accès.
Il est également à noter que malgré les connexions Internet des centres B et C, il n’y a rien à
faire de plus pour contrôler l’échange d’acheminement. Un itinéraire statique par défaut n’est pas établi
même si la “redistribution statique” est validée. RIP et BGP ne tiennent pas compte de l’information sur
l’acheminement connue par l’intermédiaire de l’autre protocole.
AppendiCE 3
éCHANTILLON DE PROGRAMME D’ÉMISSION ET DE RÉCEPTION PAR DES POINTS DE CONNEXION
/*******************************************************************************************************************
* Échantillon de programme d’un point de connexion TCP/IP qui ENVOIE un seul message.
*******************************************************************************************************************/
#include<stdio.h>
#include<unistd.h>
#include<stdlib.h>
#include<signal.h>
#include<string.h>
#include<memory.h>
#include<sys/socket.h>
#include<netinet/in.h>
#include<netdb.h>
/* LA DESTINATION TCP/IP ET LE SERVICE SONT DÉFINIS PAR LE CENTRE RÉCEPTEUR */
Édition 2009
II-15/42
#define DESTINATION “localhost”
#define SERVICE 39000
#define GTS_LENFIELD 8
#define MAX_MSGSIZE 15000 /* taille du tampon d’envoi recommandée: 4096 */
static void GetDestinationInfo();
static void SetupSocket();
static void SendData();
static void MakeConnection();
static struct sockaddr_in dest;
static int pr_sock;
/*******************************************************************************************************************
*
GRANDES LIGNES (MAINLINE)
* 1. Ne tenez pas compte des signaux SIGPIPE. Ceux-ci se produisent si une communication
* est interrompue. Par défaut, ils suspendent l’exécution d’un programme.
* 2. Obtenez des informations sur la destination (GetDestinationInfo):
* – numéro (et nom) IP
* – numéro de service et de port.
* 3. Créez un point de connexion TCP/IP (SetupSocket).
* 4. Entrez en communication avec le centre destinataire (MakeConnection).
* 5. Envoyez le message (SendData).
* 6. Fermez le point de connexion (shutdown + close).
*******************************************************************************************************************/
main(int argc, char *argv[])
{
signal (SIGPIPE,SIG_IGN);
GetDestinationInfo();
SetupSocket();
MakeConnection();
SendData();
/* shutdown(pr_sock, 1) */
close(pr_sock);
}
/*******************************************************************************************************************
*
OBTENTION D’INFORMATIONS SUR LA DESTINATION (GET DESTINATION INFO)
* Mémorisez le numéro de destination IP et le numéro de service dans une structure de point
* de connexion (dest).
* 1. Transformez le nom de destination en numéro IP (gethostbyname).
* 2. Mémorisez le numéro IP et le numéro de service dans la structure “dest”.
*******************************************************************************************************************/
static void GetDestinationInfo()
{
struct hostent *hp;
hp = gethostbyname (DESTINATION);
if (hp == NULL) {
print(“host error\n”);
exit(1);
}
memset ((char*)&dest, 0, sizeof dest);
memcpy (&dest.sin_addr.s_addr, hp->h_addr, hp->h_length);
dest.sin_family = AF_INET;
dest.sin_port = SERVICE;
}
/*******************************************************************************************************************
*
ÉTABLISSEMENT D’UN POINT DE CONNEXION (SETUP SOCKET)
* Établissez un point de connexion TCP/IP.
* 1. Créez le point de connexion.
* 2. Validez l’option KEEPALIVE du point de connexion.
*
Vous validez ainsi la transmission périodique automatique de messages
*
de “vérification” à envoyer sur la connexion. Si le destinataire ne répond pas,
Édition 2009
SUPPLéMENT ii-15
II-15/43
*
on considère que la communication est coupée et vous en êtes notifié *
(par SIGPIPE ou end-of-file).
* 3. Validez l’option REUSEADDR du point de connexion, ce qui vous permet de *
redémarrer plus rapidement les processus interrompus.
* 4. Réduisez la taille du tampon d’envoi du point de connexion pour diminuer la perte
*
de données au cas où la connexion échouerait.
*******************************************************************************************************************/
static void SetupSocket()
{
int
on = 1;
int
rc;
int
buffsize = MAX_MSGSIZE;
pr_sock = socket (AF_INET, SOCK_STREAM, 0);
if (pr_sock < 0) {
printf(“sock error\n”);
exit(1);
}
rc = setsockopt(pr_sock,SOL_SOCKET,SO_KEEPALIVE,(char *)&on,sizeof(on));
if (rc != 0) {
printf(“keepalive error\n”);
}
rc = setsockopt(pr_sock,SOL_SOCKET,SO_REUSEADDR,(char *)&on,sizeof(on));
if (rc != 0) {
printf(“reuse error\n”);
}
rc = setsockopt(pr_sock,SOL_SOCKET,SO_SNDBUF,(char *)&buffsize,sizeof(buffsize));
if (rc != 0) {
printf(“unable to set send buffer size\n”);
}
}
/*******************************************************************************************************************
*
ÉTABLISSEMENT D’UNE CONNEXION (MAKE CONNECTION)
* Essayez, au moyen d’un point de connexion TCP/IP, d’établir une connexion avec le
* destinataire avec le numéro de service et le numéro de port convenus.
*******************************************************************************************************************/
static void MakeConnection()
{
int
length;
length = sizeof (dest);
if ( connect (pr_sock,(struct sockaddr *)&dest,length) == -1 ) {
printf(“connection error\n”);
exit(1);
}
printf(“connected\n”);
}
/*******************************************************************************************************************
*
TRANSMISSION DE DONNÉES (SEND DATA)
* Envoyez un message en passant par le point de connexion (5 fois en fait).
*
* NOTE: Un programme réel vérifierait le code de retour d’écriture. Si l’opération * d’écriture échoue, le programme ferme le point de connexion, transmet un signal * d’alarme à l’opérateur et tente d’envoyer à nouveau le message depuis le départ.
*******************************************************************************************************************/
static void SendData()
{
char
msg[MAX_MSGSIZE+1], buffer[MAX_MSGSIZE+GTS_LENFIELD+3];
Édition 2009
II-15/44
int
buflen, i, rc = 0;
strcpy(msg,”\001\r\r\n001\r\r\nTTAA01 AMMC 000000\r\r\n”);
for (i=0;i<60;i++)
strcat(msg,”THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG 0123456789\r\r\n”);
strcat(msg,”\r\r\n\003”);
sprintf(buffer,”%0*dAN%s”,GTS_LENFIELD,strlen(msg),msg);
buflen = strlen(buffer);
for (i=0; i<5; i++) {
rc = write(pr_sock,buffer,buflen);
printf(“write. rc = %d\n”,rc);
}
}
/*******************************************************************************************************************
*
ESSAI DU PROGRAMME DE RÉCEPTION DU POINT DE CONNEXION TCP/IP
(TEST TCP/IP SOCKET RECEIVING PROGRAM)
* Ce programme est conçu pour donner une idée de la façon de recevoir des messages de type
* SMT en un point de connexion TCP/IP.
*******************************************************************************************************************/
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <signal.h>
#include <string.h>
#include <memory.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#define SERVICE 39000
#define MAX_MSGSIZE 15000
#define MAX_BUFLEN MAX_MSGSIZE + 100
#define SOH ‘\001’
#define ETX ‘\003’
8
#define GTS_LENFIELD #define GTS_SOCKET_HEADER 10
static void SetupService();
static void RecvData();
static void AcceptConnection();
static int ExtractMsg(char *buffer, int *buflen);
static int CheckMsgBoundaries (char *, int);
static int FindMessage (char *, int, int *);
static void ShiftBuffer (char *, int *, int);
static struct sockaddr_in dest;
static int
pr_sock, msgsock;
static char buffer[MAX_BUFLEN+1];
static int
buflen = 0;
/*******************************************************************************************************************
*
OPÉRATION PRINCIPALE (MAIN)
* Vérifiez l’arrivée d’appels entrants et lisez tout message entrant lors du premier appel établi.
*
* 1. Ne tenez pas compte des signaux SIGPIPE. Ceux-ci se produisent si une communication est
* interrompue. Par défaut, ils suspendent l’exécution d’un programme.
* 2. Établissez un point de connexion pour les messages entrants (SetupService).
* 3. Acceptez le premier appel reçu (AcceptConnection).
* 4. Lisez tous les messages de cette connexion (RecvData).
* 5. Coupez la communication et fermez le point de connexion.
*******************************************************************************************************************/
Édition 2009
SUPPLéMENT ii-15
II-15/45
main(int argc, char *argv[])
{
signal (SIGPIPE,SIG_IGN);
SetupService();
AcceptConnection();
RecvData();
close(msgsock);
/* shutdown(pr_sock,1) */
close(pr_sock);
}
/*******************************************************************************************************************
*
SERVICE D’ÉTABLISSEMENT (SETUP SERVICE)
* Vérifiez les appels sur un service ou un port donné.
* 1. Créez un point de connexion.
* 2. Validez l’option KEEPALIVE du point de connexion.
* Vous validez ainsi la transmission périodique automatique de messages de “vérification” à
* envoyer sur la connexion. Si le destinataire ne répond pas, on considère que la communication
* est coupée et vous en êtes notifié (par SIGPIPE ou end-of-file).
* 3. Validez l’option REUSEADDR du point de connexion, ce qui vous permet de redémarrer plus
* rapidement les processus interrompus.
* 4. Reliez le point de connexion au service ou au port voulu.
* 5. Commencez à vérifier l’arrivée d’appels.
*******************************************************************************************************************/
static void SetupService()
{
int
on = 1;
int
rc;
/* adjust the TCP receive buffer size
int
buffsize = MAX_MSGSIZE; */
memset ((char *)&dest, 0, sizeof dest);
dest.sin_addr.s_addr = INADDR_ANY;
dest.sin_family = AF_INET;
dest.sin_port = SERVICE;
pr_sock = socket (AF_INET, SOCK_STREAM, 0);
if (pr_sock < 0) {
printf(“sock error\n”);
exit(1);
}
rc = setsockopt(pr_sock,SOL_SOCKET,SO_KEEPALIVE,(char *)&on,sizeof(on));
if (rc != 0) {
printf(“keepalive error\n”);
exit(1);
}
rc = setsockopt(pr_sock,SOL_SOCKET,SO_REUSEADDR,(char *)&on,sizeof(on));
if (rc != 0) {
printf(“reuse error\n”);
exit(1);
}
/* adjust the TCP receive buffer size
rc = setsockopt(pr_sock,SOL_SOCKET,SO_RCVBUF,(char *)&buffsize,sizeof(buffsize));
if (rc != 0) {
printf(“unable to set send receive size\n”);
}
*/
rc = bind(pr_sock,(struct sockaddr *)&dest,sizeof dest);
if ( rc < 0) {
printf(“bind error\n”);
exit(1);
Édition 2009
II-15/46
}
rc = listen(pr_sock,1);
if ( rc < 0) {
printf(“listen error\n”);
exit(1);
}
printf(“listening\n”);
}
/*******************************************************************************************************************
*
ACCEPTATION D’UNE CONNEXION (ACCEPT CONNECTION)
* Attendez un appel entrant (acceptation).
* Renvoyez le point de connexion de l’appel établi.
*******************************************************************************************************************/
static void AcceptConnection()
{
int
addrlen;
printf(“waiting connection\n”);
addrlen = sizeof(sockaddr_in);
msgsock = accept (pr_sock,&dest,&addrlen);
if ( msgsock < 0) {
printf(“accept error\n”);
exit(1);
}
printf(“connected\n”);
}
/*******************************************************************************************************************
*
RÉCEPTION DE DONNÉES (RECV DATA)
* Lisez les données du point de connexion du message ou de l’appel.
* Extrayez les messages SMT de ces données.
* Continuez à lire jusqu’à ce que l’expéditeur interrompe l’appel ou qu’une erreur se produise.
*******************************************************************************************************************/
static void RecvData()
{
int
numr = 1;
int
rc = 0;
while (numr > 0 && rc >= 0) {
numr = read(msgsock,buffer+buflen, MAX_BUFLEN-buflen);
if (numr > 0) {
buflen += numr;
buffer[buflen] = ‘\0’;
printf(“buffer = %s\n”,buffer);
rc = ExtractMsg(buffer,&buflen);
}
}
}
/*******************************************************************************************************************
*
EXTRACTION DE MESSAGE (EXTRACT MSG)
* DESCRIPTION
* Cette fonction accepte un tampon de données en entrée, ainsi que la quantité * de données se trouvant dans le tampon, et extrait
* les messages SMT de ce tampon.
*
* Les messages se trouvant dans le tampon sont identifiés de la façon suivante.
*
* - Les 8 premiers octets du tampon contenant le message indiquent OBLIGATOIREMENT
* une longueur de message en format caractères.
Édition 2009
SUPPLéMENT ii-15
II-15/47
* Si la longueur du message dépasse la longueur maximale définie par le SMT ou ne consiste
* pas en des caractères numériques, un message d’erreur apparaît (perte de synchronisation).
*
* - Tout de suite après la longueur du message apparaît le type de message, en 2 caractères:
* “AN” = alphanumérique, “BI” = binaire, “FX” = fac-similé.
*
* - Le message SMT commence par un caractère SOH et se termine par un caractère ETX. Si tel * n’est pas le cas, un message d’erreur apparaît (perte de synchronisation).
*
* - Si un message SMT est identifié, il est extrait et sort du tampon.
*
* - Comme il peut y avoir plus d’un message dans le tampon, cette fonction tourne en boucle (en
* extrayant des messages) jusqu’à ce qu’une erreur ou un message incomplet soit détecté.
*
*
* RÉSULTATS: = 0 - Message non complet dans le tampon.
*
< 0 - Erreur bloquante dans le format du tampon.
*
> 0 - Succès: le ou les messages ont été extraits.
*******************************************************************************************************************/
static int ExtractMsg(char *buffer, int *buflen)
{
int rc, msglen;
char
msg[MAX_MSGSIZE+1];
/* RECHERCHEZ LE PREMIER MESSAGE DANS LE TAMPON. */
rc = FindMessage (buffer, *buflen, &msglen);
/* SI UN MESSAGE D’UNE LONGUEUR VALIDE SE TROUVE DANS LE TAMPON, */
while ( rc > 0 ) {
/* VÉRIFIEZ QUE LE PREMIER CARACTÈRE APRÈS LA LONGUEUR DU
MESSAGE EST UN CARACTÈRE ‘SOH’ ET QUE LE DERNIER CARACTÈRE INDIQUÉ PAR LA LONGUEUR DU MESSAGE EST UN CARACTÈRE ‘ETX’. */
if ( (rc = CheckMsgBoundaries (buffer, msglen)) < 0 )
continue;
/* IMPRIMEZ LE MESSAGE EXTRAIT. */
memcpy(msg,buffer+GTS_SOCKET_HEADER,msglen);
msg[msglen] = ‘\0’;
printf(“GTS MSG = \n%s\n”,msg);
/* SORTEZ LE MESSAGE JUSTE INJECTÉ DU TAMPON ET FAITES UNE BOUCLE
POUR RECHERCHER UN NOUVEAU MESSAGE. */
ShiftBuffer (buffer, buflen, msglen);
/* RECHERCHEZ LE PREMIER MESSAGE DANS LE TAMPON EN QUESTION. */
rc = FindMessage (buffer, *buflen, &msglen);
}
return (rc);
}
/*******************************************************************************************************************
*
RECHERCHE D’UN MESSAGE (FIND MESSAGE)
* Vérifiez si le message complet se trouve au début du tampon.
* 1.Vérifiez les 8 premiers caractères, qui indiquent la longueur du message.
* 2.Vérifiez les 2 caractères suivants, qui indiquent le type de message.
* 3.Vérifiez si le message complet, défini dans la zone “message length”, se trouve
* dans le tampon.
* Codes de retour:
* 0 = message incomplet.
* 1 = message complet.
* -1 = erreur.
*******************************************************************************************************************/
Édition 2009
II-15/48
static int FindMessage (char *buffer, int buflen, int *mlen)
{
char charlen[GTS_LENFIELD+1];
int intlen;
*mlen = 0;
/* SI LA LONGUEUR DU TAMPON DU MESSAGE PASSÉ N’EST PAS SUPÉRIEURE À 10 CARACTÈRES, INDIQUEZ ‘INCOMPLETE’. */
if ( buflen < GTS_SOCKET_HEADER ) {
return (0);
}
/* VÉRIFIEZ SI LE TYPE DE MESSAGE EST VALIDE. */
if (strncmp(buffer+GTS_LENFIELD,”AN”,2) && strncmp(buffer+GTS_LENFIELD,”BI”,2) && strncmp(buffer+GTS_LENFIELD,”FX”,2)) {
printf(“ERROR: Message Type field invalid”);
return (-1);
}
/* EXTRAYEZ LA LONGUEUR DU MESSAGE. */
strncpy (charlen, buffer, GTS_LENFIELD);
charlen[GTS_LENFIELD] = ‘\0’;
/* VÉRIFIEZ SI LA CHAÎNE DE CARACTÈRES DONNANT LA LONGUEUR DU MESSAGE SE COMPOSE
UNIQUEMENT DE CHIFFRES. INDIQUEZ UNE ERREUR SI TEL N’EST PAS LE CAS. */
if ( strspn (charlen, “0123456789”) != strlen (charlen) ) {
printf(“ERROR: length not numeric”);
return (-1);
}
/* TRANSFORMEZ LA CHAÎNE DE CARACTÈRES INDIQUANT LA LONGUEUR DU MESSAGE EN UN NOMBRE ENTIER. */
intlen = atoi (charlen);
/* VÉRIFIEZ SI LA LONGUEUR EXTRAITE DU TAMPON N’EST PAS SUPÉRIEURE À LA TAILLE MAXIMALE DES MESSAGES DÉFINIE PAR LE SMT. INDIQUEZ UNE ERREUR SI TEL EST LE CAS. */
if ( intlen > MAX_MSGSIZE ) {
printf(“ERROR: message overlength”);
return (-1);
}
/* VÉRIFIEZ SI LE MESSAGE A ÉTÉ ENTIÈREMENT REÇU. RETOUR DANS LE CAS CONTRAIRE. */
if ( buflen < intlen + GTS_SOCKET_HEADER ) {
return (0);
}
*mlen = intlen;
return (1);
}
/*******************************************************************************************************************
*
VÉRIFIEZ LES LIMITES DU MESSAGE (CHECK MSG BOUNDARIES)
* Confirmez que le premier caractère après l’en-tête du point de connexion
* est SOH et que le dernier caractère du message
* (donné par la longueur du message) est ETX.
*******************************************************************************************************************/
static int CheckMsgBoundaries (char *buffer, int msglen)
{
Édition 2009
II-15/49
SUPPLéMENT ii-15
/* VÉRIFIEZ SI LE PREMIER CARACTÈRE (APRÈS LA ZONE DONNANT LA LONGUEUR DU MESSAGE) EST UN CARACTÈRE SOH. INDIQUEZ UNE ERREUR SI TEL N’EST PAS LE CAS. */
if ( buffer[GTS_SOCKET_HEADER] != SOH ) {
printf (“ERROR: SOH not found\n”);
return (-1);
}
/* VÉRIFIEZ SI LE DERNIER CARACTÈRE (SELON LA ZONE DONNANT LA LONGUEUR DU MESSAGE)
EST UN CARACTÈRE ETX. INDIQUEZ UNE ERREUR SI TEL N’EST PAS LE CAS. */
if ( buffer[msglen+GTS_SOCKET_HEADER-1] != ETX ) {
printf(“ERROR: ETX not found\n”);
return (-1);
}
return (1);
}
/*******************************************************************************************************************
*
SORTIR LE PREMIER MESSAGE DU TAMPON (SHIFT BUFFER)
* Sortez du tampon le premier message s’y trouvant. Après cela,
* soit le tampon est vide, soit l’intégralité ou une partie
* d’un nouveau message se place en début du tampon.
*******************************************************************************************************************/
static void ShiftBuffer (char *buffer, int *buflen, int msglen)
{
int shiftlen;
/* CALCULEZ LA QUANTITÉ DE DONNÉES À SORTIR DU TAMPON. */
shiftlen = msglen + GTS_SOCKET_HEADER;
/* SORTEZ LES DONNÉES ‘TRAITÉES’ DU TAMPON
EN PLAÇANT LES DONNÉES NON TRAITÉES PAR-DESSUS CELLES-CI.
CALCULEZ LA NOUVELLE QUANTITÉ DE DONNÉES SE TROUVANT DANS LE TAMPON. */
*buflen = *buflen - shiftlen;
memcpy (buffer, buffer + shiftlen, *buflen);
}
AppendiCE 4
QUELQUES MESURES DE SÉCURITÉ POUR LES CENTRES DU SMT DE PETITE TAILLE
Le présent appendice donne des informations sur un éventail de mesures permettant de
sécuriser à peu de frais les centres du SMT lorsqu’ils sont raccordés à Internet. Sous sa forme traditionnelle,
le SMT, dont les systèmes de commutation de messages se transmettent des bulletins sur des circuits point
à point présente, par sa nature même, toutes les garanties de sécurité, contrairement à Internet. Il importe
par conséquent de faire en sorte que les utilisateurs d’Internet ne puissent pas passer par les liaisons du SMT
où ils pourraient causer des dommages à des centres voisins.
Politique de sécurité
Dans un environnement mixte Internet/SMT, une faille dans le système de sécurité d’un centre
du SMT peu compromettre la sécurité d’autres tronçons du Système. Comme très probablement la plupart
des centres du SMT seront tôt ou tard raccordés à Internet, il convient de régler le problème de la sécurité
d’une manière qui soit pratique pour tous les centres et en particulier pour ceux qui sont de petite taille. Les
outils dont on dispose aujourd’hui, qui vont du gratuiciel, qui ne coûte que quelques dollars, à la solution
propriétaire au coût élevé, permettent d’atteindre différents niveaux de sécurité réseau. L’aspect financier n’est cependant pas le seul qui compte. Un bon savoir-faire technique allié à
un soutien efficace à la gestion sont les conditions sine qua non d’une politique de sécurité digne de ce nom. Si ces deux conditions ne sont pas réunies, la protection sera inopérante, même avec les systèmes pare-feu
les plus performants et les plus coûteux.
Édition 2009
II-15/50
Coexistence d’Internet et de liaisons du SMT spécialisées
On peut configurer de nombreuses façons les systèmes dont sont dotés les centres de petite
taille. Dans la figure A4.1, des routeurs distincts sont utilisés pour l’accès à Internet et l’accès au SMT.
Internet
Routeur/
pare-feu
Serveurs B
Serveur
Web
SMT
Réseau
protégé
Routeur/
pare-feu
Serveur A
(SMT)
Figure A4.1 — Coexistence du SMT et d’Internet – routeurs d’accès distincts
Pour réduire les coûts, les centres du SMT peuvent choisir de regrouper les réseaux SMT et
Internet sans compromettre la sécurité de leurs systèmes SMT. La figure A4.2 montre comment on peut
atteindre cet objectif par une configuration peu onéreuse.
Internet
SMTP
DNS
Routeur
Pare-feu
Réseau
protégé
SMT
Serveur
Web
Serveur
SMT
Figure A4.2 — Coexistence du SMT et d’Internet – routeur d’accès commun
Comment protéger les liaisons du SMT du trafic Internet
Il est important que le ou les routeurs extérieurs connectés à la fois à des liaisons du SMT et
au réseau Internet soient efficacement protégés par des mots de passe et qu’on ne puisse pas non plus les
configurer via Internet. En outre, aucune trafic Internet ne devrait être autorisé à passer par les liaisons du
SMT et aucun trafic SMT ne devrait passer par le réseau Internet à moins que ce ne soit expressément prévu. Il faut pour cela filtrer soigneusement les mises à jour de tables d’acheminement.
Les services généraux offerts sur Internet (www/http et courrier électronique) et les systèmes
du SMT (de commutation de messages notamment) doivent être séparés: autrement dit, des ordinateurs
différents doivent être utilisés pour les uns et pour les autres. Il convient en outre de recourir à des techniques
pare-feu pour limiter l’accès du trafic général Internet au réseau interne du centre du SMT, au besoin en
restreignant les connexions entrantes au protocole SMTP sur le serveur de messagerie, au protocole HTTP
sur le serveur Web et au système DNS sur les serveurs de noms de domaine.
Édition 2009
II-15/51
SUPPLéMENT ii-15
Un pare-feu devrait être mis en place entre le routeur extérieur et les systèmes essentiels. Ce
pare-feu doit être conçu de manière à pouvoir limiter, assurer lui-même ou réorienter l’accès aux serveurs
internes de manière à les protéger. Il existe sur le marché plusieurs marques de pare-feu dont les capacités
varient d’un type à l’autre. Dans la plupart des cas, l’architecture de réseau des centres de petite taille est
suffisamment simple pour que ces derniers puissent se contenter d’un pare-feu élémentaire. L’installation d’un système pare-feu est quasiment obligatoire lorsqu’un centre se connecte à
Internet car cela permet de prévenir les risques que pourraient courir les données et les systèmes internes. Voici quelques solutions peu onéreuses envisageables pour assurer un contrôle des accès.
Ordinateurs Linux
Le système d’exploitation Linux est gratuit et tourne sur diverses plates-formes matérielles,
notamment sur PC. Les versions les plus récentes de Linux (dont la version 2.2 du noyau) sont fournies avec
des logiciels pare-feu appelés “ipchains”. Elles prennent en charge par ailleurs les protocoles d’acheminement
via un programme d’acheminement appelé “gated”. Les centres qui sont familiarisés avec UNIX n’auront
qu’à configurer un système Linux pour se doter du même coup d’un pare-feu efficace.
Windows NT
Il existe plusieurs versions commerciales de ce progiciel, qui est proche du Windows et permet
d’utiliser du matériel PC relativement bon marché.
Boîtes à outils gratuites
La société TIS (Trusted Information Systems) a lancé un programme en code source, essentiellement pour les serveurs UNIX/LINUX, qui est gratuit. Pour en bénéficier, il faut pouvoir accéder à des
machines et à des compilateurs UNIX/LINUX et avoir une bonne connaissance des problèmes de sécurité
liés à l’utilisation d’Internet.
Routeurs
De nombreux routeurs ont des fonctions de filtrage de paquets. L’une de ces fonctions peut
servir de pare-feu même si elle manque de souplesse. Les centres de petite taille pourraient envisager cette
solution.
Solution recommandée
Certains fournisseurs proposent des pare-feu combinés avec leur matériel. Le pare-feu IOS de
Cisco (voir la figure A4.3) en est un exemple notoire.
Pare-feu
Internet
Serveurs A expressément
autorisés
Routeur
d’accès
Serveurs B
Réseaux ouverts
SMT
Serveur
Web
Réseaux
protégés
Routeur
d’accès
Serveurs A
(SMT)
Serveurs A autorisés
Serveurs B bloqués
Figure A4.3 — Coexistence du SMT et d’Internet – routeurs d’accès distincts et pare-feu
Édition 2009
II-15/52
Utilisation d’Internet par les centres du SMT
Dans certaines circonstances, les centres du SMT sont amenés à utiliser Internet pour acheminer
données et produits, auquel cas ils doivent se préoccuper de la sécurité. La figure A4.4 ci-dessous montre
comment on peut, simplement et sans risque, utiliser Internet pour connecter des centres voisins du SMT. Cette formule pourrait à l’avenir remporter un certain succès auprès des centres de petite taille. La protection
“pare-feu” est assurée par la gestion des listes d’accès.
Accès 'ouvert'
Routeur
d’accès
Internet
Serveurs B
Centre voisin
Seul serveur SMT
du centre voisin
autorisé
Serveur
Web
Serveurs A
(SMT)
Figure A4.4 — Utilisation d’Internet entre centres voisins du SMT
Réseaux privés virtuels: des connexions SMT sécurisées sur Internet
Un réseau privé virtuel (VPN) est un réseau privé établi entre des organisations qui souhaitent
communiquer sur un réseau accessible au public. Le trafic d’un tel réseau peut passer par Internet à
l’aide d’un protocole venant s’ajouter aux protocoles TCP/IP standard. Les VPN sécurisés font appel à
des protocoles cryptographiques de tunnelisation pour authentifier l’expéditeur et garantir l’intégrité et
la confidentialité des messages, ce qui est considéré comme correct pour la transmission et l’échange de
données météorologiques entre centres.
Le protocole le plus courant pour les VPN sécurisés est le protocole IPSec. Celui-ci est conçu pour
assurer la sécurité cryptographique des connexions IP fondée sur la compatibilité et une qualité élevée. Les
fonctions de sécurité offertes comprennent le contrôle d’accès, l’intégrité sans connexion, l’authentification
de l’origine des données, la protection contre les répétitions et la confidentialité.
Le protocole IPSec assure la sécurité de bout en bout: toute la fonctionnalité et l’intelligence
d’une connexion VPN réside dans ses extrémités, soit dans une passerelle, soit dans le système hôte
d’extrémité. Il est possible, grâce à ce protocole, de créer un tunnel entre deux passerelles. Une passerelle
IPSec se compose en général d’un routeur d’accès, d’un pare-feu ou d’une passerelle VPN auquel s’applique
le protocole IPSec. La passerelle IPSec se trouve entre le réseau privé de l’usager et le réseau partagé de
l’entreprise de télécommunications.
Les tunnels IPSec sont créés dynamiquement et supprimés automatiquement lorsqu’ils ne sont
pas utilisés. Pour qu’un tunnel IPSec soit créé, il faut que deux passerelles s’authentifient et définissent les
algorithmes de sécurité et les clefs qu’elles utiliseront pour le tunnel. Le paquet IP initial est chiffré dans
son intégralité et “enveloppé” entre des en-têtes d’authentification et de chiffrement IPSec. La figure A4.5
indique comment réaliser une connexion VPN en utilisant le protocole IPSec entre deux centres du SMT.
La passerelle VPN est reliée à un pare-feu et à un routeur. Elle peut créer un tunnel VPN avec
d’autres passerelles VPN via l’interface du routeur. Le trafic pénétrant dans le réseau interne passe par le
pare-feu; il est contrôlé par une liste d’accès définie par l’utilisateur.
IPSec fait appel à l’en-tête d’authentification (Authentication Header (AH)) et à la charge de
sécurité d’encapsulation (Encapsulation Security Payload (ESP)) pour garantir l’intégrité et la confidentialité
des données.
Les algorithmes de chiffrement le plus couramment utilisés dans ESP sont le 3DES ou Triple
DES (Triple Data Encryption Standard) et l’AES (Advanced Encryption Standard). Leurs clefs de chiffrement vont
de 128 à 256 bits, ce qui donne une protection suffisante pour le trafic sur le réseau.
Édition 2009
II-15/53
SUPPLéMENT ii-15
Passerelle VPN
Passerelle VPN
Système hôte
du SMT
Tunnel VPN
Internet
DMZ
Routeur
Pare-feu
Intranet
Pare-feu
Figure A4.5 — Utilisation d’un réseau privé virtuel sur Internet pour relier deux centres du SMT
On obtiendra de plus amples détails concernant la mise en place de réseaux privés virtuels
dans le Guide on Virtual Private Network (VPN) via the Internet between GTS centres, qu’on peut trouver sur le
site Web de l’OMM à l’adresse http://www.wmo.int/pages/prog/www/manuals.html.
AppendiCE 5
DOCUMENTS DE RÉFÉRENCE
Documents généraux de référence sur les protocoles TCP/IP
1.
2.
3.
4.
5.
6.
7.
8.
9.
Internetworking TCP/IP Vol. 1 (2/E), Douglas Comer, Prentice Hall
TCP/IP Illustrated Vol. 1, Stevens, Addison-Wesley
TCP/IP Architecture, Protocols and Implementation, Feit, McGraw Hill
TCP/IP and Related Protocols, Black, McGraw Hill
TCP/IP Running a Successful Network, Washburn et Evans, Addison-Wesley
TCP/IP and ONC/NFS (2/E), Santifaller, Addison-Wesley
Inside TCP/IP, Arnett et al., New Riders Publishing
Teach Yourself TCP/IP in 14 days, Parker, SAMS
Introduction to TCP/IP, Davidson, Springer
Documents de référence sur la sécurité
1. 2.
3.
4.
5.
Firewalls and Internet Security, Cheswick et Bellovin, Addison-Wesley
Building Internet Firewall, Chapman, O’Reily
Practical Unix Security, Garfinkel et Spafford, O’Reilly
Internet RFC2196 (Site Security Handbook)
http://www.computersecuritynow.com: site Web offrant quantité de documents de référence sur les
systèmes de sécurité.
AppendiCE 6
PRATIQUES PROPOSÉES POUR LA GESTION DES MOTS DE PASSE
Les mots de passe constituent la première ligne de défense d’un système contre une intrusion
non autorisée. Bien qu’il soit possible de violer la sécurité d’un système sans entrer en communication
avec celui-ci, un mot de passe mal protégé ou mal choisi peut grandement faciliter la tâche à un pirate
informatique.
Édition 2009
II-15/54
Bons mots de passe
1.
2.
3.
4.
5.
6.
7.
8.
9.
Choisissez des lettres majuscules et minuscules, et/ou
Choisissez des chiffres et/ou des caractères non alphanumériques.
Les mots de passe ont une longueur de 6 à 8 caractères.
Ils devraient comprendre au moins 2 mots ou groupes de caractères.
Ils ne devraient pas être partagés ou employés par plus d’un utilisateur.
Ils ne devraient pas être utilisés sur plus d’un ordinateur.
Ils devraient être changés régulièrement, par exemple tous les mois.
Ils doivent être faciles et rapides à taper, afin qu’un observateur ne puisse pas suivre la frappe.
Ils doivent être faciles à mémoriser pour qu’on n’ait pas besoin de les écrire (choisissez par exemple la
première lettre de chacun des mots qui composent une expression courante).
Mauvais mots de passe
1. Votre propre nom, celui de votre conjoint, de vos enfants, de vos parents, de votre animal de compagnie, de vos amis, de vos stars de cinéma préférées, de n’importe quelle personne associée avec vous, de
votre poste de travail ou de son serveur.
2. Votre numéro de téléphone, votre numéro de plaque minéralogique, votre indicatif d’utilisateur, une
partie de vos numéros de cartes de crédit, ou tout numéro ayant rapport avec vous.
3. Votre date de naissance ou celle de quiconque a des rapports avec vous.
4. Tout mot figurant dans un dictionnaire, tout nom d’endroit, tout nom propre.
5. Le nom de toute personne connue: sportif, artiste ou héros de fiction connu.
6. Une structure simple: aaaaaaa, azerty.
7. L’une des rubriques 1 à 6 écrite à l’envers.
8. L’une des rubriques 1 à 6 précédée ou suivie d’un chiffre.
9. Tout mot de passe qui a été écrit et laissé dans un tiroir ne fermant pas à clef ou dans un fichier informatique non protégé.
10.Tout mot de passe utilisé sur un ordinateur qui a pu être piraté (sauf dans le cadre d’exercices autorisés).
11.Tout mot de passe se trouvant dans un ordinateur qui est resté sans surveillance lorsqu’un utilisateur
quelconque était en session.
AppendiCE 7
Adresses IP à utiliser sur le SMT
Introduction
Les actuelles “Pratiques et procédures recommandées pour la mise en œuvre, l’utilisation et
l’application du Transmission Control Protocol/Internet Protocol (TCP/IP) sur le SMT”, que l’on désigne aussi
sous le nom de Guide sur l’utilisation des protocoles TCP/IP sur le SMT, figurant dans le présent supplément,
présentent des directives et une procédure périmées pour l’affectation d’adresses IP à des liaisons du
SMT. Elles indiquent en particulier que le Secrétariat de l’OMM peut affecter des adresses IP officielles de
classe C aux liaisons en question. Ces adresses, qui ne sont plus disponibles officiellement en raison de
l’application stricte des normes Internet (RFC) par les autorités et les prestataires de services Internet, ne
sont malheureusement plus utilisables sur le SMT du fait qu’elles peuvent désormais être affectées à d’autres
organisations qui utilisent Internet. C’est pourquoi le Secrétariat de l’OMM a été avisé de ne plus affecter de
telles adresses.
L’Équipe d’experts sur les techniques et la structure de communication a été chargée de trouver
des solutions à ce problème.
Le présent document fait une description provisoire des options disponibles et des indications connexes qui permettent d’atténuer le problème et d’aider les Membres à mettre en œuvre les
options en question. Les directives incluses ne concernent que l’adressage IP. Elles ne modifient en rien les
recommandations existantes relatives aux liens d’IP avec X.25 ou d’autres fonctionnalités d’IP.
L’Équipe d’experts va rédiger les amendements qu’il est proposé d’apporter au présent supplé-
ment afin de tenir compte des nouvelles pratiques recommandées pour l’affectation d’adresses IP.
Édition 2009
SUPPLéMENT ii-15
II-15/55
Qui peut fournir des adresses IP officielles?
Pour édifier un réseau relié à de nombreuses organisations dans divers pays du monde,
il est essentiel d’établir une norme pour le système d’adressage et d’affecter des adresses uniques à ces
organisations. Les administrateurs d’Internet ont défini le principe de base et créé des organes officiels
chargés de coordonner l’affectation d’adresses IP officielles. Actuellement, cette responsabilité incombe
à l’Organisme responsable des inscriptions à Internet (Internet Assigned Numbers Authority (IANA)) et à ses
délégués régionaux, les registres Internet régionaux (Regional Internet Registries (RIR)) compétents:
AfriNIC (African Network Information Centre) – Région de l’Afrique
APNIC (Asia Pacific Network Information Centre) – Région Asie-Pacifique
ARIN (American Registry for Internet Numbers) – Amériques et Afrique australe
LACNIC (Latin-American and Caribbean Internet Addresses Registry) – Amérique latine et certaines îles
des Caraïbes
RIPE NCC (Réseaux IP européens – Network Coordination Centre) – Europe et zones avoisinantes
Ces organisations délèguent elles-mêmes l’affectation d’adresses à leurs fournisseurs régionaux
d’accès et aux entreprises de télécommunications par le biais de leurs registres Internet nationaux.
Dans ce système, ce n’est pas à l’OMM d’affecter des adresses IP. Le SMT n’étant pas conçu
comme un réseau unique relevant exclusivement d’une seule organisation, c’est le registre Internet national
ou régional compétent qui s’occupe de l’affectation des adresses.
Cependant, divers pays doivent faire face, désormais, au problème de la restriction de
l’affectation d’adresses IP version 4 (IPv4) et risquent d’avoir du mal à obtenir des adresses officielles. Le
problème n’est pas facile à résoudre à court terme et des mesures provisoires vont peut-être devoir être prises
pour permettre le développement du SMT. Les directives ci-après indiquent comment relier des réseaux
entre eux en utilisant ou non des adresses IP officielles.
Interconnexion de réseaux disposant d’adresses IP officielles
Utilisation d’adresses IP officielles affectées directement à une organisation (par exemple un SMN)
Cette solution reste la meilleure si elle est réalisable. Il s’agit en gros de la procédure principale
expliquée dans l’actuel Guide sur l’utilisation des protocoles TCP/IP sur le SMT. Celle-ci suit toutes les règles
d’Internet et permet à une organisation de constituer un réseau cohérent disposant de connexions avec
Internet, le SMT et, éventuellement, d’autres organisations partenaires. C’est aussi la configuration la plus
facile à entretenir.
Pour relier deux pays en créant une liaison sur le SMT, les deux Services météorologiques
nationaux doivent décider de celui qui va fournir l’adresse de la liaison. La décision est d’ordre strictement
pratique. Il n’existe pas de règle générale en faveur d’un ensemble d’adresses par rapport à un autre.
Utilisation d’adresses IP officielles fournies par une entreprise de télécommunications
Cette solution est très semblable à la précédente. Les adresses fournies sont officielles et toutes
les règles s’appliquent.
Il se peut que les deux organisations qui souhaitent se relier entre elles doivent faire appel à la
même entreprise de télécommunications.
Toutefois, cette solution a un inconvénient: si l’on change d’entreprise de télécommuni-
cations, il faudra peut-être changer aussi d’adresses IP, le titulaire d’origine risquant de récupérer “ses”
adresses. Chaque organisation doit prévoir cette possibilité et en évaluer les incidences sur ses activités à
venir. Si les adresses ne sont utilisées que pour des liaisons et non pour les activités internes d’une organisation, ces inconvénients peuvent être minimes.
Utilisation d’adresses IP version 6 (IPv6)
Le nouveau protocole IP version 6 (IPv6) a été conçu en grande partie pour pallier le manque
d’adresses IPv4. Bien que ce protocole soit disponible et pris en charge par de nombreux matériels de télécommunications du marché, sa mise en œuvre demande une planification soigneuse. En particulier, les protocoles
IPv4 et IPv6 ne sont pas compatibles sans l’usage de passerelles et, pour l’instant, il manque plusieurs outils
opérationnels pour qu’IPv6 puisse être utilisé pour le SMT. Le passage à ce protocole est une tâche majeure
qu’on ne peut pas imposer à nos Membres avant que l’industrie ne soit prête à l’assumer globalement.
Édition 2009
II-15/56
Cette option n’est donc pas disponible actuellement. Nous ne la mentionnons ici que pour
présenter un tableau complet. Nous la réétudierons au cours des années à venir.
Interconnexion de réseaux sans adresses IP officielles
Utilisation de la fonction “ip unnumbered”
Plusieurs fournisseurs de matériel de réseau (Cisco, 3Com, Juniper) ont introduit dans
leurs configurations une fonction qui permet d’établir des liaisons sans qu’il soit nécessaire d’obtenir
d’adresses IP. On appelle généralement cette fonction “ip unnumbered” (IP non numéroté). Cisco,
par exemple, a publié un document intitulé Understanding and Configuring the ip unnumbered Command
(voir http://www.cisco.com/warp/public/701/20.html).
Cette fonction n’étant pas une fonction standard du protocole IP, il faut un matériel compatible
aux deux extrémités de la liaison pour la mettre en œuvre (situation la plus fréquente de toute façon).
On peut procéder au routage entre deux réseaux en reliant l’interface non numérotée à une
autre interface existante du routeur (soit avec un réseau local réel soit avec une interface de bouclage virtuel).
L’emploi de cette fonction risque de limiter la souplesse du routage.
Utilisation de RFC1918
Le document RFC1918 – Addresses for private internets du groupe IETF (Internet Engineering Task
Force) présente une série d’adresses réservées à l’usage d’organisations exlusivement pour les communications
à l’intérieur des entreprises, sans connexion directe avec d’autres entreprises ou avec Internet.
L’utilisation de ces adresses n’exige donc pas d’enregistrement officiel. Le mécanisme a pour
principale fonction d’offrir à une grande organisation un espace adresse plus vaste pour ses opérations internes.
Dès que l’organisation a besoin d’échanger avec d’autres, une passerelle doit être traversée pour entrer dans
une zone d’adresses officiellement affectées afin de préserver la cohérence globale du réseau. Cette passerelle
doit traduire les adresses internes RFC1918 en adresses IP extérieures officielles, qu’on obtient par le biais des
organes officiels. La fonction généralement exécutée par un routeur ou par un pare-feu qui procède à cette
traduction a pour nom traduction d’adresses réseau (Network Address Translation (NAT)). Elle a aussi pour effet
de concentrer plusieurs adresses internes RFC1918 en un très petit nombre d’adresses officielles, ce qui permet
de protéger l’espace adresse officiel.
Bien que ce mécanisme puisse sembler intéressant de prime abord dans le cas qui nous occupe,
le SMT n’est pas le réseau d’une seule entreprise. Actuellement, tout SMHN d’un pays Membre de l’OMM ou
toute organisation apparentée peut faire appel à RFC1918 pour ses propres réseaux, ce qui risque d’entraîner
une affectation conflictuelle d’adresses si les réseaux sont reliés entre eux. Une recommandation de l’OMM
concernant l’utilisation de RFC1918 est presque impossible à formuler, car les SMHN peuvent déjà devoir
respecter des directives de leur propre gouvernement, d’où un risque de conflit avec une directive de
l’Organisation. Toutefois, des pays reliés entre eux pourront trouver un espace adresse adéquat avec RFC1918
dans le cadre d’un accord bilatéral.
Cette solution est donc réalisable tant que les points suivants sont soigneusement envisagés,
prévus, respectés et suivis.
1. Il faut choisir soigneusement une série convenable d’adresses RFC1918 pour les liaisons entre organisations. Il est important que les adresses sélectionnées ne soient déjà utilisées par aucune des organisations
concernées.
2. Il faut veiller soigneusement à ce que les configurations de routage interdisent aux adresses RFC1918 de
passer sur le réseau d’une autre organisation ou, pire, sur Internet.
3. Bien que cette solution puisse être satisfaisante entre quelques pays, elle ne peut pas être élargie à un grand
nombre de pays reliés directement entre eux, car le choix des adresses RFC1918 deviendrait alors de plus
en plus compliqué.
4. L’IANA a réservé les blocs suivants de RFC1918:
10.0.0.0 - 10.255.255.255 (préfixe 10/8)
172.16.0.0 - 172.31.255.255 (préfixe 172.16/12)
192.168.0.0 - 192.168.255.255 (préfixe 192.168/16)
Comme de nombreuses organisations utilisent déjà le bloc 10.0.0.0/8 de façon interne et que le bloc
192.168.0.0/16 sert souvent d’adresse par défaut à plusieurs équipementiers, il est recommandé, pour
les liaisons du SMT, de faire exclusivement appel au bloc 172.16.0.0/12 si possible.
Édition 2009
II-15/57
SUPPLéMENT ii-15
5. Il est aussi recommandé de diviser le bloc 172.16.0.0/12 en blocs de sous-réseaux de façon à optimiser
l’espace adresse. Pour cela, on peut établir les liaisons du SMT en sous-réseaux d’adresse /30 bits en
préfixe, ce qui permet d’affecter quatre systèmes hôtes à chaque liaison (en laissant libres les adresses 1
et 2 pour désigner les deux extrémités d’une liaison donnée).
6. Les SMHN qui envisagent d’utiliser des adresses RFC1918 devraient consulter tous les autres SMHN
avec lesquels ils sont susceptibles d’établir une liaison pour coordonner et planifier à l’avance l’utilisation des sous-réseaux. En cas de conflits d’adresses, d’autres plans d’affectation d’adresses peuvent
être utilisés par accord bilatéral dans le cadre de RFC1918. L’Équipe d’experts sur les techniques et la
structure de communication souhaite être informée de tels problèmes s’ils apparaissent afin d’affiner
cette recommandation.
L’utilisation d’adresses RFC1918 ne devrait pas poser de problèmes de sécurité si les points cidessus sont bien respectés.
Recommandation
suivant:
Toutes les options indiquées ci-dessus peuvent être utilisées sur le SMT, dans l’ordre de préférence
1. Emploi d’adresses IP officielles affectées directement à une organisation, par exemple un SMHN (solution privilégiée);
2. Emploi d’adresses IP officielles fournies par une entreprise de télécommunications;
3. Emploi de la fonction “ip unnumbered”;
4. Emploi de RFC1918.
L’emploi du protocole IPv6 sur le SMT n’est pas recommandé pour l’instant.
Il est clair que toutes les options qui n’exigent pas d’adresses IP officielles ne sont qu’un moyen
de contourner le problème du manque d’adresses et qu’il ne faut y recourir qu’avec prudence.
Exemples de configurations
Option 1 – Utilisation d’adresses IP officielles détenues par l’organisation (SMHN) ou Option 2 – Utilisation d’adresses IP officielles fournies par une entreprise de télécommunications
Voici la façon habituelle de configurer une interface entre deux réseaux.
Router A:
!
interface Ethernet0
ip address 131.238.17.11 255.255.255.0
!
interface Serial0
description 64Kbps leased line to router B
ip address 131.238.18.01 255.255.255.252
encapsulation ppp
bandwidth 64
!
ip route 142.47.43.0 255.255.255.0 131.238.18.2
!
Router B:
!
interface Ethernet0
ip address 142.47.43.201 255.255.255.0
!
interface Serial0
description 64Kbps leased line to router A
ip address 131.238.18.02 255.255.255.252
encapsulation ppp
bandwidth 64
!
ip route 131.238.17.0 255.255.255.0 131.238.18.1
Édition 2009
SUPPLéMENT II-16
Méthodes de transmission et de collecte des bulletins météorologiques sur l’Internet
A.
Utilisation du courrier électronique (courriel)
Généralités
Le courrier électronique (courriel) peut constituer un moyen très simple et très économique d’échanger
des bulletins météorologiques, en particulier pour la collecte de bulletins de données météorologiques. Il
convient toutefois de noter qu’il ne s’agit pas d’un service de bout en bout et que la livraison des messages
en temps voulu n’est pas garantie. De plus, le courrier électronique n’offre, par nature, aucune garantie de
sécurité.
Les directives qui suivent décrivent les méthodes utilisées pour envoyer des bulletins de collecte de données
et des bulletins météorologiques binaires par courrier électronique en réduisant au minimum les risques en
matière de sécurité.
Les centres qui appliqueraient cette procédure devraient s’assurer que les bulletins météorologiques à ingérer
dans le SMT respectent les procédures et les formes de présentation standard propres à ce système.
Forme de présentation des messages pour l’envoi de bulletins météorologiques par courrier
électronique sur l’Internet
1. Les courriels doivent être libellés uniquement en caractères de l’Alphabet international n° 5. Il est
recommandé que le bulletin météorologique figure dans le corps principal du courriel. Il peut aussi
figurer dans un fichier joint.
Note: Dans tout courriel, les fichiers joints sont séparés du corps principal du message, et leur affichage ou leur
stockage est généralement subordonné à une action ultérieure de l’utilisateur.
2. Il est recommandé de ne faire figurer qu’un seul bulletin dans chaque courriel envoyé. Toutefois, les
centres récepteurs peuvent convenir d’accepter plusieurs bulletins (la limite étant fixée à cinq bulletins)
par courriel.
3. Le ou les bulletins météorologiques peuvent être envoyés soit sous forme de texte dans le corps principal du courriel, soit sous forme de fichiers joints, mais pas sous ces deux formes à la fois. Les données
binaires ne peuvent être envoyées que sous forme de fichiers joints.
4. Pour le corps principal d’un courriel, il convient d’adopter le format suivant:
<Bulletin météorologique>
NNNN
où,
<Bulletin météorologique> correspond à un bulletin météorologique standard commençant par un
en-tête abrégé de type:
TTAAii CCCC YYGGgg [BBB]
texte du message
Une séquence de fin NNNN doit être placée après chaque bulletin météorologique.
Il ne faut faire figurer aucune autre information dans le corps principal du courriel à moins d’un accord
avec le centre récepteur. Ainsi, aucun texte d’information concernant le renvoi automatique ou la
réponse ne devrait figurer dans le corps du message.
Note: Le centre récepteur validera l’en-tête abrégé avant de traiter le bulletin météorologique.
5. La taille totale de tous les fichiers joints ne doit pas dépasser 2 méga-octets ou la valeur convenue par
accord bilatéral. Les fichiers joints doivent être codés en Base64 (norme MIME).
6. Dans le champ “Objet:” du courriel peut figurer:
a) L’en-tête abrégé si le courriel ne contient qu’un seul bulletin météorologique; ou b) Une <séquence de sécurité> prédéfinie.
édition 2009
II-16/2
Considérations sur la sécurité 1. Le courrier électronique n’offre, par nature, aucune garantie de sécurité. Pour réduire au minimum
les problèmes de sécurité, tous les envois de courriels devraient être préalablement autorisés au point
de réception sur la base d’une liste d’adresses électroniques considérées comme valables. Le centre
récepteur ne devrait traiter que les courriels liés au SMT envoyés à partir d’une adresse électronique
figurant dans une liste prédéfinie et devrait donc valider l’en-tête figurant dans le champ “De:”. Pour
éviter d’éventuels problèmes avec des courriels dont le champ “De:” aurait pu être manipulé, les
centres peuvent convenir de l’insertion de <séquences de sécurité> dans les messages. Si l’on convient
d’une telle insertion et que le ou les messages SMT soient transmis sous la forme de fichiers joints, la
<séquence de sécurité> ne peut figurer que dans le corps principal des courriels. Le centre récepteur doit
alors valider le champ “Objet:” de l’en-tête abrégé ou la séquence prédéfinie.
2. Les centres récepteurs ne doivent procéder à aucun envoi automatique d’accusés de réception ou de
réponses.
3. Il est recommandé d’utiliser, pour le transfert de données SMT, des comptes courrier spécifiques affectés
de noms qui auront été convenus à l’échelle bilatérale et de ne pas recevoir de données SMT dans les
boîtes à lettres personnelles.
4. Il se trouve cependant que certaines applications de messagerie fonctionnent par défaut comme un
“relais ouvert”. On parle de relais ouvert si, par exemple, le site A.com accepte de relayer du courrier
expédié par B.net et destiné à C.org. Cela veut dire que des polluposteurs peuvent utiliser le système
de messagerie A.com pour distribuer leurs courriels. Les centres doivent donc s’assurer qu’ils ne servent
pas de relais ouverts.
Exemple
De: NMCAAAAA <[email protected]> à: RTHcollector <[email protected]>
Objet: SMFW01 NWBB 270000
}
Information figurant dans l’en-tête du courriel
SMFW01 NWBB 270000
AAXX 27004
91753 32481 51008 10331 20259 40078 58017 83202
333 20263 59018 83816 84078=
91754 01581 51812 10287 20245 40092 58017 60034 70182 85200 333 20256 59016 60017 85820=
NNNN
B.
}
Texte figurant dans le
corps principal du courriel ou
dans le fichier joint
Utilisation de la méthode d’ingestion de données Web
Généralités
Cette méthode peut être utilisée par un CMN comme un simple moyen de collecte de données. Elle peut
aussi être utilisée par un CRT ou un CMN pour ingérer des bulletins météorologiques en cas de défaillance
d’un moyen d’accès habituel. Cette méthode est censée offrir davantage de sécurité, de ponctualité et de
fiabilité que l’ingestion de courriels.
Conditions préalables
Tout fournisseur de données ayant l’intention d’envoyer des données à un CRT ou à un CMN qui propose le
service d’ingestion sur le Web doit en premier lieu établir un compte avec ce centre. Un dispositif d’identification (consistant par exemple en la combinaison d’un identificateur d’utilisateur et d’un mot de passe) doit
être établi à des fins de sécurité. Dans la plupart des cas, l’adresse IP de l’expéditeur ne peut être validée en
raison de la traduction habituelle des adresses et de la nature des éventuels scénarios de rechange.
Entrée de données
L’utilisateur doit saisir les données correspondant à tous les champs obligatoires de l’en-tête abrégé ainsi
que celles correspondant au corps du message. S’agissant des champs obligatoires, des listes déroulantes
peuvent être fournies afin de réduire les possibilités d’erreur. Le corps du message doit être conforme aux
normes de l’OMM.
Édition 2009
SUPPLéMENT ii-16
II-16/3
Validation
L’interface d’entrée pour les bulletins Web devrait fournir un espace de saisie pour un seul en-tête abrégé de
type SMT. Elle devrait confirmer que:
a)
b)
c)
d)
e)
Tous les champs obligatoires ont été remplis et qu’y figurent des informations valables;
Tous les champs facultatifs contiennent des informations valables ou n’ont pas été remplis;
Le champ CCCC est valable pour l’utilisateur authentifié du centre expéditeur;
Un seul bulletin est créé par entrée de page Web;
L’en-tête abrégé obtenu est conforme à toutes les normes pertinentes de l’OMM (code alphabétique,
séquences de fin, etc.).
Vérification du contenu
Avant que le message dûment formulé soit ingéré, l’interface d’entrée pour les bulletins Web devrait afficher
le message entier à l’intention de l’utilisateur et demander à ce dernier de confirmer que le message est
correct. Le créateur du message devrait avoir la possibilité de le modifier avant présentation.
Sécurité
Afin de renforcer la sécurité, il est recommandé d’utiliser le protocole HTTPS.
Exemples de pages d’entrée de bulletins sur le Web:
CRT de Washington avec URL: http://www.nws.noaa.gov/tg/bullguid.html
____________________
Édition 2009
PARTIE III
CARACTéRISTIQUES ET SPéCIFICATIONS
TECHNIQUES DU SYSTèME MONDIAL DE
TéLéCOMMUNICATIONS
partIE III
Caractéristiques et spécifications techniques
du systÈme mondial de télécommunications
1.
caractéristiques du réseau principal de télécommunications
1.1
Le réseau principal de télécommunications (RPT) est un ensemble fermé dont les mailles
sont formées par les circuits et les centres. Il fonctionne vingt-quatre heures sur vingt-quatre.
1.2
Les centres météorologiques mondiaux (CMM) et les centres régionaux de télécommunications (CRT) désignés sont les centres/centres nodaux du réseau principal de télécommunications.
1.3
Les circuits du réseau principal de télécommunications sont mis en œuvre en utilisant
des services et des installations efficaces de télécommunications, y compris des lignes spécialisées
spéciales numériques ou analogiques, des services de relayage de trames et des services intégrés de
réseau de communication de données, fondés sur les recommandations appropriées UIT-T.
1.4
Les lignes spécialisées spéciales analogiques (c’est-à-dire les circuits de type téléphonique)
sont exploitées avec des modems conformément aux recommandations UIT-T pertinentes. Il est
recommandé d’utiliser des modems conformes à la recommandation UIT-T V.34.
1.5
Aux termes d’accords entre centres/centres nodaux, il est possible d’établir, dans les deux sens
d’un circuit en duplex intégral, des voies supplémentaires à faible vitesse, notamment une voie de retour
pour le contrôle des erreurs.
1.6
Lorsqu’un circuit du réseau principal de télécommunications ne peut être réalisé que
sous forme d’un circuit radio HF, celui-ci comporte des voies distinctes d’une largeur de 3 kHz pour la
transmission des données et la transmission par fac-similé.
1.7
Les circuits radio HF comprennent au moins deux voies de 3 kHz. Si nécessaire et
techniquement réalisable, on peut utiliser jusqu’à quatre voies de 3 kHz sur les circuits radioélectriques HF,
conformément aux recommandations UIT-R.
1.8
Le nombre de voies de 3 kHz nécessaires, sur un circuit radioélectrique, pour transmettre
les informations météorologiques dans les délais requis et aux heures appropriées en vue de répondre
aux besoins spécifiés par l’OMM est fixé par accord bilatéral entre les centres intéressés.
2.
APPLICATIONS TECHNIQUES DES CMM ET DES CRT SUR LE RÉSEAU PRINCIPAL DE
Les CMM et les CRT du réseau principal de télécommunications sont en mesure de
fonctionner en tant que nœud sur le RPT et d’assurer les fonctions nécessaires de nœud de transit sur
le réseau régional approprié de télécommunications météorologiques.
3.
Réseaux régionaux
Les réseaux régionaux établis par les conseils régionaux sont compatibles avec les
caractéristiques du réseau principal de télécommunications (en ce qui concerne leur réalisation
technique, les circuits et les transmissions). Cette compatibilité est indispensable, en particulier pour
assurer l’efficacité de l’écoulement du trafic sur le SMT.
4.
Réseaux nationaux
Les réseaux nationaux devraient être établis de manière à assurer l’acheminement efficace du
trafic sur le SMT dans les délais prescrits.
5.
Caractéristiques techniques de l’équipement pour les transmissions météorologiques par fac-similé analogique
5.1
Caractéristiques de l’équipement
Les caractéristiques techniques indiquées ci-après sont appliquées aux équipements utilisés
pour les transmissions météorologiques par fac-similé analogique destinées à l’échange international
de renseignements sous forme d’images.
édition 2009
III-2
CARACTéRISTIQUES ET SPéCIFICATIONS TECHNIQUES du smt
5.1.1
Direction d’exploration
Si l’on regarde le document dans un plan vertical, la direction d’exploration-ligne est
orientée de gauche à droite, l’exploitation débutant dans le coin gauche supérieur et finissant dans
le coin droit inférieur de l’image. Chaque exploration est adjacente à la précédente et en dessous de
celle-ci.
5.1.2
Module de coopération
Le module de coopération (M) est défini par la formule:
M =
LF
≠
dans laquelle L est la longueur de la ligne d’exploration, F est la densité d’exploration (ou
le nombre de lignes par unité de longueur).
Note: Le produit LF est appelé “facteur de coopération”. La spécification du module de coopération est
indispensable pour assurer une compatibilité entre l’émetteur et le récepteur. Ceux-ci peuvent avoir
des lignes d’exploration de longueur différente mais, si l’index est le même, le document sera reçu sans
distorsion.
Le module de coopération normalisé est de 576 ou 288.
5.1.3
Dimension de l’équipement
Il serait souhaitable que les appareils puissent accepter pour le moins des documents de 420 x
594 mm, en référence au format A2 de l’ISO.
5.1.3.1
Appareils à exploration à plat
La largeur totale de la ligne d’exploration (secteur actif plus secteur mort) est normalement
de 477,5 mm.
5.1.3.2
Appareils à exploration sur tambour
Le diamètre nominal du tambour est de 152 mm. La longueur utile du tambour devrait être
d’au moins 660 mm.
5.1.3.3
Secteur mort
Le secteur mort — partie de la ligne d’exploration qui ne peut être utilisée pour la
transmission d’un signal image — est de 4,5 % ± 0,5 % de la longueur de la ligne d’exploration.
Le signal transmis durant le passage du secteur mort devrait correspondre au “blanc”, mais il
est permis de transmettre une impulsion “noir” dans des limites qui ne doivent pas dépasser la moitié de la
durée d’exploration du secteur mort.
5.1.4
Finesse d’exploration
La finesse d’exploration-ligne se déduit de la définition du module de coopération; sa
valeur nominale est de:
3,8 lignes par mm (module 576), et
1,9 ligne par mm (module 288).
5.1.5
Fréquence d’exploration
La fréquence d’exploration-ligne ou la vitesse de rotation du tambour est de:
60 lignes par minute (60 tr/min),
exprimée respectivement en lignes par minute ou en tours par minute. La vitesse
d’exploration est maintenue dans les limites de ± 5.10-6 de sa valeur nominale.
édition 2009
III-3
Note: Cette tolérance permet une distorsion oblique maximale d’approximativement 1/55 lorsque les postes
émetteur et récepteur fonctionnent avec la déviation maximale autorisée dans les deux sens. Une tolérance
plus faible qui réduirait la distorsion oblique maximale est souhaitable.
5.2
Signaux de télécommande
5.2.1
Mise en marche du récepteur
L’appareil récepteur est conçu de façon que l’opération de démarrage commence dès
réception soit du signal de sélection du module de coopération (voir section 5.2.2 ci-dessous), soit du
signal de mise en phase (voir section 5.2.3 ci-dessous). Aucun autre signal de mise en marche n’est
transmis.
5.2.2
Sélection du module de coopération
5.2.2.1
Le module de coopération est déterminé en transmettant alternativement, durant cinq à
dix secondes, des signaux “blanc” et des signaux “noir” sur les fréquences suivantes:
300 Hz pour le module de coopération 576;
675 Hz pour le module de coopération 288 (ou pour le module de coopération 576, avec
exploration d’une ligne sur deux).
5.2.2.2
L’enveloppe des signaux transmis est approximativement rectangulaire.
5.2.3
Mise en phase et sélection de la fréquence d’exploration (ou de la vitesse de rotation)
5.2.3.1
La mise en phase et la sélection de la fréquence d’exploration-ligne s’opèrent sur
une transmission de 30 secondes de signaux alternativement “blanc” et “noir” sur les fréquences
suivantes:
1,0 Hz pour 60 lignes par minute (60 tr/min);
4,0 Hz pour 240 lignes par minute (240 tr/min).
5.2.3.2
La forme du signal devrait être soit symétrique, c’est-à-dire le signal “blanc” et le signal “noir”
ayant chacun une durée correspondant à la moitié de la ligne d’exploration, ou asymétrique, à condition
que, dans ce cas, le signal “blanc” et le signal “noir” aient chacun une durée correspondant respectivement
à 5 % et 95 % de la ligne d’exploration.
5.2.3.3
Les Membres publiant les détails de leur émission fac-similé y incluent la description de
l’émission du signal (symétrique ou asymétrique) de mise en phase.
5.2.3.4
La mise en phase est commandée par le front avant du signal “blanc”. Ce front correspond,
lors de la mise en phase, à l’entrée du rayon lumineux d’exploration dans le secteur mort de la
transmission suivante.
5.2.3.5
L’enveloppe des signaux transmis est approximativement rectangulaire.
5.2.4
Réglage des niveaux d’enregistrement
Lorsqu’on procède à un réglage automatique du niveau d’enregistrement, ce réglage devrait
être effectué en utilisant le signal de mise en phase (voir section 5.2.3 ci-dessus).
5.2.5
Arrêt du récepteur
5.2.5.1
Le signal “arrêt” correspond à la transmission, durant cinq secondes, de signaux “noir” et
“blanc” alternés à la fréquence de 450 Hz, puis, pendant 10 secondes, d’un signal correspondant à un
“noir” continu.
5.2.5.2
L’enveloppe des signaux émis à la fréquence de 450 Hz est approximativement
rectangulaire.
5.2.6
Précision de la fréquence des signaux de télécommande
La tolérance sur la fréquence des signaux de télécommande est de ± 1 %.
édition 2009
III-4
5.3
Caractéristiques de modulation
5.3.1
Les caractéristiques de modulation pour les transmissions en fac-similé analogique sont
les suivantes:
5.3.1.1
Modulation d’amplitude (MA)
L’amplitude maximale de la fréquence porteuse correspond à l’émission d’un signal “noir”.
Valeur de la fréquence porteuse:
Environ 1 800 Hz pour les fréquences d’exploration de 60, 90 et 120 lignes par minute (60,
90 et 120 tr/min);
Environ 2 600 Hz pour la fréquence d’exploration de 240 lignes par minute (240 tr/min).
Dans le cas où la fréquence d’exploration est de 240 lignes par minute (240 tr/min),
les transmissions sont effectuées avec le système à bande latérale résiduelle comportant l’utilisation
éventuelle d’un filtre asymétrique à l’émission.
5.3.1.2
Modulation de fréquence (MF)
Fréquence centrale:
Fréquence correspondant au “noir”:
Fréquence correspondant au “blanc”:
1 900 Hz;
1 500 Hz;
2 300 Hz.
Les fréquences correspondant au “noir” et au “blanc” ne varient pas de plus de 8 Hz
durant une période de 30 secondes et de plus de 16 Hz durant une période de 15 minutes.
5.3.2
Puissance à la sortie de l’émetteur
Pour les transmissions en modulation d’amplitude, la puissance du signal “noir” à la
sortie de l’émetteur doit pouvoir être ajustée entre –7 dBm et 0 dBm.
Pour les transmissions en modulation de fréquence, la puissance du signal “noir” à la
sortie de l’émetteur doit pouvoir être ajustée entre –10 dBm et 0 dBm.
Quel que soit le mode de transmission utilisé (modulation d’amplitude ou modulation de
fréquence), le rapport de contraste est le même pour les signaux de télécommande et pour les signaux
d’images en noir et blanc et est compris entre 12 et 25 dB.
5.3.3
Puissance à l’entrée du récepteur
Pour les transmissions en modulation d’amplitude, les appareils récepteurs sont conçus
pour permettre une réception correcte pour un niveau d’entrée compris entre 0 et –25 dBm, ce niveau
étant celui du signal “noir”.
Pour les transmissions en modulation de fréquence, le niveau d’entrée est compris entre
0 et –35 dBm.
5.4
Transmission des teintes intermédiaires (fac-similé analogique)
5.4.1
Pour la transmission des teintes intermédiaires, une distribution linéaire devrait être observée,
sur la base d’un nombre de teintes égal à 8, y compris les niveaux “noir” et “blanc”.
5.4.2
Pour la modulation d’amplitude, une dynamique de 20 dB devrait être observée, ainsi qu’il suit:
0 dB; –1,2 dB; –2,6 dB; –4,2 dB; –6,3 dB; –9 dB; –13 dB; –20 dB.
5.4.3
Pour la modulation de fréquence, la répartition suivante devrait être observée:
1 500, 1 614, 1 729, 1 843, 1 957, 2 071, 2 186, 2 300 Hz.
5.5
Transmission par fac-similé analogique sur circuits radioélectriques
5.5.1
Lorsqu’on emploie la modulation en fréquence d’une sous-porteuse pour transmettre des
informations par fac-similé analogique sur des circuits radioélectriques, les spécifications à respecter
sont les suivantes:
Fréquence centrale:
édition 2009
1 900 Hz;
1 500 Hz;
2 300 Hz.
III-5
5.5.2
Lorsqu’on emploie la modulation directe en fréquence de la porteuse (FSK) pour transmettre
des informations sous forme d’images par fac-similé analogique sur des circuits radioélectriques, les
spécifications à respecter sont les suivantes:
a)
Circuits en ondes décamétriques (3 MHz–30 MHz)
Fréquence centrale (correspondant à la fréquence assignée): fo
fo – 400 Hz;
fo + 400 Hz;
b)
Circuits en ondes kilométriques (30 kHz–300 kHz)
Fréquence centrale (correspondant à la fréquence assignée): fo
fo – 150 Hz;
fo + 150 Hz.
Caractéristiques techniques de l’équipement pour les transmissions en fac-similé numérique codé
6.
6.1
Les caractéristiques techniques qui suivent sont appliquées à l’équipement pour les
transmissions de documents météorologiques codés qui est utilisé pour l’échange de l’information
graphique à l’échelon international.
6.1.1
Translation d’exploration
La surface du message est explorée dans le même sens de translation à l’émetteur et au
récepteur. Si l’on regarde la surface du message dans un plan vertical, les éléments d’images devraient être
traités comme si l’exploration se faisait de gauche à droite, les explorations successives étant adjacentes et
chacune d’elles immédiatement au-dessous de la précédente.
6.1.2
Norme préférable
6.1.2.1
Les normes suivantes, fondées sur la recommandation UIT-T T.4 — Normalisation des
télécopieurs du groupe 3 pour la transmission de documents, qui s’appliquent à un document de
format A4 de l’ISO sont utilisées:
a) 1 728 éléments d’images sur une longueur de la ligne d’exploration de 215 mm ± 1 %;
b) Une définition nominale et une définition supérieure de 3,85 lignes/mm ± 1 % et 7,7 lignes/mm
± 1 % respectivement, dans le sens vertical;
c) La méthode de codage définie au paragraphe 4.1 de la recommandation UIT-T T.4.
6.1.2.2
Outre les normes applicables au format A4 de base, décrites au paragraphe 6.1.2.1 ci-dessus, il
est possible d’utiliser les normes suivantes:
a)
b)
c)
d)
Longueur utile de la ligne:
Nombre d’éléments d’images par ligne:
Définition horizontale:
Définition verticale:
456 mm;
1 728, 3 456;
3,79, 7,58 lignes/mm;
1) 3,79 lignes/mm (module de coopération 576);
2) 1,89 ligne/mm (module de coopération 288).
6.1.3
Autres normes
T.6).
Selon le cas, il est possible d’utiliser des équipements du groupe 4 (G4) UIT-T (recommandation
6.1.4
Débit binaire
Le débit binaire de transmission sur un circuit point à point est de:
2 400, 4 800, 7 200, 9 600 bit/s.
édition 2009
III-6
7.
Caractéristiques techniques de l’équipement pour les transmissions en fac-similé numérique non codé
7.1
Pour les transmissions en fac-similé numérique non codé, l’équipement terminal d’émission
et de réception devrait être conforme aux normes fixées par l’OMM pour les transmissions en fac-similé
analogique qui se font à l’aide de convertisseurs analogiques numériques.
7.2
Les signaux de télécommande devraient être conformes aux normes de l’OMM (voir la section
5.2 qui précède) et être transmis sous forme numérique après conversion directe.
7.3
à l’interface UIT-T V.24 entre les convertisseurs analogique/numérique et les modems, les
éléments d’images noirs devraient être codés sous forme de bits mis à 0 et les éléments d’images blancs sous
forme de bits mis à 1, selon le tableau suivant:
Niveau significatif (rec. UIT-T V.28)
état binaire
Condition
élément d’image
V1 < – 3 volts
1
Fermé/repos
Blanc
V1 > + 3 volts
0
Ouvert/travail
Noir
7.4
La fréquence d’exploration, le nombre d’éléments d’images dans une ligne complète, le module
de coopération et le débit binaire d’une voie discrète devraient être les suivants:
Fréquence d’exploration
(lignes/min)
60
120
240
60
120
240
Nombre d’éléments
d’images dans une
ligne complète
Module
de
coopération
Débit
binaire
(bit/s)
2 400
1 200
1 200
2 400
2 400
1 800
288
288
288
576
576
576
2 400
2 400
4 800
2 400
4 800
7 200
____________________
édition 2009
www.wmo.int
OMM-N° 386

Manuel du Système mondial de télécommunications

Transcription

Documents pareils

Transmission de données sur RTC Architecture d `une liaison

Les liaisons de base

Description d`une liaison

Classe de 1ère S - lycée Privé La Clairefontaine

Pour Contre - Cabinet Hoffman

Classe de 2nde - lycée Privé La Clairefontaine

Quelques informations concernant le club des sports de La Tania et

SpiTex T75 M1 : une toile tramée