G.5. FMN Architecture

399. The Federated Mission Networking architecture is based on the concept of abstraction: hiding details of individual systems through encapsulation in order to better identify and sustain its properties. Individual system on each Mission Network Element will contain many levels of abstraction, each with its own architecture. The FMN architecture represents an abstraction of system behaviour at those interface levels that are essential for successful federated mission networking.

400. Service developers must assume network behaviour and performance consistent with the existing characteristics of deployed mission networks, taking bandwidth limitations, extended latency and potential unreliability into account, e.g. speed differentials between typical wired network and wireless wide area radio networks using

  • static line of sight radio or geostationary satellite circuits are ~500 up to 4000,

  • Tactical radio circuits are up to ~106.

Within the Federated Mission Network architecture, new services shall be designed around the Request/Response, Publish/Subscribe, or Message Queue patterns. IT capabilities used in a FMN context shall provide read or read/write services as appropriate, support dynamic bindings, and must include authentication as part of their service.

Sample FMN Information Environment
Figure G.1. Sample FMN Information Environment

401. The following FMN architecture principles have been developed:

  • Federation: A federated Mission Network (MN) is the episodic federation of autonomous mission network elements for the purpose of executing a mission.

  • Service Management and Control. A MN shall be governed and managed by a central Service Management Authority, to ensure:

    • assured delivery of services from providers/producers to consumers/customers based on well-defined SLAs, and

    • assured change and configuration management for federation related aspects.

  • Information Sharing: A MN shall enable information discovery and provide access to information relevant to the mission.

  • Shared Awareness: A MN shall provide the ability to end-users to gain a single view of the theatre of operations.

  • Data Management: A MN shall minimize the data management burden.

  • Security: A MN shall secure information against unauthorized access.

  • Mission Platform: A MN shall provide a reliable foundation for deploying applications and services as required by operational needs.

  • Elasticity: A MN shall provide the ability to add and remove Mission Network Contributing Participants, to scale-up or scale-down capacity and performance or increase, decrease support for operational footprints based on the mission life-cycle needs.

  • Robustness: Services that are deployed onto a MN shall be designed to deal with every conceivable error, no matter how unlikely[16].

  • Standards: Federated Technology components of the Mission Platform shall be conformant with agreed FMN interoperability standards.

  • Continual Improvement: Federated Mission Networking leverages existing technology investments to generate operational benefits.

  • Proven Technologies: A MN shall be based on proven technologies that are commonly available.

  • Reuse: A MN shall enable the sharing and re-using of services, common functions and systems between Mission Participants.

402. In addition, well defined Governance and Life-cycle management capabilities (including Service Management and Control) must be in place to ensure controlled management of capability enhancements for the generic FMN configuration templates as well as the in-service MNs and to ensure assured delivery of services from providers/producers to consumers/customers based on well-defined Service Level Agreements (SLAs).

403. Figure Figure G.1 above depicts a high level illustration of a future federated mission execution environment with three different options for participating in the Mission (Mission Network Element, Mission Network Extension and Hosted User).

404. This profile is primarily aimed to define interface standards for services provided by Mission Network Contributing Participants (Option A). Other mission participants (Option B and C) may (initially) not meet minimum service and service interoperability requirements. To allow participation in those cases, mission participants must establish a hosting agreement with a Mission Network Contributing Participant. Option B mission participants must provide their local area networks incl. IP management capability within the respective physical and cyber security boundaries of the host. Services must be able to function in a network environment containing firewalls and various routing and filtering schemes; therefore, developers must use standards and well-known ports wherever possible, and document non-standard configurations as part of their service interface.


[16] It is best to assume that the network is filled with malevolent entities that will send requests and response messages designed to have the worst possible effect. This assumption will lead to suitably protective design.