An SDR-Based Experimental Study of Reliable and Low-Latency Ethernet-Based Fronthaul with MAC-PHY Split

: Cloud-Radio Access Network (RAN) is one of the architectural solutions for those mobile networks that aim to provide an infrastructure that satisﬁes the communication needs of a wide range of services and deployments. In Cloud-RAN, functions can be ﬂexibly split between central and distributed units, which enables the use of different types of transport network. Ethernet-based fronthaul can be an attractive solution for Cloud-RAN. On the one hand, the deployment of Ethernet-based fronthaul enables Cloud-RAN to provide more diverse, ﬂexible and cost-efﬁcient solutions. On the other hand, Ethernet-based fronthaul requires packetized communication, which imposes challenges to delivering stringent latency requirements between RAN functionalities. In this paper, we set up a hardware experiment based on Cloud-RAN with a low layer split, particularly between medium access control and the physical layer. The aim is to demonstrate how multi-path and channel coding over the fronthaul can improve fronthaul reliability while ensuring that: (i) latency results meet the standard requirements; and (ii) the overall system operates properly. Our results show that the proposed solution can improve fronthaul reliability while latency remains below a strict latency bound required by the 3rd Generation Partnership Project for this functional split.

Introduction
Cloud-radio access network (RAN) is one of the architecture enablers of the fifth generation of mobile communication networks (5G) paradigm, providing an innovative platform that can enhance flexibility and adaptability to mobile communication networks. 5G Cloud-RAN consists of three component elements, namely: a Central Unit (CU), a Distributed Unit (DU) and a Radio Unit (RU). The two components, CU and DU, are connected through a transport interface called midhaul, while the interface connecting DU and RU is called fronthaul [1]. 5G Cloud-RAN offers different radio network deployment scenarios each with different requirements.
Recent developments in the softwarization and virtualization of mobile networks [2] provide the platform for the deployment of Cloud-RAN solutions through a flexible functional split. A flexible functional split is a promising approach that aims to provide greater flexibility to sufficiently fulfill the diversified service requirements of 5G. Different functional splits impose different requirements on fronthaul, which have created new challenges in terms of optimizing the allocation of radio processing and transmission resources [3]. Consequently, the optimal split choice depends on a variety of factors, such as deployment scenario, availability of RAN resources and user traffic. For example, the work in [4] demonstrated how different use cases can impact the selection of RAN functional split. In our previous work, we also demonstrated the impact of user traffic, in particular 5G classes of traffic, on the choice of RAN functional split through an experimental evaluation of three different functional splits [5].
Different solutions exist for fronthaul in 5G new radio. While the fiber has clear benefits compared to other wired solutions in terms of bandwidth and speed [6], the potential for Ethernet has also been explored [7]. Ethernet is a promising solution for the transport network, given its wide availability and low cost. Therefore, several standardization bodies defined Ethernet fronthaul as a possible solution. In particular, Open RAN, which is an evolution of the Next Generation RAN architecture, considered Ethernet as a selected transport [8]. The Enhanced Common Public Radio Interface also defined a packetized interface employing an Ethernet or Internet Protocol, as a possible interface for the fronthaul [9]. Nevertheless, any fronthaul solution adopted needs to support diverse Cloud-RAN deployment scenarios and efficiently meet the key performance indicators of 5G.
Within the context of 5G, there is a growing interest in the need to provide high reliability while maintaining low latency to support the delivery of Ultra-Reliable Low Latency Communications (URLLC). One approach considered in the research on supporting URLLC is diversity, in which the same data are transmitted independently over multiple links. The authors of [10] show that, with multi-user diversity, an improvement in reliability and spectral efficiency can be achieved. Another approach considered to achieve the stringent latency-reliability requirement of URLLC is to use a combination of channel coding techniques and diversity. In this context, the authors of [11] showed, through simulation, the effectiveness of combining data duplication and network coding approaches. The combined approach achieved the highest reliability compared to network coding. While high reliability is foreseen for users' data, in Cloud-RAN architecture such reliability should also be considered for the fronthaul link.
To this end, and focusing on Cloud-RAN, there is a need for the fronthaul to maintain stringent key performance indicators of URLLC. The work in [12] proposed a multiple description coding approach to improve the quality of the signal received at the cloud in the uplink, assuming a multiple paths packet-based fronthaul. They validated the effectiveness of the approach through numerical results. In our previous work [13], we developed a Cloud-RAN model with medium access control (MAC) and a physical layer (PHY) split (split option 6 [14]) over Ethernet-based fronthaul for exploiting multi-path diversity using a fountain code. The aim was to investigate the reliability-latency trade-off on the fronthaul. We showed, analytically and through simulation, that the solution promises reliability enhancement. Following up on [13], in this paper, our main contribution concerns providing an experimental upgrade of the analytical simulation proposed and evaluating the performance of the solution. The experimentation will allow us to understand the best practices of providing fronthaul reliability while latency is compliant with the requirements of the 3rd Generation Partnership Project (3GPP). To the best of our knowledge, this paper provides the first evaluation of multi-path, Ethernet-based fronthaul using fountain code in a hardware testbed. Our particular contributions are as follows: • Proof of concept of the proposed solution in an industry-grade hardware testbed; • Consideration of a realistic scenario by taking into account varied packet sizes (32-1500 bytes) and background traffic in the fronthaul network; • Reporting and discussing the results of hardware experiments in order to evaluate the solution's performance.
The remainder of this paper is organized as follows: Section 2 provides a summary of the proposed reliable and low latency Cloud-RAN model with Ethernet-based fronthaul. In Section 3, a detailed setup of the hardware experimental testbed is provided and the evaluation methodology is described for examining the performance of the proposed system. Section 4 analyses the experimental results. Finally, the conclusion is in Section 5.

Reliable, Low-Latency Fronthaul Model
In 5G, it is recommended to avoid having a single point of failure that could affect a high number of radio sites. Where appropriate, it is important to enforce redundancy schemes. This is because, in a macro site where a single transport facility may aggregate multiple radios, the failure or repair of such transport equipment may have an impact on a large operator serving area. The key requirement of the 5G RAN transport network is to allow meshed connectivity to enable reliability and resilience [15]. In this context, a scenario in which the 5G transport network offers multiple connectivity is considered in this paper.
In [13], we presented a solution based on multi-path transmission with erasure coding (MPC) on the Ethernet-based fronthaul network with an MAC-PHY split. The aim is to achieve higher reliability without a significant impact on latency in a Cloud-RAN system.
Erasure codes, specifically fountain codes, are rateless in the sense that they do not exhibit a fixed code rate but are adapted to the channel conditions. The original data are split into k equal blocks, and then encoded independently and randomly, according to a degree distribution which determines the number of blocks to be exclusive-or-ed into n encoded blocks using an (n, k) maximum distance separable code [16]; this is referred to as the (n, k) fountain code (see Figure 1). One of the properties of fountain coding is that the receiver can retrieve the original transport block (TB) from any subset (k + ) of encoded blocks; where 0 ≤ ≤ n − k. Thus, the decoder starts decoding the message once the first k encoded blocks are received using the sum-product algorithm [16]. If these blocks do not have enough information to retrieve the original message then the encoder has to wait for more encoded blocks. In [13], we analytically derived the average latency using queuing theory by making the following assumptions: • Purging scenario, that is, after k out of n encoded blocks are received, the other n − k remaining encoded blocks are removed from the queues; • The switch on the fronthaul has a negligible delay and hence the switch delay is not included in the fronthul latency budget.
In this paper, however, we implement the same model in a software defined radiobased testbed, while fixing the value of n to 4, given the hardware limitations, to experimentally evaluate the framework and provide numerical proof on its performance. Furthermore, in this paper, we attempt to overcome the constraints raised by assumptions taken in [13] as follows: • Assess the impact of the proposed solution on end-to-end system performance: by executing the solution on a hardware testbed, we can ensure that the system is functioning properly by ensuring that user equipment remains synchronized with the network and maintains network connection, as well as that network resources, such as memory, storage space and queue buffers, are sufficiently available for executing the proposed solution; • Packets are not removed from the fronthaul network; that is, after receiving k out of n encoded blocks, the remaining n-k encoded blocks are not removed from the fronthaul network and they will continue to be processed, which is more realistic; • Consider internal process delay in the (CU + DU) entity: processing time including scheduling, queueing, encoding and packetizing data which might affect the per-formance of the system. The time taken depends, essentially, on capabilities of the hardware used and how functions are processed. In this experimental, function blocks are sequentially processed on a general purpose processor; • Include switch queueing delay: the amount of time spent queuing at the switch aggregator to demonstrate the feasibility of aggregating traffic in the fronthaul network, resulting in more realistic latency measurements. The worst case scenario happens when all the n encoded blocks arrive at the switch aggregator at the same time. Such a scenario is very likely to occur when the n encoded blocks are serialised at the same time on n separate fronthaul paths with the same capacity; • Include network driver delay: the amount of time it takes to send a packet onto a fronthaul network, which is subject to a queueing delay; • Emulate traffic congestion on the fronthaul to account for scenarios with background traffic.
For the analysis, we continuously generate data in the (CU + DU) entity to be transmitted to the user equipment via the fronthaul. The experiment is repeated several times, then the average latency and the probability of being able to transmit a packet over the fronthaul within a latency deadline are measured.

Experimental Testbed & Evaluation Methodology
In this section we detail our experimental testbed and describe our evaluation methodology.

Implementation of Experimental Testbed
For our experimentation, we consider a long-term evolution system based on the Open Air Interface [17]. Our choice of the long-term evolution module is based on the availability of a reliable open source platform. Hence, user equipment, CU, DU, and RU are based on Open Air Interface implementation comprising full long-term evolution functionalities whereby the CU is collocated with the DU.
To exploit the concept of multi-path diversity with channel coding in the Cloud-RAN platform, we implemented further amendments in the Open Air Interface to: • Decouple RAN functions between (CU + DU) entity and RU entity; • Support channel coding in order to encode/decode data streams; • Packetize/depacketize packets to transmit/receive them over the Ethernet-based fronthaul interface; • Support the multiple Ethernet-based fronthaul by transmitting over multiple Ethernet ports, each connected to a separate Ethernet link.
The experimental setup and data flow are shown in Figure 2. The (CU + DU) and the RU run on two separate servers each with 8 gigabytes of random access memory (RAM) with a Xeon 1220, and 4 cores. While the user equipment runs on a personal computer with 4 gigabytes of RAM with an Intel core i5. All hosts have a network interface card with a speed of 1 Gigabit and operate on Ubuntu 14 with a low latency kernel. The system operates on frequency division duplex on band 7 with 5 MHz bandwidth. The main configuration parameters are listed in Table 1; other Open Air Interface parameters are set to their default values.
The (CU + DU) entity accommodates MAC, Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP) and Radio Resource Control functionalities, while PHY and Radio Frequency functionalities are located in the RU. The (CU + DU) entity is connected to 4 Ethernet fronthaul links each 3 meters long and with a capacity of 1 Gigabit. The four links are connected to a 1 Gigabit layer 3 switch that switches packets to the right port based on internet protocol addresses. The output port of the switch is connected via a 3 meter long Ethernet fronthaul, with a capacity of 1 Gigabit, to the RU. This latter is connected to the user equipment via Universal Serial Bus 3 cables and two Universal Software Radio Peripherals, which are responsible for transmitting and receiving radio frequency signals. The Universal Software Radio Peripherals are connected through SubMiniature version A cables of a 1 meter long. In this experimentation, the analysis is applied only to the downlink communication.

Evaluation Methodology
To evaluate the performance of the system, once the radio access bearers for the data flow are established, User Datagram Protocol (UDP) packets are injected as user data at every frame into PDCP at the (CU + DU) entity. PDCP, then, adds a PDCP header to the UDP packet then delivers it to RLC. RLC informs its buffer occupancy to MAC to determine the TB size. MAC then requests data from RLC and composes the TB. Thereafter, the TB is processed by the coding block. The coding block has two main blocks ( Figure 2): • Splitter which splits each TB into k = 2 equal blocks; • Encoder that encodes the k blocks into n = 4 encoded blocks of the same size using fountain code and sends each encoded block into one of the n fronthaul paths.
The encoded blocks are then packetized to Ethernet packets and are transmitted to RU via a raw Ethernet socket over the fronthaul. The receiver can retrieve the original TB from any subset ≥k of encoded blocks.
In this experiment, latency is measured as the round trip time (RTT) of one packet from the MAC to the PHY layer. Procedures involved in the measurement of RTT are summarized in Algorithm 1. Packetize data by adding Ethernet header 11: Write packet to raw socket 12: end procedure 13: procedure RECEIVE PACKET FROM FRONTHAUL NETWORK 14: Read packet from raw socket 15: Depacketize data by removing Ethernet header 16: end procedure 17: procedure PREPARE DATA 18: Get data to be transmitted from scheduler 19: Append received sequence number to the data (1) latency(1), latency (7) is the time that the fronthaul interface takes to packetize data and write the packet descriptor onto the network driver transmit queue. latency(2), latency(8) is the time taken for the network driver to fetch the packet and launch it onto the fronthaul network. Since packets are fetched one by one from the transmit queue, this latency is subject to a queueing delay. latency(3), latency(9) is the time to transport data on the fronthaul network and is given by: latency (3,9) where t tran is the transmission time, that is, the time taken to transmit a packet over a fronthaul link and is defined as the packet size over the bit rate of the fronthaul link, t prop is the propagation time, that is, the time taken for a packet to propagate between two nodes. The propagation time is calculated by the distance over propagation speed in the fronthaul. N link is the number of fronthaul segments between the (CU + DU) entity and the RU entity, t proc is the amount of time the switch requires to process a packet for routing (encapsulation/decapsulation and table lookup) and t que is the queueing delay in a switch when there is a contention at its ports. Figure 4 shows that 4 fronthaul paths are input to the switch, all of which must be directed to the same destination, that is, RU. Therefore, packets may encounter queueing delay at the switch. Therefore, t que ≥ 0 and there is one switch in the experimental setup, hence N switch = 1 in Equation (2).  latency(4), latency(10) time taken for network driver to write packet descriptor in the queue. This latency is subject to a queueing delay when multiple data are sent over the Ethernet sockets. latency(5), latency (11) is the time that the fronthaul interface takes to read data from the network driver queue and depacketize data by removing the Ethernet header from the packet.
latency (6) is the protocol stack processing time of the request at the (CU + DU) entity to prepare data. This latency depends on the processing capability of the central processing unit.
The average latency of RTT is computed as: where N is the number of RTT samples collected during the execution of the experimental test.

Analysis of the Experimental Results
In this section, the performance of the system is evaluated by evaluating the results of the fronthaul latency, jitter, and probability of error. How these quality metrics meet the requirements of the 3GPP are also evaluated. The 3GPP specifies that the maximum allowed one-way latency for the MAC-PHY split (Option 6 according to 3GPP terminology) should be 250 µs (Table A-1 in [14]). The maximum allowed average RTT latency, therefore, is 500 µs (250 × 2). Since RTT in this experiment is measured as stated in Section 3.2, the analysis considers 500 µs as the maximum acceptable latency on the fronthaul.

Analysis of Latency and Jitter for MPC
In the first experiment, the performance of MPC is evaluated in terms of latency and jitter. The performance is evaluated for scenarios with packet sizes of 32 bytes up to 1500 bytes to cover both URLLC and enhanced mobile broadband 5G classes to understand how the packet size impacts the fronthaul latency. UDP packets, thus, with different sizes, are injected into the PDCP layer in the (CU + DU) entity in every frame. The protocol stack processes the packet then the MAC encodes it to n = 4 encoded blocks and transmits them on the fronthaul. The latency is measured as the RTT as explained in Section 3.2. The percentiles and probability density function results of the RTT are shown in Figures 5 and 6, respectively.  Figure 5 shows the results for different percentile values of the latency as a function of UDP packet size. In general, as the UDP packet size increases, the percentile values of latency increase too; this is because larger packets take longer to be processed. The RTT for a packet size of 100 bytes is, however, less than that for the 32 bytes and 50 bytes packet sizes. The reasoning behind this behaviour is that the packets of 32 bytes and 50 bytes are split by the coding block in the (CU + DU) entity to 16 bytes and 25 bytes, respectively. Even when the overhead header is added, the two packet sizes are still less than the minimum 64 bytes of the Ethernet frames. Therefore, prior to transmitting these packets, padding is added by the Ethernet network card, which adds an extra delay to their RTT.  Figure 5 shows that MPC provides promising results, as 95th percentile values remain below the maximum acceptable fronthaul latency for the MAC-PHY split. Figure 5 also shows that the 25th, 50th and 95th percentile values are of low variability as they are close to each other. The difference between the 95th and 25th values is 8 µs.
Focusing on the 50th percentile result, if the packet size is less than 500 bytes, the increase in latency is low and is around 4.43% from the packet size of 32 bytes to the packet size of 250 bytes. On the contrary, with packet sizes larger than 500 bytes, the increase in latency is 26% for a packet 3 times larger than 500 bytes. Ssuch behaviour can be observed in Figure 6, whereby the probability density distributions of packet sizes from 32 bytes to 250 bytes are very close to each other. However, for packet sizes ranging from 500 bytes to 1500 bytes, the probability density distributions are further apart. Another observation from Figure 6 is that the standard deviation increases with the size of the packet. For example, for packets of size 1500 bytes, the deviation is 10 µs, which is approximately two times as large as for packets of size 32 bytes. This indicates that the larger the packet size, the higher the variations in the processing time of the protocol stack, encoder/decoder and transport network. This plot provides insight into how to choose the packet size to be transmitted on the fronthaul. For example, if the probability density distribution of the latency for a service should have a deviation of less than 8 µs, then the choice of packet size ≤ 250 would satisfy the requirement. It can be concluded from Figures 5 and 6 that the average latency complies with the requirements of 3GPP, that is, staying below 250 µs [14].
Further analysis of jitter can be found in Figure 7. Two factors primarily introduce jitter: (i) the packet switch network, which can introduce variation into the packet delay when processing packets; (ii) the operating system, whereby the variation of system daemons and interrupts results in jitter. From Figure 7, it can be seen that the distribution of jitter remains the same for different packet sizes and is just below 2 µs. The tail latency of Figure 7 shows that latency values greater than 10 µs have a very low probability that is close to zero.

Comparison of MPC and Multi-Path Fronthaul with Duplication (MPD)
The second experiment compares the performance of MPC to that of the baseline MPD, which replicates the same data stream across multiple fronthaul paths. In particular, the analysis evaluates how the probability of error is improved by either of these two schemes and what the impact on the latency is. In this experiment, the focus is on the URLLC service, particularly on the tactile interaction in which reliability with low latency are key aspects. The payload sizes of the tactile interaction are typically ≤256 bytes and the error probability requirement is 10 −5 [18].
Fixed UDP packets of a size of 120 bytes are injected in PDCP in every frame. The probability of error vs latency function is presented in Figure 8, where the probability of error is defined as the probability that the measured RTT latency exceeds a predefined latency deadline t, mathematically expressed as: P(X > t). This probability of error represents the packet error rate due to the fact that some packets arrive late or never arrive due to factors such as buffer overflows, queueing, and so on.  It can be seen that, for latency values less than 250 µs, the performance of MPC and MPD is generally the same. However, as latency increases to higher than 250 µs, MPC delivers a lower error probability. MPC can achieve a latency reduction of 73 µs, with respect to MPD at the error probability of 10 −5 . It is interesting to look specifically at the performance at the latency of 500 µs, which is the maximum acceptable RTT latency on the fronthaul for the MAC-PHY split [14]. At this point, shown by the vertical black line in Figure 8, MPC clearly outperforms MPD and can achieve an error probability of 10 −5 at 288 µs latency, leaving a margin of 212 µs to the maximum allowed RTT. Therefore, MPC is set to benefit from both diversity and the splitting of packets into smaller blocks.
With MPC reaching an error probability of 10 −5 at a lower latency than MPD, a larger gap to the maximum allowed RTT can be gained. This gain can be beneficial for fronthaul dimensioning by allowing the distance between the (CU + DU) and the RU entities to be increased. The fronthaul distance can be extended by t gap /(prop delay × 2), where t gap is the time gap to the maximum allowed RTT, prop delay is the propagation delay in the Ethernet, which is 5 µs per km [19] and 2 accounts for the round trip. In our setup, for example, given that t gap = 212 µs at an error probability of 10 −5 for MPC (see Figure 8), the fronthaul can be extended by 42.4 km. Now, the performance of multi-path fronthaul is evaluated by emulating the delay in the fronthaul transport. In our next experiment, a delay is added to the fronthaul path 2 to emulate traffic congestion. An additional delay on path 2 will clearly affect the delivery of important information since link 2 carries the information required for decoding data. To investigate whether the delay would affect the performance of MPC due to the waiting effect described in Section 2, the network delay is emulated by using NetEM to add a normal distribution delay of 100 µs ± 10 µs. Figure 9 shows the probability of error as a function of the latency. It can be seen that MPD and MPC start with the same probability of error, but after latency exceeds 100 µs, the performance of the two schemes alternates. However, MPD outperforms MPC at an error probability of 10 −5 . Thus, in this case, where the extra delay is simulated in path 2, MPC is more affected than MPD because MPC needs to wait for more encoded blocks to be received to successfully decode the blocks. Here again, taking the maximum acceptable RTT latency of 500 µs on the fronthaul for the MAC-PHY split [14], which is shown by the vertical black line in Figure 9, MPC can achieve an error probability of 10 −5 at latency 158 µs earlier than the maximum allowed RTT.  Aside from the benefit of MPC in enhancing reliability while the latency remains below a strict latency bound, another aspect to consider is the load on the fronthaul network introduced by MPC and MPD. For each data point of size S bits, MPD duplicates a full copy of the data into n blocks of size S bits. On the other hand, an (n, k) MPC encodes the data into n blocks of size S/k bits. For example, if 1 packet of size S bits is to be transmitted every t milliseconds on average, the load on the fronthaul generated by MPC and MPD, denoted as MPC load and MPD load respectively, can be calculated as: MPC load = (S × 1000/t) × n/k (bits per second) MPD load = (S × 1000/t) × n (bits per second). (4) Equation (4) demonstrates the potential benefits of MPC over MPD in reducing the load on the fronthaul network, allowing for a significant reduction in the required bandwidth by a factor of k (1 < k < n), resulting in a reduction in fronthaul cost.
The results obtained under the particular system parameters set out in this paper show that MPC performs well despite the delay that is introduced into the fronthaul network. The budget latency, however, can be lowered by considering some aspects of the experiment deployed in Section 3, such as the deployment of specific devices such as accelerators for the encoder/decoder and RAN functions that are computationally intensive, and the use of the Data Plane Development Kit for fast packet processing.

Conclusions
This paper validates the Cloud-RAN model with the split between MAC and PHY over Ethernet with additional reliability using MPC. As proof-of-concept for the proposed solution, we present an end-to-end Cloud-RAN testbed that integrates user equipment, RU, DU, CU, and a fronthaul network. We first analyse the performance of MPC in terms of latency and jitter using different packet sizes. The results were satisfying in terms of average RTT latency being compliant with the requirements of 3GPP, that is, staying below 500 µs. From the latency constraint perspective, the findings in this chapter demonstrate how the size of the packet has a significant effect on RTT. To lower the RTT, it is very important to choose the right size of the packet.
Then, we compared the performance of MPC with MPD from a probability of error perspective. The experimental results show that MPC achieved an error probability of 10 −5 at a latency lower than MPD, that is, a latency reduction of 73 µs. However, when one of the paths is simulated with an extra delay, MPC achieved an error probability of 10 −5 at a latency 20 µs later than MPD. Nevertheless, MPC can deliver an error probability of 10 −5 while staying below the acceptable latency on the fronthaul for the MAC-PHY split, in addition to the advantage of MPC over MPD in terms of reducing fronthaul load. The results obtained in this paper are consistent with the results reported in [12,13] in validating the effectiveness of MPC, opening the possibility to implement MPC as a means of improving reliability in a Cloud-RAN system.
The deployment described in this paper is an experimental facility that may easily be expanded to a larger scale testbed in terms of network architecture, fronthaul network topology, and system traffic load. Funding: This work has been partially supported by the EU H2020 Primo-5G project. Additional support for this research is received form The Engineering and Physical Sciences Research Council (EPSRC) industrial Cooperative Awards in Science & Technology (iCASE) award and from BT and the EPSRC infrastructure grant, INITAITE (EP/P003974/1). Data Availability Statement: Not Applicable, the study does not report any data.

Conflicts of Interest:
The authors declare no conflict of interest.


Securing your Airspace: Detection of Drones Trespassing Protected Areas

There has been a rapid growth in the deployment of Unmanned Aerial Vehicles (UAVs) in various applications ranging from vital safety-of-life such as surveillance and reconnaissance at nuclear power plants to entertainment and hobby applications. While popular, drones can pose serious security threats that can be unintentional or intentional. Thus, there is an urgent need for real-time accurate detection and classification of drones. In this article, we perform a survey of drone detection approaches presenting their advantages and limitations. We analyze detection techniques that employ radars, acoustic and optical sensors, and emitted radio frequency (RF) signals. We compare their performance, accuracy, and cost, concluding that combining multiple sensing modalities might be the path forward.

I. INTRODUCTION
Unmanned aerial vehicles (UAVs) have evolved rapidly over the past few decades leading to mass production of affordable drones [1]. From kids and hobbyists to police officers and firefighters, drones have found novel applications and use cases. For instance, Google and Amazon use drones for merchandise delivery while law enforcement leverages drones for speed checks. During disasters, drones can help first responders to establish communications and locate victims. Unfortunately, similarly to most technological advancements, drones can be (ab)used for illicit activities [1]. Indeed, criminals groups use drones to smuggle goods and breach secure locations, to name a few. Even benign uses of drones can be unlawful, including unintentional invasion of privacy, harm to humans and infrastructure due to collisions, and interference with other flying objects (e.g., airplanes). For example, in 2016 Dubai airport reported that it had to shut down three times to avoid unauthorized drone activity [1].
Given the proliferation of drones and their use for both good and bad, there is an urgent need for accurate drone detection and classification into permitted and not-allowed while tracking their trajectory. Currently, there are different methods for detecting drones in the airspace: radars (e.g., [2]), acoustic sensors (e.g., [3]), Radio Frequency (RF) signal detection (e.g., [4]), visual and optical sensors (e.g., [5]), as shown in Fig. 1. The drone detection system is typically deployed in close proximity to the area of interest. When the drone's trajectory enters or is projected to enter the no-fly zone, the detection system can track the drone and identify it either as a friendly or an unknown intruder. Subsequently, the system can notify an operator or enforce an automated policy.
In this survey article, we present an overview of the available approaches for detecting drones. Our aim is to understand the design space for drone detection techniques and expose any inherent or situational limitations for each of these approaches. We also explore other aspects that are pertinent to selecting the drone detection approach, including cost, power consumption, accuracy, and environmental variables that might affect the performance of the detection system. Initially, we present different radar approaches. We put a significant focus of the survey on radars because they are of the most promising methods in terms of accuracy. However, their cost and deployment requirements can render radars unsuitable for some use cases. Continuing to explore drone detection techniques, we discuss offthe-shelf acoustic sensors that offer a cost-effective but less accurate alternative for radars in some deployment scenarios. Next, we explore approaches based on RF transmission of the drone followed by visual and optical sensor detection methods. Finally, we end our survey with a discussion of multi-modal and sensor-fusion approaches in which multiple sensors are employed to improve the detection accuracy either in tandem or in sequence. A first-glance summary of the advantages and disadvantages of the drone detection approaches we cover in this article is summarized in Table I. II. RADARS The current state-of-the-art in moving object detection problem, whether it is detecting a big drone or a small bird, involves some form of radar. Evaluating the feasibility of using radar for UAV detec- tion has received considerable attention [2], [6]- [8]. However, there are some practical limitations and cost considerations when designing and deploying a radar suitable for detecting drones.

A. Radar Cross Section
The main challenge is the variable size of UAVs which can make them invisible to traditional radars. Due to the small size of some UAVs and their main body construction in terms of materials, which can have a low reflection index, the Radar Cross Section (RCS) for them is extremely small and makes them hard to detect. Both theory and practice support this fact because the received power from the target object is a function of its RCS, and with smaller RCS, there will be smaller received power.

B. Frequency and Bandwidth
Another design parameter for radars is their operating frequency: high-frequency radars are more expensive but can detect smaller UAVs. An additional advantage of high-frequency radars is their larger bandwidth, and finer resolution generates more accurate results. For example, a radar with a bandwidth of 1GHz has a range resolution of 15cm (range resolution equals the speed of light divided by twice the bandwidth).

C. Radar Signal Power
In practice, radars with higher transmission power offer improved detection results. In terms of wave modulation, (Continues Wave) radars require significantly less power than pulsed versions and, thus, radars are more attractive for small UAV detection. Many of the available research papers (e.g., [2]) use (Frequency Modulated Continues Wave) radars for drone detection due to their lower power consumption compared to other wave modulation approaches.

D. Active or Passive
There are two different types of radar: active and passive. Active radars are equipped with both a transmitter and a receiver. The transmitter emits electromagnetic waves, which illuminates proximal targets. The receiver captures all reflected signals, which are then post-processed to expose any potential new targets. When only passive sensing is employed, the radar system is reduced to only receivers. Target illumination in the passive radar scenario is done by other signal sources, and the passive radar analyses the backscatter signals, including cellular signals, FM radio signals, WiFi signals, among others [8].
Although active sensing achieves a higher range of detection and better reliability, it requires significantly more transmit power and might not be capable of illuminating targets under diverse environmental conditions. Moreover, the radar operator needs to obtain a license and maintain permits for the band that the radar transmitter signal occupies. Passive radars do not require any operational permits because they do not actively transmit signals. Furthermore, their power consumption and cost requirements are significantly lower, accommodating multiple receivers for the same budget for a single active radar deployment. For instance, Chadwick et al. [8] proposed a system for drone detection using passive radar technology leveraging available 3 cellular communication signals as illumination sources. They considered three different ways for the illumination: using a cell phone on a call in the target area, having micro base stations for 3 communication in the target area, using the base stations in the closest vicinity of the target area. They use two receivers, one for capturing the genuine signal before all the reflections, and the other receiver is responsible for getting reflected signals. While this passive radar solution is costeffective, it comes at the expense of accuracy and lack of reliable coverage.

E. Beam Steering
The more focused and narrow the transmitted signal, the better the illumination for detecting small objects. For instance, using omni-directional antennas with a wide main lobe will result in poor performance for detecting small objects. On the other hand, using a narrow radar beam with a focused main lobe, while accurate for small objects, it decreases the surveillance perimeter. One option is to use several antennas on the transmitter side, each with a narrow beam but placed in such a formation that, combined, they cover the target area. Another option is to make the transmitter mobile by using a rotor. This method is called mechanical beam steering, and it can cover the target area over a period of time. In addition to the mechanical beam steering, there is yet another approach called electrical beam steering in which a narrow transmitted beam scans small areas by changing the phase of the signal over time, resulting in full target area coverage.

F. Mechanical or Multi-channel Scanning
Like the transmitter beam steering for scanning the target area, the receiver can also be installed on a motor that can mechanically turn and scan the whole area. An alternative design is to be equipped with static multi-channel antennas that can receive signals from any direction. Most active radar scenarios where the transmitter and receiver are bundled together are usually either static multichannel or use a mechanical rotation for both reception and transmission of signals. As an example, in [2], Noetel et al. investigate two methods of scanning. In the first scenario, they used a scanning surveillance radar system which is a mechanically scanning system operating in 94 GHz (they used mmWave radar). This radar can scan with the frequency of 8 Hz resulting in an image update rate of 8 frames per second. In the second scenario, they used a multi-channel radar for perimeter surveillance which is static. However, the radar is equipped with four channels on the receiver side to cover the whole area. It is also able to determine the 3 location of the target. The multi-channel approach can be used in situations where mechanical scanning is prohibited. In both of the scenarios, since they used radar, the power consumption is low. In addition, they were able to achieve good visibility of small objects and range resolution of 15 cm because of the 1 GHz bandwidth supported by the mmWave radar.

G. Micro-Doppler Analysis
Micro-Doppler analysis is used in radar analysis to fingerprint and identify target objects. This is different than the Doppler effect used to determine the speed and direction of the target object. Any vibration or movement in the target object's body or any other moving parts on-board the target can be measured using micro-Doppler analysis [9]. Drone propellers are a good example of micro-Doppler analysis performed on the reflected radar signals from drones. In this case, micro-Doppler analysis can assist in distinguishing between drones and birds, reducing false alarms. In addition, using micro-Doppler analysis, we can estimate parameters related to the target drone, such as the length of the rotors' blades [10]. For example, in Fig. 2, Gannon et al. [10] illustrated that when the size of a propeller's blades increases from 17 cm to 34 cm while maintaining the same rotation frequency of 30 Hz, the Doppler response is doubled.

H. Future Radar Drone Detection
One promising research direction is to leverage 5 cellular communications for drone detection. Terrestrial and satellite 5 communications can be used as both passive or active radar sources to illuminate and detect drones. Numerous research studies aim to investigate the challenges and limitations of harnessing existing and future 5 infrastructure capabilities for drone detection. As an example, Solomitckii et al. [6] explored the idea of using 5 base station antennas for drone detection. Since 5 can employ mmWave antennas in the base station for communications, it is conceivable that the 5 infrastructure can also be used as radar for detection purposes. In addition, Wang et al. [7] presented successful experimental results for drone detection from antennas operating in 28 GHz, which are similar to the frequencies 5 base station antennas use.
We discussed the challenges and potential design parameters when selecting an appropriate radar for detecting small UAVs. We want to reiterate that the size and materials of the target UAVs, operating environment limitations, type of radar systems, and their associated cost of operation and deployment are the primary solution drivers when it comes to drone detection. Recent advances in radar technologies, including high range coverage, working in all weather environments, and continuous coverage capability during day and night, have elevated radar technologies as one of the best candidates for drone detection systems. In the following sections, we demonstrate how radar sensors can be used alone or in combination with other sensors to increase the reliability of flying object detection.

III. ACOUSTIC SENSORS
When it comes to drone detection, acoustic antennas can sense the unique noise produced by the drone's propellers and detect the presence of a drone in the area of interest. Some examples of the available research and literature that focus on drone detection using acoustic sensors can be found in [3] and [11].
While economical, acoustic sensors have some significant drawbacks that need to be considered when it comes to drone detection. The primary limitation of acoustic sensors is that their performance is highly dependent on the range (distance) of the target to the sensor. Unfortunately, acoustic sensors are only suitable for short ranges, and they cannot be used to monitor large areas. To make matters worse, in crowded and noisy urban environments polluted with ambient sounds and noise, the performance of acoustic sensors degrades drastically. This limits their deployment options as acoustic sensors perform poorly in detection scenarios where patrol drones or other noisy equipment are employed to conduct the surveillance. In such cases, the ambient noise is too high, rendering any acoustic detection of external signals extremely hard to accomplish. On the plus side, acoustic sensors are inexpensive and can be easily acquired, installed, and deployed. In addition, they can perform well in any weather situation, both in the daytime or at night, and they do not need Line Of Sight (LOS) to the target object. All being said, when used on their own, they do not offer performance guarantees (due to their mentioned drawbacks); however, as a companion sensor, they can boost the overall system performance and accuracy.
IV. RF GROUND COMMUNICATION SENSORS One of the most widely used approaches to detect the presence of a drone in no-fly zones is by sensing the RF communication between the drone and ground controllers. This method leverages RF sensors working as receivers scanning for RF communication channel transmissions. The RF sensors are designed to detect the RF frequency ranges that drones use for control and data signaling with ground controllers. The first step is to distinguish existing versus new RF communications. Then, using the newly extracted RF communications, they have to further identify unique RF signatures for drones using techniques such as the ones presented in [1], [4], [12], [13].
As an example, Nemer et al. [13] propose a detection system based on the RF signature of drones which leverages ensemble learning to improve accuracy. Initially, a pre-processing stage removes the interference caused by other devices operating at the same frequency band as drones. Then, a machine learning program detects the presence of drone and identifies its type by deploying four classifiers hierarchically.
For RF sensing of drones, the common assumption across all approaches is that there exists an RF communication link between the target drone and its ground controller. It is further assumed that this control signal can be captured and precisely analyzed even in the presence of other signals. Indeed, for many commercial drones, RF signals are the primary means for communicating navigation commands to the drone from the ground controllers and, reversely, when downloading captured data such as images, videos, and other sensory information captured by the drones. While these assumptions are valid for many commercial offthe-shelf drones, there are drones capable of flying autonomously without the need to receive periodic navigation commands. Moreover, in some scenarios, drones are equipped with an adequate amount of on-board memory to capture sensory information for prolonged periods of time. Thus, even when a drone supports RF communications, there could be extended periods of time in which there is no RF communication between drones and ground controllers. Another challenge with RF sensing for drone detection is the presence of environmental RF noise. This is especially true in urban areas where wireless activity is prevalent, generating overlapping and constant RF transmissions emanating from both ground and aerial targets that are not necessarily drones. For instance, people use their WiFi devices to stream videos from the Internet while they are walking on the high floors of a tall building resembling the movement and transmission originating from a drone. Thus, merely depending on RF sensing is not reliable for urban environments due to environmental and noise considerations, including the presence of multiple concurrent communications from both stationary and moving targets. On the other hand, in less populated or rural areas where there are few wireless devices, the RF channels are primarily silent. Therefore, it is easy to sense the communications between drones and their ground controller.
While using RF ground communication signals for drone detection has limitations, it offers a costefficient and easy-to-implement mechanism that can be useful when allowed to operate over a more extended period of time and in combination with other sensing modalities. Moreover, this type of RF sensing can work in any weather conditions, it is not affected by the time of day, and it does not need direct LOS to the target. Additionally, this method can detect the drone even before it takes off and when it appears to be stationary (i.e., the drone has landed or it is just hovering). As long as there exists an active RF communication link between the target drone and any ground controller, the RF sensors can detect it. More importantly, this is the only method that can locate the ground controller of the drone as well as the drone itself.

V. OPTICAL SENSORS
Using optical sensors, including cameras, gated lasers, and other visual sensing modalities that perform optical processing offers another means to detect and classify UAVs. Similar to using radars, there are two approaches for deploying optical sensors: active or passive. When using active sensing, the detection system leverages an optical signal that can be emitted by a gated laser (e.g., LiDAR) to illuminate an area or a target of interest. The detection occurs by processing the reflected optical signals from the target. The passive method leverages an optical receptor, such as a camera to capture images or video for visual processing and classification of drones. The main advantage of using cameras for drone detection is that visual processing of the image from a target can reveal additional useful information for its classification. Image and video processing techniques can be applied to distinguish between drones and other flying objects or birds, between intruder and friendly drones, and determine whether a drone is carrying explosives or weapons. Thus, visual sensing can go beyond mere object detection to object classification with high accuracy when available.
The major drawback of optical sensors is their dependence on an uninhibited LOS to the target. Moreover, their accuracy degrades significantly in visually impaired environments. For instance, even when using night vision cameras, the quality of captured information in reduced or deprived light settings is far from optimal. In fact, cameras may fail to produce reliable detection results for small targets under different weather conditions (e.g., foggy, cloudy, rainy, etc). Another issue is that cameras offer a narrow beam for detection which means that single cameras cannot cover the large areas of interest at once. Therefore, we have to use multiple cameras or rotate one camera to swipe the area of interest. While active visual sensing (i.e., lasers) are not as sensitive as regular cameras to weather conditions, they can only provide detection at a very short range from the target. Hammer et al. [5], conducted experimental tests to evaluate the feasibility and practical performance of employing LiDAR for drone detection systems. While the results appear to be encouraging, the system had to operate in a very short range requiring a direct LOS to the target. When the target was within the sensor LOS and at a short range to the LiDAR system, a full 3 scan of the target was produced.

VI. MULTI-SENSOR APPROACH
All of the sensor modalities discussed thus far have both advantages and limitations that can render them ideal or unreliable under certain environmental and weather conditions. We posit that a robust drone detection system should rely on more than one sensing modality. Carefully selected, multiple sensing modalities can complement each other, increasing the reliability and identification robustness of the overall system. Therefore, any drone detection system's perimeter surveillance and reliability can be enhanced by fusing the inputs from multiple sensors while optimizing their utility based on environmental conditions. For instance, Laurenzis et al. [14] collected data from a heterogeneous sensor network consisting of acoustic antennas, small FMCW radar systems, and optical sensors. The authors applied acoustic sensors, radar, and LiDAR to monitor a wide azimuthal area (360 degree) to simultaneously track multiple drones with various degrees of success. In addition, they deployed optical sensors for sequential identification with a very narrow field of view. In another example [15], Giovanneschi et al. propose a drone detection system that consists of two stations: one was a static multi-sensory network, and the other one was a sensor unit installed on-board a moving vehicle. They initially studied a fixed multi-sensory network that included an acoustic antenna array, a stationary FMCW radar, and a passive/active optical sensor unit. The active optical sensor was LiDAR. A mobile vehicle equipped with passive/active optical sensing was brought in to augment the sensory network and cover areas behind obstacles. In contrast, the static multi-sensory network monitored a stationary area with a sensor-dependent sensing coverage. The data fusion from the multi-sensory network and the moving vehicle provided an increased situational awareness for target detection.

VII. CONCLUSION & FUTURE WORK DISCUSSION
We presented a survey on the available methods for drone detection. First, we covered the radar sensors with a deeper focus, as they are of the most promising approaches for detecting drones, but they come at a relatively high cost. In addition, we explored the capabilities and limitations of acoustic sensors due to their low energy requirements and deployment cost, showing that their use cases are limited to low noise environments. Moreover, we presented RF sensing as means for drone detection. This approach depends on detecting the drone's communications with a ground controller. Of course, drones might fly autonomously and remain silent for a prolonged period of time, thus preventing RF sensing from detecting their presence. Then we studied optical sensors which can be used actively, such as LiDAR, or in passive mode, like video and still imaging. Visual sensors offer advantages when it comes to target identification. However, they can be impaired by distance, lack of LOS to the target, and environmental conditions. Finally, we presented recent studies that attempt to fuse different sensing modalities to develop a more reliable approach for drone detection.
As we presented in this survey, using multiple types of sensors can mitigate some of the individual sensor limitations and boost detection robustness under adverse operational scenarios. Therefore, for future study, some may need to investigate how to alleviate the limitations of individual sensors by improving their performance using additional techniques (such as different learning algorithms for RF signature training) or by fusing them in a multisensor approach. Small RCS can affect performance (in cmWave radars, for a regular size commercial drones, RCS typically ranges from −1 dBsm to −18 dBsm). Active radars require transmission license and frequency check to prevent interference.

Acoustic microphone array
Operates independent of visual conditions (day, night, fog, etc). Performs even if drone flies autonomously (without RF emissions). Operates in LOS/NLOS. Low cost implementation. Low energy consumption. Highly mobile and quickly deployable.
Short detection range (detection range < 500 m). Performance degrades in loud and noisy environments. May work poorly in crowded urban environments due to acoustic noise.

RF signals
Operates in Day/Night, Acoustic Noisy, Visual Impaired, and LOS/NLOS environments. No licence required. Low cost sensors (e.g., SDRs). Can locate the controller of the drone on the ground.
Detection fails in cases where there is no RF signal transmission from the drone. May work poorly in crowded urban areas due to RF interference.

Vision-based
Offers ancillary information to classify the exact type of drone. Can record images as forensic evidence for use in eventual prosecution.


extfieldsofstudy:
Computer Science
Mathematics

text:
Autoencoder-based Semantic Communication Systems with Relay Channels

In this letter, we propose a semantic communication scheme for wireless relay channels based on Autoencoder, named AESC, which encodes and decodes sentences from the semantic dimension. The Autoencoder module provides anti-noise performance for the system. Meanwhile, a novel semantic forward (SF) mode is designed for the relay node to forward the semantic information at the semantic level, especially for the scenarios that there is no common knowledge shared between the source and destination nodes. Numerical results show that the AESC achieves better stability performance than the traditional communication schemes, and the proposed SF mode provides a significant performance gain compared to the traditional forward protocols.

I. INTRODUCTION
S EMANTIC communication was considered on the second level of communication problem [1], aiming to convey the semantic information of the transmission symbols accurately, instead of accurately recovering the transmitted information. With the development of artificial intelligence (AI) technology, semantic communication has attracted one's attention again and is considered as one of the future key mobile technologies.
Recently, several semantic communication concepts have been proposed, i.e., semantic-oriented and goal-oriented communication [2], semantic-aware networking based on federated edge intelligence [3]. Besides reconstructing a new paradigm of semantic communication from a mathematical perspective [4], many innovative communication schemes have been developed based on neural networks (NNs) and semantic interpretation modules to replace conventional communication blocks. The work [5] developed a point-to-point communications system whose entire physical layer processing was performed by NNs, but it is difficult to overcome the difference between the actual channel and the channel model used for training. In [6], a conditional generative adversarial net (GAN) was designed to represent channel effects. Moreover, based on a semantic autoencoder (SAE) [7], the network can learn a projection function from feature space to a semantic embedding space in zero-shot learning (ZSL) models. Based on Transformer [8] which is the dominating language model in natural language processing (NLP), X authors developed a deep learning based semantic communication system, named DeepSC [9]. It has better performance in the low signal-to-noise ratio (SNR) regime compared with the traditional communication system. However, the commonly used cross-entropy (CE) loss was flawed. In [10], reinforcement learning (RL) was used to narrow the semantic distance and an RL-based similarity-targeted semantic communication mechanism was established. Furthermore, it is worth noting that most of the existing semantic communication only considered end-to-end (E2E) communications system, and did not consider cooperative communications, e.g., wireless relay channel. Cooperative communication systems have been widely used in the wireless communication system [11], so it is important to study semantic communication for the cooperative communication system.
In this paper, we try to design a novel Autoencoderbased semantic communication system (AESC) to improve the reliability of semantic communication between multiple nodes. Firstly, we introduce a reliable autoencoder in the semantic communications system, including encoder and decoder powered by NNs, to compress semantic information and resist channel noise interference. Secondly, although the semantic communication is based on the common semantic background knowledge (BK) of the transmitter and receiver, in practice, it is difficult for the source node and the destination node to have exactly the same BK. As is well known, the traditional relay node can help establish the communication between a source and a destination. Thus, we propose a new semantic forward (SF) protocol in the relay node to solve the problem. With the SF protocol, the relay node can obtain semantic information from the source node based on the BK between the relay node and the source node, and then forward the semantic information based on the BK between the relay node and the destination node, thereby helping the source node and the destination node to communicate accurately at the semantic level under different background knowledge. Fig. 1 shows an Autoencoder-based semantic communication with one-way relay channels, where the source node transmits the information to the destination node through a relay node based on the semantic communication. The semantic communication consists of two levels: semantic level and transmission level. The semantic level contains the semantic coding layer and the semantic decoding layer for extracting and analyzing the semantic information, respectively. The transmission level guarantees that semantic information can be transmitted accurately in the wireless channel.  A. Autoencoder-based Semantic Communications 1) Encode Layer: The input of the AESC in the source node is a sentence s = [w 1 , w 2 , · · · , w L ], s ∈ K, where w l represents the l-th word in the sentence and K is the background knowledge. As shown in Fig. 1, the input sentence s is embedded into a vector e, and each word w in the sentence is mapped to D dimension. Then, we apply semantic encoder which is the encoder of Transformer to encode e to a semantic vector x. The Transformer encoder consists of two parts, named self-attention sublayer and feedforward sublayer. Connecting the above two parts alternately six times forms a complete semantic encoder network.

II. SYSTEM MODEL
Then the source node passes the semantically encoded vector x into the Auto-encoder to get compressed vector y. The Auto-encoder has functions similar to traditional channel coding, has anti-noise and encryption capabilities, and can compress the semantic vector to a certain extent.
Accordingly, the receive signal at the relay node is where h 1 represents the Rayleigh fading channel between the source node and the relay node, and n 1 ∼ CN (0, σ 2 n ) is the additive white Gaussian noise (AWGN).
Next, the relay node can forward the information to the destination node based on the forward protocol, which will be discussed in the next subsection.
2) Decode Layer: As shown in Fig. 1, the signal received at the destination node is given by where h 2 represents the Rayleigh fading channel between the relay node and the destination node, and n 2 ∼ CN (0, σ 2 n ) is AWGN.
The destination node gets z and passes it through the Auto-decoder to recover the semantic vector x which keeps the semantic information of x. Finally, we input x into the semantic decoder to recover the transmitted sentences. The semantic decoder is divided into three sublayers, one more layer than the Transformer encoder. Between self-attention sublayer and feed-forward sublayer is an encoder-decoder attention sublayer that can help the decoder focus on the relevant parts of the input sentence. In addition, the semantic decoder has two inputs. One is the semantic vector recovered by the softmax layer and another is the transmitted sentence according to the framework of Transformer.

B. Relay Forward Protocol
The forward protocol of the relay node can be divided into two scenarios according to whether the relay node has the semantic BK.
1) Traditional relay mode: The relay node only processes the signal at the physical level and does not involve semantics. If the amplify-and-forward (AF) mode is used, the signal received at the relay node is directly amplified and forwarded to the destination node, and we thus have z = α y. Here, α is an amplification constant factor that is chosen to satisfy the total power constraint at the relay node. If the relay node uses the decode-and-forward (DF) mode, the relay node can decode and forward the received information at different layers based on its BK. If the relay node does not have the BK shared by the source node and the destination node, it can not further perform semantic decoding; otherwise, the relay node can perform semantic decoding.
2) Semantic relay mode: The traditional relay mode requires the source node and destination node to have the same BK. However, it is difficult for the source node and the destination node to have exactly the same BK. To overcome this problem, we design a novel relay forward mode here, named semantic forward. The key idea of SF is that the relay node can perform the semantic decoding to obtain the semantic information s from the received signal y based on the BK between the source node and itself, and then it can recode the sentences s in a way that the destination node can understand based on another BK between the source node and the relay node. For example, the source node said:" My son is very good at CS", but the BK of the destination defaults that CS is a game called Counter-Strike and the destination node knows the name of the source node's son is Bob. In this case, the advantage of the proposed SF can be reflected at this time. The relay node can know that CS said by the source node means computer science and the destination node knows Bob. Based on the SF protocol, the destination node receives the sentence:"Bob is very good at computer science". We can see from this example that SF not only reduces semantic distortion but also performs semantic compression.
III. MODEL TRAINING Different from Fig. 1, we can train each module in the E2E model. At this time, z = y, the input of the whole network is a sentence s. The encoded semantic vector can be represented by where S α (·) is the semantic encoder network with the parameter set α and F β (·) is the Auto-encoder network with the parameter set β. The decoded sentence can be represented as where D θ (·) is the Auto-decoder network with the parameter set θ and G η (·) is the semantic decoder network with the parameter set η.

A. Training Auto-encoder/decoder
Different from the joint training of source and channel coding, we train the Autoencoder module separately to deal with different channel conditions more flexibly. The training of Auto-encoder and Auto-decoder does not require a true semantic vector as input. The function of this part is to make the distortion of the transmitted vector as small as possible. Therefore, we use randomly generated vectors for training, and the range of random vectors is [−2, 2], similar to the encoded semantic vector. The Auto-encoder has two hidden layers, each layer compresses the semantic vector to a certain extent. In this paper, the first layer is compressed to M dimensions, and the second layer is compressed to 2N dimensions, mapping into the N symbols of the real part plus the imaginary part. Obviously, the Auto-decoder has a symmetrical structure. Because the input and output are two vectors, we use the mean square error (MSE) as the loss function to reduce the distortion. Based on the transmitted vector x and the distorted vector x, the loss function can be expressed as where x i and x i represent the components of vector x and x respectively, N is vector size. Finally, the ADAM algorithm is exploited to optimize the parameters β, θ. The training algorithm is outlined in Algorithm 1.

B. Training Semantic Encoder/Decoder
The semantic encoder and decoder training process are illustrated in Algorithm 2. Firstly, we load the pre-trained network shown in Algorithm 1, and fetch minibatch B from BK K to generate sentences S ∈ B×L , where B is the batch size and L is the length of sentences. Through the embedding layer, the sentences can be represented as a vector E ∈ B×L×D , where D is the embedding dimension of each word. After the transmission of the entire communication model, the reconstructed sentence S ∈ B×L will be obtained. The cross-entropy is used as the loss function Algorithm 1: Train Auto-encoder/decoder network.
to measure the difference between S and S, which can be formulated as where p (x ij ) is the real probability that the j-th word in i-th sample, and q (x ij ) is the predicted probability that the i-th word in i-th sample, and m represents the number of samples in one batch. The CE can measure the difference between two probability distributions. By reducing the loss value of CE and optimizing parameters α, η by the stochastic gradient descent (SGD), the whole network can be robust to distortion.

A. Performance Metrics
For the semantic communication, the symbol has no value unless it has exploitable semantic information. Thus, we use two evaluation indicators to judge communication quality in this letter. One is the bilingual evaluation understudy (BLEU) score [12] and the other one is semantic vector similarity.
1) BLEU Score: BLEU adopts the k-gram precisions rule, which calculates the similarity of k groups of words between the candidate sentence and the reference sentence.
For example, we use "It is a nice day today" as the candidate sentence, and the reference sentence is "Today is a nice day". If we use 1-gram precision, we can see that the candidate has a total of 6 words, and 5 words all hit the reference, then its 1-gram precision is 5/6. Its 3-gram precision is 2/4. Firstly, we compute the brevity penalty BP as following where c is the length of the candidate translation and r is the effective reference corpus length. Secondly, we compute the geometric average of the modified k -gram precisions p k by using positive weights w k . Then, we have The BLEU metric ranges from 0 to 1. It will attain a score of 1 if candidate sentences are identical to reference sentences.
In this paper, we use the 2-grams BLEU score.
2) Semantic Vector Similarity: In the task of NLP, the cosine similarity formula is often used to calculate the similarity of two-word vectors. Cosine similarity uses the cosine value of the angle between two vectors in the vector space as a measure of the difference between two individuals. The closer the cosine value is to 1, the closer the angle is to 0 degrees, the more similar the two vectors are.
Given two vectors, A and B, the cosine similarity can be given by Here A i and B i represent the components of vector A and B respectively.

B. Simulation Results
We compare the proposed AESC with the traditional source and channel coding approaches over Rayleigh fading channels. We also evaluate the performance of the proposed SF mode when the source node and the destination node have different BK, which is set to different chat histories in the simulation. Fig. 2 shows the BLEU score vs. SNR for the different schemes with the same number of transmitted symbols. For comparison, we consider a benchmark scheme, i.e., Huffman for source coding, uses Reed-Solomon (RS) (7,5) for channel coding and binary phase shift keying (BPSK) for the modulation. We also compare with the scheme without Autoencoder. Firstly, it can be seen from the figure that the proposed AESC has a higher BLEU score than that of the scheme without Autoenoder because the Autoencoder can resist the interference of channel noise. The traditional approach performs a little better than the proposed AESC method when the SNR is above 6 dB but when SNR is less than 0 dB, the performance of the traditional approach is far less than the proposed AESC method. Secondly, when the source node and the destination node have the same BK, the proposed AESC method with the DF mode performs better than that of the proposed AESC method with the AF mode at low SNR. When the SNR is above 0 dB, the proposed AESC method with the AF mode performs better than the proposed AESC method with the DF mode. Thirdly, when the source node and the destination node have different BKs, the proposed SF mode has a higher BLEU score than the AF and DF modes for any SNR. The performance of the SF mode is similar to that of the DF mode when the source node and the destination node have the same BK. Fig. 3 demonstrates the performances of the proposed AESC with the AF mode and DF mode in the semantic communication with relay channels when the source node and the destination node have the same BK. We fix the SNR from source to relay and change the SNR from relay to destination. The DF mode can maintain relatively good performance in a poor SNR region. When both SNRs are −10 dB, the BLEU score of the DF mode is also close to 0.8, which means that most of the semantics can be transmitted. It can also be seen that the semantic vector at the destination node with the AF mode is closer to the real transmission semantic vector in high SNR. The reason is that the distortion caused by Auto-encoder and Auto-decoder is greater than the impact of the channel in high SNR. However, when the SNR is low, the distortion of semantic vectors caused by DF mode is significantly lower than that of the AF mode.
In Fig. 4, we evaluate the performance of different relay forward protocol via. the placement of the relay node. In the simulation, we normalize the distance between the source node and the destination node to 1, and we use d ∈ (0, 1) to denote the distance between the source node and the relay node, while (1 − d) denotes the distance between the relay node and the destination node. The results reveal that in the symmetrical situation of the transmit powers P 1 = P 2 = 5 dB, the optimal placement of the relay node in each mode is d = 0.5. When P 1 = 5 dB and P 2 = 10 dB, the optimal relay location in each mode is d ≈ 0.4, which means that the relay should be deployed closer to source node. We can also observe from Fig. 4 that the SF mode and the DF mode can more stably cope with the change of relay node position than the AF mode.

V. CONCLUSION
This letter proposed a semantic communication approach based on Autoencoder for the wireless relay channel with a novel semantic forward protocol. The proposed Autoencoderbased approach uses Autoencoder to extract and compress semantic information and reconstructs its semantic features. For the proposed SF protocol, the relay node can cooperatively use the background knowledge of the source node and the destination node to forward semantic information at the semantic level, to solve the problem of direct semantic communication under different background knowledge between the source node and the destination node. Simulation results demonstrated the effectiveness and advancement of the proposed approach.