Title: CM - Exception Handling Correction

PDR Reference:				97100006
Originator Reference: 			cmexception
SARPs Document Reference:		CM SARPs, Sections 2.1.4.2, 2.1.5.4
Status:					ADOPTED
PDR Revision Date:			20/10/97 (SUBMITTED -> ACCEPTED -> PROPOSED)
						29/10/97 (RESOLVED)
PDR Submission Date:			06/10/97
Submitting State/Organization: 	ATNP WG3/SG2
Submitting Author Name: 		Saccone, G
Submitting Author E-mail Address: 	gsaccone@ccgate.hac.com
Submitting Author Supplemental 
Contact Information:			ph 1 604 821-5182,
						fx 1 604 279-5980
SARPs Date:					IV1.1, March 97
SARPs Language:				English

Summary of Defect:

There are some exception handling cases which are not covered by the current CM SARPs 2.1.5.4:

1/ the first case is the receipt of a dialogue service primitive which does not contain a PDU when one was expected. 

2/ the second case is the receipt of a dialogue service primitive with a PDU when one was NOT expected can only occur in the case of the D-END and D-ABORT.  Both of these cases are not considered to be critical, since the connection is either being closed or aborted anyway.

The impacts of not correcting the SARPs for the first case may result in safety and interoperability problems, where an error can cause the system to go to an indeterminate state.  Therefore this situation must be addressed.

Assigned SME:				Sub-Volume 2 SME

Proposed SARPs amendment:

Change CMAbortReason in 2.1.4.2 from:

CMAbortReason ::= ENUMERATED
{
timer-expired					(0),
undefined-error					(1),
invalid-PDU						(2),
not-permitted-PDU					(3),
dialogue-acceptance-not-permitted		(4),
dialogue-end-not-accepted			(5),
communication-service-error			(6),
communication-service-failure			(7),
invalid-QOS-parameter				(8),
...
}

To:

CMAbortReason ::= ENUMERATED
{
timer-expired					(0),
undefined-error					(1),
invalid-PDU						(2),
not-permitted-PDU					(3),
dialogue-acceptance-not-permitted		(4),
dialogue-end-not-accepted			(5),
communication-service-error			(6),
communication-service-failure			(7),
invalid-QOS-parameter				(8),
expected-PDU-missing				(9),
...
}

Add new section 2.1.5.4.8 as follows:

2.1.5.4.8	Expected PDU Not Provided

2.1.5.4.8.1	If the User Data of a D-START indication, D-START confirmation (with the Result parameter set to the abstract value accepted), or D-DATA indication is not provided where it is expected, the CM-ASE shall:
a)	stop all timers,
b) if the CM-ASE is a CM-air-ASE, create a CMAircraftMessage APDU with a 
cmAbortReason [expected-PDU-missing] APDU message element,
c) if the CM-ASE is a CM-ground-ASE, create a CMGroundMessage APDU with a 
cmAbortReason [expected-PDU-missing] APDU message element,
d)	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,
d) invoke a CM-provider-abort service indication with the abstract value 
"expected-PDU-missing", and
f)	enter the IDLE state.

(in 2.1.5.4.8.1, "accepted", "Originator", "User Data" and "IDLE" should be italicised)

2.1.5.4.8.2	If the User Data of a D-START confirmation (with the Result parameter set to the abstract value rejected(transient) or rejected(permanent)) is not provided where it is expected, the CM-ASE shall:
a)	stop all timers,
b) invoke a CM-provider-abort service indication with the abstract value 
"expected-PDU-missing", and
c)	enter the IDLE state.

(in 2.1.5.4.8.2, "rejected(transient)", "rejected(permanent)" and IDLE should be italicised)

SME Recommendation to CCB: 		RESOLVED

CCB Decision:				CCB-3: RESOLVED