Work Package 2 Progress Report...Work Package 2 – Progress Report Page 3/128 Document Id: ALL_NEAN_WP2_5-1.0 Version: 1.0 Date: 1999-05-26 Control Page Revision Log. Version Date

Work Package 2 – Progress Report

Document Id: ALL_NEAN_WP2_5-1.0File: E:\NEAN\WP\2\RESULT\doc\WP2_Progress_v10.docVersion: 1.0Date: 1999-05-26Status: ReleasedAuthored by: All TeamsPrinted: 2000-10-13

Work Package 2 – Progress Report Page 2/128

Document Id: ALL_NEAN_WP2_5-1.0Version: 1.0Date: 1999-05-26

Distribution ListName Authority

Per Ahl SAS

Kimmy Bech LFV

Jonas Carlsson LFV

Maurizio Castelletti European Commission

Nynne S. Dalå SLV

Patric Delhaise EUROCONTROL

Peter Ericsson LFV

Jan Ericsson SAS

Niclas Gustavsson LFV

Fotini Iannidou European Commission

Lars Peter Jensen SLV

Ulf Johnfors SAS

Larry Johnson LFV

Heribert Lafferton DFS

Michael Lariviere DLH

Jürgen Lauterbach DLH

Andreas Nees DFS

Kim O’Neil Advanced Aviation Technology (AAT)

Stefan Penter SLV

Peter Raffay SLV

Bo Redeborn LFV

Oliver Reitenbach DFS

Björn Syrén SAS

Flemming Tidselholdt SLV

Klaus Werner DLR

Burkhard Wigger DLH

Alex Vink EUROCONTROL



Control Page

Revision Log.

Version Date Author Pagesconcerned

Reason

0.1 - 0.7 1998-11-241999-04-15

All Teams(DANT/Editor)

All Draft versions

1.0 1999-05-26 All Teams(DANT/Editor)

All First release.



Table of Contents

EXECUTIVE SUMMARY ................................................................................................................11

2. INTRODUCTION..........................................................................................................................132.1. OBJECTIVES OF THIS DOCUMENT .............................................................................................142.2. REVISIONS ...............................................................................................................................14

3. TEST SPECIFICATION AND RESULTS ....................................................................................153.1. COMMON DEFINITIONS AND GENERIC DATA ...........................................................................173.2. RELIABILITY TESTS..................................................................................................................18

3.2.1. R1: Air-Ground Data Link Reliability. ......................................................................183.2.2. R2: Ground-Ground Data Link Reliability ................................................................253.2.3. R3: Static Ground Position Accuracy ........................................................................393.2.4. R4: Dynamic Relative Position Stability....................................................................57

3.3. COVERAGE TESTS ....................................................................................................................643.3.1. C1: Air-Ground VHF Long Range Coverage ............................................................643.3.2. C2: Airport System Coverage ....................................................................................82

3.4. PERFORMANCE TESTS ..............................................................................................................883.4.1. P1: Ground Network Delay and Throughput .............................................................883.4.2. P2: System Delay .....................................................................................................100

3.5. AVAILABILITY TESTS.............................................................................................................1103.5.1. A1: Ground System Availability..............................................................................1103.5.2. A2: Reliability of Airborne GNSS Transponder......................................................117

4. CONCLUSIONS AND RECOMMENDATIONS.......................................................................1204.1. INDIVIDUAL TEST CONCLUSIONS ............................................................................................120

4.1.1. R1 - Air-Ground Data Link Reliability ....................................................................1204.1.2. R2 - Ground-Ground Data Link Reliability .............................................................1204.1.3. R3 - Static Absolute Position Accuracy for Ground Vehicles .................................1214.1.4. R4 - Dynamic Relative Position Stability for Ground Vehicles ..............................1224.1.5. C1 - Air-Ground VHF Long Range Coverage .........................................................1234.1.6. C2 - Airport System Coverage .................................................................................1244.1.7. P1 - Ground Network Delay and Throughput ..........................................................1244.1.8. P2 - System Delay ....................................................................................................1254.1.9. A1 - Ground System Availability.............................................................................1254.1.10. A2 - Reliability of Airborne GNSS Transponders .................................................126

4.2. PRINCIPAL CONCLUSIONS ......................................................................................................128

APPENDIX A – DETAILED TEST RESULTS

APPENDIX B – TEST TOOLS

APPENDIX C – NEANSERV MIB



List of FiguresFigure 1 - Plot from 1998-12-18 around Norrköping 20Figure 2 - Recorded tracks between 1998-12-01 and 1999-03-12 around EKGF and EKCH 21Figure 3 - ADS-B Completeness and TRPOD(4) for Copenhagen/Kastrup (EKCH) 22Figure 4 - ADS-B Completeness and TRPOD(4) for Tyra East (EKGF) 22Figure 5 - Plot from flight SAS181 24Figure 6 - Setup for the static reliability test 26Figure 7 - Location of Base Station and Mobile Transponder in Frankfurt 27Figure 8 - Distribution of Loss per Gaps [%] 29Figure 9 - Distribution of loss per received text message 30Figure 10 - Showing areas A-G in Frankfurt used for completeness study 31Figure 11 - Showing vehicle tracks for area A, Frankfurt Airport 33Figure 12 - Showing vehicle tracks for area B, Frankfurt Airport 34Figure 13 - Showing vehicle tracks for area C, Frankfurt Airport 34Figure 14 - Showing vehicle tracks for area D, Frankfurt Airport 35Figure 15 - Showing vehicle tracks for area E, Frankfurt Airport 35Figure 16 - Showing vehicle tracks for area F, Frankfurt Airport 36Figure 17 - Showing vehicle tracks for area G, Frankfurt Airport 36Figure 18 - ADS-B track completeness, area A-G, Frankfurt airport 37Figure 19 - Horizontal positions (all points) 42Figure 20 - West-east plot of heights (all points) 43Figure 21 - Horizontal positions (only corrected positions shown) 43Figure 22 - West-East plot of heights (only corrected positions shown) 44Figure 23 - Deviation from reference latitude 45Figure 24 - Latitude deviation - positions counted 46Figure 25 - Deviation from reference longitude 47Figure 26 - Longitude deviation - positions counted 47Figure 27 - Horizontal distance from reference point 48Figure 28 - Horizontal distance - positions counted 48Figure 29 - Deviation from reference height 49Figure 30 - Height deviation - positions counted 49Figure 31 - Distribution of latitude deviation 51Figure 32 - Distribution over time 51Figure 33 - Distribution of longitude deviation 52Figure 34 - Deviation over time 52Figure 35 - Distribution of radial deviation 53Figure 36 - Radial deviation over time 53Figure 37 - Radial deviation over time 54Figure 38 - Latitude-longitude presentation (Frankfurt) 56Figure 39 - The People Mover train at Frankfurt Airport 58Figure 40 - Track of the people mover at Frankfurt airport 59Figure 41 - Two tracks of the people mover at Frankfurt Airport 60Figure 42 - Geographical slots for statistical evaluation 60Figure 43 - Statistical distribution of ADS-B reports - southern track 61Figure 44 - Statistical distribution of ADS-B reports - northern track 62Figure 45 - Test setup with connections to individual sensors 66Figure 46 - Sample of recorded flight within the NEAN coverage area 67Figure 47 - Long range VHF coverage from Frankfurt (EDDFB01) 68Figure 48 - Long range VHF coverage from Köln/Bonn (EDDKB01) 68Figure 49 - Long range VHF coverage from Bremen (EDDWB01) 69Figure 50 - Long range VHF coverage from Braunschweig (EDDVB01), 1998-10-29 69Figure 51 - Long range VHF coverage from Kastrup (EKCHB01) 70Figure 52 - Long range VHF coverage from Aalborg (EKYTB01) 71Figure 53 - Long range VHF coverage from Billund (EKBIB01) 71Figure 54 - Long range VHF coverage from Esbjerg (EKEBB01) 72Figure 55 - Long range VHF coverage from Tyra East (EKGFB01) 72Figure 56 - Long range VHF coverage from Esbjerg - Range/Height 73Figure 57 - Long range VHF coverage from Tyra East - Range/Height 74



Figure 58 - Long range VHF coverage from Billund - Range/Height 75Figure 59 - Long range VHF coverage from Aalborg - Range/Height 75Figure 60 - Long range VHF coverage from Kastrup - Range/Height 76Figure 61 - Long range VHF coverage from Frankfurt - Range/Height 76Figure 62 - Long range VHF coverage from Köln/Bonn - Range/Height 77Figure 63 - Long range VHF coverage from Bremen - Range/Height 77Figure 64 - Long range VHF coverage from Braunschweig - Range/Height 78Figure 65 - Entry-point detection 80Figure 66 - Exit-point detection 80Figure 67 – NEAN area 81Figure 68 - Position reports received from all vehicles and aircraft at the airport 84Figure 69 - Position reports received from all vehicles and aircraft at the gate area 84Figure 70 - Position reports received from the test vehicle at Frankfurt airport 85Figure 71 - Critical coverage areas at Frankfurt airport 86Figure 72 - Areas with Navigation Mode 2 or 3 in Frankfurt Airport 87Figure 73 - Logical topology of Danish NEAN segment 89Figure 74 - Test setup for the network delay/load test 90Figure 75 - Average network delay in the Danish segment 91Figure 76 - Average network delay for the Danish NEAN network pr. day 92Figure 77 - STDMA packets from Kastrup local server (EKCHLS) 93Figure 78 - STDMA packets from Aalborg local server (EKYTLS) 94Figure 79 - STDMA packets from Billund local server (EKBILS) 94Figure 80 - STDMA packets from Esbjerg regional server (EKEBRS) 95Figure 81 - STDMA packets from Tyra East local server (EKGFLS) 95Figure 82 - Network load on Kastrup national router and influx from local servers 96Figure 83 - Network load on Billund local router and influx from local server 97Figure 84 - Network load on Esbjerg local router and influx from Tyra East Local and Esbjerg regional server 97Figure 85 - Network load on Aalborg local router and influx from both Aalborg and Billund local servers 98Figure 86 - Network load on Tyra East local router and influx from Tyra East local server 98Figure 87 - Correlation between $2-messages and router load for Tyra East 99Figure 88 - Network load on international routers in Arlanda and Bremen 99Figure 89 - Test setup for the System Delay Test 101Figure 90 - Plots from the system delay test during 19-22 December 1998. The rings represent the BaseStations used for

the test. 102Figure 91 - Distribution of message-ping delay times 103Figure 92 - Geographical locations of ping'ed aircraft 107Figure 93 - 'Raw' turn-around times of successfully delivered messages 108Figure 94 - Test setup for the availability study 112Figure 95 - Availability of all Danish segment DataFeeds 115Figure 96 - Sample of recorded flight within the NEAN coverage area 123



List of TablesTable 1 - Rcomplete result summary 21Table 2 - Completeness for EKCH and EKGF 23Table 3 - Special test message with incrementing block counter 28Table 4 - Evaluation of the block counter 29Table 5 - Reliability of the STDMA data link with message transmission in static environment 29Table 6 - Completeness for all areas, using all tracks 37Table 7 - Geographical Slot Definition 58Table 8 - Statistical Evaluation of southern track 61Table 9 - Statistical Evaluation of northern track 62Table 10 - Entry/Exit point parameter values 65Table 11 - Long-range coverage summary 79Table 12 - STDMA messages counted 92Table 13 - Packet header sizes NetHeader, IP and TCP 96Table 14 - Messages in Tyra East PING experiment 104Table 15 - Longest message path in the NEAN network 106Table 16 - Message-ping delay times Copenhagen/Kastrup to aircraft in Tyra East coverage 108Table 17 - Message path for $A-messages 112Table 18 - Danish network segment and ground station availability 113Table 19 - Time differences between $A-messages 114Table 20 - Major unavailability periods 115Table 21 - Number of flight hours with NEAN equipment installed 118Table 22 - R2 transponder problems detected in Danish segment 119



AbbreviationsADS Automatic Dependent SurveillanceADS-B Automatic Dependent Surveillance – BroadcastASN.1 Abstract Syntax Notation OneATC Air Traffic ControlATM Air Traffic ManagementATN Aeronautical Telecommunications NetworkCANDI Civil Aviation Network Data InterchangeCDTI Cockpit Display of Traffic InformationCNS Communication, Navigation and SurveillanceCOTS Commercial Off The ShelfCPDLC Controller Pilot Data Link CommunicationCWP Controller Working PositionCAA Civil Aviation AdministrationDANT Danish NEAN Project TeamDCAA Danish Civil Aviation Administration (SLV)DFS Deutsche Flugsicherung GmbHDGPS Differential Global Positioning SystemDGVII Directorate General VIIDLH Deutsche LufthansaDLR Deutsche Forschungsanstalt für Luft- und RaumfahrtDOS Disk Operating SystemDTU Data Terminating UnitEU European UnionFARAWAY Fusion of Radar and ADS data through two WAY data linkFREER Free-Route Experimental Encounter ResolutionGERT German NEAN Project TeamGNSS Global Navigation Satellite SystemGPS Global Positioning SystemICAO International Civil Aviation OrganisationIP Internet ProtocolISDN Integrated Services Digital NetworkISO International Standards OrganisationJAA Joint Aviation AuthoritiesLAN Local Area NetworkLFV Luftfartsverket (SCAA)LS Local ServerNEAN North European ADS-B NetworkNEAP North European CNS/ATM Application ProjectNUP NEAN Update ProgrammeNAAN North Atlantic ADS-B NetworkOLT Ostfriesische Lufttransport GmbHOSI Open Systems InterconnectionPETAL Preliminary EUROCONTROL Test of Air/Ground Data LinkPSN Packet Switched NetworkRAPNET Regional ATC Packet switched NetworkSAS Scandinavian Airline SystemsSCAA Swedish Civil Aviation Administration (LFV)



SDS Sub Domain ServerSLV Statens Luftfartsvæsen (DCAA)SMGCS Surface Movement Guidance and Control SystemSQL Structured Query LanguageSSR Secondary Surveillance RadarSTDMA Self-organising Time Division Multiple AccessSWET Swedish NEAN Project TeamTCP Transmission Control ProtocolTEN-T Trans-European Network - TransportTWR Air Traffic Control TowerUK United KingdomUTC Universal Time Co-ordinatedVDL VHF Digital LinkVHF Very High FrequencyWAN Wide Area NetworkWGS 84 World Geodetic System 1984WP Work PackageXPDR Transponder



References

[1] Work Package 1 – Progress ReportALL_NEAN_WP1_1, All Teams, 1997-02-11

[2] Work Package 3 – Progress ReportALL_NEAN_WP3_2, All Teams, 1997-04-30

[3] The GNSS Transponder T2/R2/MPX 3501 – Technical Description81-300-1 LFV GNSS Transponder, Tech.desc., Rev 5andThe GNSS Transponder T2/R2/MPX 3501 – Integration of External Systems81-300-2 LFV GNSS Transponder, Integrat, Rev 5

[4] NEAN Problem and Change ReportSLV_WP1_01-1.1, S.Penter, September 9, 1996

[5] RTCA/DO-208, Minimum Operational Performance Standards for AirborneSupplemental Navigation Equipment Using GPS,July 12, 1991. Prepared by SC-159

Change to DO-208,September 21, 1993, Appendix B

[6] Final NEAN Project Summary and Conclusion ReportALL_NEAN_WP5_02, All Teams, 1999-03-26

[7] Record of NEAN Problem and Change RequestsSLV_WP1_21, S.Penter, November 1996



Executive SummaryThe overall objective of the North European ADS Broadcast Network (NEAN) project was todevelop, evaluate and demonstrate new technologies for data links and networking, and therebycontribute to the implementation of a network for Communication, Navigation and Surveillance inthe provision of Air Traffic Management in Europe.

During Work Package 2 (WP2), evaluations were performed on the established network. Theobjective of the evaluations was to validate the surveillance potential of an STDMA/ADS-B basedsystem for ATM usage by examining various technical performance parameters of the installedtestbed.

This report provides a detailed description of the individual evaluations carried out and thecorresponding results. Ten tests were performed:

• Air-Ground Data Link Reliability• Ground-Ground Data Link Reliability• Static Ground Position Accuracy• Dynamic Relative Position Stability• Air-Ground VHF Long Range Coverage• Airport System Coverage• Ground Network Delay and Throughput• System Delay• Ground System Availability• Reliability of Airborne GNSS Transponder

The tests are fully described in this report, and summarised below are the principal conclusions:

• A surveillance concept based on ADS-B and STDMA/VDL Mode 4, augmenting existinginfrastructure, is feasible, in terms of data completeness, accuracy and coverage for both groundand airborne scenarios.

• An infrastructure could be developed and maintained by using existing technologies andnetwork concepts, and surveillance could be provided where none exist or deployment oftraditional equipment is too costly.

• The STDMA ground-ground surveillance capability - in terms of data completeness – could beused as part of ground surveillance systems, but it is recommended that additional BaseStations(MonitorStations) be deployed and the raw ADS-B data passed through a tracker functionalitycompensating for losses.

• Static position accuracy depends on the actual antenna environment. Although the antennas inthis test were situated in a possible multipath environment and that the position reports aresubject to the transponder resolution, position accuracy is fairly high and promising.

• The motion of a vehicle has no influence on the position stability. For SMGCS applications therelative position stability of the ADS-B/STDMA technology is suitable and useable assumingthat an ICAO - Standard will be established.

• The coverage of the VDL seems adequate for most surveillance purposes. The same systemcould be used for surveillance during multiple phases of flight. However, the coverage dependson high quality GroundStation installations and it is recommended that standards be developed



specifying minimum requirements for the GroundStation in terms of coverage and how to verifythese requirements.

• It is feasible to have a ground ADS-B/STDMA system capable of delivering ADS-B positionswithin 2s. Average delivery times of less than 2 seconds, were measured both in Sweden and inDenmark (including the Tyra East satellite link) and is quite promising.

• Availability issues have a negative effect on other tests and must be eliminated or minimised infuture developments of GroundStations or other test equipment. The trial system had problemswith availability, but is should be noticed that the system was not designed for high availability.



2. IntroductionThe overall objective of the North European ADS Broadcast Network (NEAN) project was todevelop, evaluate and demonstrate new technologies for data links and networking, and therebycontribute to the implementation of a network for Communication, Navigation and Surveillance inthe provision of Air Traffic Management in Europe.

To achieve this objective an experimental system, developed to prototype level, was establishedduring Work Package 1 and 3 comprising a network of STDMA Ground Stations in Denmark,Sweden and Germany and avionics installed in aircraft and airport based vehicles.During Work Package 2, demonstrations and evaluations were performed on the establishednetwork. The objective of these evaluations was to validate the surveillance functionality of anSTDMA/ADS-B based system for ATM usage by examining various technical performanceparameters of the installed testbed.The intention of the technical evaluation was to reveal weak points in the concept and not tocompare results with requirements for an operational system, since the infrastructure was not builtfor operational use.

This report provides a detailed description of the individual tests carried out and the correspondingresults. It comprises the reporting period from March 1997 to December 1998.

The envisaged objectives were met. ADS-B position reports were gathered from the NEANNetwork and analysed. However, the work was made difficult by several events:

• Logging functions caused crashes.The local logging functionality present in the DOS based NEAN Server software were causingproblems regarding the stability of the servers with high load and ultimately had to be stopped.WP2 were left to produce new centralised logging facilities: An NT/SQL based logging devicedeveloped by SWET and a UNIX based logging server developed by DANT was installed.

• NEAN as service provider for PETAL.During the course of Work Package 2, a decision was made to make NEAN a service providerfor the ongoing PETAL trials. The ground station server software and the R2 transpondersoftware was upgraded to handle end-to-end messaging as needed by PETAL. This task wasinherently more complex than initially foreseen causing many problems in the DOS basedserver software.

• Change of ground system concept during the trials.During the course of WP2, it was realised that the initial DOS based platform did not suffice,therefore a new concept called LS/SDS was specified and developed, but only partly deployed. It isintended that the work will continue in the NEAN Update Programme (NUP).

• New generation of transponders.The project made a call-for-tender for a next generation of transponders and the contract wasawarded to SAAB Dynamics. However, many technical problems with the new transpondersdelayed the process of deployment such that the transponder base for the NEAN network nowconsists of a mixture of R2's and T3's, making evaluations more complex.

Only compiled results are presented here. Details of the tests are placed in appendix A due to theirvoluminous nature.



2.1. Objectives of this DocumentThe document aims at providing detailed descriptions of individual tests carried out, their resultsand conclusions.

Other vital and equally important activities which has been performed on the NEAN testbed (Likethe NEAP trials and PETAL trials) is outside the scope of this document, but will be addressed inthe 'Final Project Summary and Conclusion Report' [6].

2.2. RevisionsThis document is maintained by DANT and released as the final deliverable of NEAN WorkPackage 2.



3. Test Specification and ResultsThe tests and their results are grouped into the following categories and a chapter is dedicated toeach category.

• Reliability (R)• Coverage (C)• Performance (P)• Availability (A)

Ten tests were defined within these areas and divided among the partners.

• R1: Air-Ground Data Link Reliability, SWET, DANTThe main objective was to determine the reliability of the ADS-B functionality of the data linkduring normal operation, in an area with assumed full VHF coverage. The test focused on thecompleteness of the delivered surveillance data by examining whether the system lost incomingdata.

• R2: Ground-Ground Data Link Reliability, GERT, DANTThe objective of the test was to the show the feasibility of using the STDMA/VDL Mode 4 datalink for ground-ground datalink applications, which makes the system suitable for e.g. SMGCSapplications, by examining the data link reliability within a typical airport environment.

• R3: Static Ground Position Accuracy, DANT, GERTThe objective was to determine the absolute position accuracy for a fixed mobile transponderover several days

• R4: Dynamic Relative Position Stability, GERTThe objective was to examine the relative position stability for Ground Vehicles in motion in anassumed full VHF coverage area.

• C1: Air-Ground VHF Long Range Coverage, DANT, GERTThe objective was to determine the long-range VHF coverage for NEAN ground stations interms of outer boundaries of the coverage area.

• C2: Airport System Coverage, GERT, DANTThe objective was to compile and visualise information of the system coverage (both GPS andVHF) for ground vehicles operating in a typical airport environment.

• P1: Ground Network Delay and Throughput, DANTThe objective was to collect information on ground network delay times for all links in theNEAN network.



• P2: System Delay, SWET, DANTThe objective was to measure the total system delay-times for messages sent from end-system toend-system, ground-to-air and air-to-ground.

• A1: Ground System Availability, DANTThe objective was to record the availability of a homogeneous segment of the ground system(Danish segment) and the international connections. The main reason for carrying out this testwas to register periods when recording of ADS-B data was possible rather than to check theresults against operational availability requirements.

• A2: Reliability of Airborne GNSS Transponder, SWETThe objective was to collect information regarding problems with the GNSS Transpondersoperating in the airborne environment. A mixed environment of R2/T2 and T3 transponders wasused for the NEAN tests.

For each test case the following is included:

• Test Identification Identification and name of the test together with responsible NEAN partner, a data acquisition

period and the sensor/sensors on which the data was recorded. • Objectives Short textual description of the purpose of the test. • Definitions List of any particular definitions used for this test. • Test Description and Setup Short textual description of test scenario and test setup. • Prerequisites and Assumptions List of pre-requisites and assumptions for the test. • Results Specification Textual description of how the result-data should be represented. • Results

The results after final processing. Detailed information on the test and any intermediate resultscan be found in appendix A.

• Error Sources

List/description of possible error sources contaminating the result.

Conclusions for the individual test are found in chapter 4. Conclusions and Recommendations.



3.1. Common Definitions and Generic DataThe tests will use the following common definitions.

BaseStation A BaseStation consists of the VHF-antenna, GPS antenna, an STDMAtransponder and a Differential GPS receiver.

GroundStation A GroundStation consists of a BaseStation and a NEAN Server PC incl.software.

GroundNetwork The GroundNetwork consists of LAN-Segments, IP-Routers, WAN-links

Most of the tests depend on ADS-B position report data, which contain the following (See [3] fordetails):

<POSRPT> ::= typeId A one character identification of position. The most common:1=Own position, 2=Incoming Position, 3=Crypted Position.

xpdrId Identification of the transponder from where the positionoriginated. Only 8 char ASCII allowed.

Lat WGS84 Latitude. Integer value in 1/1000 min.!90 Degrees, Lat>0⇒ N, Lat<0⇒ S. Packed as 2's complementASCII-Hex.

Lon WGS84 Longitude. Integer value in 1/1000 min.!180 degrees, Lon>0⇒ E, Lon<0⇒ W. Packed as 2'scomplement ASCII-Hex.

Speed Ground speed in 2 knot stages. Integer value. [0-4095] Packedas ASCII-Hex.

heading Integer value in 1/10 degrees.[0-359,9] Packed as ASCII-Hex.

altitude WGS84 altitude in 16 feet stages. Integer value. [0-19,7km]Packed as 2's complement ASCII-Hex.

navMode Navigation mode: 0=No Nav, 2=2D Nav., 3=3D Nav.,4=2D+DGPS, 5=3D+DGPS Nav.

UTCsecond UTC second where the report originated. Integer value [0-59,63]. 63 (3F hex)⇒ GPS is not navigating. Packed as ASCII-Hex.

climb Climb indication. [Not in Use for R2 transponder Always 0].F=Climbing, 0=Maintaining, 1=Decending.

Checksum Always starts with '*' followed by a 2 ASCII Hex NMEA-0183compatible checksum.

References to this data will occur throughout the document.



3.2. Reliability Tests

3.2.1. R1: Air-Ground Data Link Reliability.

Identification R1Name Air-Ground Data Link ReliabilityResponsible SWET/LFV, DANT/SLV

Data Acquisition Period 1998-12-18 ⇒ 1998-12-19, 1999-01-14 ⇒ 1999-01-16 (SWET)1998-12-01 ⇒ 1999-03-01 (DANT)

Recorded on Sensor ESSPB01 (ESSPLS, Norrköping)EKGFB01 (EKGFLS, Tyra East)EKCHB01 (EKCHLS, Copenhagen/Kastrup)

3.2.1.1. Objectives

The main objective of this test was to determine the reliability of the ADS-B/STDMA surveillanceduring normal operation, in an area with assumed full VHF coverage.The test focused on the completeness of the delivered surveillance data by examining whether thesystem lost incoming data.

3.2.1.2. Definitions

Rcomplete ADS-B data completeness was defined as:

Rcomplete = 100 * Received / Expected %,

measured during time interval ∆t, with transmission rate TXr in aFullCoverageArea.

FullCoverageArea FullCoverageArea = Geographical limited area near a BaseStation, where fullVHF coverage could be assumed.

Received Received = Counted ADS-B reports received by a sensor ∈ SENSORS in thetime interval ∆t.

Expected The expected number of ADS-B positions were estimated as:Expected = (∆t+1) * TXr

TXr Transmission Rate TXr = Number of transmitted ADS-B reports per time unitfor an airborne transponder.

∆t ∆t denotes the time interval in which the aircraft transmitted ADS-B positionsin the FullCoverageArea

SENSORS Denotes the set of system sensors where data entered the system. It comprisesBaseStation transponders. For the Swedish and Danish experiment the



SENSORS set were:

SENSORSSWET={ESSPB01(Norrköping)},SENSORSDANT={EKGFB01(Tyra East), EKCHB01(Kastrup)}

TRPOD(n) TRPOD(n) denotes a theoretical radar probability of detection for a radar withsweep time equal to n.This measurement was calculated by synchronising virtual radar to the firstposition in an ADS-B track and then counting ADS-B positions in thetheoretical sweep-time intervals. If no ADS-B positions were found during avirtual sweep, then a missed radar plot was counted. The principle (with sweeptime=2s) is illustrated below.

Missed ADS-B positionReceived ADS-B position

Missed radar position

Received radar position

Radar

ADS-B

time

sweep time

TRPOD(n) provides information on the distribution of ADS-B position losses.

3.2.1.3. Test Description & Setup

During the test period, all flights through the defined FullCoverageArea were recorded from asingle BaseStation. The number of received ADS-B reports was counted for each flight. Calculationof the expected number of ADS-B reports from a specific flight, was made using the time when theflight enters and leaves the FullCoverageArea and the known transmission rate TXr of the ADS-Bposition reports.

For the Swedish part of the experiment, data from SENSORSSWET was used. The log tool was thestandard log program, LS/SDS log device 1.4, running 24 hours per day. The log device created onelog file per day with aircraft ADS-B reports, and these files were downloaded from the server ramto the computer with the post-processing tool for further processing.

For the Danish part of the test, data from SENSORSDANT was used. Data was collected on a centrallog server in Copenhagen Kastrup.

3.2.1.4. Prerequisites and Assumptions

Assumption1 Link load would be sufficiently low, such that reliability would not be affected;i.e. insignificant losses of position reports caused by the actual link-load wereassumed.

Assumption2 The mobile and the BaseStation would be within range of the FullCoverageArea,such that the measured loss of ADS-B positions would not be caused byinsufficient coverage.



3.2.1.5. Results Specification

As a result the test produced reliability percentages as defined by Rcomplete and geographical mapsshowing he flights.

3.2.1.6. Results

Within the Swedish NEAN segment, results from December 18, 1998, shows a declining reliabilitywhen the FullCoverageArea (a square in this case) is increased (the ”square” is increased from 80NM to 120 and 160 NM). Almost all logged aircraft arrived or departed from Arlanda airport northof Stockholm and the descending phase of the flight was started just north of Norrköping. When theminimum altitude was set to 10000 ft, the tracks from these flights would end before the aircraft hadreached the edge of the square 120 NM and 160 NM, as the altitudes would then be below theminimum altitude. The BaseStation in Norrköping picked up ADS-B reports from flights departingfrom Arlanda and heading north resulted in conditions close to the physical limitations for VHFsignals. The conclusion was that a FullCoverageArea was only achieved if the square was set to 80NM and the minimum altitude to 10000 ft or more.

Figure 1 - Plot from 1998-12-18 around Norrköping

Figure 1 shows a plot from 1998-12-18 with Square=160 NM, Minimum altitude=10000 ft andMax Diff. Time=30 s.



Table 1 shows a summary of the results, all with Square=80 NM, Min Alt=10000 ft and Max DiffTime=30 s:

Date Average Rcomplete Minimum Rcomplete98-12-18 96.1% 94.9%99-01-13 96.6% 94.8%99-01-14 95.4% 90.2%99-01-14 98.2% 97.1%Table 1 - Rcomplete result summary

DANT measured Rcomplete of tracks in the Tyra East and Kastrup vicinity using R2 BaseStationtransponders and DOS-based NEANSERV servers.

A FullCoverageArea was defined around the sensors in SENSORDANT as a cylinder with thefollowing parameters: Radius=150 km and minimum height = 10000 ft. All positions would thenbe well within the approximated theoretical range (225 km) for the selected minimum height.Tracks with less than 1000 positions were filtered out to minimise the impact of losing positions intracks with few expected positions.

Figure 2 shows the tracks going through the FullCoverageAreas during the period 1998-12-01⇒ 1999-03-12. In total, 61 tracks were recorded and analysed.

Figure 2 - Recorded tracks between 1998-12-01 and 1999-03-12 around EKGF and EKCH

Tyra East(EKGF)

Kastrup(EKCH)



The measured ADS-B completeness and the calculated TRPOD(4) are shown in Figure 3 and Figure4.

EKCH Completeness

10099 99 10099

86

99 100

9298

87 89

10197

91

77

98 9995 97 97 97

87

98 95 98 99 99 99

9298

9498 98 98 96 96

99 99 99 99

0

20

40

60

80

100

120

1998

1201

0823

10

1998

1206

1427

09

1998

1215

2039

58

1998

1216

2028

01

1998

1221

1632

35

1998

1222

0816

30

1999

0107

2038

28

1999

0115

1842

12

1999

0116

1829

49

1999

0117

1028

20

1999

0125

1041

55

1999

0202

1223

07

1999

0303

1439

11

1999

0305

1858

17

1999

0307

0902

55

1999

0307

1835

52

1999

0308

1910

08

1999

0309

1840

04

1999

0310

1728

47

1999

0311

2031

27

1999

0312

1757

57

Time

Perc

ent TRPOD(4)

Rcomplete

Figure 3 - ADS-B Completeness and TRPOD(4) for Copenhagen/Kastrup (EKCH)

EKGF Completeness

96 98

91

79 80

90

98 98 99

86

97 97100 99 99

9598 99 100 98

0

20

40

60

80

100

120

1998

1217

1716

15

1998

1221

1032

02

1998

1221

1317

01

1999

0111

2048

52

1999

0112

2045

59

1999

0220

1147

40

1999

0227

1004

37

1999

0228

1008

57

1999

0228

1249

28

1999

0302

1705

37

1999

0303

1510

58

1999

0305

1752

15

1999

0305

2110

44

1999

0306

0846

05

1999

0306

1210

34

1999

0307

1721

52

1999

0307

2108

43

1999

0308

1228

55

1999

0309

1047

25

1999

0309

1318

00

Time

Perc

ent

TRPOD(4)Rcomplete

Figure 4 - ADS-B Completeness and TRPOD(4) for Tyra East (EKGF)



Fluctuations in the Rcomplete are observed in the graphs and completeness as low as 77% can bedetected. However, when analysing the tracks with low completeness, systematic losses are seen.This indicates problems with the transponder slot allocation (see section on error sources).

Table 2 summarises the results.

Copenhagen/Kastrup (EKCH)

Tyra East(EKGF)

Total # tracks 41 20Positions in track 52078 24631Total track time [s] 54172 25948Completeness [%] (all tracks) 96.1 94.9TRPOD(4) [%] (average) 99.8 99.9Table 2 - Completeness for EKCH and EKGF

The results indicate that a surveillance system using ADS-B/STDMA will, in terms of datacompleteness, perform as good as the current SSR systems. The test shows that it is feasible to useADS-B/STDMA for surveillance purposes.

3.2.1.7. Error Sources

• Danish BaseStations had their slot allocation tables changed and software upgraded during the test-period

• Slot reservation message. Minimum Rcomplete from 99-01-14 is only 90.2%. Detailed analysis ofthe plot files shows a repeated pattern of lost ADS-B reports from the aircraft SAS181, seeFigure 5. Every other ADS-B report is lost periodically. The time between two blocks of lostADS-B reports is 16 seconds and the block is 8 seconds long.

The explanation of this behaviour is most probably different configuration of the, so-called, slotreservation message (slot reservation for BaseStation up-link), sent from the BaseStations inthe NEAN network. The SAAB T3 aircraft transponder is sensitive to different slot reservationmessages sent from BaseStations, and has proven to be more sensitive than the previous T2/R2transponder. Each BaseStation transmits this slot reservation message every 8 seconds, and atthe time of the recording, the Danish BaseStations had another configuration than the Swedishstations. The slot reservation message sent from the Danish stations blocked twice as muchtime slots as the Swedish. The blocking is repeated every two seconds. The aircraft transponderwill use the latest received slot reservation message and abandon planned transmissions ofADS-B reports if they are in conflict with the slot reservation. Flight SAS181 has probablyused a Swedish slot reservation message for 8 seconds, and after that a Danish message (withdoubled blocking size) and abandoned every other ADS-B report for 8 seconds, and so on.According to the conclusions of a study made by SAAB Dynamics, the transponder mayabandon as much as 50% of the ADS-B reports over a period of 10 minutes based on theconfiguration in the NEAN network.



The aircraft will be out of range from the Danish stations further north, which can be seen inthe number of received ADS-B reports. A special post processing was carried out to verify thison the data from 99-01-14. The Reliability values for the upper half of the square aroundNorrköping BaseStation, were calculated. SAS181 has in this case 96.5%, compared to 90.2%for the whole square.

Figure 5 - Plot from flight SAS181

A periodical loss of ADS-B reports can be seen on more flights, but not as clear as on SAS181.Flights going more to the east show less loss of ADS-B reports than the flights more to the west.The loss can not be correlated to any specific aircraft. Same behaviour was also seen of tracks inthe Danish segment.

• Bit errors might occur on the modem lines between the BaseStation transponder and the localserver. If this happens during the data collection it might have big influence on some flights. Aflight through the coverage volume might comprise as little as 100-200 ADS-B reports. A loss ofone report will in that case decrease the reliability result with 0.5-1.0 %.



3.2.2. R2: Ground-Ground Data Link Reliability

Identification R2Name Ground-Ground Data Link ReliabilityResponsible DANT/SLV (dynamic vehicle test), GERT/DFS (static message test)

Data Acquisition Period 1997-11-14 ⇒ 1997-11-17 (static message test)1998-09-17 ⇒ 1998-09-24 (dynamic vehicle test)

Recorded on Sensor Frankfurt Tower Mobile (static message test)Frankfurt Local Server (dynamic vehicle test)

3.2.2.1. Objectives

The current Surface Movement Guidance and Control Systems (SMGCS) are not always able tosupport ground movement operations on aerodromes in order to maintain the required capacity andsafety levels, especially under low visibility conditions. As a consequence an Advanced SurfaceMovement and Guidance and Control System (A-SMGCS) is developed.The objective was to show the feasibility of using the STDMA technology as part of SMGCSapplications, by examining the STDMA/VDL Mode 4 data link reliability within a typical airportenvironment.

Two parameters will be examined:

• The reliability of message transmissions between two non-moving transponders, by detectingposition losses and width of gaps.

• The completeness of positions emitted from moving vehicles in the Frankfurt Airportenvironment during normal day-to-day operation.


Rcomplete Rcomplete = Received/Expected [%], measured during time interval ∆t [s], withtransmission rate TXr in AirportArea.

TXr Transmission Rate TXr = Number of transmitted ADS-B reports per time unitfor a Transponder[1/s].

Expected Expected = (∆t+1) * TXr

Received Received = Counted ADS-B reports received by a specified GroundStation inthe time interval ∆t. The counting must be performed close to theGroundStation recording the ADS-B positions to make sure that no losses ofposition reports remain unregistered in the path between measurement-pointand sink.

AirportArea AirportArea is a cylindrical area in the Airport. The cylindrical area is definedby a centre (Lat,Lon)WGS84 and a range r [m].



TRPOD(n) TRPOD(n) denotes a theoretical radar probability of detection for radar withsweep time equal to n.

This measurement is calculated by synchronising a virtual radar to the firstposition in an ADS-B track and then counting ADS-B positions in thetheoretical sweep-time intervals. If no ADS-B positions are found during avirtual sweep, then a missed radar plot is counted. The principle is illustratedbelow with sweep time=2s.

Missed ADS-B positionReceived ADS-B position

Missed radar position

Received radar position

Radar

ADS-B

time

sweep time

TRPOD(n) provides information on the distribution of ADS-B position losses.

VehicleTrack A VehicleTrack is a collection of ADS-B positions received in chronologicalorder where each position in the track has a speed > 5kt and each track holdsat least 15 positions. This is done to exclude tracks where vehicle has gone into'sleep-mode' and only emits one position every two seconds and to limit theinfluence of loosing a single position in a track with few positions.A VehicleTrack is initiated if 2 ADS-B positions are seen from a transponderID and is terminated if no positions are received for 5s.


For the static part of the test, a mobile transponder was installed at the Tower in Frankfurt Airport,from where text messages were transmitted with TXr = 1/s. As payload the text messages containeda block counter incremented for every transmission, thus making it possible to detect missingreceptions and to evaluate the width of reception gaps. The text messages were transmitted asbroadcast messages, so no acknowledgement was expected from the receiving BaseStation. Eachmessage was transmitted only once.

Figure 1 schematically shows the test setup.

Frankfurt Base Station (@EDDFB01)

NEAN StationFrankfurt

Sensor

Frankfurt TWR

PC

#R22

$PRGPS-Message $E-Message

Logfiles

$E-Message on VDL

Figure 6 - Setup for the static reliability test



The mobile transponder (ID '#R22'), connected to a PC via serial interface, was installed at theTower at approximately (50.027936°, 8.561450°, 157.34m)WGS84, i.e. 46,39m above ground referring toARP Frankfurt.

An application running on the PC generated and forwarded text messages to the transponder with afrequency of 1/second. Each text message consisted of 58 characters (6-bit coded), so a constant data load ofnearly 350 bit/second was produced. The BaseStation at Frankfurt Airport, located at a distance ofapprox. 2980m from the mobile was used as a receiver.

The map in Figure 7 shows the geographical location of the Base Station (@EDDFB01) and theMobile Transponder (#R22) at Frankfurt Airport.

Figure 7 - Location of Base Station and Mobile Transponder in Frankfurt

During three days, text messages with an incrementing block counter were transmitted with atransmission rate of 1/s from the mobile transponder. The messages received by the BaseStationwere forwarded to the national server installed in the DFS experimental centre in Langen. For therecording the logging functionality of the national server was used.



The message format is shown in Table 3:

Format: $:E: #R22−−−−:0:073533ABCDE... *:05:

GP&C message start characterMessage type: Text messageGround Mobile Transponder ID and 4 SpacesOption ByteMessage payload: Block counter, decimalMessage payload: Additional charactersGP&C message end characterChecksum: XOR between $ and *

Length: 58 ASCII charactersExample: $E#R22−−−−0073533ABCDEFGHIJKLMNOPQRSTUVWXYZXXABCDEFGHIJKLMNOPQRSTUVWXYZ*05

Table 3 - Special test message with incrementing block counter

For the dynamic part of the test seven AirportAreas within Frankfurt Airport were selected. Theareas were characterised by:

• Having multiple VehicleTracks going through them.• Being generic to most airports

Three generic areas1 were defined:

RWY/TWY Runway/Taxiway Area. Area is clear and no buildings are in the immediatevicinity.

GATE/TERM Gate/Terminal building Area. Area is characterised by medium height buildings(1-2 floors), extending from a terminal building.

REMOTE Area is characterised by being located far from the BaseStation transponder withpotentially many obstacles between the area and the BaseStation.

Ground vehicle ADS-B position reports were collected and data analysed with respect to loss ofposition reports.


None


For the static part of the test histograms showing the message losses are produced and for thedynamic part the test will produce reliability percentages (as defined by Rcomplete) for the specifiedareas.

1 These definitions are highly subjective.



3.2.2.6. Results - Static

The Table 4 lists the result parameters obtained from the evaluation of the block counter.

Parameters ResultsTotal Transmitted Messages: 69209Received Messages: 65530Successful Data Transfers performed: 62284Lost Messages: 6925Gaps of 1 or more missing Messages: 3246Transmission Errors: 11Table 4 - Evaluation of the block counter

Table 5 shows the reliability of the STDMA data link using message transmission in a static butairport environment:

Parameters ResultsSuccessful transmitted Messages [%] 89.99%Loss of Messages[%] 10.01%Table 5 - Reliability of the STDMA data link with message transmission in static environment

The loss of messages occurred within gaps of one or more lost messages. Figure 8 and Figure 9depict the distribution of loss in respect of the number of gaps and of the number of receivedmessages.

92.02%

5.42%1.91% 0.15% 0.15% 0.34%

0.00%

10.00%

20.00%

30.00%

40.00%

50.00%

60.00%

70.00%

80.00%

90.00%

100.00%

Perc

enta

ge

1 Msgs 2 Msgs 3 Msgs 4 Msgs 5 to N Msgs False MsgsLost Text Messages

Figure 8 - Distribution of Loss per Gaps [%]



95.05%

4.56%

0.27% 0.09% 0.01% 0.01% 0.02%

0.00%

10.00%

20.00%

30.00%

40.00%

50.00%

60.00%

70.00%

80.00%

90.00%

100.00%

0 Msgs 1 Msgs 2 Msgs 3 Msgs 4 Msgs 5 to N Msgs False MsgsLost Text Messages

Figure 9 - Distribution of loss per received text message

Some messages were seen to contain errors in the block counter, but to have correctly calculatedchecksum. This indicates that the message was transmitted successfully over the link and that theblock counter error must result from the data transfer between the PC and the transmittingtransponder. Since the serial interface of the transponder comprises no hardware handshake linesand no XON/XOFF handshake protocol is performed an error like this can occur.

Example of a message having an error in the block counter but a correctly calculated checksum:$E#R22 00735ABCDEFGHIJKLMNOPQRSTUVWXYZXXABCDEFGHIJKLMNOPQRSTUVWXYZ*05

The same message having the block counter manually corrected and checksum re-calculated:$E#R22 0073535ABCDEFGHIJKLMNOPQRSTUVWXYZXXABCDEFGHIJKLMNOPQRSTUVWXYZ*03

Faultless reference message, 2 messages earlier, block counter ok, checksum ok.$E#R22 0073533ABCDEFGHIJKLMNOPQRSTUVWXYZXXABCDEFGHIJKLMNOPQRSTUVWXYZ*05

A comparison shows that the only difference between the received message having an error in theblock counter and the message manually corrected is the block counter. Everything else istransmitted successfully.



3.2.2.7. Results - Dynamic

For the dynamic part of the test recordings were made from mobiles driving around the Frankfurtairport area. The recordings were made with an SQL Log-device, connected to the Frankfurt localserver.

Figure 10 shows a plot of all positions made by vehicles in the designated test period 1998-09-17 ⇒1998-09-24, superimposed on a map of the airport. A total of 359677 positions were recorded. Thefigure also shows the selected areas A to G identified by white circles, which were subject to thecompleteness study. The white cross indicates the location of the BaseStation.

Figure 10 - Showing areas A-G in Frankfurt used for completeness study



A centre (lat/lon) and radius (m) identify the areas A-G, which has different characteristics.

Area Parametersr=Range from Centrex=Centre latitudeWGS84,y=Centre longitude WGS84

Comment

A x= 50.036570y= 8.527895r= 200 m

Area A is located far from the BaseStation with severalbuildings obstructing the line of sight. This area is notexpected to be in full VHF coverage, but it will be interestingto see how the system performs for this type of area.Area type: REMOTEExpected position loss due to coverage: High

B x= 50.035971y= 8.535873r= 200 m

Area B is similar to A, but should have a slightly better viewtowards the BaseStation.Area type: REMOTEExpected position loss due to coverage: Medium to High

C x= 50.047798y= 8.566732r= 50 m

Area C is quite small and is located behind a large gateconstruction. The area is not expected to be in full VHFcoverage, but it is typical for most airports.Area type: GATE/TERMExpected position loss due to coverage: High

D x= 50.046592y= 8.569580r= 80 m

Area D is a typical example of a generic GATE/TERM arealocated just behind a major gate construction (as seen fromthe BaseStation).Area type: GATE/TERMExpected position loss due to coverage: Medium

E x= 50.048197y= 8.590459r= 150 m

Area E is an apron area close to the BaseStation, with line ofsight to the VHF antenna. This is expected to be in full VHFcoverage. The completeness will thus be taken as expressionfor the link reliability.Area type: RWY/TWYExpected position loss due to coverage: Low

F x= 50.039327y= 8.589150r= 600 m

Area F is an example of the generic RWY/TXY area. Thisarea is also expected to be in full VHF coverage of theBaseStation.Area type: RWY/TWYExpected position loss due to coverage: Low

G x= 50.029948y= 8.556355r= 100 m

Area G represents both a REMOTE and RWY/TXY area, butis expected to be in coverage.Area type: REMOTE, RWY/TWYExpected position loss due to coverage: Low



Due to a problem in the network configuration (or possibly a problem in the server software) thelogged data contained too many illegal duplicates and had to be pruned. (See ‘3.2.2.8. Error Sources’,p.38)

For the areas A-G, VehicleTracks were isolated and the completeness was calculated for each track foreach area. The figures below show the isolated tracks, and calculated completeness. Only a fewselected labels are included showing transponder ID, ADS-B position completeness and TRPOD(2).

Details regarding the individual tracks can be found in appendix A.

Figure 11 shows all the tracks going through area A superimposed on a map of Frankfurt airport.

F237a

F236a

F237F238F238a

F239

a

F23

F234

F235F235a

F236

X

A

#APT-276/89

#V-8482/100

#V-8574/96

Figure 11 - Showing vehicle tracks for area A, Frankfurt Airport

For area A, 8 track segments with a total of 196 positions were included and analysed in thespecified period. The overall ADS-B completeness of all tracks is 85.2%. TRPOD(2) = 98.1%.



Figure 12 shows all the tracks going through area B. Only selected track labels are shown.

F233

V176V177V178

F231

F232

V175

V174

T

L A

#V-8493/93

#APT-286/100

#V-8484/83

#APT-289/100

#V-8590/100

#V-8485/95

#V-8585/100

Figure 12 - Showing vehicle tracks for area B, Frankfurt Airport

For area B, 21 track segments with a total of 481 positions were included and analysed. The overallcompleteness of all tracks is 90.6% and the TRPOD(2) is 97.3%.

Only two tracks fulfilling the criteria were found going through area C. Figure 13 shows these.

A

A14

A16

C#V-8594/100

#V-8576/92

Figure 13 - Showing vehicle tracks for area C, Frankfurt Airport

The overall completeness of all tracks in area C is 85.4% and the TRPOD(2) is 96.0%.



Figure 14 shows the tracks going through area D.

A21

A17

A19 B22

B24

B25

B26

#V-8578/100

#V-85100/100

#V-8581/92

#V-8579/91

Figure 14 - Showing vehicle tracks for area D, Frankfurt Airport

For area D, 4 track segments with a total of 75 positions were included and analysed. The overallcompleteness of all tracks is 86.2% and the TRPOD(2) is 95.8%.

Figure 15 shows the tracks going through area E.

V117V113

V115

V116V118

V107V109

V111

V106V108

V110V112

V114

#V-84100/100

#V-85100/100

#V-8481/100

#KPK006486/100

#V-8592/100

#V-8594/100

#V-8550/86#V-8486/100

Figure 15 - Showing vehicle tracks for area E, Frankfurt Airport

For area E, 22 track segments with a total of 470 positions were included and analysed. The overallcompleteness of all tracks is 86.1% and the TRPOD(2) is 98.4%.



Figure 16 shows tracks going through area F.

D#APT-278/100

#APT-274/96

#APT-277/100

#APT-286/100

#APT-294/100

#APT-250/97 #APT-2

76/92#V-8486/100

#KPK006488/89

#KPK006492/100

#V-8484/100

#APT-294/100

Figure 16 - Showing vehicle tracks for area F, Frankfurt Airport

For area F, 32 track segments with a total of 1161 positions were included and analysed. Theoverall completeness of all tracks is 86.8 % and the TRPOD(2) is 98.7%.

Figure 17 shows the tracks going through area G.

H 432

14 - 301

#V-8489/78

#V-84100/100

#APT-279/100

#APT-2100/100

#V-8589/100

Figure 17 - Showing vehicle tracks for area G, Frankfurt Airport

For area F, 5 track segments with a total of 101 positions were included and analysed.The overall completeness of all tracks is only 93.5% and the TRPOD(2) is 95.6%.



Figure 18 illustrates the overall ADS-B track completeness for all areas.

Track completeness, Area A-G

0

10

20

30

40

50

60

70

80

90

100

110

120

Com

plet

enes

s (%

)

Area A Area B Area C Area D Area E Area F Area G

Figure 18 - ADS-B track completeness, area A-G, Frankfurt airport

Table 6 shows a summation of the calculated track completeness for the different areas.

AreaA B C D E F G

Total # tracks 8 21 2 4 22 32 5Positions in track 196 481 35 75 470 1161 101Total track time (s) 229 530 40 86 545 1338 107Expected Loss High Medium/

HighHigh Medium Low Low Low

Rcomplete (%) 85.2 90.6 85.4 86.2 86.1 86.8 93.5TRPOD(2) (%) 98.1 97.3 96.0 95.8 98.4 98.7 95.6Table 6 - Completeness for all areas, using all tracks

For area E and F a higher completeness was expected, due to the relative free placement seen inrelation to the BaseStation antenna.




For the static part of the test the data link reliability was evaluated for the transmission between amobile transponder and a BaseStation within a full coverage area. Two error sources were foundduring the test:

• The first error source is the serial interface of the R2 transponder used in the test. Some datagiven to the serial interface of the transponder were disturbed by the input buffer. This wasinvestigated using the checksum, which was calculated by the transponder after passing theinput buffer. The error rate is caused by the malfunction of the input buffer. The input bufferneeds to be improved by using professional equipment. Therefore the error rate caused by theinput buffer is not important for the assessment of the technology.

• The second error source is caused by the transmission via the radio link. During the test only acombined error rate was calculated. The derived error rates for each error source could not becalculated.

The dynamic part of the test had the following problem: Upon initial examination of the logged data, aproblem was detected. It appeared that the Frankfurt data contained many duplicate ADS-B positions.This was most likely caused by a very complex configuration used in Germany, with both old DOS-based NEAN servers and newer NT based LS/SDS servers intended to improve PETAL services.However, positions were 'bounced back' to the Local Server in Frankfurt and logged as incoming.Removing duplicates from the log-file solved the problem; however, this did also eliminate legalduplicates, which occasionally are generated by the R2 transponders and thus implies that Rcompletecould be higher than calculated.



3.2.3. R3: Static Ground Position Accuracy

Identification R3Name Static Absolute Position Accuracy for Ground VehiclesResponsible DANT/SLV, GERT/DFS

Data Acquisition Period 1998-10-01 ⇒ 1998-10-02 DANT1998-09-01 ⇒ 1998-09-02 GERT

Recorded on Sensor BaseStation Frankfurt (EDDFB01)SLV headquarter, Copenhagen

3.2.3.1. Objectives

The objective of this test was to determine the horizontal position accuracy for a ‘fixed-mobile’.


FixedMobile A mobile transponder operating as a mobile but fixed to a certain location witha non-moving GPS antenna on a surveyed position with known WGS84coordinates.

Dist(A,B)WGS84 Distance between two (Latitude, Longitude)WGS84 points on the WGS84Ellipsoid. Calculated using algorithm from [5].

Stability Deviation from the mean value

Accuracy Deviation from a reference point

Centre Position Position defined by the mean values of latitude and longitude

LatResolution The transponder resolution in latitude

LongResolution The transponder resolution in longitude

3.2.3.3. Test Description and Setup

Mobile transponders were used to obtain a measure of the absolute horizontal accuracy. Themobiles were fixed at surveyed points with known WGS84 coordinates. Position reports from atleast 24 hours were logged and analysed statistically with respect to the known reference position.The test was performed in both Copenhagen and Frankfurt by the Danish and German teamrespectively.

Danish Setup:A fixed mobile was mounted on the roof of the SLV headquarter/Copenhagen within an 8 kmdistance of the Kastrup airport from where differential GPS corrections were received.Position reports were logged directly from the fixed mobile for a period of about 36 hours(November 1st and 2nd, 1998) (~127000 ADS-B reports) and analysed with respect to the knownposition of the mobile.



German Setup:The mobile transponder #GEB101was placed on the roof of building no. 101 at Frankfurt Airport.For the VHF communication a 5/8 Lampda magnet antenna was connected. The mobile GPSmagnet antenna was placed on a reference position on the roof of the building. The position reportsbroadcast from the mobile transponder were received by the BaseStation at the airport. TheBaseStation was placed on the roof of building 173 B, in a line-of-sight distance of 1010 meter tothe mobile transponder. The BaseStation was generating and broadcasting differential correctionmessages every 4 seconds.Position reports sent out from the fixed mobile transponder were received by the BaseStation. Usingthe Frankfurt local server, position reports received by the BaseStation were forwarded to the SQLdatabase running on a PC at the DFS experimental centre in Langen.




Prerequisite1 Position reports with navigation mode less than 5 (i.e. no corrections received orused are excluded in the computations).

Prerequisite2 The test has to be run in a real airport environment to give realistic results,including all error sources.

Assumption1 It is assumed that the BaseStation - from where the differential corrections arereceived - is operating normally during the test. Non-corrected positions from thefixed mobile will be excluded.


The test will produce horizontal and vertical position plots and distribution diagrams showingdeviations from the reference position, and a concluding measure of the achieved accuracy.



3.2.3.6. Results – Danish test

The original data set consisted of about 127000 ADS-B reports. Among these, reports containingnegative heights were detected:

19981101201311,1#DCAAV01$1#DCAAV01032F31600B76DF00024FFFFF13300*01

The negative heights were only seen this once and the reason for their appearance is still notdetermined. Before plotting and statistical analysis, they were filtered out.Plotting and statistics were performed in Excel, and since Excel has the capacity of showing up to32000 points in one series, only every fourth position report is shown in the diagrams.Statistics were made on datasheets containing every third of the original data set (i.e. 42261 records- giving a tolerable processing time). Statistics made on 42261 data records was compared to resultsobtained using simple statistics on all ~127000 reports. The reduced data set was foundrepresentative and is therefore used in the following.

Figure 19 is a position plot showing latitude and longitude of the fixed mobile. All positions areshown, this means that position reports with no DGPS corrections are included.

) - Recorded positions from the fixed mobile transponder.4 - Reference position.

55,6504

55,65045

55,6505

55,65055

55,6506

55,65065

55,6507

55,65075

12,521775 12,5218 12,521825 12,52185 12,521875 12,5219 12,521925 12,52195 12,521975 12,522

Longitude (degrees)

Latit

ude

(deg

rees

)

Figure 19 - Horizontal positions (all points)

In the upper part of the diagram, “wandering” positions illustrates the effect of SA (SelectiveAvailability), when positions are not corrected.



50

60

70

80

90

100

110

120

130

140

12,52179 12,52184 12,52189 12,52194 12,52199

Longitude (degrees)

Hei

ght (

feet

)

Figure 20 - West-east plot of heights (all points)

Figure 20 is a plot of height (in feet) as function of longitude. Like in Figure 19, position reportswith no DGPS corrections are included.

In the two following plots only DGPS corrected position reports are included:

55,65041

55,65043

55,65045

55,65047

55,65049

55,65051

55,65053

55,65055

55,65057

55,65059

55,65061

12,52179 12,52184 12,52189 12,52194 12,52199

Longitude (degrees)

Latit

ude

(deg

rees

)

Figure 21 - Horizontal positions (only corrected positions shown)



50

60

70

80

90

100

110

120

130

140

12,52179 12,52184 12,52189 12,52194 12,52199

Longitude (degrees)

Hei

ght (

feet

)

Figure 22 - West-East plot of heights (only corrected positions shown)

In Figure 19 and Figure 21, the transponder’s horizontal position resolution is seen. The resolutionis in latitude: 1/1000 minutes ~ 1,85 m and in longitude: 1/1000 minutes ~ 1,04 (cf. 3.2.3.8 ErrorSources). The vertical resolution is only one foot since positions are logged directly from the mobiletransponder.

In the following table the results from the statistics performed in Excel (on the reduced data set of~42200 position reports) are listed:

Test Results DANTReference position 55,650476°N

Mean value 55,650479°NMaximum value 55,650533°NResultsMinimum value 55,650433°N

Standard deviation 1,432 meter

Latitude

Mean deviation from reference latitude -0,298 meterReference position 12,521867°E

Mean value 12,521868°EMaximum value 12,521950°EResultsMinimum value 12,521800°E


Longitude

Mean deviation from reference longitude -0,077 meterReference height 29,104 meter

Mean value 27,54024 meterMaximum value 38,40527 meterResultsMinimum value 15,84979 meter


Height

Mean deviation from reference height -1,5636 meterMean value 1,532 meterMaximum value 7,044 meterResultsMinimum value 0,815 meter

Horizontal distancefrom reference point




The standard deviation of the latitude is 1,43 meter and of longitude 0,95 meter, both within thetransponder’s resolution. In height, the standard deviation is 2,36 meter, and the maximumdeviation in height from the reference point is about 13 meters.

In the following, the reduced data set of 42261 position reports is used in diagrams to illustrate theposition deviation from the known reference point. The data set covers about 25 hours of loggeddata from where position reports with negative heights and all non-DGPS-corrected position reports(i.e. position reports having Nav Mode ≤ 3) were filtered out; finally every fourth report is plotted.

Latitude Deviation

Figure 23 - Deviation from reference latitude

In Figure 23 the latitude deviations are seen as discrete layers of points. All positions are within 6meters from the reference in latitude.



Figure 24 - Latitude deviation - positions counted

Half of the positions (52,2 %) deviate 0,814 meter from the reference latitude and 94,4 % of thepositions do not deviate more than 2,67 meter.



Longitude Deviation

Figure 25 - Deviation from reference longitude

Figure 26 - Longitude deviation - positions counted

As in the latitude plots, longitude plots show a discrete layering of points. Almost half of thepositions are only 0,02 meter wrong in latitude and 90,1 % less than 1,07 meter.



Horizontal Distance

A measure of the horizontal distance from the reference was formed combining latitude andlongitude deviations.

Figure 27 - Horizontal distance from reference point

Figure 28 - Horizontal distance - positions counted

No positions are farther from the reference than 7,5 meters, and 76,4 % are closer than 1,5 meter.



Height Deviation

Figure 29 - Deviation from reference height

Figure 30 - Height deviation - positions counted

All positions fall in the interval from –8 to 13 meters in height from the reference point. Only 7,6 %of the positions are more than 5 meter off in height.



ref. pos.50,0514468

8,594961

centre pos.50,0514486 8,5949531

deviation 0,60 meter

3.2.3.7. Results – German test

Test ResultsReference Position 50,0514468°

Mean value 50,0514486°Maximum value 50,0517667°ResultsMinimum value 50,0512333°


Latitude

Maximum deviation from mean value 35,348 meterReference Position 8,5949610°

Mean value 8,5949531°Maximum value 8,5951833°ResultsMinimum value 8,5947167°

Standard deviation 4,270 Meter

Longitude

Maximum deviation from mean value 25,677 Meter

The standard deviation for latitude and longitude is in the range of 4 to 5 meters, which is inside theexpected value range. But the maximum deviation from the mean value is clearly outside of theexpected value range: 25 meters for longitude and 35 meters for latitude. The reason for this largedeviation could not be found with the test environment. As stated in the objectives of the test it wasnecessary to run the test in an 'real' airport environment to obtain realistic results. The reason for thelarge deviation may be found in error sources produced by the airport surrounding or related to GPShardware/software malfunction.

A centre position can be defined as the position with the mean values of the measured latitudes andlongitudes.

Deviation from reference positionReference Position Centre Position distance [meter]

reference position !" mean positionLatitude 50,0514468° 50,0514486° 0,20Longitude 8,5949610° 8,5949531° 0,56

The distance between the centreposition and the referenceposition is approximately 0,6meter. The following evaluationresults are based on deviationsfrom the centre (or mean) positioninstead of including the offsetfrom the reference position.



Latitude Deviation

Figure 31 - Distribution of latitude deviation

The latitude deviation is presented in 2 graphs. The first graph presents the distribution of thedeviation. As stated before, the standard deviation is 4,9 meter, the maximum deviation is 35 meter,both referring to the mean value.

The deviation over time is shown in the second graph with a time period of 24 hours.

Figure 32 - Distribution over time



Longitude Deviation

As with latitude, the longitude deviations are presented in two graphs. The first graph presents thedistribution of the deviation. The standard deviation of the longitude is 4,3 meter, the maximumdeviation is nearly 26 meter referring to the mean value.

Figure 33 - Distribution of longitude deviation

The deviation over time is shown in the second graph with a time period of 24 hours.

Figure 34 - Deviation over time



Radial Deviation from Centre Position

Merging the results from the latitude and longitude deviation, the radial deviation from the centreposition was evaluated. The distribution of the deviation is presented in the first graph.

0

500

1000

1500

2000

2500

3000

0 5 10 15 20

radial deviation from mean value [meter]

amou

nt

Figure 35 - Distribution of radial deviation

The radial deviation over time is presented for 24 hours in Figure 36. As expected the value for theradial deviation is larger than the longitude and latitude deviation. The maximum deviation is 37,66meter.

Figure 36 - Radial deviation over time

Radial DeviationStandard deviation 3,93 meterMaximum deviation from centre position 37,67 meter



The presentation over the time axis is used to investigate the reasons for the large deviation. Onepossible solution that had to be checked was the position error caused by the update rate of thecorrection messages.

The position accuracy is based on the use of differential GPS correction messages. These messageswere sent out by the BaseStation at Frankfurt airport every 4 seconds. Within the time frame of4 seconds, the position accuracy decreases, because for the calculation of the correct position an"old" correction information is used. Although this error source is present every time, the positionerror should be very small.

If the life time of a deviation is shorter than 4 seconds, the deviation could be caused by the reducedupdate rate for differential GPS messages. Figure 37 shows a presentation over time in a time frameof 20 minutes. The time for a deviation of more than 30 meters (the largest deviation in the figure)is longer than 1 minute. Within this time frame more than 15 differential GPS messages werereceived by the transponder. Therefore, the large deviation could not be caused by the update rate ofthe differential GPS correction messages.

Figure 37 - Radial deviation over time




The deviations from the reference points, as found in the test can be caused by a list of error sources:

• Malfunctions of the transponder software.• Inaccuracy of the built-in GPS receiver.• Multipath effects at the mobile resulting in erroneous positions even if they are differential

corrected.• Multipath effects at the reference station resulting in erroneous differential corrections.• R2 mobile transponders were used. Instead of giving the ellipsoid (WGS84) height, they

produce an orthometric height (height above mean sea level) using a geoid model. This modelhas to be very precise in order not to introduce height biases.

• Limitations of accuracy by the STDMA format.All position diagrams in this test shows a discrete distribution of positions. The discreteness iscaused by the maximal system resolution limited by the STDMA format.In the STDMA format, latitude and longitude are transmitted with a resolution of 1/1000 minute(=1/60000 degree).By definition, 90º along one of the Earth’s meridians equals a distance of 10000 km on the surface,this gives a resolution in latitude of:

LatResolution: mkm 85,16000090

10000deg60000

1min1000

1=

⋅≈=

The resolution in longitude depends on latitude:

LongResolution(lat.): 6000090

.)cos(10000deg60000

1min1000

1⋅

⋅≈=latkm ,

this gives a resolution in longitude in Frankfurt of:

LongResolution(50º)= m19,1 ,

and in Copenhagen:

LongResolution(56)= m04,1

Because of the horizontal position resolution, the highest achievable accuracy will be limited to onehalf of the resolution, which in latitude is 0,93m. In longitude, the highest achievable accuracy dueto resolution is in Frankfurt 0,60m and in Copenhagen 0,52m.



Figure 38 - Latitude-longitude presentation (Frankfurt)



3.2.4. R4: Dynamic Relative Position Stability

Identification R4Name Dynamic Relative Position Stability for Ground VehiclesResponsible GERT/DFS

Data Acquisition Period 1998-10-01 ⇒ 1998-11-08Recorded on Sensor BaseStation Frankfurt (EDDFB01)

3.2.4.1. Objectives

The current Surface Movement Guidance and Control Systems (SMGCS) are not always capable ofsupporting ground movement operations on aerodromes in order to maintain the required capacityand safety levels, especially under low visibility conditions. Therefore Advanced SurfaceMovement Guidance and Control Systems (A-SMGCS) are developed. The purpose of this test wasto examine the relative position stability for Ground Vehicles in motion in an assumed full VHFcoverage area.


VehicleTrack VehicleTrack = Graph showing the movements of a ground vehicle overlaidon an airport map.


A mobile GNSS transponder was mounted on the Frankfurt airport 'people mover' that follows thesame track repeatedly between terminal A and terminal B. ADS-B position reports were collectedand analysed with respect to deviations from the assumed track.



The mobile transponder was installed in train #16. A GPS antenna was mounted on the top of thetrain and a VHF antenna was mounted on the front side. The train was driving on a regulartimetable between terminal A and terminal B of the airport.

Figure 39 - The People Mover train at Frankfurt Airport

The Frankfurt BaseStation received the position reports broadcast by the mobile transponder. For 4days the position reports were recorded in an SQL database installed in the DFS experimentalcentre in Langen.

The mobile transponder installed in the people mover train received differential correctionsbroadcast by the Frankfurt BaseStation.


Assumption1 Assume that the route taken by the Ground Vehicle is in a full VHF coveragearea.


The test will produce statistical data of the stability of positions originating from a moving vehicle.The statistical data will be presented in latitude/longitude graphs and as functions over time.

3.2.4.6. Results

To ensure that the train was in full GPS and VHF coverage only a small part of the track is used forthe evaluation. For the statistical part of the evaluation three geographical slots were defined:

Slot Mean Value Slot WidthSlot 1 8°34’37’’ (=8.577°) 0.6’’ (≈ 18.5 meter)Slot 2 8°34’48’’ (=8.580°) 0.6’’Slot 3 8°34’55’’ (=8.582°) 0.6’’Table 7 - Geographical Slot Definition



The people mover train drives on two tracks. The northern track is used for direction east to west;the southern track is used for the direction from west to east. The ADS-B reports received by theBaseStation had been separated into these tracks. For this purposes the heading information of theADS-B reports was used.

For statistical and graphical evaluation only valid position reports were used, these had to meet thefollowing conditions:

• full GPS navigation (3 dimensional GPS positions)• correct reception of Differential GPS corrections transmitted by the Frankfurt BaseStation

A NavMode status byte included in the position report message of the transponder was used tocheck the compliance with these conditions. Therefore only position reports reporting NavMode = 5(differentially corrected 3D GPS positions) were used for the evaluation.

Figure 40 - Track of the people mover at Frankfurt airport



Figure 41 - Two tracks of the people mover at Frankfurt Airport

Figure 42 - Geographical slots for statistical evaluation

The statistical evaluation was done separately for the northern and the southern track using positionreports recorded over a period of 4 days. The people mover train was driving in alternatingdirections on both tracks.



Slot 1 Slot 2 Slot 3Minimum Value [°] 50,0511 50,0505333 50,0508167Maximum Value [°] 50,0512 50,0506833 50,05105Mean Value [°] 50,05116 50,0505833 50,0509346Standard deviation [meter] 2,77 3,81 4,43

Latitude

Maximum deviation [meter] 6,67 5,56 13,11Table 8 - Statistical Evaluation of southern track

Figure 43 - Statistical distribution of ADS-B reports - southern track



Figure 44 - Statistical distribution of ADS-B reports - northern track

Slot 1 Slot 2 Slot 3Minimum Value [°] 50,0511333 50,0502 50,0508667Maximum Value [°] 50,05125 50,05125 50,0510333Mean Value [°] 50,0512056 50,0506333 50,0509667Standard deviation [meter] 2,77 3,81 4,43

Latitude

Maximum deviation [meter] 8,03 65,53 10,40Table 9 - Statistical Evaluation of northern track

In Figure 44 a sudden deviation of ADS-B reports from the northern track is seen (cf. Table 9, slot2). The reason for this deviation could not be found with the test equipment, but a likely explanationis multipath of the GPS signals resulting in miscalculated positions by the GPS receiver. Multipathcaused by nearby airport buildings at either (or both) the mobile transponder or the BaseStationcould give the seen result




The position accuracy in a 'real' airport environment is influenced by different error sources:

• Transponder resolution in position (See test 'R3:Static Ground Position Accuracy')• Multipath effects on the GPS signals caused by the airport buildings.• Malfunction of the GPS receiver software resulting in miscalculated positions.• Radio link distortion: The reception of differential corrections or the broadcast of position

reports is influenced by error sources caused by other airport users

By comparing the results from the Dynamic Relative Position Stability test (R4) with the resultsfrom the Static Ground Position Accuracy test (R3) no additional error sources were found. Thedeviation from an expected position value has the same range in both tests.



3.3. Coverage Tests

3.3.1. C1: Air-Ground VHF Long Range Coverage

Identification C1Name Air-Ground VHF Long Range CoverageResponsible DANT/SLV for Danish stations

GERT/DFS for German Stations

Data Acquisition Period 1998-10-01 ⇒ 1998-11-08 DANT1998-10-27 ⇒ 1998-10-29 GERT

Recorded on Sensor Danish and German GroundStations

3.3.1.1. Objectives

The purpose of this test was to determine the long-range VHF Coverage for all NEAN GroundStation locations in terms of outer boundaries of the coverage area. This was done by looking atwhen ground stations first saw incoming A/C and when they ‘lost contact’ with them again.


ExcludeHeight Denotes a minimum height for an A/C position to be considered as an A/C-Entry/Exit point.

A/C-Entry-Point An A/C-Entry-Point denotes a point (latitude, longitude)WGS84, where atransmitted ADS-B position report from an A/C was first detected by aGround Station sensor. A potential A/C-Entry-Point is subject to thefollowing restrictions:1. Only when entryGuard number ADS-B reports were counted is the next

report said to be an A/C-Entry-Point. (entryGuard =1,2,...)2. If the height of a potential A/C-Entry-Point was above the ExcludeHeight

it is said to be an A/C-Entry-Point

A/C-Exit-Point An A/C-Exit-Point denotes a point (latitude, longitude)WGS84 , where atransmitted ADS-B position report from an A/C was ‘lost’ (i.e. no longerseen) by a ground station sensor. A potential A/C-Exit-Point is subject to thefollowing restrictions:1. Only when no reports were detected for staleTime seconds the last seen

report was counted as an A/C-Exit-Point. (staleTime =10,11,...)2. If the height of a potential A/C-Exit-Point was above the ExcludeHeight

it is said to be an A/C-Exit-Point

ApproxVHFRange ApproxVHFRange [m] = 1852*123. * h , where h is the height in feet.This was used for approximation of the theoretical coverage withoutconsidering terrain data.



SENSORS SENSORS denote the set of BaseStations around which A/C-Entry/Exit-points were calculated.

SENSORSGERT = {Frankfurt (EDDFB01), Köln/Bonn (EDDKB01), Bremen(EDDWB01), Braunschweig (EDVEB01)}

SENSORSDANT = {Kastrup(EKCHB01), Aalborg(EKYTB01), Billund(EKBIB01), Esbjerg(EKEBB01), Tyra East(EKGFB01)}


The long-range VHF Coverage for the STDMA equipped A/C was examined by collecting ADS-Bposition data from individual BaseStations in SENSORSDANT and SENSORSGERT and calculating A/CEntry/Exit points as defined in 3.3.1.2 for aircraft, when they entered or left the area.

The following values were used in the Entry/Exit point determination.

Parameter Value CommentstaleTime [s] 300 The number of seconds to pass before

the last seen position was declared anA/C-Exit point.

filterHeight [ft] 5000 Minimum height below which, potentialA/C-Entry/Exit points were filtered out.

entryGuard 25 Minimum number of ADS-B positionreports to be received before the pointwas declared an A/C-Entry point.

Table 10 - Entry/Exit point parameter values

Whenever an A/C-Entry/Exit point was detected during the offline processing, the following wasregistered:

• Geographical location (latitude/longitude) WGS84

• Height [ft] above mean sea level.• Distance [NM] [1] to the SENSOR recording the position• ApproxVHFRange to the SENSOR recording the position• Timestamp (YYYYMMDDHHMISS) when position was logged



Figure 45 shows the generic test setup. Individual TCP transport level connections (reliable andsequenced) between the log server and the local servers are shown as dotted lines.

Transponder

NEAN NetworkSegment

Sensor

Sensor

Log Server

NEAN Station

GNSS/STDMA equipped A/C

NEAN Station

Transponder

Figure 45 - Test setup with connections to individual sensors

No special test-flights were carried out. The test relied on ordinary flights by GNSS equipped A/C.


Reliable and sequenced transfer was assumed for the connections between the GroundStations andthe log server.


As a result the test will produce:

1) Maps for the area around each ground station sensor with the A/C-Entry/Exit-points plotted.2) Calculated WGS84 distances [5] (between GroundStation sensor and AC-Entry/Exit point) as

function of height, including an approxVHFRange.



3.3.1.6. Results

As a whole, the project demonstrated a significant ADS-B coverage area in Northern Europe with17 GroundStations. Figure 46 shows a sample of the recorded flights in the NEAN coverage area.

Figure 46 - Sample of recorded flight within the NEAN coverage area

The following set of figures shows the long-range coverage from Danish and German GroundStationson a geographical map with the A/C-Entry/Exit points plotted (A/C-Entry point='X', A/C-Exit point='+'). Lines from the Entry/Exit point to the ground station are drawn for better visualisation of thecoverage. These lines do not represent individual flights. It is important to note that areas without A/C-Entry/Exit points do not necessarily indicate lack of coverage, but rather areas without flights.



Figure 47 shows the coverage map from Frankfurt (EDDFB01). In total 310 A/C-Entry/Exit pointswere recorded during the period from 1999-02-11 to 1999-02-22.

Figure 47 - Long range VHF coverage from Frankfurt (EDDFB01)

Figure 48 shows the coverage map from Köln/Bonn (EDDKB01). In total 242 A/C-Entry/Exit pointswere recorded during the period from 1998-12-18 to 1998-12-23.

Figure 48 - Long range VHF coverage from Köln/Bonn (EDDKB01)



Figure 49 shows the coverage map from Bremen (EDDWB01). In total 135 A/C-Entry/Exit pointswere recorded during the period from 1998-12-18 to 1998-12-23.

Figure 49 - Long range VHF coverage from Bremen (EDDWB01)

Figure 50 shows the coverage map from Braunschweig (EDDVB01). Only scarce data from a singleday (1998-10-29) were available from the Braunschweig station for this test.

Figure 50 - Long range VHF coverage from Braunschweig (EDDVB01), 1998-10-29



Figure 51 shows the coverage map from Kastrup Airport (EKCHB01). In total 925 Entry/Exit pointswere recorded during the period from 1998-10-01 to 1998-11-08. The VHF antenna in Kastrup airportis located at approx. 45 m above mean sea level.

Tyra East(EKGF) Børsmose

(EKEBB02)

Esbjerg(EKEBB01)

500 25

Kilometers

Billund(EKBI)

Aalborg(EKYT)

Copenhagen(EKCH)

0 100

Kilometers

200

FL0

FL55

FL63

FL68

FL74

FL76 FL89

FL98 FL146FL154

FL167

FL172

FL175

FL177

FL198

FL199

FL207

FL208

FL222

FL222

FL226FL241

FL244FL248

FL259

FL267

FL275

FL279

FL282

FL284

FL288

FL309

FL319

FL320

FL326

FL332

FL345

FL356

FL371

Figure 51 - Long range VHF coverage from Kastrup (EKCHB01)

Figure 52 shows the coverage map from Aalborg Airport (EKEBB01). In total 862 Entry/Exit pointswere recorded during the period 1998-10-01 to 1998-11-08. The VHF antenna height in Aalborg isapprox. 20 m above mean sea level.




(EKEBB02)

Esbjerg(EKEBB01)

500 25

Kilometers

Billund(EKBI)

Aalborg(EKYT)

Copenhagen(EKCH)

0 100

Kilometers

200

FL0FL54

FL56

FL68

FL71

FL83

FL93

FL124

FL133

FL140

FL141

FL172

FL176

FL180

FL187

FL190

FL191FL193

FL196FL236

FL253FL254

FL255 FL273

FL292

FL295

FL295

FL298

FL299

FL303

FL312

FL315

FL316

FL318

FL319

FL331

FL331

FL372

Figure 52 - Long range VHF coverage from Aalborg (EKYTB01)

Figure 53 shows the coverage map from Billund Airport (EKBIB01). In total 659 Entry/Exit pointswere recorded during the period 1998-10-01 to 1998-11-08. The VHF antenna height in Billund isapprox. 70 m above mean sea level.


(EKEBB02)

Esbjerg(EKEBB01)

500 25

Kilometers

Billund(EKBI)

Aalborg(EKYT)

Copenhagen(EKCH)

0 100

Kilometers

200

FL0FL50FL50 FL54

FL72

FL75

FL86

FL96

FL104

FL121

FL127

FL199

FL200

FL202

FL204

FL206 FL232

FL248

FL258

FL265

FL268

FL278

FL280FL282

FL286

FL293

FL299

FL300FL301

FL302

FL302

FL309

FL311 FL311

FL326

FL334

FL415

Figure 53 - Long range VHF coverage from Billund (EKBIB01)

Figure 54 shows the coverage map from Esbjerg Airport (EKEBB01). In total 478 Entry/Exit pointswere recorded during the period 1998-10-01 to 1998-11-08. The VHF antenna in Esbjerg airport is



located at approx. 42 m above mean sea level. Only EKEBB01 was examined - not Børsmose(EKEBB02) used by NEAP.


(EKEBB02)

Esbjerg(EKEBB01)

500 25

Kilometers

Billund(EKBI)

Aalborg(EKYT)

Copenhagen(EKCH)

0 100

Kilometers

200

FL0FL50FL60

FL68

FL71

FL72

FL115

FL134

FL166

FL195FL206

FL209

FL216

FL222FL242FL268

FL278

FL278

FL288

FL288

FL296

FL296

FL298

FL302

FL307FL311

FL313

FL318

FL342

FL355

Figure 54 - Long range VHF coverage from Esbjerg (EKEBB01)

Figure 55 shows the coverage map from the offshore installation Tyra East (EKGFB01). In total 748Entry/Exit points were recorded during the period 1998-10-01 to 1998-11-08. The VHF antenna heightat Tyra East is approx. 70 m above mean sea level, and the only construction 'shading' the VHFpropagation is the Tyra platform itself.


(EKEBB02)

Esbjerg(EKEBB01)

500 25

Kilometers

Billund(EKBI)

Aalborg(EKYT)

Copenhagen(EKCH)

0 100

Kilometers

200

FL0 FL50FL51

FL85

FL87

FL141

FL160

FL174

FL182

FL192

FL205

FL217

FL220

FL231

FL253

FL255

FL259

FL265

FL271

FL272

FL274

FL274FL296

FL297FL297

FL299

FL300

FL312

FL313

FL329

FL333

FL335

FL340 FL352

FL353

FL354

FL362

FL370FL370

Figure 55 - Long range VHF coverage from Tyra East (EKGFB01)



For a closer study of the VHF coverage, graphs showing the measured range to the GroundStation andapproximated theoretical range as function of measured height were also produced for selectedGroundStations. This provides good visualisation of the optimal coverage versus the measured.

Figure 56 shows the Range/Height graph for Esbjerg (EKEBB01).

EKEB: All flights

0

50

100

150

200

250

300

5008

5712

7600

1142

413

04016

272

1766

420

784

2163

223

600

2547

227

08827

904

2880

029

376

2987

230

512

3102

431

200

3132

831

552

3187

232

09632

736

3299

233

200

3336

033

456

3395

234

496

3512

035

568

Height(ft)

Ran

ge (N

M)

Measured points Theoretical

Figure 56 - Long range VHF coverage from Esbjerg - Range/Height

This figure indicates problems with the installation in Esbjerg (EKEBB01), since the majority of themeasured ranges lie well below the optimal. During the test period several problems with theEsbjerg installation were also detected (faulty cables, etc).



Figure 57 shows the similar Range/Height graph for Tyra East (EKGFB01).

EKGF: All flights

0

50

100

150

200

250

300

5040

1720

018

41620

14421

76023

82425

47226

30427

16827

80828

41629

28029

74429

95230

17630

48030

78431

02431

13631

26431

37631

55231

77632

27232

97633

34433

60034

22435

16835

53636

49637

21637

664

Height(ft)

Ran

ge (N

M)


Figure 57 - Long range VHF coverage from Tyra East - Range/Height

This figure indicates a good coverage from Tyra. Most of the recorded ADS-B position reports arefound in the vicinity of the optimal.



Similar figures (Figure 58 to Figure 64) are presented for Billund (EKBI), Aalborg (EKYT),Kastrup (EKCH), Frankfurt (EDDF), Köln/Bonn (EDDK), Bremen (EDDW) and Braunschweig(EDVE).

EKBI: All flights

0

50

100

150

200

250

300

5024

5504

7168

9104

1065

612

16013

00813

71214

46415

71216

91219

77621

08822

06423

44024

65625

85626

48027

16828

01628

41629

16829

68030

22430

97631

23231

56831

88832

59233

07233

44034

16035

104

Height(ft)

Ran

ge (N

M)


Figure 58 - Long range VHF coverage from Billund - Range/Height

EKYT: All flights

0

50

100

150

200

250

300

5424

7856

9696

1084

812

30413

74414

97617

07218

08018

81619

85621

74423

88824

92825

87226

62427

10427

52027

95228

36829

04029

29629

56829

95230

59231

00831

24831

68032

00032

60833

32833

71234

52837

120

Height(ft)

Ran

ge (N

M)


Figure 59 - Long range VHF coverage from Aalborg - Range/Height



EKCH: All flights

0

50

100

150

200

250

300

350

5536

7184

8560

9600

1112

014

36816

68818

41622

35224

64025

44026

06426

28826

59226

89627

15227

40827

72827

92028

19228

48028

86429

13629

39229

88830

33630

99231

31231

64832

20833

08833

44034

44837

504

Height(ft)

Ran

ge (N

M)


Figure 60 - Long range VHF coverage from Kastrup - Range/Height

EDDF: All flights

0

50

100

150

200

250

300

5840

8000

9856

1360

115

617

1632

116

705

1752

117

809

1788

918

481

2577

727

409

2798

528

993

2955

329

809

3004

930

385

3070

531

122

3155

433

042

3504

235

506

3616

236

370

3657

838

338

Height(ft)

Ran

ge (N

M)


Figure 61 - Long range VHF coverage from Frankfurt - Range/Height



EDDK: All flights

0

50

100

150

200

250

300

560059846112

620864806720

683271687456

8848

10048

11729

14785

17265

17905

18849

24513

27969

29169

29905

30065

30433

30657

30754

30978

31778

32418

32770

34322

35778

36626

36738

37170

Height(ft)

Ran

ge (N

M)


Figure 62 - Long range VHF coverage from Köln/Bonn - Range/Height

EDDW: All flights

0

50

100

150

200

250

6016

8192

16513

17249

17713

18145

20193

23841

24641

26593

26913

27601

28129

28721

29761

30401

30529

30673

30754

31826

32130

32642

34210

36370

Height(ft)

Ran

ge (N

M)

M easured points Theoretical

Figure 63 - Long range VHF coverage from Bremen - Range/Height



EDVE: All flights

0

50

100

150

200

250

572.6

1315.9

2109.4

2420.8

5409.1

5600

5871.2

5921.4

6157.5

6247.9

6649.7

6830.5

7141.9

7608.9

7709.4

7870.1

8337.2

8462.7

8477.8

8533.1

9216.1

9266.3

9427

9884.1

Height(ft)

Ran

ge (N

M)

M easured points Theoretical

Figure 64 - Long range VHF coverage from Braunschweig - Range/Height



The results are summarised Table 11. Variations in long-range coverage could be caused be severalelements, e.g. VHF antenna location, antenna properties, transponder radio, choice of antennacables, surrounding environment. The coverage assessment is seen only in relation to the optimalapproxVHFrange and does not consider the environment.

GroundStation CoverageAssessment

Comments

Kastrup (EKCH) Good Kastrup has an excellent coverage. The VHF antenna ismounted on the Kastrup Airport Tower with a clearview to all sides.

Aalborg (EKYT) Fair The Aalborg NEAN VHF antenna is the lowest in theDanish segment.

Billund (EKBI) Good Good coverage, but not optimal.Esbjerg (EKEB) Bad Bad coverage. Could be caused by the installation.Tyra East (EKGF) Good Excellent long-range coverage, but there is no

obstacles in the vicinity.Frankfurt (EDDF) Good Coverage as far as the Dutch coast is measured for high

flight levelsKöln/Bonn (EDDK) Less than

fairLarge fluctuations in the long-range coverage areobserved. Long cabling between antenna and basestation was detected.

Bremen (EDDW) Bad A consistent bad long-range coverage is detected. Theheight of this antenna installation is very low (approx.4m over GND). The antenna installation together withtopographical conditions around the base stationhampered the coverage of this base station.

Braunschweig Fair Fluctuations in the coverage.Table 11 - Long-range coverage summary




There are some problems determining Entry points for aircraft. Consider the scenario of A/C-Entrypoint detection in Figure 65:

EntryPoint

FilterHeight

EntryGuard

First detected

AC Movement

Range to Sensor

Figure 65 - Entry-point detection

If the A/C rises above the filterHeight from below, it is registered as an A/C-Entry point afterentryGuard positions have been detected. This implies that some points will be detected too close tothe sensor for the current height resulting in large discrepancies between the approxVHFRange andthe measured. The scenario occurs whenever the aircraft enters the coverage area from below thefilterHeight. Exit points do not have this problem, see Figure 66.

ExitPoint (after staleTime sec)

FilterHeight

AC Movement

Range to Sensor

Figure 66 - Exit-point detection

The last recorded point is said to be an A/C-Exit point if no other ADS-B positions are detected forstaleTime seconds. If the A/C-Exit point lies below the filterHeight, it is simply discarded. The A/C-Exit point calculation is thus not prone to the same errors as the A/C-Entry point calculation, but thecalculation is not intended to include landing sites, where the A/C drops out of VHF coverage.



MMI 5000 transponder transmission control

If the MMI 5000 is connected to the STDMA transponder the transmission of position reports isenabled only, if the aircraft is within the defined NEAN area. If the aircraft leaves the MMI 5000defined NEAN area the transmission of position reports is disabled. The decision is based on theGPS position.

Figure 67 – NEAN area

The coverage area of the German BaseStations includes also areas outside of the NEAN area.Because the coverage maps for the German BaseStations produced in this test are mainly based onposition reports from DLH Boeing 747-200 aircraft, which are equipped with the MMI 5000cockpit display system, the coverage maps are cut by the MMI 5000 transmission control function.The transmission of position reports was disabled when the aircraft had left the NEAN area. In thecoverage map this position is miss-interpreted as an exit point. When the aircraft came back to theNEAN area the transmission of position reports was enabled by the MMI 5000. In that case theposition is miss-interpreted as an entry-position.

As presented in Figure 67 the coverage maps of the BaseStations Frankfurt, Köln/Bonn, Bremenand Braunschweig are mainly cut in the eastern direction.



3.3.2. C2: Airport System Coverage

Identification C2Name Airport System CoverageResponsible GERT / DFS – Collection and processing

DANT /SLV – Additional processing

Data Acquisition Period 1998-09-09 ⇒ 1998-09-17Recorded on Sensor Frankfurt local server (EDDFLS)

3.3.2.1. Objectives

The purpose of this test was to compile and visualise information regarding the system coverage(both GPS and VHF) for Ground Vehicles operating in a 'typical' airport environment.

ADS-B position reports were collected from GNSS/STDMA equipped ground vehicles passingthrough the Frankfurt Airport environment.


VehicleTrack VehicleTrack = Graph showing the movements of a ground vehicleprojected on an airport map.

FullCoverageArea Area without Position Report Gaps longer than 3 seconds

CriticalArea Area with Position Report Gaps between 4 and 8 seconds

NonCoverageArea Area with Position Report Gaps longer than 8 seconds

ValidPositionReport Position Report which fulfils the following requirements• UTC Time Stamp between 00 and 3B (hexadecimal)• NavMode 5 (3 dimensional Differential-GPS position)




For the estimation of the airport coverage the ADS-B position reports were collected at the localserver at Frankfurt Airport during the test period. For data recording all received position reportswere registered at the SQL server running in Langen.

After locating CriticalCoverageAreas at the airport a route for a test vehicle was defined. The routehad to cross all CriticalAreas to validate the coverage area. The test vehicle drove at the pre-definedtrack with a speed limit of 30 km/h.

Using the results of both tests NonCoverage, CriticalAreas and FullCoverageAreas were located.


Because the test was done in an operational airport environment access restrictions in some areashad to be accepted.


VehicleTracks are shown superimposed on the relevant airport maps showing variations innavigation mode (Differential vs. non-Differential GPS) and VHF coverage.



3.3.2.6. Results

Figure 68 shows all recorded ADS-B position reports recorded on ground at Frankfurt Airportduring the test period.

Figure 68 - Position reports received from all vehicles and aircraft at the airport

Figure 69 - Position reports received from all vehicles and aircraft at the gate area



All position reports received by the BaseStation at Frankfurt Airport (including aircraft positionreports in the whole coverage area up to a 200 NM distance from the airport) during the test periodwere forwarded to the SQL database running in Langen. For the evaluation, only position reportsfrom the Frankfurt Airport area (altitude < 600 feet) were used.

Figure 68 and Figure 69 present a coverage map generated using the position reports from theairport cars (#V-84, #V-85, #APT-2, #KPK0064) and all aircraft at the airport. Because theLufthansa aircraft were the most frequent users, most of the position reports came from the terminalareas A and B. A possible critical area could be expected near the gates C4 to C15 due to theplacement of the BaseStation antenna. A non-coverage area could not be located using the receivedposition reports.

The airport car #KPK0064 was used as a test vehicle to verify the critical areas. The track generatedby the test vehicle is shown in Figure 70. No CriticalAreas were found in the outer areas of theairport. An expected lack of coverage at the runway 18 could not be verified.

Having a closer look at the terminal area of the airport the expected lack near the terminal area Cwas confirmed. A NonCoverageArea, which was defined as an area with position report gaps longerthan 8 seconds, was still not found during the test vehicle drive. The critical areas are marked inwhite colour in the coverage map.

Figure 70 - Position reports received from the test vehicle at Frankfurt airport



Figure 71 - Critical coverage areas at Frankfurt airport



In addition to this analysis, DANT made a study of GPS vs. DGPS for vehicles #V-84, #V-85 and#KPK0064 in the period 1998-09-17 ⇒ 1998-09-24 and 1998-09-09 ⇒ 1998-09-12. Areas withoutDifferential GPS were located and superimposed on an airport map.

Figure 72 has been filtered to show only transponder NavMode 2 and 3 (2D and 3D non-correctedpositions) for vehicles #V-84, #V-85 and #KPK0064 respectively, thus indicating areas where noDGPS is available.This result confirms the location of the CriticalAreas, to be in the gate vicinity. Of the total 220297position reports analysed only 628 (0.29%) indicated that no DGPS correction had been uplinkedsuccessfully.

Figure 72 - Areas with Navigation Mode 2 or 3 in Frankfurt Airport


• The location of NonCoverageAreas and CriticalAreas were manually performed with some errorof margin.

• Non differentially corrected position reports have a lower accuracy, so when plotted they do notnecessarily show the true position of the vehicle.



3.4. Performance Tests

3.4.1. P1: Ground Network Delay and Throughput

Identification P1Name Ground Network Delay and ThroughputResponsible DANT/SLV

Data Acquisition Period 1998-10-01 ⇒ 1998-11-08Recorded on Sensor Danish network segment

3.4.1.1. Objectives

The purpose of this test was to collect information on GroundNetwork delay times for specifiedlogical links in the NEAN network. The delay times measured were round trip times for InternetControl Message Protocol (ICMP) packets the same size as default ADS-B position reports (50bytes).

In addition to this, throughput on the physical links in the NEAN network was examined, throughSimple Network Management Protocol (SNMP) variables on the IP routers.

The Danish NEAN network segment was selected for examination due to the following:

• It contains the only regional server (Esbjerg).• It contains a satellite link for a leaf-node (Esbjerg-Tyra East).• The same server versions are running at all sites in the segment (DOS-based NEANSERV

v/3.1).• The same type of transponders is running at all sites in the segment (R2 Software v/13.9).• The Danish segment was expected to suffer the least impact from other trials (e.g. PETAL,

NEAP).

The router throughput on the international lines was also examined.


DelayTime DelayTime [ms] = Round trip time of an ICMP packet with a similar size asan ADS-B packet. The ICMP packets are generated using a standard ‘ping’utility.

LogicalLink LogicalLink = Virtual connection between a level-N NEAN Server and alevel-(N-1) server. In most cases, this will be the connection between anational server and a local server, but it could also be the connectionbetween a regional server and a local server.




The IP network on which the Danish NEAN segment relies is a sub-netted class C network, whereeach site has its own sub-net. The network is a hierarchical tree structure with a national server asroot and local servers as leaves. The national server collects and concentrates data from the localservers.All routers and NEAN servers are on the IP network level monitored by SNMP polls from a centralManagement Station (MS) and a log server (LGS) located at the Kastrup/Copenhagen IP sub-net.The logical topology of the Danish NEAN segments is shown in Figure 73. To obtain SNMP datafrom the DOS-based NEANSERV servers used in the Danish network segment a specialManagement Information Base (MIB) was developed early in the project (see Appendix C fordetails).

EKEB (Esbjerg)

EKYT (Aalborg)EKGF (Tyra)

EKCH (Kastrup)

EKCH (Kastrup)

MSNS

LS

RS

LSLS

DSLS Local Server

Display StationNS

RS Regional Server

National Server MS Management Station

NEAN Connection SNMP Connection

LGS

LGS Log Server

Figure 73 - Logical topology of Danish NEAN segment

Physically the Danish network segment is based on the Civil Aviation Network Data Interchange(CANDI) network. CANDI is a Time Division Multiplex (TDM) network, which currently offersonly Permanent Virtual Circuits (PVCs) to its users.In order to connect the North Sea production platform Tyra East, Maersk Oil & Gas has providedbandwidth on their satellite link from Esbjerg harbour to Tyra East.

Regarding the international connections, the Danish national server distributes incoming ADS-Bposition reports to the relevant neighbours. Physically these connections are realised with two point-to-point leased 64 Kbit lines connecting Sweden/Arlanda (ESSA), Denmark/Copenhagen (EKCH)and Germany/Bremen (EDDW). The IP routers at Arlanda and Bremen were made accessible forSNMP monitoring.

What was tested

A test program – pinging the servers and routers in turn – was executed at a log server (LGS) on thesame LAN segment running the top-level national server and the round-trip delay times wererecorded and logged.



SNMP data – especially octets sent/received pr. router port (both OctetsIn/OctetsOut) - were alsocollected for throughput calculations.

The actual test setup is shown in Figure 74. LS=local server, NS=national Server, DS=displaysystem, R=IP router,[2602]=backbone access point and MS=management station.The grey circles indicate which stations were IMCP pinged and the white circles indicate whichrouters/bridges were polled SNMP for this test.

LS

R

64kbps leasedline to Germany

64kbps leasedline to Sweden

Kastrup (EKCH)

Esbjerg (EKEB)

Billund (EKBI)

2602

R

LS

DS 2602

R

RS DS

B

DS

B

2602R

R NS

DS

LS

MS

26022602

CANDIDanish Backbone

TDM Network

MÆRSK PrivateFrame Relay

2602

LGS

Tyra (EKGF)

R

R

SNMP Poll

IMCP Ping

Aalborg (EKYT)

R

LS

DS 2602

Figure 74 - Test setup for the network delay/load test


Assumption1 Assume that pinging local servers from a designated server and the nationalserver would yield similar delay times, if the designated server was on thesame LAN segment as the national server.



3.4.1.5. Result Specification

The test will produce:

• Average delays (in ms) between the top-level national server and connected local servers foreach connected local server in a specified period.

• Average delay/day between the national server and a selected local server for a specified period(this should be correlated with the amount of data passing through the system).

• Throughput (bits/s) on the links in the Danish Segment, including the International Links.

3.4.1.6. Results – Network delay

10 IMCP ping packets (100 bytes long) were sent to all Danish NEAN every 20 minutes during thetest-period from 1998-10-01 to 1998-11-15 and the round-trip times recorded.

The network delay for the test period in the Danish segment is shown in Figure 75 as measured onthe four local/regional servers. Kastrup (EKCHNS), Aalborg (EKYTLS), Esbjerg (EKEBRS) andTyra East (EKGFLS) from the central national server (EKCHNS).

0

100

200

300

400

500

600

700

Del

ay (m

s)

Netdelay October (DK Segment)

ekchls ekytls ekebrs ekbils ekgfls

Figure 75 - Average network delay in the Danish segment

The shown pattern is as expected. The average delay to the Kastrup local server (EKCHLS) is verysmall, since it is situated on the same LAN as the national server and the log server. The highaverage delay to Tyra East local server is also expected, since the server is connected via a satellitelink. In total 198180 ping-messages were sent and approximately 5% were lost.



Figure 76 shows the network delay distributed on days during the test period.

Network Delay (DK Segment)

0

100

200

300

400

500

600

700

800

199

8100

1

199

8100

3

199

8100

5

199

8100

7

199

8100

9

199

8101

1

199

8101

3

199

8101

5

199

8101

7

199

8101

9

199

8102

1

199

8102

3

199

8102

5

199

8102

7

199

8102

9

199

8103

1

199

8110

2

199

8110

4

199

8110

6

199

8110

8

199

8111

0

199

8111

2

199

8111

4

Time (days)

Del

ay (m

s)

ekgfls ekbils ekebrs ekytls

Figure 76 - Average network delay for the Danish NEAN network pr. day

It is seen that the delays were fairly constant during the period. Billund (EKBI) did not come on-line until 1998-10-05 and Aalborg (EKYT) crashed around 1998-10-18.Comparing this to the availability study, it is seen that the registered 'server crashes' related to theDOS based NEANSERV software and not to the network (the IMCP ping-message only verifies theconnection to the TCP/IP stack in the server and not the application running on the server).

3.4.1.7. Results – Network load

The individual servers were examined for normal transmissions of typical STDMA messages. Table12.

ID Description$1 ADS-B position report. Own position from BaseStation. Sent to national server$2 ADS-B position report. Position of mobile in vicinity. Sent to national server$A Time message. Sent to national server approximately every 20s.$B Status message. Sent to national server approximately every 10s.$E Addressed text message. Sent to/from National server$F Link acknowledgement. Sent to national server when a text-message has been delivered

by the data-link.Table 12 - STDMA messages counted

These typical messages where counted for all Danish local/regional servers and Figure 77 to Figure81 shows the number of processed STDMA messages for the individual stations.It is observed that $2-messages (ADS-B positions) constitute the major part of the processedpackets and have the largest fluctuations. The $1-messages (Own ADS-B position), $A/$B



messages are at a constant level and the $E/$F are insignificant. A Drop in $1-messages indicateavailability problems.Aalborg is an exception, since fewer $2-messages than $1-messages were registered here. Inaddition, note that Esbjerg has a higher number of $1 messages, since two BaseStations are runningon this server. (An additional BaseStation was installed in Børsmose, at the Danish West Coast,supporting the NEAP project).

Packets sent from Kastrup (EKCHLS)

0

20000

40000

60000

80000

100000

120000

140000

199

8100

1

199

8100

3

199

8100

5

199

8100

7

199

8100

9

199

8101

1

199

8101

3

199

8101

5

199

8101

7

199

8101

9

199

8102

1

199

8102

3

199

8102

5

199

8102

7

199

8102

9

199

8103

1

199

8110

2

199

8110

4

199

8110

6

199

8110

8

199

8111

0

199

8111

2

199

8111

4

Time (Days)

Pack

ets/

day

$1 $2 $A $B $E+$F

Figure 77 - STDMA packets from Kastrup local server (EKCHLS)



Packets sent from Aalborg (EKYTLS)

0

2000

4000

6000

8000

10000

12000

199

8100

1

199

8100

3

199

8100

5

199

8100

7

199

8100

9

199

8101

1

199

8101

3

199

8101

5

199

8101

7

199

8101

9

199

8102

1

199

8102

3

199

8102

5

199

8102

7

199

8102

9

199

8103

1

199

8110

2

199

8110

4

199

8110

6

199

8110

8

199

8111

0

199

8111

2

199

8111

4

Time (Days)

Pack

ets/

day

$1 $2 $A $B $E+$F

Figure 78 - STDMA packets from Aalborg local server (EKYTLS)

Packets sent from Billund (EKBILS)

0

10000

20000

30000

40000

50000

60000

199

8100

1

199

8100

3

199

8100

5

199

8100

7

199

8100

9

199

8101

1

199

8101

3

199

8101

5

199

8101

7

199

8101

9

199

8102

1

199

8102

3

199

8102

5

199

8102

7

199

8102

9

199

8103

1

199

8110

2

199

8110

4

199

8110

6

199

8110

8

199

8111

0

199

8111

2

199

8111

4

Time (Days)

Pack

ets/

day

$1 $2 $A $B $E+$F

Figure 79 - STDMA packets from Billund local server (EKBILS)



Packets sent from Esbjerg (EKEBRS)

0

10000

20000

30000

40000

50000

60000

70000

80000

199

8100

1

199

8100

3

199

8100

5

199

8100

7

199

8100

9

199

8101

1

199

8101

3

199

8101

5

199

8101

7

199

8101

9

199

8102

1

199

8102

3

199

8102

5

199

8102

7

199

8102

9

199

8103

1

199

8110

2

199

8110

4

199

8110

6

199

8110

8

199

8111

0

199

8111

2

199

8111

4

Time (Days)

Pack

ets/

day

$1 $2 $A $B $E+$F

Figure 80 - STDMA packets from Esbjerg regional server (EKEBRS)

Packets sent from Tyra East (EKGFLS)

0

5000

10000

15000

20000

25000

30000

35000

199

8100

1

199

8100

3

199

8100

5

199

8100

7

199

8100

9

199

8101

1

199

8101

3

199

8101

5

199

8101

7

199

8101

9

199

8102

1

199

8102

3

199

8102

5

199

8102

7

199

8102

9

199

8103

1

199

8110

2

199

8110

4

199

8110

6

199

8110

8

199

8111

0

199

8111

2

199

8111

4

Time (Days)

Pack

ets/

day

$1 $2 $A $B $E+$F

Figure 81 - STDMA packets from Tyra East local server (EKGFLS)



Based on the information in the previous graphs a total "bit pr. second transmitted by a server" wascalculated for each server in the period assuming a packet overhead as described in Table 13.

Header Packet Overhead(bytes)

NetHeader (Application specific header used in the DOS-basedNEANSERV software)

29

IP Header Standard IP header. Assuming fixed length and nofragmentation.

20

TCP Header Standard TCP header. 20In total: 69

Table 13 - Packet header sizes NetHeader, IP and TCP

The bits/s transmitted pr. server - counting $1,$2,$A,$B,$E and $F messages – was combined withSNMP data for the Danish routers. The result is presented in Figure 82 to Figure 86.In general, there is good correlation between the sent STDMA-messages and the router load. Therouter load is often higher than the $1,$2,$A,$B,$E and $F message-load, since not all STDMA-messages are counted. E.g. DGPS messages are collected for test-purposes and IP messages likeSNMP, IMCP and RIP packets are also passing through the routers.

Figure 82 shows the load on the national router in Kastrup servicing the two branches of the DanishNEAN segment: Billund/Aalborg and Esbjerg/Tyra East. The packet influx (in bits/s) has beencalculated for these servers and is included in the graph.

Netload Kastrup (EKCHRT1)

0

1000

2000

3000

4000

5000

6000

7000

8000

199

8100

1

199

8100

3

199

8100

5

199

8100

7

199

8100

9

199

8101

1

199

8101

3

199

8101

5

199

8101

7

199

8101

9

199

8102

1

199

8102

3

199

8102

5

199

8102

7

199

8102

9

199

8103

1

199

8110

2

199

8110

4

199

8110

6

199

8110

8

199

8111

0

199

8111

2

199

8111

4

Time (days)

Thro

ughp

ut (b

its/s

)

ekchrt1 port2 (Esbjerg) ekchrt1 port1(Aalborg/Billund)Server: ekgfls+ekebrs Server: ekbils+ekytls

Figure 82 - Network load on Kastrup national router and influx from local servers

Figure 83 shows the load on the local router in Billund servicing only the Billund LAN segment.The packet influx (in bits/s) has been calculated and included for the Billund server. The large peakregistered around 1998-11-03 was caused by a broadcast storm inflicted by a runaway Germantransponder, that continuously sent garbage messages to all transponders in the network. This



transmission caused a high load on the routers, but was not registered as valid STDMA messages onthe servers and is consequently not registered in the graphs.

Netload Billund (EKBIRT1)

0

500

1000

1500

2000

2500

3000

3500

4000

4500

199

8100

1

199

8100

3

199

8100

5

199

8100

7

199

8100

9

199

8101

1

199

8101

3

199

8101

5

199

8101

7

199

8101

9

199

8102

1

199

8102

3

199

8102

5

199

8102

7

199

8102

9

199

8103

1

199

8110

2

199

8110

4

199

8110

6

199

8110

8

199

8111

0

199

8111

2

199

8111

4

Time (days)

Thro

ughp

ut (b

its/s

)

ekbirt1 por12 (to Aalborg) Server ekbils

Figure 83 - Network load on Billund local router and influx from local server

Figure 84 shows the load on the local router in Esbjerg servicing both the Esbjerg LAN segmentwith the Regional server and the Tyra East segment. The packet influx (in bits/s) has beencalculated and included for both Tyra East (EKGFLS) and Esbjerg (EKEBRS) servers.

Netload Esbjerg (EKEBRT1)

0

1000

2000

3000

4000

5000

6000

7000

8000

199

8100

1

199

8100

3

199

8100

5

199

8100

7

199

8100

9

199

8101

1

199

8101

3

199

8101

5

199

8101

7

199

8101

9

199

8102

1

199

8102

3

199

8102

5

199

8102

7

199

8102

9

199

8103

1

199

8110

2

199

8110

4

199

8110

6

199

8110

8

199

8111

0

199

8111

2

199

8111

4

Time (days)

Thro

ughp

ut (b

its/s

)

ekebrt1 port1 (Tyra) ekebrt1 port2 (Kastrup)Servers ekebrs+ekgfls

Figure 84 - Network load on Esbjerg local router and influx from Tyra East Local and Esbjerg regionalserver

Figure 85 shows the load on the local router in Aalborg servicing both the Aalborg LAN segmentand the Billund segment. The packet influx (in bits/s) has been calculated and included for bothBillund (EKBILS) and Aalborg (EKYT) local servers. The large router throughput peak and thedrop in sent STDMA-messages around 1998-11-03 are also seen here.



Netload Aalborg (EKYTRT1)

0

1000

2000

3000

4000

5000

6000

7000

8000

199

8100

1

199

8100

3

199

8100

5

199

8100

7

199

8100

9

199

8101

1

199

8101

3

199

8101

5

199

8101

7

199

8101

9

199

8102

1

199

8102

3

199

8102

5

199

8102

7

199

8102

9

199

8103

1

199

8110

2

199

8110

4

199

8110

6

199

8110

8

199

8111

0

199

8111

2

199

8111

4

Time (days)

Thro

ughp

ut (b

its/s

)

ekytrt1 port 1 (to Kastrup) ekytrt1 port2 (to Billund) Servers ekbils+ekytls

Figure 85 - Network load on Aalborg local router and influx from both Aalborg and Billund localservers

Figure 86 shows the load on the local router on Tyra East servicing only the Tyra East LANsegment. The packet influx (in bits/s) has been calculated and included for Tyra East local server(EKGFLS).

Netload Tyra (EKGFRT1)

0

200

400

600

800

1000

1200

1400

199

8100

1

199

8100

3

199

8100

5

199

8100

7

199

8100

9

199

8101

1

199

8101

3

199

8101

5

199

8101

7

199

8101

9

199

8102

1

199

8102

3

199

8102

5

199

8102

7

199

8102

9

199

8103

1

199

8110

2

199

8110

4

199

8110

6

199

8110

8

199

8111

0

199

8111

2

199

8111

4

Time (days)

Thro

ughp

ut (b

its/s

)

ekgfrt1 port1 (Esbjerg) Packets sent ($1,$2,$A,$B,$E,$F)

Figure 86 - Network load on Tyra East local router and influx from Tyra East local server

Figure 87 shows a correlation between $2-messages/day from Tyra and the router throughput,together with a linear approximation. This result must only be taken as an indication of the requiredbandwidth in the ground network for different counts of mobiles in the GroundStation vicinity forthis particular implementation of the server software.It can be derived that 10 simultaneous targets ($2-messages) require ≈12 Kbit/s; 20 simultaneoustargets require ≈24 Kbit/s and 50 simultaneous targets require ≈60 Kbit/s, by using theY=0.0127X+842 approximation line. However, these figures are highly dependent on theimplementation and will change radically in the future. The LS/SDS servers running in Sweden andGermany have a different protocol between LS and SDS, than implemented for the NEANSERVsoftware.



y = 0.0127x + 842.65

0

200

400

600

800

1000

1200

1400

0 5000 10000 15000 20000 25000 30000 35000

$2-messages/day

bits

/s

Tyra East Linear Tendency (EKGF/Tyra East)

Figure 87 - Correlation between $2-messages and router load for Tyra East

Finally, the load on the international routers in Arlanda and Bremen is shown in Figure 88. Thesefigures have not been correlated with STDMA message influx from the respective networks. Thesudden decrease in net load from 1998-10-10 to 1998-10-13 was caused by a shutdown of the linkto Germany during the Global NavCom demonstration.

Netload Arlanda/Bremen (ESSART, EDDWRT)

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

199

8100

1

199

8100

3

199

8100

5

199

8100

7

199

8100

9

199

8101

1

199

8101

3

199

8101

5

199

8101

7

199

8101

9

199

8102

1

199

8102

3

199

8102

5

199

8102

7

199

8102

9

199

8103

1

199

8110

2

199

8110

4

199

8110

6

199

8110

8

199

8111

0

199

8111

2

199

8111

4

Time (days)

Thro

ughp

ut (b

its/s

)

essart port1 (Kastrup)eddwrt port1 (Kastrup)

Figure 88 - Network load on international routers in Arlanda and Bremen


Other activities in the network caused uncertainty in the relation between typical STDMA packets androuter throughput.



3.4.2. P2: System Delay

Identification P2Name System DelayResponsible SWET/LFV, DANT/SLV

Data Acquisition Period 1998-10-01 ⇒ 1998-11-08Recorded on Sensor Swedish national SDS and Danish local server Tyra East

3.4.2.1. Objectives

The objective of this test was to measure the total system delay-times for messages sent from end-system to end-system, ground-to-air and air-to-ground to see if the ground system implementationcontained any performance bottlenecks relating to principal matters rather than implementational.


MessTime MessTime = The round trip time t [ms] it takes for a text message to be sentfrom an end-system on ground to an end-system on board the aircraft, or viceversa.

PingMessage The PingMessage is a special text message, which – in MMI5000 equippedaircraft – will generate and send a PingReply back towards the originator.

PingReply PingReply is a text-message echo of a PingMessage, sent back to theoriginator of the PingMessage.


A special text message was designed for the test. The principle was to time stamp the PingMessagein the end-system on ground before it was transmitted to the aircraft. The message would be timestamped in the end-system on board (MMI5000) and sent back to the originator. On it’s way to andfrom the aircraft, the message would traverse the GroundNetwork.

The PingMessage was transmitted automatically and periodically to the ”known targets” from aspecial application on ground.

The test application, MMI Ping, was connected to the SDS server in the Swedish network. ThePingMessages sent to the Sub-Domain Server (SDS) were routed in the network to a BaseStationand up-linked to the aircraft. The reply to a PingMessage was created in the MMI 5000 and sentback to ground.



Pingapplication

GroundNetworkSweden

Base stationtransponder

SwedishSDS

Server

ADS-B and Acknowledgemessages from the wholeSwedish Network

LocalServer

Aircrafttransponder

MMI 5000cock-pitdisplay

VHF Data Link

Reply

”Ping”

Figure 89 - Test setup for the System Delay Test

The number of hops in the GroundNetwork for a full cycle was always 2,3 or 4 and most of the time4. The message went from the MMI PING, connected to the network in Norrköping, to the SDS atArlanda and normally from the SDS to a local server in the network. Occasionally, the message wasrouted to the local server at Arlanda, which was running in the same physical machine as the SDS.The reply from the aircraft might be routed in a different way, but in most cases there would be twohops.

When the PingMessage was received in the aircraft, the MMI 5000 waited for 1.5 s before sendingthe reply. The measured System Delay Times were therefore reduced with 1.5 s before presentationin log files etc., to represent the true travel time for the message ground-air and air-ground.


Assumption1 It was assumed that if there was no answer on a PingMessage, the target aircraftwas out of VHF coverage.


The distribution of the delay-time will be presented graphically.



3.4.2.6. Results

Figure 90 shows the aircraft location when system delay tests were performed. Each plot representsa successful test.

Figure 90 - Plots from the system delay test during 19-22 December 1998. The rings represent theBaseStations used for the test.

Figure 91 shows the distribution of the delay time. The most probable reason for longer delay timesthan 2.0 s is waiting time between two retries on the data-link. The transponders were configured tomake up to five tries with one-second intervals. The small congestion of counts around 2.0 s wasmost probably caused by a second try.

94% of the PingMessages had a delay time less than 2.5 s. The average delay time wasapproximately 1.4 s. The longest delay time was more than 6 seconds, which indicates severalretries on the data-link.

In the diagram, the x-axis is divided into delay time intervals of 0.25 s. The labels indicates thelargest value for the interval. In total, 21539 PingMessages were sent over the test period.

Copenhagen

Stockholm



0

1000

2000

3000

4000

5000

6000

7000

8000

-0.25

-0.75

-1.25

-1.75

-2.25

-2.75

-3.25

-3.75

-4.25

-4.75

-5.25

-5.75

-6.25

System Delay Time (ground-air-ground)

Cou

nts

Figure 91 - Distribution of message-ping delay times



In addition to this, a study was also made using the Tyra East GroundStation (EKGF). Locatedapproximately 125 NM off the Danish West Coast of Jutland and connected to the NEAN networkvia a satellite link, this station had the worst possible delay properties.

Ping-messages were sent into the system from a central log server in Kastrup/Copenhagen directlyconnected to the Danish national server.

A PingMessage was sent towards aircraft for every 50 received ADS-B reports if the receivedreport originated from the Tyra East GroundStation.Just prior to sending the PingMessage a timer was activated and the delay-time and receipt of thelink-ACK ($F-message [3]) and the PingReply ($E-message [3]) was recorded together with thegeographical location of the aircraft.If no reply was received within 20s, the message was counted as 'timed out'.

Table 14 shows the messages and explains the meaning of the measured times.

Message Explanation$PRGPS,010,<A/C ID>,0,!THETHUMB0000 Application level message sent to MMI5000

equipped aircraft with transponder ID <A/C ID>.This message was generated by the Kastrup logserver and injected into the DK national server forevery 50'th received aircraft position reportoriginating from Tyra East GroundStation.The message is shorter than an ADS-B message,but will occupy one slot [3] on the data linksimilar to an ADS-B position report.

$F<A/C ID>0 The link-ACK message is generated by theground transponder when the aircraft hassuccessfully received the message. The messageis routed back towards the Danish national server.

$E<A/C ID>0!THETHUMB0000<A/C ID>3880 Application level reply from the aircraft.This reply is generated 1.5s after the originalPingMessage is received.

Table 14 - Messages in Tyra East PING experiment



Table 15 describes the longest message-path in more detail.

From⇒⇒⇒⇒ / To⇐⇐⇐⇐ Via CommentKastrup Log Server ⇒

⇓The central log server feeds a PingMessage into theDanish national server via an open TCP connection ona 10Mbit Ethernet LAN.A timer is started.

Kastrup NS The message is processed by the Danish nationalserver and an application level routing decision(NEANSERV) is made to forward the message to theEsbjerg regional server via an open TCP connection.

⇓Kastrup DKIP router

The IP packet is sent down the TCP stream through theDanish National IP router on the same LAN as thenational server. The router forwards the packets toEsbjerg via the Danish TDM Backbone WAN(guaranteed 19200bps).

⇓Esbjerg IP Router The Esbjerg Regional IP router forwards relevant IP

packets to the Esbjerg regional server. The IP router ison same LAN segment as the regional server.

⇓Esbjerg Regional NEAN Server

The Esbjerg Regional NEAN Server examines thePingMessage and makes an application level routingdecision to forward the PingMessage to the Tyra EastLocal NEAN Server via an open TCP connection.

⇓Esbjerg IP Router The packets are again forwarded through the Esbjerg

regional IP router onto the Maersk Oil & Gas satelliteNetwork with Tyra East as destination.

⇓Tyra IP Router The Tyra local NEAN IP router receives IP packets

from the satellite network and forwards them to theLocal NEAN Server at Tyra.

⇓Tyra Local NEANServer

The Tyra local server examines the PingMessage andforwards message to the Tyra East STDMABaseStation transponder via a serial connection.

⇓TyraBase StationTransponder

The transponder transmits the message – via the VDL -to the airborne transponder.

⇓AirborneTransponder

On receipt the airborne transponder sends anacknowledgement to the BaseStation transponder as alink-level ACK ($F-message) and forwards thePingMessage to the MMI5000 cockpit display unit.

⇓



AircraftMMI5000

The MMI5000 – upon receipt of the PingMessage –halts all activities for 1.5s before returning anapplication level acknowledgement ($E-message) tothe on-board mobile transponder. This is referred to asthe PingReply.

⇓AirborneTransponder

The mobile transponder transmits the PingReply ($E-message) to the Tyra BaseStation transponder.

⇓TyraBase StationTransponder

The Tyra BaseStation transponder forwards thePingReply to the Tyra local server and the PingReplyfollows the same route back as the originalPingMessage. The same route is also taken by the link-ACK

⇓TyraLocal NEANServer⇓Tyra IP Router⇓Esbjerg IP Router⇓EsbjergRegional NEANServer⇓Esbjerg IP Router⇓KastrupDK IP router⇓

Kastrup Log Server ⇐ KastrupNational NEANServer

Upon receipt of a link-ACK ($F-message [2]) theactive log server timer is read and upon receipt of thePingReply ($E-message [2]) the timer is both read andterminated. These times are recorded for laterexamination.If no PingReply is received within 20s, the messaged isregistered as 'timed out'.

Table 15 - Longest message path in the NEAN network



Figure 92 shows the geographical map of the positions where aircraft were pinged during the test-period and the plot-symbol indicates if the ping failed or not.

Legend:X = PingMessage time out (PingReply was not received back in Kastrup within 20s).+ = PingMessage was successfully delivered and an answer received within 20s.


(EKEBB02)

Esbjerg(EKEBB01)

500 25

Kilometers

Billund(EKBI)

Aalborg(EKYT)

Co(EK

Kilometers

0 100 200

Figure 92 - Geographical locations of ping'ed aircraft

The large number of hits in the centre of the figure was caused by the helicopter (OY-HMH) flyingbetween Esbjerg and the offshore installations in the North Sea. The remaining plots were mostlyDLH and SAS aircraft flying through the area.

In total, 2892 PingMessages were transmitted, but only 2204 ping-replies were successfullyreceived. The low average success-rate (76.2%) of returned PingReplies could indicate a problemregarding message delivery, but this is inconclusive, since the test setup does not ensure PingMessagesto be delivered when within VHF coverage. The scenario does also not take into account PingReplies,which are delivered to alternate GroundStations or any GroundNetwork availability issues. The testonly focused on ground system delay not on message-delivery reliability.



Figure 93 shows the 'raw' measured round-trip times for the PingMessages from Tyra (EKGF).

981022 981023 981026 981029 981030 981030 981103 981104 981105 981106

Date

0

5

10

Delay s

EKGF: Message-Ping and Link Ack. Del

Figure 93 - 'Raw' turn-around times of successfully delivered messages

The result is summarised in Table 16.

GroundStation

Link-ACK.delay (s) ±SD (s)

Ping-messageround-trip time includingMMI-delay (s) ± SD (s)

Ping-messageone-way delay (s) ± SD2 (s)

Tyra East(EKGFB01)

2.200 ± 1.282 3.668 ± 0.798 1.084 ± 0.339

Table 16 - Message-ping delay times Copenhagen/Kastrup to aircraft in Tyra East coverage

It is a simplification to say that the one-way delay is only half the round-trip time, since there aredifferences in up-link and downlink times. It is also a simplification to compare the results to ADS-Bdelivery, since ADS-B position reports are treated differently than text-messages in the transponder,but in either case ADS-B messages are processes with higher priority than text-messages and henceADS-B system transit delays will be no worse than the measured. This, however, depends on theground server implementation, but the test shows that it is feasible to have a ground ADS-B/STDMAsystem capable of delivering ADS-B positions within 2s.

2 SD of the 'one-way delay' is calculated as 'round-trip SD'/2 in accordance with VAR(cX)=c2VAR(X),VAR(X+Y)=VAR(X)+VAR(Y) and VAR(c)=0 for a constant c and uncorrelated X and Y.




• The MMI Ping application used for the trials in the Swedish network was running on a WindowsNT computer. If the computer gives higher priority to another process when the MMI Ping iswaiting for a reply, it may result in a too long delay time. The number of simultaneous processeshas consequentially been minimised. The same problem also exists for the Tyra East experiment,since the Danish ping-tool runs on a Linux-box, without real-time properties.

• The MMI5000 will not always select the same Ground Station for downlink of the PingReply aswas used by the uplink. This implies that PingMessages sent to aircraft via Tyra - in the areascovered by - Tyra and Esbjerg/Børsmose – might transmit the PingReply via Esbjerg/Børsmose,improving the turnaround times. It is, in the current system, not possible to calculate how oftenthis actually happened. The same argument applies for aircraft near the Dutch coast, where theMaastricht station used by the PETAL project might be selected for downlink of PingReplies.Availability problems with the satellite link to Tyra are also likely to influence the PingMessagesuccess-rate.



3.5. Availability Tests

3.5.1. A1: Ground System Availability

Identification A1Name Ground System AvailabilityResponsible DANT/SLV

Data Acquisition Period 1998-10-01 ⇒ 1998-11-08Data from Sensors EKCHB01 (Copenhagen)

EKEBB01 (Esbjerg)EKEBB02 (Børsmose)EKGFB01 (Tyra East)EKYTB01 (Ålborg)EKBIB01 (Billund)

Recorded on Sensor Log-server in Kastrup, CopenhagenData $A-messages from local, regional and national NEAN servers (port

23, ASCII interface)

3.5.1.1. Objectives

The main objective of this test was to record the availability of the ground system for the Danishsegment and international interconnections during the test period. The main reason for carrying outthis test was to register periods where recording of ADS-B data was possible. NEAN was notdesigned for high-availability and the results should therefore not be compared against availabilityrequirements for operational systems.




Availability Availability denotes the availability of the system and is defined as:

%imeTotalTestt

UpTimeabilityUsageAvail =

UpTime [s] UpTime = TotalTesttime – MeasuredDowntime

TotalTesttime [s] TotalTesttime denotes the total time the test is running and data is collected.

MeasuredDowntime[s]

The MeasuredDowntime is defined as:"

NBASESTATIOi

iDTPwntimeMeasuredDo∈

= )(

This is a harsh measure, since the failure of a single BaseStation causes theentire system to be registered as down.

DTP(i) [s] Down Time Period [s] for the i'th component in the BASESTATION set. ABaseStation is registered as down if the time between received consecutive$A-messages, exceeds 30 seconds.

BASESTATION Denotes the set of relevant BaseStations and is defined to consist of{EKCHB01,EKEBB01,EKEBB02,EKGFB01,EKBIB01,EKYTB01}


The BaseStations generate GPS status reports ($A-messages) containing UTC time and satelliteinformation. These streams of reports are visible in the network and are recorded by a central log-server from local, regional and national servers. The distributed nature of the GroundNetworkimplies that some part of the system could be unavailable while other parts are still functioning.Availability will therefore be calculated for all Danish NEAN servers. A BaseStation is assumedunavailable if the stream of GPS status reports stops.

The $A-messages available from the NEAN servers (port 23, ASCII interface) contains a net-headerwhich identifies the message originator. There is a slight difference between messages originatingfrom BaseStations connected to old NEAN-servers and BaseStations connected to new LS/SDS-servers. Net-headers are only added to messages by old NEAN-servers. $A-messages originatingfrom BaseStations connected to LS/SDS-servers contain the identification of the LS/SDS-serverconnected to the first NEAN-server on the route from the BaseStation to the NEAN-server. Thisaffects all $A-messages from Sweden and almost all $A-messages from Germany. $A-messagesfrom the Danish network are not affected.

The frequency of $A-messages forwarded depends on the transponder software configuration. Inthe Danish network segment the rate is approx. 1 message per 20 seconds.



Figure 94 shows the setup used for the availability study performed in the Danish network segment.

Kastrup (EKCH)

Esbjerg (EKEB)

Tyra (EKGF)

NEAN Network(Danish Segment)

Local serverTyra East

SensorNATIONALNEAN server

Kastrup

Sensor

Børsmose

Log ServerKastrup

Local serverEsbjerg

Sensor

$A-Message

$A-Message

$A-Message$A-Message

Local serverAalborg

Local serverBillund

Sensor

Sensor$A-Message

$A-Message

Billund (EKBI)

Aalborg (EKYT)

GNSS/STDMAequipped A/C

Local serverKastrup

Sensor

$A-Message

Figure 94 - Test setup for the availability study

Table 17 lists the connections from the BaseStations to the log-server including intermediateNEAN-servers, IP-routers and satellite link. IP-router identification is in Italics.

$A-message route from BaseStation to log-serverEKCHB01 - EKCHLS - EKCHNS - LOGSERVEREKCHB01 - EKCHLS - LOGSERVEREKEBB01 - EKEBRS - ekebrt1 - ekchrt1 - EKCHNS - LOGSERVEREKEBB01 - EKEBRS - ekebrt1 - ekchrt1 - LOGSERVEREKEBB02 - EKEBRS - ekebrt1 - ekchrt1 - EKCHNS - LOGSERVEREKEBB02 - EKEBRS - ekebrt1 - ekchrt1 - LOGSERVEREKGFB01 - EKGFLS - ekgfrt1 - satellite link - ekebrt1 - EKEBRS - ekebrt1 - ekchrt1 - EKCHNS - LOGSERVEREKGFB01 - EKGFLS - ekgfrt1 - satellite link - ekebrt1 - EKEBRS - ekebrt1 - ekchrt1 - LOGSERVEREKGFB01 - EKGFLS - ekgfrt1 - satellite link - ekebrt1 - ekchrt1 - LOGSERVEREKYTB01 - EKYTLS - ekytrt1 - ekchrt1 - EKCHNS - l LOGSERVEREKYTB01 - EKYTLS - ekytrt1 - ekchrt1 - LOGSERVEREKBIB01 - EKBILS - ekbirt1 - ekytrt1 -ekytch1 - EKCHNS - LOGSERVEREKBIB01 - EKBILS - ekbirt1 - ekytrt1 - ekchrt1 - LOGSERVEREKBIB01 - EKBILS - ekbirt1 - ekytrt1 - ekchrt1 - LOGSERVER

Table 17 - Message path for $A-messages


Assumption1 A BaseStation is unavailable when the time period between GPS-status messagesexceeds 30 seconds.

Assumption2 Availability of $A-messages implies availability of all messages from theBaseStation.




The availability of the ground stations will be described with percentage figures.

3.5.1.6. Results

The test period was approximately one month and the log-server was active for 99.986% of thetime.

Table 18 sums up the availability of ground station transponders in the Danish segment of theNEAN network based upon the frequency of the reception of $A-messages.

BaseStation, Location BaseStationavailabilitypercentage

IP-networkavailabilitypercentage

Measure point location/Server

EKCHB01, Copenhagen 90.0795.70

99.9999.99

Copenhagen/EKCHNSCopenhagen/EKCHLS

EKEBB01, Esbjerg 90.7595.10

99.5499.54

Copenhagen/EKCHNSEsbjerg/EKEBRS

EKEBB02, Børsmose 89.1494.40

99.5499.54


EKGFB01, Tyra East 85.5991.0093.50

96.2096.2096.20


Tyra East/EKGFBLSEKYTB01, Ålborg 87.88

92.6099.5899.58

Copenhagen/EKCHNSÅlborg/EKYTBLS

EKBIB01, Billund 88.1694.50

98.4998.49

Copenhagen/EKCHNSBillund/EKBIBLS

Table 18 - Danish network segment and ground station availability

Logging was done independently of the NEAN servers but relied on the IP-network, wherefore alsoIP network availability was included. The IP network availability calculation was based on SNMPpolling of the ifOperStatus MIB variable for individual routers.



Table 19 characterises the time differences between $A-messages arriving at the national serverEKCHNS.

All time differences Time differences > 30DataFeed N Mean SD Avail % N30 Mean30 SD30 Unavail %

EKCHNS:EKCHB01 147577 22.88 370.75 90.07 575 583.15 5918.1 9.93EKEBB01 148203 22.78 380.57 90.75 86 3633.13 15470.2 9.25EKEBB02 146515 23.05 382.81 89.14 1022 358.74 4573.3 10.86EKGFB01 142779 23.65 389.12 85.59 955 509.44 4735.2 14.41EKBIB01 127745 23.36 384.61 88.16 576 613.50 5702.0 11.84EKYTB01 143657 23.51 670.39 87.88 220 1859.86 17070.9 12.12

All DataFeeds: 75.58 24.42

Table 19 - Time differences between $A-messages

Description of fields in order of appearance:

DataFeed $A-message source base stationN Number of observed time differences between $A-messagesMean Mean value in seconds of time differencesSD Standard deviation for the time differencesAvail % Availability of the DataFeed at EKCHNSN30 Number of observed time differences between $A-messages exceeding 30 secondsMean30 Mean value in seconds of time differences exceeding 30 secondsSD30 Standard deviation for the time differences exceeding 30 secondsUnavail % Unavailability of the DataFeed at EKCHNS

All Danish segment DataFeeds:Avail % Percentage of time where all DataFeeds where concurrently availableUnavail % Percentage of time where at least one DataFeed were unavailable

The table shows that the mean time difference between $A-messages is approx. 23 seconds for allDataFeeds which is close to the expected 20 seconds. The standard deviations vary between 370and 670 seconds indicating some problems with availability for all DataFeeds. The number ofunavailability periods is high for both EKEBB02 and EKGFB01 compared to the number ofunavailability periods for EKEBB01 indicating problems with the DataFeeds from EKEBB02 andEKGFB01.

NEAN messages has low priority on the MAERSK satellite link from Tyra East to Esbjerg. NEANservers discard messages if they are too old. This fact could lead to loss of availability of the TyraBaseStation in periods where the satellite link is fully used by MAERSK.



Figure 95 illustrate the Availability of the Danish segment on an hourly basis during the test period.The light areas show periods of unavailability.

0

500

1000

1500

2000

2500

3000

3500

1998

1001

1998

1002

1998

1003

1998

1004

1998

1005

1998

1006

1998

1007

1998

1008

1998

1009

1998

1010

1998

1011

1998

1012

1998

1013

1998

1014

1998

1015

1998

1016

1998

1017

1998

1018

1998

1019

1998

1020

1998

1021

1998

1022

1998

1023

1998

1024

1998

1025

1998

1027

1998

1028

1998

1029

1998

1030

1998

1031

1998

1101

1998

1102

1998

1103

1998

1104

1998

1105

1998

1106

1998

1107

1998

1108

Time (YYYYMMDD)

Seco

nds/

Hou

r

Logging Active Down Time

Figure 95 - Availability of all Danish segment DataFeeds

Six major periods of unavailability > 4 hour occurred during the test period, five of which arerelated to the unavailability of the national server EKCHNS. When the National Server EKCHNS isdown all DataFeeds are globally unavailable.

Period Approx. Downtime Cause of unavailability1998-10-16:1998-10-19 63 hours EKYT crash on Friday, down until

Monday1998-10-21:1998-10-22 13 hours EKCHNS crash, reason unknown1998-10-25:1998-10-26 30 hours EKCHNS crash, reason unknown1998-10-30 4,5 hours EKCHNS crash, broadcast storm1998-11-01:1998-11-02 18 hours EKCHNS crash, broadcast storm1998-11-03:1998-11-04 16,5 hours EKCHNS crash, broadcast stormTable 20 - Major unavailability periods

A runaway German Monitor Station continuously transmitting garbage messages to all transpondersin the network caused the broadcast storm.

The DataFeed from EKEBB01 was the most stable. The unavailability of EKEBB01 was mainlycaused by the unavailability of the national server EKCHNS and short periods of networkmaintenance.

For the DataFeed from EKEBB02 the unavailability of the national server EKCHNS stilldominates, but a lot of small unavailability periods emerged. They could be caused by a cable



problem that was identified after the end of the test period. Also some backbone networkmaintenance affecting EKEBB02 was done around 1998-10-12.

The DataFeed from EKGFB01 was rather unstable for the first week. Afterwards the unavailabilityof the national server EKCHNS dominates. The backbone network maintenance around 1998-10-12also affected EKGFB01. The problems during the first week could be caused by problems with thesatellite link between EKEBRS and EKGFLS.

Disruptive trials, experiments, demonstrations and transitions from old NEAN servers to newLS/SDS servers took place during the test period making logging of the international connectionsimpossible.


• Cable problems between EKEBB01/EKEBB02 and EKEBRS were identified after the testperiod had ended.



3.5.2. A2: Reliability of Airborne GNSS Transponder

Identification A2Name Reliability of Airborne GNSS TransponderResponsible SWET / LFV (Input from SAS)

Data Acquisition Period 1997-02 ⇒ 1998-12Recorded on Sensor NA

3.5.2.1. Objectives

The objective was to collect information regarding problems with the GNSS transponders operatingin the airborne environment. A mixed environment of R2/T2 and T3 transponders was used for thetests.The used generation of transponders was only operating as test equipment (certified to non-hazardous level). Since R2/T2 and T3 transponders will be surpassed by proper certified VDLMode 4 equipment in the future, it was not considered worthwhile to make an in-depth study of theR2/T2/T3 reliability.


None


Airlines are invited to provide information on hours flown with a GNSS transponder and asummary of problems encountered.


NA


A table listing the airline, aircraft type, transponder type, number of flown hours and a descriptionof problems encountered or airline comments.



3.5.2.6. Results

Airline/Operator Aircraft ID Xpdr MMI5000

Est.FlightHours

Comment on problems

DLH Boeing 747-200 D-ABYQ T3 Yes 4000DLH Boeing 747-200 D-ABYR T3 Yes 2400DLH Boeing 747-200 D-ABYX T3 Yes 3500DLH Boeing 747-200 D-ABZD T3 Yes 4000DLH Boeing 747-200 D-ABZE T3 Yes 4000DLH Boeing 747-200 D-ABZH T3 Yes 4000Golden Air SAAB 340 SE-ISG R2 Yes 4000LFV Beech 200 SE-KDK T3 Yes 900MAERSKHELICOPTERS

Super PumaHelicopter

OY-HMH R2 Yes 3000 The transponder stopped workingdue to a failed diode.The problem was fixed and thetransponder put into operationagain.

OLT FairchildMetroliner III

D-COLB R2 No 2600

OLT FairchildMetroliner III

D-COLT R2 No 2800

SAS 2 x Fokker F-28 SE-DGLSE-DFG

R2/T3 Yes 11000

SAS 2 x DC-9 SE-DASSE-DAW

R2/T3 Yes 2000

From the beginning, SAS used theR2 Transponder for the data link,and since spring 1998 an upgradeto the T3 Transponder has beenmade. The system has worked verywell and only minor problemsoccurred when more functionalitywas added (PETAL-II, NEAP andthe FREER-3 Trial).

SLV Nord 262 OY-IVA R2 No 2000 Transponder failed to navigateuntil after 15-20minutes ofoperation. This was caused by afaulty backup-battery.

Table 21 - Number of flight hours with NEAN equipment installed

Feedback from the pilots on the provided ADS-B functionality as well as pilots and airlines point ofview on future benefits of an integrated system are discussed in the North European CNS/ATMApplications Project (NEAP).



Table 22 is a list of transponder related Problem and Change Requests [7] recorded in the DanishNEAN segment during the project.

Date Problem and Change request ID Synopsis1996-12-13 DANT-TRANSP-017 Mobile (SSC) transponder has problems

transmitting with 12V PSU.1997-03-03 DANT-TRANSP-022 ‘Old h/w R2 transponder s/n 079. Will not produce

proper navigation upon start-up. Approx. 30minlater the problem disappears.

1997-04-03 DANT-TRANSP-023 All Danish BaseStation transponders has ‘stalled’,i.e. they stopped sending position reports.

1997-08-25 DANT-TRANSP-033 Three out of two BaseStation transponders in theDanish Network suddenly stopped to operate.‘Killed’ by toelper text-messages broadcastthrough the network.

1997-08-12 DANT-TRANSP-036 The ‘climb-indicator’ in the ADS-B messages arealways 0 (zero)

1997-12-09 DANT-TRANSP-056 The Helicopter transponder ceases to operate du toa burnt diode.

1998-01-06 DANT-TRANSP-057 The Transponder at Tyra is reported to malfunctionon the VHF link.

1998-01-07 DANT-TRANSP-058 Malformed position report detected in the networkoriginates from R2 transponder.

1998-08-11 DANT-TRANSP-084 SE-DAS was observed to transmit same positionrepeatedly.

Table 22 - R2 transponder problems detected in Danish segment


NA.



4. Conclusions and Recommendations

4.1. Individual test conclusions

4.1.1. R1 - Air-Ground Data Link Reliability

ADS-B/STDMA data completeness (measured seen in relation to expected) were between 95 and100%.A theoretical comparison with an SSR with a sweep time of 4 seconds, revealed that ADS-B/STDMA in data completeness terms is (at least) as good as existing systems. Even countingtracks with low completeness (down to 77%) and not correlating with availability gives a calculatedVirtual Probability of Detection of 99,8%, the reason for this being primarily the high update rate(of one position per second) of ADS-B, and secondly that the majority of lost position reportsoccurred in gaps of 1 or 2 at a time. This leaves only minor gaps and thus a tracker functionalitywould minimise the effect of lost position reports if the ADS-B update rate is kept high.

An important contributor to the measured position reports losses seems to be the (T3) transponderslot reservation mechanisms. This shows the need for co-ordination of ground station transmissionsand changes of the current reservation scheme.

The results indicate that a surveillance system using ADS-B/STDMA will, in terms of datacompleteness, perform no worse than current SSR systems. The test shows that it is feasible to useADS-B/STDMA for surveillance purposes and that ADS-B/STDMA could be used to augmentexisting infrastructure or to provide surveillance where none exist and deployment of traditionalequipment is too costly.

The test showed that it was difficult to trace problems regarding reliability with the existingequipment. It was especially difficult to monitor behaviour of mobile transponders. It isrecommended that a monitoring framework is developed for future mobiles, making it possible forGroundStations to gain access to internal transponder parameter values like slot-reservation used,slot-reservation originator, DGPS-message originator, etc.It is also recommended that some reliability parameters become an integral part of the groundserver software in form of a Management Information Base (MIB) and made accessible to standardmonitoring tools.

4.1.2. R2 - Ground-Ground Data Link Reliability

ADS-B completeness (measured seen in relation to expected) for seven distinct areas within anairport environment was calculated using data from multiple vehicles. Because of their placement inrelation to the BaseStation, only two of the seven areas were expected to have a high completeness,despite that the overall completeness ranged from 85-93%.The test showed that the ADS-B position losses mostly occur in gaps of one or two positions at atime. A tracker functionality would significantly reduce the effect of position losses and anadditional BaseStation would expectedly enhance data completeness.

The STDMA ground-ground surveillance capability – regarding data completeness – could be usedas part of ground surveillance systems.



σn-1 AZIMUTH

distance 1010meter

azim

uth

stan

dard

devi

atio

n[m

eter

]

4.1.3. R3 - Static Absolute Position Accuracy for Ground Vehicles

German experiment

The objective of this test was to determine the horizontal position accuracy for a fixed mobile.Therefore a mobile transponder was installed on a reference position within the coverage of aBaseStation.

A centre position was defined using the mean values of the recorded latitude and longitude positionreports. The deviation of the centre position from the reference position was approximately 0,60meter.

The distribution of the received ADS-B positions had a standard deviation of only 3,93 meter, but amaximum deviation of 37,67 meter. An explanation of this large deviation could not be found usingthe test equipment.

Statistical data from operational SSR stations was used in acomparison of STDMA and SSR.The SSR position accuracy is described by standarddeviations: The azimuth and the range standard deviations.The azimuth deviation, described as an angle, can beconverted into a deviation in meters by setting the distancebetween radar and target equal with the distance between theBaseStation and the STDMA transponder.Because the distance between radar and target is small, the azimuth deviation is small compared tothe range deviation of the radar station. Therefore, the azimuth deviation is ignored for the furtherdiscussion.

position accuracy: SSR azimuth standard deviation

azimuthstandarddeviation

σn-1 AZIMUT

azimuthstandarddeviation[meter]

rangestandarddeviationσn-1 RANGE

SRELL1 (Boostedt) 0,19° 3,34 meter 74,08 meterSREM5 (Neunkirchen) 0,19° 3,34 meter 74,08 meterASR 2000 (Leipzig) 0,04° 0,71 meter 37,04 meterMODE-S (Götzenhain) 0,041° 0,72 meter 11,2 meter

STDMA3,93 meter (total deviation)

The comparison of the test results with values from operational SSR stations shows that when theSTDMA target is only a short distance away from the BaseStation, its position accuracy is betterthan that produced by SSR at the same distances. The comparison is only theoretical, and does notaccount for the fact that the SSR technology is mainly used for larger distances, where the accuracyof both SSR and STDMA will decrease. But nevertheless it is a clue to compare the STDMA testresults with today’s operational equipment.



Danish experiment

Differential corrected position reports from a fixed mobile transponder located at a known referenceposition were analysed. Horizontally all positions were within a distance of 7,5 meter from thereference and 76,4% were closer than 1,5 meter. Vertically all positions were within 13 meter inheight from the reference point and 93,4% were closer than 5 meter. The standard deviation of thehorizontal distance to the reference point was 1,43 meter and the standard deviation in height was2,36 meter.

In general, the Danish accuracy seems a little better than the German. This result could be causedby more multipath effects in the German test environment than in the Danish. In addition, theslightly lower longitude resolution in Denmark could influence the result.Static position accuracy depends on the actual antenna environment. Although the antennas in thistest were situated in a possible multipath environment, that the internal GPS receivers could beimproved (and will be in new generations of transponders), and the position reports are subject tothe transponder resolution, position accuracy is fairly high and promising.

4.1.4. R4 - Dynamic Relative Position Stability for Ground Vehicles

The objective of the test was to examine the relative position stability for ground vehicles in motionto demonstrate the usefulness of the system as an Advanced Surface Movement Guidance andControl System (A-SMGCS).

The test results have nearly the same characteristics as the results of the “Static Absolute PositionAccuracy for Ground Vehicles” test (R3). This demonstrates that the motion of a vehicle has littleor no influence on the position stability.

It is important to notice that the results are reflecting the performance of the internal GPS receiver,which could be changed to an improved model any time.

For SMGCS applications the relative position stability of the ADS-B (STDMA) technology issuitable and useable assuming that an ICAO - Standard will be established.



4.1.5. C1 - Air-Ground VHF Long Range Coverage

The project demonstrated a significant ADS-B coverage area in Northern Europe with 17GroundStations. Figure 46 shows a sample of the recorded flights in the NEAN coverage area.

Figure 96 - Sample of recorded flight within the NEAN coverage area

An examination of the long-range VHF coverage from individual GroundStations revealed a largediversion in the coverage. Some stations had coverage far from the optimal and some had excellentcoverage. It is concluded that the system is very dependent on the quality of GroundStationinstallations and it is recommended that standards be developed specifying minimum requirementsfor the GroundStation in terms of coverage and how these requirements are verified.

Despite problems with part of the GroundStation installations the test showed that coverage seemsadequate for surveillance purposes.



4.1.6. C2 - Airport System Coverage

A study of the VHF coverage - based on reception of ADS-B position reports was conducted inFrankfurt airport. Three critical areas were found in the terminal area of the airport. The largest areais the area close to the eastern terminal building 2. A smaller area is close to the gates C and thesmallest one is on the western side of terminal building 1 close to the gates B.

The critical coverage areas were related to the location of the BaseStation. To ensure VHF coveragethe mobile transponder has to be in line-of-sight of the BaseStation. The critical areas were foundbehind the terminal buildings where poor coverage was expected.

To extend the ground coverage at the airport two solutions could be implemented

• The location of the VHF antenna of the base station could be moved to a central position at theairport (e.g. to the top of a terminal building).

• A second BaseStation located in the south west of the airport could be used to extend thecoverage. Such a solution is likely to improve both coverage and reliability.

A study of DGPS reception was also conducted and areas without DGPS were identified. Only0.3% of the measured positions had problems with DGPS reception and most of these were locatedin the terminal areas, collaborating the coverage results.

4.1.7. P1 - Ground Network Delay and Throughput

Delays in the IP network were fairly constant. The worst measured delay times were as expected, onthe link from Kastrup to Tyra East, which included a satellite link. Here the turnaround times for anInternet Control Message Protocol (IMCP) ping message was 700ms on average. Only heavy loadon the links would cause slightly increased delay times.

Also load on individual links was measured, but the results are too dependent on the current serverimplementation to be used. It was estimated that 10 simultaneous targets ($2-messages) require ≈12Kbit/s; 20 simultaneous targets require ≈24 Kbit/s and 50 simultaneous targets require ≈60 Kbit/s,with the current NEANSERV in a real environment.

The information required to measure the throughput for individual servers was difficult to accesssince the servers themselves did not provide statistics on packets/bytes processed, etc. It isrecommended that a proper monitoring and management concept be developed for ground serversmaking it possible to monitor if servers fulfil or deviate from predefined performance profiles.



4.1.8. P2 - System Delay

The system delay time is the time for a full ”dialogue” between a ground application and theaircraft. It is a simplification to say that the one-way delay is only half the round-trip time, since thereare differences in uplink and downlink times. It is also a simplification to compare the results to ADS-B position report delivery, since ADS-B positions are treated differently from text-messages in thetransponder, but in either case ADS-B positions are processed with higher priority than text-messagesand hence ADS-B system transit delays will be no worse than the measured. The delivery times arealso related to the ground server implementation.

An average transport time of less than 2 seconds, as measured both in Sweden and in Denmark(including the Tyra East satellite link) is quite promising and the test shows that it is feasible to have aground ADS-B/STDMA system capable of delivering ADS-B positions within 2s. However, thetesting was done under low link load, which should be considered in future studies. It is recommendedthat server implementations incorporate the ability to automatically monitor the system timeliness.

4.1.9. A1 - Ground System Availability

NEAN was not designed for high availability and the results from the ground system availabilitytest covering the Danish network segment emphasised this.

The availability of the IP-network segments varied from 96.20% to 99.99%, indicating that the IP-network was built by stable COTS components without the initial problems related to newlydeveloped hardware and software. The lowest availability (96.20%) was measured for the Tyra EastIP-router connected via a satellite link. NEAN messages had low priority on the satellite linkmaking availability impossible to guarantee. Availability figures for all the other IP-network wereabove 98.49%.

The BaseStation availability varied from 85.59% to 95.70% depending on BaseStation location,measuring point (i.e. NEAN server used as data source) and availability of the IP-network.Unavailability of the IP-network implies unavailability of BaseStations.

During the test period a number of incidents affecting ground system availability were observed:

• Server crashes.• Software errors.• Hardware errors.• Satellite link problems.• Undetected cable problem.• Errors requiring human intervention outside normal work hours.

The NEAN servers crashed frequently and were sometimes unable to recover automatically. Thisbehaviour was partly due to the system platform used for the NEAN servers (MS-DOS) and partlydue to errors related to the NEAN server software. This revealed the need for a solid operatingsystem where the system kernel is unaffected by application program crashes. It also revealed theneed for Quality Management related to software development to ensure proper testing,documentation and release control.



Hardware failures (e.g. a disk crash) occurred during the test period revealing the need forredundant hardware. Higher durability of hardware components is to be expected if high qualityproducts intended for 24-hours-a-day operations are used.

The lower availability of the Tyra East IP-network segment connected via the satellite link revealedthe need for Quality of Service assurances since surveillance data is useless if not available within acertain time after creation.

Cable problems between the BaseStations in Esbjerg/Børsmose and the regional NEAN server inEsbjerg were detected after the test period had ended. This was not discovered since it only affectedcommunication to the BaseStations, but revealed the need for System Monitoring functions thatcould signal an alarm when a problem occur.

Several of the major unavailability periods occurred outside normal work hours when the systemwas unattended, which revealed the need for automatic error recovery procedures and a supportorganisation should all automatic procedures fail.

Summarising the above mentioned remarks, the following issues should be addressed in order toimprove the ground system availability:

• Selection of a solid operating system.• Use of Quality Management related to software development.• Duplication of hardware.• Quality of hardware.• Quality of Service.• System Monitoring functions.• Error recovery procedures and maintenance staff.

Availability issues have a negative effect on other tests and must be eliminated or minimised infuture developments of GroundStations or other test equipment

4.1.10. A2 - Reliability of Airborne GNSS Transponders

During the project a mixed environment of R2/T2 (2nd generation) and T3 (third generation)transponders were used. However, since the used transponders were only operating as testequipment (certified to non-hazardous level) and will be surpassed by proper certified VDL Mode 4equipment in the future, it was not considered beneficial to make an in-depth study of the R2/T2/T3reliability. The following can be summarised:

• The R2/T2 transponders have in general been working well. There have occasionally beenproblems with the GPS receiver, in terms of navigation problems, which require a resetoperation. Another unfortunate characteristic of the built-in GPS receiver is the low positionupdate frequency. All mobile transponders have been programmed to transmit its position onceevery second. The GPS receiver may fail to calculate a new position before the position istransmitted on the data link or on the serial line to the cockpit display. In these cases the sameposition will be used twice in a row, which makes it appear as a lost position report.

• There have been several software updates of the R2/T2 transponders during the project. Most ofthese updates were induced by configuration changes in the test environment.

• The R2/T2 transponders used at ground stations showed a tendency to enter “maintenancemode” unintentionally. When the transponder is in maintenance mode it will echo back



everything on the RS232 data port. This, in combination with the DOS based server software,caused “broadcast storms” in the network and severe server crashes. A safer way to entermaintenance mode solved the problem.

• The new T3 transponder had several software problems in the beginning. The most seriousproblem affected the timing of the transponder, and SAS and Lufthansa aircraft were flyingseveral months with this fault. Reliability and performance tests may have been affected by thiserror.

• The airborne T3 transponders have been observed to fail tracking enough satellites within thestipulated start-up time (2 minutes). The start-up time has on several occasions been 15 minutesor more. Unlike the R2/T2, the T3 transponder has no battery backup for the GPS receiver.According to the specifications for the receiver, this should not have prevented a short start-uptime, and it is uncertain whether a battery backup would solve the problem.

• The T3 aircraft transponder is sensitive to different slot reservation messages sent from basestations, and has proven to be more sensitive than the T2/R2 transponder. The T3 transponder willuse the latest received slot reservation message and abandon planned transmissions of ADS-Breports if they are in conflict with the slot reservation. There have been periods during theproject when different slot reservation messages have been transmitted from the GroundStationtransponders, which have affected the transmission of ADS-B reports from airborne T3transponders.



4.2. Principal Conclusions

• A surveillance concept based on ADS-B and STDMA/VDL Mode 4, augmenting existinginfrastructure, is feasible, in terms of data completeness, accuracy and coverage and for bothground and airborne scenarios.

• An infrastructure could be developed and maintained by using existing technologies andnetwork concepts, and surveillance could be provided where none exist or deployment oftraditional equipment is too costly.

• The conclusion is that the STDMA ground-ground surveillance capability - in terms of datacompleteness – could be used as part of ground surveillance systems, but it is recommended thatadditional BaseStations (MonitorStations) be deployed and the raw ADS-B data pass through atracker-functionality compensating for losses.

• Static position accuracy depends on the actual antenna environment. Although the antennas inthis test were situated in a possible multipath environment and that the position reports aresubject to the transponder resolution, position accuracy is fairly high and promising.The motion of a vehicle has no influence on the position stability. For SMGCS applications therelative position stability of the ADS-B/STDMA technology is suitable and useable assumingthat an ICAO - Standard will be established.

• The coverage of the VDL seems adequate for most surveillance purposes. The same systemcould be used for surveillance during multiple phases of flight. However, the coverage dependson high quality GroundStation installations and it is recommended that standards be developedspecifying minimum requirements for the GroundStation in terms of coverage and how theserequirements are verified.

• It is feasible to have a ground ADS-B/STDMA system capable of delivering ADS-B positionswithin 2s. Average delivery times of less than 2 seconds, were measured both in Sweden and inDenmark (including the Tyra East satellite link) and is quite promising.

• Availability issues have a negative effect on other tests and must be eliminated or minimised infuture developments of GroundStations or other test equipment. The trial system had problemswith availability, but is should be considered that the system was not designed for highavailability.

• The NEAN infrastructure did serve well for ground-based local and regional GNSSaugmentation.

Documents

Work Package 2 Progress Report...Work Package 2 – Progress Report Page 3/128 Document Id: ALL_NEAN_WP2_5-1.0 Version: 1.0 Date: 1999-05-26 Control Page Revision Log. Version Date