mode = titleLwHBench: A low-level hardware component benchmark and dataset for
Single Board Computers

[orcid=0000-0002-6444-2102] [1]

[orcid=0000-0003-1365-7573]

[orcid=0000-0001-7125-1710]

[orcid=0000-0002-4534-3483]

[orcid=0000-0002-7768-9665]

[orcid=0000-0001-5532-6604]

# LwHBench: A low-level hardware component benchmark and dataset for Single
Board Computers

Pedro Miguel Sánchez Sánchez  José María Jorquera Valero  Alberto Huertas
Celdrán  Gérôme Bovet  Manuel Gil Pérez  Gregorio Martínez Pérez  Department
of Information and Communications Engineering, University of Murcia, Murcia
30100, Spain. Corresponding author: Pedro Miguel Sanchez
<EMAIL_ADDRESS> Communication Systems Group (CSG), Department of
Informatics (IfI), University of Zurich UZH, 8050 Zürich, Switzerland  Cyber-
Defence Campus within armasuisse Science & Technology, CH—3602 Thun,
Switzerland

###### Abstract

In today’s computing environment, where Artificial Intelligence (AI) and data
processing are moving toward the Internet of Things (IoT) and Edge computing
paradigms, benchmarking resource-constrained devices is a critical task to
evaluate their suitability and performance. Between the employed devices,
Single-Board Computers arise as multi-purpose and affordable systems. The
literature has explored Single-Board Computers performance when running high-
level benchmarks specialized in particular application scenarios, such as AI
or medical applications. However, lower-level benchmarking applications and
datasets are needed to enable new Edge-based AI solutions for network, system
and service management based on device and component performance, such as
individual device identification. Thus, this paper presents LwHBench, a low-
level hardware benchmarking application for Single-Board Computers that
measures the performance of CPU, GPU, Memory and Storage taking into account
the component constraints in these types of devices. LwHBench has been
implemented for Raspberry Pi devices and run for 100 days on a set of 45
devices to generate an extensive dataset that allows the usage of AI
techniques in scenarios where performance data can help in the device
management process. Besides, to demonstrate the inter-scenario capability of
the dataset, a series of AI-enabled use cases about device identification and
context impact on performance are presented as exploration of the published
data. Finally, the benchmark application has been adapted and applied to an
agriculture-focused scenario where three RockPro64 devices are present.

###### keywords:

Hardware Benchmarking System Performance Dataset IoT device Identification

##  1 Introduction

Performance benchmarking has been an issue explored since the early days of
computer science. Knowing the capabilities of a device is critical to create
applications optimized for it [1]. In this sense, benchmarking has become a
priority due to the magnification of the number of online devices provoked by
new technologies such as 5G, IoT or cloud. In addition, the explosion of
techniques such as Machine Learning (ML) and Deep Learning (DL), which usually
require high computational power, has been another key factor increasing the
need for processing measurement applications. In this context, device
performance benchmarking is a research avenue that acquired a large momentum
in the last years [2], especially in IoT and Edge computing paradigms.
Benchmarking can be defined as an intentional stress introduced in a system to
measure how the device behaves regarding a determined set of metrics [3]. The
main purposes of benchmarking are to i) verify that the performance of a
device is the promised one and suitable for a certain activity such as running
AI tasks, and ii) model the internal behavior of a certain device to identify
it or verify that it is running properly [4]. Therefore, device benchmarking
can be seen from two perspectives. First, as a high-level system benchmarking
that seeks to measure how a certain application works on the device in terms
of performance or Quality-of-Service (QoS), for example, in execution time or
energy consumption. Second, as a low-level hardware benchmarking, which goal
is to characterize the device components in a more precise way [5], so it is
possible to differentiate devices or detect imperfections and errors in the
chips, among other options. “Low-level” indicates that the focus of the
measurements is close to the physical level of the components, measuring
values such as frequencies and cycles instead of QoS (time and energy). An
example of this type of benchmarking would be to measure how many cycles it
takes a processor to execute a certain simple task, measuring whether it meets
its specification and the necessary stability requirements.

Moreover, due to the explosion undergone by AI, and more specifically ML and
DL [6], these techniques have also landed in the IoT field, being applied in
areas such as industry, network and service management or cybersecurity. Thus,
the field of IoT benchmarking also has the task of evaluating the performance
of training and deploying ML/DL in these devices hardware. Numerous solutions
have explored the capabilities of IoT devices, mainly Single-Board Computers
(SBC) such as Raspberry Pi, when running different ML/DL algorithms and
libraries [7], so this is an area with enough pedigree and many recent works
[8]. However, low-level hardware benchmarking and the application of ML/DL in
the data generated from these benchmarks remain mostly unexplored in the IoT
field. This is an important task as critical functionalities are moving to the
IoT and having the components of these devices properly analyzed is essential.

Then, although many benchmarks have been proposed for SBCs in recent years, as
[2] shows, some challenges are present in the area, such as (i) many
benchmarks are proposed but no exhaustive execution datasets are provided;
(ii) all recent benchmarks focus on high-level applications and none of them
measures the performance of the hardware from a low-level perspective; (iii)
there is no work measuring the components performance from a different
component of the same device, which is important to avoid inconsistent values
coming from the measured component (e.g. measure an execution time using the
CPU as its own source of timestamps), as it can not notice its own inaccuracy;
(iv) only a few solutions consider storage and memory in the benchmark, most
of them are focused on CPU QoS (execution time, computation and communication
latency); and (v) none of the previous SBC benchmark solutions consider GPU
low-level performance for non-graphics processing.

In order to improve the previous limitations and fill the literature gap, the
main contributions of the present work are:

  * •

A low-level hardware component benchmarking application, namely LwHBench,
which measures CPU, GPU, memory and storage device performance from the device
reference point. The benchmark is implemented as a proof of concept for
Raspberry Pi devices [9], taking into account the particularities of their
hardware components.

  * •

A comprehensive dataset acquired as a result of running the previous benchmark
on a set of 45 Raspberry Pi of various models for 100 days [10]. For data
collection, a series of measures regarding the stability of the device
performance have been taken, setting the frequency of the components to fixed
values and trying to reduce as much as possible the possible noise introduced
in the measurements by other processes running on the devices. This dataset
contains a total of 4 GB of data (2386126 vectors), more than any other
benchmark dataset in the literature, ready to be used in ML/DL-based
applications by other researchers in a wide variety of use cases.

  * •

A set of potential use cases described as possible application scenarios for
the benchmark and the published dataset. These use cases are partially solved
as a preliminary exploration of the dataset, so that other researchers know
how to apply their ML/DL algorithms. The code used in these use cases is also
publicly available at [9]. Besides, these use cases are also demonstrated in a
real world IoT agriculture deployment using 3 RockPro64 devices, another SBC
model.

The remainder of this article is structured as follows. Section 2 provides a
review of the literature status regarding SBC performance benchmarking.
Section 3 describes the methodology and approach followed for the benchmark
implementation and generation of the dataset. Section 4 describes the
functions executed in each one of the components considered, while Section 5
explores the collected data through a set of use cases. Section 6 depicts a
real-world adaptation and deployment of the benchmark. Section 7 draws the
main strong points of the proposed method together with the drawbacks
identified during the work development. Finally, Section 8 draws the main
conclusions of the present work and future research lines.

##  2 Related Work

This section analyzes related work dealing with performance benchmarking, with
a special focus on Edge computing and IoT, and existing datasets regarding IoT
device performance monitoring.

Table 1: Comparison of IoT Benchmarking applications and datasets. Solution |  Device Type |  Monitored Components |  Metrics |  Public Data |  Open Source
---|---|---|---|---|---
[11] | SBC | GPU | Processing time, resource usage (%) | ✗ | ✗
[12] | SBC | CPU | GFLOPS, energy | ✗ | ✗
[7] | SBC / PC | CPU, GPU, memory | Processing time, mem speed, energy | ✗ | ✓
[13] | Medical IoT | CPU, memory | Hardware Performance Counters | ✗ | ✓
[14] | Cloud | CPU, memory, network | Processing time, network / mem speed | ✗ | ✗
[15] | SBC | CPU, memory, network | Processing time, network / mem speed | ✗ | ✓
[16] | Edge Servers | CPU | N Instructions |  ✓(2.5 MB) | ✓
[17] | SBC | CPU | GFLOPS | ✗ | ✓
[18] | IoT | CPU | Packet inter-arrival time |  ✓(1.5 GB) | ✗
[19] | IoT | Radio transmitters | Raw transmission data |  ✓(+50 GB) | ✗
[20] | SBC | CPU | GFLOPS, energy | ✗ | ✓
[21] | Any | SRAM and Flash memories | Initial bit status |  ✓(To be published) | ✓
This work | SBC | CPU, GPU, Memory, Storage | Cycles counters and processing time |  ✓(4 GB) | ✓

Regarding performance benchmarking, Varghese et al. [2] surveyed the evolution
of this field from the early 90s to 2020, with special consideration of Edge
benchmarking since the 2010s. This survey shows that many performance
benchmarking applications have been published in recent years, most of them
centered on SBCs, such as Raspberry Pi. The vast majority of these
applications focus on CPU and memory benchmarking [13], while only a few test
additional resources [22], such as storage, network or accelerators (GPU/TPU).
Despite the usefulness to test devices from different brands and models, none
of the existing Edge performance benchmarks revised in [2] is focused on the
extraction of low-level information capable of detecting hardware
imperfections or malfunctioning. In contrast, these existing benchmarks are
based on the execution of complex or advanced applications [15], such as AI
libraries [7] or orchestrators, and not on fast execution code for low-level
fingerprinting. Some benchmarks [14] also measure the performance of cloud
platforms oriented to the IoT, such as AWS Greengrass or Azure IoT Edge.
Regarding measurement metrics, most of the benchmarks use time-based metrics
such as GFLOPS (Giga Floating Point Operations per Second) for CPU or MB/s for
memory and network, with only a few of them using more complex and low-level
ones such as Hardware Performance Counters [13]. Besides, although most
benchmarking applications provide datasets with them (12 of 14 analyzed
applications), only 5 out of 14 benchmarking applications use full open-source
software, while 10 out of 15 use commercial-grade software. Finally, [2] also
shows that most high-level benchmarks use commercial or proprietary software
in their implementations.

In the area of low-level benchmarking, [11] evaluated the performance of the
GPUs embedded in ARM SBCs, noticing great improvements comparing the GPU
performance to the CPU when doing mathematical operations, but with higher
energy consumption. Furthermore, [12] built a Raspberry Pi cluster and
performed CPU and energy consumption testing to find the best
energy/price/performance model. Similarly, three clusters, each consisting of
16 different SBC models, were built in [20] to benchmark the SBC performance
in terms of computing and energy consumption. [17] followed a similar cluster-
oriented benchmarking but focusing on cryptography libraries. However, these
benchmarks perform fairly simple metrics about performance and do not publish
their data, which do not enable the application of the generated data to new
domains such as fingerprinting. From a different domain, [23] explored
recently the low-level benchmarking of quantum computers, an area gaining
importance in recent years that supports the need for lower-level hardware
benchmarking.

Dealing with datasets about hardware performance, there are just a few
examples available in the literature. Many benchmarking applications include
simple data samples [2]. One example is [16], which contains 2.5 MB of traces
of different high-level benchmarking applications executed in Edge servers.
However, these are not exhaustive datasets collected during long execution
periods and are not suitable for ML/DL approaches due to their size
constraints. Regarding datasets directly focused on low-level performance
fingerprinting, [21] contains fingerprints from different SRAM (Static RAM)
chips, which were used in [24] to perform individual identification. However,
most SBC models do not include SRAM chips due to their higher cost. From a
different perspective, [19] contains radio spectrum measurements from
different IoT devices, which can be employed to fingerprint their transmission
performance and properties. Similarly, [25] also contains raw IQ signals from
9 IoT devices that can be used for fingerprinting tasks. Moreover, [18]
presents inter-arrival time information from different wireless routers and
IoT devices, and it is aimed at individual and device type fingerprinting. In
contrast, to the best of our knowledge, there is not any comprehensive dataset
regarding low-level performance fingerprinting or benchmarking of hardware
components.

Table 1 shows a comparison between the different benchmarking applications and
datasets found in the literature and the present one. From the analysis made
in this section, it is noticed that there is a gap regarding solutions focused
on low-level benchmarking. Most of the recent solutions focus on high-level
application benchmarking, and the ones focusing on low-level performance only
use simple performance metrics and do not provide extensive datasets to enable
ML/DL-based use cases or new applications. Moreover, the datasets found in the
literature are focused on other areas such as device identification, and not
on hardware component benchmarking.

##  3 Benchmark and Dataset Generation Methodology

This section describes the methodology followed in order to implement the
benchmark application and collect the samples available in the dataset:
providing the details of the scenario used for data collection; describing the
components monitored and how their performance is measured; detailing the
libraries used to collect each metric; and finally, explaining the
configuration options and measures taken to ensure stability and avoid noise
in the samples published.

###  3.1 Deployment and Configuration

For the LwHBench benchmark implementation and testing, a wide number of
devices is required. In this sense, the benchmark is executed, to collect the
dataset, in a set of 45 physical devices composed of several models of
Raspberry Pi (RPi) devices. Table 2 shows a summary of the devices employed
for validation, their distribution and main characteristics.

Table 2: Number, model and most relevant characteristics of the devices used
for validation.

N |  RPi model |  Revision |  SoC |  CPU |  GPU |  Cache |  RAM |  SD
---|---|---|---|---|---|---|---|---
15 |  Raspberry Pi 4 Model B |  1.1/1.4 |  BCM2711 |  1.5 GHz quad-core 64 bit ARM A72 |  500 MHz Broadcom VideoCore VI |  2-way set associative 32 kB and 48 kB level one instruction and data caches, respectively, and a 1 MB unified level two cache |  4 GB LPDDR4 |  16GB A1 Type 10 SandDisk Ultra
10 |  Raspberry Pi 3 Model B+ |  1.3 |  BCM2837 |  1.4 GHz quad-core 64 bit ARM A53 |  400 MHz Broadcom VideoCore IV |  2-way set associative 16 kB level one instruction and data caches, and 512 kB unified level two cache |  1 GB LPDDR2 |  16GB A1 Type 10 SandDisk Ultra
10 |  Raspberry Pi Model B+ |  1.2 |  BCM2835 |  700 MHz single-core 32 bit ARM 1176JZF-S |  400 MHz Broadcom VideoCore IV |  2-way set associative 16 kB level one instruction and data caches, and 128 kB unified level two cache |  500 MB LPDDR2 |  16GB A1 Type 10 SandDisk Ultra
10 |  Raspberry Pi Zero |  1.3 |  BCM2835 |  1 GHz single-core 32 bit ARM 1176JZF-S |  400 MHz Broadcom VideoCore IV |  2-way set associative 16 kB level one instruction and data caches, and 128 kB unified level two cache |  500 MB LPDDR2 |  16GB A1 Type 10 SandDisk Ultra

All devices of the setup have identical software images, using Raspbian 10
(buster) 32 bits as OS and Linux kernel 5.4.83. The only variation in the
kernel version is related to the core architecture of each device model, ARMv6
for RPi1/Zero, ARMv7 for RPi3, and ARMv8 for RPi4.

Besides, to reduce physical context as much as possible, all devices are
located in the same lab room with identical cases and aluminum heat sinks.

###  3.2 Monitored Components

For reliable time/performance measurements of hardware components, the ideal
setup is to use as reference a physical oscillator independent of the
component being measured (the frequency of the component is not dependent on
the reference oscillator). RPi devices include all the main processing
components present in a normal computer, including oscillators. However, the
number of physical crystal oscillators is reduced to save costs. RPi4 only
includes a SoC base oscillator running at 54 MHz and an oscillator for the
USB/Ethernet controllers running at 25 MHz. In contrast, RPi3/1/Zero only
include one SoC base oscillator running at 19.2 MHz. Then, each component runs
at a different frequency using Phase-Locked Loops (PLLs) for base frequency
multiplication [26].

This condition implies that some auxiliary components which could be used as
reference points, such as the Real-Time Clock (RTC), are simulated. This fact
makes it hard to accurately measure the performance and skew of the system
from the device itself, as a skew in the CPU timing will affect the time
measurements that it is doing of itself.

However, each component can still show performance differences based on the
multiplication factor applied to the base crystal oscillator frequency in the
associated PLLs. For this reason, each component used to measure the
performance of the device is monitored from another component of the device,
measuring, in turn, the possible imperfections and deviations between the
components. More clearly, for example, the performance of code execution on
the CPU is measured in terms of GPU cycles and vice versa.

Following the previous approach, the components whose performance are
monitored and stored in the dataset are:

  * •

CPU. The execution time of code run in the CPU is measured by monitoring how
many GPU cycles have elapsed during that period of time. In this way, the skew
between CPU and GPU can be accurately measured. Therefore, the formula to
measure CPU performance based on GPU cycle variation is:

$CPU_{perf.}=\Delta GPU_{cycle\\_counter}\vdash t_{cpu\\_code\\_exec}$ (1)

  * •

GPU. In the GPU, the performance of code executed in this component is
measured using CPU-based time, just the opposite way to the previous case.

$GPU_{perf.}=\Delta CPU_{cycle\\_counter}\vdash t_{gpu\\_code\\_exec}$ (2)

  * •

Memory. Here, memory read/write operations are also monitored in terms of CPU-
based timing, as the RAM chip in RPi has its own functioning frequency
different to both the CPU and GPU.

$Memory_{perf.}=\Delta CPU_{cycle\\_counter}\vdash t_{mem\\_ops}$ (3)

  * •

Storage. Storage performance measurement is done by input/output operations in
the SD card attached to the device with the software image.

$Storage_{perf.}=\Delta CPU_{cycle\\_counter}\vdash t_{io\\_ops}$ (4)

###  3.3 Benchmark Implementation

The LwHBench benchmark code is available in [9]. The data collection program
has been implemented using Python 3, so it can be executed as a portable
script on any device with the required libraries installed. Besides, this
selection has also been influenced by the set of libraries available for CPU
and GPU low-level interaction, as it is explained below.

For the GPU low-level interaction and register monitoring, Idein py-videocore
[27] and py-videocore6 [28] are employed for VideoCore IV and VideoCore VI
GPU-based devices, respectively. To measure GPU cycles, different registers
should be considered depending on the GPU version. In particular, the register
monitored in VideoCore VI is CORE_PCTR_CYCLE_COUNT, while in VideoCore IV the
monitored registers are the performance counters 13-19 [29].

When accessing the CPU cycle counter, there are two different possibilities.
The first is to generate a kernel module to enable reading the cycle counter
from userspace. The second consists of using the interfaces provided by
performance monitoring tools such as perf. In the code, both approaches are
tested.

Regarding the kernel module, the CPU cycle counter is stored in ARMv7 and
ARMv8 AArch32 processors using c15 Cycle Counter Register (CCNT) and, by
default, it can only be read in kernel space. Therefore, a custom kernel
module is implemented to allow access to this register (enable_ccr folder in
[9]). Once compiled, the kernel module should be loaded using insmod command
with root privileges. Finally, the register can be read using the assembly
operation MRC p15, 0, <Rd>, c15, c12, 1, where <Rd> represents the variable
where to store the register value. To access perf time counting, the easiest
method is to use the time built-in Python library, which includes
perf_counter_ns() function to retrieve time in nanoseconds using the previous
counter. After some experimentation, it was decided to follow the perf-based
approach due to its simplicity compared to using a kernel module and assembly
code, and its similar consistency in the performance measurements.

Moreover, to automatize the data collection process, a system service has been
implemented (data_collection.service in the code folder). This service is in
charge of the automated data collection script launching and periodic system
rebooting in order to reduce the noise introduced by possible factors related
to the system running time. Concretely, each device is rebooted after 800
samples are collected.

###  3.4 Device Setup for Component Stability and Isolation

One of the most critical aspects of collecting reliable samples is to ensure
that the conditions in the device are as constant as possible, reducing
potential sources of noise in the samples. To this end, a number of measures
are taken to counteract the impact of other processes running on the device.
Specifically, the measures implemented to ensure stability are:

  * •

Fixed CPU/GPU/RAM frequency. By default, the kernel dynamically manages the
frequency of the device components to save energy when no high task load is
present. However, this dynamicity affects to the stability of the performance
measurements. Therefore, a fixed frequency is required in the components to
measure. In RPi, the frequency of the components can be set to be constant at
the maximum using turbo_mode=1 boot option. Besides, if only a fixed CPU
frequency is wanted, performance can be used as scaling_governor option.

  * •

Kernel level priority. Enabling a high priority for the data collection
process minimizes the interruptions caused by other programs, removing noise
and inaccurate measurements. The best option here is to set the process with
the highest scheduling priority. If root privilege is available, using the
command chrt --rr XX when launching the program enables the “real-time
scheduling” of the process, just like a kernel process. If it is not possible
to use kernel priority, another option is to use nice -n -20 to set the
maximum user level priority.

  * •

Disable Memory Address Space Layout Randomization (ASLR). Memory random
address organization can affect the stability of memory-related measurements;
therefore, this characteristic was disabled during data collection. It can be
done using sysctl kernel.randomize_va_space=0 command, but note that this
should be only enabled during memory-related data acquisition, as having ASLR
disabled increases the facility to perform memory-based attacks such as buffer
overflows.

  * •

Profiled Guided Optimization (PGO). PGO is a compiler option intended to
improve runtime performance based on static program analysis of code. Python
interpreter can be compiled to use PGO by using –enable-optimizations option.
Furthermore, Python garbage collector is also disabled to avoid unintended
tasks during the execution.

  * •

Fixed hash seed. As hash-based CPU performance measurements are generated,
using a fixed seed improves the deterministic characteristics of the function.
This is set using PYTHONHASHSEED=0 (or any other number) as environment
variable when running the data collection script. This option should only be
used for benchmark, as it can lead to an attacker causing a Denial-of-Service
(DoS) by using worst-case performance inputs to the function, which have
$O(n^{2})$ complexity.

  * •

Core isolation. For the multi-core CPU devices, e.g. RPi3 and RPi4, one core
is isolated from the rest to execute the benchmark on it using cpu affinity.
This setup avoids the (kernel) interruptions caused by other processes running
in the same CPU core while the data is being generated. Concretely, the kernel
options employed were: i) isolcpus, to avoid the kernel to schedule any
process in that core; ii) nohz_full, to tell the kernel to remove as much
kernel noise as possible, such as tick interrupts; and iii) rcu_nocbs, to
offload Read-Copy-Update (RCU) threads and callbacks.

##  4 LwHBench Benchmark and Dataset

This section details the operations executed by the benchmark and the events
collected as features for the generation of the dataset associated with this
paper. Note that this list can be updated by any other researcher just
changing the code of the benchmarking script [9].

As detailed in Section 3, the components leveraged for benchmarking are: CPU,
GPU, Memory and Storage. They have been selected because they are the most
common hardware elements in any SBC (and generic computer). Table 3 shows the
list of features collected for each device component. As it can be
appreciated, any of the operations measures typical processing power metrics
such as GFLOPS. This is because they are not well suited for low-level
component characterization. Besides, they have already been gathered in
several previous studies, as shown in Section 2. Concretely, the operations
implemented as proof of concept are:

  * •

CPU. Different sleep times (from 1 to 120 seconds) are monitored, trying to
measure the accuracy for time keeping in the component. Additionally, some
quick-execution functions are monitored: hash calculation of a string,
pseudorandom number generation, random number generation using /dev/urandom
interface, and Fibonacci number calculation.

  * •

GPU. Three simple operations are monitored in terms of CPU time: a matrix
multiplication, a matrix summation and the processing of a graphic shadow.

  * •

Memory. The operations executed are the generation of a list object with 1000
integers, the reserve of 100 MB of data and the time to read a 500 kB csv
file. These operations are measured also in terms of CPU time and represent 3
features in the generated data vector.

  * •

Storage. 100 read and write operations of 100 kB of data are monitored in the
device SD card, generating 200 features in total.

In the dataset [10], each value of Table 3 represents one feature in the
vectors (each dataset entry). Besides, each vector ends with the MAC address
of the device, which can be used as the label in supervised ML/DL tasks. The
data of each device is stored in a csv file, whose name is the MAC address.
Additionally, a text file named MAC-Model.txt contains the association between
the MAC and the model of each device in the testbed.

Table 3: Features gathered during data collection. Component |  Function |  Monitored Feature
---|---|---
- |  timestamp |  Unix timestamp
|  temperature |  Device core temperature
CPU |  1 s sleep |  GPU cycles elapsed during 1 second CPU sleep
|  2 s sleep |  GPU cycles elapsed during 2 seconds CPU sleep
|  5 s sleep |  GPU cycles elapsed during 5 seconds CPU sleep
|  10 s sleep |  GPU cycles elapsed during 10 seconds CPU sleep
|  120 s sleep |  GPU cycles elapsed during 120 seconds CPU sleep
|  string hash |  GPU cycles elapsed during a fixed string hash calculation
|  pseudo random |  GPU cycles elapsed while generating a software pseudo-random number
|  urandom |  GPU cycles elapsed while generating 100 MB using /dev/urandom interface
|  fib |  GPU cycles elapsed while calculating Fibonacci number for 20 using the CPU
GPU |  matrix mul |  CPU time taken to execute a GPU-based matrix multiplication
|  matrix sum |  CPU time taken to execute a GPU-based matrix summation
|  scopy |  CPU time taken to execute a GPU-based graph shadow processing
Memory |  list creation |  CPU time taken to generate a list with 1000 elements
|  mem reserve |  CPU time taken to fill 100 MB in memory
|  csv read |  CPU time taken to read a 500 kB csv file
Storage |  read x100 |  100 CPU time measurements for 100 kB storage read operations
|  write x100 |  100 CPU time measurements for 100 kB storage write operations

For data collection purposes, an additional Linux service has been developed
(data_collection.service). It is in charge of launching LwHBench when the
device is booted and it takes care of rebooting the device once 800 samples
have been collected. This reboot is done to minimize the possible impact of
running time in the collected data (e.g. memory usage of persistent
processes). Figure 1 shows the flow diagram of the data collection performed
in each device.

Figure 1: LwHBench data collection flow diagram.

A total of 2386126 vectors are available in the dataset, making 4 GB of data.
Figure 2 shows the number of samples per hour from each device model during
the data collection period. It can also be seen how some devices went offline
during the data collection, corresponding to each of the downward jumps shown
in the RPi4 and RPi3 graphs. The dataset contains per device model: 505584
samples of RPi 1B+, 784095 samples of RPi4, 547800 samples of RPi3 and 548647
samples of RPiZero. With more than two million vectors, the present dataset is
the one with the highest number of samples among those found in the IoT
benchmarking literature. Besides, Figure 3 shows the number of samples per
device contained in the dataset. The number varies according to the device
model, as more powerful ones generate more data in the same time. Besides,
some devices suffered power outages during data collection or they were added
lately to the set of available devices. Still, on average, more than 50000
vectors per device are present. It can also be seen that 5 devices have less
data due to interruptions during the data collection process.

Figure 2: Samples per hour generated from each device model. Figure 3: Samples
per device contained in the dataset.

##  5 Data Exploration and Use Cases

This section explores the dataset described in the previous section. For that
purpose, a set of ML/DL-based use cases for network and device management are
presented using the data available. Note that the purpose of this section is
to show the usefulness of the benchmarking application and the data collected
with it, not to find the best solution to the problems proposed as
illustrative examples.

###  5.1 Model/Individual Identification

The first use case where the dataset (and LwHBench benchmark to generate new
data) can be applied is in device identification based on the performance of
its device components. This can be a critical task in environments where the
devices can be impersonated by malicious ones with new hardware or software
configurations [30]. In this sense, this use case can be seen from two
different perspectives: identification of the device model, a relatively
straightforward task from the data measuring the performance of each hardware
component, as different hardware will have different performance values; and
individual identification of each device, a more complex task since to
uniquely identify devices with identical software and hardware it is necessary
to analyze the differences and imperfections in the chips of each device.

####  5.1.1 SBC model Identification

For this first perspective, a ML/DL-based dimensionality reduction and
clustering approach [31] is followed to group together the data from each
device model. This approach is selected due to its proven efficacy for
automated class inference and identification in unlabeled data applied in many
research areas, such as network-based IoT device type inference [32],
intrusion detection [33] or even biology [34].

As a proof of concept, it is decided to apply clustering to all CPU, GPU,
memory and storage features, discarding timestamps and temperature. As
clustering algorithms, several options are tested, concretely PCA, t-SNE and
umap, reducing the number of dimensions to two. So, the resultant data can be
easily plotted for result explainability. Regarding clustering, k-means and
DBSCAN (Density-Based Spatial Clustering of Applications with Noise)
algorithms are applied over the data once the dimensions have been reduced to
two. As the number of device models is previously known, the number of
clusters in the algorithm configuration is set to four.

Figure 4 shows the results when the combination of PCA with k-means clustering
is applied as data processing approach. Different configurations of
dimensionality reduction and clustering algorithms gave similar results. It
can be seen how four different groups in the data emerge clearly separated,
and how the clustering algorithm is able to associate the points successfully.
To verify that the clustering is correct, the number of instances assigned to
each of them is compared with the number of samples in the dataset belonging
to each device model, as also portrayed in Figure 2. Thus, the results are:

  * •

Cluster 0: 784095 samples, which coincides with the samples of RPi4.

  * •

Cluster 1: 505584 samples, which coincides with the samples of RPi1.

  * •

Cluster 2: 547800 samples, which coincides with the samples of RPi3.

  * •

Cluster 3: 548647 samples, which coincides with the samples of RPiZero.

From the above results, it can be concluded that LwHBench benchmark and
dataset can be applied to solve the model identification problem. This
approach has performed perfectly, since the number of samples in each cluster
matches one of the RPi models deployed in the testbed. Moreover, it can be
seen how Cluster 2 (green color) has its values much more concentrated than
Clusters 0 and 3 (blue and red), which indicates higher stability in the
values of this type of device.

Figure 4: PCA-based dimensionality reduction with k-means clustering.

####  5.1.2 Individual Identification

In this case, the objective is to uniquely identify each one of the 45 devices
used for dataset generation. Here, an ML/DL-based classification approach is
followed due to its demonstrated performance in IoT device identification
tasks [35, 36].

For this task, all the features available in the dataset regarding components
are used, and in this case, it is also included the temperature as a feature,
since the correlation between this and the performance of each component can
be one of the patterns that the ML/DL algorithm could detect when identifying
each device individually. Besides, the storage-related features, 100
measurements for read time and 100 for write, are preprocessed, calculating
the average, median, minimum and maximum for each feature group. As the number
of devices to be identified is fixed, the 45 devices used to generate the
dataset, ML/DL classification techniques [37] are used to identify each SBC.
Therefore, the following techniques are compared: Decision Tree (DT), Random
Forest (RF), XGBoost, k-Nearest Neighbors (k-NN), Naive Bayes (NB), Support
Vector Machine (SVM) and Multi-Layer Perceptron (MLP). For k-NN, NB, SVM and
MLP, normalization is applied using min-max :
$x=\frac{x-x_{min}}{x_{max}-x_{min}}$. The dataset is split into 80% of the
data for training and cross-validation, and 20% for testing. Table 4 shows the
Precision, Recall and F1-Score [38] per algorithm. As it can be seen, XGBoost
is the algorithm providing the best results, with a 0.97 in Precision, Recall
and F1-Score.

Table 4: Device identification results. Algorithm | Hyperparameters | Precision | Recall | F1-Score
---|---|---|---|---
DT | $max\\_depth=None$ | 0.88 | 0.88 | 0.88
RF | $n\\_estimators=100$ | 0.93 | 0.93 | 0.93
XGBoost |  $lr=0.1,gamma=0.01$ $max\\_depth=20$ | 0.97 | 0.97 | 0.97
k-NN | $k=7$ | 0.32 | 0.32 | 0.31
NB | - | 0.20 | 0.17 | 0.12
SVM |  $kernel=linear,$ $gamma=0.01$ | 0.50 | 0.51 | 0.50
MLP |  1 relu hidden layer, 50 neurons | 0.58 | 0.57 | 0.56
Figure 5: Individual device identification confusion matrix.

Moreover, Figure 5 shows the confusion matrix for the 45 devices involved in
the identification use case. Note that the RPi model has been added at the
beginning of each label to have the devices ordered by model in the image. The
results in this use case are satisfactory, as the minimum accuracy in all
devices is 0.88, having more than 0.93 in most of them. Therefore, it can be
concluded that the collected features are suitable for individual device
identification.

Furthermore, more complex approaches could be applied to perform individual
device identification depending on the scenario requirements. For example,
applying time series approaches or advanced DL models such as LSTM (Long
Short-Term Memory) or Transformer networks. One example of these solutions can
be found in [39], where similar features to the ones collected about CPU
performance were employed to differentiate 25 Raspberry Pi devices. In this
case, a sliding window approach is used for vector preprocessing,
incorporating new statistical information as features for the ML/DL
classifier.

###  5.2 Performance Analysis

The second use case where the benchmark and dataset can be applied is in the
comparison of the performance of each device hardware component. This
comparison can be seen from two different areas: intra-device comparison,
where contextual circumstances such as temperature are analyzed to evaluate
their impact on the device performance; and inter-device comparison, where
components from different devices, but from the same model and in similar
context conditions, are compared to find performance variations based on
manufacturing variations.

####  5.2.1 Intra-device Performance Analysis

One intra-device use case where the collected dataset can be applied is in the
analysis of the impact of temperature variations on the performance of the
different device models and their components. This is another research area
with a large interest in recent years [40] due to the deployment of SBC in a
wide variety of critical scenarios.

For this use case, one of the devices available in the dataset is randomly
selected and the impact of temperature on the other hardware-related metrics
is analyzed. As the impact of temperature may vary according to the device
model, one device per model is selected. Besides, only the first feature
regarding storage read and write performance (storage_read_1 and
storage_write_1) are analyzed. In order to test the impact of temperature
value on the other features, the correlation between the temperature feature
and the other features is studied. The correlation has values between 1 and -1
depending on whether the features increase their value linearly and
positively, or inversely and proportionally.

Figure 6 shows the correlation values for four different devices, one per
available model. It can be appreciated how the RPi3 shows a high sensitivity
to temperature in almost all features, only the ones based on sleep function
execution seems to have a stable performance. This analysis has been repeated
with the rest of the RPi3 devices to ensure that it was not a failure in one
of them, with all the devices of this model showing very similar correlation
graphs. In contrast, the rest of the models show much lower sensitivity to
temperature changes, with values close to zero that only vary around $\pm$0.05
in certain cases and devices.

Figure 6: Temperature correlation plot.

Thus, from this use case it can be concluded that the RPi3 devices used for
the generation of the dataset are the model with the highest sensitivity to
temperature changes, as the correlation of this feature with the rest is high
in some cases. This fact is interesting for deployments where the physical
environment conditions are changing, but the performance is expected to remain
stable over time.

Another interesting use case of intra-device analysis is the analysis of how
the performance of a device can drop over time due to component wear and tear.
For this use case, data needs to be collected over a long period of time. In
the case of the available dataset, a total of 100 days (from 6th December 2021
to 17th March 2022) of data have been collected, so although it is not an
extensive period, it could give clues about component and device aging.

####  5.2.2 Inter-device Performance Analysis

The last use case to be explored is the analysis of the performance variations
of different hardware components within devices of the same model. This use
case is closely related to individual identification, since it is the
performance variations between devices of the same model that can be used to
characterize each device separately.

To analyze this use case, the distribution densities of different features for
devices of the same model are plotted. As a proof of concept, the selected
model is the RPi4 and one feature from each component is shown: cpu_sleep_120s
for the CPU, gpu_matrixmul for the GPU, storage_read_1 for the memory/storage,
and storage_write_1 for the storage. Although identical experiments could be
performed for the other models, these are omitted for document space reasons.

Figure 7 shows the density plots for each feature. Some interesting patterns
can be appreciated in these plots. First, it can be seen how for the features
gpu_matrixmul (Figure 7(b)) and storage_read_1 (Figure 7(c)) the distributions
are quite stable between the devices and all of them show similar shapes.
However, cpu_sleep_120s (Figure 7(a)) exhibits how each device has a Gaussian
distribution centered in a different value, demonstrating that some
performance variations are present within the device model. A similar
situation is found with storage_write_1 (Figure 7(d)) feature, but in this
case, the distribution plots tend to have two distinctive center values, and
each device sticks to one of them (except for the dark green one with MAC
dc:a6:32:14:a8:d8 that has a higher value, although the distribution shape is
similar to the rest).

(a) CPU_sleep_120s density plot.

(b) gpu_matrixmul density plot.

(c) storage_read_1 density plot.

(d) storage_write_1 density plot.

Figure 7: Raspberry Pi 4 feature density plots.

From this use case, it can be concluded that performance variations are
present within each device model depending on the exact device. So, it has
been shown that although hardware specifications may be identical, chips
contain variations that can be leveraged to perform fingerprinting or
identification tasks.

##  6 Real-world Deployment in an Agriculture Scenario

This section shows the benchmark adaptation and deployment into a real-world
IoT environment based on SBC devices. Here, the aim is to show the use case
applicability of the proposed solution as well as its adaptability process to
other SBC models.

In this sense, an IoT sensor network for agriculture has been considered,
being the sensors controlled by three PINE64 RockPro64 devices. In this
scenario, the administrator wants to keep control of the environment,
monitoring the performance of the devices during run time while keeping them
identified based on their manufacturing variations. Each device includes a
6-core CPU: 4 x ARM Cortex A53 cores @ 1.4GHz + 2 x ARM Cortex A72 cores @ 1.8
GHz; as GPU it features ARM Mali T860; and 2GB LPDDR4 RAM. As operating
system, they use 64 bit armbian (Debian-based Linux for ARM).

As the GPU is different to the ones included in RPi devices, the code needed
to be adapted to gather the counters from the ARM Mali T860 GPU. Concretely,
the GPU_ACTIVE counter was selected from the ones available [41]. For cycle
counter collection, ARM HWCPipe library [42] has been employed. For the CPU-
based time gathering, perf time is gathered in the same way that for RPi
devices, using the perf_counter_ns() function. The functions executed are the
same as the ones depicted in Table 3, adapted in the case of the GPU to the
new hardware using the ARM Compute Library [43]. The code is also available in
[9].

For experimentation purposes, the code was deployed on the three identical
devices during one week. $\approx$35.9 MB of data were collected, with a total
of $\approx$12800 vector samples (around 4000 per device). After the data were
gathered, the approaches shown in Section 5 were implemented to monitor the
performance differences between devices and perform individual identification.
Figure 8 shows the distribution plot for the CPU_sleep_120s feature. As it can
be seen, the three devices distributions are clearly differentiated between
each other. Therefore, the classification results, using the same algorithms
as the ones depicted in Table 4, are perfect, giving 100% F1-Score and
accuracy.

Figure 8: RockPro64 SBC CPU_sleep_120s density plot.

This real-world deployment demonstrates how the benchmarking application can
be adapted and deployed in new SBC models with a relatively low effort,
enabling the performance analysis of the devices where the application is
deployed. This performance analysis enables different use cases, such as
individual identification, to be applied in the scenario.

##  7 Discussion

This section seeks to analyze the main advantages and weaknesses of the
proposed benchmarking application and the associated dataset, highlighting the
main lessons learned during the work development. From the advantages point of
view, it is worth noting the next aspects:

  * •

An important literature gap has been covered. As Section 2 shows, there is no
low-level benchmarking application for SBC devices, enabling precise hardware
analysis, nor any dataset regarding low-level SBC performance. The present
work has partially covered these issues with the implementation of the
benchmarking application and the release of a large dataset collected for 100
days.

  * •

Demonstrated utility for ML/DL-based use cases. The collected dataset has been
validated in a set of realistic use cases related to AI-based service
management, mainly regarding device identification. Thus, it has been shown
the utility of the benchmark when it comes to maintain under control an IoT
environment where device fingerprinting is critical.

  * •

The benchmark is easy to deploy and extend in other RPi-based environments.
The LwHBench benchmark code is completely open-source [9], so other
researchers and system administrators can execute it in their own scenarios
just by installing the required dependencies. This fact also allows for the
extension of the benchmark with new metrics according to the requirements of
other scenarios or the available hardware.

Besides, from the drawback perspective, the next points have importance,
mainly in future related research:

  * •

Hardware-based implementation. LwHBench leverages CPU and GPU cycle counters,
which accessed to monitor the performance of other components. Therefore, the
implementation for new SBC models may require deep hardware study and
understanding. For example, to access to the GPU cycle counter in a new GPU
model, it would be needed to read the documentation and try the specific
hardware drivers.

  * •

The collected metrics are not directly applicable for traditional
benchmarking. CPU performance is measured in terms of GPU cycles, an unusual
metric that is not very representative of the actual hardware performance when
executing high-level tasks. Moreover, the differences between devices from the
same model can come both from the measured or the measuring device, so it is
difficult to measure where the chip imperfections are actually located.

  * •

Component isolation might reduce device performance. The dataset has been
collected while executing LwHBench in an isolated core, when possible (RPi3
and RPi4), and reducing the kernel interruptions from other processes to the
maximum. Although the other cores can be used without performance limitations,
isolating one core can downgrade the performance of critical tasks running in
the SBC at the same time. Therefore, further experimentation with weaker
isolation measurements can be interesting to know the impact of other
processes on the collected values.

This work proposes the only low-level benchmark available in recent
literature, and its usefulness has been validated through a series of ML/DL-
enabled use cases, which are exciting topics for future IoT-based network and
service management solutions. However, as this section details, the proposed
solution has room for improvement regarding adaptation to other SBC models.

##  8 Conclusions and Future Work

This work has presented a low-level hardware component benchmarking
application for SBC, namely LwHBench. It measures the performance of the CPU,
GPU, Memory and Storage of the devices using other self-contained components.
This approach ensures that the metrics collected are reliable and non-
dependent on the imperfections of the component being measured. The benchmark
has been implemented for Raspberry Pi devices, for all the models currently
available in the market, from RPiZero to RPi4. In order to ensure optimal
measurement stability, every possible action that can help to reduce the noise
introduced by other programs running on the device has also been considered,
such as isolating the core where the benchmark is running or blocking kernel
interrupts.

In addition to the application implementation, an exhaustive dataset has been
collected from running LwHBench benchmark on a set of 45 devices over 100
days, which contains more than 2 million vectors and 4 GB of data.
Subsequently, to explore the available data and show possible areas of use, a
series of use cases have been described and partially solved, reflecting the
real needs of an environment whose management integrates modern AI-based
solutions. These use cases have been divided into two groups: one on device
identification, where it has been shown that using LwHBench it is possible to
identify both the model and each device individually; and another on
performance analysis, where the possible impact of temperature on hardware
performance as well as the variations between devices of the same model have
been studied.

As conclusions wrap up, the previous contributions intend to advance state of
the art regarding system and device management, as it enables new solutions
that, based on low-level hardware benchmarking and ML/DL techniques, improve
the control over the devices deployed in modern networking environments, such
as 5G-based industries.

As future work, it is planned to adapt the benchmarking application to other
SBC models in order to collect data from them and perform more in-depth
experiments regarding single-device identification and performance impact of
temperature and device aging. Moreover, the benchmarking application will
continue being executed in the current devices, generating more data in order
to analyze new use cases such as device and component aging. Finally, as
further research line, it is planned to integrate the benchmarking application
with federated learning techniques, so the data is processed directly in the
device according to the use case, without requiring to take the data outside
the SBC device.

## Acknowledgment

This work has been partially supported by (a) the Swiss Federal Office for
Defense Procurement (armasuisse) with the TREASURE and CyberSpec
(CYD-C-2020003) projects and (b) the University of Zürich UZH.

## References

  * [1] Roger W Hockney.  The science of computer benchmarking.  SIAM, 1996.
  * [2] Blesson Varghese, Nan Wang, David Bermbach, Cheol-Ho Hong, Eyal De Lara, Weisong Shi, and Christopher Stewart.  A survey on edge performance benchmarking.  ACM Computing Surveys (CSUR), 54(3):1–33, 2021.
  * [3] Lizy Kurian John and Lieven Eeckhout.  Performance evaluation and benchmarking.  CRC Press, 2018.
  * [4] P. M. Sánchez Sánchez, J. M. Jorquera Valero, A. Huertas Celdrán, G. Bovet, M. Gil Pérez, and G. Martínez Pérez.  A survey on device behavior fingerprinting: Data sources, techniques, application scenarios, and datasets.  IEEE Communications Surveys Tutorials, 23(2):1048–1077, 2021.
  * [5] Christopher Michael Wyant, Christopher Robert Cullinan, and Timothy Richard Frattesi.  Computing performance benchmarks among CPU, GPU, and FPGA.  Computing, 2012.
  * [6] Shi Dong, Ping Wang, and Khushnood Abbas.  A survey on deep learning and its applications.  Computer Science Review, 40:100379, 2021.
  * [7] Xingzhou Zhang, Yifan Wang, and Weisong Shi.  pCAMP: Performance comparison of machine learning packages on the edges.  In USENIX Workshop on Hot Topics in Edge Computing (HotEdge 18), 2018.
  * [8] Stephan Patrick Baller, Anshul Jindal, Mohak Chadha, and Michael Gerndt.  DeepEdgeBench: Benchmarking deep neural networks on edge devices.  In 2021 IEEE International Conference on Cloud Engineering (IC2E), pages 20–30, 2021.
  * [9] P. M. Sánchez Sánchez.  LwHBench benchmarking application for Raspberry Pi.  https://github.com/sxz0/LwHBench, 2021.  [Online; accessed 8-March-2022].
  * [10] Pedro Miguel Sánchez Sánchez, José María Jorquera Valero, Alberto Huertas Celdrán, Gérôme Bovet, Manuel Gil Pérez, and Gregorio Martínez Pérez.  LwHBench dataset, 2022.  IEEE DataPort.
  * [11] Ivan Grasso, Petar Radojkovic, Nikola Rajovic, Isaac Gelado, and Alex Ramirez.  Energy efficient HPC on embedded SoCs: Optimization techniques for Mali GPU.  In 2014 IEEE 28th International Parallel and Distributed Processing Symposium, pages 123–132, 2014.
  * [12] Michael F Cloutier, Chad Paradis, and Vincent M Weaver.  A Raspberry Pi cluster instrumented for fine-grained power measurement.  Electronics, 5(4):61, 2016.
  * [13] Ankur Limaye and Tosiron Adegbija.  HERMIT: A benchmark suite for the internet of medical things.  IEEE Internet of Things Journal, 5(5):4212–4222, 2018.
  * [14] Anirban Das, Stacy Patterson, and Mike Wittie.  EdgeBench: Benchmarking edge computing platforms.  In 2018 IEEE/ACM International Conference on Utility and Cloud Computing Companion, pages 175–180, 2018.
  * [15] Jonathan McChesney, Nan Wang, Ashish Tanwer, Eyal de Lara, and Blesson Varghese.  DeFog: Fog computing benchmarks.  In 4th ACM/IEEE Symposium on Edge Computing, pages 47–58, 2019\.
  * [16] Klervie Toczé;, Norbert Schmitt, Ulf Kargén, Atakan Aral, and Ivona Brandić.  Edge workload trace gathering and analysis for benchmarking.  In 2022 IEEE 6th International Conference on Fog and Edge Computing (ICFEC), pages 34–41, 2022.
  * [17] Daniel Hawthorne, Michael Kapralos, Raymond W Blaine, and Suzanne J Matthews.  Evaluating cryptographic performance of Raspberry Pi clusters.  In 2020 IEEE High Performance Extreme Computing Conference (HPEC), pages 1–9, 2020.
  * [18] A. S. Uluagac.  CRAWDAD dataset gatech/fingerprinting (v. 2014-06-09).  https://crawdad.org/gatech/fingerprinting/20140609, 2014.  [Online; accessed 31-March-2022].
  * [19] A. K. Hagelskjær, B. H. Grevenkop-Castenskiold, M. H. Jespersen, T. Arildsen, E. Carvalho, and P. Popovski.  IoT device identification dataset.  https://doi.org/10.5281/zenodo.3638165, April 2020.  [Online; accessed 31-March-2022].
  * [20] Philip J Basford, Steven J Johnston, Colin S Perkins, Tony Garnock-Jones, Fung Po Tso, Dimitrios Pezaros, Robert D Mullins, Eiko Yoneki, Jeremy Singer, and Simon J Cox.  Performance analysis of single board computer clusters.  Future Generation Computer Systems, 102:278–291, 2020.
  * [21] Yang Su, Yansong Gao, Surya Nepal, and Damith C. Ranasinghe.  NoisFre: Noise-tolerant memory fingerprints from commodity devices for security functions, 2021.  IEEE DataPort.
  * [22] Flávio Ramalho and Augusto Neto.  Virtualization at the network edge: A performance comparison.  In 2016 IEEE 17th International Symposium on A World of Wireless, Mobile and Multimedia Networks (WoWMoM), pages 1–6, 2016.
  * [23] K. Wright, K. M. Beck, S. Debnath, J. M. Amini, Y. Nam, N. Grzesiak, J.-S. Chen, N. C. Pisenti, M. Chmielewski, C. Collins, K. M. Hudek, J. Mizrahi, J. D. Wong-Campos, S. Allen, J. Apisdorf, P. Solomon, M. Williams, A. M. Ducore, A. Blinov, S. M. Kreikemeier, V. Chaplin, M. Keesan, C. Monroe, and J. Kim.  Benchmarking an 11-qubit quantum computer.  Nature Communications, 10(1):1–6, 2019.
  * [24] Yansong Gao, Yang Su, Surya Nepal, and Damith C Ranasinghe.  NoisFre: Noise-tolerant memory fingerprints from commodity devices for security functions.  arXiv preprint arXiv:2109.02942, 2021.
  * [25] Gianmarco Baldini.  Iot transient radio frequency signals, 2020.  IEEE DataPort.
  * [26] Embedded Linux Wiki.  The undocumented Pi.  https://elinux.org/The_Undocumented_Pi, 2021.  [Online; accessed 8-March-2022].
  * [27] Idein.  py-videocore. Python library for GPGPU on Raspberry Pi.  https://github.com/nineties/py-videocore/, 2021.  [Online; accessed 8-March-2022].
  * [28] Idein.  py-videocore6. Python library for GPU programming on Raspberry Pi 4.  https://github.com/Idein/py-videocore6/, 2021.  [Online; accessed 8-March-2022].
  * [29] Broadcom.  VideoCore IV 3D architecture reference guide.  https://docs.broadcom.com/doc/12358545/, 2013.  [Online; accessed 30-March-2022].
  * [30] Leonardo Babun, Hidayet Aksu, and A Selcuk Uluagac.  CPS device-class identification via behavioral fingerprinting: From theory to practice.  IEEE Transactions on Information Forensics and Security, 16:2413–2428, 2021.
  * [31] Hans-Peter Kriegel, Peer Kröger, Erich Schubert, and Arthur Zimek.  A general framework for increasing the robustness of PCA-based correlation clustering algorithms.  In International Conference on Scientific and Statistical Database Management, pages 418–435, 2008.
  * [32] Arunan Sivanathan, Hassan Habibi Gharakheili, and Vijay Sivaraman.  Inferring IoT device types from network behavior using unsupervised clustering.  In 2019 IEEE 44th Conference on Local Computer Networks (LCN), pages 230–233, 2019.
  * [33] Liqun Liu, Bing Xu, Xiaoping Zhang, and Xianjun Wu.  An intrusion detection method for internet of things based on suppressed fuzzy clustering.  EURASIP Journal on Wireless Communications and Networking, 2018(1):1–7, 2018.
  * [34] Daniel Granato, Jânio S Santos, Graziela B Escher, Bruno L Ferreira, and Rubén M Maggio.  Use of principal component analysis (PCA) and hierarchical cluster analysis (HCA) for multivariate association between bioactive compounds and functional properties in foods: A critical perspective.  Trends in Food Science & Technology, 72:83–90, 2018.
  * [35] Arunan Sivanathan, Hassan Habibi Gharakheili, Franco Loi, Adam Radford, Chamith Wijenayake, Arun Vishwanath, and Vijay Sivaraman.  Classifying IoT devices in smart environments using network traffic characteristics.  IEEE Transactions on Mobile Computing, 18(8):1745–1759, 2018.
  * [36] Ivan Cvitić, Dragan Peraković, Marko Periša, and Brij Gupta.  Ensemble machine learning approach for classification of IoT devices in smart home.  International Journal of Machine Learning and Cybernetics, 12(11):3179–3202, 2021.
  * [37] Aized Amin Soofi and Arshad Awan.  Classification techniques in machine learning: applications and issues.  Journal of Basic and Applied Sciences, 13:459–465, 2017.
  * [38] Margherita Grandini, Enrico Bagli, and Giorgio Visani.  Metrics for multi-class classification: an overview.  arXiv preprint arXiv:2008.05756, 2020.
  * [39] Pedro Miguel Sánchez Sánchez, José María Jorquera Valero, Alberto Huertas Celdrán, Gérôme Bovet, Manuel Gil Pérez, and Gregorio Martínez Pérez.  Can evil IoT twins be identified? Now yes, a hardware behavioral fingerprinting methodology.  arXiv preprint arXiv:2106.08209, 2021.
  * [40] Dimitris Gizopoulos, George Papadimitriou, Athanasios Chatzidimitriou, Vijay Janapa Reddi, Behzad Salami, Osman S Unsal, Adrian Cristal Kestelman, and Jingwen Leng.  Modern hardware margins: CPUs, GPUs, FPGAs recent system-level studies.  In 2019 IEEE 25th International Symposium on On-Line Testing and Robust System Design (IOLTS), pages 129–134, 2019.
  * [41] Peter Harris.  Mali Midgard family performance counters.  https://community.arm.com/arm-community-blogs/b/graphics-gaming-and-vr-blog/posts/mali-midgard-family-performance-counters/, 2016\.  [Online; accessed 30-July-2022].
  * [42] ARM Developers.  HWCPipe.  https://github.com/ARM-software/HWCPipe, 2021.  [Online; accessed 12-September-2022].
  * [43] ARM Developers.  ARM Compute Library.  https://arm-software.github.io/ComputeLibrary/latest/index.xhtml, 2021.  [Online; accessed 12-September-2022].


#  $P_{c}$ Resonances in the Compact Pentaquark Picture

W. Ruangyoo<EMAIL_ADDRESS>K. Phumphan  C. C. Chen  School of Physics and
Center of Excellence in High Energy Physics and Astrophysics, Suranaree
University of Technology, Nakhon Ratchasima 30000, Thailand  Department of
Physics, National Cheng Kung University, Tainan, 70101, Taiwan  A. Limphirat
<EMAIL_ADDRESS>Y. Yan<EMAIL_ADDRESS>School of Physics and Center of
Excellence in High Energy Physics and Astrophysics, Suranaree University of
Technology, Nakhon Ratchasima 30000, Thailand

###### Abstract

$P_{c}$ resonances are studied in the approach of quark model and group
theory. It is found that there are totally 17 possible pentaquark states with
the quark contents $q^{3}Q\bar{Q}$ ($q$ are $u$ and $d$ quarks; $Q$ is $c$
quark) in the compact pentaquark picture, where the hidden heavy pentaquark
states may take the color singlet-singlet
($[111]_{{qqq}}\otimes[111]_{{c\bar{c}}}$) and color octet-octet
($[21]_{{qqq}}\otimes[21]_{{c\bar{c}}}$) configurations. The partial decay
widths of hidden heavy pentaquark states are calculated for all possible decay
channels. The results show that the $pJ/\psi$ is the dominant decay channel
for both the spin $3/2$ and $1/2$ pentaquark states, and indicate that the
$P_{c}(4440)$ may not be a compact pentaquark state while $P_{c}(4312)$ and
$P_{c}(4457)$ could be the spin-$\frac{1}{2}$ and spin-$\frac{3}{2}$
pentaquark states, respectively.

Group theory, Quark model, Partial decay width, Pentaquark

##  I Introduction

In 2015, the two pentaquark-like states, $P_{c}(4380)$ and $P_{c}(4450)$, were
observed for the first time at 7 and 8 TeV proton-proton collisions by the
LHCb Collaboration [1, 2]. These two $P_{c}^{+}$ states with the minimal quark
content $uudc\bar{c}$ lie in the $pJ/\psi$ invariant mass spectra in
$\Lambda_{b}^{0}\rightarrow pJ/\psi K^{-}$ decay process. Then in 2019, the
LHCb Collaboration announced the updated data of three narrow pentaquark-like
states, $P_{c}(4312)$, $P_{c}(4440)$ and $P_{c}(4457)$ [3]. In this discovery
a new structure of $P_{c}(4312)$ was observed in a lowest invariant mass
around 4312 MeV with a width of $9.8\pm 2.7^{+3.7}_{-4.5}$ MeV. The
$P_{c}(4450)$ pentaquark-like state in the previous report is actually the
result of two overlapped peaks–the $P_{c}(4440)$ and $P_{c}(4457)$. The two
peaks have the widths of $20.6\pm 4.9^{+8.7}_{-10.1}$ MeV and $6.4\pm
2.0^{+5.7}_{-1.9}$ MeV, respectively. The quantum numbers of these three
narrow $P_{c}$ states have not been confirmed by LHCb yet while
$J^{P}=\frac{1}{2}^{-}$, $J^{P}=\frac{1}{2}^{-}$, and $J^{P}=\frac{3}{2}^{-}$
are only suggested for the $P_{c}(4312)$, $P_{c}(4440)$ and $P_{c}(4457)$
states, respectively. Moreover, the LHCb has proposed a structure of the bound
state of a baryon and a meson for the $P_{c}$ states stemming from that the
masses of $P_{c}(4312)$ and $P_{c}(4457)$ states are approximately 5 MeV and 2
MeV below the $\Sigma_{c}^{+}\bar{D}^{0}$ and $\Sigma_{c}^{+}\bar{D}^{*0}$
thresholds, respectively, while $P_{c}(4440)^{+}$ is close to
$\Sigma_{c}^{+}\bar{D}^{*}$ threshold with a 20 MeV gap. At this moment, no
further conclusion for $P_{c}(4380)$ state has been arrived yet.

The molecular picture of $P_{c}$ states have been studied theoretically in
Refs. [4, 5, 6, 7, 8, 9, 10, 11, 12] resulting from the closeness of their
masses to the $\Sigma_{c}^{+}\bar{D}^{(*)0}$ threshold and the only observed
$pJ/\psi$ channel. The $P_{c}^{+}$ states are also studied as compact
pentaquarks [13, 14, 15, 16]. Various approaches have been applied in
theoretical studies, such as QCD sum rules [17, 18], simple chromomagnetic
model [19] and others. However, the nature of $P_{c}$ is still an open
question.

We study in this work the $P_{c}$ resonances in the compact pentaquark picture
using the approach of quark model and group theory. The paper is organized as
follows. In Sec. II all possible quark configurations and wave functions of
ground state hidden-charm pentaquarks are worked out by applying the $S_{3}$
permutation group. Sec. III shows the calculation of the partial decay widths
of the hidden-charm pentaquarks for all possible decay channels. Discussion is
given in Sec. IV.

##  II $P_{c}$ wave functions in compact pentaquark picture

The construction of the $P_{c}$ pentaquark states follows the rules that the
color wave function of $P_{c}$ must be singlet, and the total $P_{c}$ wave
functions should be antisymmetric under any permutation of the three light
quarks. The color wave function of the $P_{c}$ states is required to be a
${[222]_{1}}$ singlet, and the total wave function for the ground $P_{c}$
pentaquark states is

$\Psi(q^{3}c\bar{c})=\psi^{O}_{sym}\psi^{C}_{[222]}\psi^{SF},$ (1)

where $\psi^{O}$, $\psi^{C}$ and $\psi^{SF}$ are the spatial, color and spin-
flavor wave functions, respectively. The spatial wave function, $\psi^{O}$, is
fully symmetric for the ground state.

The $P_{c}$ wave function in this work can be considered in two parts, $q^{3}$
and $c\bar{c}$. For $q^{3}$ part, the permutation symmetry of the $q^{3}$ part
is characterized by the $S_{3}$ young tabloids [3], [21], [111]. The color
part of $q^{3}$ can be both the [111] and [21] configurations while the color
part of $c\bar{c}$ are also [111] and [21], so the color singlet wave
functions of $P_{c}$ states are either in a color singlet-singlet or a color
octet-octet configuration, taking the form,

$\psi^{C}_{[222]}=\left\\{\begin{array}[]{l}\psi^{C}_{[111]}(q^{3})\otimes\psi^{C}_{[111]}(c\bar{c})\\\
\psi^{C}_{[21]}(q^{3})\otimes\psi^{C}_{[21]}(c\bar{c})\end{array}.\right.$ (2)

In the color octet-octet configuration, the color wave function is composed of
eight possible octet states to be in the color singlet, taking the form,

$\psi^{C}_{[222]}=\frac{1}{\sqrt{8}}\sum^{8}_{i=1}\psi^{C}_{[21]_{i},q^{3}}\otimes\psi^{C}_{[21]_{i},c\bar{c}}.$
(3)

The $q^{3}$ part is required to be fully antisymmetric. For the color singlet-
singlet configuration, the general wave function of the $q^{3}$ part is

$\Psi_{[A]}^{singlet}(q^{3})=\psi_{[111]}^{C}\psi^{O}_{Sym}\psi_{[3]}^{SF}.$
(4)

The spin-flavor part of the $q^{3}$ cluster is in the [21] configuration for
the color octet-octet configuration, and thus the $q^{3}$ wave function is in
the form,

$\Psi_{[A]}^{octet}(q^{3})=\frac{1}{\sqrt{2}}\psi^{O}_{Sym}(\psi^{C}_{[21]_{\lambda}}\psi^{SF}_{[21]_{\rho}}-\psi^{C}_{[21]_{\rho}}\psi^{SF}_{[21]_{\lambda}}).$
(5)

The $\lambda$ and $\rho$ color wave functions are listed in Appendix A. The
possible spin-flavor configurations of the $q^{3}$ cluster, listed in Table 1,
are taken from the previous studies in Refs. [20, 21, 22, 23].

Table 1: Spin-flavor configurations of the $q^{3}$ cluster.  $[3]_{SF}$ | $[3]_{F}[3]_{S}$ | $[21]_{F}[21]_{S}$
---|---|---
$[21]_{SF}$ |  $[3]_{F}[21]_{S}$ $[21]_{F}[3]_{S}$ |  $[21]_{F}[21]_{S}$ $[111]_{F}$ $[21]_{S}$
$[111]_{SF}$ | $[21]_{F}[21]_{S}$ | $[111]_{F}[3]_{S}$

After working out the direct product of $\Psi(q^{3})$ and $\Psi(c\bar{c})$,
all the quark configurations of $P_{c}$ and corresponding states are shown in
Table 2, where $\phi$ and $\chi$ are the flavor and spin parts. The spatial
wave functions are symmetric and are not specified here. The last two
configurations with the flavor singlet in Table 2 are for the $q^{3}=uds$
light quark cluster and will not be considered in this study.

Table 2: Configurations of $P_{c}$ and possible quantum numbers. $P_{c}$ configurations |  $\Psi(q^{3})$ part $\Psi(c\bar{c})$ part | Isospin | Spin
---|---|---|---
$\Psi_{[111]_{C}[3]_{F}[3]_{S}[\chi_{1}]}$ |  $\psi^{C}_{[111]}\phi_{[3]}\chi_{[3]}\hskip 28.45274pt\otimes\hskip 28.45274pt\psi^{C}_{[111]}\phi(c\bar{c})\chi_{1}$ | $\frac{3}{2}$ |  $\frac{1}{2}$, $\frac{3}{2}$, $\frac{5}{2}$
$\Psi_{[111]_{C}[3]_{F}[3]_{S}[\chi_{0}]}$ |  $\psi^{C}_{[111]}\phi_{[3]}\chi_{[3]}\hskip 28.45274pt\otimes\hskip 28.45274pt\psi^{C}_{[111]}\phi(c\bar{c})\chi_{0}$ | $\frac{3}{2}$ | $\frac{1}{2}$
$\Psi_{[111]_{C}[21]_{F}[21]_{S}[\chi_{1}]}$ |  $\psi^{C}_{[111]}\phi_{[21]}\chi_{[21]}\hskip 21.62393pt\otimes\hskip 28.45274pt\psi^{C}_{[111]}\phi(c\bar{c})\chi_{1}$ | $\frac{1}{2}$ |  $\frac{1}{2}$, $\frac{3}{2}$
$\Psi_{[111]_{C}[21]_{F}[21]_{S}[\chi_{0}]}$ |  $\psi^{C}_{[111]}\phi_{[21]}\chi_{[21]}\hskip 21.62393pt\otimes\hskip 28.45274pt\psi^{C}_{[111]}\phi(c\bar{c})\chi_{0}$ | $\frac{1}{2}$ | $\frac{1}{2}$
$\Psi_{[21]_{C}[3]_{F}[21]_{S}[\chi_{1}]}$ |  $\psi^{C}_{[21]}\phi_{[3]}\chi_{[21]}\hskip 29.02193pt\otimes\hskip 28.45274pt\psi^{C}_{[21]}\phi(c\bar{c})\chi_{1}$ | $\frac{3}{2}$ |  $\frac{1}{2}$, $\frac{3}{2}$
$\Psi_{[21]_{C}[3]_{F}[21]_{S}[\chi_{0}]}$ |  $\psi^{C}_{[21]}\phi_{[3]}\chi_{[21]}\hskip 29.02193pt\otimes\hskip 28.45274pt\psi^{C}_{[21]}\phi(c\bar{c})\chi_{0}$ | $\frac{3}{2}$ | $\frac{1}{2}$
$\Psi_{[21]_{C}[21]_{F}[3]_{S}[\chi_{1}]}$ |  $\psi^{C}_{[21]}\phi_{[21]}\chi_{[3]}\hskip 29.02193pt\otimes\hskip 28.45274pt\psi^{C}_{[21]}\phi(c\bar{c})\chi_{1}$ | $\frac{1}{2}$ |  $\frac{1}{2}$, $\frac{3}{2}$, $\frac{5}{2}$
$\Psi_{[21]_{C}[21]_{F}[3]_{S}[\chi_{0}]}$ |  $\psi^{C}_{[21]}\phi_{[21]}\chi_{[3]}\hskip 29.02193pt\otimes\hskip 28.45274pt\psi^{C}_{[21]}\phi(c\bar{c})\chi_{0}$ | $\frac{1}{2}$ | $\frac{3}{2}$
$\Psi_{[21]_{C}[21]_{F}[21]_{S}[\chi_{1}]}$ |  $\psi^{C}_{[21]}\phi_{[21]}\chi_{[21]}\hskip 25.6073pt\otimes\hskip 28.45274pt\psi^{C}_{[21]}\phi(c\bar{c})\chi_{1}$ | $\frac{1}{2}$ |  $\frac{1}{2}$, $\frac{3}{2}$
$\Psi_{[21]_{C}[21]_{F}[21]_{S}[\chi_{0}]}$ |  $\psi^{C}_{[21]}\phi_{[21]}\chi_{[21]}\hskip 25.6073pt\otimes\hskip 28.45274pt\psi^{C}_{[21]}\phi(c\bar{c})\chi_{0}$ | $\frac{1}{2}$ | $\frac{1}{2}$
$\Psi_{[21]_{C}[111]_{F}[21]_{S}[\chi_{1}]}$ |  $\psi^{C}_{[21]}\phi_{[111]}\chi_{[21]}\hskip 21.62393pt\otimes\hskip 28.45274pt\psi^{C}_{[21]}\phi(c\bar{c})\chi_{1}$ | 0 |  $\frac{1}{2}$, $\frac{3}{2}$
$\Psi_{[21]_{C}[111]_{F}[21]_{S}[\chi_{0}]}$ |  $\psi^{C}_{[21]}\phi_{[111]}\chi_{[21]}\hskip 21.62393pt\otimes\hskip 28.45274pt\psi^{C}_{[21]}\phi(c\bar{c})\chi_{0}$ | 0 | $\frac{1}{2}$

##  III $P_{c}$ partial decay widths

The $P_{c}$ resonances may decay through both the hidden-charm and open charm
modes, as shown in Fig. 1 and Fig. 2, respectively. The transition amplitudes
are calculated from

$T=\bra{\psi_{final}}\hat{O}\ket{\psi_{initial}},$ (6)

where $\psi_{initial}$ represents the initial states of hidden charm
pentaquark listed in Table 2 and $\psi_{final}$ represents the final states
from all possible decay channels. The operator, $\hat{O}$, can be either
$\hat{O}_{d}$ for the direct process or $\hat{O}_{c}$ for the cross process.
These operators can be written in the form

$\displaystyle\hat{O}_{d}=$
$\displaystyle\lambda\;\delta^{3}(\vec{q}_{1}-\vec{q}_{6})\delta^{3}(\vec{q}_{2}-\vec{q}_{7})\delta^{3}(\vec{q}_{3}-\vec{q}_{8})\delta^{3}(\vec{q}_{4}-\vec{q}_{9})$
$\displaystyle\delta^{3}(\vec{q}_{5}-\vec{q}_{10}),$ (7)
$\displaystyle\hat{O}_{c}=$
$\displaystyle\lambda\;\delta^{3}(\vec{q}_{1}-\vec{q}_{6})\delta^{3}(\vec{q}_{2}-\vec{q}_{7})\delta^{3}(\vec{q}_{3}-\vec{q}_{9})\delta^{3}(\vec{q}_{4}-\vec{q}_{8})$
$\displaystyle\delta^{3}(\vec{q}_{5}-\vec{q}_{10}).$ (8)

where $\lambda$ is a coupling constant which are assumed in this work the same
for both direct and cross processes.

Shown in Table 3 are the factors of the spin-flavor-color transition
amplitudes for the decays of 17 initial pentaquark states to 10 final states,
$p\eta_{c}$, $\Delta\eta_{c}$, $pJ/\psi$, $\Delta J/\psi$,
$\Lambda_{c}\bar{D}$, $\Sigma_{c}\bar{D}$, $\Sigma^{*}_{c}\bar{D}$,
$\Sigma_{c}\bar{D}^{*}$, $\Sigma^{*}_{c}\bar{D}^{*}$ and
$\Lambda_{c}\bar{D}^{*}$. The pentaquark states in both the color singlet-
singlet and color octet-octet configurations are classified by the isospins.

Table 3: Allowed spin-flavor-color transition amplitudes, $\bra{\psi_{f}^{SFC}}\hat{O}\ket{\psi_{i}^{SFC}}$. $P_{c}$ Configuration | $J^{P}$ | $\Delta\eta_{c}$ | $p\eta_{c}$ | $\Delta J/\psi$ | $pJ/\psi$ | $\Sigma_{c}^{*}\bar{D}$ | $\Sigma_{c}\bar{D}$ | $\Lambda_{c}\bar{D}$ | $\Sigma_{c}^{*}\bar{D}^{*}$ | $\Sigma_{c}\bar{D}^{*}$ | $\Lambda_{c}\bar{D}^{*}$
---|---|---|---|---|---|---|---|---|---|---|---
| Isospin 3/2
$\Psi_{[111]_{C}[3]_{F}[3]_{S}[\chi_{1}]}$ | $\frac{5}{2}^{-}$ |  |  | 1 |  |  |  |  | $\frac{1}{3}$ |  |
$\Psi_{[111]_{C}[3]_{F}[3]_{S}[\chi_{1}]}$ | $\frac{3}{2}^{-}$ |  |  | 1 |  | $\frac{\sqrt{\frac{5}{3}}}{6}$ |  |  | $\frac{1}{8}$ | $\frac{\sqrt{5}}{9}$ |
$\Psi_{[111]_{C}[3]_{F}[3]_{S}[\chi_{0}]}$ | $\frac{3}{2}^{-}$ |  |  | 1 |  | $\frac{1}{6}$ |  |  | $\frac{\sqrt{\frac{5}{3}}}{6}$ | $-\frac{1}{3\sqrt{3}}$ |
$\Psi_{[111]_{C}[3]_{F}[3]_{S}[\chi_{1}]}$ | $\frac{1}{2}^{-}$ | 1 |  |  |  |  | $\frac{\sqrt{\frac{2}{3}}}{3}$ |  | $-\frac{1}{9}$ | $\frac{\sqrt{2}}{9}$ |
$\Psi_{[21]_{C}[3]_{F}[21]_{S}[\chi_{1}]}$ | $\frac{3}{2}^{-}$ |  |  |  |  | $\frac{2}{3\sqrt{3}}$ |  |  | $-\frac{2\sqrt{5}}{9}$ | $-\frac{2}{9}$ |
$\Psi_{[21]_{C}[3]_{F}[21]_{S}[\chi_{1}]}$ | $\frac{1}{2}^{-}$ |  |  |  |  |  | $\frac{1}{3\sqrt{3}}$ |  | $-\frac{2\sqrt{2}}{9}$ | $-\frac{5}{9}$ |
$\Psi_{[21]_{C}[3]_{F}[21]_{S}[\chi_{0}]}$ | $\frac{1}{2}^{-}$ |  |  |  |  |  | $-\frac{1}{3}$ |  | $-\frac{2\sqrt{\frac{2}{3}}}{3}$ | $\frac{1}{3\sqrt{3}}$ |
| Isospin 1/2
$\Psi_{[111]_{C}[21]_{F}[21]_{S}[\chi_{1}]}$ | $\frac{3}{2}^{-}$ |  |  |  | 1 | $-\frac{1}{3\sqrt{6}}$ |  |  | $\frac{\sqrt{\frac{5}{2}}}{9}$ | $\frac{1}{9\sqrt{2}}$ | $\frac{1}{3\sqrt{2}}$
$\Psi_{[111]_{C}[21]_{F}[21]_{S}[\chi_{1}]}$ | $\frac{1}{2}^{-}$ |  |  |  | 1 |  | $-\frac{1}{6\sqrt{6}}$ | $\frac{1}{2\sqrt{6}}$ | $\frac{1}{9}$ | $\frac{5}{18\sqrt{2}}$ | $-\frac{1}{6\sqrt{2}}$
$\Psi_{[111]_{C}[21]_{F}[21]_{S}[\chi_{0}]}$ | $\frac{1}{2}^{-}$ |  | 1 |  |  |  | $\frac{1}{6\sqrt{2}}$ | $\frac{1}{6\sqrt{2}}$ | $\frac{1}{3\sqrt{3}}$ | $-\frac{1}{6\sqrt{6}}$ | $\frac{1}{2\sqrt{6}}$
$\Psi_{[21]_{C}[21]_{F}[3]_{S}[\chi_{1}]}$ | $\frac{5}{2}^{-}$ |  |  |  |  |  |  |  | $-\frac{2}{3}$ |  |
$\Psi_{[21]_{C}[21]_{F}[3]_{S}[\chi_{1}]}$ | $\frac{3}{2}^{-}$ |  |  |  |  | $-\frac{\sqrt{\frac{5}{3}}}{3}$ |  |  | $-\frac{1}{9}$ | $-\frac{2\sqrt{5}}{9}$ |
$\Psi_{[21]_{C}[21]_{F}[3]_{S}[\chi_{1}]}$ | $\frac{1}{2}^{-}$ |  |  |  |  |  | $-\frac{2\sqrt{\frac{2}{3}}}{3}$ |  | $\frac{2}{9}$ | $-\frac{2\sqrt{2}}{9}$ |
$\Psi_{[21]_{C}[21]_{F}[3]_{S}[\chi_{0}]}$ | $\frac{3}{2}^{-}$ |  |  |  |  | $-\frac{1}{3}$ |  |  | $-\frac{\sqrt{\frac{5}{3}}}{3}$ | $\frac{2}{3\sqrt{3}}$ |
$\Psi_{[21]_{C}[21]_{F}[21]_{S}[\chi_{1}]}$ | $\frac{3}{2}^{-}$ |  |  |  |  | $\frac{\sqrt{\frac{2}{3}}}{3}$ |  |  | $-\frac{\sqrt{10}}{9}$ | $-\frac{\sqrt{2}}{9}$ | $\frac{\sqrt{2}}{3}$
$\Psi_{[21]_{C}[21]_{F}[21]_{S}[\chi_{1}]}$ | $\frac{1}{2}^{-}$ |  |  |  |  |  | $\frac{1}{3\sqrt{6}}$ | $\frac{1}{\sqrt{6}}$ | $-\frac{2}{9}$ | $-\frac{5}{9\sqrt{2}}$ | $-\frac{1}{3\sqrt{2}}$
$\Psi_{[21]_{C}[21]_{F}[21]_{S}[\chi_{0}]}$ | $\frac{1}{2}^{-}$ |  |  |  |  |  | $-\frac{1}{3\sqrt{2}}$ | $\frac{1}{3\sqrt{2}}$ | $-\frac{2}{3\sqrt{3}}$ | $\frac{1}{3\sqrt{6}}$ | $-\frac{1}{\sqrt{6}}$
Figure 1: Hidden charm decay process (direct process).  Figure 2: Open charm
decay process (cross process).

With the transition amplitude defined in Eq.6, the decay width is evaluated in
the non-relativistic approximation [24],

$\displaystyle\Gamma_{P_{c}\rightarrow BM}=$ $\displaystyle\frac{2\pi
E_{1}E_{2}}{M_{P_{c}}}\frac{1}{2S_{i}+1}\;f(m_{B},m_{M},q)$
$\displaystyle\hskip
45.52458pt\sum_{m_{i},m_{f}}|\bra{\psi_{f}^{SFC}}\hat{O}\ket{\psi_{i}^{SFC}}|^{2},$
(9)

where $S_{i}$, $m_{i}$, and $M_{P_{c}}$ are the spin, spin projection quantum
number, and mass of the initial pentaquark states, respectively. $E_{1}$ and
$E_{2}$ are the energies of the baryon and meson in the final states,
$\bra{\psi_{f}^{SFC}}\hat{O}\ket{\psi_{i}^{SFC}}$ is the spin-flavor-color
factors of the transition amplitudes listed in Table 3. The summation is over
the spins of the initial and final states. $f(m_{B},m_{M},q)$ is a kinematical
phase-space factor depending on the masses of the baryon and meson in the
final states as well as the spatial wave functions of all particles. To reduce
the model dependence, we apply the phenomenological form for the phase space
factor,

$f(m_{B},m_{M},q)=q\;\text{exp}\\{-1.2\;\text{GeV}^{-1}\;(s-s_{0})^{1/2}\\},$
(10)

where $s_{0}=(m_{B}+m_{M})^{2}$,
$\sqrt{s}=(m_{B}^{2}+q^{2})^{1/2}+(m_{M}^{2}+q^{2})^{1/2}$, and $q$ is the
final momentum at the rest frame of the pentaquark. The kinematical phase-
space factor in Eq. (10) has been fitted to the cross section of various
$p\bar{p}$ annihilation channels [25] and applied successfully to other works
[26, 27, 28]. The numerical values of the kinematical phase-space factor are
shown in Appendix B for the masses of $P_{c}(4312)$ $P_{c}(4440)$ and
$P_{c}(4457)$ resonances and various decay channels. Some decay channels of
$P_{c}$ states are vanished by missing of spin-flavor-color transition
amplitude in Table 3 and phase space factor in Table 6. It is seen that
$P_{c}(4312)$ in the configuration
$\psi_{[111]_{C}[21]_{F}[21]_{S}[\chi_{1}]}$ with spin $\frac{3}{2}$ has two
decay channels, $pJ/\psi$ and $\Lambda_{c}\bar{D}^{*}$ while $P_{c}(4440)$ and
$P_{c}(4457)$ with the same configuration have one more open charm decay
channel, $\Sigma^{*}_{c}\bar{D}$. For the configuration
$\psi_{[111]_{C}[21]_{F}[21]_{S}[\chi_{1}]}$ and spin $\frac{1}{2}$,
$P_{c}(4312)$ has $pJ/\psi$, $\Lambda_{c}\bar{D}$ and $\Lambda_{c}\bar{D}^{*}$
decay channels while $P_{c}(4440)$ and $P_{c}(4457)$ get one more open
channel, $\Sigma_{c}\bar{D}$.

The partial decay widths of all available pentaquark states are calculated in
Eq. III. Listed in Table 4 are the results for only the $I=\frac{1}{2}$
pentaquark states, where the partial decay widths are normalized to the
$\psi_{[111]_{C}[21]_{F}[21]_{S}[\chi_{1}]}\rightarrow pJ/\psi$ process. In
the calculation we let the pentaquark states take the mass of $P_{c}(4457)$.
The results for the channels allowed by the energy conservation are similar
when the masses of $P_{c}(4312)$, $P_{c}(4440)$ are applied for the initial
pentaquark states. In the calculation, we have considered only the $S$-wave
decay since the mass thresholds for all the final states are very close to the
mass of the $P_{c}$ resonances. Among the 17 compact pentaquark states, the
state of spin $5/2$ in the $\psi_{[21]_{C}[21]_{F}[3]_{S}[\chi_{1}]}$
configuration has no any allowed decay channel.

Table 4: Partial decay widths of $I=\frac{1}{2}$ pentaquark states of 4457 MeV, normalized to the $\psi_{[111]_{C}[21]_{F}[21]_{S}[\chi_{1}]}\rightarrow pJ/\psi$ width. $J^{p}$ |  $P_{c}$ configuration | $pJ/\psi$ | $p\eta_{c}$ | $\Sigma_{c}^{*}\bar{D}$ | $\Sigma_{c}\bar{D}$ | $\Lambda_{c}\bar{D}$ | $\Lambda_{c}\bar{D}^{*}$
---|---|---|---|---|---|---|---
$\frac{3}{2}^{-}$ |  $\psi_{[111]_{C}[21]_{F}[21]_{S}[\chi_{1}]}$ |  1 |  |  0.04 |  |  |  0.11
|  $\psi_{[21]_{C}[21]_{F}[3]_{S}[\chi_{1}]}$ |  |  |  0.40 |  |  |
|  $\psi_{[21]_{C}[21]_{F}[3]_{S}[\chi_{0}]}$ |  |  |  0.24 |  |  |
|  $\psi_{[21]_{C}[21]_{F}[21]_{S}[\chi_{1}]}$ |  |  |  0.16 |  |  |  0.46
$\frac{1}{2}^{-}$ |  $\psi_{[111]_{C}[21]_{F}[21]_{S}[\chi_{1}]}$ |  1 |  |  |  0.01 |  0.07 |  0.03
|  $\psi_{[111]_{C}[21]_{F}[21]_{S}[\chi_{0}]}$ |  |  0.90 |  |  0.03 |  0.02 |  0.09
|  $\psi_{[21]_{C}[21]_{F}[3]_{S}[\chi_{1}]}$ |  |  |  |  0.62 |  |
|  $\psi_{[21]_{C}[21]_{F}[21]_{S}[\chi_{1}]}$ |  |  |  |  0.04 |  0.28 |  0.11
|  $\psi_{[21]_{C}[21]_{F}[21]_{S}[\chi_{0}]}$ |  |  |  |  0.12 |  0.09 |  0.34

##  IV DISCUSSION

We have calculated the partial decay widths for all the 17 compact pentaquark
states since the quantum numbers of the three LHCb $P_{c}$ resonances have not
been determined yet. The results in Table 4 for the nine $I=1/2$ pentaquark
states show that the $pJ/\psi$ channel is open for only two states with the
configuration $\psi_{[111]_{C}[21]_{F}[21]_{S}[\chi_{1}]}$ and spin
$\frac{3}{2}$ and $\frac{1}{2}$. If there is no mixing among the
$I=\frac{1}{2}$ and $J=\frac{3}{2}$ states as well as among the
$I=\frac{1}{2}$ and $J=\frac{1}{2}$ states, there are only two compact
charmonium-like pentaquark states which decay through the $pJ/\psi$ channel.
Therefore, one may accommodate only two of the three observed $P_{c}$ in the
compact pentaquark picture. Our results show that the $pJ/\psi$ partial decay
widths of $P_{c}(4312)$, $P_{c}(4440)$ and $P_{c}(4457)$ in the configuration
$\psi_{[111]_{C}[21]_{F}[21]_{S}[\chi_{1}]}$ are almost the same due to the
mass closeness, that is

$\displaystyle\frac{P_{c}(4312)\rightarrow pJ/\psi}{P_{c}(4457)\rightarrow
pJ/\psi}$ $\displaystyle=$ $\displaystyle 1.16$
$\displaystyle\frac{P_{c}(4440)\rightarrow pJ/\psi}{P_{c}(4457)\rightarrow
pJ/\psi}$ $\displaystyle=$ $\displaystyle 1.02$ (11)

Thus, this work indicates that $P_{c}(4440)$ may not be a compact pentaquark
since its decay width is much larger than the other observed $P_{c}$, and that
one may assign $J=\frac{1}{2}$ to the $P_{c}(4312)$ state and $J=\frac{3}{2}$
to the $P_{c}(4457)$ state in the compact pentaquark picture.

The branching ratios of the dominant channels are the key to reveal the nature
of these charmonium-like pentaquark states. In addition to the $pJ/\psi$ decay
channel, the remaining possible decay channels, particularly the $p\eta_{c}$
channel should be targeted to search for $P_{c}$ states and determine their
quantum numbers in the future experiments.

## ACKNOWLEDGEMENTS

This work is supported by Suranaree University of Technology (SUT), National
Cheng Kung University(NCKU) and Development and Promotion of Science and
Technology Talents Project (DPST).

##  Appendix A The explicit color wave function

The explicit color singlet and octet wave functions of the $q^{3}$ and
$c\bar{c}$ clusters are listed in Table 5, which are employed to evaluate the
spin-flavor-color transition amplitude of pentaquark states.

Table 5: Color wave functions of baryon and meson clusters for pentaquarks.  |  $q^{3}$ |  |  $Q\bar{Q}$
---|---|---|---
Singlet |  $\frac{1}{\sqrt{6}}(RGB-RBG+GBR-GRB$ $+BRG-BGR)$ |  |  $\frac{1}{\sqrt{3}}(R\bar{R}+G\bar{G}+B\bar{B})$
|  $q^{3}\rho$-type |  $q^{3}\lambda$-type |  $Q\bar{Q}$
Octet |  |  |
1 | $\frac{1}{\sqrt{2}}(RGR-GRR)$ | $\frac{1}{\sqrt{6}}(RRG-RGR-GRR)$ | $B\bar{R}$
2 | $\frac{1}{\sqrt{2}}(RGG-GRG)$ | $\frac{1}{\sqrt{6}}(RGG-GRG-2GGR)$ | $B\bar{G}$
3 | $\frac{1}{\sqrt{2}}(RBR-BRR)$ | $\frac{1}{\sqrt{6}}(2RRB-RBR-BRR)$ | $-G\bar{R}$
4 |  $\frac{1}{2}(RBG+GBR-BRG-BGR)$ |  $\frac{1}{\sqrt{12}}(2RGB+2GRB-GBR-RBG$ $-BRG-BGR)$ | $\frac{1}{\sqrt{2}}(R\bar{R}-G\bar{G})$
5 | $\frac{1}{\sqrt{2}}(GBG-BGG)$ | $\frac{1}{\sqrt{6}}(2GGB-GBG-BGG)$ | $R\bar{G}$
6 |  $\frac{1}{\sqrt{12}}(2RGB-2GRB-GBR+RBG$ $-BRG+BGR)$ |  $\frac{1}{2}(RBG-GBR+BRG-BGR)$ |  $\frac{1}{\sqrt{6}}(2B\bar{B}-R\bar{R}-G\bar{G})$
7 | $\frac{1}{\sqrt{2}}(RBB-BRB)$ | $\frac{1}{\sqrt{6}}(RBB+BRB-2BBR)$ | $-G\bar{B}$
8 | $\frac{1}{\sqrt{2}}(GBB-BGB)$ | $\frac{1}{\sqrt{6}}(GBB+BGB-2BBG)$ | $R\bar{B}$

##  Appendix B Phase space factor with the possible decay channels

Listed in Table 6 are the numerical values of the kinematical phase-space
factor in Eq. (10). Some decay channels are not available (N/A) because of the
energy conservation.

Table 6: Phase space factor, $f(m_{B},m_{M},q)$, for $P_{c}(4312)$, $P_{c}(4440)$ and $P_{c}(4457)$ with possible decay channels. Final particles | Total mass of | $P_{c}(4312)$ | $P_{c}(4440)$ | $P_{c}(4457)$
---|---|---|---|---
final particles (GeV)
$p\eta_{c}$ | 3.922 | 0.08056 | 0.07038 | 0.06911
$\Delta\eta_{c}$ | 4.214 | 0.12653 | 0.11442 | 0.11221
$pJ/\psi$ | 4.035 | 0.08929 | 0.07827 | 0.07686
$\Delta J/\psi$ | 4.327 | N/A | 0.12631 | 0.12516
$\Lambda_{c}\bar{D}$ | 4.157 | 0.15350 | 0.13097 | 0.12797
$\Sigma_{c}\bar{D}$ | 4.325 | N/A | 0.16237 | 0.16014
$\Sigma_{c}^{*}\bar{D}$ | 4.390 | N/A | 0.16176 | 0.16517
$\Lambda_{c}\bar{D}^{*}$ | 4.297 | 0.12507 | 0.16132 | 0.15847
$\Sigma_{c}\bar{D}^{*}$ | 4.465 | N/A | N/A | N/A
$\Sigma_{c}^{*}\bar{D}^{*}$ | 4.530 | N/A | N/A | N/A

## References

  * [1] R. Aaij et al. (LHCb Collaboration), Observation of $J/\Psi p$ Resonances Consistent with Pentaquark States in $\Lambda^{0}_{b}\to J/\Psi K^{-}p$ Decays, Phys. Rev. Lett. 115, 072001 (2015).
  * [2] R. Aaij et al. (LHCb Collaboration), Model-Independent Evidence for $J/\Psi p$ Contributions to $\Lambda^{0}_{b}\to J/\Psi pK^{-}$ Decays, Phys. Rev. Lett. 117, 082002 (2016).
  * [3] R. Aaij et al. (LHCb Collaboration), Observation of a Narrow Pentaquark State, $P_{c}(4312)^{+}$ , and of the Two-Peak Structure of the $P_{c}(4450)^{+}$, Phys. Rev. Lett. 122, 222001 (2019).
  * [4] H. X. Chen, W. Chen, and S. L. Zhu, Possible interpretations of the ${P}_{c}(4312)$, ${P}_{c}(4440)$, and ${P}_{c}(4457)$, Phys. Rev. D 100, 051501 (2019).
  * [5] R. Chen, Z. F. Sun, X. Liu, and S. L. Zhu, Strong LHCb evidence supporting the existence of the hidden-charm molecular pentaquarks, Phys. Rev. D 100, 011502 (2019).
  * [6] L. Meng, B. Wang, G. J. Wang, and S. L. Zhu, The hidden charm pentaquark states and $\Sigma_{c}\bar{D}^{*}$ interaction in chiral perturbation theory, Phys. Rev. D 100, 014031 (2019).
  * [7] F. K. Guo, H. J. Jing, U. G. Meißner, and S. Sakai, Isospin breaking decays as a diagnosis of the hadronic molecular structure of the $P_{c}(4457)$, Phys. Rev. D 99, 091501 (2019).
  * [8] C. J. Xiao, Y. Huang, Y. B. Dong, L. S. Geng, and D. Y. Chen, Exploring the molecular scenario of ${P}_{c}(4312)$, ${P}_{c}(4440)$, and ${P}_{c}(4457)$, Phys. Rev. D 100, 014022 (2019).
  * [9] M. B. Voloshin, Some decay properties of hidden-charm pentaquarks as baryon-meson molecules, Phys. Rev. D 100, 034020 (2019).
  * [10] S. Sakai, H. J. Jing, and F. K. Guo, Decays of $P_{c}$ into $J/\psi N$ and $\eta_{c}N$ with heavy quark spin symmetry, Phys. Rev. D 100, 074007 (2019).
  * [11] Y. H. Lin and B. S. Zou, Strong decays of the latest LHCb pentaquark candidates in hadronic molecule pictures, Phys. Rev. D 100, 056005 (2019).
  * [12] T. Gutsche and V. E. Lyubovitskij, Structure and decays of hidden heavy pentaquarks, Phys. Rev. D 100, 094031 (2019).
  * [13] A. Ali, I. Ahmed, M. Jamil Aslam, and A. Rehman, Heavy quark symmetry and weak decays of the b baryons in pentaquarks with a $c\bar{c}$ component, Phys. Rev. D 94, 054001 (2016)
  * [14] A. Ali and A. Y. Parkhomenko, Interpretation of the narrow $J/\psi p$ peaks in $\Lambda_{b}\to J/\psi pK^{-}$ decay in the compact diquark model, Phys. Lett. B 793, 365 (2019)
  * [15] F. Giannuzzi, Heavy pentaquark spectroscopy in the diquark model, Phys. Rev. D 99, 094006 (2019).
  * [16] X.Z. Weng, X.L. Chen, W.Z. Deng, S.L. Zhu, Hidden-charm pentaquarks and $P_{c}$ states, Phys. Rev. D 100, 016014 (2019).
  * [17] H. X. Chen, W. Chen ,X. Liu, T. G. Steele and S. L. Zhu, Towards Exotic Hidden-Charm Pentaquarks in QCD, Phys. Rev. Lett. 115, 172001 (2019).
  * [18] H. X. Chen, W. Chen and S.L. Zhu, Possible interpretations of the $P_{c}(4312)$, $P_{c}(4440)$, and $P_{c}(4457)$, Phys. Rev. D 100, 051501 (2019).
  * [19] J. B. Cheng and , Y. R. Liu, Understanding the structures of hidden-charm pentaquarks in a simple model, Nucl. Part. Phys. Proc. 309-311, 158 (2020).
  * [20] Y. Yan, Applied group theory in physics, Nakhonratchasima : Suranaree University of Technology Suranaree Press, University of Technology, (2011).
  * [21] Y. Yan and S. Srisuphaphon, Construction of multiquark states in group theory, Prog. Part. Nucl. Phys. 67, 496 (2012).
  * [22] K. Xu, A. Kaewsnod, X. Y. Liu, S. Srisuphaphon, A. Limphirat, and Y. Yan, Complete basis for pentaquark wave function in group theory approach, Phys. Rev. C 100, 065207 (2019).
  * [23] K. Xu, A. Kaewsnod, X. Y. Liu, S. Srisuphaphon, A. Limphirat, and Y. Yan, Pentaquark components in low-lying baryon resonances, Phys. Rev. D 101, 076025 (2020).
  * [24] A. Limphirat, C. Kobdaj, P. Suebka, and Y. Yan, Decay widths of ground-state and excited $\Xi^{b}$ baryons in a nonrelativistic quark model, Phy. REV. C 82, 055201, (2010)
  * [25] J. Vandermeulen, $N\bar{N}$ Annihilation creates two mesons, Z. Phys. C 37, 563 (1988).
  * [26] T. Gutsche and Amand Faessler and Granddon D. Yen and Shin Nan Yang, Consequences of strangeness content in the nucleon for $\phi-$ meson production in $N\bar{N}$ annihilation, Nucl. Phys. Proc. Suppl. 56, 311 (1997).
  * [27] T. Gutsche and R. Vinh Mau and M. Strohmeier-Presicek and A. Faessler, Radiative proton-antiproton annihilation and isospin mixing in protonium, Phys. Rev. C 59, 630 (1999)
  * [28] S. Srisuphaphon, A. Kaewsnod, A. Limphirat, K. Khosonthongkee, and Y. Yan, Role of pentaquark components in $\phi$ meson production proton-antiproton annihilation reactions, Phys. Rev. C 93, 025201 (2016).