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.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.4 NF service registration and discovery p. 390

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

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

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

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

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

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.