Patent Description:
The Internet of Things (IoT) may bring Internet connectivity to <NUM> billion devices by <NUM>. For organizations, loT devices may provide opportunities for monitoring and tracking other devices and items, including loT devices and other devices. As the number of these devices increases, implementation of self-organization techniques to monitor and control the devices will become more useful. Further, increasing autonomous operations and interactions of the loT devices will allow new uses that have not been previously possible. Document <CIT> relates to mesh networks, and to systems, methods, and apparatus for identifying invalid nodes within a mesh network. Document <CIT> relates to the field of unmanned aerial vehicles, and to an unmanned aerial vehicle and a system and a method for controlling the same in the field of unmanned aerial vehicles. Paper "<NPL>" relates to communication networks for UAVs (unmanned aerial vehicles). Document <CIT> relates to performance tests for evaluating the performance of various nodes in a network. Paper "<NPL>" surveys methods for an automated probabilistic diagnosis of large multiprocessor systems. Paper "<NPL>" discusses adaptations of a CAN network for airborne applications. Document <CIT> relates to a method for handling a faulty device in a vehicle communication network.

The present invention is defined in the appended independent claim <NUM> to which reference should be made.

The same numbers are used throughout the disclosure and the figures to reference like components and features. Numbers in the <NUM> series refer to features originally found in <FIG>; numbers in the <NUM> series refer to features originally found in <FIG>; and so on.

The internet of things (IoT) is a concept in which a large number of computing devices are interconnected to each other and to the Internet to provide functionality and data acquisition at very low levels. For example, loT networks may include commercial and home automation devices, such as water distribution systems, electric power distribution systems, pipeline control systems, plant control systems, light switches, thermostats, locks, cameras, alarms, motion sensors, and the like. These devices, termed loT devices herein, may be accessible through remote computers, servers, and other systems, for example, to control systems or access data. Further loT devices may include loT gateways, used to couple other loT devices to cloud applications.

In examples described herein, IoT devices organize themselves into swarms that may be controlled by a user as a single entity. Much of the operational control is handled by the swarm itself, as a semiautonomous unit. The techniques include coordination in the swarm using low-latency techniques to coordinate movement and communications. The swarms may be used in various applications, such as wireless search and rescue (WiSAR), tracking sporting events, setting up wireless networks at a disaster site, and the like. Further, the techniques provide resilient interconnections for large number of loT devices in a network. As loT devices are expected to be deployed in great numbers, in a volatile and dynamic deployment, such as a WiSAR scenario or tracking a sporting event in the field, IoT device attrition may be common.

The techniques herein address the challenge of potential information loss due to attrition by leveraging the combined swarm memory and processing resources to increase the resilience of the network. This may be performed via a batch broadcast hopping and a store and forward process to use the swarm nodes as distributed memory and processing entities. Further, power may be delivered in-deployment via a recharging scheme wherein designated charging devices, termed swarm secondary master devices herein, provide power to charge other swarm devices. For example, this may be performed by a recharging-in-the-air scheme in which the secondary master device is brought close to a drone in need of power to provide the power using induction or wired power contacts. In another example, the drone may land for the power delivery wherein the secondary master device may function as a charging / landing pad.

The techniques provide for efficient detection of erroneous loT nodes in a dense, low-cost network deployment and elimination of such malfunctioning nodes from network setup. The provision of support and control for a 3D- moving mesh network using inter-node delta vector information from a known GPS waypoint to locate and direct the movement of the swarm nodes. The potential for information loss due to loT device attrition is decreased by using in-swarm memory, processing, and data offload in which each node frequently broadcasts batch observations and status information to neighboring swarm nodes thus treating the swarm network as a store and forward combined processing entity.

The swarm can coordinate the movement of individual drones using fast inter-node communications to calculate delta-movement instructions, for example, {+<NUM>, -<NUM>, +<NUM>}, that are deviations from a known geographic basepoint, such as a GPS waypoint. The delta instructions may denote a change in latitude, longitude, and altitude from the GPS waypoint. This allows the movement of groups of drones to be coordinated as a unit, rather than as individually guided drone devices. As the loss of swarm nodes is probable during events, for example, due to battery life, in-swarm memory and messaging may be used to record data on events and targets of interest, lowering the likelihood of data loss. The swarm acts as a combined memory and processing store that frequently offloads aggregated data to an offsite datacenter, for example, through a satellite uplink or cellular network connection to a master drone.

In the techniques described herein, two different types of drone networks may be defined. For example, a static drone network may be used for covering static events such as disasters, fixed location sporting events, and the like. A mobile drone network may be used for covering moving events such as a marathon, a bicycle race, and the like.

Further, it should be noted that the description of the techniques for networks of drones, or unmanned aerial vehicles (UAVs), is merely one example. The techniques may be used for the control of swarms in any number of other autonomous vehicles, such as autonomous underwater vehicles (AUVs), surface rovers, and others. Further, the techniques may be implemented in any number of dense mesh networks of internet-of-things (IoT) devices, such as may be used in commercial sensing and control applications, housing control, automotive applications, automated teller machines, and many others. In these applications, each of the loT devices may be considered a single node that is analogous to a single drone in the description herein.

<FIG> is a schematic example of a static mesh network <NUM> of drones <NUM>. In this example, the drones <NUM> may hold a position over the surface, such as to provide surveillance and communications at a disaster site. If a drone <NUM> fails, it may automatically land, and other drones <NUM> may move to cover the loss. If a new drone <NUM> is added to the static mesh network <NUM>, for example, to replace a failed drone <NUM> or to extend coverage, the other drones <NUM> may move apart to provide even coverage over the target area.

The drones <NUM> of the static mesh network <NUM> may use shared spectrum radio communication links <NUM>, such as LSA (Licensed Shared Access) / SAS (Spectrum Access System), to communicate between themselves. The LSA/SAS system may use frequencies in several bands, for example, in the cellular communications frequencies near <NUM>, in the <NUM> range, and higher. Selection of individual frequencies for a communications link <NUM> may be performed by the amount of interference between devices. Further communications techniques are described herein.

The drones <NUM> of the static mesh network <NUM> may provide for fast deployment, in which the drones <NUM> self-organize to form a (gigabit) Gbit/s backhaul, and each drone <NUM> may provide wireless network based internet access, images of the site, and other services. The drones <NUM> of the static mesh network <NUM> may be programmable and may use triple radios to establish communications between the drones <NUM> and satellites <NUM>, between the drones <NUM>, and between drones <NUM> and mobile devices <NUM>, such as Wi-Fi clients. The mobile devices <NUM> may communicate with the drones <NUM>, and the drones <NUM> may relay the information to the satellites <NUM> through up/down links <NUM>. The satellites <NUM> may relay the information to a base station, or base <NUM>, through another up/down link <NUM>.

Each drone <NUM> may operate as an independent communication cell, for example, providing Wi-Fi, or other radio network communications, to mobile devices <NUM> that are in range. As the mobile devices <NUM>, or the drones <NUM> move, the communications with the mobile device <NUM> may be handed off to other drones <NUM> to maintain the communications.

The shared spectrum radio communication links <NUM> may be used by the drones <NUM> to exchange information on location, control, and resource allocation. For example, particular frequencies for communication with the mobile devices <NUM> may be allocated across the drones <NUM> such that interference is minimized. For example, a frequency may be reused if a distance between two drones <NUM> employing the same frequency is maximized. Accordingly, a Gigbit wireless backhaul may be implemented between drones <NUM> using Global Positioning assisted multi-antenna beamforming. For example, each drone <NUM> may include a phased array of antennas that can be used to control the direction of the communications by constructive and destructive interference.

<FIG> is a schematic example of a dynamic-mesh drone network <NUM> in which the individual slave drones <NUM> and a master drone <NUM> may move around an environment, while maintaining themselves in an overall location. In this example, the drones <NUM> and <NUM> are monitoring an event taking place on a pitch <NUM> in a stadium <NUM>.

The dynamic-mesh drone network <NUM> may provide reliable and consistent services for monitoring the event and other activities, such as providing Internet access to large numbers of mobile devices. In this example, the dynamic-mesh drone network <NUM> may be used to provide camera views of a defined target on the pitch <NUM>.

The basic approach for the set-up of the dynamic-mesh drone network <NUM> and the management of frequency allocation is similar to the approach described with respect to <FIG>. However, in this context, the drones <NUM> and <NUM> may interact to create a <NUM>-dimensional (3D) mesh in which the drones <NUM> and <NUM> move, as indicated by the dotted arrows <NUM>, in any number of directions. The control of the dynamic-mesh drone network <NUM> may be performed by indicating a target, such as a soccer ball on the pitch <NUM>, and allowing the drones <NUM> and <NUM> to interact and move as needed to keep the target in view, for example, of a preset number of cameras.

The initial communications may be established between the master drone <NUM> and a base station <NUM>. Once the initial communications have been established, the master drone <NUM> may initiate communications with the slave drones <NUM>. The 3D mesh network may be formed by the drones <NUM> and <NUM> distributing signals that invite neighboring drones <NUM> and <NUM> to establish a connection. Once the connections are established, the data on surrounding drones <NUM> or <NUM> may be included into a mesh drone list.

The drones <NUM> and <NUM> may then take off and establish the spacing between drones, as described herein. Since the drones <NUM> and <NUM> may not only fly next to each other at the same height level, but may also move vertically, a 3D position detection is used. Thus, messages used for establishing a connection may be emitted through isotopic antennas that cover the space in direct proximity to a drone <NUM> or <NUM>, for example, as a sphere around the drone <NUM> or <NUM>.

Furthermore, a fast relaying setup is achieved in order for the dynamic-mesh drone network <NUM> to enable infrastructure-enabled drone security and safety schemes. In particular, before a drone <NUM> or <NUM> fails, the potential fault may be detected by sensors in the drone <NUM> or <NUM>, or in surrounding drones <NUM> or <NUM>. For example, a neighboring drone <NUM> or <NUM> may detect that a drone <NUM> or <NUM> is having difficulties maintaining an expected altitude. The drone <NUM> or <NUM> may then be placed out of order, for example, through a controlled landing, prior to a crash landing or other accident. If the master drone <NUM>, a backup may be launched shortly before the master drone <NUM> is landed. In some examples, a slave drone <NUM> may take over for the master drone <NUM>, becoming the new master drone for the dynamic drone-mash network <NUM>. This may occur, for example, when the slave drone <NUM> powers up systems such as a GPS system and an uplink transceiver.

Finally, a recharging scheme may be implemented. This may be performed by having a drone <NUM> or <NUM> land on a recharging platform, for example, built into a secondary master drone, when a battery in a drone <NUM> or <NUM> is determined to be in need of charging. The charging may then be performed through wired contacts in the platform, or wirelessly, through an inductive coupling charger. In some examples, a recharging-in-the-air scheme may be implemented in combination with the mesh networking, relaying and optimized power allocation. In this example, charging drones may be brought close to drones <NUM> or <NUM> in need of power and either provide a power cable through a suitable "catapult" mechanism or wireless recharging may be performed through suitable coils being implemented into the drones <NUM> or <NUM>.

<FIG> is a schematic example of a mobile-mesh drone network <NUM>, in which the slave drones <NUM> and master drones <NUM> and <NUM> move in an environment relative to a target <NUM>. The drones <NUM>-<NUM> may be controlled by setting the target, and allowing the drones <NUM>-<NUM> to move along with the target, as indicated by the dotted arrows <NUM>. Although the average velocity and direction of each of the drones <NUM>-<NUM> is the same, tracking the target <NUM>, each of the drones <NUM>-<NUM> may be moving in slightly different directions in 3D space, for example, to keep the target centered in camera views while maintaining preset separations between drones <NUM>-<NUM> and following the terrain <NUM>.

In this example, there are two master drones <NUM> and <NUM>. A first master drone <NUM> is communicating with a base station <NUM>, which may be a car, scooter, or other wheeled or airborne vehicle accompanying the drones <NUM>-<NUM> through the terrain <NUM>. The first master drone <NUM> may also be in communications with one or more satellites <NUM>, for example, to obtain position coordinates by GPS, to upload data to the cloud, to download control signals from the cloud, or any combinations thereof. A second master drone <NUM> may provide backup communications, for example, by wireless wide area network (WWAN) communications through cell towers <NUM>.

The initialization of the mobile-mesh drone network <NUM> may be similar to that used for the dynamic-mesh drone network <NUM> (<FIG>). The master drones <NUM> and <NUM> may initiate communications with the base station <NUM>, the satellites <NUM>, or the cell towers <NUM>. Once communications are established between one or both of the master drones <NUM> or <NUM> and a control system, the master drone <NUM> or <NUM> may initiate communications with the slave drones <NUM>. Once the mobile-mesh drone network <NUM> is established, the drones <NUM>-<NUM> may launch, lock the designated target and start following the target. As described with respect to <FIG>, if a drone <NUM>-<NUM> starts to fail, for example, due to a low battery level, it may be instructed to land, charged on a landing pad, or charged by another drone.

Any of the drone networks in <FIG> may be considered a swarm, or swarm network, as used herein. Further, fixed location loT devices may either form a mesh network, or join with the swarms described herein.

<FIG> is a drawing of a cloud computing network, or cloud <NUM>, in communication with a mesh network of drones <NUM>-<NUM>, which may be termed a fog <NUM>, operating at the edge of the cloud <NUM>. The fog <NUM> may be considered to be a massively interconnected network wherein a number of drones <NUM>-<NUM>, or other devices, are in communication with each other, for example, by radio links <NUM>. The radio links <NUM> may be LSA/SAS links using LTE cellular communications, as described above, or may include any number of other radio networks, such as wireless local area networks (WLAN) consistent with the IEEE <NUM> standard, wireless wide area networks (WWAN) using LTE or other cellular technologies, and the like.

The communications protocol may be consistent with the open interconnect consortium (OIC) standard specification <NUM> released by the Open Connectivity Foundation™ (OCF) on December <NUM>, <NUM>. This standard allows devices to discover each other and establish communications for interconnects. Other interconnection protocols may also be used, including, for example, the standards under development by the Open Fog Consortium, the optimized link state routing (OLSR) Protocol, or the better approach to mobile ad-hoc networking (B. ), among many others. Further, simplified packet protocols, as described herein, may be used to lower communications overhead between drones <NUM>-<NUM>.

Three types of drones <NUM>-<NUM> are shown in this example, slave drones <NUM>, a master drone <NUM>, and a secondary master drone <NUM>, although any combinations of drones and functionality may be used. The master drone <NUM>, and in some examples, the secondary master drone <NUM>, may communicate with gateways, such as satellites, cell phone towers, or base stations, among others, over gateway links <NUM>. The gateway links <NUM> may include satellite uplink frequencies, for example, in the Ku band of <NUM> - <NUM>, WWAN communications with cell phone towers, or LSA/SAS communications with base stations, as described herein.

The slave drones <NUM> communicate with other drones <NUM>-<NUM>, as well as performing other tasks, such as taking images, video, or sensor readings. The slave drones <NUM> also perform positioning tasks, such as maintaining a particular separation from other drones <NUM>-<NUM>, tracking a target, and the like.

The secondary master <NUM> may be a backup to the master drone <NUM>, and may also perform other services. For example, the secondary master <NUM> may be used for charging drones that have a low battery reserve. The secondary master may be in a fixed location in deployments that are in a general fixed location, such as described with respect to <FIG> and <FIG>. In deployments in which the mesh network of drones is moving, for example, as described with respect to <FIG>, the secondary master drone <NUM> may include propulsion systems to remain with the other drones <NUM>-<NUM>. In this example, the secondary master drone <NUM> may charge other drones while both are moving to allow the mesh network to stay with the moving target.

The gateways <NUM> may send data from the drones <NUM>-<NUM> in the fog <NUM>, for example, received from the master drone <NUM>, to other locations, such as a control system <NUM> or a broadcast system <NUM>. Further, the gateways <NUM> may provide commands to the fog <NUM>, such as to deploy, to move to a fixed network location, track a target, and the like.

Communications from any slave drone <NUM> may be passed along the most convenient path between the slave drone <NUM> and the master drones <NUM> or <NUM> to reach the gateways <NUM>. In these networks, the number of interconnections provide substantial redundancy, allowing communications to be maintained, even with the loss of a number of slave drones <NUM>.

The fog <NUM> of the drones <NUM>-<NUM> may be presented to devices in the cloud <NUM>, such as the control system <NUM> or the broadcast system <NUM>, as a single device located at the edge of the cloud <NUM>, e.g., a fog <NUM> device or swarm. In this example, a command may request a particular camera angle for a video feed of a target, and the fog <NUM> will automatically identify the drone <NUM> or <NUM> that is closest to the requested view. Further, the operator may fly the drones <NUM>-<NUM> in the fog as a single device, for example, indicating a target area and allowing the drones <NUM>-<NUM> in the fog <NUM> to determine the motions that can be used to fly to and provide requested sensor readings, such as video, images, or sensor reading, of the target area.

Accordingly, the drones <NUM>-<NUM> forming the fog <NUM> device may be configured in a declarative programming style, allowing the drones <NUM>-<NUM> to reconfigure their operations and determine needed resources in response to conditions, queries, and device failures. For example, a query from a user located at a control system <NUM> about the location of a target may result in the fog <NUM> device determining the location based on the relative locations of the individual drones <NUM>-<NUM> to the target.

<FIG> is a schematic drawing of a swarm network <NUM> with one designated device, the master drone <NUM>, establishing a GPS waypoint as a basepoint. The slave drones <NUM> in the swarm network <NUM> may use deltas calculated from this basepoint for orientation and coordination. For example, the master drone <NUM> may pick up GPS signals <NUM> from satellites <NUM> to establish the basepoint. The basepoint may have the format of {latitude, longitude, altitude}, which is an absolute position, for example, {-<NUM>, <NUM>, <NUM>}. The slave drones <NUM> may calculate position as a delta from this position, for example, slave drone A <NUM> may have a delta position of {-<NUM>, -<NUM>, <NUM>} relative to the master drone <NUM>. Other slave drones <NUM> may determine position similarly, for example, B at {-<NUM>, -<NUM>, <NUM>}, C at {<NUM>, <NUM>, -<NUM>}, G at {-<NUM>, <NUM>, <NUM>}, and H at {-<NUM>, <NUM>, <NUM>}, among others. The role of the drone <NUM> or <NUM> that is determining the GPS waypoint may switch between drones <NUM> and <NUM>.

The position of each slave drone <NUM> relative to other slave drones <NUM>, and to the master drone <NUM>, may be calculated by measuring a position using GPS signals at each slave drone <NUM>, then calculating the delta from a position transmitted by the master drone <NUM>. The slave drones <NUM> may also calculate a relative position without using GPS receivers, lowering the power demand. For example, each of the slave drones <NUM> may have a phased antenna array, allowing the calculation of position based on the phase or timing differences between signals from other drones that are received at each antenna. Further, a multiple antenna array may be used to determine relative position based on the time of flight of a signal at each antenna.

As described herein, the drones <NUM> and <NUM> do not need to be individually controlled entities. The offsets between the drones <NUM> and <NUM> may be used to enable each drone <NUM> and <NUM> to both track and orient itself based on offsets from the known GPS waypoint. Utilizing this approach, each of the drones <NUM> and <NUM> in the swarm network <NUM> may operate in a semi-autonomous manner without direct human intervention.

By adopting this delta-vector approach, low-latency changes in direction, velocity, and altitude can be implemented for fine-grained orchestration of the swarm network <NUM>. Higher stability may be achieved by providing a window around a target position for a slave drone <NUM>. This may reduce the number of control changes the slave drone <NUM> makes to stay at or near a target position. For example, rather than a single point in space: {-<NUM>, -<NUM>, <NUM>}, the position of slave drone A <NUM> may be set as a range: {-<NUM> to <NUM>, -<NUM> to <NUM>, <NUM> to <NUM>}. Low latency may be further supported by communicating only with neighbor nodes, using the vector offset data to provide smaller payload sizes than traditional absolute GPS positioning. As used herein, nodes that have fewer nodes, or hops, separating them from the master drone <NUM> are closer to the master drone, while nodes that have more nodes, or hops, separating them from the master drone <NUM> are farther from the master drone.

<FIG> is a schematic drawing of the swarm network <NUM> with slave drones <NUM> in the swarm network <NUM> providing observation storage and processing support to neighboring slave drones <NUM>. Like numbered items are as described with respect to <FIG>. The memory and processors of the individual drones <NUM> and <NUM> in the swarm network <NUM> may be used to provide batch observation storage and processing support to neighboring nodes in order to reduce the potential of information loss due to attrition of drones <NUM> and <NUM>. In this example, data from a slave drone <NUM>, H, is broadcasted <NUM> to other locally adjacent slave drones <NUM>, E, F, and G, for storage and processing. The data may then be propagated to drone closer to the master drone <NUM>. When the data reaches the master drone <NUM>, it may be sent to a satellite <NUM> through an uplink <NUM>. As described herein, cellular networks and other uplink/downlink mechanisms may be used also.

Sending the data to adjacent drones <NUM> and <NUM> also increases the energy efficiency of the drones <NUM> and <NUM> in the swarm network <NUM> as they only need to dispatch data to locally adjacent drones <NUM> and <NUM> instead of directly sending the data to a satellite or other remotely located gateway. Further, by adopting a broadcast approach instead of a directed unicast method, the resilience of the swarm network <NUM> is increased by leveraging redundancy. The batch observation method may entail sending snapshot captures of the observed metric for the target, such as video frames, still images, infra-red sensor readings or images, particle count, air-quality, and the like, to neighboring drones <NUM> and <NUM>. Thus, measurements are not stored for long periods on an individual drone <NUM> or <NUM>, protecting against lost data if that drone <NUM> or <NUM> should fail.

<FIG> is a schematic diagram of node failure management in an loT mesh network, such as a swarm network <NUM>, as described herein. Dense networks of drones, and other loT devices, are expected to have a high probability of node failure or operational faults, for example, in highly demanding applications such as wireless search and rescue (WiSAR). The loT devices in a mesh network may monitor communications and operations of other loT devices to identify the correct functioning of surrounding network nodes and classify those nodes as valid, if functioning correctly, or invalid, if not functioning correctly. The loT network <NUM> may automatically reconfigure itself to excluding those network nodes which are functioning erroneously, providing false data or not operating at all. Thus, valid nodes <NUM> would be included into the operational loT network <NUM>. Invalid nodes <NUM> would not be included. Further, the invalid nodes <NUM> may be instructed to exit the network or power down in order to avoid any disturbance of the valid nodes <NUM>.

The loT network <NUM> may be tested by identifying valid nodes <NUM> through suitable neighborhood detection. To increase the likelihood of identifying valid nodes <NUM>, the swarm network <NUM> may be configured to have at least two valid nodes <NUM> approve a node in order to have it included into the network.

A node may be tested by forcing a response to an external trigger, for example, initiated by the approving node. This may be a predefined self-testing mode that can be triggered externally or it may be any other forcing of a response following the receipt of the triggering communication by the node. For example, the provision of context information, or the provision of any other communicated data, may be triggered and then tested to determine whether the data is correct, sent correctly, and in the correct frame format. If the overall format is correct, and the message appears to be correct, then the node may be considered to be a valid node <NUM>. Other indicators may be used in addition to, or instead of communications, such as confirmation of a position within an expected range for a drone or other moving node, a confirmation of battery power levels within an expected range, and the like.

The identification of a valid node <NUM> is communicated to neighboring nodes in a message. The neighboring nodes accept the message if the approving node has also been determined to be a valid node <NUM>. If a neighboring valid node <NUM> detects the correct operation of a target node, and also receives the message that other nodes have identified that the target node operates correctly, then the target node is included into a node list of valid nodes <NUM>.

If the target node is an invalid node <NUM>, for example, not responding to queries, sending a poorly framed message, moving outside of position limits, and the like, then the finding is shared with another node doing the same test. When at least two results correspond to each other and demonstrate that the node is working incorrectly, then the invalid node <NUM> may be forced to shut down, or otherwise exit the network. This may be implemented through a suitable external trigger, such as a disable command or other instruction. If the invalid node <NUM> is moving, it may be instructed to land, move to a separate area for charging, and the like. If this is not possible, for example, the invalid node <NUM> has stopped communicating effectively, the problematic node is excluded from the list of valid nodes <NUM> and will not be included into the swarm network <NUM>. At that point, instructions in the invalid node <NUM> may direct it to shut down, automatically land, and the like.

Further, in a mesh network <NUM> some of the nodes may be responsible for communicating with devices outside of the mesh network <NUM>, for example, the cloud. For example, the master drones <NUM> and <NUM> described with respect to <FIG> handle communications between the drown swarm and the gateways <NUM>.

Master nodes performing the same communications function may be included in a mesh network <NUM> made up of nodes that are mounted in a fixed location. If the master nodes fail, however, communication may be lost to devices outside of the mesh network. This may be mitigated by including backup nodes that have communications capability to function as master nodes, such as uplink transceivers and the like. The additional communications capability may be kept in an unpowered state until needed to lower power demand.

In an external strategy, when a loss of communications to devices outside of the mesh network <NUM> is detected, the backup nodes may intermittently activate the additional communications capability, for example, at scheduled times, to look for command messages. In this example, the external devices may note the loss of communications, and intermittently broadcast a command, for example, at scheduled times, instructing one of the backup nodes to fully activate the standby communication capabilities and become the master node.

The mesh network may not need an external command to activate the system. For example, if a loss of connectivity to devices outside of the mesh network <NUM> is detected, the backup nodes may negotiate which should assume the role of the master node. This may be performed by a sequential activation of the standby communication capabilities in each node to determine which node has the clearest communications to the external devices. Other factors, such as a nodes remaining battery life, location, and the like, may be included in the negotiation.

<FIG> is a schematic diagram <NUM> of a communications strategy, in which data packets are shortened to minimize communications overhead. Traditional loT device communications data packets <NUM> may follow a standard layer structure, in which overhead, such as framing bits and the like, is added by each of the open systems interconnect (OSI) layers. For example, the physical layer adds PHY overhead <NUM> for signaling, encoding, and the like. The data link layer includes the media access control layer, which adds MAC overhead <NUM> to create Ethernet frames, and the logical link layer, which adds transmission control protocol (TCP) overhead <NUM> for flow control, and the like.

In the present techniques, a multi-cross layer optimization <NUM> may be performed to regrouping the overhead across multiple layers into a single, highly optimized overhead <NUM> part in the frame. For example, on each layer of the OSI communications, signaling and framing fields of dynamic length are used so that overhead and signaling information from other layers can be added at the lowest overhead level possible.

In this technique, the available number of bits per layer may be dynamically varied, depending on the communication. For example, when different amounts of data are to be communicated by a specific layer, the size is adapted correspondingly. With less data being available, the size of the field is reduced and thus the overhead for signaling information is minimized.

Further, a maximum signaling field size may be imposed, which may vary from one frame to another. For example, a number of physical layer bits (PLB) for a frame number n may be set as PLB(n), wherein the number of bits used depends on the frame number. Thus, a large number may be initially used, then become smaller and smaller from one frame to another and then larger again.

On some frames, no signaling, or very limited signaling, may be included in a frame with higher layer data to increase the efficiency of frames. On other frames, some space for signaling information may be included, so that the signaling information is provided at specific predefined points in time.

<FIG> is a block diagram of components that may be present in an example of a slave device <NUM> that may be used in a swarm network. The slave device <NUM> may include any combinations of the components shown in the example. The components may be implemented as ICs, portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof adapted in the slave device <NUM>, or as components otherwise incorporated within a chassis of a larger system. The block diagram of <FIG> is intended to show a high level view of components of the slave device <NUM>. However, some of the components shown may be omitted, additional components may be present, and different arrangement of the components shown may occur in other implementations.

Further, the slave device <NUM> may be a modified drone, such as a multicopter available from Yuneec International Co. Of Hong Kong. Typical models that may be used in examples include the Typhoon H and Tornado hexacopters, the Typhoon <NUM> quadcopter, and any number of other units. The examples are not limited to these units, as any number of other drones may be used. For example, drones available from DJI of Shenzen, China under the Phantom series may be used. Further, the techniques are not limited to helicopter type drones, as any number of other autonomous vehicles may be used, including land vehicles, autonomous underwater vehicles (AUVs), and the like. Further, in some examples, the techniques may be implemented in fixed location IoT devices, such as home or commercial automation, sensor grids, SCADA, and the like.

The slave device <NUM> may include a processor <NUM>, which may be a microprocessor, a multi-core processor, a multithreaded processor, an embedded processor, or other known processing element. As an example, the processor <NUM> may include an Intel® Architecture Core™ based processor, such as an Atom™, an i3, an i5, an i7, or an MCU-class processor, or another such processor available from Intel® Corporation, Santa Clara, CA. However, other processors may be used, such as available from Advanced Micro Devices, Inc. (AMD) of Sunnyvale, CA, a MIPS-based design from MIPS Technologies, Inc. of Sunnyvale, CA, an ARM-based design licensed from ARM Holdings, Ltd. or customer thereof, or their licensees or adopters. The processors may include units such as an A5/A6, or other processors from Apple® Inc. , a Snapdragon™ processor from Qualcomm® Technologies, Inc. , or an OMAP™ processor from Texas Instruments, Inc.

To lower power demand, the processor <NUM> may be a microcontroller unit, an ultra-low voltage processor, or other known low-power processing element. As an example, the processor <NUM> may be an Intel® Architecture Core™ based processor, such as a Quark™ D2000, MCS-<NUM>, MCU-<NUM> or another such microcontroller unit. However, other low power processors may be used, such as from the PIC™ family of microcontrollers available from Microchip Technology of Chandler, Arizona, or the MSP series of microcontrollers available from Texas Instruments, Inc. of Dallas, Texas, among many others.

The processor <NUM> may communicate with a system memory <NUM> over a bus <NUM>. Any number of memory devices may be used to provide for a given amount of system memory. As examples, the memory can be random access memory (RAM) in accordance with a Joint Electron Devices Engineering Council (JEDEC) low power double data rate (LPDDR)-based design such as the current LPDDR2 standard according to JEDEC JESD <NUM>-2E (published April <NUM>), or a next generation LPDDR standard to be referred to as LPDDR3 or LPDDR4 that will offer extensions to LPDDR2 to increase bandwidth. In various implementations the individual memory devices may be of any number of different package types such as single die package (SDP), dual die package (DDP) or quad die package (Q17P). These devices, in some embodiments, may be directly soldered onto a motherboard to provide a lower profile solution, while in other embodiments the devices are configured as one or more memory modules that in turn couple to the motherboard by a given connector. Any number of other memory implementations may be used, such as other types of memory modules, e.g., dual inline memory modules (DIMMs) of different varieties including but not limited to microDIMMs or MiniDIMMs. For example, a memory may be sized between 2GB and 16GB, and may be configured as a DDR3LM package or an LPDDR2 or LPDDR3 memory, which is soldered onto a motherboard via a ball grid array (BGA).

The system memory <NUM> may be used to store data collected by the slave device <NUM>, such as video, images, sensor readings, prior to the data being transferred to other devices. Further, the system memory <NUM> may be used for storing results of position calculations, movement deltas, and holding data propagated from other devices prior to the data being propagated to a master device.

To provide for persistent storage of information such as data, applications, operating systems and so forth, a mass storage <NUM> may also couple to the processor <NUM> via the bus <NUM>. To enable a thinner and lighter system design the mass storage <NUM> may be implemented via a solid state disk drive (SSDD). However, the mass storage <NUM> may be implemented using a micro hard disk drive (HDD) in some slave devices <NUM>. Further, any number of new technologies may be used for the mass storage <NUM> in addition to, or instead of, the technologies described, such resistance change memories, phase change memories, holographic memories, or chemical memories, among others. For example, the slave device <NUM> may incorporate the 3D XPOINT memories from Intel® and Micron®. Many of these technologies may lower the power demand while increasing the reliability of the data storage.

The components may communicate over the bus <NUM>. The bus <NUM> may include any number of technologies, including industry standard architecture (ISA), extended ISA (EISA), peripheral component interconnect (PCI), peripheral component interconnect extended (PClx), PCI express (PCIe), or any number of other technologies. The bus <NUM> may be a proprietary bus, for example, used in a SoC based system. Other bus systems may be included, such as an I<NUM>C interface, an SPI interface, point to point interfaces, among others.

The bus <NUM> may couple the processor <NUM> to a swarm radio transceiver <NUM> for communications with other swarm devices <NUM>. The swarm devices <NUM> may include any combinations of master devices, slave devices, and secondary master devices, as described with respect to <FIG>. Any number of radio communications and protocols may be used, as described herein. For example, the radio transceiver may be an LTE or other cellular transceiver that uses spread spectrum (SPA/SAS) communications for implementing high speed communications, such as for video transfers. In other embodiments, any number of other protocols may be used, such as Wi-Fi networks for medium speed communications, such as still pictures, sensor readings, and provision of network communications. Further, low power, long range communications systems, such as the LPWA protocol, may be used for highly autonomous and remote deployments.

Further, the swarm radio transceiver <NUM> may use any number of 3GPP (Third Generation Partnership Project) specifications, notably Long Term Evolution (LTE), Long Term Evolution-Advanced (LTE-A), and Long Term Evolution-Advanced Pro (LTE-A Pro). It is understood that such exemplary scenarios are demonstrative in nature, and accordingly may be similarly applied to other mobile communication technologies and standards, such as any Cellular Wide Area radio communication technology, which may include e.g. a 5th Generation (<NUM>) communication systems, a Global System for Mobile Communications (GSM) radio communication technology, a General Packet Radio Service (GPRS) radio communication technology, an Enhanced Data Rates for GSM Evolution (EDGE) radio communication technology, and/or a Third Generation Partnership Project (3GPP) radio communication technology (e.g. UMTS (Universal Mobile Telecommunications System), FOMA (Freedom of Multimedia Access), 3GPP LTE (Long Term Evolution), 3GPP LTE Advanced (Long Term Evolution Advanced), 3GPP LTE Advanced Pro (Long Term Evolution Advanced Pro)), CDMA2000 (Code division multiple access <NUM>), CDPD (Cellular Digital Packet Data), Mobitex, <NUM> (Third Generation), CSD (Circuit Switched Data), HSCSD (High-Speed Circuit-Switched Data), UMTS (<NUM>) (Universal Mobile Telecommunications System (Third Generation)), W-CDMA (UMTS) (Wideband Code Division Multiple Access (Universal Mobile Telecommunications System)), HSPA (High Speed Packet Access), HSDPA (High-Speed Downlink Packet Access), HSUPA (High-Speed Uplink Packet Access), HSPA+ (High Speed Packet Access Plus), UMTS-TDD (Universal Mobile Telecommunications System - Time-Division Duplex), TD-CDMA (Time Division - Code Division Multiple Access), TD-SCDMA (Time Division - Synchronous Code Division Multiple Access), 3GPP Rel. <NUM> (Pre-<NUM>) (3rd Generation Partnership Project Release <NUM> (Pre-4th Generation)), 3GPP Rel. <NUM> (3rd Generation Partnership Project Release <NUM>), 3GPP Rel. <NUM> (3rd Generation Partnership Project Release <NUM>) , 3GPP Rel. <NUM> (3rd Generation Partnership Project Release <NUM>), 3GPP Rel. <NUM> (3rd Generation Partnership Project Release <NUM>), 3GPP Rel. <NUM> (3rd Generation Partnership Project Release <NUM>), 3GPP Rel. <NUM> (3rd Generation Partnership Project Release <NUM>), 3GPP LTE Extra, LTE Licensed-Assisted Access (LAA), UTRA (UMTS Terrestrial Radio Access), E-UTRA (Evolved UMTS Terrestrial Radio Access), LTE Advanced (<NUM>) (Long Term Evolution Advanced (4th Generation)), cdmaOne (<NUM>), CDMA2000 (<NUM>) (Code division multiple access <NUM> (Third generation)), EV-DO (Evolution-Data Optimized or Evolution-Data Only), AMPS (<NUM>) (Advanced Mobile Phone System (1st Generation)), TACS/ETACS (Total Access Communication System/Extended Total Access Communication System), D-AMPS (<NUM>) (Digital AMPS (2nd Generation)), PTT (Push-to-talk), MTS (Mobile Telephone System), IMTS (Improved Mobile Telephone System), AMTS (Advanced Mobile Telephone System), OLT (Norwegian for Offentlig Landmobil Telefoni, Public Land Mobile Telephony), MTD (Swedish abbreviation for Mobiltelefonisystem D, or Mobile telephony system D), Autotel/PALM (Public Automated Land Mobile), ARP (Finnish for Autoradiopuhelin, "car radio phone"), NMT (Nordic Mobile Telephony), Hicap (High capacity version of NTT (Nippon Telegraph and Telephone)), CDPD (Cellular Digital Packet Data), Mobitex, DataTAC, iDEN (Integrated Digital Enhanced Network), PDC (Personal Digital Cellular), CSD (Circuit Switched Data), PHS (Personal Handy-phone System), WiDEN (Wideband Integrated Digital Enhanced Network), iBurst, Unlicensed Mobile Access (UMA, also referred to as also referred to as 3GPP Generic Access Network, or GAN standard)), Wireless Gigabit Alliance (WiGig) standard, mmWave standards in general (wireless systems operating at <NUM>-<NUM> and above such as WiGig, IEEE <NUM>. 11ad, IEEE <NUM>. 11ay, etc.), etc. The examples provided herein are thus understood as being applicable to various other mobile communication technologies, both existing and not yet formulated.

The bus <NUM> may couple the processor <NUM> to a camera interface <NUM> for controlling a camera <NUM>. The camera <NUM> may be a still image camera, a video camera, a high-definition video camera, or an infrared camera, among others. Other devices and sensors may be used in addition to, or instead of the camera, such as particulate sensors, gas sensors, hyperspectral cameras, and the like.

The slave device <NUM> may include a 3D accelerometer <NUM> to measure flight characteristics, such as motion relative to the gravity field. The 3D accelerometer may be a microelectromechanical systems (MEMS) available in the iSensor MEMS accelerometer subsytems line from Analog Devices Inc. of Norwood, Massachusetts, for example, under the ADXLxxx part number.

A 3D gyroscope <NUM> may be included to measure roll of the slave device <NUM> about each of the axis. The 3D gyroscope may also be a MEMS sensor available in the iSensor MEMS 3D gyroscope subsytems line from Analog Devices, for example, in the ADISxxxx series.

The 3D accelerometer <NUM> and the 3D gyroscope <NUM> may be combined in, or used together as, an inertial measurement unit (IMU). A single IMU for example, available from Analog Devices in the iSensor MEMS IMU line of devices, for example, in the ADISxxxxx series. The IMU monitors flight characteristics and stability, and provides data that allows the processor <NUM> to adjust flight parameters to maintain stable, level flight. The IMU may include a number of other sensors, such as pressure sensors that may measure altitude, and magnetometers to measure orientation relative to the magnetic poles.

A GPS/Compass interface <NUM> may be included to interface to a GPS receiver <NUM> for obtaining position signals. The GPS/compass interface <NUM> and the GPS receiver <NUM> may be considered to be a single unit termed a GPS system herein. Further, the GPS system may or may not include the compass functionality, which may, instead, be incorporated into an IMU. The compass, if included, may be a magnetometer that provide the orientation of the unit with respect to the magnetic poles. The GPS receiver <NUM> may include units made by OriginGPS, and available from Future Electronics of Quebec, Canada, for example, under the Hornet or Spider series, among others. The position signals may be used by the slave device <NUM> to calculate a delta position form the GPS waypoint established by a master drone.

In some examples, a slave device <NUM> may not include the GPS/compass interface <NUM> or GPS receiver <NUM>. In these examples, the slave device <NUM> may calculate a position relative to other devices by timing of transmission determined using a phase array antenna, or other techniques, such as time-of-flight calculations.

The bus <NUM> may couple the processor <NUM> to one or more electronic speed control (ESC) <NUM> to control the propulsion systems <NUM>. The propulsion systems <NUM> may include any number of different units for moving the slave device <NUM> through the environment. In some examples, as described herein, the slave device <NUM> may be a UAV, and the propulsion systems <NUM> may include brushless DC motors coupled to propellers.

A battery <NUM> may power the slave device <NUM>, although in examples in which the slave device <NUM> is mounted in a fixed location, it may have a power supply coupled to an electrical grid. The battery <NUM> may be a lithium ion battery, a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium- air battery, and the like.

A battery monitor / charger <NUM> may be included in the slave device <NUM> to track the state of charge (SoCh) of the battery <NUM>. The battery monitor / charger <NUM> may be used to monitor other parameters of the battery <NUM> to provide failure predictions, such as the state of health (SoH) and the state of function (SoF) of the battery <NUM>. The battery monitor / charger <NUM> may include a battery monitoring integrated circuit, such as an LTC4020 or an LTC2990 from Linear Technologies, an ADT7488A from ON Semiconductor of Phoenix Arizona, or an IC from the UCD90xxx family from Texas Instruments of Dallas, TX. The battery monitor / charger <NUM> may communicate the information on the battery <NUM> to the processor <NUM> over the bus <NUM>. The battery monitor / charger <NUM> may also include an analog-to-digital (ADC) convertor that allows the processor <NUM> to directly monitor the voltage of the battery <NUM>, or, with appropriate circuitry, the current flow from the battery <NUM>. The battery monitor / charger <NUM> may include a temperature monitor circuit to determine the temperature in the proximity of the battery <NUM>.

A power receiver <NUM> may be coupled with the battery monitor / charger <NUM> to charge the battery <NUM>, for example, from a secondary master device as described with respect to <FIG>. The power receiver <NUM> may receive the power wirelessly, for example, through a loop antenna in the slave device <NUM>, or may receive the power through a physical connection to the battery monitor / charger <NUM>, for example, through a cable. A battery charging circuit, such as an LTC4020 chip from Linear Technologies of Milpitas, CA, among others, may be included in the battery monitor / charger <NUM>. The specific charging circuits chosen depend on the size of the battery <NUM>, and thus, the current required.

The mass storage <NUM> may store a number of code modules to implement the techniques, although in some examples, some or all of these functions may be implemented by hardware. The code modules may include an inter-drone communicator <NUM> to identify and communicate with adjacent drones. The inter-drone communicator <NUM> may implement the shortened packet system for communications described with respect to <FIG>.

A node validator <NUM> may determine whether other devices in communication with the slave device <NUM> are operational or are starting to fail, as described with respect to <FIG>. The node validator <NUM> may keep a list of valid nodes, or may provide the information to another device, such as a master device.

A data store <NUM> may be implemented in the mass storage <NUM>, instead of or in addition to, the system memory <NUM> to temporarily hold data from the slave device <NUM>, and other swarm devices <NUM>. The data store <NUM> may be maintained by the inter-drone communicator <NUM>, and may be implemented as a circular buffer, a first-in-first-out (LIFO), or other structure. In some examples, the buffer structure used may be modified to accommodate different priorities of data.

A position calculator <NUM> may be used to determine the delta position from the GPS waypoint of a master device. This may be performed using data from the GPS receiver <NUM>, or from signals received from other swarm devices <NUM> on a phased array of antennas coupled to the swarm radio transceiver <NUM>, among others.

A movement controller <NUM> may calculate adjustments to the propulsion systems <NUM> needed to move the slave device <NUM> to a target location. The movements may be based on a target location range, or cube in 3D space, determined from the delta position from a master device and a preset target separation. The movement controller <NUM> may also adjust the targeting location of the camera <NUM>, for example, adjusting pan, tilt, and zoom controls to keep the camera pointed at a predetermined target. The movement controller <NUM> may inform the other swarm devices <NUM> if a deviation from the target location is needed to keep the target in the predetermined view.

A fault controller <NUM> may predict failures, such as battery out, communication faults, and other issues with the slave device <NUM>. If a failure is identified as exceeding a probability limit, the fault controller <NUM> may take over the operation of the slave device <NUM>. For example, the fault controller <NUM> may instruct the movement controller <NUM> to land the slave device <NUM>, or otherwise move it to a point of minimum risk, such as the surface of a body of water. The fault controller <NUM> may also control charging of the slave device <NUM>, for example, locating a secondary master device, and instructing the movement controller <NUM> to move the slave device <NUM> proximate to the secondary master device for charging. The fault controller <NUM> in the slave device <NUM> may also be used to control neighboring nodes identified as not valid, for example, due to faults in communications or operations. The fault controller <NUM> may communicate the loss to other devices, and if at least one other device concurs, the fault controller <NUM> may instruct the neighboring node to exit the network, for example, by landing and powering down, communicating with a charging device for a battery charge, and the like.

Not every component shown in <FIG> is used in every example. As described herein, the slave device <NUM> may not have a GPS system, such as a GPS/Compass interface <NUM> and GPS receiver <NUM>. Further, some slave devices <NUM> in a swarm network may have GPS systems, while others do not. In some examples, the GPS system is present, but is powered down. In these examples, the GPS system may be powered up intermittently to obtain a position confirmation, or may be powered up to allow the slave device <NUM> to replace a master device in case of a device failure. Similarly, other components may be present in a slave device <NUM>. For example, an uplink radio transceiver, as described with respect to <FIG> may be present. As for the GPS system, the uplink transceiver may be powered down until a master device failure, at which point, the slave device <NUM> may power the uplink transceiver and take over for the failed master drone.

<FIG> is a block diagram of components that may be present in an example of a master device <NUM> that may be used in a swarm network. Like numbered items may be selected as described with respect to <FIG>. It can be understood that not every device is limited to the same components. The master device <NUM> may include any combinations of the components shown in the example and described with respect to <FIG>. The components may be implemented as ICs, portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof adapted in the master device <NUM>, or as components otherwise incorporated within a chassis of a larger system. The block diagram of <FIG> is intended to show a high level view of components of the master device <NUM>. However, some of the components shown may be omitted, additional components may be present, and different arrangement of the components shown may occur in other implementations.

The master device <NUM> may include a separate uplink radio transceiver <NUM> used for communicating with cloud devices <NUM>, such as a control system or a broadcast system. The uplink radio transceiver <NUM> may include a satellite uplink, a cellular phone link, a LSA/SAS spread spectrum link, or any number of other radio network links. Further, the uplink radio transceiver <NUM> may include multiple transceivers, for example, for saving power during communications in certain modes or to maintain communications in difficult terrain or during infrastructure failures. In some examples, the nodes are fixed in place, in which case, the uplink radio transceiver <NUM> may be replaced with, or supplemented with, a network interface controller (NIC) for implementing an Ethernet link.

The mass storage <NUM> may include a number of code modules to implement the functions of the master device <NUM>. These modules may include modules similar to those in the slave device <NUM>, but may include extra functionality for the master device <NUM>. For example, the master device <NUM> may include an inter-drone communicator <NUM> similar to the inter-drone communicator <NUM> described with respect to <FIG>. The inter-drone communicator <NUM> may implement the shortened packet system for communications described with respect to <FIG>.

A swarm controller <NUM> may be included to accept commands for the swarm of devices. For example, for a drone implementation, the swarm controller <NUM> may instruct the drones to take off and deploy once the network is established. The swarm controller <NUM> may also instruct slave devices to maintain a position with respect to the master device <NUM>, move to a new position with respect to the master device <NUM>, and collect data, such as video, images, and sensor readings, among others. The swarm controller <NUM> may be provided with instructions identifying the target, and pass on relevant instructions to slave devices concerning target identification, video collection angles, and the like.

A node validator <NUM> may perform a similar function to the node validator <NUM> in the slave devices. However, the node validator <NUM> may include a bootstrap function to allow the master device <NUM> to validate nodes before two devices have been validated. In the bootstrap function, the master device <NUM> may then be validated by two other devices before a final acceptance of the network operations is sent to a control computer. The node validator <NUM> in the master device <NUM> may maintain a list of valid nodes.

An uplink communicator <NUM> may provide communication functionality to a cloud device <NUM> through the uplink radio transceiver <NUM>. The uplink communicator <NUM> may select from a number of radio transceivers to lower power demand, maintain communications in difficult terrain, or increase bandwidth to a cloud device <NUM> when needed, such as during the collection of HD video, and the like. For example, if the communications are currently being conducted over a cellular communications link, such as an LTE link, communications may be lost if the swarm follows the target into a valley. The uplink communicator <NUM> may identify the communications difficulties, and switch to another transceiver, such as a satellite uplink. If the new communications link is not capable of maintaining a sufficiently high bandwidth for the current communications, the uplink communicator <NUM> may degrade the bandwidth of the feed, such as lowering a full high-definition video signal (1080p) to a lower bandwidth, such as a 1080i feed, a 720p feed, a 720i feed, or lower. The uplink communicator <NUM> may then sense when the higher bandwidth link is available, resume communications with the higher bandwidth link, and restore the full bandwidth of the feed.

A movement controller <NUM> may perform similar functions to the movement controller <NUM> in the slave device. However, in the master device <NUM> the movement may be based on a full GPS location obtained from the GPS receiver <NUM>. The master device <NUM> may accept the target and movement input from the cloud device <NUM>, including a predetermined distance to the target, among other factors. The movement controller <NUM> may establish the GPS waypoint, which can be sent by the inter-drone communicator <NUM> to slave devices.

A fault controller <NUM> may implement similar functions to the fault controller <NUM> of the slave devices. Thus, the fault controller <NUM> may predict failures, such as battery out, communication faults, and other issues with the master device <NUM>. If a failure is identified as exceeding a probability limit, the fault controller <NUM> may take over the operation of the master device <NUM>. For example, the fault controller <NUM> may instruct the swarm network to appoint a new master device <NUM>, for example, by having a slave device <NUM> activate a GPS system and uplink radio communications, or by having a secondary master device take over operations, or both. The fault controller <NUM> may then instruct the movement controller <NUM> to land the master device <NUM>, or otherwise move it to a point of minimum risk, such as the surface of a body of water. The fault controller <NUM> may also control charging of the master device <NUM>, for example, locating a secondary master device, and instructing the movement controller <NUM> to move the master device <NUM> proximate to the secondary master device for charging.

The fault controller <NUM> in the master device <NUM> may also be used to control devices, or nodes, identified as not valid, for example, due to faults in communications or operations. The fault controller <NUM> may communicate the loss to other devices, and if at least one other device concurs, the fault controller <NUM> may instruct the invalid node to exit the network, for example, by landing and powering down, communicating with a charging device for a battery charge, and the like.

<FIG> is a block diagram of components that may be present in an example of a secondary master device <NUM> that may be used in a swarm network. The secondary master device <NUM> may be present in the swarm network to provide a charging function for devices that are failing due to low battery levels. However, the secondary master device <NUM> may also function as a master device <NUM>, for example, if the master device <NUM> fails. Like numbered items may be selected as described with respect to <FIG> and <FIG>. It can be understood that not every device is limited to the same components. The secondary master device <NUM> may include any combinations of the components shown in the example and described with respect to <FIG> and <FIG>. The components may be implemented as ICs, portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof adapted in the secondary master device <NUM>, or as components otherwise incorporated within a chassis of a larger system. The block diagram of <FIG> is intended to show a high level view of components of the secondary master device <NUM>. However, some of the components shown may be omitted, additional components may be present, and different arrangement of the components shown may occur in other implementations.

The secondary master device <NUM> may include a power source <NUM> capable of providing power for high demand applications, such as charging batteries in other drones. The power source <NUM> may be a high capacity battery, or another type of source, such as a power generator. For example, the power source <NUM> may be a fuel cell, a microturbine generator, or other power unit. Accordingly, the secondary master device <NUM> may be larger than the other devices to carry the additional weight and fuel associated with the power source <NUM>.

Further, the secondary master device <NUM> may be stationary, or mounted to a moving platform, such as a landing platform mounted to a control vehicle. The control vehicle may then provide the power source <NUM>, for example, from an engine alternator or from a separate generator. In this example, the secondary master device <NUM> may not include the devices used to provide and control stable flight, such as the 3D accelerometers <NUM>, the 3D gyroscopes <NUM>, the electronic speed control <NUM> or the propulsion systems <NUM>. The secondary master device <NUM> may still be able to function as a master device <NUM> for the swarm, for example, if the master device <NUM> fails, so a GPS system may be included to provide a GPS waypoint as a basepoint for the swarm.

A battery monitor / charger <NUM> may be included to monitor the status of the power source <NUM> and to provide power to a power transmitter <NUM> for charging other devices. The power transmitter <NUM> may provide power to a device <NUM> with a low battery level, for example, by inductive coupling or through physical contacts. The battery monitor / charger <NUM> may alert the processor <NUM> when a device <NUM> is within charging range. In some examples, the processor <NUM> may instruct the battery monitor / charger <NUM> to start the charging, while in other examples, the charging may be automatically started. The charging may be performed using the Airfuel standard promulgated by the Airfuel Alliance, the Qi wireless charging standard promulgated by the Wireless Power Consortium, the Rezence charging standard, promulgated by the Alliance for Wireless Power, among others. Further, the charging may be provided by a cable that is automatically connected to the device <NUM>.

The mass storage <NUM> may include a number of code modules to implement the functions of the secondary master device <NUM>. These modules may include modules similar to those in the slave device <NUM>, but may include extra functionality for the secondary master device <NUM>. Further, the modules may perform functions similar to those of the master device <NUM>. For example, the secondary master device <NUM> may include an inter-drone communicator <NUM> similar to the inter-drone communicator <NUM> described with respect to <FIG>. The secondary master device <NUM> may also include a node validator <NUM> and a position calculator <NUM> similar to other master devices <NUM>.

A movement controller <NUM> may be included to control movements of the secondary master device <NUM>, devices <NUM> needing charging, or both. For example, when a device <NUM> needs to be charged, the movement controller <NUM> may land the secondary master device <NUM>, and then instruct the device <NUM> that needs charging to land near or on the secondary master device <NUM>. The secondary master device <NUM> may then initiate charging by coupling a cable to the device <NUM> or by sending power through a wireless power transmitter. The movement controller <NUM> may be included even if the secondary master device <NUM> is stationary. In this example, the movement controller <NUM> may control the movements of the device <NUM> needing to be charged. The movement controller <NUM> may direct the device needing to be charged to land on or near the secondary master device <NUM>. In some examples, the secondary master device <NUM> may charge the device <NUM> without either device <NUM> or <NUM> landing. In this examples, the devices <NUM> and <NUM> may move proximate to each other, allowing either a cable to be connected between the devices <NUM> and <NUM>, or a wireless power transmission to be implemented.

A fault controller <NUM> may implement similar functions to the fault controller <NUM> of the other devices. Thus, the fault controller <NUM> may predict failures, such as battery out, communication faults, and other issues with the secondary master device <NUM>. If a failure is identified as exceeding a probability limit, the fault controller <NUM> may take over the operation of the secondary master device <NUM>. For example, the fault controller <NUM> may instruct the swarm network that the secondary master device <NUM> is no longer operational, and further faults in devices may be handled by landing the devices and alerting the operators. The fault controller <NUM> may then instruct the movement controller <NUM> to land the secondary master device <NUM>, or otherwise move it to a point of minimum risk, such as the surface of a body of water. The fault controller <NUM> may also control charging of the secondary master device <NUM>, for example, locating another secondary master device <NUM>, and instructing the movement controller <NUM> to move the secondary master device <NUM> proximate to the other device for charging.

The fault controller <NUM> in the secondary master device <NUM> may also be used to control devices, or nodes, identified as not valid, for example, due to faults in communications or operations. The fault controller <NUM> may communicate the loss to other devices, and if at least one other device concurs, the fault controller <NUM> may instruct the invalid node to exit the network, for example, by landing and powering down, rendezvous with the secondary master device <NUM> for a battery charge, and the like.

A charge controller <NUM> may handle charging operations once the devices <NUM> and <NUM> are in range. The charge controller <NUM> may initiate the charging by connecting a cable or starting power flow to the power transmitter <NUM>. The charge controller <NUM> may also keep track of which swarm devices <NUM> have been charged, and how long each has run since a last charge. Further, the charge controller <NUM> may request battery status from the battery monitor / charger <NUM> of each of the swarm devices to track which devices may be serviced next.

The charge controller <NUM> may be used to implement a rotating charging schedule to decrease the chance that a number of devices may need a charge at the same time. For example, if no device is currently being charged, the charge controller <NUM> may instruct devices to come in for "topping off" the charge on a rotating schedule, based on the amount of power left in each device. If a device needs a charge while a device that is being topped off is already being charged, the charge controller <NUM> may release the current device to return to the swarm, freeing the space for the device that needs to be charged.

<FIG> is a process flow diagram of an example of a method <NUM> for managing the operation of a mobile swarm network by a master drone. The method <NUM> begins at block <NUM>, when the drones are powered. At block <NUM>, communications are established between the base and the master drone. As used herein, the base includes any device in the cloud that is configured to provide instructions to, or take data from, the swarm network. The base may include a local control device, for example, in a field or race application, a remote device, such as a broadcast station or emergency management center, or both. If communications are not confirmed at block <NUM>, process flow returns to block <NUM> to continue to try to establish the communications.

At block <NUM>, communications are established with other drones, such as the slave drones and secondary master drones described herein, among others. The establishment of communications may include validating the nodes, as described with respect to <FIG>. The validation may be bootstrapped by allowing the master drone to certify other drones before it is in turn validated by two other valid drones.

At block <NUM>, the master drone accepts a command sent by the base. This may include returning an acknowledgement of the command. At block <NUM>, a determination is made as to whether the command is a motion command, such as, for example, tracking a target, moving to a new target region, return to home, and the like. If so, at block <NUM>, the master drone may implement the motion command. At block <NUM>, while moving to the new position, the master drone may propagate the position to other drones in the swarm.

If, at block <NUM>, the command is determined not to involve motion, at least for the master drone, the command is propagated to other drones in the swarm, for example, being communicated to the nearest drones, and then being passed along to the next farther drones, until the command reaches all of the drones in the swarm. The command may include, for example, adjustments to the relative positions of drones, initiation or termination of data collection, initiation or termination of rotational charging of the drones, and the like.

At block <NUM>, the master drone collects data from sensors, if instructed by the command. Other data collected may include the status or health of the master drone, and the like.

At block <NUM>, the master drone accepts data from other drones in the swarm. The data may include data on the status, health, and position of drones in the swarm or acknowledgement of commands. Further, the data may include sensor feeds, such as camera images, video feeds, or other sensor readings.

At block <NUM>, the master drone returns the data collected, and the data from other drones to the base through the uplink. Not all of the data collected may be returned. For example, data relative to local control issues, such as the position of the drones in the swarm, may be used internally by the swarm itself to control locations. Further, health and status data may not be returned unless it is requested or it impacts the total functionality of the swarm. For example, if a drone is forced to land along a race route, without being charged, the last known location of the drone may be returned by other drones in the swarm for facilitating recovery.

Process flow then returns to block <NUM> to confirm communications with the base. If communications with the base are lost during operation, the swarm may follow any number of actions. For example, the swarm may continue to collect data for a predetermined period of time, then automatically land to await the restoration of communications.

<FIG> is a process flow diagram of an example of a method <NUM> for participating in the operation of a mobile swarm network by a slave drone. The method <NUM> begins at block <NUM>, when the drones are powered. At block <NUM>, communications are established with the master drone. If communications are not confirmed at block <NUM>, process flow returns to block <NUM> to continue to try to establish the communications with the master drone.

At block <NUM>, communications are established with other drones, such as the slave drones and secondary master drones described herein, among others. The establishment of communications may include validating the nodes, as described with respect to <FIG>. The validation may be accepted by other drones only if it is coming from a valid drone, for example, a slave drone that has, itself, been validated by two other valid drones.

At block <NUM>, the slave drone accepts a command sent by the master drone. This may involve receiving the command from another slave drone, as it is communicated through the drone networks. Further, the slave drone may return an acknowledgement of the command. For example, a positional or operational command may be acknowledged, while a less important command is not. At block <NUM>, a determination is made as to whether the command is a motion command, including, for example, tracking a target, moving to a new target region, return to home, and so one. If so, at block <NUM>, the slave drone may calculate a new target position based on the location of and separation between the slave drone and other drones. At block <NUM>, the slave drone may move to the new position and let other drones know the new location of the slave drone.

If, at block <NUM>, the command is determined not to involve motion, the command is propagated to other drones in the swarm, for example, being communicated to the nearest drones, the being passed along to the next drones, until the command reaches all of the drones in the swarm. Further, at block <NUM>, data is collected for the command as needed, for example, from the sensor readings. The command may include, for example, adjustments to the relative positions of drones, initiation or termination of data collection, initiation or termination of rotational charging of the drones, and the like.

At block <NUM>, the slave drone sends its data to adjacent drones for propagation back to the master drone. The data may include data on the status, health, and position of drones in the swarm or acknowledgement of commands. Further, the data may include sensor feeds, such as camera images, video feeds, or other sensor readings. At block <NUM>, the slave drone accepts data from other drones in the swarm that are farther from the master drone, and passes that data on to adjacent drones in that are closer to the master drone. From the adjacent drones, the data, along with the adjacent drones' data, is propagated to the nearest neighboring drones that are closer to the master drone. Not all of the data collected may be returned to the master drone. For example, data relative to local control issues, such as the position of the slave drone relative to other drones in the swarm, may be used internally by the slave drone itself to control its location. Further, health and status data may not be returned unless it is requested or it impacts the total functionality of the swarm. For example, if a slave drone is forced to land along a race route, without being charged, the last known location of the drone may be returned by other drones in the swarm for facilitating recovery.

From block <NUM>, process flow returns to block <NUM> to confirm communications with the master drone. If communications with the master drone has failed, the slave drone may perform a number of different actions. For example, the slave drone may confirm other drones, nodes, are valid and in communications, if not, the slave drone may execute an automated landing and power down.

<FIG> is a block diagram of a non-transitory, machine-readable medium <NUM> including instructions, which when executed, direct a processor <NUM> to control a slave drone in a swarm network. The processor <NUM> can access the non-transitory, machine-readable medium <NUM> over a bus <NUM>, such as described with respect to <FIG>. The processor <NUM> may be as described with respect to <FIG>. The non-transitory, machine-readable medium <NUM> may include code <NUM> to direct the processor <NUM> to initiate communications with and validate other nodes, for example, as described with respect to <FIG>. The non-transitory, machine-readable medium <NUM> may include code <NUM> to direct the processor <NUM> to initiate calculate a position relative to other drones, for example, as described with respect to <FIG>. Code <NUM> may be included to direct the processor <NUM> to move to the new location. The non-transitory, machine-readable medium <NUM> may include code <NUM> to direct the processor <NUM> to collect data, for example, locking a camera on a target and initiating the streaming of video to memory. non-transitory, machine-readable medium <NUM> may include code <NUM> to direct the processor <NUM> to communicate the data to adjacent nodes that are closer to the master drone, for example, as described with respect to <FIG>. The communication may use the limited packet structure described with respect to <FIG> to improve communications.

The non-transitory, machine-readable medium <NUM> may include code <NUM> to direct the processor <NUM> to determine a probability of failure, such as a battery failure, communications failure, and the like. The code <NUM> may direct the processor <NUM> to locate and communicate with a secondary master device for charging. The non-transitory, machine-readable medium <NUM> may include code <NUM> to direct the processor <NUM> to automatically land the slave drone, for example, proximate to a secondary master device for charging or in any safe location for other faults.

<FIG> is a block diagram of a non-transitory, machine-readable medium <NUM> including instructions, which when executed, direct a processor <NUM> to control a master drone in a swarm. The processor <NUM> can access the non-transitory, machine-readable medium <NUM> over a bus <NUM>, such as described with respect to <FIG>. The processor <NUM> may be as described with respect to <FIG>. The non-transitory, machine-readable medium <NUM> may include code <NUM> to direct the processor <NUM> to initiate communications with and validate other nodes. Code <NUM> may be included to direct the processor <NUM> to move the drone to a new location, for example, based on the location of the target, instructions from the base, and a GPS signal. The new position may be propagated to the other drones. The non-transitory, machine-readable medium <NUM> may include code <NUM> to direct the processor <NUM> to collect data, for example, locking a camera on a target and initiating the streaming of video to the base through an uplink. The non-transitory, machine-readable medium <NUM> may include code <NUM> to direct the processor <NUM> to communicate with adjacent nodes in the network receiving data and propagating commands. The communication may use the limited packet structure described with respect to <FIG> to improve communications. The non-transitory, machine-readable medium <NUM> may include code <NUM> to direct the processor <NUM> to transfer data received from other drones to the base through the uplink.

The non-transitory, machine-readable medium <NUM> may include code <NUM> to direct the processor <NUM> to determine a probability of failure, such as a battery failure, communications failure, and the like. The code <NUM> may direct the processor <NUM> to trigger a slave drone to activate systems to become a master drone, then to locate and communicate with a secondary master device for charging. Further, the code <NUM> may track the functionality of other drone devices in the network, and issue commands for landing and shutdown if a probability of failure is above a present limit. The non-transitory, machine-readable medium <NUM> may include code <NUM> to direct the processor <NUM> to automatically land the master drone, for example, proximate to a secondary master device for charging or in any safe location for other faults.

Claim 1:
An internet-of-things, loT, device (<NUM>, <NUM>) in a mesh network (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>), comprising an internet-of-things, loT, mesh network device (<NUM>, <NUM>, <NUM>), the loT device comprising:
a radio transceiver (<NUM>) configured to communicate with other devices (<NUM>, <NUM>) in the mesh network (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>);
a node validator (<NUM>, <NUM>) configured to determine if a device (<NUM>, <NUM>) of the other devices (<NUM>, <NUM>) in the mesh network (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) is invalid, wherein determining the device (<NUM>, <NUM>) as invalid comprises:
sending a trigger to a target node (<NUM>, <NUM>) to return test data;
analyzing the test data received from the target node (<NUM>, <NUM>);
if the test data is outside of the expected parameters:
communicating the results to a second node;
sending a trigger from the second node to the target node (<NUM>, <NUM>);
analyzing the test data received at the second node from the target node (<NUM>, <NUM>); and
classifying the target node (<NUM>) as invalid device if the test data received at the
second node is outside of expected parameters; and
a fault controller (<NUM>, <NUM>, <NUM>) configured to take over the operation of the invalid device and/or to instruct the invalid device (<NUM>, <NUM>) to exit the mesh network (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>).