# Presentation: 468801

## Space Network MA Fast Forward System Requirements Review (SRR)

**February 15, 2006**

## Agenda

**Section 1. Introduction ****	****	****Andre Fortin/NASA**
**Section 2. Product Planning ****	****	****Denise Gilliland/ITT****	**
**Section 3. MAFF System Description  ****	****     Richard Broomandan/ITT****NENS Study - Reaction Time Reduction ****	****WSC****Study**
**Section 4. MAFF System ****	****	****Richard Broomandan/ITT **** Requirements ****	****     Denise Gilliland/ITT**
**Section 5. Operational Concept ****	****	****Richard LaFontaine/ITT  **
**Section 6. Risks and Risk Mitigation****	****	****Andre Fortin/NASA**
**Section 7. Summary & Action Items****	****	****Andre Fortin/NASA**
**Backup Material****RFAs, Trade Studies, etc.**

## MA Fast Forward System Requirements Review

**  ****Section 1**** Introduction**
***Andre Fortin/NASA***

## Section 1. Purpose of this Review

**Conduct a requirements review of the MA Fast Forward Product, to include:**
- Product description and background
- Architecture description, requirements definition, and operational concepts
- Product planning status
- Risks and issues
**Present preliminary results from NENS MAF Reaction Time Reduction Study**
**Place the project on hold after a final SRD, OCD and draft Security Plan has been issued**

## Section 1. Where We Are

**Concept Review was held July 26, 2005**
**Five Requests For Actions (RFAs) generated:**
**See backup material for copies of RFAs**

## Section 1. Review Board

**Tom Gitlin – NASA **
**Steve Tompkins – NASA**
**Tim Rykowski – NASA**
**Ronna Brockdorff – ITT **
**Dave Zillig – QSS **
**David R Torrealba - SRSTE **

## Section 1. What is MA Fast Forward?

**MA Fast Forward is an SN Product that will accomplish the following:**
- Provides new SN Operational capability which enhances  the MA/SMA forward service by removing the need of user scheduling
- Enables almost immediate access to MAF service by the user (unmanned operations, science & emergency events etc.)
- Enables reduction in SN & Customer operational constraints
- Improves the SN network service utilization (rapid utilization of unused times)
- Provides a potential reduction in MAF inter-service time
- Provides complementary on-demand service similar to DAS

## Section 1. Potential MAFF Customers

**Potential SN MAFF Users that have been contacted (emails and presentations)**
- SWIFT
- GLAST
- Global Precipitation Measurement (GPM) Mission
- Long Duration Balloon Program/Ultra Long Duration Balloon Program
- AQUA
- AURA
- HST
- XTE (has expressed interest in utilizing MA Fast Forward product, refer to back-up section)
**If project resumes after SRR, the MA Fast Forward Product team will continue to coordinate with potential customers.**

## Section 1. MAFF System Requirements  Summary

-  Low-complexity/low-risk MAFF implementation is feasible
-  Insertion of stand-alone, MAFF work station within GT
-  Straightforward interface with existing GT subsystems
-  Efficient integration into current MAF operations
-  Current MAF loading  ~  20%
-  WSC assessments to date indicate potential for < 3.5 mins (for F1-F7) and < 8.5 mins (for HIJ) latency from user request to service start
-  Net program risk is very low
-  Risks and mitigation strategies have been identified
-  Software modifications to existing CSCI’s is the highest risk component
-  Present completed SRD and OCD to Peer Review Board and SN CCB for  approval

**Section 1. MAFF***** *****System Requirements  Summary**

## MA Fast Forward System Requirements Review

**Section 2****Product Planning**
***Denise Gilliland/ITT***

## Section 2. Product Organization

**SN Project Manager**
- Keiji Tasaki
- Code 452

**MAFF Product Design Lead (Acting)**
- Andre Fortin
- Code 452

**Resource/Business Manager**
- Paula Tidwell
- Code 452

**Implementation Contractor**
- NENS

**Systems Engineering Contractor**
- ITT/HTSI

**NASA Technical Lead**
- Dave Israel
- Code 567

**Documentation Configuration Control**
- PAAC-II

## Section 2. MA Fast Forward Product Status

**Where are we now?**
- Weekly team meetings are ongoing
- Approved final version of PCD and PMP
- Final drafts of SRD and OCD
- Draft Security Plan
- Completed 5 Trade Studies (refer to “MAFF Trade Studies” section for current status). Completed system simulations.
- Contacted potential MAFF customers & performed survey
- MAFF survey questioner and corresponding XTE responses are included in Back-up section
- A NENS task has been issued to assist with requirements development and provide a feasibility study into inter-service time reduction

## Section 2. MA Fast Forward Trade Studies

**MA Fast Forward Service Loading Analysis  *****Completed***** **
- Largest users of MAF/SMAF service
- Region (EAST-WEST-ZOE) MAF loading distribution
- Mean, Max and Average of service times
- Mean, Max and Average of Gap times( unused times between MAF services)
**MA Fast Forward Service Considerations Study  *****Completed***** ****(combined with Ops Concept Recommendations Study below)**
**MAFF Operations Concept Recommendations  *****Completed***** ****(combined with Service Considerations Study above)**
**MA Reaction Time Reduction Feasibility Analysis  *****Completed***
**User Authentication Requirements Recommendation  *****Complete***
**MA Fast Forward Performance Analysis Plan & Study (potential simulations)  *****Plan Completed; Simulations completed***

## Section 2. Product Documentation Status

**MA Fast Forward documentation deliverables:**
- 452-PCD-FF, the MAFF Project Commitment Document (PCD) (CCB approved May 12, 2005)
- 452-PMP-MAFF, the MAFF Product Management Plan (PMP) (CCB approved January 30, 2006)
- 452-OCD-MAFF, the MAFF Operations Concept Document (OCD)  (final draft)
- 452-SRD-MAFF, the MAFF System Requirements Document (SRD) (final draft)
- 452-SP-MAFF, the MAFF Security Plan (SP) (draft in work)
- 452-ICD-MAFF/XXX, MAFF External ICDs
- 452-ICD-PVM, MAFF Performance Verification Matrix

## Section 2. MA Fast Forward High-level Schedule

**MA Fast Forward High-level Schedule:**
- Concept Review (CR): July 2005
- System Requirements Review (SRR): February 2006
- System Design Review (PDR/CDR): TBD*
- Test Readiness Review (TRR) : TBD*
- Implementation Complete/Operations Readiness Review (ORR): TBD*
- Complete Transition to Operations/Sustaining Engineering:  TBD*
****Effort ends after SRR due to funding.***

## Section 2. MA Fast Forward Product Schedule

## MA Fast Forward System Requirements Review

**Section 3****MAFF System Description**
***Richard Broomandan/ITT***** **
** **
**NENS Study - Reaction Time Reduction**** ****Study**
***WSC Personnel/NASA**** *** **

## Section 3. MA Fast Forward High Level Data Flow Diagram

**MOCC**

**MOCC**

- •
- •
- •

- Ku-SGL

- MAF/SMAF

**USAT Segment**

**TDRSS Space Segment**

**TDRSS Ground Segment**

**MOCC/IONet Segment**

**MAFF Data Packet**

- Send commands/data to Ground Segment for broadcast to user satellite
- No prior scheduling

- MAF/SMAF

- User 1

- User N

-   

- Relay MA, SMA Fast Forward signal To USAT

- Verify user parameters
- Determine USAT visibility and select transmission  time
- Manage queue
- Coordinate & control ground equipment
- Provide MOCC interface

**MAFF**** System**

**TT&C**

**USS**

** ****LRS**

**NCCDS**

**  ****RF**

- Receive MA Fast Forward service signal

**Section 3. MA Fast Forward ****High Level Data Flow Diagram**

## Section 3. General MA Fast Forward Service Concept Description

**From the spacecraft perspective, a MAFF event looks exactly like a short MA forward event**
- MA Forward: 0.1 to 300 kbps
- Full MA/SMA Forward EIRP (34 dBW/42 dBW)
- Database scheduled user MAF data rate
- User’s normal PN user code
**Basic concept is of a data driven control center proxy**
- Forward link data is generated at a user control center and sent via IONet to the MAFF Workstation (FWS)
-  Upon receipt of the data, the MA FWS:
- Verifies the data source (authentication) and queues up the data
- Schedules an MA forward link for the next unscheduled available time
- Reports the schedule time of forward link to the User’s MOC
- At the time of the MAFF event, the FWS transmits the data over the MA forward link and reports data transmitted to the user’s MOC
**MAFF System Interfaces with:**
- WSC scheduling, control, and status systems (NCCDS or SWSI or SNAS)
- NISN IONet
- LRS (Low Rate Switch)

## Section 3. MA Fast Forward Reference Architecture

- Ku-SGL

- Data
- Database
-   Updates

_***Service Concept***_

**RF**

**Mod**

**LRS**

**2) MAFF MOCC **
**Interface **
**Segment**

**TT&C**

**MOCC**

**MOCC**

- •
- •
- •

**Beam Pointing **
-  Dedicated to one customer at a time

- MA, SMA FWD

**1) MAFF Ground**
**       ****Segment**
**Security Check**
- •**Database**
**Data Queue**
**Control & Status**

- Data

- Data
- Database
- Status

- Data
- Database
- Status

**NCCDS**

**1. All user data + ID enters FWS in real-time**
**2. User data queued on first-come-first-served**
**    ****basis **
**3. Minimum delay between MA FWD services**
**    ****ranges from 1.5 min (or less) to 8.5 min (depending on  degree of upgrade feasible)**
**4. User MA Forward event duration of minimum 30 sec to 5 min maximum occurs.  FWS forwards queued data.**

-  ACK/NACK
-  Status

**MAFF**
**System **
**Segments**

**Section 3. MA Fast Forward ****Reference Architecture**

## MA Fast Forward System Requirements Review

**                   ****MAFF WSC Reaction Time Reduction **
**                                ****Feasibility Study**** **

## Option 1 – FF SAR Capability 

- The FF SAR would be sent from a front-end server, and expedited through the NCCDS
- The SAR would be identified as an MAFF request using a special SUPIDEN (e.g. xyyyy’FF’)
- Upon receipt of the MAFF request, the lead-time required for this option is 3 1⁄2 minutes for F1-7, and 8 1⁄2 minutes for F8-10 (HIJ)

## Option 2 – Continuous Scheduling of MAF 

- WSC software would continuously schedule MAF unused time (updated each hour)
- By continually scheduling unused time, a user would have the ability to get in a MAF service very rapidly
- The FF SAR would be sent from a front-end server, and expedited through the NCCDS
- Upon receipt of the MAFF request, the lead-time required for this option is 3 1⁄2 minutes for all TDRS

## Option 3 – Continuous Server Scheduling of MAF 

- The MAFF server schedules MAF unused time (Schedules will be submitted to the NCCDS)
- By continually scheduling unused time, a user would have the ability to get in a MAF service very rapidly
- Upon receipt of the MAFF request from the server, the lead-time required for this option is 90 seconds

## MA Fast Forward System Requirements Review

**Section 4****MAFF System Requirements **
***Richard Broomandan/ITT***
***Denise Gilliland/ITT***

## Section 4. MAFF System Requirements

**SRD Section 4.1.1 General Functional Requirements**
- Support all TDRSS MA Forward and SMAF non-coherent (Mode 2) services
- Allow for services from Closed/Restricted IONet networks
- The MAFF system shall locally store, at WSC, service setup service profiles for all MAFF customers
- Accept command loads, on a real time basis, from the user MOCCs
- Interface with NCCDS to select and schedule the optimum transmission time
- MAFF system queuing scheme will be First Come First Served (FCFS), subjected to TDRS/User availability

## Section 4. MAFF System Requirements (cont.)

**SRD Section 4.1.2 General Performance Requirements**
- Support all TDRSS MA forward data rates supported by the SN
- Support up to 8 simultaneous MA forward services
- Six SGLTs, with potential  to use two HIJ spacecrafts with dual SMAF links
- Support an initial minimum of 32 concurrent users
- MAFF scheduling shall cause no loss of customer data for any regularly scheduled MA forward event

## Section 4. MAFF System Requirements (cont.)

**SRD Section 4.2.1 Service Setup Functional Requirements   **
- Provide the capability to create and modify service profiles by the customer
- Receive and Verify the service profile parameter values entered for the customer
- Acknowledge the customer upon successful/failed service profile verification
- Locally store, at WSC, the verified service profile
**SRD Section 4.2.2 Service Setup Performance **
- Configuration time for the MAFF system will be 5 seconds in conformance with present WSC hardware specifications

## Section 4. MAFF System Requirements (cont.)

**SRD Section 4.3.1 Service Authentication Functional Requirements **
- Identify the user by it’s SIC, User ID and IP address
- Authenticate customers using passwords
- Acknowledge the customer upon successful/failed identification or authentication

## Section 4. MAFF System Requirements (cont.)

**SRD Section 4.4.1 Vector Processing Functional Requirements**
- Obtain user state vectors from the NCCDS
- Accept user state vectors from SWSI
- Obtain TDRS state vectors from “Exec ADPE” residing at WSC
- Calculate USAT visibility intervals, including TDRS to USAT line-of-sight visibility (applying any “limb-of-earth” bias defined in user profile)
**SRD Section 4.4.2 Vector Processing Performance**
- USAT visibility accuracies will be in accordance with MA forward service requirements specified in 530-RSD-WSC

## Section 4. MAFF System Requirements (cont.)

**SRD Section 4.5.1 Data Processing and Transmission  Functional Requirements **
- Accept user command loads with data processing and transmission parameters from customers via the MAFF MOCC interface segment
- Verify the integrity of the received command loads
- Calculate the command loads length, TDRS to USAT visibility, SN availability
- Select the optimum transmission time based on the TDRS to USAT visibility, SN availability, command loads length

## Section 4. MAFF System Requirements (cont.)

**SRD Section 4.5.1 Data Processing and Transmission  Functional Requirements (continued)**
- Queue the received user command loads for transmission
- Apply the Time-To-Live constraint selected by the customer
- Accept user command load cancellation request prior to transmission
- Forward the customer command loads to the appropriate SN MAFground equipment upon the start of transmission time
- Notify the customer of a successful/failed command load transmission

## Section 4. MAFF System Requirements (cont.)

**SRD Section 4.5.2 Data Processing and Transmission Performance Requirements**
- The MAFF system maximum user command load length shall be between 5 minutes and 15 minutes.
- The MAFF system queue size shall be a minimum of 1 gigabyte

## Section 4. MAFF System Requirements (cont.)

**SRD Section 4.6.1 Service Status/Statistics Functional Requirements**
- Receive customer requests for USAT visibility update for the next hour after sending the request.
- Obtain the unused TDRS time updates from NCCDS
- Format and transmit the near term, 1 hour max, TDRS to USAT visibility and SN availability to the customer upon request

## Section 4. MAFF System Requirements (cont.)

**SRD Section 4.7.1 Service Test Functional Requirements**
- Receive and Validate customer requests for a MAFF system Ground Link test
- Perform the Ground Link test (data reception evaluation)
- Provide Ground Link test results to the user MOCC upon the completion of the Ground Link test
**SRD Section 4.7.2 Service Test Performance**
- Indicate via an operator alert when abnormalities are detected in the MAFF system as a result of Ground Link tests within 5 seconds

## Section 4. MAFF System Requirements (cont.)

**SRD Section 4.8.1 Resource Allocation and Configuration Functional Requirements**
- Format and transmit response messages with service performance information for SN reporting purposes
**SRD Section 4.8.2 Resource Status Functional Requirements**
- Provide an interface for SN O&M personnel
- Provide the capability for SN O&M personnel to manage MAFF Service Setup Profiles
- Provide the capability to collect and log O&M personnel actions, alerts, error messages and status on each customer’s requested, scheduled and actual MAFF resource usage etc

## Section 4. MAFF System Requirements (cont.)

**SRD Section 4.9 Interface Requirements**
- MAFF will interface with the user MOCC in accordance with 452-ICD-MAFF/MOCC
- MAFF will interface with WSC systems in accordance with 452-ICD-MAFF/WSC

## Section 4. MAFF System Requirements (cont.)

**SRD Section 5 Reliability, Maintainability, and Availability**
- Standard SN RMA definitions and computations
***Reliability*** is characterized by Mean Time Before Failure
***Maintainability*** is characterized by Mean Time to Repair
***MAFF Requirements:***
- Mean Time to Repair (MTTR): Not to exceed 30 minutes for 10 yr lifespan
- Max Time to Repair: Not to exceed 60 minutes for 90% of failures
- A I, Inherent availability: 0.9998 (for any 10,000-hour period)
- Ao, Operational availability: 0.9998 (for any 10,000-hour period)
- Redundancy will  be used, as needed, to reach availability numbers
- Failures shall be isolated to one chassis or LRU
- Will meet the same availability requirements as existing WSC systems

## Section 4. MAFF System Requirements (cont.)

**SRD Section 6.1 Security**
- MAFF shall follow all NASA and NISN security requirements, as required
- NPR 2810.1, *NASA Procedural Requirements for Security of Information Technology*
- NITR 2810-2 *NASA IT System Security Requirements*
- NITR-2810-4*, IT System Certification and Accreditation and Authorizing Systems for Operation*
- GPG 2810.1, *Security of Information Technology*
- GPD 8710 *Space Asset Protection Policy (Draft-NASA internal review)*
- 290-003, *IONet Access Security Plan*
- 290-004, *IONet Access Protection Policy and Requirements*
- WSC-PLN-0024, *IT System Security Plan for WSC*

## Section 4. MAFF System Requirements (cont.)

**SRD Section 6.2 Security**
- Every MAFF User will have a User ID that is registered with O&M personnel
- Every user shall have a password that satisfies the requirements set forth in the 452-SP-MAFF
- The MAFF system shall restrict the number of failed login attempts as specified in 452-SP-MAFF.
- The MAFF system shall only accept inputs from authorized users
- The MAFF shall ensure that users have access to only their data
- The MAFF system shall provide the capability for SN O&M personnel to manage all MAFF account IDs and passwords

## Section 4. MAFF System Requirements (cont.)

**SRD Section 7 Equipment Design, Construction, and Installation**
- Standard SN STDN and MIL-STD specs for the following:
- Equipment
- Electronic Equipment Racks
- Cabling and Connectors
- Electromagnetic Interference
- Modularity and Expandability
- Equipment Installation
- Waivers/approval of PDL accepted, as needed, due to “dated” STDN specs

## Section 4. MAFF System Requirements (cont.)

**SRD Section 8 Maintenance Requirements**
- Hardware 1st and 2nd level Maintenance done at WSC and will follow standard SN maintenance processes
- Software maintenance done at WSC SMTF
- Spares provisioning to be determined by contractor and approved by NASA
- The proposed spare parts and quantities shall be based upon satisfying the availability and maintainability requirements of this Requirements Document.
- Spare parts available for 10 years after Final Acceptance Testing

## MA Fast Forward System Requirements Review

**Section 5****MAFF Simulation Model Results &**
**Operational Concept **
***Richard LaFontaine/ITT***

## MAFF Simulation Model Scope

**Validate the Effectiveness of proposed service functions**
- Equal or unequal MAFF event size
- Rapid-schedule beam pointing model (current method) and a beam-hopping pointing technique
- First Come First Serve (FIFO concept) Queue versus Fair Access Queue
**Analyze the Service Performance**
- Average network latency
- Optimum time slot size
- Service loading as a function of user traffic profile
- System throughput
- Queue usage
**Select optimum ****recommended ****specification values**
- Minimum queue size
- System processing throughput

**     ****All simulations are based on a 90 sec inter-service setup time**

## Results/Conclusions

**A 5 minute average MAFF event size will provide an average delay of less than 9 minutes for 32 simultaneous MAFF users (8x capacity Increase/worst case scenario)**
**Rapid-Schedule Beam Pointing (current method) is the optimum**** be****am pointing scheme for MAFF service**
- Decreases the latency of the network
- Beam-Hopping Beam pointing provides an advantage for highly mobile networks but is not optimum for MAFF

## Results/Conclusions (cont.)

**Unequal MAFF event size processing was selected as the event slot time to transmit user data**
- Offers a greater network efficiency and decreases the latency of the network by a large amount
**FCFS Queuing Versus FQ (Fair Queuing) scheme**
- FCFS queuing scheme meets the MAFF system requirements in terms of service provisioning latency
- FQ queuing will be considered as a potential replacing queuing methodology in the case of a highly congested network (future enhancement)
**Optimum specification values based on the 32 simultaneous MAFF users:**
- MAFF system queue size will be a minimum of 1 gigabyte based on the 32 simultaneous MAFF users
- Maximum System processing throughput will be 300kb/s per an uplink channel (highest MAF data rate)

## Section 5. MA Fast Forward Operations Concept Recommendations (Study D)

|  | LOW | MEDIUM | HIGH |
| --- | --- | --- | --- |
| LOW | -Fixed Time Slot Processing 
-Large Packet Support
 | -MAF Time Availability Status
-Ground Connectivity Test
-Data Formatting | -View User Profile
-Update User Profile 
-Initiation Request Response
-User Data Formatting
-Time-to-Live
-Data Transmission
-User Status Notification  |
| MEDIUM | -Service Performance Statistics
-Virtual Uplink Test 
 | -Cancellation Request
- TDRS Selection
 | -Service Initiation Request
-User Parameter Verification 
-Unequal Time Slot Processing 
-Queue Management
-Communication Path Setup |
| HIGH | 
-Data Prioritization
 |  | -USAT Visibility Determination
-Transmission Time Scheduling
 |

**INCREASE NEED**

**INCREASE COMPLEXITY**

**RECOMMENDED  AS INITIAL SYSTEM **
**FUNCTIONS FOR IMPLEMENTATION  **

**   ****Evaluated Versus Selected MAFF Functions**

**NEED**

**COMPLEXITY**

## Section 5. General Operations Concept Data Transmission

**         ****Service                 Authentication**
**       ****Function**

**Data Processing &       Transmission**
**      ****Function**

**          ****Service     Status/Statistics**
**         ****Function **

-      **Service Test **
**         ****Function**

**Section 5. General Operations Concept ****Data Transmission**

**  ****MAFF System **
**    ****Functions**

**    ****Service Setup **
**       ****Function**

## Initial Operating Scenario

**Customer can view and modify service profiles **
**Customer will be authenticated before sending MAFF data to the TDRSS Ground Terminal Segment (Non-interactive authentication)**
**USAT visibility calculations will determine TDRS line-of-sight to USAT for omni-directional antenna service **
**TDRSS Ground Segment will select a transmission time based on current USAT visibility and SN availability, command load length **
**Customer can provide optional parameters which include time-to-live, Limb time considerations etc.**
**TDRSS Ground Segment will manage the transmission of customer data based on network loading, coverage, and selected customer options (Queue Management)**

## Initial Operating Scenario (Cont’d)

**TDRSS Ground Segment will schedule all necessary resources and prepare the communication path for the transmission of the customer data to the customer Spacecraft**
**Customer can cancel the requested MAFF operation before the data is transmitted**
**TDRSS Ground Segment will notify the user that the data packet has been transmitted or discarded**
**Visibility and SN Availability will be provided upon request **
**Ground connectivity test feature will provide service readiness and trouble shooting capabilities**

## MA Fast Forward System Requirements Review

**Section 6****Risks & Risk Mitigation**
***Andre Fortin/NASA***

## Section 6. Risk/Risk Mitigation

_**RISK #1**_
**The MAFF Product system is required to interface with existing scheduling, control and monitoring systems which could result in a complex design and implementation.**
**Consequence: Medium (schedule delay, cost estimate increase, increased complexity)**
**Likelihood: Medium **
**Mitigation: **
- Early involvement of NENS contractor and WSC personnel
- Coordination with SN Access System (SNAS) Product, NCCDS and NISN
**Status: Open**

## Section 6. Risk/Risk Mitigation

_**RISK #2**_
**Attracting a Customer base. MAFF Product will probably require changes to user POCC hardware/software and operations. Existing customers may resist the required changes to their own systems **
**Consequence: Low (architectural change, schedule delay)**
**Likelihood: Low**
**Mitigation:**
- Conducted an early customer survey for realization of MAFF customer features
- Space Communications Program and MAFF PDL working closely with potential MAFF customers in defining their communications and scheduling requirements
- Considering alternative architectural scenarios as a substitute  for a potential change
**Status: Open**

## Section 6. Risk/Risk Mitigation

_**RISK #3**_
**The MAFF Product system requirements are not fully defined.  The requirements/functionality of the system may vary dramatically during concept review.  Some requirements/customer recommendations may be contradictory to other customer recommendations. These conditions could lead to increases in cost estimates and slips in schedule. **
**Consequence: High (schedule delay, cost estimate increase)**
**Likelihood: Moderate **
**Mitigation:**
- Conducted studies, customer surveys, customer reviews andConcept Review to finalize system requirements
**Status: Closed**

## Section 6. Risk/Risk Mitigation

_**RISK #4**_
**The MAFF Product will probably result in enhancements/changes to existing user interface operational systems, such as SWSI, DAS, and TUT. These changes will impact operations as the systems are upgraded.  Customers may need to be trained if the SWSI/DAS/TUT operational interfaces change.**
**Consequence: Low to Moderate (schedule change)**
**Likelihood: High **
**Mitigation: **
- Keep operational personnel and customers informed to the changes required to SN systems via design review(s)
- Involve SN NASA, HTSI engineering personnel
**Status: Open**

## MA Fast Forward System Requirements Review

**Section 7****Summary **
***Andre Fortin/NASA***

## Section 7. Wrap-Up and Action Items

**Next Steps:**
- Evaluate NENS MAF Reaction Time Feasibility Study
- Address SRR RFAs and update appropriate documents
- Finalize SRD/OCD
- Put project on indefinite hold
**Board Review:**
- RFAs
- Discussion and approval of requirements

## Section 7. MA Fast Forward Contact Information

**MAFF Product Design Lead**
- Andre.Fortin@nasa.gov
- NASA/GSFC Code 452
- (301) 286-7829
**MAFF Technical Design Lead**
- Dave.Israel@nasa.gov
- NASA/GSFC Code 567.3
- (301) 286-5294
**MAFF web server**
- http://fastforward.gsfc.nasa.gov/

## 

	BACKUP MATERIAL

***	******BACKUP MATERIAL***

## 

	Future Expandability Requirements

***	******Future Expandability Requirements***

## Backup Material : Future Expandability Requirements

**SRD Section 4.10 Future System Expandability **
- Allow system expandability for a minimum of 8 _**return**_ services (DAS/Legacy)
- Concatenate (optionally) received user command loads with previous user command load (s) in the queue
- Subdivide received user command loads, as necessary, at their byte boundary into multiple frames that do not exceed the maximum MAFF event slot size
- Provide for future modifications to allow utilization of additional types of queuing schemes (e.g., Fair Access Queuing (FQ))

## Section 4. Future Expandability Requirements (cont.)

**SRD Section 4.10 Future System Expandability (continued)**
- Provide for future modifications to allow storage of user priority data and transmission of user data based on user’s priority
- Provide the capability to perform Virtual Uplink test (customer data reception and queuing process evaluation)
- Provide for the capability to add pre and/or post ambles to user command loads

## Backup : Future Evolutionary Concepts

**The following Concepts could potentially expand the future MA Fast Forward system characteristics or operational capabilities:**
- Support of coherent operations
- Potential planning for ground upgrades to expand number of MA FWD links for dedicated MAFF links
- Further Reduction in beam pointing reaction time

## Definitions (page 1 of 2)

| MA Fast Forward Workstation (FWS)
 | Workstation (Hardware and Software) at the Ground Segment which: 1) Validates the user information as a service order, 2) Determines availability of resources, 3) Schedules Resources, 3) Transmits user data and 4) Notifies the user of the disposition of the service order |
| --- | --- |
| Beam Hopping | MAFF architecture concept where the beam hops in 20-30 sec increments. A prior known beam-hopping pattern, based on state vectors of a user set is used.  Known hopping pattern permits extended period SHO |
| Sensor Web Applications | Sensor web is an application where data gathered by one node (below) is continuously both shared and used by other nodes to obtain environmental self-awareness over a large areas (e.g., other planets or unexplored areas etc.) |
| Data Frame | Data Frame is a chunk of data, frequently with some soft pattern of bits at the start (called a header) and bits at the end (called a trailer). |
| Data Packet | A stream of binary octets (bytes) of data of some arbitrary length.  It is typically used to describe chunks of data created by software, not by hardware. |
| PDU (Protocol Data Unit) | A protocol data unit is a term used in much of the documentation and educational literature for networking technologies. It simply means a chunk of data created and/or labeled by the protocol being discussed. |
| Datagram | A datagram is a chunk of data, usually containing some sort of message, this term is often used in describing protocols that function at higher levels of the OSI model (network layer and up). For instance it would be proper to say TCP uses datagrams. |

## Definitions (page 2 of 2)

| Data delay | The time it takes for an MAFF packet to be transmitted measured from arrival at the ground terminal until it's been forwarded to the MA forward chain for relay to the user spacecraft.
 |
| --- | --- |
| Time-to-Live | An MAFF function that provides a set time limit for completing the transmission of a given MAFF data packet.  |
| Node
 | User spacecraft as viewed by the MAFF equipment at the Ground Segment
 |

## 

MAFF Concept Review RFAs

***MAFF Concept Review RFAs***

## Backup Material : Concept Review RFAs

## Backup Material : Concept Review RFAs (cont.)

## Backup Material : Concept Review RFAs (cont.)

## Backup Material : Concept Review RFAs (cont.)

**Attachment to RFA 452/241-5**

## Backup Material : Concept Review RFAs (cont.)

## Backup Material : Concept Review RFAs (cont.)

## Backup Material : Concept Review RFAs (cont.)

## Backup Material : Concept Review RFAs (cont.)

## Backup Material : Concept Review RFAs (cont.)

## Backup Material : Concept Review RFAs (cont.)

## Backup Material : Concept Review RFAs (cont.)

**Attachment to RFA 452/241-5**

## Backup Material : Concept Review RFAs (cont.)

## Backup Material : Concept Review RFAs (cont.)

## 

MAFF Inherent and Operational Availability Definitions

***MAFF Inherent and Operational Availability ***_***Definitions***_

## Availability

*Inherent Availability (Ai) is the probability that a system or equipment, when used under stated conditions in an ideal support environment (i.e., using available tools, spares, and personnel) will operate within specifications at all times.  It excludes preventive maintenance actions, logistics supply time, and administrative downtime*** **
**Ai =  ****	****       **_*MTBF*_*	**	**(MTBF + MTTR)*
*The Operational Availability (Ao) of the MAFF is defined in terms of each MAFF forward customer service.*** **
**Ao = ****	****	**_*Time Service is Available*_* ** **	**(Time Service is Available + Time Service is Not Available***)**

## 

MAFF Trade Studies

***MAFF Trade Studies***

## Backup. MAFF Concept Implementation Questions?

**1.****	****What is the current network loading and will MAFF require new RF strings of equipment? **
**2.****	****What is the estimated service latency?**
**3.****	****What is the impact of increasing MAFF population on service performance; i.e., efficiency of system?**
**4.****	****What will be the authentication and security requirements for a near-real time service?**
**5.****	****Can we minimize existing beam forming latency of 6 minutes?**
**6.****	****Any impact to customers (MOCC, spacecraft)?**
**7.****	****What service functions will be specified in the SRD?**
**8.****	****Impact and value of grades-of-service and other traffic management functions?**
**9.****	****Which beam pointing technique is better: Rapid-schedule beam pointing or Beam-Hopping?**

## Backup. MA Fast Forward Trade StudiesSummary & Status

**Backup. MA Fast Forward Trade Studies****Summary & Status**

**A. Mission Model Study**
** ****(MA Forward Service **
**Loading Analysis)**

**D. MA Fast Forward Operations **
**Concept Recommendations**

- Research and recommend optimum communication methodology for MA Fast Forward services.
- (7, 8)

- Analysis of previous and current MAF service loading such as number and type of users, maximum, minimum, and mean length of service period, unscheduled time
- (1,2)

**C. Reaction Time Feasibility Analysis **

**E. User Authentication Requirements Recommendation**** **

**B. MA Fast Forward Service Considerations Study**** **

**F1. MA Fast Forward Performance Analysis - Plan**** **

- Research and validate the feasibility of reducing the time to react to MA forward service request.
- (5)

- Analysis of technical features and operational issues that may impact the success of MA Fast Forward service.
- (6)

- Describe and recommend requirements for MA Fast Forward users.
- (4)

- Plan for queuing-type of study to determine expected mean service delay time, optimum datagram size (service length), service loading, etc.
- (2, 3, 8, 9)

** ****F2. MA Fast Forward Performance Analysis - Study**

- Results of queuing-type of study to determine expected mean service delay time, optimum datagram size (service length), service loading, etc.
- (2, 3, 8, 9)

**In Progress**

**MA Fast Forward OCD, SRR, SRD**

## Backup. MA Fast Forward Loading Analysis (Study A) Results

**Backup. MA Fast Forward Loading Analysis ****(Study A) ****Results**

** ****S-Band**
**W-TT&C**

**S-Band**
**S-TT&C**

**4**

**5**

**SGLT’S  **

**   ****WSGT**

**    ****White Sands Complex (WSC)**

**3***

**2**

**1**

**SGLT’S**

**STGT**

**  ****WART**

**S-1   S-2**
**  ****ETGT**
**  ****S-band**
**   ****TT&C**

**GDIS**

**        ****GRGT**

**ETE Test/**
**G-TT&C**

**GDIS**

**SGLT 6**

**Current & Future Users**

-   Maximum service duration  39.00
- Minimum service duration  7.60
- Average service duration  24.34

**Service Statistics (Near-Term service) - Minutes**

**NETWORK MAF ****LOADING**
**20.4%**

## Backup. MA Fast Forward Service Considerations (Study B) - Results

**Non-coherent forward service support only**
**Partial service coverage if service is not available from all TDRSs**
**Pre-post ambles will limit time slot efficiency (% of time slot containing usable data)**

## Backup. MA Reaction Time Reduction Feasibilities Analysis (Study C) - Results

**Informal discussions suggest that MA Forward Reaction Time can be reduced from 6 minutes to 150 seconds**
- Current 6 minute response time is based on a 10 year old requirement when pre-service testing was required
- Reduction to < 3.5 mins (for F1-F7) and < 8.5 mins (for HIJ) is recommended
- Successfully tested and verified in test mode at WSC
**Reduction will be applicable to all SN MA Forward services **
**Changes and verification of USS/EXEC CSCI expected; Changes to NCCDS need further evaluation**** **
**CONCLUSION: MAF Reaction Time reduction is definitely feasible**

- NOTE: Reaction Time is also known as Inter-service Time

## Backup. MA Fast Forward Operations Concept Recommendations (Study D) - Results

**INCREASE NEED**

**INCREASE COMPLEXITY**

**RECOMMENDED  AS INITIAL SYSTEM FUNCTIONS FOR IMPLEMENTAION  **

|  | LOW | MEDIUM | HIGH |
| --- | --- | --- | --- |
| LOW |  |  -MAF Time Availability Status
 -Ground Connectivity Test | -View User Profile
-Update User Profile 
-Initiation Request Response
-User Data Formatting
-Time-to-Live
-Data Transmission
-User Status Notification  |
| MEDIUM | -Service Performance Statistics
-Virtual Uplink Test 
 | -Fixed Time Slot Processing 
-Large Packet Support
-Data Framing
-Cancellation Request | -Service Initiation Request
-User Parameter Verification 
-Unequal Time Slot Processing 
-Queue Management
-Communication Path Setup |
| HIGH | -TDRS Selection 
-Data Prioritization
 |  | -USAT Visibility Determination
-Transmission Time Scheduling
 |

**Evaluated MAFF Functions**

**NEED**

**COMPLEXITY**

## Backup. User Authentication Requirements (Study E) Results

**MAFF must be compliant with NPR 2810.1**
**For Identification and Authentication**
- Unique identification required for each user
- User identification must be authenticated before allowing any action
- Every action must be correlated to a user identification
- MAFF maintains a log of all actions
- MAFF monitors uplink rate for each user and prevents excessive uplinks
- Real-time file uploads and access to servers/database for administrative operations must be independently evaluated
**For communications via the IONet, MAFF must be compliant with:**
- IONet Security Plan, 290-003
- IONet Access Protection Policy and Requirements 290-004.

## Backup. MA Fast Forward Performance Analysis Plan (Study F1) – Results

**Plan recommends developing an MAFF simulation model**
- Determine the effectiveness of proposed MAFF functions
- Select optimum spec values
- Analyze network performance under varying operating conditions
**Proposed MAFF simulation model capabilities include:**
- Capability to simulate the interaction between independent system components to determine network performance metrics
- Average network latency
- Optimum time slot size and service loading as a function of user traffic profile, processes execution time and queue size
- Capability to compare the effectiveness of a rapid-scheduled beam pointing technique versus a beam-hopping pointing technique

## Backup. MA Fast Forward Performance Analysis Plan (Study F1) – Results (Cont’d)

**Simulation Model Diagram**

## Acronyms

- ACK/NACK 	Acknowledgement/Negative Acknowledgement
- ADPE	Automated data Processing equipment
- DAS	Demand Access System
- CFDP	CCSDS File Delivery Protocol
- dbW	Decibel Watts
- FTP	File Transfer Protocol
- FWS	Fast Forward Workstation
- GPM	Global Precipitation Measurement mission
- GRGT	Guam Remote Ground Terminal
- GSFC	Goddard Space Flight Center
- IONet	Internet Protocol Operational Network
- IP 	Internet Protocol
- KSA	K-band Single Access
- LAN	Local Area Network
- LEO	Low Earth Orbit
- LRS	Low Rate Switch
- MA	Multiple Access
- MAFF	MA Fast Forward
- MDP	Multicast Dissemination Protocol
- SMAF   	S-band Multiple Access Forward
- MOCC	Multispacecraft Operations Control Center
- MOD     	Modulator
- NCCDS	Network Control Center Data System
- NENS	Near Earth Network Services
- NISN	NASA Integrated Services Network
- NORM	Nack-Oriented Reliable Multicast
- OCD	Operations Concept Document
- ORR	Operations Readiness Review
- PCD	Project Commitment Document

- PDL	Product Design Lead
- PN	Pseudo Noise
- PMP	Product Management Plan
- RF	Radio Frequency
- S/C	Spacecraft
- SCID	Spacecraft ID
- SCP	Secure Copy Protocol
- SDR	System Design Review
- SMAF	S-Band MA Forward (applies to TDRS HIJ only)
- SN	Space Network
- SNAS	Space Network Access System
- SNIS	Space Network IP Services
- SPTR	South Pole TDRSS Relay
- SRD	System Requirements Document
- SRR	System Requirements Review
- SSA	S-band Single Access
- STGT	Second TDRSS Ground Terminal
- SWSI	SN Web Services Interface
- TT&C	Tracking, Telemetry & Control
- TCP/IP	Transmission Control Protocol/Internet Protocol
- TDRS	Tracking and Data Relay Satellite
- TDRSS	Tracking and Data Relay Satellite System
- TOCC  	TDRSS Operations Control Center
- TUT     	TDRSS Unused Time
- USAT   	User Satellite
- USS     	User Service Subsystems
- WSC	White Sands Complex
- WSGT  	White Sands Ground Terminal
- XTE	Xray Timing Explorer