Edge computing brings up a number of issues that need to be addressed before mainstream adoption.
Edge computing and certain VNFs will run in exactly the same location. Operators will have to perform gap analysis and either:
- Share the same infrastructure, or
- Share similar infrastructure, simplifying procurement, or
- Use different infrastructure if the requirements diverge sufficiently e.g. edge requiring GPU etc.
Mobility is inevitable for cellular UE when moving within the network or even when changing radio access technologies (RATs) e.g. WiFi to 5G. Users will demand continuity of service. For stateless applications, e.g. video optimization, this is not an issue. However for stateful application such as AR/VR, there needs to be seamless handoff. This could be accomplished by:
- Mobility of state across edge instances, or
- Mobility of application (VM/container) across edge instances (assuming they are not multi-tenant)
Connected cars are typically not all going to be connected to the same CSP. This means that for car to car or car to sensor communication to occur effectively, the application has to span multiple operators. This is one of the area ETSI MEC is considering looking at in their next phase.
Location and Hierarchy
To provide maximum flexibility to operators, application developers and users, edge compute needs to be deployed in a variety of places such as:
- On-premise e.g. IoT gateway, vCPE
- Radio node e.g. eNodeB
- Aggregation point e.g. Virtual central office (C-RAN), RAN aggregation hut
- Regional data center
Rather than running in only one location, the application may span a hierarchy of locations all the way from the “thing” to the cloud. See N-tier deployment viewpoint above.
Security and Compliance