nean final project summary and conclusion report · oliver reitenbach dfs björn syrén sas...

Document Id: ALL_NEAN_WP5_6-1.0File: C:\Program Files\Adobe\Acrobat 4.0\Acrobat\plug_ins\OpenAll\Transform\temp\WP5_Progress_Report.docVersion: 1.0Date: 1999-05-27Status: ReleasedAuthored by: All Project TeamsPrinted: 2000-10-14

Final Project Summary andConclusion Report

Final Project Summary and Conclusion Report /113

Document Id: ALL_NEAN_WP5_6-1.0Version: 1.0Date: 1999-05-27

Distribution List

Name 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 PageRevision Log.This version supersedes all previous versions of this document.

Version Date Author Pagesconcerned

Reason

0.0 - 0.7 1998-09-151999-04-14

All Teams(DANT/Editor)

All Draft versions

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

All First release. Incorporated EC comments.



Table of Contents

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

1. INTRODUCTION..........................................................................................................................16

1.1. OBJECTIVES OF THIS DOCUMENT .............................................................................................161.2. AUDIENCE................................................................................................................................161.3. REVISIONS ...............................................................................................................................161.4. PROJECT BACKGROUND...........................................................................................................171.5. CONCEPT AND TECHNOLOGY...................................................................................................18

1.5.1. Functional Concept .........................................................................................................181.5.2. Technology......................................................................................................................20

1.6. PROJECT ESTABLISHMENT .......................................................................................................261.6.1. Partners and Sub-contractors...........................................................................................261.6.2. Activities .........................................................................................................................27

2. OBJECTIVES OF THE NEAN PROJECT....................................................................................28

2.1. DEVELOPMENT OF INFRASTRUCTURE.......................................................................................282.2. DEMONSTRATION TO THE USER COMMUNITY ...........................................................................292.3. EVALUATION OF THE ADS-B SURVEILLANCE FUNCTIONALITY................................................29

3. HOW THE PROJECT MET THE OBJECTIVES .......................................................................303.1. DEVELOPMENT OF INFRASTRUCTURE.......................................................................................30

3.1.1. Ground Station Installation .............................................................................................313.1.2. Aircraft and Vehicle Transponder Installation................................................................333.1.3. Map Development...........................................................................................................353.1.4. ADS-B Display System ..................................................................................................353.1.5. ADS-B Network Development .......................................................................................363.1.6. Data Collection Tools .....................................................................................................433.1.7. Controller Working Position with ADS-B enhancements ..............................................433.1.8. Point-to-point functionality.............................................................................................443.1.9. Cockpit Display of Traffic Information (CDTI) .............................................................453.1.10. Procurement of next generation of Transponders .........................................................463.1.11. The New LS/SDS Concept ...........................................................................................46

3.2. DEMONSTRATION TO THE USER COMMUNITY ...........................................................................503.2.1. Support the NEAP Demonstrations ................................................................................503.2.2. Supporting other projects ................................................................................................533.2.3. Traffic Information Service - Broadcast (TIS-B)............................................................563.2.4. ADS-B and Radar compliance ........................................................................................583.2.5. Demonstration of the STDMA/ADS-B functionality to the user community ................60

3.3. EVALUATION OF THE ADS-B SURVEILLANCE FUNCTIONALITY................................................623.3.1. Technical Examination of the NEAN infrastructure.......................................................623.3.2. Certification Issues..........................................................................................................713.3.3. Cost Database..................................................................................................................72

4. THE PROJECT LIFE CYCLE.......................................................................................................76

4.1. WORK PACKAGES ....................................................................................................................764.2. LIST OF MEETINGS HELD WITHIN THE PROJECT........................................................................78

4.2.1. Steering Committee Meetings.........................................................................................78



4.2.2. Project Group Meetings ..................................................................................................784.2.3. Map group Meetings .......................................................................................................794.2.4. NEAN/PETAL Meetings ................................................................................................79

4.3. SPECIFIC PROBLEMS ................................................................................................................804.3.1. Transponders ...................................................................................................................804.3.2. Certification ....................................................................................................................814.3.3. Ground Network..............................................................................................................81

4.4. DELAYS ...................................................................................................................................824.4.1. Delayed T3 transponders.................................................................................................824.4.2. NEAN as PETAL II provider..........................................................................................82

5. CONCLUSION ..............................................................................................................................83

6. FUTURE PLANS...........................................................................................................................87

Appendix A - Partners Contact List

Appendix B - List of Project Documents



List of FiguresFigure 1 - Air-Air and Air-Ground communication.......................................................................... 18Figure 2 - Air-Air communication without presence of any ground infrastructure .......................... 18Figure 3 - Uplink of differential corrections from a ground station.................................................. 19Figure 4 - Networking of multiple base stations ............................................................................... 19Figure 5 - The time slots on the radio link ........................................................................................ 22Figure 6 - The self-organising time slots in autonomous mode ........................................................ 23Figure 7 - Generic ground station setup ............................................................................................ 32Figure 8 - Ground Station installations in Esbjerg/Denmark and Bromma/Sweden......................... 32Figure 9 - Some NEAN mobile installations..................................................................................... 34Figure 10 - Digital maps of Kastrup Airport, Denmark and Frankfurt Airport, Germany................ 35Figure 11 - Hierarchical tree topology of the NEAN ground network.............................................. 36Figure 12 - Interconnection of German, Danish and Swedish national domains .............................. 37Figure 13 - Client and server elements of the NEANSERV software............................................... 38Figure 14 - Physical topology for the Swedish NEAN network ....................................................... 40Figure 15 - Physical topology for the Danish NEAN network.......................................................... 41Figure 16 - Physical topology for the German NEAN network ........................................................ 42Figure 17 - Principal dataflow in the DCAA CWP........................................................................... 43Figure 18 - Principal data flow in the DFS CWP.............................................................................. 44Figure 19 - Screen dump from MMI5000 cockpit display................................................................ 45Figure 20 - The LS/SDS model ......................................................................................................... 48Figure 21 - TIS-B installation in Frankfurt ....................................................................................... 56Figure 22 - Sector "terminal area" presented on the CWP................................................................ 56Figure 23 - Slot allocation scheme for the TIS-B application........................................................... 57Figure 24 - TIS-B presentation on the MMI 5000 CDTI .................................................................. 57Figure 25 - Controller Working Position used by DFS..................................................................... 58Figure 26 - The AIRLINK CWP setup in Langen Germany............................................................. 58Figure 27 - STDMA and SSR data.................................................................................................... 59Figure 28 - NEAN Exhibition Display.............................................................................................. 61Figure 29 - Project timetable ............................................................................................................. 76Figure 30 - Sample of recorded flights within the NEAN coverage area.......................................... 84



List of TablesTable 1 - OSI and TCP/IP protocol stack .......................................................................................... 25Table 2 - NEAN partners and sub-contractors .................................................................................. 26Table 3 - Number of flight hours with NEAN equipment installed .................................................. 33Table 4 - Base station costs using an R2 transponder ....................................................................... 72Table 5 - Base station costs using a T3F transponder ....................................................................... 72Table 6 - NEAN server unit costs...................................................................................................... 73Table 7 - NEAN display unit costs.................................................................................................... 73Table 8 - NEAN management unit costs ........................................................................................... 73Table 9 - Network IP-router costs ..................................................................................................... 73Table 10 - International line installation costs .................................................................................. 73Table 11 - Aircraft costs for a Fairchild Metroliner III ..................................................................... 74Table 12 - Aircraft costs for a Fokker F28 ........................................................................................ 74Table 13 - Aircraft costs for a Boeing 747-200 Jumbo ..................................................................... 74Table 14 - Vehicle costs .................................................................................................................... 74Table 15 - International line costs per year ....................................................................................... 75



Abbreviations

ADS Automatic Dependent SurveillanceADS-B Automatic Dependent Surveillance – BroadcastAI Application InterfaceAOC Airline Operational CommunicationsASN.1 Abstract Syntax Notation OneASTERIX All purpose STructured EUROCONTROL Radar Information eXchangeATC Air Traffic ControlATIS-B Automatic Terminal Information Service - BroadcastATM Air Traffic ManagementATN Aeronautical Telecommunications NetworkCANDI Civil Aviation Network Data InterchangeCDE Common Desktop EnvironmentCDTI 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 TeamDAP Download of Aircraft ParameterDCAA Danish Civil Aviation Administration (SLV)DFS Deutsche Flugsicherung GmbHDEFAMM Demonstration Facilities for Airport Movement ManagementDGPS Differential Global Positioning SystemDGVII Directorate General VIIDLH Deutsche LufthansaDLR Deutsches Forschungszentrum für Luft- und RaumfahrtDOS Disk Operating SystemDTU Data Terminating UnitEATMS European Air Traffic Management SystemEC European CommissionEU European UnionEUROCAE European Organisation for Civil Aviation ElectronicsFARAWAY 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 SystemGUI Graphical User InterfaceICAO International Civil Aviation OrganisationIP Internet ProtocolIPV Instrument Approach with Vertical guidanceISDN Integrated Services Digital NetworkISO International Standards OrganisationJAR Joint Aviation RequirementsJAA Joint Aviation Authorities



LAN Local Area NetworkLFV Luftfartsverket (SCAA)LS Local ServerMAN Metropolitan Area NetworkMET MeteorologicalNAV NavigationSRG Safety Regulation GroupNEAN North European ADS-B NetworkNEAP North European CNS/ATM Application ProjectNUP NEAN Update ProgrammeNAAN North Atlantic ADS-B NetworkOLT Ostfriesiche Lufttransport GmbHOSI Open Systems InterconnectionPETAL Preliminary EUROCONTROL Test of Air/Ground Data LinkPSN Packet Switched NetworkRAPNET Regional ATC Packet switched NetworkRIMS Runway Incursion Monitoring SystemRMCDE Radar Message Conversion and Distribution EquipmentRTCM SC Radio Technical Commission for Maritime Services Special CommitteeRTD Research and Technical DevelopmentSARPs Standards and Recommended PracticesSAS Scandinavian Airline SystemsSCAT-1 Special Category OneSCAA Swedish Civil Aviation Administration (LFV)SDS Sub Domain ServerSLV Statens Luftfartsvæsen (DCAA)SMGCS Surface Movement and Guidance Control SystemSQL Structured Query LanguageSSR Secondary Surveillance RadarSTDMA Self-organising Time Division Multiple AccessSWET Swedish NEAN Project TeamTARMAC Taxi and Ramp Management and ControlTCP Transmission Control ProtocolTDI Track Deviation InstrumentTEN-T Trans-European Network - TransportTIS-B Traffic Information Service - BroadcastTWR Air Traffic Control TowerUHF Ultra High FrequencyUK United KingdomUTC Universal Time Co-ordinatedVDL VHF Digital LinkVHF Very High FrequencyWAN Wide Area NetworkWGS 84 World Geodetic System 1984WIAS Weather Information Automated SystemWP Work PackageXPDR Transponder



References

[1] Notes from the meeting in Saltsjöbaden, Stockholm 20-21 November 1995LFV, CAA-Sweden, Larry Johnsson, 1995-12-27

[2] Notes from the Steering Committee Kick Off meeting in Copenhagen the 17 and 18January 1996SLV, CAA-Denmark, Jørgen Jørgensen, 1996-01-10

[3] The Community Financial Aid in the Field of the Trans-European Transport NetworkEligible Study of the North European Automatic Dependent Surveillance Broadcast(ADS-B) NetworkLFV, CAA-Sweden, Bo Redeborn, 1995-10-18

[4] North European ADS-B Network Project DefinitionLFV_WP0_02LFV, CAA-Sweden, Kimmy Bech, 1996-10-21

[5] Work Package 1 – Progress ReportALL_NEAN_WP1_1All Teams, 1997-02-11



[8] Work Package 4 – Progress ReportALL_NEAN_WP4_4K. O’Neil, Advanced Aviation Technology & International Associates, 1997-10-16



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.

The NEAN project was launched November 1995 in Stockholm and the project officially startedJanuary 1996 by a kick off meeting in Copenhagen. The project was scheduled to run for a periodof three years from January 1996 until December 1998.

The NEAN project was funded by the European Commission Directorate General for Transport(DGVII) and the following participants:

• Swedish Civil Aviation Administration, SCAA (contract holder)• Danish Civil Aviation Administration, DCAA• Deutsche Flugsicherung GmbH, DFS• United Kingdom Civil Aviation Administration, SRG/UK CAA• Deutsche Lufthansa, DLH• Scandinavian Airline System, SAS

Beside the main participants, several other airlines and companies related to air traffic have beenparticipating in the NEAN project as subcontractors.

The application for funding of the NEAN project originally submitted to the European Commissioncomprised an objective of the development and evaluation of applications using the developedinfrastructure. This objective was due to financial reasons given a project of its own called NEAP(North European CNS/ATM Applications Project) funded by the DG VII under the 4th RTDFramework Programme. The two projects were closely connected. The separation of NEAP fromNEAN implied a reorganisation of the activities resulting in the following five Work Packages:

Work Package 0: Project establishment.Work Package 1: Installation and trials.Work Package 2: Installation and trials - expansion.Work Package 3: Development of ADS-B Network.Work Package 4: Certification Issues.Work Package 5: Data analysis and reporting.

The main components of the ADS-B network are mobiles (aircraft, vehicles) and networked groundstations equipped with GNSS transponders broadcasting their position on a VHF digital link usingan innovative technique called STDMA (Self-organising Time Division Multiple Access). TheSTDMA data link is subject of standardisation within ICAO and is called VDL Mode 4.



The ADS-B functionality in the NEAN project is based on:

• a Global Navigation Satellite System (GNSS) providing position information and timesynchronisation,

• a VHF Digital Link (VDL) enabling mobile communication,• a common framework for ground network connectivity.

Each ADS-B capable user (e.g. aircraft, vehicle, ground station) periodically broadcasts its position(latitude, longitude and height) together with other relevant data (course, speed etc) on a VDL. VHFcells are effectively created around equipped users. Any user within VHF range of a broadcast maychoose to receive and process the information.

To support surveillance applications covering a larger area, ground stations are connected in acellular network. ADS-B position reports are collected and concentrated in a focal point.

The cellular network provides ADS-B surveillance capability, but the network also includes supportfor end-to-end services like Controller Pilot Data Link Communication (CPDLC) and broadcastservices like Traffic Information Service - Broadcast (TIS-B) and Automatic Terminal InformationService - Broadcast (ATIS-B). Together the networked ground stations provide regional GNSSaugmentation services.

The development of the experimental cellular infrastructure in NEAN comprised:

• Ground Station Installation• Aircraft and Vehicle Transponder Installation• Map Development• ADS-B Display System• ADS-B Network Development

To support dedicated demonstrations and evaluations the following were also developed:

• Data Collection Tools• Controller Working Position with ADS-B input handling• Point-to-point functionality• Cockpit Display of Traffic Information (CDTI)

To bring the project further ahead the following activities were undertaken:

• Procurement of a next generation of transponders• Development of improved Ground Network Software



The evaluation of the ADS-B surveillance functionality of the NEAN infrastructure comprised thefollowing tasks:

• Technical examination of the NEAN infrastructure• Examination of certification issues• Cost Database establishment

The objective of NEAN to demonstrate the benefits of an STDMA/ADS-B system comprised:

• Support of the North European CNS/ATM Applications Project (NEAP) as the most importantdemonstrator

• Support of other projects if required• Demonstration of compliance between radar-data and ADS-B• Demonstration of uplink of radar data (TIS-B)• Demonstration of the STDMA/ADS-B functionality to a large user community

At the end of the project 17 dedicated NEAN ground stations were interconnected, 19 aircraft andmore than 25 vehicles were equipped with GNSS transponders. The following table shows themagnitude of the demonstrations, by presenting estimated flight hours for the aircraft andhelicopters used in the NEAN trials:

Airline or Operator Aircraft Estimated FlightHours

DLH Boeing 747-200 4000DLH Boeing 747-200 2400DLH Boeing 747-200 3500DLH Boeing 747-200 4000DLH Boeing 747-200 4000DLH Boeing 747-200 4000Golden Air SAAB 340 4000LFV Beech 200 900MAERSK HELICOPTERS Super Puma Helicopter 3000OLT Fairchild Metroliner III 2600OLT Fairchild Metroliner III 2800SAS 2 x Fokker F-28 11000SAS 2 x DC-9 2000SLV Nord 262 2000

Number of flight hours for different aircraft

During the NEAN project, representatives from the participants were able to demonstrate real timegate to gate scenarios, using data from the NEAN network, distributed via Internet. The NEANproject was presented at several important conferences and exhibitions during 1996-1998.

The final demonstration was the NEAN/NEAP demonstration flight February 21, 1999 arranged bySAS. Representatives from the European Commission, Airlines, airframe manufacturers, civilaviation authorities, the Swedish television and different international newspapers and magazines,



were on-board the two SAS Fokker F-28 aircraft, which performed station keeping, conflictdetection and resolution, non-precision approaches and runway incursion during a flight fromCopenhagen to Stockholm.

Altogether NEAN has been a very successful demonstrator of ADS-B. The project alsodemonstrated the advantages of a gate to gate system for ADS-B where one single system willprovide necessary data for surveillance for all phases of flight. The NEAN and NEAP projects havetogether demonstrated the possibility to use STDMA/VDL Mode 4 for CNS/ATM applications. Thesize of the coverage area, the number of equipped aircraft and ground vehicles, and the number offlight hours, make NEAN a unique ADS-B system in the world today.

A sample of recorded flights showing the NEAN coverage area

The established cost database indicates that the used technology can significantly reduce theinfrastructure costs, especially if the installations are used for several CNS/ATM applications. Thepotential savings the technology offers the total aviation community are not addressed in theframework of the NEAN project.

NEAN succeeded in establishing an experimental system developed to prototype level, comprisingnetworked ground stations, avionics in aircraft and airport based vehicles, in Denmark, Sweden andGermany. NEAN has been an essential platform for NEAP and other projects, as FREER-3(EUROCONTROL) and PETAL II (EUROCONTROL).

However, NEAN is an experimental network and several issues must be solved beforeimplementation of an operational ADS-B network can be done. In particular, standardisation andcertification issues have to be clarified.



In order to further develop the concept based on the VDL mode 4 technology, a NEAN UpdateProgramme (NUP) has been launched. NUP aims at certifiable applications that can be put intooperation in the end of the project. NUP will involve airlines, airframe manufacturers, avionicsmanufacturers, ATC-system manufacturers, infrastructure holders, airport authorities and civilaviation authorities. The candidate applications in NUP are:

• Airborne separation e.g. station keeping, parallel approaches• Enhanced surface operations in low visibility• Introduction of free flight zones• Broadcast of ATIS, RVR, TIS-B, weather information to cockpit• DGNSS for all phases of flight



1. IntroductionThis document, the ‘Final NEAN Project Summary and Conclusion Report’ is the last deliverableand thus finalises the North European ADS-Broadcast Network project. Part of the document isabstracts and synopsis of issues, which have been addressed in detail in previous delivered ProgressReports.

1.1. Objectives of this DocumentThe objectives of this document is to summarise all work conducted within the life cycle of theNEAN project and to present the project achievements and final conclusions drawn thus showinghow the project met the objectives stated in the ‘NEAN Project Definition’ [4].

1.2. AudienceThe audience for this document is the European Commission, the NEAN Steering Committee, theNEAN Project teams and other STDMA/VDL Mode 4 related projects.

1.3. RevisionsThe document has been edited, maintained and distributed by the project co-ordinator in accordancewith the Control Page and is released in its final version April 1999.

Inquiries concerning this document can be forwarded to the NEAN project co-ordinator:

Mr Peter RaffayStatens LuftfartsvæsenLuftfartshusetEllebjergvej 50DK-2450 Copenhagen SVDenmarkPhone: +45 36 44 48 48or direct: +45 35 44 08 08 · 557Fax: +45 36 44 03 03e-mail: [email protected]



1.4. Project BackgroundAfter several years of preparation, ICAO agreed at the 10th Air Navigation Conference in 1991upon the CNS/ATM concept as the future strategy for global Air Traffic Management.

During the 1980’s and the beginning of the 1990’s the Swedish Civil Aviation Administration(SCAA) sponsored a project called CNS Applications Research & Development (CARD) which, inco-operation with private enterprises, had the opportunity to develop and demonstrate a systemwhich in major aspects supported an implementation of the CNS/ATM concept. The system wasbased on several unique innovations such as a GPS based GNSS transponder and a VHF Self-organising Time Division Multiple Access (STDMA) data link.

Since the system encompassed satellite navigation, users of the system were able to determine theirposition with high accuracy. Adding data link capability provided means of transmitting positionreports and other messages as well as monitoring the positions of all other users, thus supporting theAutomatic Dependant Surveillance-Broadcast (ADS-B) application.

As initial tests showed ADS-B over the STDMA data link to be efficient, cost effective andpromising, the SCAA wanted to demonstrate the concept on a larger scale within northern Europe.When Sweden became a member of the European Community the idea of a North European ADS-BNetwork emerged and contacts to Deutsche Flugsicherung GmbH (DFS) and the Danish CivilAviation Administration (DCAA) were established.



1.5. Concept and TechnologyThis section provides a brief introduction to the functional concept and technology of the NEANproject.

1.5.1. Functional Concept

The ADS-B functionality in the NEAN project is based on:• a Global Navigation Satellite System (GNSS) providing position information and time

synchronisation,• a VHF Digital Link (VDL) enabling mobile communication,• a common framework for ground network connectivity.

Each ADS-B capable user (e.g. aircraft, vehicle, ground station) periodically broadcasts its position(latitude, longitude and height) together with other relevant data (course, speed etc) on a VDL. VHFcells are effectively created around equipped users. Any user within VHF range of a broadcast maychoose to receive and process the information. Figure 1 shows this basic principle.

Ground station

Figure 1 - Air-Air and Air-Ground communication

The operating principles do not depend on any ground infrastructure as indicated in Figure 2, wheremobile users communicates without ground dependence.

Figure 2 - Air-Air communication without presence of any ground infrastructure



To increase the position accuracy of mobiles, ground stations are capable of providing a localGNSS augmentation service within the VHF cell surrounding the ground station as shown in Figure3, where differential corrections are up-linked on the VDL to mobiles in the ground station vicinity.

Differential corrections

DGPS

Figure 3 - Uplink of differential corrections from a ground station

To support surveillance applications for ATC covering a larger area, ground stations are connectedin a cellular network as shown in Figure 4. ADS-B position reports are collected and concentratedin the ATC centre.

Ground networkATC

Figure 4 - Networking of multiple base stations

This provides ATC with a basic ADS-B surveillance capability, but the cellular network alsoincludes support for end-to-end services like Controller Pilot Data Link Communication (CPDLC)and broadcast services like Traffic Information Service - Broadcast (TIS-B) and AutomaticTerminal Information Service - Broadcast (ATIS-B). Together the networked ground stationsprovide regional GNSS augmentation services.



1.5.2. Technology

The four main technologies and techniques supporting the functional concept are:

• Global Positioning System (GPS)The GPS technology is an integral part of the GNSS transponder for obtaining the position andproviding a synchronised time function for data link management.

• Differential GPS (DGPS)DGPS is used for local and regional area GPS augmentation providing improved positionaccuracy for mobiles within VHF coverage of a base station.

• VHF Self-Organising Time Division Multiple Access data link (VHF STDMA data link)The STDMA data link is an integral part of the GNSS transponder and is used as the VHFdigital link (VDL) for air-air, air-ground and ground-ground data communication.

• TCP/IP NetworkingThe standard TCP/IP protocol suite provides a common transport layer interface in the groundnetwork architecture and facilitates base station interconnection on a large scale.

The following sub-sections describe these technologies and techniques in turn.

1.5.2.1. Global Positioning System (GPS)

GPS is a satellite based radio navigation system developed, operated and controlled by the UnitedStates Department of Defence. GPS permits land, sea and airborne users to determine their three-dimensional position, velocity, and GPS system time, with high precision, 24 hours a day, in allweather conditions, almost anywhere in the world.

GPS consists of three segments: space, control and user.

The Space Segment consists of 27 satellites in six circular orbits about 20000 km above the earthat an inclination angle of 55 degrees. The satellites continuously broadcast information about theirposition and time (based on highly stable atomic clocks). A spread spectrum technique is used forthe broadcast enabling all satellites to use the same frequencies (1575.42 MHz and 1227.60 MHz)without disturbing each other.

The Control Segment consists of one master control station in Colorado Springs, five monitorstations and three ground antennas located throughout the world. The monitor stations track all GPSsatellites in view and collect ranging information from the satellite broadcasts. The monitor stationssend the information collected from each of the satellites back to the master control station, whichcomputes and predicts the satellite orbits. The updated orbit information is transmitted to eachsatellite via the ground antennas.



The User Segment consists of the receivers, processors, and antennas that allow users to receivethe GPS broadcast and compute their precise position, velocity and time.

The GPS concept of operation is based upon satellite ranging. Users calculate their position bymeasuring their distance to each satellite in view. The satellites act as precise reference points.

Each GPS satellite transmits an accurate position and time signal. The user's receiver measures thetime delay for the signal to reach the receiver, which is the direct measure of the apparent range tothe satellite. Measurements collected simultaneously from at least four satellites are processed tosolve for the longitude, latitude, height above Earth and GPS system time.

GPS provides two levels of service, a Standard Positioning Service (SPS) for general public use andan encoded Precise Positioning Service (PPS) primarily intended for use by the U.S. Department ofDefence.

Standard Positioning Service is the standard level of positioning and timing accuracy available toany user on a continuous, world-wide basis. The accuracy of this service is adjustable by anintentional degradation of signal accuracy to protect U.S. national security interests. This process iscalled Selective Availability (SA). SPS accuracy is within 100 m horizontal, 156 m vertical and 340nanoseconds GPS system time.

1.5.2.2. Differential GPS (DGPS)

It is possible to achieve a higher position accuracy without access to the PPS by using SPS and atechnique called Differential GPS (DGPS).DGPS uses a number of GPS reference receivers located at known positions. The GPS referencereceiver calculates the position error and broadcast correctional data via radio to users with DGPScapable GPS receivers. This technique provides position accuracy within a few meters.

The NEAN project used GPS/DGPS for localisation of mobiles and GPS system time for STDMAdata link synchronisation.



1.5.2.3. Self-Organising Time Division Multiple Access (STDMA)

The GNSS transponders used in NEAN communicate on a VHF radio data link, using the Self-organising Time Division Multiple Access (STDMA) technique. On this data link each transponderfrequently transmits a position report which is received by all other transponders in the area.Additionally a number of messages that can be transmitted, such as differential corrections from aground station, warning and status messages and text messages between transponders. Thetransmission is performed in time slots, which are shared by all transponders in the vicinity of theground station, see Figure 5 below.

Figure 5 - The time slots on the radio link

The number of time slots per minute depends on the bandwidth and transmission rate of the radiochannel. The project used a bandwidth of 25 kHz and the transmission rate of 9600 bits per second.A slot size of 256 bits (32 bytes) gives 2250 time slots per minute.

Synchronisation

Since several transponders are to share the time slots, it is of high importance that all transponderstransmit on exact times to avoid overlapping transmissions. An internally corrected andsynchronised time in each transponder provides this functionality.

Transmission Package

The messages on the data link are transmitted in packets, which includes a number of frames, suchas start and stop frames and buffering.



Time Slot Allocation

The allocation of time slots can be controlled in two different ways, either in autonomous mode orin controlled mode. In autonomous mode each transponder automatically looks for vacant timeslots.In controlled mode a ground station assigns time slots to the transponders in the area. A groundstation can work either in autonomous or control mode. The mode is chosen at setup. The controlledmode can be used for transponders within the zone of a controlling ground station. When acontrolling ground station receives an autonomous transmission, it determines if the mobiletransponder is within its zone and, if it is, assigns time slots for the mobile. The mobile transponderis thereby set in controlled mode. If a mobile transponder does not receive any time slot informationfrom a controlling ground station, it automatically switches back to autonomous mode.

Base stations normally uses autonomous mode in which they do not control the time slots of anymobile transponders. The only fixed slots used by a ground station in autonomous mode are thoseused for the uplink of differential corrections, if available.

Autonomous Mode

In autonomous mode each transponder listens for vacant time slots to use and reserve for futuretransmissions. This is the Self-organising Time Division Multiple Access (STDMA) functionality.The principle is shown in Figure 6.

��

��

Figure 6 - The self-organising time slots in autonomous mode

The transponder reads data on the link and generates tables of the current radio traffic. The tablesare continuously updated and vacant time slots are registered. A vacant time slot is selected inaccordance with the requested update rate, and a position report is transmitted. The position reportalso contains information of how long the transponder will continue to send in the same time slot orin which time slot the next message will be sent.



Each transponder periodically changes the allocated time slots after a new evaluation of the currentradio traffic. This is to avoid time slot collisions for example when new users enter the system.

If a transponder in autonomous mode receives a message from a controlling ground station or atransponder in controlled mode, the use of the nearest time slots is avoided. This is to give acontrolling ground station spare slots into which it can direct transmissions from controlledtransponders.

Controlled Mode

In controlled mode, a ground station distributes the allocation of time slots. The controlling groundstation assigns time slots to all transponders within its zone, according to the requested update rate.If the ground station is equipped with a GNSS reference receiver, time slots are also assigned fordifferential correction data. Some slots are always left free in order to allow new users to enter thesystem, and for the slot changing process. Time slots can also be reserved for transmission of textmessages or external data.

When controlling ground stations are installed, each ground station is assigned a sequence of timeslots to use. In this way a controlled mobile transponder can always tell which ground stationcontrols it if several are within range.

1.5.2.4. TCP/IP Networking

In a TCP/IP network the most fundamental protocol is the Internet Protocol (IP). In this protocol alldata are packaged into datagrams.An IP datagram contains a header and data. The header in turn is divided into various fields, ofwhich the most important is the destination address. This specifies the desired destination of thedatagram, but IP does not provide a guarantee that a datagram will be delivered to the destinationaddress. If a problem arises, such as overloading of a section of the network, a datagram may belost. It is the responsibility of protocols that use IP to add error recovery if needed.Error recovery is typically dealt with in one of three ways:

1. By using Transmission Control Protocol (TCP), which is a protocol that is specifically designedto provide error recovery. This functionality was utilised throughout the NEAN project. The twoprotocols TCP and IP are commonly referred to as TCP/IP.

2. By a property of the application. An application may provide error recovery as a side effect ofthe way it works. For example, if an application sends a datagram to request information, thelack of a reply indicates that the request must be re-sent.

3. By not requiring error recovery. Some applications may not need error recovery. An example ofthis is a network clock, which periodically sends the current time to it's clients. If a message islost, the client can simply assume its own clock to be sufficiently accurate until the next updateis received.



The ISO/OSI protocol with seven layers is the usual reference model. Since TCP/IP was designedbefore the ISO model was developed it covers only four layers. Table 1 gives a comparison of theTCP/IP and OSI protocol stacks:

Layer OSI Protocol Stack TCP/IP Protocol Stack1. Physical. The transmission media The transmission media

2. Data Link Transmitting and receiving databetween intermediate nodes, not endsystems.

Media Access Sub-layer.Provides access to the transmissionmedia and transmit and receive databetween intermediate nodes, not endsystems.

3. Network Packet routing between end-systems. Internet Protocol (IP) layer.Packet routing between end systems.

4. Transport Reliable sequenced end-to-enddelivery of packets

Transmission Control Protocol (TCP)Layer. Reliable sequenced end-to-enddelivery of packets.

5. Session Authentication , authorisation andsynchronisation of data transfers

NA – Seen as an application task

6. Presentation Data abstraction (ASN.1) for transfer. NA - Seen as an application task

7. Application End user applications. End user applications.

Table 1 - OSI and TCP/IP protocol stack

All specific NEAN services, utilising the ground network, were developed as application servicesexecuting on top of the TCP layer.

Since TCP/IP is a widely adopted standard, working in almost any LAN/WAN networkenvironment, immediate access to a large base of networking software and hardware is available,reducing project developments costs.



1.6. Project EstablishmentThe North European ADS-B Network project (NEAN) was launched at a meeting in Saltsjöbaden,Stockholm November 20 and 21, 1995 as described in [1] and the project officially started January1996 by a Kick Off Meeting in Copenhagen January 17 and 18, 1996 as described in [2]. Theproject was scheduled to run for a period of three years from January 1996 until December 1998.

The NEAN project was funded by the European Commission under the Trans-European Network ofTransport (TEN-T) by Directorate General for Transport – DGVII and by the participating parties.

1.6.1. Partners and Sub-contractors

The Swedish Civil Aviation Administration has been the main contractor of the project and in thiscapacity held the chair in the Steering Committee.

The partners and sub-contractors of the NEAN project are listed in Table 2.

Organisation Country CommentLuftfartsverketSwedish Civil Aviation Administration (SCAA)

Sweden Main contractorand holder of thechair.

Statens LuftfartsvæsenDanish Civil Aviation Administration (DCAA)

Denmark

DFS Deutsche Flugsicherung GmbH (DFS)Research & Development

Germany

United Kingdom Civil Aviation Administration (NATS)Safety Regulation Group

UnitedKingdom

Scandinavian Airlines Systems (SAS) SwedenDeutsche Lufthansa (DLH) GermanyDeutsches Forschungszentrum für Luft- und Raumfahrt (DLR),Institut für Flugführung

Germany Subcontractor toDFS

Ostfriesische Lufttransport GmbH (OLT) Germany Subcontractor toDFS

MAERSK HELICOPTERS Denmark Subcontractor toDCAA

Maersk Oil and Gas Denmark Subcontractor toDCAA

Golden Air Sweden Subcontractor toSCAA

Table 2 - NEAN partners and sub-contractors

A full list of the names and addresses of people involved in the NEAN project is enclosed asAppendix A - The Partners Contact List.



1.6.2. Activities

The application for funding of the NEAN project as originally submitted to Commission [3]comprised an objective of the development and evaluation of various applications (Work Package 4in the original application) using the developed infrastructure. Due to financial reasons thisobjective was removed from the NEAN project and given a project of its own, the ‘North EuropeanCNS/ATM Applications Project’ (NEAP), funded by DGVII under the 4th RTD FrameworkProgramme. The two projects are, however, very closely connected. The separation of NEAP fromNEAN implied a reorganisation of the activities resulting in the following five Work Packages:

Work Package 0: Project establishment.Work Package 1: Installation and trials.Work Package 2: Installation and trials - expansion.Work Package 3: Development of ADS-B Network.Work Package 4: Certification Issues.Work Package 5: Data analysis and reporting.

For a more detailed description of the work packages see '4.1. Work Packages' or [4].



2. Objectives of the NEAN ProjectAs stated in the Terms of Reference for the NEAN project [3] and as mandated by the EuropeanCommission, the overall objectives of the project were to develop, evaluate and demonstrate newtechnologies for data links and networking, and thereby contribute to the implementation of anetwork for Communication, Navigation and Surveillance in the provision of Air TrafficManagement in Europe.

To achieve these objectives, an experimental system developed to prototype level was planned,comprising a network of ground stations in three countries and avionics installed in aircraft andvehicles. Certification and validation issues were also to be addressed by the project.

Further development for commercial and operational use will require the involvement of Europeanindustry.

This statement of the overall objectives has been specified in more detail in the Project DefinitionDocument [4] focusing on three areas:

• Development of infrastructure.• Demonstration to the user community.• Evaluation of the ADS-B surveillance functionality.

2.1. Development of InfrastructureThe objective was to develop an STDMA/ADS-B cellular ground infrastructure with adequateelements for supporting basic demonstrations and evaluations of the STDMA technology and theADS-B application in an ATM context on an international scale.Although the capabilities inherent in the system covered communication, navigation andsurveillance, making a large number of applications possible, the ADS-B functionality was focusedon.

The supporting objectives were to:

• Define relevant message formats and contents for evaluation of the ADS-B functionality.• Define ground network performance requirements needed for evaluation of the ADS-B

functionality.• Investigate requirements for ground station siting.• Specify the ground network architecture including common network standards to be used.• Develop a ADS-B display solution.• Develop required digital maps in a common format.• Install equipment in a variety of fixed and mobile environments.• Develop software for an ADS-B ground data collection system.• Interconnect all ground stations into a large cellular network.



2.2. Demonstration to the user communityThe overall objective was to demonstrate the benefits of an STDMA/ADS-B system to users, withthe North European CNS/ATM Applications Project (NEAP) as the most important demonstrator.


• Allow the NEAN infrastructure to serve as a testbed for NEAP and other projects.• Demonstrate compliance between radar-data and ADS-B.• Demonstrate uplink of radar data (TIS-B).• Demonstrate the STDMA/ADS-B functionality to the widest possible user community.

2.3. Evaluation of the ADS-B surveillance functionalityThe objective was to validate the surveillance functionality of an STDMA/ADS-B based system forATM usage by examining various technical performance parameters of the installed testbed.In addition to this, a cost database should be established by determining cost ofequipment/installations, operating costs and estimated costs for certification.


• Collect data for the evaluation.• Evaluate ADS-B functionality with real-time data flow over a wide area.• Evaluate ADS-B functionality en-route, in terminal and airport environments.• Evaluate the potential to support fleet management.• Evaluate network performance using developed performance requirements.• Assess system performance in terms of reliability and availability.• Determine the coverage of the communication.• Evaluate the emerging standards defined by appropriate bodies.• Examine certification issues.



3. How the Project met the ObjectivesThe objectives of development, demonstration and evaluation were during the project establishment(WP0) broken down to a set of activities spanning five Work Packages (see section '4.1. WorkPackages' p.76). The resulting work breakdown structure was included in the Project Definition [4],which was the final deliverable of the Project Establishment (WP0).

This chapter provides an overview of the major activities performed in pursuit of the projectobjectives.

3.1. Development of InfrastructureThe section describes the major developments performed by the project to fulfil the developmentobjective, but also important developments supporting demonstrations and evaluations.

The overall development objective is given below followed by a list of developments performed toachieve this. The developments are discussed in more detail in the following sub-sections.

Develop an STDMA/ADS-B cellular ground infrastructure with adequate elements for supportingbasic demonstrations and evaluations of the STDMA technology and the ADS-B application in anATM context on an international scale.

• Ground Station Installation• Aircraft and Vehicle Transponder Installation• Map Development• ADS-B Display System• ADS-B Network Development

To support dedicated demonstrations and evaluations the following were also developed:

• Data Collection Tools• Controller Working Position with ADS-B input handling• Point-to-point functionality• Cockpit Display of Traffic Information (CDTI)

To bring the project further ahead the following activities were undertaken:

• Procurement of a next generation of transponders• Development of improved Ground Network Software (The LS/SDS concept)



3.1.1. Ground Station Installation

After initial planning the first development activity carried out was the installation of NEAN groundstations. Setting up NEAN ground stations is equivalent to building one or more ‘cells’ in whateventually became the cellular NEAN ground network.

Three essential elements were performed for ground station installation:

• Obtaining frequency permission.The GNSS transponder is transmitting in the VHF band (136,950 MHz) in a range ofapproximately 200 NM at sea level. As all transmission activities required permission from theauthorities, the partners obtained transmission permissions for the transponders for the durationof the project.

• Performing Site Survey.Many considerations like finding suitable locations for VHF and GPS antenna placement andthe ground station hardware in general were made when a site was chosen. The activity isreferred to as a Site Survey and was performed for a number of sites in Sweden, Denmark andGermany.

• Installing Ground Station Hardware.As a final task the hardware was deployed and activated. Figure 7 shows a generic setup of aNEAN ground station using second generation STDMA transponders. (In the next generationT3 or the VDL mode 4 transponder currently under validation, the DGPS station is an integralpart of the ground station transponder).



Router

Display Stations

Local Server

2xbasebandmodems

LAN

Transponder & Reference Station

VHF Antenna GPS Antenna

PSUPSU

PSU

Transceiver (AUI-BNC) BNC T-Connector +Terminator

WAN

Figure 7 - Generic ground station setup

At the end of the project 17 ground stations were installed. The ground station installation activitiesare detailed in [5].

Figure 8 - Ground Station installations in Esbjerg/Denmark and Bromma/Sweden



3.1.2. Aircraft and Vehicle Transponder Installation

The main contribution of the participating airlines has been to make aircraft available forinstallation of NEAN equipment (transponders and cockpit displays).

The GNSS transponder, the GPS and VHF antennas were physically installed by the airlinecompanies technical departments in accordance with issued Technical Orders (TOs). Theinstallation was solely the responsibility of the Airline Company. Since the equipment was installedin commercial aircraft the installation procedure was cumbersome. The certification of the airbornesystem was on a non-hazardous basis, and the system was never integrated with any other on-boardcomponents.

The first aircraft installation was performed on a dedicated Fokker F-28 aircraft in January 1996.This initial installation was merely aimed for the broadcast of ADS-B on the STDMA data link andprovided very little functionality to the pilots. However, in parallel the development of an interfacefor pilots, the MMI 5000, had already started. The first MMI5000 Cockpit Display of TrafficInformation (CDTI) was installed in December 1996. The second-generation (R2) transponders,initially installed, were on some aircraft upgraded to T3 transponders during 1998.

In addition to aircraft the project also installed transponders in typical airport vehicles. At the end ofthe project more than 16 aircraft and 25 vehicles had transponders installed.

Airline/Operator Aircraft ID Trans-ponder

MMI 5000 EstimatedFlight Hours

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 Puma Helicopter OY-HMH R2 Yes 3000

OLT Fairchild Metroliner III D-COLB R2 No 2600OLT Fairchild Metroliner III D-COLT R2 No 2800SAS 2 x Fokker F-28 SE-DGL

SE-DFGR2/T3 Yes 11000

SAS 2 x DC-9 SE-DASSE-DAW

R2/T3 Yes 2000

SLV Nord 262 OY-IVA R2 No 2000

Table 3 - 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 within the NEAP project.



Figure 9 - Some NEAN mobile installations

The aircraft and vehicle installation activities are detailed in [5].



3.1.3. Map Development

In all systems used for surveillance, geographical maps are essential as references for presentedpositions of aircraft. Display systems used in the NEAN project, required geographical maps overland, lake- and sea-areas as well as detailed airport maps.

To achieve a common WGS84 based NEAN map standard, a special working group was establishedearly in the project (WP1) specifying colours, information detail level and format of the projectmaps. The MapInfo Interchange Format (MIF) was used as a common basis for all digital mapswithin the project and digital maps were developed according to this standard. Figure 10 shows twoexamples.

W

W

R

C

V

C

R

S

W

S

X

T

L

LA

A

K

J

Kto

Jto

Jto

H

G

Cto

Hto

Gto

Hto

Mto

Ato

G

Gto

D

Fto

Fto

F

B

Figure 10 - Digital maps of Kastrup Airport, Denmark and Frankfurt Airport, Germany

3.1.4. ADS-B Display System

To allow users access to the ADS-B data a simple ADS-B display system called AIRSYS was used.AIRSYS was originally developed for a DOS platform but was during the project ported toWindows95/NT by the Swedish team (SWET) and called AIRSYS95.The porting of the software was given low priority, since AIRSYS95 was only considered an interimsolution until a better system could be developed.The Swedish CAA ordered a new ADS-B display system written especially for WindowsNT . Thesystem 'Carmenta Air Traffic Surveyor' (CATS) was used as the default ADS-B display system withinNEAN.It has been possible to download a limited version of CATS on the Internet from the developer'shomepage (Carmenta AB, www.carmenta.se) as an agreement between Carmenta and the SCAA.



3.1.5. ADS-B Network Development

An ADS-B ground network - capable of interconnecting ground-based GNSS transponders into acellular VDL/STDMA network with the purpose of collecting ADS-B position reports - in principledepends on three elements:

• A network model for ADS-B data collection.• The development of amble application software for realising the model.• The deployment of a transport network with a common interface for connecting individual

nodes.

These tasks were conducted and finalised during the ground station interconnection phase (WP3).See [7] for details.

3.1.5.1. Network model for ADS-B data collection

The NEAN ADS-B network model consisted of one or more interconnected national domains,together forming an international domain. For the trials the national domains were Germany,Sweden and Denmark and the international domain was Northern Europe.

A National Operator would have the overall administrative control of a national domain and anational domain would administratively be kept within national borders.There was no single administrative international operator for the international domain.Administration of the international domain was undertaken jointly by the participating nationalauthorities.

Model for Ground Station Interconnection

The primary objective of the ground network within a national domain was to collect ADS-Bposition reports from the individual ‘VDL/STDMA cells’ and in turn offer a full traffic situationpicture for the national domain to the end-users.

The logical topology, which was chosen for the NEAN ground network - within a national domain -was a hierarchical unbalanced n-ary tree. Figure 11.

ADS-B

connect

ADS-B

connect

connect

connect

Figure 11 - Hierarchical tree topology of the NEAN ground network



The entities supporting this structure were the nodes, which created virtual links to a set of pre-defined nodes at a lower level in the tree (‘connect’ arrows). ADS-B position reports (‘ADS-B’arrows) were always ‘routed upwards’ in the tree - towards the root-node - and duplicates werefiltered out at each node. The higher the server was placed in the hierarchy the more position reportsit processed.

The nodes were referred to as NEAN servers: Local, Regional and National servers. The root-nodewas a National Server, the leaf-nodes were Local Servers and the intermediate nodes were RegionalServers.

The initial version of the NEAN ground network did only support routing of ADS-B positionreports and not routing of end-to-end messages. However, during the life cycle of the project theserver software was upgraded also to handle end-to-end messages in a simple way to suit the needsof the PETAL II project.

Models for International Interconnection

A model for tracking GNSS equipped aircraft through multiple national domains - represented bytheir National Servers - was investigated.

The project partners agreed that during the trials all ADS-B reports should be distributed freelyamong the parties, whereas in an operational scenario one would - on the National level - notdistribute position reports for mobile transponders indigenous to the national domain, e.g. airportvehicles.

Figure 12 illustrates the logical interconnection between the German Domain (de), Danish Domain(dk) and Swedish Domain (se). The arrows indicate the ADS-B data flow.

NS

NationalDomain

dk

NS

NationalDomain

de

NS

NationalDomain

sede

se

se+dk

de+dk

Figure 12 - Interconnection of German, Danish and Swedish national domains

The model shows two independent logical connections between the three domains. Swedish ADS-Bposition reports (‘se’ arrow) and German ADS-B reports (‘de’ arrow) collected in the respectivenational domains were passed to the Danish National Server from where they were re-exported tothe relevant neighbouring national domains together with Danish ADS-B data (‘dk’ arrow). TheDanish National Server (NS) performed the necessary filtering to prevent data looping. This modelwas found to be sufficient, but it was considered as an interim solution for the trials only.



3.1.5.2. Application software for realising the model

The key component in realising the model was the software implementation of the NEAN servers(local, regional and national). A single application, NEANSERV, was developed by SWET. Theapplication could be configured to local, regional and national service.

The NEANSERV application acts as a client when connecting to NEAN servers lower in thehierarchy and acts as server for both NEAN servers above in the hierarchy and for Display SystemsClients lower.

On the National level peer-to-peer National Servers were interconnected both with client and servercomponents, indicating that a national domain represented by a National Server can export data toanother National Server without importing data.

Functionality in the NEANSERV application prevented data from looping in the systemindefinitely. Figure 13 shows the client and server elements of the NEANSERV software.

NationalDomain

NEANSERV(National)

NEANSERV(Local)

NEANSERV(Regional)

S

C

AIRSYS95C

NationalDomain

C

S

Client Component

Server Component

S

C

S

C

AIRSYS95C

NEANSERV(National)

S

C

(a)

(b)

(d)

(c)

Figure 13 - Client and server elements of the NEANSERV software

There were no requirements for a particular physical topology; in fact one of the strong points of theNEAN ground architecture was its independence from the chosen transport services.

However, the lack of a Network and Transport layer in the mobile end-systems caused problemswith naming and addressing of Application Entities in the mobile environment and especiallyrouting of text messages. This became evident when the ground server software was extended withend-to-end messages in support of PETAL-II.



3.1.5.3. Deployment of a transport network

Since the participants in the project were using dissimilar network technologies for Wide AreaNetwork (WAN) services in their respective countries, it was decided that the common frameworkof network protocols used in NEAN should be the Transmission Control Protocol and the InternetProtocol TCP/IP. This made it possible to construct a North European IP network built only ofcommercial of-the-shelf (COTS) components capable of utilise any standard WAN/MAN or LANtechnology.

On the transport and network level the project agreed on the following:

• Use of TCP/IP stack for NEAN Servers.• Localised IP name resolution, i.e. no global name service.• Host Naming Conventions. A set of guidelines governing all NEAN naming was agreed upon.• IP networks should be internal with potential access to outside users through firewalls.

The NEAN IP network were realised in Sweden, Denmark and Germany as indicated by thephysical topologies in Figure 14, Figure 15 and Figure 16 (airports are named according to theICAO four letter codes).



In Sweden six ground stations were initially installed. Figure 14 shows the physical topology for theSwedish NEAN segment and part of the NATN backbone on which it relies.

BLS DS DS

DS

LS

DS

DS

B

NS

LS

LS

LS

LS

64kbps leasedline to Denmark

R

LDB MS

DS DSDS

ESSA(Arlanda)

ESMS(Sturup)

ESGG(Landvetter)

ESGJ(Jönköping)

ESSP(Norrköping)

ESSB(Bromma)

DSLS Local Server

Display Station

NS

RS Regional Server

National Server

MS Management Station

IP BridgeB

R IP router (Cisco 2501)

LD Log Device

NATN Backbone Node

FirewallFirewall

Firewall

NATNSwedish Backbone

Frame RelayNetwork

Figure 14 - Physical topology for the Swedish NEAN network



In Denmark initially four ground stations were installed but during the project two more wereactivated one in Billund airport and one in Børsmose close to Esbjerg. The initial physical topologyof the Danish NEAN Segment is shown in Figure 15.

LS

R

64kbps leasedline to Germany

64kbps leasedline to Sweden

Kastrup (EKCH)

Esbjerg (EKEB)

Aalborg (EKYT)

2602

R

LS

DS 2602

LS

IR

DS

R

RS DS

B

DS

B

2602R

R NS

DS

LS

MS

IR26022602

CANDIDanish Backbone

TDM Network

MÆRSK PrivateFrame Relay

2602

SLV/Headquater

Public ISDNNetwork

NT

NT

DSLS Local Server

Display Station

NS

RS Regional Server

National Server

MS Management Station

R IP Router (ACC ‘Nile’)

IP Bridge (ACC ‘Danube’)B

ISDN router (ACC ‘Yukon’)IRR IP router (Cisco 2501)

NT Network Termination2602 NewBridge DTU

Tyra (EKGF)

Figure 15 - Physical topology for the Danish NEAN network



In Germany initially six ground stations were installed and later a ground station in Maastricht wasadded. Figure 16 shows the implementation of the German physical network topology.

To EKCHTo MADAP

X.25German

DFS-PSN

DPN100

RDS

LS

DPN100

RDS

LS

DPN100

RDS

LS

DPN100

R

DS LS

DPN100

R

DS LS

DPN100

R

DS NS

DPN100

R

DS DS

LS

Langen

Maastricht (EDYY)

Köln/Bonn (EDDK)

Frankfurt (EDDF)

Berlin Thf (EDDI)

Bremen (EDDW)

Braunschweig (EDVE)

Hannover

Firewall

DSLS Local Server

Display Station

NS National Server Firewall (Cisco router)

R IP router (Cisco 2501)

Firewall

DPN100

DFS X.25 Switching Equipment

Leased line

Figure 16 - Physical topology for the German NEAN network



3.1.6. Data Collection Tools

The NEAN servers were designed to handle data logging locally, with the possibility to transferlogged data to a central point. However, this facility was disabled, since it required the servers to bedisabled during data retrieval, and since problems with the logging caused the server to crash moreoften than expected.

Two log-devices were developed by the project during the evaluation phase (WP2).

The Swedish CAA and a sub contractor developed a logging device, which writes ADS-B positionreports in an MS SQL Server database for further examination.

The Danish CAA developed a Unix based set of logging tools (LGS tools) which writes ADS-Bposition reports in ASCII files for further examination.

The logging tools were used for data collection in both NEAN and NEAP.

3.1.7. Controller Working Position with ADS-B enhancements

In order to provide demonstration of compliance between ADS-B and radar data, two ControllerWorking Positions (CWP) were developed. The Danish CAA had a downscaled CWP developedcapable of taking ADS-B/STDMA data as input together with multi-radar data in ASTERIXCategory 3.DFS had a CWP augmented with special modules capable of fusing ADS-B/STDMA data and SSRradar data but also with the possibility to display them as individual tracks.

Figure 17 schematically shows the architecture of the Danish CWP system.

STDMA

ASTERIXDriver

DisplayProcessing

ADS-BDriver

Graphical User Interface(GUI) X11/CDE

ASTERIX Cat 3

Figure 17 - Principal dataflow in the DCAA CWP

The CWP-Display Processing contains most of the CWP functionality and the interface to theCommon Desktop Environment windowing system (CDE), through which the CWP Graphical UserInterface (GUI) is realised.

The ASTERIX Driver and the ADS-B driver were special purpose drivers, which handled theASTERIX Category 3 and the ADS-B data flow from the respective sources available on anEthernet LAN interface.



Figure 18 shows the internal data processing of the CWP used by DFS. Data from the two datasources (SSR, STDMA) were sent to the Communication Manager of the CWP. After the data wasconverted into an internal format the data was forwarded to the multi-sensor tracker module. In thestandard configuration all information received for a target from different data sources were fusedto produce a single track for the presentation. For the demonstration of the ADS-B and radarcompliance the fusion of ADS-B data and SSR data was disabled to produce separate tracks for theADS-B and the SSR data. This made it possible to compare ADS-B data with SSR data.

Figure 18 - Principal data flow in the DFS CWP

3.1.8. Point-to-point functionality

The primary focus of NEAN was to demonstrate possible benefits of ADS-B, but the technologyused in the project also had a point-to-point message capability. This functionality was requested bythe EUROCONTROL project PETAL II. The ground network software was during the projectenhanced with a text message routing capability.

The routing of text messages were not based on any standard solution. The primary reason was thelack of support for any kind of standardised protocol in the used generation of the STDMAtransponder. In this context it is important to notice that the VDL Mode 4 standard has provisionsfor ATN.

The NEANSERV ground server based the routing of up-link messages on the number of receivedADS-B reports from a specific aircraft, during a specified time (sliding window). If the reception inthe ground station was above a specified threshold, and the last received report was fresh enough, itcould be used for uplink.Downlink messages had a fixed routing in the NEANSERV system. All messages were routed toMaastricht and PETAL II, since this was the only project requesting point-to-point communications.

CommunicationManager

Multi-SensorTracker

SSR

STDMA

Short TermConflict Alert

Medium TermConflict Probe

...

DisplayProcessing



3.1.9. Cockpit Display of Traffic Information (CDTI)

The development of a Cockpit Display of Traffic Information (CDTI) started before the NEANproject within the Swedish CAA. The basic function of the cockpit display was to provide pilotswith situation awareness by showing the surrounding traffic. The MMI is based on special hardwareand software developed by industry. The result was the MMI5000 unit.

The MMI5000 was found to be an excellent platform for experiments. The basic functionality wasextended in steps with input from several different projects. At the end of the NEAN project, theMMI had the following features:

• Pilot situation awareness based on ADS-B• Moving map, with both background and airport maps• Flight Plan management• Display of NAV Data Base information• Horizontal Track Deviation Indicator, TDI• Support for CPDLC (used in PETAL II)• Support for Conflict Detection and Resolution (used in FREER-3)• Display of ATIS information (used in NEAP)

Figure 19 - Screen dump from MMI5000 cockpit display

The MMI5000 has been installed in two SAS Fokker F-28, two SAS DC9, six Lufthansa Boeing747-200, one Golden Air SAAB 340, one SCAA Flight Inspection aircraft Beach 200, oneMAERSK HELICOPTERS Super Puma and several other smaller aircraft. The MMI has beensuccessfully demonstrated at several exhibitions where the NEAN and NEAP projects have beenrepresented.



3.1.10. Procurement of next generation of Transponders

The plan for NEAN included procurement of a new generation of transponders; ground based,airborne and transponders for ground vehicles. The Swedish CAA led the procurement process. Arequirement specification was finished in May 1996 and the Swedish CAA announced the intentionto procure transponders in the Supplement of the Official Journal of the European Commission onApril 16, 1996. Invitations to tender were mailed on July 1, 1996, to nine companies. At the closingdate, August 23, 1996, two companies had submitted their tenders; The Swedish Space Corporationand SAAB Dynamics, Sweden. A team with one member from each NEAN partner evaluated thetenders.

The Swedish CAA decided to sign framework contracts with both companies. Each NEAN partnercould then use the framework contract for own procurement. The contract with the Swedish SpaceCorporation, from January 1997, comprised ground vehicle transponders, and the contract withSAAB, from April 1997, comprised ground stations and airborne transponders.

The framework contract with the Swedish Space Corporation was never used in NEAN due tobudget constraints. The contract with SAAB was used in both NEAN and the upcoming NorthAtlantic ADS-B Network (NAAN) project. In total 17 ground-based transponders and 10 airbornetransponders were ordered from SAAB Dynamics for the NEAN project. Of these, two groundbased and four airborne transponders were paid by the EUROCONTROL PETAL II project. Alltransponders were ordered by the Swedish CAA due to time constraints and later reimbursed theDanish CAA and DFS, Germany.

The first delivery was delayed until November 1997 and the final delivery until late 1998, whichwas more than 6 month later than scheduled in the contract.

3.1.11. The New LS/SDS Concept

The hierarchical network structure used for the network initially served the project well. However,severe problems emerged concerning availability and scalability of the DOS/PC platform and theNEANSERV software. The NEAN teams generally agreed that the initial architecture based on a DOSplatform, as an operating system was sufficient for the NEAN trials, with only three national domains,but insufficient for any larger scale expansion.

Seen in this light it was found of paramount importance, that the concept for an improved architecturewas examined to some depth prior to further development on the network software. During the ADS-Bnetwork development phase (WP3) the beginning of a new architecture emerged: The LocalServer/Sub Domain Server (LS/SDS) concept.



In brief the key-points of the new architecture can be summarised as:

Separate ADS-B, ATC andAOC models

The ‘all-in-one’ functionality of the current NEAN network entities,enabling both addressed messages (AOC and ATC) and ADS-Bposition reports to be handled by the same mechanism, wasabandoned, due to different network requirements.Instead, it was suggested that the NEAN architecture shouldincorporate three different models, one for each.

Flat Hierarchy The hierarchy was suggested even flatter than in the existingimplementation only allowing two levels of servers ‘Sub-DomainServers’ (SDSs) and ‘Local Servers’ (LSs), where adjacent sub-domains can retrieve data from common LSs. A solution providingtechnical solid expansion/retraction and fall-over scenarios.

ATC Messages only tocovered SDS-Domain

It was decided that only ATC messages could be sent to aircraftwithin the domain covered by the SDS servicing the ATC unit, i.e.ATC messages cannot be sent to aircraft out of view in ADS-B terms.

No National Server The National Server as an entity in the architecture was removed.The National Server (NS) as routing entity was dropped. However,for demonstration purposes, a National Server could still beestablished, but it would not be a centralised key entity in thearchitecture.

Home Server The concept of a Home Server - not unlike mobile IP - wasintroduced to handle low-priority AOC.The main problem was the lack of network addresses in the mobiles.However, simplifying the routing and assuming knowledge about theHome Servers address a working (prototype) model could beachieved.

The Swedish CAA undertook an implementation of the LS/SDS concept for WindowsNT (except forthe Home Server functions) and the resulting server software is considered to be a major improvementof the original DOS based NEANSERV and is briefly discussed below.

The three main components of the implementation are:

• The LS/SDS server• The ASCII interfaces (transponder protocol interface)• An analysis and Configuration Tool

The LS/SDS Ground Server System is developed to support a ground infrastructure based onSTDMA ground stations. A system of ground stations connected with LS/SDS servers is called asub-domain. The LS/SDS Ground Server System has the following basic functionality:

• To collect ADS-B position reports from several ground stations to achieve extended surveillance.• To route point-to-point messages from ground-to-air and air-to-ground within the sub-domain.



There are two types of servers; local servers (LS) and sub-domain servers (SDS):

• Local Servers are used as gateways between STDMA transponders and the ground network.• Sub-domain servers are used to collect and distribute data between several local servers.

The sub-domain consists normally of one SDS and two or more LSs where the SDS is on top in thedomain hierarchy. The sub-domains are independent parts of the ground network. No data isexchanged directly between two different SDSs. If a sub-domain only consist of one LS, there is noneed for a SDS.

The main difference between the LS and the SDS is found in the routing of text messages. The LSwill create join/leave messages for different aircraft, based on the ADS-B reports. A join messagefrom the LS will advise connected servers that the LS is able to uplink text messages to a particularaircraft. The join/leave messages are for example forwarded to the SDS and used as basicinformation for the routing of point-to-point messages in the sub-domain.

A sub-domain may consist of a large number of LSs and base stations. Adjacent sub-domains maybe overlapping, or in technical terms, share one or more base stations. In which case, a particular LScan belong to more than one sub-domain.

Figure 20 - The LS/SDS model

Shared LSs can support different services in different sub-domains. They can be used forsurveillance information and/or point-to-point communication, depending on the configuration.

The sub-domain is dependent on an exact timing source. The LS will get correct time from the basestation (UTC-time from the GPS receiver) and are able to forward the time to the SDS over thenetwork. This requires a connection with minimum delay. Another possibility is to connect a GNSStransponder as a timing source directly to the SDS. If the servers in a sub-domain do not have the



same time base, the functionality can be jeopardised in different ways, e.g. ADS-B reports cominginto a SDS, which has an erroneous time base, might be discarded if the reports are considered astoo old. The routing functionality for point-to-point messages might also be disturbed.

All LS/SDS servers can have several external Application Interfaces (AI) connected. The AI isoften integrated in the external application and is responsible for the data exchange between theLS/SDS server and the application. Special designed AI’s/applications can perform several services,e.g.:

• Create ground/air broadcast messages, addressed to a specific base station.• Send point-to-point messages, addressed to a specific mobile client.• Send service identifiers to an LS, to be used in the net status message.• Receive ADS-B reports and perform filtering before forwarding the reports to other applications.

A so-called ASCII AI is normally installed when the LS/SDS server is installed. From this AI, otherapplications can receive ADS-B position reports, point-to-point messages, differential correctionsetc., in the ASCII format used by the transponder.

At the end of the project the ground infrastructure consisted of a mixed population of LS/SDSservers and the original DOS-based servers.



3.2. Demonstration to the user communityThis section describes the major activities performed by the project to fulfil the demonstrationobjective. The overall demonstration objective is given below followed by a list of activitiesperformed to achieve this. The activities are discussed in more detail in the following sub-sections.

The overall objective was to demonstrate the benefits of an STDMA/ADS-B system to users, with theNorth European CNS/ATM Applications Project (NEAP) as the most important demonstrator.

• Support NEAP demonstrations• Support other projects if required.• Demonstrate compliance between radar-data and ADS-B• Demonstrate uplink of radar data (TIS-B)• Demonstrate the STDMA/ADS-B functionality to large user community

3.2.1. Support the NEAP Demonstrations

The North European CNS/ATM Applications Project (NEAP) was originally a work package withinNEAN, but was for financial reasons executed as a stand-alone sister project to NEAN and with thesame participants.The objective of NEAP was to investigate, specify, develop, test and evaluate civil aviation userapplications and services within an integrated communications, navigation and surveillance (CNS)concept based on the NEAN infrastructure and the STDMA/VDL Mode 4 technology.Activities would focus on the following domains:

• GNSS (Global Navigation Satellite System) Precision navigation capability for all phases offlight.

• Enhanced surveillance for Air Traffic Control (ATC)• Pilot situation awareness

The key element for NEAN was to successfully support the NEAP applications with groundinfrastructure.

The NEAP applications tested and evaluated are essential in meeting the requirements of a futureCNS/ATM system. The following applications were included in the NEAP test program (theresponsible organisation is given within brackets):

• GNSS precision navigation capability for en-route and approach (SAS).• On ground situation awareness and taxi guidance (DLH).• In-flight situation awareness (DLH).• Enhanced ATC surveillance – downlink of aircraft parameters (DFS).• Automatic Terminal Information Service broadcast; ATIS-B (DFS).• Extended helicopter surveillance (DCAA).• Runway incursion (SCAA).

Hence, at least one application, or service, of each component of the CNS/ATM concept wasincluded in NEAP. Combined, they demonstrated a single system solution for seamless gate-to-gate



operations, i.e. a system supporting pilot and controllers in all phases of flight from the departuregate, through pushback, taxiing, take-off, climb, en-route, descent, approach, landing and taxiing todocking at the arrival gate.

An overview of the applications demonstrated within NEAP is given below.

3.2.1.1. Precision Navigation

The precision navigation service demonstrated in NEAP was supported by the STDMA/VDL Mode4 data link. Differential corrections were broadcast from NEAN ground stations and ADS-B reportswere received from equipped aircraft and ground vehicles.En-route navigation and approach testing was conducted using two SAS Fokker 28s on scheduledservice between Stockholm-Arlanda (ARN) and Ängelholm (AGH). The approach into AGH wasmade as an Instrument Approach with Vertical guidance (IPV). Two separate Track DeviationInstruments (TDIs) were installed to provide lateral and vertical guidance to the pilots during finalapproach. The TDIs was used together with the CDTI, which provided situation overviewthroughout en-route navigation and approach phases of flight.A new ground station was developed and installed at AGH. It used a combination of a commercialSCAT-1 system for generating differential corrections and the STDMA/VDL Mode 4 system forproviding two-way data link capability to support DGNSS broadcast and reception of ADS-Breports. New display equipment was installed in the AGH control tower. The availability of theNEAN provided data allowed the controller to seamlessly view aircraft positions from the departuregate at ARN through the en-route, approach, landing and taxiing phases into the parking position atAGH.

3.2.1.2. On-ground Situation Awareness and Taxi Guidance

The demonstrated on-ground situation awareness and taxi guidance service was based on ADS-Breports transmitted and received by six DLH Boeing 747-200 aircraft (B747), other STDMA/VDLMode 4 equipped aircraft and airport vehicles at the Frankfurt International Airport. The ADS-Breports were based on very accurate DGNSS position data transmitted from the Frankfurt NEANstation. High-precision airport maps were used in the B747 cockpit displays. The test programincluded revenue ground operations of the DLH B747s at Frankfurt during the test period.

3.2.1.3. In-flight Situation Awareness

The in-flight situation awareness service was based on ADS-B position reports and radar datauplinked from the ground and received by STDMA/VDL Mode 4 transponders in six DLH Boeing747-200 aircraft. This information was presented on a MMI 5000 CDTI. The display providedprecise area and airport maps on which the positions of ADS-B equipped aircraft and uplinked radardata were superimposed.

Traffic representation on the MMI5000 included a label showing the aircraft identity (usually theflight number), relative altitude and a prediction vector.



3.2.1.4. Enhanced Surveillance

The Enhanced Surveillance for ATC application was based on enhanced surveillance data broadcastby an appropriately equipped experimental aircraft and received by the NEAN ground network.Data was presented on the controller working position of DFS The specification of Download ofAircraft Parameter (DAP) was used to select the information flags. The experimental aircraftsupported the following ARINC 429 labels (information):

• Aircraft address• SSR Mode 3A• Magnetic Heading• Roll angle (bank)• Flight Level (barometric)• Rate of Turn• Ground Speed• Wind Speed (Velocity)• Wind Direction

The DAP data delivered by the ARINC 429 bus system was accepted and converted into theSTDMA/VDL Mode 4 format and then broadcast every second on the STDMA/VDL Mode 4 datalink. Each report contained the aircraft data mentioned above.

3.2.1.5. Automatic Terminal Information Service ATIS-B

The ATIS-B service was based on the data link functionality of the NEAN STDMA/VDL Mode 4system. All German NEAN ground stations automatically broadcast the ATIS information receivedfrom the German Weather Information Automated Systems (WIAS). Appropriately equippedaircraft within the coverage of a German ground station would receive ATIS messages from allparticipating airports. The pilot was given the possibility to display the current, as well aspreviously received ATIS messages from different German airports using the MMI5000 cockpitdisplay system.

3.2.1.6. Extended Helicopter Surveillance

The Extended Helicopter Surveillance service depended on ADS-B position reports broadcast by aNEAN STDMA/VDL Mode 4 equipped helicopter. The position reports were received by groundstations installed in Esbjerg and Børsmose - both located at the Danish West Coast of Jutland - andon the Tyra East platform located in the North Sea, approximately 125 NM from the coast, outsideradar coverage. The ADS-B position reports were distributed through the NEAN groundinfrastructure and displayed together with conventional radar data - when within radar coverage - ona dedicated Controller Working Position (CWP). The CWP was situated in the Copenhagen ATCcentre close to the controllers providing flight information and alerting services for the area.



3.2.1.7. Runway Incursion

The demonstrated runway incursion (prevention) service was based on ADS-B reports fromappropriately equipped aircraft and airport vehicles being presented on a dedicated display in theTWR. The Runway Incursion Monitoring System (RIMS), developed for the NEAP testprogramme, included functions that enabled TWR controllers and vehicle drivers to beautomatically alerted when a hazardous situation developed.

The test scenarios were designed to replicate potential airport conflict situations such as:• Vehicle too close to active runway as aircraft is landing,• Aircraft still on runway as next aircraft is landing.

Alert conditions that apply to these and similar situations were developed. Alert conditions includedwarning when a conflict risk was present, and alarm when there was an actual conflict. Alertsgenerated visual and audible indications.

3.2.2. Supporting other projects

Other projects also using the STDMA/VDL Mode 4 technology were:

• PETAL II• FREER-3• FARAWAY• DEFAMM• TARMAC• SUPRA

Only PETAL II had requirements to the NEAN ground infrastructure. The projects are brieflydiscussed below.

3.2.2.1. PETAL II

PETAL-II is a EUROCONTROL funded project investigating use of air-ground data link toperform real-time Controller Pilot Data Link Communications (CPDLC). One of the data links thatPETAL II is investigating to provide this application is the prototype VDL Mode 4 data link usedwithin NEAN. Prototype VDL Mode 4 ground stations have been installed at the Maastricht ATCCentre by the NEAN team and at the EUROCONTROL Experimental Centre.

The PETAL II project had a major impact on the NEAN project. As a result of PETAL IIrequirements NEAN network capacity had to be improved and some important functions (logging)had to be stopped. As a service provider for PETAL II, NEAN had to improve and co-ordinatenetwork management.



3.2.2.2. FREER-3

Seven European organisations: EUROCONTROL, Luftfartsverket (LFV), DFS DeutscheFlugsicherung GmbH, CARMENTA and the airlines Ostfriesische Lufttransport GmbH (OLT),Scandinavian Airlines (SAS) and Lufthansa are working together to demonstrate airborneseparation assurance in European airspace. Trial flights involving commercial aircraft equippedwith the FREER-III prototype Airborne Separation Assurance System (ASAS) are currently inprogress, running on the MMI5000 CDTI. The first successful trial flight took place on September2, 1998.

In addition to providing situational awareness based on position reports, trajectory broadcasts allowthe display of intentions and onboard detection of potential conflicts, which are displayed in theform of conflict zones. Extended Flight Rules identify the crew responsible for resolution of theconflict. The responsible crew uses a graphical interface to construct a new trajectory.

The initial results were demonstrated at IATA's Global NAVCOM 98 Conference in Berlin, 13October 1998. The demonstration showed that the free flight concept, which forms an integratedpart of the future European Air Traffic Management System (EATMS), has moved beyond papersand simulations.

3.2.2.3. FARAWAY

The objective of FARAWAY is to investigate the enhanced operational performance of groundsurveillance and aircraft navigation through the fusion of radar and ADS-B data. The FARAWAYproject is co-ordinated by Alenia, Italy and involves ATM service providers and airlines inGermany, Italy and Sweden. Three Alitalia MD-82s have been equipped with prototype VDL Mode4 transponders and cockpit displays. One ground station has been installed at Ciampino Airport,Rome.

The project was isolated from the NEAN project. The core testbed was in Italy, but occasionally theItalian aircraft were within coverage of the NEAN network. There was no direct co-ordinationbetween the projects, except the fact that the Swedish CAA was involved in both projects andexperiences were exchanged.

3.2.2.4. DEFAMM

The DEFAMM project is an EC-sponsored demonstration program, which started in the beginningof 1996 and lasted until the end of 1998. The objectives were the implementation of an AdvancedSurface Movement Guidance and Control (A-SMGCS) demonstration system at Köln/Bonn airportas well as the demonstration of the functionality and the benefits of the system increasing theefficiency of the ground traffic management.The system comprised all the functional levels of an A-SMGCS, i.e. surveillance, planning, controland guidance. It made use of the NEAN STDMA transponder as one of several surveillance sensorsand of the STDMA data link for guidance purposes.The DEFAMM project team consisted of 15 partners from industry, research organisations, airportsand Air Traffic Control. Alcatel Air Navigation Systems was the project co-ordinator.



The STDMA system used within DEFAMM at Köln/Bonn Airport made use of a differentfrequency and was thus isolated from the NEAN system. Nevertheless, for testing purposes aSTDMA monitoring station and a transponder was used for data link purposes, transferring test datafrom the test vehicle to a ground station, which utilised the same frequency as the NEAN projectand was within the NEAN coverage area.

3.2.2.5. TARMAC

The TARMAC project was launched by the DLR as an internal project in November 1997 andcontinues to the end of 2001. The objectives are to develop new solutions, system components andprocedures for an integrated A-SMGCS, to perform research work in respective field and to deliverkey inputs to the international A-SMGCS conceptions and design.

An experimental A-SMGCS is under construction at Braunschweig Airport, which comprises themain functional levels of surveillance, planning, guidance and control, flanked by comprehensivetest and simulation facilities. The surveillance part of the system is based on a multi-sensor conceptwith data fusion. STDMA transponders serve as surveillance sensors and provide data linkcapabilities required in the A-SMGCS.

The NEAN base station in Braunschweig, operated by the DLR, is connected to the NEAN groundnetwork and the station is used as a TARMAC subsystem. Results of tests performed throughoutTARMAC, e.g. concerning the reliability of the time stamp in the ADS-B message, have been madeavailable to NEAN and have influenced the technical improvement of the system.

3.2.2.6. SUPRA

This project investigated the benefits of ADS-B to general aviation. SUPRA presented ademonstration of ADS-B at a small airfield outside of Madrid. The project was co-ordinated byIndra, Spain and it was successfully completed in 1997. The project was the winner of the FlightInternational Aerospace Industry Award in 1998.

The SUPRA project was a stand-alone project without any connection to the NEAN network orcoverage.



3.2.3. Traffic Information Service - Broadcast (TIS-B)

In addition to the demonstrations undertaken by the NEAP project, NEAN also demonstratedCompliance between radar data and ADS-B and a Traffic Information Service - Broadcast (TIS-B).This sub-section briefly summarises the TIS-B demonstrator.The TIS-B service was intended automatically to support the pilot with traffic information in theterminal area of Frankfurt airport. The traffic information based on SSR position information waspresented on the MMI 5000 CDTI.

Figure 21 - TIS-B installation in Frankfurt

SSR position information from the radar station Pfälzer Wald (PFW) and Neunkirchner Höhe(NKH) were used for the TIS-B application. The defined sector for the application was in thecoverage of both radar stations. The information from both SSR stations was received from theRMCDE located at the DFS headquarters in Offenbach.

50 NM

Figure 22 - Sector "terminal area" presented on the CWP

RMCDEDFS headquarter Offenbach

DFSX.25 network

(PSN)AIRLINK CWP NEAN

R2 transponder

antennainstallation at the roofof the DFS building

in Langen

SSR dataASTERIX format

TIS-B dataSTDMA format

multi sensortracker

TIS-Bmodule



The SSR position information was transmitted to the AIRLINK controller working position (CWP)via the DFS X.25 packet switched network (PSN). All received SSR data was fused into the multi-sensor tracker of the CWP. The TIS-B module, which also executed on the CWP, requested allposition reports located in the defined sector from the tracker. The sector used for the applicationwas "Frankfurt terminal area" below flight level 100.

The module converted the SSR data from the tracker into the STDMA position report format. TheCWP was not connected to the DFS flight plan data processing system wherefore only thetransponder code was used as an identifier for the position information. After the conversion intothe STDMA format the data was forwarded to the transponder located on the roof of the DFSbuilding in Langen.

For the transmission on the radio link a TIS-B slot area had been reserved. The transponder, whichbroadcasts the TIS-B information, transmits the reservation message for the TIS-B slot area. Every75 time slots (2 seconds) 13 time slots were reserved for the TIS-B application.

0 6 7 28 29 49 50 62 63 74

75 time slots = 2 seconds

D-GPS uplink TIS-B

Figure 23 - Slot allocation scheme for the TIS-B application

To give the pilot the possibility to distinguish the TIS-B information from the STDMA ADS-Bposition reports, different colours were used for the presentation on the CDTI.

Figure 24 - TIS-B presentation on the MMI 5000 CDTI



3.2.4. ADS-B and Radar compliance

ADS-B and radar data compliance was demonstrated for technicians and controllers on twospecialised Controller Working Positions (CWPs) in the Copenhagen ATC centre and at the DFSresearch facility in Langen.

In Langen/Germany the AIRLINK Controller Working Position (CWP) was used for thedemonstration, where the CWP was connected both to a STDMA and an SSR data source.Figure 25 shows the CWP used by DFS for the demonstration.

Figure 25 - Controller Working Position used by DFS

The STDMA data was received from the German National server. The SSR data - from differentradar stations - was received from the DFS packet switched network (PSN) via an RMCDE unitlocated in the DFS headquarter in Offenbach. Figure 26.

Figure 26 - The AIRLINK CWP setup in Langen Germany

RMCDEDFS headquarter Offenbach

DFSX.25 network

(PSN)

AIRLINK CWP

SSR

dat

aAS

TER

IX fo

rmat

NEANground network

NEANnational server Germany

STDM

A da

ta



Figure 27 shows the display of the AIRLINK CWP. The position of the STDMA target D-ABZHand the SSR target 0672 were based on the same aircraft. The aircraft was broadcasting STDMAposition reports with the identifier D-ABZH. Nevertheless a radar station detected the aircraft andan additional track was created with the identifier 0672 (the SSR transponder code).

The altitude and speed values - displayed on the STDMA tracks - were based on GPS height andground speed calculated in the STDMA transponder. Whereas the altitude of the SSR track wasbased on the barometric altitude transmitted by the SSR transponder and the speed was calculatedby the CWP's internal tracker module.

Figure 27 - STDMA and SSR data

In Copenhagen/Kastrup a similar setup was used. Here a CWP processed ASTERIX Category 3multiradar tracks and displayed them together with ADS-B positions obtained from the DanishNational Server.



3.2.5. Demonstration of the STDMA/ADS-B functionality to the user community

The project has through many exhibitions, conferences and a World Wide Web site(www.lfv.se/ans/card) demonstrated the STDMA/ADS-B functionality to a large and wide segmentof various user groups from technicians, ATC controllers, pilots, airport ground crew,administrators and policy makers.

3.2.5.1. Live Data on Internet

During the NEAN project life cycle, it has been possible to monitor the traffic in the network in realtime on the Internet. This has been useful for demonstrations around the world and has showed theconcept for a large number of users with Internet access.

However, the data from all SAS and Lufthansa flights have been encrypted to ensure requiredsecurity. The encryption key has been changed regularly, managed by SAS, and with only a fewproject members having access to the key.

3.2.5.2. List of Exhibitions, Seminars and Conferences Where the Project Was Presented

The project has presented and demonstrated the concept at various meetings, workshops, conferencesand exhibitions with the most important listed below:

February, 1997 Maastricht ATC '97, ExhibitionMarch, 1997 ACC Bremen with OLT (German airline carrier)March, 1997 Demonstration for US Navy in StockholmApril, 1997 GNSS 97 Symposium in MunichApril, 1997 Workshop Cockpit, DarmstadtMay, 1997 Information Technology Week, StockholmJune, 1997 DFS Management ConferenceJune, 1997 FAA visit in GermanyJuly, 1997 Demonstration for Cargo Airline Association in StockholmAugust, 1997 North Sea Helicopter ConferenceSeptember, 1997 ACC BerlinSeptember, 1997 Interairport 97, FrankfurtSeptember, 1997 Riga CNS/ATM SeminarSeptember, 1997 Flight International Air Navigation Conference in AmsterdamDecember, 1997 ICAO AMCP Meeting WG D (VDL) Oberpfaffenhofen/GermanyFebruary, 1998 Maastricht ATC '98, ExhibitionFebruary, 1998 ADS-B Seminar, MoscowFebruary, 1998 IATA Regional Conference in SingaporeMarch, 1998 ADS-B Airborne Avionics Architecture Meeting in StockholmApril, 1998 Swedish Radio Communication Fora in StockholmMay, 1998 CNS/ATM ICAO Conference, RioAugust, 1998 Presentation for Delta Airways and Alaska Airways in StockholmAugust, 1998 Presentation for FAA in StockholmOctober, 1998 Global NAVCOM 98 Conference, BerlinOctober, 1998 Presentation for Airbus Industries in ToulouseOctober, 1998 Presentation for UK NATS in London

http://www.lfv.se/ans/card



November, 1998 Presentation for the Swedish Arm Forces in StockholmNovember, 1998 Presentation for Airbus Industries in StockholmFebruary, 1999 Combined NEAN/NEAP technical demonstration flightFebruary, 1999 Combined NEAN/NEAP demonstration flight and press meeting

Copenhagen-Arlanda

3.2.5.3. Presentation Material Produced by the Project

The following presentation material have been produced:

• Video "Cellular CNS Concept", 1996.• NEAN exhibition material presented at the ATC 97 in Maastricht, February 1997.• NEAN/NEAP exhibition material presented at the ICAO CNS/ATM Conference, Rio de Janeiro,

May 1998.• NEAN/NEAP exhibition material produced by SAS and used at SAS Flight Academy, Stockholm.• NEAN/NEAP Folder containing brochures (NEAN, NEAP, NAAN) and information papers (VDL

Mode 4, Applications, SMGCS, etc), presented at the ICAO CNS/ATM Conference, Rio deJaneiro, May 1998.

• Poster "CNS/ATM Applications in Reality".• NEAN/NEAP video "CNS/ATM, Northern Europe Shows the Way".• Information about NEAN/NEAP have been presented on the CARD web, www.lfv.se/ans/card

and on the NEAP site www.neap.dk

Figure 28 - NEAN Exhibition Display

http://www.lfv.se/ans/card



3.3. Evaluation of the ADS-B surveillance functionalityThe section describes the activities performed by the project to fulfil the evaluation objective.

The overall objective for the evaluation is given below followed by a list of activities performed toachieve this. The activities are discussed in detail in the following sub-sections.

The objective was to validate the surveillance functionality of an STDMA/ADS-B based system forATM usage by examining various technical performance parameters of the installed testbed.In addition, a cost database should be established by determining cost of equipment/installations,operating costs and estimated costs for certification.

• Technical examination of the NEAN infrastructure• Examination of certification issues• Cost Database establishment

3.3.1. Technical Examination of the NEAN infrastructure

During the main evaluation and test phase (WP2) the deployed infrastructure was examined forvarious technical parameters regarding:

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

The intention of the technical evaluation was to reveal weak points of the concept and not tocompare results with requirements for an operational system, since the infrastructure was not builtfor operational use.

The technical tests were:

• R1 - Air-Ground Data Link Reliability• R2 - Ground-Ground Data Link Reliability• R3 - Static Absolute Position Accuracy for Ground Vehicles • R4 - Dynamic Relative Position Stability for Ground Vehicles• C1 - Air-Ground VHF Long Range Coverage• C2 - Airport System Coverage• P1 - Ground Network Delay• P2 - System Delay• A1 - Ground System Availability • A2 - Reliability of Airborne GNSS Transponders

A short summary of the tests is given below. For details of the test and their results see [6].



3.3.1.1. R1 - Air-Ground Data Link Reliability

The 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 the completeness of the delivered surveillance data by examining whether thesystem lost incoming data.

During the test period, all flights through a defined full coverage area were recorded from a singlebase station. The number of received ADS-B reports was counted for each flight. Calculation of theexpected number of ADS-B reports from a specific flight, was made by using the time when theflight entered and left the full coverage area and the known transmission rate of the ADS-B positionreports.

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.



3.3.1.2. R2 - Ground-Ground Data Link Reliability

The objective was to show the feasibility of using the technology as part of SMGCS applications,by examining the data link reliability within a typical airport environment.

A mobile transponder was installed at the Tower in Frankfurt Airport, from which text messageswere transmitted once per second. As payload the text messages contained a block counter,incremented for every transmission, thus making it possible to detect missing receptions and toevaluate the width of reception gaps.

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.

3.3.1.3. R3 - Static Absolute Position Accuracy for Ground Vehicles

The objective was to determine the absolute position accuracy for a ‘fixed-mobile’ over severaldays. The test was performed in an 'real' airport environment to obtain realistic results and touncover potential error sources like multipath effect.

Fixed-mobiles were mounted at known locations in Copenhagen and Frankfurt within range of therespective airport ground stations from where the differential corrections were received. Positionreports were logged directly at the fixed-mobile. Statistical variations in the collected data werecalculated with reference to the known location of the fixed-mobile.

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 seemed 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.



3.3.1.4. R4 - Dynamic Relative Position Stability for Ground Vehicles

The purpose was to examine the relative position stability for Ground Vehicles in motion in anassumed full VHF coverage area.

A mobile GNSS transponder was mounted on the Frankfurt airport inter-terminal shuttle train,which follows the same track continuously. ADS-B position reports were collected at the airport'slocal server and analysed with respect to deviation from the assumed track.

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.



3.3.1.5. C1 - Air-Ground VHF Long Range Coverage

The purpose was to determine the long-range VHF coverage for all NEAN ground station locationsin terms of outer boundaries of the coverage area.

The long-range VHF coverage was examined by collecting ADS-B position data from individualground stations and calculating entry/exit points of aircraft when they entered and left the coveragearea.

No special test-flights were flown. The test was based on ordinary scheduled flights by GNSSequipped aircraft.

The project demonstrated a significant ADS-B coverage area in Northern Europe with 17GroundStations.

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.

3.3.1.6. C2 - Airport System Coverage

The purpose was to compile and visualise information of the system coverage (both GPS and VHF)for ground vehicles operating in a typical airport environment.

The test was carried out in Frankfurt International Airport, where ADS-B position reports werecollected from GNSS equipped ground vehicles passing through typical generic airport areas andthe captured positions were processed with respect to losses and variations in NAV-modes.

Three critical areas were found in the terminal area of the airport. The largest area is the area closeto the eastern terminal building 2. A smaller area is close to the gates C and the smallest one is onthe 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.

3.3.1.7. P1 - Ground Network Delay

The purpose was to collect information on ground network delay times for all logical links in theNEAN network. The delay times collected are round trip times for an Internet Control MessageProtocol (ICMP) packet the same size as a default ADS-B position report.

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.

3.3.1.8. P2 - System Delay

The objective was to measure the total system delay-times for messages sent from end-system toend-system, ground-to-air and air-to-ground.

A special text message was designed for the test. The principle was to time stamp the message inthe ground end-system before it was transmitted to the aircraft. The message was once again timestamped in the on-board end-system (MMI5000) and sent back to the originator.

The test message was transmitted automatically and periodically to known targets from a specialapplication on ground.

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.



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.

3.3.1.9. A1 - Ground System Availability

The objective of this test was to record the availability of a homogeneous segment of the groundsystem (Danish segment) and the international interconnections. NEAN was not designed for high-availability and the main reason for carrying out this test was to register periods when recording ofADS-B data was possible rather than to check the results against operational availabilityrequirements.

The test was based on GPS status reports originating from ground station transponders and madevisible in the network through the local servers connected to the ground stations.

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.



The following issues should be addressed in order to improve 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

3.3.1.10. A2 - Reliability of Airborne GNSS Transponders

The 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.

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 beneficial to make an in-depth study of theR2/T2/T3 reliability.

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 backeverything 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.



3.3.2. Certification Issues

One of the main objectives of EU legislation is the harmonisation of the existing practices of themember states and the removal of arbitrary technical barriers to the free movement of goods andservices. This also applies to the field of Air Traffic Management (ATM).The project performed a survey of legislation relevant to ATM that briefly summarises the relativeimpact of each piece of legislation [8].

The surveyed list of European legislation affecting civil aviation is not exhaustive, indeed, otherlegislation such as the Public Procurement Directive are also applicable, but have a less directeffect. However, the brief survey indicates that a broad swathe of directly relevant Europeanlegislation exists and is directly applicable. Unfortunately, the main characteristics of thislegislation at present, is the apparent lack of enforcement. Legislation that is not properly enforcedcreates ambiguities leading to wasteful confusion and disarray - opening the door to real harm. Theeffects of this can clearly be seen in a divided European market dominated by non-Europeaninterests. Nevertheless, assuming steady implementation and enforcement, the effects of thislegislation will become increasingly significant.

Particular difficulties are created by the demands of civil aviation bodies for specific and exclusivelegislation confined to purely safety concerns. This approach effectively ignores all other aspects,such as economic or trade issues. For example, aviation authorities have signed bilateral agreementsas if they were purely safety agreements, ignoring economic and market matters of realsignificance. This view also ignores the consequences of other legislation - not only on theregulated industry, but on the regulatory authority itself. In particular, the difficulties of partiallyoverlapping legislation or legislation having a 'horizontal' effect (i.e. generic legislation).

Despite this, it is clear that a significant body of legislation exists which can provide a basicframework within which the Safety Regulation of ATM can be based. The major obstacles lie withthe National Authorities, their acceptance, and their willingness to work within such a framework.In addition to specifically ATM related legislation, there is also a significant volume of genericlegislation in fields such as telecommunications, which must be taken into account.

As the NEAN project and the equipment involved were never intended nor allowed to be integratedwith existing on-board aircraft systems, only a non-hazardous certification of the GNSStransponders and the MMI5000 cockpit displays was undertaken (the JAA Form One Certificate).



3.3.3. Cost Database

The project has focused on development, demonstration and evaluation and the implementation wasnot designed for an operational environment. Some system components would be more expensive inan operational environment while others - specifically developed for the NEAN project - would beless expensive if produced in larger numbers. This must be taken into account if a comparison ismade with alternative system solutions. Cost estimates for certification has not been addressed.

It should also be emphasised that the some costs presented here for the used components are genericbut based on the actual cost, since cost for COTS items varied among partners. These items aremarked with an asterisk (*).

All costs are stated in ECU on a 1998 index in rounded figures.

3.3.3.1. Equipment and Installation Costs

Equipment and installation costs are specified for the following system components

• Base stations• NEAN Server, Display and Management Unit• Network• Aircraft• Vehicles

Cost Item Cost in ECUR2 transponder 9.800Leica MX 9112 DGPS Reference Station 9.700Baseband modems (*) 500Installation including GPS and VHF antenna (*) 10.000Total Costs 30.000

Table 4 - Base station costs using an R2 transponder

Cost Item Cost in ECUT3F transponder 23.500Baseband modems (*) 500Installation including GPS and VHF antenna (*) 10.000Total Costs 34.000

Table 5 - Base station costs using a T3F transponder



Cost Item Cost in ECUPentium PC incl. MS DOS v/6.20 (*) 2.600Server software (*) NAInstallation (*) 800Total Costs 3.400

Table 6 - NEAN server unit costs

Cost Item Cost in ECUPentium PC incl. WindowsNT 4.0 (*) 2.900Display software (*) NAInstallation (*) 800Total Costs 3.700

Table 7 - NEAN display unit costs

Cost Item Cost in ECUPentium PC incl. WindowsNT 4.0 (*) 2.900Network management software (*) 1.800Installation (*) 800Total Costs 5.500

Table 8 - NEAN management unit costs

Cost Item Cost in ECUIP-router incl. sundries (*) 3.000Installation (*) NATotal Costs 3.000

Table 9 - Network IP-router costs

Cost Item Cost in ECUInstallation of international line, CPH-Stockholm 6.400Installation of international line, CPH-Bremen 4.000

Table 10 - International line installation costs



The airborne installation costs covers three different types of aircraft:

• Fairchild Metroliner III• Fokker F28• Boeing 747-200

Cost Item Cost in ECUR2 transponder 9.800Installation including GPS and VHF antenna 5.100Total Costs 14.900

Table 11 - Aircraft costs for a Fairchild Metroliner III

The installation of the complete system in the SAS Fokker F28 was rather complicated, because aVHF antenna, a GPS antenna, a transponder and a display had to be installed. This major work (90man-hours for two aircraft) had to be carefully co-ordinated with other activities. The installationtook 7 days for the first aircraft and 5 days for the second.

Cost Item Cost in ECUT3M transponder 23.000MMI5000 16.300Installation including GPS and VHF antenna 30.000Total Costs 69.300

Table 12 - Aircraft costs for a Fokker F28

Cost Item Cost in ECUT3M transponder 23.000MMI5000 16.300Installation including GPS and VHF antenna 36.600Total Costs 75.900

Table 13 - Aircraft costs for a Boeing 747-200 Jumbo

Cost Item Cost in ECUR2 transponder 9.800Installation including GPS and VHF antenna (*) 1.000Total Costs 10.800

Table 14 - Vehicle costs



3.3.3.2. Operating Costs

Manpower costs for network maintenance has not been addressed.

3.3.3.3. Network Operating Costs per Year

These cost are very much dependent on national telecommunication price policies.

Cost Item Cost in ECUInternational line, CPH-Stockholm 13.700International line, CPH-Bremen 26.900

Table 15 - International line costs per year



4. The Project Life CycleThis chapter provides an overview of the project life cycle.

4.1. Work PackagesThe following five Work Packages (WP1 to WP5) covered all project activities during the threeyear project life cycle:

Task NameNEAN Project WP 0 - Project Definition

WP 1 - Installation and Trials (1)

WP 2 - Installation and Trials (2)

WP 3 - Development of ADS-B Network

WP 4 - Certification Issues

WP 5 - Data analysis and Reporting

��

��

��

��

��

Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q41996 1997 1998

Figure 29 - Project timetable

Work Package 0: Project establishment.

The participating parties agreed on the configuration of the network and theproject work procedures. The Work Package was completed February 1996and the deliverable: ‘NEAN Project Definition’ [4] was presented to theCommission.

Work Package 1: Installation and trials.

Basic installation of ground stations was carried out. The Work Packagewas completed October 1996 by the presentation of the deliverable: ‘WorkPackage 1 - Progress Report’ [5] to the Commission.

Work Package 2: Installation and trials - expansion.

Basic installation of equipment in aircraft and dedicated technicalevaluations were carried out within this Work Package. The work onvalidation of the VDL Mode 4 data link with the ICAO provisional SARPsis still ongoing and is expected not to be finished within the NEAN project,but to be continued within the NEAN Upgrade Programme. The WorkPackage was completed March 1999 by the presentation of the deliverable:‘Work Package 2 - Progress Report’ [6] to the commission.



Work Package 3: Development of ADS-B Network.

The interconnection of all base stations was done. The Work Package wascompleted January 1997 by the presentation of the deliverable: ‘WorkPackage 3 - Progress Report’ [7] to the Commission.

Work Package 4: Certification Issues.

The work of examination of certification of the various components of theinfrastructure for operational use was carried out. The Work Package wascompleted October 1997 by the presentation of the deliverable: ‘WorkPackage 4 - Progress Report’ [8] to the Commission.

Work Package 5: Data analysis and reporting.

Data analysis and final reporting was carried out. The Work Package wascompleted March 1999 by the presentation of the final Work PackageProgress Report: ‘Final NEAN Project Summery and Conclusion Report’(this document) to the Commission.



4.2. List of Meetings held within the ProjectDuring the life cycle of the project, several Steering Committee Meetings and Project GroupMeetings have been held. It has been the policy of the project, as outlined in the Project Definition[4], that each partner on an alternating basis should host both Steering Committee Meetings andProject Group Meetings.

4.2.1. Steering Committee Meetings

1996-01-17/18 Kick Off Meeting Copenhagen, Denmark1996-03-01 Steering Committee Meeting No.2 Frankfurt, Germany1996-05-28 Steering Committee Meeting No.3 Malmö-Sturup, Sweden1996-09-04 Steering Committee Meeting No.4 Copenhagen, Denmark1996-10-24 Steering Committee Meeting No.5 Frösundavik, Sweden1997-01-16 Steering Committee Meeting No.6 Frankfurt, Germany1997-05-23 Steering Committee Meeting No.7 Gatwick, England1997-09-02 Steering Committee Meeting No.8 St.Anna, Sweden1997-11-28 Steering Committee Meeting No.9 Copenhagen, Denmark1998-03-05 Steering Committee Meeting No.10 Norrköping, Sweden1998-05-28 Steering Committee Meeting No.11 Frankfurt, Germany1998-09-15 Steering Committee Meeting No.12 Arlanda, Sweden1998-12-01 Steering Committee Meeting No.13 Frösundavik, Sweden

4.2.2. Project Group Meetings

1996-02-20/21 NEAN Working Meeting Malmö-Sturup Airport, Sweden1996-04-11/12 Project Meeting No.2 Copenhagen, Denmark1996-05-30/31 Project Meeting No.3 Frankfurt, Germany1996-06-25/26 Project Meeting No.4 Norrköping, Sweden1996-09-05/06 Project Meeting No.5 Copenhagen, Denmark1996-10-01/02 Project Meeting No.6 Braunschweig, Germany1996-11-07/08 Project Meeting No.7 Frankfurt, Germany1997-01-14 Project Meeting No.8 Stockholm-Arlanda, Sweden1997-02-05 International Interconnection Meeting Copenhagen, Denmark1997-02-12 Project Meeting No.9 Copenhagen, Denmark1997-04-15 Project Meeting No.10 Langen, Germany1997-04-22 ADS-B Security Meeting No.1 Stockholm, Sweden1997-06-18 Project Meeting No.11 Langen, Germany1997-08-19 Project Meeting No.12 Malmö, Sweden1997-09-09 PDC/ATIS Meeting Langen, Germany1997-10-21/22 Project Meeting No.13 Copenhagen, Denmark1998-01-15 Project Meeting No.14 Langen, Germany1998-03-06 Project Meeting No.15 Norrköping, Sweden1998-04-06 Project Meeting No.16 Arlanda, Sweden1998-06-24 Project Meeting No.17 Copenhagen, Denmark1998-08-26 Project Meeting No.18 Langen, Germany1999-02-01/02 Project Meeting No.19 (Review) Copenhagen, Denmark



4.2.3. Map group Meetings

1996-06-25 Mapgroup Meeting No.1 Copenhagen, Denmark1997-03-14 Mapgroup Meeting No.2 Braunschweig, Germany

4.2.4. NEAN/PETAL Meetings

1998-06-30 NEAN/PETAL Meeting No.1 Langen, Germany1998-10-12 NEAN/PETAL Meeting No.2 Brussels, Belgium



4.3. Specific ProblemsThis section describes some of the major problems the project faced, which were not related to thetest cases carried out during Work Package 2. For a detailed description of the problemsencountered during the Work Package evaluations, see [6].

4.3.1. Transponders

The GNSS transponder was the core of the NEAN project and substantial effort was spent onprocurement/testing of a new generation of transponders. The second generation transponders(R2/T2 from Swedish Space Corporation) initially used in the project, were replaced by T3transponders from SAAB Dynamics in 1998, almost a year late according to the timetable due todelayed delivery from SAAB.

R2/T2 transponders were used both in aircraft and on ground, and they are still not fully replaced.They are still installed in the OLT Metroliners and in the helicopter from MAERSKHELICOPTERS.

The R2/T2 transponders have in general been working well. There have occasionally been problemswith the GPS receiver, in terms of navigation problems, which require a reset operation. Anotherunfortunate characteristic of the built-in GPS receiver is the low position update frequency. Allmobile transponders have been programmed to transmit its position once every second. The GPSreceiver may fail to calculate a new position before the position is transmitted on the data link or onthe serial line to the cockpit display. In these cases the same position 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 caused by configuration changes.

The R2/T2 transponders used at ground stations showed a tendency to enter “maintenance mode”unintentionally. When the transponder is in maintenance mode it will echo back everything on theRS232 data port. This, in combination with the DOS based server software, caused “broadcaststorms” in the network and severe server crashes. A safer way to enter maintenance mode solvedthe problem.

The new T3 transponder had several software problems in the beginning. The most serious problemaffected the timing of the transponder, and SAS and Lufthansa aircraft were flying several monthswith this fault. Reliability and performance tests may have been affected by this error.

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 minutes ormore. Unlike the R2/T2, the T3 transponder has no battery backup for the GPS receiver. Accordingto the specifications for the receiver, this should not have prevented a short start-up time, and it isuncertain whether a battery backup would solve the problem.

The SAAB T3 aircraft transponder is sensitive to different, so called, slot reservation messages sentfrom base stations, and has proven to be more sensitive than the T2/R2 transponder. The T3transponder will use the latest received slot reservation message and abandon planned transmissions



of ADS-B reports if they are in conflict with the slot reservation. There have been periods duringthe project when different slot reservation messages have been transmitted from the ground stationstransponders, which have affected the transmission of ADS-B reports from the T3 transponders.

4.3.2. Certification

All equipment installed in an aircraft must be certified. The certification process becomescomplicated if one system shall interact with another certified system on-board the aircraft. Allequipment used on-board in the project were therefore certified to a non-hazardous level and had aJAA Form One Certificate. The MMI5000 CDTI and the transponder are separated from all othersystems on-board.

4.3.3. Ground Network

In the beginning of the project, the ground network consisted of 15 servers, built on a DOSplatform. The server system, called NEANSERV, was already in use in an experimental ADS-Bnetwork in Sweden. It was important for the NEAN project to start up the practical work as soon aspossible, to gain experience from the technique. The aim was to produce a requirement specificationfor a better network later in the project.

The NEANSERV was later extended with point-to-point message routing functionality. Thisextension was necessary for the EUROCONTROL PETAL II trial, which used the NEAN networkand the SAS/DLH aircraft.

There have been several problems with the NEANSERV software. The most significant were:

• Unstable operating system, not suitable for 24 hours operation.• Unstable communication (TCP/IP) stack.• Capacity problems, in terms of possible connections and data processing.• Dangerous handling of broadcast and point-to-point messages.• Lack of documentation

The stability problems were partly solved by a hardware “watch-dog” card in each server, but theservers were occasionally observed to restart several times per hour. The capacity problems were insome extent solved by switching off the logging functionality, but still the German National Serversuffered from a very high data load. Proper handling of broadcast messages and point-to-pointmessages was never finalised. A small mistake in the configuration could lead to oscillation in thenetwork.

The NEANSERV was later replaced by the LS/SDS ground network server system, based onWindowsNT . The LS/SDS was designed from the beginning to handle both ADS-B and point-to-point messages, which resulted in a more stable system.



4.4. Delays

4.4.1. Delayed T3 transponders

The main delay in the project was caused by late delivery of procured SAAB Dynamics T3transponders. The first transponder should have been delivered June 1. 1997, and the last inNovember 1997. The final delivery was in late 1998. The main reason, according to SAABDynamics, was quality problem with the hardware, delivered by a sub-contractor, but severalsoftware problems were also found on the T3s causing additional delay.

The following experiences can be noted:

• SAAB had less experience from the previous R2/T2 transponder than expected.• Certification processes (for CE and JAA) are very time consuming.

4.4.2. NEAN as PETAL II provider

The PETAL II project, sponsored by EUROCONTROL, used the NEAN infrastructure for CPDLCtrials.

The NEAN network was not prepared for end-to-end messaging from the beginning. NEAN was anADS-B network and had no functionality for routing of text messages. However, this functionalitywas added to ground servers after a contract with PETAL II was signed regarding provision of end-to-end messaging. The first implementation of text message routing was not successful, and theNEAN network was unable to fully work as a PETAL II provider until the second generation ofground network was installed.

By the end of 1998, NEAN was used by many projects performing their own trials. The groundstations had to be switched off and on and software - both in ground servers, transponders andcockpit displays - were regularly upgraded in order to support different needs. PETAL II – whichrequired a stable service - was probably the project that suffered the most from this.



5. ConclusionThe overall objective of the NEAN project was to develop, evaluate and demonstrate newtechnologies for data links and networking, and thereby contribute to the implementation of anetwork for communication, navigation and surveillance in the provision of Air TrafficManagement in Europe.

The North European ADS-Broadcast Network (NEAN) project has successfully demonstrated thepotential of ADS-B and STDMA/VDL Mode 4. The NEAN and North European CNS/ATMApplication Project (NEAP) have also successfully demonstrated complementary applications suchas up-link of TIS-B and ATIS-B, CDTI, etc. The magnitude of the demonstrations can be seen bythe estimated flight hours for the aircraft and helicopters used in the NEAN trials. The size of thecoverage area, the number of equipped aircraft and ground vehicles, and the number of flight hours,make NEAN a unique ADS-B system in the world today.

The NEAN project has been presented at several important conferences and exhibitions during1996-1998, and a long list of material, such as videos, information brochures, etc, have beenproduced in the framework of NEAN. The number of people around the world with knowledgeabout NEAN and STDMA/VDL mode 4 has significantly increased during the project.

The NEAN project succeeded in establishing an experimental system, developed to prototype level,comprising several networked base stations and avionics in multiple aircraft in Denmark, Swedenand Germany and demonstrated the potential of ADS-B and STDMA/VDL Mode 4 within Europe.In addition to this development NEAN successfully provided the NEAP project with a sufficientinfrastructure for the development, test and demonstrations of various applications and alsoconducted own technical evaluations of the deployed infrastructure and thus met its overallobjectives.

Early in the project the consortium established the fifteen planned base stations throughout Sweden,Denmark and Germany, and later on a few more were added. All base stations were interconnectedusing both dedicated national and public leased lines thus demonstrating a significant ADS-Bcoverage area in Northern Europe. Figure 30 shows a sample of the recorded flights in the NEANcoverage area.

At the end of the project 17 dedicated NEAN base stations were up and running and interconnected,19 aircraft and more than 25 vehicles were equipped with transponders.

The development of the infrastructure was not free from problems and delays. Most of the technicalproblems occurred in the ground network not related to the data-link. New technologies wereimplemented in an experimental way, which were never expected to be free from problems.However, the project managed to solve these problems and important experiences were collected.

The most significant delay in the project was related to the delivery of the new T3 GNSStransponders. The last delivery was almost a year late, which caused some problems for theevaluation.



Figure 30 - Sample of recorded flights within the NEAN coverage area

Only the used GNSS transponder, Cockpit Display of Traffic Information (CDTI) and serversoftware were manufactured especially for the project – all other components were commercial-of-the-shelf products including various brands and types of soft- and hardware.

The components were seamlessly integrated into an experimental system, indicating that an ADS-BSTDMA/VDL Mode 4 surveillance solution could be established in a cost-effective and relativelyeasy way. The established cost database indicates that the used technology can significantly reducethe infrastructure costs, especially if the installations are used for several CNS/ATM applications.The potential savings the technology offers the total aviation community were not addressed in theframework of the NEAN project.

During the project it was decided that the NEAN network should provide the infrastructure for thePETAL II trials and the basic NEAN ADS-B surveillance capability was enhanced withrudimentary end-to-end messaging capabilities. This caused problems, since the ground system wasnot originally designed for end-to-end messaging and the airborne STDMA equipment did not haveproper network level addressing as envisioned in the VDL mode 4 standard.



However, from the work carried out the project can conclude that benefits can indeed be expectedby ADS-B and air-air, air-ground and ground-ground data link. The example below illustrates this,based on an identified bottleneck:

Bottleneck Restricted approach- and SMGCS-capacity during unfavourable weather conditions,due to safety.

Problem: Lack of proper situational awareness for both controllers and pilots.Solution: Improved surveillance/identification of essential traffic and display to both controllers

and pilots.Need: ADS-B, CDTI (Cockpit Display of Traffic Information), "station keeping" during

approach and taxi (as demonstrated in NEAP).Benefit: Better use of existing airport capacity in unfavourable weather conditions, and high

safety (e.g. IMC conditions prevail at Frankfurt airport in roughly 20 % of time).

Viewed in a global perspective, ADS-B based on STDMA/VDL mode 4 could provide significantincrease in both safety and efficiency in remote areas, in a cost-effective way, where no otheradequate surveillance infrastructure is available or affordable. The STDMA/VDL mode 4 self-organising mechanism for exchange of ADS-B data between independent aircraft/vehicles has beenworking very well during the NEAN trials and is the corner-stone of such a system.

In the long term, it should be possible to expect further reduced separation minima (less than 5NM), also in the dense Central European airspace environment, based on precise, reliable andfrequently updated position data such as the ADS-B data used in NEAN. But even more importantin the future are all new types of applications and procedures based on ADS-B that can beimplemented and can support an increase in the traffic flow in air and on ground.

Although the project has achieved encouraging results, operational implementation is still beinghampered by a number issues. Since NEAN is an experimental infrastructure, many of these are of atechnical nature, but also more general issues, in particular, the standardisation, certification andcost-benefit analysis issues have to be clarified.

The validation of the ICAO provisional SARPs for the VDL Mode 4 data link is still ongoing andexpected to be finished during 1999. Therefore, the NEAN project has used equipment based onSTDMA, which is the basic technology in the VDL mode 4 standard.

Criteria for certification depend on the chosen applications. The use of ADS-B together with e.g.trajectory data, will open for a new generation of applications and procedures, as seen in theNEAN/NEAP trials, and it must be possible to certify these in a proper way. In the foreseeablefuture (next 10-15 years) ADS-B will not replace the existing infrastructure, but gradually becomethe most important technology for surveillance. Certification can follow a stepwise approachtowards “sole means” as the potential final target, with less stringent certification criteria in theinitial phases.

In order to enable decision making it has to be clarified what really are the costs and the resultingbenefits of new technologies. Applications based on STDMA/VDL mode 4 and ADS-B are likely toincrease both capacity and safety in a cost-effective way, but a real cost-benefit analysis has notbeen performed in the framework of NEAN.



Principal conclusions:

• A surveillance concept based on ADS-B and STDMA, can be used in all phases of flight and forvarious types of vehicles (aircraft, helicopters, ground vehicles).

• STDMA/VDL mode 4 equipment can relatively easy be installed in different types of vehicles.• STDMA/VDL mode 4 equipment can be used for more applications than ADS-B.• A surveillance infrastructure could be developed and maintained by using existing technologies

and network concepts.• Scalable and dynamic infrastructure. It was comparatively easy to modify the surveillance

infrastructure according to need, e.g. by adding new ground stations to improve coverage orreliability.

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

• Issues regarding standards, certification and cost-benefit must be further investigated to obtainan operational system.



6. Future PlansSwedish Civil Aviation Administration (SCAA)

The Swedish CAA will mainly continue the work with ADS-B within the EU funded NEANUpdate Programme, NUP. NUP aims at operational and certifiable applications based on the VDLMode 4 standard. NUP will be funded (approx. 50%) by the European Commission in theframework of the Trans-European Network, TEN-T. NUP will formally be launched in 1999.

The decision within the Swedish CAA to continue the work in NUP, is based on the following:

• The Swedish CAA has been working with the VDL mode 4 technology for several years and isconvinced that it is the most promising enabler of needed new solutions in air trafficmanagement.

• The interest from the civil aviation community in the possibilities with ADS-B/VDL mode 4,demonstrated in NEAN, has also convinced SCAA to continue in NUP.

• The operation of the NEAN infrastructure over three years has formed the basic ideas for anoperational concept, which is essential input to NUP.

• NUP is the first project based on VDL mode 4 that aims at operational applications.• The mix of organisations participating in NUP (ATM/airport authorities, airframers, airlines and

system manufacturers), is very powerful and a prerequisite for success.• NUP will produce important input to different standardisation processes within ICAO,

EUROCAE etc., in which the Swedish CAA already is active.• There has been a strong interest from the European Commission in NEAN/NEAP/NUP, which

is another prerequisite for success in such projects.

Besides NUP, the Swedish CAA will continue the work in FARAWAY II and other EC fundedprojects using the STDMA/VDL Mode 4 technology. The operational use of the ADS-B technologyfor runway incursion/ground vehicle management at Stockholm-Arlanda airport, will also continueover the coming years. The operational benefit is substantial and more applications will bedeveloped.

New systems for ATM in TWR/ATC administrated by the Swedish CAA, such as systems in thenew tower at Arlanda Airport, will be prepared for ADS-B data.

Discussions and experiments together with the Swedish Coastguard and the Swedish Military in theframework of Search and Rescue will continue.

Danish Civil Aviation Administration (DCAA)

Since DCAA began its involvement in the NEAN/NEAP projects in 1996, several initiatives havebeen taken to further investigate the use of ADS-B supported by STDMA/VDL Mode 4.

• DCAA has initiated the North Atlantic ADS-B Network project (NAAN) for conducting furtherstudies of STDMA/VDL Mode 4 in the North Atlantic region, where harsh climatic conditionsmakes the deployment and maintenance of traditional surveillance equipment expensive. It is



expected that up to nine reference-stations will be distributed over Greenland, Iceland, TheFaeroe Islands, United Kingdom, Ireland and Norway.

• DCAA is participating in NEAN Update Programme (NUP), which will follow up on the initialsteps taken by the NEAN project. Results from the experiments and demonstrations conductedwithin NEAN and NEAP were encouraging. E.g. estimated average ADS-B delivery times lessthan 2 seconds and ADS-B reliabilities around 95% measured using STDMA test equipmentindicate the potential of the technology. However, the technical elements must be maturedfurther and an operational concept must be developed. NUP is seen as a vehicle for this.

• Future operational systems, being specified by DCAA, will consider the use of ADS-B as anoption.

• The CNS concept is under consideration by DCAA, and technologies like STDMA and ADS-Bare being discussed.

Deutsche Flugsicherung (DFS)

DFS was an active partner in the NEAN project. Additional effort was spent for the improvementand maintenance of the STDMA data link infrastructure to support the EUROCONTROL PETAL IItrials as well as for setting up and demonstrating the first FREER-3 live trials.

In summary, 55 man-months of DFS effort and 1,5 million ECU have been spent for theseactivities.

The engagement in all these projects was and is motivated by the following factors:

• DFS share with our partners and our customers the high concern to improve the ATM systemand are therefore prepared to actively explore new enablers like ADS-B, and demonstrateachievable benefits;

• The STDMA was identified as a new technology promising potential benefits in each of thethree areas Communication, Navigation and Surveillance taken into consideration that duringthe test phase only prototype equipment was used. With respect to the prototype level the resultsare promising and leading to a continuation of the development of this technology;

• In particular ADS-B was identified as a prime enabler for the realisation of future ATMconcepts which allow potentially improvements to safety, capacity and cost-effectiveness;

• In contrast to programmes like 8,33 kHz, Mode S, EGNOS and others, ADS-B is "pulled" bythe airspace users rather than "pushed" by the ATS providers. This should be acknowledged byall of the ATS provider organisations.

ADS-B as such may be enabled by two different technologies:

• STDMA/VDL Mode 4.• Mode S Extended Squitter.

Each of these technical solutions operate in a different frequency band and have differingadvantages and disadvantages. The mentioned projects, along with the financial support of theEuropean Commission, provided DFS the opportunity for early exploration of ADS-B benefitsprovided by STDMA within the framework of an international partnership with partners andcustomers. DFS will continue these efforts in the framework of the NEAN Update Programme(NUP). DFS will also watch the South-European FARAWAY with careful interest.



To complete the knowledge and experience of ADS-B applications and ADS-B enablingtechnologies, DFS will also perform experiments and trials involving the Mode S Extended Squitterduring the course of 1999. This will be a collaborative effort together with the US FAA.

The DFS intends to work out its ADS-B strategy in 1999, as it has already been done for SatelliteNavigation. But a European (or even better a global) “convoy” is necessary. This is not just achallenge but also a chance for the European Commission and EUROCONTROL to use theirmandate to achieve a world-wide standard “made in Europe”.

The activities so far have been supported and sponsored already by both organisations. From theDFS point of view they should continue.

To achieve a commonly agreed European proposal for an ICAO standard, DFS recommends a co-operative action with the participation of all affected parties. The ATM R&D Review Group inautumn 1998 suggested a so-called CARE programme. This could serve as an example for theorganisational framework.

Sponsored by the EU and under the programme leadership of EUROCONTROL the initiative onADS-B should lead to:

• Technology profiles and specifications for the two competing technologies• A first set of applications in context with operational concepts• A decision on the standard (Europe-wide supported proposal for ICAO standard)• Certification steps (from "dissimilar redundancy" to potentially “sole means”)• Cost benefit analysis

The mentioned tasks and milestones – under the assumption of co-ordinated Europe-wide-efforts –should be doable in the next 3 to 4 years.

A/G-Link

Media

DL-Services

2007 2008 2009 2010 2011 2012 year

VDL M2 primary link (non-time critical services only)

VDL M3

VDL M4

CPDLC(CIC-zeitkr.), ADAP(PPD, ADS), DFIS(D-RVR), others

Mode S Com, complementary linkSATCOM, complementary link

ACARS

ATM-Systems System adaptations



Appendix AThe Partners Contact List



Name:Address:

Per AhlScandinavian Airlines SystemFrösundaviks Allé 1, SolnaS-185 87 StockholmSWEDEN

Phone: +46 8797 2621Fax: +46 8797 1930E-Mail: [email protected] Role: SAS Coordinator

Name:Address:

Lars AhlmASELuftfartsverketS-601 79 NorrköpingSWEDEN

Phone: +46 1119 2675Fax: +46 1119 2670E-Mail:Project Role: Swedish Team member

Economy Reporting Responsible

Name:Address:

Kimmy BechASO 400LuftfartsverketS-601 79 NorköpingSWEDEN

Phone: +46 1119 2413Fax: +46 1119 2670E-Mail: [email protected] Role: Swedish Team member

Name:Address:

Matthias BeckersDeutsche Flugsicherung GmbHNiederlassung Köln/Bonn, FWKHeinrich-Steinmann Str.D-51147 KölnGERMANY

Phone: +49 2203 5707 146Fax: +49 2203 5707 188E-Mail:Project Role: German Team member (DFS Airport Köln)



Name:Address:

Mr BordachDeutsche Flugsicherung GmbHNiederlassung Köln/Bonn, FWKHeinrich-Steinmann Str.D-51147 KölnGERMANY


Name:Address:

Jonas CarlssonTfLuftfartsverketS-601 79 NorrköpingSWEDEN

Phone: +46 1119 2677+46 7054 05055

Fax: +46 1119 2670E-Mail: [email protected] Role: Swedish Team member

Name:Address:

Nynne S. DalåCivil Aviation Administration - DenmarkLuftfartshusetBox 744Ellebjergvej 50DK-2450 Copenhagen SVDENMARK

Phone: +45 3644 4848/543Fax: +45 3644 7101E-Mail: [email protected] Role: Danish Team Member

Name:Address:

Patric DelhaiseEurocontrolHorsterweg 11NL-6191 RX BeekNETHERLAND

Phone: +31 43 366 12 34Fax: +31 43 366 13 00E-Mail: [email protected] Role: PETAL II - NEAN Coordinator

mailto:[email protected]



Name:Address:

Peter EricssonASELuftfartsverketS-601 79 NorrköpingSWEDEN

Phone: +46 1119 2675+46 708 192 675

Fax: +46 1119 2670E-Mail: [email protected] Role: Swedish Team Leader

Name:Address:

Jan EricssonSASFrösundsviks Allé 1, SolnaS-195 87 StockholmSWEDEN

Phone: +46 8 797 2821Fax: +46 8 797 2930E-Mail: [email protected] Role: SAS Team member

Name:Address:

Niclas GustavssonTfLuftfartsverketS-601 79 NorrköpingSWEDEN

Phone: +46 1119 2273+46 708 693 259

Fax: +46 1119 2670E-Mail: [email protected] Role: Swedish Team member

Name:Address:

Joachim HartherzDeutsche Flugsicherung GmbHRegionalstelle Frankfurt, TB1FlughafenD-60549 Frankfurt am MainGERMANY

Phone: +49 6103 594 1301Fax: +49 6103 594 1380E-Mail:Project Role: German Team member (DFS Airport Frankfurt)



Name:Address:

Magnus HenrikssonATC SystemsLuftfartsverketMalmö/Sturup AirportBox 55S-230 32 Malmö-SturupSWEDEN

Phone: +46 40 613 1386+46 70 813 1386 (mobile)

Fax: +46 40 6131 378E-Mail: [email protected] Role: Swedish Team Member (Software

Development)

Name:Address:

Fotini IannidouCE DG VIIB-1049 BrusselsBELGIUM

Phone: +32 22 955 548Fax: +32 22 967 082E-Mail:Project Role: European Commission

Steering Committee member

Name:Address:

Lars Peter JensenCivil Aviation Administration - DenmarkLuftfartshusetBox 744Ellebjergvej 50DK-2450 Copenhagen SVDENMARK

Phone: +45 3644 4848/561Fax: +45 3644 7101E-Mail: [email protected] Role: Danish Team Member

Name:Address:

Ulf JohnforsScandinavian Airlines SystemFrösundaviks Allé 1, SolnaS-195 87 StockholmSWEDEN

Phone: +46 8797 4354Fax: +46 8797 2930E-Mail: [email protected] Role: Steering Committee (SAS)

mailto:[email protected]



Name:Address:

Larry JohnsonATC SystemsLuftfartsverketMalmö/Sturup AirportBox 55S-230 32 Malmö-SturupSWEDEN

Phone: +46 40 6131 381+46 70 5932 777

Fax: +46 40 6131 378+46 70 6102 677

E-Mail: [email protected] Role: Swedish Team Member

Name:Address:

Jørgen JørgensenCivil Aviation Administration - DenmarkLuftfartshusetBox 744Ellebjergvej 50DK-2450 Copenhagen SVDENMARK

Phone: +45 3644 4848/520Fax: +45 3644 7101E-Mail: [email protected] Role: Steering Committee (SLV)

Name:Address:

Heribert LaffertonDeutsche Flugsicherung GmbHDept. SETPaul-Ehrlich-Straße 37-39D-63225 LangenGERMANY

Phone: +49 6103 707 780Fax: +49 6103 707 742E-Mail: [email protected] Role: Steering Committee (DFS)

Name:Address:

Michael LariviereDeutsche Lufthansa (DLH)Dept. FRA OY/TLufthansa Base/AirportD-60546 Frankfurt/MainGERMANY

Phone: +49 69 696 93732Fax: +49 69 696 5466E-Mail: [email protected] Role: DLH Team member



Name:Address:

Jürgen LauterbachDeutsche Lufthansa (DLH)Dept. FRA OY/TLufthansa Base/AirportD-60546 Frankfurt/MainGERMANY

Phone: +49 69 696 93746Fax: +49 69 696 5466E-Mail: [email protected] Role: DLH Coordinator

Name:Address:

Karl-Ernst LiebscherDeutsche Flugsicherung GmbHRegionalstelle Bremen, FNBFlughafendamm 45D-28199 BremenGERMANY

Phone: +49 421 5372 296Fax: +49 421 5372 229E-Mail:Project Role: German Team member (DFS Airport Bremen)

Name:Address:

Jochen MickelDeutsche LufthansaDept. FRA OY/TLufthansa Base / AirportD – 60546Frankfurt am MainGERMANY

Phone: +49 177 229 8008 (Mobile)Fax: +49 69 696 5466E-Mail: [email protected] Role:

Name:Address:

Andreas NeesDeutsche Flugsicherung GmbHDept. SETPaul-Ehrlich-Straße 37-39D-63225 LangenGERMANY

Phone: +49 6103 707 782Fax: +49 6103 707 742E-Mail: [email protected] Role: German Project Team Leader



Name:Address:

Kim O`NeilAdvanced Aviation Technology LtdThe Old Post OfficeThe StreetComptonSurrey GU1 1BWENGLAND

Phone: +44 1483 811 311+44 802 785 145 (Mobile)

Fax:E-Mail: [email protected] Role:

Name:Address:

Reinhard PeikerDeutsche Flugsicherung GmbHRegionalstelle Berlin, FOB3Columbiadamm 2 - 6D-10965 BerlinGERMANY

Phone: +49 30 6951 2525Fax: +49 30 6951 2262E-Mail:Project Role: German Team member

(DFS Airport Berlin-Tempelhof)

Name:Address:

Stefan PenterCivil Aviation Administration - DenmarkLuftfartshusetBox 744Ellebjergvej 50DK-2450 Copenhagen SVDENMARK

Phone: +45 36 44 48 48 or +45 36 44 08 08 566Fax: +45 36 44 71 01 or +45 36 44 03 03E-Mail: [email protected] Role: Danish Team Member

Name:Address:

Peter RaffayCivil Aviation Administration - DenmarkLuftfartshusetEllebjergvej 50DK-2450 Copenhagen SVDENMARK

Phone: +45 36 44 48 48 or +45 36 44 08 08 557Fax: +45 36 44 71 01 or +45 36 44 03 03E-Mail: [email protected] Role: Danish Project Team Leader, Project Coordinator



Name:Address:

Bo RedebornATMLuftfartsverketS-601 79 NorrköpingSWEDEN

Phone: +46 1119 2388Fax: +46 1119 2640E-Mail: [email protected] Role: NEAN Project Manager

Steering Commitee Chairman

Name:Address:

Oliver ReitenbachDeutsche Flugsicherung GmbHDept. SETPaul-Ehrlich-Straße 37-39D-63225 LangenGERMANY

Phone: +49 6103 707 720Fax: +49 6103 707 742E-Mail: [email protected] Role: German Team member

Name:Address:

Christian RevermannDeutsche Flugsicherung GmbHNiederlassung Köln/Bonn, FWKHeinrich-Steinmann Str.D-51147 KölnGERMANY


Name:Address:

Michael SchwarzeDeutsche Flugsicherung GmbHRegionalstelle Bremen, FNBFlughafendamm 45D-28199 BremenGERMANY

Phone: +49 421 5372 220Fax: +49 421 5372 229E-Mail:Project Role: German Team member (DFS Airport Bremen)



Name:Address:

Björn SyrénScandinavian Airlines SystemFrösundaviks Allé 1, SolnaS-195 87 StockholmSWEDEN

Phone: +46 8797 2617Fax: +46 8797 2830E-Mail: [email protected] Role:

Name:Address:

Flemming TidselholdtCivil Aviation Administration - DenmarkLuftfartshusetBox 744Ellebjergvej 50DK-2450 Copenhagen SVDENMARK

Phone: +45 3644 4848/550Fax: +45 3644 7101E-Mail: [email protected] Role: Steering Committee member (SLV)

Name:Address:

Klaus WernerDLR, Deutsches Forschungszentrum für Luft- und RaumfahrtInstitut für FlugführungLilienthalplatz 738108 BraunschweigGERMANY

Phone: +49 531 295 2555Fax: +49 531 295 2180E-Mail: [email protected] Role: German Team member

Name:Address:

Dr. Burkard WiggerDeutsche LufthansaDept. FRA OY/TD-60546 Frankfurt am MainGERMANY

Phone: +49 69 696 2944Fax: +49 69 696 5466E-Mail: CompuServe 100315,2373Project Role: Steering Committee member



Name:Address:

Alex VinkEurocontrolRue de la Fusée 96B-1130 BrusselsBELGIUM

Phone: +32 2729 3347Fax: +32 2729 9087 or

+32 2729 3587E-Mail: [email protected] Role: PETAL II - NEAN Coordinator



Appendix BA list of all documents produced during the project.



Collaborative Documents

Work Package 1 - Progress ReportALL_WP1_1, All Teams, 1996-10-03


Work Package 4 – Progress ReportALL_WP4_4, K. O’Neil, Advanced Aviation Technology & International Associates1997-10-16


Final Project Summary and Conclusion ReportALL_WP5_6, All Teams, 1999-03-26



Danish Team Documents

Notes from the Steering Committee Kick-Off meeting in CopenhagenJanuary 17. And 18. 1996SLV_WP0_00, J. Jørgensen, CAA-DK/SLV, 1996-01-02

NEAN Document ListSLV_WP1_00, S.Penter, CAA-DK/SLV, 1996-10-10

NEAN Problem and Change ReportSLV_WP1_01, S.Penter, CAA-DK/SLV, 1996-09-12

Selection of NEAN software for the Danish sitesSLV_WP1_02, S.Penter CAA-DK/SLV, 1996-05-21

Selection of NEAN hardware for the Danish sites and network segmentSLV_WP1_03, S.Penter, CAA-DK/SLV, 1996-09-02

Installation of a NEAN LS, RS, NS or DS on a DELL OptiPlex PCSLV_WP1_04, S.Penter, CAA-DK/SLV, 1996-08-28

Benchmarks for the DELL OptiPlex PCSLV_WP1_05, S.Penter, CAA-DK/SLV, 1996-09-16

Test Specification for Equipment LAB-TestSLV_WP1_06, S.Penter, CAA-DK/SLV, 1996-09-12

Lab-test of old and new transponders with old and new DGPS stations inCopenhagenSLV_WP1_07, S.Penter, CAA-DK/SLV, 1996-09-30

Internal NEAN Project Archive Structure for DANTSLV_WP1_08, S.Penter, CAA-DK/SLV, 1996-07-11

Quality Standards DocumentSLV_WP1_09, P.Raffay, CAA-DK/SLV, 1996-03-11

A4 Binder Label Template for NEANSLV_WP1_10, S.Penter, CAA-DK/SLV, 1996-07-11

Binder Separator TemplateSLV_WP1_11, S.Penter, CAA-DK/SLV, 1996-08-14

Useful symbols for NEAN MS-Word drawings: ComputersSLV_WP1_12, S.Penter, CAA-DK/SLV, 1996-10-14

Useful symbols for NEAN MS-Word drawings: WindowsSLV_WP1_13, S.Penter, CAA-DK/SLV, 1996-10-14



NEAN Administrator’s Survival GuideSLV_NEAN_WP1_14, S.Penter CAA-DK/SLV, 1996-12-03

EKYT Site Survey ReportSLV_WP1_15, P.Raffay, CAA-DK/SLV, 1996-05-13

EKEB Site Survey ReportSLV_WP1, P.Raffay CAA-DK/SLV, 1996-05-13

EKCH Site Survey ReportSLV_WP1_17_1.0, P.Raffay CAA-DK/SLV, 1996-05-13

Software Documentation for ‘NEAN Config Files’SLV_WP1_18_1.0, S.Penter CAA-DK/SLV, 1996-10-21

Software Documentation for ‘Updates for Airsys’SLV_WP1_19_1.0, DOC

Equipment LAB-test v/1.0 ResultsSLV_WP1_20_1.0, S.Penter CAA-DK/SLV, 1996-11-22

Record of NEAN Problem reports and Change RequestsSLV_WP1_21_1.0, S.Penter CAA-DK/SLV, 1996-11-25

Release Note for ‘NEAN Config Files’ V/1.0SLV_WP1_22, S.Penter CAA-DK/SLV

Release Note for ‘NEAN Config Files’ V/1.1SLV_WP1_23, S.Penter CAA-DK/SLV

Release Note for ‘Updates v/1.0 for Airsys’SLV_WP1_24, S.Penter CAA-DK/SLV


Release Note for ‘Danish Map Files - Source Release v/1.1’SLV_WP1_26, S.Penter CAA-DK/SLV

NEAN Status, DecemberSLV_WP1_27, S.Penter/P.Raffay CAA-DK/SLV

Estimated Prices for a Generic NEAN Ground StationSLV_WP1_28, S.Penter CAA-DK/SLV




Release Note for ‘Danish Map Files - Source Release v/2.0’SLV_WP1_28, S.Penter CAA-DK/SLV

Airsys95 User GuideSLV_WP1_29, S.Penter CAA-DK/SLV, May 1997

Release Note for ‘Danish Updates for CATS v/1.0’SLV_NEAN_WP1_30, S.Penter CAA-DK/SLV

Log of Network Trial Period ActivitiesSLV_NEAN_WP2_01, S.Penter, CAA-DK/SLV, 1997-09-03

Minutes of 7th and 8th Steering Committee MeetingSLV_NEAN_WP2_02, Raffay, CAA-DK/SLV, 1997-09-17

Release Note - SLV WP2 Utility Programs v/1.0SLV_NEAN_WP2_03, S.Penter, CAA-DK/SLV, 1997-09-24

Intern NEAN/NEAP Status Rapport pr. 1. Oktober 1997SLV_NEAN/NEAP_WP2_04, Raffay, CAA-DK/SLV, 1997-10-08

Calling Notice to Projectgroup Meeting No 13 as SLV Copenhagen October21. and 22. 1997SLV_NEAN_WP2_05, Raffay, CAA-DK/SLV, 1997-10-12

Notes on .DXF and .DGN MapInfo file importsSLV_NEAN_WP2_06, S.Penter, CAA-DK/SLV, 1997-10-13

Release Note - DXF Export of NEAN maps v/1.0SLV_NEAN_WP2_07, S.Penter, CAA-DK/SLV, 1997-10-29

Release Note - Updates for Airsys v/3.0SLV_NEAN_WP2_08, S.Penter, CAA-DK/SLV, 1997-11-04

Release Note - DANT Map Sources v/3.0SLV_NEAN_WP2_09, S.Penter, CAA-DK/SLV, 1997-11-04

Calling Notice to Steering Committee Meeting No 9 at SLV, Copenhagen, Denmark,November 28. 1997SLV_NEAN_WP2_10, Raffay, CAA-DK/SLV, 1997-11-05

Partners Contact ListSLV_NEAN_WP2_11, Raffay, CAA-DK/SLV, 1997-11-05

Minutes of Project Group Meeting No 13, October 21. and 22. 1997in CopenhagenSLV_NEAN_WP2_12, Raffay, CAA-DK/SLV, 1997-11-12



Release Note - NEAN Config Files v/1.2SLV_NEAN_WP2_14, S.Penter, CAA-DK/SLV, 1997-11-26

Release Note - NEAN MIF/MID Map Sources v/1.0SLV_NEAN_WP2_15, S.Penter, CAA-DK/SLV, 1997-12-12

Calling Notice to Projectgroup Meeting No 14 at DFS Langen January 15. 1997SLV_NEAN_WP2_16, Raffay, CAA-DK/SLV, 1998-01-07

Minutes of the Steering Committee Meeting No 9 at SLV in Copenhagen, DenmarkNovember 28. 1997SLV_NEAN_WP2_17, Raffay, CAA-DK/SLV, 1998-01-09

NDS-RMCDE Interconnection - Problems and SolutionsSLV_NEAN_WP2_18, S.Penter, CAA-DK/SLV, 1998-01-19

NDS-RMCDE Ethernet/LAN Interconnection, a short howto.SLV_NEAN_WP2_19, S.Penter, CAA-DK/SLV, 1998-02-02

DANT Internal Status Report January 1998SLV_NEAN_WP2_20, Raffay, CAA-DK/SLV, 1998-01-31

Release Note - NEAN Config Files v/1.3SLV_NEAN_WP2_21, S.Penter, CAA-DK/SLV, 1998-02-24

Release Note - NEANSERV v/2.3SLV_NEAN_WP2_22, S.Penter, CAA-DK/SLV, 1998-02-24

Calling Notice to Steering Committee Meeting No 10 at LFV March 5. 1998SLV_NEAN_WP2_23, Raffay, CAA-DK/SLV, 1998-02-26

Calling Notice to Project Group Meeting No 15 at LFV March 6. 1998SLV_NEAN_WP2_24, Raffay, CAA-DK/SLV, 1998

DANT Internal Status Report February 1998SLV_NEAN_WP2_25, Raffay, CAA-DK/SLV, 1998-02-27

Calling Notice to Project Group Meeting No 16 at Sky City Hotel, Arlanda Airport,Stockholm, April 16. 1998SLV_NEAN_WP2_26, Raffay, CAA-DK/SLV, 1998

Calling Notice to Steering Committee Meeting No 11 at Lufthansa, FrankfurtApril 30. 1998SLV_NEAN_WP2_27, Raffay, CAA-DK/SLV, 1998-04-22

Release Note for R2 Transponder Software v/13.9 for the Danish DomainSLV_NEAN_WP2 _28, S.Penter, CAA-DK/SLV, 1998-04-28

Release Note for R2 Transponder Software v/13.9 for the Danish Domain - SourcesSLV_NEAN_WP2_29, S.Penter, CAA-DK/SLV, 1998-04-28



Cancelling of Steering Committee Meeting No 11 at Lufthansa, FrankfurtApril 30. 1998SLV_NEAN_WP2_30, Raffay, CAA-DK/SLV, 1998-04-29

Calling Notice to Projectgroup Meeting No 17 at SLV in Copenhagen,Denmark, June 25. 1998SLV_NEAN_WP2_31, Raffay, CAA-DK/SLV, 1998-06-09

Minutes of Project Group Meeting No 17, June 24. 1998 in CopenhagenSLV_NEAN_WP2_32, L.P.Jensen, CAA-DK/SLV, 1998-06-24

Calling Notice to Project Group Meeting No 18 at DFS, Langen August 26. 1998SLV_NEAN_WP2_33, Raffay, CAA-DK/SLV, 1998-06-24

Calling Notice to Project Group Meeting No 19 at DFS, Langen October 21. 1998SLV_NEAN_WP2_34, Raffay, CAA-DK/SLV, 1998-10-08

Calling Notice to Project Group Meeting No 20 at SLV, Copenhagen, November 17.1998SLV_NEAN_WP2_35, Raffay, CAA-DK/SLV, 1998-11-04

Calling Notice to Steering Committee Meeting No 13 at SAS, Frösundavik,Stockholm, December 1. 1998SLV_NEAN_WP2_36, Raffay, CAA-DK/SLV, 1998-11-24

Release Note - SLV WP2 Utility Programs v/2.0SLV_NEAN_WP2_37, S.Penter, CAA-DK/SLV, 1998-11-27

Minutes of Project Group Meeting No 20, November 17. 1998 in CopenhagenSLV_NEAN_WP2_38, Raffay, CAA-DK/SLV, 1999-01-12

Release Note for R2 Transponder Software v/14.0 for the Danish DomainSLV_NEAN_WP2 _39, S.Penter, CAA-DK/SLV, 1999-01-21

Release Note for R2 Transponder Software v/14.0 for the Danish Domain - SourceSLV_NEAN_WP2 _40, S.Penter, CAA-DK/SLV, 1999-01-21

Minutes of Meeting, May 14. 1996 Between SLV and DanRingSLV_WP3_01, S.Penter, CAA-DK/SLV, 1996-06-28

Minutes of Meeting, August 19. 1996 Between SLV and DanRingSLV_WP3_02, S.Penter, CAA-DK/SLV, 1996-08-19

Minutes of Meeting, June 6. 1996 Between SLV and NetDesignSLV_WP3_03, S.Penter, CAA-DK/SLV, 1996-06-06



Minutes of Meeting, June 3. 1996 Between SLV and DatametrixSLV_WP3_05, S.Penter, CAA-DK/SLV, 1996-06-03

Minutes of Meeting, May 15. 1996 Between SLV and Aage HempelSLV_WP3_06, S.Penter, CAA-DK/SLV, 1996-05-15

Minutes of Meeting, June 4. 1996 Between SLV and Berendsen DataSLV_WP3_07, S.Penter, CAA-DK/SLV, 1996-06-04

Configuration of the Danish NEAN SegmentSLV_WP3_08, S.Penter CAA-DK/SLV, 1996-08-26

Network EquipmentSLV_WP3_09, S.Penter CAA-DK/SLV, 1996-05-21

Software Requirement Specification for future NEAN servicesSLV_WP3_10, S.Penter CAA-DK/SLV, 1996-07-08

NEAN Component Hostnames, IP Sub-nets and Addresses for the Danish SegmentSLV_WP3_11, S.Penter CAA-DK/SLV, 1996-08-29

Network Configuration for the SLV LAB TestSLV_WP3_12, S.Penter, CAA-DK/SLV, 1996-10-25

Configuration Control Document - NEAN Installations DenmarkSLV_WP3_13, S.Penter, CAA-DK/SLV, 1997-05-05

Minutes of Meeting - NEAN International Interconnection Meeting in Copenhagen 5.February 1997SLV_WP3_14, S.Penter, CAA-DK/SLV, 1997-02-05

Standard for Release Documentation within the NEAN ProjectSLV_WP5_01, S.Penter, CAA-DK/SLV, 1997-05-21

NEAN Status Report: 31 May 1997 DANISH TEAMSLV_WP5_02, P.Raffay, S.Penter, CAA-DK/SLV, 1997-05-31

Problems in the NEAN Trial Network ArchitectureSLV_NEAN_WP5_03, S.Penter CAA-DK/SLV 1996-06-26

Standard for E-Mail notification of Network EventsSLV_NEAN_WP5_04, S.Penter, CAA-DK/SLV 1998-10-19



German Team Documents

Common Project Standards N E A NDFS_WP0_01, Matthias Poppe, February 2, 1996

Routing Strategies for a future NEAN NetworkDFS_WP3_01, Matthias Poppe, May 29, 1996

Progress Report German Team March 1996 - May 1996DFS_WP6_01, Matthias Poppe, May 24, 1996

Progress Report German Team June 1996 - August 1996DFS_WP6_03, Matthias Poppe, September 3, 1996

Minutes of Project Meeting 3, 30 and 31 May 1996 in Frankfurt/MainDFS_WP6_02, Matthias Poppe, June 5, 1996

Configuration Control Document NEAN Installations GermanyDFS_WP1_01, Matthias Poppe, September 11, 1996

Ground Station Setup Control DocumentDFS_WP1_02, (former ID: DFS_WP6_04-1.1), Matthias Poppe, September 20, 1996

Software Maintainability Test Report NEANSERVDFS_WP1_03, (no official ID before), Matthias Poppe, September 2, 1996

TCP/IP Naming Convention for NEAN Ground NetworkDLR_WP1_01, Klaus Werner, September 30, 1996

Minutes of Project Meeting 6, 1 and 2 October 1996 in BraunschweigDLR_WP6_01, Klaus Werner, November 1, 1996

Minutes of Project Meeting 7, 7th and 8th November 1996 in Frankfurt/MainDFS_WP6_06, Matthias Poppe, November 12, 1996

NEAN Network Component Configuration for the German SegmentDLR_WP3_01, Klaus Werner, January 17, 1997

Progress Report WP1 Planning and TrialsDFS_ WP6_05, Matthias Poppe, September 1996

NEAN map conventionDLR_WP1_2, Klaus Werner, March 1998

NEAN upgrade documentDFS_WP1_04, Oliver Reitenbach, January 4, 1999



NEAN Router Configuration Short Description for the German SegmentDLR_WP3_2, Klaus Werner, March 1996

Minutes of Project Meeting 10, 15th April 1997 in LangenDFS_WP6_07, Matthias Poppe, April 1997

Minutes of Project Meeting 11, 18 and 19th June 1997 in LangenDFS_WP6_08, Andreas Nees, June 1997

Minutes of Project Group Meeting No 14, January 15,1998 in LangenDFS_WP6_09, Andreas Nees, January 1998

Minutes of Project Group Meeting No 18, August 26, 1998 in LangenDFS_WP6_10, Andreas Nees, August 1998

Minutes of Project Group Meeting No 19, October 21, 1998 in LangenDFS_WP6_11, Andreas Nees, October 1998

Minutes of the Steering Committee Meeting No 11 at Köln / Bonn Airport, May 28th.1998DFS_WP6_12, Andreas Nees, June 1998

STDMA Concept Aspects using UHF and SHF Frequencies,DFS Deutsche Flugsicherung GmbH, November 19, 1997Dipl.-Ing. Ulrich Ann, TU BraunschweigProf. Dr. rer. nat. Hermann Rohling, TU Braunschweig



Swedish Team Documents

North European ADS-B Network Project DefinitionLFV_WP0_02

Swedish NEAN document standardLFV_NEAN_WP5_01

Ground Station Set-up by using STRANCS Configuration programLFV_NEAN_WP1_01

Minutes from Steering Committee meeting No 5 at SAS, Frösundavik. October 24,1996LFV_NEAN_WP5_07

Minutes of Project Meeting 8, 14 January 1997, at Stockholm-ArlandaLFV_NEAN_WP5_08

GNSS Transponder installation plan/scheduleLFV_NEAN_WP5_09

SWET Progress Report, 22 May 1997LFV_NEAN_WP5_10

Release Note - NEANSERV 2.0LFV_NEAN_WP5_12

Configuration - NEANSERV 2.0LFV_NEAN_WP5_13

NEANSERV Requirement SpecificationLFV_NEAN_WP5_14

Economic Report, Jan 1996 - Mars 1996LFV_NEAN_WP5_15

Textmessage Throughput - En Route/Ground-AirLFV_NEAN_WP5_16

Minutes of the 8th NEAN Steering Committee Meeting in St. Anna archipelago,Sweden 2 September 1997LFV_NEAN_WP5_17

Instructions on remote updating of NEANSERV softwareLFV_NEAN_WP5_18




Problem & Change Report NEANSERV-002LFV_NEAN_WP5_20

Minutes from NEAN project meeting 12 in Malmoe, August 19, 1997LFV_NEAN_WP5_21

Overview of ini-file commands in NEANSERVLFV_NEAN_WP5_22

Report from PETAL flight test 2, 28th January 1998LFV_NEAN_WP5_23

NEAN Update Programme – NUP Phase 1 and 2LFV_NEAN_WP5_25

Description of the NEAN exhibition at the CNS/ATM Systems ImplementationConference, Rio de Janeiro 11-15 May 1998LFV_NEAN_WP5_26

Minutes from the 10th Steering Committee Meeting, 5 March in NorrköpingLFV_NEAN_WP5_27

Minutes from the 15th Project Group Meeting, 6 March in NorrköpingLFV_NEAN_WP5_28

Create and Configure a Subdomain based on LS/SDS Ground Server SystemLFV_NEAN_WP5_29

Minutes from the 16th Project Group Meeting, 16 AprilLFV_NEAN_WP5_30

Ground Network Migration Plan for the NEAN Network in GermanyLFV_NEAN_WP5_31

Common Regulations for Use of STDMA Frequency 136.950 MhzLFV_NEAN_WP5_32

Release Note – NEANSERV 3.11LFV_NEAN_WP5_33

Minutes from the 15th Steering Committee Meeting, Sky City Arlanda.LFV_NEAN_WP5_34

Message Distributor, LS/SDS Test ToolLFV_NEAN_WP5_35

Message Agent, LS/SDS Test ToolLFV_NEAN_WP5_36



Message Routing Analysis, MRA, LS/SDS Test ToolLFV_NEAN_WP5_37

MMI Ping, LS/SDS Test ToolLFV_NEAN_WP5_38

Join/Leave Monitor, MRA, LS/SDS Test ToolLFV_NEAN_WP5_39

LS/SDS SQL LogLFV_NEAN_WP5_40

NEANSERV TerminologyLFV_NEAN_WP5_50

NEANSERV Design OverviewLFV_NEAN_WP5_51

NEANSERV Class DiagramsLFV_NEAN_WP5_52

LS/SDS Server System Message SpecificationLFV_NEAN_WP5_53

NEANSERV StatusrapportLFV_NEAN_WP5_54


NEANSERV Design Review ProtocolLFV_NEAN_WP5_56