Hungary’s state-owned company, MVM NET, a member of 450 MHz Alliance, started eMTC/Cat-M1 IoT solution on top of the broadband LTE 450 MHz network. The importance of this step is significant: especially on the countryside the territorial coverage of the public operators is poor, as MVM NET’s agricultural clients learned. In addition, with the vantage of the radio propagation in Band 31 and the Coverage Enhancement included in eMTC, typical places for household measurement units like sinks, basement and shielded boxes can also be covered.
Naturally, there are some limitations due to the 5 MHz wide frequency band. Since our frequency allocation, it force us to shrink our bandwidth to only 4.4 MHz, the in-band and even the guard-band operation of any IoT systems is impossible, as an LTE system would not have a minimum amount of frequency domain resources (left). After several tests and measurement campaigns in tenacious cooperation with the National Media and Infocommunications Authority of Hungary and by the exploitation of the LTE guard band opportunity, MVM NET started a 4.8 MHz operation using all the RBs (Resource Blocks) available for 5 MHz nominal LTE bandwidth. With this new lay now, it is possible to grab some RBs to use them with eMTC.
Why eMTC? It is a long story, as MVM NET colleagues say. Even though the battery consumption of eMTC is a bit more substantial than in case of NB-IoT, the eMTC system capacity is 2-5 times greater than NB-IoT one and the dynamic allocation of LTE RB to be used by eMTC indicated the applicability of eMTC on the top of the LTE. One shouldn’t forget for the mass operation of IoT terminals, congestion makes data repetition and active queueing happens, which also drains the battery. And the lower network capacity more likely causes congestions.
Why Private Network? In the last few years, the need for secure and reliable IoT network has dramatically increased. In the area of public IoT services these concepts are not common. Predominantly, IoT is used without guaranteed bandwidth, nor SLA. For non-critical sensors and control functions, cost saving is the most relevant issue.
Some would say, for smart metering it is also not necessary to build up a reliable network. Some would agree with them, though after testing the solutions presented by the main smart meter developers (basically household meters for electricity, water and natural gas), it seems the smart metering is to be on the razor’s edge.
General and well-developed secure solutions for smart metering like DLMS/COSEM are fairly good for connection oriented lower layers like TCP/IP over a kind of circuit switched network. Although DLMS has a connectionless transmission solution, it generates extensive data sessions (n x 10 sec) especially in case of consumption history queries. As the security expectations involve TSL/SSL (only over TCP) the data session with many overheads will be a never-ending story in a congested network. For a private (not public) network as MVM NET’s IoT system additional network security like TSL/SSL neither secure DLMS for the whole data path is not necessarily needed as eMTC is well secured and the entire network from radio part to backbone is safe and unopened. With the robust and quite well developed DLMS used only between the smart meter and the eMTC terminal itself and without additional security and the use of different protocol from the eMTC terminal to the HES (Head End System for the smart metering) like LwM2M (Lightweight Machine-to-Machine) over UDP/IP dramatically shortens the data session interval and solves the OTA (Over The Air) device maintenance issues as well. Hoping more and more smart metering developers will not only see through the lenses of wired technologies.