Difference between revisions of "CPDLC Air Initiated Transaction Delay for ATN"
Line 5: | Line 5: | ||
[[Image: AITransactionDelay.jpg | frame| none | CPDLC AIR INITIATED TRANSACTION DELAY]] | [[Image: AITransactionDelay.jpg | frame| none | CPDLC AIR INITIATED TRANSACTION DELAY]] | ||
− | Each different type of transaction is considered separately to determine which message initiates the transaction and which closes it. If the initial response is an ERROR message then the transaction is not included in the statistic (since the transaction will not be closed) but the [[CPDLC Technical Error Counts|error is counted]]. Also if the initial response is a LACK but an ERROR message is received subsequently for this transaction (because the the controller did not respond before the timer expired) then the transaction is also not included in the statistic but again the [[Downlink Error Counts|error is counted]]. | + | Each different type of transaction is considered separately to determine which message initiates the transaction and which closes it. If the initial response is an ERROR message then the transaction is not included in the statistic (since the transaction will not be closed) but the [[CPDLC Technical Error Counts|error is counted]]. Also if the initial response is a LACK but an ERROR message is received subsequently for this transaction (because the the controller did not respond before the timer expired) then the transaction is also not included in the statistic but again the [[Downlink Error Counts|error is counted]]. |
+ | If a STANDBY response is sent then the two elements of the transaction are measured separately as illustrated below. | ||
+ | |||
+ | [[Image: AITD_with_STANDBY.png | frame| none | CPDLC AIR INITIATED TRANSACTION WITH STANDBY]] |
Revision as of 11:13, 21 November 2014
The CPDLC Air Initiated Transaction Delay is a part of the CPDLC ground initiated transactions performance statistics. It is the time taken between the message that initiates a transaction being sent and the corresponding message that closes the transaction being received.
The time provided in the header of the CPDLC LACK message sent from the aircraft is considered as giving a fairly accurate indication of when the associated uplink message has been processed and is available to the pilot. Similarly the timestamp in the header of the CPDLC request from the aircraft can be considered as giving a reasonable indication of when the pilot made the request.
Each different type of transaction is considered separately to determine which message initiates the transaction and which closes it. If the initial response is an ERROR message then the transaction is not included in the statistic (since the transaction will not be closed) but the error is counted. Also if the initial response is a LACK but an ERROR message is received subsequently for this transaction (because the the controller did not respond before the timer expired) then the transaction is also not included in the statistic but again the error is counted. If a STANDBY response is sent then the two elements of the transaction are measured separately as illustrated below.