Title: An Application Layer Gateway for Air Traffic Management Communication by Satellite
1An Application Layer Gateway for Air Traffic
Management Communication by Satellite
- Erling Kristiansen
- European Space Agency
- Simone Patella, Massimo Mazzoccanti
- Vitrociset
2ATM traffic profile
- Short messages
- The majority of messages are 20 to a few hundred
bytes - Some longer messages (a few KB)
- Irregular, infrequent message interval
- Inter-message interval seconds to minutes,
depending on flight phase - Many different types of messages, each with its
own pattern
3ATM transport layer issues
- ATM traffic is inelastic
- Traffic is generated by events
- (Time-triggered messages are also considered
events) - ATN TP4 reliable transport was designed for
elastic traffic (by the way, so was TCP) - Speed of transmission is driven by the transport
protocol - Source is capable of slowing down if the
transport tells it to - Reliable transport insists on delivering all
data, and delivering in sequence.
4ATM transport layer issues
- There is a fundamental incompatibility between
inelastic sources and elastic transport - As long as traffic volume is well below network
capacity, and no significant volume of
retransmissions take place, all is well - But if even mild congestion is encountered, all
traffic is delayed. - Significant congestion, even for a short time,
may cause very large delays to all traffic.
Timeouts may expire, causing unnecessary
retransmissions, thus increasing congestion
further.
5ATM transport layer issues
- Congestion control
- ATM traffic to/from any given aircraft is very
thin - Infrequent, mostly short messages
- TP4 and TCP congestion control was designed for
large file transfers - Feed-back from receiver to sender via ACKs and
ACK timing - TP4/TCP congestion control does not work well
with thin, intermittentt raffic - Knowing that there was/wasnt congestion one
minute ago says nothing about now.
6ATM transport layer issues
- In summary 2 problems
- Congestion control is ineffective for the traffic
pattern - Inelastic traffic over an elastic transport
protocol - Two approaches to mitigate this situation were
investigated - Transport relay (PEP)
- Application layer gateway (AGW)
7Transport layer relay
- More commonly known as
- Performance Enhancing Proxy (PEP)
8Transport relay (PEP)
- The PEP is a transport layer proxy
- Breaks the e2e transport into 3 parts
- Ingress network
- Satellite link
- Egress network
- Solves problem 1 the inadequacy of congestion
control for the traffic profile - Does not solve problem 2 The incompatibility
between inelastic traffic and elastic transport.
9Transport relay (PEP)
10The Application Layer Gateway(AGW)
11Congestion will happen
- Unless you have an extremely high
over-provisioning of bandwidth, you have to
assume that - Congestion will happen
- And it will happen when you least want it In an
unusual operational situation such as massive
flight re-routing due to bad weather or an
incident - You can reduce the incidence rate as much as you
can afford by providing more bandwidth, but you
cannot reduce it to zero. - The only thing you can do when congestion happens
is to discard messages. - Randomly or intelligently.
- With e2e reliable transport, there is no way the
network can discard traffic. Only the sending
application can.
12Application gateway (AGW)
- The AGW is an application layer message proxy
- The AGW intercepts messages
- Transports the message to the peer AGW at the
other end of the satellite link - The peer AGW delivers the message to the
destination - The AGW can re-order and discard traffic
selectively
13Application gateway (AGW)
14Application gateway (AGW)
- AGW functionality
- The AGW builds a queue of messages to be sent
over the satellite link - The AGW attempts to build a schedule for
transmission that meets the CoS/QoS requirements
for all messages - If such a schedule cannot be built, congestion is
present - In case of congestion, the AGW will discard
messages according to set rules
15Application gateway (AGW)
- AGW rules may consider such elements as
- Priority
- Time-to-live
- Context
- AGW rules might include such features as
- Try to deliver all within time-to-live (deadline
scheduling), even if it sometimes means low
priority goes before high - High priority before low if both meet deadline
- If a message supersedes another one (e.g. new
position vs. old position), new goes before old
16Application gateway (AGW)
- Solves both problem 1 and 2
- Drawbacks
- AGW needs to know message formats
- Must be updated if new messages are introduced or
formats changed - For some rules, AGW needs to know message context
- Incompatible with end-to-end encryption
- Extra benefits
- May serve as interface between heterogeneous
technologies - E.g. ATN in the aircraft, TCP/IP on the ground
- Future proof for future network technologies
- Effectively decouples ground, satellite link,
on-board network
17The AGW test bed
18Test cases
- 4 types of test were carried out
- Very light load.
- The objective is to verify that the AGW
interferes only minimally with traffic when no
congestion is present - Very heavy load.
- The objective is to verify that the AGW performs
as designed under heavy congestion. This test is
not representative of any foreseen operational
situation - Operational heavy load situation.
- The traffic load in somewhat below congestion
most of the time, with short periods of
congestion. The objective is to show that the AGW
can improve overall performance significantly
under light congestion. - Demonstration in a realistic ATC environment
19Test cases
- The tests were carried out with a mix of 3 types
of messages. - CPDLC (Controller-Pilot Data Link Communication).
These are high-priority, urgent messages - FLIPCY (Flight Plan Consistency). These were
considered of medium priority and urgency. - ADS-C (Automatic Dependent Surveillance
Contract) reports. These are regular position
reports. Because the reports are repeated at
rather short, regular intervals, we considered
these of low priority.
20Test bed results
21Thank you for your attention