Network Management Operations W. Zhong Internet-Draft Y. Chen Intended status: Informational C. Gao Expires: 19 April 2027 XUPT 16 October 2026 Framework for High-Dimensional Anomaly Detection of Network Data in Human-Cyber-Physical Systems draft-zhong-nmop-hcps-anomaly-framework-00 Abstract Human-cyber-physical systems combine human activity, computing and communication services, and networked physical processes. Their network data is heterogeneous and high-dimensional. An abnormal condition can appear in the attributes of one entity, in an interaction between entities, or only when evidence from several domains is considered together. This document specifies an initial framework for anomaly detection in human-cyber-physical environments. It describes the functions used to inventory observations, construct entity and relation context, analyze high-dimensional data, and report an anomaly result. It also defines a small conceptual information model so that anomaly results retain their observation scope, feature context, and score meaning. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document is expected to take place on the Network Management Operations (NMOP) Working Group mailing list (nmop@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/nmop/. This document is currently an individual contribution. Its use of the NMOP name in the document header does not indicate Working Group adoption. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Zhong, et al. Expires 19 April 2027 [Page 1] Internet-Draft HCPS Anomaly Framework October 2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 19 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 2. Problem Statement and Terminology . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Heterogeneous HCPS Observations . . . . . . . . . . . . . 5 2.3. High-Dimensional Feature Space . . . . . . . . . . . . . 5 2.4. Relation and Cross-Domain Anomalies . . . . . . . . . . . 5 3. Framework Architecture . . . . . . . . . . . . . . . . . . . 6 3.1. Observation Inventory . . . . . . . . . . . . . . . . . . 7 3.2. Context Construction . . . . . . . . . . . . . . . . . . 7 3.3. High-Dimensional Anomaly Analysis . . . . . . . . . . . . 7 3.4. Anomaly Result Reporting . . . . . . . . . . . . . . . . 7 4. Initial Information Model . . . . . . . . . . . . . . . . . . 8 4.1. Observation and Feature Context . . . . . . . . . . . . . 8 4.2. Anomaly Result . . . . . . . . . . . . . . . . . . . . . 9 4.3. Evidence Handling . . . . . . . . . . . . . . . . . . . . 9 5. Security and Privacy Considerations . . . . . . . . . . . . . 9 6. Manageability Considerations . . . . . . . . . . . . . . . . 10 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 Zhong, et al. Expires 19 April 2027 [Page 2] Internet-Draft HCPS Anomaly Framework October 2026 8. Open Issues for Future Revisions . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Human-cyber-physical systems (HCPS) contains people, cyber components, and physical components that interact to perform an operational function. The cyber components include software, computing platforms, and communication services. The physical components include sensors, actuators, equipment, and the processes they observe or control. This usage follows work that places the human component inside the cyber-physical system rather than treating it as an external user [HCPS-AD]. It is also consistent with the NIST view of cyber-physical and Internet of Things systems as interacting logical, physical, transducing, and human components [NIST-CPS-IOT]. An HCPS produces network-accessible records of user actions, service operations, communications, sensor measurements, actuator states, and relations among these observations. The records use different schemas and time scales. When combined, they form a high-dimensional data space with both entity attributes and interaction structure. The broader network-big-data literature also identifies heterogeneity, uncertainty, and interaction among human, machine, and physical domains as central challenges [NETWORK-BIG-DATA]. Attributed-network detectors show that structure and attributes can be analyzed together [DOMINANT] [AnomalyDAE]. Other methods use multiple views, contrastive learning, or explicit node and relation types [CoLA] [AHEAD] [MOD-KF]. These methods demonstrate useful detection strategies, but each method reports results in its own form. A management system therefore cannot determine, in a consistent way, which HCPS domains, entities, relations, and feature groups supported a result. This document addresses that exchange problem. It complements the NMOP anomaly architecture, semantic metadata, and lifecycle work [I-D.ietf-nmop-network-anomaly-architecture] [I-D.ietf-nmop-network-anomaly-semantics] [I-D.ietf-nmop-network-anomaly-lifecycle]. It focuses on the additional context needed when anomaly evidence crosses human, cyber, and physical domains and includes high-dimensional features. Zhong, et al. Expires 19 April 2027 [Page 3] Internet-Draft HCPS Anomaly Framework October 2026 1.1. Scope This document defines four parts of an HCPS anomaly-detection framework: an observation inventory, context construction, high- dimensional anomaly analysis, and anomaly-result reporting. The framework allows different statistical, graph-based, or machine- learning methods to use the same basic description of a result. The information model covers the observation interval, HCPS domains, typed entities and relations, feature dimensions, detector profile, scores, and decision. Collection protocols and mitigation actions remain with the systems that already perform those functions. 1.2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Problem Statement and Terminology 2.1. Terminology HCPS Observation: A network-accessible record of a human action, cyber operation, physical measurement, physical state, or interaction among those domains. Source Domain: The human, cyber, physical, or cross-domain origin represented by an observation or evidence item. Entity: A typed object referenced by observations. Examples include an operational role, application service, network function, sensor, actuator, or controlled asset. Typed Relation: A declared interaction between two entities, such as accesses, invokes, communicates-with, observes, controls, or reports-to. Source-Aware Feature Space: A feature representation that retains the source domain and entity context of its dimensions after feature construction or dimensionality reduction. Zhong, et al. Expires 19 April 2027 [Page 4] Internet-Draft HCPS Anomaly Framework October 2026 Attribute Anomaly: A result indicating that observed entity attributes differ from the detector's reference context. Relation Anomaly: A result indicating that an observed or inferred interaction differs from the detector's reference context. Cross-Domain Anomaly: A result supported by evidence from more than one HCPS domain, or by a combination of entity attributes and typed relations. 2.2. Heterogeneous HCPS Observations Human-domain observations describe actions, roles, requests, and interaction sequences. Cyber-domain observations describe service calls, resource state, logs, and network flows. Physical-domain observations describe measurements, equipment state, actuation, and reporting behavior. Fields with similar labels do not necessarily have the same meaning across these domains. An anomaly detector therefore needs both the value being analyzed and the domain, entity type, and observation interval that give the value meaning. Removing that context can make a valid result impossible to interpret outside the detector that produced it. 2.3. High-Dimensional Feature Space Combining HCPS observations can create hundreds or thousands of features. Many are sparse, redundant, or valid only for one entity type. A detector can reduce or encode those features, but the reported result still needs to identify the source domain, feature namespace, input dimension, and encoded dimension when those values are needed to interpret the score. A source-aware representation preserves this information while allowing each detector to choose its own feature-selection, subspace, reconstruction, or graph-embedding method. 2.4. Relation and Cross-Domain Anomalies An entity can show ordinary attribute values while its interaction with another entity is unusual. For example, a familiar operational role, a healthy service, and a normally reporting sensor can still form a new or disallowed access-and-reporting chain. Separate per- domain detectors can miss this condition because no individual entity is unusual by itself. Zhong, et al. Expires 19 April 2027 [Page 5] Internet-Draft HCPS Anomaly Framework October 2026 The framework therefore distinguishes attribute evidence from relation evidence and records whether the final result depends on one HCPS domain or on cross-domain evidence. 3. Framework Architecture The framework has four logical stages. A deployment can place the stages in one implementation or distribute them across edge, network, and management systems. +----------------+ +----------------+ +----------------+ | Human-domain | | Cyber-domain | | Physical-domain| | observations | | observations | | observations | +-------+--------+ +-------+--------+ +-------+--------+ | | | +-------------------+-------------------+ | +---------v----------+ | Observation | | Inventory | +---------+----------+ | +---------v----------+ | Context | | Construction | | entities, relations| +---------+----------+ | +---------v----------+ | High-Dimensional | | Anomaly Analysis | +---------+----------+ | attribute, relation, or cross-domain result | +---------v----------+ | Result Reporting | | and Storage | +---------+----------+ | validation and lifecycle processing Figure 1: HCPS Anomaly-Detection Framework Zhong, et al. Expires 19 April 2027 [Page 6] Internet-Draft HCPS Anomaly Framework October 2026 3.1. Observation Inventory The inventory records which HCPS domains and entity types can provide observations during an analysis interval. It also records the local identifiers and schemas needed by the next stage. Each observation group included in a result MUST identify its source domain as human, cyber, physical, or cross-domain. 3.2. Context Construction This stage associates observations with typed entities and typed relations. It provides the context needed to recognize an unusual interaction even when each entity has ordinary attributes. A reported relation MUST state whether it was observed directly or inferred by the detector. 3.3. High-Dimensional Anomaly Analysis This stage constructs source-aware features and applies a local detection method. The method can examine entity attributes, relations, or both. Dimensionality reduction is allowed, but the result SHOULD retain the input and encoded dimensions when they are needed to reproduce or compare the analysis. For streaming data, one possible processing profile uses a change- aware observation window, groups features by source and redundancy, evaluates anomaly scores within the selected groups, and combines the group-level evidence. This outline deliberately leaves the change estimator, feature-selection method, local scoring algorithm, thresholds, and parameters to the detector profile. It describes the processing context that needs to be reported, rather than requiring one algorithm for every implementation. The stage produces an attribute, relation, or cross-domain score. Scores from different detector profiles MUST NOT be treated as directly comparable unless the profiles identify a shared calibration. 3.4. Anomaly Result Reporting This stage creates a compact anomaly record for storage, validation, correlation, or lifecycle processing. The record gives the receiving system enough context to understand what was analyzed and how the detector interpreted the result. It does not require the detector to disclose model parameters or raw high-dimensional observations. Zhong, et al. Expires 19 April 2027 [Page 7] Internet-Draft HCPS Anomaly Framework October 2026 4. Initial Information Model The information model describes the minimum context carried with an HCPS anomaly result. It is organized around four questions: which detector produced the result, what observations were examined, what type of anomaly was found, and what evidence can be disclosed. The model is conceptual in this revision and does not define an encoding. HCPS-Anomaly-Record identification event-id, detection-time, detector-id processing-profile profile-id, profile-version window-policy, feature-policy, scoring-policy observation-scope start-time, end-time, source-domains[] entities[], relations[] feature-summary[] source-domain, feature-namespace input-dimension, encoded-dimension contributing-feature-groups[] anomaly-result category, score, threshold, confidence, severity evidence-handling provenance[], sensitivity Figure 2: HCPS Anomaly Record 4.1. Observation and Feature Context The observation scope states the time interval and HCPS domains used for the decision. Entity entries state what kinds of actors, services, devices, or assets were involved. Relation entries state how those entities interacted and whether the relation was observed or inferred. The feature summary explains the dimensional context without copying raw values into the event. The namespace identifies the meaning of a feature group. The input and encoded dimensions show whether a high- dimensional representation was reduced before scoring. Zhong, et al. Expires 19 April 2027 [Page 8] Internet-Draft HCPS Anomaly Framework October 2026 4.2. Anomaly Result The detector identifier says which component produced the result. The processing profile says how that component formed its analysis window, selected or grouped features, and calculated its local score. The profile identifier and version allow a receiving system to find the corresponding configuration without placing formulas or model parameters in every anomaly record. The result category states whether the finding concerns entity attributes, a typed relation, or cross-domain evidence. Confidence describes the detector's certainty, while severity describes the expected operational importance. Keeping these meanings separate prevents a numerically high detector score from being interpreted as an automatically high operational impact. 4.3. Evidence Handling Provenance identifies the component that produced or transformed an evidence item. Sensitivity records whether disclosure is restricted. These fields allow a receiving system to evaluate the result and apply access policy without receiving all underlying human, cyber, or physical observations. 5. Security and Privacy Considerations HCPS anomaly processing crosses cyber and physical boundaries and can include human activity. A forged observation or relation can create a false alarm, hide a real anomaly, or cause an incorrect cross- domain correlation. Implementations need authentication, integrity protection, authorization, and audit appropriate to the deployment, following the general guidance in [RFC3552]. An anomaly result is evidence, not permission to act. A receiving system MUST NOT use the result as the sole authorization for a network change or physical action. Existing policy and safety controls remain responsible for such actions. Human-domain observations can reveal identity, behavior, location, role, and relationships. Implementations SHOULD use role-based or pseudonymous identifiers where possible, limit retained evidence, and avoid exporting raw feature values when a feature summary is enough. Access to entity, relation, and feature evidence needs to follow the stated operational purpose. Zhong, et al. Expires 19 April 2027 [Page 9] Internet-Draft HCPS Anomaly Framework October 2026 6. Manageability Considerations A deployment needs to manage entity and relation types, feature namespaces, detector profiles, score interpretation, retention, and access policy. Changes that alter score meaning or field semantics SHOULD result in a new detector-profile version so that stored results remain interpretable. Operators also need visibility into which source domains were available during an observation interval. Detailed states for missing, late, or policy-excluded evidence are left for a later revision. 7. Implementation Status This section is to be removed before publishing as an RFC. No interoperable implementation of the conceptual information model is reported for this -00 revision. The authors plan to test whether different high-dimensional detectors can produce records that a separate management component interprets consistently. 8. Open Issues for Future Revisions * alignment with the NMOP anomaly semantics and lifecycle models; * time quality, late evidence, and cross-domain entity resolution; * a stable YANG or message binding for the information model; and * interoperability reports from more than one detection method. 9. IANA Considerations This document has no IANA actions. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Zhong, et al. Expires 19 April 2027 [Page 10] Internet-Draft HCPS Anomaly Framework October 2026 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. Informative References [I-D.ietf-nmop-network-anomaly-architecture] Graf, T., Du, W., Francois, P., and A. Huang Feng, "A Framework for a Network Anomaly Detection Architecture", Work in Progress, Internet-Draft, draft-ietf-nmop-network- anomaly-architecture-08, July 2026, . [I-D.ietf-nmop-network-anomaly-semantics] Graf, T., Du, W., Huang Feng, A., and V. Riccobene, "Semantic Metadata Annotation for Network Anomaly Detection", Work in Progress, Internet-Draft, draft-ietf- nmop-network-anomaly-semantics-06, July 2026, . [I-D.ietf-nmop-network-anomaly-lifecycle] Riccobene, V., Graf, T., Du, W., and A. Huang Feng, "An Experiment: Network Anomaly Detection Lifecycle", Work in Progress, Internet-Draft, draft-ietf-nmop-network-anomaly- lifecycle-07, September 2026, . [HCPS-AD] Bajic, B., Rikalovic, A., Suzic, N., and V. Piuri, "Toward a Human-Cyber-Physical System for Real-Time Anomaly Detection", IEEE Systems Journal Vol. 18, DOI 10.1109/JSYST.2024.3402978, 2024, . [NIST-CPS-IOT] Greer, C., Burns, M., Wollman, D., and E. Griffor, "Cyber- Physical Systems and Internet of Things", NIST Special Publication 1900-202, DOI 10.6028/NIST.SP.1900-202, March 2019, . Zhong, et al. Expires 19 April 2027 [Page 11] Internet-Draft HCPS Anomaly Framework October 2026 [NETWORK-BIG-DATA] Wang, Y., Jin, X., and X. Cheng, "Network Big Data: Present and Future", 2014, . [DOMINANT] Ding, K., Li, J., Bhanushali, R., and H. Liu, "Deep Anomaly Detection on Attributed Networks", SDM pp. 594-602, DOI 10.1137/1.9781611975673.67, 2019, . [AnomalyDAE] Fan, H., Zhang, F., and Z. Li, "AnomalyDAE: Dual Autoencoder for Anomaly Detection on Attributed Networks", ICASSP pp. 5685-5689, DOI 10.1109/ICASSP40776.2020.9053387, 2020, . [CoLA] Liu, Y., Li, Z., Pan, S., Gong, C., Zhou, C., and G. Karypis, "Anomaly Detection on Attributed Networks via Contrastive Self-Supervised Learning", IEEE TNNLS Vol. 33, No. 6, pp. 2378-2392, DOI 10.1109/TNNLS.2021.3068344, 2021, . [AHEAD] Yang, S., Zhang, B., Feng, S., Tan, Z., Zheng, Q., Zhou, J., and M. Luo, "AHEAD: A Triple Attention Based Heterogeneous Graph Anomaly Detection Approach", arXiv 2208.08200, August 2022, . [MOD-KF] Du, H., Cao, Z., Wang, W., and L. Bai, "Multi-view Outlier Detection for Attributed Network Based on Knowledge Fusion", Acta Automatica Sinica Vol. 49, No. 8, pp. 1732-1744, DOI 10.16383/j.aas.c220629, 2023, . Authors' Addresses Wei Zhong School of Cyberspace Security, XUPT Xi'an China Email: wzhong@stu.xupt.edu.cn Zhong, et al. Expires 19 April 2027 [Page 12] Internet-Draft HCPS Anomaly Framework October 2026 Yanping Chen School of Computer Science and Technology, XUPT Xi'an China Email: chenyp@xupt.edu.cn Cong Gao School of Computer Science and Technology, XUPT Xi'an China Email: cgao@xupt.edu.cn Zhong, et al. Expires 19 April 2027 [Page 13]