Definition
UAS (Unmanned Aircraft System) is a complete UAV operational system that includes UAVs, ground control stations (GCS), communication links, payloads, mission planning, and UAV cloud platforms. UAS emphasizes system collaboration, covering capabilities such as communication, navigation, surveillance, command, and airspace management, and is the foundation for safe, compliant, and efficient UAV operations.
UAS communication links include remote control links (2.4GHz/5.8GHz), image transmission links, and 4G/5G cellular links. IoT SIM cards provide 4G/5G cellular backup or primary links for UAS, supporting BVLOS (Beyond Visual Line of Sight) flights, real-time image transmission, UAV cloud platform (UOM) integration, and flight data return.
Technical Features
UAS must comply with regulations regarding airworthiness, airspace, and operator qualifications. Integration with UAV cloud platforms can realize flight plan submission, real-time monitoring, and airspace coordination. Cellular links can compensate for the coverage limitations of traditional image transmission in BVLOS and complex terrain scenarios. IoT SIM cards need to support high data throughput, low latency, and wide coverage.
Use Cases
UAS are applied in power inspection, oil and gas pipeline monitoring, surveying and mapping, agricultural plant protection, logistics distribution, security, emergency response, and cloud seeding. Typical scenarios include UAV inspection, BVLOS flights, real-time image transmission, UAV cloud platforms, and UAV logistics. SimtoLink provides IoT SIM cards, dedicated APNs, data plans, and UAV solutions for UAS.
What the ground station, the control link, and the mission cloud each handle
An unmanned aircraft system is wider than the aircraft. The ground control station loads the mission, shows status, and takes manual control. The control link carries flight commands and critical status. The mission cloud receives the track, alarms, and job records that have already happened. An IoT SIM is usually on the cellular module of the aircraft or the ground station. It becomes the command path beyond visual line of sight, or a backup beside line-of-sight video. Which end holds the SIM decides who loses command first when the network drops. With the SIM on the aircraft, the ground station can send commands to the airborne end only over cellular. With the SIM only on the ground station, once the aircraft is past video range the cloud sees the ground station's own network, not the aircraft.
The system should separate at least three kinds of traffic: low-rate position and flight-control summaries, commands that have to arrive in time, and large images or lidar point clouds. When all three share one default bearer, images push commands into timeout. Commands and summaries belong on a separate short message or a higher priority. Images can drop resolution, or upload only during the working segment. The ground station, the aircraft, and the cloud should use one mission id. Otherwise the track in the cloud cannot be tied to that launch on the ground station. Operator credentials, airspace permission, and the flight plan are conditions of the job. A connected link does not mean those permissions are in force.
What has to be true before cellular carries beyond-visual flight
Using cellular as the primary beyond-visual link first means the route crosses areas where airborne use is allowed, and the SIM's roaming and regional policy cover the whole route, not only the takeoff field. Handover at low altitude is more frequent than in a ground vehicle. If the airframe or the gimbal blocks the antenna, the module can be registered and still have no useful throughput. What happens after loss of link has to be written into the flight controller beforehand: hover, return, or continue on the last waypoint, and that action has to match the time used to declare the link lost. Too short, and an ordinary handover is treated as a lost link. Too long, and the aircraft flies out of the airspace with no command.
A position report should include latitude and longitude, altitude, ground speed, and time, and the altitude should say whether it is pressure altitude or height above the takeoff point. If the cloud receives only a horizontal position, it cannot tell whether a height limit was crossed. Surveillance related to BVLOS also requires the report interval to stay inside the spacing the airspace authority sets. If image upload stretches that interval, surveillance marks the aircraft as a lost target. A sensor fault on the UAV and a link fault need different codes. Otherwise maintenance reads a bad altimeter as a SIM dropout.
Video crowding out the command channel
During commissioning it is easy to treat video and cellular as one channel, and to read "video is on screen" as "the system is fine." Video can still be playing on the ground link while commands on cellular have already timed out. The reverse is also true: cellular can ping the module while the video antenna is not aimed. Acceptance should break video and cellular separately and confirm that the remaining link degrades the way the mission sheet says, rather than watching the picture only when both are up.
The other problem is data volume and address. Uploading raw video for the whole mission fills the plan halfway, and then even the position summary cannot get out. The record in the cloud stops at mid-route. If the airborne end uses a public address that changes, and the ground station writes the previous mission's address into a whitelist, every command is refused after the next attach. It looks as if the aircraft will not take control. At the end of a mission the video session should be closed on purpose, with a reason, so the cloud does not count an open session as still airborne.
When several aircraft share one ground-station account, every status needs an airframe id and a mission id before the cloud can split the tracks. Missing ids collapse into one false track that seems to fly back and forth. If the airborne radio and the cellular antenna sit too close, confirm on the ground that cellular can still attach before launch. The return point should be written into the flight controller when the mission starts. If the ground station changes the return point only after the link recovers, an aircraft already returning to the old point will not turn off that path midway. The end record should distinguish a normal landing, a manual takeover, and a return after loss of link, so it can be compared with the actual flight period in the airspace filing.