## 5 Method
### Problem Modeling
#### 5.3.1 Rescue Area Model  
The rescue region, as the end of the system's extension to the emergency rescue mission, typically deploys a large number of drones, unmanned vehicles, robot dogs, and IoT sensing devices, so the arithmetic resources of these devices are expressed in terms of clock cycle frequencies \(f_{user,i}\). The latency of the rescue task to be processed by the devices in the field can be expressed as  
\[T_{i,exe}=\frac{C_{i}}{f_{user,i}} \tag{1}\]  
The energy consumption under the same conditions can be expressed as  
\[E_{i,local}=k_{u}(f_{user,i})^{2}C_{i} \tag{2}\]  
In Equation (2), \(k_{u}\) is the energy coefficient determined by the computing chip architecture of the device used in the emergency rescue mission [23], which is proportional to the computing power of the device, considering that most of the devices and equipment in the emergency rescue scenarios are mostly mobile networks or IoT terminals, with limited computational power, so according to the method in the [24], the energy coefficient of the device on the rescue region side is taken as \(k_{u}=10^{-27}\). When facing complex tasks such as rescue intelligence fusion, multi-modal data alignment, UAV obstacle avoidance optimization, etc., the terminal device's own arithmetic and storage resources are difficult to support, and problems such as high energy consumption, high latency, and short endurance will occur, seriously affecting the efficiency of the rescue \begin{table}
\begin{tabular}{l l} \hline \hline
**Parameters** & **Implications** \\ \hline \(D_{i}\) & Input data volume \\ \(\left|h_{i}^{i}\right|^{2}\) & Channel gain between terminal device \(i\) and edge node \(j\) \\ \(C_{i}\) & Workload, i.e., CPU cycles required to complete the first task \\ \(e^{2}\) & background noise variance \\ \(T_{i,local}\) & Processing latency of tasks at local terminal devices \\ \(R_{i}^{i}\) & Transmission speed from terminal device \(i\) to edge node \(j\) \\ \(f_{user,i}\) & Terminal device CPU clock cycle frequency \\ \(T_{i,trans}^{i}\) & Upstream transmission delay of the device \\ \(E_{i,local}\) & Calculating Energy Consumption for Local Devices \\ \(T_{i,exe}\) & Processing latency at the MEC side \\ \(k_{u}\) & Terminal equipment energy factor \\ \(T_{i,unc}^{i}\) & Task \(i\) Total delay from offload to MEC processing \\ \(\delta\) & Latency Optimization Weighting Factors \\ \(f_{i,unc}\) & Arithmetic resources allocated by the MEC server for task \(i\) \\ \(F_{i,local}\) & Total task local processing overhead \\ \(f_{rec,total}\) & MEC total computing power resources \\ \(W\) & Upstream bandwidth \\ \(E_{i,trans}\) & Tasks \(i\) Offloading Transmission Energy Consumption to the MEC \\ \(w_{i}^{i}\) & Task \(i\) Upstream transmission link sub-band widths \\ \(F_{i,unc}\) & Task \(i\) Offload to edge layer Total processing overhead \\ \(P_{i}\) & Transmit power of the \(i\)th terminal device \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Table of meanings of model symbols. mission. Therefore, energy consumption and time delay are taken as the main indicators of actual task performance and user experience. In addition, in order to truly reflect the differentiated needs of rescue site tasks, the optimization weights of delay and energy consumption are flexibly adjusted, the delay weight factor \(\delta\) is introduced, and the total system overhead in the rescue area is expressed by \(F_{i,local}\). In actual emergency rescue tasks, flexible adjustment is made according to different types of application services and optimization needs. For delay-sensitive tasks, such as hostage rescue, threat judgment, etc., the delay weight factor \(\delta\) is further expanded to obtain better optimization of delay indicators, and the energy consumption weight factor is \(1-\delta\). The optimization process can be expressed as  
\[F_{i,local}=\delta T_{i,local}+(1-\delta)E_{i,local} \tag{3}\]  
When the rescue task exceeds the calculated capacity of the rescue equipment, overloading and other phenomena will occur.