Attachment_0037-_RAS-G_IOP_V2_Comms_Profile.pdf

Unclassified i

Robotics and Autonomous Systems – Ground (RAS-G) Interoperability Profile (IOP)

Communications Profile Version 2.0

Project Manager Force Projection

SFAE-CSS-FP

6501 East 11 Mile Road Warren, MI 48397

February 2016

Distribution A: Approved for Public Release ii

Table of Contents 1 Scope

1.1 Purpose

1.2 Document Overview

1.3 Current State of UGV Communications

1.4 V2 Updates

2 Source Documents

2.1 Government Documents

2.2 Non-Government Documents

3 Communications Systems Architecture

3.1 Notional Block Diagram

3.2 CCL Architecture

3.3 Air Interface/ Waveform

3.4 Prioritization of Service

3.5 Boundary Diagram

3.6 Tethered Communications

3.6.1 Interface

3.6.2 Synchronization

3.7 Security (Authentication and Encryption)

3.8 Dynamic Host Configuration Protocol (DHCP) Configuration

3.9 Comms Lost Policy

4 Requirements

4.1 Physical Interface

4.1.1 Connectors

4.1.2 Power

4.2 Logical Interface

4.2.1 Network Standard

4.2.2 Addressing Standard

4.2.3 Data Packet Handling

4.2.4 IP Addressable

iii

4.2.5 DHCP Server Configuration

4.3 Radio Link

4.3.1 Frequency Channel Selection

4.3.2 Bandwidth Selection

4.3.3 RF Transmit On/Off

4.3.4 Max Transmit Power

4.3.5 Min Transmit Power

4.3.6 Comms Lost

4.4 Security

4.4.1 Authentication

4.4.2 Encryption

4.4.3 Encryption Bypass

4.5 Radio Frequency Interference Mitigation

4.5.1 Frequency Band

4.5.2 Adjacent Channel

4.6 Waveform Requirements

4.6.1 Ground to Ground Communications Waveform

4.6.2 Data Rate

5 Off-Board Network Interoperability Attributes

5.1 Non-meshed Networks

5.1.1 Basic Point-to-Point Communications Network (OCU Platform)

5.1.2 Basic Point-to-Point Network 2 (OCU Multiple Platforms)

5.2 Meshed Networks

5.2.1 Multi-node Network (Multiple OCUs Multiple Platforms)

5.2.2 Repeater/ Relay Network (OCU Relay Platform)

5.3 Cloud Network

6 Interoperability Attributes

7 Conformance and Validation Requirements

8 Appendix A – Acronyms and Abbreviations

9 Appendix B - Discussion of Technical Topics

9.1 Networking Concepts

9.1.1 IP Addressability (Layer III)

9.1.2 Mobile Ad-hoc Network (MANET)

9.1.3 Layer II Routing (for Mesh Networking)

iv

9.1.4 Broadcast

9.1.5 Multicast

9.2 Authentication and Encryption Recommendations

9.2.1 Authentication

9.2.2 Encryption Overview

9.3 RF Transmission Waveform

9.3.1 Waveform Attributes

9.3.2 Range

9.3.3 Bandwidth

9.3.4 Data rate/ Throughput

9.3.5 Scalability

9.3.6 Latency

9.3.7 Quality of Service

9.3.8 Electronic Protection

9.4 Frequency Bands

9.4.1 Potential UGV Spectrum Utilization

9.4.2 Adaptive Code Modulation

9.4.3 Adaptive Power Control

9.4.4 Security and Encryption

9.4.5 Antennas

9.4.6 RF Interference Mitigation

9.5 Off-Board Networking

9.5.1 On-Board Network Interface Standards:

9.5.2 Addressing Standard

9.5.3 Network Topologies:

9.5.4 Data Packet Handling Standards:

9.5.5 Time Management / Time Reporting

v

List of Tables Table 2-1: Government Reference Documents Table 2-2: Non – Government Reference Documents Table 3-1: Possible Priority Scheme Table 6-1: Interoperability Attributes Table 7-1: Validation / Conformance Requirements Matrix Table 9-1: Anti replay protection Table 9-2: Example Listing of Security Requirements Based on Operations Table 9-3: Transport Stream data rate for compression with H.264 protocol Table 9-4: Frequency Bands for UGV Mobile Communications Table 9-5: RF Interference Matrix Table 9-7: Data Interface Types Table 9-8: Notional IP Address Division configuration Table 9-9: Time Management Communications Services Table 9-10: Abridged listing of Vehicle Networks

List of Figures

Figure 3-1: CCL Systems Block Architecture Figure 3-2: CCL Boundary Diagram Figure 3-3: Tethered Operations Diagram Figure 4-1: Network Layer Chart Figure 9-1: OSI and TCP/IP Reference Models Figure 9-2: Nominal data flow through radio showing encrypted layer-2 packets Figure 9-3: Details on Layer 2 Packet Structure and Encrypted Data Figure 9-4: SUAS and UGV Network View Figure 9-5: UGV Network Topology Figure 9-6: Flat Network Figure 9-7: Flat Network (Static IP) Figure 9-8: Routed Network Example (no firewall) Figure 9-9: Public / Private, Firewalled Network Topology Figure 9-10: Cloud Networking Topology vi

Change Log

Version Section Description of change V0 ---------- Initial release V1 ---------- Add list of figures, list of tables 2.1-2.2 Updated reference documents

3.4 Expanded & Changed title “Quality of Service” to “Prioritization of service”

3.6 Expanded tethered communications

4 Added mandatory /selectable / mutually exclusive tags to requirements 4 Updated requirements (additions and removals) 5 Defined Layer II Mesh Networking 6 Updated attributes based on changes to overall document 7 Updated Conformance and Validation section based on changes to overall document 8 Updated Acronyms

9.1 Rearranged sections

9.1.3 New section - Layer II Mesh Networking

9.1.5.1 New section – Multicast configuration

9.1.5.2 New section – Multicast IPv4 address mapping

9.1.5.3 New section – Multicast IPv6 address mapping

9.2 New section – Authentication & Encryption Recommendations

9.3 Expanded section – added 9.3.1 Waveform attributes

9.3.6 New section – Scalability

9.4 Updated section – Frequency bands

9.4.6.1 Updated section – Adjacent channel interference

9.4.6.2 Added section – Survivability

9.5.2 Updated and added subsections – Addressing Standard

V2 3.9 New section – Lost Comms Policy

4.2.2 Updated – Addressing Standard

4.3.6 New requirement – Lost Comms

9.3 Updated section - RF Transmission Waveform

9.5 Updated section – Off-board Networking

9.5.5 New section - Time Management / Time Reporting

1 Scope

1.1 Purpose

This document defines the interfaces and attributes of the communications link to be used on Robotics and Autonomous Systems – Ground (RAS-G). For the purposes of this document, communications interfaces to support multiple OCU and multiple platforms will be described in addition to point-to-point interface between the Operator Control Unit (OCU) and the platform that were addressed in previous versions of the Communications IOP. The intent of this document is to allow for a wide variety of product differentiation that can be adapted to multiple applications and usage models supporting unmanned ground systems. The end goal of this document product is to define the physical, electrical and logical interfaces of the radio systems to be plug and play to meet the need of the mission. It is not the intention of this document to provide all requirements necessary for implementation thereof but to provide a standard for on-board and off-board communications links of UGV systems.

The development and management of this document is now under Project Manager Force Projection (PM FP), with inputs and assistance from industry and other Government organizations. This document serves as an interface agreement between the UGV provider(s) and their interfacing radio provider(s), and is maintained and controlled by PM

FP.

1.2 Document Overview

This document provides the base concepts, architecture, requirements, and overview for the communications Interoperability Profile. The document is organized into seven sections:

1. Scope (this section)

2. Source documents

3. Communications Systems Architecture

4. Requirements

5. Off-Board Network Interoperability Attributes

6. Interoperability Attributes

7. Conformance and Validation Requirements

This document also includes an appendix (Section 9 – Appendix B) of technical discussions from the Communications IOP Work Groups with recommendations based on group discussions and trade studies.

The Common Communications Link (CCL) will be a term used throughout this document to describe the interoperable communications system between UGV platforms and OCUs. It is not the intent of this document to restrict the radio capability in any way outside common interface and operational mode.

1.3 Current State of UGV Communications

The radios used on UGVs vary from platform to platform. Some of these transmit video and telemetry with separate radios and different frequency bands, while others provide a single radio to handle all wireless communications between the controller and platform.

In addition, most radios are limited to a single frequency band making it difficult to use the radio in some countries to which these UGVs are deployed. These unique configurations of radios on unmanned systems make sustainment difficult and costly for DoD. Radios must move to a standard that is interoperable so that radios can transmit and receive communications to and from any UGV and be adaptable for deployment worldwide.

UGV radio communications are largely commercial-off-the-shelf (COTS) based, closed loop, point to point links between the UGV and the controller. Generally, the UGV communications data link can be broken down to two types; the control link and video/payload sensor link. Some UGV systems keep these data links separate by employing two radios, one to handle video and the other for control and status supporting data and audio. The video link is one-way from the UGV to the controller and requires higher data rates than the control data link.

UGVs use COTS radios due to their availability at low cost in a Small Form Factor (SFF) with low weight and low power. However, the communications system hardware is largely different from one platform to another, making support expensive and difficult in the field.

This issue is compounded by spectrum supportability and the lack of compatibility with radio frequency jamming systems that frequency bands used by COTS radios. To counter or mitigate these factors as much as possible, the UGV spectrum dependent (S- D) equipment will be required to obtain, or have, Stage 4, Equipment Spectrum Certification (ESC). Higher frequencies do not propagate as well as lower frequencies (particularly in non-Line-of-Sight (NLOS) conditions) and where low antenna heights of the controller and UGV are less than six feet above ground level. To mitigate the degradation of radio signal due to multipath while supporting high data rates, some UGV systems employ Orthogonal Frequency Division Multiplexing (OFDM) or Coded Orthogonal Frequency Division Multiplexing (COFDM) waveforms which have favorable radio performance in a multipath environment.

1.4 V2 Updates

Previous versions of the Communications IOP defined a baseline of interoperable capabilities supporting UGV systems that PM FP manages. This document, Version 2 (V2), takes the Communications IOP to the next level by adding new capabilities planned for emerging Programs of Record (PoR) and better defining communications standards.

Some of the notable added capabilities addressed in V2 of this document include Communications (Comms) Lost, Off-Board Networking, Network Timing and Waveform guidance.

2 Source Documents

The following documents are referenced within this IOP and shall be used to implement the requirements contained within the IOP.

2.1 Government Documents

MIL-STD-348B Interfaces, Radio Frequency Connector, Coaxial, Triaxial and Twinaxial MIL-STD-461 Requirements for the Control of Electromagnetic Interference

Characteristics of Subsystems and Equipment.

MIL-STD-464 ELECTROMAGNETIC ENVIRONMENTAL EFFECTS

REQUIREMENTS FOR SYSTEMS

MIL-STD-810 G Environmental Engineering Considerations and laboratory test MIL-HDBK-189 Reliability Growth Management MIL-HDBK-338B Electronic Reliability Design Handbook MIL‐PRF‐39012 General Specification For Connectors, Coaxial, Radio Frequency MIL‐PRF‐55339 General Specification For Adapters, Connectors, Coaxial, Radio

Frequency, (Between Series and Within Series) FIPS PUB 140-2 Security Requirements For Cryptographic Modules

FIPS PUB 140-2,

Annex A

Approved Security Functions for FIPS PUB 140-2

FIPS PUB 140-2,

Annex B:

Approved Protection Profiles FIPS PUB 140-2

FIPS PUB 140-2,

Annex C:

Approved Random Number Generators for FIPS PUB 140-2

FIPS PUB 140-2,

Annex D:

Approved Key Establishment Techniques for FIPS PUB 140-2

FIPS PUB 197 Advanced Encryption Standard (AES) NIST SP 800-38C Recommendation for Block Cipher Modes of Operation: The CCM

Mode for Authentication and Confidentiality NIST SP 800-38D Recommendation for Block Cipher Modes of Operation:

Galois/Counter Mode (GCM) and GMAC NIST SP 800-56A Recommendation for Pair-Wise Key Establishment Schemes

Using Discrete Logarithm Cryptography

NIST SP 800-

131A

Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths

DoDI 8500.2 Information Assurance Implementation AR 25-2 Army Regulation Information Assurance CNSSP-15 Committee for National Security System Policy No. 15 – National

Information Assurance Policy on the Use of Public Standards for Secure Sharing of Information Among National Security Systems

NSA CSS 3-9 National Security Agency Central Security Service Policy 3-9 on Cryptographic Modernization

CJCSI 6510 Committee of the Joint Chief of Staff’s Instruction 6510

Table 2-1: Government Reference Documents

2.2 Non-Government Documents

IEEE 802.11 Telecommunications and information exchange between systems, -

Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications

IEEE 802.3 Standards for Ethernet based LANs SAE AS5669A JAUS / SDP Transport Specification SAE AS5710 JAUS Core Service Set standard TIA/EIA-232/485 Electronic Industries Association/Telecommunication

Industry Association TIA/EIA-232/485 and ITU V.28 (generally referred to as 232).

USB Forum Universal Serial Bus Forum control standards RFC 791 Internet Protocol DARPA Internet Program Protocol Specification

(IPv4) RFC 2460 Internet Protocol, Version 6 (IPv6) Specification RFC 2131 Dynamic Host Configuration Protocol RFC 2132 DHCP Options and BOOTP Vendor Extensions RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) RFC 4604 Using IGMPv3 and MLDv2 for Source-Specific Multicast RFC 4861 Neighbor Discovery for IP version 6 (IPv6) RFC 4862 IPv6 Stateless Address Auto-configuration (obsoletes RFC 2462)

Table 2-2: Non – Government Reference Documents

3 Communications Systems Architecture

3.1 Notional Block Diagram

The role of the CCL is to reliably and efficiently provide a communications link between the OCU and the UGV platform, with minimal latency. It is also the role of the CCL to provide network management services in support of the communications link.

Baseline CCL systems block architecture for Communications IOP is presented below in Figure 3-1: depicts the architecture general components integrated within the CCL and serves as a baseline for the organization and discussion of technical requirements. The primary CCL subsystems contained within the block diagram are further described below.

Figure 3-1: CCL Systems Block Architecture

3.2 CCL Architecture

The CCL architecture as shown in the diagram above will support an Ethernet interface at both the OCU and the UGV Platform, and provide on-board network services. The CCL may have Dynamic Host Configuration Protocol (DHCP) server component capable of supporting either flat or routed networking. The DHCP will be allowed to traverse the entire radio system from the UGV to the OCU. This setup is also known as a bridge network. For flat or routed networks there will be no need for a Network Addressing Table (NAT), port forwarding, tunneling, or other techniques that would normally be required on the public/private network. The On-Board Network Interoperability Attribute has four selectable, non-mutually-exclusive values listed in the Attributes Table of Section 6 of this document. The DHCP server should follow the Dynamic Host Configuration Protocol as defined in RFC 2131 and DHCP Options in RFC 2132 to avoid IP address conflicts across subnets (DHCP for IPv6 is RFC 3315).

3.3 Air Interface/ Waveform

For this version of the IOP, the Air Interface/ Waveform of the Communications Link will be defined by the radio vendor to meet the requirements of the system. However, it is the goal of the Communications IOP to have a common Air Interface/ Waveform for UGV Communications. Section 9.3 of this document has further discussion on waveforms and the communications approach of this IOP.

3.4 Prioritization of Service

Different classes of traffic have different priorities. In computer networking, this is referred to as Quality of Service (QoS). Network traffic is marked to designate the different priorities. For Ethernet frames, 802.1p is used to mark traffic. In Layer III(3), the IP layer of the OSI model, DiffServ Code Points (DCSP) is used to mark traffic. Traffic must be prioritized in two distinct places:

1. Within the platform/OCU: Higher priority traffic must leave the platform/OCU before lower priority traffic.

2. Between platforms/OCUs: Higher priority traffic from one platform/OCU must access the air interface before lower priority traffic from other platforms/OCUs.

An example of a marking and prioritization standard for wireless networks is Wi-Fi Multi- Media (WMM) 802.11e, which can be useful to the system designer in setting up a prioritization scheme to meet system objectives. The table below contains a possible priority scheme based on IEEE P802.1P.

PCP Network Priority

Traffic

1 0 (lowest) Background 0 1 Best Effort 2 2 Excellent effort 3 3 Video 4 4 Voice 5 5 Platform telemetry 6 6 Platform Control 7 7 (highest) Emergency Stop / Fire control

Table 3-1: Possible Priority Scheme

This is not the only way to implement packet prioritization; it can also be performed via port priority. In the port priority technique, some ports on the network have a higher prioritization than others. As an example, the JAUS port (3794) may be given the higher priority than the port that video is sent on. This might be an easier or simpler implementation for the radio payload provider.

The actual packet prioritization and schema will be left up to the system architect.

Different missions may require different priority schemes. It is highly recommended that the radio payload support prioritization of service.

3.5 Boundary Diagram

The Boundary Diagram of the CCL presented in Figure 3-2 below provides focus areas of the radio system toward interoperability of UGV communications.

Figure 3-2: CCL Boundary Diagram

The boundary areas of the CCL define specific aspects of the UGV communications systems as follows:

• Physical/ Power Interface – Defines the physical connection points of the CCL and input power requirements.

• Logical Interface – Defines the electrical and networking aspects of the CCL.

• Radio Link – Defines the Air Interface/ Waveform of the CCL including frequency channel selection, bandwidth and transmit power.

• Radio Frequency Interference Mitigation – Defines frequency bands and resiliency to interference.

• Wireless Security – Defines the radio encryption and tamper security of the CCL.

Further discussion of Wireless Security can be found in section 4.4 and Appendix B of this document.

3.6 Tethered Communications

Some environments are not conducive to wireless communications due to high electromagnetic levels, obstacles that block radio communications or when radio silence is required. In these environments tethered communication can provide the communications link between the OCU and the UGV in place of radio. A tether can be a fiber optic or wired. A fiber tether would need a payload to convert electrical signals from the Ethernet message to light. That light would then travel through the fiber optic cable.

The light would be converted back to electrical signals which would create an Ethernet message with a similar fiber optic payload on the far end. A wired tether would physically connect the communications backbone of the OCU and platform via metal wires (e.g.

Ethernet).

Figure 3-3: Tethered Operations Diagram.

3.6.1 Interface

The tether shall be capable of interfacing with any open payload port on the platform or through an open payload port on the radio payload. (See section 4.1.1.2 Data Connectors)

3.6.2 Synchronization

Once communications is established between the OCU and UGV through the tether, the OCU shall require confirmation from the user to shutdown any radio transmissions or place the radio in stand-by mode.

3.7 Security (Authentication and Encryption)

Any new computer device connecting to the system shall be authenticated by using an authenticating protocol, i.e. Secure Shell (SSH), Hypertext Transfer Protocol Secure (HTTPS), etc.

Encryption can be embedded in the radio or can be accomplished by an encryption module interfacing between the radio and the platform or OCU communications backbone.

Encryption is not required for a tethered link but is recommended. It is important to note that without proper user authentication (over an encrypted channel) and encryption/ authentication of the payload, an intruder may be capable of taking control of the platform.

As stated above, HTTPS and SSH (when used with FIPS-approved ciphers) provide the necessary encryption to protect user authentication. SSH can also be used to tunnel TCP traffic securely. SSH is not recommended for UDP traffic. Section 9.2.1 provides further details.

3.8 Dynamic Host Configuration Protocol (DHCP) Configuration

Configuration of the DHCP server shall be open and available to the Government without the use of special tools or licenses. At minimum, the following controls shall be configurable on the server:

• Network Class

• DHCP address pool

• Subnet mask

• IP Address Lease Time

3.9 Comms Lost Policy

The platform may automatically detect and attempt to recover from situations in which communications with the controller or off-board network are lost (“comms lost”). The exact conditions for a comms lost event are not specified by the IOP, as they are likely to vary per platform, per radio, and possibly per mission. For instance, teleoperation of a platform requires low latency, high throughput communication channels to support streaming video; communications might be considered lost if latency increases above some threshold or throughput drops sufficiently that real-time video is no longer supported. On the other hand, an autonomous mission may only require that a platform ‘check-in’ periodically with very small position and status reports; in that case, communications may not be considered lost until error rates reach 100% for hours at a time. The criteria listed below are provided for illustrative purposes only, and should be considered as examples during implementation of comms lost behavior:

• Bit Error Rate > 5%

• Packet Error Rate > 2%

• Latency > 700 ms

• Liveness::ReportHeartbeatPulse message missed 7 out of last 10 queries

Also note that comms lost should be considered at both the physical or logical networking level. For example, a radio may be connected to other radios in a mesh-networking set-up, and all links may have acceptable throughputs and latency. From a physical networking perspective, the radio and comms links are healthy. However, if the platform is unable to send messages through the mesh-network to a controller or remote operator due to range or configuration errors, then comms could be considered lost at the logical level.

Finally, comms lost events should be considered as a matter of last resort, after other communication enhancement behaviors have been exhausted. For instance, if a radio supports automatic adjustment of the transmit/receive power, these settings should be managed first. If necessary, alternate or redundant communication systems could also be brought online; however, if such systems still do not meet the latency, throughput or other communication requirements for a platform/mission, a comms lost event might still be triggered.

Platform behavior during a comms lost event is dictated by the Comms Lost Policy Manager Service as specified in the SAE JAUS Profiling Rules and Custom Service Messages and Transports documents. Allowed behaviors are: 1) continue mission without comms; 2) stop the platform immediately; 3) retro-traverse on the previously executed path in an attempt to re-establish comms; and 4) return to a designated rally point.

The Comms Lost Policy Manager Service also requires specification of desired behavior when communications are restored after a comms lost event. For example, a system might be configured to retro-traverse along the previously executed path, then stop once comms are regained. At that point, the operator can elect to retry or restructure the mission to accommodate the communications dead-zone. Alternatively, a vehicle might be configured to return to a rendezvous/ rally point in a comms lost event, and continue to that location even after communications are reestablished. This “comms regained” behavior can also be used to handle temporary drop-outs when switching between primary and secondary communication systems. If communications are temporarily lost when a primary system goes down, the vehicle can be configured to wait for confirmation from the user via the secondary channel before continuing the mission.

4 Requirements

4.1 Physical Interface

4.1.1 Connectors

4.1.1.1 Data Connectors

[V2.COMM 001 (MANDATORY, SELECTABLE)] The radio or tether communication system shall employ a connector(s) defined in the Payloads IOP or provide a conversion to interface with the UGV Platform.

[V2.COMM 002 (MANDATORY, SELECTABLE)] The tether interface shall be capable of interfacing with any open payload port on the Ethernet backbone or through an open payload port on the radio.

4.1.1.2 Antenna Connectors

[V2.COMM 003 (MANDATORY, SELECTABLE)] The external antenna connector of the radio system shall use any of the following common polarity industry connectors to interface with the antenna:

• SMA-female

• TNC-female

• N type-female

[V2.COMM 004 (MANDATORY)] The antenna port of the radio system shall be weatherproof with 50 Ohm impedance supporting frequency range of 200 MHz to 6000 MHz.

4.1.2 Power

[V2.COMM 005 (MANDATORY, SELECTABLE)] The CCL input power shall be auto-ranging supporting a minimum voltage range of 10 to 28 VDC.

4.2 Logical Interface

4.2.1 Network Standard

[V2.COMM 006 (MANDATORY)] The primary on-board network standard shall be derived from the IEEE 802.3 standard for Ethernet communication.

[V2.COMM 007(SELECTABLE)] The secondary standard will be USB 2.0 or higher and/or RS232/422/485. USB standard will be derived from the USB Forum standards. The RS232/422/485 standard will be derived from EIA/TIA (232/422/485) standards.

4.2.2 Addressing Standard

[V2.COMM 008 (MANDATORY)] IPv6 standard shall be used on UGV systems and will be backward compatible to support IPv4 components. See Section 9.5.2 for details and supporting protocols for both IPv4 and IPv6.

[V2.COMM 009 (MANDATORY)] A CCL system with non-static addressing schema shall be capable of enacting Dynamic Host Configuration Protocol (DHCP) to enable the automatic IP address assignment of payloads and other Ethernet system components.

[V2.COMM 010 (MANDATORY, MUTUTALLY EXCLUSIVE)] The CCL system shall use one of the following:

[V2.COMM 010a] The CCL system, with a value of Layer III (Non-Mesh Networking) for Routing Type attribute, shall be capable of enacting Routing for IP packets between CCLs and systems they support.

[V2.COMM 010b] The CCL system, with a value of Layer II (Mesh Networking) for Routing Type attribute, shall be capable of routing Ethernet frames between CCL’s and the system they support. See Layer II Routing section 9.1.2.

*See section 9.5.3 on network topologies.

4.2.3 Data Packet Handling

[V2.COMM 011 (MANDATORY)] The CCL system shall be able to manage packets and the data contained within the IEEE 802.3 protocol standards per Figure 4-1.

DATA

DATA

Application Layer (HTTP, SMTP, Telnet, etc.)

Transport Layer (TCP, UDP, etc.)

Internet Layer (IP, ICMP, etc.)

Link Layer (Ethernet, ATM, etc.)

Se rv ic e

Application

HEADER DATA

Application

HEADER

Transport

HEADER

Application

HEADER

Transport

HEADER

Internet

HEADER

Application

HEADER

Transport

HEADER

Internet

HEADER

LInk

HEADER

User Data

Pr ot oc ol

Figure 4-1: Network Layer Chart

[V2.COMM 012 (MANDATORY)] The CCL system shall support multicast messaging.

4.2.4 IP Addressable

[V2.COMM 013 (MANDATORY, MUTUTALLY EXCLUSIVE)] The CCL system shall use one of the following:

4.2.4.1 Non-Mesh Radios

[V2.COMM 013a] The CCL radio, with a value of Layer III (Non-Mesh Networking) for Routing Type attribute, shall be IP addressable for plug and play capability. IP shall be the standard protocol for CCL Network Layer for CCL radios with this attribute.

4.2.4.2 Mesh Radios

[V2.COMM 013b] The CCL radio, with a value of Layer II (Mesh Networking) for Routing Type attribute, shall be IP addressable for configuration purposes.

4.2.5 DHCP Server Configuration

[V2.COMM 014 (MANDATORY)] All DHCP servers shall have at least the following list of configuration items available and adjustable to the Government: Network Class, DHCP address pool, Subnet Mask, and Address Lease Time. No special tools or licenses shall be required for configuration of the server.

4.3 Radio Link

4.3.1 Frequency Channel Selection

[V2.COMM 015 (MANDATORY)] The radio shall be capable of tuning across the frequency band of operation in increments of one channel bandwidth (BW) or less but not more than 5 MHz.

4.3.2 Bandwidth Selection

[V2.COMM 016 (SELECTABLE)] The radio shall be able to change the BW of the radio channel transmission through JAUS messages as defined in JAUS Profiling IOP and the Custom Service Messages & Transports document.

4.3.3 RF Transmit On/Off

[V2.COMM 017 (MANDATORY)] The radio shall be able to turn off and on RF transmissions of the communications link through JAUS messages as defined in JAUS Profiling IOP and the Custom Service Messages & Transports document. This feature does not necessarily shut down the receive operations of the radio.

4.3.4 Max Transmit Power

[V2.COMM 018 (SELECTABLE)] The user shall be able to set the maximum RF transmit power output of the radio through JAUS messages as defined in JAUS Profiling IOP and the Custom Service Messages & Transports document.

4.3.5 Min Transmit Power

[V2.COMM 019 (SELECTABLE)] The user shall be able to set the radio minimum RF transmit power output through JAUS messages as defined in JAUS Profiling IOP and the Custom Service Messages & Transports document.

4.3.6 Comms Lost

[V2.COMM 020 (SELECTABLE)] Systems that support comms lost capabilities shall do so by implementing the Lost Comms Management Interoperability Attribute as defined by the SAE JAUS Profiling Rules and Custom Service Messages and Transports documents.

4.4 Security

4.4.1 Authentication

[V2 COMM 021(MANDATORY)] Any computer device connecting to the system shall be authenticated by using an authenticating protocol, i.e. Secure Shell (SSH), Hypertext Transfer Protocol Secure (HTTPS), etc.

4.4.2 Encryption

[V2.COMM 022 (MANDATORY)] The CCL system shall include a method of encrypting the wireless communications that meets one of the following:

[V2.COMM 022a] The radio shall be validated under the NIST Cryptographic Module Validation Program (CMVP) and, at a minimum, meet level 2 security requirements of the Federal Information Processing Standard 140–2 (FIPS 140–2) to support Unclassified But Sensitive (UBS) data links. FIPS 140-2 certified solutions must be approved by Headquarter Department of the Army (HQDA) CIO/G6, per Army Regulation (AR) 25-2.

[V2.COMM 022b] The radio shall be certified by the National Security Agency (NSA) in accordance to CNSSP-15 and AR 25-2 to support Secret and below data links.

4.4.3 Encryption Bypass

[V2.COMM 023 (SELECTABLE)] Maintenance mode shall allow the encryption of the communications link to toggle on and off using JAUS messages in accordance with the Custom Service Messages & Transports document.

4.5 Radio Frequency Interference Mitigation

4.5.1 Frequency Band

[V2.COMM 024 (MANDATORY)] The radio communications system shall be capable of changing the frequency band of operation either by swapping hardware or through software commands.

[V2.COMM 025 (MANDATORY, SELECTABLE)] The primary frequency band of UGV radio systems shall be 4400 – 4940 MHz. The following frequency bands are secondary to provide spectrum agility to support worldwide operations and shall only be employed as a back-up to the primary frequency band. These secondary frequency bands include but are not limited to: 225 – 470 MHz, 902 – 928 MHz, 1250 – 1390 MHz, 2025 – 2110 MHz, 2200 – 2300 MHz, 2400 – 2500 MHz, 4940 – 4990 MHz and 5000 – 5875 MHz.

4.5.2 Adjacent Channel

[V2.COMM 026 (MANDATORY)] The radio communications link shall operate without degradation of radio communications range performance in the presence of other radios tuned to second adjacent channel frequencies operating at a distance of at least 10m.

[V2.COMM 027 (MANDATORY)] The radio communications link shall operate without degradation of radio communications range performance in the presence of other radios tuned to first adjacent channel frequencies operating at a distance of at least 150m from the area of operation.

4.6 Waveform Requirements

4.6.1 Ground to Ground Communications Waveform

The RF waveform shall be resilient in multipath environments while supporting communications data rate requirements between the OCU and platform.

4.6.2 Data Rate

[V2.COMM 028 (MANDATORY)] The radio communications video link shall support a data rate of 1.8 Mbps or better at a receive signal input level of -40 to -85 dBm throughout in a benign RF environment with a Bit Error Rate (BER) of 10-6 or better.

[V2.COMM 029 (MANDATORY)] The radio communications telemetry and audio link shall support a data rate of 200 kbps or better at a receive signal input level of -40 to -85 dBm throughout in a benign RF environment with a Bit Error Rate (BER) of 10-6 or better.

[V2.COMM 030 (MANDATORY)] The radio communications link that combines video, telemetry and audio products to a single link shall support a data rate of 2.0 Mbps or better at a receive signal input level of -40 to -85 dBm throughout in a benign RF environment with a Bit Error Rate (BER) of 10-6 or better.

5 Off-Board Network Interoperability Attributes

5.1 Non-meshed Networks

For IOP V2, the off-board networking capabilities will be limited to closed networking that does not share information outside of the OCU, platform and Remote Video terminals (RVTs). However, additional interoperability attributes will be defined in future revisions to specify CCL options. These attributes will include Public / Private networking for the sharing of information on the battlefield. Eventually, the CCL will interface with the Global Information Grid (GIG) to support ubiquitous communications.

5.1.1 Basic Point-to-Point Communications Network (OCU Platform) At its most basic level a network can consist of two non meshing end-points. In this case the two end-points are the OCU and the UGV. This point-to-point (PTP) network will be an IP-based network with the endpoints preconfigured with static IP addresses. This indicates that the OCU and the UGV are “paired”.

The network will be able to use either tethered communications, or wireless communications. It is highly recommended that a common waveform be developed for UGVs like IEEE 802.11 waveform that is robust in multipath environments and supports high data rates. A standard common waveform like IEEE 802.11 would allow radios to transmit and receive data from one vendor radio to another.

The transport used for network traffic will be identical to the Interoperability Attribute Value selected for “Transport”, which can be JUDP, JTCP, or Custom, as defined in the Overarching IOP and the JAUS Profiling Rules document.

As specified in the AS5669A document, implementations using JUDP will use the Internet Assigned Numbers Authority (IANA) specified port for primary contact port for JUDP messages.

Although a discovery mechanism is not specifically needed since the OCU and the UGV are “paired,” a discovery mechanism for the payload components on the UGV shall be incorporated. For this case, the discovery service, and protocols should follow the SAE AS5710 JAUS Core Service Set standard.

5.1.2 Basic Point-to-Point Network 2 (OCU Multiple Platforms) As an extension to the network defined in 5.1.1, a non-meshed networked OCU could be configured to select control of a UGV from multiple available UGVs. This indicates that the OCU would have the ability to choose a PTP network for a specific UGV, from a number of available PTP networks. In the realm of 802.11, the robot is the access point, and the OCU is attaching to the access point of the platform. The OCU could only control one UGV at a time. Other OCUs could be configured the same way, for the same set of UGVs. All other requirements are the same as in 5.1.1. Imaging data could also be shared with RVTs capable of receiving the radio signals from the UGV.

5.2 Meshed Networks

Mesh Networking or Mobile Ad-hoc Networking (MANET) network connections are established and broken down between compatible radios depending on the quality of the radio connections or current mission conditions. This network type is dynamic in nature and is self-forming and self-healing in terms of topology. Section 9.1.1 has more details on Mesh networking.

Messaging and service definitions will follow the SAE AS-4 JAUS standards.

Discovery of end- points (OCUs and UGVs) will follow the paradigm in SAE AS5710 JAUS Core Service Set standard. Refer to JAUS Profiling IOP and the Custom Service Messages & Transports documents on discovery service.

5.2.1 Multi-node Network (Multiple OCUs Multiple Platforms)

This network is commonly referred to as Mesh or Mobile Ad-Hoc Network (MANET). In this network, multiple OCUs and multiple platforms (devices) co-exists within the same networking space. The mesh radios that the OCU and Platform use are capable of linking to other mesh radios that are set up similarly. Each Device in the network can communicate to every other device as long as it is in the rage. In this network, information is passed or routed between devices on layer II (of the OSI reference model).

5.2.2 Repeater/ Relay Network (OCU Relay Platform)

In this network topology the OCU cannot directly communicate to the Platform because of an obstruction or separation distance. Therefore one or more devices in must be placed in between the OCU and platform to enable their communication. The device(s) in between the OCU and platform will relay the messages from the OCU to the Platform and from the Platform to the OCU. This topology can be used to extend the communications range of the system or it can be used in NLOS missions. Mesh enabled radios would be capable of this topology. The devices that are in between the OCU and Platform may be unintelligent communication bricks that contain a mesh radio, another platform with a mesh enabled radio, or a combination of the two. It is possible to establish a Repeater / Relay net without Mesh networking radios but such specifications are not in the scope of this document.

5.3 Cloud Network

Cloud networks are not within the scope of IOP V2. However, following the paradigm of the World Wide Web, OCUs and UGVs can be part of a larger network without dedicated channels of communications as in previous sections. This type of network will be IP-based, and can use either statically assigned IP addresses or DHCP. It can be a combination of wired and wireless nodes that comprise the overall network. All nodes should include a standard Ethernet adaptor for testing purposes. Both network mentioned above (mesh and non-meshed) can be connected to a larger network via a router that contains a Firewall and Network Address Translation (NAT).

6 Interoperability Attributes

The following table specifies the set of Interoperability Attributes defined within this IOP.

These attributes are used to specify required interoperable capabilities to be implemented within a robotic system. The specification of an Interoperability Attribute may imply additional requirements defined in other portions of the IOP.

Attribute Paragraph Title Values Waveform 3.3 Air Interface/ Waveform

Type

OFDM,

COFDM,

DDL,

CDL,

None

OCU to Platform Communications

3.5 - 3.6 Radio and Tethered Communications

CCL,

Optical Tether, Wired Tether

RF Connector

(V2.COMM 003)

4.1.1.2 Antenna Connectors SMA-female, TNC-female , N type-female, None

Input Power

(V2.COMM 005)

4.1.2 Power Auto-sense 10-28 VDC, Fixed

Network Interface Standard

(V2.COMM 007)

4.2.1 Network Standard Ethernet, USB 2.0, RS232, RS422, RS485

IP Addressing

(V2.COMM 008)

4.2.2 Addressing Standard IPv4, IPv6

Routing Type (between radios)

(V2.COMM 010)

4.2.2 Radio Routing Type Layer III, Layer II

On-board Network

(V2.COMM 011)

4.2.3 Data Packet Handling Flat Network, Routed Network, None

Channel Bandwidth Agility

(V2.COMM 016)

4.3.2 Bandwidth Selection Adjustable, Fixed

Transmit Power

(V2.COMM 018)

4.3.4 Max Transmit Power Adjustable, Fixed

Transmit Power

(V2.COMM 019)

4.3.5 Min Transmit Power Adjustable, Fixed

Wireless Encryption

(V2.COMM 022)

4.4.2 Encryption FIPS 140-2, NSA Certified

Attribute Paragraph Title Values Encryption Bypass

(V2.COMM 023)

4.4.3 Encryption Bypass Supported, Not supported

Frequency Band Selectable

(V2.COMM 025)

4.5.1 Frequency Band Selection 4400 – 4940 MHz, 225 – 470 MHz, 902 – 928 MHz, 1250 – 1390 MHz, 2025 – 2110 MHz, 2200 – 2300 MHz, 2400 – 2500 MHz, 4940 – 4990 MHz, 5000 – 5875 MHz, other

Data Rate

(V2.COMM 030 -

031)

4.6.2 Data Rate >1.8 Mbps for video, >200 kbps for telemetry, >2.0 Mbps for video and telemetry None

Off-Board Network Attributes

5. Network Interoperability Attributes

OCU/Platform PTP paired, OCU/Platform PTP independent, OCU/Repeater/Platfor m, Mesh/MANET Network, None

Table 6-1: Interoperability Attributes

7 Conformance and Validation Requirements

The table below specifies the conformance requirements associated with this IOP. This matrix maps product unique identifiers (PUIs) to applicable IOP requirements, paragraph numbers, titles/subtitles, and planned verification methods. System Developers, Conformance and Verification Testers, and Acquisition Managers can use this matrix to help validate conformant implementations to this IOP. The following verification methods are defined:

Analysis – Analysis is an element of verification that uses established technical or mathematical models or simulations, algorithms, charts, graphs, circuit diagrams, or other scientific principles and procedures to provide evidence that stated requirements were met.

Examination – Examination is an element of verification that is generally nondestructive and typically includes the use of sight, hearing, smell, touch, and taste; simple physical manipulation; and mechanical and electrical gauging and measurement.

Demonstration – Demonstration is an element of verification that involves the actual operation of an item to provide evidence that the required functions were accomplished under specific scenarios. The items may be instrumented and performance monitored.

Test – Test is an element of verification in which scientific principles and procedures are applied to determine the properties or functional capabilities of items.

PUI

(COMM) Paragraph (U) Title Verification Method

A E D T N/A 001 4.1.1.1 U Data Connector (Platform) A 002 4.1.1.1 U Tether Interface A 003 4.1.1.2 U Antenna Connector E 004 4.1.1.2 U Antenna port A 005 4.1.2 U Power D 006 4.2.1 U Network Standard - Primary A 007 4.2.1 U Network Standard - Secondary A 008 4.2.2 U Addressing Standard – IPv6 A 009 4.2.2 U Addressing Standard –DHCP A 010a 4.2.2 U Addressing Standard – Layer III A 010b 4.2.2 U Addressing Standard – Layer II A 011 4.2.3 U Data Packet Handling A 012 4.2.3 U Multicast Messaging A 013a 4.2.4.1 U IP Addressable – Non-Mesh

Radios D

013b 4.2.4.2 U IP Addressable – Mesh Radios D 014 4.2.5 U CCL Network Configuration D

PUI

(COMM) Paragraph (U) Title Verification Method

A E D T N/A 015 4.3.1 U Frequency Channel Selection D 016 4.3.2 U Bandwidth Selection D 017 4.3.3 U RF Transmit On/ Off D 018 4.3.4 U Max Transmit Power D 019 4.3.5 U Min Transmit Power D 020 4.3.6 U Comms Lost D 021 4.4.1 U Authentication A 022a 4.4.2 U Encryption – Validated under

CMVP

A

022b 4.4.2 U Encryption – Certified by NSA A 023 4.4.3 U Encryption Bypass A 024 4.5.1 U Frequency Band Selection D 025 4.5.1 U Frequency Band Selection –

4400-4940 MHz D

026 4.5.2 U Adjacent Channel – second adjacent

D

027 4.5.2 U Adjacent Channel – first adjacent D 028 4.6.2 U Data Rate – Video link D 029 4.6.2 U Data Rate – Telemetry/ Audio link D 030 4.6.2 U Data Rate – Total link D

Table 7-1: Validation / Conformance Requirements Matrix

8 Appendix A – Acronyms and Abbreviations

ACM Adaptive Code Modulation APC Adaptive Power Control ATPC Automatic Transmit Power Control BLOS Beyond Line of Sight BW Bandwidth dB Decibels dBc Decibels referenced to carrier C2 Command and Control CCL Common Communications Link CDMA Code division multiple access COFDM Coded Orthogonal Frequency Division Multiplexing COMSEC Communications Security CONUS Continental US COTS Commercial Off-the-Shelf CREW Counter RCIED (Radio-Controlled Improvised Explosive Device)

Electronic Warfare DHCP Dynamic Host Configuration Protocol DISA Defense Information Systems Agency DMZ Demilitarized Zone DoD Department of Defense DSSS Direct-Sequence Spread Spectrum ESC Equipment Spectrum Certification FDD Frequency Division Duplex FEC Forward Error Correction GHz Gigahertz GIG Global Information Grid IA Information Assurance IANA Internet Assigned Numbers Authority IAW In Accordance With ICMP Internet Control Message Protocol IGMP Internet Group Management Protocol IETF Internet Engineering Task Force IF Intermediate Frequency IOP Interoperability Profile

IP Internet Protocol JAUS Joint Architecture for Unmanned Systems JTCP JAUS Transmission Control Protocol JUDP JAUS User Datagram Protocol kbps Kilo-bits per second kHz Kilo-Hertz LI Logical Interface LOS Line of Sight MANET Mobile Ad-hoc Network MBU Mobility Base Unit Mbps Megabits per second MC/PM Master Controller/ Payload Manager MHz Megahertz MIMO Multiple Input Multiple Output MLD Multicast Listener Discovery MMCX Micro-Miniature Coaxial ms millisecond NAT Network Address Translation Table NLOS Non- Line of Sight NSA National Security Agency OCONUS Outside Continental US OCU Operator Control Unit OFDM Orthogonal Frequency Division Multiplexing OSI Open Systems Interconnection P2I Physical/ Power Interface PCP Priority Code Point POE Power Over Ethernet PTP Point-to-Point PUI Product Unique Identifier QoS Quality of Service RAS-G Robotics and Autonomous Systems - Ground RCIED Radio Controlled Improvised Explosive Device RF Radio Frequency RFC Request for Comments RFIM Radio Frequency Interference Mitigation RL Radio Link

RS Recommended Standard RVT Remote Video Terminal SDP Session Description Protocol SDR Software Defined Radio SFF Small Form Factor SMA Sub-Miniature version A SWaP Size, Weight, and Power TCP Transmission Control Protocol TDD Time Division Duplex TNC Threaded Neill-Concelman UAV Unmanned Air Vehicle UDP User Datagram Protocol UGV Unmanned Ground Vehicle UMS Unmanned Systems USB Universal Serial Bus V0 Version 0 VDC Voltage Direct Current VGA Video Graphics Array VSWR Voltage Standing Wave Ratio WEP Wired Equivalent Privacy WG Working Group WPA Wi-Fi Protected Access WS Wireless Security

9 Appendix B - Discussion of Technical Topics

9.1 Networking Concepts

9.1.1 IP Addressability (Layer III)

An IP-based network layer provides flexibility in the data link (layer II) and physical layers used for data transport whether wireless (i.e., digital radio or laser link) or hard-wire (copper or fiber-optic). In addition, IP-based systems have gained wide acceptance in many sectors and as a result, many COTS-based solutions are exploitable to reduce cost.

IP-based communications put very few limits on future systems because the bandwidth capabilities of the data link and physical layers continue to increase.

9.1.2 Mobile Ad-hoc Network (MANET)

A mobile ad hoc network (MANET), sometimes called a mobile mesh network, is a self-configuring network of mobile devices connected by wireless link. Each device in a MANET is free to move independently in any direction, and will therefore change its links to other devices as it moves within the net. Each MANET radio must be capable of forwarding traffic unrelated to its own use, and therefore be a router. The primary challenge in building a MANET is equipping each device to continuously maintain the information required to properly route traffic.

9.1.3 Layer II Routing (for Mesh Networking)

The radio nodes of the mesh network shall use Layer II (2) for IP packet / message routing (RFC 1122 and RFC 1123). That is, routing at the Data link layer of the seven layer OSI model. In the TCP/IP reference model this is layer I (Host-to-Network Layer). One of the advantages of Layer II routing is that the radio nodes get abstracted from the devices’ (OCUs’ and MBUs’) network configuration. The radio nodes themselves do not need a particular IP address assignment since packets from the devices are routed based on the hardware MAC addresses of the devices connected to the network. In other words, a network of radios supporting Layer II routing appears logically to the devices as a simple Ethernet switch. Each radio node behaves as an Ethernet port for this logical Ethernet switch. Naturally the radio network needs to know the MAC address of the devices and to which Ethernet port (radio) they are attached to. This is resolved by the Address Resolution Protocol (ARP) explained in RFC 1122 and RFC 826.

Example 1: let OCU and MBU be two devices on the same subnet S. If the OCU and the MBU are operable by connecting them to a common Ethernet switch then they would also be operable by connecting them to any two radios that are part of the same mesh network. No IP configurations should be necessary on the radios to reflect the subnet S.

Example 2: let OCU and MBU be two devices on the same subnet S1. Assume MBU has multiple sensors in subnet S1. In this case, the OCU may be connected to an arbitrary radio on the network and the MBU and its sensors to another arbitrary node in the network. The OCU has direct access to the sensors on the MBU via a fully flat network.

Example 3: let OCU and MBU be two devices on the same subnet S1. Assume MBU has multiple sensors in subnet S2.