Methods and apparatus for security enhancement for avatar communication

Abstract

Methods, apparatus and computer-readable medium are disclosed for security enhancement for avatar communication. In an embodiment, there is provided a method performed at a user equipment (UE). The method comprises receiving from a first network entity, such as an internet protocol multimedia subsystem (IMS) application server, security information for avatar object of an avatar; receiving from a second network entity, such as an extended reality (XR) application server, avatar object of the avatar for UE centric rendering; and verifying authenticity of the avatar object received from the second network entity based on the security information.

Description

METHODS AND APPARATUS FOR SECURITY ENHANCEMENT FOR AVATAR COMMUNICATIONTECHNICAL FIELD

[0001] Embodiments of the disclosure generally relate to security in a communication system, and more particularly, to methods and apparatus for security enhancements in avatar communication for user equipment (UE) centric rendering.BACKGROUND

[0002] The 5th generation (5G) mobile communication system, including internet protocol (IP) multimedia subsystem (IMS) , is being developed to support metaverse services including avatar call functionality. A user can take part in mobile metaverse services that provide animated digital representations (e.g., three-dimension (3D) avatar) of several users simultaneously, for example, to support a conference using extended reality (XR) media. In these services, two or more users may communicate with each other using avatar representations associated with the users.

[0003] Avatar is a digital representation specific to media that encodes facial (possibly body) position, motions and expressions of a person or some software generated entity. The 5G mobile communication system supports communication of avatar that can be presented to other users as "avatar media" as well as audio and other media as needed. Avatar media is a media stream (e.g. video) that mixes gesture / movement using avatar metadata. Supporting avatar communication includes providing avatar or a reference to one or several avatars, downloading and negotiating the avatar with B-party, transferring avatar media, and rendering of avatar media. It is also desired to design a security mechanism for avatar communication.SUMMARY

[0004] This summary is provided to introduce simplified concepts of the present disclosure. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0005] According to a first aspect of the disclosure, there is provided an apparatus at a user equipment (UE) . The apparatus comprises at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to receive from a first  network entity, security information for avatar object of an avatar; receive from a second network entity, avatar object of the avatar for UE centric rendering; and verify authenticity of the avatar object received from the second network entity based on the security information.

[0006] According to some embodiments, when the instructions are executed by the at least one processor, the instructions may further cause the apparatus at least to: render the avatar based on the avatar object received from the second network entity, if the verifying of the authenticity of the avatar object received from the second network entity is successful.

[0007] According to some embodiments, the security information comprises a first hash of the avatar object of the avatar. The apparatus may be further caused at least to generate a second hash of the avatar object received from the second network entity; and determine whether the second hash matches the first hash or not.

[0008] According to some embodiments, the first hash is comprised in an avatar identifier of the avatar. Receiving the security information from the first network entity may comprises receiving the avatar identifier of the avatar comprising the first hash. The apparatus may be further caused at least to generate a local avatar identifier based on the second hash; and determine whether the generated local avatar identifier matches the avatar identifier received from the first network entity.

[0009] According to some embodiments, the avatar identifier of the avatar received from the first network entity further comprises at least one of: an initially fixed value of a unique identifier for the avatar; a message authentication code (MAC) ; or an indication of an algorithm used to generate the first hash. A value of the MAC may be generated based on a secret key, the initially fixed value of the unique identifier, and the first hash.

[0010] According to some embodiments, the avatar identifier of the avatar received from the first network entity is consisted of one of the following groups of information elements: a first group comprising an initially fixed value of a unique identifier for the avatar concatenated with the first hash; a second group comprising merely the first hash; a third group comprising an initially fixed value of a unique identifier for the avatar concatenated with the first hash and a message authentication code (MAC) , where a value of the MAC is generated based on a secret key, the initially fixed value of the unique identifier, and the first hash; or a fourth group comprising an initially fixed value of a unique identifier for the avatar concatenated with the first hash and an indication of an algorithm used to generate the first hash.

[0011] In case that the avatar identifier of the avatar comprises the MAC, the apparatus may be further caused at least to receive the secret key from the first network entity; and generate a MAC for the local avatar identifier, based on the received secret key, the initially fixed value of the unique identifier, and  the second hash. In case that the avatar identifier of the avatar comprises the indication of the algorithm, the second hash may be generated using an algorithm indicated by the indication.

[0012] According to some embodiments, the avatar object received from the second network entity may be signed avatar object. The security information comprises at least one of: a certificate for signing the avatar object of the avatar; or an address of a verification server for verifying the signed avatar object. The apparatus may be further caused at least to verify the signed avatar object using the certificate; or verify the signed avatar object by communicating with the verification server via the address of the verification server.

[0013] According to some embodiments, the security information may be received from the first network entity via a session initialization protocol (SIP) signaling during an extended reality (XR) media rending negotiation for rendering the avatar.

[0014] According to some embodiments, the avatar object is received from the second network entity via an application data channel.

[0015] According to some embodiments, the first network entity may be an internet protocol multimedia subsystem (IMS) application server.

[0016] According to some embodiments, the second network entity may be an extended reality (XR) application server.

[0017] According to some embodiments, the avatar object may comprise avatar metadata of the avatar.

[0018] According to a second aspect of the disclosure, there is provided an apparatus at a first network entity. The apparatus comprises at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to transmit to a user equipment (UE) , security information for avatar object of an avatar for UE centric rendering of the avatar.

[0019] According to some embodiments, when the instructions are executed by the at least one processor, the instructions may further cause the apparatus at least to receive the security information from a third network entity.

[0020] According to some embodiments, the security information may comprise a hash of the avatar object.

[0021] According to some embodiments, the hash of the avatar object may be comprised in an avatar identifier of the avatar. The apparatus may be further caused at least to receive an avatar identifier of  the avatar comprising the hash from the third network entity, and transmit the received avatar identifier to the UE.

[0022] According to some embodiments, the avatar identifier of the avatar further comprises at least one of: an initially fixed value of a unique identifier for the avatar; a message authentication code (MAC) ; or an indication of an algorithm used to generate the hash of the avatar object. A value of the MAC may be generated based on a secret key, the initially fixed value of the unique identifier, and the hash of the avatar object.

[0023] According to some embodiments, the avatar identifier of the avatar may be consisted of one of the following groups of information elements: a first group comprising an initially fixed value of a unique identifier for the avatar concatenated with the hash; a second group comprising merely the hash; a third group comprising an initially fixed value of a unique identifier for the avatar concatenated with the hash and a message authentication code (MAC) , where a value of the MAC is generated based on a secret key, the initially fixed value of the unique identifier, and the hash; or a fourth group comprising an initially fixed value of a unique identifier for the avatar concatenated with the hash and an indication of an algorithm used to generate the hash.

[0024] According to some embodiments, in case that the avatar identifier of the avatar comprises the MAC, the apparatus may be further caused at least to transmit the secret key to the third network entity for a generation of the avatar identifier of the avatar with the hash of the avatar object; and transmit the secret key to the UE.

[0025] According to some embodiments, the security information comprises at least one of: a certificate for signing the avatar object of the avatar; or an address of a verification server for verifying the signed avatar object.

[0026] According to some embodiments, when the instructions are executed by the at least one processor, the instructions may further cause the apparatus at least to: transmit the certificate to a third network entity.

[0027] According to some embodiments, the security information may be transmitted to the UE via a session initialization protocol (SIP) signaling during an XR media rending negotiation for rendering the avatar.

[0028] According to some embodiments, the first network entity may be an internet protocol multimedia subsystem (IMS) application server.

[0029] According to some embodiments, the third network entity may be a digital asset container (DAC) .

[0030] According to some embodiments, the avatar object of the avatar may comprise avatar metadata of the avatar.

[0031] According to a third aspect of the disclosure, there is provided an apparatus at a third network entity. The apparatus comprises at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to obtain security information for avatar object of an avatar for user equipment (UE) centric rendering of the avatar.

[0032] According to some embodiments, when the instructions are executed by the at least one processor, the instructions may further cause the apparatus at least to transmit the security information to a first network entity, for user equipment (UE) centric rendering of the avatar. The security information may be transmitted to the first network entity during an XR media rending negotiation for rendering the avatar. The first network entity may be an internet protocol multimedia subsystem (IMS) application server.

[0033] According to some embodiments, the security information may comprise a hash of the avatar object. The apparatus may be further caused at least to obtain the security information by generating the hash of the avatar object.

[0034] According to some embodiments, the hash of the avatar object may be comprised in an avatar identifier of the avatar. The apparatus may be further caused at least to generate the avatar identifier of the avatar comprising the hash; and transmit the generated avatar identifier of the avatar to a UE.

[0035] According to some embodiments, the avatar identifier of the avatar may further comprise at least one of: an initially fixed value of a unique identifier for the avatar; a message authentication code (MAC) ; or an indication of an algorithm used to generate the hash of the avatar object. A value of the MAC may be generated based on a secret key, the initially fixed value of the unique identifier, and the hash of the avatar object.

[0036] According to some embodiments, the avatar identifier of the avatar may be consisted of one of the following groups of information elements: a first group comprising an initially fixed value of a unique identifier for the avatar concatenated with the hash; a second group comprising merely the hash; a third group comprising an initially fixed value of a unique identifier for the avatar concatenated with the hash and a message authentication code (MAC) , where a value of the MAC is generated based on a secret key, the initially fixed value of the unique identifier, and the hash; or a fourth group comprising an initially fixed value of a unique identifier for the avatar concatenated with the hash and an indication of an algorithm used to generate the hash.

[0037] In case that the avatar identifier of the avatar comprises the MAC, the apparatus may be further caused at least to receive the secret key from the first network entity; and generate the MAC based on a secret key, the initially fixed value of the unique identifier, and the hash of the avatar object.

[0038] According to some embodiments, the security information comprises at least one of: a certificate for signing the avatar object; or an address of a verification server for verifying the signed avatar object. The apparatus may be further caused at least to obtain the security information by receiving the certificate from a first network entity.

[0039] According to some embodiments, the apparatus may be further caused at least to sign the avatar metadata with the certificate; or obtain a signed avatar object from a signing server.

[0040] According to some embodiments, the apparatus may be further caused at least to transmit the signed avatar object to a second network entity. The second network entity may be an extended reality (XR) application server.

[0041]

[0042] According to some embodiments, the third network entity is a digital asset container (DAC) .

[0043] According to some embodiments, the avatar object of the avatar comprises avatar metadata of the avatar.

[0044] According to a fourth aspect of the disclosure, there is provided a method performed at a user equipment (UE) . The method comprises receiving from a first network entity, security information for avatar object of an avatar; receiving from a second network entity, avatar object of the avatar for UE centric rendering; and verifying authenticity of the avatar object received from the second network entity based on the security information.

[0045] According to a fifth aspect of the disclosure, there is provided a method performed at a first network entity. The method comprises transmitting to a user equipment (UE) , security information for avatar object of an avatar for UE centric rendering of the avatar.

[0046] According to a sixth aspect of the disclosure, there is provided a method performed at a third network entity. The method comprises obtaining security information for avatar object of an avatar for user equipment (UE) centric rendering of the avatar.

[0047] According to a seventh aspect of the disclosure, there is provided an apparatus at a user equipment (UE) . The apparatus comprises means for receiving from a first network entity, security information for avatar object of an avatar; means for receiving from a second network entity, avatar  object of the avatar for UE centric rendering; and means for verifying authenticity of the avatar object received from the second network entity based on the security information.

[0048] According to an eighth aspect of the disclosure, there is provided an apparatus at a first network entity. The apparatus comprises means for transmitting to a user equipment (UE) , security information for avatar object of an avatar for UE centric rendering of the avatar.

[0049] According to a ninth aspect of the disclosure, there is provided an apparatus at a third network entity. The apparatus comprises means for obtaining security information for avatar object of an avatar for user equipment (UE) centric rendering of the avatar.

[0050] According to a tenth aspect of the disclosure, there is provided a computer readable storage medium, on which instructions are stored. When executed by at least one processor, the instructions cause the at least one processor to perform any method according to the fourth, fifth, or sixth aspect.

[0051] According to an eleventh aspect of the disclosure, there is provided computer program product comprising instructions which when executed by at least one processor, cause the at least one processor to perform any method according to the fourth, fifth, or sixth aspect.

[0052] It is to be understood that the summary section is not intended to identify key or essential features of embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become easily comprehensible through the following description.BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Some example embodiments will now be described with reference to the accompanying drawings in which:

[0054] FIG. 1 illustrates an exemplary procedure for establishment of network centric IMS avatar call using data channel;

[0055] FIG. 2 illustrates an exemplary procedure for establishment of UE-A centric IMS avatar call using data channel;

[0056] FIG. 3 illustrates an exemplary procedure for establishment of UE-B centric IMS avatar call using data channel;

[0057] FIG. 4 illustrates an exemplary procedure for person-to-application (P2A) application data channel setup;

[0058] FIG. 5 illustrates an exemplary scenario depicting a potential security problem in avatar communication;

[0059] FIG. 6 is a flow chart depicting an exemplary process according to an embodiment of the present disclosure;

[0060] FIG. 7 is a flow chart depicting another exemplary process according to an embodiment of the present disclosure;

[0061] FIG. 8 is a flow chart depicting yet another exemplary process according to an embodiment of the present disclosure;

[0062] FIG. 9 is a flow chart depicting yet another exemplary process according to an embodiment of the present disclosure;

[0063] FIG. 10 is a flow chart depicting a method performed at a UE according to an embodiment of the present disclosure;

[0064] FIG. 11 is a flow chart depicting another method performed at a first network (e.g., IMS application server) entity according to an embodiment of the present disclosure;

[0065] FIG. 12 is a flow chart depicting another method performed at a third network entity (e.g., DAC) according to an embodiment of the present disclosure; and

[0066] FIG. 13 is shows a simplified block diagram of an apparatus according to an embodiment of the present disclosure.DETAILED DESCRIPTION

[0067] Some example embodiments will now be described in more detail hereinafter with reference to the accompanying drawings, in which some, but not all embodiments are shown. Indeed, the example embodiments may take many different forms and should not be construed as fixed to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Like reference numerals refer to like elements throughout.

[0068] References in the present disclosure to “one embodiment” , “an embodiment” , “an example embodiment” , and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an example embodiment, it is submitted that it is within the knowledge of one skilled in the art to  affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0069] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

[0070] As used herein, the terms “data, ” “content, ” “information, ” and similar terms may be used interchangeably to refer to data capable of being transmitted, received and / or stored in accordance with embodiments of the present invention. Thus, use of any such terms should not be taken to limit the spirit and scope of embodiments of the present invention.

[0071] As used in this application, the term “circuitry” may refer to one or more or all of the following:

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

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

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

[0075] (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

[0076] (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.

[0077] This definition of “circuitry” applies to all uses of this term 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 baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

[0078] As defined herein, a “computer-readable storage medium, ” which refers to a non-transitory physical storage medium (e.g., volatile or non-volatile memory device) , can be differentiated from a “computer-readable transmission medium, ” which refers to an electromagnetic signal. Such a medium may take many forms, including, but not limited to a non-transitory computer-readable storage medium  (e.g., non-volatile media, volatile media) , and transmission media. Transmission media include, for example, coaxial cables, copper wire, fiber optic cables, and carrier waves that travel through space without wires or cables, such as acoustic waves and electromagnetic waves, including radio, optical and infrared waves. Signals include man-made transient variations in amplitude, frequency, phase, polarization or other physical properties transmitted through the transmission media. Examples of non-transitory computer-readable media include a magnetic computer readable medium (e.g., a floppy disk, hard disk, magnetic tape, any other magnetic medium) , an optical computer readable medium (e.g., a compact disc read only memory (CD-ROM) , a digital versatile disc (DVD) , a Blu-Ray disc, or the like) , a random access memory (RAM) , a programmable read only memory (PROM) , an erasable programmable read only memory (EPROM) , a FLASH-EPROM, or any other non-transitory medium from which a computer can read. The term computer-readable storage medium is used herein to refer to any computer-readable medium except transmission media. However, it will be appreciated that where embodiments are described to use a computer-readable storage medium, other types of computer-readable mediums may be substituted for or used in addition to the computer-readable storage medium in alternative embodiments.

[0079] In the following, certain embodiments are explained with reference to user equipment (UE) capable of avatar communication in a wireless communication system, e.g., via cells, base stations, WiFi access point or similar wireless transmitter and / or receiver nodes, providing access points for a radio access system. The radio access system may be a 3GPP access system, or a non-3GPP access system.

[0080] The UE may comprise any suitable device capable of at least receiving and transmitting signaling and data for avatar communication. For example, the UE can be handheld data processing device equipped with radio transceiver, data processing apparatus and user interface apparatus. Non-limiting examples include a mobile station (MS) such as a mobile phone or what is known as a “smart phone” , a portable computer such as a laptop or a tablet computer provided with a wireless interface card or other wireless interface facility, personal data assistant (PDA) provided with wireless communication capabilities, or any combinations of these or the like. Further examples include wearable wireless devices such as those integrated with watches or smart watches, eyewear, helmets, hats, clothing, ear pieces with cellular connectivity, jewelry and so on, universal serial bus (USB) sticks with cellular capabilities, modem data cards, machine type devices or any combinations of these or the like.

[0081] The embodiments provided in the present disclosure may be described with reference to a 5G mobile communication system. However, it would be appreciated that embodiments of the present disclosure would also be applied in other mobile communication systems, such as 5G-advanced  communication system, the sixth generation (6G) communication system, or other future communication systems.

[0082] As introduced above, two or more users may communicate with each other using avatar representations associated with the users. In the present disclosure, the terms “avatar representation” , “avatar object” , “avatar model” , and “base avatar” can be used interchangeable to refer to a digital representation (e.g., 3D avatar) associated with a user in avatar communication, which may include avatar metadata and avatar media. In an avatar communication, an avatar object of an avatar is identified via an avatar identity (denoted as Avatar-id) . Avatar metadata are accessible via an Avatar-id and can be fetched from a digital assert container (DAC) using the Avatar-id. An Avatar-id can be an integer, string, universally unique identifier (UUID) , or a uniform resource identifier (URI) (such as uniform resource name (URN) or uniform resource locator (URL) ) . Avatar metadata is the 2D / 3D representational content / model of an avatar stored in a file, which can be accessed via a URL. Avatar metadata are stored in the DAC. The avatar metadata, or a reference of the avatar metadata (e.g. identifier) , is associated per subscriber and / or per subscriber's user identifier.

[0083] Avatar communication supported by 5G mobile communication system includes providing avatar or a reference to one or several avatars, downloading and negotiating the avatar with B-party, transferring avatar media, and rendering of avatar media. For example, an IMS architecture specified in 3GPP TR 23.700-77 (v 0.5.0) can be used as basis architecture of the mobile communication system.

[0084] Rendering of avatar media can be performed by network, a UE (referred to as UE-A) in the originating network of an avatar call, or a UE (referred to as UE-B) in the terminating network. Accordingly, the avatar XR media rendering can be done in three manners: by network (called network centric rendering) , by UE-A (called UE-A centric rendering) or by UE-B (called UE-B centric rendering) . FIGs. 1 to 3 depict call flows to establish an avatar call of these three manners based on IMS.

[0085] FIG. 1 illustrates a call flow to establish a network centric avatar call with rendering avatar media in a network node, e.g., Media Function (MF)  / Media Resource Function (MRF) . In this procedure, avatar media of UE-A are transmitted to UE-B via MF / MRF. The main steps in the call flow are as follows.

[0086] At step 1, UE-A 101 initiates an IMS session and establishes audio and / or video session connections with UE-B 109. A bootstrap data channel is established at the same time for both the UE-A 101 and UE-B 109. The UE-A 101 would also download an avatar application and Avatar-id (s) of one or more avatar.

[0087] At step 2, the UE-A 101 decides to request network centric rendering of an avatar intended to use for the avatar call, based on its status such as power, signal, computing power, internal storage, etc. The UE-A 101 selects an Avatar-id of the avatar.

[0088] Then, at step 3, the UE-A 101 performs an XR media rendering negotiation between the UE-A 101 and IMS network with the Avatar-id of the avatar and an indication of network centric rendering preference. In this regard, the UE-A 101 may negotiate with the XR application server 107, by using the Avatar-id of the avatar and the indication of network centric rendering preference. The XR application server is responsible for XR service control related to XR communication, including XR session media control, XR media capability negotiation with UE (for example, UE-A 101) .

[0089] At step 4, if the negotiation result is successful in step 3, the UE-A 101 initiates new person-to-application (P2A) application data channels, which are used for XR data transmission between the UE-A 101 and the network. The procedure for establishing a P2A application data channel would be described later with reference to FIG. 4. During the P2A application data channel establishment procedure, a data channel signaling function (DCSF) 105 will instruct the MF / MRF 106 via an IMS application server (AS) 104 how to establish the data channel and corresponding media processing specification.

[0090] Optionally, at step 5, a media re-negotiation between UE-A 101 and the IMS network is performed for anchoring UE-A’s audio / video media to the MF / MRF 106. In this regard, the IMS AS 104 may initiate a media re-negotiation request with UE-A 101 by exchanging the Avatar-id via an application data channel, to connect UE-A's audio / video media stream to the MF / MRF 106. The UE-A 101 provides to the XR application server 107 via the application data channel the Avatar-id of the avatar intended to use for the avatar call.

[0091] At step 6, a media re-negotiation between UE-B 109 and the IMS network is performed for anchoring UE-B’s audio / video media to the MF / MRF 106. In this regard, the IMS AS 104 may initiate a media re-negotiation request with the UE-B 109, to connect UE-B's audio / video media stream to the MF / MRF 106. The Avatar-id is exchanged with UE-B 109 to indicate about the avatar session during the signaling. The UE-B 109 has an option to reject the avatar alone or terminate the session based on the Avatar-id.

[0092] At step 7, if the re-negotiation at step 6 is successful, the IMS AS 104 may request the XR application server 107 to start the network centric rendering operation with the Avatar-id of the avatar.

[0093] Then, at step 8, the XR application server 107 retrieves avatar metadata of the avatar using the Avatar-id from the DAC 103, e.g. by sending a request for the avatar metadata with the Avatar-id. The DAC 103 responds to the XR application server 107 with the avatar metadata, as shown at step 9.

[0094] At step 10, the XR application server 107 starts controlling the XR media rendering. In this regard, the XR application server 107 may decide to send the received avatar metadata to the MF / MRF 106 based on the indication of network centric rendering preference.

[0095] Then, at step 11, the XR application server 107 sends the received avatar metadata to the MF / MRF 106 and requests rendering of the avatar by the MF / MRF 106 for network centric rendering.

[0096] After receiving a successful response from the MF / MRF 106, the XR application server 107 starts controlling the XR media rendering at step 12, and forwards the response to the UE-A 101 indicating a readiness of the network centric rendering, as shown at step 13.

[0097] At step 14, the UE-A 101 sends XR information about UE-A, such as audio and / or video media for rendering, to the MF / MRF 106.

[0098] At step 15, the MF / MRF 106 performs XR media rendering. In this regard, it may receive the XR information of UE-A from the UE-A 101 and replace the face / body with the selected avatar metadata, e.g. via face detection and / or recognition mechanisms.

[0099] Then, the rendered avatar media (including audio and / or video) is sent as regular video media to the UE-B at step 16, and sent back to the UE-A 101 as feedback (same content as the one sent to the UE-B in step 16) , e.g. to display a thumbnail view of the avatar to the UE-A 101 in the IMS session, as shown at step 17.

[0100] FIG. 2 illustrates a call flow to establish a UE centric avatar call with rendering avatar media in the UE-A. The main steps in the call flow are as follows.

[0101] At step 1, UE-A 201 initiates an IMS session and establishes audio and / or video session connections with UE-B 209. A bootstrap data channel is established at the same time for both the UE-A 201 and UE-B 209. The UE-A 201 would also download an avatar application and Avatar-id (s) of one or more avatar.

[0102] At step 2, the UE-A 201 decides to request UE-A media rendering of an avatar intended to use for the avatar call, based on its status such as power, signal, computing power, internal storage, etc. The UE-A 201 selects an Avatar-id of the avatar.

[0103] At step 3, the UE-A 201 performs an XR media rendering negotiation between the UE-A 201 and IMS network with the selected Avatar-id of the avatar and an indication of UE-A centric rendering preference. In this regard, the UE-A 201 may negotiate with the XR application server 207, by using the Avatar-id of the avatar and the indication of UE-A centric rendering preference.

[0104] At step 4, if the negotiation result is successful in step 3, the UE-A 201 initiates new person-to-application (P2A) application data channels, which are used for XR data transmission between the UE-A 201 and the network. During the P2A application data channel establishment procedure, a data channel signaling function (DCSF) 205 will instruct the MF / MRF 206 via an IMS AS 204 how to establish the data channel and corresponding media processing specification. The P2A application data channel may be setup through the procedure described later with reference to FIG. 4.

[0105] At step 5, a media re-negotiation between UE-B 209 and the IMS network is performed for anchoring UE-B’s audio / video media to the MF / MRF 206. In this regard, the IMS AS 204 may initiate a media re-negotiation request with UE-B 209. The Avatar-id of the avatar is exchanged with UE-B 209 to indicate about the avatar session during the signaling. The UE-B 209 has an option to reject the avatar alone or terminate the session based on Avatar-id.

[0106] At step 6, if the re-negotiation at step 5 is successful, the IMS AS 204 may request the XR application server 207 to start the UE-A centric rendering operation with the Avatar-id of the avatar. Then, at step 7, the XR application server 207 retrieves avatar metadata of the avatar using the Avatar-id from the DAC 203. For example, the XR application server 207 may send a request for the avatar metadata with the Avatar-id and UE-identity of UE-A 201, via the data channel. The DAC 203 responds to the XR application server 207 with the avatar metadata, as shown at step 8.

[0107] At step 9, the XR application server 207 starts controlling the XR media rendering. In this regard, the XR application server 207 may decide to send the received avatar metadata to the UE-A201 based on the indication of UE-A centric rendering preference. As shown at step 10, the XR application server 207 sends the received avatar metadata to the UE-A 201 for UE-A centric rendering.

[0108] At step 11, the UE-A 201 performs XR media rendering and encoding. In this regard, the UE-A 201 may locally mix the avatar metadata received from the XR application server 207 together with audio / video media received from its local sensors (e.g. camera) , to animate the avatar (the rendered avatar audio / video media) .

[0109] Then, at step 12, the UE-A 201 sends the rendered avatar audio / video media as regular video media to the UE-B 209.

[0110] FIG. 3 depicts a call flow procedure to establish a UE centric IMS avatar call with rendering in the UE-B. The main steps in the call flow are as follows.

[0111] At step 1, UE-A 301 initiates an IMS session and establishes audio and / or video session connections with UE-B 309. A bootstrap data channel is established at the same time for both the UE-A 301 and UE-B 309. The UE-A 301 would also download an avatar application and Avatar-id (s) of one or more avatar.

[0112] At step 2, the UE-A 301 decides to request UE-B media rendering of an avatar intended to use for the avatar call, based on its status such as power, signal, computing power, internal storage, etc. The UE-A 301 selects an Avatar-id of the avatar.

[0113] Then, at step 3, the UE-A 301 performs an XR media rendering negotiation with the XR application server 307 and UE-B 309, by using the Avatar-id of the avatar and an indication of UE-B centric rendering preference. The Avatar-id of the avatar is exchanged with UE-B 309 to indicate about the avatar session during the signaling.

[0114] If the negotiation result is successful in step 3, the UE-B 309 accepts the UE-B centric rendering preference option. Then, the UE-B 309 initiates new P2A application data channels, which are used for XR data transmission between the UE-A 301 and UE-B 309. During the P2A application data channel establishment procedure, the DCSF 305 will instruct the MF / MRF 306 via IMS AS 304 how to establish the data channel and corresponding media processing specification. The P2A application data channel may be setup through the procedure described later with reference to FIG. 4.

[0115] At step 5, a media re-negotiation between UE-B 309 and the IMS network is performed for anchoring UE-B’s audio / video media to the MF / MRF 306. In this regard, the IMS AS 304 may initiate a media re-negotiation request with UE-B 309, to connect UE-B's audio / video media stream to the MF / MRF 306. The UE-B 309 has an option to reject the avatar alone or terminate the session based on Avatar-id.

[0116] At step 6, if the re-negotiation at step 5 is successful, the IMS AS 304 may request the XR application server 307 to start the UE-B centric rendering operation with the Avatar-id of the avatar. Then, at step 7, the XR application server 307 retrieves avatar metadata of the avatar using the Avatar-id from the DAC 303. For example, the XR application server 307 may send a request for the avatar metadata with the Avatar-id and UE-identity of UE-A 301, via the data channel. The DAC 303 responds to the XR application server 307 with the avatar metadata, as shown at step 8.

[0117] At step 9, the XR application server 307 starts controlling the XR media rendering. In this regard, the XR application server 307 may decide to send the received avatar metadata to the UE-B 309 based on the indication of UE-B centric rendering preference. As shown at step 10, the XR application server 307 sends the received avatar metadata to the UE-B 309 for UE-B centric rendering.

[0118] At steps 11 to 13, after receiving a successful response from UE-B 309, the XR application server 307 forwards a response to UE-A 301 via the IMS AS 304, indicating about the readiness of UE-B centric rendering.

[0119] Then, at step 14, the UE-A 301 sends XR information about UE-A 301, such as audio and / or video media for rendering, to the UE-B 309.

[0120] At step 15, the UE-B 309 performs XR media rendering and encoding. In this regard, it may locally mix the avatar metadata received from the XR application server 307 together with the received information of UE-A 301 to animate the avatar (the rendered avatar audio / video media) .

[0121] Now, reference is made to FIG. 4 which illustrates an exemplary signaling flow diagram for establishing an application data channel in a person to application (P2A) use case. The steps in the call flow are as follows.

[0122] At step 0, IMS session and bootstrap data channel have been established. Selected data channel application (s) have been downloaded to UE#1 401 and possibly UE#2 402.

[0123] At step 1, UE#1 401 sends the SIP reINVITE request with an updated session description protocol (SDP) to IMS AS 404, through P-CSCF 402 and S-CSCF 402’ of the originating network. The updated SDP contains the bootstrap data channel information, as well as the requested application data channel and the associated data channel application binding information. The SIP re-INVITE can be initiated either from UE#1 401 or UE#2 409.

[0124] At step 2, the IMS AS 404 validates user subscription data to determine whether the media change request event should be notified to the DCSF 405.

[0125] At step 3, the IMS AS 404 notifies the DCSF 405, via Nimsas_SessionEventControl_Notify (MediaChangeRequest Event, Session ID, Event Direction, Event initiator, Media Info List) of the media change request event.

[0126] At step 4, after receiving the session event notification, the DCSF 405 determines the policy about how to process the application data channel establishment request based on the related parameters (i.e. associated data channel application binding information) in the notification and / or DCSF service specific policy.

[0127] At step 5, the DCSF 405 determines that the added application data channel media of the offer takes data channel (DC) application server 411 as target endpoint and requires to anchor in the MF or MRF 406.

[0128] At step 6, the DCSF 405 invokes Nimsas_MediaControl service operation to instruct the IMS AS 404 to terminate the media flow of the originating UE to MF. The instruction also includes information to be consumed by the MF / MRF 406 that the data channel media shall be relayed via the MDC2 interface.

[0129] At step 7, the IMS AS 404 invokes Nmf_MRM_Create (List of Media Termination Descriptors) service operation to instruct MF / MRF 406 on application data channel establishment and data channel media resource reservation based on the DC media information received from DCSF 405.  If MRF 406 is used, IMS AS 404 uses DC2 or Mr' / Cr to MF / MRF 406 to reserve data channel media resources.

[0130] At step 8, the IMS AS 404 notifies the MediaControl instruction control response to DCSF 405.

[0131] At step 9, the DCSF 405 stores the media resource information and sends a P2A application data channel establishment request (including the MDC2 media resource received from MF / MRF) to the DC Application Server 411 via DC3 / DC4.

[0132] At step 10, the DC application server 411 accepts the P2A application data channel establishment request, returning an MDC2 reserved media resource as answer and is prepared for UE#1 traffic through MDC2.

[0133] At step 11, DCSF 405 requests IMS AS 404 to update the MF / MRF resource with MDC2 media endpoint information of DC Application Server 411.

[0134] At step 12, the IMS AS 404 updates the MF / MRF resource. At step 13, the IMS AS 404 notifies the MediaControl instruction control response to DCSF 405. Then, at step 14, DCSF 405 replies to the notification received in step 13.

[0135] At step 15-16, IMS AS 404 sends the re-INVITE to remote network side and UE#2 411, via the originating S-CSCF 402’, which does not include application data channel request in the SDP for the application data channel.

[0136] At steps 17-19, UE#2 409 and terminating network 411 returns a 200 OK response with SDP answer for audio / video.

[0137] At step 20, the IMS AS 404 notifies the DCSF 405 about the successful result of the MediaChangeRequest event. The DCSF 405 replies to the notification at step 21.

[0138] Then, at steps 22 to 23, the IMS AS 404 includes SDP answer for application data channels to UE#1 401 in 200 OK response and sends 200 OK response to S-CSCF 402’ and P-CSCF 402.

[0139] At step 24, the originating network P-CSCF 402 executes QoS procedure for application data channel media based on the SDP answer information from the 200 OK response.

[0140] Then, CSCF 402 returns the 200 OK response to UE#1 401 at step 25. UE#1 401 send ACK to the terminating network 409.

[0141] Then at step 27, the application data channel between UE#1 401 and DC Application Server 411 is established via MF or MRF 406. MF or MRF 406 forwards data channel traffic between UE#1  401 and DC Application Server 411 based on MDC2 media point information received in step 9 and 12.

[0142] Besides the solutions for establish an avatar call described above, there are some other solutions for supporting avatar communication, including solutions for downloading avatar object / representation in bootstrap data channel from avatar repository, transition between avatar and audio / video communication, supporting network-based avatar communication by media capability invocation, support for avatars in augmented reality (AR) calls, early capability negotiation for avatar communication, etc. Those solutions are more or less based on an IMS data channel, and supposed there's a repository / container inside or outside 3GPP network to store avatar objects / representations. Some solutions assumed that an avatar object / representation is provided by UE, other solutions assumed an avatar object / representation is provided by a 3rd party, and may be associated to 3rd party applications. Providing avatar by an operator is also not excluded.

[0143] The security of avatar communication should also be considered. Avatar objects / representations could be used by malicious users to impersonate other users. For example, A malicious UE can use Avatar-IDs belonging to other UEs or forged Avatar-IDs to initiate IMS avatar communication in the IMS network and therefore impersonate other UEs. Avatar objects could be used for impersonating an IMS caller. The potential transfer of the Avatar-ids or avatar object (e.g., comprising avatar metadata) between IMS networks can potentially be manipulated by intermediary network entities.

[0144] Therefore, it is essential to ensure that the avatar objects are secure and cannot be tampered with or accessed by unauthorized entities. In this regard, the 5G mobile communication system (including IMS network) shall support an integrity protection of avatar objects / representations on an originating network and a terminating network for avatar communication.

[0145] Data gram transport layer security (DTLS) bases end-to-end (E2E) authentication and communication link protection, and DTLS bases end-to-DC-edge (e2DCe) authentication and communication link protection have been specified in specifications (e.g., 3GPP TS 33.328 v 18.1.0) for security on IMS data channels. However, these security mechanisms cannot provide sufficient integrity protection of avatar objects in avatar communication. Some solutions have been proposed to authenticate and authorize a usage of Avatar-id and avatar metadata or object, by a user or an application, protect the integrity of the avatar metadata at rest and transmission. However, how to make sure the authenticity of the avatar pushed from an XR application server to a UE (UE-A or UE-B) is missing for UE centric rendering scenario.

[0146] For example, below technical problems need to be addressed: how to validate the authenticity or legitimacy of avatar object / representation / metadata that is pushed towards a UE via data channel before rendering, if the avatar metadata received is genuine, and how will a UE verify this metadata. For example, avatar metadata received in a data channel may have been changed to another avatar metadata or changed by any module in between. In this regard, an XR application server may be considered as malicious.

[0147] FIG. 5 illustrates an exemplary scenario depicting a potential security problem in avatar communication. The scenario shown in FIG. 5 is a establish procedure of a UE-B centric IMS avatar call based on IMS. Steps 1 to 9 may be similar as the steps 1 to 9 shown in FIG. 3, and thus would not be described repeatedly.

[0148] In case that the XR application server 507 is considered as untrusted entity, there may be a security issue at step 10. At step 10, the XR application server 507 is to send avatar metadata received at step 8 with the Avatar-id to UE-B 509 via an application data channel. However, the untrusted XR application server 507 may change the received avatar metadata to another avatar metadata, and send tampered avatar metadata to UE-B 509 at step 10. Another issue is related to the avatar object, how the UE-B 509 or other node in the terminating network ensures that avatar received via the application data channel is trusted or not modified in between.

[0149] The present disclosure focuses on avatar communication with UE centric rending, including UE-A centric rending and UE-B centric rending. In these avatar communications, an avatar object (e.g., comprising avatar metadata) of an avatar would be downloaded from an XR application server to a UE-A or UE-B to be rendered with XR information (such as audio and / or video media) from the UE-A. In the present disclosure, it is proposed to provide security information of an avatar to a UE (such as UE-A or UE-B) via signaling. When avatar metadata or object is received or pushed from an XR application server to the UE through an application data channel, the UE could verify authenticity of the avatar metadata or object based on the received security information of the avatar. The security information may comprise hash or signature of the avatar. For example, the hash may be transferred in an Avatar-id of the avatar via the signaling.

[0150] In some embodiments, a hash of an avatar object (e.g., comprising avatar metadata) is generated and included in the Avatar-id when the avatar is created in DAC. The Avatar-id may further comprise at least one of an initially fixed value of a unique identifier for the avatar; a message authentication code (MAC) ; or an indication of an algorithm used to generate the hash. A value of the MAC may be generated based on a secret key, the initially fixed value of the unique identifier, and the hash. The Avatar-id is sent to a UE (such as UE-A or UE-B) during a SIP procedure by an IMS AS. The UE generates a hash after receiving a corresponding avatar object (e.g., comprising avatar metadata) from  XR application server via an application data channel, and compares the generated hash (or Avatar-id containing the hash) with the Avatar-id received from the IMS AS in the SIP procedure. If the generated hash (or Avatar-id containing the hash) can match to the received Avatar-id which contains the hash from the IMS AS, then the UE can determine that an avatar object is same as the avatar intended to be rendered based on the Avatar-id.

[0151] In these embodiments, overhead for avatar communication may be reduced, since an Avatar-id can be utilized for multiple functions, i.e., not only for identifying an avatar, but also for including a Hash value. However, an Avatar-id becomes specific to avatar verification, and needs to be pushed to a UE for avatar verification.

[0152] In some other embodiments, a hash of an avatar metadata is not comprised in an Avatar-id, but is a separate information element. The hash of an avatar object (e.g., comprising avatar metadata) may be generated when the avatar is created in DAC, or when an IMS AS retrieves the hash from the DAC. The value of the hash is sent to a UE (such as UE-A or UE-B) during a SIP procedure by the IMS AS. The hash specific to avatar verification may be sent independent from Avatar-id. Then, the UE may generate a hash after receiving corresponding avatar object (e.g. comprising avatar metadata) of the avatar from an XR application server via an application data channel, and compare the hash with the hash value received in SIP procedure.

[0153] In some other embodiments, an avatar object (e.g., comprising avatar metadata) is signed when uploaded to DAC. The signed avatar object (e.g., comprising avatar metadata) is transmitted between DAC and XR AS, then between XR AS and a UE (such as UE-A or UE-B) . The UE may receive a certificate to sign the avatar object (e.g., comprising avatar metadata) , or optionally an address of a verification server, during SIP procedure. When a signed avatar object (e.g., comprising avatar metadata) is received from an XR application server, the UE may verify the signature with the certificate or by virtue of the verification server. For example, the UE may request the verification server to verify the signature. In these embodiments, a signature can be sent together with an avatar object (e.g., comprising avatar metadata) . It is easy to execute a verification of the avatar object with no or less addition information is required. The certificate may be not specific to verification of one particular avatar, but it can be used for verifying multiple avatars. For example, the certificate may be specific to a UE, so it may be used to verify multiple avatars associated with the UE.

[0154] It should be noted that embodiments of the present disclosure are applicable to both UE-Acentric rendering and UE-B centric rendering to validate the authenticity of avatar, which is pushed for example by an XR application server via an application data channel.

[0155] Hereinafter, solutions of the present disclosure will be described in detail with reference to FIGs. 6-13.

[0156] FIG. 6 is a flow chart depicting a process for establishment of UE-B centric IMS avatar call using data channel according to an embodiment of the present disclosure. As shown in FIG. 6, the process involves a UE-A 601, a UE-B 609, related network nodes in originating side, such as P / I / S-CSCF / IMS AGW 602, DAC 603, IMS AS 604, DCSF 605, MF / MRF 606, XR application server 607, IBCF / TrGW 610, and related network nodes in terminating side (collectively referred to as terminating IMS core 608) . This process may be implemented based an IMS architecture, e.g., as specified in 3GPP TR 23.700-77 (v 0.5.0) .

[0157] At step 0, the DAC 603 generates a hash value of an avatar, e.g., by hashing avatar metadata of the avatar. The Avatar-id may be generated accordingly by taking any suitable format to comprise the hash, for example in the following formats.

[0158] · Format 1: <Number> < Hash value of avatar file / object>.

[0159] The “Number” field is an initially fixed value of a unique identifier of the avatar. “Hash value of avatar file / object” is a hash of the avatar object (e.g., comprising avatar metadata) of the avatar. In Format 1, the initially fixed value of the unique identifier may be concatenated with a hash value of the avatar object, so as to consist of an Avatar-id of the avatar.

[0160] · Format 2: < Hash value of avatar file / object>.

[0161] In Format 2, an Avatar-id of the avatar contains only the hash value of the avatar object (e.g., comprising avatar metadata) .

[0162] · Format 3: <Number>< Hash value of avatar file / object><MAC>.

[0163] The “MAC” field is a message authentication code (MAC) , which is also referred to as a tag. It is used to authenticate an origin and nature of a message. MACs use authentication cryptography to verify the legitimacy of data sent through a network or transferred from one person to another. In Format 3, an initially fixed value of a unique identifier of the avatar is concatenated with a hash value of the avatar object (e.g., comprising avatar metadata) and a value of the MAC.

[0164] In an example, MAC can be derived from a secret key, the initially fixed value of the unique identifier of the avatar, the hash value of the avatar object, e.g., using a key derivation function (KDF) . In this regard, MAC = KDF (Avatar Key, hash value of avatar file / object, number) . The secret key (also known as Avatar Key) may be pre-provisioned to the DAC 603 and the UE-B 609. In an example, The IMS AS 604 provides the secret key to the DAC 603 at step 0.

[0165] · Format 4: <Number><Hash of avatar file ><algo indication>.

[0166] The “algo indication” field is an indication of algorithm used to generate the hash. In Format 4, an initially fixed value of a unique identifier of the avatar is concatenated with a hash value of the avatar object (e.g., comprising avatar metadata) and an indication of the algorithm.

[0167] It should be appreciated that the above four formats of the Avatar-id are listed as examples, and Avatar-id generated in step 0 is not limited to these particular formats, but may be in any other suitable formats.

[0168] At step 1, the UE-A 601 initiates an IMS session and establishes audio and video session connections with the UE-B 609. A bootstrap data channel (BDC) is established at the same time for both the UE-A 601 and UE-B 609. The UE-A 601 also downloads an avatar application and Avatar-id (s) . The DAC 603 needs to be contacted for each Avatar-id during the downloading of the Avatar-id (s) . In the solutions of the present disclosure, the Avatar-id (s) are generated by the DAC 603 as mentioned in step 0.

[0169] In particular, the UE-A 601 sends a request to the MF 606 in the IMS core for downloading the Avatar-id (s) via the BDC, and the MF / MRF 606 will forward the request to the DCSF 605, and the DCSF 605 can contact the DAC 603 directly or indirectly via the XR AS 604 to retrieve the Avatar-id (s) . The retrieved Avatar-id (s) then can be sent back to the UE-A 601 via the DCSF 605 and MF 606 via the BDC.

[0170] At step 2, the UE-A 601 decides to request UE-B media rendering based on its status such as power, signal, computing power, internal storage, etc. The UE-A 601 may select an Avatar-id of an avatar, which is intended to use for the call.

[0171] At step 3, the UE-A 601 performs an XR media rendering negotiation with the XR application server 607 and the UE-B 609. The Avatar-id and an indication of UE-B centric rendering preference are exchanged with the UE-B 609 to indicate about the avatar session during the signaling, and the UE-B 609 accepts the UE-B preferred rendering option. According to embodiments of the present disclosure, a hash of the selected avatar (such as a hash of avatar metadata) is comprised in the Avatar-id, and this Avatar-id is sent to UE-B 609 in a SIP signaling by the IMS AS 604.

[0172] In case that the Avatar-id comprises a MAC (e.g., in format 3) , the IMS AS 604 may send a secret key (also known as Avatar Key) for deriving the MAC value to the UE-B 609. In case that the Avatar-id comprises an indication of an algorithm for generating the hash (e.g., in format 4) , the IMS AS 604 may also send an indication of the algorithm to the UE-B 609.

[0173] At step 4, if the negotiation result is successful in step 3, the UE-B 609 initiates new P2A application data channels, which are used for XR data transmission between the UE-A 601 and UE-B 609. During the P2A application data channel establishment procedure, the DCSF 605 will instruct the MF 606 via the IMS AS 604 how to establish the data channel and corresponding media processing specification.

[0174] At step 5, the IMS AS 604 initiates a media re-negotiation request with the UE-B 609, to connect UE-B's audio / video media stream to the MF 606. The UE-B 609 has an option to reject the avatar alone or terminate the session based on Avatar-id.

[0175] At step 6, if the negotiation result is successful in step 5, the IMS AS 604 requests the XR application server 607 via the DCSF 605 to start UE-B centric rendering procedure with the Avatar-id of the avatar.

[0176] At step 7, The XR application server 607 retrieves the avatar metadata using the Avatar-id from the DAC 603. The DAC 603 responds to the XR application server 607 with the avatar metadata of the avatar associated with the Avatar-id, at step 8.

[0177] Based on the indication of UE-B centric rendering received in step 6, the XR application server 607 decides to send the avatar metadata to the UE-B, at step 9.

[0178] Then, the XR application server 607 may send an avatar metadata with an associated Avatar-id to the UE-B 609 via the application data channel, at step 10. According to embodiments of the present disclosure, the UE-B 609 may store temporarily the avatar metadata and the Avatar-id received from the XR application server 607, at step 10a. The UE-B 609 generates a hash value of the avatar metadata and then generates the corresponding Avatar-id locally, at step 10b.

[0179] In case that the Avatar-id comprises a MAC (e.g., in format 3) , the UE-B 609 may further derive a MAC value based on the secret key received from the IMS AS 604. For example, a same function KDF may be used for the derivation, MAC = KDF (Avatar Key, hash value of avatar file / object, number) . In case that the Avatar-id comprises an indication of an algorithm for generating the hash (e.g., in format 4) , the UE-B 609 may utilize the indication of the algorithm received from the IMS AS 604 for generating the hash value of the avatar metadata.

[0180] Then, at step 10c, authenticity of the avatar metadata received from the XR application server 607 may be verified based on a comparison between the Avatar-id (or hash value) generated locally and the Avatar-id (or hash value) received previously at step 3. If the generated Avatar-id (or hash value) is same as (or matches to) the one received in step 3 from the IMS AS 604, then it can be determined that the avatar metadata received from the XR application server 607 is not tampered and  can be considered for further rendering by the UE-B 609, as shown at step 10d. In this regard, the UE-B 609 may send a response to the XR application server 607 to indicate a successful verification.

[0181] At step 11, after receiving the successful response from the UE-B 609, the XR application server 607 forwards the response to the UE-A 601 via the IMS AS 604 indicating about the readiness of UE-B centric rendering.

[0182] At step 12, the UE-A 601 sends XR information about UE-A, which is sufficient for rendering, to the UE-B 609. Then, the UE-B 609 performs XR media rendering at step 13. It may locally mix the avatar metadata received from the XR application server 607 together with the received XR information of UE-A to animate the avatar (including the rendered avatar audio / video media) .

[0183] FIG. 7 is a flow chart depicting another process for establishment of UE-B centric IMS avatar call using data channel according to an embodiment of the present disclosure. As shown in FIG. 7, the process involves a UE-A 701, a UE-B 709, related network nodes in originating side, such as P / I / S-CSCF / IMS AGW 702, DAC 703, IMS AS 704, DCSF 705, MF / MRF 706, XR application server 707, IBCF / TrGW 710, and related network nodes in terminating side (collectively referred to as terminating IMS core 708) . This process may be implemented based an IMS architecture, e.g., as specified in 3GPP TR 23.700-77 (v 0.5.0) .

[0184] At step 0, the DAC 703 generates a hash for avatar metadata of one or more avatars stored in the DAC 703. Alternatively, the hash may be generated when the IMS AS 704 requests the hash for an avatar as described later in step 3.

[0185] At step 1, the UE-A 701 initiates an IMS session and establishes audio and video session connections with the UE-B 709. The bootstrap data channel (s) are established at the same time for both the UE-A 701 and UE-B 709. The UE-A 701 also downloads avatar applications and Avatar-id (s) . Different from the embodiments shown in FIG. 6, the Avatar-id in this embodiment is a normal avatar identity of an avatar.

[0186] At step 2, the UE-A 701 decides to request UE-B media rendering based on its status such as power, signal, computing power, internal storage, etc. The UE-A 701 selects an Avatar-id of an avatar, which is intended to use for the call.

[0187] At step 3, the UE-A 701 performs an XR media rendering negotiation with the XR application server 704 and the UE-B 709. An Avatar-id of the selected avatar and an indication of UE-B centric rendering preference are exchanged with the UE-B 709 to indicate about the avatar session during the signaling. The UE-B 709 accepts the UE-B preferred rendering option. In this step, the IMS AS 704 may request for a hash of the avatar metadata of the selected avatar from the DAC 703 based on the Avatar-id received from the UE-A 701. Then, a hash value of the avatar received from DAC 703 is  sent from the IMS AS 704 to the UE-B 709. The UE-B 709 may store the hash value received from IMS AS 704.

[0188] At step 4, if the negotiation result is successful in step 3, the UE-B 709 initiates new P2A application data channels, which are used for XR data transmission between the UE-A 701 and UE-B 709. During the P2A application data channel establishment procedure, the DCSF 705 will instruct the MF 706 via the IMS AS 704 how to establish the data channel and corresponding media processing specification.

[0189] At step 5, the IMS AS 704 initiates a media re-negotiation request with the UE-B 709, to connect UE-B's audio / video media stream to MF 706. The UE-B 709 has the option to reject the avatar alone or terminate the session based on the Avatar-id.

[0190] At step 6, if the negotiation result is successful in step 5, the IMS AS 704 requests the XR application server 707 via the DCSF 705 to start UE-B centric rendering procedure with the Avatar-id.

[0191] At step 7, the XR application server 707 retrieves the avatar metadata of the avatar using the Avatar-id of the avatar from DAC 703. The DAC 703 responds to the XR application server 707 with the avatar metadata, at step 8.

[0192] Based on the indication of UE-B centric rendering received in step 6, the XR application server 707 decides to send the avatar metadata to the UE-B 709, at step 9.

[0193] Then, at step 10, the XR application server 707 sends an avatar metadata with an associated Avatar-id to UE-B 709 via the application data channel. According to embodiments of the present disclosure, the UE-B 709 may store the received avatar metadata and Avatar-id before verification, as shown at step 10a. Hashing on the avatar metadata received from the XR application server 707, may be performed at step 10b. Then, the UE-B 709 may verify authenticity of the avatar metadata received from the XR application server 707 based on the hash. At step 10c, the UE-B 709 compares the hash value of the generated hash and that of the hash received from the IMS AS 704 at step 3. If the generated hash matches to the hash received from the IMS AS 704 at step 3, then the verification is successful, and the avatar metadata received form XR application server 707 is considered for further UE-B centric rendering, at step 10d. In this regard, the UE-B 709 may send a response to the XR application server 707 to indicate a successful verification.

[0194] At step 11, after receiving the successful response from the UE-B 709, the XR application server 707 forwards the response to the UE-A 701 via the IMS AS 704 indicating about the readiness of UE-B centric rendering.

[0195] At step 12, the UE-A 701 sends XR information about UE-A, which is sufficient for rendering, to the UE-B 709. Then, the UE-B 709 performs XR media rendering at step 13. It may locally mix the avatar metadata received from the XR application server 707 together with the received XR information of UE-A to animate the avatar (including the rendered avatar audio / video media) .

[0196] FIG. 8 is a flow chart depicting yet another process for establishment of UE-B centric IMS avatar call using data channel according to an embodiment of the present disclosure. As shown in FIG. 8, the process involves a UE-A 801, a UE-B 809, related network nodes in originating side, such as P / I / S-CSCF / IMS AGW 802, DAC 803, IMS AS 804, DCSF 805, MF / MRF 806, XR application server 807, IBCF / TrGW 810, and related network nodes in terminating side (collectively referred to as terminating IMS core 808) . This process may be implemented based an IMS architecture, e.g., as specified in 3GPP TR 23.700-77 (v 0.5.0) .

[0197] At step 0, the DAC 803 causes each avatar metadata to be signed when storing it in the DAC 803. An avatar metadata can be signed by DAC 803 with a corresponding certificate. In this regard, the DAC 803 may receive the certificate from the IMS AS 804 or other network entity. In other examples, the avatar metadata can be signed by a signing server, such as the DCSF 805 or a third party or other trusted entities such as the IMS AS 804 or the MF / MRF 806.

[0198] At step 1, the UE-A 801 initiates an IMS session and establishes audio and video session connections with the UE-B 809. The bootstrap data channel (s) are established at the same time for both the UE-A and UE-B. The UE-A 801 also downloads the avatar applications and Avatar-id (s) .

[0199] At step 2, the UE-A 801 decides to request UE-B media rendering based on its status such as power, signal, computing power, internal storage, etc. The UE-A 801 selects an Avatar-id of an avatar, which is intended to use for the call.

[0200] At step 3, the UE-A 801 performs an XR media rendering negotiation with the XR application server 804 and the UE-B 809. An Avatar-id of the selected avatar and an indication of UE-B centric rendering preference are exchanged with the UE-B 809 to indicate about the avatar session during the signaling. The UE-B 809 accepts the UE-B preferred rendering option. In this step, the IMS AS 804 may send the certificate (s) or an address of a verification server to UE-B 809 for later verification. In some examples, an address of a verification server of a third party can be provisioned to UE-B 809 for later verification.

[0201] In some embodiments, the IMS AS 804 could obtain the certificate from a network entity, e.g., a signing server. In an example, the IMS AS 804 may get the certificate from Operation and Management system (OAM) or Certificate Authority (CA) . The certificate can be preconfigured in  IMS AS 804 manually or configured by OAM automatically after the IMS AS network function being deployed.

[0202] In some embodiments, the IMS AS 804 could obtain the certificate from the DAC 803. In some solutions, the DAC 803 has an interface to the DCSF 805, and therefore the IMS AS 804 can request the DCSF 805 to retrieve the certificate from the DAC 803 via the interface. In some other solutions, the DAC 803 may only have an interface to the XR application server 807, and therefore the IMS AS 804 can request the DCSF 805 to retrieve the certificate, and then the DCSF 805 requests the XR AS 807 to retrieve it from the DAC 803. In some embodiments, address information of the address of the verification server can be added as a part of SIP message content during the media negotiation. The address information may be transparent to the IMS AS 804 and the DCSF 805. After the UE-B 809 receives the SIP message, the UE-B 809 can read the address information.

[0203] At step 4, if the negotiation result is successful in step 3, the UE-B 809 initiates new P2A application data channels, which are used for XR data transmission between the UE-A 801 and UE-B 809. During the P2A application data channel establishment procedure, the DCSF 805 will instruct the MF 806 via the IMS AS 804 how to establish the data channel and corresponding media processing specification.

[0204] At step 5, the IMS AS 804 initiates a media re-negotiation request with the UE-B 809, to connect UE-B's audio / video media stream to MF 806. The UE-B 809 has the option to reject the avatar alone or terminate the session based on the Avatar-id.

[0205] At step 6, if the negotiation result is successful in step 5, the IMS AS 804 requests the XR application server 807 via the DCSF 805 to start UE-B centric rendering procedure with the Avatar-id.

[0206] At step 7, the XR application server 807 retrieves the signed avatar metadata of the avatar using the Avatar-id of the avatar from DAC 803. The DAC 803 responds to the XR application server 807 with the signed avatar metadata, at step 8.

[0207] Based on the indication of UE-B centric rendering received in step 6, the XR application server 807 decides to send the avatar metadata to the UE-B 809, at step 9.

[0208] Then, at step 10, the XR application server 807 sends a signed avatar metadata with an associated Avatar-id to UE-B 809 via the application data channel. According to embodiments of the present disclosure, the signed Avatar metadata from the XR Application server is received in the UE-B 809 at step 10a, and then the UE-B 809 may verify at step 10b the signature of the signed Avatar metadata using the certificate (s) received at step 3. In some embodiments, the UE-B 809 may contact a verification server via the address received at step 3, for verifying the signature.

[0209] If the verification of the signature is successful, the avatar metadata received form XR application server 807 is considered for further UE-B centric rendering. In this regard, the UE-B 809 may send a response to the XR application server 807 to indicate a successful verification.

[0210] At step 11, after receiving the successful response from the UE-B 809, the XR application server 807 forwards the response to the UE-A 801 via the IMS AS 804 indicating about the readiness of UE-B centric rendering.

[0211] At step 12, the UE-A 801 sends XR information about UE-A, which is sufficient for rendering, to the UE-B 809. Then, the UE-B 809 performs XR media rendering. It may locally mix the avatar metadata received from the XR application server 807 together with the received XR information of UE-A to animate the avatar (including the rendered avatar audio / video media) .

[0212] The embodiment procedures of FIGs. 6-8 were focused on UE-B centric rendering, but these solutions of the present disclosure are applicable to UE-A centric rendering to verify avatar sent from an XR application server through an application data channel. FIG. 9 is a flow chart depicting a process for establishment of UE-A centric IMS avatar call using data channel according to an embodiment of the present disclosure. As shown in FIG. 9, the process involves a UE-A 901, a UE-B 909, related network nodes in originating side, such as P / I / S-CSCF / IMS AGW 902, DAC 903, IMS AS 904, DCSF 905, MF / MRF 906, XR application server 907, IBCF / TrGW 910, and related network nodes in terminating side (collectively referred to as terminating IMS core 908) . This process may be implemented based an IMS architecture, e.g., as specified in 3GPP TR 23.700-77 (v 0.5.0) .

[0213] At step 0, the DAC 903 will generate a hash value of an avatar, e.g., by hashing avatar metadata of the avatar. Similar as the embodiment described with reference to FIG. 6, the Avatar-id may be generated accordingly by taking any suitable format to comprise the hash, such as Format 1, Format 2, Format 3, or Format 4.

[0214] At step 1, the UE-A 901 initiates an IMS session and establishes audio and video session connections with the UE-B 909. The bootstrap data channel (s) are established at the same time for both the UE-A 901 and UE-B 909.

[0215] At step 2, the UE-A 901 decides to request UE-A media rendering of an avatar intended to use for the call based on its status such as power, signal, computing power, internal storage, etc. The UE-A selects an Avatar-id of an avatar.

[0216] At step 3, the UE-A 901 performs an XR media rendering negotiation with the XR application server 907. The negotiation includes a usage of the Avatar-id of the selected avatar. A hash of the selected avatar (such as a hash of avatar metadata) is comprised in the Avatar-id, and this Avatar-id is sent to UE-A 901 in a SIP signaling by the IMS AS 904. Similar as step 3 described with reference to  FIG. 6, in case that the Avatar-id comprises a MAC (e.g., in format 3) , the IMS AS 904 may send a secret key (also known as Avatar Key) for deriving the MAC value to the UE-A 901; in case that the Avatar-id comprises an indication of an algorithm for generating the hash (e.g., in format 4) , the IMS AS 904 may also send an indication of the algorithm to the UE-A 901.

[0217] At step 4, if the negotiation result is successful in step 3, the UE-A 901 initiates new P2A application data channel, which are used for XR data transmission between the UE-A 901 and the network. During the P2A application data channel establishment procedure, the DCSF 905 will instruct the MF / MRF 906 via IMS AS 904 how to establish the data channel and corresponding media processing specification.

[0218] At step 5, the IMS AS 904 initiates a media re-negotiation request with the UE-B 909, to connect UE-B's audio / video media stream to the MF / MRF 906. The Avatar-id is exchanged with UE-B 909 to indicate about the avatar session during the signaling. The UE-B 909 has the option to reject the avatar alone or terminate the session based on Avatar-id.

[0219] At step 6, if the re-negotiation at step 5 is successful, the IMS AS 904 may request the XR application server 907 to start the UE-A centric rendering operation with the Avatar-id of the avatar. Then, at step 7, the XR application server 907 requests the DAC 903 to retrieve avatar metadata associated with the avatar, by providing UE-identity of UE-A and the Avatar-id via the data channel. The DAC 903 responds to the XR application server 907 with the avatar metadata, as shown at step 8. Then, the XR application server 907 sends the avatar metadata to the UE-A 901 to start the UE-A centric rendering, at step 9. In some embodiments, if the UE-A 901 has the association avatar metadata available in its cache, steps 6-9 may be skipped.

[0220] According to embodiments of the present disclosure, the UE-A 901 may verify an authentication of the avatar metadata of the avatar received at step 9. The UE-A 901 stores temporarily the Avatar metadata and the Avatar-id received from the XR application server 907, at step 10a. The UE-A 901 generates a hash value of the avatar metadata and then generate corresponding Avatar-id locally, at step 10b.

[0221] In case that the Avatar-id comprises a MAC (e.g., in format 3) , the UE-A 901 may further derive a MAC value based on the secret key received from the IMS AS 904. For example, a same function KDF may be used for the derivation, MAC = KDF (Avatar Key, hash value of avatar file / object, number) . In case that the Avatar-id comprises an indication of an algorithm for generating the hash (e.g., in format 4) , the UE-A 901 may utilize the indication of the algorithm received from the IMS AS 904 for generating the hash value of the avatar metadata.

[0222] Then, at step 10c, authenticity of the avatar metadata received from the XR application server 907 may be verified based on a comparison between the Avatar-id (or hash value) generated locally and the Avatar-id (or hash value) received previously at step 3. If the generated Avatar-id (or hash value) is same as (or matches to) the one received in step 3 from the IMS AS 904, then it can be determined that the avatar metadata received form the XR application server 907 is not tampered and can be considered for further rendering by the UE-A 901, as shown at step 10d.

[0223] At step 11, the UE-A 901 performs XR media rendering and encoding. In this regard, the UE-A 901 may locally mix the avatar metadata received from the XR application server 907 together with audio / video media received from its local sensors (e.g. camera) , to animate the avatar (the rendered avatar audio / video media) .

[0224] Then, at step 12, the UE-A 901 sends the rendered avatar audio / video media as regular video media to the UE-B 909.

[0225] With the process of FIG. 6-9, the UE-A or UE-B can only perform an avatar rendering for the avatar whose avatar metadata is successfully verified. It should be understood that, the processes of FIGs. 6-9 are only described as exemplary application scenarios, schemes proposed in the present disclosure may be applied in any suitable scenarios. For example, the verification of avatar metadata based on a hash or a certificate as shown in FIGs. 7 and 8 can be applicable for scenarios with UE-A centric avatar rending.

[0226] FIG. 10 is a flow chart 1000 depicting a method performed at a user equipment (UE) according to an embodiment of the present disclosure. The UE may be a UE-A in UE-A centric avatar rending, such as UE-A 901, or a UE-B in UE-B centric avatar rending, such as UE-B 609, 709, or 809.

[0227] At block 1010, the UE receives from a network entity, e.g., an IMS AS, security information for avatar object of an avatar. The security information may be received from the IMS application server via a session initialization protocol (SIP) signaling during an XR media rending negotiation for rendering the avatar. The avatar object may comprise avatar metadata of the avatar.

[0228] At block 1020, the UE receives from a second network entity (e.g., an XR application server) , avatar object of the avatar for UE centric rendering. The avatar object may be received from the XR application server via an application data channel. The received avatar object may comprise avatar metadata of the avatar. The received object may be stored temporarily in the UE.

[0229] At block 1030, the UE verifies authenticity of the avatar object received from the second network entity based on the security information. Although not shown, the flow chart may further comprise rendering the avatar based on the avatar object received from the second network entity by  the UE, if the verifying of the authenticity of the avatar object received from the second network entity is successful.

[0230] In some embodiments, the security information comprises a first hash of the avatar object. In order to verify authenticity of the avatar object received from the second network entity, the UE may generate a second hash of the avatar object received from the second network entity; and determine whether the second hash matches the first hash or not.

[0231] In some embodiments, the first hash is comprised in an avatar identifier of the avatar. Then, the UE may receive the avatar identifier of the avatar which comprises the first hash from the first network entity (e.g., IMS application server) . The avatar identifier may be taken as the security information. In order to verify authenticity of the avatar object received from the second network entity, the UE may generate a local avatar identifier based on the second hash o; and determine whether the generated local avatar identifier matches the avatar identifier received from the IMS application server.

[0232] In some embodiments, an avatar identifier of an avatar only comprises the hash of avatar object. In other embodiments, besides a hash of avatar object, an avatar identifier of an avatar may further comprise at least one of: an initially fixed value of a unique identifier for the avatar; a message authentication code (MAC) , and the first hash; or an indication of an algorithm used to generate the first hash. A value of the MAC may be generated based on a secret key, the initially fixed value of the unique identifier and the first hash.

[0233] In case that the avatar identifier of the avatar comprises the MAC, e.g., an Avatar-id in Format 3, the UE may receive the secret key from the IMS application server. In order to verify authenticity of the avatar object received from the second network entity, the UE may generate a MAC for the local avatar identifier, based on the received secret key, the initially fixed value of the unique identifier, and the second hash, so as to generate the local avatar identifier.

[0234] In case that the avatar identifier of the avatar comprises the indication of the algorithm, the second hash may be generated using an algorithm indicated by the indication.

[0235] In some embodiments, the security information comprises at least one of a certificate for signing the first avatar metadata; or an address of a verification server for verifying the signed avatar object. The avatar object received from the second network entity are signed avatar metadata. In order to verify authenticity of the signed avatar object received from the second network entity, the UE may verify the signed avatar metadata using the received certificate; or verify the signed avatar object by communicating with the verification server via the address of the verification server.

[0236] FIG. 11 is a flow chart 1100 depicting a method performed at the first network entity (such as an IMS application server) according to an embodiment of the present disclosure. The IMS application server may be implemented as IMS AS 604, 704, 804, or 904.

[0237] At block 1110, the first network entity (e.g., IMS application server) transmits to a UE, security information for avatar object of an avatar for UE centric rendering of the avatar. The avatar object may comprise avatar metadata of the avatar. The security information may be transmitted to the UE via a SIP signaling during the XR media rending negotiation for rendering the avatar.

[0238] In some embodiments, the security information may be received from a second network entity (e.g., DAC) , as shown at block 1120. In this regard, an IMS application server may retrieve the security information from an DAC during an XR media rending negotiation for rendering the avatar.

[0239] In some embodiments, the security information comprises a hash of the avatar object. In some embodiments, the hash of the avatar object is comprised in an avatar identifier of the avatar. The IMS application server may receive an avatar identifier of the avatar which comprises the hash from the second network entity (e.g., DAC) , and transmit the received avatar identifier to the UE. The avatar identifier may be taken as the security information.

[0240] In some embodiments, an avatar identifier of an avatar only comprises the hash of avatar object. In other embodiments, besides a hash of avatar object, an avatar identifier of an avatar may further comprise at least one of: an initially fixed value of a unique identifier for the avatar; a message authentication code (MAC) , and the hash of the avatar object; or an indication of an algorithm used to generate the hash of the avatar object. A value of the MAC may be generated based on a secret key, the initially fixed value of the unique identifier and the hash of the avatar object.

[0241] In case that the avatar identifier of the avatar comprises the MAC, e.g., an Avatar-id in Format 3, the first network entity (e.g., IMS application server) may transmit the secret key to the DAC for a generation of the avatar identifier of the avatar with the hash of the avatar object. For example, the secret key may be sent to the third network entity (e.g., DAC) when it retrieves the security information from the third network entity (e.g., DAC) . Meanwhile, the first network entity may transmit the secret key to the UE, e.g., together with the avatar identifier of the avatar via the SIP signaling during the XR media rending negotiation for rendering the avatar.

[0242] In some embodiments, the security information comprises at least one of a certificate for signing the avatar metadata; or an address of a verification server for signing the avatar metadata. In an example, the first network entity may obtain the certificate and / or the address of the verification server from the third network entity (e.g., DAC) . In other example, the first network entity may obtain the certificate and / or the address of the verification server from an operator of the system in advance  to the XR media rending negotiation. In this regard, the first network entity may transmit the certificate to the third network entity (e.g., DAC) .

[0243] FIG. 12 is a flow chart 1200 depicting a method performed at a third network entity (e.g., DAC) according to an embodiment of the present disclosure. The DAC may be implemented as DAC 603, 703, 803, or 903.

[0244] At block 1210, the DAC obtains security information for avatar object of an avatar for UE centric rendering of the avatar. The avatar object may comprise avatar metadata of the avatar. The security information may be generated by the DAC or received from other trusted entities.

[0245] In some embodiments, the third network entity may transmit the security information to a first network entity (e.g., an IMS application server) , for UE centric rendering of the avatar as shown at block 1220. The security information may comprise a hash of the avatar object. For example, the third network entity may generate the hash of the avatar object.

[0246] In some embodiments, the hash of the avatar object is comprised in an avatar identifier of the avatar. The third network entity may generate the avatar identifier of the avatar comprising the hash. The avatar identifier may be taken as the security information. The generated avatar identifier of the avatar may be also transmitted to a UE which request UE centric rendering of the avatar.

[0247] In some embodiments, an avatar identifier of an avatar only comprises the hash of avatar metadata. In other embodiments, besides a hash of avatar metadata, an avatar identifier of an avatar may further comprise at least one of: an initially fixed value of a unique identifier for the avatar; a MAC, and the hash of the avatar object; or an indication of an algorithm used to generate the hash of the avatar object. A value of the MAC may be generated based on a secret key, the initially fixed value of the unique identifier and the hash of the avatar object.

[0248] In case that the avatar identifier of the avatar comprises the MAC, e.g., an Avatar-id in Format 3, the third network entity may receive the secret key from the first network entity (e.g., IMS application server) ; and generate the MAC based on a secret key, the initially fixed value of the unique identifier, and the hash of the avatar object.

[0249] In some embodiments, the security information comprises at least one of a certificate for signing the avatar object; or an address of a verification server for verifying the signed avatar object. The third network entity (e.g., DAC) may sign the avatar object with the certificate, or obtain a signed avatar object from a signing server. Then the third network entity may transmit the signed avatar object to a second network (e.g., an XR application server) , for example when the XR retrieve avatar object from the third network entity (e.g., DAC) based on an avatar identifier of the avatar. In an example, the certificate may be received from the first network entity (e.g., IMS application server) .

[0250] Now reference is made to FIG. 13 illustrating a simplified block diagram of an apparatus 1300 that may be embodied in / as the base station, or the terminal device. The apparatus 1300 may comprise at least one processor 1301, such as a data processor (DP) and at least one memory 1302 coupled to the at least one processor 1301. The apparatus 1300 may further comprise one or more transmitters TX, one or more receivers RX 1303, or one or more transceivers coupled to the one or more processors 1301 to communicate wirelessly and / or through wireline.

[0251] Although not shown, the apparatus 1300 may have at least one communication interface, for example, the communicate interface can be at least one antenna, or transceiver as shown in the FIG. 13. The communication interface may represent any interface that is necessary for communication with other network entities.

[0252] The processors 1301 may be of any type suitable to the local technical environment, and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples.

[0253] The memory 1302 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, as non-limiting examples.

[0254] The memory 1302 stores a program 1304. The program 1304 may include instructions that, when executed on the associated processor 1301, enable the apparatus 1300 to operate in accordance with the embodiments of the present disclosure. A combination of the at least one processor 1301 and the at least one memory 1302 may form processing circuitry or means 1305 adapted to implement various embodiments of the present disclosure.

[0255] Various embodiments of the present disclosure may be implemented by computer program executable by one or more of the processors 1301, software, firmware, hardware or in a combination thereof.

[0256] In general, the various exemplary embodiments may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. For example, some aspects 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 invention is not limited thereto. While various aspects of the exemplary embodiments of this 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.

[0257] As such, it should be appreciated that at least some aspects of the exemplary embodiments of the disclosures may be practiced in various components such as integrated circuit chips and modules. It should thus be appreciated that the exemplary embodiments of this disclosure may be realized in an apparatus that is embodied as an integrated circuit, where the integrated circuit may comprise circuitry (as well as possibly firmware) for embodying at least one or more of a data processor, a digital signal processor, baseband circuitry and radio frequency circuitry that are configurable so as to operate in accordance with the exemplary embodiments of this disclosure.

[0258] It should be appreciated that at least some aspects of the exemplary embodiments of the disclosures may be embodied in computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor in a computer or other device. The computer executable instructions may be stored on a computer readable medium, for example, non-transitory computer readable medium, such as a hard disk, optical disk, removable storage media, solid state memory, RAM, etc. As will be appreciated by one of skills in the art, the function of the program modules may be combined or distributed as desired in various embodiments. In addition, the function may be embodied in whole or in part in firmware or hardware equivalents such as integrated circuits, field programmable gate arrays (FPGA) , and the like.

[0259] Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination.

[0260] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise.  It will be further understood that the terms “comprises” , “comprising” , “has” , “having” , “includes” and / or “including” , when used herein, specify the presence of stated features, elements, and / or components etc., but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof. As used herein, the term “and / or” includes any and all combinations of one or more of the listed terms.

[0261] As used herein, the phrase “at least one of A and B” or “at least one of A or B” should be understood to mean “only A, only B, or both A and B. ” The phrase “A and / or B” should be understood to mean “only A, only B, or both A and B” .

[0262] The present disclosure includes any novel feature or combination of features disclosed herein either explicitly or any generalization thereof. Various modifications and adaptations to the foregoing exemplary embodiments of this disclosure may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings. However, any and all modifications will still fall within the scope of the non-limiting and exemplary embodiments of this disclosure.

Claims

1.An apparatus at a user equipment (UE) , the apparatus comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to:receive from a first network entity, security information for avatar object of an avatar;receive from a second network entity, avatar object of the avatar for UE centric rendering; andverify authenticity of the avatar object received from the second network entity based on the security information.2.The apparatus according to claim 1, wherein when the instructions are executed by the at least one processor, the instructions further cause the apparatus at least to:if the verifying of the authenticity of the avatar object received from the second network entity is successful, render the avatar based on the avatar object received from the second network entity.3.The apparatus according to claim 1 or 2, wherein the security information comprises a first hash of avatar object of the avatar.4.The apparatus according to claim 3, wherein when the instructions are executed by the at least one processor, the instructions further cause the apparatus at least to:generate a second hash of the avatar object received from the second network entity; anddetermine whether the second hash matches the first hash or not.5.The apparatus according to claim 4, wherein the first hash is comprised in an avatar identifier of the avatar, andwherein receiving the security information from the first network entity comprises receiving the avatar identifier of the avatar comprising the first hash.6.The apparatus according to claim 5, wherein when the instructions are executed by the at least one processor, the instructions further cause the apparatus at least to:generate a local avatar identifier based on the second hash; anddetermine whether the generated local avatar identifier matches the avatar identifier received from the first network entity.7.The apparatus according to claim 6, wherein the avatar identifier received from the first network  entity further comprises at least one of:an initially fixed value of a unique identifier for the avatar;a message authentication code (MAC) , where a value of the MAC is generated based on a secret key, the initially fixed value of the unique identifier, and the first hash; oran indication of an algorithm used to generate the first hash.8.The apparatus according to claim 6, wherein the avatar identifier received from the first network entity is consisted of one of the following groups of information elements:a first group comprising an initially fixed value of a unique identifier for the avatar concatenated with the first hash;a second group comprising merely the first hash;a third group comprising an initially fixed value of a unique identifier for the avatar concatenated with the first hash and a message authentication code (MAC) , where a value of the MAC is generated based on a secret key, the initially fixed value of the unique identifier, and the first hash; ora fourth group comprising an initially fixed value of a unique identifier for the avatar concatenated with the first hash and an indication of an algorithm used to generate the first hash.9.The apparatus according to claim 7 or 8, wherein in case that the avatar identifier of the avatar comprises the MAC, when the instructions are executed by the at least one processor, the instructions further cause the apparatus at least to:receive the secret key from the first network entity; andgenerate a MAC for the local avatar identifier, based on the received secret key, the initially fixed value of the unique identifier, and the second hash.10.The apparatus according to claim 7 or 8, wherein in case that the avatar identifier of the avatar comprises the indication of the algorithm, the second hash is generated using an algorithm indicated by the indication.11.The apparatus according to claim 1 or 2, wherein the avatar object received from the second network entity are signed avatar object, and the security information comprises at least one of:a certificate for signing the avatar object of the avatar; oran address of a verification server for verifying the signed avatar object.12.The apparatus according to claim 11, wherein when the instructions are executed by the at least one processor, the instructions further cause the apparatus at least to:verify the signed avatar object using the certificate; orverify the signed avatar object by communicating with the verification server via the address of the verification server.13.The apparatus according to any of claims 1 to 12, wherein the security information is received from the first network entity via a session initialization protocol (SIP) signaling during an extended reality (XR) media rending negotiation for rendering the avatar.14.The apparatus according to any of claims 1 to 13, wherein the avatar object is received from the second network entity via an application data channel.15.The apparatus according to any of claims 1 to 14, wherein the first network entity is an internet protocol multimedia subsystem (IMS) application server.16.The apparatus according to any of claims 1 to 15, wherein the second network entity is an extended reality (XR) application server.17.The apparatus according to any of claims 1 to 16, wherein the avatar object of the avatar comprises avatar metadata of the avatar.18.An apparatus at a first network entity, the apparatus comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to:transmit to a user equipment (UE) , security information for avatar object of an avatar for UE centric rendering of the avatar.19.The apparatus according to claim 18, wherein when the instructions are executed by the at least one processor, the instructions further cause the apparatus at least to:receive the security information from a third network entity.20.The apparatus according to claim 19, wherein the security information comprises a hash of the avatar object of the avatar.21.The apparatus according to claim 20, wherein the hash of the avatar object is comprised in an  avatar identifier of the avatar, andwherein when the instructions are executed by the at least one processor, the instructions further cause the apparatus at least to receive an avatar identifier of the avatar comprising the hash from the third network entity, and transmit the received avatar identifier to the UE.22.The apparatus according to claim 21, wherein the avatar identifier of the avatar further comprises at least one of:an initially fixed value of a unique identifier for the avatar;a message authentication code (MAC) , where a value of the MAC is generated based on a secret key, the initially fixed value of the unique identifier, and the hash of the avatar object; oran indication of an algorithm used to generate the hash of the avatar object.23.The apparatus according to claim 21, wherein the avatar identifier of the avatar is consisted of one of the following groups of information elements:a first group comprising an initially fixed value of a unique identifier for the avatar concatenated with the hash;a second group comprising merely the hash;a third group comprising an initially fixed value of a unique identifier for the avatar concatenated with the hash and a message authentication code (MAC) , where a value of the MAC is generated based on a secret key, the initially fixed value of the unique identifier, and the hash; ora fourth group comprising an initially fixed value of a unique identifier for the avatar concatenated with the hash and an indication of an algorithm used to generate the hash.24.The apparatus according to claim 22 or 23, wherein in case that the avatar identifier of the avatar comprises the MAC, when the instructions are executed by the at least one processor, the instructions further cause the apparatus at least to:transmit the secret key to the third network entity for a generation of the avatar identifier of the avatar with the hash of the avatar object; andtransmit the secret key to the UE.25.The apparatus according to claim 18, wherein the security information comprises at least one of:a certificate for signing the avatar object of the avatar; oran address of a verification server for verifying the signed avatar object.26.The apparatus according to claim 25, wherein when the instructions are executed by the at least  one processor, the instructions further cause the apparatus at least to:transmit the certificate to a third network entity.27.The apparatus according to any of claims 18 to 26, wherein the security information is transmitted to the UE via a session initialization protocol (SIP) signaling during an extended reality (XR) media rending negotiation for rendering the avatar.28.The apparatus according to any of claims 18 to 27, wherein the first network entity is an internet protocol multimedia subsystem (IMS) application server.29.The apparatus according to any of claims 18 to 28, wherein the third network entity is a digital asset container (DAC) .30.The apparatus according to any of claims 18 to 29, wherein the avatar object of the avatar comprises avatar metadata of the avatar.31.An apparatus at a third network entity, the apparatus comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to:obtain security information for avatar object of an avatar for user equipment (UE) centric rendering of the avatar.32.The apparatus according to claim 31, wherein when the instructions are executed by the at least one processor, the instructions further cause the apparatus at least to:transmit the security information to a first network entity, for UE centric rendering of the avatar.33.The apparatus according to claim 32, wherein the security information is transmitted to the first network entity during an extended reality (XR) media rending negotiation for rendering the avatar.34.The apparatus according to claim 32 or 33, wherein the security information comprises a hash of the avatar object, andwherein when the instructions are executed by the at least one processor, the instructions further cause the apparatus at least to obtain the security information by generating the hash of the avatar object.35.The apparatus according to claim 34, wherein the hash of the avatar object is comprised in an avatar identifier of the avatar, andwherein when the instructions are executed by the at least one processor, the instructions further cause the apparatus at least to,generate the avatar identifier of the avatar comprising the hash; andtransmit the generated avatar identifier of the avatar to a UE.36.The apparatus according to claim 35, wherein the avatar identifier of the avatar further comprises at least one of:an initially fixed value of a unique identifier for the avatar;a message authentication code (MAC) , where a value of the MAC is generated based on a secret key, the initially fixed value of the unique identifier, and the hash of the avatar object; oran indication of an algorithm used to generate the hash of the avatar object.37.The apparatus according to claim 35 or 36, wherein the avatar identifier of the avatar is consisted of one of the following groups of information elements:a first group comprising an initially fixed value of a unique identifier for the avatar concatenated with the hash;a second group comprising merely the hash;a third group comprising an initially fixed value of a unique identifier for the avatar concatenated with the hash and a message authentication code (MAC) , where a value of the MAC is generated based on a secret key, the initially fixed value of the unique identifier, and the hash; ora fourth group comprising an initially fixed value of a unique identifier for the avatar concatenated with the hash and an indication of an algorithm used to generate the hash.38.The apparatus according to claim 36 or 37, wherein in case that the avatar identifier of the avatar comprises the MAC, when the instructions are executed by the at least one processor, the instructions further cause the apparatus at least to:receive the secret key from a first network entity; andgenerate the MAC based on a secret key, the initially fixed value of the unique identifier, and the hash of the avatar object.39.The apparatus according to claim 31, wherein the security information comprises at least one of:a certificate for signing the avatar object; oran address of a verification server for verifying the avatar object.40.The apparatus according to claim 39, wherein when the instructions are executed by the at least one processor, the instructions further cause the apparatus at least to:obtain the security information by receiving the certificate from a first network entity.41.The apparatus according to claim 39 or 40, wherein when the instructions are executed by the at least one processor, the instructions further cause the apparatus at least to:sign the avatar object of the avatar with the certificate; orobtain a signed avatar object from via a signing server.42.The apparatus according to claim 41, wherein when the instructions are executed by the at least one processor, the instructions further cause the apparatus at least to:transmit the signed avatar object to a second network entity.43.The apparatus according to any of claims 31 to 42, wherein the third network entity is a digital asset container (DAC) .44.The apparatus according to any of claims 31 to 43, wherein the first network entity is an internet protocol multimedia subsystem (IMS) application server.45.The apparatus according to claim 42, wherein the second network entity is an extended reality (XR) application server.46.The apparatus according to any of claims 31 to 45, wherein the avatar object of the avatar comprises avatar metadata of the avatar.47.A method performed at a user equipment (UE) , the method comprising:receiving from a first network entity, security information for avatar object of an avatar;receiving from a second network entity, avatar object of the avatar for UE centric rendering; andverifying authenticity of the avatar object received from the second network entity based on the received security information.48.The method according to claim 47, further comprising:if the verifying of the authenticity of the avatar object received from the second network entity is successful, rendering the avatar based on the avatar object received from the second network entity.49.The method according to claim 47 or 48, wherein the security information comprises a first hash of avatar object of the avatar.50.The method according to claim 49, further comprising:generating a second hash of the avatar object received from the second network entity; anddetermining whether the second hash matches the first hash or not.51.The method according to claim 50, wherein the first hash is comprised in an avatar identifier of the avatar, and wherein receiving the security information from the first network entity comprises receiving the avatar identifier of the avatar comprising the first hash.52.The method according to claim 51, further comprising:generating a local avatar identifier based on the second hash; anddetermining whether the generated local avatar identifier matches the avatar identifier received from the first network entity.53.The method according to claim 52, wherein the avatar identifier received from the first network entity further comprises at least one of:an initially fixed value of a unique identifier for the avatar;a message authentication code (MAC) , where a value of the MAC is generated based on a secret key, the initially fixed value of the unique identifier, and the first hash; oran indication of an algorithm used to generate the first hash.54.The method according to claim 53, wherein in case that the avatar identifier of the avatar comprises the MAC, the method further comprises:receiving the secret key from the first network entity; andgenerating a MAC for the local avatar identifier, based on the received secret key, the initially fixed value of the unique identifier, and the second hash.55.The method according to claim 53, wherein in case that the avatar identifier of the avatar comprises the indication of the algorithm, the second hash is generated using an algorithm indicated by the indication.56.The method according to claim 47 or 48, wherein the avatar object received from the second network entity are signed avatar object, and the security information comprises at least one of:a certificate for signing the avatar object of the avatar; oran address of a verification server for verifying the signed avatar object.57.The method according to claim 56, further comprising:verifying the signed avatar object using the certificate; orverifying the signed avatar object by communicating with the verification server via the address of the verification server.58.The method according to any of claims 47 to 57, wherein the security information is received from the first network entity via a session initialization protocol (SIP) signaling during an extended reality (XR) media rending negotiation for rendering the avatar.59.The method according to any of claims 47 to 58, wherein the avatar object is received from the second network entity via an application data channel.60.The method according to any of claims 47 to 59, wherein the first network entity is an internet protocol multimedia subsystem (IMS) application server.61.The method according to any of claims 47 to 60, wherein the second network entity is an extended reality (XR) application server.62.The method according to any of claims 47 to 61, wherein the avatar object of the avatar comprises avatar metadata of the avatar.63.A method performed at a first network entity, the method comprising:transmitting to a user equipment (UE) , security information for avatar object of an avatar for UE centric rendering of the avatar.64.The method according to claim 63, further comprising:receiving the security information from a third network entity.65.The method according to claim 64, wherein the security information comprises a hash of the avatar object of the avatar.66.The method according to claim 65, wherein the hash of the avatar object is comprised in an avatar identifier of the avatar, and wherein the method further comprises: receiving an avatar identifier of the avatar comprising the hash from the third network entity, and transmitting the received avatar identifier to the UE.67.The method according to claim 66, wherein the avatar identifier of the avatar further comprises at least one of:an initially fixed value of a unique identifier for the avatar;a message authentication code (MAC) , where a value of the MAC is generated based on a secret key, the initially fixed value of the unique identifier, and the hash of the avatar object; oran indication of an algorithm used to generate the hash of the avatar object.68.The method according to claim 67, wherein in case that the avatar identifier of the avatar comprises the MAC, the method further comprises:transmitting the secret key to the third network entity for a generation of the avatar identifier of the avatar with the hash of the avatar object; andtransmitting the secret key to the UE.69.The method according to claim 63, wherein the security information comprises at least one of:a certificate for signing the avatar object of the avatar; oran address of a verification server for verifying the signed avatar object.70.The method according to claim 69, further comprising:transmitting the certificate to a third network entity.71.The method according to any of claims 63 to 70, wherein the security information is transmitted to the UE via a session initialization protocol (SIP) signaling during an extended reality (XR) media rending negotiation for rendering the avatar.72.The method according to any of claims 63 to 71, wherein the first network entity is an internet protocol multimedia subsystem (IMS) application server.73.The method according to any of claims 63 to 72, wherein the third network entity is a digital asset container (DAC) .74.The method according to any of claims 63 to 73, wherein the avatar object of the avatar comprises avatar metadata of the avatar.75.A method performed at a third network entity, the method comprising:obtaining security information for avatar object for user equipment (UE) centric rendering of the avatar.76.The method according to claim 75, further comprising:transmitting the security information to a first network entity, for UE centric rendering of the avatar.77.The method according to claim 76, wherein the security information is transmitted to the first network entity during an extended reality (XR) media rending negotiation for rendering the avatar.78.The method according to claim 76 or 77, wherein the security information comprises a hash of the avatar object, and wherein obtaining the security information comprises generating the hash of the avatar object.79.The method according to claim 78, wherein the hash of the avatar object is comprised in an avatar identifier of the avatar, and, and wherein the method further comprises:generating the avatar identifier of the avatar comprising the hash; andtransmitting the generated avatar identifier of the avatar to a UE.80.The method according to claim 79, wherein the avatar identifier of the avatar further comprises at least one of:an initially fixed value of a unique identifier for the avatar;a message authentication code (MAC) , where a value of the MAC is generated based on a secret key, the initially fixed value of the unique identifier, and the hash of the avatar object; oran indication of an algorithm used to generate the hash of the avatar object.81.The method according to claim 80, wherein in case that the avatar identifier of the avatar comprises the MAC, the method further comprises:receiving the secret key from a first network entity; andgenerating the MAC based on a secret key, the initially fixed value of the unique identifier, and the hash of the avatar object.82.The method according to claim 75, wherein the security information comprises at least one of:a certificate for signing the avatar object; oran address of a verification server for verifying the avatar object.83.The method according to claim 82, further comprising:obtaining the security information by receiving the certificate from a first network entity.84.The method according to claim 82 or 83, further comprising:signing the avatar object of the avatar with the certificate; orobtaining a signed avatar object from via a signing server.85.The method according to claim 84, further comprising:transmitting the signed avatar object to a second network entity.86.The method according to any of claims 75 to 85, wherein the third network entity is a digital asset container (DAC) .87.The method according to any of claims 75 to 86, wherein the first network entity is an internet protocol multimedia subsystem (IMS) application server.88.The method according to claim 85, wherein the second network entity is an extended reality (XR) application server.89.An apparatus at a user equipment (UE) , the apparatus comprising:means for receiving from a first network entity, security information for avatar object of an avatar;means for receiving from a second network entity, avatar object of the avatar for UE centric rendering; andmeans for verifying authenticity of the avatar object received from the second network entity based on the received security information.90.An apparatus at a first network entity, the apparatus comprising:means for transmitting to a user equipment (UE) , security information for avatar objection of an avatar for UE centric rendering of the avatar.91.An apparatus at a third network entity, the apparatus comprising:means for obtaining security information for avatar object of an avatar for user equipment (UE) centric rendering of the avatar.92.A computer-readable medium having computer program codes embodied thereon which, when executed on a computer, cause the computer to perform the method according to any of claims 47 to 88.93.A computer program product comprising computer programs or instructions which, when executed by a processor, cause the method according to any of claims 47 to 88 to be implemented.

Images