WiSE – a satellite-based system for remote monitoring

SUMMARY Recent technological advancements in sensors, processors and communications technology make it viable to per- form digital acquisition of environmental data from remote locations. Declining costs and miniaturisation of electronics and sensors have enabled design of systems for intelligent remote monitoring. These advances pave the way for new tools to support ﬁ eld work by virtually extending researchers ’ reach to the ﬁ eld study area from the comfort of their of ﬁ ces. The Wireless Internet Sensing Environment project developed an architecture providing control and retrieval of data from networked sensors and cameras at a remote location using Internet backhaul. Satellite connectivity enabled this equipment to be deployed to remote locations to support an ecological application. This paper describes architecture and innovative design features for this challenging problem space, including motion event detection, power management and a method to upload collected data. © 2016 The Authors. International Journal of Satellite Communications and Networking published by John Wiley & Sons Ltd.


INTRODUCTION
Harsh conditions and/or distance to transport infrastructure can make it difficult/impossible to visit sites that are remote, resulting in a desire for remote data backhaul and autonomous system operation. The technological advances in sensor and communication technology have enabled development of long-term intelligent monitoring systems. This technology extends to a range of application scenarios [1], including surveillance, emergency communications, support and environmental monitoring. This paper focuses on an emerging application to support long-term environmental monitoring using cameras and sensor networks. This can be used in ecological research monitoring natural resources, biodiversity and ecological and social sustainability [2][3][4]. Many areas of interest to this type of research are geographically isolated and require systems able to operate unattended for prolonged periods. The absence of local communications infrastructure motivates the use of satellite communications services.
The architecture presented in this paper was developed for the WiSE project [5] at the University of Aberdeen, Scotland, UK. The system supports long-term monitoring of sporadic events. While it is crucial, the system could report all events of interest, and the system must also carefully manage its use of power resources to ensure availability over a long-term deployment. A commercial-off-the-shelf broadband satellite terminal provides backhaul communications to locations where there is little or no other communications, although the platform can also incorporate general packet radio service/Global System for Mobile communication [6,7] where there is coverage by commercial mobile access networks. A wired/wireless Local Area Networks connects motion and networked environmental sensors.
The main features of the Wireless Internet Sensing Environment (WISE) platform are as follows: (1) two-way communication, providing event-based and scheduled environmental sensing; (2) autonomous operation in a harsh environment with power constraints; and (3) an extensible architecture that can be adapted to the needs of each measurement campaign. In a significant advancement over existing methods, our system can record, backhaul and display motion-triggered imagery as well as stream live video to remote researchers using the Internet.
An example application for the WISE system is the study of animal behaviour in the wild. This is currently often performed using camera traps, where each trap uses a sensor to activate a camera when a moving target (an animal) is detected [8]. Such traps require frequent site visits [9] to retrieve imagery from each camera and possibly to tune the position/sensitivity of the camera (or its sensors).
A range of challenges and requirements exist for other applications, from video surveillance in harsh environments [10] to habitat monitoring [11]. Solar power may be used to make the system independent of local power. Self-powered satellite backhaul systems have been used for various applications, including re-establishing communication services after a disaster (e.g. Wireless infrastructure over satellite for emergency communications [12]). Examples of solar-powered satellite backhaul technology applied to wildlife monitoring include a system monitoring seabird nests, reporting light and temperature data [13], a polar bear camera [14] and the BearCam camera system [15]. The latter enabled daily video streaming from a site near the Arctic Circle to a base station, where the imagery was collected and analysed. However, even though power consumption was managed, by streaming only for 4 h, the collected imagery from BearCam was often devoid of bears [15]. Similarly, image-based camera traps have been often found to capture images that do not contain a subject, primarily because of false triggering of the sensors. The desire to eliminate useless imagery before it incurs storage, transmission or analysis costs [16] was the key driver in our system development. WISE addresses these drawbacks by enabling remote access to imagery and sensor data and by automating imagery selection.
The remainder of the paper is structured as follows: Section 2 provides a system overview and describes the architecture and deployment challenges. The results and measurements are described in Section 3. Finally, Section 4 provides a conclusion for this work.

SYSTEM OVERVIEW AND ARCHITECTURE
The WiSE platform combines remote access to imagery and sensor data while optimising utilisation of the deployed resources (power, storage and transmission costs). The self-powered architecture is designed to be flexible during its year-long deployment. Embedding 'intelligence' in the remote system not only allows intelligent use of resources but also reduces the burden on analysis by researchers and increases the operational life of the system, by avoiding wasteful transmission of pictures when these include no valuable information to the user [5]. The complete infrastructure can be transported in a pick-up truck, and in our tests, the entire system may be deployed in approximately 20 man-hours. The most time-consuming task is erecting and securing the satellite broadband antenna and the solar panels so that they can withstand the strong gusts expected at a remote deployment site.
The first deployment of the WiSE system was in the Scottish Cairngorms National Park ( Figure 1). The system architecture ( Figure 2) comprises a network of sensors and multiple cameras connected through a Gateway. The Gateway includes a System Controller [17] that monitors and controls power to the subsystems, a Satellite Indoor Unit (IDU) and on-site Local Area Networks equipment. A network of sensor nodes monitors the area in the vicinity of the Gateway. The sensors may be wired or connected via low-power wireless to monitor the environment, perform motion detection and so on. Sensor-triggered messages and imagery are stored in a data repository, together with logged contextual information used to detect events of interest (e.g. animal movement). The repository is implemented as an SQLite database [18] in the System Controller. When a sensor node detects movement within its local vicinity (or changes in other parameters, e.g. local temperature), it sends a trigger message to enable intelligent image capture. In a typical application, a processor queries the repository in real-time using a set of rules that automates the decision about when to start recording video or still images by each Internet protocol (IP)-based camera (cameras may be remote from the Gateway, powered over CAT-5 Unshielded twisted pair (UTP). Imagery from each camera is captured as two simultaneous video streams with MJPEG and H.264 coding. Sensor nodes can also have on-board cameras. Captured imagery can be automatically analysed by our system to detect the presence of a target of interest in the scene.
The major system components and their features are described in the following sub-sections.

System Controller
The System Controller uses the Raspberry Pi [17] platform ( Figure 3). This is responsible for overall control of the Gateway: (1) processing of messages from the sensor nodes; (2) activation and de-activation of cameras and satellite equipment; and (3) storage and backhaul of imagery and sensor data. The general purpose input output interface of the Raspberry Pi was used, supplemented by eight analogue channels input/output pins, using an analog-to-digital converter (ADC) board v2 [19]. Four analogue channels measured the internal (housing) and external (ambient) temperature and battery voltages for the two battery banks. Another two channels enabled power control for the Ethernet switch and satellite terminal equipment.
The software was written in the Python programming language, supporting widely available libraries, for example, for hardware interfacing to the Raspberry Pi and control of the IP camera through image and video capture commands.

Power system for the WISE gateway
The WISE system needed to be self-powered. The power system therefore comprised batteries and power source and control algorithms for power management.
An energy harvesting technique was needed to provide power, such as solar panels and/or a small wind turbine [14]. For the application considered, a wind turbine would need to be located away from the terminal to avoid disturbing wildlife. In contrast, solar panels had no moving parts and were not thought to pose any distraction to wildlife. Another advantage was that solar panels were expected to provide a more predictable and a consistent source of energy.
The system power budget is summarised in Table I and requires approximately 60 W. The design of the solar panel was based on a required maximum load imposed by satellite operation (to be sustained for 12 h each day). The IDU, with typical (clear-sky) conditions, was measured to have a total direct current (DC) power consumption of 24 W for transmit and 20 W for receive. The total load for operating the WiSE system was calculated as 1.44 kWh/day (5 A * 12 W * 24 h). The required load was thus 0.72 kWh/day. Table II indicates the solar panel area required to sustain this load for a mountainous region in the Scottish Highlands. This panel area needed to sustain the required load varied by month (depending on average sunlight). A panel area of 3.2 m 2 was sufficient for continuous use of 12 h over 75% of the  year, but required power management in the winter months, where charging could fall to a few hours a day. The System Controller provided this management of battery power to enable sustained operation over the duration of the intended deployment. Power management is essential during the winter months when solar panels receive less daylight and may be prone to snow coverage. The final design combined two independent power supplies (known as Battery 'A' and 'B'). Each used an Axitec 235 W photovoltaic solar panel [20]. A maximum power point tracking (MPPT) [21] method was used to capture solar power with the highest efficiency. The MPPT controller accepts input voltages from the solar panel of up to 40 V and converts this to 13.8 V for charging the battery. This results in high average conversion efficiency. Each supply used a bank of 12-V gel batteries (with 70 Ah capacity [22]) for energy storage. The redundancy offered by two independent units enabled the System Controller to automatically switch to using only one panel in the event of a failure. The Schottky diode shown in Figure 4 provides protection against power supply reversal, when one bank of batteries is depleted.   imagery. The satellite IDU (and power to Outdoor Unit (ODU)) and the Ethernet switch (providing power to the IP camera(s)) consume the most power (Table I).
To manage long-term use, the System Controller needs to dynamically trade the quality of image/video capture and the use of communications resource against the power budget. For instance, it may use image processing algorithms to perform increasingly stringent selection of imagery of interest, based on stored battery energy and power consumption for communication tasks (real-time streaming, remote control, access to data or background upload of high-quality imagery).
Control policies ( Figure 5) were implemented to assess the stored battery energy each hour and to determine the conditions under which the IDU and other devices would be enabled if this fell below a minimum threshold. For example, if a low-power level was reported for Battery B, an IP camera could change to be powered from Battery A to continue operation. In power-limited conditions, the power could be further conserved by activating the satellite IDU only at pre-scheduled intervals. In this mode, a function allowed an operator to override this to enable emergency remote system access when the Gateway performed its scheduled contact with the central site.

Satellite link
The Gateway uses a commercial two-way IP broadband system by Avanti (London, UK) [23] using the Hylas 1 satellite geostationary at 33.5 0 W. Communications was in the Ka-band broadband with an uplink frequency range of 27.5-29.5 GHz and downlink frequency range of 19.7-20.2 GHz. In the current system, this used a Hughes Network Systems IPOS terminal, the HN9200 IDU, with dual Ka-/Ku-band satellite DVB-S/S2 modem. The IDU provides a UTP Ethernet interface to the Gateway Ethernet switch. It was connected by a pair of coaxial cables to an ODU containing a 2-W solid state power amplifier. A 75-cm antenna was used (the smaller size of a Ka-Band terminal compared with Ku-Band offered less wind resistance in an exposed site). This IDU was designed to operate from a mains supply using a custom-built DC power supply controlled by the System Controller.
The communications architecture adopts a multi-tiered structure ( Figure 6) using a two-way IP communications service. This supports four categories of communications interaction (in decreasing order of the number of sessions): 1. Telemetry to monitor the Gateway. 2. Scheduled bulk data upload of imagery and captured data. 3. On-demand live video streaming of imagery. 4. Remote system Access.
In common with other broadband access systems, the satellite terminal provided an IP network interface and the primary transport protocol used in the project was Transmission Control Protocol (TCP)the most widely used Internet transport. This protocol was chosen, rather than UDP, because of its ability to provide robust reliable transmission in the face of occasional loss or congestion. At first sight, this would seem an odd choice, because much research has noted the deficiencies of TCP when there are long path delays (as in geostationary satellite system), especially when there can be packet loss. However, our experiments did not detect performance problemslargely because the satellite system employed a split performance enhancing proxy (PEP), which successfully mitigated the performance issues of using TCP. It was also expected that the PEP was able to interact positively with the bandwidth on demand subsystem, because inbound performance was significantly lower when TCP was not used. This had implications on the protocols used over the transportthis drove a preference for security methods over TCP (e.g. Transport Layer Security, TLS, and services such as Secure Shell, Secure file transfer protocol)rather than introduce IPsec or a UDP-based virtual private network. The benefits of using standard methods across all components of WiSE therefore greatly outweighed the cost and complexity of developing special-purpose methods.

Telemetry.
A WISE site contacts the central site according to a schedule to verify that it is operational and to allow the central site to receive telemetry data to monitor the remote system health (e.g. system uptime, battery capacity, temperature and notification of key sensor data).
2.3.2. Bulk data upload. Captured data (imagery, sensory data and system log files) from the Gateway at the remote site is automatically pulled from the repository (SQLite database) in the System Controller to a Triplestore database [24] at the central site. This data is collected as a single scheduled file upload that is transferred using File Transfer Protocol (FTP or secure FTP). After each bulk transfer, this data is populated to the Triplestore database. Imagery is typically analysed by the System Controller to discard items that do not contain a relevant target (false positive motion triggers), saving storage and transmission cost. To save satellite transmission cost, only thumbnails of the retained images and videos are routinely transferred together with their metadata (information about motion sensor activation, temperature and other environmental data at the time of capture). This metadata is also stored in the Triplestore. If required, the corresponding larger full-resolution images and extended video coverage may be selected and added to a subsequent bulk data upload.
The metadata provides evidence to validate correct working of the sensors and maintains a record of the remote system decisions, allowing these to be reviewed and helps to suggest improvements to algorithms. All collected data can be retrieved via the Internet, for instance, to plot temperature variation; explore trends in activity at the site or to enable new ways to exploit the context between sensors not previously envisaged.

Video streaming.
A commercial satellite broadband service had sufficient uplink capacity to enable streaming on-demand live video to be streamed from the IP camera (1.5-2 Mbps) when the IDU was enabled, although these consumed satellite's service capacity (especially data volume), and its use needed to be limited in winter months to avoid depleting the battery. The imagery could be streamed live over IP across the Internet to users. The solar-powered power supply developed in WISE has been successfully used for other solar-powered satellite terminals to offer live streaming services (e.g. [14]).
An advanced satellite service could allow send a request to the satellite network control centre to enable a higher inbound service rate (uplink from the WISE terminal) or/and an increased volume allowance, or to enable the uplink video to be routed by a satellite multicast gateway and re-broadcast over the outbound satellite service as an IP multicast stream available that could be simultaneously received by authorised satellite users. Both these advanced mechanisms were piloted in the Digital Advanced Rural Network Project [25], where they were implemented as an over-the-top control real-time service using IP-based signalling to make requests to the network operator satellite service platform.

2.3.4.
Remote system configuration. The system provided two-way communications coupled with an IP-based system design, in which individual components of the gateway could be directly accessed via IP protocols. This allows an operator to login to the remote systems and for the remote software to be reconfigured after deployment or software updates to be provided.
The resultant system provided a flexible platform allowing experimentation with both new technologies and to customise the algorithms for data collection in the System Controller. Access was enabled to the system to change parameters, or change or replace an existing algorithm with one optimised in some way for better performance (e.g. updating the motion detection or algorithms to use the X-band radar, discussed in Section 2.4). Remote access to devices (e.g. an IP camera or sensor node) provided the first line of off-site investigation after a malfunction to resolve this issue in advance of a field trip.

WiSE sensor nodes
The sensor node design used an AVR RFA1 micro-controller platform [26] connecting a temperature sensor, passive infrared (PIR) and X-band radar motion detectors [27]. Each sensor node was designed to use wireless communication to send status and trigger messages to the System Controller. The sensor nodes employed Contiki, a real-time OS running for the AVR platform. An external highcapacity battery was used to power each sensor. The use of battery power and wireless communication significantly reduced installation time at a remote site and enable easy repositioning of sensors to explore different motion triggering strategies. To ensure a long life in the field, low standby current consumption was required. This was measured as 4.1 mA, rising to 18.6 mA during transmission, allowing operation of the unit for extended periods using only batteries.
The sensor node includes a radio interface using the IPv6 low power wireless personal area network (6LoWPAN) [28,29], designed as a standard for communication between low-power devices and which consumes a fraction of the power of an equivalent WiFi connection when exchanging infrequent small control messages [29]. Our experiments [30] verified that although WiFi communications require less energy for transmission and reception of a series of packets, in the idle state, the power consumed by the WiFi chipset was much greater than that required for 6LoWPAN. WiFi is therefore more suited to systems sending a high volume of data, but would require a permanent power source to avoid batteries draining rapidly. In contrast, 6LoWPAN is better suited to light traffic, as in this case to carry sensor trigger information with long idle periods or sleep states. Another key advantage of using 6LoWPAN is that each sensor node can automatically configure an identity on joining the network, eliminating the need to configure new devices when introduced to the field site.

Layered motion detection
Each sensor node continuously monitors the area using a conventional PIR sensor. This is triggered by the presence of moving heat sources (animal or human body) within its coverage area, but such a sensor can also be activated by a gust of hot air in front of the sensor. The PIR sensing was therefore augmented by low-cost X-Band Doppler radar, which detects motion by sensing a change in the reflected radar frequency. The second type of sensor increased the options for generating a reliable trigger, and the two sensor triggers could be combined to provide a higher probability of positive detection [5]. It was empirically established that the X-band radar set at its mid-sensitivity provided more robust triggers. However, some false positive remained, and further sensitivity reduction would result in targets moving slowly to be missed entirely. This limitation encouraged research into image processing techniques to discern useful images.
A sensor node was implemented, also based on the Raspberry Pi platform that used a low-resolution camera to integrate robust motion detection algorithms on the acquired images/video. This method further reduced false triggering and allowed to separate the videos with actual subjects from videos that only show a moving background [31] (such as the blowing leaves of a tree, or the effect of a passing cloud on an otherwise clear summers day).
The use of advanced image analysis methods within the Gateway allowed captured imagery to be classified and tagged with eventseliminating the cost associated with sending large volumes of useless data over the satellite backhaul, and more significantly for many users, reducing the need for subsequent human interpretation of large volumes of uninteresting imagery. These significant reductions in the cost of processing the captured imagery are seen as essential because increasing the use of remote sensing systems would overwhelm the capacity of users to process the captured data [5].

RESULTS AND MEASUREMENTS
The WiSE platform has been successfully deployed to monitor the natural environment (Figure 7). Various deployment sites were used to test the algorithms during development of prototype camera trap units before deploying the satellite-based WiSE architecture [5].

Satellite terminal
The performance of Ka-Band satellite links is degraded by atmospheric propagation effects (e.g. heavy rain or snow) and the build-up of ice on the antenna and/or feedhorn. Although high availability was expected, the system was designed so that in the worst case it would continue autonomous operation following a communications outage.
A more common occurrence was atmospheric attenuation because of rain or cloud on the path to the satellite. Such effects are significant at higher radio frequencies (e.g. Ka-band) and needed to be considered in the design of the communications system. The terminal used adaptive control of the ODU uplink transmit power [32] as a fade countermeasure. Experiments were performed to understand the implications on power consumption and network throughput while recording weather conditions and at different times of day. The bulk TCP upload rate was measured at 1 s intervals to generate a scatter plot of power against throughput using the inbound service from the WiSE Gateway ( Figure 8). The transfers are coloured to indicate whether they were in the daytime, at night or during rainy periods. Figure 8 shows that the power consumption is proportional to throughput and both have higher values during the day.
Peak upload rate was approximately 3.5 Mbps. Power consumption (~53 W under typical conditions) and mean upload rate (~2 Mbps) were found to be suitable for both the bulk data upload, and, when required, for continuous streaming of high-quality video (e.g. using an HTTP server in the IP camera). Transmit rates higher than 500 kbps were observed to sometimes (e.g. during day time rain, with greater cloud cover) require an additional 5 W of DC power from the supply compared with the power needed for lower rate. The WiSE System Controller (Section 2.1), can dynamically trade the use of communications resources against the power budget. Figure 9 shows a trace of the automated switching on/off the satellite IDU. The System Controller checks and updates the IDU operating state every hour. If the battery voltage exceeds the HIGH threshold value, then the IDU was allowed to be operated continuously. When the System Controller determines a need to constrain its power usage (operating below the LOW threshold, e.g. in winter months), it can avoid using the IDU for prolonged periods, especially to perform high-rate transfers (such as scheduled bulk data upload or streaming of video), rescheduling these data-intensive tasks to some later time.
A separate feature enables the IDU to be periodically switched on for a scheduled 5 min slot to send keepalive messagesuseful for retrieving telemetry data, but also useful for requesting longer times for communication when the IDU would not otherwise have been powered. This mode was essential for enabling remote operator access to a system that had little stored power (e.g. to tune the configuration or software).

Satellite communications service
The WISE system chose to use a commercial Ka-band broadband access system for the Gateway, rather than specialised monitoring or mobile data satellite service. This approach enabled use of low-cost mass-market equipment. The only adaptation required to the terminal was a redesign of the IDU power supply. When housed in an appropriate environmental enclosure, the IDU worked reliably, but is expected to have a higher power requirement than a dedicated mobile data or a terminal specifically designed for this application.
The Ka-band antenna was small enough to be easily deployable, but consideration was still needed to the effect of wind in exposed areas, and possible icing in winter months. This required design of an appropriate mount for the antenna. A drawback of current systems was the need and resulting cost for a satellite installation engineer to travel to a remote site with poor/no vehicle access to perform a terminal installation. A self-installable terminal design would therefore have decreased the time and cost to bring the Gateway on line. (While an L-band satellite systems would not have these drawbacks, capacity is limited and usually attracts a higher usage cost).
The WISE terminal was supported by an IP broadband service platform, rather than requiring dedicated operator control and satellite gateway functions. In this respect, the traffic generated by the platform was different to that of consumer or professional Internet traffic sharing the platform: There was minimal outbound traffic (which is usually the predominant traffic in a broadband system); Inbound traffic was also often low volume, but from time to time required high capacity for specific operations (taking advantage of the terminals peak transmission rates).
While broadband service platforms typically cost less to use than mobile data or dedicated monitoring systems, the user service expectation for such monitoring platforms deployed for prolonged periods of time was very different to that expected for broadband delivery. The ability to occasionally communicate at the high peak rate allowed by the terminal (tens of Mbps outbound, several Mbps inbound) was particularly valuable at the times when connecting to the remote equipment to perform remote reconfiguration and maintenance. This was important to users, because virtual access saved the cost of remote site visits and even allowed maintenance when adverse weather prevented physical access to the remote site [5]. The traditional monthly Internet service provider charging scheme may also not be best suited for this application, and in future systems with alternate service models could be effectively used to reduce the cost of delivery for such services, and we suggest these could stimulate new service models [25] (e.g. using IP-based signalling to the network control centre to indicate the desire to provide adaptive variation of QoS when needed to support streaming, or to schedule bulk data transfers at off-peak times, with billing per use).

Environmental challenges and monitoring
The year-long deployment required careful consideration of the operating environment at the deployed location. The climate was harsh in winter with limited access to the deployment site during snowfall. Protection against rain and humidity was provided using sealed IP66-rated inner boxes and silica gel packets, all placed inside a (second) outer weather-proof enclosure (with drainage holes at the bottom and allowing moisture to vent). A simple protection to the on-site Ethernet and satellite cables from adverse weather and the potential gnawing animals was provided by running the on-ground cables through domestic hose pipe.
The WiSE sensors monitored the internal temperature of the Gateway enclosure, the temperature outside the housing (ambient) and also at some remote sensor nodes. The temperature inside the enclosure could be used to selectively power-off devices to prevent operation outside the prescribed range (Table I). In the summer months, an exposed site may need to avoid high temperatures. Similarly in winter, equipment must maintain a minimum temperature. Versions of the system that have been later designed for an Arctic deployment can, when required, use battery power to heat the electronics enclosure to a minimum operational temperature.
All temperature readings are logged each hour and form a part of the system telemetry. They also provide additional scalar contextual data for captured imagery. A representative plot for the daily temperature (observing midday temperature at noon) for a period of 3 months is shown in Figure 10. (The satellite IDU could be managed via its IP-based management interface to control its configuration and retrieve key operational parameters).

CONCLUSION
The paper describes the architecture of a satellite-based system for long-term remote monitoring. The system integrates Internet using satellite backhaul and power generation through solar panels, making autonomous deployment possible at any remote place within the coverage of the satellite communications systems. It captures both environmental data and imagery for later analysis. From a technology perspective, the methods combine 'off-the-shelf' equipment with power optimisation and sensor data transmission. The main features are extensibility of the system to incorporate new types of sensors, autonomous operation and flexibility, allowing the mission objectives to be tailored over a long-term deployment.
The system was successfully deployed as a tool for natural resource management. In this context, it helped explore how digital technology can change the monitoring of remote environments. This architecture may also be useful for a range of other applications, for example, to support large infrastructure development projects, providing remote safety surveillance or assisting in emergency operations in disaster areas.