Summary of S4-260182: Adaptive Model Delivery for IMS DC Applications

1. Introduction

This contribution revises previous documents (S4-251799, S4aR250211) on adaptive model delivery, incorporating the agreed call flow for device inferencing from S4aR260014 (agreed in SA4#134). The work builds upon TR 26.927 which documented AI/ML model delivery procedures.

2. Discussion

2.1 Background and Motivation

The document addresses the critical challenge of timely model delivery for UE-centric inference in IMS DC-based AI/ML applications. Key points:

• Real-time nature of multimedia communication sessions makes startup latency particularly problematic
• Delayed inference startup adversely affects QoE and service usefulness
• Adaptive model delivery can mitigate these challenges

2.2 Adaptive Model Delivery Concept

Based on TR 26.927 clause 5.2.2.2:

• Reduces startup latency by delivering a smaller, lower precision but inference-ready model first
• Subsequently updates to higher precision through model updates
• Bit-incremental model update approach was evaluated in TR 26.847 clause 5.4

2.3 Reference Call Flows

The document references two agreed high-level call flows:

General AIML IMS DC Call Flow (from S4-252075)

Key steps include:
1. MMTel service establishment
2. BDC establishment between UE and MF
3. DCSF creates DC application list based on subscription filter and UE static capabilities
4. Application list includes AI service information
5. User selects app based on AI service
6. App download via BDC
7. Task selection and model variant selection
8. ADC establishment
9. Three inferencing modes: Local, Remote, or Split

Device Inferencing Call Flow (from S4aR260014)

Detailed 15-step procedure including:
- Application discovery with AI_APPLICATION_DISCOVERY_REQUEST/RESPONSE messages
- Application metadata including AI feature tags and task descriptions
- Task manifest delivery
- Model selection and delivery via BDC or ADC
- Support for task reselection during session

3. Technical Proposal

3.1 New Clause: AI/ML Model Delivery to DCMTSI Client

3.1.1 General Model Delivery Procedure

Figure X.X-1: Basic Model Delivery over IMS DC

14-step procedure:
0. UE1 registers to IMS with AI/ML capability indication
1. MMTEL session establishment
2. IMS AS allocates DC resources
3. Session established between UE1 and UE2
4. Bootstrap Data Channel (bDC) establishment
5. DCSF creates subscriber-specific application list
6. Application list delivery over bDC
7. App selection and download with app manifest (includes inference tasks and model lists)
8. UE2 side DC procedures
9-10. Application data channel establishment with DC AS
11-12. Model selection and delivery (from DC AS or DCAR via DCSF)
13. Media exchange over MMTEL session
14. Inference execution on local or remote media

3.1.2 Adaptive Model Delivery Procedure

Figure X.Y-2: Adaptive Model Delivery over IMS DC

Enhanced procedure building on basic delivery:

Steps 1-10: Same as basic model delivery, with lower precision model selection in step 10

Step 11: Request for updatable model via MF

Steps 12a/12b: Model delivery from either:
- Option a: DCAR via DCSF
- Option b: DC-AS

Step 13: Model download to UE

Step 14: Inference loop starts and continues

Step 15: UE requests model update via MF

Steps 16a/16b: Model update delivery from either:
- Option a: DCAR via DCSF
- Option b: DC-AS

Step 17: Model update download via MF

Step 18: UE applies model update to initial model

Step 19: Inference continues with potential for further updates

3.2 Key Technical Features

• Two-stage delivery: Initial lower precision model followed by precision updates
• Dual source support: Models and updates can be sourced from either DCAR (via DCSF) or DC-AS
• Continuous inference: Inference can continue while model updates are applied
• Flexible model selection: Selection can be performed by UE, MF, or DC AS
• Session-aware: Procedure integrated with IMS DC session lifecycle

Editor's Notes and Open Issues

The referenced S4aR260014 document contains an Editor's Note indicating:
- Whether MF needs to understand AI task semantics requires clarification (FFS)
- Application type handling needs clarification
- Large model handling procedures need clarification