Architecture begins with responsibilities
An AI-native RAN proposal should show where observations originate, where models run and which component has authority to change network behavior. Drawing an AI block beside a base station does not answer those questions. Start with a concrete function, such as a resource recommendation, then trace its inputs and outputs through the proposed system. Record which parts are supported in the selected implementation and which are research assumptions. The architecture should remain understandable without relying on the phrase AI-native as an explanation.
Separate training from operational decisions
Training produces or updates a model using a defined dataset and objective. Operational inference applies a model to new inputs. Those activities can have different computing, timing and governance requirements. A training environment may tolerate long processing jobs that would be inappropriate in a time-sensitive radio path. Specify how an approved artifact moves from development to deployment and how compatibility is checked. Automatically copying the latest model into a running network is not a substitute for release control.
Place inference against a measured timing budget
Execution location should follow the decision deadline and data dependencies. Include measurement collection, transport, queueing, inference and action application in the budget. A fast model can still produce an obsolete recommendation when its inputs arrive late. Conversely, moving every function into a radio site can increase operational complexity without improving the intended service. Measure the complete path and identify the component responsible for rejecting a result that has exceeded its valid time window.
Define interfaces and authority explicitly
A model output may be a score, prediction or suggested action. Those forms should not be treated as interchangeable. An independent policy layer can check whether an action is permitted, within resource limits and compatible with existing commitments. Document schema versions, units and unsupported states at each interface. An architectural diagram should also identify identity and authorization boundaries so that a component allowed to observe the network cannot automatically modify every service it can inspect.
Design for missing intelligence
A production architecture needs a usable response when inference is unavailable, inputs are invalid or a model behaves unexpectedly. The fallback may be a supported conventional algorithm, a restricted operating mode or a controlled escalation. Specify the transition rather than saying that operators will intervene. Check whether fallback restores the actual service behavior, not merely an earlier configuration file. Preserve enough telemetry to investigate the failure without collecting unnecessary sensitive data.
Review evolution without assuming a final standard
Future 6G planning should distinguish architectural flexibility from speculative feature commitments. ITU's IMT-2030 framework identifies AI and communication as an area of development, but it does not certify a particular deployment design. Use modular interfaces where they solve a real integration problem and maintain a tested compatibility matrix. Before expanding, review the selected workload, timing evidence, model ownership and recovery procedure together. An architecture is ready for a limited next stage when those responsibilities can be demonstrated, not simply when every diagram contains an AI component.
Questions for the project review
An architecture review can use a single transaction as a walkthrough. Follow its observation timestamp, model invocation, policy check and applied result, then repeat the walkthrough with a missing dependency. Record every responsibility that changes between the successful and failed path. If no team owns a transition, the design has an operational gap even when the components individually meet their technical specifications. Resolve that gap before expanding authority.
Further reading and scope
- O-RAN ALLIANCE WG2: AI/ML workflow and non-real-time control
- ITU: IMT-2030 framework and usage scenarios
These references support the background concepts and terminology. The review questions and proposed evaluations are original educational analysis, not benchmark results or requirements attributed to these sources. Research reports and future-facing frameworks do not certify a commercial implementation. Check the documentation for the actual supported release and deployment environment.
Educational analysis only. Not an implementation certification, security guarantee or personalized legal or financial advice. Examples are hypothetical; no performance gain, investment return or future 6G capability is promised. Site and safety-sensitive work requires qualified system-specific review.



