Further Details on DC Application List

Introduction

This contribution consolidates relevant text from existing 3GPP specifications (TS 23.228, TS 29.176, and TS 26.114) regarding the Data Channel (DC) application list request mechanism, particularly focusing on root URL replacement procedures. The document aims to clarify how these procedures are already defined in the context of Bootstrap Data Channel (BDC) setup and proposes their reuse for AIML_IMS-MED work.

Relevant Specifications Overview

Bootstrap Data Channel Setup Signalling (TS 23.228 Clause AC.7.1)

The specification defines the complete BDC establishment procedure for person-to-person use cases where the Media Function (MF) anchors the bootstrap data channel:

Key Steps:

• Steps 1-2: UE#1 sends SIP INVITE with initial SDP containing bootstrap DC offers. IMS AS validates user subscription and determines if DCSF notification is required.

• Steps 3-6: IMS AS notifies DCSF via Nimsas_SessionEventControl_Notify with session parameters. DCSF determines policy, reserves MDC1 media information for both originating and terminating sides, and responds with Nimsas_MediaControl_MediaInstruction containing:

• MDC1 media endpoint addresses
• DC Stream ID

• Replacement HTTP URL representing the application list offered via MDC1 interface

• Steps 7-10: IMS AS selects MF and invokes Nmf_MRM_Create to allocate DC media resources. The request includes information for both Mb and MDC1 interfaces. MF responds with negotiated media resource information.

• Steps 11-19: SDP negotiation completes through terminating network, with similar DCSF/MF resource allocation on terminating side. Bootstrap data channels are established.

• Steps 20-24: Critical application list request flow:

• UEs send application request messages to MF via established bootstrap data channel
• MF replaces the root URL with the replacement URL received in step 8
• MF forwards message to DCSF media endpoint
• DCSF provides application list and DC applications to UEs based on capabilities and choices through MF
• Either UE may select applications from local or remote DCSF (subject to DCSF policy)

Media Control Service Operation (TS 23.228 Clause AA.2.4.3.2)

The Nimsas_MediaControl_MediaInstruction service operation defines the MediaInstructionSet structure:

DC Media Specification includes:

• Media proxy configuration (HTTP or UDP)
• MDC1/MDC2 media endpoint address
• Replacement HTTP URL per stream ID allocated by application layer representing the application list (e.g., graphical user interface) provided to IMS subscriber via MDC1 interface (used only in BDC establishment)
• Data Channel Mapping and Configuration information
• DC Interworking indication
• Data Channel Port and SCTP Port

Media Instructions supported:
- TerminateMedia
- OriginateMedia
- TerminateAndOriginateMedia
- UpdateMedia
- DeleteMedia
- RejectMedia

MF Resource Management (TS 29.176 Clause 5.2.2.2)

The Nmf_MRM_Create service operation defines how NF service consumer (IMS AS) requests media context creation:

For DC media resource type, the request includes:

• Media proxy configuration in mediaProxyConfig attribute
• Data channel mapping and configuration in streams attribute (SCTP stream ID, subprotocol, order, maxRetry, maxTime, priority)
• Remote SCTP and DTLS endpoint information in remoteDcEndpoint
• Optional maximum message size

For bootstrap data channel specifically:

• Remote MDC1 media specification in remoteMdc1Endpoint attribute within Mdc1Info data type
• Replacement HTTP URL for each streamId allocated by application layer representing the application list offered to IMS subscriber via MDC1 interface

For P2A/A2P application data channel:

• Remote MDC2 media specification in remoteMdc2Endpoint attribute within Mdc2Info data type

Data Channel Application Definition (TS 26.114 Clause 6.2.10.1)

Data channel application consists of:
- HTML web page including JavaScript(s)
- Optionally image(s) and style sheet(s)

Bootstrap data channel is defined as:
- Data channel used to retrieve DC application(s) for DCMTSI client
- Data channel stream ID below 1000
- Uses HTTP protocol as data channel subprotocol
- Application accessible at HTTP root ("/") URL describes GUI and logic for further data channel usage
- Authority (host) part of URL and "Host" HTTP header shall be ignored on reception and set to empty value by DCMTSI client

Discussion

The complete flow for application list handling is already specified:

1. DCSF provides replacement HTTP URL to IMS AS in MediaInstructionSet (representing application list)
2. IMS AS forwards replacement HTTP URL to MF during resource allocation via Nmf_MRM_Create
3. UE sends HTTP GET request for application list to MF via bootstrap data channel
4. MF performs root URL replacement using the replacement HTTP URL received from IMS AS
5. MF forwards request to DCSF media endpoint (MDC1)
6. DCSF provides application list and selected DC applications to UE through MF

The specifications explicitly state that "the details of how to provide the application list to the UE and how to use it by the UE are not defined in TS 23.228," but the transport mechanism and URL replacement procedures are fully defined.

Proposal

From the UE perspective, the following procedures are already well-defined in TS 23.228 as part of BDC setup signalling:

• Request of an application list
• Download of the application list
• Request of a selected application
• Download of the selected application

For AIML_IMS-MED work:

1. Reuse these existing procedures and HTTP protocol for the same purposes
2. Capability exchange negotiation between UE and MF (e.g., for task and/or model selection) should happen after the selection and download of a DC application
3. Capability exchange should occur via an application data channel established for that specific application

This approach leverages existing standardized mechanisms and maintains consistency with current IMS DC architecture.