MORA_Specification_V2.5_Revision_Notice_20221221_Final_DIST_A_APPROVED-23-182.pdf

APPROVED FOR PUBLIC RELEASE

MODULAR OPEN RF ARCHITECTURE

(MORA)

SPECIFICATION REVISION NOTICE

VERSION 2.5

December 21, 2022

Approved for Public Release on 23 FEB 2023 under C5ISR Center DRAS-23-182.

MORA Specification Document Version 2.5 - Revision Notice December 21, 2022

REVISION TYPE DEFINITIONS

• ADDITION: The addition of normative text and/or regulations (shall, shall not, may, should, and should not), addressing new requirements or preexisting gaps.

• CLARIFICATION: The addition, modification, or deletion of non-normative text.

• CORRECTION: The modification of normative text and/or regulations (shall, shall not, may, should, and should not), addressing an error or defect.

• DELETION: The removal of normative text and/or regulations (shall, shall not, may, should, and should not).

• RELOCATION: A movement of existing content within the document. Denoted for both the “from” and the “to” location.

• UPDATE: The modification of normative text and/or regulations (shall, shall not, may, should, and should not), addressing formatting or changes over time.

TABLE OF REVISIONS

Section in V2.5 Rev Type Change in V2.5 throughout Clarification Resolved typographical errors.

throughout Clarification Revised grammar for consistency.

throughout Addition Added uniqueness statements to ensure defined scope and bounds.

throughout Update Updated the formatting of management parameter sections to separately bulletize/number complex argument, return value and error condition paragraphs for ease of reading.

throughout Correction Corrected argument and error conditions in management parameters specifications that used the word “are” to use the word “shall” instead.

throughout Update Updated definition, data type/units, and applicability statements of complex type fields to have consistent verbiage and structure.

throughout Update Updated complex type field applicability statements (shall/may) to appear last in the field section.

throughout Update Updated complex type fields with Boolean logic to have data type statements of consistent structure.

throughout Update Updated internal and external document references to have consistent structure and verbiage.

throughout Clarification Revised instances of “IPV4” and “IPV6” to “IPv4” and “IPv6” respectively.

APPROVED FOR PUBLIC RELEASE

throughout Update

Updated any MORA table/spec tags from V2.4 to V2.5 if they were impacted in the 2.5 release:

RF Layer Command Interface <MT90012-V2.5>

RF Layer Context Interface <MT90013-V2.5>

RF Layer Digital Data Interface <MT90014-V2.5>

RF Layer Operations Interface <MT90015-V2.5>

MORA Device Operations Interface <MT90016-V2.5>

MORA Signal Resource Manager Operations Interface <MT90017-V2.5>

Low Latency Switch <MT91010-V2.5>

Low Latency Switch Data Interface <MT91011-V2.5>

Low Latency Switch Data Interface Physical and Data-Link Layer Specifications <MT91012-V2.5>

MORA Device <MT92010-V2.5>

MORA Device Management Interface <MT92011-V2.5>

MORA Signal Resource Manager <MT92013-V2.5>

MORA Signal Resource Management Interface <MT92014-V2.5>

MORA Signal Port Manager <MT92016-V2.5>

MDM Protocol Specifications <MT96001-V2.5>

MDM Networking Specifications <MT96002-V2.5>

Standard for Ethernet Specification <48001-20221221, Pro>

Virtual LANs Specification <48002-20220414, Exp>

Standard for Internet Protocol and User Datagram Protocol Specification <48005-20221221, Pro>

Multicast Dissemination Over the Network Specification <48006-20221221, Pro>

Jumbo Frame Packet Support Specification <48007-20221221, Pro>

MDM Traffic Marking Specification <48008-20220414, Exp>

MDM Data Encoding Specification <48605-20221221, Pro>

MDM Encapsulation Specification <48606-20221221, Pro>

MDM VRT Message Structure Specification <48607-20221221, Pro>

MDM VRT Signal Data Packet Type Specification <48608-20221221, Pro>

MDM VRT Context Packet Type Specification <48609-20221221, Pro>

MDM VRT Command Packet Type Specification <48610-20221221, Pro>

MDM Acknowledgement Message (Type 2) Specification <48611-20221221, Pro>

MDM Time of Day Message (Type 3) Specification <48612-20221221, Pro>

MDM Signal Port User ID Message (Type 4) Specification <48613-20221221, Pro>

MDM Health Message (Type 5) Specification <48614-20221221, Pro>

MDM Command Message (Type 6) Specification <48615-20221221, Pro>

MDM VRT Context and Command Fields Specification <48616-20221221, Pro>

MDM Switch Group User ID Message (Type 7) Specification <48617-20221221, Pro>

MDM Multicast Dissemination Specification <48801-20221221, Pro>

Radio Frequency Distribution Management Parameters <49005-20220414, Pro>

MORA Device Management Parameters <49011-20220307, Pro>

Waveform Management Parameters <49012-20220307, Pro>

MORA Signal Resource Management Parameters <49014-20221221, Pro>

MORA Common Complex Types <49016-20221221, Pro>

Radio Frequency Distribution Complex Types <49018-20220307, Pro>

MORA Signal Resource Profile <49019-20221221, Pro>

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

APPROVED FOR PUBLIC RELEASE

Section in V2.5 Rev Type Change in V2.5 throughout Update Renamed Appendix B from “MORA WSDLS” to “MORA SCHEMAS AND WSDLS.”

throughout Clarification Revised the order of validation examples for value scope in the introduction second paragraph of all management parameter sections.

throughout Addition Added “unsigned integer” to the data type introductory paragraph within complex type sections representing a 32-bit unsigned integer for future use (no impact to current complex types).

throughout Clarification Resolved confusing verbiage for ID-Device Type.

throughout Correction

Clarified the data type introductory paragraph within complex type sections to document the data type interdependency between XML and binary based messaging.

Updated XML schema field specification definitions, that need a binary MDM/VRT equivalent precise translation, to use an accurate mathematical/exponent notation instead of the VITA specification’s observations which were approximate values.

throughout Clarification Revised table headers for binary content for consistency.

1.1 Clarification

Replaced Intelligence and Information Warfare Directorate (I2WD) references due to organizational change (integrated into the

C5ISR Center).

1.7 Clarification Clarified that compliance can be tested and documented for the MORA component types implemented.

2 Update Updated descriptions of references [6] and [7] to “Deleted”.

2 Addition

Added Reference [11] IETF RFC 8200 IPv6 Specification.

Added Reference [12] IEEE 802.1Q-2018 Specification.

Added Reference [13] IETF RFC 2474 Specification.

3.1 – Table 2 Clarification Revised “RCD”, “RHD”, and “SDR” acronym entries to include “(MORA Device Type)” to their definitions.

Revised definition of “VICTORY” acronym for conciseness.

3.1 – Table 2 Clarification Added “MD”, “MSPM”, “MSRM”, and “MSRP” acronym entries.

3.1 – Table 2 Clarification Removed “I2WD” and “MAC” – “Message Authentication Code” acronym entries.

3.2 – Table 3 Clarification

Corrected Digital Signal Port Class definition by replacing the word “coaxial” with “copper.” Also corrected DTR from “Digital

Transmit or Receive (DTR)” to “Digital Transmit and/or Receive (DTR).”

Corrected Reference Signal Port Class definition by adding the word “copper.”

4.6.3.2 Clarification Corrected definition of DTR from “Digital Transmit or Receive (DTR)” to “Digital Transmit and/or Receive (DTR).”

4.6.5 – Figure 10 Clarification Updated image to add MDM Type 4 Signal Port User ID as additional responses to “reserve Signal Port” and “release Signal Port.”

5.1.1 – Table 4 Clarification Corrected IEEE standard number.

5.2.1.1 Update

Replaced IPv4 specification references to IETF RFC standards [6] [7] with references to the applicable sections of the VICTORY

Standard specifications.

5.2.1.1 Addition Added optional IPv6 specifications with references to the applicable sections of the VICTORY Standard specifications.

5.2.1.3 Update Updated the reference [10] description to remove the version year since it is already documented in the referenced documents section.

5.2.1.4 Update Updated MDM VLAN specification for applicability to network infrastructure versus end nodes.

5.2.1.5 Addition Added optional IPv6 specifications in addition to existing required IPv4 specifications.

5.2.1.6 Addition Added required equivalency for Traffic Marking when both DSCP and PCP are contained in a given packet

5.2.1.6 – Table 6 Clarification Corrected IEEE standard number.

5.3.1.1 – Table 8 Addition Added optional Switch IPv6 Data Interface Network Layer and Higher Specifications.

5.3.2 Addition

Added statement: “The MORA Device, MORA Signal Resource Manager, and MORA Signal Port Manager component types shall all be at the same component type version (e.g., V2.5) for a given MORA Signal Resource implementation.”

5.3.2 – Table 12 Addition Added required MORA Signal Resource Profile specification to the MORA Device component type.

Added optional Generic End Node IPv6 Data Interface to the MORA Device component type.

5.3.2.1 Addition

Added statement about optional WSDL declarations in Version Information as well as Authentication and Authorization dependencies.

APPROVED FOR PUBLIC RELEASE

Section in V2.5 Rev Type Change in V2.5

5.3.2.1 – Table 13 Update Changed Generic End Node Management Parameters from required to optional in support of MORA proxy implementations where the surrogate host isn’t managed by the proxied interfaces (e.g. set Host Name).

5.3.2.1.1 – 3.b.i.2 Correction Corrected that list contents of the return value for the “getFileList” operation are unique.

5.3.2.1.1 – 4.b.i.2 Correction Corrected that list contents of the return value for the “getAvailableMORAConfigurations” operation are unique.

5.3.2.1.1 – 5.b.ii.2 Correction Corrected that list contents of the return value for the “getBuiltInTestResults” operation are unique.

5.3.2.1.1 – 6.b.i.1.a Clarification Added definition to OPERATE: “All RF waveform operations as well as signal resource signal data production and consumption on the device are active”

5.3.2.1.1 – 6.b.i.1.b Clarification Revised definition of STANDBY: “All RF waveform operations as well as signal resource signal data production and consumption on the device are halted”

5.3.2.1.1 – 6.b.i.1.c Clarification

Revised definition of TRANSMIT_INHIBIT: “Receive RF waveform operations as well as receive signal resource signal data production and consumption on the device are active. Transmit RF waveform operations as well as transmit signal resource signal data production and consumption on the device are halted.”

5.3.2.1.2 Addition

Added statement at the beginning of the section “Waveform Management Parameters is an optional WSDL interface. It shall only be included in the MORA Device component type, and declared in the associated Version Information, when Waveforms are present in the implementation specific MORA Signal Resource Profile.”

5.3.2.1.2 – 1.a Clarification Updated the definition of Waveforms parameter to be analogous to a single RF application capability for a wireless protocol or modulation.

5.3.2.1.2 – 1.b.i.2 Correction Corrected that list contents of the return value for the “getAvailableWaveforms” operation are unique.

5.3.2.1.2 – 1.b.i.2.a Correction Corrected statement from “If there are no available waveforms, then an empty list shall be returned.” to “The list of available waveforms shall contain at least one item.”

5.3.2.1.2 – 2.a Relocation Relocated a definition of Waveform Operation from section 5.3.5.2 – 2.a.iv.

5.3.2.1.2 – 2.b.i.2 Correction Corrected that list contents of the return value for the “getAvailableWaveformOperations” operation are unique.

5.3.2.1.2 – 2.b.i.2.a Correction Corrected statement from “If there are no available waveform operations, then an empty list shall be returned.” to “The list of available waveform operations shall contain at least one item.”

5.3.2.2 Addition Added that the MORA Device Operations Interface shall provide unicast transmissions.

5.3.2.2 – Table 14 Correction Corrected the applicability of “MDM Health Message (Type 5) Specification” from optional to required for the MORA Device

Operations Interface.

5.3.3 Addition

Added statement: “The MORA Device, MORA Signal Resource Manager, and MORA Signal Port Manager component types shall all be at the same component type version (e.g., V2.5) for a given MORA Signal Resource implementation.”

5.3.3 – Table 15 Addition Added required MORA Signal Resource Profile specification to the MORA Signal Resource Manager component type.

5.3.3.1 Addition

Added statement about optional WSDL declarations in Version Information as well as Authentication and Authorization dependencies.

5.3.3.1.1 – 1.b.i.2 Correction Corrected that list contents of the return value for the “getSignalPorts” operation are unique.

5.3.3.1.1 – 1.b.ii Clarification

Added note “NOTE: When a client receives a reservation confirmation, unambiguous operation for a signal port and its sub ports is accomplished by ensuring that all “Required Control Fields” are set appropriately via MDM Type 1 Command Packets, or are validated via MDM Type 1 Context Packets.”

5.3.3.1.1 – 1.b.ii.1.b Correction Corrected that list contents of an argument for the “reserveSignalPort” operation are unique.

5.3.3.1.1 – 1.b.ii.1.b Update Changed the argument complex type from “MORA Transport Configuration” to “MORA Client Transport Configuration”

Deleted operation specific regulations for “MORA Transport Configuration” optional fields.

5.3.3.1.1 – 1.b.ii.3.e Update Changed the complex type name from “MORA Transport Configuration” to “MORA Client Transport Configuration”.

5.3.3.1.1 -1.b.iii Addition Added note “NOTE: The resource’s behavior after a successful release should maintain the “Required Control Fields” settings and the persistence of analog signals or digital signal data, but is ultimately implementation specific.”

5.3.3.1.1 – 2.b.i.2 Correction Corrected that list contents of the return value for the “getSignalPortReservations” operation are unique.

APPROVED FOR PUBLIC RELEASE

Section in V2.5 Rev Type Change in V2.5

5.3.3.1.1 – 5.a Clarification Clarified the definition of the Static External Connection Map parameter by replacing “… connections between signal ports to other

MORA Devices” with “… connections from internal signal ports to other MORA Devices”.

5.3.3.1.1 – 5.c.i.2 Correction Corrected that list contents of the return value for the “getStaticExternalConnectionMap” operation are unique.

5.3.3.1.1 – 7.a Clarification Clarified the definition of the Internal Reference Connections parameter by replacing “…are available to non-reference signal ports…” with “ … are connected to non-reference signal ports…”.

5.3.3.1.1 – 7.b.i.2 Correction Corrected that list contents of the return value for the “getInternalReferenceConnections” operation are unique.

5.3.3.1.1 – 8.b.i.2 Correction Corrected that list contents of the return value for the “getAntennaArrays” operation are unique.

Corrected that return values from MORA Device Types of “SDR”, “RCD”, and “OTH” shall return an empty list.

5.3.3.1.1 – 8.b.i.2 Addition Added that return values from MORA Device Type of “RHD” shall return at least one item in its list.

5.3.3.1.1 – 9.b.i.2 Clarification Corrected that list contents of the return value for the “getManifoldBands” operation are unique.

Corrected that return values from MORA Device Types of “SDR”, “RCD”, and “OTH” shall return an empty list.

5.3.3.1.1 – 9.b.i.2 Addition

Added that return values from MORA Device Type of “RHD” that have at least one manifold band shall return at least one item in its list.

Added that return values from MORA Device Type of “RHD” that do not have a manifold band shall return an empty list.

5.3.3.1.2 Addition

Added statement at the beginning of the section “Radio Frequency Distribution Management Parameters is an optional WSDL interface. It shall only be included in the MORA Signal Resource Manager component type, and declared in the associated Version

Information, when Switch Groups are present in the implementation specific MORA Signal Resource Profile.”

5.3.3.1.2 – 1.b.i.2 Correction Corrected that list contents of the return value for the “getSwitchGroups” operation are unique.

5.3.3.1.2 – 1.b.i.2.a Correction Corrected statement from “If there are no switch groups, then an empty list shall be returned.” to “The list of switch groups shall contain at least one and no more than 127 items.”

5.3.3.1.2 – 1.b.ii Clarification

Added note “NOTE: When a client receives a reservation confirmation, unambiguous operation for a switch group is accomplished by ensuring that the “Switch State” is set appropriately via MDM Type 1 Command Packets, or are validated via MDM Type 1 Context

Packets.”

5.3.3.1.2 – 1.b.ii.1.b Correction Corrected that list contents of an argument for the “reserveSwitchGroup” operation are unique.

5.3.3.1.2 – 1.b.ii.1.b Update Changed the argument complex type from “MORA Transport Configuration” to “MORA Client Transport Configuration”

Deleted operation specific regulations for “MORA Transport Configuration” optional fields.

5.3.3.1.2 – 1.b.ii.3.d Update Changed the complex type name from “MORA Transport Configuration” to “MORA Client Transport Configuration”.

5.3.3.1.2 – 1.b.iii Addition Added note “NOTE: The resource’s behavior after a successful release should maintain the switch state control field, and hence the persistence of analog signals, but is ultimately implementation specific.”

5.3.3.1.2 – 2.b.i.2 Correction Corrected that list contents of the return value for the “getSwitchGroupReservations” operation are unique.

5.3.3.2 Addition Added that the MORA Signal Resource Manager Operations Interface shall provide unicast transmissions.

5.3.3.2 – Table 17 Correction Corrected the applicability of “MDM Switch Group User ID Message (Type 7) Specification” from optional to required for the

MORA Signal Resource Manager Operations Interface.

5.3.4 Clarification Added explanatory paragraphs to highlight the closely coupled relationships among component type operations and behaviors.

5.3.4 Addition

Added statement: “The MORA Device, MORA Signal Resource Manager, and MORA Signal Port Manager component types shall all be at the same component type version (e.g., V2.5) for a given MORA Signal Resource implementation.”

5.3.4 – Table 18 Addition Added required MORA Signal Resource Profile specification to the MORA Signal Resource Manager component type.

5.3.4.2 Addition Added that the RF Layer Command Interface shall provide unicast transmissions.

5.3.4.3 Clarification Clarified that the RF Layer Context Interface shall provide multicast transmissions, which was already a requirement in the table.

5.3.4.4 Clarification Clarified that the RF Layer Digital Data Interface shall provide multicast transmissions, which was already a requirement in the table.

5.3.4.5 Addition Added that the RF Layer Operations Interface shall provide unicast transmissions.

5.3.5.1 – 3.b.ii Addition Added “SPIRAL” and “OTHER” enumerated values.

5.3.5.1 – 4.a.i Clarification Clarified that the “Array ID” identifier is unique.

APPROVED FOR PUBLIC RELEASE

Section in V2.5 Rev Type Change in V2.5

5.3.5.1 – 4.a.ii Addition Added that the “Array ID” enumeration is described in the Reference Point Identifier section of the “MDM VRT Context and

Command Fields Specification.”

5.3.5.1 – 8.c.i Clarification Clarified the definition of Compensation Criteria by replacing “maximum temperature change” with “temperature change threshold.”

5.3.5.1 – 8.d.i Clarification Clarified the definition of Compensation Criteria by replacing “maximum amount of elapsed time” with “elapsed time threshold.”

5.3.5.1 – 8.e.i Clarification Clarified the definition of Compensation Criteria by replacing “maximum frequency change” with “frequency change threshold.”

5.3.5.1 – 10 Clarification Added missing definitions for both “Name” and “Value” fields of the Device Specific Status complex type.

5.3.5.1 – 11.a.ii.1.a Clarification Added definition to OPERATE: “All RF waveform operations as well as signal resource signal data production and consumption on the device are active”

5.3.5.1 – 11.a.ii.2.a Clarification Revised definition of STANDBY: “All RF waveform operations as well as signal resource signal data production and consumption on the device are halted”

5.3.5.1 – 11.a.ii.3.a Clarification

Revised definition of TRANSMIT_INHIBIT: “Receive RF waveform operations as well as receive signal resource signal data production and consumption on the device are active. Transmit RF waveform operations as well as transmit signal resource signal data production and consumption on the device are halted.”

5.3.5.1 – 14.c.i Clarification Revised the definition of “External Device” to be the device type and identifier of the external device for this connection.

5.3.5.1 – 14.c.ii Correction Changed data type of “External Device” from a “MORA Device” complex type to be a restricted string composed of the concatenated

“Type” and “ID” that corresponds to the “MORA Device” complex type. There shall not be any zero padding on the “ID” field.

5.3.5.1 – 15.g Clarification Clarified that the filter frequency range is determined at the -3 dB amplitude response points.

5.3.5.1 – 17 Addition Added new “Frequency Domain Packet Format” complex type.

5.3.5.1 – 18.b.iii Addition Added “End shall be greater than or equal to Start.”

5.3.5.1 – 18.c.ii Correction Corrected the bounds to match the schema for the Resolution field of the Frequency Range complex type.

5.3.5.1 – 19.a.ii Correction Corrected the bounds to match the schema for the IF Center Frequencies field of the Frequency Translation complex type.

5.3.5.1 – 19.b.ii Correction Corrected the bounds to match the schema for the IF Bandwidths field of the Frequency Translation complex type.

5.3.5.1 – 19.d.ii Correction Corrected the bounds to match the schema for the RF Bandwidths field of the Frequency Translation complex type.

5.3.5.1 – 19.e.i Clarification Clarified the definition by replacing “RF Converter” with “analog frequency translation” for the Tuning Speed field of the Frequency

Translation complex type.

5.3.5.1 – 20.b.i Clarification Revised the definition by removing “half duplex” for the Signal Direction field of the Gain Stage complex type.

5.3.5.1 – 20.d.iii/iv Update Changed applicability of Manual Gain from optional (may) to conditionally required (shall be provided as part of Gain Stage when

Gain Type is MANUAL or SELECTABLE, shall not be provided as part of Gain Stage when Gain Type is AUTOMATIC).

5.3.5.1 – 20.e.i Clarification Revised the definition of Output Level to be the control description for the 1dB Compression Point output power level(s) of this gain stage.

5.3.5.1 – 20.e.ii Correction Changed the data type of Output Level from “Output Level complex type to be an increasing list of real numbers, greater than or equal to -28 and less than or equal to 28 - (1/27), in dBm and a resolution of 1/27 dB (0.0078125 dB).”

5.3.5.1 – 20.e.iii Addition Added that “Output Level” must have at least one item in its list.

5.3.5.1 – 20.e.iv/v Update Changed applicability of Output Level from optional (may) to conditionally required (shall be provided as part of Gain Stage when

Gain Type is AUTOMATIC or SELECTABLE, shall not be provided as part of Gain Stage when Gain Type is MANUAL).

5.3.5.1 – 21.b.iii Addition Added “If the test source power is fixed, the Max Injected Power shall equal the Min Injected Power.”

5.3.5.1 – 21.b.iv Addition Added “If the test source power is not fixed, then Max Injected Power shall be greater than the Min Injected Power.”

5.3.5.1 – 21.c.iii Update Updated to “If the test source power is fixed, the Resolution shall equal zero.”

5.3.5.1 – 23.b.iii Addition Added “Maximum Gain shall be greater than Minimum Gain.”

5.3.5.1 – 23.c.i Clarification Clarified the definition by replacing “measure that” with “gain change for” for the Resolution field of the Manual Gain complex type.

5.3.5.1 - 24 Addition Added “MORA Client Transport Configuration” complex type.

5.3.5.1 – 25.d.iv Correction Corrected the “Supported Signal Ports” field within the “MORA Configuration” complex type where it “shall be provided as part of

MORA Configuration when MORA Signal Resource Manager and MORA Signal Port Manager component types are present.”

APPROVED FOR PUBLIC RELEASE

Section in V2.5 Rev Type Change in V2.5

5.3.5.1 – 25.d.v Addition

Added the following statement to the “Supported Signal Ports” field within the “MORA Configuration” complex type: “Supported

Signal Ports shall not be provided as part of MORA Configuration when MORA Signal Resource Manager and MORA Signal Port

Manager component types are not present.”

5.3.5.1 – 25.e Addition Added the “Supported Switch Groups” field to the “MORA Configuration” complex type.

5.3.5.1 - 29 Update

Renamed “MORA Transport Configuration” complex type to “MORA Resource Transport Configuration” complex type.

Deleted Component ID, Signal Port ID and Priority Level from the complex type since they do not apply to MORA Resource

Transport Configuration.

5.3.5.1 Deletion Deleted the “Output Level” complex type

5.3.5.1 – 39.b.i Clarification Clarified the definition by replacing “unique” with “private” since confirmation numbers could repeat during long operating cycles for the Confirmation Number field of the Reservation Confirmation complex type.

5.3.5.1 – 42.a.ii Correction Corrected the bounds to match the schema for the Sample Bandwidth field of the Sample Bandwidth and Sample Rate complex type.

5.3.5.1 – 42.b.ii Correction Corrected the bounds to match the schema for the Sample Rate field of the Sample Bandwidth and Sample Rate complex type.

5.3.5.1 Deletion Deleted the “Signal Data Attributes” complex type.

5.3.5.1 – 44 Addition Added new “Signal Data Format” complex type.

5.3.5.1 – 45.a.iii Update

Changed applicability of Signal Port Signal Domain Conversion Description from required to optional for implementations that do not support signal port wide band signal data production or consumption but do support subport narrow band signal data production or consumption.

5.3.5.1 – 46 Deletion Deleted the “Sample Format” field from the “Signal Domain Conversion Description” complex type.

Deleted the “Sample Sizes” field from the “Signal Domain Conversion Description” complex type.

5.3.5.1 – 46.c Addition Added new field “Supported Signal Data Formats” to the “Signal Domain Conversion Description” complex type.

5.3.5.1 – 46.d Clarification Added note box recommending documentation as to which Supported Signal Data Formats are available for each Sample Bandwidth and Sample Rate.

5.3.5.1 – 47.m.ii Clarification Clarified the subfields from the field and added a hyperlink to the Reference Point Identifier (CIF0/Bit30) section.

5.3.5.1 – 47.n.ii Update Changed the complex type from “MORA Transport Configuration” to “MORA Resource Transport Configuration”

5.3.5.1 – 47.p Clarification Added a note for “If the comprehensive set includes any fields from CIF1 (integer 101-131), then the CIF1 enable bit (integer 1) present in CIF0 would be included.”

5.3.5.1 – 47.p.i Clarification Clarified the definition to become “The comprehensive set of MDM Type 1 control fields required to be provided by a client for unambiguous operation of this signal port.”

5.3.5.1 – 47.q Addition Added the new “Client Inactivity Timeout Field” to the “Signal Port” complex type.

5.3.5.1 – 47.r Addition Added the new “Command Execution Time” to the “Signal Port” complex type.

5.3.5.1 – 48.a.i Clarification Clarified the definition by replacing “reservation” with “description” for the Signal Port ID field of the Signal Port Description complex type.

5.3.5.1 – 48.b.iii Addition Added that when “RF Conditioning” is provided as part of “Signal Port Description” that “RF Conditioning” shall not be empty.

5.3.5.1 – 48.d.iii Addition Added that when “Signal Domain Conversion” is provided as part of “Signal Port Description” that “Signal Domain Conversion” shall not be empty.

5.3.5.1 – 50.b.ii Update The corresponding complex type changed from “MORA Transport Configuration” to “MORA Client Transport Configuration”.

5.3.5.1 – 53.d Clarification Added a note for “If the comprehensive set includes any fields from CIF1 (integer 101-131), then the CIF1 enable bit (integer 1) present in CIF0 would be included.”

5.3.5.1 – 53.d.i Clarification Clarified the definition to become “The comprehensive set of MDM Type 1 control fields required to be provided, in addition to the signal port control fields, by a client for unambiguous operation of this sub port.”

5.3.5.1 – 53.d.ii Correction Corrected the bounds to match the schema for the Required Control Fields field of the Sub Port complex type.

5.3.5.1 – 59 Addition Added new “Time Domain Packet Format” complex type.

5.3.5.2 – 2.a Relocation Relocated V2.4 section 5.3.5.2 – 2.a.iv to V2.5 section 5.3.2.1.2 – 2.a.

APPROVED FOR PUBLIC RELEASE

Section in V2.5 Rev Type Change in V2.5

5.3.5.3 – 1.c.iii Addition Added that Unique Name in the “Data Transport Configuration” shall minimally include the MAC address in the first 17 characters in the restricted string (e.g. 02:C0:ED:12:34:56) for the Control Transport Configuration field of the Switch Group complex type.

5.3.5.3 – 1.c.iv Correction

Added that URI field in the “Data Transport Configuration” shall minimally include IPv4/6 address, UDP port and MUI information in the path (e.g. udp://192.168.0.1:50001/50100) and that the UDP port and MUI may have the same assigned value for the Control

Transport Configuration field of the Switch Group complex type.

5.3.5.3 – 1.c.v Addition

Added that the optional Network Layer field in the “Data Transport Configuration” shall not be included and that if the Network

Layer field is included and well formed, it shall be ignored for the Control Transport Configuration field of the Switch Group complex type.

5.3.5.3 – 1.d.iii Addition Added that Unique Name in the “Data Transport Configuration” shall minimally include the MAC address in the first 17 characters in the restricted string (e.g. 02:C0:ED:12:34:56) for the Context Transport Configuration field of the Switch Group complex type.

5.3.5.3 – 1.d.iv Correction

Added that URI field in the “Data Transport Configuration” shall minimally include IPv4/6 address, UDP port and MUI information in the path (e.g. udp://192.168.0.1:50001/50100) and that the UDP port and MUI may have the same assigned value for the Context

Transport Configuration field of the Switch Group complex type.

5.3.5.3 – 1.d.v Addition

Added that the optional Network Layer field in the “Data Transport Configuration” shall not be included and that if the Network

Layer field is included and well formed, it shall be ignored for the Context Transport Configuration field of the Switch Group complex type.

5.3.5.3 – 1.e Addition Added the new “Client Inactivity Timeout Field” to the “Switch Group” complex type.

5.3.5.3 – 1.f Addition Added the new “Command Execution Time” to the “Switch Group” complex type.

5.3.5.3 – 2.b.i Clarification Clarified the definition with “The Client Component IDs authorized to use the identified switch group for this switch group reservation.”

5.3.5.3 – 2.b.ii Update The corresponding complex type changed from “MORA Transport Configuration” to “MORA Client Transport Configuration”.

5.4.2.b.i.2.a Clarification Added definition to OPERATE: “All RF waveform operations as well as signal resource signal data production and consumption on the device are active”

5.4.2.b.i.2.b Clarification Revised definition of STANDBY: “All RF waveform operations as well as signal resource signal data production and consumption on the device are halted”

5.4.2.b.i.2.c Clarification

Revised definition of TRANSMIT_INHIBIT: “Receive RF waveform operations as well as receive signal resource signal data production and consumption on the device are active. Transmit RF waveform operations as well as transmit signal resource signal data production and consumption on the device are halted.”

5.4 – 2.b.i.4 Update Updated to better define the relationship between the reported SYSLOG values for a “deviceState” with the “State” in the “Device

Status” complex type.

5.4 – 2.b.ii.3 Update Updated to better define the relationship between the reported SYSLOG values for a “waveform” with the “Description” in the

“Waveform” complex type.

5.4 – 2.b.iii Clarification Clarified that SPM_errors are related to MDM Type 2 No Responses and Response Values of 2, 4, 8, 16, 64, and 128.

5.4 – 2.b.iv Clarification Clarified that SPM_out_of_sequence events are related to MDM Type 2 Response Value of 32.

5.4 – 2.b.v Clarification Clarified that SPM_ACKs are related to MDM Type 2 Response Values of 1 and 32.

5.5 – Table 24 Update Added a V2.5 column under the “Version Applicability” heading in the MORA Management Interface Types table.

5.5 – Table 25 Correction Corrected by renaming heading from “Version Applicability” to “WSDL Port Version(s)” in the MORA SOAP Component Types table.

5.5 – Table 25 Update

Added a V2.5 column under the “WSDL Port Version(s)” heading in the MORA SOAP Component Types table.

Changed the WSDL port versions of MORA_DEVICE, WAVEFORM, MORA_SIGNAL_RESOURCE, and

RADIO_FREQUENCY_DISTRIBUTION from V2.4 to V2.5.

5.7 Addition Added new “MORA Signal Resource Profile” section.

5.7.1 Addition Added new “MORA Signal Resource Profile Implementation Rules” section.

APPROVED FOR PUBLIC RELEASE

Section in V2.5 Rev Type Change in V2.5

5.7.2 Addition Added new “MORA Signal Resource Profile Complex Types” section.

6.1.2.1.3 Update

Updated the meaning of the MDM header version major / minor to be specific to the MDM Type in accordance with the “MDM

Version by Type” table and that implementations may support interoperability of legacy versions by MDM Type.

6.1.2.1.5 Addition

Added that the ML2B Interface ID shall be used to validate all incoming messages by verifying the originator and/or destination

MUIs in MDM transmissions.

6.1.2.1.5 Update

Updated the uniqueness bounds for both the “Origination ID” and “Destination ID” are minimally unique to the component type instance within a MORA device and is also unique within a MORA system.

6.1.2.1.6 Relocation Relocated “MDM Types” table to APPENDIX C and renamed it to “MDM Size by Types.”

6.1.2.1.6 Deletion

Removed the unnecessary sentence “All messages within a particular MDM packet shall be of the same type” as regulation in the

“MDM Size by Types” table naturally prevents this.

6.3.1 Clarification Clarified that the use of MDM VRT Type 1 messages is for MORA Signal Port Manager client interactions only.

6.3.1.1 Clarification

Added summary bullets for Warning and Error Response Field.

Added summary bullets for Message ID Field.

6.3.1.2.3 Update

Added synchronization of the TSI and TSF code values so that when TSI is present, TSF is also present. When TSI is not present, TSF is also not present.

6.2.1.2.3 – Table 36 Correction Corrected erroneous callout of “T3/T2/T1” to “T2/T1/T0”.

6.3.1.2.5 Update

Updated the meaning of the VERSION MAJ and VERSION MIN subfields within Information Class Code to be specific to MDM

Type 1 in accordance with the “MDM Version by Type” table.

6.3.1.3.3 Clarification Deleted two note boxes regarding the C5ISR Center reference design implementation as they are irrelevant to the specification.

6.3.1.3.3 – Table 47 Clarification Corrected the table name from “Signal Payload Packet Data Format Field” to “Signal Data Packet Payload Format Field”.

6.3.1.4.5 Addition Added section for signal packet generation regulations.

6.3.1.5.3 Addition Added differentiation of which MORA context fields apply to signal ports, switch groups or both.

6.3.1.5.3 – Table 65 Update Updated table applicability indicator from “X” to now include “SP”, “SG” and “SP/SG”.

6.3.1.5.4 Update

Added rule regarding context packet generation in response to executed command packets minimally for specific Device States and stated applicability to signal ports and subports with one or more Required Control Fields as well as all switch groups.

Updated existing rule regarding periodic comprehensive context packet generation minimally for specific Device States and clarified applicability to signal ports and subports with one or more Required Control Fields as well as all switch groups.

6.3.1.6.4 Addition

Added “Er” to the list of bits that shall be set to “0”.

Added that the “W” bit shall be set to “1”.

Added that when “ReqV” is set to “1”, then “ReqW” and “ReqEr” shall also be set to “1”.

6.3.1.6.4 – Table 67 Update Updated “W” to “1”, “Er” to “0”, and all “Res” bits to “0”.

6.3.1.6.5 Addition

Added new section “Message ID Field for Control and Acknowledge Packets” to further clarify VITA 49.2 rules and add sequential numbering assignment to enable detection of out of sequence control packets.

6.3.1.6.6 Addition

Added “Er” to the list of bits that shall be set to “0”.

Added that the “W” and “AckV” bits shall be set to “1”.

Add the following to clarify the VITA specification: The VITA 49.2 table 8.4.1-1 function description for bit 16 (AckEr) for validation acknowledge packets (AckV = 1) shall be interpreted as follows: “Set To 1: Errors were generated; Set to 0: No errors were generated.”

6.3.1.6.6 – Table 68 Update Updated “W” and “AckV” to “1”, “Er” to “0”, and all “Res” bits to “0”.

6.3.1.6.7 Addition

Added new section “MORA Warning and Error Response Fields for Acknowledge Packets” to describe the MORA implementation of the VITA 49.2 Warning and Error Response Fields for Acknowledge Packets.

6.3.1.6.8 Addition Added that when “ReqV” is set to “1”, then “ReqW” and “ReqEr” shall also be set to “1”.

6.3.1.6.8 – Table 70 Update Updated all “Res” bits to “0”.

APPROVED FOR PUBLIC RELEASE

Section in V2.5 Rev Type Change in V2.5

6.3.1.6.9 Addition Added differentiation of which MORA control fields apply to signal ports, switch groups or both.

6.3.1.6.10 Addition Added section for command packet execution regulations.

6.3.1.6.9 – Table 71 Update Updated table applicability indicator from “X” to now include “SP”, “SG” and “SP/SG”.

6.3.2 Clarification

Clarified that the MDM Type 2 message is used for both resource inter-component type and MORA Signal Port Manager client interactions.

6.3.2 Update

Updated first paragraph to become: “This message is used for both resource inter-component type and MORA Signal Port Manager client interactions. The MDM Acknowledgement Message (Type 2) shall be used, when requested, to provide a positive acknowledgement to the sender of valid MDMs, excluding MDM Acknowledgement Message (Type 2), that a specific message (as indicated by the MDM SEQUENCE NUMBER) was received and the MDM Header was validated by the recipient. In addition to this initial scrutiny, the MDM Acknowledgement Message (Type 2) also shall provide a means by which the recipient may further delineate payload validation as well as execution success or failure for all valid MDM Types, excluding MDM VITA Radio Transport

(VRT) (Type 1) and MDM Acknowledgement Message (Type 2).

Added paragraph: “MDM VITA Radio Transport (VRT) (Type 1) Command Packet Sub Type message payload validation acknowledgement shall be accomplished, when requested, using the acknowledge validation (AckV) feature of VITA 49.2. However, an AckV response shall not be issued if an MDM Acknowledgement Message (Type 2) error response occurs. Execution acknowledgement for MDM VITA Radio Transport (VRT) (Type 1) Command Packet Sub Type messages shall be accomplished by monitoring the associated multicast MDM VITA Radio Transport (VRT) (Type 1) Context Packet Sub Type messages. Therefore, MDM Acknowledgement Message (Type 2) responses to MDM VITA Radio Transport (VRT) (Type 1) Command Packet Sub Types shall not include response values of (4), (8), and (16) as depicted in Table 73 below.”

6.3.2 – Table 73 Update Replaced the “r” bit label with a “VI” bit label for “Version Incompatibility” errors.

6.3.2 Addition

Added the following sentences before Table 73: “The response to an MDM requesting acknowledgement shall be a single MDM

Acknowledgement Message (Type 2). The single acknowledgement shall follow the order of response precedence specified. The requester’s notional behavior based upon the response value is also described below.

6.3.2 – Table 74 Addition

Added a response value of 128 to the table for “Version Incompatibility (VI)” errors.

Added a column specifying an order of precedence in acknowledgement evaluation.

Changed existing ‘*’ callout instances to ‘**’.

Added a new ‘*’ to indicate MDM Acknowledgement responses (4, 8, and 16) are not permitted for MDM VRT Command Packet

Types.

6.3.2 – Table 74 Clarification Clarified some of the entries in the “Response Meaning” column.

6.3.3 – Table 75 Clarification Renamed “SEND-ACK” to “ACK” to be consistent with the field name defined in the MDM encapsulation section.

6.3.3 Clarification Clarified that the MDM Type 3 message is used for resource inter-component type interactions only.

6.3.4 – Table 77 Clarification Renamed “SEND-ACK” to “ACK” to be consistent with the field name defined in the MDM encapsulation section.

6.3.4 – Table 77 Addition

Added User ML2B Command Field Indicator Bits, User Command ML2B Unique Identifier (MUI), User ML2B Signal Data Field

Indicator Bits, User Signal Data ML2B Unique Identifier (MUI), User ML2B Context Field Indicator Bits, and User Context ML2B

Unique Identifier (MUI) fields to the MDM Signal Port User ID Message Format table.

6.3.4 Clarification

Clarified that the MDM Type 4 message is used for both resource inter-component type and MORA Signal Port Manager client interactions.

Clarified verbiage for verifying incoming release MDMs.

6.3.4 Update

Updated the third use case description to become “To communicate to a MORA Signal Resource Manager component type and

MORA Signal Port Manager Client(s) that a signal port release has occurred at its MORA Signal Port Manager component type due to a lack of communications from an authorized MORA Signal Port Manager client within a signal port specific period of time, if implemented.”

Updated the octet/byte order and bit ordering verbiage for IPv4, IPv6, and MAC for Command, Signal Data, and Context.

APPROVED FOR PUBLIC RELEASE

Section in V2.5 Rev Type Change in V2.5

6.3.4 Addition

Added definitions for the User ML2B Command Field Indicator Bits, User Command ML2B Unique Identifier (MUI), User ML2B

Signal Data Field Indicator Bits, User Signal Data ML2B Unique Identifier (MUI), User ML2B Context Field Indicator Bits, and

User Context ML2B Unique Identifier (MUI) fields.

Added sentence along with updates to an existing paragraph to clarify usage of the SIGNAL PORT ID field of the SIGNAL PORT

RESOURCE ID and USER ID subfields.

Added sentence to User ML2B Signal Data message fields to be set to zero when the client does not publish digital signal data.

Added sentence to User ML2B Context message fields to be set to zero when the client does not publish context.

6.3.5 – Table 80 Clarification Renamed “SEND-ACK” to “ACK” to be consistent with the field name defined in the MDM encapsulation section.

6.3.5 Clarification Clarified that the MDM Type 5 message is used for resource inter-component type interactions only.

6.3.5 Update

Updated to become “For device level operational parameters, messages shall be sent to both MORA Device and MORA Signal

Resource Manager component types. For signal port level operational parameters, messages shall be sent only to the MORA Signal

Resource Manager component type.”

6.3.5 Update

Updated the MDM Type 5 second method use of Operational State field’s value to not have to represent all monitored parameters in a single value.

6.3.5 Correction

Corrected that switch group resource health status is reported for each signal port(s) impacted unless all signal ports on the device are impacted, in which case it’s reported at the device level.

6.3.5 – Figure 25 Clarification Clarified that the Operational State field is implementation specific.

6.3.6 – Table 81 Clarification Renamed “SEND-ACK” to “ACK” to be consistent with the field name defined in the MDM encapsulation section.

6.3.6 Clarification Clarified that the MDM Type 6 message is used for resource inter-component type interactions only.

6.3.6 – Figure 26 Correction Corrected the upper bound of Configuration ID to be 2,147,483,647 in alignment with the XML signed integer greater than 0.

6.3.6 – Figure 27 Correction Corrected the upper bound of Waveform Operation ID to be 2,147,483,647 in alignment with the XML signed integer greater than 0.

6.3.7 – Table 82 Clarification Renamed “SEND-ACK” to “ACK” to be consistent with the field name defined in the MDM encapsulation section.

6.3.7 – Table 82 Addition Added User ML2B Command Field Indicator Bits, User Command ML2B Unique Identifier (MUI), User ML2B Context Field

Indicator Bits, and User Context ML2B Unique Identifier (MUI) fields to the MDM Switch Group User ID Message Format table.

6.3.7 Clarification

Clarified that the MDM Type 7 message is used for both resource inter-component type and MORA Signal Port Manager client interactions.

Clarified verbiage for verifying incoming release MDMs.

6.3.7 Update

Updated the third use case description to become “To communicate to a MORA Signal Resource Manager component type and

MORA Signal Port Manager Client(s) a switch group release has occurred at its MORA Signal Port Manager component type due to a lack of communications from an authorized MORA Signal Port Manager client within a switch group specific period of time, if implemented.”

Updated the octet/byte order and bit ordering verbiage for IPv4, IPv6, and MAC for Command and Context.

6.3.7 Addition

Added definitions for the User ML2B Command Field Indicator Bits, User Command ML2B Unique Identifier (MUI), User ML2B

Context Field Indicator Bits, and User Context ML2B Unique Identifier (MUI) fields.

Added/updated sentence(s) to existing paragraphs to clarify usage of the SWITCH GROUP ID / SIGNAL PORT ID fields of the

SWITCH GROUP RESOURCE ID / USER ID subfields respectively.

Added sentence to User ML2B Context message fields to be set to zero when the client does not publish context.

7.3.1.1 Clarification Added Avahi to the listed library examples.

7.3.2 – Figure 30 Clarification Corrected figure to include Generic End Node content to the MORA Device response.

7.3.2 Clarification

Corrected to include Generic End Node content to the MORA Device response given by the version information web service and included references to applicable specification sections for version information and health publishing content.

APPROVED FOR PUBLIC RELEASE

Section in V2.5 Rev Type Change in V2.5

7.3.5 – Figure 33 Clarification

Corrected the figure to show that the resource announces the reservation over ML2B to all clients of the reservation.

Corrected the figure for the change in complex type name from “MORA Transport Configuration” to “MORA Client Transport

Configuration”

7.3.5 Clarification

Corrected the explanations to show that the resource announces the reservation over ML2B to all clients of the reservation.

Corrected for the change in complex type name from “MORA Transport Configuration” to “MORA Client Transport Configuration”

7.4.1 Clarification

Corrected for the change in complex type name from “MORA Transport Configuration” to “MORA Resource Transport

Configuration”

7.5.2 Clarification

Clarified that the example demonstrates a multi-client reservation.

Corrected for the change in complex type name from “MORA Transport Configuration” to “MORA Client Transport Configuration”

7.5.2 – Figure 39 Clarification

Corrected that the reserving client is required to be an authorized user and must be listed first in the reserve request argument’s list of

MORA Transport Configuration to leverage its priority.

Corrected that the MORA Signal Port Manager resource announces reservations to all authorized clients and that the reserving client does not announce reservations to non-reserving authorized clients.

Corrected that the context was erroneously depicted as being sent by an RF Layer Command Interface for RHD1.

Corrected the figure for the change in complex type name from “MORA Transport Configuration” to “MORA Client Transport

Configuration”

7.5.2 Clarification Corrected the explanation to align with the corrected figure.

Appendix B Update Updated the title of the appendix from “MORA WSDLS” to “MORA SCHEMAS AND WSDLS.”

Appendix B Relocation Relocated the two schema tables from the previous MORA SCHEMAS Appendix C to the existing MORA WSDLs tables in

Appendix B.

Appendix B – Table 89 Addition Added the required MORA Signal Resource Profile Complex Types schema to the “MORA Schemas” table.

Appendix B – Table 91 Correction Corrected capitalization of “RfDistribution.wsdl” to “RFDistribution.wsdl” to match the actual filename of the wsdl.

Appendix B – Table 92 Update Changed the applicability of the GenericEndNode.wsdl from required to optional.

Appendix C Update Updated the title of the appendix from “MORA SCHEMAS” to “MORA DATA MESSAGE TYPE ATTRIBUTES.”

Appendix C Relocation Relocated the two schema tables to the new MORA SCHEMAS AND WSDLS Appendix B.

Appendix C – Table 93 Addition Added “Current Version by MDM Type” table to Appendix C.

Appendix C Relocation Relocated “MDM Types” table (V2.4 table 30) from section 6.1.2.1.6 and renamed it to “MDM Size by Types” (V2.5 table 93).

Appendix C – Table 94 Update Updated Data Message Size of MDM Type 4 from 19 to 22 words and of MDM Type 7 from 13 to 15 words.