Providing secure, reliable network coverage to a mission critical enterprise environment is extremely complex. Not only do networks in factories, construction sites, warehouses and hospitals need to cover large areas both indoors and outdoors, they also need to reliably connect hundreds of sensors, trackers and monitoring devices, some of which require high bandwidth and low latency connectivity and all of which need to be protected from hackers and security breaches. Until now, a mixture of WiFi and public LTE networks have provided connectivity for these enterprise IoT networks, but neither of these technologies can provide the reliability, range, flexibility, security and above all ownership that a mission critical enterprise network requires.
Using WiFi to connect indoor campus networks has its advantages. It is relatively easy to deploy and manage and the enterprise has the ownership of the network, contrary to cellular networks which are usually provided by Mobile Network Operators (MNOs). However, using WiFi (even WiFi 6, the latest standard) to connect hundreds of devices does not provide the resilience required for mission critical enterprise applications. WiFi is fine for indoor deployments, but in a large outdoor area such as a construction site where there are also many moving assets that need to be tracked, it is not feasible. The number of base stations required to connect a WiFi network in this type of deployment would be too costly, and the range and signal strength is not suited to moving assets, especially if they need to be tracked on and offsite. Public cellular networks, using LTE are a better option for outdoor sites and moving vehicles, but indoor signal strength can be an issue, particularly in factories or warehouses where metal walls or doors can prevent the signal from penetrating the building. Public LTE networks are also an inflexible option for enterprises because the infrastructure is owned by the MNO and shared with consumer applications which can create interference and loss of bandwidth. Latency and security can also be a problem on the public cellular network, particularly for applications which require 99.999% uptime.
So what is the answer? The recent availability of unlicensed spectrum in some countries (such as CBRS spectrum in the USA) allows enterprises to create their own private LTE networks using small cells across a campus area. This is ideal for enterprises that are located in remote areas where public cell towers may not reach (such as mines or utilities). Since the network is owned by the enterprise, it can be configured and deployed in a way that exactly matches the enterprise requirements, and the possibility of “slicing” the private LTE network allows them to connect different devices with different requirements in terms of bandwidth, security and latency. The private nature of a private LTE network also means that there is no interference from other devices on the network, devices can be deployed with practically zero latency and the network can be kept completely separate from the public internet, making it much more secure than a public LTE network.
However, it is also possible to deploy a private LTE Network using the public network infrastructure and deploying a private LTE core to route traffic back to the enterprise. This option can be deployed in conjunction with an “island” network on unlicensed spectrum, or as a private LTE network using licensed spectrum and the public network infrastructure. For many enterprises, the latter example is ideal because it enables them to seamlessly roam on and off the private network whilst keeping data secure behind the corporate firewall. For use cases such as a construction site, factory or warehouse where goods and deliveries coming on and offsite need to be tracked, or even in a hospital scenario where remote patient monitoring devices are being used, this is where private LTE really comes into its own. Pod Group specializes in this type of deployment, so if you are looking to deploy a private LTE network, talk to their experts about your particular use case.