The package provides public semantic identities for sensing participants, arrangements, requirements, capabilities, information, performance, results, and evidence. Domains represent concepts associated with those subjects; they are not operational nodes, functions, services, or control systems.
Why it matters: Clear boundaries among sensing concepts help readers compare terminology, evidence posture, and adjacent ideas without turning an LJP domain name into a standards claim or implementation claim.
6G Sensing Fabric is an LJP-organized public reference spanning three semantic views and 25 approved public domains. Sensing Node anchors the environment, entity, and topology view. Sensing Capabilities anchors the objectives, profiles, capabilities, and services view. Sensing Data Integration anchors the information, performance, results, and evidence view. The three-view organization and semantic capability traverse are an LJP synthesis and do not constitute an official 3GPP architecture or standardized taxonomy. Individual technical concepts are mapped to primary-source specifications and study items according to their verified publication status.
Sensing Entity represents concepts associated with sensing transmitter and receiver entity identity. Distinguishing participants helps readers discuss sensing arrangements without treating a descriptive identity as an operating entity. Within Sensing Environment, Entities & Topology, it is the primary identity.
sensingentity.comSensing Topology represents concepts associated with spatial and configurational relationships among sensing participants. Topology language helps compare how participants are arranged while leaving implementation and protocol choices open. Within Sensing Environment, Entities & Topology, it is the primary identity.
sensingtopology.comMonostatic Sensing represents concepts associated with a monostatic sensing configuration. A distinct identity for the monostatic configuration helps separate it from bistatic and multistatic arrangements. Within Sensing Environment, Entities & Topology, it is the primary identity.
monostaticsensing.comBistatic Sensing represents concepts associated with a bistatic sensing configuration. A distinct identity for the bistatic configuration helps separate transmitter and receiver placement questions from other arrangements. Within Sensing Environment, Entities & Topology, it is the primary identity.
bistaticsensing.comMultistatic Sensing represents concepts associated with a multistatic or cooperative sensing configuration. A distinct identity for multistatic sensing helps discuss multiple participating entities without implying one required coordination method. Within Sensing Environment, Entities & Topology, it is the primary identity.
multistaticsensing.comSensing Infrastructure represents concepts associated with the broader environment that can support sensing activity. This supporting identity provides environmental context without implying an operational platform or established standards term. Within Sensing Environment, Entities & Topology, it is the supporting identity.
sensinginfrastructure.comSensing Mesh represents concepts associated with distributed or cooperative relationships among sensing participants. This supporting identity helps describe distributed participation while avoiding claims about a prescribed mesh implementation. Within Sensing Environment, Entities & Topology, it is the supporting identity.
sensingmesh.comSpatial Network Sensing represents concepts associated with the broader spatial-network sensing space. This supporting identity provides spatial context while remaining LJP descriptive vocabulary rather than established standards terminology. Within Sensing Environment, Entities & Topology, it is the supporting identity.
spatialnetworksensing.comSensing Capabilities represents concepts associated with a set or description of sensing capabilities. The View 2 anchor gives readers a stable entry point for discussing what sensing may be provided against a requirement. Within Sensing Objectives, Profiles, Capabilities & Services, it is the anchor identity.
sensingcapabilities.comSensing Objective represents concepts associated with a desired sensing outcome expressed as a public-safe abstraction. Separating an objective from a request or service type helps readers frame outcomes without claiming a sensing-intent function. Within Sensing Objectives, Profiles, Capabilities & Services, it is the primary identity.
sensingobjective.comSensing Profiles represents concepts associated with an LJP semantic abstraction for requirements, KPIs, and constraints. The abstraction helps group requirement context without claiming a standards construct called a Sensing Profile. Within Sensing Objectives, Profiles, Capabilities & Services, it is the primary identity.
sensingprofiles.comSensing Service Type represents concepts associated with classification of a requested or offered sensing service. A separate service-type identity helps distinguish classification from objectives, capabilities, requests, and authorization boundaries. Within Sensing Objectives, Profiles, Capabilities & Services, it is the primary identity.
sensingservicetype.comSensing Request represents concepts associated with a request associated with a sensing service. A request identity helps distinguish the expression of a need from the capability, service type, selection, or result. Within Sensing Objectives, Profiles, Capabilities & Services, it is the primary identity.
sensingrequest.comTRP Discovery and Selection provides a bounded identity for considering TRPs within the broader, developing area of sensing-entity discovery and selection. Current sources establish TRPs as possible sensing nodes and establish sensing-entity discovery and selection, but they do not establish a standardized TRP-specific discovery-and-selection procedure. Within Sensing Objectives, Profiles, Capabilities & Services, it remains the primary identity.
trpdiscoveryandselection.comSensing Authorization represents concepts associated with an authorization boundary associated with sensing activity or service. A distinct boundary identity helps separate permission context from objectives, requests, selection, and operational behavior. Within Sensing Objectives, Profiles, Capabilities & Services, it is the primary identity.
sensingauthorization.comSensing Capability represents concepts associated with an individual sensing capability identity. The singular term supports the plural anchor and remains less prominent; the distinction is LJP descriptive vocabulary. Within Sensing Objectives, Profiles, Capabilities & Services, it is the supporting identity.
sensingcapability.comSensing Contextual Information represents concepts associated with context that may influence requirements or selection. This supporting identity helps describe relevant context without presenting the phrase as established standards terminology. Within Sensing Objectives, Profiles, Capabilities & Services, it is the supporting identity.
sensingcontextualinformation.comSensing Data Integration represents concepts associated with integration of sensing information or data. The View 3 anchor gives readers a stable entry point for discussing information, performance, results, and evidence. Within Sensing Information, Performance, Results & Evidence, it is the anchor identity.
sensingdataintegration.comSensing Information represents concepts associated with information representation associated with sensing. A distinct information identity helps separate representation from transport, integration, performance, and results. Within Sensing Information, Performance, Results & Evidence, it is the primary identity.
sensinginformation.comSensing Data Transmission represents concepts associated with transport or transmission of sensing data. A separate transport identity helps distinguish movement of data from its representation, integration, evaluation, or result. Within Sensing Information, Performance, Results & Evidence, it is the primary identity.
sensingdatatransmission.comSensing Performance represents concepts associated with performance or KPI evaluation associated with sensing. A performance identity helps separate evaluation from information, transmission, results, and evidence. Within Sensing Information, Performance, Results & Evidence, it is the primary identity.
sensingperformance.comSensing Result represents concepts associated with the identity of a sensing result. A distinct result identity helps readers separate what remains from the information, performance evaluation, and supporting evidence. Within Sensing Information, Performance, Results & Evidence, it is the primary identity.
sensingresult.comSensing Evidence represents concepts associated with evidence associated with sensing operations, results or provenance. This bounded identity provides public orientation to evidence and provenance without describing implementation detail. Within Sensing Information, Performance, Results & Evidence, it is the primary identity.
sensingevidence.comSensing Metadata represents concepts associated with descriptive context for sensing data. This supporting identity helps discuss descriptive context while remaining LJP descriptive vocabulary rather than established standards terminology. Within Sensing Information, Performance, Results & Evidence, it is the supporting identity.
sensingmetadata.comThe package uses three LJP-defined views: Sensing Environment, Entities & Topology asks what exists and participates in sensing and how it is arranged; Sensing Objectives, Profiles, Capabilities & Services asks what sensing can be provided against a requirement; and Sensing Information, Performance, Results & Evidence asks what was produced, how well, and what result remains. Its conceptual traverse is Objective, Profile or Requirements, Capabilities, Service Type, Request, Discovery or Selection, Authorization, Sensing Information, Performance, Result, and Evidence. The traverse is Evidence Level E, an LJP synthesis rather than a protocol sequence or executed workflow. Cross-cutting considerations are security, privacy and trust; cooperative or multi-entity sensing; compute or AI as a candidate relationship and LJP synthesis; and performance and evaluation. The three-view organization and semantic capability traverse are an LJP synthesis and do not constitute an official 3GPP architecture or standardized taxonomy. Individual technical concepts are mapped to primary-source specifications and study items according to their verified publication status.
ETSI GR ISC 003 V1.1.1 (2026-02), clauses 4 and 5, and informative Technical Report ITU-T YSTR.ISAC-fra (11/2025), clauses 6 to 8, support underlying sensing-node, capability, request, data-processing, performance, and result concepts. ETSI ISG ISAC performs pre-standardisation work; its reports are not normative 3GPP architecture. The three-view package and traverse remain LJP synthesis, Evidence Level E.
ETSI · ETSI GR ISC 003 V1.1.1 (2026-02)
Supports published ETSI terminology for sensing modes, entities, service requests, results, and architecture context.
Published ETSI Group Report; pre-standardisation material, not normative 3GPP architecture.
Does not establish the LJP three-view organization or conceptual traverse.
ITU · ITU-T YSTR.ISAC-fra (11/2025)
Supports underlying sensing capability, request, processing, performance, and result concepts.
Published ITU technical report.
Does not endorse LJP identities or package relationships.
Sensing terminology can collapse participants, configurations, objectives, requests, information, performance, results, and evidence into one undifferentiated narrative. That obscures what each concept means and what source families support it.
Identify the relevant sensing view and concept.
Review the concept definition, role, and evidence status.
Compare only the same-package explanatory links and their stated limits.
Reserve implementation and standards conclusions for controlled follow-on review.
Three LJP-defined views, 25 stable public identities, restrained same-package explanatory links, explicit evidence-status language, and the normal Publisher v2.2.2 package-membership graph.
Sensing Node is the canonical package-page host and the View 1 anchor under the existing Publisher package-page pattern. Sensing Capabilities and Sensing Data Integration remain the View 2 and View 3 anchors in public copy. This implementation choice does not make Sensing Node an operational node.
The three-view organization and semantic capability traverse are an LJP synthesis and do not constitute an official 3GPP architecture or standardized taxonomy. Individual technical concepts are mapped to primary-source specifications and study items according to their verified publication status. The domains provide semantic identity for concepts. They do not constitute an operational sensing platform, protocol sequence, service, implementation, or external endorsement. The normal Publisher graph expresses LJP package membership and page identity only; all such membership semantics are LJP synthesis.
The package organization is an LJP editorial construct. External sources explain their own terminology and do not endorse LJP, its namespaces, or a commercial evaluation.
Use the public package to frame a controlled review without inferring a standards architecture, protocol flow, or implementation.
Email LJP Asset Group