A: Hitendra Sonny | Kaloom – We see 5G network slicing as providing a mechanism to define a set of logical services. And those modular services share the same end-to-end infrastructure, including all the radios and the data plane, and all the control planes. If we dive a little bit deeper into the power of the 3GPP specs, slices are usually defined by two IDs. One ID like SST is a slice service, which indicates the expected network slice behavior in terms of features and services. And the second ID is SD (Slice differentiator), which is used to differentiate multiple networks and multiple network slices with the same behavior. A: Amar Kapadia | Aarna Networks – Let me explore the relationship angle, the relationship between 5G, edge computing, and network slicing. If you look at the B2B space, 5G is the ideal network to connect end devices to edge computing applications. So that is where those two technologies match up. Before network slicing, a lot of industries would dedicate one workload to one network. With network slicing, you can have sub slices like Sonny mentioned, and each sub slice can have different service level agreements are attributes. That allows you to mix workloads onto the same network. So you can have end devices of different types, edge computing applications of different types going over the same network through network slicing. Â
A: Amar Kapadia | Aarna Networks – The classical use cases, if you go by the standards, are three-plus, maybe one, and they are: latency-sensitive, which is called uRLLC, ultra-reliable low latency, bandwidth-oriented eMBB enhanced mobile broadband, and IoT centric, which is a machine to machine type communication or MMTC. I said three plus one because you also have slices with a security bent. A lot of the government-related work we are seeing requires extremely secure slices. So you can generally say that these are the four, and then you mix and match. And that’s generally the universe of the types of use cases you’ll be supporting with slices. A: Hitendra Sonny | Kaloom – Some specific use cases from a market perspective and what we see from our perspective include smart cities, smart homes, and smart factories. We’ve seen a significant amount of traction in the 4.0 Industry. Having said that, in all the cases, massive IoT, or augmented and virtual reality, comes up a lot. But if I were to double click on the massive IoT use case – now we’re going to be able to take the factories that can deploy the MEC host. So, think of the factory being able to take a MEC host and take that on-site. Now, all IoT devices are there, and they obviously need to communicate with applications. And they need to communicate with each other, and literally the 1000s and 1000s of elements in this network. So, in this case, how are you going to offer and guarantee low latency communication? So it becomes important that you keep all the traffic that needs to remain local with MEC. But, at the same time, keep an eye on a significant amount of traffic that would have to go through the network further beyond for other requirements and other connectivity. We’re actually working with several partners and coming with a blueprint that can be deployed for specific use cases where we can call it a “stamp-it-out” out. It’s not as easy as that, obviously not, but the thing is, this kind of reference architecture does and will help. We also demonstrated with a large telecom service provider – Telenor. Telenor plans to offer enterprise 5G or private 5G services. This demo includes eight different vendors, all running end-to-end on the containerized platform. We’re creating slices & demonstrating that each slice does not end up affecting the other slice. So not only they had multiple customers, per slice, and even per customer, multiple slices. Â
A: Hitendra Sonny | Kaloom – We demonstrated the benefits for two use cases – one for a defense customer and one for a broadcast radio customer. The requirements for both use cases were different. And Amar initially referred to the ultra-reliable low latency (uRLLC), that’s exactly what the requirement was for the defense use case, where any and all devices would have to have the ultra-low latency, and that has to be guaranteed and delivered. Now that just cannot be done in like one size fits all. So they have to have a slice such that absolutely no matter, this low latency guaranteed, will be delivered. Whereas the other customer in there had much more of a high data rate requirement. But we needed to make sure that the other application with high data requirements doesn’t creep into taking away from a common infrastructure and compromise on the low latency requirement. And that’s exactly what we actually demonstrated together, where traffic is going up significantly on one side. Meanwhile, the other side is continued to delivering the low latency without any impact whatsoever. A: Amar Kapadia | Aarna Networks – One different use case that we are seeing is actually in healthcare. In healthcare, Of course, with 5G, you’ve heard about these crazy use cases like remote surgery, etc. We don’t even have to talk about those, I think those are further out. But just the fact that you may have a doctor at a site who doesn’t have the expertise, and you want to pull in another doctor remotely over say augmented reality, those use cases are quite doable these days, with 5G and network slicing. And again, the slice guarantees a certain level of SLA, no matter what is going on in the other slices. So that’s really the value. So if you want to say let’s say, 15 milliseconds of low latency for your remote doctor use case, then you’re guaranteed that no matter what’s going on with the rest of the network. Â
With related 5G and Edge computing use cases beyond the demos and PoCs A: Hitendra Sonny | Kaloom – Let me go back with a specific example. We talked about Telenor where – eight different vendors, eight different solutions, all 5G working end to end all in the container under some kind of control plane function – in a single pane of glass. The purpose was to show the readiness of these technologies & the marketplace. And we absolutely see from our perspective to that solution, we delivered the networking portion of it, which is obviously a key part of the things, we deliver the UPF, which is the call it the workhorse of the 5G network where every traffic, every packet needs to go through that, actually that network, by the way, if you don’t mind me saying that that network actually won the global award for the innovative network of the year or how they phrase it. I’m pretty proud of that. But the reality is there, we are showing interoperability with multiple vendors. And then we gotta go to the next part of operationalizing. So we’re out of the PoCs and the lab, we’re out in the field actually carrying customer traffic. And that’s where I want to end on bringing also the work we’re doing at VCO 3.0 together. We’re doing a lot of work together to create an end-to-end multi-vendor blueprint where the customer benefits from all of the above – no vendor lock-ins, better pricing, better agility, and the ability to innovate. A: Amar Kapadia | Aarna Networks – Let me just add one more point on the readiness. I think the technology is ready. And what we have found is that markets are never really gated by technology. It’s more of the cultural business model, those types of issues. And I think that’s sort of where we’re at right now. Specifically, our Aarna Networks works on the management plane. So my perspective is network slicing from a management point of view. Can we create slices? Can we manage them? Can we manage the lifecycle terminate them, optimize them? So we’ve been working in the open-source communities with companies such as China Mobile, Wipro, Tech Mahindra. And the work has been going on for at least a year, maybe a year and a half on network slicing management. So the implementation that we have through Linux Foundation is completely 3GPP aligned, the management solution is ready. There’s always room for improvement, there are things like optimizing slices, using machine learning to optimize slices for that is pending. But all the nuts and bolts sort of bread and butter stuff on network slicing is ready. So I think from a technology readiness, I would sort of echo the same thing Sonny mentioned. Â
A: Hitendra Sonny | Kaloom – So speaking from Kaloom’s perspective, our initial go-to-market approach has been with service providers. We’re involved with very active conversations, way beyond demos and POCs, into field trials and some deployment conversations – many active conversations with tier one operators. That’s where we have initially focused i.e. the use cases they all are looking at – from the mobile world and enterprise world. The thing is, they’re focused on the enterprise side as well. Now, of course, there’s cloud as a portion that’s always involved. So the termination or connecting to the cloud, and then going all the way. As mentioned earlier, we are creating a reference architecture with multiple partners – focus on industry 4.0. We’re providing programmable networking, fabric, and UPF. The UPF is further able to be sliced and multiple UPFs in the same infrastructure, each UPF having its own capabilities of slicing and what have you. It takes a village to deliver, it takes many partners. And one of the key requirements for deployment is the management & orchestration of network slices.Â
A: Amar Kapadia | Aarna Networks – Let me talk about our product and then I’ll also talk a little bit more about the blueprint that Sonny has mentioned VCO 3.0, and we’ll touch upon how the two companies are collaborating on network slicing. Our product is an open-source product, and it’s called the Aarna Networks Multi-Cluster Orchestration Platform (AMCOP). It is effectively the management plane for 5G networks and edge computing applications both because our philosophy is that you only have one edge, so you can’t have two management planes, one for networking and one for edge computing fighting for resources. Our product does initial orchestration of 5G network services, edge computing applications, ongoing Lifecycle Management, Day 1 and 2 configurations, and automated Service Assurance, which is nothing but fixing problems automatically via closed-loop automation. In addition, we do things like network slicing, machine learning-based analytics, for example, non-real-time RIC (NONRTRIC) network data analytics function (NWDAF). We have about seven or eight active POCs going on with a few going into production in the next quarter. We are working on a Linux Foundation networking blueprint, which used to be called VCO 3.0. The new name is the Cloud Native 5G Blueprint.
The Cloud Native 5G Blueprint is based on the idea, as Sonny said, it takes a village to do this. It’s a multi-party collaboration. So we have companies like Kaloom and Aarna networks, for sure. But we also have Red Hat, we have Capgemini Engineering, we have A10, we have Intel, GenXComm, and Turnim. So what we are doing is we are creating a blueprint that initially is for private 5G networks over CBRS. And we are building an end-to-end 5G network. In addition to that, we are also doing core slicing. Ultimately, we will extend it to RAN slicing, transport slicing, as well to do end to end slicing. But for now, the focus is core slicing where we collaborated using our product AMCOP. The core is a mix of the Capgemini Engineering 5G core with the Kaloom UPF. So we have successfully done that and now we’re doing test & integration on that implementation.
A: Hitendra Sonny | Kaloom – In this context, Kaloom basically provides the NETCONF or Yang-based model upstream. And Aarna and other partners that Aarna works with beyond can all take from that northbound, and chances are, as you talk about, management orchestration is a huge piece. It’s a humongous deal, right. So there may even be further northbound to deliver end to end. But the end result is these are all open standards, industry-based standards, we all are working together. Â
A: Amar Kapadia | Aarna Networks – Yes, so I can maybe cover the management part. And then I’ll hand it over to Sonny for the full picture. On the network slicing management in terms of what’s there in the future, I think the future is extremely interesting in terms of network slice optimization. And that’s where we will introduce the fourth technology. So you mentioned 5G, you mentioned edge computing, you mentioned slicing. We will introduce machine learning. So machine learning will be able to see the usage and the utilization of the slice. And in real-time, make optimizations. So that’s the next big thing from our standpoint is how to optimize the slices because all the bread and butter stuff has been done creating slices, terminating them, configuring them — all done. We are also looking forward to actually getting this into many, many customers. We have trials going on, hopefully going into production by early next year. But next year, we hope that slicing will proliferate. So those are the two things I’m looking forward to. Â
A: Amar Kapadia | Aarna Networks – In theory, it should be plug-and-play. So if you follow the 3GPP standards for 5G core, if you follow O-RAN standards for your RAN, for slicing, if you follow similar standards, 3GPP, and O-RAN, and on the transport side IETF, it should be plug and play. But there is no such thing as plug and play in real life. Nobody complies with the standards perfectly. So what you end up having to do is to make adjustments. From our standpoint, we can make adjustments on either end. Either we can make an adjustment on the network function side. So the 5G core or the RAN can make tweaks to be better aligned to the standards, or our offering is a platform. So we can make adjustments and adapt to what the network function offers. So you have different standards for orchestration, it may be Helm charts for configuration, it may be Yang net con for the rest APIs, for data collection and analytics, it might be VES, HV-VES, and other formats.
Maybe more specifically on slicing, there is a component called the NSSMF network slice subnet management function. The NSSMF is the one that interfaces between the management stack, network slice management stack, and the network function. We are leveraging through LF standard NSSMFs apps for core, RAN, and transport that are standards-compliant. If the network function is completely standards-compliant, great. If not, we develop a custom NSSMF to adapt to the different vendors.
A: Hitendra Sonny | Kaloom – As Amar said that things don’t work plug and play, but it’s not as bad as plug and pray either. I’ll give two examples. In the context of the UPF that we provide, we work with AMF and SMF provided by large incumbent vendors or some upstarts. Initially, it took a long time with everybody’s implementation. But we’ve watched over time, and it gets easier and easier. Similar thing on the orchestration side. When our first customer asked us to do orchestration with one specific tool that they had chosen – it took us about six weeks to work together. Subsequently, we’ve done with three or four vendors. And we’ve got it down to days now. From the technology side – network slicing has to scale at a very high level, both from a bandwidth perspective and from a subscriber number perspective. It also has to maintain the latency. But the last one that many people forget about and we talk a lot about is SASE – that is security is going to be kept in mind 100% as well. We do it in the hardware on P4 enabled hardware and fabrics that we use that bring some amount of security inherent into there. Â
A: Hitendra Sonny | Kaloom – If we look at the customers in this perspective, enterprise or service provider, the end game is you’ve got to be able to offer differentiated services. Differentiated services for which you would charge for if you’re a service provider – different services where you could guarantee certain services to your internal BUs (business units) or external customers. And that to us is when you put it all together is the huge benefit to bring the differentiated services of many things that Amar and I discussed over time. So I think that’s the name of the game. And that’s the exciting part, both for the enterprise and service provider customers. That’s the end benefit. A: Amar Kapadia | Aarna Networks – Ultimately, all this technology has to serve a purpose. And what is that purpose? For a service provider, it’s to increase the potential revenue. We all know that the average revenue per user, ARPU, is only going down. So how can we expect the service providers to roll out such a CAPEX intensive 5g network? And it’s through techniques such as this. Edge computing applications, network slicing, are the ways they can make more revenue. When it comes to enterprise, it’s not so much about increasing the ARPU. That’s not the case. But it’s cutting OPEX. So how do you get OPEX for your environment? How do you improve your customer satisfaction? How do you roll out new services faster? So I think that’s ultimately the promise of network slicing.
Subscribe for industry insights. Elevate your influence – promote with us!
