Voice_Conferencing_System_Requirements_Document_v1_2_rev_18_June_2014_CLEAN.docx

Voice Conferencing System (VCS) Requirements Document

Document Number: VCSDR00001 Revision 1.2 18 June 2014

Prepared by:

Test Communications Branch Atlantic Test Range 23013 Cedar Point Road Patuxent River, MD 20670

Revision Record

1. Throughout document - Added traceability to CLINs

2. Section 2.4.2 – Removed wording referencing the LEMO connector

3. Added Section 2.5 to address reliability, maintainability, and availability

4. Section 3.4 – Provided clarification regarding the level of verification required for each delivery order, and timing

5. Section 3.5 – Provided clarification regarding the timing of training events, and effort required for the follow-up consultation

6. Section 4.2 - Provided clarification regarding Vendor Demonstration requirements

7. (Fmr)VCS.2.1.1.3.3 – Removed the requirement to indicate PTT state per conference; Renumbered as VCS.2.3.4 to better fit within the hierarchy

8. VCS.2.3 – Added “non-blocking” as part of the requirement

9. VCS.2.3.1 – Removed the objective requirement to interface with a LEMO connector

10. VCS.3.0 – Clarified the number of external COTS devices that the system must interface with

11. VCS.3.3 – Removed Threshold and Objective requirements to avoid confusion with VCS.3.0

12. VCS.3.6.4 – Clarified objective requirement to better describe RS-232 and Ethernet relationship

13. VCS.5.1.1 – Updated to reflect the latest version of the standard

14. Section 7.0 – Maps have been updated to show users which could share units

15. Section 8.0 – Updated to indicate the preference that the vendor should provide administration client PCs, and increased qtys.

2. Section 3.1 – Removed the requirement for CDRL# A013

3. Section 3.2 – Removed the requirement for CDRL# A003

4. VCS.3.0 – Updated threshold objective to be “12 T1s” adding 2 channel banks connected to the RED core in addition to the previously mentioned 10 channel banks attached the BLACK CORE

5. Section 3.3 – Removed SECRET Clearance requirement for installers, and mandated 100% escort in secure spaces

6. Section 3.3.2 – Specified Hardware required as part of the initial installed capability

7. Section 3.5 – Removed the requirement for 90 follow-up consultation

8. Section 3.6 – Grouped Technical Data Package items under separate CLINS

9. Section 8.0 – Qty. change to match Section 7.0

Table of Contents

1. Project Introduction The Voice Conferencing System (VCS) is a communications suite intended for use in a flight test environment. The system’s primary function is to enable test personnel to exchange voice communications during flight-test missions, regardless of their physical location or type of communication equipment used.

VCS is a Commercial off the shelf (COTS), highly scalable, highly modular and upgradable system that will allow system operators to communicate on logically separated voice conferences, to coordinate flight test operations in the air, on the ground, and in the surrounding waterways.

The VCS will provide a central conferencing capability, and provide end-users with devices that can communicate on multiple voice conferences simultaneously. The VCS will be able to interface with a variety of COTS communication devices including UHF/VHF Radios, telephone lines, T1, Voice recorders, etc. The VCS will provide voice conferencing services for all connected communication equipment, bridging the gap between dissimilar communications devices. VCS will be capable of conferencing both secure (RED) and unsecure (BLACK) audio traffic. Individual voice conferences are highly configurable, and can be tailored to meet the needs of individual customers.

1. Concept of Operations The Voice Conferencing System (VCS) is the central communications hub that connects multiple voice communication devices together, forming a single network. The VCS will provide the ability to connect a subset of these devices into logically segregated voice conferences, as determined by a VCS administrator. Voice conferences create a logical boundary between conference members, and those devices external to the conference. Audio that is transmitted on a conference will be heard by all conference members.

For more advanced conferencing needs, the VCS will provide user End Instruments (EIs) that will enable operators to be members of multiple conferences simultaneously. The EIs will allow operators to choose which of the available conference(s) shall be selected to transmit audio on, and which shall be selected to receive audio from. EI operators will also have the option to manage basic conference settings such as volume levels, Push-to-Talk (PTT) selection, audio routing, etc. More advanced conference administration will be handled by one or more VCS administrators, via an Administration graphical user interface (GUI) that is separate from the EI end user device.

The VCS EIs will be capable of handling both RED and BLACK audio. All VCS EIs will be capable of joining BLACK conferences, but subset of these devices will also be capable of joining RED conferences as well. For all RED/BLACK EIs, measures will be taken to ensure that RED audio is separated from BLACK audio at all times, in accordance with Department of Defense Information Assurance and TEMPEST regulations.

Commercial off the shelf (COTS) communication devices, using standard interfaces can be joined into any conference to add additional users or capabilities. For example, a digital voice recorder can be added to the conference to preserve voice, or an Ultra High Frequency / Very High Frequency (UHF/VHF) radio may be added to communicate with mobile users who are external to the system.

Using these basic mechanisms, the VCS will allow flight test ranges to setup a communication scheme that will enable communication to flow between geographically dispersed test personnel, without overloading operator workload. The VCS is designed with an extremely flexible architecture that provides very few limitations on how devices can be connected to conferences. The specific number of conferences and their respective members can vary based on mission requirements. See Figure 1 - VCS Overview.

Figure 1 - VCS Overview

System Scenarios The VCS is a highly configurable communications solution that provides voice communication services in and around an open-air test range. These basic mechanisms can be uniquely combined and administered on an installation by installation basis, and are described in the follow sections.

Simple Conferencing Certain system users will interface with the VCS through COTS communication devices that are external to the system. Communication devices may vary depending on the application, but each utilizes standard communication protocols (4 wire E&M, 2 wire, IP, VoIP, etc)

Example COTS devices include:

1. Push to Talk (PTT) Handsets

2. Telephone Line

3. Voice Recorder

4. UHF/VHF Radio

5. T1 / 4-wire Ear and Mouth (E&M)

6. Hot mic Radios

7. Overhead speakers

Users of these COTS devices are restricted to being members of only one conference at a given time.

Communication over Radio System users will also have the need to reach out and talk to mobile assets in the air, on the ground and on the water. Communication with mobile assets will be achieved by adding a UHF/VHF Radio into a conference, tuned to a specific, predetermined frequency.

In the event two or more radios (with different frequencies) are added to the same conference, conference voice traffic will be transmitted on both frequencies simultaneously. Frequency coordination is of the utmost importance to either employ this ancillary benefit, or to specifically guard against it. In a typical flight test, there will only be one radio in a conference at any given time.

Multi-Conferencing Certain users, depending on role, may be required to join multiple conferences simultaneously. For these more advanced users, the VCS will provide End Instruments (EIs) to perform this function.

EIs will allow a single user to be a member of multiple conferences at the same time, but it does not imply that he or she will be communicating on all of these conferences at once.

Each user will have the ability to participate in an assigned conference one of three ways:

1. Active Communication (transmit and receive)

2. Monitor Only

3. Standby (inactive)

Active communication allows the operator to both send and receive information on the active conference(s), while “Monitor Only” mode limits communication strictly to receive-only. When an operator does not wish to listen to a particular conference that he or she is a member of, the operator has the option to set that conference into Standby mode. While a conference is on Standby, the operator cannot talk or listen to any voice traffic that is occurring, but can quickly reactivate it with a single selection.

A typical EI user will be a member of multiple conferences, and will have a subset of these conferences set to “Monitor Only”. This allows the user to have constant awareness of voice traffic across conferences. In the event the user will need to transmit voice, he/she will select one of these conferences and change it to “Active” prior to depressing the PTT. When the PTT button is pressed, the user’s voice will be transmitted onto any and all conferences set to “Active”.

Administration Central to the VCS is the administrator, who is responsible for tailoring the system configuration to meet the specific needs of individual test events. The Administration GUI is the mechanism used to alter the more advanced settings of the VCS. The Administration GUI will be access controlled, and will only be available through privileged administrator accounts. Using customer requirements, and the test plan as a guide, VCS administrators will create the required conferences, add necessary members, and limit conferencing privileges as needed.

Once the VCS system is configured appropriately, the configuration (or a subset) must be able to be saved to a mission file that can be recalled at a later date. This function is vital to reducing the maintainer footprint of the VCS. The Atlantic Test Range routinely conducts multiple flights tests per day, many of which are simultaneous and/or overlapping. The VCS must be able to be quickly reconfigured in time to support the next incoming mission. Mission configurations shall be developed offline, saved, and recalled for future use to reduce downtime between test events, and ensure the exact configuration is used every time.

The Administration GUI also will provide VCS administrators with a mechanism to monitor VCS performance. This GUI will provide the administrator insight into the current performance levels and potential trouble areas, ensuring the system stays operational.

Information Assurance The VCS will be maintained and operated in a Department of Defense (DoD) facility, and will be required to comply with all rules and regulations pertaining to electronic equipment that processes DoD data. All VCS components must be hardened, in accordance with Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs) at the time of system acceptance. As new STIGs are released, VCS system components must be kept up to date (patched) to maintain information assurance certification. To maximize system functionality, all patches must be verified offline, prior to installation on the operational system.

Opportunities for cost savings Given the current fiscal climate, the opportunity to reduce procurement costs without sacrificing performance is highly valued aspect in any potential procurement. Opportunities to achieve cost savings are outlined in the following sections End Instrument Sharing

For most applications, one end instrument (EI) will be required for each user, however certain instances allow for a single EI to be shared by two users. These situations typically occur in the larger rooms, such as the ATR Control Room, or users in Project Engineering Stations (PES). Each opportunity to employ shared EIs is outlined, per user, in Section 7.0

Headset / Handset Reuse

ATR maintains a large inventory of Plantronics Headsets and a significant cost savings will be realized if this equipment is reused. In this context, a “Headset” is a user wearable unit which contains two speakers and a boom microphone.

The modified Plantronics Handsets (SHS 2463-01) currently used provides PTT capabilities and connects in-line, between the Headset, and the EI. The handset interfaces with the headset using a TA6FL, 6 pin Mini XLR Female connector, and interfaces with the EI using a LEMO FGG.2B, 10 pin connector.

Many of these Plantronics Headsets (SHS 2362-01, and SHS 2639-01) are owned by ATR’s customers and brought into the range by each flight test engineer prior to each test event. It is imperative that the new system is able to connect with these units, to avoid an unnecessary cost to ATR customers.

Any delivered handset must be compatible with a 6 pin Mini XLR connector natively, or via an adaptor (REQ# VCS.2.2.4).

Reliability, maintainability, availability

The VCS is used to vector live aircraft assets, and it is essential that the system is designed with reliability, and maintainability to ensure the system is available 99.97%.

It is the vendor’s responsibility to design the system with the appropriate amount of redundancy, and reliability engineering to ensure this value is met.

Vendors shall provide their system performance data for reliability, maintainability, and availability for evaluation.

Statement of Work Project Management The contractor shall attend scheduled meetings on-site at ATR and/or at the contractor’s facility to review designs, develop installation plans and develop procedures.

The contractor shall be available via phone and e-mail to discuss any issues during the period of performance.

<17June14 – Project Status CDRL is no longer a requirement> System Implementation Plan The contractor shall provide a proposed plan for how they will use their COTS equipment (quantity, connectivity, architecture) to implement the system requirements. (CLIN 0019)

<17June14 – NRE CDRL is no longer a requirement>

The contractor shall provide the government with a list of COTS equipment, including prices, which will be used to implement their proposed plan. (CDRL# A001)

The government will review the contractor’s implementation plan, discuss any modifications, and have final approval authority before installation begins.

System Installation The government will be responsible for coordinating the installation effort to ensure flight operations are not affected. Access to the facilities and/or equipment will be scheduled by the ATR Technical Point of Contact (TPOC). Notice of installation times will be given 48 hours in advance.

The contractor shall gain approval from the government before attempting to perform work on any space or equipment.

VCS equipment will be located in secure spaces, and all installers must be US citizens. All personnel who will enter the secure space will be escorted 100% of the time.

The contractor shall submit visit requests via the Joint Personnel Adjudication Service (JPAS), or via a faxed hardcopy base access form (available upon request) for each installer, allowing the government to verify status before granting permission to enter secure spaces.

Factory Acceptance Test Prior to installation, the contractor shall build, configure, and test the core equipment in a test bed located at the contractor’s facility.

The contractor shall perform a formal factory acceptance test of the core equipment and a subset of EIs, with government witnesses present, prior to delivering the equipment for installation.

The contractor shall trace factory acceptance test procedures to the requirements specified within this document.

The contractor shall send an electronic copy of the Factory Acceptance Test Procedures to the government 21 days in advance of performing the Factory Acceptance Test. (CDRL# A004)

The Factory Acceptance Test is not considered complete until all defects are resolved, and the government has signed off on zero-defect test results. (CDRL# A003)

Initial Equipment Installation

The contractor shall install and configure the BLACK core (CLIN0001), RED core (CLIN0002), and administration capability (CLIN0003),(CLIN0004) at ATR, including any support equipment necessary for the system to be fully operational. (CLIN0014)

The contractor shall supply the government with Installation Drawings which detail all the cabling and power requirements that are required for all EIs and ancillary equipment. (CLIN0020)

ATR personnel will install all fiber and/or copper cabling between all rooms and remote sites.

The contractor shall install an initial capability of EIs, to include at minimum:

CLIN0005 Weather Hardened – Qty. 2 CLIN0007 Compact Single-level – Qty. 15 CLIN0008 Desktop, Multi-level – Qty. 3 CLIN0009 Compact Multi-level – Qty. 5

The contractor shall connect an initial capability of four (4) ATR-owned Radios, and one (1) COTS 4-wire device, as identified by the government.

Should changes in initial hardware be required, the government reserves the right to make minor modifications to this hardware list after award and will notify the selector vendor.

The contractor shall verify this initial operational capability performs as intended, per Section 3.4 - System Verification. (CLIN0016)

Remaining Equipment Installation The contractor shall provide the government with all required installation documentation necessary to allow ATR personnel to install the remaining equipment throughout the range. (CLIN0020)

As installation spaces become available, the government will provide delivery orders to the vendor requesting additional hardware for installation.

ATR personnel will install the contractor provided equipment at all remaining locations, per contractor documentation.

The contractor shall be available via phone and e-mail to answer any installation questions as they arise.

System Verification With each delivery order that includes Follow-on Testing (CLIN0017), the contractor shall return to ATR once the installation is complete and perform on site verification, with government witnesses present, for each installed increment.

The contractor shall trace on-site acceptance test procedures to the requirements specified within this document.

The contractor shall tailor the test procedures to match the untested equipment to ensure proper verification while avoiding unnecessary costs, and send an electronic copy of the On-site Acceptance Test Procedures to the government 21 days in advance of performing the On-site Acceptance Test. (CDRL# A005)

The contractor shall work with ATR personnel to correct any defects discovered through system acceptance testing.

A delivery order is not considered complete until all defects are resolved, and the government has signed off on a zero-defect test results. (CDRL# A006)

Training Upon successful installation, and completion of the final system acceptance test, the government will place a delivery order for the contractor to perform on-site training, for approximately 12 ATR personnel on how to use, troubleshoot, and maintain the system as installed. Training will be performed on-site, using the installed system. (CDRL# A007) (CLIN0015) <17 June 14 – follow-up consultation requirement has been removed> Technical Data Package The contractor shall deliver a technical data package which includes at minimum:

· Site Implementation Plan (CLIN0019)

· Installation drawings (CLIN0020)

· Data Package,NSP (CLIN0012)

· Operator manuals (CDRL# A008)

· Maintenance manuals (CDRL# A009)

· Recommended Spares List (CDRL# A002) Period of Performance The system must be 100% delivered and installed within 2 years of contract award Spares The vendor must provide adequate spare units with delivered system, to maintain system availability for 1 year (CLIN0013)

Warranty The vendor must provide a warranty for system components, installation, and functionality for a period no less than 12 months after satisfactory site acceptance testing is completed.

Pre Contract-award Activities Site Visit The government will be holding a site visit for this procurement, and will invite all prospective vendors to participate. This visit will be held at the Atlantic Test Ranges facility, and will provide bidders an opportunity to view the site spaces, and ask any questions about the procurement.

All details regarding this site visit, to include the date and time, will be posted on the Federal Business Opportunities website. All prospective vendors are responsible for all costs associated with this site visit.

Vendor Demonstrations Each vendor shall perform a hands-on demonstration for the government, as part of the proposal package, in addition to the written submission.

This demonstration shall include the administration console, scaled-down core equipment, and at least one of each type of end instrument (Weather hardened, Compact, Desktop), and demonstration the following requirements:

Vendors will be allotted 2 hours to demonstrate their equipment, plus 1 hour of setup, and 1 hour of teardown time.

The audience of the demonstration includes users and maintainers. Vendors are responsible for all costs associated with the demonstration date.

Key Performance Parameters The following section contains the critical system capabilities that are essential to the development of VCS. Any delivered system that fails to meet any of these Key Performance Parameters (KPPs) will not be accepted. For any KPPs that allow trade space, the minimum and desired levels of performance are specified.

The KPPs listed in the table below have been extracted from the complete set of system requirements, found in Section 6.0.

48 Conferences per EI

System Requirements The following section contains the hierarchy of the specific, uniquely numbered VCS requirements. Any requirement number containing a “*” indicates that it is a KPP. In the event trade space exists, the acceptable range of performance has been identified in the “Specification” column. The Threshold requirement, or minimum accepted level of performance is identified with a “T=”, and the Objective requirement, or desired level of performance is identified with an “O=”. In the event achieving the Objective level of performance incurs the government a cost that exceeds “best-value”, the Threshold level will be desired.

Conferencing Requirements

Conferences, O=1500)

O= less than or equal to 40ms)

End User Interface Requirements

Conference Communication

O=48 Conferences per EI)

O=1”x1”)

O=24 max)

The EI shall display the current Push-To-Talk (PTT) state (Keyed/Unkeyed) for each connected PTT device, for each conference

O= less than or equal to 1 second)

O=Allow all assigned conferences to be Active)

O=Allow all assigned conferences to be Monitored)

Conference Audio Receipt

O=20 at once

O=Nine spatial positions (Left, L. Far, L. Mid, Mid L., Mid, Mid R., R. Mid, R. Far, Right)

Conference Audio Transmission

O=Indication of which connected PTT trigger is active

Red/Black Audio

Telephone Emulation

O=Expandable

Physical End Instrument Constraints

O=Pole mount and Rack mount)

O=12” display)

O= Dual 6” displays)

Commercial-off-the-Shelf (COTS) Interface Requirements

T1 Interface

Voice over Internet Protocol Interface

4-wire Analog Audio Interface

Key Line Audio

Telephone Interface

Remote Radio Configuration

O=Motorola URC-200, General Dynamics CM 200, INTECH COM160

O=.0001Mhz

O=RS-232 and Ethernet capable (limited by the COTS radio’s interface requirements)

Administration Requirements

Voice Conference Management

Complex Networking

Communication Device Management

System Status