Aerial UE - NR Support for UAV

A drone with an NR modem is a UE, but it does not behave like one on the ground. At 100 m or 150 m it sees many cells in line of sight. It hears their interference, and its uplink reaches all of them too. A cellular network is planned for UEs near the ground, with antennas tilted down, so a flying UE breaks several planning assumptions at once. Release 18 added a set of NR features for this case, under the name Aerial UE.

Most of these features are about information. The network wants to know that a UE is aerial, how high it is, where it will fly next, and whether it sees too many strong cells. With that information the gNB can choose a better configuration, a better target cell, or a different frequency. This page goes through the Release 18 features in that order, with the RRC fields behind each one. The radio side of drone links, such as range and interference with height, is covered in the UAV Communication page.

• Why does an aerial UE need special handling ?
• Identifying an aerial UE
• Height-based reporting - events H1, H2 and AxHy
• Interference detection - numberOfTriggeringCells
• Altitude-dependent configuration
• Flight path reporting
• Location, BRID/DAA and Release 19 additions
• Deployment options - does an operator need dedicated TRPs ?
• Reference

Why does an aerial UE need special handling ?

What changes when a UE moves from the street to 120 m above it ? On the ground, buildings and terrain block most cells, so a UE usually sees one strong server and a few weaker neighbours. In the air, those obstacles are below the UE. The UE now has line of sight to many cells, some of them far away. The main lobe of a down-tilted antenna points below the drone, so the drone is often served by side lobes, and the strongest cell can be a distant one.

This has two consequences. In the downlink, the UE receives strong signals from many cells at once, so its SINR is low even when its RSRP is high. In the uplink, its transmission arrives at many cells with little attenuation, so one drone raises the interference level for UEs on the ground in many cells. Neither effect depends on the drone doing anything wrong. They are caused by height and line of sight alone.

So the network needs to recognise these UEs and react. LTE did this first: as far as I know, LTE Release 15 introduced height-based events and flight path reporting for aerial UEs. NR Release 18 brought the same ideas to NR and extended them.

• Many cells in line of sight: high RSRP from many cells, but low SINR, because most of them are interference.
• Uplink interference: one aerial UE can raise the interference floor in several cells. This is why the network wants to know which UEs are aerial.
• Side-lobe service: the best cell can change quickly and unpredictably as the drone moves through side lobes of different cells.
• Height matters for decisions: a configuration that works at 30 m may not work at 150 m. The Release 18 features all give the network height-related information.

Identifying an aerial UE

How does a gNB know that a UE is a drone ? It cannot tell from the radio signal alone, and a smartphone carried in a drone is technically possible too. NR uses two independent sources. The first is the subscription, which says whether this user is authorized for aerial operation. The second is the UE capability, which says which aerial features the modem supports.

The subscription information is stored in the UDM and transferred to the AMF at registration. The AMF passes it to the gNB in NGAP INITIAL CONTEXT SETUP REQUEST, and can update it with UE Context Modification or Path Switch Request. At Xn handover, the source gNB includes it in the XnAP HANDOVER REQUEST. So the gNB that serves the UE always knows whether it is an authorized aerial UE. The capability side is a group of Release 18 bits in AerialParameters-r18.

Following is based on 38.331 v19.4.0 (Release 19)

AerialParameters-r18 ::=                      SEQUENCE {
    -- Support of Aerial UE features
    aerialUE-Capability-r18                       ENUMERATED {supported}                               OPTIONAL,
    -- Support of altitude measurement and event H1/H2-triggered reporting
    altitudeMeas-r18                              ENUMERATED {supported}                               OPTIONAL,
    -- Support of altitude based measurement configuration of SSB-ToMeasure
    altitudeBasedSSB-ToMeasure-r18                ENUMERATED {supported}                               OPTIONAL,
    -- Support of events A3H1, A3H2, A4H1, A4H2, A5H1, A5H2
    eventAxHy-r18                                 ENUMERATED {supported}                               OPTIONAL,
    -- Support of flight path reporting
    flightPathReporting-r18                       ENUMERATED {supported}                               OPTIONAL,
    -- Support of flight path availability indication via UAI
    flightPathAvailabilityIndicationUAI-r18       ENUMERATED {supported}                               OPTIONAL,
    -- Support of numberOfTriggeringCells for eventA3, eventA4, and eventA5, and additionally, if the UE supports eventAxHy-r18,
    -- support of numberOfTriggeringCells for eventA3H1, eventA3H2, eventA4H1, eventA4H2, eventA5H1, and eventA5H2
    multipleCellsMeasExtension-r18                ENUMERATED {supported}                               OPTIONAL,
    -- Support of handling aerial-specific Ns value(s) and Pmax list broadcasted by the cell
    nr-NS-PmaxListAerial-r18                      ENUMERATED {supported}                               OPTIONAL,
    -- Support of reporting only the measurement report corresponding to the event with the smallest value between the
    -- altitude of the UAV and the altitude threshold for which the altitude-related entering condition e.g. A3H1-2 is satisfied, when
    -- multiple events of the same type (Hx or AxHy) for the same MO (for AxHy) are triggered simultaneously.
    simulMultiTriggerSingleMeasReport-r18         ENUMERATED {supported}                               OPTIONAL,
    -- Support of A2X service(s) using PC5 Sidelink and dedicated resource pool for A2X service(s)
    sl-A2X-Service-r18                                 ENUMERATED {brid, daa, bridAndDAA}                   OPTIONAL,
    ...,
    [[
    -- Support of condEvents A3H1, A3H2, A5H1, A5H2
    condEventAxHy-r19                             ENUMERATED {supported}                               OPTIONAL
    ]]
}

• aerialUE-Capability-r18: the UE supports the Aerial UE features as a whole.
• altitudeMeas-r18, eventAxHy-r18: the height-based events in the next section.
• flightPathReporting-r18, flightPathAvailabilityIndicationUAI-r18: flight path reporting, and indicating its availability in UEAssistanceInformation.
• nr-NS-PmaxListAerial-r18: the UE can apply aerial-specific NS values and Pmax. A cell can broadcast frequencyBandListAerial-r18 with its own nr-NS-PmaxListAerial, so an aerial UE can get a lower maximum power or different emission rules than a ground UE in the same band. This is a direct tool against aerial uplink interference.
• sl-A2X-Service-r18, condEventAxHy-r19: BRID/DAA over sidelink, and the Release 19 altitude-based CHO events. Both are described in the last section.

Height-based reporting - events H1, H2 and AxHy

The simplest piece of height information is a threshold crossing. The network does not need the altitude every second. It needs to know when the UE goes above or below a height where its configuration should change. Release 18 adds two measurement events for this, H1 and H2, defined in 38.331 clauses 5.5.4.21 and 5.5.4.22. They work like A1 and A2, but the measured quantity is the UE altitude instead of RSRP.

Ms is the UE altitude relative to sea level, and Ms, Hys and Thresh are all in meters. Note the reference. It is sea level, not the ground, so a threshold of 300 m means about 100 m above a city at 200 m elevation. Figure 1 shows the two events with their hysteresis.

Figure 1. Events H1 and H2. The shaded band is twice the hysteresis wide, so a drone hovering near the threshold does not trigger a report every few seconds.

The H events alone say nothing about the radio. Release 18 therefore also defines six combined events, written AxHy: A3H1, A3H2, A4H1, A4H2, A5H1 and A5H2. Each one triggers only when the RSRP/RSRQ/SINR condition of A3, A4 or A5 and the altitude condition of H1 or H2 are met together. A typical use is to allow a handover to a neighbour only above or only below a given height. The listing below shows H1 and A3H1 from ReportConfigNR. H2 and the other AxHy events have the same structure.

Following is based on 38.331 v19.4.0 (Release 19)

eventH1-r18                                SEQUENCE {
            h1-Threshold-r18                            Altitude-r18,
            h1-Hysteresis-r18                           HysteresisAltitude-r18,
            reportOnLeave-r18                           BOOLEAN,
            timeToTrigger-r18                           TimeToTrigger,
            includeAltitudeUE-r18                       BOOLEAN,
            simulMultiTriggerSingleMeasReport-r18       BOOLEAN
        },
        eventA3H1-r18                              SEQUENCE {
            a3-Offset-r18                               MeasTriggerQuantityOffset,
            reportOnLeave-r18                           BOOLEAN,
            a3-Hysteresis-r18                           Hysteresis,
            timeToTrigger-r18                           TimeToTrigger,
            useAllowedCellList-r18                      BOOLEAN,
            h1-Threshold-r18                            Altitude-r18,
            h1-Hysteresis-r18                           HysteresisAltitude-r18,
            includeAltitudeUE-r18                       BOOLEAN,
            simulMultiTriggerSingleMeasReport-r18       BOOLEAN
        },

Altitude-r18 ::=              INTEGER (minAltitude-r18..maxAltitude-r18)

HysteresisAltitude-r18 ::=                      INTEGER (0..64)

• Altitude-r18: -420 m to 10000 m relative to sea level (minAltitude-r18, maxAltitude-r18). The value is directly in meters.
• HysteresisAltitude-r18: 0 to 64 m.
• includeAltitudeUE-r18: when true, the UE adds altitudeUE-r18 to MeasResults, so the report carries the actual altitude as well as the event.
• simulMultiTriggerSingleMeasReport-r18: a network may configure several H1 events with different thresholds. If a fast climb triggers several of them at once, this flag makes the UE report only the one whose threshold is closest to its current altitude.
• Capabilities: H1/H2 need altitudeMeas-r18, and the combined events need eventAxHy-r18.

The general event framework is described in the Measurement Report page.

Interference detection - numberOfTriggeringCells

How can the network detect that a UE is causing or suffering aerial interference, without asking for its height ? The typical sign is many strong cells at the same time. A ground UE rarely has five neighbours that all satisfy A4. An aerial UE often does. Release 18 turns this observation into a reporting rule.

The new field numberOfTriggeringCells-r18 in ReportConfigNR sets a count from 2 up to maxCellReport. With it, an A3, A4 or A5 event, or one of the AxHy events, triggers a report only when at least that many cells fulfil the event at the same time. After the first report, the UE keeps updating its list of triggered cells. It sends no further report while the list stays at or above the configured count, unless reportOnLeave is configured.

• Detection without trusting the UE: the trigger is purely radio based. A UE that does not report itself as aerial, or that has no altitude, is still detected by this pattern.
• Applies to neighbour events only: the field applies to A3, A4, A5 and the AxHy events, which compare neighbour cells.
• reportOnLeave: with reportOnLeave, the report can list the cells that left the condition in cellsMetReportOnLeaveList-r18.
• Capability: multipleCellsMeasExtension-r18. It covers A3, A4 and A5, and the AxHy events as well when the UE also supports them.

What the gNB does after detection is left to implementation. Possible actions are a lower uplink power, an aerial-specific NS and Pmax, a handover to a frequency reserved for drones, or a release. 38.300 does not prescribe any of them.

Altitude-dependent configuration

Height-based events tell the network when a UE changes height. Then the network has to reconfigure the UE, which costs signalling every time the drone climbs or descends. Release 18 offers an alternative for measurement: the network gives several configurations at once, each for an altitude range, and the UE switches between them by itself.

In Release 18 this applies to ssb-ToMeasure, the bitmap of SSBs that the UE measures. The reason is beam geometry. At low height the UE sees mainly the SSB beams pointing towards the ground, and at high height it may see a different set. MeasObjectNR can carry up to 8 altitude ranges (maxNrofAltitudeRanges-r18), each with its own SSB set.

Following is based on 38.331 v19.4.0 (Release 19)

SSB-ToMeasureAltitudeBasedList-r18 ::= SEQUENCE (SIZE (1..maxNrofAltitudeRanges-r18)) OF SSB-ToMeasureAltitudeBased-r18

SSB-ToMeasureAltitudeBased-r18 ::=     SEQUENCE {
    altitudeRange-r18                      SEQUENCE {
        altitudeMin-r18                        Altitude-r18                                             OPTIONAL,  -- Need S
        altitudeMax-r18                        Altitude-r18                                             OPTIONAL,  -- Need S
        altitudeHyst-r18                       HysteresisAltitude-r18                                   OPTIONAL   -- Need R
    },
    ssb-ToMeasure-r18                      SSB-ToMeasure                                                OPTIONAL   -- Need S
}

• altitudeMin-r18 / altitudeMax-r18: the range, relative to sea level. Either end can be open.
• altitudeHyst-r18: hysteresis for entering and leaving a range, with the same 0 to 64 m type as the events.
• Filtering: when the UE moves into another altitude range, it is up to the UE whether to reset its layer 3 filtering (38.331 clause 5.5.3.2, NOTE 5).
• Idle and inactive: 38.300 says the same configuration can also be given in SIB2 and SIB4. In 38.331 v19.4.0 these SIB fields carry the suffix -r19 (ssb-ToMeasureAltitudeBasedList-r19), so for RRC_IDLE and RRC_INACTIVE this looks like a Release 19 addition that reuses the Release 18 type.

Flight path reporting

Height and current position describe where the drone is. A drone, unlike most ground UEs, usually also knows where it will be. A flight controller holds a planned route as a list of waypoints. If the network knew that route, it could prepare handovers, choose cells along the path, and avoid surprises. Release 18 therefore lets the gNB request the planned flight path from the UE.

The procedure has two steps, as Figure 2 shows. First, the UE indicates that it has flight path information with a one-bit flag, flightPathInfoAvailable-r18. Then the gNB asks for it in UEInformationRequest, and the UE sends it in UEInformationResponse. The gNB can also skip the first step and ask directly. This is the same request and response pattern used for RLF reports and logged MDT, described in the MDT page.

Figure 2. Flight path reporting. The availability flag is one bit and can ride on several messages, while the waypoint list itself is sent only when the gNB asks.

The availability flag can be carried in RRCSetupComplete, RRCResumeComplete, RRCReestablishmentComplete and RRCReconfigurationComplete, all in their v1800 extensions. In RRC_CONNECTED, it can also be sent in UEAssistanceInformation when the network has enabled this with aerial-FlightPathAvailabilityConfig-r18 in OtherConfig. The UE Assistance Information page covers that message in general.

When does the UE set the flag again after a report ? 38.331 lists the cases. The UE sets it if it has not sent a flight path since entering RRC_CONNECTED, if a new waypoint or timestamp has appeared, or if an upcoming waypoint has been removed. It also sets it if a waypoint has moved further than flightPathUpdateDistanceThr, or its timestamp has shifted more than flightPathUpdateTimeThr. These two thresholds are in Aerial-Config-r18. Without them, it is up to the UE when a change is worth reporting.

Following is based on 38.331 v19.4.0 (Release 19)

Aerial-Config-r18 ::= SEQUENCE {
    flightPathUpdateThrConfig-r18     SEQUENCE {
        flightPathUpdateDistanceThr-r18   SetupRelease { FlightPathUpdateDistanceThr-r18 }        OPTIONAL, -- Need M
        flightPathUpdateTimeThr-r18       SetupRelease { FlightPathUpdateTimeThr-r18 }            OPTIONAL  -- Need M
    }                                                                                             OPTIONAL, -- Need M
    ...
}

FlightPathUpdateDistanceThr-r18 ::=   INTEGER (0..1023)

FlightPathUpdateTimeThr-r18 ::=       INTEGER (0..16383)

FlightPathInfoReportConfig-r18 ::= SEQUENCE {
    maxWayPointNumber-r18              INTEGER (1..maxWayPoint-r18),
    includeTimeStamp-r18               ENUMERATED {true}                        OPTIONAL  -- Need N
}

FlightPathInfoReport-r18 ::=         SEQUENCE (SIZE (0..maxWayPoint-r18)) OF WayPoint-r18

WayPoint-r18 ::=                     SEQUENCE {
    wayPointLocation-r18                 OCTET STRING,
    timeStamp-r18                        AbsoluteTimeInfo-r16                OPTIONAL
}

• flightPathUpdateDistanceThr-r18: the actual value is 5 times the field value in meters, so 0 to 5115 m. The distance is the 3D distance between the old and the new location of the same waypoint.
• flightPathUpdateTimeThr-r18: in seconds, 0 to 16383 s.
• maxWayPointNumber-r18: how many waypoints the gNB wants, up to maxWayPoint-r18 = 20.
• wayPointLocation-r18: an OCTET STRING containing LocationCoordinates from TS 37.355, the LPP coordinate format, which includes altitude.
• timeStamp-r18: the estimated time of arrival at the waypoint, if the UE has it and includeTimeStamp-r18 was requested.
• Empty report: the list size starts at 0, so the UE can answer a request with an empty path.

How does the gNB use the waypoints ? 38.300 leaves that open. An obvious use is to pick handover targets along the path or to prepare conditional handover. Another is to forward the path at handover, so the target knows the plan without asking again. The CHO procedure itself is in the CHO page.

Location, BRID/DAA and Release 19 additions

Height events and flight paths are the core of Release 18 aerial support. A few more features complete the picture, and some of them only arrived in Release 19. They are listed here briefly, with the release taken from the field suffixes in 38.331 v19.4.0 where a suffix exists.

• Location with velocity: an aerial UE can include location information in RRM reports and in height-based reports. 38.300 says this can include horizontal and vertical speed. In 38.331, the measurement report carries this in commonLocationInfo with velocityEstimate-r16, an LPP Velocity field, when includeCommonLocationInfo is configured. The container itself is from Release 16.
• BRID and DAA over sidelink: BRID (Broadcast Remote Identification) and DAA (Detect And Avoid) messages are sent over NR sidelink (PC5), as A2X communication. BRID is broadcast, while DAA can be unicast or broadcast. They work in and out of coverage with autonomous resource selection, and the gNB can configure dedicated resource pools. The capability is sl-A2X-Service-r18 with values brid, daa and bridAndDAA.
• Altitude-based CHO: conditional handover events condEventA3H1, condEventA3H2, condEventA5H1 and condEventA5H2 combine an RSRP/RSRQ/SINR condition with an altitude condition. In 38.331 they carry the suffix -r19, so this is Release 19.
• UAV prioritized frequency: SIB2 and SIB4 can mark a frequency as prioritized for UAVs, optionally only within an altitude range (uav-PrioritizedFrequency-r19, uav-PrioritizedFrequencyAltitudeRange-r19). An aerial UE may then treat that frequency as higher priority in cell reselection. This is also Release 19.
• Flight information reporting to the core: the core network can ask the gNB to report the aerial UE's flight information. The trigger is the UE crossing altitude thresholds in given areas (38.300 clause 16.18.11, based on TS 23.256 clause 5.16). This is NGAP, not RRC. The clause does not state its release, and this page does not verify it.

Taken together, the Release 18 set is mostly about information flowing to the network: who is aerial, how high it is, how many cells it sees, and where it will go. Release 19 then begins to use that information in the UE's own decisions, through altitude-based CHO and UAV prioritized frequencies. The release overview is in the Release 18 page.

• Where to look in a log: ReportConfigNR with eventH1-r18 or eventAxHy for height reporting; MeasResults with altitudeUE-r18; UEInformationRequest with flightPathInfoReq-r18 and the matching UEInformationResponse for the flight path.
• No new physical layer: none of the Release 18 aerial features changes the physical layer. They are RRC, NGAP and XnAP features, plus sidelink resource configuration for BRID and DAA.

Deployment options - does an operator need dedicated TRPs ?

Everything above is signalling. It gives the network information about aerial UEs, but it does not change the antennas. So a practical question remains. A terrestrial TRP is tilted towards the ground, and a drone flies above its main lobe. Should an operator install TRPs dedicated to aerial UEs ? The specifications do not require it. It is a deployment choice, and the answer depends mostly on how many drones there are and how high they fly.

The existing network works up to a point. A drone at 50 m to 150 m is served by side lobes, which are weak, but the line-of-sight path loss is also low, so RSRP is usually sufficient. The limiting factor is interference: poor downlink SINR because many cells are equally strong, and uplink interference into many cells. 3GPP studied this for LTE in TR 36.777. My recollection of its conclusion is that an existing network can serve aerial UEs when interference mitigation is added, but I have not re-checked the report for this page.

The table below lists the options, from the cheapest to the most dedicated.

Release 19 gives a hint about the direction 3GPP expects. The field uav-PrioritizedFrequency-r19 is in SIB2 and SIB4, with an optional altitude range. It lets a cell tell aerial UEs to prefer one frequency in cell reselection. That only makes sense if a drone-oriented frequency layer exists. I believe some operators and vendors have trialled up-tilted cells, but I cannot point to specific deployments.

• No dedicated TRP is required by the standard: all Release 18 aerial features run on a normal terrestrial network.
• Interference, not coverage, is the main limit: side-lobe coverage is usually enough, while SINR and uplink interference degrade with height.
• Massive MIMO is the middle ground: vertical beamforming serves a drone with a main-lobe beam from an existing site.
• Dedicated layers pay off with density: for corridors and heavy, predictable drone traffic, up-tilted sectors on a separate carrier give clean SINR and keep drone uplink interference off the ground layer. The Release 19 UAV prioritized frequency supports steering drones onto such a layer.

Reference

• 3GPP TS 38.300 V19.4.0 : NR; NR and NG-RAN Overall description; Stage-2. Clause 16.18, Support for Aerial UE Communication
• 3GPP TS 38.331 V19.4.0 : NR; Radio Resource Control (RRC) protocol specification. Clauses 5.5.4.21 to 5.5.4.28, 5.7.4 and 5.7.10, ReportConfigNR, Aerial-Config, UEInformationRequest, UEInformationResponse, AerialParameters
• 3GPP TS 23.256 : Support of Uncrewed Aerial Systems (UAS) connectivity, identification and tracking; Stage 2
• 3GPP TR 36.777 : Enhanced LTE support for aerial vehicles
• 3GPP TS 37.355 : LTE Positioning Protocol (LPP). LocationCoordinates and Velocity
• UAV Communication, Measurement Report, MDT, UE Assistance Information, CHO, Release 18 (ShareTechnote)