Method and system for controlling a network for power beam transmission

[0001] The present invention is directed to a method and system for controlling a network for power beam transmission, and more particularly to a system architecture for controlling beam power between multiple source nodes and user nodes.

[0002] Aircraft combustion engines that burn hydrocarbon fuels are limited in their flight altitude because at high altitudes, there is insufficient oxygen to sustain combustion. Aircraft that operate on combustion engines are also limited in the total time and distance that can be achieved between landings, due to the weight and quantity of fuel that they must transport. Aircraft that do not rely on combustion engines can achieve higher flight altitude, as well as longer flight times, than aircraft that rely on combustion engines. Some high-altitude airplanes have been powered by solar power, but sunlight has low intensity under the best circumstances and is unavailable at night. For example, the HELIOS Prototype is a solar powered aircraft developed by NASA and AeroVironment Inc., of California, as part of the Environmental Research Aircraft and Sensor Technology (ERAST) program. However, limitations have been encountered with the operation of HELIOS and other solar-powered aircraft.

[0003] Solar intensity is especially low during winter months in higher latitudes. The transmission of power beams, or “power beaming”, is one solution that was developed to alleviate the problem of low-intensity regions of solar power. The concept of power beaming goes back at least as far as the famous scientist Nikola Tesla (1856-1943). There is a large body of literature regarding power beaming, which is also referred to at times as “wireless power transmission.” Power beaming includes a set of technologies that transmit large, non-destructive amounts of power from some source to some receiver via electromagnetic waves, e.g. microwaves or light. Power beaming can provide the equivalent energy levels of high-intensity sunlight with nearly 100% duty cycle.

[0004] Power beaming has been used to demonstrate the feasibility of use in small aircraft. However, power beaming from a single beam power source to a single user node such as a small aircraft, has limited usefulness. The user node is constrained to flight within the direct line-of-sight of the source node, and the reliability of the user node or aircraft is dependent on the reliability of the power source or source node. Singular source nodes do not have the ability to handoff user nodes from one source to the next to improve flight reliability of the user aircraft node, and to enable a user aircraft node to receive sufficient power to sustain flights of long-distance or long-duration.

[0005] A single source may be configured with power beam characteristics that are incompatible with a particular aircraft—e.g., the power beam may be too powerful or too weak. Since there is not a uniform standard for power beaming, interoperability becomes difficult, reducing the value of each type of aircraft and each type of source node.

[0006] Current ground-based power beam source nodes encounter additional obstacles to power transmission. Atmospheric obstacles such as clouds or turbulence interfere with the power transmissions by scattering light. Since some user nodes receive the power via arrays of photovoltaic cells that are limited in area, much of the transmitted power becomes unfocused due to such spreading and is lost.

[0007] Maintaining airborne surveillance is another challenge that cannot be effectively achieved using combustion propulsion, as political and military factors reduce airborne intelligence, surveillance and reconnaissance (ISR) below 100 thousand feet. Higher altitude surveillance is desirable because of the ability to acquire a larger visible area ratio as the altitude of the surveillance aircraft increases. Strong winds at extreme altitudes cause conventional airships to consume a prohibitive amount of power just for holding the airship in a fixed position, thus making fixed wing aircraft more desirable.

[0008] Providing for the needs and capabilities of multiple user nodes, source nodes, and relays to create a distributed power beaming system is a complex undertaking. Such a system is unable to function properly without interoperability and the ability to represent various attributes and interactions between the nodes of the power-beaming network.

[0009] Applying Network Centric Operations (NCO) concepts and expertise to directed energy weapons and power beaming, the present invention addresses a need to make directed energy platforms more network-compatible.

[0010] There is a need for a power beaming network architecture to enable each beam-powered aircraft to be served by one or more power beams in various locations to accomplish high-altitude flights of extreme duration. There is also a need for a distributed network of power beaming source nodes to allow the source nodes to be built in smaller sizes in order to reduce the cost per unit of power.

[0011] The present invention is directed to a system power beam transmission system. The system includes a plurality of source nodes. Each source node is configured to generate a power beam usable by at least one user node. A control system controls operation of the source nodes, one or more user nodes and a communication system. The communication system transmits signals between the plurality of source nodes and the user node or nodes. The user nodes are configured to transmit messages via the communication system to at least one source node. The user node messages include one or more of a set of operative parameters, a power beam service request; and at least one acceptance message. The acceptance message is sent in response to at least one offer from one of the source nodes. Each source node is configured to transmit, upon receipt of a user node message, an offer to provide power beam service in response to the power beam service request. The offer to power beam service commits the source node to provide a power beam service corresponding to the set of operative parameters of the user node or nodes. The source node delivers a power beam to the user node or nodes in response to receiving an acceptance message or messages from the user node or nodes.

[0012] In another aspect, the present invention is also directed to a user node for receiving transmissions of power beams from a network of power beam source nodes including an airborne vehicle. The airborne vehicle is configured to communicate via a communication system a preferably predetermined set of operative parameters; broadcast a request for power service from a user node to at least one source node of a plurality of source nodes in the network; and communicate at least one acceptance message in response to at least one offer from one of the plurality of source node.

[0013] The present invention is also directed to a method of controlling power transmission of power beams from a plurality of power beam source nodes to one or more airborne vehicles or nodes. The method includes the following steps: providing a plurality of source nodes, a control system for configuring the plurality of source nodes and at least one user node, and a communication system for transmitting signals between the plurality of source nodes and the at least one user node, wherein each user node is configured to communicate via the communication system a preferably predetermined set of parameters; broadcasting a request for power service from a user node to at least one source node of the plurality of source nodes; determining a set of operative parameters of a requesting user node in response to a need for power; transmitting at least one offer to provide power service from at least one source node of the plurality of source nodes in response to the broadcast request for power service, wherein the offer commits the at least one source node to provide a power beam service corresponding to the set of operative parameters of the requesting user node; communicating from the requesting user node at least one acceptance message in response to the at least one offer; and delivering a power beam of the at least one source node in response to the at least one acceptance message.

[0014] The method also includes communicating a set of power beam parameters and a set of physical parameters associated with each source node of the plurality of source nodes, and communicating a set of user parameters from at least one user node.

[0015] The present invention will enable aircraft to fly higher, e.g. in the “near space” range from 20 km to 100 km altitude, and for longer durations, e.g. over 30 days at a time, while carrying heavy, power-hungry payloads such as AMTI and GMTI radars.

[0016] An advantage of the present invention is that mobile user nodes may rely on multiple beam sources for power, rather than limiting their dependence to a single beam source.

[0017] Another advantage of the present invention is that range of travel of a mobile user node is increased beyond the range of a single beam source by enabling handoffs between multiple source nodes.

[0018] A further advantage of the present invention is increased reliability and availability by having multiple sources of power.

[0019] Yet another advantage of the present invention is that the unit size of individual beam sources in the network can be decreased, which decreases overall cost per unit of power, and decreases the logistical burden.

[0020] Still another advantage of the present invention is increased range and reliability by the inclusion of relays in the architecture to provide pathways around airborne obstacles.

[0021] Another advantage of the present invention is the generality of the architecture and its interoperability, e.g., a source node may support multiple types of user nodes that it was not specifically designed to support, and a user node may use power from a variety of source nodes.

[0022] Finally, the use of an infosphere for communication within the architecture reduces communication traffic, software integration complexity, and software development for system management.

[0023] Other features and advantages of the present invention will be apparent from the following more detailed description of the preferred embodiment, taken in conjunction with the accompanying drawings which illustrate, by way of example, the principles of the invention.

[0027] Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

[0028] Referring to FIG. 1, an exemplary system of the present invention has a plurality of source nodes 12, 14, 16, 18, 20 & 22. Source nodes 12-22 include fixed nodes 12, 14, 16 & 18 and mobile nodes 20 & 22, and combinations thereof. The system also has beam-powered user nodes 24, 26, 28, 30, 32, 34 & 36 and communication systems (not shown) for each beam-powered user node 24-34 to request power from a plurality of source nodes 12-22. The user node 24-34 specifies a set of preferably predetermined parameters, including, e.g., an acceptable time interval, and acceptable parameters relative to the power beam, e.g., the wavelength of a power beam that the user node may receive, the pulse rate of the power beam, a duty cycle, engagement geometry, size of beam, etc. The system also includes one or more relays 56 for directing power beams around airborne obstructions 38.

[0029] Each source node 12-22 is configured to specify its power delivery capability, e.g., the wavelength of its power beam, the pulse rate of delivery, a duty cycle, a field of regard, a beam angle, etc., as well as the available capacity of the source node 12-22. The system has the ability to assign source nodes 12-22 and relays 56, from a plurality of source nodes 12-22 and relays 56, to satisfy the service requests of user nodes 24-34. The system may assign multiple source nodes 12-22 to individual user nodes 24-34, and configure a source node 12-22 to time-share the power beam of the source node 12-22 among multiple user nodes 24-34. The system also is configured to optimize power beam assignments, by taking into account atmospheric conditions that present obstacles between source nodes 12-22 and user nodes 24-34. Obstacles include such atmospheric conditions as clouds 38, smoke, or turbulent regions. The system configuration preferably includes a method to deconflict airspace to prevent power beams from damaging vehicles or persons. There is also provided a verification means to verify that a scheduled connection between source nodes and user nodes has been successfully established, and to make new node assignments if a scheduled connection fails. The system also has the ability to transfer each user node to new source nodes or relays when the user node or source node moves out of range for power transfer, or, for example, a power failure of the source node occurs, or the user node revises its power requirements up or down.

[0030] Referring again to FIG. 1, Source node 14 has a first beam 42, and a second beam 44. The second beam 44 is been illuminating a fast-moving user node, 26. At the moment shown, source node 14 is executing a beam transmission pursuant to commitment to node 26, and the commitment is expiring. Source node 16 is just beginning a new commitment to node 26, so the beam 44 from source node 14 is ending and the beam 46 from source node 16 is starting.

[0031] Source node 18 is transmitting a power beam 48 to relay 56 via a microwave beam 48 that goes through a cloud obstacle 38. Relay 56 has a single outgoing beam 50, 52, which it time-shares between two user nodes, user node 28, and user node 30. User node 28 requires more power than user node 30, and therefore receives about twice as much beam time as user node 30, the differences in beam power levels indicated by longer dashes in the arrow 50 to user node 28.

[0032] Source node 22 is a mobile, sea-going node. Source node 20 is an airborne mobile source node. Mobile source node 20 has two outgoing beams 58, 60. Beam 60 goes to airborne user node 32. Another beam 58 from source node 20 is transmitted to an orbiting satellite user node, 34. The satellite user node 34 is orbiting the Earth in lower space orbit, beyond the Earth's atmosphere.

[0033] FIG. 2 shows example communications leading to service for user node 36. First, user node 36 transmits a broadcast, represented by arrows 64, requesting service. The request 64 includes an indicator that the servicing beam must arrive at user node 36 from a direction that is below the local horizon. Source nodes 22 and 20 receive the broadcast request 64. Source node 22 responds to user node 36 by transmitting an offer, represented by arrow 66, to provide a power beam 54 within the parameters specified in the request to user node 36. Source node 20 does not respond to request 64, since the request required the source node to deliver a beam that is below the local horizon, and the position of source node 20 above user node 36 is unsuitable for such an engagement geometry. In this example, user node 36 receives no other offers from source nodes. It transmits an acceptance message, represented by arrow 68, to source node 22 to initiate the transaction. Shortly thereafter, the power delivery service should begin transmission from source node 22.

[0034] Referring next to FIG. 3, the results of a simulated power transfer between a single user and multiple source nodes are graphically illustrated. In this simulation an airborne user node traversed a path served by two widely-separated source nodes. The simulation includes two events enabled by the system architecture:

• • [0035] the user node's initial request for beam power, which is satisfied by power from a stationary source node that provide 12 kW of beamed power
  • [0036] a second request when the user node moves out of range of the first source node. This is satisfied by power from a second source node that provides only 11 kW.

[0037] The line designated as 70 represents battery energy (in Joules) and indicates energy available in the on-board battery of a user node. In the simulation scenario, the user node requests service when its on-board energy drops below 5×10⁵ Joules. At the time of the first request, at approximately 5 minutes, the user node is within range of the source node. The source node is capable of delivering a 12 kW power beam. The line designated 72 represents “Beam in” (in Watts) and indicates the amount of power reaching the user node receiver. At time equals approximately 7 minutes, the power beam begins arriving from a first source node. The user node has sufficient incoming power to keep flying and to begin recharging its battery. At time equals approximately 21 minutes, the user node moves out of range of the first source node and issues a request for a new source node to supply a beam. A second source node begins delivering a beam with 11 kW of power, while the user node travels onward and continues charging its battery at a slightly lower rate. The power deficit is indicated by line 74, which approximates a mirror image of the beam in line 72. Thus, when the power deficit 74 is high the “beam in” 72 is low, and the battery is generally discharging; when the power deficit 74 is low, the “beam in” 72 is high and the battery is charging.

[0038] The system preferably does not specify particular types of source nodes or user nodes. Rather, the system provides an operational and technological framework within which the source nodes and user nodes can operate effectively.

[0039] Source Nodes

[0040] In the system of the present invention, a source node is defined as a node that transmits power via one or more beams. Each source node can communicate its properties in response to an initial query message.

[0041] The properties of a source node can be described by various parameters, including:

• • [0042] whether the source node is a mobile or stationary node;
  • [0043] the field of regard of the source node relative to the axes of the vehicle on which the beam source is mounted, or if the source node is immobile, the field of regard of the source node relative to geographic axes;
  • [0044] one or more power beam wavelengths that the source node is configured to deliver. For each beam wavelength that a source node is configured to transmit, the source node can specify the following parameters:
  • [0045] the maximum sustained beam power that the source node can transmit;
  • [0046] the maximum duty cycle, i.e., the ratio of the maximum duration of beam transmission in a pulse, to the minimum duration of no transmission between pulses;
  • [0047] a pulse repetition rate—the pulse repetition rate is zero if the beam is constant; pulse repetition rate may be specified within a range of pulse rates;
  • [0048] the duration of a pulse;
  • [0049] a nearest acceptable focal distance to a user node, i.e., some beams can converge to a target at modest distance, e.g. 10 km;
  • [0050] and a minimum angular width of the beam at infinity.

[0051] Other parameters may be added to describe a power beam and characteristics, within the scope of the present invention, as will be appreciated by those skilled in the art. Thus, the above list of parameters is provided by way of example and not limitation.

[0052] The source node can also communicate parameters that describe the current physical parameters of the source node, in response to a request for update. The current physical parameters communicated by the source node can include the following:

• • [0053] the current location of the source node;
  • [0054] the current velocity vector of the source node
  • [0055] the current orientation of the source node, with respect to axes of a vehicle on which the source node is mounted. This orientation is preferably defined relative to geographic axes to allow computation of its current field of regard, based on its response to the initial query.
  • [0056] the identification of all user nodes to which it is currently sending power and the power being consumed by each of the identified user nodes;
  • [0057] the available energy capacity remaining at the source node, e.g. for a node that burns fuel to power its beam, the remaining energy capacity is a function of the fuel expended.

[0058] The current physical parameters of the source node may be communicated once, in response to a user node inquiry. Alternately, the current operative situation of the source node may be communicated periodically, e.g., as part of a system for tracking some or all of the source nodes in the system. The list of parameters set forth above with respect to user nodes is not intended to be exhaustive, and may include additional parameters as warranted by particular circumstances, as known to those who are skilled in the art.

[0059] In a distributed-control implementation of the present invention, each source node is configured to track its power capability parameters. For example, each source node may continuously or iteratively assess its own commitments and capabilities by comparing them to each request for power, and sending an appropriate response based on the tracked parameters. In response to a request for power, the source node may deny the request by a user node or offer to provide power. The source node may deny a request if insufficient resources are available, or for other reasons, such as for example, the location of the requesting user node, or obstacles obstructing the direct path between the source node and the user node. If able to satisfy all or part of a user node request, the source node communicates to the requesting source node an offer to provide power. The offer communicated by the source node specifies the format, the user node and the time interval of the power beam. If the user node communicates an acceptance of the offer from the source node back to the user node, the source node commits the necessary resources to fulfill that offer and executes the agreement at the parameters specified in the offer.

[0060] In an alternate embodiment of the present invention, there is a centralized controlled system. The centralized control system may be configured to track the power capabilities of all or some of the source nodes in the system. In the centralized control system, each source node receives commands from an authorized controller. Each command from the authorized controller directs the source node to provide power in a specific format to a specific user node for a specific time interval.

[0061] In either the distributed control or centralized control embodiments, each source node is configured to acquire a user node, track the user node, and transmit power in accordance with a commitment to provide power. Each source node is also configured to receive feedback parameters from a cooperating user node to maintain an accurate beam pointing and focus on the receiver of the user node. When power begins to flow from a mobile source node, the mobile source node maneuvers as appropriate, within the specified parameters of the beam geometry. In a preferred embodiment, the source node includes software that optimizes the source node flight pattern based on the mission constraints, other power beam commitments, the location, and weather obstacles that affect the beam.

[0062] Each source node is also configured to communicate a non-compliance message in response to a determination by the source node that the source node is unable to satisfy a request, or a commitment to a given user node. This response by the source node enables the user node to identify other suitable source nodes to satisfy its power needs. Possible reasons for non-compliance by a source node with a request from a user node may include, by way of example and not a limitation, a malfunction, a detected obstacle, an unplanned change of flight path, a higher-priority request, or deconfliction with other vehicles approaching the beam path.

[0063] In a preferred embodiment the system would automatically perform all of the above-described capabilities. However, it is also within the scope of the present invention for some of the above-described capabilities to be provided by human operators.

[0064] User Nodes

[0065] The present invention defines a user node as a node that receives power via one or more power beams. Each user node can communicate its properties and request power service. The properties of a user node can be described by various parameters, including the following:

• • [0066] whether the user node is mobile or stationary
  • [0067] the field of regard of the user node relative to the axes of the vehicle on which the user node is mounted, or if the user node is immobile, the field of regard of the user node relative to geographic axes;
  • [0068] one or more beam wavelengths that the user node is configured to receive. The acceptable beam wavelengths may be given as a range.

[0069] For each wavelength or sub-range of wavelengths, the user node can specify the following parameters:

• • [0070] the maximum sustained beam power that the user node is configured to receive; an acceptable pulse repetition rate—the pulse repetition rate is zero if the beam is constant, and the pulse repetition rate may be specified within a range of pulse rates;
  • [0071] a pulse duration that the user node is configured to receive, which may be specified within a preferably predetermined range.

[0072] The user node can also describe, in response to a request for update:

• • [0073] the current location of the user node;
  • [0074] the current velocity vector of the user node
  • [0075] the current orientation of the user node, with respect to axes of a vehicle on which the user node is mounted. This orientation is preferably defined relative to geographic axes to allow computation of its current field of regard, based on its receipt of a response to the initial query

[0076] The current physical parameters of the user node may be communicated once, or alternately, the current physical parameters of the user node may be communicated periodically, e.g., as part of a system for tracking some or all of the nodes in the system. The list of parameters set forth above with respect to user nodes is not intended to be exhaustive, and may include additional parameters as warranted by particular circumstances, as known to those who are skilled in the art.

[0077] Each user node can communicate requests for power to other nodes in the system. In a preferred embodiment of a distributed-control system, the user node communicates queries via an infosphere to identify all the available source nodes that are capable of meeting the power requirement of the user node. Infosphere, as used herein, means middleware that provides four major functions: publish, subscribe, advertise, and query. The query by the user node may include fields such as the user node location, and beam wavelength or wavelengths, pulse format and power levels of the user node, etc. If the user node receives no offers from source nodes in response to the query by the user node, then the user node may expand or revise the parameters of the query. This may require re-planning the flight of the user node, or the payload operation, in order to accommodate a non-optimal offer by a source node.

[0078] The user node may be required to revise its query several times and repeat them, with the queries being modified each time for less than optimal service. If the responses from source nodes indicate that the source node or nodes are unable to supply the user node with power sufficient for the user node, the user node executes a predetermined contingency plan. For example, the user node may be a manned vehicle, and would require making arrangements to land the vehicle before the remaining energy of the user node is exhausted.

[0079] When the user node receives offers of power supply from various source nodes in response to a query, the user node selects one or more of the offers. The user node then communicates an acceptance message in response to the offer message of the selected source node, or nodes if from multiple source nodes. If the source node or nodes selected by the user node begin to provide power service as agreed, the user node executes the plan. However, if the source node or nodes selected by the user node do not begin service as agreed, e.g., as a result of hardware failure or an unforeseen occlusion by clouds, the user node communicates a new query for power.

[0080] In an alternate embodiment, the system uses a central control system. The user node in a central control system communicates a request for power to an authorized control node. The control node responds to the user node request with a denial, or with a command to the user node to accept power from one or more specified source nodes. The user node communicates a confirmation message to the control node when the specified source begins service as specified, or a failure message if the specified source does not provide service as specified. The control node may be a source node configured for control functions, or a separate, standalone node in the network.

[0081] In the case of a mobile user node, when power is received, the user node positions itself according to the parameters of the agreed beam geometry. In a preferred embodiment, the user node is programmed to select optimized flight patterns based on one or more predefined parameters, including the mission, location and capacity of the user node, and weather obstacles that affect the transmission of the power beam.

[0082] The user node communicates with the source node to provide feedback to help the source node to maintain aimpoint, beam quality, etc. The feedback communicated by the user node may be passive feedback, e.g. corner reflectors, or active feedback, e.g. networked communication packets that report measured errors of the incoming beam, or combinations thereof.

[0083] The user node transmits a “change request” message if it is necessary to interrupt the transmission of the power beam before the agreed time, or to adjust the duty cycle or power level of the received power beam.

[0084] Relays

[0085] A relay is defined as a device that transmits power in one or more beams, and it receives power in one or more other beams. Relays are used as intermediate nodes for delivering power beams around obstacles, such as clouds or mountains, that obstruct direct line-of-sight power beam transmissions between source and user nodes.

[0086] In the system architecture of the present invention, a relay provides functions of both a user node and of a source node. In particular, a relay is configured to receive a request for service from a user node and pass the request on to other source nodes. In order for a relay to fulfill a power request by a user node, the relay must receive power from a source node. Therefore, when a relay receives a request for power, it computes how much additional power the relay must receive, factoring in the losses or inefficiency of the relay, then re-transmits a derived request that is greater in total power than the original user node request. If the derived request of the relay is able to be fulfilled by one or more source nodes, the relay transmits an offer to deliver a power beam to the requesting user node. When the acceptance of the offer is received by the relay, then the relay communicates its acceptance of the offer or offers that the relay received from the source node(s). A power beam is then transmitted from the source node(s) to the relay, and the relay in turn transmits a power beam to the requesting user node. Until a request from a user node is received, the relay remains in a standby mode.

[0087] A relay may be configured to convert power from one wavelength to another, e.g. from a microwave frequency to an optical frequency.

[0088] Sensors

[0089] The present invention employs two classes of sensors, obstacle sensors and deconfliction sensors. Obstacle sensors detect and quantify parameters related to obstacles that affect the transmission of various types of power beams. For example, power beams may be adversely affected by rain, clouds, smoke, regions of strong air turbulence, mountains, etc. Obstacle sensors may be physically embodied in a variety of ways. Video cameras, human inputs, weather forecasts, radar, or measured quality of beams traversing a region of the atmosphere are examples of devices that may be used as obstacle sensors. Other devices may be used as obstacle sensors as are well known to those skilled in the art.

[0090] A common characteristic shared by obstacle sensors is the ability to communicate information about obstacles to user nodes, source nodes or control nodes. In a preferred embodiment, obstacle sensors publish this information to an infosphere where it becomes available to any interested node of the system.

[0091] Deconfliction sensors are configured to detect conflicts and potential conflicts with beam transmissions. The deconfliction sensors are also configured to communicate information about areas through which beams should not be transmitted, or where beams may only be transmitted within defined limitations, due to presence of vulnerable assets. Vulnerable assets may include, for example, people on the ground, flammable trees in a drought-stricken region, manned aircraft, or other safety, logistical or ecological factors.

[0092] Deconfliction sensors may be physically embodied in a variety of ways, e.g. radar, human input, or an air traffic control network. A common characteristic that is shared by deconfliction sensors is the ability to transmit information about vulnerable assets or restricted areas to user nodes, source nodes or control nodes. A restricted area may include a traffic lane in which flights are planned. This is a typical method used to deconflict airspace in wartime. Information about conflicts may be as simple as setting a bit to 1 or 0 for a given location. Preferably, however, the deconfliction information would include more information, such as indicating whether a vulnerable asset is present; describing allowable intensity and total fluence for various wavelengths, and indicating any variation affecting deconfliction, with respect to the engagement angle of the beam. Deconfliction information enables nodes in the network to estimate whether a particular proposed beam transmission would pose a real threat to each asset. Deconfliction sensors may preferably be configured to publish deconfliction information to an infosphere, where the information is available to any interested node in the network.

[0093] Control Architecture

[0094] The control architecture of the system is configured to assign source nodes to user nodes. Decisions regarding assignment of beam transmissions may occur at user nodes or at a control node. Decisions regarding beam transmission conflicts can be made at user nodes, source nodes, or control nodes.

[0095] In one embodiment of the present invention, each user node broadcasts a request message to source nodes as shown in FIG. 2. Each source node decides whether to decline the user node request, or to offer to transmit power, based the capacity and available resources of the source node to fulfill the request. The source nodes that decide to extend offers, communicate the offers to the user node directly or via a network. The user node selects the offer or offers to accept, communicates its acceptance of the offer(s), and beam transmission service begins. In the embodiments of the invention that include beam deconfliction, all nodes in the system must periodically broadcast their locations and/or planned paths so that each source node or user node can perform deconfliction before extending or accepting an offer, and perform deconfliction periodically while the beam transmission service is provided. This method is conceptually similar to the link assignment method described in commonly-owned U.S. Pat. No. 6,947,733 entitled “Method And Apparatus For Reducing Self Interference In A Mobile Network”, and is hereby incorporated by reference. That invention dealt with communication interference, whereas in the present invention, deconfliction avoids physical harm.

[0096] In a centrally controlled system architecture, all nodes are configured to periodically report their status to a control node. User nodes send requests to the control node. The control node decides which source node should handle each request, sends an order to the selected source node, and awaits confirmation from the user node that the service is provided. When a user node moves from one region to another, it may come under control of a different control node, just as airliners today come under control of different ATC centers when they cross the country.

[0097] Communication Architecture

[0098] In a preferred embodiment of the present invention, each user node sends a request message as a broadcast. The user node broadcast may be a radio frequency (RF) broadcast signal, or a logical broadcast transmitted across a data network to all source nodes. Source nodes extending offers to supply power beams transmit such offers directly to the user node. These signals may be transmitted directly via RF signal, or across a data network. The user node communicates acceptance of the offer to the selected source node in the same or similar manner as the original broadcast, and service begins.

[0099] In the embodiments of the invention that include beam deconfliction, all nodes are configured to periodically broadcast their locations and/or planned paths so each source node or user node can perform deconfliction before extending or accepting an offer.

[0100] As discussed above, the present invention includes an infosphere-enabled architecture. In an infosphere-enabled architecture, each node is configured to publish its location periodically to the infosphere. “Location” may include the planned path as well, so that other nodes can predict where the publishing node will be.

[0101] Each source or user node subscribes to receive location data from the infosphere about other network nodes so that the node can analyze deconfliction information. Further, in the infosphere-enabled architecture, user nodes are configured to publish requests for power beams via the infosphere. The infosphere selectively passes the requests to source nodes which have indicated suitability by subscribing to certain types of requests. For example, a source node may have indicated to the infosphere the ability to cover requests by user nodes in predetermined geographic areas, and within a specified range of wavelengths and power levels. The infosphere-enabled architecture eliminates message traffic to nodes that are predetermined to be unsuitable for requests. In a centrally-controlled architecture with an infosphere, control nodes subscribe to requests; source nodes do not. Source nodes and user nodes may subscribe to orders, which the central control node publishes.

[0102] While the invention has been described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted for elements thereof without departing from the scope of the invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the invention without departing from the essential scope thereof. Therefore, it is intended that the invention not be limited to the particular embodiment disclosed as the best mode contemplated for carrying out this invention, but that the invention will include all embodiments falling within the scope of the appended claims.