Enclosure F - NOMS Demonstration Use Case.pdf

NETWORK ORCHESTRATION & MANAGEMENT SYSTEM (NOMS)

DEMONSTRATION REPRESENTATIVE USE CASE

The representative use case provides a structure to enable demonstration of capabilities to support management and orchestration of space communication services for a set of representative user missions. The desired outcome of the representative use case is a demonstration of integrated service management and orchestration capabilities in a “day-in-the-life” network operations scenario.

The use case is structured in two sections, which cover service planning and scheduling, and service monitoring and control, respectively. A vendor may choose to demonstrate capabilities in one or both sections, as appropriate for their product offering. If both capabilities are being demonstrated, then performance of the use case should begin with the service planning and scheduling section to generate a service schedule that serves as the basis for activity in the other section.

Appendix A contains a list of representative user missions, including LEO, GEO, and Lunar spacecraft. Each entry in the user mission list contains a selection of key characteristics, including orbit, service coverage requirements, and data link specifications. Vendors should use these characteristics as appropriate in their demonstrations. For any mission characteristics not explicitly specified, vendors may assume any reasonable configuration of their choice if necessary for the demonstration

Appendix B contains a list of representative space link providers, including both direct-to-earth (DTE) and space relay (SR) providers. The locations and service types listed for these space link providers should be used when planning and configuring services for the representative user missions. Vendors whose products include a pre-existing catalog of DTE and/or SR providers may choose to utilize that catalog in place of Appendix B.

SECTION 1: SERVICE PLANNING AND SCHEDULING

Prior to demonstrating the following functions, vendors should walk through the process by which the representative missions in Appendix A and the representative space link providers in Appendix B (or the vendor’s alternative provider set) have been integrated with the vendor’s product, including any necessary changes to software source code, databases, or static configuration files.

(1) The vendor’s product will receive and process provider availability data and spacecraft acquisition data to create a list of potential visibility / contact opportunities for the representative user missions. Vendors should simulate provider availability based on their choice of provider set, and use the orbital specifications listed in Appendix A for orbit calculations. Vendors may choose to simulate transfer of provider availability data from a simulated provider system (via API, file transfer, or other means).

(2) The vendor’s product will collect manual scheduling inputs (such as mission requests for specific contact opportunities) via an API and/or an interactive user interface. If both API and UI options are supported, vendors should demonstrate both, including any alternative user interfaces for different categories of users or operators.

(3) The vendor’s product will use the collected scheduling inputs and the known mission constraints to generate an integrated service schedule covering a seven-day forecast period.

Demonstration of schedule optimization based on specified criteria (such as service quality or cost) is preferred.

(4) The vendor’s product will distribute generated schedules and corresponding spacecraft acquisition data to providers. Vendors may choose to simulate transfer and provider acceptance/rejection of this data (via API, file transfer, or other means).

(5) The vendor’s product will receive and disposition schedule modifications during the active schedule period. Particular scenarios of interest for this include:

a. A launch delay, including any necessary propagation of launch vehicle acquisition data based on an updated launch time.

b. A spacecraft contingency that results in a need to reallocate a provider that was previously scheduled for a lower-priority mission.

c. An unplanned science event that causes surge demand for services from multiple missions.

d. A provider anomaly or asset failure that results in a need to reallocate a previously scheduled service to a different provider.

SECTION 2: SERVICE MONITORING AND CONTROL

Demonstration Scope Demonstration Scenario Tailoring Vendor is demonstrating both planning / scheduling and monitoring / control capabilities

Configure and monitor simulated resources for the specific service instances identified in the schedule generated in Section 1

Vendor is demonstrating monitoring / control capabilities only

Configure and monitor simulated resources for a sample set of services for the representative missions

Prior to demonstrating the following functions, vendors should walk through the process by which assets to be monitored and controlled are integrated with the vendor’s product, including any necessary changes to software source code, databases, or static configuration files.

(1) The vendor’s product will provision simulated network and provider assets to provide the scheduled services, including any processed schedule modifications.

(2) The vendor’s product will collect, aggregate, display, and distribute status data from the previously provisioned assets. If possible, this capability should be demonstrated both in an in-service state and in an out-of-service state.

(3) The vendor’s product will accept, validate, and execute a representative real-time request for reconfiguration of an active service.

(4) The vendor’s product will detect and respond to network conditions that impact active services, such as network link or asset outage, performance degradation due to environmental or weather conditions, or a similar scenario.

(5) The vendor’s product will generate network status, utilization, and accounting reports corresponding to the state of network resources, assets, and provisioned services. Vendors may additionally demonstrate options for accessing network status data via a database or other storage mechanism, if available.

APPENDIX A: REPRESENTATIVE MISSIONS

The network provides services to five representative missions.

M1 M2 M3 M4 M5 Priority 4 2 5 1 3 Type Robotic Human Space

Flight Robotic Human Space

Flight Launch Vehicle

# Spacecraft 3 Identical orbit, 3.2° separation

1 1 1 1

Orbital Regime

LEO LEO GEO Multiple

Launch

Orbit Altitude: 1,336 km Inclination: 66.0° Period: 112.0 min

Altitude: 413 km - 422 km Inclination: 51.64° Period: 92.9 min

Longitude: 75.2° W Altitude 35,780.2 km - 35,793.1 km Inclination:

0.0363° Period: 1,436.1 min

Launch (KSC) to LEO to Lunar Transfer to

NRHO

Launch (KSC) to

LEO

Requested Service

One 10-minute contact per spacecraft per orbit (S-band)

Near-continuous (S-band + Ka-band)

Near-continuous (S-band) 90 minutes per day (Ka-band)

Near-continuous (X-band + Ka-band) during all phases

Near-continuous (S-band) for 300 minutes

Scheduling Preference

Network automatically allocates contacts based on coverage requirement and mission priority

Network automatically allocates contacts based on coverage requirement and mission priority

Mission manually selects from available contact opportunities

Network automatically allocates contacts based on coverage requirement and mission priority

Network automatically allocates contacts based on coverage requirement and mission priority

Forward Link 1

S-band

PCM/PSK/PM

Frame data

(CCSDS TC)

BCH coding 500 kbps

S-band

BPSK

Frame data

(CCSDS AOS)

R/S + Viterbi coding 500 kbps

S-band

BQPSK

Frame data

(CCSDS TC)

BCH coding 100 kbps

X-band

OQPSK

Frame data

(CCSDS AOS)

R/S + Viterbi coding 10 Mbps

N/A

Forward Link 2

N/A Ka-band

OQPSK

Encapsulated video + frame data

(CCSDS AOS)

LDPC coding 300 Mbps

N/A Ka-band

OQPSK

Encapsulated video + file data via CCSDS DTN LDPC coding 200 Mbps

N/A

Return Link

S-band

SQPSK

Frame data

(CCSDS AOS)

R/S + Viterbi coding 1 Mbps

S-band

OQPSK

Frame data

(CCSDS AOS)

R/S + Viterbi coding 1 Mbps

S-band

OQPSK

Frame data

(CCSDS AOS)

R/S + Viterbi coding 1 Mbps

X-band

OQPSK

Frame data

(CCSDS AOS)

R/S + Viterbi coding 10 Mbps

S-band

BPSK

Frame data

(CCSDS AOS)

Viterbi coding 2 Mbps

M1 M2 M3 M4 M5 Return Link

N/A Ka-band

OQPSK

Encapsulated video + frame data

(CCSDS AOS)

LDPC coding 300 Mbps

Ka-band

OQPSK

File data via CFDP LDPC coding 400 Mbps

Ka-band

OQPSK

Encapsulated video + file data via CCSDS DTN LDPC coding 200 Mbps

N/A

Requested Interface

LEO-T (frames) VITA-49 BB (frames) IP (video)

CCSDS SLE

(frames) SFTP (files)

CCSDS SLE

(frames) SFTP (files) IP (video)

DTN

CCSDS SLE

(frames)

APPENDIX B: REPRESENTATIVE PROVIDERS

The network consists of 15 direct-to-earth (DTE) SLPs and 4 space relay (SR) SLPs.

DTE Aperture Location Forward Link Capability

Forward Link EIRP (dBW)

Return Link Capability

Return Link G/T (dB/K)

Available Interfaces

DTE-SLP01 64.8° N

147.8° W

S-Band 64.6 S-Band X-Band

22.0 35.2

SLE (FCLTU / RAF)

IP

DTE-SLP02 64.7° N

147.5° W

S-Band Ka-Band

87.5

S-Band X-Band Ka-Band

21.4 35.0 41.5

SLE (FCLTU / RAF)

IP

DTE-SLP03 25.8° S

27.7° E

S-Band 69 S-Band 22.4 SLE (FCLTU / RAF)

LEO-T (CDH / TFDH)

IP

DTE-SLP04 19.0° N

155.6° W

S-Band 78 S-Band X-Band

23.5 37.7

SLE (FCLTU / RAF)

IP

DTE-SLP05 29.0° S

115.3° E

S-Band 68 S-Band X-Band

23.5 37.7

SLE (FCLTU / RAF)

IP

DTE-SLP06 32.5°N

106.6°W

S-Band 72 S-Band Ka-Band

29.6 46.9

SLE (FCLTU / RAF)

IP

DTE-SLP07 67.8°N

21.0°E

S-Band 69 S-Band X-Band

23.0 33.0

SLE (FCLTU / RAF)

IP

DTE-SLP08 77.8° S

166.6° E

S-Band 63 S-Band X-Band

21.0 32.0

SLE (FCLTU / RAF)

IP

DTE-SLP09 72.0°S

2.0°E

S-Band Ka-Band

S-Band X-Band Ka-Band

19.4

SLE (FCLTU / RAF)

VITA-49 BB

IP

DTE-SLP10 78.2°N

15.3°E

S-Band 63.5 S-Band X-Band

22.1 36.8

SLE (FCLTU / RAF)

IP

DTE-SLP11 78.2°N

15.4°E

S-Band 67 S-Band X-Band

23.0 37.8

SLE (FCLTU / RAF)

IP

DTE-SLP12 52.9° S

70.9° W

S-Band Ka-Band

88.1

S-Band X-Band Ka-Band

SLE (FCLTU / RAF)

IP

DTE-SLP13 33.1° S

70.6° W

S-Band 79 S-Band 24.4 SLE (FCLTU / RAF)

LEO-T (CDH / TFDH)

IP

DTE-SLP14 1.3°N

103.8°E

S-Band 59 S-Band X-Band

20.5 33.4

SLE (FCLTU / RAF)

IP

DTE-SLP15 37.9° N

75.4° W

S-Band Ka-Band

S-Band X-Band Ka-Band

21.4 35.0 41.5

SLE (FCLTU / RAF)

VITA-49 BB

IP

Relay Node Location Forward Link Capability

Return Link Capability

Available Interfaces

SR-SLP01 Geosynchronous orbit at 46° W, Central Body = Earth

S-Band Ka-Band

S-Band Ka-Band

SLE (FCLTU / RAF)

LEO-T (CDH / TFDH)

Relay Node Location Forward Link Capability

Return Link Capability

Available Interfaces

SR-SLP02 Geosynchronous orbit at 167° W, Central Body = Earth

S-Band Ka-Band

S-Band Ka-Band

SLE (FCLTU / RAF)

VITA-49 BB

LEO-T (CDH / TFDH)

SR-SLP03 Geosynchronous orbit at 275° W, Central Body = Earth

S-Band Ka-Band

S-Band Ka-Band

SLE (FCLTU / RAF)

VITA-49 BB

LEO-T (CDH / TFDH)

SR-SLP04 12-hour Lunar frozen orbit, Central Body = Moon

S-Band Ka-Band

S-Band Ka-Band

SLE (FCLTU / RAF)