What is 5G Network Slicing?

If you have been reading as many 5G white papers as I have, you are already familiar with the vision that 5G will be more than a new Radio Access Technology (RAT), that is, 5G New Radio (5G NR), and additional spectrum. This will become true when the industry moves from NR Non-Standalone, which uses existing LTE radio and core network as an anchor for mobility management and coverage while adding a new 5G carrier, to NR Standalone (i.e., “full 5G” including a new 5G core). Besides NR, one of the other key 5G features is network slicing [3GPP-1]. The aim of network slicing is to transform the network from using a rather static one-network-fits-all approach to a dynamic model where multiple logical networks can be created on top of the same physical infrastructure to fulfill the diverse needs of different use cases such as enhanced Mobile BroadBand (eMBB), critical Internet of Things (IoT), and massive IoT.

A network slice is a logical network that includes a set of network functions, which may be Virtual Network Functions (VNFs) or Physical Network Functions (PNFs), and corresponding resources, such as compute, storage, and networking resources. It is sliced out from the physical network in order to provide specific capabilities and characteristics (e.g., customized connectivity with ultra-low latency, extreme reliability, and/or value-added services) that the application running within the slice requires [3GPP-2]. A slice could also be seen as a unique profile for an application, defined as a set of services within the network [WW], or as a network function chain built to support a given use case, traffic type or a customer [ETSI].

The instantiation of a network slice is called a Network Slice Instance (NSI). An NSI is a deployed set of network functions and it delivers network slice services according to a network slice blueprint, which is a description of the structure, configuration and the plans or work flows for how to instantiate and control the Network Slice Instance during its lifecycle [IETF-2, NGMN-2]. NSI is the end-to-end realization of network slicing. The NSI contains access, core, and transport network functions and information relevant to the interconnections between these network functions such as the topology of connections and individual link requirements like Quality of Service (QoS) attributes [3GPP-1].

A slice may serve a particular purpose or a specific category of services (e.g., a specific use case or a specific traffic type) or even individual customers, in which case it may be created on-demand following a Network-as-a-Service (NaaS) approach [3GPP-1].

Each network slice exists within a Software Defined Networking (SDN) overlay [BRO]. Within the slice, a collection of network functions is chained together according to the requirements of the service using the slice [WW, 5GA]. Each slice sharing the same underlying physical infrastructure is a logically separated and isolated system that can be designed with different network architecture, engineering mechanism and network provisioning. When appropriate, slices can share functional components.

Examples of Network Slices

Some examples of network slices and use cases using them include [NGMN, NM, KCF]:

• A 5G slice for an Ultra High Definition (UHD) or Virtual Reality (VR) video streaming service could include for example a virtualized BBU (BaseBand Unit) VNF, a 5G core network User Plane (UP) and Control Plane (CP) VNFs, a cache server running as a VNF in the edge cloud, and a Mobile Video Optimization (MVO) server VNF in a central cloud.
• A 5G slice for typical eMBB smartphone use (e.g., voice or video calls) could include a virtualized BBU in the edge cloud. The core cloud could include a 5G core UP and CP VNFs (e.g., access management, session management, full mobility management, and charging), and IP Multimedia Subsystem (IMS) and TCP optimization VNFs running in a central cloud
• A 5G slice supporting a critical IoT (e.g., self-driving car) use case is likely to require a high level of security, high level of mobility, extreme reliability, and extremely low latency. For such a slice, all the needed network functions (e.g., 5G core UP and a V2X (Vehicle-to-Everything) server VNFs) and the control software for the self-driving car can be instantiated in a node located at the edge of the network (i.e., in the edge cloud) to meet the very strict latency requirements.
• For a network slice supporting a massive IoT use case (e.g., stationary weather sensors infrequently sending small amounts of data), could include a virtualized BBU in the edge cloud. The core cloud could include some basic light-weight 5G core control plane functions (e.g., access management and session management) configured without mobility management features together with contention-based resources for access, and an IoT server VNF.
• In addition to the four slices above, there could a generic slice that provides best-effort connectivity for unknown use cases and traffic types

Some of the above-mentioned slices are illustrated in Figure 1 below. More examples of network slicing use cases are available for example in [IETF-6].

Figure 1 – Examples of network slices

As we can observe, all of the use cases above require different types of features and network characteristics when it comes to for example to mobility, charging, security, policy control, latency, reliability, bandwidth, and so forth. Not all use cases will require all of the features that the network is capable of providing. Furthermore, in some cases, the applications will be brought closer to the users to the edge cloud and is some cases the RAN and/or the transport network will require a specific configuration.

Network Slicing Related Technologies 

Network slicing leverages multiple different technologies and concepts, including [NOK-1, HW]:

• End-to-end management and orchestration – an E2E management and orchestration entity configures the infrastructure layer (which contains all physical resources of the network, including compute, storage and networking), business enablement layer (which includes the network functions), and business application layer (which consists of applications or services of the network operator or tenant) according to the needs of a the application using the slice and supervises them during runtime [5GN]. This includes defining the network slices, chaining together the required VNFs and PNFs and mapping them on the infrastructure equipment. It also includes resource management, scaling the capacity of network functions and managing their geographic distribution. The E2E management and orchestration entity will build on technologies such as NFV, SDN, and SON (Self-Organizing Network). The management and orchestration entity communicates with the OSS/BSS of the network service provider to among other things report status and receive requirements [5GPPP].
• Distributed cloud infrastructure, which refers to virtual infrastructure distributed across a mobile network. In the most ambitious visions, nearly any node in the network will be capable of hosting distributed applications and VNFs [ER-5]. This brings applications closer to (or perhaps even into) the RAN and enables optimizing network characteristics like latency and bandwidth.
• Service chaining – to support diverse services, the E2E management and orchestration system can orchestrate multiple network and service functions by chaining them together on demand in a specific order to create control plane and data plane graphs [5GPPP]. 
• Cloud-native design, including for example microservices, containers, and a Service Oriented Architecture (SOA) in which libraries of network functions can be requested from a VNF catalog and composed into end-to-end service chains on demand [HW]
• Network Function Virtualization (NFV) – NFV installs network function software (VNFs), such as MME (Mobility Management Entity), PDN (Public Data Network) Gateway, SGW (Serving Gateway) and PCRF (Policy and Charging Rules Function) in the core network and BBU in the RAN, into Virtual Machines (VMs; or perhaps into containers in a more cloud-native system) deployed on virtualized COTS (Common Off-The-Shelf) servers instead of onto their dedicated network equipment individually [KCR]
• Software-Defined Networking (SDN) – SDN provisions the connectivity among VMs or containers located in edge and core clouds [KCR].  An SDN controller configures the service chain of network functions (VNFs) as a logical overlay among them [5GPPP].
• Analytics and machine learning are required to make the network slicing process highly automated [NOK]. High levels of automation will be needed since running multiple slices on top of the same physical infrastructure adds complexity to network operations and optimization. Analytics and machine learning will be used to enhance end-to-end management and orchestration (see the first bullet).

End-to-End Network Slicing

A network slice can span all the domains of the network, including [5GA, NGMN, 3GPP-2]:

• RAN slicing: for example, a dedicated radio configuration (RAT settings) or specific RAT.
• Transport network slicing: for example, a specific configuration of the transport network to support flexible placement of network functions. A network slice includes also the transport resources between the network functions.
• Core network slicing: here the slice includes the control plane and user plane network functions and their resources, such as compute, storage, and network resources. In the core network, NFV and SDN virtualize the network elements and functions in each slice to meet the requirements of the user of the slice
• Edge cloud and data centers [IETF-3]: slicing covers also applications or VNFs (e.g., a V2X application) running on cloud nodes in an edge cloud (where RAN works as an edge cloud [KCR]) or a central data center
• Specific configuration of a 5G device and any dedicated resources that an end-user device allocates to a specific NSI [IETF-2]

More information about RAN, core network and transport network slicing is available in the sections below.

The details of how network slicing will work are still being nailed down. However, it is likely that slice selection will be controlled by the network [HW]. The UE will be able to provide network slice selection assistance information based on policy. The UE may belong to more than one slice on the same RAN and core network.

RAN Slicing

In the RAN, slicing can be built on physical radio resources or on logical resources abstracted from physical radio resources [5GA]. RAN slicing could be implemented by mapping a slice identifier to a set of configuration rules applied to the RAN control plane (i.e., RRC, Radio Resource Control in the case of LTE) and user plane functions, that is PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control), MAC (Medium Access Control) in the case of LTE. Some network functions, such as mobility management, can be common to several slices. There will also be common control functions that coordinate RAN resource usage among the slices.

Radio slices in the RAN may share radio resources (time, frequency, space) and the corresponding communication hardware such as digital baseband processing components or analog radio components [5GA]. The sharing could be done in a dynamic or static manner depending on the network slice’s configuration rules. In case of dynamic sharing, each slice obtains resources based on its demand and priority using either scheduling (the slice requests resources from a central scheduler, which allocates them for example based on the overall traffic load or the priority of the slice) or contention. In the case of static sharing, a slice is pre-configured to operate in a dedicated resource throughout its operation time. Static sharing enables guaranteed resource allocation to the slice, whereas dynamic resource sharing allows overall resource usage optimization.

Slice-specific configuration rules for the control plane functions tailor the RAN control plane functions for each slice. This is because not all slices will require all control plane functions. In the RAN Layer 2 (L2) user plane, each slice may have a configured user plane protocol stack. For example, a slice supporting different QoS classes could be configured to use separate packet segmentation and scheduling layers similar to the RLC (Radio Link Control) and MAC (Medium Access) layers in LTE.

There is also a need for network slice specific admission control so that the system can meet the initial access requirements of various network slices [5GA]. For example, a network slice for critical IoT must get guaranteed low-latency access - consider for instance a slice supporting a remote surgery use case.

The end-to-end network slice also includes the virtualized BaseBand Unit (BBU) - the waveform samples carried in the fronthaul network are processed by a VNF that implements the BBU functions instead of a physical BBU [5GPPP].

How much of the baseband processing is virtualized as VNFs and centralized depends on front-haul availability [NOK] – in some cases, such as with extreme 5G data rates and massive beamforming, CPRI (Common Public Radio Interface, i.e., transmission links between central BBUs and distributed RRHs) fronthaul capacity requirements may be too high and prevent fully centralized baseband processing [ER-6]. Thus, the radio architecture needs to be flexible to cope with different fronthaul deployments. The RAN control plane, is more straightforward to centralize since it does not have extreme bitrate requirements [ER-6]. To enable massive beamforming, the physical layer (PHY) could be distributed closer to the antenna while the upper layers in the stack, that is, MAC, RLC, PDCP, and PHY (physical layer), could be centralized. In fully centralized based deployment, all baseband processing (RAN L1, L2, and L3 protocol layers) is located in a central data center.

Core Network Slicing

The 5G core network (a.k.a., Next-Generation Core, NGC) will be a key element for network slicing since it manages sessions, QoS, security, policy, and so forth [HW]. Network slicing allows core networks to be built in a flexible way [ER-2], tailored to the needs of the application using the slice. SDN and NFV allow traditional network architectures to be broken down into customizable elements (VNFs) that can be chained together programmatically using Service Function Chaining (SFC; a.k.a., service chaining) to provide the required level of connectivity and network functionality. An SDN controller configures service chaining to build a network slice for each user or service [ER-4]. SFC makes it possible to dynamically configure user plane traffic to be routed through a chain of network components which provide value added services [SS].

In LTE, service function chains live in the SGi-LAN [IETF-1], which is the part of the LTE network between the Evolved Packet Core (EPC) and the PDN (Packet Data Network, e.g., Internet) gateway [Int-1]. It is where service providers deploy IP functions such as firewalls, NATs (Network Address Translators), policy and charging enforcement functions, traffic detection functions, CDN (Content Delivery Network) functions, video transparent caching functions, and video optimization functions. In coordination with SDN and NFV, service chaining in the SGi-LAN can be used to optimally steer traffic through selected SGi-LAN network functions.

5G networks are expected to remove the separation between the network service functions that are traditionally placed in the SGi-LAN and the connectivity service, that is, the core network and RAN [NOK]. This allows service chaining to take advantage of edge clouds. Thus, virtualized SGi-LAN functions can be chained together with other VNFs (including the 5G core network VNFs) into a network slice and placed wherever appropriate, including router-based compute blades, COTS x86 servers deployed at the edge, or in central data centers [AF]. The placement decisions are made by a central management and orchestration system.

When it comes to interconnection between core network control plane functions, in addition to traditional point-to-point interfaces (which is the traditional 3GPP architecture that defines functions and interfaces between them), for the core network control plane, 5G is expected to also use a service oriented (cloud-native) model in which components query a Network Function Repository Function (NRF) to discover and communicate with each other [3GPP-3, HW]. The NRF allows libraries of functions to be requested from a VNF catalog and composed into service chains on demand. Using such a service-oriented model, network functions on the control plane can access each other’s services through APIs (Application Programming Interfaces) 3GPP-2].

A 5G device will associate an application with one out of multiple parallel PDU (Packet Data Unit [5GA-2]) sessions, each PDU session corresponding to one core network slice and one RAN slice [IETF-5]. A PDU session is a 5G concept for an association between the device and a data network (e.g., IP or Ethernet). Part of the core network control plane may be common to several slices. One of common control plane functions is the Slice Selection Function (SSF), which is in charge of selecting a core network slice instance. The SSF not specific to any particular network slice [3GPP-3]. Other common control plane network functions can include the Access and Mobility Management Function (AMF), Authentication Function, and NAS (Non-Access Stratum) proxy function. Different slices may also have dedicated core network control plane functions such as the Session Management Function (SMF) which manages PDU sessions. User plane functions are dedicated to each slice.

Transport Network Slicing

In addition to the RAN and core network, also the transport network will play a key role in 5G in enabling flexibility and the ability to address the requirements of the broad range of use cases that 5G will need to support [5GPPP]. To make the transport network programmable and capable of supporting network slicing, SDN and NFV need to be used to separate the control and data planes. This will allow the transport network to dynamically interconnect distributed 5G RAN and core network functions hosted on distributed cloud infrastructure (i.e., the “network cloud”). In general, the 5G transport network will consist of integrated optical and wireless (e.g., mmWave transmission of fronthaul and backhaul) network infrastructure. In 5G transport networks, the fronthaul and backhaul will become one unified IP network known as the 5G Xhaul [EOC].

Programmability will allow the transport network to support the requirements that network slicing brings, including the support for diverse use cases, network sharing, isolation, Service Level Agreement (SLA) fulfillment, short Time-To-Market (TTM), efficient scaling, interconnection of distributed network functions over links that fulfill the required performance levels for bandwidth, delay and availability, etc. SDN-based resource and service orchestration will orchestrate not only the RAN, core, and cloud, but also the transport network, and a 5G network slice will also include the transport layer [ER-1].

Introducing a fully centralized control plane (i.e., full SDN) might be easier for optical transport than packet networks since in legacy optical transport networks, most control functions are already separated from the data plane nodes [ER-1]. In contrast, in legacy packet-switched transport nodes, the two planes are often tightly coupled.

As an example of transport network slicing, Deutsche Telekom (DT) has demonstrated bandwidth based transport network slicing (i.e., slicing based on the bandwidth requirements of applications [Wang]). DT’s transport network consists of T-SDN (Transport SDN) controllers and underlying DWDM (Dense Wavelength Division Multiplexing) nodes. The controllers generate a series of specific data forwarding paths based on slice topology and service requirements [TEL].

Network slicing needs to be configured both for the backhaul transport network (between the RAN/edge cloud and the core cloud) and for the fronthaul transport network (between the edge cloud and a RRH at the cell site) [KCR].

Between the edge and core clouds (i.e., backhaul), inter-VM networking is set up with IP/MPLS-SDN (Internet Protocol / Multi-Protocol Label Switching SDN) and T-SDN [KCR]. IP/MPLS networks, as one of the widely deployed mobile transport networks, need to provide the functionality and capability required by network slicing [IETF-4]. The hypervisor of a virtualized server in the core cloud might run a vRouter/vSwitch. The SDN controller does provisioning of the virtualized server Datacenter (DC) Gateway (GW) routers (i.e., Provider Edge (PE) router of MPLS L3 (Layer 3) VPN (Virtual Private Network) installed in the cloud DC) to create SDN tunnels (i.e., MPLS GRE (General Routing Encapsulation), VXLAN (Virtual Extensible Local Area Network)) between each VM in the core cloud (e.g., 5G IoT core) and the DC GW router. The SDN controller then performs mapping between these tunnels and MPLS L3 VPNs (such as an IoT VPN). The process is the same in the edge cloud, creating an IoT slice connecting from the edge cloud to the IP/MPLS backbone, and all the way to core cloud.

Also the fronthaul between the edge cloud and a 5G NR RRH needs to be sliced [KCR]. It is envisioned that the 5G Cloud RAN will use packet-based T-SDN as the fronthaul network to transport both control plane and data plane traffic between RRHs and BBUs [ODL-1]. RRH slicing, which is a new type of RAN sharing, could segment a physical RRH into multiple slices. It could dynamically create a virtual RRH (vRRH) instance using a single or multiple RRH slices, and then associate the vRRH to the BBU requesting it. This means that a novel RRH infrastructure is needed to provide virtualization and programmability of RRH networks for Cloud RAN.

The OpenDaylight open source SDN controller project is working on an OCP (Open Radio Equipment Interface Control & Management Protocol) plugin [ODL-2]. OCP is an ETSI standard protocol for control and management of RRH equipment. The OpenDaylight OCP project addresses the need for a southbound plugin that allows applications and controller services to interact with RRHs using OCP. The addition of the OCP plugin to OpenDaylight will make it possible to build an RRH controller on top of OpenDaylight to centrally manage deployed RRHs and integrate the RRH controller with T-SDN, achieving joint RRH and fronthaul network provisioning in Cloud RAN.

References

[3GPP-1] 3GPP TR 28.801 V1.0.0 (2017-03), Technical Report, 3rd Generation Partnership Project;
Technical Specification Group Services and System Aspects; Telecommunication management; Study on management and orchestration of network slicing for next generation network  (Release 14), http://www.3gpp.org/ftp//Specs/archive/28_series/28.801/28801-100.zip

[3GPP-2] 3GPP TS 23.501 V0.3.0 (2017-02), Technical Specification, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System Architecture for the 5G System; Stage 2(Release 15), http://www.3gpp.org/ftp//Specs/archive/23_series/23.501/23501-030.zip

[3GPP-3] 3GPP TR 23.799, Technical Report, 3rd Generation Partnership Project; Study on Architecture for Next Generation System, Release 14, https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3008

[5GA] Network Slicing for 5G Networks & Services, http://www.5gamericas.org/files/3214/7975/0104/5G_Americas_Network_Slicing_11.21_Final.pdf

[5GA-2] Wireless Technology Evolution towards 5G: 3GPP Release 13 to Release 15 and beyond, http://www.5gamericas.org/files/6814/8718/2308/3GPP_Rel_13_15_Final_to_Upload_2.14.17_AB.pdf

[5GN] 5G NORMA Deliverable D3.1, Functional Network Architecture and Security Requirements,
https://5gnorma.5g-ppp.eu/wp-content/uploads/2016/11/5g_norma_d3-1.pdf

[5GPPP] 5G PPP Architecture Working Group, View on 5G Architecture, https://5g-ppp.eu/wp-content/uploads/2014/02/5G-PPP-5G-Architecture-WP-For-public-consultation.pdf

[AF] Designing 5G-Ready Mobile Core Networks, https://www.affirmednetworks.com/wp-content/themes/renden/pdf/5G_Whitepaper_Heavy_Reading.pdf

[BRO] The Path to 5G with Programmable Mobility Management, https://www.brocade.com/content/dam/common/documents/content-types/whitepaper/brocade-path-to-5g-with-programmable-mobility-management-wp.pdf

[EOC] What is 5G Xhaul, http://edge-of-cloud.blogspot.fi/2017/03/what-is-5g-xhaul.html

[ER-1] Flexibility in 5G Transport Networks: The Key to Meeting the Demand for Connectivity, https://www.ericsson.com/res/thecompany/docs/publications/ericsson_review/2015/etr-5g-transport-networks.pdf

[ER-2] A Vision of the 5G Core: Flexibility for New Business Opportunities, https://www.ericsson.com/res/thecompany/docs/publications/ericsson_review/2016/etr-5G-core-vision.pdf

[ER-3] X-haul, fronthaul and backhaul network research, https://www.ericsson.com/research-blog/5g/x-haul-fronthaul-and-backhaul-network-research/

[ER-4] Why 5G Network Slices? https://www.ericsson.com/spotlight/cloud/blog/2015/02/17/5g-network-slices/

[ER-5] The Programmable Network Cloud, https://www.ericsson.com/res/docs/whitepapers/wp-the-programmable-network-cloud.pdf

[ER-6] Cloud RAN, https://www.ericsson.com/res/docs/whitepapers/wp-cloud-ran.pdf

[ETSI] Next Generation Protocols (NGP); Scenarios Definitions, http://www.etsi.org/deliver/etsi_gs/NGP/001_099/001/01.01.01_60/gs_NGP001v010101p.pdf

[HW] Service-Oriented 5G Core Networks, http://www-file.huawei.com/~/media/CORPORATE/PDF/white%20paper/Heavy%20Reading%20Whitepaper-%20Service-Oriented%205G%20Core%20Networks.pdf

[IETF-1] Service Function Chaining Use Cases in Mobile Networks, https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-07

[IETF-2] Network Slicing Architecture, draft-geng-netslices-architecture-00, https://tools.ietf.org/html/draft-geng-netslices-architecture-00

[IETF-3] Network Slicing - Introductory Document and Revised Problem Statement, draft-gdmb-netslices-intro-and-ps-02, https://tools.ietf.org/html/draft-gdmb-netslices-intro-and-ps-02

[IETF-4] Problem Statement of Network Slicing in IP/MPLS Networks, draft-dong-network-slicing-problem-statement-00, https://tools.ietf.org/html/draft-dong-network-slicing-problem-statement-00

[IETF-5] Network Slicing - 3GPP Use Case, draft-defoy-netslices-3gpp-network-slicing-00, https://tools.ietf.org/html/draft-defoy-netslices-3gpp-network-slicing-00

[IETF-6] Network Slicing Use Cases: Network Customization for Different Services, draft-qin-netslices-use-cases-00, https://tools.ietf.org/html/draft-qin-netslices-use-cases-00

[Int-1] Etisalat and Intel Virtualizing the Internet Gateway Gi-LAN for Service Flexibiity, https://builders.intel.com/docs/networkbuilders/Etisalat-and-Intel-virtualizing-the-internet-gateway-Gi-LAN-for-service-flexibility.pdf

[KCR] Korea Communication Review Q4 2015, http://5g.itrc.ac.ir/sites/default/files/korea_communication_review.pdf

[NGMN] NGMN 5G White Paper, https://www.ngmn.org/uploads/media/NGMN_5G_White_Paper_V1_0.pdf

[NGMN-2] NGMN 5G P1 Requirements & Architecture Work Stream End-to-End Architecture Description of Network Slicing Concept by NGMN Alliance, https://www.ngmn.org/uploads/media/160113_Network_Slicing_v1_0.pdf

[NM] E2E Network Slicing - Key 5G technology : What is it? Why do we need it? How do we implement it? http://www.netmanias.com/en/post/blog/8325/5g-iot-network-slicing-sdn-nfv/e2e-network-slicing-key-5g-technology-what-is-it-why-do-we-need-it-how-do-we-implement-it

[NOK] 5G - a System of Systems for a programmable multi-service architecture, http://resources.alcatel-lucent.com/asset/200012

[ODL-1] Project Proposals: OCP Plugin, https://wiki.opendaylight.org/view/Project_Proposals:OCP_Plugin

[ODL-2] OCP Plugin: Main, https://wiki.opendaylight.org/view/OCP_Plugin:Main

[SS] The Road from EPC to 5G, https://www.slideshare.net/AlbertoDiez4/mobile-plots-from-epc-to-5g

[TEL] Deutsche Telekom and Huawei demonstrate world’s first 5G E2E autonomous network slicing, https://www.telekom.com/en/media/media-information/archive/5g-autonomous-network-slicing-demonstrated-444778

[TP] LTE Overview, https://www.tutorialspoint.com/lte/lte_quick_guide.htm

[Wang] An Optimal Slicing Strategy for SDN based Smart Home Network, http://ir.siat.ac.cn:8080/bitstream/172644/6290/1/%E5%8D%97%E6%B2%99%E6%89%80-%E6%99%BA%E6%8E%A72014008.pdf

[WW] Elements of a 5G Core Network, https://www.wirelessweek.com/article/2016/10/elements-5g-core-network

How Does a Jitter Buffer Work?

In an earlier blog post, I wrote about the components of motion-to-photon latency in Virtual Reality (VR) systems [EOC]. In most video streaming applications, the dominant latency contributor is buffering at the receiving (decoder) side. This blog post will take a closer look at buffering, focusing on jitter buffers.

In IP networks, jitter refers to the variation in latency on a packet flow between two systems [TT]. Jitter causes some packets to take longer to travel from the sender to the receiver. Jitter results from network congestion, timing drift and route changes. Due to jitter, packets may arrive at the destination late, they may arrive out of order, or may get completely lost if for example buffer overflows occur [Vocal]. In the case of VoIP and video conferencing, jitter can cause audio and video artifacts.

When it comes to jitter, packet loss and latency, QoS requirements and recommendations for VoIP are as follows [Cisco-1]:

• Average one-way jitter should be targeted at less than 30ms. Research has shown that voice quality degrades significantly when jitter consistently exceeds 30ms.
• Maximum packet loss is 1%
• One-way latency (a.k.a., the mouth-to-ear latency) should be no more than 150ms

The ability to compensate for network jitter is one of the key factors impacting the overall quality of VoIP and video conferencing [Vocal]. This compensation is achieved using a jitter buffer. The jitter buffer adds directly to the end-to-end (mouth-to-ear) delay. As an example, a static jitter buffer of 100ms reduces the end-to-end delay budget by 100ms. One the one hand, setting too large a size for the jitter buffer may require the network to support a tighter delay target than may be necessary [Cisco-1]. On the other hand, a jitter buffer too small to accommodate the network jitter can result in buffer underflows (i.e., the buffer is empty when the codec needs to play out a sample) or overflows (i.e. the buffer becomes full and an arriving packet cannot be queued in it). If the jitter is so large that packets are received out of the range of the buffer, the out-of-range packets are discarded and dropouts (clipping) are heard in the audio.

As an example, let’s assume a static jitter buffer set to 100ms. This means that the first voice sample that is received when the jitter buffer is initially empty is held in the buffer for 100ms before it is sent to the codec for playout [Giralt]. A subsequent packet can be delayed as much as 100ms with respect to the first packet without loss of voice continuity. However, if a subsequent packet is delayed more than 100ms, there will be a dropout in the audio (unless packet loss concealment is performed – more about that below). If packets are received on average at a lower rate than the fixed interval at which they are fed to the codec, the codec will eventually starve (i.e., a buffer underflow occurs).  When packets arrive at a sufficient average rate, the jitter buffer will always have enough packets to play 100ms of audio before running out of packets. Thus, the variable delay (i.e., jitter) in the network can be up to 100ms without noticeable voice quality degradation.

As another example, if we have a network with a low average delay of 20ms, average jitter of 8ms, and an occasional maximum jitter of 60ms, the size of the jitter buffer should be at least 60ms (or perhaps slightly more) to compensate for the network jitter, and the overall mouth-to-ear delay would be 80ms [Giralt, Kularatna].

As a final example, Linksys devices use a minimum adaptive jitter buffer size of 30ms (or 10ms + current RTP frame size, whichever is larger) [Cisco-3].

A rule of thumb is that if the jitter level is over 100ms, increasing the size of the jitter buffer to avoid packet discards may introduce too large a delay and cause conversational problems (consider the above-mentioned recommend max mouth-to-ear latency of 150ms) [VTS-1]. According to [VTS-2], a typical jitter buffer configuration is 30-50ms in size. In the case of an adaptive jitter buffer, the maximum size may be set to 100-200ms.

Budgeting for jitter accurately (i.e., choosing an appropriate size for the jitter buffer) is difficult due to jitter’s dependency on the traffic mix, traffic burstiness, link utilization, and the nonadditive property of jitter (which means that jitter across a network path does not equal to the sum of jitters across consecutive parts of the path) [Joseph]. The nonadditive property of jitter should not be confused with the impact of several jitter buffers between the sender and the received on the mouth-to-ear latency – if there are for instance two cascaded mixers [RFC 4353] each having a static jitter buffer of 50ms, the total latency introduced by the jitter buffers is 100ms.

Above, static jitter buffers were covered. Many systems use adaptive jitter buffers that dynamically tune the size of the jitter buffer to the lowest acceptable value [Cisco-1] by continuously estimating the network delay and adjusting the playout delay at the beginning of each talkspurt [SS]. Adaptive jitter buffers [Cisco-1]:

• Increase the size of the buffer to the current measured jitter value following a buffer overflow
• Slowly decrease the buffer size when the measured jitter is less than the current buffer size
• Use Packet Loss Concealment (PLC) to incorporate the loss of a packet on a buffer underflow. PLC is a technique used to mask the effects of lost or discarded VoIP packets. One simple method is to replay the latest received sample with increasing attenuation at each repeat. This can conceal the loss of up to 20ms of samples. More sophisticated PLC techniques can conceal up to 30-40ms of loss with tolerable quality.

An adaptive jitter buffer performs the playout adjustment during the silent periods between talkspurts [SS]. The adjustment is done on the first packet of the talkspurt. All packets in the same spurt are scheduled to play out at fixed intervals following the playout of the first packet.

The level at which jitter becomes noticeable depends on the media type. As an example, tolerable video jitter is larger than tolerable audio jitter [Jeffay]. This means that in video conferencing, the buffering delay for video is determined by the size of the audio jitter buffer (in video conferencing, the audio and video need to be synchronized to achieve lip sync). In the audio-video synchronization process, adaptive playout algorithms are performed first, and the video frames are played out on the playout times of their corresponding audio packets (the correspondence is determined by the timestamps of the video and audio packets) [SS]. To enable this, the video frames are stored in a video playout buffer and each frame is delayed until the corresponding audio packets are played out.

References

[Cisco-1] Quality of Service Design Overview, http://www.ciscopress.com/articles/article.asp?p=357102

[Cisco-2] Understanding Jitter in Packet Voice Networks (Cisco IOS Platforms), http://www.cisco.com/c/en/us/support/docs/voice/voice-quality/18902-jitter-packet-voice.html

[Cisco-3] What is the jitter buffer value in ms of Linksys devices? https://supportforums.cisco.com/discussion/11128491/what-jitter-buffer-value-ms-linksys-devices

[EOC] The Components of Motion-to-Photon Latency in Virtual Reality Systems, http://edge-of-cloud.blogspot.fi/2016/11/the-components-of-motion-to-photon.html

[Giralt] Giralt, Hallmark and Smith: Troubleshooting Cisco IP Telephony

[Jeffay] Jeffay and Zhang: Readings in Multimedia Computing and Networking

[Joseph] V. Joseph and B. Chapman: Deploying QoS for Cisco IP and Next Generation Networks: The Definitive Guide

[Kularatna] N. Kularatna: Essentials of Modern Telecommunications Systems

[RFC 4353] A Framework for Conferencing with the Session Initiation Protocol (SIP), https://tools.ietf.org/html/rfc4353

[SS] Adaptive Playout Buffering for Audio/Video Transmission over the Internet, https://pdfs.semanticscholar.org/acc0/c0b01e6a49c619c550fee77dea7f1778c518.pdf

[TT] Jitter, http://searchunifiedcommunications.techtarget.com/definition/jitter

[Vocal] Jitter Buffer for Voice over IP, https://www.vocal.com/voip/jitter-buffer-for-voice-over-ip/

[VTS-1] Problem: Jitter, http://www.voiptroubleshooter.com/problems/jitter.html

[VTS-2] Problem: Jitter buffer, http://www.voiptroubleshooter.com/problems/jitterbuffer.html

Understanding 5G and LTE - SGi-LAN

SGi-LAN (SGi Local Area Network) is network infrastructure connected to a 3GPP (Third Generation Partnership Project) LTE (Long-Term Evolution) network over the SGi or Gi reference point (i.e., interface) that provides different value-added IP-based services to user data as it flows through the network [3GPP]. These value-added services may include, among others [3GPP, Cisco, Intel-1]:

• NAT (Network Address Translation)
• Anti-malware
• Parental control
• DDoS (Distributed Denial of Service) protection
• Firewall
• Policy and charging enforcement
• Traffic detection (PCEF/TDF; Policy and Charging Enforcement Function / Traffic Detection Function)
• Content Delivery Network (CDN) caches
• Video transparent caching and optimization
• TCP optimization (e.g., to prepare the traffic for the Radio Access Network)
• Shaping traffic with Deep Packet Inspection (DPI)
• HTTP header enrichment to support partner services
• Providing analytics information
• Differentiated charging

In the future, SGi-LAN will also need to address the growing use of encrypted traffic. It might also include different forms of proxies and interworking functions for IoT [Cisco].

In an LTE network, SGi-LAN is positioned between the Evolved Packet Core (EPC; the LTE core network) and a PDN (Packet Data Network) Gateway such as an Internet or IMS (IP Multimedia Subsystem) gateway. A typical SGi-LAN supports several million subscribers [Intel-1].

SGi-LAN is the home of Service Function Chains (SFC), which are not standardized by 3GPP [IETF]. Traditional mobile deployments of SGi-LAN services simply chain all the functions together in a serial and static manner [HPE]. The limitations of this approach include that (1) each function has to process all the traffic, (2) introducing new functions or upgrading existing ones takes a lot of time and effort, (3) a failure of a single function may interrupt the overall service for all subscribers, and (4) the introduction of new services is slowed down.

Service Function Chaining (SFC) makes it possible to dynamically configure user plane traffic to be routed through a chain of network components which provide value-added services [SS]. As an example, traffic of a certain customer may be passed through a protocol optimization component (e.g., for video) or a security function such as parental control. SFC, when combined with SDN (Software-Defined Networking) and NFV (Network Functions Virtualization), can be used to remove the limitations mentioned in the previous paragraph and enable optimal use of data center resources, scalability to cope with ever-increasing traffic, and optimal steering of traffic through SGi-LAN network functions [Intel-2]. In fact, virtualization of the SGI-LAN is often a first step for mobile operators towards network virtualization [HPE]. It allows the virtualized SGi-LAN functions to be run as VNFs (Virtualized Network Functions) on standard x86 server hardware in the operator’s cloud infrastructure.

3GPP is defining the integration of 3GPP policy standards with external policy standards, including policies for SDN controllers. A new interface (St) has been defined between the PCRF (Policy and Charging Rules Function) and a new Service Chain Traffic Controller Function (SCTCF) [Intel-2]. The St interface allows the PCRF to interface to the SFC controller functions in order to provide traffic description filters that enable more coordinated and comprehensive implementation of service chains in SGi-LAN.

But what is the role of the SGi-LAN in 5G networks? According to some visions, in 5G networks, the integration of SGi-LAN network functions will be seamless, and the traditional separation between the network functions placed in the SGi-LAN and other parts of the network will be removed [NOK], allowing the SGi-LAN functions to be either integrated with the basic connectivity and policy enforcement functions, or still be deployed independently in the SGi-LAN. Among other things, this will allow service function chaining to take advantage of edge clouds - virtualized SGi-LAN functions can be placed where needed [AF]. As an example, SGi-LAN functions could be placed on router-based compute blades, on COTS (Common Off-The-Shelf) x86 servers on an edge node (e.g, one could place a CDN cache on an edge node to move traffic closer to the edge), or in a central data center. The placement decision is made by a central orchestration system, which can steer traffic into service chains for example on a per application, subscriber, bearer or device basis, or based on some combination of them.

Finally, SGi-LAN may also be referred to as (S)Gi-LAN, Gi-LAN, GiLAN, vGiLAN (virtualized GiLAN), SGiLAN, Gi LAN or SGi LAN.

References

[3GPP] 3GPP TS 23.203 V14.3.0 (2017-03), Technical Specification, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects;
Policy and charging control architecture (Release 14)
https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=810

[AF] Designing 5G-Ready Mobile Core Networks, https://www.affirmednetworks.com/wp-content/themes/renden/pdf/5G_Whitepaper_Heavy_Reading.pdf

[Cisco] The Cisco 5G Strategy Series: Packet Core, Transport, and Identity Management, http://www.cisco.com/c/dam/en/us/solutions/collateral/service-provider/ultra-services-platform/5g-strategy-series.pdf

[HPE] Virtualization of Gi-LAN Functions, https://www.hpe.com/h20195/v2/GetPDF.aspx/4AA6-3417ENN.pdf

[IETF] Service Function Chaining Use Cases in Mobile Networks, draft-ietf-sfc-use-case-mobility-07, https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-07

[Intel-1] Etisalat and Intel – Virtualizing the Internet Gateway Gi-LAN for Flexibility, https://builders.intel.com/docs/networkbuilders/Etisalat-and-Intel-virtualizing-the-internet-gateway-Gi-LAN-for-service-flexibility.pdf

[Intel-2] Gi-LAN and Dynamic Service Function Chaining for Communications Service Providers, https://builders.intel.com/docs/networkbuilders/Gi-LAN-and-dynamic-service-function-chaining-for-communication-service-providers-ra.pdf

[NOK] 5G - a System of Systems for a programmable multi-service  architecture, http://resources.alcatel-lucent.com/asset/200012

[SS] The Road from EPC to 5G, https://www.slideshare.net/AlbertoDiez4/mobile-plots-from-epc-to-5g a

What Is 5G Xhaul?

To put xhaul (also known as crosshaul or X-haul) into a context, let's start from the domains of a mobile network. These include [5GPPP-1]:

• Radio Access Network (RAN) domain
• Transport network domain
• Core Network (CN) domain
• Other domains, like the OSS/BSS domain for supporting telecommunication services and application domain for providing services [NM]

Xhaul is a concept related to the second domain on the list above, that is, the 5G transport network. The transport network consists of the backhaul of radio base stations and fronthaul of remote radio units (a.k.a., Remote Radio Heads, RRHs). In the case of LTE, fronthaul refers to the high-bandwidth (optical [EX]) transport links that connect the RRHs to a BaseBand Unit (BBU) pool in the LTE C-RAN (Centralized Radio Access Network) architecture. Backhaul is the IP (IP/MPLS [EX]) network from the centralized BBUs to the LTE Evolved Packet Core (EPC). Finally, xhaul could be defined as a common flexible transport solution for future 5G networks, which integrates the fronthaul and backhaul networks with all their wired and wireless technologies into a common packet-based network that is under SDN (Software Defined Networking) based and NFV (Network Functions Virtualization) enabled common control [ER].

This SDN-controlled integrated backhaul and fronthaul transport network (i.e., xhaul) aims to enable a flexible and software-defined reconfiguration of all network functions in a multi-tenant and service-oriented manner [5GPPP-2]. The xhaul transport network is envisioned to consist of high-capacity software-defined switches and heterogeneous transmission links (e.g., fiber or wireless optics, high-capacity copper, and wireless millimeter wave links). These links will interconnect RRHs, macro and small cells, and distributed physical and virtual 5G RAN and core network functions (i.e., Physical Network Functions (PNFs) and Virtual Network Functions (VNFs)) hosted on in-network cloud nodes.

The vision is that Xhaul will turn the fronthaul and backhaul into a unified IP network [Cisco]. The unified approach will provide support for key timing issues like phase and frequency, and increases in network scale. The xhaul transport network needs to be application-aware and automated. Xhaul will be a key enabler for network slicing. Slicing will construct xhaul network resources based on SLAs (Service Level Agreements) and the needs of the application. The xhaul resources will be automated, model-driven and programmable (i.e., SDN-based) to be able to deal with real-time service transition and specific latency demands.

References

[5GPPP-1] 5G PPP Architecture Working Group, View on 5G Architecture, https://5g-ppp.eu/wp-content/uploads/2014/02/5G-PPP-5G-Architecture-WP-For-public-consultation.pdf

[5GPPP-2] 5G Crosshaul, the integrated fronthaul/backhaul, https://5g-ppp.eu/xhaul/

[Cisco] Are you ready for 5G xHaul? http://blogs.cisco.com/sp/are-you-ready-for-5g-xhaul

[ER] X-haul, fronthaul and backhaul network research, https://www.ericsson.com/research-blog/5g/x-haul-fronthaul-and-backhaul-network-research/

[EX] Overcoming Network Failures in C-RAN for 5G-Readiness, http://www.exfo.com/corporate/blog/2017/overcoming-network-failures-in-c-ran-for-5g-readiness

[NM] LTE Network Architecture: Basic, http://www.netmanias.com/en/post/techdocs/5904/lte-network-architecture/lte-network-architecture-basic

What is 5G NR (5G New Radio)?

5G NR (5G New Radio) is a wireless network standard for the next (i.e., fifth) generation of mobile networks. 3GPP (Third Generation Partnership Project) is expecting to complete the NR specification in two phases. Phase I will be completed in June 2018 (3GPP Release 14) and Phase II in December 2019 (3GPP Release 15) [3GPP-1].

NR aims to provide a single technical framework addressing a broad range of use cases, requirements and deployment models, including [3GPP-1]:

• enhanced Mobile BroadBand (eMBB) – MBB is the use case for which the previous generations of mobile networks have primarily been optimized
• Massive Machine Type Communications (M-MTC), which is also known as Massive Internet of Things (M-IoT)
• Ultra-Reliable and Low-Latency Communications (URLLC), which is also referred to as Critical MTC (C-MTC) or Critical IoT (C-IoT)

These use cases place very different requirements on NR and the whole 5G system. Critical IoT (e.g., remote controlled machinery, cloud robotics, and self-driving cars) requires extremely low latency and extreme reliability, whereas massive IoT (e.g., large network of stationary weather sensors) has less stringent requirements on latency, reliability, bandwidth and mobility, but requires extreme coverage (enabled by low frequency spectrum). eMBB (e.g., Ultra-High Definition video streaming) requires extreme bandwidth (enabled by millimeter wave spectrum and small cells) and mobility but does typically not require as low latency or reliability as critical IoT.

NR Capabilities

NR aims to meet the 5G requirements outlined by ITU-R (International Telecommunication Union Radiocommunication Sector) for IMT-2020 (International Mobile Telecommunication system) in the IMT-2020 recommendation document (see reference [ITU-R-1]). 3GPP will submit NR as a candidate technology to the IMT-2020 process. Initial submission is expected to happen by June 2019, and a detailed specification will be submitted by October 2020. The IMT-2020 capabilities include [ITU-R-1]:

• Peak data rate of 20 Gbit/s per user or device. This is the maximum achievable data rate under ideal conditions. For IMT-Advanced (i.e., LTE), the peak data rate is 1 Gbit/s.
• User experienced data rate of 100 Mbit/s in wide-area coverage cases (e.g., urban and sub-urban areas). This is the data rate that is available ubiquitously across the coverage area to a user or device. In hotspot areas (e.g., indoors), the user experienced data rate is expected to be 1 Gbit/s. For IMT-Advanced, the user experienced data rate is 10 Mbit/s.
• Latency of 1ms. This is the contribution of the radio network to the end-to-end latency (i.e., the over-the-air latency). For IMT-Advanced, the latency is 10ms.
• Mobility for up to 500 km/h (e.g., when the user is on a high-speed train). This is the maximum speed at which a defined QoS and seamless transfer between radio nodes can be achieved. For IMT-Advanced, the maximum speed is 350 km/h
• Connection density of one million devices per square kilometer. For IMT-Advanced, the figure is 100,000 per km^2
• Network energy efficiency of 100 times higher than for IMT-Advanced
• Spectrum efficiency that is three times higher than for IMT-Advanced
• Area traffic capacity of 10 Mbit/s/m^2. This is the traffic throughput served per geographic area. This represents a 100x improvement over IMT-Advanced
• Spectrum and bandwidth flexibility, such as the ability to operate at different frequency ranges, including higher frequency (e.g., millimeter wave) and wider channel bandwidths than today
• Reliability, that is, the capability to provide a given service with very high availability
• Resilience, which refers to the ability of the network to continue operating for instance after natural disturbances
• Security and privacy, including encryption and integrity protection of user data and signaling, end user privacy (e.g., preventing unauthorized user tracking), and protection of network against hacking, fraud, Denial of Service (DoS), man-in-the-middle attacks, etc.
• Long operational lifetime, which is important for IoT devices that require a very long battery life (e.g., more than 10 years)

NR will achieve the capabilities listed above through [NOK-1]:

• Massive densification of small cells – due to constraints on spectrum efficiency (Shannon’s law) and use of higher frequency spectrum, cell densification is needed for 5G to be able to deliver the required data rate and capacity improvements [NGMN]
• Additional spectrum (see below)
• Increased spectral efficiency, for which a key technology will be massive MIMO (Multiple Input Multiple Output)

Spectrum

NR will be using both more traditional cellular access bands below 6 GHz and large amounts of spectrum available above 6 GHz [NOK-1]. In fact, NR should be able to use any spectrum band ranging at least up to 100 GHz that may be made available for wireless communications [3GPP-1]. NR will be using [QC-1]:

• Low bands below 1 GHz to achieve longer range for example for mobile broadband and massive IoT. The could include for example 600 MHz, 700 MHz, and 850/900 MHz
• Mid bands from 1 GHz to 6 GHz to provide wider bandwidth for example for eMBB and critical IoT. Examples include 3.4 - 3.8 GHz, which includes also the CBRS (Citizens Broadband Radio Service) bands, 3.8 - 4.2 GHz, and 4.4 – 4.9 GHz.
• High bands above 24 GHz, which will be helpful for reaching extreme bandwidths. Examples include 24.25 – 27.5 GHz, 27.5 – 29.5 GHz, 37-40 GHz, and 64 – 71 GHz.

NR will be leveraging a combination of licensed, shared, and unlicensed spectrum with a goal of having a unified design across all of these spectrum types and bands, including both below and above 6 GHz.

The frequency bands between 3 GHz and 30 GHz are known as centimeter wave (cmWave) bands, whereas bands between 30 GHz and 300 GHz are known as millimeter wave (mmWave) bands. At mmWave frequencies, the radio propagation and Radio Frequency (RF) engineering is different from the traditional sub-6 GHz cellular access bands. For example, diffraction (short radio waves are affected more by obstacles than long radio waves [LR-1]), foliage (radio signal running into leaves on a tree), and structure penetration losses (penetration loss of radio waves for example through walls of a building tends to increase with frequency [ITU-R-2]) are higher at mmWave frequencies [NOK-1]. However, mmWave frequencies are still similar to sub-6 GHz frequencies when it comes to reflections and path loss exponents. mmWave’s reach and ability to support mobility can be extended from Line-of-Sight (LOS) to Non-Line-of-Sight (NLOS) scenarios with beamforming and beamtracking by leveraging reflected and scattered radio waves [AT-1, INF-1]. Telecom vendors have demonstrated very high data rates using mmWave spectrum (e.g., 15 Gbps at 73 GHz with 2 GHz bandwidth [NOK-1]).

Likely NR Features

NR is still work-in-progress since its standardization is currently ongoing in 3GPP. However, it is possible to extract various likely NR features for example from the latest 3GPP documents, and vendor and operator white papers and press releases. These include:

• Access/backhaul integration [ERIC-1]
• Carrier Aggregation (CA) evolution [QC-1]
• Direct Device-to-Device (D2D) communication [ERIC-1]
• Flexible duplex (FDD (Frequency Division Duplexing) and TDD (Time Division Duplexing)) [ERIC-1] / dynamic uplink/downlink (UL/DL) switching [QC-1]
• Multi-antenna transmission [ERIC-1], which could include Massive MIMO (Multiple Input Multiple Output) [QC-1], FD-MIMO (Full-Dimension MIMO; 3D beamforming) [QC-1], Multi-User MIMO (MU-MIMO), hybrid beamforming, distributed MIMO, adaptive beamforming and beamtracking
• Multi-Connectivity (including NR, LTE, Wi-Fi) [QC-1]
• Narrowband 5G (NB-5G), supporting e.g., RSMA (Resource Spread Multiple Access) and multi-hop mesh [QC-1]
• NR-based MulteFire [QC-1]
• NR-based Licensed Assisted Access (LAA) [QC-1]
• NR-based tiered sharing of spectrum utilizing CBRS (Citizens Broadband Radio Service) and LSA (Licensed Shared Access) [QC-1]
• OFDM (Orthogonal Frequency Division Multiplexing) based waveform (also LTE uses OFDM) [3GPP-1]
• Scalable numerology with scaling of subcarrier spacing [QC-1]
• Scalable Transmission Time Interval (TTI) [QC-1]
• Self-backhauling [HW-1]
• Self-contained integrated subframe design [QC-1]
• Ultra-lean design [ERIC-1]
• User/control separation [ERIC-1]
• V2X (Vehicle-to-Everything) [QC-1, 3GPP-3]

It should be noted that many of these technologies are evolved versions of features (e.g., MIMO, carrier aggregation, Narrowband IoT (NB-IoT), MulteFire, LAA, LSA, OFDM) that have already been introduced in LTE. I intend to publish additional blog posts in the near future that give a bit more details about them.

5G beyond NR

Finally, even though they were the focus of this blog post, 5G is much more than a NR-based new radio access network and additional spectrum. There are plenty of developments also in the transport network and core network that deserve to be discussed in future blog posts, including for example network slicing, programmable network, service chaining (a.k.a., Service Function Chaining; SFC), Software-Defined Networking (SDN), Network Functions Virtualization (NFV), Next Generation Core (NGC), Cloud-RAN, virtual cells, xhaul, Core Network as-a-Service (CNaaS), RAN as-a-Service (RANaaS), end-to-end management and orchestration, Mobile Edge Computing (MEC), and the use of Machine Learning (ML) and Artificial Intelligence (AI). In addition to NR, many of these technologies will be needed to make 5G a platform that is capable of providing extreme bandwidth, extremely low latency, extreme reliability, extreme coverage, extreme flexibility, and security to cater for the needs of a broad range of use cases.

References

[3GPP-1] 3GPP TR 38.912 V1.0.0 (2017-03), 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Study on New Radio (NR) Access Technology (Release 14), http://www.3gpp.org/ftp//Specs/archive/38_series/38.912/38912-100.zip

[3GPP-2] Tentative 3GPP timeline for 5G, http://www.3gpp.org/news-events/3gpp-news/1674-timeline_5g

[3GPP-3] 3GPP TR 22.886 V15.1.0 (2017-03), Technical Report, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on enhancement of 3GPP Support for 5G V2X Services (Release 15), https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3108

[AT-1] Millimeter-wave 5G modem coming mid-2018 with 5Gbps peak download, https://arstechnica.com/business/2016/10/qualcomm-5g-x50-modem-millimetre-wave-5g-modem/

[ERIC-1] Ericsson White paper, 5G Radio Access, https://www.ericsson.com/res/docs/whitepapers/wp-5g.pdf

[HW-1] 5G: A Technology Vision, http://www.huawei.com/5gwhitepaper/

[INF-1] Introduction to Millimeter Wave Wireless Communications, http://www.informit.com/articles/article.aspx?p=2249780

[ITU-R-1] Recommendation ITU-R M.2083-0 (09/2015), IMT Vision – Framework and overall objectives of the future development of IMT for 2020 and beyond, https://www.itu.int/dms_pubrec/itu-r/rec/m/R-REC-M.2083-0-201509-I!!PDF-E.pdf

[ITU-R-2] Recommendation ITU-R  P.2040-1 (07/2015), Effects of building materials and structures on radiowave propagation above about 100 MHz, https://www.itu.int/dms_pubrec/itu-r/rec/p/R-REC-P.2040-1-201507-I!!PDF-E.pdf

[LR-1] Vodafone CTO 'Worried' About 5G mmWave Hype, http://www.lightreading.com/mobile/spectrum/vodafone-cto-worried-about-5g-mmwave-hype/d/d-id/730679

[NGMN] NGMN 5G White Paper, https://www.ngmn.org/uploads/media/NGMN_5G_White_Paper_V1_0.pdf

[NOK-1] 5G Radio Access System Design Aspects, http://resources.alcatel-lucent.com/asset/200009

[QC-1] Making 5G NR A Reality, https://www.qualcomm.com/documents/making-5g-nr-reality

A Quick Guide to LTE in Unlicensed Spectrum, Part 2: SAS (Spectrum Access System) and LSA (Licensed Shared Access)

In my previous blog post, I covered a number of technologies related to the use of LTE in unlicensed spectrum. This blog post continues on that topic, with a focus on spectrum management systems.

Today, wireless spectrum below 6GHz is fully allocated to incumbents who, unsurprisingly, oppose any proposals to repurpose the spectrum to someone else. Thus, the traditional approach of repurposing spectrum for new cellular technologies is no longer sufficient in the case of 5G – novel ways to manage spectrum below 6GHz are needed. Two such technologies are LSA (Licensed Shared Access) and SAS (Spectrum Access System). LSA is a shared spectrum technology deployed in Europe, whereas SAS is its counterpart in the US.

Spectrum Access System (SAS)

SAS authorizes and manages use of spectrum for the Citizens Broadband Radio Service (CBRS), which is 150MHz of spectrum in the US in the 3550-3700MHz band that the FCC (Federal Communications Commission) opened up in 2015 for commercial use. CBRS enables almost anyone to use this spectrum while it is still being used by existing incumbents such as the military or satellite communication [QC-1].

CBRS defines three levels of priority when assigning shared spectrum [TSC]:

• Tier-1: Incumbent users (e.g., the Department of Defence) have the highest priority. 
• Tier-2: Priority Access Licenses (PAL), where an organization can pay for a fee to be assigned a 10MHz block for a limited geographic area for a three-year period, giving them priority over other users. A maximum of seven such blocks can be concurrently allocated within the same geographic area. Thus, max 70MHz of the available 150MHz can be assigned to priority users and the remaining 80MHz is left for others to use.
• Tier-3: General Authorized Access (GAA) for general usage. In this third tier, anyone can use the spectrum when it is not used by the higher layers.

As an example, an LTE network can be operated on licensed shared basis in the CBRS frequency band and it is not surprising that the telecom industry is interested in the band since it is considered one of the low-band options to support 5G, which is expected to have a high reliance on bands above the 25GHz level [RCR].

The 3.5GHz band does not penetrate indoors as much as lower frequencies. Thus, it is a good fit for small cells and their dense deployment model. As an example, organizations such as private enterprises, venues, and fixed operators could autonomously deploy high-quality in-building LTE networks e.g., following a floor-by-floor deployment model [FW].

Licensed Shared Access (LSA)

The LSA system includes coordination of resource usage between incumbents and LSA licensees. Its main use case is the extension of cellular capacity below 6GHz in Europe. One major difference between SAS and LSA is that LSA is missing tier-3 (i.e., GAA). LSA enables an LTE network to be operated on licensed shared basis in the 2.3-2.4GHz frequency band between incumbents (tier-1) and Mobile Network Operators (MNOs; tier-2) [Intel]. Tier-1 is prioritized over tier-2, meaning that the MNO using the LSA band is required to vacate it for a given geographic area, frequency range, and period of time for which the incumbent is requiring access. The expectation is that MNOs will enter in multi-year (typically ten years or more) sharing agreements with the incumbents for the LSA band. The LSA band is typically combined with LTE in dedicated licensed spectrum through carrier aggregation mechanisms

Spectrum management in LSA relies on an LSA Repository, which is a centralized database providing information about the availability of the LSA spectrum to multiple MNO networks [Intel]. Incumbents need to provide a priori usage information to the database on the LSA band’s availability. Based on this information, the LTE system is either granted access or requested to vacate the concerned bands using control mechanisms of an LSA Controller located within the MNO network. The LSA Controllers and the LSA Repository interact through an ETSI (European Telecommunications Standards Institute) defined interface. In LSA, no sensing mechanisms are required for the identification of incumbent operation in the LSA band.

And back to SAS

In contrast to LSA, SAS is designed to ensure coexistence with incumbents (e.g., the military using networks operated mainly close to US coastal areas) who are not able to provide a priori information to the central repository [Intel]. SAS can be operated throughout the US territory except within exclusion zones close to the coastal areas. In the second step of SAS, an Environmental Sensing Capability (ESC) component is added which allows operation even within the exclusion zones. ESC performs required sensing tasks to discover incumbent operation in the CBRS band. Spectrum access for tier-2 and tier-3 users is based on the sensing results. ESC will consist of networks of sensors that detect the presence of signals from incumbent systems in the CBRS band and communicate that information to one or more SAS repositories to facilitate protection of incumbent operations in the band [FW-2].

One of the companies that has filed SAS Administrator and ESC Operator applications with the FCC is Google [FW-2]. Google wrote in its application that it has been trialing a prototype SAS for almost two years. Google has also demonstrated its SAS prototype to industry and government. Google believes that 5G deployment will receive a boost from the CBRS band and that SAS will make the traditional model of MNOs spending billions of dollars to gain control of specific spectrum blocks no longer valid [RCR]. According to Preston Marshall, an engineering director for Alphabet Access at Google, “This [SAS] changes what spectrum ownership means. There is no owner”. Google believes that the killer application for the CBRS band will be the neutral host concept, which is an attractive model in places where it is not feasible for every operator to deploy their own radio systems independently, such as in enterprises or public venues like sports stadiums or shopping malls.

Besides neutral host scenarios, the CBRS band can be useful for enabling MNOs to offer Gigabit LTE speeds in more places thanks to the additional spectrum, for small cell deployments to extend coverage and capacity outdoors, and for creating private LTE networks for enterprises or industrial IoT.

Google is not stopping at the CBRS band – the company has urged the FCC to seriously consider applying the SAS framework to the 24GHz band as well [SE].

References

[FW] Google, Intel, Nokia and more partner to advance U.S. 3.5 GHz CBRS, http://www.fiercewireless.com/tech/google-intel-nokia-and-more-partner-to-advance-u-s-3-5-ghz-cbrs

[FW-2] Google, Federated Wireless, others apply to fill role of SAS, ESC for 3.5 GHz, http://www.fiercewireless.com/tech/google-federated-wireless-others-apply-to-fill-role-sas-esc-for-3-5-ghz

[Intel] Spectrum Sharing Technology | LSA and SAS White Paper, http://www.intel.com/content/www/us/en/wireless-network/spectrum-sharing-lsa-sas-paper.html

[QC-1] A new kind of spectrum for new opportunities, https://www.qualcomm.com/news/onq/2016/08/29/new-kind-spectrum-new-opportunities

[RCR] Google sees CBRS spectrum band as key for 5G, new model for industry, http://www.rcrwireless.com/20161117/carriers/google-sees-cbrs-spectrum-band-key-5g-new-model-industry-tag2

[SE] Google urges FCC to consider SAS model for 24 GHz band, http://www.spectrumeffect.com/google-urges-fcc-to-consider-sas-model-for-24-ghz-band.html

[TSC] What is CBRS Shared Spectrum for in-building small cell wireless? https://www.thinksmallcell.com/LTE/what-is-cbrs-shared-spectrum-for-in-building-small-cell-wireless.html

A Quick Guide to LTE in Unlicensed Spectrum, Part 1: LTE-U, LAA, LWA, MulteFire, Neutral Hosts, Private LTE Networks, QUIC and Multipath TCP

I have been a bit lost with all the unlicensed spectrum related terms and abbreviations listed in the title of this blog post. This post is an attempt to bring some clarity to myself and hopefully also to others who might discover the post.

Many of the technologies in the title like LTE-U, LAA, MulteFire and LWA are the result of recent developments within various standardization bodies and the telecommunications industry around data offloading to unlicensed spectrum.

LAA (Licensed Assisted Access) uses carrier aggregation in the downlink to combine LTE (Long Term Evolution) in unlicensed spectrum (5GHz, which is also used by 802.11a Wi-Fi) with LTE in the licensed band [QC-3, TVT]. The benefit of doing so is a fatter data pipe with faster data rates and more responsive user experience. LAA maintains a persistent anchor in the licensed spectrum. All control signaling information is carried in the licensed band, which ensures seamless and reliable user experience. LAA is for mobile operator deployments in Europe and Japan.

LTE-U (LTE in Unlicensed Spectrum) is the US (and Korean and Indian) version of LAA [4GA, QC-2]. It differs from LAA mostly in the way it handles contention. Whereas LAA has been specified in 3GPP, LTE-U has been defined in LTE-U Forum. LTE-U focuses on deployment options and regions where LBT (Listen Before Talk) policy, which is used by LAA, is not required. Both LTE-U and LAA dynamically select the unused channel with the least interference, avoiding Wi-Fi. At low traffic loads, they turn off transmission in the unlicensed spectrum, relying solely on the anchor of the licensed spectrum. In cases where there is no clear unused channel, they aim for fair and efficient coexistence with Wi-Fi. For this, LAA uses LBT to sense channel availability and adjust on/off LTE cycling (LTE on/off cycling is used to share the channel fairly with Wi-Fi). In contrast, LTE-U uses CSAT (Carrier-Sensing Adaptive Transmission) to sense other users and adjust on/off LTE cycling. CSAT and LBT represent fundamentally different approaches to access the channel [IEEE]. There are opinions that LTE-U/LAA are an attempt by mobile network operators to expand into the Wi-Fi spectrum and push out the Wi-Fi operators [TVT].

MulteFire is an LTE-based technology that, unlike LAA and LTE-U, solely operates in unlicensed spectrum without requiring an anchor in licensed spectrum [QC-1]. It broadens the LTE ecosystem to entities that may not own licensed spectrum, including ISPs (Internet Service Providers) and enterprise and venue owners. MulteFire is claimed to combine the performance benefits of LTE technology such as enhanced capacity, range, mobility and quality of experience with the simplicity of Wi-Fi like deployments. MulteFire is suitable for neutral host services. Neutral host is an LTE deployment that can be used by subscribers irrespective of their service provider. In the neutral host model, any deployment (e.g., by an ISP or enterprise or venue owner) can provide wireless access services to any end user without requiring a SIM or subscription, using neutral unlicensed spectrum. MulteFire can also interface with mobile networks to offer data offload services to mobile operators. Finally, MulteFire can be used to create private LTE networks using unlicensed spectrum bands [QC-4] for example for Industrial Internet of Things (IIoT) or enterprise use.

LWA (LTE Wi-Fi Aggregation) differs from LAA and LTE-U since LWA access in the unlicensed spectrum is based on IEEE 802.11 (i.e., Wi-Fi) standards [NOK]. LWA uses both LTE and WLAN (Wireless Local Area Network) interfaces in parallel: LTE provides reliable connectivity and mobility and Wi-Fi boosts data capacity and improves coverage. LWA aggregates data at the radio access network where Evolved NodeB (eNB; a base station) schedules packets to be served on LTE and Wi-Fi radio links [4GA].  LWA supports downlink aggregation at the PDCP (Packet Data Convergence Protocol; one of the user plane protocols in LTE that sends and receives packets to and from User Equipment (UE) and eNodeB over air interface) layer. It supports uplink transmissions only on the LTE network. LWA introduces a new direct interface Xw, which is defined between LTE and Wi-Fi. The Xw interface is terminated at the WT (WLAN termination), which is a new 3GPP logical node that may be in control of one or more WLAN APs (Access Points).

QUIC (Quick User Datagram Protocol Internet Connections) and Multipath TCP (Transmission Control Protocol) are options for multi-connectivity/aggregation that occur at the network level [4GA]. They can work with any combination of licensed and unlicensed band technologies, including future ones such as 5G. QUIC is a transport protocol that supports a set of multiplexed connections between two endpoints over UDP (User Datagram Protocol). It provides security equivalent to TLS/SSL (Transport Layer Security and Secure Sockets Layer) together with reduced connection and transport latency, and bandwidth estimation in each direction to avoid congestion [WP]. IETF’s (Internet Engineering Task Force) QUIC Working Group (WG) is looking into extending QUIC’s core protocol facilities to enable multipath capabilities for connection migration between paths and load sharing across multiple paths [IETF]. This would also enable the parallel use of Wi-Fi and LTE interfaces to download content. Multipath TCP is another ongoing effort in the IETF that aims at allowing a TCP connection to use multiple paths to maximize resource usage and increase redundancy [WP-2]. The use of both Wi-Fi and a mobile network is a typical use case for Multipath TCP. Multipath TCP can split data and transmit them through both LTE and Wi-Fi networks in parallel. LTE-Wi-Fi aggregation takes place between a device and MPTCP proxy, meaning that no dedicated network equipment is required for aggregation additionally [NM].

There exists a bunch of other exciting unlicensed spectrum related abbreviations and technologies that I plan to look into in a future blog post, including CBRS, LAS, SAS, PAL, GAA, and ESC. Stay tuned!

Although this blog post focused on LTE in unlicensed spectrum, unlicensed spectrum will also be key in boosting data rates in 5G NR (5G New Radio), which is the topic of another blog post.

(If I counted right, I managed to fit over 30 different abbreviations into this blog post).

References

[4GA] LTE Aggregation & Unlicensed Spectrum, http://www.4gamericas.org/files/1214/4648/2397/4G_Americas_LTE_Aggregation__Unlicensed_Spectrum_White_Paper_-_November_2015.pdf

[IEEE] Unlicensed LTE/WiFi coexistence: Is LBT inherently fairer than CSAT?, http://ieeexplore.ieee.org/document/7510910/

[IETF] IETF’s QUIC Working Group Charter, https://datatracker.ietf.org/wg/quic/charter/

[MG] Google’s QUIC protocol: moving the web from TCP to UDP, https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp/

[NM] Analysis of LTE – WiFi Aggregation Solutions, http://www.netmanias.com/en/post/reports/8532/laa-lte-lte-u-lwa-mptcp-wi-fi/analysis-of-lte-wifi-aggregation-solutions

[NOK] Unlicensed band opportunities for mobile broadband, http://resources.alcatel-lucent.com/asset/200296

[QC-1] Introducing MulteFire: LTE-like performance with Wi-Fi-like simplicity, https://www.qualcomm.com/news/onq/2015/06/11/introducing-multefire-lte-performance-wi-fi-simplicity

[QC-2] How different are LTE-U and LAA?, https://www.qualcomm.com/news/onq/2015/11/04/how-different-are-lte-u-and-laa

[QC-3] Extending LTE to unlicensed spectrum globally – LAA, https://www.qualcomm.com/invention/technologies/lte/laa

[QC-4] GE, Nokia and Qualcomm Unveil First Private LTE-based Trial Network Customized for Industrial IoT, https://www.qualcomm.com/news/releases/2017/02/22/ge-nokia-and-qualcomm-unveil-first-private-lte-based-trial-network

[TVT] LWA offers aggregation without the aggravation: the alternative acronym to LTE-U and LAA, http://www.telecomtv.com/articles/wi-fi/lwa-offers-aggregation-without-the-aggravation-the-alternative-acronym-to-lte-u-and-laa-12804/

[WP] QUIC, https://en.wikipedia.org/wiki/QUIC

[WP-2] Multipath TCP, https://en.wikipedia.org/wiki/Multipath_TCP