The Digital NOTAM Subscription and Request Service allows the service consumer to get dynamic aeronautical information in accordance with the Digital NOTAM specification. The aeronautical information conforms to the event scenarios that are supported by Digital NOTAM.
The service consumer may subscribe to the service, specifying the event scenarios of interest. It is also possible to send a direct request to the service to get the aeronautical information.
The information returned is in the form of an AIXM 5.1.1 message ensuring compliance with aeronautical information exchange standards.
The digitalization of CNOTAM is in a transition phase. Expected completion date 2026-06-19.
Categorisation
SERVICE_DESCRIPTION
OPERATIONAL
- INFORMATION_MANAGEMENT
- AERONAUTICAL_INFORMATION_SERVICE_PROVIDER
- AIR_TRAFFIC_SERVICE_PROVIDER
- AIRPORT_OPERATOR
- CIVIL_AIR_NAVIGATION_SERVICE_PROVIDER
- CIVIL_AIRSPACE_USER
- COMMUNICATION_NAVIGATION_AND_SURVEILLANCE_SERVICE_PROVIDER
- MILITARY_AIR_NAVIGATION_SERVICE_PROVIDER
- MILITARY_AIRSPACE_USER
- MILITARY_DEFENCE_CENTRE
- PROVIDER_OF_DATA_SERVICES
- AERONAUTICAL_INFORMATION_EXCHANGE
- SYNCHRONOUS_REQUEST_REPLY
- BROKERED_PUBLISH_SUBSCRIBE_WITH_PUSH_MECHANISM
Estonian FIR
Provider
Estonian Air Navigation Services
Estonian Air Navigation Services (EANS, Lennuliiklusteeninduse Aktsiaselts) is a next generation air navigation services provider, headquartered in Tallinn, Estonia. We are state-owned public limited company under the jurisdiction Ministry of Economic Affairs and Communication of Republic of Estonia.
- AERONAUTICAL_INFORMATION_SERVICE_PROVIDER
- AIR_TRAFFIC_SERVICE_PROVIDER
- CIVIL_AIR_NAVIGATION_SERVICE_PROVIDER
EANS
- AIM Service Desk
- Registration form
-
EMAIL
General Information
A Digital NOTAM is intended for automatic processing and interpretation. Using dedicated software, it can be formatted into textual and graphical formats for presentation to human operators.
Air Traffic Services
Digital NOTAMs are instantly accsessible to ATS staff, so they can have the latest changes for Air Traffic Control. In Tallinn FIR ATS is provided by ANSP (EANS) and is responsible for providing TWR, APP and ACC traffic control in Estonian Airspace and consume digitalNOTAMs for operational situational awareness purposes.
Civil and Military Airspace Users
Consumer of digitalNOTAM data in the context of pre-flight briefing.
Civil and Military Air Navigation Service Providers
Use digitalNOTAM data to support the provision of air traffic and flow management, CNS services, aeronautical information and SAR services
Military Defence Centre
DigitalNOTAMs enhance operational efficiency and enable defence centers to visualize Prohibited, Restricted and Danger areas for military air- and ground operations. Military defence centre also acts as data originator and provides AISP with airspace limitations information.
Airport Operator
DigitalNOTAMs enhance the ability for airport operators to directly provide data concerning airport events. They provide AISP with aerodrome dynamic data and consume digitalNOTAM data to safely guide flights on airport grounds.
Information Exchange Requirements
A3SG-IER-05 Digital NOTAM Data Exchange as follows:1)Allow civil and military Airspace users, ATS, civil and military ANSP-s to subscribe to digitalNOTAM service. This is achieved by using AMQP standardized messaging protocol which is meant for asynchronous message exchange between systems. Users can specify the digitalNOTAM events they want and receive latest dynamic data on it. 2) Allow airport operators and AISP to exchange dynamic aerodrome data to achieve high efficiency and safe ground operations. 3) Allow military defence center and Military and Civil ANSPs to exchange airspace limitation and reservation data for flexible airspace usage. 4) Allow all users to request digital Pre-Flight Information Bulletins. This is achieved through the use of web-based API.
Aeronautical Features
Service offers high-quality, trusted and regulated digitalNOTAM request and event subscription capability in AIXM 5.1 format. Service offers following capabilities: 1)Direct Requests, users can request specific dynamic aeronautical information as a digitalPIB; 2) Subscription - users can subscribe and specify their event scenarios of interest.
Request digitalPIB
User retrieves data with all active (digitalNOTAM) events in selected time period.
Information about selected effective digital events is received and stored in client database.
Receive AMQP flow
Subscribe to specific scenario data feed. Also possible to check all or multiple.
Message is received and stored in client database.
-
Capacity
The service shall achieve a quality of processing 25 200 requests per hour.
-
Response time
The service shall achieve a quality 0.955 second delay for 95% of messages.
-
Availability
High Availability – 95%: Service disruption is minimal, support for cluster or multiple instances. Autoscaling: Ability to scale according to load. If one instance goes down, traffic is automatically redirected to another.
-
Recoverability
Recovery is performed automatically or in a managed manner according to policy. Loss of configuration and authentication data is not allowed. Configuration and queue metadata are backed up regularly. API Gateway configuration is backed up automatically. In case of system failure, the service must be restored the next business day. In case of force major this may not be guaranteed.
-
Confidentiality
Data confidentiality is ensured by the implemented security mechanisms: mTLS ensures mutual authentication between client and server (client and server certificates) and all connections are secured with TLS 1.2/1.3 encryption.
-
Integrity
Data integrity is maintained, no messages or critical queries are lost.
-
Authentication and Authorisation
Only authenticated users are authorised to use the service. The service shall ensure consumer authentication in accordance with the EUROCONTROL Specification for SWIM Technical Infrastructure (TI) Yellow Profile through the use of a X.509 certificate over mTLS and the use of a username/password (SASL). In order to use the service and have access to appropriate service functions and operations, the client must have user roles granted in service provider authentication system.
-
Access
In order to be able to access and use the EANS Aeronautical Information Feature Request service, users need to become certified clients. The authentication to the service is performed basic authentication:1) Register as a service user via web-form (registration form will soon be accessible from our aim webpage), you will be provided with username and password. 2)Authenticate with x.509 via mTLS. 3)Username and password will later be used for authentication and authorization for using the service. 4)By sending us a request for signing up as a client, you agree with our terms and conditions.
-
Policy
When signing up as a service user, we ask for your personal information: full name, organization name, organizational e-mail address, organizational mobile phone number. When you fill the contact form, you do so voluntarily. We only use the information provided by you for our own business purposes, such as providing access to the service.
-
Fair Use
soon be published
-
AIM Service DeskTo report incidents about services in operation.
SELF_VALIDATION
Before allowed access to live API, the client must test that their API endpoint is compliant with service configurations. The verification process is performed in service provider test environment. Client must run validation checks to ensure proper functionality, security and data format compliance. Once the clients endpoint is confirmed as compliant, the live service full access is activated enabling seamless system integration.
For information about the achieved results, please approach the designated point of contact.
-
AIP
Aeronautical Information Publication
-
AIM
Aeronautical Information Management
-
AIRM
Aeronautical Information Reference Model
-
AIRM
Aeronautical Information Exchange Model
-
API
Application Programming Interface
-
ATM
Air Traffic Management
-
ATS
Air Traffic Services
-
EANS
Estonian Air Navigation Services
-
EU
European Union
-
FIR
Flight Information Region
-
GAT
General Air Traffic
-
HTTP
Hypertext Transfer Protocol
-
ICAO
International Civil Aviation Organization
-
IER
Information Exchange Requirement
-
IPv
Internet Protocol version
-
mTLS
Mutual Transport Layer Security
-
NOTAM
NOtice To AirMen
-
OAT
Operational Air Traffic
-
OGC
Open Geospatial Consortium
-
PIB
Preflight Information Bulletin
-
SASL
Simple Authentication Security Layer
-
SESAR
Single European Sky ATM Research
-
SWIM
System Wide Information Management
-
TI
Technical Infrastructure
-
TLS
Transport Layer Security
-
WFS
Web Feature Service
-
WFS-TE
Web Feature Service - Temporality Extension
-
WMS
Web Map Service
-
WS
Web Service
-
WSDL
Web Services Description Language
-
YP
Yellow Profile
-
Event-based filtering for subscription service
When registering as a client for the subscription service, a registration form allows selecting following events to subscribe to: a) SAA.ACT, b) SAA.NEW, c) AD.CLS, d)AD.LIM, e)RWY.CLS, f)RWY.LIM, g)SFC.CON, h)OBS.NEW. For every scenario, there is also a possibility to subscribe to the full context event scenario. This means, that the filter reacts on BASELINEs of dnotam:Event time slices. The AIXM 5.1 data and digitalNOTAM are returned together with the referencing time slice, which contains the actual feature change (TEMPDELTA or PERMDELTA) and the underlying BASELINE of the feature change. This will allow clients to receive the full scope of the DNOTAM.
-
OGC Filter Encoding 2.0 Encoding Standard for DigitalPIB request service
Synchronous request/reply service for requesting digitalPIB uses OGC Filter Encoding 2.0 Encoding Standard Spatial Filters: Within, Dwithin, BBOX.
-
OGC Web Feature Service (WFS) Temporality Extension for DigitalPIB request service
All Temporal operations use cases described in OGC Web Feature Service (WFS) Temporality Extension (Doc nr OGC 12-027r3) are supported.
-
The service will receive information from the data originators that have signed service level agreement with EANS. This includes: AIRPORT_OPERATOR, CIVIL_AIR_NAVIGATION_SERVICE_PROVIDER, MILITARY_AIR_NAVIGATION_SERVICE_PROVIDER, COMMUNICATION_NAVIGATION_AND_SURVEILLANCE_SERVICE_PROVIDER, MILITARY_DEFENCE_CENTER, CIVIL_AVIATION_ADMINISTRATION and Government Agencies. EANS aims at achieving the level of minimal to no modifications made when receiving information from data originators.
-
https://aixm.aero/schema/5.1.1/AIXM_Features.xsd
-
https://aixm.aero/schema/5.1.1/message/AIXM_BasicMessage.xsd
-
Normal Behaviour for a client requesting digitalPIB
Users can request baseline data through OGC Web Feature Service 2.0. There is no automatic dataset publication, all data is available in the database and users can request digital NOTAM data in the form of a digital PIB.
Client sends a standard SOAP (envelope) request message via HTTP to the API Gateway and authenticates using mTLS and API Gateway validates the clients certification. API GW routes the request to the WFS server that is connected with AIM Database. An AIXM 5.1 data response is generated and the response message is embedded into a SOAP envelope just like the request.
The service behaviour shall be in accordance with the Synchronous Request-Reply pattern detailed in the Message Exchange Patterns: Identification Guidelines. The typical behaviour is as follows Synchronous Request/Reply- The request message is sent from the service consumer to the service - The service consumer remains blocked while awaiting the reply- The service remains blocked while processing the reply - The AIXM Basic Message, the reply message, is sent from the service to the service consumer.
-
Normal behaviour for digitalNOTAM AMQP push service using AMQP 1.0 or 0.9.1
The client registers to the service by filling a registration form. On the registration form, the client chooses the event scenarios (e.g. subscription channels) of interest. In the AMQP broker the client-subscription queue connection is established, to receive messages from an AMQP message queue. Clients can connect through an API Gateway and authenticate using mTLS and API Gateway validates the clients certification. After authentication, service consumers can access the AMQP delivery channel and receive data by connecting with appropriate credentials, that are made available after registration.
Only preconfigured event scenario based channels are available, no explicit subscribe/unsubscribe API is provided. Whenever new data is available (e.g. a new digitalNOTAM), messages are generated and pushed to AMQP message queues. Clients can only access their selected scenario queues.
The service behaviour is in accordance with the Asynchronous Request-Reply pattern detailed in the Message Exchange Patterns: Identification Guidelines. The typical behaviour is as follows: BROKERED_PUBLISH_SUBSCRIBE_WITH_PUSH_MECHANISM - A Publish/Subscribe pattern with push mechanism introducing a layer of decoupling between the publisher and subscribers by means of a broker.
-
Error Handling
For digitalPIB request service: incase of HTTP request failure an XML FaultMessage shall be generated indicating that an error has occurred.
-
<p>When you sign up to use the service, your IP-address will be logged for analytics and behavioural purposes.</p>
-
Digital NOTAM Subscription and Request Service AMQP push service
The interface allows users access to digitalNOTAM event feed to receive any updates. Service uses OASIS Standard AMQP Version 1.0. and 0.9.1. After establishing a TLS connection the client sends a protocol header indicating whether it wants to use AMQP 1.0 or AMQP 0.9.1.
Endpoint is AMQP Queue in AMQP Message Broker. Each subscription is linked to one queue. The necessary details regarding AMQP credentials and queue is contained in the subscription confirmation. The consumer needs to establish a consumer-client confirmation to consume the data from that queue. Queue enables guaranteed messaging, that means message is kept in the queue until message consumer sends acknowledgment. Only then message is removed from the queue.
Http endpoint url will be provided after registering to become a client.
PROVIDER_SIDEFIRE_AND_FORGET-
Publishgit
This operation allows service provider to publish Digital NOTAM messages to AMQP broker queues.
Messages-
AMQP MessageOUT
-
-
endpointNot provided yethttps://
-
SWIM_TI_YP_2_0_AMQP_MESSAGING
The service is bound to the AMQP 1.0 and 0.9.1 messaging protocol. The service Interface binding is compliant with EUROCONTROL Specification for SWIM Technical Infrastructure (TI) Yellow Profile.
-
IPv4_Secure Unicast
The service shall use the network bindings of the SWIM TIYP IPv4 Secure Unicast.
-
AMQP Message
The message is an output of the service, containing digitalNOTAM data.
-
-
DigitalNOTAM Subscription and Request Service DigitalPIB Request
The interface is used to allow users to request digital PIB-s aka AIXM basic message based on spatial and temporal filters linked to the event feature. The service uses the OGC Web Feature Service 2.0 Interface Standard.
PROVIDER_SIDESYNCHRONOUS_REQUEST_RESPONSE-
GetCapabilitiesgit
Returns XML metadata with information describing a WFS service provided by a server.
Messages-
GetCapabilitiesRequestIN
-
CapabilitiesOUT
-
-
GetFeaturegit
The GetFeature operation allows the retrieval of features and time slices. The GetFeature request will result in a GetFeatureResponse answer containing a queryResult in the form of an XML file for every query defined in the request. The default feature version of the query responses is AIXM 5.1.
Messages-
GetFeatureRequestIN
-
GetFeatureResponseOUT
-
-
AIM API Endpointhttps://aimapi.eans.ee/cadas-aimdb/wfs
-
SWIM_TI_YP_1_1_WS_SOAP_WITH_BASIC_MESSAGE_SECURITY
The service Interface binding is compliant with EUROCONTROL Specification for SWIM Technical Infrastructure (TI) Yellow Profile. The OGC Web Feature Service 2.0 Interface Standard is used and the mandatory standardised operations for a Basic WFS are implemented.
-
IPV4_Secure Unicast
The service uses the network bindings of the SWIM TIYP IPv4.
-
Error status code
The WFS interface uses A Common Fault Message Schema. Any errors and fault messages that can occur are categorized into different fault-message-groups. To communicate such a message an object called FaultMessage is used on the SOAP-level and made up of the properties type, the errorMessageCode, maybe one or more errorMessageParameters and defaultErrorMessage.
-
-
Interface WSDL
Machine processable description of the service interface.
For specific WSDL description, please contact the POC.
MACHINE_READABLE_SERVICE_DESCRIPTIONN/AReference-
https://schemas.xmlsoap.org/wsdl/
-
-
Interface Control Document
The CADAS-AIMDB Interface Control Document (ICD) contains a description of all interfaces provided by CADAS-AIMDB for the exchange of information with external systems.
SERVICE_BEHAVIOUR_DESCRIPTION2 -
Service Categories
A set of service categorisation schemes for use in artefacts that describe services.
SERVICE_BEHAVIOUR_DESCRIPTIONN/AReference-
https://reference.swim.aero/information-services/service-categories.html
-
-
Appendix A: References
Digital NOTAM Subscription and Request Service - Service Definition - Aeronautical SWIM Services - SWIM Confluence (atlassian.net).
SERVICE_SPECIFICATION01.00.00Reference-
https://swim-eurocontrol.atlassian.net/wiki/x/qgGUAw
-
-
Appendix B: Information Definition for Digital NOTAM Subscription and Request Service
Digital NOTAM Subscription and Request Service - Service Definition - Aeronautical SWIM Services - SWIM Confluence (atlassian.net).
SERVICE_SPECIFICATION01.00.00Reference-
https://swim-eurocontrol.atlassian.net/wiki/x/qgGUAw
-
OGC Web Feature Service
SERVICE_STANDARD
The service conforms with the standard as per Technical Constraints section of the current service description.
2.0/1.1.0/1.0.0
This standard defines direct fine-grained access to geographic information at the feature and feature property level by specifying discovery, query, locking and transaction operations and operations to manage stored, parameterized query expressions. This standard covers 11 operations e.g. GetCapabilities (discovery operation). This Standard continues to be a reliable means to provide geospatial data to the web. However, the functional capabilities are now available in a more modern web API, OGC API – Features, and implementers are encouraged to use the newer Standard.
-
https://www.ogc.org/standards/wfs/
OGC Filter Encoding
SERVICE_STANDARD
The service conforms with the standard as per Technical Constraints section of the current service description.
2.0
This standard is a jointly developed OGC and ISO TC/211 International Standard that describes an XML and Key Value Pairs (KVP ) encoding of a system neutral syntax for expressing projections, selection and sorting clauses collectively called a query expression.
-
https://www.ogc.org/standards/filter/
Eurocontrol Specification for SWIM Service Description
EUROCONTROL_SPECIFICATION_FOR_SWIM_SERVICE_DESCRIPTION
The service conforms with the standard.
2.0
This specification contains requirements for service descriptions, describing information services, in the context of System Wide Information Management (SWIM).
-
https://www.eurocontrol.int/publication/eurocontrol-specification-swim-service-description-sd
Eurocontrol Specification for SWIM Technical Infrastucture (TI)Yellow Profile
EUROCONTROL_SPECIFICATION_FOR_SWIM_TECHNICAL_INFRASTRUCTURE
The service conforms with the standard as per Technical Constraints section of the current service description.
2.0
This specification contains requirements for the implementation of technical infrastructure supporting information exchanges in System Wide Information Management (SWIM). It enables technical interoperability by specifying standardised technical interfaces (e.g. protocols) and the capabilities required to enable a reliable, secure and efficient exchange of information.
-
https://www.eurocontrol.int/publication/eurocontrol-spec-170-eurocontrol-specification-swim-technical-infrastructure-ti-yellow
OASIS Advanced Message Queuing Protocol (AMQP)
SERVICE_STANDARD
The service conforms with the standard as per Technical Constraints section of the current service description.
1.0/0.9.1
The Advanced Message Queuing Protocol (AMQP) is an open internet protocol for business messaging. It defines a binary wire-level protocol that allows for the reliable exchange of business messages between two parties. AMQP has a layered architecture and the specification is organized as a set of parts that reflects that architecture.
Digital NOTAM Specification
SERVICE_STANDARD
The service conforms with the standard as per Technical Constraints section of the current service description.
2.0
The Digital NOTAM Specification defines the rules for harmonised encoding of NOTAM information as digital AIXM data sets (version 5.1 or later).
-
https://ext.eurocontrol.int/aixm_confluence/display/DNOTAM/Digital+NOTAM+Specification