Title: PROBLEMS WITH ICAO V2.2 CPDLC SARPS 
     
PDR Reference:              	98050019
Originator Reference:			
SARPs Document Reference:   	CPDLC SARPs section 2.3.4.2.1
					AIDC SARPs section 3.2.7.1.1
Status:                     	RESOLVED
Impact :				B (Bug)
PDR Revision Date:          	25/06/98 (PROPOSED -> RESOLVED)
					10/06/98 (item #6 added and SUBMITTED -> ACCEPTED 
					-> PROPOSED)
PDR Submission Date:		29/05/98
Submitting State/Organization:  		Eurocontrol (TES)
Submitting Author Name:           		Kerr, T
Submitting Author E-mail Address:	
Submitting Author Supplemental
Contact Information:
SARPs Date:                 		    	IV2.2, Rio 
SARPs Language:                    		English
     
Summary of Defect:

In order to update the Eurocontrol TES implementation to be compatible with the official ICAO V2.2 publication, the PDRs which are RESOLVED in V2.2 are being applied to the existing software, which is compliant to the Phuket (V1.1) SARPs.  In comparing the PDRs for CPDLC with the ICAO V2.2 text, I encountered the following discrepancies:

1. PDR 97100015 changed the name of AirwayIdentifier to ATSRouteDesignator. In the Phuket SARPs, the constraint of AirwayIdentifier was given as (2..6), yet both PDR 97100015 and the CPDLC V2.2 text show the constraint as (2..7). Where did the changed constraint come from?

2. In CPDLC V2.2 text, PDR 97100016 has not been applied exactly as stated in the PDR.  Frequencyvhf should be Frequencyvhfchannel throughout, and the unit of Frequencyvhfchannel should be VHFchannel, not Megahertz.

3. In CPDLC V2.2 text, PDR 97100039 has not been applied exactly as stated in the PDR.  PositionRouteClearance should have been renamed PositionRouteClearanceIndex, and the identifier routeClearance should be routeClearanceIndex.

4. Errors in PDR 97100039: In the PDR itself, the ATCDownlinkMessageData definition should not contain the line: "header   ATCMessageHeader,".  In bullet 5/, ATCUplinkMsgElementId should read ATCDownlinkMsgElementId (the 2.2 texts are OK)

5. In CPDLC V2.2 text, tags [1], [2] and [3] have been added to UnitName. PDR 97080010 did not include such tags.

6. In CPDLC V2.2 text, item #7 and #8 of PDR 97100026 have not been applied exactly as stated in the PDR. item b) in proposed section 2.3.5.4.6.1 and 2.3.5.6.6.1 are missing in the SARPs text. In section 2.3.5.6.6.1, the reference to the CPDLC-ASE should be "CPDLC-ground-user".  In addition, the reference in section 8 of the PDR itself is wrong (it should be 2.3.5.6.6.1).

Assigned SME:                    		Sub-Volumes II and III SMEs

Proposed SARPs amendment:		

1. (2..6) is the operational constraint given in the ICAO Manual of the ATS Data Link Applications. Edition 2.2 ICAO SARPs specifies (2..7) probably because of the collision of two PDR resolutions (change of the constraint + change of the name). The ADSP was made aware of the 2-7 from 2-6 range for size.  This was put in as there was input that in the future this size would be needed. No SARPs modification is proposed.  

2. The ADSP strongly disagreed with renaming choice [1] to frequencyvhfchannel, and wanted it to remain frequencyvhf (since it still is for VHF frequencies, but it can with resolution changes handle the new requirement (the change used to be accomplished with a new independent choice [4] for the 8.33 split)).  ADSP requested the CPDLC editor to rename it "Frequencyvhf". This has been done but not reported in the PDR. PDR 97100016 will be updated accordingly.

The same change - for the same reason - should have been applied to the AIDC ASN.1 definition.

Change in AIDC SARPs section 3.2.7.1.1 from:

Frequency ::=  CHOICE
	{
	frequencyHF		[0]	FrequencyHF,
	frequencyVHFChannel	[1]	FrequencyVHFChannel,
	frequencyUHF		[2]	FrequencyUHF,
	frequencySatChannel	[3]	FrequencySatChannel
	} 

FrequencyVHFChannel ::= INTEGER (23600..27398) 
-- Unit= VHF Channel, Range (118.000..136.990), resolution = 0.005

to:

Frequency ::=  CHOICE
	{
	frequencyHF		[0]	FrequencyHF,
	frequencyVHF		[1]	FrequencyVHF,
	frequencyUHF		[2]	FrequencyUHF,
	frequencySatChannel	[3]	FrequencySatChannel
	} 

FrequencyVHF ::= INTEGER (23600..27398) 
--unit = Megahertz, Range (118.0000..136.990), resolution = 0.005


3. This change for some unknown reason was incorrectly implemented in CPDLC.

Change CPDLC section 2.3.4.2.1 from:

PositionRouteClearance ::= SEQUENCE
{
     position           	Position,
     routeClearance       	RouteClearanceIndex
}
     
to:
     
PositionRouteClearanceIndex ::= SEQUENCE 
{
     position           	Position,
     routeClearanceIndex  	RouteClearanceIndex
}

4. This is correct. The change has been agreed at the CCB level but the PDR was not updated. The PDR will be updated accordingly.

5. This is correct. The convention used by the SARPs editor when generating the ASN.1 is to tag the fields in a SEQUENCE when at least one is optional. This convention has been applied when changing the SARPs. The PDR will be updated accordingly.

6. Item 8 of PDR 97100026 will be updated to refer section 2.3.5.6.6.1.

Change SARPs section 2.3.5.4.6.1 from:

a) Stop any timer,
b) Invoke D-ABORT request with:
c)
d)

to:

a) Stop any timer,
b) Create an AircraftPDUs APDU with CPDLCProviderAbortReason [invalid-QOS-parameter] APDU message element,
c) Invoke D-ABORT request with
d)
e)

Change SARPs section 2.3.5.6.6.1 from:

the CPDLC-air-ASE shall:

a) Stop any timer,
b) Invoke D-ABORT request with:
c)
d)

to:

the CPDLC-ground-ASE shall:

a) Stop any timer,
b) Create an GroundPDUs APDU with CPDLCProviderAbortReason [invalid-QOS-parameter] APDU message element,
c) Invoke D-ABORT request with
d)
e)

SME Recommendation to CCB:          	

CCB Decision:                    		atnp_ccb_chair: SUBMITTED (29/05/98)
					atnp_ccb_chair: ACCEPTED (10/06/98)
					CCB-6 (Utrecht): RESOLVED (25/06/98)