This episode gives a concise logical description of network slicing, and it comes from the course “Network Slicing in an Hour”.

If you enjoyed this Apis Tech Tip, check out the full Apis course ” Network Slicing in an Hour” where this video came from. There you will get a condensed view of the 5G Network slicing feature as defined by the 3GPP. It presents operational benefits and explains the technology needed to realize network slicing in 5G.

Here are some of the topics that are covered in “Network Slicing in an Hour”:

• Network Slicing: Overall Perspective
• Technological Aspects of Network Slicing
• Business Aspects of Network Slicing

To learn more about this course, go to https://apistraining.com/portfolio/network-slicing-in-an-hour/

This TechTip is also part of a whole eBook of tips, all focusing on 5G technology. We call it an eBook+ since all chapters are both text and video. If you want to read the text, you can do that, and if you want to watch a teacher tell the story, you can choose that.

All the video chapters are excerpts taken directly from our recorded lessons, so if one of them piques your interest, you can easily go to the course and dive deeper into that particular subject.

This particular eBook+ is called “5G Demystified: Use Cases, Architecture, and More”, and you only need to CLICK HERE to request it for immediate download.

Below you can find the transcribed text for this particular TechTip.

What Is Network Slicing?

I would like to start us off with an overall picture, just putting together some of the most important information about network slicing. A network slice is a logical network that is kind of placed on top. It’s an overlay on an actual physical infrastructure. And the purpose of having this logical network is to have use case-specific settings, which means it’s no longer one-size-fits-all.

Now, looking at the image, the boxes in the green, red, and blue shapes are supposed to represent the physical infrastructure that we are going to be using. And just to be clear, such a box can mean a physical piece of equipment. ”Compute” means processing power, ”storage” means databases, and ”networking” means the cabling that interconnects them. So, these three would be physical things.

But such a box can just as well be a specialized piece of software. It can be something virtual. Virtual machines is a term that comes to mind, but other solutions for virtualization exist. We can talk about containers, and we can talk about microservices. These are techniques for virtualization, and they can be applied in the 5G Network Functions or the 5G network services.

So, these boxes are not necessarily physical things, but they are our resources. And what we are going to do now is we are going to overlay things onto that actual infrastructure. We are going to overlay our, in my example, three different logical networks (coloured shapes). Each and every one of these three different logical networks has well-defined capabilities and is going to handle certain groups of services.

The divisions between logical networks and the network definitions are going to be a result of the operator discussing with its customers what it is they actually need. The key things about the different logical networks are two buzzwords. The network resources for a network slice are dedicated, and the network resources between different slices are independent of one another.

This is the biggest benefit of having network slicing. So, let’s make sure we understand these words. Dedicated resources. What does the term ”dedicated” mean? First of all, it can mean dedicated to certain services, which means that we prepare our capabilities in this logical network to fit the needs of a certain type of application. And then we can call this package a communication service.

For a particular communication service, we will define its characteristics. These can be the quality of service, mobility, power-saving mode, battery saving, these kinds of things. The list of characteristics can be really, really long. So, you can have resources that are dedicated to a particular service or application.

The other way of having dedicated resources carries yet another benefit of network slicing with it. You can have resources dedicated to different customers, and this means that a network slice becomes a business proposal. It becomes something tangible that an operator can sell to another company and put a price tag on.

So, who are these customers? The term ”vertical” started being quite big in the 5G environment. Verticals are simply different business players of a certain type. From time to time, we talk about private networks. A network slice can be offered as a service, and then it can be, for example, a private network. And generally, a Network Slice as a service is a business offer.

You might know the abbreviation MVNO, Mobile Virtual Network Operator. They’ve been around for years, and it’s basically a different brand name, a different business, but the owner of that business sits on top of an actual operator’s infrastructure. And mobile virtual network operators are among the customers that can use a network slice.

I am talking about a world in which a mobile operator has an operation and maintenance system, and somewhere in the war room, a person pushes one button, and a completely new virtual network pops up. And that’s all the work that needs to be done. Of course, I’m a bit simplistic here. There is a lot of work around it, but that’s at least the direction that we are heading.

So, the resources can be dedicated either to a service or to a customer. What about the other term, ”independent”? This actually boils down to another keyword in the network: isolation in 5G slicing. Independent means that things that happen in the green network slice don’t affect whatever is happening in the blue one and vice versa. That’s isolation.

Maybe you’ve noticed I’m being a little vague on purpose. What does it mean that things that are happening don’t affect other things? It’s not the very technical term, the word isolation. A lot of people interpret it to mean isolation of resources. But please notice that isolation can refer to a whole number of aspects.

You can have isolation of functions, configurations, policies for resource usage, failure domains, and security domains. This is a big, big term. What I’m saying is that we can have isolation between slices, and this is a big benefit. This is what the operators are after.

Now, speaking of benefits, at the bottom of the illustration, I’ve tried to compile a list that summarizes what is seen as the most important things we gain with network slicing. The first statement, I would guess, is quite straightforward. It simply says that network slicing allows us to support the services and verticals that we have identified. They need this, and we are addressing a need on the market that we are aware of.

On top of that, we also have new use cases. With the tool that network slicing is, we can actually come up with new and interesting offers. This can be both for individual customers and for enterprises like the Network Slice as-a-service, for example, towards MVNOs. The technology itself, from an operator’s perspective, must be reasonably cheap, though. It’s the whole profitability question.

Next comes scalability. Resources can be allocated according to need, and this can be done dynamically. Where does this come from? Well, from the fact that the logical networks that I’m talking about are using the underlying enabler of virtualization. So this is actually a benefit that comes together with the technology that we are using.

We also get fewer dependencies and consequences to consider at the start of a dedicated network for a new service. This is a very important statement because if we are starting to talk about a world in which one operator of this physical infrastructure has to carry a number of logical overlay networks, this is a level of complexity that can be absolutely startling. So this bullet point essentially says, don’t worry if you add yet another network slice onto your network. You might, of course, have problems with this particular network slice. But the other already up-and-running slices will not be affected, which is an important statement in its own right.

This independence also has another effect, and that’s the last bullet point. If I can add a new logical slice onto a live network without affecting the other elements, well, this makes it a fantastic sandbox for testing new ideas. So, the network slicing feature makes it easier to develop our service offer.

Until now, I was talking about the network slicing concept on a generic level, but the actual term network slicing comes from the standards of the Third Generation Partnership Project (3GPP). So, to stick to the naming convention, we have to know where the naming comes from, and the network feature and the 3GPP standards of overlaying logical networks did not start in 5G.

I just want you to be aware of the term dedicated core networks, sometimes referred to as DECOR. Dedicated core networks is an equivalent feature that was introduced for a 4G environment. So, it was for the LTE or for the evolved packet core (EPC), and these definitions can also be applied to 2G and 3G.

Having said that, dedicated core networks is a feature that exists, but pretty much just on paper or in the form of bits in files. To put it mildly, it’s not heavily used, but the corresponding solution in 5G is actually viewed as the absolute cornerstone of the extra features that we are going to get with 5G.

So, it’s a feature that is almost unused in 2G/3G/4G but expected to be a basic feature of 5G. Interesting. We’ve simply evolved to the point in time when deploying this makes a lot of sense to us. On the left of the illustration is a small picture, which is supposed to show us an overview from an architectural perspective of what a network slice is.

So you can see on the left the RAN or the radio access network. I’m not trying to say that the RAN is a cloud environment. I just use a cloud shape to say that this is one physical radio access network with its corresponding transmission and reception. And at the end, the radio interface towards an end-user device, the user equipment (UE). It’s wireless access; it’s a radio access network.

On the right side of this small part of the illustration is my 5G core. A network slice is the access network part plus the core network part. So, it spans all the way across the access and core network down to the user equipment.

If you look at this basic definition, have you noticed that these two network slices are represented with different colors (pink and green)? But they both go to the same device. This is just to underline the fact that one user equipment can use multiple network slices. What’s more, we expect that this is what will be happening.

So, if this is an image that summarizes everything, let’s not forget that network slicing sits on top of the underlying technology, which is virtualization. So, virtualization is a must if we want to have network slicing.

And if we have more and more and more of these logical networks placed on top of a physical infrastructure, this does introduce other issues as well. Like the scalability of what I like to call satellite systems around the actual transportation network, the most important of which I think is operation and maintenance. So, let’s not forget that operation and maintenance of a huge number of logical networks running on our physical network is a challenge in and of itself.

This episode explains the three main use cases that 5G was originally written for, and it comes from the course “5G Core Network in an Hour”.

If you enjoyed this Apis Tech Tip, check out the full Apis course ” 5G Core Network in an Hour” where this video came from. The course offers a condensed view of the 5G Core Network as specified by 3GPP, while also summarizing important improvements and new concepts when comparing with 4G.

Here are some of the topics that are covered in “5G Core Network in an Hour”:

• Rationale behind defining a new system: why not LTE?
• 5G Deployment Options
• Service Based Architecture, SBA
• 5G Core Network Features
• Resource Definitions for 5G
• Service Influencing

To learn more about this course, go to https://apistraining.com/portfolio/5g-core-network-in-an-hour/

This TechTip is also part of a whole eBook of tips, all focusing on 5G technology. We call it an eBook+ since all chapters are both text and video. If you want to read the text, you can do that, and if you want to watch a teacher tell the story, you can choose that.

All the video chapters are excerpts taken directly from our recorded lessons, so if one of them piques your interest, you can easily go to the course and dive deeper into that particular subject.

This particular eBook+ is called “5G Demystified: Use Cases, Architecture, and More”, and you only need to CLICK HERE to request it for immediate download.

Below you can find the transcribed text for this particular TechTip.

The 5G Use Cases

If you look at the image, these are the original 5G use cases that I would like to start with.

It’s a well-known picture with a triangle where we say that the telecom system that we are designing will have to be able to handle applications that have certain characteristics. Originally, we found three groups of applications that need to be addressed. The top group of applications are the ones that require high throughput. This is their focus. They are going to need enhanced mobile broadband, eMBB.

You can see some examples: 3D video, ultra-high definition screens, augmented reality, and the voice service, the normal telephony service used by people, also falls into this group.

Then, another set of needs over on the left. Smart home. Smart building. Smart city. This is what we could refer to as Internet of Things, or machine-type communication. The main challenge here is that there are so many of these things, so massive machine-type communication (mMTC) is a bunch of applications that we will want to handle within the 5G system.

This large triangle portrays the original 5G use cases. And as time proceeded, we managed actually to figure out that there is a group that needs to be kind of taken out of there, that has special needs that make it slightly different to cater for: The so-called ”High-performance Machine-Type Communication” (HMTC). This means that some of the applications in this group will actually need high throughput, and therefore they should be treated differently than the original IoT devices that we were analyzing when the original triangle was built.

And then the third part of the triangle over on the right, URLLC, or ultra-reliable and low-latency communication. These are applications that require either very high reliability or low latencies, or in the worst case both, when it comes to quality of service. Industry, automation, and mission-critical applications are here, and self-driving cars, which again, over time, got taken out of their original category and got their own category defined.

The V2X is now one of the five 5G use cases as opposed to the original when we had only three of them. The idea is going to be that when we are designing the 5G system, we will keep in mind that we would like to be able to carry a variety of applications with their different requirements from one another on physical networks, and they are no longer following the rule of one size fits all.

This episode covers the most important concepts used in NFV and comes from the course NFV MANO in an Hour.   

If you found this Apis TechTip interesting, you’ll want to check out our full course NFV MANO in an Hour. The course uses as a starting point the main ETSI NFV architecture with its building blocks, and then focuses its attention on the Management and Orchestration (or MANO) functions.  

The course covers the following topics: 

• ETSI NFV  
• MANO Functions  
• The NFV Network Service  
• Network Service Instantiation  
• On-Boarding  
• Scaling

Read more about NFV MANO here: https://apistraining.com/portfolio/nfv-mano-in-an-hour/ 

This TechTip is also part of a whole eBook of tips, all focusing on Cloud technology. We call it an eBook+ since all chapters are both text and video. If you want to read the text, you can do that, and if you want to watch a teacher tell the story, you can choose that.

All the video chapters are excerpts taken directly from our recorded lessons, so if one of them piques your interest, you can easily go to the course and dive deeper into that particular subject.

This particular eBook+ is called “Cloud Chronicles: A Journey into a Virtualized and Software-Defined World“, and you only need to CLICK HERE to request it for immediate download.

Below you can find the transcribed text for this particular TechTip.

NFV in a Nutshell

The purpose of NFV is to be able to virtualize network functions that were previously not virtualized. To do this, we create VNFs, virtualized network functions. Previously we had NFs, network functions, which means physical things. You buy them, you unpack them from a box, you can drop them on your toes, and then you pick them up, and you put them in a rack somewhere in a data center, and you configure it and put cables in it and so on.

Virtualized network functions are based completely on standard virtualization. So a VNF is the virtual version of a previously non-virtualized network function. This all runs in the NFVI, NFV Infrastructure, because that’s where we have the real hardware resources. The real hardware resources come in this holy trinity of cloud computing resources, which is usually divided into compute, storage, and network.

And then we have the technology to virtualize these things. Sometimes you will see a big box that just says” virtualization” or” virtualization layer” or something like that. I think that’s a little bit fooling the audience because the technology to virtualize a server is very different from the technology used to virtualize a hard drive or a switch or a router, or a cable. That’s why we like to separate these three kinds of resources and their virtualization methods.
We then want to manage these things from somewhere so we have the good old OSS/BSS. That’s the operations and business support systems.

From here, we will want to be able to create VNFs running as virtual machines or containers in the NFVI. But how do we do this?

Well, we can manage them with normal OSS/BSS surveillance and maintenance. If you can’t do that directly to the VNF, there’s something called an Element Manager or EM that can sit as a sort of translation function. But note here that the EM, the element manager, is not a mandatory function to have. You can live without any EMs at all.

What you can’t live without is the MANO on the right side of the picture. That’s the Management and Orchestration of the NFV architecture. MANO has become a word, so you pretty much never say “Let’s look into the management and orchestration.” Instead, you say “Look in the MANO.” Or you can say “We’re going to have a MANO meeting this afternoon to discuss what MANO software we’re going to use. There are some MANO providers here to sell their stuff to us, and we’ll have a little MANO chat after that to discuss which MANO to choose.” So MANO really has become a word unto its own.
Inside MANO, there are no fewer than three different functions. Starting from the bottom. We have the VIM, which is the Virtual Infrastructure Manager, which is the only one that talks to the NFVI. So it’s the one that actually sends commands to start and stop virtual machines, to mount storage to those virtual machines, and to create virtual networks with virtual switches and things like that. That’s the VIM, the lowermost part of the MANO.

If we take one step up, we come to the VNF Manager, which is a pretty good name, actually. It does what it says on the tin. It manages VNFs. What does buying a VNF mean? Previously, when you bought a network function, you bought something physical. You put it in the back of your car, and you rode it over to the data center and installed it. Now, with VNFs, you essentially buy software. You can download the software or buy a disk with that software.

That’s what the VNF actually consists of. But the idea is that you also get a VNF manager with that VNF because a VNF manager knows its VNF very well. It knows how to handle it, how to start it, how to stop it, how to scale it to make it bigger or smaller, and how to repair it if it starts acting up.
You can have a generic VNF manager that can send basic commands like start and stop. But if you want to have more specific handling of your VNF, that may require more specific knowledge. If you’re going to make it bigger, perhaps you need to start increasing this particular little function up in one corner before you then increase this little function down there in that other corner.

These are things that wouldn’t be known by a generic VNF manager, but they could be known by a specific VNF manager. And we can have several VNF managers, as it says in the image, to cover our different VNFs.

And finally, on top, sits the boss, the NFVO or NFV orchestrator. The NFV orchestrator is the only one that talks to the OSS/BSS, and it does orchestration, which is a word that means higher level management, with largely automatic management.

It handles large complex systems and not so much the details in those systems. So whereas the VIM at the bottom knows about virtual machines and containers, it does not know how they form VNFs. The VNF manager knows which virtual machines and containers comprise a particular VNF, but it does not know how those VNFs come together to build a larger network service.

The orchestrator knows about network services; it knows how VNFs can be connected together. So we have mentioned a few terms and objects that we can play around with, VNFs and Network Services. Those terms are very important. Before we move on to talk about which other objects we can play around with in the NFV playground, let’s just note here that the lines between the boxes have names, and those can be useful if you want to find out from a standard what goes on between two different functions in the NFV architecture.

I’ve been in the telecommunication training business for two decades now, and it has always been a little bit vague and mysterious how to tell interfaces from reference points. To me, those two things have always been fairly similar and largely interchangeable, sometimes almost completely synonymous. And the standards that I have read have really not made a great distinction between the two. ETSI, who created NFV, really do distinguish between them in the NFV papers.

The lines in the image are reference points. The names that are on these lines are names of reference points. And those reference points can then offer a number of interfaces. And just to give you an idea, all these reference points offer somewhere between five and fifteen interfaces. None of them have just one, and none of them have a thousand.

Those interfaces are essentially just groups of commands that fit together. Maybe up by the OSS/BSS, there is the group of commands that onboard things. Maybe then there’s another group of commands that manages those onboarded things. Those would be two different interfaces. So these reference points host one or more interfaces with which we can play around with NFV things in the wavy NFV playground box in the middle of the picture.

We have things like PNFs or physical network functions. We will always need that for legacy reasons. PNFs are just the good old network functions, the ones that you unpack from a cardboard box and can then drop on your toe, but they won’t go away. So we still need to keep them in our infrastructure.

VNF is the new virtual version of a PNF, so that’s a virtualized network function. And then, we have network services which combine PNFs and VNFs. In order to have those connections, physical network functions have Connection Points (CP), VNFs have connection points and network services have connection points, although they’re not called connection points – they’re called Service Access Points (SAP). But SAPs are, for all intents and purposes, exactly the same as connection points. When it comes to their data models, they are pretty much identical.

And finally, we can connect these connection points with Virtual Links (VL) inside VNFs and virtual links inside network services.

This episode comes from the course Cloud, NFV and SDN in an Hour and gives you a quick, logical and functional introduction to OpenStack. 

Do you want to know more about OpenStack and other cloud connected environments? Explore Apis Training’s full course Cloud, NFV and SDN in an Hour.  

The course gives you a deeper understanding of: 

• OpenStack 
• Network Functions Virtualization (NFV)  
• Software-Defined Networking (SDN) 
• Cloud Introduction  
• Virtualization  
• Containers  

Are you curious? Read more about the course now: https://apistraining.com/portfolio/cloud-nfv-and-sdn-in-an-hour/ 

This TechTip is also part of a whole eBook of tips, all focusing on Cloud technology. We call it an eBook+ since all chapters are both text and video. If you want to read the text, you can do that, and if you want to watch a teacher tell the story, you can choose that.

All the video chapters are excerpts taken directly from our recorded lessons, so if one of them piques your interest, you can easily go to the course and dive deeper into that particular subject.

This particular eBook+ is called “Cloud Chronicles: A Journey into a Virtualized and Software-Defined World“, and you only need to CLICK HERE to request it for immediate download.

Below you can find the transcribed text for this particular TechTip.

What Does OpenStack Do?

Let’s take a look at OpenStack. In the lower part of the first image, we have two data centers or at least server groups, server groups one and two. They’re connected by some physical network. We have cables, switches, and routers in the IP transport layer, and we have connected storage, hard drives, and storage clusters.

Our aim here is to start virtual machines on the servers and connect them, but we need to control that from somewhere, maybe from the laptop at the top of the picture. That is us sitting connected to the Internet at the top, and we want something to happen down there at the bottom. We need some kind of intermediary here. Something in between.

We need something that allows us to start and stop virtual machines in the data centers, connect those virtual machines using networks, and mount storage, meaning make the virtual machines believe they have hard drives. While there are other solutions, OpenStack is a popular choice to play this role of intermediary. OpenStack is arguably the biggest open-source option, but private vendors like VMware are also big players.

In the second image, we can see what OpenStack consists of, a number of modules. Firstly, it has a Horizon module, which is the one that gives me the graphical user interface. This is essentially just a web service that I log into that allows me to see what’s going on. It allows me to click to start and stop virtual machines.
Each one of these modules, the rectangles in this picture, is just a piece of code. It’s written in Python if you’re interested, but it’s just computer code. Computer programs.

There’s the computing, or NOVA, module. It’s the one that sends the commands to start or stop virtual machines. Then we have three that have to do with storage. One of these is the one that fakes hard drives toward virtual machines (Cinder). It allows you to write blocks of data, e.g. “write these ones and zeros on this location on the hard drive”; that’s how hard drives work. We have one module (Glance) that keeps track of image files, the blueprints that are used to start virtual machines, and a third one (Swift) that actually stores those image files.

Swift is object storage, as opposed to block storage (Cinder) which writes blocks of ones and zeros. Swift handles whole files the way you’re used to in a normal file explorer in Windows or in Dropbox. You’ll notice if you try that it’s very difficult in File Explorer to move half a file, but you can do that in Cinder while Swift handles whole files. Swift is essentially OpenStack’s own little internal Dropbox.

We have a module for networking, which is called Neutron, that can behave as a router or as a switch, as a load balancer, as a firewall, and all kinds of things. It can be a NAT for virtual machines to reach the outside world.

And then there’s a module that handles security, Keystone. It handles security when you log in, but more importantly, it handles security between all these modules because everything these days is moving towards restful APIs with HTTP/TCP-based communication between functions. 5G is all about that, so is NFV, and OpenStack as well. So all the coloured lines are the modules talking HTTP to each other.

They are essentially acting as web services to each other, and those APIs are, by default, open. You can reach them from everywhere. And that’s what the arrows directly between Access and Function denote. There is no OpenStack police that tells you you have to go through Horizon to reach e.g. Cinder. If you are able to reach Cinder on a network level and you can speak the language that it speaks, then that’s perfectly fine, and you can communicate directly with Cinder from the outside.

If you don’t want to use OpenStack, and you just want to use Swift as your own little local Dropbox at home, you can do that as well.

This episode gives a basic understanding of what software-defined networking can look like, and comes from the course Cloud, NFV and SDN in an Hour.

We hope you enjoyed this TechTip! Do you want more insights about SDN? Discover Apis Training’s full course Cloud, NFV and SDN in an Hour.  

The course takes a deep dive into the following topics: 

• An introduction to the Cloud 
• The importance of virtualization  
• Network Functions Virtualization (NFV)  
• Software-Defined Networking (SDN) 
• What OpenStack does and why you need it 

Learn more about Cloud, NFV and SDN here: https://apistraining.com/portfolio/cloud-nfv-and-sdn-in-an-hour/   

This TechTip is also part of a whole eBook of tips, all focusing on Cloud technology. We call it an eBook+ since all chapters are both text and video. If you want to read the text, you can do that, and if you want to watch a teacher tell the story, you can choose that.

All the video chapters are excerpts taken directly from our recorded lessons, so if one of them piques your interest, you can easily go to the course and dive deeper into that particular subject.

This particular eBook+ is called “Cloud Chronicles: A Journey into a Virtualized and Software-Defined World“, and you only need to CLICK HERE to request it for immediate download.

Below you can find the transcribed text for this particular TechTip.

What Is SDN?

What if we have a network that looks like the left side of the first image? It seems very weird. There’s a router, a switch, a diode of some kind, and other very strange-looking hardware-specific network pieces of equipment.

Couldn’t we do it like the right side instead? We buy these generic, white boxes, and we manage them centrally from the little brain in the middle. And it controls the generic boxes to behave in such a way that, from the outside, they look like the thought balloon. Which happens to be the exact same picture as the network on the left!

So from the outside, we can’t tell whether we’re connected to the left or right picture. But of course, there’s so much more flexibility on the right side because there, at the flip of a switch or the drop of a hat, I can just change how the network devices behave. On the left side, in order to change the functionality, I’d need to disconnect them and go away and buy another thing and connect it.
Sometimes the interface between the controller and the SDN devices (the red lines) uses a protocol called OpenFlow. I mention it because it’s a popular SDN protocol. It’s not at all the only way to do it, but it’s a popular protocol for controlling SDN devices.

One possibility with this is what’s called network slicing. Let’s say we have the little network seen in the second image, and maybe I’m sitting somewhere up there with the control computer, talking to the SDN controller, asking it to do something. Then customer A, compared to customer B may perceive the network completely differently.

Customer A sees a square of routers, while customer B sees a matrix of switches. Even though it’s the same physical network! This is sometimes called network slicing, but network slicing has a bigger meaning as well. This is network slicing specifically for transport networks, packet-forwarding networks. If you include network functions like higher-layer applications but still apply the same logic, then it’s all hardware infrastructure that is perceived differently depending on who is using it

Network slicing on both lower and higher layers is very popular in NFV and 3GPP, and 5G papers talk a lot about network slicing, for instance.

This episode of Apis TechTips introduces the concept of the Telco Cloud, and comes from the course Cloud, NFV and SDN in an Hour.   

Did you enjoy this Apis TechTip? Check out the entire course Cloud, NFV and SDN in an Hour and gain valuable insights about topics such as: 

• Virtualization and Cloud Introduction  
• OpenStack and Containers  
• NFV – Network Functions Virtualization 
• SDN – Software-Defined Networking  

Read more about this course here: https://apistraining.com/portfolio/cloud-nfv-and-sdn-in-an-hour/   

This TechTip is also part of a whole eBook of tips, all focusing on Cloud technology. We call it an eBook+ since all chapters are both text and video. If you want to read the text, you can do that, and if you want to watch a teacher tell the story, you can choose that.

All the video chapters are excerpts taken directly from our recorded lessons, so if one of them piques your interest, you can easily go to the course and dive deeper into that particular subject.

This particular eBook+ is called “Cloud Chronicles: A Journey into a Virtualized and Software-Defined World“, and you only need to CLICK HERE to request it for immediate download.

Below you can find the transcribed text for this particular TechTip.

The Telco Cloud

Let me give you an introduction to Telco Cloud. In the image, we have data centers in different places, or geolocations. We have places X, Y, and Z, and HV stands for hypervisor. So we have data centers with compute nodes where we can run virtual machines.

Typically, these would be large data centers, but we can also have smaller data centers, maybe in base station sites or perhaps even at your home. Your home router could be a micro or femto data center where we can run everything that’s going on in your home router: switching, routing, NAT-ing, DHCP-ing, and firewalling.

All of that could be run as virtual machines in your little micro data center in your home router. The point is that it’s the same kind of hardware. It’s COTS (commercial off-the-shelf) hardware everywhere in this execution environment, which is managed by some kind of cloud management (could be OpenStack, for instance) so that we can run different functions in this network.

And it’s COTS, so applications can move. We can move functions where they’re needed either because we have resources to spare in another location or maybe the users are moving and they need low latency. And since there’s just a sea of generic hardware resources that are generally the same, we can move our functions pretty much where they’re needed.

It’s real-time server and payload applications, which is maybe one of the biggest differences between telco cloud and datacom cloud. Datacom Cloud was built for email and web services, and if you get your email 3 seconds late, it doesn’t matter. However, if you get your IP packet containing voice in a phone call 3 seconds late, it really does matter.

So that’s one of the challenges, and it is difficult. It’s one of the important differences that you need to handle, and that’s why there is quite a bit of talk about acceleration technologies and things like that in order to make this actually fly.

And this could also work as a service-agnostic platform, on top of which we can develop innovative applications. So the cloud management could be like an abstraction layer if you will. You don’t need to understand all the underlying technology in order to add new functions. In fact, very much like the Internet. You can start new web services without understanding how TCP/IP works, and that is arguably one of the success factors for the Internet.

This episode is about virtualization from a birds-eye perspective and comes from the course Network Slicing in an Hour. 

If you liked this Apis TechTip, check out the complete course Network Slicing in an Hour. The course provides you with a condensed view of the 5G Network slicing feature as defined by the 3GPP. It presents operational benefits and explains the technology needed to actualize network slicing in 5G.  

Network Slicing in an Hour covers topics such as:  

• Network Slicing: Overall Perspective  
• Technological Aspects of Network Slicing  
• Business Aspects of Network Slicing  

Learn more about the full course here: https://apistraining.com/portfolio/network-slicing-in-an-hour/ 

This TechTip is also part of a whole eBook of tips, all focusing on Cloud technology. We call it an eBook+ since all chapters are both text and video. If you want to read the text, you can do that, and if you want to watch a teacher tell the story, you can choose that.

All the video chapters are excerpts taken directly from our recorded lessons, so if one of them piques your interest, you can easily go to the course and dive deeper into that particular subject.

This particular eBook+ is called “Cloud Chronicles: A Journey into a Virtualized and Software-Defined World“, and you only need to CLICK HERE to request it for immediate download.

Below you can find the transcribed text for this particular TechTip.

Intro to Virtualization

In this chapter, I just want to contain the things that I find most relevant. Virtualization is a topic in its own right, of course. This picture, on the left, presents what is called the traditional approach. This is one machine that does one thing.

So within the red area, I have dedicated hardware with specialized software that runs on it, and it has certain functionalities and capabilities. And you can see three of these machines over here. This is the way things were for a very, very long time. It’s a good solution. It does have a lot of good things about it. What’s bad about the traditional approach? Because this is an explanation of why we move away from that. And the answer is: The traditional approach is expensive.
It’s expensive because buying dedicated hardware and software is expensive. But also because it’s a very long time to market and long deployment times. Establishing a new MME (4G signalling node) within the evolved packet (4G) core is a project for one and a half months if we do it in this traditional approach. We have a lack of scalability and lack of flexibility. So basically, the traditional approach is fantastic if we can afford it. It’s the best possible solution because you have dedicated resources and everything is beautiful, but it is expensive.

So in order to save, and economizing is what the operators really need to do nowadays, we started with the idea of sharing the hardware resources. And the first really big method was using virtual machines, which can be seen in the middle part of the picture.

So this application in the middle runs on a virtual machine and has a certain functionality. The red shape is one virtual machine that has its own operating system. And there are a number of them, running on the same hardware with a hypervisor between. The hypervisor ensures that we have some kind of multiplexing and resource allocation that fits all of these three virtual machines, which are, by the way, unaware of the fact that anybody else exists on that hardware. That’s what the hypervisor does. It hides the fact that there are other users.

And over time, looking at the rightmost part of the image, you can see that what is the actual functionality gets smaller and smaller. Smaller building blocks are easier to design, and they can be put out onto the market much quicker. These are containers that share an operating system, so they are smaller than the virtual machine solution. There is a container management tool (e.g. a Docker engine) to basically dock them into the operating system. And then the hardware below is going to be used by all of them.

There are also microservices which are even smaller building blocks, but without going any deeper into details, I simply wanted to say that the virtualization as such gives us huge benefits. It’s a much more cost-efficient way of designing the network. It has its drawbacks, of course, stemming from the fact that we are sharing physical resources, but it’s often worth it.

With virtualization, we get scalability, automated management, and orchestration. Lower power consumption is one of the main arguments for virtualization. We get isolation. One thing that also comes with virtualization is the fact that a process that is running on a particular piece of hardware can be moved to another piece of hardware without interrupting the process. This is called live migration and is probably going to be quite useful for us in the mobile networks to follow the mobility of the customers across the virtualized networks. These are also the underlying benefits of virtualization, which we use for network-slicing solutions.