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

Wednesday 1 April 2020

A Look into 5G Virtual/Open RAN - Part 2

In the first blog post of this series the different virtual RAN functions, interfaces and protocols have been discussed. Now it is time to have a look at a set of procedures that are required for the establishment of an UE connection in virtual 5G RAN.

The Big Picture

In 5G standalone RAN the crucial elements for user plane payload transport of an UE connection are  GTP/IP transport tunnels and a dedicated radio bearer on the radio interface.

When looking at the 5G RAN there are two of such tunnels: one on NG-U (aka N3) that is controlled by NGAP, and one on F1-U that is controlled by F1AP - see figure 1.

On behalf  of these two tunnels payload data can be transported between the 5G core network User Plane Function (UPF) to the gNB Distributed Unit (gNB-DU) and vice versa. For the transport over the 5G RAN fronthaul (realized e.g. as eCPRI) and across the radio interface a dedicated radio bearer (DRB) for the user plane transport must be configured by the gNB Central Unit for the Control Plane (gNB-CU CP).

As in LTE it is the RRC protocol that establishes this DRB. However, due to the virtualization the different protocol layers for the air interface are also distributed and the gNB-DU is in charge of all the lower layer PHY/RLC/MAC parameters (e.g the c-RNTI), while the gNB-CU CP assigns higher layer parameters of PDCP and RRC like the DRB-ID. Since only the gNB-CU CP can send downlink RRC messages to the UE the lower layer parameters from the DU first need to be sent in uplink direction to the gNB-CU CP.

Beside this parameter exchange the F1AP is also responsible for the tunnel management of the F1-U Tunnel.

The downlink tunnel endpoint information is provided by the gNB-DU using F1AP, but the uplink tunnel endpoint terminates at the gNB-CU UP and thus, its endpoint parameters are received by the gNB-CU CP when it exchanges information with the gNB-CU UP on behalf of the E1AP protocol.

Figure 1: Network Functions, Protocols and Parameters involved in Setup of User Plane Data Transmission Resources
(click on the image to see full size)
A similar situation we see for the NG-U tunnel that is controlled by NGAP, the protocol for communication between gNB-CU CP and the Access and Mobility Management Function (AMF) in the 5G core. Neither the gNB-CU CP nor hte AMF have direct access to the NG-U tunnel endpoints. Hence, E1AP is used again to transmit the downlink tunnel parameters to the gNB-CU CP while the uplink tunnel endpoint parameters must be sent by the UPF to the Session Management Function (SMF) using the Packet Forwarding Control Protocol (PFCP) and later by the SMF to the AMF over the service-based interface where the tunnel endpoint parameters are embedded in a JavaScript Object Notation (JSON) container.

By the way, JSON is a quite generic format for exchanging and storing different kind of data. Between the AMF and the SMF JSON is used to transport Non-Access Stratum Session Management messages (defined in 3GPP 24.501).

The Ladder Diagram

Having the Big Picture in mind it is now easier to look at the ladder diagram with the individual RAN messages for UE connection setup - shown in Figure 2.

It looks complicated, because the F1AP messages carry RRC plus NAS messages in uplink and downlink direction, but when understanding the underlying logic it is easy.

Figure 2: 5G VRAN Successful UE Connection Setup
(click on the image to see full size)

The very first step (in the figure: step 0) is the random access procedure executed on the MAC layer involving the UE and the gNB-DU.

After successful random access the UE sends the NR RRC Setup Request message. This is the Initial UL RRC Message transported by the F1AP from the gNB-DU to the gNB-CU CP. Actually the F1AP carries PDCP transport blocks and inside the PDCP the NR RRC messages are found, but to keep it simple I do not show the PDCP header in the ladder diagram.

Beside RRC Setup Request there are also some other initial NR RRC messages and RRC response messages possible (see step 1 and 2).

More RRC messages are transported over F1AP until the RRC Connection establishment is complete.

The NR RRC Setup Complete message also transports the initial NAS message and the reception of this message by the gNB-CU CP triggers the setup of a F1AP UE context. The concept of UE context management in F1AP is the same as in NGAP or - when looking back into the E-UTRAN - in S1AP.

The GTP/IP transport tunnel on F1-U is established during F1AP UE Context Setup assisted by E1AP Bearer Context Setup procedure that provides the necessary tunnel endpoint parameters.

In the same manner the NG-U tunnel is established by the NGAP Initial UE Context Setup procedure.

Additional NAS messages (especially for session management) and NR RRC Reconfiguration are exchanged to establish the end-to-end UE connection through the core network. And that's it.

Related Posts:

Monday 9 March 2020

How LTE RRC (4G) and NR RRC (5G) Protocols are used in Parallel in EN-DC (5G NSA)

Last week I had a fruitful discussion with a fellow blogger on the web, Martin Sauter (@mobilesociety) regarding a post in which he compared features of LTE RRC (3GPP 36.331) and NR RRC (3GPP 38.331).

It was Martin's impression that the NR RRC protocol is primarily designed to be used in the 5G standalone mode. However, as I wrote in a comment to his post the NR RRC protocol is already used in EN-DC radio connections.

The reason is that the UE must be informed about Hundreds of lower layer 5G parameters (physical, MAC, RLC) that are needed for the payload transmission over 5G frequencies. Indeed, when it comes to user plane data transmission the gNB works almost independently and the UE must handle LTE and NR radio links in parallel.So it has two different radio units (even if combined into a single radio chip set). This double-functionality is also one important reason why 5G smartphones are quite expensive. It is a lot of software and know-how that sits inside these chips.

How much surplus code is really necessary to enable 5G technology becomes visible when looking at trace data using a state-of-the-art protocol test and monitoring tool.

When reading the 3GPP 36.331 (LTE RRC) standard document one might have the impression that just a few 5G parameters have been incorporated into this protocol to support EN-DC connections.

However, when looking into the details of e.g. the nr-SecondaryCellGroupConfig-r15 it turns out that some this single information element is indeed a huge block of NR information (total size: 1111 Byte)

It is an entire 5G RRC message (rRCReconfiguration) that is piggybacked by the LTE rrcConnectionReconfiguration message, because in 5G non-standalone mode this is the only way to transmit 5G signaling information to the UE. And as highlighted in the upper part of the screenshot there are a couple of NR RRC messages transported in so-called NR-RRCContainers* during the EN-DC Establishment Procedure.

And what about 5G standalone mode? For this radio access technology the 3GPP 38.331 Rel. 15 protocol is suitable as well. Hence, some parameters mentioned in the standard paper will never be seen in EN-DC. A perfect example is S-NSSAI (Single Network Slice Selection Assistance Information), because network slicing requires the connection with a 5G core network as a prerequisite. 


(click on image for larger version)

* This is not an 3GPP term, but coined by the developers of the decoding engine.

Wednesday 4 March 2020

A Look into 5G Virtual/Open RAN - Part 1

Although it is understood in general that virtualization and increasing complexity are inherent characteristics of 5G networks many people are surprised when they realize the significant differences of 5G RAN architecture and signaling procedures compared to what they know from LTE or UTRAN.

In this blog post series I want to highlight some details that are not immediately visible when reading the 3GPP specs.

Figure 1 shows a virtualized gNB and the protocols it uses to communicate with its internal entities as well as with the UE and peer entities in neighbor network elements/functions.

Figure 1: Virtual Network Functions and Protocols in 5G RAN
(click on the image to see full size)

The core of the whole thing is the gNB-Central Unit for the Control Plane (gNB-CU CP). This function communicates directly with the UE using the NR RRC protocol. It also "talks" to the 5G Core Network represented by the AMF using the NGAP, a protocol very similar to the S1AP known from E-UTRAN. Neighboring 5G base stations are contacted using the XnAP, neighboring eNBs can be reached by using X2AP.

The other virtual functions of the gNB are the Central Units for User Plane (gNB-CU UP) and the Distributed Units (gNB-DU). While the gNB-CU UP is responsible for handling the transport of payload the gNB-DUs deal with all the allocation of radio resources, especially the scheduling. As a result the lower layer radio interface protocols, especially RLC and MAC terminate in the gNB-DUs.

For the RAN monitoring tools and the 3GPP Minimization of Drive Test (MDT) feature this means that RRC and Logged Measurement Reports sent by UEs will be available at gN-CU CP while all uplink radio quality measurements and call-related user plane metrics is only available at the gNB-DU - see figure 3.

Figure 2: Distribution of un-correlated RAN measurement tasks among different gNB virtual functions
(click on the image to see full size) 

And today, there is no 3GPP-standardized procedure to correlate this measurement information collected by different virtual gNB functions.

The full impact of the 5G RAN virtualization becomes even more evident when looking at Figure 3. It shows a single gNB-CU CP in charge of controlling several gNB-CU UPs and gNB-DUs.

In a live network deployment a single gNB-CU CP will control hundreds of gNB-DUs and maybe several gNB-CU UPs. This is why it is misleading to compare the connectivity of a gNB-CU CP with that of a LTE eNB. Rather it could be compared with a UTRAN RNC controlling a similar number of 3G base stations.


Figure 3: 5G RAN Connectivity
(click on the image to see full size)

Looking back into figure 1 we see that the F1AP is used for communication between gNB-CU CP and its gNB-DUs while the E1AP is the protocol that connects the gNB-CU CP with surrounding gNB-CU UPs.

Call-related control plane procedures of F1AP and E1AP are very similar to what is known from NGAP. There is a UE context established between the gNB-CU CP and the gNB-DU. On F1-U a GTP tunnel is established for user plane transport. At the same time an E1 Bearer Context in gNB-CU CP and gNB-CU UP keeps track of the most relevant user plane transport parameters.

All in all for setting up a single subscriber connection in the virtualized 5G RAN there are significantly more signaling transactions necessary than in E-UTRAN. Figure 4 shows a practical example.

Figure 4: 5G RAN Call Trace in NETSCOUT Session Analyzer
(click on the image to see full size)
The volume and complexity of signaling information is increasing when the UE moves or is redirected to virtual functions within one gNB e.g. due to load balancing.

The next blog post of this series will dive deeper into details of such call scenarios.

Stay tuned...

Related Posts:

Sunday 1 March 2020

5G Private and Non-Public Network (NPN)


Private Networks have been around for a while and really took off after 4G was launched. This is due to the fact that the architecture was simplified due to the removal of CS core and also the advancements in silicon, storage, computation, etc. allowed creation of smaller and more efficient equipment that simplified private networks.

While private networks imply an isolated network for selected devices that are allowed to connect on to the network, Non-Public Networks are much broader in scope. Chief among them is the ability of certain devices to be capable of working on Private as well as Public Network or roaming between them.

I recently ran a workshop on 'Introduction to Private 4G & 5G Networks' with a well known Industry analyst Dean Bubley. One of the sections looked at the Network Architecture based on the 3GPP standards. This tutorial is a part of that particular section. Slides and video embedded below. There are also some interesting videos on YouTube that show how and why Private Networks are needed and some use cases. The playlist is embedded in the end.






Playlist of Private Networks Use Cases.



Related Posts:

Friday 21 February 2020

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.

Wednesday 12 February 2020

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


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?




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:

Friday 31 January 2020

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



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:

Sunday 26 January 2020

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



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



Finally, here is a tweet highlighting the 6G research



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:

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)

Sunday 5 January 2020

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 ALSOhttps://www.free5gtraining.com/

Monday 16 December 2019

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:

Monday 9 December 2019

5G Evolution with Matthew Baker, Nokia


I wrote a summary of CW (Cambridge Wireless) TEC conference here a couple of months back. The last session was on "Getting ready for Beyond-5G Era". Matthew Baker, Head of Radio Physical Layer & Co-existence Standardization, Nokia Bell Labs was one of the speakers. His talk provided a summary of 3GPP Rel-15 and then gave a nice and short summary of all the interesting things coming in Rel-16 and being planned for Rel-17. The slides from his presentation is embedded below:



Nokia also created a short video where Matthew talks about these new features. It's embedded below:



Related Posts:

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.

Monday 2 December 2019

Guest Post: Exploring Network Convergence of Mobile, Broadband and Wi-Fi

This is a guest post by Ben Toner, Founder and Director, Numerous Networks


Are multiple networks better than one?

How many articles have you read with a title similar to "Which technology is better, 5G or Wi-Fi6?" If, like me, you regularly use Wi-Fi and cellular (I still use 4G though) then you might find it hard to take sides.

Enter Network Convergence - the concept of bringing multiple networks together to get the best of them all. Imagine, as an end user, not having to decide which network to use but instead feeling satisfied that your data was traversing the best combination of networks at that moment in time.

Imagine a business traveler being connected to Wi-Fi which is slow or busy while trying to take that all important conference call while sitting in an airport. Because you are roaming you want to use that Wi-Fi but you do not want to compromise the video call quality. If your network and device could work together to use just enough cellular data to supplement the slow Wi-Fi so that you stayed within your daily roaming quota but never lost a moment in the video call - then you would probably be very happy with that service. Better still, as you start walking off, if the call transitioned from Wi-Fi to cellular with no dropouts or hangup then you might be delighted!

Earlier I underlined best because that in itself is somewhat complicated.  The example above is easy to desribe but quite hard for to achieve within a framework where all possible scenarios are handled that well, for every user. The common questions which need to be factored into any such choice are:
  • What do I as the end user want? 
  • What performance can each network deliver. 
  • How important is the transfer of content at that time and 
  • How much am I willing to pay for it (how many MB of my data plan am I willing to use?). 

This is one of the challenges that we cannot easily solve today, but technology is being developed to help in that process. The operators and device vendors are working within standardisation to develop technology which can provide such a converged service. However at this time there is still a rules mechanism behind it all which does not really describe how user input and preference is going to be captured.

In the last 10 years I have witnessed many battles within service providers when deciding what "one size fits all" service to offer everyone when deciding how to make service provider Wi-Fi available to their customers; all fuelled by my points above.

A lot of concepts are well designed and somewhat mature but deciding exactly what will be implemented in standards is currently ongoing.

In the following slides and video I introduce this whole concept of Network Convergence. The following content introduces the concept and then takes a detailed look at the ATSSS; technology being defined in 3GPP. I also have highlighted the technologoies you can get hold of today to try out network convergence.

I encourage you all to download the example technologies and try convergence for yourself. I'm eager to hear opinions of what technologies work best for each of you. And better still, what is not being provided which you think should be...

Looking forward to your feedback and answering your questions...





Ben Toner
Founder and Director, Numerous Networks


Related Posts:

Wednesday 27 November 2019

Private 4G / 5G Cellular Networks and Bring Your Own Spectrum


With 4G maturing, private cellular networks are finally getting the attention that they deserve and has been promised for quite a while. In a Industry Analyst event, Nokia announced that they are running 120+ private networks including transportation, Energy, Public sector, Smart cities, manufacturing and logistics, etc. (tweet below). The Enterprise Business division is now accounting for 5% of the revenue.
Ray Le Maistre, Editor-in-Chief at Light Reading, in an opinion on Telecoms.com pointed out:

One of the more immediate revenue stream opportunities right now is wireless private networks, and the good news is that this opportunity doesn’t require 5G. Instead, the potential looks set to be enhanced by the availability of a full set of 5G standards (including the yet-to-be concluded core network specs) and the maturity of associated technology.

In the meantime, 4G/LTE has already been the cellular foundation for an increasingly thriving wireless private networks sector that, according to ABI Research, will be worth $16.3 billion by 2025

Another market sizing prediction, this time by SNS Telecom & IT, pitches annual spending on private 4G and 5G networks at $4.7 billion by the end of 2020 and almost $8 billion by 2023. 

However this plays out, there’s clear anticipation of growing investment. What’s particularly interesting, though, is which organizations might pocket that investment. That’s because enterprises and/or organizations looking to benefit from having a private wireless network have a number of options once they decide to move ahead with a private network – here are three permutations that look most likely to me:
  1. Build and run it themselves – technology vendors get some sales in this instance
  2. Outsource the network planning, construction and possibly even the day-to-day. management of the network to a systems integrator (SI) – the SI and some vendors get the spoils. It’s possible here, of course, that the SI could be a technology vendor.
  3. Outsource to a mobile network operator – the operator and some vendors will get some greenbacks.
For sure there will be other permutations, but it shows how many different parts of the ecosystem have some skin in the game, which is what makes this sector so interesting.

What’s also interesting, of course, is what the enterprises do with their private networks: Does it enhance operations? Help reduce costs? Create new business opportunities? All of the above?

Let’s not forget the role of the regulators in all of this. In the US the private wireless sector has been given a shot in the arm by the availability of CBRS (Citizens Broadband Radio Service) shared spectrum in the currently unlicensed 3.5 GHz band: This has given rise to numerous trials and deployments in locations such as sports stadiums, Times Square and even prisons.

In Germany, the regulator has set aside 100MHz of 5G spectrum for private, industrial networks has caused a storm and even led to accusations from the mobile operators that the move ramped up the cost of licenses in the spectrum auction held earlier this year.

In the UK, Ofcom is making spectrum available in four bands:
  • the 1800 MHz and 2300 MHz shared spectrum bands, which are currently used for mobile services;
  • the 3.8-4.2 GHz band, which supports 5G services, and
  • the 26 GHz band, which has also been identified as one of the main bands for 5G in the future.
Slide shared by Mansoor Hanif, CTO, Ofcom at TIP Summit 2019

The process to enable companies and organizations (Ofcom has identified manufacturers, business parks, holiday/theme parks and farms as potential users) in the UK to apply for spectrum will go live before the end of this year, with Ofcom believing that thousands of private networks could be up and running in the coming years.

Dean Bubley from Disruptive Analysis recently spoke about BYOSpectrum – Why private cellular is a game-changer at TAD Summit. The talk is embedded below and is definitely worth listening:



TelecomPaper reported:

The German Federal Ministry for Economic Affairs and Energy said that companies can start to apply to use 5G frequencies in the 3.7-3.8 GHz range on industrial campuses. Local frequencies enable firms to build their own private networks, rather than rely on telecommunications providers to build networks. 

The Automotive Industry Association (VDA) and other industry associations including the VCI, VDMA and ZVEI have welcomed the allocation of frequencies for industrial campuses. According to VDA, several dozen companies have already registered their interest in such frequencies with the Federal Network Agency. 

The firms believe that 5G can replace existing networks, including WLAN, provide improved coverage of entire company premises, enable full control over company data and reduce disruption to public mobile networks.

The spectrum licences will be allocated based on the applicant's geographic footprint and use of a certain area. Prices also take account the area covered by the network, as well as the amount of bandwidth used and duration of the licence.

The formula for the prices is very interesting as shown in the tweet below



In Japan, NTT Docomo is working in co-operation with industry partners to help them to create their own private 5G networks. More announcements on this are expected at MWC next year.



Finally, I am running an Introduction to Private 4G /5G Networks Workshop with Dean Bubley on 04 Feb 2020. If this is an area of interest, consider attending it.



Related Posts: