Toward AI-Native 6G Air Interface: A 3GPP Perspective on Protocol Framework

1

Toward AI-Native 6G Air Interface: A 3GPP Perspective on Protocol Framework Xingqin Lin

Abstract—Artificial intelligence (AI) is expected to play an important role in the sixth-generation (6G) air interface design, but making the air interface truly AI-native requires more than applying learning algorithms to individual radio functions. The deeper challenge is architectural: once AI influences how the user equipment and network interpret, predict, and adapt radio behavior, the air interface must provide common protocol semantics for coordinating such intelligence across vendors and deployments. This article presents a 3rd generation partnership project (3GPP) oriented perspective on the protocol framework for AI-native 6G air interface. We argue that standardization should preserve implementation freedom by avoiding prescription of model architectures, training methods, or model weights. Instead, 6G should define the protocol framework needed for interoperable AI operation, including how AI-enabled functions are configured, validated, activated, monitored, and safely reverted to conventional operation. Neural receiver assisted reference signal adaptation is used as a case study to concretely show this broader architectural shift.

I. INTRODUCTION Cellular air interface standardization has traditionally been built on a careful balance between interoperability and implementation freedom [1]. The standard defines the externally visible behavior that allows a user equipment (UE) and a network from different vendors to communicate reliably, while leaving substantial room for proprietary innovation inside the receiver, scheduler, and radio resource management algorithms. This separation has been one of the foundations of cellular success: the protocol specifications are common, but the implementation choices behind the specifications remain competitive. Artificial intelligence (AI) does not necessarily disturb this balance [2]. If AI is used only to improve an internal algorithm, the existing model of standardization remains largely intact. A UE may use a neural network to improve receiver processing, or a base station may use reinforcement learning to improve scheduling decisions, without requiring the peer to know how the algorithm works. In such cases, AI is an implementation technique. The air interface remains unchanged, and interoperability is preserved through the same standardized signals, reports, and procedures. The challenge becomes more fundamental when AI begins to influence behavior that must be coordinated across the air interface. Future sixth-generation (6G) systems are expected to use learning-based methods not only to improve local processing, but also to interpret radio observations, predict future channel states, and enable more proactive radio control [3]. Once such AI outputs affect how the UE and base station configure, interpret, or adapt radio behavior, the protocol must provide more than conventional resource allocations and

measurement reports. It must provide common semantics for what the AI-enabled function is doing, when its output is valid, how reliable it is, and how the system should respond when that reliability degrades. This distinction is central to the meaning of an AI-native air interface. An AI-native air interface includes protocol support for learnable and adaptive radio functions [4][5]. The goal is not to standardize neural network architectures, training datasets, optimization methods, or model weights. Doing so would constrain innovation and would be poorly matched to the rapid evolution of AI techniques and deployment-specific model design. Instead, the standardization challenge is to define the air interface around AI-enabled behavior so that different implementations can interoperate safely. A 3rd generation partnership project (3GPP) oriented approach to AI-native 6G should therefore focus on protocol semantics rather than model internals [6]. This evolution is expected to build on 5G-Advanced AI studies and early 6G study directions in 3GPP [7]. The UE and base station need mechanisms to describe AI-related capabilities, configure AIenabled tasks, activate and suspend them at appropriate timescales, monitor their validity, report confidence or degradation, and fall back to conventional operation when needed. These mechanisms should be integrated into the existing protocol structure rather than introduced as a separate AI layer. Radio resource control (RRC) layer can provide semistatic configuration and capability exchange, medium access control (MAC) layer can manage activation and fallback, physical layer can provide the necessary measurement resources, and management functions can support lifecycle control. This article develops a protocol framework for AI-native 6G air interface from a 3GPP perspective. The focus is on the standardization objects and procedures needed to make AIenabled radio functions interoperable, observable, and robust. We first discuss how AI-native operation changes the air interface design, then introduce protocol-visible objects such as AI task profiles, capability descriptors, representation semantics, validity regions, confidence reporting, and fallback profiles. We then map these objects onto a layered protocol architecture and describe a generic procedure flow for configuration, validation, activation, monitoring, and recovery. Finally, we use neural receiver assisted reference signal adaptation as a concrete example of how AI can enable deeper physical layer innovation while still preserving the standardization principles that have made cellular systems reliable and multi-vendor interoperable. Figure 1 provides an illustration of the protocol framework for AI-native 6G air interface that will be discussed in detail in the rest of this article.

2

Figure 1: An illustration of the protocol framework for AI-native 6G air interface.

II. PROTOCOL IMPLICATIONS OF AI-NATIVE AIR INTERFACE OPERATION The air interface specifications define how radio resources are configured, how transmitted signals are interpreted, how measurements are reported, and how the system recovers when radio conditions change. In existing cellular systems, the specifications are largely deterministic from a protocol perspective. Even when the UE and base station use sophisticated proprietary algorithms internally, the meaning of the exchanged information is standardized and stable. AI-native operation changes this because the behavior of a radio function may depend on learned representations, prediction models, deployment context, inference timing, and operating conditions [8]. For example, a conventional channel state information (CSI) report has a standardized interpretation regardless of how the UE computes it. By contrast, an AI-assisted CSI output may represent a compressed channel description, a predicted future channel state, or an uncertainty-aware estimate [9]. These outputs can be useful only if the base station understands their intended meaning and the conditions under which they remain valid. The protocol implication is that AI-enabled reports and control decisions require explicit semantics beyond the traditional definition of measurement quantities and resource configurations. This issue is not limited to CSI. Beam management, reference signal adaptation, and predictive mobility control all raise a similar question: when an AI output affects a decision at the peer node, what must be standardized so that the decision remains interoperable and reliable? The answer is not the internal AI model. The standard does not need to know whether a UE uses a convolutional network, transformer, or graph neural network. What the peer node needs to know is the task being

supported, the scope of the output, its timing, its reliability, and the fallback behavior if the AI-assisted mode becomes unreliable. A key implication is that task semantics become protocol visible. In a conventional design, a measurement report typically corresponds to a well-defined radio quantity. In an AI-native design, the same underlying observations may be used for different purposes. Without a task context, an AIgenerated feature has no interoperable meaning. Therefore, AInative operation requires the protocol to identify not only what is being reported, but also why it is being reported and how the receiving node is expected to use it. Another implication is that timing becomes part of the meaning of the AI output. Many AI-native functions are inherently predictive. A predicted channel is meaningful only with respect to a prediction horizon and a validity duration. Similarly, an AI receiver or AI-assisted feedback mechanism may be usable only if the inference can be completed within the required processing timeline. This creates a closer coupling between radio timing and AI processing capability. The protocol must therefore distinguish between information that describes the present, information that predicts the future, and information that has become stale. Validity and confidence are equally important. Unlike conventional protocol fields, whose meaning is fixed by specification, AI outputs may be reliable only within certain operating envelopes. These envelopes may depend on radio conditions, device capability, measurement availability, mobility, channel dynamics, or deployment context. If the system continues to rely on an AI function outside its valid region, performance may degrade abruptly. Confidence reporting provides a way to make this degradation visible before it results in repeated radio link failures or unstable control decisions. The protocol does not need to expose the AI model’s internal reasoning, but it should provide

3 a common way to indicate whether an AI output remains trustworthy enough for its intended use. AI-native operation also introduces lifecycle considerations [10]. A conventional radio feature is typically either supported, configured, activated, or released. AI-enabled functions may require additional states such as validation, monitoring, fallback, update, and recovery. A function profile may be available in principle but not yet validated for the current deployment condition. It may need to be rolled back after an update or reactivated only after sufficient monitoring confirms stable behavior. These lifecycle states become protocol relevant whenever they influence air interface behavior. The most important implication is the need for safe fallback. AI-native operation should not replace the conventional anchor that makes cellular systems robust. Instead, AI-assisted modes should be introduced with explicit fallback mechanisms. For example, a predictive CSI mode should be able to fall back to conventional CSI reporting. Fallback should be part of the AI task profile from the beginning. III. STANDARDIZATION OBJECTS FOR AI-NATIVE AIR INTERFACE A practical AI-native air interface cannot be standardized by adding a generic “AI mode” to the radio protocol. Such an approach would be too coarse to support meaningful interoperability. AI may be used to assist various radio functions, and each of these functions may have different assumptions, timescales, reliability requirements, and fallback needs. At the same time, 3GPP should avoid standardizing the internal form of AI itself. Model architectures, training datasets, optimization methods, inference engines, and model weights should remain implementation specific because they evolve rapidly and are central to vendor differentiation. The appropriate standardization target lies between these two extremes [11]. 6G should define the protocol-visible objects that describe how AI-enabled radio functions are exposed, configured, interpreted, monitored, and safely controlled. These objects play a role similar to existing radio objects, e.g., a CSI report configuration does not specify how a UE estimates the channel, but it specifies what report is expected, when it is provided, and how the base station should interpret it. Similarly, an AI-native task profile should not specify how a model is trained, but it should define the semantics of the AI-enabled function and the conditions under which its output can be used. Figure 2 provides an illustration of the standardization objects for AI-native 6G air interface discussed in this section. The central object in such a framework is the AI task profile. The task profile identifies the radio function that is being assisted by AI and gives that function a protocol meaning. This distinction is important because an AI output is not selfdescribing. A learned representation, a predicted channel state, or a confidence value has meaning only in relation to the task it supports. Without task context, the receiving node cannot know how to interpret the feature. The AI task profile, therefore, provides the semantic anchor for the rest of the configuration. Around this task profile, the protocol needs a capability description. Capability signaling is especially important for AInative operation because support for an AI task is rarely universal. For example, a UE may support an AI-enhanced

Figure 2: An illustration of the standardization objects for AInative 6G air interface.

receiver only for certain bandwidths, ranks, mobility ranges, or processing timelines. The capability description should express the conditions under which the AI-enabled function can be configured and the types of reports, confidence indications, or fallback procedures that the device can support. This allows the network to configure AI-native operation only when the UE and base station have compatible assumptions. Once a task is supported, the protocol also needs a way to identify the specific behavior being configured. This can be captured by an AI profile identifier. The profile identifier should be understood as a reference to a protocol-visible operating mode, not as a reference to a particular neural network. For example, within a CSI prediction task, different profiles may correspond to different prediction horizons, input measurement resources, or output representations. The value of such an identifier is that it gives both the UE and the base station a compact and unambiguous way to refer to a configured behavior. Vendors remain free to implement the underlying function using different AI models, but the externally visible behavior associated with the profile is common. In this way, the profile identifier enables interoperability at the protocol level without imposing implementation uniformity. The next part concerns the information entering and leaving the AI-enabled function. An AI-native profile should describe the relevant input sources at the level needed for interoperability. These inputs may be associated with reference signals, measurement resources, or decoding outcomes. In many cases, the raw inputs should remain local to the UE or base station, both to limit overhead and to preserve implementation freedom. However, when an AI function depends on shared observations or reported features, the protocol must specify which resources or measurements are associated with the task. The output side is equally important. Conventional air interface reports are usually directly interpretable because their formats and meanings are standardized. AI-native outputs may be more abstract. They may represent a predicted channel condition, a compressed channel representation, a validity indication, or a confidence

4 measure. The standard, therefore, needs representation semantics: what the output means, how it is quantized, what time or resource it refers to, and how the receiving node is expected to use it. This does not require a universal representation for all AI tasks. Instead, each task profile can define the output semantics needed for that function. Timing is another essential object because many AI-native functions are predictive or processing-constrained. The protocol should distinguish between present state inference, future state prediction, and stale information that should no longer be used. AI-native operation also requires an explicit description of validity. Unlike conventional protocol fields, whose interpretation is fixed by specification, an AI output may be reliable only within a certain operating envelope. The standard should provide a protocol-level way to express the conditions under which the AI profile is intended to operate. Validity can be configured semi-statically, indicated dynamically, or inferred through monitoring procedures. Because validity is not always binary, confidence becomes part of the AI-native operation. Confidence should have task-dependent operational meaning. A high-confidence prediction may allow the base station to rely more strongly on the AI output, while a lowconfidence indication may trigger verification, conservative operation, or fallback. The standard does not need to prescribe how confidence is computed, but it should define how confidence is represented and how it is associated with the corresponding AI output. Finally, every AI-native profile that can affect air interface behavior should include monitoring and fallback semantics. Monitoring determines whether the profile remains suitable for use after activation. Fallback defines the conservative behavior when the AI-enabled mode becomes unreliable or invalid. This is particularly important for link-critical functions such as reference signal adaptation. A reduced reference signal mode, for instance, should always be associated with a baseline reference signal configuration to which the system can return. Fallback is the mechanism that allows AI-native operation to be introduced safely. IV. PROTOCOL AND PROCEDURE FOR AI-NATIVE 6G AIR INTERFACE A. Layered Protocol Architecture Cellular systems already have a mature layering structure that separates long-term configuration, medium-timescale control, fast physical layer operation, and network management. A practical AI-native design should build on this structure rather than bypass it. The purpose of the protocol architecture is therefore to determine where AI-related semantics should reside within the existing RRC, MAC, physical layer, and management framework. This layered view is important because AI-native functions operate across different timescales. Some aspects evolve slowly, such as UE capability, supported AI task profiles, model availability, and operator policy. Other aspects change at medium timescales, such as whether an AI profile is active, suspended, under validation, or in fallback. Still others must be handled close to the physical layer, e.g., measurement reporting may occur within a few slots. A clean architecture should place each AIrelated function at the layer whose timing and reliability

properties match the function being controlled, as illustrated in Figure 1. RRC is the natural layer for defining the semantic framework of AI-native operation. RRC should configure the AI task profile, the radio scope to which it applies, the input and output representations, the associated measurement resources, the expected timing behavior, the validity assumptions, the confidence reporting format, and the fallback profile. In other words, RRC should establish what an AI-enabled function means before lower layers are allowed to use it dynamically. RRC is also the right place for capability discovery. AI capability cannot be represented by a single feature bit because AI support is often conditional. The role of RRC capability signaling is to expose these constraints in a structured way so that the network can configure AI-native operation only when the UE and base station share compatible assumptions. This preserves the multi-vendor nature of cellular systems: each vendor can implement the AI function differently, but the protocol-visible capability and configuration semantics remain common. Although RRC defines the semantic envelope, it is too slow for frequent adaptation. AI-native functions may need to be activated, suspended, resumed, or switched as radio conditions change. This is the role of MAC. MAC should manage the operational state of already configured AI profiles. For example, an AI-assisted CSI profile may be configured by RRC but activated only when the channel has been sufficiently observed and the UE reports adequate confidence. MAC can support such transitions without requiring full RRC reconfiguration, allowing AI-native operation to adapt at a timescale that is practical for radio control. The MAC layer is also well suited to fallback management. When an AI-enabled mode becomes unreliable, the system should be able to return to a conservative operating mode that is already configured and understood by both sides. MAC can coordinate this transition by activating a fallback profile, suspending the AI-assisted profile, or switching to a less aggressive configuration. The physical layer is where AI-native operation becomes directly tied to signals, measurements, and scheduling-time decisions. AI-enabled functions ultimately rely on physical observations and often influence physical layer behavior. The physical layer should therefore provide the reference signal, measurement, and resource associations needed by the AI task profiles configured at higher layers. While RRC may configure several AI-aware reference signal profiles and MAC may activate the subset currently allowed, downlink control information (DCI) may select which profile applies to a particular transmission or reporting occasion. Similarly, uplink control information (UCI) may carry compact indications such as validity flag or fallback request. In short, dynamic L1 signaling should carry only what is needed for immediate radio operation: profile selection, triggering, compact reporting, and urgent reliability indications. Beyond the radio protocol layers, AI-native operation requires lifecycle management from operations, administration, and maintenance (OAM) functions [12][13]. AI profiles may need to be provisioned, validated, monitored, updated, rolled back, or retired. These actions may depend on operator policy, deployment environment, or device class. The detailed management of AI models does not need to be part of the air

5

Figure 3: An illustration of procedure flow for AI-native 6G air interface.

interface specification, but its radio-visible consequences must be reflected in the protocol. For example, a profile may become unavailable after a failed update, require revalidation after rollback, or be restricted to certain deployment conditions. The UE and base station should have a common understanding of such lifecycle states when they affect radio behavior. B. AI-Native Procedure Flow A layered architecture becomes useful only when it supports clear procedures. For AI-native operation, the procedure should be understood as a closed-loop process in which an AI-enabled function is discovered, configured, prepared, activated, monitored, and safely recovered or released as conditions evolve, as illustrated in Figure 3. The procedure begins with capability discovery. A UE may support an AI-assisted function only under certain operating conditions. The purpose of capability discovery is therefore to establish whether the UE and base station share a compatible basis for AI-native operation. This does not require either side to reveal its model implementation. It requires only that both sides can identify the supported task, the applicable radio scope, the timing constraints, and the available fallback behavior. After capabilities are known, the network can configure one or more AI task profiles. The configuration defines what the AIenabled function is intended to do, which radio resources or observations it is associated with, how its output is represented, when the output is expected to be valid, and what conservative mode should be used if the AI-assisted mode is no longer appropriate. Importantly, configuration does not necessarily mean immediate use. A profile may be configured so that the UE and base station have a common understanding of it, while the actual activation is delayed until the operating conditions are suitable. Many AI-native functions require preparation before activation. In particular, an AI-enabled function may depend on recent measurements, historical observations, or environmental context. The protocol should support the idea that a configured AI function may first operate in an observation state before it is allowed to affect scheduling or transmission behavior. Validation provides the bridge between preparation and activation. The goal of validation is to determine whether the configured AI profile appears reliable under the current operating condition. Validation may be performed locally by the UE, locally by the base station, or jointly through observed radio outcomes. In some cases, the AI output can be generated in the background without being used for control decisions,

allowing the network to build confidence before activation. Activation is the point at which the AI-native profile begins to influence radio behavior. This transition should be explicit because it changes the operation between the UE and base station. Once activated, an AI-assisted output may affect beam selection, CSI interpretation, mobility preparation, or other radio control decisions. During active operation, the procedure should remain lightweight. The richer semantics should already have been configured at higher layers, so fast control can remain compact. Scheduling-time signaling can select among configured profiles or trigger reports, while uplink control can convey concise information such as validity indication or fallback request. Monitoring is the mechanism that keeps the active AI profile under control. Radio conditions may change quickly, and model reliability can degrade before conventional failure metrics become severe. Monitoring should therefore combine ordinary radio metrics with AI-specific reliability indications. Hybrid automatic repeat request (HARQ) feedback and CSI reports remain important, but they may be complemented by confidence, validity, or degradation indicators associated with the AI profile. When monitoring indicates that reliability has degraded, the procedure should support adaptation before hard failure occurs. Adaptation may be conservative and incremental, e.g., a predictive CSI profile may use a shorter horizon. Adaptation allows the system to preserve some AI benefit while reducing risk. If the degradation is more severe, the procedure should move to fallback. Fallback is the mechanism that makes AI-native features deployable in a robust cellular system. An AI-assisted mode that changes air interface behavior should be associated with a conventional or more conservative profile that both UE and base station can use reliably. Fallback may be triggered by the UE, by the base station, or by jointly observed behavior. What matters is that the transition is deterministic enough for both sides to know when the fallback mode applies. After fallback, recovery of the AI-assisted profile may require renewed validation, stable confidence over a configured duration, or successful verification measurements. This prevents oscillation between AI-assisted and fallback modes, especially in rapidly changing environments. V. CASE STUDY: NEURAL RECEIVER ASSISTED REFERENCE SIGNAL ADAPTATION Neural receivers provide a useful case study for illustrating the protocol framework developed in the previous sections

6

Figure 4: An illustration of different levels of neural receiver assisted reference signal adaptation.

because they sit at the boundary between implementation freedom and air interface coordination. If a UE uses a neural network only to improve channel estimation, equalization, or demapping while receiving the same reference signals and following the same control procedures as a conventional UE, then the neural receiver remains an implementation detail [14]. The base station does not need to know how the receiver is designed, trained, or executed. Interoperability is preserved because the standardized air interface behavior is unchanged. The standardization question becomes more interesting when the receiver capability begins to affect what the base station transmits. A neural receiver may be able to exploit timefrequency correlation, spatial structure, channel history, or learned impairment characteristics more effectively than a conventional receiver. This may allow the system to reduce demodulation reference signal (DMRS) overhead, adapt pilot placement, or use more aggressive reference signal designs under suitable conditions. At that point, the receiver is no longer only a proprietary implementation behind a fixed interface. The base station must know that the UE can support a particular reference signal configuration, when that support is valid, how reliable the UE considers the receiver operation, and how the system should fall back if the receiver becomes unreliable. A useful way to understand the standards impact is to view neural receiver assisted DMRS operation as a continuum, as illustrated in Figure 4. At one end is the baseline orthogonal DMRS design, where pilot resource elements are dedicated to the reference signal and the receiver follows conventional assumptions. In this regime, a neural receiver can still provide implementation gain, but the standards impact is minimal because the transmitted signal and the protocol interpretation of DMRS remain unchanged. This mode is essential because it provides the conservative anchor for interoperability and

fallback. Even if more advanced AI-assisted modes are introduced, the baseline DMRS profile gives the UE and base station a robust configuration to return to when the AI-assisted mode becomes invalid or insufficiently reliable. A moderate step beyond the baseline is sparse orthogonal DMRS. Here, the pilot density is reduced, but pilots still occupy dedicated orthogonal resource elements. The neural receiver is expected to recover the channel from fewer observations by exploiting correlation over time, frequency, antennas, or recent channel history. This changes the standards problem in a manageable way. The air interface can still define a bounded set of DMRS profiles, and the base station can select a reduceddensity profile only when the UE has declared support for the corresponding operating envelope. The AI model remains proprietary, but the reduced-DMRS capability, validity assumptions, and fallback profile become protocol visible. Such a design is attractive for early 6G consideration because it preserves the familiar interpretation of DMRS while allowing AI to reduce overhead. Irregular or adaptive DMRS represents a deeper level of AInative operation. In this case, the pilot pattern is not simply a lower-density version of a fixed grid. Instead, pilot placement may adapt to channel conditions, mobility, receiver class, cellspecific environment, or other contextual information. A neural receiver may make such patterns viable by learning to interpolate from nonuniform observations and by exploiting structure that is difficult to capture with conventional interpolation. However, the standards impact also increases. The UE and base station must have a common understanding of the allowed pattern family, the profile identifier, the conditions under which the pattern is valid, and the mechanism by which the pattern is selected. The standard does not need to prescribe

7

Figure 5: Learned pilot-to-data power splits for superimposed DMRS in two-sided training.

how the neural receiver performs interpolation, but it does need to define the protocol semantics of the adaptive DMRS profile. A larger qualitative shift occurs with superimposed pilot transmission [15]. In conventional transmission, pilot and data symbols are separated in resource elements. In superimposed transmission, pilot and data components share the same timefrequency resources through a controlled embedding rule, for example, through a power split between pilot and data components. This design can potentially reduce explicit pilot overhead because pilot information is embedded together with data. However, it also changes the nature of the air interface. The receiver must jointly interpret the pilot and data components, while the transmitter must embed them according to a structure that the receiver has been trained to understand. This is why superimposed pilot transmission is a clear example of two-sided training. A one-sided neural receiver can be introduced without changing the transmitted waveform, but superimposed pilots require joint assumptions at both ends of the link. The transmitter-side embedding rule and receiver-side neural processing are coupled. If the base station changes the superposition rule without a compatible receiver assumption, the UE may no longer be able to disentangle pilot and data reliably. Conversely, a neural receiver trained for one superposition profile may not generalize to a different profile with a different mobility regime or channel condition. Therefore, the relevant standardization object is not the trained model, but the superposition profile and its protocol envelope. Figure 5 illustrates this point: the learned pilot-energy allocation varies with modulation order and mobility. Under low mobility, the model may concentrate pilot energy on a smaller set of resources because the receiver can exploit stronger temporal and frequency correlation. Under higher mobility, the allocation becomes more dispersed, reflecting the need to refresh channel information more frequently. Modulation order also matters. For 64QAM, where residual channel estimation error can have a stronger impact on detection, the learned allocation tends to preserve more pronounced pilot-bearing components than in lower-order modulation cases. From a protocol perspective, superimposed pilots therefore require richer support than sparse orthogonal DMRS. RRC may need to configure the superposition profile, including the pilot

embedding rule, permitted power-split range, validity assumptions, confidence reporting format, and fallback DMRS profile. MAC may activate or suspend the profile based on receiver readiness and radio conditions. Physical layer signaling may select among configured profiles or trigger compact validity reporting. During operation, the UE may report whether the current profile remains reliable, while the base station may respond by adjusting scheduling, reverting to orthogonal DMRS, or selecting a less aggressive profile. At the far end of the continuum lies pilot-free transmission, where pilot information is implicitly embedded in the data structure and the receiver relies on learned inference rather than explicit reference signal. This is the most ambitious point in the design space and also the most challenging from a standards perspective. It would require strong transmitter-receiver codesign, extensive validation, carefully defined conformance behavior, and robust fallback. For this reason, pilot-free transmission may be better viewed as a longer-term research direction than as an immediate 6G standardization target from day 1. It remains valuable, however, because it clarifies the direction of progress: as AI becomes more deeply integrated into the physical layer, receiver assumptions become increasingly protocol visible. The key lesson is that neural receivers should not be standardized as neural networks. They should be standardized, when needed, through the air interface assumptions they create. The neural model itself can remain proprietary, but the protocol-visible consequences of relying on that model must be common. This preserves the cellular principle of implementation freedom while enabling 6G to benefit from more adaptive, AI-assisted physical layer designs. VI. CONCLUSION AND FUTURE OUTLOOK AI-native 6G should not be understood simply as the use of AI models inside the UE or base station. Its deeper significance is architectural. Once AI influences how radio behavior is interpreted, predicted, or adapted across the air interface, the protocol must provide common semantics for coordinating such intelligence. This article has argued that the right standardization target is not the AI model itself, but the protocol envelope around AI-enabled radio functions: how they are described, configured, validated, activated, monitored, and

8 safely reverted to conventional operation. From a 3GPP perspective, this distinction is essential. Cellular systems have succeeded because they combine strict interoperability with implementation freedom. AI-native 6G should preserve this balance. Standards should avoid prescribing model architectures, training methods, or model weights; instead, future specifications should define the objects and procedures needed for AI-enabled functions to interoperate across vendors and network deployments. Looking forward, the path toward AI-native 6G is likely to be progressive rather than abrupt. Early standardization may focus on AI-aware capability signaling, reporting, validation, and fallback for selected use cases. As confidence grows, later releases may support tighter coordination among communication, AI, and sensing, enabling the air interface to become more predictive, context-aware, and self-adaptive. In the longer term, AI-native operation could transform the air interface from a fixed set of procedures into a flexible framework where learned functions are introduced, evaluated, updated, and retired through standardized lifecycle mechanisms. The long-term goal is not to standardize intelligence itself, but to standardize the protocol framework that allows intelligence to operate reliably and interoperably. REFERENCES [1]

E. Dahlman, S. Parkvall, and J. Skold, “5G NR: The next generation wireless access technology,” Academic Press, 2020. [2] X. Lin et al., “Embracing AI in 5G-Advanced Toward 6G: A Joint 3GPP and O-RAN Perspective,” IEEE Communications Standards Magazine, vol. 7, no. 4, pp. 76–83, Dec. 2023. [3] ITU-R, “Framework and overall objectives of the future development of IMT for 2030 and beyond,” Recommendation ITU-R M.2160, Nov. 2023. [4] J. Hoydis et al., “Toward a 6G AI-Native Air Interface,” IEEE Communications Magazine, vol. 59, no. 5, pp. 76–81, May 2021. [5] S. Shafaei et al., “Toward AI in 6G: Concepts, Techniques, and Standards,” IEEE Access, vol. 13, pp. 143843–143874, 2025. [6] 3GPP TR 38.843, “Study on Artificial Intelligence (AI)/Machine Learning (ML) for NR air interface,” V19.0.0, Sep. 2025. [7] X. Lin, “A Tale of Two Mobile Generations: 5G-Advanced and 6G in 3GPP Release 20,” IEEE Communications Standards Magazine, early access, Oct. 2025. [8] T. J. O’Shea and J. Hoydis, “An Introduction to Deep Learning for the Physical Layer,” IEEE Transactions on Cognitive Communications and Networking, vol. 3, no. 4, pp. 563–575, Dec. 2017. [9] C.-K. Wen, W.-T. Shih, and S. Jin, “Deep Learning for Massive MIMO CSI Feedback,” IEEE Wireless Communications Letters, vol. 7, no. 5, pp. 748–751, Oct. 2018. [10] A. Gupta et al., “AI for Air Interface Life-Cycle Management: End-toEnd Verification, Adaptation, and Procedures,” IEEE Wireless Communications, vol. 33, no. 1, pp. 13–15, Feb. 2026. [11] P. Zhang et al., “Way to Build Native AI-Driven 6G Air Interface: Principles, Roadmap, and Outlook,” IEEE Transactions on Network Science and Engineering, vol. 13, pp. 3551–3565, 2026. [12] 3GPP TR 28.908, “Study on Artificial Intelligence/Machine Learning (AI/ML) Management,” V19.0.0, Oct. 2025. [13] L. Kundu et al., “AI-RAN: Transforming RAN with AI-Driven Computing Infrastructure,” IEEE Communications Magazine, vol. 64, no. 1, Jan. 2026. [14] M. Honkala et al., “DeepRx: Fully Convolutional Deep Learning Receiver,” IEEE Transactions on Wireless Communications, vol. 20, no. 6, pp. 3925–3940, Jun. 2021. [15] F. Ait Aoudia et al., “End-to-End Learning for OFDM: From Neural Receivers to Pilotless Communication,” IEEE Transactions on Wireless Communications, vol. 21, no. 2, pp. 1049–1063, Feb. 2022.