DOC

Mirror Site - Indiana State University

By David Ray,2014-11-07 04:43
9 views 0
Mirror Site - Indiana State University

    Resolving interoperability issues for SATCOM Frequency Channel 1

    RTCA SC-214/EUROCAE WG-78

    Air Traffic Services Safety and Interoperability Requirements

    General Information

    Paper Reference: Revision: Date: Status :

    1 10 Dec 2012 Individual(s) Proposal POS- SATCOM Numbers

Editor / Author: AIRBUS Review Meeting/Teleconference:

     Comments Due: Plenary #16 (Washington, DC) Position Paper Title:

    Resolving interoperability issues for SATCOM Frequency Channel

    Abstract and Proposed Action:

Due to divergent implementations among aircraft types, the use of CPDLC to send satellite voice telephone

    numbers in MONITOR and CONTACT messages cannot be uniformly implemented and seamlessly used around the world (refer to GOLD v1, ? 3.1.2.6).

    This may become a strong limitation with the ongoing deployment of Satcom voice for ATS communications. A resolution should be pursued for the definition of next generation ATS Data Link services and applications within

    the frame of WG78/SC214 activities.

    This Position Paper makes a proposal for resolution by introducing a new definition for this parameter so that :

    - Global technical interoperability is ensured, by avoiding NumericString type that implied divergent and

    incompatible PER coding/decoding implementations on ground and in the air.

    - Global operational interoperability is ensured, by accommodating the existing formats of satellite voice

    telephone numbers.

Key words (Optional):

    Frequency Channel Satcom, ASN.1, PER

    Distribution

    SC-214/WG-78Groups Additional Names Additional Names Additional Names Plenary

    CSG

    VSG

    Resolving interoperability issues for SATCOM Frequency Channel 2

    1. Introduction

1.1 Technical interoperability issue

    There are different flavors of PER coding/decoding of the ASN.1 NumericString type, used in particular in the parameter Frequencysatchannel. This leads to an interoperability issue, which in turns, led ground systems:

    o Either to avoid sending of messages using this parameter (and use voice to communicate this

    kind of information to aircraft),

    o Or to accommodate aircraft type specificities by adapting the content of the uplinked data.

Such limitation is clearly explained in ICAO GOLD document:

    3.1.2.6 Satcom channel numbers in CPDLC messages. The CPDLC standard provides a [Frequencysatchannel] variable that is intended for ATSUs to send satellite voice telephone numbers in MONITOR and CONTACT messages (UM 117 to UM 122). However, the decoding of this variable varies by aircraft type. Therefore, the ATSU should not use this variable in these messages unless the ground system can determine the appropriate decoding in use by the receiving aircraft and encode the uplink accordingly.

    DO258A/ED100A (or DO258/ED100) and DO280B/ED110B documents provide the following definition for Frequencysatchannel parameter:

    o ASN.1 syntax is Frequencysatchannel ::= NumericString (SIZE (12))

    o compliance with ISO/IEC 8825-2 (1996 Packed Encoding Rules (PER) - Basic Unaligned) is

    required to encode and decode the ASN.1 message structures.

    In ISO/IEC 8825-2 PER standard, NumericString type is unambiguously including the {space} character in addition to 0, 1, 2, 3, 4, 5, 6, 7, 8 and 9 ones.

    PER encoding is then based on the canonical order of the values: {space, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9}. As a result, each item of a FrequencySatChannel should be encoded as follows:

    o Space = ―0000‖

    o 0 = ―0001‖

    o 1 = ―0010‖

    o 2 = ―0011‖

    o

    This is the encoding/decoding scheme for the FrequencySatChannel parameter to be used for exchange of this data between DO258A/ED100A or DO280B/ED110B compliant avionics and ATSUs.

    Other implementations have not implemented the space in the NumericString type and so interpret:

    o 0 = ―0000‖

    o 1 = 0001

    o 2 = ―0010‖

    o

    Even though it looks simpler, this implementation is not recognized as being DO258A/ED100A or DO280B/ED110B compliant.

    Exchanging uplink messages between systems that are not implementing the same logics may likely induce undetected corruption of uplink data (at the system level at least).

    Resolving interoperability issues for SATCOM Frequency Channel 3

1.2 Operational interoperability issue

    DO258A/ED100A (? 4.6.3.2) provides additional guidance for Data Structures Presentation, but the display of CPDLC messages is a local implementation.

For Frequencysatchannel, the guidance is the following:

    Frequencysatchannel nnnnnnnnnnn (no space allowed)

    The comment ―no space allowed‖ is ambiguous, because there are two possible interpretations:

    - any uplink containing the parameter with a {space} character must be rejected (same logics as

    for Free Text parameter)

    - the {space} character shall be accepted but must not be displayed.

    The Frequencysatchannel is defined with 12 characters, while operational channels may have:

    - Less than 12 digits (e.g. short codes).

    - More than 12 digits. The phone number length vary with the country (Chinese phone numbers

    are defined on 14 characters; this is also the case for Brazilian and Finish phone numbers).

    Resolving interoperability issues for SATCOM Frequency Channel 4

2. Proposition

    From an operational standpoint, it is proposed to make the length of the Frequencysatchannel parameter variable, so that all known formats for satellite voice telephone numbers can be supported.

    As a provision, the maximum length could be 18 digits, but it is highly recommended that an adequate length is decided in close coordination with groups and panels working on guidance for SATCOM Voice for ATS communications and monitoring associated deployment (e.g. ICAO).

    From a technical standpoint, to prevent divergent and incompatible PER coding/decoding implementations on ground and in the air, it is proposed to avoid use of NumericString type for the definition of Frequencysatchannel parameter. Alternatively, it is proposed:

    o to use another widely type (e.g. character string), and

    o to provide recommendation to include only ―0‖ to ―9‖ digits within this parameter.

    Note: need to include additional characters (e.g. +) should be investigated groups and panels

    working on guidance for SATCOM Voice for ATS communications and monitoring

    associated deployment (e.g. ICAO).

    Consequently, the following amendments are proposed for Frequencysatchannel parameter:

    o in PU-10 SPR, Table 5 7: CPDLC Message Variables, Range, and Resolution Variable Definition Parameters (if any) Range Resolution

    Frequency sat Specifies frequency None 1 to 18 digit NA

    channel as a telephone character string

    number

    o in PU-20 Interop PART 4 CPDLC ASN.1 for Baseline 2 Systems

    Frequencysatchannel ::= IA5String (SIZE (1..18))

    -- Frequencysatchannel corresponds to a 1 to 18 digit telephone number

    o Ripple effect on PU-30 FANS 1/A ATS INTEROP STANDARD should also be

    investigated.

    Resolving interoperability issues for SATCOM Frequency Channel 5

    3. ACTION(S) OR RECOMMENDATION(S)

    The meeting (group) is invited to:

    a) review and discuss the issues in the paper,

    b) agree on the resolutions , and

    c) integrate the proposed amendments in documents.

    -END-

Report this document

For any questions or suggestions please email
cust-service@docsford.com