Tuesday 16 November 2021

5G-Advanced Flagship Features

I am starting to get a feeling that people may be becoming overwhelmed with all the new 5G features and standards update. That is why this presentation by Mikael Höök, Director Radio Research at Ericsson, at Brooklyn 6G Summit (B6GS) caught my attention. 

The talk discusses the network infrastructure progress made in the previous two years to better illustrate the advanced 5G timeline to discovering 6G requirements. At the end of the talk, there was a quick summary of the four flagship features that are shown in the picture above. The talk is embedded below, courtesy of IEEE TV

In addition to this talk, October 2021 issue of Ericsson Technology Review covers the topic "5G evolution toward 5G advanced: An overview of 3GPP releases 17 and 18". You can get the PDF here.

I have covered the basics of these flagship features in the following posts:

Please feel free to add your thoughts as comments below.

Related Posts

Thursday 11 November 2021

Network Slicing using User Equipment Route Selection Policy (URSP)

Google announced that its latest smartphone OS will include support for 5G network slicing. Last week Telecom TV brought this news to my attention. The article explains:

It's a move designed to leverage its expertise in devices in order to give it the edge over its rival hyperscalers.

It comes in two flavours. The first is for enterprise-owned handsets, and routes all data sent and received by a device over the network slices provided by that company's mobile operator. Android 12 gives operators the ability to manage slices using a new dynamic policy control mechanism called User Equipment Route Selection Policy (URSP). URSP enables devices to automatically switch between different network slices according to which application they are using. For example, someone working for a financial institution might require a highly-secure network slice for sending and receiving sensitive corporate data, but will then require a reliable, high-throughput, low-latency slice so they can participate in a video meeting.

The second flavour is implemented in the work profile. For years, enterprises have had the option of creating work profiles on Android devices – irrespective of whether they are owned by the organisation or the individual – to use as a separate repository for enterprise apps and data. When Android 12 comes out next year, enterprises will be able to route data to and from that repository over a network slice.

Google said it has already carried out network slicing tests with both Ericsson and Nokia using test versions of its recently released Pixel 6 smartphone running on the as-yet-unreleased Android 12 OS.

Last week Taiwanese operator Far EasTone (FET) and Ericsson announced they have completed the world’s first proof of concept (PoC) for simultaneously connecting multiple network slices per device running on Android 12 commercial release. The press release said:

The trial, carried out on FET’s 5G standalone (SA) infrastructure built on Ericsson’s radio access network and cloud-native Core network, successfully demonstrated the 5G user equipment slicing policy feature (User Equipment Route Selection Policy, or URSP) on multiple Android devices. This marks a breakthrough in network slicing capabilities on a 5G standalone network and paves the way for further ecosystem development in this important area.

With more 5G networks evolving to standalone architecture around the globe, end-to-end network slicing, which includes Ericsson RAN Slicing to secure Quality of Service (QoS) differentiation, plays a key role in enabling new services for end users, with which multiple virtual 5G networks are created on top of one physical network. The 5G trial, in collaboration with FET, Ericsson and Android, went even further in network slicing capabilities by introducing and demonstrating 5G user equipment (UE) slicing policy (URSP) features that allow devices to simultaneously operate on dynamic policy control and selection between multiple 5G network slices. This enables the steering of applications and services with specific requirements to defined slices without switching devices.

Multiple slices allow devices to have multiple profiles to secure different levels of experience, security, and privacy requirements, based on the needs of the different applications and in correspondence with the user profile.  For instance, a device can have a personal profile with private data from apps or off-work entertainment, and a work profile with enterprises productivity apps. With URSP features, employers can customize the work profile with increased security and enable better use of RAN Slicing with QoS so that enterprise-related apps can work even during network congestion.

Some security-sensitive apps, such as mobile banking, can also benefit from different routing mechanisms of the traffic enabled by URSP. For instance, the banking app would not need to send its traffic to the internet and then to the app server as it does today. Instead, it could go straight to the app server and avoid the routing through internet. With the shortest route by connecting to a defined slice, users could reduce the risk of being attacked by hackers.

In their technical whitepaper on Network Slicing, Samsung explains: 

Along with the concept of network slicing and features in the RAN and Core network, UE Route Selection Policy (URSP) is introduced as a way to manage network slice information for the UE. URSP is a network slice feature enabled by the PCF which informs the network slice status to the UE via the AMF. In 4G network systems, it was near impossible to install new services in the network for a UE. But through the URSP feature, 5G network operators can easily configure new service for a UE. Figure 12 (top of this blog post) shows the difference in network slice selection in 4G and 5G Network. In 5G network, slice selection policy can be configured dynamically through URSP, while slice selection policy is pre-defined and cannot be changed dynamically in 4G network.

URSP contains OSId, AppId, IP descriptors to define the application and Single-Network Slice Selection Assistance Information (S-NSSAI), Data Network Name (DNN), Session and Service Continuity (SSC) mode information for the application and network slice mapping.

The S-NSSAI identifies each network slice service and provides information to properly assign network slice/functions. An S-NSSAI is comprised of:

  • A Slice/Service type (SST), which refers to the expected network slice behavior in terms of features and services;
  • A Slice Differentiator (SD), which is an optional information that complements the Slice/Service type(s) to differentiate amongst multiple network slices of the same Slice/Service type.

3GPP allows the use of the Slice Differentiator (SD) field that can build customized network slices. The SD field can be used to describe services, customer information and priority.

Here is a short video from Mpirical explaining 5G UE Route Selection.

It it worth reminding here that this feature, like many of the other 5G features, is dependent on 5G Core. We hope that the transition to 5G Standalone Networks happens as soon as possible.

Related Posts:

Thursday 4 November 2021

Voice over New Radio (VoNR) Establishment and Release between NG RAN and 5G Core

In this video I explain how QoS Flows for VoNR are established and released especially on N2 reference point between 5G Core and NG RAN.

The pervious video about generic aspects of "QoS Flow Establishments in 5G Standalone RAN and Core" you will find in the first link of the Related Posts listed below:

Tuesday 2 November 2021

Energy Consumption in Mobile Networks and RAN Power Saving Schemes

We just made a tutorial on this topic looking at where most of the power consumption in the mobile network occurs and some of the ways this power consumption can be reduced. 

The chart in the Tweet above (also in the presentation) clearly shows that the energy costs for operators run in many millions. Small power saving schemes can still have a big impact on the total energy reduction, thereby saving huge amounts of energy and costs.

The March issue of ZTE Communications Magazine contains some good articles looking at how to tackle the energy challenges in the network going forward. This recent article by Ericsson is also a good source of information on this topic.

Anyway, the slides and the video of the tutorial is embedded below:

Related Posts:

Tuesday 26 October 2021

An Early View of 3GPP Release-18 5G-Advanced Topics

5G is hot at the moment. While the operators are busy rolling out the networks based on Release-15/16 features, 3GPP is working on finalising Release-17 specifications and laying the foundations for Rel-18.

The latest issue of 3GPP Highlights magazine (I prefer the PDF) contains a lot of valuable technical content, in addition to many other articles. The technical content includes:

  • An early view of the RAN Topics for 5G-Advanced
  • 5G Advanced in the Making – The TSG SA approach to Release 18
  • Application Enablement Standards in 3GPP – Maximizing the potential of 5G!
  • RAN3 flourishing in this time of change
  • Enhanced support of Industrial IoT in the 5G System (Rel-17)
  • Autonomous Network standardization in WG SA5
  • Rel-17 Edge Computing and Network Slicing charging (WG SA 5)
  • Media Production over 5G NPN

While I am not going into too much detail here, I want to highlight the 5G-Advanced topics that will be under discussion over the next couple of months. The final list will be approved by 3GPP TSGs SA, RAN and CT in December 2021.

Dr. Wanshi Chen, 3GPP TSG RAN Chair provided an early view of the RAN topics for 5G-Advanced. 

Topics Under Discussion

As well as taking a tentative decision on an 18-month duration for Release 18, the RAN workshop endorsed a list of topics for subsequent email discussions. Some of the topics in the following list also have a set of example areas, serving as a starting point for further refinement:

  • Evolution for downlink MIMO, with the following example areas:
    • Further enhancements for CSI (e.g., mobility, overhead, etc.)
    • Evolved handling of multi-TRP (Transmission Reception Points) and multi-beam
    • CPE (customer premises equipment) -specific considerations
  • Uplink enhancements, with the following example areas:
    • >4 Tx operation
    • Enhanced multi-panel/multi-TRP uplink operation
    • Frequency-selective precoding
    • Further coverage enhancements
  • Mobility enhancements, with the following example areas:
    • Layer 1/layer 2 based inter cell mobility
    • DAPS (Dual Active Protocol Stack)/CHO (Conditional HandOver) related improvements
    • FR2 (frequency range 2)-specific enhancements
  • Additional topological improvements (IAB and smart repeaters), with the following example areas:
    • Mobile IAB (Integrated Access Backhaul)/Vehicle mounted relay (VMR)
    • Smart repeater with side control information
  • Enhancements for XR (eXtended Reality), with the following example areas:
    • KPIs/QoS, application awareness operation, and aspects related to power consumption, coverage, capacity, and mobility
      • Note: only power consumption/coverage/mobility aspects specific to XR
  • Sidelink enhancements (excluding positioning), with the following example areas:
    • SL enhancements (e.g., unlicensed, power saving enhancements, efficiency enhancements, etc.)
    • SL relay enhancements
    • Co-existence of LTE V2X & NR V2X
  • RedCap evolution (excluding positioning), with the following example areas:
    • New use cases and new UE bandwidths (5MHz?)
    • Power saving enhancements
  • NTN (Non-Terrestrial Networks) evolution
    • Including both NR & IoT (Internet of Things) aspects
  • Evolution for broadcast and multicast services
    • Including both LTE based 5G broadcast and NR MBS (Multicast Broadcast Services)
  • Expanded and improved Positioning, with the following example areas:
    • Sidelink positioning/ranging
    • Improved accuracy, integrity, and power efficiency
    • RedCap positioning
  • Evolution of duplex operation, with the following example areas:
    • Deployment scenarios, including duplex mode (TDD only?)
    • Interference management
  • AI (Artificial Intelligence)/ML (Machine Learning), with the following example areas:
    • Air interface (e.g., Use cases to focus, KPIs and Evaluation methodology, network and UE involvement, etc.)
    • NG-RAN
  • Network energy savings, with the following example areas:
    • KPIs and evaluation methodology, focus areas and potential solutions
  • Additional RAN1/2/3 candidate topics, Set 1:
    • UE power savings
    • Enhancing and extending the support beyond 52.6GHz
    • CA (Carrier Aggregation)/DC (Dual-Connectivity) enhancements (e.g., MR-MC (Multi-Radio/Multi-Connectivity), etc.)
    • Flexible spectrum integration
    • RIS (Reconfigurable Intelligent Surfaces)
    • Others (RAN1-led)
  • Additional RAN1/2/3 candidate topics, Set 2:
    • UAV (Unmanned Aerial Vehicle)
    • IIoT (Industrial Internet of Things)/URLLC (Ultra-Reliable Low-Latency Communication)
    • <5MHz in dedicated spectrum
    • Other IoT enhancements/types
    • HAPS (High Altitude Platform System)
    • Network coding
  • Additional RAN1/2/3 candidate topics, Set 3:
    • Inter-gNB coordination, with the following example areas:
      • Inter-gNB/gNB-DU multi-carrier operation
      • Inter-gNB/gNB-DU multi-TRP operation
      • Enhancement for resiliency of gNB-CU
    • Network slicing enhancements
    • MUSIM (Multiple Universal Subscriber Identity Modules)
    • UE aggregation
    • Security enhancements
    • SON (Self-Organizing Networks)/MDT (Minimization of Drive Test)
    • Others (RAN2/3-led)
  • Potential RAN4 enhancements

Dr. Georg Mayer, 3GPP TSG SA Chair provides the TSG SA approach to 3GPP Release-18

The candidate items for Rel-18 include:

  • Immersive Media and Virtual/Artificial/Extended Reality (XR) Media support in Working Group (WG) SA4 and WG SA2.
  • New work areas for Internet of Things (e.g. passive IoT (WG SA2) and application capability exposure for IoT platforms (WG SA6)).
  • Proposals to for Artificial Intelligence and Machine Learning Services Transport and Management (WGs SA2, SA5).
  • Concepts for integration and migration of existing vertical infrastructure, e.g. for railway networks (WG SA6).
  • Examples for proposed enhancements to existing 3GPP services and functionalities include:
    • Network Slicing (WGs SA2, SA5)
    • Edge Computing (WGs SA2, SA5, SA6)
    • Autonomous Networks (WG SA5)
    • Service Based Architecture (WGs SA2, SA5)
    • Northbound APIs (WG SA6)
    • Non-Public Networks (WG SA2)
    • Satellite 5G Networks (WG SA2)
    • Drone support (WG SA2)
    • 5G Multicast and Broadcast (WG SA2)
    • Location Services (WG SA2, SA6)
    • Management Data Analytics (WG SA5)
    • Mission Critical Services (WG SA6)

None of these features are final but we will know in the next few months what will be included as part of Rel-18 and what won't. In the meantime, do check out the latest issue of 3GPP Highlights here.

Related Posts

Wednesday 20 October 2021

5G NR-Unlicensed (NR-U)

I have been talking about unlicensed LTE since 2013. With all the debate around LTE-U and LAA now non-existent, the technology has evolved with every new release. As can be seen from this picture by Ericsson above, 5G NR-U in Release-16 supports:

  • License-exempt Downlink (DL)
  • License-exempt scheduled Uplink (UL)
  • License-exempt autonomous UK
  • Standalone license-exempt operation

The Release-16 work item summary details the following deployment scenarios for NR-based access to unlicensed spectrum:

  • Scenario A: Carrier aggregation between NR in licensed spectrum (PCell) and NR in shared spectrum (SCell);
    • A.1: SCell is not configured with UL (DL only); 
    • A.2: SCell is configured with UL (DL+UL). 
  • Scenario B: Dual connectivity between LTE in licensed spectrum and NR in shared spectrum (PSCell);
  • Scenario C: NR in shared spectrum (PCell);
  • Scenario D: NR cell in shared spectrum and uplink in licensed spectrum;
  • Scenario E: Dual connectivity between NR in licensed spectrum (PCell) and NR in shared spectrum (PSCell)

5G New Radio Unlicensed: Challenges and Evaluation, available on arXiv here provides a lot of useful information on different kind of operations within the unlicensed band and the challenges of co-existence with Wi-Fi

Finally, Qualcomm has quite a few resources on this topic. Last year, they hosted a webinar on the topic, "How does unlicensed spectrum with NR-U transform what 5G can do for you?". The slides from that are available here and a video of that is available here. RCR Wireless also has this short article from one of the webinar presenters here.

Related Posts

Tuesday 12 October 2021

Monday 4 October 2021

Are there 50 Billion IoT Devices yet?

Detailed post below but if you are after a quick summary, it's in the picture above.

Couple of weeks back someone quoted that there were 50 billion devices last year (2020). After challenging them on the number, they came back to me to say that there were over 13 billion based on GSMA report. While the headline numbers are correct, there are some finer details we need to look at.

It all started back in 2010 when the then CEO of Ericsson announced that there will be 50 Billion IoT Devices by 2020. You could read all about it here and see the presentation here. While it doesn't explicitly say, it was expected that the majority of these will be based on cellular technologies. I also heard the number 500 Billion by 2030, back in 2013.

So the question is how many IoT devices are there today and how many of these are based on mobile cellular technologies?

The headline number provided by the GSMA Mobile Economy report, published just in time for MWC 2021, is 13.1 billion in 2020. It does not provide any further details on what kind of connectivity these devices use. I had to use my special search skills to find the details here.

As you can see, only 1.9 billion of these are based on cellular connections, of which 0.2 billion are based on licensed Low Power Wide Area (licensed LPWA, a.k.a. LTE-M and NB-IoT) connections. 

Ericsson Mobility Report, June 2021, has a much more detailed breakdown regarding the numbers as can be seen in the slide above. As of the end of 2020, there were 12.4 billion IoT devices, of which 10.7 billion were based on Short-range IoT. Short-range IoT is defined as a segment that largely consists of devices connected by unlicensed radio technologies, with a typical range of up to 100 meters, such as Wi-Fi, Bluetooth and Zigbee.

Wide-area IoT, which consists of segment made up of devices using cellular connections or unlicensed low-power technologies like Sigfox and LoRa had 1.7 billion devices. So, the 1.6 billion cellular IoT devices also includes LPWAN technologies like LTE-M and NB-IoT.

I also reached out to IoT experts at analyst firm Analysys Mason. As you can see in the Tweet above, Tom Rebbeck, Partner at Analysys Mason, mentioned 1.6 billion cellular (excluding NB-IoT + LTE-M) and 220 million LPWA (which includes NB-IoT, LTE-M, as well as LoRa, Sigfox etc.) IoT connections.

I also noticed this interesting chart in the tweet above which shows the growth of IoT from Dec 2010 until June 2021. Matt Hatton, Founding Partner of Transforma Insights, kindly clarified that the number as 1.55 billion including NB-IoT and LTE-M.

As you can see, the number of cellular IoT connections are nowhere near 50 billion. Even if we include all kinds of IoT connectivity, according to the most optimistic estimate by Ericsson, there will be just over 26 billion connections by 2026.

Just before concluding, it is worth highlighting that according to all these cellular IoT estimates, over 1 billion of these connections are in China. GSMA's 'The Mobile Economy China 2021' puts the number as 1.34 billion as of 2020, growing to 2.29 billion by 2025. Details on page 9 here.

Hopefully, when someone wants to talk about Internet of Thing numbers in the future, they will do a bit more research or just quote the numbers from this post here.

Related Posts

Monday 27 September 2021

Maritime Communication (MARCOM) Services over 3GPP system


Maritime Communication Services over 3GPP System is one of the topics listed in the 3GPP Release-16 summary that I summarised here.

Maritime domain, one of 5G vertical domains in 3GPP, started to be considered since 2016 to enable 3GPP systems to play the role of mobile communication platform necessary for the digitalization and mobilization of the maritime domain that bring about the Fourth Industrial Revolution of the maritime businesses as well as maritime safety.

Compared to other vertical domains, the maritime domain has the radio communication environment that 3GPP hasn’t considered in detail, which means that maritime related issues and features were not in the scope of 3GPP standardization and some of existing 3GPP enabling technologies or solutions are not able to fully support the optimized performances required by the maritime domain in a way that has been guaranteed for on-land communication. In addition, on-board mobile users in a vessel would like to experience the same rich mobile communication services as they enjoy on land.

Furthermore, it is of the view that the capacity and rate for data transmission based on legacy maritime radio communication technologies are indeed not enough for e-Navigation described in IMO Strategy Implementation Plan (SIP) or Maritime Autonomous Surface Ships (MASS), which the International Maritime Organization (IMO), a United Nations specialized agency, have been working to provide to ship.

Considering that the maritime domain is one of 5G vertical domains that 3GPP take into account in order for 5G to be able to provide enhanced mobile broadband services or massive machine-type communication services etc. everywhere anytime in the world, it is desirable to study use cases and requirements for maritime communication services over 3GPP system so that 3GPP system can be a good candidate of innovative tools to help address the information gap between users on land and users at sea as well as the maritime safety and vessel traffic management etc. that IMO intends to achieve especially in 5G era.

3GPP TR 22.819, Feasibility Study on Maritime Communication Services over 3GPP system concluded in 2018 and a report is available here. The scope of the document says:

The present document aims to support the maritime communication services between users ashore and at sea or between vessels at sea over 3GPP system that are targeted to improve maritime safety, protect the maritime environment and promote the efficiency of shipping by reducing maritime casualty caused by human error, in particular, involving small ships and fishing vessels. In addition, the outcome of the technical report is expected to narrow the information gap between mobile users on land and shipboard users on vessels at sea by making it possible to provide the mobile broadband services.

The document describes use cases and potential requirements for services between shore-based users such as authorities and shipboard users in the maritime radio communication environment over 3GPP system. In addition, it deals with use cases to support Mission Critical Services between authorities on land and authorities at sea (e.g. maritime police) as well as use cases to support the interworking between 3GPP system and the existing/future maritime radio communication system for the seamless service of voice communication and data communication between users ashore and at sea or between vessels at sea.

Analysis is also made on which legacy services and requirements from the existing 3GPP system need to be included and which potential requirements need additional work for new functions to support maritime communication services over 3GPP system.

The first 3GPP Technical Specification (TS) 22.119 covering service requirements (Stage 1) is specified for the support of maritime communication (MARCOM) over 3GPP systems.

The maritime domain, one of the 5G vertical domains in 3GPP, is moving forward with the digitalisation and mobilisation of commercial as well as safety fields. Legacy 3GPP-based technologies and solutions can be beneficial to the digitalisation and mobilisation of the maritime domain though some of the legacy 3GPP enabling technologies and solutions may not be able to fully support the performances required by the maritime domain. The maritime radio environment was not originally considered by 3GPP when the technical specifications and solutions were standardised for LTE and 5G. 

However, most of the legacy mobile services and IoT services based on capabilities of EPS and 5GS specified in 3GPP specifications are applicable to maritime usage for the support of mobile broadband services, and for the support of IoT services or machine-type communication services in a vessel at sea. 

In addition, there are service scenarios and requirements specified in 3GPP specifications based on requirements of other related vertical domains (e.g. public safety domain, automotive domain, factory automation domain, and satellite industrial domain). Some requirements derived by service scenarios from these related vertical domains are applicable to the maritime domain. Thus, it is beneficial to use 3GPP enabling technologies developed to satisfy those requirements for the maritime domain in terms of the economy of scale.

For example, satellite access is one of the 3GPP radio access networks supported over the 5G system, so it is possible to provide seamless maritime mobile services by integrating multiple access technologies including satellite access depending on the service scenarios. In addition, Vertical LAN that can replace Ethernet-based access are applicable to indoor maritime mobile services inside a vessel.

Mission Critical (MC) Services specified in 3GPP specifications are applicable to commercial and maritime safety fields. Some similarities exist between the public safety domain and the maritime domain in terms of service scenarios that are essentially the same. For example, in some situations, mobile communication services are supported in spite of disconnected networks, i.e. off-network mode, or under isolated conditions. 

However, the maritime domain also has specific situations that do not happen in other vertical domains or in the legacy ICT industrial domain. New 3GPP enabling technologies dedicated to the maritime domain can be used to address such specific situations based on requirements derived from maritime use cases. Other vertical domains may benefit from such new 3GPP enabling technologies that consider maritime domain scenarios and may need more robust technologies or solutions than those that currently exist for those vertical domains.

The following specifications are relevant for MARCOM:

  • 3GPP TS 22.119, Maritime communication services over 3GPP system
  • 3GPP TS 22.179, Mission Critical Push to Talk (MCPTT); Stage 1
  • 3GPP TS 22.280, Mission Critical (MC) services common requirements
  • 3GPP TS 22.281, Mission Critical (MC) video
  • 3GPP TS 22.282, Mission Critical (MC) data

Related Posts

Monday 20 September 2021

When can we Stop the 5G NSA Experiment?

Cross posting from LinkedIn, please post any comments there!

One of the advantages of having been in the industry for a very long time is one knows (and in my case, remembers) the hacks of each generation of mobile technology.

In case of UMTS (3G), the initial version had very poor data rates. Even though 3G was designed to bring data to the masses, there were hardly any applications that could take advantage of the mobile data connectivity. In addition, you could hardly get over 128 kbps (yes, kilo bits per second, not mega bits).

Most people think that the data part was added later on, as HSDPA, HSUPA (collectively HSPA) and HSPA+ from 3GPP Release-5 onwards. This is just one side of the story. The initial version of 3G had Downlink Shared Channel (DSCH) and Uplink Common Packet Channel (CPCH). As nearly all the patents were held by one very small company, none of the big vendors (both in network side as well and device side) implemented it (cartel?) and those channels eventually got removed from the standards.

Politics aside, until the arrival of HSPA, people couldn’t take advantage of mobile broadband.

LTE had already started being standardised while HSPA was being rolled out. LTE promised much higher data rates and reduction in the device power consumption, and it delivered! But… 

Have you heard this industry joke? When the standards engineers were designing 3G, 2G voice and SMS was generating most of income for the operators. Naturally they focussed on Voice and SMS and forgot to design data properly. When it came to design LTE, they focussed so much on data, they forgot to design the voice part.

Not My Job

Well, to be honest, 4G was always planned to be a packet switched (PS) only network, with a flatter and simplified architecture and protocols. With CS domain gone, the RRC and NAS protocols could be simplified. From a RAN engineer point of view, the voice calls would be voice over IP (VoIP) but the people who design the network telephony part didn’t get the memo.

The first set of LTE standards in Release-8 had to rely on this hack called CS Fallback. When nobody was taking ownership of the issue on hand, GSMA stepped in and created Voice over LTE (VoLTE) standards. It was based on the IMS standards that were bandied about for a long time but never got deployed fully. The standards was also complex and even after 8 years of it being standardised, it has still not been deployed everywhere.

5G for Everyone

I have been closely following the developments in 5G for over 6 years now. If you saw and heard the things I did, you would have believed that 5G is a panacea for all the world’s ills. In fact, in reality, it is just another generation of mobile network standards, astutely referred to as 5G JAG (Just Another Generation) by the outspoken industry analyst, Dean Bubley.

In the race to launch 5G by hook or by crook, the Non-Standalone (NSA) version of 5G, option 3 (technical name EN-DC) was launched. It gives the operators the ability to show 5G icon on you smartphones easily while not having to worry too much about delivering all the promises. If an operator has spare or a lot of spectrum, they can then use (some of) it to start transmitting on 5G New Radio (NR). If they don’t have much spectrum then they will have to do some kind of Dynamic Spectrum Sharing (DSS) to show the 5G icon. The problem with DSS is that while it would provide some kind of 5G to everyone capable of receiving it, it spoils the experience of the 4G users who are satisfied or happy with their LTE network.

5G Stands Alone

While all this had been going on, the operators have started buying new 5G spectrum, and started preparing and in many cases rolling out the Real Standalone 5G Network. If an operator has sufficient spectrum and the right kind of spectrum, they can now start to deliver on some of the actual 5G promises. 

I am aware of some of the operators who are already thinking about switching off their Non-Standalone EN-DC networks within the next couple of years. The initial 5G smartphones did not support the Standalone version of 5G networks so the operators will give them enough time to switch over to a newer device capable of standalone network.

So what would happen to a 5G device only supporting NSA 5G, after the NSA network is switched off?

Nothing really. It would still be able to do 4G (and 2G, 3G) which is generally good enough. They would stop seeing the 5G icon and in some cases, won’t benefit with the extra speeds boost.

Switching off 5G NSA will benefit the operator with the simplification of the network, not just from deployment point of view but also from optimization as there is no need for 4G-5G dual connectivity and for the 5G cell to be planned based on the 4G cell.

Industry’s View

5G Training ran a poll on LinkedIn to ask people involved in the 5G industry if they were happy with 5G NSA or would rather go with Standalone 5G, 6G or just satisfied with 4G. Surprisingly most people in the 5G industry said they were waiting for Standalone 5G. This was followed by “Looking forward to 6G!”. “Happy with existing 5G” got the least number of votes. 

This poll is by no measure reliable but it should force the operators, vendors and everyone else to ponder if it makes sense to move to SA sooner rather than later and to switch off NSA as soon as possible.

Non-Standalone Part 2

When the first set of 5G standards were being defined, it was felt that there should be a path to transition from 4G to 5G in the future. While the initial Option 3 (EN-DC) relied on 4G Core or EPC, these future NSA options can rely on 5G core.

Sometimes, in their zeal and enthusiasm, engineers define things that would make everyone’s lives difficult. These options are very much like that. While some operators have asked for Option 4, most people realise that it doesn’t make sense, at least right now to be creating more fragmentation in 5G deployment.

Hopefully rationality will prevail and any major architecture changes we do with 5G going forward will only be done after lots of analysing and thinking about the long term consequences. 

Please post any comments on LinkedIn as comments have been disabled on this post.