Tech-invite3GPPspaceIETF RFCsSIP
indexN21222324252627282931323334353637384‑5x

Content for  TS 23.228  Word version:  18.2.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.2.4…   4.3…   4.4…   4.13…   4.16…   5…   5.2…   5.3…   5.4…   5.4.7…   5.4.8…   5.4a…   5.5…   5.5.3…   5.6…   5.6.3…   5.7…   5.7.3…   5.7.5…   5.7.8…   5.8…   5.10…   5.11…   5.11.3…   5.11.3.3   5.11.3.4   5.11.4…   5.11.5…   5.11.5.3…   5.11.6…   5.12…   5.16…   5.16.2…   5.19…   5.20…   A…   E…   E.2.2…   G…   G.5…   H   I…   J…   K…   L…   M…   M.3…   N…   P…   Q…   Q.2.5…   R…   S…   T…   U…   U.2…   V…   W…   X…   Y…   Z…   AA…   AA.3…   AB…   AC…   AC.7…   AC.7.2…   AC.7.2.2   AC.7.2.3…   AC.7.4…   AC.9…

 

AC (Normative)  Support of Data Channel services in IMS |R18|p. 364

AC.1  Generalp. 364

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 clause AA.1.3.
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 Data Channel Media Function (DCMF), which interacts with the IMS AS via the service-based interface DC2.
In this Release of the specification IMS Data Channel is supported in the case of non-roaming and home routed roaming scenarios.
Up

AC.2  Architecture and functionsp. 364

AC.2.1  Architecturep. 364

Figure AC.2.1-1 shows the data channel architecture when using the service-based DC media function.
Reproduction of 3GPP TS 23.228, Fig. AC.2.1-1: Architecture option of IMS supporting DC usage with DCMF
Up
Figure AC.2.1-2 shows the data channel architecture when using the MRF.
Reproduction of 3GPP TS 23.228, Fig. AC.2.1-2: Architecture option of IMS supporting DC usage with MRF
Up

AC.2.2  Functional entitiesp. 366

AC.2.2.1  Data Channel Signalling Function (DCSF)p. 366

The DCSF is the signalling control function that provides data channel control logic. The DCSF is not involved in SIP signalling. The DCSF supports the following functionalities:
  • The DCSF receives event reports from the IMS AS and decides whether data channel service is allowed to be provided during the IMS session;
  • The DCSF manages bootstrap data channel and (if applicable) application data channel resources at the DCMF or MRF via the IMS AS;
  • The DCSF supports HTTP web server functionality to download data channel applications (bootstrapping) via DCMF and/or MRF to the UE based on UE subscription.
  • The DCSF downloads data channel applications from the Data Channel Application Repository;
  • The DCSF interacts with NEF for data channel capability exposure via N33;
  • The DCSF interacts with the DC Application Server for DC resource control via DC4/DC3, and for traffic forwarding via MDC3/MDC2.
Up

AC.2.2.2  Data Channel Application Repository (DCAR)p. 366

The Data Channel Application Repository stores the verified data channel applications which are retrieved by the DCSF when required.

AC.2.2.3  Data Channel Media Function (DCMF) / MRFp. 366

The DCMF and MRF provide the media resource management and forwarding of data channel media traffic . The DCMF and MRF provides the following functionalities:
  • The DCMF and MRF manage the data channel media resources (bootstrap and application data channel resources, if applicable) under the control of the IMS AS;
  • The DCMF and MRF terminate the bootstrap data channel from the UE and forward HTTP traffic between the UE and DSCF via MDC1;
  • The DCMF and MRF may anchor the application data channel in P2P scenarios, if required, and forward application data traffic from/to the UEs;
  • The DCMF and MRF relays traffic on the A2P/P2A application data channels between the UE and the DC Application Server via MDC2.
Up

AC.2.2.4  IMS ASp. 366

The IMS AS is enhanced to support the following functionalities:
  • The IMS AS interacts with the DCSF via DC1 for event notifications;
  • The IMS AS receives the data channel control instructions from the DCSF and accordingly interacts with the DCMF via DC2 or wit MRF via Mr'/Cr for data channel media resource management;

AC.2.3  Reference pointsp. 367

The following service-based reference points are defined to support data channel service in IMS:
  • DC1: Reference point between the DCSF and the IMS AS.
  • DC2: Reference point between the IMS AS and DCMF.
  • DC3: Reference point between the DCSF and NEF.
  • DC4: Reference point between the DCSF and DC Application Server.
  • DC5: Reference point between the DCSF and DCAR.
  • N72/Sc: Reference point between the DCSF and HSS.
The following service- based reference points are updated to support data channel signalling control in IMS:
  • N70/Cx/Dx: Reference point between the CSCF and HSS.
  • N71/Sh: Reference point between the IMS AS and HSS.
The following reference points are defined for data channel media handling:
  • MDC1: Reference point for transport of data channel media between data channel media function (either DCMF or MRF) and DCSF.
  • MDC2: Reference point for transport of data channel media between data channel media function (either DCMF or MRF) and DC Application Server.
  • MDC3: Reference point for transport of data channel media between DCSF and DC Application Server.
The following reference point is updated to support data channel media handling:
  • Mr'/Cr: SIP based reference point between IMS AS and MRF.
Up

AC.3  IMS Data Channel Service Subscriptionp. 367

Service Subscription for IMS Data Channel shall be an extension to the MMTEL service profile in HSS. The Data Channel subscription information shall be used by the IMS AS during IMS 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 interface.
DCSF service specific data used by DCSF for data channel management, may be stored and retrieved from HSS using the N72 interface. DCSF service specific data are out of scope of 3GPP.
Up

AC.4  IMS DC Channel Setupp. 367

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 when to initiate a DC establishment request. If the UE is not configured, it is left for UE implementation 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.
  • 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 DCMF 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 DCMF or MRF, acting as HTTP proxy, receive a HTTP GET Request containing the root ("/") URL through the bootstrap data channel, the DCMF 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 DCMF 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 DCMF.
Up

AC.5  Binding of DC Application with the related DCp. 368

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 .
Up

AC.6  Data Channel Media Setupp. 368

DCMF 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, DCMF/MRF supports terminating DTLS with HTTP traffic being transparent to DCMF/MRF. 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.
Reproduction of 3GPP TS 23.228, Fig. AC.6-1: DCMF/MRF "HTTP Proxy" Media Configurations
Up
  • UDP Proxy: In this configuration, DCMF/MRF transparently proxies HTTP traffic to its target. 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.
Reproduction of 3GPP TS 23.228, Fig. AC.6-2: DCMF/MRF "UDP Proxy" Media Configurations
Up

Up   Top   ToC