5G Network Architecture Options (Updated)

ICYMI, we created an updated video on 5G Network Architecture options. The videos and slides are embedded below.

Intermediate: 5G Network Architecture Options (Updated) from 3G4G

This updated presentation/video looks at 5G Network Architecture options that have been proposed by 3GPP for deployment of 5G. It covers the Standalone (SA) and Non-Standalone (NSA) architecture. In the NSA architecture, EN-DC (E-UTRA-NR Dual Connectivity), NGEN-DC (NG-RAN E-UTRA-NR Dual Connectivity) and NE-DC (NR-E-UTRA Dual Connectivity) has been looked at. Finally, migration strategies proposed by vendors and operators (MNOs / SPs) have been discussed.


Nokia has also released a whitepaper on this topic that I only became aware of after my slides / video were done. More details in the tweet below.

Nokia has released a whitepaper on 5G Network Deployment Options, 'Understanding the strange language of NSA vs SA and options 3, 2, 7 and 4'. Available here: https://t.co/FJEIbEuAFO - ICYMI, we also made a new tutorial on this topic: https://t.co/5QOll1Sui7 pic.twitter.com/tHjbuEfW3l

— 3G4G (@3g4gUK) October 5, 2018

Related Links:

• Free 2G, 3G, 4G & 5G Training Videos
• 5G (IMT-2020) Wireless Resources
• 3GPP 5G Specifications
• Introduction to Fixed Wireless Access (FWA)
• 5G Network Architecture Options (Updated)

End-to-end Network Slicing in 5G

I recently realised that I have never written a post just on Network slicing. So here is one on the topic. So the first question asked is, why do we even need Network Slicing? Alan Carlton from Interdigital wrote a good article on this topic. Below is what I think is interesting:

Network slicing is a specific form of virtualization that allows multiple logical networks to run on top of a shared physical network infrastructure. The key benefit of the network slicing concept is that it provides an end-to-end virtual network encompassing not just networking but compute and storage functions too. The objective is to allow a physical mobile network operator to partition its network resources to allow for very different users, so-called tenants, to multiplex over a single physical infrastructure. The most commonly cited example in 5G discussions is sharing of a given physical network to simultaneously run Internet of Things (IoT), Mobile Broadband (MBB), and very low-latency (e.g. vehicular communications) applications. These applications obviously have very different transmission characteristics. For example, IoT will typically have a very large number of devices, but each device may have very low throughput. MBB has nearly the opposite properties since it will have a much smaller number of devices, but each one will be transmitting or receiving very high bandwidth content. The intent of network slicing is to be able to partition the physical network at an end-to-end level to allow optimum grouping of traffic, isolation from other tenants, and configuring of resources at a macro level.

Source: ITU presentation, see below

The key differentiator of the network slicing approach is that it provides a holistic end-to-end virtual network for a given tenant. No existing QoS-based solution can offer anything like this. For example, DiffServ, which is the most widely deployed QoS solution, can discriminate VoIP traffic from other types of traffic such as HD video and web browsing. However, DiffServ cannot discriminate and differentially treat the same type of traffic (e.g. VoIP traffic) coming from different tenants.

Also, DiffServ does not have the ability to perform traffic isolation at all. For example, IoT traffic from a health monitoring network (e.g. connecting hospitals and outpatients) typically have strict privacy and security requirements including where the data can be stored and who can access it. This cannot be accomplished by DiffServ as it does not have any features dealing with the compute and storage aspects of the network. All these identified shortfalls of DiffServ will be handled by the features being developed for network slicing.

I came across this presentation by Peter Ashwood-Smith from Huawei Technologies who presented '5G End to-end network slicing Demo' at ITU-T Focus Group IMT-2020 Workshop and Demo Day on 7 December 2016. Its a great presentation, I wish a video of this was available as well. Anyway, the presentation is embedded below and the PPT can be downloaded from here.

5G End to-end network slicing Demo from ITU

The European Telecommunications Standards Institute (ETSI) has established a new Industry Specification Group (ISG) on Zero touch network and Service Management (ZSM) that is working to produce a set of technical specifications on fully automated network and service management with, ideally, zero human intervention. ZSM is targeted for 5G, particularly in network slice deployment. NTT Technical review article on this is available here.

Finally, here is a presentation by Sridhar Bhaskaran of Cellular Insights blog on this topic. Unfortunately, not available for download.


Related Posts:

• 5G and IoT Security Update from ETSI Security Week 2018
• 5G – Beyond the Hype
• 5G Network Architecture Options (Updated)
• Automated 4G / 5G HetNet Design

Automating the 5G Core using Machine Learning and Data Analytics

One of the new entities introduced by 3GPP in the 5G Core SBA (see tutorial here) is Network Data Analytics Function, NWDAF.

3GPP TR 23.791: Study of Enablers for Network Automation for 5G (Release 16) describes the following 5G Network Architecture Assumptions:

1 The NWDAF (Network Data Analytics Function) as defined in TS 23.503 is used for data collection and data analytics in centralized manner. An NWDAF may be used for analytics for one or more Network Slice.
2 For instances where certain analytics can be performed by a 5GS NF independently, a NWDAF instance specific to that analytic maybe collocated with the 5GS NF. The data utilized by the 5GS NF as input to analytics in this case should also be made available to allow for the centralized NWDAF deployment option.
3 5GS Network Functions and OAM decide how to use the data analytics provided by NWDAF to improve the network performance.
4 NWDAF utilizes the existing service based interfaces to communicate with other 5GC Network Functions and OAM.
5 A 5GC NF may expose the result of the data analytics to any consumer NF utilizing a service based interface.
6 The interactions between NF(s) and the NWDAF take place in the local PLMN (the reporting NF and the NWDAF belong to the same PLMN).
7 Solutions shall neither assume NWDAF knowledge about NF application logic. The NWDAF may use subscription data but only for statistical purpose.

Picture Source: Application of Data Mining in the 5G Network Architecture by Alexandros Kaloxylos

Continuing from 3GPP TR 23.791:

The NWDAF may serve use cases belonging to one or several domains, e.g. QoS, traffic steering, dimensioning, security.
The input data of the NWDAF may come from multiple sources, and the resulting actions undertaken by the consuming NF or AF may concern several domains (e.g. Mobility management, Session Management, QoS management, Application layer, Security management, NF life cycle management).
Use case descriptions should include the following aspects:
1. General characteristics (domain: performance, QoS, resilience, security; time scale).
2. Nature of input data (e.g. logs, KPI, events).
3. Types of NF consuming the NWDAF output data, how data is conveyed and nature of consumed analytics.
4. Output data.
5. Possible examples of actions undertaken by the consuming NF or AF, resulting from these analytics.
6. Benefits, e.g. revenue, resource saving, QoE, service assurance, reputation.

Picture Source: Application of Data Mining in the 5G Network Architecture by Alexandros Kaloxylos

3GPP TS 23.501 V15.2.0 (2018-06) Section 6.2.18 says:

NWDAF represents operator managed network analytics logical function. NWDAF provides slice specific network data analytics to a NF. NWDAF provides network analytics information (i.e., load level information) to a NF on a network slice instance level and the NWDAF is not required to be aware of the current subscribers using the slice. NWDAF notifies slice specific network status analytic information to the NFs that are subscribed to it. NF may collect directly slice specific network status analytic information from NWDAF. This information is not subscriber specific.

In this Release of the specification, both PCF and NSSF are consumers of network analytics. The PCF may use that data in its policy decisions. NSSF may use the load level information provided by NWDAF for slice selection.

NOTE 1: NWDAF functionality beyond its support for Nnwdaf is out of scope of 3GPP.
NOTE 2: NWDAF functionality for non-slice-specific analytics information is not supported in this Release of the specification.

3GPP Release-16 is focusing on 5G Expansion and 5G Efficiency, SON and Big Data are part of 5G Efficiency.

3GPP Release-16 is going to focus on 5G expansion & efficiency. Listen to the @3GPPLive Webinar here: https://t.co/tKzXJ3cUFj pic.twitter.com/1xCZfpT9lt

— 3G4G (@3g4gUK) July 14, 2018

Light Reading Artificial Intelligence and Machine Learning section has a news item on this topic from Layer123's Zero Touch & Carrier Automation Congress:

The 3GPP standards group is developing a machine learning function that could allow 5G operators to monitor the status of a network slice or third-party application performance.

The network data analytics function (NWDAF) forms a part of the 3GPP's 5G standardization efforts and could become a central point for analytics in the 5G core network, said Serge Manning, a senior technology strategist at Sprint Corp.

Speaking here in Madrid, Manning said the NWDAF was still in the "early stages" of standardization but could become "an interesting place for innovation."

The 3rd Generation Partnership Project (3GPP) froze the specifications for a 5G new radio standard at the end of 2017 and is due to freeze another set of 5G specifications, covering some of the core network and non-radio features, in June this year as part of its "Release 15" update.

Manning says that Release 15 considers the network slice selection function (NSSF) and the policy control function (PCF) as potential "consumers" of the NWDAF. "Anything else is open to being a consumer," he says. "We have things like monitoring the status of the load of a network slice, or looking at the behavior of mobile devices if you wanted to make adjustments. You could also look at application performance."

In principle, the NWDAF would be able to make use of any data in the core network. The 3GPP does not plan on standardizing the algorithms that will be used but rather the types of raw information the NWDAF will examine. The format of the analytics information that it produces might also be standardized, says Manning.

Such technical developments might help operators to provide network slices more dynamically on their future 5G networks.

Generally seen as one of the most game-changing aspects of 5G, the technique of network slicing would essentially allow an operator to provide a number of virtual network services over the same physical infrastructure.

For example, an operator could provide very high-speed connectivity for mobile gaming over one slice and a low-latency service for factory automation on another -- both reliant on the same underlying hardware.

However, there is concern that without greater automation operators will have less freedom to innovate through network slicing. "If operators don't automate they will be providing capacity-based slices that are relatively large and static and undifferentiated and certainly not on a per-customer basis," says Caroline Chappell, an analyst with Analysys Mason .

In a Madrid presentation, Chappell said that more granular slicing would require "highly agile end-to-end automation" that takes advantage of progress on software-defined networking and network functions virtualization.

"Slices could be very dynamic and perhaps last for only five minutes," she says. "In the very long term, applications could create their own slices."

Despite the talk of standardization, and signs of good progress within the 3GPP, concern emerged this week in Madrid that standards bodies are not moving quickly enough to address operators' needs.

Caroline Chappell's talk is available here whereas Serge Manning's talk is embedded below:



I am helping CW organise the annual CW TEC conference on the topic The inevitable automation of Next Generation Networks

#CWTEC 2018 planning committee working hard to bring an exciting conference - explores the role of #AI in delivering Next Gen. Network performance; & bridges the gap between #AI/#ML & Telecos communities! @zahidtg @Bob_CWCEO @swunger Paul Ceely @bt_uk , John Haine @BristolCSN pic.twitter.com/4uGprC1usg

— Sylvia Lu (@SylviaLuUk) July 23, 2018

Communications networks are perhaps the most complex machines on the planet. They use vast amounts of hardware, rely on complex software, and are physically distributed over land, underwater, and in orbit. They increasingly provide essential services that underpin almost every aspect of life. Managing networks and optimising their performance is a vast challenge, and will become many times harder with the advent of 5G. The 4th Annual CW Technology Conference will explore this challenge and how Machine Learning and AI may be applied to build more reliable, secure and better performing networks.

Is the AI community aware of the challenges facing network providers? Are the network operators and providers aware of how the very latest developments in AI may provide solutions? The conference will aim to bridge the gap between AI/ML and communications network communities, making each more aware of the nature and scale of the problems and the potential solutions.

I am hoping to see some of this blog readers at the conference. Looking forward to learning more on this topic amongst others for network automation.

Related Post:

• Artificial Intelligence - Beyond SON for Autonomous Networks

Minimum Bandwidth Requirement for 5G Non-Standalone (NSA) Deployment

I was attending the IEEE 5G World Forum live-stream, courtesy of IEEE Tv and happen to hear Egil Gronstad, Senior Director of Technology Development and Strategy at T-Mobile USA. He said that they will be building a nationwide 5G network that will initially be based on 600 MHz band.

During the Q&A, Egil mentioned that because of the way the USA has different markets, on average they have 31 MHz of 600 MHz (Band 71). The minimum is 20 MHz and the maximum is 50 MHz.

So I started wondering how would they launch 4G & 5G in the same band for nationwide coverage? They have a good video on their 5G vision but that is of course probably going to come few years down the line.

In simple terms, they will first deploy what is known as Option 3 or EN-DC. If you want a quick refresher on different options, you may want to jump to my tutorial on this topic at 3G4G here.

The Master Node (recall dual connectivity for LTE, Release-12. See here) is an eNodeB. As with any LTE node, it can take bandwidths from 1.4 MHz to 20 MHz. So the minimum bandwidth for LTE node is 1.4 MHz.

The Secondary Node is a gNodeB. Looking at 3GPP TS 38.101-1, Table 5.3.5-1 Channel bandwidths for each NR band, I can see that for band 71

	NR band / SCS / UE Channel bandwidth
NR Band	SCS kHz	5 MHz	101,2 MHz	152 MHz	202 MHz	252 MHz	30 MHz	40 MHz	50 MHz	60 MHz	80 MHz	90 MHz	100 MHz
n71	15	Yes	Yes	Yes	Yes
	30		Yes	Yes	Yes
	60

The minimum bandwidth is 5MHz. Of course this is paired spectrum for FDD band but the point I am making here is that you need just 6.4 MHz minimum to be able to support the Non-Standalone 5G option.

I am sure you can guess that the speeds will not really be 5G speeds with this amount of bandwidth but I am looking forward to all these kind of complaints in the initial phase of 5G network rollout.

I dont know what bandwidths T-Mobile will be using but we will see at least 10MHz of NR in case where the total spectrum is 20 MHz and 20 MHz of NR where the total spectrum is 50 MHz.

If you look at the earlier requirements list, the number being thrown about for bandwidth was 100 MHz for below 6 GHz and up to 1 GHz bandwidth for spectrum above 6 GHz. Don't think there was a hard and fast requirement though.

Happy to hear your thoughts.

An Introduction to ONF and CORD (Central Office Re-architected as a Datacenter)

Continuing on the theme of Open Source from last week's post from Telefonica, lets look at the CORD by ONF.

The CORD (Central Office Re-architected as a Datacenter) platform leverages SDN, NFV and Cloud technologies to build agile datacenters for the network edge. Integrating multiple open source projects, CORD delivers a cloud-native, open, programmable, agile platform for network operators to create innovative services.

CORD provides a complete integrated platform, integrating everything needed to create a complete operational edge datacenter with built-in service capabilities, all built on commodity hardware using the latest in cloud-native design principles.



The video above from MWC 2018 is a very short summary of what ONF and CORD is. The video below from OCP Telecom Workshop at the Big Communications Event (BCE) on May 14th, 2018 in Austin, Texas looks at CORD in detail.



Related Post:

• Telefonica and open source

Tutorial on Network In a Box (NIB)

Made a short video explaining what Network In a Box is. Slides and video embedded below.

Beginners: Network In a Box (NIB) from 3G4G

5G Security Updates - March 2018

Its been a while since I wrote about 5G security in this fast changing 5G world. If you are new to 3GPP security, you may want to start with my tutorial here.

3GPP SA3 Chairman, Anand R. Prasad recently mentioned in his LinkedIn post:

5G security specification finalized! Paving path for new business & worry less connected technology use.

3GPP SA3 delegates worked long hours diligently to conclude the specification for 5G security standard during 26 Feb.-2 Mar. Several obstacles were overcome by focussed effort of individuals & companies from around the globe. Thanks and congrats to everyone!

All together 1000s of hours of work with millions of miles of travel were spent in 1 week to get the work done. This took 8 meetings (kicked off Feb. 2017) numerous on-line meetings and conference calls.

Excited to declare that this tremendous effort led to timely completion of 5G security specification (TS 33.501) providing secure services to everyone and everything!

The latest version of specs is on 3GPP website here.

ITU also held a workshop on 5G Security in Geneva, Switzerland on 19 March 2018 (link). There were quite a few interesting presentations. Below are some slides that caught my attention.

Major 5G Security Issues via Min Zuo, China Mobile #RANSplit #NetworkSlicing #SBA #NFV #SDN #CloudComputing #MEC pic.twitter.com/GD8EMNP1Fk

— 3G4G (@3g4gUK) March 20, 2018

The picture in the tweet above from China Mobile summarises the major 5G security issues very well. 5G security is going to be far more challenging than previous generations.

The presentation by Haiguang Wang, Huawei contained a lot of good technical information. The picture at the top is from that presentation and highlights the difference between 4G & 5G Security Architecture.

New entities have been introduced to make 5G more open.

EPS-AKA vs 5G-AKA (AKA = Authentication and Key Agreement) for trusted nodes

EAP-AKA' for untrusted nodes.

Slice security is an important topic that multiple speakers touched upon and I think it would continue to be discussed for a foreseeable future.

Dr. Stan Wing S. Wong from King’s College London has some good slides on 5G security issues arising out of Multi-Tenancy and Multi-Network Slicing.

Peter Schneider from Nokia-Bell Labs had good slides on 5G Security Overview for Programmable Cloud-Based Mobile Networks

Sander Kievit from TNO, a regular participant of working group SA3 of 3GPP on behalf of the Dutch operator KPN presented a view from 3GPP SA3 on the Security work item progress (slides). The slide above highlights the changes in 5G key hierarchy.

The ITU 5G Security Workshop Outcomes is available here.

ETSI Security Week 2018 will be held 11-15 June 2018. 5G security/privacy is one of the topics.

There is also 5GPPP Workshop on 5G Networks Security (5G-NS 2018), being held in Hamburg, Germany on August 27-30, 2018.

In the meantime, please feel free to add your comments & suggestions below.


Related Posts & Further Reading:

• Introduction to 3GPP Security in Mobile Cellular Networks - 3G4G
• 5G Security Updates - July 2017 - 3G4G
• 3GPP 5G Specifications - 3G4G
• Tutorial: Service Based Architecture (SBA) for 5G Core (5GC) - 3G4G

Artificial Intelligence - Beyond SON for Autonomous Networks

What is the next step in evolution of SON? Artificial Intelligence obviously. The use of artificial intelligence (AI) techniques in the network supervisory system could help solve some of the problems of future network deployment and operation. ETSI has therefore set up a new 'Industry Specification Group' on 'Experiential Networked Intelligence' (ISG ENI) to develop standards for a Network Supervisory assistant system.

The ISG ENI focuses on improving the operator experience, adding closed-loop artificial intelligence mechanisms based on context-aware, metadata-driven policies to more quickly recognize and incorporate new and changed knowledge, and hence, make actionable decisions. ENI will specify a set of use cases, and the generic technology independent architecture, for a network supervisory assistant system based on the ‘observe-orient-decide-act’ control loop model. This model can assist decision-making systems, such as network control and management systems, to adjust services and resources offered based on changes in user needs, environmental conditions and business goals.

The introduction of technologies such as Software-Defined Networking (SDN), Network Functions Virtualisation (NFV) and network slicing means that networks are becoming more flexible and powerful. These technologies transfer much of the complexity in a network from hardware to software, from the network itself to its management and operation. ENI will make the deployment of SDN and NFV more intelligent and efficient and will assist the management and orchestration of the network.

We expect to complete the first phase of ENI work in 2019. It will include a description of use cases and requirements and terminology, including a definition of features, capabilities and policies, which we will publish in a series of informative best practice documents (Group Reports (GRs)).

This will of course require co-operation from many different industry bodies including GSMA, ITU-T, MEF, IETF, etc.

Will see how this goes.

Further reading:

• ETSI Presentation on ENI
• Network, All Intelligent. - ENI introduction, IETF

Tutorial: Service Based Architecture (SBA) for 5G Core (5GC)

As a continuation of 'Control and User Plane Separation of EPC nodes (CUPS) in 3GPP Release-14', here is another tutorial on Service Base Architecture (SBA) for the 5G Core.

The slides (with video) is embedded below but there are quite a few tutorials on 5G available on 3G4G page here.

Advanced: 5G Service Based Architecture (SBA) from 3G4G

Further Reading:

• Control and User Plane Separation of EPC nodes (CUPS) in 3GPP Release-14
• 3GPP 5G Specifications
• 5G - 3G4G Webpage
• 2G, 3G, 4G & 5G Training and Tutorial Videos - 3G4G Webpage

QUIC - Possibly in 5G, 3GPP Release-16

Over the last year or so, I have heard quite a few discussions and read many articles around why QUIC is so good and why we will replace TCP with QUIC (Quick UDP Internet Connection). One such article talking about QUIC benefits says:

QUIC was initially developed by Google as an alternative transport protocol to shorten the time it takes to set up a connection. Google wanted to take benefits of the work done with SPDY, another protocol developed by Google that became the basis for the HTTP/2 standard, into a transport protocol with faster connection setup time and built-in security. HTTP/2 over TCP multiplexes and pipelines requests over one connection but a single packet loss and retransmission packet causes Head-of-Line Blocking (HOLB) for the resources that were being downloaded in parallel. QUIC overcomes the shortcomings of multiplexed streams by removing HOLB. QUIC was created with HTTP/2 as the primary application protocol and optimizes HTTP/2 semantics.

What makes QUIC interesting is that it is built on top of UDP rather than TCP. As such, the time to get a secure connection running is shorter using QUIC because packet loss in a particular stream does not affect the other streams on the connection. This results in successfully retrieving multiple objects in parallel, even when some packets are lost on a different stream. Since QUIC is implemented in the userspace compared to TCP, which is implemented in the kernel, QUIC allows developers the flexibility of improving congestion control over time, since it can be optimized and better replaced compared to kernel upgrades (for example, apps and browsers update more often than OS updates).

Georg Mayer mentioned about QUIC in a recent discussion with Telecom TV. His interview is embedded below. Jump to 5:25 for QUIC part only

Georg Mayer, 3GPP CT work on 5G from 3GPPlive on Vimeo.

Below are some good references about QUIC in case you want to study further.

• IETF QUIC Charter
• Youtube: QUIC Next generation multiplexed transport over UDP - Google
• Understanding QUIC wire protocol - Anuradha Niroshan
• HTTP/2 and QUICK protocols. Optimizing the Web stack for HTTP/2 era
• Measuring QUIC vs TCP on mobile and desktop

5G Network Architecture, Design and Optimisation - Jan 2018

Prof. Andy Sutton, Principal Network Architect, Architecture & Strategy, TSO, BT, provided an update on 5G Network Architecture & Design last year which was also the most popular post of 2017 on 3G4G blog. This year again, he has delivered an update on the same topic at IET '5G - State of Play' conference. He has kindly shared the slides (embedded below) that are available to download from Slideshare.

5G Network Architecture, Design and Optimisation from 3G4G

The video of this talk as follows:


There are many valuable insights in this talk and the other talks from this conference. All the videos from the IET conference are available here and they are worth your time.

Related Links:

• [Video] The UK’s first end-to-end 5G network test - EE
• [Video] 5G Network Architecture Options - 3G4G
• [Video] Beginners: 5G Terminology - 3G4G
• 3GPP-VRIF workshop on Virtual Reality Ecosystem & Standards in 5G
• Ultra Reliable Low Latency Communications (URLLC) 2017 Conference summary

Control and User Plane Separation of EPC nodes (CUPS) in 3GPP Release-14

One of the items in 3GPP Rel-14 is Control and User Plane Separation of EPC nodes (CUPS). I have made a video explaining this concept that is embedded below.

In 3G networks (just considering PS domain), the SGSN and GGSN handles the control plane that is responsible for signalling as well as the user plane which is responsible for the user data. This is not a very efficient approach for deployment.

You can have networks that have a lot of signalling (remember signaling storm?) due to a lot of smartphone users but not necessarily consuming a lot of data (mainly due to price reasons). On the other hand you can have networks where there is not a lot of signalling but lot of data consumption. An example of this would be lots of data dongles or MiFi devices where users are also consuming a lot of data, because it’s cheap.

To cater for these different scenarios, the control plane and user plane was separated to an extent in the Evolved Packet Core (EPC). MME handles the control plane signalling while S-GW & P-GW handles the user plane

CUPS goes one step further by separating control & user plane from S-GW, P-GW & TDF. TDF is Traffic Detection Function which was introduced together with Sd reference point as means for traffic management in the Release 11. The Sd reference point is used for Deep Packet Inspections (DPI) purposes. TDF also provides the operators with the opportunity to capitalize on analytics for traffic optimization, charging and content manipulation and it works very closely with Policy and charging rules function, PCRF.

As mentioned, CUPS provides the architecture enhancements for the separation of S-GW, P-GW & TDF functionality in the EPC. This enables flexible network deployment and operation, by using either distributed or centralized deployment. It also allows independent scaling between control plane and user plane functions - while not affecting the functionality of the existing nodes subject to this split.

As the 3GPP article mentions, CUPS allows for:

• Reducing Latency on application service, e.g. by selecting User plane nodes which are closer to the RAN or more appropriate for the intended UE usage type without increasing the number of control plane nodes.
• Supporting Increase of Data Traffic, by enabling to add user plane nodes without changing the number of SGW-C, PGW-C and TDF-C in the network.
• Locating and Scaling the CP and UP resources of the EPC nodes independently.
• Independent evolution of the CP and UP functions.
• Enabling Software Defined Networking to deliver user plane data more efficiently.

The following high-level principles were also adopted for the CUPS:

• The CP function terminates the Control Plane protocols: GTP-C, Diameter (Gx, Gy, Gz).
• A CP function can interface multiple UP functions, and a UP function can be shared by multiple CP functions.
• An UE is served by a single SGW-CP but multiple SGW-UPs can be selected for different PDN connections. A user plane data packet may traverse multiple UP functions.
• The CP function controls the processing of the packets in the UP function by provisioning a set of rules in Sx sessions, i.e. Packet Detection Rules for packets inspection, Forwarding Action Rules for packets handling (e.g. forward, duplicate, buffer, drop), Qos Enforcement Rules to enforce QoS policing on the packets, Usage Reporting Rules for measuring the traffic usage.
• All the 3GPP features impacting the UP function (PCC, Charging, Lawful Interception, etc) are supported, while the UP function is designed as much as possible 3GPP agnostic. For example, the UPF is not aware of bearer concept.
• Charging and Usage Monitoring are supported by instructing the UP function to measure and report traffic usage, using Usage Reporting Rule(s). No impact is expected to OFCS, OCS and the PCRF.
• The CP or UP function is responsible for GTP-u F-TEID allocation.
• A legacy SGW, PGW and TDF can be replaced by a split node without effecting connected legacy nodes.

CUPS forms the basis of EPC architecture evolution for Service-Based Architecture for 5G Core Networks. More in another post soon.

A short video on CUPS below, slides available here.



Further reading:

• 3GPP: Control and User Plane Separation of EPC nodes (CUPS)
• ITU: 5G Network Architecture and FMC - Joe Wilke, Ericsson
• Heavy Reading: Service-Based Architecture for 5G Core Networks

5G NR Radio Protocols and Tight Inter-working with LTE

Osman Yilmaz, Team Leader & Senior Researcher at Ericsson Research in Finland gave a good summary of 5G NR at URLLC 2017 Conference (see summary here). His presentation is embedded below:

5G NR radio protocols to support URLLC from 3G4G

Osman, along with Oumer Teyeb, Senior Researcher at Ericsson Research & member of the Ericsson 5G standardization delegation has also published a blog post LTE-NR tight-interworking on Ericsson Research blog.

The post talks about how how signalling and data will work in LTE & New Radio (NR) dual connected devices. In control plane it looks at RRC signalling applicable for this DC devices whereas in user plane it looks at direct and split DRB options.

Further details here.

A practical use of MOCN in ESN

Just came across this slide from recent DAS & Small Cells Congress where EE talked about their ESN network development. Found this particular example interesting as they talk about how the commercial user and ESN user would use the same RAN but a different core.

This ties nicely with a recent tutorial that I did on Mobile Network Sharing options. If you would like to learn more, see here.

Related Post (added 23 March 2019)

• Update on UK's Emergency Services Network (ESN) from BAPCO 2019

Quick tutorial on Mobile Network Sharing Options

Here is a quick tutorial on mobile network sharing approaches, looking at site/mast sharing, MORAN, MOCN and GWCN. Slides and video embedded below. If for some reason you prefer direct link to video, its here.

Mobile Network Sharing from 3G4G

See also:

• Telecoms Infrastructure Blog: Passive and Active Infrastructure Sharing
• Telecoms Infrastructure Blog: Small Cells Network Sharing
• The 3G4G Blog: Network Sharing is becoming more relevant with 5G
• The 3G4G Blog: A practical use of MOCN in ESN

5G Architecture Options for Deployments?

I have blogged earlier about the multiple 5G Architecture options that are available (see Deutsche Telekom's presentation & 3G4G video). So I have been wondering what options will be deployed in real networks and when.

The 3GPP webinar highlighted that Option-3 would be the initial focus, followed by Option 2.

Last year AT&T had proposed the following 4 approaches as in the picture above. Recall that Option 1 is the current LTE radio connected to EPC.

ZTE favours Deployment option 2 as can be seen in the slide above

Huawei is favoring Option 3, followed by Option 7 or 2 (& 5)

Going back to the original KDDI presentation, they prefer Option 3, followed by Option 7.

If you are an operator, vendor, analyst, researcher, or anyone with an opinion, what options do you prefer?