Showing posts with label 5GS. Show all posts
Showing posts with label 5GS. Show all posts

Tuesday, 12 October 2021

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.

Monday, 21 June 2021

3GPP Standards on Edge Computing

A sub-set of 3GPP Market Representation Partners hosted a 2-part webinar series in April 2021 looking at edge computing for industry verticals and on-going standardisation work in 3GPP. The first part write-up is available here. The webinar was attended by a mix of organisations from both verticals and the telecommunication industry, helping to share a common understanding on edge computing. 

The webinar brought together top experts at the 3GPP plenary level, SA2 (Architecture) and SA6 (application enablement and critical communication applications) for a deep-dive into how 5G and related standards can help harmonise and enable technologies like edge computing and artificial intelligence to work together much more efficiently. 

The webinar was co-chaired by Georg Mayer, 3GPP SA Chairman and Stephanie Parker, Trust-IT and Vice-chair of the 5G-IA Pre-Standardisation WG with the John Favaro, Trust-IT and member of the 5G PPP Automotive Working Group. 

The webinar was attended by a mix of organisations from both verticals and the telecommunication industry, helping to share a common understanding on edge computing.

This video embedded below is the recording of the webinar on edge computing held on Thursday 22 April 2021 part 2 - 3GPP Standards on Edge Computing as an educational deep dive to help industry verticals gain a better understanding of an evolving landscape. It gives key insights into 3GPP standardisation work on edge computing with an overview of the main activities taking place within SA (System Aspects and Architecture). Presentations and panel discussions zoom in on the network layer with SA2 Architecture and on the application layer for vertical enablement with SA6 Application Enablement and Critical Communication Applications. The panel discussion with SA TSG, SA2 and SA6 chairmen sheds light on the role of artificial intelligence from both the network and application perspectives, underscoring the vital importance of industry verticals in the standardisation process to meet their specific requirements in 3GPP as a truly global initiative.

PDF of presentations as follows:

Global5G has a summary with main takeaways and poll findings here. The following is from there:

Main Takeaways

  1. 5G will help technologies like edge computing and artificial intelligence to harmonise and enable them to work together much more efficiently.
  2. 3GPP Release 17 is foundational for edge computing but more will come in future releases given its importance in mobile communications and as we gradually move beyond 5G. The webinar was therefore a timely deep-dive into today's landscape. 
  3. Artificial Intelligence and edge computing can both serve as building blocks but in different ways: 
    • Network layer perspectives: AI can further optimise edge computing applications.
    • Application layer persepctives: Edge computing can be a building block for AI, e.g. offloading limited capabilities from the device to the network.
  4. Global initiatives like 3GPP can help reduce regional fragmentation, drive convergence and enable network-compliant rollouts that benefit the ecosystem around the world.
  5. As a global initiative, 3GPP is well placed to build on its strong relationships and collaborations with ETSI MEC and GSMA. 
  6. It is absolutely essential that industry verticals get involved in 3GPP working groups, which is where key activities take place and where their requirements should be channelled. It is also important that verticals understand how their seemingly specific requirements could be relevant to other sectors. Being part of 3GPP is a complex but highly rewarding experience. It does not need to be a life-long commitment.

Poll Findings - Participant Viewpoints

Do you participate in standardization on edge computing?

Interestingly most respondents do not take part in any standardisation initiatives. Hence the webinar series was an opportunity to highlight the many activities taking place and encourage participants to get involved. Those that do take part mostly contribute to 3GPP and other forums (29%) like ETSI (SDO) and industry associations like 5GAA and 5G-ACIA as some of the early movers on edge computing. Beyond 3GPP, a smaller number of respondents (11%) contribute to ETSI and other forums such as 5GAA and GSMA and the same amount (11%) are involved in other forums.

How important do you think coordination on edge computing standardisation is?

Coordination on edge computing standardisation needs to be prioritised with 65% of respondents saying it's vital and another 33% saying it's quite important. Only 1 respondent said it's not needed. An important output via the 5G-IA Pre-Standardisation WG and supported by panellists and organisers (5G-IA, 5GAA, 5G-ACIA and PSCE) would be a user-friendly guide on edge computing standardisation to help stakeholders navigate the landscape. 

Do you see a need for new areas of standardisation for edge computing?

Findings from this poll are particularly interesting as we have a close split between those that think more standardisation work is needed (47%) and those that don't know (43%) with just 10% saying it's not needed. Webinar organisers have come up with two possible explanations. On the one hand, we may be looking at a fragmented landscape that would benefit from more unification, also from an architecture perspective. On the other hand, organisations looking at the landscape may simply be overwhelmed by the dverse activities taking place. They may also have new applications sitting on top of the network but are not sure if they need to be standardised. Practical guidance could go a long way in clarifying this uncertainty. 

Again, a quick guide on edge computing standardisation could be a useful output, highlighting also the good cooperation already taking place as an important step in the right direction. 

You can see Part 1 of this webinar here.

Related Posts

Monday, 31 May 2021

5G User Plane Redundancy


We looked at the 5G Enhanced URLLC (eURLLC) earlier. One of the ways to improve reliability is to have redundancy in the user plane. This can use different approaches like: 

  • Duplicating N3
  • Adding a secondary gNB using Dual connectivity
  • Introducing another UPF
  • Two anchor UPFs

In fact they are all built on top of each other so you can decide how critical are your user plane redundancy needs. 

I came across this short video from Mpirical embedded below that covers this topic nicely. In case you want to refresh your 5G Core Network architecture, jump to our old tutorial here.

Related Posts:

Tuesday, 6 April 2021

A look at 5G Applications, Application Functions & Application Servers

We often get questions about 5G Service Based Architecture. Luckily, we have a tutorial that we can redirect people to. It's available here and the video just crossed 50K views. One of the questions that people often want to understand, is about the Application Function (AF) and how does it fit in the Applications Architecture.

To explain this, we made a tutorial. The slides and videos are embedded below. In that we have used the examples from our XR, V2X and Private Networks tutorials. All links are available at the bottom of this post.

Video:

Slides:

Related Posts:

Tuesday, 2 February 2021

NWDAF in 3GPP Release-16 and Release-17

We looked at Network Data Analytics Function, NWDAF, in detail here. While the 3GPP Release-16 work just starting back then, we have now completed Rel-16 and looking at Release 17. 

The 5G Core (5GC) supports the application of analytics to provide Intelligent Automation of the network, In Rel-16 the set of use cases that are proposed for the NWDAF has been widely expanded. 

In an earlier post, we looked at the ATIS webinar discussing Release-16 & forthcoming features in Rel-17. Puneet Jain, Director of Technical Standards at Intel and 3GPP SA2 Chairman talked briefly about NWDAF. The following is from his talk:

Release-16 provides support for Network Automation and Data Analytics.  Network Data Analytics Function (NWDAF) was defined to provide analytics to 5G Core Network Functions (NFs) and to O&M. It consists of several services that were defined in 3GPP Rel-16 and work is now going in Release 17 to further extend them. 

In release 16 Slice load level related network data analytics and observed service experience related network data analytics were defined. NF load analytics as well Network Performance analytics was also specified. NWDAF provides either statistics or prediction on the load communication and mobility performance in the area of interest. 

Other thing was about the UE related analytics which includes UE mobility analytics, UE communication analytics, Expected UE behavior parameter, Related network data analytics and abnormal behavior related network data analytics.

The NWDAF can also provide user data congestion related analytics. This can be done by one time reporting or continuous reporting in the form of statistics or prediction or both to any other network function. 

QoS sustainability analytics, this is where the consumer of QoS sustainability analytics may request NWDAF analytics information regarding the QoS change statistic for a specific period in the past in a certain area or the likelihood of QoS change for a specific period in future, in certain areas. 

In Release 17, studies are ongoing for network automation phase 2. This includes some leftover from Release 16 such as UE driven analytics, how to ensure that slice SLA is guaranteed and then also new functionality is being discussed that includes things like support for multiple NWDAF instance in one PLMN including hierarchies, how to enable real-time or near-real-time NWDAF communications, how to enable NWDAF assisted user pane optimization and last which is very interesting is about interaction between NWDAF and AI model and training service owned by the operator.

This article on TM Forum talks about NWDAF deployment challenges and recommendations:

To deploy NWDAF, CSPs may encounter these challenges:

  • Some network function vendors may not be standards compliant or have interfaces to provide data or receive analytics services.
  • Integrating NWDAF with existing analytics applications until a 4G network is deployed is crucial as aggregated network data is needed to make decisions for centralized analytics use cases.
  • Many CSPs have different analytics nodes deployed for various use cases like revenue assurance, subscriber/marketing analytics and subscriber experience/network management. Making these all integrated into one analytics node also serving NWDAF use cases is key to deriving better insights and value out of network data.
  • Ensuring the analytics function deployed is integrated to derive value (e.g., with orchestrator for network automation, BI tools/any UI/email/notification apps for reporting).

Here are some ways you can overcome these challenges and deploy efficient next-generation analytics with NWDAF:

  • Mandate a distributed architecture for analytics too, this reduces network bandwidth overhead due to analytics and helps real-time use cases by design.
  • Ensure RFPs and your chosen vendors for network functions have, or plan to have, NWDAF support for collecting and receiving analytics services.
  • Look for carrier-grade analytics solutions with five nines SLAs.
  • Choose modular analytics systems that can accommodate multiple use cases including NWDAF as apps and support quick development.
  • Resource-efficient solutions are critical for on-premise or cloud as they can decrease expenses considerably.
  • Storage comes with a cost, store more processed smart data and not more raw big data unless mandated by law.
  • In designing an analytics use case, get opinions from both telco and analytics experts, or ideally an expert in both, as they are viewed from different worlds and are evolving a lot.

This is such an important topic that you will hear more about it on this blog and elsewhere.

Related Posts:

Tuesday, 10 November 2020

Network Slicing Tutorials and Other Resources

I have received quite a few requests to do a 5G Network Slicing tutorial but have still not got around to doing it. Luckily there are so many public resources available that I can get away with not doing one on this topic. 


This Award Solutions webinar by Paul Shepherd (embedded below) provides good insights into network slicing, what it is, how it efficiently enables different services in 5G networks, and the architectural changes in 5G required to support it.

Then there is also this myth about 3 slices in the network. The GSMA slice template is a good starting point for an operator looking to do network slicing in their 5G networks. The latest version is 3.0, available here.


As this picture (courtesy of Phil Kendall) shows, it's not a straightforward task.  

Alistair URIE from Nokia Bell Labs points out some common misconceptions people have with Network Slicing:

  1. Multiple slices may share the same cell and the same RU in each slice
  2. Single UE may have up to 8 active slices but must have a single CU-CP instance to terminate the common RRC 
  3. Slicing supports more than 3 slices 

Back in March, China Mobile, Huawei, Tencent, China Electric Power Research Institute, and Digital Domain have jointly released the Categories and Service Levels of Network Slice White Paper to introduce the industry’s first classification of network slice levels. The new white paper dives into the definitions, solutions, typical scenarios, and evolution that make up the five levels of network slices. It serves as an excellent reference to provide guidance in promoting and commercializing network slicing, and lays a theoretical foundation for the industry-wide application of network slicing.

The whitepaper describes the different phases as:

Phase 1 (ready): As mentioned above, the 5G transport network and 5G core network support different software-based and hardware-based isolation solutions. On the 5G NR side, 5QIs (QoS scheduling mechanism) are mainly used to achieve software-based isolation in WAN scenarios. Alternatively, campus-specific 5G NR (including micro base stations and indoor distributed base stations) is used to implement hardware-based isolation in LAN scenarios. In terms of service experience assurance, 5QIs are used to implement differentiated SLA assurance between slices. In terms of slice OAM capabilities, E2E KPIs can be managed in a visualized manner. This means that from 2020 on, Huawei is ready to deliver commercial use of E2E slicing for common customers and VIP customers of the public network and common customer of general industries (such as UHD live broadcast and AR advertisement).

Phase 2 (to be ready in 2021): In terms of isolation, the 5G NR side supports the wireless RB resource reservation technology (including the static reservation and dynamic reservation modes) to implement E2E network resource isolation and slicing in WAN scenarios. In terms of service experience assurance, features such as 5G LAN and 5G TSN are enhanced to implement differentiated and deterministic SLA assurance between different slices. In terms of slice OAM, on the basis of tenant-level KPI visualization, the limited self-service of the industry for rented slices can be further supported. In this phase, operators can serve VIP customers in common industries (such as AR/VR cloud games and drone inspection), dedicated industry customers (such as electric power management information region, medical hospital campus, and industrial campus), and dedicated industry customers (such as electric power production control region and public security).

Phase 3 (to be ready after 2022): In this phase, 5G network slicing supports real dynamic closed-loop SLAs based on AI and negative feedback mechanism, implementing network self-optimization and better serving industries (such as 5G V2X) with high requirements on mobility, roaming, and service continuity. In addition, industry-oriented comprehensive service capabilities will be further enhanced and evolved.

A more technical presentation from Nokia is available here. The video below shows how innovations in IP routing and SDN work together to implement network slicing in the transport domain.

If you know some other good resources and tutorials worth sharing, add them in the comments below.

Related Posts:

Thursday, 10 September 2020

Interfacing HSS and UDM in 5GS with UDICOM (a.k.a NU1 / Nhss)

Back in 2012, we were talking about migration from HLR to HSS. Now we are discussing how to interface HSS to the UDM (Unified Data Management in 5G Core).


In the recent 5G World event, Richard Band, Head of 5G Core, HPE talked about 4G to 5G transition planning. During the talk he mentioned about UDICOM, which is the Standardised new interface between HSS and UDM as defined in 3GPP TS 23.632.


UDICOM allows operators to deploy separate HSS and UDM, even from different vendors. Supported features include:
  • Authentication
  • Single Registration Handover
  • IMS
  • SMS over NAS
3GPP TS 23.632 (Technical Specification Group Core Network and Terminals; User data interworking, coexistence and migration; Stage 2; Release 16) does not use the term UDICOM. It does however describe the interface details, system architecture, system procedures and network function service procedures of UDM-HSS interface.

As can be seen in the picture above, the following reference points are realized by service-based interfaces:
NU1: Reference point between the HSS and the UDM.
NU2: Reference point between the HSS and the 5GS-UDR.

The following Service based interfaces are defined for direct UDM-HSS interworking:
Nudm: Service-based interface exhibited by UDM.
Nhss: Service-based interface exhibited by HSS.

I am not going in more details here but anyone wanting to learn more about the interface should start with 3GPP TS 23.632.

Finally, this talk from HP Enterprise below provides more details of UDICOM.



Related Posts:

Sunday, 19 July 2020

Mobile Initiated Connection Only (MICO) mode in 5G System


Mobile Initiated Connection Only (MICO) mode is designed for IoT devices that send small amounts of data and do not need to be paged. An example of this could be a smart bin that sends a message to the waste collection company saying it is 50% full, etc. This way the bin emptying lorry can plan to empty it in the next collection round. Here there is no reason to page the bin as there is no mobile terminated data that would be required.

MICO mode has to be negotiated between the device and AMF in 5GC. A device in MICO mode cannot be paged as it would not listen to paging to conserve battery power. This extreme power saving mode can ensure that the battery can last for very long time, ideally years thereby making this vision of billions of connected IoT devices a reality.


In an earlier post on RRC Inactive state, we looked at NAS states, along with RRC states. When the UE is in MICO mode, the AMF in 5GC will consider the UE to be unreachable when it is in CM-IDLE state. In addition, a periodic registration timer is also allocated to the MICO mode UEs. The UE has to confirm the MICO mode again during registration update.

The video and presentation are embedded below:





Related Posts:

Monday, 6 July 2020

A Technical Introduction to 5G NR RRC Inactive State


I looked at the RRC Inactive state back in 2017, but the standards were not completely defined. In the meantime standards have evolved and commercial 5G networks are rolling out left, right and centre. I made a short technical introduction to the RRC_INACTIVE state, comparing it with the 4G states in RRC and NAS. I also looked at some basic signalling examples and there are lots of relevant references at the end. Video and slides embedded below.






Related Posts: