Title: ADS+ARF - Reception of a D-START Calling Peer ID with a wrong type PDR Reference: 98120004 Originator Reference: aciads10 SARPs Document Reference: ADS SARPs, Sections 2.2.1.4.2.1, 2.2.1.5.3.16.5.1 and 2.2.1.5.4, 2.2.2.5.3.5.3.1 Status: RESOLVED Impact : C (Clarification) PDR Revision Date: 21/01/99 (PROPOSED -> RESOLVED) 19/01/99 (SUBMITTED -> PROPOSED) 18/01/99 (SUBMITTED -> ACCEPTED) 16/12/98 (SME Comment added) PDR Submission Date: 12/03/98 Submitting State/Organization: AIRSYS ATM (ACI) Submitting Author Name: Ilkiewicz, M, Stokes, S Submitting Author E-mail Address: michel.ilkiewicz@cdv.vly.sextant. thomson-csf.com, shawn.stokes@atnsi.com Submitting Author Supplemental Contact Information: SARPs Date: IV2.2, IV2.3 (Doc 9705 Ed1) SARPs Language: English Summary of Defect: The ADS-air-ASE should abort with a reason indicating Invalid Calling Peer ID (not yet defined as a abstract syntax value for the AbortReason in section 2.2.1.4.2.1) when a D-START indication is received with a Calling Peer ID which is not a valid four to eight character facility designator. Note: Requirement 2.2.1.5.3.16.5.1 should also indicate as a precondition to this requirement that the Calling Peer ID is a valid facility designator. The responding ARF-RF-ASE should abort the dialogue when a D-START indication is received with a Calling Peer ID which is not a valid four to eight character facility designator. Assigned SME: Sub-Volume II SME Proposed SARPs amendment: Solution A/ 1/ The abstract syntax for the AbortReason in section 2.2.1.4.2.1 should add one additional value as follows: invalid-calling-peer-id (11), 2/ Change section 2.2.1.5.3.16.5.1 from: 2.2.1.5.5.16.5.1 If in the LI-A-IDLE state, and the application service priority parameter value is "high priority flight safety messages", and the RER quality of service parameter is the abstract value "low", the air LI module shall: To: 2.2.1.5.5.16.5.1 If in the LI-A-IDLE state, and the application service priority parameter value is "high priority flight safety messages", the RER quality of service parameter is the abstract value "low", and the Calling Peer ID parameter is a valid four to eight character facility designation, the air LI module shall: 3/ Add a new section 2.1.5.4.9 and subsections for the following textual requirements as follows: 2.1.5.4.9 D-START Indication Calling Peer ID Parameter Not as Expected 2.1.5.4.9.1 Upon receipt by the ADS-air-ASE of a D-START indication with a Calling Peer ID which is not a valid four to eight character facility designator, the ADS-air-ASE shall request the air AB module to abort with reason . Solution B/ In order to be able to map the value received in the D-START ind parameter to the ADS-demand/event/periodic-contract parameter, a check ON THE TYPE of the must first be performed by the ADS-air-ASE. This is not done in section 2.2.1.5.16.5.1. There is an exception handling procedure (section 2.2.1.5.4.4.2 introduced by PDR 98110002) defined for the case an unexpected primitive or a parameter primitive is received. If the peer ASE has used the wrong type for the Calling Peer Id, then the dialogue is aborted on the ground that the protocol has not been respected by the peer (reason "sequence-error"). Therefore, only change 2 in solution A/ above is proposed to be accepted. In addition, the ARF protocol shall be also modified as follows: 4/ Change section 2.2.2.5.3.5.3.1 from: 2.2.2.5.3.5.3.1 If in the RF-R-IDLE state, and if the D-START parameter is not compatible with the version number of the responding ADS-RF-ASE, and the parameter value is "high priority flight safety messages", and the RER parameter is the abstract value "low", it shall To: 2.2.2.5.3.5.3.1 If in the RF-R-IDLE state, and if the D-START parameter is not compatible with the version number of the responding ADS-RF-ASE, and the parameter value is "high priority flight safety messages", and the parameter is the abstract value "low", and the parameter is a valid four to eight character facility designation, the responding ADS-RF-ASE shall: SME Recommendation to CCB: CCB Decision: atnp_ccb_chair (SUBMITTED): 12/03/98 CCB-8 (Honolulu) : ACCEPTED (18/01/99) CCB-8a (Honolulu) : RESOLVED (21/01/99) With solution B/