AMHS – Amendment Proposal on EITs and Probe handling in ...



[pic] |

International Civil Aviation Organization

WORKING PAPER |ACP-WGM14/WP-05

2 June 2009

| |

AERONAUTICAL COMMUNICATIONS PANEL (ACP)

14th MEETING OF WORKING GROUP M (Maintenance)

Brussels, Belgium 2-5 June 2009

|Agenda Item 2: |ATN/OSI Document 9880 Update Status |

AMHS – Amendment Proposal on EITs and Probe handling in AFTN/AMHS Gateway (Doc 9880 Part IIB)

(Presented by Jean-Marc Vacher, France)

|SUMMARY |

|This paper aims at submitting an Amendment Proposal (AP) related to the Detailed Technical Specifications |

|for AMHS, for processing by WGM. The reported defects were detected during the preparation of the Site |

|Acceptance Testing (SAT) of the MESANGE AMHS Implementation Project which is currently underway in France |

|and in Switzerland. |

|This paper is also an opportunity to discuss the practical aspects of AP submission to WGM. |

|ACTION |

|The working group is invited to perform the actions recommended in section 3 of the paper. |

1. INTRODUCTION

This paper aims at submitting an Amendment Proposal (AP) related to the detailed technical specifications for AMHS, for processing by WGM. The reported defects were detected during the preparation of the Site Acceptance Testing (SAT) of the MESANGE AMHS Implementation Project which is currently underway in France and in Switzerland.

This paper is submitted based on the procedure provided in Attachment to the WGM/12 meeting report, and it is also an opportunity to discuss the practical aspects of AP processing following this procedure.

2. DISCUSSION

The attached AP is related to a couple of defects detected in the detailed technical specifications for AMHS, in the chapter related to the AFTN/AMHS Gateway. The main defect is related to the lack of identical processing for probes and messages received from AMHS at an AFTN/AMHS Gateway. The parameter which is not handled identically for probes and messages is named Encoded Information Types (EITs). The details of the defects are provided in the attached AP.

The AP includes a full resolution for the identified defects. Unfortunately, they were identified too late to fulfil steps ii and iii of the ACP maintenance procedures, i.e. posting on the ACP web site and submission at least 4 weeks before the meeting. Therefore, it might be needed to wait until the next WGM meeting to address it.

However, this practical example enables to raise the following points and questions:

a) a topic should be created on the ACP website to store APs, in a way that would be easy to locate by implementers;

b) it might be useful to define a means to inform interested parties of the existence of APs. An example of such means could be a participants’ list;

c) it is assumed that APs become applicable at the moment of their publication, according to step vi of the procedure. However the way in which APs are published in not defined in the procedure. It could be useful to introduce the notion that an AP can be published “alone” to avoid editing a full Manual for each AP;

d) it is also necessary that Industry and ANSPs that are implementing systems and applications based on the Manuals, typically in the present case AMHS systems, be informed about the publication of the APs and/or of the revised Manuals. This aspect is not addressed in the procedure;

e) to relieve ICAO from significant editorial processing, a possible way to handle these issues could be to use the WGM status (e.g. Proposed, Pending, Approved, Rejected) to the APs posted on the ACP web site, so that interested parties know that APs are to be implemented when they reach the status Approved. If needed, an additional status (e.g. Adopted) could be added to reflect the ICAO ACP (or ANC) decision when needed. In this way, the ACP website could serve as the focal point for all parties in this procedure. Each Coordinator could provide the ACP Secretariat with the appropriate files for this purpose.

3. ACTION BY THE MEETING

The ACP WG-M is invited to:

1. adopt the attached AP, or, if time must be granted for further analysis/comments by more parties, to recommend that this analysis be performed with the objective of adopting the AP at the next WGM meeting;

2. discuss the practical points and questions related to the agreed ACP document maintenance procedure and adopt appropriate solutions to facilitate the processing of APs by ICAO and their implementation by Industry and ANSPs.

|Title: |AMHS - EITs and Probe handling in AFTN/AMHS Gateway |

|AP working paper number and date: |Acp-WGM14/WP-05 |

|Document(s) affected: |Doc 9880, Manual on detailed technical specifications for the |

| |Aeronautical Telecommunication Network using OSI standards and |

| |protocols, part IIB (AMHS) |

|Sections of Documents affected: |4.5.2.1.1, 4.5.5.1, 4.5.5.2 |

|Coordinator: |Jean-Marc Vacher |

|Coordinators address: |DSNA/DTI |

| |Pôle CNS/ITR (support ON-X) |

| |1 avenue du Dr Maurice Grynfogel |

| |31035 Toulouse |

| |France |

|Coordinators Phone: |+33 5 6214 5474 |

|Coordinators Fax: |+33 5 6214 5401 |

|Coordinators e-mail address: |jean-marc.vacher@regis- |

|Category: |CLARIFICATION and BUG |

|Problem description: |1) The referred clauses 4.5.2.1.1 and 4.5.5.1 are currently |

| |worded as if each acceptable value of Encoded Information Types |

| |(EITs) was a single item among the proposed list. In reality, the|

| |EITs parameter is a set of one or several values, particularly |

| |when OIDs are used. The clauses therefore need to be clarified. |

| | |

| |2) In AMHS, a probe is similar to a message with an envelope but |

| |no contents. The probe is used to determine whether a message |

| |with certain characteristics, borne by the envelope, would be |

| |delivered to its intended recipient(s). The result of the probe |

| |is sent to the originator by means of a Delivery Report (if |

| |successful) or Non-Delivery-Report (if unsuccessful). Thus, the |

| |behaviour of the AFTN/AMHS Gateway, upon reception of an AMHS |

| |probe, should be identical to its behaviour upon reception of a |

| |message, for parameters which are common to both information |

| |elements. This principle is currently not correctly applied to |

| |EITs, as the list of “acceptable” EITs values is not the same for|

| |a probe (clause 4.5.5.1) and for a message (clauses 4.5.2.1.1 and|

| |4.5.2.1.2). Note that another parameter named |

| |“implicit-conversion-prohibited”, also has an influence for a |

| |given EITs value. This is reflected in 4.5.2.1.2 and now taken |

| |into account in 4.5.5.1. |

|Background: | |

|Backwards compatibility: |Systems with and without the amendment implemented will |

| |interoperate, but will not behave in the same manner. Thus, |

| |interpretation of probe results could be over-restrictive by |

| |users sending probes to a gateway without the AP implemented. |

|Amendment Proposal: |4.5.2.1.1 Upon reception by the Message Transfer and Control |

| |Unit of an IPM, the received message shall be processed in one of|

| |the following manners, depending on the abstract-value of the |

| |current encoded-information-types, determined as either the |

| |abstract-value of the latest converted-encoded-information-types,|

| |if existing, in the trace-information element, or as the |

| |abstract-value of the original-encoded-information-types element |

| |if the previous does not exist: |

| | |

| |processing as specified in 4.5.2.1.2 if the abstract-value of the|

| |current encoded-information-types is any includes exclusively one|

| |or several of the following values: |

| | |

| |basic "ia5-text"; |

| | |

| |externally-defined "ia5-text"; |

| | |

| |OID {id-cs-eit-authority 1} as specified in ISO/IEC 10021-7; |

| | |

| |OID {id-cs-eit-authority 2} as specified in ISO/IEC 10021-7; |

| | |

| |OID {id-cs-eit-authority 6} as specified in ISO/IEC 10021-7; or |

| | |

| |OID {id-cs-eit-authority 100} as specified in ISO/IEC 10021-7; or|

| | |

| |if the abstract-value includes any value differs different from |

| |all the values indicated in item a) above: |

| |1) rejection of the message for all the message recipients; and |

| | |

| |2) generation of a non-delivery report as specified in 4.5.6 with|

| |the following elements taking the following abstract-values in |

| |all the per-recipient-fields of the report […] |

| | |

| |4.5.2.1.2 A message which was not rejected as the result of |

| |4.5.2.1.1 shall be processed in one of the following manners: |

| | |

| |processing as specified in 4.5.2.1.3 if the abstract-value of the|

| |implicit-conversion-prohibited in the per-message-indicators |

| |element in the Message Transfer Envelope differs from |

| |"prohibited", or if the abstract-value of the current |

| |encoded-information-types does not include the OID value |

| |{id-cs-eit-authority 100}; or |

| | |

| |if the abstract-value of the element is "prohibited" and if the |

| |abstract-value of the encoded-information-types includes OID |

| |{id-cs-eit-authority 100}: |

| | |

| |rejection of the message for all the message recipients; and |

| | |

| |generation of a non-delivery report as specified in 4.5.6 with |

| |the following elements taking the following abstract-values in |

| |all the per-recipient-fields of the report […] |

| | |

| | |

| |Other related section: |

| | |

| |4.5.5.1 Upon reception by the Message Transfer and Control Unit |

| |of an AMHS probe which content type is |

| |"interpersonal-messaging-1988", the received probe shall be |

| |processed in one of the following manners, depending on the |

| |abstract-value of the current-encoded-information-types, |

| |determined as either the abstract-value of the latest |

| |converted-encoded-information-types, if existing, in the |

| |trace-information element, or as the abstract-value of the |

| |original-encoded-information-types element in the Probe Transfer |

| |Envelope if the previous does not exist: |

| | |

| |a) processing as specified in 4.5.5.2 if the abstract-value of |

| |the current encoded-information-types is "ia5-text" or extended |

| |"ia5-text"; or includes exclusively one or several of the |

| |following values: |

| | |

| |basic "ia5-text"; |

| | |

| |externally-defined "ia5-text"; |

| | |

| |OID {id-cs-eit-authority 1} as specified in ISO/IEC 10021-7; |

| | |

| |OID {id-cs-eit-authority 2} as specified in ISO/IEC 10021-7; |

| | |

| |OID {id-cs-eit-authority 6} as specified in ISO/IEC 10021-7; or |

| | |

| |OID {id-cs-eit-authority 100} as specified in ISO/IEC 10021-7; or|

| | |

| |b) if the abstract-value differs from built-in "ia5-text" and |

| |from extended "ia5-text":includes any value different from the |

| |values indicated in item a) above, or if it includes OID |

| |{id-cs-eit-authority 100} and the implicit-conversion-prohibited |

| |in the per-message-indicators element of the Probe Transfer |

| |Envelope has the abstract value “prohibited”: |

| | |

| |1) rejection of the message probe for all the message probe |

| |recipients; and |

| | |

| |2) generation of a non-delivery report as specified in 4.5.6 with|

| |the following elements taking the following abstract-values in |

| |all the per-recipient-fields of the report […] |

| | |

| | |

|WG-M status: |PROPOSED |

| | |

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download