IEEE Std 802.15.22.3-2020 pdf download

IEEE Std 802.15.22.3-2020 pdf download.IEEE Standard for Spectrum Characterization and Occupancy Sensing.
The primary goals of the SCOS architecture are to achieve distributed persistent sensing and data aggregation. To meet these goals, SCOS developers are required to meet general requirements categorized and described in the following subclauses.
4.4.1 Connectivity, control, and access
The following requirements are related to connectivity, Sensor control, and data access:
Connectivity and access: Sensors and the Manager shall be remotely accessible to authorized users over a network.
Control: SCOS entities shall provide interfaces for distributed control and data acquisition.
Discoverable capabilities: SCOS capabilities and resources shall be discoverable.
Data access: SCOS entities shall make data available to authorized users.
Data standardization: Compliance with a common metadataldata specification is required to allow for collaborative research, large-scale analytics, and sharing of sophisticated tools and methodologies. Sensor data acquisitions shall include SigMF metadata and should use the SigMF extensions defined in Annex B.
4.4.2 Design flexibility
The following requirements support the evolution of SCOS technology and broad deployments.
— Extensible technologies, algorithms, and metrics: The SCOS architecture shall support the evolution of centralized and edge processing, sensor technologies, and metrics.
— Hardware, software, OS, and protocol agnostic: SCOS standard implementations shall not be bound to specific hardware, software, operating systems or protocols to allow for cost-performance tradeoffs to be considered during the design process and for implementations to be tailored to address unique domain requirements.
5. Sensor
5.1 Hardware
Figure 3 provides a block diagram of the basic Sensor hardware model. There may be more sophisticated hardware models, for example with multiple antennas and/or multiple signal analyzers connected to a single computer. Each of the components may also be integrated within a single unit (e.g., a mobile phone). Metadata to describe the hardware components is defined in Annex B.
— Antenna: Required Sensor hardware component that convert environmental electromagnetic fields into a voltage. An RF cable may connect the antenna with the next hardware component.
Preselector: Optional Sensor hardware component that can provide preselection filtering. improved sensitivity via low noise amplification, and calibration signal sources.
Signal analyzer: Required Sensor hardware component, for example software defined radios (SDRs), rhich capture discrete raw data (e.g., baseband representation of the signal) and can apply digital signal processing algorithms to the raw data to achieve a desired metric.
Computer: Required Sensor hardware component that can provide control signals and messages to the preselector and receiver. Computers may also provide data processing, data packaging, and remotely accessible services.
5.2 Software
5.2.1 Functional requirements
The following are functional requirements of the Sensor software in order to provide a common language for Sensor control and data acquisition. Sensors shall:
Associate with a Manager using the association request defined in Table 1.
Describe Sensor status, for example: location. system datetime, last calibration datetime, and execution status as defined in Table 4.
— Advertise Sensor capabilities, for example Sensor hardware configuration and available actions, as defined in Table 6. Actions are functions that the Sensor developer implements and exposes to the API. Actions should be used to constrain Sensor tasks to the valid operational ranges of hardware components (e.g., frequency range of antenna, preselector, and signal analyzer).
— Execute schedule entries, defined in Table 7, that specify action, start/stop times, interval, and/or priority.
Describe schedule and task status as defined in Table 12 in response to the status request defined in Table 11.
Record and distribute acquisitions including metadata describing the measurement and security categorization of the data.
5.2.2 Messages
The following subclauses describe the Sensor messages used to provide the core functionality across five key system interactions: association, capabilities, subscription, schedule, and data distribution. Each of the message descriptions below includes a column titled RJO/C that indicates whether each property is required (R), optional (0), or conditional (C). Required properties shall be included in the message. Optional properties may be included in the message, and conditional properties shall be included in the message under specified conditions. In addition, many of the messages below utilize conditional properties and indicate that the properties shall be used when the underlying protocol does not inherently define the property. The SCOS system remains protocol agnostic and in some protocols it makes more sense to rely on the built-in features of the protocol than to rely on custom properties within the messages themselves. For example, HTTP defines verbs that define common operations like create, read, update, and delete and also includes status codes that are useful to indicate common status conditions.
5.2.2.1 Association
Association messages allow Sensors to register with a Manager. Table 1 and Table 2 describe the association request and response messages.