Physical Network Function (PNF) Support & Relevance in 5G

Introduction to Aarna Networks

Sriram Rupanagunta  – Aarna Networks is a startup that’s working on a platform that essentially tries to automate a lot of the functions of the 5G, cloud-native functions of 5G, and edge applications such as automation lifecycle management and creating control loops for making changes in the configuration. 

What is the physical network function (PNF) & its relevance in 5G?

Hema Kadia: Sriram, let’s start with defining the physical network function (PNF). We’ve heard a lot about virtual network function (VNF). And we know that PNFs are going to exist here beyond the transition phase to 5G.

Sriram Rupanagunta: There are two categories of these physical functions:

Physical network functions are the devices that cannot be virtualized

So if you take any sort of modern cloud-native functions, a lot of the functions are virtualized either as VNFS or as CNFs. The VNF refers to the virtual machines, and the CNS refers to containers. The idea is to make it more flexible so that people can create these functions quickly and make changes. There is a class of these devices which cannot be virtualized. For example, if you take the 5G specific use case, the 5G base stations function cannot be virtualized. They will remain as physical functions, and they are an important part of the overall service. And because when you create a service, it will have virtual functions and physical functions. 

Physical network functions are devices that have not yet migrated to virtual functions.

There are a bunch of devices that have not yet migrated to the virtual functions. This could be some legacy devices, like routers, which are high-performance devices. That people don’t want to migrate to virtual functions. So, in that case, you want to keep them as PNFs. Now, the importance is that you know that even though your entire network service is virtualized or containerized, there will continue to be these physical devices that will stay as PNFs. So that’s the importance of having these PNFs.

PNF automation – What needs to be automated & why?

What are the similarities with VNF automation?  

Hema Kadia: Sriram, one of the things that we always hear about is virtual network function (VNF lifecycle management or how the orchestrators – whether it is ONAP, OSM MANO, or vendor-specific orchestration & management functions, always talk about VNF management. Now, how do you automate PNFs? Is it a similar capability? What PNF objects/functionality do you automate? Can you elaborate on that? 

Sriram Rupanagunta: Essentially, there are three aspects that you have to look at from a PNF point of view. 

PNF onboarding automation – There could be thousands of PNFs, and onboarding them manually by the operators is going to be a very tedious and very time-consuming process. So, that’s the first aspect, which is to onboard the PNFs. In that sense, it’s kind of similar to the way you onboard VNFs. But these are all physical functions that are out there in the network service.

The second part of that same functionality is PNF migration. For example, you may take a physical device and move it to a different location. In that case, it has to be automated or reconfigured. So again, all these functions can be done manually, but it’s going to be extremely tedious to do that. Also, as in the case of 5g, the problem is going to be there due to a lot more units because the number of such devices will be more known at the base stations and so on. So that’s the first part, which is to automate the onboarding.

Automating the configuration – All PNFs may not have the same configuration. So, you have to configure a certain set of PNFs with certain parameters. And then set parameters depending on the location or whatever, in the case of 5g, for example. For example, when you initially configure them, which is called day zero configuration parameters. And then, as you know, as you gain more experience, you may have to tweak certain parameters. So those are day one day N, so again, all of them have to be managed, either as a cluster or individual. And, again, the same point, all of them can be done manually, but it’s going to be extremely difficult for operators to do that without automation.

Automate the changes based on certain changes in the environment – For example, there could be load congestion suddenly because of some event, or there may be some errors, because of which you will have to make some adjustments to the PNFs configuration. And again, it’s extremely difficult for somebody to sit at a terminal or a management station, look at all of these, and make these changes. So this process has to be automated; where you may receive these errors, we receive these parameters. There may be some analytics functions, that look at all of these, analyze them, and provide input to change all of these sets of parameters on these physical functions. So in that sense, the requirements are very similar to VNFs. So, even to do exactly the same thing based on certain environmental variables, you will have to change those parameters. And so that’s exactly what these automation platforms will enable you to do. You can create what’s called a control loop, where you receive these parameters, and then you run certain analytics, which could be either developed by the operators or they could be from other vendors, and then they run them, and then based on that they go and make changes. That’s the third aspect of PNF management, where you have to automate these aspects.

PNF pre-on-boarding, on-boarding | similarities & differences with VNFs | how to handle scalability & related challenges

Hema Kadia: What are the PNF onboarding process, the discovery process, and related lifecycle management? Is that similar to VNF? What are the differences in the context of PNFs? And how do you handle all the scalability issues and the related challenges?

Sriram Rupanagunta: I can describe the process in the context of ONAP. But it’ll be very similar for other automation platforms as well. 

The first step is pre-onboarding. In this case, essentially, what you do is, that’s typically something that the PNF vendor has to do, say, a vendor of a base station or some specialized network equipment. So you are the one who is going to be creating what’s called a PNF descriptor. This includes all the artifacts for managing the PNFs. And how do you set certain parameters? What are the models that are required to manage this VNF? So, all of that is part of what’s called a PNF descriptor. That is the pre-onboarding step, where even before you actually bring it to some automation platform, you have to create this in a package, which is, again, kind of similar to the VNF packages. So, the considerations are very similar.

The second step is to onboard and do the design. A platform like ONAP has a very clear delineation of a design and run time. And so the same thing applies to the physical functions as well, where you know, in the case of PNF, what you do is you essentially onboard these PNFs. So whatever package that you have, you get from the vendor you onboard it, make sure there are no errors, and so on. Then you upload these packages to the design; whatever is your design controller in the case of ONAP, it is SDC. And then you also do the network service. So, the service may consist of some VNFs or a combination of VNFs and PNFs. A lot of them all together create a service, which kind of makes sense for you to start distribution and other steps. And so, in that sense, it’s kind of a subset of what you do in the case of VNFs, for uploads.

The third part is the runtime. Once you do the design, and your PNF is kind of known to the platform, and then the PNF registration starts, so where let’s say, a device is turned on so that it tries to register. And there is a process for doing that. So we’d say it’s a kind of a well-defined protocol in the PNFs registers, and there are certain components in your platform, which will receive it, and then it will configure it, and it will act to any device. So, again, going back to the previous discussion, the whole idea is to automate all of this. So, it’s not like somebody’s going to sit there at the terminal and management console. And we’re going to do that as PNF come up because there could be, you know, thousands of them that will come up. So, that process, again, is kind of fully automated.

And so that’s kind of the three important steps. Now, subsequently, there are additional things that are possible to be done or to be automated. For example, ONAP defines this process of plug and play, which is kind of an extension of what we talked about in the runtime. So, the entire discovery process is fully automated. So, there’s a well-defined sequence where that when the device is turned on its sense, you know, certain messages in case of ONAP it is rest messages, the module in ONAP that receives them, and then it goes to certain it looks like its own internal databases. So all of that is kind of a well-documented procedure. For example, the PNF vendors can just leave it and don’t have to develop anything extra for this.

And then there is the configuration, the ongoing Lifecycle Management. So, LCM refers to the Lifecycle Manager. So, that includes configuring it from day zero all the way to decommissioning a device. Supposing you have permission for the device, configure it for the first two days of operation and then you keep modifying it depending on the needs, as we talked about earlier, right? So that also kind of leads to the last one, which is creating the control loops or closed loops. So essentially, what you do there is that this configuration or LCM process can be fully automated. Based on certain changes that happened in the environment, let’s say you’ve added because of errors, because of load, or because of, You know, any other, you know, situations which are, you know, which are kind of seen by the operators based on those events, you can make the changes to these devices and, and also the LCM is broader than just configuration, it also means, you know, upgrading the software of the device, upgrading or downgrading, decommissioning the device. So, all of that is part of the life cycle. So, these are all the, you know, parts that are required to be done from the time that the vendor kind of designs the device and, you know, create their own descriptor, all the way to the time that you actually deploy and then keep it in operation. 

And finally, maybe you can decommission the device. So the entire cycle can be managed with very little manual intervention. And so that’s the that’s the whole idea of this whole process. 

PNF Management | What is the equivalence of VNF Manager for PNFs?

Hema Kadia: Sriram, when we talk about VNFs, there is also a concept of a VNF manager. Most of the time, you see that the vendors who bring their own VNFs also have their own VNF manager functionality. Is it similar to what we have in the PNF world? If we come from a legacy perspective, their concepts of EMS and NMS. So how does this all play into when you talk about pre-boarding PNFs and when you’re doing the packaging? Can you elaborate on this as well? 

Sriram Rupanagunta: There are multiple ways you can manage a PNF device. For example, platforms like ONAP have controllers. These controllers have different ways of managing, either PNFs or VNFs that are very similar. For example, you can manage them on Netconf, the standard way of managing these devices, whether PNFs or VNFs, or you can have some Ansible playbooks to run to, to do some configuration, or it may have a chef or other various ways to do these configurations. So, in that sense, the way you do the management of PNFs is similar to the way you do the VNFs. So you go through the controllers, how you can use different ways of managing them using the standard mechanisms, and that’s how the PNFs are handled.

PNF Plug and Play support

Hema Kadia: Sriram, you hinted at the previous question about PNF plug and play. Again, the key aspect is how you can reduce the OPEX. Can you elaborate a little more about the same and what exactly it encompasses? 

Sriram Rupanagunta: The PNF plug-and-play is essential to make the process as seamless as possible. With with, you know, kind of a close to zero-touch and accomplish. The first step we talked about already is a bit of modeling. You create a descriptor, you onboard it, so you do all of that in the design time. So at that time, what happens is that the details of the PNF are also registered in the local databases, which the platform maintains. And so, and then the runtime starts, which is really where the planning comes into play.

So the first is an instance declaration. You describe the PNF, right? So it has its own characteristics. Now, an instance is one particular instance of that PNF. And so when the PNF comes up, somebody turns it on, and then the rest of the process is fully automated. The PNF sends a message to the platform – ONAP or any other platform, and then the entire bootstrapping and discovery, through the registration, happens by a very defined mechanism. Now, though obviously, there are a lot of details which I’m not going to go into, the sequence of operations that happened, in the case of ONAP or any other platform, the point here is that what it’s going to help is as you mentioned right about the OPEX, especially in 5G plan devices, right. So, again, considering that compared to 4g, or the previous generations, the number of base stations are going to be tenfold.

PNF life cycle management and control loop creation

Hema Kadia: Sriram, you also touched on the PNF Lifecycle Management. I think the audience is pretty familiar with how we manage VNF Lifecycle Management and how we scale up and scale down depending upon the business needs. How would you describe the entire lifecycle management process for a PNF? We can take ONAP as an example from an orchestration perspective. 

Sriram Rupanagunta: In most cases, PDFs can be handled similarly to VNFs. In fact, a lot of the ONAP terminology, they’re just called xNFs, so PNFs or VNFs are CNFs. In a lot of operations, though, the goal is to keep it common. Obviously, in some cases, there will be differences, but the logic still it’s, it’s similar. In ONAP, there is a concept of controllers. There are multiple controllers in ONAP, and these controllers can support multiple protocols to manage these devices, be it PNFs or VNFs. In the context of PNFs, again, the PNF device supports, for example, netconf, XML. So you can use any of the controllers in ONAP to manage, configure, or perform all the lifecycle operations of PNFs.

For example, though, cet or apc is one of the controllers, and it supports multiple ways to manage or configure these devices, and all of them can be used for PNFs as well. Similarly, an SDN controller or CDS, which is a controller design studio, has a similar mechanism where you can have multiple ways to manage your devices. So, in that sense, the considerations are very similar, but obviously, being a physical device, there are certain things that don’t make sense, as in the case of VNFs or CNFs, as an example, there is no concept of y scaling out a physical device because it’s some physical device, So, you can just spin up another virtual machine and scale-up, so those things are not applicable for PNF. So, barring such differences in a lot of the other things now can be common, for example, if the PNF device can be modeled using a Yang, which is one of the popular models to model your network device. And so it’s model using YANG, you can pretty much manage in a way similar to the way you manage a VNF; you can change its parameters and maintain multiple copies of these parameters. So all of the functions that you can normally do for virtual functions can also be done for physical functions. And the same thing applies to the controls. And I know we briefly talked about it in the previous slides. So again, you can create a controller, which is very similar to the VNFs control loops, and then, you know, update the parameters or change or change anything on the VNFs.

Summary – Benefits & Challenges

Hema Kadia: Let’s summarize the benefits as well as what are the key challenges that you see on a day-to-day basis.  One of the key challenges when I speak to customers is that there are a number of legacy devices that do not support the standards. They are still dependent upon CLI. We can talk about automation, but at the same time, we know that there are legacy network devices where there is a lack of support for standards. 

Sriram Rupanagunta: I think most of the devices support some of these protocols we talked about. So in case some of them don’t support, you know, there are ways to sort of create some kind of proxy mechanisms or create your own plugins to enable these platforms to support these kinds of legacy devices. Maybe a little bit of customization is required if it is something that doesn’t support any of these standard mechanisms, but to a large extent, a lot of this, the whole idea is that most of these standard protocols are supported so that you know, it’s possible to you know, onboard and manage them without doing a lot of customization. That’s the whole idea. But, you know, you’re right. In some cases, there may be devices that you know, that don’t support some of these protocols. So there may be a little bit of custom development that may be required to support those physical devices. So that’s kind of, you know, that may be one of the challenges in supporting it.

The automation actually starts from the day that you onboard anyway. So there can be thousands of these devices, particularly in the 5G world, considering that these base stations are going to be more. So we will definitely require automation to support all the pieces, not just onboarding but also continuing to configure them. So just to summarize, the steps are first to make sure that the device comes up, it’s onboarded, and it’s recognized by the platform. And then there’s a descriptor, and the vendor provides using which the platform knows how to manage, right? So that’s the first part, and then continue to manage them during its lifecycle, starting with the day zero to day n configuration. And the third part is to make the changes based on the changes, number one, which is the control. So these are kind of broadly the three areas –  onboarding, configuration, and then creating these control loops for automation of the changes. So, that’s kind of the process that’s required for PNFs to be orchestrated and managed again.  

To summarize the importance of automation, all of these steps can be done manually, but it’s not going to be scalable. So, that’s, that’s, that’s the importance of PNF automation.

Download Whitepapers and Magazines:

5G & Edge Edition | 5G Magazine