Smart Grids: Data Concentrator or Gateway?
Since the establishment of communication networks, it has been necessary to choose between centralised and decentralised solutions. However, there are not only two solutions – it is also possible to choose different levels of decentralisation. What level of decentralisation is suitable depends on a number of parameters. The main parameters include connectivity between different network elements and their computing power.
Devices and topology of smart grids
The fundamental element of any smart grid is a smart meter. The meter is called ‘smart’ if it has a communication interface which allows integration of the meter into the smart grid. The most common communication interfaces are: PLC (power line communication), W-MBus, ZigBee, 6LoWPAN, GPRS, etc.
Leaving aside GPRS, which does not require a gateway or concentrator, it can be said that the remaining communication types are low cost in terms of construction of the communication network, but they are characterised by lower reliability of communication and a relatively low data throughput.
Due to the relatively short communication distance of most networks used for smart meter communication, it is necessary to ensure network connectivity to other networks such as the Internet.
That functionality can be provided by a gateway or data concentrator, which can be located in a transformer, common areas of the building or at another location. These devices communicate with a head-end server, mostly via mobile networks. An example of smart grid topology including connection to the head-end server is shown in Figure 1.
Gateway
The most important gateway function is to transmit messages from one network to another. Furthermore, the gateway can manage the topology of sub-networks or can integrate router functionality.
It is necessary to note that meters in most cases do not support the protocols used in computer networks which are mostly based on web services. Even when devices are compatible with the IP protocol, on the application layer they use specialised protocols for smart grids such as DLMS, W MBus etc.
Due to these facts, functionalities from data concentrator are still needed, but it is possible to implement them on the server-side where high-level programming languages can be used and it is easier to maintain the software.
Gateway with/without queue
Quality of communication is influenced by message queue support in the gateway. If the gateway does not support queue, the gateway can be implemented very easily with low demands on computing power but with potentially bad consequences for throughput, error rates and latency of communication.
If the gateway supports queue, it should also support QoS (quality of service), which allows prioritisation of messages using a scheduler. A good example of such a scheduler is LLQ (low-latency queuing) used in Ethernet routers. However, implementation of the queue along with QoS support is computationally demanding.
A way of calculating the communication parameters for the gateway without queue and with queue if the second network is of the master-slave (request-answer) type can be seen in Table 1. In the variant without queue, baud rate [the rate at which information is transferred in a communication channel] is always less than the baud rate in both networks.
| Gateway without queue | Gateway with queue / Concentrator | |
| Baud rate (R) | R = ( R1 R2 ) / ( R1 + R2 ) | R = min (R1 , R2 ) |
| Latency | Latency = Latency1 + Latency2 | Latency = Latency2 |
| Error ratio (PER) | PER = 1 – (1 – PER1 ) (1 – PER2 ) | PER = ( R – min( R1(1-PER1 ), R2(1-PER2 )) / R |
| Throughput | L R / ( L + R Latency ) ( 1 – PER ) |
A significant relative decrease in comparison with the minimum baud rate occurs if these speeds are similar. Latency is the sum of latencies in both networks, and the error ratio is always greater than the error ratio in the individual networks.
A significant relative increase in the error ratio to the greatest error ratio occurs if networks have similar error ratio. In the case of gateways with a queue, baud rate is limited only by the baud rate of the slower network.
| GPRS | MT-PLC | |
| Baud rate (R) | R1 = 3200 B/s | R2 = 1160 B/s |
| Latency | Latency1 = 0,3 s | Latency2 = 0,022 s |
| Error ratio (PER) | PER1 = 20 % | PER2 = 30 % |
| Frame length | L = 42 B |
Long-term network throughput is affected only by latency from the second network since the latency of the first network is eliminated by the queue. Error ratio of the faster network occurs only if its throughput is lower than the throughput of the slower network.
Example calculation of communication parameters for GPRS in the first network and MT PLC in the second network are shown in Table 3; the parameters of GPRS and MT PLC in Table 2.
| Without queue | With queue | |
| Baud rate (R) | R = 851 B/s | R = 1160 B/s |
| Latency | Latency = 0,322 s | Latency = 0,022 s |
| Error ratio (PER) | PER = 44 % | PER = 30 % |
| Throughput | 64 B/s = 0,50 kb/s | 505 B/s = 3,95 kb/s |
Due to baud rate of both networks being quite similar, latency of the first network is considerably higher, and as error ratios of networks are also similar, it is not surprising that the resulting throughput for gateway without queue is much lower than the gateway with queue. In the case of a combination of Ethernet and MT PLC, the difference will not be so significant.
Table 4 summarises advantages and disadvantages of the gateways with queue and without queue.
| Gateway without queue | Gateway with queue |
| + price + simple software update + easier development | + simple software update + easier development |
| – low network throughput – complex software on server-side – greater data flow between the gateway and the server | – complex software on the server-side – greater data flow between the gateway and the server – server has to manage the use of the gateway queue |
Data concentrator
A data concentrator is another development stage of the gateway with a queue. Given that the gateway with queue requires more computing power, there is the possibility to slightly increase the performance and add more functionality. The actual advantages and disadvantages of a data concentrator are shown in Table 5.
Automatic creation of routine tasks – The majority of messages in smart grids are periodic readings of profiles with measured data and asynchronous logs and nothing prevents the concentrator from creating these messages itself. This saves a considerable part of the communication between the server and concentrator, and the server does not have to schedule these tasks.
Joining answers into larger units – Since the packets in the network between the concentrator and the server may be in most cases substantially greater than the size of packets in the network of meters, it is appropriate to transmit multiple responses from the meters to the server in a single message. Moreover, it is possible to use data compression. As before, it saves a considerable amount of data transmitted between the concentrator and the server.
| Data Concentrator |
| + lower data flow between data concentrator and server + simple application development on server-side + faster response to smart grids events |
| – price – complex FW development and maintenance |
Protocol translation – For server-side applications, it is difficult to implement specialised protocols such as the DLMS, W-MBus, etc., which are used in smart grids. So it is an advantage if the concentrator communicates with the server by a protocol independent of the protocol used in the meter network. Furthermore, this protocol can be optimised and it can provide greater convenience in its processing in high-level programming languages.
Data analysis, events filtering – The concentrator does not have to only forward data from meters to server. The concentrator can analyse this data, filter it or perform other processing. This can result in substantial savings in the communication between the concentrator and the server, and also greatly accelerates the response to certain network states.
Conclusion: What is the perfect solution?
A gateway without queue can be a more cost-effective solution if the network between the server and gateway has low latency and high throughput with minimal error rates compared to the meter network.
Since a large part of the solutions in practice use networks with higher latency and error ratios and lower throughput, using the gateway without the queue in those cases is inappropriate and could cause a significant reduction of data throughput compared to devices with queue.
In these cases, it is necessary to use at least a gateway with queue, or use a data concentrator, which can save the cost of server applications development and data transfer between the concentrator and the server.
A concentrator can also improve the response to smart grid events and generally provide greater comfort when using and servicing the device. If the device has queue, the arrangement of queue scheduler ensuring QoS is also very important.