DLS AP Validation Report v10Length (lg) – 8 bits Frequency (f) – 11 bits 2.4.3.2 If default...

Validation Report AMCP/WGM/5 Attachment B to the DLS Amendment Proposal

Version 1.0 – 09/08/02 HELIOS TECHNOLOGY 1 of 44

AA nneeww DDLLSS pprroottooccooll ffoorr VVDDLL MMooddee 44 ddaattaalliinnkk

VVaalliiddaattiioonn RReeppoorrtt

The content of this document is basically the same as that presented in version 0.2 of theValidation Report released on 26th June 2002 and sent on the 2nd of July 2002 to WGMmembers. The differences are editorial changes and corrections.

Document information

Document title A new DLS protocol for VDL Mode 4 datalink: Validation Report

Author Paul Ravenhill, Anita Woogara, Helios Technology

Produced by Helios Technology Ltd

Chamberlain House

High Street

Bagshot

Surrey

GU19 5AE

Tel: +44 1276 452 811

Fax: +44 1276 472 897

Produced for Nikos Fistas, Eurocontrol

Helios contact Dr Michael G Shorthose

Tel: +44 1276 452 811

Fax: +44 1276 472 897

Email: [email protected]

Produced under contract TRS/150

Version 1.0

Date of release 9 August 2002

Document reference P196D010



Contents

1 Introduction............................................................................................................ 3

1.1 Purpose ................................................................................................................... 3

1.2 Scope ...................................................................................................................... 3

1.3 Document Structure ................................................................................................. 3

2 Scope...................................................................................................................... 4

2.1 Validation Activities .................................................................................................. 4

2.2 Context .................................................................................................................... 4

2.3 LME Services........................................................................................................... 6

2.4 VSS Services........................................................................................................... 6

3 Analysis .................................................................................................................. 8

3.1 Introduction .............................................................................................................. 8

3.2 Context Diagram...................................................................................................... 9

3.3 DLS Procedures......................................................................................................10

3.4 The Disconnected State..........................................................................................13

3.5 The Connected State ..............................................................................................14

3.6 The Reset State ......................................................................................................14

3.7 Combined frames....................................................................................................14

3.8 Interface with LME ..................................................................................................16

3.9 VSS Requests ........................................................................................................16

3.10 Issues arising from Analysis ....................................................................................17

4 Inspection..............................................................................................................18

4.1 DLS Services (TM 1.4.1).........................................................................................18

4.2 DLS Protocol Specification (TM 1.4.2) ....................................................................19

4.3 DLS System Parameters (TM 1.4.3) .......................................................................22

4.4 DLS Procedures (TM 1.4.4) ....................................................................................23

5 Conclusions and Recommendations ..................................................................35

5.1 Assumptions ...........................................................................................................35

5.2 Recommendations ..................................................................................................35

5.3 Issues .....................................................................................................................35

5.4 Further Analysis ......................................................................................................36

5.5 Conclusion ..............................................................................................................36

6 Acronyms ..............................................................................................................37

A Summary of Issues ...............................................................................................38



1 Introduction

1.1 Purpose

1.1.1 This document describes the output of the validation task being undertaken as partof a study to provide a new DLS protocol for VDL Mode 4 datalink being carriedout on behalf of Eurocontrol under contract TRS/150/01.

1.2 Scope

1.2.1 The current exercise has considered Section 1.4 of the VDL Mode 4 TechnicalManual. The version inspected is held under configuration control by the validationteam as ‘P196D007 v0_51TM_AMCP_rev2chv5 G1.doc’. Within this document,references TMx.x.x are to the document under validation.

1.2.2 The current validation exercise includes inspection and analysis. No simulationhas been performed. A simulation of the DLS Protocols will be developed in thenext phase of work.

1.2.3 The validation team has used the following classification for issues:

§ Major – issues where the validation team believes the protocol will not supportits intended purpose, or where insufficient detail is currently provided to allowsuch a judgement to be made.

§ Minor – issues where the validation team believes that the protocol could beimproved by further consideration.

§ Editorial – minor corrections to the text with obvious solutions.

1.3 Document Structure

1.3.1 The report is structured as follows:

§ Section 2 provides a definition of the context in which the DLS operates. Thismaterial has been prepared to support the Validation team’s understanding ofthe rationale for elements of the DLS protocol.

§ Section 3 provides a commentary on the DLS protocol. This material has beenprepared by the validation team in order to document their understanding ofthe protocol under validation. Validation issues are raised during thecommentary. The commentary is presented in the order of the material in thetechnical manual. This section describes the results of the inspection task.

§ Section 4 describes the Validation teams understanding of the protocol usingProcess Diagrams. This section describes the results of the analysis task.

§ Section 5 summarises the assumptions, recommendation and conclusions ofthe validation activity.

§ Section 6 provides a list of acronyms used in the report.

§ Annex A provides a summary table of the issues raised in the report.



2 Scope

2.1 Validation Activities

2.1.1 This document represents the output of Task 2 ‘Initial Inspection and Analysis’ ofthe VDL Mode 4 DLS Change Proposal Validation Plan (AMCP/WGM4, WorkingPaper 18).

2.1.2 The task involved inspection and analysis of the DLS Protocol. These activitieswere carried out in iterative manner. Section 3 provides details of how the analysiswas undertaken and general issues arising from the analysis. Section 4 describesthe results of the inspection. Each section of the proposed standard is reported onin turn.

2.1.3 The remainder of this section provides information on:

§ The context of the DLS

§ LME Use of the DLS

§ VSS Services used by the DLS.

2.2 Context

2.2.1 VDL Mode 4 is an aeronautical communications system employing the Self-organised Time Division Multiple Access (STDMA) scheme to support bothbroadcast and point-to-point datalink services.

2.2.2 The many VDL Mode 4 protocols allow stations to ‘reserve’ their portion of channeltime for making transmissions. The management of the time slots is shared amongall the participating stations.

2.2.3 The self-organising concept allows VDL Mode 4 to operate efficiently without acentralised coordinating station, thus eliminating the need for groundinfrastructure. Ground stations may however serve an important role providingother services that enhance Mode 4 operations.

2.2.4 As illustrated in figure 1, the Data Link Service (DLS):

§ Provides services to external users in order to support point-to-point, multi-castand broadcast communications.

§ Provides services to the LME to support link management.

§ Supports services between peer DLSs.

§ Uses the services of the VSS in order to send and receive message.



LME

DLS User

DLS Peer DLS

VSS

Figure 2-1 DLS Services

2.2.5 The following diagram illustrates the use of various services provided by the DLSand VSS in supporting DLS User and LME.

Directed Data(INFO, CTRL)

Short Acknowledged

LongAcknowledged

ShortUnacknowledged

LongUnacknowledged

Unicast RequestReservation

InformationTransferRequest

GeneralResponseProtocol

Retransmission

Connection Management (IB/SZOM)Message Segmentation (M-bit)

Delivery Order (T-bit)

Broadcast Data(UDATA)

DLS

VSS

DLS User LME

Figure 2-2 Use of DLS and VSS Functions



2.3 LME Services

2.3.1 The LME utilises the DLS Services during connection establishment using theCTRL, CTRL_RTS, CTRL_CTS and CTRL_ACK DLPDUs. The content of theseDLPDUs has not been considered.

2.3.2 The LME uses the same basic services as the DLS User.

2.4 VSS Services

2.4.1 Services Used

2.4.1.1 The following VSS Services are used:

§ Unicast Request Reservation (TM Section 1.3.14)

§ Information Transfer Request (TM Section 1.3.15)

§ General Response Protocol (TM1.3.20)

§ Retransmission (TM1.3.21)

2.4.2 Unicast Request Reservation (TM Section 1.3.14)

2.4.2.1 The unicast request reservation is used to reserve a response to a message andcontains the following:

§ Destination address (d) – 27 bits

§ Response Offset (ro) – 12 bits

§ Length (lg) – 8 bits

§ Source/Destination Flag (sdf) – 1 bit

§ Priority (pr) - bits

2.4.2.2 If default values are not required, the VSS user (in this case the DLS) is requiredto provide values for:

§ V32, V33, V34, V35 and V36

§ Q2a, Q2b, Q2c, Q2d, Q4, Q5 (Q5min, Q5max, Q5mult, Q5exp, Q5num,Q5wait)

2.4.2.3 It is noted that a common agreement of V32, V33, Q2a-d and Q5 is requiredbetween peers.

2.4.3 Information Transfer Request (TM Section 1.3.15)

2.4.3.1 The information transfer request is used to reserve a response to a messagealong with the subsequent acknowledgement. The information transfer requestcontains the following:

§ Destination address (d) – 27 bits

§ Response Offset (ro) – 12 bits

§ Acknowledgement Offset (ao) – 7 bits



§ Length (lg) – 8 bits

§ Frequency (f) – 11 bits

2.4.3.2 If default values are not required, the VSS user (in this case the DLS) is requiredto provide values for:

§ V32, V33, V34, V35 and V36

§ Q2a, Q2b, Q2c, Q2d, Q4, Q5 (Q5min, Q5max, Q5mult, Q5exp, Q5num,Q5wait)

2.4.3.3 It is noted that a common agreement of V32, V33, Q2a-d and Q5 is requiredbetween peers.

2.4.4 General Response Protocol (TM1.3.20)

2.4.4.1 The General Response Protocol is used to transmit a general failure or generalconfirm. It is not used directly by the DLS, but may be used by the VSS to reportconditions to the peer-VSS relating to the VSS User (ie the DLS).

2.4.5 Retransmission (TM1.3.21)

2.4.5.1 The retransmission procedure is used to repeat a transmission for which ananticipated response has not been received, for example a unicast requestreservation with sdf =0.

2.4.5.2 The retransmission procedures are not used directly by the DLS. The DLSspecifies the Q5 parameters when issuing the original request.



3 Analysis

3.1 Introduction

3.1.1 This section describes the results of an analysis of the protocol conducted by thevalidation team.

3.1.2 The following approach was followed during the analysis:

§ Air-ground and air-air protocols were considered separately.

§ Three states were considered:

- Disconnected

- Connected

- Reset

§ Process Diagrams (also known as Flow Charts) were developed for each state.

3.1.3 The following considerations are important to understanding the ProcessDiagrams:

§ The transmit and receive sides operate separately, but the reset state effectsboth sides.

§ A combined frame may update both transmit and receive sides

§ A combined frame may link two transmissions

§ Except for combined frames, only a single data packet shall be in transmit at agiven time.

§ Except for combined frames, only a single data packet shall be in receipt at agiven time.

§ The VSS is responsible for re-transmissions. These are not shown on theProcess Diagrams.

§ The DLS resets the link when a CTRL_CTS or INFO_CTS DLPDU is receivedfor which the T bit is not equal to Tt.

§ The DLS does not re-send a packet that has not been delivered; it selects thenext packet (excluding partial M-bit sequences).

§ The DLS informs DLS user if a data packet was not delivered.

3.1.4 The following stimuli exist for state transitions:

§ Reception of DLS Request from End User (INFO or UDATA)

§ Reception of DLS Request from LME (CTRL)

§ Notification from VSS of received DLPDU

§ Notification from VSS of failed response (not currently supported by standard)



3.2 Context Diagram

3.2.1 The following diagram illustrates the context for the DLS.

Connected ResetDisconnected

DLSDLS User

LME

VSS

Rx Data, Notifications

Rx Data, Failure Notifications

Tx Data

Tx Data

Rx DLPDUs, Failure Notifications

Tx DLPDUs,

FRMR_ACK Received

Invalid T-bit

Timer Expires

SZOMCTRL(IB=1)

Figure 3-1 Context Diagram

3.2.2 Initially, all station pairs are considered to be in disconnected state.

3.2.3 A connection is established:

§ For air-air: When a station wishes to transmit to a station without an activeconnection. A successful connection is established only when the transfer ofan SZOM associated with an INFO DLPDU has been successfully transferred.

§ For air-ground: At the instigation of the LME. A successful connection isestablished only when the transfer of a CTRL DLPDU with IB = 1 has beensuccessfully transferred.

3.2.4 A connection is cleared:

§ For air-air: When TD1 or TD2 expires.

§ For air-ground: No Stimuli.

3.2.5 A connection is reset:

§ When a CTRL_CTS or INFO_CTS DLPDU is received for which the T bit is notequal to Tt.



3.3 DLS Procedures

3.3.1 Stimuli

3.3.1.1 The following table defines which procedures handle which stimuli.

Type Stimuli Procedure

DLS_User Request All requests Transmit

LME Request All requests Transmit

_CTS, _ACK Transmit

DM_DISC Change connection statusto Disconnect

INFO, CTRL, UDATA, _RTS Receive

DLPDU from VSS

FRMR, FRMR_ACK Reset

No_CTS, No_ACK TransmitVSS Notification of Failure

No_DATA Receive

3.3.2 Transmission Procedures

3.3.2.1 The transmission process handles the following stimuli:

§ Reception of DLS Request from End User (INFO or UDATA)

§ Data is placed in Send Array.

§ Reception of DLS Request from LME (CTRL)

§ Data is placed in Send Array.

§ Notification from VSS of received DLPDU:

§ CTS

§ ACK

§ Notification from VSS of failed response

§ CTS not received

§ ACK not received



3.3.2.2 The following diagram illustrates the basic process for sending a data packet.

Start

Length?

SendDATA

SendRTS

CTS?

ACK?

END

Short Long

Incorrect T-bit

Correct T-bit

None Received

Correct T-bit

Reset

Wrong T-bit

None Received

Undefined Action

Undefined Action

Figure 3-2 Transmit Processing

3.3.2.3 UDATA transmissions do not require the ACK.

3.3.2.4 If an ACK is received with the wrong T-bit it is assumed to be a NACK and thepacket is resent.

3.3.2.5 If an ACK is not received (and the VSS gives up resending the DATA) then noaction is defined.

3.3.2.6 When the process reaches END, the next DATA DLPDU is selected fortransmission.

3.3.3 Reception Procedures

3.3.3.1 The reception process handles the following stimuli:

§ Notification from VSS of received DLPDU:

§ DATA

§ RTS

3.3.3.2 The following diagram illustrates the process for receiving a data packet (shorttransmission procedure).



Start

Type?

Send ACKForward to

Receive Array

ForwardTo DLS

User

T-bit?

END

INFO, CTRL

UDATA

Incorrect T-bit

Correct T-bit

Undefined Action

Figure 3-3 Receive Processing (short)

3.3.3.3 If the reservation for the ACK is missed, no further action is taken by the DLS.

3.3.3.4 TM1.4.4.6.2 does not specify actions when a DATA DLPDU is received with anincorrect T-bit.

3.3.3.5 The following diagram illustrates the process for receiving a RTS packet (start of along transmission procedure).

Start

RTSType?

Send ACKForward to

Receive Array

SendCTS

T-bit?

END

INFO, CTRL

UDATA

IncorrectT-bit

Correct T-bit

Correct T-bit

T-Bit?

Send NACKDiscardDATA

DataType?

Incorrect T-bit

ForwardTo DLS

User

UDATA

None Received

INFO, CTRL

Figure 3-4 Receive Processing (long)



3.3.4 Reset Procedures

3.3.4.1 The following diagram illustrates the procedure for a station initiating the resetstate:

Figure 3-5 Reset Processing (initiate)

3.3.4.2 When waiting for a FRMR_ACK, invalid packets may be received (ie the other endstarting a new transmission). A new FRMR is sent.

3.3.4.3 Failure to receive a FRMR_ACK is not considered by the standard.

3.3.4.4 The following diagram illustrates the procedure for a station receiving a reset:

Reset_Reply

Send FRMR_ACKClear Receive Arrays

End

Figure 3-6 Reset Processing (receive)

3.3.4.5 During the reset procedure both transmit and receive arrays are discarded.

3.4 The Disconnected State

3.4.1 Air-Air Disconnected

3.4.1.1 In the air-air disconnected state, it is possible to transmit/receive:

§ INFO (with SZOM)

§ UDATA

3.4.1.2 The connection is deemed established following the successful transfer of INFO(with SZOM). The contents of the SZOM indicate the set of default parameters foruse over the link. The lowest value is used to determine the set to be used if thevalues are different.

Reset

SendFRMR

FRMRACK?

End

No action defined

Valid

InvalidFailure



3.4.1.3 Action on receipt of INFO (without SZOM) is to send a DM/DISC.

3.4.1.4 Action on receipt of a CTRL is not specified.

3.4.2 Air-Ground Disconnected

3.4.2.1 In the air-ground disconnected state, it is possible to transmit/receive:

§ CTRL (IB equal to 1)

§ UDATA

3.4.2.2 The connection is deemed connected following the successful transfer of a CTRL(with IB equal to 1).

3.4.2.3 Action on receipt of CTRL (IB not equal to 1) is to send a DM/DISC.

3.4.2.4 Action on receipt of a SZOM is not specified.

3.5 The Connected State

3.5.1 Air-Air Connected

3.5.1.1 During the connected state for an Air-Air connection, the TD1 and TD2 timers areactive. When a timer expires the link is considered disconnected. It is not clear ifboth timers need to expire before the link is considered disconnected.

3.5.1.2 Receipt of a DM/DISC in the connected state would indicate an error. An SZOMshould be combined with the next INFO transmitted.

3.5.1.3 Action on receipt of an SZOM in the connected state is not defined.

3.5.1.4 A station could continuously receive UDATA using the short protocol and TD1would expire.

3.5.2 Air-Ground Connected

3.5.2.1 In the air ground connected state, it is possible to transmit/receive:

§ INFO

§ CTRL (IB not equal to 1)

§ UDATA

3.5.2.2 Action on receipt of a SZOM is not specified.

3.6 The Reset State

3.6.1 The reset state exists so that all DLPDUs except the FRMR_ACK can be rejected.The reset state lasts until a FRMR_ACK is received. The reset state is equallyapplicable to air-air and air-ground procedures.

3.7 Combined frames

3.7.1 Purpose

3.7.1.1 The DLS allows for the combination of DLPDUs to support:

§ Chaining sequences of DATA packets being transmitted using:



§ RTS/DATA

§ ACK/CTS

§ Piggy-backing transmissions on to reception acknowledgement using:

§ ACK/DATA (if data fits into single slot)

§ ACK/RTS (if data does not fit into a single slot)

3.7.1.2 The purpose of this section is to identify changes to the procedures required tosupport packet combinations.

3.7.1.3 The DATA DLPDU is always processed first so that the toggle bit sequence iscorrect.

3.7.2 Chaining sequences of DATA packets

3.7.2.1 In order to chain a sequence of DATA packets, a RTS is sent with each DATApacket. The following diagram shows the required decision point in thetransmission process.

Figure 3-7 Chaining Sequences of Data Packets

3.7.3 Piggybacking Transmissions

3.7.3.1 Whenever an ACK is sent, the possibility of combining a DATA or RTS should beconsidered.

Start

SendDATA

SendRTS

CTS?

ACK?

END

Incorrect T-bitCorrect T-bit

CTS/ACK

Correct T-bit

Reset

Wrong T-bit

Chain?

SendDATA/RTS

Response?

T-bits?

ACK

Correct T-bit

Incorrect T-bit

NoYes



3.8 Interface with LME

3.8.1 The interface with the LME requires the DLS to send Data using either the CTRLDLPDUs or the UDATA DLPDUs.

3.8.2 The LME uses the DLS services in the same way as the DLS User.

3.9 VSS Requests

3.9.1 The following table identifies the VSS Requests associated with each singleDLPDU including SZOM combined with INFO, INFO_RTS, INFO_CTS andINFO_ACK.

DLPDU Type VSS Request Actions

CTRL (short)INFO (short)

Unicast Request Reservation Send Packet (random access)Reserve ACK (sdf = 0)

CTRL (long)INFO (long)

None Send Packet (in reservation)

UDATA None Send Packet (in reservation if long)

CTRL_RTSINFO_RTSUDATA RTS

Unicast Request Reservation Send Packet (random access)Reserve CTS (sdf = 0)

CTRL_CTSINFO_CTS

Information Transfer Request Send Packet (in reservation)Reserves DATAReserves ACK

UDATA_CTS Unicast Request Reservation Send Packet (in reservation)Reserves UDATA (sdf = 0)

CTRL_ACKINFO_ACK

None Send Packet (in reservation)

FRMR Unicast Request Reservation Send Packet (in reservation)Reserve FRMR_ACK (sdf = 0)

FRMR_ACK None Send Packet (in reservation)

DM/DISC None Send Packet (in reservation)

Table 3-1



The following table identifies the VSS Requests associated with each combined DLPDU.

DLPDU Type VSS Request Actions

Combined Packets

RTS/INFORTS/CTRL

Unicast Request Reservation Send Packet (in reservation)Reserves CTS/ACK (sdf = 0)

RTS/UDATA Unicast Request Reservation Send Packet (in reservation)Reserves CTS (sdf = 0)

ACK/INFO_CTSACK/CTRL_CTS

Information Transfer Request Send Packet (in reservation)Reserves DATAReserves ACK

ACK/UDATA_CTS Unicast Request Reservation Send Packet (in reservation)Reserves UDATA (sdf = 0)

ACK/INFOACK/CTRL

Unicast Request Reservation Send Packet (in reservation)Reserves ACK (sdf = 0)

ACK/INFO_RTSACK/CTRL_RTS

Unicast Request Reservation Send Packet (in reservation)Reserves CTS (sdf = 0)

Table 3-2

3.10 Issues arising from Analysis

3.10.1 Issues arising from the analysis have generally been raised in the Section 4. Thiswas considered a more convenient means of presenting the results.

3.10.2 The following additional general issues also arose during the analysis.

Issue 1 Category Major Section General

Description It is not clear from the descriptions that VSS is responsible for re-transmissions. The text should be clearer.


Description The VSS does not inform the DLS if a retransmission procedure fails.This leads to the failure of the protocol.


Description Action on receipt of a DM/DISC is not defined.


Description It is not clear if an air-ground connection should be deemed establishedfollowing the completion of the CTRL exchange or on notification by theLME.


Description No stimuli exists for disconnecting an air-ground connection.



4 Inspection

4.1 DLS Services (TM 1.4.1)

4.1.1 DLS Services are described in:

§ Section 1.4 that states ‘the DLS shall support communications on a sharedcommunications channel… ’

§ Section 1.4.1 which states ‘The DLS shall support bit-orientated simplexair/ground (A/G) communications using a negotiated setup connection-orientated protocol (NSCOP).’

§ Note 1 (in Section 1.4.1) which states ‘For ground-air communications, theDLS supports communication over a link controlled by the LME.

§ Section 1.4.1 that states ‘The DLS shall support air/air (A/A) communicationsusing a zero-overhead connection-orientated protocol (ZOCOP).’

§ Note 2 (in section 1.4.1) which states ‘For air-air communication, a zero-overhead connection–oriented protocol is specified.’

4.1.2 It is noted that nothing presented in Section 1.4 is contrary to a bit-orientedair/ground communications, although full validation of this statement would requirefull implementation.

4.1.3 The validation team understands that:

§ The DLS User is offered a connectionless service. The DLS user is not awareif the required connection has been established, the DLS user is notresponsible for managing the connection establishment.

§ The DLS mediates DLS User Request by providing a connection-orientedservice over the air-ground datalink.

4.1.4 This understanding is illustrated in Figure 4-1.

DLS DLSDLSUser

DLSUser

Connection-less service

Connection-oriented service

Connection-less service

Figure 4-1 Relationship between DLS User and DLS Peer Services

4.1.5 The validation team feels that the services offered to the DLS user should beexplicitly stated. The following points should be clarified:

§ Does the DLS user establish the connection?

Assumption 1: The DLS user is not responsible for establishing connections.

§ Can the DLS user reset the connection?

Assumption 2: The DLS user cannot reset the connection.

§ Is the DLS user informed if an attempt to send a data packet was successful orunsuccessful?

Assumption 3: The DLS user is not informed of the success of a data transferrequest.



Issue 6 Category Major Section 1.4

Description Insufficient detail is included on the interfaces to the DLS.

4.1.6 TM1.4.1.1 infers that user data is transferred in CTRL DLPDUs. It is the validationteams understanding that LME data is transferred in these DLPDUs.

Issue 7 Category Editorial Section 1.4.1.1

Description Clarify that LME data not User Data is transferred in CTRL DLPDUs.

4.1.7 TM1.4.1.2 infers that all data packets are delivered in sequence. This is only truefor data packets for a given priority.

4.1.8 Assumption 4: The order of data delivery is only important for data requests atthe same priority and in particular within M-bit sequences.


Description Clarify statement on delivery sequence of data packets.

4.1.9 TM1.4.1.3 infers that the DLS layer is responsible for error detection. It is thevalidation teams understanding that the MAC layer incorporates the CRC. TheDLS plays no part in ensuring that corrupted packets are discarded using thismechanism.

4.1.10 Assumption 5: The MAC layer is responsible for error detection.


Description Clarify statement on the DLS being responsible for error correction ratherthan the MAC layer.

4.1.11 TM1.4.1.4 and TM1.4.1.5 infer that the DLS layer is responsible for acceptingDLPDUs depending upon address criteria. This would appear to be a VSS issue.

4.1.12 Assumption 6: The VSS is responsible for accepting DLPDUs according toaddress.

Issue 10 Category Editorial Section 1.4.1.4 / 5

Description Clarify statement on the DLS being responsible for accepting DLPDUs onaddress criteria rather than the VSS.

4.2 DLS Protocol Specification (TM 1.4.2)

4.2.1 TM1.4.2.1 refers to the maintenance of certain state variables, namely:

§ Tt

§ Tr

§ Send array

§ Receive array



4.2.2 ‘State variables’ seems an odd name for arrays and expected toggle bit settings. Astation will have to maintain other data, for example a list of stations for which anactive connection is established. The maximum number of station pairs for whichthe variables are maintained should be stated.


Description Change ‘State variables’ to ‘Resources’

Issue 12 Category Minor Section 1.4.2.1

Description Describe number of station pairs for which resources should bemaintained.

4.2.3 Further, it is noted that the send array contains all data queued for transmission.This means that a reset will cause all queued data to be lost, whereas it would bepossible only to delete data for which a partial M-bit sequence has beentransmitted.

Issue 13 Category Major Section 1.4.2.1

Description Separate requests to transmit data from partially sent M-bit sequences.

4.2.4 Note 1 in TM1.4.2.2.2 is not sufficient. A station in coverage of two or more aircraftwith the same address will not be able to use DLS services with any of theseaircraft. It is not an end-system issue. The DLS protocols will be unstable if morethan one aircraft responds in a reserved slot. The DLS user should be informedthat the requested station is not available.

Issue 14 Category Minor Section 1.4.2.2.2

Description Expand Note 1 to make it clear that the DLS will not work for aircraft withidentical addresses.

Issue 15 Category Major Section 1.4.2.2.2

Description The DLS should inform the DLS User when requests for unavailableaircraft are made, including those with non-unique addresses.

4.2.5 A DLS Burst consists of (TM1.4.2.3.1):

§ Burst id (fixed) (including one reserved bit).

§ One or two DLPDUs

4.2.6 The limit of two DLPDUs means that it is not possible to link DLPDUs containingan SZOM.

4.2.7 Assumption 7: It is not possible to link DLPDUs containing an SZOM.

4.2.8 The following DATA DLPDUs (data link protocol data units) are defined:

§ CTRL – Used by the LME to establish and maintain links for NSCOPcommunication.

§ INFO – Contains a user data field.

§ UDATA – Enables the broadcast of user data and shall be unacknowledged.



4.2.9 The following RTS frames are defined:

§ CTRL_RTS – Sent when there is no current connection established and theCTRL message is to be sent using long transmission procedures.

§ INFO_RTS – A request to send (for long transmission procedures)

§ UDATA_RTS – This frame is broadcast

4.2.10 The following ACK, CTS and other DLS link control frames are defined:

§ UDATA_CTS – This frame is a clear to send in response to a UDATA_RTS.

§ INFO_ACK – An acknowledgment of the previous INFO frame

§ INFO_CTS – A clear to send (for long transmission procedures)

§ CTRL_ACK – An acknowledgment of the previous CTRL frame

§ FRMR_ACK – Sent to acknowledge receipt of FRMR

§ FRMR – Used to reset the link.

§ DM/DISC (Disconnected Mode) – Used to indicate that a DLS frame has beenreceived when no link has been initialised.

§ SZOM – sent in combination with an INFO, INFO_RTS or INFO_ACK toestablish a link for ZOCOP communication.

4.2.11 The following table summarises the contents of these packets:

Toggle Bit(T)

More Bit(M)

Priority(p)

Negotiation subfield(neg)

IB Length(lg)

CTRL ü ü ü

INFO ü ü ü

UDATA

CTRL_RTS ü ü ü ü

INFO_RTS ü ü ü

UDATA_RTS ü ü

UDATA_CTS

INFO_ACK ü

CTRL_ACK ü ü

CTRL_CTS ü ü

FRMR_ACK

FRMR

DM/DISC

SZOM ü

Table 3 DLPDU Contents



Where:

§ Toggle Bit (T): see section 3.4.4.4.

§ More Bit (M): This is set to zero to indicate end of message. It is set to 1 toindicate that it is part of a segmented message and there are more segmentsto follow.

§ Priority (p): see section 3.4.4.1.

§ Negotiation subfield (neg): This will indicate the link management parametersto be used for air/air link control.

§ Initialise bit (IB): This bit shall cause the receiver to initialise the Tt and Tr statevariables and to clear the send and receive arrays whilst processing the frame.It is set to zero and ignored on receipt unless otherwise stated.

§ Length (lg): This is the length of the data in slots.

4.2.12 The following issues arise from inspection of section 1.4.2:

§ The UDATA DLPDU needs to contain the priority sub-field for instances whenthe UDATA is sent using the short transmission procedure.

§ Given that the lg field has only 5 bits, the maximum number of slots that can bereserved is therefore 32 (assuming lg is length minus 1). This is insufficient forcoding the required range indicated by parameter ND2.

§ In the TM, Table 1-57 contains single bit fields C/R and P/F in the definition ofthe CTRL DLPDU. These fields are not in the subsequent sections.


Description The UDATA DLPDU needs to contain the priority sub-field for instanceswhen the UDATA is sent using the short transmission procedure.


Description The lg sub-field has insufficient bits to code the full range (1 to 75 slots)indicated by ND3.


Description The C/R and P/F fields are not defined

4.3 DLS System Parameters (TM 1.4.3)

Issue 19 Category Minor Section 1.4.3

Description Final clause of second sentence gives the impression that the exchangeof CTRL DLPDUs is not required if default values are to be used.

4.3.1 The following timers are used in the DLS procedures:

§ TD1: ZOCOP link transmit timer. This timer is reset when a frame is sent to thepeer. If it expires, then Tt shall be set to 0 and the send channel array cleared.

§ TD2: ZOCOP link receive reset timer. This timer is reset when a frame isreceived from the peer. If this timer expires then Tt shall be set to 0, the sendchannel array cleared and the link shall be considered to be cleared.



4.3.2 Note: Expiry of TD1 or TD2 does not cause a reset. The link is merely consideredto be dormant. The arrays should clearly already be empty.

4.3.3 The following counters are used in the DLS Procedures:

§ ND1: Maximum number of octets that may be submitted to the DLS fortransfer.

§ ND2: Maximum length of a DLS transmission that may use the shorttransmission procedures.

§ ND3: Maximum length of a segment with M-bit processing.

4.3.4 The maximum value of ND2 (16384) should not be larger than the maximum valueof ND1 (2063)

4.3.5 In order to ensure that M-bit processing is not applied to the short transmissionprocedure (see TM1.4.4.5) a note should be included that ND3 and ND2 valuesshould only be selected such that ND3 represents more octets than ND2.


Description The maximum value of ND2 (16384) should not be larger than themaximum value of ND1 (2063)


Description A note should be included that ND3 and ND2 values should only beselected such that ND3 represents more octets than ND2.

4.3.6 TM1.4.3.3 infers that a station receiving a data packet greater in length than ND1shall reset the link. This seems appropriate if the data packet is an M-bit sequencefrom a peer station, but does not seem appropriate if the data packet is from theDLS user. It is recommended that the interface protocol reject the packet.


Description The DLS should reject packets from the DLS user greater in length thanND1 octets.

4.4 DLS Procedures (TM 1.4.4)

4.4.1 Modes of Operation (TM1.4.4.1)

4.4.1.1 TM1.4.4.1 indicates that DLS shall operate in asynchronous balanced mode(ABM) at all times.

4.4.1.2 It is assumed that ABM refers to HDLC. Given that the no other mode of operationis defined, the validation team is not sure why this statement is made.

4.4.1.3 The note indicates that both stations are considered peers with respect to linkmanagement. Whilst this is clearly the case for air-air communications, thevalidation team are not convinced it is true for air-ground communications, wherethe ground station could take additional responsibility.




Description ABM has no definition within the DLS. Remove statement.


Description Consider if aircraft and ground are truly peers with regard to linkmanagement.

4.4.2 Broadcast (TM1.4.4.2)

4.4.2.1 It is understood that Broadcast and Multi-cast data is included in the DLS as asuitable mechanism for broadcast of a single user data packet (as opposed toperiodic broadcast) is not provided in the broadcast protocols.

4.4.2.2 It is understood that UDATA can be transferred using both the short and longtransmission procedures. The validation team had come to the conclusion thatUDATA could not be sent using the short procedure.


Description It should be made clear if UDATA can only be sent using M-bitprocessing. If not, the greatest length for the UDATA data field needs tobe specified.

4.4.2.3 Assumption 8: UDATA cannot be subjected to M-bit processing.

4.4.2.4 Whilst the Validation team accept this position, it should be noted that a clearerdistinction between point-to-point and broadcast protocols would be preferable.

4.4.2.5 Recommendation 1: Consider separation of Point-to-point and broadcastfunctionality.

4.4.2.6 It is understood that the intention of TM1.4.4.2 is to prevent the broadcast ofUDATA_RTS and UDATA_CTS (and the subsequent multiple reservations thatwould incur.

4.4.2.7 It is understood that the intention is that the UDATA_RTS is directed at a particularstation, which would reply with a directed UDATA_CTS reserving slots for theUDATA which is broadcast.

4.4.2.8 TM1.4.4.2 does not make this intention sufficiently clear. A note describing theintent should be included. Consideration should also be given to including a noteon how the aircraft to receive a UDATA_RTS is selected. Is it sufficient to link theUDATA_RTS with any frame directed at a station within the broadcast/multi-castaddress space, or should it be directed at a geographically suitable aircraft?


Description Insufficient information is presented to understand intent of directedUDATA_RTS and UDATA_CTS.



4.4.3 Setting of retransmission parameters (TM1.4.4.3)

4.4.3.1 It is understood that if a response is not received in the reserved slot then the re-transmission procedures (TM1.3.21) shall be invoked by the VSS. This implies thatan indication from the VSS that a reserved reply has not been received shouldperhaps be handled more severely than current, for example informing DLS Userthat the packet is undeliverable rather than resending the packet with thereservation.

4.4.3.2 A complete view on this cannot be taken as the key parameter (Q5num) is listedas TBD.

4.4.3.3 Assumption 9: The VSS is responsible for retransmission. The DLS does notretransmit.


Description Table contains TBD

4.4.4 Selection of User Data Packet for Transmission (TM1.4.4.4)

4.4.4.1 User Data Packet Priority (TM1.4.4.4.1)

4.4.4.1.1 TM1.4.4.4.1 does not reflect the send array defined in TM1.4.2.1.

4.4.4.1.2 The concept of priority should only be applied to DATA DLPDUs (and byassociation the related _RTS, _CTS, _ACK).

4.4.4.1.3 CTRL has a default priority of 15. INFO and UDATA have assigned prioritiessupplied by the DLS User (see 3.2.11).

4.4.4.1.4 SZOM, FRMR and DM/DISC do not require a priority. They are all transmitted aspart of a procedure initiated by the transmission/reception of a data packet. Theywould be transmitted before the next data packet could be selected.


Description Section should be re-worded to reflect the send arrays described inTM1.4.2.1


Description SZOM, FRMR and DM/DISC do not have a priority, they are sent as partof a procedure associated with a data packet.

4.4.4.2 User Data Fragmentation (TM1.4.4.4.2)

4.4.4.3 Message Segmentation and Concatenation

4.4.4.3.1 If the length of the burst is longer than ND3 slots the sending station shall segmentthe message.

4.4.4.3.2 For Single Segment Messages:

§ M bit is zero

§ For an INFO frame the pr bits shall indicate the priority of the frame



4.4.4.3.3 For Multiple Segment Messages:

§ The M bit is set to 1 except the last segment, which is set to zero

§ For INFO frames the pr bits shall indicate the priority of the frame

4.4.4.3.4 No strategy is suggested for fragmentation. For example should all segments withM=1 contain ND3 octets? Or should an M-bit sequence contain equal lengthsegments? It is noted that TM1.4.4.5 states that M-bit is always zero for a shorttransmission. From this it is inferred that the required strategy is to send segmentof ND3 octets with M=1.


Description Add note describing segmentation strategy.

4.4.4.4 Setting of T-bit (TM1.4.4.4.3)

Initialising T bit for NSCOP communication

4.4.4.4.1 If there is no connection between the mobile and ground station and the LMErequests the transmission of a CTRL message. The sending station shall sendeither a CTRL frame (short transmission procedures) or a CTRL_RTS frame (longtransmission procedures).

4.4.4.4.2 The setting of T bits and the state variables Tr and Tt is summarised below:

1If T=0 and IB=1 Tt is set

0Tt set to 0 when sending CTRL frame

TrTtdetails


0Tt set to 0 when sending CTRL frame

TrTtdetails

0

IB = 1 ∴ Receive arrays cleared and Tr set

0

detailsTrTt

0


0

detailsTrTtCTRL, T=0, IB=1

CTRL_ACK , T=0, IB=1

Figure 4-2: Initialisation of T bit for NSCOP communication (short transmissionprocedures)


0∴ set T= Tt

0T = Tt

0Tt is set to 0 when sending CTRL_RTS frame

TrTtdetails


0∴ set T= Tt

0T = Tt

0Tt is set to 0 when sending CTRL_RTS frame

TrTtdetails

0


0

T is set to previous value of T

T ≠ Tr ∴ send CTS

detailsTrTt

0


0



detailsTrTtCTRL_RTS , T=0, IB=1

CTRL_CTS , T=0, IB=1

CTRL, T=0, IB=1

CTRL_ACK , T=0, IB=1

Figure 4-3: Initialisation of T bit for NSCOP communication (long transmissionprocedures)

4.4.4.4.3 Response to a DLS User data request for a station for which the LME has notrequested a connection is undefined.


Description Specify action when DLS user requests transfer to ground station withoutan active connection.



Initialisation of T bit for ZOCOP communication

4.4.4.4.4 A mobile station wishing to send data to another mobile station with which it doesnot have a link should send a DLS burst containing a SZOM frame and either anINFO frame (short transmission procedures) or an INFO_RTS frame (longtransmission procedures).

1If T ≠ Tt, Tt is set

0∴ set T= Tt

0T = Tt

0Tt is set to 0 when sending a SZOM frame neg = highest value

TrTtdetails

1If T ≠ Tt, Tt is set

0∴ set T= Tt

0T = Tt

0Tt is set to 0 when sending a SZOM frame neg = highest value

TrTtdetails

neg = highest value0

Tr set 0



detailsTrTt

neg = highest value0

Tr set 0



detailsTrTtSZOM/ INFO_RTS , T=0

SZOM/ INFO_CTS , T=0

SZOM/ INFO, T=0

SZOM/ INFO_ACK , T=0

Figure 4-4: Initialisation of T bit for ZOCOP communication (long transmissionprocedures)

4.4.4.4.5 For all transmissions after initialisation the Toggle bit shall be alternate between 1and 0 on each successive ‘data’ transmission, except for retransmissions. Theassociate RTS, CTS and ACK should have the same value T bit as the datapacket.

4.4.5 Selection of Transmission Procedures (TM1.4.4.5)

4.4.5.1 There are two types of DLS procedures, short and long. After receiving the burstthe sending station calculates the total length of the transmission. If the total lengthis less than or equal to ND2, then the station shall use the short transmissionprocedure, otherwise, the station will use the long transmission procedure.

4.4.5.2 The clarity of the English used in TM1.4.4.5 is not adequate, in particular the endof the first sentence is confusing. It is assumed to be an editorial error that itexists.


Description Tidy English

4.4.5.3 It should be made clear that the only combined frame that can be sent using shorttransmission procedures is the ACK/DATA frame.


Description It should be made clear that the only combined frame that can be sentusing short transmission procedures is the ACK/DATA frame.

4.4.6 Short transmission procedure (TM1.4.4.6)

4.4.6.1 The short transmission procedure is used for transmission requiring less than ND2octets. For a short transmission, a burst containing the DATA DLPDU and aUnicast Request Reservation for ACK is transmitted using the Random Accessprotocol.

4.4.6.2 (The Unicast Request Reservation is not included for UDATA DLPDUs.)



4.4.6.3 Transmission of Data frame:

§ The link type shall be set to INFO, CTRL or UDATA

§ M bit shall be set to 0 (not applicable to UDATA)

§ The T bit shall be set to Tt (not applicable to UDATA)

4.4.6.4 Transmission of ACK frame:

§ The link type shall be set to INFO_ACK or CTRL_ACK depending on the framereceived.

§ The T bit shall be set to the value of the T bit in the received DATA frame

§ UDATA shall be unacknowledged.

4.4.6.5 Error Processing:

§ If the receiver is unable to provide an ACK in the required slot, it may send ageneral failure and a unicast reservation (with itself as the transmitter) for alater acknowledgement (TM1.3.20)

§ If the receiver does not provide the ACK in the required slot, the DATA packetis resent (by the VSS) using the retransmission procedures (TM1.3.21)

4.4.6.6 Processing of the t-bit is not described for the short transmission procedure.


Description Processing of the T-bit is not described for the short transmissionprocedure.

4.4.7 Long Transmission Procedures (TM1.4.4.7)

4.4.7.1 Transmission of request to send (TM1.4.4.7.1)

4.4.7.1 The long transmission procedure is used to send user data packets greater inlength than ND2 octets.

4.4.7.2 The RTS is much shorter than the Data transmission so it is quicker to find anavailable slot for sending this by random access, the RTS reserves a slot for theCTS. The CTS then reserves the slots for the DATA and an ACK.

4.4.7.3 Transmission of RTS

§ The link type shall be set to INFO_RTS, CTRL_RTS, or UDATA_RTS

§ The length subfield shall indicate the length of the DLS burst required tocontain the DATA DLPDU

§ The pr bits shall be set to the DATA frame to be sent

§ The T bit shall be set to Tt (not included in a UDATA_RTS)

§ The transmission shall reserve a slot for the CTS using a Unicast RequestReservation.



4.4.7.2 No response to RTS (TM1.4.4.7.2)

4.4.7.2.1 If a response is not received to the RTS, it is retransmitted in accordance with theretransmission procedures. This is a VSS issue. TM1.4.4.7.2 should indicate theaction required if the retransmission procedures also fail.


Description Define action if retransmission procedure fails.

4.4.7.3 Response to RTS (TM1.4.4.7.3)

4.4.7.3.1 When an RTS is received, the T-bit value is inspected. If the T-bit is not equal to Trthen it is a new request and a CTS is transmitted:

§ The link type shall be set to INFO_CTS, CTRL_CTS or UDATA_CTS

§ The T bit shall be set to the T bit of the RTS frame to which the CTS is aresponse

§ For INFO_CTS and CTRL_CTS this transmission shall also reserve slots forthe expected DATA transmission and an ACK (Information Transfer Request).

§ For UDATA_CTS this transmission shall also reserve slots for the expectedDATA transmission (Unicast Request Reservation).

4.4.7.3.2 If T-bit is equal to Tr then it is a duplicate of the previous packet (possibly sentbecause the sender did not receive the ACK). In this case an ACK is sent in theslot reserved for CTS.

Issue 36 Category Editorial Section 1.4.4.7.3

Description Final sentence should be … .ACK DLPDU shall not contain… .

4.4.7.3.3 If the channel is too busy to service the request (eg a sufficiently large series ofcontiguous slots can not be found) then the reservation for the CTS shall be usedto send:

§ General confirm including a Unicast Reservation Request (sdf =1) for a futureCTS

§ General failure with error type 01 hex (in which case the sender can retransmitthe RTS).

4.4.7.4 Response to CTS (TM1.4.4.7.4)

4.4.7.4.1 When a CTS is received, the T-bit value is inspected. If the T-bit is equal to Tt thenthe DATA DLPDU is sent. If the T-bit is not equal to Tt then the reset procedure isapplied.

4.4.7.4.2 If the data associated with the CTS has been deleted (due to a reset) then notransmission is made.

4.4.7.5 Acknowledging the DATA (TM1.4.4.7.5)

4.4.7.1 If a valid DATA DLPDU is received an ACK is sent in the reserved slot. The t-bit isset to Tr.



Issue 37 Category Editorial Section 1.4.4.7.5.1


4.4.7.2 If a valid DATA DLPDU is not received a NACK is sent in the reserved slot. The t-bit is set to the inverse of Tr.



4.4.8 DLS not supported (TM1.4.4.8)

4.4.8.1 It is not clear why UDATA_RTS is not included in the list of packets for which ageneral failure response is issued if the DLS is not supported.


Description Exclusion of UDATA_RTS from packets which may initiate a DLSprocedure is not understood.

4.4.9 No Link With Sender (TM1.4.4.9)

4.4.9.1 If an active connection is not established when a CTRL or CTRL_RTS with IB notequal to 1 or an INFO DLPDU which is not combined with a SZOM DLPDU isreceived then an DM/DISC DLPDU is sent in the reserved slot.

4.4.9.2 Action is not defined for a CTRL_CTS and CTRL_ACK. This combination shouldnot occur, except in error.

4.4.9.3 It is not clear if TM1.4.4.9 means INFO, INFO_RTS, INFO_CTS and INFO_ACK orjust INFO.

4.4.9.4 Assumption 10: SZOM is combined with INFO, INFO_RTS, INFO_CTS andINFO_ACK during connection establishment.


Description It is not clear if this means INFO, INFO_RTS, INFO_CTS and INFO_ACKor just INFO.

4.4.9.5 Action on receipt of CTRL or CTRL_RTS DLPDU with IB equal to 1 or an INFODLPDU combined with an SZOM DLPDU when a link is established is not defined.


Description Action on receipt of CTRL or CTRL_RTS DLPDU with IB equal to 1 or anINFO DLPDU combined with an SZOM DLPDU when a link is establishedis not defined.



4.4.10 User data packet reception (TM1.4.4.10)

4.4.10.1 Receipt of DATA DLPDUs (TM1.4.4.10.1)

4.4.10.1.1 The receipt of a UDATA DLPDU is not covered by this section.


Description Receipt of UDATA should be covered by this section.

4.4.10.2 Concatenation (TM1.4.4.10.2)

4.4.10.2.1 If any preceding message segments have been received with, in the case of anINFO frame, the same value pr bits and the M bit set to one then the user datapart of the DATA frame shall be concatenated to the end of the messagesegments.

4.4.10.2.2 If the M bit is set to zero then the user data part of the DATA frame along with anyother message segments received earlier shall be passed to the user as a singlemessage.

4.4.11 Receipt of ACK DLPDU (TM1.4.4.11)

4.4.11.1 The t-bit of a received ACK is compared with the Tt variable. If the t-bit has thecorrect value, the DATA packet is accepted. If the t-bit has the wrong value, theDATA packet is resent. This is because an incorrect t-bit is assumed to be aNACK (TM1.4.4.7.5.2).

4.4.11.2 It is not clear if this use of the t-bit violates the claim in TM1.4.1.2 that ‘duplicatedDATA DLPDUs are discarded and all DATA DLPDUs are delivered in sequence’.

4.4.12 Link Reset (TM1.4.4.12)

4.4.12.1 When the DLS requires to reset the link, an FRMR is sent in a pre-reserved slotalong with a reservation for the FRMR_ACK. The DLS shall not initiate a newtransmission until a FRMR_ACK has been received. Both transmit and receivearrays are cleared.

4.4.12.2 The link will be reset if:

§ Cause 1: A data packet is received with a total length exceeding ND1. This canoccur when:

- a common value of ND1 has not been agreed, or

- the final packet in an M-bit sequence is not received and a new M-bitsequence is appended to the start of the previous sequence.

§ Cause 2: A CTRL_CTS or INFO_CTS DLPDU is received for which the T bit isnot equal to Tt.. This can occur only when the intended recipient of the data hascorrupted the T bit settings.

4.4.12.3 The station initiating a reset clears both Transmit and Receive Arrays.

4.4.12.4 The station receiving a reset clears only the receive array (eg discards incompleteM-bit sequences).



4.4.12.5 If the reset is due to cause 1, it is not clear why the transmit arrays are cleared. Itmay be appropriate to clear the connection and re-negotiate the DLS parameters.

4.4.12.6 If the reset is due to cause 2, then the Tt values need to be reinitialised. Again itmay be more appropriate to clear the connection and re-establish in order to resetthe values of Tt and Tr.

4.4.12.7 Recommendation 2: Remove the reset functionality and replace initiation with thesending of a DM/DISC. The receiver of the DM/DISC will need to clear receivearrays and assume that a new connection establishment phase is required.

4.4.13 Linking DLS DLPDU Transmissions (TM1.4.4.13)

4.4.13.1 Types of linking (TM1.4.4.13.1)

4.4.1 The DLS allows for the combination of DLPDUs to support:

§ Chaining sequences of DATA packets being transmitted using:

§ RTS/DATA

§ ACK/CTS

§ Piggy-backing transmissions on to reception acknowledgement using:

§ ACK/DATA (if data fits into single slot)

§ ACK/RTS (if data does not fit into a single slot)

4.4.2 The rationale for allowing combined DLPDUs is that they enable newtransmissions to be made using reserved slots rather than the random accessprotocol which is likely to have a significant advantage concerning transfer delay.

4.4.3 Other combinations of DLPDUs are excluded. This clearly does not include thecombination of a SZOM with INFO, INFO_RTS, INFO_CTS and INFO_ACK.


Description Add note that combination of SZOM with INFO DLPDUs is not excluded.

4.4.4 TM1.4.4.13.1 also states the ‘The DLPDUs above shall only be transmitted in theorder listed’. The intent of this statement is not understood. An ACK/RTS does notfollow an ACK/DATA. If the intent is to fix the order of the DLPDUs in a burst – thisis not clear.


Description Resolve intent of ‘The DLPDUs above shall only be transmitted in theorder listed’

4.4.13.2 Combined RTS/DATA (TM1.4.4.13.2)

4.4.13.2.1 A combined RTS/DATA DLPDU is used to combine a series of user data packets.A RTS is included with the DATA DLPDU and the slot reserved for the ACK isused for a ACK/CTS (see next section).



4.4.13.2.2 TM1.4.4.13.2 states that the DATA DLPDU in transmission should be a long. It isnot understood why the Unicast Request Reservation in the DATA DLPDU in theshort procedure could not be used for a combined RTS/DATA.


Description Clarify why the Unicast Request Reservation in the DATA DLPDU in theshort procedure could not be used for a combined RTS/DATA.

4.4.13.3 Combined ACK/CTS DLPDUs (TM1.4.4.13.3)

4.4.13.3.1 A combined ACK/CTS is sent in response to a combined RTS/DATA if sufficientresources exist for the subsequent DATA DLPDU transfer.

4.4.13.3.2 It is assumed, but not stated that an ACK is sent if sufficient resources do notexist.


Description State that An ACK is sent in response to a RTS/DATA if sufficientresources do not exist for the DATA requested by the RTS.

4.4.13.3.3 An ACK/INFO_CTS or ACK/CTRL_CTS is sent with an Information TransferRequest which reserves the DATA and subsequent ACK.

4.4.13.3.4 ACK/UDATA_CTS is sent with a Unicast Request reservation which reservesUDATA.

4.4.13.4 Combined ACK/DATA DLPDUs (TM1.4.4.13.4)

4.4.13.4.1 A combined ACK/DATA DLPDU is used to initiate a short transmission procedurewhich fits in to a single slot on the back of a previously reserved ACK.

4.4.13.5 Combined ACK/RTS DLPDUs (TM1.4.4.13.5)

4.4.13.5.1 A combined ACK/RTS DLPDU is used to initiate a long transmission procedure onthe back of a previously reserved ACK.

4.4.13.5.2 It is not clear if the next packet to be sent would use a short transmissionprocedure or if the combined long procedure should be used instead.


Description Clarify if the next packet to be sent would use a short transmissionprocedure or if the combined long procedure should be used instead.

4.4.13.6 Combined ACK/RTS DLPDUs to different peers (TM1.4.4.13.6)

4.4.13.6.1 A station wanting to send data to a station may include a Unicast RequestReservation with an ACK (directed to any station) with sdf = 1 and use thesubsequent reservation for sending an RTS to the new destination.

4.4.13.6.2 Hence, whenever a station sends an ACK, it needs to determine if any data packetis waiting for transmission.



4.4.13.6.3 It is not clear if a packet that would normally be sent using the short procedurewould be sent using this method.


Description Clarify if a packet that would normally be sent using the short procedurewould be sent using this method.

4.4.14 CTRL DLPDU (TM1.4.4.14)

4.4.14.1 CTRL DLPDU is used to establish and maintain link.

4.4.14.2 Assumption 11: CTRL DLPDUs are not only used during connectionestablishment.

4.4.15 Procedures for Air-Air Data Exchange (TM1.4.4.15)

4.4.15.1 TM1.4.4.15.2 states that the link is regarded as terminated if both TD1 and TD2expire.

4.4.15.2 The descriptions of TD1 and TD2 clear resources for transmit and receiverespectively, but indicate that the link is considered to be clear.

4.4.15.3 Is it possible to reset only the transmit (or receive side) but not the other?


Description Clarify if the intent is to allow the reset of the transmit (or receive side) butnot the other.



5 Conclusions and Recommendations

5.1 Assumptions

5.1.1 The following assumptions have been made by the validation team in order tofacilitate the completion of the validation task. If any of these assumptions are nottrue, then further issues would need to be raised.

Number Assumption Reference

1 The DLS user is not responsible for establishing connections 4.1.5

2 The DLS user cannot reset the connection. 4.1.5

3 The DLS user is not informed of the success of a data transferrequest.

4.1.5

4 The order of data delivery is only important for data requests atthe same priority and in particular within M-bit sequences.

4.1.8

5 The MAC layer is responsible for error detection 4.1.10

6 The VSS is responsible for accepting DLPDUs according toaddress.

4.1.12

7 It is not possible to link DLPDUs containing a SZOM. 4.2.8

8 UDATA cannot be subjected to M-bit processing. 4.4.2.3

9 The VSS is responsible for retransmission. The DLS does notretransmit.

4.4.3.3

10 SZOM is combined with INFO, INFO_RTS, INFO_CTS andINFO_ACK during connection establishment.

4.4.9.4

11 CTRL DLPDUs are not only used during connectionestablishment.

4.4.14.2

5.2 Recommendations

5.2.1 The validation team has raised the following recommendations. They aresuggestions for the simplification of the DLS, which the validation team believewould support the readability of the standard. They do not impact on the suitabilityof the standard.

Number Recommendation Reference

1 Consider separation of Point-to-point and broadcastfunctionality.

4.4.2.5

2 Remove the reset functionality and replace initiation with thesending of a DM/DISC. The receiver of the DM/DISC will needto clear receive arrays and assume that a new connectionestablishment phase is required.

4.4.12.7

5.3 Issues

5.3.1 49 issues have been raised. 25 have been classified as major, 12 as minor and 12as editorial. Section 6 contains a summary of issues raised during the validation.



5.4 Further Analysis

5.4.1 The next stage in the validation process is the development of a simulation of theDLS. This simulation will be used to investigate:

§ SZOM exchange when both stations start to transmit before one completes.

§ Re-establishing t-bit settings after a reset.

§ Parameter values

§ The use of T-bit as a NACK.

§ Combined DLPDUs

5.5 Conclusion

5.5.1 The current document represents the output of the inspection and analysis stagesof the validation activity. The next stage is the use of simulation to resolveremaining concerns.

5.5.2 At this stage a number of issues exist which would prevent the successfuladoption of the proposed standard by the aviation community. In particular theValidation Team would like to see clearer distinction of responsibility between theDLS, the VSS and the DLS User.

5.5.3 None of the issues are show stoppers. The DLS is now reaching maturity.

5.5.4 The Development team are invited:

§ to review this document;

§ to inform the Validation team if any of the assumptions are incorrect;

§ to consider the recommendations

§ to respond to all issues raised.

5.5.5 The Validation team will update Annex A with comments received, recommendresolutions and close issues as this becomes appropriate.



6 Acronyms

A/A Air/Air

A/G Air/Ground

ACK Acknowledgement

CTRL Control

DLPDU Data Link Protocol Data Unit

DLS Data Link Service

INFO Information

LME Link Management Entity

MAC Media Access Control

NSCOP Negotiated Set-up Connection Orientated Protocol

RTS Request to Send

SZOM Start Zero Overhead Mode

TM Technical Manual

UDATA Unacknowledged Data

VDL VHF Data Link

VSS VDL Mode 4 Specific Services

ZOCOP Zero Overhead Connection Orientated Protocol



A Summary of Issues


Description It is not clear from the descriptions that VSS is responsible for re-transmissions. The text should be clearer.

Response

Resolution Status Open


Description The VSS does not inform the DLS if a retransmission procedure fails.This leads to the failure of the protocol.

Response



Description Action on receipt of a DM/DISC is not defined.

Response



Description It is not clear if an air-ground connection should be deemed establishedfollowing the completion of the CTRL exchange or on notification by theLME.

Response



Description No stimuli exists for disconnecting an air-ground connection.

Response


Issue 6 Category Major Section 1.4

Description Insufficient detail is included on the interfaces to the DLS.

Response



Description Clarify that LME data not User Data is transferred in CTRL DLPDUs.

Response



Description Clarify statement on delivery sequence of data packets.

Response





Description Clarify statement on the DLS being responsible for error correction ratherthan the MAC layer.

Response


Issue 10 Category Editorial Section 1.4.1.4 / 5

Description Clarify statement on the DLS being responsible for accepting DLPDUs onaddress criteria rather than the VSS.

Response



Description Change ‘State variables’ to ‘Resources’

Response



Description Describe number of station pairs for which resources should bemaintained.

Response



Description Separate requests to transmit data from partially sent M-bit sequences.

Response



Description Expand Note 1 to make it clear that the DLS will not work for aircraft withidentical addresses.

Response



Description The DLS should inform the DLS User when requests for unavailableaircraft are made, including those with non-unique addresses.

Response



Description The UDATA DLPDU needs to contain the priority sub-field for instanceswhen the UDATA is sent using the short transmission procedure.

Response





Description The lg sub-field has insufficient bits to code the full range (1 to 75 slots)indicated by ND3.

Response



Description The C/R and P/F fields are not defined

Response



Description Final clause of second sentence gives the impression that the exchangeof CTRL DLPDUs is not required if default values are to be used.

Response



Description The maximum value of ND2 (16384) should not be larger than themaximum value of ND1 (2063)

Response



Description A note should be included that ND3 and ND2 values should only beselected such that ND3 represents more octets than ND2.

Response



Description The DLS should reject packets from the DLS user greater in length thanND1 octets.

Response



Description ABM has no definition within the DLS. Remove statement.

Response



Description Consider if aircraft and ground are truly peers with regard to linkmanagement.

Response





Description It should be made clear if UDATA can only be sent using M-bitprocessing. If not, the greatest length for the UDATA data field needs tobe specified.

Response



Description Insufficient information is presented to understand intent of directedUDATA_RTS and UDATA_CTS.

Response



Description Table contains TBD

Response



Description Section should be re-worded to reflect the send arrays described inTM1.4.2.1

Response



Description SZOM, FRMR and DM/DISC do not have a priority, they are sent as partof a procedure associated with a data packet.

Response



Description Add note describing segmentation strategy.

Response



Description Specify action when DLS user requests transfer to ground station withoutan active connection.

Response



Description Tidy English

Response





Description It should be made clear that the only combined frame that can be sentusing short transmission procedures is the ACK/DATA frame.

Response



Description Processing of the T-bit is not described for the short transmissionprocedure.

Response



Description Define action if retransmission procedure fails.

Response


Issue 36 Category Editorial Section 1.4.4.6.3.2i


Response




Response




Response



Description Exclusion of UDATA_RTS from packets which may initiate a DLSprocedure is not understood.

Response



Description It is not clear if this means INFO, INFO_RTS, INFO_CTS and INFO_ACKor just INFO.

Response





Description Action on receipt of CTRL or CTRL_RTS DLPDU with IB equal to 1 or anINFO DLPDU combined with an SZOM DLPDU when a link is establishedis not defined.

Response



Description Receipt of UDATA should be covered by this section.

Response



Description Add note that combination of SZOM with INFO DLPDUs is not excluded.

Response



Description Resolve intent of ‘The DLPDUs above shall only be transmitted in theorder listed’

Response



Description Clarify why the Unicast Request Reservation in the DATA DLPDU in theshort procedure could not be used for a combined RTS/DATA.

Response



Description State that An ACK is sent in response to a RTS/DATA if sufficientresources do not exist for the DATA requested by the RTS.

Response



Description Clarify if the next packet to be sent would use a short transmissionprocedure or if the combined long procedure should be used instead.

Response



Description Clarify if a packet that would normally be sent using the short procedurewould be sent using this method.

Response





Description Clarify if the intent is to allow the reset of the transmit (or receive side) butnot the other.

Response


Date post:	15-Jul-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

DLS AP Validation Report v10Length (lg) – 8 bits Frequency (f) – 11 bits 2.4.3.2 If default...

Documents