Attachment 09 ISW_SolNet_Protocol_FinalDraft.pdf

UNCLASSIFIED//FOR OFFICIAL USE ONLY

(U//FOUO) Intra-Soldier Wireless (ISW)

(U//FOUO) SolNet Protocol

Version 1.4 October 2020

DISTRIBUTION STATEMENT D: Distribution authorized to the Department of Defense and U.S. DoD contractors For Official Use Only or for Administrative or Operational Use, 28 September 2018. Other requests for this document shall be referred to the C5ISR Center S&TCD CTI&E Branch. Bldg. 6010, Blair Hall, 6590 Reconnaissance Street, Aberdeen Proving Ground, MD 21005

SolNet Protocol Version: 1.4 Date: October 2020 UNCLASSIFIED//FOR OFFICIAL USE ONLY

(U) Revision History (U)

Date Version Description

September 2018 1.0 Initial document

March 2019 1.1 Edits from implementer feedback; added APIs and SolNet reference

June 2019 1.2 API and SolNet compliance matrix changes; updated API

September 2019 1.3 Updated API (get FW version, set factory default)

October 2020 1.4 SolNet Separated from ISW Embedment Guide & Updated

(U)

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page i

(U) Table of Contents

1. (U) Document Purpose and Scope

2. (U) References

(U) Document References

(U) Definitions

(U) Acronyms and Abbreviations

(U) Language and Word Usage

3. (U) General Description

4. (U) Developing SolNet Software

(U) Overview

(U) Services

4.2.1 (U) Service Provider

4.2.2 (U) Service Subscriber

4.2.3 (U) Service Hierarchy

4.2.4 (U) Service Sessions

(U) Endpoints

(U) Service Discovery

4.4.1 (U) Advertisement Change

4.4.2 (U) Browse Service Retries

(U) Service Registration

4.5.1 (U) Registration Status

4.5.2 (U) Registration Requests

4.5.2.1 (U) Service Registration Retry

4.5.3 (U) Deregistration Requests

4.5.3.1 (U) Deregistration Retry

4.5.4 (U) Revoke Requests

4.5.4.1 (U) Revoke Retry

4.5.5 (U) Example Service Registration

(U) Data Flow Initiation

4.6.1 (U) Data Flow Policies

4.6.2 (U) Automatic Flow

4.6.3 (U) Autonomous Start

4.6.4 (U) Autonomous Stop

4.6.5 (U) Polled Data

4.6.6 (U) Examples

(U) Keep Alive Monitoring

(U) Condition Reporting

(U) Network Disassociation

(U) SolNet Session Cessation Conditions

5. (U) SolNet Messaging and Data Structures

(U) Byte Order and Alignment

(U) Data Types

(U) Data Packing

(U) Base Message Formats

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page ii

5.4.1 (U) Protocol Version

5.4.2 (U) Protocol Class

(U) SolNet Data Packets (SolNet Protocol Class = 0x00)

5.5.1 (U) Dataflow Identifier

5.5.2 (U) Sequence Number

5.5.3 (U) Policies

5.5.4 (U) Header Checksum

5.5.5 (U) Data Length

5.5.6 (U) Data Payload

5.5.7 (U) Pad

5.5.8 (U) Payload Checksum

(U) SolNet Message Packets (SolNet Protocol Class = 0x01)

5.6.1 (U) Message Class

5.6.2 (U) Message ID

5.6.3 (U) Sequence Number

5.6.4 (U) Policies

5.6.5 (U) Status

5.6.6 (U) Header Checksum

5.6.7 (U) Message Length

5.6.8 (U) Message Payload

5.6.9 (U) Pad

5.6.10 (U) Payload Checksum

(U) Specific SolNet Messages

5.7.1 (U) Discovery Protocol Packets

5.7.1.1 (U) Browse Service

5.7.1.2 (U) Service Advertisement

5.7.1.3 (U) Service Advertisement Change

5.7.2 (U) Flow Protocol Packets

5.7.2.1 (U) Get Status

5.7.2.2 (U) Register

5.7.2.3 (U) Deregister

5.7.2.4 (U) Revoke Registration

5.7.2.5 (U) Poll Data

5.7.2.6 (U) Autonomous Flow

5.7.2.7 (U) Keep Alive

5.7.3 (U) Reporting Protocol Packets

5.7.3.1 (U) Report Dataflow Condition Indication

5.7.4 (U) Low-Level Bridge Protocol Packets

5.7.4.1 (U) Revoke Network Association

5.7.5 (U) Policy Protocol Packets

5.7.5.1 (U) Acknowledgement

(U) SolNet Message Retries

5.8.1 (U) Concurrent Requests

5.8.2 (U) Out of Order Request

5.8.3 (U) No Response Retry

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page iii

5.8.4 (U) Unsuccessful Response Retry

(U) SolNet Parameters

6. (U) Descriptors

(U) Descriptor Hierarchy

(U) Descriptor Format

(U) Root Descriptors

6.3.1 (U) Root Device Descriptor

6.3.2 (U) Root Service Descriptor

6.3.3 (U) Example Descriptor Hierarchy

(U) Descriptor Parsing

(U) Descriptor Development Best Practices

(U) Descriptor Namespace

(U) Service Descriptors

6.7.1 (U) Service Descriptor Format

6.7.1.1 (U) Service Selector

6.7.1.2 (U) Service Child Block

6.7.1.3 (U) Required Property Descriptors

6.7.2 (U) Service Descriptor Hierarchy

6.7.2.1 (U) Sub-Services

6.7.3 (U) Well-Known Services Descriptor IDs

(U) Property Descriptors

(U) Core Property Descriptors

6.9.1 (U) Label Descriptor

6.9.2 (U) Endpoint Descriptor

6.9.2.1 (U) Endpoint ID

6.9.2.2 (U) Dataflow ID

6.9.2.3 (U) Endpoint Distribution

6.9.2.4 (U) Data Policies

6.9.2.5 (U) Required Child Descriptors

6.9.2.6 (U) Optional Child Descriptors

6.9.3 (U) Multicast Group Descriptor

6.9.4 (U) Device Name Descriptor

6.9.5 (U) Device Serial Number Descriptor

6.9.6 (U) Device Manufacturer Descriptor

6.9.7 (U) Device Friendly Name Descriptor

6.9.8 (U) Associated Service Descriptor

6.9.9 (U) Endpoint Protocol Descriptor

6.9.10 (U) Text Label Descriptor

6.9.11 (U) Device Descriptor

6.9.11.1 (U) Generation ID

6.9.12 (U) QoS Properties Descriptor

6.9.13 (U) QoS Data Rate Descriptor

6.9.14 (U) QoS Max Latency Descriptor

6.9.15 (U) Device Software/Firmware Version Descriptor

6.9.16 (U) Software/Firmware Name Descriptor

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page iv

6.9.17 (U) Software/Firmware Version Descriptor

(U) Service-Specific Property Descriptors

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page v

(U) List of Figures

Figure 3-1 (U) ISO/OSI-IEEE 802 Reference Model Figure 4-1 (U) Service Hierarchy Example Figure 4-2 (U) Example Browse/Advertise Services, A Figure 4-3 (U) Example Browse/Advertise Services, B Figure 4-4 (U) Example Registration Figure 4-5 (U) Example Data Flow Start, Autonomous Figure 4-6 (U) Example Data Flow Start, Polled Figure 6-1 (U) Descriptor Hierarchy Padding Figure 6-2 (U) Descriptor Hierarchy Figure 6-3 (U) Example Descriptor Hierarchy Figure 6-4 (U) Example Descriptor Parser Figure 6-5 (U) Example “Dependent On” Service Relationship Figure 6-6 (U) Example "Sibling To" Service Relationship

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page vi

(U) List of Tables Table 2-1 (U) Document References Table 2-2 (U) Definitions Table 2-3 (U) Acronyms and Abbreviations Table 2-4 (U) IEEE Word Usage Summary Table 4-1 (U) ISW Compliance for SolNet Table 4-2 (U) ISW Unicast Endpoint Assignment Policy Table 5-1 (U) Data Types Table 5-2 (U) SolNet Common Packet Header Table 5-3 (U) SolNet Protocol Class Values Table 5-4 (U) Data Packet Header Table 5-5 (U) Message Packet Header Table 5-6 (U) Message Class Values and Categories Table 5-7 (U) Status Values Table 5-8 (U) SolNet Message Classes and IDs Table 5-9 (U) Browse Service Table 5-10 (U) Advertise Services Table 5-11 (U) Announce Advertisement Change Table 5-12 (U) Service Advertisement Change Confirmation Table 5-13 (U) Get Service Status Request Table 5-14 (U) Get Service Status Response Table 5-15 (U) Service Status Values for Get Service Status Response Table 5-16 (U) Register Request Table 5-17 (U) Register Response Table 5-18 (U) Register Response Message Specific Status Table 5-19 (U) Deregister Request Table 5-20 (U) Deregister Response Table 5-21 (U) Deregister Response Message Specific Status Table 5-22 (U) Revoke Registration Request Table 5-23 (U) Revoke Registration Response Table 5-24 (U) Revoke Registration Message Specific Status Table 5-25 (U) Poll Data Request Table 5-26 (U) Poll Data Response Table 5-27 (U) Poll Data Response Message Specific Status Table 5-28 (U) Autonomous Flow Request Table 5-29 (U) Autonomous Flow Response Table 5-30 (U) Autonomous Flow Message Specific Status Table 5-31 (U) Keep Alive Request Table 5-32 (U) Keep Alive Response Table 5-33 (U) Keep Alive Message Specific Status Table 5-34 (U) Report Dataflow Condition Indication Table 5-35 (U) Dataflow Conditions Table 5-36 (U) Revoke Network Association Request Table 5-37 (U) Revoke Network Association Response Table 5-38 (U) Revoke Network Association Message Specific Status Table 5-39 (U) Acknowledgement Packet Table 5-40 (U) Acknowledgement Block Table 5-41 (U) SolNet Parameters

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page vii

Table 6-1 (U) Common Descriptor Format Table 6-2 (U) Descriptor Namespace Table 6-3 (U) Service Descriptor Format Table 6-4 (U) Service Descriptor ID Values Table 6-5 (U) Service Descriptor ID Values – Continued Table 6-6 (U) Property Descriptor Class Namespace Table 6-7 (U) Core Property Descriptor ID Values Table 6-8 (U) Label Descriptor Table 6-10 (U) Endpoint Descriptor Table 6-11 (U) Native Multicast Group Descriptor Table 6-13 (U) Device Name Descriptor Table 6-14 (U) Device Serial Number Descriptor Table 6-15 (U) Device Manufacturer Descriptor Table 6-16 (U) Device Friendly Name Descriptor Table 6-17 (U) Associated Service Descriptor Table 6-18 (U) Endpoint Protocol Descriptor Table 6-19 (U) Endpoint Protocol Identifiers Table 6-20 (U) Text Label Descriptor Table 6-21 (U) Device Descriptor Table 6-22 (U) QoS Properties Descriptor Table 6-23 (U) QoS Data Rate Descriptor Table 6-24 (U) QoS Max Latency Descriptor Table 6-25 (U) Device Software/Firmware Version Descriptor Table 6-26 (U) Software/Firmware Name Descriptor Table 6-27 (U) Software/Firmware Version Descriptor

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page 1

1. (U) Document Purpose and Scope (U//FOUO) This document defines the protocol for the Intra-Soldier Wireless (ISW) Soldier Network (SolNet). This document is intended to provide enough information for ISW nodes to be compliant with the SolNet protocol for interoperating and coexisting with other ISW SolNet devices within the same network.

(U//FOUO) If in conflict with the same version of ISW Protocol Specification [R2], this document is superseded by the ISW Protocol Specification [R2].

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page 2

2. (U) References

(U) Document References (Unclassified)

Table 2-1 (U) Document References Ref # Title

[R1] ECMA-368, High Rate Ultra-Wideband PHY and MAC Standard, 3rd Edition. Also coded as ISO/IEC 26907

[R2] A3309771A ISW Protocol Specification v4.4

[R3] A3309777- ISW Observer Sessions v2.0

[R4] IEEE-SA Standards Style Manual, 2014

[R5] IEEE Std 1003.1-2001

[R6] IEEE Std 754-2008

[R7] A3309776-1 ISW SolNet Property Descriptor Specification v1.4

(Unclassified)

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page 3

(U) Definitions (Unclassified)

Table 2-2 (U) Definitions Term Definition

Application Application that uses ISW to transport data over wireless

Consumer See data consumer

Data Consumer

An ISW node that receives (consumes) data from a given Data Producer

Data Producer

An ISW node that produces (transmits) data to a given Data Consumer

Endpoint Logical flow of data arriving from an application over a wired interface

Node The hardware, firmware and software that constitutes an ISW implementation

Peer Node connected to the local node over the air

Producer See data producer

Provider See service provider

Service Provider

An ISW node, or service, which advertises and offers its service, through the use of ISW SolNet

Service Subscriber

An ISW node which queries (Browses), and registers with a given Service Provider

Stream Collection of logical flows between two peers in a network

Subscriber See service subscriber

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page 4

(U) Acronyms and Abbreviations (Unclassified)

Table 2-3 (U) Acronyms and Abbreviations Acronym Abbreviation

AL Alereon

ASCII American Standard Code for Information Interchange

API Application Programming Interface

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

EUI-48 Extended Unique Identifier, 48 bits

FCC Federal Communications Commission

FPGA Field Programmable Gate Array

FOUO For Official Use Only

FWS-I Family of Weapon Sight-Individual

GPIO General Purpose Input/Output

HUD Heads-Up Display

IMU Inertial Measurement Unit

ISW Intra-Soldier Wireless

LSB Least Significant Bits

LRF Laser Range Finder

MAC Media Access Control

MSB Most Significant Bits

NIST National Institute of Standards and Technology

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page 5

Acronym Abbreviation

PHY Physical Layer

QoS Quality of Service

SolNet Intra-Soldier Wireless Networking

SWIM Simple Wire Interface Mux/De-mux

USB Universal Serial Bus

UTF Unicode Transformation Format

UWB Ultra-Wideband

WS Weapon Sight

(U) Language and Word Usage

(U) This specification has adopted IEEE Standards Style Manual [R4] word usage, as defined in §10.2.

Table 2-4 (U) IEEE Word Usage Summary

(U//FOUO)

Shall is required to - The word shall indicate mandatory requirements strictly to be followed in order to conform to the standard and from which no deviation is permitted.

Must is a natural consequence of - The use of the word must is deprecated and shall not be used when stating mandatory requirements; must is used only to describe unavoidable situations.

Will it is true that - The use of the word will is deprecated and shall not be used when stating mandatory requirements; will is only used in statements of fact.

Should is recommended that - The word should indicate that among several possibilities, one is recommended as particularly suitable without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required.

May is permitted to - The word may is used to indicate a course of action permissible within the limits of the standard.

Can is able to - The word can is used for statements of possibility and capability, whether material, physical, or causal.

(U//FOUO)

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page 6

3. (U) General Description (U//FOUO) The Intra-Soldier-Wireless (ISW) architecture supports a series of operations, methods, and policies that allow ISW nodes to form networks, exchange data in a standard manner, and meet the unique operational requirements of ISW in a military space.

(U//FOUO) The ISW Protocol Specification [R2] defines a protocol, referred to as ISW-Mac, for simple transport of high-bandwidth data streams over the UWB medium in a manner that meets ISW objectives and use cases. The protocol corresponds to the logical link control sub layer of the standard ISO/OSI IEEE 802 reference model. The model is shown in the following figure.

Figure 3-1 (U) ISO/OSI-IEEE 802 Reference Model

(U//FOUO) The ISW-Mac client (system application) can assume a variety of forms, including interface protocol adaptation, network protocol adaptation, client drivers communicating with hosts, host drivers communicating with clients, and self-contained embedded functions. Every ISW node shall have an ISW- Mac client.

(U//FOUO) This specification defines the Intra-Soldier Wireless Networking (SolNet) Protocol. This protocol promotes networking layer compatibility between ISW nodes. SolNet defines a simple networking protocol for service discovery and flow activation. ISW nodes discover the services of peers using service discovery. ISW nodes register with the discovered peer's service using flow activation.

Together, these operations promote efficient use of the network.

(U//FOUO) SolNet is designed specifically for optimal usage in a fully connected peer-to-peer network, such as provided by the ISW-Mac. SolNet does not provide any mechanism for routing data across multiple ISW networks, or between hidden nodes. Higher layer applications may provide this bridging capability as necessary.

Session Layer

Transport Layer

Network Layer

Presentation Layer

Data Link

Layer

Physical Layer

Logical Link Control

MAC

ISO/OSI-IEEE 802

reference model

ECMA-368

MAC

ECMA-368

PHY

ISW-Mac

Application Layer

ECMA-368

MAC

ECMA-368

PHY

Application Layer

MAC protocol

PHY protocol

MAC SAP

SolNet SolNet ISW-Mac SAP

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page 7

4. (U) Developing SolNet Software

(U) Overview (U//FOUO) SolNet allows an ISW module to discover the offered services of all nodes in its network and access those services as needed. SolNet shall be implemented in the ISW client; the ISW module is a simple pipe that knows nothing of SolNet protocol. In practice, a service is a particular flow of data sent over the air by a peer. The implementer of an ISW client determines which services to offer, how to represent the services in a SolNet advertisement, and how to shape QoS for ISW endpoints to properly transmit data for each service.

(U//FOUO) SolNet defines a mechanism for devices to discover each other, and exchange data. The mechanism itself is standardized, as defined below, but there is no policy enforcement on the network.

All peers shall adhere to the strict communication protocol to prevent inadvertent negative impacts to the network performance and the nodes connected to the network.

(U//FOUO) The ISW module automatically finds and connects to peers and notifies the host application of the available connection. However, the host application does not blindly send data to a peer or expect to blindly receive data from a peer, except for broadcast streams. Before exchanging data, the nodes shall discover each other’s services, determine if any (or all) of the services are of interest to the node, and then register for the service. Once a peer registers for a service, the node can begin sending data to the peer or expecting data from the peer for that particular service. SolNet defines the protocol whereby host applications perform this service discovery and registration.

(U//FOUO) The SolNet sequence for getting data is as follows:

• (U//FOUO) Browsing and advertising. A node asks another node for a set of descriptors describing its offered services. The integrated node responds to the requestor with the descriptors.

• (U//FOUO) Selectively Registering with Services. Each node determines what services it wishes to use, and then registers for that service or set of services.

• (U//FOUO) Starting Data Flow. Each node signals the other when to start sending data related to that service.

• (U//FOUO) Performing Other Operations. Nodes can perform other operations, such as stopping data flow, unregistering, etc.

(U//FOUO) All SolNet messages are issued on unicast endpoint 0 only. SolNet messages, operation, and descriptor sets are defined in sections (U) SolNet Messaging and Data Structures §5 and (U) Descriptors §6.

(U//FOUO) The following tables shows the SolNet requests and SolNet responses that are required for ISW compliance. The tables delineate between a service provider and service subscriber. If a device both provides and subscribes to services, it shall implement the superset of required requests and responses.

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page 8

Table 4-1 (U) ISW Compliance for SolNet

Service Provider Service Subscriber

Field Create Parse Create Parse

Discovery – Messages for service and device discovery

Browse Service Request Optional Required Required Required

Service Advertisement Required Optional Required Required

Service Advertisement Change Optional Optional N/A Required

Service Advertisement Change Confirmation

Optional Optional Required N/A

Flow – Messages to establish, maintain, and control data flow

Get Status Request N/A Required Optional N/A

Get Status Response Required N/A N/A Optional

Register Request N/A Required Required N/A

Register Response Required N/A N/A Required

Deregister Request N/A Required Optional1 N/A

Deregister Response Required N/A N/A Optional1

Revoke Registration Request Optional2 N/A N/A Required

Revoke Registration Response N/A Optional2 Required N/A

Poll Data Request N/A Required3 Optional3 N/A

Poll Data Response Required3 N/A N/A Optional3

Autonomous Flow Request N/A Required Optional4 N/A

Autonomous Flow Response Required N/A N/A Optional4

Keep Alive Request N/A Required Optional5 N/A

Keep Alive Response Required N/A N/A Optional

Acknowledgement Required Optional6 Required Optional6 1 If Deregister Request is implemented then Deregister Response shall be parsed.

2 If Revoke Registration Request is implemented then Revoke Registration Response shall be parsed.

3 If advertised Autonomy defines polled data, the provider shall support it. If the subscriber would like to poll data, it shall implement these messages. Polling is not strictly required, and a service provider may not support it.

4 If the subscriber wants to start and stop flows, it must support this.

5 If Keep Alive Request is implemented then Keep Alive Response shall be parsed.

6 If any data transmitted or received implements and uses the acknowledgement flag, then this shall be implemented.

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page 9

(U//FOUO) Host applications shall be able to process any received SolNet request and send a valid response. For any unsupported SolNet requests, the receiver may send the associated SolNet response with a status value of “not supported”.

(U//FOUO) NOTE: The ISW nodes do not implement policies restricting data flow between devices, therefore it is crucial that devices follow the ISW SolNet handshake for proper data flow. Misuse or improper implementation could cause significant network and system degradation, to include but not limited to loss of connection, corrupted data, or impacting host processors core functionality.

(U) Services (U//FOUO) An ISW node may provide or subscribe to one or more services. A service is a logical self-contained unit that performs a specific task (e.g. a print function), for one or more subscribers within the network. Services may have hierarchical structure to support more complex service based functions with interrelated subservices.

(U//FOUO) Service Philosophies:

• (U//FOUO) Services should be designed to minimize user intervention and configuration.

• (U//FOUO) Services discovery shall use a common language (SolNet Messages and Descriptors).

• (U//FOUO) Services shall be dynamically discoverable by other devices on the network. The service shall contain as much data as necessary for well-defined machine-to-machine communications.

• (U//FOUO) At the lowest level a service shall perform a single functional task.

• (U//FOUO) Complex services shall be built from a set of well-known services that perform single functional tasks.

• (U//FOUO) A service provider shall define how services are created (Registered), how sessions are controlled (Data Flow), and what protocols are used within the service.

• (U//FOUO) A service may consume or produce data, or any combination thereof.

4.2.1 (U) Service Provider (U//FOUO) A Service Provider is one which advertises a specific service, through the use of ISW SolNet Advertisement messages, using the well-defined descriptor format. The service provider defines the policies for the service usage and any negotiations necessary to interoperate with a service subscriber(s).

Service Provider and provider may be used interchangeably throughout this document.

(U//FOUO) A Service Provider shall decide the policy for which its service and data may be accessed by the Service Subscriber. The Service Provider shall provide enough details about the service being offered, for the Service Subscriber to query and decide if it has interest in subscribing to those services.

(U//FOUO) The Service Provider waits until a service subscriber requests to register a service. This registration process notifies a Service Provider of the intent of a Service Subscriber to access a specific service within the network node. The Service Provider shall accept or reject this request.

(U//FOUO) A Service Provider may manage and prioritize service connections based on any criteria it wishes. It may support one or more Service Subscribers simultaneously, or it may revoke registration when higher priority service subscribers joins the network.

(U//FOUO) This model is similar to client-server model. Similar to the Client-Server model, the Service Provider much like a server, waits for a Service Subscriber, much like the client, to initiate a connection.

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page 10

4.2.2 (U) Service Subscriber (U//FOUO) A Service Subscriber is one which queries (Browses), and registers with a given Service Provider. Service Subscriber and subscriber may be used interchangeably throughout this document.

(U//FOUO) The Service Subscriber, typically queries all nodes on the network, or new nodes on the network, and after parsing their Advertisement Messages, decides if it has interest in any of the services being offered on the network. When a service that matches the Service Subscribers criteria is made available on the network, it may begin the service registration process.

(U//FOUO) Service Subscribers do not publish information about the services they are interested in.

Only Service Providers include service details within the Advertisement Message. Instead they actively query service databases, with the SolNet Browse Message, of peers on the network.

(U//FOUO) Although a Service Subscriber cannot force a Service Provider to accept a registration, it may at any time deregister with a Service Provider, to discontinue the service with that provider.

4.2.3 (U) Service Hierarchy (U//FOUO) Simple services are able to perform a single function, while complex services may require a hierarchy of functions to be realized. To simplify development and improve reliability, a service may contain child services that implement sub-functions. The parent service is known as Composite Service, and child services are known as Sub-Services. Services that do not inherently require child services are known as a Base Services. All composite, and sub-services are made up of base services or sub-services.

(U//FOUO) An example of a Composite Service would be a mixed reality service. This service may require inertial measurement units (IMU), imagery sensors, and infrared spatial sensors as well as an output display. The mixed reality service may contain well-known base services for each of these sensor platforms and include them as child services to accomplish the mixed reality functions. See Figure 4-1for example hierarchy.

(U//FOUO)

Mixed Reality Service (Composite Service &

Root Service)

Motion Sense Service

- IMU

(Base Service & Sub-Service)

Video Input (Base Service &

Sub-Service)

Motion Sense Service

- Infrared

(Base Service & Sub-Service)

Motion Sense Service (Base Service &

Sub-Service)

Figure 4-1 (U) Service Hierarchy Example

(U//FOUO) In most cases a Sub-Service will also be a Base Service, as shown in the previous example.

In rare circumstances a Sub-Service may be another Composite Service.

(U//FOUO) Services that are distinct and individually accessible from all other services are known as Root Services. These services can be acted upon and utilized independently of all other services provided

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page 11 by the ISW node. A service that relies on another root service, but the reciprocal is not true, shall utilize service association and may also be a root service.

4.2.4 (U) Service Sessions (U//FOUO) A service that has been registered by a service subscriber and accepted by a service provider shall be considered an Active Service until the service is revoked, is deregistered, or loss of activity between the peers occurs.

(U) Endpoints (U//FOUO) Endpoints are a function of the ISW-Mac, in which data is multiplexed between nodes into logical data streams. These data streams allow for different types or priority of data to be independently controlled between pairs of nodes on the network. Most endpoints are unicast, although there also exists multicast and broadcast endpoints.

(U//FOUO) The ISW-Mac implements QoS as transmit-side mechanism that tells the ISW module what to do when the wireless link is experiencing interference sufficient to cause congestion in the transmit buffers. ISW allows the module to shape QoS parameters for each of the transmit endpoints on a peer-by-peer basis. The ISW module does not allow setting of QoS parameters for receive endpoints. By default, the ISW module weights each endpoint equally (high priority) and does not discard any data. The ISW API Set Stream Spec command allows the client to set certain endpoints as low priority or to allow certain endpoints to discard data during congestion.

(U//FOUO) For the purpose of interoperability between subsystems, unicast endpoint QoS has been standardized for SolNet. In order to maintain interoperability with all combinations of services being provided, SolNet compliant devices shall select the endpoint numbers based on priority and discard policy as outlined below.

Table 4-2 (U) ISW Unicast Endpoint Assignment Policy

(U//FOUO)

Endpoint Data Policy Notes

0 High Priority (1) Non-Discardable (0)

This endpoint shall be used for SolNet commands and reliable (guaranteed delivery), high priority, low throughput data. Low throughput is meant to include data rates that do not cause undue interference or latency to SolNet data, such as periodic status information. Broadcast data also utilizes Endpoint 0.

1 High Priority (1) Non-Discardable (0)

This endpoint shall be used for high priority reliable (guaranteed delivery) data. Such data may include real-time video.

2 High Priority (1) Discardable (1)

This endpoint shall be used for high priority non-reliable (best effort delivery) data.

3 Low Priority (0) Non-Discardable (0)

This endpoint shall be used for low priority best effort delivery data. Such data may include non-critical periodic status information.

(U//FOUO)

(U//FOUO) Because unicast endpoint 0 carries all SolNet command packets, it must remain non-discardable.

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page 12

(U//FOUO) Two or more services offered by the same node can share an endpoint as long as the QoS is the same for each service sharing the endpoint. Services sharing an endpoint delineate from one another using the dataflow ID.

(U//FOUO) In addition to determining endpoint QoS, the implementer must determine what kind of data distribution an endpoint/dataflow combination uses. When sending data directly to a single peer, the dataflow distribution shall be unicast. When sending data to a particular sub-set of peers, the dataflow distribution shall be multicast. When sending data available to all peers, the dataflow distribution should be broadcast.

(U//FOUO) A node that receives data on an incoming endpoint is known as a Data Consumer, while a node that transmits data on an outgoing endpoint is known as a Data Producer. A Service Provider or Service Subscriber may be one of each, or both.

(U//FOUO) There may be times when a pair of nodes subscribe to each other’s services, for which the services utilize the same endpoint and direction. A condition may occur when the two services have different QoS requirements for the given endpoint. In this scenario the peer(s) that are producing the data shall set the endpoint to the highest of QoS settings. For example, if two services require different latencies, the peer shall be set to the lowest latency, i.e. tightest QoS setting.

(U//FOUO) Each service shall use one or more Endpoint Descriptors to define the details about the endpoints being used. The implementer must decide the QoS needs of that endpoint and encode it properly in the advertised endpoint descriptors, using the Table 4-2.

(U//FOUO) The Service Provider shall use endpoint numbers from Table 4-2 that match the desired QoS for the given service. Additional QoS parameters, such as max latency may optionally be included in the Endpoint Descriptors, or just set by the service.

(U//FOUO) Some services, such as Control and Status, can implement bi-directional protocol. A node supporting a bi-directional protocol can advertise a single service containing two endpoint descriptors.

One endpoint descriptor defines a producer dataflow ID while the other defines a consumer dataflow ID.

(U) Service Discovery (U//FOUO) The host application uses SolNet discovery protocol to determine the services offered by peers. In brief, the packets are:

• (U//FOUO) Browse Service – Packet asking a peer node to send its service descriptor to the requestor. Sent to a specific node using peer index.

• (U//FOUO) Service Advertisement – Packet containing a node's service and property descriptor(s). Sent to a specific node using peer index in response to a Browse Service.

(U//FOUO) Upon joining a network, the joining node issues a Browse Service packet to each node that it finds. Nodes already on the network, should reciprocate with their own Browse Service packet. The existing nodes do not need to wait until they receive a Browse Service packet from the joining node before sending their Browse Service request. This request asks for the peer node's service descriptor.

Upon receiving a Browse Service packet, the peer's host application responds with a Service Advertisement packet. The Service Advertisement packet shall contain the minimum device level descriptors outlined in (U) Root Descriptors §6.3, but may additionally contain one or more service descriptors.

(U//FOUO) The following sequence chart illustrates a WS joining a network consisting of a HUD and LRF as seen from the WS’s perspective.

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page 13

Figure 4-2 (U) Example Browse/Advertise Services, A

(U//FOUO) The following sequence chart illustrates a WS joining a network consisting of a HUD and LRF as seen from the perspective of the HUD and LRF.

Figure 4-3 (U) Example Browse/Advertise Services, B

(U//FOUO) Only provided services are advertised. When advertising to their peers, each node must advertise the services they provide and enough information about the service to allow peers to know if they need and can process the data produced or consumed by the service.

(U//FOUO) Each service descriptor includes a Service ID. A service may contain child descriptors that describe service details. The SolNet descriptor topology allows the subscriber to skip or ignore unknown or unwanted services. When parsing a Service Advertisement, the subscriber may quickly decide whether the device offers services it needs. The device need only establish a flow with the services it needs.

Browse Service

Service Advertisement

Browse Service

Service Advertisement

Connection Indication: HUD

Connection Indication: LRF

Example

Service Advertisement

Browse Service)

Service Advertisement

Browse Service

Connection Indication: WS

Example

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page 14

4.4.1 (U) Advertisement Change (U//FOUO) When an ISW Mac-Client needs to change its service advertisement descriptor without disconnecting from all peers, for any reason, including, but not limited to, changes in available services, it shall notify all nodes on the network of this change, via the Service Advertisement Change packet. The only mechanism to guarantee all nodes receive this notification, is to send it via the unicast SolNet endpoint, zero (0). The message shall be repeated to all connected nodes, whether the ISW-Mac Client has active service with them or not.

(U//FOUO) If the change in descriptor causes any level of conflict between endpoints, service handles, or dataflow identifiers for active services, the Service Provider shall initiate revoking all conflicting registrations prior to updating the Service Advertisement descriptors and shall notify any nodes on the network of the advertisement change, with the Service Advertisement Change packet. Care should be taken to limit the need to revoke registrations for active services, as this will cause a disruption in the network. Many best practices, such as limiting the scope of descriptor changes to only those services that need to be modified, should be followed.

(U//FOUO) If a service provider does not revoke a registration with a service subscriber that has active services, before sending an updated advertisement change, the service subscriber shall assume that the Service Advertisement descriptor has not changed for the given service. It is the responsibility of the service provider to uphold this.

(U//FOUO) If the Service Provider chooses to remove its service from the Service Advertisement, it shall initiate a revoke to any service subscribers for the service being removed. At this time, the service subscriber may not re-register to this service, until it is published in the Service Advertisement again.

Care must still be taken to guarantee any new services do not cause conflict with service handles, endpoints, or dataflow identifiers. New services shall not use the service handle or endpoint / dataflow identifier combination of an existing service. A new service shall not reuse the service handle of a service removed during the same advertisement change.

(U//FOUO) Alternatively, a service provider may revoke its service from any active service subscribers, before removing its advertisement.

4.4.2 (U) Browse Service Retries (U//FOUO) If the peer node does not issue a Service Advertisement packet within RequestTimeout, the host application resends1 the Browse Service packet. The host application client retries up to SolNetMessageRetries attempts before assuming that the peer node cannot or will not respond, and ceases attempting to discover the peer node's services. The node can have multiple outstanding Browse Service packets in flight simultaneously to multiple peers. See (U) SolNet Message Retries §5.8 for further details.

(U) Service Registration (U//FOUO) After discovering a peer's services, the host application parses the descriptors to determine which, if any, services it should register with. The host application uses the SolNet protocol to register with and start services. The SolNet packets for registration are:

• (U//FOUO) Status – Packet sent to the service provider to return its registration status. This is optional.

• (U//FOUO) Register – Packet sent to the service provider to register with a service it provides.

1 (U//FOUO) Resends is defined as sending the same exact packet again, exactly as previously. No changes to sequence numbers or any other fields should occur.

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page 15

This allows the services function to be exposed to the requesting node and data may flow between them.

• (U//FOUO) Deregister – Packet sent to the service provider to deregister the requesting node as a registered node of its specific service and forgo data flow for this service.

• (U//FOUO) Revoke Registration – Packet sent from the service provider to revoke the registration of a currently registered peer and forgo all data flow for the given service.

4.5.1 (U) Registration Status (U//FOUO) After discovering a peer's service, the host application may optionally determine the peer's status using a Get Status Request packet. Upon receiving a Get Status Request packet, a node shall return a Get Status Response packet indicating the registration state relative to the requester.

4.5.2 (U) Registration Requests (U//FOUO) Regardless of registration status of the peer, the host application may send a Register Request packet to the peer to register itself as a subscriber of the peer’s service. If the service provider accepts the Registration Request from the service subscriber, the peers will be said to have an Active Service. The active service shall stay in effect until a service is revoked, deregistered, or times out.

(U//FOUO) During an active service, data may flow between the peers over the dataflow/endpoint(s) defined by the service descriptor for the given service. The flow of data between the service provider and service subscriber is managed based on the policies defined for each dataflow/endpoint(s) within the service.

(U//FOUO) Service Subscribers shall only register to root services. Sub-services shall not be registered to individually. Should a peer try and register to a Sub-service, the service provider shall respond to the request with the Status field set to “Request Denied” (0x05). See (U) Register §5.7.2.2 for further details.

(U//FOUO) When a root service has been registered to by a subscriber and the service is an active service, all sub-services shall be part of that active service. In other words, there is an inherent registration to all sub-services as part of the root service registration. Data may flow to these sub-services as it would for any other active service.

4.5.2.1 (U) Service Registration Retry (U//FOUO) Upon receiving the Register Request packet, the service provider returns a Register Response packet. If the service provider does not issue a Register Response packet within RequestTimeout, the service subscriber resends another Register Request packet. The subscriber retries up to SolNetMessageRetries attempts before assuming that the service provider cannot or will not respond, and ceases attempting to register with the peer node. See (U) SolNet Message Retries §5.8 for further details.

4.5.3 (U) Deregistration Requests (U//FOUO) If a node is registered with a service provider and it leaves the network (loss of activity), the service subscriber implicitly deregisters from the service provider. No message shall be exchanged to deregister from the service provider. When the peer reappears, the service subscriber may repeat the service discovery and registration process.

(U//FOUO) If a service provider has a service subscriber registered and the service subscriber leaves the network (loss of activity), the service provider deregisters the subscriber implicitly. No message shall be exchanged to revoke the registration due to the loss-of-activity (disconnection) of the service subscriber.

(U//FOUO) If a service subscriber wishes to deregister from the service provider, the subscriber sends a Deregister Request packet to the service provider. Upon receiving the Deregister Request packet, the service provider returns a Deregister Response packet and stops sending data to the subscriber.

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page 16

4.5.3.1 (U) Deregistration Retry (U//FOUO) If the service provider does not issue a Deregister Response packet within RequestTimeout, the service subscriber resends another Deregister Request packet. The subscriber retries up to SolNetMessageRetries attempts before assuming that the provider cannot or will not respond, and ceases attempting to deregister from the provider. On expiration of retries, the subscriber assumes that deregistration succeeded. See (U) SolNet Message Retries §5.8 for further details.

4.5.4 (U) Revoke Requests (U//FOUO) If the service provider wishes to terminate the services to a subscriber, it may revoke the registration by sending a Revoke Registration Request packet to the desired subscriber and cease all data transmission with the service subscriber.

(U//FOUO) Upon receiving a Revoke Registration Request, the service subscriber shall immediately cease data transmission for this service, and it shall send a Revoke Registration Response message to the service provider, at which time the service will be terminated.

(U//FOUO) The service provider may issue Revoke Registration Requests to multiple service subscribers at the same time, to allow revocations to occur in parallel.

(U//FOUO) Upon revocation of service, the subscriber may attempt to re-register with the service if the provider continues to advertise the service. However, the service provider may deny the attempt.

4.5.4.1 (U) Revoke Retry (U//FOUO) If a service subscriber does not issue a Revoke Registration Response packet, in response to a Revoke Registration Request, within RequestTimeout, the service provider resends another Revoke Registration Request packet. The provider retries up to SolNetMessageRetries attempts before assuming that the peer node cannot or will not respond, and ceases attempting to revoke the service from the service subscriber. If the subscriber continues to send data to the provider on a consumer endpoint, the provider may continue to send Revoke Registration requests until successful revocation. See (U) SolNet Message Retries §5.8 for further details.

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page 17

4.5.5 (U) Example Service Registration (U//FOUO) The following figure shows service discovery followed by registration for a HUD and WS, where the HUD expects the WS to send it data without the need for constant polling.

Figure 4-4 (U) Example Registration

(U) Data Flow Initiation (U//FOUO) After registering with a service provider, the service subscriber may, based on service flow policy, tell the provider to start sending to the wireless interface data associated with the newly registered services. The SolNet messages for starting and stopping data flow is:

• (U//FOUO) Autonomous Flow – Packet telling the service provider to start sending data autonomously to the registered node or stop sending data autonomously to the registered node.

• (U//FOUO) Poll Request – Packet telling the service provider to poll data from the registered node.

(U//FOUO) Data flow requests shall only be made to active services. If a data flow request is made to any services that are not active (not registered), the service provider shall respond to the request with the Status field set to “Request Denied” (0x05).

(U//FOUO) SolNet data flow request messages, Autonomous Flow and Poll Request, shall only be initiated by the service subscriber.

(U//FOUO) Service providers that consume data (dataflow=consume), may flow control the reception of data in one of the following manners:

• (U//FOUO) Not advertising the service until the service is ready to receive data.

• (U//FOUO) Set the consumer endpoint data policy descriptor to utilize autonomous flow. The service subscriber shall not send data to the service provider, until a successful completion of the start Autonomous Flow. The service provider may flow control the consumer by responding to the autonomous start with the Status field set to “Resource not ready; retry” (0x0A) and Resulting Flow State field set to dataflow stopped. This response alerts the service subscriber to try again after the standard SolNet message timeout.

Browse Service

Service Advertisement

Get Status Request (optional)

Get Status Response

Register Request (automatic)

Register Response

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page 18

• (U//FOUO) Advertising the service but not allowing successful registration to succeed until the consumer service is ready to receive data. In this case, the consumer service shall respond to the request with the Status field set to “Resource not ready; retry” (0x0A). This response alerts the service subscriber to try again after the standard SolNet message timeout.

• (U//FOUO) Allowing registration of the service but discarding any received data until the service is ready.

• (U//FOUO) Allowing registration of the service but gating the start of data flow using application-specific out-of-band protocol carried by SolNet data packets.

4.6.1 (U) Data Flow Policies (U//FOUO) Each dataflow/endpoint descriptor contained within a service descriptor define whether it is influenced by the specific data flow request. The Data Policies field within the Endpoint descriptor specifies these behaviors. See (U) Endpoint Descriptor §6.9.2 for further details.

(U//FOUO) If an unsupported flow request (e.g. no descriptor data policy within the service supports that flow request), was received the service provider shall respond to the request with the Status field set to 0x09 (“Application policy violation”), as shown in Table 5-7.

4.6.2 (U) Automatic Flow (U//FOUO) If the service supports autonomous start on registration, and the service subscriber requests to start data on registration, the service provider may start communication immediately following a successful registration.

(U//FOUO) If an endpoint/dataflow has a dataflow policy, in which all flow control types are set to “Not Supported”, it may start communication immediately following a successful registration.

4.6.3 (U) Autonomous Start (U//FOUO) Data that flows freely and asynchronously may be controlled or gated with the use of start Autonomous Flow Request. This operation is only supported if the data flow policies for autonomous flow are met, see (U) Data Flow Policies §4.6.1 for details.

(U//FOUO) To start data flow, the service subscriber sends a start Autonomous Flow Request packet to the service provider. Upon receiving the start Autonomous Flow Request packet, the service provider returns an Autonomous Flow Response packet, at which time the service provider may start the transmission of data.

(U//FOUO) If a service requires an Autonomous Flow Request to initiate data flow, the service subscriber shall not send, if supported, any data to the service subscriber until the autonomous flow is started.

(U//FOUO) NOTE: SolNet messages and data packets may be on different endpoints, with different QoS settings. As such, and due to application implementations, it is possible to receive data packets from a start Autonomous Flow Request, before receiving the Autonomous Flow Response.

4.6.4 (U) Autonomous Stop (U//FOUO) To stop data flow, the service subscriber sends a stop Autonomous Flow Request message. On receipt of the stop Autonomous Flow Request message, the service subscriber shall immediately cease all data transmissions, on dataflow/endpoints defined as autonomous capable, and shall respond with an Autonomous Flow Response message, with the status set to 0x00 (“Successful”).

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page 19

4.6.5 (U) Polled Data (U//FOUO) A service subscriber may poll data, packet-by-packet, from the service subscriber, using the Poll Data Request message. This operation is only supported if the data flow policies for poll flow are met. See (U) Data Flow Policies §4.6.1 for details.

(U//FOUO) When a service is registered as a polling service, assuming it supports polling, it shall wait until the service subscriber initiates a Poll Data Request message before sending any data. Upon receipt of a Pull Data Request message, it shall first respond with a Pull Data Response message on the SolNet endpoint, followed by the data payload on the specific dataflow/endpoint.

(U//FOUO) NOTE: SolNet messages and data packets may be on different endpoints, with different QoS settings. As such, and due to application implementations, it is possible to receive a polled data packet from a Poll Data Request, before receiving the Poll Data Response.

4.6.6 (U) Examples (U//FOUO) The following figure shows service discovery followed by registration, autonomous start, and data flow for a HUD and WS.

Figure 4-5 (U) Example Data Flow Start, Autonomous

Browse Service

Service Advertisement

Register Request (automatic data)

Register Response

Data

Data

Start Request Start Response

UNCLASSIFIED//FOR OFFICIAL USE ONLY Page 20

(U//FOUO) The following figure…