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 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. Multiplexing of multiple IMS Data Channel streams with different endpoints onto a single SCTP association is not supported in this Release of the specification.

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 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, acting as HTTP proxy, receive a HTTP GET Request containing the root ("/") URL through the bootstrap data channel, the MF 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 attribute of the SDP offer as specified in clause 6.2.13 of 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 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 supports terminating DTLS with HTTP traffic being transparent to MF. When acting as HTTP Proxy, MF 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 transparently proxies HTTP traffic to its target. When acting as UDP Proxy, the media resources reserved by MF contain MF 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.