Dear Dale Worley, Thank you for your comments. Inline you will find replies to the raised issues and we are planning to incorporate related updates in the next version. Best, Nils Mäurer -----Ursprüngliche Nachricht----- Von: Dale Worley via Datatracker <noreply@xxxxxxxx> Gesendet: Freitag, 1. April 2022 04:51 An: gen-art@xxxxxxxx Cc: draft-ietf-raw-ldacs.all@xxxxxxxx; last-call@xxxxxxxx; raw@xxxxxxxx Betreff: Genart last call review of draft-ietf-raw-ldacs-10 Reviewer: Dale Worley Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-raw-ldacs-10 Reviewer: Dale R. Worley Review Date: 2022-03-31 IETF LC End Date: 2022-04-04 IESG Telechat date: not known Summary: This draft is basically ready for publication, but it seems to me to have open issues, depending on the intended scope of the document. Issues: There are a number of minor editorial issues listed below. But the one issue that might be significant is the lack of detail about how LDACS is expected to utilize the IP infrastructure as defined by the IETF. Strictly speaking, this document is an informational document about a particular data-link layer, and in that sense, layer 3 is out of scope, but what the IETF audience would be most informed by would be how the data-link layer integrates with IPv6 and existing IPv6 protocols. - Reply: LDACS is a terrestrial access network technology for the upcoming Air Traffic Network/Internet Protocol Suite (ATN/IPS), which is a network technology that will route any Air Traffic Management (ATM) related information over IP. As such any access technology for the ATN/IPS operates directly with IP infrastructure and is in our opinion of strong interest to the IETF. LDASC offers an interface, the SNP, which will use IPv6 traffic as input, and adapt the input to LDACS specific packet format, and vice versa. 3. Motivation and Use Cases It refers to the mostly proprietary exchange of data between the aircraft of the airline, its operation centers, and its service partners. Not being in the airline industry, my initial reading of this was that aircraft had operation centers and service partners. Perhaps this could be clarified for the naive as It refers to the mostly proprietary exchange of data between the aircraft of the airline and the airline's operation centers and service partners. - Reply: Indeed, an aircraft does not have direct operation centers and service partners. The airline does. As such, we will use your suggestion as replacement. 3.1. Voice Communications Today Voice links are used for Air/Ground (A/G) and Air/Air (A/A) communications. The communications equipment is either ground-based working in the High Frequency (HF) or VHF frequency band or satellite-based. By comparison, 5.2.2 states that A/A communication is only considered as a possible extension for LDACS, which seemed surprising to read at that point. This could be clarified if 3.1 noted that LDACS is not currently planned to implement A/A communication, even for voice. - Reply: It is foreseen that LDACS A/A will be implemented after the LDACS A/G rollout. As such, we will clarify this point in the document. 5.2. Application (sending Ground Based Augmentation System (GBAS) correction data) Naively, this reads as "data to correct GBAS data". Perhaps clearer as "Ground Based Augmentation System (GBAS) data to correct GNSS" or even just "GNSS correction data" as is used in 5.2.3. - Reply: We will change it to "GNSS correction data". 7. Characteristics Achieving the stringent continuity, availability, and integrity requirements defined in [DO350A] will require the specification of layer 3 and above mechanisms (e.g. reliable crossover at the IP layer). Fault management mechanisms are similarly undefined. This limitation seems to be strictly correct, given that this document is only scoped to the data link layer. But it would be useful to the reader to give an outline of how IP interacts with the data link layer. In particular, are the packets sent over the link IPv6 packets (perhaps encoded in some special way)? What is the general IP addressing architecture of the LDACS sub-network (i.e. AS, GS, and AR)? Similarly, what existing protocols (if any) are expected to reach the AS? These latter points are the ones that most directly intersect the IETF's business. - Reply: As mentioned above, the SNP layer of LDACS directly interacts with IPv6 traffic. ATN/IPS packets are encoded in IPv6 and these are routed over LDACS from and to the aircraft. The final IP addressing structure in an LDACS subnet still needs to be defined, however, for aircraft, the addressing is set as follows: ICAO prefix 16bit, Aircraft Type (Operator based) 4 bit, Operator Code 16 bit, Aircraft ID 24bit, Application Type 4bit. The current layout is considered to consist of the five network segments: Air Core Net, Air Management Net, Ground Core Net, Ground Management Net, Ground Net. Any protocols that the ATN/IPS defines as mandatory will reach the aircraft, however we think that listing these here in the LDACS draft is out of its actual scope. We will update the draft with the provided updates above. 7.3. LDACS Protocol Stack The last entity resides within the sub-network layer: the Sub-Network Protocol (SNP). Given the context of this sentence, "the last entity" could refer to either functional block five, or to item (4) in the immediately preceding list (the LME). This would be less ambiguous as "The fifth block ...". - Reply: "The last entity" was supposed to refer to the last functional entity in the LDACS protocol stack, hence the last one, which was not mentioned yet. We will clarify this accordingly. The LDACS network is externally connected to voice units, radio control units, and the ATN network layer. How does this mesh with the architecture shown in Figure 1 of 7.1, which shows only the connection of LDACS to ATN? - Reply: We agree, that this sentence is poorly formulated. Figure 1 depicts the user-data (or payload) view, hence user-data travels from ATN over ATN/IPS to the A/G router, to the AR and then to the GS, is sent via LDACS to the AS, and then further used as ATN/IPS traffic (the reverse direction applies similarly in reverse order). As such, the control plane for voice or radio units is simply not depicted in Figure 1. We will streamline this to give the reader a better understanding to what we are referring to. -- Figure 2 doesn't show the positioning of the VI functional block. - Reply: That is true. We will update it accordingly. 8.2. Layer 1 and 2 The figures in this section have very little information for a diagram of a frame structure. E.g. the length of an SF is specified (240ms = 2000 symbols), but the lengths of MF, BCCH, and RACH are not specified. Similarly, the lengths of the divisions of the MF aren't specified. The layout and size of the transmission time slots aren't discussed. FL and RL boundaries are aligned in time (from the GS perspective) Given that a cell can be as large as 200 nautical miles, which is 1235 microseconds at light-speed, and a symbol is 120 microseconds, while the FL and RL frame structures are synchronized at the GS, they can be desynchronized by ~20 symbols at the AS. This seems to be handled by propagation guard times but it would be useful to describe the guard time placements in the frame structures. - Reply: We will update the frame structure to incorporate more information and give detailed descriptions of the guard time placements within it. 8.3. Beyond Layer 2 This means proliferating the number of terrestrial ground stations. However, the scarcity of aeronautical spectrum for data link communication (in the case of LDACS: tens of MHz in the L-band) and the long range (in the case of LDACS: up to 200 nautical miles) make this quite hard. Naively, the available bandwidth for the LDACS system as a whole in a geographical region should scale with the number of cells. The above statement suggests that is not true in LDACS, and it would be useful to explain why. - Reply: What we are saying here are three things: 1. aeronautical spectrum for data link communications is very scarce 2. An increase in the amount of ground stations also increases the individual bandwidth for aircraft in the cell, as fewer aircraft have to share that specific spectrum 3. However, to cover worldwide terrestrial ATM via LDACS is also a question of cost and the possible reuse of spectrum which makes it not always possible to shrink cell sizes. We will update this statement to make it more clear. 9.5.1. Entities The document seems to be using "LDACS access network" in 9.5.1 and "LDACS Sub-Network" in Figure 1 of 7.1 to mean the same thing. Neither term is defined in 2. Can these be unified into one term? Would it help to insert it in the glossary? - We will insert it in the glossary and only use one term from here on out. [END] -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
