NAWCAD WOLF Voice over Internet Protocol (VOIP) System

Classification Code: 7G22 - IT and Telecom - Network: Satellite And RF Communications Products (HW, Perpetual License Software) NAICS Code(s): 334290 - Other Communications Equipment Manufacturing REQUEST FOR INFORMATION PURSUANT TO FAR 15.201(e) - THIS IS A REQUEST FOR INFORMATION (RFI) ONLY. This RFI is issued solely for information and planning purposes - it does not constitute a Request for Proposal (RFP) or a promise to issue an RFP in the future. This request for information does not commit the Government to contract for any supply or service whatsoever. Further, the government is not at this time seeking proposals and will not accept unsolicited proposals. Responders are advised that the U.S. Government will not pay for any information or administrative costs incurred in response to this RFI; all costs associated with responding to this RFI will be solely at the interested party's expense. Interested parties are responsible for adequately marking proprietary or competition sensitive information contained in their response. Proprietary information will be safeguarded in accordance with the applicable Government regulations. Failure to respond to this RFI does not preclude participation in any future associated RFP that may be issued. BACKGROUND/PURPOSE/TECHNICAL REQUIREMENTS The Naval Air Warfare Center (NAWC) Webster Outlying Field (WOLF) Division is soliciting information and comments from industry on its ability to provide a non-developmental or Commercial off the Shelf (COTS) Voice over Internet Protocol (VoIP) system that will support the USAF Remote Radio Secure Voice System (RRSVS) program. The RRSVS provides distributed voice communications between geospatially separated locations for terrestrial and aerial users. Operators and supervisors reside in a Tactical Operations Center (TOC) to communicate with deployed personnel via Remote Units (RUs). Each TOC has an associated Interface Unit (IU) to coordinate communications between the TOC and remote personnel. Additional communication pathways are provided using Plain Old Telephone System (POTS). Many pathways allow for encryption of voice data. Working in concert, the RRSVS components provide mission essential communications. The goal of the RRSVS Block Upgrade is to provide technology modernization to reduce Space, Weight, and Power (SWaP) while enabling expansion of capabilities. To this end, a new architecture has been proposed for the RRSVS Block Upgrade to facilitate the modernization. The proposed architecture is depicted in Figure 1 (SEE ATTACHED). This figure shows the entire RRSVS communications chain from an operator to aircraft (depicted as airplanes) and other communication targets (depicted as troops) near the remote deployment units (RDUs). This diagram divides the operational area of the RRSVS into two segments. One segment is local to the TOC1 (RRSVS-LOCAL) and the other depicts one set of the remotely deployed equipment2 (RRSVS-REMOTE). The communications lines include a variety of encryption levels and data types. These are color coded as: - The red solid lines denote unencrypted audio data between the operator and the OIU, between the RIU and a self-encrypting radio, or between a CIU and a cryptography device. - The red dotted lines represent voice and control data. This traffic would be encrypted with AES-256 to minimize the risk of crosstalk in the red switch should some of the aircraft traffic be plain text. - The red dashed lines denote operator GUI traffic. This would be encrypted using a protocol such as HTTPS. - The green dashed lines represent control data between the RIU and the radios. This data would include control such as channel frequency selection. - The purple dashed lines represent the system log data including voice communications that is stored utilizing CSfC technology for data at rest. - The black data is bulk encrypted, with an additional encryption occurring in the firewall / router device, as is normal for all IP traffic within a VPN. - The thin blue lines represent Radio Frequency (RF) data. The basic concept of the reference architecture lies in the utilization of small SWaP devices for interface points. This system utilizes current Internet Protocol (IP) technologies to meet the capability requirements and drive significant SWaP reduction in the RRSVS. IP capabilities, similar to, but more comprehensive than just VoIP, provide the core data communication machinery. Specialized interface units (xIU) based on Commercial Off the Shelf (COTS) or Government Owned Technology Solutions (GOTS) products anchor the voice and control data interface devices. All of these devices provide conversion between their native format (e.g., audio, PTT signaling, or other control data) and IP data packets. The system also includes a pair of small and redundant servers supporting data recording and radio routing. Additional interfaces such as public address (PA) speakers and alarm annunciators are also supported. A summary of these external interface units (XIU) is: - Operator Interface Unit (OIU) - provides push-to-talk (PTT) equipment, microphone and listening devices (headset), local application or local web-based UI, and operational control of radio selection and control. The OIU also provides more traditional voice communications through the system to other operators, local public address (PA) systems, the Plain Old Telephone System (POTS), and secure telephony equipment (STE). - Radio Interface Unit (RIU) - translates voice and control information from the IP stream to appropriate signals for the radio. These are required for radios that do not support an IP based voice and control interface. Even if internal crypto exists within the radio equipment, the radio might still require control through a serial port from the RIU. The latest AN/PRC radios support a full voice and control IP network interface. - PA and Alarm Annunciator Interface Unit (AIU) - interfaces between the underlying IP streams and devices such as PA speakers, intercom devices, and alarm annunciators. The AIU may only provide contact closures for external devices. - STE-R Telephony Interface Unit (TIU) - interfaces between the underlying IP streams and STE-R or other secure telecom devices. - Cryptography Interface Unit (CIU) - interfaces between the underlying IP streams and the serial nature of aircraft cryptography devices. These are needed only in the case where legacy radios with embedded COMSEC are employed. This architecture supports both existing radios with associated COMSEC devices and radios with built-in encryption and Ethernet interfaces. Commercial Solutions for Classified (CSfC) concepts and other commercially available information technology equipment may be used to reduce risks but are not required. The architecture includes an Ethernet connection for IU-RU data transport connections that supports any long-haul network. These technologies lead to the overall RRSVS SWaP minimization. Configuration of the system would consist of ensuring the system understands the topology of the devices and any required security certificate needs for the current deployment. The Controller and Recording Server (CRS) devices perform this configuration of the basic IP subnets and expected topology of remote deployment units. Once the basic IP topology is defined and necessary security information are loaded, the system can automatically configure the required IP addresses. The expected concept of operations for data flow from an operator to a radio (remote or local) is as follows: - Operators make radio selections via their GUI. This data flows to the CRS devices to arbitrate radio requests and IP routing information is configured. - Operators make voice transmissions to target radio. o IP addresses are based on CRS assignments to all devices along the pathway. - Data bound for the remote radios passes via IP packet to the bulk encryption device to receive necessary end-point encryption. - Traffic destined for local radio units flows directly to the local radio equipment or RIU/CIU depending on radio capabilities. - At the RRSVS-REMOTE end, the traffic is bulk decrypted and routed to the correct XIU (RIU or CIU if embedded crypto is not available in the radio). The reverse traffic follows the same processing flow, but in the opposite direction. As before, radios local to the RRSVS-LOCAL pass directly into the red switch while radios at the RRSVS-REMOTE site all pass through a black switch and bulk encryption/decryption before the red switch, thus providing a common communication paradigm at the red switch, regardless of radio location or type. The reference architecture provides a description of the state of possible, but it is not a complete design. Additional effort is ongoing to fully define requirements, create design artifacts, and perform additional Systems Engineering Life Cycle (SELC) activities. This design leverages current network equipment, data storage devices, and cryptographic equipment with NSA certification to not hinder the development timeline. The bulk of the design effort is finalization of components that accept configuration from the operators, arbitrate conflicts, and route the network data consisting of voice and control to the proper radios. RESPONSES Requested Information Section 1 of the response shall provide administrative information, and shall include the following as a minimum: - Organization name, mailing address, overnight delivery address (if different from mailing address), phone number, fax number, and name and e-mail of designated point of contact. - Business type (large business, small business, small, disadvantaged business, 8(a)-certified small disadvantaged business, HUB Zone small business, woman-owned small business, very small business, veteran-owned small business, service-disabled veteran-owned small business). - Country of origin for main component(s) Section 2 of the response shall provide technical information, and shall include the following as a minimum: - Interested parties shall respond with existing capabilities or products that meet all or a subset of the aforementioned attributes. Reponses that include information detailing potential tradeoffs or alternative solutions is encouraged. - Respondents should provide a detailed description to address the following in their submission: - Product specification, sketches, or listings of authorized distributors are not to count as part of the page count. 1. Does your company have a product, or family of products that can support any or all of the reference architecture as described? 2. Does your company have a product, or family of products that can support the reference architecture with modifications, and what modifications would be needed to the reference architecture for your product(s) to support the RRSVS goals? 3. If item 1 or 2 was answered affirmatively, describe your product(s) that can meet the reference architecture as described (1) or with modifications (2). 4. If item 1 or 2 was answered affirmatively, what is the status of the listed products in terms of TRL, ordering status, availability, planned support life, etc.? 5. If item 1 or 2 were answered affirmatively, what is the expected unit cost for each component, including any license fees, maintenance plans, etc.? 6. Provide any additional details relevant to your offering regarding the reference architecture as presented or modified that will assist NAWCADWOLF provide a new and enhanced modernization technology to the RRSVS. - If applicable and able, respondents shall include a list of Department of Defense (DoD), Department of Justice (DoJ) or Department of Homeland Security (DoHS) programs of record that currently employ their solution. It would be helpful if a sponsor POC for each program, with email address and phone number could be identified. - The Government is interested in receiving vendors price lists for items they believe meet the need in this RFI. Supplying price data does not imply a contractual obligation and must be provided and marked as PRICE DATA. - Respondents should include a list of authorized distributors. ADDITIONAL INFORMATION In response to this RFI, respondents shall submit written responses, not-to-exceed ten (10) pages in length via electronic mail. Product specification, sketches, or listings of authorized distributors will not count toward the page limitation. The Government is interested in identification of long lead items(s), sub-systems(s), or systems(s). The Government does not intend to award a contract on the basis of this request or to otherwise pay for the information solicited. Proprietary information will be safeguarded in accordance with the applicable Government regulations. All information received in response to the RFI that is marked PROPRIETARY will be handled accordingly. The Government will not be liable for or suffer any consequential damages for any proprietary information not properly identified. Responses to this RFI may not be returned. Respondents may not be notified of the result of the review. Failure to respond to this RFI does not preclude participation in any future associated RFP that may be issued. Information provided in no way binds the government to solicit or award a contract. If a solicitation is released, it will be synopsized on the System for Award Management (SAM) website: www.sam.gov. It is the potential vendor's responsibility to monitor this site for the release of any follow-on information. HOW TO RESPOND Interested parties are requested to respond to this RFI with a PDF Document Format. Responses shall be limited to 10 pages and submitted via e-mail only to contact@example.gov. Proprietary information, if any, should be minimized and must be clearly marked. Responses are due no later than 21 June 2024, 4:00 P.M. EST. Responses to this RFI may not be returned. Respondents may not be notified of the result of the review. If a solicitation is released, it will be synopsized on the SAM website: www.sam.gov. It is the potential vendor's responsibility to monitor this site for the release of any follow-on information.