Showing posts with label Network Architecture. Show all posts
Showing posts with label Network Architecture. Show all posts

Thursday, 12 July 2018

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.

Monday, 11 June 2018

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:

Sunday, 25 March 2018

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.

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:

Tuesday, 13 February 2018

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:



Friday, 9 February 2018

Tuesday, 6 February 2018

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.

Thursday, 25 January 2018

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.



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:

Monday, 18 December 2017

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:


Thursday, 23 November 2017

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:



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.

Tuesday, 21 November 2017

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.

Thursday, 9 November 2017

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 with video embedded below. If for some reason you prefer direct link to video, its here.



See also:

Monday, 23 October 2017

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?

Sunday, 3 September 2017

5G Core Network, System Architecture & Registration Procedure

The 5G System architecture (based on 3GPP TS 23.501: System Architecture for the 5G System; Stage 2) consists of the following network functions (NF). The functional description of these network functions is specified in clause 6.
- Authentication Server Function (AUSF)
- Core Access and Mobility Management Function (AMF)
- Data network (DN), e.g. operator services, Internet access or 3rd party services
- Structured Data Storage network function (SDSF)
- Unstructured Data Storage network function (UDSF)
- Network Exposure Function (NEF)
- NF Repository Function (NRF)
- Network Slice Selection Function (NSSF)
- Policy Control function (PCF)
- Session Management Function (SMF)
- Unified Data Management (UDM)
- Unified Data Repository (UDR)
- User plane Function (UPF)
- Application Function (AF)
- User Equipment (UE)
- (Radio) Access Network ((R)AN)

As you can see, this is slightly more complex than the 2G/3G/4G Core Network Architecture.

Alan Carlton, Vice President, InterDigital and Head of InterDigital International Labs Organization spanning Europe and Asia provided a concise summary of the changes in 5G core network in ComputerWorld:

Session management is all about the establishment, maintenance and tear down of data connections. In 2G and 3G this manifested as the standalone General Packet Radio Service (GPRS). 4G introduced a fully integrated data only system optimized for mobile broadband inside which basic telephony is supported as just one profile.

Mobility management as the name suggests deals with everything that needs doing to support the movement of users in a mobile network. This encompasses such functions as system registration, location tracking and handover. The principles of these functions have changed relatively little through the generations beyond optimizations to reduce the heavy signaling load they impose on the system.

The 4G core network’s main function today is to deliver an efficient data pipe. The existence of the service management function as a dedicated entity has been largely surrendered to the “applications” new world order. Session management and mobility management are now the two main functions that provide the raison d’etre for the core network.

Session management in 4G is all about enabling data connectivity and opening up a tunnel to the world of applications in the internet as quickly as possible. This is enabled by two core network functions, the Serving Gateway (SGW) and Packet Data Gateway (PGW). Mobility management ensures that these data sessions can be maintained as the user moves about the network. Mobility management functions are centralized within a network node referred to as Mobility Management Entity (MME). Services, including voice, are provided as an “app” running on top of this 4G data pipe. The keyword in this mix, however, is “function”. It is useful to highlight that the distinctive nature of the session and mobility management functions enables modularization of these software functions in a manner that they can be easily deployed on any Commercial-Off-The-Shelf (COTS) hardware.

The biggest change in 5G is perhaps that services will actually be making a bit of a return...the plan is now to deliver the whole Network as a Service. The approach to this being taken in 3GPP is to re-architect the whole core based on a service-oriented architecture approach. This entails breaking everything down into even more detailed functions and sub-functions. The MME is gone but not forgotten. Its former functionality has been redistributed into precise families of mobility and session management network functions. As such, registration, reachability, mobility management and connection management are all now new services offered by a new general network function dubbed Access and Mobility Management Function (AMF). Session establishment and session management, also formerly part of the MME, will now be new services offered by a new network function called the Session Management Function (SMF). Furthermore, packet routing and forwarding functions, currently performed by the SGW and PGW in 4G, will now be realized as services rendered through a new network function called the User Plane Function (UPF).

The whole point of this new architectural approach is to enable a flexible Network as a Service solution. By standardizing a modularized set of services, this enables deployment on the fly in centralized, distributed or mixed configurations to enable target network configurations for different users. This very act of dynamically chaining together different services is what lies at the very heart of creating the magical network slices that will be so important in 5G to satisfy the diverse user demands expected. The bottom line in all this is that the emphasis is now entirely on software. The physical boxes where these software services are instantiated could be in the cloud or on any targeted COTS hardware in the system. It is this intangibility of physicality that is behind the notion that the core network might disappear in 5G.


3GPP TS 23.502: Procedures for the 5G System; Stage 2, provides examples of signalling for different scenarios. The MSC above shows the example of registration procedure. If you want a quick refresher of LTE registration procedure, see here.

I dont plan to expand on this procedure here. Checkout section "4.2.2 Registration Management procedures" in 23.502 for details. There are still a lot of FFS (For further studies 😉) in the specs that will get updated in the coming months.


Further Reading:

Monday, 19 June 2017

Network Sharing is becoming more relevant with 5G

5G is becoming a case of 'damned if you do damned if you don't'. Behind the headlines of new achievements and faster speeds lies the reality that many operators are struggling to keep afloat. Indian and Nigerian operators are struggling with heavy debt and it wont be a surprise if some of the operators fold in due course.

With increasing costs and decreasing revenues, its no surprise that operators are looking at ways of keeping costs down. Some operators are postponing their 5G plans in favour of Gigabit LTE. Other die hard operators are pushing ahead with 5G but looking at ways to keep the costs down. In Japan for example, NTT DOCOMO has suggested sharing 5G base stations with its two rivals to trim costs, particularly focusing efforts in urban areas.


In this post, I am looking to summarise an old but brilliant post by Dr. Kim Larsen here. While it is a very well written and in-depth post, I have a feeling that many readers may not have the patience to go through all of it. All pictures in this post are from the original post by Dr. Kim Larsen.


Before embarking on any Network sharing mission, its worthwhile asking the 5W's (Who, Why, What, Where, When) and 2H's (How, How much).

  • Why do you want to share?
  • Who to share with? (your equal, your better or your worse).
  • What to share? (sites, passives, active, frequencies, new sites, old sites, towers, rooftops, organization, ,…).
  • Where to share? (rural, sub-urban, urban, regional, all, etc..).
  • When is a good time to start sharing? During rollout phase, steady phase or modernisation phase. See picture below. For 5G, it would make much more sense that network sharing is done from the beginning, i.e., Rollout Phase


  • How to do sharing?. This may sound like a simple question but it should take account of regulatory complexity in a country. The picture below explains this well:



  • How much will it cost and how much savings can be attained in the long term? This is in-fact a very important question because the end result after a lot of hard work and laying off many people may result in an insignificant amount of cost savings. Dr. Kim provides detailed insight on this topic that I find it difficult to summarise. Best option is to read it on his blog.


An alternative approach to network sharing is national roaming. Many European operators are dead against national roaming as this means the network loses its differentiation compared to rival operators. Having said that, its always worthwhile working out the savings and seeing if this can actually help.

National Roaming can be attractive for relative low traffic scenarios or in case were product of traffic units and national roaming unit cost remains manageable and lower than the Shared Network Cost.

The termination cost or restructuring cost, including write-off of existing telecom assets (i.e., radio nodes, passive site solutions, transmission, aggregation nodes, etc….) is likely to be a substantially financial burden to National Roaming Business Case in an area with existing telecom infrastructure. Certainly above and beyond that of a Network Sharing scenario where assets are being re-used and restructuring cost might be partially shared between the sharing partners.

Obviously, if National Roaming is established in an area that has no network coverage, restructuring and termination cost is not an issue and Network TCO will clearly be avoided, Albeit the above economical logic and P&L trade-offs on cost still applies.

If this has been useful to understand some of the basics of network sharing, I encourage you to read the original blog post as that contains many more details.

Futher Reading:



Friday, 12 May 2017

5G – Beyond the Hype

Dan Warren, former GSMA Technology Director who created VoLTE and coined the term 'Phablet' has been busy with his new role as Head of 5G Research at Samsung R&D in UK. In a presentation delivered couple of days back at Wi-Fi Global Congress he set out a realistic vision of 5G really means.

A brief summary of the presentation in his own words below, followed by the actual presentation:
"I started with a comment I have made before – I really hate the term 5G.  It doesn’t allow us to have a proper discussion about the multiplicity of technologies that have been throw under the common umbrella of the term, and hence blurs the rationale for one why each technology is important in its own right.  What I have tried to do in these slides is talk more about the technology, then look at the 5G requirements, and consider how each technology helps or hinders the drive to meet those requirements, and then to consider what that enables in practical terms.

The session was titled ‘5G – beyond the hype’ so in the first three slides I cut straight to the technology that is being brought in to 5G.  Building from the Air Interface enhancements, then the changes in topology in the RAN and then looking at the ‘softwarisation’ on the Core Network.  This last group of technologies sets up the friction in the network between the desire to change the CapEx model of network build by placing functions in a Cloud (both C-RAN and an NFV-based Core, as well as the virtualisation of transport network functions) and the need to push functions to the network edge by employing MEC to reduce latency.  You end up with every function existing everywhere, data breaking out of the network at many different points and some really hard management issues.

On slide 5 I then look at how these technologies line up to meeting 5G requirements.  It becomes clear that the RAN innovations are all about performance enhancement, but the core changes are about enabling new business models from flexibility in topology and network slicing.  There is also a hidden part of the equation that I call out, which is that while technology enables the central five requirements to be met, they also require massive investment by the Operator.  For example you won’t reach 100% coverage if you don’t build a network that has total coverage, so you need to put base stations in all the places that they don’t exist today.

On the next slide I look at how network slicing will be sold.  There are three ways in which a network might be sliced – by SLA or topology, by enterprise customer and by MVNO.  The SLA or topology option is key to allowing the co-existence of MEC and Cloud based CN.  The enterprise or sector based option is important for operators to address large vertical industry players, but each enterprise may want a range of SLA’s for different applications and devices, so you end up with an enterprise slice being made up of sub-slices of differing SLA and topology.  Then, an MVNO may take a slice of the network, but will have it’s own enterprise customers that will take a sub-slice of the MVNO slice, which may in turn be made of sub-sub-slices of differing SLAs.  Somewhere all of this has be stitched back together, so my suggestion is that ‘Network Splicing’ will be as important as network slicing.

Slide illustrates all of this again and notes that there will also be other networks that have been sliced as well, be that 2G, 3G, 4G, WiFi, fixed, LPWA or anything else.  There is also going to be an overarching orchestration requirement both within a network and in the Enterprise customer (or more likely in System Integrator networks who take on the ‘Splicing’ role).  The red flags are showing that Orchestration is both really difficult and expensive, but the challenge for the MNO will also exist in the RAN.  The RRC will be a pinch point that has to sort out all of these device sitting in disparate network topologies with varying demands on the sliced RAN.

Then, in the next four slides I look at the business model around this.  Operators will need to deal with the realities of B2B or B2B2C business models, where they are the first B. The first ‘B’s price is the second ‘B’s cost, so the operator should expect considerable pressure on what it charges, and to be held contractually accountable for the performance of the network.  If 5G is going to claim 100% coverage, 5 9’s reliability, 50Mbps everywhere and be sold to enterprise customers on that basis, it is going to have to deliver it else there will be penalties to pay.  On the flip side to this, if all operators do meet the 5G targets, then they will become very much the same so the only true differentiation option will be on price.  With the focus on large scale B2B contracts, this has all the hallmarks of a race downwards and commoditisation of connectivity, which will also lead to disintermediation of operators from the value chain on applications.

So to conclude I pondered on what the real 5G justification is.  Maybe operators shouldn’t be promising everything, since there will be healthy competition on speed, coverage and reliability while those remain as differentiators.  Equally, it could just be that operators will fight out the consumer market share on 5G, but then that doesn’t offer any real uplift in market size, certainly not in mature developed world markets.  The one thing that is sure is that there is a lot of money to be spent getting there."



Let me know what do you think?

Thursday, 20 April 2017

5G: Architecture, QoS, gNB, Specifications - April 2017 Update


The 5G NR (New Radio) plan was finalised in March (3GPP press release) and as a result Non-StandAlone (NSA) 5G NR will be finalised by March 2018. The final 3GPP Release-15 will nevertheless include NR StandAlone (SA) mode as well.

NSA is based on Option 3 (proposed by DT). If you dont know much about this, then I suggest listening to Andy Sutton's lecture here.


3GPP TR 38.804: Technical Specification Group Radio Access Network; Study on New Radio Access Technology; Radio Interface Protocol Aspects provides the overall architecture as shown above

Compared to LTE the big differences are:

  • Core network control plane split into AMF and SMF nodes (Access and Session Management Functions). A given device is assigned a single AMF to handle mobility and AAA roles but can then have multiple SMF each dedicated to a given network slice
  • Core network user plane handled by single node UPF (User Plane Function) with support for multiple UPF serving the same device and hence we avoid need for a common SGW used in LTE. UPF nodes may be daisy chained to offer local breakout and may have parallel nodes serving the same APN to assist seamless mobility.

Hat tip Alistair Urie.
Notice that like eNodeB (eNB) in case of LTE, the new radio access network is called gNodeB (gNB). Martin Sauter points out in his excellent blog that 'g' stands for next generation.

3GPP TS 23.501: Technical Specification Group Services and System Aspects; System Architecture for the 5G System; Stage 2 provides architecture model and concepts including roaming and non-roaming architecture. I will probably have to revisit as its got so much information. The QoS table is shown above. You will notice the terms QFI (QoS Flow Identity) & 5QI (5G QoS Indicator). I have a feeling that there will be a lot of new additions, especially due to URLLC.

Finally, here are the specifications (hat tip Eiko Seidel for his excellent Linkedin posts - references below):
5G NR will use 38 series (like 25 series for 3G & 36 series for 4G).

RAN3 TR 38.801 v2.0.0 on Study on New Radio Access Technology; Radio Access Architecture and Interfaces

RAN1 TR 38.802 v2.0.0 on Study on New Radio (NR) Access Technology; Physical Layer Aspects

RAN4 TR 38.803 v2.0.0 on Study on New Radio Access Technology: RF and co-existence aspects

RAN2 TR 38.804 v1.0.0 on Study on New Radio Access Technology; Radio Interface Protocol Aspects

38.201 TS Physical layer; General description
38.211 TS Physical channels and modulation
38.212 TS Multiplexing and channel coding
38.213 TS Physical layer procedures
38.214 TS Physical layer measurements
38.21X TS Physical layer services provided to upper layer
38.300 TS Overall description; Stage-2
38.304 TS User Equipment (UE) procedures in idle mode
38.306 TS User Equipment (UE) radio access capabilities
38.321 TS Medium Access Control (MAC) protocol specification
38.322 TS Radio Link Control (RLC) protocol specification
38.323 TS Packet Data Convergence Protocol (PDCP) specification
38.331 TS Radio Resource Control (RRC); Protocol specification
37.3XX TS [TBD for new QoS]
37.3XX TS Multi-Connectivity; Overall description; Stage-2
38.401 TS Architecture description
38.410 TS NG general aspects and principles
38.411 TS NG layer 1
38.412 TS NG signalling transport
38.413 TS NG Application Protocol (NGAP)
38.414 TS NG data transport
38.420 TS Xn general aspects and principles
38.421 TS Xn layer 1
38.422 TS Xn signalling transport
38.423 TS Xn Application Protocol (XnAP)
38.424 TS Xn data transport
38.425 TS Xn interface user plane protocol
38.101 TS User Equipment (UE) radio transmission and reception
38.133 TS Requirements for support of radio resource management
38.104 TS Base Station (BS) radio transmission and reception
38.307 TS Requirements on User Equipments (UEs) supporting a release-independent frequency band
38.113 TS Base Station (BS) and repeater ElectroMagnetic Compatibility (EMC)
38.124 TS Electromagnetic compatibility (EMC) requirements for mobile terminals and ancillary equipment
38.101 TS User Equipment (UE) radio transmission and reception
38.133 TS Requirements for support of radio resource management
38.104 TS Base Station (BS) radio transmission and reception
38.141 TS Base Station (BS) conformance testing

Note that all specifications are not in place yet. Use this link to navigate 3GPP specs: http://www.3gpp.org/ftp/Specs/archive/38_series/

Further reading: