MORA_Specification_V2.4_20210301_Final_DIST_A A519.pdf

MODULAR OPEN RF ARCHITECTURE

(MORA)

DRAFT SPECIFICATION DOCUMENT

VERSION 2.4

MARCH 01, 2021

DISTRIBUTION STATEMENT A. Approved for public release. Distribution is unlimited.

MORA Specification Document Version 2.4 March 01, 2021

TABLE OF CONTENTS

1 INTRODUCTION

1.1 Objectives

1.2 Motivations for a Modular Open RF Architecture

1.3 Approach

1.4 Scope

1.5 Maturity Levels

1.6 Document Conventions

1.6.1 Specification Tags

1.6.2 Standards Key Words

1.6.3 MORA Definitions

1.7 Compliance Statement

2 REFERENCED DOCUMENTS

3 ABBREVIATIONS, ACRONYMS, AND DEFINITIONS

3.1 ABBREVIATIONS AND ACRONYMS

3.2 MORA Definitions Table

4 ARCHITECTURE

4.1 VICTORY Overview

4.2 MORA Overview

4.3 MORA Top-Down Perspective

4.3.1 MORA Signal Resource

4.3.2 MORA Processing Resource

4.3.3 MORA Transitional Implementation

4.4 MORA Functional Perspective

4.4.1 Antenna (ANT) Signal Resource

4.4.2 RF Conditioning (RFC) Signal Resource

4.4.3 RF Distribution (RFD) Signal Resource

4.4.4 RF Translation (RFT) Signal Resource

4.4.5 Signal Domain Conversion (SDC) Signal Resource

4.5 MORA Devices

4.5.1 MORA Radiohead (RHD) Device

4.5.2 MORA RF Conditioning and Distribution (RCD) Device

4.5.3 MORA Software Defined Radio (SDR) Device

4.6 MORA Resource Management

4.6.1 Resource Management Objectives

4.6.2 Resource Management Methodology

4.6.3 Signal Resource Partitioning

4.6.4 Processing Resource Partitioning

4.6.5 Resource Capabilities and Tasking

4.7 MORA Basic System Composition

5 SPECIFICATIONS

5.1 VICTORY Specifications

5.1.1 VICTORY Data Bus

5.1.2 VICTORY Component Types

5.2 MORA Low Latency Bus

5.2.1 MORA Low Latency Bus Specifications

5.3 MORA Component Types

5.3.1 Low Latency Switch <MT91010-V2.4>

5.3.2 MORA Device <MT92010-V2.4>

5.3.3 MORA Signal Resource Manager <MT92013-V2.4>

5.3.4 MORA Signal Port Manager <MT92016-V2.4>

5.3.5 Complex Type Definitions

5.4 Syslog Protocol Data Parameters for MORA <49101-20200707, Pro>

5.5 Version Information Management Parameters for MORA <49102-20210301, Pro>

5.6 MORA Schemas and WSDLs <49103-20201002, Pro>

6 MORA DATA MESSAGING

6.1 MDM Protocol Specifications <MT96001-V2.4>

6.1.1 MDM Data Encoding Specification <48605-20160131, Exp>

6.1.2 MDM Encapsulation Specification <48606-20201002, Exp>

6.2 MDM Networking Specifications <MT96002-V2.4>

6.3 MDM Types

6.3.1 MDM VITA Radio Transport (VRT) (Type 1) Specifications

6.3.2 MDM Acknowledgement Message (Type 2) Specification <48611-20180928, Exp>

6.3.3 MDM Time of Day Message (Type 3) Specification <48612-20170531, Exp>

6.3.4 MDM Signal Port User ID Message (Type 4) Specification <48613-20201002, Exp>

6.3.5 MDM Health Message (Type 5) Specification <48614-20200707, Exp>

6.3.6 MDM Command Message (Type 6) Specification <48615-20200707, Exp>

6.3.7 MDM Switch Group User ID Message (Type 7) Specification <48617-20200707, Exp>

7 MORA SYSTEM REFERENCE DESIGN

7.1 Overview

7.2 Common Hardware for Multiple Missions

7.3 MORA System Sequence Diagrams

7.3.1 Component Discovery

7.3.2 Discovering Available Web Service Interfaces on VICTORY Data Bus

7.3.3 Retrieving Device Level Information

7.3.4 Retrieving Signal Resource Capability

7.3.5 Signal Port Reservation and Release

7.4 Improved Survivability

7.4.1 Example Transmit or Receive System

7.4.2 Radiohead Failover

7.4.3 SDR Failover

7.5 Improved Performance

7.5.1 Transmit Diversity

7.5.2 Switch Group With Transmit Diversity

APPENDIX A: MORA ZEROCONF ANNOUNCEMENT STRINGS

APPENDIX B: MORA WSDLS

APPENDIX C: MORA SCHEMAS

APPENDIX D: RESOURCE MANAGEMENT EXAMPLE

APPENDIX E: MULTIPLE SECURITY DOMAINS Distribution C - Provided Separately

APPENDIX F: RADIOHEAD REFERENCE DESIGN Distribution C - Provided Separately

APPENDIX G: MORA SOFTWARE MAP EXAMPLE Distribution C - Provided Separately

LIST OF TABLES

Table 1 Specification Tag Groups Table 2 Abbreviations and Acronyms Table 3 MORA Definitions Table 4 Recommended VDB Traffic Marking Table 5 Minimum Recommended VICTORY Component Types Table 6 MDM Traffic Marking Table 7 Low Latency Switch <MT91010-V2.4> Table 8 Low Latency Switch Data Interface <MT91011-V2.4> Table 9 Low Latency Switch Data Interface Physical and Data-Link Layer Specifications <MT91012-V2.4> Table 10 Low Latency Copper Data Physical and Data-Link Layer Specifications <MT91013-V2.4> Table 11 Low Latency Fiber Data Physical and Data-Link Layer Specifications <MT91014-V2.1> Table 12 MORA Device <MT92010-V2.4> Table 13 MORA Device Management Interface <MT92011-V2.4> Table 14 MORA Device Operations Interface <MT90016-V2.4> Table 15 MORA Signal Resource Manager <MT92013-V2.4> Table 16 MORA Signal Resource Management Interface <MT92014-V2.4> Table 17 MORA Signal Resource Manager Operations Interface <MT90017-V2.4> Table 18 MORA Signal Port Manager <MT92016-V2.4> Table 19 RF Layer Analog Data Interface <MT90011-V2.1> Table 20 RF Layer Command Interface <MT90012-V2.4> Table 21 RF Layer Context Interface <MT90013-V2.4> Table 22 RF Layer Digital Data Interface <MT90014-V2.4> Table 23 RF Layer Operations Interface <MT90015-V2.4> Table 24 MORA Management Interface Types Table 25 MORA SOAP Component Types Table 26 MDM Protocol Specifications <MT96001-V2.4> Table 27 MDM Layout Table 28 MDM Header Format Table 29 ML2B Interface ID Format Table 30 MDM Types Table 31 MDM Networking Specifications <MT96002-V2.4> Table 32 MDM VRT Message Format Table 33 VRT Packet Header Field Table 34 VRT Packet Types Table 35 TSI Code Types Table 36 TSF Code Types Table 37 Timestamp Meaning by Packet Type/Sub Type/Variant Table 38 MORA Stream ID Format Table 39 Stream ID Bit Field Table 40 ID-Device Types Table 41 VRT Class ID Format Table 42 Information Class Code Subfields Table 43 Packet Class Code Subfields Table 44 VITA 49.2 Context/Command Indicator Field (CIF) Matrix and Bit Assignments Table 45 MORA Reference Point Identifier Field Table 46 State/Event Indicators Field Table 47 State/Event Indicator Field Enable and Indicator Bits Table 48 Signal Payload Packet Data Format Field Table 49 Real/Complex Subfield

Table 50 Data Item Format Subfield Table 51 MORA Discrete I/O 32-Bit Field Format Table 52 Coherency Modes Table 53 Test Source Waveforms Table 54 Test Source Delivery Methods Table 55 RF Modes Table 56 MORA Discrete I/O 64-Bit Field Format Table 57 Filter Selection Table 58 Switch Group ID Table 59 Switch State ID Table 60 Buffer Status Field Table 61 Status Subfield Table 62 Signal Data Packet Header Table 63 VRT Trailer Format Table 64 Trailer Enable and Indicator Bits Table 65 Context Packet Header Table 66 MORA Context Fields Matrix Table 67 Command Packet Header Table 68 Control/Acknowledge Mode (CAM) Field for Control Packets Table 69 Control/Acknowledge Mode (CAM) Field for Acknowledge Packets Table 70 Control/Acknowledge Mode (CAM) Field for Control Cancellation Packets Table 71 MORA Control Fields Matrix Table 72 MDM Acknowledgement Message Format Table 73 MDM Acknowledgement Message Response Bit Field Table 74 MDM Acknowledgement Response Meaning Table 75 MDM Time of Day Message Format Table 76 MDM Time of Day Field Table 77 MDM Signal Port User ID Message Format Table 78 Signal Port User ID Field Format Table 79 Signal Port Resource ID and User ID Bit Fields Table 80 MDM Health Message Format Table 81 MDM Command Message Format Table 82 MDM Switch Group User ID Message Format Table 83 Switch Group User ID Field Format Table 84 Switch Group Resource ID Bit Field Table 85 User ID Bit Field Table 86 MORA Zeroconf Announcement Strings Table 87 Recommended VICTORY Zeroconf Announcements for Consumption Table 88 Announcement String TXT Field Descriptions Table 89 MORA WSDLs Table 90 Inherited VICTORY WSDLs Table 91 MORA Schemas Table 92 Inherited VICTORY Schemas

LIST OF FIGURES

Figure 1 VICTORY Component Types Figure 2 MORA Specific Component Types Figure 3 MORA Architecture Figure 4 MORA Top-Down Perspective Figure 5 MORA Transitional RF System Top-Down Perspective Figure 6 MORA Functional Perspective Figure 7 MORA Device Type Resource Functionality Figure 8 MORA Processing Resource Blocks Figure 9 MORA Direction Finding Engine Processing Port Figure 10 MORA Resource Management Process Figure 11 MORA Basic System Composition Figure 12 Implementation of Component Types within a MORA Device for Signal Resources Figure 13 Alternate Proxy Implementation of Signal Resources Figure 14 VRT Message Structure Figure 15 VRT Prologue Structure Figure 16 MORA Mapping of Switch Groups and States Example Figure 17 Signal Data Packet Format Figure 18 Context Packet Format Figure 19 MORA Command Packet Taxonomy Figure 20 Command Packet Format Figure 21 MORA Acknowledge Packet Variants in Response to Control Packets Figure 22 MORA Acknowledge Packet Variants in Response to Control Cancellation Packets Figure 23 Health Status Field #1 Format Figure 24 Health Status Field #2 Format Figure 25 Command Field Format Figure 26 Configuration Field Format Figure 27 Waveform Operation Field Format Figure 28 MORA Reference Design Figure 29 Component Discovery Figure 30 Version Information Web Service Example Figure 31 Retrieving Device Level Information Figure 32 Retrieving Signal Port Capability Figure 33 Signal Port Reservation and Release Figure 34 MORA Transmit or Receive Figure 35 Common Hardware for Multiple Missions Figure 36 Radiohead Failover Figure 37 SDR Failover Figure 38 Transmit Diversity Figure 39 Switch Control with Transmit Diversity Figure 40 Two Application MORA Resource Management Example

1 INTRODUCTION

1.1 Objectives

The objective of this document is to identify and describe the architecture and specifications associated with I2WD’s

Modular Open RF Architecture (MORA).

MORA is an extension to the Vehicular Integration for C4ISR/EW Interoperability (VICTORY) Architecture [1], which is an Open System Architecture (OSA) for integrating electronics onto military platforms. VICTORY is developed and maintained by the U.S. Army VICTORY Standards Support Office (VSSO), an organization hosted by the U.S. Army

Program Executive Office for Ground Combat Systems (PEO-GCS), and governed by an Executive Steering Group (ESG) made up of leadership of the PEOs within the Assistant Secretary of the Army (Acquisition, Logistics, and Technology)

(ASA(ALT)). MORA is currently being developed and maintained by the U.S. Army Command, Control, Computers, Communications, Cyber, Intelligence, Surveillance and Reconnaissance Center (C5ISR Center) Intelligence and

Information Warfare Directorate (I2WD).

This document is intended for material developers and system integrators who seek to leverage open architectures to implement multifunction radio frequency (RF) capabilities on tactical platforms and to provide a framework to guide the implementation of MORA interface specifications.

1.2 Motivations for a Modular Open RF Architecture

RF products spanning multiple functions have become increasingly critical to the warfighter. Military use of the electromagnetic spectrum now includes communications, EW, intelligence, and mission command systems. Due to the urgent needs of counterinsurgency operations, various quick reaction capabilities (QRCs) have been fielded to enhance warfighter capability. Although these QRCs were highly successful in their respective missions, they were designed independently, resulting in significant challenges when integrated on a common platform. Current RF system implementations are typically single-mission focused with closed or proprietary interfaces between stove-piped resources.

Specific limitations of this legacy stove-piped approach include the following:

• Inordinate consumption of size, weight, and power (SWaP) due to duplicated hardware such as tuners, power amplifiers, antennas, processors, displays, and user interface devices.

• Independent concurrent operation with overlapping frequency bands resulting in RF spectral conflict and mutually-degraded effectiveness.

• Closed systems and interfaces creating vendor lock-in and reduced competition for maintenance, upgrades, and user training.

• Inability to perform rapid technology insertion to address emerging threats and keep pace with commercial technology.

• Preclusion of multifunctional/multi-nodal techniques and data sharing (e.g., situational awareness (SA)).

1.3 Approach

MORA addresses these limitations by defining an open architecture for multifunction missions that decomposes monolithic radio systems into high-level components with well-defined functions and interfaces. Instead of developing a new open architecture from the ground-up, MORA is an extension to the scope of the open architecture defined by

VICTORY. To avoid redundancy, the reader should review the portions of the Vehicular Integration for C4ISR/EW

Interoperability (VICTORY) Architecture [1] and Vehicular Integration for C4ISR/EW Interoperability (VICTORY)

Standard Specifications [2] documents that are referenced within this MORA specification.

VICTORY defines an Ethernet-based network architecture for integrating electronic systems within military platforms, as well as interface specifications for sharing sensor and data products, managing configuration, states, modes, and health of the infrastructure and applications, transporting data with quality of service (QoS), and implementing necessary information assurance (IA) controls to protect the system and its data from cyber threats. VICTORY can support the non-time critical messaging and management of RF systems, which include setup, tasking, and monitoring of RF processing chains, and transport of lower-volume processed data messages. Extensions to VICTORY are required to support transport of large-volume signal data streams and to standardize the access and low latency control of the RF chain.

MORA extends the scope of VICTORY by adding a low latency transport mechanism, data streaming interfaces, new message types, management operations, and functional concepts that are specific to RF applications. Examples of RF applications include voice communications, data communications, and EW.

The MORA functional decomposition maximizes hardware sharing while minimizing added complexity and cost due to modularization. Existing software defined radio (SDR) architectures concentrate on modularizing the digital signal processing and application functions of radio applications. MORA achieves significant SWaP savings by allowing power amplifiers (PAs) and antennas, some of the biggest consumers of SWaP on the platform, to be shared across systems.

MORA separates the signal resources from processing resources that implement the actual radio application, exposing points in the architecture that were not previously accessible. This provides system integrators with the flexibility to insert best-of-breed third-party capabilities into the processing chain to address technical challenges and emerging requirements.

Modularizing components such as PAs, which require greater heat dissipation, allows system integrators to place them in more ideal locations with better cooling and airflow, such as outside the platform. These semi-perishable components are decoupled from more sensitive and expensive components, which are still located inside the platform. Co-locating PAs and antennas further reduces power consumption by minimizing the length of high-power cable runs and associated cable loss. Overall system efficiency and performance is thereby improved by requiring less power to achieve the same over-the-air (OTA) effects. Routing low power RF signals between components within the platform enables hot switching at rapid speeds, which is required for time switched sharing of PAs and antennas. Resulting capabilities include transmit diversity, which mitigates multipath interference by transmitting the same signal from two or more antennas. Although this is not a new technique, it is now possible without additional SWaP as systems can share the same antennas.

By divorcing specific capabilities (i.e., radio applications) from the hardware they run on, MORA makes hardware a commodity that can be dynamically configured based on mission objectives. Because most RF applications have the same underlying hardware requirements, a radio’s personality can be changed simply by provisioning it with new software.

Although the concept of an SDR is not unique to MORA, the standardized interfaces that MORA defines enable monitoring and management of SDRs via common user interfaces and platform automation. Use of common hardware allows system integrators to establish pooled resources that provide varied levels of availability. A dedicated spare can be included that provides 1xN redundancy to tolerate the failure of a single component without any loss of capability. On platforms where redundancy is not an option, MORA allows the warfighter to select which capability is lost by preempting a lower priority mission. As an example, the warfighter may choose to repurpose an SDR currently performing a communications mission to restore a higher priority EW mission.

1.4 Scope

MORA is not a material solution, but rather an architecture and a set of open interface standards that defines an RF functional decomposition and associated interfaces. MORA open interface standards promote modularity, compatibility, interoperability, and portability of capabilities while allowing proprietary hardware, software, and algorithms to be utilized. MORA interfaces will manifest in mission solutions once the acquisition community references the MORA specification in future procurements while industry incorporates MORA into their product offerings. It is incumbent on the system integrator to leverage MORA, as appropriate, to address today’s size, weight, and power - cost (SWaP-C) requirements while still maintaining sufficient flexibility to address tomorrow’s technical challenges.

1.5 Maturity Levels

The “Maturity Level” is used to describe the maturity level of a specification and is designated using one of the following abbreviations:

• Pre - Preliminary

• Inf - Informational

• Exp - Experimental

• Pro - Proposed Standard

• Dft - Draft Standard

• Std - MORA Standard

The meanings and definitions of these terms are given in and governed in Section ”Maturity Levels” of the Vehicular

Integration for C4ISR/EW Interoperability (VICTORY) Standard Specifications [2]. Those meanings/definitions are, in turn, based on Internet Engineering Task Force (IETF) Request for Comment (RFC) 2026: The Internet Standards Process

[3].

1.6 Document Conventions

The conventions and terms used in this document are consistent with, and governed by, Section “Document Conventions” of the VICTORY Standard Specifications document. MORA utilizes VICTORY specification tags and key word conventions. For ease of reference, the portions of the VICTORY document on “specification tag”, “VICTORY Type

Tag”, and “Standards Key Words” are repeated in this section.

1.6.1 Specification Tags

Specification tags are used to track individual specifications in a manner that is independent of the organization of the document. A specification tag is defined as follows:

<Spec ID-Date of Publication, Maturity Level>

The “Spec ID” is a 5-digit identification number with a range of 00000-99999. Spec ID shall be unique within the

VICTORY specifications. This number is comprised of two parts: a 2-digit specification group followed by a 3-digit identifier. Each specification group may have identifiers ranging from 001 to 999, excluding 000. Table 1 below provides the list of possible specification groups.

Table 1 Specification Tag Groups

The “Date of Publication” is the date of the last update of the specification.

The VICTORY Type (VT) Tag is an alphanumeric identification tag with a prefix of “VT”, followed by a numeric range of 50000-89999, and ending in the version number of the applicable VICTORY Specification document. These tags are used to identify tables - system, component, and/or interface type tables - which contain applicable specification titles and associated spec tags, and/or other VT titles/tags to identify other applicable specifications.

<VT12345-V1.5>

Similarly, a MORA Type (MT) Tag is used in this document and is directly analogous to the previously described VT

Tag, with the exceptions of leading with “MT” vice “VT”, and the trailing version number refers to the applicable MORA

Specification document. MT Tags have a numeric range of 90000-99999.

1.6.2 Standards Key Words

In this document, key words are used to signify the requirements in the standards. This section defines these words (derived from IETF RFC 2119) as they should be interpreted in the VICTORY specification. Note that the force of these words is modified by the requirement level of the specification in which they are used.

SHALL: This word means that the definition is an absolute requirement of the specification.

Specification Group Group Identifier

Unused 00

Data Transport Interfaces 01

Time Synchronization Interfaces 02

Non-Networked Nodes Interfaces 05

Common Management Parameters 10

VDB Management Interfaces 11

Infrastructure Node Management Interfaces 12

End Node Management Interface 13

Information Assurance Management Interfaces 14

C4ISR/EW Application Management Interfaces 15

Platform Systems Management Interfaces 16

Application Data Interfaces 20

VICTORY Configuration Language 30

Access Control Interfaces 40

MORA RF Interfaces 47

MORA Low Latency Bus 48

MORA Management Interfaces 49

SHALL NOT: This phrase means that the definition is an absolute prohibition of the specification.

SHOULD: This word means that there may exist valid reasons, in particular circumstances, to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

SHOULD NOT: This phrase means that there may exist valid reasons, in particular circumstances, when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

MAY: This word means that an item is truly optional. One implementation may choose to include the item because a particular marketplace requires it, or because the implementation enhances the product, while another implementation may omit the same item. An implementation that does not include a particular option SHALL be prepared to interoperate with another implementation that does include the option, though perhaps with reduced functionality. In the same vein, an implementation that does include a particular option SHALL be prepared to interoperate with another implementation that does not include the option (except, of course, for the feature the option provides).

1.6.3 MORA Definitions

Key MORA terms are formally defined for clarity in section titled “MORA Definitions Table.”

1.7 Compliance Statement

There is no concept of overall MORA compliance. MORA defines a collection of open interface standards. Compliance is specified, implemented, claimed, tested, and documented based on the open interface standards that are relevant for the specific device or system in question.

2 REFERENCED DOCUMENTS

The documents directly referenced herein are enumerated as follows.

[1] Vehicular Integration for C4ISR/EW Interoperability (VICTORY) Architecture, Version: A4.

[2] Vehicular Integration for C4ISR/EW Interoperability (VICTORY) Standard Specifications, Version 1.9.

[3] Internet Engineering Task Force (IETF) Request for Comment (RFC) 2026: The Internet Standards Process -

Revision 3.

[4] Internet Engineering Task Force (IETF) Request for Comment (RFC) 768: User Datagram Protocol (UDP).

[5] Internet Engineering Task Force (IETF) Request for Comment (RFC) 791: Internet Protocol.

[6] Internet Engineering Task Force (IETF) Request for Comment (RFC) 2236: Internet Group Management

Protocol, Version 2.

[7] Internet Engineering Task Force (IETF) Request for Comment (RFC) 4541: Considerations for Internet Group

Management Protocol (IGMP) and Multicast Listener Delivery (MLD) Snooping Switches.

[8] ANSI/VITA 49.2-2017 VITA Radio Transport (VRT) Standard for Electromagnetic Spectrum: Signals and

Applications, Revision 00.55 (VITA ballot approved/ANSI ballot in process).

[9] MIL-STD-1275E, DoD INTERFACE STANDARD: Characteristics of 28 Volt DC Electrical Systems in Military

Vehicles, 22 March 2013.

[10] “IEEE Standard for Ethernet” in IEEE Std 802.3-2018 (Revision of IEEE Std 802.3-2015), vol., no., pp.1-5600, 31 Aug. 2018, doi: 10.1109/IEEESTD.2018.8457469

3 ABBREVIATIONS, ACRONYMS, AND DEFINITIONS

3.1 ABBREVIATIONS AND ACRONYMS

Table 2 Abbreviations and Acronyms

Abbreviation/Acronym Definition

ACK Acknowledge

ADC Analog to Digital Converter

AMM Aperture Manifold Management

ANSI American National Standards Institute

ANT Antenna

APG Aberdeen Proving Ground

API Application Programming Interface

ARI Analog Reference Input

ARO Analog Reference Output

ARX Analog Receive

ASCII American Standard Code for Information Interchange

ATR Analog Transmit and/or Receive

ATX Analog Transmit

BBS Baseband Sample

BMC Baseband Multi-Channel

BSC Baseband Single-Channel

C4ISR/EW Command, Control, Communications, Computers, Intelligence, Surveillance, Reconnaissance/Electronic

Warfare

C5ISR Center Command, Control, Computers, Communications, Cyber, Intelligence, Surveillance and Reconnaissance

Center

CAM Control/Acknowledge Mode

CIF Context/Command Indicator Field

CLK Clock

COMP Component

COUNT Context Packet Count

CPU Central Processing Unit

DAC Digital to Analog Converter dB Decibel dBc Decibels Relative to the Carrier dBi Decibels Relative to an Isotropic Radiator dBm Decibel-milliwatt

DDC Digital Down Converter

DF Direction Finding

Abbreviation/Acronym Definition

DFE Direction Finding Engine

DFIB Discrete Field Indicator Bits

DNS Domain Name System

DoD Department of Defense

DRI Digital Reference Input

DRO Digital Reference Output

DRX Digital Receive

DSCP Differentiated Services Code Point

DSP Digital Signal Processor

DTR Digital Transmit and/or Receive

DTX Digital Transmit

DUC Digital Up Converter

EC Error Code

EIF Error Indicator Field

ES Electronic Support

EW Electronic Warfare

EWFS Error/Warning Fields

Exp Experimental

FFT Fast Fourier Transform

FPGA Field-Programmable Gate Array

Gb Gigabyte

GbE Gigabit Ethernet

GPP General Purpose Processor

GPS Global Positioning System

GPU Graphics Processing Unit

HMI Human Machine Interface

HPA High Power Amplifier

Hz Hertz

IA Information Assurance

IANA Internet Assigned Numbers Authority

ID Identification/Identifier

IEEE Institute of Electrical and Electronic Engineers

IETF Internet Engineering Task Force

IF Intermediate Frequency

IFS IF Sample

IGMP Internet Group Management Protocol

IMC Intermediate Frequency Multi-Channel

IP Internet Protocol

IPSIZE Item Packing Field Size

IQ In-phase and Quadrature

ISC IF Single-Channel

I2WD Intelligence and Information Warfare Directorate

LAN Local Area Network

LNA Low Noise Amplifier

LOB Line of Bearing

MAC Media Access Control

MAC Message Authentication Code

MDM MORA Data Message

MIL STD Military Standard

ML2B MORA Low Latency Bus

MORA Modular Open RF Architecture

MT MORA Type

MUI ML2B Unique Identifier

OA&M Operations, Administration, and Maintenance

OSA Open System Architecture

OSC Oscillator

OTA Over-The-Air

OTH Other (MORA Device Type)

PA Power Amplifier

PARMS Parameters

PNT Position, Navigation, and Timing

QoS Quality of Service

QRC Quick Reaction Capability

RAM Random Access Memory

RC Real or Complex

RF Radio Frequency

RFC RF Conditioning

RCD RF Conditioning and Distribution

RFD RF Distribution

RFS RF Sample

RFT RF Translation

RHD Radiohead

RMC Radio Frequency Multi-Channel

RMON Remote Network Monitoring

RSC Radio Frequency Single-Channel

RSS RF Spectrum Sensor

RX Receive

RXO Receive Only

SDC Signal Domain Conversion

SDR Software Defined Radio

SNMP Simple Network Management Protocol

SOAP Simple Object Access Protocol

SPM Signal Port Manager

SPU Shared Processing Unit

S&E State and Event

SWaP Size, Weight, and Power

SWaP-C Size, Weight, and Power - Cost

TAR Transmit and Receive

TBD To Be Determined

TLS Transport Layer Security

TOR Transmit or Receive

TSF Timestamp Fractional

TSI Timestamp Integer

TX Transmit

TXO Transmit Only

UDP User Datagram Protocol

UUID Universally Unique Identifier

UTC Coordinated Universal Time

VDB VICTORY Data Bus

VDC Volt Direct Current

VDM VICTORY Data Message

VICTORY Vehicular Integration for (C4ISR) Command, Control, Communication, Computers, Intelligence, Surveillance, Reconnaissance /(EW) Electronic

Warfare (EW) Interoperability

VITA VMEbus International Trade Association

VLAN Virtual Local Area Networks

VMEbus Versa Module Europa bus

VRT VITA Radio Transport

WSDL Web Service Description Language

VT VICTORY Type

XML eXtensible Markup Language

Zeroconf Zero Configuration Networking

3.2 MORA Definitions Table

Table 3 MORA Definitions

MORA Device

An entity within a MORA system that contains signal resources and/or processing resources in support of receive and/or transmit operations. MORA Device types include: Radiohead (RHD), RF

Conditioning & Distribution (RCD), and Software Defined Radio (SDR). MORA Device subtypes include: Receive Only (RXO), Transmit Only (TXO), Transmit or Receive (TOR), and Transmit and Receive (TAR).

MORA Device Types

Radiohead

(RHD)

Device

A MORA Device that contains ANT signal resources, may contain

RFC, RFD, RFT, and/or SDC signal resources, and may contain processing resources in support of receive and/or transmit operations.

RF Conditioning and

Distribution

(RCD)

Device

A MORA Device that may contain RFC, RFD, RFT, and/or SDC signal resources and may contain processing resources in support of receive and/or transmit operations.

Software Defined

Radio

(SDR)

Device

A MORA Device that contains processing resources, and may contain

RFC, RFD, RFT, and/or SDC signal resources in support of receive and/or transmit operations.

MORA Device Sub

Types

Receive Only

(RXO) Device Sub

Type

A MORA Device within a MORA system that contains signal resources and/or processing resources in support of receive operations.

Transmit Only

(TXO) Device Sub

Type

A MORA Device within a MORA system that contains signal resources and/or processing resources in support of transmit operations.

Transmit or Receive

(TOR)

Device Sub Type

A MORA Device within a MORA system that contains signal resources and/or processing resources in support of either transmit or receive operations.

Transmit and Receive

(TAR)

Device Sub Type

A MORA Device within a MORA system that contains signal resources and/or processing resources in support of simultaneous transmit and receive operations.

MORA Signal

Resource

A resource within a MORA Device that captures, radiates, conditions, distributes, translates, and/or converts RF signals in support of receive and/or transmit operations in a MORA system. Signal

Resource types include: Antenna (ANT), RF Conditioning (RFC), RF Distribution (RFD), RF

Frequency Translation (RFT), and Signal Domain Conversion (SDC).

MORA Signal

Resource Types

Antenna

(ANT)

Resource Type

A resource within a MORA Device that captures or radiates electromagnetic energy in support of receive and/or transmit operations.

An example of an ANT resource is an antenna or an antenna array.

RF Conditioning

(RFC)

Resource Type

A resource within a MORA Device that conditions conducted RF signals in support of receive and/or transmit operations. Examples of

RFC resources include low noise amplifiers (LNAs), filters (i.e., low pass, high pass, band pass, and band reject), and high power amplifiers

(HPAs).

RF Distribution

(RFD)

Resource Type

A resource within a MORA Device that distributes conducted RF signals in support of receive and/or transmit operations. Examples of

RFD resources include power dividers, power combiners, and RF switches.

RF Frequency

Translation (RFT)

Resource Type

A resource within a MORA Device that frequency translates conducted

RF signals in support of receive and/or transmit operations. Examples of RFT analog domain resources include mixers and local oscillators, RF tuners, frequency upconverters, and frequency downconverters.

Examples of RFT digital domain resources include digital down converters (DDCs) and digital up converters (DUCs).

Signal Domain

Conversion (SDC)

Resource Type

A resource within a MORA Device that converts the domain (analog

vs. digital) of conducted RF signals in support of receive and/or transmit operations. Examples of SDC resources include analog to digital converters (ADCs) and digital to analog converters (DACs).

MORA Signal Port

A logical partition of signal resources with an external access point on a MORA Device in support of receive and/or transmit operations in an RF system. A MORA Signal Port consists of analog (radio frequency, intermediate frequency, or baseband) or digital (real or complex IQ in time or frequency domains) signals transported between devices in coaxial, copper wire, or fiber optic interconnect cables. MORA Signal Port classes include the Analog Signal, Digital Signal and Reference Signal classes.

MORA Signal Port

Class

Analog Signal Port

Class

A MORA Signal Port operating within the receive and/or transmit chain containing an analog representation, in the time domain, of radio frequency, intermediate frequency, or baseband signals transported between MORA Devices on coaxial or fiber optic interconnect cables.

The Analog Signal Port Class includes the following signal port types:

Analog Receive (ARX), Analog Transmit (ATX), and Analog

Transmit and/or Receive (ATR).

MORA Analog

Signal Port Types

Analog Receive (ARX)

Signal Port

A unidirectional signal port operating within the system’s receive chain containing an analog representation, in the time domain, of radio frequency, intermediate frequency, or baseband signals transported between MORA Devices on coaxial or fiber optic interconnect cables.

Analog Transmit

(ATX) Signal Port

A unidirectional signal port operating within the system’s transmit chain containing an analog representation, in the time domain, of radio frequency, intermediate frequency, or baseband signals transported between MORA Devices on coaxial or fiber optic interconnect cables.

Analog Transmit and/or Receive

(ATR) Signal Port

A bi-directional, half or full duplex signal port operating within the system’s receive and/or transmit chain containing an analog representation, in the time domain, of radio frequency, intermediate frequency, or baseband signals transported between MORA Devices on coaxial or fiber optic interconnect cables.

MORA Analog

Signal Port Sub

Types

ARX/ATX/ATR

Signal Port Sub Types

ARX, ATX, and ATR signal port subtypes include: RF Single-

Channel (RSC), IF Single-Channel (ISC), and Baseband Single-

Channel (BSC).

MORA Signal Port

Class

Digital Signal Port

Class

A MORA Signal Port operating within the receive and/or transmit chain containing a digital representation of radio frequency, intermediate frequency, or baseband signals transported between devices on coaxial or fiber optic interconnect cables. The Digital

Signal Port Class includes the following signal port types: Digital

Receive (DRX), Digital Transmit (DTX), and Digital Transmit or

Receive (DTR).

MORA Digital

Signal Port Types

Digital Receive

(DRX)

Signal Port

A unidirectional signal port operating within the system’s receive chain containing a digital representation, in the time or frequency domain, of radio frequency, intermediate frequency, or baseband signals transported between devices on coaxial or fiber optic interconnect cables.

Digital Transmit

(DTX)

Signal Port

A unidirectional signal port operating within the system’s transmit chain containing a digital representation, in the time or frequency domain, of radio frequency, intermediate frequency, or baseband signals transported between devices on coaxial or fiber optic interconnect cables.

Digital Transmit and/or Receive (DTR)

Signal Port

A bi-directional, half or full duplex signal port operating within the system’s receive and/or transmit chain containing a digital representation, in the time or frequency domain, of radio frequency, intermediate frequency, or baseband signals transported between devices on coaxial or fiber optic interconnect cables.

MORA Digital

Signal Port Sub

Types

DRX/DTX/DTR Sub

Types

DRX, DTX, and DTR signal port sub types include: RF Single-

Channel (RSC), RF Multi-Channel (RMC), IF Single-Channel (ISC), IF Multi-Channel (IMC), Baseband Single-Channel (BSC), and

Baseband Multi-Channel (BMC).

MORA Signal Port

Class

Reference Signal Port

Class

A MORA Signal Port that supports the MORA system containing an analog or digital representation of reference signals transported between devices on coaxial or fiber optic interconnect cables. The Reference

Signal Port Class includes the following signal port types: Analog

Reference Input (ARI), Analog Reference Output (ARO), Digital

Reference Input (DRI), and Digital Reference Output (DRO).

MORA Analog

Reference Signal

Port Types

Analog Reference

Input

(ARI)

Signal Port

A unidirectional signal port that accepts an analog representation, in the time domain, of a reference signal transported between devices on coaxial or copper interconnect cables.

Analog Reference

Output (ARO)

Signal Port

A unidirectional signal port that generates an analog representation, in the time domain, of a reference signal transported between devices on coaxial or copper interconnect cables.

MORA Analog

Reference Signal

Port Sub Types

ARI/ARO

Signal Port Sub Types

ARI and ARO signal port subtypes include: Sinusoidal Oscillator

(OSC), Reference Clock (CLK), RF Sample (RFS), IF Sample (IFS), and Baseband Sample (BBS).

MORA Digital

Reference Signal

Port Types

Digital Reference

Input

(DRI)

Signal Port

A unidirectional signal port that accepts a digital representation, in the time or frequency domain, of a reference signal transported between devices on fiber or copper interconnect cables.

Digital Reference

Output (DRO)

Signal Port

A unidirectional signal port that generates a digital representation, in the time or frequency domain, of a reference signal transported between devices on fiber or copper interconnect cables.

MORA Digital

Reference Signal

Port Sub Types

DRI/DRO

Signal Port Sub Types

DRI and DRO signal port subtypes include: RF Sample (RFS), IF

Sample (IFS), and Baseband Sample (BBS).

MORA Processing

Resource

A resource within a MORA Device that processes signal data into information, processes information into signal data, or further processes information in support of receive and/or transmit operations in a MORA system. A processing resource can contain either one signal port and one processing port or two processing ports.

MORA Processing

Ports

A logical partition of processing resources with an external access point on a MORA Device in support of receive and/or transmit operations in an RF system. Processing ports include management and data interfaces on the VICTORY Data Bus (VDB) and may also interface with signal resources through signal ports on the MORA Low Latency Bus (ML2B). The information consists of digital formats transported between devices in copper wire or fiber optic interconnect cables.

4 ARCHITECTURE

The Modular Open RF Architecture (MORA) and its interfaces, herein defined, expand the value of VICTORY by supporting complex Radio Frequency (RF) missions in an OSA environment. Specifically, MORA decomposes the RF system by resource functions to promote efficiency, enable resource sharing, and support low-risk reuse in future capability insertions while enabling multi-mission flexibility in a single RF node.

4.1 VICTORY Overview

The VICTORY initiative is developing a framework to enable the integration of C4ISR/EW systems on military platforms.

This framework consists of a network-based architecture, validated interface specifications, reference designs, a reference software library, and a compliance test suite. VICTORY focuses on adopting, adapting, or authoring open standards through a standards body consisting of Government, Industry, and Academia.

The central structure of the VICTORY architecture defines network infrastructure known as the VICTORY Data Bus

(VDB), shared data services, shared hardware devices, management services, data protection, and attribute-based access control. Shared data services foster commonality by providing information required by most C4ISR/EW systems such as time synchronization, position, orientation, and direction of travel. Shared hardware devices reduce SWaP impacts by allowing systems to use common resources and user interface devices. The IA architecture enables “defense in depth” security designs and supports many IA requirements and levels. Access control services provide authentication of entities and authorization for access to resources which becomes increasingly important as current-force systems move towards network-centricity.

VICTORY defines components/systems with network-based messaging interfaces for data transport, data dissemination, management, and access control. Data transport interfaces define physical to transport layer protocols for data delivery, QoS, and signaling that leverage Ethernet and Internet Protocol (IP). Data interfaces define higher layer protocols for application data format, encoding, and encapsulation that primarily use eXtensible Markup Language (XML) encapsulated in User Datagram Protocol (UDP). Management interfaces enable configuration and control of each component/system using Simple Object Access Protocol (SOAP), web services, and Simple Network Management Protocol (SNMP). Status reporting and fault management is accomplished using Syslog and Remote Network Monitoring (RMON). Zero

Configuration Networking (Zeroconf) can be used for service and node auto-discovery to enable plug-and-play functionality on the VDB.

The VICTORY architecture is organized into VDB component types (e.g., switch, router, and shared processing unit), C4ISR/EW systems and component types (e.g., data radio and networked audio data source), and platform system types

(e.g., automotive bus, power distribution unit, and remote weapon station). The VDB enables both integration of

C4ISR/EW systems and interfaces to platform systems. Multiple component types and system types are instantiated in a

VDB design based on the functionality required.

MORA leverages various VICTORY component types to provide infrastructure (e.g., switch), shared data services (e.g., time synchronization, position, orientation, and direction of travel services), shared computing (e.g., shared processing unit), and access control (e.g., authentication, policy decision, policy enforcement, policy store, and attribute store services).

The aspects of VICTORY that are leveraged by MORA include the following:

VICTORY Data Bus - MORA implements a VDB that provides:

o A core transport for delivery of data with QoS o Shared processing resources with a standard Application Programming Interface (API) o Network-based interfaces for managing (configuring, controlling, and managing the health of) the network infrastructure o Defined facilities for access control and protection of data confidentiality

Access control (e.g., authentication, policy decision, policy enforcement, policy store, and attribute store services) o A set of shared data services commonly required in systems

Key component types - a minimal VDB implementation requires two component types that imply hardware support:

o Shared Processing Unit (SPU) o Switch

MORA down-selects from the options available in the VICTORY SPU and Switch specifications by specifying a profile of the specifications to ensure that the performance and quality of service required by MORA applications will be supported

Shared position, navigation, and timing (PNT) - MORA leverages the VICTORY component types that implement shared data services on the VDB to ensure that PNT information can be shared with the MORA system. These component types include:

o Position Service o Direction of Travel Service o Orientation Service o Time Synchronization Service o Global Positioning System (GPS) Receiver

VICTORY features - VICTORY defines a core set of features that are applied to MORA component types.

MORA leverages the following VICTORY features:

o Publish-subscribe style data streams o Web-services style Management Interfaces for configuration and control o Syslog-based health monitoring o Zero Configuration Networking (Zeroconf) based auto-discovery mechanisms

These VICTORY component types and their specifications can be found in Vehicular Integration for C4ISR/EW

Interoperability (VICTORY) Architecture [1] and Vehicular Integration for C4ISR/EW Interoperability (VICTORY)

Standard Specifications [2], respectively. Figure 1 below highlight the minimum set of VICTORY component types recommended for a MORA system.

Figure 1 VICTORY Component Types

4.2 MORA Overview

MORA extends the scope of VICTORY by adding a low latency transport mechanism, data streaming interfaces, new message types, management operations, and functional concepts that are specific to RF applications. Examples of RF applications include voice communications, data communications, and EW.

MORA can be extremely useful in implementing modular, flexible RF systems for performing multiple missions with very high resource efficiency. In basic terms, a MORA system consists of an integration of multiple devices utilizing a two network (bus) topology. These two networks enable MORA systems to build upon VICTORY’s accomplishments while also enabling new, unique MORA features such as low latency message control signaling to replace discrete signaling.

The MORA extension of VICTORY modularizes RF missions, which require additional capabilities including:

Resource management and monitoring of the operation of the RF devices and applications.

Dependable, low latency, and high-speed access and transport of high-volume digital RF signal data sample streams.

Message based, real-time (low latency) control of the RF chain including antenna arrays, RF switches, RF filters and gain stages, frequency converters, analog to digital converters (ADC), digital analog converters (DAC), field programmable gate arrays (FPGA), general purpose processors (GPP), and digital signal processors (DSP).

Formatting, encoding, encapsulation, transport, and routing of messages between the MORA and VICTORY components.

The MORA Low Latency Bus (ML2B) extends VICTORY by introducing an addressable bus for real-time communication. The ML2B provides deterministic message delivery with ultra-low latency (i.e., less than 10 microseconds). Latency is defined as the overall time to send/receive a message and includes transmission, propagation, and switch delays. The ML2B replaces current point-to-point discrete signals (e.g., transistor-transistor logic) between

MORA components. Specific uses of the ML2B include transmit/receive switching, blanking, and tuning messages. Use of an addressable bus, vice point-to-point signals, improves scalability of the MORA architecture and enables component distribution throughout the platform. The ML2B can also be used for digital RF, including real-time control, and delivery of high volume, high rate signal data.

The ML2B uses 10 Gigabit Ethernet (10GbE) or greater due to its ubiquity in commercial products. Since “when” a device can send a message is as important as “how long” it takes for the message to be delivered, deterministic protocols that use a scheduling approach are not appropriate as they limit the maximum message rate. MORA achieves near-deterministic message delivery by using a “fat pipe” to send very small control messages that receive priority in the network based on

QoS policies. Current discrete signals typically convey binary data (i.e., 0 or 1) that can also be conveyed through the use of control messages over the ML2B that will fit within a minimum size Ethernet frame (i.e., 64 bytes). Signal data messages over the ML2B may use larger packets, such as jumbo frames (i.e., 9000 bytes), to improve protocol efficiency.

The combination of high throughput and QoS mechanisms reduce the probability that buffering delays will occur. This is likely further reduced by the fact that most commercial switches are able to switch at line rate, which limits the potential for network contention to traffic to/from the same device.

A combination of VICTORY and MORA specific component types define the interface(s) and transport methods with which the devices in a system interact with one another. The MORA specific component types include the Low Latency

Switch, MORA Device, MORA Signal Resource Manager, MORA Processing Port(s), and MORA Signal Port Manager, as depicted in Figure 2 below.

Figure 2 MORA Specific Component Types

MORA decomposes a monolithic radio system into three different device types including Software Defined Radio (SDR), Radiohead (RHD), and RF Conditioning and Distribution (RCD). Other VICTORY devices and their component types are recommended to complete the system functionality required by RF missions. The ML2B supports low latency, highly deterministic messaging for both resource control (as a means to replace discrete signaling) and digital RF signal data sample streams, which may eliminate the need for analog RF cables. MORA also supports the transport of analog RF

MORA Component Types

Low Latency Switch MORA Signal Port

Manager MORA Device

MORA Signal Resource Manager

MORA Processing Ports

Direction Finding Engine

RF Spectrum Sensor signals on separate fiber optic or coaxial cables. A power bus completes the architecture by providing standard platform power to each device. A typical implementation might use a 28 volt direct current (VDC) power bus, as described in MIL-

STD-1275E, DoD INTERFACE STANDARD: Characteristics of 28 Volt DC Electrical Systems in Military Vehicles [9].

The overall architecture containing capabilities from both VICTORY and MORA is illustrated in Figure 3 below.

Figure 3 MORA Architecture

4.3 MORA Top-Down Perspective

MORA is logically designed to create efficiency, flexibility, reusability, and scalability in future Army RF systems.

Current RF system implementations are typically single-mission focused with closed or proprietary interfaces between stove-piped resources. By defining open interfaces for the processing and signal resources, MORA will enable multi-mission capabilities that utilize and share resources within a single RF node in the tactical environment.