Title: CM - CMLogonResponse Correction PDR Reference: 98050020 Originator Reference: SARPs Document Reference: CM SARPs, Sections 2.1.1, 2.1.3.3.7, 2.1.3.4.4, 2.1.4.2.1, 2.1.7.1.1.1, 2.1.7.1.1.4, 2.1.7.1.1.6, 2.1.7.1.2, 2.1.7.1.2.1, 2.1.7.2.2.5, 2.1.7.2.2.8, 2.1.7.2.3.1 Status: WITHDRAWN PDR Revision Date: 17/09/98 (ACCEPTED -> WITHDRAWN) 25/06/98 (PROPOSED -> ACCEPTED) 29/05/98 (SUBMITTED -> ACCEPTED -> PROPOSED) PDR Submission Date: 29/05/98 Submitting State/Organization: ATNP WG3/SG2 Submitting Author Name: Saccone, G Submitting Author E-mail Address: gsaccone@mail.hac.com Submitting Author Supplemental Contact Information: ph 1 604 821-5182, fx 1 604 279-5980 SARPs Date: IV2.2 SARPs Language: English Summary of Defect: There are serious operational issues with the intended use of the Facility Designation in the CM Logon sequence of messages (Logon Request/Logon Response. There are a number of elements in the CMLogonRequest message that may optionally be used. This is intended to allow different implementations as much flexibility as possible. There are [at least] two types of problems that may arise from the use of optional data however: - case #1: one region determines that optional data needs to be made mandatory for its particular region, while a neighboring region does not require the optional information. - case #2: different regions may interpret the same data differently. Both of these situations can lead to safety issues if not resolved. These two situations do not have the same safety impact since the intent of the information is the same for the first case, but not the second. - case #1: the logon could be rejected (e.g. no application information given or an abort issued by the ground system) because information a region requires is not present. The aircraft would then be told to provide the required data. - case #2: if a pilot is intending that the facility designation in the logon is specifying an alternate aerodrome (for instance) while the ground is interpreting it to mean that the pilot is specifying a facility from where he wants data link services, then there is an operational issue. This cannot be resolved in guidance, since there would be nothing binding implementations-different regions may still choose operationally incompatible implementations. This is clearly a case that must be resolved in SARPs. There are two immediate solutions to this problem. - Solution #1: mandate, via user requirement changes in Section 2.1.7, that the optional FacilityDesignation field of the CMLogonRequest, if used, will have a specific meaning. - Solution #2: change the ASN.1 of the CMLogonResponse to completely clarify the intended purpose of the FacilityDesignation. Both of these options are discussed, and the final choice recommended. The first option of changing the user requirements has the advantage of not affecting the current technical interoperability of the SARPs. However, there are some critical safety issues. For this solution, one must assume that if the optional FacilityDesignation field is used, then the aircraft performing the logon will use it as a means to request the data link information of a facility other than, or in addition to, the one being logged on to. This is logical and consistent with how a CM server might be implemented. Therefore the facility that receives the CMLogonRequest with the optional FacilityDesignation field used will do one of two things: 1) the receiving facility will either respond with its own information, and forward the CMLogonRequest to the facility indicated by the FacilityDesignation field (either by CMForward or other means). The ground system receiving the CMLogonRequest (i.e. the one that is specified in the FacilityDesignation) would then perform a CMUpdate with the aircraft, or 2) the receiving facility will respond with the data link information of the facility specified by the FacilityDesignation. Both of these solutions make certain assumptions about the receiving CM ground system. For 1), it is assumed that the CM ground system has a database of CM addresses and is able to correlate those addresses with the given facility designation. It also assumes that the CM ground system has the ability to forward this information in some way, which implies some level of ground-ground connectivity. Also, if a CM ground system is a CM server, then it would always return an empty field in the CMLogonResponse. However, there is no guarantee that the CMLogonRequest was forwarded to the appropriate facility, and also no way to indicate that to the aircraft via CM. This could lead to an unacceptable situation where the aircrew has assumed its data link information has been passed on to a facility with which it wishes to perform data link services with, when in reality that has not been successfully completed. Operational problems would arise, such as how long to wait for a "successful" logon or what retry methods would be applicable. For 2), it is assumed that the receiving facility is a CM server, and has a database complete with current information for all data link applications at all facilities. This may not be the case, and the CM ground system without access to this information would return no application information in the CMLogonResponse. Also, there are certain applications that the intended ground system will need to be made aware of, such as ADS or ground-initiated CPDLC. The CM ground system receiving the CMLogonRequest will need to forward that information to the intended CM ground system somehow. If the CM ground system supports the contact and/or forward functions, it may be able to either direct the aircraft to contact the facility directly or forward the aircraft's information to that facility via ground-ground. However, as in the previous case, there is no guarantee that either of these services are available and no ability to indicate the success or availability of those services to the aircrew. This may also cause an operational problem, as an aircrew will assume that its ADS and CPDLC information has been forwarded to the proper ground facility when in fact it hasn't. Another problem is that the Facility Designation parameter (i.e. Dialogue Service Called Peer ID parameter) of the CM-logon service will not match the information returned in the CMLogonResponse. This will add complexity to both the aircraft and ground systems, as both systems will now have to carefully track the creation of the actual TSAPs for each application (i.e., the use of the long TSAP). A problem with these two solutions is that they both lead to ambiguities with the CM-update service. If the addressing data is forwarded to the facility as requested by the aircraft, the facility will send an update to the aircraft. However, there is no way to indicate which facility the data link information being returned is for. And since the other facility may be a CM server, there is the danger of the aircraft having incorrect application addresses. This represents a serious safety impact. The same situation is also possible with the response/confirmation portion of the CM-logon service. A solution that would solve this problem would be to change the ASN.1 of the CMLogonResponse. The CMLogonResponse would be changed to include a FacilityDesignation field, that would indicate which facility the information being returned is for. This fix would support both the CM server and CM end system concepts of operation. In addition, there would be no ambiguity as to which facility's information is being provided; it is explicitly stated in the response. The problem of a CM ground system not being able to guarantee that the application information contained in a CMLogonRequest was successfully passed to the appropriate facility would still exist. However, this solution does solve the ambiguity of which facility's information is being returned upon successful forwarding of information. In addition, this solution supports a more efficient operational concept by allowing multiple updates over a single dialogue. This would allow a CM facility to give an aircraft many facilities' application information along with the information needed for the aircraft to properly correlate the information via the CM-update service (the CMUpdate is identical to the CMLogonResponse). Therefore, in order to ensure that an aircraft can correlate application information returned in a CMLogonResponse or CMUpdate, the ASN.1 of those elements is proposed to be updated, as well as additional appropriate user requirements in 2.1.7. Assigned SME: Sub-Volume 2 SME Proposed SARPs amendment: 1/ In 2.1.1, Note 2, a) 1 add at the end after "...for each requested application that can be air initiated and that the ground can support." the following sentence: The ground also provides the facility designation that corresponds to the application information provided. 2/ In 2.1.1, Note 2, a) 5 add et the end after "...For each desired air-initiated application the ground provides the application name, version number, and address." the following sentence: The corresponding facility designation is also provided. 3/ In 2.1.1, Note 2, b) 2 add at the end after "...For each updated application the ground provides the application's name, version number and address. " the following sentence: The corresponding facility designation is also provided. 4/ In the note of 2.1.3.3.7, add at the end after "... to provide data link service." the following service: It also contains the facility designation that corresponds to the application information provided. 5/ In the note of 2.1.3.4.4, add at the end after "...on each updated data link application." the following service: It also contains the facility designation that corresponds to the application information provided. 6/ In 2.1.4.2.1, change from: CMLogonResponse ::= SEQUENCE { airInitiatedApplications [0] SEQUENCE SIZE (1..256) OF AEQualifierVersionAddress OPTIONAL, groundOnlyInitiatedApplications [1] SEQUENCE SIZE (1..256) OF AEQualifierVersion OPTIONAL } to: CMLogonResponse ::= SEQUENCE { facilityDesignation [0] FacilityDesignation, airInitiatedApplications [1] SEQUENCE SIZE (1..256) OF AEQualifierVersionAddress OPTIONAL, groundOnlyInitiatedApplications [2] SEQUENCE SIZE (1..256) OF AEQualifierVersion OPTIONAL, ... } 7/ In 2.1.7.1.1.1, change from ( within brackets is in italics): 2) for applications that can be ground initiated: application name, version number, and address for all the versions that can be supported, and d) flight information data as required by the ground system. to: 2) for applications that can be ground initiated: application name, version number, and address for all the versions that can be supported, d) the facility designation of the ground system that corresponds to the application information in c) if necessary, and e) flight information data as required by the ground system. 8/ In 2.1.7.1.1.4, change ( within brackets is in italics) from: to: 9/ In 2.1.7.1.1.6, change ( within brackets is in italics) from: Upon the receipt of a from a CM-logon service confirmation from an ICAO ground facility designation for which CM information has previously been received, the CM-air-user shall only replace the previous information for which new logon information has been received. to: Upon the receipt of a from a CM-logon service confirmation from an ICAO ground facility designation for which CM information has previously been received, the CM-air-user shall only replace the previous information of the facility identified in the Logon Response for which new logon information has been received. 10/ In 2.1.7.1.2, add the following note ( within brackets is in italics): 11/ In 2.1.7.1.2.1, change ( within brackets is in italics) from: Upon the receipt of from a CM-update service indication from a ground facility designation for which CM information has previously been received, the CM-air-user shall only replace the previous information for which updated information has been received. Upon the receipt of from a CM-update service indication from a ground facility designation for which CM information has previously been received, the CM-air-user shall only replace the previous information of the facility identified in the Update Information for which updated information has been received. 12/ In 2.1.7.2.2.5, change from: Upon receipt of a CM-logon service indication, the CM-ground-user shall invoke a CM-logon service response with a CMLogonResponse containing: a) application names, addresses, and version numbers for the requested applications that can be air- initiated for all versions that the ground and aircraft systems can support, and b) application names and version numbers for the requested ground-only initiated applications that the ground system can support. to: Upon receipt of a CM-logon service indication, the CM-ground-user shall invoke a CM-logon service response with a CMLogonResponse containing: a) the facility designation relevant to the application information to be returned, b) application names, addresses, and version numbers for the requested applications that can be air- initiated for all versions that the ground and aircraft systems can support, and c) application names and version numbers for the requested ground-only initiated applications that the ground system can support. 13/ Add new section, 2.1.7.2.2.8 ([text] is bolded, is italicised): 2.1.7.2.2.8 [Recommendation.] - 14/ In 2.1.7.2.3.1, change from: When invoking the CM-update service request, the CM-ground-user shall provide a CMUpdate containing application names, addresses, and version numbers for each of the data link applications being updated. to: When invoking the CM-update service request, the CM-ground-user shall provide a CMUpdate containing the facility designation relevant to the application information to be updated and application names, addresses, and version numbers for each of the data link applications being updated. SME Recommendation to CCB: CCB Decision: atnp_ccb_chair: SUBMITTED (29/05/98) CCB-6 (Utrecht) : ACCEPTED (25/06/98) CCB-6 requests the SME2 Team to revisit the PDR and to propose a solution not impacting the interoperability, even if this restricts the server capability of the ground CM. The full capability will be provided in version 2. As a consequence, this PDR is withdrawn by the author (the proposed solution could be used as input in CM version 2 to support the full server capability) and replaced by PDR 98090003. PDR 98090003 proposes to keep unchanged the ASN.1 and to instruct the users in chapter 7 how to handle the Facility Designation field of the Logon Request. There is no ambiguity any more in the Logon Response. The use of the CM-update service is restricted for updating the information related to the gound facility designator of the CM-update service initiator.