Remote-Timber: An Outlook for Teleoperated Forestry With First 5G Measurements

Across all industries, digitalization and automation are on the rise under the Industry 4.0 vision, and the forest industry is no exception. The forest industry depends on distributed flows of raw materials to the industry through various phases, wherein the typical workflow of timber loading and offloading is finding traction in using automation and 5G wireless networking technologies to enhance efficiency and reduce cost. This article presents one such ongoing effort in Sweden, Remote-Timber—demonstrating a 5G-connected teleoperation use-case within a workflow of timber terminal—and disseminates its business attractiveness as well as first measurement results on network performance. Also, it outlines the future needs of the 5G network design/optimization from teleoperation perspective. Overall, the motivation of this article is to disseminate our early-stage findings and reflections to the industrial and academic communities for furthering the research and development activities in enhancing 5G networks for verticals.


Introduction
The connectivity role is growing beyond convenience and entertainment functions; for instance, with reliable, low-latency, and high-bandwidth connectivity, the connected automotive market is set for radical transformation to develop safer and sustainable mobility [1].The futuristic use-cases of this mobility revolution are teleoperated, autonomous, and cooperative vehicles/robotics [2], [3], which fall in the tactile Internet regime.In remote, teleoperated driving (ToD), a vehicle is driven from a remote location using a mobile communication infrastructure.The driving operation is not automated; instead, the vehicle's state and surroundings are properly transferred and visualized back to the operator for vehicle control.Meanwhile, autonomous and cooperative driving requires vehicles/robots to navigate synchronously and automatically in the environment, with the frequent exchange of information among vehicles' control systems and the (edge or cloud) back-end systems.
In ToD, the inclusion of the operator's perceptual/cognitive skills in the control loop alleviates the need for sophisticated technologies (e.g., advanced algorithms and complex subsystems) to perform real-time tasks of object identification, navigation, and cooperation as demanded for autonomous driving (AD).In this respect, ToD can be seen as an additive service to AD, with the remote operator taking control of challenging/critical maneuvers in distant, inaccessible, and harsh environments.
Teleoperation is gaining traction for realizing low-cost remote handling of workflows, operations, and processes across various industries, including (but not limited to) harbor or port automation [4], [5], construction [6], transport and logistics [2], mining [7], and forestry.Figure 1 shows the drivers for teleoperation across industries, with an emphasis on teleoperated forestry workflow, which is discussed in the "Timber Terminal: Workflow and Motivation for Automation" section.
In all of these industrial use-cases, dependable mobile connectivity is a prerequisite for teleoperation and remote driving-based automation, which fall in the mission-critical application domain.The haptic control and video communication between the vehicle and the operator must satisfy the application-specific quality-of-service parameters.The operators' cognitive functions (spatial cognition and awareness) and the control loop (actuation to the reception of the vehicle's sensory feedback) depend on reliable, low-latency communications.The endto-end latency is shown to be inversely related to the perceived quality of the teleoperation [8].Meanwhile, the vehicle's video-based environment perception and state knowledge are vital aids to the operator's cognitive functions, which are throughput and bandwidthdemanding.However, the latency increases proportionally as the throughput requirement increases [9].
The 5G networks are conceived and developed to meet such (video-controlled) interactive and real-time requirements of mission-critical applications and services.In this respect, 5G introduces a multiservice 5G architecture [10], [11] to provide differentiated services for verticals with features, such as multiaccess edge computing (MEC) to offload computing near the edge for real-time analytics and service optimization, end-to-end network slicing (NS) for heterogeneous (video and control) traffic demands, and new radio access network (RAN).Figure 1 illustrates a generic 5G network architecture from a ToD perspective.With these features, compared to LTE, cellular connectivity is becoming adaptable and robust in meeting the diverse latency, packet loss, bandwidth, and service availability demands in harsh conditions.Several pilot projects, private 5G deployments, and measurement campaigns have increased our 5G understanding and transition toward real-world deployments [12], [13].
To demonstrate the ToD over 5G, the 5GCroCo European Union-funded project [14] tested and confirmed the effectiveness of advanced 5G features to enable innovative use-cases for connected and automated mobility services.The relevant 5GCroCo use-cases are ToD and cooperative collision avoidance, with the partially aligned objectives to the Remote-Timber usecase presented in this article in terms of human-in-the-loop for remote teleoperation with functional safety.However, the Remote-Timber use-case, demonstrating the teleoperation of a wheel-loading machine for timber terminal automation, requires not only ToD features with higher situational awareness but also remote control of the timber handling operations.On the other hand, the teleoperated support (TeSo) use-case of 5G-Heart [15] supported a remote vehicle operator with real-time video streaming and instrumentation data to monitor and control the vehicle.In TeSo, the vehicle equipped with video cameras and sensors was remotely driven in urban, suburban, and highway conditions; however, these test conditions are completely different than the Remote-Timber use-case.Similarly, the 5G Blueprint project is focused on teleoperated transportation and logistics [16].In Remote-Timber, teleoperation and timber handling (loading and unloading) operations are incorporated for real timber terminal automation.
To this end, this article presents the first measurement results, experiences, and outlook of teleoperated timber handling operations over a 5G network.It begins by describing the motivation for automation within the workflow of a timber terminal and outlining the requirements and practical considerations from different perspectives, e.g., functional safety, responsive control, and high-capacity uplink multiview video for timber loading and unloading operations, radio propagation conditions of a dynamically changing timber terminal, and limitations of a public LTE network by drive tests.The results exemplify the need for 5G for real-time relaying of the remote operator's control inputs to the wheel loader in response to perceived changing timber site conditions and operations based on real-time uplink video feedback.After that, it introduces the end-to-end 5G wireless enablers for ToD.Later, it presents the demo setup, including the description of the test site and mobile network configuration, and the 5G network test scenario and measurement results.The article concludes with key insights and future research and development directions for 5G network design and optimization for ToD.

Teleoperated Forestry: Motivation and Requirements
The forest industry relies on distributed logistics flows of large amounts of raw materials.In Sweden alone, the forest-to-industry supply chain contributes 80 million tons of raw materials annually.Therefore, efficient logistics flows are central to reducing energy consumption, environmental impact, and costs, thereby strengthening competitiveness.The forest that is felled, in some cases, is temporarily stored at timber terminals before it is transported to the industries by trucks or trains.In Sweden, there are about 100 timber terminals, and globally they amount to several thousand.The timber terminals are usually located in remote locations, making it challenging to staff them efficiently.

Timber Terminal: Workflow and Motivation for Automation
In a timber terminal, the loading is carried out by wheel loaders that are adapted for efficient unloading and loading of the timber.A typical operational workflow in a timber terminal is (Figure 1): ■ Ar rival: The truck with timber comes into the terminal and is registered, and the load is weighed and measured.The driver also removes safety locks that secure the timber before unloading.■ Transfer: The truck moves into the position where the wheel loader unloads it.■ Off-loading: The wheel loader unloads the truck and transports the timber to a designated storage place in the terminal.■ Departure: When the wheel loader finishes unloading, usually in four rounds, the truck driver prepares the truck for transportation and leaves the terminal.■ Shipment: The wheel loader prepares and loads the timber to the trucks or trains for shipment to the industry.
The flow of trucks coming into the terminal comes in bursts, randomly distributed over a day, and can also be unevenly distributed over longer time spans.The same work pattern applies to the loading trucks/trains with timber from the terminal.The uneven workload and remote location of the terminal make it a good candidate for remote control with a centralized operator that can operate several terminals to reduce cost without degrading performance.Our analysis of the traffic data in several timber terminals for a full year shows that a centralized operator has the potential to serve four timber terminals; thus, providing a 75% reduction of staff.Additionally, a remotely operated timber terminal could also extend the operational hours, and the improved accessibility would enable new and more climate-friendly planning of the whole logistic chain.

Requirements for Teleoperated Terminal
The remote execution of the earlier described workflow comes with many requirements, ranging from functional safety and visual feedback, to connectivity capacity/coverage in challenging radio conditions.

Functional Safety Control
In ToD, functional safety requirements are critical since the erroneous or delayed perception (to detect, locate, and recognize potential objects) of a vehicle's surrounding and control feedback might disrupt the terminal's operation, material losses, and fatal accidents, mainly when operating heavy timber loaders.Therefore, a functional safe and reliable communication of a loading machine is vital for teleoperated forestry.In this respect, safety requirements for remote-controlled earth-moving machinery are regulated in the ISO 15817 standard [17].Meanwhile, the Swedish machinery directive [18] requires that the remotecontrolled machines shall automatically and immediately stop to prevent dangerous operations in the event of: ■ if the operator loses contact ■ upon receipt of a stop signal ■ when a fault is detected in a safetyrelated part of the system ■ when a control signal is not detected within the specified time.
When networks are not developed in line with the requirements of functional safety, implementing the functions mentioned above is challenging.One possibility is to take inspiration from Profisafe [19], a leading functional safety protocol from process automation.To prevent errors or failures in the safety functions of remote-controlled machines, Profisafe requires implementing a safety function response timer as the time between error detection and the transition to a safe state.Profisafe is a higher-layer protocol (i.e., between the application layer and communication layer) that can be used both with the Profibus and Profinet (i.e., layer-2 protocols), and its approach for safety communication is based on the black channel principle.Under this principle, Profisafe comprises measures to deterministically discover all possible faults and hazards caused by the channel without relying on a standard transmission system, which includes switches, routers, gateways, and transmission protocols [19], [20].

Multiview Uplink Video
For safe ToD, providing multiview video and multisensor information from the vehicles is necessary for teleoperators.However, in a teleoperated forest terminal, the number of views and auxiliary information from sensors have special requirements.Despite the placement of cameras based on the visibility analysis to achieve total supervision around the machine, our initial trials required several modifications in the video views for remote timber handling operations (i.e., loading/ offloading from trucks/trains).For instance, the drivers: ■ take 90° when loading/offloading from the truck to protect the truck, especially when taking the last grip, requiring changing the views on the screen accordingly ■ require a view from inside the cabin to recognize the learned references often used in driving ■ point out the lack of reference view for depth and precision ■ capture the machine angle and distance to the objects around the machine.
The visibility analysis, integrated with these insights from seasoned drivers, resulted in the need for a total of 11 cameras on the wheel loader to ensure comprehensive coverage.Apart from the optimal views, to establish the correlation between image and movement, the delay and information quality affect work efficiency, operator well-being, and safety.In this respect, for 11 cameras with each camera capturing at 30 frames per second (FPS) at 720p (1,280 × 720 pixels) resolution, the optimal conditions for the teleoperators required multiview video information of up to 50 Mb/s in the uplink direction at a time lag of less than 200 ms.Note that these figures were determined from the functional safety perspective as well as the drivers' quality of experience (QoE) during training and actual trials; whenever not met, the work efficiency and well-being (noticeable in the form of dizziness and fatigue) of the operators were greatly affected.

Radio Propagation Conditions
The timber site spreads over a large area with laid timber, often forming narrow "streets" of greater than 2-to -10-m high walls of wood (Figure 2, timber terminal and radio conditions).Depending on how these streets are oriented with reference to the radio network, it affects the user terminal's connectivity performance due to attenuation and fading caused by signal absorption and nonline-of-sight (NLoS) conditions.Moreover, the orientation and height of these walls are not "static" and change dynamically according to the inflow and outflow of the timber.The second issue is the limited radio coverage from public mobile networks at remote terminals, where the distance from the nearest base stations could be in the order of kilometers.Altogether, our preliminary drive tests (Figure 3) showed sharp signal quality variations, affecting throughput and latency performance significantly.Figure 3 shows that the uplink throughput mostly remains below 5 Mb/s.Meanwhile, the round trip time (RTT), measured using the standardized internet control message protocol procedure (layer 3 ping), is also excessively large, i.e., mostly in the 40-to 60-ms range.The RTT is considered to be large because the ping measurements only give a snapshot of the actual link latency and may not trigger end-to-end resource scheduling in the network for real applications.Therefore, the drive tests necessitated reinforcing the mobile coverage in the test area, e.g., with dedicated 5G-supported base station deployment, to meet the aforementioned functional safety and data rate and latency requirements of a teleoperated wheel loader.Such deployment at remote timber terminals can be seen as a path toward public-network integrated private 5G networking [12], [21].
In summary, as shown by our drive tests, supporting such deterministic/responsive connectivity requirements for functional safety and visual feedback between the machine and the operators is plausible only with the new 5G architecture,

5G Enablers for Teleoperation
To meet the diverse and demanding performance requirements of emerging 5G services, the Third Generation Partnership Project (3GPP) standards organization has introduced new 5G new radio (NR) access and servicebased architecture (SBA) for 5G Core.
The 5G NR provides various capacity, coverage, and low-latency features, such as flexible (noncontinuous) carrier aggregation (CA), multiantenna transmission, and finer scheduling [22].The noncontinuous CA feature in 5G allows extending the geographic availability of high data rates by combining different (e.g., low and mid) frequency bands [23].Meanwhile, the SBA enables service agility by decoupling the network functions (control and user planes) from the network infrastructure, providing service deployment flexibility [11], [24].One prominent advantage of such functional decoupling is NS [25] for the 5G verticals, which supports multiple virtual networks operating on the same physical hardware.NS provides a tailored end-to-end network [including RAN, transport, and core networks (CNs)] to meet the 5G vertical requirements.However, end-to-end NS has two key associated challenges: slice isolation [26] and resource management due to the shared physical RAN, transport, and core infrastructure between various 5G applications.For example, the expensive shared spectrum dedicated to a specific slice may be static and overprovisioned to meet the latency and throughput requirements of the remote teleportation use-case, which could reduce the financial benefit derived by operators from adopting slicing technology, requiring dynamic resource management mechanisms [27].Furthermore, joint slicing and edge computing [28] play a vital role in improving the end-to-end latency performance of the 5G teleoperation usecases, where different computation and storage functions are supported near the network edge (e.g., collocated MEC at RAN [29]).However, without reducing the RAN queueing delay, the latency may spike significantly under high/bursty traffic and poor link quality conditions, and the network/device buffers may overflow, causing high packet losses and end-to-end delay.Therefore, the development of different congestion control and link adaptation approaches are widely explored [30], [31], [32], [33], [34] for realizing a balanced between the low-latency and high-throughput requirements in industrial use-cases.
baseline rate adaptation, the network endpoints achieve rate adaptation over the top (OTT) without the explicit support of a network, in which the receiver measures the bitrates and latency and provides feedback to the sender.By employing end-to-end OTT congestion control methods, a tolerable latency requirement can be met regardless of the fluctuating network conditions.However, these approaches are not appropriate for time-critical flows on public 5G networks due to the possibility of increasing RAN queueing delays.Additionally, the endpointbased delay-sensitive congestion control implementation partially solves the delay issue, but the endpoint does not have an indicator of what other factors are contributing to the delay, like scheduling jitter, discontinuous reception, handover, and radio link control (RLC)-layer retransmissions.Therefore, the RAN should also support congestion control methods for time-critical applications.

5G-Connected Remote-Timber: Demo and Measurements
The Remote-Timber demo was designed/ tested in close collaboration with academic and industrial partners, including the research institute, mobile network operator, wheel loader manufacturer, and timber logistics.Their overarching objective was to assess the operational feasibility of timber terminal automation while evaluating the performance of a cloud-based control design and supporting 5G connectivity infrastructure, and to identify the needed enhancements and future research directions.Figure 2 shows an aerial view of the timber terminal and 5G test site in Sundsvall, Sweden.

Test Site Setup
In the following, a brief description of the main elements of the test setup precedes the measurement results.A distinctive aspect of these 5G measurements is the end-to-end packetlevel analysis.

Test Site
The test area, where the loader machine is operated remotely, is an asphalt 150 × 200-m floor, adjacent to a 5-m-high pile of wood.A two-sector gNodeB (gNB), with 4G/5G antennas mounted on a lighting mast, is installed with one sector providing coverage to the machine and the other to the remote operator.This setup is shown in Figure 2 (5G test site), with the purple arrows showing the approximate sector antenna directions.This setup is used to analyze the remote driving scenario with the machine and driver connected over the same 5G network.

Loader Machine
The machine used in the setup, as a test bench to evaluate the remote control functionality, is a Volvo L180 forklift (Figure 2, wheel loader).The experiments focused on testing functionality rather than optimizing the conditions for productivity.

Remote Operator
The operator was located in a cabin to control the machine with a modified simulator, intended to train on a Volvo L180.In the setup, the remote driver cabin was located approximately 50 to 250 m from the driving area of the loading machine.However, as described later in the test scenarios, the end-to-end communication path between the driver and the machine was approximately 800 km.The operator had seven screens, with multiview video information from 11 cameras, Orlaco EMOS Ethernet camera 180° [35].In addition to video feedback, textual information (e.g., r/min, parking brake, gear, fuel, speed, machine angle, and distance to the nearest object) was distributed across five screens.However, no feedback in the form of sound and shaking was provided to the operator.

Mobile Network Configuration
The gNB, a part of a nonstandalone 5G public network, was reinforced [Time division duplex (TDD) refers to duplex communication where uplink is separated from downlink by the allocation of different timeslots in the same channel.NR TDD frame configurations are often described as DDDSU or DDDSUUDDDD, where D/U indicates slots for downlink/uplink-only symbols and "S" is the special slot.]The reinforced gNB in Sundsvall was connected to the CN located approximately 400 km away in Stockholm, via the transport network over a dedicated 10-Gbit/s fiber link.From the CN, the machine traffic was terminated on a fiber switch at the test site, near the driver cabin, using a virtual private network-based broadband service over an L2 network.

Mobile Terminal
Cradlepoint R1900 router [36] was used as a mobile terminal.In the downlink (gNB-to-machine), the router can aggregate all LTE bands and 5G band.For the uplink, the mobile terminal can combine an LTE band with a 5G band or two LTE bands.The tested scenario mostly used uplink video streams from the machine to the driver cabin, exclusively using a combined LTE and 5G link.

Remote Driver's Experience
Using this setup, the test activity for remote loading/offloading operations spanned over a week at Torsboda, Sweden.The main objectives were to monitor the drivers' experiences and obtain reference data during the load cycle: empty driving to grip, lift, driving, and release of the load.The wheel loader manufacturer was mainly interested in measuring the loading/ unloading performance without correlating the drivers' control/visual experiences to the 5G traffic statistics.Second, considering the sensitivity of exposing the control design with respect to network dynamics, unfortunately, application-level statistics are retracted.Still, the following problems were observed: ■ At least once a day, the loader's communication watchdog timer was triggered, requiring a manual reset of the loader's electronic control unit.In fact, the communication module implements a keep-alive mechanism using periodic heartbeats to ensure that communication between the vehicle and the remote operator control module is functioning properly.If the vehicle fails to receive a heartbeat within a specified time period (i.e., 200 ms), the connection is assumed lost, triggering the watchdog.■ Minor disturbances (i.e., pixelation) in two to three video streams were experienced throughout the day, mostly occurring when the loader was at the far-edge of the test area, having low signal strength values.In summary, the project successfully demonstrated control and multiview video signals for vehicle steering, acceleration, and braking, as well as loading operations over 5G in real time using LTE/5G capabilities.Meanwhile, to gather supporting quantitative statistics, we tested two independent measurement setups, as shown in Figure 4 and described hereafter.

Test Scenario 1: SCReAM
Test scenario 1 relies on Linux-based implementation of low-latency lowloss scalable throughput (L4S)-ready SCReAM (self-clocked rate adaptation for multimedia), an optimized congestion control algorithm for realtime multimedia traffic, especially in cellular networks [37].SCReAM adopts a self-clocking principle, i.e., it uses a feedback-based reactive congestion window to minimize the RTT without compromising link utilization/throughput.The self-clocking in SCReAM enables channel jitter-aware congestion control in wireless scenarios, introduced by, e.g., radio resource scheduling in dynamic radio conditions [38].Using reasonable congestion-control algorithms, it measures the achievable data rate for a given network configuration and environment.
For tests, a laptop running SCReAM transmitter (Tx) (emulating as a machine) transmits the fake video frames (i.e., RTP media) in the uplink to SCREAM receiver (Rx) (located in the driver cabin) at a maximum possible rate range of 0. comfortably satisfied in an LoS condiwith a 10% violation probability on the data rate target; however, in NLoS, although latency of the video rate possible to inject into the network violates the bound by 1%, the data rate always remains below the target.
As mentioned in the "Test Site Setup" section, the gNB is located approximately 400 km from the CN; thus, the end-to-end communication path between the teleoperator and the wheel loader is 800 km.Therefore, the minimum RTT delay between the SCReAM Tx and the Rx is around 8 ms.consequently, in both test scenarios (compare with, Figure 4), the lower bound on the RTT delay is 8 ms.Meanwhile, it can be observed from Figure 5(a) that the RTT delay in both the LoS and NLoS conditions is greater than ≈ 50 ms.It implies that the rest of the delay figure is caused by signaling and queueing processes in the various network segments in the round-trip path.In addition, the higher queueing delay at the SCReAM Tx in NLoS conditions is the result of congestion at the Tx-side caused by nonfavorable channel conditions.
Meanwhile, Figure 6 shows snapshots of selected test runs to compare and correlate the RTT and data rate.It is observed (compare dotted rectangles in Figure 6) that throughput changes are associated to RTT spikes because of limiting radio link conditions, implying the congested window adjustment kicks in as soon the throughput starts deteriorating and/ or RTT spikes, until both are recovered quickly to the highest possible link utilization.As expected, the NLoS tests provide an entirely contrasting situation; yet, the SCReAM congestion control algorithm's reaction to packet delays is visible.

Test Scenario 2: Voysys Streamer
In this test scenario, we used a Voysys commercial video testing tool [39], with

Summary and Outlook
In this article, we outlined the operational flow of a timber terminal and how 5G-based remote operation and automation can lead to various gains, especially lowering costs of the on-site workforce, while the pool of skilled labor is decreasing globally [40].However, we discussed how the teleoperation of a timber terminal differs from other ToD use-cases from the perspectives of functional safety, timber handling, on-terminal radio propagation conditions, and radio coverage in remote areas.Our drive test results showed that LTE alone is insufficient, and 5G enhancements were necessary to provide the needed responsive and uplink-heavy wireless connectivity.Later, we described our test setup and its configuration and provided reflections on the experimental results of connectivity performance.Our results showed that the use-case-specific key performance indicators (KPIs) are mostly satisfied only within a limited visible area around the radio tower and the wheel loader.Still, on various occasions, the functional safety protocol of the wheel loader triggered an emergency stop, implying that the network latency/throughput has to be further optimized.Moreover, as soon as the wheel loader moves beyond that area or is obstructed by wooden piles, the performance decreases drastically, and drivers experienced difficulty in correlating the control operations with the perceived motion.Therefore, our initial results are encouraging but limited, and the project's further outlook on various future needs and directions for cellular-connected teleoperated operations can be summarized as follows.

Network Deployments
In typical terminal layouts, a single gNB cannot provide suitable coverage for remote driving.Our measurements at the far end of the test area experienced poor channel conditions; consequently, RTT and bandwidth metrics were missing the desired targets.Meanwhile, an additional gNB or a relay node can extend coverage to the far end of the test area but cannot cover the entire terminal area of dynamically changing (in orientation and height) narrow streets of wood piles.Therefore, network planning and deployment must consider multitransmission-point or multiconnectivity setups [41] to enhance coverage and avoid NLoS situations to meet KPIs.Another possibility is introducflying gNB or relay with radio link condition-based placement.

Congestion Control
The L4S technology is currently being standardized by the Internet Engineering Task Force, with the purpose of improving the QoE for use cases that require both low latency and high throughput.The L4S system mitigates the queueing delay problem by introducing the explicit congestion notification (ECN) bits in the IP header and adjusting a marking strategy that changes the ECN bits to indicate network congestion.The ECN leverages the active queue management congestion detection method but with explicit signaling to indicate to the end hosts that packets normally dropped are instead marked as congested.Nevertheless, implementing and evaluating the functionality of the L4S features in 5G NR requires new approaches because the current marking strategy cannot be used to mark congestion of the encrypted packets queued up in the RLC layer [42].

End-to-End Slicing
To demonstrate the feasibility and guarantee the desired latency/bandwidth requirements, the Remote-Timber project allocated raw end-to-end bandwidth, without any adaptive resource allocation strategies.However, such resource overprovisioning leads to higher cost and underutilization of precious network resources.As a solution, operator-driven NS for optimal end-to-end network resource provision is needed to ensure the required bandwidth to achieve the desired RTT for ToD control and video data streams.Furthermore, future slicing solutions for ToD must be dynamic or elastic [27], [43], such that different slice instances with different resource allocations can be instantiated/modified/terminated on the fly based on ToD traffic flows.Meanwhile, learning-based policies are of interest to determine mapping functions between application-and network-level requirements [44].

Multivehicle Maneuvering
To achieve fully automated terminal operations, autonomous maneuvering or mobility management of multiple machines is necessary, mandating revisiting many of the aforementioned considerations.Such autonomy needs leveraging a shared connectivity infrastructure for integrated positioning, sensing, and low-latency deterministic communication [45] to allow machines to develop a shared perception of their surroundings from their local views and make safe maneuvering decisions.The recent network-and device-level positioning enhancements [46] in the 3GPP framework are expected to support such autonomy with centimeter-level position accuracy in indoor/outdoor scenarios.

MEC-Based Automation
However, reducing direct human/ operator intervention in automated teleoperation can increase the information exchange rate, latency, and volume between the vehicle's control and cloud-based control systems.As a solution, MEC can reduce latency and improve the functional safety of the remote-operation solutions by bringing core functionalities (i.e., computing and intelligence) to the edge [3] for various actions, including computation offloading (e.g., image processing for depth perception), predictionbased radio/computing resource management, and flying gNB or relay placement to support associated traffic and it's criticality.By implementing these functions at the edge, MEC could assist in reducing the risk of failures in the driver-vehicle control loop and ensure seamless remote driving and machine operation experience.

Biographies
Aamir Mahmood (aamir.mahmood@miun.se)earned his D.Sc.degree in communications engineering from Aalto University School of Electrical Engineering, Finland in 2014.He is an assistant professor of wireless communication for industrial applications at Mid Sweden University, 852 30 Sundsvall, Sweden.His research interests include wireless networks for dependable communication, focusing on intelligent solutions for radio frequency coexistence, radio resource management, and network optimization.He is a member of the IEEE Industrial Electronics Society and a Senior Member of IEEE.
Sarder Fakhrul Abedin (sarder.abedin@miun.se)earned his Ph.D. degree in computer engineering from Kyung Hee University, South Korea in 2020.He is an assistant professor at the Department of Computer and Electrical Engineering, Mid Sweden University, 852 30 Sundsvall Sweden.His research interests include Internet-of-Things network management of computing, machine learning, Industrial 5G, and wireless networking.He is a member of IEEE.
Mattias O'Nils (mattias.onils@miun.se)earned his Ph.D. degree in electronic systems design from the Royal Institute of Technology, Stockholm, Sweden in 1999.He is a professor with the Department of Computer and Electrical Engineering and leads the Research Group in Embedded Internet of Things Systems, Mid Sweden University, 852 30 Sundsvall, Sweden.His research interests include design methods and implementation of embedded deep neural network-based systems, especially in the implementation of real-time video processing and time-series processing systems.
Mats Bergman (mats.bergman@teliacompany.com) is a solution architect at Telia Company, 169 94 Solna, Sweden, specializing in driving service and application innovation in collaboration with major customers.With a working background in both Ericsson and Telia Company, he brings extensive international experience and a diverse skill set acquired through various roles such as system management, research and development, sales, delivery, and product management.His research interests include engaging with customers to benefit from new capabilities and features in Telia's 5Gbased systems.
Mikael Gidlund (mikael.gidlund@miun.se)earned his Ph.D. degree in electrical engineering from Mid Sweden University, Sundsvall, Sweden in 2005.He is a professor of computer engineering at Mid Sweden University, 852 30 Sundsvall Sweden.He holds more than 20 patents (granted and pending applications) in the area of wireless communication.research interests include wireless communication and networks, wireless sensor networks, access protocols, and security.He is an associate editor of IEEE Transactions on Industrial Informatics.He is a member of the IEEE Industrial Electronics Society and a Senior Member of IEEE.

20 FIGURE 3 -
FIGURE 3 -Drive test results: (a) uplink throughput and (b) round trip time (RTT) in the test area (compare with "5G-Connected Remote-Timber: Demo and Measurement" section for test site's details), where the nearest base station is located at around 3.5 km and the test equipment is locked to LTE 1,800-MHz band.

FIGURE 4 -
FIGURE 4 -Illustration of experimental setups.Test Sscenario 1: emulating machine (Tx) and driver (Rx) connected to same/different sectors.Test scenario 2: Tx and Rx are connected to the same sector, with a gateway at AWS.

FIGURE 5 - 2 FIGURE 6 -
FIGURE 5 -CDF of results in test scenario 1: (a) vertical dashed-line showing a delay target of 200 ms; (b) vertical dashed-line at target of 50 Mb/s.

FIGURE 7 -
FIGURE 7 -Independent trials for various observation parameters in test scenario 2 (target data rate of 30 Mb/s and 60 Mb/s at 30 FPS).(a) Data Rate (Mb/s), (b) Delay (ms), (c) Average Channel Usage, (d) Lost Packets.