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.11 Support of Avatar Communication  AC.11.1 General  AC.11.2 Architecture  AC.11.3 Procedure  AC.11.3.1 Avatar ID List Download through Bootstrap Data Channel  AC.11.3.2 UE centric procedure  AC.11.3.2.1 Sending UE centric procedure  AC.11.3.2.2 Receiving UE centric procedure  AC.11.3.3 Network centric procedure 
...

 

AC.11  Support of Avatar Communication |R19|  p. 419

AC.11.1  General  p. 419

This clause describes the enhancements to the IMS architecture supporting data channel services to additionally support Avatar communication services.
For Avatar communication over IMS data channel, the list of Avatar ID(s) is downloaded to the UE by following options:
  • Pre-configured in the UE: The Avatar ID List is provisioned or downloaded to the UE before a data channel for avatar call is setup. The Avatar Representations may be downloaded together. The UE and the BAR may interact by means out of the scope of 3GPP.
  • Through bootstrap data channel: The Avatar ID List is fetched by the DC AS from the BAR, and transferred from the DC AS to the DCSF, and downloaded to UE through bootstrap data channel.
  • Through application data channel: The Avatar ID List is fetched by the DC AS from the BAR, and downloaded to the UE through application data channel.
Avatar ID List contains the list of Avatar IDs that are identifying the Avatar Representation and/or the associated information. The associated information may include the information for the user selection in the avatar calls (e.g. the metadata associated with the Avatar such as thumbnails, URLs, the associated data channel applications).
For downloading of Avatar ID List through bootstrap data channel, the DC AS URL(s) may be pre-configured in the DCSF, or fetched by DCSF. When the downloading of Avatar ID List is requested through bootstrap data channel, the DCSF requests DC AS to fetch the Avatar ID List from the BAR for the authorized user of the UE.
The BAR and/or the DC AS may be deployed either in the trusted domain or untrusted domain of operator's network.
After selection of Avatar ID to use in the avatar call by the user of the UE, the Avatar Representation identified with the selected Avatar IDs may be provided from the BAR to MF, and it may be transferred to the local UE (if not locally available) and/or to the remote UE according to the rendering mode via application data channel if needed.
The avatar media is rendered by processing the Avatar Representation with the animation data.
  • The avatar media rendering process may be performed by the sending UE, the receiving UE, or the network according to the rendering mode.
  • The animation data may be generated by the sending UE, the receiving UE, or the network (e.g. from audio, video, and/or metadata such as UE sensors collected data).
Up

AC.11.2  Architecture  p. 420

Copy of original 3GPP image for 3GPP TS 23.228, Fig. AC.11.2-1: Architecture to support Avatar communication
Figure AC.11.2-1: Architecture to support Avatar communication
(⇒ copy of original 3GPP image)
Up
To support Avatar communication, the data channel architecture and functions described in clause AC.2 is enhanced as below:
Base Avatar Repository (BAR):
  • The BAR stores Avatar Representation, its Avatar ID, and the associated information as described in clause AC.11.1. One or more Avatar Representation(s), is stored for a user, and each Avatar Representation is identified with Avatar ID.
  • The BAR may provide Avatar ID List to the DC Application Server, and the DC Application Server may further provide to DCSF.
  • The BAR provides Avatar Representation and the associated information to the MF directly or after URL redirection from the DC AS.
DCSF:
  • If the Avatar ID List is downloaded through bootstrap data channel, the DCSF may fetch the Avatar ID List from the DC AS, and send to MF via MDC1.
MF:
  • The MF supports the UE downloading the Avatar ID List and associated information through bootstrap data channel or application data channel.
  • The MF supports the UE downloading the Avatar Representation through bootstrap data channel or application data channel.
  • The MF may retrieve the Avatar Representation and the associated information from BAR via MDC2.
  • The MF may support Avatar media processing and transcoding (e.g. ASR/TTS).
DC AS:
  • The DC AS may provide the DC AS URL(s) to DCSF via DC3/N33 or DC4 for downloading of Avatar ID List through bootstrap data channel.
  • The DC AS retrieves the Avatar ID List from BAR(s) via MDC2.
  • The DC AS sends the Avatar ID List either to DCSF via MDC3 for downloading through bootstrap data channel, or to MF via MDC2 for downloading through application data channel.
  • The DC AS may retrieve the Avatar Representation and the associated information from BAR and sends to MF via MDC2.
  • The DC AS supports Avatar media negotiation and provides the instruction for Avatar media processing.
Up

AC.11.3  Procedure  p. 421

AC.11.3.1  Avatar ID List Download through Bootstrap Data Channel  p. 421

Copy of original 3GPP image for 3GPP TS 23.228, Fig. AC.11.3.1-1: Procedures of Avatar ID List Download through Bootstrap Data Channel
Figure AC.11.3.1-1: Procedures of Avatar ID List Download through Bootstrap Data Channel
(⇒ copy of original 3GPP image)
Up
Figure AC.11.3.1-1 depicts a typical call flow procedure of avatar ID list download procedure through bootstrap data channel. The main steps in the call flow are as follows:
Step 1.
IMS session and bootstrap data channel have been established.
Step 2.
The UE1 downloads application list through established bootstrap data channel.
Step 3.
The UE1 selects and downloads avatar communication application through established bootstrap data channel.
Step 4.
The DCSF checks the requested DC application is avatar communication application, and select the corresponding DC AS based on local configuration.
Step 5-6.
The DCSF downloads avatar communication from DCAR.
Step 7.
The DCSF requests DC AS to get UE1's avatar ID list using DC AS URL.
Step 8.
The DC AS get UE1's avatar ID list from BAR.
Step 9-10.
The BAR returns UE1's avatar ID list to the DC AS, the DC AS returns it to the DCSF.
Step 11.
The DCSF sends the avatar ID list together with the avatar application to the UE1.
Up

AC.11.3.2  UE centric procedure  p. 422

The UE centric mode includes two scenarios:
  • Sending UE centric: When the UE initiates an avatar communication with the peer UE, the UE that owns the avatar representation should download the avatar representation from BAR, if the Avatar representation is not locally available. The sending UE performs avatar animation and sends the animated video stream to the peer UE.
  • Receiving UE centric: When the UE initiates an avatar communication with the peer UE, the UE that owns the avatar representation should sends the avatar ID to the peer UE. The peer UE downloads the avatar representation from BAR based on the received avatar ID, performs the avatar animation, and displays the animated video stream.
Up
AC.11.3.2.1  Sending UE centric procedure  p. 422
Copy of original 3GPP image for 3GPP TS 23.228, Fig. AC.11.3.2.1-1: Procedures of Sending UE centric IMS Avatar communication
Figure AC.11.3.2.1-1: Procedures of Sending UE centric IMS Avatar communication
(⇒ copy of original 3GPP image)
Up
Figure AC.11.3.2.1-1 depicts a typical call flow procedure of sending UE centric IMS Avatar communication. The main steps in the call flow are as follows:
Step 1.
IMS session and bootstrap data channel have been established. UE1 downloads avatar communication application. The avatar ID list is downloaded as described in clause AC.11.3.1. Then UE1 chooses an avatar ID and runs the avatar communication application. If the avatar representation is locally available on the UE1, then step 2-6 can be skipped.
Step 2.
P2A application data channel(s) are established between UE1 and DC AS which is used for avatar representation transmission.
Step 3.
UE1 downloads Avatar representation from DC AS using avatar ID and UE1's identity (e.g., IMSI or MSISDN) through the established application data channel.
Step 4-5.
The DC AS should authenticate and authorize the UE1 request and download Avatar representation using avatar ID from the BAR, the BAR responses with avatar representation data.
Step 6.
The DC AS responses with the avatar representation data to MF, and then MF sends it back to UE1.
Step 7.
UE1 performs avatar animation.
Step 8.
UE1 transmits the animated video stream over RTP to UE2.
Up
AC.11.3.2.2  Receiving UE centric procedure  p. 423
Copy of original 3GPP image for 3GPP TS 23.228, Fig. AC.11.3.2.2-1: Procedures of Receiving UE centric IMS Avatar communication
Figure AC.11.3.2.2-1: Procedures of Receiving UE centric IMS Avatar communication
(⇒ copy of original 3GPP image)
Up
Figure AC.11.3.2.2-1 depicts a typical call flow procedure of receiving UE centric IMS Avatar communication. The main steps in the call flow are as follows:
Step 1.
IMS session and bootstrap data channel have been established. UE1 downloads avatar communication application. The avatar ID list is downloaded as described in clause AC.11.3.1. Then UE1 chooses an avatar ID and runs the avatar communication application.
Step 2.
P2A2P application data channel(s) are established between UE1/UE2 and DC AS.
Step 3.
UE1 decides to request peer UE to perform avatar animation based on its status such as power, signal, computing power, internal storage, etc.
Step 4.
UE1 performs avatar animation negotiation with the DC AS and UE2. The negotiation includes usage of the UE1's avatar ID and the animation data types (e.g. text and/or facial expression) supported by UE1.
Step 5.
UE2 downloads avatar representation from DC AS using the avatar ID received from UE1 through the established application data channel in step 2.
Step 6-7.
The DC AS should authenticate and authorize the UE2 request and download avatar representation using UE1's avatar ID from the BAR, the BAR responses with UE1's avatar representation data. The DC AS should authorize the UE2 download request based on the negotiation result from step 4.
Step 8.
The DC AS responses with UE1's avatar representation data to the MF, and the MF sends it back to UE2.
Step 9.
UE1 may send metadata (e.g. facial expression) to UE2 through the established application data channel or audio/video through RTP channel between UE1 and UE2.
Step 10.
UE2 performs avatar animation with the UE1's avatar representation based on the metadata received from UE1.
Up

AC.11.3.3  Network centric procedure  p. 424

Copy of original 3GPP image for 3GPP TS 23.228, Fig. AC.11.3.3-1: Procedures of network centric IMS Avatar communication
Figure AC.11.3.3-1: Procedures of network centric IMS Avatar communication
(⇒ copy of original 3GPP image)
Up
Figure AC.11.3.3-1 depicts a typical call flow procedure of network centric IMS avatar communication. The main steps in the call flow are as follows:
Step 1.
IMS session and bootstrap data channel have been established. UE1 downloads avatar communication application. The avatar ID list is downloaded as described in clause AC.11.3.1. Then UE1 chooses an avatar ID and runs the avatar communication application.
Step 2.
P2A2P application data channel(s) are established between UE1/UE2 and DC AS.
Step 3.
UE1 decides to request network to perform avatar animation based on its status such as power, signal, computing power, internal storage, etc.
Step 4.
The avatar animation negotiation is finished between the DC AS and UE1.
Step 5.
If the negotiation result is successful in step 4, the UE1 initiates new P2A2P application data channels, which are used for avatar data transmission between the UE1/UE2 and the network. During the P2A2P application data channel establishment procedure, the DCSF will retrieve the avatar media processing specification, and instruct the MF via IMS AS how to establish the data channel and corresponding avatar media processing specification.
Step 6.
The IMS AS initiates the media re-negotiation between UE1, UE2 and MF, which anchors UE1 and UE2's audio/video to MF.
Step 7.
The MF downloads UE1's avatar representation using the URL sent from DC AS in step 5.
Step 8.
The UE1/UE2 may send avatar metadata (e.g. facial expression, FOV) through the P2A2P ADC established in step 5 and/or audio/video through established RTP channels in step 6.
Step 9.
MF performs avatar animation based on the avatar metadata received from application data channel and/or audio/video. MF should support different media processing according the avatar type, e.g., animation with no rendering for 2D avatar, animation and rendering for 3D avatar.
Step 10-11.
MF sends the animated video stream to UE2, and sends the animated video stream to UE1 if required.
The above procedures also apply for the transition from audio/video communication between two users to avatar communication. In an ongoing audio/video communication, one of UEs decides to switch the communication to avatar mode, it will interact with the IMS Core and peer UE to establish application data channel for the avatar communication. Then two UEs will exchange avatar media; and the original video media between two UEs may be stopped.
Up

Up   Top   ToC