Improvements in and relating to management of user equipment memory for data collection

Abstract

Controlling data collection, logging and / or reporting by a User Equipment based on one or more UE resource status. The UE resource status may be related to memory or buffer status, processing power, battery life or power consumption. For example, reporting may be paused or resumed based on remaining battery life or buffer status of the UE and in relation to a related threshold. The data collection, logging or reporting may be related to AI / ML data used in network optimisation. The UE may be configured by the network taking into account properties of the UE, such as UE capabilities.

Description

The present invention relates to techniques associated with managing and handling User Equipment, UE, memory in connection with data collection tasks, especially tasks associated with Artificial Intelligence / Machine Learning, AI / ML, data. It is a topic of much debate exactly how to manage the potentially large amounts of AI / ML data generated and / or required in a telecommunication system, which seeks to make use of such data to optimise or improve the performance of the system. In 3GPP meeting RAN2#123bis meeting, RAN2 agreed the following proposals on data collection [RAN2#123bis]: “Proposal 4 Related to gNB-centric data collection for NW-side model training, the following principles can be considered for the L3 signalling reporting framework, if used: a. logging is supported c. periodic, event based reporting, on demand report d. The UE memory, processing power, energy consumption, signalling overhead should be taken into account. Note: The above principles, can be revised depending on RAN1 progress / requirements Proposal 9 Related to OAM-centric data collection for NW-side model training, the following principles can be considered for the immediate MDT framework, if used: a. The Immediate MDT framework for NW-side model training should allow the UE to store sets of measurements and then report them in multiple RRC messages (e.g. similar to the logged MDT). b. The Immediate MDT framework for NW-side model training should allow the UE to store multiple measurements taken at different points in time and report them in a single RRC report. c. The Immediate MDT framework for NW-side model training should allow the network to configure the UE to report measurements periodically or upon fulfilling certain events. d. The UE memory / processing power / energy consumption / signalling overhead should be taken into account. Note: The above principles, for the immediate MDT framework, can be revised depending on RAN1 progress / requirements Agreements on NW-side data collection For CSI and beam management 1 For training of NW-side models, both gNB- and OAM-centric data collection are considered in the study. 2 For training of NW-side models, the gNB-centric data collection implies that the gNB configures the UE to initiate / terminate the data collection procedure. To further study the details of the data collection configuration 3 For training of NW-side models, an OAM-centric data collection implies that the OAM provides the configuration (via the gNB) needed for the UE to initiate / terminate the data collection procedure. MDT framework can be considered. 4 Related to gNB-centric data collection for NW-side model training, RAN2 studies the potential impact on L3 signalling for the reporting of collected data, taking into account RAN1 further inputs / progress. 5 Related to OAM-centric data collection for NW-side model training, RAN2 studies the potential impact at on the MDT for connected mode, taking into account RAN1 further inputs / progress Positioning For LMF sided inference (case 2b, case 3b), RAN2 assumes LPP protocol should be applied to the data collected by UE and terminated at LMF, while the NRPPa protocol should be applied to the data collected by gNB and terminated at LMF. 8 For LMF sided performance monitoring, RAN2 assumes LPP protocol should be applied to the data collected by UE and terminated at LMF, while the NRPPa protocol should be applied to the data collected by gNB and terminated at LMF. General 6 Principles in proposal 4 and 9 will be captured as one combined set of principles for NW-side data collection: logging is supported periodic, event based reporting, on demand report The UE memory, processing power, energy consumption, signalling overhead should be taken into account. Note: The above principles, can be revised depending on RAN1 progress / requirements” Additionally, in RAN plenary #102 (RAN#102), 3GPP RAN working groups will be looking in to the following objective as part of Rel-19 work item on AI / ML for NR Air Interface: “4.1 Objective of SI or Core part Wl or Testing part Wl Provide specification support for the following aspects: AI / ML general framework for one-sided AI / ML models within the realm of what has been studied in the FS_NR_AIML_Air project [RAN2]: o Signalling and protocol aspects of Life Cycle Management (LCM) enabling functionality and model (if justified) selection, activation, deactivation, switching, fallback ■ Identification related signalling is part of the above objective o Necessary signalling / mechanism(s) for LCM to facilitate model training, inference, performance monitoring, data collection (except for the purpose of CN / OAM / OTT collection ofUE-sided model training data) for both UE-sided and NW-sided models o Signalling mechanism of applicable functionalities / models Beam management - DL Tx beam prediction for both UE-sided model and NW-sided model, encompassing [RAN1 / RAN2]: o Spatial-domain DL Tx beam prediction for Set A of beams based on measurement results of Set B of beams (“BM-CaseT) o Temporal DL Tx beam prediction for Set A of beams based on the historic measurement results of Set B of beams (“BM-Case2”) o Specify necessary signalling / mechanism(s) to facilitate LCM operations specific to the Beam Management use cases, if any o Enabling method(s) to ensure consistency between training and inference regarding NW-side additional conditions (if identified) for inference at UE NOTE: Strive for common framework design to support both BM-Case1 and BM-Case2 Positioning accuracy enhancements, encompassing [RAN1 / RAN2 / RAN3]: o Direct A i / ML positioning: ■ (1st priority) Case 1: UE-based positioning with UE-side model, direct AI / ML positioning ■ (2nd priority) Case 2b: UE-assisted / LMF-based positioning with LMF-side model, direct AI / ML positioning ■ (1st priority) Case 3b: NG-RAN node assisted positioning with LMF-side model, direct AI / ML positioning o AI / ML assisted positioning ■ (2nd priority) Case 2a: UE-assisted / LMF-based positioning with UE-side model, AI / ML assisted positioning ■ (1st priority) Case 3a: NG-RAN node assisted positioning with gNB-side model, AI / ML assisted positioning o Specify necessary measurements, signalling / mechanism(s) to facilitate LCM operations specific to the Positioning accuracy enhancements use cases, if any o Investigate and specify the necessary signalling of necessary measurement enhancements (if any) o Enabling method(s) to ensure consistency between training and inference regarding NW-side additional conditions (if identified) for inference at UE for relevant positioning sub use cases Core requirements for the above two use cases forAI / ML LCM procedures and UE features [RAN4J: o Specify necessary RAN4 core requirements for the above two use cases. o Specify necessary RAN4 core requirements for LCM procedures including performance monitoring. Study objectives with corresponding checkpoints in RAN#105 (Sept ’24): CSI feedback enhancement [RAN1J: o For CSI compression (two-sided model), further study ways to: ■ Improve trade-off between performance and complexity / o verhead • e.g., considering extending the spatia / / frequency compression to spatial / temporal / frequency compression, cell / site specific models, CSI compression plus prediction (compared to Rel-18 non-AI / ML based approach), etc. ■ Alleviate / resolve issues related to inter-vendor training collaboration. while addressing other aspects requiring further study / conclusion as captured in the conclusions section of the TR 38.843. o For CSI prediction (one-sided model), further study performance gain over Rel-18 non-AI / ML based approach and associated complexity, while addressing other aspects requiring further study / conclusion as captured in the conclusions section of the TR 38.843 (e.g., cell / site specific model could be considered to improve performance gain). Necessity and details of model Identification concept and procedure in the context of LCM [RAN2 / RAN1] - CN / OAM / OTT collection of UE-sided model training data [RAN2 / RAN1J: o For the FS_NR_AIML_Air study use cases, identify the corresponding contents of UE data collection o Analyse the UE data collection mechanisms identified during the FS_NR_AIML_Air (TR 38.843 section 7.2.1.3.2) study along with the implications and limitations of each of the methods Model transfer / delivery [RAN2 / RAN1]: o Determine whether there is a need to consider standardised solutions for transferring / delivering AI / ML model(s) considering at least the solutions identified during the FS_NR_AIML_Air study Testability and interoperability [RAN4J: o Finalize the testing framework and procedure for one-sided models and further analyse the various testing options for two-sided models, in collaboration with RAN1, and including at least: ■ Relation to legacy requirements ■ Performance monitoring and LCM aspects considering usecase specifics ■ Generalization aspects ■ Static / non-static scenarios / conditions and propagation conditions for testing (e.g., CDL, field data, etc.) ■ UE processing capability and limitations ■ Post-deployment validation due to model change / drift o RAN5 aspects related to testability and interoperability to be addressed on a request basis” The logging and reporting of UE measurements of AI / ML data will significantly increase the usage of UE memory, processing power and energy consumption. One issue associated with this is that the UE (or UEs) may fail to collect, store, and / or report the requested data if the UE(s) run(s) out of memory, processing power and / or energy. This problem has been identified by 3GPP RAN working group as set out above. However, there is currently no solution available for how the UE behaves when its resources become depleted with respect to AI / ML data collection, storing &reporting. It is an aim of embodiments of the present invention to regulate or control the behaviour of the network and / or the UE in order to handle the UE logging and reporting of AI / ML data in the event of UE limitations of memory, processing power, and / or energy. According to the present invention there is provided an apparatus and method as set forth in the appended claims. Other features of the invention will be apparent from the dependent claims, and the description which follows. According to a first aspect of the present invention, there is provided a method of operating a User Equipment, UE, communicatively coupled to a telecommunication network, comprising the step of the UE controlling one or more of data collection, logging or reporting, based on one or more UE resource status. In an embodiment, the data collection, logging or reporting is connected with AI / ML data used in UE or network optimisation. In an embodiment, the UE is configured by the telecommunication network taking into account at least one property of the UE. In an embodiment, the at least one property comprises UE capabilities, UE type, UE subscription information, or UE local resources. In an embodiment, the UE reports its resource status to the telecommunication network periodically or on demand. In an embodiment, the UE reports its resource status either separately or together with the collected data. In an embodiment, the UE indicates a failure to perform a configuration for data collection, data logging, and / or data reporting, due to local resources status. In an embodiment, the UE pauses or stops data collecting, logging or reporting in the event of a resource threshold being reached. In an embodiment, the UE resumes data collecting, logging or reporting in the event of resources becoming available again. In an embodiment, the resource threshold relates to one or more of memory or buffer status, processing power, battery life or power consumption. According to a second aspect of the present invention, there is provided apparatus arranged to perform the method of the first aspect. Aspects of the invention can be considered as follows. • The network determines and / or configures the behaviour of the desired UE (or multiple UEs) for data collection considering, for example, the UE(s) capabilities, UE(s) type, UE subscription information, and / or UE local resources. In one example, the UE memory, processing power, energy consumption level, etc. • All interactions (or actions) between the UE and the network (e.g. actions such as: requests, responses, feedback, recommendations, commands, indications, reporting, etc.) may occur using new and / or existing RRC signalling, procedure, messages, and / or lEs. • All interactions (or actions) between the UE and the network (e.g. actions such as: requests, responses, feedback, recommendations, commands, indications, reporting, etc.) may occur using new and / or existing NAS signalling, procedure, messages, and / or lEs. • All proposals in this invention can apply to any type of resource e.g. UE memory, processing power, local resources, and / or power consumption, battery charge, etc. • All (or part of) proposals are made using memory as an example, but all proposals (or part of) are not necessarily restricted to memory only and can be therefore applied to other resources in the UE such e.g. processing power, power consumption, battery charge, and / or any other UE local resources, etc. • All (or part of) proposals can be applied in any order and combination. As such there may be solutions that are based on network and UE proposals in an individual or combined manner • All (or part of) proposals are not limited to 5G system only. • All (or part of) proposals herein apply in any order and / or combination and can apply to 5GS or any other system, e.g. 4G, 6G, loT, NTN, loT NTN, dual connectivity, etc. • All proposal herein apply to any RAN entity (and / or function) maybe a RAN node (e.g. NG-RAN, gNB, eNB, etc.). • All proposal herein apply to the any core network entity (and / or function) e.g. AMF, SMF, MME, UPF, UDM, NWDAF, etc. • In all proposals the use of “data collection, logging, and / or reporting” can refer to all traffic types or AI / ML traffic type or a combination of such traffic types. • In all proposals the term “data collection task”, may refer to data collection, data logging, and / or data reporting steps / tasks / procedures. Although a few preferred embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes and modifications might be made without departing from the scope of the invention, as defined in the appended claims. For a better understanding of the invention, and to show how embodiments of the same may be carried into effect, reference will now be made, by way of example only, to the accompanying diagrammatic drawings in which: Figure 1 shows an example of the UE sending a resource report to the network in relation to a data collection procedure; Figure 2 an example call flow according to an embodiment of the invention; and Figure 3 shows a flowchart illustrating an embodiment of the invention. In the following embodiments are described which are provided for handling data collection, logging and reporting of collected AI / ML data according to the UE memory status / requirements. Herein, the mention of UE memory status, UE memory, UE storage, may refer to (or mean), for example, memory storage status, current storage, remaining storage, storage level, storage level, storage upper and / or lower threshold or bound, maximum storage, minimum storage, storage below a given level, storage above a given level, storage between two levels, absolute storage level, used storage, corrupted storage, functioning storage, deleted (or released or erased) storage and / or time (and / or location) of deleting this memory, and / or other storage description etc. The storage may refer to overall storage in the UE which is used by more than one local entity, or it may refer to storage that is dedicated for AI / ML data collection and / or processing. Moreover, resource status, may refer to (or mean), for example, remaining resource, consumed resource, reserved resource, allocated (or assigned) resource, required resource, resource level (or threshold or upper or lower bound), maximum (and / or minimum) resource, damaged or unavailable resource, etc. Similar to the memory status referred to above, the mention of UE resource status, may refer (or mean), for example, resources such as (but not limited to): memory, power (or battery charge, or power consumption), processing power, and / or other UE resources. The following relates to UE capability exchange with the network. It is known in the prior art that the UE and the associated network may exchange certain details of capabilities. The following are new capabilities that the UE and the network can exchange with each other, according to one or more embodiments of the present invention: • The UE indicates (or reports) its capability (optionally) to the network about its support for reporting of UE memory and / or other local resources; • The UE indicates (or reports) its capability (optionally) to the network about its support for resource management (e.g. resource allocation, re-allocation, release, modify allocation, etc.), during (or for) the data collection, data logging (or storing) and / or data reporting tasks (or procedures). In one example, the UE manages the memory (e.g. store, delete, etc.) for logging data; • The UE sends (or reports) any of the proposed capability (optionally) to the network periodically, upon request from the network (e.g. AMF, or RAN, etc.), and / or provides it to the network as part of (or during) the UE connection (re-)establishment with the network; • The network indicates (or reports) it capability, (optionally) to the UE, to support configuration and handling of data collection, data logging, and / or data reporting tasks (or procedures), according to UE’s local resources (e.g. UE memory). For example, capability to request reports of UE resources, capability to configure a data collection task (e.g. data size, latency, etc.) according to the UE’s local resource (e.g. UE memory and / or battery, etc.); • The UE and the network capabilities can be exchanged (or reported) using existing UE and network capabilities exchange signaling (e.g. RRC and / or NAS signaling / messages / IEs), any other suitable signaling, and / or any newly defined signaling (e.g. RRC and / or NAS signali ng / messages / l Es); o In another example, the UE reports its capabilities using (or as part of) U E Assista ncelnformation; • In one example, on the UE capability exchange with the network, the UE capability can be exchanged with the network using (or as part of) UE capability transfer procedure. The following relates to Network configuration for UE logging and / or reporting based on UE resource. The following applies for data collection, logging and / or reporting, in any combination or order, unless explicitly stated otherwise. Note that any reference to “memory” is not to be considered as restrictive to memory only and may apply to any UE resource such as power, etc. 1) The network controls (or decides or determines) the UE behavior for data collection, logging, reporting via direct signaling (e.g. SIBs, NAS, RRC, MAC CE, etc.) and / or configurations. Optionally, the network may decide the configuration according to the UE reported capability (e.g. capability related to data collection, logging, and / or reporting, or another existing or newly defined UE capability), UE category, UE location, time, and / or subscription, etc. In one example, a selected set (one or more) of UEs can be capable to support data logging according to network configuration (and / or control). In another example, the configuration may be related to memory usage for data collection reporting amongst other resources in the UE (e.g. power consumption). 2) The network provides configurations to the UE and it is up to the UE how to handle the different steps (or processes) of data collection, logging, and / or reporting according to its local resources (e.g. UE memory status). For example, the network indicates that the UE can decide what to do when the UE determines that the memory is full (or at a given percentage or proportion of usage / allocation of resources). In another example, the UE assesses the remaining or free memory that is still available, or the memory which has been used, where this memory may be overall UE memory or dedicated memory for AI / ML data collection and / or processing. Based on this, the UE may determine what to do in terms of data collection and / processing for AI / ML e.g. to stop data collection, report the logged data (e.g. full or in part), delete all data (or part of the data), report memory status, etc. 3) The network may configure the UE data collection task, e.g. data collection size, use case, latency, data logging amount, time, etc., according to the UE reported UE memory status. For example, if the network had previously configured the UE to report data of size, say, X Bytes, then the network may now configure the UE to report data of size P Bytes where P is less than X. This may happen when for example the UE reports that it has less memory that is available. Alternatively, if the UE reports an increase in its available memory, the network may reconfigure the UE to report data size Y Bytes where Y is larger than X (which may be the previous size configured by the network). 4) The network provides, as part of the (re)-configurations for the UE, information (or parameters) related to the collected data, such as: data size, data latency, data QoS characteristics (or QoS profile), data reporting timing and periodicity, reporting triggers (in case of not periodic reporting), e.g. reporting data in X Megabytes, Y msec, etc., where X and Y are positive real numbers defined by the network, in another example, defined by the UE and / or the Network). 5) The network configures the UE to indicate (or report) one (or more or combination) of the following in relation to AI / ML data collection: a. The UE’s current memory status and / or expected memory status after a given time instance. Optionally, additionally, using same or separate messaging (and / or lEs) to indicate (or report) other UE’s resource(s) status (e.g. power status). b. In another example, the UE report the memory status when reaching a certain storage level or threshold, e.g. at or after 50% has been used, or after the memory is full or close to becoming full. Or the network configures the UE to report when the UE’s memory changes by a certain level or threshold, or crosses a certain level or threshold. c. The status of the logged data, e.g. data logged in full, logged partially, or logging is complete, or incomplete, data is released (or erased, deleted) or will be updated or released at a given time period, etc. For example, data logged in full may refer to data that is logged based on a known size. As such, logged data which is not full. 6) The network configures the UE to wait (or postpone or delay) reporting for complete log or log a certain amount (or data size) and then start reporting. In another example, for the UE to only trigger the reporting when a complete data logging (or a certain amount of data logging) is reached before starting to report the logged data to the network. 7) The network indicates (or configures or informs) the UE that when data logging (or logged data size) exceeds certain threshold (or preconfigured or assigned parameters), report this event, if possible (e.g. the UE is in RRC connected mode). 8) The network configures the UE to record the number of times (frequency, or how frequent) the UE failed to log the data completely (or partially) or not log according to a set of network configurations of the data collection and logging, for example, data logging according up to a specific time or specific measurements and / or specific time logging window. 9) The network decides (or controls) and / or configures the UE behavior under (or during) resource shortage (e.g. memory shortage) to complete the data collection in the UE. For example, the network configures one or more of the following UE behaviors: a) The UE to trigger the report of resource shortage (e.g. ‘no memory’ upon detection of insufficient memory or unavailable memory resource) required (or needed) to complete the data collection, logging and reporting, according to the originally configured data collection task (e.g. data size, latency, periodicity of data reporting, etc.). b) The UE to send the collected data (or stored or logged data) and indicate to the network the case of reporting of incomplete data (or incomplete data collection task) due to resource shortage (or unavailability or not enough of resources) to complete the data collection task as requested by the network or in another example as required by the data collection task. c) The time duration for the event (or situation or condition) of lack of (or shortage or unavailability of) resource before the UE should flag (or indicate or report) this issue to the network. For example, the UE should wait T seconds during which lack of resources is still ongoing and after T seconds then the UE should report the lack of memory. In other words, the network may configure the UE to report a lack of a certain resource but only after a duration of time elapses while the resource is deemed to be still lacking. d) The UE to wait until resources become available again. In another example, postpone data collection, logging and / or reporting until resources are available (or available again). In another example, resources are available to complete the data collection, logging, and / or reporting task (or procedure). The UE may save all logged data and potentially augment (or combine or amend, etc.) them with more data when the logging is resumed later. e) The UE to tag the time from the start to end of the case of resource shortage (or unavailability) - hence tag pause or resume time of data log. The UE may report this information. f) The UE to stop (or pause) data collection (logging and / or reporting) based on a request from the network. In one example, the network may request (or command) the UE to stop (or pause) data collection (logging and / or reporting) considering the UE reports on resource status (e.g. UE memory). In one example, the UE reported that the UE memory is at X% (or above a given threshold and / or upper bound, etc.) of memory storage usage, then the network informs the UE to stop (or pause) data collection (logging and / or reporting) until the time instance when the memory status is less than X% (or another level below initially reported level) before the UE can re-start or resume data collection task. In one example, the network can inform or command the UE using new and / or existing RRC signaling / messages / IEs (e.g. RRC Reconfiguration). Additionally, in the case that the UE re-starts data collection (logging and / or reporting), the UE may or may not delete (or release memory resources) previously logged. In another example, the UE may combine the logged data with the newly collected data after the UE resumes the data collection task. In an alternative example, the network may configure the UE to stop data collection and delete logged data or pause data collection and delete or combine logged data with data to be collected after the UE resume data collection task. g) The UE to start or resume data collection tasks after a given period of time (e.g. expiry of preconfigured T-resume; value is integer of ms) of the UE memory becoming available for data collection (e.g. start new data collection or resume an ongoing data collection task). h) The UE to stop data collection (logging and / or reporting) after a given time period (e.g. expiry of preconfigured T-stop; value is integer of ms) from the start of the event (or case) of resource shortage (e.g. no memory or memory status) at the UE. In another example, to stop data collection after a given period of time from the UE reporting the event (or case) of resource shortage (e.g. no memory or memory status) to the network. Additionally, the UE may delete the logged data upon the expiry of the given timer (e.g. T-stop, or any other suitable naming). i) Configures how the UE should manage resources (e.g. memory storage or usage, etc.) in the case of resource shortage, taking into considerations of: (i) the purpose of the collected data and / or (ii) the use case of the collected data. ■ The data collection for life-cycle-management (LCM) purpose of a model (or functionality), such as data collection for the LCM purpose of monitoring, inference or training, etc., of a model (or functionality). In one example, in the case of memory shortage, the UE may continue to log data collected for the LCM purpose of model (or functionality) monitoring, while the UE would release memory resource storing data collected for other LCM purposes (e.g. training, etc.). ■ In another example, the UE may release any logged data collected for a given use case and maintain and / or continue logging data collected for a different use case, if logging is possible (or as long as logging data is still possible, assuming that more memory resources are available due to releasing resources previously used for other data), e.g. release data collected for load balancing, CSI prediction, CSI compression, beam management, positioning and / or energy saving, etc., and keep logging data collected for mobility optimization, etc. • The network may request a success and / or failure report(s) on completion of the data collection (and / or logging) requested from the UE. In one example, based on those reports the network may reconfigure the data collection (and / or logging) tasks for the UE based on those reports. In one example, the network may adjust / modify (e.g. reduce or increase) the requested data collection size (e.g. measurements parameters collection periods or number of collected parameters, etc.) or adjust other parameters (or information) related to the collected data (e.g. latency, LCM purpose, etc.) for the desired UE. • In one example, the Network may reconfigure requirements for data size logging based on this indication, or increase periodicity of data reporting. • The network may perform access barring to one (or more or all UEs) from collecting and / or reporting data, and delete or flush or pause all data collection in the network. In one example, access barring introduced as part of exiting or newly defined SIB. Note that for all the details herein, any unit of time or memory or any other resources is to be considered as an example only. The following relates to UE behavior for data collection, logging and / or reporting based on resource status. Note that details set out above in relation to the network behaviour can be implement in whole or in part as a UE based solution without the need for network configuration. • The UE monitors resources for AIML data and / or reporting o The UE may have local policies, or (pre-)configurations that a certain portion (or all) of its resources may be used for AIML related procedures (e.g. LCM purposes) or data collection, logging and / or reporting for AI / ML. o The UE monitors the resource allocation for upcoming (or requested or instructed by the network) data collection tasks. For example, the UE monitors if current available resources are enough to assign for AIML data collection, logging, and / or reporting, based on information received related to this data. In one example, data size, latency, priority, LCM purpose, QoS profile / characteristics, other information related to the collected data. ■ (For cases where resources are not enough for logging process - i.e. logging process not started) the UE indicates that it does not have enough resource to complete the requested data logging (or data collection, logging, and / or reporting) task. The UE may also report how much data size has been logged and / or how much memory is missing to complete the task ■ This is the case of UE just reporting the problem of not enough (or lack of) resources to perform the data collection, logging and / or reporting task. • Basically UE reports lack of resources or • Potential memory failure case o The UE monitors if resource usage for AI / ML has gone up or down e.g. based on a predefined threshold ■ In one example, the threshold may be: • preconfigured in the UE or received from the network via any form of existing and / or newly defined signalling (e.g. RRC and / or NAS signaling / messages / IEs or locally) and / or via system broadcast (e.g. periodically and / or on-demand), e.g. using existing and / or newly defined SIBs • selected by the UE, e.g. based on UE resource status or other local policies, or preconfigured by and external entity (or application function, etc.) or via OAM. • jointly decided (or selected) by the UE and the network. ■ When the condition or threshold (on data logging) is met, the UE can behave in one or more (or combination of the following manners: • (For cases where resources or logging process is started) o the UE indicates it has already collected data and not possible to collect / log more. This is an example of how the UE just reports the problem o The UE pauses data collection, and may report pause. Additionally, the UE re-monitors and may report restart when the condition of resource shortage is ended (i.e. resources available again). The UE may resume data collection and / or logging when its resources are available again o the UE sends what it has logged already, unless the network configure the UE to log fully (UE may decides to send what it has in the case that UE detects the case of memory shortage). o the UE monitors and / or decides that the resources have not been available for a time period T, where T may be preconfigured or provided by the network. o The UE may periodically report its memory usage e.g. based on configurations by the network to do so ■ The network may use this report to determine if the UE in question should continue to collect and / or report data. For example, a UE which reports critically low memory may be informed by the network to stop reporting until the memory usage is gone down, or until a certain memory is available (using any units to provide such indications). Note that these proposals can also apply to other UE resources such as power. As such, the UE may report low power and the network may indicate to the UE that reporting should be stopped and optionally resumed when the power goes above, for example, 50%, etc. o In one example, the UE reporting of memory status happens (or triggered) at the expiry of a timer configured by the network. In another example the UE reporting of the logged data is triggered when the UE memory status (or storage) reaches a preconfigured threshold (or upper bound), or a lower bound of memory storage, etc. Optionally, the UE may indicate the reason why the UE stopped the data collection (and / or logging) before the full data collection due to UE memory storage reason (e.g. NotEnoughMemory, or any other suitable naming or cause value). o The UE reports, in addition to (or separate from) the logged data, the memory status, for example, using the same or separate signals (or messages (or lEs). o The UE may indicate its current UE memory status, including how much memory or storage is available for another data collection to the network, so that the network may consider this information when configuration the next data collection (and / or logging) tasks at the UE. The indication may be in any form such as: absolute memory that is remaining, absolute memory that has been used, a percentage of remaining memory, a percentage of used memory, where optionally any of this may be for AIML data collection and / or processing or for overall usage of resource in the UE (optionally not necessarily just for AIML data collection and / or processing). o The UE may decide autonomously or based on assistance information from the network (e.g. configurations or other information or commands) to stop collection (and / or logging) of data if it determines that the UE memory status will not be enough to perform the full (or part of) the requested data collection task. Additionally, the UE informs the network of its failure to collected (and / or log or perform this task) due to it is current (and / or predicted) memory status. In one example, the UE may keep, or delete any collected (and / or logged data) at this stage, or send the collected data to the network and then delete this data. o The UE may indicate that it does not have enough power to process the configured (or requested) data collection (and / or logging) task, and may recommend a different data collection (and / or logging) task according to the UE’s memory status (e.g. remaining UE storage or other local resources status). • The UE autonomously handles the different steps of data collection, logging, and / or reporting according to its local resources (e.g. UE memory status) or policies that describe the UE behaviour under resource constraints or shortages: o The UE may indicate, in addition to the reported (or sent) data (or part of data), the UE memory status at the time of data reporting, where this time may be tagged by the UE as part of the memory reporting. Optionally the network may tag a time for each reported UE memory status in order to see any pattern in UE memory usage. o In one example, the UE indicates that it only collected (and / or logged) part of the data requested for collection (and / or logging) by the network. Optionally, the UE may include with this indication the reason of this action as related to the memory status, e.g. not enough memory to store all requested data. For example, the UE may be configured to report data of a certain size, say X megabytes (or any other unit). However, the UE’s collected data has a size of less than X megabyte where this is a result of lack of UE memory. The UE may report the collected data and indicate a reason for the lack of the complete data size where the reason may be to lack of resources such as memory, power, etc. • For cases when the UE wants to admit a new data collection and / or data log processes (or tasks), e.g. based on network indication, the UE may: ■ Reject the network’s request and indicate reason (e.g. lack of memory resources to complete the requested task, e.g. reuse existing cause value or a newly defined, NoMemoryResource, MemoryResourceShortage, or any other suitable naming). ■ Report log is delayed or postponed. Optionally, indicate the time when the log will be available. ■ Report that log is full, or report the percentage of resource which is full (or available) for another more important or higher priority tasks, e.g. related to other exchanged traffic with the network (MO, MT, or other traffic). • A UE capable of providing memory status (and / or any other local resources) information in RRC_CONNECTED state may initiate the UE Assistance information procedure, to provide the indication of memory status to the network, if it was configured to do so, upon detecting memory status problem if the UE is not able to collect or log more data, since it was configured to provide memory status indications, or upon change of memory status or memory status problem information. All (or part of) above details are applicable to the case of power resource shortage (e.g. battery charge shortage, etc.). In one example, the UE may indicate that it does not have enough power to process the configured (or requested) data collection (and / or logging) task. Figure 1 illustrates an example of the UE sending a resource report to the network in relation to data collection procedure. This is illustrative of a change which may be made to 3GPP TS 38.331. The purpose of this procedure is to transfer from the UE to the Network (e.g. NG-RAN) information on the status of UE’s resources in relation to data collection procedure at the UE. The specific information transferred in this message may include one (or more) of the following: - The data collection process: • Includes information on the status of the collected data (e.g. complete, incomplete, partial, etc.), • e.g. DataCollectionReport (or any other suitable naming) - The data logging process; • Including status of data logging process (e.g. partial, complete, success, failure, postponed, stopped, resumed, started, or stopped, etc.) - The UE’s memory: • Including status of UE memory (e.g. full, available, not storage, storage, % of storage available or used, etc. • UEMemoryStaus IE; Note that the UEResourceReport message or ResourceReport message (or any other suitable naming) message may also include the collected data (or UE measurements). In one example, AI / ML data (or AI / ML measurements or measurement results). In an alternative example, the UE may report the collected data (or UE measurement results) in a separate procedure. In one example, the report is sent based on the network request or triggered by a change in the UE’s resource status. Note that the above example, also applies to providing information on the reporting the UE’s resource status in general, e.g. processing power, power or battery charge, other. Figure 2 shows an example call flow, illustrating at least one embodiment described herein. It should be noted that the call flow of Figure 2 is based on the proposals above and hence should be considered as an example of how the proposed solutions can be used. As such other actions for the UE or the network may also be used in any order or combination in addition to the call flow shown above. The UE behavior may be based on network configuration or may be based on local decision in the UE (e.g. autonomous UE behavior) and therefore the actions taken by the UE may not necessarily be based on a previous message from the network or based on specific indications from the network. All other proposals herein may also be used and the steps shown above may be used in different order and combination. Figure 3 illustrates an embodiment of the invention where at step S101, the UE is communicatively coupled to a telecommunication network and at step S102 the UE controls one or more of data collection, logging or reporting, based on one or more UE resource status. At least some of the example embodiments described herein may be constructed, partially or wholly, using dedicated special-purpose hardware. Terms such as ‘component’, ‘module’ or ‘unit’ used herein may include, but are not limited to, a hardware device, such as circuitry in the form of discrete or integrated components, a Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC), which performs certain tasks or provides the associated functionality. In some embodiments, the described elements may be configured to reside on a tangible, persistent, addressable storage medium and may be configured to execute on one or more processors. These functional elements may in some embodiments include, by way of example, components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. Although the example embodiments have been described with reference to the components, modules and units discussed herein, such functional elements may be combined into fewer elements or separated into additional elements. Various combinations of optional features have been described herein, and it will be appreciated that described features may be combined in any suitable combination. In particular, the features of any one example embodiment may be combined with features of any other embodiment, as appropriate, except where such combinations are mutually exclusive. Throughout this specification, the term “comprising” or “comprises” means including the component(s) specified but not to the exclusion of the presence of others. Attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and / or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features. The invention is not restricted to the details of the foregoing embodiment(s). The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.

Claims

1. A method of operating a User Equipment, UE, communicatively coupled to a telecommunication network, comprising the step of the UE controlling one or more of data collection, logging or reporting, based on one or more UE resource status.

2. The method of claim 1 wherein the data collection, logging or reporting is connected with AI / ML data used in UE or network optimisation.

3. The method of claim 1 or claim 2 wherein the UE is configured by the telecommunication network taking into account at least one property of the UE.

4. The method of claim 3 wherein the at least one property comprises UE capabilities, UE type, UE subscription information, or UE local resources.

5. The method of any preceding claim wherein the UE reports its resource status to the telecommunication network periodically or on demand.

6. The method of claim 5 wherein the UE reports its resource status either separately or together with the collected data.

7. The method of any preceding claim comprising wherein the UE indicates a failure to perform a configuration for data collection, data logging, and / or data reporting, due to local resources status.

8. The method of any preceding claim wherein the UE pauses or stops data collecting, logging or reporting in the event of a resource threshold being reached.

9. The method of claim 8 wherein the UE resumes data collecting, logging or reporting in the event of resources becoming available again.

10. The method of claim 8 or 9 wherein the resource threshold relates to one or more of memory or buffer status, processing power, battery life or power consumption.

11. Apparatus arranged to perform the method of any preceding claim.

Images