Network Slicing

We’re only halfway through 2019, and it’s already shaping up to be a promising year for 5G. Verizon, AT&T and Sprint have launched 5G networks in select areas in the US; Swisscom is offering commercial 5G services in major towns and cities in Switzerland; EE switched on 5G in a number of city districts last month; and South Korea’s SK Telecom, KT, and LG Uplus all announced their first 5G subscribers in April.

However, getting subscribers’ buy-in for 5G is just one part of the puzzle. While live-streaming and AR gaming via your smartphone are impressive, it’ll be the huge range of IoT and IoT use cases which will really drive the commercial development of 5G. Different vertical sectors and different use cases will require different types of connectivity, and operators will be contractually obliged to ensure that they deliver on these demands. Customers (and their end-users) will expect operators to effectively support massive machine type communications (mMTC), enhanced mobile broadband (eMBB), and ultra-reliable low latency communications (URLLC).

The only way that operators will be able to deliver on service-level agreements, ensure that networks will be optimized for 5G, and guarantee the massively diverse IoT ecosystem runs effectively, is via network slicing.

What is network slicing?

Network slicing is an independent end-to-end network that runs on a shared, virtual infrastructure, and can serve the demands and functions of multiple (specific) 5G use cases or communication types. Think of it like a police escort creating a clear path through congested traffic.  The path is clear and tailored to the specific need of the police escort – i.e. to traverse a busy junction rapidly, reliably and seamlessly, with other vehicles prioritising the escort over their own movements.

Why test network slicing now?

5G deployments are still few and far between, so operators should use this current period to test and assure the architectures and approaches which will be so vital to its success across different vertical markets and customer segments. When testing network slicing, operators must consider:

  • Does each network slice select the correct network nodes (AMF, access and mobility management function; SMF, session management function; and UPF, user plane function, are all new with 5G networks)?
  • Does the function of the network slice work correctly?
  • Can the network support the volume and variety of systems and devices which characterise 5G networks?

Testing a 5G network loaded with multiple types of data traffic in a real-world scenario is near impossible. Imagine trying to test a URLLC use case like connected cars, for instance, which will involve a network slice supporting thousands of vehicles and ensuring their safe, regulation-complying movement within smart city environments.

How can operators test network slicing effectively?

For operators to prepare themselves for the 5G use cases of the future they must test network slicing in a virtual, lab environment. VIAVI Solutions has developed end-to-end, RANtoCore test and validation solutions capable of emulating the 5G core network as a whole, individual nodes such as the UPF, SMF, AMF as well as multiple other functions.

Combining TeraVM and TM500 provides operators with a solution to the network slicing challenge, which is unique in the T&M industry, enabling service providers to ready their networks for 5G, get ahead of the competition, and future-proof their business.

To find out more about the importance of testing network slicing, learn how VIAVI is supporting major operators globally, and discover the benefits of partnering with us, head to our dedicated whitepaper.  Download the Whitepaper

Additional resources: 5G Testing and 5G Deployment.

About The Author

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

VIAVI Perspectives