Title: ADS - QOS in D-START Primitives PDR Reference: 98120003 Originator Reference: aciads09 SARPs Document Reference: ADS SARPs, Sections 2.2.1.5.3.16.5.1 and 2.2.1.5.4.8.1 Status: RESOLVED Impact: C (Clarification) PDR Revision Date: 17/05/99 (PROPOSED -> RESOLVED) 01/03/99 (ACCEPTED -> PROPOSED) 18/01/99 (SUBMITTED -> ACCEPTED) 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 SARPs Language: English Summary of Defect: Problem 1/ Sections 2.2.1.5.4.8.1 covers the ADS LI exception handling requirement for the case where one of the QOS parameters is invalid within a D-START indication. However, the ADS ASE should also abort if the QOS parameters received in the D-START confirm are not valid for the ADS ASE. The ADS LI requirement associated with receiving a valid D-START confirmation needs to include valid QOS parameters as a precondition (2.2.1.5.3.15.6). Problem 2/ Section 2.2.1.5.4.8.1 should also cover the case where the QOS Routing Class is not valid. The ADS LI requirement associated with receiving a valid D-START indication needs to include a valid QOS Routing class as a precondition (2.2.1.5.3.16.5.1). 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.2.1.5.3.15.6 from: Upon receipt of a D-START confirmation with the Result parameter value containing the abstract value accepted: To: Upon receipt of a D-START confirmation with the Result parameter value containing the abstract value accepted and with the application service priority parameter set to a the abstract value "high priority flight safety messages" and the RER quality of service parameter set to the abstract value "low" and the Routing Class quality of service parameter set to one of the abstract values specified in table 2.2.1.6-1: 2/ Change section 2.2.1.5.4.8.1 from: Upon receipt of a D-START indication with the application service priority parameter set to a value other than the abstract value "high priority flight safety messages", or the RER quality of service parameter set to a value other than the abstract value "low", the air LI module shall request the air AB module to abort with reason invalid-qos-parameter. To: Upon receipt of a D-START indication with the application service priority parameter set to a value other than the abstract value "high priority flight safety messages", or the RER quality of service parameter set to a value other than the abstract value "low", or the Routing Class quality of service parameter set to one of the abstract values specified in table 2.2.1.6-1, the air LI module shall request the air AB module to abort with reason invalid-qos-parameter. 3/ Add a new section 2.2.1.5.4.8.2 as follows: Upon receipt of a D-START confirmation with the application service priority parameter set to a value other than the abstract value "high priority flight safety messages", or the RER quality of service parameter set to a value other than the abstract value "low", or the Routing Class quality of service parameter set to a value other than one of the abstract values specified in table 2.2.1.6-1, the ground LI module shall request the ground AB module to abort with reason invalid-qos-parameter. SME Recommendation to CCB: - Problem 1/ There is no need at all to check the QOS parameters in 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 changes 1 and 3 are proposed to be rejected. Problem 2/ A check on the received Traffic Type value is needed to check the requested category (ATSC/AOC/other). If the AOC category is used instead of ATSC, if for some reason there is no AOC route available, the messages could not be transmitted. No check can be done on the ATSC route class since all values are authorised. Change 2 proposed above is rejected. The new proposed change is the following: 4/ Change 2.2.1.5.3.16.5.1 from: 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: to: 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", the Routing Class parameter identifies the traffic category "Air Traffic Service Communications (ATSC)" and the Calling Peer Id parameter is a valid four to eight character facility designation, the air LI module shall: 5/ Change section 2.2.1.5.4.8.1 from: Upon receipt of a D-START indication with the application service priority parameter set to a value other than the abstract value "high priority flight safety messages", or the RER quality of service parameter set to a value other than the abstract value "low", the air LI module shall request the air AB module to abort with reason . To: Upon receipt of a D-START indication with the application service priority parameter set to a value other than the abstract value "high priority flight safety messages", the RER quality of service parameter set to a value other than the abstract value "low", or the Routing Class quality of service parameter set to a value other than one identifying the traffic category "Air Traffic Service Communications (ATSC)", the air LI module shall request the air AB module to abort with reason . Problem 3/ There is no change to the ADS SARPs since the received Routing Class value is not provided to the ADS-user. The mapping Table (2.2.1.6-1) is only application for the D-START request (not the indication) and does not need to be changed. CCB Decision: atnp_ccb_chair (02/12/98): SUBMITTED CCB-8 (Honolulu): ACCEPTED (18/01/99) CCB-9 (Naples): RESOLVED (17/05/99)