AFTN/CIDIN system SUN/Solaris platform Linux platform

Transcription

1 In the context of the ATN (Aeronautical Telecommunication Network), Vitrociset provides some systems for the exchanging of ATS (Air Traffic Service) messages. The systems cover the exchanging of messages on the AFTN/CIDIN (Aeronautical Fixed Telecommunication Network / Common ICAO Data Interchange Network) and the AMHS (ATS Message Handling System) networks. The systems are provided on the following platforms: AFTN/CIDIN system SUN/Solaris platform Linux platform AMHS system Linux platform AFTN/CIDIN SYSTEM Application The application is part of the operating context of the AFTN/CIDIN network, whose architecture has been defined by the ICAO according to a schema which defines the areas of responsibility of each node of the network. The nodes of the network are connected by peer-to-peer connections and they exchange messages on the basis of a predefined routing table. The routing table defines alternate paths when the predefined routing is unavailable; the alternate path isn't selected automatically, instead it needs to be agreed among the nodes by the operative personnel. Description The AFTN/CIDIN system is a message-switch application, which allows the exchanging of ATS messages on the AFTN/CIDIN network. The application works on the basis of to the "store-and-forward" mechanism according to the ICAO recommendations (Annex 10 vol. II, EUR CIDIN Manual and so on). The CIDIN component implements 1

2 the CIDIN relay functionality, which is the routing of messages at packet level (CIDIN level 3b). The system provides end-user applications, which allow the sending and receiving of messages (AFTN position and CIDIN Operator Position), with an assisted-compilation mechanism for the most common message types (FPL, NOTAM and so on). The system includes a human machine interface (HMI) for the configuration, command and control of the system itself. The HMI includes: for the configuration, a dedicated application allows to configure the system online for the commands, the possibility of managing lines, logical circuits, queues, etc. for the control, some real-time monitoring applications showing the status of the system resources (hardware, software components, lines, remote network centres) Furthermore, the system provides other applications for the analysis of the log files, the statistical data and so on. Access to the system is protected by a configurable security mechanism based on some privilege levels. Generic configuration The system is proposed in redundant configuration, as shown in the figure: 2 servers in duplicated LAN with shared database on external RAID 5 disks An X.25 switch for the management of the X.25 lines, both AFTN and CIDIN Terminal servers for V.24 and telegraphic lines. The telegraphic lines are implemented by suitable converters on the RS232 ports of the terminal server 2

3 Architecture The system integrates the AFTN and CIDIN functionalities by an architecture implemented on more levels. Two dedicated components manage the AFTN and CIDIN and communicate with the core message-switch by a layer of protocol interface, which allows the exchanging of messages between the AFTN and CIDIN network by an automatic mechanism of format conversion. Every received message from these components is passed to the final layer of message-switch through the protocol interface layer. The message-switch layer, which is the core component of the system, routes the messages over the two networks according to the AFTN and CIDIN routing tables. The messages are passed again to the protocol interface layer and then to the AFTN or CIDIN component. The system is implemented in fault tolerant configuration. A node supervisor, activated on both servers, synchronizes the access to the shared resources (disks, lines and so on). The HMI interface is, instead, activated on workstations connected to the system by an internal duplicated LAN and has been developed in Linux/Qt environment. AFTN component The AFTN component supports the following communication protocols: TCP/IP X.25 V.24 Telegrafic lines Access to lines is implemented by external hardware components, such as terminal servers, routers and so on. This component is strictly conformant with the ICAO document "Annex 10 - volume II". However, on the basis of the extensions requested by EuroControl for the ATS message format, it supports messages with text up to 16 Kb (ADEXP format). The maximum length of text can be configured specifically for each circuit, both in input and in output. 3

4 CIDIN component The CIDIN component's design is strictly conformant to the "Eur CIDIN Manual". It implements the three separate CIDIN layers 3a, 3b e 4 and provides the functionalities: CIDIN relay at 3b level Automatic switch between primary and secondary Virtual circuits Automatic and configurable retransmission of the unacknowledged messages by remote CIDIN centres. Support for the transport of AFTN messages and CIDIN operator messages at level 4. This component supports the extensions requested by EuroControl for the ATS message format (text up to 16 Kb in ADEXP format). This limitation applies at level 4 only, because the level 3 doesn't have any limitations. AMHS SYSTEM Application The AMHS system is an application that allows the exchanging of ATS messages among the users of the ATN. The AMHS is devised in order to offer a generic architecture and technical solutions so as to eliminate the heterogeneity of several types of protocols used on the ATN network. Some European Countries are already operative with AMHS system at the national level. The AMHS application works on objects of analogous format to the , so it is possible to manage and exchange more typologies of information like text, attachments and so on. Currently the AMHS system is going to replace the existing AFTN/CIDIN systems. Overview The AMHS application is based on switch nodes, named MTA (Message Transfer Agent) and end-user positions, named UA (User Agent). The AMHS can be integrated with other communication systems (i.e. AFTN/CIDIN) by interface components generically named AU (Access Unit), which are gateways. Furthermore, there are other components with mailbox functionalities, named MS (Message Store). 4

5 The communication among the various components of the AMHS is implemented through some standardized protocols (P1, P2, P3, P7). These protocols allow the exchanging of messages on different networks. The AMHS is based in the protocols ITU-T X.400/X.500. The use of such protocols into the AMHS has been standardized by the ICAO in the Doc. 9705/AN956. The Vitrociset AMHS is compliant with all the ICAO recommendations. Its development is strictly based on the recommendations of ICAO Doc. 9705/AN956, furthermore the variations requested by the ICAO Planning Group have been taken into account. Description The AMHS makes use of the MHS (Message Handling Service), defined into the specifications ITU-T X.400, made by ITU-T and ISO/IEC. The MHS implements a mechanism of message exchanging based on the store-and-forward procedures. The types of AMHS messages are: IPM (Inter Personal Message): generic ATS message IPN (Inter Personal Notification): notification, whenever required, of the reception of the message by the final user DR (Delivery Report): it's a message originated by the MTS to the originator MTA to confirm the successful sending of the message NDR (Non-Delivery Report): it's a message generated by the system to inform the MTA and eventually the sender of transmission's problems The AMHS implements the service for the transport of ATS messages in two possible ways: Basic ATS msg service: it extends the AFTN capabilities (unlimited number of addresses, unlimited length of messages, NDR possibility, indication of the subject of the message) Extended ATS msg service: it extends the functionalities of the Basic service (directory service, security mechanisms, attachments support) The ATS Message Service can be used both by direct users (User Agent) and indirect (AFTN/AMHS Gateway or CIDIN/AMHS gateway). Addressing The X.400 standard identifies the users by an O/R-Name. This consists of a directory name, an O/R-Address or both. The OR-Address is a set of information that uniquely identify the user who has generated the message (Originator) or the receiving user (Recipient). An AMHS O/R-address contains the following information: C = Country ADMD = Administrative Management Domain 5

6 PRMD = Private Management Domain O = Organization OU = Organizational Unit CN = Common Name The ICAO has provided a standard addressing scheme named CAAS (Common AMHS Addressing Scheme). Example: C=XX; ADMD=ICAO; PRMD=Italy; O=ENAV; OU=LIII; CN=LIIIYFYX Architecture The AMHS system has a modular architecture. The compatibility with the AFTN/CIDIN network is implemented by a gateway between the AMHS and the AFTN/CIDIN systems. The specifications of the AMHS/AFTN are in the ICAO Doc. 9705/AN956. The figure shows the system's components and its interfaces. The AMHS system includes a User Agent as end-user position. AFTN Component This component interfaces the existing AFTN system with the AMHS environment. For the AFTN part, the standard AFTN protocol is used, according to the recommendations of ICAO Annex 10, volume II; for the AMHS part, the component communicates by another component (MTCU). The aim of this component is to exchange messages with the AFTN system with an autonomous management of some service and control (CH) messages. MTCU The MTCU (Message Transfer and Control Unit) is the core of the gateway and is dedicated to the conversion of the messages from AMHS to AFTN and vice versa. ATN Component The ATN component interfaces the AMHS and includes an MTA. In the proposed architecture, the ATN component is implemented by an MTA based on the Isode software and associated interfaces. 6

7 Control Position The control position manages the unsupported or corrupted messages. The AMHS system's architecture is shown in the following figure: AMHS/AFTN GATEWAY The gateway allows the following configurations between the AMHS and AFTN systems: UA > AFTN AFTN > UA AFTN > AFTN UA > UA In such a way it's possible to exchange any message typologies on the ATN network with the maximum flexibility. The MTCU is the component of the gateway responsible for: Message format conversion Priority conversion Mapping of the address logging The MTCU processes the AFTN service messages, converting the following typologies: AFTN SVC Address Unknown < > AMHS ' NDR' AFTN SS Ack < > AMHS ' IPN/RN' The AFTN Component implements the interface between the MTCU and the AFTN system. It's responsible for the service messages received from the AFTN system, except for the service messages: SVC Address Unknown and SS Ack. The AFTN component is implemented according to the recommendations of the 7

8 Annex 10 (vol. II), so as to make it identical to an AFTN station. The Control Position receives the messages with errors (for example format or transmission errors). The Control Position receives also all the alarms from the gateway and provides an interface to correct the errors in the corrupted AFTN messages. The ATN Component interfaces the AMHS and the MTCU component; it implements an MTA (with X.400), it can generate automatic messages (NDR) in case of failed transmission due to unknown recipient in the message or when it receives a message with an unsupported format. The interface to an X.400 MTA is based on software developed by Isode. Vitrociset has a partnership with this company. The provided functionalities allow building and analyzing X.400 messages or reports, with the means to transfer generic objects in X