Content for TS 23.228 Word version: 19.1.0

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.7.9… AC.7.9.3… AC.7.10… AC.7.10.4.2… AC.9… AC.10… AC.11… AD… AE… AF… AG…

AC.10 Standalone IMS Data Channel Sessions AC.10.1 General AC.10.2 Procedures AC.10.2.1 Originating Standalone Bootstrap DC Setup using PSI AC.10.2.2 Originating Standalone IMS DC Session if Application not Available in Originating UE AC.10.2.3 Originating Standalone IMS DC Session if Application Available in Originating UE AC.10.2.4 Adding MMTel Media to Standalone IMS Data Channel Session AC.10.2.5 Removing All MMTel Media from IMS Data Channel Session
...

AC.10 Standalone IMS Data Channel Sessions |R19| p. 411

AC.10.1 General p. 411

A standalone IMS data channel session is applied to establish data channels without MMTel media (e.g. audio, video, messaging). A standalone IMS data channel session with bootstrap data channels is used for downloading application list and applications from the DCSF. Application data channels between two UEs may be initiated with bootstrap data channels simultaneously or not during the standalone IMS data channel session establishment.

There are two types of standalone IMS data channel session:

IMS session with only bootstrap data channel towards PSI, which cannot add MMTel media.
IMS session with only bootstrap and application data channels towards peer UE.

In the case of b), the terminating UE sends 180 Ringing only when the terminating UE successfully downloaded the DC application indicated by the originating UE. The IMS data channel session is able to be answered by the terminating UE after the DC application for communication is allowed to run on the terminating UE. It is assumed early media is used during the process.

The standalone IMS data channel session towards peer UE can be updated by adding MMTel media to the session. All MMTel media can be removed from an IMS data channel session towards peer UE if standalone IMS data channel session is supported.

When standalone IMS data channel session is supported, based on operator policy, additional subscription information for standalone IMS data channel service may be required to be included in service subscription. The additional subscription information is used by the IMS AS to determine whether to accept or reject a standalone IMS data channel session.

When subscription for a standalone IMS data channel session is needed, and if a UE that has not subscribed for standalone IMS data channel session, the IMS AS rejectS the request of standalone IMS data channel session establishment.

Standalone IMS data channel sessions use SIP session timer as per RFC 4028 to avoid hanging resources in the UE and the network. Usage of SIP session timer in IMS is specified in TS 24.229. Establishment of standalone IMS data channel sessions does not require SIP precondition.

The standalone IMS data channel session is terminated by the existing session release procedure specified in clause AC.7.6. The session release may be triggered by the expiry of the session timer or by sending a SIP BYE request.

AC.10.2 Procedures p. 412

AC.10.2.1 Originating Standalone Bootstrap DC Setup using PSI p. 412

The originating standalone Bootstrap DC setup using PSI is triggered by a UE for downloading application list and/or applications from DCSF. In this procedure, a PSI is configured in the UE for that purpose.

After the standalone bootstrap DC is established, the UE downloads the application list and/or applications via the bootstrap DC. The list of application information is used for selection, downloading, and/or initiating standalone application DC in a subsequent IMS data channel session. The UE terminates the standalone IMS data channel session when the session timer expires.

Whether and when to initiate the standalone Bootstrap DC setup using PSI is up to UE implementation.

Figure AC.10.2.1-1depicts a signalling flow diagram for originating standalone bootstrap data channel setup using PSI.

Reproduction of 3GPP TS 23.228, Fig. AC.10.2.1-1: Originating Standalone Bootstrap DC Setup using PSI

Figure AC.10.2.1-1: Originating Standalone Bootstrap DC Setup using PSI

Step 1.

UE#1 sends the SIP INVITE request with an initial SDP offer to the IMS AS, through P-CSCF and S-CSCF in the originating network. The Request URI of the SIP INVITE message is a specific target URI, i.e. a specific PSI indicating standalone bootstrap DC. The initial SDP offer includes only the bootstrap data channel establishment request with bootstrap DC stream ID(s). The SIP precondition is not needed.

Step 2-4.

Steps 2-4 of clause AC.7.1 apply with the following difference:

The IMS AS rejects a session initiated by a UE not subscribed for a standalone IMS data channel session.

Step 5.

Since the SessionEstablishmentRequestEvent indicates that served user is offered only a local bootstrap media, the DCSF, based on the value of the Called ID (i.e. the specific PSI) and the content of the initial SDP offer, determines that the UE#1 requests to establish a standalone bootstrap DC and reserves only originating side MDC1 media information, which is used to receive the UE request for application downloading from the MF.

Step 6.

The DCSF invokes the Nimsas_MediaControl_MediaInstruction (Session ID, Media Instruction Set) service operation based on its policies instructing the IMS AS how to set up bootstrap data channel with the MF for originating side. The MediaInstructionSet provided by the DSCF, includes its MDC1 media endpoint addresses created in step 5, DC Stream ID, and the replacement HTTP URL representing the application list offered via the MDC1 interface.

Step 7.

Step 7 of clause AC.7.1 applies.

Step 8.

The IMS AS invokes Nmf_MRM_Create (List of Media Termination Descriptors) service operation to instruct the MF to allocate required data channel media resources for originating side only. The IMS AS requests creation of only one Media Termination which representing the local bootstrap media to be terminated.

Step 9-10.

Steps 9-10 of clause AC.7.1 apply.

Step 11.

The IMS AS does not forward the SIP INVITE request based on the specific Request URI (i.e. PSI) and sends the SIP 18X response with the SDP answer through S-CSCF and P-CSCF to UE#1.

Step 12-13.

The standalone IMS data channel session with only bootstrap data channel is answered and bootstrap data channel between the originating MF and UE#1 is established.

Step 14.

The UE#1 sends application request messages to the MF to request a data channel application or an application list if multiple DC applications are available, via the established bootstrap data channel. The MF forwards the message to the received media point of DCSF. The DCSF provides the application list and proper data channel applications further to the UE#1 based on their data channel capabilities and their choices through MF.

Step 15-16.

If the established bootstrap DC is not used for a period of time (expiry of the session timer), UE#1 sends SIP BYE to release the bootstrap DC.

AC.10.2.2 Originating Standalone IMS DC Session if Application not Available in Originating UE p. 413

When an originating UE initiates a standalone IMS data channel session and the DC application is not available in the originating UE, the originating UE initiates standalone bootstrap DC setup. After successful establishment of bootstrap DC with the DCSF, the originating UE downloads the DC application via the bootstrap DC and updates the IMS session to add application DC. If the DC application is not downloaded yet by the terminating UE, the terminating UE does not accept the addition until the DC application is downloaded via the bootstrap DC. If the terminating UE did not successfully download the DC Application, the terminating UE, as an example, does not alert the user at all and tear down the entire IMS session.

Figure AC.10.2.2-1 depicts a signalling flow diagram for originating standalone IMS DC Session if application is not available in the originating UE with the assumption that application list is available in the originating UE.

Copy of original 3GPP image for 3GPP TS 23.228, Fig. AC.10.2.2-1: Originating Standalone IMS DC Session if Application not Available in Originating UE

Figure AC.10.2.2-1: Originating Standalone IMS DC Session if Application not Available in Originating UE
(⇒ copy of original 3GPP image)

The steps in the call flow are as follows:

Step 1.

The UE#1 sends an initial SIP INVITE request with an initial SDP offer including media component for bootstrap data channel for originating side and optional for terminating side. The SIP precondition is not needed. The originating P-CSCF may include the P-Early-Media header field indicating support of early media authorization in the initial SIP INVITE request if not exists.

Step 2-13.

Steps 2-13 of clause AC.7.1 apply. In this scenario, the SDP offer for bootstrap data channel to UE#2 are included.

Step 14.

The UE#2 returns a SIP 18X response with an SDP answer for bootstrap data channel. The IMS AS includes the P-Early-Media header field indicating early media allowed in the SIP 18X response based on the SDP answer not indicating any application data channel. Simultaneously, the UE#2 may alert the terminating user the incoming session is a standalone IMS data channel session that DC application will be indicated later.

Step 15.

Step 21 of clause AC.7.1 applies, except that the UE#1 may download the application list.

Step 16.

The UE#1 sends a SIP PRACK request towards the terminating side before or during performing step 15, and the UE#2 returns a SIP 200 OK response for the PRACK. After the DC application has been downloaded, the UE#1 initiates the SIP UPDATE request to update the IMS session for adding the application DC and to inform the UE#2 the associated DC application binding information.

The IMS AS, the DCSF, and the MF repeat steps 3-10 with the media information of bootstrap data channel and application data channel, optionally including allocation of MDC2 resources for originating and terminating side. The IMS AS sends the SIP UPDATE request with the modified SDP offer including media component for bootstrap data channel and application data channel towards the terminating network and the UE#2. The IMS AS includes the P-Early-Media header field indicating early media allowed in the SIP UPDATE request based on the previously received SDP answer not indicating any application data channel.

Step 17.

The bootstrap data channels have been established between the originating MF and the UE#2. If the DC application is not available in the UE#2, the UE#2 may alert the terminating user for DC application downloading. The UE#2 sends application request messages to the MF to request downloading the DC application and application list if needed.

Step 18-23.

When the DC application is available in the UE#2, steps 15-20 of clause AC.7.1 apply with the difference that bootstrap data channel and application data channel established is indicated. The IMS AS may include the P-Early-Media header field indicating early media allowed in the SIP 200 response for the UPDATE forwarded to the originating side.

Step 24.

The UE#2 alerts the terminating user for running the DC application. The UE#2 returns a SIP 180 response to indicate the UE#2 is ringing.

Step 25.

Subsequent procedures continue. When the terminating user accepts to run the DC application for communication, the UE#2 answers the IMS session.

AC.10.2.3 Originating Standalone IMS DC Session if Application Available in Originating UE p. 415

When an originating UE initiates a standalone IMS data channel session and the user selected DC application is available in the originating UE, the originating UE may initiate combined bootstrap DC and application DC. If the selected DC application is not downloaded yet by the terminating UE, the terminating UE will not establish the application DC and indicate the originating UE the DC application is desired to be downloaded. The originating UE further updates the standalone IMS data channel session to add the selected application DC. If the terminating UE did not successfully download the DC Application, the terminating UE, as an example, does not alert the user and tear down the entire IMS session.

Figure AC.10.2.3-1 depicts a signalling flow diagram for originating standalone IMS DC Session if application is available in the originating UE.

Copy of original 3GPP image for 3GPP TS 23.228, Fig. AC.10.2.3-1: Originating Standalone IMS DC Session if Application Available in Originating UE

Figure AC.10.2.3-1: Originating Standalone IMS DC Session if Application Available in Originating UE
(⇒ copy of original 3GPP image)

The steps in the call flow are as follows:

Step 1.

The UE#1 sends the initial SIP INVITE request with an initial SDP offer including the media information of the bootstrap DC and application DC, as well as the associated DC application binding information. The SIP precondition is not needed. The originating P-CSCF may include the P-Early-Media header field indicating support of early media authorization in the initial SIP INVITE request if not exists.

Step 2.

The IMS AS determines whether the IMS session is a standalone IMS data channel session, and determines if the session is allowed to be established based on local configuration or subscription data. If standalone IMS data channel session is not allowed, the IMS AS rejects the request, otherwise the IMS AS selects a DCSF for this user based on local configuration or discovery and selection of a DCSF instance via NRF.

Step 3-10.

Steps 3-10 of clause AC.7.1 apply with the media information of bootstrap data channel and application data channel, optionally including allocation of MDC2 resources for originating and terminating side.

Step 11-13.

Steps 11-13 of clause AC.7.1 apply. In this scenario, the SDP offer for bootstrap data channel, application data channel, and the associated DC application binding information to UE#2 are included.

Step 14.

The UE#2 returns a SIP 18X response with the SDP answer for bootstrap data channel and application data channel. If the DC application is not available in the UE#2, the UE#2 may alert the terminating user for DC application downloading. The UE#2 indicates the DC application is not available but desired to be downloaded in the SDP answer if needed.

Step 15.

The bootstrap data channels have been established between originating MF and the UE#1.

Step 16.

The bootstrap data channels have been established between originating MF and the UE#2.

Step 17.

The UE#1 sends a SIP PRACK request towards the terminating side before or during performing step 15. If the indication that DC application is desired to be downloaded is received, the UE#1 will consequently send a SIP UPDATE request to update the IMS session for adding the selected application data channel. The IMS AS includes the P-Early-Media header field indicating early media allowed in the SIP UPDATE request forwarded to the terminating side based on the indication.

Step 18.

The UE#2 sends application request messages to MF to request downloading the DC application and application list if needed.

Step 19-24.

If the DC application does not need to be downloaded in the UE#2, the UE#2 returns a 200 response for the PRACK. Otherwise, after the DC application successfully downloaded, steps 15-20 of clause AC.7.1 apply with the difference that bootstrap data channel and application data channel established is indicated. The IMS AS may include the P-Early-Media header field indicating early media allowed in the SIP 200 response for the UPDATE forwarded to the originating side.

Step 25.

The UE#2 alerts the terminating user for running the DC application. The UE#2 returns a SIP 180 response to indicate the UE#2 is ringing.

Step 27.

Subsequent procedures continue. When the terminating user accepts to run the DC application for communication, the UE#2 answers the IMS session.

AC.10.2.4 Adding MMTel Media to Standalone IMS Data Channel Session p. 417

When a standalone IMS data channel session between two UEs is ongoing, any of the UE may add some MMTel media (e.g. audio/video/messaging) into the IMS session, which turns the standalone IMS data channel session to IMS data channel session.

Figure AC.10.2.4-1depicts a signalling flow diagram for adding MMTel media (e.g. audio/video/messaging0 to standalone IMS data channel session between two UEs.

Reproduction of 3GPP TS 23.228, Fig. AC.10.2.4-1: Adding MMTel Media to standalone IMS data channel session

Figure AC.10.2.4-1: Adding MMTel Media to standalone IMS data channel session

Step 1.

A standalone IMS DC session has been established between the UE-A and the UE-B, which does not include MMTel media.

Step 2.

The UE-A sends SIP re-INVITE request which includes an SDP offer containing the media description of both application data channel and MMTel media description.

Step 3.

The IMS AS, the DCSF and the UE-B handles the SIP re-INVITE request as specified in steps 2-9 of clause AC.7.2.1.

Step 4.

If the UE-B accepts the session update, the UE-B sends 200 OK response to the UE-A through the IMS AS, as specified in steps 10-18 of clause AC.7.2.1, indicating the MMTel media has been added.

AC.10.2.5 Removing All MMTel Media from IMS Data Channel Session p. 418

When a IMS data channel session between two UEs is ongoing, any of the UE may remove all MMTel media (e.g. audio/video/messaging) from the IMS session, which turns the IMS data channel session to standalone IMS data channel session.

Figure AC.10.2.5-1depicts a signalling flow diagram for removing all MMTel media (e.g. audio/video/messaging) from IMS data channel session between two UEs.

Reproduction of 3GPP TS 23.228, Fig. AC.10.2.5-1: Removing all MMTel Media from IMS data channel session

Figure AC.10.2.5-1: Removing all MMTel Media from IMS data channel session

Step 1.

An IMS DC session has been established between the UE-A and the UE-B, which includes MMTel and application DC media.

Step 2.

The UE-A sends SIP re-INVITE request with an SDP offer containing media information for MMTel media and application data channel, which sets the port number of MMTel media stream to zero, as specified in RFC 3264.

Step 3.

The IMS AS, the DCSF and the UE-B handles the SIP re-INVITE request as specified in steps 2-9 of clause AC.7.2.1.

Step 4.

If the UE-B accepts the session update, the UE-B sends 200 OK response to the UE-A through the IMS AS, as specified in steps 10-18 of clause AC.7.2.1, indicating the MMTel media has been removed.