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

Top   Top   Up   Prev   Next
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.10.4.2 Application data channel establishment 
...

 

AC.7.10.4.2  Application data channel establishment  p. 404
AC.7.10.4.2.1  Application data channel multiplexing when both originating and terminating networks support data channel multiplexing  p. 404
Figure AC.7.10.4.2.1-1 shows the procedure of multiplexing application data channels when both originating and terminating networks support data channel multiplexing.
In this example procedure, the originating UE initiates a IMS session with audio and DC media components. The UE multiplexes 3 applications all with different endpoints. The originating IMS network and terminating IMS network eventually de-multiplexes the applications based on the different endpoints. Since the originating network and terminating network both support data channel multiplexing, application data channels are multiplexed between originating network and terminating network.
Reproduction of 3GPP TS 23.228, Fig. AC.7.10.4.2.1-1: Application data channel multiplexing when both originating and terminating networks support data channel multiplexing
Figure AC.7.10.4.2.1-1: Application data channel multiplexing when both originating and terminating networks support data channel multiplexing
Up
Step 1.
When the UE#1 wants to multiplex its application data channels for app#1, #2 and #3, the UE includes multiplexed SDP media description when sending reINVITE request. The endpoints of the applications are different, that of app#1 is DC AS in originating network, that of app#2 is DC AS in terminating network and that of app#3 is terminating UE. The media feature tag in the Contact header field indicating its capability of supporting data channel multiplexing is included in reINVITE request.
Step 2.
The IMS AS report event to DCSF.
Step 3.
The DCSF determines that data channel for app#1 needs to be de-multiplexed because its target endpoint is local DC AS. The DCSF also determine that the multiplexing for app#2 and #3 is kept unchanged towards their target terminating network as described in clause AC.7.10.3.
Step 4.
The DCSF generates data channel media information for originating side and terminating side.
Step 5.
The DCSF instructs the IMS AS to reserve resources on MF.
Step 6.
The IMS AS instructs MF to reserve media resources for multiplexed data channel streams and other media resources based on instructions from DCSF.
Step 7-8.
The session continues after the media resource is reserved successfully.
Step 9-10.
The IMS AS generates reINVITE request to terminating network. The reINVITE request includes capability of supporting data channel multiplexing and the SDP offer for multiplexed data channels of app#2 and #3.
Step 11.
The terminating network supports data channel multiplexing. The IMS AS in terminating network reports event to DCSF.
Step 12.
The DCSF in terminating network determines that data channel for app#2 and #3 needs to be de-multiplexed as described in clause AC.7.10.3 because they have different endpoints,
Step 13.
The DCSF generates data channel media information for originating side and terminating side.
Step 14.
The DCSF instructs the IMS AS to reserve resources on MF.
Step 15.
The IMS AS instructs MF to reserve media resources for multiplexed data channel streams and other media resources based on instructions from DCSF.
Step 16-17.
The session continues after the media resource is reserved successfully.
Step 18-19.
The IMS AS generates reINVITE request to UE#2.
Step 20-21.
The UE#2 replies 18X response with SDP answer for app#3.
Step 22-23.
The IMS AS replies 18X response with capability indication of supporting data channel multiplexing and SDP answer for multiplexed data channels for app#2 and #3 to originating network.
Step 24.
The IMS AS replies 18X response with SDP answer for multiplexed data channels for app#1, #2 and #3 to UE#1.
Step 25-26.
The IMS AS reports event to DCSF.
Step 27.
The session is established successfully. The streams of app#1, #2 and #3 are transported in the same SCTP connection between UE#1 and originating MF. The stream of app#1 is routed to DC AS and streams of app#2 and #3 are transported in the same SCTP connection between MFs of originating and terminating network and are routed to DC AS and UE#2 accordingly.
Up
AC.7.10.4.2.2  Application data channel multiplexing when terminating network does not support data channel multiplexing  p. 405
Figure AC.7.10.4.2.2-1 shows the procedure of multiplexing application data channels when terminating network does not support data channel multiplexing.
In this example procedure, the originating UE initiates a IMS session with audio and DC media components. The UE multiplexes 3 applications all with different endpoints. The originating network de-multiplexes app#1 because app#1 is terminated in originating network. The originating network further de-multiplexes app#2 and app#3 because the terminating network does not support data channel multiplexing and rejects the multiplexed SDP offer, by updating the session towards terminating network with normal SDP offer.
Reproduction of 3GPP TS 23.228, Fig. AC.7.10.4.2.2-1: Application data channel multiplexing when terminating network does not support data channel multiplexing
Figure AC.7.10.4.2.2-1: Application data channel multiplexing when terminating network does not support data channel multiplexing
Up
Step 1.
When the UE#1 wants to multiplex its application data channels for app#1, #2 and #3, the UE includes multiplexed SDP media description when sending reINVITE request. The endpoints of the applications are different, that of app#1 is DC AS in originating network, that of app#2 is DC AS in terminating network and that of app#3 is terminating UE. The media feature tag in the Contact header field indicating its capability of supporting data channel multiplexing is included in reINVITE request.
Step 2.
The IMS AS report event to DCSF.
Step 3.
The DCSF determines that data channel for app#1 needs to be de-multiplexed because its target endpoint is local DC AS. The DCSF also determine that the multiplexing for app#2 and #3 is kept unchanged towards their target terminating network as described in clause AC.7.10.3.
Step 4.
The DCSF generates data channel media information for originating side and terminating side.
Step 5.
The DCSF instructs the IMS AS to reserve resources on MF.
Step 6.
The IMS AS instructs MF to reserve media resources for multiplexed data channel streams and other media resources based on instructions from DCSF.
Step 7-8.
The session continues after the media resource is reserved successfully.
Step 9-10.
The IMS AS generates reINVITE request to terminating network. The reINVITE request includes capability of supporting data channel multiplexing and the SDP offer for multiplexed data channels of app#2 and #3.
Step 11-12.
The terminating network does not support data channel multiplexing. The terminating network replies 18X with the port of media component for multiplexed data channels set to zero in SDP answer and no capability indication of supporting data channel multiplexing is included.
Step 13-14.
The IMS AS determines that the terminating network does not support data channel multiplexing. It sends UPDATE request with normal SDP offer for app#2 and #3 to re-negotiate SDP with terminating network.
Step 15-16.
The terminating network replies 200 OK (UPDATE) with SDP answer for app#2 and #3.
Step 17.
The IMS AS reports the event of terminating network not supporting data channel multiplexing to the DCSF along with the media information of SDP answer.
Step 18.
The DCSF instructs the IMS AS and the IMS AS further requests the MF to modify media resources for streams of app#2 and #3.
Step 19.
The IMS AS replies 18X response with SDP answer for multiplexed data channels for app#1, #2 and #3 to UE#1.
Step 20.
The session is established successfully. The streams of app#1, #2 and #3 are transported in the same SCTP connection between UE#1 and originating MF. The stream of app#1 is routed to DC AS and streams of app#2 and #3 are transported to terminating network and are routed to DC AS and UE#2 accordingly.
Up

AC.8  Void

Up   Top   ToC