Electronic device and method for wireless communication, and computer-readable storage medium

Abstract

The present application relates to an electronic device and a method for wireless communication, and a computer-readable storage medium. The electronic device for wireless communication comprises at least one processor and at least one memory. The at least one memory comprises computer program code. The at least one memory and the computer program code are configured to, via the at least one processor, cause the electronic device to perform the following: for a task model on a user equipment side and used to implement a task, on the basis of channel conditions of the user equipment and / or capability information representing a capability of the user equipment, indicating a monitoring format to be used by the user equipment for monitoring the task model.

Description

Electronic device and method for wireless communication, computer readable storage medium This application claims priority to the Chinese patent application No. 202411285689.7, filed on September 12, 2024, and entitled "Electronic device and method for wireless communication, computer readable storage medium", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of wireless communication, in particular to an electronic device and method for wireless communication. More particularly, the present disclosure relates to an electronic device and method for wireless communication using a task model as an AI model. BACKGROUND

[0002] Considering the powerful adaptive-nonlinear fitting capability of artificial intelligence (AI) and machine learning (ML), the organic combination of AI or ML with wireless communication has become one of the key directions of 6G. For example, compared with the traditional model-driven method, AI based on data-driven has two significant advantages in application to wireless communication. On the one hand, AI can adaptively learn the high-dimensional features of the wireless environment from a large amount of data without explicit prior knowledge of the wireless environment. On the other hand, AI has a large number of learnable parameters and a large number of nonlinear activation layers, which can effectively model complex nonlinear relationships. Based on this, 3GPP has carried out standardization discussions on using AI to assist wireless communication for three typical NR (New Radio) functions, namely CSI feedback, beam management, and user positioning.

[0003] The purpose of monitoring the AI or ML model is to determine whether the accuracy of the model meets the current needs. How to more effectively monitor the AI or ML model is a hot research topic. In addition, how to more effectively construct the AI or ML model is also a hot research topic. SUMMARY

[0004] A brief summary of the application is presented in the following to provide a basic understanding of some aspects of the application. It should be understood that this summary is not an exhaustive overview of the application. It is not intended to identify key or important parts of the application nor is it intended to limit the scope of the application. Its purpose is merely to present some concepts in a simplified form as a prelude to the more detailed description of a later discussion.

[0005] According to an aspect of the present disclosure, an electronic device for wireless communication is provided, comprising: at least one processor; and at least one memory including computer program codes, wherein the at least one memory and the computer program codes are configured to, with the at least one processor, cause the electronic device to perform: indicating, for a task model on a user equipment side for implementing a task, a monitoring format to be adopted by the user equipment for monitoring the task model based on a channel condition in which the user equipment is located and / or capability information representing a capability of the user equipment.

[0006] According to an aspect of the present disclosure, an electronic device for wireless communication is provided, comprising: at least one processor; and at least one memory including computer program codes, wherein the at least one memory and the computer program codes are configured to, with the at least one processor, cause the electronic device to perform: receiving, for a task model on a user equipment side for implementing a task, an indication from a network side device about a monitoring format to be adopted for monitoring the task model, wherein the monitoring format is determined by the network side device based on a channel condition in which the user equipment is located and / or capability information representing a capability of the user equipment.

[0007] According to an aspect of the present disclosure, an electronic device for wireless communication is provided, comprising: at least one processor; and at least one memory including computer program codes, wherein the at least one memory and the computer program codes are configured to, with the at least one processor, cause the electronic device to perform: implementing a plurality of tasks simultaneously through a plurality of task models, wherein the plurality of task models comprise a shared parameter model shared by the plurality of tasks and model branches respectively corresponding to at least part of the plurality of tasks.

[0008] According to an aspect of the present disclosure, a method for wireless communication is provided, comprising: indicating, for a task model on a user equipment side for implementing a task, a monitoring format to be adopted by the user equipment for monitoring the task model based on a channel condition in which the user equipment is located and / or capability information representing a capability of the user equipment.

[0009] According to an aspect of the present disclosure, a method for wireless communication is provided, comprising: receiving, for a task model on a user equipment side for implementing a task, an indication from a network side device about a monitoring format to be adopted for monitoring the task model, wherein the monitoring format is determined by the network side device based on a channel condition in which the user equipment is located and / or capability information representing a capability of the user equipment.

[0010] According to an aspect of the present disclosure, a method for wireless communication is provided, comprising: implementing a plurality of tasks simultaneously by a multi-task model, wherein the multi-task model comprises a shared parameter model shared by the plurality of tasks and model branches respectively corresponding to at least part of the plurality of tasks.

[0011] According to other aspects of the present disclosure, there are also provided computer program codes and computer program products for implementing the above method, and a computer readable storage medium having the computer program codes recorded thereon. BRIEF DESCRIPTION OF DRAWINGS

[0012] To further illustrate and describe the above and other advantages and features of the present application, a further specific description of the application is described below with reference to the accompanying drawings. The accompanying drawings form a part of the specification. Elements having the same function and structure are designated with the same reference numerals throughout. It is to be understood that these drawings are only typical examples of the present application and should not be viewed as limiting the scope of the present application. In the drawings:

[0013] FIG. 1 shows an exemplary functional module block diagram of an electronic device for wireless communication according to one embodiment of the present disclosure;

[0014] FIG. 2 is a diagram showing an example of time domain beam prediction;

[0015] FIG. 3 shows a diagram of an example of beam prediction in a first monitoring format according to an embodiment of the present disclosure;

[0016] FIG. 4 shows a diagram of an example of beam prediction in a second monitoring format according to an embodiment of the present disclosure;

[0017] FIG. 5 shows a diagram of an example of multiplexing historical measurement data in inference of a model according to an embodiment of the present disclosure;

[0018] FIG. 6 shows a diagram of an example of signaling procedure in inference of a beam prediction model in a case of stable model performance according to an embodiment of the present disclosure;

[0019] FIG. 7 shows a diagram of an example of signaling procedure in inference of a beam prediction model in a case of model prediction failure according to an embodiment of the present disclosure;

[0020] FIG. 8 shows an exemplary functional module block diagram of an electronic device for wireless communication according to another embodiment of the present disclosure;

[0021] FIG. 9 shows an exemplary functional module block diagram of an electronic device for wireless communication according to yet another embodiment of the present disclosure;

[0022] FIG. 10 is a diagram illustrating an example framework of a multi-task model according to an embodiment of the present disclosure;

[0023] FIG. 11 is a first example flow of model certification for multi-task learning according to an embodiment of the present disclosure;

[0024] FIG. 12 is an example of a task list according to an embodiment of the present disclosure;

[0025] FIG. 13 is an example of a dataset list according to an embodiment of the present disclosure;

[0026] FIG. 14 is an example flow of model activation / deactivation for multi-task learning according to an embodiment of the present disclosure;

[0027] FIG. 15 is a first example flow of model detection and model update for multi-task learning according to an embodiment of the present disclosure;

[0028] FIG. 16 is a second example flow of model detection and model update for multi-task learning according to an embodiment of the present disclosure;

[0029] FIG. 17 is a third example flow of model detection and model update for multi-task learning according to an embodiment of the present disclosure;

[0030] FIG. 18 is a flow of multi-task multi-base station cooperation according to an embodiment of the present disclosure;

[0031] FIG. 19 illustrates an example flow of model training and model distribution of a multi-task dual-end model according to an embodiment of the present disclosure;

[0032] FIG. 20 illustrates an example flow of model inference of a multi-task dual-end model according to an embodiment of the present disclosure;

[0033] FIG. 21 is a diagram showing a comparison of a multi-task model and a single-task model dedicated to beam prediction in terms of beam prediction accuracy;

[0034] FIG. 22 is a diagram showing a comparison of a multi-task model and a single-task model dedicated to positioning in terms of average positioning error;

[0035] FIG. 23 illustrates a flowchart of a method for wireless communication according to one embodiment of the present disclosure;

[0036] FIG. 24 illustrates a flowchart of a method for wireless communication according to another embodiment of the present disclosure;

[0037] FIG. 25 illustrates a flowchart of a method for wireless communication according to yet another embodiment of the present disclosure;

[0038] FIG. 26 is a block diagram illustrating a first example of a schematic configuration of an eNB or gNB to which the technology of the present disclosure can be applied;

[0039] FIG. 27 is a block diagram illustrating a second example of a schematic configuration of an eNB or gNB to which the technology of the present disclosure is applicable;

[0040] FIG. 28 is a block diagram illustrating an example of a schematic configuration of a smartphone to which the technology of the present disclosure is applicable;

[0041] FIG. 29 is a block diagram illustrating an example of a schematic configuration of a car navigation device to which the technology of the present disclosure is applicable; and

[0042] FIG. 30 is a block diagram of an example of an exemplary structure of a general-purpose personal computer in which a method and / or apparatus and / or system according to an embodiment of the present application can be implemented. DETAILED DESCRIPTION

[0043] In the following, exemplary embodiments of the present application will be described with reference to the accompanying drawings. In the description, all features that are not described in detail of actual embodiments have not been described in the specification for the sake of clarity and conciseness. It should be appreciated, however, that numerous specific details are set forth in order to provide a thorough understanding of the present application. These details are merely exemplary as it is contemplated that one of ordinary skill in the art, to which the present application pertains, can alter the implementations of the present application described while still being within the scope of the present application. In other instances, well-known structures are not shown or described in order to avoid obscuring aspects of the present application.

[0044] It is also to be noted that, in this application, reference to an apparatus or a process should not be construed as a reference to a particular device or structure having only a single function. For example, the use of a processor or a controller in the description should not be construed to limit the processor or the controller to only a single function.

[0045] The present disclosure provides an electronic device for wireless according to one embodiment of the present disclosure. The electronic device includes at least one processor and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: indicating, for a task model for a user equipment side to implement a task, a monitoring format to be employed by the user equipment to monitor the task model based on a channel condition in which the user equipment is located and / or capability information representing a capability of the user equipment.

[0046] FIG. 1 illustrates an example functional block diagram of an electronic device 100 for wireless communication according to one embodiment of the present disclosure.

[0047] As shown in FIG. 1, the electronic device 100 includes a control unit 101 which performs control, and a processing unit 103 which can be configured to instruct, under control of the control unit 101, a monitoring format to be adopted by a user device for monitoring a task model for implementing a task of the user device, based on a channel condition in which the user device is located and / or capability information representing a capability of the user device.

[0048] The control unit 101 and the processing unit 103 can be implemented as one or more processing circuits, for example, a processor or a chip, and at least one memory, for example, a RAM, a ROM, etc., which can be used to store computer program codes and data required by the processing circuit for processing, etc. It should be understood that the various functional units in the electronic device 100 shown in FIG. 1 are only logical modules divided according to the specific functions they implement, and are not intended to limit the specific implementation manner.

[0049] The electronic device 100 can be disposed at a base station side or communicatively connected to a base station, for example. For example, the electronic device 100 can work as the base station itself, and can further include external devices such as a memory, a transceiver (not shown), etc. The memory can be used to store programs and related data information required by the electronic device 100 to implement various functions. The transceiver can include one or more communication interfaces to support communication with different devices (e.g., UEs, base stations, etc.), and the implementation form of the transceiver is not specifically limited here.

[0050] As an example, the base station can be an eNB or a gNB, for example. Hereinafter, the base station is generally described by taking the gNB as an example.

[0051] The electronic device 100 according to the embodiments of the present disclosure can instruct different monitoring formats to be adopted by the user device for monitoring the task model according to different situations. For example, the electronic device 100 can instruct the monitoring format based on the channel condition in which the user device is located and / or the capability information representing the capability of the user device.

[0052] As an example, the channel condition includes channel state information (CSI). For example, the channel condition can be characterized by measurement results (e.g., L1-RSRP and / or reference signal (RS) index) of a resource set for monitoring. Other examples of the channel condition can also be conceived by those skilled in the art, which are not listed here.

[0053] As an example, the capability information includes capability of the AI model carried by the user equipment (e.g., applicable input beam cases, beam width, beam quantity, beam index, etc.), and / or capability of the user itself (e.g., antenna capability, beam measurement accuracy, i.e., the accuracy and quantity of beams that can be measured, i.e., the maximum number of beams that can be measured, etc.). Other examples of the capability information can also be conceived by those skilled in the art, which are not listed here.

[0054] As an example, the task includes predicting a beam, and the task model includes a beam prediction model for predicting the beam. Other examples of the task model can also be conceived by those skilled in the art, which are not listed here. For ease of description, in the following, the task model is taken as the beam prediction model for illustration, and sometimes the task model is simply referred to as the model or the AI model, and those skilled in the art can understand that the task model can also be an ML model.

[0055] For the beam prediction model, the purpose of the model monitoring is to determine whether the prediction accuracy of the model meets the current transmission requirements.

[0056] After the model monitoring mechanism is triggered, the UE is allocated resources for measurement. In an embodiment according to the present disclosure, after the model monitoring mechanism is started, the prediction accuracy of the model is calculated by comparing the prediction result based on the AI model and the measurement result of the non-AI model, thereby achieving the purpose of monitoring. In order to avoid the occurrence of "ping-pong" effect, the prediction accuracy of the model is evaluated multiple times to determine the performance of the model in a certain scenario.

[0057] FIG. 2 is a diagram illustrating an example of time-domain beam prediction.

[0058] In time-domain beam prediction, the beams in a certain period of history are measured as the input of the model to predict the optimal beams corresponding to the future time (e.g., future slots). For example: as shown in FIG. 2, slots 1 to 5 are included in the historical time window, the beams in the time window are measured, and the measurement results are input to the model, and the model will predict the optimal candidate beams corresponding to future slots 6 to 9.

[0059] As an example, the monitoring format is a first monitoring format or a second monitoring format, wherein in the first monitoring format, multiple monitoring is performed by multiplexing at least part of the historical measurement information for the task, and in the second monitoring format, for multiple monitoring, the measurement information for the task used for each monitoring does not overlap. Monitoring in the first monitoring format can save measurement overhead and latency. Monitoring in the second monitoring format can achieve a wider span in the time domain, which means that more corresponding data in the channel environment can be obtained, so that the evaluation of the model performance will be more accurate.

[0060] For example, the first monitoring format refers to multiplexing historical measurement information on the part of each monitoring, and the second monitoring format refers to using historical measurement information that does not overlap each time.

[0061] For example, when the measurement beams corresponding to each time are different (for example, the beams measured on the slot 1 correspond to indexes 1, 2, 3, but the beams measured on the slot 2 correspond to indexes 8, 9, 10, and so on, and the beams measured each time are different), it is not possible to multiplex historical measurement data, and only the second monitoring format can be selected, otherwise the first monitoring format can be selected.

[0062] As an example, the processing unit 103 can be configured to indicate the first monitoring format to the user equipment in a case where it is determined based on the channel condition that the channel is a slow fading channel, and indicate the second monitoring format to the user equipment in a case where it is determined based on the channel condition that the channel is a fast fading channel.

[0063] For example, the channel condition can refer to the time-varying characteristics of the channel. If the channel is relatively flat in the time domain, the first monitoring format can be selected. If the channel is fast in the time domain, more channel environment features need to be monitored, and the second monitoring format can be selected.

[0064] For example, when the channel is in a relatively flat state, the main reason affecting the performance of the model is not the change of the channel environment, and the first monitoring format can be selected to evaluate the prediction performance of the model; by multiplexing part of the historical measurement data, the model can be used to implement multiple predictions, and in a relatively flat channel environment, the model can save measurement and time delay overheads in the monitoring stage. When the performance of the model in more channel environments needs to be evaluated, the second monitoring format can be used.

[0065] As an example, the processing unit 103 can be configured to indicate the first monitoring format to the user equipment in a case where the capability information meets a predetermined condition, and indicate the second monitoring format to the user equipment in a case where the capability information does not meet the predetermined condition.

[0066] For example, the predetermined condition can be determined in advance by a person skilled in the art according to application scenarios or experience.

[0067] For example, the predetermined condition includes that the maximum number of beams that can be measured by the user equipment is less than the number of beams that need to be measured each time for prediction, and / or the accuracy of the beams that can be measured by the user equipment is less than the required measurement beam accuracy for each prediction.

[0068] For example, the first monitoring format is indicated to the user equipment when the maximum number of beams the user equipment is able to measure is less than the number of beams required to be measured for each prediction, and the second monitoring format is indicated to the user equipment when the maximum number of beams the user equipment is able to measure is greater than or equal to the number of beams required to be measured for each prediction. For example, the first monitoring format is indicated to the user equipment when the accuracy of beams the user equipment is able to measure is less than the accuracy of beams required to be measured for each prediction, and the second monitoring format is indicated to the user equipment when the accuracy of beams the user equipment is able to measure is greater than or equal to the accuracy of beams required to be measured for each prediction.

[0069] The above describes examples of determining the monitoring format according to the channel condition and determining the monitoring format according to the capability information respectively, and the monitoring format can also be determined according to both the channel condition and the capability information together. For example, the processing unit 103 can be configured to indicate the first monitoring format to the user equipment in the case that the channel is determined to be a slow fading channel based on the channel condition and the capability information satisfies a predetermined condition, and indicate the second monitoring format to the user equipment in the case that the channel is determined to be a fast fading channel based on the channel condition and the capability information does not satisfy the predetermined condition.

[0070] FIG. 3 shows a diagram of an example of beam prediction with the first monitoring format according to an embodiment of the present disclosure. In FIG. 3, slot 1 to slot 12 are exemplified.

[0071] As shown in FIG. 3, for time-domain beam prediction, the input time window of the model in multiple predictions overlaps. For ease of description, it is assumed that the beams measured at each measurement time in the time window of historical data measurement are the same (for example, the beams measured in slot 1 correspond to indexes 1, 2, and 3, and the beams measured in slots 2 to 5 also correspond to indexes 1, 2, and 3), and the historical measurement data is multiplexed for multiple monitoring. For example, beams are measured at the time corresponding to slots 1 to 5, the measurement structure is taken as the input of the model to complete the first prediction of the model. In the second prediction of the model, the network side device (for example, a base station) only needs to allocate resources required for measuring beams corresponding to slot 6 to the UE, and the measurement results obtained by measuring beams in slots 2 to 6 are taken as the input of the model to complete the second prediction. In this way, the network side device only needs to allocate measurement resources corresponding to part of the reference signals to the UE each time, and the measurement results of the other part are multiplexed from the previous time. If Set A (the full set containing all possible beams) in BM-Case2 in the 3GPP discussion is equal to Set B (the set of measurement beams used for model input), the prediction results of the AI model and the measurement results of the non-AI model can be directly compared in the time window in which the model output and the input repeat. For example, in a certain prediction, the output of the model is the beam prediction result for slot 11 (which is the prediction result of the AI model), and in other predictions, the beam measurement result for slot 11 is taken as the input of the model (which is the measurement result of the non-AI model) to predict the optimal beam for the future time slot. The prediction accuracy of the model can be calculated by comparing the beam prediction result for slot 11 and the beam measurement result for slot 11, thereby achieving the purpose of monitoring. Those skilled in the art can understand that the prediction accuracy of the model can also be calculated by comparing the beam prediction results for multiple time points and the beam measurement results for the multiple time points.

[0072] FIG. 4 shows a diagram of an example of beam prediction in a second monitoring format according to an embodiment of the present disclosure. In FIG. 4, slots 1 to 14 are illustrated. In this case, each measurement is separate, as shown in FIG. 4, beams at times of slots 1 to 5 are measured, and the obtained measurement results are taken as the input of the first beam prediction of the model. Then, beams corresponding to times of slots 6 to 10 are measured, and the obtained measurement results are taken as the input of the second beam prediction of the model. In this way, in each prediction, the measurement result of each time cannot be multiplexed, that is, each measurement is independent in multiple predictions of the model. Even so, if Set A is equal to Set B in the time window in which the model output and the input repeat, the prediction result based on AI and the measurement result of non-AI can be directly compared.

[0073] As an example, the processing unit 103 can be configured to, in a case where the first monitoring format is indicated to the user equipment, indicate time domain information of at least a part of the multiplexed historical measurement information in the time domain, wherein the time domain information comprises a starting point of the at least a part of the multiplexed historical measurement information in the time domain and a length of the at least a part of the multiplexed historical measurement information in the time domain. The time domain information can further comprise a measurement information interval at each prediction time.

[0074] When the network side device indicates the monitoring format of the UE, the following information can be included: index of the monitoring format, allocated reference signal and corresponding time-frequency resource.

[0075] For the model on the UE side, after the model monitoring mechanism is started, the network side device needs to indicate the index corresponding to the monitoring format of the UE. In the format 1 (i.e. the first monitoring format, which can multiplex historical measurement data), the following information should be included: the above-mentioned time domain information (e.g. time domain interval of each measurement (or length of historical data multiplexed in the time domain each time)), measurement resource configuration carrying the reference signal. The format 2 (i.e. the second monitoring format, each beam measurement in the time domain is independent) should include: measurement resource configuration carrying the reference signal. If the network side device does not know the time window length of the input and output of the model on the UE side, the monitoring format information mentioned above should also include the length of the time window occupied by the input and output of the model in the time domain.

[0076] As an example, multiple beam predictions are performed using the beam prediction model to perform multiple monitoring of the prediction accuracy of the beam prediction model, so as to improve the prediction accuracy of the future candidate beam by the beam prediction model.

[0077] As an example, the user equipment performs the task model N times by multiplexing part of the historical measurement information for the task to obtain N execution results, and judges the stability of the task model based on the execution results, so as to perform inference on the task model, wherein N is a positive integer greater than 1. By multiplexing part of the historical measurement information for the task to perform inference, there is no great overhead in measurement overhead and time delay.

[0078] In NR, in order to ensure the reliability of data transmission, one technical means is retransmission, which refers to transmitting the same information multiple times to increase the decoding performance of the receiving end. For time domain beam prediction, the inference of the model can also use the retransmission means to increase the reliability of the prediction result, and the performance of the retransmission here should be multiple predictions of the model. Influenced by the time domain channel characteristics, the time window length of the historical data collected in each inference of the model is fixed. Of course, the historical data time window lengths corresponding to adjacent two inferences can be the same or different, but in multiple inferences, the time window of the collected data can overlap.

[0079] FIG. 5 shows a diagram of an example of reusing historical measurement data in inference of a model according to embodiments of the present disclosure. In FIG. 5, slot 1 to slot 12 are exemplified. For example, considering the time-varying characteristics of a channel, to ensure the reliability of the prediction result, the model can be allowed to make multiple predictions to enhance the reliability of the prediction result of the model. For example, in FIG. 5, N times of beam prediction can be performed by reusing at least part of the historical measurement information (for example, reusing at least part of the beam measurement result of the time slot before slot 11) to obtain N times of beam prediction results for slot 11, and then the stability of the beam prediction model is determined by comparing the N times of beam prediction results for slot 11, so as to perform inference on the beam prediction model. As such repeated measurement in FIG. 5, part of the last measurement result is reused, so there is no great overhead in measurement overhead and time delay.

[0080] As an example, the processing unit 103 can be configured to, in a case where the result of the inference indicates that the stability of the task model is less than a predetermined stability threshold, receive a report of an event reflecting that the stability is less than the predetermined stability threshold from the user equipment, and determine whether to trigger monitoring of the task model based on the event.

[0081] The monitoring of the model can be one or more of periodic, aperiodic, and semi-static. For example, the periodic can be configured in radio resource control (RRC) signaling. For example, as described above, whether to trigger the monitoring of the task model can be determined based on the event.

[0082] As an example, the processing unit 103 can be configured to specify a predetermined number of times for the user equipment to execute the task model in the inference, wherein the predetermined number of times is greater than or equal to N.

[0083] For example, the predetermined number of times can be configured by the network side device, and the basis for the configuration can be, for example, an estimate and observation of the channel obtained by the network side device. Taking the beam prediction model of the UE side as an example, the network side device indicates the number of times of repeated prediction (the number of times of repeated measurement) and the time interval of each prediction (the time interval of each measurement) to the UE. In addition, the network side device can configure corresponding measurement resources to the UE. Of course, the number of times of repeated measurement can also be a non-fixed value, for example, the network side device configures a value for the number of times of repeated measurement of the model, and when it is found that the prediction result is relatively stable after multiple predictions, it can actively report the termination of the prediction. That is, after the network side device configures the predetermined number of times of execution of the prediction to the UE, if the UE judges that the model performance is stable, it can report the termination of the prediction before the predetermined number of times configured by the network side device is executed.

[0084] The relatively stable prediction result can refer to a very small difference between multiple prediction results for the same time in the future, and the quality of the communication link can still be ensured in the communication process using the predicted beam. However, for the same time in the future, the prediction result each time is very different, which proves that the performance of the model has a problem, and the possible reason is that the model cannot be applied to the current variable channel environment, or it can also be that the training data is unbalanced in the training process of the model, and the diversity of the training data leads to. The size of the difference can be compared according to a predefined threshold. When the difference is less than the threshold, and the use of the predicted beam can ensure the link quality, it is considered that the prediction performance of the model is relatively stable. When the difference is greater than the threshold, it is considered that the prediction performance of the model is unstable, and it can be determined that the current prediction of the model fails. Once the difference between multiple prediction outputs is large at a certain time, the prediction result should be terminated, and the model prediction failure event is reported to the network side device, and whether the monitoring mechanism of the model is triggered is determined by the network side device through the event reported by the UE.

[0085] In an embodiment according to the present disclosure, in the inference stage, the reliability of the model output (model prediction) can be ensured by performing multiple predictions based on the model, and this reliability is obtained by observing the difference between multiple prediction results at a certain time or multiple times in the future. If the difference is small, the performance is relatively stable, and if the difference is large, it proves that the prediction of the model has an error, and this error can be caused by the time-varying of the channel. In the latter case, the UE should not report the prediction result again, but report the event to the network side device, and the network side device determines whether to trigger the monitoring mechanism of the model.

[0086] FIG. 6 shows a diagram of an example of a signaling flow in the inference of the beam prediction model in the case of stable model performance, according to an embodiment of the present disclosure.

[0087] In S61, the gNB configures the UE with a set of measurement beams, the number of repeated predictions, and the time interval for each prediction.

[0088] In S62, the UE estimates the beam prediction result by performing model inference.

[0089] In S63, when it is found that the prediction result is relatively stable after multiple predictions, the UE actively reports to the gNB to terminate repeated prediction.

[0090] In S64, the UE reports the prediction result to the gNB.

[0091] FIG. 7 shows a diagram of an example of a signaling flow in the inference of the beam prediction model in the case of model prediction failure, according to an embodiment of the present disclosure.

[0092] In S71, the gNB configures the UE with a set of measurement beams, a number of times of repeated prediction, and a time interval for each prediction.

[0093] In S72, the UE estimates the beam prediction result by performing model inference.

[0094] In S73, when it is found that the prediction result is unstable after multiple predictions, the UE reports a model inference failure event to the gNB.

[0095] In S74, the gNB triggers model monitoring based on the above event.

[0096] As an example, the task model is a multi-task model for simultaneously implementing multiple tasks, and the multi-task model includes a shared parameter model shared by the multiple tasks and a model branch corresponding to at least part of the multiple tasks respectively.

[0097] As an example, the shared parameter model extracts a shared representation shared by the multiple tasks from input data, and each model branch is used to determine a mapping from the shared representation to a label of a task corresponding to the model branch.

[0098] The description of the multi-task model can refer to the description of the multi-task model in the following embodiment of the electronic device 300, and will not be repeated here.

[0099] The present disclosure also provides an electronic device 200 for wireless communication according to another embodiment of the present disclosure. The electronic device 200 includes at least one processor and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device 200 to perform: receiving, for a task model for implementing a task on the side of the electronic device 200, an indication from a network side device about a monitoring format to be adopted for monitoring the task model, wherein the monitoring format is determined by the network side device based on channel conditions in which the electronic device 200 is located and / or capability information representing capabilities of the electronic device 200.

[0100] FIG. 8 shows an exemplary functional module block diagram of an electronic device 200 for wireless communication according to another embodiment of the present disclosure.

[0101] As shown in FIG. 8, the electronic device 200 includes a control unit 201 that controls, a processing unit 203 that, under the control of the control unit 201, receives, for a task model for implementing a task on the side of the electronic device 200, an indication from a network side device about a monitoring format to be adopted for monitoring the task model, wherein the monitoring format is determined by the network side device based on channel conditions in which the electronic device 200 is located and / or capability information representing capabilities of the electronic device 200.

[0102] The control unit 201 and the processing unit 203 can be implemented as one or more processing circuits, for example, a processor or a chip, and at least one memory, for example, a RAM, a ROM, etc., for storing computer program codes and data required by the processing circuit for processing, etc. It should be understood that the various functional units in the electronic device 200 shown in FIG. 8 are only logical modules divided according to the specific functions they implement, and are not intended to limit the specific implementation manner.

[0103] For example, the electronic device 200 can work as a user equipment itself, and can further include external devices such as a memory, a transceiver (not shown), etc. The memory can be used to store programs and related data information required by the electronic device 200 to implement various functions. The transceiver can include one or more communication interfaces to support communication with different devices (for example, a UE, a base station, etc.), and the implementation form of the transceiver is not specifically limited here.

[0104] The electronic device 200 according to the embodiments of the present disclosure can receive an indication of different monitoring formats for model monitoring determined by the network side device according to different situations. For example, the electronic device 200 can receive an indication of a monitoring format determined by the network side device based on channel conditions in which the electronic device 200 is located and / or capability information representing the capability of the electronic device 200.

[0105] As an example, the electronic device 200 can be a user equipment in the electronic device 100 embodiment, and the network side device in the electronic device 200 embodiment can be the electronic device 100.

[0106] As an example, the monitoring format is a first monitoring format or a second monitoring format, wherein in the first monitoring format, multiple monitoring is performed by multiplexing at least part of the historical measurement information for the task, and in the second monitoring format, for multiple monitoring, the measurement information for the task used for each monitoring does not overlap.

[0107] As an example, the processing unit 203 can be configured to receive an indication of the first monitoring format from the network side device in a case where the network side device determines that the channel is a slow fading channel based on the channel conditions, and receive an indication of the second monitoring format from the network side device in a case where the network side device determines that the channel is a fast fading channel based on the channel conditions.

[0108] As an example, the channel conditions can include channel state information.

[0109] As an example, the processing unit 203 can be configured to receive, from the network-side device, the indication about the first monitoring format in a case that the capability information satisfies a predetermined condition, and receive, from the network-side device, the indication about the second monitoring format in a case that the capability information does not satisfy the predetermined condition.

[0110] For details about the first monitoring format and the second monitoring format, please refer to the corresponding parts described in the embodiments of the electronic device 100 in conjunction with FIG. 3 and FIG. 4, which will not be repeated here.

[0111] As an example, the processing unit 203 can be configured to, in a case that the indication about the first monitoring format is received from the network-side device, further receive an indication about time domain information of at least part of the multiplexed historical measurement information in the time domain, wherein the time domain information comprises a starting point of at least part of the multiplexed historical measurement information in the time domain and a length of at least part of the multiplexed historical measurement information in the time domain. The time domain information can further comprise a measurement information interval at each prediction time.

[0112] As an example, the processing unit 203 can be configured to perform the task model for N times by multiplexing part of the historical measurement information for the task to obtain N execution results, and determine the stability of the task model based on the execution results to make an inference on the task model, wherein N is a positive integer greater than 1.

[0113] As an example, the processing unit 203 can be configured to, in a case that the result of the inference indicates that the stability of the task model is less than a predetermined stability threshold, report an event reflecting that the stability is less than the predetermined stability threshold to the network-side device, so that the network-side device determines whether to trigger monitoring of the task model based on the event.

[0114] As an example, the processing unit 203 can be configured to receive, from the network-side device, a predetermined number of times of executing the task model in the inference, wherein the predetermined number of times is greater than or equal to N.

[0115] For details about the inference on the model, please refer to the corresponding parts described in the embodiments of the electronic device 100 in conjunction with FIG. 6 and FIG. 7, which will not be repeated here.

[0116] As an example, the task comprises predicting a beam, and the task model comprises a beam prediction model for predicting the beam.

[0117] As an example, the beam prediction model is used for multiple times of beam prediction to perform multiple times of monitoring of prediction accuracy of the beam prediction model, so as to improve prediction accuracy of the beam prediction model on a future candidate beam.

[0118] As an example, the task model is a multi-task model for simultaneously implementing multiple tasks, and the multi-task model includes a shared parameter model sharing model parameters by the multiple tasks and model branches respectively corresponding to at least part of the multiple tasks.

[0119] As an example, the shared parameter model extracts a shared representation shared by the multiple tasks from input data, and each model branch is used to determine a mapping from the shared representation to a label of a task corresponding to the model branch.

[0120] FIG. 9 shows an exemplary functional module block diagram of an electronic device 300 for wireless communication according to yet another embodiment of the present disclosure.

[0121] As shown in FIG. 9, the electronic device 300 includes a control unit 301 that controls, and a processing unit 303 that, under the control of the control unit 301, simultaneously implements multiple tasks by a multi-task model, wherein the multi-task model includes a shared parameter model (which can also be referred to as a partial model) sharing model parameters by the multiple tasks and model branches respectively corresponding to at least part of the multiple tasks.

[0122] The control unit 301 and the processing unit 303 can be implemented as one or more processing circuits, such as a processor or a chip, and at least one memory, such as a RAM, a ROM, etc., for storing computer program codes and data required for processing performed by the processing circuit, etc. It should be understood that the various functional units in the electronic device 300 shown in FIG. 9 are only logical modules divided according to the specific functions they implement, and are not intended to limit the specific implementation manner.

[0123] The electronic device 300 can be provided at a base station side or communicatively connected to a base station, for example. For example, the electronic device 300 can work as the base station itself, and can further include external devices such as a memory, a transceiver (not shown), etc. The memory can be used to store programs and related data information required for the electronic device 300 to implement various functions. The transceiver can include one or more communication interfaces to support communication with different devices (e.g., UEs, base stations, etc.), and the implementation form of the transceiver is not specifically limited here.

[0124] As an example, the base station can be an eNB or a gNB, for example. Hereinafter, the base station is generally described by taking the gNB as an example.

[0125] For example, the electronic device 300 can work as a UE itself, and can further include external devices such as a memory, a transceiver (not shown), and the like. The memory can be used to store programs and related data information required for the electronic device 300 to implement various functions. The transceiver can include one or more communication interfaces to support communication with different devices (e.g., UEs, base stations, and the like), and the implementation form of the transceiver is not specifically limited here.

[0126] Hereinafter, unless specifically stated, the electronic device 300 can be one of a gNB and a UE on which a multi-task model is deployed.

[0127] In the prior art, one AI model is dedicated to implementing one task (function). Such a model is referred to as a single-task model. In actual scenarios, a gNB and a UE usually need to support the implementation of multiple tasks. Mathematically, let x be the input data, T be the number of tasks, and y t , then implementing multiple tasks using single-task learning can be expressed as:

[0128]

[0129] where f t (·) is a single-task model corresponding to task t. is the prediction of the single-task model for task t. According to the prediction of task t and the label y t , the loss of task t is calculated, thereby completing the training of the single-task model f t (·).

[0130] Further, since the deployment and management of AI models in a wireless communication system require information exchange between nodes (gNB or UE), 3GPP discusses the life cycle management of single-task models. Specifically, the life cycle management includes but is not limited to the following stages: (1) model authentication, to ensure that the gNB and the UE have a common understanding of the AI model. The common understanding includes but is not limited to task confirmation, UE capability confirmation, and model information confirmation; (2) activating / deactivating / switching models, to select a model that meets the requirements from multiple AI models; (3) model performance monitoring and model updating, to ensure the task performance of the model in a complex and variable wireless environment.

[0131] The method of AI-assisted wireless communication brings significant performance gain, and can apply AI models to actual wireless communication systems through life cycle management. However, since a gNB and a UE usually need to support the implementation of multiple tasks, the model and life cycle management oriented to single-task learning have the following problems:

[0132] (1) A single-task label can only reflect a one-sided physical feature of a wireless environment. For example, an optimal beam label can only reflect the angular feature of multipath transmission. Therefore, a single-task model trained using a single-task label is prone to overfitting.

[0133] (2) Life cycle management for single-task learning manages each task separately, which brings a large overall signaling overhead when different tasks need to be coordinated.

[0134] (3) It is difficult to determine whether the performance degradation of a task is caused by input data quality problems, auxiliary data quality problems, or model and scene mismatch, which brings a large model update overhead.

[0135] (4) In single-task multi-base station cooperation, different gNBs are required to have the same type of input data and the same type of task label data. However, since the capabilities of different gNBs in actual scenarios are usually different, they may not be able to support the acquisition of the same type of input data and the same type of task label data, thereby bringing challenges to single-task multi-base station cooperation.

[0136] (5) In dual-end model deployment, single-task learning requires a UE-end or gNB-end model to be distributed for each task and a specific code word to be fed back, which brings a large model distribution overhead and feedback overhead.

[0137] To solve the above problems of the model, the present application proposes to use an AI model to implement multiple tasks at the same time. Such a model is called a multi-task model.

[0138] FIG. 10 is a diagram illustrating an example framework of a multi-task model according to an embodiment of the present disclosure.

[0139] As shown in FIG. 10, taking an example in which multiple tasks include three tasks (task 1, task 2, and task 3), the multi-task model includes a shared parameter model in which the three tasks share model parameters and model branches corresponding to task 1, task 2, and task 3, respectively, for example, which can implement prediction of task 1 to task 3.

[0140] As an example, the shared parameter model extracts a shared representation shared by multiple tasks from input data, and each model branch is used to determine a mapping from the shared representation to a label of a task corresponding to the model branch.

[0141] Mathematically, the implementation of multiple tasks by a multi-task model can be expressed as:

[0142]

[0143] where g(·) is a shared parameter model of T task-shared model parameters. c is a representation of T task-shared extracted from input data x by the encoder (g(·)). Further, a task t-specific model branch g t learns a mapping of c to task t label y t . The loss of T tasks is calculated by the predictions and labels {y1, y2, …, y T} of T tasks by the multi-task model, and the training of the multi-task model is implemented by using the loss. Under the supervision of multiple task labels, the shared parameter model of shared model parameters can extract different labels reflecting the physical characteristics of the wireless environment from the input data, thereby improving the generalization performance of the multi-task model.

[0144] To solve the above-mentioned life cycle management problems and manage the life cycle of the multi-task model, the present application proposes a life cycle management process for multi-task learning. Specifically, first, in the model authentication stage, the tasks in the group use unified input data and uniformly perform model authentication. Second, the tasks in the group in the multi-task model are uniformly managed, without the need for additional signaling to coordinate the tasks in the group. Third, the multiple tasks in the same multi-task model can supervise each other, assisting in determining the cause of the performance degradation of the task. Fourth, in multi-task multi-base station cooperation, different base stations are allowed to have different types of input data and different sets of tasks. Fifth, in the deployment of the double-end model, only the shared parameter model of the shared model parameters of the tasks in the group needs to be distributed to the UE end or the gNB end, reducing the model distribution overhead. In the inference of the double-end model, only a code word shared by the tasks in the group needs to be fed back, reducing the feedback overhead.

[0145] In the following, from the perspective of comparison between single-task learning and multi-task learning, each stage of the life cycle management of the AI model will be described in detail. Before that, first, two concepts are defined:

[0146] Input data: data directly input to the AI model.

[0147] Auxiliary data: data not input to the AI model. For example, UE positioning usually predicts the position relative to the gNB, so the absolute position of the gNB is needed when inferring the absolute position of the UE. In this process, the position of the gNB is not input to the AI model, so the position of the gNB is auxiliary data.

[0148] As an example, the tasks are grouped based on the correlation between the tasks, wherein each task in the group is implemented via a corresponding multi-task model, wherein the correlation is obtained based on at least one of prior information of the correlation between the tasks, coordination information between the tasks, and matching degree between the tasks.

[0149] Training multiple tasks with weak correlation using multi-task learning method will instead harm performance. Therefore, in this application, all tasks confirmed by the node are grouped according to the correlation between tasks. The tasks in each group are implemented through the corresponding multi-task model. After completing the task grouping, the multi-task model deployment and life cycle management are performed by group. That is, tasks with strong correlation are grouped, and multi-task model deployment and life cycle management are performed by group.

[0150] The node usually needs to support the implementation of multiple tasks. The existing model deployment and life cycle management are for a single task, and there are three deficiencies: (1) the correlation between tasks is not utilized, and the performance of each task still has a large room for improvement; (2) when different tasks need to be coordinated, a large signaling overhead is brought; (3) it is difficult to determine the cause of the performance decline of the task, and a large model update overhead is brought.

[0151] According to the multi-task learning for wireless communication of the embodiments of the present disclosure, all tasks in the group are faced, and model deployment and life cycle management are uniformly performed, so as to utilize the correlation between tasks to improve the performance of each task and reduce the signaling and model update overhead.

[0152] For example, the correlation between tasks comes from the fact that the labels of different tasks reflect different aspects of physical characteristics in the same wireless environment. For example, the optimal beam index label contains the angle characteristics of multipath transmission, and the UE position label contains the relative position characteristics between the UE and the gNB. By utilizing the labels of different tasks for supervised learning, a more comprehensive understanding of the physical characteristics of the wireless environment can be obtained, thereby improving the performance of each task.

[0153] In the following, for the sake of simplicity, sometimes the multi-task model is described for a group of tasks (in-group tasks) after grouping. However, it can be understood that the multi-task model can also be used without grouping the tasks.

[0154] Model authentication refers to the common understanding of AI models between the UE and the gNB. The understanding includes but is not limited to the data type of the model, the data quality (including but not limited to the time sampling period, the quantization bit, the signal-to-noise ratio), and the implemented task (function).

[0155] As an example, the same input data is used for multiple tasks implemented by the multi-task model.

[0156] For example, the input data is uniform for the in-group tasks in terms of including but not limited to data type, data quality.

[0157] As an example, the input data is determined according to at least one of a requirement of the task, a capability of the node related to the task, and a data collection overhead. That is, a unified input data is determined for the tasks in the group. A balance is achieved between the performance of the multiple tasks in the group and the data collection overhead.

[0158] As an example, the requirement of the task includes a time sampling period, the capability of the node includes at least one of availability of node data, quality of node data, matching of node data to different tasks, and quality requirement of different tasks on node data, and the data collection overhead includes a collection overhead of data of a predetermined quality.

[0159] The model authentication for multi-task learning according to the embodiments of the present disclosure simultaneously implements model authentication for multiple tasks in a group. For example, the gNB determines a unified input data according to the tasks and requirements of the tasks, gNB capabilities, and data collection overheads. Since the tasks in the group are uniformly managed in subsequent model updating and model migration operations, the result of the unified input data only needs to be confirmed once between the gNB and the UE, thereby reducing signaling overhead.

[0160] For example, in the case that the electronic device 300 is a gNB, a unified input data can be determined according to the tasks and requirements of the tasks, gNB capabilities, and data collection overheads. For example, in determining the unified input data, the features that can be considered include but are not limited to: C1, availability of gNB-end data; C2, quality of gNB-end data; C3, matching of gNB-end data to different tasks in the group; C4, quality requirement of different tasks in the group on gNB-end data; and C5, collection overhead of data of a specific quality.

[0161] As a comparison, a model authentication for single-task learning is first described. Here, a scenario is discussed in which a model is deployed at the UE end and the gNB needs to complete all or part of data determination and collection.

[0162] The process of the model authentication for single-task learning includes:

[0163] S1, the UE and the gNB store a task list containing all tasks and a data set list containing all available data, which are shared by the UE and the gNB.

[0164] S2, the UE confirms a single task and a requirement of the task.

[0165] S3, according to the task list, a task ID of the task is determined.

[0166] S4, the UE sends the task ID and the requirement to the gNB.

[0167] S5, the gNB determines a type and quality of input data to be provided by the gNB according to the gNB capability, the task ID, and the requirement.

[0168] S6, the gNB informs the determined input data type and quality to the UE.

[0169] S7, according to the task list, the data set list, the input data type and the quality, the UE completes the model information confirmation of the single-task model. The model information includes but is not limited to: (1) model ID: composed of single-task ID and input data ID; (2) input data quality.

[0170] Problems existing in the model authentication for single-task learning are as follows. Through the above process, the model authentication for a single task can be realized. However, since the UE usually needs to support the implementation of multiple tasks, and the model authentication for single-task learning independently manages each single-task model, it can lead to a large data collection overhead and signaling overhead. Specifically, different tasks can use the same type of data (for example, the reference signal receiving power (RSRP) can be used as input data for both beam prediction tasks and positioning tasks), and different tasks can have different quality requirements for the data due to different task requirements. Under the above model authentication process for single-task learning, data of a specific quality needs to be collected for each task, and when the number of tasks is huge, it will bring huge data collection overhead. Generally, the higher the quality of the data (for example, the higher the time sampling rate, the more the quantization bits, and the higher the signal-to-noise ratio), the stronger the performance of the model inference. Therefore, a unified input data can be determined for multiple tasks according to the performance requirements and data collection overhead of each task, so as to reduce the overhead of data collection. However, due to the independent management of each task, in order to perform subsequent model updating and model migration operations, the data type and quality in the model authentication still need to be confirmed between the gNB and the UE through signaling for each task, thereby bringing a large signaling overhead.

[0171] To solve the problems existing in the model authentication for single-task learning, the present application proposes a model authentication process for multi-task learning.

[0172] As an example, the processing unit 303 can be configured to confirm the model information of the multi-task model based on the results about the unified input data, thereby simultaneously performing model authentication for multiple tasks. The model information confirmation between the gNB and the UE is performed in units of groups. The tasks in the same group do not need to be coordinated through signaling between the gNB and the UE. The model information contains the IDs of all the tasks in the group, so the information of the multiple tasks that the model can implement can be obtained by accessing the model information.

[0173] FIG. 11 is a first example process of model authentication for multi-task learning according to an embodiment of the present disclosure. The process shown in FIG. 11 is a process of model authentication for multi-task learning in a scenario where the multi-task model is deployed at the UE end and the gNB needs to complete all or part of the data determination and collection.

[0174] The first example process of model authentication for multi-task learning includes:

[0175] S1, the UE and the gNB store the same task list and the same data set list. The task list contains all possible AI tasks, and each task is assigned a dedicated task ID. The data set list contains all data types, and each data type is assigned a dedicated data ID.

[0176] S2, the UE confirms all tasks and task requirements (including but not limited to time sampling period).

[0177] S3, task ID allocation is performed according to the task list.

[0178] S4, the UE groups tasks according to the correlation between tasks.

[0179] S5, the UE sends the task ID and requirements in the group to the gNB in units of groups.

[0180] S6, the gNB determines the input data that needs to be provided by the gNB according to the task ID and requirements in the group, gNB capability and data collection overhead, including but not limited to input data ID and input data quality determined according to the data set list.

[0181] S7, the gNB notifies the UE of the unified result of the input data that needs to be provided by the gNB.

[0182] S8, the UE completes model information confirmation of the multi-task model according to the task list, the data set list, and the unified result of the input data. The model information includes but is not limited to: (1) model ID: composed of the union of task IDs in the group and input data IDs; (2) input data quality.

[0183] FIG. 12 is an example of a task list according to an embodiment of the present disclosure.

[0184] As shown in FIG. 12, the task list includes three tasks of beam prediction, UE positioning, and CSI feedback, and their task IDs are 0-2 respectively. For example, the two tasks with task IDs 0 and 1 have correlation.

[0185] FIG. 13 is an example of a data set list according to an embodiment of the present disclosure.

[0186] As shown in FIG. 13, the data set list includes three input data of received signal, UE position, and CSI, and their input data IDs are 0-2 respectively.

[0187] A second example process of model authentication for multi-task learning according to an embodiment of the present disclosure is described below. The second example process is a process of model authentication for multi-task learning in a scenario where a multi-task model is deployed at a gNB end and a UE needs to complete all or part of data determination and collection.

[0188] The second example process of model authentication for multi-task learning includes:

[0189] S1, the UE and the gNB store the same task list and the same data set list. The task list contains all possible AI tasks, and each task is assigned a dedicated task ID. The data set list contains all data types, and each data type is assigned a dedicated data ID.

[0190] S2, the gNB confirms all tasks and task requirements (including but not limited to time sampling period).

[0191] S3, task ID allocation is performed according to the task list.

[0192] S4, the gNB groups tasks according to the correlation between tasks.

[0193] S5, the gNB inquires about the UE capability.

[0194] S6, the UE feeds back the UE capability to the gNB.

[0195] S7, the gNB determines the unified input data to be provided by the UE for the tasks in a group according to the task ID and requirements in the group, the UE capability, and data collection overhead, including but not limited to input data ID and input data quality determined according to the data set list.

[0196] S8, the gNB notifies the UE of the unified input data to be provided by the UE.

[0197] S9, the gNB completes model information confirmation of the multi-task model according to the task list, the data set list, and the unified input data result. The model information includes but is not limited to: (1) model ID: composed of the union of task IDs in the group and input data IDs; (2) input data quality.

[0198] A third example process of model authentication for multi-task learning according to an embodiment of the present disclosure is described below. The third example process is a process of model authentication in which a model is deployed at a node (gNB or UE) and the node completes all data confirmation and collection. Model authentication can be performed uniformly for multiple tasks in a group.

[0199] The third example process of model authentication for multi-task learning includes:

[0200] S1, the node stores a task list and a dataset list. The task list contains all possible AI tasks, and each task is assigned a dedicated task ID. The dataset list contains all data types, and each data type is assigned a dedicated data ID.

[0201] S2, the node confirms all tasks and task requirements (including but not limited to time sampling period).

[0202] S3, task ID assignment according to the task list.

[0203] S4, the node groups tasks according to the correlation between tasks.

[0204] S5, the node determines the unified input data for the tasks in the group according to the task ID and task requirements in the group, the node's capabilities, and data collection overhead, including but not limited to input data ID and input data quality determined according to the dataset list.

[0205] S6, the node completes the model information confirmation of the multi-task model according to the task list, the dataset list, and the unified input data result. The model information includes but is not limited to: (1) model ID: composed of the union of task IDs in the group and input data IDs; (2) input data quality.

[0206] In the following, the AI model of activating / deactivating a specific task is described. A task may belong to different groups at the same time, i.e., different multi-task models.

[0207] As a comparison, the model activation / deactivation for single-task learning is described first. Coordination between models of different tasks may be needed. For example, the input of a given model is the output of another model, in which case the trigger time of the two models needs to be aligned. Therefore, in single-task learning, when activating / deactivating a task, the coordination information (including but not limited to trigger time) of the existing activated tasks needs to be inquired.

[0208] The model activation / deactivation process for single-task learning is as follows:

[0209] S1, the node confirms the task ID of the model activation / deactivation.

[0210] S2, the node confirms the IDs of the activated tasks that need to be coordinated with the task according to the activation / deactivation task ID.

[0211] S3, the node inquires the coordination information of the activated tasks that need to be coordinated.

[0212] S4, the node schedules multiple tasks that need to be coordinated according to the coordination information.

[0213] S5, activate / deactivate the corresponding model.

[0214] The problem of the model activation / deactivation for single-task learning is that the coordination information of the tasks that need to be coordinated needs to be inquired, causing additional scheduling signaling overhead.

[0215] To solve the above problem of single-task learning, the model activation / deactivation for multi-task learning is proposed.

[0216] As an example, the processing unit 303 can be configured to, based on the model ID included in the model activation information or the model deactivation information, notify the multi-task model corresponding to the model ID of the task ID to be activated or deactivated, and based on the task ID, activate or deactivate the model branch corresponding to the task ID in the corresponding multi-task model.

[0217] As described above, the tasks that need to be coordinated are usually divided into a group, and the tasks in one group are implemented by using one multi-task model. Since the model deployment and life cycle management of the tasks in the group are unified, the coordination information of the tasks in the group does not need to be inquired. For example, in the same model, the triggering time of different tasks is naturally aligned. Therefore, when a certain task is activated / deactivated, only the model branch of the corresponding task needs to be activated / deactivated in the multi-task model, and the coordination information of other tasks in the same multi-task model does not need to be inquired, thereby reducing the scheduling signaling overhead.

[0218] In the model activation / deactivation for multi-task learning, the multi-task model is first confirmed through the model ID. The tasks that need to be coordinated usually belong to the same multi-task model. Since the model deployment and management of multiple tasks are simultaneously performed, the activation / deactivation for multi-task learning does not need additional signaling to schedule the tasks in the group.

[0219] FIG. 14 is an example flow of the model activation / deactivation for multi-task learning according to an embodiment of the present disclosure.

[0220] S1, a node (gNB or UE) confirms model activation / deactivation information. The information contains a model ID and a task ID.

[0221] S2, the node notifies the multi-task model of the task ID that needs to be activated / deactivated according to the model ID.

[0222] S3, the multi-task model activates / deactivates the model branch specific to the corresponding task according to the task ID.

[0223] It needs to be mentioned that in the multi-task model, the model branches of different tasks are independent. In the model inference stage, activating / deactivating the model branch of a certain task will not affect the shared parameter model in which the tasks in the group share the model parameters and the inference of the model branches of other tasks.

[0224] In addition, one task can belong to different groups at the same time. For example, task A is strongly related to task B and task C, while the relationship between task B and task C is weak. Therefore, task A belongs to the group containing task B and the group containing task C at the same time.

[0225] In addition, when a task can be inferred by different multi-task models, a fusion decision can be considered. For example, the confidence of the multi-task model can be evaluated according to the performance of the task in the group. Further, according to the confidence of the multi-task model, the inference results of different multi-task models for a same task are assigned with decision weights to realize fusion decision.

[0226] Model detection refers to detecting the performance of a task during the inference stage. Model updating refers to updating the parameters or structure of the model.

[0227] In this application, the performance degradation of a task is considered to be caused by: (1) input data quality problem; (2) auxiliary data quality problem; (3) model and scene mismatch.

[0228] In the multi-task model, the tasks in the group have the same input data and share the model parameters. In contrast, the auxiliary data is usually task-specific. For example, the gNB location as auxiliary data is specific to the UE positioning task.

[0229] As a comparison, model detection and model updating for single-task learning are described first.

[0230] The model detection for single-task learning cannot determine the cause of the performance degradation of the task. Therefore, the corresponding model updating process is usually non-environment-specific (as the environment changes, the cause of the performance degradation of the task usually changes, and the method for single-task learning cannot accurately detect such environmental changes and take corresponding model updating operations). In the scenario of UE-side model deployment, gNB needs to complete all or part of the data confirmation and collection, and a model detection and model updating process for single-task learning is as follows:

[0231] S1, the UE sends an update auxiliary data quality request to the gNB according to the single-task model information.

[0232] S2, the gNB updates the auxiliary data quality that needs to be provided by the gNB according to the gNB capability.

[0233] S3, the gNB notifies the UE of the updated auxiliary data quality that needs to be provided by the gNB.

[0234] S4, the gNB collects auxiliary data according to the updated auxiliary data quality and sends it to the UE for model inference.

[0235] S5, the UE continues to detect the performance of the task.

[0236] (the task performance still cannot meet the requirements, enter S6)

[0237] S6, the UE sends an updated input data quality request to the gNB according to the single task model information.

[0238] S7, the gNB updates the input data quality to be provided by the gNB according to the gNB capability.

[0239] S8, the gNB notifies the UE of the updated input data quality to be provided by the gNB.

[0240] S9, the gNB collects input data according to the updated input data quality and sends it to the UE for model inference.

[0241] S10, the UE continues to detect the performance of the task.

[0242] (the task performance still cannot meet the requirements, enter S11)

[0243] S11, the UE sends a model update request to the gNB according to the single task model information.

[0244] S12, the gNB and the UE cooperate to complete the data collection of the task including but not limited to input data, auxiliary data, and label data under the current scenario.

[0245] S13, the single task model is updated using the collected data.

[0246] S14, return to S1.

[0247] The problems of the single task learning-oriented model detection and model update process are as follows. The above process is not environment-specific. When the cause of the task performance decline is the input data quality problem, unnecessary auxiliary data quality update process is performed; when the cause of the task performance decline is the model and scene mismatch, unnecessary auxiliary data and input data quality update process is performed. The single task learning-oriented model management is difficult to determine the cause of the task performance decline, resulting in large model update overhead. As described above, the single task learning-oriented model management is difficult to determine that the task performance decline is caused by: (1) input data (data directly input to the AI model) quality problem; (2) auxiliary data (data not input to the AI model) quality problem; (3) model and scene mismatch.

[0248] In the multi-task model, since the tasks in the group have the same input data and a part of shared model parameters, the tasks in the group can supervise each other. The mutual supervision of the tasks in the group is reflected in that when a small number of tasks in the multi-task model have performance degradation, it can be considered that the probability of the occurrence of the input data quality problem of the model and the model-scene mismatch is low; relatively, when a large number of tasks in the multi-task model have performance degradation, it can be considered that the probability of the occurrence of the input data quality problem of the model and the model-scene mismatch is high. Therefore, according to the situation of the performance degradation of the tasks in the group, the corresponding model updating operation can be taken, so as to reduce the overhead of the model updating in the average sense. By using the characteristics of the mutual supervision of the tasks in the group, the situation of the performance degradation of the tasks in the group is classified, so as to assist in determining the cause of the performance degradation of the tasks.

[0249] Generally, updating the data quality means improving the data quality, for example, quantizing the input data with more quantization bits. Therefore, when the data quality is updated because of the performance degradation of a task, the performance of the remaining tasks in the group generally does not decrease.

[0250] In order to determine the situation of the performance degradation of the tasks in the group, in the scene of the model deployment at the UE end, a process for classifying the situation of the performance degradation of the tasks in the group is as follows:

[0251] S1, a proportion threshold for determining the situation of the performance degradation of the tasks in the group is preset.

[0252] S2, for each task in the group, a threshold for judging whether the task has performance degradation is preset.

[0253] S3, the degradation index of the performance of all the tasks in the group is calculated, and compared with the threshold in S2, so as to determine whether each task in the group has performance degradation.

[0254] S4, the proportion of the number of the tasks in the group that have performance degradation to the total number of the tasks is calculated, and compared with the proportion threshold in S1: if the proportion exceeds the proportion threshold in S1, the model updating process of the performance degradation of the majority of the tasks in the group is taken; otherwise, the model updating process of the performance degradation of the minority of the tasks in the group is taken.

[0255] For example, the proportion threshold has a value range of (0, 1). The proportion threshold can be adjusted according to actual needs.

[0256] As an example, the processing unit 303 can be configured to implement the updating of the multi-task model by at least one of the updating of the quality of the input data of the multi-task model, the updating of the quality of the auxiliary data of the multi-task model, and the updating of the model parameters of the multi-task model, based on the classification of the performance degradation situation of the plurality of tasks.

[0257] FIG. 15 is a first example flow of model detection and model update for multi-task learning according to an embodiment of the present disclosure. The flow shown in FIG. 15 is a model update flow for performance degradation of most tasks in a group in a scenario where model deployment is at the UE end, and gNB needs to complete all or part of data confirmation and collection.

[0258] The first example flow of model detection and model update for multi-task learning described above includes:

[0259] S1, the UE sends an update input data quality request to the gNB according to the multi-task model information.

[0260] S2, the gNB updates the input data quality to be provided by the gNB according to the gNB capability.

[0261] S3, the gNB notifies the UE of the updated input data quality to be provided by the gNB.

[0262] S4, the gNB collects input data according to the updated input data quality and sends it to the UE for model inference.

[0263] S5, the UE continues to monitor the performance of all tasks in the group.

[0264] (If the performance of most tasks still cannot meet the requirements, go to S6)

[0265] S6, the UE sends a model update request to the gNB according to the multi-task model information.

[0266] S7, the gNB and the UE cooperate to complete the collection of multi-task model input data, multi-task model auxiliary data, and all task label data in the group according to the multi-task model information in the current scenario.

[0267] S8, the multi-task model is updated using the collected data.

[0268] S9, the UE continues to monitor the performance of all tasks in the group.

[0269] (If the performance of most tasks still cannot meet the requirements, go to S10)

[0270] S10, the UE sends an update auxiliary data quality request to the gNB according to the multi-task model information.

[0271] S11, the gNB updates the auxiliary data quality to be provided by the gNB according to the gNB capability.

[0272] S12, the gNB notifies the UE of the updated auxiliary data quality to be provided by the gNB.

[0273] S13, the gNB collects the assistance data according to the updated assistance data quality, and sends it to the UE for model inference.

[0274] Since the tasks in a group have the same input data and have the same part of model parameters (i.e., share the parameters of the shared parameter model included in the multi-task model described above), while the assistance data is usually task-specific. For example, the gNB location as a kind of assistance data is specific to the UE positioning task. Therefore, when the performance of most tasks decreases, the probability of the occurrence of input data quality problems and model and scene mismatch is large, while the probability of the occurrence of task-specific assistance data quality problems is small. Considering that the overhead of model parameter updating is usually much larger than the overhead of updating the input data quality, therefore, when updating the model, first update the input data quality, then update the model parameters, and finally update the assistance data quality. By taking the corresponding model updating operation according to the problem occurrence probability from large to small, the overhead of model updating can be reduced in the average sense.

[0275] FIG. 16 is a second example flow of multi-task learning-oriented model detection and model updating according to an embodiment of the present disclosure. The flow shown in FIG. 16 is a model updating flow for a few task performance decrease in a group in a scenario where the UE side model deployment is needed, and the gNB completes all or part of the data confirmation and collection.

[0276] The second example flow of multi-task learning-oriented model detection and model updating described above includes:

[0277] S1, the UE sends an update assistance data quality request to the gNB according to the multi-task model information and the task ID of the performance decreased task.

[0278] S2, the gNB updates the assistance data quality of the few performance decreased tasks that need to be provided by the gNB according to the gNB capability.

[0279] S3, the gNB notifies the UE of the updated assistance data quality of the few performance decreased tasks that need to be provided by the gNB.

[0280] S4, the gNB collects the assistance data of the few performance decreased tasks according to the updated assistance data quality, and sends it to the UE for model inference.

[0281] S5, the UE continues to monitor the performance of the few performance decreased tasks.

[0282] (If the performance of the few performance decreased tasks still cannot meet the requirements, go to S6)

[0283] S6, the UE sends an update input data quality request to the gNB according to the multi-task model information.

[0284] S7, the gNB updates the input data quality to be provided by the gNB according to the gNB capability.

[0285] S8, the gNB informs the UE of the updated input data quality to be provided by the gNB.

[0286] S9, the gNB collects the input data according to the updated input data quality and sends it to the UE for model inference.

[0287] S10, the UE continues to monitor the performance of the few performance-degraded tasks.

[0288] (If the performance of the few performance-degraded tasks still cannot meet the requirements, go to S11)

[0289] S11, the UE sends a model update request to the gNB according to the multi-task model information and the task ID set of the few performance-degraded tasks.

[0290] S12, the gNB and the UE cooperate to complete the collection of input data, auxiliary data, and label data of the few performance-degraded tasks in the current scenario according to the multi-task model information and the task ID set of the performance-degraded tasks.

[0291] S13, use the collected data to update the model parameters of the model branches of the few performance-degraded tasks in the multi-task model. For S13, only the model branches of the performance-degraded tasks are updated, and the parameters of the model branches of the majority of normal performance tasks and the model sharing parameters within the group are fixed. Generally, since different tasks in the multi-task model are usually decoupled in the model inference stage (except for multi-task cascading), updating only the decoder parameters of the few performance-degraded tasks will not affect the performance of the majority of tasks.

[0292] When the performance of a few tasks is degraded, the probability of auxiliary data problems is relatively large, while the probability of input data quality problems and model and scene mismatch is relatively small. Therefore, when updating the model, the auxiliary data quality is updated first, then the input data quality is updated, and finally the model parameters are updated. By taking the corresponding model update operation according to the problem occurrence probability from large to small, the average model update overhead can be reduced. In addition, since only a few tasks are degraded, when updating the model parameters, only the labels of the few performance-degraded tasks need to be collected and the corresponding model branches need to be updated, thereby reducing the model update overhead.

[0293] Unlike the deployment at the UE side, when the multitask model is deployed at the gNB side, it is usually required to support multiple UEs within the gNB service range. When a few UEs have performance degradation, the model update operation performed on them cannot affect the inference of most normal performance UEs. Therefore, when the multitask model is deployed at the gNB side, the task performance degradation situation is divided into four categories: (1) most task performance degradation of most UEs; (2) few task performance degradation of most UEs; (3) most task performance degradation of few UEs; (4) few task performance degradation of few UEs.

[0294] In order to determine the task performance degradation situation in the group, a process for classifying the task performance degradation situation in the group is proposed in the scenario of gNB-side model deployment and multitask model supporting multiple UEs within the gNB service range:

[0295] S1, for multiple UEs within the gNB service range, the same multitask model is supported, and a proportion threshold for determining the performance degradation situation of the multiple UEs is preset.

[0296] S2, a proportion threshold for determining the performance degradation situation of multiple tasks in the group is preset.

[0297] S3, for each task in the group, a threshold for judging whether the task has performance degradation is preset.

[0298] S4, for each UE, the performance degradation index of all tasks in the group is calculated and compared with the threshold in S3, so as to determine whether each task in the group has performance degradation for each UE.

[0299] S6, for each UE, the proportion of the number of tasks with performance degradation in the group to the total number of tasks is calculated and compared with the proportion threshold in S2, so as to determine whether each UE has most task performance degradation / few task performance degradation / no task performance degradation.

[0300] S7, the proportion of the number of UEs with task performance degradation (including most task performance degradation and few task performance degradation) to the total number of UEs is calculated and compared with the proportion threshold in S1, so as to classify the performance degradation situation of UEs within the gNB service range as most UE performance degradation / few UE performance degradation.

[0301] The multitask model deployed at the gNB side usually needs to support multiple UEs within the gNB service range. When a few UEs have performance degradation, the model update operation performed on them cannot affect the model inference of most normal performance UEs.

[0302] According to an embodiment of the present disclosure, a model updating process is proposed for the scenario of model deployment at the gNB end, requiring the UE to complete all or part of the data confirmation and collection, under the condition of performance degradation of most tasks of most UEs:

[0303] S1, the gNB determines the updated input data quality to be provided by the UE according to the multi-task model information.

[0304] S2, the gNB informs the updated input data quality to be provided by the UE to the performance-degraded UE.

[0305] S3, the performance-degraded UE collects the input data according to the updated input data quality and feeds back to the gNB for model inference.

[0306] S4, the gNB continues to monitor the performance of all tasks in the group of all UEs.

[0307] (If the performance of most tasks of most UEs still cannot meet the requirements, go to S5)

[0308] S5, the gNB sends a model update request to all UEs according to the multi-task model information.

[0309] S6, the gNB and all UEs cooperate to complete the collection of all UEs including multi-task model input data, multi-task model auxiliary data, and group task label data under the current scenario according to the multi-task model information.

[0310] S7, the multi-task model is updated using the collected data.

[0311] S8, the gNB continues to monitor the performance of all tasks in the group of all UEs.

[0312] (If the performance of most tasks of most UEs still cannot meet the requirements, go to S9)

[0313] S9, the gNB determines the updated auxiliary data quality to be provided by the UE according to the multi-task model information.

[0314] S10, the gNB informs the updated auxiliary data quality to be provided by the UE to the performance-degraded UE.

[0315] S11, the performance-degraded UE collects the auxiliary data according to the updated auxiliary data quality and feeds back to the gNB for model inference.

[0316] The input data and the auxiliary data are UE-specific, and the multi-task model is shared by all UEs. Therefore, when the input data quality and the auxiliary data quality are updated, the update can be performed for the UEs with performance degradation. When the model parameters are updated, the data of all UEs need to be collected to ensure the performance of all UEs. Meanwhile, because most of the tasks of most UEs have performance degradation, the entire multi-task model can be mismatched with the scene. Therefore, when the model parameters are updated, the label data of all tasks in the group need to be collected to update the entire multi-task model.

[0317] According to an embodiment of the present disclosure, a model update process for performance degradation of a minority of tasks of most UEs is proposed in a scenario where the gNB end model deployment needs the UEs to complete all or part of data confirmation and collection.

[0318] S1, the gNB determines the updated auxiliary data quality of the minority of performance-degraded tasks that need to be provided by the UEs according to the multi-task model information.

[0319] S2, the gNB informs the updated auxiliary data quality of the minority of performance-degraded tasks that need to be provided by the UEs to the performance-degraded UEs.

[0320] S3, the performance-degraded UEs collect the auxiliary data of the minority of performance-degraded tasks according to the updated auxiliary data quality and feed back to the gNB for model inference.

[0321] S4, the gNB continues to monitor the performance of the minority of performance-degraded tasks in the group of all UEs.

[0322] (If the performance of the minority of tasks of most UEs still cannot meet the requirements, go to S5)

[0323] S5, the gNB determines the updated input data quality that needs to be provided by the UEs according to the multi-task model information.

[0324] S6, the gNB informs the updated input data quality that needs to be provided by the UEs to the performance-degraded UEs.

[0325] S7, the performance-degraded UEs collect the input data according to the updated input data quality and feed back to the gNB for model inference.

[0326] S8, the gNB continues to monitor the performance of the minority of performance-degraded tasks in the group of all UEs.

[0327] (If the performance of the minority of tasks of most UEs still cannot meet the requirements, go to S9)

[0328] S9, the gNB sends a model update request to all UEs according to the multi-task model information and the task ID set of the minority of performance-degraded tasks.

[0329] S10, the gNB and all UEs cooperate to complete the collection of all UEs in the current scene including multi-task model input data, multi-task model auxiliary data, and group minority performance degradation task label data according to multi-task model information and a task ID set of a few performance degradation tasks.

[0330] S11, model parameter updating is performed on the model branch of the few performance degradation tasks in the multi-task model by using the collected data.

[0331] Most UEs have only a few performance degradation tasks, so the quality of auxiliary data is updated first, then the quality of input data is updated, and finally the model parameters are updated. It should be noted that when the model parameters are updated, since most tasks have normal performance, only the model branch of the few performance degradation tasks in the multi-task model is mismatched with the scene. Therefore, only the label data of the few performance degradation tasks needs to be collected, and only the model branch corresponding to these tasks needs to be updated in model updating, thereby reducing the model updating overhead.

[0332] FIG. 17 is a third example flow of model detection and model updating for multi-task learning according to an embodiment of the present disclosure. The flow shown in FIG. 17 is a model updating flow for a few UEs with most performance degradation tasks in a scenario where the gNB side model is deployed and the UE needs to complete all or part of the data confirmation and collection.

[0333] The third example flow of model detection and model updating for multi-task learning described above includes:

[0334] S1, the gNB determines the updated input data quality to be provided by the UE according to the multi-task model information.

[0335] S2, the gNB notifies the few performance degradation UEs of the updated input data quality to be provided by the UE.

[0336] S3, the few performance degradation UEs collect input data according to the updated input data quality and feed back to the gNB for model inference.

[0337] S4, the gNB continues to monitor the performance of all tasks in the group of few performance degradation UEs.

[0338] (If most of the tasks of the few performance degradation UEs still cannot meet the requirements, go to S5)

[0339] S5, the gNB determines the updated auxiliary data quality to be provided by the UE according to the multi-task model information.

[0340] S6, the gNB informs the UE of the updated, UE-provided, assistance data quality for the few-task performance degradation.

[0341] S7, the few-task performance degradation UE collects assistance data according to the updated assistance data quality and feeds back to the gNB for model inference.

[0342] S8, the gNB continues to monitor the performance of all tasks of the few-task performance degradation UE.

[0343] (If the majority of the few-task performance degradation UE still cannot meet the demand, go to S9)

[0344] S9, according to the multi-task model information, model switching is performed for all tasks of the few-task performance degradation UE. Model switching refers to that the current multi-task model stops supporting the few-task performance degradation UE, and a new model is activated for these UEs. The new model includes but is not limited to: (1) a multi-task model trained using different scene training data to achieve the same group task; (2) multiple traditional methods capable of achieving the same group task.

[0345] When only a few UEs have performance degradation, in order to ensure the overall performance of the system, the multi-task model is generally not updated. Therefore, when the input data and the assistance data quality of the few UEs are updated, model updating is not performed, but model switching is performed.

[0346] According to the embodiments of the present disclosure, a few-task performance degradation model updating process for few UEs is proposed in the scenario of gNB-end model deployment and the need for UEs to complete all or part of data confirmation and collection:

[0347] S1, the gNB determines the updated, UE-provided, assistance data quality for the few-task performance degradation task according to the multi-task model information.

[0348] S2, the gNB informs the UE of the updated, UE-provided, assistance data quality for the few-task performance degradation task.

[0349] S3, the few-task performance degradation UE collects assistance data for the few-task performance degradation task according to the updated assistance data quality and feeds back to the gNB for model inference.

[0350] S4, the gNB continues to monitor the performance of the few-task performance degradation task of the few UEs.

[0351] (If the performance of the few-task performance degradation task of the few UEs still cannot meet the demand, go to S5)

[0352] S5, the gNB determines the updated, UE-provided, input data quality according to the multi-task model information.

[0353] S6, the gNB informs the updated UE whose input data quality needs to be provided by the UE at least the number of performance degradation.

[0354] S7, the UE whose number of performance degradation collects input data according to the updated input data quality and feeds back to the gNB for model inference.

[0355] S8, the gNB continues to monitor the performance of the UE whose number of performance degradation.

[0356] (If the performance of the UE whose number of performance degradation still cannot meet the demand, enter S9)

[0357] S9, according to the multi-task model information, for the UE whose number of performance degradation, model switching is performed. Model switching refers to that for the UE whose number of performance degradation, the multi-task model still supports the majority of its performance normal tasks, and stops supporting its number of performance degradation tasks. For the UE whose number of performance degradation, a new model is activated. The new model includes but is not limited to multiple traditional methods capable of realizing the group performance degradation task.

[0358] The number of performance degradation of the UE is only a few, so the multi-task model can still support the majority of the performance normal tasks of these UEs.

[0359] After model updating, some tasks may still not achieve satisfactory performance. This may be because the task needs the cooperation of multiple base stations. For example, for the UE positioning task, when there is an obstruction between the main gNB (the gNB currently supporting the AI task of the UE) and the UE, resulting in no LOS path, the performance of the UE positioning task will be significantly reduced. At this time, if there is an LOS path between the auxiliary gNB (the gNB around the main gNB, the number of auxiliary gNBs can be multiple or single) and the UE, the positioning performance can be significantly improved by using the cooperation of the main gNB and the auxiliary gNB to locate the UE.

[0360] As a comparison, a multi-base station cooperation for single task learning is first described.

[0361] A flow of single task multi-base station cooperation:

[0362] S1, the main gNB performs privacy confirmation.

[0363] S2, the main gNB informs the UE to perform privacy confirmation, and the UE feeds back the privacy confirmation result to the main gNB.

[0364] S3, the main gNB sends the model ID (including single task ID, input data ID) and UE ID to the auxiliary gNB.

[0365] S4, the auxiliary gNB performs privacy confirmation.

[0366] S5, according to the model ID and the UE ID, the authentication of the auxiliary gNB side single task model is completed.

[0367] S6, according to the model information of the auxiliary gNB side single task model, the data collection between the auxiliary gNB and the UE is completed.

[0368] S7, the model training of the auxiliary gNB side single task model is completed.

[0369] S8, the main gNB and the auxiliary gNB perform joint inference according to the results of the respective single task models.

[0370] Problems of single task multi-base station cooperation are as follows. In single task multi-base station cooperation, different gNBs are required to have the same type of input data and the same type of task label data. However, since the capabilities of different gNBs in actual scenarios are usually different, it may not be possible to support obtaining the same type of input data and the same type of task label data, thereby bringing challenges to single task multi-base station cooperation.

[0371] As an example, the processing unit 303 can be configured to cooperate with other electronic devices to implement at least part of a plurality of tasks, wherein the input data of the multi-task model at the other electronic devices is the same as or different from the input data of the multi-task model at the electronic device 300.

[0372] In the multi-base station cooperation oriented to multi-task learning according to the embodiments of the present disclosure, the auxiliary gNB side multi-task model is allowed to implement part of the task set of multi-base station cooperation to improve the performance of this part of the task. The auxiliary gNB side multi-task model is allowed to implement tasks other than the task set of multi-base station cooperation, which are related to the task of multi-base station cooperation, to improve the performance of the task of multi-base station cooperation. The auxiliary gNB side multi-task model is allowed to use different types of input data from the main gNB side multi-task model, and more rich types of input data can drive the model to have a more comprehensive understanding of the wireless environment, to improve the performance of the task of multi-base station cooperation.

[0373] The capabilities of the auxiliary gNB and the main gNB are usually different. The auxiliary gNB side multi-task model is allowed to implement part of the task set of multi-base station cooperation to improve the performance of this part of the task. The auxiliary gNB side multi-task model is allowed to implement tasks other than the task set of multi-base station cooperation, which are related to the task of multi-base station cooperation, to improve the performance of the task of multi-base station cooperation. The auxiliary gNB side multi-task model is allowed to use different types of input data from the main gNB side multi-task model, and more rich types of input data can drive the model to have a more comprehensive understanding of the wireless environment, to improve the performance of the task of multi-base station cooperation.

[0374] FIG. 18 is a flowchart illustrating multi-task multi-base station cooperation according to an embodiment of the present disclosure. The flowchart includes:

[0375] S1, according to the multi-task model information, the master gNB determines the ID set of the group performance degradation task.

[0376] S2, the master gNB performs privacy confirmation.

[0377] S3, the master gNB selects the task suitable for multi-base station cooperation according to the ID set of the group performance degradation task and the nature of the task. These selected tasks constitute the task ID set of multi-base station cooperation.

[0378] S4, the master gNB notifies the UE to perform privacy confirmation, and the UE feeds back the privacy confirmation result to the master gNB.

[0379] S5, the master gNB sends the task ID set of multi-base station cooperation and the UE ID to the secondary gNB.

[0380] S6, the secondary gNB performs privacy confirmation.

[0381] S7, according to the task ID set of multi-base station cooperation and the UE ID, the authentication of the multi-task model at the secondary gNB end is completed. It should be noted that according to the secondary gNB capability, the secondary gNB end multi-task model is allowed to implement part of the task set in the multi-base station cooperation task set, implement the task outside the multi-base station cooperation task set (this part of the task is activated in the model training stage and deactivated in the model inference stage). At the same time, the secondary gNB end multi-task model is allowed to use different types of input data from the master gNB end multi-task model.

[0382] S8, according to the model information of the secondary gNB end multi-task model, the data collection between the secondary gNB and the UE about the secondary gNB end multi-task model is performed.

[0383] S9, the model training of the secondary gNB end multi-task model is completed.

[0384] S10, the master gNB and the secondary gNB perform joint inference according to the results of the respective multi-task models.

[0385] The dual-end model refers to the model inference which needs to be jointly performed at the gNB and the UE. The present application considers a general case, that is, in order to implement a given task, part of the model is deployed at the gNB end and part of the model is deployed at the UE end. Further, from the perspective of life cycle management, the gNB end model input and the UE end model input are similar. Therefore, the present application focuses on the scenario of the UE end model input dual-end model.

[0386] To train and deploy the dual-end model, one method is to complete the training of the whole dual-end model in the gNB, and then distribute the shared parameter model in the trained model which should be deployed in the UE to the UE. In the model inference stage, the UE-side model completes the UE-side inference according to the input data. The result of inference is quantized and called codeword. The codeword is fed back to the gNB through the uplink channel as the input of the gNB-side model inference, so as to complete the joint inference of the dual-end model.

[0387] As a comparison, the model training, model distribution and model inference of the dual-end model for single task learning are described first.

[0388] The process of model training and model distribution of a single task dual-end model is as follows:

[0389] S1, the UE and the gNB complete the confirmation of the task and the task requirement of the single task dual-end model.

[0390] S2, the gNB inquires the UE capability.

[0391] S3, the UE feeds back the UE capability to the gNB.

[0392] S4, the gNB determines the input data to be provided by the UE according to the task ID and requirement, the UE capability and the data collection overhead.

[0393] S5, the gNB informs the UE of the input data to be provided by the UE.

[0394] S6, the gNB and the UE complete the model information confirmation of the single task dual-end model. The model information includes but is not limited to the model ID and the data ID.

[0395] S7, the UE and the gNB cooperate to complete the data collection of the dual-end model according to the model information of the single task dual-end model.

[0396] S8, the data is migrated to the gNB.

[0397] S9, the gNB completes the training of the single task dual-end model.

[0398] S10, the gNB distributes a part of the single task dual-end model which should be deployed in the UE to the UE.

[0399] The process of model inference of a single task dual-end model is as follows:

[0400] S1, the UE collects inference data according to the model information of the single task dual-end model.

[0401] S2, the UE-side model completes the UE-side inference according to the inference data, and outputs the task-specific codeword.

[0402] S3, the UE feeds the task-specific code word to the gNB through an uplink channel.

[0403] S4, the gNB takes the received feedback code word as the input of the gNB-end model, completes the inference of the gNB-end model, and thus realizes the joint inference of the single-task dual-end model.

[0404] The problems existing in the model training, model distribution and model inference of the dual-end model for single-task learning are as follows. The above process has two problems in model training, model distribution and model inference. First, single-task learning needs to deploy a dual-end model for each task, and when the number of tasks is huge, a large amount of model distribution overhead will be brought. Second, single-task learning needs to feed back a task-specific code word for each task, and when the number of tasks is huge, a large amount of model inference feedback overhead will be brought.

[0405] In the multi-task model, the shared parameter model sharing model parameters of tasks in a group extracts a representation shared by tasks in the group from input data. Inspired by this, the present application proposes model training, model distribution and model inference for multi-task learning. Specifically, the UE-end model is a shared parameter model sharing model parameters of tasks in a group in the multi-task model, so that in the distribution of the dual-end model, only one shared parameter model shared by tasks in a group needs to be distributed, and the model distribution of the multi-task dual-end model corresponding to multiple tasks in a group can be realized. At the same time, the UE-end model extracts one shared representation for tasks in a group, i.e., one shared feedback code word, thereby significantly reducing the feedback overhead of model inference.

[0406] FIG. 19 shows an example of the process of model training and model distribution of the multi-task dual-end model according to an embodiment of the present disclosure. As shown in FIG. 19, the process includes:

[0407] S1, the UE and the gNB complete the confirmation of the tasks in a group and the task requirements of the dual-end model.

[0408] S2, the gNB inquires about the UE capability.

[0409] S3, the UE feeds back the UE capability to the gNB.

[0410] S4, the gNB determines the unified input data to be provided by the UE for the tasks in a group according to the task ID and requirements, the UE capability and the data collection overhead.

[0411] S5, the gNB notifies the UE of the unified input data to be provided by the UE.

[0412] S6, the gNB and the UE complete the model information confirmation of the multi-task dual-end model. The model information includes but is not limited to model ID and data ID.

[0413] S7, the UE and the gNB cooperate to complete data collection of the dual-end model according to the model information of the multi-task dual-end model.

[0414] S8, the training data is migrated to the gNB.

[0415] S9, the gNB completes the training of the multi-task dual-end model

[0416] S10, the gNB distributes part of the model of the multi-task dual-end model, which shares model parameters of intra-group tasks, to the UE.

[0417] FIG. 20 shows an example of a flow of model inference of a multi-task dual-end model according to an embodiment of the present disclosure. As shown in FIG. 20, the flow includes:

[0418] S1, the UE collects inference data according to the model information of the multi-task dual-end model.

[0419] S2, the UE-side model completes UE-side inference according to the inference data, and outputs intra-group task shared code words.

[0420] S3, the UE feeds back the shared code words to the gNB through an uplink channel.

[0421] S4, the gNB takes the received feedback code words as inputs of model branches specific to each task of the gNB-side model, completes inference of the gNB-side model, and thus realizes joint inference of the multi-task dual-end model.

[0422] As an example, in a case where the electronic device 300 is a network-side device (e.g., a gNB): for a multi-task model of a user device side, based on a channel condition in which the user device is located and / or capability information representing a capability of the user device, indicating a monitoring format to be adopted by the user device for monitoring the multi-task model; and in a case where the electronic device 300 is a user device: for a multi-task model of the electronic device side, receiving, from a network-side device, an indication about a monitoring format to be adopted for monitoring the multi-task model, wherein the monitoring format is determined by the network-side device based on a channel condition in which the electronic device is located and / or capability information representing a capability of the electronic device.

[0423] As an example, the monitoring format is a first monitoring format or a second monitoring format, wherein in the first monitoring format, multiple monitoring is performed by multiplexing at least part of historical measurement information for multiple tasks, and in the second monitoring format, for multiple monitoring, measurement information used for each monitoring does not overlap.

[0424] In the case that the electronic device 300 is a network side device (for example, a gNB), the description about indicating the detection format can refer to the description of the electronic device 100 embodiment. That is, the electronic device 300 has the same function as the electronic device 100, and here is not repeated.

[0425] In the case that the electronic device 300 is a user device, the description about indicating the detection format can refer to the description of the electronic device 200 embodiment. That is, the electronic device 300 has the same function as the electronic device 200, and here is not repeated.

[0426] Consider using an AI model to implement the beam prediction task and the positioning task at the same time. Since the optimal beam index label reflects the angle information of the multipath transmission between the UE and the gNB, and the user position label contains the position information between the UE and the gNB. The two labels reflect different aspects of physical characteristics in the same wireless environment, so there is a correlation between the two tasks, and multi-task learning can be used to improve the performance of each task. The input data of the multi-task learning model is the RSRP of the historical beam training.

[0427] In order to model the wireless channel, the Saleh-Valenzuela channel model is used to calculate the CSI according to the characteristics of each path such as attenuation, delay, angle of arrival, angle of departure, etc. The specific simulation parameters are shown in Table 1.

[0428]

[0429] Table 1 Channel simulation parameters

[0430] Since the RSRP of the historical beam training is used to predict the future optimal beam index and user position, the multi-task model needs to process time series. The application adopts the combination of convolutional neural network (CNN) and long short-term memory neural network (LSTM) to realize time series processing, wherein CNN is used to extract spatial correlation and LSTM is used to extract temporal correlation. The multi-task model includes a shared parameter model sharing model parameters within a group and two model branches for beam prediction task and positioning task respectively, and the specific structure and parameters are shown in Tables 2-4. Wherein fi, fo respectively represent the number of input, output feature channels, (a, b, c) respectively represent the convolution kernel size, down-sampling step and edge padding size of the convolution layer, BatchNorm refers to batch normalization, Global AvgPooling refers to global average pooling, and ReLU refers to ReLU activation function.

[0431]

[0432] Table 2 Structure and parameters of shared parameter model sharing model parameters within a group

[0433]

[0434] Table 3 Structure and parameters of model branches for beam prediction task

[0435]

[0436] Table 4 Structure and parameters of model branches for positioning task

[0437] To train the proposed multi-task model, the cross-entropy loss function for beam prediction and the mean square error loss function for UE positioning are combined:

[0438]

[0439] where pn is the indication of whether the n-th beam index in the label is the optimal beam index (pn = 1 when it is the optimal beam index; otherwise, pn = 0). N is the number of candidate beams. is the probability prediction of the multi-task model for whether the n-th beam index is the optimal beam index. x and y are the two-dimensional coordinates of the UE position in the label. and is the prediction of the multi-task model for the two-dimensional coordinates of the UE position. μ is a weighted hyperparameter that balances the loss of the beam prediction task and the positioning task. The larger μ is, the more the training of the multi-task model is biased towards the positioning task.

[0440] To demonstrate the effectiveness of multi-task learning, the multi-task model is compared with the single-task model specialized for beam prediction and the single-task model specialized for positioning. At the same time, to compare fairly, the parameter amount of each model is arranged as shown in Table 5. Among them, the parameter amount of the multi-task model is slightly smaller than the sum of the parameter amounts of the above two single-task models.

[0441]

[0442] Table 5 Decoder structure and parameters for positioning task

[0443] Further, the accuracy of beam prediction and the average positioning error of positioning are evaluated. Assuming the total number of samples is N sum , where the optimal beam index of beam prediction is the number of samples in the label whose optimal beam index is N acc , then the accuracy of beam prediction is

[0444]

[0445] The average error of positioning is

[0446]

[0447] FIG. 21 is a graph showing the comparison of the multi-task model and the single-task model specialized for beam prediction in terms of beam prediction accuracy. In FIG. 21, the weighting hyper-parameter μ is used as the horizontal coordinate. Since the training of the single-task model only considers the loss of a single task, the accuracy of the single-task model does not change with the change of the weighting hyper-parameter μ. In contrast, it can be seen that since the weighting hyper-parameter μ affects the training of the multi-task model, the greater the weighting hyper-parameter μ, the more the training of the multi-task model is biased towards the positioning task. Therefore, the greater the weighting hyper-parameter μ, the overall downward trend of the multi-task model in terms of beam prediction accuracy.

[0448] FIG. 22 is a graph showing the comparison of the multi-task model and the single-task model specialized for positioning in terms of average positioning error. In FIG. 22, the weighting hyper-parameter μ is used as the horizontal coordinate. It can be seen that the greater the weighting hyper-parameter μ, the overall downward trend of the multi-task model in terms of average positioning error. This is because the greater the weighting hyper-parameter μ, the more the training of the multi-task model is biased towards the positioning task.

[0449] Further, by comparing FIG. 21 and FIG. 22, it can be seen that as the weighting hyper-parameter μ increases, since the training of the multi-task model is more biased towards the positioning task, the overall trend is that the beam prediction accuracy decreases and the average positioning error decreases. However, by setting a suitable weighting hyper-parameter μ, for example, in FIG. 21 and FIG. 22, by setting μ = 0.05, the multi-task model can achieve higher beam prediction accuracy and lower user positioning error compared to the two single-task models, that is, better performance on both tasks.

[0450] In addition, it should be noted that as the weighting hyper-parameter μ increases, the average positioning error of the multi-task model does not always decrease. As the weighting hyper-parameter μ decreases, the accuracy of the beam prediction of the multi-task model also does not always improve. This is because when the training of the multi-task model is completely biased towards a certain task, the performance of the task in multi-task learning tends to be close to the performance of the task in single-task learning, instead of improving the performance of each task by utilizing the correlation between tasks.

[0451] In summary, the multi-task learning scheme proposed in this paper utilizes the correlation between tasks to achieve better performance with fewer model parameters compared to the single-task learning scheme.

[0452] In the process of describing the electronic devices 100, 200 and 300 in the above embodiments, some processes or methods are also disclosed. Hereinafter, the outlines of these methods are given without repeating some details that have been discussed above, but it should be noted that although these methods are disclosed in the process of describing the above electronic devices, these methods do not necessarily employ or are not necessarily executed by those components described. For example, the above embodiments of the electronic devices can be partially or completely implemented using hardware and / or firmware, and the methods discussed below can be completely implemented by computer executable programs, although these methods can also be implemented using hardware and / or firmware of the electronic devices.

[0453] FIG. 23 shows a flow chart of a method S2300 for wireless communication according to an embodiment of the present disclosure. The method S2300 starts at step S2302. In step S2304, for a task model for implementing a task at a user equipment side, an indication is given of a monitoring format to be employed by the user equipment for monitoring the task model, based on channel conditions at which the user equipment is located and / or capability information indicative of a capability of the user equipment. The method S2300 ends at step S2306.

[0454] The method can be performed, for example, by the electronic device 100 described above, and specific details thereof can be found in the description of the related processes of the electronic device 100 above, which are not repeated here.

[0455] FIG. 24 shows a flow chart of a method S2400 for wireless communication according to another embodiment of the present disclosure. The method S2400 starts at step S2402. In step S2404, for a task model for implementing a task at an electronic device side, an indication is received from a network side device about a monitoring format to be employed for monitoring the task model, wherein the monitoring format is determined by the network side device based on channel conditions at which the electronic device is located and / or capability information indicative of a capability of the electronic device. The method S2400 ends at step S2406.

[0456] The method can be performed, for example, by the electronic device 200 described above, and specific details thereof can be found in the description of the related processes of the electronic device 200 above, which are not repeated here.

[0457] FIG. 25 shows a flow chart of a method S2500 for wireless communication according to yet another embodiment of the present disclosure. The method S2500 starts at step S2502. In step S2504, a plurality of tasks are implemented simultaneously by a multi-task model, wherein the multi-task model comprises a shared parameter model shared by the plurality of tasks and model branches respectively corresponding to at least a portion of the plurality of tasks. The method S2500 ends at step S2506.

[0458] The method can be performed by the electronic device 300 described above, for example, and details thereof can be found in the description of the related processing of the electronic device 300 above, which will not be repeated here.

[0459] The technology of the present disclosure can be applied to various products.

[0460] The electronic devices 100 and 300 can be provided on the base station side or connected to the base station. The base station can be implemented as any type of evolved Node B (eNB) or gNB (5G base station). The eNB includes, for example, a macro eNB and a small eNB. The small eNB can be an eNB for a small cell whose coverage is smaller than that of a macro cell, such as a pico eNB, a micro eNB, and a home (femto) eNB. The same can be applied to the gNB. Instead, the base station can be implemented as any other type of base station, such as a NodeB and a base transceiver station (BTS). The base station can include a main body (also referred to as a base station device) configured to control wireless communication, and one or more remote radio heads (RRHs) provided at a different place from the main body. In addition, various types of electronic devices can operate as a base station by temporarily or semi-persistently performing a base station function.

[0461] The electronic devices 200 and 300 can be implemented as various user devices. The user device can be implemented as a mobile terminal such as a smartphone, a tablet personal computer (PC), a notebook PC, a portable game terminal, a portable / cryptographic dongle type mobile router, and a digital camera device, or a vehicle-mounted terminal such as a car navigation device. The user device can also be implemented as a terminal that performs machine-to-machine (M2M) communication (also referred to as a machine type communication (MTC) terminal). Furthermore, the user device can be a wireless communication module mounted on each of the above-described terminals, such as an integrated circuit module including a single wafer.

[0462] [Application Example Regarding Base Station]

[0463] (First Application Example)

[0464] FIG. 26 is a block diagram illustrating a first example of a schematic configuration of an eNB or gNB to which the technology of the present disclosure can be applied. Note that the following description assumes an eNB as an example, but the same can be applied to a gNB. An eNB 800 includes one or more antennas 810 and a base station device 820. The base station device 820 and each antenna 810 can be connected to each other via an RF cable.

[0465] Each of the antennas 810 includes a single or multiple antenna elements (such as a plurality of antenna elements included in a multiple-input multiple-output (MIMO) antenna), and is used for the base station apparatus 820 to transmit and receive wireless signals. As illustrated in FIG. 26, the eNB 800 can include a plurality of antennas 810. For example, the plurality of antennas 810 can be compatible with a plurality of frequency bands used by the eNB 800. Although FIG. 26 illustrates an example in which the eNB 800 includes a plurality of antennas 810, the eNB 800 can also include a single antenna 810.

[0466] The base station apparatus 820 includes a controller 821, a memory 822, a network interface 823, and a wireless communication interface 825.

[0467] The controller 821 can be, for example, a CPU or a DSP, and operates various functions of a higher layer of the base station apparatus 820. For example, the controller 821 generates data packets from data in a signal processed by the wireless communication interface 825, and transfers the generated packets via the network interface 823. The controller 821 can bundle data from a plurality of baseband processors to generate bundled packets, and transfer the generated bundled packets. The controller 821 can have a logical function of performing control such as radio resource control, radio bearer control, mobility management, admission control, and scheduling. The control can be performed in conjunction with a nearby eNB or a core network node. The memory 822 includes a RAM and a ROM, and stores programs executed by the controller 821 and various types of control data such as a terminal list, transmission power data, and scheduling data.

[0468] The network interface 823 is a communication interface used to connect the base station apparatus 820 to the core network 824. The controller 821 can communicate with a core network node or another eNB via the network interface 823. In this case, the eNB 800 and the core network node or the other eNB can be connected to each other by a logical interface such as an S1 interface and an X2 interface. The network interface 823 can also be a wired communication interface or a wireless communication interface for a wireless backhaul line. If the network interface 823 is a wireless communication interface, the network interface 823 can use a higher frequency band for wireless communication than a frequency band used by the wireless communication interface 825.

[0469] The wireless communication interface 825 supports any cellular communication scheme such as Long Term Evolution (LTE) and LTE-Advanced, and provides wireless connections to terminals located in a cell of the eNB 800 via the antenna 810. The wireless communication interface 825 can typically include, for example, a baseband (BB) processor 826 and an RF circuit 827. The BB processor 826 can perform, for example, encoding / decoding, modulation / demodulation, and multiplexing / demultiplexing, and perform various types of signal processing of layers (e.g., layer 1, medium access control (MAC), radio link control (RLC), and packet data convergence protocol (PDCP)). The BB processor 826 can have a part or all of the logical functions described above instead of the controller 821. The BB processor 826 can be a memory that stores a communication control program, or a module that includes a processor and related circuitry configured to execute the program. Updating the program can cause the functions of the BB processor 826 to change. The module can be a card or a blade that is inserted into a slot of the base station device 820. Alternatively, the module can also be a chip that is mounted on a card or a blade. Meanwhile, the RF circuit 827 can include, for example, a mixer, a filter, and an amplifier, and transmit and receive wireless signals via the antenna 810.

[0470] As illustrated in FIG. 26, the wireless communication interface 825 can include a plurality of BB processors 826. For example, the plurality of BB processors 826 can be compatible with a plurality of frequency bands used by the eNB 800. As illustrated in FIG. 26, the wireless communication interface 825 can include a plurality of RF circuits 827. For example, the plurality of RF circuits 827 can be compatible with a plurality of antenna elements. While FIG. 26 illustrates an example in which the wireless communication interface 825 includes a plurality of BB processors 826 and a plurality of RF circuits 827, the wireless communication interface 825 can also include a single BB processor 826 or a single RF circuit 827.

[0471] The electronic devices 100 and 300, when implemented as the eNB 800 illustrated in FIG. 26, can have their transceivers implemented by the wireless communication interface 825. At least a part of the functions can also be implemented by the controller 821. For example, the controller 821 can perform wireless communication using a task model as an AI model by executing the functions of the units in the electronic devices 100 and 300.

[0472] (Second Application Example)

[0473] FIG. 27 is a block diagram illustrating a second example of a schematic configuration of an eNB or gNB to which the technology of the present disclosure can be applied. Note that, similarly, the following description takes the eNB as an example, but is equally applicable to the gNB. The eNB 830 includes one or plural antennas 840, a base station device 850, and RRHs 860. The RRHs 860 and each of the antennas 840 can be connected to each other via an RF cable. The base station device 850 and the RRHs 860 can be connected to each other via a high-speed line such as an optical fiber cable.

[0474] Each of the antennas 840 includes a single or plural antenna elements (such as plural antenna elements included in a MIMO antenna) and is used for the RRH 860 to transmit and receive a radio signal. As illustrated in FIG. 27, the eNB 830 can include plural antennas 840. For example, the plural antennas 840 can be compatible with plural frequency bands used by the eNB 830. Although FIG. 27 illustrates an example in which the eNB 830 includes plural antennas 840, the eNB 830 can also include a single antenna 840.

[0475] The base station device 850 includes a controller 851, a memory 852, a network interface 853, a wireless communication interface 855, and a connection interface 857. The controller 851, the memory 852, and the network interface 853 are the same as the controller 821, the memory 822, and the network interface 823 described with reference to FIG. 27.

[0476] The wireless communication interface 855 supports any cellular communication scheme such as LTE and LTE-Advanced, and provides wireless communication to terminals located in a sector corresponding to the RRH 860 via the RRH 860 and the antennas 840. The wireless communication interface 855 can typically include, for example, a BB processor 856. The BB processor 856 is the same as the BB processor 826 described with reference to FIG. 27 except that the BB processor 856 is connected to the RF circuit 864 of the RRH 860 via the connection interface 857. As illustrated in FIG. 27, the wireless communication interface 855 can include plural BB processors 856. For example, the plural BB processors 856 can be compatible with plural frequency bands used by the eNB 830. Although FIG. 27 illustrates an example in which the wireless communication interface 855 includes plural BB processors 856, the wireless communication interface 855 can also include a single BB processor 856.

[0477] The connection interface 857 is an interface for connecting the base station device 850 (the wireless communication interface 855) to the RRH 860. The connection interface 857 can also be a communication module for communication in the above-described high-speed line for connecting the base station device 850 (the wireless communication interface 855) to the RRH 860.

[0478] The RRH 860 includes a connectivity interface 861 and a wireless communication interface 863.

[0479] Connection interface 861 is an interface for connecting RRH 860 (wireless communication interface 863) to base station equipment 850. Connection interface 861 can also be a communication module for communication in the aforementioned high-speed line.

[0480] Wireless communication interface 863 transmits and receives wireless signals via antenna 840. Wireless communication interface 863 typically includes, for example, RF circuitry 864. RF circuitry 864 may include, for example, mixers, filters, and amplifiers, and transmits and receives wireless signals via antenna 840. As shown in FIG27, wireless communication interface 863 may include multiple RF circuits 864. For example, multiple RF circuits 864 may support multiple antenna elements. Although FIG27 shows an example in which wireless communication interface 863 includes multiple RF circuits 864, wireless communication interface 863 may also include a single RF circuit 864.

[0481] When electronic devices 100 and 300 are implemented as the eNB 830 shown in FIG. 27, their transceivers can be implemented by wireless communication interface 855. At least a portion of the functionality can also be implemented by controller 851. For example, controller 851 can perform wireless communication using a task model as an AI model by executing the functions of the units in electronic devices 100 and 300.

[0482] [Application examples related to user equipment]

[0483] (First application example)

[0484] Figure 28 is a block diagram illustrating an example of a schematic configuration of a smartphone 900 to which the technology of this disclosure can be applied. The smartphone 900 includes a processor 901, a memory 902, a storage device 903, an external connection interface 904, a camera device 906, a sensor 907, a microphone 908, an input device 909, a display device 910, a speaker 911, a wireless communication interface 912, one or more antenna switches 915, one or more antennas 916, a bus 917, a battery 918, and an auxiliary controller 919.

[0485] The processor 901 can be, for example, a CPU or a system-on-a-chip (SoC), and controls the application layer and other functions of the smartphone 900. The memory 902 includes RAM and ROM, and stores data and programs executed by the processor 901. The storage device 903 can include storage media such as semiconductor memory and hard disks. The external connectivity interface 904 is an interface for connecting external devices, such as memory cards and Universal Serial Bus (USB) devices, to the smartphone 900.

[0486] The camera 906 includes an image sensor such as a charge coupled device (CCD) and a complementary metal oxide semiconductor (CMOS), and generates a captured image. The sensor 907 can include a set of sensors such as a measurement sensor, a gyro sensor, a geomagnetic sensor, and an acceleration sensor. The microphone 908 converts a sound input to the smartphone 900 into an audio signal. The input device 909 includes, for example, a touch sensor configured to detect a touch on a screen of the display device 910, a keypad, a keyboard, a button, or a switch, and receives an operation or information input from a user. The display device 910 includes a screen such as a liquid crystal display (LCD) and an organic light emitting diode (OLED) display, and displays an output image of the smartphone 900. The speaker 911 converts an audio signal output from the smartphone 900 into a sound.

[0487] The wireless communication interface 912 supports any cellular communication scheme such as LTE and LTE-Advanced, and performs wireless communication. The wireless communication interface 912 can generally include, for example, a BB processor 913 and an RF circuit 914. The BB processor 913 can perform, for example, encoding / decoding, modulation / demodulation, and multiplexing / demultiplexing, and perform various types of signal processing for wireless communication. Meanwhile, the RF circuit 914 can include, for example, a mixer, a filter, and an amplifier, and transmit and receive a wireless signal via an antenna 916. Note that, although a case in which one RF link is connected to one antenna is shown in the drawing, this is merely illustrative, and a case in which one RF link is connected to a plurality of antennas through a plurality of phase shifters is also included. The wireless communication interface 912 can be one chip module in which the BB processor 913 and the RF circuit 914 are integrated. As shown in FIG. 28, the wireless communication interface 912 can include a plurality of BB processors 913 and a plurality of RF circuits 914. Although FIG. 28 shows an example in which the wireless communication interface 912 includes a plurality of BB processors 913 and a plurality of RF circuits 914, the wireless communication interface 912 can also include a single BB processor 913 or a single RF circuit 914.

[0488] In addition, the wireless communication interface 912 can support another type of wireless communication scheme in addition to the cellular communication scheme, such as a short-range wireless communication scheme, a near field communication scheme, and a wireless local area network (LAN) scheme. In this case, the wireless communication interface 912 can include a BB processor 913 and an RF circuit 914 for each wireless communication scheme.

[0489] Each of the antenna switches 915 switches a connection destination of the antenna 916 between a plurality of circuits included in the wireless communication interface 912 (for example, circuits for different wireless communication schemes).

[0490] Each of the antennas 916 includes a single or a plurality of antenna elements (such as a plurality of antenna elements included in a MIMO antenna), and is used for the wireless communication interface 912 to transmit and receive wireless signals. As illustrated in FIG. 28, the smartphone 900 can include a plurality of antennas 916. While FIG. 28 illustrates an example in which the smartphone 900 includes a plurality of antennas 916, the smartphone 900 can also include a single antenna 916.

[0491] Furthermore, the smartphone 900 can include an antenna 916 for each wireless communication scheme. In this case, the antenna switch 915 can be omitted from the configuration of the smartphone 900.

[0492] The bus 917 connects the processor 901, the memory 902, the storage 903, the external connection interface 904, the camera 906, the sensor 907, the microphone 908, the input device 909, the display device 910, the speaker 911, the wireless communication interface 912, and the auxiliary controller 919 to one another. The battery 918 supplies power to the respective blocks of the smartphone 900 illustrated in FIG. 28 via feed lines, which are partially illustrated as dotted lines in the figure. The auxiliary controller 919, for example, operates the minimum necessary functions of the smartphone 900 in a sleep mode.

[0493] When the electronic devices 200 and 300 are implemented as, for example, a smartphone on the user device side, such as the smartphone 900 illustrated in FIG. 28, respectively, the transceivers of the electronic devices 200 and 300 can be implemented by the wireless communication interface 912. At least a part of the functions can also be implemented by the processor 901 or the auxiliary controller 919. For example, the processor 901 or the auxiliary controller 919 performs the functions of the units in the electronic devices 200 and 300 described above, using a task model as an AI model, to perform wireless communication.

[0494] (Second Application Example)

[0495] FIG. 29 is a block diagram illustrating an example of a schematic configuration of a car navigation device 920 to which the technology of the present disclosure can be applied. The car navigation device 920 includes a processor 921, a memory 922, a global positioning system (GPS) module 924, a sensor 925, a data interface 926, a content player 927, a storage medium interface 928, an input device 929, a display device 930, a speaker 931, a wireless communication interface 933, one or more antenna switches 936, one or more antennas 937, and a battery 938.

[0496] The processor 921 can be, for example, a CPU or a SoC, and controls a navigation function and another function of the car navigation device 920. The memory 922 includes a RAM and a ROM, and stores data and programs executed by the processor 921.

[0497] The GPS module 924 measures a position (such as latitude, longitude and altitude) of the car navigation device 920 using GPS signals received from GPS satellites. The sensor 925 can include a set of sensors such as a gyro sensor, a geomagnetic sensor and an air pressure sensor. The data interface 926 is connected to, for example, an in-vehicle network 941 via a terminal not shown, and acquires data generated by the vehicle such as vehicle speed data.

[0498] The content player 927 reproduces content stored in a storage medium such as a CD and a DVD, which is inserted into the storage medium interface 928. The input device 929 includes, for example, a touch sensor configured to detect a touch on a screen of the display device 930, a button or a switch, and receives an operation or information input from a user. The display device 930 includes a screen such as an LCD or an OLED display, and displays an image of a navigation function or reproduced content. The speaker 931 outputs a sound of a navigation function or reproduced content.

[0499] The wireless communication interface 933 supports any cellular communication scheme such as LTE and LTE-Advanced, and performs wireless communication. The wireless communication interface 933 can typically include, for example, a BB processor 934 and an RF circuit 935. The BB processor 934 can perform, for example, encoding / decoding, modulation / demodulation and multiplexing / demultiplexing, and perform various types of signal processing for wireless communication. Meanwhile, the RF circuit 935 can include, for example, a mixer, a filter and an amplifier, and transmit and receive wireless signals via an antenna 937. The wireless communication interface 933 can also be one chip module on which the BB processor 934 and the RF circuit 935 are integrated. As shown in FIG. 29, the wireless communication interface 933 can include a plurality of BB processors 934 and a plurality of RF circuits 935. While FIG. 29 shows an example in which the wireless communication interface 933 includes a plurality of BB processors 934 and a plurality of RF circuits 935, the wireless communication interface 933 can also include a single BB processor 934 or a single RF circuit 935.

[0500] In addition, the wireless communication interface 933 can support another type of wireless communication scheme in addition to the cellular communication scheme, such as a short-range wireless communication scheme, a near field communication scheme and a wireless LAN scheme. In this case, the wireless communication interface 933 can include a BB processor 934 and an RF circuit 935 for each wireless communication scheme.

[0501] Each of the antenna switches 936 switches a connection destination of the antenna 937 between a plurality of circuits included in the wireless communication interface 933, such as circuits for different wireless communication schemes.

[0502] Each of the antennas 937 includes a single or multiple antenna elements (such as multiple antenna elements included in a MIMO antenna), and is used for the wireless communication interface 933 to transmit and receive wireless signals. As illustrated in FIG. 29, the car navigation device 920 can include multiple antennas 937. While FIG. 29 illustrates an example in which the car navigation device 920 includes multiple antennas 937, the car navigation device 920 can also include a single antenna 937.

[0503] Further, the car navigation device 920 can include an antenna 937 for each wireless communication scheme. In this case, the antenna switch 936 can be omitted from the configuration of the car navigation device 920.

[0504] The battery 938 supplies power to the various blocks of the car navigation device 920 illustrated in FIG. 29 via feed lines, which are partially illustrated as dotted lines in the figure. The battery 938 accumulates power supplied from the vehicle.

[0505] When the electronic devices 200 and 300 are implemented as, for example, the car navigation device 920 illustrated in FIG. 29 as a user device side, the transceivers of the electronic devices 200 and 300 can be implemented by the wireless communication interface 933. At least a part of the functions can also be implemented by the processor 921. For example, the processor 921 performs wireless communication using a task model as an AI model by executing the functions of the units in the electronic devices 200 and 300 described above.

[0506] The technology of the present disclosure can also be implemented as an in-vehicle system (or vehicle) 940 including one or more of the car navigation device 920, the in-vehicle network 941, and the vehicle module 942. The vehicle module 942 generates vehicle data such as vehicle speed, engine speed, and failure information, and outputs the generated data to the in-vehicle network 941.

[0507] The basic principles of the present application are described above in connection with specific embodiments, but it is to be noted that, for those skilled in the art, it is understood that all or any steps or components of the method and device of the present application can be implemented in any computing device (including processors, storage media, etc.) or network of computing devices in the form of hardware, firmware, software or a combination thereof, which can be implemented by those skilled in the art with their basic circuit design knowledge or basic programming skills after reading the description of the present application.

[0508] Furthermore, the present application also proposes a program product storing machine-readable instruction codes. The instruction codes are read and executed by a machine to perform the above-mentioned method according to the embodiments of the present application.

[0509] Accordingly, a storage medium for carrying the program product storing the machine-readable instruction code described above is also included in the present disclosure. The storage medium includes, but is not limited to, a floppy disk, an optical disk, a magneto-optical disk, a memory card, a memory stick, and the like.

[0510] In the case where the present application is implemented by software or firmware, a program constituting the software is installed from a storage medium or a network to a computer having a special hardware structure, such as a general-purpose computer 3000 shown in FIG. 30, which is capable of executing various functions when various programs are installed.

[0511] In FIG. 30, a central processing unit (CPU) 3001 performs various processes according to a program stored in a read-only memory (ROM) 3002 or a program loaded from a storage section 3008 to a random access memory (RAM) 3003. In the RAM 3003, data required when the CPU 3001 performs various processes and the like is also stored as necessary. The CPU 3001, the ROM 3002, and the RAM 3003 are connected to each other via a bus 3004. An input / output interface 3005 is also connected to the bus 3004.

[0512] The following components are connected to the input / output interface 3005: an input section 3006 (including a keyboard, a mouse, and the like), an output section 3007 (including a display such as a cathode ray tube (CRT), a liquid crystal display (LCD), and the like, and a speaker, and the like), a storage section 3008 (including a hard disk, and the like), a communication section 3009 (including a network interface card such as a LAN card, a modem, and the like). The communication section 3009 performs communication processing via a network such as the Internet. A drive 3010 can also be connected to the input / output interface 3005 as necessary. A removable medium 3011 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, and the like is installed in the drive 3010 as necessary, so that a computer program read therefrom is installed in the storage section 3008 as necessary.

[0513] In the case where the above series of processes are implemented by software, a program constituting the software is installed from a network such as the Internet or a storage medium such as the removable medium 3011.

[0514] It is understood by those skilled in the art that such storage media are not limited to the removable media 3011 shown in Fig. 30 in which the programs are stored and distributed separately from the apparatus to provide the programs to users. Examples of the removable media 3011 include magnetic disks (including floppy disks (registered trademark)), optical disks (including compact disc read only memory (CD-ROM) and digital versatile disk (DVD)), magneto-optical disks (including mini disks (MD) (registered trademark)), and semiconductor memories. Alternatively, the storage media can be the ROM 3002, the hard disk included in the storage section 3008, or the like in which the programs are stored and distributed to users together with the apparatuses including them.

[0515] It is also to be noted that in the apparatus, method, and system of the present application, each component or step can be decomposed and / or recombined. Such decomposition and / or recombination should be considered as equivalents of the present application. Also, the steps of performing the above-described series of processes can naturally be executed in the order of the description, but do not necessarily have to be executed in the order of time. Some steps can be executed in parallel or independently of each other.

[0516] Finally, it is to be noted that the terms "comprising", "including", or any other variant thereof are intended to cover non-exclusive inclusions, so that processes, methods, articles, or apparatuses including a series of elements not only include those elements, but also include other elements not explicitly listed or inherent to such processes, methods, articles, or apparatuses. In addition, without more restrictions, the element defined by the phrase "including a" does not exclude the presence of another identical element in the process, method, article, or apparatus including the element.

[0517] Although the embodiments of the present application have been described in detail above with reference to the accompanying drawings, it is to be understood that the above-described embodiments are merely for the purpose of illustration of the present application and do not constitute a limitation of the present application. Various modifications and changes can be made to the above-described embodiments without departing from the spirit and scope of the present application. Therefore, the scope of the present application is only limited by the appended claims and their equivalents.

[0518] The present technology can also be implemented as follows. Scheme 1. An electronic device for wireless communication, comprising: at least one processor; and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: indicating, for a task model of a user device side for implementing a task, a monitoring format to be employed by the user device for monitoring the task model based on a channel condition in which the user device is located and / or capability information representing a capability of the user device. Scheme 2. The electronic device of scheme 1, wherein the monitoring format is a first monitoring format or a second monitoring format, wherein in the first monitoring format, multiple monitoring is performed by multiplexing at least part of historical measurement information for the task, and in the second monitoring format, for multiple monitoring, measurement information for the task used for each monitoring does not overlap. Scheme 3. The electronic device of scheme 2, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: in a case where the first monitoring format is indicated to the user device, indicating time domain information of the multiplexed at least part of historical measurement information in time domain, wherein the time domain information comprises a starting point of the multiplexed at least part of historical measurement information in time domain and a length of the multiplexed at least part of historical measurement information in time domain. Scheme 4. The electronic device of scheme 2 or 3, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: in a case where it is determined based on the channel condition that a channel is a slow fading channel, indicating the first monitoring format to the user device, and in a case where it is determined based on the channel condition that a channel is a fast fading channel, indicating the second monitoring format to the user device. Scheme 5. The electronic device of any one of schemes 1 to 4, wherein the channel condition comprises channel state information, CSI. Scheme 6. The electronic device of scheme 2 or 3, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: in a case where the capability information satisfies a predetermined condition, indicating the first monitoring format to the user device, and in a case where the capability information does not satisfy the predetermined condition, indicating the second monitoring format to the user device. Scheme 7. The electronic device of any one of schemes 1 to 6, wherein the user device performs the task model N times by multiplexing part of historical measurement information for the task to obtain N execution results, and judges stability of the task model based on the execution results to perform inference on the task model, wherein N is a positive integer greater than 1.Scheme 8. The electronic device according to scheme 7, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: in a case where the result of the inference indicates that the stability of the task model is less than a predetermined stability threshold, receiving an event reported by the user device reflecting that the stability is less than the predetermined stability threshold, and deciding whether to trigger the monitoring of the task model based on the event. Scheme 9. The electronic device according to scheme 7, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: specifying a predetermined number of times for the user device to perform the task model in the inference, wherein the predetermined number of times is greater than or equal to N. Scheme 10. The electronic device according to any one of schemes 1 to 9, wherein the task comprises predicting a beam, and the task model comprises a beam prediction model for predicting the beam. Scheme 11. The electronic device according to scheme 10, wherein performing multiple beam predictions with the beam prediction model to perform multiple monitoring of the prediction accuracy of the beam prediction model to improve the prediction accuracy of the beam prediction model for a future candidate beam. Scheme 12. The electronic device according to any one of schemes 1 to 11, wherein the task model is a multi-task model for simultaneously implementing multiple tasks, and the multi-task model comprises a shared parameter model sharing model parameters by the multiple tasks and model branches respectively corresponding to at least part of the multiple tasks. Scheme 13. The electronic device according to scheme 12, wherein the shared parameter model extracts a shared representation shared by the multiple tasks from input data, and each model branch is used to determine a mapping from the shared representation to a label of a task corresponding to the model branch. Scheme 14. An electronic device for wireless communication, comprising: at least one processor; and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: receiving, for a task model of the electronic device side for implementing a task, an indication from a network side device about a monitoring format to be adopted for monitoring the task model, wherein the monitoring format is determined by the network side device based on channel conditions of the electronic device and / or capability information representing a capability of the electronic device. Scheme 15. The electronic device according to scheme 14, wherein the monitoring format is a first monitoring format or a second monitoring format, wherein in the first monitoring format, multiple monitoring is performed by multiplexing at least part of historical measurement information for the task, and in the second monitoring format, for multiple monitoring, measurement information for the task used for each monitoring does not overlap.Scheme 16. The electronic device according to scheme 15, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: receiving, in case of receiving the indication about the first monitoring format from the network-side device, an indication about time domain information of at least a part of the multiplexed historical measurement information in time domain, wherein the time domain information comprises a starting point of the at least a part of the multiplexed historical measurement information in time domain and a length of the at least a part of the multiplexed historical measurement information in time domain. Scheme 17. The electronic device according to scheme 15 or 16, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: receiving the indication about the first monitoring format from the network-side device in case the network-side device determines, based on the channel condition, that the channel is a slow fading channel, and receiving the indication about the second monitoring format from the network-side device in case the network-side device determines, based on the channel condition, that the channel is a fast fading channel. Scheme 18. The electronic device according to any one of schemes 14 to 17, wherein the channel condition comprises channel state information, CSI. Scheme 19. The electronic device according to scheme 15 or 16, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: receiving the indication about the first monitoring format from the network-side device in case the capability information satisfies a predetermined condition, and receiving the indication about the second monitoring format from the network-side device in case the capability information does not satisfy the predetermined condition. Scheme 20. The electronic device according to any one of schemes 14 to 19, wherein performing the task model N times by multiplexing part of historical measurement information for the task to obtain N execution results, and determining stability of the task model based on the execution results to make an inference of the task model, wherein N is a positive integer greater than 1. Scheme 21. The electronic device according to scheme 20, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: in case the result of the inference indicates that the stability of the task model is less than a predetermined stability threshold, reporting an event reflecting that the stability is less than the predetermined stability threshold to the network-side device for the network-side device to decide whether to trigger monitoring of the task model based on the event.Scheme 22. The electronic device according to scheme 20, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: receiving, from the network-side device, a specification of a predetermined number of times of performing the task model in the inference, wherein the predetermined number of times is greater than or equal to N. Scheme 23. The electronic device according to any one of schemes 14 to 22, wherein the task comprises predicting a beam, and the task model comprises a beam prediction model for predicting a beam. Scheme 24. The electronic device according to scheme 23, wherein performing multiple times of beam prediction with the beam prediction model to monitor a prediction accuracy of the beam prediction model multiple times to improve a prediction accuracy of the beam prediction model on a future candidate beam. Scheme 25. The electronic device according to any one of schemes 14 to 24, wherein the task model is a multi-task model for simultaneously implementing multiple tasks, and the multi-task model comprises a shared parameter model sharing model parameters by the multiple tasks and model branches respectively corresponding to at least part of the multiple tasks. Scheme 26. The electronic device according to scheme 25, wherein the shared parameter model extracts a shared representation shared by the multiple tasks from input data, and each model branch is configured to determine a mapping from the shared representation to a label of a task corresponding to the model branch. Scheme 27. An electronic device for wireless communication, comprising: at least one processor; and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: simultaneously implementing multiple tasks by a multi-task model, wherein the multi-task model comprises a shared parameter model sharing model parameters by the multiple tasks and model branches respectively corresponding to at least part of the multiple tasks. Scheme 28. The electronic device according to scheme 27, wherein the shared parameter model extracts a shared representation shared by the multiple tasks from input data, and each model branch is configured to determine a mapping from the shared representation to a label of a task corresponding to the model branch. Scheme 29. The electronic device according to scheme 27 or 28, wherein tasks are grouped based on a correlation between tasks, wherein tasks within each group are implemented via a corresponding multi-task model, wherein the correlation is obtained based on at least one of prior information of the correlation between tasks, coordination information between tasks, and matching degree between tasks. Scheme 30. The electronic device according to any one of schemes 27 to 29, wherein the same input data is employed for the multiple tasks implemented by the multi-task model. Scheme 31. The electronic device according to scheme 30, wherein the input data is determined according to at least one of a requirement of a task, a capability of a node related to the task, and a data collection overhead.Scheme 32. The electronic device according to scheme 31, wherein the requirement of the task comprises a time sampling period, the capability of the node comprises at least one of availability of node data, quality of node data, matching degree of node data with different tasks, quality requirement of node data by different tasks, and the data collection overhead comprises collection overhead of data of a predetermined quality. Scheme 33. The electronic device according to scheme 30, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: based on the result of unifying the input data, confirming model information of the multi-task model, thereby simultaneously performing model confirmation on the multiple tasks. Scheme 34. The electronic device according to any one of schemes 27 to 29, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: based on a model ID included in the model activation information or the model deactivation information, notifying a multi-task model corresponding to the model ID of a task ID to be activated or deactivated, and based on the task ID, activating or deactivating a model branch corresponding to the task ID in the corresponding multi-task model. Scheme 35. The electronic device according to any one of schemes 27 to 29, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: based on classification of performance degradation scenarios of the multiple tasks, implementing update of the multi-task model by at least one of update of quality of input data of the multi-task model, update of quality of auxiliary data of the multi-task model, and update of model parameters of the multi-task model. Scheme 36. The electronic device according to any one of schemes 27 to 29, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: cooperating with other electronic devices to implement at least part of the multiple tasks, wherein input data of a multi-task model at the other electronic devices is the same as or different from input data of a multi-task model at the electronic device.Scheme 37. The electronic device according to any one of schemes 27 to 36, wherein, in case that the electronic device is a network-side device: for a multi-task model at a user equipment side, indicating, based on channel conditions at the user equipment and / or capability information indicative of capabilities of the user equipment, a monitoring format to be employed by the user equipment for monitoring the multi-task model, and in case that the electronic device is a user equipment: for a multi-task model at the electronic device side, receiving, from a network-side device, an indication on a monitoring format to be employed for monitoring the multi-task model, wherein the monitoring format is determined by the network-side device based on channel conditions at the electronic device and / or capability information indicative of capabilities of the electronic device. Scheme 38. The electronic device according to scheme 37, wherein the monitoring format is a first monitoring format or a second monitoring format, wherein in the first monitoring format, multiple monitoring is performed by multiplexing at least part of historical measurement information for the multiple tasks, and in the second monitoring format, for multiple monitoring, measurement information used for each monitoring does not overlap. Scheme 39. A method for wireless communications, comprising: for a task model at a user equipment side for implementing a task, indicating, based on channel conditions at the user equipment and / or capability information indicative of capabilities of the user equipment, a monitoring format to be employed by the user equipment for monitoring the task model. Scheme 40. A method for wireless communications, comprising: for a task model at an electronic device side for implementing a task, receiving, from a network-side device, an indication on a monitoring format to be employed for monitoring the task model, wherein the monitoring format is determined by the network-side device based on channel conditions at the electronic device and / or capability information indicative of capabilities of the electronic device. Scheme 41. A method for wireless communications, comprising: implementing multiple tasks simultaneously through a multi-task model, wherein the multi-task model comprises a shared parameter model shared by the multiple tasks and model branches respectively corresponding to at least part of the multiple tasks. Scheme 42. A computer-readable storage medium having computer-executable instructions stored thereon, which when executed, perform the method according to any one of schemes 39 to 41.

Claims

An electronic device for wireless communication, comprising: at least one processor; and at least one memory including computer program codes, wherein the at least one memory and the computer program codes are configured to, with the at least one processor, cause the electronic device to perform: indicating, for a task model of a task at a user equipment side, a monitoring format to be adopted by the user equipment for monitoring the task model, based on a channel condition in which the user equipment is located and / or capability information representing a capability of the user equipment. According to claim 1, wherein, the monitoring format is a first monitoring format or a second monitoring format, wherein, in the first monitoring format, multiple monitoring is performed by multiplexing at least part of historical measurement information for the task, and in the second monitoring format, for multiple monitoring, measurement information for the task used for each monitoring does not overlap. The electronic device of claim 2, wherein, the at least one memory and the computer program codes are configured to, with the at least one processor, cause the electronic device to perform: in a case where the first monitoring format is indicated to the user equipment, indicating time domain information of the multiplexed at least part of historical measurement information in time domain, wherein the time domain information comprises a starting point of the multiplexed at least part of historical measurement information in time domain and a length of the multiplexed at least part of historical measurement information in time domain. The electronic device according to claim 2 or 3, wherein the at least one memory and the computer program codes are configured to, with the at least one processor, cause the electronic device to perform: in a case where it is determined based on the channel condition that the channel is a slow fading channel, indicating the first monitoring format to the user equipment, and in a case where it is determined based on the channel condition that the channel is a fast fading channel, indicating the second monitoring format to the user equipment. The electronic device of any one of claims 1 to 4, wherein the channel condition comprises channel state information, CSI. The electronic device according to claim 2 or 3, wherein the at least one memory and the computer program codes are configured to, with the at least one processor, cause the electronic device to perform: in a case where the capability information satisfies a predetermined condition, indicating the first monitoring format to the user equipment, and in a case where the capability information does not satisfy the predetermined condition, indicating the second monitoring format to the user equipment. According to any one of claims 1 to 6, wherein, the user equipment performs the task model N times by multiplexing part of historical measurement information for the task to obtain N execution results, and judges stability of the task model based on the execution results to make an inference on the task model, wherein N is a positive integer greater than 1. The electronic device of claim 7, wherein, the at least one memory and the computer program codes are configured to, with the at least one processor, cause the electronic device to perform: in a case where a result of the inference indicates that the stability of the task model is less than a predetermined stability threshold, receiving an event reported by the user equipment reflecting that the stability is less than the predetermined stability threshold, and deciding whether to trigger monitoring of the task model based on the event. The electronic device of claim 7, wherein, The at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: specifying, for the user device, a predetermined number of times of performing the task model in the inference, wherein the predetermined number of times is greater than or equal to N. The electronic device of any one of claims 1-9, wherein the task comprises predicting a beam, and the task model comprises a beam prediction model for predicting the beam. The electronic device according to claim 10, wherein a plurality of times of beam prediction is performed using the beam prediction model to perform a plurality of times of monitoring of prediction accuracy of the beam prediction model, so as to improve prediction accuracy of the beam prediction model on a future candidate beam. The electronic device according to any one of claims 1 to 11, wherein the task model is a multi-task model for simultaneously implementing a plurality of tasks, and the multi-task model comprises a shared parameter model shared by the plurality of tasks and a model branch respectively corresponding to at least part of the plurality of tasks. The electronic device according to claim 12, wherein the shared parameter model extracts a shared representation shared by the plurality of tasks from input data, and each model branch is used to determine a mapping from the shared representation to a label of a task corresponding to the model branch. An electronic device for wireless communication, comprising: at least one processor; and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: receiving, from a network side device, an indication about a monitoring format to be adopted for monitoring a task model for implementing a task at the electronic device side, wherein the monitoring format is determined by the network side device based on channel conditions at which the electronic device is located and / or capability information representing capability of the electronic device. The electronic device according to claim 14, wherein the monitoring format is a first monitoring format or a second monitoring format, wherein in the first monitoring format, a plurality of times of monitoring is performed by multiplexing at least part of historical measurement information for the task, and in the second monitoring format, for the plurality of times of monitoring, measurement information for the task used in each time of monitoring does not overlap. The electronic device of claim 15, wherein, The at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: in a case where the indication about the first monitoring format is received from the network side device, an indication about time domain information of at least part of the multiplexed historical measurement information in time domain is also received, wherein the time domain information comprises a starting point of the at least part of the multiplexed historical measurement information in time domain and a length of the at least part of the multiplexed historical measurement information in time domain. The electronic device of claim 15 or 16, wherein, The at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: in a case where the network-side device determines, based on the channel condition, that the channel is a slow-fading channel, receiving, from the network-side device, an indication about the first monitoring format, and in a case where the network-side device determines, based on the channel condition, that the channel is a fast-fading channel, receiving, from the network-side device, an indication about the second monitoring format. The electronic device of any one of claims 14-17, wherein The channel condition comprises channel state information, CSI. The electronic device of claim 15 or 16, wherein, The at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: in a case where the capability information satisfies a predetermined condition, receiving, from the network-side device, an indication about the first monitoring format, and in a case where the capability information does not satisfy the predetermined condition, receiving, from the network-side device, an indication about the second monitoring format. According to any one of claims 14 to 19, wherein the inference on the task model is performed by executing the task model N times with multiplexing partial historical measurement information for the task, and determining the stability of the task model based on the execution results, wherein N is a positive integer greater than 1. The electronic device of claim 20, wherein, The at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: in a case where the result of the inference indicates that the stability of the task model is less than a predetermined stability threshold, reporting, to the network-side device, an event reflecting that the stability is less than the predetermined stability threshold, for the network-side device to decide whether to trigger monitoring on the task model based on the event. The electronic device of claim 20, wherein, The at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: receiving, from the network-side device, a specification of a predetermined number of times of executing the task model in the inference, wherein the predetermined number of times is greater than or equal to N. The electronic device of any one of claims 14-22, wherein The task comprises predicting a beam, and the task model comprises a beam prediction model for predicting the beam. According to claim 23, wherein a plurality of times of beam prediction is performed with the beam prediction model to monitor a prediction accuracy of the beam prediction model a plurality of times, to improve the prediction accuracy of the beam prediction model on a future candidate beam. According to any one of claims 14 to 24, wherein the task model is a multi-task model for simultaneously implementing a plurality of tasks, and the multi-task model comprises a shared parameter model sharing model parameters by the plurality of tasks, and model branches respectively corresponding to at least part of the plurality of tasks. According to claim 25, wherein the shared parameter model extracts a shared representation shared by the plurality of tasks from input data, and each model branch is used to determine a mapping from the shared representation to a label of a task corresponding to the model branch. An electronic device for wireless communication, comprising: at least one processor; and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: implementing multiple tasks simultaneously through a multi-task model, wherein the multi-task model comprises a shared parameter model shared by the multiple tasks and model branches respectively corresponding to at least part of the multiple tasks. According to claim 27, wherein the shared parameter model extracts a shared representation shared by the multiple tasks from input data, and each model branch is used to determine a mapping from the shared representation to a label of a task corresponding to the model branch. According to claim 27 or 28, wherein tasks are grouped based on a correlation between tasks, wherein tasks within each group are implemented via a corresponding multi-task model, wherein the correlation is obtained based on at least one of prior information of the correlation between tasks, coordination information between tasks, and matching degree between tasks. The electronic device of any one of claims 27-29, wherein The same input data is used for the multiple tasks implemented by the multi-task model. The electronic device of claim 30, wherein The input data is determined according to at least one of a requirement of a task, a capability of a node related to the task, and a data collection overhead. According to claim 31, wherein the requirement of the task comprises a time sampling period, the capability of the node comprises at least one of availability of node data, quality of node data, matching degree of node data to different tasks, and quality requirement of different tasks to node data, and the data collection overhead comprises a collection overhead of data of a predetermined quality. The electronic device of claim 30, wherein The at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: based on a result of unifying the input data, confirming model information of the multi-task model, thereby simultaneously model authenticating the multiple tasks. The electronic device of any one of claims 27-29, wherein The at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: based on a model ID included in model activation information or model deactivation information, notifying a multi-task model corresponding to the model ID of a task ID to be activated or deactivated, and based on the task ID, activating or deactivating a model branch corresponding to the task ID in the corresponding multi-task model. The electronic device of any one of claims 27-29, wherein The at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: based on classification of performance degradation scenarios of the multiple tasks, implementing an update of the multi-task model through at least one of an update of quality of input data of the multi-task model, an update of quality of auxiliary data of the multi-task model, and an update of model parameters of the multi-task model. The electronic device of any one of claims 27-29, wherein The at least one memory and the computer program code are configured to, with the at least one processor, cause the electronic device to perform: cooperating with other electronic devices to implement at least part of the multiple tasks, The input data of the multi-task model at the other electronic device is the same as or different from the input data of the multi-task model at the electronic device. The electronic device according to any one of claims 27-36, wherein In a case where the electronic device is a network-side device: For a multi-task model at a user equipment side, based on a channel condition in which the user equipment is located and / or capability information representing a capability of the user equipment, an indication of a monitoring format to be adopted by the user equipment for monitoring the multi-task model is determined, and In a case where the electronic device is a user equipment: For a multi-task model at the electronic device side, an indication of a monitoring format to be adopted for monitoring the multi-task model is received from a network-side device, wherein the monitoring format is determined by the network-side device based on a channel condition in which the electronic device is located and / or capability information representing a capability of the electronic device. The electronic device according to claim 37, wherein The monitoring format is a first monitoring format or a second monitoring format, wherein in the first monitoring format, a plurality of monitoring is performed by multiplexing at least part of historical measurement information for the plurality of tasks, and in the second monitoring format, for a plurality of monitoring, the measurement information used by each monitoring does not overlap. A method for wireless communication, comprising: For a task model at a user equipment side for implementing a task, based on a channel condition in which the user equipment is located and / or capability information representing a capability of the user equipment, an indication of a monitoring format to be adopted by the user equipment for monitoring the task model is determined. A method for wireless communication, comprising: For a task model at an electronic device side for implementing a task, an indication of a monitoring format to be adopted for monitoring the task model is received from a network-side device, wherein the monitoring format is determined by the network-side device based on a channel condition in which the electronic device is located and / or capability information representing a capability of the electronic device. A method for wireless communication, comprising: A plurality of tasks are implemented simultaneously by a multi-task model, wherein the multi-task model comprises a shared parameter model shared by the plurality of tasks and model branches respectively corresponding to at least part of the plurality of tasks. A computer-readable storage medium having stored thereon computer-executable instructions which, when executed, perform the method according to any one of claims 39-41.

Images