Title: CM - Conflicting Requirements 

PDR Reference:                    		98120008
Originator Reference:                 	acicm06 
SARPs Document Reference:            	CM SARPs, Section 2.1.5.4.3.2
Status:                                	RESOLVED
Impact :						D (Minor)
PDR Revision Date:                    	21/01/99 (PROPOSED -> RESOLVED)
							19/01/99 (ACCEPTED -> PROPOSED)
							15/12/98 (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:

There is a conflict between requirements 2.1.5.4.5.1 and requirement 2.1.5.4.3.2 (item b in particular).  Section 2.1.5.4.5.1 indicates that the CM ASE should Abort with reason "dialogue-acceptance-not-permitted" when a D-START Confirmation is received with the result of "accepted".  2.1.5.4.3.2 covers the case where the D-START confirmation does not contain a valid PDU, but item b indicates how to Abort with Reason "invalid-PDU" if the abstract value is "accepted".  These two requirements conflict.

The proposed solution is that 2.1.5.4.3.2 has relevance only if the Result is not "accepted" and item b can then be removed.

Assigned SME:                              Sub-Volume II SME

Proposed SARPs amendment: 

Solution 1/
The requirement text for section 2.1.5.4.3.2 should be changed from:

If the User Data parameter of a D-START confirmation does not contain a valid PDU as defined in 2.1.5.3.1.3 and 2.1.5.3.1.4, the CM-ASE shall:

a) stop all timers

b) if the D-START Result parameter is set to the abstract value "accepted", then

1) ...
2) ...
3) ...

c) if the CM-user is an active user, invoke CM-provider-abort service indication with the abstract value "invalid-PDU" as the CM-provider-abort Reason parameter value, and

d) enter the IDLE state

To:

If the User Data parameter of a D-START confirmation does contains a D-START Result parameter with an abstract value of "rejected (permanent)", but does not contain a valid PDU as defined in 2.1.5.3.1.3 and 2.1.5.3.1.4, the CM-ASE shall:

a) stop all timers

b) if the CM-user is an active user, invoke CM-provider-abort service indication with the abstract value "invalid-PDU" as the CM-provider-abort Reason parameter value, and

c) enter the IDLE state

Solution 2/

Solution 1 is not correct since section 2.1.5.4.3.2 b) is applicable to the CM-air-ASE (reception of a CM-logon cnf). Therefore item b) cannot be removed. Note that 2.1.5.4.5.1 is applicable only to the CM-ground-ASE (reception of a CM-update cnf). There is therefore a conflict only for the CM-ground-ASE upon receipt of a positive D-START cnf, i.e. between section 2.1.5.4.3.2 b) 2) and section 2.1.5.4.5.1. 

It is proposed to remove from section 2.1.5.4.3.2 the requirement b) 2) related to the CM-ground-ASE. Section 2.1.5.4.3.2 should read as follows:

2.1.5.4.3.2 If the <User Data> parameter of a D-START confirmation does not contain a valid PDU as defined in 2.1.5.3.1.3 and 2.1.5.3.1.4, the CM-ASE shall:
a) stop all timers,
b) if the CM-ASE is a CM-air-ASE and if the D-START <Result> parameter is set to the abstract value "accepted", then:
	1) create a CMAircraftMessage APDU...
	2) invoke D-ABORT request with:...
           i) the abstract value...
           ii) the APDU...
c) if the CM-user is an active-user,...
d) enter the <IDLE> state.

SME Recommendation to CCB:              		   

CCB Decision:                     	atnp_ccb_chair (SUBMITTED): 03/12/98
						atnp_ccb_chair (ACCEPTED): 15/12/98
						CCB-8a (Honolulu): RESOLVED (21/01/99)
									  With solution 2