Content for TS 23.228 Word version: 18.5.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.9…

AC.7 Data Channel Procedures AC.7.0 IMS DC capability negotiation AC.7.1 Bootstrap Data Channel Setup Signalling procedure
...

AC.7 Data Channel Procedures p. 372

AC.7.0 IMS DC capability negotiation p. 372

The IMS network and the UE need to mutually negotiate the capability of supporting IMS data channel when a UE supporting IMS data channel registers to IMS network.

IMS data channel capability negotiation includes two aspects:

The network discovers the data channel capability of the UE.
The UE discovers the data channel capability of the network.

When the UE supporting IMS data channel registers on the IMS network and the UE is allowed to use IMS data channel as specified in clause AC.4, it includes the media feature tag as specified in TS 26.114 in the Contact header field of the initial REGISTER request and any subsequent REGISTER request to allow the home IMS network to discover its IMS data channel capability.

If the IMS network supports IMS data channel, the S-CSCF includes a Feature-Caps header field indicating its data channel capability in the 200 OK response to the initial and any subsequent REGISTER request as specified in clause 9.2 of TS 24.186, which is used by the UE to discover the IMS data channel capability of its home IMS network.

The UE may receive a Feature-Caps header field indicating its data channel capability in the 200 OK response to a subsequent REGISTER request when the network starts supporting IMS data channel after successful initial registration of the UE.

When the UE supporting IMS data channel initiates an IMS session, and if the UE is allowed to use IMS data channel as specified in clause AC.4, it includes the media feature tag as specified in TS 26.114 in the Contact header field of the initial INVITE or any re-INVITE request message, regardless of data channel media being part of the SDP or not.

The UE shall not include the media feature tag as specified in TS 26.114 in the Contact header field and data channel media description in the SDP offer of the initial INVITE request or any subsequent re-INVITE request message, if the S-CSCF has not included the data channel capability indication in the Feature-Caps header field in the 200 OK response either to the initial REGISTER or a subsequent REGISTER request message.

If the UE is not configured whether to use IMS data channel, it is up to UE implementation whether or not to include the media feature tag in the Contact header field.

AC.7.1 Bootstrap Data Channel Setup Signalling procedure p. 372

Figure AC.7.1-1depicts a signalling flow diagram for establishing a bootstrap data channel in a person-to-person use case. The MF anchors the bootstrap data channel, and the originating network is offering a bootstrap data channel to the remote peer as well for application download.

In the call flow the two UEs have already established an IMS audio session, and the originating UE is updating the IMS audio/video session to an IMS data channel session.

Reproduction of 3GPP TS 23.228, Fig. AC.7.1-1: Bootstrap Data Channel set up Signalling Procedure

Figure AC.7.1-1: Bootstrap Data Channel set up Signalling Procedure

The steps in the call flow are as follows:

Step 1.

UE#1 sends the SIP INVITE request with an initial SDP to the IMS AS, through P-CSCF and S-CSCF in the originating network. The initial SDP contains offers for the bootstrap data channel establishment request with bootstrap DC stream ID. In this example procedure, the SDP contains both bootstrap data channel offers for originating side and terminating side.

Step 2.

IMS AS validates user subscription data to determine whether the data channel call request should be notified to DCSF.

If the IMS AS determined, based on the user profile, that data channel call request needs to be notified to DCSF, the IMS AS selects a DCSF for this user based on local configuration or discovery and selection of a DCSF instance via NRF.

If the IMS AS determined, based on the user profile, that the data channel call request need not to be notified to DCSF, or DCSF decides that DC request is not allowed, the IMS AS proceeds with normal IMS procedures to setup the MMTel session without performing Data Channel bootstrapping, by deleting DC related media information and sending the updated SIP INVITE to the originating S-CSCF.

Step 3.

IMS AS notifies the DCSF of the DC call event by sending Nimsas_SessionEventControl_Notify (SessionEstablishmentRequestEvent, Session ID, Calling ID, Called ID, Session Case, Event initiator, Media InfoList, DC Stream ID) request to the DCSF.

Step 4.

After receiving the DC control request, the DCSF determines the policy about how to process the bootstrap data channel establishment request based on the related parameters in the Data Channel control request (e.g. CallingID, CalledID, DC Stream ID) and/or DCSF service specific policy.

Step 5.

Since the SessionEstablishmentRequestEvent indicates that served user is offered local bootstrap media, DCSF, based on its policies reserves originating side MDC1 media information, as well as the terminating side MDC1 remote bootstrap media (targeting remote UE), which are used to receive UE request for application downloading from MF or MRF.

Step 6.

DCSF invokes the Nimsas_MediaControl_MediaInstruction (Session ID, Media Instruction Set) operation based on its policies instructing the IMS AS how to set up bootstrap data channel with MF both for originating and terminating 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.

In this scenario, the DCSF instructs the IMS AS to terminate bootstrap data channel establishment request on originating MF, and initiate remote bootstrap data channel establishment request(targeting remote UE) as well as forwarding remote bootstrap data channel establishment request of served user (targeting remote DCSF) towards terminating network.

Step 7.

The IMS AS selects a MF based on local configuration or discovers and selects a MF instance or MRF supporting DC media function via NRF.

Step 8.

IMS AS invokes Nmf_MRM_Create(List of Media Termination Descriptors) service operation to instruct MF to allocate required data channel media resources. IMS AS request creation of two different Media Terminations, one representing the local bootstrap media to be terminated and the other representing the remote bootstrap media to be offered to remote UE. Each Media Termination includes information required to allocate resources in both Mb and the MDC1 interfaces. The MF responds with the negotiated data channel media resource information to IMS AS. If MRF is used, IMS AS uses Mr'/Cr to the MRF to reserve data channel media resources.

Step 9.

IMS AS responds to the MediaInstruction request received in step 6. The response may include the atomic success result of operation and also includes negotiated data channel media resource information for MDC1.

Step 10.

The DCSF stores the media resource information and responds to the Notify Request received in step 3.

Step 11-13.

IMS AS sends the INVITE which includes the updated SDP offer adding media information of MF or MRF via the originating S-CSCF to remote network side and UE#2. In this scenario, the SDP offer for bootstrap data channel to UE#2 is included.

Step 14.

UE#2 and terminating network returns an 18X response with the SDP answer to bootstrap data channel to originating network. According to the received SDP answer, IMS AS may instruct MF or MRF to update data channel media resource information for UE#2.

Step 15-16.

UE#2 and terminating network returns a 200 OK response.

Step 17.

The IMS AS notifies the successful session establishment event, Nimsas_SessionEventControl Notify (SessionEstablishmentSuccessEvent, Session ID, Media Info List) to DCSF.

Step 18.

The DCSF responds to the Nimsas notification request.

Step 19.

200 OK forwarded to UE#1 which indicates the bootstrap data channel has been established.

Step 20.

The originating network P-CSCF executes QoS procedure for bootstrap data channel as specified in TS 23.203 and TS 23.503.

Step 21-24.

The bootstrap data channels have been established between originating MF or MRF and UE#1/UE#2. The UEs send application request messages to MF or MRF to request a data channel application or an application list if multiple DC applications are available, via the established bootstrap data channel with its data channel capabilities. The MF or MRF replaces the root URL with the replacement URL received in steps 8 and forwards the message to received media point of DCSF. The DCSF provides the application list and proper data channel applications further to UE#1 and UE#2 based on their data channel capabilities and their choices through MF or MRF.

The bootstrap data channels have also been established between terminating MF or MRF and UE#1/UE#2. The data channel application is requested and downloaded to UE#1 and UE#2 from terminating DCSF

Steps 20-24 may be executed after step 14, if the SDP answer in 200 OK to the PRACK and UPDATE messages contain the information required to establish bootstrap data channels.

Step 25.

Subsequent procedures continue.