Showing posts with label Release 19. Show all posts
Showing posts with label Release 19. Show all posts

Thursday, 29 October 2026

How 3GPP Release 19 Optimises UE-Satellite-UE Voice and Video Communications

One of the interesting developments in 3GPP Release 19 is the introduction of optimised UE-Satellite-UE communications, allowing voice and video traffic between two satellite-connected devices to be routed through satellites without unnecessarily passing through the terrestrial core network.

We briefly covered this feature in our earlier discussion of Release 19 NTN enhancements, but a recent article (in Japanese) from the NTT DOCOMO Technical Journal, published in October 2026, provides a much more detailed explanation of the underlying 5G Core (5GC) and IP Multimedia Subsystem (IMS) architecture, along with the procedures needed to establish and maintain these communications.

The article, titled 5GC Enhancement Technologies for Satellite Communication Networks in 3GPP Release 19, explains how satellite-based user-plane functions, IMS media gateways and terrestrial control-plane functions work together to enable more efficient voice and video services.

To understand the significance of this development, it is worth briefly revisiting the evolution of 5G Non-Terrestrial Networks (NTN). Release 17 introduced NTN support based primarily on transparent satellite payloads, where satellites act as radio repeaters while the gNB and core network functions remain on the ground. Release 18 introduced core network architectural enhancements for regenerative GEO satellites, where additional processing and network functions can be located onboard. Release 19 further develops regenerative NTN architectures and supports scenarios involving LEO satellites with onboard user-plane functionality.

One problem with conventional satellite communication architectures is that even when two devices communicate through satellites belonging to the same constellation, their user traffic may still need to travel down to a terrestrial gateway, through the ground network, and then back up to the satellite serving the receiving device.

As shown in the diagram above, traffic from the originating UE travels to its serving satellite and across an inter-satellite link (ISL), before being routed through an NTN gateway and terrestrial 5GC. It then returns through the satellite network to reach the destination UE.

This introduces unnecessary satellite-to-ground and ground-to-satellite transmissions, increasing propagation delay and consuming feeder-link capacity. Depending on the constellation and routing arrangement, the additional latency can become significant, particularly for delay-sensitive applications such as voice and video calls.

Release 19 addresses this by allowing the media traffic to be routed locally through the satellite network, provided that the necessary network functions and inter-satellite connectivity are available. In the optimised arrangement, voice or video packets travel from one UE to its serving satellite, pass through satellite-based network functions and, when required, use inter-satellite links to reach the satellite serving the other UE. The traffic can therefore avoid traversing terrestrial network elements.

Importantly, this does not mean that the entire 5G Core or IMS network has been moved into space. This is probably the most interesting aspect of the architecture. The Release 19 solution places selected user-plane functions onboard the regenerative satellites, including the IMS Access Gateway (IMS-AGW), Uplink Classifier (UL-CL) and Local PDU Session Anchor (L-PSA). The IMS-AGW handles the media path associated with an IMS session. The UL-CL provides traffic classification and steering, allowing relevant packets to be directed towards the local satellite-based processing functions. The L-PSA provides the local user-plane anchoring needed for the optimised media path.

However, the main PDU Session Anchor (PSA) UPF remains on the ground. This is important because it allows the UE's IMS PDU session IP address to remain unchanged as the serving satellite changes. Similarly, IMS control-plane functions such as the Proxy Call Session Control Function (P-CSCF) and Serving Call Session Control Function (S-CSCF) remain terrestrial.

In other words, the network separates the handling of voice and video packets from the signalling and control functions used to establish and manage the communication. The media can remain in space even though the session is still controlled through the terrestrial network. The architecture also relies on coordination between IMS and the 5GC. It is not sufficient simply to install a UPF on a satellite. The network must determine which satellites are serving the two devices, whether optimised routing is possible, and where the relevant media processing functions should be configured.

The call establishment procedure uses familiar IMS signalling, with additional mechanisms to support satellite identification and media path selection. When a UE initiates a voice or video call, it sends a SIP INVITE message. The originating P-CSCF obtains information from the terrestrial 5GC identifying the satellite currently serving the UE. Initially, a terrestrial IMS-AGW is selected, providing a conventional media path while the network determines whether satellite optimisation is possible.

The satellite identifier is conveyed towards the terminating side through the IMS signalling procedures. The terminating P-CSCF also obtains the identity of the satellite serving the receiving UE. Using this information, the network determines whether both sides can support optimised satellite media routing. If the required conditions are satisfied, the P-CSCFs select satellite-based IMS-AGWs, release the initially allocated terrestrial gateways where appropriate, and coordinate with the 5GC to configure the UL-CL and L-PSA functions onboard the satellites.

The 5GC policy and session management mechanisms, including interaction with the Policy Control Function (PCF) and Session Management Function (SMF), help establish the necessary traffic steering and Quality of Service (QoS) treatment. Once the procedure is complete, the IMS voice or video media can travel through the satellite network rather than being routed through terrestrial gateways.

It is worth emphasising that this is not a direct device-to-device radio connection. Each device still communicates with its serving satellite using the normal satellite access interface. The optimisation takes place inside the satellite network, with the appropriate onboard user-plane functions handling the media traffic.

Another important consideration is mobility. Unlike a conventional terrestrial mobile network, where the base station is generally stationary, LEO satellites move continuously relative to the Earth's surface. Even a stationary user may need to change serving satellites frequently as satellites enter and leave the visible coverage area.

This creates an additional challenge for optimised UE-Satellite-UE communication. A voice or video call may already be using satellite-based IMS-AGWs and local user-plane functions when one of the devices changes its serving satellite. Simply transferring the radio connection to another satellite is not enough. The media path must also be updated so that packets continue to reach the correct gateway and user-plane functions.

Release 19 defines procedures for maintaining the optimised media path when the serving satellite changes, as well as falling back to terrestrial routing when satellite-based optimisation can no longer be maintained.

When a UE changes its serving satellite, the 5GC can provide an early notification to the P-CSCF containing the identity of the target satellite. The P-CSCF then determines whether optimised routing can continue between the new serving satellite and the satellite serving the other UE. If it can, the network selects an IMS-AGW on the target satellite and coordinates the necessary user-plane configuration.

The SMF manages the appropriate UL-CL and L-PSA configuration, while updated media transport information is provided for the continuing session. This allows the media route to change without requiring the user to establish a completely new call. There will, however, be situations where the optimised route cannot be maintained. For example, the required inter-satellite connectivity may not be available, or the new satellite arrangement may not support the necessary media path.

Rather than allowing the communication to fail simply because the optimised path is unavailable, Release 19 also supports a terrestrial fallback procedure.

In this case, the P-CSCF arranges for the media to be routed through a terrestrial IMS-AGW instead of continuing through the optimised satellite path. The relevant media transport information is updated and provided through the 5GC. Both continued satellite optimisation and terrestrial fallback require the IMS session to be updated. This is achieved through the SIP RE-INVITE procedure.

The IMS Application Server (IMS-AS) plays a role in coordinating this update. Following the change of media gateway, the IMS-AS initiates SIP RE-INVITE signalling so that the two sides can renegotiate the media transport addresses associated with the ongoing session. Depending on whether the network is maintaining satellite-based routing or falling back to the ground, the relevant IMS-AGWs and media paths are updated accordingly.

This is particularly important for LEO satellite systems, where changes in the serving satellite are a normal part of operation rather than an occasional event. The ability to relocate media functions and update traffic paths is essential for maintaining service continuity, although actual interruption performance will depend on network implementation and operating conditions.

There are also some important limitations to the Release 19 functionality. The standardised UE-Satellite-UE optimisation discussed here is restricted to IMS-based voice and video services involving two devices belonging to the same Public Land Mobile Network (PLMN), without roaming. It does not provide a general-purpose mechanism for arbitrary data communication between any two satellite-connected devices.

The requirement for satellite-based processing also means that the feature is intended for appropriately equipped regenerative satellite networks. It should not be confused with conventional transparent-payload direct-to-device services. NTT DOCOMO identifies support for additional services, including mission-critical communications and non-IMS data exchange, as areas for further development. Communication between different PLMNs and roaming scenarios also remains an important area for future standardisation, with related work being considered in Release 20.

From a network architecture perspective, this development is particularly interesting because it demonstrates how 5G is evolving towards more distributed processing. Instead of forcing all traffic through a centralised terrestrial network, selected user-plane and media functions can operate closer to the devices being served, even when those functions are located on moving satellites.

There are, of course, practical challenges. Satellite resources, onboard processing capabilities, inter-satellite connectivity, transport topology and coordination between terrestrial and non-terrestrial network functions will influence how such systems can be deployed. Standardising the architecture does not necessarily mean that operators have already implemented these capabilities commercially.

Nevertheless, the Release 19 enhancements represent an important step towards more tightly integrated terrestrial and non-terrestrial mobile networks. While the immediate focus is on optimising IMS voice and video communication, the underlying principles of distributed user-plane processing, dynamic media routing and service continuity are likely to remain relevant as NTN architectures evolve towards 6G.

For those interested in the detailed procedures, the original NTT DOCOMO article is well worth reading, particularly its signalling diagrams. The relevant 3GPP specifications include TS 23.501, which covers the 5G System architecture for UE-Satellite-UE communication, and TS 23.228, whose Annex AE addresses the IMS architecture and media routing procedures.

Related Posts: 

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , , , ,

Tuesday, 1 September 2026

Energy Efficiency Improvements in 3GPP Technologies: From LTE to 5G-Advanced

Energy efficiency has become one of the most important topics in mobile networks. Operators need to support growing traffic, wider bandwidths, massive MIMO, better coverage and new services, while also reducing energy consumption, managing cost and meeting sustainability targets.

We have put together a five-part video series looking at Energy Efficiency Improvements in 3GPP Technologies, starting with LTE and then moving through 5G NR, 5G-Advanced Release 18 and 3GPP Release 19.

The aim of the series is to explain the topic in a structured way. Energy saving in mobile networks is not simply about switching equipment off. It requires careful coordination between radio design, traffic load, user experience, QoS, mobility, device behaviour, RAN hardware, network policies and service requirements.

The five videos in the playlist are:

  1. Energy Efficiency in Mobile Networks: The Basics - This introductory video explains why energy efficiency matters, why the RAN gets most attention, how energy saving differs from energy efficiency, and why measurements and KPIs are essential before optimisation.
  2. How LTE Networks Save Energy - This video looks at LTE energy-saving mechanisms including dormant mode, carrier switch-off, secondary antenna deactivation, common channel power control, Cell DTX, compensation cells, and OAM or signalling-based control.
  3. Why 5G NR Is More Energy Efficient by Design - This part explains the energy-efficiency improvements built into 5G NR, including lean carrier design, sleep opportunities, Bandwidth Parts, carrier aggregation, UE DRX, massive MIMO, beamforming and radio hardware evolution.
  4. 5G-Advanced Release 18 Network Energy Saving - This video looks at Release 18 Network Energy Saving features such as SSB-less SCells, Cell DTX/DRX, CSI enhancements, antenna adaptation, PDSCH power adaptation, Conditional Handover for NES cells and legacy UE handling.
  5. 3GPP Release 19 Energy Efficiency and Energy Saving - The final video looks at Release 19 enhancements including on-demand SSB operation for SCells, on-demand SIB1 for idle/inactive UEs, SSB periodicity adaptation, PRACH and paging adaptation, LP-WUS/WUR, Energy Information Function, OAM, slicing, charging and energy efficiency as a service criterion.

The overall message from the series is that mobile network energy efficiency has evolved from relatively simple resource switch-off mechanisms towards more intelligent, adaptive and service-aware optimisation. LTE introduced many of the early practical ideas. 5G NR provided a more flexible and energy-efficient foundation. 5G-Advanced Release 18 made RAN Network Energy Saving more explicit, and Release 19 expands the topic towards on-demand signalling, UE wake-up efficiency and system-wide energy awareness.

The complete playlist is embedded below.

The main references used for this series include 3GPP article, 3GPP TR 21.919, 3GPP TR 38.864, 3GPP TR 38.869, NGMN material on 5G energy efficiency best practices, and technical material from Nokia Bell Labs on 5G-Advanced Network Energy Saving.

Related Posts: 

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , , , , , , , ,

Friday, 10 July 2026

From 3GPP MPS to Wi-Fi 7 EPCS

Back in January 2011, I wrote about Enhanced Multimedia Priority Service, or eMPS, in 3GPP Release 10. At the time, the focus was on extending priority treatment beyond basic voice calls to packet data and multimedia sessions over LTE and EPC.

The basic requirement has not changed. During a major incident, commercial communication networks may become heavily congested at exactly the time when certain authorised users most need to communicate. These users may include government personnel, emergency management officials and others assigned National Security or Emergency Preparedness, NS/EP, responsibilities.

3GPP addresses this through Multimedia Priority Service, or MPS, specified in TS 22.153. MPS is not a separate radio system and it should not be confused with public emergency calling. It is a mechanism that gives authorised Service Users priority treatment on commercial networks, increasing the probability that their voice, video or data communications can be successfully established and maintained during congestion.

In my original post, I explained that this required more than simply prioritising user-plane packets. End-to-end priority could involve NAS and AS signalling establishment, session establishment, resource allocation in the radio and core networks and treatment of the media bearers themselves.

Fifteen years later, the interesting development is that this idea is expanding beyond the traditional cellular access network.

The challenge is easy to understand. An authorised priority user may have an MPS subscription with a mobile operator, but that user may be inside a building, transport hub, stadium, campus or other environment where connectivity is provided over Wi-Fi. Even where cellular coverage exists, the device may already be using Wi-Fi because of local coverage, capacity or policy.

The question is therefore no longer just how to prioritise an NS/EP user in LTE or 5G. It is how priority authorisation can follow the user across different access technologies.

There are actually two related but different technical developments taking place.

The first is within 3GPP itself. In Release 19, a change to TS 22.153 added explicit MPS requirements for situations where a UE is using a 3GPP radio access technology, such as NR or E-UTRA, and non-3GPP WLAN access connected to the same EPC or 5GC. The associated work item is MPS_WLAN, or MPS when access to EPC/5GC is WLAN.

This is important, but it is still primarily a 3GPP system view. The WLAN is acting as non-3GPP access towards the mobile core.

The second development goes further. Wi-Fi 7 introduces Emergency Preparedness Communications Service, or EPCS, functionality that can provide preferred or prioritised channel access to authorised users. This means that priority treatment can also be applied on the Wi-Fi access network itself.

This creates a different architectural problem.

Wi-Fi can define how the Access Point, AP, and Station, STA, support prioritised channel access, but the Wi-Fi network still needs to know whether the user is genuinely authorised to receive that treatment.

The network therefore needs to determine whether the user is authenticated, whether the user is authorised for Priority Services, what priority level has been assigned, whether that authorisation is valid in the relevant regulatory jurisdiction and whether the network and device support the required EPCS capabilities.

This is the gap that the current IETF work is attempting to address.

The latest version at the time of writing is draft-gundavelli-radepcs-02, titled RADIUS attributes for National Security and Emergency Preparedness Service. It is an active Internet-Draft and work in progress rather than an approved IETF standard. The draft describes RADIUS extensions for authorising EPCS users so that they can receive preferential access to Wi-Fi network resources during congestion.

The proposed architecture reuses mechanisms already widely deployed for managed and roaming Wi-Fi, including Passpoint, EAP and RADIUS.

A user is first authorised for Priority Services by an appropriate Authorising Entity. The service provider receives this authorisation and stores the relevant priority information against the subscriber profile. Where the service provider is also a cellular operator and Wi-Fi Identity Provider, the priority service subscription information can be mirrored into the Wi-Fi AAA system.

The overall architecture and signalling flow are shown below.

The first part of the process is network discovery. An EPCS-enabled Wi-Fi network advertises an EPCS Roaming Consortium, while the authorised user's device contains a corresponding Passpoint profile. The device can discover the relevant roaming information and select the network using normal Passpoint mechanisms.

After the device associates with the Wi-Fi network, EAP authentication is performed and the AP or Wireless LAN Controller forwards the authentication exchange towards the Identity Provider using RADIUS.

This is where the proposed new RADIUS attributes become important.

EPCS-Capable-Indication allows the Wi-Fi Network Access Server to tell the RADIUS server that it supports EPCS. The capability information can also indicate whether priority treatment is possible only when the user device itself supports EPCS, or whether some treatment, such as downlink prioritisation, may still be possible for a non-EPCS device.

EPCS-Regulatory-Info provides information about the regulatory regime under which priority service is being authorised. This may contain an ISO 3166-1 country code or ISO 3166-2 subdivision code. This matters because priority authorisation and priority levels may be specific to a particular country or jurisdiction.

EPCS-Subscription-Info indicates that the authenticated user is authorised to receive Priority Services and carries the priority level associated with the user's subscription. The priority levels themselves are administered according to the relevant regulatory regime.

The important point is that the Wi-Fi network does not independently decide that a user should receive priority.

The authorisation originates from an external authority and is linked to an authenticated identity or subscription.

Authentication and priority authorisation are therefore separate. Successfully authenticating to a Wi-Fi network does not automatically make someone an EPCS user.

Once the AAA system confirms that the user is authorised, the AP/WLC can enable EPCS Priority Access for the device. Where both the network and device support EPCS, uplink and downlink traffic can receive priority treatment. Depending on the capabilities of the network, downlink traffic may still be prioritised even when the device itself does not support EPCS. The exact mechanism used by the network to prioritise the traffic is vendor-specific and outside the scope of the current IETF draft.

There are several interesting aspects to this architecture.

First, the solution uses the existing Wi-Fi roaming framework rather than creating an entirely separate emergency network discovery and authentication mechanism. Passpoint supports automatic discovery and network selection, EAP handles authentication and RADIUS carries the EPCS authorisation information.

Second, location and regulatory information become part of the authorisation process. A user authorised for a particular level of priority in one jurisdiction may not necessarily be entitled to the same treatment everywhere.

Third, the network needs to separate a user's normal access credentials from their entitlement to Priority Services. An ordinary subscriber, an authenticated Wi-Fi user and an authorised EPCS user may all use the same access network but receive very different treatment during congestion.

Finally, this is not simply a matter of giving some packets a higher priority marking.

Real end-to-end priority may involve access to the Wi-Fi medium, AP queues, backhaul networks, interconnected networks and application traffic. The IETF draft identifies authentication, authorisation, traffic identification and prioritisation as separate requirements. Where networks interconnect, priority indicators may also need to be passed securely to downstream networks.

It is also worth stressing the difference between Priority Services and emergency calling.

An ordinary user attempting to call 999, 112 or 911 is not automatically an NS/EP Priority Service user. Emergency calling is about allowing the public to reach emergency services, potentially even when normal cellular coverage or credentials are unavailable.

MPS and EPCS are different. They are intended for authorised users or organisations that have been assigned priority privileges so their communications have a greater probability of success during congestion.

The Wireless Broadband Alliance has been working on both areas through its Mission Critical and Emergency Services programme. Its work covers emergency calling over Wi-Fi, cellular emergency calling over OpenRoaming and NS/EP priority communications. For the priority case, the focus is on using Wi-Fi, Passpoint and roaming mechanisms to extend capabilities traditionally associated with cellular networks.

For me, the interesting part is how the boundaries between cellular and Wi-Fi continue to blur.

3GPP MPS started from the assumption that priority treatment had to be provided across the cellular system, from access signalling through to core network resources and application sessions. 3GPP has now added explicit requirements for MPS when 3GPP and WLAN accesses connect to the same EPC or 5GC.

At the same time, Wi-Fi 7 provides EPCS mechanisms for prioritised channel access, while Passpoint and the proposed RADIUS extensions provide a possible way to discover the service, authenticate the user and transfer priority authorisation into the Wi-Fi network.

The result is not a replacement for cellular MPS, and it is not simply Wi-Fi QoS.

It is the beginning of a more access-independent model in which an authorised user's priority status could potentially follow them across cellular and Wi-Fi networks, with each access technology applying the appropriate mechanisms within its own domain.

That is a much more interesting evolution than simply adding another priority bit to the network.

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , , , , ,

Thursday, 11 June 2026

Release 19 Takes Satellite, NTN and Aerial Connectivity Further

3GPP Release 19 continues the evolution of 5G-Advanced and, among many other areas, brings important enhancements for satellite access, Non-Terrestrial Networks (NTN), Uncrewed Aerial Systems (UAS), Air-to-Ground networks and positioning. While NTN was initially seen by many as a way of extending mobile coverage to remote areas, Release 19 shows that the ambition is now much broader. The aim is to make satellite and aerial connectivity more practical, more resilient and better integrated with the 5G ecosystem.

Release 17 introduced the first major NR NTN framework, largely focused on transparent satellite payloads. Release 18 added further improvements, including mobility and service continuity enhancements. Release 19 now moves the discussion towards more advanced capabilities, including regenerative payloads, Store-and-Forward satellite operation, UE-Satellite-UE communication, improved support for IoT NTN and better support for aircraft and drones.

One of the key areas in Release 19 is NR NTN Phase 3. Satellite links face challenges that are very different from terrestrial mobile networks. The distances are much greater, propagation delays are longer, satellite beams can cover very large geographical areas and satellite payload power is limited. Release 19 addresses these constraints through improved coverage and capacity mechanisms. For example, important control and system information can be repeated to improve the chance that devices can successfully receive and decode it. This is especially important for handset-type terminals and power-limited devices operating in challenging satellite conditions.

This also connects to the wider industry discussion around Direct-to-Device satellite connectivity. 3GPP does not always use the marketing phrase Direct-to-Device, but the work on improved downlink performance for handset-type terminals is clearly relevant to that vision. It is worth being careful with the abbreviation D2D, as in standards discussions it can also mean Device-to-Device. For this reason, Direct-to-Device is probably the clearer term when talking about phones or lightweight devices connecting directly to satellites.

Release 19 also improves uplink capacity in NTN through multiplexing techniques such as Orthogonal Cover Codes. This matters because a satellite beam can cover a large area with many potential users, while the available spectrum and power remain limited. Better multiplexing means more users and devices can be supported with the same satellite resources. This will become increasingly important as NTN expands beyond emergency messaging towards IoT, broadband and more diverse services.

Perhaps the most interesting architectural shift is the support for regenerative payloads and gNB functions on board the satellite. In a traditional transparent payload model, the satellite mainly acts as a relay, with most processing taking place on the ground. With regenerative payloads, more intelligence moves into space. The satellite can process, switch or route signals, making the network more flexible and less dependent on a continuous feeder link to the ground.

This helps enable one of the most distinctive Release 19 capabilities, Store-and-Forward satellite operation. In some non-geostationary satellite scenarios, the satellite may be visible to the UE but may not have a simultaneous active feeder link to the ground network. Store-and-Forward allows the satellite to temporarily store data and forward it later when connectivity to the ground segment becomes available. This is especially useful for delay-tolerant IoT applications such as asset tracking, environmental sensing, remote monitoring and logistics.

Another new area is UE-Satellite-UE communication. Normally, traffic between two users would travel via the satellite, the ground network and then back again. Release 19 starts enabling a more direct path via a regenerative satellite architecture. The initial scope is limited, including IMS voice and video services for users in the same PLMN and in non-roaming scenarios, but it is still an important step. It shows how NTN can evolve from simple coverage extension towards a more capable communication platform.

IoT NTN also receives significant attention in Release 19. Enhancements include Store-and-Forward operation for IoT, improved uplink capacity and support for Public Warning System messages over NB-IoT NTN. Release 19 also introduces IoT NTN TDD mode, which is important because earlier NB-IoT NTN work was focused on FDD operation. TDD support gives satellite operators more flexibility and opens the door to additional deployment scenarios.

Public warning support is another practical and important enhancement. Satellite connectivity can be extremely valuable in areas where terrestrial networks are unavailable, damaged or overloaded. Supporting warning messages over satellite and IoT NTN can help extend emergency alerting capabilities to remote regions, maritime environments and disaster-affected areas.

Release 19 is not only about satellites. It also includes enhancements for Air-to-Ground networks and UAS Phase 3. Air-to-Ground connectivity uses ground-based cellular infrastructure to serve aircraft, rather than relying on satellites. Release 19 work in this area supports improvements such as downlink carrier aggregation and MIMO for better throughput and more efficient spectrum use.

For UAS, Release 19 continues the work needed to make drones better integrated into mobile networks and service platforms. This includes support for pre-mission planning, in-mission monitoring, command and control reliability, network-assisted Detect and Avoid, No-Transmit Zones and interaction with UAS traffic management systems. These capabilities matter because drones are increasingly being used for inspection, logistics, public safety, disaster response, smart cities and future urban air mobility.

Positioning is another important part of the Release 19 satellite and aerial story. Enhancements include on-demand broadcast of GNSS assistance data, support for BeiDou B2b in A-GNSS for LTE and NR, and support for NavIC L1 SPS in NR and LTE. These improvements help make positioning more flexible and globally relevant, especially for NTN, IoT, maritime, aviation and UAS use cases.

Taken together, Release 19 shows how NTN is maturing. The focus is no longer just on whether a device can connect to a satellite. The bigger question is how satellite, aerial and terrestrial networks can work together as part of a wider 5G-Advanced system. With regenerative payloads, Store-and-Forward operation, UE-Satellite-UE communication, IoT NTN enhancements, public warning support, Air-to-Ground improvements and UAS integration, Release 19 takes another important step towards making non-terrestrial connectivity practical, resilient and service-rich.

The video below provides a visual walkthrough of these Release 19 satellite, NTN, UAS and aerial enhancements.

Related Posts: 

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , , , , , ,

Tuesday, 28 April 2026

7 MHz Brings Much Needed Flexibility to 5G NR

The evolution of channel bandwidths in 5G NR has been relatively conservative compared to earlier generations, but recent developments in 3GPP Release 19 show that this is beginning to change. The introduction of 7 MHz channel bandwidth in FR1 marks an important step towards addressing practical spectrum realities that many operators have faced since the early days of NR.

In the original 5G NR specifications, channel bandwidths were defined in regular steps of 5 MHz, such as 5, 10, 15, 20 MHz and so on. This design choice simplified implementation and aligned well with clean spectrum allocations. However, real world spectrum holdings are rarely so neat. Many operators hold fragmented or irregular chunks of spectrum, particularly in low bands where legacy allocations and refarming have resulted in non standard bandwidths.

This was not a new problem. LTE had already addressed this challenge by supporting a wider range of channel bandwidths including 1.4 MHz and 3 MHz, in addition to the more common 5, 10, 15 and 20 MHz. Combined with carrier aggregation, LTE allowed operators to make efficient use of spectrum even when it was not aligned to neat multiples. When NR was introduced, this flexibility was initially reduced, creating a gap between specification and deployment reality.

Recognising this limitation, 3GPP introduced a 3 MHz channel bandwidth in Release 17 and continued refining spectrum flexibility in Release 18. The addition of 3 MHz was an important step, particularly for narrowband and coverage focused deployments, and it allowed combinations such as 8 MHz or 13 MHz to be better utilised through aggregation.

However, this still did not fully solve the problem. Operators continued to highlight the need to support other irregular bandwidths such as 6, 7, 11 and 12 MHz. These are not edge cases but reflect actual spectrum holdings in several bands. Release 19 addresses this directly by introducing native 7 MHz channel bandwidth.

The standardisation of 7 MHz focuses on FR1 operation, initially targeting bands such as n5 and n26. Rather than relying on workarounds such as overlapping channels or using the next larger bandwidth, this approach defines 7 MHz as a native channel bandwidth within NR. This avoids some of the practical issues associated with earlier approaches, including blocking from adjacent operators and compatibility challenges with legacy devices.

The work also includes a comprehensive set of requirements covering both core and performance aspects. These span RF requirements for user equipment and base stations, spectrum utilisation considerations, and the necessary signalling updates across the protocol stack. The effort is led by RAN4, with coordination from RAN2 and RAN3 to ensure seamless integration into the NR framework.

An interesting aspect of this development is the constraint to 15 kHz subcarrier spacing. This reflects the focus on low band and coverage scenarios where such numerology is most relevant. It also helps to limit complexity while still delivering the intended benefit of improved spectrum utilisation.

From a deployment perspective, the introduction of 7 MHz fills an important gap. While 3 MHz enabled some additional flexibility, it was not sufficient to address all irregular spectrum cases. With 7 MHz, operators gain a more practical option that aligns better with real spectrum allocations, especially in bands where 6 or 7 MHz chunks are common.

It is also worth noting that this is likely not the end of the story. Earlier study work identified several other irregular bandwidths that could be useful. The inclusion of 7 MHz in Release 19 can be seen as a pragmatic step, with the possibility of extending similar support to other bandwidths in future releases once the framework is established.

In many ways, this development reflects a broader trend in 5G and beyond. Early specifications tend to favour simplicity and clean design, but as deployments mature, practical considerations drive the need for greater flexibility. Spectrum is one of the most valuable assets for operators, and the ability to use it efficiently, regardless of how it is fragmented, is critical.

The addition of 3 MHz in earlier releases and the introduction of 7 MHz in Release 19 shows that NR is evolving in that direction. It is a reminder that standardisation is not just about defining ideal systems, but also about adapting to the realities of how networks are deployed and operated.

Ericsson’s blog provides a useful background on the introduction of 3 MHz bandwidth in Release 18, available here. Further technical details on the 7 MHz enhancement can be found in RP-251453, which describes the NR FR1 7 MHz channel bandwidth Work Item.

Related Posts: 

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , , ,

Thursday, 9 April 2026

3GPP Release 19 Description and Summary of Work Items

As the journey towards 3GPP Release 20 and 6G (3GPP Rel-21) continues to gather pace, the recently concluded Release 19 comes with a clearer view of what the next phase of 5G evolution, often referred to as 5G-Advanced, will look like in practice. One of the most useful artefacts in this process is the recently published technical report 3GPP TR 21.919, which offers a consolidated snapshot of the features and work items currently shaping this release.

Rather than focusing on detailed specifications, this report takes a step back and provides accessible summaries of the agreed work items. Each summary is intended to answer two simple but important questions: what problem is being addressed, and what impact the feature will have on the overall system. This makes the document particularly valuable not only for specialists deeply involved in standardisation work, but also for a broader audience trying to keep track of where the industry is heading.

It is worth noting that this is still very much a work in progress (50% complete). At the time of publication, just over 60 summaries have been included, with many more expected in future updates. Even so, the current version already highlights the sheer breadth of activity in Release 19, spanning everything from energy efficiency and non-terrestrial networks to AI, immersive services, and advanced radio capabilities.

In this post, I will not attempt to reinterpret or condense the summaries themselves. Instead, I am sharing the full list of topics covered in the report below, which provides a useful index into the areas that 3GPP worked on as part of Release 19.

It should be noted that the technical report (TR) presents the "initial state" of the Features introduced in Release 19, i.e. as they are by the time of publication of this document. Each Feature is subject to be later modified or enhanced, over several years, by the means of Change Requests (CRs). To further outline a feature at a given time, it is recommended to retrieve all the CRs which relate to the given Feature, as explained in its Reference section. 

Below is the list of all topics covered in this report. Some of the topics may be missing a summary, which will be added later in the later updates.  

5 Rel-19 Energy Efficiency, Energy Saving
5.1   Enhancements of Network energy savings for NR
5.2   Low-power wake-up signal and receiver for NR (LP-WUS/WUR)
5.3   Energy Efficiency as Service Criteria

6   Rel-19 Satellite (5GSAT), NTN, UAS, Aerial
6.1   Satellite access Phase 3
6.1.1   Security Aspects of 5G Satellite Access Phase 3
6.1.2   Charging aspects of satellite access Phase 3
6.2   Non-Terrestrial Networks (NTN) for NR Phase 3
6.3   Enhancements for Air-to-ground network for NR
6.4   Inter-RAT mode mobility support from E-UTRAN TN to NR NTN
6.5   Non-Terrestrial Networks (NTN) for Internet of Things (IoT) Phase 3 (for LTE)
6.6   Introduction of IoT-NTN TDD mode
6.7   Enhanced requirements and test methodology for NR NTN and IoT NTN
6.8   On-demand broadcast of GNSS assistance data
6.9   Uncrewed Aerial System Phase 3
6.10   Support for PWS in Satellite E-UTRAN and Satellite NG-RAN
6.11   Introduction of BDS (BeiDou Navigation Satellite System) B2b Signal in A-GNSS for LTE and NR
6.12   Introduction of A-GNSS support for NavIC (Navigation with Indian Constellation) L1 SPS (Standard Positioning Service) in NR & LTE
6.13   Management Aspects of Rel-18's NTN Phase 2
6.14   Lower Selection-priority for PLMN Selection
6.15   New LTE band for 5G broadcast for region 3 utilizing a geosynchronous satellite
6.16   Satellite band-related items
6.16.1   Introduction of Ku bands for NR NTN
6.16.2   Introduction of additional operating NR bands for HAPS (High Altitude Platform Station)
6.16.3   Introduction of another NR NTN S-band (MSS band 2000-2020 MHz UL and 2180-2200 MHz DL)
6.16.4   New NR NTN bands to support Extended L-band and combined MSS L-band and Extended L-band ranges
6.16.5   Introduction of another IoT-NTN S-band (MSS band 2000-2020 MHz UL and 2180-2200 MHz DL)

7   Rel-19 Internet of Things (IoT) and Reduced Capability (RedCap) UE
7.1   NR power class 2 RedCap (Reduced Capability) UE in FR1
7.2   NAS layer overhead reduction for data transfer using CP CIoT
7.3   Management Aspects of RedCap features

8   Ambient power-enabled Internet of Things (IoT)
8.1   Ambient power-enabled Internet of Things (IoT) (SA and CT)
8.1.1   Charging for Ambient power-enabled Internet of Things
8.1.2   Security Aspects of Ambient IoT Services in 5G for Isolated Private Networks
8.2   Solutions for Ambient IoT (Internet of Things) in NR

9   Rel-19 Artificial Intelligence (AI)/Machine Learning (ML)
9.1   AI/ML Model Transfer Phase 2
9.2   Core Network Enhanced Support for Artificial Intelligence (AI)/Machine Learning (ML)
9.3   Application enablement for AI/ML services
9.4   Artificial Intelligence (AI)/Machine Learning (ML) for NR air interface
9.5   Artificial Intelligence (AI)/Machine Learning (ML) for NR air interface
9.6   Enhancements for Artificial Intelligence (AI)/Machine Learning (ML) for NG-RAN
9.7   AI/ML Management Phase 2
9.8   Protocol for AI Data Collection from UPF

10   Rel-19 Verticals and Non Public Network
10.1   Rel-19 Enhancements of 3GPP Northbound and Application Layer Interfaces and APIs
10.2   SEAL DD (Data Delivery) Phase 2
10.3   Common Application Programming Interface (API) Framework (CAPIF) Phase 3
10.4   Enhanced OAM for management service exposure to external consumers through CAPIF
10.5   Non-Public Network (NPN) security considerations
10.6   Security for PLMN hosting a NPN
10.7   Interconnect of SNPN
10.8   ProSe support in NPN

11   Rel-19 communications services
11.1   Media Messaging Enhancements
11.2   Terminal Audio quality performance and Test methods for Immersive Audio Services, Phase 2
11.3   EVS Codec Extension for Immersive Voice and Audio Services, Phase 2
11.4   5GMSG Service phase 3
11.5   Video Operating Points - Harmonization and Stereo MV-HEVC
11.6   Advanced Media Delivery
11.7   5G Real-time Transport Protocol Configurations, Phase 2
11.8   Next Generation Real time Communication services Phase 2
11.8.1   System architecture for Next Generation Real time Communication services Phase 2
11.8.2   Security support for the Next Generation Real Time Communication services Phase 2
11.8.3   Application enablement aspects for MMTel

12   Rel-19 XR (eXtended Reality), Augmented Reality (AR), Metaverse, Edge Computing
12.1   Localized Mobile Metaverse Services
12.2   Extended Reality and Media
12.3   XR (eXtended Reality) for NR Phase 3
12.4   Avatar Communications in AR Calls
12.5   Split rendering over IMS
12.6   Enhancement of support for Edge Computing in 5G Core network - Phase 3
12.7   Edge Computing for Industrial Scenarios
12.8   Edge Computing Considering the Operational Needs of Service Hosting Environment
12.9   Architecture for enabling Edge Applications Phase 3

13   Rel-19 High Power UEs (HPUE)
13.1   Rel-19 High power UE (power class 1.5 or 2) for NR intra-band CA or NR inter-band CA/DC band combinations with/without NR Supplementary Uplink (UL)
13.2   Rel-19 High power UE (power class 1.5 and 2) for NR FR1 TDD/FDD single band for handheld/FWA UEs, and high power UE operation (power class 1) for FWVM (fixed-wireless/vehicle-mounted) use cases in a single NR band
13.3   Introduction of Power Class 2 and UE 40MHz Channel Bandwidth in NR band n28
13.4   Rel-19 High power UE (power class 1.5 or 2) for DC combinations of LTE band(s) and NR band(s)
13.5   Rel-19 High power UE (power class 2) and high power operation (power class 1) for fixed-wireless/vehicle-mounted use cases in a single LTE band

14   Rel-19 RAN topology
14.1   5G NR Femto
14.2   Additional topological enhancements for NR
14.3   Vehicle Mounted Relays Phase 2

15   Rel-19 Sidelink, Proximity
15.1   NR sidelink multi-hop relay
15.2   UE-to-UE multi-hop relay
15.3   NR Sidelink: Intra-band Carrier Aggregation in ITS band
15.4   Charging Aspects of Ranging and Sidelink Positioning
15.5   Multi-path relay
15.6   Proximity-based Services in 5GS Phase 3

16   NR and LTE Dual Connectivity (DC)
16.1   UE RF enhancements for NR FR1/FR2 and EN-DC, Phase 4
16.2   Support of intra-band non-collocated EN-DC/NR-CA deployment Phase2: new receiver type(s)
16.3   Rel-19 downlink interruption for NR and EN-DC band combinations at dynamic Tx Switching in Uplink
16.4   Rel-19 DC of x LTE band(s), y NR band(s) (1<=x<6, 1<=y<6, x+y<=6) and single or two NR Supplementary Uplink (SUL) bands
16.5   Simultaneous Rx/Tx band combinations for NR CA/DC, NR SUL and LTE/NR DC in Rel-19
16.6   UE Conformance - Rel-19 NR CA and DC; and NR and LTE DC Configurations

17   Rel-19 Other NR and LTE Radio
17.1   Adding channel bandwidth(s) support to existing NR bands and CA/ENDC combinations in REL-19
17.2   Data collection for SON (Self-Organising Networks)/MDT (Minimization of Drive Tests) in NR standalone and MR-DC (Multi-Radio Dual Connectivity) Phase 4

18   Rel-19 NR Radio
18.1   NR mobility enhancements Phase 4
18.2   Evolution of NR duplex operation: Sub-band full duplex (SBFD)
18.3   NR Radio Resource Management (RRM) Phase 5
18.4   Multi-carrier enhancements for NR Phase 3
18.5   NR demodulation performance Phase 5
18.6   NR MIMO Phase 5
18.7   FR1 TRP, TRS and MIMO OTA testing enhancement Phase 3
18.8   Rel-19 NR CA/DC for x bands DL with y bands UL (x<7, y<3) and SUL/CA band combinations with a single SUL or two SUL cells
18.9   Low band carrier aggregation via switching
18.10  NR channel BW less than 5MHz for FR1 Phase 2
18.11  mmWave in NR: UE spurious emissions and EESS (Earth Exploration Satellite Service) protection
18.12  NR base station (BS) RF requirement evolution for FR1/FR2 and testing
18.13  UE Conformance - New Rel-19 NR licensed bands and extension of existing NR bands
18.14  Other band-related items
18.14.1   7MHz Channel Bandwidth for n26 and n5
18.14.2   Introduction of the NR FDD 1.4 GHz band
18.14.3   Introduction of NR bands n87 and n88
18.14.4   Introduction of NR band n68
18.14.5   Additional NR bands for NR features in Rel-19
18.15  Study on spatial channel model for demodulation performance requirements for NR

19   Rel-19 LTE Radio
19.1   LTE-based 5G Broadcast Phase 2
19.2   Rel-19 LTE-Advanced Carrier Aggregation for x bands (1<=x<= 6) DL with y bands (y=1, 2) UL
19.3   Band-related items
19.3.1   New bands for LTE based 5G terrestrial broadcast for early deployments
19.3.2   Introduction of LTE FDD band in 1800–1830 MHz for Canada

20   Rel-19 Mission Critical, eCall, Emergency
20.1   Enhanced Mission Critical Architecture
20.2   Enhanced Mission Critical Location Management
20.3   Alignment of eCall over IMS with CEN
20.4   UE Conformance - Alignment of eCall over IMS with CEN
20.5   Multiple Location Procedure for Emergency LCS Routing
20.6   Multimedia Priority Service (MPS) for Messaging services
20.7   Mission Critical (MC) services for generic support on Isolated Operation for Public Safety (IOPS) mode of operation
20.8   Sharing of administrative configuration between interconnected MC service systems
20.9   Future Railway Mobile Communication System (FRMCS) Phase 5
20.10   Mission critical security enhancements for release 19
20.11   Protocol enhancements for Mission Critical Services

21   Rel-19 Network Slicing
21.1   Network Controlled Network Slice Selection

22   Rel-19 Service-Based Architecture (SBA)
22.1   UPF enhancement for Exposure And SBA Phase 2
22.2   Automatic Certificate Management Environment (ACME) for the Service Based Architecture (SBA)
22.3   Reducing Information Exposure over SBI
22.4   Service Based Interface Protocol Improvements Release 19

23   Rel-19 QoS and Policy
23.1   Rel-19 Enhancements of UE Policy
23.2   Rel-19 Enhancements of Session Management (SM) Policy
23.3   Minimize the Number of Policy Associations
23.4   Spending Limits for UE Policies in Roaming scenario
23.5   Enhancing Parameter Provisioning with static UE IP address and UP security policy
23.6   Providing per-subscriber VLAN instructions from UDM and DN-AAA
23.7   QoS monitoring enhancement

24   Rel-19 multi-access
24.1   Upper layer traffic steering and switching over dual 3GPP access
24.2   Multi-Access (ATSSS_Ph4)
24.3   ATSSS Rule Provisioning via 3GPP access connected to EPC
24.4   Local traffic routing for multi-access UE

25   Other topics
25.1   Deferred 5GC-MT-LR Procedure for Periodic Location Events based NRPPa Periodic Measurement Reports
25.2   Subscription control for reference time distribution in EPS
25.3   Rel-19 IMS:
25.3.1   PS Data Off for IMS Data Channel Service
25.3.2   IMS Disaster Prevention and Restoration Enhancement
25.3.3   IMS Stage-3 IETF Protocol Alignment
25.4   Identifying non-3GPP Devices Connecting behind a UE or 5G-RG
25.5   Integrated Sensing and Communication
25.6   Rel-19 Application Data Analytics Enablement Service
25.7   Interworking of Non-3GPP Digital Terrestrial Broadcast Networks with 5GS Multicast Broadcast Services
25.8   Minimization of Service Interruption During Core Network Failure Phase 2
25.9   Measurement Data Collection
25.10  Enhanced application layer support for location services
25.11  NF discovery and selection by target PLMN
25.12  MSISDN verification operation support to Nnef_UEId Service
25.13  Rel-19 Enhancements of Network Automation Enablers
25.14  Enhancement of controlling RAT utilization
25.15  CT Aspects for IP Domain usage
25.16  Indirect Network Sharing
25.17  Management of Network Sharing Phase 3
25.18  Roaming Value-Added Services
25.19  Monitoring of signalling traffic in 5G
25.20  Roaming traffic offloading via session breakout in HPLMN
25.21  Stage-3 5GS NAS protocol development 18
25.22  Stage-3 SAE Protocol Development
25.23  Harmonization of test case definitions for cross-RAT usability
25.24  Data management regarding subscriptions and reporting
25.25  PRU Usage Extension supported by Core Network

26   Rel-19 miscellaneous Security
26.1   Security Assurance Specification for maintenance of 5G features
26.2   5G Security Assurance Specification (SCAS) for the Unified Data Repository (UDR)
26.3   5G Security Assurance Specification (SCAS) for the Short Message Service Function (SMSF)
26.4   Addition of 256-bit security Algorithms
26.5   Addition of Milenage-256 algorithm
26.6   Roaming and interconnect authorization aspects in indirect communication
26.7   Public key distribution and Issuer claim verification of the Access Token
26.8   3GPP profiles for cryptographic algorithms and security protocols
26.9   Mobility over non-3GPP access to avoid full primary authentication
26.10  LI Handling of Protected Services
26.11  Lawful Interception Rel-19
26.12  Lawful Interception Guidance Rel-19
26.13  Specification of example algorithm for alternative f5* (f5**) function

27   Rel-19 miscellaneous OAM&charging
27.1   Charging aspects for Multi-Operator Core Network (MOCN) Network Sharing
27.2   Service Based Management Architecture enhancement phase 3
27.3   Management Data Analytics phase 3
27.4   Intent driven management services for mobile network phase 3
27.5   Management of planned configurations
27.6   Management aspects of Network Digital Twins
27.7   Closed Control Loop Management
27.8   Data management phase 2
27.9   5G performance measurements and KPIs phase 4
27.10  5G Advanced NRM features phase 3
27.11  Subscriber and Equipment Trace and QoE collection management
27.12  Management of IAB nodes
27.13  Enhancement of Management Aspects Related of NWDAF Phase 2
27.14  CHF Segmentation
27.15  Subscriber Data Migration

You can download the latest version of the specs from here.

Related Post: 

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , , , , ,

Tuesday, 4 November 2025

AIoT and A-IoT

Our industry loves acronyms. In fact, sometimes it feels as if half our job is simply keeping up with them, while the other half is explaining them to everyone else. A recent example I saw referenced D2D for satellites, but expanded it as Device to Device instead of Direct to Device. Today, two similar acronyms are gaining momentum and are likely to become far more mainstream: AIoT and A-IoT.

Artificial Intelligence (AI) and the Internet of Things (IoT) are two of the key technological pillars of the modern digital world. IoT connects billions of devices, from sensors and cameras to industrial machinery, all producing vast amounts of useful data. AI enables these devices and systems to learn from this data, recognise patterns, predict outcomes, and act autonomously.

When these technologies come together, we get the Artificial Intelligence of Things, or AIoT. In simple terms, AIoT allows connected devices to analyse the data they generate and make decisions without always relying on central systems.

The intelligence in AIoT can sit in different places. Cloud based AI offers extensive processing power and the ability to leverage wider datasets. Edge AI processes data closer to where it is generated, enabling faster and more context aware decision making while reducing bandwidth use and protecting data privacy. Increasingly, lightweight machine learning models allow intelligence directly on devices themselves, enabling instant reactions without constant network access. This evolution transforms IoT devices from passive data collectors into proactive decision makers.

The benefits are significant. AIoT increases automation, improves efficiency, enhances reliability, and enables predictive maintenance, energy optimisation, autonomous navigation, and smarter logistics. It also supports sustainability initiatives, for instance by improving energy and water use monitoring or enabling more intelligent control of municipal utilities. In short, AIoT forms a key part of the digital transformation strategies emerging across industries.

To get a better sense of how AIoT could shape our everyday lives, I have embedded a couple of older Ericsson videos below that imagine a future where intelligence is seamlessly built into everything.

For anyone interested in going deeper into this topic, Transforma Insights and Supermicro have good explainers. While 3GPP continues to work on AI, ML and IoT, AIoT as a concept is largely implementation driven rather than a standardised feature in itself.

In contrast, 3GPP is actively defining a different acronym: A-IoT, short for Ambient IoT.

Ambient IoT represents a major shift in connected device design. Instead of relying on batteries or frequent charging, Ambient IoT devices operate using energy harvested from their surroundings. This can include radio signals, light, heat, or motion. The technology supports both passive operation, where devices backscatter incoming RF signals, and active operation, where they harvest enough power to generate and transmit signals independently.

Unlike traditional IoT devices, Ambient IoT units are extremely low power, low cost, and very simple in design. They have a shorter range and lower data throughput than conventional wireless technologies, but they excel in scenarios where massive numbers of tiny, battery-free sensors can be deployed and left to operate with minimal maintenance.

This makes Ambient IoT well suited to applications such as environmental sensing, supply chain tracking, inventory monitoring, smart agriculture, and intelligent labelling. It also opens opportunities in consumer environments, from smart packaging to indoor positioning. With the right network support, these devices can operate indefinitely, enabling sustainable, large-scale sensing networks.

Ambient IoT is already included in 5G Advanced Release 19. For those interested in learning more, 3GPP has a detailed overview, Oppo has produced an excellent white paper, and LG Uplus has published a forward looking document exploring Ambient IoT in the context of 6G.

Both AIoT and Ambient IoT represent the next phase of connected intelligence. AIoT pushes computation and decision making closer to where data originates, while Ambient IoT removes power barriers and enables pervasive, maintenance-free connectivity. Together, they will support systems that are scalable, energy efficient and context aware.

As these technologies mature, we can expect a world where devices are not only always connected, but also constantly learning, adapting, and operating independently with minimal energy demands. The future of connectivity lies in this balance between intelligence and efficiency, and both AIoT and Ambient IoT will play a crucial role in shaping it.

Related Posts: 

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , , , , , , , , ,
Subscribe to: Posts (Atom)