Offnet RFI.pdf
PDF 476 KB Posted
- Attached to
- Next Generation Off-Network Communications
- Solicitation number
- 1333P221Q00000006
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Offnet QA.pdf | ||
| Offnet RFI.pdf |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Request for Information for
Next Generation Off‐Network
Communications
August 11, 2021 Rev 1.8
Next Generation Off-Network Communications
I. PURPOSE
This request for information (“RFI”) seeks input from interested parties aware of, investigating, or pursuing research into off‐network communication solutions that may meet the unique challenges and operational requirements of public safety workers. By off‐network, we mean solutions that enable devices that cannot “reach” the supporting network equipment such as towers or base stations to provide reliable communications or solutions that enable devices within coverage that can be configured to communicate without support of the network. In addition to understanding Land Mobile
Radio (LMR) and “LMR‐like” off‐network capabilities, we seek information on emerging technologies that are expected to take advantage, whether directly or indirectly, of broadband capabilities and to include video, location, and the potential for other situational awareness information.
Responses to this RFI will be used by the First Responder Network Authority (“FirstNet Authority” or the
“Authority”) to better understand respondents' current and future capabilities, develop awareness of emerging technologies and potential long‐term solutions, evaluate best procurement approach(es), and determine how to best leverage existing and emerging capabilities and best practices to meet public safety needs. The objective is to identify potential solutions, that take advantage of emerging technologies, and accelerate the development of next generation off‐network technologies in support of public safety’s future operational needs.
Understanding emerging technologies that may be applicable to first responder communications, especially where the “Macro Network” is not reachable or not functioning as planned, is paramount to the Authority’s mission of prudent and effective reinvestment into the network.
II. BACKGROUND
In February 2012, Congress enacted the Middle‐Class Tax Relief and Job Creation Act of 2012 (the “Act”), containing landmark provisions to create an interoperable, nationwide public safety broadband network
(“NPSBN”) for law enforcement, firefighters, emergency medical service professionals and other public safety entities. The Act outlined a governing framework for the deployment and operation of this network based on single, nationwide network architecture. The NPSBN has been operational since 2018 and the Authority has begun reinvesting into the network, as required by the Act.
Currently, the 3rd Generation Partnership Project (3GPP) has developed standards for off‐network for
4G and are currently developing standards for 5G. Parallel efforts in 3GPP Vehicle to Everything (V2X) may drive potential standards for off‐network capabilities such as vehicle to pedestrian (V2P) or pedestrian to pedestrian (P2P).
The FirstNet Authority has participated in the 3GPP standards efforts to develop an off‐network communication capability using 5G New Radio (NR) side link for mission critical services.
III. PREVIOUS RFIs, VENDOR ENGAGEMENT, AND MARKET RESEARCH
This RFI will inform engagements with industry, academia, and other federal agencies, opportunities for ongoing market research, and will provide the Authority a means of monitoring potentially beneficial technologies as they emerge.
IV. INFORMATION REQUESTED
The Authority is interested in any ongoing or planned efforts to mature current and/or emerging technologies that may contribute to a next generation public safety off‐network solution. Such technology or solutions are of interest to the Authority especially where the NPSBN does not provide
Macro Network coverage, e.g., wilderness areas, or where the macro network is not performing as designed, e.g., network outages, backhaul outages, catastrophic failures.
Technologies and/or solutions may be standards based, or non‐standards based and may utilize current and/or future technologies as solutions for the next generation of direct mode operation.
The Authority is interested in any work that your organization has ongoing pertinent to off‐network technologies and/or solutions for first responders and may include applied research as it pertains to future product development possibilities; new product design, development and test; prototype work;
and/or pilots and demonstrations of potential solutions.
The FirstNet Authority expects future functional & operational requirements to be similar to those stated in Section V. However, it is well‐recognized that this is based primarily on current LMR direct‐ mode paradigm and that new technologies may emerge with new and improved operating scenarios.
Respondents should not be constrained by perceived or assumed “requirements” nor should respondents be constrained by preconceived ideas of what off‐network functionality is today. The authority is interested in technologies and solutions of virtually any Technology Readiness Level (TRL) as defined in APPENDIX C – Technology Readiness Level Definitions.
For reference, a glossary of terms are included in ; two use‐cases, for consideration, are included in
APPENDIX B – Use Cases.
V. Functional & Operational Scenarios
1. Device to Device: Two or more user devices (UEs) communicating without the need for any
Macro Network or additional equipment. This mode should function whether any number of devices is within the coverage of the macro network and should permit the users to determine whether to use this mode or the macro network where it exists.
2. Device Relay: Three or more devices functioning such that if device A cannot directly reach device C, but a device B can reach A and C, all devices can communicate with one another through any reachable device. This type of relay topology is often referred to as a “mesh network”.
3. Network Relay: Two or more devices functioning such that if device A can reach the Macro
Network and device B cannot reach the Macro Network, device A will provide a relay such that device B is fully functional with no awareness that device A is assisting in the network connection.
4. Data Services: support for sharing pictures, video, telemetry including location, sensor data or
Internet of Things (IoT) data to other devices without Macro Network coverage.
VI. Detailed Questions:
Respondents are to use the following questions as a guide to their response and comment/answer as many as are appropriate to the scope of their organization’s expertise.
1. Please describe your proposed technology and/or solution and directly address each of the scenarios described in Section V.
2. What is the Technical Readiness Level (TRL) of the components of your technology/solution using the definitions in APPENDIX C – Technology Readiness Level Definitions.
3. Can users choose to employ your off‐network solution regardless of their Macro Network coverage?
4. What is the anticipated transmit power, receive power, and associated link budget/margin for various ranges and various sets of obstruction e.g., buildings, foliage, indoor, etc.?
5. Which frequency bands are utilized and how is interference with cellular macro coverage managed?
6. For relays included in your solution, please discuss:
a. How public safety operationalizes the use of relays.
b. Additional latency or other performance challenges.
c. Whether the relays are part of the handheld or body worn equipment or are separate devices.
7. What international or national standards are followed if any?
8. Describe how your solution securely identifies nearby devices for use in any relay activity as well as communication with other users.
9. Is your solution capable of integration to current or future Mission Critical Services defined by
3GPP? If so, please explain details and user experience expectations.
10. Are devices other than standard “smartphones” required?
11. What form factor does your solution employ, e.g., specialized device, accessory or add‐on to commercial cell phone, separate device paired with smartphone or radio, etc.?
12. Are there unique operational considerations of your solution including UI, how worn on body, health & safety, e.g., SAR requirements, etc.?
13. Are “talk‐group” communications possible when off‐network?
14. Are there unique or extensive cost considerations?
15. Is there, or do you anticipate, a robust supply chain for the components of your solution?
16. Is there an expectation regarding intellectual property rights (IPR), licensing considerations or other financial considerations for use of your technology and/or solutions or any of its components?
VII. GUIDANCE FOR RESPONDING TO THE RFI
In accordance with FAR 15.201(e), responses to this RFI are not offers and cannot be accepted by the
Government for the basis of forming a binding contract. This RFI is being issued solely for the purpose of gathering information for planning purposes. The FirstNet Authority does not intend to create any public reports from any material collected in response to this RFI including, but not limited to, the names of respondent organizations. It does not constitute an RFP or a promise to issue an RFP in the future. This RFI does not commit the Government to a contract for any supply or service whatsoever.
Furthermore, the Government is not at this time seeking proposals and will not accept unsolicited proposals. Respondents are advised that the Government will not reimburse interested parties or any other organizations 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 parties’ expense. Any information submitted to the government in response to the RFI will not be returned to the respondent.
Interested parties of all sizes are encouraged to respond to this RFI. If the scope of this RFI is too large or there are aspects to which a respondent does not wish to provide a response, feedback limited to the areas of specific expertise is requested. The FirstNet Authority hopes to receive information from all interested parties on any aspects of this RFI that could be of benefit to the Government or its user communities.
When responding to this RFI, clearly label all proprietary information and any other limitations on disclosure. Please limit your specific narrative response to 15 pages inclusive of attachments, Calibri or
Corbel 12‐point font, single‐spaced, single‐sided pages with 1‐inch margins.
Questions regarding the RFI shall be submitted directly to the Contracting Officer, Kimberly Luke, at
Kimberly.Luke@firstnet.gov. Please be advised that the Government reserves the right to transmit those questions and answers of a common interest to all interested parties via sam.gov. Question should be submitted by 2pm eastern on September 1, 2021. All responses to this RFI shall be submitted on or before 2pm eastern September 30, 2021.
The group reviewing the responses may seek further clarification from respondents. This clarification may be requested in the form of brief oral communication by telephone, written communication, or electronic communication. In addition, RFI respondents may be invited to present their responses to the reviewing group. The purpose of this presentation would be to seek clarification of information contained within the response. These exchanges are viewed as a component of information gathering and do not constitute discussions.
It is not the intent of the FirstNet Authority to publicly disclose vendor proprietary information obtained during this market research effort. To the fullest extent consistent with the FirstNet Authority’s legal obligations, information identified by a respondent as “Proprietary or Confidential” will be kept confidential.1 Information submitted by interested parties in response to this RFI, including information marked as limited rights data, as restricted computer software, as being subject to limited rights, and/or as being subject to restricted rights, will be shared by the Government with current and future support contractors hired to assist the FirstNet Authority. The FirstNet Authority’s support contractors that have been, or that will be hired, are required to sign non‐disclosure agreements restricting them from unauthorized use and disclosure of information that may be proprietary to third party companies. By submitting information in response to this RFI, vendors are agreeing to voluntarily allow the
Government to share the information they submit with the FirstNet Authority’s support contractors who are, or will be, covered by a non‐disclosure agreement.
1 Note that FirstNet Authority is not subject to the requirements of the Freedom of Information Act.
APPENDIX A ‐ Glossary
When responding to this RFI, please refer to the glossary of terms below to ensure consistent use of relevant terms.
Device‐to‐Device (D2D) – a feature requirement where two or more devices can communicate with one another directly with no intervening equipment required. Repeaters or relays may be used to extend the range among devices.
Emerging Technologies – general term applied to the lower levels on the Technology Readiness Level
(TRL) scale described in APPENDIX C. For purposes of this RFI, the FirstNet Authority views TRL levels 3 through 7 as “emerging.
LMR – Land‐mobile radio. The radio technology, generally, in use today for public safety agencies, often characterized as conventional, trunking, P25, TETRA, DMR, etc.
Macro Network – Refers to the overall physical network infrastructure that supports communications.
In the case of LMR it is the towers and other equipment typically owned by a local entity and in the case of a cellular network, it is the towers, base stations, cables, and other physical facilities that provide communications.
Off Network – a descriptive term for devices that cannot “reach” the supporting network equipment such as towers or base stations to provide reliable communications OR when devices are within coverage but have been set (manually) to a mode that allows them to communicate without support of the network. Often done for operational reasons.
Out of Coverage – supporting network is not available whether due to outages, distance, interference, or other reason.
Repeater or relay – a feature that adds range to for off network communications. The feature may be physically distinct from handheld or body worn UE or this functionality may be incorporated into a handheld or body worn UE.
Talk Around or Simplex Mode – LMR terms for D2D communications. See above.
APPENDIX B – Use Cases
While there are many potential use‐cases for off network communications, two use cases are outlined below for consideration. Responses may, or may not, include detail of how your technology and/or solutions will operate in the use cases presented.
Scenario A: Search and rescue
A hiker is lost in the Betasso Preserve, west of Boulder, Colorado.
The terrain is rugged foothills that are mixed open and forested areas. The normal trail area covers a 1‐mile x 4‐mile area. A command post for search and rescue of the lost hiker is setup at the trailhead. There is no cellular coverage in the area and no power facilities. Station 2 is in command of the search and rescue effort and there are 10 responders and volunteers participating. Operationally, users must be able to communicate with voice, data, and may make use of additional third‐party applications.
Scenario B: High rise fire
A 3‐alarm fire has broken out at in a high rise in downtown Metropolis.
The building is 16 stories of rebar‐reinforced concrete. There are 3 stories of underground parking garage below the building. Three command posts are staged around the exterior of the building at street level. There are 76 total responding units that will communicate on 3 different talkgroups. A broadcast group can be used from any command post to talk to all responders. All users will communicate on their respective talkgroup with the ability of voice, video, data, and location sharing. Along with the above, telemetry from all users will be collected at the respective command posts (e.g., user state of health and oxygen supply). Further robots inside and drones outside are deployed that will provide real time streaming video, IR and other situational awareness sensors. This information will be collected at the command posts and automatically result in real time actionable information that is transmitted to the firefighters heads up displays and will display, minimally, building layouts, location of people that need to be evacuated, other responders and hot spots that firefighters should focus their efforts on. Due to the fire all power within the building has been shut down on arrival of responders. Network coverage is available at the command posts and near the windows at floor 4 and above. Network coverage in elevators, the core of the building, and below floor 4 including subterranean levels is not available.
APPENDIX C – Technology Readiness Level Definitions
Technology Readiness Levels, as defined by the Department of Defense (DoD) (Source: DoD (2010), Defense Acquisition Guidebook; see also U.S. Government Accountability Office Technology Readiness
Assessment Guide, GAO‐20‐48G (Jan. 2020).
Technology Readiness Level Description
1. Basic principles observed and reported Lowest level of technology readiness. Scientific research begins to be translated into applied research and development. Examples might include paper studies of a technology's basic properties.
2. Technology concept and/or application formulated. Invention begins.
Once basic principles are observed, practical applications can be invented. Applications are speculative and there may be no proof or detailed analysis to support the assumptions.
Examples are limited to analytic studies.
3. Analytical and experimental critical function and/or characteristic proof of concept.
Active research and development is initiated. This includes analytical studies and laboratory studies to physically validate analytical predictions of separate elements of the technology. Examples include components that are not yet integrated or representative.
4. Component and/or breadboard validation in laboratory environment
Basic technological components are integrated to establish that they will work together. This is relatively "low fidelity" compared to the eventual system. Examples include integration of "ad hoc" hardware in the laboratory.
5. Component and/or breadboard validation in relevant environment.
Fidelity of breadboard technology increases significantly. The basic technological components are integrated with reasonably realistic supporting elements so it can be tested in a simulated environment. Examples include "high fidelity" laboratory integration of components.
6. System/subsystem model or prototype demonstration in a relevant environment.
Representative model or prototype system, which is well beyond that of TRL 5, is tested in a relevant environment. Represents a major step up in a technology's demonstrated readiness.
Examples include testing a prototype in a high‐ fidelity laboratory environment or in simulated operational environment.
7. System prototype demonstration in an operational environment.
Prototype near, or at, planned operational system. Represents a major step up from TRL 6, requiring demonstration of an actual system prototype in an operational environment such as an aircraft, vehicle, or space. Examples include testing the prototype in a test bed aircraft.
8. Actual system completed and qualified through test and demonstration.
Technology has been proven to work in its final form and under expected conditions. In almost all cases, this TRL represents the end of true system development. Examples include developmental test and evaluation of the system in its intended weapon system to determine if it meets design specifications.
9. Actual system proven through successful mission operations.
Actual application of the technology in its final form and under mission conditions, such as those encountered in operational test and evaluation.
Examples include using the system under operational mission conditions.
File details come from the government source that posted it. Updated .