For years, the radio access network has been guessing. Every scheduling decision, every beam selection, every channel estimate has been built on the network's best inference of how a device actually experiences the radio environment. With 3GPP Release 19, that dynamic begins to change in a formal, standardized way — and the evidence is sitting right there in the UE capability signaling.

The introduction of AIML-Parameters-r19 is, on its surface, just another capability container. In practice, it represents a turning point: the device itself can now run trained models to support functions like beam management, CSI feedback, and positioning, and — critically — it can tell the network exactly what it's capable of.

Where it lives in the specification:

The ASN.1 follows the familiar 3GPP non-critical extension chain. Release 18's capability structure hands off to a new Release 19 container, and that's where the AI/ML parameters make their debut:

asn1

UE-NR-Capability-v1860 ::= SEQUENCE {
    ntn-CHO-OnlyLocationTimeTrigger-r18    ENUMERATED { supported } OPTIONAL,
    nonCriticalExtension                   UE-NR-Capability-v1900 OPTIONAL
}

UE-NR-Capability-v1900 ::= SEQUENCE {
    aiml-Parameters-r19                        AIML-Parameters-r19 OPTIONAL,
    ue-RadioPagingInfo-r19                     OCTET STRING (CONTAINING UE-RadioPagingInfo-r19) OPTIONAL,
    ntn-VSAT-AntennaTypeKuBand-r19             ENUMERATED { electronic, mechanical } OPTIONAL,
    ntn-VSAT-MobilityTypeKuBand-r19            ENUMERATED { fixed, mobile } OPTIONAL,
    ntn-ERedCap-FR1-r19                        ENUMERATED { supported } OPTIONAL,
    onDemandSIB1-r19                           ENUMERATED { supported } OPTIONAL,
    onDemandPosSIB-ConnectedCtrlParam-r19      ENUMERATED { supported } OPTIONAL,
    ntn-Redirection-r19                        ENUMERATED { supported } OPTIONAL,
    drx-PreferenceCellDTX-DRX-r19              ENUMERATED { supported } OPTIONAL,
    lpwus-SupportedBandsIdleInactiveOFDM-r19   SEQUENCE (SIZE (1..maxBands)) OF FreqBandIndicatorNR OPTIONAL,
    lpwus-SupportedBandsIdleInactiveOOK-r19    SEQUENCE (SIZE (1..maxBands)) OF FreqBandIndicatorNR OPTIONAL,
    nonCriticalExtension                       UE-NR-Capability-v1920 OPTIONAL
}

AIML-Parameters-r19 ::= SEQUENCE {
    applicabilityReportingCSI-r19              ENUMERATED { supported } OPTIONAL,
    applicabilityReportingOther-r19            ENUMERATED { supported } OPTIONAL,
    loggedDataCollection-r19                   ENUMERATED { supported } OPTIONAL,
    eventBasedLoggedDataCollection-r19         ENUMERATED { supported } OPTIONAL,
    dataThresholdAvailabilityIndication-r19    ENUMERATED { supported } OPTIONAL
}

By anchoring these fields under UE-NR-Capability-v1900, 3GPP is sending an unambiguous message: Release 19 is the formal starting point for standardized AI/ML capability signaling. This isn't a vendor experiment or a proprietary extension — it's part of the specification itself.

Why a capability framework matters more than the models

It's tempting to focus on the models — the neural networks predicting beams or compressing channel state feedback. But the harder engineering problem has always been trust and control. AI in a mobile network cannot operate as an uncontrolled black box. Before the network can rely on a device's intelligence, it needs answers to three questions: Can this UE do AI-related processing at all? Is the model it's running still valid in the current radio environment? And can this device contribute useful data toward improving the next generation of models?

The AIML-Parameters-r19 structure answers all three. Walking through the fields makes the design philosophy clear.

Knowing when the model can be trusted. The applicabilityReportingCSI-r19 field indicates whether the UE can report the applicability of its AI model specifically for Channel State Information — in other words, whether the device can tell the network "my CSI model is reliable here" or "conditions have drifted; don't lean on my predictions." Its sibling, applicabilityReportingOther-r19, extends the same idea to other use cases such as beam management and positioning. A model trained in one deployment scenario may degrade in another, and these fields give the network the visibility it needs to manage that risk rather than discover it the hard way.

Turning devices into data sources. The loggedDataCollection-r19 field confirms that the UE can collect and store radio signal measurements for use as training data. Its event-based counterpart, eventBasedLoggedDataCollection-r19, is the smarter variant: rather than logging continuously, the device can trigger collection only when something interesting happens — a handover failure, a sudden signal drop. The most valuable training data often comes from exactly these edge cases, and event-based logging captures them without burning battery and memory on routine measurements.

Knowing when there's enough. Finally, dataThresholdAvailabilityIndication-r19 lets the UE proactively inform the network that it has accumulated enough data to be useful for model training or updates. Instead of the network polling devices blindly, devices raise their hand when they have something worth fetching.

The bigger picture:

Taken together, these five optional fields do something subtle but important: they make AI/ML a controlled, predictable component of radio resource management. The network can discover capability, monitor model validity, and orchestrate a data lifecycle — all through standard RRC signaling, all interoperable across vendors.

That's the real story of Release 19. The transition to an AI-native air interface won't arrive as a single dramatic feature. It arrives like this: one capability container at a time, with the groundwork for trust laid before the intelligence is switched on. The devices in your pocket are about to become active participants in how the network learns — and now there's a standardized language for the conversation.