Featured Vendor
5G Series Sponsor
TeckNexus
5G Series Host
In this 5G Fireside chat series, Hema Kadia from TeckNexus discusses with Sriram (Co-founder and Head of Engineering) at Aarna Networks, Physical Network Functions (PNFs) support and relevance in 5G. In this context, we cover - what is PNF, what elements of PNFs can be automated, what are similarities with VNF onboarding, PNF life cycle management, PNF plug and play support, and PNF automation benefits & challenges.
5G Chat Topics
    Add a header to begin generating the table of contents
    Scroll to Top

    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 physical network function (PNF) support & relevance in 5G?

    Hema Kadia  

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

    Sriram Rupanagunta  

    There are 2 categories of these physical functions:

    Physical 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. And 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. 

    Devices that have not yet migrated to the virtual functions

    There  are a bunch of devices which 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 them to virtual functions. So in that case, you want to keep them as PNFs. Now, the importance is that you know, even though your entire network service is virtualized or containerized, there will continue to be these physical devices which will stay as PNFs. So that’s the importance of having these PNFs.

    PNF automation – What needs to be automated & why? What are similarities with VNF automation?  

    Hema Kadia  

    Sriram, one of the things that we always hear about is VNF lifecycle management or how the orchestrators – whether it is ONAP, or OSM MANO, or vendor specific orchestration & management functions, they 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 3 aspects that you have to look at from a PNFs 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.

    Second part of that same functionality is PNFs 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. And 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 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. And there may be some analytics functions, which looks at all of these, analyzes them and provides 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 there 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 is PNF onboarding process, 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 vendor the PNF vendor has to do, say 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. The 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 case of PNF, what you do is you essentially onboard this PNFs. So whatever package that you have from you get from the vendor you onboard it, make sure there are no errors and so on. And then you upload these packages to the design, whatever is your design controller in 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 other steps. And so, in that sense, it’s kind of a subset of what you do in case of VNFs, for uploads.

    And 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 is the, 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 PNFs 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. And 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. Which 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, the LCM refers to the Lifecycle Manager. So, that includes configuring it from day zero all the way to decommission a device. Supposing you permission the device, configure it for the first two days 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’re 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 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 then decommission the device. So the entire cycle can be managed with very little manual intervention. And so that’s 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 like in the PNF world. If we come from a legacy perspective, there concept 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 very similar. For example, you can manage them on Netconf, 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, 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. And, again, the key aspect is how can you 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 essentially 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 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, 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 of the cases, PDFs can be handled similar to VNFs. In fact, a lot of the ONAP terminology, they’re just called as xNFs, so PNFs or VNFs are CNFs. 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 or configure or to 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 these or configure these devices and all of them can be used for PNFs as well. Similarly 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 case of VNFs or CNFs, as 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, maintain multiple copies of these parameters. So all of the 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 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 that when I speak to customers is that there are a number of legacy devices which 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 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 creating some kind of proxy mechanisms or creating your own plugins, to enable these platforms to support these kinds of legacy devices. Maybe a little bit of a customization that’s 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, on- board and manage them without doing 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 they may be a little bit of a custom development that may be required to to support those physical devices. So that’s that’s kind of a you know, that may be one of the challenges in supporting it.

    The automation actually starts from the day from the time that you onboard anyways. So they can be, thousands of these devices, and 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, 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 and 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.

    Sriram Rupanagunta 

    Co-Founder & Head of Engineering at Aarna Networks
    Sriram Rupanagunta  is a co-founder at Aarna Networks, Inc, and heads their engineering team.  Aarna Networks provides commercial distribution of ONAP. Prior to Aarna, Sriram was the Head of India Engineering at Data Center Business of  Western Digital Corp, responsible for the development of ActiveScale product line from India development center.Prior to Western Digital, Sriram was with the SSD based startup Virident Systems (which was acquired by Western Digital). Earlier to that, Sriram was also the co-founder of start up Aarohi Communications which was acquired by Emulex Corporation, and was the Vice President, Technology at Emulex. He lives in Bangalore, India with his wife and a daughter.

    Join 5G Fireside Chat Series

    By submitting this from, you agree to our Terms & Conditions and Privacy Policy.

    5G Ecosystem Landscape
    How to join 5G Ecosystem?

    We will review the company and product descriptions for consideration into the next monthly update of 5G Ecosystem.

    Need help? [email protected]

    Signup For Our Newsletter

    Related 5G Fireside Chats

    TeckNexus - 5G Fireside chat on Lean NFV

    Lean NFV: Accelerating the adoption of NFV and the deployment of 5G

    In this 5G Fireside chat series, Hema Kadia from TeckNexus discusses with Dan Pitt “How Lean NFV can accelerate the adoption of NFV and deployment of 5G.” In this context, we cover, what is Lean NFV, what are the business drivers for Lean NFV, comparison with ETSI NFV, the Lean NFV Key-Value Store (KVS) concept, how Lean NFV will accelerate the adoption of ETSI NFV and 5G, and more.

    Read More »
    TeckNexus 5G Fireside chat series - 5G Introduction with Nokia

    5G Introduction – Concepts, Use cases, Architecture and Technologies

    In this 5G Fireside chat series, Hema Kadia from TeckNexus discusses with Ben Cheung, Ph.D. Systems Architect at Nokia and ONAP RAN Architecture, 5G key concepts. In this 5G introduction chat, we cover – what is 5G, the 3 key 5G concepts i.e. enhanced mobile broadband (eMBB), massive machine type communications (mMTC) and ultra reliable low latency communications (URLLC), high level 5G architecture and key technologies (including those we plan to cover in future 5G Fireside chat series).

    Read More »
    TeckNexus 5G fireside chat series with Zeetta Networks CEO Vas for Network Slicing & Splcing for Industry 4.0 Use Cases

    5G Network Slicing & Splicing for Industry 4.0 Use Cases

    In this 5G Fireside chat series, Hema Kadia from TeckNexus discusses with Vassilis Seferidis, CEO and Co-founder of Zeetta Networks, 5G Network Slicing & Splicing for Industry 4.0 Use Cases. In this context, we cover – what is network slicing & splicing, what are the industry 4.0 use cases where network slicing & splicing is being used, how is the network slicing done across mulitple networks (e.g. fiber, mmWave, 5G public network), what are the challenges and benefits and beyond industry 4.0 where network slicing is being leveraged.

    Read More »
    Scroll to Top
    Receive the latest content
    Subscribe To Our Newsletter

    Get notified about 5G ecoystem updates, firechat series, vblogs, insights & more.