Private 5G: A Systems Approach Larry Peterson, Oguz Sunay, and Bruce Davie
Table of Contents
Preface Acknowledgements Chapter 1: Introduction 1.1 Standardization Landscape 1.2 Access Networks 1.3 Managed Cloud Service 1.4 Beyond 5G Chapter 2: Architecture 2.1 Overview 2.2 Radio Transmission 2.3 Radio Access Network 2.4 Mobile Core 2.5 Managed Cloud Service Chapter 3: Radio Transmission 3.1 Coding and Modulation 3.2 Scheduler 3.3 Virtualized Scheduler (Slicing) 3.4 New Use Cases Chapter 4: Radio Access Network 4.1 Packet Processing Pipeline 4.2 Split RAN 4.3 Software-Defined RAN 4.4 Near Real-Time RIC 4.5 Control Loops Chapter 5: Mobile Core 5.1 Identity Management 5.2 Functional Components 5.3 Control Plane 5.4 User Plane Chapter 6: Managed Cloud Service 6.1 Building Blocks 6.2 Example Deployment 6.3 Cloud Management Platform 6.4 Connectivity API About The Book Read the Book Build the Book Contribute to the Book About The Authors
5G Mobile Networks: A Systems Approach
Larry Peterson and Oguz Sunay
Table of Contents
- Preface
- Chapter 1: Introduction
- Chapter 2: Radio Transmission
- Chapter 3: Basic Architecture
- Chapter 4: RAN Internals
- Chapter 5: Advanced Capabilities
- Chapter 6: Exemplar Implementation
- Chapter 7: Cloudification of Access
- About The Book
- About The Authors
- Read the Latest!
Clip source: Summary of - Chapter 1: Introduction
- 5G represents a fundamental rearchitecting of the access network in a way that leverages several key technology trends and sets it on a path to enable much greater innovation.
- Its promise is primarily about the transition from a single access service (broadband connectivity) to a richer collection of edge services and devices. 5G is expected to provide support for immersive user interfaces, mission-critical applications (e.g., AR/VR), and the Internet-of-Things (IoT).
- Governments have auctioned off and licensed exclusive use of various frequency bands to service providers, who in turn sell mobile access service to their subscribers
- There is also a shared-license band at 3.5 GHz, called Citizens Broadband Radio Service (CBRS), set aside in North America for cellular use
- The CBRS band allows 3 tiers of users to share the spectrum: first right of use goes to the original owners of this spectrum (naval radars and satellite ground stations); second, priority users who receive this right over 10MHz bands for three years via regional auctions; and finally the rest of the population
- The cellular network is part of the access network that implements the Internet's so-called last mile.
- Global network operators like AT&T run access networks at thousands of aggregation points-of-presence across a country like the US, along with a national backbone that interconnects those sites
- Small regional and municipal network operators might run an access network with one or two access points and then connect to the rest of the Internet through some large operator's backbone
- The cloud began as a collection of warehouse-sized datacenters, each of which provided a cost-effective way to power, cool, and operate a scalable number of servers.
- Over time, this shared infrastructure lowered the barrier to deploying scalable Internet services, but today, there is increasing pressure to offer low-latency/high-bandwidth cloud applications that cannot be effectively implemented in centralized datacenter
- Augmented Reality (AR), Virtual Reality (VR), Internet-of-Things (IoT), and Autonomous Vehicles are all examples of this kind of application
- Network operators are re-architecting the access network to use the same commodity hardware and best practices in building scalable software as cloud providers
- Such a design is sometimes referred to as CORD
- CORD is designed to host both edge services and access technologies like 5G on a common platform, where Telco Central Office is one possible location to deploy such a platform
- At its core, coding inserts extra bits into the data to help recover from all the environmental factors that interfere with signal propagation.
- Modulation generates signals that represent the encoded data stream, and it does so in a way that matches the channel characteristics
- The dynamic nature of the wireless channel is a central challenge to address in the cellular network.
- How the scheduler does its job is one of the most important properties of each generation of cellular network, which in turn depends on the multiplexing mechanism.
- 4G and 5G are based on Orthogonal Frequency-Division Multiplexing (OFDM), an approach that multiplexes data over multiple orthogonal subcarrier frequencies, each of which is modulated independently.
- The 4G approach to multiplexing downstream transmissions is called Orthogonal Frequency-Division Multiple Access (OFDMA), a specific application of OFDM that multiplexes data over a set of 12 orthogonal subcarrier frequencies, each of which is modulated independently.
- Data can simultaneously be sent on behalf of multiple users, each on a different sub-carrier frequency and for a different duration of time, to minimize the risk of data loss due to interference between adjacent bands.
- The transition from 4G to 5G introduces additional flexibility in how the radio spectrum is scheduled, making it possible to adapt the cellular network to a more diverse set of devices and applications domains.
- Fundamentally, 5G defines a family of waveforms-unlike LTE, which specified only one waveform-each optimized for a different band in the RF spectrum.
- A waveform is the frequency, amplitude, and phase-shift independent property (shape) of a signal. A sine wave is an example waveform.
- This new 5G air interface specification enables three new new use cases that go well beyond simply delivering increased bandwidth:
- Extreme Mobile Broadband
- Ultra-Reliable Low-Latency Communications
- Massive Machine-Type Communications
- All three correspond to the requirements introduced in Chapter 1, and can be attributed to four fundamental improvements in how 5G multiplexes data onto the radio spectrum
- Being able to change the waveform
- The ability to dynamically change the size and number of schedulable resource units, which opens the door to making fine-grain scheduling decisions that are critical to predictable, low-latency communication
- Multiple Access
- New spectrum available to 5G NR, with mmWave allocations opening above 24 GHz
- Delivering mobile connectivity to a massive number of IoT devices
- Support for IoT device connectivity revolves around allocating some of the available radio spectrum to a light-weight (simplified) air interface
- The cellular network consists of two main subsystems: the Radio Access Network (RAN) and the Mobile Core.
- RAN manages the radio spectrum, making sure it is used efficiently and meets the quality-of-service requirements of every user
- Mobile Core is a bundle of functionality that serves several purposes: Provides Internet (IP) connectivity for both data and voice services, Tracks user mobility to ensure uninterrupted service, Tracks subscriber usage for billing and charging, and is partitioned into a Control Plane and User Plane.
- Each base station establishes the wireless channel for a subscriber’s UE upon power-up or upon handover when the subscriber is active, and forwards signaling traffic between the two to enable UE authentication, registration, and mobility tracking
- The base station forwards both control and user plane packets between the Mobile Core and the UE, and coordinates UE handovers with neighboring base stations using direct station-to-station links
- The main function of the Mobile Core is to provide external packet data network (i.e., Internet) connectivity to mobile subscribers, while ensuring that they are authenticated and their observed service qualities satisfy their subscription SLAs.
- It needs to manage all subscribers' mobility by keeping track of their last whereabouts at the granularity of the serving base station.
- Components of the 4G Mobile Core include: MME (Mobility Management Entity), HSS (Home Subscriber Server), PCRF (Policy and Charging Rules Function), SGW (Serving Gateway), and PGW (Packet Gateway).
- All of these components are often combined in a single device, commonly referred to as an S/PGW.
- Adopts a microservice-like architecture
- Three groups of functional blocks
- AMF (Core Access and Mobility Management Function): Responsible for connection and reachability management, mobility management, access authentication and authorization, and location services
- SMF (Session Management Function) Manages each UE session
- PCF (Policy Control Function): Manages the policy rules that other CP functions then enforce
- UDM (Unified Data Management) manages user identity, including the generation of authentication credentials
- AUSF (Authentication Server Function): Essentially an authentication server
- UPF (User Plane Function): Forwards traffic between RAN and the Internet, corresponding to the S/PGW combination in EPC
- Of these, the first and third groups are best viewed as a straightforward refactoring of 4G's EPC, while the second group is 3GPP's way of pointing to a cloud native solution as the desired end-state for the Mobile Core
- Each UE has an operator-provided SIM card which uniquely identifies the subscriber (i.e., phone number) and establishes radio parameters (e.g., frequency band) needed to communicate with that operator’s Base Stations.
- When a UE first becomes active, it communicates with a nearby Base Station over a temporary (unauthenticated) radio link (Step 1).
- The Base Station forwards the request to the Core-CP over the existing tunnel, and, in turn, initiates an authentication protocol with the UE (Step 2).
- 3GPP officially spells out multiple deployment options, which can be summarized as follows: Standalone 4G / Stand-Alone 5G Non-Standalone (4G+5G RAN) over 4G’s EPC, NSA, and NG-Core
- The second of the three options, known as "NSA", involves 5G base stations being deployed alongside the existing 4G station in a given geography to provide a data-rate and capacity boost.
- In NSA, control plane traffic between the user equipment and the 4G Mobile Core utilizes (i.e., is forwarded through) 4G base station, and the 5G station is used only to carry user traffic.
- The RRC (Radio Resource Control) runs in the RAN's control plane; it does not process packets on the user plane.
- RLC (Radio Link Control) is responsible for segmentation and reassembly, including reliably transmitting/receiving segments by implementing a form of ARQ (automatic repeat request).
- MAC (Media Access Control) handles buffering, multiplexing and demultiplexing segments, including all real-time scheduling decisions about what segments are transmitted when and also able to make a “late” forwarding decision (i.e., to alternative carrier frequencies, including Wi-Fi)
- PHY (Physical Layer) controls coding and modulation.
- The functionality outlined above is partitioned between physical elements, and hence, “split” across centralized and distributed locations.
- A single Central Unit (CU) running in the cloud serves multiple Distributed Units (DUs), each of which in turn serve multiple Radio Units (RUs).
- RRC (centralized in the CU) is responsible for only near-real-time configuration and control decision making, while the Scheduler that is part of the MAC stage (which lies on the RAN’s control plane and user plane, respectively.)
- Because scheduling decisions for radio transmission are made by the MAC layer in real time, a DU needs to be "near" (within 1ms) the RUs it manages.
- The RAN is partitioned into two sub-components: a 3GPP-compliant way for the RAN to interface to the Mobile Core’s control plane and a new programmatic API for exerting software-based control over the pipeline that implements RAN user plane.
- RIC maintains a RAN Network Information Base (R-NIB)-a common set of information that can be consumed by numerous control apps.
- NODES: Base Stations and Mobile Devices
- Base Station Attributes: Identifiers Version Config Report RRM config PHY resource usage
- Mobile Device Attributes: Identifiers Capability Measurement Config State (Active/Idle)
- LINKS: Actual between two nodes and Potential between UEs and all neighbor cells
- SLICES: Virtualized RAN Construct
- Each RAN element advertises a Service Model, which effectively defines the set of RAN Functions the element is able to support.
- RIC issues a combination of the following four operations against this Service Model: report, control, policy, insert, and insert
- Report: RIC asks the element to report a function-specific value setting.
- Policy: sets a policy parameter on one of the activated functions
- Insert: instructs element to activate a user plane function
- Control: sets the outer loop of functions that can be applied to the RAN
- Takeaway: These interfaces define the pivot points around which 5G RAN is architected to evolve
- Decoupling control and data code paths allows them to be optimized independently
- Modern white-box switches with programmable packet forwarding pipelines are a perfect example of specialized hardware we can exploit in the cellular network
- Mobile Core, Central Unit (CU), Distributed Unit (DU), and Radio Unit (RU) can be mapped directly onto an SDN-enabled data plane
- The PHY (Physical) element of the RAN pipeline is split between the DU and RU partition
- PDCP-C element and the Control Plane (Forwarding) element can be combined into a single functional block
- Pushing RAN and Mobile Core forwarding functionality into the switching hardware results in overlapping terminology
- Once decoupled, different functions can be placed in different physical locations.
- The user plane at the edge of the network (e.g., in the Central Office) and the control plane to a centralized cloud (eg. Google or Amazon).
- Centralization also facilitates collecting and analyzing data across multiple edge locations.
- The ability to differentiate the level of service offered to different applications and customers through network slicing fundamentally comes down to scheduling
- A network slice is a realization of the QoS Class Identifier (QCI) discussed earlier
- 3GPP specifies a standard set of network slices, called Standardized Slice Type (SST) values
- SST 1 corresponds to mobile broadband, SST 2 corresponds to Ultra-Reliable Low Latency Communications (ULLC), SST 3 corresponds to Massive IoT
- The goal of RAN slicing is to programmatically create virtual RAN nodes (base stations) that operate on the same hardware and share the spectrum resources according to a given policy for different applications, services, users, and so on.
- There are several possible configurations of a disaggregated RAN
- Centralized near-real-time control applications cooperating with distributed real-time RAN schedulers
- RAN slices share the antennas and RF components, but have their own CU-U and CU-C
- In addition to slicing the RAN, we also need to slice the Mobile Core.
- The steps we've taken in the previous chapters to virtualize, disaggregate, optimize, distribute, and slice the cellular network not only help us understand the inner-workings of 5G, but they are also necessary to reduce the entirety of the 5G cellular network to practice.
- A CORD POD connects downstream to a set of DUs (and associated RUs), and upstream to the rest of the Internet.
- Internally, it includes servers and switches arranged in a leaf-spine topology (the figure shows two leaves and two spine switches, but the design allows anywhere from a single switch to two leaf switches per rack and as many spine switches as necessary to provide sufficient east-to-west bandwidth).
- With respect to software, Figure 34 shows a combination of RAN (red) and Mobile Core (blue) components, plus modules that define the CORD platform.
- Stratum: A thin operating system that runs locally on each white-box switch.
- ONOS: A logically centralized SDN controller that hosts a collection of SDN control applications, each of which controls some aspect of the underlying network.
- Trellis control application managing a (possibly distributed) leaf-spine fabric
- P4Runtime: An SDN-ready interface for controlling forwarding behavior at runtime
- OpenConfig Models: Define a base for device configuration and management
- gNOI: A collection of microservices that enable switch specific operations, like certificate management, device testing, software upgrade, and networking troubleshooting
- A collection of multi-tenant clouds-including virtualized RAN resources alongside conventional compute, storage, and network resources-hosting both Telco and Over-the-Top (OTT) services and applications.
- Each individual cloud site is potentially owned by a different organization, and as a consequence, each site is able to host (and isolate) applications on behalf of many other people and organizations.
- Can run a 5G-enabled edge cloud as a centrally managed service
- Deploy an edge cloud in enterprises, configured with the user plane components of the RAN and Mobile Core (along with any edge services the enterprise wants to run locally), and then manage that edge deployment from the central cloud
- The value of this is to bring 5G wireless advantages into the enterprise
- Multi-Access: The access-edge will need to support multiple access technologies (e.g., WiFi, 5G, fiber), and allow users to seamlessly move between them.
- Heterogeneity: Research is needed to tailor edge services to take advantage of heterogeneous resources, as well as how to construct end-to-end applications from such a collection of building blocks (i.e., virtualization, hyper-localization, data reduction, near-real time, etc.)
- Distributed Services: Services will become inherently distributed, with some aspects running at the edge, some in the datacenter, and some running on-premises or in an end device (e,g., on-vehicle).
- Scalability: Access-edge could span thousands or tens of thousands of edge sites, and scaling up the ability to remotely orchestrate that many edge sites will be a qualitatively different challenge than managing one in a single data center.
- Customization: Monetizing the edge will require ability to offer differentiated and customized services to different classes of subscribers/applications, and a need to analyze control loops, define analytic-based controllers, and design dynamically adaptable mechanisms.
- This book is part of the Systems Approach Series, with an online version published at https://5G.systemsapproach.org
- To build a web-viewable version, you first need to download the source: https://github.com/SystemsApproach/5G.git
- The build process is stored in the Makefile and requires Python to be installed. The Makefile will create a virtualenv (venv-docs) which installs the documentation generation toolset.
- Larry Peterson is the Robert E. Kahn Professor of Computer Science, Emeritus at Princeton University, where he served as Chair from 2003-2009
- Lead the CORD and Aether access-edge cloud projects at the Open Networking Foundation (ONF), where he serves CTO
- Oguz Sunay is the Vice President for Research & Development at ONF
- Before joining ONF, Sunay was the CTO at Argela-USA
- He has also held prior industry positions at Nokia Research Center and Bell Laboratories
- Hold many U.S. and European patents on various aspects of 3G, 4G, and 5G
Clip source: Summary of - Chapter 2: Radio Transmission
For anyone familiar with wireless access technologies like Wi-Fi, the cellular network is most unique due to its approach to sharing the available radio spectrum among users, all the while allowing those users to remain connected while moving. This has resulted in a highly dynamic and adaptive approach, in which coding, modulation and scheduling play a central role.
- At its core, coding inserts extra bits into the data to help recover from all the environmental factors that interfere with signal propagation.
- Modulation generates signals that represent the encoded data stream, and it does so in a way that matches the channel characteristics
- The dynamic nature of the wireless channel is a central challenge to address in the cellular network.
- How the scheduler does its job is one of the most important properties of each generation of cellular network, which in turn depends on the multiplexing mechanism.
- 4G and 5G are based on Orthogonal Frequency-Division Multiplexing (OFDM), an approach that multiplexes data over multiple orthogonal subcarrier frequencies, each of which is modulated independently.
- The 4G approach to multiplexing downstream transmissions is called Orthogonal Frequency-Division Multiple Access (OFDMA), a specific application of OFDM that multiplexes data over a set of 12 orthogonal subcarrier frequencies, each of which is modulated independently.
- Data can simultaneously be sent on behalf of multiple users, each on a different sub-carrier frequency and for a different duration of time, to minimize the risk of data loss due to interference between adjacent bands.
- The transition from 4G to 5G introduces additional flexibility in how the radio spectrum is scheduled, making it possible to adapt the cellular network to a more diverse set of devices and applications domains.
- Fundamentally, 5G defines a family of waveforms-unlike LTE, which specified only one waveform-each optimized for a different band in the RF spectrum.
- A waveform is the frequency, amplitude, and phase-shift independent property (shape) of a signal.
- These different waveforms affect the scheduling and subcarrier intervals.
- This new 5G air interface specification enables three new new use cases that go well beyond simply delivering increased bandwidth:
- Extreme Mobile Broadband
- Ultra-Reliable Low-Latency Communications
- Massive Machine-Type Communications
- All three correspond to the requirements introduced in Chapter 1, and can be attributed to four fundamental improvements in how 5G multiplexes data onto the radio spectrum
- Being able to change the waveform
- The ability to dynamically change the size and number of schedulable resource units, which opens the door to making fine-grain scheduling decisions that are critical to predictable, low-latency communication
- Multiple Access
- New spectrum available to 5G NR, with mmWave allocations opening above 24 GHz
- Delivering mobile connectivity to a massive number of IoT devices
- Support for IoT device connectivity revolves around allocating some of the available radio spectrum to a light-weight (simplified) air interface
- The cellular network consists of two main subsystems: the Radio Access Network (RAN) and the Mobile Core.
- RAN manages the radio spectrum, making sure it is used efficiently and meets the quality-of-service requirements of every user
- Mobile Core is a bundle of functionality that serves several purposes: Provides Internet (IP) connectivity for both data and voice services, Tracks user mobility to ensure uninterrupted service, Tracks subscriber usage for billing and charging, and is partitioned into a Control Plane and User Plane.
- Each base station establishes the wireless channel for a subscriber’s UE upon power-up or upon handover when the subscriber is active, and forwards signaling traffic between the two to enable UE authentication, registration, and mobility tracking
- The base station forwards both control and user plane packets between the Mobile Core and the UE, and coordinates UE handovers with neighboring base stations using direct station-to-station links
- The main function of the Mobile Core is to provide external packet data network (i.e., Internet) connectivity to mobile subscribers, while ensuring that they are authenticated and their observed service qualities satisfy their subscription SLAs.
- It needs to manage all subscribers' mobility by keeping track of their last whereabouts at the granularity of the serving base station.
- Components of the 4G Mobile Core include: MME (Mobility Management Entity), HSS (Home Subscriber Server), PCRF (Policy and Charging Rules Function), SGW (Serving Gateway), and PGW (Packet Gateway).
- All of these components are often combined in a single device, commonly referred to as an S/PGW.
- Adopts a microservice-like architecture
- Three groups of functional blocks
- AMF (Core Access and Mobility Management Function): Responsible for connection and reachability management, mobility management, access authentication and authorization, and location services
- SMF (Session Management Function) Manages each UE session
- PCF (Policy Control Function): Manages the policy rules that other CP functions then enforce
- UDM (Unified Data Management) manages user identity, including the generation of authentication credentials
- AUSF (Authentication Server Function): Essentially an authentication server
- UPF (User Plane Function): Forwards traffic between RAN and the Internet, corresponding to the S/PGW combination in EPC
- Of these, the first and third groups are best viewed as a straightforward refactoring of 4G's EPC, while the second group is 3GPP's way of pointing to a cloud native solution as the desired end-state for the Mobile Core
- Each UE has an operator-provided SIM card which uniquely identifies the subscriber (i.e., phone number) and establishes radio parameters (e.g., frequency band) needed to communicate with that operator’s Base Stations.
- When a UE first becomes active, it communicates with a nearby Base Station over a temporary (unauthenticated) radio link (Step 1).
- The Base Station forwards the request to the Core-CP over the existing tunnel, and, in turn, initiates an authentication protocol with the UE (Step 2).
- 3GPP officially spells out multiple deployment options, which can be summarized as follows: Standalone 4G / Stand-Alone 5G Non-Standalone (4G+5G RAN) over 4G’s EPC, NSA, and NG-Core
- The second of the three options, known as "NSA", involves 5G base stations being deployed alongside the existing 4G station in a given geography to provide a data-rate and capacity boost.
- In NSA, control plane traffic between the user equipment and the 4G Mobile Core utilizes (i.e., is forwarded through) 4G base station, and the 5G station is used only to carry user traffic.
- The RRC (Radio Resource Control) runs in the RAN's control plane; it does not process packets on the user plane.
- RLC (Radio Link Control) is responsible for segmentation and reassembly, including reliably transmitting/receiving segments by implementing a form of ARQ (automatic repeat request).
- MAC (Media Access Control) handles buffering, multiplexing and demultiplexing segments, including all real-time scheduling decisions about what segments are transmitted when and also able to make a “late” forwarding decision (i.e., to alternative carrier frequencies, including Wi-Fi)
- PHY (Physical Layer) controls coding and modulation.
- The functionality outlined above is partitioned between physical elements, and hence, “split” across centralized and distributed locations.
- A single Central Unit (CU) running in the cloud serves multiple Distributed Units (DUs), each of which in turn serve multiple Radio Units (RUs).
- RRC (centralized in the CU) is responsible for only near-real-time configuration and control decision making, while the Scheduler that is part of the MAC stage (which lies on the RAN’s control plane and user plane, respectively.)
- Because scheduling decisions for radio transmission are made by the MAC layer in real time, a DU needs to be "near" (within 1ms) the RUs it manages.
- The RAN is partitioned into two sub-components: a 3GPP-compliant way for the RAN to interface to the Mobile Core’s control plane and a new programmatic API for exerting software-based control over the pipeline that implements RAN user plane.
- RIC maintains a RAN Network Information Base (R-NIB)-a common set of information that can be consumed by numerous control apps.
- NODES: Base Stations and Mobile Devices
- Base Station Attributes: Identifiers Version Config Report RRM config PHY resource usage
- Mobile Device Attributes: Identifiers Capability Measurement Config State (Active/Idle)
- LINKS: Actual between two nodes and Potential between UEs and all neighbor cells
- SLICES: Virtualized RAN Construct
- Each RAN element advertises a Service Model, which effectively defines the set of RAN Functions the element is able to support.
- RIC issues a combination of the following four operations against this Service Model: report, control, policy, insert, and insert
- Report: RIC asks the element to report a function-specific value setting.
- Policy: sets a policy parameter on one of the activated functions
- Insert: instructs element to activate a user plane function
- Control: sets the outer loop of functions that can be applied to the RAN
- Takeaway: These interfaces define the pivot points around which 5G RAN is architected to evolve
- Decoupling control and data code paths allows them to be optimized independently
- Modern white-box switches with programmable packet forwarding pipelines are a perfect example of specialized hardware we can exploit in the cellular network
- Mobile Core, Central Unit (CU), Distributed Unit (DU), and Radio Unit (RU) can be mapped directly onto an SDN-enabled data plane
- The PHY (Physical) element of the RAN pipeline is split between the DU and RU partition
- PDCP-C element and the Control Plane (Forwarding) element can be combined into a single functional block
- Pushing RAN and Mobile Core forwarding functionality into the switching hardware results in overlapping terminology
- Once decoupled, different functions can be placed in different physical locations.
- The user plane at the edge of the network (e.g., in the Central Office) and the control plane to a centralized cloud (eg. Google or Amazon).
- Centralization also facilitates collecting and analyzing data across multiple edge locations.
- The ability to differentiate the level of service offered to different applications and customers through network slicing fundamentally comes down to scheduling
- A network slice is a realization of the QoS Class Identifier (QCI) discussed earlier
- 3GPP specifies a standard set of network slices, called Standardized Slice Type (SST) values
- SST 1 corresponds to mobile broadband, SST 2 corresponds to Ultra-Reliable Low Latency Communications (ULLC), SST 3 corresponds to Massive IoT
- The goal of RAN slicing is to programmatically create virtual RAN nodes (base stations) that operate on the same hardware and share the spectrum resources according to a given policy for different applications, services, users, and so on.
- There are several possible configurations of a disaggregated RAN
- Centralized near-real-time control applications cooperating with distributed real-time RAN schedulers
- RAN slices share the antennas and RF components, but have their own CU-U and CU-C
- In addition to slicing the RAN, we also need to slice the Mobile Core.
- The steps we've taken in the previous chapters to virtualize, disaggregate, optimize, distribute, and slice the cellular network not only help us understand the inner-workings of 5G, but they are also necessary to reduce the entirety of the 5G cellular network to practice.
- A CORD POD connects downstream to a set of DUs (and associated RUs), and upstream to the rest of the Internet.
- Internally, it includes servers and switches arranged in a leaf-spine topology (the figure shows two leaves and two spine switches, but the design allows anywhere from a single switch to two leaf switches per rack and as many spine switches as necessary to provide sufficient east-to-west bandwidth).
- With respect to software, Figure 34 shows a combination of RAN (red) and Mobile Core (blue) components, plus modules that define the CORD platform.
- Stratum: A thin operating system that runs locally on each white-box switch.
- ONOS: A logically centralized SDN controller that hosts a collection of SDN control applications, each of which controls some aspect of the underlying network.
- Trellis control application managing a (possibly distributed) leaf-spine fabric
- P4Runtime: An SDN-ready interface for controlling forwarding behavior at runtime
- OpenConfig Models: Define a base for device configuration and management
- gNOI: A collection of microservices that enable switch specific operations, like certificate management, device testing, software upgrade, and networking troubleshooting
- A collection of multi-tenant clouds-including virtualized RAN resources alongside conventional compute, storage, and network resources-hosting both Telco and Over-the-Top (OTT) services and applications.
- Each individual cloud site is potentially owned by a different organization, and as a consequence, each site is able to host (and isolate) applications on behalf of many other people and organizations.
- Can run a 5G-enabled edge cloud as a centrally managed service
- Deploy an edge cloud in enterprises, configured with the user plane components of the RAN and Mobile Core (along with any edge services the enterprise wants to run locally), and then manage that edge deployment from the central cloud
- The value of this is to bring 5G wireless advantages into the enterprise
- Multi-Access: The access-edge will need to support multiple access technologies (e.g., WiFi, 5G, fiber), and allow users to seamlessly move between them.
- Heterogeneity: Research is needed to tailor edge services to take advantage of heterogeneous resources, as well as how to construct end-to-end applications from such a collection of building blocks (i.e., virtualization, hyper-localization, data reduction, near-real time, etc.)
- Distributed Services: Services will become inherently distributed, with some aspects running at the edge, some in the datacenter, and some running on-premises or in an end device (e,g., on-vehicle).
- Scalability: Access-edge could span thousands or tens of thousands of edge sites, and scaling up the ability to remotely orchestrate that many edge sites will be a qualitatively different challenge than managing one in a single data center.
- Customization: Monetizing the edge will require ability to offer differentiated and customized services to different classes of subscribers/applications, and a need to analyze control loops, define analytic-based controllers, and design dynamically adaptable mechanisms.
- This book is part of the Systems Approach Series, with an online version published at https://5G.systemsapproach.org
- To track progress and receive notices about new versions, you can follow the project on Facebook and Twitter.
- Read a running commentary on how the Internet is evolving
- To build a web-viewable version, you first need to download the source: https://github.com/SystemsApproach/5G.git
- The build process is stored in the Makefile and requires Python to be installed. The Makefile will create a virtualenv (venv-docs) which installs the documentation generation toolset.
- Larry Peterson is the Robert E. Kahn Professor of Computer Science, Emeritus at Princeton University, where he served as Chair from 2003-2009
- Lead the CORD and Aether access-edge cloud projects at the Open Networking Foundation (ONF), where he serves CTO
- Oguz Sunay is the Vice President for Research & Development at ONF
- Before joining ONF, Sunay was the CTO at Argela-USA
- He has also held prior industry positions at Nokia Research Center and Bell Laboratories
- Hold many U.S. and European patents on various aspects of 3G, 4G, and 5G
Clip source: Summary of - Chapter 3: Basic Architecture
This chapter identifies the main architectural components of cellular access networks. It focuses on the components that are common to both 4G and 5G and establishes a foundation for understanding the advanced features of 5G presented in later chapters. It also introduces the 3GPP standardization process, which has historically been concerned about telephony and almost completely disconnected from the Internet-related efforts
- The cellular network consists of two main subsystems: the Radio Access Network (RAN) and the Mobile Core.
- RAN manages the radio spectrum, making sure it is used efficiently and meets the quality-of-service requirements of every user
- Mobile Core is a bundle of functionality that serves several purposes: Provides Internet (IP) connectivity for both data and voice services, Tracks user mobility to ensure uninterrupted service, Tracks subscriber usage for billing and charging, and is partitioned into a Control Plane and User Plane.
- Each base station establishes the wireless channel for a subscriber’s UE upon power-up or upon handover when the subscriber is active, and forwards signaling traffic between the two to enable UE authentication, registration, and mobility tracking
- The base station forwards both control and user plane packets between the Mobile Core and the UE, and coordinates UE handovers with neighboring base stations using direct station-to-station links
- The main function of the Mobile Core is to provide external packet data network (i.e., Internet) connectivity to mobile subscribers, while ensuring that they are authenticated and their observed service qualities satisfy their subscription SLAs.
- It needs to manage all subscribers' mobility by keeping track of their last whereabouts at the granularity of the serving base station.
- Components of the 4G Mobile Core include: MME (Mobility Management Entity), HSS (Home Subscriber Server), PCRF (Policy and Charging Rules Function), SGW (Serving Gateway), and PGW (Packet Gateway).
- All of these components are often combined in a single device, commonly referred to as an S/PGW.
- Adopts a microservice-like architecture
- Three groups of functional blocks
- AMF (Core Access and Mobility Management Function): Responsible for connection and reachability management, mobility management, access authentication and authorization, and location services
- SMF (Session Management Function) Manages each UE session
- PCF (Policy Control Function): Manages the policy rules that other CP functions then enforce
- UDM (Unified Data Management) manages user identity, including the generation of authentication credentials
- AUSF (Authentication Server Function): Essentially an authentication server
- UPF (User Plane Function): Forwards traffic between RAN and the Internet, corresponding to the S/PGW combination in EPC
- Of these, the first and third groups are best viewed as a straightforward refactoring of 4G's EPC, while the second group is 3GPP's way of pointing to a cloud native solution as the desired end-state for the Mobile Core
- Each UE has an operator-provided SIM card which uniquely identifies the subscriber (i.e., phone number) and establishes radio parameters (e.g., frequency band) needed to communicate with that operator’s Base Stations.
- When a UE first becomes active, it communicates with a nearby Base Station over a temporary (unauthenticated) radio link (Step 1).
- The Base Station forwards the request to the Core-CP over the existing tunnel, and, in turn, initiates an authentication protocol with the UE (Step 2).
- 3GPP officially spells out multiple deployment options, which can be summarized as follows: Standalone 4G / Stand-Alone 5G Non-Standalone (4G+5G RAN) over 4G’s EPC, NSA, and NG-Core
- The second of the three options, known as "NSA", involves 5G base stations being deployed alongside the existing 4G station in a given geography to provide a data-rate and capacity boost.
- In NSA, control plane traffic between the user equipment and the 4G Mobile Core utilizes (i.e., is forwarded through) 4G base station, and the 5G station is used only to carry user traffic.
- The RRC (Radio Resource Control) runs in the RAN's control plane; it does not process packets on the user plane.
- RLC (Radio Link Control) is responsible for segmentation and reassembly, including reliably transmitting/receiving segments by implementing a form of ARQ (automatic repeat request).
- MAC (Media Access Control) handles buffering, multiplexing and demultiplexing segments, including all real-time scheduling decisions about what segments are transmitted when and also able to make a “late” forwarding decision (i.e., to alternative carrier frequencies, including Wi-Fi)
- PHY (Physical Layer) controls coding and modulation.
- The functionality outlined above is partitioned between physical elements, and hence, “split” across centralized and distributed locations.
- A single Central Unit (CU) running in the cloud serves multiple Distributed Units (DUs), each of which in turn serve multiple Radio Units (RUs).
- RRC (centralized in the CU) is responsible for only near-real-time configuration and control decision making, while the Scheduler that is part of the MAC stage (which lies on the RAN’s control plane and user plane, respectively.)
- Because scheduling decisions for radio transmission are made by the MAC layer in real time, a DU needs to be "near" (within 1ms) the RUs it manages.
- The RAN is partitioned into two sub-components: a 3GPP-compliant way for the RAN to interface to the Mobile Core’s control plane and a new programmatic API for exerting software-based control over the pipeline that implements RAN user plane.
- RIC maintains a RAN Network Information Base (R-NIB)-a common set of information that can be consumed by numerous control apps.
- NODES: Base Stations and Mobile Devices
- Base Station Attributes: Identifiers Version Config Report RRM config PHY resource usage
- Mobile Device Attributes: Identifiers Capability Measurement Config State (Active/Idle)
- LINKS: Actual between two nodes and Potential between UEs and all neighbor cells
- SLICES: Virtualized RAN Construct
- Each RAN element advertises a Service Model, which effectively defines the set of RAN Functions the element is able to support.
- RIC issues a combination of the following four operations against this Service Model: report, control, policy, insert, and insert
- Report: RIC asks the element to report a function-specific value setting.
- Policy: sets a policy parameter on one of the activated functions
- Insert: instructs element to activate a user plane function
- Control: sets the outer loop of functions that can be applied to the RAN
- Takeaway: These interfaces define the pivot points around which 5G RAN is architected to evolve
- Decoupling control and data code paths allows them to be optimized independently
- Modern white-box switches with programmable packet forwarding pipelines are a perfect example of specialized hardware we can exploit in the cellular network
- Mobile Core, Central Unit (CU), Distributed Unit (DU), and Radio Unit (RU) can be mapped directly onto an SDN-enabled data plane
- The PHY (Physical) element of the RAN pipeline is split between the DU and RU partition
- PDCP-C element and the Control Plane (Forwarding) element can be combined into a single functional block
- Pushing RAN and Mobile Core forwarding functionality into the switching hardware results in overlapping terminology
- Once decoupled, different functions can be placed in different physical locations.
- The user plane at the edge of the network (e.g., in the Central Office) and the control plane to a centralized cloud (eg. Google or Amazon).
- Centralization also facilitates collecting and analyzing data across multiple edge locations.
- The ability to differentiate the level of service offered to different applications and customers through network slicing fundamentally comes down to scheduling
- A network slice is a realization of the QoS Class Identifier (QCI) discussed earlier
- 3GPP specifies a standard set of network slices, called Standardized Slice Type (SST) values
- SST 1 corresponds to mobile broadband, SST 2 corresponds to Ultra-Reliable Low Latency Communications (ULLC), SST 3 corresponds to Massive IoT
- The goal of RAN slicing is to programmatically create virtual RAN nodes (base stations) that operate on the same hardware and share the spectrum resources according to a given policy for different applications, services, users, and so on.
- There are several possible configurations of a disaggregated RAN
- Centralized near-real-time control applications cooperating with distributed real-time RAN schedulers
- RAN slices share the antennas and RF components, but have their own CU-U and CU-C
- In addition to slicing the RAN, we also need to slice the Mobile Core.
- The steps we've taken in the previous chapters to virtualize, disaggregate, optimize, distribute, and slice the cellular network not only help us understand the inner-workings of 5G, but they are also necessary to reduce the entirety of the 5G cellular network to practice.
- A CORD POD connects downstream to a set of DUs (and associated RUs), and upstream to the rest of the Internet.
- Internally, it includes servers and switches arranged in a leaf-spine topology (the figure shows two leaves and two spine switches, but the design allows anywhere from a single switch to two leaf switches per rack and as many spine switches as necessary to provide sufficient east-to-west bandwidth).
- With respect to software, Figure 34 shows a combination of RAN (red) and Mobile Core (blue) components, plus modules that define the CORD platform.
- Stratum: A thin operating system that runs locally on each white-box switch.
- ONOS: A logically centralized SDN controller that hosts a collection of SDN control applications, each of which controls some aspect of the underlying network.
- Trellis control application managing a (possibly distributed) leaf-spine fabric
- P4Runtime: An SDN-ready interface for controlling forwarding behavior at runtime
- OpenConfig Models: Define a base for device configuration and management
- gNOI: A collection of microservices that enable switch specific operations, like certificate management, device testing, software upgrade, and networking troubleshooting
- A collection of multi-tenant clouds-including virtualized RAN resources alongside conventional compute, storage, and network resources-hosting both Telco and Over-the-Top (OTT) services and applications.
- Each individual cloud site is potentially owned by a different organization, and as a consequence, each site is able to host (and isolate) applications on behalf of many other people and organizations.
- Can run a 5G-enabled edge cloud as a centrally managed service
- Deploy an edge cloud in enterprises, configured with the user plane components of the RAN and Mobile Core (along with any edge services the enterprise wants to run locally), and then manage that edge deployment from the central cloud
- The value of this is to bring 5G wireless advantages into the enterprise
- Multi-Access: The access-edge will need to support multiple access technologies (e.g., WiFi, 5G, fiber), and allow users to seamlessly move between them.
- Heterogeneity: Research is needed to tailor edge services to take advantage of heterogeneous resources, as well as how to construct end-to-end applications from such a collection of building blocks (i.e., virtualization, hyper-localization, data reduction, near-real time, etc.)
- Distributed Services: Services will become inherently distributed, with some aspects running at the edge, some in the datacenter, and some running on-premises or in an end device (e,g., on-vehicle).
- Scalability: Access-edge could span thousands or tens of thousands of edge sites, and scaling up the ability to remotely orchestrate that many edge sites will be a qualitatively different challenge than managing one in a single data center.
- Customization: Monetizing the edge will require ability to offer differentiated and customized services to different classes of subscribers/applications, and a need to analyze control loops, define analytic-based controllers, and design dynamically adaptable mechanisms.
- This book is part of the Systems Approach Series, with an online version published at https://5G.systemsapproach.org
- To track progress and receive notices about new versions, you can follow the project on Facebook and Twitter.
- Read a running commentary on how the Internet is evolving
- To build a web-viewable version, you first need to download the source: https://github.com/SystemsApproach/5G.git
- The build process is stored in the Makefile and requires Python to be installed. The Makefile will create a virtualenv (venv-docs) which installs the documentation generation toolset.
- Larry Peterson is the Robert E. Kahn Professor of Computer Science, Emeritus at Princeton University, where he served as Chair from 2003-2009
- Lead the CORD and Aether access-edge cloud projects at the Open Networking Foundation (ONF), where he serves CTO
- Oguz Sunay is the Vice President for Research & Development at ONF
- Before joining ONF, Sunay was the CTO at Argela-USA
- He has also held prior industry positions at Nokia Research Center and Bell Laboratories
- Hold many U.S. and European patents on various aspects of 3G, 4G, and 5G
Clip source: Summary of - Chapter 4: RAN Internals
The description of the RAN in the previous chapter focused on functionality, but was mostly silent about the internal structure. We now focus on some of the internal details, and in doing so, explain how the 5G RAN is being transformed in 5G.The RAN's internal structure
- The RRC (Radio Resource Control) runs in the RAN's control plane; it does not process packets on the user plane.
- RLC (Radio Link Control) is responsible for segmentation and reassembly, including reliably transmitting/receiving segments by implementing a form of ARQ (automatic repeat request).
- MAC (Media Access Control) handles buffering, multiplexing and demultiplexing segments, including all real-time scheduling decisions about what segments are transmitted when and also able to make a “late” forwarding decision (i.e., to alternative carrier frequencies, including Wi-Fi)
- PHY (Physical Layer) controls coding and modulation.
- The functionality outlined above is partitioned between physical elements, and hence, “split” across centralized and distributed locations.
- A single Central Unit (CU) running in the cloud serves multiple Distributed Units (DUs), each of which in turn serve multiple Radio Units (RUs).
- RRC (centralized in the CU) is responsible for only near-real-time configuration and control decision making, while the Scheduler that is part of the MAC stage (which lies on the RAN’s control plane and user plane, respectively.)
- Because scheduling decisions for radio transmission are made by the MAC layer in real time, a DU needs to be "near" (within 1ms) the RUs it manages.
- The RAN is partitioned into two sub-components: a 3GPP-compliant way for the RAN to interface to the Mobile Core’s control plane and a new programmatic API for exerting software-based control over the pipeline that implements RAN user plane.
- RIC maintains a RAN Network Information Base (R-NIB)-a common set of information that can be consumed by numerous control apps.
- NODES: Base Stations and Mobile Devices
- Base Station Attributes: Identifiers Version Config Report RRM config PHY resource usage
- Mobile Device Attributes: Identifiers Capability Measurement Config State (Active/Idle)
- LINKS: Actual between two nodes and Potential between UEs and all neighbor cells
- SLICES: Virtualized RAN Construct
- Each RAN element advertises a Service Model, which effectively defines the set of RAN Functions the element is able to support.
- RIC issues a combination of the following four operations against this Service Model: report, control, policy, insert, and insert
- Report: RIC asks the element to report a function-specific value setting.
- Policy: sets a policy parameter on one of the activated functions
- Insert: instructs element to activate a user plane function
- Control: sets the outer loop of functions that can be applied to the RAN
- Takeaway: These interfaces define the pivot points around which 5G RAN is architected to evolve
- Decoupling control and data code paths allows them to be optimized independently
- Modern white-box switches with programmable packet forwarding pipelines are a perfect example of specialized hardware we can exploit in the cellular network
- Mobile Core, Central Unit (CU), Distributed Unit (DU), and Radio Unit (RU) can be mapped directly onto an SDN-enabled data plane
- The PHY (Physical) element of the RAN pipeline is split between the DU and RU partition
- PDCP-C element and the Control Plane (Forwarding) element can be combined into a single functional block
- Pushing RAN and Mobile Core forwarding functionality into the switching hardware results in overlapping terminology
- Once decoupled, different functions can be placed in different physical locations.
- The user plane at the edge of the network (e.g., in the Central Office) and the control plane to a centralized cloud (eg. Google or Amazon).
- Centralization also facilitates collecting and analyzing data across multiple edge locations.
- The ability to differentiate the level of service offered to different applications and customers through network slicing fundamentally comes down to scheduling
- A network slice is a realization of the QoS Class Identifier (QCI) discussed earlier
- 3GPP specifies a standard set of network slices, called Standardized Slice Type (SST) values
- SST 1 corresponds to mobile broadband, SST 2 corresponds to Ultra-Reliable Low Latency Communications (ULLC), SST 3 corresponds to Massive IoT
- The goal of RAN slicing is to programmatically create virtual RAN nodes (base stations) that operate on the same hardware and share the spectrum resources according to a given policy for different applications, services, users, and so on.
- There are several possible configurations of a disaggregated RAN
- Centralized near-real-time control applications cooperating with distributed real-time RAN schedulers
- RAN slices share the antennas and RF components, but have their own CU-U and CU-C
- In addition to slicing the RAN, we also need to slice the Mobile Core.
- The steps we've taken in the previous chapters to virtualize, disaggregate, optimize, distribute, and slice the cellular network not only help us understand the inner-workings of 5G, but they are also necessary to reduce the entirety of the 5G cellular network to practice.
- A CORD POD connects downstream to a set of DUs (and associated RUs), and upstream to the rest of the Internet.
- Internally, it includes servers and switches arranged in a leaf-spine topology (the figure shows two leaves and two spine switches, but the design allows anywhere from a single switch to two leaf switches per rack and as many spine switches as necessary to provide sufficient east-to-west bandwidth).
- With respect to software, Figure 34 shows a combination of RAN (red) and Mobile Core (blue) components, plus modules that define the CORD platform.
- Stratum: A thin operating system that runs locally on each white-box switch.
- ONOS: A logically centralized SDN controller that hosts a collection of SDN control applications, each of which controls some aspect of the underlying network.
- Trellis control application managing a (possibly distributed) leaf-spine fabric
- P4Runtime: An SDN-ready interface for controlling forwarding behavior at runtime
- OpenConfig Models: Define a base for device configuration and management
- gNOI: A collection of microservices that enable switch specific operations, like certificate management, device testing, software upgrade, and networking troubleshooting
- A collection of multi-tenant clouds-including virtualized RAN resources alongside conventional compute, storage, and network resources-hosting both Telco and Over-the-Top (OTT) services and applications.
- Each individual cloud site is potentially owned by a different organization, and as a consequence, each site is able to host (and isolate) applications on behalf of many other people and organizations.
- Can run a 5G-enabled edge cloud as a centrally managed service
- Deploy an edge cloud in enterprises, configured with the user plane components of the RAN and Mobile Core (along with any edge services the enterprise wants to run locally), and then manage that edge deployment from the central cloud
- The value of this is to bring 5G wireless advantages into the enterprise
- Multi-Access: The access-edge will need to support multiple access technologies (e.g., WiFi, 5G, fiber), and allow users to seamlessly move between them.
- Heterogeneity: Research is needed to tailor edge services to take advantage of heterogeneous resources, as well as how to construct end-to-end applications from such a collection of building blocks (i.e., virtualization, hyper-localization, data reduction, near-real time, etc.)
- Distributed Services: Services will become inherently distributed, with some aspects running at the edge, some in the datacenter, and some running on-premises or in an end device (e,g., on-vehicle).
- Scalability: Access-edge could span thousands or tens of thousands of edge sites, and scaling up the ability to remotely orchestrate that many edge sites will be a qualitatively different challenge than managing one in a single data center.
- Customization: Monetizing the edge will require ability to offer differentiated and customized services to different classes of subscribers/applications, and a need to analyze control loops, define analytic-based controllers, and design dynamically adaptable mechanisms.
- This book is part of the Systems Approach Series, with an online version published at https://5G.systemsapproach.org
- To build a web-viewable version, you first need to download the source: https://github.com/SystemsApproach/5G.git
- The build process is stored in the Makefile and requires Python to be installed. The Makefile will create a virtualenv (venv-docs) which installs the documentation generation toolset.
- Larry Peterson is the Robert E. Kahn Professor of Computer Science, Emeritus at Princeton University, where he served as Chair from 2003-2009
- Lead the CORD and Aether access-edge cloud projects at the Open Networking Foundation (ONF), where he serves CTO
- Oguz Sunay is the Vice President for Research & Development at ONF
- Before joining ONF, Sunay was the CTO at Argela-USA
- He has also held prior industry positions at Nokia Research Center and Bell Laboratories
- Hold many U.S. and European patents on various aspects of 3G, 4G, and 5G
Clip source: Summary of - 5.1 Optimized Data Plane
- Disaggregating cellular network pays dividends
- Decoupling control and data code paths allows them to be optimized independently
- Modern white-box switches with programmable packet forwarding pipelines are a perfect example of specialized hardware we can exploit in the cellular network
- The RAN and Mobile Core user plane can be mapped directly onto an SDN-enabled data plane
- They can be further disaggregated into control/user plane pairs, denoted PGW-C, PGW, SGW, and PDCP-C
- To do this, reduce the User Plane component to the minimal Receive-Packet/Process-Pack/Send-Packacket processing core, and elevate all control-related aspects into the Control Plane component
- PHY (Physical) element of the RAN pipeline is split between the DU and RU partition
- Figure 25 shows the PDCP and Control Plane (Forwarding) element combined into one functional block
- Another consequence of disaggregating functionality is that once decoupled, different functions can be placed in different physical locations.
- For example, when splitting the RAN, placing some functions (e.g., the PDCP and RRC) in the Central Unit and others in Distributed Units allows for simpler hardware in remote locations, where there are often space, power, and cooling constraints.
- One of the most compelling value propositions of 5G is the ability to differentiate the level of service offered to different applications and customers
- The mechanism that supports this sort of differentiation is called network slicing
- It fundamentally comes down to scheduling
- A network slice is a realization of the QoS Class Identifier (QCI) discussed earlier
- 3GPP specifies a standard set of network slices, called Standardized Slice Type (SST) values
The goal of RAN slicing is to programmatically create virtual RAN nodes (base stations) that operate on the same hardware and share the spectrum resources according to a given policy for different applications, services, users, and so on.
- A single RAN Slicing control application is responsible for the macro-scheduling decision by allocating resources among a set of slices
- In addition to slicing the RAN, we also need to slice the Mobile Core.
- What makes slicing work is to also virtualize and replicate the entire service graph that implements the mobile Core.
- The similarity between slicing and the much-debated topic of network QoS might lead one to conclude that slicing won't take off, as QoS never seemed to provide quite enough benefit in large networks to justify its complexity.
- However, slicing is valuable precisely because it allows efficient partitioning of the relatively scarce resource that is cellular spectrum.
Clip source: Summary of - Chapter 6: Exemplar Implementation
CORD is a blueprint for building a 5G deployment from commodity hardware and a collection of open source software components
- The goal is an implementation, which by definition, forces us to make specific engineering choices
- This chapter describes one set of engineering choices that results in a running system, called CORD.
- A CORD POD includes three major subsystems: Platform, Profile, and CI/CD Toolchain
- Platform: The base layer common to all configurations includes Kubernetes as the container management system and ONOS as the SDN controller, with Stratum (an open source switch OS) loaded on to each switch.
- Profile: The deployment-specific collection of microservices and SDN control apps that have been selected to run on a particular POD.
- Stratum: A thin operating system that runs locally on each white-box switch
- ONOS: A logically centralized SDN controller
- Trellis: An ONOS-hosted SDN control application that implements a leaf-spine fabric
- P4Runtime: An SDN-ready interface for controlling forwarding behavior at runtime
- OpenConfig Models: Define a base for device configuration and management
- gNMI: Improves on the existing configuration interfaces by using a binary representation on the wire and enabling bi-directional streaming
Chapter 7: Cloudification of Access
Summary | Save 6 min
The previous chapters went step-by-step, first breaking 5G down into its elemental components and then showing how those components could be put back together using best practices in cloud design to build a fully functional, 3GPP-compliant 5G cellular network. We conclude by making some observations about this big picture.
- The cloud has fundamentally changed the way we compute, and more importantly, the pace of innovation.
- Disaggregation: Breaking vertically integrated systems into independent components with open interfaces
- Virtualization: Run multiple independent copies of those components on a common hardware platform
- Commoditization: Being able to elastically scale those virtual components across commodity hardware bricks as workload dictates
- The idea is to deploy an edge cloud in enterprises, configured with the user plane components of the RAN and Mobile Core, and then manage that edge deployment from the central cloud.
- This is similar to the multi-cloud configuration discussed in Section 5.2, except with the added feature of being able to manage multiple edge deployments from one central location.
- Multi-Access: The access-edge will need to support multiple access technologies (e.g., WiFi, 5G, fiber) and allow users to seamlessly move between them.
- Heterogeneity: Much of the edge functionality will be implemented by programming the forwarding pipeline in white-box switches, and more generally, will use other domain-specific processors, e.g. GPUs, TPUs
- Virtualization
- Integration: Research is needed to reconcile the assumptions made about by cloud native services and access-oriented Virtualized Network Functions (VNFs) about how to virtualize compute, storage, and networking resources, as well as how to construct end-to-end applications from such a collection of building blocks (i.e. Multi-Tenancy)
- Customization
- Monetizing the edge will require the ability to offer differentiated and customized services to different classes of subscribers/applications
- Data reduction
- Near-Real Time
- Supporting such an environment requires tight control loops, with control software running at the edge.