5G is more relevant and different than previous generation (4G, 3G), when we talk about the use cases, its targeting. For more details about the use case differentiation & categorization, please refer to my previous blog https://goftelecome.blogspot.com/2018/10/5g-myths-facts-use-cases-solutions.html
5G is designed to deal with 3 very different and unique use (namely; eMBB, mMTC, URLLC) cases and it is supposed to handle all 3 dimensions so well, that it logically isolates the impact on one another. While eMBB requires HUGE-DATA-RATES (~10Gbps), mMTC demands a DENSE-CONNECTIVITY(1Mn/Sq.Km) and a LONGER-UE-BATTERY-LIFE(~10Years) and on the other hand URLLC demands an ULTRA-RELIABLE-NETWORK with extremely LOW-LATENCY. All the use cases of 5G like 4K-Videos Streaming, Connected Cars & Logistics, AR/VR, Tactile Internet, Industry-Automation, Remote Healthcare etc. revolves around these 3 network characteristics.
Clearly a single network is just not suffice to cater all 3 requirements. But still 5G promises to offer each of these. And to make this happen, 5G leverages the 2 technologies; Network-Slicing & Mobile-Edge-Computing.
Network-Slicing is a set of Network-Functions grouped together to meet a certain network and service characteristics. It is possible to use a Network-Slice for more than one service. However, unlike many people think about it, network slicing is not a new concept, but the procedures to implement it has been refined significantly in 5G (3GPP-R15). Up until LTE, Network Slices are usually created only for the User-Plane Core network, basis on APN classification. But in 5G, Network Slicing is much more complex and covers not only the User-Plate Functions (UPF), but also the Control-Plane Functions (AMF, SMF, PCF, CHF, etc.) and the Access-Network (RAN, Fixed) as well. To manage and simplify this implementation 3GPP introduces few new NFs in Control Plane (Service-Based-Architecture) such as, NSSF, NRF and NEF. By analyzing the appropriate use-cases, a complex network topology and slices can be created dynamically by utilizing these new NFs.
Mobile-Edge-Computing (MEC) is again a relatively young concept, but not entirely new one. However the implementation of MEC in 5G is not just network in a box, but it is more subjective to the use-case, service-demand and cost. MEC solutions are not cost effective and increases the cost of implementation of a large scale network, hence it is important to analyze all the factors, before choosing the right topology blueprint.
"It is always said in 5G Centralized as much as you can and Distribute only what you must!"
MEC in 5G is actually, finding the right edge. It is the right balance between the Service Demand Characteristics and the Cost involved. Below picture, gives a brief about how to decide, which compute technology should an operator adapt to, based on the latency and network setup time requirements.
If we look closely, we could say that in case of an Edge-Compute network, although the latency requirements are very stringent, but the number of connections are relatively less, hence it does not require a high performance Network-Function, but on the contrary it requires a very light-weight one which can minimize the HW cost and power requirements. But on the contrary, in case of a Centralized-Compute scenario, the requirement is a very high performance oriented NFs to cater Millions of connections and Transactions. In this (centralized) case, implementation cost can be higher, but performance should not be compromised.
Clearly a single Software framework can not cater to both of these requirements perfectly and this is the reason, why 2 Speed Software Architecture is required.
"One architecture is designed to be very light-weight, offering a faster response time while the second one is designed to be more performance oriented with capability to serve Millions of Connection & Transaction, by utilizing a bigger infrastructure"
I also have some insight, on how vendors can achieve it. For instance, PCF can have First Architecture as a container based designed with collocated SPR (Database) and capability to be co-hosted on a common infrastructure along with other NFs (AMF, SMF etc.). Many of the non-required modules, such as non-required Protocol-Stacks, Notification Channels etc. can be removed from the main code, to minimize the size of deployment and Response time. While in case of a performance oriented deployment, Internal modules of PCF (Access-Layer, Policy-Engine, Notification-Service, Policy-Catalogue etc.) can be distributed among multiple set of infrastructure separately to support Scalability of individual modules. Hence the Architecture of Software (of PCF) should also be engineered such that all these modules are separately deployed and scaled.
No comments:
Post a Comment