160 likes | 249 Views
Présented by. Luc Deneufchatel]. ETDMA Study results: Integration of ETDMA sub-network within an ATN/IP network. Sous-titre facultatif de la diapositive. Agenda. 1. End-to-end connectivity VDL/ETDMA architecture Protocols stack model Mobility management Addressing requirements
E N D
Présented by Luc Deneufchatel] ETDMA Study results:Integration of ETDMA sub-network within an ATN/IP network Sous-titre facultatif de la diapositive
Agenda • 1. End-to-end connectivity • VDL/ETDMA architecture • Protocols stack model • Mobility management • Addressing requirements • QoS management • 2. Guaranteed QoS • At ATM services level • At ETDMA network level • End-to-end • In the Internet • 3. Conclusion
End-to-end connectivityObjectives • Definition of protocols stack model for end-to-end connectivity(without using ISO 8208, identification of ETDMA users) • Clarify the role of each protocols stack layer • Describe service primitives • Define addressing requirements • Describe QoS management (“soft” guaranteed QoS)
End-to-end connectivityETDMA architecture ETDMA Sub-Network ETDMA Network Users
End-to-end connectivityData transfer • LREF compression: specific to CLNP and thus provided in Frame Mode SNDCF proper (refer to ATN specifications) • Deflate compression: part of ETDMA network layer and it requires a low probability of re-ordering! Problem: ETDMA Data Link layer provides a high probability of re-ordering (use of ETDMA Classes of Service). Adaptations are thus necessary: • Frame Mode SNDCF proper should handle ETDMA QoS to request appropriate ETDMA QoS before compression • One Deflate compressor should be used for each ETDMA QoS (one channel should be established for each ETDMA QoS) • Deflate function has to be implemented at the link layer level • ETDMA network should transit data using the requested ETDMA QoS • Priorities: priorities should not be used after Deflate compression => priorities should not be used at ETDMA Data Link level
End-to-end connectivityData transfer • Delivery reliability: at Data Link level, ETDMA should implement acknowledgements and a CRC • Service primitives: description of parameters and behaviour (uplink)
End-to-end connectivityHandoff • Handoff between Ground Stations in same cluster has only a minor impact on air and ground: • On ground side, it will be handled by the GNI • On airborne side, the ETDMA radio should recognize that it is still connected to the same ETDMA sub-network, using first part of the address of ground ETDMA users (A/G Routers) advertised using the GSC. • Handoff between Ground Stations in different clusters has more impact on air and ground: • On ground side, it will be handled by the previous GNI (leading to Leave Event) and the next GNI (leading to Join Event) • On airborne side, the ETDMA radio should recognize that it is no longer connected to the same ETDMA sub-network, using first part of the address of ground ETDMA users (A/G Routers) advertised using the GSC. This will lead to Join and Leave Events.
End-to-end connectivityAddressing requirements Ground-based ETDMA User address Mobile ETDMA User address
End-to-end connectivityQoS management • ETDMA Classes of Service • Frame Mode SNDCF proper should have capability to handle ETDMA Classes of Service to request appropriate ETDMA Class of Service • ETDMA link layer should use one Deflate compressor for each ETDMA Class of Service (one logical channel for each ETDMA CoS). • ETDMA Ground Stations and radio should transmit data using the requested ETDMA Class of Service. • Priorities • Priorities should be used before and not after compression i.e. at the level of the Frame Mode SNDCF and not at the level of ETDMA. • Some mechanisms should be implemented to allow the ETDMA network layer to know status of sending queues within lower layers. • Integrity • ETDMA should implement an acknowledged service between an ETDMA Ground Station and an ETDMA radio. A CRC should be used.
Guaranteed QoSObjectives • Investigate the implementation of guaranteed QoS (“hard” guaranteed QoS) at ATM services level using ETDMA capabilities • Methodology: • Analyse the gap between “guaranteed QoS at ATM services level” and “guaranteed QoS at ETDMA network service level” • Review solutions implemented in the Internet to provide a “guaranteed QoS”
Guaranteed QoSAt ATM Services level • Operational requirement for a “hard” guaranteed QoS • Several possible solutions for guaranteed QoS implementation: • Time stamps could be added in messages sent by the ATM service. Main drawback: sending of additional information (time stamps) • Timers could be implemented at ATM services level (current solution with ATN). Main drawback: lack of responsiveness and requires a reply at ATM service level • Network service could support the provision of compulsory and guaranteed QoS. Main drawback: additional mechanisms must be implemented • ATN Classes of Communications should be re-defined as they are not adapted to the implementation of guaranteed QoS to meet operational requirements • Guaranteed QoS applicability: • A flag is required to indicate whether the ATM service requests “best-effort”, “compulsory” or “guaranteed” service • Operational context may need to be considered to set this flag!
Guaranteed QoSAt ETDMA network level • QoS provided in an ETDMA cell from a user viewpoint: • Guarantee of a minimum QoS (maximum transit delay and minimum throughput), which essentially depends on the size of slots, the size of families and ETDMA frame duration. • Actual QoS, which depends on the current traffic load conditions (number of aircraft inserted into the ETDMA cell). • QoS provided in a multi-cells environment: • Minimum QoS (maximum transit delay and minimum throughput) that ETDMA can guarantee to an aircraft is expected to change when moving from one cell to another one. • QoS provided at ETDMA network level: • Integrity using CRC • Priorities before compression (at ETDMA network layer) • QoS parameters in SN-UnitData.Request service primitive: QoS category, ETDMA QoS, Max Transit Delay
Guaranteed QoSEnd-to-end • Main issue is to implement the guarantee of a maximum transit delay: • Need to estimate the maximum one-way ATN mobile sub-network transit delay • Need to estimate the maximum one-way ATN end-to-end transit delay • Need to provide this information to end users • Need to report anomalies
Guaranteed QoSIn the Internet • Initial development to provide a “best-effort” service: not adapted to carry real time traffic that requires a guaranteed transit delay and minimum throughput • Integrated Services (IntServ) model • Differentiated Services (DiffServ) model • None of those models really provide a « guaranteed » QoS • No real benefit to be taken from the IP world and there is a strong need to further investigate the issue and to address the necessary evolutions required at transport layer level