 |
| PCC: 4G Vs 5G |
It's no news that 5G is a big technology shift, in both terms; Functional and Non-Functional aspects. And PCC being an integral and one of the most important part of 5G Core, is also to be evolved into both aspects. So, I will put down both the aspects one by one and let us start with Non-Functional requirements first.
Non-Functional:
When it comes to 5G, it is evident that every NF(Network Function) has to be:1. Virtual
2. Containerized
3. Orchestrated
4. Web-Scaled
5. 2 Speed Architecture
We will discuss each of the above 5 main building blocks of 5G NF in details.
1. Virtual:
I believe most of the vendors are already having this in place in some way or another, as an approach to reduce hardware dependency. But in many cases, they still require a specific set of hardware. Making an NF truly virtual, means it should be Hardware, Platform & Infra agnostic. Having said that it should be possible for operator to be in a position to use any COTS Physical Hardware, Any Hypervisor and even other infra options like, On-Premises-Virtualized, Public or Private Cloud and even Hybrid infrastructure. An NF should never be deemed as Virtual, until it has a certain dependency on a specific set of hardware. Vendors should guarantee that the functional and performance outcomes of Software (PCF & CHF) are identical irrespective of the underlying infrastructure type.
"This is the time BSS vendors should more focus on Software rather than becoming the Hardware specialists and remove their dependency on specific set of hardware!"
2. Containerized:
This is the next stage of NF evolution. Being Virtual is the essential part of 5GC, but it is not the ultimate goal. Containerization is not only a necessary requirement, but it also an unavoidable evolution step towards making the NFs truly agnostic and predictable. Containerization helps Vendors and Telcos to have a light weight Software package, which is independent of the underlying OS and infrastructure. Even today, most of the Telco vendors are having their BSS Softwares containerized, but they are struggling with the Database, especially who have been using RDBMS. RDBMS are fundamentally not designed to be containerized and hence vendors should take this evident problem as a serious note, that this is the time to shift to a Cloud-Native, Containerized Database; the choice is up to them, but sooner or later they have to shift; the sooner is better though.
By adopting Containerization, the NFs becomes truly virtual and agnostic. Docker is a classical Tool-kit for containerization. Being an open source Tool, it helps the vendors and telcos to bring down the CAPex with a wide community support and evolution guarantee.
3. Orchestrated:
Orchestration is the intermediate stage between Containerized/Virtual NFs and Web-Scaled architecture. Without being an end-to-end Orchestration, it becomes very difficult (if not impossible) to manage the overall NF infrastructure. Think about it this way, even if you have a containerized or virtual solution deployed, it becomes a tedious task to manage the Fault detection, when we have 100s of NF container deployed; Which NF is talking to which and how, at Which step the fault happened, Which NF logs, should we look for are few of many operation issues, which will not be addressed, until the robust Orchestration is in place. Additionally, Vendors should also make it possible to use Persistent Queue mechanism to provide high fault-tolerance and business-continuity. Centralized Logging, One-Touch Monitoring, Persistent Queue Management, Stateless-NFs are the main part, which needs to be taken care, while building an orchestration for 5G-NFs.
4. Web-Scaled:
The unpredictable load demand in 5G, will require an On-Demand Scalable NFs. However, the criteria for Scaling should not be common for every NF. For instance, PCF and CHF load is primarily based on TPS (Transaction Per Second) & No. of Concurrent Sessions, but for NFs like UPF, it is based on throughput, for Billing it may be no. of Invoice per second, and so on. So, the criteria for Auto-Scaling and Auto-Healing should be subjective to each NF-Type. In today's scenarios, most of the Web-Scaled Solutions are designed for Web-Applications and those should be modified (by Vendors) to comply with the Telco requirements. Web-Scaled PCC solution is the ultimate target for 5G Non-Functional Requirements. The scaling should not only be automated, but it should be fast enough to ensure no service interruption.
5. 2 Speed Architecture:
This is my favourite part! 2 Speed Software architecture, essentially talks about 2 very practical deployment scenarios; Centralized and Distributed. In 5G, on the basis of Service & Demand Characteristic, Operator will decide to deployment strategy. For instance in case of a URLLC Service, the best way to minimize the latency and connection setup time, is to put everything on edge and close to application (Edge), while in case of a highly densed metropolitan, it is better to go with a high capacity centralized solution. Clearly, it is very difficult to have a single Software stack to cater both the requirements with desired SLAs and KPIs. So, better is to design 2 different architectures; one for Edge deployments & one for Centralized deployment. While Edge solution should be light weight and self-contained to deliver the reduced Response Time for relatively less connections, the Centralized solution should be more performance oriented in terms of handling Millions of connections and TPS, while using a distributed Database.
So, this concludes to a step-by-step evolution of the 5G-NFs and where, Vendors should start from and the Vision they should look for!
Funtional:
The Functional requirements are huge, when it comes to 5G-PCC, because its not only about meeting the 5G-Tech-Specs, but also seeing how to monetize them. However, I will be having a separate write-up for Monetization, I will keep this article limited to Tech-Spec specific Functional Requirements only.Based on the Tech-Specs for Policy & Charging of 3GPP, below should be the incremental aproach for 5G functional compliance:
1. 5G NSA Compliance
2. HTTP/2 Adaptation
3. N7 Interface
4. New 5G PCCRule and QoS attributes incorporation
5. N15 Interface
6. N25 Interface
7. N23 Interface
8. N40 Interface
9. Other Interfaces
1. 5G NSA Compliance:
As we know the migration strategy for 5G, will involve sequential approach, it is evident that most of the players will start with Non-Stand-Alone 5G deployment, with primary focus on the Radio network for higher speed. Here operators will be using the existing EPC (or 4G-Core) connected to the 5G-RAN. While it seems to have no change in the existing PCC (PCRF and OCS) at the architecture level, but it has everything to do with the primary requirement of this phase, i.e "High Speed". PCRF to have the support for the Extended-Bit-Rate (Higher than 4Gbps), along with the RAT-Type Support for NR and Access-Network support for 5GS to have the 4G-core ready to serve the 5G-RAN. Additionally, New QCI values (other than 1 to 9), will also be needed support, along with new dimension of QCI classification, which is "Delay-Critical-GBR". These changes will be very quick to implement and a faster way to claim 5G ready PCF.
2. HTTP/2 Adaptation:
The first thing to start with the Functional compliance in 5G PCC, is to have HTTP/2 adaptation. However, this itself is a major technological shift, as these systems were running over Diameter for decades. Shifting directly to HTTP/2 will also have incemental steps involved.
2.a External HTTP/2 Adaptor:
At this stage the prime objective will be to integrate with 5GC (SMF) over HTTP/2. And best way to do it to build an adaptation layer, probably an external application. This external layer will just accept the HTTP/2 based Policy requests and convert into Diameter (Gx, Gy) messages and legacy PCRF/ OCS systems can work as is. This will be the first step to accept the HTTP/2 based requests and respond them accordingly. However, this external layer should have the capability to map 5G-QoS parameters (5QI, QoS-Rules, PCC-Rules, QoS-Flow-ID, SUPI, GPSI etc.) to 4G-EPC QoS parameters (QCI, EPS-Bearer-QoS, PCC-Rules, EPS-Bearer-ID, IMSI, MSISDN etc). These systems will typically be used to show case the demo/POC to claim that vendor has the 5G ready PCC in place.
2.b Merging of HTTP/2 Access Layer:
This stage will be more from the source code perspective, where an additional Stack (apart from Diameter) will need to be added into PCC applications (PCRF, OCS). This is just to merge this external adaptation layer inside the main code and this will also require significant changes in overall internal workflow of PCC. Vendors should use generic methods to convert the HTTP/2 and Diameter messages into REST based flows or internal/proprietory message flows, which will be identical to the core engine of PCC (PCRF or OCS). This will not only ensure the better dual stack support of both Diameter and HTTP/2, but also make the product future proof, where any additional protocol adaptor can be added into Access-Layer at a later stage.
3. N7 Interface:
N7 interface implementation should be the first thing in vendors' checklist, when it comes to Stand-Alone 5GC. They can start by replacing or modifying their existing Gx interface to N7. All the 4 main methods (Create, Update, Delete, Notify) of N7 reference point should be incorporated and supported as a replacement of their current stage of Gx Reference point (Initial, Update, terminate, Re-Authorize).
4. New 5G PCC-Rule & QoS Attributes:
This stage will be more form the actual compliance of Stand-Alone 5GC and will involve a significant change in source code. At this stage vendors' should decide, if they want to adapt a really micro-services based architecture to slice down the compliance parameters of all Session Management Policy Flows. This includes additional attributes inclusion in PCC-Rule definition, Separate configuration options for additional business Rules, like QoS-Rules, Network-Slicing Information and traffic-Steering based configuration options. This stage has a lot to include and can further be sliced down to multiple release cycles in order to bring down it to the incremental delivery. I will not list down all the parameters, but a detailed study of 3GPP tech-Specs, related to PCC will be required and same has to be incorporated. The level of compliance, however can be subjected to Vendors' choice or Business Availability/ Visibility, as complete compliance will take a very long time.
5. N15 Interface:
At this stage it will be better to understand more form Radio perspective and the main goal of this stage will be to position PCF as a converged Policy Controller. This PCF will be able to not only perform the Session & Access management Policies, but should also be able to make a Synchronization between these 2 types of Policies. 3GPP does not define any specific reference point interface between Access-Management PCF and Session-Management PCF, but to make a truly converged PCF, vendors' should either include both functionality in a single PCF or should have a synchronization mechanism between the 2 PCF. The later part is more preferable, as it allows to separately scale and configure the Access and Session Management Policies. However, Policy Configuration can be made centralized for both Access and Session Management, but I would still prefer to use separate PCF instances to deal with these policies separately. The reason is that both Access and Session Management demands a different set of response-time, functionality and scalability. Operator should be in a position to scale these two independently. Additionally, PCF at Access side in many cases may be deployed at Edge and for session management it will mostly be a centralized deployment. This is another reason for our 2 Speed Architecture, which we discussed above.
6. N25 Interface:
N25 interface is the one of the main requirement of 5GC, to make the Service-Based Architecture a reality. In 5GC, UDR is the single master database and it removes the dependency of multiple nodes (HSS, PCRF, OCS, IMS etc.) on multiple databases and also removes the synchronization issue between these many databases. The PCF should be in a position to use UDR as a main database for complete Subscriber, Subscription and Usage management and this is only possible after a complete compliance of N25 reference point interface along with the Nudr APIs.
7. N23 Interface:
N23 interface is between PCF and NWDAF (Network Data Analytics Function). This is one of the reason, PCF is termed as one of the most critical Network Function in 5GC and "The Most Intelligent Function" as well. NWDAF is having real-time network analytics information of all the NFs, at the system level and at the Network-Slice level as well. Hence NWDAF is having most valuable and critical information of the network, but it doesn't perform any action on its own. And the best part is that only PCF is having the access to this information (principally). This makes PCF very well informed about the real-time network status information, like Load, Stats, KPIs, Slice Utilization etc. PCF can use this information to perform change in policies; both Access-Management and Session-Management at subscriber level and at Slice level, to avoid any unwanted overload at any network function or at a network slice.
 |
| Industry Priority for Different 5G Network Functions |
8. N40 Interface:
Charging will be the last touch point in 5G-PCC, as most of the systems will continue to support Diameter (Gy, Ro) for a very long time, during the transition phase from NSA to SA. But to make a truly Stand-Alone 5GC, it is important to migrate Gy to N40, just the way I explained for Gx to N7.
9. Other Interfaces:
The other interfaces are not part of immediate future requirements and most of the 5G use-cases will be complied with above approach only. However, still from the compliance perspective an incremental approach, below preference matrix can be taken forward:
N30 --> N5 --> N28
No comments:
Post a Comment