WO2025087677A1

WO2025087677A1 - Apparatuses, methods and computer programs supporting avatar calling in ims

Info

Publication number: WO2025087677A1
Application number: PCT/EP2024/078120
Authority: WO
Inventors: Parthasarathi RAVINDRAN; Saurabh Khare; Rainer Liebhart; Laurent GOIX
Original assignee: Nokia Technologies Oy
Current assignee: Nokia Technologies Oy
Priority date: 2023-10-27
Filing date: 2024-10-07
Publication date: 2025-05-01
Anticipated expiration: 2026-04-27

Abstract

There is provided an apparatus comprising means for: sending (601) a session initiation protocol, SIP, request, to an internet protocol multimedia subsystem, IMS, application server, the SIP request comprising an avatar calling capability indication, wherein the avatar calling capability indication indicates that the communication device is capable of avatar calling; and receiving (602), from the IMS application server, a SIP response comprising an indication whether an IMS network that comprises the IMS application server allows avatar calling.

Description

APPARATUSES, METHODS AND COMPUTER PROGRAMS SUPPORTING AVATAR CALLING IN IMS

FIELD

[0001] The present application relates to a method, apparatus, system and computer program and in particular but not exclusively to a communication device that sends and receives information on capabilities of apparatus for performing and/or allowing avatar calling.

BACKGROUND

[0002] A communication system can be seen as a facility that enables communication sessions between two or more entities such as user terminals, base stations and/or other nodes by providing carriers between the various entities involved in the communications path. A communication system can be provided for example by means of a communication network and one or more compatible communication devices. The communication sessions may comprise, for example, communication of data for carrying communications such as voice, video, electronic mail (email), text message, multimedia and/or content data and so on. Non-limiting examples of services provided comprise two-way or multi-way calls, data communication or multimedia services and access to a data network system, such as the Internet.

[0003] In a wireless communication system at least a part of a communication session between at least two stations occurs over a wireless link. Examples of wireless systems comprise public land mobile networks (PLMN), satellite based communication systems and different wireless local networks, for example wireless local area networks (WLAN). Some wireless systems can be divided into cells, and are therefore often referred to as cellular systems.

[0004] A user can access the communication system by means of an appropriate communication device or terminal. A communication device of a user may be referred to as user equipment (UE) or user device. A communication device is provided with an appropriate signal receiving and transmitting apparatus for enabling communications, for example enabling access to a communication network or communications directly with other users. The communication device may access a carrier provided by a station, for example a base station of a cell, and transmit and/or receive communications on the carrier. [0005] The communication system and associated devices typically operate in accordance with a given standard or specification which sets out what the various entities associated with the system are permitted to do and how that should be achieved. Communication protocols and/or parameters which shall be used for the connection are also typically defined. One example of a communications system is UTRAN (3G radio). Other examples of communication systems are the long-term evolution (LTE) of the Universal Mobile Telecommunications System (UMTS) radioaccess technology and so-called 5G or New Radio (NR) networks. NR is being standardized by the 3rd Generation Partnership Project (3GPP).

SUMMARY

[0006] According to a first aspect, there is provided a communication device comprising: means for sending a session initiation protocol, SIP, request, to an internet protocol multimedia subsystem, IMS, application server, the SIP request comprising an avatar calling capability indication, wherein the avatar calling capability indication indicates that the communication device is capable of avatar calling; and means for receiving, from the IMS application server, a SIP response comprising an indication whether an IMS network that comprises the IMS application server allows avatar calling.

[0007] The communication device further comprises means for enabling avatar calling based on the indication indicating that the IMS network allows avatar calling; and means for disabling avatar calling based on the indication indicating that the IMS network does not allow avatar calling.

[0008] When the SIP response received from the IMS application server further comprises an indication of whether the IMS network supports avatar rendering at the communication device, the communication device further comprises: means for enabling avatar rendering at the communication device based on the indication indicating that the IMS network supports avatar rendering at the communication device; and mean for disabling avatar rendering at the communication device based on the indication indicating that the IMS network does not support avatar rendering at the communication device.

[0009] According to a second aspect, there is provided an internet protocol multimedia application, IMS, application server comprising: means for receiving, from a communication device, a session initiation protocol, SIP, reqest, the SIP request comprising an avatar calling capability indication, wherein the avatar calling capability indication indicates that the communication device is capable of avatar calling; and means for sending, to the communication device, a SIP response comprising an indication whether an IMS network that comprises the IMS application server allows avatar calling.

[0010] The IMS application server may further comprise means for determining a default avatar that identifies an avatar to be used by the communication device as a default avatar for avatar calling originating from the communication device; and means for providing an identifier of the default avatar to the communication device. [0011] The means for determining a default avatar may comprise means for: extracting, from the SIP request message, an avatar identifier identifying an avatar to be used as a default avatar for avatar calling originating from the communication device; and means for verifying that the communication device is authorized to use the extracted avatar identified by the identifier as a default avatar for avatar calling. [0012] The means for determining a default avatar may comprise means for: using an IMS identifier of the communication device to retrieve IMS subscription information associated with the communication device; means for verifying, using the subscription information, at least one avatar that the communication is authorized to use; and means for selecting a default avatar from the verified at least one avatar.

[0013] The means for using an IMS identifier of the communication device to retrieve IMS subscription information associated with the communication device may comprise means for using the IMS identifier to retrieve and verify at least one avatar and/or at least one avatar identifier from a home subscriber system and/or a unified data management system.

[0014] The IMS identifier may comprise an IMS public user identity.

[0015] According to a third aspect, there is provided an communication device comprising at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the communication device at least to perform: sending a session initiation protocol, SIP, request, to an internet protocol multimedia subsystem, IMS, application server, the SIP request comprising an avatar calling capability indication, wherein the avatar calling capability indication indicates that the communication device is capable of avatar calling; and receiving, from the IMS application server, a SIP response comprising an indication whether an IMS network that comprises the IMS application server allows avatar calling.

[0016] The at least one processor may be configured to cause the communication device to perform: enabling avatar calling based on the indication indicating that the IMS network allows avatar calling; and disabling avatar calling based on the indication indicating that the IMS network does not allow avatar calling.

[0017] When the SIP response received from the IMS application server further comprises an indication of whether the IMS network supports avatar rendering at the communication device, the at least one processor may be configured to cause the communication device to perform: enabling avatar rendering at the communication device based on the indication indicating that the IMS network supports avatar rendering at the communication device; and disabling avatar rendering at the communication device based on the indication indicating that the IMS network does not support avatar rendering at the communication device.

[0018] According to a fourth aspect, there is provided an internet protocol multimedia application, IMS, application server comprising at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the IMS application server at least to perform: receiving, from a communication device, a session initiation protocol, SIP, request, the SIP request comprising an avatar calling capability indication, wherein the avatar calling capability indication indicates that the communication device is capable of avatar calling; and sending, to the communication device, a SIP response comprising an indication whether an IMS network that comprises the IMS application server allows avatar calling.

[0019] The at least one processor may be configured to cause the IMS AS to perform: determining a default avatar that identifies an avatar to be used by the communication device as a default avatar for avatar calling originating from the communication device; and providing an identifier of the default avatar to the communication device. [0020] The determining a default avatar may comprise: extracting, from the SIP request message, an avatar identifier identifying an avatar to be used as a default avatar for avatar calling originating from the communication device; and verifying that the communication device is authorized to use the extracted avatar identified by the identifier as a default avatar for avatar calling.

[0021] The determining a default avatar may comprise: using an IMS identifier of the communication device to retrieve IMS subscription information associated with the communication device; verifying, using the subscription information, at least one avatar that the communication is authorized to use; and selecting a default avatar from the verified at least one avatar.

[0022] The using an IMS identifier of the communication device to retrieve IMS subscription information associated with the communication device may comprise: using the IMS identifier to retrieve and verify at least one avatar and/or at least one avatar identifier from a home subscriber system and/or a unified data management system.

[0023] The IMS identifier may comprise an IMS public user identity.

[0024] According to a fifth aspect, there is provided a method for a communication device, the method comprising: sending a session initiation protocol, SIP, request, to an internet protocol multimedia subsystem, IMS, application server, the SIP request comprising an avatar calling capability indication, wherein the avatar calling capability indication indicates that the communication device is capable of avatar calling; and receiving, from the IMS application server, a SIP response comprising an indication whether an IMS network that comprises the IMS application server allows avatar calling.

[0025] The method may further comprise: enabling avatar calling based on the indication indicating that the IMS network allows avatar calling; and disabling avatar calling based on the indication indicating that the IMS network does not allow avatar calling.

[0026] When the SIP response received from the IMS application server further comprises an indication of whether the IMS network supports avatar rendering at the communication device, the method may further comprise: enabling avatar rendering at the communication device based on the indication indicating that the IMS network supports avatar rendering at the communication device; and disabling avatar rendering at the communication device based on the indication indicating that the IMS network does not support avatar rendering at the communication device.

[0027] According to a sixth aspect, there is provided a method for an internet protocol multimedia application, IMS, application server, the method comprising: receiving, from a communication device, a session initiation protocol, SIP, request, the SIP request comprising an avatar calling capability indication, wherein the avatar calling capability indication indicates that the communication device is capable of avatar calling; and sending, to the communication device, a SIP response comprising an indication whether an IMS network that comprises the IMS application server allows avatar calling.

[0028] The method may further comprise: determining a default avatar that identifies an avatar to be used by the communication device as a default avatar for avatar calling originating from the communication device; and providing an identifier of the default avatar to the communication device.

[0029] The determining a default avatar may comprise: extracting, from the SIP request message, an avatar identifier identifying an avatar to be used as a default avatar for avatar calling originating from the communication device; and verifying that the communication device is authorized to use the extracted avatar identified by the identifier as a default avatar for avatar calling.

[0030] The determining a default avatar may comprise: using an IMS identifier of the communication device to retrieve IMS subscription information associated with the communication device; verifying, using the subscription information, at least one avatar that the communication is authorized to use; and selecting a default avatar from the verified at least one avatar.

[0031] The using an IMS identifier of the communication device to retrieve IMS subscription information associated with the communication device may comprise: using the IMS identifier to retrieve and verify at least one avatar and/or at least one avatar identifier from a home subscriber system and/or a unified data management system.

[0032] The IMS identifier may comprise an IMS public user identity. [0033] According to a seventh aspect, there is provided a computer readable medium comprising instructions which, when executed by a communication device, cause the communication device to perform at least the following: sending a session initiation protocol, SIP, request, to an internet protocol multimedia subsystem, IMS, application server, the SIP request comprising an avatar calling capability indication, wherein the avatar calling capability indication indicates that the communication device is capable of avatar calling; and receiving, from the IMS application server, a SIP response comprising an indication whether an IMS network that comprises the IMS application server allows avatar calling.

[0034] The communication device may be caused to perform: enabling avatar calling based on the indication indicating that the IMS network allows avatar calling; and disabling avatar calling based on the indication indicating that the IMS network does not allow avatar calling.

[0035] When the SIP response received from the IMS application server further comprises an indication of whether the IMS network supports avatar rendering at the communication device, the communication device may be caused to perform: enabling avatar rendering at the communication device based on the indication indicating that the IMS network supports avatar rendering at the communication device; and disabling avatar rendering at the communication device based on the indication indicating that the IMS network does not support avatar rendering at the communication device.

[0036] According to an eighth aspect, there is provided a computer readable medium comprising instructions which, when executed by an internet protocol multimedia application, IMS, application server, cause the internet protocol multimedia application, IMS, application server to perform at least the following: receiving, from a communication device, a session initiation protocol, SIP, request, the SIP request comprising an avatar calling capability indication, wherein the avatar calling capability indication indicates that the communication device is capable of avatar calling; and sending, to the communication device, a SIP response comprising an indication whether an IMS network that comprises the IMS application server allows avatar calling. [0037] The instructions, when executed by the IMS application server may further cause the IMS application sever to perform: determining a default avatar that identifies an avatar to be used by the communication device as a default avatar for avatar calling originating from the communication device; and providing an identifier of the default avatar to the communication device.

[0038] The determining a default avatar may comprise: extracting, from the SIP request message, an avatar identifier identifying an avatar to be used as a default avatar for avatar calling originating from the communication device; and verifying that the communication device is authorized to use the extracted avatar identified by the identifier as a default avatar for avatar calling.

[0039] The determining a default avatar may comprise: using an IMS identifier of the communication device to retrieve IMS subscription information associated with the communication device; verifying, using the subscription information, at least one avatar that the communication is authorized to use; and selecting a default avatar from the verified at least one avatar.

[0040] The using an IMS identifier of the communication device to retrieve IMS subscription information associated with the communication device may comprise: using the IMS identifier to retrieve and verify at least one avatar and/or at least one avatar identifier from a home subscriber system and/or a unified data management system.

[0041] The IMS identifier may comprise an IMS public user identity.

[0042] In all of the above, the SIP request message may further comprise an indication of an avatar rendering capability of the communication device, wherein the avatar rendering capability of the communication device indicates whether the communication device is capable of avatar rendering.

[0043] The communication device may be considered to be capable of avatar rendering when the communication device is able to modify a video stream by inserting avatar metadata and/or avatar media into the video stream to produce a modified video stream that comprises an avatar and/or to generate a video stream using avatar metadata and/or avatar media, and sensor data from at least one sensor of the communication device. [0044] The SIP request message may further comprise an identifier of an avatar to be used as a default avatar for avatar calling originating from the communication device.

[0045] The SIP response received from the IMS application server may further comprise an indication of whether the IMS application server supports avatar calls.

[0046] The SIP response received from the IMS application server may further comprise an indication of whether the IMS network supports avatar rendering at the communication device.

[0047] The SIP response may further comprise a default avatar identifier that identifies an avatar to be used by the communication device as a default avatar for avatar calling originating from the communication device.

[0048] The SIP response may further comprise, at least one of: an indication of whether a second communication device supports avatar calling, or an indication of whether the second communication device supports avatar rendering.

[0049] The SIP request message may comprise a session initiation protocol invite message or a session initiation protocol registration message.

[0050] The SIP response may comprise a session initiation protocol 200 OK message or a session initiation protocol provisional acknowledgement message.

[0051] At least one of the avatar calling capability indication or avatar rendering may be transmitted in a session initiation protocol message header.

[0052] The apparatus of the above aspects may be further caused to perform: determining that the communication device is to no longer use avatar calling; and deleting at least one avatar comprised in a local cache of the communication device or IMS application server.

[0053] According to an aspect, there is provided a non-transitory computer readable medium comprising program instructions that, when executed by an apparatus, cause the apparatus to perform at least the method according to any of the preceding aspects.

[0054] In the above, many different embodiments have been described. It should be appreciated that further embodiments may be provided by the combination of any two or more of the embodiments described above.

DESCRIPTION OF FIGURES [0055] Embodiments will now be described, by way of example only, with reference to the accompanying Figures in which:

[0056] Fig. 1 shows a schematic representation of an originating user equipment communicating with a terminating user equipment via a communication network comprising two internet protocol multimedia subsystem networks in accordance with an example embodiment;

[0057] Fig. 2 shows a schematic representation of an apparatus implementing one or more network functions of an internet protocol multimedia subsystem network;

[0058] Fig. 3 shows a schematic representation of a user equipment;

[0059] FIGS. 4 and 5 illustrate example call signalling procedures; and

[0060] FIGS. 6 and 7 illustrate operations that may be performed by apparatus described herein.

DETAILED DESCRIPTION

[0061] Avatar calling relates to the ability of an internet protocol multimedia subsystem (IMS) network to modify a video stream being provided from a device (e.g., a UE) associated with a first participant, via IMS networks, to a communication device (e.g., a UE) associated with a second participant such that at least one person being depicted in the video stream is replaced by an alternative representation (a.k.a., avatar) in the video stream that is rendered at the communication device (e.g., UE) associated with the second participant.

[0062] The avatar may be two dimensional and/or three dimensional. The avatar may have a range of physical characteristics. The replacement of at least one person in a video steam by a communication device (e.g., a UE) may include detecting motion (e.g., gestures) of the at least one person in a video (e.g., by processing the video, using, for examples an AI/ML model configured for gesture detection or gesture recognition) and matching the motion (e.g., the gestures) of the at least one person in the video to avatar actions such that the motion of the avatar in the modified video stream mimics the motions (e.g., gestures) of the at least one person in the video stream. The avatar may be associated with metadata that describes the avatar. The metadata may include, for example, whether the avatar is associated with a specific language to be used in the audio stream of the avatar call. [0063] 3GPP TS 22.156, clause 5.2.2 describes several features to be supported for avatar calling. These include, for example, that a 5G system that includes an IMS network should support (e.g., be capable of or configured for) multimedia communications, including the transfer of real-time avatar media and audio media. An IMS call or IMS session that uses avatar media is referred to herein as an IMS avatar call and/or an avatar call. The 5G system that includes the IMS network should also support encoding of sensor data (and transmission thereof) that includes for example a facial expression, pose and movements, and body movement and gestures of a participant in an avatar call.

[0064] In relation to this, avatar metadata and avatar media have been defined. Avatar metadata comprises the 2D and/or 3D representational content of an Avatar. The representational content may also be referred to as a model. The avatar metadata can be stored in a file that can be addressed via a URL. Avatar media (used synonymously herein with “gesture media”) comprises user plane and/or media plane data related to an Avatar. This avatar media is transmitted between two UEs and can be used to animate an avatar model. Stated differently, avatar metadata relates to information that defines the appearance and/or representation of an avatar, while avatar media relates to information for animating of the avatar.

[0065] The present application identifies that there are several issues that result in an inefficient setup of an avatar call in a 5G system comprising an IMS network.

[0066] In particular, there are several use cases in which it would be useful for an IMS network of a 5G system and/or a communication device (e.g., a UE) that is served by the IMS network to know whether avatar calling is possible or not.

[0067] For example, not all communication devices (e.g., UEs) will be able to support (e.g., may not be capable of or configured for) avatar calling. This can be seen when a UE associated with Party-A supports avatar calling and wants to initiate an avatar call with a UE associated with Party-B. In such a case, when the IMS network serving the UE associated with Party-A is not aware of the avatar capability of the UE associated with Party-B, then the IMS network serving the UE associated Party-B will try to terminate the avatar call at the UE associated with Party-B, and the avatar call will fail. [0068] As another example, the IMS network serving the UE associated with Party- A’s and/or the IMS network serving the UE associated Party-B’s may not allow avatar calling. In such a case, it would be useful to provide this information about the non-allowance of avatar calling to the UE associated with Party-A and/or the UE associated with Party-B.

[0069] As another example, communication devices (e.g., UEs) that support avatar calling may want to indicate to the IMS network and other communication devices (e.g., other UEs) that they support avatar calling despite the initial IMS SIP session established for audio and/or video calling that was established for the communication device not using this capability. Stated differently, it may be useful for UEs to be able to transition between a video call and an avatar call, or to otherwise change transcoding parameters between a video codec and an avatar codec at some point during a call. The Audio and/or Video (AV) associated with the avatar call may subsequently be downgraded to audio, and/or the parameters associated with the avatar call be subsequently renegotiated. This may delay the call setup time. Stated differently, this may delay the call connection time.

[0070] It would therefore be useful to provide an indication about a communication device’s (e.g., UE’s) capability for performing avatar calls (e.g., for avatar calling) to be available at an IMS network in order to allow the IMS network to support avatar calls for UEs. The UE’s capability for performing avatar calls may be configured and/or activated by at least one IMS network. The UE’s capability for performing avatar calls may be based on, at least in part, a user input. The user input may configure a setting that toggles between activating and deactivating avatar calling such that one of activating and deactivating avatar calling is configured for the UE. [0071] Another issue that arises with respect to avatar calling relates to avatar identification.

[0072] Avatars can be identified by a respective identifier (also referred to herein as an avatar identifier). An avatar may be identified by a unique avatar identifier (e.g., a uniform resource identifier, URI) and be stored on a server.

[0073] Avatars are expected to be associated with specific 5GC identities, such as, for example, Generic Public Subscription Identifier (GPSI). However, an IMS already supports multiple identities like IMS Public User Identity (IMPU). As avatars may be used in IMS call, it would be useful to associate avatars with an existing IMPU. For example, if IIE-A has two avatars that can be used for avatar calling and multiple IMS user identities are available, then which IMS user identity will be used with which avatar identifier should be defined. Stated differently, associations between an avatar identifier and at least one IMS user identity (e.g., IMPU) should be defined. [0074] The following further identifies that it would be useful to define and cache a “default avatar” per IMS subscriber in the UE during IMS registration (e.g., when the UE registers with an IMS network). The use of such a default avatar may reduce the time required to setup a subsequent avatar call. The default avatar may be authenticated very similarly to any avatar caused to be stored in the IMS network for a UE during a session.

[0075] To address at least one of the above-mentioned issues relating to setup delays, a UE provides an indication of its capability for avatar calls (e.g., avatar calling capability) to the IMS network and/or to another UE, e.g., during IMS registration (e.g. when the UE registers with an IMS network) and/or during IMS session establishment or modification (e.g., when a UE requests the IMS network establish an IMS session or modify an existing IMS session). The avatar calling capability may be as described below.

[0076] An avatar identifier may be accompanied by additional metadata that describes at least one property associated with the avatar identified by the avatar identifier. For example, an avatar identifier may be associated with a specific audio language. This specific audio language may be indicated via metadata accompanying the avatar identifier.

[0077] When avatar calling is allowed in the IMS network and/or supported in the IMS network, then the IMS network provides an indication to the UE that avatar calling is allowed during this UE registration and/or IMS session.

[0078] The UE can further provide a default avatar identifier that identifies a “default avatar”. The default avatar identifier may have the same properties described herein as an avatar identifier. The default avatar may have the same properties described herein as an avatar. [0079] The UE may further be configured to indicate a “default” avatar identifier that identifies a default avatar to be used for rendering at least one person within a video stream provided from the UE.

[0080] When the UE does not indicate a “default” avatar identifier to the IMS network, the IMS network can select a default avatar identifier on behalf of the UE. The network-selected default avatar identifier may be provided to the UE. The network-selected default avatar identifier identifies an avatar to be used as a default avatar for rendering at least one person within a video stream provided from the UE. This network-selected default avatar identifier may be provided by a network function in the IMS network that maintains an association between avatar ID and user identities. This network-selected default avatar identifier may be a generic (e.g. user-independent) avatar identifier.

[0081] In the following certain embodiments are explained with reference to communication devices capable of communication via comprising a 5GS an IMS network. Before explaining in detail the exemplifying embodiments, certain general principles of a cellular system, and communication devices are briefly explained with reference to FIGS. 1 , 2 and 3 to assist in understanding the technology underlying the described examples.

[0082] FIG. 1 shows a schematic representation of a first user equipment (denoted UE-A) communicating with a second user equipment comprising a communication network that includes two IMS networks. The communication network may comprise a public land mobile network (PLMN). A communication network may comprise a (radio) access network ((R)AN) (not illustrated), a core network (5GC) (not illustrated) in addition to the two internet protocol multimedia subsystem (IMS) networks shown. The IMS network serving the first user equipment (e.g., UE-A) may be referred to as an originating IMS network and the IMS network servicing the second user equipment (e.g., UE-B) may be referred to as a terminating IMS network.

[0083] In this disclosure, the expressions “internet protocol multimedia subsystem” and “internet protocol multimedia subsystem network” may be used interchangeably. [0084] The (R)AN (not illustrated) may comprise one or more base stations. A base station may be an evolved NodeB (eNB) or a gNodeB (gNB). A gNB may comprise distributed units connected to one or more centralized units. A (base station may be configured to provide wireless connectivity between the first user equipment and a base station and wired and/or wireless connectivity between the base station and the IMS network via the 5GC. and between the second user equipment and the 5GC.

[0085] The 5GC may comprise an access and mobility management function (AMF), a session management function (SMF), an authentication server function (ALISF), a user data management (UDM), a network exposure function (NEF), a unified data repository (UDR), a network repository function (NRF) and/or a network data analytics function (NWDAF), and a user plane comprising a user plane function (UPF). The 5GC may be connected to an IMS network (e.g., the originating IMS network or the terminating IMS network). The 5GC may be to manage traffic and routing from a UE via the (R)AN towards an IMS network (e.g., from the first UE towards the originating IMS network or the second UE towards the terminating IMS network).

[0086] An IMS network (e.g., the originating IMS network or the terminating IMS network) may comprise a proxy call session control function (P-CSCF), a serving call session control function (S-CSCF), an interrogating call session control function (l-CSCF), an IMS application level gateway (IMS-AGW), an IMS home subscriber server (IMS HSS), an IMS application server (IMS AS), a media function (MF) or media repository function (MRF), a transition gateway (TrGW), an interconnection border control function (IBCF), a terminating IMS core, a data channel signalling function (DCSF), an XR application server (AS), a digital asset container (DAC) or a web server (not represented).

[0087] The DAC may be separate from other network functions of the originating IMS network or may be integrated with other network functions of the originating IMS network. For example, the DAC may be integrated within the IMS HSS or the XR AS.

[0088] Although the DAC is illustrated in Figure 1 as being part of the originating IMS network, it will be understood that the DAC is not necessarily part of the originating IMS network, let alone the communication network (e.g., PLMN). The DAC may be part of the 5GC. The DAC may be separate from other network functions of the 5GC or may be integrated with other networks functions of the 5GC. For example, the DAC may be integrated within the UDM. Alternatively, the DAC may not be part of the communication network (e.g., PLMN). For example, the DAC may be part of a web server or a computing system of a cloud provider that is connected to the communication network (e.g., PLMN).

[0089] The DAC may be separate from other functions of the IMS or may be integrated with other functions of the IMS. For example, the DAC may be integrated within the HSS or the XR AS. The DAC stores digital assets of a user. Digital assets of a user may comprise digital representations of, for example, user information and/or user documents such as e.g. passport, social security number, avatar, driving license, insurance policy etc.

[0090] It will be understood that the DAC is not necessarily part of the IMS, let alone the PLMN. The DAC may be part of the 5GC. The DAC may be separate from other functions of the 5GC or may be integrated with other functions of the 5GC. For example, the DAC may be integrated within the UDM. Alternatively, the DAC may not be part of the PLMN. The DAC may be part of a web server or a cloud provider outside the PLMN.

[0091] A user equipment (UE) can connect and register to the IMS network in various ways through an access network (such as through a 5G and/or 6G access network). Registration with the IMS network currently uses Session Initiation Protocol (SIP) signalling mechanisms, which are defined by the Internet Engineering Task Force (IETF). A home subscriber server (HSS) and/or unified data management (UDM) located in the core network contains subscription-related information for users, performs authentication and/or authorisation of the user for the IMS network. An IMS subscriber comprises a user and/or user equipment that has an IMS subscription stored in the HSS. Each IMS subscription is linked to a single IP multimedia private user identity (IMP I), which is discussed further below.

[0092] The IMS network further comprises a plurality of IMS network-based identifies. For example, IMS identities include at least IP multimedia private user identity (IMPI), IP multimedia public user identity (IMPU), globally routable user agent URI (GRUU), wildcarded public user identity. Both IMPI and IMPU are uniform resource identifiers (URIs), that can be digits or alphanumeric identifiers.

[0093] The IMPI is a unique permanently allocated global identity assigned by the home network operator. It has the form of a Network Access Identifier (NAI) (e.g., user.name@domain), and is used, for example, for Registration, Authorization, Administration, and Accounting purposes.

[0094] The IMPU is used by any user for requesting communications to other users (e.g. this might be included on a business card). There can be multiple IMPU per IMPI.

[0095] FIG. 2 illustrates an example of an apparatus 200 comprising or implementing a network function of IMS network as illustrated in FIG. 1. The apparatus may comprise at least one random access memory (RAM) 211a, at least on read only memory (ROM) 211 b, at least one processor 212, 213 and an inputoutput interface 214. The at least one processor 212, 213 may be coupled to the RAM 211 a and the ROM 211 b. The at least one processor 212, 213 may be configured to execute an appropriate software code 215. The software code 215 may be software code for the IMS application server which is configured to perform one or more steps to perform one or more of the present aspects. The software code 215 may be stored in the ROM 211 b. The apparatus 200 may be interconnected with another apparatus 200 comprising or implementing another network function of the 5GC or IMS network. In some embodiments, each network function of the 5GC or IMS network is implemented on an apparatus 200. In alternative embodiments, two or more network functions of the 5GC or IMS network may be implemented on the same apparatus 200.

[0096] FIG. 3 illustrates an example of a communication device 300, such as the UEs (e.g., UE-A and UE-B) illustrated in FIG. 1A. The communication device 300, which is also referred to herein as a user equipment (UE) and/or communication device, may be provided by any device capable of sending and receiving radio signals. Non-limiting examples comprise a user equipment, a mobile station (MS) or mobile device such as a mobile phone or what is known as a ’smart phone’, a computer provided with a wireless interface card or other wireless interface facility (e.g., USB dongle), a personal data assistant (PDA) or a tablet provided with wireless communication capabilities, a machine-type communications (MTC) device, an Internet of things (loT) type communication device or any combinations of these or the like. The terminal 300 may provide, for example, communication of data for carrying communications. The communications may be one or more of voice, electronic mail (email), text message, multimedia, data, machine data and so on.

[0097] The communication device 300 may receive signals over an air or radio interface 307 via appropriate apparatus for receiving and may transmit signals via appropriate apparatus for transmitting radio signals. In FIG. 3 transceiver apparatus is designated schematically by block 306. The transceiver apparatus 306 may be provided for example by means of a radio part and associated antenna arrangement. The antenna arrangement may be arranged internally or externally to the mobile device.

[0098] The communication device 300 may be provided with at least one processor 301 , at least one memory ROM 302a, at least one RAM 302b and other possible components 303 for use in software and hardware aided execution of tasks it is designed to perform, including control of access to and communications with access systems and other communication devices. The at least one processor 301 is coupled to the RAM 302b and the ROM 302a. The at least one processor 301 may be configured to execute an appropriate software code 308. The software code 308 may for example allow to perform one or more of the present aspects. The software code 308 may be stored in the ROM 302a.

[0099] The processor, storage and other relevant control apparatus can be provided on an appropriate circuit board and/or in chipsets. This feature is denoted by reference 304. The device may optionally have a user interface such as key pad 305, touch sensitive screen or pad, combinations thereof or the like. Optionally one or more of a display, a speaker and a microphone may be provided depending on the type of the device.

[0100] As mentioned above, the following provides examples in which a communication device (e.g., a UE) is configured to provide an IMS network with an indication of its avatar calling capability, and, potentially, a default avatar identifier to be used to depict a user associated with the communication device (e.g., UE) in a video stream provided by the communication device (e.g., UE) during an avatar call.

[0101] Referring to FIG. 4, a procedure for registration of a communication device (e.g., UE) with an IMS network in which the communication device (e.g., UE) indicates its avatar calling capability to the IMS network is shown. Referring to FIG. 5 a procedure for setting up or establishing an IMS session for avatar calling is shown. These FIGS, illustrate how avatar calling capability of at least one communication device (e.g., UE) may be signalled to the IMS network. These procedures may result in a more efficient setup for avatar calling.

[0102] FIG. 4 illustrates an IMS registration procedure in which a UE indicates its avatar call capability during IMS registration (e.g., when the UE is registering with an IMS network serving the UE).

[0103] The avatar call capability, described in more detail below, may indicate whether the UE is configured to transmit and/or receive signalling for participating in an avatar. The avatar call capability may indicate whether the UE is able to generate a video that comprises avatar data, and/or to modify a video stream such that the modified video stream comprises avatar data. Stated differently, the avatar call capability may indicate whether the UE is capable of avatar rendering. During IMS registration, the UE may register with an IMS network by sending a registration request (e.g., an IMS registration request or a SIP registration message) to the IMS network serving the UE that includes at least the UE’s avatar calling capabilities.

[0104] The IMS registration procedure illustrated in FIG. 4 involves UE-A 401 , an CSCF 402, a DAC 403, an IMS-AS 404, an XR-server 405, and a UDM and/or HSS 406 (labelled herein as UDM/HSS). All of these entities may be comprised as part of the originating network.

[0105] During 4001 , the UDM/HSS is configured to store an association between an avatar identifier and a respective IMS-based identifier. Stated differently, the UDM/HSS is configured to be provisioned with an avatar in the IMS network by associating an avatar identifier with a respective IMS identifier (e.g., an IP Multimedia Public User Identity, IMPU) and/or other identifier (e.g., Generic Public Subscription Identifier, GPSI). This provisioning can be done out of band, for example, by the user associated with the UE calling customer care to provide the avatar the user wishes to use and the customer care provisions the IMS network (e.g., the UDM/HSS) with the avatar identifier of the avatar with a respective IMS identifier or using a web portal where user associated with IIE-A selects the avatar it wishes to use for avatar calling and the IMS network stores (e.g., in the UDM/HSS) the mapping of an avatar identifier to its associated IMS identity.

[0106] During 4002, UE-A 401 sends SIP signalling to the IMS network (e.g., the IMS AS 404). This SIP signalling may comprise a SIP registration message. This SIP signalling may comprise an indication of whether UE-A supports avatar calling. Stated differently, UE-A sends SIP signalling to an IMS application server that comprises an avatar calling capability indication of the UE-A. The avatar calling capability indicates that the communication device is capable of avatar calling. The avatar calling capability may indicate whether UE-A supports avatar rendering. This is described further below. This signalling may comprise an indication of whether UE-A is capable of supporting avatar rendering at UE-A.

[0107] In general, a UE may be said to support avatar calling when the UE is able to participate in an avatar call (with the help of an IMS network to modify a video stream to comprise avatar media). A UE may be said to be capable of supporting avatar rendering when the UE is able to locally modify a video stream to comprise avatar media at the UE. This SIP signalling may comprise an indication of a default avatar identifier to be used for UE-A (e.g., avatar identifier A1 ). This SIP signalling may be comprised in a header of the SIP signalling.

[0108] Stated differently, during 4002, UE-A 401 may send SIP signalling (e.g., a SIP registration message) that comprises at least one of the two new types of capability feature capability headers or that comprises a new header indicating whether UE-A:

• Supports avatar Calling: True/False (This UE capability defines if the UE is capable of participating in avatar calling or not. This may be regardless of whether the UE is able to support Avatar rendering); and/or

• Supports Avatar rendering at UE: True/False (This capability defines if the UE is capable of introducing avatar media into a video stream. Stated differently, this capability defines whether the UE is capable of modifying and/or generating a video stream at the UE so that the modified and/or generated video stream comprises avatar media).

[0109] UE-A can also provide default avatar identifier when this is configured in UE- A (e.g., in local cache or previously retrieved by UE-A).

[0110] During 4003, the IMS network checks whether UE-A is allowed to use the default avatar identifier. This check may be performed based on, for example, subscription data associated with UE-A and/or DAC data associated with UE-A. The IMS network may perform authentication of UE-A based on this indicated default avatar identifier. The IMS AS 404 and/or XR server 405 may also cache the default avatar identifier when this is signalled.

[0111] 4004 to 4005 may be performed when the IMS network supports avatar calling.

[0112] During 4004, the IMS AS 404 sends signalling to the UDM/HSS 406. This signalling may be a request that the UDM/HSS 406 map the default avatar identifier to the IMPU associated with the present IMS session (e.g., an ongoing IMS session). When a default avatar identifier is not provided during 4002, the UDM selects the avatar identifier associated with the IMPU.

[0113] During 4005, the UDM/HSS 406 sends signalling to the IMS AS 404 which confirms that the mapping has been performed.

[0114] Although 4004 to 4005 are shown as involving the UDM/HSS 406, it is understood that this signalling may instead be sent by the DAC 403, where IMS AS requests that the DAC performs the mapping.

[0115] When the received default Avatar ID is not allowed to be mapped to that user identity, the UDM/HSS and/or DAC may reject the request. The default Avatar ID may not be allowed to be mapped to that user identity when, for example, a user has only has a single IMPU that is not allowed to be associated with avatar media. Alternatively, the UDM/HSS and/or DAC may overwrite with the allowed avatar Id available in the network and/or DAC when the default Avatar identifier is not allowed. [0116] During 4006, the IMS AS 404 sends SIP signalling to UE-A 401. This SIP signalling may comprise an indication of whether the IMS network supports avatar calling. This SIP signalling may include an indication whether the IMS network supports avatar rendering at the UE and/or the IMS network. For example, the IMS network may be configured to prioritize performing avatar rendering at the IMS network, and so the SIP signalling may include an indication that the IMS network does not support avatar rendering at the UE. Similarly, the IMS network may be configured to prioritize performing avatar rendering at the UE, and so the SIP signalling may include an indication that the IMS network does not support avatar rendering at the network. The indication of whether the IMS network supports avatar calling and/or the IMS network supports avatar rendering at the UE and/or the IMS network may be comprised in a header of SIP signalling, such as for example in a header of a SIP 200 OK message.

[0117] Stated differently, during 4006, the UE-A receives, from the IMS application server, a SIP response comprising an indication whether an IMS network that comprises the IMS application server allows avatar calling.

[0118] Stated differently, during 4006, the IMS network indicates whether the IMS network supports avatar calling and avatar rendering. This may be indicated by, including new information elements and/or headers in a 200 OK response that indicate:

• Allowed avatar Calling: True/False, where if the IMS network does not support IMS avatar calling, it is set to False. This network capability defines if the network is capable of supporting avatar calling or not. This may be regardless of whether the network is able to support Avatar rendering; and/or

• Allowed avatar rendering at UE-A: True/False, where if the IMS network does not support avatar rendering at UE-A, then it is set to False.

[0119] During 4007, UE-A can enable or disable avatar calling at UE-A based on the indication of 4006.

[0120] During 4008, UE-A signals the XR server 405. This signaling may comprise a request to download information related to the default avatar identifier (e.g., avatar media and/or metadata). For example, this signaling may comprise an indication of the default avatar identifier (A1 ), a session identifier, and/or an identifier of UE-A.

[0121] During 4009, the XR server 405 sends signalling to UE-A 401 . This signaling comprises information defining a representation of the default avatar corresponding to the default avatar identifier. Stated differently, this signalling comprises avatar metadata. This signalling may further comprise avatar media when the UE-A 401 is configured to perform avatar rendering locally. Although 4008 to 4009 are shown being sent by the XR server 405, it is understood that this signalling may instead be sent by the DAC 403, where IIE-A or the XR server requests that the DAC provides the information related to the default avatar.

[0122] Referring to FIG. 5, a procedure for setting up an IMS audio call between an originating UE (UE-A) and a terminating UE (IIE-B) via an IMS network is shown, in which an originating UE indicates its avatar calling capability to the IMS network. The avatar call capability may indicate whether the UE is configured to transmit and/or receive signalling for participating in an avatar. The avatar call capability may indicate whether the UE is able to generate a video that comprises avatar data, and/or to modify a video stream such that the modified video stream comprises avatar data. Stated differently, the avatar call capability may indicate whether the UE is capable of performing avatar rendering.

[0123] FIG. 5 illustrates an IMS call setup procedure in which a UE indicates its avatar calling capability to an IMS network when performing call setup with another UE via an IMS network.

[0124] FIG. 5 illustrates signalling that may be performed between UE-A 501 , CSCF 502, a DAC 503, an IMS AS 504, a UDM/HSS 505, a terminating IMS network 506, and UE-B 507. The terminating IMS network 506 and UE-B may be comprised as part of a terminating network. The UE-A 501 , CSCF 502, DAC 503, IMS AS 504, and UDM/HSS 505 may be comprised as part of an originating network.

[0125] During 5001 , the UDM/HSS is configured to store an association between an avatar identifier and a respective IMS-based identifier. Stated differently, the UDM/HSS is configured to be provisioned with an avatar in the IMS network by associating an avatar identifier with a respective IMS identifier (e.g., an IP Multimedia Public User Identity, IMPU) and/or other identifier (e.g., Generic Public Subscription Identifier, GPSI). This provisioning can be done out of band, for example, by the user associated with the UE calling customer care to provide the avatar the user wishes to use and the customer care provisions the IMS network (e.g., the UDM/HSS) with the avatar identifier of the avatar with a respective IMS identifier or using a web portal where user associated with UE-A selects the avatar it wishes to use for avatar calling and the IMS network stores (e.g., in the UDM/HSS) the mapping of an avatar identifier to its associated IMS identity.

[0126] During 5002, IIE-A 501 sends SIP signalling to the IMS network (e.g., the IMS AS 504). This SIP signalling may comprise a SIP INVITE request message for establishing a call to the terminating IIE-B via the originating and terminating IMS network. This SIP signalling may comprise an indication of whether IIE-A supports avatar calling. Stated differently, IIE-A sends SIP signalling to an IMS application server that comprises an avatar calling capability indication of the IIE-A. The avatar calling capability indicates that the communication device is capable of avatar calling. The avatar calling capability may indicate whether IIE-A supports avatar rendering. This is described further below. This SIP signalling may comprise an indication of whether IIE-A is capable of supporting Avatar rendering at IIE-A. This SIP signalling may be comprised in a header of the SIP signalling.

[0127] Stated differently, during 5002, IIE-A 501 may send SIP signalling (e.g., a SIP INVITE request message) that comprises indications of whether IIE-A:

• Supports avatar Calling: True/False (This UE capability defines if the IIE-A is capable of participating in avatar calling or not. This may be regardless of whether the UE is able to support Avatar rendering); and/or

• Supports Avatar rendering at UE: True/False (This capability defines if the UE-A is capable of introducing avatar media into a video stream. Stated differently, this capability defines whether the UE is capable of modifying and/or generating a video stream at the UE so that the modified and/or generated video stream comprises avatar media).

[0128] These may be as described above in relation to FIG. 4.

[0129] During 5003, the IMS AS 504 selects an avatar identifier associated with the IMPU of the UE-A. This avatar identifier may comprise the avatar identifier previously stored according to FIG. 4.

[0130] During 5004, the IMS AS 504 sends SIP signalling (e.g., a SIP INVITE request message) to UE-B 507. This SIP signalling may comprise a SIP request message (e.g., a SIP INVITE request message, also referred to as a SIP INVITE) for establishing (e.g., setting up) a call between UE-A and UE-B. This SIP signalling may comprise an indication of the capabilities of IIE-A that were comprised in the SIP signalling of 5002.

[0131] During 5005, IIE-B 507 sends SIP signalling to IMS AS 504. This SIP signalling may comprise indications of whether IIE-B:

• Supports avatar Calling: True/False (This capability defines if IIE-B is capable of participating in avatar calling or not. This may be regardless of whether the IIE-B is able to support Avatar rendering); and/or

• Supports Avatar rendering at UE client: True/False (This capability defines if IIE-B is capable of introducing avatar media into a video stream. Stated differently, this capability defines whether the IIE-B is capable of modifying and/or generating a video stream at the IIE-B so that the modified and/or generated video stream comprises avatar media).

[0132] These may be as described above in relation to FIG. 4 in relation to IIE-A. [0133] The SIP signaling of 5005 may be comprised in a SIP 200 OK message.

[0134] During 5006, the IMS AS 504 sends SIP signalling UE-A 501. This SIP signalling may forward the avatar calling capability indications of 5005 relating to IIE-B 507 to UE-A 501 via the terminating and originating IMS network. The SIP signalling of 5006 may be comprised in a SIP 200 OK message.

[0135] The SIP signalling of 5006 further comprises an indication of whether UE-A 501 should enable or disable avatar calling and/or Avatar rendering to UE-B. This indication may be determined by the network based on the indications of 5006 and the capabilities of UE-A 501 signalled during 5002.

[0136] During 5007, UE-A 501 enables or disables avatar calling and/or Avatar rendering based on the indication of 5006. UE-A 501 subsequently conducts a call to UE-B based on this enablement or disablement (e.g., without avatar calling when avatar calling is disabled, with avatar calling when avatar calling is enabled, etc.).

[0137] These call signal flows illustrate several features that may be useful for addressing at least one of the issues discussed above.

[0138] For example, a UE may provision an avatar in the IMS network by associating an avatar ID with a specific IMS identifier (e.g., IMPU) and/or other identifiers (e.g., GPSI). The network may store the mapping of avatar identifier to IMS identity. [0139] The UE may provide an avatar call capability indication to the IMS network when the UE registers with the IMS network or when the UE requests the IMS network set up an IMS session. The UE may provide an avatar call capability indication to the IMS network by including the avatar calling capability indication in a new header of a SIP request message (e.g., a SIP registration message or a SIP invite request message) and sending the SIP request message comprising the new header to the IMS network (e.g., the IMS application server of the IMS network). Alternatively, the UE may provide an avatar call capability indication to the IMS network by including the avatar calling capability indication in a feature capability header field of a SIP request message (generally referred to herein as a Feature- Caps header field.

[0140] The UE may also provide the IMS network with an indication of further avatar-related capabilities of the UE , e.g., Avatar rendering capability .

[0141] The UE may further provide the IMS network with a default avatar identifier that identifies an avatar to be considered as a “default avatar”. This may be accompanied with additional avatar metadata, as discussed above. The IMS network and/or other UE can use the default avatar identified by this default identifier to render the user associated with the UE in video stream when no other avatar identifier is selected by the UE for an avatar call.

[0142] When UE avatar calling capabilities are included in SIP registration request sent by the UE, the IMS network can use this information as default avatar information for that user for the registration lifetime of the UE. Stated differently, when another avatar identifier and associated metadata is provided during a call setup and/or call update operation, that another avatar identifier and associated metadata will take precedence over the “default” avatar identifier provided at registration time.

[0143] The IMS server (e.g., S-CSCF, IMS AS) stores the UE’s avatar capability in the registration context.

[0144] When an avatar identifier is provided by a UE, the IMS Server verifies with the UDM/HSS or the DAC whether the user identity associated with that UE (e.g., the subscriber associated with that UE) is allowed to use the avatar identified by the avatar identifier during the lifetime of the UE’s registration with the IMS network. If the user is allowed, the same avatar identifier is provided in the response to the registration request for registering with the IMS network (e.g., the IMS registration request sent by the UE). If the user identity is not allowed, the registration may be rejected, or may be approved, with no avatar identifier in the registration response, or may be approved with a different avatar identifier in the registration response (e.g., a new “default” avatar identifier is defined by the IMS server for the UE).

[0145] If avatar calling is allowed in the IMS network or supported in the IMS network, then the IMS network may provide an indication to the UE that avatar calling is allowed for this IMS registration.

[0146] It is understood that even when the UE has not provided a “default” avatar identifier in the UE’s registration request (e.g., IMS registration request), the IMS network can provide an avatar identifier in the response to the UE’s registration request to be used by the UE as a default avatar identifier in subsequent actions. This default avatar identifier may or may not be related to the user identity being registered. This default avatar identifier may be used by the UE to retrieve the associated avatar metadata to this default avatar identifier at a later stage. It is possible to retrieve the associated avatar metadata during the registration for the future use during IMS avatar call. The default avatar associated with this default avatar identifier can be stored in the HSS and/or DAC, or on an entity outside of the IMS network.

[0147] A UE’s avatar call capability and/or avatar rendering capability may also be included by a UE in SIP INVITE requests or responses, even if the UE is not establishing an IMS session for an avatar call or negotiating for an IMS session for an avatar call immediately. This may enable the UE to indicate that the UE is able to switch from an audio or video call to avatar call at some point during an IMS session.

[0148] When a UE receives an indication that avatar calling is allowed (e.g., from the IMS network or another UE with which the UE intends to establish an avatar call), then the UE knows it can make an avatar call based on its UE avatar capability. [0149] The avatar identifier in the above can be mapped to an associated IMS identity based on a configuration defined by a policy of the operator of the IMS network. For example, a user can define more than one IMPU and assign different avatar ld(s) to each IMPU. This information can be provided by the user to the IMS network via different means (out of band) for use in configuring the HSS and/or UDM with the mapping. This configuring may be performed by the UE that subsequently sends signalling to the IMS network that includes an indication of the UE’s avatar capability (e.g., by IIE-A in FIGS. 4 and 5, above).

[0150] This association between the IMPU and the different avatar identifiers can additionally or alternatively be configured in the DAC.

[0151] In a further option a UE can provide a mapping of IMPU to avatar identifier in SIP signaling to the IMS network, e.g., during IMS registration.

[0152] When an IMPU is used by the user equipment or IMS network for a specific user equipment to be used in an avatar call, a corresponding avatar identifier to that IMPU may also be selected for mapping to that IMPU. The corresponding avatar identifier may be a default avatar identifier that was selected by the network, as described above. As part of the selection process, the IMS network may verify that the selected avatar is authorized for use for the specific user equipment. Subsequently, when the IMPU is associated with a session for an avatar call and no other avatar identifier has been selected by that specific user equipment for the session, the corresponding avatar identifier is used as a default avatar identifier for the specific user equipment for avatar calling. A UE may select different, respective, IMPUs for different avatar calls.

[0153] A UE may also be able to update and/or remove the avatar currently being used for communications (and/or currently registered as a default avatar for that UE) using the avatar identifier corresponding to that avatar. The corresponding IMS identity and/or avatar association may be updated in the IMS network, e.g., at UDM/HSS or DAC. In case of the avatar deletion, the UE clears an avatar identifier associated to the avatar being deleted and any metadata associated to that avatar identifier from its local cache.

[0154] FIGS. 6 and 7 illustrate features of the above examples. It is therefore understood that examples mentioned above may describe features having function correspondence to features mentioned below. Further, it is understood that the following described examples may be further understood with reference to the above examples. [0155] FIG. 6 illustrates operations that may be performed by a communication device. The communication device may comprise a UE. The communication device of FIG. 6 may perform functions mentioned above with reference to IIE-A.

[0156] During 601 , the communication device sends a session initiation protocol, SIP, request, to an internet protocol multimedia subsystem, IMS, application server, the SIP request comprising an avatar calling capability indication, wherein the avatar calling capability indication indicates that the communication device is capable of avatar calling. The capability indication may be comprised in a SIP header. However, it is understood that this is merely one example of how the capability indication may be signalled.

[0157] During 602, the communication device receives, from the IMS application server, a SIP response comprising an indication whether an IMS network that comprises the IMS application server allows avatar calling.

[0158] The communication device may be configured to enable avatar calling based on the indication indicating that the IMS network allows avatar calling, and disable avatar calling based on the indication indicating that the IMS network does not allow avatar calling. The communication device therefore performs avatar calling when avatar calling is enabled, or performs a non-avatar audio video call when avatar calling is enabled or disabled.

[0159] The SIP response received from the IMS application server may further comprise an indication of whether the IMS network supports avatar rendering at the communication device. The communication device may be configured to perform: enabling avatar rendering at the communication device based on the indication indicating that the IMS network supports avatar rendering at the communication device; and disabling avatar rendering at the communication device based on the indication indicating that the IMS network does not support avatar rendering at the communication device.

[0160] FIG. 7 illustrates operations that may be performed by an internet protocol multimedia application, IMS, application server.

[0161] During 701 , the IMS AS receives, from a communication device (e.g., the communication device of FIG. 7), a session initiation protocol, SIP, request, the SIP request comprising an avatar calling capability indication, wherein the avatar calling capability indication indicates that the communication device is capable of avatar calling.

[0162] During 702, the IMS AS signals, to the communication device, a SIP response comprising an indication whether an IMS network that comprises the IMS application server allows avatar calling.

[0163] The IMS AS may determine a default avatar that identifies an avatar to be used by the communication device as a default avatar for avatar calling originating from the communication device, and provide an identifier of the default avatar to the communication device.

[0164] How the default avatar is determined may be performed in at least one of a plurality of different ways.

[0165] For example, the determining the default avatar may comprise extracting, from the SIP request message, an avatar identifier identifying an avatar to be used as a default avatar for avatar calling originating from the communication device, and verifying that the communication device is authorized to use the extracted avatar identified by the identifier as a default avatar for avatar calling.

[0166] For example, the determining the default avatar may comprise using an IMS identifier of the communication device to retrieve IMS subscription information associated with the communication device, verifying, using the subscription information, at least one avatar that the communication is authorized to use, and selecting a default avatar from the verified at least one avatar.

[0167] The using an IMS identifier of the communication device to retrieve IMS subscription information associated with the communication device may comprise using the IMS identifier to retrieve and verify at least one avatar and/or at least one avatar identifier from a home subscriber system and/or a unified data management system.

[0168] The following may apply to each of the apparatus of FIG. 6 and FIG. 7.

[0169] The IMS identifier may comprise an IMS public user identity.

[0170] The SIP request message may further comprise an indication of an avatar rendering capability of the communication device, wherein the avatar rendering capability of the communication device indicates whether the communication device is capable of avatar rendering. [0171] The communication device may be considered capable of avatar rendering when the communication device is able to modify a video stream by inserting avatar metadata and/or avatar media into the video stream to produce a modified video stream that comprises an avatar and/or to generate a video stream using avatar metadata and/or avatar media, and sensor data from at least one sensor of the communication device.

[0172] The SIP request message may further comprise an identifier of an avatar to be used as a default avatar for avatar calling originating from the communication device.

[0173] The SIP response received from the IMS application server may further comprise an indication of whether the IMS application server supports avatar calls.

[0174] The SIP response received from the IMS application server may further comprise an indication of whether the IMS network supports avatar rendering at the communication device.

[0175] The SIP response may further comprise a default avatar identifier that identifies an avatar to be used by the communication device as a default avatar for avatar calling originating from the communication device.

[0176] The SIP response may further comprise, at least one of: an indication of whether a second communication device supports avatar calling, or an indication of whether the second communication device supports avatar rendering.

[0177] The SIP request message may comprise a session initiation protocol invite message or a session initiation protocol registration message.

[0178] The SIP response may comprise a session initiation protocol 200 OK message or a session initiation protocol provisional acknowledgement message.

[0179] At least one of the avatar calling capability indication or avatar rendering may be transmitted in a session initiation protocol message header or a session description protocol message.

[0180] At least one of the communication device or IMS application server may be caused to perform: determining that the communication device is to no longer use avatar calling; and deleting at least one avatar comprised in a local cache of the communication device or IMS application server. [0181] It should be understood that the apparatuses may comprise or be coupled to other units or modules etc., such as radio parts or radio heads, used in or for transmission and/or reception. Although the apparatuses have been described as one entity, different modules and memory may be implemented in one or more physical or logical entities.

[0182] It is noted that whilst some embodiments have been described in relation to 5G networks, similar principles can be applied in relation to other networks and communication systems, such as 6G and beyond. Therefore, although certain embodiments were described above by way of example with reference to certain example architectures for wireless networks, technologies and standards, embodiments may be applied to any other suitable forms of communication systems than those illustrated and described herein.

[0183] It is also noted herein that while the above describes example embodiments, there are several variations and modifications which may be made to the disclosed solution without departing from the scope of the present invention.

[0184] As used herein, “at least one of the following: <a list of two or more elements>” and “at least one of <a list of two or more elements>” and similar wording, where the list of two or more elements are joined by “and” or “or”, mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

[0185] In general, the various embodiments may be implemented in hardware or special purpose circuitry, software, logic or any combination thereof. Some aspects of the disclosure may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the disclosure is not limited thereto. While various aspects of the disclosure may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof. [0186] As used in this application, the term “circuitry” may refer to one or more or all of the following:

(a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry) and

(b) combinations of hardware circuits and software, such as (as applicable):

(i) a combination of analog and/or digital hardware circuit(s) with software/firmware and

(ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions); and

(c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.”

[0187] This definition of circuitry applies to all uses of the term “means” in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a processor integrated circuit for a communication device (e.g., UE) or a similar integrated circuit in server, a cellular network device, or other computing or network device.

[0188] The embodiments of this disclosure may be implemented by computer software executable by a data processor of the mobile device, such as in the processor entity, or by hardware, or by a combination of software and hardware. Computer software or program, also called program product, including software routines, applets and/or macros, may be stored in any apparatus-readable data storage medium and they comprise program instructions to perform particular tasks. A computer program product may comprise one or more computer-executable components which, when the program is run, are configured to carry out embodiments. The one or more computer-executable components may be at least one software code or portions of it. [0189] Further in this regard it should be noted that any blocks of the logic flow as in the Figures may represent program steps, or interconnected logic circuits, blocks and functions, or a combination of program steps and logic circuits, blocks and functions. The software may be stored on such physical media as memory chips, or memory blocks implemented within the processor, magnetic media such as hard disk or floppy disks, and optical media such as for example DVD and the data variants thereof, CD. The physical media is a non-transitory media.

[0190] The term “non-transitory,” as used herein, is a limitation of the medium itself (i.e. , tangible, not a signal ) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM).

[0191] The memory may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The data processors may be of any type suitable to the local technical environment, and may comprise one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASIC), FPGA, gate level circuits and processors based on multi core processor architecture, as non-limiting examples.

[0192] Embodiments of the disclosure may be practiced in various components such as integrated circuit modules. The design of integrated circuits is by and large a highly automated process. Complex and powerful software tools are available for converting a logic level design into a semiconductor circuit design ready to be etched and formed on a semiconductor substrate.

[0193] The scope of protection sought for various embodiments of the disclosure is set out by the independent claims. The embodiments and features, if any, described in this specification that do not fall under the scope of the independent claims are to be interpreted as examples useful for understanding various embodiments of the disclosure.

[0194] The foregoing description has provided by way of non-limiting examples a full and informative description of the exemplary embodiment of this disclosure. However, various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings and the appended claims. However, all such and similar modifications of the teachings of this disclosure will still fall within the scope of this invention as defined in the appended claims. Indeed, there is a further embodiment comprising a combination of one or more embodiments with any of the other embodiments previously discussed.

Claims

1 . A communication device comprising: means for sending a session initiation protocol, SIP, request, to an internet protocol multimedia subsystem, IMS, application server, the SIP request comprising an avatar calling capability indication, wherein the avatar calling capability indication indicates that the communication device is capable of avatar calling; and means for receiving, from the IMS application server, a SIP response comprising an indication whether an IMS network that comprises the IMS application server allows avatar calling.

2. The communication device of claim 1 , further comprising: means for enabling avatar calling based on the indication indicating that the IMS network allows avatar calling; and means for disabling avatar calling based on the indication indicating that the IMS network does not allow avatar calling.

3. The communication device of claim 1 or 2, wherein the SIP response received from the IMS application server further comprises an indication of whether the IMS network supports avatar rendering at the communication device.

4. The communication device of claim 3, wherein the communication device further comprises: means for enabling avatar rendering at the communication device based on the indication indicating that the IMS network supports avatar rendering at the communication device; and means for disabling avatar rendering at the communication device based on the indication indicating that the IMS network does not support avatar rendering at the communication device.

5. The communication device of any of claims 1 to 4, wherein the SIP request message further comprises an indication of an avatar rendering capability of the communication device, wherein the avatar rendering capability of the communication device indicates whether the communication device is capable of avatar rendering.

6. The communication device of claim 5, wherein the communication device is considered capable of avatar rendering when the communication device is able to modify a video stream by inserting avatar metadata and/or avatar media into the video stream to produce a modified video stream that comprises an avatar and/or to generate a video stream using avatar metadata and/or avatar media, and sensor data from at least one sensor of the communication device.

7. The communication device of any of claims 1 to 6, wherein the SIP request message further comprises an identifier of an avatar to be used as a default avatar for avatar calling originating from the communication device.

8. The communication device of any of claims 1 to 7, wherein the SIP response further comprises an indication of whether the IMS application server supports avatar calls.

9. The communication device of any of claims 1 to 8, wherein the SIP response further comprises an indication of whether the IMS network supports avatar rendering at the communication device.

10. The communication device or IMS application server of any of claim 1 to 9, wherein the SIP response further comprises a default avatar identifier that identifies an avatar to be used by the communication device as a default avatar for avatar calling originating from the communication device.

11 . The communication device of any of claims 1 to 10, wherein the SIP response further comprises, at least one of: an indication of whether a second communication device supports avatar calling, or an indication of whether the second communication device supports avatar rendering.

12. The communication device of any of claims 1 to 11 , wherein the SIP request message comprises a session initiation protocol invite message or a session initiation protocol registration message.

13. The communication device of any of claims 1 to 12, wherein the SIP response comprises a session initiation protocol 200 OK message or a session initiation protocol provisional acknowledgement message.

14. The communication device of any of claims 1 to 13, wherein at least one of the avatar calling capability indication or avatar rendering are transmitted in a session initiation protocol message header.

15. The communication device of any of claims 1 to 14, further comprising: means for determining that the communication device is to no longer use avatar calling; and means for deleting at least one avatar comprised in a local cache of the communication device or IMS application server.

16. An internet protocol multimedia application, IMS, application server comprising: means for receiving, from a communication device, a session initiation protocol, SIP, request, the SIP request comprising an avatar calling capability indication, wherein the avatar calling capability indication indicates that the communication device is capable of avatar calling; and sending, to the communication device, a SIP response comprising an indication whether an IMS network that comprises the IMS application server allows avatar calling.

17. The IMS application server of claim 16, wherein further comprising: means for determining a default avatar that identifies an avatar to be used by the communication device as a default avatar for avatar calling originating from the communication device; and means for providing an identifier of the default avatar to the communication device.

18. The IMS application server of claim 17, wherein the means for determining a default avatar comprises: means for extracting, from the SIP request message, an avatar identifier identifying an avatar to be used as a default avatar for avatar calling originating from the communication device; and means for verifying that the communication device is authorized to use the extracted avatar identified by the identifier as a default avatar for avatar calling.

19. The IMS application server of claim 17, wherein the means for determining a default avatar comprises means for: means for using an IMS identifier of the communication device to retrieve IMS subscription information associated with the communication device; means for verifying, using the subscription information, at least one avatar that the communication is authorized to use; and means for selecting a default avatar from the verified at least one avatar.

20. The IMS application server of claim 19, wherein the means for using an IMS identifier of the communication device to retrieve IMS subscription information associated with the communication device comprise: means for using the IMS identifier to retrieve and verify at least one avatar and/or at least one avatar identifier from a home subscriber system and/or a unified data management system.

21 . The IMS application server of claims 19 or 20, wherein the IMS identifier comprises an IMS public user identity.

22. The IMS application server of any of claims 16 to 21 , wherein the SIP request message further comprises an indication of an avatar rendering capability of the communication device, wherein the avatar rendering capability of the communication device indicates whether the communication device is capable of avatar rendering.

23. The IMS application server of any of claims 16 to 22, wherein the SIP request message further comprises an identifier of an avatar to be used as a default avatar for avatar calling originating from the communication device.

24. The IMS application server of any of claims 16 to 23, wherein the SIP response further comprises an indication of whether the IMS application server supports avatar calls.

25. The IMS application server of any of claims 16 to 24, wherein the SIP response further comprises an indication of whether the IMS network supports avatar rendering at the communication device.

26. The IMS application server of any of claims 16 to 25, wherein the SIP response further comprises a default avatar identifier that identifies an avatar to be used by the communication device as a default avatar for avatar calling originating from the communication device.

27. The IMS application server of any of claims 16 to 26, wherein the SIP response further comprises, at least one of: an indication of whether a second communication device supports avatar calling, or an indication of whether the second communication device supports avatar rendering.

28. The IMS application server of any of claims 16 to 27, wherein the SIP request message comprises a session initiation protocol invite message or a session initiation protocol registration message.

29. The IMS application server of any of claims 16 to 28, wherein the SIP response comprises a session initiation protocol 200 OK message or a session initiation protocol provisional acknowledgement message.

30. The IMS application server of any of claims 16 to 29, wherein at least one of the avatar calling capability indication or avatar rendering are transmitted in a session initiation protocol message header.

31 . The IMS application server of any of claims 16 to 30, further comprising: means for determining that the communication device is to no longer use avatar calling; and means for deleting at least one avatar comprised in a local cache of the communication device or IMS application server.

32. A method of a communication device, the method comprising: sending a session initiation protocol, SIP, request, to an internet protocol multimedia subsystem, IMS, application server, the SIP request comprising an avatar calling capability indication, wherein the avatar calling capability indication indicates that the communication device is capable of avatar calling; and receiving, from the IMS application server, a SIP response comprising an indication whether an IMS network that comprises the IMS application server allows avatar calling.

33. A method of an internet protocol multimedia application, IMS, application server, the method comprising: receiving, from a communication device, a session initiation protocol, SIP, request, the SIP request comprising an avatar calling capability indication, wherein the avatar calling capability indication indicates that the communication device is capable of avatar calling; and sending, to the communication device, a SIP response comprising an indication whether an IMS network that comprises the IMS application server allows avatar calling.

34. A non-transitory computer-readable medium comprising instructions which when executed by at least one processor of a communication device cause the communication device to perform at least: sending a session initiation protocol, SIP, request, to an internet protocol multimedia subsystem, IMS, application server, the SIP request comprising an avatar calling capability indication, wherein the avatar calling capability indication indicates that the communication device is capable of avatar calling; and receiving, from the IMS application server, a SIP response comprising an indication whether an IMS network that comprises the IMS application server allows avatar calling.

35. A non-transitory computer-readable medium comprising instructions which when executed by at least one processor of an internet protocol multimedia application, IMS, application server cause the IMS application server to perform at least: receiving, from a communication device, a session initiation protocol, SIP, request, the SIP request comprising an avatar calling capability indication, wherein the avatar calling capability indication indicates that the communication device is capable of avatar calling; and sending, to the communication device, a SIP response comprising an indication whether an IMS network that comprises the IMS application server allows avatar calling.

36. A computer program comprising instructions which, when the computer program is executed by a communication device, cause the communication device to perform at least: sending a session initiation protocol, SIP, request, to an internet protocol multimedia subsystem, IMS, application server, the SIP request comprising an avatar calling capability indication, wherein the avatar calling capability indication indicates that the communication device is capable of avatar calling; and receiving, from the IMS application server, a SIP response comprising an indication whether an IMS network that comprises the IMS application server allows avatar calling.

37. A computer program comprising instructions which, when the computer program is executed by an internet protocol multimedia application, IMS, application server cause the IMS application server to perform at least: receiving, from a communication device, a session initiation protocol, SIP, request, the SIP request comprising an avatar calling capability indication, wherein the avatar calling capability indication indicates that the communication device is capable of avatar calling; and sending, to the communication device, a SIP response comprising an indication whether an IMS network that comprises the IMS application server allows avatar calling.