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

AC.7.4 NF service registration and discovery AC.7.4.1 DCSF Registration and Discovery AC.7.4.2 MF Registration and Discovery AC.7.5 Providing subscriber specific graphical user interface to the UE AC.7.6 Termination of IMS Data Channel AC.7.7 QoS requirement of IMS Data Channel AC.7.9 IMS data channel setup Signalling Procedure for interworking with MTSI UE AC.7.9.1 Bootstrap Data Channel Setup Signalling Procedure AC.7.9.2 Signalling Procedure of Application Data Channel Interworking via MF AC.7.9.3 Signalling Procedure of Application Data Channel Interworking via DC AS
...

AC.7.4 NF service registration and discovery p. 383

If the NRF is used for NF registration and discovery, the DCSF and the MF shall register their services at the NRF before providing services to consumers, and existing NRF based mechanism needs to be extended with DC specific profiles according to clause 4.17.1 of TS 23.502.

AC.7.4.1 DCSF Registration and Discovery p. 383

The DCSF profile includes NF type=DCSF and may include IMPU ranges for calling identities or called identities of users it serves.

The DCSF can update and deregister in the NRF after registration and the procedures are specified in clauses 4.17.2 and 4.17.3 of TS 23.502.

After registration in the NRF, the DCSF can be discovered by other consumer NFs as specified in clauses 4.17.4 and 4.17.5 of TS 23.502.

AC.7.4.2 MF Registration and Discovery p. 383

The MF profile includes NF type=MF and may include MF location information to select a local MF to minimize transmission delays in the media path.

The MF can update and deregister in the NRF after registration and the procedures are specified in clauses 4.17.2 and 4.17.3 of TS 23.502.

After registration in the NRF, the MF and its services can be discovered by other consumer NFs as specified in clauses 4.17.4 and 4.17.5 of TS 23.502.

AC.7.5 Providing subscriber specific graphical user interface to the UE p. 383

According to clause 6.2.10.1 of TS 26.114, the UE can send a HTTP GET Request for the root ("/") URL through the bootstrap data channel which is replied with a data channel application describing the graphical user interface and the logic needed to handle any further data channel usage beyond the bootstrap data channel itself. The graphical user interface can e.g. contain a menu of applications, from which the user can choose one or several. The graphical user interface should be subscriber specific and contain only applications for which the user has subscribed to and is authorized to use. To provide the graphical user interface containing subscriber specific data channel applications via the bootstrap data channel to the UE, the DCSF, when receiving a call event notification including subscriber specific information and optionally stream ID from the IMS AS, creates the URL identifying the graphical user interface corresponding to the stream ID (if available) for this subscriber.

AC.7.6 Termination of IMS Data Channel p. 383

When a bootstrap data channel is established successfully, the bootstrap data channel shall be kept available during the IMS MMTel session, and it shall be terminated along with the release of the call.

The application data channel shall be terminated along with the release of the call or be terminated by closing this application separately. In the latter case, the UE triggers a SDP negotiation to release the application data channel.

The termination of application data channel shall not have any impact on the audio or video within the IMS sessions.

AC.7.7 QoS requirement of IMS Data Channel p. 383

The appropriate 5QI/QCI for the QoS flows of the IMS data channel media, as defined in TS 26.114, shall be applied over the 5GS system or EPS system for IMS data channel.

AC.7.8 Void

AC.7.9 IMS data channel setup Signalling Procedure for interworking with MTSI UE |R19| p. 384

AC.7.9.1 Bootstrap Data Channel Setup Signalling Procedure p. 384

Figure AC.7.9.1-1 depicts a signalling flow diagram for establishing a bootstrap data channel when the originating DCMTSI UE initiates an IMS DC session to the terminating MTSI UE.

Reproduction of 3GPP TS 23.228, Fig. AC.7.9.1-1: Bootstrap Data Channel set up Signalling Procedure for IMS data channel interworking with MTSI UE

Figure AC.7.9.1-1: Bootstrap Data Channel set up Signalling Procedure for IMS data channel interworking with MTSI UE

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 SDP offers for the bootstrap data channel with bootstrap DC stream ID.

Step 2.

Data channel management procedure in originating network is executed as per step2~10 in Figure AC.7.1-1.

Step 3-4.

IMS AS sends the INVITE request to remote network with SDP containing data channel media for terminating network and UE #2.

Step 5-7.

UE#2 and terminating network returns bootstrap DC negotiation result to originating network. The port number of bootstrap data channel in the SDP answer is set to zero.

Step 8.

IMS AS requests MF to update the local DC media resources accordingly.

Step 9-11.

When IMS AS sends the bootstrap DC negotiation result to DCSF, since the port of bootstrap data channel for UE #2 is set to zero, the DCSF knows that the terminating network or UE #2 does not support or does not use IMS data channel in this session.

Step 12-18.

These procedures are same as step 14~20 in Figure AC.7.1-1.

Step 19.

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

Step 20.

The subsequent procedure applies.

AC.7.9.2 Signalling Procedure of Application Data Channel Interworking via MF p. 385

Figure AC.7.9.2-1 depicts a signalling flow diagram for establishing the application data channel when the originating DCMTSI UE initiates an IMS DC session to the terminating MTSI UE, providing interworking of application data channel to MTSI UE via MF. This signalling flow takes the data channel application Real-time Screen Sharing for instance.

Reproduction of 3GPP TS 23.228, Fig. AC.7.9.2-1: Application Data Channel set up signalling procedure for IMS data channel interworking with MTSI UE via MF

Figure AC.7.9.2-1: Application Data Channel set up signalling procedure for IMS data channel interworking with MTSI UE via MF

Step 1-3.

UE#1 initiates a re-INVITE request to establish an application data channel in which the application data channel and data channel application information (for instance, application ID) are contained. The IMS AS validates user subscription data to determine whether this request should be notified to the DCSF as stated in clause AC.7.2.

Step 4.

After receiving the request, the DCSF determines the policy about how to process the application data channel establishment request based on the related parameters (i.e. associated DC application binding information as application ID) in the notification and/or DCSF service specific policy.

Step 5-7.

Since the DCSF has known the terminating network or UE #2 does not support or does not use IMS data channel in this session, the DCSF determines that interworking of the application data channel media to MTSI UE is needed, based on the application information, i.e. application id. The DCSF invokes Nimsas_MediaControl_MediaInstruction to the IMS AS and instructs the IMS AS to create resources and association for the application data channels on originating side and video media on terminating side. And it also includes the instruction of how to transform data channel media to video media. The IMS AS invokes Nmf_MediaResourceManagement to the MF to allocate resource and transform data channel media to video media according to DCSF's instruction.

Step 8-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. The DCSF stores the media resource information and responds to the request received in step 3.

Step 10-11.

After the media resource reservation, the IMS AS sends a re-INVITE request with the SDP offer for anchoring the video media of UE#2 to the MF.

Step 12-14.

After terminating network side negotiation, UE#2 and terminating network returns 200 OK for the re-INVITE.

Step 15-16.

DCSF is notified about the terminating network media negotiation result.

Step 17-21.

The IMS AS sends 200 OK for re-INVITE initiated by UE#1 and UE#1 returns ACK.

Step 22.

UE#1 initiates SCTP association and DTLS connection establishment procedures and establishes the application data channels with the MF.

Step 23-24.

The IMS AS reports media negotiation result to the DCSF, and reports that anchoring video stream is successful. The DCSF sends a Call Control Request to the MMTel AS indicating it to continue the call process.

Step 25.

The IMS AS sends a Media Resource Management Request to the MF to associate application data channel stream between UE#1 and the MF with the allocated video streams between UE#2 and the MF.

The application data channels between the MF and UE#1 are associated with the RTP video streams between the MF and UE#2. The RTP stream of UE#1's screenshot sequence is received by UE#2 from video streams.

AC.7.9.3 Signalling Procedure of Application Data Channel Interworking via DC AS p. 387

Figure AC.7.9.3-1 depicts a signalling flow diagram for establishing an application data channel from DCMTSI UE to DC application server, providing interworking of application data channel to MTSI UE via DC application server.

In the call flow the UEs have already established an IMS audio session, and the DCMTSI UE (UE#1) wants to provide DC application data to MTSI UE (UE#2) during the call, such as transfer a file (e.g. a photo) to UE#2.

Reproduction of 3GPP TS 23.228, Fig. AC.7.9.3-1: Application Data Channel set up signalling procedure for IMS data channel interworking with MTSI UE via DC application server

Figure AC.7.9.3-1: Application Data Channel set up signalling procedure for IMS data channel interworking with MTSI UE via DC application server

The steps in the call flow are as follows:

Step 1.

DC AS subscribes to IMS AS the event that application DC for an DC application that requires interworking is established.

Step 2.

IMS session and bootstrap data channel have been established. Selected DC application(s) have been downloaded to UE#1.

The DCSF knows the UE#2 or terminating network does not support IMS DC based on procedure in clause AC.7.9.1.

Step 3-5.

The UE#1 initiates a P2P application DC. Steps 1-2 of clause AC.7.2.1 applies.

Step 6.

After receiving the session event notification, the DCSF determines that IMS DC interworking for the requested DC application is required based on the application information, i.e. application id. Since the remote network or UE#2 does not support IMS DC, the DCSF changes P2P application DC to P2A application DC.

Step 7-16.

The DCSF instructs the MF via the IMS AS to establish the media resource of the P2A application DC and the DC connection is established between UE and the DC AS. Steps 5-14 of clause AC.7.2.2 applies.

Step 17.

IMS AS sends the event notification to indicate the DC AS that the interworking should be perform for UE#2.

Step 18-19.

IMS AS sends the re-INVITE to remote network side and UE#2,which does not include bootstrap data channel information and application data channel media components in the SDP.

Step 20-29.

Steps 17-26 of clause AC.7.2.2 applies.

Step 30.

UE#1 uses the established application data channel to provide DC application specific information to the DC AS, e.g. sends the file (e.g. a photo) which will be sent to UE#2 to DC AS.

Step 31.

DC AS performs interworking actions based on the notification received in step 17 and the data received in step 30.