This Annex describes IMS architecture enhancements to support data channel services. Data channels are always established in the context of an IMS MMTel session. Service based interfaces applicable to data channel services are specified in clauses AA.2.4 and AA.2.5. The architecture in this annex supports separation of signalling function and media function supporting data channel services. A network function for data channel management signalling, Data Channel Signalling Function (DCSF), is specified. The network function to handle data channel media can be provided in two ways:

• by enhancing the existing IMS MRF (called MRF) to perform media functions related to DC, which interacts with the IMS AS via enhanced Mr'/Cr interfaces; and
• by introducing a new network function called Media Function (MF), which interacts with the IMS AS via the service-based interface DC2. MF provides media capabilities in support of IMS DC and Augmented Reality.

In this Release of the specification IMS Data Channel is supported in the case of non-roaming and home routed roaming scenarios.

Service subscription for IMS Data Channel shall be an extension to the MMTEL related service profile in HSS. The Data Channel subscription data shall be used by the IMS AS and S-CSCF during IMS registration, session initiation or update to authorize subscribers to use the DC service. IMS AS Service specific data is enhanced with DC specific service data, optionally stored in HSS (e.g. as repository data) and retrieved by IMS AS using N71/Sh interface. DCSF service specific data used by DCSF for data channel management, may be stored (e.g. as repository data) and retrieved from HSS using the N72/Sc interface. DCSF service specific data are out of scope of 3GPP.

The following principles apply when an IMS Data Channel is established:

• UE can establish an IMS Data Channel simultaneously while establishing an IMS audio/video session or upgrade an ongoing IMS audio/video session through a re-INVITE to an IMS Data Channel session.
• The UE may be configured by the HPLMN either via Device Management or in the UICC whether and when to initiate a DC establishment request. If the UE is not configured by the HPLMN, it is left for UE implementation whether and when to initiate the DC establishment request. The UE shall not initiate a DC establishment request if the network has not indicated support for IMS DC service during IMS registration or if the UE is configured to not establish an IMS Data Channel.
• If a UE that has not subscribed to IMS Data Channel establishes an IMS Data Channel simultaneously with an IMS audio/video IMS session, the IMS AS shall discard the Data Channel request and proceed with the audio/video IMS session establishment.
• The DCSF provides stream ID and a corresponding URL to the MF or MRF via the IMS AS during data channel media resource reservation for the bootstrap data channel that enables downloading a subscriber specific graphical user interface to the UE via the bootstrap data channel. The stream ID is optional. Once the MF or MRF, acting as HTTP proxy, receive a HTTP GET Request containing the root ("/") URL through the bootstrap data channel, the MF or MRF replaces the root ("/") URL in the HTTP GET Request with the subscriber specific URL corresponding to the stream ID (if available) of the bootstrap data channel and forward the request to the DCSF for downloading the subscriber specific graphical user interface to the UE. The MF retrieves the stream ID of the bootstrap data channel from the transport layer of the data channel connection. The UE shall maintain the HTTP session state when interacting with the MF.

Information for the binding of DC Application with the related DC is required to support multiple, simultaneous DC applications in a UE. The binding information is maintained by the HPLMN or retrieved from DC application provider when a DC Application is uploaded to DCSF. DCSF may be configured with a DC application profile associated with the binding information, which indicates the DC control policy (e.g. whether the Application DC establishment follows the P2P, P2A/A2P or P2A2P procedure). The UE receives the binding information of a DC application via the Bootstrap DC, e.g. when the DC application is downloaded to the UE. When the UE is establishing an IMS Application DC as defined in clause AC.7.2, the binding information is provided by the UE in the SDP offer as described in TS 26.114. The IMS AS provides the binding information to the DCSF. The DCSF may use the binding information for controlling the Application DC setup .

MF and the MRF provides media anchoring when needed for the IMS Bootstrap Data Channel, and the IMS Application Data Channel. To that effect, they support the following capabilities:

• HTTP Proxy: In this configuration, MF/MRF supports terminating DTLS with HTTP traffic being transparent to MF/MRF. When acting as HTTP Proxy, MF/MRF reserves media resources on both the UE side and on the MDC1/MDC2 side allowing to send HTTP traffic to the DC Application Server. This mode is deployed both for Bootstrap Data Channel, and HTTP Application Data Channels. Figure AC.6-1 illustrates the protocol stack for the HTTP proxy configuration mode for the Bootstrap Data Channel case.
  When used with HTTP Application Data Channel, the downloaded Data Channel application will in this case communicate with the DC Application Server, using basic HTTP, within the same bootstrap SCTP association as in which this application was downloaded. UDP, TCP and SCTP should be supported as the transport layer protocols for MDC2.

• UDP Proxy: In this configuration, MF/MRF transparently proxies HTTP traffic to its target. When acting as UDP Proxy, the media resources reserved by MF/MRF contain MF/MRF connection information (e.g. IP addresses and port numbers). This mode is deployed only for Application Data Channels. Figure AC.6-2 illustrates the protocol stack for the UDP proxy configuration mode for the Application Data Channel case, providing a Person2Application/Application2Person/Person2Person Data Channel Application.