WO2022050729A1

WO2022050729A1 - Methods and wireless communication networks for handling data driven model

Info

Publication number: WO2022050729A1
Application number: PCT/KR2021/011873
Authority: WO
Inventors: Ravi SURANA; Naveen Kolati; Hoonjae Lee; Bhavin Shah; Yongtae Kim
Original assignee: Samsung Electronics Co., Ltd.
Priority date: 2020-09-03
Filing date: 2021-09-02
Publication date: 2022-03-10
Also published as: EP4165828A1; US20220095131A1; US11963020B2; EP4165828A4

Abstract

Embodiments herein disclose methods for handling a data driven model in a wireless communication network (1000). The method includes identifying, by a first electronic device (100), a common data driven model capability between a capability information of one or more first data driven model and a capability information of one or more second data driven model. The one or more first data driven model is associated with the first electronic device (100) and the one or more second data driven model is associated with the second electronic device (200). Further, the method includes performing, by the first electronic device (100), one of: storing the common data driven model capability in the first electronic device (100) on identifying the common data driven model capability, and disabling a data driven model capability in the first electronic device (100) on not identifying the common data driven model capability.

Description

METHODS AND WIRELESS COMMUNICATION NETWORKS FOR HANDLING DATA DRIVEN MODEL

Embodiments disclosed herein relate to data driven model capability negotiation methods, and more specifically related to methods and wireless communication networks for handling a data driven model in electronic devices.

A data driven model (e.g., Artificial Intelligence (AI) model, Machine Learning (ML) model, or the like) will be used in future audio-video calls to provide new features (e.g., quality enhancement feature, up-sampling feature or the like) and to improve quality of services. Consider, each electronic device can have different versions of the data driven model, and feature set might differ between different model versions. Some data driven model versions may not be compatible with other versions. For example, a sender device (i.e., first electronic device) may use an AI model version x in a sending side data stream, but if a receiver side data stream (i.e., second electronic device) has version y of model and tries to process data, then functionality can break or may give poorer quality of service in the sender side and the receiver side.

The sender device needs to know what all models, versions and features are supported in the receiver device before using the AI model in its sending side data stream. The receiver device also needs to know which model, version and feature the sender device has used before processing any data using the AI model.

In existing methods, negotiation of call related parameters uses a Session Initiation Protocol (SIP)/Session Description Protocol (SDP). The negotiation using the SDP/SIP needs an operator support. If a server finds some unknown field in the SIP/SDP, the server might drop call or the server can remove unknown fields before forwarding it to the receiver side. So, the negotiation of the AI model related information may not always be possible using the SIP/SDP. During the call, the user of the sender device or receiver device may want to modify or enable or disable any AI model feature due to network or device conditions (such as packet loss, battery level, and so on) and if user device uses SIP/SDP method to convey this information to other side. The server can be flooded with the SIP/SDP messages as the network and device conditions might change frequently. This makes SIP/SDP based modifications cumbersome from both bandwidth and server processing perspective.

The principal object of the embodiments herein is to disclose methods and a wireless communication network for handling a data driven model in electronic devices.

Another object of the embodiments herein is to identify a common data driven model capability between capability information of one or more first data driven model and capability information of one or more second data driven model, where the one or more first data driven model is associated with a first electronic device and the one or more second data driven model is associated with the second electronic device.

Another object of the embodiments herein is to store the common data driven model capability in the first electronic device and the second electronic device on identifying the common data driven model capability.

Another object of the embodiments herein is to disable a data driven model capability in the first electronic device, and the second electronic device on not identifying the common data driven model capability.

Another object of the embodiments herein is to enable a configured common data driven model capability upon determining the configured common data driven model capability meets a predefined condition.

Another object of the embodiments herein is to disable the configured common data driven model capability upon determining the configured common data driven model capability does not meet the predefined condition.

Another object of the embodiments herein is to reconfigure a common data driven model capability based on a change in the predefined condition.

Another object of the embodiments herein is to negotiate/publish AI model capability using a Real-Time Transport Control Protocol (RTCP) Source Description RTCP Packets (SDES) message.

Accordingly, embodiments herein disclose methods for handling a data driven model in a wireless communication network. The method includes acquiring, by a first electronic device, capability information of one or more first data driven model associated with the first electronic device. Further, the method includes sending, by the first electronic device, a message comprising capability information of one or more first data driven model associated with the first electronic device. Further, the method includes receiving, by the first electronic device, a message comprising capability information of one or more second data driven model associated with a second electronic device. The first electronic device and the second electronic device are in a communication session. Further, the method includes identifying, by the first electronic device, a common data driven model capability between the capability information of the one or more first data driven model and the capability information of the one or more second data driven model. Further, the method includes performing, by the first electronic device, one of: storing the common data driven model capability in the first electronic device on identifying the common data driven model capability, and disabling a data driven model capability in the first electronic device on not identifying the common data driven model capability.

Accordingly, the embodiments herein disclose a first electronic device for handling a data driven model in a wireless communication network. The first electronic device includes a data driven model capability handling controller coupled with a processor and a memory. The data driven model capability handling controller is configured to acquire capability information of one or more first data driven model associated with the first electronic device. Further, the data driven model capability handling controller is configured to send a message comprising capability information of one or more first data driven model associated with the first electronic device. Further, the data driven model capability handling controller is configured to receive a message comprising capability information of one or more second data driven model associated with the second electronic device. The first electronic device and the second electronic device are in a communication session. Further, the data driven model capability handling controller is configured to identify a common data driven model capability between the capability information of the one or more first data driven model and the capability information of the one or more second data driven model. Further, the data driven model capability handling controller is configured to perform one of: store the common data driven model capability in the first electronic device on identifying the common data driven model capability, and disable a data driven model capability in the first electronic device on not identify that the common data driven model capability.

Accordingly, the embodiments herein disclose methods for handling a data driven model in a wireless communication network. The method includes creating by a first electronic device and a second electronic device, a RTCP SDES message. Further, the method includes identifying, by the first electronic device and the second electronic device, capability information comprising at least one of an AI model name, a ML model name, a version of the AI model, a version of the ML model, and a feature supported by at least one of an AI model and a ML model of the first electronic device and the second electronic device. Further, the method includes appending, by the first electronic device and the second electronic device, capability information of the first electronic device and the second electronic device to the RTCP SDES message. Further, the method includes causing by the first electronic device and the second electronic device, exchange of the capability information using the RTCP SDES message during an ongoing call.

The proposed method can be used for negotiating/publishing an AI model capability in the wireless communication network in an effective manner. The method can be used to dynamically handle the data driven model in the wireless communication network, while enabling/disabling/modifying the configured common data driven model capability without wasting any resources.

In the proposed method, a feature set negotiation has no dependency on an operator/server. The network/server will not strip or modify the data before forwarding it. Therefore, the feature negation will be guaranteed. Further, there is no additional bandwidth required for negotiation. The server will also not be flooded with packets to process.

These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions, while indicating at least one embodiment and numerous specific details thereof, are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the embodiments herein without departing from the spirit thereof, and the embodiments herein include all such modifications.

The embodiments disclosed herein are illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the various figures. The embodiments herein will be better understood from the following description with reference to the drawings, in which:

FIG. 1a is an overview of a wireless communication network for handling a data driven model, according to embodiments as disclosed herein;

FIG. 1b is another overview of the wireless communication network for handling the data driven model, according to embodiments as disclosed herein;

FIG. 1c is another overview of the wireless communication network for handling the data driven model, according to embodiments as disclosed herein;

FIG. 2 shows various hardware components of a first electronic device or a second electronic device for handling the data driven model, according to embodiments as disclosed herein;

FIG. 3 shows various hardware components of a data driven model capability handling controller in the first electronic device or the second electronic device, according to embodiments as disclosed herein;

FIG. 4 is a flow chart illustrating a method, implemented by the first electronic device, for handling the data driven model in the wireless communication network, according to embodiments as disclosed herein;

FIG. 5 and FIG. 6 are flow charts illustrating a method, implemented by the first electronic device and the second electronic device, for handling the data driven model in the wireless communication network, according to embodiments as disclosed herein;

FIG. 7 is an example sequence flow diagram illustrating step by step operations for negotiating/publishing an AI model capability using a RTCP SDES message in the wireless communication network, according to embodiments as disclosed herein;

FIG. 8 is an example sequence flow diagram illustrating step by step operations for handling the data driven model in the wireless communication network, while enabling a configured common data driven model capability, according to embodiments as disclosed herein;

FIG. 9 is an example sequence flow diagram illustrating step by step operations for handling the data driven model in the wireless communication network, while disabling the configured common data driven model capability, according to embodiments as disclosed herein;

FIG. 10 is an example sequence flow diagram illustrating step by step operations for handling the data driven model in the wireless communication network, while modifying the configured common data driven model capability, according to embodiments as disclosed herein; and

FIG. 11 is an example sequence flow diagram illustrating step by step operations for handling the data driven model in the wireless communication network, when the common data driven model capability is not found in the second electronic device, according to embodiments as disclosed herein.

The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein can be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.

The embodiments herein achieve methods for handling a data driven model in a wireless communication network. The method includes acquiring, by a first electronic device, capability information of one or more first data driven model associated with the first electronic device. Further, the method includes sending, by the first electronic device, a message comprising capability information of one or more first data driven model associated with the first electronic device. Further, the method includes receiving, by the first electronic device, a message comprising capability information of one or more second data driven model associated with a second electronic device. The first electronic device and the second electronic device are in a communication session. Further, the method includes identifying, by the first electronic device and the second electronic device, a common data driven model capability between the capability information of the one or more first data driven model and the capability information of the one or more second data driven model. Further, the method includes performing, by the first electronic device, one of: storing the common data driven model capability in the first electronic device on identifying the common data driven model capability, and disabling a data driven model capability in the first electronic device on not identifying the common data driven model capability.

Unlike conventional methods and systems, the proposed method can be used for negotiating/publishing the AI model capability in the wireless communication network in an effective manner. The method can be used to dynamically handle the data driven model in the wireless communication network, while enabling/disabling/modifying the configured common data driven model capability without wasting any resources. In the proposed method, the RTCP based AI model version and feature set negotiation has no dependency on an operator/server. The RTCP SDES is an end to end protocol, wherein the network/server will not strip or modify the data before forwarding it. So, the feature negation will be guaranteed. The RTCP SDES packets are sent periodically, even in current calls RTCP sent once in every 2 or 5 seconds. Thus, there is no additional bandwidth required for negotiation. The server will also not be flooded with packets to process.

The method can be used to dynamically handle the data driven model in the wireless communication network without changing any property/configuration of the server/ wireless communication network in a cost effective manner. The method can be used to improve audio or video quality of a call (e.g., video call, conference call or the like), restore/recover lost frames, enhance new user feature (e.g., augmented reality (AR) emoji feature or the like), and provide an end to end security (e.g., encryption and decryption) even in a lossy network and a bandwidth constrained environment.

Referring now to the drawings, and more particularly to FIGS. 1a through 11, where similar reference characters denote corresponding features consistently throughout the figures, there are shown at least one embodiment.

FIG. 1a is an overview of a wireless communication network (1000a) for handling a data driven model, according to embodiments as disclosed herein. In an embodiment, the wireless communication network (1000a) includes the first electronic device (100) and the second electronic device (200). The first electronic device (100) and the second electronic device (200) can be, for example, but not limited to a laptop, a desktop computer, a notebook, a relay device, a Device-to-Device (D2D) device, a vehicle to everything (V2X) device, a smartphone, a tablet, an internet of things (IoT) device, an immersive device or the like. The first electronic device (100) and the second electronic device (200) are in a communication session. The communication session can be, for example, but not limited to a video call session, a voice call session, a conference call session, a Mission Critical Push to Talk (MCPTT) session, Mission Critical Video (MCVideo) session, a content broadcasting session or the like.

The data driven model can be, for example, but not limited to a linear regression model, a logistic regression model, a linear discriminant analysis model, a decision trees model, a Naive Bayes model, a K-Nearest neighbors model, a learning vector quantization model, a support vector machine, a bagging and random forest model, a deep neural network, an unsupervised learning model, a supervised learning model or the like.

The first electronic device (100) is configured to acquire capability information of one or more first data driven model associated with the first electronic device (100). The capability information of the one or more first data driven model can be, for example, but not limited to an AI model name, a ML model name, a version of the AI model, a version of the ML model, and a feature supported by the AI model and a feature supported by a ML model.

Further, the first electronic device (100) is configured to receive the message including capability information of one or more second data driven model associated with the second electronic device (200). The first electronic device (100) is configured to send the message including capability information of one or more first data driven model associated with the first electronic device (100). The capability information of the one or more second or first data driven model can be, for example, but not limited to an AI model name, a ML model name, a version of the AI model, a version of the ML model, and a feature supported by AI model and a feature supported by a ML model. The message can be, for example, but not limited to a RTCP SDES message, a RTCP-application message, a RTP extension header, a RTCP message, a SIP information message, a SIP-XML message, a SIP-SDP message or the like.

The feature supported by the ML model can be, for example, but not limited to an up-scaling feature, a downscaling feature, an up-sampling feature, down-sampling feature a smoothening feature, a content recovering feature, a quality enhancement feature, an encryption feature, a decryption feature, an indoor feature, and an outdoor feature. The feature supported by the AI model can be, for example, but not limited to an up-scaling feature, a downscaling feature, an up-sampling feature, a smoothening feature, a content recovering feature, a quality enhancement feature, an encryption feature, a decryption feature, an indoor feature, and an outdoor feature.

In an embodiment, receiving the message in first electronic device (100) includes processing the generated capability information of the one or more second data driven model associated with from the second electronic device (200), identifying the capability information of the one or more second data driven model, appending the capability information of the one or more second data driven model to the message, sending the message comprising transmitting the capability information of the one or more second data driven model to the first electronic device (100) from second electronic device (200).

After receiving the message including the capability information of one or more second data driven model associated with the second electronic device (200), the first electronic device (100) is configured to identify a common data driven model capability between the capability information of the one or more first data driven model and the capability information of the one or more second data driven model. On identifying the common data driven model capability, the first electronic device (100) is configured to store the common data driven model capability in the first electronic device (100).

In another example, as per RFC: 3550 and Section: 6.5, the RTCP SDES message uses a customized strings (no protocol restrictions) to publish/negotiate any information using a RTCP SDES packet. The RTCP SDES packet includes fields such as CName, TOOL, PRIV, and so on, to publish/negotiate AI model details. Each device (100 and 200) will publish its own AI model capability in the RTCP SDES message during the call, and based on received RTCP SDES information from both devices (100 and 200), the device (100 and 200) will select the common version and set it to AI model before using it. If the common version is found and configured, then the devices (100 and 200) are assumed that both devices (100 and 200) support the same set of feature and AI model encoding/decoding performance will also be the same. If common version is not found, then AI model usage will be disabled in the both devices (100 and 200).

Consider, in another example, in a direct video call between the first electronic device (100) and the second electronic device (200), if the first electronic device (100) supports the AI Model: X with version 1, 3, and 5 it will send RTCP SDES message with version numbers 1, 3, and 5. If the second electronic device (200) supports the AI Model: X with version: 3, 5, and 7, it will send the RTCP SDES message with version numbers 3, 5, and 7. Both the electronic devices (100 and 200) get the SDES message from the other device, and will set version 5 to AI Model: X before using it (assuming higher version numbers are preferred over the lower version).

In the proposed method, the RTCP based AI model version and feature set negotiation has no dependency on an operator/server. The RTCP SDES is an end to end protocol, wherein the network/server will not strip or modify the data before forwarding it. So, the feature negation will be guaranteed. The RTCP SDES packets are sent periodically, even in current calls RTCP sent once in every 2 or 5 seconds. Thus, there is no additional bandwidth required for negotiation. The server will also not be flooded with packets to process.

Further, the RTCP SDES is typically smaller in size compared to SIP/SDP packets. So, in cases where the RTCP SDES are not currently used, bandwidth consumption and processing time will be lesser, when the RTCP SDES is used. Also, it is easier to share the AI model or feature information with other side using the RTCP SDES during call due to dedicated end-to-end path.

Considering, CName as an example of the SDES field being used to convey capability information to other side of the electronic device (200). The below format defines to publish AI model capability to other electronic device (200). This format can be different for each AI model. An example format for publishing AI model capability to the other side is depicted below:

Cname Format: ModelName_Version_FeatureSet

ModelName: AI Model name, delimited with "_" with no fixed length. In current example, embodiments herein consider "SN" as model name.

Version: "n" characters, each character representing a Hex Value. Delimited with "_" with no fixed length. Each bit of the formed hexadecimal number represents one version. Large number of versions can be supported by simply setting appropriate bit in hexadecimal number.

Feature Set: Optional Parameter. This indicates the features which are/will be used for that particular negotiated version. Large number of features can be supported with each feature delimited with "_" with no fixed length. Each feature will have its own rule for interpretation.

The string, AI/ML model, version Number and feature sets are of any length but each separated by a delimiter.

In the current example, "scaling" is considered as one feature. If a version is supporting more than one scaling factor, then electronic device (100) will send the scaling factor being used to process data being sent. In an example, the rule for scaling factor is defined as below:

ScalingFactor: 1 character, represented in Hex Value, Maximum 14 scaling factors can be supported, and each value represents one scaling factor where 0 and F are reserved. 0 represents AI Model "SN" disabled and not supported, F represents AI model "SN" supported but scaling factor is still not decided.

Consider that there are the first and second electronic devices (100 and 200) which have following AI model capabilities:

First electronic device (100): Supporting AI Model "SN" with Versions 1, 3, 5.

Second electronic device (200): Supporting AI Model "SN" with Versions 3, 6.

Initially, the scaling factor is undecided. So, the following CName strings are set out by the first electronic device (100) and the second electronic device (200).

First electronic device (100): SN_15_F. 15 is 00010101 in hexadecimal, bits 1, 3 and 5 are set.

Second electronic device (200): SN_24_F. 24 is 00100100 in hexadecimal, bits 3 and 6 are set.

Once this exchange of SDES packet is complete, both devices (100 and 200) can discover that maximum supported version is 3. After this, Scaling Factors can be chosen to level 2. Then, CName string becomes

First electronic device (100): SN_15_2

Second electronic device (200): SN_24_2

The hexadecimal numerals (0-F) used can be mapped to a different printable range or hash map used. For example, A-P can be used such that 0=A, 1=B, 2=C,..., F=P. So, CName strings can alternatively be

First electronic device (100): SN_BF_C

Second electronic device (200): SN_CE_C

In another example, the call is established between the first electronic device (100) and the second electronic device (200). The first electronic device (100) supports two AI models (X and Y) with multiple versions of each model (i.e., AI model: Y with version 1, 2, 4 and AI model: X with version 2, 3). The second electronic device (200) supports one AI Model (X) with multiple versions of each model (i.e., AI model: X with version 2, 5). Further, the first electronic device (100) sends the RTCP SDES with 1) AI model: Y with version 1, 2, 4 and 2) AI model: X with

version

2, 3 to the second electronic device (200). Further, the second electronic device (200) sends the RTCP SDES with AI model: X with version 2, 5 to the the first electronic device (100). Based on the proposed method, the RTCP SDES based AI model negotiation, compatible model and version is set in both electronic devices (100 and 200) before AI model usage. Hence, in the first electronic device (100), AI model: X with version 2 will be used in the video call based on the need and AI model Y usage will be disabled, similarly, in the second electronic device (200), AI model: X with version 2 will be used in the video call based on the need.

Upon not identifying that the common data driven model capability, the first electronic device (100) or the second electronic device (200) is configured to disable a data driven model capability in the first electronic device (100) or the second electronic device (200). In an example, the call is established between the first electronic device (100) and the second electronic device (200). The first electronic device (100) supports the AI model SN with version 1, 3, 5 [10101] and the second electronic device (200) does not supports the AI model. Further, the first electronic device (100) sends the Cname:SN_15_F to the second electronic device (200), and the second electronic device (200) sends the Cname:not present or unknown format to the first electronic device (100). Hence, the first electronic device (100) finds that the Cname is not present or unknown format in the second electronic device (200), so that the first electronic device (100) assumes that the second electronic device (200) is not supported by the AI model and disables the AI model in the first electronic device (100).

Further, the first electronic device (100) configures the common data driven model capability in the first electronic device (100) and send the configured common data driven model capability to the second electronic device (200).

Further, the first electronic device (100) is configured to determine whether the configured common data driven model capability meets a predefined condition. The predefined condition is determined based on a parameter, wherein the parameter can be, for example, but not limited to a condition of the first electronic device (100), a condition of the second electronic device (200), a condition of a network, a type of the network, a temperature associated with the first electronic device (100), a temperature associated with the second electronic device (200), a packet loss, jitter, a delay in communication, a resolution of a content, a speed of transmission of the content, an ambient condition associated with the first electronic device (100), and an ambient condition associated with the second electronic device (200). Upon determining the configured common data driven model capability meets the predefined condition, the first electronic device (100) is configured to enable the configured common data driven model capability. In an example, step by step operations for handling the data driven model in the wireless communication network, while enabling the configured common data driven model capability, is explained in the FIG. 8.

Upon determining the configured common data driven model capability does not meet the predefined condition, the first electronic device (100) is configured to disable the configured common data driven model capability. In an example, step by step operations for handling the data driven model in the wireless communication network (1000a), while disabling the configured common data driven model capability, is explained in the FIG. 9.

Further, the first electronic device (100) is configured to determine a change in the predefined condition and reconfigure a common data driven model capability based on the change in the predefined condition. In an example, step by step operations for handling the data driven model in the wireless communication network (1000a), while modifying the configured common data driven model capability, is explained in the FIG. 10.

FIG. 1b is another overview of the wireless communication network (1000b) for handling the data driven model, according to embodiments as disclosed herein. In an embodiment, the wireless communication network (1000b) includes the first electronic device (100) and one or more second electronic device (200a-200n). The operations and functions of the first electronic device (100) and the one or more second electronic device (200a-200n) are already explained in conjunction with the FIG. 1a. For the sake of brevity, the repeated operations are omitted in the patent disclosure.

FIG. 1c is another overview of the wireless communication network (1000c) for handling the data driven model, according to embodiments as disclosed herein. As shown in the FIG. 1c, the first electronic device (100) or the second electronic device (200) is communicated with the server (300). The operations and functions of the first electronic device (100) and the second electronic device (200) are already explained in conjunction with the FIG. 1a. For the sake of brevity, the repeated operations are omitted in the patent disclosure.

FIG. 2 shows various hardware components of the first electronic device (100) or the second electronic device (200), according to embodiments as disclosed herein. In an embodiment, the first electronic device (100) or the second electronic device (200) includes a data driven model capability handling controller (110), a communicator (120), a memory (130), a processor (140), and a display (150). The processor (140) is coupled with the data driven model capability handling controller (110), the communicator (120), the memory (130), and the display (150). For the sake of clarity, we have explained that the data driven model capability handling controller (110) is placed/operated in the first electronic device (100) and similar operations handled by the data driven model capability handling controller (110) is placed/operated in the second electronic device (200).

In an embodiment, the data driven model capability handling controller (110) is configured to acquire capability information of one or more first data driven model associated with the first electronic device (100). Append the capability information to message and send message to the second electronic device (200). Further, the data driven model capability handling controller (110) is configured to receive the message including capability information of one or more second data driven model associated with the second electronic device (200). After receiving the message comprising capability information of one or more second data driven model associated with the second electronic device (200), the data driven model capability handling controller (110) is configured to identify the common data driven model capability between the capability information of the one or more first data driven model and the capability information of the one or more second data driven model.

On identifying the common data driven model capability, the data driven model capability handling controller (110) is configured to store the common data driven model capability in the first electronic device (100). Upon not identifying that the common data driven model capability, the data driven model capability handling controller (110) is configured to disable the data driven model capability in the first electronic device (100).

Further, the data driven model capability handling controller (110) configures the common data driven model capability in the first electronic device (100) and send the configured common data driven model capability to the second electronic device (200).

Further, the data driven model capability handling controller (110) is configured to determine whether the configured common data driven model capability meets the predefined condition. Upon determining the configured common data driven model capability meets the predefined condition, the data driven model capability handling controller (110) is configured to enable the configured common data driven model capability. Upon determining the configured common data driven model capability does not meet the predefined condition, the data driven model capability handling controller (110) is configured to disable the configured common data driven model capability.

Further, the data driven model capability handling controller (110) is configured to determine the change in the predefined condition and reconfigure the common data driven model capability based on the change in the predefined condition.

Further, the processor (140) is configured to execute instructions stored in the memory (130) and to perform various processes. The communicator (120) is configured for communicating internally between internal hardware components and with external devices via one or more networks. The memory (130) also stores instructions to be executed by the processor (140). The memory (130) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory (130) may, in some examples, be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non-transitory" should not be interpreted that the memory (130) is non-movable. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache).

Further, at least one of the plurality of modules/controller may be implemented through the AI model. A function associated with the AI model may be performed through the non-volatile memory, the volatile memory, and the processor (140). The processor (140) may include one or a plurality of processors. At this time, one or a plurality of processors may be a general purpose processor, such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and/or an AI-dedicated processor such as a neural processing unit (NPU).

The one or a plurality of processors control the processing of the input data in accordance with a predefined operating rule or AI model stored in the non-volatile memory and the volatile memory. The predefined operating rule or artificial intelligence model is provided through training or learning.

Here, being provided through learning means that a predefined operating rule or AI model of a desired characteristic is made by applying a learning algorithm to a plurality of learning data. The learning may be performed in a device itself in which AI according to an embodiment is performed, and/o may be implemented through a separate server/system.

The AI model may comprise of a plurality of neural network layers. Each layer has a plurality of weight values, and performs a layer operation through calculation of a previous layer and an operation of a plurality of weights. Examples of neural networks include, but are not limited to, convolutional neural network (CNN), deep neural network (DNN), recurrent neural network (RNN), restricted Boltzmann Machine (RBM), deep belief network (DBN), bidirectional recurrent deep neural network (BRDNN), generative adversarial networks (GAN), and deep Q-networks.

The learning algorithm is a method for training a predetermined target device (for example, a robot) using a plurality of learning data to cause, allow, or control the target device to make a determination or prediction. Examples of learning algorithms include, but are not limited to, supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning.

Although the FIG. 2 shows various hardware components of the first electronic device (100) or the second electronic device (200) but it is to be understood that other embodiments are not limited thereon. In other embodiments, first electronic device (100) or the second electronic device (200) may include less or more number of components. Further, the labels or names of the components are used only for illustrative purpose and does not limit the scope of the invention. One or more components can be combined together to perform same or substantially similar function in the first electronic device (100) or the second electronic device (200).

FIG. 3 shows various hardware components of the data driven model capability handling controller (110) in the first electronic device (100) or the second electronic device (200), according to embodiments as disclosed herein. In an embodiment, the data driven model capability handling controller (110) includes a data driven model capability information acquiring controller (210), a common data driven model capability identifying controller (220), and a data driven model capability controller (230). In an embodiment, the data driven model capability information acquiring controller (210) is configured to acquire the capability information of one or more first data driven model associated with the first electronic device (100). Further, Append the capability information to message and send message to second electronic device (200). Further, the data driven model capability information acquiring controller (210) is configured to receive the message including capability information of one or more second data driven model associated with the second electronic device (200).

After receiving the message comprising capability information of one or more second data driven model associated with the second electronic device (200), the common data driven model capability identifying controller (220) is configured to identify the common data driven model capability between the capability information of the one or more first data driven model and the capability information of the one or more second data driven model. On identifying the common data driven model capability, the data driven model capability controller (230) is configured to store the common data driven model capability in the first electronic device (100). Upon not identifying that the common data driven model capability, the data driven model capability controller (230) is configured to disable the data driven model capability in the first electronic device (100).

Further, the data driven model capability controller (230) configures the common data driven model capability in the first electronic device (100) and send the configured common data driven model capability to the second electronic device (200). Further, the data driven model capability controller (230) is configured to determine whether the configured common data driven model capability meets the predefined condition.

Upon determining the configured common data driven model capability meets the predefined condition, the data driven model capability controller (230) is configured to enable the configured common data driven model capability. Upon determining the configured common data driven model capability does not meet the predefined condition, the data driven model capability controller (230) is configured to disable the configured common data driven model capability. Further, the data driven model capability controller (230) is configured to determine the change in the predefined condition and reconfigure the common data driven model capability based on the change in the predefined condition.

Although the FIG. 3 shows various hardware components of the data driven model capability handling controller (110) but it is to be understood that other embodiments are not limited thereon. In other embodiments, the data driven model capability handling controller (110) may include less or more number of components. Further, the labels or names of the components are used only for illustrative purpose and does not limit the scope of the invention. One or more components can be combined together to perform same or substantially similar function in the data driven model capability handling controller (110).

FIG. 4 is a flow chart (400) illustrating a method, implemented by the first electronic device (100), for handling the data driven model in the wireless communication network (1000), according to embodiments as disclosed herein. Hereafter, the label of the wireless communication network is 1000. The operations (402-422) are performed by the the data driven model capability handling controller (110).

At 402, the method includes acquiring the capability information of first data driven model associated with the first electronic device (100), At 404, the method includes appending the capability information to message and sending the message to the second electronic device (200). At 406, the method includes receiving the message comprising the capability information of the second data driven model associated with the second electronic device (200).

At 408, the method includes identifying the common data driven model capability between the capability information of the first data driven model and the capability information of the second data driven model. If the common data driven model capability is identified between the capability information of the first data driven model and the capability information of the second data driven model then, at 410, the method includes storing the common data driven model capability in the first electronic device (100).

If the common data driven model capability is not identified between the capability information of the first data driven model and the capability information of the second data driven model then, at 412, the method includes disabling the data driven model capability in the first electronic device (100). At 414, the method includes configuring the common data driven model capability in the first electronic device (100).

At 416, the method includes determining whether the configured common data driven model capability meets the predefined condition. If the configured common data driven model capability meets the predefined condition then, at 418, the method includes enabling the configured common data driven model capability. If the configured common data driven model capability does not meet the predefined condition then, at 420, the method includes disabling the configured common data driven model capability.

At 422, the method includes determining the change in the predefined condition. At 424, the method includes reconfiguring the common data driven model capability based on the change in the predefined condition and convey reconfigured information to other device.

FIG. 5 and FIG. 6 are flow charts (500 and 600) illustrating a method, implemented by the first electronic device (100) and the second electronic device (200), for handling the data driven model in the wireless communication network (1000), according to embodiments as disclosed herein.

As shown in the FIG. 5, the operations (502-508) are performed by the the data driven model capability handling controller (110) of the first electronic device (100) and the second electronic device (200). At 502, the method includes creating the RTCP SDES message. At 504, the method includes identifying the capability information comprising the AI model name, the ML model name, the version of the AI model, the version of the ML model, and the feature supported by the AI model and the ML model of the first electronic device (100) and the second electronic device (200). At 506, the method includes appending the capability information of the first electronic device (100) and the second electronic device (200) to the RTCP SDES message. At 508, the method includes causing to exchange of the capability information using the RTCP SDES message during the call.

As shown in the FIG. 6, the operations (602-608) are performed by the the data driven model capability handling controller (110) of the first electronic device (100) and the second electronic device (200). At 602, the method includes creating the string information based on the available AI model, the ML model in the first electronic device (100) and the second electronic device (200), the device condition, and network condition. At 604, the method includes appending the string information to the RTCP SDES message. At 606, the method includes sending the RTCP SDES message to the server (300) or the network (1000). At 608, the method includes receiving the RTCP SDES message from the server (300) or the network (1000). At 610, the method includes enabling the AI model and the ML model based on the device condition and the network condition or disabling the AI model and the ML model based on the device condition and the network condition or reconfiguring the AI model and the ML model based on the device condition and the network condition.

By using RTCP SDES message, the proposed method has no dependency on network entities as the RTCP SDES message string fields are customizable as per specification. Hence, feature negotiation is guaranteed. Further, the RTCP SDES packets are sent periodically in current calls every 2 seconds. Thus, no additional bandwidth required for negotiation and the server will not be flooded with packets to process.

The various actions, acts, blocks, steps, or the like in the flow charts (400-600) may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some of the actions, acts, blocks, steps, or the like may be omitted, added, modified, skipped, or the like without departing from the scope of the invention.

FIG. 7 is an example sequence flow diagram illustrating step by step operations for negotiating/publishing an AI model capability using the RTCP SDES message in the wireless communication network (1000), according to embodiments as disclosed herein.

At S702, the call is established between the first electronic device (100) and the second electronic device (200). The first electronic device (100) supports two AI models (X and Y) with multiple versions of each model (i.e., AI model: Y with version 1, 2, 4 and AI model: X with version 2, 3). The second electronic device (200) supports one AI Model (X) with multiple versions of each model (i.e., AI model: X with version 2, 5). At S704, the first electronic device (100) sends the RTCP SDES with 1) AI model: Y with version 1, 2, 4 and 2) AI model: X with

version

2, 3 to the second electronic device (200). At S706, the second electronic device (200) sends the RTCP SDES with AI model: X with version 2, 5 to the the first electronic device (100). Based on the proposed method, the RTCP SDES based AI Model negotiation, compatible model and version is set in both electronic devices (100 and 200) before AI model usage. Hence, in the first electronic device (100), AI model: X with version 2 will be used in the video call based on the need and AI model Y usage will be disabled, similarly, in the second electronic device (200), AI model: X with version 2 will be used in the video call based on the need.

FIG. 8 is an example sequence flow diagram illustrating step by step operations for handling the data driven model in the wireless communication network (1000), while enabling a configured common data driven model capability, according to embodiments as disclosed herein.

In conventional methods, when there is packet loss, the method can be used to reducing a sending bitrate and downgrade video resolution [e.g., Video Graphics Array (VGA) to Quarter Video Graphics Array (QVGA) OR high definition (HD)->VGA->QVGA]. But, this will impact user experience as quality of image will degrade because of less video resolution. Based on the proposed method, the method is using AI scaler AI module to intelligently upscale and downscale image without impacting user experience or degrading image quality. In the first electronic device (100) (i.e., sending side), if scaling factor is 2 then, AI model will take VGA as input resolution, downscale and output QVGA resolution [VGA = QVGA*2]. In the second electronic device (200) (i.e., receiving side) if scaling factor is 2 then, the AI model will take QVGA as input resolution, upscale and output VGA resolution [VGA = QVGA*2]. As same AI model and version used in both side [upscale & downgrade] quality of image will be much better compared to the conventional method. Hence, even in constrained bandwidth network condition, based on the proposed method, the method can be used to provide the better video call experience to user.

At S802, the call is established between the first electronic device (100) and the second electronic device (200). The first electronic device (100) supports the AI model SN with version 1, 3, 5 [10101] and the second electronic device (200) supports the AI model SN with version 3, 6 [100100]. At S804, the first electronic device (100) sends the Cname:SN_15_F to the second electronic device (200). At S806, the second electronic device (200) sends the Cname:SN_24_F to the first electronic device (100). Both electronic devices (100 and 200) configured version 3 for "SN" AI model, but both electronic devices (100 and 200) still not using the AI model. Based on the first electronic device decision based on the packet loss, network type, device internal logic and so on, the first electronic device (100) started to use the AI model SN with scaling factor 2. Hence, at S808, the first electronic device (100) sends the Cname:SN_15_2 to the second electronic device (100). The second electronic device (200) will use the AI model SN and version 3. Hence, the first electronic device (100) uses the AI model in the sending side data stream (i.e., sending stream) and the second electronic device (200) uses the AI model in the receiving side data stream (i.e., receiving stream). Based on the second electronic device decision, the second electronic device (100) is started to use the AI model SN with scaling factor 2 in sending stream and first electronic device (100) uses the AI model in the receiving stream. At S810, the second electronic device (200) sends the Cname:SN_24_2 to the first electronic device (100). Hence, the first electronic device (100) and the second electronic device (200) will use AI model SN, version 3 and scaling factor 2 in the sending stream and receiving stream.

FIG. 9 is an example sequence flow diagram illustrating step by step operations for handling the data driven model in the wireless communication network (1000), while disabling the configured common data driven model capability, according to embodiments as disclosed herein.

At S902, the call is established between the first electronic device (100) and the second electronic device (200). The first electronic device (100) supports the AI model SN with version 1, 3, 5 [10101] and the second electronic device (200) supports the AI model SN with version 3, 6 [100100]. At S904, the first electronic device (100) sends the Cname:SN_15_F to the second electronic device (200). At S906, the second electronic device (200) sends the Cname:SN_24_F to the first electronic device (100). Both electronic devices (100 and 200) configured version 3 for "SN" AI model, but both electronic devices (100 and 200) still not using the AI model.

Based on the first electronic device decision, the first electronic device (100) started to use the AI model SN with scaling factor 2. At S908, the first electronic device (100) sends the Cname:SN_15_2 to the second electronic device (100). The second electronic device (200) will use the AI model SN and version 3. Hence, the first electronic device (100) uses the AI model in the sending stream and the second electronic device (200) uses the AI model in the receiving stream. Based on the second electronic device decision, the second electronic device (100) disables the usage of the AI model. At S910, the second electronic device (200) sends the Cname:SN_24_0 to the first electronic device (100). Hence, the first electronic device (100) and the second electronic device (200) will not use AI model in the sending stream and receiving stream.

FIG. 10 is an example sequence flow diagram illustrating step by step operations for handling the data driven model in the wireless communication network (1000), while modifying the configured common data driven model capability, according to embodiments as disclosed herein.

At S1002, the call is established between the first electronic device (100) and the second electronic device (200). The first electronic device (100) supports the AI model SN with version 1, 3, 5 [10101] and the second electronic device (200) supports the AI model SN with version 3, 6 [100100]. At S1004, the first electronic device (100) sends the Cname:SN_15_F to the second electronic device (200). At S1006, the second electronic device (200) sends the Cname:SN_24_F to the first electronic device (100). Both electronic devices (100 and 200) configured version 3 for "SN" AI model, but both electronic devices (100 and 200) still not using the AI model.

Based on the first electronic device decision, the first electronic device (100) started to use the AI model SN with scaling factor 2. At S1008, the first electronic device (100) sends the Cname:SN_15_2 to the second electronic device (100). The second electronic device (200) will use the AI model SN, version 3 and scaling factor 2. Hence, the first electronic device (100) uses the AI model in the sending stream and the second electronic device (200) uses the AI model with scaling factor 2 in the receiving stream. Based on the second electronic device decision due to ambient network issues, the second electronic device (100) starts the usage of the AI model with scaling factor 3. At S1010, the second electronic device (200) sends the Cname:SN_24_3 to the first electronic device (100). Based on the received Cname:SN_24_3, the first electronic device (100) modify to use a more bitrate saving feature parameter. Hence, the first electronic device (100) uses the AI model in the receiving stream with the scaling factor 3 and the second electronic device (200) uses the AI model in the sending stream with the scaling factor 3.

FIG. 11 is an example sequence flow diagram illustrating step by step operations for handling the data driven model in the wireless communication network (1000), when the common data driven model capability is not found in the second electronic device (200) (e.g., legacy device), according to embodiments as disclosed herein.

At S1102, the call is established between the first electronic device (100) and the second electronic device (200). The first electronic device (100) supports the AI model SN with version 1, 3, 5 [10101] and the second electronic device (200) does not supports the AI model. At S1104, the first electronic device (100) sends the Cname:SN_15_F to the second electronic device (200). At S1106, the second electronic device (200) sends RTCP SDES message where The Cname:not present or unknown value present in Cname header OR RTCP SDES itself not present Hence, the first electronic device (100) finds that the Cname is not present or unknown format in the second electronic device (200), so that the first electronic device (100) assumes that the second electronic device (200) is not supported by the AI model and disables the AI model in the first electronic device (100).

In the patent disclosure, the method can be used to negotiate/publish the AI model capability using the RTCP SDES message, but it also extended to use in any other message format (e.g., SDES message field format, RTP Extension Header, other RTCP messages, etc.).

Further, the AI/ML model capabilities can alternatively be negotiated over the SIP-SDP message which can be exchanged at the call start or during the call if any modification is required. Below is the sample SIP-SDP format:

a=aimodel:<model_name> <versions>/<feature_set>

if the first electronic device (100) supports the AI model: SN with version 1,3,5 & AI model: SAI with version 1,4 then sample SDP structure looks like below:

m=video 55790 RTP/AVPF 118

a=rtpmap:118 H264/90000

a=fmtp:118 profile-level-id=42C00C; packetization-mode=1;

a=aimodel:<SN> <1,3,5>/<F>

a=aimodel:<SAI> <1,4>/<F>

In an embodiment, the capability information of the one or more first data driven model comprises at least one of an artificial intelligence (AI) model name, a machine learning (ML) model name, a version of the AI model, a version of the ML model, and a feature supported by the AI model and a feature supported by the ML Model, where the capability information of the one or more second data driven model comprises at least one of an AI model name, a ML model name, a version of the AI model, a version of the ML model, and a feature supported by the AI model and a feature supported by the ML model.

In an embodiment, further, the method includes configuring, by the first electronic device, the common data driven model capability in the first electronic device. Further, the method includes sending, by the first electronic device, the configured common data driven model capability to the second electronic device.

In an embodiment, further, the method includes determining, by the first electronic device, whether the configured common data driven model capability meets a predefined condition. Further, the method includes performing, by the first electronic device, at least one of: enabling, by the first electronic device, the configured common data driven model capability upon determining the configured common data driven model capability meets the predefined condition, and disabling, by the first electronic device, the configured common data driven model capability upon determining the configured common data driven model capability does not meet the predefined condition.

In an embodiment, further, the method includes determining, by the first electronic device, a change in the predefined condition. Further, the method includes reconfiguring, by the first electronic device, a common data driven model capability based on the change in the predefined condition.

In an embodiment, the message comprising the capability information of the one or more second data driven model is received from the second electronic device by generating the message, identifying the capability information of the one or more second data driven model, appending the capability information of the one or more second data driven model to the message, sending the message comprising the capability information of the one or more second data driven model to the first electronic device, and receiving the message comprising the capability information of the one or more first data driven model from the first electronic device.

In an embodiment, the predefined condition is determined based on a parameter, wherein the parameter comprises at least one of a condition of the first electronic device, a condition of the second electronic device, a condition of a network, a type of the network, a temperature associated with the first electronic device, a temperature associated with the second electronic device, a packet loss, Jitter, a delay in communication, a resolution of a content, a speed of transmission of the content, an ambient condition associated with the first electronic device, and an ambient condition associated with the second electronic device.

In an embodiment, the message comprises at least one of a RTCP SDES message, a RTCP-application message, a Real-time Transport Protocol (RTP) extension header, a RTCP message, a SIP information message, a Session Initiation Protocol-eXtensible Markup Language (SIP-XML) message and a Session Initiation Protocol-Session Description Protocol (SIP-SDP) message.

In an embodiment, the feature supported by the ML model includes an up-scaling feature, a downscaling feature, an up-sampling feature, down-sampling feature, a smoothening feature, a content recovering feature, a loss recovering feature, a content modification feature, quality enhancement feature, an encryption feature, a decryption feature, an indoor feature, and an outdoor feature, where the feature supported by the AI model includes an up-scaling feature, a downscaling feature, an up-sampling feature, a down-sampling feature, a smoothening feature, a content recovering feature, a loss recovering feature, a content modification feature, a quality enhancement feature, an encryption feature, a decryption feature, an indoor feature, and an outdoor feature.

In an embodiment, the data driven model includes at least one of a linear regression model, a logistic regression model, a linear discriminant analysis model, a decision trees model, a Naive Bayes model, a K-Nearest neighbors model, a learning vector quantization model, a support vector machine, a bagging and random forest model, a deep neural network, an unsupervised learning model, and a supervised learning model.

Accordingly, the embodiments herein disclose methods for handling a data driven model in a wireless communication network. The method includes creating, by a first electronic device and a second electronic device, a string information based on at least one of available AI model, a ML model in the first electronic device and the second electronic device, a device condition, and network condition. Further, the method includes appending, by the first electronic device and the second electronic device, the string information to a RTCP SDES message. Further, the method includes sending, by the first electronic device and the second electronic device, the RTCP SDES message to at least one of a server and a network. Further, the method includes receiving, by the first electronic device and the second electronic device, the RTCP SDES message from at least one of the server and the network. Further, the method includes performing, by the first electronic device and the second electronic device, one of enabling at least one of the AI model and the ML model based on at least one of the device condition and the network condition, disabling at least one of the AI model and the ML model based on at least one of the device condition and the network condition, and reconfiguring at least one of the AI model and the ML model based on at least one of the device condition and the network condition.

Accordingly, the embodiments herein disclose a wireless communication network for handling a data driven model. The wireless communication network includes a first electronic device and a second electronic device. The first electronic device and the second electronic device are configured to create a RTCP SDES message. The first electronic device and the second electronic device are configured to identify capability information comprising at least one of an AI model name, a ML model name, a version of the AI model, a version of the ML model, and a feature supported by the ML model and AI model. The first electronic device and the second electronic device are configured to append capability information of the first electronic device and the second electronic device to the RTCP SDES message. The first electronic device and the second electronic device are configured to exchange the capability information using the RTCP SDES message during an ongoing call.

Accordingly, the embodiments herein disclose a wireless communication network for handling a data driven model. The wireless communication network includes a first electronic device and a second electronic device. The first electronic device and the second electronic device are configured to create a string information based on at least one of available AI model, a ML model in the first electronic device and the second electronic device, a device condition, and network condition. Further, the first electronic device and the second electronic device are configured to append the string information to a RTCP SDES message. Further, the first electronic device and the second electronic device are configured to exchange the RTCP SDES message. Further, the first electronic device and the second electronic device are configured to enable at least one of the AI model and the ML model based on at least one of the device condition and the network condition.

Accordingly, the embodiments herein disclose methods for handling a data driven model in a wireless communication network. The method includes initiating, by a first electronic device and a second electronic device, a call between the first electronic device and the second electronic device. Further, the method includes creating, by the first electronic device and the second electronic device, a RTCP SDES message comprising device capabilities of the first electronic device and the second electronic device. Further, the method includes exchanging, by the first electronic device and the second electronic device, the created RTCP SDES message comprising the device capabilities between the first electronic device and the second electronic device. The device capabilities comprise an AI model name, a ML model name, versions and features supported by first electronic device and the second electronic device.

Accordingly, the embodiments herein disclose a wireless communication network for handling a data driven model. The wireless communication network includes a first electronic device and a second electronic device. The first electronic device and the second electronic device are configured to initiate a call between the first electronic device and the second electronic device. Further, the first electronic device and the second electronic device are configured to create a RTCP SDES message comprising device capabilities of the first electronic device and the second electronic device. Further, the first electronic device and the second electronic device are configured to exchange the created RTCP SDES message comprising the device capabilities between the first electronic device and the second electronic device. The device capabilities comprise an AI model name, a ML model name, versions and features supported by first electronic device and the second electronic device.

The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the elements. The elements can be at least one of a hardware device, or a combination of hardware device and software module.

The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of at least one embodiment, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the embodiments as described herein.

Claims

A method for handling a data driven model in a wireless communication network (1000), the method comprising:

acquiring, by a first electronic device (100), capability information of one or more first data driven model associated with the first electronic device (100);

receiving, by the first electronic device (100), a message comprising capability information of one or more second data driven model associated with a second electronic device (200), wherein the first electronic device (100) and the second electronic device (200) are in a communication session;

identifying, by the first electronic device (100), a common data driven model capability between the capability information of the one or more first data driven model and the capability information of the one or more second data driven model; and

storing, by the first electronic device (100), the common data driven model capability in the first electronic device (100) on identifying the common data driven model capability.
The method as claimed in claim 1, wherein the capability information of the one or more first data driven model comprises at least one of an artificial intelligence (AI) model name, a machine learning (ML) model name, a version of the AI model, a version of the ML model, and a feature supported by the AI model and a feature supported by the ML Model, wherein the capability information of the one or more second data driven model comprises at least one of an AI model name, a ML model name, a version of the AI model, a version of the ML model, and a feature supported by the AI model and a feature supported by the ML Model.
The method as claimed in claim 1, wherein the method further comprises:

configuring, by the first electronic device (100), the common data driven model capability in the first electronic device (100);

determining, by the first electronic device (100), whether the configured common data driven model capability meets a predefined condition; and

performing, by the first electronic device (100), at least one of:

enabling the configured common data driven model capability upon determining the configured common data driven model capability meets the predefined condition, or

disabling the configured common data driven model capability upon determining the configured common data driven model capability does not meet the predefined condition.
The method as claimed in claim 3, wherein the method further comprises:

determining, by the first electronic device (100), a change in the predefined condition; and

reconfiguring, by the first electronic device (100), a common data driven model capability based on the change in the predefined condition.
The method as claimed in claim 3, wherein the predefined condition is determined based on a parameter, wherein the parameter comprises at least one of a condition of the first electronic device (100), a condition of the second electronic device (200), a condition of a network, a type of the network, a temperature associated with the first electronic device (100), a temperature associated with the second electronic device (200), a packet loss, Jitter, a delay in communication, a resolution of a content, a speed of transmission of the content, an ambient condition associated with the first electronic device (100), or an ambient condition associated with the second electronic device (200).
The method as claimed in claim 1, wherein the message comprises at least one of a Real-Time Transport Control Protocol (RTCP) Source Description (SDES) message, a RTCP-application message, a Real-time Transport Protocol (RTP) extension header, a RTCP message, a Session Initiation Protocol (SIP) information message, a Session Initiation Protocol-eXtensible Markup Language (SIP-XML) message and a Session Initiation Protocol-Session Description Protocol (SIP-SDP) message.
The method as claimed in claim 2, wherein the feature supported by the ML model comprises at least one of an up-scaling feature, a downscaling feature, an up-sampling feature, a down-sampling feature, a smoothening feature, a content recovering feature, a content modification feature, a quality enhancement feature, a loss recovering feature, an encryption feature, a decryption feature, an indoor feature and an outdoor feature, wherein the feature supported by the AI model comprises at least one of an up-scaling feature, a downscaling feature, an up-sampling feature, a down-sampling feature, a smoothening feature, a content recovering feature, a content modification feature, a quality enhancement feature, a loss recovering feature, an encryption feature, a decryption feature, an indoor feature or an outdoor feature.
The method as claimed in claim 1, wherein the method further comprises disabling, by the first electronic device (100), a data driven model capability in the first electronic device (100) on not identifying the common data driven model capability.
The method as claimed in claim 1, wherein the data driven model comprises at least one of a linear regression model, a logistic regression model, a linear discriminant analysis model, a decision trees model, a Naive Bayes model, a K-Nearest neighbors model, a learning vector quantization model, a support vector machine, a bagging and random forest model, a deep neural network, an unsupervised learning model, and a supervised learning model.
A first electronic device (100) for handling a data driven model in a wireless communication network (1000), the first electronic device comprising:

a processor (140);

a memory (130); and

a data driven model capability handling controller (110), coupled with the processor (140) and the memory (130), configured to:

acquire capability information of one or more first data driven model associated with the first electronic device (100),

receive a message comprising capability information of one or more second data driven model associated with the second electronic device (200), wherein the first electronic device (100) and the second electronic device (200) are in a communication session,

identify a common data driven model capability between the capability information of the one or more first data driven model and the capability information of the one or more second data driven model, and

store the common data driven model capability in the first electronic device (100) on identifying the common data driven model capability.
The first electronic device (100) as claimed in claim 10, wherein the capability information of the one or more first data driven model comprises at least one of an artificial intelligence (AI) model name, a machine learning (ML) model name, a version of the AI model, a version of the ML model, and a feature supported by the AI model and a feature supported by a ML model, wherein the capability information of the one or more second data driven model comprises at least one of an AI model name, a ML model name, a version of the AI model, a version of the ML model, and a feature supported by AI model and a feature supported by a ML model, and wherein the feature supported by the ML model comprises at least one of an up-scaling feature, a downscaling feature, an up-sampling feature, a down-sampling feature, a smoothening feature, a content recovering feature, a content modification feature, a quality enhancement feature, a loss recovering feature, an encryption feature, a decryption feature, an indoor feature and an outdoor feature, wherein the feature supported by the AI model comprises at least one of an up-scaling feature, a downscaling feature, an up-sampling feature, a down-sampling feature, a smoothening feature, a content recovering feature, a content modification feature, a quality enhancement feature, a loss recovering feature, an encryption feature, a decryption feature, an indoor feature and an outdoor feature.
The first electronic device (100) as claimed in claim 10, wherein the data driven model capability handling controller (110) is configured to:

configure the common data driven model capability in the first electronic device (100);

determine whether the configured common data driven model capability meets a predefined condition; and

perform at least one of:

enable the configured common data driven model capability upon determining the configured common data driven model capability meets the predefined condition, or

disable the configured common data driven model capability upon determining the configured common data driven model capability does not meet the predefined condition,

wherein the predefined condition is determined based on a parameter, wherein the parameter comprises at least one of a condition of the first electronic device (100), a condition of the second electronic device (200), a condition of a network, a type of the network, a temperature associated with the first electronic device (100), a temperature associated with the second electronic device (200), a packet loss, jitter, a delay in communication, a resolution of a content, a speed of transmission of the content, an ambient condition associated with the first electronic device (100), or an ambient condition associated with the second electronic device (200).
The first electronic device (100) as claimed in claim 12, wherein the data driven model capability handling controller (110) is configured to:

determine a change in the predefined condition; and

reconfigure a common data driven model capability based on the change in the predefined condition.
The first electronic device (100) as claimed in claim 12, wherein the data driven model capability handling controller (110) is configured to disable a data driven model capability in the first electronic device (100) on not identifying the common data driven model capability.
A method for handling a data driven model in a wireless communication network (1000), the method comprising:

creating, by a first electronic device (100) and a second electronic device (200), a string information based on at least one of available AI model, a ML model in the first electronic device (100) and the second electronic device (200), a device condition, and network condition;

appending, by the first electronic device (100) and the second electronic device (200), the string information to a Real-Time Transport Control Protocol (RTCP) Source Description (SDES) message;

sending, by the first electronic device (100) and the second electronic device (200), the RTCP SDES message to at least one of a server (300) and the wireless communication network (1000); and

performing, by the first electronic device (100) and the second electronic device (200), one of: enabling at least one of the AI model and the ML model based on at least one of the device condition and the network condition, disabling at least one of the AI model and the ML model based on at least one of the device condition and the network condition, and reconfiguring at least one of the AI model and the ML model based on at least one of the device condition or the network condition.