Showing posts with label Technical Details. Show all posts
Showing posts with label Technical Details. Show all posts

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

Thursday, 10 June 2021

Nokia veterans Harri Holma and Antti Toskala explain 5G Basics

An online conference on 5G is currently going on. 'Backed by 5G: Technology for Impact', is hosted by Start North as a part of the Aalto University Summer Course 5G Hack the Mall.

It is a two-week online conference which gathers the industry experts, entrepreneurs and policymakers together to discuss, present and question how 5G will affect our society, economy and everyday life. We want you to join the change by offering a chance to learn from the best, to start or strengthen your journey to expertise in 5G. With the support of our partners, you have the possibility to listen and get your questions answered by the global 5G leaders from the leading companies, academia, NGOs and public institutions, which all are daily involved with changing the world and enabling change with the latest technology.

The current conference features couple of Nokia experts who are well known in the industry for their books on the mobile technologies. Dr. Harri Holma, Fellow, Nokia Bell Labs, spoke on "What is Good to Know About 5G Technology Components". His talk is embedded below:


The second talk is by Dr. Antti Toskala, Fellow, Nokia Bell Labs, on Radio Access (5G Physical Layer). His talk is embedded below

Slides are shared to the 5G Summer School participants. If you are keen to get your hands on the slides, please email: hello@startnorth.com. You can watch all the videos from the event on the Start North YouTube channel 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:

Friday, 5 March 2021

How to Identify Network Slices in NG RAN

In my last post I described how NG RAN resources can be divided into network slices. 

Now I would like to show how these network slices and the traffic they carry can be identified. 

The key to this is a parameter from the NG Application Protocol (NGAP) called the Single Network Slice Selection Assistance Information (S-NSSAI). When configuring virtual network functions in NG RAN there are lists of S-NSSAI exchanged, e.g. between gNB-CU CP and AMF during NGAP Setup procedure, to negotiate which network slices have to be supported in general. 

When it comes to connection establishment starting with NGAP Initial Context Setup for each PDU session that is established its individual S-NSSAI is signaled. 

The S-NSSAI - as show in the figure below - consists of two parameters, the Slice/Service Type (SST - 8 bit) and the optional Slice Differentiator (SD - 24 bit). The exact format and numbering ranges are defined in 3GPP 23.003.

3GPP 23.501 defines a set of default values for SST as listed in the following table:

Slice/Service type

SST value

Characteristics

eMBB

 

1

Slice suitable for the handling of 5G enhanced Mobile Broadband.

URLLC

2

Slice suitable for the handling of ultra- reliable low latency communications.

MIoT

3

Slice suitable for the handling of massive IoT.

V2X

4

Slice suitable for the handling of V2X services.

So when looking back at the figure it emerges that for each subscriber represented by an IMSI the SST allows to identify which services are running. 

On the other hand allows to see if in which virtual network the subscriber is active. In my example I have defined that the resources are shared among a Public MNO that I consider the owner of the network hardware and two different private (campus) networks. While IMSI 1 and IMSI 2 are not allowed to use any other network slice the IMSI 3 is allowed to "roam" betweent the public slice and the two private network slices. This explains why a slice-specific authentication functionality as defined in Rel. 16 is necessary. 

Related Posts:

Monday, 22 February 2021

Reducing 5G Device Power Consumption Using Connected-mode Discontinuous Reception (C-DRX)


Back in 2019, when we were still participating in physical event, I heard Sang-Hoon Park, ESVP, Head of Regional Network O&M Headquarter, KT talk about 'KT’s journey to large-scale 5G rollout' at Total Telecom Congress.

South Korea is blessed with three highly competitive MNOs and due to this, the government asked them to launch their 5G networks at the same time in 2018. I have also blogged about how KT is working on reducing the latency of their network here.

Anyway, as you can see in the picture above, using Connected-mode Discontinuous Reception (C-DRX), KT was able to show huge power saving in the 5G Samsung smartphone. They also made a video embedded below:

KT has some more details from their blog post back in 2019 here. Also some more details on RayCat here. Both the sites are in Korean but you can use Google translate to get more details.

What is KT battery saving technology (C-DRX)?

KT's'battery saving technology' is shortened to'Connected Mode Discontinuous Reception' and is called C-DRX. In simple terms, it is one of the technologies that reduces battery usage by periodically switching the communication function of a smartphone to a low power mode while data is connected.

In CDRX technology, the base station and the terminal share CDRX information through RRC setting and reconfiguration, so when there is no packet transmission/reception by the terminal, the terminal transmission/reception terminal can be turned off to reduce battery consumption, and the CDRX setting is optimized to reduce the user's battery consumption. It is possible to increase the available time for related applications.

In order to reduce the battery consumption of the terminal, it is a technology that controls the PDCCH monitoring activity, which is a downlink control channel related to the terminal identifier, through RRC. The base station controls the CDRX through RRC, and how the communication company optimizes and applies this was a big task. Is the first in Korea to optimize this technology and apply it to the national network.

In simple terms, the smartphone is not using communication, but it turns off the power completely and enters the standby state to reduce power consumption. When not in use, it completely turns off the power wasted in transmitting and receiving even during the standby time, thus extending the user's smartphone usage time.

As can be seen from the picture above, battery saving technology saves battery by completely turning off the communication function when there is no data or voice call. If the network does not have the battery saving technology applied, it is always connected to the communication network and waits even when not in use. Then, the battery is always connected to the communication function and the battery saving technology overcomes this part.

When Qualcomm announced their Industry’s First Mobile Platform with Integrated 5G back in 2019, the press release said:

The new integrated Snapdragon 5G mobile platform features Qualcomm® 5G PowerSave technology to enable smartphones with the battery life users expect today. Qualcomm 5G PowerSave builds on connected-mode discontinuous reception (C-DRX, a feature in 3GPP specifications) along with additional techniques from Qualcomm Technologies to enhance battery life in 5G mobile devices – making it comparable to that of Gigabit LTE devices today. Qualcomm 5G PowerSave is also supported in the Snapdragon X50 and X55 5G modems, which are expected to power the first waves of 5G mobile devices introduced this year.

The picture is from the slide deck here. See links in further reading below to learn more about this feature.

Further Reading:

  • All about Wired and Wireless Technology: LTE Connected Mode DRX (link)
  • Netmanias: Future LTE Designed by SK Telecom: ​(2) Application of C-DRX, July 2017 (link)
  • Ericsson: A technical look at 5G mobile device energy efficiency, Feb 2020 (link)
  • ZTE via IEEE Access: Power Saving Techniques for 5G and Beyond, July 2020 (link)

Related Posts:

Tuesday, 17 November 2020

5G Non IP Data Delivery and Lightweight M2M (LwM2M) over NIDD

Earlier this year, MediaTek had announced that its MT2625 NB-IoT chip has been validated for LwM2M over NIDD on SoftBank Corp.’s cellular network across Japan. This achievement marks the first global commercial readiness of LwM2M over NIDD; a secure, ultra-efficient IoT communications technique that is being adopted by operators worldwide. The benefits of LwM2M over NIDD include security improvements, cost-efficient scalability and reduced power consumption.

LwM2M over NIDD is a combination of the communication technology "NIDD (Non-IP Data Delivery)" that does not use an IP address in LTE communication NB-IoT for IoT and the device management protocol "LwM2M (Lightweight M2M)" advocated by the Open Mobile Alliance. It's been a while since I wrote about Open Mobile Alliance on this blog. OMA SpecWorks is the successor brand to the Open Mobile Alliance. You can read all about it here.


OMA SpecWorks’ LightweightM2M is a device management protocol designed for sensor networks and the demands of a machine-to-machine (M2M) environment. With LwM2M, OMA  SpecWorks has responded to demand in the market for a common standard for managing lightweight and low power devices on a variety of networks necessary to realize the potential of IoT. The LwM2M protocol, designed for remote management of M2M devices and related service enablement, features a modern architectural design based on REST, defines an extensible resource and data model and builds on an efficient secure data transfer standard called the Constrained Application Protocol (CoAP). LwM2M has been specified by a group of industry experts at the OMA SpecWorks Device Management Working Group and is based on protocol and security standards from the IETF.

You can get all the LwM2M resources here and the basic specs of 'Lightweight M2M 1.1: Managing Non-IP Devices in Cellular IoT Networks' here.
The 5G Americas whitepaper 'Wireless Technology Evolution Towards 5G: 3GPP Release 13 to Release 15 and Beyond' details how Current Architecture for 3GPP Systems for IOT Service Provision and Connectivity to External Application Servers. It also talks about Rel-13 Cellular IoT EPS Optimizations which provide improved support of small data transfer over control plane and user plane. Control Plane CIoT EPS Optimization transports user data (measurements, ID, status, etc.) via MME by encapsulating user data in NAS PDUs and reduces the total number of control plane messages when handling a short data transaction. Control Plane CIoT EPS optimization, designed for small infrequent data packets, can also be used for larger data bursts depending in UE Radio capability.

User data transported using the Control Plane CIoT EPS Optimization, has special characteristics, as different mobility anchor and termination nodes.

Therefore, the Preferred Network Behavior signaling must include information on:
  • Whether Control Plane CIoT EPS optimization is supported
  • Whether User Plane CIoT EPS optimization is supported
  • Whether Control Plane CIoT EPS optimization is preferred or whether User Plane CIoT EPS optimization is preferred
These optimizations have enabled:
  • Non-IP Data Delivery (NIDD) for both: mobile originated and mobile terminated communications, by using SCEF (Service Capability Exposure Function) or SGi tunneling. However, it has to be taken into account that Non-IP PDUs may be lost and its sequence is not guaranteed
  • For IP data, the UE and MME may perform header compression based on Robust Header Compression (ROHC) framework
  • NB-IoT UE can attach but not activate any PDN connection
  • High latency communication handled by the buffering of downlink data (in the Serving GW or the MME)
  • SMS transfer
  • EPS Attach, TA Update and EPS Detach procedures for NB-IoT only UEs, with SMS service request
  • Procedures for connection suspend and resume are added
  • Support for transfer of user plane data without the need for using the Service Request procedure to establish Access Stratum context in the serving eNodeB and UE
When selecting an MME for a UE that is using the NB-IoT RAT, and/or for a UE that signals support for CIoT EPS Optimizations in RRC signaling, the eNodeB’s MME selection algorithm shall select an MME taking into account its Release 13 NAS signaling protocol.

Mpirical has a nice short video explaining 5G Non IP Data Delivery. It is embedded below.

IoT has not taken off as expected and prophesised for years. While the OMASpecWorks is doing some fantastic work by defining simplified approach for IoT deployment, its current member list doesn't have enough operators to drive the uptake required for its spec adoption. They would argue that it doesn't matter how many members there are as the NIDD approach is completely optional and over-the-top. Let's wait and see how it progresses.

Related Posts:

Friday, 2 October 2020

5G Enhanced URLLC (eURLLC)

One of the interesting features of 5G is Ultra-Reliability and Low-Latency Communication or URLLC. It has been enhanced as part of 3GPP Release-16. A summary of the changes in eURLLC can be seen in the picture above. 


This ATIS webinar that I blogged about last week covered this topic as well. For example L1/L2 changes have been summarised nicely in this Qualcomm slide above while the slide from Intel speaker below looks at redundant transmission and session continuity.

Redundant transmission in the user plane is an extremely useful feature, especially if the packets are mission critical and have to reach from the source to their destination in a guaranteed time / reliability.

Dual connectivity will enable this redundant path when required to meet a guaranteed reliability. 

Here is a short video from the training company Mpirical, explaining the the 5G eURLLC feature: 

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:

Monday, 22 June 2020

Carrier Aggregation (CA) and Dual Connectivity (DC)


This topic keeps coming up every few months with either someone asking me for clarifications or someone asking us to make a video. While I don't think I will mange to get round to making a video sometime soon, there are some excellent resources available that should help a new starter. Here they are in an order I think works best



The first resource that I think also works best is this webinar / training from Award Solutions. It covers this topic well and the image at the top of the post is a god summary for someone who already understands the technology.


It may also help to understand that in the 5G NSA can have 4G carrier aggregation as well as 5G carrier aggregation in addition to dual connectivity.


If you saw the video earlier, you noticed that DC actually came as part of LTE in Release-12. We covered it in our Telecom Infrastructure blog here. NTT Docomo Technical journal had a detailed article on 'Carrier Aggregation Enhancement and Dual Connectivity Promising Higher Throughput and Capacity' that covered DC in a lot more technical detail, albeit from LTE point of view only. The article is available here. A WWRF whitepaper from the same era can also provide more details on LTE Small Cell Enhancement by Dual Connectivity. An archived copy of the paper is available here.

Another fantastic resource is this presentation by Rapeepat Ratasuk and Amitava Ghosh from Mobile Radio Research Lab, Nokia Bell Labs. The presentation is available here and details the MCG (Master Cell Group) Split Bearer and SCG (Secondary Cell Group) Split Bearer, etc. This article from Ericsson also provides more detail on this topic while ShareTechNote takes it one level even deeper with technical details and signalling here and here.

So hopefully this is a good detailed starting point on this topic, until we manage to make a simple video someday.

Sunday, 19 January 2020

2-step RACH Enhancement for 5G New Radio (NR)

5G Americas recently published a white paper titled, "The 5G Evolution: 3GPP Releases 16-17" highlighting new features in 5G that will define the next phase of 5G network deployments across the globe. It's available here. One of the sections in that details the 2-step RACH enhancement that is being discussed for a while in 3GPP. The 2-step process would supercede the 4-step process today and would reduce the lartency and optimise the signalling.


Here are the details from the 5G Americas whitepaper:

RACH stands for Random Access Channel, which is the first message from UE to eNB when it is powered on. In terms of Radio Access Network implementation, handling RACH design can be one of the most important / critical portions.
The contention-based random-access procedure from Release 15 is a four-step procedure, as shown in Figure 3.12. The UE transmits a contention-based PRACH preamble, also known as Msg1. After detecting the preamble, the gNB responds with a random-access response (RAR), also known as Msg2. The RAR includes the detected preamble ID, a time-advance command, a temporary C-RNTI (TC-RNTI), and an uplink grant for scheduling a PUSCH transmission from the UE known as Msg3. The UE transmits Msg3 in response to the RAR including an ID for contention resolution. Upon receiving Msg3, the network transmits the contention resolution message, also known as Msg4, with the contention resolution ID. The UE receives Msg4, and if it finds its contention-resolution ID it sends an acknowledgement on a PUCCH, which completes the 4-step random access procedure.

The four-step random-access procedure requires two round-trip cycles between the UE and the base station, which not only increases the latency but also incurs additional control-signaling overhead. The motivation of two-step RACH is to reduce latency and control-signaling overhead by having a single round trip cycle between the UE and the base station. This is achieved by combining the preamble (Msg1) and the scheduled PUSCH transmission (Msg3) into a single message (MsgA) from the UE, known as MsgA. Then by combining the random-access respond (Msg2) and the contention resolution message (Msg4) into a single message (MsgB) from the gNB to UE, see Figure 3.13. Furthermore, for unlicensed spectrum, reducing the number of messages transmitted from the UE and the gNB, reduces the number of LBT (Listen Before Talk) attempts.

Design targets for two-step RACH:

  • A common design for the three main uses of 5G, i.e. eMBB, URLLC and mMTC in licensed and unlicensed spectrum.
  • Operation in any cell size supported in Release 15, and with or without a valid uplink time alignment (TA).
  • Applicable to different RRC states, i.e. RRC_INACTIVE, RRC_CONNECTED and RRC_IDLE states.
  • All triggers for four-step RACH apply to two-step RACH including, Msg3-based SI request and contention-based beam failure recovery (CB BFR).

As described earlier, MsgA consists of a PRACH preamble and a PUSCH transmission, known as MsgA PRACH and MsgA PUSCH respectively. The MsgA PRACH preambles are separate from the four-step RACH preambles, but can be transmitted in the same PRACH Occasions (ROs) as the preambles of fourstep RACH, or in separate ROs. The PUSCH transmissions are organized into PUSCH Occasions (POs) which span multiple symbols and PRBs with optional guard periods and guard bands between consecutive POs. Each PO consists of multiple DMRS ports and DMRS sequences, with each DMRS port/DMRS sequence pair known as PUSCH resource unit (PRU). two-step RACH supports at least one-to-one and multiple-to-one mapping between the preambles and PRUs.

After the UE transmits MsgA, it waits for the MsgB response from the gNB. There are three possible outcomes:

  1. gNB doesn’t detect the MsgA PRACH ➡ No response is sent back to the UE ➡ The UE retransmits MsgA or falls back to four-step RACH starting with a Msg1 transmission.
  2. gNB detects MsgA preamble but fails to successful decode MsgA PUSCH ➡ gNB sends back a fallbackRAR to the UE with the RAPID (random-access preamble ID) and an uplink grant for the MsgA PUSCH retransmission ➡ The UE upon receiving the fallbackRAR, falls back to four-step RACH with a transmission of Msg3 (retransmission of the MsgA PUSCH).
  3. gNB detects MsgA and successfully decodes MsgA PUSCH ➡ gNB sends back a successRAR to the UE with the contention resolution ID of MsgA ➡ The reception of the successRAR successfully completes the two-step RACH procedure.

As described earlier, MsgB consists of the random-access response and the contention-resolution message. The random-access response is sent when the gNB detects a preamble but cannot successfully decode the corresponding PUSCH transmission. The contention resolution message is sent after the gNB successfully decodes the PUSCH transmission. MsgB can contain backoff indication, fallbackRAR and/or successRAR. A single MsgB can contain the successRAR of one or more UEs. The fallbackRAR consists of the RAPID: an uplink grant to retransmit the MsgA PUSCH payload and time-advance command. The successRAR consists of at least the contention resolution ID, the C-RNTI and the TA command.

For more details on this feature, see 3GPP RP-190711, “2-step RACH for NR” (Work-item description)

Wednesday, 4 December 2019

Challenges of 5G Inter-Node Handovers

In all mobile communication networks handovers are the most complex signaling procedures, because multiple network elements (or network functions) are involved. Thus, it is logical that dual connectivity with two different base stations contributing to the radio connection simultaneously are even more complicated. And in EN-DC these two base stations are often covering different footprints using different carrier frequencies.This leads to a situation where we have more options for performing a handover in detail compared with plain LTE handover scenarios before.

The two signaling scenarios presented below illustrate in which different ways a change of the LTE master eNodeB can be performed during an ongoing EN-DC radio connection by using the X2 interface. In a very similar way it is also possible to perform S1 handover from old to new MeNB.

The pros and cons of these options have been discussed already by Martin Sauter in his Wireless Moves blog.

Inter-MeNB Handover without 5G Inter-Site Anchor

Figure 1 shows the easiest way of handing over the signaling connection from one MeNB to another one. Here it is up to the new MeNB to decide if and how the 5G part of the radio connection is continued.

Figure 1: X2 Handoverof EN-DC connection without 5G inter-site anchor

The handover is triggered when the UE sends a RRC Measurement Report (step 1) indicating that a stronger 4G cell than the currently used primary cell was measured. From its neighbor list the current MeNB detects that this better cell belongs to a neighbor eNB.

To provide both, the the Master Cell Group (MCG) and Secondary Cell Group (SCG) parameters to this neighbor eNB the old MeNB queries the SCG configuration parameters from the old SgNB by performing the X2AP SgNB Modification procedure (step 2+3).

Then it sends the X2AP Handover Request message to the target MeNB (step 4) including all information necessary to continue the 5G radio link in case the target MeNB decides to go for this option.

However, what comes back from the target MeNB is a plain LTE handover command (LTE RRC Connection Reconfiguration message [step 6]) embedded in the X2AP Handover Request Acknowledge message (step 5).

Due to this the old MeNB releases all 5G resources and the UE context in the SgNB (steps 7 + 10).

After the UE  successfully connected via radio interface with the target cell in the new MeNB the S1AP Path Switch procedure is executed to re-route the GTP/IP-Tunnels on S1-U (step 8) and releases the X2 UE context in the old MeNB (step 9)

The new MeNB then waits for a new inter-RAT measurement event B1 (step 11) before starting a new SgNB addition procedure (step 12).  Once the SgNB addition is successfully completed including all necessary reconfigurations/modifications on RRC and S1 the payload transmission over 5G resources is continued.

Inter-MeNB Handover with 5G Inter-Site Anchor

Now figure 2 shows what happens when the new MeNB decides to keep the existing UE context in the SgNB while the RRC measurement results and parameters are identical with what was presented above. 
Figure 2: X2 Handoverof EN-DC connection with 5G inter-site anchor

The difference in the call flow starts at step 5 when the new MeNB after receiving the X2AP Handover Request (step 4) starts the X2AP SgNB Addition procedure towards the SgNB (old = new!). The SgNB-UE-X2AP-ID earlier requested in step 2+3 acts as the reference number for the existing context that is going to be continued.

After adding the SgNB UE context successfully the new MeNB sends the X2AP Handover Request Acknowledge message including an UE Context Kept = "true" flag and the Handover Command (step 8).

After the UE successfully connected to the target cell of the new MeNB the S1AP Path Switch procedure is performed and the temporary X2 UE context between old and new MeNB is released (step 10).

The big advantage of handling the handover in this way: The duration of the interruption of the payload transmission over 5G radio resources is minimalized and subscriber experience is significantly better compared to the scenario in figure 1.

Friday, 22 November 2019

5G Call Drops in EN-DC: A Thread for Service Quality?


As explained in the post about EN-DC setup the addition of 5G NR radio resources to an ongoing LTE connection provides additional bandwidth for user plane data transmission. And it seems to be fair to say that at least in social media today 5G speed test results, especially throughput measurements, are treated as the benchmark for EN-DC service performance. Hence, it is also logical that a loss of the physical 5G radio link (5G drop) could have a serious impact on user experience.

I write "could", because as a matter of fact many 5G drops will not be recognized by subscribers using non-realtime services including HTTP streaming.

Due to the dual connectivity of LTE Master eNodeB (MeNB) and Secondary gNodeB (SgNB) the signaling trigger points indicating a 5G drop are also a bit more complex compared to what we know from LTE. Indeed, both network nodes are able to release 5G radio resources abnormally using three different X2AP message flow scenarios as shown in figure 1.

Figure 1: Three Basic Signaling Flows for Abnormal Release of 5G Radio Resources

Which of these individual message flows will be found in the trace data depends on which of the two base stations is the first one that detects a problem on the 5G radio link.

A particular case that is seen quite often in live networks is illustrated in figure 2.

Figure 2: 5G Drop due to SGC Failure in UE



Here the trigger is a LTE RRC SCG Failure Information NR message sent by the UE to the MeNB. Thus, the MeNB requests the release of 5G radio resources, which is acknowledged and executed by the SgNB.

In addition (not show in the figures) also the GTP/IP-Tunnel for user plane transport between S-GW and gNB is released by the MeNB after successful completion of the X2AP SgNB Release procedure.

For the UE the 5G drop is not as serious as a drop of the LTE radio connection would be. It is just a fallback on plain LTE, so to say. And after the switching the GTP/IP-Tunnel back to a downlink endpoint at the eNB 4G payload transmission continues.

The longer the overall duration of the radio connection the higher is the risk that the 5G radio resources are lost during an EN-DC call. One of my favorite cases is a subscriber with a radio connection that last a bit more than two and a half hours - see figure 3.

Figure 3: Location Session Record of a Single Subscriber indicating a total number 340 SgNB Drops over 2:33 Hours

Thanks to the smart algorithms of NETSCOUT's TrueCall geolocation engine there is high confidence that she or he sits in an indoor environment, but is served by an outdoor 5G cell. Thus, the penetration loss of the 5G signal is significant. Due to the higher frequency the path loss has also higher impact on the 5G than on the 4G radio signal. This seems to be the main reason why the 5G radio link drops as often as 340 times, which leads to an overall 5G (SgNB) Drop Rate of 83% for this connection.

However, the impact on the subscriber experience might not be a serious one as a different KPI, the 5G EN-DC Duration Rate indicates. According to the Duration Rate 99.99% of all the time 5G radio resources have been available for the subscriber. This is possible, because as also shown in figure 2 within a relatively short time new 5G radio resources are allocated again to this connection. Even if the subscriber is watching e.g. a Netflix video the buffering of already downloaded data on the end user device should be sufficient to conceal the short interruption of the data transfer over 5G resources.

With rising amount of EN-DC traffic it might be rather problematic for the network to handle the additional signaling load originating from the frequent 5G additions and releases. In extreme cases this may even lead to congestion due to CPU overload in RAN nodes or virtual network functions.

For realtime services like Voice over New Radio (VoNR) the entire situation changes. Here even short interruptions of the user plane radio transmission can be perceived by subscribers so that the above discussed 5G Duration Rate KPI will become insufficient to estimate the service quality. Hence, this will drive the demand for a fully integrated view of 5G RAN and Core KPIs covering both, signaling and application quality.




Monday, 7 October 2019

Exploiting Possible 5G Vulnerabilities


The standards can try their best to ensure that the next generation of protocols is more secure than the previous one but there is always some way in which the protocols can be exploited. This is where researchers play an important role in finding such vulnerabilities before they can be exploited by hackers. Frankly I am quite sure that only a handful of these vulnerabilities are found and hackers always have something that may never be found.

In the recent HITBSecConf or the Hack In The Box Security Conference Altaf Shaik presented "4G to 5G: New Attacks". He along with Ravishankar Borgaonkar has been working to find out issues with security in cellular networks. In fact in the GSMA Mobile Security Hall of Fame, they both appear twice, individually.

From the talk narrative:

5G raises the security bar a level above 4G. Although IMSI exposure is prevented in 5G, we found new vulnerabilities to attack devices and subscribers. In this talk we expose a set of vulnerabilities in the 5G/4G protocols that are found in network operators equipment and also consumer devices such as phones, routers, latest IoT sensors, and even car modems. Our vulnerabilities affect several commercial applications and use cases that are active in 4G networks and are expected to take off in 5G networks. We developed automated tools to exploit the exposed cellular information and share some of our research traces and data sets to the community. We demonstrate a new class of hijacking, bidding down and battery draining attacks using low cost hardware and software tools. We did a rigorous testing worldwide to estimate the number of affected base stations and are surprised by the results. Finally our interactions with various vendors and standard bodies and easy fixes to prevent our attacks are discussed.

Slides and Video is embedded below






Slides and Whitepaper can be downloaded from here.

Further Reading:

Thursday, 18 July 2019

5G SpeedTests and Theoretical Max Speeds Calculations


Right now, Speed Tests are being described as 5G killer apps.



A good point by Benedict Evans



Everyone is excited and want to see how fast 5G networks can go. If you use Twitter, you will notice loads and loads of speed tests being done on 5G. An example can be seen above.


I recently heard Phil Sheppard, Director of Strategy & Architecture, '3 UK' speak about their 5G launch that is coming up soon. Phil clearly mentioned that because they have a lot more spectrum (see Operator Watch blog post here and here) in Capacity Layer, their 5G network would be faster than the other UK operators. He also provided rough real world Peak Speeds for Three and other operators as can be seen above. Of course the real world speeds greatly depend on what else is going on in the network and in the cell so this is just a guideline rather than actual advertised speeds.


I have explained multiple times that all 5G networks being rolled out today are Non-Stand Alone (NSA) 5G networks. If you don't know what SA and NSA 5G networks are, check this out. As you can see, the 5G NSA networks are actually 4G Carrier Aggregated Networks + 5G Carrier Aggregated Networks. Not all 4G spectrum will be usable in 5G networks but let's assume it is.

To calculate the theoretical maximum speed of 5G NSA networks, we can calculate the theoretical maximum 4G Network speeds + theoretical maximum 5G Network speeds.

I have looked at theoretical calculation of max LTE Carrier Aggregated Speeds here. Won't do calculation here but assuming 3CA for any network is quite possible.

I also looked at theoretical calculation of 5G FDD New Radio here but then found a website that helps with 5G NR calculation here.

If we calculate just the 5G part, looking at the picture from Three, we can see that they list BT/EE & O2 speeds as 0.61 Gbps or 610 Mbps, just for the 5G part.

Looking at the calculation, if we Input Theoretical max values in this equation:

Calculating just for DL

J - number of aggregated component carriers,
maximum number (3GPP 38.802): 16
input value: 1

v(j)Layers - maximum number of MIMO layers ,
3GPP 38.802: maximum 8 in DL, maximum 4 in UL
input value: 8

Q(j)m modulation order (3GPP 38.804)
For UL and DL Q(j)m is same (QPSK-2, 16QAM-4, 64QAM-6, 256QAM-8)
input value: 8 (256QAM)

f(j) Scaling factor (3GPP 38.306)
input value: 1

FR(j) Frequency Range 3GPP 38.104:
FR1 (450 MHz – 6000 MHz) и FR2 (24250 MHz – 52600 MHz)
input value: FR1

µ(j) -value of carrier configuration (3GPP 38.211)
For DL and UL µ(j) is same (µ(0)=15kHz, µ(1)=30kHz, µ(2)=60kHz, µ(3)=120kHz)
input value: 0 (15kHz)

BW(j)- band Bandwidth, MHz (3GPP 38.104),
should be selected with Frequency Range and µ(i) configuration:
input value: BW:40MHz FR1 µ:15kHz:

Enter a PRB value (if other)
default: 0

Rmax (if you don't know what is it, don't change)
Value depends on the type of coding from 3GPP 38.212
(For LDPC code maximum number is 948/1024 = 0.92578125)
default: 0.92578125

*** Only for TDD ***
Part of the Slots allocated for DL in TDD mode,
where 1 = 100% of Slots (3GPP 38.213, taking into account Flexible slots).
Calculated as: the number of time Slots for DL divided by 14
default value: 0.857142

Part of the Slots allocated for UL in TDD mode,
where 1 = 100% of Slots (3GPP 38.213, taking into account Flexible slots).
Calculated as: 1 minus number of Slots for DL
default value: 0.14285800000000004

Calculated 5G NR Throughput, Mbps: 1584


As you may have noticed, BTE/EE has 40 MHz spectrum while Vodafone in UK have 50 MHz of spectrum.

Changing
BW(j)- band Bandwidth, MHz (3GPP 38.104),
should be selected with Frequency Range and µ(i) configuration:
input value: BW:50MHz FR1 µ:15kHz:

Calculated 5G NR Throughput, Mbps: 1982

Now Three UK has 100 MHz, immediately available for use. So changing

µ(j) -value of carrier configuration (3GPP 38.211)
For DL and UL µ(j) is same (µ(0)=15kHz, µ(1)=30kHz, µ(2)=60kHz, µ(3)=120kHz)
input value: 1 (30kHz)

BW(j)- band Bandwidth, MHz (3GPP 38.104),
should be selected with Frequency Range and µ(i) configuration:
BW:100MHz FR1 µ:30kHz:


Calculated 5G NR Throughput, Mbps: 4006

In theory, a lot of speed is possible with the 100 MHz bandwidth that Three will be able to use. We will have to wait and see who can do a theoretical max SpeedTest. In the meantime remember that a 1Gbps speed test will use over 1 GB of data.



Related Posts: