The file's text, extracted by GovTribe without its formatting.
Voice Conferencing System (VCS) Requirements Document
Document Number: VCSDR00001 Revision 1.0 16 April 2014
Prepared by:
Test Communications Branch Atlantic Test Range 23013 Cedar Point Road Patuxent River, MD 20670
Table of Contents
| 1.0 | Project Introduction | 4 |
| 2.0 | Concept of Operations | 4 |
| 2.1. | System Scenarios | 6 |
| 2.1.1. | Simple Conferencing | 6 |
| 2.1.2. | Communication over Radio | 6 |
| 2.1.3. | Multi-Conferencing | 6 |
| 2.2. | Administration | 7 |
| 2.3. | Information Assurance | 7 |
| 2.4. | Opportunities for cost savings | 8 |
| 2.4.1. | End Instrument Sharing | 8 |
| 2.4.2. | Headset / Handset Reuse | 8 |
| 3.0 | Statement of Work | 9 |
| 3.1. | Project Management | 9 |
| 3.2. | System Implementation Plan | 9 |
| 3.3. | System Installation | 9 |
| 3.3.1. | Factory Acceptance Test | 10 |
| 3.3.2. | Initial Equipment Installation | 10 |
| 3.3.3. | Remaining Equipment Installation | 10 |
| 3.4. | System Verification | 11 |
| 3.5. | Training | 11 |
| 3.6. | Technical Data Package | 11 |
| 3.7. | Period of Performance | 12 |
| 3.8. | Spares | 12 |
| 3.9. | Warranty | 12 |
| 4.0 | Pre Contract-award Activities | 12 |
| 4.1. | Site Visit | 12 |
| 4.2. | Vendor Demonstrations | 12 |
| 5.0 | Key Performance Parameters | 12 |
| 6.0 | System Requirements | 13 |
| 6.1. | Conferencing Requirements | 14 |
| 6.2. | End User Interface Requirements | 14 |
| 6.2.1. | Conference Communication | 14 |
| 6.2.2. | Conference Audio Receipt | 16 |
| 6.2.3. | Conference Audio Transmission | 16 |
| 6.2.4. | Red/Black Audio | 17 |
| 6.2.5. | Telephone Emulation | 18 |
| 6.2.6. | Physical End Instrument Constraints | 18 |
| 6.3. | Commercial-off-the-Shelf (COTS) Interface Requirements | 19 |
| 6.3.1. | T1 Interface | 19 |
| 6.3.2. | Voice over Internet Protocol Interface | 20 |
| 6.3.3. | 4-wire Analog Audio Interface | 20 |
| 6.3.4. | Key Line Audio | 20 |
| 6.3.5. | Telephone Interface | 20 |
| 6.3.6. | Remote Radio Configuration | 21 |
| 6.4. | Administration Requirements | 21 |
| 6.4.1. | Voice Conference Management | 21 |
| 6.4.2. | Complex Networking | 22 |
| 6.4.3. | Communication Device Management | 22 |
| 6.4.4. | System Status | 23 |
| 6.4.5. | System Reports | 24 |
| 6.4.6. | System Diagnostics | 25 |
| 6.4.7. | Remote EI Operation | 25 |
| 6.4.8. | User Account Management | 25 |
| 6.4.9. | System Mission Configuration Files | 26 |
| 6.4.10. | Administration Consoles | 27 |
| 6.5. | Information Assurance Requirements | 27 |
| 7.0 | End Instrument Locations | 28 |
| 7.1. | Maryland and Virginia | 29 |
| 7.2. | NAS Patuxent River | 30 |
| 7.3. | ATR Main Complex | 31 |
| 8.0 | Suggested Equipment List | 32 |
| 9.0 | Acronym List / Glossary | 33 |
| 9.1. | Acronym List | 33 |
| 9.2. | Glossary | 34 |
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
The current voice switch solution uses a combination of Plantronics Headsets (SHS 2362-01, and SHS 2639-01), coupled with a Plantrontics Push-to-Talk (PTT) Handset (SHS 2463-01) to interface with EIs. ATR maintains a large inventory of Plantronics Headsets and Handsets, 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, while “Handset” refers to the inline handheld unit which contains the PTT buttons.
The Plantronics Handsets (SHS 2463-01) 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 EI that interfaces with the Plantronics handsets, using LEMO FGG.2B (REQ# VCS.2.1.3) will yield the highest cost savings for ATR, and is the preferred solution. In the event this is not possible, any delivered handset must be compatible with a 6 pin Mini XLR connector natively, or via an adaptor (REQ# VCS.2.2.4).
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, and provide project status (CDRL# A013).
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. (CDRL# A001)
The contractor shall identify all requirements which will require a non-recurring engineering (NRE) cost to meet, and provide a cost estimate for each item, enabling discuss options with the government to ensure the best value solution is achieved. (CDRL# A003)
The contractor shall provide the government with a list of COTS equipment, including prices, which will be used to implement their proposed plan. (CDRL# A002)
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 unescorted are required to have an active SECRET clearance or better.
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# A005)
Initial Equipment Installation
The contractor shall install and configure the BLACK core, RED core, and administration capability at ATR, including any support equipment necessary for the system to be fully operational.
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. (CDRL# A009)
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, as identified by the government.
The contractor shall connect an initial capability of ATR-owned Radios, as identified by the government.
The contractor shall verify this initial operational capability performs as intended, per Section 3.4 - System Verification.
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. (CDRL# A009)
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 At the completion of each delivery order, the contractor shall return to ATR 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 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# A006)
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# A007)
Training Upon successfully completion of the system acceptance test, the contractor shall 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# A008)
The contractor shall provide an on-site follow-up consultation visit 90 days after final system acceptance test, as scheduled by ATR.
Technical Data Package The contractor shall deliver a technical data package which includes at minimum:
· Site Implementation Plan (CDRL# A001)
· Installation drawings (CDRL# A009)
· Operator manuals (CDRL# A010)
· Maintenance manuals (CDRL# A011)
· Recommended Spares List (CDRL# A012) 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 of 99.97% for 1 year
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). The audience of the demonstration includes users and maintainers. Vendors are responsible for all costs associated with the demonstration.
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.
| Number |
| KPP Description |
| Threshold |
| Objective |
| VCS.1.2 |
| The system shall maintain a one-way, end-to-end communication latency of 125ms or less |
| 125ms |
| <=40ms |
| VCS.2.1 |
| The EI shall provide a tactile mechanism for operators to select one or more voice conferences for communication, utilizing a configurable touch screen, or similar technology. |
| 24 Conferences per EI |
48 Conferences per EI
| VCS.2.2.1.1 |
| The EI shall allow the operator to listen to multiple conferences at one time |
| 8 conferences at once |
| 20 at once |
| VCS.2.2.1.2 |
| The EI shall allow the operator to spatially separate conference audio within the headset (i.e. conference A in left ear only, conference B in right ear only, etc) |
| Left ear only/Right ear only / Both ears |
| Nine spatial positions (Left, L. Far, L. Mid, Mid L., Mid, Mid R., R. Mid, R. Far, Right) |
| VCS.2.4.2 |
| The Multi-level EI shall be capable of becoming members of both secure conferences and unsecure conferences simultaneously (RED/BLACK) |
| Support 180 current RED users, with an expandable architecture |
| Support 180 current RED users, with an expandable architecture |
| VCS.4.9 |
| The system shall provide administrators tools to quickly and consistently reconfigure system configuration and conference settings |
| N/A |
| N/A |
| VCS.5.0 |
| The system shall provide mechanisms to ensure the availability, integrity, and confidentiality of the system and the data it transfers |
| N/A |
| N/A |
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.
| Number |
| Description |
| Specification |
| VCS.0.0 |
| The system shall provide voice conferencing services for Atlantic Test Ranges personnel |
| T=O=Support 500 current users, with an expandable architecture |
Conferencing Requirements
| Number |
| Description |
| Specification |
| VCS.1.0 |
| The system shall join multiple communications devices into logically connected conferences. |
| (T=Max. number of 750 |
Conferences, O=1500)
| VCS.1.1 |
| The system shall transfer voice communication in full duplex |
| VCS.1.2 * |
| The system shall maintain a one-way, end-to-end communication latency of 125ms or less |
| (T=125ms |
O= less than or equal to 40ms)
| VCS.1.3 |
| The system shall be designed to positively prevent voice crosstalk / bleed-over between each logically separated conference at all times |
| (T=O=99.99%) |
| VCS.1.4 |
| The system shall employ modular components, to allow for future expansion of system users. |
End User Interface Requirements
| Number |
| Description |
| Specification |
| VCS.2.0 |
| The system shall provide a configurable, physical user interface device that will allow operators to interact with multiple voice conferences ( End Instrument (EI) ) |
Conference Communication
| Number |
| Description |
| Specification |
| VCS.2.1 * |
| The EI shall provide a tactile mechanism for operators to select one or more voice conferences for communication, utilizing a configurable touch screen, or similar technology. |
| (T=24 Conferences per EI |
O=48 Conferences per EI)
| VCS.2.1.1 |
| The EI shall display all conferences available to the operator in an organized manner (paged format, drop-down menu, etc) |
| VCS.2.1.1.1 |
| The EI shall display conference selection buttons that are sufficiently large enough to be quickly selected with a single finger press |
| (T=0.5”x0.75” |
O=1”x1”)
| VCS.2.1.1.2 |
| The EI shall display a minimum number of conference buttons to the operator at one time, which vary by type |
| VCS.2.1.1.2.1 |
| The Weather Hardened EI shall display a minimum of 8 conference buttons to the operator at one time |
| VCS.2.1.1.2.2 |
| The Desktop EI shall display a minimum of 48 conference buttons to the operator at one time |
| VCS.2.1.1.2.3 |
| The Compact EI shall display a minimum of 24 conference buttons to the operator at one time |
| VCS.2.1.1.3 |
| The EI shall display the status for each conference |
| VCS.2.1.1.3.1 |
| The EI shall display the conference name (or radio frequency), for each conference |
| (T=8 characters max |
O=24 max)
| VCS.2.1.1.3.2 |
| The EI shall display the current conference participation state (Active, Monitor-Only, Inactive) , for each conference |
| VCS.2.1.1.3.3 |
| The EI shall display the current Push-To-Talk (PTT) state (Keyed/Unkeyed) for each connected PTT device, for each conference |
| VCS.2.1.1.3.4 |
| The EI shall indicate the presence of conference audio activity, for each conference |
| VCS.2.1.1.3.5 |
| The EI shall display where the conference audio is currently being directed (i.e. headset left, right, speaker, etc.) , for each conference |
| VCS.2.1.1.3.6 |
| The EI shall indicate the assigned Push-To-Talk (PTT) mechanism, for each conference |
| VCS.2.1.1.3.7 |
| The EI shall automatically update the displayed status, name, and configuration, when it is changed in the Administration GUI, for each conference |
| (T= 5 second updates |
O= less than or equal to 1 second)
| VCS.2.1.2 |
| The EI shall allow the operator to change the type of participation for each conference, as permitted by administrative permissions |
| VCS.2.1.2.1 |
| The EI shall allow the operator to select one or more conferences and place them into "Active" communication mode, where the operator can listen to, and speak on the selected conference |
| (T= Allow 8 “Active” conferences at once |
O=Allow all assigned conferences to be Active)
| VCS.2.1.2.2 |
| The EI shall allow the operator to select one or more conferences and place them into "Monitor-Only" communication mode, where the operator can listen to, but is unable to speak on the selected conference |
| (T= Allow 8 “Monitor-Only“ conferences at once |
O=Allow all assigned conferences to be Monitored)
| VCS.2.1.2.3 |
| The EI shall allow the operator to select one or more conferences and place them into "Inactive" communication mode, where the operator can neither listen to nor speak on the selected conference |
| (T=O=Allow all assigned conferences to be placed Inactive) |
| VCS.2.1.2.4 |
| Each conference button shall toggle between participation modes ("Active", "Monitor-Only") with each successive button selection |
| VCS.2.1.3 |
| The EI unit shall provide an interface for PTT handsets |
| (T=Interface with a commercial standard connector O=Interface with a LEMO FGG.2B Connector) |
| VCS.2.1.4 |
| The EI unit shall provide an interface for a “handmic” |
Conference Audio Receipt
| Number |
| Description |
| Specification |
| VCS.2.2 |
| The EI shall provide a mechanism for operators to receive audio for conferences in "Active" and "Monitor-Only" modes |
| VCS.2.2.1 |
| The EI shall provide the ability to route conference audio to the connected binaural headset(s) or handmics |
| VCS.2.2.1.1 * |
| The EI shall allow the operator to listen to multiple conferences at one time |
| T=8 conferences at once |
O=20 at once
| VCS.2.2.1.2 * |
| The EI shall allow the operator to spatially separate conference audio within the headset (i.e. conference A in left ear only, conference B in right ear only, etc) |
| T=Left ear/Right ear / Both ears |
O=Nine spatial positions (Left, L. Far, L. Mid, Mid L., Mid, Mid R., R. Mid, R. Far, Right)
| VCS.2.2.2 |
| The EI shall provide the ability to route conference audio to an internal, hands-free speaker |
| VCS.2.2.3 |
| The EI shall provide the operator the ability to change the volume level of each individual conference |
| VCS.2.2.3.1 |
| The EI shall allow operators to independently set the conference volume level in the left and right ear of the connected headset(s) |
| VCS.2.2.3.2 |
| The EI shall provide the ability for operators to set the speaker volume level |
| VCS.2.2.4 |
| The EI’s PTT handset shall interface with binaural headsets that use a 6 pin male mini-XLR connecter (TA6ML) to transfer audio |
| (T=via an adapter O=native support) |
| VCS.2.2.5 |
| The EI shall allow multiple headsets to share a single unit |
| (T=2 users per EI O=3 users per EI) |
| VCS.2.2.5.1 |
| The EI shall provide separate volume controls for each shared headset |
| VCS.2.2.5.2 |
| The EI shall provide separate Push-to-talk (PTT) controls for each shared headset |
Conference Audio Transmission
| Number |
| Description |
| Specification |
| VCS.2.3 |
| The EI shall provide a mechanism for operators to transmit audio on conferences in "Active" mode |
| VCS.2.3.1 |
| The EI shall include a PTT handset to trigger voice transmission |
| (T=Provide a PTT handset O=Compatible with current handsets) |
| VCS.2.3.1.1 |
| The EI handset shall provide two Push-to-talk (PTT) buttons, where each PTT button is independently able to trigger voice transmission on its assigned conference(s). |
| VCS.2.3.1.1.1 |
| The EI handset shall include one index-finger actuated momentary PTT button |
| VCS.2.3.1.1.2 |
| The EI handset shall include one thumb-actuated lockable PTT button |
| VCS.2.3.1.2 |
| The EI shall provide operators the ability to assign a single PTT to trigger one or more conferences. |
| VCS.2.3.1.2.1 |
| The EI shall provide operators the ability to assign ‘PTT button 1’ to one or more conferences |
| VCS.2.3.1.2.2 |
| The EI shall provide operators the ability to assign ‘PTT button 2’ to one or more conferences |
| VCS.2.3.2 |
| The EI shall interface with handheld Microphone/PTT devices (handmic) |
| (T=Interface with a commercial standard connector O=Interface with a LEMO FGG.2B Connector) |
| VCS.2.3.2.1 |
| The handmic shall contain an integrated speaker |
| VCS.2.3.2.2 |
| The handmic shall contain an integrated microphone |
| VCS.2.3.2.3 |
| The handmic shall contain a single PTT button |
| VCS.2.3.3 |
| The EI shall allow multiple handsets to share a single unit |
| (T=2 users per EI O=4 users per EI) |
Red/Black Audio
| Number |
| Description |
| Specification |
| VCS.2.4 |
| The system shall provide multiple EI models to handle a combination of secure (RED) and unsecure (BLACK) communication schemes |
| VCS.2.4.1 |
| The Single-level EI shall be capable of connecting to either BLACK or RED voice networks |
| VCS.2.4.1.1 |
| When connected, the Single-level EI shall properly handle BLACK audio |
| VCS.2.4.1.2 |
| When connected, the Single-level EI shall properly handle RED audio |
| T=O=Provide letter of volatility |
| VCS.2.4.2 * |
| The Multi-level EI shall be capable of becoming members of both secure conferences and unsecure conferences simultaneously (RED/BLACK) |
| (T=O= Support 180 current RED users, with an expandable architecture) |
| VCS.2.4.2.1 |
| The Multi-level EI shall separate all classified (RED) and unclassified (BLACK) audio, when an EI is a member of both RED and BLACK conferences |
| VCS.2.4.2.2 |
| The Multi-level EI shall isolate RED voice traffic from BLACK circuits in the event of a failure |
| VCS.2.4.2.3 |
| The Multi-level EI shall provide mechanisms to mute all RED audio in the event audio is being transmitted on a BLACK conference |
Telephone Emulation
| Number |
| Description |
| Specification |
| VCS.2.5 |
| The EI shall provide operators telephone functionality |
| VCS.2.5.1 |
| The EI shall provide operators the ability to dial outside telephone numbers |
| T=Connected to 4 POTS lines |
O=Expandable
| VCS.2.5.2 |
| The EI shall provide operators the ability to receive calls from outside telephone numbers |
Physical End Instrument Constraints
| Number |
| Description |
| Specification |
| VCS.2.6 |
| The system shall provide multiple End Instrument (EI) models to support the varying communications needs and physical environments |
| VCS.2.6.1 |
| The system shall provide single-level “Weather Hardened EIs” which are hardened against moisture and temperature, and are able to function in a semi-sheltered environment |
| VCS.2.6.1.1 |
| The Weather Hardened EI shall consist of a single encased unit which can be mounted in a rack, or on a pole |
| (T=Rack mount |
O=Pole mount and Rack mount)
| VCS.2.6.1.2 |
| The Weather Hardened EI shall withstand ambient temperatures from 0°F to 120°F |
| VCS.2.6.1.3 |
| The Weather Hardened EI shall withstand environments up to 100% humidity, with light water spray |
| VCS.2.6.2 |
| The system shall provide single and multi-level large screen “Desktop EIs” which will be used in a desktop, office environment |
| (T=10” diagonal display |
O=12” display)
| VCS.2.6.2.1 |
| The Desktop EI shall include a touch-panel, able to be placed on a desktop |
| VCS.2.6.2.2 |
| The Desktop EI shall withstand ambient temperatures from 50°F to 100°F |
| VCS.2.6.2.3 |
| If additional hardware is required by design, all non-touch-panel Desktop EI hardware shall be rack-mounted, separate from the touch panels |
| VCS.2.6.2.4 |
| The Desktop EI touch-panel and non-touch-panel hardware (if required by design) shall function when separated by 80 feet of cabling |
| (T=O 80ft. separation) |
| VCS.2.6.3 |
| The system shall provide single and multi-level “Compact EIs” which will be used at an engineering workstation, in an office like environment, with limited desk space |
| (T=6” diagonal display |
O= Dual 6” displays)
| VCS.2.6.3.1 |
| The Compact EI shall include a touch-panel able to be placed on a desk, arm mounted, or rack mounted |
| (T=Desk mounted, O=Arm mounted) |
| VCS.2.6.3.2 |
| The Compact EI shall withstand ambient temperatures from 50°F to 100°F |
| VCS.2.6.3.3 |
| If additional hardware is required by design, all non-touch-panel Compact EI hardware shall be rack-mounted, separate from the touch panels |
| VCS.2.6.3.4 |
| The Compact EI touch-panel and non-touch-panel hardware (if required by design) shall function when separated by 80 feet of cabling |
| (T=O 80ft. separation) |
Commercial-off-the-Shelf (COTS) Interface Requirements
| Number |
| Description |
| Specification |
| VCS.3.0 |
| The system shall interface with Commercial-Off-the-Shelf (COTS) communication devices |
T1 Interface
| Number |
| Description |
| Specification |
| VCS.3.1 |
| The system shall be capable of interfacing with devices using a T1 circuit |
| VCS.3.1.1 |
| The system shall allow new T1 circuits to be added |
| VCS.3.1.2 |
| The system shall allow connected T1 circuits to be removed |
| VCS.3.1.3 |
| The system shall be capable of interfacing with the T1 as a single circuit |
| VCS.3.1.4 |
| The system shall be capable of interfacing with the individual DS0 channels, within the T1 circuit |
| VCS.3.1.5 |
| The system shall be capable of setting framing |
| VCS.3.1.6 |
| The system shall be capable of setting the line coding |
| VCS.3.1.7 |
| The system shall be capable of setting the signaling type |
| VCS.3.1.8 |
| The system shall be capable of adjusting DS0 line levels |
Voice over Internet Protocol Interface
| Number |
| Description |
| Specification |
| VCS.3.2 |
| The system shall be capable of exchanging Voice over a standard IP network (VoIP) |
| VCS.3.2.1 |
| The system shall be capable of exchanging VoIP with individual COTS communications devices |
| VCS.3.2.2 |
| The system shall be capable of exchanging VoIP with external VoIP systems |
| VCS.3.2.3 |
| The system shall exchange audio with other Session Initiation Protocol (SIP) capable voice devices |
| T=interface via a separate, external interface unit O=interface via native capability |
4-wire Analog Audio Interface
| Number |
| Description |
| Specification |
| VCS.3.3 |
| The system shall be capable of exchanging two-way analog audio with COTS 4-wire devices |
| (T=O=Support 100 current 4-wire devices, with an expandable architecture) |
| VCS.3.3.1 |
| The system shall allow new COTS devices to be added |
| VCS.3.3.2 |
| The system shall allow connected COTS devices to be removed |
Key Line Audio
| Number |
| Description |
| Specification |
| VCS.3.4 |
| The system shall key COTS equipment to transmit audio |
| VCS.3.4.1 |
| The system shall key COTS equipment via PTT |
| VCS.3.4.2 |
| The system shall key COTS equipment via Voice Operated Transmission (VOX) |
Telephone Interface
| Number |
| Description |
| Specification |
| VCS.3.5 |
| The system shall be capable of exchanging audio with Plain Old Telephone Service (POTS) circuits |
| VCS.3.5.1 |
| The system shall allow new POTS phone lines to be added |
| VCS.3.5.2 |
| The system shall allow connected POTS phone lines to be removed |
Remote Radio Configuration
| Number |
| Description |
| Specification |
| VCS.3.6 |
| The system shall be capable of controlling configuration settings for COTS 2-way radios |
| T=Motorola URC-200 |
O=Motorola URC-200, General Dynamics CM 200, INTECH COM160
| VCS.3.6.1 |
| The system shall be capable of setting UHF/VHF transmit and receive radio frequencies to .001 MHz |
| T=.001Mhz |
O=.0001Mhz
| VCS.3.6.2 |
| The system shall be capable of setting radio modulation schemes as AM or FM |
| VCS.3.6.3 |
| The system shall be capable of adjusting radio squelch (0-100%) |
| VCS.3.6.4 |
| The system shall be capable of controlling connected radios via RS-232 or Ethernet |
| T=RS-232 |
O=RS-232 and Ethernet
Administration Requirements
| Number |
| Description |
| Specification |
| VCS.4.0 |
| The system shall provide a centralized mechanism to administer VCS system configurations over a standard IP network |
Voice Conference Management
| Number |
| Description |
| Specification |
| VCS.4.1 |
| The system shall provide administrators the ability to centrally manage all voice conferences without requiring a system reset |
| VCS.4.1.1 |
| The system shall provide administrators the ability to add new voice conferences |
| VCS.4.1.2 |
| The system shall provide administrators the ability to remove existing voice conferences |
| VCS.4.1.3 |
| The system shall provide administrators the ability to name voice conferences |
| VCS.4.1.4 |
| The system shall provide administrators the ability to manage members within each conference |
| VCS.4.1.4.1 |
| The system shall provide administrators the ability to add individual communication devices (including radios) to a conference |
| VCS.4.1.4.2 |
| The system shall provide administrators the ability to remove communication devices from conferences |
| VCS.4.1.4.3 |
| The system shall provide administrators the ability to name communication devices |
| VCS.4.1.4.4 |
| The system shall provide administrators the ability to limit communication privileges for each member, in each conference |
| VCS.4.1.4.4.1 |
| The system shall provide administrators the ability to grant communication devices the privilege of transmitting on a per conference basis (Active mode) |
| VCS.4.1.4.4.2 |
| The system shall provide administrators the ability to disallow communication devices the privilege of transmitting on a per conference basis (Monitor-Only mode) |
| VCS.4.1.4.4.3 |
| The system shall provide administrators the ability to enable the ability for devices to route audio to the EI’s internal speaker, per conference |
| VCS.4.1.4.4.4 |
| The system shall provide administrators the ability to disable the ability for devices to route audio to the EI’s internal speaker, per conference |
Complex Networking
| Number |
| Description |
| Specification |
| VCS.4.2 |
| The system shall provide administrators the ability to join multiple conferences to form a single logical conference |
| (T=Ability to join up to 5 Conferences, O=10 Conferences) |
| VCS.4.2.1 |
| The system shall allow members of one or more conferences to communicate across conference boundaries, while their respective conferences are “joined” together |
| VCS.4.2.2 |
| The system shall provide administrators the ability to separate joined conferences into their original states |
Communication Device Management
| Number |
| Description |
| Specification |
| VCS.4.3 |
| The system shall provide administrators the ability to manage communication devices connected to the system device network |
| VCS.4.3.1 |
| The system shall provide administrators the ability to add communication devices to the network |
| VCS.4.3.2 |
| The system shall provide administrators the ability to remove communication devices from the network |
| VCS.4.3.3 |
| The system shall provide administrators the ability to give meaningful names to communication devices attached to the network |
| VCS.4.3.4 |
| The system shall provide administrators with the ability to enable voice operated transmission (VOX) |
| VCS.4.3.4.1 |
| The system shall provide administrators the ability to set the VOX activation audio level |
| VCS.4.3.4.2 |
| The system shall provide administrators with the ability to set the duration after the VOX level drops below threshold |
| VCS.4.3.5 |
| The system shall provide administrators the ability to manage EI configurations |
| VCS.4.3.5.1 |
| The system shall provide administrators the ability to select one or more EI(s) to apply configuration changes |
| VCS.4.3.5.2 |
| The system shall provide administrators the ability to select one or more EI(s) and clear all assigned conferences |
| VCS.4.3.5.3 |
| The system shall provide administrators the ability to select one or more EI(s) and clear out a single, selected conference |
| VCS.4.3.6 |
| The system shall provide administrators the ability to manage Radio configurations |
| VCS.4.3.6.1 |
| The system shall provide administrators the ability to alter the transmit frequency for each connected, configurable UHF/VHF radio |
| VCS.4.3.6.2 |
| The system shall provide administrators the ability to alter the receive frequency for each connected, configurable radio |
| VCS.4.3.6.3 |
| The system shall provide administrators the ability to alter the modulation (AM/FM) for each connected, configurable radio |
| VCS.4.3.6.4 |
| The system shall provide administrators the ability to alter the squelch level for each connected, configurable radio |
System Status
| Number |
| Description |
| Specification |
| VCS.4.4 |
| The system shall provide administrators the ability to view system status |
| VCS.4.4.1 |
| The system shall provide administrators the ability to view all voice conferences |
| VCS.4.4.1.1 |
| The system shall display a list of all voice conferences, by name, sorted in alphabetical order |
| VCS.4.4.1.2 |
| The system shall provide the administrators the ability to search for conferences, by name |
| VCS.4.4.1.3 |
| The system shall display a list of voice conferences, by current status |
| VCS.4.4.1.3.1 |
| The system shall display a list of all voice conferences that have less than, or equal to one communication device assigned to it |
| VCS.4.4.1.3.2 |
| The system shall display a list of all voice conferences that are actively keyed on one or more of its member's communication devices |
| VCS.4.4.1.4 |
| The system shall provide administrators the ability to select a conference and view its members |
| VCS.4.4.2 |
| The system shall provide administrators the ability to view connected communication devices (including EIs, Radios, Telephones, 4-wire, T1, VoIP) |
| VCS.4.4.2.1 |
| The system shall display a list of all communication devices, by name, sorted in alphabetical order |
| VCS.4.4.2.2 |
| The system shall provide the administrators the ability to search for communication devices, by name |
| VCS.4.4.2.3 |
| The system shall provide administrators the ability to display a list of communication devices by type (EI, Radio, Telephone, 4-wire, T1, VoIP) |
| VCS.4.4.2.4 |
| The system shall provide administrators the ability to display a list of communication devices, by current status |
| VCS.4.4.2.4.1 |
| The system shall display a list of all communication devices that are members of less than, or equal to one conference |
| VCS.4.4.2.4.2 |
| The system shall display a list of all communication devices that have one or more actively keyed PTT mechanism(s) |
| VCS.4.4.2.5 |
| The system shall provide administrators the ability to select a communication device and view the conference(s) it is a member of |
| VCS.4.3.2.6 |
| The system shall provide administrators the ability to select a Radio and view the current settings, to include at minimum transmit/receive frequency, modulation, power level (high/low) and squelch |
System Reports
| Number |
| Description |
| Specification |
| VCS.4.5 |
| The system shall provide administrators the ability to generate system reports |
| VCS.4.5.1 |
| The system shall provide administrators the ability to generate a report for the entire system |
| VCS.4.5.2 |
| The system shall provide administrators the ability to select a subset of communication devices for report generation |
| VCS.4.5.3 |
| The system shall provide administrators the ability to generate a report containing the history of all administrative changes |
| VCS.4.5.3.1 |
| The system shall generate a report of all conference membership changes (add/remove communication devices), with a timestamp for each event |
| VCS.4.5.3.2 |
| The system shall generate a report of each time a mission file has been loaded, with a timestamp for each event |
| VCS.4.5.3.3 |
| The system shall provide administrators the ability to clear admin log history |
| VCS.4.5.3.4 |
| The system shall provide the ability to export these log files in a readable format (.csv, etc) |
| VCS.4.5.3.5 |
| The system shall provide the ability to write these log events using the syslog protocol, per RFC 5424. |
System Diagnostics
| Number |
| Description |
| Specification |
| VCS.4.6 |
| The system shall provide administrators tools to diagnose system health issues |
| VCS.4.6.1 |
| The system shall provide administrators the ability to select any communication device, and send a tone to test end-to-end connectivity |
| VCS.4.6.2 |
| The system shall provide administrators the ability to view system alarms |
| VCS.4.6.2.1 |
| The system shall identify links in the device network that are experiencing connectivity failures |
| VCS.4.6.2.2 |
| The system shall identify EI(s) which are experiencing failures |
| VCS.4.6.3 |
| The system shall provide diagnostic indicators to isolate system issues to major system components, and sub-components |
Remote EI Operation
| Number |
| Description |
| Specification |
| VCS.4.7 |
| The system shall provide administrators the ability to have full control of any connected EI, through the device network, regardless of physical location |
| VCS.4.7.1 |
| The system shall provide administrators the ability to select any EI connected to the device network, for remote administration |
| VCS.4.7.2 |
| The system shall display a graphical representation of the selected EI’s Graphical User Interface (GUI), updating the display as configuration changes occur. |
| VCS.4.7.3 |
| The system shall provide administrators the ability to remotely interact with the selected remote EI Graphical User Interface (GUI), as if the administrator was physically sitting in front of the device |
User Account Management
| Number |
| Description |
| Specification |
| VCS.4.8 |
| The system shall provide administrators the ability to manage system user accounts |
| VCS.4.8.1 |
| The system shall provide administrators the ability to add new users to the system |
| VCS.4.8.2 |
| The system shall provide administrators the ability to remove users from the system |
| VCS.4.8.3 |
| The system shall provide administrators the ability to manage multiple classes of user privileges |
| (T=3 User classes, O=5) |
| VCS.4.8.3.1 |
| The system shall provide administrators the ability to set user accounts with "End User" privileges, restricting access to all administrative functions |
| VCS.4.8.3.2 |
| The system shall provide administrators the ability to set user accounts with "Power User" privileges, allowing limited administration functions, such as loading preconfigured radio profiles, and system missions |
| VCS.4.8.3.3 |
| The system shall provide administrators the ability to set user accounts with "System Administrator" privileges, allowing full access to all administrative functions |
| VCS.4.8.3.4 |
| The system shall provide administrators the ability to customize the specific level of privileges associated with each user level. |
| VCS.4.8.4 |
| The system shall provide administrators the ability to reset / change user passwords |
System Mission Configuration Files
| Number |
| Description |
| Specification |
| VCS.4.9 * |
| The system shall provide administrators tools to quickly and consistently reconfigure system configuration and conference settings |
| VCS.4.9.1 |
| The system shall provide administrators the ability to reconfigure multiple system conferences via mission configuration files |
| VCS.4.9.1.1 |
| The system shall provide administrators the ability to create VCS Mission configurations |
| VCS.4.9.1.1.1 |
| The system shall provide administrators the ability to create a “Mission” by saving conference membership settings for the entire system |
| VCS.4.9.1.1.2 |
| The system shall provide administrators the ability to create a “Mission” by saving conference membership settings for a subset of VCS components |
| VCS.4.9.1.2 |
| The system shall provide administrators the ability to edit a VCS Mission without affecting the current system configuration |
| VCS.4.9.1.3 |
| The system shall provide administrators the ability to delete VCS Missions |
| VCS.4.9.1.4 |
| The system shall provide administrators the ability to update conference membership settings, by loading one or more VCS Missions |
| VCS.4.9.1.5 |
| The system shall display a list of Missions available on the system, along with basic parameters to include: Mission name, Description, number of connections, last modified date, last loaded date |
| VCS.4.9.2 |
| The system shall provide administrators the ability to replicate EI conference configurations, via EI Templates |
| VCS.4.9.2.1 |
| The system shall provide administrators the ability to save the any EI's conference configuration into an EI Template |
| VCS.4.9.2.2 |
| The system shall provide administrators the ability to edit an EI Template |
| VCS.4.9.2.3 |
| The system shall provide administrators the ability to delete an EI Template |
| VCS.4.9.2.4 |
| The system shall provide administrators the ability to reconfigure any EI's conference configuration by applying an EI template to it |
| VCS.4.9.4 |
| The system shall provide administrators the ability to backup system configuration files to removable media |
| VCS.4.9.5 |
| The system shall provide administrators the ability to restore system configuration files from removable media |
Administration Consoles
| Number |
| Description |
| Specification |
| VCS.4.10 |
| The system shall allow for multiple administration consoles at one time |
| (T=8, O=12+) |
| VCS.4.10.1 |
| The system shall be able to administer both RED and BLACK conferences/components from each administration console |
| VCS.4.10.2 |
| The system shall apply controls to guard against multiple consoles from changing the same device/conference at the exact same time |
| VCS.4.10.1 |
| All administration consoles shall stay synchronized with all system configuration changes |
| VCS.4.10.2 |
| The administration consoles shall communicate with the core system via Ethernet connected computers |
| (T=Software application based consoles, O=Web browser based consoles) |
| VCS.4.10.3 |
| The administration console shall provide a mechanism to update any connected EI |
Information Assurance Requirements
This is the start of the file's text. The full file is on GovTribe.