1. 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 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.

2. 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

3. 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

4. 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
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.

5. 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.

6. ASIA/PAC REGIONAL ROUTER PLAN Operational ATN BackboneKR
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

7. 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.

8. 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 In fact, there are few other Boundary Intermediate Station hubs also, where AMHS has already been informed.
AMHS/SWIM SEMINAR

9. 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 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

10. Project title (Insert, Header & Footer)
AMHS REGISTER
ICAO established AMHS Management Domains and Addressing Information Register available on web link
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 ‘
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)

11. 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/ /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)

12. 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 ( ), 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 and 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, 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)

13. 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

14. 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)

15. 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 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)

16. 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)

17. 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

18. 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

19. 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

20. 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