- What it is: a way to hold conversations through 3D avatars, driven in real time from a participant's audio and video.
- Why it matters: Remote participants see and hear an avatar, so only compact animation data needs to travel.
- In this section: This page covers the avatar data model, scene placement, the end-to-end procedure and interoperability boundaries.
How it works
An avatar communication system combines three pieces: a representation of the avatar (its 3D model and how it is described), an animation stream that drives it in real time from a participant's audio and video, and a media transport that carries these over the network so remote participants see and hear the avatar. 5G-MAG's work looks at how these pieces map onto 5G media delivery (TR 26.813 V20.0.0 clause 4; TR 26.813 V20.0.0 clause 7.1; TR 26.813 V20.0.0 clause 8.2.2).
Key specifications: ISO/IEC 23090-39 (MPEG Avatar Representation Format, ARF), 3GPP TR 26.813 (Avatar Representation and Communication, studied under FS_AVATAR; V20.0.0 is a Release 20 report, and the normative avatar work in TS 26.264 that it builds on was completed in Release 19: TR 26.813 V20.0.0 clause 10.2). An introductory teaser is also available on the Technology Exchanges page.
The ARF data model
The Avatar Representation Format (ISO/IEC 23090-39) is built from two complementary parts (TR 26.813 V20.0.0 clause 6.3.4):
- A Base Avatar Format that stores the avatar asset. Its data model is composed of skeletons, meshes, blendshapes, skins, landmarks, textures, and nodes (joints). The skeleton and joints give the avatar its articulation; meshes and skins give it surface geometry and how that geometry deforms with the skeleton; blendshapes provide expression and fine facial deformation; landmarks give named reference points used to map tracking data onto the model (TR 26.813 V20.0.0 clause 6.3.4).
- An Animation Stream Format that carries the time-varying data used to animate a base avatar. The stream is a sequence of Avatar Animation Units (AAUs). Each AAU is the unit of packetisation for avatar animation data, similar in role to a NAL unit in video coding, and consists of an AAU header (a type code and a payload length) followed by an AAU payload that starts with a timestamp (TR 26.813 V20.0.0 clause 6.3.4; TR 26.813 V20.0.0 clause 8.2.2; draft-ietf-avtcore-rtp-avatar-02 sections 1 and 4.2). Facial, joint and landmark AAUs carry the identifier of their target blendshape set, joint set or landmark set (TR 26.813 V20.0.0 clause 6.3.4), and in a multi-party call the RTP SSRC identifies the source of each stream (TR 26.813 V20.0.0 clause 8.2.2).
The base avatar can be stored and exchanged in two container types: an ISOBMFF container (ISO/IEC 14496-12) or a Zip-based container (ISO/IEC 21320-1). Because the base avatar and the animation are separate, a client can fetch and load the model once (or reuse one it already holds) and then receive only the compact animation stream during the call (TR 26.813 V20.0.0 clause 6.3.4; TR 26.813 V20.0.0 clause 7.2 step 8; TR 26.813 V20.0.0 clause 6A).
Scene placement via MPEG-I Scene Description
ARF does not, by itself, position an avatar in a room; that is the job of MPEG-I Scene Description (ISO/IEC 23090-14), a set of extensions to Khronos glTF 2.0. Avatar support is defined in ISO/IEC 23090-14 (TR 26.813 V20.0.0 clause 6.3.4), which defines a glTF node extension that marks a particular node as the root/skeleton node of a humanoid avatar (TR 26.813 V20.0.0 clause 6.3.3). The 5G-MAG Features page, which follows the second edition (ISO/IEC 23090-14:2025), places it in clause 8.3. In the 5G-MAG documentation this is referred to as the MPEG_node_avatar glTF extension, described on the MPEG-I Scene Description page. The Presentation Engine reads the scene, resolves the avatar node, binds the ARF base avatar to it, and then applies the incoming animation stream frame by frame. This is the same Presentation Engine / Media Access Function decoupling used across the other MPEG-I Scene Description tooling.
End-to-end procedure
At a high level, a conversational avatar session proceeds as follows: (TR 26.813 V20.0.0 clause 7.2; TR 26.813 V20.0.0 clause 8.3.2.2)
| Step | What happens |
|---|---|
| 1. Provisioning | Both endpoints obtain the base avatar (either a stored ARF asset or one generated for the user). Because the avatar model is shared, only animation and audio need to flow during the call (TR 26.813 V20.0.0 clause 7.2 steps 1 and 8; TR 26.813 V20.0.0 clause 8.3.2.0). |
| 2. Session setup | The endpoints set up an IMS-based AR session (TS 26.264) and negotiate the avatar animation mode, sender-centric, receiver-centric or network-centric (TS 26.264 annex A.2.3), together with the avatar type and the animation data each side supports; the immersive audio codec (IVAS) is negotiated through SDP (TS 26.114 V20.1.1 clause 6.2.2.2). |
| 3. Capture and tracking | The sender tracks the participant from camera and microphone input and derives animation parameters (skeletal pose, facial blendshape weights, landmark positions, and similar) that drive the ARF joints, blendshape sets and landmark sets (TR 26.813 V20.0.0 clause 6.2; TR 26.813 V20.0.0 clause 7.1; TR 26.813 V20.0.0 clause 6.3.4). |
| 4. Encode and packetise | Animation parameters are formatted as ARF AAUs (TR 26.813 V20.0.0 clause 6.3.4); audio is encoded with the codec negotiated for the call, and MTSI clients in terminals offering immersive audio communication shall support IVAS (TS 26.114 V20.1.1 clause 5.2.1.1). |
| 5. Transport | In TS 26.264, animation data is carried over the IMS data channel: the Avatar Animation Data Channel uses the sub-protocol "3gpp-ar-animation", and each message "shall contain ARF animation units pertaining to exactly one animation sample" (TS 26.264 V19.4.1 clause 6.3.2). The IETF is separately defining an RTP payload format for ARF animations (draft-ietf-avtcore-rtp-avatar, version 02 of August 2026, a work in progress) with three payload structures: single unit, fragmentation unit and aggregation packet, the last as single-time or multi-time aggregation (draft-ietf-avtcore-rtp-avatar-02 section 5.4; TR 26.813 V20.0.0 clause 8.2.2). IVAS audio uses its own RTP payload format (TS 26.253 V19.3.0 clause A.1). |
| 6. Render | The receiver applies the animation stream to the downloaded base avatar and renders the scene; in the TR use case, spatial audio is rendered in the direction of each participant's geolocation (TR 26.813 V20.0.0 clause 5.1; TR 26.813 V20.0.0 clause 7.2 steps 13 and 18). |
Interfaces and interoperability
This analysis distinguishes four interoperability boundaries (a grouping derived by 5G-MAG from the clauses above, not stated in TR 26.813): the ARF base-avatar asset (so any conforming client can load the same avatar), the ARF animation stream and AAU structure (so animation produced by one endpoint can drive an avatar at another), the scene-description document that anchors the avatar, and the session-level negotiation (SDP media descriptions for IVAS audio and for the avatar animation payload). Keeping animation production separate from rendering means the tracking/animation component and the Unity-based presentation can evolve independently, provided both sides agree on the ARF stream format.
Release history: TS 26.264 was created in Release 18 by the IBACS work item as the AR-MTSI client specification (TR 21.918 clause 14.6; TS 26.264 V18.0.0). The avatar call functionality was added in Release 19 by the AvCall-MED work item (TR 21.919 clause 12.4; TS 26.264 V19.4.1 annex E, CR 0006 "CR for Avatar calls in IMS", version 19.0.0): ARF base avatars, 3D and 2D avatars, data channel animation messages, avatar negotiation in SDP and over the data channel, and the Base Avatar Repository management service. Later Release 19 versions add the OpenAPI specification of the Base Avatar Management Interface (CR 0007, V19.1.0) and corrections to animation sample transport, call flows and profile signalling (CRs 0017, 0018 and 0023). For Release 20 (work plan of 28 September 2026), the work item AvCall_Ph2-MED, Avatar Communications phase 2, lists TS 26.264 (WID SP-260910, 0%, planned finish 3 March 2027), and the study FS_Avatar_Ph2_MED on TR 26.813 is complete (100%).
ARF (ISO/IEC 23090-39) was still at the Draft International Standard stage as of 2025; MPEG's own report of its 155th meeting (July 2026) states it has since advanced to Final Draft International Standard, the stage just before publication, so the base-avatar and animation-stream details above can still change before final publication. Confirm the current stage on the ISO catalogue page and treat reference tooling as tracking a moving target.
The slide deck below introduces the Avatar Communications reference tools and their role in 5G real-time communication.
Related: XR Media & 3D Scenes: the wider XR area, including the scene-description model that positions and animates avatars · MPEG-I Scene Description: the MPEG_node_avatar glTF extension used for 3D avatar representation · Standards: Conversational Avatar Communication: the standards-tracking view of this topic.