N° d’ordre : 02 / TRC Année Universitaire : 2002/2003

UNIVERSITE D’ANTANANARIVO
-------------------------
ECOLE SUPERIEURE POLYTECHNIQUE
-------------------------
DEPARTEMENT TELECOMMUNICATION

MEMOIRE DE FIN D’ETUDES

en vue de l’obtention
du DIPLOME d’INGENIEUR
Spécialité : Télécommunication
Option : Transmission – Réseau – Commutation

Par : Karim ATTOUMANI

ETUDE DU RESEAU DE TELECOMMUNICATION

AERONAUTIQUE (ATN)

Soutenu le Lundi 23 Février 2004 devant la Commission d’Examen composée de :

Président : M. RANDRIAMITANTSOA Paul Auguste

Examinateurs :
1. M. RAZAKARIVONY Jules
2. M. BOTO ANDRIANANDRASANA Jean Espérant
3. M. RAMORASATA Joseph Raphaël

Directeur de mémoire : M. RATSIHOARANA Constant

REMERCIEMENT

Ce travail de mémoire de fin d’études n’aurait pu être réalisé sans la Grâce de Dieu ainsi
que la contribution des personnes suivantes à qui je tiens à adresser mes vifs remerciements.

Monsieur RANDRIANOELINA Benjamin, Professeur et Directeur de l’Ecole Supérieure

Polytechnique d’Antananarivo pour m’avoir accueilli dans son Etablissement et pour m’avoir
donné l’autorisation de soutenir aujourd’hui ;

Monsieur RANDRIAMITANTSOA Paul Auguste, Professeur et Chef du Département

Télécommunication à l’ESPA, qui nous fait l’honneur de présider le Jury de ce mémoire. Je tiens à
lui adresser toute ma gratitude pour son assistance et son intégrité pendant les trois années
d’études passées au sein du Département Télécommunication ;

Monsieur RATSIHOARANA Constant, Assistant d’Enseignement Supérieure et de

Recherche au sein du Département Télécommunication et Directeur de ce mémoire, qui n’a cessé
de me prodiguer de précieux conseils et de multiples suggestions tout au long de mes travaux de
mémoire malgré ses occupations ;

Monsieur RAZAKARIVONY Jules, Maître de Conférence au sein du Département

Télécommunication à l’ESPA, Membre du Jury ;

Monsieur BOTO ANDRIANANDRASANA Jean Espérant, Assistant d’Enseignement

Supérieure et de Recherche au sein du Département Télécommunication à l’ESPA, Membre du
Jury ;

Monsieur RAMORASATA Joseph Raphaël, Assistant d’Enseignement Supérieure et de

Recherche au sein du Département Télécommunication à l’ESPA, Membre du Jury ;

Mes vifs remerciements s’adressent également à tous les enseignants et personnels de

l’Ecole Supérieure Polytechnique d’Antananarivo, avec un coup de cœur à ceux des Départements
Télécommunication et Electronique qui m’ont formé durant mon cursus universitaire.

Je n’oublierai pas ma famille qui m’a soutenu durant toutes mes études tant moralement
que matériellement. Malgré la distance qui nous sépare, vos pensées et prières m’ont accompagné
jusque là. Plus particulièrement, à mon Père et à mes Mères pour leurs efforts, leur confiance et
leur compréhension durant mon séjour à Madagascar.

Et pour toute personne physique ou morale qui a aidé de prés ou de loin à l’élaboration de
ce mémoire, je vous en suis très reconnaissant et que la grâce d’Allah soit avec vous.

i
 TABLE DES MATIERES

REMERCIEMENT ........................................................................................................................................ i

LISTE DES ABREVIATIONS..................................................................................................................... v

INTRODUCTION ........................................................................................................................................ 1

Chapitre I : CARACTERISTIQUES OPÉRATIONNELLES DU RÉSEAU DE

TÉLÉCOMMUNICATION AÉRONAUTIQUE................................................................. 3
I.1. Introduction. ........................................................................................................................................................ 3
I.2. Environnement aéronautique futur à transmission de données air/sol ............................................................. 3
I.2.1. Fondement d’un futur système de gestion de la circulation aérienne (ATM)........................................ 3
I.2.2. Fonctions AOC et Applications connexes de la Liaison de données. ...................................................... 6
I.2.3. Communications administratives aéronautiques (AAC). ........................................................................ 7
I.3. Caractéristiques du système de communication ATN. ....................................................................................... 7
I.3.1. Généralités. .................................................................................................................................................. 7
I.3.2. Caractéristiques de transfert de données. ................................................................................................. 7
I.3.2.1. Type de données de l'utilisateur. .............................................................................................................................. 7
I.3.2.2. Caractéristiques du dialogue. .................................................................................................................................. 8
I.3.2.3. Paramètres de Qualité du service (QOS). .............................................................................................................. 11
I.3.2.4. Remise des messages. ............................................................................................................................................. 14
I.3.3. Principes de connexion. ............................................................................................................................ 14
I.3.3.1. Types de sous-réseaux aéronautiques. ................................................................................................................... 14
I.3.3.2. Sous-réseaux avionique. ......................................................................................................................................... 15
I.3.3.3. Sous–réseaux sol. ................................................................................................................................................... 15
I.3.3.4. Sous-réseaux air/sol. .............................................................................................................................................. 17
I.3.3.5. Interconnexion de sous-réseaux ............................................................................................................................ 17
I.3.4. Principes d'adressage. ............................................................................................................................... 17
I.3.4.1. Adressage ATN. ...................................................................................................................................................... 17
I.3.4.2. Adressage réseau.................................................................................................................................................... 17
I.3.4.3. Identification de processus. .................................................................................................................................... 19
I.3.5. Contrôle de l’accès au réseau. .................................................................................................................. 19

Chapitre II : ARCHITECTURE DU RÉSEAU DE TÉLÉCOMMUNICATION AÉRONAUTIQUE

(ATN). .................................................................................................................................... 20
II.1. Introduction. ..................................................................................................................................................... 20
II.2. Caractéristiques d'une architecture inter-réseaux .......................................................................................... 20
II.3. Aperçu de l’architecture de protocole ISO. ..................................................................................................... 21
II.3.1. Généralités ............................................................................................................................................... 21
II.3.2. Couches inférieures. ................................................................................................................................ 22
II.3.3. Couches supérieures. ............................................................................................................................... 23
II.3.4. Couche Transport. ................................................................................................................................... 23
II.4. Orientation des services de communication au point de vue connexion. ....................................................... 24
II.5. Organisation de la couche Réseau................................................................................................................... 24
II.6. Accès au service de couche Réseau ................................................................................................................. 25
II.7. Protocoles inter-réseaux ATN. ......................................................................................................................... 26
II.7.1. Protocole inter-réseaux ........................................................................................................................... 26
II.7.2. Protocole d'échange d'information d'acheminement intra-domaine .................................................. 27
II.7.3. Protocole d'acheminement de système terminal à système intermédiaire (ES-IS). ........................... 27
II.7.4. Protocole d'échange d'information d'acheminement inter-domaines. ................................................ 27
II.7.5. Protocoles de gestion de couche Réseau................................................................................................. 27

ii
 II.8. Sous-réseaux constituants. ............................................................................................................................... 28
II.8.1. Généralités. .............................................................................................................................................. 28
II.8.2. Sous-réseaux à topologie générale ou réseaux longue distance (WAN). ............................................. 29
II.8.3. Sous-réseaux de diffusion ou réseaux locaux (LAN). ........................................................................... 29
II.8.4. Sous-réseaux mobiles............................................................................................................................... 29
II.9. Routeurs ATN. .................................................................................................................................................. 30
II.9.1. Rôle du routeur. ....................................................................................................................................... 31
II.9.2. Echange d’informations de routage. ...................................................................................................... 33
II.10. Structure des domaines de l'entité inter-réseaux ATN.................................................................................. 33
II.10.1. Domaines administratifs ATN. ............................................................................................................. 33
II.10.2. Domaines d'acheminement ATN. ......................................................................................................... 34
II.10.3. Zones d'acheminement. ......................................................................................................................... 34
II.10.4. Domaines de sous-réseau....................................................................................................................... 35
II.11. Adresse inter-réseaux ATN. ........................................................................................................................... 36
II.11.1. Adresses inter-réseaux locaux. ............................................................................................................. 36
II.11.2. Titres d'entité de réseau. ....................................................................................................................... 36
II.11.3. Adresses de sous-réseau locales. ........................................................................................................... 37
II.11.4. Utilisation d'adresses pour l'acheminement inter-réseaux ................................................................ 37
II.11.5. Relation entre les domaines ATN et les adresses NSAP ATN............................................................ 38
II.12. Procédures d’acheminement inter-réseaux ATN. ......................................................................................... 38
II.12.1. Généralités. ............................................................................................................................................ 38
II.12.2. Acheminement inter-domaines ............................................................................................................. 39
II.12.3. Acheminement intra-domaine .............................................................................................................. 39
II.13. Transmission des unités de données. ............................................................................................................. 40
II.14. Échange d'information topologique intra-domaine ...................................................................................... 40
II.15. Architecture de protocole ATN. ..................................................................................................................... 41
II.15.1. Généralités. ............................................................................................................................................ 41
II.15.2. Interfaces de l'architecture de protocole ATN. ................................................................................... 42
II.15.3. Fonctionnement de l'architecture de protocole ATN. ........................................................................ 43
II.16. Fonctionnement des sous-réseaux ................................................................................................................. 44
II.16.1. Généralités. ............................................................................................................................................ 44
II.16.2. Considérations relatives au protocole. ................................................................................................. 45
II.17. Opérations inter-réseaux ................................................................................................................................ 46
II.18. Opérations de Transport. ............................................................................................................................... 47
II.18.1. Généralités. ............................................................................................................................................ 47
II.18.2. Considérations relatives au protocole. ................................................................................................. 47
II.19. Opérations de couches supérieures. ............................................................................................................... 48

Chapitre III : Les différentes architectures fonctionnelles des communications air/sol de l’ATN. ..... 49
III.1. Evolution des architectures des systèmes de communication........................................................................ 49
III.1.1. Système informatisé d'Aéronef. ............................................................................................................ 49
III.1.1.1. Réseau Haut débit. ............................................................................................................................................... 49
III.1.1.2. Serveurs dans l'aéronef........................................................................................................................................ 51
III.1.1.3. Affichages multifonctionnels ................................................................................................................................ 51
III.1.1.4. Routeur intelligent. .............................................................................................................................................. 52
III.1.2. Amélioration des liaisons VHF ............................................................................................................. 52
III.1.2.1. Antenne VHF directionnelle ................................................................................................................................ 52
III.1.2.2. Modulation .......................................................................................................................................................... 53
III.1.2.3. Réseau virtuel ...................................................................................................................................................... 53
III.1.3. SATCOM. ............................................................................................................................................... 54
III.1.3.1. Interfaces radio multimode avec la bande Ka. .................................................................................................... 54
III.1.3.2. Techniques de modulation. .................................................................................................................................. 54
III.1.3.3. Niveaux mobiles................................................................................................................................................... 55

iii
 III.1.3.4. Amélioration des récepteurs. ............................................................................................................................... 56
III.1.3.5. Améliorations de l'Antenne dans la bande Ka. .................................................................................................... 56

III.2. Architecture fonctionnelle des communications air sol. ............................................................................... 56

III.3. Analyse fonctionnelle. .................................................................................................................................... 56
III.3.1. Concepts opérationnels et techniques................................................................................................... 56
III.3.2. Catégories des messages. ....................................................................................................................... 57
III.4. Introduction sur les applications Client/Serveur ........................................................................................... 59
III.4.1. Présentation de l'architecture d'un système Client/Serveur .............................................................. 59
III.4.2. Avantages de l'architecture Client/Serveur ......................................................................................... 60
III.4.3. Inconvénients du modèle Client/Serveur ............................................................................................. 60
III.4.4. Fonctionnement d'un système Client/Serveur ..................................................................................... 60
III.4.5. L’architecture Client/Serveur multi-niveaux ...................................................................................... 61
III.4.5.1. Présentation de l'architecture à 2 niveaux........................................................................................................... 61
III.4.5.2. Présentation de l'architecture à 3 niveaux........................................................................................................... 61
III.4.5.3. Comparaison des deux types d'architecture ........................................................................................................ 62
III.4.5.4. L'architecture multi-niveaux. ............................................................................................................................... 62

Chapitre IV : Simulation du Réseau de Télécommunication Aéronautique sous PHP/MySQL :

Implémentation d’une application Client/Serveur. ........................................................... 63
IV.1. Présentation des logiciels utilisés.................................................................................................................... 63
IV.1.1. MySQL : Serveur et Serveur et Système de Gestion de Base de Données ........................................ 63
IV.1.2. PHP.......................................................................................................................................................... 64
IV.1.3. Apache ..................................................................................................................................................... 65
IV.2. Les fonctions utilisées pour la simulation du Réseau de Télécommunication Aéronautique. ..................... 66
IV.2.1. La fonction de connexion au serveur mysql_pconnect(). .................................................................... 66
IV.2.2. La fonction die(). .................................................................................................................................... 67
IV.2.3. La fonction mysql_error(). ................................................................................................................... 67
IV.2.4. La fonction mysql_select_db()............................................................................................................... 67
IV.2.5. La fonction mysql_query() .................................................................................................................... 67
IV.2.6. La fonction mysql_fetch_assoc(). .......................................................................................................... 67
IV.2.7. La fonction mysql_num_rows() ............................................................................................................ 68
IV.2.8. La fonction mysql_free_result() ............................................................................................................ 68
IV.2.9. La fonction date(). ............................................................................................................................. 68
IV.3. Architecture du modèle utilisé. ....................................................................................................................... 68
IV.4. Base de données. ............................................................................................................................................. 70
IV.5. Fonctionnement du site Web interfaçant notre base de données. ................................................................. 70

CONCLUSION ............................................................................................................................................ 76

ANNEXES ................................................................................................................................................ 77

ANNEXE I : Communications aéronautiques .......................................................................................... 77

ANNEXE II : Normes utilisées dans l’ATN par couche OSI. ................................................................. 79

ANNEXE III : Création de la base de données......................................................................................... 81

ANNEXE IV : Création du site. ................................................................................................................. 83

Bibliographie................................................................................................................................................ 97

iv
LISTE DES ABREVIATIONS
ACARS : Aircraft Communications Addressing and Reporting System
ADS : Automatic Dependent Surveillance
ADS-B : ADS-Broadcast
AFTN : Aeronautical Fixed Telecommunication Network
AOC : Airline Operation Center
APAXS : Aeronautical passengers services
APC : Aeronautical passengers Communication
ATC : Air Traffic Control
ATFM : Air Traffic Flight Management
ATM : Air Traffic Management
ATN : Aeronautical Telecommunication Network / Réseau de Télécommunication
Aéronautique
ATNPA : ATN protocol architecture
ATS : Air Traffic Services
ATSC : ATS communications
AUTOMET : Transmission météorologique automatisée
BPSK : Bi Phase Shift Keying
CCITT : Comité Consultatif International Télégraphique et Téléphonique
CIDIN : Common ICAO Data Interchange Network
CLNP : Connectionless-mode Network Protocol
CLNS : Connectionless-mode Network Service
CLTS : Connectionless-mode Transport Service
CM : Context Management
CMU : Central management Unit
CNS : Communication Navigation Surveillance
COTS : Connection Oriented Transport Service
CPC : Communication Pilote-Contrôleur
CPDLC : Controller/Pilot Data Link Communications
D8PSK : Modulation par déplacement de phase différentielle octovalente / Differentially
encoded 8 phase shift keying
DME : Distance measurement equipment
DNS : Domain Name Service
DSB-AM : Double Side Bande-Amplitude Modulation
DSSDL : Liaison de données du Système de prise de décision
ES : Système Terminal / End-System
FDDI : Fiber Distributed Data Interface
FIB : Base d'information de transmission / Forwarding Information Base
FMS : Système de gestion de vol / Flight Management System
FTP : File Transfer Protocol / Protocole de transfert de fichiers
GEO : Geostationary satellite
GMP : Groupes motopropulseurs
HEO : High earth orbit
HTML : HyperText Markup Language
http : HyperText Transfer Protocol
IATA : International Air Transportation Association
ICD : International Code Designator

v
ID : Identification
IDRP : Inter-Domain Routing Protocol
IP : Internet Protocol
IS : Intermediate System
ISO : International Organization for Standardization
ISOPA : Architecture du protocole OSI / ISO Protocol Architecture
Kb : Kilo bit
LAN : Local Area Network
LEO : Low Earth Orbit
LNA : Low Noise Amplifier
MEO : Medium Earth Orbit
MET : Météo
MTU : Maximum Transmission Unit
NAS : National Airspace System
NASA : National Aeronautics and Space Administration
NET : Network Entity Title
NIC : Network Information Center
NLM : Gestion de couche réseau / Network Layer Management
NOTAM : Notice To Airman
NSAP : Point d'accès au service de réseau /
OACI/ICAO : Organisation de l’Aviation Civile Internationale
OSI : Open System Interconnection
PCI : Information de commande de protocole
PDU : Protocol Data Unit
PHP : Hypertext Preprocessor
QOS : Quality of Service
QPSK : Quadrature Phase Shift Keying
RAID : Redundant Array of Independant Disks / Ensemble redondant de disques
indépendants
RF : Radio Frequency
RIB : Routing Information Base
SATCOM : Satellite Communications
SDU : Service Data Unit / Unité de données de service
SGBD : Système de Gestion de Base de Données Relationnelle
SNAcP : Protocole d'accès au sous-réseau
SNDCP : Protocole de convergence dépendant du sous-réseau
SNPA : Point de raccordement au sous-réseau
SQL : Structured Query Language / langage courant d'extraction de données
SSR : radar secondaire de surveillance
UHF : Ultra High Frequency
VDL : VHF Data Link ou VHF Digital Link
VHF : Very High Frequency
VOR : VHF Omnidirectional Ranging
WAN : Wide Area Network

vi
INTRODUCTION [1] [2]
Le niveau d’automatisation des systèmes du contrôle de la circulation aérienne ATC (air
trafic control) va devoir augmenter si l’on veut que le contrôleur puisse faire face à l’augmentation
continuelle du trafic aérien. En particulier, les ordinateurs de bord qui contiennent des
informations précises sur la trajectoire future de l’aéronef devraient être connectés aux ordinateurs
sol de l’ATC qui ont connaissance de la situation globale du trafic aérien.
De ce constat est née une forte activité dans le domaine des liaisons de données air/sol.
Mais chacune de ces « data-links » n’est qu’un élément appelé « sous-réseau » de la chaîne reliant
l’expéditeur au destinataire, et ne peut donc pas fournir une assurance suffisante sur la qualité de
transmission de bout en bout.
Un concept plus global est donc nécessaire, englobant tous les sous-réseaux que les
communications aéronautiques air/sol et sol/sol utiliseront (sous-réseaux embarqués, sous-réseaux
air/sol, et sous-réseaux sol), et qui leur permet de fonctionner ensemble comme un réseau unique.
Ce concept s’appelle l’ATN : Aeronautical Télécommunication Network ou Réseau de
Télécommunication Aéronautique (ATN).
Afin d’assurer le succès de la mise en œuvre de cette nouvelle infrastructure inter-réseaux,
il est important de reconnaître que :
a) le recours de plus en plus fréquent à l’automatisation de l’ATM (Air Trafic
Management ou gestion de la circulation aérienne) exige un niveau accru de transmission
de données entre ordinateurs au sol et ordinateurs embarqués desservant des emplacements
fixes ou mobiles ;
b) le niveau de plus en plus élevé d’automatisation de l’ATM exige une infrastructure de
réseau de transmission de données comportant un plus grands nombre de connexions et
une configuration plus souple que ce qui existe actuellement, autant à bord des aéronefs
qu’au sol ;
c) l’augmentation de l’ATM ne connaîtra un réel succès que lorsque les systèmes
informatiques à bord des aéronefs soient conçus et exploités comme des systèmes de
traitement de données et de mise en réseau semblables aux systèmes informatiques utilisés
au sol, plutôt que de continuer à servir de terminaux de bord reliés à des ordinateurs hôtes
au sol.
L’infrastructure nécessaire à l’interconnexion des systèmes ATM automatisés s’appelle
entité inter-réseaux L’entité inter-réseaux assure l’interconnexion d’ordinateurs et de passerelles

1
ou de routeurs au moyen de sous-réseaux réels. Il est ainsi possible de construire un réseau de
données virtuel homogène dans un environnement caractérisé par la diversité administrative et
technique. L’infrastructure inter-réseaux mise au point dans ce but par l’Organisation de
l’Aviation Civile Internationale (OACI) est le réseau de télécommunication aéronautique (ATN)
qui fait l’objet de ce mémoire de fin d’étude.

La conception de l’ATN permet d’assurer des services de communication à différents

groupes d’utilisateurs, à savoir les services de la circulation aérienne (ATS), le contrôle
d’exploitation aéronautique (AOC), les communications administratives aéronautiques (AAC) et
les communications des passagers aériens (APC). Cette conception permet d’incorporer différents
sous-réseaux air/sol et différents sous-réseaux sol/sol pour obtenir un service commun de transfert
de données. Ces deux aspects forment la base de l’interopérabilité de l’ATN et constituent un
service fiable de transfert pour tous les utilisateurs. En outre, la conception de l’ATN est telle que
des services de communication utilisateur peuvent être mis en œuvre progressivement.

Les deux grandes parties qui composent ce mémoire, partie théorique et partie simulation,
sont reparties de la manière suivante :

Partie théorique :

- Le chapitre I décrit les caractéristiques opérationnelles de l’ATN du point de vue de

l’utilisateur.

- Le chapitre II, qui est étroitement lié au chapitre I, décrit l’architecture de l’ATN au point
de vue du fournisseur de service ATN.

- Le chapitre III énonce les différentes architectures fonctionnelles des communications

air/sol de l’ATN.

Partie simulation : Quant à la simulation du réseau de télécommunication aéronautique,

nous avons implémenté une application Client/Serveur pouvant être utilisé dans l’ATN : accès à
une base de données à distance en utilisant PHP/MySQL et Apache.

2
Chapitre I : CARACTERISTIQUES OPÉRATIONNELLES DU RÉSEAU DE
TÉLÉCOMMUNICATION AÉRONAUTIQUE.

I.1. Introduction. [1] [2] [3] [4]

Pour concevoir l’ATN, il est indispensable de savoir comment la transmission de données

peut être intégrée dans les systèmes terminaux embarqués comme dans les systèmes terminaux au
sol. Il faut donc définir l’emploi opérationnel de la transmission de données. Il est possible de
distinguer différents groupes d’utilisateurs de système que sont les services ATS. L’emploi de la
transmission de données à des fins ATS peut être très varié.

On s’attend à ce que l’aviation internationale respecte la séparation des fonctions de

communication que spécifie le modèle de référence d’interconnexion de systèmes ouverts (OSI)
mis au point par l’Organisation internationale de normalisation (ISO). Les couches supérieures
(Application, Présentation et Session) dépendent des Applications. Par conséquent, il faut mieux
connaître les processus d’Application de la Liaison de données avant d’entreprendre l’élaboration
de normes pour les couches supérieures.

I.2. Environnement aéronautique futur à transmission de données air/sol. [1] [2] [3] [5]

I.2.1. Fondement d’un futur système de gestion de la circulation aérienne (ATM)

La gestion de la circulation aérienne (ATM) est constituée d’une partie sol et d’une partie
air; l’une et l’autre sont nécessaires pour assurer la sécurité et l’efficacité de toutes les phases du
vol. Le contrôle de la circulation aérienne (ATC) est l’élément principal de l’ATM.

Les fonctions de l’ATM comprennent le contrôle de la circulation aérienne (ATC), la

gestion des courants de trafic aérien (ATFM) et la gestion de l’espace aérien. Ces trois éléments
contribuent à la réalisation des objectifs ATM durant les différents phases du vol. L’ATM a pour
objectif principal d’assurer l’écoulement sûr, rapide et ordonné de la circulation aérienne.
L’efficacité du système dépend en particulier de facteurs tels que le coût de la mise en œuvre et les
dépenses de fonctionnement de la partie air comme de la partie sol, et la capacité de satisfaire les
besoins des utilisateurs.

Les principes qu'il faut appliquer pour réaliser les objectifs ci-dessus comprennent les
points suivants :

a) le système ATM devrait offrir aux utilisateurs la plus grande souplesse possible
d'utilisation de 1'espace aérien, compte tenu de leurs besoins opérationnels et économiques aussi

3
bien que des possibilités du système sol. Ces possibilités peuvent être limitées par la capacité des
aéroports;
b) la compatibilité fonctionnelle des données échangées entre les aéronefs et le sol est
indispensable à l’efficacité globale du système ;
c) le partage de l’espace aérien entre différentes catégories d’utilisateurs doit être organisé
de la manière la plus souple possible compte tenu des différents niveaux d’équipement des
aéronefs ;
d) les différents composants ATC des systèmes ATM globaux doivent être conçus pour
fonctionner ensemble efficacement de manière à assurer un service homogène, continu et efficace
à 1’utilisateur, du décollage à l'atterrissage. Il faut assurer une harmonisation internationale, et en
fin de compte 1'intégration, en vue de la cohérence des vols transfrontaliers.
Pour réaliser un système conforme aux principes ci-dessus, il faudra adapter les procédures et les
moyens existants et aussi en mettre au point de nouveaux.
Jusqu'à présent, l'automatisation du contrôle de la circulation aérienne, qu'exige
l'acheminement d'une circulation dont le volume ne cesse d'augmenter, a reposé principalement
sur une meilleure utilisation des renseignements limités dont on dispose sur :
a) les intentions de l’aéronef indiquées dans le plan de vol et ses mises à jour ;
b) la position de l’aéronef, qui est déterminée par les moyens actuels de surveillance.
Malgré la mise en service du radar secondaire de surveillance (SSR), on constate encore
une importante lacune dans la circulation de l'information entre les aéronefs et le sol. De plus, de
vastes parties du monde manquent de couverture fiable par des systèmes de communication,
navigation et surveillance (CNS). Faute de mesures appropriées, l'efficacité diminuera encore dans
l'avenir en raison de la croissance prévue de la circulation et de l'élargissement du fossé entre les
moyens embarqués et les moyens sol. Les exemples ci-dessous sont valables, dans une certaine
mesure, même dans les environnements de systèmes ATC les plus évolués :
a) la circulation de l'information à l'intérieur des organes ATC (communication sol/sol) et
entre les organes ATC et les aéronefs qu’ils contrôlent (communication air/sol) est insuffisante
pour permettre d'autres améliorations. C'est un fait cependant que le traitement des données de vol
et le traitement des données radar, plus ou moins perfectionnés, sont assez largement utilisés et
que la gestion automatique des courants de trafic existe déjà;
b) le contrôle de la circulation aérienne (ATC) a besoin de données et de procédures
améliorées pour assurer la surveillance, la prédiction et l'optimisation des flux de trafic aérien ;

4
 c) les systèmes ATC les plus évolués utilisent encore des données sur les performances des
aéronefs et sur les conditions ambiantes peu fidèles à la réalité. Pour cette raison, les profils de vol
optimisés ne sont pas toujours possibles;

d) les possibilités des équipements embarqués évolués en matière de planification et

d'optimisation des trajectoires de vol ont dépassé les possibilités des systèmes au sol
correspondants. Les exploitants insistent pour mettre à profit ces possibilités dans une plus large
mesure. Il est évident qu'un moyen de leur donner satisfaction serait d'appliquer des concepts qui
tiennent davantage compte de ces possibilités;

e) les structures de routes sont généralement rigides, bien que l'on autorise de plus en plus
des itinéraires directs lorsque la charge de travail des contrôleurs le permet.

Les améliorations des systèmes embarqués et des systèmes au sol, améliorations qui se
complètent, permettront d’utiliser de la manière la plus efficace possible les ressources des
aéroports et de l'espace aérien. La mise en œuvre prévue d'une Liaison de données air/sol jouera à
cet égard un rôle essentiel. On envisage d'améliorer le système sol comme suit :

a) amélioration de l'acheminement et du transfert de 1'information entre exploitants,

aéronefs et centres ATC;

b) amélioration de la planification en la rendant plus précise et en ayant recours

notamment à de meilleurs renseignements météorologiques ;

c) amélioration de la détection et la résolution des conflits ;

d) amélioration de l'aptitude à tirer profit de la plus grande précision de navigation en

quatre dimensions des aéronefs modernes;

e) mieux tenir compte du profil de vol préféré dans toutes les phases du vol, en se fondant
sur les objectifs de l'exploitant.
L'évolution de l'ATM exige l'amélioration des services CNS. Il faudrait notamment que
leur couverture soit bien meilleure et qu'il y ait des moyens efficaces d'échange air/sol de données.
Pour que l'on retire les avantages maximaux des nouveaux systèmes CNS, il est indispensable que
ces derniers soient adaptés aux services ATM nécessaires. Les objectifs et les principes de l'ATM
sont essentiellement les mêmes partout, mais le degré de perfectionnement nécessaire à l’ATM
dépend beaucoup du type d'espace aérien et, de ce fait, le détail des conditions de mise en oeuvre
variera d'un endroit à l'autre. De plus, la mesure dans laquelle ces besoins ATM peuvent être
satisfaits est fortement influencée par la possibilité d'assurer des services CNS.

5
I.2.2. Fonctions AOC et Applications connexes de la Liaison de données.
Les fonctions AOC sont habitue1lement exercées par les services de contrôle
d'exploitation des organismes aéronautiques, qui, selon la structure concrète de chaque organisme,
peuvent soit exercer directement certaines fonctions connexes d'autres services d’exploitation, soit
avoir des liens très étroits avec d’autres services (opérations aériennes, ingénierie et maintenance,
etc.) dans l'exercice et la coordination de certaines fonctions connexes. Voici quelques exemples
de fonctions AOC :
a) traitement de situations exceptionnelles (cas d'urgence d’aéronef ou de vol, piraterie
aérienne, etc.);
b) planification des vols;
c) certains renseignements météorologiques;
d) information d'exploitation au sujet des aéroports et des voies aériennes (NOTAM), etc.:
e) contrôle des mouvements (départs, arrivées, retards et déroutements des vols);
f) temps de vol des équipages de conduite;
g) contrôle des groupes motopropulseurs (GMP) ; et
h) comptes rendus de problèmes de maintenance en vol et résolution de ces problèmes.
Toutes les fonctions AOC ci-dessus demandent des Liaisons avec les aéronefs sous forme
de communications air/sol adéquates (voix et données) effectuées soit par l'intermédiaire de
l'équipage de conduite, soit directement par des systèmes et des capteurs embarqués (après
vérification des données par l'équipage de conduite), par exemple les systèmes de gestion de vol
(FMS) ou l'unité d'acquisition de données numériques de vol (DFDAU) pour des fonctions telles
que les suivantes :
a) mise à jour de la base de données d'exploitation du FMS en ce qui concerne :
1) les données de plan de vol;

2) le devis de poids et de centrage;

3) certaines données météorologiques;
b) enregistrements/comptes rendus DFDAU sur :
1) le contrôle de l'état des GMP ;
2) la consommation, les réserves, les besoins de carburant, etc.
Des processus d'Application informatique servent déjà à bien des fonctions AOC ci-dessus.
La tendance, qui devrait s'accentuer, a déjà eu pour effet une diminution sensible des
communications vocales, donc une utilisation plus équilibrée des bandes de fréquences

6
disponibles. Les communications AOC échangées à l'intérieur de l'ATN rehaussent sensiblement
la sécurité, la régularité et l'efficacité des vols et des opérations en général.

I.2.3. Communications administratives aéronautiques (AAC).

Les services d'exploitation aéronautique ont besoin d’échanger des communications liées
aux aspects affaires des vols et du service de Transport aérien. Ces communications d'un
organisme privé ont des objets très variés tels que les réservations en matière de vol et de
Transport terrestre, le déploiement des équipages et des aéronefs, l'organisation des fournitures et
services pour les vols à l'aller et au retour et n'importe quelle autre opération logistique de nature à
maintenir ou à rehausser l’efficacité d’ensemble du vol.

I.3. Caractéristiques du système de communication ATN. [1] [2] [3]

I.3.1. Généralités.
Dans cette partie nous allons décrire les reg1es fondamentales relatives au transfert de
données, aux connexions et à l'adressage, et définir les caractéristiques du système de
communication. Toutes les Applications que doit servir l'ATN doivent être conformes au même
ensemble normalisé de règles afin que tous les messages soient remis aussi efficacement que
possible et dans l'ordre de priorité.
Il importe de reconnaître le type des transferts de données réalisés dans l'ATN pour
concevoir les procédures appropriées de transfert de données. Les différents types de transfert de
données sont déterminés par les différentes Applications pour lesquelles des fonctions sont gérées
par des processus spéciaux d'Application. Il est possible d'examiner les différents types de
données d'Application en tant que données de fichier utilisateur et de données de message
utilisateur. Il est possible de décrire la méthode particulière de transfert de données utilisée à l'aide
de types de dialogue tels que le dialogue d'instructions et le dialogue de demande. Pour que le
réseau de communication puisse déterminer et assurer le service nécessaire, les données utilisateur
doivent être accompagnées de paramètres de qualité de service (QOS) et d'une information
d'adressage.

I.3.2. Caractéristiques de transfert de données.

I.3.2.1. Type de données de l'utilisateur.

Par définition, les données utilisateur sont les données produites par un utilisateur (ATS)
pour être transférées à son homologue par le réseau de télécommunication aéronautique.

7
 Fichier utilisateur : par définition, un fichier utilisateur est un ensemble comprenant un ou
plusieurs enregistrements comprenant tous le même ensemble de paramètres ou d'articles. Un
fichier utilisateur confirmé exige que 1'utilisateur récepteur envoie un accusé de réception à
1'utilisateur expéditeur. Une bonne partie des futures fonctions ATS générera un fichier utilisateur.
Par exemple, une trajectoire, qu'utiliseront bien des fonctions ATS futures, peut être définie
comme étant un fichier contenant deux ou plusieurs enregistrements de point de cheminement
décrivant la trajectoire. Chaque enregistrement de point de cheminement contient un ensemble de
paramètres qui définissent ce point de cheminement en 2, 3 ou 4 dimensions. Un fichier utilisateur
avec confirmation de type fichier trajectoire peut servir au transfert d'une instruction relative à la
trajectoire, tandis qu'un fichier trajectoire sans confirmation peut servir à une demande de
trajectoire émanant du poste de pilotage. Un fichier utilisateur peut également servir à l'échange de
renseignements météorologiques. Dans ce cas, le fichier utilisateur est sans confirmation, c'est-à-
dire qu'aucun accusé de réception n’est exigé de l'utilisateur récepteur. A noter que le réseau de
communication peut générer un accusé de réception technique de bout en bout, indépendamment
de l’utilisateur. Cependant, cet accusé de réception n'est pas lié à la signification des données
transférées, comme l'est l'accusé de réception de l'utilisateur, mais à la syntaxe et au format des
données. La longueur d'un fichier utilisateur varie entre plusieurs dizaines et plusieurs centaines de
bits.

Message utilisateur : un message utilisateur contient un ou plusieurs champs, contenant

différents paramètres ou articles. Un message utilisateur avec confirmation nécessite un accusé de
réception de la part de 1'utilisateur. La plupart des instructions ATC nécessitant une confirmation
peuvent rentrer dans un message utilisateur avec confirmation. Les messages sans confirmation
peuvent servir par exemple au transfert de préavis et de renseignements ATS. La longueur du
message utilisateur a généralement une valeur faible par rapport à celle de la longueur du fichier
utilisateur.

I.3.2.2. Caractéristiques du dialogue.

Par définition, un dialogue est un échange de messages ou de fichiers utilisateur entre deux
utilisateurs.

Types de dialogue : On peut distinguer les types fondamentaux de dialogue suivants :

a) Dialogue d'instructions (Figure I. 1) : Le dialogue d'instructions doit servir au transfert

d'instructions ATC (communications exécutives ATC). Une instruction peut être un fichier ou un

8
message exécutif utilisateur, tandis qu’une confirmation peut être un message utilisateur si aucun
renseignement ne doit être répété. Un dialogue d'instructions est toujours déclenché au sol.

Utilisateur sol Réseau de Utilisateur air

communication

Instruction
Instruction

Confirmation
Confirmation

Figure I. 1 : Dialogue d’instructions déclenché au sol

b) Dialogue de demande (Figure I.2 et I.3) : Le dialogue de demande peut être déclenché
soit à bord, soit au sol. Dans le sens demande aussi bien que dans le sens réponse, il est possible
de transférer des fichiers et des messages non exécutifs. Ce type de dialogue peut servir par
exemple à l'acquisition de renseignements météorologiques (MET).
Utilisateur sol Réseau de Utilisateur air
communication

Demande
Demande

Information
Réponse

Figure I. 2 : Dialogue de demande déclenché au sol

Réseau de
Utilisateur sol communication Utilisateur air

Demande
Demande

Réponse
Information

Figure I. 3 : Dialogue de demande déclenché à bord

9
 c) Dialogue demande/instructions (Figure I. 4) : Le dialogue demande/instructions ne peut
être déclenché qu'à bord, car l'instruction est une réponse à la demande et l'instruction ne peut être
donnée que par l'utilisateur se trouvant au sol (ATC). Un dialogue demande/instructions peut
servir par exemple à une demande de trajectoire émanant du poste de pilotage. La demande
contient un fichier trajectoire; le contrôle de la circulation aérienne (ATC) peut donner en guise
de réponse une instruction relative à la trajectoire sous forme de fichier utilisateur exécutif de type
trajectoire. Puisqu'une instruction doit être confirmée, l'utilisateur en vol enverra une confirmation
(fichier/message utilisateur) au contrôle de la circulation aérienne.
Réseau de
Utilisateur sol communication Utilisateur air

Demande
Demande

Instruction
Instruction

Confirmation
Confirmation

Figure I. 4 : Dialogue de demande/Instructions déclenché à bord

d) Dialogue demande/négociation/instructions (Figure I. 5) : Si, dans le cas d'une

demande de trajectoire émanant du poste de pilotage, le contrôle de la circulation aérienne ne juge
pas acceptable la trajectoire demandée, un dialogue de négociation peut être amorcé. Les
possibilités de négociation sont limitées par les délais disponibles. Si les deux parties peuvent
s'entendre, le dialogue s'achève par une instruction.
Paramètres de dialogue : Un dialogue peut être caractérisé par deux paramètres qui
peuvent servir à déterminer les paramètres QOS qui servent, eux, à établir la connexion de réseau
ayant rapport au dialogue. Ces paramètres sont :
a) Durée du dialogue : Par définition, la durée du dialogue est le temps pendant lequel un
utilisateur considère qu'un dialogue est en cours. Un dialogue est en cours à partir du moment où
le premier message ou fichier correspondant est envoyé ou reçu (Figure I. 6). La durée du
dialogue est donc liée au type de dialogue et à 1'utilisateur (utilisateur sol, utilisateur air).

10
 Utilisateur sol Réseau de Utilisateur air
communication
Demande
Demande

Proposition (1)
Proposition (1)

Proposition (2)
Proposition (2)

Instruction
Instruction

Confirmation
Confirmation

Figure I. 5 : Dialogue de demande/Instructions déclenché à bord

b) Priorité du dialogue : La priorité qui peut être attribuée à un dialogue a une certaine
importance pour chaque message ou fichier faisant partie de ce dialogue. La priorité de dialogue
dépend du type de dialogue et de la situation opérationnelle dans laquelle ce dialogue a lieu.

Utilisateur A Réseau de Utilisateur B

communication

Durée du Durée du
dialogue dialogue

Figure I. 6 : Durée du dialogue

I.3.2.3. Paramètres de Qualité du service (QOS).

Pour qu'il puisse accomplir ses fonctions, l’ATN doit connaître les types de données et le
transfert de dialogues, qui concernent un processus d'Application particulier. L'ATN utilise des
renseignements tels que la fréquence des transferts, le débit, la priorité, le retard de transfert, la
fiabilité et le coût (paramètres QOS) pour allouer les ressources et remettre les données à

11
l'utilisateur spécifié, il est possible d'utiliser un ensemble de types de données pour déterminer à
l'avance les valeurs nécessaires des paramètres QOS.
Fréquence des transferts : Par définition, la fréquence des transferts est le nombre total de
messages utilisateur et fichiers utilisateur transférés par unité de temps par utilisateur. La
fréquence des transferts est un paramètre propre à l'utilisateur, qui peut dépendre de :
a) la densité de circulation;
b) le niveau d'automatisation;
c) la phase de vol;
d) les besoins locaux d'exploitation.
Débit : Le débit exigé par une fonction ATS est déterminé par le transfert des messages ou
des fichiers générés par cette fonction et la longueur de ces messages ou fichiers. Le débit
nécessaire est exprimé dans un paramètre QOS. Dans le cas des fonctions ATS de haute priorité et
d'importance critique pour le vol, le débit nécessaire doit toujours être inférieur au débit disponible
qui est déterminé par le «plus faible maillon» du réseau de communication. Il est donc important
de déterminer le débit maximal nécessaire avant de normaliser et de mettre en oeuvre une fonction
ATS d'importance critique pour le vol, qui fait usage du réseau. Il faut comparer ce débit avec le
débit maximal disponible estimé.
Priorité : D'après la priorité requise (paramètre QOS), le réseau détermine l'ordre dans
lequel les messages ou les fichiers sont transmis. Cette priorité est indiquée pendant la phase
d'établissement de la communication. On peut distinguer deux types de priorités :
a) Priorité statique : La priorité statique est liée au type d'information à transférer par
l'intermédiaire de l'ATN, comme dans le cas de tout autre réseau de communication. L'article 51
du Règlement des radiocommunications de 1'UlT indique l’ordre de priorité ci-après pour dix
catégories de communications du service mobile aéronautique et du service mobile aéronautique
par satellite :
1. Appels de détresse, messages de détresse et trafic de détresse.
2. Communications précédées du signal d'urgence.
3. Communications relatives à la radiogoniométrie.
4. Messages intéressant la sécurité des vols.
5. Messages météorologiques.
6. Messages intéressant la régularité des vols.
7. Communications relatives à l'Application de la Charte des Nations Unies.

12
 8. Communications d’État pour lesquelles le droit de priorité a été expressément
demandé.
9. Communications de service relatives au fonctionnement du service de
télécommunication ou à des communications précédemment écoulées.
10. Autres communications aéronautiques.

Les communications des catégories 1 à 6 se rapportent à des services de sécurité et les

communications des catégories 7 à 10 à d'autres services. La catégorie 3 ne concerne pas le réseau
de télécommunication aéronautique. Un système de priorité peut aussi être établi à l'intérieur d'une
catégorie. Cela vaut en particulier pour les catégories 4, 5 et 6.

b) Priorité dynamique : La priorité dynamique est liée à la situation dans laquelle une
certaine information doit être transférée. Par exemple, il est possible qu'en cas d'avertissement de
conflit à court terme un message contenant des informations relatives au cap (s'il doit en résulter
une meilleure résolution) bénéficie d'une priorité plus élevée que dans une situation normale. Le
niveau de priorité dynamique doit être assigné par les fonctions ATS pertinentes tandis que le
niveau de priorité statique est prédéterminé.
Temps de transfert : Par définition, le temps de transfert est le temps total nécessaire au
transfert d’un message ou d’un fichier utilisateur, de l'utilisateur expéditeur à l’utilisateur
récepteur. Un utilisateur peut indiquer le temps de transfert maximal acceptable en positionnant
convenablement le paramètre de débit dans l'ensemble de paramètres QOS. Comme le paramètre
QOS priorité, le paramètre temps de transfert maximal acceptable est prédéterminé par le type
d'information, et il est possible de ne pas en tenir compte selon la situation dans laquelle une
certaine information doit être transférée. Le temps de transfert dans un réseau est une grandeur
dynamique. On peut toutefois déterminer, pour certaines configurations de sous-réseaux, un temps
minimal de transfert. Les facteurs ci-dessous, parmi d'autres, entrent en jeu :
a) temps minimal de traitement dans les passerelles et dans l'équipement de traitement ;
b) caractéristiques de sous-réseau (temps d'accès à la Liaison).
Le temps minimal de transfert est un des facteurs qui déterminent l'applicabilité d'un système de
communication particulier dans le cas d’une fonction ATS.
Fiabilité : Par définition, la fiabilité est la probabilité qu’un message ou un fichier
utilisateur soit correctement reçu par 1'utilisateur récepteur. La fiabilité qui fait partie de
l'ensemble de paramètres QOS est la fiabilité exigée par l'utilisateur récepteur. La fiabilité
maximale qu’un réseau est capable d'offrir est déterminée par la fiabilité de sous-réseau du plus

13
faible élément. La fiabilité nécessaire peut être rapportée, dans une certaine mesure, à la priorité
nécessaire. Une fonction ATS qui transfère des messages utilisateur d'urgence doit bénéficier
d'une plus grande priorité et d'une plus grande fiabilité qu'une fonction ATS transférant un fichier
utilisateur météorologique (MET).
Coût : Pour un certain nombre d'Applications, le coût de la communication est un
paramètre important dont il faut tenir compte. A cet égard, une Application donnée peut spécifier
un coût maximal acceptable en tant que paramètre de qualité du service. Ce paramètre peut
influencer le choix du sous-réseau à utiliser pour le transfert des données lorsqu'il en existe plus
d'un. Du point de vue du sous-réseau, le coût effectif peut être calculé de différentes façons
(communication gratuite pour certains utilisateurs, coût déterminé par le nombre de bits, coût
calculé en fonction du temps, etc.) selon le sous-réseau et l’utilisateur.

I.3.2.4. Remise des messages.

Du fait que l'on emploie les paramètres QOS et du fait des hypothèses en matière de
fonctionnement du réseau indiqué ci-dessous, l'utilisateur ne sait pas quelles méthodes
particulières de remise l'ATN utilise pour effectuer le transfert de données :
a) l'ATN peut remettre des messages de n'importe quelle longueur. Il le fait en fractionnant
et en combinant les messages selon les besoins de manière à ne pas dépasser la dimension de
transfert de données maximal utilisée par les différents sous-réseaux qui font partie de l'ATN ;
b) l’ATN remet les données de manière fiable. L'utilisateur peut supposer que, une fois que
les données sont acceptées par l’ATN, elles seront remises. L'utilisateur est mis au courant si la
remise est impossible ;
c) il est inutile que l'utilisateur indique l'itinéraire à suivre pour arriver à destination. De ce
fait, l'ATN tient des tables d’acheminement dynamiques où entre en ligne de compte l'état des
connexions à cet instant ;
d) pour accomplir ses fonctions, l'ATN n'a besoin que de l’information d’adresse, des
données utilisateur et des paramètres QOS spécifiés.

I.3.3. Principes de connexion.

I.3.3.1. Types de sous-réseaux aéronautiques.

On peut appeler architecture inter-réseaux l’environnement de transmission de données

aéronautiques représenté à la Figure I. 7. Une architecture inter-réseaux permet la plus grande
souplesse de conception, de gestion et de commande de chaque sous-réseau indépendant et permet

14
aussi à chaque sous-réseau d'être optimisé en vue de son emploi dans son propre environnement.
La seule autre solution (un seul réseau global homogène desservant tous les processus embarqués
et au sol) imposerait un degré excessif de normalisation et poserait des problèmes énormes pour sa
gestion. Dans cette figure, les sous-réseaux de communication sont représentés par des ovales, et
les processeurs d'Application que ces sous-réseaux relient sont représentes par des rectangles. On
accomplit le transfert de données entre deux utilisateurs (c'est-à-dire deux processus
d’Application) du système de réseau de données aéronautiques en réalisant l'interconnexion de ces
sous-réseaux de manière à obtenir un parcours continu entre ces utilisateurs. Le transfert de
données à travers un environnement inter-réseaux aéronautique se fait à l'aide de trois types de
sous-réseaux de transmission de données :
a) sous-réseaux avionique;
b) sous-réseaux sol; et
c) sous-réseaux air/sol.

I.3.3.2. Sous-réseaux avionique.

Chaque aéronef comporte en général un ou plusieurs sous-réseaux internes reliant les
différents processeurs nécessaires au fonctionnement des systèmes de commande de vol. Ces
sous-réseaux sont appelés «sous-réseaux avioniques». A bord des aéronefs équipés pour la
transmission de données aéronautiques, ces sous-réseaux servent à re1ier les processeurs de
transmission de données aux processeurs d'Application de l'aéronef (exemples : processeurs
d'affichage de données, processeurs de saisie de données et ordinateurs de gestion de vol). Dans le
cas le plus simple (c'est-à-dire dans le cas d'un simple sous-réseau air/sol), un processus
d'Application embarqué peut être relié directement à un processus de transmission de données
spécialisé. Lorsqu'on désire réaliser des opérations inter-réseaux, chaque processus d'Application
embarqué peut avoir accès à un ou à plusieurs processus de transmission de données, donc aux
sous-réseaux air/sol correspondants.

I.3.3.3. Sous–réseaux sol.

Les installations au sol de traitement de l'information exigent un niveau comparable de
connexions entre les divers processeurs locaux. Un sous-réseau sol fournit les connexions
nécessaires à l’intérieur d'une installation, souvent sous la forme d'un réseau local (LAN). Les
sous-réseaux sol fournissent aussi les interconnexions entre processus d’Application sol et
processus de transmission de données sol en vue de l'accès aux processus d'Application
embarqués. Dans le cas des installations des services de la circulation aérienne, les différents sous-

15
réseaux sol possèdent en général des caractéristiques Physiques et logiques différentes, bien qu’ils
servent tous à relier les divers processus d'Application sol. Ces systèmes de traitement
d'Application peuvent comprendre des processus météorologiques, des processus de contrôle
régional de la circulation aérienne, des processus de service de vol et des processus de tour de
contrôle d'aérodrome. Les installations des services de la circulation aérienne sont généralement
reliées par l'intermédiaire de sous-réseaux sol inter-installations, et, comme le montre la Figure I.
7, des sous-réseaux de données publics ou privés peuvent aussi être reliés à des sous-réseaux sol
ATS (la connexion au sous-réseau privé de données n'est pas indiquée sur la figure).

Processeur Processeur de
Processeur de d’affichage de saisie de Processeur de
gestion données données gestion

Sous réseau
avionique

Sous réseau Sous réseau à Sous réseau

VHF satellite mode S

Sous réseau sol Sous réseau sol

privé ATS

Base de données Contrôle Base de Contrôle Contrôle d’ Base de Base de

exploitation exploitation données en données données
Aérodrome
aéronautique aéronautique météo route ATS météo

Figure I. 7 : Environnement de transmission de données aéronautiques

16
I.3.3.4. Sous-réseaux air/sol.
Un sous-réseau air/sol sert à relier les utilisateurs de sous-réseaux sol aux utilisateurs de
sous-réseaux avionique. Le sous-réseau air/sol accomplit cette fonction en transférant des
messages du sous-réseau sol émetteur au sous-réseau avionique destinataire et en transférant des
messages du sous-réseau avionique émetteur au sous-réseau sol destinataire. La Figure I. 7
représente trois sous-réseaux air/sol : un sous-réseau de transmission de données mode S, un sous-
réseau de transmission de données VHF et un sous-réseau de transmission de données par satellite.
On y remarque que n'importe quel sous-réseau air/sol peut être relié à des sous-réseaux sol ATS
ainsi qu'à des sous-réseaux sol publics ou privés.

I.3.3.5. Interconnexion de sous-réseaux

Afin que les messages puissent être transférés entre les sous-réseaux sol et avionique à
travers le sous-réseau air/sol, il doit y avoir un passage clairement défini d'un sous-réseau à un
autre. Ce passage s'appelle un routeur inter-réseaux Pour relier des sous-réseaux qui sont
Physiquement, logiquement et administrativement distincts, on dispose des routeurs aux points
d’interconnexion. La Figure I. 8 indique la manière dont les sous-réseaux de la Figure I. 7 sont
reliés par des routeurs. Dans le présent document, le terme «routeur inter-réseaux» désigne
l'élément de communication qui assure la gestion de la retransmission et de l'acheminement de
paquets de données entre des sous-réseaux hétérogènes pendant que ces paquets sont en route vers
un ordinateur principal de destination.

I.3.4. Principes d'adressage.

I.3.4.1. Adressage ATN.

Le sous-réseau de communication est connu de manière, qu'en principe, deux processus
d'utilisation quelconques puissent communiquer l'un avec l'autre. De ce fait, chaque processus
d'utilisation doit avoir une adresse ATN unique. Un processus d'utilisation est identifié
uniquement par son point d'accès au service de réseau (NSAP) plus l'identité du processus.

I.3.4.2. Adressage réseau.

Le système d’adressage NSAP ATN définit une structure abstraite pour les adresses de
NSAP. Ce système définit l’information d’adressage de couche Réseau à utiliser pour
l’identification des systèmes terminaux. Il devrait satisfaire les besoins d’une variété de groupes
d’utilisateurs de données aéronautiques, y compris les services ATS. Le système d’adressage
NSAP spécifie un format hiérarchique d’adresse qui peut servir à identifier les systèmes terminaux

17
fixes comme les systèmes terminaux mobiles. Les principaux avantages du système d’adressage
NSAP devraient être les suivants :
a) englober l'information d'adressage aéronautique existante comme les indicateurs
d'emplacement ATS OACI et les codes IATA attribués aux organisations et aux emplacements;
b) être conforme aux protocoles de réseau ISO déjà normalisés;
c) le format devrait permettre d'utiliser les protocoles d'acheminement OSI.
Processeur Processeur de
Processeur de d’affichage de saisie de Processeur de
gestion données données gestion

Sous réseau
avionique

Routeur
avionique

Sous réseau Sous réseau à Sous réseau

VHF satellite mode S

Routeur Routeur
sol sol

Sous réseau sol Routeur Sous réseau sol

privé sol ATS

Base de données Contrôle Base de Contrôle Contrôle d’ Base de Base de

exploitation exploitation données en données données
Aérodrome
aéronautique aéronautique météo route ATS météo

Figure I. 8 : Interconnexion de sous-réseaux par des routeurs

18
I.3.4.3. Identification de processus.
Il est nécessaire de fournir un identificateur de processus pour compléter l'identification
d'un processus d'Application utilisateur. Cet identificateur de processus d'Application comprend
l'ensemble des éléments d'adresse relatifs aux protocoles de Transport, de Session, de Présentation
et d'Application OSI mis en oeuvre dans le système informatique utilisateur identifié par l'adresse
NSAP. Les identificateurs de processus d'Application peuvent avoir une signification locale ou
globale, la principale différence étant l'autorité responsable de l'enregistrement et de la gestion des
identificateurs. Les identificateurs de processus d'Application peuvent être publiés par les autorités
appropriées (dans un répertoire local) ou peuvent être obtenus d'un répertoire en ligne par le biais
de l'ATN.

I.3.5. Contrôle de l’accès au réseau.

L'ATN peut comporter certains sous-réseaux (par exemple le sous-réseau mode S) qui
exigent un contrôle d'accès. Ce contrôle d'accès est nécessaire aux besoins de la sécurité et de
l'intégrité de la transmission de données aéronautiques : sécurité pour ce qui est de l'accès à l'ATN
par des utilisateurs autorisés, et intégrité pour ce qui est de l'affectation des ressources (par
exemple le débit) entre les utilisateurs autorisés.
L'ATN permet d'appliquer le contrôle de sécurité et d'intégrité dans le routeur inter-réseaux
et les mécanismes d'accès aux sous-réseaux Les décisions relatives à la sécurité sont fondées sur
l'authentification des adresses réseau pour les Applications autorisées à échanger des messages sur
l'ATN. L'affectation des ressources (c'est-à-dire le contrôle d'intégrité) se fait d'après la priorité de
message sélectionnée par l'Application. Pour cette raison, le mécanisme des priorités doit
s'appliquer à toutes les Applications de l'ATN.

19
Chapitre II : ARCHITECTURE DU RÉSEAU DE TÉLÉCOMMUNICATION
AÉRONAUTIQUE (ATN).

II.1. Introduction. [1] [2] [3] [6] [7] [8]

L'architecture de protocole du réseau de télécommunication aéronautique (ATNPA) est

une mise en oeuvre de l'architecture de protocole ISO (ISOPA) dans l'environnement de
transmission de données aéronautiques. Cette architecture comprend les besoins de service, de
protocole et d'adressage dont on a besoin pour participer à l'environnement inter-réseaux
aéronautique. L'ATNPA définit en outre le niveau nécessaire de conformité à ces besoins.

L'ATNPA a pour principal objet d'assurer des communications interprocessus inter-

opérables parmi les ordinateurs hôtes aéronautiques à bord des aéronefs comme au sol; ces
communications interprocessus peuvent avoir lieu parmi les ordinateurs hôtes interconnectés avec
une combinaison quelconque de sous-réseaux avionique et de communications air/sol.
L’architecture de protocole ATN définit les besoins en réseaux de communication, en routeurs
inter-réseaux et en ensembles de protocoles pour ordinateurs hôtes, qu'il faut mettre en oeuvre
pour atteindre ce niveau d'interopérabilité aéronautique.

II.2. Caractéristiques d'une architecture inter-réseaux [1] [2] [3] [6] [7] [8]

Pour que l'on puisse tirer profit d'une architecture inter-réseaux, les techniques de transfert
de messages entre les sous-réseaux participants doivent être indépendantes des protocoles et des
systèmes d'adressage propres à un sous-réseau participant quelconque. Cela signifie que tous les
sous-réseaux participants doivent être interconnectés au moyen de routeurs inter-réseaux
conformes aux conventions et aux normes communes d'interconnexion de réseaux. Les conditions
à remplir par ces sous-réseaux et leurs routeurs d'interconnexion peuvent se résumer comme suit :

a) tous les routeurs participants doivent utiliser une norme commune d’adressage de réseau
global, de protocole inter-réseaux, y compris une définition commune des paramètres de qualité de
service ;

b) tous les routeurs participants doivent échanger une information d'acheminement en se

conformant à une norme commune de protocole d'échange d'information d'acheminement ;

c) tous les sous-réseaux interconnectés doivent acheminer le protocole inter-réseaux, le

protocole d'acheminement adjacents de manière transparente.

20
 Une norme commune de protocole inter-réseaux, accompagnée d'un plan commun
d'adressage et d'acheminement inter-réseaux, fournit une interface indépendante des réseaux pour
tous les utilisateurs inter-réseaux

II.3. Aperçu de l’architecture de protocole ISO. [1] [2] [3] [7] [8] [9]

II.3.1. Généralités

L’architecture de protoco1e ISO (ISOPA) a pour but de permettre l'interconnexion des

systèmes de transmission de données hétérogènes de manière que l'on puisse réaliser un échange
fiab1e de messages sans se préoccuper de la mise en oeuvre des réseaux et des supports Physiques
que traversent les messages. On atteint cet objectif en structurant 1es systèmes de transmission de
données interconnectés de manière à ce que les messages traversent des couches de protocole
hiérarchiques entre lesquelles i1 existe des interfaces bien définies. Chaque couche à l'intérieur
d'un système de communication émetteur accomplit une fonction qui est également accomp1ie à
l'intérieur de la couche homologue dans le système de communication de destination. Les
différences qui existent dans les mises en oeuvre de protocoles et de supports à l'intérieur des
systèmes communicant sont ainsi «masquées» par des interfaces normalisées, ce qui permet
l'interconnexion de ces systèmes.

Le modèle de référence OSI de l'ISO définit sept couches fonctionnelles dont les fonctions
s'étendent de la commande du transfert de données sur les supports Physiques (radio, fils, fibres
optiques, etc.) à la commande de l'interface de l'utilisateur de l'Application. Dans chaque couche
sont effectuées des opérations bien définies conçues de manière à minimiser la circulation de
commandes et d'informations à travers les limites de couche. Ces sept couches sont les couches
Physique, Liaison de données, Réseau, Transport, Session, Présentation et Application. Pour
accomplir sa fonction, chaque couche peut ajouter des champs d’information de commande de
protocole à l'unité de données de service communiquée par la couche supérieure. Cependant,
chaque couche laisse intacte l'information de commande ajoutée par les couches précédentes, en la
traitant, sans altération, de la même façon que les données à transférer. La Figure II.1 montre
l'organisation des sept couches d'architecture de protocole ISO en indiquant à titre d’illustration
l’environnement inter-réseaux aéronautiques (réseau avionique, réseau air/sol et réseau sol).

21
 Processus Processus
d’application d’application

Application Application
Point d’accès au service de réseau
Présentation Présentation

Session Session
Point de raccordement au sous réseau
Transport Transport
Gestion couche réseau Gestion couche réseau
Retransmission/Acheminement Retransmission/Acheminement
IP/RP IP/RP IP/RP IP/RP
IP/RP IP/RP

SNDCP SNDCP SNDCP SNDCP SNDCP SNDCP

Couche
Avionique Avionique Air-sol Air-sol sol sol
réseau

SNAcP SNAcP SNAcP SNAcP SNAcP SNAcP

Avionique Avionique Avionique Avionique Avionique Avionique

Liaison de Liaison de Liaison de Liaison de Liaison de Liaison de

données données données données données données

Physique Physique Physique Physique Physique Physique

Sous réseau avionique Sous réseau mobile Sous réseau sol

Ordinateur hôte ATN Routeur ATN Routeur ATN Ordinateur hôte

ATN
Légende : Protocole Inter réseaux (IP)
Protocole de convergence dépendant du sous réseau (SNDCP)
Protocole d’accès au sous réseau (SNAcP)
Protocole d’échange d’information d’acheminement (RP)
Figure II. 1: Architecture de protocole ISO

II.3.2. Couches inférieures.

Les couches inférieures ISOPA comprennent la couche Physique, la couche Liaison de
données et la couche Réseau. Ces couches forment la partie de l'architecture de protocole ISO qui
dépend des réseaux et fournissent une interface de service indépendante des Applications à la
limite entre la couche Réseau et la couche Transport. L'ISOPA exige la Présentation d'un niveau
uniforme de service de réseau à tous les processus de la couche Transport à cette limite; il faut
donc qu'une seule interface de service de couche Réseau (protocole inter-réseaux) soit adoptée
dans tout un domaine donné.

22
 La couche Physique commande l'accès au support de transmission qui forme la base du
système de communication. La couche Liaison de données assure la gestion des opérations de la
couche Physique, et peut utiliser des techniques spéciales de détection des erreurs ou de
retransmission afin que les taux d'erreurs soient acceptables. La couche Réseau assure la gestion
de la couche Liaison de données afin de transférer des données entre les entités de la couche
Transport en fonction de l'information d'adresse mondiale et de qualité du service. La couche
Réseau prend des décisions au sujet de l'acheminement lorsqu'il existe des possibilités redondantes
de connexion de Liaison de données et fractionne ou rassemble des unités de données comme
l'exigent les techniques de Liaison de données sous-jacentes. Comme l'indique la Figure II.1, la
couche Réseau se compose de plusieurs sous-couches. L'organisation interne de la couche Réseau
est examinée de manière plus détaillée en II.5.

II.3.3. Couches supérieures.

Les couches supérieures ISOPA sont les couches Session, Présentation et Application.
Elles forment la partie de l'architecture de protocole ISO qui dépend des Applications et
fournissent une interface de service indépendante du réseau à la limite entre les couches Transport
et Session.

La couche Session établit une relation entre deux entités utilisateur pour gérer un flux
continu de données. La couche Présentation détermine le format et l'allure des données transférées
à destination et en provenance de la couche Application, en accomplissant généralement des
fonctions telles que le codage et la compression de données. La couche Application commande
l'accès du processus d'Application au système de communication, en offrant une interface de
communication qui optimise le fonctionnement de ce processus. Exemples d'entités de la couche
Application : protocoles de transfert de fichiers, protocoles de courrier électronique et protocoles
de terminal virtuel.

II.3.4. Couche Transport.

La couche Transport offre un service fiable de transfert de données de bout en bout entre
utilisateurs des couches supérieures du service de réseau ISO et peut être mise en oeuvre soit en
mode connexion, soit en mode sans connexion. Elle comble le vide entre l'indépendance des
protocoles des couches supérieures (Application, Présentation et Session) à l'égard du réseau et
l'indépendance des protocoles des couches inférieures (Réseau, Liaison de données et Physique) à
l'égard de l'Application. La couche Transport est la couche OSI la plus basse mise en oeuvre

23
uniquement à l'intérieur des ordinateurs hôtes, et on peut la considérer comme une interface entre
les processus de l’ordinateur hôte et l'environnement inter-réseaux

II.4. Orientation des services de communication au point de vue connexion. [1] [2] [3] [7] [8]
Les services de communication, dans l'une quelconque des sept couches ISOPA, peuvent
se distinguer d'une manière générale selon qu'ils utilisent l'une ou l'autre de deux techniques de
transfert d’unités de données de service parmi les processus en communication. Ces techniques
s'appellent service en mode sans connexion (CL) et service en mode connexion (CO).
En mode sans connexion, chaque unité de données de protocole (PDU) est transférée entre
utilisateurs sans association implicite parmi les différentes PDU nécessaires au transfert du
message de l'utilisateur. Chaque PDU renferme un champ information de commande de protocole
(PCI) (y compris les adresses de l'entité d'origine et de l'entité de destination et les paramètres de
qualité du service) et l'unité de données de service de couche supérieure (SDU) (c'est-à-dire le
contenu d'information) à transférer.
En mode connexion, une relation est établie entre processus en communication en vue de
l'association logique de la suite de PDU contenant chaque message interprocessus. De ce fait, il
faut un transfert d'adresses d'origine et de destination et de paramètres QOS pour établir une
connexion. Pour le transfert des PDU de données, on utilise alors l'identificateur de connexion au
lieu des adresses et des paramètres QOS qui doivent figurer dans le champ PCI en mode sans
connexion. On peut mettre fin à la connexion à un moment quelconque en transférant une PDU de
gestion demandant la «déconnexion». Il faut en général une moindre largeur de bande de réseau
pour une Session continue de communication d'égal à égal en mode connexion qu'en mode sans
connexion, car l'information d'adresse et QOS n'est transférée qu'une fois par connexion. Par
ailleurs, le fonctionnement en mode connexion nécessite une plus grande complexité à l'intérieur
des noeuds de communication, puisque chaque noeud servant à une connexion doit conserver
l'information d'adresse et QOS transférée au moment de l'établissement de la connexion et
spécifier des variables d'état indiquant l'état relatif du train de paquets pour cette connexion.

II.5. Organisation de la couche Réseau. [1] [2] [3] [7] [8]

La Couche Réseau ISO doit fournir une interface de service uniforme pour le transfert de
données parmi les systèmes terminaux (ES) et les systèmes intermédiaires (IS) utilisant
l'architecture de protocole ISO. Afin qu'elle puisse jouer ce rôle global tout en se conformant aux
exigences de protocoles différents de réseaux et systèmes réels locaux qui servent à assurer le
service de réseau, les normes ISO définissent plusieurs sous-couches à l'intérieur de la couche

24
Réseau ISO. Ces sous-couches s'appellent sous-couche de convergence dépendante du sous-
réseau, sous-couche de convergence indépendante du sous-réseau et sous-couche d'accès au sous-
réseau. L’existence de ces sous-couches confirme l'idée qu’une interface de service de réseau
uniforme est de la plus haute importance pour l'interconnexion de réseaux de systèmes
informatiques, la diversité des supports et des environnements locaux nécessite souvent différentes
techniques d’interconnexion.
La sous-couche d'accès au sous-réseau comprend le protocole d'accès au sous-réseau
(SNAcP) qui fournit le mécanisme d'accès au protocole pour le transfert de données entre noeuds
de communication adjacents sur une Liaison de données en particulier. Comme le montre la
Figure II.1, la sous-couche de convergence indépendante du sous-réseau consiste en un protocole
inter-réseaux (IP), des protocoles d'acheminement (RP), des protocoles de gestion et une fonction
de retransmission. La sous-couche inter-réseaux accomplit les fonctions de retransmission et
d'acheminement dans toute l'étendue des sous-réseaux réels qui constituent un environnement
inter-réseaux global.
Ensemble, ces deux sous-couches fournissent l'interface uniforme de service de réseau ISO
aux processus de la couche Transport ISO. Si le protocole inter-réseaux ne peut pas fonctionner
directement avec le SNAcP disponible, un protocole de convergence dépendant du sous-réseau
(SNDCP) s'impose. Selon les choix qui seront faits en matière de mise en oeuvre, ce protocole
peut être associé soit avec le processus d'accès au sous-réseau, soit avec le processus de protocole
inter-réseaux
Comme l'indique la Figure II.1, un système constitué uniquement des trois couches de
protocole inférieures est appelé un système intermédiaire (IS). Cette structure est typique d’une
passerelle ou d’un système de retransmission. Par contre, un système terminal (ES) contient les
sept couches de protocole. Bien que des fonctions d’acheminement existent dans la couche Réseau
d’un système terminal, il a pour rôle principal de prendre en charge les processus d'Application de
l'utilisateur.

II.6. Accès au service de couche Réseau [1] [2] [3] [7] [8]
La Figure II.1 montre deux points d'accès aux services de réseau de données. Un point
d'accès au service de réseau (NSAP) est un point d'accès global ou de bout en bout; il indique le
point où un service de réseau en mode sans connexion ATN est fourni à l'utilisateur du service de
réseau ATN (c'est-à-dire le protocole de Transport). Un NSAP est associé au service fourni par le
protocole inter-réseaux (IP) ATN à l'intérieur d'un système terminal en particulier. Un point de

25
raccordement au sous-réseau (SNPA) est un point d'accès d'un sous-réseau constituant particulier;
il indique le point de fourniture d'un service de sous-réseau à l'ensemble des protocoles inter-
réseaux ATN (c'est-à-dire les protocoles IP et de gestion/acheminement ATN). Un SNPA est
associé à un service local fourni à un routeur ou à un système terminal par un protocole particulier
d'accès au sous-réseau

II.7. Protocoles inter-réseaux ATN. [1] [2] [3] [7] [8]

L’entité inter-réseaux ATN comprend un certain nombre de routeurs et de sous-réseaux
constituants ATN interconnectés qui assurent la transmission de données entre des ordinateurs
hôtes exploitant les protocoles inter-réseaux ATN. Les protocoles inter-réseaux ATN fonctionnent
à l'intérieur de la couche 3 OSI ISO, soit la couche Réseau. Cet ensemble de protocoles comprend
le protocole inter-réseaux (IP) ISO 8473, le protocole d'échange d'information d'acheminement
intra-domaine entre systèmes intermédiaires (IS-IS) ISO 10589 et le protocole routeur/ordinateur
hôte de système terminal à système intermédiaire (ES-IS) ISO 9542. On considère aussi que
certains protocoles d'échange d'information d’acheminement intra-domaine et certains protocoles
de maintenance et d'exploitation de réseau font partie de l'ensemble de protocoles inter-réseaux
ATN.
Toutes les unités de données du protocole réseau (NPDU) (c'est-à-dire les paquets) de
l’entité inter-réseaux ATN sont encapsulées dans les unités de données de protocole de sous-
réseau appropriées afin d'en permettre le transfert entre les entités de réseau ATN. Chaque en-tête
de protocole inter-réseaux ATN contient un code d'identification unique qui permet au routeur ou
à l’ordinateur hôte ATN de réception de traiter correctement l’en-tête de protocole et toute autre
donnée correspondante. De plus, étant donné que tous les protocoles inter-réseaux ATN sont sans
connexion, toute information nécessaire pour traiter une NPDU en particulier est insérée dans
l’en-tête de cette NPDU.
Le rôle de la couche Transport OSI ISO est d'assurer le transfert fiable de données de bout
en bout; tout protocole de Transport exploité dans un environnement ATN doit pouvoir
fonctionner correctement avec le service de réseau sans connexion OSI ISO fourni par l'entité
inter-réseaux ATN.

II.7.1. Protocole inter-réseaux

Le protocole inter-réseaux (ISO 8473) fournit le mécanisme de base pour le Transport de
bout en bout des données ATN. Ce protocole permet l'adressage global, la spécification de la
qualité de service, le contrôle de l'encombrement ainsi que la segmentation et le réassemblage des

26
paquets de données. L'IP comporte en outre la possibilité d'effectuer des diagnostics comme
l'enregistrement d'acheminement et la signalisation d'erreurs de bout en bout.

II.7.2. Protocole d'échange d'information d'acheminement intra-domaine

Le protocole d'échange d'information d'acheminement intra-domaine IS-IS (ISO 10589)
fournit un mécanisme d'échange d'information sur la connectivité et la topologie entre les routeurs
ATN à l'intérieur d'un domaine administratif. Ce protocole prend en charge la configuration
dynamique des tables d'acheminement inter-réseaux ATN pour chaque domaine, sans qu'il soit
nécessaire d'introduire manuellement les changements concernant la topologie ou la disponibilité
des routeurs de l'entité inter-réseaux ATN.

II.7.3. Protocole d'acheminement de système terminal à système intermédiaire (ES-IS).

Le protocole ordinateur hôte/routeur de système terminal (ES) à système intermédiaire (IS)
(ISO 9542) fournit un mécanisme qui permet aux ordinateurs hôtes (systèmes terminaux) et aux
routeurs (systèmes intermédiaires) ATN d'échanger des informations sur la connectivité à
l'intérieur d'un sous-réseau local. Ce protocole sert de complément au protocole d'acheminement
IS-IS afin de permettre la reconfiguration dynamique des tables de données d'acheminement
locales, sans qu'il soit nécessaire d'introduire manuellement les changements concernant la
disponibilité des ordinateurs hôtes.

II.7.4. Protocole d'échange d'information d'acheminement inter-domaines.

Le protocole d'acheminement inter-domaines (IDRP) de l'ISO permet d'échanger des
données d'acheminement à travers les limites des domaines d'acheminement. L’acheminement
inter-domaines ATN est réalisé par des systèmes intermédiaires de la couche limite au moyen
d'informations d'acheminement et de topologie obtenue dynamiquement. Une des caractéristiques
fondamentales de l'architecture ATN est la possibilité d'acheminement entre routeurs air et
routeurs sol.

II.7.5. Protocoles de gestion de couche Réseau.

L'architecture ATN prévoit la mise en oeuvre de protocoles de gestion de couche Réseau
(NLM). Les protocoles NLM prennent en charge les processus NLM responsables des bases de
données d'exploitation et de maintenance de la couche Réseau situées dans les systèmes terminaux
et les systèmes intermédiaires repartis dans toute l'entité inter-réseaux ATN. La gestion de la
couche Réseau ATN est réalisée conformément aux accords locaux ou régionaux et elle est mise

27
en oeuvre au moyen d'informations introduites manuellement ou d'informations Transportées par
les paquets de données IP ATN entre les processus de gestion de la couche Réseau.

II.8. Sous-réseaux constituants. [1] [2] [3] [6] [7] [8] [10]

II.8.1. Généralités.
Les sous-réseaux constituants sont les sous-réseaux qui interconnectent les routeurs ATN
et les ordinateurs hôtes dans le but de Transporter les protocoles inter-réseaux ATN parmi ces
routeurs et ces ordinateurs hôtes. L’architecture inter-réseaux ATN est conçue pour permettre
l'emploi de toute technologie de sous-réseau capable d'effectuer la remise des données
indépendamment des codes et des octets comme un réseau constituant. La caractéristique la plus
importante qu'on exige des sous-réseaux constituants est qu'ils doivent fournir au minimum un
service de sous-réseau en mode sans connexion. Bien que seul le service sans connexion soit
exigé, il est possible d’utiliser un sous-réseau en mode connexion en mettant en oeuvre la fonction
de convergence appropriée. Les sous-réseaux constituants peuvent être divisés en trois catégories
principales :
a) sous-réseaux à topologie générale;
b) sous-réseaux de diffusion:
c) sous-réseaux mobiles.
Ces sous-réseaux constituants peuvent communiquer des unités de données de protocole
réseau (NPDU), créées par n'importe lequel des protocoles inter-réseaux ATN, en double ou
erronées ou ne pas les communiquer. Ceci ne constitue aucune difficulté pour les protocoles inter-
réseaux ATN; cependant, certains protocoles de Transport et de couche supérieure peuvent exiger
l'établissement de critères minimaux raisonnables pour un sous-réseau qui doit prendre en charge
des routeurs et des ordinateurs hôtes ATN. Ces critères limitent généralement la proportion de
paquets perdus par rapport au nombre de paquets remis et la répartition des délais nécessaires pour
la réception des paquets hors séquence. Les ordinateurs hôtes et les routeurs ATN peuvent utiliser
des sous-réseaux dont les performances naturelles sont à l'extérieur de ces limites pourvu qu'il soit
possible d'appliquer des mécanismes de protocole supplémentaires qui permettent de maintenir le
service de sous-réseau présent à l'entité inter-réseaux ATN à l'intérieur des limites spécifiées.
L'architecture de protocole ATN permet d'avoir recours à n'importe quelle combinaison
raisonnable de ces types de sous-réseaux pour construire un trajet de bout en bout entre deux
ordinateurs hôtes communicant dans ce cas, les routeurs ATN intermédiaires pertinents effectuent

28
la conversion d’adresse de sous-réseau et de protocole d’accès au sous-réseau nécessaire pour
transmettre les paquets.

II.8.2. Sous-réseaux à topologie générale ou réseaux longue distance (WAN).

Les sous-réseaux à topologie générale (appelés réseaux longue distance ou WAN) sont
souvent utilisés pour interconnecter des routeurs et des ordinateurs hôtes séparés
géographiquement. Ces sous-réseaux peuvent être des entités complexes de commutation de
paquets ou de simples lignes point à point spécialisées. Cette catégorie comprend souvent les
réseaux publics de transmission de données exploités selon le protocole d'accès X.25 du CCITT;
les réseaux privés de transmission de données exploités selon les normes du réseau commun
OACI d'échange de données (CIDIN) se classent également dans cette catégorie. Une des
principales caractéristiques des sous-réseaux à topologie générale est que le coût et la difficulté de
transmission d'un paquet à plusieurs adresses simultanément sont élevés par rapport à ceux des
réseaux de diffusion. On entend par «coût» plus que de simples mesures économiques. Par
exemple, il est vrai qu'on peut diffuser un paquet sur un sous-réseau X.25 en envoyant tour à tour
une copie de ce paquet à chacune des adresses d'un groupe d'adresses; dans ce cas, toutefois, les
appels répétés de protocole occuperaient une plus grande partie des ressources de sous-réseau que
dans le cas d’un sous-réseau dont les supports peuvent prendre en charge une vraie technologie de
diffusion de paquets.

II.8.3. Sous-réseaux de diffusion ou réseaux locaux (LAN).

Les sous-réseaux de diffusion (appelés réseaux locaux ou LAN) servent souvent à
interconnecter des routeurs ou des ordinateurs hôtes à l'intérieur d'une région géographique réduite
et comportent des supports qui offrent des débits de données élevés et des délais relativement
courts. Les sous-réseaux de diffusion ont habituellement une structure en bus, en étoile ou en
anneau et, comme leur nom le suggère, utilisent des mécanismes simples pour transmettre des
paquets simultanément à plusieurs adresses locales à des coûts relativement peu élevés par rapport
à ceux des sous-réseaux à topologie générale.

II.8.4. Sous-réseaux mobiles.

Bien qu'il soit généralement possible de les classer dans la catégorie des sous-réseaux de
diffusion ou des sous-réseaux à topologie générale, les sous-réseaux mobiles de l'entité inter-
réseaux ATN sont traités dans une catégorie à part pour des raisons d'efficacité de protocole. Ces
sous-réseaux comportent habituellement des supports de transmission à rayonnement libre (radio

29
VHF ou UHF, satellite dans la bande L ou radar secondaire de surveillance dans la bande L) plutôt
que des supports à «confinement» comme les fils ou les câbles coaxiaux; ils sont donc capables de
diffuser dans le vrai sens du terme. Par ailleurs, la largeur de bande disponible des supports a
tendance à être extrêmement restrictive, ce qui entraîne l'utilisation de protocoles conservateurs au
niveau de la largeur de bande comme c'est souvent le cas dans les sous-réseaux à topologie
générale. Par conséquent, bien que les sous-réseaux mobiles soient traités comme des sous-
réseaux de diffusion en ce qui concerne la couverture des supports de transmission, il peut être
nécessaire d’avoir recours à des protocoles d'accès au sous-réseau en mode connexion afin
d’utiliser efficacement la largeur de bande des supports.

II.9. Routeurs ATN. [1] [2] [3] [4] [6] [7] [8] [10] [11]

Les sous-réseaux constituants de l'entité inter-réseaux ATN sont interconnectés par des
routeurs ATN. Chaque routeur ATN est raccordé à un minimum de deux sous-réseaux et chaque
sous-réseau le considère comme une entité adressable localement à l'intérieur du sous-réseau Les
routeurs ATN enchaînent les Liaisons de sous-réseau pour créer un trajet de bout en bout qui
permet de transmettre les paquets IP ATN entre des ordinateurs hôtes ATN communicants.

Application
Système terminal opérationnelle

Aéronef Routeur ATN embarqué

Sous réseaux air-sol Réseau sol

Routeur ATN air-sol Routeur ATN sol-sol Routeur ATN sol-sol

Système
terminal Console CM Console Système terminal
(ES) (ES)
Equipement du Contrôle de la Communications du contrôle
circulation aérienne d’exploitation aéronautiques
AOC

Figure II. 2: Environnement de communication avec des routeurs

30
II.9.1. Rôle du routeur.
Les routeurs ATN performent les fonctions de transmission de données et de routage pour
les paquets de données du protocole CLNP.

Backbone du
pays B BIS #4
Equipement Equipement
ATS BIS #1 ATS BIS #5

Backbone du Backbone du
pays A BIS #2 pays C BIS #3

Système terminal Système terminal

ES #1 ES #2

Itinéraire le plus court : ES#1 BIS#1 BIS#2 BIS#3

BIS#5 ES#2
Figure II. 3 : Choix du chemin le plus court après concertation entre routeurs

La transmission d’un paquet IP ATN exige que chaque routeur de transmission choisisse le
routeur de l’étape suivante ou, s'il s'agit de la dernière étape, qu'il choisisse l'ordinateur hôte de
destination. Ces choix se font habituellement en fonction de critères de connectivité et de qualité
de service (QOS), mais ils reposent aussi sur la probabilité que chaque étape choisie aura pour
résultat de rapprocher le paquet IP ATN de sa destination finale. Pour l'IP ATN, la QOS demandée
par l'utilisateur du service de réseau est une mesure relative (c'est-à-dire qualitative) comprenant
quatre éléments :
a) le débit ;
b) le temps de transit;
c) la probabilité d'erreurs résiduelles;
d) le coût

31
 Dès l’indisponibilité du tronçon entre le BIS#2 et le BIS#3, le trafic venant du ES#1 vers ES#2
est dérouté à travers le BIS#4

Backbone du
pays B BIS #4

Equipement Equipement
ATS BIS #1 ATS BIS #5

Backbone du Backbone du
pays A BIS #2 pays C BIS #3

Système terminal Système terminal

ES #1 ES #2
Figure II. 4 : Détection automatique des failles dans le réseau et déroutage du trafic

L'utilisateur du service de réseau peut indiquer explicitement l'importance relative du

temps de transit, de la probabilité d'erreurs résiduelles et du coût; en l'absence d'indication
explicite, le routeur ATN essaie d'optimiser le débit offert à l'utilisateur du service de réseau en
minimisant la longueur de ses files d'attente de sortie.
L'entité inter-réseaux ATN utilise des procédures d'acheminement adaptatives en mode
reparti; cette méthode permet à chaque routeur ATN de déterminer la topologie de l’entité inter-
réseaux ATN sans qu'il ait à dépendre d'une base de données d'acheminement centrale et sans qu'il
soit nécessaire de distribuer cette base de données en mode synchrone dans toute l'entité inter-
réseaux ATN. Elle permet, en outre, à chaque routeur ATN de s'adapter aux changements
topologiques de l'entité inter-réseaux ATN de façon relativement rapide par comparaison à une
méthode centralisée plus traditionnelle. La topologie actuelle de l'entité inter-réseaux ATN est
consignée dans la base d'information d'acheminement (RIB) contenue dans chaque routeur ATN.
Cette RIB est initialisée et mise à jour dynamiquement au moyen des protocoles ATN d'échange
d'information d'acheminement IS-IS et ES-IS. Le routeur ATN réduit encore la RIB à une base
d'information de transmission (FIB) qui contient un ensemble de trajets de transmission définis en
fonction des différentes règles et QOS qui peuvent être utilisées pour atteindre chaque destination
connue. Grâce au service de réseau en mode sans connexion (CLNS) fourni par l'entité inter-

32
réseaux ATN, il est possible d'obtenir une fonction d'acheminement dynamique robuste et flexible;
étant donné qu'ils transmettent les paquets IP ATN en mode sans connexion, les routeurs
minimisent l'information d'état nécessaire pour fournir le service inter-réseaux ATN.

II.9.2. Echange d’informations de routage.

Un routeur ATN doit pouvoir échanger des informations de routage avec des systèmes
adjacents en utilisant les protocoles de routage : IDRP, IS-IS et ES-IS.
Le protocole IDRP ：Utilisé pour l’échange des informations de routage entre des routeurs
connectés appartenant à des domaines différents.
Le protocole IS-IS ：Utilisé pour l’échange des informations de routage entre des routeurs
connectés appartenant au même domaine.
Le protocole ES-IS ：Utilisé pour l’échange des informations de routage entre routeurs et
systèmes terminaux.

Figure II. 4: Echange d’informations de routage

II.10. Structure des domaines de l'entité inter-réseaux ATN. [1] [2] [3]
Le domaine commun ATN est constitué des ordinateurs hôtes et des routeurs ATN
interconnectés, administrés par les autorités internationales en vue de la communication de
données aéronautiques. Il comprend tous les utilisateurs de service de transmission de données
associés à l'aviation civile internationale.

II.10.1. Domaines administratifs ATN.

Les services d'Application des utilisateurs, ainsi que les sous-réseaux de données qui
desservent ces utilisateurs, peuvent être exploités par des autorités gouvernementales ou par des
fournisseurs de services publics et privés. Le domaine commun ATN est divisé en domaines

33
administratifs ATN en fonction de ces limites administratives, dans le but de faciliter et
d'optimiser l'acheminement du trafic de données. Les domaines administratifs ATN sont gérés par
des fournisseurs et des utilisateurs de services gouvernementaux et de services aéronautiques et
sont définis en accord avec les limites administratives. La Figure II.5 montre trois domaines
administratifs ATN; les limites des domaines sont représentées par un ovale en pointillé. Cette
structure d'acheminement permet de maintenir le contrôle local à l'intérieur des administrations
actuelles.

II.10.2. Domaines d'acheminement ATN.

Les domaines administratifs ATN peuvent être divisés en domaines d'acheminement ATN.
Les domaines d'acheminement ATN sont crées par l'autorité exploitante d'un domaine
administratif ATN lorsque ce domaine administratif est suffisamment ample pour justifier une
hiérarchie interne afin d'optimiser l'échange de données et d'information d'acheminement à
l'intérieur de ce domaine administratif. Bien que la division en domaines administratifs ATN soit
un élément obligatoire de l'entité inter-réseaux ATN, la création de domaines d'acheminement
ATN relève de chaque domaine administratif et n'est pas visible à l'extérieur du domaine
administratif. Les trois domaines administratifs de la Figure II.5 pourraient, au besoin, être
subdivisés en domaines d'acheminement. Si une administration décide de ne pas diviser son
domaine administratif en domaines d'acheminement, le domaine administratif est perçu comme un
domaine d'acheminement unique.

II.10.3. Zones d'acheminement.

On peut encore subdiviser les domaines d'acheminement ATN en zones d'acheminement

ATN. Les zones d'acheminement ATN sont créées par l'autorité exploitante d'un domaine
d'acheminement ATN lorsque ce domaine d’acheminement est suffisamment ample pour justifier
une hiérarchie interne afin d’optimiser l'échange de données et d'information d'acheminement à
l'intérieur de ce domaine d'acheminement. Comme dans le cas des domaines d'acheminement
ATN, la création des zones d'acheminement relève de chaque domaine d'acheminement et n'est
pas visible à l'extérieur du domaine d'acheminement. Si une administration décide de ne pas
subdiviser son domaine d'acheminement en zones d'acheminement, le domaine d'acheminement
est perçu comme une zone d'acheminement unique.

34
 ATC Vers d’autres
WX AAC domaines
AOC
Domaine
d’aéronef

Domaine des
Vers d’autres fournisseurs des
domaines services de
communications
aéronautiques
AAC AOC

WX AAC

WX AOC

ATC ATC
Vers d’autres
utilisateurs
ATC
WX

Domaine des fournisseurs ATC AAC

des services de la
circulation aérienne

WX AOC
Domaine des
exploitants
d’aéronefs (par
ex. compagnies
aériennes)
Vers d’autres
domaines AAC

AOC
Vers d’autres
domaines

Légende : Routeur intra-domaine

Routeur inter-domaines
Ordinateur hôte (système terminal)
Domaine
Liaison fixe intra-domaine
Liaison fixe inter-domaines
Liaison mobile inter-domaines

Figure II. 5: Architecture d’acheminement

II.10.4. Domaines de sous-réseau

Un domaine de sous-réseau définit un ensemble de systèmes terminaux (ES) et de

systèmes intermédiaires (IS) participant à l'ATN et raccordés à un seul sous-réseau. Les domaines

35
de sous-réseau comprennent les sous-réseaux publics et privés, les réseaux locaux (LAN) ou les
réseaux longue distance (WAN) ainsi que les sous-réseaux sol, avioniques ou mobiles. Les
domaines de sous-réseau définissent les limites d'exploitation et de contrôle pour les fournisseurs
de services de sous-réseau et n'ont pas de rapport avec les domaines d'acheminement et
administratifs inter-réseaux ATN.

II.11. Adresse inter-réseaux ATN. [1] [2] [3]

On utilise trois catégories d'adresses pour les opérations de la couche Réseau à l'intérieur
de l'entité inter-réseaux ATN. L'adresse NSAP ATN est une adresse inter-réseaux globale utilisée
par le protocole inter-réseaux ATN. L’adresse SNPA est une adresse locale utilisée par le
protocole d'accès au sous-réseau pour transférer des données entre les éléments constituants ATN
connectés par un seul sous-réseau Le titre d'entité de réseau (NET) ATN est l'adresse d'une entité
de réseau et il est dérivé de l’adresse NSAP. Les adresses NSAP ATN ainsi que la syntaxe et la
sémantique NET sont définies dans le pressent mémoire, mais les adresses SNAP sont considérées
comme des questions locales.

II.11.1. Adresses inter-réseaux locaux.

Le format de l'adresse NSAP ATN correspond à l'indicateur de code international (ICD)

ISO et comprend une partie spécifique au domaine (DSP) à codage binaire conforme à la norme
ISO 83481/AD2. Cette structure, représentée à la Figure II.6, est hiérarchisée afin de permettre
l'acheminement inter-réseaux multi-niveaux. Cette structure hiérarchique permet aussi le
masquage d'adresse au niveau du champ afin de minimiser la quantité de trafic de gestion
d'acheminement qui doit passer par les routeurs de la couche Réseau. En plus des champs qui
assurent l'acheminement multi-niveaux, chaque adresse NSAP comprend un champ unique qui
identifie l'utilisateur des services de la couche Réseau qui est soit récepteur, soit émetteur, d'un
paquet. Ce champ, désigné par l'expression «sélecteur NSAP» dans la Figure II.6, peut être
considéré comme une adresse de processus à l'intérieur de l'ordinateur hôte identifié par les
champs adresse de zone et indicateur NSAP.

II.11.2. Titres d'entité de réseau.

Le NET ATN est l'adresse d'un routeur ATN ou d'une entité de réseau d'ordinateur hôte. Le
NET ATN est dérivé de la structure NSAP ATN en omettant l'interprétation du champ sélecteur
NSAP. Cette structure NET permet aussi le masquage sé1ectif des champs, ce qui permet

36
d'optimiser encore plus le trafic de gestion d’acheminement dans un environnement où 1es
adresses NSAP sont attribuées à l’intérieur d’une hiérarchie optimale.

Adresse de point d’accès au service de réseau (NSAP)

Partie initiale
du domaine Partie spécifique au domaine

IDP DOMAINE ZONE LOC ID SEL

Acheminement Acheminement
Niveau 2 Niveau 1
IS-IS IS-IS
Acheminement
inter-domaines

Titre d’entité de réseau (NET)

Sélecteur
IDP : Partie initiale du domaine NSAP
DOMAINE : Identificateur de domaine
ZONE LOC : Identificateur de zone locale
ID : Identificateur de système
SEL : Sélecteur NSAP

Figure II. 6: Structure d’adresse NSAP ATN

II.11.3. Adresses de sous-réseau locales.

L’adresse SNPA est l'adresse locale d'une entité de réseau ATN à l'intérieur d'un sous-
réseau particulier. La forme et le contenu des adresses SNPA varient généralement en fonction du
protocole d'accès au sous-réseau choisi; ces adresses n'ont aucune signification à l’extérieur du
sous-réseau local.

II.11.4. Utilisation d'adresses pour l'acheminement inter-réseaux

Les ordinateurs hôtes et les routeurs ATN utilisent à la fois les adresses NSAP et SNPA
pendant le processus d'acheminement des NPDU à travers le domaine aéronautique; ils exécutent
la résolution d’adresses parmi les adresses NSAP globales et les adresses SNPA locales au moyen
de l'information enregistrée dans les tables d'acheminement locales. Comme l'entité inter-réseaux
ATN comporte l'échange dynamique d'information d'acheminement entre les entités de la couche
Réseau, il n'est pas nécessaire d'avoir un format d'adresse SNPA ATN uniforme. Étant donné que
la structure d'adressage SNPA peut être optimisée pour un sous-réseau particulier, il est possible
d'utiliser une grande variété de types de sous-réseaux à l'intérieur de l'ATN. Les routeurs ATN
sont responsables de la constitution et de la mise à jour des tables de correspondance entre les

37
adresses NSAP, les NET et les adresses SNPA à l’intérieur de leur environnement local. L'adresse
NSAP ATN est fondée sur un nom et ne comprend aucune forme d'adresse SNPA ATN.

II.11.5. Relation entre les domaines ATN et les adresses NSAP ATN.
On peut résumer la relation entre les domaines ATN et les champs adresse NSAP ATN de
la manière suivante :
a) Le domaine administratif est identifié par la partie initiale du champ DOMAINE, qui
contient le code de pays ISO dans le cas des adresses NSAP ATSC ou un indicateur de compagnie
aérienne IATA dans le cas des adresses NSAP ATSC.
b) À l'intérieur du domaine administratif, le domaine d'acheminement est identifié par la
partie finale du champ DOMAINE selon la définition de 1'administrateur du domaine.
c) A l'intérieur du domaine d'acheminement, la zone d'acheminement est identifiée par le
champ ZONE LOCALE, qui peut contenir une valeur numérique attribuée par l'administrateur du
domaine, un indicateur d'emplacement OACI dans le cas des adresses NSAP ATSC ou un
indicateur d'emplacement IATA dans le cas des adresses NSAP ATSC ou un indicateur
d’emplacement IATA dans le cas des adresses NSAP ATSC.

II.12. Procédures d’acheminement inter-réseaux ATN. [1][2]

II.12.1. Généralités.
L'acheminement inter-réseaux ATN fonctionne à l'intérieur d'une hiérarchie à trois
niveaux, qui comprend 1es éléments constituants inter-domaines et intra-domaine Dans le présent
contexte, le terme «domaine» désigne un domaine d’acheminement ATN. L’acheminement inter-
domaines est basé principalement sur des règles et mis en oeuvre au moyen de procédures
dynamiques adaptatives. L’acheminement intra-domaine est aussi de nature dynamique
adaptative, mais se fonde principalement sur les performances. L'acheminement inter-domaines et
intra-domaine ATN dépendent de l'échange opportun d'information pour permettre la mise à jour
dynamique de la topologie.
Dans une structure d'acheminement hiérarchique, l'objectif le plus important en matière de
performance consiste à minimiser le transfert d'informations d'acheminement entre les domaines
administratifs et d'acheminement au niveau inter-domaines, et entre les zones d'acheminement au
niveau intra-domaine Ce procédé réduit la quantité de trafic supplémentaire d’acheminement
transporté par les sous-réseaux de connexion ainsi que la quantité d’information d’acheminement
enregistrée à l'intérieur de chaque routeur ATN. Le résultat est que les domaines administratifs et

38
les domaines d'acheminement produisent moins d’information sur la connectivité et la topologie et
qu'ils peuvent ainsi conserver un degré supplémentaire de confidentialité. Étant donné que les
limites des domaines administratifs et d'acheminement respectent habituellement les limites inter-
administratives et intra-administratives, ce résultat est souvent comparable à l'efficacité obtenue au
niveau du protocole et du fonctionnement à la suite de l'utilisation de l'architecture
d'acheminement hiérarchique.

II.12.2. Acheminement inter-domaines

L’acheminement inter-domaines ATN est le pivot de l’ATN, en ce sens que les liaisons
inter-domaines interconnectent les diverses organisations qui font partie de l'entité inter-réseaux
ATN. Les interconnexions de sous-réseaux sont généralement structurées conformément aux
accords locaux ou régionaux conclus entre les exploitants des systèmes intermédiaires limites de
l'entité inter-réseaux ATN (c'est-à-dire des routeurs limites de domaines). Ces accords portent sur
l'affectation des frais de service de sous-réseau, sur la comptabilité des NPDU d'utilisateur ainsi
que sur le niveau de sécurité, de fiabilité, de disponibilité et d'intégrité exigées pour les liaisons de
sous-réseau d'interconnexion. Étant donné que la structure inter-domaines de l'ATN est le
fondement de l'entité inter-réseaux ATN, tous les exploitants de systèmes intermédiaires limites
doivent respecter certains niveaux de sécurité, de fiabilité, de disponibilité et d'intégrité.

II.12.3. Acheminement intra-domaine

L'organisation interne de l’acheminement intra-domaine ATN comporte deux niveaux
hiérarchiques, conformément au cadre d’acheminement OSI ISO (ISO TR 9575). Le niveau
supérieur de la hiérarchie, appelé niveau 2, est responsable de l'acheminement interzone. Le
niveau inférieur, soit le niveau 1, est responsable de l'acheminement entre systèmes intermédiaires
à l'intérieur d'une zone. Comme ils sont le fondement du domaine d'acheminement, les routeurs de
niveau 2 sont soumis à des normes de sécurité, de fiabilité, de disponibilité et d'intégrité plus
rigoureuses que celles des routeurs de niveau 1. L’acheminement intra-domaine ATN comprend
deux étapes :
1. Transmission de la NPDU adressée à la zone de destination après évaluation de la partie
adresse de zone de l'adresse NSAP (Figure II.6). Cette étape effectue la remise de la NPDU à un
point d'entrée connu de la zone de destination.
2. Transmission de la NPDU adressée à 1'équipement hôte de destination après évaluation
de la partie ID de l'adresse NSAP (Figure II.6). Cette étape effectue la remise de la NPDU à
l'ordinateur hôte récepteur désigné.

39
II.13. Transmission des unités de données. [1] [2] [3]
A l'intérieur d'un domaine d'acheminement, un routeur ATN peut déterminer s'il est
possible d'accéder à un NSAP localement ou s'il faut retransmettre la NPDU correspondante à un
système intermédiaire limite. Si le NSAP est accessible localement, le routeur peut dériver un
trajet pour accéder à ce NSAP. La procédure de transmission des NPDU est la suivante :
a) l'ordinateur hôte d'origine transfère la NPDU au routeur local désigné approprié;
b) selon l'adresse NSAP de destination, le routeur local détermine si l’ordinateur hôte de
destination est situé dans la zone locale, le domaine d'acheminement local ou le domaine
administratif local ;
c) si l'ordinateur hôte de destination se trouve dans la zone locale, la NPDU est envoyée
par le ou les routeurs de niveau 1 à l'ordinateur hôte de destination ;
d) si l'ordinateur hôte de destination est situé dans une autre zone à l'intérieur du même
domaine d'acheminement, le routeur de niveau 1 envoie la NPDU au routeur de niveau 2
approprié; la NPDU est alors retransmise par les routeurs de niveau 2 à la zone de destination. Une
fois arrivée à la zone de destination, la NPDU est envoyée à l'ordinateur hôte de destination par le
ou les routeurs de niveau 1 ;
e) si l'ordinateur hôte de destination est situé dans un autre domaine d’acheminement (et
par conséquent dans une autre zone), la procédure d'acheminement est la même que celle du cas
précédent et le passage d’un domaine d'acheminement à l'autre se fait entre deux systèmes
intermédiaires limites ;
f) si l'ordinateur hôte de destination est situé dans un autre domaine administratif (et par
conséquent dans un autre domaine d'acheminement), la procédure d'acheminement est la même
que celle du cas précédent et le passage d'un domaine administratif à l'autre se fait entre deux
systèmes intermédiaires limites.

II.14. Échange d'information topologique intra-domaine [1] [2] [3]

L'échange d'information d'acheminement entre les systèmes d'un domaine d’acheminement
est organisé de façon hiérarchique et peut être décrit de la manière suivante :
a) l'information d'acheminement de niveau 1 (qui se rapporte aux systèmes et aux trajets de
la zone locale) est diffusée dans toute la zone locale ;
b) l'information d'acheminement de niveau 2 (qui se rapporte aux routeurs et itinéraires de
niveau 2 du domaine d'acheminement) est diffusée dans tout le domaine d'acheminement.

40
 Aucune information d’acheminement intra-domaine ne traverse les limites des domaines
d’acheminement. L’information d’acheminement est propagée au moyen du protocole ES-IS (ISO
9542) et du protocole IS-IS (ISO 10589) :
a) Le protocole ES-IS fonctionne à l'intérieur d'un seul sous-réseau, indépendamment de la
structure en domaines et en zones d'acheminement. Il permet à chaque ES de découvrir son IS
voisin et à chaque IS de découvrir son ES voisin. Il peut aussi être utilisé entre deux IS de sorte
que chaque IS puisse découvrir son IS voisin.
b) Le protocole IS-IS fonctionne conformément à la structure en domaines et en zones
d'acheminement. Il est conçu pour tenir compte d’une grande variété de sous-réseaux (sous-
réseaux à topologie générale, sous-réseaux de diffusion, sous-réseaux point à point). Il permet à
chaque IS situé à l'intérieur d'un domaine d'acheminement de déterminer si un IS voisin se trouve
dans le même domaine et le même niveau d’acheminement.
Chaque routeur de niveau 1 utilise le protocole IS-IS pour produire des PDU d'état de
liaison de niveau 1 (décrivant les liaisons entre le routeur et tous ses IS et ES voisins) qui sont
communiquées à tous les routeurs de niveau 1 à l'intérieur d'une zone donnée. Chaque routeur de
niveau 2 produit des PDU d'état de Liaison de niveau 2 (décrivant les Liaisons entre le routeur et
tous ses IS de niveau 2 voisins) qui sont communiquées à tous les routeurs de niveau 2 à
l’intérieur d’un domaine d’acheminement.

II.15. Architecture de protocole ATN. [1] [2] [3]

II.15.1. Généralités.
L'architecture de protocole ATN a pour rôle de définir un environnement dans lequel le
transfert fiable de données de bout en bout peut avoir lieu, dans l'ensemble des sous-réseaux de
données embarqués, air/sol et sol envisagés, tout en assurant l'interopérabilité de ces réseaux.
L’accent est mis sur l'interopérabilité du transfert de données de système terminal à système
terminal. Si un ensemble de spécifications d'interface standard est respecté pour l'échange de
données de bout en bout entre adresses globales (NSAP), l'interopérabilité du transfert de données
parmi ces systèmes terminaux devient faisable. L'ATNPA procure ce niveau d'interopérabilité en
utilisant des normes de protocole d'interface ISOPA dans les sous-couches, sous-réseau et inter-
réseaux, et à l'interface entre la couche Transport et l'utilisateur des services de communication.
La Figure II-7 montre l'adaptation de l'architecture de protocole ISO au réseau
aéronautique. On distingue dans cette architecture 1es divisions 1ogiques ci-dessous aux fins de
description fonctionne1le et de définition des spécifications de protocole :

41
 a) opérations de sous-réseau (couche Liaison de données et couche Physique comprise) ;

b) opérations inter-réseaux (retransmission et acheminement compris) ;

c) opérations de Transport ;

d) opérations des couches supérieures (Application, Présentation, Session).

Cette architecture représente une division du modèle de référence ISO, d'une façon convenant à la
normalisation aéronautique, l'objectif étant de conserver le niveau le plus élevé possible de
conformité à l'ISOPA au sein de chaque couche de protocole.
Processus d’ Processus d’ Processus d’ Processus d’ Processus d’ Processus d’ Processus d’
Application 1 Application N Application S1 Application M Application P Application 1 Application A

APPLICATION P APPLICATION P APPLICATION P APPLICATION P

I I I I
L L L L
PRESENTATION PRESENTATION PRESENTATION PRESENTATION
E E E E
1 a b c
SESSION SESSION SESSION SESSION

INTERFACE C

TRANSPORT 1 TRANSPORT k
INTERFACE B

INTERRESEAUX
INTERFACE A

Sous réseau 1 Sous réseau i Sous réseau j

Figure II. 7: Architecture du protocole ATN

II.15.2. Interfaces de l'architecture de protocole ATN.

La Figure II.7 montre les interfaces entre couches qui ont une importance critique pour les
opérations accomplies selon l'ATNPA. L'interface A de la Figure II.7 est l'interface de sous-
réseaux et définit l'exécution du transfert de données entre l'entité inter-réseaux et le sous-réseau
aéronautique souhaité. L’interface B est l'interface de réseaux et définit l’exécution du transfert de
données entre l'entité de Transport et l’entité inter-réseaux. L’interface C est l'interface de
Transport et définit l'exécution du transfert de données entre les entités des couches supérieures et
l'entité de Transport.

42
 L'entité inter-réseau représenté dans la Figure II.7 accomplit toutes les fonctions de
routeur (retransmission et acheminement) à l'intérieur de l'ATNPA, tandis que la couche sous-
réseau assure le transfert de l'information de supervision et de paquets de données à l'intérieur d'un
réseau local. L’entité inter-réseaux évalue l'adresse NSAP et choisit un trajet de sous-réseau par
l'intermédiaire duquel il est possible d'atteindre l'adresse NSAP. Les entités de sous-réseau doivent
acheminer l'information d'adresse NSAP de manière transparente mais ne sont pas tenues
d'accomplir des fonctions de retransmission ou d'acheminement d'après la teneur de l'adresse
NSAP.

Puisque les interfaces de Transport, inter-réseaux et de sous-réseaux sont normalisées à

l'intérieur de l'ATNPA, la configuration modulaire des processus de protocole inter-réseaux,
Transport et couches supérieures est faisable. Dans un système initial, le processus de service
Applications peut accomplir des fonctions de couches supérieures et Transport et dialoguer
directement avec l'interface de couche Réseau ATN (c'est-à-dire l'interface B). Une telle
configuration permet de mettre en oeuvre les fonctions standard de couches supérieures et
Transport standard. La conformité aux normes relatives aux interfaces A, B et C à l'intérieur de
l'architecture de protocole ATN permet une évolution progressive du système de communication
sans obliger à modifier les opérations de sous-réseau, inter-réseaux ou des couches supérieures.

II.15.3. Fonctionnement de l'architecture de protocole ATN.

Voici une suite type d'opérations de communication interprocessus entre systèmes

terminaux ATNPA (en cas d'uti1isation du protocole de Transport en mode connexion) :

a) un processus d'Application embarqué désireux de transférer des données à un processus

d'Application sol spécifie l'adresse de destination globale (c'est-à-dire l'adresse NSAP) et les
paramètres QOS dans l'information de demande de connexion communiquée à la couche
Transport par les entités des couches supérieures ;

b) la couche Transport formule une demande de connexion de Transport à transférer à son

homologue dans le système terminal de destination. Cette demande est encapsulée dans une ou
plusieurs PDU de réseau sans connexion et communiquée à la sous-couche inter-réseaux en même
temps que les paramètres QOS et adresse NSAP correspondants;

c) la sous-couche inter-réseaux choisit alors le sous-réseau air/sol approprié d’après ces

paramètres, en transférant les NPDU à l’entité inter-réseaux (routeur) suivante au moyen du
protocole d’accès au sous-réseau choisi ;

43
 d) après avoir traversé tous les sous-réseaux intermédiaires et leurs routeurs respectifs, les
NPDU contenant la demande de connexion de Transport parviennent au système terminal de
destination. L’entité de couche Transport du système terminal de destination rassemble le message
de la couche Transport, détermine d'après sa teneur qu'il s'agit d'une demande de connexion et
génère la réponse appropriée pour confirmer la connexion de Transport.
Une fois qu’a été établie une connexion de bout en bout (de couche Transport) entre le
processus d'Application émetteur et le processus d'Application de destination, une communication
interprocessus normale peut avoir lieu entre les Applications d'origine et de destination.
Lorsqu'une communication interprocessus cesse d'être nécessaire, l'un ou l'autre de ces processus
d'Application peut demander une suspension en envoyant une demande à l'autre au moyen de la
connexion de Transport existante. Lorsque le système terminal qui reçoit la demande confirme la
déconnexion, les deux systèmes terminaux libèrent la connexion de Transport ainsi que toutes les
ressources consacrées à cette connexion.
Notons que dans cette suite d'opérations un protocole de Transport en mode connexion
fonctionne par dessus un protocole inter-réseaux en mode sans connexion, et que les sous-réseaux
intermédiaires peuvent fonctionner de l'une ou l'autre façon dans n'importe quel sous-réseau utilisé
entre systèmes terminaux. Si les processus d'Application en communication ont besoin
d’accomplir un transfert de données en mode sans connexion (c'est-à-dire sans contrôle de flux de
bout en bout), on pourrait utiliser un protocole de Transport en mode sans connexion sans
modifier aucunement la nature des opérations inter-réseaux ou des opérations de sous-réseau

II.16. Fonctionnement des sous-réseaux [1] [2] [3]

II.16.1. Généralités.
La sous-couche sous-réseau ATN doit permettre le transfert transparent de NPDU entre
entités inter-réseaux adjacentes. Il s'agit notamment du transfert transparent d'adresses globales et
de l'information de qualité du service, ainsi que de données de l'utilisateur. Les exigences
fonctionnelles imposées à un sous-réseau ATNPA participant peuvent se résumer comme suit :
a) l'interface entre le sous-réseau et l'entité inter-réseaux (c'est-à-dire le routeur) se trouve
dans la couche Réseau; l'information de commande en ce qui concerne la couche Liaison de
données et la couche Physique n'est donc pas communiquée d'un sous-réseau à l'autre. Il en résulte
que le sous-réseau peut utiliser des protocoles non conformes à l'intérieur de ces couches tout en
maintenant la conformité ISOPA à l'intérieure de la couche Réseau ;

44
 b) le sous-réseau n'impose aucune restriction quant à la forme ou à la teneur des en-têtes
des couches supérieures, mais se contente de transférer sans modification de l’information de
commande concernant ces couches ;
c) le sous-réseau doit acheminer l'information de commande de protocole (PCI) de réseau
ISO pour évaluation par chaque routeur intermédiaire (c'est-à-dire chaque système intermédiaire) ;
d) le sous-réseau doit assurer le transfert transparent de l'information d'adresse globale
standard de réseau (NSAP ISO) et de qualité du service, en vue de leur évaluation par chaque
routeur intermédiaire.
Le sous-réseau ATN aide le routeur à assurer des services de système intermédiaire (c'est-
à-dire la retransmission transparente de données) parmi les sous-réseaux contigus. Des services de
système terminal ne sont nécessaires que dans les ordinateurs hôtes desservant l'utilisateur. Par
conséquent, il est inutile que le sous-réseau comprenne d'avance les opérations des couches
supérieures (Session, Présentation et Application) ou de Transport. De même, l'interface avec les
sous-réseaux contigus se trouve dans la couche Réseau; ainsi, les en-têtes associés avec les
opérations de la couche Liaison de données et de la couche Physique ne sortent pas du sous-réseau
Chaque sous-réseau peut ne pas être organisé sur le plan interne de la même manière que les sous-
réseaux qui l'entourent et maintenir quand même la compatibilité ISOPA à l'intérieur de la couche
Réseau.

II.16.2. Considérations relatives au protocole.

Dans l'ATN il existe trois types de sous-réseaux : les sous-réseaux avionique, les sous-
réseaux air/sol et les sous-réseaux sol. Ces sous-réseaux ont des caractéristiques différentes, dont
la plus importante est probablement que les sous-réseaux air/sol ont en général une largeur de
bande limitée par rapport à celle des deux autres sous-réseaux
Les protoco1es de sous-réseau peuvent être classés dans deux catégories: mode sans
connexion et mode connexion, décrites en II.4. Dans les cas où les utilisateurs échangent des
messages multiples, le protocole en mode connexion fait un usage plus efficace de la largeur de
bande de communication, car l’information d'adresse et de QOS n'est envoyée qu'une seule fois.
Ainsi, le protoco1e en mode connexion a la caractéristique souhaitable de devenir plus efficace à
mesure que la demande augmente. Cette augmentation d'efficacité fait plus que compenser
l'augmentation de complexité du mode connexion par rapport à celle du protoco1e en mode sans
connexion. Il est donc recommandé d'utiliser le protocole de sous-réseau en mode connexion dans
les sous-réseaux air/sol à largeur de bande limitée. Pour les sous-réseaux avionique ou sol, dans

45
lesquels la largeur de bande ne joue pas le rôle principal, on peut choisir soit le mode connexion
soit le mode sans connexion.
On n'est pas strictement tenu d'adopter un protocole standard commun d'interface des sous-
réseaux pour tous les sous-réseaux air/sol, mais cela simplifie grandement la mise en oeuvre et la
validation des échanges inter-réseaux puisqu'il ne faut qu'un progiciel de communication pour
l'interface avec les différents sous-réseaux air/sol. Le protocole de niveau paquets ISO 8208 a été
adopté pour cette interface.

II.17. Opérations inter-réseaux [1] [2] [3]

Les opérations inter-réseaux ATNPA forment l'essentiel de l'entité inter-réseaux
aéronautique. L’architecture inter-réseaux ATN peut se résumer comme suit :
a) l'entité inter-réseaux aéronautique se compose de divers sous-réseaux embarqués, sous-
réseaux air/sol et sous-réseaux sol; on chaîne ces sous-réseaux à l'aide d'un protocole inter-réseaux
en mode sans connexion pour fournir une connectivité globale;
b) il faut mettre en oeuvre un routeur ATN à la limite de chaque sous-réseau (c'est-à-dire
dans chaque système terminal et chaque système intermédiaire) en vue de l'interconnexion de ces
divers sous-réseaux ;
c) chaque routeur ATN est chargé :
1) de retransmettre les PDU inter-réseaux vers le système terminal de destination à
l'aide d'un protocole d'accès au sous-réseau (SNAcP);
2) de suivre dynamiquement les connexions de sous-réseau disponibles afin de
faciliter ce processus de retransmission;
3) d'informer les routeurs adjacents des modifications intervenues dans les
connexions et la qualité de service à l'aide du protocole d'échange d’information
d’acheminement.
d) les sous-réseaux ATN peuvent fonctionner en mode connexion ou en mode sans
connexion. Chaque routeur ATN comprend un moyen de convergence dépendant du sous-réseau
(SNDCF) qui gère le protocole d'accès au sous-réseau pour chaque sous-réseau disponible, et
convertit les PDU inter-réseaux en un format convenant au transfert en sous-réseau et
inversement.
Le service réseau en mode sans connexion ATN (CLNS) dispose du protocole inter-
réseaux ISO 8473. La couche Transport utilise ce protocole pour transférer les messages
interprocessus (c'est-à-dire les données de l'utilisateur) à travers les sous-réseaux qui relient les

46
ordinateurs hôtes communicant ; de plus, le protocole inter-réseaux ATN sert à acheminer des
protocoles de gestion de réseau et d'acheminement parmi les entités de couche Réseau qui
coopèrent.
Le protocole inter-réseaux ATN a été choisi pour maximiser l'efficacité inter-réseaux par
simplification des opérations de retransmission et d'acheminement; pour cette raison, il n'est tenu
compte dans les opérations inter-réseaux ATN d'aucune forme de préoccupation de bout en bout.
La couche Transport ATN est exclusivement chargée d'assurer le transfert fiable de bout en bout.

II.18. Opérations de Transport. [1] [2] [3]

II.18.1. Généralités.
Les opérations de Transport ATNPA représentent l'interface entre l'ordinateur hôte et
l'entité inter-réseaux aéronautique. Elles peuvent être exécutées dans l'un des deux modes
possibles spécifiés dans la norme ISO 8072 : le mode connexion et le mode sans connexion.
Le service de Transport en mode connexion (COTS) permet l'établissement d'une
connexion de Transport entre les entités des couches supérieures avant le transfert de données et
maintient une relation entre toutes les unités de données du protocole de Transport (TPDU)
transférées par l'intermédiaire de cette connexion. Cette relation peut être utilisée, par exemple,
pour le contrôle de flux de bout en bout ou pour l'accusé de réception de remise. Le COTS serait
sélectionné lorsque les processus d'Application homologues exigent des échanges répétés de
TPDU ou lorsque le contrôle de flux de bout en bout, le contrôle d'erreurs et l'accusé de réception
de remise sont nécessaires.
Un service de Transport en mode sans connexion (CLTS) permet le transfert de bout en
bout de données en mode sans connexion et assure l'intégrité du Transport de données lorsqu'il n'y
a pas de relation entre les TPDU. Le CLTS serait sélectionné lorsque les processus d'Application
homologues exigent un échange de TPDU sans contrôle de flux de bout en bout ni accusé de
réception de remise. Ce service est principalement destiné aux Applications qui exigent un
transfert de données unique et unidirectionnel.

II.18.2. Considérations relatives au protocole.

Le service de Transport en mode connexion ISO utilise le protocole de Transport ISO
8073. Cette norme comprend cinq classes différentes de protocoles de Transport. Une classe
appropriée d'opérations doit être sélectionnée en fonction des besoins du processus d’Application.
Le service de Transport en mode sans connexion ISO utilise le protocole de Transport ISO 8602.

47
Il faut sélectionner un protocole de Transport approprié (COTS ou CLTS) pour chaque processus
d'Application, d'après les besoins de ce dernier et de ses protocoles de couches supérieures. Cette
sélection se fait en fonction des critères analysés dans la partie II.18.1.

II.19. Opérations de couches supérieures. [1] [2] [3]

Les opérations de couches supérieures ATNPA comprennent des protocoles utilisés avec
les couches Application, Présentation et Session. Ces couches sont très différentes selon les
processus d'Application et leurs besoins; par conséquent, un ensemble de protocoles de couches
supérieures doit surtout être conforme aux normes pertinentes de l'ISO et pouvoir interagir avec
les protocoles de Transport ATNPA. De plus, l'ensemble de couches supérieures doit être capable
d'exprimer les adresses mondiales et la qualité du service en des termes conformes aux normes
ATNPA.

48
Chapitre III : Les différentes architectures fonctionnelles des communications air/sol de
l’ATN.

III.1. Evolution des architectures des systèmes de communication [13]

Les concepts de vol libre et de gestion répartie de la circulation au sol et en l’air sont
concevables sur une conscience situationnelle commune parmi les contrôleurs aériens, les pilotes
et les fournisseurs de services tels que les régulateurs du transport aérien. Si on se base sur ce
point de vue commun de la situation, tous les utilisateurs peuvent négocier sur les problèmes de la
gestion de la circulation (tel que les mauvais temps, fermetures aéroportuaires, pannes
techniques), et peuvent échanger des informations sur les observations météorologiques, sur les
modifications de plan de vol. La quantité de données exigées pour supporter les concepts de vol
libre et de gestion répartie de la circulation qui incluent des systèmes d’information de vol (FIS)
graphiques et les matériels du service d’information de la circulation (TIS) sont supposés
augmenter les demandes sur le système des communications de l'aéronef et sur le spectre VHF.

III.1.1. Système informatisé d'Aéronef.

Avec le flot de données qui sera envoyée au poste de pilotage, un réseau aéroporté
semblable aux LAN au sol est préconisé. Les transmissions de données haut débit, les échanges
croissants entre processeurs à bord, et le besoin combiné pour une installation de haute précision
(fiabilité) et d’une facilité d’usage nous renvoi au besoin d’un réseau avionique.

III.1.1.1. Réseau Haut débit.

Dans cette section nous allons voir le besoin pour un réseau avionique semblable aux LAN
au sol mais convenable pour les environnements aéroportés. Le réseau avionique actuel est décrit
pour comparaison.
Actuellement les communications du vol à bord sont supportées par une variété
d’émetteurs-récepteurs de liaisons sonore et de données qui opèrent dans la bande des très hautes
fréquences (VHF), des hautes fréquences (HF) et des fréquences de Communications par Satellite
(SATCOM – Bande L). Les exigences des fonctionnalités historiques ont placé la liaison
analogique sonore et la liaison de données dans les mêmes unités pour minimiser le nombre de
radios à bord. La figure III.1 illustre la configuration de l’état actuel des installations des
différentes radios pour les transporteurs aériens (Classe 3 et 2). Le câblage de l'antenne à l’Unité
de Gestion des Communications (CMU) est indépendant pour chaque radio. Les radios sont

49
considérées cruciales pour les opérations du vol et les aéronefs commerciaux ont des systèmes
doublés voir même triplés avec pour chaque système un constructeur différent.
Unité d’affichage interactive pour
différentes applications Voix Analogique Liaison de données Antenne HF
ou Données HF

Unité de Gestion des

Communications Voix Analogique Radio
Numérique Antenne VHF
CMU ou Données
VHF

Communications
Système de Voix Analogique par satellite Antenne
Gestion du Vol ou Données SATCOM SATCOM
FMS Système Audio

Figure III. 1: Configuration actuelle des systèmes de communication d’un aéronef

En plus de la distribution d'information aux équipements du poste de pilotage, des futurs

services aéroportés tels que les divertissements en plein vol, le commerce électronique et les
applications Internet venant et en partance de l’aéronef avoisineront les 10 Mbps durant le vol. La
distribution dans l'aéronef nécessitera un bus haut débit ou un réseau local (LAN).

Les réseaux aéronautiques auront des exigences supplémentaires au-delà de celles des
LAN au sol. Les installations dans les aéronefs exigent différentes certifications : au niveau
d’interférences électromagnétiques (EMI), de la sécurité incendie, des tolérances des pannes, de la
sécurité et de la maintenance. Si le réseau supporte les trafics ATC, AOC et des passagers, cela
exigera une sécurité de l'information, une qualité des services fournis et un plan de priorité.

L’emploi de nouvelles technologies telles que la Fibre Optique (FDDI), est potentiellement
applicable aux exigences du réseau de l'aéronef. La technologie FDDI est conçue pour manier les
données synchrones pour la voix et la vidéo. Elle fournit une capacité de données élevée. Elle est
immunisée contre les interférences électromagnétiques et elle est légère.

Comme précédemment énoncées, les radios existantes opèrent dans l’une des deux modes :
soit avec voix ou avec des données. Par contre, le futur système des communications de l'aéronef
implémentera sur le même câblage la voix et les données comme illustré dans la figure III. 2.

50
 HF VHF SAT Mode S

Modem/Récepteur multimode de données

Routeur/Passerelle de l’aéronef

Serveur non Serveur des Terminal d’accès

Système de au pilot
distribution essentiel de données critiques
Vidéo/Audio l’aéronef du vol

Base de donnée du
système de gestion de vol
Système de téléphonie à
bord

Système d’enregistrement des

données de vol
Poste de travail à bord

FOQA

Imprimante de bord ACARS

Systèmes
de com.
hérité Voix
analogique

Figure III. 2: Systèmes de communication aéronautiques intégrant des données et de la voix

III.1.1.2. Serveurs dans l'aéronef.

L'architecture de réseau exigera un serveur dans l'aéronef qui pourra profiter des moyens
partagés et acheminer toute l'information nécessaire. L'architecture, le système d'exploitation, les
applications majeures, et la gestion des bases de données ont besoin à ce que ce serveur soit bien
défini.

III.1.1.3. Affichages multifonctionnels

Le volume nouveau de la quantité d’information disponible au pilote exigera un moyen

adéquat de présentation. La plupart des études et efforts ont supposé qu’une exposition
multifonctionnelle sera utilisée pour présenter une variété de formats textes et graphiques.

51
III.1.1.4. Routeur intelligent.

Le concept ATN inclut une fonction de routeur de l'aéronef qui permettra à ce dernier de
communiquer avec plusieurs applications sol différentes telles que le CPDLC, l’ADS, et l’AOC.

Les spécifications générales et l'architecture interne pour un tel routeur doivent, si possible,
correspondre aux routeurs haut débit qui supportent le réseau sol. Le routeur devrait être aussi
capable de gérer de multiples liaisons air/sol employant une politique basée sur d’acheminement
pour optimiser la sélection du liaison pour chaque message.

L’approche d’un routeur de l'aéronef multi protocolaire, exploitable dans tout l’aéronef
rehausserait la fiabilité et diminuerait les coûts des communications.

III.1.2. Amélioration des liaisons VHF

Certaines mesures devraient être prises pour améliorer l'infrastructure VHF. Ces
améliorations incluent un nouveau design de l'antenne, de nouvelles modulations et techniques de
compression, et une amélioration des composants utilisés pour la transmission de la voix.

III.1.2.1. Antenne VHF directionnelle

Les multiples liaisons VHF sont attendues pour les futurs aéronefs y compris des
combinaisons de la voix sur 25 kHz DSB-AM, de la voix sur 8.33 kHz DSB-AM, l’ACARS, la
VDL Mode 2, la VDL Mode 3, et la VDL Mode 4. L’installation de multiples systèmes sur les
grands aéronefs est difficile mais faisable. L’installation de multiples systèmes sur les petits
aéronefs est difficile du fait que l’espace disponible est limitée et le risque d’interférence entre
systèmes est grand.

Les antennes VHF des aéronefs sont omnidirectionnelles actuellement, lesquelles sont à
bas prix et permettent une simple installation. Les antennes directionnelles fournissent une
protection élevée contre les signaux non désirés à l'extérieur de l’angle d’ouverture de l'antenne.
Une antenne VHF directionnelle peut être utile pour résoudre les problèmes de la liaison de
données VHF si elle a un faible coût et est fiable. Les antennes électriquement manoeuvrables
existent déjà pour d’autres services et la technologie peut être utilisée dans l’aviation. Une
combinaison d'antennes ou une configuration modifiable de l'antenne du modèle omni au modèle
unidirectionnel pourrait permettre d’utiliser initialement le mode omnidirectionnel pour trouver un
poste et puis par la suite passer en mode unidirectionnel une fois le poste localisé.

52
III.1.2.2. Modulation

Le plan de modulation D8PSK sélectionné par l’OACI pour la VDL Mode 2 et la VDL
Mode 3 a été basé sur la modulation existante espacée de 25 kHz dans la bande VHF, utilisant des
messages relativement courts, et des communications bilatérales. Les plans de modulation retenus
sont : D8PSK, 8LFM, 4QAM, et 16QAM. Ces différentes modulations sont résumées comme
suit :
a) La 4QAM a un débit insuffisant ;
b) La 16QAM est la technique la plus complexe et considérablement plus chère que les
autres ;
c) La 8LFM a un émetteur non linéaire qui peut fournir plus de puissance RF dans le canal et
fournir plus de marge que le D8PSK ;
d) La D8PSK a la performance de la diaphonie entre voies adjacentes très supérieure pour la
modulation analogique contre la modulation numérique (Mode 2, Mode 3, ou des
combinaisons)
e) La D8PSK fournit un débit de transmission de données de canal de 31.5 kbps avec une
vitesse en baud de 10.5 kbaud et trois bits par symbole.
Le 16QAM pourraient céder un débit de 37.8 kbps pour les plus longs messages (1024
octets) basé sur une bande passante de 25 kHz. Les FIS et les autres services utilisant des message
de grandes dimensions pourraient bénéficier du plus grand débit.

III.1.2.3. Réseau virtuel

Les techniques actuelles d’allocations des fréquences sont basés sur les techniques de
radiodiffusion de la voix analogique et assignent une seule fréquence à chaque secteur du contrôle
du trafic aérien ATC. Avec l’avenue des communications numériques telle que la VDL Mode 3,
l'usage effectif du spectre de fréquence est possible. La figure III.3 illustre la transition de
l’allocation des tâches analogiques existantes à l’allocation future du VDL Mode 3. La VDL
Mode 3 fournira beaucoup plus de canaux virtuels et permettra l'augmentation ou services
supplémentaires.
Une nouvelle stratégie d’allocation de fréquence qui maximise la capacité du Mode 3
devrait être développé. L'application de l'approche des réseaux virtuels employés dans les
systèmes tel que la téléphonie cellulaire, qui maintient la connexion quand le véhicule se déplace à
travers plusieurs cellules et donc plusieurs fréquences devrait être considéré.

53
 En route
En route
Niveau supérieur
Niveau supérieur
f1A - Voix
f1
f1C - Données
NEXCOM (VDL – 3) En route
En route
Niveau moyen
Niveau moyen
f1B - Voix
f2
4 sous canaux par 25 kHz de f1D - Données
fréquence
Terminale Terminale
f(x) A B C D
f2A - Voix
f2C - Données
f3 4.8 kbps par sous canal

Aéroport Aéroport
f4 f2B - Voix
f2D - Données

Figure III. 3: Gestion des fréquences - Analogique au VDL-3

III.1.3. SATCOM.
L'usage de la bande de fréquence Ka satellitaire est suggéré pour l’émission de diffusion
FIS et TIS. Cette section décrit l'usage de la bande de fréquence Ka satellitaire qui inclut les
interfaces radio multimode avec la bande Ka, les techniques de la modulation, les standards
mobiles, les améliorations du récepteur et de l'antenne.

III.1.3.1. Interfaces radio multimode avec la bande Ka.

Les conceptions des radios air/sol actuelles sont basées sur des radios multimodes qui
peuvent fournir des modulations AM, VDL mode 2 et VDL mode 3. L'approche multimode réduit
le nombre total des radios exigées à bord de l'aéronef, et permet à l’aéronef d'opérer dans de
nombreuses régions géographiques. Une interface de bande Ka aux radios multimodes existantes
serait nécessaire pour que les communications par satellite soient intégrées avec les autres
opérations radios.

III.1.3.2. Techniques de modulation. [12]

Les liaisons de communications utilisant les fréquences appartenant dans la bande Ka sont
dégradées par la pluie et sont bloquées par les obstacles dans les lignes de vue. L'atténuation

54
causée par l'oxygène et la vapeur d'eau dans la bande Ka avoisine 0.1 dB/Km à 0.2 dB/km. Une
étude effectuée en 1993 par le Programme de la NASA ACTS montre que l'atténuation typique de
la pluie dans la bande Ka est d’environ 7 dB. Pour minimiser cette atténuation pendant la pluie,
plusieurs approches telles que des itinéraires alternatives pour éviter la pluie et des techniques de
codage ont été proposées. Les codes de Viterbi peuvent améliorer la marge de la liaison
satellitaire; en utilisant la modulation PSK et un taux d'erreurs de 10-5, on peut s’attendre à un gain
de traitement de 7 dB.

Les plus grandes techniques efficaces de modulation 8-PSK et QAM paraissent

appropriées pour les applications satellitaires de la bande Ka. Pour pouvoir optimiser l’utilisation
de la puissance et de la bande passante des satellites, la modulation 8-PSK ou 16-QAM associée à
un puissant code peut être utilisée. Comparé au QPSK ou BPSK (les plus utilisées des
modulations numériques dans les communications par satellite) la modulation 8-PSK utilise deux
tiers de la bande passante exigée par la modulation QPSK et seulement un tiers de la bande
passante exigés par la modulation BPSK.

III.1.3.3. Niveaux mobiles

La bande Ka a été recommandée à l'origine à cause de sa disponibilité relative du spectre

radio. Les bandes inférieures sont techniquement utilisables mais sont déjà saturées par d’autres
utilisateurs et applications. L'usage des liaisons de communications par satellite exige le
développement des technologies aéronautiques mobiles dans les domaines des antennes, des
récepteurs, des algorithmes des liaisons, des protocoles et des normalisations. En plus, l'usage par
les satellites de la bande Ka exige plusieurs initiatives politiques et économiques. Le spectre des
satellites est alloué internationalement. Si une bande de fréquence aéronautique dédiée est exigée,
la fréquence devra être proposée et acceptée dans un processus qui, traditionnellement exigeait
beaucoup de temps.

Comme précédemment mentionné, la bande Ka est atténuée par la pluie, la vapeur de l'eau
et l'oxygène à certaines fréquences. Les méthodes de codage fournissent un gain supplémentaire
qui peut compenser l'atténuation de la pluie. La diversité des satellites peut être aussi applicable si
le segment d'espace inclut des satellites multiples. Les constellations LEO, MEO, et HEO et la
combinaison des constellations LEO/MEO/GEO/HEO pourraient fournir une diversité à l'aéronef.

55
III.1.3.4. Amélioration des récepteurs.

Les récepteurs de la bande Ka existants sont faits pour une bande passante élevée, pour les
services fixes ou de diffusion. Aucun de ces récepteurs n'est prévu actuellement pour le service
mobile. Un récepteur d'aéronef devrait être léger, avoir un faible coût, et doit travailler avec
l'antenne, et le plan de modulation pour permettre les opérations pendant les manœuvres
dynamiques de l’aéronef.

III.1.3.5. Améliorations de l'Antenne dans la bande Ka.

La future antenne requise pour l’aéronef doit être un sous-système performant qui
maximise le gain en minimisant la température du système. Une telle antenne doit être
électroniquement capable de traquer le satellite avec une erreur de moins de 0.25°C, en autorisant
un petit profil de moins de 20 centimètres pour minimiser son impact sur l'aérodynamique de
l'aéronef. Le système de l'antenne exigé doit contenir deux voies (réception et émission), un
amplificateur à faible bruit (LNA), un amplificateur de puissance, un duplexeur, et devra être
intégrable dans les systèmes RF et de câblage de l’aéronef.
Le système d'antenne doit entrer dans un radome installé dans le fuselage de l'aéronef et ne
doit pas dépasser 15 centimètres. L'antenne exigerait une haute directivité supportée par un
système de positionnement ou d’orientation automatique (basé sur la position de l'aéronef et les
puissances de réception RF) orientant l'antenne vers le satellite pour optimiser la réception.

III.2. Architecture fonctionnelle des communications air sol. [13]

Cette architecture montre l'environnement dans lequel l'aéronef évolue et les différents
concepts utilisés. (figure III. 4)

III.3. Analyse fonctionnelle. [13]

III.3.1. Concepts opérationnels et techniques.

Le tableau suivant montre les concepts opérationnels et techniques dans le domaine de
l’aéronautique.

56
 Concepts Opérationnels Concepts techniques

L'aéronef reçoit de façon continue les Informations du vol

Service d’information de vol (FIS)
pour permettre une conscience situationnelle commune

L'aéronef reçoit de façon continue les Informations du vol

Service d'Information de la
pour permettre une conscience situationnelle commune
circulation (TIS)

la messagerie Contrôleur - Pilote supporte efficacement

Communication de données entre
la validation, les Modifications du Plan du vol, et les
Pilote Contrôleur (CPDLC)
consultations (y compris les Alertes de mauvais temps)

Communications Pilote-Contrôleur
Communication vocale entre Contrôleur Pilote
(CPC)
L’aéronef échange des données de
Liaison de données du Système de
Performance/Préférence avec l’ATC pour optimiser les
prise de décision (DSSDL)
prises de décision
Les aéronefs émettent en continu leur position actuelles et Automatic Dependent Surveillance-
projetées de façon à optimiser les manoeuvres Broadcast (ADS-B)
La messagerie Pilote - AOC soutient efficacement les Liaison de données pour le contrôle
opérations et la maintenance des compagnies et opérationnel des compagnies
Transporteurs aériens (AOCDL)
Transmission météorologique
L’aéronef fait des observations météorologiques à bord automatisée
(AUTOMET)
Les passagers aiment des services de télévision, de radio, Services aéronautiques des
d’Internet, et de divertissement à bord passagers (APAXS)
Tableau III. 1 : Concepts opérationnels et techniques.

III.3.2. Catégories des messages.

Ce tableau nous montre les différents niveaux de priorités des messages, les catégories et
leurs contenus.

57
 Priorité du
Concept technique message
Service d’information de
vol
(FIS)
Service d'Information de
la circulation (TIS)
Communication de
données entre Pilote
Contrôleur (CPDLC)
Communications Pilote
Contrôleur (CPC)
Liaison de données du
Système de prise de
décision (DSSDL)
Liaison de données pour le
contrôle opérationnel des
compagnies (AOCDL)
Automatic Dependent
Surveillance-Broadcast
(ADS-B)
Transmission
météorologique
automatisée
(AUTOMET)
Transmission
météorologique
automatisée
(AUTOMET)
Tableau III. 2 Catégories des messages
Catégorie du
message Contenue du message
Données dynamiques de
1 Information de vol position et météorologiques du
NAS
Données de position de
2 Information de la l’aéronef en temps réel
circulation (incluant les informations sur la
trajectoire) fournis par l’ATC
Messagerie Autorisations, modifications
3 Contrôleur-pilote des plans de vol et consultation
Voix Autorisations, modifications
4 Contrôleur-pilote des plans de vol et consultation
Messagerie entre Performance et préférence de
5 l’aéronef et l’ATC l’aéronef
les opérations et la maintenance
6 Messagerie entre des compagnies et
l’aéronef et l’AOC Transporteurs aériens
Les aéronefs émettent en
7 Rapport ADS continu leur position actuelles
et projetées
Rapport L’aéronef fait des observations
8 météorologique de météorologiques à bord (vent,
l’aéronef vélocité/magnitude,
température, humidité)
Services des Services à bord de télévision,
9 passagers de radio et de divertissent
incluant les services Internet
58
 Observation du temps aéroportée

Voix OPERATION, MAINTENANCE

AERONEF
Messagerie

Négociation ADS-B Aéronef

Position/Intention
CPC
FIS TIS APAX
CPDLC -TV, RADIO
- INTERNET

AUTOMET Fournisseurs de
DSSDL AOC
service commercial
Com

ADS-B D’autres
NWIS utilisateurs
autorisés

Service Contrôle de la
Circulation Centres des
Météo opérations des
National Aérienne (ATC)
Compagnies
Aériennes
(AOC)

Figure III. 4: Architecture fonctionnelle

III.4. Introduction sur les applications Client/Serveur [21]

III.4.1. Présentation de l'architecture d'un système Client/Serveur

De nombreuses applications fonctionnent selon un environnement Client/Serveur, cela
signifie que des machines clientes (des machines faisant partie du réseau) contactent un serveur,
une machine généralement très puissante en terme de capacités d'entrée-sortie, qui leur fournit des
services. Les services sont exploités par des programmes, appelés programmes clients, s'exécutant
sur les machines clientes. On parle ainsi de client FTP, client de messagerie, ..., lorsque l'on
désigne un programme, tournant sur une machine cliente, capable de traiter des informations qu'il
récupère auprès du serveur.
Dans un environnement purement Client/Serveur, les ordinateurs du réseau (les clients) ne
peuvent voir que le serveur, c'est un des principaux atouts de ce modèle.

59
III.4.2. Avantages de l'architecture Client/Serveur
Le modèle Client/Serveur est particulièrement recommandé pour des réseaux nécessitant
un grand niveau de fiabilité, ses principaux atouts sont :
a) des ressources centralisées : étant donné que le serveur est au centre du réseau, il peut
gérer des ressources communes à tous les utilisateurs, comme par exemple une base de
données centralisée, afin d'éviter les problèmes de redondance et de contradiction ;
b) une meilleure sécurité : car le nombre de points d'entrée permettant l'accès aux données
est moins important ;
c) une administration au niveau serveur : les clients ayant peu d'importance dans ce
modèle ont moins besoin d'être administrés ;
d) un réseau évolutif : grâce à cette architecture on peu supprimer ou rajouter des clients
sans perturber le fonctionnement du réseau et sans modifications majeures.

III.4.3. Inconvénients du modèle Client/Serveur

L'architecture Client/Serveur a tout de même quelques lacunes parmi lesquelles :
a) un coût élevé : dû à la technicité du serveur ;
b) une maillon faible : le serveur est le seul maillon faible du modèle Client/Serveur, étant
donné que tout le réseau est architecturé autour de lui. Heureusement, le serveur a une
grande tolérance aux pannes (notamment grâce au système RAID).

III.4.4. Fonctionnement d'un système Client/Serveur

Un système Client/Serveur fonctionne selon le schéma suivant :

Figure III. 5 : Système Client/Serveur

a) Le client émet une requête vers le serveur grâce à son adresse et le port, qui désigne un
service particulier du serveur ;
b) Le serveur reçoit la demande et répond à l'aide de l'adresse de la machine client et son
port ;

60
III.4.5. L’architecture Client/Serveur multi-niveaux

III.4.5.1. Présentation de l'architecture à 2 niveaux

L'architecture à deux niveaux (aussi appelée architecture 2-tier, tier signifiant étage en
anglais) caractérise les systèmes clients/serveurs dans lesquels le client demande une ressource et
le serveur la lui fournit directement. Cela signifie que le serveur ne fait pas appel à une autre
application afin de fournir le service.

Figure III. 6 : Architecture Client/Serveur à deux niveaux.

III.4.5.2. Présentation de l'architecture à 3 niveaux
Dans l'architecture à 3 niveaux (appelées architecture 3-tier), il existe un niveau
intermédiaire, c'est-à-dire que l'on a généralement une architecture partagée entre :
a) Le client : le demandeur de ressources 1 ;
b) Le serveur d'application (appelé aussi middleware) : le serveur chargé de fournir la
ressource mais faisant appel à un autre serveur ;
c) Le serveur secondaire (généralement un serveur de base de données), fournissant un
service au premier serveur ;

Figure III. 7 : Architecture Client/Serveur à trois niveaux

Etant donné l'emploi massif du terme d'architecture à 3 niveaux, celui-ci peut parfois désigner
aussi les architectures suivantes :

61
 a) Partage d'application entre client, serveur intermédiaire, et serveur d'entreprise ;

b) Partage d'application entre client, base de données intermédiaire, et base de données

d'entreprise ;

III.4.5.3. Comparaison des deux types d'architecture

L'architecture à deux niveaux est donc une architecture Client/Serveur dans laquelle le
serveur est polyvalent, c'est-à-dire qu'il est capable de fournir directement l'ensemble des
ressources demandées par le client. Dans l'architecture à trois niveaux par contre, les applications
au niveau serveur sont délocalisées, c'est-à-dire que chaque serveur est spécialisé dans une tâche
(serveur Web/serveur de base de données par exemple). Ainsi, l'architecture à trois niveaux
permet :

a) une plus grande flexibilité (souplesse) ;

b) une plus grande sécurité (la sécurité peut être définie pour chaque service) ;

c) de meilleures performances (les tâches sont partagées) ;

III.4.5.4. L'architecture multi-niveaux.

Dans l'architecture à 3 niveaux, chaque serveur (niveaux 1 et 2) effectue une tâche (un
service) spécialisée. Ainsi, un serveur peut utiliser les services d'un ou plusieurs autres serveurs
afin de fournir son propre service. Par conséquence, l'architecture à trois niveaux est
potentiellement une architecture à N niveaux.

Figure III. 8 : Architecture Client/Serveur à n-niveaux

62
Chapitre IV : Simulation du Réseau de Télécommunication Aéronautique sous
PHP/MySQL : Implémentation d’une application Client/Serveur.

IV.1. Présentation des logiciels utilisés. [16] [17] [18] [19] [20]

IV.1.1. MySQL : Serveur et Serveur et Système de Gestion de Base de Données

MySQL est un système de gestion et conception de base de données relationnelles, comme
beaucoup d’autres dont ORACLE, SYBASE, SQL/Server, etc. Le point commun de tous ces
systèmes est de proposer une représentation extrêmement simple de l’information sous forme de
table. MySQL est libre, gratuit facile à installer, il s'accompagne de nombreux produits permettant
sa gestion, tels que PhpMyAdmin, un driver MyODBC implémenté par défaut dans PHP. C’est un
véritable serveur de base de données SQL multi utilisateur. Il est constitué d'un ensemble de
programmes chargés de gérer une ou plusieurs bases de données, et qui fonctionnent selon une
architecture Client/Serveur.
Le processus mysqld est le serveur de MySQL. Lui seul peut accéder aux fichiers stockant
les données pour lire et écrire des informations. MySQL fournit tout un ensemble de programmes,
que l’on appelle utilitaires, qui sont chargés de dialoguer avec mysqld, par l’intermédiaire d’une
connexion, pour accomplir un type de tâche particulier :
d) mysqldump : permet d'effectuer des sauvegardes ;
e) mysqlimport : permet d'importer des fichiers ASCII dans une BDD ;
f) mysql : est le plus utile, il permet d'envoyer directement des commandes au serveur.
La base de données est un ensemble de fichiers stockant les informations selon un format
propre à MySQL et qui peut – doit – rester inconnu à l’utilisateur. Le serveur est le seul habilité à
lire/écrire dans ces fichiers, en fonction de demandes effectuées par des clients MySQL. Notons
qu’il peut y avoir plusieurs clients accédant simultanément à une même base. Le serveur se charge
de coordonner ces accès.
Les clients de MySQL communiquent avec le serveur pour effectuer des recherches ou des
mises à jour dans la base. Cette communication n’est pas limitée à des processus situés sur la
même machine : il est possible de s’adresser au serveur MySQL par un réseau, notamment dans
notre cas l’ATN.
Les SGBD relationnels offrent non seulement une représentation simple et puissante, mais
également un langage, SQL, pour interroger ou mettre à jour les données. SQL est
incomparablement plus facile à utiliser qu’un langage de programmation classique comme le C.

63
C’est un langage déclaratif qui permet d’interroger une base sans se soucier de la représentation
interne des données, de leur localisation, des chemins d’accès ou des algorithmes nécessaires.

Figure IV. 1 : Environnement MySQL

MySQL est administrable à partir d’un logiciel contenu toujours dans EasyPHP 1.7 appelé
PhpMyAdmin 2.5.3. Ce dernier peut gérer un grand nombre de serveurs MySQL. On peut
spécifier des droits aux utilisateurs pour quelles bases on leur donne accès. En général
PhpMyAdmin peut :
a) créer et supprimer des bases ;
b) créer, copier, supprimer, renommer et retoucher des tables ;
c) faire la maintenance des tables ;
d) effacer, éditer et ajouter des champs ;
e) exécuter toute requête SQL ;
f) créer des schémas de définition des données et des relations ;
g) administrer plusieurs serveurs ;
h) etc.

IV.1.2. PHP
Le langage PHP (Hypertext Preprocessor) a été créé par Rasmus Lerdorf vers la fin de
l’année1994, pour ses besoins personnels. Comme dans beaucoup d’autres cas, la mise à

64
disposition du langage sur l’Internet est à l’origine de son développement par beaucoup de
d’autres utilisateurs qui y ont vu un outil propre à satisfaire leurs besoins.
PHP est un langage de script HTML, compatible avec tous les systèmes d'exploitation ;
Unix, Linux, Windows, Macintosh. L'essentiel de sa syntaxe est emprunté aux langages C, Java et
Perl, mais y ajoute plusieurs fonctionnalités uniques. Le but de ce langage est de permettre aux
développeurs Web de concevoir des sites aux pages dynamiques. La programmation avec PHP
consiste à insérer des lignes de programmation dans la source d'un document html. Ces lignes
représentent une succession de commandes qui doivent être interprétées par la machine qui
exécute le script. PHP est un langage de script qui fonctionne côté serveur, le client ne reçoit que
le résultat du script, sans aucun moyen d'avoir accès au code qui a produit ce résultat.
Le script PHP se trouve dans les balises < ?…?> ou bien < ?php…?>.
L’un des grands atouts de PHP est sa très riche collection d’interfaces avec tout un
ensemble de SGBD. En particulier il est possible à partir d’un script PHP de se connecter à un
serveur mysqld pour récupérer des données que l’on va ensuite afficher dans des documents
HTML. D’une certaine manière, PHP permet de faire d’Apache un client MySQL, ce qui aboutit à
l’architecture de la figure IV. 2.
Il s’agit d’une architecture à trois composantes, chacune réalisant une des trois tâches
fondamentales d’une application :
a) Le navigateur constitue l’interface graphique dont le rôle est de permettre à
l’utilisateur de visualiser et d’interagir avec l’information ;
b) MySQL est le serveur de données ;
c) Enfin l’ensemble des fichiers PHP contenant le code d’extraction, traitement et
mise en forme des données est le serveur d’application, associé à Apache qui se charge de
transférer les documents produits sur l’ATN.
Une architecture où les trois composantes sont franchement séparées et dialoguent par
l’intermédiaire du réseau ATN est concevable mais dans ce que nous avons mis en œuvre, nous
utilisons le serveur mysqld et Apache sur la même machine, mais le passage à une solution
réellement à « trois pôles » ne présente pas, ou peu, de différence du point de vue technique.

IV.1.3. Apache
Apache est le serveur le plus répandu sur Internet. Il s'agit d'une application fonctionnant à
la base sur les systèmes d'exploitation de type Unix, mais il a désormais été porté sur de nombreux
systèmes, dont Microsoft Windows. Apache tire son nom de la façon dont il a été mis au point ("

65
Apatchy server" traduisez "un serveur rafistolé") car il est le fruit d'une multitude de correctifs
logiciels afin d'en faire une solution très sûre. En effet Apache est considéré comme ayant peu de
failles connues. Ainsi dès qu'un bug ou une faille de sécurité est décelée, celui-ci est rapidement
corrigé et une nouvelle version de l'application est éditée.

Programme client
requêtes requêtes SQL
Programme Serveur
ATN serveur mysqld
document(s) document(s) données
HTML HTML

Client HTTP
Fichier Base de
PHP données

Site Web avec scripts PHP et MySQL

Figure IV. 2 : Architecture d’un site Web avec MySQL/PHP

IV.2. Les fonctions utilisées pour la simulation du Réseau de Télécommunication

Aéronautique. [22]

PHP fournit un grand choix de fonctions permettant de manipuler les bases de données.
Entre autres les fonctions de connexion au serveur, de sélection de bases de données, de faire des
requêtes et de se déconnecter.

IV.2.1. La fonction de connexion au serveur mysql_pconnect().

La fonction mysql_pconnect() ouvre une connexion persistante à un serveur MySQL. Sa

syntaxe est la suivante : resource mysql_pconnect (string_server, string_username,
string_password, int client_flags).

Mysql_pconnect retourne un lien persistant positif en cas de succès et sinon FALSE en cas
d'erreur. Tous les arguments sont optionnels et des valeurs par défaut seront utilisées en cas
d'omission (' localhost ', nom d'utilisateur propriétaire du processus, mot de passe vide). Le nom
de l'hôte peut aussi inclure le numéro de port, c'est-à-dire "hostname:port" ou un chemin jusqu'à la
socket :/path/to/socket pour l'hôte local.

66
IV.2.2. La fonction die().

La fonction die() n'est pas une véritable fonction, mais un élément de langage. Sa syntaxe
est la suivante : void die ( string message ). Elle termine l'exécution du script courant et n'a pas
de valeur de retour.

IV.2.3. La fonction mysql_error().

La syntaxe est la suivante : string mysql_error (resource link_identifier ) .

Les erreurs retournées par le serveur MySQL ne génèrent plus de message d'alerte. A la
place, nous devons utiliser la fonction mysql_error() pour lire le contenu du message. Notons que
cette fonction ne retourne que le texte de l'erreur la plus récente, ce qui fait que si vous souhaitez
l'utiliser, vous devez vous assurer de sa valeur avant de lancer une autre requête.

IV.2.4. La fonction mysql_select_db().

Elle sélectionne une base de données MySQL. Sa syntaxe est la suivante :

bool mysql_select_db ( string database_name , resource link_identifier ).

Elle change la base de données active sur la connexion représentée par link_identifier . Si
aucun identifiant n'est spécifié, la dernière connexion est utilisée. S'il n'y a pas de dernière
connexion, la fonction tentera de se connecter seule, avec mysql_connect et les paramètres par
défaut. Cette fonction retourne TRUE en cas de succès, FALSE en cas d'échec.

IV.2.5. La fonction mysql_query()

Cette fonction envoie une requête SQL à la base de données actuellement active sur le
serveur MySQL. Si link_identifier n'est pas précisé, la dernière connexion est utilisée. Si aucune
connexion n'a été ouverte, la fonction tentera d'en ouvrir une, avec la fonction mysql_connect
mais sans aucun paramètre (c'est-à-dire avec les valeurs par défaut).

Sa syntaxe est la suivante : resource mysql_query (string_query, resource

link_identifier).

IV.2.6. La fonction mysql_fetch_assoc().

Sa syntaxe est la suivante : resource mysql_query ( string query , resource

link_identifier ).

Cette fonction retourne un tableau associatif qui contient la ligne lue dans le résultat result,
ou bien FALSE, s'il ne reste plus de lignes à lire.

67
IV.2.7. La fonction mysql_num_rows()
Sa syntaxe est la suivante : int mysql_num_rows (resource result). Elle retourne le
nombre de lignes d'un résultat. Cette commande n'est valide que pour les commandes SELECT.
Pour connaître le nombre de lignes retournées par INSERT, UPDATE ou DELETE, utilisez
mysql_affected_rows.

IV.2.8. La fonction mysql_free_result()

Sa syntaxe est la suivante : bool mysql_free_result ( resource result ).
Cette fonction libère toute la mémoire et les ressources utilisées par la ressource de résultat
result. Elle n'est à appeler que si on a peur d'utiliser trop de mémoire durant l'exécution des scripts.
Toute la mémoire associée à l'identifiant de résultat sera automatiquement libérée.
Cette fonction retourne TRUE en cas de succès, FALSE en cas d'échec.

IV.2.9. La fonction date().

Sa syntaxe est la suivante : string date ( string format , int timestamp )
Elle retourne une date sous forme d'une chaîne, au format donné par la chaîne format . La
date est fournie par le paramètre timestamp , sous la forme d'un timestamp. Par défaut, la date
courante est utilisée.

IV.3. Architecture du modèle utilisé.

Dans la pratique, un aéronef doit pouvoir accéder à des informations contenues dans les
équipements au sol sans l’intermédiaire d’un opérateur au sol. Ce qui allègera le travail des
contrôleurs aériens qui, dans la conception des opérations ATC classiques, devraient donner toutes
genres d’informations dont les pilotes ont besoin pour le bon déroulement du vol. En générale, les
systèmes terminaux, illustrés dans la figure IV. 3 par les entités #1 à #4 qu’ils soient en l’air ou au
sol doivent pouvoir accéder aux ressources du réseau notamment des informations qui sont
stockées dans les types entités #5.
En effet, nous nous sommes intéressés à la conception d’un outil permettant d’accéder à
distance aux informations contenues dans des bases de données représentant les équipements de
traitement au sol ATC.
Nous nous sommes limités aux données météorologiques, aux données ATC ainsi qu’aux
données liées aux différents équipements qui rentrent en jeu dans les opérations aéronautiques.
Ces différentes données seront vues après lors de la présentation des tables constituant notre base
de données.

68
 Entité #1
Entité #2

Entité #5 Entité #3

Entité #4

Figure IV. 3 : Modèle réel

Notons tout de même que beaucoup d’autres types de données peuvent être insérées dans la
base par le biais d’autres tables qui seront à définir. Mais quant à notre simulation nous nous
sommes limité aux données nommées précédemment et à un modèle à deux postes : Client et
Serveur illustré dans la figure IV. 8.
Machine A Machine B

Liaison directe

Client embarqué Serveur avec base de

données
Figure IV. 4 : Modèle pratique

L’outils que nous avons élaboré ne met pas en œuvre le côté connexion physiquement mais
plutôt le côté exploitation des ressources contenues dans les bases de données gérées par les
serveurs au sol. Ainsi donc, on peut considérer que l’entité #1 se connecte au serveur de base de
données représenté par l’entité #5 sans se demander par où passe sa connexion.
D’après ce qui a été développé au paragraphe III.4.5.2, nous avons utilisé une architecture
à trois niveaux pour notre simulation. En niveau 3, nous avons utilisé comme serveur de base de
données le logiciel MySQL 4.0.15. En niveau 2, nous avons comme serveur Web : Apache 1.3.27
et comme gestionnaire de scripts PHP 4.3.3 (serveur d’application). En dernier niveau, nous
utilisons l’Internet Explorer. Notons que tous ces logiciels à part l’Internet Explorer, sont
regroupés dans le logiciel EasyPHP 1.7.

69
IV.4. Base de données.

Notre base de données est constituée de dix tables dont le schéma est illustré par la figure
IV. 5. On y voit les différentes relations qui existent entre les différentes tables ainsi que toutes les
champs utilisés.

Cette base est le cœur du système. Tout incohérence dans la base se répercutera sur la
fonctionnalité du système. Sa conception mérite donc une bonne connaissance de l’environnement
à modéliser. Les scripts de conception de cette base sont donnés en ANNEXE III.

IV.5. Fonctionnement du site Web interfaçant notre base de données.

La fenêtre principale est donnée par la figure IV.6. Cette fenêtre possède deux
fonctionnalités majeures à savoir :

a) donner l’heure en TU (Temps Universel). En effet, il est important à ce que les

informations stockées dans la base aient le même référentiel temporel.

b) fournir un accès aux ressources du système par le biais des liens.

En effet, en cliquant sur les boutons « Information météo », « Données ATC »,

« Infrastructures terrestres » ou « Renseignements », ces derniers nous donnent accès à
d’autres pages qui leurs sont liées respectivement et ayant comme sources respectives
« infomto.htm », « atcdata.htm », « vole.htm » et « infrater.htm ». Tous ces programmes sont
fournis en ANNEXE IV.

Le bouton « Information météo » nous renvoi à deux programmes permettant:

a) de voir toutes les prévisions météorologiques contenues dans la base de données

(Figure IV. 7).

b) aux différentes stations météo d’enregistrer à distance leurs prévisions du temps. En

envoyant le formulaire (figure IV. 8), les données sont enregistrées et dans les secondes qui
suivent, sont disponibles dans le réseau.

Le bouton « Données ATC » nous renvoi à deux programmes :

a) Le premier permet aux pilotes d’envoyer leurs plans de vol au sol, peu importe leur
position (figure IV.9), puis recevoir automatiquement une identité de plan de vol
(figure IV. 10) qui leur sera utile dans les opérations ultérieures.

70
 Figure IV. 5 : Schéma conceptuel de notre base de données

b) Le deuxième permet aux aéronefs d’envoyer leurs coordonnées (figure IV.11) par
période à fixer. Ces coordonnées sont directement enregistrées dans la base de données.

Le bouton « Infrastructures terrestres » nous renvoi à deux programmes :

a) Le premier affiche tous les équipements (VOR, DME, NDB, etc.) répertoriés dans
la base au sol (figure IV.12).

b) Le deuxième donne accès aux caractéristiques des différents aéroports (figure IV.
13).

71
 Figure IV. 6 : Fenêtre principale

Figure IV. 7 : Ensemble des prévisions météorologiques

72
 Figure IV. 8 : Envoi prévision à distance.

Figure IV. 9 : Enregistrement plan de vol

Figure IV. 10 : Récupération de l’Identité du plan de vol

73
 Figure IV. 11 : Report de position

Figure IV. 12 : Consultation données équipements

74
Figure IV. 13 : Caractéristiques aéroports

75
CONCLUSION
L’approche ATN est essentielle pour l’implémentation future d’un réseau mondial de
télécommunication numérique pour l’aviation civile. Ce réseau devra fournir une interopérabilité
globale, être basé sur les sous-réseaux existants (notamment au sol), intégrer les différents sous-
réseaux air/sol prévus (satellite, mode S et VDL), minimiser les équipements correspondants
nécessaires à bord des avions, et supporter les communications de l’ATC comme celles des
compagnies aériennes.
Les communications aéronautiques se distinguent par leurs spécificités mais leur traitement
est intégrable dans un environnement classique de transmission de données. Le réseau de
télécommunication aéronautique n’est autre qu’une architecture d’interconnexion de réseaux.
Cette approche est basée sur le modèle de référence OSI reconnu mondialement. Les
normes ISO sont adoptées, et adaptées si nécessaire à l’environnement spécifique ATN.
L’accent doit être mis sur le routeur ATN à cause de la place occupée par cette composante
au niveau de l’architecture du réseau.
L’utilisation d’outils comme les applications Client/Serveurs peut optimiser l’exploitation
et la gestion du réseau. Ce qui peut, du moins dans le modèle développé dans notre simulation,
alléger le travail des utilisateurs finaux du réseau (contrôleurs aériens, équipes navigants,
administrateurs du réseau, etc).

76
ANNEXES

ANNEXE I : Communications aéronautiques

i. Système du Contrôle de la Circulation aérienne (ATCS)
C'est un système mis en place entre les Institutions du Contrôle de la Circulation aérienne
et l'aéronef pour la sécurité et la mobilité des aéronefs en fournissant un guidage au sol, des
informations au sujet du trafic aérien et les conditions météorologiques aéroportuaires.
a) Téléphone VHF Sans fil, Téléphone HF Sans fil
b) Radar de surveillance de route aérienne (ARSR), Radar de Surveillance Aéroportuaire
(ASR), Radar de Surveillance Secondaire (SSR)
ii. Système de communications du Contrôle de l'air
C'est un système de communications que les compagnies aériennes utilisent pour
déterminer la position de l’avion.
a) Téléphone sans fil à travers la VHF, la HF, et les Communications par satellite Inmarsat
b) Transmission des données par VHF et Communications par satellite Inmarsat
iii. Téléphone dans l’aéronef
C'est un service téléphonique public à bord que les passagers utilisent pour communiquer.
Le service téléphonique aérien par satellite qui utilise la constellation de satellites N-STAR prévu
pour les lignes domestiques a été mis en place depuis octobre 2001. Aussi, dans les régions où il
n'y a aucun fournisseur de services d’équipements radio au sol, le service téléphonique satellitaire
est fourni par les satellites Inmarsat.
iv. Système de Radio Navigation
C'est un système de radio navigation dont les aéronefs utilisent pour déterminer leurs
positions : VOR/DME, NDB, TACAN,
En outre, le développement d'un système de navigation par satellite utilisant le GPS a été
mis en cours.
v. Système d’atterrissage de l’aéronef
C'est un système utilisé pour guider l'aéronef par les ondes radio jusqu’à l'aéroport pour
son atterrissage en toute sécurité.
a) Système d’Atterrissage aux instruments (ILS)
b) Atterrissage par Système de radio navigation
En outre, comme un système de navigation par satellite (GPS) devient populaire, le
développement d'un système qui l'utilise est en progression.

77
vi. Equipements radios chargés à bord.
Il y a différents modèles d’équipements radio disponibles à bord, destinés principalement à
la Navigation et à la Communication.

a) Equipement de navigation : VOR/DME, Transpondeur ATC, Radar météorologique, Radio

Altimètre, Radio de sauvetage, Récepteur ILS, Récepteur ADF,

b) Equipement de communication : Téléphone Satellitaire Sans fil VHF/HF/Inmarsat,

Transmission de Données par Satellite à travers la VHF/Inmarsat, Téléphone dans l’avion.

Satellite GPS Satellite artificiel d’Inmarsat

Centre des liaisons de données

Comm. du contrôle des
opérations Station aéronautique
sol

Communication
aéronautique publique

(Liaison micro)

Centre de contrôle Centre de contrôle terminal Centre de contrôle

Centre de contrôle terminal
aéroport aéroport

Figure A1. 1 : Diagramme du Concept de Communication aéronautique

78
ANNEXE II : Normes utilisées dans l’ATN par couche OSI.

Figure A2. 1 : Normes et protocoles utilisés dans l’ATN.

AP Function : Fonction définissant les protocoles d’application utilisés dans le réseau,

notamment le CPDLC, l’ADS, etc.
ISO 10589 : Protocole IS-IS (Intermediate System To Intermediate System). Protocole de
routage hiérarchique OSI à état de liens, reposant sur le routage DECnet Phase
V selon lequel les systèmes intermédiaires (routeurs) échangent des
informations de routage basées sur une seule métrique permettant de déterminer
la topologie du réseau.
ISO 10747 : Protocole de routage inter-domaines ISIS. Protocole OSI qui précise comment
des routeurs communiquent avec les routeurs d'autres domaines
ISO 7776 : (Link Access Procedure, Balanced) procédure d'accès en mode équilibré.
Protocole de couche liaison de données de la pile de protocole X.25. LAPB est
un protocole orienté binaire dérivé du protocole HDLC.
ISO 8072 : Norme définissant le service de transport en mode connexion.
ISO 8073 : Protocole de transport en mode connexion.
ISO 8208 : Norme de l'UIT-T qui définit comment maintenir les connexions entre ETCD
et ETTD pour permettre l'accès à distance à des terminaux et la communication
entre ordinateurs dans un réseau public de transmission de données. X.25
spécifie le protocole de couche liaison de données LAPB et le protocole PLP
pour la couche réseau. La norme Frame Relay a dans une certaine mesure
supplantée la norme X.25.
ISO 8326 : Service orienté connexion devant être rendu par la couche session. Un additif
ajoute les caractéristiques du mode sans connexion.
ISO 8327 : Spécification du protocole de session orienté connexion.
ISO 8473 : (Connectionless Network Protocol) protocole réseau non orienté connexion.
Protocole de couche réseau OSI qui n'exige pas l'établissement d'un circuit
avant la transmission de données.

79
ISO 8802-2 : (Logical Link Control) contrôle de lien logique. Sous-couche supérieure des
deux sous-couches liaison de données définies par l'IEEE. La sous-couche de la
procédure LLC gère le contrôle d'erreurs, le contrôle de flux, le verrouillage de
trames et l'adressage de la sous-couche MAC. Le protocole LLC le plus
répandu est IEEE 802.2, qui inclut des variantes non orientées connexion et
orientées connexion.

ISO 8802-3 : (Carrier sense multiple access collision detect) détection de porteuse avec
accès multiple. Mécanisme d'accès aux médias par lequel les unités qui sont
prêtes à transmettre des données vérifient d'abord le canal afin de détecter une
porteuse. Si aucune porteuse n'est détectée pendant un délai donné, l'unité peut
transmettre. Si deux unités transmettent simultanément, une collision se produit
et elle est détectée par toutes les unités touchées. Cette collision retarde ensuite
toute nouvelle transmission par ces unités pour une période de temps aléatoire.
L'accès CSMA/CD est utilisé par les protocoles Ethernet et IEEE 802.3.

ISO 9582 : End System To Intermediate System. Protocole OSI qui définit la façon dont
les systèmes d'extrémité (hôtes) se présentent aux systèmes intermédiaires
(routeurs).

TCP/IP : Protocole de contrôle de transmission/protocole Internet. Nom commun utilisé

pour décrire la suite de protocoles développés par le département de la Défense
américain dans les années 70 à l'appui de la construction d'inter-réseaux
mondiaux. TCP et IP sont les deux protocoles les plus connus de cette pile.

80
ANNEXE III : Création de la base de données.
Il existe beaucoup de manières de créer une base de données sur Contrôleur-pilote, nous
avons retenu celle qui fait appel à un fichier SQL (extension : .sql ) pour créer la base et les tables
qui la compose :
Fichier database.sql :

CREATE DATABASE database

# Pour se connecter toujours à la bonne base.
USE database;
DROP TABLE IF EXISTS tbl_aeronef;
DROP TABLE IF EXISTS tbl_aeroport;
DROP TABLE IF EXISTS tbl_equipement;
DROP TABLE IF EXISTS tbl_info_mto;
DROP TABLE IF EXISTS tbl_localite;
DROP TABLE IF EXISTS tbl_model_aeronef;
DROP TABLE IF EXISTS tbl_plan_vol;
DROP TABLE IF EXISTS tbl_position_aeronef;
DROP TABLE IF EXISTS tbl_station_mto;
DROP TABLE IF EXISTS tbl_waypoint;

CREATE TABLE `tbl_aeronef` (`id_aeronef` int(11) NOT NULL auto_increment, `Type`

varchar(20) NOT NULL default '', `Pavillon` varchar(20) NOT NULL default '', `Plan_vol`
varchar(20) NOT NULL default '', PRIMARY KEY (`id_aeronef`)) TYPE=MyISAM
COMMENT='Contient les informations concernants les aéronefs'

CREATE TABLE `tbl_aeroport` (`Nom` varchar(20) NOT NULL default '', `Id_OACI` varchar(20) NOT
NULL default '', `Ville` varchar(20) NOT NULL default '', `Orientation_piste` varchar(20) NOT NULL
default '', `Longueur` varchar(20) NOT NULL default '', `Type_chaussee` varchar(20) NOT NULL default
'', `Emplacement` varchar(20) NOT NULL default '', `Frequence_twr` varchar(20) NOT NULL default '',
`Frequence_mto` varchar(20) NOT NULL default '', `Station_mto` varchar(20) NOT NULL default '',
PRIMARY KEY (`Nom`)) TYPE=MyISAM COMMENT='Contient les informations concernants les
aÚroports'

CREATE TABLE `tbl_equipement` (`Id_OACI` varchar(20) NOT NULL default '', `Type` varchar(20)
NOT NULL default '', `Morse` varchar(20) NOT NULL default '', `Frequence` varchar(20) NOT NULL
default '', `Classe` varchar(20) NOT NULL default '', `Position` varchar(20) NOT NULL default '',
PRIMARY KEY (`Id_OACI`)) TYPE=MyISAM COMMENT='Contient les informations sur les
différents equipements'

CREATE TABLE `tbl_info_mto` (`numero` int(11) NOT NULL auto_increment, `Date_heure` datetime
NOT NULL default '0000-00-00 00:00:00', `id_info_mto` int(11) NOT NULL default '0', `Temperature`
varchar(20) NOT NULL default '', `Pression` varchar(20) NOT NULL default '', `Direction_vent`
varchar(20) NOT NULL default '', `Vitesse_vent` varchar(20) NOT NULL default '', `Type_nuage`
varchar(20) NOT NULL default '', `Couverture_nuageuse` varchar(20) NOT NULL default '', `Turbulence`
varchar(20) NOT NULL default '', `Visibilite` varchar(20) NOT NULL default '', PRIMARY KEY
(`numero`)) TYPE=MyISAM COMMENT='Contient les différents bulletins météorologiques'

CREATE TABLE `tbl_localite` (`Ville` varchar(20) NOT NULL default '', `Etat` varchar(20) NOT NULL
default '', `Pays` varchar(20) NOT NULL default '', `Continent` varchar(20) NOT NULL default '',
PRIMARY KEY (`Ville`)) TYPE=MyISAM COMMENT='Contient les informations concernants une
localité'

81
CREATE TABLE `tbl_model_aeronef` (`Type` varchar(20) NOT NULL default '', `Vitesse_croisiere`
longtext, `Vitesse_max` longtext, `Moteur_reacteur` longtext, `Nbre_helice` longtext, `Max_range`
longtext, `Service_ceiling` longtext, `Capacite_carburant` longtext, `Poids_vide` longtext,
`Poids_max_decollage` longtext, `Longueur` longtext, `Envergure` longtext, `Hauteur` longtext,
`Nbre_siege` longtext, `Useful_load` longtext, `Capacite_cargo` longtext, `Photo` varchar(100) default
NULL, PRIMARY KEY (`Type`)) TYPE=MyISAM

CREATE TABLE `tbl_plan_vol` (`id_plan_vol` int(11) NOT NULL auto_increment, `wpt_depart`

varchar(20) NOT NULL default '', `wpt_arrivee` varchar(20) NOT NULL default '', PRIMARY KEY
(`id_plan_vol`)) TYPE=MyISAM COMMENT='Contient toutes les plans de vols'

CREATE TABLE `tbl_position_aeronef` (`Date_heure` datetime NOT NULL default '0000-00-00

00:00:00', `Id_aeronef` varchar(20) NOT NULL default '', `Niveau_vol` bigint(255) NOT NULL
default '0', `Vitesse` bigint(255) NOT NULL default '0', `Emplacement` varchar(20) NOT NULL
default '', PRIMARY KEY (`Date_heure`)
) TYPE=MyISAM COMMENT='Situe un aéronef'

CREATE TABLE `tbl_station_mto` (`id_station_mto` int(11) NOT NULL auto_increment,

`Id_OACI_station` varchar(20) NOT NULL default '', `libele_station` varchar(40) NOT NULL default '',
PRIMARY KEY (`id_station_mto`)) TYPE=MyISAM COMMENT='Recence toutes les stations
météorologiques'

CREATE TABLE `tbl_waypoint` (`id_wpt` int(11) NOT NULL auto_increment, `Latitude` varchar(20)
NOT NULL default '', `Longitude` varchar(20) NOT NULL default '', `Altitude` varchar(20) default
NULL, PRIMARY KEY (`id_wpt`)) TYPE=MyISAM COMMENT='Contient tous les points utilisé sur la
base'
quit
Les tables sont créées, à l'aide du client mysql, à l’invite de commande par :
mysql> database.sql

82
ANNEXE IV : Création du site.
Les programmes que nous avons élaborés se répartissent en deux catégories. En effet il y a
une différenciation entre la conception de la Base de données sous MySQL (ANNEXE III) et
l’interfaçage de cette base à travers un page Web combinant du HTML et du PHP. Dans cette
annexe, seul l’interfaçage est donné.

Script memcon.php : ce script est utilisé dans chaque page faisant appel à une connexion à
la base de données, c'est-à-dire tout fichier ayant besoin d’un accès à la base de la manière
suivante : <?php require_once('Connections/memcon.php'); ?>.

<?php $hostname_memcon = "techmak"; # nom du serveur hôte

$database_memcon = "database"; # nom de la base de données utilisée
$username_memcon = "karim"; # nom de l’utilisateur
$password_memcon = "karim"; # mot de passe utilisateur
$memcon = mysql_pconnect($hostname_memcon, $username_memcon, $password_memcon) or
die(mysql_error()); ?>

script index.php : c’est le programme principal affichant la fenêtre principale. Ce

programme utilise à deux niveaux le script php “<?php include ("non d’un fichier.php");?>” pour
faire appel à deux sous programmes: menu.php et accueil.php.

a) index.php :
<html>
<head>
<title>Special memory</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body>
<table width="100%" height="100%" border="4" align="center" cellpadding="1" cellspacing="1"
bordercolor="#CCCCCC" bgcolor="#99CCFF">
<tr>
<td width="19%" height="44" align="left" valign="top">
<div align="center">
<p>
<?php $aujourdhui = date("Y-F-j G:i:s "); echo "$aujourdhui"; ?>
UT</p>
</div>
</td>
<td width="81%" rowspan="2" align="center" valign="middle">
<div align="center">
<?php include ("composants/accueil.php");?>
</div></td>
</tr>
<tr><td height="385" align="left" valign="top">
<?php include ("composants/menu.php"); ?></td>
</tr>
</table>
</body>
</html>

83
 b) menu.php
<p align="center"><font color="#000000" size="-1"><strong>Veuillez choisir une
cat&eacute;gorie</strong></font></p>
<table width="90%" height="80" border="1" align="center" cellpadding="0" cellspacing="0"
bordercolor="#CCCCCC">
<tr>
<td height="21" align="left" valign="top" bordercolor="#999999"> <div align="center">
<table width="100%" border="3" cellspacing="0" cellpadding="0">
<tr>
<td bgcolor="#CCCCCC">
<div align="center"><strong><a href="infomto.htm" target="_self">Informations
m&eacute;t&eacute;o</a></strong></div></td>
</tr>
</table>
</div></td>
</tr>
<tr>
<td align="left" valign="top" bordercolor="#999999"> <div align="center">
<table width="100%" border="3" cellspacing="0" cellpadding="0">
<tr>
<td bgcolor="#CCCCCC">
<div align="center"><strong><a href="atcdata.htm" target="_self">Donn&eacute;es
ATC</a></strong></div></td>
</tr>
</table>
</div></td>
</tr>
<tr>
<td align="left" valign="top" bordercolor="#999999"> <div align="center">
<table width="100%" border="3" cellspacing="0" cellpadding="0">
<tr>
<td bgcolor="#CCCCCC">
<div align="center"><strong><a href="infrater.htm" target="_self">Infrastructures
terrestres</a></strong></div></td>
</tr>
</table>
</div></td>
</tr>
</table>
<p align="center"><strong><font size="-1">Une page renseignement vous est
destin&eacute;e</font></strong></p>
<table width="90%" border="1" align="center" cellpadding="0" cellspacing="0"
bordercolor="#CCCCCC">
<tr>
<td bgcolor="#FFFFFF">
<div align="center">
<table width="100%" border="3" cellspacing="0" cellpadding="0">
<tr>
<td bgcolor="#CCCCCC"><div align="center"><strong><a
href="vole.htm">Renseignements</a></strong></div></td>
</tr>
</table>
</div></td>

84
 </tr>
</table>

c) accueil.php
<table width="80%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td height="378">
<p align="center"><strong>Ecole Sup&eacute;rieure Polytechnique d'Antananarivo</strong></p>
<p align="center"><strong>D&eacute;partement T&eacute;l&eacute;communication</strong></p>
<p align="center"><strong><font size="2">Option : Transmission - R&eacute;seau
- Commutation 2002/2003</font></strong></p>
<p align="center"><strong><font size="+2">Simulation du R&eacute;seau de
T&eacute;l&eacute;communication</font></strong></p>
<p align="center"><strong><font size="+2"> A&eacute;ronautique </font></strong><font
size="+2"><strong>(ATN)
sous PHP/MySQL : </strong></font></p>
<p align="center"><font size="+2"><strong>Impl&eacute;mentation d&#8217;une
application Client/Serveur</strong></font><strong>.</strong> </p>
<p align="center"><strong>R&eacute;alis&eacute;e par Monsieur Karim ATTOUMANI
</strong></p>
<p align="center"><strong>sous la direction de </strong></p>
<p align="center"><strong>Monsieur RATSIHOARANA Constant.</strong></p>
</td>
</tr>
</table>

Script infomto.html. Ce script conduit à deux pages : infomto1.php et

forminfomto2.php.

d) infomto1.php
<?php require_once('Connections/memcon.php'); ?>
<?php mysql_select_db($database_memcon, $memcon);
$query_Recordset1 = "SELECT date_heure, id_OACI_station, libele_station, temperature, pression,
direction_vent, vitesse_vent, type_nuage, couverture_nuageuse, turbulence, visibilite FROM
tbl_station_mto, tbl_info_mto WHERE tbl_station_mto.id_station_mto = tbl_info_mto.id_info_mto
ORDER BY tbl_station_mto.Id_OACI_station ";
$Recordset1 = mysql_query($query_Recordset1, $memcon) or die(mysql_error());
$row_Recordset1 = mysql_fetch_assoc($Recordset1);
$totalRows_Recordset1 = mysql_num_rows($Recordset1); ?>
<html>
<head>
<title>Document sans titre</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body>
<p>&nbsp;</p>
<table width="110%" border="0" align="center" cellpadding="0" cellspacing="0">
<tr>
<td> <p align="left"> <strong>La situation globale du temps est donn&eacute;e
dans le tableau suivant qui regroupe toutes les stations repertori&eacute;es :</strong> </p></td>
</tr>

85
</table>
<p>&nbsp;</p><div align="center">
<table width="130%" border="1" align="center" cellpadding="1">
<tr bgcolor="#CCFFFF">
<td><div align="center"><strong>Pr&eacute;vision du</strong></div></td>
<td><div align="center"><strong>Identit&eacute; OACI du Station</strong></div></td>
<td><div align="center"><strong>Nom de la station</strong></div></td>
<td><div align="center"><strong>Temperature</strong></div></td>
<td><div align="center"><strong>Pression</strong></div></td>
<td><div align="center"><strong>Direction du vent</strong></div></td>
<td><div align="center"><strong>Vitesse du vent</strong></div></td>
<td><div align="center"><strong>Type de nuage</strong></div></td>
<td><div align="center"><strong>Couverture nuageuse</strong></div></td>
<td><div align="center"><strong>Turbulence</strong></div></td>
<td><div align="center"><strong>Visibilite</strong></div></td>
</tr>
<?php do { ?>
<tr>
<td><div align="center"><?php echo $row_Recordset1['date_heure']; ?></div></td>
<td><div align="center"><?php echo $row_Recordset1['id_OACI_station']; ?></div></td>
<td><div align="center"><?php echo $row_Recordset1['libele_station']; ?></div></td>
<td><div align="center"><?php echo $row_Recordset1['temperature']; ?></div></td>
<td><div align="center"><?php echo $row_Recordset1['pression']; ?></div></td>
<td><div align="center"><?php echo $row_Recordset1['direction_vent']; ?></div></td>
<td><div align="center"><?php echo $row_Recordset1['vitesse_vent']; ?></div></td>
<td><div align="center"><?php echo $row_Recordset1['type_nuage']; ?></div></td>
<td><div align="center"><?php echo $row_Recordset1['couverture_nuageuse'];?></div></td>
<td><div align="center"><?php echo $row_Recordset1['turbulence']; ?></div></td>
<td><div align="center"><?php echo $row_Recordset1['visibilite']; ?></div></td>
</tr>
<?php } while ($row_Recordset1 = mysql_fetch_assoc($Recordset1)); ?>
</table>
</div>
</body>
</html>
<?php mysql_free_result($Recordset1); ?>

e) forminfomto2.php
<?php require_once('Connections/memcon.php'); ?>
<?php function GetSQLValueString($theValue, $theType, $theDefinedValue = "", $theNotDefinedValue =
"") {
$theValue = (!get_magic_quotes_gpc()) ? addslashes($theValue) : $theValue;
switch ($theType) {
case "text":
$theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL";
break;
case "long":
case "int":
$theValue = ($theValue != "") ? intval($theValue) : "NULL";
break;
case "double":
$theValue = ($theValue != "") ? "'" . doubleval($theValue) . "'" : "NULL";
break;

86
 case "date":
$theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL";
break;
case "defined":
$theValue = ($theValue != "") ? $theDefinedValue : $theNotDefinedValue;
break; }
return $theValue;}
$editFormAction = $HTTP_SERVER_VARS['PHP_SELF'];
if (isset($HTTP_SERVER_VARS['QUERY_STRING'])) {
$editFormAction .= "?" . $HTTP_SERVER_VARS['QUERY_STRING'];}
if ((isset($HTTP_POST_VARS["MM_insert"])) && ($HTTP_POST_VARS["MM_insert"] == "form1"))
{
$insertSQL = sprintf("INSERT INTO tbl_info_mto (Date_heure, id_info_mto, Temperature, Pression,
Direction_vent, Vitesse_vent, Type_nuage, Couverture_nuageuse, Turbulence, Visibilite) VALUES (%s,
%s, %s, %s, %s, %s, %s, %s, %s, %s)",
GetSQLValueString($HTTP_POST_VARS['Date_heure'], "date"),
GetSQLValueString($HTTP_POST_VARS['id_info_mto'], "int"),
GetSQLValueString($HTTP_POST_VARS['Temperature'], "text"),
GetSQLValueString($HTTP_POST_VARS['Pression'], "text"),
GetSQLValueString($HTTP_POST_VARS['Direction_vent'], "text"),
GetSQLValueString($HTTP_POST_VARS['Vitesse_vent'], "text"),
GetSQLValueString($HTTP_POST_VARS['Type_nuage'], "text"),
GetSQLValueString($HTTP_POST_VARS['Couverture_nuageuse'], "text"),
GetSQLValueString($HTTP_POST_VARS['Turbulence'], "text"),
GetSQLValueString($HTTP_POST_VARS['Visibilite'], "text"));
mysql_select_db($database_memcon, $memcon);
$Result1 = mysql_query($insertSQL, $memcon) or die(mysql_error());}
mysql_select_db($database_memcon, $memcon);
$query_Recordset1 = "SELECT * FROM tbl_station_mto ORDER BY tbl_station_mto.id_station_mto";
$Recordset1 = mysql_query($query_Recordset1, $memcon) or die(mysql_error());
$row_Recordset1 = mysql_fetch_assoc($Recordset1);
$totalRows_Recordset1 = mysql_num_rows($Recordset1); ?>
<html>
<head>
<title>Formulaire information m&eacute;t&eacute;o &agrave; distance</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body>
<div align="center">
<p><strong>Veuillez remplir et envoyer la prévision météorologique actuelle.</strong></p>
<form action="<?php echo $editFormAction; ?>" method="post" enctype="multipart/form-data"
name="form1">
<table width="87%" align="center">
<tr valign="baseline">
<td width="443" height="24" align="right" nowrap>
<div align="left">
<p><strong>Pr&eacute;vision du
<?php $aujourdhui = date("Y-m-d G:i:s "); echo "$aujourdhui"; ?>
(yyyy-mm-dd hh:mm:ss) : </strong></p>
</div></td>
<td width="200"><input type="text" name="Date_heure" value="" size="32"></td>
</tr>
<tr valign="baseline">

87
 <td nowrap align="right"><div align="left"><strong>Identit&eacute; info
m&eacute;t&eacute;o (verrifier sur la liste en bas) :</strong></div></td>
<td><input type="text" name="id_info_mto" value="" size="32"></td>
</tr>
<tr valign="baseline">
<td nowrap align="right"><div align="left"><strong>Temperature (&deg;C)
:</strong></div></td>
<td><input type="text" name="Temperature" value="" size="32"></td>
</tr>
<tr valign="baseline">
<td nowrap align="right"><div align="left"><strong>Pression (Pa) :</strong></div></td>
<td><input type="text" name="Pression" value="" size="32"></td>
</tr>
<tr valign="baseline">
<td nowrap align="right"><div align="left"><strong>Direction du vent (ex:
25&deg;) :</strong></div></td>
<td><input type="text" name="Direction_vent" value="" size="32"></td>
</tr>
<tr valign="baseline">
<td nowrap align="right"><div align="left"><strong>Vitesse du vent (knots)
:</strong></div></td>
<td><input type="text" name="Vitesse_vent" value="" size="32"></td>
</tr>
<tr valign="baseline">
<td nowrap align="right"><div align="left"><strong>Type des nuages :</strong></div></td>
<td><input type="text" name="Type_nuage" value="" size="32"></td>
</tr>
<tr valign="baseline">
<td nowrap align="right"><div align="left"><strong>Couverture nuageuse
(1/8 &agrave; 8/8) : </strong></div></td>
<td><input type="text" name="Couverture_nuageuse" value="" size="32"></td></tr>
<tr valign="baseline">
<td nowrap align="right"><div align="left"><strong>Turbulence :</strong></div></td>
<td><input type="text" name="Turbulence" value="" size="32"></td></tr>
<tr valign="baseline">
<td nowrap align="right"><div align="left"><strong>Visibilit&eacute; (NM)
: </strong></div></td>
<td><input type="text" name="Visibilite" value="" size="32"></td></tr>
<tr valign="baseline">
<td nowrap align="right">&nbsp;</td>
<td><input name="Envoyer" type="submit" value="Envoyer la prévision"></td>
</tr>
</table>
<input type="hidden" name="MM_insert" value="form1">
</form>
<p>Ce tableau vous permet d'envoyer vos pr&eacute;visions</p>
</div>
<table width="71%" border="1" align="center" cellpadding="1">
<tr bgcolor="#CCFFFF">
<td width="31%"> <div align="center"><strong>Identit&eacute; info
m&eacute;t&eacute;o</strong></div></td>
<td width="30%"> <div align="center"><strong>Identit&eacute; OACI du station</strong></div></td>
<td width="39%"> <div align="center"><strong>Nom du station</strong></div></td>

88
 </tr>
<?php do { ?>
<tr>
<td><div align="center"><?php echo $row_Recordset1['id_station_mto']; ?></div></td>
<td><div align="center"><?php echo $row_Recordset1['Id_OACI_station']; ?></div></td>
<td><div align="center"><?php echo $row_Recordset1['libele_station']; ?></div></td></tr>
<?php } while ($row_Recordset1 = mysql_fetch_assoc($Recordset1)); ?>
</table>
<p>&nbsp;</p>
</body>
</html>
<?php mysql_free_result($Recordset1); ?>

Script atcdata.htm. Ce script contient deux sous programmes : atcdata-form-plvol.php et

atcdata2-form.php.
f) atcdata-form-plvol.php :
<?php require_once('Connections/memcon.php'); ?>
<?php function GetSQLValueString($theValue, $theType, $theDefinedValue = "", $theNotDefinedValue =
"") {
$theValue = (!get_magic_quotes_gpc()) ? addslashes($theValue) : $theValue;
switch ($theType) {
case "text":
$theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL";
break;
case "long":
case "int":
$theValue = ($theValue != "") ? intval($theValue) : "NULL";
break;
case "double":
$theValue = ($theValue != "") ? "'" . doubleval($theValue) . "'" : "NULL";
break;
case "date":
$theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL";
break;
case "defined":
$theValue = ($theValue != "") ? $theDefinedValue : $theNotDefinedValue;
break;}
return $theValue;}
$editFormAction = $HTTP_SERVER_VARS['PHP_SELF'];
if (isset($HTTP_SERVER_VARS['QUERY_STRING'])) {
$editFormAction .= "?" . $HTTP_SERVER_VARS['QUERY_STRING'];}
if ((isset($HTTP_POST_VARS["MM_insert"])) && ($HTTP_POST_VARS["MM_insert"] == "form1"))
{
$insertSQL = sprintf("INSERT INTO tbl_plan_vol (wpt_depart, wpt_arrivee) VALUES (%s, %s)",
GetSQLValueString($HTTP_POST_VARS['wpt_depart'], "text"),
GetSQLValueString($HTTP_POST_VARS['wpt_arrivee'], "text"));
mysql_select_db($database_memcon, $memcon);
$Result1 = mysql_query($insertSQL, $memcon) or die(mysql_error());
$insertGoTo = "recup-id-plvol.php";
if (isset($HTTP_SERVER_VARS['QUERY_STRING'])) {
$insertGoTo .= (strpos($insertGoTo, '?')) ? "&" : "?";
$insertGoTo .= $HTTP_SERVER_VARS['QUERY_STRING'];}
header(sprintf("Location: %s", $insertGoTo));}

89
mysql_select_db($database_memcon, $memcon);
$query_Recordset1 = "SELECT id_plan_vol, wpt_depart, wpt_arrivee FROM tbl_plan_vol";
$Recordset1 = mysql_query($query_Recordset1, $memcon) or die(mysql_error());
$row_Recordset1 = mysql_fetch_assoc($Recordset1);
$totalRows_Recordset1 = mysql_num_rows($Recordset1);
mysql_select_db($database_memcon, $memcon);
$query_Recordset2 = "SELECT id_wpt, Latitude, Longitude FROM tbl_waypoint";
$Recordset2 = mysql_query($query_Recordset2, $memcon) or die(mysql_error());
$row_Recordset2 = mysql_fetch_assoc($Recordset2);
$totalRows_Recordset2 = mysql_num_rows($Recordset2); ?>
<html>
<head>
<title>Document sans titre</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td><div align="center">Le centre ATC a besoint de votre Plan de Vol pour
le bon d&eacute;roulement des op&eacute;rations de contr&ocirc;le. </div></td>
</tr>
</table>
<form method="post" name="form1" action="<?php echo $editFormAction; ?>">
<table align="center">
<tr valign="baseline">
<td width="162" align="right" nowrap><div align="left">Waypoint de d&eacute;part:</div></td>
<td width="241"><input type="text" name="wpt_depart" value="" size="32"></td>
</tr>
<tr valign="baseline">
<td nowrap align="right"><div align="left">Waypoint d'arriv&eacute;e:</div></td>
<td><input type="text" name="wpt_arrivee" value="" size="32"></td>
</tr>
<tr valign="baseline">
<td nowrap align="right">&nbsp;</td>
<td><input type="submit" value="Envoyer le Plan de Vol"></td>
</tr>
</table>
<input type="hidden" name="MM_insert" value="form1">
</form>
<p>&nbsp;</p>
<p>&nbsp;</p>
<table width="50%" border="1" align="center" cellpadding="1">
<tr>
<td><div align="center">id_wpt</div></td>
<td><div align="center">Latitude</div></td>
<td><div align="center">Longitude</div></td>
</tr>
<?php do { ?>
<tr>
<td><div align="center"><?php echo $row_Recordset2['id_wpt']; ?></div></td>
<td><div align="center"><?php echo $row_Recordset2['Latitude']; ?></div></td>
<td><div align="center"><?php echo $row_Recordset2['Longitude']; ?></div></td></tr>
<?php } while ($row_Recordset2 = mysql_fetch_assoc($Recordset2)); ?>

90
</table>
</body>
</html>
<?php
mysql_free_result($Recordset1);
mysql_free_result($Recordset2); ?>

g) atcdata2-form.php
<?php require_once('Connections/memcon.php'); ?>
<?php function GetSQLValueString($theValue, $theType, $theDefinedValue = "", $theNotDefinedValue =
"") {
$theValue = (!get_magic_quotes_gpc()) ? addslashes($theValue) : $theValue;
switch ($theType) {
case "text":
$theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL";
break;
case "long":
case "int":
$theValue = ($theValue != "") ? intval($theValue) : "NULL";
break;
case "double":
$theValue = ($theValue != "") ? "'" . doubleval($theValue) . "'" : "NULL";
break;
case "date":
$theValue = ($theValue != "") ? "'" . $theValue . "'" : "NULL";
break;
case "defined":
$theValue = ($theValue != "") ? $theDefinedValue : $theNotDefinedValue;
break; }
return $theValue;}
$editFormAction = $HTTP_SERVER_VARS['PHP_SELF'];
if (isset($HTTP_SERVER_VARS['QUERY_STRING'])) {
$editFormAction .= "?" . $HTTP_SERVER_VARS['QUERY_STRING'];}
if ((isset($HTTP_POST_VARS["MM_insert"])) && ($HTTP_POST_VARS["MM_insert"] == "form2"))
{
$insertSQL = sprintf("INSERT INTO tbl_position_aeronef (Date_heure, Id_aeronef, Niveau_vol, Vitesse,
Emplacement) VALUES (%s, %s, %s, %s, %s)",
GetSQLValueString($HTTP_POST_VARS['Date_heure'], "date"),
GetSQLValueString($HTTP_POST_VARS['Id_aeronef'], "text"),
GetSQLValueString($HTTP_POST_VARS['Niveau_vol'], "int"),
GetSQLValueString($HTTP_POST_VARS['Vitesse'], "int"),
GetSQLValueString($HTTP_POST_VARS['Emplacement'], "text"));
mysql_select_db($database_memcon, $memcon);
$Result1 = mysql_query($insertSQL, $memcon) or die(mysql_error());
$insertGoTo = "atcdata.htm";
if (isset($HTTP_SERVER_VARS['QUERY_STRING'])) {
$insertGoTo .= (strpos($insertGoTo, '?')) ? "&" : "?";
$insertGoTo .= $HTTP_SERVER_VARS['QUERY_STRING'];}
header(sprintf("Location: %s", $insertGoTo));}
mysql_select_db($database_memcon, $memcon);
$query_Recordset1 = "SELECT Date_heure, Id_aeronef, Niveau_vol, Vitesse, Emplacement FROM
tbl_position_aeronef";
$Recordset1 = mysql_query($query_Recordset1, $memcon) or die(mysql_error());

91
$row_Recordset1 = mysql_fetch_assoc($Recordset1);
$totalRows_Recordset1 = mysql_num_rows($Recordset1);
mysql_select_db($database_memcon, $memcon);
$query_Recordset2 = "SELECT * FROM tbl_aeronef";
$Recordset2 = mysql_query($query_Recordset2, $memcon) or die(mysql_error());
$row_Recordset2 = mysql_fetch_assoc($Recordset2);
$totalRows_Recordset2 = mysql_num_rows($Recordset2);
mysql_select_db($database_memcon, $memcon);
$query_Recordset3 = "SELECT id_wpt, Latitude, Longitude FROM tbl_waypoint ORDER BY Latitude
ASC";
$Recordset3 = mysql_query($query_Recordset3, $memcon) or die(mysql_error());
$row_Recordset3 = mysql_fetch_assoc($Recordset3);
$totalRows_Recordset3 = mysql_num_rows($Recordset3); ?>
<html>
<head>
<title>Formulaire position de l'a&eacute;ronef</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body>
<table width="80%" border="0" align="center" cellpadding="0" cellspacing="0">
<tr>
<td>
<div align="center">Cette formulaire nous permet de reccueillir votre
position sur une p&eacute;riode de x temps &agrave; fixer avec les centres
ATC. En effet, &agrave; chaque fois que vous l'envoyer vos coordonn&eacute;es
seront stock&eacute;es dans la BD centrale :</div></td>
</tr>
</table>
<hr align="center" width="50%">
<form method="post" name="form2" action="<?php echo $editFormAction; ?>">
<table width="597" align="center">
<tr valign="baseline">
<td width="386" align="right" nowrap><div align="left">Report du <strong>
<?php $aujourdhui = date("Y-m-d G:i:s "); echo "$aujourdhui"; ?>
</strong><strong>(yyyy-mm-dd hh:mm:ss)</strong> :</div></td>
<td width="199"><input type="text" name="Date_heure" value="" size="32"></td>
</tr>
<tr valign="baseline">
<td nowrap align="right"><div align="left">Identit&eacute; de l'aeronef*
:</div></td>
<td><input type="text" name="Id_aeronef" value="" size="32"></td>
</tr>
<tr valign="baseline">
<td nowrap align="right"><div align="left">Niveau_vol : (ex : FL 150, &eacute;crivez
150)</div></td>
<td><input type="text" name="Niveau_vol" value="" size="32"></td>
</tr>
<tr valign="baseline">
<td nowrap align="right"><div align="left">Vitesse en knots :</div></td>
<td><input type="text" name="Vitesse" value="" size="32"></td>
</tr>
<tr valign="baseline">
<td nowrap align="right"><div align="left">Point de report** : </div></td>

92
 <td><input type="text" name="Emplacement" value="" size="32"></td>
</tr>
<tr valign="baseline">
<td nowrap align="right">&nbsp;</td>
<td><input type="submit" value="Envoyer les coordonnées"></td>
</tr>
</table>
<input type="hidden" name="MM_insert" value="form2">
</form>
<table width="82%" border="0" align="center" cellpadding="0" cellspacing="0">
<tr>
<td>
<p align="left">(<strong>*</strong>) <em><font size="-1">Veuillez verrifier votre
identit&eacute; sur le tableau 1.</font></em></p>
<p>(<strong>**</strong>) <em><font size="-1">Choisissez parmi les identit&eacute;s
des coordonn&eacute;es ps&eacute;sents dans le tableau 2.</font></em></p>
</td>
</tr>
</table>
<p>&nbsp;</p>
<table width="100%" border="0" align="center" cellpadding="0" cellspacing="0">
<tr>
<td>
<div align="center">Tableau 1</div></td>
<td>
<div align="center">Tableau 2</div></td>
</tr>
<tr>
<td align="right" valign="top">
<table border="1" cellpadding="1">
<tr>
<td><div align="center">id_aeronef</div></td>
<td><div align="center">Type</div></td>
<td><div align="center">Immatriculation</div></td>
<td><div align="center">Plan_vol</div></td>
</tr>
<?php do { ?>
<tr>
<td><div align="center"><?php echo $row_Recordset2['id_aeronef']; ?></div></td>
<td><div align="center"><?php echo $row_Recordset2['Type']; ?></div></td>
<td><div align="center"><?php echo $row_Recordset2['Immatriculation']; ?></div></td>
<td><div align="center"><?php echo $row_Recordset2['Plan_vol']; ?></div></td>
</tr>
<?php } while ($row_Recordset2 = mysql_fetch_assoc($Recordset2)); ?>
</table>
</td>
<td align="left" valign="top">
<table border="1" align="center" cellpadding="1">
<tr>
<td><div align="center">id_wpt</div></td>
<td><div align="center">Latitude</div></td>
<td><div align="center">Longitude</div></td>
</tr>

93
 <?php do { ?>
<tr>
<td><div align="center"><?php echo $row_Recordset3['id_wpt']; ?></div></td>
<td><div align="center"><?php echo $row_Recordset3['Latitude']; ?></div></td>
<td><div align="center"><?php echo $row_Recordset3['Longitude']; ?></div></td>
</tr>
<?php } while ($row_Recordset3 = mysql_fetch_assoc($Recordset3)); ?>
</table>
</td>
</tr>
</table>
<p>&nbsp;</p>
</body>
</html>
<?php
mysql_free_result($Recordset1);
mysql_free_result($Recordset2);
mysql_free_result($Recordset3); ?>

Script infrater.htm, ce script fait appel à deux sous programmes : infrater1.php et infrater2.php.
h) infrater1.php
<?php require_once('Connections/memcon.php'); ?>
<?php mysql_select_db($database_memcon, $memcon);
$query_Recordset2 = "SELECT tbl_equipement.Id_OACI, tbl_equipement.Type, tbl_equipement.Morse,
tbl_equipement.Frequence, tbl_equipement.Classe, tbl_waypoint.Latitude, tbl_waypoint.Longitude FROM
tbl_equipement, tbl_waypoint WHERE tbl_waypoint.id_wpt=tbl_equipement.`Position`";
$Recordset2 = mysql_query($query_Recordset2, $memcon) or die(mysql_error());
$row_Recordset2 = mysql_fetch_assoc($Recordset2);
$totalRows_Recordset2 = mysql_num_rows($Recordset2); ?>
<html>
<head>
<title>Equipements</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body>
<table width="100%" border="0" cellspacing="0" cellpadding="0"><tr>
<td bordercolor="#FFFFFF"><div align="center">Voici les diff&eacute;rents
&eacute;quipements disponibles dans le FIR d'Antananarivo avec leurs diff&eacute;rentes
caract&eacute;ristiques :</div></td></tr>
</table>
<p>&nbsp;</p>
<table width="80%" border="1" align="center" cellpadding="1">
<tr bgcolor="#99FFFF">
<td> <div align="center"><strong>Identit&eacute; OACI de l'&eacute;quipement</strong></div></td>
<td> <div align="center"><strong>Type</strong></div></td>
<td> <div align="center"><strong>Code Morse g&eacute;n&eacute;r&eacute;</strong></div></td>
<td> <div align="center"><strong>Frequence</strong></div></td>
<td> <div align="center"><strong>Classe</strong></div></td>
<td> <div align="center"><strong>Latitude</strong></div></td>
<td> <div align="center"><strong>Longitude</strong></div></td></tr>
<?php do { ?><tr>
<td><div align="center"><?php echo $row_Recordset2['Id_OACI']; ?></div></td>
<td><div align="center"><?php echo $row_Recordset2['Type']; ?></div></td>

94
 <td><div align="center"><?php echo $row_Recordset2['Morse']; ?></div> </td>
<td><div align="center"><?php echo $row_Recordset2['Frequence']; ?></div></td>
<td><div align="center"><?php echo $row_Recordset2['Classe']; ?></div></td>
<td><div align="center"><?php echo $row_Recordset2['Latitude']; ?></div></td>
<td><div align="center"><?php echo $row_Recordset2['Longitude']; ?></div></td></tr>
<?php } while ($row_Recordset2 = mysql_fetch_assoc($Recordset2)); ?>
</table>
</body>
</html>
<?php mysql_free_result($Recordset2); ?>

i) infrater2.php
<?php require_once('Connections/memcon.php'); ?>
<?php mysql_select_db($database_memcon, $memcon);
$query_Recordset1 = "SELECT tbl_aeroport.Nom, tbl_aeroport.Id_OACI, tbl_aeroport.Ville,
tbl_aeroport.Orientation_piste, tbl_aeroport.Longueur, tbl_aeroport.Type_chaussee,
tbl_aeroport.Frequence_twr, tbl_aeroport.Frequence_mto, tbl_waypoint.Latitude, tbl_waypoint.Longitude,
tbl_waypoint.Altitude FROM tbl_aeroport, tbl_waypoint WHERE tbl_waypoint.id_wpt =
tbl_aeroport.Emplacement";
$Recordset1 = mysql_query($query_Recordset1, $memcon) or die(mysql_error());
$row_Recordset1 = mysql_fetch_assoc($Recordset1);
$totalRows_Recordset1 = mysql_num_rows($Recordset1); ?>
<html>
<head>
<title>Données aéroportuaires</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body>
<table width="100%" border="0" align="center" cellpadding="0" cellspacing="0"><tr>
<td><div align="center">Ici nous avons acc&egrave;s aux caract&eacute;ristiques
de chaque a&eacute;roport sans oublier leurs localisation. Ceci demontre
une fois de plus la capacit&eacute; de notre syst&egrave;me &agrave; lier
des tables pour donn&eacute;es des r&eacute;sultats probants sur une entit&eacute;.</div></td></tr>
</table>
<pre>&nbsp;</pre>
<table width="110%" border="1" cellpadding="1">
<tr bgcolor="#CCFFFF">
<td><div align="center"><strong>Nom de l'a&eacute;roport</strong></div></td>
<td><div align="center"><strong>Identit&eacute; OACI</strong></div></td>
<td><div align="center"><strong>Ville </strong></div></td>
<td><div align="center"><strong>Orientation de la piste</strong></div></td>
<td><div align="center"><strong>Longueur de piste</strong></div></td>
<td><div align="center"><strong>Type de chauss&eacute;e</strong></div></td>
<td><div align="center"><strong>Frequence ATC</strong></div></td>
<td><div align="center"><strong>Frequence AUTOMET</strong></div></td>
<td><div align="center"><strong>Latitude</strong></div></td>
<td><div align="center"><strong>Longitude</strong></div></td>
<td><div align="center"><strong>Altitude</strong></div></td>
</tr>
<?php do { ?><tr>
<td><div align="center"><?php echo $row_Recordset1['Nom']; ?></div></td>
<td><div align="center"><?php echo $row_Recordset1['Id_OACI']; ?></div></td>
<td><div align="center"><?php echo $row_Recordset1['Ville']; ?></div></td>

95
 <td><div align="center"><?php echo $row_Recordset1['Orientation_piste']; ?></div></td>

<td><div align="center"><?php echo $row_Recordset1['Longueur']; ?></div></td>

<td><div align="center"><?php echo $row_Recordset1['Type_chaussee']; ?></div></td>

<td><div align="center"><?php echo $row_Recordset1['Frequence_twr']; ?></div></td>

<td><div align="center"><?php echo $row_Recordset1['Frequence_mto']; ?></div></td>

<td><div align="center"><?php echo $row_Recordset1['Latitude']; ?></div></td>

<td><div align="center"><?php echo $row_Recordset1['Longitude']; ?></div></td>

<td><div align="center"><?php echo $row_Recordset1['Altitude']; ?></div></td></tr>

<?php } while ($row_Recordset1 = mysql_fetch_assoc($Recordset1)); ?>

</table>

<p>&nbsp;</p>

<p>&nbsp;</p>

</body>

</html>

<?php mysql_free_result($Recordset1); ?>

96
 Bibliographie

[1] OACI : « Manuel du réseau de télécommunication aéronautique (ATN) », Document

9578-AN/935 Première Edition 1991
[2] ASECNA Service CNS/ATM, « Communications, Navigation and Surveillance / Air
Trafic Management (CNS/ATM)», Document technique
[3] http://www.fans-is.com
[4] OKI Electric Industry Co, “ATN Router Overview”, OKI Network Solution for a Global
Society 29 Mars 2003
[5] African Airports, « Implementing the CNS/ATM system », Africa’s airport and Air Trafic
Management Journal October/December 1996.
[6] G. Pujolle, “Les réseaux” Edition Eyrolles (3ème édition mise à jour) Février 2000
[7] A. Ratsimbazafy, “Téléinformatique”, Cours 3ème année, Dép. Télécommunication -
ESPA, AU 2000-2001
[8] F. Rajaonarivony, “Réseaux Locaux et TCP/IP”, Cours 5ème année, Télécommunication -
ESPA, AU 2002-2003
[9] P. Nicolas, « Cours de réseaux – Maîtrise d’Informatique », U.F.R. Science de l’Université
d’Angers.
[10] E. Randriarijaona “Les réseaux d’entreprise”, Cours 5ème année, Dép.
Télécommunication- ESPA, AU 2002-2003.
[11] Y. Sagnier, « L’ATN… ou le Réseau de Télécommunication Aéronautique », CENA 1997.
[12] G. Clark., et J. Caïn, « Error-Correction Coding for Digital Communications », Plenum,
1988
[13] S. Gallagher, M. Olson, J. McKinley, N. Blake, D. Blythe, J. Heletz, G. Hamilton, B. Kolb,
A. Homans, K. Zemrowski, S. Decker, C. Pate, Dr. P. Carlock, D. Johnson,
“Communications System Architecture Development for Air Trafic Management and
Aviation Weather Information Dissemination”, Science Applications International
Corporation, Mai 2000
[14] Sixth Meeting of CNS/MET Sub-Group of APANPIRG « ASIA/PAC (ICD) ATS Message
Handling System (AMHS) »,. Appendix F to the Report. Version 1.0 9 Avril 2002
[15] Henkof, T. Whyman, “Aeronautical Contrôleur-pilote Network Panel Working Group
Two”, ATNP/WG2/WP/174 Eurocontrol 10 Octobre 1995.

97
[16] P. Rigaux, « Pratique de MySQL et PHP », Edition O’REILLY, Paris 2001.

[17] www.mysql.com

[18] www.php.net

[19] www.easyphp.org

[20] www.apache.org

[21] www.commentcamarche.net

[22] http://www.php.net/docs.php

98
 Auteur :
Nom : Karim
Prénom : ATTOUMANI MOHAMED
Adresse :
- ESPA CUR Vontovorona Bloc 03 Porte 083 BP 3826 Tana 101 Madagascar
- email: attoukarim@caramail.com
- Aéroport International Moroni Prince Saïd Ibrahim S/C ATTOUMANI
MOHAMED (SHARLY) BP 1003 Moroni Comores.
Tél. : - 00269 73 37 09 (Union des Comores)
- 00261 3202 378 99 (Madagascar)

Titre du mémoire : “ETUDE DU RESEAU DE TELECOMMUNICATION

AERONAUTIQUE (ATN)”
Nombre de pages : 100
Nombre de tableaux : 2
Nombre de figures : 39

Mots clés : ATN, CNS/ATM, sous-réseau air/sol, topologie mobile, routeur ATN, serveur
embarqué, application Client/Serveur, AMHS, VDL, ADS-B, Automet, SGBDR, PHP, MySQL,
etc.

Directeur de mémoire : Monsieur RATSIHOARANA Constant.

99
Résumé :
Ce mémoire nous a permis de découvrir le Réseau de Télécommunication Aéronautique

(ATN) qui n’est autre qu’une interconnexion de réseaux aéronautiques existants et à venir.

Dans la première partie, nous offrons la possibilité aux lecteurs de comprendre

l’environnement de communication ainsi que les services qui doivent êtres fournis aux utilisateurs.

Les particularités de ce réseau sont analysées et adaptées selon le concept OSI.

Quant à la deuxième partie, nous avons implémenté une application Client/Serveur

reposant sur un SGBDR sous MySQL avec une interface dynamique sous PHP pouvant être

utilisé dans l’ATN.

Abstract :
This memory allowed us to discover the Aeronautical Telecommunication Network (ATN)

that is merely an interconnection of existing and futures aeronautical networks.

In the first part, we offer the possibility to the readers to understand the environment of

communication as well as the services that owe to be provided to the users. The particularities of

this network analyzed and adapted according to the OSI concept.

As for the second part, we have implemented a Client/Server application based on a

DBMS (Data Base Management System) under MySQL with a dynamic interface under PHP

which can be used in the ATN.

100