Maritime Communication (MARCOM) Services over 3GPP system

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The following specifications are relevant for MARCOM:

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

Related Posts: 

• The 3G4G Blog: 3GPP Release 16 Description and Summary of Work Items
• The 3G4G Blog: '5G RAN Release 18 for Industry Verticals' Webinar Highlights
• The 3G4G Blog: ATIS Webinar on '5G Standards Developments in 3GPP Release 16 and Beyond'
• The 3G4G Blog: Future Railway Mobile Communication System (FRMCS)
• The 3G4G Blog: Update from 3GPP on LTE & 5G Mission Critical Communications 

When can we Stop the 5G NSA Experiment?

Cross posting from LinkedIn, please post any comments there!

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

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

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

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

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

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

Not My Job

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

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

5G for Everyone

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

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

5G Stands Alone

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

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

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

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

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

Industry’s View

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

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

Non-Standalone Part 2

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

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

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

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

3GPP Release 16 Description and Summary of Work Items

Someone reached out recently asking for a summary of Release 16 features. For people who are involved in standards, they already know of a few ways you can get this quickly. 

The first is to go to the Releases page here: https://www.3gpp.org/specifications/releases 

Here you can see the status of current releases as well as at the bottom of the page you can jump to the individual releases. 

A full Release Description is produced by the Work Plan manager at the completion of the work. This has been available since Release-14 onwards. You can go and get the latest version of the following technical reports:  

• TR 21.914 covers Rel-14, 
• TR 21.915 for Rel-15 and now 
• TR 21.916 as the Rel-16 description document.

The following is the summary of features listed in 3GPP TR 21.916 for Release-16: 

5. Enhancement of Ultra-Reliable and Low Latency Communications (URLLC)
1. Enhancement of URLLC support in the 5G Core network
2. Physical Layer Enhancements for NR Ultra-Reliable and Low Latency Communication (URLLC)
3. Support of NR Industrial Internet of Things
6. Support of LAN-type services
1. NR-based access to unlicensed spectrum
2. LAN support in 5G
3. 5GS Enhanced support of Vertical and LAN Services
7. Cellular Internet of Things (IoT)
1. Cellular IoT support and evolution for the 5G System
2. Additional enhancements for NB-IoT
3. Additional MTC enhancements for LTE
8. Advanced V2X support
1. Improvement of V2X service Handling
2. Architecture enhancements for 3GPP support of advanced V2X services
3. Application layer support for V2X services
4. 5G V2X with NR sidelink
9. Northbound APIs related items
1. Usage of CAPIF for xMB API
2. Enhancement of 3GPP Northbound APIs
3. Enhancements for Common API Framework for 3GPP Northbound APIs
4. Service Enabler Architecture Layer for Verticals
5. Other APIs-related items
10. Coexistence with Non-3GPP systems
1. Wireless and Wireline Convergence Enhancement
2. Access Traffic Steering, Switch and Splitting support in the 5G system architecture
11. Railways and Maritime
1. Mobile Communication System for Railways 2
2. Further performance enhancement for LTE in high speed scenario
3. NR support for high speed train scenario
4. Maritime Communication Services over 3GPP System
12. Mission Critical, Public Warning
1. Enhancements of Public Warning System
2. MBMS APIs for Mission Critical Services
3. Mission Critical Services Security Enhancements
4. Other Mission critical improvements
1. MCData File Distribution support over xMB
2. Enhanced Mission Critical Communication Interworking with Land Mobile Radio Systems
3. MBMS APIs for Mission Critical Services
4. Enhancements to Functional architecture and information flows for Mission Critical Data
5. MC Communication Interworking
6. Enhanced Mission Critical Push-to-talk architecture phase 2
7. Other Mission Critical activities
13. Conversational services, Streaming and TV
1. Conversational services
1. Coverage and Handoff Enhancements for Multimedia (CHEM)
2. Single radio voice continuity from 5GS to 3G
3. Volume Based Charging Aspects for VoLTE
4. EVS Floating-point Conformance for Non Bit-Exact
5. Media Handling Extensions for 5G Conversational Services
6. VR QoE metrics
7. Media Handling Aspects of RAN Delay Budget Reporting in MTSI
8. Removal of H.263 and MPEG-4 Visual from 3GPP Services
2. 13.2 Streaming
1. Enhancement of LTE for Efficient delivery of Streaming Service
2. Enhancements to Framework for Live Uplink Streaming
3. Media streaming architecture
14. 5G Location and Positioning Services
1. 5G positioning services (5G_HYPOS)
2. Enhancement to the 5GC LoCation Services
3. NR positioning support
15. User Identities, Authentication, multi-device
1. User Identities and Authentication
2. Multi-device and multi-identity
16. Slicing
1. Enhancement of Network Slicing
2. Enhancement of 3GPP management system for multiple tenant environment support
3. Business Role Models for Network Slicing
4. Enhancement of performance assurance for 5G networks including network slicing
17. UE radio capability signalling optimization
1. Optimisations on UE radio capability signalling
18. Other system-wide Features
1. Enablers for Network Automation Architecture for 5G
2. Provision of Access to Restricted Local Operator Services by Unauthenticated UEs
3. Enhancing Topology of SMF and UPF in 5G Networks
4. Private and Non-Public Network Support for NG-RAN
5. Service-Based Architecture
1. Enhancements to the Service-Based 5G System Architecture
2. SBA aspects of enhanced IMS to 5GC integration
6. User data interworking, Coexistence and Migration
19. Radio Features
1. NR-related Release 16 Features
1. NR-based access to unlicensed spectrum
2. 2-step RACH for NR
3. UE Power Saving in NR
4. Integrated access and backhaul for NR
5. Dual Connectivity (EN-DC) with 3 bands DL and 3 bands UL
6. NR mobility enhancements
7. Rel-16 NR inter-band CA/Dual Connectivity for 2 bands DL with x bands UL (x=1, 2)
8. Rel16 NR inter-band Carrier Aggregation for 3 bands DL with 1 band UL
9. Add support of NR DL 256QAM for frequency range 2 (FR2)
10. SON (Self-Organising Networks) and MDT (Minimization of Drive Tests) support for NR
11. Introduction of NR FDD bands with variable duplex and corresponding framework
12. Cross Link Interference (CLI) handling and Remote Interference Management (RIM) for NR
13. RF requirements for NR frequency range 1 (FR1)
14. NR RF requirement enhancements for frequency range 2
15. NR RRM enhancement
16. RRM requirement for CSI-RS based L3 measurement in NR
17. Over the air (OTA) base station (BS) testing TR
2. Release 16 Features impacting both LTE and NR
1. Transfer of Iuant interface specifications from 25-series to 37-series
2. Introduction of GSM, UTRA, E-UTRA and NR capability set(s) (CS(s)) to the multi-standard radio (MSR) specifications
3. Direct data forwarding between NG-RAN and E-UTRAN nodes for inter-system mobility
4. eNB(s) Architecture Evolution for E-UTRAN and NG-RAN
5. High power UE (power class 2) for EN-DC (1 LTE TDD band + 1 NR TDD band)
6. LTE-NR & NR-NR Dual Connectivity and NR Carrier Aggregation enhancements
7. 29 dBm UE Power Class for LTE band 41 and NR Band n41
8. LTE/NR Dynamic Spectrum Sharing (DSS) in band 48/n48 frequency range
3. LTE-related Release 16 Features
1. LTE-based 5G terrestrial broadcast
2. Support for NavIC Navigation Satellite System for LTE
3. Even further mobility enhancement in E-UTRAN
4. DL MIMO efficiency enhancements for LTE
5. Other LTE-only items
20. All other Release 16 Features
1. Service Interactivity
2. RTCP Verification for Real-Time Services
3. Stage-3 SAE Protocol Development for Rel16
4. Reliable Data Service Serialization Indication
5. Shared Data Handling on Nudm and Nudr
6. New Services and Markets Technology Enablers – Phase 2
7. Ambient noise test methodology for evaluation of acoustic UE performance
8. KPI reporting
21. Telecom Management
1. Network and Service Management
1. 5G Management capabilities
2. Energy Efficiency of 5G
3. OAM aspects of LTE and WLAN integration
4. Methodology for 5G management specifications
5. Closed loop SLS Assurance
6. Trace Management in the context of Services Based Management Architecture and Streaming Trace reporting
7. Management of QoE measurement collection
8. Network Resource Model (NRM) enhancement
2. Charging Management
1. Charging Enhancement of 5GC interworking with EPC
3. Other charging and management items
22. Other items
1. Items not (fully) completed in Rel-16
1. Remote Identification of Unmanned Aerial Systems
2. 5G message service
3. Integration of Satellite Access in 5G

If you find them useful then please get the latest document from here.

Related Posts: 

• The 3G4G Blog: ATIS Webinar on '5G Standards Developments in 3GPP Release 16 and Beyond'
• The 3G4G Blog: Anritsu Webinar on 'Evolution of 5G from 3GPP Rel-15 to Rel-17 and Testing Challenges'
• The 3G4G Blog: Future Railway Mobile Communication System (FRMCS)
• The 3G4G Blog: Qualcomm Explains 5G Millimeter Wave (mmWave) Future & Integrated Access and Backhaul (IAB)
• The 3G4G Blog: 5G User Plane Redundancy
• The 3G4G Blog: NWDAF in 3GPP Release-16 and Release-17
• The 3G4G Blog: UE Radio Capability Signaling Optimization (RACS) in Rel. 16
• The 3G4G Blog: Conditional Handover (Rel. 16) Explained
• The 3G4G Blog: Three New Standards to Accelerate 5G Wireless Wireline Convergence (WWC)
• The 3G4G Blog: Positioning Techniques for 5G NR in 3GPP Release-16
• The 3G4G Blog: Understanding the Dual Active Protocol Stack (DAPS) Handover in 5G
• The 3G4G Blog: 5G Enhanced URLLC (eURLLC)
• The 3G4G Blog: 3GPP MDT - How it works and what is new in Rel. 16
• The 3G4G Blog: Mobile Initiated Connection Only (MICO) mode in 5G System 

Future Railway Mobile Communication System (FRMCS)

I have been meaning to write on this topic for a very long time. The discussion started back in 2016 when the limitations of GSM-R were obvious and it was recognised that a successor will be needed sooner or later. The International Railway Union (UIC) published a user requirement specification in their paper “Future Railway Mobile Communication System - FRMCS”. This is available on 3GPP server as liaison statement S1-161250.

As 3GPP notes in their article, this was the trigger for them to go ahead and start the studies. Then in Release 16, 3GPP TS 22.289 "Mobile communication system for railways" outlined the requirements for railway communication, beyond the 3GPP Future Railway Mobile Communication System (FRMCS) Phase 1 specs. Details are available on this post here.

Source Tweet

The latest version of 3GPP TR 22.889, Study on Future Railway Mobile Communication System; Stage 1 is from Release 17. The introduction to the document clarifies:

The railway community is considering a successor communication system to GSM-R, as the forecasted obsolescence of the 2G-based GSM-R technology is envisaged around 2030, with first FRMCS trial implementations expected to start around 2020. 

The Future Railway Mobile Communication System (FRMCS) Functional Working Group (FWG) of the International Union of Railways (UIC) have investigated and summarised their requirements for the next generation railway communication system in the Future Railway Mobile Communication User Requirements Specification (FRMCS URS). The present document is based on this input given by the UIC/ETSI TC-RT 

Study on FRMCS Evolution (FS_eFRMCS), available as SP-201038 clarifies:

The UIC FRMCS programme was recently releasing stable version 5.0.0 of the User Requirement Specification, version 2.0.0 of the Functional Use Cases and a new specification item, version 1.0.0 of the Telecom On-Board System - Functional Requirements Specification, as a further step in the evolution of the FRMCS specifications. The UIC FRMCS Programme is developing all the technical conditions for the 5G FRMCS, with the main objective to make available a “FRMCS First Edition” ecosystem available for procurement by Q1 2025.

The UIC FRMCS 3GPP Task Force has been identifying and analyzing impact of this newly released set of FRMCS specifications on existing use cases and requirements collected in TR 22.889. The UIC FRMCS 3GPP Task Force analysis has concluded that refining existing use cases, defining new use cases such as merging railway emergency communications and real-time translation of conversation, and deriving potential new requirements, will be necessary to align FRMCS and 3GPP specifications. The potential impact on normative work is estimated to be limited and much less compared to the study work.

As approved in SA1#90-e (S1-202245), TR 22.889 has now been re-named to TR 22.989 from Rel-18 onwards (latest version is TR 22.989 v18.0.0) to make it visible to the Rail community to be able to follow the 3GPP normative work in line with their needs. It is of most importance for the Rail community that specifications from different organisations (i.e. UIC, 3GPP and ETSI) are all aligned.

Due to the expected 3GPP work overload in Release 18 (SA1 and downstream groups), it is proposed to reduce the scope of the present Rel-18 study to evolution of critical applications related use cases only already identified by UIC – what is really essential for the railways as part of the “FRMCS First Edition” and the migration phase from GSM-R to FRMCS. 

Study of non-essential use cases (e.g. evolution of performance and business use cases) shall be postponed to Rel-19.

This plan is from 2019 so quite likely that it is already outdated. It does provide an idea on different steps and trial plans. Some of this was also covered in the 5G RAN Release 18 for Industry Verticals Webinar detailed here.

Finally, as this image from Arthur D. Little highlights, there is a lot of other interest in addition to FRMCS for 5G in railway. Report here.

Related Posts:

• The 3G4G Blog: '5G RAN Release 18 for Industry Verticals' Webinar Highlights
• The 3G4G Blog: Three New Standards to Accelerate 5G Wireless Wireline Convergence (WWC)
• The 3G4G Blog: 3GPP's 5G-Advanced Workshop Summary
• The 3G4G Blog: 3GPP's 5G-Advanced Technology Evolution from a Network Perspective Whitepaper
• Telecoms Infrastructure Blog: Bringing Connectivity to Underground Rail Network
• Connectivity Technology Blog: Deutsche Bahn to get Seamless Mobile Network Along all Tracks
• Connectivity Technology Blog: China Unicom Brings 5G Connectivity to Nanjing Metro 

Qualcomm Explains 5G Millimeter Wave (mmWave) Future & Integrated Access and Backhaul (IAB)

We have covered various topics in our blog posts on millimeter wave spectrum and even going beyond 52.6 GHz in FR2. A Qualcomm webinar from back in January expands on many of the topics that I looked superficially in various posts (links at the bottom).

The following is edited from the Qualcomm blog post:

5G NR in unlicensed spectrum (NR-U) was standardized in Release 16 and it is a key enabler for the 5G expansion to new use cases and verticals, providing expanded spectrum access to mobile operators, service providers, and industry players. At the same time, we are starting to push the mmWave boundary to even higher bands toward the sub-Terahertz (i.e., >100 GHz) range. Expected in Release 17, 5G NR will support spectrum bands up to 71 GHz, leveraging the 5G NR Release 15 scalable numerology and flexible framework. This opens up 5G to operate in the globally unlicensed 60 GHz band, which can fuel a broad range of new applications and deployments.

One daunting challenge that mobile operators will face when expanding 5G mmWave network coverage is the cost of deploying additional base stations for mmWave, which usually requires new fiber optics backhaul installations. Release 16-defined IAB allows a base station to not just provide wireless access for its user devices (e.g., smartphones) but also the ability to backhaul wirelessly via neighboring base stations using the same mmWave spectrum. IAB opens the door to more flexible densification strategies, allowing mobile operators to quickly add new base stations to their networks before having to install new fiber to increase backhaul capacity. 

Release 16 established foundational IAB capabilities, such as dynamic topology adaptation for load balancing and blockage mitigation, and Release 17+ will further enhance IAB by bringing new features like full-duplex operation, topology redundancy, and ML-based network management.

Beyond IAB, there is a rich roadmap of other new features that can further improve 5G mmWave system performance and efficiency. The webinar embedded below is presented by Ozge Koymen, Senior Director, Technology, Qualcomm Technologies, Inc. It covers the following topics:

• Qualcomm's vision for 5G mmWave and the new opportunities it poises to bring for the broader ecosystem
• mmWave capabilities and enhancements coming in Release -16 and beyond
• Qualcomm’s role in mobilizing and democratizing 5G mmWave to usher in new experiences
• Latest update on the global commercial rollout of 5G mmWave networks and devices

Slides of the presentation are available here.

Related Posts:

• Free 6G Training: Spectrum for 5G, Beyond 5G and 6G research
• The 3G4G Blog: A mmWave Special Cell in Open RAN Environment
• The 3G4G Blog: Spectrum for 5G NR beyond 52.6 GHz
• The 3G4G Blog: 5G Integrated Access and Backhaul (IAB) Enhancements in Rel-17
• The 3G4G Blog: Carrier Aggregation (CA) and Dual Connectivity (DC)
• The 3G4G Blog: The Politics of Standalone vs Non-Standalone 5G & 4G Speeds