3GPP and its Japanese Organizational Partners TTC (Telecommunication Technology Committee) and ARIB (Association of Radio Industries and Businesses) hosted a “3GPP Summit” online workshop at CEATEC 2021, back in October. The event was co-located with the Japanese Ministry of Internal Affairs and Communications (MIC) and 5G Mobile Communications Promotion Forum (5GMF) 5G day at the event. Here is a summary of the event from 3GPP news:
The “3GPP Summit” featured all three Technical Specification Group (TSG) Chairs and one Japanese leader from each group. After the presentations, they exchanged their views and expectations for 3GPP work – as the industry starts to look at research beyond 5G. The event attracted almost 700 people, keen to understand what is going on in 3GPP.
The first session covered Release 17 and 18 evolution, with each TSG Chair and a domestic leader jointly presenting. Wanshi Chen introduced the latest schedule of each release and potential projects for Release 18 with the result of 3GPP Release 18 workshop held in June. Then, Hiroki Takeda presented some key features on Release 17 such as Redcap, RAN slicing and evolution of duplex.
TSG SA Chair, Georg Mayer introduced the group’s latest activities alongside Satoshi Nagata, covering key Release 17 features, such as enhanced support on Non-public Networks, Industrial IoT and Edge computing.
Next up was the TSG CT Chair, Lionel Morand, presenting the latest activities and roadmap for Core Network evolution from Release 15 to 17. Hiroshi Ishikawa also presented, covering 5G core protocol enhancements and some activities driven by operators.
The second part of the session focused more on activities ‘Beyond 5G’. First, Takaharu Nakamura introduced the latest activities on the topic in Japan. A panel discussion followed, with Satoshi Nagata joining the other 3GPP speakers, to give feedback on 5G developments and future use.
You can download the PPT of presentations from 3GPP site here or get the PDF from 3G4G page here.
Please feel free to add your thoughts as comments below.
I am starting to get a feeling that people may be becoming overwhelmed with all the new 5G features and standards update. That is why this presentation by Mikael Höök, Director Radio Research at Ericsson, at Brooklyn 6G Summit (B6GS) caught my attention.
The talk discusses the network infrastructure progress made in the previous two years to better illustrate the advanced 5G timeline to discovering 6G requirements. At the end of the talk, there was a quick summary of the four flagship features that are shown in the picture above. The talk is embedded below, courtesy of IEEE TV
In addition to this talk, October 2021 issue of Ericsson Technology Review covers the topic "5G evolution toward 5G advanced: An overview of 3GPP releases 17 and 18". You can get the PDF here.
I have covered the basics of these flagship features in the following posts:
Google announced that its latest smartphone OS will include support for 5G network slicing. Last week Telecom TV brought this news to my attention. The article explains:
It's a move designed to leverage its expertise in devices in order to give it the edge over its rival hyperscalers.
It comes in two flavours. The first is for enterprise-owned handsets, and routes all data sent and received by a device over the network slices provided by that company's mobile operator. Android 12 gives operators the ability to manage slices using a new dynamic policy control mechanism called User Equipment Route Selection Policy (URSP). URSP enables devices to automatically switch between different network slices according to which application they are using. For example, someone working for a financial institution might require a highly-secure network slice for sending and receiving sensitive corporate data, but will then require a reliable, high-throughput, low-latency slice so they can participate in a video meeting.
The second flavour is implemented in the work profile. For years, enterprises have had the option of creating work profiles on Android devices – irrespective of whether they are owned by the organisation or the individual – to use as a separate repository for enterprise apps and data. When Android 12 comes out next year, enterprises will be able to route data to and from that repository over a network slice.
Google said it has already carried out network slicing tests with both Ericsson and Nokia using test versions of its recently released Pixel 6 smartphone running on the as-yet-unreleased Android 12 OS.
It's a replacement for enterprise APNs for now. So not earth-shattering, but a start nonetheless.
Perhaps indicates that enterprise privacy/security/policy might be the major use-case for slicing for the foreseeable future?
Last week Taiwanese operator Far EasTone (FET) and Ericsson announced they have completed the world’s first proof of concept (PoC) for simultaneously connecting multiple network slices per device running on Android 12 commercial release. The press release said:
The trial, carried out on FET’s 5G standalone (SA) infrastructure built on Ericsson’s radio access network and cloud-native Core network, successfully demonstrated the 5G user equipment slicing policy feature (User Equipment Route Selection Policy, or URSP) on multiple Android devices. This marks a breakthrough in network slicing capabilities on a 5G standalone network and paves the way for further ecosystem development in this important area.
With more 5G networks evolving to standalone architecture around the globe, end-to-end network slicing, which includes Ericsson RAN Slicing to secure Quality of Service (QoS) differentiation, plays a key role in enabling new services for end users, with which multiple virtual 5G networks are created on top of one physical network. The 5G trial, in collaboration with FET, Ericsson and Android, went even further in network slicing capabilities by introducing and demonstrating 5G user equipment (UE) slicing policy (URSP) features that allow devices to simultaneously operate on dynamic policy control and selection between multiple 5G network slices. This enables the steering of applications and services with specific requirements to defined slices without switching devices.
Multiple slices allow devices to have multiple profiles to secure different levels of experience, security, and privacy requirements, based on the needs of the different applications and in correspondence with the user profile. For instance, a device can have a personal profile with private data from apps or off-work entertainment, and a work profile with enterprises productivity apps. With URSP features, employers can customize the work profile with increased security and enable better use of RAN Slicing with QoS so that enterprise-related apps can work even during network congestion.
Some security-sensitive apps, such as mobile banking, can also benefit from different routing mechanisms of the traffic enabled by URSP. For instance, the banking app would not need to send its traffic to the internet and then to the app server as it does today. Instead, it could go straight to the app server and avoid the routing through internet. With the shortest route by connecting to a defined slice, users could reduce the risk of being attacked by hackers.
Along with the concept of network slicing and features in the RAN and Core network, UE Route Selection Policy (URSP) is introduced as a way to manage network slice information for the UE. URSP is a network slice feature enabled by the PCF which informs the network slice status to the UE via the AMF. In 4G network systems, it was near impossible to install new services in the network for a UE. But through the URSP feature, 5G network operators can easily configure new service for a UE. Figure 12 (top of this blog post) shows the difference in network slice selection in 4G and 5G Network. In 5G network, slice selection policy can be configured dynamically through URSP, while slice selection policy is pre-defined and cannot be changed dynamically in 4G network.
URSP contains OSId, AppId, IP descriptors to define the application and Single-Network Slice Selection Assistance Information (S-NSSAI), Data Network Name (DNN), Session and Service Continuity (SSC) mode information for the application and network slice mapping.
The S-NSSAI identifies each network slice service and provides information to properly assign network slice/functions. An S-NSSAI is comprised of:
A Slice/Service type (SST), which refers to the expected network slice behavior in terms of features and services;
A Slice Differentiator (SD), which is an optional information that complements the Slice/Service type(s) to differentiate amongst multiple network slices of the same Slice/Service type.
3GPP allows the use of the Slice Differentiator (SD) field that can build customized network slices. The SD field can be used to describe services, customer information and priority.
Here is a short video from Mpirical explaining 5G UE Route Selection.
It it worth reminding here that this feature, like many of the other 5G features, is dependent on 5G Core. We hope that the transition to 5G Standalone Networks happens as soon as possible.
In this video I explain how QoS Flows for VoNR are established and released especially on N2 reference point between 5G Core and NG RAN.
The pervious video about generic aspects of "QoS Flow Establishments in 5G Standalone RAN and Core" you will find in the first link of the Related Posts listed below:
We just made a tutorial on this topic looking at where most of the power consumption in the mobile network occurs and some of the ways this power consumption can be reduced.
The chart in the Tweet above (also in the presentation) clearly shows that the energy costs for operators run in many millions. Small power saving schemes can still have a big impact on the total energy reduction, thereby saving huge amounts of energy and costs.
The March issue of ZTE Communications Magazine contains some good articles looking at how to tackle the energy challenges in the network going forward. This recent article by Ericsson is also a good source of information on this topic.
Anyway, the slides and the video of the tutorial is embedded below:
5G is hot at the moment. While the operators are busy rolling out the networks based on Release-15/16 features, 3GPP is working on finalising Release-17 specifications and laying the foundations for Rel-18.
The latest issue of 3GPP Highlights magazine (I prefer the PDF) contains a lot of valuable technical content, in addition to many other articles. The technical content includes:
An early view of the RAN Topics for 5G-Advanced
5G Advanced in the Making – The TSG SA approach to Release 18
Application Enablement Standards in 3GPP – Maximizing the potential of 5G!
RAN3 flourishing in this time of change
Enhanced support of Industrial IoT in the 5G System (Rel-17)
Autonomous Network standardization in WG SA5
Rel-17 Edge Computing and Network Slicing charging (WG SA 5)
Media Production over 5G NPN
While I am not going into too much detail here, I want to highlight the 5G-Advanced topics that will be under discussion over the next couple of months. The final list will be approved by 3GPP TSGs SA, RAN and CT in December 2021.
Dr. Wanshi Chen, 3GPP TSG RAN Chair provided an early view of the RAN topics for 5G-Advanced.
Topics Under Discussion
As well as taking a tentative decision on an 18-month duration for Release 18, the RAN workshop endorsed a list of topics for subsequent email discussions. Some of the topics in the following list also have a set of example areas, serving as a starting point for further refinement:
Evolution for downlink MIMO, with the following example areas:
Further enhancements for CSI (e.g., mobility, overhead, etc.)
Evolved handling of multi-TRP (Transmission Reception Points) and multi-beam
Uplink enhancements, with the following example areas:
>4 Tx operation
Enhanced multi-panel/multi-TRP uplink operation
Frequency-selective precoding
Further coverage enhancements
Mobility enhancements, with the following example areas:
Layer 1/layer 2 based inter cell mobility
DAPS (Dual Active Protocol Stack)/CHO (Conditional HandOver) related improvements
FR2 (frequency range 2)-specific enhancements
Additional topological improvements (IAB and smart repeaters), with the following example areas:
Mobile IAB (Integrated Access Backhaul)/Vehicle mounted relay (VMR)
Smart repeater with side control information
Enhancements for XR (eXtended Reality), with the following example areas:
KPIs/QoS, application awareness operation, and aspects related to power consumption, coverage, capacity, and mobility
Note: only power consumption/coverage/mobility aspects specific to XR
Sidelink enhancements (excluding positioning), with the following example areas:
SL enhancements (e.g., unlicensed, power saving enhancements, efficiency enhancements, etc.)
SL relay enhancements
Co-existence of LTE V2X & NR V2X
RedCap evolution (excluding positioning), with the following example areas:
New use cases and new UE bandwidths (5MHz?)
Power saving enhancements
NTN (Non-Terrestrial Networks) evolution
Including both NR & IoT (Internet of Things) aspects
Evolution for broadcast and multicast services
Including both LTE based 5G broadcast and NR MBS (Multicast Broadcast Services)
Expanded and improved Positioning, with the following example areas:
Sidelink positioning/ranging
Improved accuracy, integrity, and power efficiency
RedCap positioning
Evolution of duplex operation, with the following example areas:
Deployment scenarios, including duplex mode (TDD only?)
Interference management
AI (Artificial Intelligence)/ML (Machine Learning), with the following example areas:
Air interface (e.g., Use cases to focus, KPIs and Evaluation methodology, network and UE involvement, etc.)
NG-RAN
Network energy savings, with the following example areas:
KPIs and evaluation methodology, focus areas and potential solutions
Additional RAN1/2/3 candidate topics, Set 1:
UE power savings
Enhancing and extending the support beyond 52.6GHz
CA (Carrier Aggregation)/DC (Dual-Connectivity) enhancements (e.g., MR-MC (Multi-Radio/Multi-Connectivity), etc.)
Flexible spectrum integration
RIS (Reconfigurable Intelligent Surfaces)
Others (RAN1-led)
Additional RAN1/2/3 candidate topics, Set 2:
UAV (Unmanned Aerial Vehicle)
IIoT (Industrial Internet of Things)/URLLC (Ultra-Reliable Low-Latency Communication)
<5MHz in dedicated spectrum
Other IoT enhancements/types
HAPS (High Altitude Platform System)
Network coding
Additional RAN1/2/3 candidate topics, Set 3:
Inter-gNB coordination, with the following example areas:
Inter-gNB/gNB-DU multi-carrier operation
Inter-gNB/gNB-DU multi-TRP operation
Enhancement for resiliency of gNB-CU
Network slicing enhancements
MUSIM (Multiple Universal Subscriber Identity Modules)
UE aggregation
Security enhancements
SON (Self-Organizing Networks)/MDT (Minimization of Drive Test)
Others (RAN2/3-led)
Potential RAN4 enhancements
Dr. Georg Mayer, 3GPP TSG SA Chair provides the TSG SA approach to 3GPP Release-18
The candidate items for Rel-18 include:
Immersive Media and Virtual/Artificial/Extended Reality (XR) Media support in Working Group (WG) SA4 and WG SA2.
New work areas for Internet of Things (e.g. passive IoT (WG SA2) and application capability exposure for IoT platforms (WG SA6)).
Proposals to for Artificial Intelligence and Machine Learning Services Transport and Management (WGs SA2, SA5).
Concepts for integration and migration of existing vertical infrastructure, e.g. for railway networks (WG SA6).
Examples for proposed enhancements to existing 3GPP services and functionalities include:
Network Slicing (WGs SA2, SA5)
Edge Computing (WGs SA2, SA5, SA6)
Autonomous Networks (WG SA5)
Service Based Architecture (WGs SA2, SA5)
Northbound APIs (WG SA6)
Non-Public Networks (WG SA2)
Satellite 5G Networks (WG SA2)
Drone support (WG SA2)
5G Multicast and Broadcast (WG SA2)
Location Services (WG SA2, SA6)
Management Data Analytics (WG SA5)
Mission Critical Services (WG SA6)
None of these features are final but we will know in the next few months what will be included as part of Rel-18 and what won't. In the meantime, do check out the latest issue of 3GPP Highlights here.
I have been talking about unlicensed LTE since 2013. With all the debate around LTE-U and LAA now non-existent, the technology has evolved with every new release. As can be seen from this picture by Ericsson above, 5G NR-U in Release-16 supports:
The Release-16 work item summary details the following deployment scenarios for NR-based access to unlicensed spectrum:
Scenario A: Carrier aggregation between NR in licensed spectrum (PCell) and NR in shared spectrum (SCell);
A.1: SCell is not configured with UL (DL only);
A.2: SCell is configured with UL (DL+UL).
Scenario B: Dual connectivity between LTE in licensed spectrum and NR in shared spectrum (PSCell);
Scenario C: NR in shared spectrum (PCell);
Scenario D: NR cell in shared spectrum and uplink in licensed spectrum;
Scenario E: Dual connectivity between NR in licensed spectrum (PCell) and NR in shared spectrum (PSCell)
5G New Radio Unlicensed: Challenges and Evaluation, available on arXiv here provides a lot of useful information on different kind of operations within the unlicensed band and the challenges of co-existence with Wi-Fi
Finally, Qualcomm has quite a few resources on this topic. Last year, they hosted a webinar on the topic, "How does unlicensed spectrum with NR-U transform what 5G can do for you?". The slides from that are available here and a video of that is available here. RCR Wireless also has this short article from one of the webinar presenters here.
Today I launched a new video on my YouTube channel that explains how QoS Flows are established in 5G RAN and Core. It also highlights the main differences between 4G E-RAB handling and 5G QoS Flows.
Detailed post below but if you are after a quick summary, it's in the picture above.
Couple of weeks back someone quoted that there were 50 billion devices last year (2020). After challenging them on the number, they came back to me to say that there were over 13 billion based on GSMA report. While the headline numbers are correct, there are some finer details we need to look at.
It all started back in 2010 when the then CEO of Ericsson announced that there will be 50 Billion IoT Devices by 2020. You could read all about it here and see the presentation here. While it doesn't explicitly say, it was expected that the majority of these will be based on cellular technologies. I also heard the number 500 Billion by 2030, back in 2013.
So the question is how many IoT devices are there today and how many of these are based on mobile cellular technologies?
The headline number provided by the GSMA Mobile Economy report, published just in time for MWC 2021, is 13.1 billion in 2020. It does not provide any further details on what kind of connectivity these devices use. I had to use my special search skills to find the details here.
As you can see, only 1.9 billion of these are based on cellular connections, of which 0.2 billion are based on licensed Low Power Wide Area (licensed LPWA, a.k.a. LTE-M and NB-IoT) connections.
Ericsson Mobility Report, June 2021, has a much more detailed breakdown regarding the numbers as can be seen in the slide above. As of the end of 2020, there were 12.4 billion IoT devices, of which 10.7 billion were based on Short-range IoT. Short-range IoT is defined as a segment that largely consists of devices connected by unlicensed radio technologies, with a typical range of up to 100 meters, such as Wi-Fi, Bluetooth and Zigbee.
Wide-area IoT, which consists of segment made up of devices using cellular connections or unlicensed low-power technologies like Sigfox and LoRa had 1.7 billion devices. So, the 1.6 billion cellular IoT devices also includes LPWAN technologies like LTE-M and NB-IoT.
Figures are connections/SIMs sold - not all will be live yet.
I also reached out to IoT experts at analyst firm Analysys Mason. As you can see in the Tweet above, Tom Rebbeck, Partner at Analysys Mason, mentioned 1.6 billion cellular (excluding NB-IoT + LTE-M) and 220 million LPWA (which includes NB-IoT, LTE-M, as well as LoRa, Sigfox etc.) IoT connections.
If I understand this correctly, as of June 2021 there were 1.55 billion cellular IoT connections. Do these include NB-IoT as well as LTE-M?
I also noticed this interesting chart in the tweet above which shows the growth of IoT from Dec 2010 until June 2021. Matt Hatton, Founding Partner of Transforma Insights, kindly clarified that the number as 1.55 billion including NB-IoT and LTE-M.
As you can see, the number of cellular IoT connections are nowhere near 50 billion. Even if we include all kinds of IoT connectivity, according to the most optimistic estimate by Ericsson, there will be just over 26 billion connections by 2026.
Just before concluding, it is worth highlighting that according to all these cellular IoT estimates, over 1 billion of these connections are in China. GSMA's 'The Mobile Economy China 2021' puts the number as 1.34 billion as of 2020, growing to 2.29 billion by 2025. Details on page 9 here.
Hopefully, when someone wants to talk about Internet of Thing numbers in the future, they will do a bit more research or just quote the numbers from this post here.
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
