Tech-invite  3GPPspace  IETFspace
◀  ▶  21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.228  Word version:  19.4.0

Top   Top   Up   Prev   None
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… 
AG IMS Capability Exposure Framework in IMS  AG.1 Description  AG.2 IMS Data Channel capability exposure procedures  AG.2.1 Updating an existing IMS session  AG.2.2 Establishing IMS session with standalone Data Channel  AG.2.3 Terminating standalone Data Channel session  $ Change history 

 

AG (Normative)  IMS Capability Exposure Framework in IMS |R19|  p. 463

AG.1  Description  p. 463

The following scenarios utilizing IMS data channel capability exposure services are depicted in clause AG.2:
  • Adding, removing or updating the data channel to an existing IMS session, for which Nimsas_ImsSessionManagement_Update is used.
  • Creating a standalone data channel session, for which Nimsas_ImsSessionManagement_Create is used.
  • Terminating a standalone data channel session, for which Nimsas_ImsSessionManagement_Delete is used.
The procedures can be triggered via the NEF on the originating or terminating side.
The security and privacy for IMS capability exposure are specified in Annex Q of TS 33.328.
Up

AG.2  IMS Data Channel capability exposure procedures  p. 463

AG.2.1  Updating an existing IMS session  p. 463

AG.2.1.0  General  p. 463

This clause describes the procedure for adding, removing or updating bootstrap data channel(s) and application data channel(s) to an existing IMS session via dedicated NEF services.
The DC AS sends a request to the NEF via Nnef_ImsSessionManagement_Update to update an existing IMS session with a specific session ID with a data channel. The procedures of adding A2P, P2P and P2A2P application data channel(s) and adding bootstrap data channel(s) to an existing IMS session are provided below. For removing or updating application data channel(s) in an existing IMS session, as well as for removing, or updating bootstrap data channel(s) in an existing IMS session, the same principle applies.
If the IMS session management request is authorized, the IMS AS may include an indication of data channel initiator in the request to the UEs for user awareness.
Up

AG.2.1.1  Adding A2P Application Data Channel to an existing IMS session  p. 463

Figure AG.2.1.1-1 depicts the call flow of adding A2P application data channel(s) to an existing IMS session. In this scenario, the MF-2 is used to anchor the application data channel between the UE B and the DC AS.
Copy of original 3GPP image for 3GPP TS 23.228, Fig. AG.2.1.1-1: Procedure of adding A2P application data channel(s) to an existing IMS session
Figure AG.2.1.1-1: Procedure of adding A2P application data channel(s) to an existing IMS session
(⇒ copy of original 3GPP image)
Up
An IMS session between UE A and UE B has been established, a bootstrap DC has also been established and the DC AS has received the IMS session ID.
Step 0.
DC AS determines to add A2P application data channel(s) to an existing IMS session, e.g. based on the event notification of the related IMS session to which the DC AS subscribed to.
Step 1.
The DC AS sends a Nnef_ImsSessionManagement_Update request to the NEF requiring to add A2P application data channel(s) to the existing IMS session. The AF request contains the DC AS identifier as AF ID.
The DC AS includes the session ID of the existing IMS session to be updated, the operation type as Adding, media operation set including the parameters for the media type set as A2P ADC, the UE B as the target of the A2P ADC, the application binding information and the MDC2 media endpoint address (e.g. FQDN or IP address and port number) in Nnef_ImsSessionManagement_Update request. The DC AS may include a Notification Target Address and Correlation ID to the Nnef_ImsSessionManagement_Update request to be notified of the session update progress.
Step 2.
The NEF uses the Nhss_ImsUECM_AsInfoGet service operation to retrieve the IMS AS instance serving UE B.
Step 3.
The NEF sends a Nimsas_ImsSessionManagement_Update request to the IMS AS-2 requiring to add A2P application data channel(s) to the specific IMS session. The received session ID of the existing IMS session, the operation type as Adding, the media type as A2P ADC, the UE B as the target of the A2P ADC, the application binding information and the MDC2 media endpoint address shall be included in the request. The NEF may include a Notification Target Address and Correlation ID to the Nimsas_ImsSessionManagement_Update request to be notified of the session update progress.
Step 4.
The IMS AS-2 validates the user subscription data and checks the IMS DC capability of UE B and determines whether the data channel request should be notified to DCSF-2. If UE B does not have subscription of IMS data channel or does not have the IMS DC capability, then the request shall be rejected with appropriate cause and subsequent steps are skipped. If the IMS AS-2 allows the request to proceed, it returns a successful Nimsas_ImsSessionManagement_Update response to the NEF.
If the same IMS data channel is already established and if there are no other operations included in the request, then the request shall be rejected with an appropriate cause and the following steps are skipped.
Step 5.
The NEF returns a successful Nnef_ImsSessionManagement_Update response to the DC AS.
Step 6.
The IMS AS-2 sends a Nimsas_SessionEventControl_Notify request to the DCSF-2 with event set to ExternalSessionUpdateEvent. The notification includes the necessary parameters based on the information extracted from media operation set parameters received in step 3 and other stored parameters in the IMS AS-2 if applicable.
Step 7.
After receiving the session event control notification, the DCSF-2 determines the policy how to process the application data channel establishment request based on the related parameters in the notification and/or DCSF-2 service specific policy.
Step 8.
The DCSF-2 determines that the added application data channel media requires the DC to be anchored in MF-2.
Step 9.
The DCSF-2 instructs the IMS AS-2 to set up the A2P application data channel(s) by sending a Nimsas_MediaControl_MediaInstruction request.
Step 10.
Based on the instruction from DCSF-2, the IMS AS-2 interacts with the MF-2 to allocate data channel media resource towards UE B and MDC2 media resource towards DC AS.
The IMS AS-2 also requests MF-2 to update DC AS side MDC2 media resource information using the received MDC2 media endpoint address in step 3.
Step 11.
The IMS AS-2 may respond to Nimsas_MediaControl_MediaInstruction request.
Step 12.
The DCSF-2 may respond to Nimsas_SessionEventControl_Notify.
Step 13.
The IMS AS-2 generates a re-INVITE request(s) in which the SDP offer contains the media information of the data channel required by the DC AS, application binding information, the existing IMS session ID, together with the other existing media descriptions, with an indication that the DC AS initiated the re-INVITE request (see clause AG.2.1.0).
The IMS AS-2 sends the re-INVITE request(s) to the target UE B.
Step 14.
The UE B may download the corresponding DC application signalled in the SDP offer, if not done already and associate it with the requested application DC.
The UE-B decides from which BDC (if there is more than one BDC) to download the DC application based on application binding information.
Step 15.
The DC media negotiation is completed and corresponding data channel(s) are established. The UE B returns a 200 OK response with SDP answer for the application data channel(s).
Step 16.
The IMS AS-2 requests MF-2 to update UE B side media resource information based on the received SDP answer for the application data channel from the UE B.
Step 17.
The IMS AS-2 sends ACK to the UE-B.
Step 18.
If the DC AS included a Notification Target Address in the Nnef_ImsSessionManagement_Update request in step 1, the IMS AS-2 notifies the NEF on the progress of the session update with the Nimsas_ImsSessionManagement_Notify request. The MF-2 side MDC2 media information is included in the request.
Step 19.
The NEF notifies the DC AS on the progress of the session update with the Nnef_ImsSessionManagement_Notify request, including the MF-2 side MDC2 media information.
Step 20.
The DC AS updates its MF-2 side MDC2 media information and returns with Nnef_ImsSessionManagement_Notify response to the NEF.
Step 21.
The NEF returns a Nimsas_ImsSessionManagement_Notify response to the IMS AS-2.
Up

AG.2.1.2  Adding P2P Application Data Channel to an existing IMS session  p. 466

Figure AG.2.1.2-1 depicts the call flow of adding P2P application data channel(s) to an existing IMS session. In this scenario, the MF-2 is used to anchor the application data channel between the UE B and UE A.
Copy of original 3GPP image for 3GPP TS 23.228, Fig. AG.2.1.2-1: Procedure of adding P2P data channel(s) to an existing IMS session
Figure AG.2.1.2-1: Procedure of adding P2P data channel(s) to an existing IMS session
(⇒ copy of original 3GPP image)
Up
An IMS session between UE A and UE B has been established, the bootstrap DCs have also been established and the DC AS has received the IMS session ID.
Step 0.
DC AS may determine to add P2P application data channel(s) to an existing IMS session based on the event notification of the related IMS Session for which DC AS subscribed to.
Step 1.
The DC AS sends a Nnef_ImsSessionManagement_Update request to the NEF requiring to add P2P application data channel(s) in the existing IMS session. The AF request contains the DC AS identifier as AF ID.
The DC AS shall include session ID of the existing session, the operation type as Adding, the media type as P2P ADC and the application binding information in Nnef_ImsSessionManagement_Update request. The DC AS includes the media operation set parameters and may include UE B and UE A as the targets of the P2P ADC as well as a Notification Target Address and Correlation ID to the Nnef_ImsSessionManagement_Update request to be notified for the progress of the session update.
Step 2.
The NEF uses the Nhss_ImsUECM_AsInfoGet service operation to retrieve the IMS AS instance serving the UE B.
Step 3.
The NEF sends a Nimsas_ImsSessionManagement_Update request to the IMS AS-2 requiring to add P2P application data channel(s) in the specific session. The received IMS session ID of the existing session, the operation type as Adding, the media type as P2P ADC and the application binding information are included in the request. The NEF may include UE B and UE A as the targets of the P2P ADC, as well as a Notification Target Address and Correlation ID to the Nimsas_ImsSessionManagement_Update request to be notified on the progress of the session update.
Step 4.
The IMS AS-2 validates the user subscription data and checks the IMS DC capability of UE B and determines whether the data channel request should be notified to DCSF-2. If the UE B does not have subscription for IMS data channel or does not have the IMS DC capability, then the request shall be rejected with an appropriate cause and the subsequent steps are skipped. If the IMS AS-2 allows the request to proceed, it returns a successful Nimsas_ImsSessionManagement_Update response to the NEF.
If the same IMS data channel is already established and if there are no other operations included in the request, then the request shall be rejected with an appropriate cause and the subsequent steps are skipped.
Step 5.
The NEF returns a successful Nnef_ImsSessionManagement_Update response to the DC AS.
Step 6.
The IMS AS-2 sends a Nimsas_SessionEventControl_Notify request to the DCSF-2 with event set to ExternalSessionUpdateEvent. The notification includes the necessary parameters based on the information extracted from media operation set parameters received in step 3 and other stored parameters in the IMS AS-2 if applicable.
Step 7.
After receiving the session event control notification, the DCSF-2 determines the policy how to process the application data channel establishment request based on the related parameters in the notification and/or DCSF-2 service specific policy.The DCSF-2 determines that the added application data channel requires the DC to be anchored in the MF-2.
Step 8.
The DCSF-2 instructs the IMS AS-2 to set up the P2P application data channel(s) by sending a Nimsas_MediaControl_MediaInstruction request.
Step 9.
Based on the instruction from DCSF-2, the IMS AS-2 interacts with the MF-2 to allocate data channel media resources towards UE B and UE A.
Step 10.
The IMS AS-2 may respond to Nimsas_MediaControl_MediaInstruction request.
Step 11.
The DCSF-2 may respond to Nimsas_SessionEventControl_Notify.
Step 12.
The IMS AS-2 generates a re-INVITE request(s) in which the SDP offer contains the media information of the data channel, application binding information, the existing IMS session ID, together with the other existing media descriptions, with an indication that the DC AS initiated the re-INVITE request (see clause AG.2.1.0).
The IMS AS-2 sends the re-INVITE request(s) to the target UE B.
Step 13.
The UE B may need to download the corresponding DC Application signalled in the SDP offer, if not done already and associate it with the requested application DC.
The UE-B decides from which BDC (if there is more than one BDC) to download the DC application based on application binding information.
Step 14.
The DC media negotiation is completed. The UE B returns a 200 OK response with SDP answer for the application data channel.
Step 15.
The IMS AS-2 generates a re-INVITE request(s) in which the SDP offer contains the media information of the data channel, application binding information, the existing IMS session ID, together with the other existing media descriptions, with an indication that the DC AS initiated the re-INVITE request (see clause AG.2.1.0).
The IMS AS-2 sends the re-INVITE request(s) to the target UE A.
Step 16.
The UE A may need to download the corresponding DC Application signalled in the SDP offer, if not done already and associate it with the requested application DC.
The UE-A decides from which BDC (if there is more than one BDC) to download the DC application based on application binding information.
Step 17.
The DC media negotiation is completed. UE A returns a 200 OK response with SDP answer for the application data channel.
Step 18.
The IMS AS-2 requests MF-2 to update UE B side and UE A side media resource information based on the received SDP answer for the application data channel from UE B and UE A.
Step 19.
The IMS AS-2 sends ACK to the UE-B and UE A.
Step 20.
If the DC AS included a Notification Target Address in the Nnef_ImsSessionManagement_Update request in step 1, the IMS AS-2 notifies the NEF for the progress of the session update with the Nimsas_ImsSessionManagement_Notify request.
Step 21.
The NEF notifies the DC AS for the progress of the session update with the Nnef_ImsSessionManagement_Notify request.
Step 22.
The DC AS may return a Nnef_ImsSessionManagement_Notify response to the NEF.
Step 23.
The NEF may return a Nimsas_ImsSessionManagement_Notify response to the IMS AS-2.
Up

AG.2.1.3  Adding P2A2P Application Data Channel to an existing IMS session  p. 468

Figure AG.2.1.3-1 depicts the call flow of adding P2A2P application data channel(s) to an existing IMS session. In this scenario, the MF-2 is used to anchor the application data channel between the UE B, the UE A and the DC AS.
Copy of original 3GPP image for 3GPP TS 23.228, Fig. AG.2.1.3-1: Procedure of adding P2A2P data channel(s) to an existing IMS session
Figure AG.2.1.3-1: Procedure of adding P2A2P data channel(s) to an existing IMS session
(⇒ copy of original 3GPP image)
Up
An IMS session between UE A and UE B has been established, bootstrap DCs have also been established and the DC AS has received the IMS session ID.
Step 0.
DC AS determines to add P2A2P application data channel(s) to an existing IMS session, e.g. based on the event notification of the related IMS Session to which DC AS subscribed to.
Step 1.
The DC AS sends a Nnef_ImsSessionManagement_Update request to the NEF requiring adding P2A2P application data channel(s) in the existing IMS session. The DC AS shall include session ID of the existing session, the operation type as Adding, the media type as P2A2P ADC, the application binding information and the MDC2 media endpoint address (e.g. FQDN or IP address and port number) in Nnef_ImsSessionManagement_Update request. The DC AS includes the media operation set parameters and may include UE B and UE A as the targets of the P2A2P ADC, as well as a Notification Target Address and Correlation ID to the Nnef_ImsSessionManagement_Update request to be notified on the progress of the session update. The AF request contains the DC AS identifier as AF ID.
Step 2.
The NEF uses the Nhss_ImsUECM_AsInfoGet service operation to retrieve the IMS AS instance serving the UE B.
Step 3.
The NEF sends a Nimsas_ImsSessionManagement_Update request to the IMS AS-2 requiring to add P2A2P application data channel(s) in the specific session. The received session ID of the existing session, the operation type as Adding, the media type as P2A2P ADC, the application binding information and the MDC2 media endpoint address shall be included in the request. The NEF may include UE B and UE A as the targets of the P2A2P ADC, as well as a Notification Target Address and Correlation ID to the Nimsas_ImsSessionManagement_Update request to be notified for the progress of the session update.
Step 4.
The IMS AS-2 validates the user subscription data and checks the IMS DC capability of UE B and determines whether the data channel request should be notified to DCSF-2. If the UE B does not have subscription of IMS data channel or does not have the IMS DC capability, then the request shall be rejected with appropriate cause and the subsequent steps are skipped. If the IMS AS-2 allows the request to proceed, it returns a successful Nimsas_ImsSessionManagement_Update response to the NEF.
If the same IMS data channel is already established and if there are no other operations included in the request, then the request shall be rejected with an appropriate cause and the subsequent steps are skipped.
Step 5.
The NEF returns a successful Nnef_ImsSessionManagement_Update response to the DC AS.
Step 6.
The IMS AS-2 sends a Nimsas_SessionEventControl_Notify request to the DCSF-2 with event set to ExternalSessionUpdateEvent. The notification includes necessary parameters based on the information extracted from Media operation set parameters received in step 3 and other stored parameters in the IMS AS-2 if applicable.
Step 7.
After receiving the session event notification, the DCSF-2 determines the policy how to process the application data channel establishment request based on the related parameters in the notification and/or DCSF-2 service specific policy. The DCSF-2 determines that the added application data requires to anchor the DC in the MF-2.
Step 8.
The DCSF-2 instructs the IMS AS-2 to set up the P2A2P application data channel(s) by sending a Nimsas_MediaControl_MediaInstruction request.
Step 9.
Based on the instruction from DCSF-2, the IMS AS-2 interacts with the MF-2 to allocate data channel media resource towards UE B and UE A and the originating and terminating MDC2 media resource towards DC AS.The IMS AS-2 requests MF-2 to update DC AS side MDC2 media resource information using the received MDC2 media endpoint address (e.g. FQDN or IP address and port number) in step 3.
Step 10.
The IMS AS-2 may respond to Nimsas_MediaControl_MediaInstruction request.
Step 11.
The DCSF-2 may respond to Nimsas_SessionEventControl_Notify.
Step 12.
The IMS AS-2 generates a re-INVITE request(s) in which the SDP offer contains the media information of the data channel, application binding information, the existing session ID, together with the existing media descriptions, with an indication that the DC AS initiated the re-INVITE request (see clause AG.2.1.0).
The IMS AS-2 sends the re-INVITE request(s) to the target UE B.
Step 13.
The UE B may need to download the corresponding DC Application signalled in the SDP offer, if not done already and associate it with the requested application DC.
The UE-B decides from which BDC (if there is more than one BDC) to download the DC application based on application binding information.
Step 14.
The DC media negotiation is completed. The UE B returns a 200 OK response with SDP answer for the application data channel.
Step 15.
The IMS AS-2 generates a re-INVITE request(s) in which the SDP offer contains the media information of the data channel, application binding information, the existing session ID with the existing media descriptions, with an indication that the DC AS initiated the re-INVITE request (see clause AG.2.1.0).
The IMS AS-2 sends the re-INVITE request(s) to the target UE A.
Step 16.
The UE A may need to download the corresponding DC Application signalled in the SDP offer, if not done already and associate it with the requested application DC.
The UE-A decides from which BDC (if there is more than one BDC) to download the DC application based on application binding information.
Step 17.
The DC media negotiation is completed. The UE A returns a 200 OK respond with SDP answer for the application data channel.
Step 18.
The IMS AS-2 requests MF-2 to update UE B side and UE A side media resource information based on the received SDP answer for the application data channel from UE B and UE A.
Step 19.
The IMS AS-2 sends ACK to the UE-B and UE A.
Step 20.
If the DC AS included a Notification Target Address in the Nnef_ImsSessionManagement_Update request in step, the IMS AS-2 notifies the NEF for the progress of the session update with the Nimsas_ImsSessionManagement_Notify request. The MF-2 side originating and terminating MDC2 media information is included in the request.
Step 21.
The NEF notifies the DC AS for the progress of the session update with the Nnef_ImsSessionManagement_Notify request, including the MF-2 side originating and terminating MDC2 media information.
Step 22.
The DC AS updates its MF-2 side originating and terminating MDC2 media information, returns a Nnef_ImsSessionManagement_Notify response to the NEF.
Step 23.
The NEF returns a Nimsas_ImsSessionManagement_Notify response to the IMS AS-2.
Up

AG.2.1.4  Adding Bootstrap Data Channel to an existing IMS session  p. 471

Figure AG.2.1.4-1 depicts the call flow for adding bootstrap data channel towards UE B to an existing IMS session. In this scenario, the MF-2 is used to anchor the bootstrap data channel between UE B and DCSF2.
Copy of original 3GPP image for 3GPP TS 23.228, Fig. AG.2.1.4-1: Procedure of adding bootstrap data channel to an existing IMS session
Figure AG.2.1.4-1: Procedure of adding bootstrap data channel to an existing IMS session
(⇒ copy of original 3GPP image)
Up
An IMS voice session between UE A and UE B has been established.
Step 0.
DC AS decides to add a bootstrap DC to the existing IMS session, which is notified based on the event notification of the related IMS session to which the DC AS subscribed to.
Step 1.
The DC AS sends a Nnef_ImsSessionManagement_Update request to the NEF requiring to add a bootstrap data channel to the existing IMS session.
The DC AS includes its own identity as the AF Identifier, the session ID of the existing IMS session to be updated, the operation type as Adding, media operation set including the parameters for the media type set as BDC, the UE B as the target of the BDC, in the Nnef_ImsSessionManagement_Update request. The DC AS may include a Notification Target Address and Correlation ID in the Nnef_ImsSessionManagement_Update request to be notified of the session update progress.
Step 2.
If the NEF authorizes the request, the NEF uses the Nhss_ImsUECM_AsInfoGet service operation to retrieve the IMS AS instance serving UE B.
Step 3.
The NEF sends a Nimsas_ImsSessionManagement_Update request to the IMS AS-2 to add a BDC to the specific IMS session. The received session ID of the existing IMS session, the operation type as Adding, the media type as BDC, the UE B as the target of the BDC, and the MDC1 media endpoint address shall be included in the request. The NEF may include a Notification Target Address and Correlation ID to the Nimsas_ImsSessionManagement_Update request to be notified of the session update progress.
Step 4.
The IMS AS-2 determines whether the BDC request should be notified to DCSF-2 based on subscription information and DC capability of UE B. If UE B does not have subscription of IMS data channel or does not have the IMS DC capability, or then the request shall be rejected with appropriate cause and subsequent steps are skipped. If the IMS AS-2 allows the request to proceed, it returns a successful Nimsas_ImsSessionManagement_Update response to the NEF.
If the bootstrap DC is already established, the request shall be rejected with an appropriate cause and the following steps are skipped.
Step 5.
The NEF returns a successful Nnef_ImsSessionManagement_Update response to the DC AS.
Step 6.
The IMS AS-2 sends a Nimsas_SessionEventControl_Notify request to the DCSF-2 with event set to ExternalSessionUpdateEvent. The notification includes the necessary parameters based on the information extracted from media operation set parameters received in step 3 and other stored parameters in the IMS AS-2 if applicable.
Step 7.
Steps 7 to 10 in clause AC.7.1 applies with the following exception:
  • The data channel media resource in MF-2 is allocated only for UE B.
Step 8.
The IMS AS-2 generates a re-INVITE request in which the SDP offer contains the media information of the bootstrap data channel and existing voice media and sends the request to UE B.
Step 9.
UE B responds 200 OK with SDP answer.
Step 10.
Steps 17 to 18 in clause AC.7.1 applies.
Step 11.
IMS AS sends ACK to UE B to complete the IMS session modification procedure.
Step 12.
If the NEF included a Notification Target Address in the Nimsas_ImsSessionManagement_Update request in step 3, the IMS AS-2 notifies the NEF MediaChangeSuccess event with the Nimsas_ImsSessionManagement_Notify request.
Step 13.
If the DC AS included a Notification Target Address in the Nnef_ImsSessionManagement_Update request in step 3, the NEF notifies the DS AS MediaChangeSuccess event with the Nnef_ImsSessionManagement_Notify request.
Step 14-15.
The DC AS and NEF return responses.
Up

AG.2.2  Establishing IMS session with standalone Data Channel  p. 473

AG.2.2.0  General  p. 473

This clause describes the procedures of establishing an IMS session with standalone bootstrap data channel(s) and standalone A2P application data channel(s) via dedicated NEF services. The DC AS sends a Nnef_ImsSessionManagement_Create request to the NEF to establish an IMS session with standalone data channel(s).

AG.2.2.1  Establishing an IMS session with a standalone bootstrap data channel  p. 473

Figure AG.2.2.1-1 shows the establishment procedure of a standalone data channel session.
Copy of original 3GPP image for 3GPP TS 23.228, Fig. AG.2.2.1-1: Establishment procedure of a standalone BDC session
Figure AG.2.2.1-1: Establishment procedure of a standalone BDC session
(⇒ copy of original 3GPP image)
Up
Step 0.
The DC AS decides to establish a standalone data channel session between UE A and UE B. A standalone data channel can be a standalone bootstrap or standalone application data channel. This call flow describes the case of a standalone bootstrap data channel.
Step 1.
The DC AS sends a Nnef_ImsSessionManagement_Create request to the NEF to create a standalone DC session with UE A. The request includes calling ID (UE A), called ID (UE B), media information set including the instructions for the BDC, associated with the standalone IMS DC session and the DC AS identifier as AF ID.
The DC AS may include a Notification Target Address and Correlation ID to the Nnef_ImsSessionManagement_Create request to be notified for the progress of the session update.
Step 2.
The NEF queries the HSS for the address of the IMS AS serving the UE B if needed. If the UE B is unregistered, that is, the HSS fails to return the address of IMS AS, the NEF shall reject the Nnef_ImsSessionManagement_Create request from the DC AS with an error response and the subsequent steps are skipped.
Step 3.
The NEF sends a Nimsas_ImsSessionManagement_Create request to the IMS AS-2 requiring to create a standalone DC session.
Step 4.
The IMS AS-2 validates the user subscription data and checks the IMS DC capability of UE to determine whether the data channel request should be notified to DCSF-2. If the user B does not have subscription for IMS data channel, then the request shall be rejected with appropriate cause. If the IMS AS-2 allows the request to proceed, it returns a successful Nimsas_ImsSessionManagement_Create response to the NEF including a Session ID.
Step 5.
The NEF returns a successful Nnef_ImsSessionManagement_Create response to the DC AS.
Step 6.
If the IMS AS-2 allows the request to proceed, the IMS AS-2 sends a Nimsas_ImsSessionEventControl_Notify request to the DCSF-2 with event set to ExternalSessionCreateEvent. The notification includes the necessary parameters based on the information extracted from parameters received in step 3.
The DCSF-2 instructs the IMS AS-2 to set up the data channel by sending a Nimsas_MediaControl_MediaInstruction request. The IMS AS-2 interacts with the MF-2 to allocate data channel resource. The procedures in clause AC.7 are reused to interact with MF.
The Nimsas_MediaControl_MediaInstruction request instructs the IMS AS to originate the indicated data channel(s) from the MF-2 using the MDC1 and/or MDC2 media endpoint address(es) as included in the Nimsas_ImsSessionManagement_Create request.
Step 7.
The IMS AS-2 generates INVITE request(s) in which the SDP offer contains the media information of the data channel(s) required by the DC AS. The IMS AS-2 uses the calling and called parties as indicated in the Nimsas_SessionManagement_Create request in step 3 as targets when sending the INVITE requests.
The IMS AS-2 sends the INVITE request(s) according to the IMS DC session establishment procedures described in clauses AC.7.1 and AC.7.2 to UE A and UE B with the SIP header "display-name" indicating that IMS AS-2 sends the INVITE request on behalf of the callee.
Step 8.
The DC media negotiation is completed and corresponding data channel are established.
Step 9.
The IMS AS-2 notifies the DCSF for the IMS session events with the Nimsas_SessionEventControl_Notify service operation as described in clause AC.7.
Step 10.
If the NEF included a Notification Target Address to the Nimaas_ImsSessionManagement_Create request in step 3, the IMS AS-2 notifies the NEF for the progress of the session creation with the Nimsas_ImsSessionManagement_Notify request.
Step 11.
The NEF notifies the DC AS for the progress of the session creation with the Nnef_ImsSessionManagement_Notify request.
Step 12.
The DC AS returns the Nnef_ImsSessionManagement_Notify response to the NEF.
Step 13.
The NEF returns the Nnef_ImsSessionManagement_Notify response to the IMS AS-2.
Up

AG.2.2.2  DC AS initiated IMS session establishment with a standalone A2P application data channel  p. 475

Figure AG.2.2.2-1 depicts the call flow of establishing an IMS session with a standalone A2P application data channel between the DC AS and UE A.
Copy of original 3GPP image for 3GPP TS 23.228, Fig. AG.2.2.2-1: Establishment procedure of an IMS session with a standalone A2P application data channel
Figure AG.2.2.2-1: Establishment procedure of an IMS session with a standalone A2P application data channel
(⇒ copy of original 3GPP image)
Up
Step 0.
The DC AS decides to establish an IMS session with a standalone A2P application data channel with UE A.
Step 1.
The DC AS sends a Nnef_ImsSessionManagement_Create request to the NEF requiring to create an IMS session with a standalone A2P application DC with UE A.
The DC AS sends the media operation set including the parameters for the media type set as A2P ADC and the UE A as the target of the ADC to NEF. The DC AS may include a Notification Target Address and Correlation ID to the Nnef_ImsSessionManagement_Create request to be notified for the progress of the session creation.
Step 2.
If the NEF authorizes the request, the NEF queries the HSS with Nhss_ImsUECM_AsInfoGet service operation to retrieve the IMS AS instance serving UE A.
Step 3.
The NEF sends a Nimsas_ImsSessionManagement_Create request to the IMS AS-1 requiring to create an IMS session with a standalone A2P application DC. The media operation set includes the parameters for the media type set as A2P ADC and the UE A as the target of the A2P ADC. The NEF may include a Notification Target Address and Correlation ID to the Nimsas_ImsSessionManagement_Create request to be notified of the session create progress.
Step 4.
The IMS AS-1 validates the user subscription data and checks the IMS DC capability of UE A to determine whether the data channel request should be notified to DCSF-1. If UE A does not have subscription of IMS data channel or does not have the IMS DC capability, then the request shall be rejected with appropriate cause and the subsequent steps are skipped. If the IMS AS-1 allows the request to proceed, it returns a successful Nimsas_ImsSessionManagement_Create response to the NEF.
Step 5.
The NEF returns a successful Nnef_ImsSessionManagement_Create response with the session ID generated by the IMS AS-1 to the DC AS.
Step 6.
The IMS AS-1 sends a Nimsas_SessionEventControl_Notify request to the DCSF-1 with event set to ExternalSessionCreateEvent. The notification includes the necessary parameters based on the information extracted from the media operation set received in step 3 and other stored parameters in the IMS AS-1 if applicable.
Step 7.
After receiving the session event control notification, the DCSF-1 determines the policy how to process the A2P application data channel establishment request based on the related parameters in the notification and/or DCSF-1 service specific policy.
Step 8.
The DCSF-1 determines that the standalone A2P application data channel media requires the DC to be anchored in MF-1.
Step 9.
The DCSF-1 instructs the IMS AS-1 to set up the standalone A2P application data channel by sending a Nimsas_MediaControl_MediaInstruction request.
Step 10.
Based on the instruction from DCSF-1, the IMS AS-1 interacts with the MF-1 to allocate data channel media resource towards UE A and MDC2 media resource towards the DC AS.
Step 11.
The IMS AS-1 returns the Nimsas_MediaControl_MediaInstruction response to the DCSF-1.
Step 12.
The DCSF-1 returns the Nimsas_SessionEventControl_Notify response to the IMS AS-1.
Step 13.
The IMS AS-1 generates an INVITE request in which the SDP offer contains the media information of the standalone A2P application data channel required by the DC AS, binding information and the session ID.
The IMS AS-1 sends the INVITE request to UE A.
If UE A has not downloaded the DC application specified in binding information, then the UE A needs to download the DC Application.
The UE-A decides from which BDC (if there is more than one BDC) to download the DC application based on application binding information.
Step 14.
DC media negotiation may be completed through 18X/PRACK/200 OK(PRACK)/200 OK(INVITE)/ACK procedure.
Step 15.
The IMS AS-1 requests MF-1 to update DC AS side media resource information.
Step 16.
UE A runs the DC application specified in binding information and establish the standalone A2P application data channel with the DC AS.
Step 17.
If the NEF included a Notification Target Address in the Nimsas_ImsSessionManagement_Create request in step 3, the IMS AS-1 notifies the NEF for the progress of the session creation with the Nimsas_ImsSessionManagement_Notify request.
Step 18.
If the DC AS included a Notification Target Address in the Nnef_ImsSessionManagement_Create request in step 1, the NEF notifies the DC AS for the progress of the session creation with the Nnef_ImsSessionManagement_Notify request.
Step 19.
The DC AS returns a Nnef_ImsSessionManagement_Notify response to the NEF.
Step 20.
The NEF returns a Nimsas_ImsSessionMangement_Notify response to the IMS AS-1.
Up

AG.2.3  Terminating standalone Data Channel session  p. 478

Figure AG.2.3-1 shows the terminating procedure of a standalone data channel session. A standalone data channel can be a standalone bootstrap or standalone application data channel.
Copy of original 3GPP image for 3GPP TS 23.228, Fig. AG.2.3-1: Terminating of a standalone data channel Session
Figure AG.2.3-1: Terminating of a standalone data channel Session
(⇒ copy of original 3GPP image)
Up
Step 1.
The DC AS sends a Nnef_ImsSessionManagement_Delete request to the NEF requiring terminating a standalone DC session with UE A. The request includes the Session ID to be terminated.
Step 2.
The NEF queries the HSS for the address of the IMS AS-2 serving the specific UE if needed.
Step 3.
The NEF sends a Nimsas_ImsSessionManagement_Delete request to the IMS AS-2 requiring to terminate the standalone data channel session identified by the Session ID.
Step 4.
The IMS AS-2 returns a successful Nimsas_ImsSessionManagement_Delete response to the NEF.
Step 5.
The NEF returns a successful Nnef_ImsSessionManagement_Delete response to the DC AS.
Step 6.
The IMS AS-2 releases DC resources in the MF-2 and sends the BYE request to UE A according to existing IMS procedures to terminate the data channel session.
Step 7.
The IMS AS-2 sends a Nimsas_SessionEventControl_Notify request including the event SessionTerminationEvent to notify DCSF-2 that the session is terminated.
Step 8.
If the DC AS included a Notification Target Address to the Nnef_ImsSessionManagement_Delete request, the IMS AS-2 notifies the NEF for the progress of the session deletion with the Nimsas_ImsSessionManagement_Notify request, based on Table AA.2.4.4.5-1.
Step 9.
The NEF notifies the DC AS for the progress of the session deletion with the Nnef_ImsSessionManagement_Notify request.
Step 10.
The DC AS returns the Nnef_ImsSessionManagement_Notify response to the NEF.
Step 11.
The NEF returns the Nimsas_ImsSessionManagement_Notify response to the IMS AS-2
Up

$  Change history  p. 479

Up   Top