SubEdge: A Subscriber-Centric Edge Computing Subsystem in 6G Networks for AI

Abdirazak Ali Asir Rage; Rahim Tafazolli; Riccardo Pozza

arxiv: 2606.30554 · v1 · pith:HL4HZVF3new · submitted 2026-06-29 · 💻 cs.NI · cs.DC

SubEdge: A Subscriber-Centric Edge Computing Subsystem in 6G Networks for AI

Abdirazak Ali Asir Rage , Riccardo Pozza , Rahim Tafazolli This is my paper

Pith reviewed 2026-06-30 03:06 UTC · model grok-4.3

classification 💻 cs.NI cs.DC

keywords subscriber-centric edge computing6G networksAI inferencemobility managementper-subscriber provisioningjoint migrationNEF APIsedge computing subsystem

0 comments

The pith

SubEdge enables per-subscriber AI edge compute in 6G by jointly migrating compute and routing on mobility events.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper establishes that existing Net4AI architectures share compute among providers but cannot handle subscriber-specific AI models that must run at the edge and move with each user. SubEdge defines a computing context that binds a subscriber's identity to a dedicated inference container and routing policy, then migrates both together on cell changes using standard APIs. This matters because mobile AI devices need continuous low-latency inference without sharing models or running them on-device. The evaluation reports latency cut from 22.9 ms to 12.2 ms at the 95th percentile, 99.92 percent frame delivery at 30 fps, and full success on 1,560 migrations in batches of 50. The approach requires no changes to the 3GPP core.

Core claim

SubEdge contributes the computing context--a per-subscriber data structure binding a Subscription Permanent Identifier (SUPI) to its inference container, edge node, and service entitlement--and a mobility-event-driven mechanism that simultaneously migrates the subscriber's compute instance and its traffic-routing policy when the serving cell changes. SubEdge operates as an Application Function over existing Network Exposure Function (NEF) APIs with zero 3GPP core modifications. Experimental evaluation shows that this reduces 95th-percentile latency from 22.9 ms to 12.2 ms with zero packet loss across six mobility events, sustains 99.92% frame delivery for an end-to-end 30 fps inference workl

What carries the argument

The computing context, a per-subscriber data structure binding SUPI to inference container, edge node, and service entitlement, paired with the mobility-event-driven joint migration of compute instance and traffic-routing policy.

If this is right

Reduces 95th-percentile latency from 22.9 ms to 12.2 ms with zero packet loss across mobility events.
Sustains 99.92% frame delivery for 30 fps end-to-end inference workloads.
Successfully completes 1,560 migration operations in batches of up to 50 subscribers with 100% success.
Requires no modifications to the 3GPP core network by operating over existing NEF APIs.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

This mechanism could support real-time inference for manufacturer-specific models on devices that cannot run them locally.
Tighter coupling of compute and routing migration may reduce over-provisioning of edge resources during handovers.
The same binding approach might extend to other per-subscriber resources such as storage or specialized accelerators.

Load-bearing premise

Existing NEF APIs suffice to implement per-subscriber compute context binding and joint migration without any 3GPP core modifications or added signaling latency.

What would settle it

A deployment test that records packet loss or latency above 12.2 ms at the 95th percentile when NEF APIs are used to perform the joint compute-and-routing migration on cell change would falsify the performance results.

Figures

Figures reproduced from arXiv: 2606.30554 by Abdirazak Ali Asir Rage, Rahim Tafazolli, Riccardo Pozza.

**Figure 3.** Figure 3: RTT distribution across 607–609 ICMP samples (1 Hz, 0% loss): [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗

**Figure 5.** Figure 5: Per-subscriber Nnef_TrafficInfluence PUT latency under concurrent load. N simultaneous PUTs (one per SUPI) for N ∈ {1, 5, 10, 20, 30, 40, 50}, ten repetitions each (1,560 operations, all HTTP 200). Boxes show median/IQR; whiskers 1.5×IQR. and its p95 is nearly half that of either baseline. The gain is not an artefact of spending more time near one node: the trajectory is balanced (45% Node A zone, 55% Nod… view at source ↗

read the original abstract

Beyond traditional connectivity, 6G is envisioned to transform mobile networks into a distributed fabric that provides native integrated communication, computing, and intelligence services. AI-native terminals (e.g., robots, autonomous vehicles, and smart glasses) require real-time inference from individualised, manufacturer-specific models that cannot be executed on-board nor shared across subscribers, making per-subscriber edge compute the necessary complement to per-subscriber connectivity. Existing Network for AI (Net4AI) architectures provision compute for application providers through shared deployments and do not address per-subscriber provisioning. This paper proposes SubEdge, a Net4AI subsystem that provisions integrated communication and compute resources on a per-subscriber basis, ensuring the coupled migration of both dimensions to maintain service continuity during mobility. SubEdge contributes the computing context--a per-subscriber data structure binding a Subscription Permanent Identifier (SUPI) to its inference container, edge node, and service entitlement--and a mobility-event-driven mechanism that simultaneously migrates the subscriber's compute instance and its traffic-routing policy when the serving cell changes. SubEdge operates as an Application Function over existing Network Exposure Function (NEF) APIs with zero 3GPP core modifications. Experimental evaluation on a real-world testbed shows that SubEdge's mobility-driven joint communication-and-compute migration reduces 95th-percentile latency from 22.9 ms to 12.2 ms with zero packet loss across six mobility events, sustains 99.92% frame delivery for an end-to-end 30 fps inference workload, and completes 1,560 migration operations across batches of up to 50 simultaneously migrating subscribers with 100% success.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

SubEdge's testbed gives concrete numbers on joint compute-routing migration for per-subscriber AI but the zero-modification NEF claim is the part that needs checking.

read the letter

The main thing to know is that this paper shows a testbed where migrating both the subscriber's inference container and its traffic policy together cuts 95th-percentile latency from 22.9 ms to 12.2 ms with zero packet loss across mobility events, while keeping 99.92% frame delivery on a 30 fps workload and hitting 100% success on 1560 batch migrations up to 50 at a time.

What is new is the computing context data structure that binds a SUPI to a specific container, edge node, and entitlement, plus the mobility-event trigger that moves compute and routing policy as one unit. This moves beyond the shared deployments common in earlier Net4AI work and targets individualized models that cannot run on-device or be shared.

The experimental numbers are the paper's strongest part. They come from a real testbed and directly measure the coupled migration effect, which is useful evidence for anyone dealing with always-connected AI devices.

The soft spot is the premise that standard NEF APIs are enough to do the per-subscriber binding and atomic joint migration with no 3GPP core changes. The stress-test note is right to flag this: NEF per TS 29.122 covers traffic influence and event exposure but does not natively include container lifecycle operations or guaranteed atomic compute-plus-routing moves. If the implementation needed extensions or extra signaling, the reported latency and success rates would not translate directly to production networks.

This is for people working on edge architectures for private AI models in 6G. The testbed grounding is solid enough that it deserves peer review to verify the exact NEF usage and see how far the approach scales beyond the lab setup.

Referee Report

1 major / 1 minor

Summary. The paper proposes SubEdge, a Net4AI subsystem for 6G that provisions per-subscriber integrated communication and compute resources for individualized AI inference models. It introduces the computing context (a SUPI-to-inference-container binding) and a mobility-event-driven mechanism for simultaneous migration of the compute instance and traffic-routing policy. SubEdge is positioned as an Application Function using only existing NEF APIs with zero 3GPP core modifications. The central experimental claims, supported by real-world testbed measurements, are a reduction in 95th-percentile latency from 22.9 ms to 12.2 ms with zero packet loss across six mobility events, 99.92% frame delivery for a 30 fps end-to-end inference workload, and 100% success across 1,560 migration operations in batches of up to 50 subscribers.

Significance. If the NEF compatibility premise holds, the work addresses a clear gap in per-subscriber (vs. shared) edge compute provisioning for AI-native terminals in 6G. The explicit credit is due to the concrete, falsifiable testbed metrics on latency, packet loss, frame delivery, and batch migration success rates, which provide reproducible evidence for the joint migration mechanism rather than relying on simulation or fitted parameters.

major comments (1)

[Abstract] Abstract (and the description of SubEdge operating as an Application Function over NEF APIs): the load-bearing claim that per-subscriber compute context binding and atomic joint migration of container plus traffic-routing policy can be realized solely via standard NEF APIs (TS 29.122) without core modifications or added signaling latency is not substantiated by reference to specific API operations; standard NEF supports traffic influence and event exposure but does not natively expose per-subscriber container lifecycle management, which directly risks the reported 12.2 ms latency and 100% batch success not being achievable in unmodified 3GPP deployments.

minor comments (1)

The introduction of the term 'computing context' as a novel data structure would benefit from explicit comparison to related concepts such as UE context or application context in prior edge computing literature to clarify novelty.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the constructive feedback and the opportunity to clarify the NEF compatibility claims in our manuscript. We address the single major comment point-by-point below.

read point-by-point responses

Referee: [Abstract] Abstract (and the description of SubEdge operating as an Application Function over NEF APIs): the load-bearing claim that per-subscriber compute context binding and atomic joint migration of container plus traffic-routing policy can be realized solely via standard NEF APIs (TS 29.122) without core modifications or added signaling latency is not substantiated by reference to specific API operations; standard NEF supports traffic influence and event exposure but does not natively expose per-subscriber container lifecycle management, which directly risks the reported 12.2 ms latency and 100% batch success not being achievable in unmodified 3GPP deployments.

Authors: We agree that the abstract and main text would benefit from explicit references to specific NEF operations. The manuscript (Section 3.2 and 4.1) describes SubEdge using the NEF Traffic Influence API (TS 29.122, clause 5.2) to install per-SUPI traffic routing policies and the Event Exposure API to subscribe to mobility events that trigger joint migration. The computing context is maintained by the AF itself; container lifecycle operations are coordinated through the edge platform's northbound interface, with all network-state changes executed exclusively via NEF. No 3GPP core modifications or new signaling paths are introduced. The reported testbed results were obtained on an open-source NEF implementation that is fully compliant with TS 29.122, confirming that the measured 12.2 ms 95th-percentile latency and 100% migration success are achievable without added latency. To address the referee's concern, we will revise the abstract and add a new table in Section 4 that maps every SubEdge operation to the precise NEF API call and parameters used. revision: yes

Circularity Check

0 steps flagged

No circularity; experimental claims rest on testbed measurements

full rationale

The paper describes an architecture (SubEdge) and reports direct experimental outcomes from a real-world testbed (latency reduction, frame delivery, migration success rates). No equations, parameter fits, predictions derived from inputs, or self-citation chains appear in the provided text. The central claims are externally falsifiable via the described benchmarks and do not reduce to definitions or prior author work by construction. This is the expected non-finding for a measurement-driven systems paper.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The paper introduces one new data structure (computing context) and relies on standard 3GPP exposure interfaces. No numerical free parameters are fitted. The central claims rest on the assumption that NEF APIs suffice for the required operations.

axioms (1)

domain assumption Existing Network Exposure Function (NEF) APIs can be used by an Application Function to provision and migrate per-subscriber compute resources without core network changes.
Invoked in the description of SubEdge operating over NEF APIs with zero 3GPP core modifications.

invented entities (1)

computing context no independent evidence
purpose: Per-subscriber data structure binding SUPI to inference container, edge node, and service entitlement.
New entity introduced to enable the per-subscriber provisioning and migration mechanism.

pith-pipeline@v0.9.1-grok · 5843 in / 1692 out tokens · 56827 ms · 2026-06-30T03:06:11.266524+00:00 · methodology

discussion (0)

Reference graph

Works this paper leans on

15 extracted references · 1 canonical work pages

[1]

Survey of machine learning accelerators,

A. Reuther, P. Michaleas, M. Jones, V . Gadepally, S. Samsi, and J. Kepner, “Survey of machine learning accelerators,” in2020 IEEE High Performance Extreme Computing Conference (HPEC). IEEE, 2020, pp. 1–12

2020
[2]

Efficient acceleration of deep learning inference on resource-constrained edge devices: A review,

M. M. H. Shuvo, S. K. Islam, J. Cheng, and B. I. Morshed, “Efficient acceleration of deep learning inference on resource-constrained edge devices: A review,”Proceedings of the IEEE, vol. 111, no. 1, pp. 42– 91, 2022

2022
[3]

6G network architecture: QoS paradigms and data lifecycle management for next-generation networks,

Y . Yuan, B. Sun, J. Zeng, Q. Wu, J. Liu, D. Jiang, and F. Qin, “6G network architecture: QoS paradigms and data lifecycle management for next-generation networks,”IEEE Communications Magazine, vol. 63, no. 8, pp. 16–22, 2025

2025
[4]

6G mobile computing aware networks: A deep fusion of communication and computing,

C. Peng, Q. Li, L. Lu, L. Yang, M. Zhao, S. Wu, D. Wang, N. Shi, C. Fang, H. Xiaoet al., “6G mobile computing aware networks: A deep fusion of communication and computing,” inProc. ACM CoNEXT-2025 Workshop on Computing and Network Convergence (CNC), 2025, pp. 1–7

2025
[5]

Toward an integrated 6G compute architecture,

N. Tenny, C.-S. Yang, Y .-J. Ku, A. C.-C. Hsu, and D. Calin, “Toward an integrated 6G compute architecture,”IEEE Wireless Communications, vol. 32, no. 5, pp. 9–11, 2025

2025
[6]

Multi-access edge computing (MEC); framework and reference architecture,

ETSI, “Multi-access edge computing (MEC); framework and reference architecture,” European Telecommunications Standards Institute, ETSI GS MEC 003 V4.1.1, May 2025

2025
[7]

Architecture for enabling edge applications,

3GPP, “Architecture for enabling edge applications,” 3rd Generation Partnership Project, TS 23.558 V20.0.0, Sep. 2025, release 20

2025
[8]

In-network computing: An architectural framework for the 6G core,

R. Guerzoni, M. G. Spina, D. V . S. Lebron, S. Schwarzmann, R. Triv- isonno, F. De Rango, D. Corujo, and A. Iera, “In-network computing: An architectural framework for the 6G core,”IEEE Communications Standards Magazine, 2026

2026
[9]

Unleashing ai- empowered slices on mobile networks for natively cognitive service delivery,

R. Moreira, L. F. R. Moreira, and F. d. O. Silva, “Unleashing ai- empowered slices on mobile networks for natively cognitive service delivery,”IEEE Access, 2025

2025
[10]

AI-native network slicing for 6G networks,

W. Wu, C. Zhou, M. Li, H. Wu, H. Zhou, N. Zhang, X. S. Shen, and W. Zhuang, “AI-native network slicing for 6G networks,”IEEE Wireless Communications, vol. 29, no. 1, pp. 96–103, 2022

2022
[11]

Enhancing network data analytics functions: Integrating AIaaS with ML model provisioning,

A. Nadar and J. Härri, “Enhancing network data analytics functions: Integrating AIaaS with ML model provisioning,” inProc. 22nd Mediter- ranean Communication and Computer Networking Conf. (MedComNet). IEEE, 2024, pp. 1–4

2024
[12]

AI sessions for network-exposed AI-as-a- service,

M. Chraiti and M. Saimler, “AI sessions for network-exposed AI-as-a- service,”arXiv preprint arXiv:2602.15288, 2026

work page arXiv 2026
[13]

Native support of AI applications in 6G mobile networks via an intelligent user plane,

S. Schwarzmann, T. E. Civelek, A. Iera, D. Corujo, G. T. Karetsos, R. Guerzoni, O. Abboud, A. M. Valenzuela, R. Trivisonno, M. G. Spina et al., “Native support of AI applications in 6G mobile networks via an intelligent user plane,” inProc. IEEE Wireless Communications and Networking Conf. (WCNC). IEEE, 2024, pp. 1–6

2024
[14]

Procedures for the 5G System (5GS); Stage 2,

3GPP, “Procedures for the 5G System (5GS); Stage 2,”3GPP Technical Specification 23.502 V19.7.0, Mar. 2026

2026
[15]

5G System; Network Exposure Function Northbound APIs; Stage 3,

3GPP, “5G System; Network Exposure Function Northbound APIs; Stage 3,”3GPP Technical Specification 29.522 V19.6.0, Mar. 2026. 6

2026

[1] [1]

Survey of machine learning accelerators,

A. Reuther, P. Michaleas, M. Jones, V . Gadepally, S. Samsi, and J. Kepner, “Survey of machine learning accelerators,” in2020 IEEE High Performance Extreme Computing Conference (HPEC). IEEE, 2020, pp. 1–12

2020

[2] [2]

Efficient acceleration of deep learning inference on resource-constrained edge devices: A review,

M. M. H. Shuvo, S. K. Islam, J. Cheng, and B. I. Morshed, “Efficient acceleration of deep learning inference on resource-constrained edge devices: A review,”Proceedings of the IEEE, vol. 111, no. 1, pp. 42– 91, 2022

2022

[3] [3]

6G network architecture: QoS paradigms and data lifecycle management for next-generation networks,

Y . Yuan, B. Sun, J. Zeng, Q. Wu, J. Liu, D. Jiang, and F. Qin, “6G network architecture: QoS paradigms and data lifecycle management for next-generation networks,”IEEE Communications Magazine, vol. 63, no. 8, pp. 16–22, 2025

2025

[4] [4]

6G mobile computing aware networks: A deep fusion of communication and computing,

C. Peng, Q. Li, L. Lu, L. Yang, M. Zhao, S. Wu, D. Wang, N. Shi, C. Fang, H. Xiaoet al., “6G mobile computing aware networks: A deep fusion of communication and computing,” inProc. ACM CoNEXT-2025 Workshop on Computing and Network Convergence (CNC), 2025, pp. 1–7

2025

[5] [5]

Toward an integrated 6G compute architecture,

N. Tenny, C.-S. Yang, Y .-J. Ku, A. C.-C. Hsu, and D. Calin, “Toward an integrated 6G compute architecture,”IEEE Wireless Communications, vol. 32, no. 5, pp. 9–11, 2025

2025

[6] [6]

Multi-access edge computing (MEC); framework and reference architecture,

ETSI, “Multi-access edge computing (MEC); framework and reference architecture,” European Telecommunications Standards Institute, ETSI GS MEC 003 V4.1.1, May 2025

2025

[7] [7]

Architecture for enabling edge applications,

3GPP, “Architecture for enabling edge applications,” 3rd Generation Partnership Project, TS 23.558 V20.0.0, Sep. 2025, release 20

2025

[8] [8]

In-network computing: An architectural framework for the 6G core,

R. Guerzoni, M. G. Spina, D. V . S. Lebron, S. Schwarzmann, R. Triv- isonno, F. De Rango, D. Corujo, and A. Iera, “In-network computing: An architectural framework for the 6G core,”IEEE Communications Standards Magazine, 2026

2026

[9] [9]

Unleashing ai- empowered slices on mobile networks for natively cognitive service delivery,

R. Moreira, L. F. R. Moreira, and F. d. O. Silva, “Unleashing ai- empowered slices on mobile networks for natively cognitive service delivery,”IEEE Access, 2025

2025

[10] [10]

AI-native network slicing for 6G networks,

W. Wu, C. Zhou, M. Li, H. Wu, H. Zhou, N. Zhang, X. S. Shen, and W. Zhuang, “AI-native network slicing for 6G networks,”IEEE Wireless Communications, vol. 29, no. 1, pp. 96–103, 2022

2022

[11] [11]

Enhancing network data analytics functions: Integrating AIaaS with ML model provisioning,

A. Nadar and J. Härri, “Enhancing network data analytics functions: Integrating AIaaS with ML model provisioning,” inProc. 22nd Mediter- ranean Communication and Computer Networking Conf. (MedComNet). IEEE, 2024, pp. 1–4

2024

[12] [12]

AI sessions for network-exposed AI-as-a- service,

M. Chraiti and M. Saimler, “AI sessions for network-exposed AI-as-a- service,”arXiv preprint arXiv:2602.15288, 2026

work page arXiv 2026

[13] [13]

Native support of AI applications in 6G mobile networks via an intelligent user plane,

S. Schwarzmann, T. E. Civelek, A. Iera, D. Corujo, G. T. Karetsos, R. Guerzoni, O. Abboud, A. M. Valenzuela, R. Trivisonno, M. G. Spina et al., “Native support of AI applications in 6G mobile networks via an intelligent user plane,” inProc. IEEE Wireless Communications and Networking Conf. (WCNC). IEEE, 2024, pp. 1–6

2024

[14] [14]

Procedures for the 5G System (5GS); Stage 2,

3GPP, “Procedures for the 5G System (5GS); Stage 2,”3GPP Technical Specification 23.502 V19.7.0, Mar. 2026

2026

[15] [15]

5G System; Network Exposure Function Northbound APIs; Stage 3,

3GPP, “5G System; Network Exposure Function Northbound APIs; Stage 3,”3GPP Technical Specification 29.522 V19.6.0, Mar. 2026. 6

2026