EPS Fallback in 5G Standalone Deployments

It can be expected that later this year some mobile network operators will launch their initial 5G standalone (5G SA) deployments.

Nevertheless there will remain areas with temporary or permanently weak 5G NR coverage. One possible reason might be that even when 5G and LTE antennas are co-located, which means: mounted at the same remote radio head, the footprint of the 5G NR cell is significantly smaller when it uses a higher frequency band than LTE - see figure 1.

Figure 1: Smaller footprint of co-located 5G NR cell with higher frequency

Especially UEs making Voice over New Radio (VoNR) calls from the 5G cell edge have a high risk of experiencing bad call quality, in worst case a call drop. To prevent this the UE is forced  during the voice call setup towards 5G core network (5GC) to switch to a LTE/EPS connection where the radio conditions are better for the voice service.

The same procedure for which the term "EPS Fallback" was coined by 3GPP also applies when the UE is served by a 5G cell that is not configured/not optimized for VoNR calls or when the UE does not have all needed VoNR capabilities.

Figure 2: Two options for EPS fallback

When looking at the RAN there are two options for executing the EPS Fallback as shown in figure 2.

In option A the 5G radio connection is released after the initial call attempt is successfully finished and with the 5G RRC Release the UE is ordered to reselect to a 4G cell where a new radio connection is started for the VoLTE call. In this case the UE context is transferred from the AMF to the MME over the N26 interface. 3GPP seems to use also the term "RAT fallback" for this option.

Option B is to perform a 5G-4G inter-RAT handover. Here the session management and user plane tunnels in the core network are handed over from SMF/UPF to MME/S-GW in addition. This is realized with the GTPv2 Forward Relocation procedure on N26 interface.

All in all the EPS fallback is expected to cause an additional call setup delay of approximately 2 seconds.

For the inter-RAT handover case it is easy to detect from signaling information that an EPS fallback was triggered. In the source-eNodeB-to-target-eNodeB-transparent-container sent by the gNB to the eNB a boolean "IMS voice EPS fallback from 5G" indicator will be found that is set to "true". This container is named according to the receiving entity and will be carried by the NGAP Handover Preparation, GTPv2 Forward Relocation Request and the S1AP Handover Request messages.

If a redirection for Voice EPS Fallback is possible or not is indicated in the NGAP Initial Context Setup Request, Handover Request (during 5G intra-system handover) and Path Switch Request Acknowledge (after Xn handover) messages, all sent by the AMF to the gNB.

Further the NGAP protocol provides the cause value "IMS voice EPS fallback or RAT fallback triggered" in the PDU Session Resource Modify Response message indicating that a requested VoNR session cannot be established.  

An excellent, very detailed description of N26 interface functionality and testing ia available here.

AI your Slice to 5G Perfection

Back in November, The Enhanced Mobile Broadband Group in CW (Cambridge Wireless) held an event on 'Is automation essential in 5G?'. There were some thought provoking presentations and discussions but the one that stood out for me was by Dan Warren from Samsung

I consider that to be quite an achievement. I'll take it as a compliment #cwembb

— Dr. Dan Warren (@TMGB) November 28, 2019

The slides are embedded below but I want to highlight these points:

• Some Network Functions will be per slice whereas others will be multi-slice, the split may not be the same for every slice
• Two slices that have the same 'per slice vs multi-slice' functional split may be different network hardware topologies
• Enterprise customers will likely want a 'service' contract that has to be manifested as multiple slices of different types. 
• Physical infrastructure is common to all slices

The last point is very important as people forget that there is a physical infrastructure that will generally be common across all slices.

Again, when you apply Artificial Intelligence (AI) to optimize the network functions, does it do it individually first and then end-to-end and if this is applied across all slices, each of which may have a different functionality, requirement, etc. How would it work in practice?

Agree with pretty much all of this, but there are other points. Key to success of this as a 'full industry' solution is how slicing works when roaming and across interconnect. That is fundamental to SLA support on fully mobile devices and applications (inc. NPN to MNO mobility)

— Dr. Dan Warren (@TMGB) February 4, 2020

5G - Peak Complexity from 3G4G

As Dan says in his tweet, "It is hard to implement AI to optimise a point solution without potentially degrading the things around it.  Constantly being pushed to a bigger picture view => more data => more complexity"

Let me know what you think.

Related Posts:

• Tutorial: Service Based Architecture (SBA) for 5G Core (5GC)
• Exploring Network Convergence of Mobile, Broadband and Wi-Fi
• Prof. Andy Sutton: Backhauling the 5G Experience - Jan 2020
• 5G Core Architecture Webinar from Apis
• 5G and Fixed-Mobile Convergence (FMC)
• Updated 5G Terminology Presentation

Prof. Andy Sutton: Backhauling the 5G Experience - Jan 2020

Prof. Andy Sutton has shared quite a few presentations and talks on this blog. His presentations from the annual 'The IET 5G Seminar' has made it to the top 10 for the last 3 years in a row. His talk from 2019, 2018 & 2017 is available for anyone interested.

The title of this year's conference was '5G 2020 - Unleashed'. The details are available here and the video of all the talks are here. As always, the slides and video is embedded below.

Slides

Prof. Andy Sutton: Backhauling the 5G Experience from 3G4G

Video


There are a lot of bands that keep on getting mentioned, especially in relation to backhaul. Here is a summary of these bands that would come handy.

Related Posts:

• Prof. Andy Sutton: 5G Radio Access Network Architecture Evolution - Jan 2019
• Prof. Andy Sutton: 5G Network Architecture, Design and Optimisation - Jan 2018
• Prof. Andy Sutton: 5G Network Architecture and Design Update - Jan 2017
• Prof. Andy Sutton #CWHeritage Talk: The History of Synchronization in Digital Cellular Networks
• Connectivity Technology Blog: An Introduction to Different Types of Backhaul
• 5G Evolution with Matthew Baker, Nokia
• Exploring Network Convergence of Mobile, Broadband and Wi-Fi
• 5G and Fixed-Mobile Convergence (FMC)

NTT Docomo's Vision on 5G Evolution and 6G

NTT Docomo released a whitepaper on 5G Evolution and 6G. In a press release they announced:

NTT DOCOMO has released a white paper on the topic of 6G, the sixth-generation mobile communications system that the company aims to launch on a commercial basis by 2030. It incorporates DOCOMO's views in the field of 5G evolution and 6G communications technology, areas that the company has been researching since 2018. The white paper summarizes the related technical concepts and the expected diverse use cases of evolving 5G and new 6G communication technologies, as well as the technology components and performance targets.

Mobile communication systems typically evolve into the next generation over a period of roughly ten years; DOCOMO commenced its research into the commercial launch of 5G in 2010. In 2018, the company conducted successful radio wave propagation experiments at frequencies of up to 150 GHz, levels which are expected to enable the much faster and larger-capacity communications that 6G will require.

DOCOMO will continue to enhance the ultra-high-speed, large-capacity, ultra-reliable, low-latency and massive device-connectivity capabilities of 5G technology. It will continue its research into and development of 5G evolution and 6G technology, aiming to realize technological advances including:

• the achievement of a combination of advances in connectivity, including ultra-high speed, large capacity and low latency
• the pioneering of new frequency bands, including terahertz frequencies
• the expansion of communication coverage in the sky, at sea and in space
• the provision of ultra-low-energy and ultra-low-cost communications
• the ensuring of highly reliable communications
• the capability of massive device-connectivity and sensing

Visitors to DOCOMO Open House 2020 will be able to view conceptual displays incorporating DOCOMO's vision of the evolution of 5G technologies into 6G. The event will take place in the Tokyo Big Sight exhibition complex in Tokyo on January 23 and 24. DOCOMO also plans to hold a panel session entitled "5G Evolution and 6G" on January 24.

Videos from Docomo Open House are embedded below, along with a previous talk by Takehiro Nakamura from 6G Summit.


6G has become a hot topic, especially after China announced back in November that they are working on 6G. We have some interesting tweets on 6G as well.

This one from Stefan Pongratz, Dell'Oro group shows the timeline for 5G, Pre-6G and 6G

5G is not all the same by @StefanPongratz - https://t.co/5ladQa2RGC #SA #NSA #6G #eMBB #URLLC #mMTC #FWA

Ties in nicely with #CWTEC theme @cambwireless @zahidtg pic.twitter.com/R6FfwhUG1J

— 3G4G (@3g4gUK) August 9, 2019

This one provides a timeline all the way from Release 99 up till 21

3GPP Release - Technology
99 - UMTS (3G)
4
5 - HSDPA (3.5G)
6 - HSUPA
7 - HSPA+
8 - LTE (3.9G)
9
10 - LTA-A (4G)
11
12
13 - LTE-A Pro (4.5G)
14
15 - 5G
16
17
18 - 5.5G?
19
20
21 - 6G?#CWTEC #3G4G5Gpic.twitter.com/vQi5Dhfsno

— 3G4G (@3g4gUK) October 8, 2019

Finally, here is a tweet highlighting the 6G research

6G Research Directions and Vision (with source) for anyone interested - https://t.co/i9XzG3bjFv - frankly that's really high expectations and we worry about laws of physics. 10-100μs latency?
(Paging @IEEEFutureNtwks @ComSoc @PhantomBenn @alainmouradUK @simonchapman ) #CWTEC pic.twitter.com/5dQQxDoQp0

— 3G4G (@3g4gUK) August 16, 2019

Finally, the paper acknowledges the 5G challenges and focus areas for 5G evolution, before focusing on 6G.

The mmWave coverage and mobility needs improvement, while the downlink is able to provide very high data rates, the uplink is struggling to be better than 4G. Also, there are some very extreme requirements for industrial use cases, 5G has yet to prove that it can meet them.

Finally, here is another view from iDate Digiworld comparing 5G vs 6G in terms of performance, spectrum and network.

Related Posts:

• 6G: Above 100 GHz and Terahertz (THz) Frequencies
• 3GPP Release-16, Release-17 & Beyond...
• Couple of talks by NTT Docomo on 5G and Beyond (pre-6G)
• Slides and Videos from the 1st 6G Wireless Summit - March 2019
• ITU 'Network 2030': Initiative to support Emerging Technologies and Innovation looking beyond 5G advances

How MOCN RAN-Sharing Works

Shared RAN deployment scenarios are an excellent opportunity for mobile network operators to lower their investments on both, network hardware and operational costs by sharing resources.

The MORAN approach where each operator continues to have its dedicated spectrum (= radio network cells) is easy to understand.

However, the Multi-Operator Core Network (MOCN) is a bit more complex, especially if one of the involved operators asks for service assurance KPIs that apply to its - and only its - subscribers. In this case it is a prerequisite to find out which "call" belongs to which core network operator to enable further KPI correlation and aggregation.

The figure below illustrates how this works:

(click on picture for larger version)

In the System Information Block (SIB) 1 of the cell a list of PLMN-IDs is broadcasted followed by a single Tracking Area Code (which can be combined each of the PLMN-IDs to get multiple TAIs) and a single Cell Identity.

Encoding is specified in 3GPP 36.331 (RRC) as follows:

SystemInformationBlockType1 ::=     SEQUENCE {

    cellAccessRelatedInfo              SEQUENCE {

       plmn-IdentityList                 PLMN-IdentityList,

       trackingAreaCode                  TrackingAreaCode,

       cellIdentity                      CellIdentity,

The spec further defines that the ECGI is the CellIdentiy combined with the first (!!!) PLMN-ID from the PLMN-ID List:

CellGlobalIdEUTRA field descriptions
cellIdentity Identity of the cell within the context of the PLMN.
plmn-Identity Identifies the PLMN of the cell as given by the first PLMN entry in the plmn-IdentityList in SystemInformationBlockType1.

So there is one and only 1 ECGI per radio cell in the network, but multiple PLMN-IDs and hence, multiple TAI, one fore each core network operator, are broadcasted.

During RRC establishement a particular UE signals on behalf on the selected PLMN-ID information element in the RRC Connection Setup Complete message to which core network operator shall be used.

This information is "translated" by the eNB into ECGI and TAI with different PLMN-IDs. While the ECGI displays the PLMN-ID of the operator that owns the RAN equipment the TAI shows the selected PLMN-ID of the UE's core network operator. 

Related Posts:

• The 3G4G Blog: Quick tutorial on Mobile Network Sharing Options
• The 3G4G Blog: Mobile Network Infrastructure Sharing in Japan over Electric Power Infrastructure
• The 3G4G Blog: A practical use of MOCN in ESN

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.

The 5G Evolution: 3GPP Releases 16-17 white paper from @5GAmericas highlights specific updates in Releases 16-17. Good whitepaper, worth reading - https://t.co/wVHBj7ZunE #Free5GTraining pic.twitter.com/lshYbzP5ne

— 5G Training (@5Gtraining) January 18, 2020

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)

EN-DC SRB3 Demystified

3GPP 37.340 says that it is up the secondary node to establish "SRB3", but what exactly does this mean and how is it done?

Simple answer: The establishment of a signaling radio bearer (SRB) 3 in EN-DC mode means that RRC Measurement Reports for NR quality can be sent directly to the SgNB. This enables the 5G node to make intra-SgNB handover decisions and start the handover execution without involving the master eNodeB of the connection.

To prevent confusion the figure below shows a simplified scenario in which the Complete/Acknowledgement messages are not mentioned although they will be seen in the message flow.

A prerequisite is the successful addition of 5G radio resources as described in an earlier blog post. After this is completed the UE in the example transmits user plane information over the NR cell with the physical cell ID (PCI) = 12. In the transport network this cell is identified by NR CGI = xxxx52 (where „xxxx“ stands for a valid PLMN-ID and gNodeB-ID).

In the figure below the SgNB sends a X2AP SgNB Modification Required message that carries an embedded NR RRC cG-Config message. This cG-Config message is transparently forwarded by the MeNB to the UE. When arriving at the UE it activates CSI reference signal measurements on the 5G frequency including the serving 5G cell as well as its neighbors. It shall be noticed that here the concept of the Special Cell (SpCell) applies as it was defined for LTE-A CoMP scenarios. 

Instead of the X2AP SgNB Modification Required message the information for activating the CSI reference signal measurements can alternatively transported using the X2AP SgNB Addition Request Acknowledge or X2AP SgNB Change Required message.

In step 2 the UE sends a NR RRC (3GPP 38.331) Measurement Report that indicates a stronger 5G cell (the neighbor cell with PCI = 11) was measured. It might be a vendor-specific implementation to send this NR RRC Measurement Report simultaneously over uplink channels of the LTE radio link where it is carried by the LTE RRC Uplink Information Transfer MRDC (Multi-RAT Dual Connectivity) as well as over NR radio links where it is forwarded by the SgNB to the MeNB embedded in a X2AP RRC Transfer message.

Indeed, it is the SgNB that makes the handover decision, but since the MeNB is in charge of the signaling connection the handover command (here: another NR RRC cG-Config message that orders to switch the 5G radio link to the cell with PCI = 11) must be transmitted to the MeNB by using another X2AP SgNB Modification Required message.

After the UE received the NR CC cG-Config message sent by the SgNB the HO is executed and the 5G cell with PCI = 11 becomes the new primary secondary cell of the EN-DC connection.

Figure: Measurement Configuration, Reporting and Execution for intra-SgNB  Handover 

Free 5G Training

Many readers of this blog would be aware that I run 5G 'An Advanced Introduction to 5G Technology' training course for Cambridge Wireless at regular intervals. The next one is on 10th March 2020, in Cambridge. In fact I am also running a 'Introduction to Private 4G & 5G Networks' workshop on 4th Feb 2020 in London.

Many people ask me if they I have an online course available. While I haven't, I have quite a few videos on 3G4G YouTube channel and also have a 3G4G training page. People (mainly students or newbies) still ask me what sequence of videos they should go through, etc. So to make everyone's life simple, I created 2 YouTube playlists. Both are embedded below for ease.

Part 1. This is for people who know basic telecommunications theory and don't know much about mobile technology in general




Part 2. This is for people who understand 2G/3G/4G basics and want to learn about 5G.


I will add/remove/update videos when we add new videos on our channel. Feel free to skip videos if you already know a topic. There is quite a lot of other information on the 3G4G YouTube channel if you want to explore more

Where do you go after you have watched these videos? Go to the 3GPP homepage and start looking at specifications, news, etc. You can also start looking at the specifications on 3G4G page here.

Hopefully this is a good starting point.

SEE ALSO: https://www.free5gtraining.com/

Top 10 posts for 2019

As one would guess, 2019 was dominated by 5G and so was this blog. Surprisingly the most popular post was on Open RAN. Most likely because many people did not understand what the term meant.

People still continue to ask us when we will be changing the 3G4G name. We will change it when 3GPP (whose name is derived from 3G) and/or GSMA (whose name is derived from 2G/GSM) change their name. In short, never!

Here are the posts, from most popular to the tenth most popular, in descending order of popularity

1. A quick tutorial on Open RAN, vRAN & White Box RAN - Feb 2019

2. Displaying 5G Network Status Icon on Smartphones and Other Devices - Feb 2019

3. Prof. Andy Sutton: 5G Radio Access Network Architecture Evolution - Jan 2019

4. Theoretical Throughput Calculation of FDD 5G New Radio (NR) - Feb 2019

5. New 3GPP Release-17 Study Item on NR-Lite (a.k.a. NR-Light) - Aug 2019

6. Slides and Videos from the 1st 6G Wireless Summit - Apr 2019

7. Examples of 5G Use Cases & Applications - May 2019

8. Updated 5G Terminology Presentation - Mar 2019

9. 3GPP 5G Standardization Update post RAN#84 - July 2019

10. Exploiting Possible 5G Vulnerabilities - Oct 2019

Finally, a post from 2018 that continued to perform brilliantly this year

11. 5G Network Architecture Options (Updated) - Oct 2018

If you had a favorite post, let us know which one.

Related Posts:

• Telecoms Infrastructure Blog: Top 5 posts for 2019
• Operator Watch Blog: Top 5 Posts for 2019
• The 3G4G Blog: Top 10 posts for 2018
• The 3G4G Blog: Top 10 posts for 2017 and some other 3G4G info
• The 3G4G Blog: Top 10 posts for 2016
• The 3G4G Blog: Top 10 posts for 2015

5G Integrated Access and Backhaul (IAB) Enhancements in Rel-17

It's been a while since I last wrote about IAB on this blog here. At that time 3GPP Release-16 was being discussed. Since then things have moved on. While Release-16 is being prepared for final release soon, Release-17 study and work items have just been agreed upon.

IAB is included as part of Rel-16 but there isn't a comprehensive document or presentation easily available to details all that it will contain. Similarly the enhancements for Release-17 are available only superficially. Qualcomm is well known for making some really excellent presentations available on 5G. One of their presentations from January (here) has some details on IAB (pg. 32 - 35). There was also an excellent presentation by Navid Abedini, Qualcomm from IEEE Sarnoff Symposium, 2019 which is embedded at the end.

In a 3GPP RAN#84 discussion document RP-191181, Samsung has provided a comprehensive summary of what is being done as part of Rel-16 and what did not make in that:

• Rel-16 IAB aims at basic operations
• Architecture and protocol design
• IAB integration procedure 
• Routing, BAP and BH configuration
• CP and UP data transmission  via IAB
• Topology support: 
• Spanning Tree (ST) and Directed acyclic graph (DAG) 
• Intra-Donor adaptation is prioritized
• The following cannot  be supported in Rel-16
• Mobile IAB
• Topology support: Mesh
• Some functionalities in Rel-16 may not be completed due to time constrains e.g. 
• Topology adaptation between IAB donors
• Mechanisms for efficient control signaling transmission

Ericsson also provides a good summary in RP-190971 regarding Release 16 IAB and Rel-17 enhancements:

• IAB Rel-16 provide basic support for multi-hop and multi-path relaying. 
• The solution supports 
• QoS prioritization of traffic on the backhaul link
• Flexible resource usage between access and backhaul
• Topology adaptivity in case link failure
• In Rel-17 it would be possible to further evolve the IAB solution targeting increased efficiency and support for new use cases

Meanwhile in the recently concluded RAN#86, AT&T provided a good detailed summary on what enhancements are required for IAB as part of Rel-17 in RP-192709

• Duplexing enhancements
• Multiplexing beyond TDM (FDM/SDM/multi-panel Tx/Rx) including multi-parent scenarios, case 6/7 timing alignment, power control/CLI optimizations
• Topology enhancements
• Mobile IAB: CP/UP split + Group mobility 
• Inter-CU topology adaptation
• Mesh-connectivity between IAB nodes for local control/user plane routing
• User plane enhancements
• Multi-hop scheduling enhancement – exchange of benefit metric between IAB nodes to enable radio-aware multi-hop scheduling to improve throughput performance
• Network Coding
• Study benefits compared to duplication over redundant backhaul routes

We will have to wait and see what makes it into the enhancements and what don't. Meanwhile here is a video from Navid Abedini, Qualcomm from IEEE Sarnoff Symposium, 2019




Related Posts:

• Connectivity Technology Blog: Integrated Access and Backhauling (IAB) - Today and Tomorrow
• 5G Evolution with Matthew Baker, Nokia
• Summary of #CWTEC 2019 Conference: 5G, Satellites & Magic MIMO
• 5G and Fixed-Mobile Convergence (FMC)
• R&S Webinar on LTE-A Pro and evolution to 5G
• Introduction to NR-Light a.k.a. NR-Lite
• An Introduction to Non-Terrestrial Networks (NTN)