HK1214041B - Methods and systems for a distributed radio communications network - Google Patents

Description

Method and system for distributed radio communication network

RELATED APPLICATIONS

The benefit and priority of U.S. patent application No. 13/690,602 entitled "METHODS AND SYSTEMS FOR acquired radiation COMMUNICATIONS NETWORK," filed on 30/11/2012, which is incorporated herein by reference in its entirety FOR all purposes, is claimed.

Technical Field

The present disclosure relates generally to methods and systems for distributed collection of data. In particular, the present disclosure relates to methods and systems for distributed radio communication networks.

Background

Conventional data collection networks, such as Wireless Sensor Networks (WSNs), provide distributed monitoring using sensor nodes that are generally aimed at low cost and/or low power. The geographic reach of such networks may be limited, and some networks may use multi-hop transmissions on multiple nodes (e.g., in a mesh configuration). Some data collection systems sometimes face network impairments due to unusable nodes and/or low signal-to-noise ratio radios. Some conventional data collection networks also face increased costs due to the number of nodes deployed to support the network, dedicated hardware to gather or process data, and/or maintenance/upgrades of these remote nodes. Real-time collection of environmental data over a wide area is a key contributing factor in a number of industries including agriculture, weather forecasting, disaster management, and homeland security. However, existing wireless technologies, including mesh networks, cellular and satellite, do not have such a range or are too costly for widespread monitoring applications.

Disclosure of Invention

In various aspects, the present application relates to methods and systems for a distributed radio communication network. Such networks may include ubiquitous wireless sensor networks or machine-to-machine (M2M) networks. Some embodiments of a distributed radio communications network may be implemented using Software Defined Radio (SDR). SDR may implement functions in software (e.g., mixing, filtering, amplifying, modulation/demodulation, detection, and encoding) typically provided by hardware. Radio Frequency (RF) signals may be converted to and from the digital domain via analog-to-digital (a/D) and digital-to-analog (D/a) converters. By using SDR, RF signals received by an antenna may be filtered and/or amplified before being sampled by an a/D converter. A processor executing a software application may process the samples from the a/D converter and may reconstruct the transmitted information. The reverse process may take the information to be transmitted and may construct samples of the transmitted waveform that are applied to the D/a converter. The output of the D/a converter may then be filtered and amplified before being applied to the antenna. A digital or analog frequency conversion step may be used to convert back and forth between the samples and the desired operating frequency. In some radio communication applications, it may be desirable to perform some or all of the receiver functions at a particular location remote from the antenna and/or RF electronics. This may occur when the complexity of some receive functions requires an expensive processing system (e.g., MIMO/MISO/SIMO applications). Rather than performing these functions at the receiver, it may be advantageous to collect samples of the RF information and send them to a central location via a network, e.g., where SDR processing functions may be located and/or may be shared among multiple radios/antennas.

In some aspects and as disclosed herein, certain SDR features may be centralized or selectively assigned and/or delegated to particular devices operating in a distributed radio communications network. In some embodiments, updates to a particular SDR function may be directed to a central device (or devices) hosting the SDR function, rather than being distributed to different locations via a network. Such updates may be transmitted over the network and, in some cases, wirelessly. Such SDR configuration may allow, for example, more manageable maintenance and updates, as compared to the installation of dedicated hardware or fully characterized SDR at each node. The present disclosure also describes systems and methods for dealing with impairments, such as doppler and multipath associated with ionospheric propagation, and may improve communication link margin by combining data received at multiple locations.

In one aspect, the present disclosure describes a system for providing a distributed radio communication network to implement a Wireless Sensor Network (WSN), where the sensor nodes may include low cost transmit and receive electronics and small, inefficient antennas. The nodes may be equipped with various sensors that measure some aspect of the environment, such as temperature, humidity or other weather conditions, the quantity or quality of water in, for example, a river or stream, or a characteristic of soil or other geological composition, such as temperature, moisture content, salinity or other parameters. A distributed radio communications network as described may receive node transmissions from nodes using multiple antennas in a coordinated manner, the transmissions of the nodes may not be detectable by a single antenna and a single receiver. In a similar manner, very low power signals from multiple gateway antennas may be used to send transmissions from the network to the node when low power transmissions from any one gateway antenna are used. In another aspect, the present disclosure describes a method of a distributed radio communications network in which node transmissions utilize frequencies below 30MHz, where both ground wave and ionospheric propagation may occur. Ionospheric propagation may involve near-normal incidence (NVIS) sky-wave or long-path sky-wave modes. Node transmissions may occur through a network using distributed antennas and may be received simultaneously by one or more nodes due to the distributed nature of gateway antennas, which may be located at different distances from the transmitting node that facilitate a particular propagation pattern.

In yet another aspect, the present disclosure is directed to a method for providing a distributed radio communication network. The method may include receiving, by each of the first gateway and the second gateway, respectively, a modulated signal including at least a portion of data from a first node of the plurality of geographically dispersed nodes. The modulated signal may be wirelessly transmitted as a Radio Frequency (RF) signal from the first node, with data collected or generated by the first node at the first location. The server may receive modulated signals from the first gateway and the second gateway. As configured by Software Defined Radio (SDR) software, the server may perform processing of the separately received modulated signals to recover the data. The processing may include demodulation of the modulated signal.

In some embodiments, the first gateway may compress the modulated signal received by the first gateway and may communicate the compressed modulated signal to the server. The server may perform a process including at least one of a Single Input Multiple Output (SIMO) and a Multiple Input Multiple Output (MIMO) process. The server may perform a process comprising at least one of: signal filtering, interference suppression, decompression, encryption, decryption, Forward Error Correction (FEC), encoding, decoding, beamforming, and antenna diversity processing. In some embodiments, the first gateway, the second gateway, and the server are connected via a communication network.

In some embodiments, at least one of the first gateway and the second gateway may receive one of the RF signals reflected from the ionosphere. The first gateway and the second gateway may receive the modulated signal transmitted as an RF signal via at least two of: a direct path from the first node, a ground wave path, and ionospheric reflections. The first node may transmit a low power RF signal between 3 and 30 megahertz (MHz) to at least one of the first gateway and the second gateway over a transmission path greater than 10 kilometers. The server may time-synchronize the modulated signals received from the first gateway and the second gateway, respectively, for combination of the modulated signals. The server may identify the interfering signal and may remove the interfering signal from the modulated signals received from the first gateway and the second gateway.

In yet another aspect, the present disclosure is directed to a system for providing a distributed radio communication network. The system may include a first node of the plurality of geographically dispersed nodes. A first node may gather or generate data at a first location. The first gateway and the second gateway may each receive a modulated signal comprising at least a portion of the data from the first node. The modulated signal may be wirelessly transmitted as a Radio Frequency (RF) signal from the first node. In some embodiments, the server may receive modulated signals from the first gateway and the second gateway. The server may be configured by Software Defined Radio (SDR) software to perform processing of the separately received modulated signals to recover the data. The processing may include demodulation of the modulated signal.

In some embodiments, the first gateway compresses the modulated signal received by the first gateway and may communicate the compressed modulated signal to the server. The server may be configured by the SDR software to perform processes including at least one of Single Input Multiple Output (SIMO) and Multiple Input Multiple Output (MIMO) processes. In some embodiments, the first gateway, the second gateway, and the server are connected by a communication network. At least one of the first gateway and the second gateway may receive one of the RF signals reflected from the ionosphere. The first gateway and the second gateway may receive the modulated signal transmitted as an RF signal via at least two of: a direct path from the first node, a ground wave path, and ionospheric reflections.

In some embodiments, the first node transmits a low power RF signal between 3 and 30 megahertz (MHz or MHz) to at least one of the first gateway and the second gateway over a transmission path greater than 10 kilometers. The server may perform a process comprising at least one of: signal filtering, interference suppression, decompression, encryption, decryption, Forward Error Correction (FEC), encoding, decoding, beamforming, and antenna diversity processing. The server may time-synchronize the modulated signals received from the first gateway and the second gateway, respectively, for combination of the modulated signals. In some embodiments, the server identifies an interfering signal and removes the interfering signal from the modulated signals received from the first gateway and the second gateway.

Drawings

The foregoing and other objects, aspects, features, and advantages of the disclosure will become more apparent and better understood by reference to the following description taken in conjunction with the accompanying drawings in which:

FIG. 1A is a block diagram depicting an embodiment of a network environment including a client in communication with a remote machine.

FIGS. 1B and 1C are block diagrams depicting embodiments of computing devices useful in connection with the methods and systems described herein.

Fig. 2A is a block diagram illustrating an embodiment of a distributed radio communications network.

Figure 2B is a flow chart showing an example of some steps applied to combine signals from multiple gateways.

Fig. 2C is a flow chart illustrating an example of some steps applied to cancel the effect of an interfering signal.

Fig. 2D is a block diagram depicting one embodiment of a wireless sensor node.

Fig. 2E is a block diagram depicting another embodiment of a wireless sensor node.

Fig. 2F and 2G are block diagrams of embodiments of a gateway for receiving and processing node transmissions.

Fig. 2H depicts a block diagram of one embodiment of an SDR server.

FIG. 2I depicts one embodiment of a data flow diagram for an end-user application.

Figure 2J is a block diagram depicting one embodiment of a flow chart of a method of a distributed radio communication network.

Detailed Description

For purposes of reading the description of the various embodiments below, the following descriptions of the sections of the specification and their respective contents may be helpful:

section a describes network environments and computing environments that may be useful for implementing embodiments described herein; and

section B describes embodiments of methods and apparatus for a distributed radio communications network.

A.Computing and network environment

Before discussing specific embodiments of the present solution, it may be helpful to describe aspects of the operating environment and related system components (e.g., hardware elements) in connection with the methods and systems described herein. Referring to FIG. 1A, an embodiment of a network environment is depicted. In brief overview, a network environment includes one or more clients 101a-101n (also collectively referred to as local machines 101, clients 101, client nodes 101, clients 101, client computers 101, client devices 101, endpoints 101, or endpoint nodes 101) in communication with one or more servers 106a-106n (also collectively referred to as servers 106, nodes 106, or remote machines 106) via one or more networks 104. In some implementations, the client 101 has the capability to function as a client node seeking access to resources provided by the server and as a server providing access to hosted resources by other clients 101a-101 n.

Although fig. 1A shows network 104 between client 101 and server 106, client 101 and server 106 may be on the same network 104. Network 104 may be a Local Area Network (LAN) such as a corporate intranet, a Metropolitan Area Network (MAN), or a Wide Area Network (WAN) such as the Internet or world Wide Web. In some implementations, there are multiple networks 104 between the client 101 and the server 106. In one of these embodiments, network 104' (not shown) may be a private network and network 104 may be a public network. In another of these embodiments, network 104 may be a private network, while network 104' is a public network. In yet another of these embodiments, both networks 104 and 104' may be private networks.

The network 104 may be any type and/or form of network and may include any of the following: point-to-point networks, broadcast networks, wide area networks, local area networks, telecommunications networks, data communication networks, computer networks, ATM (asynchronous transfer mode) networks, SONET (synchronous optical network) networks, SDH (synchronous digital hierarchy) networks, wireless networks and wired networks. In some embodiments, the network 104 may include a wireless link, such as an infrared channel or satellite band. The topology of the network 104 may be a bus, star, or ring network topology. Network 104 may have any such network topology as known to those of ordinary skill in the art capable of supporting the operations described herein. The network may include a mobile telephone network utilizing any protocol or standard for communicating between mobile devices, including AMPS, TDMA, CDMA, GSM, GPRS, UMTS, WiMAX, 3G, or 4G. In some embodiments, different types of data may be transmitted via different protocols. In other embodiments, the same type of data may be transmitted via different protocols.

In some implementations, the system can include multiple logically grouped servers 106. In one of these embodiments, the logical group of servers may be referred to as a server farm 38 or a machine farm 38. In another of these embodiments, the servers 106 may be geographically dispersed. In other embodiments, the machine farm 38 may be managed as a single entity. In still other embodiments, the machine farm 38 includes a plurality of machine farms 38. The servers 106 within each machine farm 38 may be heterogeneous — one or more servers 106 or machines 106 may operate according to one type of operating system platform (e.g., WINDOWS manufactured by microsoft corporation of redmond, washington), while one or more other servers 106 may operate according to another type of operating system platform (e.g., Unix or Linux).

In one embodiment, the servers 106 in the cluster 38, along with associated storage systems, may be stored in a high density rack system and located in an enterprise data center. In this embodiment, consolidating the servers 106 in this manner may improve system manageability, data security, physical security of the system, and system performance by locating the servers 106 and high performance storage systems on a localized high performance network. Centralizing the servers 106 and storage systems and coupling them with advanced system management tools allows for more efficient use of server resources.

The server 106 of each machine farm 38 need not be physically proximate to another server 106 in the same machine farm 38. Thus, the set of servers 106 logically grouped as a machine farm 38 may be interconnected using a Wide Area Network (WAN) connection or a Metropolitan Area Network (MAN) connection. For example, the machine farm 38 may include servers 106 physically located in different continents or different regions, countries, states, cities, campuses, or rooms of a continent. If the servers 106 are connected using a Local Area Network (LAN) connection or some form of direct connection, the data transfer speed between the servers 106 in the machine farm 38 may be increased. Further, the heterogeneous machine farm 38 may include one or more servers 106 operating according to one type of operating system, while one or more other servers 106 execute one or more types of hypervisors rather than operating systems. In these embodiments, the hypervisor may be used to emulate virtual hardware, partition physical hardware, virtualize physical hardware, and execute virtual machines that provide access to the computing environment. Hypervisors may include those manufactured by VMWare, inc, of palonoto, california; xen hypervisor-open source products, the development of which is supervised by Citrix systems, Inc.; virtualserver or virtual PC hypervisor, offered by microsoft, or others.

To manage the machine farm 38, at least one aspect of the performance of the servers 106 in the machine farm 38 should be monitored. Generally, the load placed on each server 106 or the status of sessions running on each server 106 is monitored. In some embodiments, a centralized service may provide management of the machine farm 38. The centralized service may gather and store information about multiple servers 106, respond to requests to access resources hosted by the servers 106, and enable a connection to be established between the client 101 and the servers 106.

Management of the machine farm 38 may be decentralized. For example, one or more servers 106 may include components, subsystems, and modules to support one or more management services for the machine farm 38. In one of these embodiments, one or more servers 106 provide functionality for management of dynamic data, including techniques for handling failover, data replication, and increasing the robustness of the machine farm 38. Each server 106 may be in communication with a persistent repository and, in some embodiments, a dynamic repository.

The server 106 may be a file server, an application server, a web server, a proxy server, a device, a network device, a gateway server, a virtualization server, a deployment server, an SSL VPN server, or a firewall. In one embodiment, the server 106 may be referred to as a remote machine or node. In another embodiment, multiple nodes 290 may be in the path between any two communicating servers.

In one embodiment, the server 106 provides the functionality of a web server. In another embodiment, the server 106a receives the request from the client 101, forwards the request to the second server 206b and responds to the client 101's request with a response to the request from the server 106 b. In yet another embodiment, the server 106 obtains an enumeration of applications available to the client 101 and address information associated with the server 106' hosting the application identified by the enumeration of applications. In yet another embodiment, the server 106 presents a response to the request to the client 101 using a web interface. In one embodiment, the client 101 communicates directly with the server 106 to access the identified application. In another embodiment, the client 101 receives output data, such as display data, generated by execution of the identified application on the server 106.

The clients 101 and servers 106 may be deployed to and/or executed by any type and form of computing device, such as a computer, network device, or apparatus capable of communicating over any type and form of network and performing the operations described herein. FIGS. 1B and 1C depict block diagrams of a computing device 100 that may be used to implement embodiments of a client 101 or server 106. As shown in fig. 1B and 1C, each computing device 100 includes a central processing unit 121 and a main memory unit 122. As shown in FIG. 1B, computing device 100 may include storage 128, installation 116, network interface 118, I/O controller 123, display devices 124a-101n, keyboard 126, and pointing device 127 (e.g., a mouse). The storage device 128 may include, but is not limited to, an operating system, software, and software of the demand side platform 120. As shown in FIG. 1C, each computing device 100 may also include additional optional elements, such as a memory port 103, a bridge 170, one or more input/output devices 130a-130n (generally referred to with reference numeral 130), and a cache memory 140 in communication with the central processing unit 121.

Central processing unit 121 is any logic circuitry that responds to and processes instructions fetched from main memory unit 122. In many embodiments, the central processing unit 121 is provided by a microprocessor unit, such as that manufactured by intel corporation of mountain view, california; a microprocessor unit manufactured by motorola corporation of Schaumburg, illinois; a microprocessor unit manufactured by International Business machines corporation of White Plains, N.Y.; or a microprocessor unit manufactured by Advanced Micro Devices, inc. Computing device 100 may be based on any of these processors or any other processor capable of operating as described herein.

The main memory unit 122 may be one or more memory chips capable of storing data and allowing direct access to any storage location by the microprocessor 121, such as Static Random Access Memory (SRAM), burst SRAM or synchronous burst SRAM (bsram), Dynamic Random Access Memory (DRAM), fast page mode DRAM (fpm DRAM), enhanced DRAM (edram), extended data output ram (edo ram), extended data output DRAM (edo DRAM), burst extended data output DRAM (bedo DRAM), enhanced DRAM (edram), Synchronous DRAM (SDRAM), JEDEC SRAM, PC100SDRAM, double data rate SDRAM (ddr SDRAM), enhanced SDRAM (esdram), synchronous link DRAM (sldram), Direct Rambus DRAM (DRDRAM), ferroelectric ram (fram), NAND flash, NOR flash, and Solid State Drive (SSD). The main memory 122 may be based on any of the above-described memory chips or any other available memory chip capable of operating as described herein. In the embodiment shown in FIG. 1B, processor 121 communicates with main memory 122 via a system bus 150 (described in more detail below). FIG. 1C depicts an embodiment of the computing device 100 in which the processor communicates directly with main memory 122 via a memory port 103. For example, in fig. 1C, the main memory 122 may be a DRDRAM.

FIG. 1C depicts an embodiment in which the main processor 121 communicates directly with the cache memory 140 via a secondary bus, sometimes referred to as a back-side bus. In other embodiments, the main processor 121 communicates with the cache memory 140 using the system bus 150. Cache memory 140 typically has a faster response time than main memory 122 and is typically provided by SRAM, BSRAM, or EDRAM. In the embodiment shown in FIG. 1C, the processor 121 communicates with various I/O devices 130 via a local system bus 150. Various buses may be used to connect the central processing unit 121 to any of the I/O devices 130, including a VESA VL bus, an ISA bus, an EISA bus, a MicroChannel architecture (MCA) bus, a PCI-X bus, a PCI-Express bus, or a NuBUS. For embodiments in which the I/O device is a video display 124, the processor 121 may use an Advanced Graphics Port (AGP) to communicate with the display 124. FIG. 1C depicts an embodiment of the computer 100 in which the main processor 121 may communicate directly with the I/O device 130b, e.g., via HyperTransport, RAPIDIO, or INFINIBAND communication technologies. FIG. 1C also depicts an embodiment in which the local bus and direct communication are mixed: the processor 121 communicates with I/O device 130a using a local interconnect bus while communicating directly with I/O device 130 b.

A wide variety of I/O devices 130a-130n may be present in the computing device 100. Input devices include keyboards, mice, trackpads, trackballs, microphones, dials, touch pads, and drawing pads. Output devices include video displays, speakers, inkjet printers, laser printers, projectors, and dye-sublimation printers. The I/O devices may be controlled by an I/O controller 123 as shown in FIG. 1B. The I/O controller may control one or more I/O devices, such as a keyboard 126 and a pointing device 127, such as a mouse or light pen. Further, the I/O device may also provide storage and/or installation media 116 for the computing device 100. In still other embodiments, the computing device 100 may provide a USB connection (not shown) to accept a handheld USB storage device, such as the USB flash drive family of devices manufactured by Twintech Industry, Inc. of Los Alamitos, Calif.

Referring again to FIG. 1B, the computing device 100 may support any suitable installation device 116, such as a disk drive, CD-ROM drive, CD-R/RW drive, DVD-ROM drive, flash drive, tape drives of various formats, USB device, hard drive, or any other device suitable for installing software and programs. The computing device 100 may also include a storage device, such as one or more hard disk drives or redundant arrays of independent disks, for storing an operating system and other related software, and for storing application software programs, such as any program related to the software 120 of the demand side platform. Alternatively, any of the mounting devices 116 may also serve as a storage device. Further, the operating system and software may run from a bootable medium (e.g., a bootable CD).

Further, computing device 100 may include a network interface 118 to interface to network 104 through various connections including, but not limited to, standard telephone lines, LAN or WAN links (e.g., 802.11, T1, T3, 56kb, X.25, SNA, DECNET), broadband connections (e.g., IDSN, frame-and-frame relay, ATM, gigabit Ethernet, Ethernet over SONET), wireless connections, or some combination of any or all of the above. Connections may be established using various communication protocols, such as TCP/IP, IPX, SPX, NetBIOS, Ethernet, ARCNET, SONET, SDH, Fiber Distributed Data Interface (FDDI), RS232, IEEE802.11a, IEEE802.11 b, IEEE802.11 g, IEEE802.11 n, CDMA, GSM, WiMax, and direct asynchronous connections. In one embodiment, the computing device 100 communicates with other computing devices 100' via any type and/or form of gateway or tunneling protocol, such as Secure Sockets Layer (SSL) or Transport Layer Security (TLS) or Citrix gateway protocol manufactured by Citrix systems ltd, ft. Network interface 118 may include a built-in network adapter, network interface card, PCMCIA network card, card bus network adapter, wireless network adapter, USB network adapter, modem, or any other device suitable for interfacing computing device 100 to any type of network capable of communicating and performing the operations described herein.

In some implementations, the computing device 100 may include or be connected to multiple display devices 124a-124n, each of which may be of the same or different type and/or form. Thus, any of the I/O devices 130a-130n and/or the I/O controller 123 may include any type and/or form of suitable hardware, software, or combination of hardware and software to support, enable, or provide for connection and use of multiple display devices 124a-124n by the computing apparatus 100. For example, computing device 100 may include any type and/or form of video adapter, video card, driver, and/or library to interface with, communicate with, connect to, or otherwise use display devices 124a-124 n. In one embodiment, the video adapter may include a plurality of connectors to interface to a plurality of display devices 124a-124 n. In other implementations, the computing device 100 may include multiple video adapters, each video adapter connected to one or more of the display devices 124a-124 n. In some implementations, any portion of the operating system of the computing device 100 may be configured to use multiple displays 124a-124 n. In other implementations, one or more of the display devices 124a-124n may be provided by one or more other computing devices (e.g., computing devices 100a and 100b connected to computing device 100 via, for example, a network). These embodiments may include any type of software designed and configured to use another computer's display device as the second display device 124a of the computer device 100. Those of ordinary skill in the art will recognize and appreciate various ways and embodiments in which the computing device 100 may be configured with multiple display devices 124a-124 n.

In further embodiments, the I/O device 130 may be a bridge between the system bus 150 and an external communication bus (e.g., a USB bus, an apple desktop bus, an RS232 serial connection, a SCSI bus, a FireWire 800 bus, an ethernet bus, an AppleTalk bus, a gigabit ethernet bus, an asynchronous transfer mode bus, a FibreChannel bus, a serial attached small computer system interface bus, or an HDMI bus).

Computing devices 100 of the type depicted in FIGS. 1B and 1C typically operate under the control of an operating system, which controls the scheduling of tasks and access to system resources. The computing device 100 may run any operating system, such as any version of the MICROSOFT WINDOWS operating system, different versions of the Unix and Linux operating systems, any version of the MAC OS of a Macintosh computer, any embedded operating system, any real-time operating system, any open source operating system, any proprietary operating system, any operating system for a mobile computing device, or any other operating system capable of running on a computing device and performing the operations described herein. Typical operating systems include, but are not limited to, Android manufactured by Google, Inc., WINDOWS 7 and 8 manufactured by Microsoft corporation of Redmond, Washington, MAC OS manufactured by apple computers of Pittano, California, WebOS manufactured by Research In Mot (RIM), OS/2 manufactured by International Business machines corporation of Armann, New York, and the freely available Linux operating system or Unix operating system of any type and/or form, issued by Caldera corporation of salt lake City, Utah, and the like.

Computer system 100 may be any workstation, telephone, desktop computer, laptop or notebook computer, server, handheld computer, mobile telephone or other portable telecommunications device, media playing device, gaming system, mobile computing device, or any other type and/or form of computing, telecommunications, or media device capable of communication. Computer system 100 has sufficient processor power and memory power to perform the operations described herein. For example, the computer system 100 may include devices of the IPAD or IPOD family of devices manufactured by apple computers of Bitino, Calif., the PLAYSTATOIN family of devices manufactured by Sony corporation of Tokyo, Japan, the NINTENDO/Wii family of devices manufactured by Nintendo, Inc., of Kyoto, Japan, or the XBOX device manufactured by Microsoft corporation of Redmond, Washington.

In some implementations, the computing device 100 may have different processors, operating systems, and input devices consistent with the device. For example, in one implementation, the computing device 100 is a smartphone, mobile device, tablet computer, or personal digital assistant. In still other implementations, the computing device 100 is an Android-based mobile device, an iPhone smartphone or blackberry handheld or smartphone manufactured by apple computer of bietino, california, such as the device manufactured by research Mot ion ltd. Moreover, the computing device 100 may be any workstation, desktop computer, laptop or notebook computer, server, handheld computer, mobile phone, any other computer, or other form of computing or telecommunication device capable of communication and having sufficient processing power and memory capacity to perform the operations described herein.

In some implementations, the computing device 100 is a digital audio player. In one of these embodiments, the computing device 100 is a tablet computer (e.g., APPLE IPAD) or a digital audio player (e.g., the APPLE IPOD family of devices manufactured by APPLE computers of bitino, california). In another of these embodiments, the digital audio player 100 may function as a portable media player and a mass storage device. In other implementations, the computing device 100 is a digital audio player, such as an MP3 player. In still other embodiments, computer device 100 is a portable media player or digital audio player that supports file formats including, but not limited to, MP3, WAV, M4A/AAC, WMA protected AAC, AIFF, audible audiobooks, Apple lossless audio file format, and. mov,. M4v, and. MP4MPEG-4(H.246/MPEG-4AVC) video file format.

In some implementations, the communication device 101 includes a combination of devices, such as a mobile phone combined with a digital audio player or a portable media player. In one of these embodiments, the communication device 101 is a smart phone, such as an iPhone manufactured by apple computer or a blackberry device manufactured by Research in Motion, Inc. In yet another embodiment, the communication device 101 is a laptop or desktop computer equipped with a web browser and a microphone and speaker system (e.g., a telephone headset). In these embodiments, the communication device 101 is web-enabled and may receive and initiate telephone calls.

In some implementations, the status of one or more machines 101, 106 in the network 104 is monitored, typically as part of network management. In one of these embodiments, the state of the machine may include an identification of load information (e.g., the number of processes on the machine, CPU and memory utilization), port information (e.g., the number of available communication ports and port addresses), session state (e.g., the duration and type of the process and whether the process is active or idle). In another of these embodiments, this information may be identified by a plurality of metrics, and the plurality of metrics may be applied, at least in part, to decisions in load distribution, network traffic management, and network failure recovery, as well as any aspect of the operation of the current solution described herein. Aspects of the operating environment and components described above will become apparent in the context of the systems and aspects disclosed herein.

B.Distributed radio communication network

Before discussing specific embodiments of the present solution, it may be helpful to describe aspects of Software Defined Radio (SDR) in conjunction with the methods and systems described herein. The SDR may implement in software the functions typically provided by radio hardware (e.g., mixing, filtering, amplifying, modulation/demodulation, detection decoding, and encoding). By way of example, SDR software may perform radio frequency filtering, audio filtering, and/or signal enhancement (e.g., equalization and binaural rendering). In SDR, some signal processing may be performed by, for example, a general-purpose processor rather than dedicated hardware. Various functions may thus be implemented via software configurations on computing devices, such as those described with respect to fig. 1A-1C.

As examples, hardware that can be configured by an SDR includes embedded systems and systems that include Field Programmable Gate Array (FPGA) devices. In certain applications and implementations, some components or functions of the SDR devices disclosed herein may be maintained in hardware (e.g., an analog-to-digital converter). SDR software as disclosed herein may be proprietary and/or configurable. Thus, an SDR may be configured to be able to receive and transmit various audio or communication protocols. The software implementing modules of the SDR server 107 may be written in various computer languages, such as C, assembly, Python, Java, Basic, or other languages.

Radio Frequency (RF) signals may be converted to and from the digital domain via analog-to-digital (a/D) and digital-to-analog (D/a) converters. In SDR, an RF signal received by an antenna may be filtered and amplified (e.g., by one or more software-defined hardware components) before being sampled by an a/D converter (e.g., one or more software-defined hardware components). A processor executing a software application may process the samples from the a/D converter and may reconstruct the transmitted information. The reverse process may take the information to be transmitted and may construct samples of the transmitted waveform that are applied to a D/a converter (implemented as one or more software-defined hardware components). The output of the D/a converter may then be filtered and/or amplified (e.g., by one or more software-defined hardware components) before being applied to the antenna. A digital or analog frequency conversion step may be utilized to convert back and forth between the samples and the desired operating frequency (e.g., within one or more software-defined hardware components).

In distributed radio communication network configurations (such as those disclosed herein with respect to the present methods and systems), SDR software and/or related applications may be deployed on one or more network devices. The distributed radio communication network may include a wide area or ubiquitous Wireless Sensor Network (WSN) or machine-to-machine (MM) network. Such networks may be configured to monitor and/or provide information regarding water, weather, and/or energy to users in agriculture, government, and defense. Such a network may direct the generated data to a centralized node for processing and/or combining. In certain embodiments, the network may include a cloud-based sensor network (sometimes referred to hereinafter as a "RadioCloud") to gather or receive data from low-cost, battery-powered sensors. A network of gateways may be deployed (e.g., as part of the RadioCloud) to relay sensor transmissions to a processing center or cloud-based application. The transmission may be relayed via, for example, an IP network, which may be wireless or otherwise. The cloud-based web services platform may provide end-user access to data recovered from sensor transmissions.

In some embodiments, DSR may be used to implement a substantial portion of a distributed radio communications network. For example, some sensors or gateways or components thereof may be implemented using specially adapted SDR software and applications. Conventional SDRs typically combine front-end, digital conversion and software functions into a single device, which requires that all devices in the network be equipped with the necessary hardware and software functions and power supplies to power all components. The SDR solution disclosed herein may configure a particular device (e.g., a central server) and may provide particular functions but not necessarily all functions.

In certain embodiments, the distributed radio communications network is configured to collect network-wide data regarding impairments (e.g., interference) to, for example, a central location. A distributed radio communications network may improve communication link margin by combining data received at multiple locations (e.g., gateways). In a network, updates to SDR functions may require physical propagation of computer media (e.g., CDROMs) or may require multiple file downloads over a communications network. Embodiments of distributed radio communication networks using SDR may defer or redistribute computationally intensive techniques such as antenna diversity or multiple-input multiple-output (MIMO), multiple-input single-output (MISO), or single-input multiple-output (SIMO), for example, from some or all radios (e.g., sensors or gateways) in the network to a central processing node or specific application hosted at one or more locations in the network. It is not necessary for all radios in the network to include the computing hardware and full software functionality for handling these computationally intensive techniques.

In some radio communication applications, it may be desirable to perform some receiver functions at a particular location remote from the antenna and/or RF electronics. This may occur when the complexity of some receive functions requires an expensive processing system (e.g., MIMO/MISO/SIMO applications). Rather than performing these functions at each receiver (e.g., gateway or intermediate node), it may be advantageous to collect samples of RF information and send them via a network to a remote location where SDR processing may be centralized or shared among multiple radios.

By way of example, fig. 2A shows a distributed radio communication network with a plurality of nodes (100, 101) and a plurality of gateways (102, 103). The nodes 100, 101 may communicate with one or more gateways (102, 103) over one or more radio channels. Each gateway (102, 103) may be connected to one or more SDR servers 107 via the network 104 through respective wired or wireless communication links 116, 117.

Each gateway may include an antenna, a "front end module," an a/D converter, a D/a converter, a digital up-converter, a digital down-converter, and a network interface. One or more software modules, applications or other executable code running on SDR server 107 may operate on digital samples received from gateways (102, 103) or produce samples which are then transmitted by gateways (102, 103) to nodes. At least one and possibly a plurality of users (105, 106) may be connected to the network 104. The user may access a module on the SDR server 107 to view, generate and/or retrieve information from the nodes (100, 101). The user may access data transmitted by the nodes 100, 101. As non-limiting examples, the nodes 100, 101 may be wireless sensors that measure some parameter from the environment (e.g., water level, temperature, humidity, pressure, infrared levels for detecting fires, location, radioactivity, sound level, geographic activity, etc.). The network may collect such data and may provide some or all of the data to the user 105 via a web page, map, application interface, broadcast, etc. The user 105 may also interact with the module 108 and the nodes 100, 101, for example by setting an alarm level (e.g. for water temperature) which will cause an alarm if a threshold is exceeded. The nodes 100, 101 may be any devices that transmit and/or receive information over a network, such as conventional sensors used in WSNs or customized and/or configured sensor nodes. Some embodiments of the RadioCloud system may include transmission-only nodes that transmit data, while other embodiments may include nodes that transmit data as well as receive communications, which may include instructions, updates, configurations, and data for retransmission.

Still referring to fig. 2A, nodes 100 and 101 may include hardware radios and/or software defined radios. These nodes may send and receive information over Radio Frequency (RF) channels. A node may be equipped with a single (100) or multiple (101) antennas. Transmissions 112 to and from the node 100 may propagate or travel directly to gateways (102, 103), e.g., via ground wave propagation, or reflect 110, 111 from the ionosphere 109 of the earth to form a High Frequency (HF) radio network. In ground or surface wave propagation, radio waves may travel near the surface of the earth without being reflected or refracted by the atmosphere. Using ground wave propagation, the HF signal can be diffracted strongly and follow the curvature of the earth for distances up to tens of kilometers, depending on the frequency. Such ground wave propagation may include dominant propagation modes at lower frequencies. Nodes may also transmit data using line-of-sight propagation, where radio waves travel in straight lines and have dominant patterns at higher frequencies.

In some aspects, a node may transmit data to one or more gateways via skywaves. Sky wave propagation may occur at short wave radio frequencies, including the upper intermediate frequency (MF) and all High Frequency (HF) portions of the radio spectrum. Sky wave propagation utilizes the propagation of radio waves that reflect or refract from the ionosphere back to the earth. Due to the nature of the earth's ionosphere, signals in the HF range can be reflected and can travel large distances. Sky wave propagation may be used to relay data to receivers outside the horizon, up to continental ranges, regardless of the curvature of the earth. Sky wave propagation occurs when a signal reflects from the ionosphere at high (NVIS) or low (long path) angles of incidence. In particular, long path propagation with a single low angle reflection may provide a transmission path of thousands of kilometers.

In certain aspects, a node may transmit data to one or more gateways via near-vertical incidence sky-wave (NVIS) that may support a transmission range between ground wave and sky-wave distances (e.g., about 50 to 650 km). NVIS radio waves may use frequencies between 1.8MHz and 15 MHz. NVIS operation may include selection of operating frequencies that may reflect from the ionosphere, which experience daily variations due to the ionizing effects of solar radiation. Some advantages of NVIS are that the corresponding RF path loss is rather low, allowing the use of low power transmitters, and that propagation outside the NVIS region is greatly attenuated, leading to the possibility of frequency reuse. Using nodes transmitting via NVIS, the radio waves can travel up into the ionosphere where they can be refracted back down and received up to 650km away from the transmitter.

Ionospheric propagation can cause multiple impairments to RF signals, including doppler delay spread, multipath due to time variations in propagation, interference from natural sources (e.g., light), and interference from transmitters in other regions of the world that share the same or nearby spectrum. The present systems and methods can handle impairments associated with ionospheric reflections and interference, such as doppler and multipath, and can improve communication link margin by combining data received at multiple locations.

The HF spectrum using WSNs includes a number of challenges, including daily variations in the ionosphere of the earth, natural and man-made noise, and interference from transmitters sharing the same frequency in other regions of the world. The RadioCloud system takes advantage of HF propagation and low free space loss while overcoming such challenges. By using SDR techniques and power efficient modulation, both HF propagation modes can be used to optimize WSNs for applications such as soil moisture monitoring and broader environmental data monitoring, where infrequent reporting of small amounts of data is required for large geographic coverage. Furthermore, the RadioCloud system is designed to take advantage of the surface and NVIS propagation modes, and the proposed locations of the nodes and gateways can be used to determine the relative performance of each mode.

By supporting signal propagation at high frequencies (e.g., 3-30MHz), using low power, and over a propagation range of 10km, the present systems and methods differ from conventional WSNs (e.g., mesh networks) and provide advantages over conventional WSNs. Mesh networks, for example, rely on short range (typically less than 300m) signals being relayed from a source node through other nodes to a destination device over multiple hops. The intermediate node performs demodulation and modulation of the received signal prior to retransmission. Such additional processing results in increased complexity and cost for each network node. In applications such as remote monitoring of soil moisture in large scale farming operations, the battery requirements and limited coverage of cellular services make cellular data networks unsuitable for environmental monitoring. Satellite networks are even more expensive to operate than cellular (typically greater than $ 15/month/node), require larger antennas and have line-of-sight limitations, which precludes the use of tall crops or plants.

To reduce power requirements, current systems and methods may take advantage of the lower data rate (e.g., 100bps) requirements of some applications. Bandwidth efficient waveforms, such as Phase Shift Keying (PSK), may be used where a higher link data rate for a given bandwidth is required. Power efficient waveforms (e.g., PSK, M-PSK) may trade off bandwidth efficiency to reduce the transmission power required in power constrained applications (e.g., battery powered WSNs).

The transmissions 114, 115 from the node 101 may utilize multiple antennas to provide MIMO or MISO capabilities in the network. In some cases, nodes (e.g., transmission-only nodes) may schedule their transmissions using the Media Access Control (MAC) protocol or some other protocol. Transmissions may be scheduled at particular times and/or frequencies to minimize the likelihood of collisions with transmissions of other nodes, e.g., using time division multiplexing and/or frequency division multiplexing. For example, GPS coordinates or other node identifiers may be used to select or identify particular time and/or frequency slots for corresponding transmissions.

In certain embodiments, the gateway (102, 103) may include a transceiver, an antenna, one or more front end components for converting and amplifying RF signals, a/D and D/a converters, digitizer circuitry and/or a network interface. The gateway may comprise an SDR transceiver or an SDR interface. Each gateway may be configured to receive different types/modes of transmissions from one or more nodes. For example, the gateway may be configured to receive signals from any one or more of the three modes (ground wave, NVIS, and long-range). The gateway may perform direct sampling of the signal received at the gateway. The gateway may downconvert the received signal (e.g., via a digital downconverter) without demodulating the signal. The gateway may sample the downconverted signals and may transmit these samples via a network (e.g., the internet) to a remote/central location for processing.

The gateway may sample the received signal at a specified frequency at a specified time, e.g., as indicated by software of the SDR server. The network interface of the gateway may relay the samples of RF frequencies to the network 104 or from the network 104. The network may comprise a private packet-switched network, a public network, the internet, or any other wide or local area network. The network interface may include an ethernet or other interface. The network interface may enable the radio processing modules to be located anywhere away on the network without restricting them to being within the gateway or to devices connected proximately to the gateway. In some implementations, the radio processing module is configured via an SDR on a computing device (e.g., an SDR server) connected to the gateway (e.g., via USB). The gateway may compress the samples first and then relay the compressed samples to the central SDR server.

In some embodiments, the gateway software downconverts the received signal to baseband in order to reduce the bandwidth required to send signal samples to the SDR server for further processing. The nodes and gateways may be synchronized according to GPS information (e.g., embedded in the received signals) so that the received signals are properly grouped or separated and the samples are properly time registered. The signal transmissions from the nodes may include timing, synchronization, and/or sequencing information embedded in the payload and/or header portions of the signals. In some embodiments, the nodes and gateways may receive and/or use information from a GPS source for high precision time synchronization. In some embodiments, the RadioCloud system may use GPS time synchronization to recover symbol timing and for supporting multiple access. Some or all of these processing steps, which may be computationally intensive, may be deferred from the gateway to the SDR server. The cost of gateways may be reduced because such gateways do not demodulate and/or significantly process received node transmissions.

In some embodiments, a network may include multiple nodes, gateways, and/or users. The network 104 may be connected to one or more SDR servers 107, such as in a cloud computing network. A module 108 running on the SDR server may perform various functions for recovering node data from samples sent by the gateways 102, 103 over the network 104. In a similar manner, these modules 108 may also generate samples containing information to be sent to one or more nodes. The antennas on the gateway may be selected and/or configured to give preference to one or the other type of propagation (e.g., antennas with high angular radiation patterns may give preference to NVIS propagation).

SDR server 107 may comprise any type of computing device configured via SDR software. By configuration, an SDR server may comprise one or more modules that perform specific processing of samples of a radio signal. The modules on SDR server 107 may include, but are not limited to, logic and functionality for performing the following: filtering, interference suppression, modulation/demodulation, encryption/decryption, Forward Error Correction (FEC) encoding/decoding, MIMO/MISO/SIMO processing, beamforming and antenna diversity processing (e.g., maximum likelihood combining and diversity encoding), database access, and user interface. In one embodiment, all of the modules 108 may be present on a single SDR server 107. While in alternate embodiments less than all of the modules 108 may be present on each of the multiple SDR servers 107. The user 105 may access the recovered node data via the network 104 through a user interface.

In some aspects, MIMO processing involves the use of multiple antennas at both the transmitter and receiver to improve communication performance by efficiently providing multiple channels for communication. MIMO provides a significant increase in data throughput and link range without additional bandwidth or increased transmit power, for example, by spreading the same total transmit power over antennas to achieve array gain for improved spectral efficiency or to achieve diversity gain for improved link reliability (reduced fading). SIMO similarly improves communication performance by providing multiple receive antennas that can provide diversity gain.

Beamforming is used for directional signal transmission or reception in the sensor array to achieve spatial selectivity. This is achieved by combining the elements in a phased array in the following way: such that signals at a particular angle experience constructive interference while other signals experience destructive interference. In some embodiments, beamforming implemented in a RadioCloud system may be referred to as distributed beamforming. A RadioCloud system may include multiple (gateway) antennas separated by large distances to collect phase and amplitude information about the node signals. The RadioCloud system may use this information in the SDR server to form virtual "beams" that selectively enhance signals from one direction and reduce signals from other directions. In fact, this set of gateway antennas operates like one large steerable high gain antenna.

Antenna diversity uses two or more antennas to improve the quality and reliability of the wireless link. There is often no clear line of sight between the transmitter and receiver and the signal may reflect along multiple paths before being finally received. Each of these bounces can introduce phase shifts, time delays, attenuations, and distortions that can destructively interfere with each other at the aperture of the receive antenna. Antenna diversity mitigates these multipath situations because multiple antennas provide several observations of the same signal, which experience different interference environments. Thus, if one antenna experiences deep fading, it is likely that the other antenna has sufficient signal. Such systems may collectively provide a robust link.

Still referring to fig. 2A, nodes 100 and 101 may comprise commercial, standard or specially configured digital radios operating at HF, VHF, UHF or other frequencies. In some embodiments, radios operating in the High Frequency (HF) range, including the spectrum from 3-30MHz, are used for RadioCloud. The HF signals may be reflected by various layers of the earth's ionosphere and may travel long distances. The HF spectrum has been widely used for various services such as short wave broadcasting, marine and aeronautical communications, and other commercial and defense communications; today, most of the spectrum is unused (e.g., except short-wave broadcasting, amateur radio, and defense). In addition to this spectrum under-utilization and availability, HF transmission may also be desirable for outdoor wireless sensors because low power HF signals may travel long distances.

The node may be configured to transmit on one or more frequencies based on the location of or distance from the receiving gateway. A node may be configured to transmit on one or more frequencies based on factors such as terrain, time of day, season, weather, supported propagation modes, and so forth. The node may transmit on a frequency that maximizes the chance of successful transmission to the receiving gateway. The propagation characteristics of the ionosphere can change due to the influence of solar radiation. This may mean that the maximum available frequency or range increases during the night. In a simple case, certain embodiments of the node may switch between two frequencies or frequency ranges during the day and night. A single transmission may travel through the ground wave or one or two sky wave modes depending on the location of the gateway receiving the signal.

The RadioCloud nodes may include wireless nodes, each including one or more sensors. These nodes may include radios capable of transmitting and/or receiving digital information as radio frequency signals or samples. Gateways 102 or 103 may be constructed from commercial, custom, or specially programmed radio components (e.g., antennas, RF converters, amplifiers, a/D and D/a converters, FPGAs, microprocessors, and/or SDR components). The SDR server 107 may comprise a computing device such as, but not limited to, a standard computer server running a Microsoft Windows or Linux operating system. SDR servers may be dedicated to specified applications/tasks and may include cloud computing services that may utilize one or more virtual servers.

In some embodiments, and referring again to fig. 2A, node 100 sends transmissions 112, 113 received at gateway 102 and/or gateway 103. Samples of the received signal may be sent or directed to an antenna diversity module on the SDR server where they may be time synchronized and combined, for example, to improve signal-to-noise ratio (SNR) and/or other parameters. Alternatively, node 100 and node 101 may each transmit space-time encoded signals received by gateway 102 and/or gateway 103, and each gateway may send samples to a MIMO/SIMO module to increase signal transmission speed/throughput, SNR, or other parameters of the received signal. MIMO/SIMO processing may be performed entirely in software (e.g., via SDR software configuration, rather than custom radio hardware).

The configuration of the one or more gateways may include a set of distributed antennas. These distributed antennas may collect different signals from multiple paths or propagation modes from one or more locations for aggregation/processing at a predetermined central location. The distributed antennas may be configured to support antenna diversity and/or beamforming strategies. In some embodiments, gateway 102 and/or gateway 103 may transmit space-time coded signals 114 and 115 to node 101 such that speed/throughput, SNR, or other parameters of the link may be improved.

Fig. 2B is a flow diagram illustrating an example of steps that may be used to implement an antenna diversity module, such as the antenna diversity module shown in fig. 2A. In step 200, the node transmits a radio frequency signal, which is received by a plurality of gateways via three paths 201, 202 and 203 or any other number of transmission paths. These paths may be directed from the node to the gateway via ground wave paths, via reflections from the ionosphere, and/or via another type of path. The signals from these paths may be down-converted to, for example, a baseband frequency and sampled at each gateway. The samples may be time synchronized in step 205, for example, using local GPS information or other timing information. The samples may be added together or otherwise combined in step 206 (e.g., without regard to signals received over a distributed set of antennas/gateways), and the combined samples may then be sent to a demodulation module in step 207, where they are processed as if the samples came from a single path. Thus, demodulation and other processing techniques (e.g., SIMO/MIMO) may be performed as if it were a non-distributed system. As a result of the sample addition, the resulting signal-to-noise ratio can be improved.

Fig. 2C is a flow chart illustrating an example of steps that may be used to implement the interference suppression module shown in fig. 2A. In step 300, the node may transmit a radio frequency signal received by the first gateway on path 302. In step 301, interference samples may be received at a first gateway via path 303 and interference samples may be received by a second gateway via path 304. One or more of the paths 303, 304 may be directed from the node to the gateway via a ground wave path, via reflection from the ionosphere, or via another path. The interfering signal may be identified, for example, by connecting both a vertically polarized antenna and a horizontally polarized antenna to the gateway. For example, a vertical antenna (e.g., a monopole antenna) may have a lower radiation angle than other types of HF antennas (e.g., a loop antenna). Vertically polarized signals can be more prominent from artificial noise sources such as car ignition and arcing in electrical transmission lines. Signals from remote sources (e.g., short wave broadcast stations) may be more likely to arrive at low reflection angles because they travel through multiple ionospheric reflections. The signal from the interferer may also be reduced by using a phased array technique, where nulls are generated in the overall antenna pattern in the direction of the known interferer. One type of antenna may be easier to acquire node signals than other types of antennas. Another type of antenna may be easier to acquire noise or interference signals, for example, which the first type of antenna may pick up in addition to the node signal.

In step 305, the samples from gateway 1 comprising the desired signal plus the interfering signal and the samples from gateway 2 comprising the interfering signal may be passed to the next step 306. In step 306, samples containing the interfering signal may be subtracted from samples including the desired signal plus the interfering signal. In step 307, the desired signal samples may be sent to a demodulation process, where the samples may be processed as if the samples were received without an interfering signal.

Advantages of the described embodiments include, without limitation, minimizing the cost of providing a wireless network by using one or more central software defined radio servers. The signal-to-noise ratio of a wireless link may be improved by combining signals received at multiple locations. The SNR may be improved by combining signals received via different propagation paths and/or different propagation modes. For example, different signal paths may be generated by different propagation modes and/or by multipath effects resulting from the motion of the ionosphere. Based on daily propagation, some node transmissions (e.g., from a single node) may be received by one gateway, while other node transmissions are received by both gateways. Processing functions associated with complex radio waveforms may be performed in one or more powerful centralized servers or distributed across multiple computing resources. Updates to certain SDR functions to accommodate new wireless standards can be quickly implemented by changing only the software in the SDR server.

By way of example and not intended to be limiting, the RadioCloud node may include a battery-powered wireless sensor. The battery of the node may comprise a rechargeable battery, for example, rechargeable from solar energy. The node may include a microcontroller (e.g., an 8-bit processor) having a set of peripherals such as (I) a GPS module for obtaining geographic location information and a global timing reference, (I I) a digital sensor which may include a sensor IC having a digital interface connected to, for example, an I2C or SPI bus of the microcontroller, (iii) an analog sensor which may include a sensor circuit having an analog output connected to an a/D converter of the microcontroller, and (iv) a radio transmitter which may include, for example, a digitally controlled Frequency Shift Keying (FSK) transmitter. In some embodiments, the transmitter may be a Phase Shift Keying (PSK) transmitter or a transmitter supporting any other modulation technique. From an interface perspective and by way of example, the microcontroller may control a digitally controlled HF oscillator to select a channel and may sequence general purpose input/output (GPIO) parallel output ports to provide any necessary digital baseband signals. For illustration, fig. 2D depicts one embodiment of a block diagram including functional modules of a node. The node may also provide one or more of the following: (v) control signals, where one or more GPIOs may be used to selectively turn power on or off to components of a node (e.g., radio or sensor circuitry) to save power, (vi) Light Emitting Diodes (LEDs), buzzers, and/or buttons that communicate with a person at manufacture or installation time, and (vii) serial consoles that may include synchronous serial interfaces with command resolvers used for device configuration, manufacturing, and debugging, for example.

In some embodiments, the responsibilities of the node microcontroller may include any one or more of the following: (i) periodically waking certain functions of the node by a timer, (ii) reading sensors, (iii) interfacing with GPS, (iv) maintaining a Real Time Clock (RTC), (v) generating sensor reports, (vi) selecting appropriate channels and time slots for transmission/reception, (vii) encoding reports for transmission, (viii) reading/writing configuration settings, such as non-volatile (NV) configuration settings, (ix) responding to external button/input devices and setting LED or buzzer outputs as necessary, (x) providing a serial console for, e.g., device configuration, manufacturing testing and/or debugging, and (xi) providing a boot loader for field upgrades and/or factory programming of firmware. In some embodiments, the software of the node may be simple enough to be implemented as a single task using an event driven state machine, such as a main loop. Interrupt handlers may support time-dependent I/O and timing functions. The GPS location may be sent at irregular or set times to save transmission bandwidth.

In some embodiments, a node generates and/or encodes a sensor report for transmission to one or more gateways. The node may add any necessary MAC-level control information, such as a point sequence, a synchronization word, or a protocol identifier. The node may perform Forward Error Correction (FEC) encoding to protect the packet from errors, for example, using a rate 1/2 (k-32) convolutional code. The node may include or contain library code to implement the encoding. The node may perform data whitening to ensure a clean spectrum. The node may perform FSK, PSK, or other types of encoding. Depending on how the modulation is performed, the node may generate a 4-bit parallel word for each symbol, output a digital-to-analog conversion (DAC) value, or issue a command to a Numerically Controlled Oscillator (NCO) to move to a specified frequency.

Fig. 2E depicts one embodiment of a RadioCloud node. The node may include one or more sensors 406 for monitoring temperature, humidity, wind speed/direction, soil moisture, etc. The sensors may be connected to a Microcontroller (MCU) 405. The MCU may include an a/D converter, flash and RAM memory, I/O ports, and/or a CPU. A timer, for example contained within the MCU, may be used to periodically "wake up" the MCU from a low power sleep mode in order to conserve battery power. When the MCU wakes up, the data from the sensors 406 may be digitized by the a/D converter and combined with synchronization and Forward Error Correction (FEC) information to create packets. Once the sensor packet is created, the transmission time and frequency may be selected by the node software based on a combination of configuration and/or GPS information. Once the appropriate time and frequency of transmission is determined, the transmission cycle can begin.

During the transmission period, binary information from the packet may be used to change the frequency of the oscillator 404, which oscillator 404 may be a voltage controlled crystal oscillator (VCXO), a frequency synthesizer, or a Direct Digital Synthesizer (DDS), which may be used to generate the carrier frequency. The output signal from the oscillator may be filtered (403) to remove spurious signals and then amplified by the power amplifier 402 to a power level suitable for transmission. The power output required for reliable communication can be reduced by virtue of the ability of the central SDR server to combine information from multiple propagation paths and multiple gateways. The output of the power amplifier 402 may include a frequency modulated carrier and may be filtered by a second filter 401 to remove spurious signals generated by the power amplifier 40. The filtered power amplifier output may be applied to an antenna 40, which may be a custom or conventional antenna, such as a monopole, dipole or Yagi antenna or a compact antenna (e.g., a loop antenna), which may be ferrite loaded to further reduce its size. The elements of the node may be powered by a battery 407, which battery 407 may be a primary disposable battery or a rechargeable secondary battery. If a secondary battery is used, it may be recharged by Photovoltaic (PV) cells 409. In some other embodiments, SDR techniques and D/a converters may be used to generate the carrier frequency, which may be a less expensive approach to FSK, PSK, and certain other types of waveforms.

A node may transmit data as an RF signal, which may include packets of data (sometimes interchangeably referred to as frames, datagrams, or messages). A node may encode packets at two or more layers, such as a PHY layer and a MAC layer. The PHY layer may represent a physical encoding of symbols, for example on a radio carrier, using 4-FSK transmitted at 1.46 baud (WSPR) or 16-FSK transmitted at a predetermined baud. The packet data payload may be limited to 50 bits, although this may be reconfigured or extended. Certain embodiments of the node may support or use Multiple Frequency Shift Keying (MFSK) and any type/variant thereof, such as, without limitation, dual tone multi-frequency (DTMF), MFSK8, MFSK16, Olivia MFSK, Coquelet, Piccolo, ALE (MIL-STD 188-. Some embodiments may support or use any type or variation of Phase Shift Keying (PSK), such as Differential Phase Shift Keying (DPSK), Binary Phase Shift Keying (BPSK), Quadrature Phase Shift Keying (QPSK), and variations thereof (e.g., OQPSK, pi/4-QPSK, SOQPSK, DPQPSK). Nodes may also support Amplitude Shift Keying (ASK), such as OOK, 8VSB, or any combination of ASK, PSK, and/or FSK. Certain embodiments of the node may support or use Frequency Division Multiplexing (FDM), such as OFDM, Phase Division Multiplexing (PDM), Quadrature Amplitude Modulation (QAM), ultra wideband (UMB), Continuous Phase Modulation (CPM), and/or spread spectrum techniques (e.g., DSSS, FHSS, THSS, CSS, UWB).

As a non-limiting example, a PHY frame may be encoded using a MAC payload of N-50 data bits. A node may apply binary encoding using (K-32, r-1/2) convolutional codes to produce, for example, (N + K-1) × 2-162 code bits. The node may modulate the code bits using, for example, continuous phase 4-FSK, where one bit of each symbol may be driven by a (e.g., 16-bit) pseudo-random synchronization vector. The resulting (162+162)/2 ═ 162 symbol frame may be transmitted by the node at 1.46Hz tone intervals at 1.46 baud, resulting in a final transmission length of 110.6 seconds. Each transmission may be slotted, e.g., beginning two seconds after an even 2-minute boundary per coordinated Universal Time (UTC) time period (e.g., at hh:00:02, hh:02:02, etc.). The transmission may occupy a bandwidth of about 6 Hz.

In some embodiments, the PHY frame may be encoded using an N-bit (e.g., 127-bit) MAC payload. A node may apply binary encoding using (K-32, r-1/2) convolutional codes to produce (N + K-1) × 2-316 code bits. The node may modulate the code bits using continuous phase 16-FSK, where the message is preceded by, for example, a (e.g., 16-symbol) balanced synchronization (sync) vector. The node may transmit the resulting (316/4) +16 ═ 95 symbol frame at a predetermined baud at a particular tone interval. Each transmission may be slotted. The synchronization vector may be used to provide an explicit reference to the start of the packet to facilitate frame decoding. The synchronization vector may be designed to provide a balance of ones and zeros and exhibit low autocorrelation. At least 14 out of 16 symbols may have to match the synchronization vector before attempting to decode the frame. The node may be configured to allow a margin of ± 4 symbols.

By way of non-limiting example, a MAC frame may include a fixed outer encapsulator and a variable inner message payload, and may include one or more of the following fields:

field(s)	Type (B)	Number of bits	Description of the invention
				SourceMacAddress	Integer without sign	28	Address of transmission node
MsgType	Integer without sign	4	Type of message attached
				MsgPayload	Variable	≤68	Message payload

The length of the message payload may depend on the type of message. As an example, for the longest message type of 68 bits, the maximum MAC frame length of 28+4+68 is 100 bits. To account for higher requirements on the data, extended margins of up to 127 bits or more may be implemented.

In some embodiments, the MAC frame may include one or more of the following message types: (i) MsgType0x 0-INFO (46 bits), where the exemplary embodiments are described below:

(ii) MsgType0x 1-SENSOR _ DATA (36 bits), where the exemplary embodiments are described below:

in the event that a previous transmission was not received, a copy of the previous SensorRecord may be included in the message for redundancy. The SensorRecord may be defined as:

and (iii) MsgType0 xF-TEST (40 bits), wherein exemplary embodiments are described below:

additional message types may be configured or reserved for future use/expansion.

As discussed above, multiple gateways may receive signals transmitted by one or more nodes. The gateway may include an intermediary device that bridges a wireless network (including one or more nodes) to a wired network (including an SDR server). The gateway may receive signals or radio packets from the nodes including one or more sensor reports and may forward these to a server (sometimes referred to as a cloud server), e.g., over the internet. In some embodiments, the radio packet is not demodulated at the gateway. The signal processing of the gateway may stop when the signal is down-sampled to blocks of I and Q baseband samples. The gateway may include a network-enabled Single Board Computer (SBC), such as a Gateway Interface Processor (GIP). The gateway may run embedded Linux or another operating system. The gateway may be connected to the SDR receiver directly or via a network connection.

In some embodiments, the gateway includes a plurality of modules that may be implemented in hardware or software executing on the hardware of the gateway. Some of these modules may provide functionality including one or more of the following: (i) interfacing with an SDR receiver, (ii) down-sampling a fully received HF band to each baseband signal of each channel, (iii) assigning each baseband signal according to channel and time slot, producing "baseband blocks", (iv) calculating a thumbnail spectrogram for each block, (v) labeling and time-stamping each baseband block, attaching the spectrogram, and uploading it to an SDR server, and (vi) interfacing with a GPS module for geolocation and timing reference, and/or (vii) reading/writing profiles. Some of these modules may provide (viii) a serial console for configuration, manufacturing testing and debugging, (ix) a web server control panel for configuration and monitoring and/or event logging. Some modules may contain or be implemented using a programming or scripting language (e.g., Python or C). Fig. 2F and 2G are block diagrams of embodiments of gateways for receiving and processing node transmissions. On the signal processing front side, the gateway may contain a library, such as the GNU radio library. On the networking front side, the gateway may contain libraries of XML, HTTP, SSL, JSON, etc.

The gateway may include an SDR interface for communicating with and/or controlling an SDR on a connected computing device or remote server. The SDR interface may comprise, for example, an ethernet interface. In some embodiments, the SDR interface may comprise a graphical interface. The graphical interface may be used to control an SDR written in C and/or Qt running on Linux, for example. The SDR interface may operate or support one or more network protocols such as (i) TCP sockets for controlling the SDR, e.g., using Amateur Station Control Protocol (ASCP), and (ii) UDP sockets for low-overhead transmission of sample data, which may be in a custom format. The gateway or SDR interface may include a DHCP client for obtaining an IP address and may include a device discovery mechanism using a UDP protocol sometimes referred to as SNDP.

In some embodiments, the gateway samples the HF band, which may include a predetermined number of sub-channels (e.g., 100 sub-channels). The gateway may isolate each subchannel for processing. The process of band pass filtering, decimation, and down converting the signal to baseband at the same time is sometimes referred to as down sampling. Timing synchronization for determining slot boundaries may be derived from a GPS source. As an example, if a node transmits information nominally comprising 32 bytes encoded at a rate of 1/2, modulated at 50 baud, occupying 800Hz of bandwidth, and sampled at 2kSps at 16 bits per quadrant, the baseband block to be uploaded may occupy approximately 22 kilobytes.

The gateway may include a web service client to communicate with the SDR server as a client. Web service clients may use a Web services remote procedure call (PRC) framework (e.g., SOAP or REST). Web service requests and responses can be built on top of HTTP. In some embodiments where the gateway sends medium-sized data blocks to the server (e.g., -22 kilobytes), the web service design may benefit from using a binary encoding format.

The gateway may transmit the samples of the modulated signal to the SDR server over the network. These samples may sometimes be referred to as gateway-to-cloud (G2C) messages. In a given timeslot, the gateway may send a block of received sample data to the SDR server. The gateway may establish a TCP connection on a port, such as port 8081, to send the message. In some implementations, the gateway can send the message using a representational state transfer (REST) based web service. The sequence number of the gateway may be defined as its ethernet MAC address. As an example, the G2C message may have the following message format:

an SDR server or cloud server may receive samples of a modulated signal (sometimes referred to as sample blocks or G2C messages) from one or more gateways in a network. In some embodiments, the SDR server may use the following database record format. The SDR server may store the received G2C message in such a format until the message can be paired with available copies from other gateways and SIMO processed.

In some embodiments, the format of the processed sample block (e.g., after SIMO processing) may look like:

the SDR server may process the sample block or G2C message and may deposit the resulting data record in a database for use by end-user applications. As an example, the decoded sensor report extracted from the processed sample block may include the following:

the SDR server may comprise a virtual server running Linux, Windows, or another operating system. In some embodiments, the SDR server may be divided among multiple servers, such as utilization of cloud database services for the back-end and lightweight application servers for the front-end, for example. This implementation can be scaled to multiple instances of the same application running on different machines and even at different URLs to support, for example, multiple SDR servers. Each instance may communicate with the same database server and specify which nodes are associated with that particular instance. The SDR server application task may be implemented in a language such as C, Python or Java.

An SDR server may comprise a module implemented in hardware or software executing on hardware. Certain modules may provide functionality such as (i) providing a web service to receive blocks of baseband samples from a gateway, (ii) processing blocks of samples to extract sample records and spectrogram data, (iii) writing decoded sample records and spectrograms to a history database, (iv) providing a web service to allow end-user applications to access the history database, (v) providing a web server control panel for configuration and monitoring, and (vi) performing event logging for debugging/diagnostics. As an example, fig. 2H depicts a block diagram of one embodiment of an SDR server.

The SDR server may be configured to perform important signal processing. The SDR server may be configured via SDR software, applications and/or custom code. The SDR server may provide various signal processing functions including SIMO antenna diversity combining, FSK demodulation, discrete fourier transform implementation to account for tones, coherent demodulated carrier phase recovery, and/or timing recovery. Using a small sample duration, timing synchronization can be obtained without an explicit point sequence preamble. A node may ensure a sufficient number of transitions in data by applying a scrambling sequence to the data at the transmitter. The SDR server may restore bit synchronization when aggregated for each bit duration by finding a bit phase that maximizes the power in each "frequency bucket" of the DFT. The SDR server may also perform FEC decoding.

The end user may access some portion of the sensor data recovered at the SDR server. One or more end-user applications may retrieve sensor data from a sensor history repository of the SDR server and present it to the end-user in a graphical format. The end-user application may perform any one or more of the following operations: (i) interacting with a sensor history service to retrieve sensor data, (ii) providing a sensor geographical view showing each sensor as a sign on a scrolling map with a sensor reading in, for example, a pop-up box, (iii) providing a sensor table view showing each sensor as a row with, for example, the most recent report, (iv) providing a history table view showing each sensor report as a row, for example, of a single sensor or a group of selected sensors, and (v) providing a history graphical view that graphically represents all sensor values of one or more selected sensors, for example, over a selected period of time. FIG. 2I depicts one embodiment of a data flow diagram for an end-user application.

The end-user application may monitor new sensor reports and generate an alert, for example, if: (a) sensor values outside of a specified range, and/or (b) sensor failure to report before alarm timeout expires. The end-user applications may include standalone desktop applications, browser-based web applications, or standalone mobile applications.

Referring to fig. 2J, one embodiment of a flow chart of a method for a distributed radio communication network is depicted. The method can include receiving, by each of the first gateway and the second gateway, a modulated signal (501), respectively, the modulated signal including at least a portion of data from a first node of the plurality of geographically-dispersed nodes. The modulated signal may be wirelessly transmitted as a Radio Frequency (RF) signal from the first node. Data may be gathered or generated by a first node at a first location. The server may receive samples of the modulated signal from the first gateway and the second gateway (503). The server may subtract the interference signal from the samples of the modulated signal (505). The server may time synchronize samples of the modulated signals received from the first gateway and the second gateway for combination of the samples (507). The server may be configured by Software Defined Radio (SDR) software to perform processing of the separately received samples of the modulated signal to recover the data (509). The processing may include demodulation of the modulated signal recovered from the samples.

Referring to (501), each of a plurality of gateways may respectively receive a modulated signal including at least a portion of data from a first node of a plurality of geographically dispersed nodes. The plurality of gateways may include a first gateway and a second gateway. Data may be gathered or generated by a first node at a first location. For example, the data may include measurements made by the node, including environmental attributes (e.g., humidity or temperature) or detection of events, e.g., to trigger an alarm, notification, or event log. A node may include data in one or more signals that include one or more packets, frames, datagrams or messages for transmission. The node may add MAC level control information (e.g., a point sequence, a synchronization word, or a protocol identifier) to each signal or packet.

The node may perform Forward Error Correction (FEC) coding to protect each signal or packet from errors, for example, using a rate 1/2 (k-32) convolutional code. The node may modulate code bits in the signal using, for example, continuous phase 4-FSK or 16-FSK, although various other modulation schemes may be implemented. A node may determine a time slot and/or frequency to transmit a modulated signal. This determination may be based at least in part on one or more of the following: location of the receiving gateway, distance from the receiving gateway, terrain, time of day, season, weather, antenna type, and/or transmission mode supported by the receiving gateway. The modulated signal may be wirelessly transmitted as a Radio Frequency (RF) signal from the first node. The first node may transmit low power RF signals between 3 and 30 megahertz (MHz), within the HF band or another band/range. The first node may transmit the RF signal to at least one of the first gateway and the second gateway over a transmission path greater than 10 kilometers (e.g., 50km, 300km, or 600 km).

Each of the multiple gateways may be located at a different location and may include a particular type of antenna for receiving various types of signals and/or transmissions. The modulated signal may be wirelessly transmitted as a Radio Frequency (RF) signal from the first node. Each of the first gateway and the second gateway may receive the modulated signal transmitted as an RF signal via a direct path from the first node, a ground wave path, or ionospheric reflections (e.g., NVIS and long-sky wave). The first gateway and the second gateway may receive the modulated signal transmitted as an RF signal via at least two of: a direct path from the first node, a ground wave path, or an ionospheric reflection. In some embodiments, at least one of the first gateway and the second gateway receives one of the RF signals reflected from the ionosphere of the earth.

One or more gateways may be configured to include a set of distributed antennas. The antennas on each gateway may be selected and/or configured to give preference to one or the other type of propagation. These distributed antennas may collect different signals from multiple paths or propagation modes from one or more locations for aggregation/processing at a predetermined central location. The distributed antennas may be configured to support antenna diversity and/or beamforming strategies. One or both of the first and second gateways may receive a particular signal transmission from a node. In some cases, the signal may be blocked, too weak, or outweighed by noise received at a particular gateway. For example, based on daily propagation, some node transmissions may be received by one gateway while other node transmissions are received by two gateways.

Each gateway may sample the received signal. Each gateway may perform sampling on signals detected in the HF band, which may include a predetermined number of sub-channels. The gateway may isolate each subchannel for processing. The received signal may be downconverted to a baseband frequency and sampled at each respective gateway. Each gateway may perform down-sampling including one or more steps of bandpass filtering, decimation, and down-conversion of the signal to baseband. Each gateway may interface with a GPS module for geographic location and timing reference. Each gateway may perform timing synchronization to determine slot boundaries, for example, using timing information from a GPS source.

Each gateway may allocate each baseband signal according to a channel and/or time slot to produce a "baseband block. In some embodiments, the gateway may compute a thumbnail spectrogram for each block. The gateway may tag and timestamp each baseband block. The gateway may attach a spectrogram and may upload each block to the SDR server. The radio signals or packets may not be demodulated at the gateway. The signal processing of the gateway may stop to blocks of I and Q baseband samples, for example, when the signal is downsampled.

One or both gateways may communicate samples of the modulated signal to the SDR server over the network. These samples may sometimes be referred to as gateway-to-cloud (G2C) messages or sample blocks. In a given timeslot, the gateway may send a block of received sample data to the SDR server. The gateway may establish a TCP connection on the port to send the sample. In some implementations, the gateway can send the samples using a representational state transfer (REST) based web service. One or both gateways may compress the modulated signals received by the respective gateways and pass the compressed modulated signals to a central location for further processing. For example, the gateway may compress one or more samples of the modulated signal before transmission to the SDR server over the network.

Referring now to (503), a server may receive samples of a modulated signal from a first gateway and a second gateway. The SDR server may receive a modulated signal from the first gateway and the second gateway. The SDR server may receive modulated signals from one or both of the first gateway and the second gateway, respectively. The SDR server may receive separately samples of the modulated signal from each gateway. The first gateway, the second gateway, and the server may be connected by a communication network (e.g., a wide area network or the internet). The SDR server may receive samples from each gateway in different time slots, such as the time slot assigned to each gateway. In some implementations, the SDR server may store the received samples in a database record format (such as the format described above). The SDR server may store the received samples in such a format until the samples can be paired with available copies from other gateways. The SDR server may store the received samples in this format until the samples can be processed by SIMO/MIMO.

Referring now to (505), the server may subtract the interference signal from the sample of the modulated signal. The server may subtract the interference signal from the modulated signal received by one or both gateways. The interfering signal may be identified, for example, by connecting different antennas (e.g., vertically and horizontally polarized antennas) to the gateway or to different gateways. One type of antenna may be easier to acquire node signals than another type of antenna. Another type of antenna may be prone to acquiring noise or interference signals, for example, which the first type of antenna may pick up in addition to the node signal.

The SDR server may receive a sample from a gateway (e.g., a first gateway) that includes a desired node signal plus an interfering signal and a sample from another gateway (e.g., a second gateway) that includes an interfering signal. In some embodiments, the SDR server may receive a sample including a desired node signal plus an interfering signal from a first antenna (e.g., of a first gateway) and a sample including an interfering signal from another antenna (e.g., of the first gateway). The SDR server may perform interference suppression and/or noise filtering. The SDR server may subtract the samples comprising the interfering signal from the samples comprising the desired signal plus the interfering signal. The SDR server may extract the desired signal sample based on the subtraction and may send the desired signal sample to a demodulation process where the sample may be processed as if the sample were received without an interfering signal.

Referring now to (507), the server may time synchronize samples of the modulated signals received from the first gateway and the second gateway for combination of the samples. The SDR server may forward samples of the received signal to an antenna diversity module on the SDR server, where they may be time synchronized and combined, for example, to improve signal-to-noise ratio (SNR) and/or other parameters. The SDR server may use local GPS information or other timing information to synchronize the sample time. The samples may be added together or otherwise combined without regard to the signal received over a distributed set of antennas/gateways. The SDR server may drop or remove any redundant or duplicate samples. The SDR server may send the combined samples to a demodulation module of the SDR server where the combined samples may be processed as if the samples came from a single path. Thus, demodulation and other processing techniques (e.g., SIMO/MIMO) can be performed as if the set of gateways and SDR servers were a non-distributed system.

In some embodiments, different nodes may each transmit space-time coded signals received by the first and second gateways. Each gateway may send samples to the MIMO/SIMO module of the SDR server. The MIMO/SIMO module may separate, group, or combine samples based on space-time coding to improve signal transmission speed/throughput, SNR, or other parameters of the received signal.

Referring now to (509), the server may be configured by Software Defined Radio (SDR) software to perform processing on samples of separately received modulated signals to recover data. The server may be configured by the SDF software to perform any of the processes in (503), (505), and/or (507). The processing may include demodulation of the modulated signals received from one or both gateways. The processing may include demodulation of the modulated signals received by the first and/or second gateways. The processing may include demodulation of the modulated signal recovered from the samples.

The SDR server may be configured to perform important signal processing. The SDR server may be configured to perform signal processing steps deferred from the gateway. The SDR server may be configured to perform centralized signal processing for multiple gateways by offloading common or computationally important processing from each gateway. The SDR server may be configured to perform signal processing of a combined set of signals received from a distributed set of antennas/gateways, for example to benefit from gateway/antenna "redundancy", diversity processing, and/or interference suppression. Thus, the signal-to-noise ratio (SNR) of a node-to-gateway wireless link may be improved by combining signals received at multiple locations. The SNR may be improved by combining signals received via different propagation paths and/or different propagation modes.

The SDR server may perform processing of a modulated signal comprising at least one of: signal filtering, interference suppression, decompression, encryption, decryption, Forward Error Correction (FEC), encoding, decoding, beamforming, and antenna diversity processing. For example, the SDR server may decompress the compressed samples from the gateway before combining the samples for further processing. The server may be configured by the SDR software to perform processes including at least one of Single Input Multiple Output (SIMO) and Multiple Input Multiple Output (MIMO) processes. The SDR server may provide various signal processing functions including SIMO antenna diversity combining, FSK demodulation, discrete fourier transforms to account for embedded tones, coherent demodulated carrier phase recovery, and/or timing recovery.

The SDR server may include or provide a web service to receive the baseband sample blocks from the gateway. The SDR server may process the samples and may deposit the resulting data records in a database for use by end-user applications. The sample block may be processed to extract a sample record and/or spectrogram data. As previously discussed, the SDR server or MIMO/SIMO processing module may output a data record in a particular format (e.g., after SIMO processing) for storage in a database. The SDR server may extract decoded sensor reports from the processed sample blocks. The SDR server may write the decoded sample records and spectrogram to a history database of the SDR server.

In some embodiments, an SDR server may perform event logging for debugging or diagnostics and may provide a web server control panel for configuration and monitoring. The SDR server may provide a web service to allow end-user applications to access the historical database. An end user may access some portion of the sensor data recovered at the SDR server through one or more end user applications. The end-user application may retrieve the sensor data from the sensor history repository of the SDR server and present it to the end-user in a graphical format.

It will be appreciated that the system described above may provide multiple components of any one or each of those components, and that those components may be provided on separate machines or, in some embodiments, on multiple machines in a distributed system. Further, the systems and methods described above may be provided as one or more computer-readable programs or executable instructions embodied on or in one or more articles of manufacture. The article of manufacture may be a floppy disk, hard disk, CD-ROM, flash memory card, PROM, RAM, ROM, or tape. Generally, the computer readable program may be implemented in any programming language (e.g., LISP, PERL, C + +, C #, PROLOG) or in any bytecode language (e.g., JAVA). Software programs or executable instructions may be stored on or in one or more articles of manufacture as object code.

While the foregoing written description of the invention enables one of ordinary skill to make and use what is presently considered to be the best mode thereof, those of ordinary skill will understand and appreciate the existence of variations, combinations, and equivalents of the specific embodiments, methods, and examples herein. The present invention should therefore not be limited by the embodiments, methods and examples described above, but by all embodiments and methods within the scope and spirit of the invention.

Claims (22)

1. A system for providing a distributed radio communications network, the system comprising:

a first gateway that receives a first at least a portion of a modulated signal of data wirelessly transmitted from a first node of a plurality of geographically dispersed nodes, performs analog-to-digital (A/D) conversion to generate a first sample of the first at least a portion of the modulated signal, and transmits the first sample to a server;

a second gateway that receives a second at least a portion of a modulated signal of data wirelessly transmitted from the first node, performs A/D conversion to generate a second sample of the second at least a portion of the modulated signal, and transmits the second sample to the server; and

the server receiving the first samples transmitted from the first gateway and the second samples transmitted from the second gateway, the server configured by Software Defined Radio (SDR) software to combine the received first and second samples to recover a modulated signal of the data, and to demodulate the recovered modulated signal to recover the data.

2. The system of claim 1, wherein the first gateway compresses the first sample and communicates the compressed first sample to the server.

3. The system of claim 1, wherein the server is configured by the SDR software to perform a process comprising at least one of a single-input multiple-output (SIMO) and a multiple-input multiple-output (MIMO) process.

4. The system of claim 1, wherein the first gateway, the second gateway, and the server are connected by a communication network.

5. The system of claim 1, wherein at least one of the first gateway and the second gateway receives one of the modulated signals reflected from the ionosphere.

6. The system of claim 1, wherein the modulated signal comprises a low power Radio Frequency (RF) signal between 3 and 30 megahertz (MHz) that is transmitted to at least one of the first gateway and the second gateway over a transmission path greater than 10 kilometers.

7. The system of claim 1, wherein the server performing processing of the received first and second samples comprises at least one of: signal filtering, interference suppression, decompression, encryption, decryption, Forward Error Correction (FEC), encoding, decoding, beamforming, and antenna diversity processing.

8. The system of claim 1, wherein the server time synchronizes first and second samples received from the first and second gateways, respectively, for combining the first and second samples.

9. The system of claim 1, wherein the server removes interfering signals from the first and second samples received from the first and second gateways, respectively.

10. The system of claim 1, wherein the first gateway and the second gateway receive first and second at least a portion of the modulated signal transmitted as a Radio Frequency (RF) signal via at least two of: a direct path from the first node, a ground wave path, and an ionospheric reflection.

11. The system of claim 1, wherein at least one of the first gateway and the second gateway receives one of a modulated signal wirelessly transmitted from the first node at a Very High Frequency (VHF) or an Ultra High Frequency (UHF).

12. A method for providing a distributed radio communications network, comprising:

receiving, by a first gateway, a first at least a portion of a modulated signal of wirelessly transmitted data from a first node of a plurality of geographically dispersed nodes;

performing analog-to-digital (A/D) conversion by a first gateway to generate first samples of a first at least a portion of the modulated signal;

transmitting the first sample to a server through a first gateway;

receiving, by a second gateway, a second at least a portion of a modulated signal of wirelessly transmitted data from the first node;

performing, by a second gateway, a/D conversion to generate second samples of a second at least a portion of the modulated signal;

transmitting the second sample to the server through a second gateway;

receiving, by the server, the first sample transmitted from the first gateway and the second sample transmitted from the second gateway;

combining, by the server, the received first and second samples to recover the modulated signal as configured by Software Defined Radio (SDR) software; and

demodulating, by the server, the recovered modulated signal to recover the data.

13. The method of claim 12, further comprising compressing, by the first gateway, the first sample and communicating the compressed first sample to the server.

14. The method of claim 12, further comprising performing, by the server, processing comprising at least one of Single Input Multiple Output (SIMO) and Multiple Input Multiple Output (MIMO) processing.

15. The method of claim 12, further comprising connecting the first gateway, the second gateway, and the server via a communication network.

16. The method of claim 12, comprising receiving, by at least one of the first gateway and the second gateway, one of the modulated signals reflected from the ionosphere.

17. The method of claim 12, wherein the modulated signal comprises a low power RF signal between 3 and 30 megahertz (MHz) that is transmitted to at least one of the first gateway and the second gateway over a transmission path greater than 10 kilometers.

18. The method of claim 12, further comprising performing, by the server, processing comprising at least one of: signal filtering, interference suppression, decompression, encryption, decryption, Forward Error Correction (FEC), encoding, decoding, beamforming, and antenna diversity processing.

19. The method of claim 12, further comprising time synchronizing, by the server, the first and second samples received from the first and second gateways, respectively, for combining the first and second samples.

20. The method of claim 12, further comprising removing, by the server, interfering signals from the first and second samples received from the first and second gateways, respectively.

21. The method of claim 12, further comprising receiving, by the first gateway and the second gateway, the first and second at least a portion of the modulated signal transmitted as a Radio Frequency (RF) signal via at least two of: a direct path from the first node, a ground wave path, and an ionospheric reflection.

22. The method of claim 12, comprising receiving, by at least one of the first gateway and the second gateway, one of the modulated signals wirelessly transmitted from the first node at a Very High Frequency (VHF) or an Ultra High Frequency (UHF).