Dynamic PORT Boundaries for RPAS CPDLC A Message-Type-Sensitive Conceptual Framework under RCP 240

Controller–Pilot Data Link Communications (CPDLC) performance is commonly interpreted within the Performance-Based Communication and Surveillance (PBCS) framework through transaction-time metrics and Required Communication Performance (RCP) specifications. In conventional aircraft operations, the aircraft communication end system, cockpit display, and flight crew are located within a single operational environment. In Remotely Piloted Aircraft System (RPAS) operations, however, the remotely piloted aircraft (RPA) and the responsible remote-pilot (RP) are separated by the command-and-control (C2) link and the Remote Pilot Station (RPS). This distributed architecture creates intermediate transaction states between aircraft-side message receipt and remote-pilot (RP) operational response, making aircraft-side logical acknowledgement an insufficient proxy for pilot awareness, interpretation, or action.This paper develops a message-type-sensitive conceptual framework for interpreting Pilot Operational Response Time (PORT) in RPAS CPDLC transactions under RCP 240 logic. Using structured conceptual synthesis, the framework aligns PBCS/CPDLC transaction logic with RPAS communication architecture and RP human-response considerations. It introduces four analytical constructs: Acknowledgement-State Ambiguity, RPAS Relay Penalty, PORT Encroachment, and Dynamic PORT Boundary. These constructs are organized around a state-transition model that distinguishes ATC uplink initiation, RPA receipt, RPS delivery, RP awareness, pilot response initiation, and ATC-side closure. The framework further classifies CPDLC messages into administrative/informational, communication-management, strategic trajectory/planning, tactical control, and abnormal/contingency/emergency classes. For each class, it links message urgency, acknowledgement-state progression, monitoring evidence, and escalation posture. The proposed framework is conceptual rather than regulatory or empirical; it does not define validated timing thresholds, prescribe operational timers, or claim RCP 240 compliance. Instead, it provides a structured basis for future empirical validation, RPS HMI design, RPAS safety-case development, and RPAS-specific extensions to CPDLC performance monitoring.