3_T3747-1-PD-17-467_T3747-1_AWS-3_EEP_Software_Design_Document_-_v2.3_29_June_2017.pdf

Defense Information Systems Agency

Defense Spectrum Organization

Strategic Planning Office

Annapolis, Maryland 21402

Software Document

Advanced Wireless Services-3 Early Entry Portal Software Design Description

T3747-1-PD-17-467

29 June 2017

Prepared for:

Strategic Planning Office 2004 Turbot Landing

Annapolis, MD 21402-5064

Prime Contractor

Harris Corp.

141 National Business Parkway, Suite 200

Annapolis Junction, MD 20701

Distribution authorized to DoD Components only: Operational use; June 2017. Other requests shall be referred to the DSO.

AWS-3 Early Entry Portal Software Design Document

Defense Spectrum Organization ii

This report was prepared by Harris Corp. under Contract HC1047-07-D-0001 in support of the

Defense Information Systems Agency’s Defense Spectrum Organization.

This report has been reviewed by the following Harris Corp. personnel:

LYNN CUMBERPATCH

Program Manager, Harris Corp.

ALEXANDRA FINKLER

Chief Software Engineer, Harris Corp.

This report is approved for publication by the following government personnel:

HOWARD J. MCDONALD ROBERT L. SCHNEIDER

Chief, Advanced Access Initiatives Branch Technical Director

Strategic Planning Division Defense Spectrum Organization

Defense Spectrum Organization iii

REPORT DOCUMENTATION PAGE

Form Approved

OMB No. 0704-0188 Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing this collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and Reports (0704-0188), 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to any penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number. PLEASE DO NOT RETURN

YOUR FORM TO THE ABOVE ADDRESS.

1. REPORT DATE (MM-YYYY) 2. REPORT TYPE 3. DATES COVERED (From - To)

06-2017 Software Design Description

4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER

Advanced Wireless Services-3 Early Entry Portal Software Design Description HC1047-07-D-0001 5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

6. AUTHOR(S) 5d. PROJECT NUMBER

Harris Corp. T3747-1 Project Team T3747-1 5e. TASK NUMBER

TO-1110

5f. WORK UNIT NUMBER

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION REPORT NUMBER Harris Corporation

141 National Business Pkwy., Suite 200 Bowie, MD 20701 T3747-1-PD-17-467

9. SPONSORING / MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)

Strategic Planning Office 2004 Turbot Landing Annapolis, MD 21402-5064

DSO/SPO

11. SPONSOR/MONITOR’S REPORT

NUMBER(S)

12. DISTRIBUTION / AVAILABILITY STATEMENT

Distribution authorized to DoD Components only: Operational use; June 2017. Other requests shall be referred to the DSO.

13. SUPPLEMENTARY NOTES

14. ABSTRACT

This document specifies the design for the Advanced Wireless Services-3 Early Entry Portal.

15. SUBJECT TERMS

Advanced Wireless Services, AWS-3, Early Entry Portal, EEP, Software Design Description, SDD, SharePoint

16. SECURITY CLASSIFICATION OF: 17. LIMITATION

OF ABSTRACT

18. NUMBER

OF PAGES

19a. NAME OF RESPONSIBLE JSC PERSON

a. REPORT b. ABSTRACT c. THIS PAGE Christopher Johnson

U U U SAR 38

19b. TELEPHONE NUMBER

410-293-9920

Standard Form 298 (Rev. 8-98) Prescribed by ANSI Std. Z39.18

Defense Spectrum Organization iv

This page intentionally left blank.

Defense Spectrum Organization v

Record of Changes

Change

Number Date

Section

Number Description Modified By

October 2015 Initial Document EEP Team

1 March 7, 2016 Updated for v2.0 Mariana Schiff

2 July 20, 2016 Updated for v2.1 Mariana Schiff

3 October 25, Updated for v2.2 Mariana Schiff

4 June 29, 2017 Updated for v2.3 Mariana Schiff

Defense Spectrum Organization vi

Defense Spectrum Organization vii

Table of Contents

1. INTRODUCTION

1.1 BACKGROUND

1.2 PURPOSE

1.3 SCOPE

1.4 INTENDED DOCUMENT AUDIENCE

1.5 SECURITY CLASSIFICATION AND CONSIDERATIONS

1.6 PROVIDING FEEDBACK

1.7 STRATEGY FOR UPDATING THE DOCUMENT

2. SYSTEM DESIGN DECISIONS

2.1 DESIGN TERMINOLOGY

2.2 USAGE SCENARIOS

2.3 LIMITATIONS AND CONSTRAINTS

2.4 DATA CONSIDERATIONS

2.5 ACCESS CONTROL AND CRITICAL SYSTEM CONSIDERATIONS

2.6 DEPLOYMENT CONSIDERATIONS

2.7 INFORMATION ASSURANCE CONSIDERATIONS

3. SYSTEM ARCHITECTURE

3.1 LOGICAL SYSTEM ARCHITECTURE

3.1.1 Users

3.1.2 User Roles

3.1.3 Groups

3.1.4 AWS-3 EEP Cases

3.1.4.1 Coordination Requests

3.1.4.2 Coordination Agreements

3.1.4.3 Deployment Plans

3.1.4.4 TRR Coordination Requests

3.1.5 Case History

3.1.6 AWS-3 EEP Messages

3.1.7 AWS-3 EEP Resources Library

3.1.8 AWS-3 EEP TRR Support Files

3.2 PHYSICAL SYSTEM ARCHITECTURE

3.2.1 System Architecture Components

3.2.2 Deployment Architecture

4. SYSTEM DETAILED DESIGN

4.1 SHAREPOINT

4.2 MICROSOFT FORMS-BASED AUTHENTICATION

4.3 AWS-3 EEP WEB APPLICATION

4.3.1 User Interface

4.3.2 Data Model

4.3.3 Workflow

4.3.4 Messaging System

5. REFERENCES

6. ACRONYMS

Defense Spectrum Organization viii

List of Tables

Table 2-1. Limitations and Constraints Table 2-2. Datasets Table 2-3. AWS-3 EEP Hardware and Software Requirements Table 3-1. User Roles and Groups Table 3-2. AWS-3 EEP CR Workflow Status

Table 3-3. AWS-3 EEP CA Workflow Status Table 3-4. AWS-3 EEP DP Workflow Statuses Table 3-5. AWS-3 EEP TRR Workflow Status Table 3-6. Software Packages and Versions

List of Figures Figure 3-1. Unique Case ID for Coordination Requests Figure 3-2. 5-, 10-, 60-, and Post-60-day Processes

Figure 3-3. Unique Case ID for Coordination Agreements Figure 3-4. SATOPS CA Workflow Process Figure 3-5. Unique Case ID for Deployment Plans

Figure 3-6. Deployment Plan Workflow Processes Figure 3-7. Unique Case ID for TRR Coordinations

Figure 3-8. TRR Workflow Process Figure 3-9. AWS-3 EEP System View Figure 3-10. AWS-3 EEP Deployment View file:///C:/Working%20Folder%202013-14/1%20QA%20Review/3747-1%20EEP%20-%20PORTAL%202017/T3747-1-PD-17-467%20T3747-1%20AWS-3%20EEP%20Software%20Design%20Document%20-%20v2.3%2029%20June%202017.docx%23_Toc486329214 file:///C:/Working%20Folder%202013-14/1%20QA%20Review/3747-1%20EEP%20-%20PORTAL%202017/T3747-1-PD-17-467%20T3747-1%20AWS-3%20EEP%20Software%20Design%20Document%20-%20v2.3%2029%20June%202017.docx%23_Toc486329216 file:///C:/Working%20Folder%202013-14/1%20QA%20Review/3747-1%20EEP%20-%20PORTAL%202017/T3747-1-PD-17-467%20T3747-1%20AWS-3%20EEP%20Software%20Design%20Document%20-%20v2.3%2029%20June%202017.docx%23_Toc486329220

Defense Spectrum Organization 1

1. INTRODUCTION

This Software Design Document (SDD) represents the design for the Advanced Wireless

Services-3 (AWS-3) Early Entry Portal (EEP).

1.1 BACKGROUND

The Federal Communications Commission (FCC) reallocated the 1755-1780 Megahertz

(MHz) band for use by commercial entities (Amendment of the Commission’s Rules with

Regard to Commercial Operations in the 1695-1710 MHz, 1755- 1780 MHz, and 2155-

2180 MHz Bands [1]) and completed its auction of AWS-3 licenses. The Services and the

Defense Information Systems Agency (DISA) Defense Spectrum Organization (DSO) have developed transition plans for their respective organizations to facilitate increasingly less restrictive sharing arrangements for early entry of commercial AWS systems and permanent sharing between Department of Defense (DoD) and commercial systems operating in the 1755-1780 MHz band.

The FCC and National Telecommunications and Information Administration, issued the

Coordination Procedures in the 1695-1710 MHz and 1755-1780 MHz Bands Public Notice

[2] specifying the procedures to be followed in allowing early entry into this band by the

AWS-3 licensees as well as ongoing coordination that would continue to be applicable to the Government stations that would continue to operate in the band after the transition period. The AWS-3 EEP is being designed and developed to facilitate this coordination.

The AWS-3 EEP draws on the successful experience gained with the DoD portal used for coordination of early entry of commercial AWS-1 licensees into the 1710-1755 MHz band during the 2007-2011 time frame. Improved spectrum engineering algorithms will be provided by the Early Entry Portal Analysis Capability (EEPAC) for more precise assessment of aggregate interference from AWS-3 systems into the DoD systems being protected. For information on the AWS-3 EEP workflow, refer to the AWS-3 Early Entry

Portal End-to-End Business Process [3].

1.2 PURPOSE

This SDD provides information on the design of the AWS-3 EEP. The purpose of this

SDD is to communicate the AWS-3 EEP design information to the DSO and the AWS-3

EEP development and test teams.

1.3 SCOPE

The scope of this SDD is limited to describing the design of the AWS-3 EEP.

1.4 INTENDED DOCUMENT AUDIENCE

This document is of value to both a management and technical audience as described below:

DSO Management Team and Technical Staff – This document will serve as a means of communicating the design for the AWS-3 EEP.

http://www.thefreedictionary.com/Megahertz

Defense Spectrum Organization 2

Development, and Test Teams – This document will be used by the developers and testers as an input for their efforts.

1.5 SECURITY CLASSIFICATION AND CONSIDERATIONS

This document is considered to be unclassified, with distribution authorized to DoD components only. Other requests shall be referred to the DSO.

1.6 PROVIDING FEEDBACK

Constructive feedback is encouraged from all readers to improve the value and accuracy of the information presented herein. Provide feedback to Mr. Christopher Johnson/DSO.

1.7 STRATEGY FOR UPDATING THE DOCUMENT

This SDD is based on the requirements specified in the Advanced Wireless Services-3

Early Entry Portal Proposal [4]. If the proposal is revised, this SDD will be reviewed and, if necessary, revised to reflect any changes.

Defense Spectrum Organization 3

2. SYSTEM DESIGN DECISIONS

The AWS-3 EEP development effort has leveraged a mix of agile- and waterfall-development principles, thus placing more emphasis on iterative development with significant and frequent user involvement and feedback and less emphasis on detailed requirements at the very beginning.

2.1 DESIGN TERMINOLOGY

The following terms are used in this document:

Logical Design – defines what the system will do, and suggests how those functions may be distributed across functional units. It does not define how the actual system is constructed.

Physical Design – describes the actual software modules that will be constructed to implement the system, including the internal classes and methods into which the software code will be divided.

2.2 USAGE SCENARIOS

The AWS-3 EEP usage scenarios are detailed in the AWS-3 Early Entry Portal End-to-End

Business Process [3] and presented as a set of use cases, sequence diagrams, and workflow descriptions.

2.3 LIMITATIONS AND CONSTRAINTS

The AWS-3 EEP design in this document is based on the limitations and constraints listed in Table 2-1.

Table 2-1. Limitations and Constraints

Short Name Description

Portal Platform

Microsoft SharePoint 2013 will be leveraged to implement the AWS-3 EEP and will provide some functionality out of the box, while constraining the implementation of other functionality due to SharePoint limitations.

AWS-3 EEP Web

Application

AWS-3 EEP Web Application will be integrated into the SharePoint framework and will be deployed as part of the SharePoint deployment, on top of the standard SharePoint installation.

Internet AWS-3 EEP will be deployable on the Internet.

Web Browser

The AWS-3 EEP shall support current versions of Internet Explorer, Google

Chrome, Mozilla Firefox, and Microsoft Edge browsers in use by DoD, as specified in the AWS-3 Early Entry Portal v2.3 System Requirements

Specification [5].

IA Considerations Best commercial practices will be used with respect to Information

Assurance (IA).

Forms-Based

Authentication

Microsoft Forms-Based Authentication (FBA) will be used for user authentication and authorization.

Defense Spectrum Organization 4

2.4 DATA CONSIDERATIONS

The AWS-3 EEP will use a data model that provides support for the following datasets listed in Table 2-2.

Table 2-2. Datasets

Dataset Description

Licensee laydown data

Data provided by the licensee upon submitting an initial

Coordination Request (CR), Deployment Plan (DP), or Tactical

Relay Radio (TRR) request.

AWS-3 EEP Cases CRs, Coordination Agreements (CAs), DPs, or TRR requests submitted by various licensees.

AWS-3 EEP Case History

All data associated with a particular CR, CA, DP, or TRR request, including data files, status changes, reports, and messages.

Messages and Notifications User messages and system notifications used by the portal to communicate status updates.

The AWS-3 EEP will not be used to store or transmit any sensitive data. All reports containing sensitive or classified data will be processed outside of the portal.

2.5 ACCESS CONTROL AND CRITICAL SYSTEM CONSIDERATIONS

The AWS-3 EEP will require each user to log onto the portal. Each user will be assigned an individual user ID and password by a Portal Administrator. Authentication will be done using the Microsoft FBA component. Upon initial logon, users will be allowed to modify their passwords. The connection between the browser and the AWS-3 EEP will be encrypted utilizing a Secure Sockets Layer (SSL) connection for security purposes.

Users will be organized into groups based on roles. Each role will have an associated set of permissions and privileges, which will ensure proper access control to data and operations.

Groups within the same role will have a similar set of permissions and privileges, however, each group’s data will be protected, and limited, or no visibility, would be allowed between the groups. For example, carriers will belong to a Licensee Role; however each carrier, such as Verizon or AT&T, would not have visibility into each other’s data.

AWS-3 EEP has a set of performance requirements that are documented in the AWS-3

Early Entry Portal v2.3 System Requirements Specification [5]. While no specific availability requirements exist, it is expected that the AWS-3 EEP availability will be on par with the industry standards.

2.6 DEPLOYMENT CONSIDERATIONS

The AWS-3 EEP will be hosted on the Harris network within the Harris data center facility.

The AWS-3 EEP servers will be stood up in a virtual environment and will require licenses for the Windows Server 2012 and Microsoft SharePoint 2013. The AWS-3 EEP servers will reside behind the Harris firewall(s) and will be subject to Harris data center security policies. All servers will be properly patched and would allow only SharePoint traffic.

SSL connection will be used to connect to the server with a certificate provided by the

Certificate Authority used by Harris Corp.

Defense Spectrum Organization 5

The initial operating capability of the AWS-3 EEP should have an anticipated capacity of one Terabyte (TB). This is expected to be a sufficient storage capacity for the datasets repository.

Recommended computer hardware (e.g., maximum processor, memory, and auxiliary storage device capacity) will be refined and documented during application performance testing. Table 2-3 lists initial recommended requirements.

Table 2-3. AWS-3 EEP Hardware and Software Requirements

Component Software Platform Description

SharePoint Server

Windows Server 2012 R2 64-bit

Windows Internet Information

Server (IIS) Server 7.5

Microsoft .NET Framework 4.5

32 Gigabyte (GB) Random Access

Memory (RAM)

8 Central Processing Units (CPUs)

1 TB Hard Drive

The AWS-3 EEP Web Application is hosted on this SharePoint server. The server must be accessible over the

Internet to all AWS-3 EEP users.

Database Server

Windows Server 2012 R2 64-bit

Microsoft Structured Query

Language (SQL) Server 2012

Microsoft .NET Framework 4.5

32 GB RAM

8 CPUs

1 TB Hard Drive

The SQL Server database required as part of the SharePoint deployment that will store all the AWS-3 EEP and

SharePoint data.

2.7 INFORMATION ASSURANCE CONSIDERATIONS

The AWS-3 EEP is implemented using commercial best practices. No DoD data is stored or processed by the AWS-3 EEP; therefore, no Authority to Operate is required. All code developed for the portal shall be scanned using Visual Studio Code Analysis Tool. All high-priority vulnerabilities will be fixed before delivery.

The AWS-3 EEP uses the SSL protocol to secure the data link between the user’s browser and the server. The AWS-3 EEP will be located within the Harris data center and will be firewalled and protected in accordance with Harris corporate standards. Servers will be properly patched; security and anti-malware software will be installed to detect any malicious activity. The traffic will be restricted to the SharePoint traffic and additional monitoring software will be used to protect against attacks from foreign networks.

Defense Spectrum Organization 6

Defense Spectrum Organization 7

3. SYSTEM ARCHITECTURE

The AWS-3 EEP is implemented as a Microsoft SharePoint 2013 application running on

Windows Server 2012. The bulk of the work in implementing the AWS-3 EEP involves customizing SharePoint for the specifics of the AWS-3 EEP requirements. Custom implementation is required to address the specifics of the AWS-3 EEP User Interface (UI), workflow and other functionality that is not well supported by the out-of-the-box

SharePoint system. Most of the implementation will be done using Microsoft C#.NET and

JavaScript programming languages.

Because the implementation is based on a Commercial Off-the-Shelf (COTS) platform, the software design does not have a large number of components or interfaces.

Lists are a key part of the architecture of Windows SharePoint Services. For development purposes, a list is the main mechanism through which data stored in Windows SharePoint

Services is presented to a user for data input or retrieval. This means that, to customize a

SharePoint site such as the AWS-3 EEP, organization and customization to the list data is required. As a result, most of the AWS-3 EEP data is logically stored in a collection of lists. Lists can contain one or more folders, to help with further data organization and to improve the performance of data retrieval. Access Control Lists (ACLs) are the primary means of controlling access to resources, including list data. ACLs are used to define which users and groups have access to which lists and which folders within those lists. To prevent non-administrator users from altering data within the portal, only read privileges to lists are granted by default. Write privileges are only granted programmatically, when needed.

The logical components are described in the following sections.

3.1 LOGICAL SYSTEM ARCHITECTURE

3.1.1 Users

Each AWS-3 EEP user will be provided an individual user ID and password. The AWS-3

EEP Administrator will create new users, assign them to groups, delete users and reset user passwords. Users will also be able to change their own passwords through the portal. Each user will belong to a group based on the user’s role in the AWS business process. Upon successful authentication through the portal, based on their role, users will be re-directed to the landing pages with permissions and privileges that have been allotted to their role.

3.1.2 User Roles

There are seven fundamental types of users within the AWS-3 EEP portal:

Licensees – Commercial wireless companies responsible for submitting CRs, CAs, DPs, and TRR requests.

DoD Spectrum Relocation Management Team (DSRMT) – Overall responsibility for the AWS-3 coordination process. DSRMT is responsible for each case submitted by the AWS-3 Licensee. DSRMT will provide the integrated DoD response to the

AWS-3 Licensee.

Defense Spectrum Organization 8

Spectrum Management Office (SMO) Representatives – Service SMO

Representatives are responsible for reviewing each of the subcases and analysis results.

Service SMO Representatives will make the final decision on each sub-case. In addition, Army SMO Representatives are responsible for reviewing TRR requests and providing a response.

Federal Agency Representatives – Federal Agency users are responsible for reviewing cases submitted to them and providing a response.

Engineering Analysis Staff – Engineering analysis staff will retrieve cases from the

Portal, run validation processes, conduct electromagnetic capability analyses via

EEPAC, and provide analysis results.

Portal Administration Staff – Portal Administration Staff will ensure the smooth operation of the Portal and will be responsible for establishing and maintaining user accounts.

Satellite Operations Staff – Satellite Operations (SATOPS) staff is responsible for reviewing and countersigning CAs.

Each user type is assigned a separate role within the AWS-3 EEP implementation, with each role having a different set of permissions and privileges. Various users can be then further aggregated into disparate groups that belong to each role, thus allowing for data protection between users belonging to various organizations within a given role.

3.1.3 Groups

Groups are used to aggregate users belonging to the same organization within a given role into a single entity with the same permissions, privileges, and access control. All groups are pre-set upon AWS-3 EEP deployment, as all of the organizations participating in the

AWS process are defined and known. This simplifies the deployment process and reduces administrative maintenance. Table 3-1 below describes the relationship between the user roles and the groups.

Table 3-1. User Roles and Groups

User Role Groups

AWS-3 Licensees

One for each carrier submitting requests, such as Verizon, AT&T, etc. Groups will be named based on the company name

DSRMT DSRMT

Service SMO Representative Air Force, Army, Navy

Engineering Analysis Staff Engineers

Portal Administration Staff Administrators

Federal Agency User Department of Justice, Department of the

Interior

Satellite Operations Staff SATOPS Lead

Defense Spectrum Organization 9

Each group can belong to only one role and each user will be assigned to only one group by the AWS-3 EEP administrator. All members of the group will have the same permissions, privileges and data visibility. This allows any member of the group to act on behalf of the group.

3.1.4 AWS-3 EEP Cases

There are four types of cases that can be submitted to the Portal: CRs, CAs, DPs, or TRRs.

The AWS-3 EEP will store some of the case data, e.g., initial CR, CA, DP, and TRR submission data, and final CR resolution letter, counter-signed CA data, and TRR response memo; however, all data containing sensitive assignment information, such as impacted records reports and subcase analysis reports, will be stored outside of the portal for security purposes. The AWS-3 EEP will be used to capture the workflow and case status, as well as for communication purposes. The AWS-3 EEP case data will be stored in SharePoint lists, with ACLs controlling access to that data. To better organize the data within each list, reduce the number of ACLs, and not impact performance, SharePoint List folders will be utilized. This will ensure that licensees, for example, have no visibility into other licensee’s data.

3.1.4.1 Coordination Requests

When a licensee submits a coordination request to the Portal, the Portal automatically generates a Case Identifier (ID) for that request, which becomes a unique identifier for that submission. Thus all requests within the Portal are organized and can be looked up by their

Case IDs. Case IDs are alphanumeric and are 13 characters long. Each Case ID encapsulates a number of data elements and is structured as shown in Figure 3-1.

For each initial CR submission, users will be required to upload two files: a csv file with the laydown data and a pdf file with the cover letter. The format of the laydown file is documented in the AWS-3 Early Entry Portal Analysis Capability v2.3 System

Requirements Specification [5]. Upon receiving the initial coordination request and creating a unique case ID for it, the portal will store the case data and will provide a notification to the licensee that the data have been successfully received and stored. In

Licensee Name

(3 Characters) Market Area

(3 Digits) AWS-3 Frequency Block

(1 Character)

Unique

Computer Generated

Number

(6 Digits)

Figure 3-1. Unique Case ID for Coordination Requests

Defense Spectrum Organization 10 general, the CR workflow will follow the 5-, 10-, 60-, and post-60-day processes defined in the Coordination Procedures in the 1695-1710 MHz and 1755-1780 MHz Bands [2], as shown in Figure 3-2. For a detailed description of the workflow, please refer to the AWS-3

Early Entry Portal End-to-End Business Process [3].

Figure 3-2. 5-, 10-, 60-, and Post-60-day Processes

An automated workflow will be implemented within the portal to assist users with the overall case management process. To that end, each case will have a workflow object associated with it, which will keep track of the current status of the case, i.e., where in the process a given case resides. Native SharePoint workflow will be leveraged as much as possible; however, customization will be required. As the case will transition through various workflow states, a set of statuses will be used to easily keep track of the case progress.

Table 3-2 below identifies all possible statuses and their descriptions.

Table 3-2. AWS-3 EEP CR Workflow Status

Workflow Status Description

Submitted Initial CR received

Acknowledged Initial CR stored in the Portal and unique Case ID generated

Complete - Accepted CR successfully validated and accepted for analysis

Defense Spectrum Organization 11

Workflow Status Description

Incomplete - Resubmit CR had validation errors and must be resubmitted

Pending Analysis with Subcases

CR is pending analysis and assignments from one or more services might be impacted by the submitted laydown, which triggers a generation of a subcase for the impacted SMO

Pending Analysis – No Subcases

CR is waiting to be analyzed and no assignments from the services have been identified as being impacted by the submitted laydown

Analysis in Progress Analysis on CR has begun

Subcase Report Posted Analysis for each impacted SMO is available for SMO review;

CR is pending the review and approval by the impacted SMO

Subcase Review Complete Impacted SMO(s) completed the review and provided their results

Result Letter Available An aggregated result letter has been prepared for delivery to

Licensee

Response Delivered The response letter is delivered to the licensee for a given case

Withdrawn Request has been withdrawn and will no longer be processed

Results Accepted The licensee has accepted the analysis results.

Object – No Discussion The licensee objects to the analysis results, and requests no discussion.

Requested Discussion The licensee has conditionally accepted or objects to the results and has requested a meeting with DoD.

Discussion Result – Accept After discussion with DoD, the licensee has accepted the analysis results.

Discussion Result – Object After discussion with DoD, the licensee objects to the analysis results.

Closeout Complete – Accept The Engineering Analysis Staff has completed the closeout of a request that was accepted by the licensee.

Closeout Complete – Object The Engineering Analysis Staff has completed the closeout of a request to which the licensee had objected.

Closed – Accepted The case is closed and the licensee has accepted the terms.

Closed – Objected The case is closed and the licensee has objected to the results of the analysis.

Defense Spectrum Organization 12

3.1.4.2 Coordination Agreements

When a licensee submits a coordination agreement to the Portal, the Portal automatically generates a Case ID for that agreement, which becomes a unique identifier for that submission. Similarly to CRs, agreement case IDs for CAs are alphanumeric and are 13 characters long. Each Case ID encapsulates a number of data elements and is structured as shown in Figure 3-3.

For each CA submission, users will be required to upload a pdf file containing a signed

SATOPS coordination agreement. Upon receiving the initial coordination agreement and creating a unique case ID for it, the Portal will store the CA data and will provide a notification to the licensee that the data has been successfully received and stored. The CA workflow will follow a similar path as the CR’s for 5- and 10-day processes, as depicted in

Figure 3-4.

Figure 3-4. SATOPS CA Workflow Process

The workflow for CAs will be implemented similarly to the CR workflow implementation. Each case will have a workflow object associated with it, and a set of statuses will be used to keep track of the case progress.

Licensee Name

(3 Characters) CA Indicator

(3 Digits) Placeholder 0

(1 Character)

Unique

Computer Generated

Number

(6 Digits)

_ _ _ 0 C A 0 _ _ _ _ _ _

Figure 3-3. Unique Case ID for Coordination Agreements

Defense Spectrum Organization 13

The statuses for the CA workflow are provided in Table 3-3 below.

Table 3-3. AWS-3 EEP CA Workflow Status

Workflow Status Description

Submitted Signed CA received

Acknowledged Signed CA stored in the Portal and unique Case ID generated

Completed SATOPS lead determines the CA template is complete and uploads a countersigned agreement

Incomplete - Resubmit SATOPS lead determines the CA template is not valid and must be resubmitted

In addition to the Coordination Agreement, there are other files, collectively known as

Other SATOPS Information, which will be required from the AWS-3 Licensee. All of these files are in pdf format. The types of Other SATOPS Information files are: Radio

Frequency Interference (RFI) Mitigation Methods (MM) also known as Mitigation Plans;

Safety of Life Service Assurances; and Licensee Contact Information. These files may be attached to the CA case at any point during the workflow.

3.1.4.3 Deployment Plans

When a licensee submits a deployment plan to the Portal, the Portal automatically generates a Case ID for that plan, which becomes a unique identifier for that submission.

Similarly to CRs and CAs, deployment case IDs are alphanumeric and are 13 characters long. Each Case ID encapsulates a number of data elements and is structured as shown in

Figure 3-5.

Figure 3-5. Unique Case ID for Deployment Plans

For each initial DP submission, users will be required to upload two files: a csv file with the technical data for the deployment plan, and a pdf file with the cover letter. The template for the technical data is documented in the AWS-3 Early Entry Portal Analysis

Capability v2.3 System Requirements Specification [5]. Upon receiving the initial

Licensee Name

(3 Characters) DP Indicator

(3 Digits) Placeholder 0

(1 Character)

Unique

Computer Generated

Number

(6 Digits)

_ _ _ 0 D P 0 _ _ _ _ _ _

Defense Spectrum Organization 14 deployment plan and creating a unique case ID for it, the portal will store the DP data and will provide a notification to the licensee that the data has been successfully received and stored. The DP workflow will follow the process shown in Figure 3-6.

Figure 3-6. Deployment Plan Workflow Processes

The statuses for the DP workflow are provided in Table 3-4 below.

Table 3-4. AWS-3 EEP DP Workflow Statuses

Workflow Status Description

Submitted Initial DP received

Acknowledged Initial DP stored in the Portal and unique Case ID generated

Complete - Accepted DP successfully validated and accepted for analysis

Incomplete - Resubmit DP had validation errors and must be resubmitted

Analysis in Progress Analysis on DP has begun

Analysis Results Posted Analysis is complete and the results have been posted

3.1.4.4 TRR Coordination Requests

When a licensee submits a TRR Coordination Memo to the Portal, the Portal automatically generates a Case ID for that coordination, which becomes a unique identifier for that submission. Similarly to CRs, CAs, and DPs, coordination case IDs for TRRs are alphanumeric and are 13 characters long. Each Case ID encapsulates a number of data elements and is structured as shown in Figure 3-7.

Defense Spectrum Organization 15

For each TRR submission, users will be required to upload two files: a csv file with the technical data for the coordination, and a pdf file containing their TRR memo. The templates for these documents are available within the Portal. Upon receiving the initial

TRR submission and creating a unique case ID for it, the Portal will store the TRR data and will provide a notification to the licensee that the data has been successfully received and stored. The TRR workflow will follow the process shown in Figure 3-8.

Figure 3-8. TRR Workflow Process

The workflow for TRRs will be implemented similarly to the other workflow implementations.

Each case will have a workflow object associated with it, and a set of statuses will be used to keep track of the case progress.

Licensee Name

(3 Characters) TRR Indicator

(3 Digits) Placeholder 0

(1 Character)

Unique

Computer Generated

Number

(6 Digits)

_ _ _ T R R 0 _ _ _ _ _ _

Figure 3-7. Unique Case ID for TRR Coordinations

Defense Spectrum Organization 16

The statuses for the TRR workflow are provided in Table 3-5 below.

Table 3-5. AWS-3 EEP TRR Workflow Status

Workflow Status Description

Submitted TRR Coordination Request received

Acknowledged TRR stored in the Portal and unique Case ID generated

Coordinating Army is in the process of coordinating with the

Licensee

Complete – Closed The Army has completed the coordination and posted the response memo.

Withdrawn Request has been withdrawn and will no longer be processed.

3.1.5 Case History

The history of state transitions within the workflow, including dates and times, together with data uploaded in files, status change information, and final documents, will be associated with each case and will be referred to as case history. Case history will keep track of the date and time each action on the case took place, the user who was responsible for the action, and the type of the action, such as status change.

The visibility into case history for each case will be limited and controlled by the privileges and permission of a user role and a specific user group (disallowing licensees to view each other’s case history, for example, and filtering out the DoD internal workflow, such as part of the 60-day process).

To implement case history, SharePoint Lists will be utilized again. Each licensee will have one unique list to store its CR case history, one unique list to store its SATOPS CA and DP case history, and one unique list to store its TRR case history data. Each list will have exactly one folder per combination of groups that can access its list items, and that folder will have an ACL on it to enforce that access. The case history list will be indexed to support an acceptable response time to the user.

3.1.6 AWS-3 EEP Messages

The AWS-3 EEP messaging is implemented inside of SharePoint and will have no connectivity to any outside mail system. To view or send messages, users will be required to use the AWS-3 EEP Inbox. In general, there are two types of messages that the AWS-3

EEP messaging system will support:

1. Notifications – messages that are auto-generated by the system, such as the ones notifying the users of a status change.

2. AWS-3 EEP Messages – messages that are generated by users and directed to other groups, with all users within those groups having the visibility and access to the message.

To assist with message and notification management, the AWS-3 EEP will provide the following capabilities:

Defense Spectrum Organization 17

Users will have an ability to organize and move messages between the Inbox, Sent, and

Deleted folders

Received messages will initially reside in the user’s Inbox folder

Sent messages will initially reside in the user’s Sent folder

Messages could be deleted and will be placed in the Deleted folder

To assist with message addressing, users will be provided a quick address lookup functionality that will be filtered to allow only the allowed recipient groups for that given user. The following restrictions will be implemented to properly manage the allowable communication:

Licensees will not be able to correspond with other licensees, or with SMO

Representatives or Engineers.

DoD will be able to correspond with any other agency and group; however, they will be able to send a message to only one licensee at a time.

SATOPS Lead will not be able to correspond with Engineers or Federal Agencies, or with licensees that are not designated as SATOPS licensees.

All groups will be allowed to correspond with the Administrator.

Since SharePoint does not support point to point messaging out of the box, the entire messaging system will be implemented from scratch, leveraging built-in SharePoint structures such as lists and folders. As with other data, messaging system data will be stored in a collection of lists. Each combination of groups that can send messages among each other will get separate folders that must be protected by an ACL. The total number of

ACLs should not exceed the maximum number of recommended ACLs.

3.1.7 AWS-3 EEP Resources Library

The AWS-3 EEP Resources Library will be implemented as a SharePoint Document

Library. The DSRMT and EEP System Administrator groups will have permissions to manage the library, including the ability to upload, replace, and delete files. All other user groups will be able to view the list of documents and to download them.

3.1.8 AWS-3 EEP TRR Support Files

The AWS-3 EEP Support Files repository will be implemented as a SharePoint Document

Library. The Army, DSRMT, and EEP System Administrator groups will have permissions to manage the library, including the ability to upload, replace, and delete files.

Licensees will be able to view the list of documents and to download them. Documents in this library may include TRR memo and technical data templates, and shape files.

Defense Spectrum Organization 18

3.2 PHYSICAL SYSTEM ARCHITECTURE

3.2.1 System Architecture Components

The AWS-3 EEP is built using the SharePoint 2013 platform. As such, there are very few modules to its physical architecture, as it relies on native SharePoint constructs. Microsoft

FBA, provided by .NET, is the only non-SharePoint component that is used within the

AWS-3 EEP. Users connect to the AWS-3 EEP from their browsers using the SSL connection for security. The AWS-3 EEP system architecture is depicted in Figure 3-9.

Figure 3-9. AWS-3 EEP System View

A full list of software packages and libraries required and used by the AWS-3 EEP system for development and installation is provided in Table 3-6.

Table 3-6. Software Packages and Versions

Software Version Vendor

Windows Server 2012 2012, Release R2, 64-bit Microsoft

Microsoft .NET Framework 4.5 Microsoft

Microsoft IIS 7.5 Microsoft

Microsoft SharePoint 2013 2013 Microsoft

Microsoft SQL Server 2012 2012, 64-bit Microsoft

Defense Spectrum Organization 19

3.2.2 Deployment Architecture

The deployment view communicates the physical deployment architecture of the system.

The AWS-3 EEP was initially deployed within the Harris Corporation data center in

Culpeper, Virginia, and later in Melbourne, Florida. As part of the Harris data center, the deployment architecture of the AWS-3 EEP follows the rules and standard deployment practices of that facility. As such, the SharePoint server is located within the Harris data center Demilitarized Zone protected by the firewall with only SharePoint traffic allowed to that server. The SharePoint SQL Server database server, however, is located behind yet another firewall on the corporate Local Area Network, thus providing an extra layer of security to the data stored on the portal. Figure 3-10 provides the deployment architecture view.

Figure 3-10. AWS-3 EEP Deployment View

Defense Spectrum Organization 20

Defense Spectrum Organization 21

4. SYSTEM DETAILED DESIGN

4.1 SHAREPOINT

Microsoft SharePoint 2013 is a web application platform used for the portal development.

The AWS-3 EEP customizes SharePoint for the needs of the AWS business process by developing and integrating an AWS-3 EEP Web Application into the SharePoint infrastructure. Some typical portal functionality is provided by SharePoint out of the box, thus saving some development time by leveraging COTS. Where customization is required, custom code is built as part of the AWS-3 EEP Web Application, which is integrated into the SharePoint infrastructure. While SharePoint itself is not modified for the AWS-3 EEP, AWS-3 EEP Web Application gets integrated as a SharePoint Site, a standard SharePoint container that is part of the SharePoint Site Collection, which allows deployment of multiple sites, if need be. SharePoint Site Collection in itself is part of the

SharePoint Web Application – a mechanism used by SharePoint to develop custom applications within its platform. To store its data, SharePoint platform houses its own

Microsoft SQL Server, although most of the database interaction is abstracted from the

SharePoint developers. SharePoint platform itself leverages Microsoft.NET capabilities and, as such, provides standard .NET functionality and interfaces to the SharePoint developers.

4.2 MICROSOFT FORMS-BASED AUTHENTICATION

Since SharePoint does not provide its own way of authenticating users, the AWS-3 EEP utilizes Microsoft FBA to provide authentication services to its users. FBA services are part of the .NET v4.5 framework and can be conveniently leveraged from the AWS-3 EEP

Web Application. To store the user authentication information, the AWS-3 EEP leverages the existing SharePoint SQL Server Database Management System, while creating a separate authentication database within it. Upon trying to login into the AWS-3 EEP, users are authenticated using FBA and the data stored within the authentication database. When a user logs into the Portal, SharePoint uses the SQL Membership provider to check the credentials entered against what is stored in the authentication database. Upon successful authentication, users are authorized according to each user’s permissions and privileges which are determined by the group and role to which they belong.

4.3 AWS-3 EEP WEB APPLICATION

The AWS-3 EEP Web Application is a custom solution for the AWS needs that is integrated into the SharePoint infrastructure, leveraging built-in SharePoint constructs along the way. The AWS-3 EEP Web Application is logically comprised of the following components:

UI

Data Model

Workflow

Messaging System

Defense Spectrum Organization 22

Each of these components is covered in more detail below.

4.3.1 User Interface

SharePoint user interface customization is achieved through development of custom web pages and web parts. For the purposes of the AWS-3 EEP, JavaScript, C#.NET and

ASP.NET are the programming languages utilized for UI development. All of the web pages within the AWS-3 EEP are custom developed. Standard UI controls, such as combo boxes, edit boxes, filtered lists, grids and buttons are used. Web page layout follows the rules of the SharePoint page layout. A custom master page is used to provide the pages a common look and feel.

4.3.2 Data Model

Since most of the database interaction is abstracted from SharePoint developers, SharePoint offers its native data model constructs for data management. Lists and folders are the main architectural types for data management and are used extensively as part of the AWS-3

EEP Web Application for data management. Most of the portal data is stored inside of

SharePoint lists with data being further organized into subfolders within these lists. Native

SharePoint ACL mechanisms are leveraged to control access to the data.

While data access can be controlled at the list item level, in general this technique will not work. Aside from the difficulty of maintaining possibly thousands of ACLs within the

AWS-3 EEP, for performance reasons SharePoint recommends limiting the number of

ACLs to well below the capacity of list items a list can hold. So to limit the number of

ACLs within the AWS-3 EEP, a collection of list items must be protected with a single

ACL. This single ACL can be placed either on an entire list (where it applies to every item in the list) or on a folder (where it applies to every item within the folder).

4.3.3 Workflow

The AWS-3 EEP leverages the built-in SharePoint workflow functionality, further customizing it to its own needs in support of the AWS process. Each case within the

AWS-3 EEP will have a corresponding workflow object associated with it to keep track of the status of the case within the AWS business process. Users will only be allowed to take actions based on what the available states of the workflow are at any given time in the process. All states and statuses are implemented as part of the workflow customization and follow the rules of the 5-, 10-, 60-, and post-60-day processes, the CA process, the DP process, or the TRR process, as described in Section 3 (Figure 3-2, Figure 3-4, Figure 3-6, Figure 3-8, and Tables 3-2 to 3-5).

4.3.4 Messaging System

SharePoint does not provide a suitable solution for the messaging needs of the AWS-3 process, being unable to support point-to-point communication. As a result, the AWS-3

EEP Messaging System is a custom-built component that is implemented entirely within the SharePoint framework with no connectivity to outside email servers. The messaging system, like the rest of the AWS-3 EEP Web Application, is built by creating custom web pages, leveraging the SharePoint data model, i.e. lists, for message storage, and a custom

Defense Spectrum Organization 23 solution to message routing, which is achieved by leveraging SharePoint folders and ACLs to ensure data integrity and proper data access.

The AWS-3 EEP Messaging System supports two disparate message types: notifications and user messages. Notifications are auto-generated by the system, as a result of a workflow status change for example, while user messages are used to allow the communication between the groups of users. Messages can only be addressed to an entire group, with each user within the group having access and visibility to the received message. This is done to prevent implementation of a custom business process for each group of users, as the correspondence processes and responsibilities may vary from organization to organization. However, each individual user within a group can manage

Inbox, Sent, and Deleted folders independently of other users in the group.

Each combination of groups that can send messages among each other will be protected by an ACL on a folder that will contain messages between these groups. The folder naming convention will determine which users are allowed access to its items, and the ordering of the groups within the folder name will be standardized. This will improve performance and will eliminate the need to query each ACL. Some groups, such as an Administrator group, will be granted access to all messages within the system.

Defense Spectrum Organization 24

Defense Spectrum Organization 25

5. REFERENCES

1. Amendment of the Commission’s Rules with Regard to Commercial Operations in the

1695-1710 MHz, 1755- 1780 MHz, and 2155-2180 MHz Bands. GN Docket No. 13-

185. Report and Order, 29 FCC Record 4610. (2014) (reconsideration pending), Federal Communications Commission.

2. Coordination Procedures in the 1695-1710 MHz and 1755-1780 MHz Bands. Public

Notice DA 14-1023. Federal Communications Commission and National

Telecommunications and Information Administration. 18 July 2014.

3. AWS-3 Early Entry Portal End-to-End Business Process.pptx. DSO. Annapolis, MD:

June 2017

4. Advanced Wireless Services-3 Early Entry Portal Proposal. Exelis Inc. Bowie, MD:

01 September 2015.

5. AWS-3 Early Entry Portal v2.3 System Requirements Specification. DSO-SD-16-051.

DSO. Annapolis, MD: (n.d.)

Defense Spectrum Organization 26

Defense Spectrum Organization 27

6. ACRONYMS

ACL Access Control List

AWS Advanced Wireless Services

CA Coordination Agreement

COTS Commercial Off-the-Shelf

CPU Central Processing Unit

CR Coordination Request

DISA Defense Information Systems Agency

DoD Department of Defense

DP Deployment Plan

DSO Defense Spectrum Organization

DSRMT Defense Spectrum Relocation Management Team

EEP Early Entry Portal

EEPAC Early Entry Portal Analysis Capability

FBA Forms-Based Authentication

FCC Federal Communications Commission

GB Gigabyte

IA Information Assurance

ID Identifier

IIS Internet Information Server

MHz Megahertz

MM Mitigation Methods

RAM Random Access Memory

RFI Radio Frequency Interference

SATOPS Satellite Operations

SDD Software Design Document

SMO Spectrum Management Office

SQL Structured Query Language

SSL Secure Sockets Layer

TB Terabyte

TRR Tactical Radio Relay

UI User Interface

Defense Spectrum Organization 28

Defense Spectrum Organization 29

DISTRIBUTION LIST

Internal No. of Copies

R. Schneider (.pdf)

H. McDonald (.pdf)

C. Johnson (.pdf)

S. Schutta (.pdf)

T. Shanholtz (.pdf)

L. Cumberpatch (.pdf)

A. Finkler (.pdf)

Defense Spectrum Organization 30