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 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 2 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. 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. 

    Physical network functions are devices that have not yet migrated to the 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 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 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, 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.

    The 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 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. And there may be some analytics functions, which look 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 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 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 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 steps. And so, in that sense, it’s kind of a subset of what you do in the 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 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, 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 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’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 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 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, 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 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, 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 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 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 cases, PDFs can be handled similarly to VNFs. In fact, a lot of the ONAP terminology, they’re just called as 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 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 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, 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 that 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 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 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, 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 they 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 from the time that you onboard anyway. 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.

    5G Magazine

    5G Infographic

    5G Network Rollouts

    Featured Content

    5G Use Cases

    Ericsson US Smart Factory

    Ericsson Smart Factory: Sustainable and Energy-Efficient

    Ericsson’s smart factory based in Texas, US builts 5G and advanced antenna systems radios. The smart factory is 25% more energy-efficient, produces 17% of required power on-site via solar panels, uses 40,000-gallon tanks to collect & reuse rainwater, and reduces shipping distance up to 5 times.

    Private 5G Strategies

    Private Networks Strategy for Edge & Cloud Vendors - TeckNexus

    Edge & cloud vendors: How to become telcos for private 5G networks?

    The journey from edge to becoming private 5G telcos The cloud and edge vendors are taking various approaches to target enterprise customers for Private 5G networks. Sample private network strategies of edge and cloud vendors include: Acquisitions of network equipment & technology vendors Building an ecosystem of partners across companies with telecom expertise Advancing and

    Private Networks LTE/5G Strategy of Network Equipment Vendors | TeckNexus

    What is private network strategy of network equipment vendors? sell with or without operators?

    The network equipment vendors are taking various approaches to win the private network enterprise business.   Sample strategies include: Selling to Enterprises via Partnerships with Mobile Network Operators Selling directly to Enterprises (without spectrum from Mobile Network Operators) Selling to Enterprises with System Integrators or Private Network Specialists  In this article, we are focusing on the

    Private Networks Strategy of Mobile Network Operators | TeckNexus

    What is the private networks strategy of mobile network operators?

    The private network strategy of mobile operators varies based on several criteria such as: Brownfield operator vs. Green field operator How to monetize the platform? How to scale globally? What is a regional strategy? What is the cellular technology – 5G vs. CBRS vs. LTE networks? In this article, we are going to focus on

    5G Research Reports

    5G for smart manufacturing | smart factory | industry 4.0 report - TeckNexus

    5G in Smart Manufacturing

    The 5G in Smart Manufacturing report provides in-depth global and regional insights on the related use cases, technologies, drivers, expected benefits, challenges, ecosystem players, roles of the ecosystem players, industry leaders, startups disruptive this space, and more.

    TeckNexus - 5G and monetization strategies

    5G Monetization Strategies

    The 5G monetization strategies report provides in-depth global and regional insights pricing strategies for retail (B2C) and enterprise (B2B) segments, related ecosystem players, partnership models, and startups offering unique offerings.

    TeckNexus - 5G for Healthcare

    5G for Smart Healthcare

    The 5G for smart healthcare report provides in-depth global and regional insights on the related use cases, technologies, drivers, expected benefits, challenges, ecosystem players, roles of the ecosystem players, industry leaders, startups disruptive this space, and more.

    TeckNexus - 5G for Energy and Utilities Industry Report

    5G in Smart Energy & Utilities

    The 5G in energy and utility report provides in-depth global and regional insights on the related use cases, technologies, drivers, expected benefits, challenges, ecosystem players, roles of the ecosystem players, industry leaders, startups disruptive this space, and more.

    TeckNexus - 5G and transportation industry report

    5G in Smart Transportation

    The 5G in Transport report provides in-depth global and regional insights on the related use cases, technologies, drivers, expected benefits, challenges, ecosystem players, roles of the ecosystem players, industry leaders, startups disruptive this space, and more.

    5G Companies

    Gladiator Innovations LLC

    Gladiator Innovations is a wireless analytics company specializing in network drive test data processing, report generation, network optimization & analysis by providing: Designed for the wireless industry professionals, G-Suite Pro provides engineering software tools on the desktop and cloud as a part of an end-to-end service assurance platform. With automation in focus, G-Suite Pro provides

    Read More »

    Bwtech

    Bwtech is a company focused on software development and integration of solutions for mobile operators and regulators. It provides solutions for more than 20 major carriers across Latin America, the Middle East, Asia, Africa and Europe. NetChart, Bwtech’s main solution, is a cloud-based tool for end-to-end monitoring and optimization of mobile networks. It has Configuration

    Read More »

    Radcom

    RADCOM (Nasdaq: RDCM) is the leading expert in cloud-native, automated service assurance solutions for telecom operators transitioning to non-standalone and standalone 5G networks. RADCOM ACE is an automated 5G assurance platform that seamlessly integrates with Kubernetes to provide a closed-loop approach to assurance for Non-Standalone (NSA) and Standalone (SA) 5G. Being Service Based Architecture (SBA)

    Read More »

    Seashore Networks

    Seashore Networks has a strong focus on leveraging software to build great last mile networks starting with 4G 5G. Seashore provides 4G and 5G open virtualized radio access network software that supports open interfaces and virtualizes the baseband unit to build a disaggregated multi-vendor, web-scale, cloud-native mobile network. It opens interfaces for operators to add

    Read More »

    arQana Technologies

    arQana Technologies designs and develops integrated circuits, modules, and subsystems for radio frequency, microwave, and mm-wave applications. The company product range is comprised of power amplifiers, driver amplifiers, and low noise amplifiers, along with control components, including switches, attenuators, and phase shifters, that target phased array antenna system solutions in Wireless Infrastructure, Aerospace & Defence

    Read More »

    NFWare

    NFWare develops high-performance VNFs which are based on a brand-new technology for fast packet processing. We provide level of performance and reliability which was historically associated only with proprietary hardware. Our solutions are purpose-built to be deployed on standard x86 servers and designed for virtualized and cloud environments. NFWare’s product portfolio includes Virtual Carrier-Grade NAT

    Read More »

    APITech

    Got 5G? APITech’s high-performance testing tools empower your successful roll-out across the spectrum. To support the development, verification, and testing of 5G and Wi-Fi networks, services, and devices, including for Wi-Fi 6E, both tech giants and industry upstarts rely on APITech’s extensive portfolio of Programmable Attenuators, Switch/Attenuation/Phase Shifter Matrices, MIMO and beamforming accessories, and customized

    Read More »

    CableFree: Wireless Excellence

    CableFree: Wireless Excellence designs and manufactures a complete range of Wireless Communication products including 5G & 4G Infrastructure solutions. The CableFree range includes advanced Software-Defined 4G & 5G LTE Macro & Small Cell Base Stations for ultra high performance & flexibility. CableFree also offer Microwave, Millimeter Wave, Free Space Optics and MIMO Radio backhaul plus

    Read More »

    DZS

    DZS Inc. (NSDQ: DZSI) is a global provider of leading-edge access, 5G transport, and enterprise communications platforms that enable the hyper-connected world. A pioneer in disaggregated platforms, SDN, and virtualization, service providers and enterprises look to DZS for the innovation that leads to future-proof networks and outstanding performance. Over 1,200 service providers, operators, and enterprises

    Read More »

    Polystar

    Polystar is a leading provider of real-time monitoring and analytics platforms to more than 100 CSPs worldwide. The company´s solutions deliver tailored insights into network, service and OTT application performance. These insights allow stakeholders to enhance customer experience, operational efficiency, and identify new revenue streams from data monetisation. Polystar’s products enable the smooth introduction of

    Read More »

    Additional 5G Tech Talks | Fireside Chats

    Scroll to Top
    Receive the latest content
    Subscribe To Our Newsletter

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