Thu, 01 Aug 2024 16:35:33 -0000
|Read Time: 0 minutes
Increasing revenue and decreasing costs are at the top of every CSP’s priorities, and the 5G Core plays an important role in achieving these outcomes. Its service-based architecture activates new revenue streams for CSPs by enabling mobile edge computing, network slicing, slicing orchestration, and service assurance. Its future-proof design also allows for improved efficiencies such as fixed mobile convergence, collapsing all 3GPP and non-3GPP wireless and fixed accesses into a single core network.
However, embracing a 5G Core network means also embracing a cloud transformation strategy to achieve these outcomes. Cloud-native network functions with microservices architecture require a container-based cloud native architecture built around a common automation and operational framework to achieve the desired service agility that would allow CSPs to introduce new features and service improvements faster. Moreover, this should be a multi-tenant cloud platform to maximize infrastructure utilization and reuse.
Cloud transformation is also vital in ensuring that the SLAs are met by CSPs transitioning from legacy purpose-built physical appliances to modernized network infrastructure with open disaggregated cloud-native architecture to run their 5G Core. Moreover, cloud transformation allows CSPs to support multiple customized SLAs for different services and customer segments, and offer the following benefits:
Building a container-based, cloud platform for network workloads is certainly doable. Several CSPs have successfully done this while leveraging Dell PowerEdge servers. For example, Dell Technologies offers telecom optimized PowerEdge XR Edge servers to ensure that CSPs have the right form factor for every location from core sites to the network edge.
Nevertheless, many CSPs do not want to build this telecom cloud infrastructure themselves for a variety of reasons such as time constraints, integration complexity, lack of cloud competencies and experience, and limited budgets. Building and maintaining cloud platforms is not a CSP’s core competence after all.
This is where the Dell Technologies’ engineered systems for 5G telecom cloud networks come in. The Dell Telecom Infrastructure Blocks for Red Hat were developed in close partnership with Red Hat, a leader for container management with Red Hat® OpenShift®, according the 2023 Gartner® Magic Quadrant™ for Container Management1. The Infrastructure Blocks are built around automation for these reasons and are in line with Dell’s philosophy of making cloud transformation not only open, but also consumable.
These engineered systems introduce a horizontal cloud architecture that effectively dismantles technology silos, offering CSPs a streamlined approach to deployment while substantially lowering their Total Cost of Ownership (TCO)2.
Some of the key advantages of Dell's pre-validated, factory integrated, solution is that it comes with automated workflows and single call support model for the entire cloud platform. They can help accelerate the time-to-market for new services, enabling CSPs to maintain a competitive edge in the fast-paced 5G landscape.
The robust Dell and Red Hat cloud foundation stack, that utilizes performant, telecom optimized servers and Red Hat OpenShift software, means CSPs can confidently make the leap from legacy systems to a modern, cloud-native telecom cloud for their 5G Core workloads. The platform ensures strict adherence to Service Level Agreements (SLAs) and delivers superior performance, giving CSPs peace of mind as they navigate this transition.
Dell Technologies also works closely with a wide range of Network Equipment Providers (NEPs) and Independent Software Vendors (ISVs) to certify their workloads on Dell Telecom Infrastructure Blocks. This is made possible by the Open Telecom Ecosystem Labs where CSPs, hardware, CaaS, and application vendors come together to accelerate cloud transformation.
Dell Telecom Infrastructure Blocks for Red Hat stand out as a unique solution for CSPs. By leveraging this jointly engineered telecom cloud solution, providers can swiftly respond to market demands and stay ahead of their competition in the 5G race.
Below are links to the first four blogs in our five-part blog series on moving to a cloud-native architecture for deploying 5G Core with Red Hat OpenShift.
Learn more about Dell Telecom Infrastructure Blocks for Red Hat here.
Footnotes
1. Source: Red Hat Blog, “Red Hat Named a Leader in 2023 Gartner Magic Quadrant for Container Management”, September 2023
2. Source: ACG Research Report, “Examining the Impact on Total Cost of Ownership when deploying Telecom Infrastructure Blocks for Red Hat from Core to RAN”, February 2024
Fri, 08 Dec 2023 19:40:56 -0000
|Read Time: 0 minutes
5G, especially 5G standalone, has not yet developed to fulfill expectations. End users are not yet seeing significant differences in comparison to 4G, and CSPs are not yet seeing new revenue streams. To address these challenges, we have previously presented two blogs (Network Slicing and Network Edge). In this third blog, we continue to describe a realistic view of how CSPs could maximize the 5G standalone experience and go beyond being merely connectivity providers. This blog focuses on exposing the network capabilities (services and user/network information) that service providers and enterprises can use to enable innovative and monetizable services.
The success of numerous innovative mobile applications can be traced to the availability of mobile Software Development Kits (SDKs). SDKs are available for both iOS and Android mobile platforms. These SDKs provide open tools, libraries, and documentation that allow application developers to easily create mobile applications that rely upon the capabilities of existing mobile platforms (such as notifications and analytics) and device hardware (like GPS and camera.). Most importantly, these two mobile platforms alone currently support over four billion users. The next step is to use the same principles on the network side by using Open APIs that allow unified access to network capabilities for increased network exposure.
The concept of network exposure is not new. There have been a few less-than-successful attempts in the past, such as Service Capabilities Exposure Function (SCEF) and APIs for the IMS/Voice. These solutions were not able to scale sufficiently to attract a significant number of application developers. The specifications have been too complicated for anybody outside of the telecom world to understand or implement. The integration of network exposure into the 5G design is groundbreaking. API exposure is now fundamental to 5G and is natively built into the architecture, enabling applications to seamlessly interact with the network.
Monetizing mobile networks using Open APIs relies on the implementation of communication APIs for voice, video, and messaging, as well as network APIs for location, authentication, and quality of service. By exposing these capabilities through Open APIs, CSPs can establish partnerships by facilitating the creation of tailored, high-value services for businesses, thereby enabling them to monetize 5G beyond traditional connectivity and bundled offerings. These new revenue streams are paramount as the traditional revenue streams from mobile broadband services are flat while costs continue to rise. Moreover, the deployment of a cloud-native 5G standalone network requires substantial investments, making it crucial to identify new revenue streams that can justify the business case.
5G standalone was specified in 3GPP release 15 and its architecture standardized the Network Exposure Function (NEF). One of the 5G core network functions, NEF allows applications to subscribe to network changes, or instruct them to extract network information and capabilities. NEF enables an extensive set of network exposure capabilities, but it lacks the scale, agility, and simplicity that application developers require. GSMA’s Open Gateway Initiative, the CAMARA project, and TM Forum’s Open APIs all aim to address this gap.
The use case is well described in the GSMA’s Open Gateway white paper.
Open APIs and network capabilities in this new concept have much to offer. The CAMARA project has already defined 18 Service APIs such as Quality on Demand, Device Location, Device Status, Number Verification, Simple Edge Discovery, One Time Password SMS, Carrier Billing, and SIM swap. Three of the most popular elements are described in more detail below:
Quality on Demand: It is easy to imagine that multiple applications can benefit from better quality (bandwidth and latency). The challenge is to address how the network can fulfill this request instantaneously and cost-effectively. Some Proof of Concepts (PoCs) demonstrate that implementing Quality on Demand improvements can trigger either a new Network Slice or a different Quality of Service Class Identifier (QCI). For more information, see our Network Slicing blog.
Device Location: This API verifies that the device is in a specific geographical area. The main benefits of the network-based request are that it can be used when a GPS signal is not available, and it is considered more trustworthy (location info cannot be spoofed).
Device Status: This API provides a very simple and straightforward request to determine whether the subscriber is roaming.
None of these Service APIs offer anything unique that the market has not seen before. Their intrinsic value comes from being part of a unified platform that enables a consistent way of accessing network capabilities and information, similar to how mobile SDKs became a catalyst to the thriving mobile device ecosystem we know today. Only time will tell how much value-add application developers will see from these Open APIs.
The value of new features and applications is considered whenever 5G monetization is discussed. We are still in the early phase of Open APIs, but the TM Forum’s Catalyst Program and CAMARA Open API showcases can give good insights into what the coming commercial deployments could look like. These programs have triggered several PoCs where the related use cases have required optimized performance (Quality of Demand), user location/roaming information, and feedback on consumer experience. In these PoCs, the service providers have been able to consume the Open APIs directly or through a Hyperscale marketplace. As an example, in one PoC, guaranteed Quality of Delivery was needed for a 360-degree 8K live streaming service with content monetization through APIs (with CSPs curating markets at the edge). Another PoC included an end-to-end implementation of a marketplace from which one could consume network services from multiple CSP networks (Simple hyperscaler integrated network experience).
We can expect several commercial models for these Open APIs, because these APIs can be utilized in various ways such as providing network/subscriber information, optimizing functionalities/features, and allocating network capacity/resources. it is yet to be determined how these Open APIs can be consumed easily. Service providers are unlikely to integrate and set up individual contracts with every other service provider in the world. Therefore, there must be a place for aggregation in order to hide the complexity behind a portal. This role can be assumed by a group of service providers or hyperscalers who can onboard these services onto their marketplaces.
One of the main Key Performance Indicators (KPI’s that define success for service providers is the ability to scale and have a global reach. It is critical that there be no fragmentation and that the community work towards a unified approach. Jointly agreed upon solutions and specifications require more time to develop; therefore, another year may pass before we start to see commercial use case launches (as forecast by Borje Ekholm, Ericsson CEO during the Q3-2023 earnings call).
The journey to unified 5G is not easy, and it presents various challenges:
Some service providers have already launched platforms with a few Service APIs. Early deployments can introduce a risk of fragmentation. However, the risk is outweighed by the positive impact testing the concept in the real world and constructing more concrete requirements from actual user experiences with these services.
Regardless of how much commercial success these new Network and Service APIs realize in the coming years, they will have made an important step towards more Open, Agile, and Programmable networks. Similarly, Dell has been embracing this vision in our Telecom strategy as reflected on our Multi-Cloud Foundation Concept, Bare Metal Orchestration, and Open RAN development projects. In our vision, Open APIs are needed in all layers (Infrastructure, Network, Operations, and Services). Stay tuned for more to come from Dell about the open infrastructure ecosystem and automation (#MWC24).
Mon, 26 Jun 2023 10:59:44 -0000
|Read Time: 0 minutes
Where is the Network Edge in Mobile Networks
The notion of ‘Edge’ can take on different meanings depending on the context, so it’s important to first define what we mean by Network Edge. This term can be broadly classified into two categories: Enterprise Edge and Network Edge. The former refers to when the infrastructure is hosted by the company using the service, while the latter refers to when the infrastructure is hosted by the Mobile Network Operator (MNO) providing the service.
This article focuses on the Network Edge, which can be located anywhere from the Radio Access Network (RAN) to next to the Core Network (CN). Network Edge sites collocated with the RAN are often referred to as Far Edge.
What is in the Network Edge
In a 5G Standalone (5G SA) Network, a Network Edge site typically contains a cloud platform that hosts a User Plane Function (UPF) to enable local breakout (LBO). It may include a suite of consumer and enterprise applications, for example, those that require lower latency or more privacy. It can also benefit the transport network when large content such as Video-on-Demand is brought closer to the end users.
Modern cloud platforms are envisioned to be open and disaggregated to enable MNOs to rapidly onboard new applications from different Independent Software Vendors (ISV) thus accelerating technology adoption. These modern cloud platforms are typically composed of Commercial-of-the-Shelf (COTS) hardware, multi-tenant Container-as-a-Service (CaaS) platforms, and multi-cloud Management and Orchestration solutions.
Similarly, modern applications are designed to be cloud-native to maximize service agility. By having microservices architectures and supporting containerized deployments, MNOs can rapidly adapt their services to meet changing market demands.
What contributes to Network Latency
The appeal of Network Edge or Multi-access Edge Computing (MEC) is commonly associated with lower latency or more privacy. While moving applications from beyond the CN to near the RAN does eliminate up to tens of milliseconds of delay, it is also important to understand that there are many other contributors to network latency which can be optimized. In fact, latency is added at every stage from the User Equipment (UE) to the application and back.
RAN is typically the biggest contributor to network latency and jitter, the latter being a measure of fluctuations in delay. Accordingly, 3GPP has introduced a lot of enhancements in 5G New Radio (5G NR) to reduce latency and jitter in the air interface. We can actively reduce latency through the following categories: There are three primary categories where latency can be reduced:
Transport latency is relatively simple to understand as it is mainly due to light propagation in optical fiber. The industry rule of thumb is 1 millisecond round trip latency for every 100 kilometers. The number of hops along the path also impacts latency as every transport equipment adds a bit of delay.
Typically, CN adds less than 1 millisecond to the latency. The challenge for the CN is more about keeping the latency low for mobile UEs, by seamlessly changing anchors to the nearest Edge UPF through a new procedure called ‘make before break’. Also, the UPF architecture and Gi/SGi services (e.g., Deep Packet Inspection, Network Address Translation, and Content Optimization) may add a few additional milliseconds to the overall latency, depending on whether these functions are integrated or independent.
Architectural and Business approaches for the Network Edge
The physical locations that host RAN and Network Edge functionalities are widely recognized to be some of the MNOs’ most valuable assets. Few other entities today have the real estate and associated infrastructure (e.g., power, fiber) to bring cloud capabilities this close to the end clients. Consequently, monetization of the Network Edge is an important component of most MNOs’ strategy for maximizing their investment in the mobile network and, specifically, in 5G. In almost all cases, the Network Edge monetization strategy includes making Network Edge available for Enterprise customers to use as an “Edge Cloud.” However, doing so involves making architectural and business model choices across several dimensions:
Certainly, the likely end state is a complex mixture of services and go-to-market models focused on the Enterprise (B2B) segment. The exposition of operational automation and the features of 5G designed to address this make it likely that this is a huge opportunity for MNOs. Navigating the complexities of this space requires a deep understanding of both what services the Enterprises are looking for and how they are looking to consume these. It also requires an architectural approach that can handle the variable mix of what is needed in a way that is highly scalable.
As the long-time leader in Enterprise IT services, Dell is uniquely positioned to address this space – stay tuned for more details in an upcoming blog!
Building the Network Edge
There are several factors to consider when moving workloads from central sites to edge locations. Limited space and power are at the top of the list. The distance of locations from the main cities and generally more exposed to the elements require a new class of denser, easier-to-service, and even ruggedized form factors. Thanks to the popularity of Open RAN and Enterprise Edge, there are already solutions in the market today that can also be used for Network Edge. Read more on Edge blog series Computing on the Edge | Dell Technologies Info Hub
Higher deployment and operating costs are another major factor. The sheer number of edge locations combined with their degraded accessibility make them more expensive to build and maintain. The economics of the Network Edge thus necessitates automation and pre-integration. Dell’s solution is the newly engineered cloud-native solution with automated deployment and life-cycle management at its core. More on this novel approach here Dell Telecom MultiCloud Foundation | Dell USA.
Last is the lower cost of running applications centrally. Central sites have the advantage of pooling computes and sharing facilities such as power, connectivity, and cooling. It is therefore important to reduce overhead wherever possible, such as opting for containerized over VM-based cloud platforms. Moreover, having an open and disaggregated horizontal cloud platform not only allows for multitenancy at edge locations, which significantly reduces overhead but also enables application portability across the network to maximize efficiency.
The ideal situation is where Open/Cloud RAN and Network Edge are sharing sites thus splitting several of the deployment and operations costs. Due to the latency requirements, Distributed Unit (DU) must be placed within 20 kilometers of the Radio Unit (RU). Latency requirements for the mid-haul interface between DU and Central Unit (CU) are less stringent, and CU could be placed roughly around 80-100 kilometers from the DU. In addition, the Near-Real Time Radio Intelligent Controller (Near-RT RIC) and the related xApps must be placed within 10ms RTT. This makes it possible to collocate Network Edge sites with the CU sites and Near-RT RIC.
Future
What has happened over the past few years is that several MNOs have already moved away from having 2-3 national DCs for their entire CN to deploying 5-10 regional DCs where some network functions such as the UPF were distributed. One example of this is AT&Ts dozen “5G Edge Zones” which were introduced in the major metropolitan areas: AT&T Launching a Dozen 5G “Edge Zones” Across the U.S. (att.com).
This approach already suffices for the majority of “low latency” use cases and for smaller countries even the traditional 2-3 national DCs can offer sufficiently low transport latency. However, when moving into critical use cases with more stringent latency requirements, which means consistently very low latency is a must, then moving the applications to the Far Edge sites becomes a necessity in tandem with 5G SA enhancements such as network slicing and an optimized air interface.
The challenge with consumer use cases such as cloud gaming is supporting the required Service Level (i.e., low latency) country wide. And since enabling the network to support this requires a substantial initial investment, we are seeing the classic chicken and egg problem where independent software vendors opt not to develop these more demanding applications while MNOs keep waiting for these “killer use cases” to justify the initial investment for the Network Edge. As a result, we expect geographically limited enterprise use cases to gain market traction first and serve as catalysts for initially limited Network Edge deployments.
For use cases where assured speeds and low latency are critical, end-to-end Network Slicing is essential. In order to adopt a new more service-oriented approach, MNOs will need Network Edge and low latency enhancements together with Network Slicing in their toolbox. For more on this approach and Network Slicing, please check out our previous blog To slice or not to slice | Dell Technologies Info Hub.
About the author: Tomi Varonen
Tomi Varonen is a Telecom Network Architect in Dell’s Telecom Systems Business Unit. He is based in Finland and working with the Cloud, Core Network, and OSS&BSS customer cases in the EMEA region. Tomi has over 23 years of experience in the Telecom sector in various technical and sales positions. Wide expertise in end-to-end mobile networks and enjoys creating solutions for new technology areas. Passion for various outdoor activities with family and friends including skiing, golf, and bicycling.
About the author: Arthur Gerona
Arthur is a Principal Global Enterprise Architect at Dell Technologies. He is working on the Telecom Cloud and Core area for the Asia Pacific and Japan region. He has 19 years of experience in Telecommunications, holding various roles in delivery, technical sales, product management, and field CTO. When not working, Arthur likes to keep active and travel with his family.
About the author: Alex Reznik
ALEX REZNIK is a Global Principal Architect in Dell Technologies Telco Solutions Business organization. In this role, he is focused on helping Dell’s Telco and Enterprise partners navigate the complexities of Edge Cloud strategy and turning the potential of 5G Edge transformation into the reality of business outcomes. Alex is a recognized industry expert in the area of edge computing and a frequent speaker on the subject. He is a co-author of the book "Multi-Access Edge Computing in Action." From March 2017 through February 2021, Alex served as Chair of ETSI’s Multi-Access Edge Computing (MEC) ISG – the leading international standards group focused on enabling edge computing in access networks.
Prior to joining Dell, Alex was a Distinguished Technologist in HPE’s North American Telco organization. In this role, he was involved in various aspects of helping Tier 1 CSPs deploy state-of-the-art flexible infrastructure capable of delivering on the full promises of 5G. Prior to HPE Alex was a Senior Principal Engineer/Senior Director at InterDigital, leading the company’s research and development activities in the area of wireless internet evolution. Since joining InterDigital in 1999, he has been involved in a wide range of projects, including leadership of 3G modem ASIC architecture, design of advanced wireless security systems, coordination of standards strategy in the cognitive networks space, development of advanced IP mobility and heterogeneous access technologies and development of new content management techniques for the mobile edge.
Alex earned his B.S.E.E. Summa Cum Laude from The Cooper Union, S.M. in Electrical Engineering and Computer Science from the Massachusetts Institute of Technology, and Ph.D. in Electrical Engineering from Princeton University. He held a visiting faculty appointment at WINLAB, Rutgers University, where he collaborated on research in cognitive radio, wireless security, and future mobile Internet. He served as the Vice-Chair of the Services Working Group at the Small Cells Forum. Alex is an inventor of over 160 granted U.S. patents and has been awarded numerous awards for Innovation at InterDigital.
Wed, 25 Jan 2023 21:53:29 -0000
|Read Time: 0 minutes
Network Slicing is possibly the most central feature of 5G – lots of game-changing potentials, but at the same time often overhyped and misunderstood. In this blog, we will give a fact-based assessment and guidance on the question of “To Slice Or Not To Slice.”
Guidance for the reader:
5G doesn’t only promise to enhance mobile broadband but also to support a wide range of enterprise use cases – from those requiring better reliability and lower latency to those requiring a long battery life and greater device density. From the long list of 3GPP Release 15 features, Network Slicing is the cornerstone feature for service creation. The basic idea behind this feature is the ability to subdivide a single physical network into many logical networks where each is optimized to support the requirements of the services intended to run on it.
We can think of Network Slicing as ordering pizza for friends. 4G gets you the classic Margherita, which is acceptable to most. Yet some would be willing to pay more for extra toppings. In this case, 5G allows you to customize the pizza where half can still be the classic Margherita, but the remaining slices can be split into four cheese, pepperoni, and Hawaiian.
It all sounds great, but why are we not seeing Network Slicing everywhere today? Let us explore some of the hurdles it has to clear before becoming more mainstream.
Slicing requires new features to work – Network equipment providers need to develop these new features, especially on the Radio Access Network (RAN), and communications service providers need to implement them. This will take time since much of the initial industry focus has been on enhanced mobile broadband and fixed wireless access, which is the initial monetizable 5G use cases.
Slicing needs automation to be practical – While it is possible to create network slices manually at the start, doing so at scale takes too long and costs too much. An entirely new 3GPP-defined management and orchestration layer is needed for slicing orchestration and service assurance. Business Support Systems (BSS) also need new integrations and feature enhancements to support capabilities like online service ordering and SLA-based charging.
Slicing has to make money – There will come a time when we cannot live without the metaverse and web 3.0, but that is not today. There will also come a time when factories will be run by collaborative robots and infrastructures are maintained by autonomous drones, but that is not today. The reality is that there is limited demand for custom slices since most consumer and enterprise use cases today work fine on 4G or 5G non-standalone networks. For example, YouTube and other over-the-top streaming apps implement algorithms to adapt to varying speeds and latency. Lastly, Network Slicing also comes with additional costs related to implementation, operations, and reduced overall capacity (due to resource reservation and prioritization) that must be factored into the business case.
Regulatory challenges – Net Neutrality is an essential topic in the United States and European Union. Misinterpreting differentiated services as something that violates Net Neutrality may put communications service providers under scrutiny by regulators.
5G standalone may have been slow out of the gate, but it is gaining momentum. In 2022, GSA counted 112 operators in 52 countries investing in public 5G standalone networks. Some communications service providers are even more advanced. For example, Singtel has already implemented Paragon, an orchestration platform that allows them to offer network slices and mobile edge computing for mission-critical applications on demand. Another example is Telia Finland which uses Network Slicing to guarantee the service level for its home broadband (fixed wireless access) subscribers.
There are also a lot of ongoing and planned projects that aim to accelerate the development of enterprise use cases. Collaborations such as ARENA2036, a research campus in Germany, allow communications service providers, network equipment manufacturers, independent software vendors, system integrators, and the academe to work together in developing and testing new technologies and services.
One of the key reasons behind this positive momentum shift in 2022 is the major network equipment providers like Nokia and Ericsson bringing to the market their Network Slicing features for the RAN. These features enable the reservation and prioritization of RAN resources to particular slices. According to these vendors, Network Slice capacity management is done dynamically, which means the scarce air interface resources are allocated as efficiently as possible. This has been the much-needed catalyst for the first commercial launches and pre-commercial trials across several industries: fixed wireless access (live), video streaming (live), smart city, public safety, remote TV broadcast, assisted driving, enterprise interconnectivity, and mining.
Another positive development is related to smartphones where the biggest mobile operating system (Android OS) started supporting multiple Network Slices simultaneously on the same device (from Android 12). This is beneficial to both consumer and enterprise use cases that have more demanding requirements for speed and latency.
These enhancements on the RAN and devices close several gaps. We can therefore expect Network Slicing to gain even more traction in 2023.
Several hundred successful 4G and 5G Mobile Private Networks (MPN) have been deployed globally. Many have specific indoor coverage, cybersecurity, or business-critical performance requirements that can be best accomplished with dedicated network resources. The common challenges for MPN are private spectrum availability, high cost of deployment and operations, and long lead times.
5G use cases can only be deployed through Network Slicing or MPN, but the majority can be deployed on either. In our view, the discussion should not focus too much on comparing Network Slicing to MPN but should rather be on the use case requirements such as coverage, where Network Slicing is a natural fit for wide areas and MPN is a natural fit for deep indoor. Communications service providers should have both solutions in their toolbox as individual enterprise customers may require both for their various use cases. Let the use case dictate the solution, similar to the approach of most network equipment providers for private wireless (4G/5G versus WiFi6/6E).
In our view, the evidence is clear from the recently available slicing features and commercial/pre-commercial market deployments to conclude that Network Slicing is here to stay, enabling new service creation and fostering competitive differentiation. Only time will tell how successful it will be with consumer and enterprise market segments. The level of investments by governments, industry groups, communications service providers, and network equipment providers will play a major role in the success or failure of Network Slicing. At the same time, communications service providers should keep in mind other industry players like AWS and other webscale companies who are betting big on 5G with MPN-based solutions (as Network Slicing is not an option for them).
Communications service providers must understand that Network Slicing, in most situations, is not a sellable service, but rather an enabler to support services with performance or security requirements that are significantly different from mobile broadband. Differentiation for most of the use cases will be in the RAN domain since the air interface is a constrained resource and the RAN equipment is too costly to dedicate.
While there is no harm to having the management and orchestration layer from the start especially if CAPEX is not an issue, it is still recommended to first focus on deploying the end-to-end network features Network Slicing requires and on identifying monetizable use cases that will benefit from it. Note that some use cases require additional features such as those that lower latency and improve reliability.
The vast majority of consumer and enterprise end users are not interested in the underlying technologies, but rather just want to achieve the speed, latency, and reliability they need for the services they enjoy or need. And in many cases even discussions on speed, latency and reliability do not interest them as long as the services are performing as expected. Communications service providers should have the capability to create and market the services by themselves or, in most instances, with the right partners. Unlike 4G, the potential of 5G can no longer be realized just by the communications service providers and network equipment vendors.
Communications service providers should have a complete toolbox – different tools for different requirements. And the guidance is not to stand idly, but to gain experience and form partnerships for both Network Slicing and MPN.
Deploying Network Slicing or MPN and moving into new business models where offering multiple tailored and assured connectivity services are not trivial tasks. How Dell can help CSPs in this transformation journey:
About the author: Tomi Varonen
Principal Global Enterprise Architect
Tomi Varonen is a Telecom Network Architect in Dell’s Telecom Systems Business Unit. He is based in Finland and working with the Cloud and Core Network customer cases in the EMEA region. Tomi has over 23 years of experience in the Telecom sector in various technical and sales positions. He has wide expertise in end-to-end mobile networks and enjoys creating solutions for new technology areas. Tomi has a passion for various outdoor activities with family and friends including skiing, golf, and bicycling.
About the author: Arthur Gerona
Principal Global Enterprise Architect
Arthur is a Principal Global Enterprise Architect at Dell Technologies. He is working on the Telecom Cloud and Core area for the Asia Pacific and Japan region. He has 19 years of experience in Telecommunications, holding various roles in delivery, technical sales, product management, and field CTO. During his free time, Arthur likes to travel with his family.
Fri, 06 Jan 2023 14:29:40 -0000
|Read Time: 0 minutes
Communications service providers (CSPs) are on a journey of digital transformation that gives them the ability to offer new innovative services and a better customer experience in an open, agile, and cost-effective manner. Recent developments in 5G, Edge, Radio Access Network disaggregation, and, most importantly the pandemic have all proven to be catalysts that accelerated this digital transformation. However, all these advancements in telecom come with their own set of challenges. New architectures and solutions have made the modern network considerably more complex and difficult to manage.
In response, CSPs are evaluating new ways of managing their complex networks using automation and artificial intelligence. The ability to fully orchestrate the operation of digital platforms is vital for touchless operations and consistent delivery of services. Almost every CSP is working on this today. However, the standard automation architecture and tools can't be directly applied by CSPs as all these solutions need to adhere to strict telecom requirements and specifications such as those defined by enhanced Telecom Operations Map (eTOM), Telecom Management Forum (TM Forum), European Telecommunications Standards Institute (ETSI), 3rd Generation Partnership Project (3GPP), etc. CSPs also need to operate many telecom solutions including legacy physical network functions (PNF), virtual network functions (VNF), and the latest 5G era containerized network functions (CNF).
Removing barriers with telecom automation
Although many CSPs have built cloud platforms, only a handful have achieved their automation targets. So, what do you do when there is no ready-made industry-standard automation solution? You build one. And that’s exactly what Dell Technologies did with the recent launch of its Dell Telecom Multi-Cloud Foundation. Dell Telecom Multi-Cloud Foundation automates the deployment and life-cycle management of the cloud platforms used in a telecom network to reduce operational costs while consistently meeting telco-grade SLAs. It also supports the leading cloud platforms offering operators the flexibility of choosing the platform that best meets their needs based on workload requirements and cost-to-serve. It streamlines telecom cloud design, deployment, and management with integrated hardware, software, and support.
The solution includes Dell Telecom Infrastructure Blocks. Telecom Infrastructure Blocks are engineered systems that provide foundational building blocks that include all the hardware, software and licenses to build and scale out cloud infrastructure for a defined telecom use case.
Telecom Infrastructure Block releases will be delivered in an agile manner with multiple releases per year to simplify lifecycle management. In 2023, Dell Telecom Infrastructure Blocks will support workloads for Radio Access Network and Core network functions with:
Dell Telecom Infrastructure Blocks for RedHat will target core network workloads (planned). The primary goal of Telecom Multi-Cloud Foundation with Telecom Infrastructure Blocks is to deliver telco cloud platforms that are engineered for scaled deployments, providing three core capabilities:
Dell Technologies Telecom Multi-Cloud Foundation meets Telco automation requirements
Dell Technologies Multi-Cloud Foundation provides communications service providers with a platform-centric solution based on open Application Programming interfaces (APIs) and consistent tools. This means the platform can deliver outcomes based on a unique use case and workload and then scale out deployments using an API-based approach.
Dell Telcom Multi-Cloud Foundation enables telco-grade automation through the following key capabilities:
Automation use cases with Dell Technologies Telecom Multi-Cloud Foundation
Telecom Automation is not just about Day 0 (design) and Day 1 (deployment) but should also cover Day 2 (operations and lifecycle management). Dell Telecom Multi-Cloud Foundation supports the following use cases:
Dell Technologies developed Dell Telecom Multi-Cloud Foundation and Dell Telecom Infrastructure Blocks to accelerate 5G cloud infrastructure transformation. Our current release of Telecom Infrastructure Blocks for Wind River delivers an engineered and factory-integrated system that comes with a fully automated deployment model for CSPs looking to build resilient and high-performance RAN.
To learn more about our solution, please visit the Dell Telecom Multi-Cloud Foundation solutions site.
About the Author: Saad Sheikh
Saad Sheikh is APJ's Lead Systems Architect in Telecom Systems Business at Dell Technologies. In his current role, he is responsible for driving Telecom Cloud, Automation, and NGOPS transformations in APJ supporting partners, NEPs, and customers to accelerate Network Transformation for 5G, Open RAN, Core, and Edge using Dell’s products and capabilities. He is an industry leader with over 20 years of experience in Telco industry holding roles in Telco, System Integrators, Consulting businesses, and with Telecom vendors where he has worked on E2E Telecoms systems (RAN, Transport, Core, Networks), Cloud platforms, Automation, Orchestration, and Intelligent Networking. As part of Dell CTO team, he represents Dell in Linux Foundation, TMforum, GSMA, and TIP.