Extensions to MCEB Pub 7 Spectrum Frequency Action Format (SFAF)


SFAFx is a proposed open source extension and reference implementation to the MCEB Pub 7 Spectrum Frequency Action Format (SFAF). SFAFx resources are primarily targeted at acquiring, developing, deploying, and operating spectrum management and engineering services. Information relevant to stakeholders evaluating and eliciting system requirements as well as implementers of spectrum systems such as systems designers, software architects, and software engineers.

SFAFx is an evolving extension and tools driven by the need to provide quicker iterations of capability through an open collaborative community. There are a small but growing body of tools working with spectrum related data, and SFAFx is not intended to be a full working version of a specific system, but rather a set of tools supporting the interoperation between many systems and standards. SFAFx was initiated in 2015 as an extension to the SFAF open parser GitHub project which started in 2013. SFAFx initially will act as a hub for accessing relevant standards, open source projects, and references for all things SFAF or SSRF related.

SFAFx Methodology

Here we will lay out the general systems design approach for SFAFx. Understanding the SFAFx Semantic Precedence approach will better inform the SFAFx user of how and where SFAFx components or tools may be used. SFAFx semantic precedence methodology is Semantics over Convention over Configuration over Code (see CoC), which means that systems should designed with minimal or least coupling and system interfaces should work wherever and however possible and fail intelligently and in gradation rather than completely where system or semantic mismatches or formatting issues occur. In simplest terms, this is an elaboration of the design first, code last approach towards maximal code flexibility, extensibility, and reusability. So many new systems are being produced these days that it is difficult to determine if a system capability is already implement somewhere. Software components are not aware of what domain they are written for, and some components may be repurposed to do new things completely unlike the original intent of the component developer. Even wholly disparate components may be able to be repurposed into new systems to create new capabilities, through "renaming" or aliasing the component interfaces, if someone understood the deeper use of the component. M*A*S*H has a famous "repurposing" quote:

M*A*S*H "The Incubator"

Hawkeye: [regarding the requisition of the incubator being denied] We're not asking for a jukebox or a pizza oven.
Captain Sloan: Oh, those I can let you have.
Henry: No kidding! Hey, those would be great on movie nights. You got any pizza requisition forms?
Captain Sloan: Just use the standard S stroke 1798 and write in "Pizza" where it says "Machine Gun".

To support the interoperation of disparate systems and formats, SFAFx uses the methodology of Nomenclature → Dictionary → Taxonomy → Convention → Configuration → Components → Code. This is a semantic precedence hierarchy, such that the most preferred is nomenclature and the least preferred is coding. Coding (such as implementation in a Java) should be the last choice for realizing a capability. Because this is a semantic precedence, each level of abstraction should be able to reflect or introspect to discover the meaning of the lower precedence layers in a system. Practically speaking, this means each system boundary provides an interface to expose structure, classes, data dictionaries, programming interfaces, etc. The system semantic precedence methodology is generally ordered on least resource intensive to most resource intensive. This methodology encourages realizing capability through risk transference to other shared investments (such as open source, commercial, or government) and discourages coding until the value proposition is firmly known. This methodology is particularly useful for stakeholders that gain no intellectual property benefit from custom coded components, maximizes the stakeholders investment by minimizing investment in the highest cost center artifact (custom code).

System Semantic Precedence

  1. Nomenclature: patterns of naming should understandable even if specific names or identifiers are not.
  2. Dictionary: meanings of names should be generally known within a domain, even if all names are not.
  3. Taxonomy: relationships and specific use of a name, such semantics (Is-A, Has-A, Like-A) is generally known, even if not all structures are known.
  4. Convention: interfaces follow basic verbs and properties for interrogation and provide a means of exposing schema and/or taxonomy.
  5. Configuration: properties of systems should be configurable as much as possible.
  6. Components: system-of-systems configurable components approach, where new systems could be repurposed via configuration and component integration alone. In modern development, this generally means individual services are a light, configurable, and REST-based flexible web services wherever possible. (see microservcies)
  7. Code: compiled or interpreted computer language almost always partially or wholly created by a software developer. This is the most costly, longest lived, and most fixed system artifact. It is also the layer for the most powerful "verbs" of a system or the place where "things get done". Because this is the most resource intensive and highest technical risk artifact, all previous uses of the previous 6 elements on the Semantic Precedence ladder should be used first, and only code where configuration as failed to provide the needed capability.


There are multiple formats used in the spectrum community, such as SFAF, SSRF (v1.x, v2.x, v3.x), GMF, etc.

SFAF - Spectrum Frequency Action Format

Standard Frequency Action Format (SFAF) is used for the US Department of Defense (DoD) radio frequency proposals, assignments, modifications, renewals, reviews, and deletions. Frequency assignment proposals for space or earth stations may be made in either the International Telecommunication Union (ITU) Appendix 3 format or the SFAF.

SFAF is a line oriented text file format that requires a specific format parser instead of XML.

SSRF - Standard Spectrum Resource Format (XML)

SSRF defines standard data elements for automated exchange of radio-frequency (RF) spectrum-related data. Basic spectrum management transactions supported by this standard include:

  1. RF equipment and antenna parameters
  2. Spectrum supportability requests and associated host nation replies
  3. Temporary and permanent frequency proposals and assignments
  4. Frequency allotments
  5. Joint Restricted Frequency Lists (JRFL)
  6. Interference reports

Electronic Warfare and JCEOI transactions will be included in future releases.

Authority: The SSRF standards document is issued under the authority of DOD Directive 5100.35, Military Communications- Electronics Board (MCEB) with changes thereto.


The SFAFx extensions are a set of parsers and web tools written in JavaScript to support the decoding, analysis, engineering, visualization, compliance checking, and systems integration of spectrum frequency information through a JavaScript Object Notation (JSON) format specification and common dictionary.


Compliance checking support the verification and validation of proposed and existing spectrum assignments.


Electromagnetic propagation analysis is key to understanding the effects of RF transmission. SFAFx proposes the integration of several elements to support the use and standardization of EM engineering and GIS services.

Tools & Projects

Spectrum XXI


SFAF.js composed of several reference implementation tools for developing and testing web-centric systems.

SFAF Python



SFAFx Demonstration

The tools SFAFx tools are used in the SFAFx demonstration web application project. The SFAFx demonstration website requires prior authorization by email address, and can authenticate via Google or Amazon.

SFAFx JSON Formatter

There is an online JSON SFAFx parser available at the SFAFxJS Online Parser.

The sfafx.js parser is a bower component than can easily be installed via bower install sfafxjs


SFAFx tools, documentation, and demonstration web application are managed or developed by Eric Lindahl at Sciumo Inc.