VICTORY-Spec-Doc-V1-9-MORA-Appendix.pdf

VICTORY STANDARD SPECIFICATIONS DOCUMENT

APPENDIX: MODULAR OPEN RF ARCHITECTURE (MORA)

SPECIFICATION

Version 2.4 An Appendix to VICTORY Standard Specifications Document V1.9

April 09, 2021

Distribution Statement A

Approved for public release. Distribution is unlimited.

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

VICTORY Specifications Version 1.9 Appendix: Modular Open RF Architecture (MORA) Specification April 09, 2021

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

VICTORY Specifications Version 1.9

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

VICTORY Specifications Version 1.9

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

VICTORY Specifications Version 1.9

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

VICTORY Specifications Version 1.9

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

VICTORY Specifications Version 1.9

1. INTRODUCTION

NOTE: This document requires the VICTORY Standard Specifications V1.9 (release date April 09, 2021) document for a complete understanding of the MORA component type.

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 Specifications Version 1.9

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

VICTORY Specifications Version 1.9

• Exp - Experimental

• Pro - Proposed Standard

• Dft - Draft Standard

• Std - MORA Standard

The meanings and definitions of these terms are given in and governed in the section titled “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, the section titled “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

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

VICTORY Specifications Version 1.9

Specification Group Group Identifier

MORA Low Latency Bus 48

MORA Management Interfaces 49

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.

• 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 the 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.

VICTORY Specifications Version 1.9

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

VICTORY Specifications Version 1.9

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

VICTORY Specifications Version 1.9

Abbreviation/ Acronym Definition 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

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

VICTORY Specifications Version 1.9

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

VICTORY Specifications Version 1.9

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

VICTORY Specifications Version 1.9

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

VICTORY Specifications Version 1.9

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).

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.

MORA

Device Types

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.

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.

MORA

Device Sub Types

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).

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.

MORA

Signal Resource Types

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).

VICTORY Specifications Version 1.9

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).

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.

MORA

Analog Signal Port Types

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).

VICTORY Specifications Version 1.9

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.

MORA

Digital Signal Port Types

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).

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.

MORA

Analog Reference Signal Port Types

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).

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.

MORA

Digital Reference Signal Port Types

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).

VICTORY Specifications Version 1.9

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.

VICTORY Specifications Version 1.9

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:

◦ A core transport for delivery of data with QoS

◦ Shared processing resources with a standard Application Programming Interface (API)

◦ Network-based interfaces for managing (configuring, controlling, and managing the health of) the network infrastructure

◦ 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)

◦ 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:

◦ Shared Processing Unit (SPU)

VICTORY Specifications Version 1.9

◦ 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:

◦ Position Service

◦ Direction of Travel Service

◦ Orientation Service

◦ Time Synchronization Service

◦ 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:

◦ Publish-subscribe style data streams

◦ Web-services style Management Interfaces for configuration and control

◦ Syslog-based health monitoring

◦ 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

VICTORY Specifications Version 1.9

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.

VICTORY Specifications Version 1.9

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 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 2. MORA Specific Component Types

VICTORY Specifications Version 1.9

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. Figure 4 below depicts the top-down perspective of a MORA system and the boundary of resource interfaces that the MORA specification encompasses.

Figure 3. MORA Architecture

VICTORY Specifications Version 1.9

The operation of RF missions typically consists of a combination of complex hardware, firmware, and software resources. These resources can require significant space and power and therefore can often be constrained in smaller platforms. It is essential that future systems be based on an architecture that fully promotes maximum efficiency and flexibility of resources. At the foundation of all RF missions, signal resources are required to capture, radiate, condition, distribute, translate, and/or convert RF signals. For RF chain receive operations, signal resources provide digital signal data to processing resources in order to develop information.