ATN/AMHS IMPLEMENTATION IN ASIA/PACIFIC REGION SP/1 ATN/AMHS IMPLEMENTATION IN ASIA/PACIFIC REGION Sujan Kumar Saraswati ICAO Asia Pacific Office, Bangkok This presentation traces the history of ATN and AMHS implementation in the region and highlights some of the significant policy decisions which have been adopted to enhance the performance of ATN/AMHS. Concept of the Aeronautical Telecommunications Network or ATN was developed by the SSR Improvement and Collision Avoidance Panel in the late eighties (Robert Witzenm 24 April 2007). Later in 1993, ICAO Air Navigation Commission agreed to establish the ATN Panel to continue the task. First set of ICAO SARPs for ATN was completed at the Second Meeting of ATNP in 1998 and subsequently introduced in ICAO Annex 10 in 2000. Initial standards prescribed the usage of ISO/OSI protocols. First edition of the Manual of Technical Provisions for ATN (ICAO Doc 9705) was published in 1998 providing detailed guidance on the concept of ATN. Fourth edition of the Manuel was withheld and instead a separate document “Manual on detailed technical specifications for the Aeronautical Telecommunication Network (ATN)” Doc 9880 was published. Significant relevant material was transferred from Doc 9705 into the Doc 9880 and Doc 9705 then became obsolete after all the material was transferred. Later the SARPs were revised to allow the use of Internet Protocol System or IPS. IPv6 has been adopted for the network layer. Considering current internet environment, IPv4 is being used predominantly but transition will be made to IPv6 as and when feasible.

STRUCTURE Strategy Structure Status Technical Specifications Address Management Handling OPMET & AIS/AIM messages Directory Service Voice over Internet Protocol (VoIP) Conclusion This presentation has been structured in 8 brief sections. 9th Section provides Conclusion from the presentation. AMHS/SWIM SEMINAR

COMMUNICATION GROUND-TO-GROUND Strategy adopted by APANPIRG/17 – August 2006 ATN to be implemented in compliance with ICAO requirements Initially support ATS Message Handling System (AMHS) to replace AFTN Deploy Backbone ATN routers to provide reliable infrastructure to eventually support air-ground applications Reasonable timeframe be established to replace AFTN with AMHS Message Transfer Agent sites to provide AFTN/AMHS gateways States to cooperate with each other in the implementation States to organize training After successful deployment of ground-to-ground ATN, should introduce air-to-ground Deploy dual stack protocols (OSI/IPS) AFTN has been in use for ground to ground communication since seventies. A number of applications like ATS Interfacility Data Communication or AIDC for ATS to ATS automation communication, NOTAM data handling, HF RT application etc. necessitated the requirement of accommodating higher quantum of data exchange and increasing the speed of communication. AMHS is expected to meet both these requirements. APANPIRG adopted a strategy to transit from AFTN to AMHS to take benefits from this later generation technology. 9 backbone sites in Australia, China, Fiji, Hong Kong China, Japan, Singapore, Thailand, USA and India were identified to form the backbone for the network, other states in the region are to connect to one or more of the backbone States. Initially ISO/OSI only was adopted but subsequently the strategy was amended to include IPS protocol also in line with the Amendment of Annex 10, Volume III

ATN OVER OSI AND ATN OVER IPS Conclusion 19/20 – Adoption of ATN over IPS in addition to ATN over OSI That, considering the inclusion of ATN over IPS SARPs in ICAO Annex 10, Volume 3 and to support global harmonization of ATN implementation, States hosting BBIS be urged to implement ATN over IPS in addition to ATN over OSI and complete this implementation of Dual Stack ATN (ATN/OSI and ATN/IPS) by 2011. Subsequently, APANPIRG in its Nineteenth meeting held from 1 to 5 September, 2008 adopted a conclusion urging all those nine States hosting the Backbone Boundary Intermediate Stations or BBIS hubs to complete implementation of dual stack ATN in their administrations. We will review the completion status during the meeting we have from tomorrow onwards.

DUAL STACK Dual Stack at the MTA level Dual Stack at the sub-net level Dual stack at IP level: - Address allocation - IPv4 vs. IPv6 TP4 CLNP AMHS MTA ISO/OSI AMHS Message IP Based ATN Router MTA IP RFC 1006 TCP Dual Stack in ATN/AMHS environment has been interpreted differently under differently circumstances. We have many options of implementing dual stack ATN/AMHS, the contemporary technology however supports most of these options.

ASIA/PAC REGIONAL ROUTER PLAN Operational ATN Backbone KR United State of America CN JP US China Russian Federation Japan MN Mongolia PW HK Hong Kong, China Palau MO Micronesia, Federal State of KP Macau China FM DPR Korea MM LA NP PK VN Myanmar PH TW TH Lao MH Marshall Island Nepal Pakistan Thailand Vietnam Philippines Taiwan KH MY BN Cambodia Malaysia Brunei Darussalam AS American Samoa ID BT Regarding dual stack, current Asia/Pacific Strategy for the implementation of ATN/AMHS, vide item ‘l’ requires that ‘Strategically deploy a network approach that permits dual stacks protocols (ATN/OSI and ATN/IPS) using dual stack routers by introducing separate IPS routers along side BIS Routers. Strategy also supports States with AFTN terminal or minimal connection to other States can take advantage of Internet Protocol network based on bi-lateral agreements. The BIS hubs have been given the option to either go for ATN/OSI or ATN/IPS or both on bilateral basis with the BBIS hubs to which they are connected. BD Indonesia Bhutan IN Bangladesh SG AU FJ India Singapore Australia Fiji LK Sri Lanka PG TL VU SB NR NZ New Zealand KI NC TV WF MV Maldives Island Papua New Guinea Timor Leste Vanuatu Solomon Islands Nauru Kiribati New Caledonia Tuvalu Wallis and Futuna Islands ATN Backbone Site ATN Site WS TO NU PF CK Plan ATN Backbone Operational ATN Backbone Samoa Tonga Niue French Polynesia Cook Islands Plan ATN Link Operational ATN Link

INTER-REGIONAL CONNECTIVITY Inter-Regional Trunk Connection New Inter-Regional Trunk Connection Intra-Regional Trunk Connection New Intra-Regional Trunk Connection NAM Region EUR Region MID Region AFI Region APAC Region AU CN JP IN TH SG HK US is North America Backbone FJ Japan China Hong Kong, Thailand Fiji India Singapore Australia North America Europe Middle East Africa Except for Asia/Pacific region, other regions have opted ATN over IPS. Most of Asia/Pacific BBIS hubs support both ISO/OSI and IPS and hence there should not be any problem in establishing AMHS connectivity across the regional boundaries. Some of the regions, in fact have progressed significantly in implementing AMHS network. Asia/Pacific States are making arrangements to implement connectivity as early as possible.

AMHS IMPLEMENTATION STATUS ADMINISTRATION LOCATION TARGET DATE REMARKS Australia Brisbane 2006 Implemented China Beijing 2010 Hong Kong China Hong Kong 2009 Fiji Nadi India Mumbai Japan Fukuoka ISO/OSI Singapore Thailand Bangkok 2012 USA Salt Lake City The table gives the present status of dual stack implementation of AMHS in the Backbone Boundary Intermediate Systems or BBIS hubs. The implementation status at Fiji and Thailand will probably be confirmed in the meeting starting tomorrow. In Japan, AMHS on ISO/OSI protocol is in operation since 2006. In fact, there are few other Boundary Intermediate Station hubs also, where AMHS has already been informed. AMHS/SWIM SEMINAR

TECHNICAL SPECFICATIONS ATNICG/6 recognized that Asia/Pacific requirements for ATN/AMHS developed at different times in several manuals based on different versions of Doc 9705 and EUROCONTROL AMHS Manual. Creates an Ad-hoc group to develop a baseline document. APANPIRG adopts AMHS Technical Specifications Draft Conclusion 22/18 – Asia/Pacific AMHS Technical Specifications That, the Asia/Pacific AMHS Technical Specifications provided in the Appendix E to the Report on Agenda Item 3.4 be adopted. Over years, 25 guidance documents had been created to support the implementation of ATN/AMHS in the region. These guidance documents were and in fact are still being reviewed periodically to make sure that information gathered from experience is incorporated into these documents. Comm. Centers may use this information as guidance but verify the contents before using it for operations. States are urged to verify the information provided in the Registry and get it corrected if required. ATNICG, in last last meeting identified that Asia/Pacific requirements for AMHS had been published in several manuals based on different versions of Doc 9705 and EUROCONTROL AMHS manuals. It was decided that an Ad-hoc Working Group be established to identify the baseline document on ATN/AMHS Implementation in this region. A single document, that captures the AMHS requirements for the region and that is based on the latest ICAO specifications in this regard should be developed. This ad-hoc group communicated amongst themselves through e-mail and developed a draft which was discussed in a side meeting during the time CNS/MET SG/15 met in July last year. The draft document, produced by the ad-hoc group of ATNICG and recommend by CNS/MET SG/15 was adopted by APANPIRG through its Conclusion 22/18. APANPIRG recorded its appreciation for the members of the Ad-hoc group from Japan, Singapore, Thailand, India and USA for their efficiency and the good work done by them in completing the draft specifications in such a short time. The ad-hoc group is now working on developing the document further. AMHS/SWIM SEMINAR

Project title (Insert, Header & Footer) AMHS REGISTER ICAO established AMHS Management Domains and Addressing Information Register available on web link http://legacy.icao.int/anb/panels/acp/amhs/AMHSRegisterList.cfm States urged to review information provided in respect of their administrations and get it corrected in case it is not correct. ICAO, through State Letter SP 54/1-03/39 dated 30 May 2003, sought input from States and related international organizations to allow ICAO to establish the AMHS Management Domains and Addressing Information Register. The Register has since been established and is available on ICAO website at the address ‘http://legacy.icao.int/anb/panels/acp/amhs/AMHSRegisterList.cfm’. States have been urged to review the information provided in respect of their administrations and get it corrected in case it not correct. In fact, some regions have created directory for their own region based on the information provided in the Registry. Project title (Insert, Header & Footer)

Project title (Insert, Header & Footer) EUROCONTROL AMC ICAO in cooperation with EUROCONTROL establishes procedures for coordination and synchronization of AMHS addresses on short/medium term States invited to designate representatives to register as AMC users using procedures described For long term, true global method of AMHS address management required. States shall support CAAS addressing scheme and BBIS States shall support both CAAS and XF addressing scheme (Strategy) ICAO, in cooperation with the European Organization for the Safety of Air Navigation (EUROCONTROL) has established procedures for the coordination and synchronization of AMHS addresses in the short-to medium term. State Letter AN 7/49.1-09/34 dated 14 April 2009 invites States to designate representatives to register as ATS Messaging Management Center or AMC users. EUROCONTROL AMC is expected to be a short/medium term solution. For long term, a true global method of AMHS address management will be required. Staff within CNS/AIRS Section of the Air Navigation Bureau will take the necessary action to develop appropriate recommendations for the establishment of management centers in ICAO Regions and also cooperation within these centers. Asia/Pacific ATN/AMHS Strategy requires that States shall support CAAS addressing scheme and BBIS hubs shall support both the CAAS and the XF addressing scheme. Project title (Insert, Header & Footer)

HANDLING OPMET MESSAGES ICAO supports XML for OPMET messages Milestones reported to CNS/MET SG/14 AFTN limitations to handle XML messages Some States not implemented full IA-5 character set Limitation line length 69 characters Limitations message length 1800 characters. AFTN and AMHS expected to co-exist for considerable period of time. Regional OPMET Data Banks RODB to accept either AFTN or AMHS, so AFTN/AMHS Gateway required to be implemented. In short term (2010-2013), ICAO is planning to introduce an enabling clause in Annex 3 to use XML for OPMET that is METARs, SPECIs and TAFs and also for tropical cyclone and volcanic ash advisories and SIGMET in graphical format. It was predicted that this will have little impact on telecommunication facilities, since the XML-code form will be used on a bilateral basis only and will be exchanged over internet. In the Extraordinary Session of the WMO Commission for Basic Systems (CBS) held in Windhoek, Namibia from 17 to 24 November 2010, ICAO assured support in principle for the transition to the use of extensible markup language or XML for OPMET information in the future net-centric environment. Milestones were reported in the CNS/MET SG/14 meeting which referenced section 2.4.1 and 2.4.2 of the report on ICAO attendance to the WMO Commission for Aeronautical Meteorology (CAEM) and Commission for Basic Systems (CBS) Expert Team on OPMET Data Representation meeting held in Paris on 26 October, 2009. Milestones include a Pilot Project conducted by WMO in 2009. There are some limitations in AFTN in handling XML protocol, these include non implementation of full IA-5 character set by some States, AFTN line length limitation of 69 characters, limitation of message size that is 1800 characters etc. Then there is another AFTN limitation of special characters and capability of using capital letters only. These limitations are not there with AMHS. Because of the investment already made by the States in AFTN, both AFTN and AMHS are expected to co-exist for a considerable period of time. During this period , Regional OPMET Data Banks, will get their input both from AFTN and AMHS through Gateways established to provide interface requirements. Project title (Insert, Header & Footer)

AMHS GATEWAY – OPMET MESSAGES Convert non-Annex 10 ITA2 characters to “?” before passing to AFTN Part messages of more than 1800 characters Convert IA5 IRV characters, if in lower case, into equivalent upper case characters Wrap lines if longer than 69 characters AMHS Gateway will be expected to meet these requirements to make them compatible with the OPMET systems Convert all non-Annex 10 ASCII ITA2 characters to “?” before passing them on to AFTN, if the system lacks the support of full IA5 character set Divide the messages of more than 1800 character length before passing them on to the AFTN Convert each IA5 International Reference Version or IRV character, if it is in lower case, into equivalent upper case character; and Wrap the lines, which are longer than 69 characters These steps are required to be taken to tackle AFTN limitations. Convert all non-Annex 10 ASCII (ITA2) characters to “?” before passing to AFTN, if required by lack of support for full IA-5 character set AMHS/SWIM SEMINAR

Project title (Insert, Header & Footer) XML FOR AIM Elements of specifications for Digital NOTAM to be included in Amendment 38, Annex 15 Amendment 38, Annex 15 Substantive chapter on digital services; and Incorporation of requirement to enable digital data exchange (AICM/AIXM) Digital NOTAM encoded in AIXM 5.1 is 20 times larger than equivalent Text NOTAM Exchange of some static messaging requirement like AIRAC cycle amendments may be challenging Digital NOTAM using Aeronautical Information Exchange Model (AIXM) version 5.1 has been adopted. Specifications to be considered in Amendment 38 of Annex 15. On an average, the Digital NOTAM encoded in AIXM 5.1 is 20 times larger than the equivalent ICAO Text NOTAM sent by AFTN, when number of characters is counted. It is further argued that the larger size of Digital NOTAM should not be a real problem for AMHS transmission on the ground, because of much enhanced capacity of the contemporary systems. Static data, where the size of the file is very large, like in AIRAC cycle Amendment in the range of 10 to 50 MB, messaging such requirements may be very challenging. Project title (Insert, Header & Footer)

Project title (Insert, Header & Footer) DIRECTORY SERVICE Reference ATNICG WG/8 – WP/6 & WP/10 – 28/09/2010 In support of ATN Directory Service a) can be used to distribute, update and synchronize address translation data between ATN & AMHS b) allows lookup and browsing of ATC object entries by operational and administrative staff c) can support Public Key Infrastructure (PKI) for digital signatures for AMHS and other applications d) will provide more efficient & timely management of the data required to operate the AMHS & AFTN gateways Reasons for not using Directory Service a) only a few ANSPs are using AMHS b) those that are using want to gain more experience before committing to deploy the Directory Service – recognizing the associated difficulties Concept of Directory Service was discussed in the Eighth Working Group meeting of ATNICG held in Christ Church, New Zealand from 27 to 30 September 2010. Meeting was informed about the benefits of using the Directory Service in ATN. Benefits included ability to distribute, update and synchronize address translation, look up and browsing of ATC object entries in the address data, support for security through Public Key Infrastructure or PKI and more efficient and timely management of the data required to operate AMHS and AFTN gateways. The reason, why it is not being used currently is because it has been decided to first implement point to point connectivity before going for ‘any point to any point’ type of network. May be in future, after the users have gained sufficient level of experience, directory service will be introduced in a progressive manner. Project title (Insert, Header & Footer)

Project title (Insert, Header & Footer) DIRECTORY SERVICE X.500 based Directory Service specified in Doc 9880 Part IV Technical Specifications Distributed Global System Commercial Off the Shelf (COTS) product Main Directory Service Requirements Resolve names between ATN & AMHS Manage distribution list Publish user attributes capabilities Support AMHS security Directory Service, based on X.500 has been specified in ICAO Doc 9880 Part IV for Technical Specifications. Directory Service is expected to support multiple applications like the ATS Message Handling Service or ATSMHS, Context Management or CM, System Wide Information Management or SWIM etc. Directory Service envisage is going to be hierarchical, global in nature and will be based on commercial off the shelf product or COTS product customized to meet the specific aviation related requirements. Main requirements of Directory service will include the following Resolve names between ATN & AMHS. There will be directory entry for each AMHS user, along with its attributes. The resolution between AFTN and AMHS, however will be carried out at the gateway level for the originator/receiver addresses Manage distribution list. Message servers can expand distribution lists to determine all the members Directory Service will publish the user attributes and capabilities for each address like the maximum length of message it can handle etc. The Directory Service will also take care of the AMHS security by maintaining the digital certificates. Project title (Insert, Header & Footer)

VOICE OVER INTERNET PROTOCOL VoIP to transmit audio data (especially voice) via IP packets. EUROCAE/67 created to examine use of VoIP in Air Traffic Management environment. Benefits for ground-ground communication Technical benefits: single network Cost reduction: single network for voice & data Flexibility: IP solution Main issues to be addressed Safety of operations Continuity Release of documents in Feb 2009 Transition issues Well, Voice over IP not really an ATN application, however it is being considered for ground to ground and air to ground applications, in view of its benefits. Voice over IP means transimitting audio data especially voice via IP Packets. European Organization for Civil Aviation Equipment or EUROCAE created Working Group 67 in 2004 for examining the use of Voice over Internet Protocol or VoIP in an Air Traffic Management environment.. The main benefits expected from the use of VoIP can be categorized under three main headings Technical benefits: presently separate networks are being used for the voice and data communication. With VoIP, it will be possible to implement, configure and manage single network which will be ready for present and future communication needs Cost Reduction, because of single network. And then Flexibility, a trait associated with the usage of Internet Protocol. IP technology is already being widely used by the governments and defence organizations as a mission critical technology. However Safety and service continuity are of more paramount significance for air traffic management compared to these services. February 2009 saw the official release of the first version of the three major EUROCAE WG 67 documents that is ED-136: VoIP ATM System Operational and Technical Requirements, ED-137 Interoperability Standards for VoIP ATM Components and ED-138 Network Requirements and Performances for VoIP ATM Systems. Inputs from the FAA were included and released in 2010 with updates to the ED-137 Part 1 and Part 2 specifications. Transition from the current systems to VoIP is going to be a big issue, because the States have already invested heavily into their ATM systems, changing or modifying them to accept IP is going to be an expensive undertaking. In addition, there is a requirement of service continuity. An ATM system cannot be switched off during transition to IP network system. Implementation has to be phased with both the systems running simultaneously for some time. AMHS/SWIM SEMINAR

VOICE OVER INTERNET PROTOCOL Voice networks normally are Connection Oriented, whereas data networks are mainly Connection-less. Benefits Network availability Continuity/contingency Issues with IP Data corruption Sequence of receipt of datagrams Loss or destruction of datagrams Safety critical & administrative communication Usually voice networks like PSTN are classified in the category of Connection Oriented Networks. A channel is established between source and the destination through switches to establish the required path and resources are allocated. When both correspondents hang up, the communication is terminated and the resources are released. The data network on the other hand is connectionless, data packet containing the source and the destination addresses are posted into the network like in the letter-box and packet is delivered to the addressee through what is called the “best effort”. This makes the network non-reliable” Specific Benefits that is driving the implementation of VoIP for ATM are IP networking provides inherent routing capabilities and is therefore less vulnerable to network link outages Planning business continuity and execution of resumption of service becomes more flexible and easier to accomplish by automatic re-routing and reconfiguration of network configurations. Some of the main issues with IP Protocol may include: First there is no protection against data corruption. There is no error detection function available Transmission delay is another issue The message is broken into datagrams. The incoming order of these datagrams may not be in sequence, like the a datagram A sent before datagram B may arrive later at the destination Then of course the datagrams may be lost or destroyed Mixing safety critical and administrative communication must be planned carefully as the network itself does not guarantee latency and packet loss Work is going on in Aeronautical Communication Panel or ACP for the implementation of VoIP. Usage of VoIP for ground-to-ground communication is also under consideration in the APAC region. AMHS/SWIM SEMINAR

CONCLUSION Dual Stack BBIS in place to meet APANPIRG Conclusion 19/20 timeline AFTN and AMHS to coexist for considerable period of time Many options coexisting For AMHS to be really acceptable, applications need to developed Transition to SWIM So that was a brief presentation on the development of ATN/AMHS implementation in the region. Through the presentation, efforts have been made to bring out some salient issues related to the implementation. As mandated by APANPIRG Conclusion 19/20, the Backbone Boundary Intermediate System is more or less in place meeting the timeline prescribed. In fact implementation at the next level has already started with the AMHS connectivity provided between BBIS hubs at Hong Kong China and China and the BIS hubs at Macao China and Republic of Korea. AFTN has been in use for more than four decades. A number of applications have been developed on AFTN and till such time these applications are also developed on AMHS, AFTN and AMHS are ging to co-exist, with AFTN/AMHS gateway working as the interface application between the two. As on date there are many options coexisting, like option between ISO/OSI and IPS at the MTA level and at the subnet level, option of using IPv4 and IPv6 etc. Arrangements have to be made to ensure that all these options are accommodated. For reaping the true benefits of ATN/AMHS, it is essential that applications based on AMHS are developed. Some trials were made in the region for XML over AMHS. The community needs to be convinced that the OPMET and the AIS/AIM requirements of exchanging data over Extended Markup Language or XML will be adequately met by using AMHS as medium. Other similar applications also need to be developed. As has been observed or will be observed shortly in the coming presentations, there is move to transit to a new concept, the concept of System Wide Information Management or SWIM. How AMHS will be accommodated in the future communication structure like SWIM is yet to be seen. We except to see many new innovations in Communication infrastructure in next couple of years. On the other hand, there is an issue of stability of investment environment. The community has to make sure the investment made by the States is protected at the same time benefits from the emerging technologies are realized to maximum extent possible. AMHS/SWIM SEMINAR

THANK YOU Well that was an attempt towards a very comprehensive presentation on issues related to the implementation of ATN/AMHS. I am sure, you have many questions. I am no expert on the subject myself, and would therefore request you to address them to the experts we have from the States and from the industry. I am sure, based on the immense experience they have accumulated over last couple of years in the implementation and operation, they will be able to remove all your doubt and reply to your all questions. AMHS/SWIM SEMINAR