Summary of S4-260092: IMS Bootstrap Data Channel Restart

Introduction

This contribution addresses issues related to IMS Data Channel (DC) failure and exceptional case handling in TS 26.114, which will be reviewed under the newly started study on DC Enhancements (FS_DCE_MED).

Problem Statement

Missing Specifications for Failure Cases

The document identifies that TS 26.114 lacks clear handling procedures for IMS DC failure and exceptional cases, which could result in:
- Inconsistent behavior
- Interoperability problems

Scope within DC Enhancement Study

The identified problem maps to multiple DC Enhancement study objectives:
- Clarifications to HTTP protocol usage on DC
- Identification of inconsistencies and ambiguities between TS 23.228, TS 26.114, TS 26.264, and TS 26.567

IMS DC Transport Restart Scenarios

The contribution focuses on IMS DC transport restart (DTLS restart and/or SCTP restart), which may be triggered by:
- IMS call forwarding
- IMS call forking (typically when using IMS DC as "early media")
- Access transport failures causing IP address and/or UDP port changes on core and/or UE side

Note: DTLS and SCTP restart procedures are covered by references to IETF RFC 8864 and RFC 8841 in TS 26.114.

Bootstrap Data Channel (BDC) Initial URL Ambiguity

Current TS 26.114 clause 6.2.10.1 specifies:
- Initial entry point accessible at HTTP root ("/") URL after BDC establishment
- Per TS 29.176 clause 6.1.6.2.5, this root URL is typically modified in the MF to represent the specific subscriber before being passed to DCSF for user customization
- The modified URL is not visible to the UE

Key Gap: The specification does not define which initial URL the UE should use when the BDC is reestablished after a restart.

Potential Solutions

The document presents three alternative approaches for selecting the initial URL in a reestablished BDC:

Option 1: Use Original Initial Entry Point ("/") - Preferred

Characteristics:
- Reuse the same initial entry point as first BDC establishment
- Possible interpretation of existing text
- Straightforward implementation
- Provides clearly defined restart point
- Maintains possibility for MF to adapt URL to specific subscriber
- No identified downsides

Source Position: This is the preferred approach.

Option 2: Use Last URL Before Restart

Limitations:
- Would likely fail in forking or forwarding scenarios
- IMS network serving the URL may differ before and after restart
- Previously valid URL may become invalid in the post-restart IMS network

Option 3: Use Some Other URL

Status:
- No current use cases or scenarios exist to guide URL selection
- Not a viable option at this time

Proposals

The document proposes two actions for the DC Enhancement study:

1. Include this topic as a key issue in draft TR 26.823
2. Include the above potential solutions to address this key issue in draft TR 26.823