Aaron Hinkle, System Architect, Sprint
Is your AI client thick or thin?
From a network perspective, there are two types of AI clients. The thicker client has more compute capacity at the mobile endpoint. An autonomous vehicle is a good example of a thick AI client. Autonomous robots and autonomous drones are good examples of light AI clients. Both robots and drones have space, power and weight constraints limiting how much compute can be onboard.
For thick AI clients, outlier situations exist where massive amounts of video and telemetry data need to be uploaded quickly and a response from the application in the cloud needs to be returned within a very short time period. The Internet as a whole is best effort with no service level agreements and is oversubscribed for bandwidth, tonnage, and latency. One of the best ways to guarantee the speed and delivery of latency sensitive critical data is to put the user plane of the mobile core and the AI application as close to the edge as possible removing as many of the best effort links as possible.
For light AI clients, the need for compute resources in the network to offset the limited compute resources on the mobile IoT device will drive the cloud to the edge. The light AI client will need to send live video and telemetry data to the network and receive control instructions back in a very timely manner. A flying drone is a unique case where an untimely response could result in the drone falling from the sky. The potential for injury to people or damage to property is problematic. Unlike the thick AI client where the network and heavy cloud compute usage is more intermittent, a thin AI client is likely to be a heavy and continuous user of both.
Where is the edge?
Critical services and their associated applications will have service level and latency requirements. Latency should be measured from an end-to-end service perspective, i.e. the mobile end point through the cellular network to the application and back. Based upon that latency the user plane of the cellular core will need to move closer to the tower so that the service application can be closer to the mobile end point. The business will drive where the edge distance should be located.
Applications and AI being deployed to the edge need to be re-thought in terms of application structure as well as deployment strategy
Removing the best effort network links associated with the Internet implies the application should be in the metro area market. Moving the application to every cell tower is problematic due to the cost and the nature of mobility causing hand-off between cell towers.
Internet peering points and inter-network connections are rarely within the metro market. New network connection points will be required in the metro market and potentially closer to the cell tower providing cross operator cloud services.
The price of compute will have a large impact on the speed of the cloud edge distribution. Datacenter space within the markets is very limited when compared to the hyper scaled cloud providers. The scarcity of the compute resource and the proximity to the cell tower will drive the cost higher.
See Also: Top IoT Companies In Europe
Need to change the Application Design
Applications and AI being deployed to the edge need to be re-thought in terms of application structure as well as deployment strategy. The cost of compute will be higher closer to the edge given the scarcity of resources. Handoff needs will also drive application structural changes. For AI, only the most critical functions should be distributed to the edge. For thick AI clients, the collection of the critical upload data should be at the edge while the large analytical data collection and less latency sensitive functions should be deployed further from the edge where compute and storage are more readily available and more cost effective.
With the user plane separated and distributed to different locations from the control plane, session state, authentication, and failover domains need to be re-examined. An IoT device connected to a stateless user plane application at the cell tower can easily failover to another instance of that application at another location. This is possible with a cache miss at the other instance causing the session state to be pulled from the control plane at a couple of key points within the market. These key points are likely to be where the mobile network interconnects to the Internet or other network providers.
The failover domain for a light AI client is more complicated. The network AI function will need to failover to another location. This will only be possible if the cell towers are connected to a metro fiber ring and not home run to key network interconnects.
As the 5G networks are deployed and the autonomous vehicles, drones, and robots begin to arrive, the cloud will need to extend out to meet the need. New network interconnections will need to be made. Application structure and distribution will need to be rethought. Failover domains need to be re-evaluated. The complexity to automation and orchestration will be interesting to watch. No longer are CPU, memory, storage and network capacity the only variables to be considered. Now location, failover domain, and cost of each need to be factored in. We live in interesting times.
Check Out : Top IoT Vendors
