Title: CPDLC - QOS in D-START Confirmation Primitive PDR Reference: 98120009 Originator Reference: acicpc03 SARPs Document Reference: CPDLC SARPs, Sections 2.3.5.3.3, 2.3.5.4.6, 2.3.5.5.3, and 2.3.5.6.6 Status: RESOLVED Impact: B (Bug) PDR Revision Date: 17/05/99 (PROPOSED -> RESOLVED) 01/03/99 (ACCEPTED -> PROPOSED) 18/01/99 (SUBMITTED -> ACCEPTED) PDR Submission Date: 03/12/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: Problem 1/ Sections 2.3.5.4.6 and 2.3.5.6.6 covers the exception handling requirement for the case where one of the QOS parameters is invalid within a D-START indication. However, the CPDLC ASE should also abort if the QOS parameters received in the D-START confirm are not valid for the CPDLC ASE. In addition, requirements related to the receipt of valid D-START confirmation primitives (see 2.3.5.3.3 and 2.3.5.5.3) need to include conditions for valid QOS parameters similar to the D-START Indication requirements. Problem 2/ Sections 2.3.5.4.6.1 and 2.3.5.6.6.1 requirements are missing a statement to create the AirPDUs or GroundPDUs APDU with a CPDLCProviderAbortReason [invalid-QOS-parameter] APDU message element in order to send in the "invoked" D-ABORT request. Note also that 2.3.5.6.6.1 is in the CPDLC-ground-ASE section and mistakenly indicates the CPDLC-air-ASE in the requirement text. Problem 3/ The assumption is made in the application SARPs that when the Routing Class abstract value "ATSC - No Traffic Type Policy Preference" is requested by the DS-user, then the DSP (actually the TSP) indicates in the D-START indication (actually the T-CONNECT indication) the actual Traffic Type ("A" to "H"). This assumption is not correct, the traffic type value supplied in the indication is always identical the one provided in the request. This means that the value "ATSC - No Traffic Type Policy Preference" may be received by the called ASE. Assigned SME: Sub-Volume II SME Proposed SARPs amendment: 1/ Change section 2.3.5.3.3.1 from: Upon receipt of a D-START confirmation, if the CPDLC-air-ASE is in the START-REQ state and the D-START Result parameter has the abstract value "accepted" and DSC has the abstract value "false" and D-START User Data parameter is not provided, the CPDLC-air-ASE shall: To: Upon receipt of a D-START confirmation, if the CPDLC-air-ASE is in the START-REQ state and the D-START Result parameter has the abstract value "accepted" and the D-START QOS Priority parameter has the abstract value "high priority flight safety message" and the D-START QOS Residual Error Rate parameter has the abstract value "low" and the D-START QOS Routing Class parameter has one of the abstract values specified in Table 2.3.6-1 and DSC has the abstract value "false" and D-START User Data parameter is not provided, the CPDLC-air-ASE shall: 2/ Change section 2.3.5.3.3.3 from: Upon receipt of a D-START confirmation, if the CPDLC-air-ASE is in the START-REQ state and the D-START Result parameter has the abstract value "accepted" and DSC has the abstract value "true" and D-START User Data parameter is not provided, the CPDLC-air-ASE shall: To: Upon receipt of a D-START confirmation, if the CPDLC-air-ASE is in the START-REQ state and the D-START Result parameter has the abstract value "accepted" and the D-START QOS Priority parameter has the abstract value "high priority flight safety message" and the D-START QOS Residual Error Rate parameter has the abstract value "low" and the D-START QOS Routing Class parameter has one of the abstract values specified in Table 2.3.6-1 and DSC has the abstract value "true" and D-START User Data parameter is not provided, the CPDLC-air-ASE shall: 3/ Change section 2.3.5.4.6 from: D-START Indication Quality of Service Not As Expected To: D-START Quality of Service Not As Expected 4/ Add a new item "b)" statement to 2.3.5.4.6.1 as follows and increment the letters of the statements that are to follow the new "b" statement [i.e., "b)" becomes "c)", "c)" becomes "d)", and "d)" becomes "e)"]: b) create an AircraftPDUs APDU with a CPDLCProviderAbortReason [invalid-QOS-parameter] APDU message element, 5/ Add new section 2.3.5.4.6.2 as follows: If a D-START confirmation QOS Priority parameter does not have the abstract value of "high priority flight safety messages" or if the QOS Residual Error Rate parameter does not have the abstract value of "low" or if the QOS Routing Class parameter does not have one of the abstract values specified in Table 2.3.6-1, and the Result parameter has the abstract value "accepted", the CPDLC-ground-ASE shall: a) stop any timer, b) create an AircraftPDUs APDU with a CPDLCProviderAbortReason [invalid-QOS-parameter] APDU message element, c) invoke D-ABORT request with: 1) the abstract value "provider" as the D-ABORT Originator parameter value, and 2) the APDU as the D-ABORT User Data parameter value, and d) if the CPDLC-air-user is an active user, invoke a CPDLC-provider-abort service indication with the CPDLC-provider-abort service Reason parameter set to the abstract value "invalid-QOS-parameter " e) if DSC has the abstract value "true", set DSC to the abstract value "false", and f) enter the IDLE state. 6/ Change section 2.3.5.5.3.1 from: Upon receipt of a D-START confirmation, if the CPDLC-ground-ASE is in the START-REQ state and the D-START Result parameter has the abstract value "accepted" and DSC has the abstract value "false" and D-START User Data parameter is not provided, the CPDLC-ground-ASE shall: To: Upon receipt of a D-START confirmation, if the CPDLC-ground-ASE is in the START-REQ state and the D-START Result parameter has the abstract value "accepted" and the D-START QOS Priority parameter has the abstract value "high priority flight safety message" and the D-START QOS Residual Error Rate parameter has the abstract value "low" and the D-START QOS Routing Class parameter has one of the abstract values specified in Table 2.3.6-1 and DSC has the abstract value "false" and D-START User Data parameter is not provided, the CPDLC-ground-ASE shall: 7/ Change section 2.3.5.6.6 from: D-START Indication Quality of Service Not As Expected To: D-START Quality of Service Not As Expected 8/ For the text in 2.3.5.6.6.1, replace "... the CPDLC-air-ASE shall:" by "... the CPDLC-ground-ASE shall" 9/ Add a new item "b)" statement to 2.3.5.6.6.1 as follows and increment the letters of the statements that are to follow the new "b" statement [i.e., "b)" becomes "c)", "c)" becomes "d)", and "d)" becomes "e)"]: b) create an GroundPDUs APDU with a CPDLCProviderAbortReason [invalid-QOS-parameter] APDU message element, 10/ Add new section 2.3.5.6.6.2 as follows: 2.3.5.6.6.2 If a D-START confirmation QOS Priority parameter does not have the abstract value of "high priority flight safety messages" or if the QOS Residual Error Rate parameter does not have the abstract value of "low" or if the QOS Routing Class parameter does not have one of the abstract values specified in Table 2.3.6-1, and the Result parameter has the abstract value "accepted", the CPDLC-ground-ASE shall: a) stop any timer, b) create a GroundPDUs APDU with a CPDLCProviderAbortReason [invalid-QOS-parameter] APDU message element, c) invoke D-ABORT request with: 1) the abstract value "provider" as the D-ABORT Originator parameter value, and 2) the APDU as the D-ABORT User Data parameter value, and d) if the CPDLC-ground-user is an active user, invoke a CPDLC-provider-abort service indication with the CPDLC-provider-abort service Reason parameter set to the abstract value "invalid-QOS-parameter " e) if DSC has the abstract value "true", set DSC to the abstract value "false", and f) enter the IDLE state. SME Recommendation to CCB: - Problem 1/ There is no need at all to check the QOS parameter of a D-START confirmation. The Priority and the Routing Class provided by the initiator ASE can not be changed by the DSP or the peer ASE (see SARPs SV4 section 4.2.3.2.1, note 7). The RER may be changed only if the requested RER is "high" (seen note 10). For ADS, the requested RER is low, therefore the peer ASE cannot change the value. Therefore, if the dialogue is established, it is established with the QOS requested by the initiator ASE. Note. Anyway, when the peer ASE invokes the D-START response, the Transport connection is already set up and its QOS parameters can not be changed. Therefore proposed changes 1, 2, 3, 5, 6, 7, 9 and 10 above are rejected. Problem 2/ (i.e.proposed changes 4/ and 8/ above) is already covered by PDR 98070003/7a. Problem 3/ The CPDLC protocol shall allow the reception of a Traffic Type parameter with the value "ATSC - No Traffic Type Preference". 11/ Add a new entry in Table 2.3.6-1: No Preference No Traffic Type Policy Preference 12/ In Note 3 of both sections 2.3.3.3.7 and 2.3.3.4.7, replace from: else the parameter indicated to the peer user is that what the dialogue service provider supplies to: else it indicates that no routing preference was requested by the CPDLC dialogue initiator. 13/ In sections 2.3.3.3.7.2 and 2.3.3.4.7.2, add else the abstract value "ATSC - No Traffic Type Policy Preference" is indicated. CCB Decision: atnp_ccb_chair (SUBMITTED): 03/12/98 CCB-8 (Honolulu): 18/01/99 (ACCEPTED) CCB-9 (Naples): RESOLVED (17/05/99)