Hardware module: A communication system developed around on a deployable private LTE network
1. A description of the communication subsystem solution
The communications subsystem block diagram is depicted in the below figure.
We chose to use a private LTE network due to the following considerations:
- the commercial LTE operators might be affected in a crisis scenario, either because they are prone to be heavily requested by the other users (risks of denial of service) or their infrastructure (eNodeB’s) is affected
- a rather large area must be covered (e.g. 300 x 300 m). A WiFi alternative has a lesser coverage (or requires more access points) and the communication bands are not guaranteed to be available when needed
- a large band is required, mainly for video streaming. LTE has a high performance regarding the efficiency of band usage (bits/Hz/s) and the necessary UE’s (user equipment) are well tested and tried due to mass dissemination for commercial purposes
- LTE provides the IP connectivity over which it’s easy to seamlessly implement various communication functions: audio/video streaming, file transfer, encryption, tunnelling.
- the UE costs (smart phones, LTE routers) are very competitive, compared to other, smaller scale production alternatives
- there’s a consensus within the European Union that the 1st responders organizations need to be given dedicated (LTE) radio spectrum for their actions. Compared to relying on unlicensed frequencies, these organizations will benefit from complete availability for the dedicated band, less noise, better voice and image quality.
- smart phones are small and deliver excellent audio/video capabilities.
The communication network, apart from the LTE part, includes conventional IP phones (or desktop soft phone applications), inside the mobile data centre, a simple backhaul based on radio relays/satellite links/government owned networks (or a combination of these) and a number of IP phones in the main command centre. Also, gateways for other types of users/networks are included: TETRA and commercial LTE operators. TETRA is needed to communicate with other organizations while the crisis situation unfolds. If any users are outside the LTE coverage, they can communicate via the commercial operator network (if available).
The calls are handled by SIP server applications (and SIP clients installed on the phones) and machines, one within the mobile centre and another one in the main centre.
Group calls are supported; the groups can be configured in advance, with management tools provided in the SIP apps. The audio and video streams pertaining to the one-on-one and group calls are stored in the mobile centre; they are available for processing in the main centre, because the IP network easily supports transfers.
The communications system doesn’t use any outside-managed resources, like the Internet. This makes any outside attacks less plausible and possible. Additional security is provided by the IPsec servers and client applications.
2. A description of the private LTE network
There are various manufacturers for small scale LTE networks, for various purposes. For instance, there are solutions that are integrated in larger commercial networks and have limited capabilities if the backhaul to the main infrastructure is unavailable.
There are certain characteristics that helped us in choosing a simpler solution:
- at any given time, the active users number is small enough, about 20.
- the covered area allows to implement a single LTE cell. However, the system can be expanded, if needed. For the time being, we don’t need to use the hand-over functions of the network
- the necessary eNodeB is small enough and has a reasonable power consumption. It can be hoisted, together with the antenna(s) on a telescopic pole a few meters long, which can be installed where the mobile command centre is situated in less than 30 minutes. Also, the eNodeB can be installed within the mobile centre, while the antenna system is fixed on the telescopic pole.
There are available solutions that gather in a sole, battery operated equipment the eNodeB and the core network.
- the necessary transmission power is 10...20 W, with a good quality, high gain antenna system
- no billing is required.
For the demonstrator stage, we decided to use, instead of the full eNodeB, a laboratory version of it, namely LTE LabKit manufactured by ss7ware. It has a less than 100 mW transmission power and can be put to work in any LTE band that uses FDA. Together with the Minicore (core network) equipment it also provides the necessary management capabilities.
The smart phones within the private LTE network have dedicated SIM cards; when turning on the equipment, registration occurs, just as in any LTE network, and IP addresses are given. There is a dedicated software app that runs on Android OS’s installed on the phones; it gives the user only the functionalities that are necessary during the mission:
- one to one call
- one-touch attachment to a group call
- video streaming upload (from the phone’s back camera) is done when the user pushes a dedicated button (“push to video”). A “push to talk” function is unnecessary, as full audio conferences are available without restrictions of bandwidth
- file upload
- SMS send
- user notification when a SMS or file is received
A Quality of Service (Qos) system is used to give priority to streaming-type connections. Apart from that, the users are placed in a hierarchy: if the simultaneously uploaded streams surpass the network capacity, the less important sources are discarded.
The LTE user equipments also include LTE routers, for uploading video streams from fixed position surveillance cameras. The peculiarity of this type of application is that the LTE routers, which have an Eth port, are usually connected to a host computer via the Ethernet port and the LTE provides Internet access to the host, which uses the LTE network as its needs demand. On the other hand, the surveillance cameras are generating the video stream all the time, while the LTE network might not have available capacity all the time. This is why the router must be able to receive simple “active/standby” commands via the LTE; actually, “active” status is entered when the router receives a notification, just as an ordinary phone would do. The router must have an explicit “standby request” in its set of commands.
The biometric data collection module
We have decided to split the biometric data collection task into two separate scenarios:
- Training sessions
While in training sessions, with intense physical effort, significant indicators are recorded: pulse, burnt calories, covered distance, ECG. For this we will use a COTS system, with appropriate sensors that communicate via Bluetooth with a smart phone. A specialized app, that accompanies the sensors, is recording the data. After the session is finished, the data are transferred by another ready-made application to a server that sorts and stores the data for each of the subjects, for further analysis.
- Monitoring during actual missions
The data most necessary during missions are tied to the subject’s capability to function, a “man-down warning” for the supervisors in the mobile and main centres. The biometric sensors must be accurate and, at the same time, to be easy to wear for the subject.
We opted for a chest belt that reliably measures the heart rate and transmits it to the mobile centre in a frame, via a LoRaWAN network.
We are using a Polar H10 chest belt that is capable of transmitting the heart pulses AM-modulated with a 5 KHz frequency, at a very low power. In its immediate vicinity we placed a miniature AM demodulator that feeds the heart pulses, at CMOS level, to a small, rechargeable battery-powered custom module, fixed on the heart belt near the sensor and the demodulator.
This module includes a low-power microcontroller, a LoRaWAN modem and a small embedded GPS module which has its own antenna. The microcontroller measures the heart pulses mean period. At about every 30 seconds, the microcontroller creates a frame with the subject’s ID, a timestamp, the current position (from the GPS receiver) and the current pulse rate. It sends this frame, via the LoRaWAN embedded modem and its network, to a gateway that is mounted in the mobile command centre. The raw frames are filtered (from other local LoRaWAN networks) and stored in a data base by a small-scale server that works together with the LoRaWAN radio module in the gateway.
A custom software application reads the database, parses the frames, filters and stores the data for each subject. If the pulse rate is abnormally small or big, an alarm is issued to the human supervisor, which will contact the subject by phone.