PMMC-TMD-05012025- Chat.docx

Program Executive Office Command Control Communications and Network (PEO C3N) Project Manager Mission Command (PM MC)

Request for Information (RFI) for Chat Capability Purpose:

This Request for Information (RFI) is issued by Project Manager Mission Command to gather industry feedback regarding chat communication solutions that can operate effectively across mounted, dismounted, and command post environments. The objective is to identify technologies that provide seamless, secure, scalable, and reliable communication to support mission command and enhance operational effectiveness in diverse operational settings. This RFI aims to gather insights into existing capabilities, potential innovations, and best practices that can inform future procurement decisions. Responses will assist in understanding market offerings and shaping requirements for a comprehensive solution that meets the Army’s needs.

The Government requests interested sources provide information in the form of a white paper. The white paper should not exceed 10 pages, not including the cover. The whitepaper must demonstrate recent experience (within the last three (3) years) and capabilities in providing the requirements described in this RFI.

Intent:

This RFI is for information purposes only and does not constitute an invitation for Bid, Request for Task Execution Plan, Request for Quotation, or Request for Proposal. There is no obligation on the part of the Government to acquire any products or services described in this RFI or its responses. Responses will be treated only as information and market research for the Government to consider. The Government will not pay for information submitted in response to this RFI. Interested parties are responsible for marking proprietary, restricted, or competition-sensitive information contained in their response.

Requirement Overview:

Project Manager Mission Command is seeking a chat platform that includes the standard functionalities typically expected of chat solutions. Project Manager Mission Command is seeking chat capability that includes standard functionalities typically expected of a chat/text solution. The solution should be deployable via microservices and offer an easy-to-use automated deployment process.

The Chat solution should provide the following capabilities:

· Ecosystem Scalability: Solution provides capability for devices used in dismounted (e.g. Nett Warrior), mounted (e.g. MMC), and command post (e.g. MCIS) environments.

· Extensible: Solution provides an API that enables integration with existing Army C2 applications (e.g. TAK, CPCE).

· Data Security: Ensure data protection and privacy through role-based access controls (RBAC).

· Backend Infrastructure Agnostic: Operate efficiently across Commercial Cloud Service Provider, Bare metal (On-premises Server/Client Hardware), or Hybrid environments, including disconnected, degraded, intermittent, and limited (D-DIL) scenarios while providing seamless functionality on various platforms and compatibility with existing infrastructure.

· Peer Resilience: The solution should support peer-to-peer communication to maintain messaging functionality in the absence of backend server connectivity.

· Presence Awareness: The solution should provide online presence indicators (e.g., available, busy, offline) that function reliably in D-DIL environments, using available network information to reflect user status as accurately and timely as possible.

· User-Friendly Interface: Client side of the solution should provide an intuitive interface for ease of use by non-technical users.

Detailed Requirements:

Client Requirements User interface/User Experience (UI/UX) Ability to modify the UI/UX to achieve and maintain a desired/common look and feel across clients.

Functionality can be integrated with other C2 functions UI/UX and data, including authentication (e.g. identity), net SA/management, COP, file management, etc. “Plug-in” capability.

Common UI/UX across devices and platforms Cross-platform support (Windows, Linux, Android) Session Management

· Solution provides common identities across platforms for identifying user sand groups to each other. Capability should provide defining mission specific role identities (e.g. call sign, other alias) to include Non-Person Entity (NPE) support.

· User is provided with an authentication capability that establishes and can securely end a login session to the chat capability, supports discoverability by other users (i.e. presence awareness), and supports ability to create/join/authenticate chat sessions with other users and/or groups.

· Authenticated users can be discovered by other users, as well as search and find users and groups to support initiating or joining chat sessions.

· Authenticated users can see the availability status of other users.

Messaging Functionality

· One to One Messaging between authenticated users.

· One to Group Messaging capability in addition to a persistent chat room or channel.

· The solution should support receipt/read acknowledgements.

· The solution should provide online presence indicators (e.g., available, busy, offline) Persistent chat rooms/channels with join/leave sync.

Data Handling

· Clients shall securely cache message history for offline access with encryption-at-rest.

Server Requirements Infrastructure Compatibility Operates on cloud, bare metal, on-prem, or hybrid.

Scalability & Availability Horizontal scaling support.

High availability and failover capabilities.

Data Management

· The server maintains detailed tamper-evident logs of message and user activity.

· Solution provide interfacing to data archive and retrieval services that enable near-term access by analytics (e.g. AAR) and long -term archiving or future data access needs (7-10 years).

Security Role-based access controls (RBAC) as described below:

· Assign roles

· Configure federation and Cross Domain Solution settings

· Access audit logs

· Monitor network health

· Restart services

· View presence diagnostics

· Assign moderator roles

· Access all message histories (read-only)

· File attachment uploads

· Presence display

· Session initiation and termination

· Attach metadata or alerts

· Read-only access to assigned channels

Protocol & Interoperability Requirements Protocol Standards The solution uses open documented communication protocols (e.g. XMPP, Matrix, or custom protocol with public spec).

The protocol shall support optional end-to-end encryption using NSA Suit B or CNSA-compliant algorithms.

The protocol stack shall support fallback mechanisms for operation in DDIL environments (e.g. switch to store-and-forward).

Data Format & Mediation Chat messages should be encoded and formatted to agreed standards that enable automated mediation into and out of other message formations and system API interfaces, to include Cross Domain Solution (CDS) interfaces. Standardized chat formats (to include unique extensions) preferred (e.g. XMPP or Matrix) if possible.

Data markings and structure supports automated processing by CDS and other data orchestration capabilities to enable real-time and cross-conclave chat collaboration as well as other data automation services (i.e. alerts/warnings).

Federation & CDS Integration Chat services can federate with like-instances of other chat services in different IP spaces, to include .MIL to .COM, .GOV, NGO and episodic/ad hoc enclaves.

Data markings and structure supports automated processing by CDS to enable real-time cross enclave chat collaboration. CDS gateways can participate as proxy agents in chat groups/rooms to facilitate cross enclave chat room bridging.

Resilience & Presence

· The capability will implement efficient and best effort protocols that assure delivery of chat messages against denied, disrupted, intermittent and limited (DDIL) network connectivity.

· Ability to support chat functions between connected users in the absence of a supporting common server (local or reach-back)

· Presence indicators should function reliably in D-DIL environments, using available network information to reflect user status as accurately and timely as possible.

· Solution should leverage available network heath/availability data to make policy-based decisions (PACE/precedence) on data exchange.

Interoperability

· The protocol shall support integration with existing tactical radios and data link systems.

Network Requirements Network Flexibility Peer chat without server in disconnected scenarios.

Operates in narrowband/DDIL and non-IP environments.

Gateways such as DISA Boundary Cloud Access Point (BCAP) enable capability reach into/through commercial IP network space from MIL/GOV space to access commercially hosted computer/store/network services.

Episodic/Ad-hoc Support Capability can be organically hosed on MPE enclaves (NATO, FVEY, CX-K/J), and episodic/ad-hoc enclaves.

Other General Requirements Open IP/Data Rights

· Solution interfaces and data representations are ideally open standards that are supported by multiple vendors as well as open-source products.

CSSP/DCO Support

· Capability makes data and service performance visible to CSSP and DCO cyber requirements.

Traceable SBOM

· The solution should include a comprehensive, traceable Software Bill of Materials (SBOM) that lists all components, their versions, and associated suppliers, and shall support verification through cryptographic signing to ensure provenance and integrity across the software lifecycle.

Standalone Deployment

· Solution should be deliverable as a standalone capability and shall not be bundled with broader solution suites that include unrelated or non-essential functionality.

Additional Requirements:

· Company Profile: Narrative describing the company’s core business; Company name, NAICS, CAGE code, and DUNS number; Company size and locations; Traditional/non-traditional defense contractor; Point of contact and email address

· Corporate Experience: Detail prior/current United States Department of Defense (DoD) and/or foreign defense department corporate experience performing efforts of similar size and scope within the last three years, including contract number, organization supported, indication of whether as a prime or subcontractor, contract value, government point of contact, and a brief description of the specific task areas as they relate to the services described herein.

· Capabilities: Describe experience and capabilities in managing DoD tasks of this nature and size, including system engineering, software development, software upgrades, testing, integration, training, and help desk support for any new software components.

· Security Requirements: Indicate the ability to meet security requirements, including Secret Security Clearance for personnel and Secret Facility Clearance and Secret Safeguarding.

· Cybersecurity: Describe experience with Risk Management Framework accreditations, Information Assurance Vulnerability Alert updates, and Security Technical Implementation Guides.

Submission of Responses:

Submission Deadline and Contact Information:

Responses shall be submitted electronically no later than noon (12 PM) EST on 13 June 2025. All questions and responses shall be submitted via email to virginia.a.pippen.civ@army.mil and shall not exceed 10 pages, using a 12-point Times New Roman font presented in a in a .docx or .pdf format. An additional, single, cover page may be submitted. If the vendor chooses, the Vendor may complete the requirements checklist showing how their product meets the indicated requirements.

Additional Discussions:

The Government may choose to reach out to select respondents for additional discussions as a result of this RFI to obtain further information as part of the market research effort.

Questions:

Questions regarding this RFI shall be submitted in writing by email NLT 16 May 2025 to the contacts listed above. As questions are submitted, they will be collected and all questions will be answered at the same time, posted on SAM.gov by close of business on 30 May 2025. The Government does not guarantee the ability to answer questions received after 16 May 2025.

Disclaimer:

This RFI is issued solely for informational and planning purposes. This RFI is not a solicitation. This RFI is not to be considered a commitment by the Government to issue a solicitation or award a contract. Responses to this RFI are not proposals and cannot be accepted by the Government to form a binding contract. Federal Acquisition Regulation (FAR) clause 52.215-3, “Request for Information or Solicitation for Planning Purposes”, is incorporated by reference. The Government does not intend to reimburse respondents for any costs associated with the submissions of their responses to this RFI; respondents to this RFI are solely responsible for all expenses associated with responding. Proprietary information and trade secrets, if any, must be clearly marked on all materials. All information received in response to this RFI that is marked “Proprietary” will be handled accordingly. Please be advised that all submissions become Government property and will not be returned. The Government will not be confirming receipt of submissions. In accordance with FAR 15.201(e), responses to this RFI are not offers and cannot be accepted by the Government to form a binding contract.

Responses from this RFI will be used to formatively shape broad Army guidance for acquiring software solutions. Response content may be aggregated and anonymously published into summary documentation to facilitate such guidance. Any publications resulting from this RFI will be non-attributional. RFI respondents consent to their submissions being used for such purposes.

Note: Ensure proprietary information and trade secrets are clearly marked on all materials. All submissions become Government property and will not be returned nor will receipt be confirmed.