- Title
- FMN Spiral 5 Standards Profile
Subprofiles
Status
- FMN Spiral 5 Standards Profile
- Business Support Standards Profiles
- Geospatial Standards Profiles
- Information Management Standards Profiles
- Communication and Collaboration Standards Profiles
- Informal Messaging Standards Profiles
- Calendaring and Scheduling Standards Profiles
- Text-based Collaboration Standards Profiles
- Video-based Collaboration Standards Profiles
- Audio-based Collaboration Standards Profiles
- Media-based Collaboration Standards Profiles
- COI-Enabling Standards Profiles
- COI-Specific Standards Profiles
- Command and Control Standards Profiles
- Intelligence and ISR Standards Profiles
- CIS Support Standards Profiles
- SMC Orchestration Profile
- SMC Process Implementation Profile
- SMC Process Implementation Profile for Enabling Processes
- SMC Process Implementation Profile for Change Management
- SMC Process Implementation Profile for Service Catalogue Management
- SMC Process Implementation Profile for Incident Management
- SMC Process Implementation Profile for Request Fulfilment
- SMC Process Implementation Profile for Event Management
- SMC Process Implementation Profile for Problem Management
- SMC Process Implementation Profile for Service Asset and Configuration Management
- SMC Process Implementation Profile for Service Level Management
- SMC Process Implementation Profile for Access Management
- SMC Process Implementation Profile for Transfer of Management Authority
- SMC Process Implementation Profile for Joining Process
- SMC Process Implementation Profile for Exiting Process
- SMC Process Implementation Profile for Service Request Catalogue Management
- Cyber Information Exchange Profile
- SMC Process Choreography Profile
- SMC Orchestration Profile
- Federated Fires profiles
- Communications Access Standards Profiles
- Inter-Autonomous Systems Multicast Signaling Profile
- Inter-Autonomous Systems Routing Profile
- Traffic Flow Confidentiality Protection Profile
- Generic Routing Encapsulation profile
- Inter-Autonomous Systems Multicast Source Discovery Profile
- Inter-Domain Multicast Planning Profile
- NMCD Information Exchange Service Profile
- Communications Transport Standards Profiles
- IP Quality of Service Profile
- Inter-Autonomous Systems IP Communications Security Profile
- Inter-Autonomous Systems IP Transport Profile
- Interface Auto-Configuration Profile
- Tactical Interoperability Network Interconnection Profile
- IPv4 Transport Services Profile
- IPv6 Transport Services Profile
- IP Access to Tactical Radio
- NINE ISPEC
- Infrastructure Standards Profiles
- Platform Standards Profiles
- Database Platform Standards Profiles
- Web Platform Standards Profiles
- Metadata Labelling Profile
- Web Authentication Profile
- Structured Data Profile
- Web Content Profile
- Web Feeds Profile
- Web Platform Profile
- Web Service Messaging Profile
- Web Services Profile
- OAuth 2.0 Authorization Server Bootstrap Profile
- SAML 2.0 Bootstrap Profile
- Security Token Services Profile
- OAuth 2.0 Assertion Grant Profile
- SAML 2.0 Assertion Profile
- JSON Web Token Assertion Profile
- OAuth 2.0 Access Token Profile
- Secure SOAP-based Request Response Profile
- Secure REST-based Request Response Profile
- SOAP-Based Request Response Profile
- REST-Based Request Response Profile
- Direct Notification Publish Subscribe Profile
- Brokered Notification Publish Subscribe Profile
- OAuth 2.0 DPoP Profile
- OAuth 2.0 HTTP Message Signatures Profile
- Communications Transmission Standards Profiles
- Business Support Standards Profiles
FMN Spiral 5 Standards Profile
Business Support Standards Profiles
Geospatial Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Geospatial Data Exchange Profile The Geospatial Data Exchange Profile provides standards and guidance in support of Geospatial Web Services to produce and exchange geospatial data between different participants using standardized exchange formats. These datasets will be loaded into specialized geospatial information systems (GIS) and published via standardized Geospatial Web Services. |
||
Communication and Collaboration Applications, File System Storage Services, Geospatial Services, Technical Services, Text-based Communication Services |
Candidate Exchange of Digital Vector Data
Candidate This ESRI Technical Paper describes XML schemas for the Geodatabase in order to enable exchange of digital geospatial data. In contrary to the ESRI Arc Geodatabase (File-based), this document is freely available to the public and does not require vendor-specific licenses. Candidate Exchange of Digital Raster Data
Candidate Exchange of Digital Elevation Data |
Vector data has to be accompanied with a clear description (UML model or text file) of the data schema and fields which are to be based on AGeoP-11. |
Geospatial Web Feeds Profile The Geospatial Web Feeds Profile provides standards and guidance for in support of Geospatial Web Services to deliver geospatial content to web sites and to user agents, including the encoding of location as part of web feeds. |
||
Web Hosting Services |
Candidate GeoRSS Simple encoding for "georss:point", "georss:line", "georss:polygon", "georss:box". Candidate GML subset for point "gml:Point", line "gml:LineString", polygon "gml:Polygon", and box "gml:Envelope". In Atom feeds, location shall be specified using Atom 1.0's official extension mechanism in combination with the GeoRSS GML Profile 1.0 whereby a "georss:where" element is added as a child of the <entry> element. |
Geography Markup Language (GML) allows to specify a coordinate reference system (CRS) other than WGS84 decimal degrees (lat/long). If there is a need to express geography in a CRS other than WGS84, it is recommended to specify the geographic object multiple times, one in WGS84 and the others in your other desired CRSs. |
Web Feature Service Profile The Web Feature Service Profile provides standards and guidance for in support of Geospatial Web Services to provide a standardized interface for geodata provision in a defined format over a network connection. |
||
Geospatial Web Feature Services |
Candidate |
Implementation guidance can be found in DGIWG 122, Defence Profile of OGC’s Web Feature Service 2.0 v.2.0.1, 28 November 2017. |
Web Map Service Profile The Web Map Service Profile provides standards and guidance in support of Geospatial Web Services to provide a standardized interface for geodata provision in a defined format over a network connection. |
||
Geospatial Web Map Services |
Candidate |
Service Providers can select which profile(s) to implement, and should put emphasis on DGIWG Profiles. Service Consumers that want to consume WMS/WMTS services provided by the NATO Command Structure must implement the NCIA SIP. |
Web Map Tile Service Profile The Web Map Tile Service Profile provides standards and guidance in support of Geospatial Web Services to provide a standardized protocol for serving pre-rendered georeferenced map tiles over the Internet. |
||
Geospatial Web Map Tile Services |
Candidate |
Service Providers can select which profile(s) to implement, and should put emphasis on DGIWG Profiles. Service Consumers that want to consume WMS/WMTS services provided by the NATO Command Structure must implement the NCIA SIP. |
GeoPackage Profile A GeoPackage is an open, standards-based, platform-independent, portable, self-describing, compact format for transferring geospatial information. The GeoPackage standard describes a set of conventions for storing within a SQLite database vector features, tile matrix sets of imagery and raster maps at various scales and extensions. Please note that the spatial extent, vector and raster content, use of extensions, CRS, and metadata of a GeoPackage will generally be based on the intended use and the existing capabilities of system(s) that will use the GeoPackage. |
||
C3 Taxonomy |
Candidate |
All geopackages are based on version 3 of the SQLite file format, and will have a file name of “.gpkg”. The only tables that are mandated are the gpkg_spatial_ref_sys table and the gpkg_contents table. The gpkg_spatial_ref_sys table contains the spatial (coordinate) reference system (SRS) definitions needed by the gpk_contents and the gpkg_geometry_columns table to relate the vector and tile data in user tables to locations on the earth. The gpkg_contents table provides a list of all the geospatial contents in a GeoPackage and provides identifying and descriptive information that an application can display to a user as a menu of geospatial data that is available for access and/or update.Further implementation guidance can be found in DGIWG 126, the (DRAFT) DGIWG GeoPackage Profile, DRAFT Rev 2.1 (STD-DP-19-005), June 10, 2021, expected ratification April 2022. Providers should put emphasis on DGIWG Profile requirements and recommendations.The DGIWG Profile of Geopackage provides the following advantages to the users of GeoPackage data
|
Information Management Standards Profiles
Formal Messaging Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Formatted Messages for MedEvac Profile The Formatted Messages Profile for Medical Evacuation (MedEvac) provides standard for formatted messages that are typically used for C2 of Medical Evacuation missions. These formatted messages may be used as payload/attachment in combination with various transport mechanisms such as informal messaging (e-mail), text collaboration (chat) or in standardized voice procedures. |
||
C3 Taxonomy |
Candidate C2 of MedEvac Missions requires the following messages: Situational Awareness:Incident Report (INCREP – A078)Incident Spot Report (INCSPOTREP – J006)Troops in Contact SALTA Format (SALTATIC A073)Requests:Medical Evacuation Request (MEDEVAC – A012)Mechanism Injury Symptoms Treatment (MIST‐AT, supplement to A012)Diving Accident (DIVEACC – N019)Evacuation Request (EVACREQ – N096) |
|
Formatted Messages for Maritime Profile The Formatted Messages Profile for Maritime provides the standard for formatted messages that are typically used in Maritime operations in support of Maritime Situational Awareness (MSA), tasking and reporting. These formatted messages may be used as payload/attachment in combination with various transport mechanisms such as informal messaging (e-mail), text collaboration (chat) or simply with ACP-127 headers. |
||
C3 Taxonomy |
Candidate NATO Message Text Formats—Purpose and Method of Use NATO message text consists of standardized messages that are both man- and machine-readable. The formats of these messages are laid out in the NATO Message Catalogue (APP-11) and are generally referred to as MTF messages. Purpose. MTF messages may be used:To convey operational instructions or intentions.To pass operational information to tactical commanders at sea.To pass operational information between component commanders and subordinate units.To report operational information between commanders and from subordinate to higher formations.To notify organizations of impending and actual operations of units engaged in maritime warfare. Method of Use. MTF messages are to be used as shown in Table 2-15. Detailed instructions of the structures and method of completion are contained in APP-11. Some of these messages have not yet been incorporated into FORMETS and their structures are found in Chapter 6 of APP-11. Relevant Allied publications should be consulted for direction on content to be included.Ships and aircraft joining a force should be in receipt of all relevant messages pertaining to the operation in sufficient time before joining a force, to allow the commander and operational staff to make sufficient plans and provisions that they can join the force without further orders. |
Affiliates should take implementation guidance of Maritime related MTFs from Table B-15, Chapter 2 of MTP-01(H)(1). |
Formatted Messages for Air Profile The Formatted Messages Profile for Air provides the standard for formatted messages that are typically used in Air operations in support of the air processesAir Operational Planning and ExecutionandAir Tactical Picture Management Process. These formatted messages may be used as payload/attachment in combination with various transport mechanisms such as informal messaging (e-mail), web hosting, text collaboration (chat) or simply the use of the ACP-127 protocol. |
||
C3 Taxonomy |
Candidate NATO Message Text Formats—Purpose and Method of Use NATO message text consists of standardized messages that are both man- and machine-readable. The formats of these messages are laid out in the NATO Message Catalogue (APP-11) and are generally referred to as MTF messages. In some instances older versions of these MTFs are still used by Affiliates as is the case for the ATO and ACO during the Spiral 5 Preferred phase. Purpose. MTF messages may be used:To convey operational instructions or intentions.To pass operational information to tactical commanders at sea.To pass operational information between component commanders and subordinate units.To report operational information between commanders and from subordinate to higher formations.To notify organizations of impending and actual operations of units engaged in maritime warfare. Method of Use. MTF messages are to be used as shown in Table 2-15. Detailed instructions of the structures and method of completion are contained in APP-11. Some of these messages have not yet been incorporated into FORMETS and their structures are found in Chapter 6 of APP-11. Relevant Allied publications should be consulted for direction on content to be included.Ships and aircraft joining a force should be in receipt of all relevant messages pertaining to the operation in sufficient time before joining a force, to allow the commander and operational staff to make sufficient plans and provisions that they can join the force without further orders. |
To conduct Air coalition operations, Joint and Air commanders utilize formal messages taken from the NATO Message Catalogue. It should be noted that these formatted MTFs are build on the rules and procedures contained in ADatP-3.To support the procedures of Air Tasking and Execution the following messages should be implemented Air Tasking Order to be implemented from BL-11F.
|
Communication and Collaboration Standards Profiles
Informal Messaging Standards Profiles
Calendaring and Scheduling Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Calendaring Exchange Profile The Calendaring Exchange Profile provides standards and guidance for the exchange meeting requests, free/busy information as well as calendar sharing implemented by common user access (CUA) software. The focus of this profile is on the exchange of the aforementioned information items and does not cover other typical features found in collaboration software. |
||
Calendaring and Scheduling Services |
Candidate |
RFC 5545 is required in order to allow a vendor independent representation and exchange of calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol.RFC 5546 defines the scheduling methods that permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling.RFC 6047 defines how calendaring entries defined by the iCalendar Object Model (iCalendar) are wrapped and transported over SMTP. Authentication, Authorization and Confidentiality with S/MIME (section 2.2 of RFC 6047) is not applicable for this profile. |
Text-based Collaboration Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Text-based Collaboration Chatroom Profile The Text-based Collaboration Managed Chatroom Profile provides standards and guidance to host moderated, password-protected and member-only chatrooms to support strongly controlled persistent near-real time text-based group collaboration capability (chat) for time critical reporting and decision making in military operations. In addition to standard chatroom features such as room topics and invitations, the protocol defines a strong room control model, including the ability to kick and ban users, to name room moderators and administrators, to require membership or passwords in order to join the room, etc. |
||
Text-based Communication Services |
Candidate XMPP Services hosting the shared chatrooms must comply with the following additional extensions.
|
|
Text-based Collaboration Core Profile The Text-based Collaboration Core Profile provides standards and guidance to establish a basic near-real time text-based group collaboration capability (chat) for time critical reporting and decision making in military operations. |
||
Communication and Collaboration Applications, Metadata Repository Services, Technical Services, Text-based Communication Services |
Candidate The following standards are the base IETF protocols for interoperability of chat services.
Candidate The following standards are required to achieve compliance for an XMPP Server and an XMPP Client dependent upon the categorisation of presenting a core or advanced instant messaging service interface.
|
|
Text-based Collaboration Data Forms Profile The Text-based Collaboration Forms Profile provides standards and guidance to use (define, discover, fetch and submit) the data forms for use by XMPP entities. |
||
Communication and Collaboration Applications, Metadata Repository Services, Text-based Communication Services |
Candidate
|
|
Text-based Collaboration Tactical Profile The Text-based Collaboration Tactical Profile provides guidance and standards to support the exchange of chat messages between mission participants at the tactical level. |
||
Text-based Communication Services |
Candidate |
The current proposal (Sep 21) is to up-issue STANAG 4677 to include a Chat Extension message to support the exchange of Chat messages at the tactical level. |
Text-based Collaboration Publish-Subscribe Profile The Text-based Collaboration Publish-Subscribe Profile provide standards and guidance in support of Text-based Collaboration Publish-Subscribe Services. |
||
Text-based Communication Services |
Candidate
|
|
Text-based Collaboration Information Discovery Profile The Text-based Collaboration Information Discovery Profile provides standards and guidance to support Information Discovery about XMPP entities. |
||
Text-based Communication Services |
Candidate |
Video-based Collaboration Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Video-based Collaboration Profile The Video-based Collaboration Profile provides standards and guidance for the implementation and configuration of video teleconferencing (VTC) systems and services in a federated mission network. |
||
C3 Taxonomy |
Candidate The following standards are required for audio coding in VTC.
Candidate Use of the BFCP is conditional to that VTC conferencing services are used with the shared content like presentations and/or screen sharing, whose control needs to be shared among participants. Candidate The following standards are required for video coding in VTC. |
It Is recommended that dynamic port ranges are constrained to a limited and agreed number. This is an activity that needs to be performed at the mission planning stage. Different vendors have different limitations on fixed ports. However, common ground can always be found.As a minimum G.722.1 is to be used. Others are exceptions and need to be agreed by the mission network's administrative authority for video calls. |
Audio-based Collaboration Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Audio-based Collaboration Profile The Audio-based Collaboration Profile provides standards and guidance for the implementation of an interoperable voice system (telephony) on federated mission networks. |
||
C3 Taxonomy |
Candidate The following standards are used for audio protocols.
|
Voice over IP (VoIP) refers to unprotected voice communication services running on unclassified IP networks e.g. conventional IP telephony. Voice over Secure IP (VoSIP) refers to non-protected voice service running on a classified IP networks. Depending on the security classification of a FMN instance, VoIP or VoSIP is mandatory.If a member choses to use network agnostic Secure Voice services in addition to VoSIP, then SCIP specifications as defined for audio-based collaboration services (end-to-end protected voice) shall be used.The voice sampling interval is 40ms. |
IP voice to Half Duplex Radio The Tactical All-informed Voice Information Exchange profile, provides standards in order to establish all-informed voice communications between tactical units (TACCIS) that are interconnected via coalition waveforms. |
||
Audio-based Communication Services, Voice Access Services |
Candidate This profile covers the part of STANAG 5634 that describes the voice client interface (MELPe/RTP/UDP/IP) as well as the access to a radio device. |
This profile MUST use the RTP-HE specification for voice interfacing with the radio and MUST NOT use the VARC approach that is also described in STANAG5634. |
Media-based Collaboration Standards Profiles
Call Media Encoding Profile
Secure Voice Profile
Service | Standard | Implementation Guidance |
---|---|---|
SCIP PPK Profile In the context of secure communications, PPK is the Pre-Placed Key, which is a symmetric encryption key, pre-positioned in a cryptographic unit. Note: SCIP is depending on the FIPS 186-2 Digital Signature Standard. This standard is superseded by FIPS 186-4, which is the applicable standard in the Service Instructions for Digital Certificates. FIPS 186-2 is only allowed within the confinement of SCIP-based secure voice solutions on the mission network. |
||
C3 Taxonomy |
Candidate When PPK is applied for the Secure Communications Interoperability Protocol (SCIP), the following standards need to be followed.
|
|
SCIP X.509 Profile The X.509 standard is used in cryptography to define the format of public key certificates, which are used in many Internet protocols. One example is the use in Transport Layer Security (TLS) / Secure Sockets Layer (SSL), which is the basis for HTTPS, the secure protocol for browsing the web. Public key certificates are also used in offline applications, like electronic signatures. An X.509 certificate contains a public key and an identity (a hostname, or an organization, or an individual), and is either signed by a certificate authority or self-signed. When a certificate is signed by a trusted certificate authority, or validated by other means, someone holding that certificate can rely on the public key it contains to establish secure communications with another party, or validate documents digitally signed by the corresponding private key. Besides the format for certificates themselves, X.509 specifies certificate revocation lists as a means to distribute information about certificates that are no longer valid, and a certification path validation algorithm, which allows for certificates to be signed by intermediate Certificate Authority (CA) certificates, which are in turn signed by other certificates, eventually reaching a trust anchor. Note: SCIP is depending on the FIPS 186-2 Digital Signature Standard. This standard is superseded by FIPS 186-4, which is the applicable standard in the Service Instructions for Digital Certificates. FIPS 186-2 is only allowed within the confinement of SCIP-based secure voice solutions on the mission network. |
||
C3 Taxonomy |
Candidate When X.509 is applied for the Secure Communications Interoperability Protocol (SCIP), the following standards need to be followed.
|
|
Secure Voice Profile The Secure Voice Profile provides standards and guidance for the facilitation of secure telephony and other protected audio-based collaboration on federated mission networks. |
||
Audio-based Communication Services, Video-based Communication Services |
Candidate SCIP Signaling Plan and Negotiation.
Candidate SCIP Network Standards for operation over VoIP Real-time Transport Protocol (RTP).
Candidate SCIP Network Standards for operation over other network types.
Candidate SCIP Secure Applications. |
AComP-5068 Secure Communications Interoperability Protocol (SCIP) Edition A Version 1provides further guidance for the implementation of SCIP specifications. |
Unified Audio and Video Profile
Service | Standard | Implementation Guidance |
---|---|---|
IPSec-based Media Infrastructure Security Profile The IPSec-based Media Infrastructure Security Profile provides security standards that are used for security of media infrastructure based on Internet Protocol Security (IPSec). |
||
Audio-based Communication Services, Video-based Communication Services |
Candidate Securing the media infrastructure can be done in several ways and that the selection of the appropriate method is to be done during the mission planning. For this specific method, the following standard apply.
|
|
Media Streaming Profile The Media Streaming Profile provides standards used to stream media across the mission network. |
||
Audio-based Communication Services, Video-based Communication Services |
Candidate |
|
Priority and Pre-emption Profile The Priority and Pre-emption Profile provides standards are used to execute priority and pre-emption service with the Session Initiation protocol (SIP). |
||
Audio-based Communication Services, Video-based Communication Services |
Candidate |
|
SRTP-based Media Infrastructure Security Profile The SRTP-based Media Infrastructure Security Profile provides security standards that are used for security of media infrastructure based on Transport Layer Security (TLS) and Secure Real-time Transport Protocol (SRTP). |
||
Audio-based Communication Services, Video-based Communication Services |
Candidate Securing the MN Media infrastructure can be done in several ways and that the selection of the appropriate method is to be done during the mission planning. For this specific method, the following standard apply.
|
Note that securing the MN Media infrastructure can be done in several ways and that the selection of the appropriate method is to be done during the mission planning. |
Session Initiation and Control Profile The Session Initiation and Control Profile provides standards used for session initiation and control. |
||
Audio-based Communication Services, Video-based Communication Services |
Candidate The following standards are used for regular Session Initiation Protocol (SIP) support..
Candidate The following standards define the Session Initiation Protocol (SIP) and Real-time Transport Protocol (RTP) support for conferencing.
|
COI-Enabling Standards Profiles
Situational Awareness Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Ground-to-Air Information Exchange Profile The Ground-to-Air Information Exchange Profile provides standards and guidance to support the exchange of Friendly Force Tracking information within a coalition network or a federation of networks over Link 16. |
||
Mediation Services, Track Management Services, Wired Transmission Services, Wireless LOS Mobile Transmission Services |
Candidate |
Messages exchanged according to the exchange mechanisms described in ADatP-37(A) shall comply with the J-series message schema defined STANAG 5516, Tactical Data Exchange – Link 16 and STANAG 5518, Interoperability Standard for Joint Range Extension Application Protocol (JREAP). |
Ground-to-Air Situational Awareness Profile The Ground-to-Air (G2A) Situational Awareness Profile provides standards and guidance to support the exchange of Friendly Force Tracking information within a coalition network or a federation of networks over Link 16. |
||
Mediation Services, Track Management Services, Wired Transmission Services, Wireless LOS Mobile Transmission Services |
Candidate |
Messages exchanged according to the exchange mechanisms described in ADatP-37(A) shall comply with the J-series message schema defined STANAG 5516, Tactical Data Exchange – Link 16 and STANAG 5518, Interoperability Standard for Joint Range Extension Application Protocol (JREAP). |
Overlay Distribution Profile The Overlay Distribution Profile covers the standards for overlays and (military) symbology that identify locations on the surface of the planet. These overlays are employed when disseminating recognized domain or functional pictures and related picture elements between different communities of interest in a federated mission network environment, as well as sharing with partners operating outside of the Operational Network. |
||
Communication and Collaboration Applications, Overlay Services, Recognized Picture Services, Situational Awareness Services, Text-based Communication Services |
Candidate Applies to NVG only. Implementation Guidance is provided inNVG APP-6(D)(1) Bindings Candidate The minimum conformance level for Spiral 4 is defined as conformant with type B3R - as per the NVG 2.0.2 Specification summarized as: File-based and NVG Request/Response Protocol, all symbolized content, with timing information and operationally relevant extended data. Candidate Conditional for three use cases that typically involve cross-domain information exchange: sharing overlays outside of the Mission Network or,sharing overlays to exchange information in the form of Cross-security domain exchange. If an Affiliate has the requirement to share (export/import) with external (non-MN) organisations, then it is to support exchange via KMLexchanging of targeting and JISR products that are prepared on national networks. This particular COI have articulated a requirement to use KML for “Named Area of Interest”. In terms of conditionality, this use is to be defined by that COI. When exporting KML files that reference external resources, KML Zipped (KMZ) must be used and all relevant referenced external resources must be included in the KMZ structure as relative references. The references to these files can be found in the href attribute (or sometimes, the '"`UNIQ--nowiki-0000001F-QINU`"' element) of several KML elements. To enable cross domain exchange and long-term preservation relative references must be used for those resources that are included in the KMZ structure. As many Earth Viewers only work with legacy PKZIP 2.x format for KMZ, .zip folders shall be created in accordance withhttps://www.pkware.com/documents/APPNOTE/APPNOTE-2.0.txt. |
All presentation services shall render tracks, tactical graphics, and battlespace objects using the defined symbology standards except in the case where the object being rendered is not covered in the standard. In these exceptional cases, additional symbols shall be defined as extensions of existing symbol standards and must be backwards compatible. These extensions shall be submitted as a request for change within the configuration management process to be considered for inclusion in the next version of the specification. |
Operations Information Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Battlespace Event Federation Profile The Battlespace Event Federation Profile provides standards and guidance to support the exchange of information on significant incidents, important events, trends and activities within a coalition network or a federation of networks. |
||
C3 Taxonomy |
Candidate To support exploitation the following APP-11 message formats MUST be supported (MTF Identifier, MTF Index Ref Number): Incident Report (INCREP, A078)Incident Spot Report (INCSPOTREP, J006)Troops in Contact SALTA format (SALTATIC, A073)Events Report (EVENTREP, J092)Improvised Explosive Device Report (IEDREP, A075) The INCREP is used to report any significant incident caused by terrorism, civil unrest, natural disaster, or media activity. The INCSPOTREP is used to provide time critical information on important events that have an immediate impact on operations. The SALTATIC is used to report troops in contact, the report should be made as soon as possible by the unit that has come under some form of attack. It uses the following basic format: Size of enemy, Action of enemy, Location, Time and Action taken The EVENTREP is used to provide the chain of command information about important Events, trends and activities that do not have an element of extreme urgency, but do influence on-going operations The IEDREP is sent when an IED has been encountered. It identifies the hazard area, tactical situation, operational priorities and the unit affected. This initial report should be followed by normal EOD/Engineer reporting requirements. |
|
Friendly Force Tracking Profile The Friendly Force Tracking Profile provides standards and guidance to support the exchange of Friendly Force Tracking information within a coalition network or a federation of networks. |
||
Mediation Services, Situational Awareness Services, Track Distribution Services, Track Management Services |
Candidate |
ADatP-36 Edition A Version 2Messages exchanged according to the exchange mechanisms described in ADatP-36(A)(2) shall comply with the Message Text Format (FFI MTF) schema incorporated in APP-11.IP1 is the preferred protocol for FMN Spiral 45. Where needed, the other ADatP-36(A)(2) protocols (IP2 or WSMP 1.3.2) may be used if the situation requires this. The version of WSMP to be used in FMN Spiral 54 is version 1.3.2. This version is explicitly stated as is it is recognized that ADatP-36(A)(2) does not unambiguously state a version of WSMP to be used.ADatP-36 Edition B Version 1Messages exchanged according to the exchange mechanisms described in ADatP-36(B)(1) shall comply with the Message Text Format (FFI MTF) schema incorporated in ADatP-36(B)(1) Standard Related Document (SRD)1.IP1 is the preferred protocol for FMN Spiral 5. Where needed, the other ADatP-36(B)(1) protocols (IP2 or WSMP 1.3.2) may be used if the situation requires this. The version of WSMP to be used in FMN Spiral 5 is version 1.3.2. This version is explicitly stated as is it is recognized that ADatP-36(B)(1) does not unambiguously state a version of WSMP to be used. Note that the IP1 of the ADatP-36(A)(2) and of the ADatP-36(B)(1) are not interoperable. In case both the version need to coexist it is needed the presence of an FFT proxy service as adapter. |
Tactical Message Distribution Profile The Tactical Message Distribution Profile provides standards and guidance to support the exchange of selected messages between Tactical Data Link networks and IP based federation of networks. |
||
Tactical Messaging Access Services |
Candidate The "Minimum Link-16 Message Profile", as described in the FMN Spiral 3 Service Interface Profile for RAP Data, defines the minimum set of data elements that are required to be available for operational or technical reasons so that correctly formatted technical message can be generated to establish the COP in a federated environment. The implementation of the following message types of ATDLP-5.16 is MANDATORY and refers to Appendix A of the standard for the detailed requirement of receive or transmit support, also based on the role of the MNP: Precise Participant Location and Identification (PPLI) MessagesJ2.0 Indirect Interface Unit PPLIJ2.2 Air PPLIJ2.3 Surface (Maritime) PPLIJ2.4 Subsurface (Maritime) PPLIJ2.5 Land (Ground) Point PPLIJ2.6 Land (Ground) Track PPLISurveillance MessagesJ3.0 Reference PointJ3.1 Emergency PointJ3.2 Air Track messageJ3.3 Surface (Maritime) TrackJ3.4 Subsurface (Maritime) TrackJ3.5 Land (Ground) Point/TrackJ3.7 Electronic Warfare Product Information For MNPs that are contributing to Shared Situational Awareness production, the following messages should be supported to maximize the ability to share tactical data: J7 Information ManagementJ9 Weapons Coordination and ManagementJ10 Weapons Coordination and ManagementJ12 ControlJ13 Platform and System StatusJ15 Threat WarningJ17 Miscellaneous More recent editions of this standard may be implemented for operational use but ATDLP-5.16 is the minimum to guarantee Link 16 tactical message distribution. Candidate The JREAP Standard enables TDL data to be transmitted over digital media and networks not originally designed for tactical data exchange. JREAP consists of three different protocols: A, B and C. For implementation in FMN only JREAP-C 'Encapsulation over Internet Protocol (IP)' which enables TDL data to be transmitted over an IP network must be used. Refer to Appendix E of the standard for an overview of which messages are MANDATORY for implementation. Whenever there is a common reference clock in the JREAP network, one that is available to all nodes, it should be used. In instances when there is no reference clock available, then Round Trip Time (RTT) should be utilized. With a common time reference, all JREAP-C gateways have a simple way to synchronize and measure delays between JREAP-C nodes by looking at the time of transmission inside the incoming messages. In instances where nodes do not have a common time reference, JREAP-C offers RTT message to measure delays between gateways. These messages measure the RTT between nodes. Each node can state which time reference it will support, and which is its preferred protocol. Inherent within the standard is the ability to select either method |
JREAP is designed to support operations using Link 16 over most communication media (JRE media) including forwarding TDL data over satellite communication links, however, for implementation in FMN only JREAP-C Encapsulation over IP is to be used. It supports UDP Unicast, UDP multicast, and TCP. |
COI-Specific Standards Profiles
Command and Control Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
MIP4 Profile The Land C2 Information MIP4 Profile provides standards and guidance to support the exchange of Command and Control information within a coalition network or a federation of networks. |
||
Land Domain Services, Order of Battle Services, Situational Awareness Services |
Candidate |
The MIP4 profile should be used primarily for the exchange of Battlespace Objects (BSOs); this profile is not intended to support high volume, high frequency updates such as Friendly Force Tracking (FFT). Nor is it intended to support the exchange of data over tactical bearers (with limited capacity and intermittent availability).The MIP interoperability specification comprises both a mandatory technical interface specification as well as implementation guidance documents, and is available on the MIP website (https //www.mip-interop.org). The minimum iteration for MIP4 implementation is MIP4.3 (and MIP4.3 is the basis for the capabilities covered by the Spiral 4 Specification). However, as the MIP4 specification supports inter-version compatibility, later iterations of MIP4 (i.e. MIP4.4+) are expected to remain interoperable with MIP4.3.The suite of guidance documents includes the MIP Operating Procedures (MOP), which provides technical procedures for configuration/operation of MIP 4.3 interfaces in a coalition environment. |
Land Tactical C2 Information Exchange Profile The Land Tactical C2 Information Exchange Profile provides standards and guidance with regard to a core set of Command and Control information and also on how to exchange XML messages within a coalition tactical environment with mobile units. |
||
Situational Awareness Services |
Candidate AEP-76 is to be used for direct C2 Data Exchange between coalition units at the Mobile Tactical Edge, where a shared interoperability network is in place built upon the loaned radio concept. The data model of AEP-76 is based on variant of MIP 3.1 XML messages extended to support APP-6(D) symbology. The following messages of the messages defined in Volume II are mandatory for federating JDSS in coalition operations: JDSSDM 1.2 Presence Message ExtensionJDSSDM 1.2 Identification Message ExtensionJDSSDM 1.2 Contact/Sighting Message ExtensionJDSSDM 1.1 Sketch MessageJDSSDM 1.1 GenInfo MessageJDSSDM 1.1 Receipt MessageJDSSDM 1.2 Overlay Message ExtensionJDSSDM 1.1 Casualty Evacuation Request Message (Request Message Body only)JDSSDM 1.2 Chatrooms Message ExtensionJDSSDM 1.2 Chat Message Extension Candidate The JDSS Gateway shall use JDSSDM 1.2 exclusive mode configuration as defined by Business Rule BACK010. Candidate
|
Developers may useAEP-76 Ed A V3 XML Schema Definitionsfor implementing JDSS. |
Maritime C2 Information Exchange Profile The Maritime C2 Information Exchange Profile provides standards and guidance to support the exchange of the Recognized Maritime Picture (RMP) information within a coalition network or a federation of networks. |
||
Recognized Maritime Picture Services |
Candidate For conditional use, coupled with the AIS line from OTH-T GOLD Baseline 2007. Candidate |
The implementation of the following message types is mandatory
|
Maritime C2 Processes Profile Maritime Operations includes a set of military activities conducted by maritime air, surface, sub-surface and amphibious forces to attain and maintain a desired degree of control of the surface, sub-surface, and air above the sea, influence events ashore, and, as required, support land, air/space, and cyber operations |
||
C3 Taxonomy |
Candidate |
The maritime conflict and operation themes are likely to cover the following types of operations in the maritime environment (AJP-3.1)
|
XMPP/JDSSDM Mediation Profile. The XMPP/JDSSDM Mediation Profile provides standards and guidance on text based information exchange between TACCIS and OPCIS. |
||
Mediation Services, Situational Awareness Services, Text-based Communication Services |
Candidate |
|
MIP 4/JDSSDM Mediation Profile. The MIP 4/JDSSDM Mediation Profile provides standards and guidance on non-friendly observed reported Battlespace Objects information exchange between TACCIS and OPCIS. |
||
Mediation Services, Situational Awareness Services |
Candidate |
|
NVG/JDSSDM Mediation Profile. The NVG/JDSSDM Mediation Profile provides standards and guidance on overlays exchange between TACCIS and OPCIS. |
||
Mediation Services, Situational Awareness Services |
Candidate |
|
ADatP-36/JDSSDM Mediation Profile. The ADatP-36/JDSSDM Mediation Profile provides standards and guidance on self reporting FFT exchange between TACCIS and OPCIS. |
||
Mediation Services, Situational Awareness Services |
Candidate |
Intelligence and ISR Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
ISR Library Interface Profile The ISR Library Interface is the standard interface for querying and accessing heterogeneous product libraries maintained by various nations. |
||
Intelligence and ISR Functional Services |
Candidate The following NATO standards provide the specification as well as business rules for interoperability of ISR libraries. Candidate The following NATO standards are mandated for interoperability of ISR library products.
Candidate The Basic Image Interchange Format (BIIF) is mandated for interoperability of ISR libraries.
Candidate The following international standards are mandated for interoperability of ISR libraries.
Candidate Implementation of JC3IEDM (STANAG 5525) in the context of the ISR Library Interface Profile is limited to the definition of unique keys that could be used to unambiguously refer to an external information object that is modelled in accordance with JC3IEDM. Note that AEDP-17 refers to the metadata attribute “JC3IEDMIdentifier” on page G-15, but to “identifierJC3IEDM” on page G-79. The correct attribute to use is “identifierJC3IEDM”. |
To ensure optimization of network resources the ISR Library Interface services work best with a unicast address space.AEDP-17 defines four interfaces
|
ISR Streaming Profile The ISR streaming services architecture defined by AEDP-18 covers the ISR enterprise wide sharing and management of streaming data, i.e. data generated by sensors and which is periodically updated. The ISR Streaming Services Standard mandates support for streams of one or more of the data types: Ground Moving Target Indicator (GMTI),Motion imagery,Link 16. The supported datatype(s) of the ISR Streaming Services are required information in the Joining instructions. |
||
ISR Exploitation Services, Intelligence and ISR Functional Services |
Candidate Candidate Implementation mandates that one or more of the following standards be implemented:
|
The operational processes facilitated by the ISR Streaming architecture are described in detail in the Procedural Instructions for JISR and Intelligence Products which is based on AIntP-16 (IRM&CM procedures) and AIntP-14 (JISR procedures). |
CIS Support Standards Profiles
SMC Orchestration Profile
Service | Standard | Implementation Guidance |
---|
SMC Process Implementation Profile
SMC Process Implementation Profile for Enabling Processes
Service | Standard | Implementation Guidance |
---|---|---|
SMC Process Implementation Profile for Party Management The Party Management, leveraging the TM Forum Party Management API, enables the exchange of federated Parties between Mission Network Participants. |
||
C3 Taxonomy |
Candidate |
|
SMC Process Implementation Profile for Geographic Location Management The Geographic Location Management, leveraging the - TM Forum Geographic Address Management API, - Tm Forum Geographic Site Management API, - Tm Forum Location Management enables the exchange of federated Locations between Mission Network Participants. |
||
C3 Taxonomy |
Candidate |
|
SMC Process Implementation Profile for Activity Management Description The Activity Management, leveraging the TM Forum Process Flow Management API, enables the exchange of federated Service Tasks between Mission Network Participants. |
||
Business Support SMC Services |
Candidate |
Federated Fires profiles
Service | Standard | Implementation Guidance |
---|---|---|
Kinetic Indirect Fire Support Information Exchange profile The Kinetic Indirect Fire Support Information Exchange profile provides standards and guidance to plan, prepare and execute kinetic fires missions, in support of Land maneuver forces, within a coalition network or a federation of networks. |
||
C3 Taxonomy |
Candidate |
Contact NATO ICGIF IER Panel Chair about ASCA-012 CTIDP.========Digital Fire Control Systems must be qualified to guarantee a sufficient level of interoperability. Upon necessary Information Assurance objectives, Dependability of digital fire control systems (DFCS) is the most critical objective to reach, in order to ensure a fast, constant, reliable and safe Fire Support service to maneuver units.For now and the purpose of indirect kinetic fire support, and in accordance with STANAG-2245 and STANAG-2432 (AArtyP-03), be a Full or Associated ASCA Member is the stipulated way for an Affiliate to ensure such an aim.After be sponsored, nation implements ASCA-012 CTIDP, coached by its sponsoring nation, and demonstrates interoperability with at least two Full ASCA Members.
|
Communications Access Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Inter-Autonomous Systems Multicast Signaling Profile The Inter-Autonomous Systems Multicast Signaling Profile provides standards and guidance for multicast group signaling between inter-autonomous systems. |
||
C3 Taxonomy |
Candidate Service providers with their own multicast capability shall implement Rendezvous Point (RP) and provide signaling between their network segments supporting the following IP multicast signaling standards. |
|
Inter-Autonomous Systems Routing Profile The Inter-Autonomous Systems Routing Profile provides standards and guidance for routing between inter-autonomous systems. The best current practice for the Border Gateway Protocol (BGP) based network routing operations and security is described in RFC 7454 - "BGP Operations and Security". Deployment guidance with regards to the application of BGP in the Internet is described in IETF RFC 1772:1995. |
||
Audio-based Communication Services, Packet Routing Services, Video-based Communication Services |
Candidate The following standards apply for all IP interconnections.
Candidate Additionally, the following standards apply for use of communities, extended communities and 32-bit extended communities for traffic engineering purposes.
Candidate The following standard is added to improve security of BGP peering Candidate The following standards are added to improve BGP resilience through faster detection of network failures |
BGP sessions must be authenticated, through a TCP message authentication code (MAC) using a one-way hash function (MD5), as described in IETF RFC 4271. |
Traffic Flow Confidentiality Protection Profile The Traffic Flow Confidentiality Protection Profile provides standards and guidance for implementing IPSEC based protection for data traffic. |
||
Authentication Services, Communications Security Services, Transport Cryptography Services |
Candidate These are standards to implement protection profiles needed for IPSec.
|
|
Generic Routing Encapsulation profile The Routing Encapsulation Profile provides standards and guidance for generic routing encapsulation functions over network interfaces both in PCN and in Information Domain network interconnection points (NIPs). |
||
Packet-based Broadcast Services, Packet-based Transport Services |
Candidate Standards for GRE tunneling in IPv4 Candidate Standards for GRE tunneling in IPv6 Candidate Key and sequence number extension for GRE |
|
Inter-Autonomous Systems Multicast Source Discovery Profile The Inter-Autonomous Systems Multicast Source Discovery Profile provides standards and guidance for multicast group source active signaling between inter-autonomous systems. |
||
C3 Taxonomy |
Candidate Service providers with their own multicast capability shall provide signaling between their Rendezvous Point (RP) supporting the following IP multicast source discovery standards. |
|
Inter-Domain Multicast Planning Profile Multicast management within inter-domain context requires careful planning and orchestration. |
||
C3 Taxonomy |
Candidate The following standards shall apply to multicast routing. |
|
NMCD Information Exchange Service Profile The NMCD Information Exchange uses RESTCONF-like exchange semantics to distribute Protected Core Community PCSOP information throughout the community. |
||
Web Hosting Services, Web Platform Services |
Candidate NMCD IES uses a subset of the RESTCONF protocol to exchange information between peering NMCD IESes. Candidate NMCD IES client discovers the resource root endpoint of the RESTCONF protocol using the Web Host Metadata standard. Candidate Information published by the NMCD IES is labelled according to ADatP-4774 confidentiality information label schema. Candidate Confidentiality Information Labels used by the NMCD IES are bound to data objects using the ADatP-4778 Metadata Binding Mechanism. |
Communications Transport Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
IP Quality of Service Profile The IP Quality of Service Profile provides standards and guidance to establish and control an agreed level of performance for Internet Protocol (IP) services in federated networks. |
||
Packet-based Broadcast Services, Packet-based Transport Services |
Candidate The following normative standard shall apply for IP Quality of Service (QoS).
Candidate Following standards give more information on implementation of QoS within IP networks.
|
|
Inter-Autonomous Systems IP Communications Security Profile The Inter-Autonomous Systems IP Communications Security Profile provides standards and guidance for communications security for transporting IP packets between federated mission network interconnections and in general over the whole Mission Network. |
||
Communications Security Services |
Candidate In missions where no NATO information products are carried over the mission network, the MISSION SECRET (MS) communications infrastructure is protected with technical structures by mutual agreement made during the mission planning phase. Candidate In missions where NATO information products are carried over the mission network, the MISSION SECRET (MS) communications infrastructure is protected at minimum with Type-B crypto devices. |
|
Inter-Autonomous Systems IP Transport Profile The Inter-Autonomous Systems IP Transport Profile provides standards and guidance for Edge Transport Services between autonomous systems, using the Internet Protocol (IP) over point-to-point ethernet links on optical fibre. |
||
Frame-based Access Services, Packet-based Access Services, Transport Services |
Candidate Section 3 - Clause 38 - 1000BASE-LX, nominal transmit wavelength 1310nm. Candidate The use of LC-connectors is required for network interconnections inside shelters (or inside other conditioned infrastructure).
Candidate Physical connectors for harsh environments
Candidate |
Use 1 Gb/s ethernet over single-mode optical fibre (SMF). |
Interface Auto-Configuration Profile The Interface Auto-Configuration Profile provides standards and guidance for support of the Routing Information Protocol (RIPv2 and RIPng) to expand the amount of useful information carried in RIP messages for the exploitation of auto-configurations over NIP-G and PCN-compliant interfaces, and for the inclusion of a measure of control. |
||
C3 Taxonomy |
Candidate |
The auto-configuration is a highly recommended feature for the desired flexibility, maintainability and survivability in communications systems configuration. Nevertheless, there is always an option to follow a manual configuration process. This implies that auto-configuration in itself is not mandatory; when applied, the listed standards are mandatory. |
Tactical Interoperability Network Interconnection Profile The Tactical Interoperability Network Interconnection Profile provides standards and guidance for a shared interoperability network at the mobile tactical edge: when no common waveform for land tactical radios can be used to interconnect networks, a standard "bridging" solution with loaned radios can be used to mitigate the interoperability problem. In that situation, interoperability will be achieved with the exchange of assets. Information exchange for mobile users at the tactical edge is based onSTANAG 4677. The information exchange over the loaned radio interface shall be protected with similar mechanisms that are required to protect NATO RESTRICTED information or an equivalent mission classification level. The protection of information at the lower tactical level has a number of distinctive characteristics: The information is often transient and perishable – it is only relevant for a short period of time.The transmission of information is confined to a small geographic area.The information is held on portable devices which are often close to physical threats.The networks at the lower tactical level are often isolated from the wider network. |
||
C3 Taxonomy |
Candidate
Candidate Implement the following standard in addition to RFC 1112. |
This profile is to be used exclusively for operations at the tactical edge (TACCISMC 0640) and not in combination with any of the other profiles defined in the SP4 SI for Communications, which are targeted at OPCISMC 0640. |
IPv4 Transport Services Profile Implementation guidance for the implementation of standards for transport service based on Internet Protocol version 4 (IPv4). |
||
Edge Services, Packet-based Access Services, Packet-based Broadcast Services, Packet-based Transport Services, Transport Services |
Candidate Standards for Internet Protocol version 4 (IPv4). Candidate Standards for Internet Protocol version 4 (IPv4) over Ethernet.
Candidate For automatic detection of the maximum transmission unit (MTU) between end-points. |
|
IPv6 Transport Services Profile Implementation guidance for the implementation of standards for transport service based on Internet Protocol version 6 (IPv6). |
||
Packet-based Access Services, Packet-based Broadcast Services, Packet-based Transport Services, Transport Services |
Candidate These standard are used for point-to-point interconnections between network devices. Candidate Standards for IPv6 address allocation scheme utilizing reserved address space for Unique Local IPv6 Unicast Addresses. It should be noted that actual allocation policy is not following the RFC, but co-ordinated policy. Also prefix that is used is from the non-defined area of ULA addresses. Candidate Standards for IPv6 Anycast address assignment. These standards need to be taken account when assigning IPv6 addresses on systems. Candidate Standards for Internet Protocol version 6 (IPv6) and Internet Control Message Protocol for IPv6 (ICMPv6).
Candidate For automatic detection of the maximum transmission unit (MTU) between end-points. It is strongly recommended that IPv6 nodes implement Path MTU Discovery, in order to discover and take advantage of path MTUs greater than 1280 octets. Candidate Standards for Internet Protocol version 6 (IPv6) neighbor discovery over link level network. Candidate Standard for understanding different options to generate IPv6 addresses. |
|
IP Access to Tactical Radio This profile described the standards for IP access to a tactical radio. It contains the IP requirements of STANAG 5634 and STANAG 4677. This includes at least the following standards: UDP, IPv4 unicast and multicast, including IP addressing standards, IGMPv3, ICMP, DSCP. |
||
IPv4 Routed Access Services, Packet-based Broadcast Services, Packet-based Transport Services |
Candidate A Standard for the Transmission of IP Datagrams over Ethernet Networks (IPv4) Candidate Internet Standard Subnetting Procedure Candidate Host extensions for IP multicasting Candidate Path MTU discovery Candidate Address Allocation for Private Internets Candidate Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers Candidate Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan Candidate IANA Guidelines for IPv4 Multicast Address Assignments Candidate Internet Group Management Protocol, Version 3 |
|
NINE ISPEC NINE ISPEC - NETWORKING AND INFORMATION INFRASTRUCTURE (NII) INTERNET PROTOCOL (IP) NETWORK ENCRYPTOR – INTEROPERABILITY SPECIFICATION, will serve as a basis and allows manufacturers from different nations to develop and produce interoperable IPsec devices to be used in federated IP network environments such as the Federated Mission Networking (FMN). |
||
Communications Security Services |
Candidate |
AComP-4787 Ed1 contains several sections out of which following form basis for interoperability in the context of FMN SP5
|
Infrastructure Standards Profiles
Infrastructure Security Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Certificates Exchange Profile The Certificates Exchange Profile specifies the use of public standards for exchange of digital certificates. |
||
Digital Certificate Services, Technical Services |
Candidate The PEM format with base64-encoded data shall be used to exchange Certificates, Certificate Revocation Lists (CRLs), and Certification Requests. |
|
Cryptographic Algorithms Profile The Cryptographic Algorithms Profile specifies the use of public standards for cryptographic algorithm interoperability to protect IT systems. |
||
Digital Certificate Services, Technical Services |
Candidate
|
The following algorithms and parameters are to be used to support specific functions
|
Digital Certificate Profile The Digital Certificate Profile provides standards and guidance in support of a Public Key Infrastructure (PKI) on federated mission networks. |
||
Digital Certificate Services, Technical Services |
Candidate |
The version of the encoded public key certificate shall be version 3.For further guidance on the implementation the AC/322-N(2020)0077 iTIF Certificate Profiles Version 1.2.2 shall also be considered. |
Transport Layer Security Fallback Profile This profile provides detailed information, guidance, and standardsto be used for the usage of Transport Layer Security version 1.2 (TLS 1.2) protocol to provide authentication, confidentiality and integrity services for protecting the communication between service providers and consumers. |
||
Directory Services, Informal Messaging Services, Technical Services, Text-based Communication Services, Web Hosting Services |
Candidate TLS 1.2 compression SHALL be disable with the use of the "null" compression method. Candidate TLS 1.2 base standards. Mandatory extensions: Section 7.4.1.4.1 - Signature Algorithms
Candidate Transport Layer Security (TLS) Renegotiation Indication Extension Renegotiation shall only be initiated by the server.Implementation shall be compliant with RFC 7525, section 3.5 Candidate TLS extensions Mandatory extensions: Section 3 - Server Name Indication Extension Disallowed extensions: Section 7 - Truncated HMAC Candidate Session Hash and Extended Master Secret Extension Candidate Negotiated Finite Field Diffie-Hellman Ephemeral Parameters Required curves: secp256p1secp384p1 Candidate Supported Elliptic Curves extension. Required extensions: Section 5.1/5.2 - Supported Point Formats Required curves: secp256r1secp384r1 |
Certificate validation
|
Transport Layer Security Profile This profile provides detailed information, guidance, and standards to be used for the usage of Transport Layer Security version 1.3 (TLS 1.3) protocol to provide authentication, confidentiality and integrity services for protecting the communication between service providers and consumers. |
||
Directory Services, Informal Messaging Services, Technical Services, Text-based Communication Services, Web Hosting Services |
Candidate Base standard |
Certificate validation
|
Digital Certificate Validation (OCSP) Profile The Digital Certificate Validation (OCSP) Profile provides standards and guidance in support of a digital certificate validation based on OCSP. |
||
Digital Certificate Services |
Candidate The Online Certificate Status Protocol (OCSP) capability is mandatory for PKI Service providers. Clients might support this protocol. |
The addresses of OCSP endpoints shall be provided in digital certificates through Authority Information Access (AIA) extension. |
Digital Certificate Validation (CRL) Profile The Digital Certificate Validation (CRL) Profile provides standards and guidance in support of a digital certificate validation based on CRL. |
||
Digital Certificate Services |
Candidate Service profile Digital Certificate Validation (CRL) Profile does not refer to any standard. |
CRLs may be provided at multiple locations, these are to be provided in digital certificates through the cRLDistributionPoints extension. Each CA is to provide CRLs over HTTP. Clients must support this protocol.The version of the encoded certificate revocation list (CRL) shall be version 2. |
Infrastructure Networking Standards Profiles
Domain Naming Profile
Service | Standard | Implementation Guidance |
---|---|---|
Secure Domain Naming Profile The Secure Domain Naming Profile provides standards and guidance to support the hierarchical distributed name system with a set of extensions to DNS which provide to DNS clients (resolvers) cryptographic authentication of DNS data, authenticated denial of existence, and data integrity, but not availability or confidentiality. These extensions are combined in the Domain Name System Security Extensions (DNSSEC), a suite of Internet Engineering Task Force (IETF) specifications for securing certain kinds of information provided by the Domain Name System (DNS) as used on Internet Protocol (IP) networks. |
||
C3 Taxonomy |
Candidate
|
Only the following security algorithms shall be used
|
Zone Transfer Profile The Zone Transfer Profile provides standards and guidance to support zone synchronization in the hierarchical distributed name system for authoritative name servers of federated mission network ing. |
||
C3 Taxonomy |
Candidate
Candidate Mandatory message digest algorithm is hmac-sha384. |
|
Anycast DNS Profile The Anycast DNS Profile provides standards and guidance for operating an Authoritative Name Service on an anycast address. |
||
Packet-based Access Services |
Candidate DNS operation on shared unicast address Candidate Operation of anycast services |
|
Generic Domain Naming Profile The Generic Domain Naming Profile provides base standards and guidance to support the hierarchical distributed name system for computers, services, or any resource connected to a federated mission network. |
||
C3 Taxonomy |
Candidate Base standards
Candidate Additional types and bigger payloads |
|
IPv6 Domain Naming Profile The IPv6 Domain Naming Profile contains additions to the base Domain Name System standards, which enable the usage of the Domain Name System in the context of the Internet Protocol, version6. |
||
C3 Taxonomy |
Candidate DNS Extensions for IP version 6 Candidate Address Selection |
Time Synchronization Profile
Service | Standard | Implementation Guidance |
---|---|---|
Peer Time Synchronization Profile The Symmetric Peer Profile provides standards and guidance to support the symmetric synchronization of time servers on the same NTP stratum level across a network or a federation of networks. |
||
Distributed Time Services |
Candidate Protocol modes 1 and 2 |
|
Federation Time Synchronization Profile The Client/Server Synchronization Profile provides standards and guidance to support the synchronization of clients and servers across a network or a federation of networks and the safeguard of the accurate use of timestamps. |
||
Distributed Time Services |
Candidate Protocol modes 3 and 4 |
Stratum 1 servers must implement IPv4 so that they can be used as time servers for IPv4-based mission networks. |
Infrastructure Processing Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Virtual Appliance Interchange Profile The Virtual Appliance Interchange Profile provides standards and guidance to support the Virtualized Processing Services to exchange virtual appliances between different host platforms. |
||
Technical Services, Virtualized Processing Services |
Candidate File format for virtual hard disk drives, which the service consumer has to be able to provide.
Candidate OVF format shall be used as exchange format. |
To ensure optimization of the exchange of virtual appliances, the following guidelines should be observed.The environment should be prepared for optimal implementation of a virtual machine (VM).
|
Platform Standards Profiles
Database Platform Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Directory Data Exchange Profile The Directory Data Exchange Profile provides standards and guidance in support of a mechanism used to connect to, search, and modify Internet directories on the basis of the Lightweight Directory Access Protocol (LDAP). |
||
Directory Services |
Candidate
|
|
Directory Data Structure Profile The Directory Data Structure Profile provides standards and guidance in support of the definition of the namespace of a federated mission network on the basis of the Lightweight Directory Access Protocol (LDAP). The Directory Data Structure Profile facilitate the need to share contact information across all participants of a federation, in order to support improved collaboration and communication, for example through the sharing of a Global Address List (GAL) for email addresses. |
||
Directory Services |
Candidate |
The central DIT, for sharing GAL information, is based on the IETF standards for 'inetOrgPerson' LDAP Object Class.The Federated Directory Services shall be able to exchange inetOrgPerson object class with mandatory Common Name (cn) and Surname (sn) attributes.Based on the specific mission network's requirements, the list of exchanged attributes for a particular mission network might be extended by Service Management Authority (SMA) during the planning process. The table provides mandatory, recommended and optional specific guidance of such attributes within a federation context. The attributes refer back to those attributes as defined in ACP 133 Supp-1(C).[CREATE TABLE FROM TABLE 3 IN SIP FOR IDENTITY INFORMATION] |
Global Address List Schema Mapping Profile Participants within a federation may use different directory representations (Active Directory and IETF schemas) for GAL information, therefore, information within the different directories needs to be mapped to the correct representation for each participant. |
||
C3 Taxonomy |
Candidate |
The ‘Contact’ Object Class, defined in Microsoft Active Directory schema, is not a standard LDAP class.In the case a mapping is required to be performed between the standardised IETF 'inetOrgPerson' Object Class and the 'Contact' Object Class then the following rules must be applied
|
Web Platform Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Metadata Labelling Profile Metadata Labelling Profile describes how to apply standard confidentiality metadata to common protocols and file formats. |
||
Communication and Collaboration Applications, Direct Messaging Services, Informal Messaging Services, Metadata Repository Services, Technical Services, Text-based Communication Services, User Applications, Web Hosting Services |
Candidate The Allied Data Publication and associated binding profiles describe the syntax and mechanisms for applying Confidentiality Metadata. |
The structure of the binding is defined in ADatP-4778.The labelling values shall be based on the security policy defined for the mission. |
Web Authentication Profile The Web Authentication Profile provides standards and guidance in support of principal authentication and exchange of authenticated principal's identity attributes between Mission Network Participants. |
||
Security Token Services, Web Hosting Services |
Candidate
|
Identity providers must support the following components of the SAML 2.0 specification
|
Structured Data Profile The Structured Data Profile provides standards and guidance for the structuring of web content on federated mission networks. |
||
Direct Messaging Services, Technical Services, User Applications, Web Hosting Services |
Candidate General formatting of information for sharing or exchange.
|
XML shall be used for data exchange to satisfy those Information Exchange Requirements (IERs) within a FMN mission network instance that are not addressed by a specific information exchange standard. XML schemas and namespaces are required for all XML documents. |
Web Content Profile The Web Content Profile provides standards and guidance for the processing, sharing and presentation of web content on federated mission networks. Web presentation services must be based on a fundamental set of basic and widely understood protocols, such as those listed below. These recommendations are intended to improve the experience of Web applications and to make information and services available to users irrespective of their device and Web browser. However, it does not mean that exactly the same information is available in an identical representation across all devices: the context of mobile use, device capability variations, bandwidth issues and mobile network capabilities all affect the representation. Some services and information are more suitable for and targeted at particular user contexts. While services may be most appropriately experienced in one context or another, it is considered best practice to provide as reasonable experience as is possible given device limitations and not to exclude access from any particular class of device, except where this is necessary because of device limitations. |
||
Web Hosting Services |
Candidate Publishing information including text, multi-media, hyperlink features, scripting languages and style sheets on the network.
Candidate Providing a common style sheet language for describing presentation semantics (that is, the look and formatting) of documents written in markup languages like HTML. |
To enable the use of web applications by the widest possible audience, web applications shall be device independent and shall be based on HTML5 standards and criteria for the development, delivery and consumption of web applications and dynamic websites. HTML5 contains new features for attributes and behaviors, plus a large set of associated technologies such as CSS 3 and JavaScript that allows more diverse and powerful Web sites and applications.Web applications will not require any browser plug-ins on the client side as some organizations or end user devices do not allow the use of Java Applets or proprietary extensions such as Silverlight (Microsoft), Flash (Adobe) or Quick Time (Apple). Implementers shall use open standard based solutions (HTML5 / CSS3) instead.These requirements are mandatory for all web content consumers (browsers) and are optional for web content providers. It is expected that in the future FMN Spiral Specifications they will also become mandatory for the web content providers. |
Web Feeds Profile The Web Feeds Profile provides standards and guidance for the delivery of content to feed aggregators (web sites as well as directly to user agents). |
||
Web Hosting Services |
Candidate Web content providers must support at least one of the two standards (RSS and/or Atom).
Candidate Receivers of web content such as news aggregators or user agents must support both the RSS and the ATOM standard. |
RSS and Atom documents should reference related OpenSearch description documents via the Atom 1.0 link element, as specified in Section 4.2.7 of RFC 4287.The rel attribute of the link element should contain the value search when referring to OpenSearch description documents. This relationship value is pending IANA registration. The reuse of the Atom link element is recommended in the context of other syndication formats that do natively support comparable functionality.The following restrictions apply
|
Web Platform Profile The Web Platform Profile provides standards and guidance to enable web technology on federated mission networks. |
||
Web Hosting Services |
Candidate
|
HTTP MAY (only) be used as the transport protocol for CRL and AIA exchange between all service providers and consumers (unsecured HTTP traffic). HTTP traffic shall use port 80 by default.HTTPS MUST be used as the transport protocol between all service providers and consumers to ensure confidentiality requirements (secured HTTP traffic). HTTPS traffic shall use port 443 by default. |
Web Service Messaging Profile The Web Service Messaging Profile (WSMP) defines a set of service profiles to exchange a wide range of XML-based messages. WSMP is extensible and may be used by any Community of Interest (COI). It is based on publicly available standards and defines a generic message exchange profile based on the Request/Response (RR) and the Publish/Subscribe (PubSub) Message Exchange Pattern (MEP). WSMP is platform independent and can be profiled for different wire protocols such as SOAP. Other protocols like REST, JMS, AMQP, and WEBSocket will be profiled later. This profile is intended for software developers to implement interoperable "WSMP services" and "WSMP clients". |
||
C3 Taxonomy |
Candidate |
To enable plug-and-play interoperability a pre-defined minimum set of topics referenced and shared by multiple communities of interest is recommended. This TopicNamespace is included in Annex A Information Products - Detailed Definitions to the FMN Spiral 4 Procedural Instructions for Situational Awareness.The version of the WSMP Standard used with MIP4-IES (Version 4.3) is WSMP 1.3.2. |
Web Services Profile The Web Services Profile provides standards and guidance for transport-neutral mechanisms to address structured exchange of information in a decentralized, distributed environment via web services. |
||
C3 Taxonomy |
Candidate
Candidate Provide the elements a web service needs to deliver a suitable UI service, such as remote portlet functionality. |
The preferred method for implementing web-services are SOAP, however, there are many use cases (mashups etc.) where a REST based interface is easier to implement and sufficient to meet the IERs.Restful services support HTTP caching, if the data the Web service returns is not altered frequently and not dynamic in nature. REST is particularly useful for restricted-profile devices such as mobile phones and tablets for which the overhead of additional parameters like headers and other SOAP elements are less. The foundational document of the REST architectural style may be found athttp //www.ics.uci.edu/~fielding/pubs/dissertation/top.htm. |
OAuth 2.0 Authorization Server Bootstrap Profile OAuth 2.0 Authorization Server Bootstrap Profile provides standards and guidance on how OAuth 2.0 Clients can obtain the necessary information required to interact with an OAuth 2.0 Authorization Server. |
||
Direct Messaging Services, Security Token Services, Technical Services, User Applications |
Candidate |
The OAuth 2.0 Authorization Server Metadata is retrieved from a well-known location.Alternatively, OAuth 2.0 Clients can configure some or all of this information in an out-of-band manner.As a minimum the OAuth 2.0 Authorization Server Metadata is recommended to contain the issuer, token_endpoint, jwks_uri and grant_types_supported fields. |
SAML 2.0 Bootstrap Profile The SAML 2.0 Bootstrap profile is based on the SAML2.0 standard. |
||
Direct Messaging Services, Security Token Services, Technical Services, User Applications |
Candidate |
|
Security Token Services Profile The Security Token Services Profile supports the exchange of SAML 2.0 assertions to support federated Identity and Access Management. |
||
Direct Messaging Services, Security Token Services |
Candidate Candidate |
How the SAML 2.0 Token has been retrieved from the local STS to be used at the federated STS is not a federation issue.The operations that are specified here are the minimal operations that SHALL be implemented by the STS in order to support the exchange of SAML Security Tokens between federation partners. Other operations that are defined by the relevant specification MAY be implemented by the STS in accordance with those specifications.
|
OAuth 2.0 Assertion Grant Profile The OAuth 2.0 Assertion Grant Profile supports the exchange of SAML 2.0 or JWT assertions for Access Tokens to be used to access federated protected resources (i.e. REST-based web services) |
||
Direct Messaging Services, Security Token Services |
Candidate
Candidate |
A federated Authorization Server supports this profile by providing a Security Token Service Endpoint (HTTP collection resource identified by the request URI) for a Client to make a request to exchange a Security Token (SAML or JWT assertion) from its own domain for a new Security Token (Access Token) that can be used to support chaining web services and access to federated protected resources.How the Client receives a SAML or JWT assertion is out of scope for this profile.The SAML assertion, if used, shall be compliant with the structure specified in the SIP for Middleware.The JWT assertion, if used, shall be compliant with the structure specified in the SIP for Middleware.When complying with this profile the Client must set the fields of its assertion grant token requests as follows
|
SAML 2.0 Assertion Profile The SAML 2.0 Assertion Profile facilitates interoperability for distributing Claims, structured in SAML 2.0, between federated entities. |
||
Direct Messaging Services, Security Token Services |
Candidate |
The list of Claims to be provided in the SAML assertions has to be defined for each federation context and may differ from federation to federation.The recommendations in the Service Interface Profile (SIP) for Middleware are intended to give directives, along with clarifications and amendments on the use of mandatory and recommended requirements to be implemented by the services that support SAML assertions. |
JSON Web Token Assertion Profile The JSON Web Token Assertion Profile facilitates interoperability for distributing Claims, structured as a JWT assertion, between federated entities. |
||
Direct Messaging Services, Security Token Services |
Candidate |
The list of Claims to be provided in the JWT assertion has to be defined for each federation context and may differ from federation to federation.The recommendations in the Service Interface Profile (SIP) for Middleware are intended to give directives, along with clarifications and amendments on the use of mandatory and recommended requirements to be implemented by the services that JSON Web Tokens. |
OAuth 2.0 Access Token Profile The OAuth 2.0 Access Token Profile facilitates interoperability for distributing Claims, structured as a JWT bearer Access Token, between federated entities. |
||
Direct Messaging Services, Security Token Services |
Candidate |
The list of Claims to be provided in the JWT access token has to be defined for each federation context and may differ from federation to federation.The recommendations in the Service Interface Profile (SIP) for Midleware are intended to give directives, along with clarifications and amendments on the use of mandatory and recommended requirements to be implemented by the services that support OAuth 2.0 Access Tokens in JSON Web Token format. |
Secure SOAP-based Request Response Profile The Request-Response Message Exchange Pattern (MEP) involves a consumer sending a request message to a provider, which receives and processes the request, ultimately returning a message in response. The Secure SOAP-based Request Response profile provides the key elements of security infrastructure required to implement uniform, consistent, interoperable and effective protection of the resources exposed by partners in a federated environment. |
||
Direct Messaging Services, Technical Services, User Applications |
Candidate
|
The recommendations provided in the Service Interface Profile (SIP) Securing SOAP-based Request-Response Web Services are intended to give directives, along with clarifications and amendments on the use of securing SOAP-based Request-Response web services. |
Secure REST-based Request Response Profile The Secure REST-based Request Response profile supports consistent and compliant use of the uniform interface offered by HTTP for accessing a federated protected resource (REST-based Web Service). The Client makes a protected access request to the Resource Server (authority part referred to within the request URI) presenting the Access Token in the Header of the HTTP request. If the Access Token is successfully validated the Resource Server processes the authorised request and the result is returned to the Client. |
||
Direct Messaging Services, Technical Services, User Applications |
Candidate |
The Access Token is encoded in the HTTP Authorization entity-header by the Client.The auth-scheme parameter for the HTTP Authorization entity-header is specified to indicate the type of Access TokenAs a minimum for complying with this profile, the auth-scheme parameter value for the HTTP Authorization Header is Bearer.Note If supporting the OAuth 2.0 DPoP Profile the auth-scheme parameter value is DPoP).Note If supporting the OAuth 2.0 HTTP Message Signatures Profile the auth-scheme parameter value is PoP).In the cases where a Client receives a 401 status error code, that Client SHALL request an Access Token from the Authorization Server as specified in PRF-139 OAuth 2.0 Assertion Grant Profile. |
SOAP-Based Request Response Profile The SOAP-Based Request Response Profile defines the standard interface for sending a SOAP Message from a Consumer to a Provider and returning the results. The profile covers only the call from a Consumer to the Provider using SOAP, and the response from the Provider. This details the structuring of the Message. |
||
Direct Messaging Services, Technical Services, User Applications |
Candidate |
Providers must reject unsupported versions of SOAP.Upon request, Providers are to make available to authorized Consumers a Web Service Description Language (WSDL) describing the service interface. |
REST-Based Request Response Profile The REST-Based Request Response Profile provides the implementation details for REST-based Request-Response Message Exchange Pattern (MEP). The profile covers only the call from a Consumer to the Provider using HTTP, and the response from the Provider. |
||
Direct Messaging Services, Technical Services, User Applications |
Candidate
Candidate Candidate Candidate
Candidate Candidate |
When a Consumer asks a Provider for a resource, the Provider is expected to respond with the best possible representation for that resource, given the Consumer's preferences.This profile places no constraints on the type of data that can be exchanged between Consumers and Providers in the body of an HTTP Message request or response. However, it is recommended that XML or JSON be used as the MIME media type exchanged between Consumers and Providers in the body of an HTTP Message request or response.HTTP requests from the Consumers using the HTTP verbs GET, HEAD, PUT and DELETE are honoured as idempotent requests by the Provider.Create, Read, Update and Delete (CRUD) are the main operations used when dealing with information in persistent storage.While REST/HTTP has similar operations, the correspondence with CRUD is not a direct one-to-one match, specifically for the Create and Update methods, but also due to the granularity of HTTP resources.REST offers generic uniform HTTP interface methods (HTTP verbs RFC 7231 (IETF)]) that apply to the request URI entity which is the URI specified on the HTTP request.It is RECOMMENDED that RESTful web services use the prescribed HTTP verbs for Create, Read, Update and Delete (CRUD) operations as specified in below
|
Direct Notification Publish Subscribe Profile This profile provides provides standards and guidance for Publish-Subscribe components (Producer, Subscription Manager and Consumer) based on WS-BaseNotification. |
||
Direct Messaging Services, Technical Services, User Applications |
Candidate Candidate |
|
Brokered Notification Publish Subscribe Profile The Brokered Notification Publish Subscribe Profile provides standards and guidance based on WS-BrokeredNotification. |
||
Direct Messaging Services, Message Brokering Services, Technical Services, User Applications |
Candidate Candidate |
In a brokered environment it is possible to generate a situation, where notifications may circulate in a set of brokers. This behaviour has to be solved with organisational methods if no additional features are added to a brokered environment. |
OAuth 2.0 DPoP Profile DPoP, an abbreviation for Demonstrating Proof-of-Possession at the Application Layer, is an application-level mechanism for sender-constraining OAuth access and refresh tokens. It enables a client to demonstrate proof-of-possession of a public/private key pair by including a "DPoP" header in an HTTP request. The OAuth 2.0 Proof of Possession Profile is based on the internet draft ID OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer1. |
||
Direct Messaging Services, Security Token Services, Technical Services, User Applications |
Candidate Service profile OAuth 2.0 DPoP Profile does not refer to any standard. |
Proof-of-Possession IS supported between the Client and the Authorization Server; and, Client and Resource Server. |
OAuth 2.0 HTTP Message Signatures Profile The OAuth 2.0 framework provides methods for Clients to get delegated access tokens as bearer tokens from an Authorization Server for accessing protected resources. The OAuth 2.0 HTTP Message Signatures Profile defines an access token type that binds the access token to a cryptographic key known to the Client1. The Client uses HTTP Message Signatures2to digitally sign requests using its key, thereby proving Proof-of-Possession to present the access token to the Resource Server. |
||
Direct Messaging Services, Security Token Services, Technical Services, User Applications |
Candidate Service profile OAuth 2.0 HTTP Message Signatures Profile does not refer to any standard. |
Communications Transmission Standards Profiles
Wireless NB LOS Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
NATO Narrowband waveform for VHF/UHF Radios edition 1 The Narrowband Waveform (NBWF) provides ground–ground interoperability over air between troops/platforms of different nations at the tactical battlefield using the military VHF and UHF band (30 - 500 MHz). |
||
Wireless LOS Mobile Narrowband Transmission Services |
Candidate NBWF - HEAD STANAG Candidate NBWF - Physical Layer Candidate NBWF - Link Layer Candidate NBWF - Network Layer |
For FMN Spiral 5, NATO Narrowband Waveform Profile A shall be implemented according to Annex G of AComP 5630, i.e. one-hop voice and data wireless communication using PHY modes N1 and NR. Other PHY modes and profiles are optional. |
SATURN Waveform edition 4 A narrow-band waveform with Fast Frequency Hopping EPM Mode for UHF Radio. A/G/A use, typically used voice-only. |
||
Wireless LOS Mobile Narrowband Transmission Services |
Candidate SATURN - a fast frequency hopping EPM mode for UHF radio. AComP-4372 EDITION A |
A/G/A use, typically used voice-only. |
Wireless NB BLOS Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Digital Interoperability Between UHF Satellite Communications Terminals - Integrated Waveform (IWF) Phase 1 edition 1 This profile specifies the interoperability and performance characteristics of terminal equipment that will operate over NATO or national UHF satellite systems. |
||
Wireless BLOS Mobile Narrowband Transmission Services |
Candidate Digital Interoperability Between UHF Satellite Communications Terminals - Integrated Waveform (IWF). |
Wireless WB LOS Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
NATO HDRWF (ESSOR) Standards Profile edition 1 NATO HDRWF (ESSOR) is a wideband waveform standard originated from the EU ESSOR program and community. |
||
Wireless LOS Mobile Wideband Transmission Services |
Candidate These standards define NATO HDRWF based on ESSOR Standards. Candidate These standards define NATO HDRWF based on ESSOR Standards System Description
Candidate These standards define NATO HDRWF based on ESSOR Standards System Design Candidate These standards define NATO HDRWF based on ESSOR Standards Physical Layer Specifications Candidate These standards define NATO HDRWF based on ESSOR Standards MAC Layer Specifications
Candidate These standards define NATO HDRWF based on ESSOR Standards LLC Layer Specifications Candidate These standards define NATO HDRWF based on ESSOR Standards NET Layer Specifications
Candidate These standards define NATO HDRWF based on ESSOR Standards MGT Layer Specifications |
|
NATO High Capacity Data Rate Waveform (NHCDRWF) edition 1 Wideband UHF waveform |
||
Wireless LOS Mobile Wideband Transmission Services |
Candidate NHCDRWF - Head Specification Candidate NHCDRWF - Link/Network Layer Specification Candidate NHCDRWF - Modem Specification |