\section{Introduction}
\IEEEPARstart{M}{obile} Augmented reality (MAR) could be extended and enhanced in wireless edge supported metaverse by today's available technologies like digital twin and head-mounted display rendering \cite{xu2021wireless}\cite{dong2019deep}. Compared to ongoing MAR applications, users could have mixed experience seamlessly between metaverse and physical world through various metaverse MAR applications like massively multiplayer online video games and virtual concerts \cite{xu2021wireless}. Users equipped with MAR devices can upload and analyze their environment through AR customization to achieve appropriate AR objects (AROs) and access the metaverse in mobile edge networks \cite{xu2022full}. Rendering 3-dimensional (3D) AROs with the background virtual environment and updating in metaverse consume significant amounts of energy and could be highly demanding in terms of required caching and computing resources \cite{xu2022full}\cite{li2020rendering}. Hence, such applications are delay and energy sensitive and face challenges in ensuring user quality of experience and providing reliable and timely interactions with the metaverse \cite{xu2021wireless}\cite{xu2022full}.

\begin{figure}[htb]
\centering
\includegraphics[width=0.95\linewidth]{workflow2.jpg}
\caption{The general work flow of metaverse AR applications with delay of each stage (6 EC, 30 requests, weight $\mu$ is 1, EC Capacity is 14 and total mobility probability is 1)}
\label{fig:workflow}
\end{figure}

Generally speaking, a metaverse scene will in essence consisted by a background view as well as many objects in foreground interactions. The background view at a defined amalgamated virtual and physical location cane be deemed as static or slowly changing \cite{xu2022full}\cite{guo2020adaptive}. A typical background scene can be the 3D model of the metaverse, a presentation of a related background virtual environment based on a certain user viewport \cite{guo2020adaptive}\cite{kato2021split}. Its size can reach tens of MB and the corresponding complexity of rendering related functionalities measured by computation load is also large (e.g., 10 CPU cycles/bit) \cite{guo2020adaptive}\cite{yang2018communication}. On the other hand, objects (such as for example avatars) in foreground interactions that are embedded in the metaverse scene change much more frequently however they are significantly less complex than the background scene (e.g., 4 CPU cycles/bit) \cite{li2020rendering}\cite{guo2020adaptive}. But, even though those objects are less complex than the background scene, due to their frequent changes they also require rendering them in a timely manner so that to avoid a considerable quality of experience degradation. Thus, in this paper, rendering for both foreground and background are deployed at the edge clouds (ECs) rather than only at the terminals to make full use of the caching and computing resources. Noticing that uploaded information are focused in foreground interactions while background content checking consumes not only computing resources but also lots of local cache to match and integrate AROs and related models of the metaverse. Hence, similar to our previous work in \cite{huang2021proactive}, the metaverse AR application could also be decomposed into computational and storage intensive functions which serve as a chain for improved assignment and resource allocation.

The general work flow of a metaverse MAR application supported by ECs is shown by Fig. \eqref{fig:workflow}. A metaverse region is a fraction of the complete metaverse and is assumed to be stored on a server geographically close to its corresponding service region in the mobile network (not necessarily running within an EC). The metaverse AR service could be triggered by certain behavior with foreground interactions \cite{xu2022full}\cite{guo2020adaptive}\cite{hertzmann2000painterly}. Then, content related to background contents like for example pre-cached 3D models and AROs are firstly searched in the EC cache to check if they are what the user requires. If the target AROs or model information cannot be found in the cache, then this case is labelled as a "cache miss" and the request is redirected to the original metaverse region stored in a cloud deeper in the network. Finally, according to user's physical mobility and virtual orientation extracted from foreground interactions, the matched AROs and model are integrated into a final frame and transmitted back to the user \cite{xu2022full}\cite{guo2020adaptive}. At the same time, updated information is also sent to the metaverse region for synchronization. Thus, the user could be aware of changes caused by other participants if they share the same metaverse region during the service. The overall quality of the metaverse AR application depends on the communication delays and the capabilities of the above mentioned network entities that participate in the service creation. Hereafter, we assume a nominal frame rate as 15 frames/second and the rendering happens at every other frame (\~ 133.2ms interval) \cite{cozzolino2022nimbus}\cite{niu2018learning}\cite{naman2013inter}. Thus, the service delay of the aforementioned work flow within the interval could be regarded as acceptable.
\begin{figure}
    \centering
    \begin{minipage}[]{0.9\linewidth}
     \centering
    \includegraphics[width=1\linewidth]{toy1.jpg}
    \end{minipage}
    \begin{minipage}[]{0.9\linewidth}
    \centering
    \includegraphics[width=1\linewidth]{toy2.jpg}
    \end{minipage}
    \caption{Illustrative toy examples of a metaverse MAR application where in case (a) user mobility is not considered and in case (b) the physical mobility of the end user and service decomposition are considered with different renderings on pro-active resource allocation of the metaverse MAR functions.}
    \label{fig: toyMetaAR}
\end{figure}

\begin{figure}[htb]
\centering
\includegraphics[width=0.98\linewidth]{TerminalECExample.jpg}
\caption{Illustrative toy examples where in case (i) only terminals are activated, in case (ii) only ECs are activated and in case (iii) both are activated}
\label{fig:TerminalEC}
\end{figure}
Fig. \eqref{fig: toyMetaAR} further reveals the difference between cases that consider the user mobility with service decomposition or not related to rendering requirements in metaverse AR applications. Clearly, when neglecting user mobility and service decomposition as shown by case (a), models, target AROs and metaverse AR applications are all cached close to the user's initial location. It might leave a heavy burden for the adjacent server when there are multiple users at the same cell and causes a "hot spot" area \cite{huang2021proactive}. However, when user mobility and service decomposition is enabled, as shown in case (b), then service delivery becomes more flexible and efficient in terms of assigning requests and allocating network resources. In case (a), although the user A only needs wireless communication in the initial location, it takes 2 hops after moving to the middle cell. However, when taking mobility and local resources into consideration, the same user A in case (b) could encounter a better delay in the after mobility event by allowing 2 more hops in the before mobility event. Hence, in a high mobility scenario, it might not always be ideal to allocate requests and services as close as possible to the user's initial location. As shown in the Figure for users A and B in case (b), the AR contents in the model might be similar in terms of the viewport of different users. Hence, participating users should be aware of each other's updates and could share rendering functions to reduce the consumed resources. In this paper, we apply Structural Similarity (SSIM) proposed by \cite{wang2004image} for user perception experience. It is a widely accepted method that measures user perception quality of an image by comparing to its original version \cite{wang2004image}. Caching more models and AROs also causes more processing and transmission delay with energy consumption \cite{xu2021wireless}\cite{xu2022full}. Hence, the the joint optimization has to accept some potential loss due to constraints of computing and storage resources. Fig. \eqref{fig:TerminalEC} further reveals the difference among cases whether allocating MAR service on terminals or ECs. Neglecting the EC support and service decomposition, the whole MAR application is left to the terminal and could be a heavy burden in case (i). According to \cite{xu2022full}\cite{chen2018understanding}, MAR application on terminals takes up around 47\% power consumption and could affect the running of other functionalities when this service becomes more complex like in metaverse. In case (ii) that researched in our previous work \cite{huang2022mobility}, the processing time is significantly cut down through enabling ECs with the cost of extra transmission delay. Although the terminals are still limited in computing resources and more sensitive in energy consumption, neglecting their capacity at all seems also a waste, especially when recent technical improvements approve their computing and caching potential. Noticing that the foreground interactions are much less complex that background scenes and are more suitable to terminals, we further bring in terminals into the scenario as shown by case (iii) and executing only computational intensive functions. In this paper, the optimization under the integration of terminals and ECs becomes the scheme OptimT and is compared to the previous case (ii) neglecting the terminals (OptimNT). To maintain a fair comparison and focus more on energy consumption and service latency, the overall energy in Joule is measured instead of power in \cite{huang2022mobility} and the user perception quality is accepted as a given boundary.

In this paper, by considering explicitly the terminals, user mobility, service decomposition and models of metaverse regions with embedded AROs, a joint optimization framework (OptimT) is constructed for the metaverse MAR application in the edge supported network. The proposed optimization framework seeks a balance between energy consumption and service delay under a given level of user perception quality. To reveal the influence of capacity and cost of terminals on the metaverse MAR application, this OptimT scheme is further compared with another optimized framework (OptimNT) proposed in our previous work \cite{huang2022mobility} that only focuses on ECs and neglects terminals.

\section{Related Work}
Hereafter, a series of closely related works in the area edge/cloud support of metaverse type of applications over 5G and beyond wireless networks are discussed and compared with the approach proposed in this paper.

Noticing that MAR terminals have witnessed a series of technical improvements while are still quite time and computational consuming, their utilization are focused and accepted as part of the network optimization. In \cite{song2019energy}, authors try to minimize the energy consumption of multicore smart devices, which are usually applied for AR applications. Through tracking the response process of an AR application, they manage to measure the terminal's energy consumption by Amdahl's law. Although the law and a similar formula for the terminal energy are also applied in this paper, we consider a larger scenario including edge servers and a more complex balance between energy and latency. \cite{chen2018marvel} shares a similar target like us, which is achieving the balance between latency and energy consumption under an level of acceptable image quality. However, \cite{chen2018marvel} brings in local sensors at MAR devices for recognizing and tracking AROs so that their scheme could realize selective local visual tracking (optical flow) and selective image offloading. Object recognition stage is more focused in \cite{chen2018marvel} with four AR applications requiring different types of AROs. Without support from ECs, they utilize a further cloud server as a heavy database for 3D AROs and leave most tasks at terminals and cloud offloading only triggers when confronted with a calibration. While in this work, we accept an EC supported network and compare the difference between schemes utilizing MAR terminals or not. In \cite{seo2021novel}, the energy efficiency is optimized under required service latency for MAR in an EC supported network. Similarly, authors consider the proactively caching and propose a tradeoff between energy and latency in terms of cache size. However, their mobile cache and power management scheme still focuses the energy consumption on terminals. Clearly, above mentioned works do not explicitly consider user mobility, perception quality, service decomposition and metaverse application features like ours.

The problem of efficient resource allocation for supporting metaverse type of applications is starting to attract significant amount of attention and various aspects have been considered. In \cite{han2021dynamic}, the emphasis is placed  in the  synchronization of Internet of Things (IoT) services, in which they employ IoT devices to collect real world data for virtual service providers. Through calculating maximum awards, users could select the ideal virtual service provider. Researchers then proposes the game framework considers such reward allocation scheme and general metaverse sensing model \cite{han2021dynamic}. In  \cite{jiang2021reliable}, the authors also adopt a game theoretic framework by considering tasks offloading between mobile devices based on Coded Distributed Computing (CDC) in a proposed vehicular metaverse environment. Another framework proposed by \cite{chu2022metaslicing} manages and allocates different types of metaverse applications so that common resources among them could be shared through a semi-Markov decision process and an optimal admission control scheme. The work in \cite{ng2021unified} applies a set of proposed resource optimization schemes in a virtual education metaverse. Mores specifically, a stochastic optimal resource allocation
scheme is developed with the aim to reduce the overall cost of incurred by a service provider. Similar to the service decomposition in this paper, they only upload and cache some parts of data or services to achieve reduced levels of delay and offer better privacy \cite{ng2021unified}. The work in \cite{dong2019deep} is closely relevant since in that paper not only latency but energy consumption is also considered as is the case of our proposed model that uses a multi-objective optimization approach. For ultra-reliable and low-latency communication services, researchers bring in digital twins and deploy a mobility management entity for each access point to determine probabilities of resource allocation and data offloading \cite{dong2019deep}. Then, by applying a deep learning neuro network the proposed scheme tries to identify a suitable user association and an optimized resource allocation scheme for this association. While, in this paper, the core idea is to decompose he service and allow a flexible allocation across edge clouds by taking also into account user mobility.  The work in\cite{xu2021wireless} considers virtual reality applications in the metaverse and regards the service delivery as a series of events in the market, in which users are buyers and service provides are sellers. Hence, they apply Double Dutch Auction (DDA) to achieve common price through asynchronous and iterative biding stages \cite{xu2021wireless}. They emphasize the quality of user perception experience by Structural SIMilarity (SSIM) and Video Multi-Method Assessment Fusion (VMAF). In our proposed framework, we also utilize the SSIM metric to determine the frame quality after integrating background scene and AR contents \cite{xu2021wireless}. The work in \cite{xu2021wireless} further brings in a deep reinforcement learning-based auctioneer to reduce the information exchanging cost. While in this paper, a multi-objective optimization approach is taken where we aim to balance across different objectives using scalarization and considering user mobility in an explicit manner.

\section{System Model}
\subsection{Multi Rendering in Metaverse AR}
In a given wireless network topology, the set $\mathbb{M}=\{1,2,...,M\}$ denotes the available locations, including available edge clouds and terminals. Assuming that each user makes a single request, the corresponding MAR service requests defined by $r\in \mathbb{R}$ in the metaverse region generated by mobile users could be equipped with MAR devices. Request $r$ emerge from network location $f(r)$. It represents the initial access router where this user is firstly connected to. For each request, the user terminal could also be viewed as a valid location to cache or to process information locally. Thus, we define with $j_r \in \mathbb{M}$ as the terminal sending the request $r$. The terminals are brought into consideration in the following formulation. Through defining the location with constraint as $j\in \mathbb{M}, j\neq j_r$, this could only enable the ECs. Clearly, for the OptimNT scheme, this works for all locations. While in the following formulation for the OptimT scheme, we force that the storage intensive functions are executed only on the ECs while the computing intensive ones could also hosted at the end terminals. During the mobility event, a user could move to different potential destinations $k\in \mathbb{K}$ (i.e., changing of the anchoring point). Hereafter, and without loss of generality, we only accept adjacent access routers as available destinations in the mobility event. A series of metaverse regions are set on ECs to interact with users. The corresponding metaverse region serving the user can be found through functions $A(f(r)), A(k)$. As explained earlier, each metaverse region is pre-deployed on a server close to the mobile network and its distance to an EC is also predefined. In this paper, as already alluded, a set of AROs is assumed to be embedded across the different background metaverse region models and is defined as $\mathbb{N}=\{1,2,...,N\}$. A set $\mathbb{S}_r=\{1,2,...,S\}$ is defined for multiple rendering of the available metaverse region model to each user. Thus, we denote the decision variable $p_{sj}$ for pre-caching a metaverse region model $s\in \mathbb{S}_r$ at the EC $j$ ($j\in \mathbb{M}, j \neq j_r$). The subset $\mathbb{L}_{rs}$ represents the target AROs required by the user $r$ in the related model $s\in \mathbb{S}_r$ and the size of each target ARO $l\in \mathbb{L}_{rs}$ is denoted as $O_l$. Lastly, the decision variable $h^s_{rl}$ is brought in for proactively caching an ARO required by a request $r$. Based on the above, the decision variables $p_{sj}$ and $h^s_{rl}$ can be defined as follows,
\begin{equation}
p^{j}=\left\{
\begin{aligned}
1,&\;\text{if rendering the related model}\;s\;\text{at  node}\;j, \\
0,&\;\text{otherwise}.
\end{aligned}
\right.
\end{equation}
\begin{equation}
h^s_{rl}=\left\{
\begin{aligned}
1,&\;\text{if ARO}\;l\;\text{required by request}\; r\;\text{embedded}\qquad\qquad\qquad\quad\\&\;\text{in the model}\;s\;\text{is cached}, \\
0,&\;\text{otherwise}.
\end{aligned}
\right.
\end{equation}
In addition to the above, the following constraints should also be satisfied,
\begin{equation}
\begin{aligned}
\sum_{r \in \mathbf{R}}h^s_{rl} \leqslant 1,\; \forall j\in \mathbf{M}, j\neq j_r,\;\forall s\in \mathbf{S_r},\; \forall l\in \mathbf{L_{rs}} \\
\end{aligned}
\label{cons_h1}
\end{equation}
\begin{equation}
\begin{aligned}
\sum_{s\in \mathbf{S_r}}\sum_{l \in \mathbf{L_{rs}}}h^s_{rl} \geqslant 1,\; \forall r\in \mathbf{R} \\
\end{aligned}
\label{cons_h2}
\end{equation}
\begin{equation}
\begin{aligned}
\sum_{j \in \mathbf{M}, j\neq j_r }p_{sj} \geqslant h^s_{rl},\; \forall r\in \mathbf{R},\;\forall s\in \mathbf{S_r},\; \forall l\in  \mathbf{L_{rs}} \\
\end{aligned}
\label{cons_h3}
\end{equation}
\begin{equation}
\begin{aligned}
h^s_{rl} \leqslant h^s_{rl} \sum_{j \in \mathbf{M}, j\neq J_r}p_{sj},\; \forall r\in \mathbf{R},\;\forall s\in \mathbf{S_r},\; \forall l\in  \mathbf{L_{rs}} \\
\end{aligned}
\label{cons_h4}
\end{equation}
Constraints in \eqref{cons_h1} forces each ARO to be pre-cached at most once in a related model. In constraints \eqref{cons_h2}, a valid request consists of at least one model and an embedded ARO. Constraints in \eqref{cons_h3} guarantee that the allocation of an ARO happens in conjunction to the decision of proactive caching whilst constraints in \eqref{cons_h4} further certify that the rejection of the model's proactive caching causes any ARO planned to be embedded in this model should not be pre-cached as well. Thus, \eqref{cons_h3} only accepts ARO in an pre-cached model and \eqref{cons_h4} rejects all related ones when failing to cache a model, which together could ensure the model and corresponding AROs cannot be handled separately during the formulation.

\subsection{Wireless Channel Model}
With $B_j$ we express the bandwidth of the resource block and $\gamma_{rj}$ denotes the Signal to Interference plus Noise Ratio (SINR) of the user $r$ at the node $j$. With $P^{tran}_{rj}$ we denote the transmit power of the user $r$ at the node $j$, and $P_i$ is transmission power at the base station. Furthermore,  $H_{rj}$ is the channel gain, $N_j$ is the noise power and $a$ is the path loss exponent whilst $d_{rj}$ is the  distance between the user and the base station. Finally, a  Rayleigh fading channel is used to capture the channel between the base stations and the users\cite{gemici2021modeling}. More specifically, the channel gain $H_{rj}$ can be written as follows \cite{cho2010mimo},
\begin{equation}
\begin{aligned}
H_{rj}=\sqrt{\frac{1}{2}}(t+t^{'}J)
\end{aligned}
\end{equation}
Where $J^2=-1$, $t$ and $t^{'}$ are random numbers following the standard normal distribution. Based on the above, the SINR $\gamma_{rj}$ can be expressed as follows \cite{cho2010mimo}\cite{wang2017meta},
\begin{equation}
\begin{aligned}
\gamma_{rj}=\frac{P^{tran}_{rj}H^2_{rj}d^{-a}_{rj}}{N_j+\sum_{i\in \mathbf{M}, i\neq j}P_iH^2_{ri}d^{-a}_{ri} }
\end{aligned}
\end{equation}
 The data rate is denoted as $g\in\mathbb{G}$ and the decision variable $e_{rg}$ decides whether to select the data rate $g$ for user $r$,
\begin{equation}
e^{rg}=\left\{
\begin{aligned}
1,&\;\text{if data rate}\;g\;\text{is selected}\;\text{for user}\;r, \\
0,&\;\text{otherwise}.
\end{aligned}
\right.
\end{equation}
Noticing that the chosen data rate can also be written as $B_j \log_2 (1+\gamma_{rj})$, after choosing a data rate as $ge_{rg}$ for the user, the current transmit power $P^{tran}_{rj}$ can be written as follows,
\begin{equation}
\begin{aligned}
P^{tran}_{rj}=\frac{N_j+\sum_{i\in \mathbf{M}, i\neq j}P_iH^2_{ri}d^{-a}_{ri}}{H^2_{rj}d^{-a}_{rj}}(2^{\frac{ge_{rg}}{B_j}}-1)
\end{aligned}
\label{transpower}
\end{equation}
Note that $2^{\frac{ge_{rg}}{B_j}}=(1-e_{rg})+e_{rg}2^{\frac{g}{B_j}}$ and should satisfy the following constraint to ensure that a user could only select one data rate,
\begin{equation}
\begin{aligned}
\sum_{g\in\mathbb{G}}e_{rg}=1, \forall r\in\mathbb{R}
\end{aligned}
\label{cons_h7}
\end{equation}

\subsection{Latency, Power Consumption and Quality of Perception Experience}
Similar to our previous work in \cite{huang2021proactive}, the MAR service can be decomposed into computational intensive and storage intensive functionalities and are defined as $\eta$ and $\varrho$ respectively. For these functionalities, their corresponding execution locations are then denoted as $x_{ri}$ and $y_{ri}$ respectively \cite{huang2021proactive}. In a mobility event, the user's moving probability from the starting location to an allowable destination could be known to mobile operators through learning from the historical data and hence is defined as $u_{f(r)k} \in [0,1]$ ($\{f(r),k\} \subset \mathbb{M}$). The size of foreground interactions is denoted as $F^{fore}_{\eta r}$, the size of pointers used for matching AROs is denoted as $F_{\varrho r}$ and the size of the related model $s$ used for background content checking is $F^{back}_{sr}$ \cite{huang2021proactive}\cite{guo2020adaptive}. During the matching and background content checking process, the target AROs or background content are possibly not pre-cached in the local cache and such case is known as a "cache miss" (otherwise there is a "cache hit"). A cache miss in the local cache inevitably triggers the redirection of the request to the metaverse region stored in a core cloud deeper in the network and this extra cost in latency is defined as the penalty $D$. After rendering, the model and target AROs are integrated into a compressed final frame for transmission and its compressed size is denoted as $F^{res}_{sr}$.

In this section, a joint optimization scheme is proposed that aims to balance  the service delay and the energy consumption under the constraint of the user perception quality of the decomposed Metaverse AR services in the EC supported network. The cache hit/miss is expressed by the decision variable $z_{rj}$ and can be written as follows,
\begin{equation}
z_{rj}=\left\{
\begin{aligned}
1 ,&\;\text{if} \sum_{l \in \mathbf{L_{rs}}}\sum_{s \in \mathbf{S_r}}p_{sj}h^s_{rl} \geqslant L_{rs}, \\
0 ,&\;\text{otherwise}.
\end{aligned}
\right.
\end{equation}

The cache capacity of an EC and the cache hit/miss relation can be written as follows,
\begin{equation}
\begin{aligned}
&\sum_{r \in \mathbf{R}}\sum_{l \in \mathbf{L_{rs}}}\sum_{s \in \mathbf{S_r}} p_{sj}h^s_{rl}O_{l}\leq \Theta_j,\forall j\in \mathbf{M},\; j\neq j_r\\
\end{aligned}
\label{cons_h5}
\end{equation}
\begin{equation}
\begin{aligned}
&\sum_{l  \in \mathbf{N}}\sum_{s \in \mathbf{S_r}} h^s_{rl} + \epsilon \leq L_{rs} + U(1-q_{rj}) \\ &\forall j\in \mathbf{M},\; j\neq j_r,  r \in \mathbf{R}\\
\end{aligned}
\label{cons_h6}
\end{equation}
in the above expressions $\Theta_j$ denotes the cache available memory at node $j$. In \eqref{cons_h6}, to transfer the either-or constraint (i.e., $\sum_{l  \in \mathbf{N}}\sum_{s \in \mathbf{S_r}} h^s_{rl} < L_{rs} $ or $z_{rj}=1$) into inequality equations, we bring in $\epsilon$ as a small tolerance value, $U$ as a large arbitrary number and $q_{rj}$ as a new decision variable satisfying $1-q_{rj}=z_{rj}$ \cite{huang2021proactive}. Undoubtedly, increased levels of pro-caching decisions related to the background models and embedded AROs in a request inevitably brings about an extra execution burden for the matching function. Taking the above into account, the actual processing delay of the computational intensive function can be expressed as follows,
\begin{equation}
\begin{aligned}
V_{rj}=\frac{\omega_{\eta} F^{fore}_{\eta r}}{f_V^j}
\end{aligned}
\end{equation}
Similarly, the processing delay of the matching and background content checking function is assumed happen only at serves and can be written as,
\begin{equation}
\begin{aligned}
W_{rj}=\frac{\omega_{\varrho} (F_{\varrho r}+\sum_{l \in \mathbf{L_{rs}}}\sum_{s \in \mathbf{S_r}}p_{sj}h^s_{rl}O_l+\sum_{s \in \mathbf{S_r}}F^{back}_{sr}p_{sj})}{f_V^j}
\end{aligned}
\end{equation}
where $\omega_{\eta}$ and $\omega_{\varrho}$ (cycles/bit) represent the computation load of foreground interaction and background matching, $f^j_V$ is the virtual CPU frequency (cycles/sec), $F_{\varrho r}$ are the size of uploaded pointers of AROs in foreground interactions \cite{huang2021proactive}\cite{guo2020adaptive}.
When finding the target AROs during matching, their pointers included by foreground interactions should also be transferred to the metaverse for updating. Finally, the final frame integrating the model and target AROs of is transmitted back to the user. Hence, the wired transmission delay for each user after processed by functions can be written as follows,
\begin{equation}
\begin{aligned}
\sum_{s \in \mathbf{S_r}}\sum_{j \in \mathbf{M},j\neq j_r}(C_{jA(f(r))}+C_{jA(k)})p_{sj}+\\
(C_{A(f(r))f(r)}+ \sum_{k \in \mathbf{K}}C_{A(k)k}u_{f(r)k})
\end{aligned}
\end{equation}

Note that the product of decision variables, $p_{sj}h^s_{rl}$, $p_{sj}y_{rj}$ and $p_{sj}h^s_{rl}y_{rj}$, create a non-linearity. $p_{sj}h^s_{rl}$ and $p_{sj}y_{rj}$ appear directly while $p_{sj}h^s_{rl}y_{rj}$ appears in $W_{rj}y_{rj}$, which represents the execution of the matching function at the location $j$ ($j\in \mathbb{M},j\neq j_r$).  To express the optimization problem in a nominal linear programming setting, we linearize the above expressions via new auxiliary decision variables. To this end, a decision variable $\alpha_{rsj}$ is introduced as $\alpha_{rsj}=p_{sj}y_{rj}$ and the constraints should be added as follows,
\begin{equation}
\begin{aligned}
 &\alpha_{rsj} \leqslant p_{sj}, \\
 &\alpha_{rsj} \leqslant y_{rj},\\
 &\alpha_{rsj} \geqslant p_{sj}+y_{rj}-1 \label{a1}\\
\end{aligned}
\end{equation}

Similarly, a new decision variable $\beta_{rslj}$ is introduced as $\beta_{rslj}=p_{sj}h^s_{rl}$ and the constraints should be added as follows,
\begin{equation}
\begin{aligned}
 &\beta_{rslj} \leqslant p_{sj},\\
 &\beta_{rslj} \leqslant h^s_{rl} ,\\
 &\beta_{rslj} \geqslant p_{sj}+h^s_{rl}-1 \label{a2}\\
\end{aligned}
\end{equation}

The aforementioned constraint \eqref{cons_h4} is affected and should be rewritten as follows,
\begin{subequations}
\begin{align}
h^s_{rl} \leqslant \sum_{j \in \mathbf{M}} \beta_{rslj},\;\forall r\in \mathbf{R},\;\forall s\in \mathbf{S_r},\; \forall l\in  \mathbf{L_{rs}}   \tag{\ref{cons_h4}$'$} \label{cons_h4_new}
\end{align}
\end{subequations}

Also, note that $p_{sj}$ is a binary decision variable and causes $p_{sj}=p^2_{sj}$. Thus, we have $p_{sj}h^s_{rl}y_{rj}=\alpha_{rsj}\beta_{rslj}$. A new decision variable $\lambda_{rslj}$ is introduced as $\lambda_{rslj}=\alpha_{rsj}\beta_{rslj}$ and the following constraints should be added as follows,
\begin{equation}
\begin{aligned}
&\lambda_{rslj} \leqslant \alpha_{rsj},\\& \lambda_{rslj} \leqslant \beta_{rslj},\\&\lambda_{rslj} \geqslant \alpha_{rsj}+\beta_{rslj}-1 \label{a3}\\
\end{aligned}
\end{equation}

Hence, the product $W_{rj}y_{rj}$ can be rewritten as follows,
\begin{equation}
\begin{aligned}
\frac{\omega_{\varrho} (F_{\varrho r}y_{rj}+\sum_{l \in \mathbf{L_{rs}}}\sum_{s \in \mathbf{S_r}}\lambda_{rslj}O_l+\sum_{s \in \mathbf{S_r}}F^{back}_{sr}\alpha_{rsj})}{f_V^j}
\label{storage_intensive_comp}
\end{aligned}
\end{equation}

By checking whether users share the same metaverse region by $A(f(t))=A(f(r)), \{t,r\}\subset\mathbb{R}$, we can ensure the user could also view other updates happening in the same metaverse region. Based on the previous modelling of wireless channel, the wireless transmission delay in a mobility event can be written as follows,
\begin{equation}
\begin{aligned}
&\sum_{r\in \mathbf{R}}\frac{F^{fore}_{\eta r}+\sum_{t\in\mathbf{R}, A(f(t))=A(f(r))}\sum_{s\in\mathbf{S_r}}p_{sj}F^{res}_{st}}{ge_{rg}}+\\&\sum_{r\in \mathbf{R}}\sum_{k\in\mathbf{K}}u_{f(r)k}\frac{F^{fore}_{\eta r}+\sum_{t\in\mathbf{R}, A(t)=A(k)}\sum_{s\in\mathbf{S_r}}p_{sj}F^{res}_{st}}{ge_{rg}}
\label{wireless}
\end{aligned}
\end{equation}

Noticing that with constraint \eqref{cons_h7}, $\frac{1}{e_{rg}}$ can be replaced by $e_{rg}$ for linearization. By introducing a new decision variable $\phi_{rlsg}$ with following constraints,
\begin{equation}
\begin{aligned}
&\phi_{rsg} \leqslant e_{rg},\\&\phi_{rsg} \leqslant p_{sj},\\&\phi_{rsg} \geqslant e_{rg}+p_{sj}-1 \label{a4}\\
\end{aligned}
\end{equation}

Thus, the previous formula \eqref{wireless} can be updated as follows,
\begin{equation}
\begin{aligned}
&\frac{1}{g}\sum_{r\in \mathbf{R}}(1+\sum_{k\in\mathbf{K}}u_{f(r)k}) (F^{fore}_{\eta r}e_{rg}+\\&\sum_{t\in\mathbf{R}, A(f(t))=A(f(r))}\sum_{s\in\mathbf{S_r}}\phi_{rsg}F^{res}_{st} )
\label{wireless_new}
\end{aligned}
\end{equation}

Based on the above derivations and inline with \cite{huang2021proactive}, the overall latency can be written as follows,
\begin{equation}
\begin{aligned}
L=&\eqref{wireless_new}+\sum_{r \in \mathbf{R}}\sum_{i \in \mathbf{M}}(C_{f(r) i}+V_{ri})x_{ri}+\\
&\sum_{r \in \mathbf{R}}\sum_{i \in \mathbf{M}}\sum_{j \in \mathbf{M},j\neq j_r} (\eqref{storage_intensive_comp}+ C_{ij}\xi_{rij}+C_{A(f(r))f(r)}+\psi_{rj}D  )+\\ \\
&\sum_{s \in \mathbf{S_r}}\sum_{j \in \mathbf{M},j\neq j_r}(C_{jA(f(r))}+C_{jA(k)})p_{sj}+ \\
&\sum_{r \in \mathbf{R}}\sum_{k \in \mathbf{K}}(C_{A(k)k}+C_{ki}x_{ri})u_{f(r)k}
\end{aligned}
\end{equation}
where $V_{ri}$ is the processing delay of computational intensive function \cite{huang2021proactive}. $L_{max}$ here denotes the maximum allowed service latency and has $\frac{L}{L_{max}} \in [0,1]$.

The energy efficiency of the system during each service time slot is measured by the production of its total power and running time. The server total power consists of the transmission power and CPU processing power at target ECs. Denote the required CPU processing power of the user $r$ at the node $j$ as $P^{cpu}_{rj}$ and the CPU chip architecture coefficient as $k_0$ (e.g. $10^{-18}$) \cite{dong2019deep}. Then the power at the EC can be achieved through $k_0(f^j_V)^2$ (J/s) based on measurements in \cite{zhang2013energy}\cite{miettinen2010energy}. Noticing that for both conditions, the background contents are processed at servers, hence the consumed processing time of the server is,
\begin{equation}
\begin{aligned}
T_{cpu} =\sum_{r\in\mathbf{R}}\sum_{j\in\mathbf{M},j\neq m_r}V_{rj}x_{rj}+\sum_{r\in\mathbf{R}}\sum_{j\in\mathbf{M}}W_{rj}y_{rj}
\end{aligned}
\end{equation}
The wireless transmission happens no matter if executing foreground interactions at terminals. Since the selected data rate is $ge_{rg}$, the wireless transmission time is,
\begin{equation}
\begin{aligned}
T_{tran} =\sum_{r\in\mathbf{R}}\sum_{j\in\mathbf{M},j\neq j_r}\frac{F^{fore}_{\eta r}}{ge_{rg}}  + \sum_{r\in\mathbf{R}}\sum_{j\in\mathbf{M},j= j_r}\frac{F_{\varrho r}}{ge_{rg}}
\end{aligned}
\end{equation}
Finally, through the production of power and time, the total consumed energy at the server side can be written as follows,
\begin{equation}
\begin{aligned}
E_{server} &=\sum_{r\in\mathbf{R}}\sum_{j\in\mathbf{M}}(P^{tran}_{rj}T_{tran}+P^{cpu}_{rj}T_{cpu})\\
&=\sum_{r\in\mathbf{R}}\sum_{j\in\mathbf{M}}(\frac{N_j+\sum_{i\in \mathbf{M}, i\neq j}P_iH^2_{ri}d^{-a}_{ri}}{H^2_{rj}d^{-a}_{rj}}(2^{\frac{ge_{rg}}{B_j}}-1))\\
&\quad (\sum_{j\neq j_r}\frac{F^{fore}_{\eta r}}{ge_{rg}}  + \sum_{j= m_r}\frac{F_{\varrho r}}{ge_{rg}})\\
&\quad +\sum_{r\in\mathbf{R}}\sum_{j\in\mathbf{M}}k_0(f^j_V)^2 (W_{rj}y_{rj}+\sum_{j\neq j_r}V_{rj}x_{rj})
\end{aligned}
\end{equation}

At the terminal, this paper also follows the Amdahl’s law to model its energy consumption, in which considers the parallelism by the serial and parallel portion respectively \cite{amdahl1967validity}. In this paper, the metaverse AR functions work by serial and the parallel portion is assumed to be 0 for simplicity like \cite{song2019energy}. As mentioned earlier, the dynamic foreground interactions including some highly used AROs could be proactively cached at terminals with the matching function. The 3D background model, on the other hand, is much larger and might serve multiple users in a region. Hence, it is not recommended to be stored or processed at the terminal. In addition, the metaverse application should not exceed a certain portion of the whole terminal cpu resources so that other functionalities could work properly \cite{song2019energy}. Denoting the consumed portion as $\Gamma_r \in [30\%, 50\%]$ \cite{song2019energy}, then $\frac{V_{rj}x_{rj}}{\Gamma_r}$ means processing metaverse AR functions at the terminal requires a longer time. The Energy consumption of terminals could be written as follows,
\begin{equation}
\begin{aligned}
E_{terminal} =&P_{terminal}T_{terminal}\\
=&\sum_{r\in\mathbf{R}}\sum_{j=j_r}k_0(f^j_V)^2 \frac{V_{rj}x_{rj}}{\Gamma_r}
\end{aligned}
\end{equation}

Finally, the overall system energy consumption is $E=E_{server}+E_{terminal}$.
$E_{max}$ represents the maximum possible energy consumption of the system. It also has $\frac{E}{E_{max}} \in [0,1]$.

SSIM is applied to reveal the quality of perception experience. In this paper, the video coding scheme (e.g. H.264) and frame resolution (e.g. 1280$\times$720) are assumed as pre-defined \cite{kato2021split}. Then SSIM is mainly affected by data rate and a concave function could be applied to reveal the relation between them\cite{kato2021split}. Hence, denote the set of SSIM values for each ARO under corresponding data rates as $\mathbb{SSIM}_{l}, l\in\mathbb{L}_r$. The overall quality of perception experience $Q$ can be written as follows,
\begin{equation}
\begin{aligned}
Q=\sum_{r\in\mathbf{R}}\sum_{l\in\mathbf{L_r}}\sum_{g\in\mathbf{G}}\sum_{c\in\mathbf{SSIM}_{l}} e_{rg}c
\end{aligned}
\end{equation}
To maintain the user experience above an acceptable level, the perception quality constraint could be added as follows,
\begin{equation}
\begin{aligned}
\frac{Q}{Q_{max}}\geq Q_{bound}
\label{cons_quality}
\end{aligned}
\end{equation}
where $Q_{max}$ is the maximum quality through selecting max allowable data rate and storing as many AROs as possible.

We denote the weight parameter is denoted as $\mu \in [0,1]$ and the joint optimization problem can eventually be written as follows,
\begin{subequations}
\begin{align}
\mathop{min}
&\; \mu \frac{L}{L_{max}}+(1-\mu) \frac{E}{E_{max}}
\label{JOP:1}
\\
\nonumber
\\
\text{s.t.}\;& z_{rj} = 1-q_{rj}, \: \forall j\in \mathbf{M},  r \in \mathbf{R}
\label{JOPcon:1}
\\
&\sum_{r \in \mathbf{R}} (x_{rj}+y_{rj})\leq \Delta_j,\forall j\in \mathbf{M},j\neq j_r
\label{JOPcon:2}
\\
&\sum_{j  \in \mathbf{M}} x_{rj}=1,\forall r\in \mathbf{R}
\label{JOPcon:3}
\\
&\sum_{j  \in \mathbf{M},j\neq j_r} y_{rj} =1,\forall r \in \mathbf{R}
\label{JOPcon:4}
\\
&\xi_{rij} \leq x_{ri}, \: \forall r \in \mathbf{R}, i,j \in  \mathbf{M},j\neq j_r
\label{JOPcon:5}
\\
&\xi_{rij} \leq y_{rj}, \: \forall r \in \mathbf{R}, i,j \in  \mathbf{M},j\neq j_r
\\
&\xi_{rij} \geq x_{ri} + y_{rj} -1, \: \forall r \in \mathbf{R}, i,j \in  \mathbf{M},j\neq j_r
\\
&\psi_{rj} \leq z_{rj}, \: \forall r \in \mathbf{R}, j \in  \mathbf{M},j\neq j_r
\\
&\psi_{rj} \leq y_{rj}, \: \forall r \in \mathbf{R}, j \in  \mathbf{M},j\neq j_r
\\
&\psi_{rj} \geq z_{rj} + y_{rj} -1, \: \forall r \in \mathbf{R}, j \in  \mathbf{M},j\neq j_r
\label{JOPcon:10}
\\
&x_{rj}, y_{rj},p_{sj}, h^s_{rl}, z_{rj}, q_j\in  \{0,1\},\nonumber\\
&\alpha_{rsj},\beta_{rslj},\lambda_{rslj}, \phi_{rslg},\psi_{rj}, \xi_{rij}\in \{0,1\}, \nonumber\\
&\forall r \in \mathbf{R},  j\in \mathbf{M},  l \in \mathbf{L_{rs}}, s\in \mathbf{S_r}
\label{JOPcon:11}
\\
&\eqref{cons_h1},\;\eqref{cons_h2},\;\eqref{cons_h3},\;\eqref{cons_h4_new},\;\eqref{cons_h7},\;\eqref{cons_h5},\;\eqref{cons_h6}, \nonumber \\
&\eqref{a1},\;\eqref{a2},\;\eqref{a3},\;\eqref{a4},\;\eqref{cons_quality}\nonumber
\end{align}
\end{subequations}

As mentioned earlier, any assignment relating to the storage intensive functions ($y_{rj}$) are limited to only ECs and hence should apply the constraint $j\neq j_r$. The constraint \eqref{JOPcon:1} together with constraints \eqref{cons_h1} to \eqref{cons_h4_new} reveal the relation between pre-caching decisions and the cache miss/hit for each request \cite{huang2021proactive}. The constraint \eqref{JOPcon:2} is the virtual machine limitation while \eqref{JOPcon:3} and\eqref{JOPcon:4} guarantee the once execution of each function of a request at a single server as explained in \cite{huang2021proactive}. The constraints \eqref{a1} to \eqref{a3} and \eqref{JOPcon:5} to \eqref{JOPcon:10} are auxiliary and required to solve the product of decision variables for linearization.

\section{Numerical Investigations}
In this section, the effectiveness of the proposed optimization scheme, which will be referred to as Optim in the sequel, is investigated
and compared with a number of nominal/baseline schemes.
\begin{figure}[htbp]
\centering
\includegraphics[width=0.9\linewidth,height=0.5\linewidth]{topology_new.jpg}
\caption{A typical tree-like designed network topology}
\label{fig:topology}
\end{figure}
A nominal tree-like network topology shown as \eqref{fig:topology} is applied with 20 ECs in total and 6 ECs being activated for the current metaverse AR service and 30 requests are sent by MAR devices. The remaining available resources allocated for metaverse AR support within an EC are assumed to be CPUs with frequency as 4 to 8 GHz, CPU chip architecture coefficient as $10^{-18}$ (affected by the chip's design and structure) \cite{dong2019deep}, 4 to 8 cores and $[100,400]$MBytes of cache memory \cite{huang2021proactive}. Similarly, the mobiles AR devices are assumed to own a CPU with around 1 GHz frequency, 4 cores and $[0,100]MBytes$ available cache memory for Metaverse AR applications \cite{song2019energy}. According to \cite{chen2018understanding}, the power of AR applications should not exceed 50\% of the mobile device's CPU total power of the mobile device ($2-3W$) so that other functionalities could operate efficiently. Hereafter, a nominal frame rate is asssumed as 15 frames/second and the rendering happens at every other frame (\~ 133.2ms interval) \cite{cozzolino2022nimbus}\cite{niu2018learning}\cite{naman2013inter}. Thus, the service delay of the aforementioned work flow within the interval could be regarded as acceptable. Each request requires a single free resource unit for each service function, such as for example a Virtual Machine (VM) \cite{liu2018edge}. Up to 14 available VMs are assumed in each EC, with equal splitting of the available CPU resources \cite{huang2021proactive}. Note that different view ports lead to different models of the metaverse \cite{guo2020adaptive} and up to 4 different models can be cached. All target AROs must be integrated with the corresponding model and rendered within the frame before being streamed to the end user based on a matched result. After triggering the metaverse MAR service, pointers to identify AROs like a name or index are usually a few bytes  \cite{zhang2021multi} and hence their transmission and processing are neglected in the following simulations. The set of available data rates is $\{2,3,...,8\}$Mbps and its corresponding SSIM values set is $\{0.955, 0.968,...,0.991\}$ \cite{kato2021split}. We require the acceptable average SSIM above 0.97 ($Q_{bound}$). For a nominal 5G base station, we assume its cell radius as 250m, its carrier frequency as 2GHz, its transmit power as 20dBm, the noise power as $10^{-11}$W, the path loss exponent is 4, its maximum resource blocks as 100 and without the loss of generality, each user can utilize only one resource block \cite{korrai2019slicing}\cite{li2020computing}\cite{chettri2019comprehensive}. As mentioned earlier, we accept a predefined video coding scheme H.264 with a fixed frame resolution as 1280$\times$720 \cite{kato2021split} in RGB (8 bits per pixel). Based on the given resolution, the size of foreground interactions after decoding and compressing can be calculated through multiplying the coefficients $\frac{5}{9}$ and $10^{-3}$ \cite{guo2020adaptive}. Matlab on a personal PC with its CPU of intel i7, 6500U and 2 cores is applied for the simulation. Key simulation parameters are shown below in Table \eqref{tab:parameters}.
\begin{table}[ht]
\caption{Simulation parameters}
\begin{center}
\begin{tabular}{c|c}
\hline
\textbf{Parameter}&\textbf{Value} \\
\hline
Number of available ECs&$6$\\
\hline
Number of available VMs per EC (EC Capacity)&$14$\\
\hline
Number of requests&$30$\\
\hline
Number of available models per user &$4$\\
\hline
AR object size&$(0,10]$ MByte\\
\hline
Total moving probability&$[0,1]$\\
\hline
Cell Radius&$250$m\\
\hline
Remained Cache Capacity per EC&$[100,400]$ MByte\\
\hline
EC CPU frequency&[4,8] GHz\\
\hline
EC CPU cores&[4,8]\\
\hline
EC CPU core portion per VM&$0.25-0.5$\\
\hline
Remained Cache Capacity per Terminal&$[0,100]$ MByte\\
\hline
Terminal CPU frequency&$1$ GHz\\
\hline
Terminal CPU cores&$4$\\
\hline
CPU Architecture Coefficient&$10^{-18}$ \\
\hline
Foreground Interaction Computational Load&$4$ cycles/bit\\
\hline
Background Content Checking Computational Load &$10$ cycles/bit\\
\hline
Carrier Frequency &$2$ GHz\\
\hline
Transmission Power &$20$dBm\\
\hline
Path Loss Exponent&$4$\\
\hline
Noise Power&$10^{-11}$W\\
\hline
Number of Resource Blocks&$100$\\
\hline
Frame Resolution&1280$\times$720\\
\hline
Average latency per hop &$2$ ms\\
\hline
Cache miss penalty&$25$ ms\\
\hline
\end{tabular}
\label{tab:parameters}
\end{center}
\end{table}

In following figures and discussion, the optimized scheme considering terminals is denoted as OptimT while the other one without terminals is denoted as as OptimNT. The OptimNT scheme could be regarded as an natural extension from our previous work \cite{huang2022mobility}. Two other baseline schemes sharing same caching decisions as the proposed Optim scheme are also implemented for comparison. Those are the Random Selection Scheme (RandS) and the Closest EC First Scheme (CEC) \cite{tocze2019orch}. The RandS scheme operates a random EC selection while the other two both select the closest EC to the user's initial location. The CEC scheme also accepts the second closest one as a back up choice \cite{tocze2019orch}.

\begin{figure}[ht]
\centering
\includegraphics[width=0.9\linewidth]{W_D.jpg}
\caption{Overall Delay with Weight $\mu$ (6 EC, 30 Requests, EC Capacity is 14 and total mobility probability is 1)}
\label{fig:W&D}
\end{figure}
\begin{figure}[ht]
\centering
\includegraphics[width=0.9\linewidth]{W_E.jpg}
\caption{Average Energy Consumption with Weight $\mu$}
\label{fig:W&E}
\end{figure}
According to Fig. \eqref{fig:W&D}, the service delay for each request of proposed schemes drop as expected with an increasing weight $\mu$. With a larger weight, the proposed schemes tend to select a larger data rate and direct the service to more powerful ECs, which naturally lead to a smaller overall delay. Compared to the OptimNT scheme, for example, the gain in delay of the Optim scheme ranges from 1.9\% to 10.4\%. When seeking for the best energy efficiency ($\mu=0$), since the CPU resources at the terminals are also shared by other functionalities, the OptimT scheme also tries to avoid the occupation of terminals. Hence, in this case, these two schemes share similar solutions and approach to each other. Noticing that the proposed schemes do not care about latency cost, they could choose further and busy EC which even cause the OptimNT scheme become worse than the CEC scheme. Afterwards, as the weight $\mu$ increases and the emphasis is placed on latency rather than energy,  causes the OptimT scheme to allocate some foreground interactions at terminals and becomes better than OptimNT. Since the baseline schemes neglect energy consumption, service decomposition and mobility, their gaps to the proposed schemes become larger with an increasing weight. However, such gain in delay comes with an extra cost in energy consumption. As shown by Fig. \eqref{fig:W&E}, the energy consumption per request of the proposed schemes increase with a larger weight. Compared to the OptimNT scheme, the OptimT scheme consumes 2.9\% to 23.0\% more energy under different weights. Thus, it might not always be worthy to endure lots of energy consumption for narrow gains in delay. By selecting a suitable weight, a balance could be achieved with the OptimT scheme between delay and energy consumption. Through the utilization of terminals, the OptimT scheme becomes the most sensitive to the energy consumption and there could be instances that it might consume more energy that the RandS scheme.

\begin{figure}[ht]
\centering
\includegraphics[width=0.9\linewidth]{F_D.jpg}
\caption{Overall Delay with Foreground Interaction Size (6 EC, 30 Requests, $\mu=0.5$, EC Capacity is 14 and total mobility probability is 1)}
\label{fig:Fore&D}
\end{figure}
\begin{figure}[ht]
\centering
\includegraphics[width=0.9\linewidth]{F_E.jpg}
\caption{Average Energy Consumption with Foreground Interaction Size (6 EC, 30 Requests, $\mu=0.5$, EC Capacity is 14 and total mobility probability is 1)}
\label{fig:Fore&E}
\end{figure}
\begin{figure}[ht]
\centering
\includegraphics[width=0.9\linewidth]{B_D.jpg}
\caption{Overall Delay with Background Model Size (6 EC, 30 Requests, $\mu=0.5$, EC Capacity is 14 and total mobility probability is 1)}
\label{fig:Back&D}
\end{figure}
Clearly, the user experience could be elevated through viewing more AROs in foreground interactions or more delicate scenes from background models. Fig. \eqref{fig:Fore&D} reveals the variation of delay with the increasing foreground interaction size.When the average foreground interaction size is not too large and there are still enough resources at target ECs, OptimNT and baseline schemes increase almost linearly at a similar speed. When the size keeps increasing and resources become limited, the CEC scheme becomes the most sensitive one because it only targets on several closest ECs and is easier to trigger the penalty. The optimT scheme, on the other hand, maintains the least latency and the least increasing tendency. To this end, it could save up to 13.8\% and 51.7\% delay compared respectively to the OptimNT scheme and the CEC scheme. Fig. \eqref{fig:Fore&E} further reveals the variation of energy in this case. Baseline schemes process foreground interactions at ECs without considering energy. Hence, their decisions are not obviously affected by the size of foreground interactions and their energy consumption increases almost linearly. The OptimNT schemes keeps finding more suitable ECs according to current foreground interaction size and remained resources while the OptimT schemes further enables terminals to process some works. Compared to the CEC scheme, they could save over 14.3\% energy. It is necessary to point out that the energy consumption will not be taken into account when redirecting the request to the further core cloud and triggering the penalty. According to Fig. \eqref{fig:Back&D}, the background model size is much larger and could cause a significant increase in delay. Note that the terminals could take charge of some foreground interactions and hence could make room for background models in the OptimT scheme. It is still the best scheme in terms of delay and could be up to 9.8\% less than the OptimNT scheme. As mentioned earlier, the proactively caching and processing of background models only happen at ECs, these schemes share a similar level of increased energy consumption until triggering the overloading penalty.

\begin{figure}[ht]
\centering
\includegraphics[width=0.9\linewidth]{U_D.jpg}
\caption{Overall Delay with Average EC Utilization Rate (6 EC, $\mu=0.5$ and total mobility probability is 1)}
\label{fig:U&D}
\end{figure}
\begin{figure}[ht]
\centering
\includegraphics[width=0.9\linewidth]{U_E.jpg}
\caption{Energy Consumption with Average EC Utilization Rate (6 EC, $\mu=0.5$ and total mobility probability is 1)}
\label{fig:U&E}
\end{figure}

The number of available VMs activated in an EC is known as the EC capacity. For a given EC capacity (e.g. 14), the the ratio between the different number of requests (e.g. [30,40]) and the EC capacity could be applied to represent the average EC Utilization in the network. Then, this rate is normalized into [0,1] for better presentation. As shown in Fig. \eqref{fig:U&D} and \eqref{fig:U&E}, the increasing EC Utilization rate indicates a more congested network and hence as expected the delay and energy consumption increase as well. Compared to the OptimT scheme, the OptimNT scheme is still more sensitive in terms of energy but better in terms of delay. Thus, its consideration of terminals benefits delay at the cost of energy. Observe from Table \eqref{tab:no_mob}, that even when there is no mobility event, the proposed OptimT scheme is still slightly better than other baseline schemes because its flexibility of terminals could better avoid potential EC overloading. Therefore, the proposed OptimT and OptimNT schemes have an obvious advantage over baseline schemes and is recommended in a congested network and a high user physical mobility scenario. Especially when the MAR terminal still owns enough energy capacity, its computing resources should not be neglected and hence the OptimT scheme is more suitable in this case.

\begin{table}[htb]
\caption{Overall Delay in no mobility event \\($\mu=1$, 6 ECs, 30 requests and EC Capacity is 14)}
    \centering
    \begin{tabular}{c|c|c|c|c|c|c}
    \hline
         \textbf{Scheme}&\textbf{OptimT}&\textbf{OptimNT}&\textbf{CFS}&\textbf{RandS}\\
         \hline
         \textbf{Delay (ms)}&38.8&40.1&40.7&60.8\\
         \hline
    \end{tabular}
    \label{tab:no_mob}
\end{table}

\section{Conclusions}
Extending MAR applications into the metaverse, it is expected to incorporate rendering and updating of high quality AR metadata in order to provide a more realistic experience. Hence, such applications are delay and energy sensitive and are demanding in caching and computing resources. In this paper, a joint optimization scheme is proposed by considering explicitly the model rendering, user mobility and service decomposition to achieve the balance between energy consumption and service delay under the constraint of user perception quality for metaverse MAR applications. Technical improvements on AR devices allow them to take over more tasks and its potential in metaverse is explored and then compared with  the terminal oblivious one in this paper. A wide set of numerical investigations reveals that the proposed terminal aware framework provides improved decision making compared to baseline schemes for energy consumption and resource allocation for metaverse MAR applications, especially under a congested network and high mobility scenario.

\bibliographystyle{IEEEtran}


\section{Introduction}
The last years have seen the rise of Decentralized Finance (DeFi), a form of finance that does not rely on central financial intermediaries, such as banks and exchanges, to offer traditional financial services, and instead utilizes smart contracts on distributed ledgers (blockchains). The cryptographically secured digital tokens that are stored on these blockchains, called cryptoassets, include cryptocurrencies (like Bitcoin and Ethereum), utility tokens, security tokens and Non-Fungible Tokens (NFTs) \cite{Karim2022}. A simple application of this is that people can effectively invest in a company or project by acquiring and trading digital tokens of that company without intermediaries. Because these cryptoassets are freely traded, there is a lot of room for price speculation and manipulation \cite{Nizzoli2020}. Importantly, compared to traditional investing, this decentralized investing can be conducted by lay investors \cite{Abramova2021} who are often influenced disproportionally by information they receive from social media \cite{Glenski2019,Jahani2018}. This provides a strong incentive for such crypto projects to create artificial "hype" in order to convince more social media users to buy their token, or in order to manipulate the price of a token in a certain way. In particular, they provide payments in the form of "bounties" to users willing to engage with the project on social media in a positive way, such as following, commenting, retweeting and creating content.

This paper presents a dataset of crypto-related bounty events that coordinate social media campaigns to create artificial hype around a crypto project, as well as the users that engage in these campaigns. Our dataset was crawled from the \textit{Bounties(Altcoins)} subforum of the \textit{Bitcointalk.org} online forum. While a lot of research has studied inauthentic, manipulative, deceptive and collusive content online, this type of bounty hunting phenomenon is unique due to the particularities of the cryptoassets context. In particular, the sentiment and the volume of information online have been found to strongly influence market prices and user investing decisions in traditional finance \cite{Bollen2011b}, and even more so in relation to cryptoassets \cite{Domingo2020,Xie2020}. In the context of cryptoassets, these coordinated campaigns aim to achieve this in two ways; directly, by influencing social media users to buy an asset based on artificial hype, and indirectly, by influencing trading algorithms that make investing decisions based on sentiment mined from social media \cite{Garcia2015}. What makes this practice particularly concerning is that bounty hunters are typically paid in the token that they are promoting. This gives them an incentive to "dump" (i.e., sell) the asset when the campaign ends, and since they have inside knowledge of exactly when the campaign will end, this practice can be considered equivalent to a "pump-and-dump" scheme \cite{Hamrick2021} that will dramatically crash the price of the token causing the investors outside the campaign to lose the funds they invested.

While this type of bounty hunting phenomenon is unique, it builds on known practices that have been identified and studied earlier in the literature. These practices have been tailored specifically to the crypto space and are of varying ethical and legal positioning and justification. \textbf{Bounty programs}, in general, have been commonly used to manage rewards traditionally aimed at incentivizing positive and productive behavior, such as finding bugs in software code \cite{Ding2019}, providing worthy answers in question-answer platforms \cite{Parnin2012} and verifying the bias and safety of AI systems \cite{Brundage2020}. The practices and ethics of \textbf{advertising}, in general \cite{Schauster2016}, and social media promotion \cite{Zeng2021}, in particular, have been debated by researchers. Related work has highlighted particularly questionable practices, such as \textbf{astroturfing} (i.e., hidden coordinated information campaigns that mimic genuine user behavior by incentivizing agents to spread information online) for consumers \cite{Kauppila2022, Lee2013b} and citizens \cite{Schoch2022}. \citet{Dutta2021b} have studied \textbf{blackmarket services} that are employed by "collusive" users to inflate the popularity of their online account and get appraisals for their content, while \textbf{spam} has been a topic of intensive research over the years \citep[e.g.,][]{Benevenuto2010,Yardi2009}.

From the perspective of \textbf{finance}, researchers have examined the inner workings, the nuances and the relationships between cryptocurrency pump-and-dump schemes \cite{Hamrick2021}, market price manipulation \cite{Nizzoli2020}, and Initial Coin Offerings (ICOs) \cite{Ante2018}. From a \textbf{legal and regulatory} perspective, researchers are examining the ways and the extent to which social media content creators comply with the guidelines of the US Federal Trade Commission (FTC) which requires them to disclose their endorsements in order to prevent deception and harm to users \cite{Mathur2018}. Specifically in the crypto space, scholars are examining the practices of crypto users and businesses in order to determine the status of cryptoassets as \textit{securities} (i.e., investment contracts), something that would also place restrictions on discussions around cryptoassets and would require disclosure of any connections or endorsements \cite{Henderson2019}. Finally, such practices are in violation of the Terms of Service (ToS) of online platforms; for example Twitter's platform manipulation and spam policy\footnote{https://help.twitter.com/en/rules-and-policies/platform-manipulation} prohibits artificially amplifying content and makes specific mentions to coordinated activities for doing so. This mix of characteristics of other practices that is present in crypto-related social media bounty hunting muddles the way that campaign organisers, participants and even targets of the campaigns perceive the ethical and legal implications.

This paper presents a dataset collected from the \textit{Bounties(Altcoins)}\footnote{https://bitcointalk.org/index.php?board=238.0} subforum (message board) of the \textit{Bitcointalk.org}\footnote{https://bitcointalk.org/} forum describing crypto-related bounty events, the participants, the actions taken and the rewards received from 13-May-2014 when the first thread was started to 31-Dec-2022. We collected and analyzed information about 15.8K unique cross-media bounty events, 185K bounty hunters (i.e., users that participated in such events), 10.01M comments, 18M spreadsheet lines, 56K images, 42.1M Tweets and 33.9M links to Facebook posts, among other information posted on the subforum. We further enhanced the dataset to make it accessible to a broader set of researchers and enable future research in this area by linking information collected across the forum threads and aggregating it to calculate useful metadata. This resulted in a rich set of descriptive metadata; for example, we provide 31 data fields describing each Bounty event and 17 data fields describing each participant.

While previous research has focused on detecting coordinated social media campaigns and attempting to infer the actors and the details of deceptive actions from their social media traces \citep[e.g.,][]{Peng2017,Keller2020}, our dataset provides comprehensive information on these campaigns and their organisation from their source, including the structure of incentives, exact instructions and timing of actions, and a full account of all participants. We expect that this unprecedented detail afforded by our dataset will be invaluable to researchers studying online coordinated deceptive practices.

We make the entire dataset, along with a smaller sample and supplementary material, publicly available at the following link: (Dataset URL: \url{https://zenodo.org/record/7539179}).

\section{The Bitcointalk.org Forum and the Bounties(Altcoins) Subforum}
The BitcoinTalk forum was created by the developer of Bitcoin in 2009, the same year that Bitcoin was developed\footnote{https://bitcointalk.org/index.php?topic=5}. While originally focusing on Bitcoin itself, the discussions on the forum gradually expanded to include alternative cryptocurrencies (altcoins). The forum currently has more than 3.5M registered users and 61.5M posts on 1.3M topics\footnote{https://bitcointalk.org/index.php?action=stats}.
As the first and very popular community created around cryptocurrencies, the forum had an original intention of furthering adoption and supporting users. Areas of discussion include technical aspects of distributed ledgers, such as development and mining, economics, politics, as well as supporting users in using the technology, trading, and recovering from scams. As cryptocurrencies became more widespread and less technically-inclined users turned to the forum for information and advice, researchers utilized the BitcoinTalk forum to study crypto-related collective intelligence \cite{Jahani2018}, speculation \cite{Xie2020} and scams \cite{Vasek2019}.

The main BitcoinTalk forum comprises multiple subforums, each focusing on a separate aspect of cryptoassets. Each subforum contains many discussion threads initiated by different users. The earliest entries of the Bounties(Altcoins) subforum date back to 2014, although it didn't receive much attention until 2017. The subforum experienced a massive growth in popularity during 2017 – 2018, which aligns with the first steep increase in crypto adoption. More than 15,000 threads have been created since and it has evolved to the most popular subforum of BitcoinTalk\footnote{see note 5}.

Bounties(Altcoins) serves as a place to organize airdrops (cryptocurrency giveaways) and alert the public about upcoming projects or ICOs, however it is dominated by \textit{bounty events}. A bounty event involves the distribution of cryptocurrency or monetary rewards for the accomplishment of event-specific objectives. These rewards are typically distributed in the token being promoted, although it is not uncommon to use stablecoins (e.g., USDT) and even US dollars transferred via a service like Paypal. Each bounty event can have one or more \textit{campaigns} which are allocated a percentage of the total reward pool. The vast majority of the campaigns require participants to use their social media accounts to spread awareness about the project, however event organizers may also be interested in producing quality content with campaigns such as translation (e.g., of a whitepaper or  website content), copywriting, or visual content creation such as infographics or visual art.

Over time, certain norms have arisen to make it easier for users to participate in a bounty event. Although for some events the procedure differs slightly, most events follow a three-part structure:
\begin{enumerate}
\item A user shows their interest in participating by posting a “proof of registration” comment and including information about themselves (e.g., Telegram username, campaigns joined, crypto wallet address) which may differ slightly from event to event.
\item The participant completes the tasks defined in the campaign rules section. The event can last from a few weeks to a few months or even up to a year, therefore the tasks can be completed more than once (usually once a week).
\item The participant provides evidence of engagement with the project by posting “proof of participation” comments that include some required information (e.g., social media handle, social media interaction links) which is usually similar for all events. However, a small subset of events uses other means for providing evidence, such as Google forms.
\end{enumerate}

Users that employ social media bot accounts are  identified by the event organisers and are removed from the event. Participants are rewarded for their contribution at the end of an event. Each campaign has different amounts of stakes that are distributed to users which is proportional to the difficulty of the task, the quality of content, or the value provided by the user (e.g., a user with more Twitter followers will be allocated more stakes for the same task). The total reward can be calculated with the  formula
\[User \: Rewards= \frac{Campaign \: Prize \: Pool}{Distributed \: Stakes} * User \: Stakes\]

\section{Data Collection}
In this section we describe our data-scraping methods. The process consisted of crawling \textit{subforum} pages, \textit{user} pages, \textit{thread} pages, \textit{images}, and \textit{Google spreadsheets}. To achieve this, a Python crawler was developed which used HTML requests library\footnote{https://github.com/psf/requests} to fetch images and information from forum pages, BeautifulSoup\footnote{https://github.com/waylan/beautifulsoup} to parse HTML and gspread library\footnote{https://docs.gspread.org/en/v5.7.0/} to access Google Sheets API endpoints.

\subsubsection{Subforum and thread crawling}
The forum comprises multiple subforums, which contain a collection of threads divided into pages. Each subforum has a unique identifier; Bounties(Altcoins) ID is 238. Each page in the subforum contains up to 40 threads and has a unique identifier which starts at 0 for the first page and is increased by 40 for every subsequent page. Additionally, each subforum page contains a navigation strip, which can be utilized to retrieve the last page ID. This allowed us to generate a unique URL for each page by inserting the identifiers into \textit{https://bitcointalk.org/index.php?board=238.page\_id}. Crawling all pages resulted in retrieval of information from 15K unique events.

\subsubsection{Comments crawling}
Each forum thread has a unique identifier retrieved during subforum crawling. Similarly to subforum page, each thread had a comment page id which starts at 0 for the first page and is increased by 20 for each subsequent page and a navigation section which can be used to derive the last comment page ID. This allowed us to generate unique URLs for each comment page by inserting unique identifiers into \textit{https://bitcointalk.org/index.php?topic=thread\_id.page\_id}. 10M comments were obtained after crawling each page.

\subsubsection{User profile crawling}
Forum users are given a unique identification number which was retrieved during comment crawling. Inserting it into \textit{ https://bitcointalk.org/index.php?action=profile;u=user\_id} allowed us to access each user’s profile page. Information on 185K users was retrieved after crawling every page.

\subsubsection{Image crawling}
Some events in the forum used images to convey information, which had to be retrieved, converted to text and inserted back into the main post for more accurate processing. The image URLs could be found in HTML \verb|<img>| elements of the main forum post. In total 64K unique image URLs were detected out of which 56K were downloaded successfully and 8K were no longer being hosted.

\subsubsection{Spreadsheet crawling}
Some events used Google spreadsheets to track user progress and keep user information in one place. Spreadsheet URLs were collected from main posts using regular expressions to match spreadsheets domain\footnote{https:///www.docs.google.com/spreadsheets} and cleaned to extract unique spreadsheet identifiers. Using this information all rows were retrieved from Google sheets by querying Google Sheets API with gsread. This resulted in the retrieval of more than 20M distinct rows from Google spreadsheets.

\section{Data Processing}
In this section we provide an overview of how the collected data were processed and labeled and we explain the structure of the dataset.

\subsection{Forum Threads}
The primary focus of the dataset is bounty events. This section explains the methods used to extract information from the main post as well as how such events were distinguished from other sorts of events in the subforum.

\subsubsection{Categorization}
Information from 15,870 unique events was fetched from the first thread creation on 13-May-2014 to 31-Dec-2022. Each thread was assigned one or more categories based on the title, main post comment and user replies. The category of \textit{Bounty} was assigned to threads that:
\begin{enumerate}
\item Had seven or more out of 14 common Bounty event traits. Nine of the traits involved matching against a single word (Stake, Rewards, Campaign, General rules, Token, Bounty, Pool, Spreadsheet, Whitepaper). Five traits had multiple synonyms (Rules: 3, Reward allocation: 19, Proof: 2, Signature: 2 and Social media campaigns: 22); or
\item Had six out of the 14 common bounty event terms and more than 100 replies or the terms included \textit{Bounty} and \textit{Whitepaper}; or
\item More than 50\% of comments were classified as registration / participation (see next section for details) and the event was closed (the main post, title or both removed) or had more than 200 replies.
\end{enumerate}

Events containing the keyword \textit{bounty} in the title but not meeting any of the requirements above were assigned a category of \textit{Bounty(low quality)}. These categories had to be separated because titles were created by users and some threads that contained the \textit{bounty} keyword in the title had nothing to do with bounty hunting.

\begin{figure*}[t]
  \centering
  \includegraphics[width=\textwidth]{plots/participations_and_registrations_each_week.png}
  \caption{Number of unique participations and registrations per week (multiple comments of the same type by an individual in the same event are counted as one).}
  \label{fig:RSUencountered}
\end{figure*}
Other categories included: \textit{Moved} (event moved to another subforum), \textit{ICO} (Initial Coin Offering), \textit{Closed} (removed content), \textit{Announcement}, and \textit{Other}. 7,177 events were identified as Bounty events, 3,432 threads were identified as Bounty (Low Quality) and 5,261 events were assigned one of the other categories. While just fewer than half of the threads were categorized as Bounty events, 96.4\% of the collected comments were posted in Bounty events and 1.2\% to Bounty(Low Quality) events, demonstrating the importance of Bounty events in the subforum.
\subsubsection{Content processing}
Information about forum events was gathered from several places. Data which are included in every thread were collected from the subforum page which is well structured. This information includes \textit{thread title}, \textit{thread author}, \textit{username} and \textit{unique ID}, number of \textit{replies} and \textit{views}, and information about last comment: \textit{date}, \textit{author username} and \textit{ID}. The thread page also contained structured information that was common between all events such as event creation date and main post in HTML format. Further analysis was only carried out on events assigned a category of Bounty.

All HTML \verb|<a>| elements of the main post were inspected for links. By matching domain names with regular expressions, URLs were divided into the following categories: \textit{spreadsheet}, \textit{image} – embedded images that were converted to text, \textit{forum} – bitcointalk.org domain, \textit{social media} and \textit{other} – the rest of the URLs.

The remaining event information was obtained from text. To overcome a BeautifulSoup parser limitation when converting HTML to text and to preserve post structure, a new line character was inserted after each element that was not \verb|<br>| or inline. The text was split on new lines to aid the analysis process.

The \textit{Reward pool} size section of the event was identified by matching keywords (e.g., "Bounty pool", "Bounty details"). Subsequent lines were checked for three common reward pool patterns (e.g., "\$100 worth of ABC", "ABC 500", "200\$ in ABC token" ).

\textit{Token names} were detected in title, reward pool and text (near phrases such as "Token" or "Coin"). Each of these strings was tested against a set of conditions: two characters or longer, no words in a list of 27 phrases (e.g., “NFT”, “USDT”, “APY”), only contain characters A-Z and \$, not a word in a USA or UK dictionary. Strings that passed all checks and were most frequent are included in the dataset.

\textit{Reward allocation} was determined by matching phrases (e.g., "Reward allocation", "Budget"). Each subsequent line was inspected for \verb

Bounty events would often have sections for event \textit{general rules}, and  \textit{rules} and \textit{rewards} for each campaign. Retrieving these sections comprised two steps; detecting in which line the section began and where it ended:
\begin{enumerate}
\item The general rules section was detected by matching the text for relevant phrases (e.g., "Bounty rules"). For each campaign this was achieved by matching a phrase (e.g., "Twitter campaign") followed by the keywords “Rules” and “Rewards”.
\item Once the index of a line where the section began was found, the subsequent lines were checked for an ordered or unordered list. If found, this information outlined where the section began and finished.
\end{enumerate}
\subsection{Thread Comments}
\subsubsection{Categorization}
The dataset contains five comment types: \textit{mixed} (participation and registration in one), \textit{participation}, \textit{registration}, \textit{author} (comments by the thread author) and \textit{other}. Comment category was assigned with a 4-step process:
\begin{enumerate}
\item Check if userid of comment author and main post author match. If yes, assign author category, else next step.
\item Check how many out of six common proof of registration traits (headline “\#proof of authentication”, forum username, forum profile URL, telegram username, campaigns joined, wallet address) the comment has.
\item Check how many out of six common proof of participation traits (headline “week” or “day”, social media URLs, social media campaign names, social media username, numbered list, keywords such as "Like", "Retweet", etc) the comment has.
\item If a comment passes a registration threshold of 4 traits (3 if there are fewer than 5 lines in the comment) or has \# symbol with one of 75 synonyms for “proof of authentication” then the threshold for participation comment becomes 2 (it must contain social media links). If both thresholds are passed, the comment is assigned a category of mixed else, it becomes registration. If registration threshold is not passed, the comment is considered as participation with threshold of 3 (must contains social media links or keywords: “week”, “day”). If this threshold is passed the comment is assigned a category of participation, else it is assigned to other.
\end{enumerate}
The regular expressions used to match social media URLs are provided in the supplementary material.

One limitation of this process is detecting registration comments which include little information. Some registration comments are not detected, however lowering the threshold would result in misclassification of other comments.
\subsubsection{Content processing}
Each comment shares some mutual information retrieved from the forum: comment id, author username and id, post time. Additionally, the thread id where the comment was found is included in the dataset.
Comments of type \textit{other} and \textit{author} were not processed and contain the comment text saved in HTML format. This choice was made to preserve the structure of the comment since it would be lost if the comment was a reply (contained one or more \verb|<div class="quote">| elements).

On the other hand, \textit{participation}, \textit{registration} and \textit{mixed} comments were processed extensively. Mixed comments include a Boolean check and get analyzed by both algorithms. Most of the information was extracted with conditional statements and regular expressions utilizing library re\footnote{https://docs.python.org/3/library/re.html}.

Registration comments include information such as \textit{campaigns a user registered for}, \textit{telegram username}, \textit{twitter username}, \textit{forum rank} and \textit{post count} (specified by user), \textit{line number} in spreadsheets and \textit{crypto wallet address}. Additionally, the dataset also contains \textit{other information} which was rare and did not get assigned any label.

Participation comments include information about user \textit{social media username} (with social media platform), \textit{campaigns participated} in (based on participation links found) and all proof of interactions which include \textit{TweetIDs} and social media links (\textit{Twitter (without id)}, \textit{Facebook}, \textit{Instagram}, \textit{Telegram}, \textit{Reddit}, \textit{YouTube}, \textit{Medium}, \textit{LinkedIn}, \textit{Discord}, \textit{TikTok}, \textit{Steemit}, \textit{Image sharing}, \textit{Other})
\subsubsection{Google spreadsheets}
Each Google spreadsheet contains one or more sheets, which are processed independently. The process comprises two parts:
\begin{enumerate}
\item Many spreadsheets included banners of varying height, so we had to detect which row contains column names by iterating through the first 15 rows and checking which one has the most out of ten common column names (e.g., "timestamp", "twitter followers", "post count").
\item Label consequent rows based on column names.
\end{enumerate}

Unidentified columns \textit{labels} and \textit{data} are also included in the dataset. Identified columns include: \textit{timestamp}, \textit{proof of registration post URL}, \textit{forum rank}, \textit{forum profile URL}, \textit{forum username}, \textit{wallet address}, \textit{email address}, \textit{stakes}, \textit{twitter followers}, \textit{twitter audit URL}, \textit{post count}, \textit{social media username}, \textit{social media profile URL}.

\subsection{Images to Text}
Using Tesseract OCR\footnote{https://github.com/tesseract-ocr/tesserac}, locally stored images were converted to text and inserted into respective HTML \verb|<img>| elements. The process encountered a few limitations when dealing with intricate graphics pictures. Occasionally when dealing with such images, there were misinterpreted letters, random symbols, or parts of the text missing. The dataset contains the \textit{text} generated from locally retrieved images and corresponding \textit{image URLs}.

\begin{table}[t!]
\begin{center}
\begin{tabular}{ |l|l| }
 \hline
Data category &	Entries collected \\
 \hline
Total threads in subforum	& 15,870 \\
Bounty events	& 7,177 \\
Total comments in subforum & 10,024,001 \\
Bounty comments (participation)	& 6,926,577 \\
Bounty comments (registration)	& 1,670,871 \\
Bounty comments (author)	& 107,650 \\
Bounty comments (other)	& 1,183,612 \\
Social media links & 82,854,734 \\
Images (converted to text)	& 56,529 \\
User profiles	& 185,709 \\
Google spreadsheets  & 24,887 \\
Lines in Google spreadsheets	& 20,182,746 \\
Labeled Google spreadsheets entries	& 18,082,209 \\

 \hline
\end{tabular}
\end{center}
\label{demo-table}
\caption{Statistics of collected dataset.}
\end{table}

\subsection{Structure of the processed dataset} Our data collection and analysis process resulted in a PostgreSQL database with twelve tables. We exported the tables to twelve tsv files and added some additional annotations. The final dataset contains four tsv files of unprocessed information retrieved from the subforum, google spreadsheets, and image hosting services. To accommodate the largest audience possible and to aid further analysis by researchers, we also release eight processed tsv files resulting from the cleaning, merging and annotation conducted in the processing stage. In total, the files contain 159 fields (events – 31 fields, users – 17, comments\_participation - 29, comments registration – 21, comments\_author, comments\_other and comments\_raw – 7, rewards\_and\_rules – 4, spreadsheets – 18, spreadsheets\_raw – 5, images\_raw – 3, threads\_raw – 10). More extensive description of each file and field can be found in the \textit{Readme} file that comes with the dataset. Table 1 shows some statistics of the collected data.

\section{Exploratory Analysis}
\subsubsection{Subforum activity over time}
Figure 1 shows forum activity in terms of \textit{unique} user registrations and participations. If a user created more than one participation/registration comments in the same thread, they were only counted as one participation/registration. To preserve plot space, the visualization starts from 2017 as there are only ten threads that were created before that time.

From the illustration we can observe that bounty events first started gaining traction in the second half of 2017 and peaked during the first half of 2018, which aligns with the timeline of the first massive bull market run\footnote{https://coinmarketcap.com/charts/} and corresponding increase in crypto adoption. During this period we can observe up to 30,000 unique participations every week.

Since then, the forum has stayed active with some ups and downs in participation over time. After a substantial slump in 2019 and 2020 where activity fell to almost one tenth of the peak, activity started to slowly recover in 2021 and falling again from 2022.

\subsubsection{Size and activity of Bounty events}
Most Bounty events are substantially large to make a difference in promoting a project; 4,402 (61.4\%) events had more than 100 unique participants and 837 (11.7\%) had more than 1,000 unique participants. We found five outlier events where more than 5,000 forum users participated (Figure 2).

The number of activities that participants engaged in varied substantially across Bounty events. In the early days of the subforum the norms hadn't evolved yet and the comments did not have the structure that could help us crawl them successfully and categorize them as registration or participation comments. Still, a substantial number of events show relatively little activity with limited participation from users. On the other hand, we also identified a large number of events with several thousand participation comments; each one typically being a weekly comment including many activities across different campaigns (Figure 3).

\begin{figure}[t!]
  \begin{center}
  \includegraphics[width=\linewidth]{./plots/events_users_spaced_changed}
  \end{center}
  \caption{Number of unique participants per Bounty event. Note that for visualization purposes, the bins in the horizontal axis are not equal.}
  \label{fig:RSUencountered}
\end{figure}

\begin{figure}[t]
  \begin{center}
  \includegraphics[width=\linewidth]{./plots/event_lengths_changed}
  \end{center}
  \caption{Number of consecutive days a Bounty event stayed active.}
  \label{fig:RSUencountered}
\end{figure}

\begin{figure}[t!]
  \begin{center}
  \includegraphics[width=\linewidth]{./plots/participation_horizontal_log}
  \end{center}
  \caption{Number of participation comments per Bounty event. Note that the y axis is logarithmic.}
  \label{fig:RSUencountered}
\end{figure}

\subsubsection{Duration of events}
Figure 4 shows the duration of Bounty events. The duration is determined by calculating the time passed from the first post in the thread (which announces the beginning of the event) to the last (which typically ends the event). To account for inconsistencies with this rule, any period of more than three weeks between two consecutive comments was considered the ending of an event.

We can observe that 350 (5\%) events last less than a day and 30\% end in the first month, which leads us to believe that the majority of Bounty events end successfully.

A small number of events (92) kept operating for more than 300 days. These projects may have a long-term objective to remain in the cryptocurrency market and invest in a continuous bounty program.

\subsubsection{Bounty campaign popularity}
We discuss which campaigns are most likely to attract participating users and how many links grouped by campaign type have been collected from user comments.

Figure 5 illustrates how many unique participations for each campaign type were recorded in the subforum each week. Twitter and Facebook are the most utilized platforms across all time by a substantial margin. Telegram and Instagram started being utilized considerably in recent years.

In Figure 6 we can observe campaign popularity from another angle. Twitter and Facebook are still the most popular platforms with 42.1M and 33.9M URLs collected respectively, while all other platforms account for less than 9\% of all links collected. No Telegram links were collected as these tasks did not require users to share a proof of participation link. Campaigns that involved more complex or time-consuming tasks, such as creating YouTube videos or Medium blog posts are underrepresented compared to their relative importance.

\subsubsection{Reward allocation}
Bounty events typically involve more than one campaign, necessitating the distribution of the reward pool across campaigns. Each campaign gets allocated a percentage of the total pool based on the project owners' preferences and the goal of the event. We were able to determine reward allocation that added up to 100\% for only 2,705 of the 7,170 Bounty events, which we analyze below. Figure 7 shows the average reward allocation for each campaign type as a percentage of the full available reward pool. Campaigns that were encountered fewer than five times are grouped under the category “rare campaigns”.

The campaign with the most funds allocated on average is \textit{Signature}. Signature is an exclusive campaign to the forum that requires users to update their profile with a specific banner that is visible on all their posts, effectively acting as advertisements for the Bounty event. This suggests that event organizers may expect that forum users will consider campaigns with signatures to be more professional, trustworthy or popular, and thus will be more likely to join them.

The second most rewarded campaign type is \textit{Content creation}. This campaign type includes activities such as .gif and meme creation, infographics, and copywriting. Together with the \textit{Rare} category, which also attracts a substantial level of rewards, this suggests that Bounty events are particularly interested in unconventional, but also sophisticated and time-consuming activities of project promotion.

Twitter and Facebook are the third and fourth most rewarded campaigns, which is not surprising since they make up 91\% of all links collected from proof of participation comments and are key channels for spreading information about Bounty events online.

\begin{figure*}[t!]
  \centering
  \includegraphics[width=\textwidth]{./plots/campaigns_in_participation_comments_grouped_by_week}
  \caption{Number of unique participations (multiple participation comments from the same user in the same thread are counted as one) for different campaign types over time. The legend is sorted from most to least popular campaigns, top to bottom.}
  \label{fig:RSUencountered}
\end{figure*}

\begin{figure}[t!]
  \begin{center}
  \includegraphics[width=\linewidth]{./plots/participation_links_count}
  \end{center}
  \caption{Number of links collected from proof of participation comments for different types of campaigns.}
  \label{fig:RSUencountered}
\end{figure}

\begin{figure}[t!]
  \begin{center}
  \includegraphics[width=\linewidth]{./plots/reward_allocation_percentages_one_color}
  \end{center}
  \caption{Average percentage of reward pool that gets allocated to different campaign types in Bounty events.}
  \label{fig:RSUencountered}
\end{figure}

\section{Research Opportunities Using the Dataset}
The BitcoinTalk forum has a long history and has had significant influence in the cryptocurrency space. As the largest subforum, and one that encourages users to engage with social media, create content and participate in discussions, the Bounties (Altcoins) dataset can provide useful insights to researchers of various interests. Here we discuss some unique research opportunities arising from our dataset.

\subsubsection{Financial analysis} Market price manipulation has long been of interest to researchers, both in the stock market and in the crypto space \citep[e.g.,][]{Gandal2021}. Further studies can use our dataset to study the effect of coordinated social media campaigns \cite{Schou2022} by examining the movement of the prices of the tokens included in our dataset. This can show whether the bounty campaigns have been successful and whether they were intended to con investors out of their investments by inflating the price and then "dumping" the token \cite{Mirtaheri2021,Nizzoli2020}. Further research can also attempt to correlate the activity in the forum or the prices of the promoted tokens with the movements of the wider economy, Bitcoin or other cryptoassets \cite{Gandal2021} to examine how these affect online campaigns.

\subsubsection{Social media and network analysis} A lot of research has examined how and why people use multiple media \cite{Spiliotopoulos2020a, Alhabash2017}. Our dataset, which includes the details of multiple social media accounts for each user, can be valuable for social media researchers studying cross-media user posting practices. Researchers can also follow the social media links from the dataset to gain a better understanding of the effect of these campaigns. For example, how much of the discussion around a crypto project is organic and how much is driven by bounties? How many followers of a crypto project are genuine and how many are bounty hunters? Social network researchers can use the bounty hunter profiles provided in the dataset to determine details about the networks \cite{Himelboim2017} of bounty hunters; How many are connected and follow each other within and across media? What cliques are they part of? Are their followers genuine or are they just following one another and effectively promoting the project to the converted?

\subsubsection{Natural Language Processing} Researchers can follow the social media links and download text content from the Tweets, Facebook posts, Reddit discussions and blog posts to study the specific language used by bounty hunters. Natural Language Processing (NLP) techniques \cite{Hirschberg2015} can identify the topics discussed and the linguistic characteristics of this content, in order to detect it and protect social media users. Sentiment analysis techniques \cite{Valle-Cruz2022} can be used to quantify the effect of changes in online sentiment created by bounty campaigns on the crypto market \cite{Xie2020}.

\subsubsection{Policy and regulation} Legal scholars and policy makers can use the dataset to reach a more nuanced understanding of the crypto space and the relationship between social media or online communities and cryptocurrency investing. Examination of the structure and organization of Bounty events and the practices of crypto bounty hunters will inform the evaluation of the current regulatory state and protect naive investors. This is particularly important as the calls for regulation of the crypto space become increasingly insistent \cite{Henderson2019}.
\section{Broader Impact of the Work and Ethical Considerations}
Overall, there are numerous benefits that can be derived from our dataset. We bring awareness to a large number of Bounty events and campaigns that can potentially lead inexperienced crypto investors to make poor financial decisions. Our dataset can be a useful resource for researchers that can study the details and structure of the campaigns and develop ways to protect users and inform policy makers.

Of course, these benefits need to be considered together with the potential risks of collecting the data and sharing the dataset, especially risks related to unanticipated secondary use \cite{Salganik2019}. With regards to the data collection stage, while our dataset includes information and links from a range of social media and other online platforms, we only collected data from the BitcoinTalk forum. This data collection is in line with the Terms and Conditions of the forum, and, in fact, the forum specifically encourages data scraping from its boards\footnote{https://bitcointalk.org/index.php?topic=5208423.0}. The collected raw data were held in secure password-protected devices and cloud accounts.

Our dataset does not include sensitive information, therefore the risks associated with sharing the dataset are relatively low. We removed email addresses from the shared dataset, but we decided to keep other account information, such as social media account IDs and crypto wallet addresses. It was clear to us that these accounts were created for the purpose of participating in Bounty events and there is minimal overlap with forum users' personal social media accounts or other personal information. It is possible that a forum user in the future may decide to delete their account from the forum and their account information will remain in our dataset, but we consider that to be in line with the reasonable privacy expectations of public forum users, especially since a significant amount of content scraping takes place by other forum users in public\footnote{see previous note}. We do not foresee that the release of our dataset can put any of the forum users in any additional danger or risk, as the activities taking place during these Bounty events are currently within the law. Furthermore, while we did not employ any social media APIs to collect the data and, thus, we are not technically subject to any of their Terms and Conditions, we still decided to not share social media content (e.g., tweets) and to only share social media URLs and Tweet IDs. Finally, this work received ethical approval from our institution.

\subsubsection{Compliance with FAIR principles}
Our dataset adheres to the four FAIR data principles\footnote{https://force11.org/info/the-fair-data-principles/}. Our dataset is \textit{Findable} as it is assigned a unique and persistent Digital Object Identifier (DOI): \verb|10.5281/zenodo.7539179|. The dataset is indexed in a searchable resource and contains rich metadata that describe it. The data and metadata are retrievable by their identifier in an open and free manner, making our dataset \textit{Accessible}. The dataset is released in tsv format, making it \textit{Interoperable}. It is extensively documented with metadata describing every data field in a text file that accompanies the data. We also provide further details of the regular expressions used for some of the data processing we conducted in a supplementary file and we also share files with the raw collected data in order to enable unanticipated future uses. This makes our dataset \textit{Re-usable}.

\section*{Acknowledgments}
The reported research is supported by UKRI under Grant title: AGENCY: Assuring Citizen Agency in a World with Complex Online Harms. Grant reference: EP/W032481/2.
Further support was received by the EPSRC Centre for Digital Citizens. Grant reference: EP/T022582/1.