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

Abstract

The invention relates to an electronic device and method for wireless communication, and a computer readable storage medium. An electronic device for wireless communication includes at least one processor and at least one memory, the at least one memory including computer program code, and wherein the at least one memory and the computer program code are configured to, via the at least one processor, transmit the at least one memory to the at least one processor. The electronic equipment executes the following steps: aiming at a task model used for realizing a task at a user equipment side, based on a channel condition of the user equipment and / or capability information representing the capability of the user equipment, indicating a monitoring format to be adopted by the user equipment and used for monitoring the task model.

Description

Technical Field

[0001] This disclosure relates to the field of wireless communication technology, and more particularly to electronic devices and methods for wireless communication. More specifically, it relates to electronic devices and methods for wireless communication that use a task model as an AI model for wireless communication. Background Technology

[0002] Given the powerful adaptive-nonlinear fitting capabilities of artificial intelligence (AI) and machine learning (ML), the organic integration of AI or ML with wireless communication has become one of the key directions for 6G. For example, compared to traditional model-driven methods, data-driven AI has two significant advantages in wireless communication. Firstly, AI can adaptively learn high-dimensional features of the wireless environment from massive amounts of data without requiring explicit prior knowledge of the wireless environment. Secondly, AI possesses a vast number of learnable parameters and numerous nonlinear activation layers, enabling it to effectively model complex nonlinear relationships. Based on this, 3GPP has conducted standardization discussions on using AI to assist wireless communication for three typical NR (New Radio) functions: CSI feedback, beam management, and user positioning.

[0003] The purpose of monitoring AI or ML models is to determine whether the model's accuracy meets current requirements. How to more effectively monitor AI or ML models is currently a hot research topic. Additionally, how to more effectively construct AI or ML models is also a current research focus. Summary of the Invention

[0004] A brief overview of the invention is given below to provide a basic understanding of certain aspects of it. It should be understood that this overview is not an exhaustive summary of the invention. It is not intended to identify key or essential parts of the invention, nor is it intended to limit the scope of the invention. Its purpose is merely to present certain concepts in a simplified form as a prelude to the more detailed description that follows.

[0005] According to one aspect of this disclosure, an electronic device for wireless communication is provided, 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, through the at least one processor, to cause the electronic device to execute: a task model for implementing a task on the user equipment side, and, based on the channel conditions in which the user equipment is located and / or capability information representing the capabilities of the user equipment, an instruction for the user equipment to adopt a monitoring format for monitoring the task model.

[0006] According to one aspect of this disclosure, an electronic device for wireless communication is provided, 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, through the at least one processor, to cause the electronic device to perform: receiving from a network-side device an indication of a monitoring format to be adopted for monitoring the task model, for a task model on the electronic device side for implementing a task, wherein the monitoring format is determined by the network-side device based on the channel conditions in which the electronic device is located and / or capability information representing the capabilities of the electronic device.

[0007] According to one aspect of this disclosure, an electronic device for wireless communication is provided, 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 cause the electronic device to perform, via the at least one processor, the following: simultaneously implementing multiple tasks through a multi-task model, wherein the multi-task model includes a shared parameter model whose model parameters are shared by the multiple tasks and model branches corresponding to at least a portion of the multiple tasks.

[0008] According to one aspect of this disclosure, a method for wireless communication is provided, comprising: for a task model on the user equipment side for performing a task, instructing the user equipment to adopt a monitoring format for monitoring the task model, based on the channel conditions in which the user equipment is located and / or capability information representing the capabilities of the user equipment.

[0009] According to one aspect of this disclosure, a method for wireless communication is provided, comprising: receiving from a network-side device an indication of a monitoring format to be adopted for monitoring the task model, for a task model on the electronic device side for performing a task, wherein the monitoring format is determined by the network-side device based on channel conditions in which the electronic device is located and / or capability information representing the capabilities of the electronic device.

[0010] According to one aspect of this disclosure, a method for wireless communication is provided, comprising: simultaneously implementing multiple tasks through a multi-task model, wherein the multi-task model includes a shared parameter model in which model parameters are shared by the multiple tasks, and model branches corresponding to at least a portion of the multiple tasks.

[0011] According to other aspects of the present invention, computer program code and computer program product for implementing the above methods, as well as a computer-readable storage medium having the computer program code for implementing the above methods recorded thereon, are also provided. Attached Figure Description

[0012] To further illustrate the above and other advantages and features of the present invention, specific embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. The accompanying drawings, together with the following detailed description, are included in and form a part of this specification. Elements having the same function and structure are indicated by the same reference numerals. It should be understood that these drawings only depict typical examples of the invention and should not be construed as limiting the scope of the invention. In the drawings:

[0013] Figure 1 An exemplary functional block diagram of an electronic device for wireless communication according to an embodiment of the present disclosure is shown;

[0014] Figure 2 This is a diagram illustrating an example of time-domain beam prediction;

[0015] Figure 3 A diagram illustrating an example of beam prediction using a first monitoring format according to an embodiment of the present disclosure is shown;

[0016] Figure 4 A diagram illustrating an example of beam prediction using a second monitoring format according to an embodiment of the present disclosure is shown;

[0017] Figure 5 A diagram illustrating an example of reusing historical measurement data in the inference of a model according to an embodiment of the present disclosure;

[0018] Figure 6 A diagram illustrating an example of the signaling flow during inference in a beam prediction model according to an embodiment of the present disclosure, under stable model performance conditions;

[0019] Figure 7 A diagram illustrating an example of the signaling flow in the case of model prediction failure during inference of a beam prediction model according to an embodiment of the present disclosure;

[0020] Figure 8 An exemplary functional block diagram of an electronic device for wireless communication according to another embodiment of the present disclosure is shown;

[0021] Figure 9 An exemplary functional block diagram of an electronic device for wireless communication according to yet another embodiment of the present disclosure is shown;

[0022] Figure 10 This is a diagram illustrating an example framework of a multitasking model according to embodiments of the present disclosure;

[0023] Figure 11 This is a first example flow illustrating model authentication for multi-task learning according to an embodiment of the present disclosure;

[0024] Figure 12This is an example illustrating a task list according to an embodiment of this disclosure;

[0025] Figure 13 This is an example illustrating a list of datasets according to embodiments of this disclosure;

[0026] Figure 14 This illustrates an example flow of model activation / deactivation for multi-task learning according to embodiments of the present disclosure;

[0027] Figure 15 This is a first example flow illustrating model detection and model updating for multi-task learning according to an embodiment of the present disclosure;

[0028] Figure 16 This is a second example flow illustrating model detection and model updating for multi-task learning according to embodiments of the present disclosure;

[0029] Figure 17 This is a third example flow illustrating model detection and model updating for multi-task learning according to embodiments of the present disclosure;

[0030] Figure 18 This illustrates a process for multi-task, multi-base station collaboration according to embodiments of the present disclosure;

[0031] Figure 19 An example of the model training and model distribution process for a multi-task dual-end model according to an embodiment of the present disclosure is shown;

[0032] Figure 20 An example flow diagram of model inference for a multi-task dual-end model according to an embodiment of the present disclosure is shown;

[0033] Figure 21 This is a graph showing a comparison of beam prediction accuracy between a multi-task model and a single-task model dedicated to beam prediction.

[0034] Figure 22 This is a graph that shows a comparison of the average localization error between a multi-task model and a single-task model dedicated to localization.

[0035] Figure 23 A flowchart of a method for wireless communication according to an embodiment of the present disclosure is shown;

[0036] Figure 24 A flowchart of a method for wireless communication according to another embodiment of the present disclosure is shown;

[0037] Figure 25 A flowchart of a method for wireless communication according to yet another embodiment of the present disclosure is shown;

[0038] Figure 26This is a block diagram illustrating a first example of a schematic configuration of an eNB or gNB to which the technologies of this disclosure can be applied;

[0039] Figure 27 This is a block diagram illustrating a second example of a schematic configuration of an eNB or gNB to which the technologies of this disclosure can be applied;

[0040] Figure 28 This is a block diagram illustrating an example of a schematic configuration of a smartphone to which the technologies of this disclosure can be applied;

[0041] Figure 29 This is a block diagram illustrating an example of a schematic configuration of a car navigation device to which the technology of this disclosure can be applied; and

[0042] Figure 30 This is a block diagram of an exemplary structure of a general-purpose personal computer in which methods and / or apparatus and / or systems according to embodiments of the present invention can be implemented. Detailed Implementation

[0043] Exemplary embodiments of the invention will be described below with reference to the accompanying drawings. For clarity and brevity, not all features of actual implementations are described in the specification. However, it should be understood that many implementation-specific decisions must be made in the development of any such actual embodiment to achieve the developer’s specific goals, such as complying with constraints related to the system and business, and these constraints may vary depending on the implementation. Furthermore, it should be understood that while development work can be very complex and time-consuming, such development work is merely a routine task for those skilled in the art who benefit from this disclosure.

[0044] It should also be noted that, in order to avoid obscuring the invention with unnecessary details, only the device structure and / or processing steps closely related to the solution according to the invention are shown in the accompanying drawings, while other details that are not closely related to the invention are omitted.

[0045] This disclosure provides an electronic device for wireless communication according to one embodiment of the disclosure. The electronic device includes at least one processor and at least one memory, the at least one memory including computer program code, wherein the at least one memory and the computer program code are configured, via the at least one processor, to cause the electronic device to perform: for a task model on the user equipment side for implementing a task, based on the channel conditions in which the user equipment is located and / or capability information representing the capabilities of the user equipment, instructing the user equipment to adopt a monitoring format for monitoring the task model.

[0046] Figure 1An exemplary functional block diagram of an electronic device 100 for wireless communication according to an embodiment of the present disclosure is shown.

[0047] like Figure 1 As shown, the electronic device 100 includes: a control unit 101 for control; and a processing unit 103, which can be configured, under the control of the control unit 101, to instruct the user equipment to adopt a monitoring format for monitoring the task model based on the channel conditions of the user equipment and / or capability information representing the capabilities of the user equipment, for the task model used to perform the task on the user equipment side.

[0048] The control unit 101 and processing unit 103 can be implemented as one or more processing circuits and at least one memory. The processing circuits can be, for example, a processor or a chip, and the at least one memory can be RAM, ROM, etc. The at least one memory is used, for example, to store computer program code and data required for the processing circuits to perform processing. Furthermore, it should be understood that... Figure 1 The functional units in the electronic device 100 shown are logical modules divided according to the specific functions they implement, rather than being used to limit the specific implementation method.

[0049] Electronic device 100 may be located on the base station side or communicatively connected to the base station. For example, electronic device 100 may function as the base station itself and may also include external devices such as memory and transceiver (not shown). Memory may be used to store programs and related data information that electronic device 100 needs to execute to perform various functions. Transceiver may include one or more communication interfaces to support communication with different devices (e.g., UE, base station, etc.), and the implementation of transceiver is not specifically limited here.

[0050] As an example, the base station could be an eNB or a gNB. In the following description, we will typically use a gNB as the base station.

[0051] The electronic device 100 according to embodiments of this disclosure can instruct the user equipment to adopt different monitoring formats for monitoring the task model, depending on different circumstances. For example, the electronic device 100 can instruct the monitoring format based on the channel conditions of the user equipment and / or capability information representing the capabilities of the user equipment.

[0052] As an example, channel conditions include channel state information (CSI). For instance, channel conditions can be characterized by measurements of the resource set used for monitoring (e.g., L1-RSRP and / or reference signal (RS) index). Other examples of channel conditions will be apparent to those skilled in the art, and will not be elaborated here.

[0053] As an example, capability information includes information about the capabilities of the AI ​​model carried by the user equipment (e.g., applicable input beam configurations, beamwidth, number of beams, beam index, etc.), and / or information about the user's own capabilities (e.g., antenna capabilities, beam measurement accuracy (i.e., the accuracy and number of beams that can be measured), and the maximum number of beams that can be measured, etc.). Other examples of capability information that those skilled in the art will recognize will not be elaborated here.

[0054] As an example, the task includes beam prediction, and the task model includes a beam prediction model for beam prediction. Other examples of task models may be conceived by those skilled in the art, which will not be elaborated here. For ease of description, the task model is described below as a beam prediction model, and sometimes the task model is simply referred to as a model or an AI model. Those skilled in the art will understand that the task model can also be an ML model.

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

[0056] After the model monitoring mechanism is triggered, resources need to be allocated to the UE for measurement. In the embodiments according to this disclosure, after the model monitoring mechanism is started, the prediction accuracy of the model is calculated by comparing the prediction results based on the AI ​​model with the measurement results of the non-AI model, thereby achieving the monitoring purpose. To avoid the "ping-pong" effect, the prediction accuracy of the model is evaluated multiple times to determine the model's performance in a certain scenario.

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

[0058] In time-domain beamforming, beam measurements taken over a historical period are used as input to a model to predict the optimal beam for future times (e.g., future slots). For example: Figure 2 As shown, slots 1 to 5 are included in the historical time window. The beams within this time window are measured, and the measurement results are input into the model. The model will predict the optimal candidate beams corresponding to future slots 6 to 9.

[0059] As an example, the monitoring format is either a first monitoring format or a second monitoring format. In the first monitoring format, multiple monitoring sessions are performed by reusing at least a portion of historical measurement information relevant to the task. In the second monitoring format, the measurement information relevant to the task used in each monitoring session does not overlap. Using the first monitoring format saves on measurement overhead and latency. Using the second monitoring format allows for a wider time-domain span, meaning more data can be acquired for different channel environments, resulting in a more accurate evaluation of model performance.

[0060] For example, the first monitoring format refers to reusing part of the historical measurement information from the previous monitoring session for each monitoring session, while the second monitoring format refers to using historical measurement information that does not overlap for each monitoring session.

[0061] For example, when the measurement beams at each time point are different (for instance, the beams measured in slot 1 have indices of 1, 2, and 3, but the beams measured in slot 2 have indices of 8, 9, and 10, and so on, with differences in the beams measured each time), historical measurement data cannot be reused, 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 a first monitoring format to the user equipment when the channel is determined to be a slow fading channel based on the channel conditions, and to indicate a second monitoring format to the user equipment when the channel is determined to be a fast fading channel based on the channel conditions.

[0063] For example, channel conditions can refer to the time-varying characteristics of the channel. If the channel fading is relatively gentle in the time domain, the first monitoring format can be selected. If the channel fading is rapid in the time domain, and more model characteristics under the channel environment need to be monitored, the second monitoring format can be selected.

[0064] For example, when the channel is relatively flat, the primary factor affecting model performance is not channel environment changes, and the first monitoring format can be chosen to evaluate the model's predictive performance. By reusing some historical measurement data to perform multiple predictions, the model can save measurement and latency overhead during the monitoring phase in a relatively flat channel environment. When it is necessary to evaluate the model's performance in more channel environments, the second monitoring format can be used.

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

[0066] For example, those skilled in the art can predetermine the predetermined conditions based on the application scenario or experience.

[0067] For example, the predetermined conditions include that the maximum number of beams that the user equipment can measure is less than the number of beams that need to be measured in each prediction, and / or that the accuracy of the beams that the user equipment can measure is less than the required accuracy of the measured beams in each prediction.

[0068] For example, when the maximum number of beams that the user equipment can measure is less than the number of beams that need to be measured in each prediction, a first monitoring format is indicated to the user equipment; when the maximum number of beams that the user equipment can measure is greater than or equal to the number of beams that need to be measured in each prediction, a second monitoring format is indicated to the user equipment. Similarly, when the accuracy of the beams that the user equipment can measure is less than the required accuracy for each prediction, a first monitoring format is indicated to the user equipment; when the accuracy of the beams that the user equipment can measure is greater than or equal to the required accuracy for each prediction, a second monitoring format is indicated to the user equipment.

[0069] The above describes examples of determining the monitoring format based on channel conditions and determining the monitoring format based on capability information, respectively. The monitoring format can also be determined based on both channel conditions and capability information. For example, processing unit 103 can be configured to indicate a first monitoring format to the user equipment when the channel is determined to be a slow fading channel based on channel conditions and the capability information meets predetermined conditions, and to indicate a second monitoring format to the user equipment when the channel is determined to be a fast fading channel based on channel conditions and the capability information does not meet predetermined conditions.

[0070] Figure 3 A diagram illustrating an example of beam prediction using a first monitoring format according to an embodiment of this disclosure is shown. Figure 3 The example shows slots 1 through 12.

[0071] like Figure 3As shown, for time-domain beam prediction, the input time windows of the model overlap during multiple predictions. For ease of description, it is assumed that the beams measured at each measurement moment within the historical data measurement time window are the same (for example, the beams measured in slot 1 correspond to indices 1, 2, and 3, and the beams measured in slots 2 to 5 also correspond to indices 1, 2, and 3). Historical measurement data is reused for multiple monitoring sessions. For instance, beam measurements are performed for the moments corresponding to slots 1 to 5, and the measurement structure is used as the model input to complete the first prediction. In the second prediction, the network-side equipment (e.g., the base station) only needs to allocate the resources required for the measurement beam corresponding to slot 6 to the UE, using the measurement results obtained from beam measurements in slots 2 to 6 as the model input for the second prediction. This process continues, with the network-side equipment only needing to allocate a portion of the measurement resources corresponding to the reference signal to the UE each time, while reusing the previous measurement results for the remaining portion. If Set A (the complete set, containing all possible beams) in the BM-Case 2 time-domain beam prediction discussed in 3GPP is equal to Set B (the set of measured beams used as model input), the prediction results of the AI ​​model and the measurement results of the non-AI model can be directly compared within the time window where the model output and input overlap. For example, in one prediction, the model output is the beam prediction result for slot 11 (which is the prediction result of the AI ​​model), while in other predictions, the beam measurement result for slot 11 is used as the model input (which is the measurement result of the non-AI model) to predict the optimal beam for future time slots. 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 will understand that the prediction accuracy of the model can also be calculated by comparing the beam prediction results for multiple times and the beam measurement results for said multiple times.

[0072] Figure 4 A diagram illustrating an example of beam prediction using a second monitoring format according to an embodiment of this disclosure is shown. Figure 4 The example shown is slots 1 through 14. In this case, each measurement is performed separately, as... Figure 4As shown, the beams at times 1 to 5 are measured, and the results are used as input for the model's first beam prediction. Then, the beams at times 6 to 10 are measured, and the results are used as input for the model's second beam prediction. This process continues. In each prediction, the measurement results are not reused; that is, each measurement is independent in the model's multiple predictions. Even so, within the time window where the model output and input overlap, if Set A equals Set B, the AI-based prediction results and the non-AI measurement results can be directly compared.

[0073] As an example, processing unit 103 can be configured to, when instructing a user equipment on a first monitoring format, indicate time-domain information of at least a portion of the multiplexed historical measurement information in the time domain, wherein the time-domain information includes the start point of the multiplexed at least a portion of the historical measurement information in the time domain and the length of the multiplexed at least a portion of the historical measurement information in the time domain. The time-domain information may also include the measurement information interval for each prediction.

[0074] When the network-side device instructs the UE on the monitoring format, it may include the following information: the index of the monitoring format, the allocated reference signal, and the corresponding time and frequency resources.

[0075] For the UE-side model, after the model monitoring mechanism is activated, the network-side device needs to instruct the UE to use the corresponding index for the monitoring format. Format 1 (i.e., the first monitoring format, which can reuse historical measurement data) should include: the aforementioned time-domain information (e.g., the time-domain interval of each measurement (or the length of the reused historical data in the time domain)) and the measurement resource configuration carrying the reference signal. Format 2 (i.e., the second monitoring format, where each prediction's beam measurement in the time domain is independent) should include: the measurement resource configuration carrying the reference signal. If the network-side device does not know the time window length of the UE-side model's input and output, the aforementioned monitoring format information should also include the length of the time window occupied by the model's input and output in the time domain.

[0076] As an example, multiple beam predictions are performed using the beam prediction model to monitor the prediction accuracy of the model multiple times, thereby improving the prediction accuracy of the beam prediction model for future candidate beams.

[0077] As an example, the user equipment executes the task model N times by reusing some historical measurement information for the task, thus obtaining N execution results. Based on the execution results, it judges the stability of the task model and makes inferences about the task model, where N is a positive integer greater than 1. By reusing some historical measurement information for the task to perform inference, there is no significant increase in measurement overhead and latency.

[0078] In NR (Radio Frequency Identification), retransmission is a technique used to ensure data transmission reliability. Retransmission involves transmitting the same information multiple times, thereby increasing the decoding performance at the receiving end. For time-domain beam prediction, retransmission can also be used to increase the reliability of prediction results. Here, retransmission manifests as multiple predictions by the model. Due to the characteristics of the time-domain channel, the time window length for collecting historical data is fixed in each inference of the model. While the time window lengths for historical data in two adjacent inferences may be the same or different, the time windows for data collection can overlap across multiple inferences.

[0079] Figure 5 A diagram illustrating an example of reusing historical measurement data in model inference according to an embodiment of this disclosure. Figure 5 The example illustrates slots 1 through 12. For instance, considering the time-varying characteristics of the channel, to ensure the reliability of the prediction results, the model can perform multiple predictions, thus enhancing the reliability of the prediction results. For example, in... Figure 5 In this process, N beam predictions can be performed by reusing at least a portion of historical measurement information (e.g., reusing at least a portion of beam measurement results from time slots prior to slot 11) to obtain N beam prediction results for slot 11. Then, the stability of the beam prediction model is determined by comparing the N beam prediction results for slot 11, thereby enabling inference of the beam prediction model. Figure 5 This repeated measurement reuses some of the previous measurement results, so it does not significantly increase the overhead in terms of measurement cost and latency.

[0080] As an example, the processing unit 103 can be configured to receive an event reported by the user device indicating that the stability of the task model is less than a predetermined stability threshold when the inference result indicates that the stability of the task model is less than a predetermined stability threshold, and decide whether to trigger monitoring of the task model based on the event.

[0081] Model monitoring can be categorized into one or more of the following three types: periodic, aperiodic, and semi-static. For example, periodicity can be configured in Infinite Resource Control (RRC) signaling. For example, as mentioned above, it can be determined whether to trigger monitoring of the task model based on the aforementioned events.

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

[0083] For example, the predetermined number of predictions can be configured by the network-side device, based on factors such as channel estimations and observations obtained by the network-side device. Taking a beam prediction model on the UE side as an example, the network-side device instructs the UE on the number of predictions (number of repeated measurements) (i.e., the predetermined number of predictions) and the time interval between each prediction (time interval between each measurement). Furthermore, the network-side device can allocate corresponding measurement resources to the UE. Of course, this number of repeated measurements can also be a non-fixed value. For example, the network-side device can configure a value for the number of repeated measurements of the model. If the prediction result is found to be relatively stable after multiple predictions, it can proactively report the termination of the current prediction. In other words, after the network-side device configures a predetermined number of predictions for the UE, if the UE determines that the model performance is stable, it can report the termination of prediction before completing the predetermined number of predictions configured by the network-side device.

[0084] Relatively stable prediction results mean that the differences between multiple predictions for the same future moment are very small, and the communication link quality can still be guaranteed during communication using the prediction beam. However, if the prediction results for the same future moment differ significantly each time, it indicates a problem with the model's performance. Possible reasons include the model's inability to adapt to the current variable channel environment, or imbalanced or undiversified training data during training. The magnitude of the difference can be judged using a predefined threshold. When the difference is less than the threshold, and the prediction beam can guarantee link quality, the model's prediction performance is considered relatively stable. A difference greater than the threshold indicates unstable prediction performance, and the model's current prediction can be considered a failure. Once the difference between multiple prediction outputs becomes large at a certain point, the reporting of prediction results should be stopped, and a model prediction failure event should be reported to the network-side device. The network-side device will then determine whether to trigger the model's monitoring mechanism based on the event reported by the UE.

[0085] In embodiments according to this disclosure, during the inference phase, the reliability of the model output (model prediction) can be ensured by performing multiple predictions based on the model. This reliability is obtained by observing the differences between multiple prediction results at one or more future times. If the difference is small, it indicates relatively stable performance; if the difference is large, it proves that the model's prediction has failed, which may be due to time-varying channel conditions. In the latter case, the UE should not report the prediction result again, but instead report the event to the network-side device, which will then determine whether to trigger the model's monitoring mechanism.

[0086] Figure 6 A diagram illustrating an example of the signaling flow during inference of a beam prediction model according to an embodiment of the present disclosure, assuming stable model performance.

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

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

[0089] In S63, if the prediction results are found to be relatively stable after multiple predictions, the UE will proactively report to the gNB to terminate the repeated predictions.

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

[0091] Figure 7 A diagram illustrating an example of the signaling flow in the case of model prediction failure during inference of a beam prediction model according to an embodiment of this disclosure is shown.

[0092] In S71, the gNB configures the measurement beam set, the number of repeated predictions, and the time interval between each prediction for the UE.

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

[0094] In S73, if the prediction results are found to be unstable after multiple predictions, the UE reports a model inference failure event to the gNB.

[0095] In S74, gNB monitors based on the event-triggered model described above.

[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 in which multiple tasks share model parameters and model branches that correspond to at least a portion of the multiple tasks.

[0097] As an example, the shared parameter model extracts a shared representation shared by multiple tasks from the input data, as well as a mapping from the shared representation to the label of the task corresponding to that model branch for each model branch.

[0098] For a description of the multitasking model, please refer to the description of the multitasking model in the embodiment of electronic device 300 below, which will not be repeated here.

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

[0100] Figure 8 An exemplary functional block diagram of an electronic device 200 for wireless communication according to another embodiment of the present disclosure is shown.

[0101] like Figure 8 As shown, the electronic device 200 includes: a control unit 201 for control; and a processing unit 203, which, under the control of the control unit 201, receives from a network-side device an instruction regarding a monitoring format for monitoring the task model to be adopted, for the task model used to implement the task on the electronic device 200 side. The monitoring format is determined by the network-side device based on the channel conditions where the electronic device 200 is located and / or capability information representing the capabilities of the electronic device 200.

[0102] The control unit 201 and processing unit 203 can be implemented as one or more processing circuits and at least one memory. The processing circuits can be, for example, a processor or a chip, and the at least one memory can be RAM, ROM, etc., and is used to store, for example, computer program code and data required for the processing circuits to perform processing. Furthermore, it should be understood that... Figure 8 The functional units in the electronic device 200 shown are logical modules divided according to the specific functions they implement, rather than being used to limit the specific implementation method.

[0103] For example, electronic device 200 can function as a user equipment itself and may also include external devices such as memory and transceiver (not shown). The memory can be used to store programs and related data information that electronic device 200 needs to execute to perform various functions. The transceiver may include one or more communication interfaces to support communication with different devices (e.g., UE, base station, etc.), and there is no specific limitation on the implementation of the transceiver.

[0104] The electronic device 200 according to embodiments of this disclosure can receive instructions from a network-side device on different monitoring formats for model monitoring, determined according to different circumstances. For example, the electronic device 200 can receive instructions from a network-side device on a monitoring format determined based on the channel conditions in which the electronic device 200 is located and / or capability information representing the capabilities of the electronic device 200.

[0105] As an example, electronic device 200 can be a user device in the embodiment of electronic device 100, and network-side device in the embodiment of electronic device 200 can be 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 reusing at least a portion of historical measurement information for the task, and in the second monitoring format, for multiple monitoring, the measurement information for the task used in each monitoring does not overlap.

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

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

[0109] As an example, the processing unit 203 may be configured to receive an instruction on a first monitoring format from the network-side device when the capability information meets predetermined conditions, and to receive an instruction on a second monitoring format from the network-side device when the capability information does not meet predetermined conditions.

[0110] For a description of the first and second monitoring formats, please refer to the embodiments of the electronic device 100. Figure 3 and Figure 4 The relevant parts of the description will not be repeated here.

[0111] As an example, processing unit 203 can be configured to, upon receiving an indication from a network-side device regarding a first monitoring format, also receive an indication regarding time-domain information of at least a portion of the multiplexed historical measurement information in the time domain, wherein the time-domain information includes the start point of the multiplexed at least a portion of the historical measurement information in the time domain and the length of the multiplexed at least a portion of the historical measurement information in the time domain. The time-domain information may also include the measurement information interval for each prediction.

[0112] As an example, the processing unit 203 can be configured to execute the task model up to N times by reusing some historical measurement information for the task to obtain N execution results, and to judge the stability of the task model based on the execution results, thereby making inferences about the task model, where N is a positive integer greater than 1.

[0113] As an example, the processing unit 203 can be configured to report an event to the network-side device that reflects the stability being less than the predetermined stability threshold when the inference result indicates that the stability of the task model is less than the predetermined stability threshold, so that the network-side device can decide 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 a task model is executed in inference, wherein the predetermined number of times is greater than or equal to N.

[0115] For a description of the inferences of the dry model, please refer to the embodiment of electronic device 100. Figure 6 and Figure 7 The relevant parts of the description will not be repeated here.

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

[0117] As an example, multiple beam predictions are performed using the beam prediction model to monitor the prediction accuracy of the model multiple times, thereby improving the prediction accuracy of the beam prediction model for future candidate beams.

[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 in which multiple tasks share model parameters and model branches that correspond to at least a portion of the multiple tasks.

[0119] As an example, the shared parameter model extracts a shared representation shared by multiple tasks from the input data, as well as a mapping from the shared representation to the label of the task corresponding to that model branch for each model branch.

[0120] Figure 9 An exemplary functional block diagram of an electronic device 300 for wireless communication according to yet another embodiment of the present disclosure is shown.

[0121] like Figure 9As shown, the electronic device 300 includes: a control unit 301, which performs control; and a processing unit 303, which, under the control of the control unit 301, simultaneously performs multiple tasks through a multi-task model. The multi-task model includes a shared parameter model (which may also be called a partial model) in which multiple tasks share model parameters, and model branches corresponding to at least a portion of the multiple tasks.

[0122] The control unit 301 and processing unit 303 can be implemented as one or more processing circuits and at least one memory. The processing circuit can be, for example, a processor or a chip, and the at least one memory can be RAM, ROM, etc., and is used to store, for example, computer program code and data required for the processing circuits to perform processing. Furthermore, it should be understood that... Figure 9 The functional units in the electronic device 300 shown are logical modules divided according to the specific functions they implement, rather than being used to limit the specific implementation method.

[0123] Electronic device 300 may be located on the base station side or communicatively connected to the base station. For example, electronic device 300 may function as the base station itself and may also include external devices such as memory and transceiver (not shown). The memory may be used to store programs and related data information that electronic device 300 needs to execute to perform various functions. The transceiver may include one or more communication interfaces to support communication with different devices (e.g., UE, base station, etc.), and the specific implementation of the transceiver is not limited here.

[0124] As an example, the base station could be an eNB or a gNB. In the following description, we will typically use a gNB as the base station.

[0125] For example, electronic device 300 can function as the UE itself, and may also include external devices such as memory and transceiver (not shown). The memory can be used to store programs and related data information that electronic device 300 needs to execute to perform various functions. The transceiver may include one or more communication interfaces to support communication with different devices (e.g., UE, base station, etc.), and there is no specific limitation on the implementation of the transceiver.

[0126] In the following text, unless otherwise specified, electronic device 300 may be one of the gNBs and UEs on which a multitasking model is deployed.

[0127] In existing technologies, an AI model is dedicated to implementing a single task (function). Such a model is called a single-task model. In real-world scenarios, gNBs and UEs typically need to support the implementation of multiple tasks. Mathematically, defining the input data as x, the number of tasks as T, and the label of task t as yt, then using single-task learning to implement multiple tasks can be expressed as:

[0128]

[0129] Among them, f t (·) represents the single-task model corresponding to task t. This is the prediction of task t for a single-task model. Based on the prediction of task t... and tag y t Calculate the loss for task t, thereby completing the analysis of the single-task model f. t Training (·).

[0130] Furthermore, since the deployment and management of AI models in wireless communication systems require information interaction between nodes (gNB or UE), 3GPP has discussed lifecycle management for single-task models. Specifically, lifecycle management includes, but is not limited to, the following stages: (1) Model authentication to ensure that the gNB and UE have a common understanding of the AI ​​model. Common understanding includes, but is not limited to, task confirmation, UE capability confirmation, and model information confirmation; (2) Activating / deactivating / switching the model to select the appropriate model from multiple AI models; (3) Model performance monitoring and model updating to ensure the model's task performance in complex and ever-changing wireless environments.

[0131] AI-assisted wireless communication methods offer significant performance gains and enable the application of AI models to real-world wireless communication systems through lifecycle management. However, since gNBs and UEs typically need to support the implementation of multiple tasks, single-task-oriented learning models and lifecycle management suffer from the following problems:

[0132] (1) The label of a single task can only reflect a partial physical characteristic of the wireless environment. For example, the optimal beam label can only reflect the angular characteristics of multipath transmission. Therefore, single-task models trained using the labels of a single task are prone to overfitting.

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

[0134] (3) It is difficult to determine whether the performance degradation of the task is due to input data quality problems, auxiliary data quality problems or model-scenario mismatch, resulting in a large model update cost.

[0135] (4) In single-task multi-base station collaboration, 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 are usually different in real-world scenarios, they may not be able to support the acquisition of the same type of input data and the same type of task label data, which brings challenges to single-task multi-base station collaboration.

[0136] (5) In dual-end model deployment, single-task learning requires distributing a UE-end or gNB-end model for each task and feeding back a specific codeword, resulting in large model distribution overhead and feedback overhead.

[0137] To address the aforementioned model-related issues, this application proposes using a single AI model to perform multiple tasks simultaneously. Such a model is referred to as a multi-task model.

[0138] Figure 10 This is a diagram illustrating an example framework of a multitasking model according to an embodiment of the present disclosure.

[0139] like Figure 10 As shown, taking multiple tasks including three tasks (task 1, task 2 and task 3) as an example, the multi-task model includes a shared parameter model that shares model parameters with these three tasks, as well as model branches corresponding to task 1, task 2 and task 3 respectively. For example, it can realize the prediction of task 1 to task 3.

[0140] As an example, the shared parameter model extracts a shared representation shared by multiple tasks from the input data, as well as a mapping from the shared representation to the label of the task corresponding to that model branch for each model branch.

[0141] Mathematically speaking, a multi-task model that implements multiple tasks can be described as follows:

[0142] c = g(x)

[0143]

[0144] Here, g(·) is the shared parameter model for T tasks. c is the shared representation for the T tasks extracted by the encoder (g(·)) from the input data x. Further, the task-specific model branch gt(·) learns the mapping from c to the task-t label yt. Prediction of T tasks is achieved through the multi-task model. and labels {y1,y2,…,y T The loss for each of the T tasks is calculated, and this loss is used to train the multi-task model. Under supervised learning with multiple task labels, the shared-parameter model, which shares model parameters, can extract the physical features of the wireless environment reflected by different labels from the input data, thereby improving the generalization performance of the multi-task model.

[0145] To address the aforementioned lifecycle management issues and to implement lifecycle management for multi-task models, this application proposes a lifecycle management process oriented towards multi-task learning. Specifically, firstly, during the model certification phase, tasks within a group use unified input data and undergo unified model certification. Secondly, tasks within a group are managed uniformly within the multi-task model, eliminating the need for additional signaling coordination. Thirdly, multiple tasks within the same multi-task model can mutually supervise each other, aiding in identifying the causes of task performance degradation. Fourthly, in multi-task multi-base station collaboration, different base stations are allowed to have different types of input data and not entirely identical task sets. Fifthly, in the deployment of dual-end models, only the shared parameter model with shared model parameters among tasks within the group needs to be distributed to the UE or gNB, reducing model distribution overhead. In the inference of dual-end models, only a codeword shared among tasks within the group needs to be fed back, reducing feedback overhead.

[0146] The following section will elaborate on each stage of AI model lifecycle management from the perspective of comparing single-task learning and multi-task learning. Before proceeding, let's clarify two concepts:

[0147] Input data: Data that is directly used as input to the AI ​​model.

[0148] Auxiliary data: Data that is not used as input to the AI ​​model. For example, UE positioning typically predicts the position relative to the gNB; therefore, the absolute position of the gNB is needed when inferring the absolute position of the UE. However, in this process, the gNB position is not used as input data to the AI ​​model; therefore, the gNB position is auxiliary data.

[0149] As an example, tasks are grouped based on their correlation with each other, with each group of tasks implemented through a corresponding multi-task model. The correlation is obtained based on at least one of the following: prior information about the correlation between tasks, coordination information between tasks, and matching degree between tasks.

[0150] Training multiple tasks with weak correlation using a multi-task learning approach can actually degrade performance. Therefore, in this application, all tasks confirmed by a node are grouped according to their inter-task correlation. Tasks within each group are implemented using a corresponding multi-task model. After task grouping, multi-task models are deployed and their lifecycles are managed group by group. That is, highly correlated tasks are grouped together, and multi-task models are deployed and their lifecycles managed group by group.

[0151] Nodes typically need to support the implementation of multiple tasks. Existing model deployment and lifecycle management are geared towards a single task, which has three shortcomings: (1) it does not take advantage of the correlation between tasks, and there is still considerable room for improvement in the performance of each task; (2) when different tasks need to coordinate, it brings a large signaling overhead; (3) it is difficult to determine the cause of the task performance degradation, which brings a large model update overhead.

[0152] According to the embodiments of this disclosure, multi-task learning for wireless communication is applied to all tasks within a group, and model deployment and lifecycle management are performed uniformly. This enables the performance of each task to be improved by leveraging the correlation between tasks, and reduces signaling and model update overhead.

[0153] For example, the correlation between tasks stems from the fact that the labels of different tasks reflect different aspects of the physical characteristics of the same wireless environment. For instance, the optimal beam index label contains the angular characteristics of multipath transmission, and the UE location label contains the relative positional 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.

[0154] In the following text, for simplicity, the multi-task model will sometimes be used to describe a group of tasks (tasks within a group). However, it is understood that the multi-task model can also be used without grouping the tasks.

[0155] Model certification refers to achieving a shared understanding of the AI ​​model between the UE and gNB. This understanding includes, but is not limited to, the model's data type, data quality (including but not limited to time sampling period, quantization bits, and signal-to-noise ratio), and the tasks (functions) it implements.

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

[0157] For example, the input data is consistent across tasks within the group in terms of, but not limited to, data type and data quality.

[0158] As an example, input data is determined based on at least one of the following: task requirements, the capabilities of nodes associated with the task, and data collection overhead. That is, uniform input data is determined for tasks within the group. A balance is struck between the performance and data collection overhead of multiple tasks within the group.

[0159] As an example, the requirements of a task include the time sampling period, the capabilities of a node include the availability of node data, the quality of node data, the matching degree of node data with different tasks, the quality requirements of node data for different tasks, and the data collection overhead includes the collection overhead of data of a predetermined quality.

[0160] The model authentication for multi-task learning according to embodiments of this disclosure simultaneously performs model authentication for multiple tasks within a group. For example, the gNB determines unified input data based on the task and task requirements, gNB capabilities, and data collection overhead. Since the tasks within the group are managed uniformly in subsequent model updates and model migrations, the result of the unified input data only needs to be confirmed once between the gNB and the UE, thereby reducing signaling overhead.

[0161] For example, if electronic device 300 is a gNB (gear-based data unit), standardized input data can be determined based on the task and task requirements, gNB capabilities, and data collection overhead. For instance, features that can be considered when determining standardized input data include, but are not limited to: C1, the availability of gNB-side data; C2, the quality of gNB-side data; C3, the matching degree between gNB-side data and different tasks within the group; C4, the quality requirements of different tasks within the group for gNB-side data; and C5, the collection overhead for data of specific quality.

[0162] In contrast, we will first describe model certification for single-task learning. Here we discuss a scenario where the model is deployed on the UE and requires the gNB to complete all or part of the data determination and collection.

[0163] The model certification process for single-task learning includes:

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

[0165] S2, UE confirms a single task and task requirements.

[0166] S3, determine the task ID of the task based on the task list.

[0167] S4, the UE sends the task ID and requirements to the gNB.

[0168] S5, based on gNB capabilities, the task ID, and requirements, gNB determines the type and quality of input data that gNB needs to provide.

[0169] S6, gNB notifies the UE of the determined input data type and quality.

[0170] S7. Based on the task list, dataset list, input data type and quality, the UE completes the model information confirmation for the single task model. This model information includes, but is not limited to: (1) Model ID: composed of single task ID and input data ID; (2) Input data quality.

[0171] The problems with model certification for single-task learning are as follows. While the above process enables model certification for a single task, UEs typically need to support multiple tasks. Since single-task learning-oriented model certification manages each single-task model independently, this can lead to significant data collection and signaling overhead. Specifically, different tasks may use the same type of data (e.g., both beam prediction and positioning tasks can use Received Reference Signal Power (RSRP) as input data), and different tasks may have different quality requirements for this data. Under the above single-task learning-oriented model certification process, specific quality data needs to be collected for each task, which results in substantial data collection overhead when the number of tasks is large. Generally, higher data quality (e.g., higher time sampling rate, more quantization bits, higher signal-to-noise ratio) leads to stronger model inference performance. Therefore, a unified input data can be determined for multiple tasks based on their performance requirements and data collection overhead to reduce data collection overhead. However, since each task is managed independently, for subsequent model updates and migrations, the data type and quality in model authentication still need to be confirmed between the gNB and UE via signaling for each task, resulting in significant signaling overhead.

[0172] To address the problems of model certification for single-task learning, this application proposes a model certification process for multi-task learning.

[0173] As an example, processing unit 303 can be configured to verify model information of a multi-task model based on results from unified input data, thereby simultaneously certifying models for multiple tasks. Model information verification between the gNB and UE is performed on a group basis. Tasks within the same group do not require signaling coordination between the gNB and UE. The model information contains the IDs of all tasks within the group; therefore, by accessing the model information, information about the multiple tasks that the model can perform can be obtained.

[0174] Figure 11 This is a first example flow illustrating model authentication for multi-task learning according to an embodiment of the present disclosure. Figure 11 The illustrated process is a model certification process for multi-task learning in a scenario where a multi-task model is deployed on the UE and the gNB needs to complete all or part of the data determination and collection.

[0175] The first example process for model certification for multi-task learning includes:

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

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

[0178] S3: Assign task IDs based on the task list.

[0179] S4, the UE groups tasks based on their correlation with each other.

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

[0181] S6, based on the task ID and requirements within the group, gNB capabilities, and data collection overhead, determines the unified input data that gNB must provide for the tasks within the group, including but not limited to the input data ID and input data quality determined based on the dataset list.

[0182] S7, gNB will notify UE of the unified result of the input data provided by gNB.

[0183] S8, the UE confirms the model information of the multi-task model based on the task list, dataset list, and input data unification results. This model information includes, but is not limited to: (1) Model ID: composed of the union of task IDs within the group and input data ID; (2) Input data quality.

[0184] Figure 12 This is an example illustrating a list of tasks according to an embodiment of this disclosure.

[0185] like Figure 12 As shown, the task list includes three tasks: beam prediction, UE positioning, and CSI feedback, with task IDs ranging from 0 to 2. For example, tasks with task IDs 0 and 1 are related.

[0186] Figure 13 This is an example showing a list of datasets according to embodiments of this disclosure.

[0187] like Figure 13 As shown, the dataset list includes three types of input data: received signal, UE location, and CSI, with input data IDs ranging from 0 to 2.

[0188] The following describes a second example flow for model authentication for multi-task learning according to embodiments of the present disclosure. The second example flow describes a model authentication process for multi-task learning in a scenario where a multi-task model is deployed on a gNB and the UE needs to complete all or part of the data determination and collection.

[0189] The second example process for model certification for multi-task learning includes:

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

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

[0192] S3: Assign task IDs based on the task list.

[0193] S4 and gNB group tasks based on their correlation with each other.

[0194] S5, gNB queries UE capabilities.

[0195] S6, UE feeds back UE capabilities to gNB.

[0196] S7, gNB determines the unified input data that the UE must provide for the tasks within the group based on the task ID and requirements, UE capabilities and data collection overhead, including but not limited to the input data ID and input data quality determined based on the dataset list.

[0197] S8, gNB will notify the UE of the unified result of the input data that needs to be provided by the UE.

[0198] S9, gNB confirms the model information of the multi-task model based on the task list, dataset list, and input data unification results. This model information includes, but is not limited to: (1) Model ID: composed of the union of task IDs within the group and input data ID; (2) Input data quality.

[0199] The following describes a third example flow for model certification of multi-task learning according to embodiments of this disclosure. The third example flow is a model certification process where the model is deployed on a node (gNB or UE), and the node completes all data verification and collection. Model certification can be performed uniformly for multiple tasks within a group.

[0200] The third example process for model certification for multi-task learning includes:

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

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

[0203] S3: Assign task IDs based on the task list.

[0204] S4, this node groups tasks based on their correlation with each other.

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

[0206] S6, this node confirms the model information of the multi-task model based on the task list, dataset list, and unified input data. The model information includes, but is not limited to: (1) Model ID: composed of the union of task IDs within the group and input data ID; (2) Input data quality.

[0207] The following describes the activation / deactivation of an AI model for a specific task. A task may belong to different groups simultaneously, i.e., different multi-task models.

[0208] In contrast, let's first describe model activation / deactivation for single-task learning. Models for different tasks may require coordination. For example, if the input of one model is the output of another, the trigger times of the two models need to be aligned. Therefore, in single-task learning, when activating / deactivating a task, it's necessary to query the coordination information (including but not limited to trigger times) of existing activated tasks.

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

[0210] S1, the task ID for confirming model activation / deactivation at the node.

[0211] S2, the node determines the ID of the activated task that needs to be coordinated with the activated task based on the activated / deactivated task ID.

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

[0213] S4, the node schedules multiple tasks that need to be coordinated based on the coordination information.

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

[0215] The problem with model activation / deactivation for single-task learning is that it requires querying the coordination information of the task that needs to be coordinated, resulting in additional scheduling signaling overhead.

[0216] To address the aforementioned problems in single-task learning, this application proposes a model activation / deactivation approach for multi-task learning.

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

[0218] As mentioned above, tasks requiring coordination are typically grouped, and tasks within a group are implemented using a multi-task model. Because the model deployment and lifecycle management of tasks within a group are unified, there's no need to query coordination information for tasks within the group. For example, within the same model, the trigger times of different tasks are naturally aligned. Therefore, when a task is activated / deactivated, only the corresponding task's model branch needs to be activated / deactivated in the multi-task model, without needing to query coordination information for other tasks within the same multi-task model, thus reducing scheduling signaling overhead.

[0219] In model activation / deactivation for multi-task learning, the multi-task model is first identified using the model ID. Tasks requiring coordination typically belong to the same multi-task model. Because multiple tasks are deployed and managed simultaneously, activation / deactivation for multi-task learning does not require additional signaling for task scheduling within the group.

[0220] Figure 14 This is an example flow illustrating model activation / deactivation for multi-task learning according to embodiments of the present disclosure.

[0221] S1, the node (gNB or UE) confirms the model activation / deactivation information. The information includes the model ID and the task ID.

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

[0223] S3, the multi-task model activates / deactivates the corresponding task-specific model branch based on the task ID.

[0224] It's important to note that in multi-task models, the model branches for different tasks are independent. During the model inference phase, activating / deactivating a model branch for a particular task will not affect the inference of shared parameter models within the group or the model branches for other tasks.

[0225] Additionally, a task may belong to different groups simultaneously. For example, task A may be highly correlated with task B / task C, but task B and task C may be weakly correlated. In this case, task A belongs to both the group containing task B and the group containing task C.

[0226] Furthermore, when a task can be inferred by different multi-task models, fusion decision-making can be considered. For example, the confidence level of a multi-task model can be evaluated based on its in-group task performance. Further, based on the confidence level of the multi-task models, decision weights can be assigned to the inference results of different multi-task models for the same task, thus achieving fusion decision-making.

[0227] Model checking refers to evaluating the performance of a task during the inference phase. Model updating refers to updating the parameters or structure of the model.

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

[0229] In a multi-task model, tasks within a group share the same input data and model parameters. In contrast, auxiliary data is typically task-specific. For example, gNB location, as auxiliary data, is specific to the UE positioning task.

[0230] In contrast, we will first describe model detection and model update for single-task learning.

[0231] Model detection based on single-task learning struggles to pinpoint the causes of performance degradation. Therefore, the corresponding model update process is often non-environment-specific (the causes of performance degradation typically change with the environment, and single-task learning methods cannot accurately detect these environmental changes and implement appropriate model updates). In scenarios where model deployment on the UE side requires gNB to complete all or part of the data verification and collection, a single-task learning-based model detection and update process is as follows:

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

[0233] S2, gNB updates the quality of auxiliary data that needs to be provided by gNB based on gNB capabilities.

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

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

[0236] S5, the UE continues to monitor the performance of the task.

[0237] (The task's performance still cannot meet the requirements, proceeding to S6)

[0238] S6, the UE sends an update input data quality request to the gNB based on the single-task model information.

[0239] S7, gNB updates the quality of the input data that needs to be provided by gNB based on gNB capabilities.

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

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

[0242] S10, the UE continues to monitor the performance of the task.

[0243] (The task's performance still cannot meet the requirements, proceeding to S11)

[0244] S11, the UE sends a model update request to the gNB based on the single-task model information.

[0245] S12, gNB and UE collaborate to complete the data collection of input data, auxiliary data, and tag data in the current scenario.

[0246] S13, use the collected data to update the single-task model.

[0247] S14, return to S1.

[0248] The problems with model detection and update processes for single-task learning are as follows. The above process is not environment-specific. When the reason for the decline in task performance is the quality of the input data, unnecessary auxiliary data quality update processes are performed; when the reason for the decline in task performance is the mismatch between the model and the scene, unnecessary auxiliary data and input data quality update processes are performed. Model management for single-task learning makes it difficult to determine the cause of the decline in task performance, resulting in a large model update overhead. As mentioned above, model management for single-task learning makes it difficult to determine the source of the decline in task performance: (1) quality problems of input data (data directly used as input to the AI ​​model); (2) quality problems of auxiliary data (data not used as input to the AI ​​model); (3) model mismatch with the scene.

[0249] In multi-task models, since tasks within a group share the same input data and some model parameters, mutual supervision among tasks is possible. This mutual supervision manifests in the following ways: when a few tasks in a multi-task model experience performance degradation, the probability of input data quality issues and model-scenario mismatch is considered low; conversely, when most tasks in a multi-task model experience performance degradation, the probability of input data quality issues and model-scenario mismatch is considered high. Therefore, appropriate model update operations can be performed based on the performance degradation patterns of tasks within the group, thereby reducing the average cost of model updates. Utilizing the characteristics of mutual supervision among tasks within the group, the scenarios of performance degradation can be categorized to aid in determining the causes of task performance degradation.

[0250] Generally, updating data quality means improving data quality, such as quantizing the input data with more quantization bits. Therefore, when data quality is updated because of a performance degradation in one task, the performance of other tasks in the group usually does not degrade.

[0251] To identify situations where task performance degrades within a group, a process for classifying such situations is presented in a UE-side model deployment scenario:

[0252] S1 is a preset threshold for determining the proportion of tasks within a group that experience performance degradation.

[0253] S2 sets a preset threshold for each task within the group to determine whether the task has experienced a performance degradation.

[0254] S3 calculates the performance degradation index of all tasks within the group and compares it with the threshold in S2 to determine whether each task in the group has experienced a performance degradation.

[0255] S4, calculate the proportion of the number of tasks with performance degradation within the group to the total number of tasks, and compare it with the proportion threshold in S1: if the proportion exceeds the proportion threshold in S1, then adopt the model update process for the majority of tasks in the group with performance degradation; otherwise, adopt the model update process for the minority of tasks in the group with performance degradation.

[0256] For example, the ratio threshold ranges from (0,1). This ratio threshold can be adjusted according to actual needs.

[0257] As an example, the processing unit 303 can be configured to update the multi-task model based on the classification of performance degradation scenarios of multiple tasks, by updating the quality of the input data of the multi-task model, updating the quality of the auxiliary data of the multi-task model, and updating the model parameters of the multi-task model.

[0258] Figure 15This is a first example flow illustrating model detection and model updating for multi-task learning according to an embodiment of the present disclosure. Figure 15 The illustrated process is a model update process designed to address the performance degradation of most tasks within a group, in scenarios where the model is deployed on the UE side and the gNB is required to complete all or part of the data confirmation and collection.

[0259] The first example process for model detection and model update for multi-task learning described above includes:

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

[0261] S2, gNB updates the quality of the input data that needs to be provided by gNB based on gNB's capabilities.

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

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

[0264] S5, UE continues to monitor the performance of all tasks within the group.

[0265] (If performance for most tasks still cannot meet the requirements, proceed to S6)

[0266] S6, the UE sends a model update request to the gNB based on the multi-task model information.

[0267] S7, gNB and UE collaborate to collect multi-task model input data, multi-task model auxiliary data and all task label data in the current scenario based on multi-task model information.

[0268] S8 uses the collected data to update the model parameters of the multi-task model.

[0269] S9, UE continues to monitor the performance of all tasks within the group.

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

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

[0272] S11, based on the gNB's capabilities, update the quality of auxiliary data that needs to be provided by the gNB.

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

[0274] S13, gNB collects auxiliary data based on the updated auxiliary data quality and sends it to UE for model inference.

[0275] Because tasks within a group share the same input data and a portion of the same model parameters (i.e., sharing the parameters of the shared parameter model included in the aforementioned multi-task model), while auxiliary data is typically task-specific. For example, gNB location, as auxiliary data, is specific to the UE positioning task. Therefore, when most tasks experience performance degradation, input data quality issues and model-scene mismatch are more likely to occur, while task-specific auxiliary data quality issues are less likely to occur. Considering that the overhead of updating model parameters is usually much greater than the overhead of updating input data quality, during model updates, the input data quality is updated first, followed by the model parameters, and finally the auxiliary data quality. By taking appropriate model update operations based on the probability of problems occurring from highest to lowest, the overhead of model updates can be reduced on average.

[0276] Figure 16 This is a second example flow illustrating model detection and model updating for multi-task learning according to an embodiment of the present disclosure. Figure 16 The illustrated process is a model update process for a small number of tasks within a group that suffer from performance degradation, in a scenario where the model is deployed on the UE side and the gNB needs to complete all or part of the data confirmation and collection.

[0277] The second example process for model detection and model update for multi-task learning described above includes:

[0278] S1, the UE sends an update auxiliary data quality request to the gNB based on the multi-task model information and the task ID of the performance degradation task.

[0279] S2, based on gNB capabilities, updates the quality of auxiliary data for a small number of performance-degraded tasks that require gNB support.

[0280] S3, the gNB notifies the UE of the updated auxiliary data quality for a few performance-degraded tasks that need to be provided by the gNB.

[0281] S4, gNB collects auxiliary data for a small number of tasks with degraded performance based on the updated auxiliary data quality, and sends it to the UE for model inference.

[0282] S5, the UE continues to monitor the performance of a small number of tasks that experience performance degradation.

[0283] (If the performance of a few tasks with degraded performance still cannot meet the requirements, proceed to S6)

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

[0285] S7, gNB updates the quality of the input data that needs to be provided by gNB based on gNB's capabilities.

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

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

[0288] S10, the UE continues to monitor the performance of a small number of tasks that are experiencing performance degradation.

[0289] (If the performance of a few degraded tasks still cannot meet the requirements, proceed to S11)

[0290] S11, the UE sends a model update request to the gNB based on the multi-task model information and the set of task IDs for a few performance-degraded tasks.

[0291] S12, gNB and UE collaborate to collect, based on multi-task model information and the task ID set of performance degradation tasks, the current scenario's multi-task model input data, multi-task model auxiliary data, and a few performance degradation task label data.

[0292] S13 uses the collected data to update the model parameters of some of the performance-degraded task branches in the multi-task model. Specifically, S13 only updates the model branches of the performance-degraded tasks; the parameters of most normal-performing task branches and models sharing parameters within the task group remain fixed. Generally, since different tasks in a multi-task model are usually decoupled during the model inference phase (except for multi-task cascading), updating only the decoder parameters of a few performance-degraded tasks will not affect the performance of most tasks.

[0293] When performance degrades on only a few tasks, the probability of auxiliary data issues is higher, while the probability of input data quality problems and model-scenario mismatch is lower. Therefore, when updating the model, the auxiliary data quality should be updated first, followed by the input data quality, and finally the model parameters. By taking appropriate model update operations based on the probability of problems occurring from highest to lowest, the average cost of model updates can be reduced. Furthermore, since only a few tasks experience performance degradation, updating model parameters only requires collecting the labels for these few degraded tasks and updating the corresponding model branches, thereby reducing model update overhead.

[0294] Unlike deployment on the UE side, when the multi-task model is deployed on the gNB side, it usually needs to support multiple UEs within the gNB service range. When a few UEs experience performance degradation, the model update operations performed on them cannot affect the inference of the majority of UEs with normal performance. Therefore, when the multi-task model is deployed on the gNB side, the scenarios of task performance degradation are divided into four categories: (1) performance degradation of most tasks for most UEs; (2) performance degradation of a few tasks for most UEs; (3) performance degradation of most tasks for a few UEs; (4) performance degradation of a few tasks for a few UEs.

[0295] To identify scenarios where intra-group task performance degrades, a process for classifying intra-group task performance degrade scenarios is proposed in a scenario where the gNB-based model is deployed and the multi-task model supports multiple UEs within the gNB service range:

[0296] S1, for multiple UEs within the gNB service range and supported by the same multi-task model, preset a threshold for the proportion of multiple UEs whose performance degrades.

[0297] S2, presets the threshold for the proportion of multiple tasks within a group that experience performance degradation.

[0298] S3 sets a preset threshold for each task within the group to determine whether a task experiences performance degradation.

[0299] S4: For each UE, calculate the performance degradation index of all tasks within the group and compare it with the threshold in S3 to determine whether there is a performance degradation for each task within the group for each UE.

[0300] S6. For each UE, calculate the proportion of the number of tasks with performance degradation within the group to the total number of tasks, and compare it with the proportion threshold in S2 to determine whether each UE has most tasks with performance degradation, a few tasks with performance degradation, or no tasks with performance degradation.

[0301] S7, calculate the proportion of UEs with task performance degradation (including most task performance degradation and a few task performance degradation) to the total number of UEs, and compare it with the proportion threshold in S1, thereby classifying the UE performance degradation situation within the gNB service range into most UE performance degradation / a few UE performance degradation.

[0302] Multi-task models deployed on the gNB typically need to support multiple UEs within the gNB service range. When a few UEs experience performance degradation, model update operations performed on them should not affect model inference for the majority of UEs with normal performance.

[0303] According to embodiments of this disclosure, a model update process is proposed for most tasks with degraded performance for most UEs in scenarios where the model is deployed on the gNB and the UE needs to complete all or part of the data confirmation and collection:

[0304] S1, gNB determines the quality of the updated input data that needs to be provided by the UE based on the multi-task model information.

[0305] S2, gNB notifies UEs of the updated quality of input data that needs to be provided by the UE, which has led to performance degradation.

[0306] S3, the UE with degraded performance collects input data based on the updated input data quality and feeds it back to the gNB for model inference.

[0307] S4, gNB continues to monitor the performance of all tasks within the group for all UEs.

[0308] (If the performance of most tasks for most UEs still cannot meet the requirements, proceed to S5)

[0309] S5, gNB sends model update requests to all UEs based on multi-task model information.

[0310] S6, gNB, and all UEs collaborate to collect multi-task model input data, multi-task model auxiliary data, and all task label data within the group for all UEs in the current scenario, based on multi-task model information.

[0311] S7 uses the collected data to update the model parameters of the multi-task model.

[0312] S8 and gNB continue to monitor the performance of all tasks within the group for all UEs.

[0313] (If the performance of most tasks for most UEs still cannot meet the requirements, proceed to S9)

[0314] S9, gNB determines the updated quality of auxiliary data that needs to be provided by the UE based on the multi-task model information.

[0315] S10, gNB notifies UEs of updated auxiliary data quality that needs to be provided by the UE and whose performance has degraded.

[0316] S11, the UE with degraded performance collects auxiliary data based on the updated auxiliary data quality and feeds it back to the gNB for model inference.

[0317] Input and auxiliary data are UE-specific, while the multi-task model is shared by all UEs. Therefore, when updating input and auxiliary data quality, updates can be performed on UEs experiencing performance degradation. However, when updating model parameters, data from all UEs needs to be collected to ensure performance across all UEs. Furthermore, because most tasks on most UEs experience performance degradation, the entire multi-task model may become mismatched with the scenario. Therefore, when updating model parameters, it is necessary to collect label data for all tasks within the group to update the entire multi-task model.

[0318] According to embodiments of this disclosure, a model update process for a small number of tasks that suffers performance degradation for most UEs is proposed in scenarios where the model is deployed on the gNB and the UE needs to complete all or part of the data confirmation and collection:

[0319] S1, gNB determines the quality of the updated auxiliary data for a few tasks that require UE to provide and have degraded performance, based on the multi-task model information.

[0320] S2, gNB notifies the UE of the updated auxiliary data quality for a few performance-degraded tasks that need to be provided by the UE.

[0321] S3, the UE with degraded performance collects auxiliary data for a small number of tasks with degraded performance based on the updated auxiliary data quality, and feeds it back to the gNB for model inference.

[0322] S4, gNB continues to monitor the performance of a small number of tasks with performance degradation within the group for all UEs.

[0323] (If the performance of a few tasks for most UEs still cannot meet the requirements, proceed to S5)

[0324] S5, gNB determines the quality of the updated input data that needs to be provided by the UE based on the multi-task model information.

[0325] S6, gNB notifies UEs of updated input data quality that requires UE input and results in performance degradation.

[0326] S7, the UE with degraded performance collects input data based on the updated input data quality and feeds it back to the gNB for model inference.

[0327] S8, gNB continues to monitor the performance of a small number of tasks with performance degradation within the group for all UEs.

[0328] (If the performance of a few tasks for most UEs still cannot meet the requirements, proceed to S9)

[0329] S9, gNB sends model update requests to all UEs based on multi-task model information and a set of task IDs for a few performance-degraded tasks.

[0330] S10, gNB, and all UEs collaborate to collect multi-task model input data, multi-task model auxiliary data, and a set of task IDs for a few performance-degraded tasks for all UEs in the current scenario, based on multi-task model information and a set of task IDs for a few performance-degraded tasks within the group.

[0331] S11, using the collected data, update the model parameters for the model branches of a few tasks with degraded performance in the multi-task model.

[0332] Most UEs only experience performance degradation on a few tasks. Therefore, the auxiliary data quality should be updated first, followed by the input data quality, and finally the model parameters. It's important to note that when updating model parameters, since most tasks perform normally, only a few task branches in the multi-task model may exhibit performance degradation and be mismatched with the scene. Therefore, it's only necessary to collect label data for these few performance-degraded tasks and update only the corresponding model branches during model updates, thereby reducing model update overhead.

[0333] Figure 17 This is a third example flow illustrating model detection and model updating for multi-task learning according to embodiments of the present disclosure. Figure 17 The illustrated process is a model update process for a small number of UEs where the performance of most tasks is degraded in scenarios where the model is deployed on the gNB side and the UE needs to complete all or part of the data confirmation and collection.

[0334] The third example process for model detection and model update for multi-task learning described above includes:

[0335] S1, gNB determines the quality of the updated input data that needs to be provided by the UE based on the multi-task model information.

[0336] S2, gNB notifies UEs that the quality of the input data required by the UE has been updated and that at least a few UEs have experienced performance degradation.

[0337] S3, a small number of UEs with degraded performance collect input data based on the updated input data quality and feed it back to the gNB for model inference.

[0338] S4, gNB continues to monitor the performance of all tasks within the group of a small number of UEs with degraded performance.

[0339] (If the performance of most tasks for a few UEs with degraded performance still cannot meet the requirements, proceed to S5)

[0340] S5, gNB determines the updated quality of auxiliary data that needs to be provided by the UE based on the multi-task model information.

[0341] S6, gNB notifies UEs that the quality of auxiliary data provided by the UE has been updated to at least a few UEs with degraded performance.

[0342] S7, a small number of UEs with degraded performance collect auxiliary data based on the updated auxiliary data quality and feed it back to the gNB for model inference.

[0343] S8 and gNB continue to monitor the performance of all tasks within the group of a small number of UEs with degraded performance.

[0344] (If the performance of most tasks for a small number of UEs with degraded performance still cannot meet the requirements, proceed to S9)

[0345] S9. Based on the multi-task model information, perform model switching for all tasks of a small number of UEs with degraded performance. Model switching means that the current multi-task model stops supporting a small number of UEs with degraded performance, and activates a new model for these UEs. The new model includes, but is not limited to: (1) a multi-task model trained using training data from different scenarios that implements the same group of tasks; (2) multiple traditional methods that can implement the same group of tasks.

[0346] When only a few UEs experience performance degradation, the multi-task model is generally not updated to ensure overall system performance. Therefore, after updating the input data and auxiliary data quality for a few UEs, a model switch is performed instead of a model update.

[0347] According to embodiments of this disclosure, a model update process is proposed for a small number of UEs experiencing performance degradation in a scenario where the model is deployed at the gNB end and the UE needs to complete all or part of the data confirmation and collection:

[0348] S1, gNB determines the quality of the updated auxiliary data for a few performance-degraded tasks that need to be provided by the UE based on the multi-task model information.

[0349] S2, gNB notifies the UE of the updated auxiliary data quality for a small number of performance-degraded tasks that need to be provided by the UE.

[0350] S3, for a small number of UEs with degraded performance, auxiliary data for a small number of tasks with degraded performance is collected based on the updated auxiliary data quality and fed back to gNB for model inference.

[0351] S4, gNB continues to monitor the performance of a few UEs for a few tasks that cause performance degradation.

[0352] (If the performance of a few tasks with a few performance degradations in a few UEs still cannot meet the requirements, proceed to S5)

[0353] S5, gNB determines the quality of the updated input data that needs to be provided by the UE based on the multi-task model information.

[0354] S6, gNB notifies UEs that have been updated and whose input data quality has degraded to at least a few.

[0355] S7, a small number of UEs with degraded performance collect input data based on the updated input data quality and feed it back to the gNB for model inference.

[0356] S8 and gNB continue to monitor the performance of a few UEs for a few tasks that cause performance degradation.

[0357] (If the performance of a few tasks with a few performance degradations in a few UEs still cannot meet the requirements, proceed to S9)

[0358] S9, based on the multi-task model information, performs model switching for a few performance-degraded tasks of a few UEs. Model switching means that for a few UEs with performance degradation, the multi-task model still supports most of their tasks with normal performance, while ceasing to support the few performance-degraded tasks. For a few performance-degraded tasks of a few UEs, a new model is activated. The new model includes, but is not limited to, multiple traditional methods capable of implementing performance-degraded tasks within the group.

[0359] For a small number of UEs, only a few tasks experience performance degradation, so the multi-task model is still able to support most of the tasks that perform normally for these UEs.

[0360] Even after model updates, some tasks may still fail to achieve satisfactory performance. This could be because the task requires collaboration from multiple base stations. For example, in UE positioning, when there is obstruction between the primary gNB (the gNB currently supporting the UE's AI task) and the UE, resulting in no LOS path, the performance of the UE positioning task will significantly decrease. However, if there is an LOS path between the secondary gNB (gNBs surrounding the primary gNB; the number of secondary gNBs can be multiple or single) and the UE, the positioning performance can be significantly improved by using collaboration between the primary gNB and the secondary gNBs to locate the UE.

[0361] In contrast, we will first describe multi-base station collaboration for single-task learning.

[0362] A single-task multi-base station collaboration process:

[0363] S1, the main gNB performs privacy verification.

[0364] S2, the primary gNB notifies the UE to confirm privacy, and the UE sends the privacy confirmation result back to the primary gNB.

[0365] S3, the primary gNB sends the model ID (including single task ID and input data ID) and UE ID to the secondary gNB.

[0366] S4 assists gNB in ​​privacy verification.

[0367] S5 completes the authentication of the auxiliary gNB terminal single-task model based on the model ID and UE ID.

[0368] S6, based on the model information of the auxiliary gNB single-task model, completes the data collection between the auxiliary gNB and the UE.

[0369] S7 completes the training of the auxiliary gNB single-task model.

[0370] S8, the main gNB and the auxiliary gNB perform joint inference based on the results of their respective single-task models.

[0371] The problems with single-task multi-base station collaboration are as follows. Single-task multi-base station collaboration requires different gNBs to have the same type of input data and the same type of task label data. However, since the capabilities of different gNBs are usually different in real-world scenarios, they may not be able to support acquiring the same type of input data and the same type of task label data, thus posing a challenge to single-task multi-base station collaboration.

[0372] As an example, the processing unit 303 can be configured to cooperate with other electronic devices to perform at least a portion of multiple tasks, wherein 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 300.

[0373] In multi-base station cooperation based on multi-task learning according to embodiments of this disclosure, an auxiliary gNB-side multi-task model is allowed to implement some tasks within the multi-base station cooperation task set to improve the performance of these tasks. The auxiliary gNB-side multi-task model is also allowed to implement tasks outside the multi-base station cooperation task set, which are related to the multi-base station cooperation tasks, to improve the performance of the multi-base station cooperation tasks. Furthermore, the auxiliary gNB-side multi-task model is allowed to use input data of a different type than the primary gNB-side multi-task model; richer input data types can drive the model to have a more comprehensive understanding of the wireless environment, thereby improving the performance of the multi-base station cooperation tasks.

[0374] The capabilities of the auxiliary gNB typically differ from those of the primary gNB. The auxiliary gNB multi-task model can implement some tasks from the multi-base station cooperative task set to improve the performance of those tasks. It can also implement tasks outside the multi-base station cooperative task set, which are related to the multi-base station cooperative tasks, to improve the performance of those tasks. Furthermore, the auxiliary gNB multi-task model can use different types of input data than the primary gNB multi-task model; richer input data types enable the model to have a more comprehensive understanding of the wireless environment, thereby improving the performance of multi-base station cooperative tasks.

[0375] Figure 18 This illustrates a process for multi-task, multi-base station cooperation according to an embodiment of the present disclosure. The process includes:

[0376] S1, based on the multi-task model information, the main gNB determines the set of IDs of tasks with degraded performance within the group.

[0377] S2, the main gNB performs privacy verification.

[0378] S3, the primary gNB selects tasks suitable for multi-base station cooperation based on the set of IDs of performance-degrading tasks within the group and the nature of these tasks. These selected tasks constitute the task ID set for multi-base station cooperation.

[0379] S4, the primary gNB notifies the UE to confirm privacy, and the UE sends the privacy confirmation result back to the primary gNB.

[0380] S5, the primary gNB sends the set of task IDs for multi-base station cooperation and the UE ID to the secondary gNB.

[0381] S6 assists gNB in ​​privacy verification.

[0382] S7, based on the task ID set and UE ID of the multi-base station collaboration, completes the authentication of the auxiliary gNB-side multi-task model. It is important to note that, depending on the capabilities of the auxiliary gNB, the auxiliary gNB-side multi-task model is allowed to implement some tasks from the multi-base station collaboration task set, and tasks outside the multi-base station collaboration task set (these tasks are activated during model training and deactivated during model inference). Simultaneously, the auxiliary gNB-side multi-task model is allowed to use input data of a different type than that of the primary gNB-side multi-task model.

[0383] S8. Based on the model information of the auxiliary gNB multi-task model, perform data collection between the auxiliary gNB and the UE regarding the auxiliary gNB multi-task model.

[0384] S9 completes the training of the multi-task model for the gNB terminal.

[0385] S10, the main gNB and the auxiliary gNB perform joint inference based on the results of their respective multi-task models.

[0386] A dual-end model refers to a model inference process that requires joint operation on both the gNB and the UE. This application considers a common scenario where, to achieve a given task, part of the model is deployed on the gNB and part on the UE. Furthermore, from a lifecycle management perspective, the model inputs on the gNB and UE are similar. Therefore, this application focuses on the dual-end model scenario with UE-side model input.

[0387] To train and deploy the dual-end model, one approach is to train the entire dual-end model at the gNB, and then distribute the shared parameter model (which should be deployed at the UE) to the UE. During the model inference phase, the UE-side model performs inference based on the input data. The inference result, after quantization, is called a codeword. This codeword is fed back to the gNB via the uplink channel as input for the gNB-side model inference, thus completing the joint inference of the dual-end model.

[0388] In contrast, we will first describe the model training, model distribution, and model inference of a dual-end model for single-task learning.

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

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

[0391] S2, gNB queries UE capabilities.

[0392] S3, UE feeds back UE capabilities to gNB.

[0393] S4, gNB determines the input data that needs to be provided by the UE based on the task ID and requirements, UE capabilities and data collection overhead.

[0394] S5, gNB notifies UE that input data needs to be provided by UE.

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

[0396] S7, UE and gNB collaborate to complete the data collection of the dual-end model based on the model information of the single-task dual-end model.

[0397] S8, data migration to gNB.

[0398] S9 and gNB complete the training of the single-task dual-end model.

[0399] S10, gNB distributes a portion of the single-task dual-end model that should be deployed on the UE to the UE.

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

[0401] S1, the UE collects inference data based on the model information of the single-task dual-end model.

[0402] S2, the UE-side model completes UE-side inference based on the inference data and outputs task-specific codewords.

[0403] S3, the UE feeds back the task-specific codeword to the gNB via the uplink channel.

[0404] S4, the gNB uses the received feedback codeword as input to the gNB-side model to complete the inference of the gNB-side model, thereby realizing joint inference of the single-task dual-end model.

[0405] The following are the problems with model training, distribution, and inference for dual-end models designed for single-task learning. The above process has two issues in model training, distribution, and inference: First, single-task learning requires deploying a dual-end model for each task, which incurs significant model distribution overhead when the number of tasks is large. Second, single-task learning requires providing task-specific codewords for each task, which incurs significant model inference feedback overhead when the number of tasks is large.

[0406] In multi-task models, the shared parameter model, which shares model parameters among tasks within a group, extracts representations shared across tasks within the group from the input data. Inspired by this, this application proposes a model training, distribution, and inference approach for multi-task learning. Specifically, the UE-side model is the shared parameter model for shared model parameters among tasks within the group in the multi-task model. Therefore, in the distribution of the dual-end model, only one shared parameter model among tasks needs to be distributed to achieve model distribution for multiple tasks within the group corresponding to the multi-task dual-end model. Simultaneously, the UE-side model extracts a shared representation, i.e., a shared feedback codeword, for each task within the group, thereby significantly reducing the feedback overhead of model inference.

[0407] Figure 19 An example flow diagram of model training and model distribution for a multi-task dual-end model according to embodiments of the present disclosure is shown. Figure 19 As shown, the process includes:

[0408] S1, UE and gNB complete the confirmation of intra-group tasks and task requirements for the dual-end model.

[0409] S2, gNB queries UE capabilities.

[0410] S3, UE feeds back UE capabilities to gNB.

[0411] S4, gNB determines the unified input data that the UE must provide for tasks within the group, based on the task ID and requirements, UE capabilities, and data collection overhead.

[0412] S5, gNB notifies UE that it needs to provide uniform input data.

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

[0414] S7, UE and gNB collaborate to complete the data collection of the dual-end model based on the model information of the multi-task dual-end model.

[0415] S8, training data migrated to gNB.

[0416] S9 and gNB complete the training of the multi-task dual-end model.

[0417] S10, gNB distributes a portion of the model parameters shared by tasks within a group in the multi-task dual-end model to the UE.

[0418] Figure 20 An example flow diagram of model inference in a multi-task dual-end model according to embodiments of the present disclosure is shown. Figure 20 As shown, the process includes:

[0419] S1, the UE collects inference data based on the model information of the multi-task dual-end model.

[0420] S2, the UE-side model completes UE-side inference based on the inference data and outputs the shared codewords for tasks within the group.

[0421] S3, the UE feeds back the shared codeword to the gNB via the uplink channel.

[0422] S4, the gNB uses the received feedback codewords as input to the specific model branches of each task on the gNB side to complete the inference of the gNB side model, thereby realizing the joint inference of the multi-task dual-end model.

[0423] As an example, when electronic device 300 is a network-side device (e.g., gNB): for the user equipment side multitasking model, based on the channel conditions where the user equipment is located and / or capability information representing the capabilities of the user equipment, an instruction is given to the user equipment to adopt a monitoring format for monitoring the multitasking model; and when electronic device 300 is a user equipment: for the electronic device side multitasking model, an instruction is received from the network-side device regarding the monitoring format to be adopted for monitoring the multitasking model, wherein the monitoring format is determined by the network-side device based on the channel conditions where the electronic device is located and / or capability information representing the capabilities of the electronic device.

[0424] 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 reusing at least a portion of historical measurement information for multiple tasks, and in the second monitoring format, for multiple monitoring, the measurement information used in each monitoring does not overlap.

[0425] When electronic device 300 is a network-side device (e.g., gNB), the description of the indication detection format can be found in the description of the embodiment of electronic device 100. That is, electronic device 300 has the same functions as electronic device 100, and will not be repeated here.

[0426] When electronic device 300 is a user equipment, the description of the indication detection format can be found in the description of the embodiment of electronic device 200. That is, electronic device 300 has the same functions as electronic device 200, and will not be repeated here.

[0427] Consider using an AI model to simultaneously perform beam prediction and localization tasks. Since the optimal beam index label reflects the angle information of multipath transmission between the UE and gNB, and the user location label contains the location information between the UE and gNB, these two labels reflect different aspects of the physical characteristics of the same wireless environment. Therefore, these two tasks are correlated, and multi-task learning can be used to improve the performance of each task. The input data for the multi-task learning model is the RSRP of the beam training historically.

[0428] To model the wireless channel, the Saleh-Valenzuela channel model was used to calculate the CSI based on the characteristics of each path, such as attenuation, delay, angle of arrival, and angle of departure. Specific simulation parameters are shown in Table 1.

[0429] parameter Value Scene Outdoor 1 gNB Index 1 UE speed 20m / s Center frequency 28GHz UE large line number 1 Number of gNB antennas 32 gNB Alternate Beams 32 Time sampling period 160ms RSRP signal-to-noise ratio 5dB

[0430] Table 1 Channel Simulation Parameters

[0431] Since the RSRP (Real-Short Memory Relationship) trained on historical beams is used to predict future optimal beam indices and user locations, the multi-task model requires time series processing. This application employs a combination of Convolutional Neural Networks (CNN) and Long Short-Term Memory Neural Networks (LSTM) to achieve time series processing, where CNN is used to extract spatial correlations and LSTM is used to extract temporal correlations. The multi-task model includes a shared parameter model with shared model parameters within the group and two model branches for beam prediction and localization tasks, respectively. The specific structure and parameters are shown in Table 2-4. Where f i f o represents the number of input and output feature channels, respectively; (a, b, c) represent the kernel size, downsampling stride, and edge padding size of the convolutional layer, respectively; BatchNorm refers to batch normalization; Global AvgPooling refers to global average pooling; and ReLU refers to the ReLU activation function.

[0432] structure parameter Convolutional layer <![CDATA[f i =2,f o =64,(3,3,1),BatchNorm,ReLU]]> Convolutional layer <![CDATA[f i =64,f o =64,(3,3,1),BatchNorm,ReLU]]> Convolutional layer <![CDATA[f i =64,f o =128,(3,3,1),BatchNorm,ReLU]]> Pooling layer <![CDATA[f i =128,f o =128,Global AvgPooling]]> LSTM <![CDATA[f i =128,f o =64]]>

[0433] Table 2. Parameters of the Intra-Group Task Sharing Model: Structure and Parameters

[0434] structure parameter Convolutional layer <![CDATA[f i =2,f o =64,(3,3,1),BatchNorm,ReLU]]> Convolutional layer <![CDATA[f i =64,f o =64,(3,3,1),BatchNorm,ReLU]]> Convolutional layer <![CDATA[f i =64,f o =64,(3,3,1),BatchNorm,ReLU]]> Pooling layer <![CDATA[f i =64,f o =64,Global AvgPooling]]> Fully connected layer <![CDATA[f i =64,f o =32]]>

[0435] Table 3. Structure and parameters of the model branches for the beam prediction task.

[0436] structure parameter Convolutional layer <![CDATA[f i =2,f o =64,(3,3,1),BatchNorm,ReLU]]> Convolutional layer <![CDATA[f i =64,f o =64,(3,3,1),BatchNorm,ReLU]]> Convolutional layer <![CDATA[f i =64,f o =64,(3,3,1),BatchNorm,ReLU]]> Pooling layer <![CDATA[f i =64,f o =64,Global AvgPooling]]> Fully connected layer <![CDATA[f i =64,f o =2]]>

[0437] Table 4. Structure and parameters of the model branches for the localization task.

[0438] To train the proposed multi-task model, this application employs a combination of the cross-entropy loss function of beam prediction and the mean square error loss function of UE positioning:

[0439]

[0440] Where, p n This indicates whether the nth beam index in the label is the optimal beam index (when it is the optimal beam index, p) n =1; otherwise, p n =0). N is the number of alternative beams. This is a probability prediction for the multi-task model regarding whether the nth beam index is the optimal beam index. x and y are the two-dimensional coordinates of the UE's position in the tag. and This represents the prediction of the UE's two-dimensional location coordinates by the multi-task model. μ is a weighted hyperparameter used to balance the losses of the beam prediction and localization tasks. The larger μ is, the more the multi-task model is trained, favoring the localization task.

[0441] To demonstrate the effectiveness of multi-task learning, this application compares the multi-task model with a single-task model dedicated to beam prediction and a single-task model dedicated to localization. Furthermore, for a fair comparison, the parameter counts of each model are summarized in Table 5. The number of parameters in the multi-task model is slightly less than the sum of the parameter counts of the two single-task models mentioned above.

[0442] Model Parameters Single-task model specifically for beam prediction 70722 Single-task model specifically for localization 72672 The two single-task models mentioned above 143394 Multi-task model 133058

[0443] Table 5. Decoder structure and parameters for the localization task.

[0444] Furthermore, this application evaluates the accuracy of beam prediction and the average positioning error. Assume the total number of samples is N. sum The optimal beam index for beam prediction is N, where the number of samples with the optimal beam index in the label is N. acc The accuracy of beam prediction is then...

[0445]

[0446] The average positioning error is

[0447]

[0448] Figure 21 This is a graph comparing the beam prediction accuracy of a multi-task model and a single-task model dedicated to beam prediction. Figure 21 In the diagram, the weighted hyperparameter μ is used as the x-axis. 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 weighted hyperparameter μ. In contrast, it can be seen that the weighted hyperparameter μ affects the training of the multi-task model, and the larger the weighted hyperparameter μ is, the more the training of the multi-task model is biased towards the localization task. Therefore, as the weighted hyperparameter μ increases, the beam prediction accuracy of the multi-task model generally shows a downward trend.

[0449] Figure 22 This is a graph comparing the average localization error of a multi-task model and a single-task model dedicated to localization. Figure 22 In the diagram, the weighted hyperparameter μ is used as the x-axis. It can be seen that as the weighted hyperparameter μ increases, the average localization error of the multi-task model generally shows a downward trend. This is because the larger the weighted hyperparameter μ, the more the multi-task model's training is biased towards the localization task.

[0450] Furthermore, through comparison Figure 21 and Figure 22 As can be seen, with the increase of the weighting hyperparameter μ, since the training of the multi-task model is more biased towards the localization task, the overall trend is a decrease in beam prediction accuracy and a decrease in average localization error. However, by setting an appropriate weighting hyperparameter μ, for example in... Figure 21 and Figure 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, it achieves better performance in both tasks.

[0451] Furthermore, it's important to note that as the weighted hyperparameter μ increases, the average localization error of the multi-task model does not invariably decrease. Conversely, as the weighted hyperparameter μ decreases, the beam prediction accuracy of the multi-task model does not invariably improve. This is because when the training of a multi-task model is entirely biased towards a single task, it cannot leverage inter-task correlations to improve the performance of each task. Instead, the performance of that task in multi-task learning tends to approach the performance of that task in single-task learning.

[0452] In summary, the proposed multi-task learning scheme achieves better performance with fewer model parameters compared to single-task learning schemes by leveraging the correlation between tasks.

[0453] In the process of describing electronic devices 100, 200, and 300 in the embodiments described above, some processes or methods have obviously also been disclosed. Hereinafter, without repeating some details already discussed above, a summary of these methods is given. However, it should be noted that although these methods are disclosed in the description of the above electronic devices, these methods do not necessarily employ or are performed by the components described. For example, the embodiments of the above electronic devices can be implemented partially or entirely using hardware and / or firmware, while the methods discussed below can be implemented entirely by computer-executable programs, although these methods can also be implemented using the hardware and / or firmware of the electronic device.

[0454] Figure 23 A flowchart of a method S2300 for wireless communication according to an embodiment of the present disclosure is shown. Method S2300 begins at step S2302. In step S2304, for a task model on the user equipment side used to implement a task, based on the channel conditions of the user equipment and / or capability information representing the capabilities of the user equipment, a monitoring format for monitoring the task model is indicated to be adopted by the user equipment. Method S2300 ends at step S2306.

[0455] This method can be executed, for example, by the electronic device 100 described above. For details, please refer to the above description of the relevant processing of the electronic device 100, which will not be repeated here.

[0456] Figure 24 A flowchart of a method S2400 for wireless communication according to another embodiment of this disclosure is shown. Method S2400 begins at step S2402. In step S2404, for a task model on the electronic device side for implementing a task, an indication is received from a network-side device regarding a monitoring format to be adopted for monitoring the task model, wherein the monitoring format is determined by the network-side device based on the channel conditions in which the electronic device is located and / or capability information representing the capabilities of the electronic device. Method S2400 ends at step S2406.

[0457] This method can be executed, for example, by the electronic device 200 described above. For details, please refer to the above description of the relevant processing of the electronic device 200, which will not be repeated here.

[0458] Figure 25A flowchart of a method S2500 for wireless communication according to another embodiment of the present disclosure is shown. Method S2500 begins at step S2502. In step S2504, multiple tasks are implemented simultaneously using a multi-task model, wherein the multi-task model includes a shared parameter model whose model parameters are shared by the multiple tasks, and model branches corresponding to at least a portion of the multiple tasks. Method S2500 ends at step S2506.

[0459] This method can be executed, for example, by the electronic device 300 described above. For details, please refer to the description of the relevant processing of the electronic device 300 above, which will not be repeated here.

[0460] The technology disclosed herein can be applied to a variety of products.

[0461] Electronic devices 100 and 300 can be located on the base station side or connected to the base station. The base station can be implemented as any type of evolved NodeB (eNB) or gNB (5G base station). eNBs include, for example, macro eNBs and small eNBs. Small eNBs can be eNBs covering cells smaller than macro cells, such as pico eNBs, micro eNBs, and femtocell eNBs. A similar situation can occur with gNBs. Alternatively, the base station can be implemented as any other type of base station, such as a NodeB and a Base Transceiver Station (BTS). A base station can include: a main body configured to control wireless communication (also called base station equipment); and one or more remote radio heads (RRHs) located in a different location from the main body. Furthermore, various types of electronic devices can operate as base stations by temporarily or semi-persistently performing base station functions.

[0462] Electronic devices 200 and 300 can be implemented as various user devices. User devices can be implemented as mobile terminals (such as smartphones, tablet PCs, laptop PCs, portable gaming terminals, portable / dongle-type mobile routers, and digital camera devices) or in-vehicle terminals (such as car navigation devices). User devices can also be implemented as terminals performing machine-to-machine (M2M) communication (also known as machine-type communication (MTC) terminals). Furthermore, user devices can be wireless communication modules (such as integrated circuit modules comprising a single chip) installed on each of the aforementioned terminals.

[0463] [Application examples of base stations]

[0464] (First application example)

[0465] Figure 26This is a block diagram illustrating a first example of a schematic configuration of an eNB or gNB to which the technologies of this disclosure can be applied. Note that the following description uses an eNB as an example, but it can also be applied to a gNB. The 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 RF cables.

[0466] Each of the antennas 810 includes one or more antenna elements (such as multiple antenna elements included in a multiple-input multiple-output (MIMO) antenna) and is used by the base station equipment 820 to transmit and receive wireless signals. Figure 26 As shown, the eNB 800 may include multiple antennas 810. For example, the multiple antennas 810 may be compatible with multiple frequency bands used by the eNB 800. Although Figure 26 An example is shown in which the eNB 800 includes multiple antennas 810, but the eNB 800 may also include a single antenna 810.

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

[0468] The controller 821 can be, for example, a CPU or a DSP, and operates various higher-level functions of the base station equipment 820. For example, the controller 821 generates data packets based on data in signals processed by the wireless communication interface 825, and transmits the generated packets via the network interface 823. The controller 821 can bundle data from multiple baseband processors to generate bundled packets and transmit the generated bundled packets. The controller 821 may have logical functions that perform controls such as radio resource control, radio bearer control, mobility management, admission control, and scheduling. This control can be performed in conjunction with nearby eNBs or core network nodes. The memory 822 includes RAM and ROM, and stores programs executed by the controller 821 and various types of control data (such as terminal lists, transmission power data, and scheduling data).

[0469] Network interface 823 is a communication interface used to connect base station equipment 820 to core network 824. Controller 821 can communicate with core network nodes or other eNBs via network interface 823. In this case, eNB 800 and core network nodes or other eNBs can be connected to each other through logical interfaces (such as S1 and X2 interfaces). Network interface 823 can also be a wired communication interface or a wireless communication interface for wireless backhaul. If network interface 823 is a wireless communication interface, it can use a higher frequency band for wireless communication compared to the frequency band used by wireless communication interface 825.

[0470] The wireless communication interface 825 supports any cellular communication scheme (such as LTE and LTE-Advanced) and provides wireless connectivity to terminals located in the cell of eNB 800 via antenna 810. The wireless communication interface 825 typically includes, for example, a baseband (BB) processor 826 and RF circuitry 827. The BB processor 826 can perform, for example, encoding / decoding, modulation / demodulation, and multiplexing / demultiplexing, and performs various types of signal processing at layers (e.g., Layer 1, Medium Access Control (MAC), Radio Link Control (RLC), and Packet Data Convergence Protocol (PDCP)). Instead of controller 821, the BB processor 826 can have some or all of the above-described logical functions. The BB processor 826 can be a memory storing communication control programs, or a module including a processor and associated circuitry configured to execute programs. Update programs can change the functionality of the BB processor 826. The module can be a card or blade inserted into a slot in base station equipment 820. Alternatively, the module can also be a chip mounted on a card or blade. Meanwhile, the RF circuit 827 may include, for example, a mixer, a filter, and an amplifier, and transmits and receives wireless signals via the antenna 810.

[0471] like Figure 26 As shown, the wireless communication interface 825 may include multiple BB processors 826. For example, the multiple BB processors 826 may be compatible with multiple frequency bands used by the eNB 800. Figure 26 As shown, the wireless communication interface 825 may include multiple RF circuits 827. For example, the multiple RF circuits 827 may be compatible with multiple antenna elements. Although Figure 26 An example is shown in which the wireless communication interface 825 includes multiple BB processors 826 and multiple RF circuits 827, but the wireless communication interface 825 may also include a single BB processor 826 or a single RF circuit 827.

[0472] Electronic devices 100 and 300 when implemented as Figure 26 In the case of the eNB 800 shown, its transceiver can be implemented by the wireless communication interface 825. At least a portion of the functionality 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 electronic devices 100 and 300.

[0473] (Second application example)

[0474] Figure 27This is a block diagram illustrating a second example of a schematic configuration of an eNB or gNB to which the technologies of this disclosure can be applied. Note that, similarly, the following description uses an eNB as an example, but it can also be applied to a gNB. The eNB 830 includes one or more antennas 840, a base station device 850, and an RRH 860. The RRH 860 and each antenna 840 can be connected to each other via RF cables. The base station device 850 and the RRH 860 can be connected to each other via high-speed lines such as fiber optic cables.

[0475] Each of the antennas 840 includes one or more antenna elements (such as multiple antenna elements included in a MIMO antenna) and is used by the RRH 860 to transmit and receive wireless signals. Figure 27 As shown, the eNB 830 may include multiple antennas 840. For example, the multiple antennas 840 may be compatible with multiple frequency bands used by the eNB 830. Although Figure 27 An example is shown in which the eNB 830 includes multiple antennas 840, but the eNB 830 may also include a single antenna 840.

[0476] The base station equipment 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, memory 852, and network interface 853 are connected to a reference... Figure 27 The controller 821, memory 822, and network interface 823 described are the same.

[0477] The wireless communication interface 855 supports any cellular communication scheme (such as LTE and LTE-Advanced) and provides wireless communication to terminals located in the sector corresponding to the RRH 860 via the RRH 860 and antenna 840. The wireless communication interface 855 may typically include, for example, a BB processor 856. In addition to the BB processor 856 being connected to the RF circuitry 864 of the RRH 860 via a connection interface 857, the BB processor 856 is connected to the reference... Figure 27 The described BB processor 826 is the same. Figure 27 As shown, the wireless communication interface 855 may include multiple BB processors 856. For example, the multiple BB processors 856 may be compatible with multiple frequency bands used by the eNB 830. Although Figure 27 An example is shown in which the wireless communication interface 855 includes multiple BB processors 856, but the wireless communication interface 855 may also include a single BB processor 856.

[0478] Connection interface 857 is an interface for connecting base station device 850 (wireless communication interface 855) to RRH 860. Connection interface 857 can also be a communication module for connecting base station device 850 (wireless communication interface 855) to the aforementioned high-speed line of RRH 860.

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

[0480] 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.

[0481] The wireless communication interface 863 transmits and receives wireless signals via antenna 840. The wireless communication interface 863 typically includes, for example, RF circuitry 864. RF circuitry 864 may include, for example, a mixer, a filter, and an amplifier, and transmits and receives wireless signals via antenna 840. Figure 27 As shown, the wireless communication interface 863 may include multiple RF circuits 864. For example, the multiple RF circuits 864 may support multiple antenna elements. Although Figure 27 An example is shown in which the wireless communication interface 863 includes multiple RF circuits 864, but the wireless communication interface 863 may also include a single RF circuit 864.

[0482] Electronic devices 100 and 300 when implemented as Figure 27 In the case of the eNB 830 shown, its transceiver can be implemented by the wireless communication interface 855. At least a portion of the functionality can also be implemented by the controller 851. For example, the 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.

[0483] [Application examples related to user equipment]

[0484] (First application example)

[0485] Figure 28 This is a block diagram illustrating an example of a schematic configuration of a smartphone 900 to which the technologies 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.

[0486] 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.

[0487] The camera device 906 includes an image sensor (such as a charge-coupled device (CCD) and complementary metal-oxide-semiconductor (CMOS)) and generates captured images. The sensor 907 may include a set of sensors, such as a measurement sensor, a gyroscope sensor, a magnetometer sensor, and an accelerometer sensor. The microphone 908 converts sound input to the smartphone 900 into an audio signal. The input device 909 includes, for example, a touch sensor, keypad, keyboard, buttons, or switches configured to detect touches on the screen of the display device 910 and receives operations or information input from the 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 the output image of the smartphone 900. The speaker 911 converts the audio signal output from the smartphone 900 into sound.

[0488] 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 typically includes, for example, a BB processor 913 and RF circuitry 914. The BB processor 913 can perform, for example, encoding / decoding, modulation / demodulation, and multiplexing / demultiplexing, and performs various types of signal processing for wireless communication. Meanwhile, the RF circuitry 914 can include, for example, mixers, filters, and amplifiers, and transmits and receives wireless signals via antenna 916. Note that although the figure shows a scenario where one RF link is connected to one antenna, this is only illustrative; scenarios where an RF link is connected to multiple antennas via multiple phase shifters are also included. The wireless communication interface 912 can be a single chip module on which the BB processor 913 and RF circuitry 914 are integrated. Figure 28 As shown, the wireless communication interface 912 may include multiple BB processors 913 and multiple RF circuits 914. Although Figure 28 An example is shown in which the wireless communication interface 912 includes multiple BB processors 913 and multiple RF circuits 914, but the wireless communication interface 912 may also include a single BB processor 913 or a single RF circuit 914.

[0489] In addition to cellular communication schemes, the wireless communication interface 912 can support other types of wireless communication schemes, such as short-range wireless communication schemes, near-field communication schemes, and wireless local area network (LAN) schemes. In this case, the wireless communication interface 912 may include a BB processor 913 and RF circuitry 914 for each wireless communication scheme.

[0490] Each of the antenna switches 915 switches the connection destination of the antenna 916 among multiple circuits (e.g., circuits for different wireless communication schemes) included in the wireless communication interface 912.

[0491] Each of the antennas 916 includes one or more antenna elements (such as multiple antenna elements included in a MIMO antenna) and is used by the wireless communication interface 912 to transmit and receive wireless signals. Figure 28 As shown, the smartphone 900 may include multiple antennas 916. Although Figure 28 An example is shown in which the smartphone 900 includes multiple antennas 916, but the smartphone 900 may also include a single antenna 916.

[0492] Furthermore, the smartphone 900 may 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.

[0493] Bus 917 connects processor 901, memory 902, storage device 903, external connection interface 904, camera device 906, sensor 907, microphone 908, input device 909, display device 910, speaker 911, wireless communication interface 912, and auxiliary controller 919 to each other. Battery 918 supplies power to... Figure 28 The various blocks of the smartphone 900 shown are powered, and the feeders are partially shown as dashed lines in the figure. The auxiliary controller 919 operates the minimum necessary functions of the smartphone 900, for example, in sleep mode.

[0494] When electronic devices 200 and 300 are respectively implemented as smartphones on the user equipment side, for example... Figure 28 In the case of the smartphone 900 shown, the transceivers of electronic devices 200 and 300 can be implemented by the wireless communication interface 912. At least a portion of the functionality can also be implemented by the processor 901 or the auxiliary controller 919. For example, the processor 901 or the auxiliary controller 919 performs wireless communication using a task model as an AI model by executing the functions of the units in the aforementioned electronic devices 200 and 300.

[0495] (Second application example)

[0496] Figure 29This is a block diagram illustrating an example of a schematic configuration of a car navigation device 920 to which the technology of this 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.

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

[0498] GPS module 924 uses GPS signals received from GPS satellites to measure the location (such as latitude, longitude, and altitude) of car navigation device 920. Sensor 925 may include a set of sensors, such as a gyroscope sensor, a geomagnetic sensor, and an air pressure sensor. 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).

[0499] Content player 927 reproduces content stored on storage media (such as CDs and DVDs), which is inserted into storage media interface 928. Input device 929 includes, for example, a touch sensor, button, or switch configured to detect touch on the screen of display device 930, and receives operations or information input from the user. Display device 930 includes a screen such as an LCD or OLED display and displays images or reproduced content for navigation functions. Speaker 931 outputs sound for navigation functions or reproduced content.

[0500] 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 typically includes, for example, a BB processor 934 and RF circuitry 935. The BB processor 934 can perform, for example, encoding / decoding, modulation / demodulation, and multiplexing / demultiplexing, and performs various types of signal processing for wireless communication. Meanwhile, the RF circuitry 935 can include, for example, a mixer, filters, and amplifiers, and transmits and receives wireless signals via an antenna 937. The wireless communication interface 933 can also be a chip module on which the BB processor 934 and RF circuitry 935 are integrated. Figure 29 As shown, the wireless communication interface 933 may include multiple BB processors 934 and multiple RF circuits 935. Although Figure 29An example is shown in which the wireless communication interface 933 includes multiple BB processors 934 and multiple RF circuits 935, but the wireless communication interface 933 may also include a single BB processor 934 or a single RF circuit 935.

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

[0502] Each of the antenna switches 936 switches the connection destination of the antenna 937 among multiple circuits (such as circuits for different wireless communication schemes) included in the wireless communication interface 933.

[0503] Each of the antennas 937 includes one or more antenna elements (such as multiple antenna elements included in a MIMO antenna) and is used by the wireless communication interface 933 to transmit and receive wireless signals. Figure 29 As shown, the car navigation device 920 may include multiple antennas 937. Although Figure 29 An example is shown in which the car navigation device 920 includes multiple antennas 937, but the car navigation device 920 may also include a single antenna 937.

[0504] Furthermore, the car navigation device 920 may 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.

[0505] Battery 938 via feeder to Figure 29 The various blocks of the car navigation device 920 shown are powered, and the feeders are partially shown as dashed lines in the figure. Battery 938 accumulates the power supplied from the vehicle.

[0506] When electronic devices 200 and 300 are respectively implemented as car navigation devices on the user equipment side, for example... Figure 29 In the case of the illustrated car navigation device 920, the transceivers of electronic devices 200 and 300 can be implemented by the wireless communication interface 933. At least a portion of the functionality 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 aforementioned electronic devices 200 and 300.

[0507] The technology disclosed herein can also be implemented as an in-vehicle system (or vehicle) 940 comprising one or more of the following blocks: a car navigation device 920, an in-vehicle network 941, and a vehicle module 942. The vehicle module 942 generates vehicle data (such as vehicle speed, engine speed, and fault information) and outputs the generated data to the in-vehicle network 941.

[0508] The basic principles of the present invention have been described above in conjunction with specific embodiments. However, it should be noted that those skilled in the art will understand that all or any step or component of the method and apparatus of the present invention 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. This can be achieved by those skilled in the art using their basic circuit design knowledge or basic programming skills after reading the description of the present invention.

[0509] Furthermore, this invention also proposes a program product storing machine-readable instruction code. When the instruction code is read and executed by a machine, the method described above according to embodiments of the present invention can be performed.

[0510] Accordingly, the storage medium used to carry the program product storing the machine-readable instruction code is also included in the disclosure of this invention. Storage media include, but are not limited to, floppy disks, optical disks, magneto-optical disks, memory cards, memory sticks, etc.

[0511] When the present invention is implemented via software or firmware, the transmission from a storage medium or network to a computer with a dedicated hardware architecture (e.g., Figure 30 The general-purpose computer 3000 shown is equipped with the programs that constitute the software, and when various programs are installed, the computer is able to perform various functions, etc.

[0512] exist Figure 30 In this system, the Central Processing Unit (CPU) 3001 performs various processes based on programs stored in the Read-Only Memory (ROM) 3002 or programs loaded into the Random Access Memory (RAM) 3003 from the Storage Section 3008. The RAM 3003 also stores data required as needed when the CPU 3001 performs various processes. The CPU 3001, ROM 3002, and RAM 3003 are interconnected via a bus 3004. An input / output interface 3005 is also connected to the bus 3004.

[0513] The following components are connected to the input / output interface 3005: input section 3006 (including keyboard, mouse, etc.), output section 3007 (including monitors, such as cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.), storage section 3008 (including hard disk, etc.), and communication section 3009 (including network interface cards such as LAN cards, modems, etc.). The communication section 3009 performs communication processing via a network such as the Internet. If necessary, a drive 3010 may also be connected to the input / output interface 3005. Removable media 3011, such as disks, optical disks, magneto-optical disks, semiconductor memories, etc., are installed on the drive 3010 as needed, so that computer programs read from them can be installed into the storage section 3008 as needed.

[0514] When the above series of processes are implemented through software, the program constituting the software is installed from a network such as the Internet or a storage medium such as removable media 3011.

[0515] Those skilled in the art will understand that such storage media are not limited to Figure 30 The illustration shows a removable medium 3011 containing a program, distributed separately from the device to provide the program to the user. Examples of removable media 3011 include disks (including floppy disks (registered trademark)), optical disks (including optical disc read-only memory (CD-ROM) and digital versatile disks (DVD)), magneto-optical disks (including mini-discs (MD) (registered trademark)), and semiconductor memory. Alternatively, the storage medium may be ROM 3002, a hard disk included in storage section 3008, etc., containing programs and distributed to the user along with the device containing them.

[0516] It should also be noted that in the apparatus, method, and system of the present invention, the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered equivalent solutions of the present invention. Furthermore, the steps performing the above series of processes can naturally be executed in the order described, but are not necessarily required to be executed in chronological order. Some steps can be performed in parallel or independently of each other.

[0517] Finally, it should be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Furthermore, unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0518] While embodiments of the present invention have been described in detail above with reference to the accompanying drawings, it should be understood that the embodiments described above are merely illustrative and do not constitute a limitation thereof. Those skilled in the art can make various modifications and alterations to the above embodiments without departing from the spirit and scope of the present invention. Therefore, the scope of the present invention is defined only by the appended claims and their equivalents.

[0519] This technology can also be implemented as follows.

[0520] Option 1. An electronic device for wireless communication, comprising:

[0521] At least one processor; and

[0522] At least one memory, including computer program code, wherein the at least one memory and the computer program code are configured to cause the electronic device to execute via the at least one processor:

[0523] For a task model used to implement a task on the user equipment side, based on the channel conditions where the user equipment is located and / or capability information representing the capabilities of the user equipment, an indication is given of the monitoring format to be adopted by the user equipment for monitoring the task model.

[0524] Option 2. The electronic device according to Option 1, wherein,

[0525] The monitoring format is either a first monitoring format or a second monitoring format.

[0526] In the first monitoring format, multiple monitoring operations are performed by reusing at least a portion of historical measurement information for the task.

[0527] In the second monitoring format, for multiple monitoring sessions, the measurement information for the task used in each monitoring session does not overlap.

[0528] Option 3. The electronic device according to Option 2, wherein the at least one memory and the computer program code are configured to cause the electronic device to execute, via the at least one processor:

[0529] When instructing the user equipment to use the first monitoring format, the instruction specifies the time-domain information of at least a portion of the multiplexed historical measurement information in the time domain.

[0530] The time-domain information includes the starting point of at least a portion of the multiplexed historical measurement information in the time domain and the length of at least a portion of the multiplexed historical measurement information in the time domain.

[0531] Option 4. The electronic device according to Option 2 or 3, wherein the at least one memory and the computer program code are configured to cause the electronic device to execute, via the at least one processor:

[0532] If the channel is determined to be a slow fading channel based on the channel conditions, the first monitoring format is indicated to the user equipment, and

[0533] If the channel is determined to be a fast fading channel based on the channel conditions, the second monitoring format is indicated to the user equipment.

[0534] Option 5. The electronic device according to any one of Options 1 to 4, wherein the channel condition includes Channel State Information (CSI).

[0535] Option 6. The electronic device according to Option 2 or 3, wherein the at least one memory and the computer program code are configured to cause the electronic device to execute, via the at least one processor:

[0536] If the capability information meets predetermined conditions, the first monitoring format is indicated to the user equipment, and

[0537] If the capability information does not meet the predetermined conditions, the second monitoring format is indicated to the user equipment.

[0538] Option 7. The electronic device according to any one of Options 1 to 6, wherein,

[0539] The user equipment executes the task model N times by reusing some historical measurement information for the task, thereby obtaining N execution results. Based on the execution results, it determines the stability of the task model and makes inferences about the task model.

[0540] Where N is a positive integer greater than 1.

[0541] Option 8. The electronic device according to Option 7, wherein the at least one memory and the computer program code are configured to cause the electronic device to execute, via the at least one processor:

[0542] If the inference result indicates that the stability of the task model is less than a predetermined stability threshold, then the user equipment reports an event reflecting that the stability is less than the predetermined stability threshold.

[0543] The decision to trigger monitoring of the task model is based on the event.

[0544] Option 9. The electronic device according to Option 7, wherein the at least one memory and the computer program code are configured to cause the electronic device to execute, via the at least one processor:

[0545] Specify a predetermined number of times the task model is executed during the inference for the user equipment.

[0546] Wherein, the predetermined number of times is greater than or equal to N.

[0547] Option 10. An electronic device according to any one of Options 1 to 9, wherein the task includes predicting a beam, and the task model includes a beam prediction model for predicting the beam.

[0548] Option 11. The electronic device according to Option 10, wherein,

[0549] The beam prediction model is used to perform multiple beam predictions, thereby monitoring the prediction accuracy of the beam prediction model multiple times, in order to improve the prediction accuracy of the beam prediction model for future candidate beams.

[0550] Option 12. The electronic device according to any one of Options 1 to 11, wherein,

[0551] The task model is a multi-task model used to simultaneously implement multiple tasks, and

[0552] The multi-task model includes a shared parameter model in which model parameters are shared by the multiple tasks, and model branches that correspond to at least a portion of the multiple tasks.

[0553] Option 13. The electronic device according to Option 12, wherein,

[0554] The shared parameter model extracts a shared representation shared by the multiple tasks from the input data, and

[0555] Each model branch is used to determine the mapping from the shared representation to the label of the task corresponding to that model branch.

[0556] Option 14. An electronic device for wireless communication, comprising:

[0557] At least one processor; and

[0558] At least one memory, including computer program code, wherein the at least one memory and the computer program code are configured to cause the electronic device to execute via the at least one processor:

[0559] For the task model used to implement the task on the electronic device side, an instruction is received from the network-side device regarding the monitoring format to be used for monitoring the task model.

[0560] The monitoring format is determined by the network-side device based on the channel conditions of the electronic device and / or capability information representing the capabilities of the electronic device.

[0561] Option 15. The electronic device according to Option 14, wherein,

[0562] The monitoring format is either a first monitoring format or a second monitoring format.

[0563] In the first monitoring format, multiple monitoring operations are performed by reusing at least a portion of historical measurement information for the task.

[0564] In the second monitoring format, for multiple monitoring sessions, the measurement information for the task used in each monitoring session does not overlap.

[0565] Option 16. The electronic device according to Option 15, wherein the at least one memory and the computer program code are configured to cause the electronic device to execute, via the at least one processor:

[0566] Upon receiving an indication regarding the first monitoring format from the network-side device, an indication is also received regarding the time-domain information of at least a portion of the multiplexed historical measurement information in the time domain.

[0567] The time-domain information includes the starting point of at least a portion of the multiplexed historical measurement information in the time domain and the length of at least a portion of the multiplexed historical measurement information in the time domain.

[0568] Option 17. The electronic device according to Option 15 or 16, wherein the at least one memory and the computer program code are configured to cause the electronic device to execute, via the at least one processor:

[0569] When the network-side device determines that the channel is a slow fading channel based on the channel conditions, it receives an indication from the network-side device regarding the first monitoring format, and

[0570] When the network-side device determines that the channel is a fast fading channel based on the channel conditions, it receives an indication from the network-side device regarding the second monitoring format.

[0571] Option 18. An electronic device according to any one of Options 14 to 17, wherein the channel condition includes Channel State Information (CSI).

[0572] Option 19. The electronic device according to Option 15 or 16, wherein the at least one memory and the computer program code are configured to cause the electronic device to execute, via the at least one processor:

[0573] When the capability information meets predetermined conditions, an instruction regarding the first monitoring format is received from the network-side device, and

[0574] If the capability information does not meet the predetermined conditions, an instruction regarding the second monitoring format is received from the network-side device.

[0575] Option 20. The electronic device according to any one of Options 14 to 19, wherein,

[0576] By reusing some historical measurement information for the task, the task model is executed N times to obtain N execution results. Based on the execution results, the stability of the task model is determined, thereby making inferences about the task model.

[0577] Where N is a positive integer greater than 1.

[0578] Option 21. The electronic device according to Option 20, wherein the at least one memory and the computer program code are configured to cause the electronic device to execute, via the at least one processor:

[0579] If the inference results indicate that the stability of the task model is less than a predetermined stability threshold, an event reflecting that the stability is less than the predetermined stability threshold is reported to the network-side device, so that the network-side device can decide whether to trigger monitoring of the task model based on the event.

[0580] Option 22. The electronic device according to Option 20, wherein the at least one memory and the computer program code are configured to cause the electronic device to execute, via the at least one processor:

[0581] Receive from the network-side device a predetermined number of times the task model is executed in the inference.

[0582] Wherein, the predetermined number of times is greater than or equal to N.

[0583] Option 23. An electronic device according to any one of Options 14 to 22, wherein the task includes predicting a beam, and the task model includes a beam prediction model for predicting the beam.

[0584] Option 24. The electronic device according to Option 23, wherein,

[0585] The beam prediction model is used to perform multiple beam predictions, thereby monitoring the prediction accuracy of the beam prediction model multiple times, in order to improve the prediction accuracy of the beam prediction model for future candidate beams.

[0586] Option 25. The electronic device according to any one of Options 14 to 24, wherein,

[0587] The task model is a multi-task model used to simultaneously implement multiple tasks, and

[0588] The multi-task model includes a shared parameter model in which model parameters are shared by the multiple tasks, and model branches that correspond to at least a portion of the multiple tasks.

[0589] Option 26. The electronic device according to Option 25, wherein,

[0590] The shared parameter model extracts a shared representation shared by the multiple tasks from the input data, and

[0591] Each model branch is used to determine the mapping from the shared representation to the label of the task corresponding to that model branch.

[0592] Option 27. An electronic device for wireless communication, comprising:

[0593] At least one processor; and

[0594] At least one memory, including computer program code, wherein the at least one memory and the computer program code are configured to cause the electronic device to execute via the at least one processor:

[0595] Multiple tasks can be accomplished simultaneously using a multi-task model.

[0596] The multi-task model includes a shared parameter model in which model parameters are shared by the multiple tasks, and model branches that correspond to at least a portion of the multiple tasks.

[0597] Option 28. The electronic device according to Option 27, wherein,

[0598] The shared parameter model extracts a shared representation shared by the multiple tasks from the input data, and

[0599] Each model branch is used to determine the mapping from the shared representation to the label of the task corresponding to that model branch.

[0600] Option 29. The electronic device according to Option 27 or 28, wherein,

[0601] Tasks are grouped based on their correlation with each other, and the tasks within each group are implemented using a corresponding multi-task model.

[0602] The correlation is obtained based on at least one of the following: prior information on inter-task correlation, inter-task coordination information, and inter-task matching degree.

[0603] Option 30. An electronic device according to any one of Options 27 to 29, wherein the same input data is used for the multiple tasks implemented by the multi-task model.

[0604] Option 31. The electronic device according to Option 30, wherein the input data is determined based on at least one of the requirements of the task, the capabilities of the nodes related to the task, and the data collection overhead.

[0605] Option 32. The electronic device according to Option 31, wherein,

[0606] The requirements of the task include the time sampling period.

[0607] The capabilities of a node include at least one of the following: the availability of node data, the quality of node data, the matching degree of node data with different tasks, and the quality requirements of different tasks for node data.

[0608] The data collection overhead includes the overhead of collecting data of a predetermined quality.

[0609] Option 33. The electronic device according to Option 30, wherein the at least one memory and the computer program code are configured to cause the electronic device to execute, via the at least one processor:

[0610] Based on the results of unifying the input data, the model information of the multi-task model is confirmed, thereby simultaneously certifying the models for the multiple tasks.

[0611] Option 34. An electronic device according to any one of Options 27 to 29, wherein the at least one memory and the computer program code are configured to cause the electronic device to execute, via the at least one processor:

[0612] Based on the model ID included in the model activation or deactivation information, the multi-task model corresponding to the model ID is notified of the task ID to be activated or deactivated, and

[0613] Based on the task ID, activate or deactivate the corresponding model branch in the multi-task model that corresponds to the task ID.

[0614] Option 35. An electronic device according to any one of Options 27 to 29, wherein the at least one memory and the computer program code are configured to cause the electronic device to execute, via the at least one processor:

[0615] Based on the classification of performance degradation scenarios for the multiple tasks, the multi-task model is updated by at least one of updating the quality of the input data of the multi-task model, updating the quality of the auxiliary data of the multi-task model, and updating the model parameters of the multi-task model.

[0616] Solution 36. An electronic device according to any one of claims 27 to 29, wherein the at least one memory and the computer program code are configured to cause the electronic device to execute, via the at least one processor:

[0617] Collaborate with other electronic devices to accomplish at least a portion of the multiple tasks.

[0618] The input data of the multi-task model at the other electronic device may be the same as or different from the input data of the multi-task model at the electronic device.

[0619] Option 37. The electronic device according to any one of Options 27 to 36, wherein,

[0620] In the case where the electronic device is a network-side device:

[0621] For the multi-task model on the user equipment side, based on the channel conditions of the user equipment and / or capability information representing the capabilities of the user equipment, an indication is given of the monitoring format to be adopted by the user equipment for monitoring the multi-task model, and

[0622] In the case where the electronic device is a user device:

[0623] For the multitasking model on the electronic device side, an instruction is received from the network side device regarding the monitoring format to be used for monitoring the multitasking model, wherein the monitoring format is determined by the network side device based on the channel conditions in which the electronic device is located and / or capability information representing the capabilities of the electronic device.

[0624] Option 38. The electronic device according to Option 37, wherein,

[0625] The monitoring format is either a first monitoring format or a second monitoring format.

[0626] In the first monitoring format, multiple monitoring operations are performed by reusing at least a portion of historical measurement information for the multiple tasks.

[0627] In the second monitoring format, for multiple monitoring sessions, the measurement information used in each monitoring session does not overlap.

[0628] Option 39. A method for wireless communication, comprising:

[0629] For a task model used to implement a task on the user equipment side, based on the channel conditions where the user equipment is located and / or capability information representing the capabilities of the user equipment, an indication is given of the monitoring format to be adopted by the user equipment for monitoring the task model.

[0630] Option 40. A method for wireless communication, comprising:

[0631] For the task model used to implement the task on the electronic device side, an instruction is received from the network-side device regarding the monitoring format to be used for monitoring the task model.

[0632] The monitoring format is determined by the network-side device based on the channel conditions of the electronic device and / or capability information representing the capabilities of the electronic device.

[0633] Option 41. A method for wireless communication, comprising:

[0634] Multiple tasks can be accomplished simultaneously using a multi-task model.

[0635] The multi-task model includes a shared parameter model in which model parameters are shared by the multiple tasks, and model branches that correspond to at least a portion of the multiple tasks.

[0636] Scheme 42. A computer-readable storage medium having stored thereon computer-executable instructions that, when executed, perform the method according to any one of Schemes 39 to 41.

Claims

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 cause the electronic device to execute via the at least one processor: For a task model used to implement a task on the user equipment side, based on the channel conditions where the user equipment is located and / or capability information representing the capabilities of the user equipment, an indication is given of the monitoring format to be adopted by the user equipment for monitoring the task model.

2. The electronic device according to claim 1, wherein, The monitoring format is either a first monitoring format or a second monitoring format. In the first monitoring format, multiple monitoring operations are performed by reusing at least a portion of historical measurement information for the task. In the second monitoring format, for multiple monitoring sessions, the measurement information for the task used in each monitoring session does not overlap.

3. The electronic device according to claim 2, wherein, The at least one memory and the computer program code are configured to cause the electronic device to execute, via the at least one processor: When instructing the user equipment to use the first monitoring format, the instruction specifies the time-domain information of at least a portion of the multiplexed historical measurement information in the time domain. The time-domain information includes the starting point of at least a portion of the multiplexed historical measurement information in the time domain and the length of at least a portion of the multiplexed historical measurement information in the time domain.

4. The electronic device according to claim 2 or 3, wherein, The at least one memory and the computer program code are configured to cause the electronic device to execute, via the at least one processor: If the channel is determined to be a slow fading channel based on the channel conditions, the first monitoring format is indicated to the user equipment, and If the channel is determined to be a fast fading channel based on the channel conditions, the second monitoring format is indicated to the user equipment.

5. 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 cause the electronic device to execute via the at least one processor: For the task model used to implement the task on the electronic device side, an instruction is received from the network-side device regarding the monitoring format to be used for monitoring the task model. The monitoring format is determined by the network-side device based on the channel conditions of the electronic device and / or capability information representing the capabilities of the electronic device.

6. 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 cause the electronic device to execute via the at least one processor: Multiple tasks can be accomplished simultaneously using a multi-task model. The multi-task model includes a shared parameter model in which model parameters are shared by the multiple tasks, and model branches that correspond to at least a portion of the multiple tasks.

7. A method for wireless communication, comprising: For a task model used to implement a task on the user equipment side, based on the channel conditions where the user equipment is located and / or capability information representing the capabilities of the user equipment, an indication is given of the monitoring format to be adopted by the user equipment for monitoring the task model.

8. A method for wireless communication, comprising: For the task model used to implement the task on the electronic device side, an instruction is received from the network-side device regarding the monitoring format to be used for monitoring the task model. The monitoring format is determined by the network-side device based on the channel conditions of the electronic device and / or capability information representing the capabilities of the electronic device.

9. A method for wireless communication, comprising: Multiple tasks can be accomplished simultaneously using a multi-task model. The multi-task model includes a shared parameter model in which model parameters are shared by the multiple tasks, and model branches that correspond to at least a portion of the multiple tasks.

10. A computer-readable storage medium having stored thereon computer-executable instructions that, when executed, perform the method according to any one of claims 7 to 9.

Images