140811_Q_A_to_Draft_RFP-06_Oct_14.doc

STS HH Radio Questions and Responses from the Draft RFP Solicitation Number: H92222-12-R-0017

1. Performance Specification, 3.4.3 ISR Video Receive Capability / Interoperability Specifies 640 x 480 pixels at 15 frames per second. It is recommended to increase this specification to include HD resolutions of 720p60 (1280 x 720 @ 60fps) or 1080i30 (1920 x 1080 @ 30fps) as an ‘objective’ requirement.

Question: Is the requirement to obtain these resolutions (HD or SD) at an eyepiece (i.e. monocle) or at the display of a computer?

Response: The NGHH shall support both SD and HD. The requirement is for the ISR receiver to support various video resolutions from 640x480 @15 fps to 1920 x 1080p @ 30 fps. The end user display device is not being procured as part of the NGHH system.

2. Performance Specification, 3.4.4.1 SOF users require the ability to receive ISR feeds, providing both Standard Definition (SD) and High Definition (HD )

Question: Is the requirement to obtain these resolutions (HD or SD) at an eyepiece (i.e. monocle) or at the display of a computer?

Response: Both SD and HD are required resolutions at a monocle and End User Device (EUD).

3. Performance Specification, 3.4.3 ISR Video Receive Capability / Interoperability Specifies Frequency Bands of L, S, C and Ku, but the table omits the Frequency Bands for Ku of 14.4-14.83GHz and 15.15-15.35 GHz.

Question: We suggest adding these additional frequency bands for clarity.

Response: KU frequency bands were added to the Performance Specification (PS).

4. Performance Specification, 3.4.3 ISR Video Receive Capability / Interoperability Specifies 10.71Mbps as the Maximum Data Rate, however, it is very realizable today to receive 44.73Mbps and suggest this become an ‘objective’ requirement. Many, if not most, of the air assets are capable of transmitting 21.42 and 44.73Mbps. We recommend including the higher CDL rates as an objective.

Question: We recommend including the higher CDL rates as an objective Response: The CDL rates were modified with higher vendor agnostic data rates as an objective.

5. Performance Specification,3.4.3 ISR Video Receive Capability / Interoperability Specifies CDL, DDL and STANAG 7085 as the waveforms. Also note that STANAG 7085, Implementation 1 is effectively analogous to CDL. We suggest including VNW and “Predator” or “Tactical” waveforms as well as ‘threshold’ requirements.

Question: We also suggest adding Bandwidth Efficient CDL (BE-CDL) as an ‘objective’ requirement. This waveform is moving forward as an IOP compliance for the US Army.

Response: BE-CDL was added as a requirement.

6. Performance Specification, 3.7.4, Commercial and Proprietary Waveforms The Table in section 3.7.4.1 specifies Frequency Bands of 224-450 MHz, 1775 - 1815 MHz, and 2312-2507 MHz.

Question: It is recommended to include C-band frequencies of 4400-5800 MHz as ‘threshold’ requirements. This will increase operational flexibility by including additional military and unlicensed spectrum as options.

Response: The frequency bands were modified accordingly.

7. Performance Specification, 3.7.4, Commercial and Proprietary Waveforms The table specifies maximum data rates of 37 Mbps UDP, 27 Mbps TCP for 20 MHz channel.

Question: It is recommended to choose the maximum data rates to 80Mbps for UDP and 65Mpbs for TCP connections as ‘threshold’ requirements. These are realizable today and represent throughputs necessary for maximum functionality.

Response: The data rates were modified somewhat with vendor agnostic values.

8. Draft RFP

Question: Is the five year warranty specified in the CLINS and Section 10.0 ‘Warranty', a requirement, or should it be priced as an option in addition to the manufacturer’s standard warranty?

Response: Yes, a five year warranty is the minimum requirement.

9. Draft RFP Section H.3 refers to 5652.216‐9004 "Procedures for Issuing Delivery Orders under Single Aware, IDIQ Contracts”

Question: Does this mean you anticipate only a single award as a result of the RFP?

Response: The Government anticipates a single award but may choose to award multiple contracts.

10. Performance Specification, 1.2.1 Handheld (HH) Device Question: Where the HH is referenced, does this imply that these same specifications apply to the Mission Module? Will separate specifications be included?

Response: The MM must meet all the environmental requirements including 20 meter immersion when and when not connected to the HH. Electrical performance shall also comply with those cited for the host radio itself.

11. Performance Specification, 3.2.1Software Communications Architecture (SCA) Question: If the MANET is a Mission Module, does this specification apply?

Response: SCA is not required for MM.

12. Performance Specification, End User Device (EUD) Connection to HH / MM Question: If integrated into the HH device, the device must be able to connect to the EUD. If the MANET is included as a Mission Module, then the connection should be to the MANET/Mission Module not the HH.

Response: The EUD will be connected to the host HH and the operator shall be able to see and control the MM through the HHR. However, programming of the MM may be accomplished through the HH or through a direct connection to the MM.

13. Performance Specification, 3.2.3.1-3.2.3.3 and 3.2.3.6 Question: The above paragraphs suggest that the Mission Module is totally dependent on the HH, is that the intent?

Response: Yes, the MM should be controlled and operated through HH Human Machine Interface (HMI). However, programming of the MM may be accomplished through the HH or through a direct connection to the MM.

14. Performance Specification, 3.4.3 ISR Video Receive Capability / Interoperability Question: Can you please define what “Yes” means for MESH Network in this matrix?

Response: Reference to Mesh Network in paragraph 3.4.3 is deleted. The ISR receiver will provide video to the host radio and the radio will distribute the video via the internal MANET channel to other STC HH users.

15. Performance Specification, Multifunctional Capabilities 3.4.4 - Intelligence, Surveillance & Reconnaissance (ISR)

Question: How does this distribute simultaneously if both the ISR and MANET are integrated as a Mission Module?

Response: The radio has an internal wideband channel that is used to disseminate the video when the ISR MM is attached. The HH shall control video distribution.

16. Performance Specification, Multifunctional Capabilities 3.4.5 Simultaneous Channel Operation Question: How can this be simultaneous if both the ISR and MANET are incorporated as a Mission Module?

Response: The radio has an internal wideband channel that is used to disseminate the video when the ISR MM is attached.

17. Performance Specification, Mobile Ad Hoc Networking (MANET) Waveforms 3.7.5 Encryption Question: How can the HH be a subscriber in the MANET if it is connected via Mission Module? Can you please define subscriber?

Response: The radio has an internal wideband channel that is used to disseminate the video when the ISR MM is attached via the HH cross-banding capability.

18. Performance Specification, Mobile Ad Hoc Networking (MANET) Waveforms 3.7.7 Operate as Standalone or Member Device

Question: This section (3.7.7) appears to be using terminology related to a specific solution. Unsure of the intent or meaning. Please provide details.

Response: Whether using the internal wideband channel (MANET) or a MANET MM the HH is the term used to describe the complete system including all Mission Modules. The HH controls the Mission Modules through the organic HH keypad and through the connected EUD using remote control applications. However, programming of the MM may be accomplished through the HH or through a direct connection to the MM.

19. Performance Specification, Physical Characteristics 4.4 Environmental Question: Are MM expected to meet the same environmental conditions as the HH?

If the MM is expected to meet the same standards as the HH, is it expected that there will be different versions of the MM to include a maritime and urban version?

If the MM is not expected to meet the same conditions, MM environmental specifications are not defined anywhere else in the document. This also applies to electrical specifications.

Response: The MM is expected to meet the same environmental requirements as the HH including immersion of 20 meters.

20. Performance Specification, Electrical Characteristics and Performance Question: Are MM expected to meet the same environmental conditions as the HH? If the MM is expected to meet the same standards as the HH, is it expected that there will be different versions of the MM to include a maritime and urban version?

If the MM is not expected to meet the same conditions, MM environmental specifications are not defined anywhere else in the document. This also applies to electrical specifications.

Response: The MMs are expected to meet the same requirements as the radio host. However, the offeror should identify those requirements that it can, cannot or only partially meet. The Government does not intend to provide separate MM variants (Urban or Maritime), thus the MM must meet the same requirements as the maritime HH.

21. Performance Specification, Logistics 6.0 Question: Are MM expected to meet the same environmental conditions as the HH?

If the MM is expected to meet the same standards as the HH, is it expected that there will be different versions of the MM to include a maritime and urban version?

If the MM is not expected to meet the same conditions, MM environmental specifications are not defined anywhere else in the document. This also applies to electrical specifications.

Response: The MMs are expected to meet the same requirements as the radio host. However, the offeror should identify those requirements that it can, cannot or only partially meet.

22. Performance Specification, Workmanship, 8.0 Question: Are MM expected to meet the same environmental conditions as the HH?

If the MM is expected to meet the same standards as the HH, is it expected that there will be different versions of the MM to include a maritime and urban version?

If the MM is not expected to meet the same conditions, MM environmental specifications are not defined anywhere else in the document. This also applies to electrical specifications.

Response: The MMs are expected to meet the same requirements as the radio host. However, the offeror should identify those requirements that it can, cannot or only partially meet.

23. Performance Specification, 10.0, ENVIRONMENTAL TEST REQUIREMENTS Question: Does the MM need to meet all of these requirements? Will this be funded by the Government?

Response: The MMs are expected to meet the same requirements as the radio host. However, the offeror should identify those requirements that it can, cannot or only partially meet. Cost for testing will be borne by the contractor per the SOW.

24. Performance Specification, Section 3.7.4.1 A UBLOX 6 GPS is called out in the GPS section but a SAASM based GPS is called out everywhere else in the document.

Question: Are you requiring both? In our experience most HH radios call for one or the other.

Response: The requirement is for a SAASM / MGUE or comparable GPS capability.

25. Performance Specification, Section 3.9.1.1 The current MicroGRAM supports 1 output but we have talked internally about supporting multiple outputs in the future.

Question: Does this requirement indicate that 2 timing outputs are required?

Response: Each channel may require access to timing simultaneously. Whether the MicroGram provides two outputs or the design of the radio splits the single timing output is at the discretion of the contractor.

26. Performance Specification, Section 3.9.1.7

Question: This paragraph should be changed to require a SAASM based GPS receiver and not call out a GB-GRAM specifically. GB-GRAM compliance as you have it limits this program to a Type II form factor which may be too large to embed. Changing the language to "SAASM based GPS receiver" allows for smaller form factors like MicroGRAM.

Response: Paragraph changed accordingly.

27. Reference Section L, Section L.3.1.1.1 Provide a brief narrative for each contract or subcontract listed. Explain the nature of the work involved and the extent the work involved was/is similar to the STC HH effort in terms of operations, contract scope, schedule, and risk.

Question: If an offeror refers to work which includes technology that the offeror has obtained by a licensing agreement, is the offerer required to provide a statement from the supplier of the licensed technology that evidences that the offerer and the supplier have entered into an agreement whereby the supplier of the licensed technology will allow the use of the licensed technology for the purpose of STC HH?

Response: Yes.

28. Performance Specification, 1.2.1, Handheld (HH) Device As an Objective (O), it will support advanced LPI/LPD/LPE waveforms that transmit and receive voice and data Question: Add the following – “The STC HH will be capable of computing an estimate of the probability of intercept of the selected LPD waveform. The probability of intercept will be computed by on-board analysis in real-time by considering the prevailing RF environment, the characteristics of the selected LPD waveform, and the characteristics of likely intercept threats.”

Response: Comparable language was added to the paragraph.

29. Performance Specification, 3.1.1, HH System Components

Question: An appropriate antenna array for single-node Angle of Arrival (AOA) should be identified.

Response: Such an antenna array will be added to the ancillary items as well as comparable language describing the special purpose antenna.

30. Performance Specification, 3.3.3.2, SCAN Characteristics

Question: Modify the paragraph to read, “The HH shall monitor from 2 to 10 preset scan channels for a time of 0.25 to 0.50 seconds before moving to the next channel. Scanning will cease when the device is transmitting or receiving. The HH shall also be capable of general scan. In general scan, the frequency search criteria will consist of a collection of frequency intervals, where the intervals are of a bandwidth that may be significantly larger.

Response: Comparable language added to the paragraph.

31. Performance Specification, 3.4, Multifunctional Capabilities

Question: Modify the sub-paragraph to read, “Compatibility and interoperability with other systems/devices such as tactical sensors shall provide rudimentary intelligence capabilities not found in current radios. (O) The STC HH will be capable of exporting a posteriori probability density function (PDF) for the position of a SOI, from either AOA or TDOA.

Response: Comparable language added to the paragraph.

32. Performance Specification, 3.4, Multifunctional Capabilities

Question: Modify the sub-paragraph to read, “Provide detection and location of Signals of Interest (SOI) at significantly relevant stand-off distances. The STC HH will satisfy the performance requirements of the GSK-BW SOW as a minimum.“ Response: The Government believes this is beyond the scope of its requirements.

33. Performance Specification, 3.4, Multifunctional Capabilities Question: Modify the sub-paragraph to read, “Relay relevant data via communications network for informational reporting or enhanced processing. The STC HH will support single-node AOA.

Response: Comparable language added to the paragraph.

34. Performance Specification, 3.4.2.1, Scan Capability Question: Add the following to the paragraph to read, “The HH shall be able to; scan, detect, intercept and recognize SOI transmitting on frequencies from 2 to 2,000 MHz. Limited processing/evaluation of such signals shall be done locally on an Android or laptop connected to the HH. The HH shall also be able to transfer and relay these signals for further evaluation to a remote processing center. Ideally, limited processing of such signals may be done within the radio itself and displayed without being connected to an external device. The STC HH will include programmable on-board generic classifiers. For digital modulations these will include the modulation type (e.g. M-ary PSK, M-ary QAM, M-ary FSK, and so on), symbol rate, known signal (e.g. pre/mid/post ambles), and periodicity, at a minimum. Common analog modulations will also be included (e.g. AM/ FM), including the ability to automatically tune. Specification of spectral and temporal support will also be included” Response: Some of the proposed language was included but not all. Tuning range of the HH does not go below 30 MHz and thus the SOI scanning function was changed to read 30-2000 MHz.

35. Performance Specification, 3.4.2.3

Question: Modify the paragraph to read, “The HH shall, without external assistance, be able to provide radio Direction Finding (DF) of signals of interest by combining LOB information and display it to the operator. It shall take no more than one HH device receiving the same signal at appropriate different positions and times (out to a radial distance of at least 5 kilometers) to provide location of the signal within 50 meters accuracy. The range and bearing information shall be shared among the HH devices with the location information presented on the HH display.”

Response: Some of the proposed language was included but not all.

36. General Competition and Acquisition

The contractor may be forced to no-bid this STC HH solicitation due to the IPS capability and certification requirements due at the same time as the proposal (~Aug/Sep 2014).

Question: If a contractor does not win this solicitation, what future contract on-ramp alternatives will exist in USSOCOM for our upcoming STC HH offering?

Response: As stated in the RFP, all certifications are required upon the delivery of the initial production samples 12-18 months After Contract Award (ACA). After careful consideration the Government has decided to forego the IPS Demonstration as part of its Source Selection Procedures. Regardless, USSOCOM has no plans for future contract on-ramp alternatives.

37. General Competition and Acquisition

The contractor recommends that the IPS Demonstration Plan should be re-defined to ensure that it values promising new technologies and not just mature old technologies.

Question: Will USSOCOM consider an updated IPS Demonstration Plan, and Section L and M?

Response: After careful consideration the Government has decided to forego the IPS Demonstration as part of its Source Selection Procedures.

38. General Competition and Acquisition Given the complex and very high capability requirements of STC HH, the contractor recommends that USSOCOM can further improve the definition, competition, and ultimate end result of the STC HH program by providing the updated DRAFT RFP (including the 6/6/14 round of comments) back to industry for a 2nd round of review and comment (~Aug/Sep).

Question: Will USSOCOM consider a 2nd round of DRAFT RFP re-review and comments?

Response: The Government is not considering a 2nd round of Draft RPF review and comment.

39. General Competition and Acquisition The full STC capability consists of 5 different devices, of which the STC HH is one. At least 2 of the other STC device markets are currently more competitive and more technologically mature than the STC HH.

STC Individual Radio

· Production ready competitive offerings exist from at least 4 contractors: Thales, General Dynamics, Harris, and Exelis.

STC Manpack Radio

· Production ready competitive offerings exist from at least 3 contractors: General Dynamics, Harris, and Rockwell Collins.

The contractor recommends that USSOCOM would achieve significant competitive and technical benefits if the STC Manpack solicitation was executed prior to STC HH.

Question: Will USSOCOM consider this recommendation?

Response: The Government does not believe that there is adequate competition to support a manpack solicitation at this time. Given a revised contract award, circa January 2015 and with the time to deliver first production articles 12-18 months ACA (that would likely be in the third quarter of FY 16), SOCOM believes that the baseline HH requirements are achievable within that time frame.

40. Product Definition and Maturity The contractor recommends that a truly leap ahead STC HH must make the necessary investments to mature its technology and leverage industry progress in 2 critical areas.

1. Lessons learned from the first multi-channel devices being fielded today.

2. A high performance, highly integrated, and very SWaP efficient core engine.

The very small package of the STC HH requires a revolutionary core engine to make it successful. The STC Manpack market is more mature and competitive because the additional size and space of a manpack makes some of the technical challenges easier to solve and bring maturely to market. The contractor believes that if the STC HH is rushed to production, before the underlying foundation of lessons learned and core engine are ready, then the STC HH will not achieve the operational objectives envisioned by USSOCOM and SOF users.

Question: Would USSOCOM consider “stepping back” with industry and entering into a collaborative IPT like effort to further the definition and maturity of STC HH prior to proceeding with this solicitation?

Response: No.

41. Product Definition and Maturity

The IPT/Collaborative effort suggested in Question 40 would establish a formal USSCCOM led industry collaboration to prepare the STC HH for technical maturity and operational success.

Question: Alternatively, would USSOCOM consider modifying this solicitation to allow multiple contract awards for the P3I period?

Response: The Government does not plan on multiple contract awards but has not ruled out the possibility.

42. Reference Draft Solicitation Question: Does USSOCOM intend to foster ongoing competition and innovation in the STC HH market? Or does USSOCOM intend to create a 5-year sole source provider?

Response: The acquisition strategy is based on full and open competition, accentuated by allowing 12 – 18 months to deliver the initial production radio.

43. Reference Draft RFP

Question: The date ranges don’t match the date ranges shown on page 2 (above).

Year 1, Oct 2016 - Sep 2017:

Year 2, Oct 2017 - Sep 2018:

Year 3, Oct 2018 - Sep 2019:

Year 4, Oct 2019 - Sep 2020:

Year 5, Oct 2020 - Sep 2021:

Are the differences intentional? Or is there a clarification/correction required? See CLIN 0007 thru 0011 Response: The differences were not intentional as it was a typo is corrected as reflected below:

Year 1 pricing –2015 to 2016

Year 2 pricing –2016 to 2017

Year 3 pricing - 2017 to 2018

Year 4 pricing –2018 to 2019

Year 5 pricing –2019 to 2020

44. Reference Section M - M.1.6 FACTOR 3 –Price The respondent believes that its software upgrade website has been valuable to USSOCOM and SOF users.

Question: Can the respondent be provided a copy of the approved Source Selection Plan for its review prior to RFP release?

If yes, does USSOCOM have an anticipated date when the approved Source Selection Plan could be provided for review?

Response: Per the Federal Acquisition Regulation (FAR) Source Selection Plans are Competition Sensitive and as such is not releasable. However, Sections L & M (found in the RFP and part of the Source Selection Plan) provide the evaluation criteria and basis of award which is all that is needed for potential offerors to submit proposals.

45. Reference Specifications, Table 1 - STC Waveforms and Appendix A The respondent is not currently planning to implement BOWMAN VHF in the STC HH.

Question: Can SOCOM provide information on the use case and RFP evaluation significance of BOWMAN VHF?

Response: BOWMAN VHF is an Objective capability in the CPD but is not being specifically evaluated per Section L of the RFP. If an offeror proposes BOWMAN (along with cost and schedule) then it may be favorably considered.

46. Performance Specification, Table 1 - STC Waveforms and Appendix A The respondent is not currently planning to implement TCM in the STC HH.

Question: Can SOCOM provide information on the use case and RFP evaluation significance of TCM?

Response: Deleted from Table as an Objective.

47. Performance Specification, Table 1 - STC Waveforms Question: Did USSOCOM intend to reference SADL (not just EPLRS)?

Response: No. Deleted EPLRS from the Table as an Objective.

48. Performance Specification, 4.2.6.1 - Device Weight (Including Battery Box) Request clarification on the fixed mount set.

Question: Why are 2 batteries needed?

What type of batteries?

What type of mounting tray?

Is an RF power amplifier included in the system weight?

Response: This was in error, only one rechargeable battery is required. The type of mounting tray should be proposed by the offeror. If existing mounting trays can accommodate the STC HH FMS configuration that would be likely be favorably considered. Yes, the HPA/LNA is to be included in the system weight.

49. Performance Specification, Table 1 - STC Waveforms and Appendix A Question: Can SOCOM provide information on the use case and RFP evaluation significance of TCM?

Response: Deleted from Table as an Objective.

50. Performance Specification, Cross-banding STC HH is requiring many new capabilities and mission modules because of the growth in requirements by SOF combating near peer adversaries, and because of the proliferation of many new and emerging technologies. The STC HH must be able to cross band and securely link these new technologies and/or “IP clouds”. This includes the ability to address NSA Type 1 security requirements while cross-banding.

Question: Is cross-banding a STC HH requirement?

Response: Cross-banding will be specifically addressed as a requirement in the Performance Specification.

51. Performance Specification, Table 1 - STC Waveforms, 3.5.3, 3.8.4.3 and Appendix A Since MUOS will replace and improve upon those capabilities as the new DoD SATCOM baseline during the fielding period of the STC HH, MUOS should be required as a (T) threshold, and furthermore it should be implemented in the STC HH primary radio “core”.

Question: Will MUOS be made a threshold waveform?

Response: There is no certainty that the MUOS waveform can be implemented in a two channel HH and maintain SWaP at the same time. Requirement is for a P3I that will not impact performance and schedule of baseline STC HH.

52. Performance Specification, Integrated STC HH, 3.4.5 In order to increase SOF Operator flexibility and lower SWaP, the RFP should permit best value consideration for a tightly integrated HH that included all 3 functions (legacy, MANET, ISR) fully embedded in the HH (~38 in3), without the need for bulky external modules. The fully integrated STC HH would be able to: 1) Perform all 3 functions (legacy, MANET, ISR), 2) Perform 2 simultaneously, and 3) Crossband the ISR onto a MANET with NSA certified Type 1 encryption.

Question: The respondent recommends that capabilities integrated internal to the STC HH are preferred due to size, weight, power, ease of use, and integration (cross-banding and NSA Type 1 encryption) benefits.

Response: The Government changed the language accordingly.

53. Performance Specification, 1.3 - Threat Question: The respondent asks for copies of the threat documents cited in the paragraph.

Response: The documents that are considered germane to proposal submission will be provided to respondents to the final RFP provided the offeror possess the appropriate facility clearances and need-to-know.

54. Performance Specification, 2.1.3 – DOD Reference Documents

Question: The respondent suggests referencing STANAG 4372 for the SATURN waveform.

Response: The paragraph is changed accordingly.

55. Performance Specification, 2.1.4 – Other Government Documents, Drawings and Publications

Question: The respondent suggests requiring SCA Version 2.2.2 rather than Version 4.0. since the latter is not backward compatible with version 2.2.2. The respondent also proposes adding several support MUOS documents to the section including:

70-P50230E , ICD – MUOS to Common Air Interface (CAI)

99-P50267E ,MUOS Message Sequence Diagrams for Control Signaling 1,3

62-P58381P, MUOS Waveform Specification 1,4

62-P58383P, MUOS Specific Terminal Services 1,5

62-P58382P, MUOS Functional Terminal Specification 1,6

62-P54168T , Waveform Design Specification (WDS) for the MUOS CAI WFv31

Response: The Government will investigate the availability of version 4.1 that is backward compatible with version 2.2.2. However, since the RFP provides 12 months ARO before the IPS is to be delivered to the Government it is not evident why the latest SCA version 4.1 should not be required. Regarding the proposed MUOS standards, upon verification, they will be added to the Performance Specification.

56. Performance Specification, 3.1.1 HH System Components, Exhibit A, Sections L&M Presently, the accessories listed in Exhibit A and in the System Descriptions include lists of multiple limited bandwidth antennas.

Question: The respondent requests that it be allowed to offer fewer antennas, but wider bandwidth capability and to address the 0 dBi antenna gain requirement.

Response: The issue with broadband antennas is the performance of same. In this regard, bandwidth specific antennas usually provide better gain than does broadband antennas all of which equates to power output needed to meet range requirements that impacts battery life. If an offeror can provide fewer antennas and meet the threshold range requirements with minimal power output then the Government is willing to entertain such a proposal. However, until it is proven that the multiband antennas meet the gain requirement the Government will still require band specific antennas. The Government prefers the fewer the number of antennas. Regarding the 0 dBi antenna gain, the Government will change the requirement to “as good as possible.” However, antenna performance (gain) and power output that is needed to meet threshold communications range requirements will be measured during Contactor/Government conducted DT

57. Performance Specification, 3.1.2 – Universal Accessories As written, “Universal” could imply applicability to all future TBD STC device form factors.

Question: Are the “Universal” accessories applicable to just the STC HH?

Response: Yes. The word “Universal” will be deleted to avoid further confusion.

58. Performance Specification, 3.2.3 – Android Interface The tasks in 3.2.2.1 through 3.2.3.8 shall be performed through a combination of Android functions and STC HH functions but require the STC HH, the Android computing device, and an applicable Android Application.

Question: Are Android applications required?

Response: Not necessarily. The term Android was replaced with the term “End User Device (EUD).”

59. Performance Specification, 3.3.1.2 – Channel Types The broad statement of “any combination”, “without any performance degradation or co-site interference” is not realistically achievable.

Question: What frequency separation is permitted in order to facilitate this performance?

Response: The Government recognizes there may be co-site issues with simultaneous operation of both wideband and narrowband channels especially if operating in the same frequency band (e.g., 225-400 MHz). Thus it is expected that the offeror will provide frequency planning/guidance with respect to the potential co-site interference of its material solution.

60. Performance Specification, 3.4 and 3.4.2.3 – Multifunctional Capabilities

The respondent recommends that if USSOCOM desires LOB from STC HH, then provisions must be permitted for a specialized antenna.

Question: Will a specialized antenna be added to Exhibit A?

Response: A special antenna array will be added to the ancillary items as well as comparable language describing the special purpose antenna.

61. Performance Specification, 3.4, 3.4.2.1 and 3.4.2.3 – Multifunctional Capabilities

This paragraph states “rudimentary” capabilities. But 3.4.2 SBTW/SA states very advanced specific requirements (ie. 2 to 2000MHz coverage and 50m accuracy at 5km range).

Question: Since the detailed requirements in 3.4.2 exceed the performance of the most advanced JTWS dismount dedicated SIGINT systems will the requirement be adjusted accordingly?

Response: The frequency range will be changed from “2 - 2000 MHz” to “30 – 2000 MHz” which is consistent with the tuning range of the HH. The Government believes the accuracy is reasonable.

62. Performance Specification, 3.4.1.2 and 3.4.3 - ISR Video Receive Capability / Interoperability This requirement should be more specific and testable. It should reference the testable waveform specification.

Question: Will the Government replace “ROVER” and “VORTEX” interoperability with Bandwidth Efficient – Common Data Link (BE-CDL) Waveform. Rev A, May 2011 and the Standard Common Data Link (Std-CDL) Waveform, Specification 7681990 REV H-1, Feb 2012?

Response: The Government will add the two referenced specifications as suggested but will also retain the ROVER/VOTEX requirements by citing the appropriate waveform specifications.

63. Performance Specification, 3.4.2.3, last sentence Question: Recommend that the wording in the last sentence be changed to read, “. . . information be presented on the Android or laptop connected to the HH (T) or on the HH display itself (O).” .

Response: Recommended change will be made and Android will be replace with “End User Device (EUD).”

64. Performance Specification, 1.2, 3.4.3, 3.4.4.1, 3.7.1, 3.7.2, 3.7.4.1 (Table), 3.7.5, 3.7.7.2 and Appendix A Question: The respondent recommends changing the encryption requirement to:

The reference should be to “Type 1 Suite A, NSA Approved AES.” Thus, recommend clarifying the AES standard as: The NSA approved AES standard in accordance with DoDI S-4660.04 and BE-CDL Rev A, Appendix D. Furthermore, suggests that “Suite B” refers to an NSA standard. Thus all references to “Suite B” should be specifically clarified to state “NSA Certified Type 1 Suite B”.

Response: The encryption requirement will be re-written in collaboration with NSA.

65. Performance Specification, 3.4.3 - ISR Video Receive Capability / Interoperability, Table The respondent proposed multiple changes to the Table found in this paragraph.

Question: Recommend augmenting or replacing the requirements in the table.

Response: Some of the recommended changes were adopted to include:

WiFI was deleted from the table.

The new H.265 specification was included as an Objective

“Tuning Steps” was used to further describe “Frequency Resolution”

Mesh Network was deleted from the table since the HH will provide the video dissemination

Bandwidth Efficient – Common Data Link (BE-CDL) was added

66. Performance Specification, 3.6.1.1 Question: The respondent recommends specific and testable interoperability requirements be defined (i.e., JITC interoperability for a list of waveforms).

Response: Recommended rejected since this is a Performances Specifications not at Test Plan or Design Specification. The interoperability of the STC HH shall, as a minimum, meet the established interoperability capabilities/standards, for all waveforms, of the legacy radios it is to replace.

67. Performance Specification, 3.6.1.2

In this regard, the HH shall provide a functional interface to platform host equipment not requiring changes to platform host equipment.

Question: The new STC HH, will have many more capabilities than the prior legacy HH. Thus it may require more I/O, protocols, and interface controls with the platform host in order to enable full STC HH capability in the platform.

Response: The intent is for the HH to be able to interface with existing platform components without requiring significant hardware and software modifications to the platforms. Those STC HH material solutions that require minimal modifications to existing platform components will be considered.

68. Performance Specification, 3.7.1 – General Characteristics The MANET shall be able to support a minimum of two video feeds, voice and SA over the MANET network with no limitations on numbers of nodes or hops.

Question: The respondent recommends that the term “no limitations” is theoretical and does not have practical value. It has been shown in USSOCOM’s own testing that commercial MANETs with “no limitations” will crash and fail to operate when certain mission and network topologies are encountered.

Response: The reference to “no limitations” has been removed.”

69. Performance Specification, 3.7.1 – General Characteristics

Performance in restricted propagation environments and high multipath environments shall be implemented in the MANET solution.

Question: Recommend a 3 µsec delay, the typical spread is found in outdoor hilly multipath environments, be included in the paragraph.

Response: The latency requirement is provided in the corresponding table.

70. Performance Specification, 3.7.2 and 3.7.3 Question: The respondent requests that the version and roadmap requirements for SRW and WNW, respectively be defined Response: The intent of the draft RFP/Performance Specification is for respondents to identify what they are capable of doing WRT P3I and not the Government telling them what to do especially for a NDI/COTS acquisition strategy.

71. Performance Specification, 3.7.4.1 The information contained in the following table and subsequent paragraphs represents the optimal SOF features and specifications for commercial MANET waveform.

Question: The respondent recommends that the wording be changed to read, “The information contained in the following table and subsequent paragraphs represents example features and characteristics for the commercial MANET waveform.”

Response: The recommendation is being considered but the intent was for the respondent to provide those features and characteristics of its proposed commercial MANET waveform if not the same as that presented in the paragraph.

72. Performance Specification, 3.7.4.1 Google Earth based network monitoring

Question: The respondent recommends that the Google Earth requirement is too specific given SOF desires to operate with ATAK and APAS.

Response: The requirement is revised.

73. Performance Specification, 3.7.5.2

Question: The respondent recommends that KOI-18 should not be required. It is not supported by most current devices.

Response: KOI-18 deleted from the paragraph

74. Performance Specification, 3.7.7.1

Question: Recommends clarification of the text “secure/non voice”.

Response: Correction made to read, “secure/non- secure voice and data communications system.”

75. Performance Specification, 3.7.7.6 – Internet Protocol Question: Will the Government change the wording to permit the evolution from IPV4 to IPV6?

Response: Yes, but IPv6 is a requirement that must be proposed as part of the baseline radio that will be supported within 12-18 months after contract award.

76. Performance Specification, 3.8.4.5 – Netted Iridium

Question: Recommend that Netted Iridium be identified as a threshold supported by NSA certified Type 1 encryption.

Response: Netted Iridium is a P3I and thus should be proposed by the offerors (including cost and schedule). However, the classification requirement is for SECRET and Below that may be satisfied by NSA approved Suite A or B algorithms. Again the details are in the offerors implementation as approved/certified by NSA.

77. Performance Specification, 3.10.1.1 – Voice Activation Question: Recommend that voice activated PTT (e.g., VOX) be an objective vs. a threshold requirement.

Response: Voice activation through the radio was changed to an objective requirement.

78. Performance Specification, 3.13.1.1 – Boot Time

Cold Start and Warm Start should not refer to temperature conditions.

Question: Will the Government consider eliminating the temperature criteria regarding Boot Time?

Response: Government has revised the paragraph to read, “….shall be less than 60 seconds for the narrowband channel and less than 180 seconds for the wideband channel.”

79. Performance Specification, 3.14.1.3 – Battery Power

It is very difficult and usually not accurate to attempt to measure battery life with 5 minute accuracy.

Question: Will the Government change the requirement regarding notification by the radio when only 5 minutes of battery life remain?

Response: The requirement was changed where the HH will display a warning when approximately 25% of the battery life remains in the battery.

80. Performance Specification, 4.4.1.2 - Altitude The HH shall be capable of continuous operation while in transit from an unpressurized altitude of 30,000 feet to a depth of 20 meters below sea level without any degradation in performance.

Question: Will the Government change the requirement to read, “recommend clarification. 2 meters for Urban radio and 20 meters for Maritime radio.

Response: Paragraph changed to read, “The Maritime HH shall be capable of continuous operation while in transit from an unpressurized altitude of 30,000 feet to a depth of 20 meters below sea level without any degradation in performance. The Urban HH shall be capable of continuous operation while in transit from an unpressurized altitude of 30,000 feet to sea level without any degradation in performance.”

81. Performance Specification, Table 3 – Dismounted EMI/C Test Requirements

Question: Will the Government relinquish some of the test requirements for the HH?

Response: The Government recognizes that these requirements may be hard to meet and expects that offerors will identify which requirements its proposed solution can and cannot meet. The purpose of the draft RFP is to align requirements with available solutions but at the same time not give up on requirements that have been previously established for minimizing EMI/C issues. Even so, some of the more stringent test requirements were deleted.

82. Performance Specification, Table 4 – Fixed Mount EMI/C Test Requirements

Question: Will the Government relinquish some of the test requirements for the Fixed Mount System?

Response: The Government recognizes that these requirements may be hard to meet and expects that offerors will identify which requirements its proposed solution can and cannot meet. The purpose of the draft RFP is to align requirements with available solutions but at the same time not give up on requirements that have been previously established for minimizing EMI/C issues. Even so, some of the more stringent test requirements were deleted. Besides, proposed design goals are meaningless in a competitive solicitation.

83. Performance Specification, Table 1 - Personnel-Borne ESD Environment Full compliance with 25kV specifications is extremely hard in HH form factor.

Question: Will the Government relinquish this requirement?

Response: The Government recognizes that these requirements may be hard to meet and expects that offerors will identify which requirements its proposed solution can and cannot meet. The purpose of the draft RFP is to align requirements with available solutions but at the same time not give up on requirements that have been previously established for minimizing ESD issues. Besides, proposed design goals are meaningless in a competitive solicitation.

84. Performance Specification, 6.1.2.8

The Mean Time to Repair (MTTR) shall not exceed 15 minutes at unit level and 1 hour at direct support.

Question: Is it correct to interpret the 15 minute unit level requirement to apply to the entire STC HH as an LRU.

Response: The paragraph was changed to read, “The Mean Time to Repair (MTTR) shall not exceed 15 minutes at organizational maintenance level. The LRUs at the organizational maintenance level include antennas, cables, knobs, mission modules and batteries.” The reference to direct support was deleted.

85. Performance Specification, 3.8.4.1 Question: Paragraph numbering and MIL-STD references appear in error

Response: Corrections to numbering and MIL-STD-130N were made.

86. Performance Specification, Appendix A - STC / Legacy Waveform Interoperability ASCM encryption

Question: The table includes VINSON as a requirement for ASCM, is this correct?

Response: VINSON was removed and replaced with MELP.

87. Performance Specification, Appendix A – LPI/LPD/LPE, Frequency Range

Question: Is the frequency range presented in the table correct?

Response: The frequency range of “1.6 to 30 MHz” was deleted and the range of “30 MHz to 2 GHz” was changed to the Objective.

88. Reference Draft RFP – Periods of Performance

Question: Why are the pricing time frames on page 2 of 69 for CLINs 0001 through 0006 different than the pricing time frames for CLINs 0007 through 0011 listed on pages 6 through 9.

Response: See correction below:

Year 1 pricing –2015 to 2016

Year 2 pricing –2016 to 2017

Year 3 pricing - 2017 to 2018

Year 4 pricing –2018 to 2019

Year 5 pricing –2019 to 2020

89. Reference Draft RFP – Section J Section B CLINS

Question: In CLIN 0002 there is a typo – should say urban instead of maritime.

Response: Change made accordingly

90. Reference Draft RFP – Section J

Section Exhibit D: P3I; Otherwise it is unclear as to how to allocate the NRE over the years 1-5.

Question: For the P3I pricing, should it be assumed that award of the NRE will occur upon award of the IDIQ?

Response: No. As explained in the RFP the Government wants the flexibility to decide when to implement a P3I based availability of funds and need. So offerors are to propose the total NRE for each P3I in each year (1 thru 5) and the year in which the Government elects to implement the P3I that year will be the total NRE cost. Recurring costs should be proposed for each year as well.

91. Reference Draft RFP – Section L – L.2.1.1 Question: Will the CRM count against the 75 page limit for the technical volume?

Response: No

92. Reference Draft RFP – Section L – L.2.1.2 Question: Are all five of the cited P3I topics required to be addressed within the 75 page limit for the technical volume?

Response: The Government will allow five additional pages for each P3I proposed in addition to the 75 page limit. If five pages are not used for each P3I proposed the unused pages cannot be applied to the 75 page limit.

93. Reference Draft RFP – Section M – M.1.4.1 Sub-factor 1: Transceiver Performance Question: How and/or will the objective requirements and P3I proposals influence/ factor into the overall technical performance ratings.

Response: Not all objectives are identified as P3Is, thus if not a P3I then it is not evaluated but an objective that is not a P3I would be given credit if it were proposed (including cost and schedule). The P3Is proposed may positively influence the overall technical ratings.

94. Reference Draft RFP – Section M – M.1.6 FACTOR 3 –Price

Question: Will the Source Selection Plan be made available to potential offerers before release of the RFP?

If yes, what will be the vehicle for obtaining a copy?

If not what is the vehicle for providing the best estimate of quantities.

Response: Per the Federal Acquisition Regulation (FAR) Source Selection Plans are Competition Sensitive and as such is not releasable. However, Sections L & M (found in the RFP and part of the Source Selection Plan) provide the evaluation criteria and basis of award which is all that is needed for potential offerors’ to submit proposals.

95. Reference Draft RFP – Section M – M.1.6 FACTOR 3 –Price

Question: Does this mean that price will not be used as a factor for selecting who is awarded the contract? What happens if the vendors score equally on factors 1 and 2?

Response: No. The proposed price is used as part of the tradeoff process. The price doesn’t receive a “score” or “color”

96. Performance Specification, 3.4.3, ISR Video Receive Capability / Interoperability - Table Question: How is this related to Data Rate requirement of 10.71 Mbps? Recommend deleting 400-470 MHz since it is not located in the L, S, C and Ku bands as cited in the table.

Response: The 10.71 Mbps is not related and the 400-470 MHz requirement was removed from the table.

97. Performance Specification, 3.8 - Waveform Requirements, Section 3.8.1.5 When configured for two channel operation the HH shall have the capability of automatic protocol conversion within like modes and between frequency bands or waveforms for which it is configured

Question: Please provide clarification Response: The paragraph was deleted.

98. Performance Specification, 3.8 - Waveform Requirements, Section 3.8.2.2 The two channel capability shall provide reroute signals when waveform capabilities are changed, for example, when switching from SRW to another MANET waveform As an Objective (O) the HH will be configurable for RF switching capabilities to perform automatic retransmission, cross-banding and routing operations between channels in both secure and non-secure modes.

Question: Please provide clarification Response: The paragraph was reworded.

99. Performance Specification, 3.3.1.1 and 3.9.1.1 Question: Will the Government accept an external SAASM receiver?

Response: No the requirement is for an embedded SAASM or M-Code or comparable receiver.

100. Performance Specification, 1.10.1 – Voice Activation

Question: Recommend that voice activated PTT (e.g., VOX) be an objective vs. a threshold requirement.

Response: Voice activation through the radio was changed to an objective requirement.

101. Performance Specification, 3.1.1 HH System Components, Exhibit A, Sections L&M

Typical antenna performance of handheld radios is not 0 dBi.

Question: The respondent proposes negative gain performance for the band specific antennas.

Response: Regarding the 0 dBi antenna gain, the Government will change the requirement to “as good as possible.” However, antenna performance (gain) and power output that are needed to meet threshold communications range requirements will be measured during Contactor/Government conducted DT

102. Performance Specification, 3.2.1 – Software Communications Architecture (SCA) Question: Respondent recommends the requirement be restated to specify that platforms hosting multiple waveforms must be compliant to SCA version 2.2 or above and further recommends that the reference to SCA version 4.1 for wideband waveforms, e.g., SRW be deleted.

Response: Paragraph changed accordingly.

103.…