2010-01-31_RFNE_Standard_Experimental_v0.7.pdf

integrated Network Enhanced Telemetry (iNET)

RF Network Element Technical Group

RF Network Element Standard

Maturity Level 1 – Experimental

Version 0.7 For the general information of the T&E technical community, this Maturity Level 1 Experimental version of the RF

Network Element Standard contains a significant amount of background and descriptive material. As this standard is matured to the Proposed Level, it is anticipated that such material will be condensed or eliminated.

January 31, 2010

Environment: Aeronautical Environment

Approved By:

Hank Owen, RFNE TG Co-chairman

Jim Kaba, RFNE TG Co-chairman

Daniel Skelley iNET Chief Engineer

Distribution Statement C Distribution authorized to U.S. Government Agencies and their contractors for the purposes of reviewing and commenting on this working draft. Administrative protections are employed to limit premature dissemination. Other requests for this document shall be referred to the RF Network Element Standards Area Director or the iNET Program Office.

RF Network Element Standard, Experimental Version 0.7

See Distribution Statement C on cover page ii

Revision History

Version Date Sections

Affected

Comments

0.0.1 05/18/09 All Document Created

0.0.2 05/28/09 All Document initial distribution

0.0.3 07/02/09 All Internal release to team

0.1.0 07/21/09 All Internal release

0.2.0 08/03/09 All Internal release

0.3.0 08/27/09 All Internal release

0.4.0 09/04/09 All Internal release

0.5.0 09/10/09 All Prepare for public release

0.6.0 01/22/2010 All Internal release

0.7 01/31/2010 All Prepare for public release

See Distribution Statement C on cover page iii

Table of Contents

1 Introduction

1.1 Background 1

1.2 Responsibility

1.3 General

1.3.1 Radio Access Network Segment Overview

1.3.2 Ground Segment Overview

1.3.3 RF Network Element Overview

1.4 Scope

2 Applicable Documents

2.1 Government Documents

2.1.1 Specifications

2.1.2 Standards

2.2 Non-Government Documents

2.2.1 Specifications

2.2.2 Standards

3 Definitions and Abbreviations

3.1 Definitions

3.2 Abbreviations and Acronyms

3.3 Standards Key Words

3.4 Octet and Bit Ordering

4 General Principles

5 Overview

5.1 Functional Components of the RFNE

5.2 Basic Themes

5.2.1 Radio Links

5.2.2 Radio Bearers

5.2.3 Service Level Profiles

5.3 RFNE External Interfaces

5.3.1 IRFNE-UTA (Interface between RFNE and User Test Article)

5.3.2 IRFNE-RTA (Interface between RFNE and the Radio on the TA)

5.3.3 IRFNE-MTA (Management Interface of RFNE at the TA)

5.3.4 IRFNE-UGS (Interface between RFNE and User Ground Segment)

5.3.5 IRFNE-RGS (Interface between RFNE and the Radio on the Ground)

5.3.6 IRFNE-MGS (Management Interface of RFNE at the Ground)

See Distribution Statement C on cover page iv

5.3.7 IRFNE-GSR (Interface between the RFNE and the Remote Ground Segment)

5.4 RFNE Internal Interfaces

5.5 RFNE Control Message Protocols

5.6 Quality of Service

5.6.1 Quality of Service (QoS)

5.6.2 DiffServ

6 RFNE Common Message Format

6.1 RFNE Common Message Structure

6.1.1 RFNE Message Sequence Flow

6.2 RFNE Common Message Format

6.3 RFNE Command Message Format

6.4 RFNE Response Message Format

6.5 RFNE Ack Message Format

6.6 RFNE Message Payload TLV Format

7 RFNE External Interfaces

7.1 Network Payload

7.1.1 NetworkPayload-G

7.1.2 NetworkPayload-TA

7.2 Radio Payload

7.2.1 RadioPayload-G

7.2.2 RadioPayload-TA

7.3 Link Management to Radio Link Agent (LM-LA)

7.3.1 LM-LA-G

7.3.2 LM-LA-TA

7.4 RF Network Management to Radio Agent (RFNM-RA)

7.4.1 RFNM-RA-G

7.4.2 RFNM-RA-TA

7.5 RF Network Management to SST Tx/Rx Configuration/Control Interface (RFNM-SST)

7.5.1 RFNM-SST-G

7.5.2 RFNM-SST-TA

7.6 RF Network Management to System Management (RFNM-SM)

7.6.1 RFNM-SM-G

7.6.2 RFNM-SM-TA

7.6.3 RFNM-RFNM-G

7.7 RF Network Management to Network Operations (RFNM-NO)

8 RFNE Internal Interfaces

See Distribution Statement C on cover page v

8.1 Link Management to Queue Management (LM-QM)

8.1.1 LM-QM-G

8.1.2 LM-QM-TA

8.2 RFNM to Link Management (RFNM-LM)

8.2.1 RFNM-LM-G

8.2.2 RFNM-LM-TA

8.3 RFNM to Queue Management (RFNM-QM)

8.3.1 RFNM-QM-G

8.3.2 RFNM-QM-TA

8.4 RFNM to Connection Control (RFNM-CC)

8.4.1 RFNM-CC-G

8.4.2 RFNM-CC-TA

9 RFNE Control Message Protocols

9.1 Link Management Protocols

9.1.1 Radio Link Establishment

9.1.2 Radio Link Release

9.1.3 Radio Link Capacity Management

9.1.4 Intra TmNS Handover

9.1.5 Inter TmNS Handover

9.1.6 Power Management

9.1.7 Configuration and Status

9.1.8 Message Descriptions

9.2 RF Network Management Protocols

9.2.1 GS RFNM to TA RFNM

9.2.2 GS RFNM to local GS RFNM

9.2.3 GS RFNM to remote GS RFNM

9.3 Connection Control Protocols

9.3.1 GS-TA

9.3.2 GS – GS Test Enclave

10 General Networking Protocols and Services

10.1 Networking Protocols

10.1.1 Data Link Protocols

10.1.2 Network Protocols

10.1.3 Network Routing Protocols

10.1.4 Transport Protocols

10.2 Network Services

10.2.1 Address Resolution and Configuration

10.2.2 Name Services

10.2.3 File Transfer

10.2.4 System Management Interfaces

See Distribution Statement C on cover page vi

10.3 Time Synchronization

10.3.1 Network Time Synchronization Interfaces

11 Security and Authentication (Information Assurance)

11.1 RFNE Support of Radio Encryption

11.2 RFNE Support of Radio Authentication

12 APPENDIX A - RFNE Supported FunctionS

13 APPENDIX B - IETF RFC Listing

14 APPENDIX C - Service Level Profiles: Network System View

15 Index

List of Figures

Figure 1-1. Relationship of the TmNS Standards

Figure 1-2. TmNS Networks

Figure 1-3. Radio Access Network Segment Overview

Figure 1-4 RF Network Element Functions

Figure 1-5. RF Network Element Standard Interface and Protocol Scope

Figure 5-1 Overview of RAN Segment and RF Network Element

Figure 5-2. Examples of Different Radio Bearer Configurations

Figure 5-3. Relationship of SLPs to Radio Bearers

Figure 5-4. Data flow and SLP usage within the RFNE

Figure 5-5. RFNE External Interfaces (canonical view)

Figure 5-6. RFNE External Interfaces (expanded context)

Figure 5-7. Link Management Control Message Protocol

Figure 5-8. RF Network Management Control Message Protocol

Figure 5-9. Connection Control Message Protocol

Figure 5-10. TmNS traffic mapping to DSCPs

Figure 6-1. Complete RFNE Command Message

Figure 6-2. Complete RFNE Response Message

Figure 6-3. Complete RFNE Ack Message

Figure 6-4. RFNE Message Sequence Flow

Figure 6-5. RFNE Common Message Format

Figure 6-6. RFNE Command Message Format

See Distribution Statement C on cover page vii

Figure 6-7. RFNE Response Message Format

Figure 6-8. RFNE Ack Message Format

Figure 7-1. RF Network Element External Interfaces

Figure 8-1. RF Network Element Internal Interfaces

Figure 9-1. Example Link Management Protocol Sequence Diagram

Figure 9-2. Sequence Diagram for Link Establishment

Figure 9-3: Sequence Diagram for Link Release

Figure 9-4. Sequence Diagram for Resource Assignment to a TA

Figure 9-5. Sequence Diagram for Resource Assignment to an RL

Figure 9-6. Intra TmNS Handover Message Sequence

Figure 9-7. Sequence Diagram for Power Management

List of Tables

Table 6-1. Format Summary Matrix

Table 6-2. RFNE Common Message Header Fields

Table 6-3. Interface/Protocol Field Values

Table 6-4. RFNE Command Message Fields

Table 6-5. RFNE Response Message Fields

Table 6-6. RFNE Ack Message Fields

Table 6-7. RFNE Ack Status Field Values

Table 6-8. RFNE Message TLV Format

Table 7-1: LM-LA-GS (Ground Station Variant) Message List

Table 7-2: LM-LA-TA (Test Article Variant) Message List

Table 7-3: Summary of RFNM-RA-G Radio Variables

Table 7-4: Summary of RFNM-RA-TA Radio Configuration Parameters

Table 7-5 Command Field Values for RFNM-NO Interface Command Messages

Table 7-6 Response Field Values for RFNM-NO Interface Response Messages

Table 7-7. TLV Values for Mission SLP Parameters

Table 7-8. TLV Values for Bearer SLP Parameters

Table 8-1 Command Field Values for LM-QM Interface Command Messages

See Distribution Statement C on cover page viii

Table 8-2 Response Field Values for LM-QM Interface Response Messages

Table 8-3 Command Field Values for RFNM-LM Interface Command Messages

Table 8-4 Response Field Values for RFNM-LM Interface Response Messages

Table 8-5 Command Field Values for RFNM-QM Interface Command Messages

Table 8-6 Response Field Values for RFNM-QM Interface Response Messages

Table 8-7 Command Field Values for RFNM-CC Interface Command Messages

Table 8-8 Response Field Values for RFNM-CC Interface Response Messages

Table 9-1. Message Paths Associated with Queue Status Message

Table 9-2. Message Paths Associated with TxOp Assignment Message

Table 9-3. Message Paths Associated with for Power Adjustment Message for Power Management

Table 9-4 Command Field Values for RFNM-RFNM Protocol Command Messages

Table 9-5 Response Field Values for RFNM-RFNM Protocol Response Messages

RF Network Element Standard, version 0.7

See Distribution Statement C on cover page 1

1 INTRODUCTION

The Telemetry Network System (TmNS) is governed by a collection of standards documents. This Radio

Frequency (RF) Network Element Standard provides a document that vendors and range users of TmNS equipment shall reference to ensure interoperability using RF network communications among Test Articles and Ground

Control Stations across multiple ranges. The standards in this document are intended to provide a referenced set of technologies and protocols, and TmNS-specific well-defined interfaces and control message protocols governing the shared RF network. This document is not intended to provide operational details for the Test Articles or

Ground Control Stations.

The RF Network Element Standard, together with the Communication Link Standard, defines the network infrastructure over which Test Articles, governed by the Test Article Standard, and Ground Control Stations communicate using the RF network. The RF Network Element Standard is further augmented by the System

Management standard for system management of RF network components. The Metadata Standard provides metadata descriptions used by the System Management Standard. The RF Network Element Standard, along with the other standards shown in Figure 1-1, provides a complete framework for a TmNS.

Figure 1-1. Relationship of the TmNS Standards

1.1 Background

The RF Network Element (RFNE) Technical Group created this document. The RFNE Technical Group (RFNE

TG) included the iNET Architecture team (including government support contractors from Sarnoff Corporation), additional government personnel and support contractors from Edwards AFB and NAS Patuxent River, and government support contractors from the Jet Propulsion Laboratory, LinQuest Corporation, and Southwest

Research Institute involved in development of the iNET Communications Link, Test Article, System Management

See Distribution Statement C on cover page 2 and Metadata standards. This standard was produced through the process of collaborative development. The format of this document is similar to other iNET standard documents being developed. In addition, a companion

Rationale document was created to aid understanding of this standard.

1.2 Responsibility

The RF Network Element Technical Group is responsible for the content and changes to this standard. The government shall not be responsible for any ambiguities in this document. If any ambiguities are identified, the burden is on the user of the standard to bring the ambiguities to the attention of the government. Additional copies of this document may be obtained from the iNET Program Web Portal (https://www.inetprogram.org).

1.3 General

Architecturally, the TmNS is divided into three segments: the Test Article Segment (TAS), the Ground Station

Segment (GSS) and the Radio Access Network Segment (RANS); along with two supporting entities: System

Management and Metadata. The TmNS focuses primarily on two networks: the Vehicle Network (vNET) and

Radio Access Network (RAN). The RAN has the ability to control one or more radios which are the heart of the

Radio Frequency (RF) communications. The Ground Network (gNET) that interfaces into the RAN varies from range to range and thus the TmNS provides an interface to the gNET. The main functionality of the TmNS is moving data. The vNET transfers data between peripherals (end nodes) on a test article and the RAN. The RAN transfers data between the vNET and gNET. Generally, these networks operate autonomously. Additionally, the

TmNS supports many different types of applications and peripherals that reside outside the TmNS but have an integral role in the operation of the TmNS. System Management is used across the TmNS to manage network devices that provide fault, configuration, utilization, performance, and security management. The applications (or managers) in the system communicate with agents in managed devices such as peripherals and network devices. In general, Metadata is used to describe configurations and measurements. A simplified illustration of the TmNS and the supporting elements with representative users of the networks is shown in Figure 1-2.

Vehicle

Network Ground Network

Ground Network

R e p re s e n ta tiv e A p p lic a tio n s

Metadata

System Management

R e p re s e n ta ti v e P e ri p h e ra ls

Test Article

Segment

Ground Station

Segment

Radio

N e tw o rk

Radio AccessN e tw o rk

Radio Access

Radio

N e tw o rk

Radio AccessN e tw o rk

Radio Access

Radio Access Network

Segment

Figure 1-2. TmNS Networks

1.3.1 Radio Access Network Segment Overview

Architecturally, the RAN Segment is divided into three elements:

• RF Network Element (RFNE)

See Distribution Statement C on cover page 3

• Radio Element

• Antenna Element.

On a Test Article, an RFNE instance will be connected to the vNET by one or more Ethernet connections and will be connected to one or more Radios by both Ethernet connections and dedicated high speed connections.

On the ground, components of the RFNE will be physically distributed (see Section 5 below). An overview illustration of the RAN Segment is provided in Figure 1-3.

In the Aeronautical environment, the RAN segment will support the sharing of one RF frequency by multiple tests using a TDMA (Time Division Multiple Access) scheme. The Communication Link Standard [1] for the Radio

Element defines the TDMA epoch and other detailed information such as the format and content of Link Layer

Control Messages (LLCMs) for Radio-to-Radio communications. The RFNE standard defines the protocols for exchanging TLVs contained in LLCMs (see Section 9 below).

The RAN segment supports mobility of a Test Article during a test through handover and relay operation.

• The RAN segment supports a Test Article moving from one antenna to another while continuing to participate in the same TDMA regime on the same frequency (intra-TmNS handover). The RAN segment also supports a Test Article moving from one antenna to another and switching to a different

TDMA regime on a different frequency (inter-TmNS handover).

• The RAN segment supports relay operation for a Test Article required to operate beyond the limit of one Radio-to-Radio link in two manners:

o A Test Article may be handed off to an antenna that is remote from the Mission Control Facility so as to require additional network links to the range network.

o A second aircraft, configured as a Test Article but not being tested, may stay in range of an antenna on the ground and serve to relay wireless communications to/from the Test Article under test.

The RAN segment supports Quality of Service (QoS) for distinguishing priorities among different Test Articles and for distinguishing different QoS levels within a test. Within a test, different QoS levels can be provided for different data streams being telemetered from Test Article to Ground and/or for different command-and-response actions initiated on the Ground. In the RAN segment, support for Quality of Service is primarily provided by the

RFNE, which makes decisions on the order in which packets will be presented to the Radio for transmission over a shared TDMA channel.

The RAN segment supports data delivery for tests with diverse security constraints that require Test Article and ground networks to be divided into red and black network segments by security devices such as High Assurance

Internet Protocol Encryptor (HAIPE) interfaces. For some ranges and some tests, it may be possible to use guards or data diodes in the ground network. The RFNE provides multiple flexible capacity management and QoS approaches to allow basic functionality for constrained security conditions and improved performance when security conditions are less constrained.

The RAN segment supports cross-band operation of Test Articles using spectrum allocated from the L, S and C telemetry bands concurrently. The RFNE can provide multiple physical network uplink or downlink paths through the use of multiple radios on the Test Articles and in associated Ground Stations.

For the purpose of this standard, a test is considered to be an activity that may last for multiple hours, that involves a Test Article communicating with a Mission Control Room using the RF Network, and that may include multiple test maneuvers (e.g., flutter maneuvers). Each test is coordinated by a range with the program responsible for the system-under-test, the aircraft that is a Test Article. A range may support multiple different tests concurrently, e.g., test programs for a JSF, an F18, and a helicopter may be operating from different control rooms concurrently.

See Distribution Statement C on cover page 4

RF Network Element (Ground):

Link Management

Queue Management, Traffic Engineering Queues

Network Infrastructure (switches, routers, etc.)

Connection Control

RF Network Management

RFNE (TA)

Radio

Radio

Radio Radio

Ground Network

Control Room 1 Control Room 2

Radio

Network

Operations

Center

Vehicle Network

Test Article 1

(Hangar) Test Article 2

(Runway)

Test

Article 3 Test

Article 4

Test Article 5

Test Article 4

RFNE Detail

RAN Segment

Scope:

- RFNE

- Radio

- Antenna

RAN Segment Boundary

Handovers Expected as TA goes from hangar to runway and then airborne

RFNE Supporting

Remote Antenna Site

Radio

Figure 1-3. Radio Access Network Segment Overview

1.3.2 Ground Segment Overview

For the purpose of this standard, the Ground Segment is considered to be composed of:

• One or more Mission Control Facilities (MCFs) that contain one or more blackside control rooms and one or more redside test control enclaves

• Antenna sites that are collocated with or remote from an MCF and are used with Test Articles in flight

• Antenna sites that are used with Test Articles in a hangar or on the tarmac

• A ground network that connects antenna sites with an MCF – A TmNS may share an existing ground network on a range, or a range may decide to install a ground network dedicated to TmNS operation.

The ground network may be a wired network and/or it may include microwave links.

See Distribution Statement C on cover page 5

On the ground, an instance of a Radio Element of the RAN Segment is expected to be installed at an antenna site.

Multiple Radios on the ground will communicate with one RFNE instance using a shared ground network.

1.3.3 RF Network Element Overview

The functions of the RFNE (Figure 1-4) include:

• Link Management (LM) – Responsible for optimized control and coordination of radio operation across multiple radios in a network. On the ground, the LM is responsible for the role of TDMA controller to allocate slots for transmission among all uplinks and downlinks.

• Traffic Engineering (TE) Queue(s) – Responsible for control of queue structures and associated mechanisms used to implement optimized QoS (Quality of Service) performance. TE Queues transmit packets to Radio and to vNET/gNET according to QoS constraints currently in effect during a test.

Packets may be either:

• Payload packets containing user/application data being transmitted between vNET and gNET

• Control packets containing information for control of RFNE components, Radios, or Antennas.

• Queue Management (QM) – Responsible for providing a common interface (i.e., wrapper) to the

Traffic Engineering (TE) Queues, which may be physically realized on different vendors’ commercial equipment.

• Connection Control (CC) – Allows for additional control of establishment, maintenance, and termination of data stream connections over a radio network

• RF Network Management – Responsible for management of the components of the Radio Access

Network and for supporting Consolidated Management of the TmNS defined in the System

Management Standard [3].

Figure 1-4 RF Network Element Functions

Appendix Section 12 contains a more detailed description of functionality associated with the RF Network

Element.

1.4 Scope

This standard establishes the requirements for the operation of the RF Network Element of the TmNS architecture.

It encompasses the physical, electrical, protocol, and interface aspects of the RFNE to ensure interoperability with other elements of the Radio Access Network and the TmNS as a whole. Figure 1-5 provides an overview of the interfaces and protocols specified in this standard document. This standard defines RFNE External Interfaces, RFNE Internal Interfaces, and RFNE Control Message Protocols.

See Distribution Statement C on cover page 6

Figure 1-5 a) illustrates the external interfaces of the RFNE. These are the interfaces that specify logical and, in some cases, physical interconnection details that define communication between the functional components of the

RF Network Element and those contained in other elements of the TmNS. The “user” interface details the connectivity between the RFNE and the “users” of the Radio Access Network, typically peripherals, test resources and test applications in both Test Articles and ground Control Stations, as well as the networks that connect them to the RFNE. Radio Interfaces define the interconnectivity details between the RF Network Element and the Radio

Element that together form the TmNS wireless network infrastructure. Additional interfaces define the communication between the RFNE and external TmNS management systems, as well as communication between separate instantiations of RF Network Element to coordinate use of resources both within a range and between neighboring ranges. These RFNE External Interfaces are introduced in Section 5.3 and described in detail in

Section 7. The functional components of the RF Network Element are described in Appendix Section 12.

Figure 1-5 b) illustrates the internal interfaces of the RFNE. These are the interfaces that specify logical interconnection details that define communication between the functional components that form the RF Network

Element. While RFNE functionality may exist within both the Test Article and ground portion of the Radio Access network at levels of complexity that may vary from Test Article to Test Article or range to range, the RFNE

Internal Interfaces define the communication within a given RFNE instance. These RFNE Internal Interfaces are introduced in Section 5.4 and described in detail in Section 8.

Figure 1-5 c) illustrates the control message protocols of the RFNE. These control message protocols define the messages and rules for message flow between multiple functional components with similar functionality within the

Figure 1-5. RF Network Element Standard Interface and Protocol Scope

See Distribution Statement C on cover page 7

RFNE. The RFNE Control Message Protocols are used when a logical connection is needed between two similar functional entities on different physical portions of an RFNE (e.g., one within a TA and another on the ground) to enable or support the coordination of some form of distributed operation. These RFNE Control Message Protocols are introduced in Section 5.5 and described in detail in Section 9.

The RFNE External Interfaces, Internal Interfaces and Control Message Protocols covered in this standard are provided with the primary goal of ensuring interoperability between multiple independent Test Article RFNE instantiations sharing network resources that are coordinated by a common Range RFNE instantiation. This will also ensure that a Test Article is also interoperable across multiple different independent RFNE instantiations at different ranges. A secondary goal of the RFNE standard is to ensure interoperability between TmNS components manufactured by different vendors or provided through COTS (Commercial Off-The-Shelf) solutions. It is anticipated that vendors, specific test programs and ranges may implement or procure solutions that posses differing levels of integration and that provide differing amounts of RFNE functionality. In these cases, if a given

External or Internal interface is not exposed to other parts of the TmNS for interoperability purposes, then the vendor is free to deviate from those specific interface standards so long as the required overall component functionality is met.

See Distribution Statement C on cover page 8

2 APPLICABLE DOCUMENTS

The following documents are referenced in the text of this standard. Unless otherwise noted, all standards referenced have equal precedence. Information contained in this standard takes precedence over all referenced documents.

2.1 Government Documents

2.1.1 Specifications

No government specifications are currently referenced by this standard.

2.1.2 Standards

iNET Standards:

• [1] Communication Link Standard, Proposed Version 0.5, July 31, 2009

• [2] Metadata Standard, Proposed Version 0.7.2, July 30, 2009

• [3] System Management Standard, Proposed Version 0.7.2, July 30, 2009

• [4] Test Article Standard, Proposed Version 0.7.3, July 30, 2009

2.2 Non-Government Documents

2.2.1 Specifications

No non-government specifications are currently referenced by this standard.

2.2.2 Standards

Institute of Electrical and Electronics Engineers (IEEE):

• IEEE 802.1D-2004 [TBD]

• IEEE 802.3-2005 [TBD]

Internet Engineering Task Force (IETF):

• Requests for Comments (RFCs)

768 791 792 793 826 834 919 922 950

959 1034 1035 1042 1122 1123 1305 1350 1812

2068 2119 2131 2161 2210 2212 2215 2309 2326

2328 2347 2348 2430 2474 2475 2581 2597 2697

2698 2963 3140 3246 3247 3260 3270 3289 3290

3376 3986 4188 4541 4594 4601 4632

IETF RFC titles are enumerated in Appendix Section 13.

Telecommunications Industry Association/Electronic Industries Alliance (TIA/EIA)

See Distribution Statement C on cover page 9

• TIA/EIA-568-B.2-2001 (except where conflicting with IEEE 802.3, in which case IEEE 802.3 takes precedence).

See Distribution Statement C on cover page 10

3 DEFINITIONS AND ABBREVIATIONS

Definitions and abbreviations in this standard are common with the Test Article, System Management and

Metadata Standards.

3.1 Definitions

Black or Blackside – A portion of a network that is not physically protected (not secure) with respect to another portion of the network. Sensitive data that traverses this network must be protected by encryption.

Connection Control (CC) – A set of functionality provided by the RFNE to augment RF Network Management functionality and allow for additional control of establishment, maintenance, and termination of data stream connections over the Radio Access Network.

Control Message Protocol – A protocol that defines the sets of messages and the rules for message flow to interface between multiple instances of some functional grouping within the RFNE, used when a logical control connection is needed between two similar functional entities on different physical portions of the Radio Access Network.

DiffServ (Differentiated Services) – -- A computer networking architecture that specifies a simple, scalable and coarse-grained mechanism for classifying, managing and providing Quality of Service (QoS) guarantees on IP network traffic.

Downlink – Communication originating at a Test Article and terminating at the ground. With reference to a relay, communication originating at a Test Article and terminating at the relay.

Enclave – A distinct portion of a network, system or facility that is isolated, usually for security-related purposes, from the rest of the network, system or facility

Internal Interface – A reference point that describes the physical and logical interconnection between two functional components within the RFNE to support Radio Access Network functionality or services.

IntServ (Integrated Services) – A computer network architecture that specifies fine-grained, reservation-based mechanisms for providing Quality of Service (QoS) guarantees for individual IP network traffic flows.

Link Layer Control Messages – The data structure that provides control information at the link layer to support radio functions such as resource allocations, range compensation, power adjustments, queue status reports, and timestamps.

Link Management – A set of functionality provided by the RFNE responsible for optimized control and coordination of radio operation across multiple radios in the Radio Access Network. The primary role of Link

Management is LM is implementation of the TDMA controller that allocates uplink and downlink transmission opportunities.

Manager – An entity which monitors the status of or controls NetworkNodes.

Metadata – An iNET-specific method of describing system and data interrelationships. See Metadata Standard for details.

MIB – A Management Information Base is a “Structure of Management Information” (SMI) formatted text file used by the SNMP agents and managers to define a common communication language for exchanging management information.

NetworkDevice – A NetworkNode that provides network and/or data link layer service and interconnectivity.

NetworkNode – Any device that contains a network interface that is physically connected to the TmNS.

See Distribution Statement C on cover page 11

Octet – A sequence of eight bits.

Protocol – An agreement between communicating parties on how communication is to proceed. Generally, a protocol defines a set of messages and a set of rules for exchanging those messages.

Quality of Service – An umbrella term describing the delivery and performance requirements of a data transfer and/or the network mechanisms used to meet those requirements.

Queue Management – A set of functionality provided by the RFNE as a common, standardized interface to the

Traffic Engineering Queues, which may be implemented with non-standard, vendor-specific mechanisms.

Radio Access Network – The segment of a TmNS that provides RF network connectivity between Test Articles and

Ground Stations

Radio Bearer – The service provided by the Radio Access Network to transfer data between the TA network and ground network. Service is the collection of all means and facilities provided by the network to allow a certain type of communication over the network

Radio Link – The association of one test article radio to a ground station radio. A radio link is established when the

LLCM control loop between the radios is established.

Red or Redside – A portion of a network that is physically protected (secure) with respect to another portion of the network. Sensitive data may be communicated within this protected enclave without need for encryption.

RFNE Control Message Protocol – see “Control Message Protocol”.

RFNE External Interface – see “External Interface”.

RFNE Internal Interface – see “Internal Interface”.

RF Network Management (RFNM) – A set of functionality provided by the RFNE to manage components of the

Radio Access Network and to support Consolidated Management of the TmNS as defined in the System

Management standard.

Test - For the purpose of this standard, a test is considered to be an activity that may last for multiple hours, that involves a Test Article communicating with a Mission Control Room using the RF Network, and that may include multiple test maneuvers (e.g., flutter maneuvers).

Traffic Engineering Queues (TE Queues) – A set of functionality provided by the RFNE that collectively includes the implementation and control of queue structures and associated mechanisms used to provide optimized QoS

(Quality of Service) performance.

Type-Length-Value – A flexible format for defining or specifying data fields in a message, especially when the fields may be of variable length and multiple fields are encapsulated into the message. Used as the data structure that forms LLCMs.

Uplink – Communication originating at the ground and terminating at a Test Article. With reference to a relay, communication originating at the relay and terminating at a Test Article.

3.2 Abbreviations and Acronyms

AES Advanced Encryption Standard

AF Assured Forwarding

AFB Air Force Base

ARP Address Resolution Protocol

See Distribution Statement C on cover page 12 b

B

C2

CBS

Bit

Byte

Command and Control

Committed Burst Size

CC Connection Control

CIDR

CIR

Classless Inter-domain Routing

Committed Information Rate

CLSWG

CINR

COTS

CP

CS

Communication Link Standards Working Group

Carrier to Interference plus Noise Ratio

Commercial Off-The-Shelf

Contention Period

Class Selector

CTEIP Central Test and Evaluation Investment Program

DHCP Dynamic Host Configuration Protocol

DiffServ

DL

Differentiated Services

Downlink

DNS Domain Name System

DoD Department of Defense

DS Differentiated Services (DiffServ)

DSCP DiffServ Codepoint

EF Expedited Forwarding

FIFO

FIPS

FTP

FEC

First-in First-out

Federal Information Processing Standards

File Transfer Protocol

Forward Error Correction

GB Gigabyte gNET

G

Ground Network

Ground

GPS Global Positioning System

GTKSA

GSE

Group Transient Key Security Association

Ground Service Equipment

GS Ground Station

GSS

GUI

Ground Station Segment

Graphical User Interface

HAIPE

HTTP

High Assurance Internet Protocol Encryptor

Hypertext Transfer Protocol

See Distribution Statement C on cover page 13

HTML Hypertext Markup Language

IAW

IBSS

ICMP

ID

in accordance with

Independent Basic Service Set

Internet Control Message Protocol

Identifier

IEEE Institute of Electrical and Electronics Engineers

IETF Internet Engineering Task Force

IGMP Internet Group Management Protocol iNET

IRFNE-GSR

IRFNE-MGS

IRFNE-MTA

IRFNE-RGS

IRFNE-RTA

IRFNE-UGS

IRFNE-UTA

Integrated Network Enhanced Telemetry

Interface between the RFNE and other remote

RFNE instantiations on the Ground Segment

Interface between the RFNE and the TmNS

Management Systems on the Ground Segment

Interface between the RFNE and the TmNS

Management Systems on the TA

Interface between the RFNE and the Radio on the

Ground Segment

Interface between the RFNE and the Radio on the

TA

Interface between the RFNE and the Users of the

RFNE on the Ground Segment

Interface between the RFNE and the Users of the

RFNE on the Test Article

IntServ

IP

IPDV

IPTD

Integrated Services

Internet Protocol

IP Packet Delay Variation

IP Packet Transfer Delay

IPv4 Internet Protocol version 4

IPv6 Internet Protocol version 6

IRIG Inter-Range Instrumentation Group kbps

LA

kilobits-per-second (1000 bits per second)

Link Agent

LLC Logical Link Control

LLCM Link Layer Control Message

LM

MAC

MB

Link Management

Media Access Control

Mega Bytes

Mbps Megabits-per-second

MCC

MCF

Mission Control Center

Mission Control Facility

See Distribution Statement C on cover page 14

MDSWG Metadata Standards Working Group

MIB Management Information Base

MIL-STD

MLD

MPLS

ms

MSLP

Military Standard

Multicast Listener Discovery

Multiprotocol Label Switching millisecond

Mission Service Level Profile

MRTFB Major Range and Test Facility Base

MSB Most Significant Bit

NAS Naval Air Station

OSI

OFDM

Open Systems Interconnection

Orthogonal Frequency Division Multiplexing

PCM Pulse Code Modulation

PHB Per-Hop Behavior

PHY

PPS

QM

Physical Layer

Pulse-per-Second

Queue Management

QoS

PIM

PIM-SM

PIR

PSK

PMKSA

PTK

PTKSA

PTP

PUB

RA

Quality of Service

Protocol Independent Multicast

PIM-Sparse Mode

Peak Information Rate

Pre-Shared Key

Pre-shared Master Key Security Association

Pairwise Transient Key

Pairwise Transient Key Security Association

Precision Time Protocol

Publication

Radio Agent

RAN

RE

RED

RF

Radio Access Network

Radio Element

Random Early Discard

Radio Frequency

RFC Request For Comment

RFNE

RFNE-G

RFNE-TA

RFNM

RL

RSNA

Radio Frequency Network Element

RFNE – Ground

RFNE – Test Article

RF Network Management

Relay

Robust Security Network Association

See Distribution Statement C on cover page 15

RSSI Received Signal Strength Indicator

RSTP

Rx

SLP

SM

Rapid Spanning Tree Protocol

Receive

Service Level Profile

System Management

SMSWG System Management Standards Working Group

SMK

SNMP

SOQPSK

SOQPSK-

TG

Station to Station Link master Key

Simple Network Management Protocol

Shaped Offset Quadrature Phase-Shift Keying

Shaped Offset Quadrature Phase-Shift Keying –

Telemetry Group

SST Serial Streaming Telemetry

STK

STKSA

STSL

T&E

STSL Transient Key

STSL transient Key Security Association

Station to Station Link

Testing and Evaluation

TA Test Article

TAS Test Article Segment

TASWG Test Article Standards Working Group

TBD To Be Determined

TBR To Be Reviewed

TBU To Be Updated

TCP

TDMA

Transmission Control Protocol

Time Division Multiple Access

TE

TFTP

TG

Traffic Engineering

Trivial File Transfer Protocol

Telemetry Group

TIA

TLV

Telecommunication Industry Association

Type-Length-Value

TmNS

Tx

TxOp

Telemetry Network System

Transmit

Transmission Opportunity

UBS

UDP

UL

Unclassified but Sensitive

User Datagram Protocol

Uplink

UTC

WRED

Coordinated Universal Time

Weighted Random Early Discard

UTP Unshielded Twisted Pair vNET Vehicle Network

See Distribution Statement C on cover page 16

XML eXtensible Markup Language

3.3 Standards Key Words

In many sections of this document, key words are used to signify the requirements in the standard. This section defines these words (in accordance with RFC 2119) as they should be interpreted in iNET standards. Note that the force of these words is modified by the requirement level of the standard in which they are used.

• SHALL: This word, or the term "REQUIRED", means that the definition is an absolute requirement of the standard.

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

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

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

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

3.4 Octet and Bit Ordering

Octet ordering is important for correct interpretation of multi-octet fields of the interfaces and protocols specified in this document. The TmNS is an Internet Protocol (IP) network and, therefore, uses the big-endian (a.k.a. network order) convention for octet (byte) order as specified in RFC 791. The big-endian convention states that whenever a multi-octet field represents a numeric quantity the following order is used:

• The most significant octet is transmitted first.

• The left most bit of the whole field is the most significant bit.

To illustrate big-endian ordering, consider a 16-bit field whose decimal value is 258, or 0x0102. This field is transmitted over the IP network in the octet order 0x01, 0x02.

For all figures in this document, a field containing a numeric quantity is shown with the most significant bit (MSB) on the left, unless otherwise noted. When specific bits of fields are numbered, the MSB gets the highest number, unless otherwise noted.

See Distribution Statement C on cover page 17

4 GENERAL PRINCIPLES

There are a number of issues that help define the constraints in which a RAN segment and the RF Network Element may operate. These issues are captured within a set of general principles. The following principles are identified and help frame the development of the RFNE standard.

Range Interoperability: A key requirement considered in this standard is the need to have test articles be able to operate at different ranges, with relatively minor changes in configuration parameters and without redevelopment of software or hardware. This has been a significant motivation for the development of message protocols that govern the interaction between RF Network Element functional components on the ground and their associated functional components on the test article.

Implementation Flexibility: There is an assumption that there is a great deal of flexibility that must be made available for implementation of the RF Network Element. Each range will operate differently to support varying test missions. Each range may have different philosophies in terms of life cycle support and system evolution.

Each range may choose different implementation technologies, relying to various degrees on different commercial technologies. It is expected that various ranges, and certainly various programs at a given range, may take different views in terms of level of integration for test article and ground hardware for the RF Network Element. The RFNE standard has been developed to allow for implementation flexibility. In some cases, some interfaces defined in this standard may be integrated wholly within a vendor’s product and not exposed (either on the test article or ground side equipment). In such cases, these interfaces are not specified for build, and are not tested. When less integration occurs and the interface is exposed, this standard provides guidance for implementation of the interface to support increased capabilities for component interoperability.

Data Delivery Optimization / Quality of Service: Multiple levels of data delivery optimization capability must be made available for various ranges and programs, addressing both near term and longer term needs. Individual ranges can choose to implement capabilities in this standard to address more simple connectivity capabilities with fewer differentiations of QoS. Alternately, ranges and programs can choose to implement more complex capabilities to address a higher level of performance requirements with more complex QoS capabilities implemented. These diverse levels of capability must be managed by the configuration functionality of the RF

Network Element so that range interoperability of the Radio Access Network Segment is maintained.

Security Constraints: Varying levels of security constraints exist at different ranges and for different tests.

Examples of these variations include the presence or absence of data diodes in a Ground Segment and variations in what may be passed through the HAIPE (High Assurance Internet Protocol Encryptor) interface separating red and black side sections of the Ground Segment infrastructure. This standard provides flexibility so that improved performance will result when security constraints allow, but basic functionality still is provided when more constrained security conditions exist.

See Distribution Statement C on cover page 18

5 OVERVIEW

This section provides an overview of:

• The functional components of the RF Network element o The manner in which these components support the overall operation of the RAN Segment o The services provided by the components of the RFNE

• The external interfaces of the RFNE to other elements in the TmNS

• The internal interfaces within the RFNE.

The purpose of this section is to provide the framework to describe and interpret the requirements that follow in

Sections 7-9.

5.1 Functional Components of the RFNE

Figure 5-1 provides an overview of the relationship between the components of the RF Network Element and the manner in which they support the overall operation of the RAN Segment. The blue dashed boundaries encompass components of the RF Network Element. The ground station side RFNE components are shown more completely than the test article side. One test article (number 4) has the components of the RFNE listed.

The basic functional components of the RFNE (RF Network Management, Connection Control, Queue

Management, Traffic Engineering (TE) Queues, and Link Management), are illustrated in boxes in Figure 5-1.

The RF Network Management component provides an overall mechanism for configuration and control of the

RFNE. It provides a mechanism for the RFNE to interact with higher control elements external to the RFNE.

The Connection Control and Queue Management functional components in turn are configured to manage overall flow of data through the RFNE. These two components are responsible for deciding which QoS rules and mechanisms will be implemented for each set of data to be passed over the RFNE, and will govern the behavior of the data queues that may exist in the RFNE as data are passed. The Traffic Engineering (TE) Queues functional component provides one or more queues for staging packets for delivery according to the QoS rules.

The Link Management function, which includes the TDMA controller, is responsible for directing operation of the radios and assigning them capacity to ensure the data held within queues that may exist within the RFNE are transferred between radios in an overall optimal manner. The Link Management function is asymmetric. The ground Link Management function is the entity which directs allocation of TDMA capacity among test articles, and initiates direction to the test article radios to manage the allocation of capacity across the radio air interface.

In Figure 5-1, the grey lines represent payload paths for data that are being transferred between the Vehicle

Network and the Ground Network. The red lines represent control paths between various functional elements that are required to ensure that appropriate configuration, control, and status can be exercised and reported as needed in support of proper RFNE operation. These lines do not necessarily identify standardized interfaces. A standardized interface list is provided separately. Functional descriptions for each component of the RFNE are provided in

Appendix Section 12.

See Distribution Statement C on cover page 19

Radio Radio

Radio Radio

Control Room 1 Control Room 2

Radio

Network Operations

System

Vehicle Network

Test Article 1

(Hangar)

Test Article 2

(Runway)

Test

Article 3 Test

Article 4

Test

Article 5 Test Article Detail

Range WAN (Existing Range Infrastructure)

Ground Network (Existing Range Infrastructure)

RF Network Mgmt

Link Management

(TDMA Control) Queue

Management

Connection

Control RF Network Element LAN

Infrastructure

RAN Segment Boundary

Control Line:

Payload Line:

Handovers Expected as TA goes from hangar to runway and then airborne

TE Queues

RFNE (G) Boundary

CC

QM

TE Queues

RFNM

LM

RFNE (TA) Boundary

Radio

Figure 5-1 Overview of RAN Segment and RF Network Element

One key item to note in the overview figure is that there is expected to be mobility of test articles across ground antennas and radios in the course of normal operation. Additionally, the RFNE will be implemented at ranges that may have significant existing network infrastructure. Components of the RFNE, and elements within the RAN segment, may be geographically separated and connected by existing range infrastructure.

5.2 Basic Themes

The standard is organized about basic themes designed to support the description of this flexible Radio Access

Network. These themes include:

See Distribution Statement C on cover page 20

• Radio links – supporting management of radio associations within the RAN segment,

• Radio bearers – supporting management of data flows across the RAN segment, and

• Service Level Profiles – supporting the overall establishment and management of radio bearers within the

RAN segment.

5.2.1 Radio Links

A radio link represents the association of one test article radio to a ground station radio. The establishment of and management of TDMA capacity among radio links is the responsibility of Link Management. A radio link is established when the Link Layer Control Message ‘control loop’ is established between a master (e.g., the ground radio) and a slave (e.g., the test article radio). It is reconfigured as necessary to maintain required performance and to support handovers of test article radios among various ground radios and antennas within a TmNS.

It is expected in the future that a Test Article may have multiple radios, each operating on the same or a different frequency, perhaps in diverse spectrum bands. In this case multiple radio links, one for each TA and ground radio pair, would be established. A single ground radio can be associated with multiple TA radios (one-to-many), each radio pair forming a radio link. In addition to the TmNS-standard Radio Links described here, additional non-

TmNS-standard communication links (e.g., Satellite Communication links) can be incorporated.

5.2.2 Radio Bearers

A radio bearer represents the collection of services provided by the Radio Access Network to transfer data between the vehicle network and the ground network. A service is the collection of all means and facilities provided by the network to allow communication across the network. A radio bearer can be established once a radio link exists between a test article and the ground.

Radio bearers are used to organize the establishment and management of data transfers across the RAN segment so that appropriate QoS requirements can be supported. The concept of radio bearers is scalable. Simple radio bearers can be established to provide a general unoptimized capability to pass data through the RAN segment with best effort performance. More explicit radio bearers can be established to provide higher levels of optimized performance for certain data types as appropriate. The configuration of a radio bearer is done using parameters that are collected in a construct called a Service Level Profile, described in more detail in Section 5.2.3.

A bearer can be associated with traffic at varying physical and logical levels of abstraction, e.g.,

• all traffic sourced by a given test

• traffic associated with a specific related flow of packets (e.g., from specific sources)

• unrelated traffic…