Devices and methods for ML model formal verification in a mobile network

Abstract

A control plane network entity (110) is disclosed for formal verification of a machine learning, ML, model implementing a task in a mobile network (100). The control plane network entity (110) is configured to obtain an ML model property set defining one or more input constraints and / or one or more output constraints for the ML model and to obtain one or more ML model structure features. Moreover, the control plane network entity (110) is configured to determine an indicator indicative of a trustworthiness of the ML model based on the ML model property set and the one or more ML model structure features. The control plane network entity (110) allows for an accurate formal verification of an ML model implementing a task in the mobile network (100).

Description

[0001] Devices and methods for ML model formal verification in a mobile network

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to wireless communications. More specifically, the present disclosure relates to devices and methods for machine learning, ML, model formal verification in a mobile network, in particular a 3GPP mobile network.

[0004] BACKGROUND

[0005] Artificial intelligence (Al) and machine learning (ML) techniques are being used in various industrial sectors, ranging from Robotics, healthcare, finance, agriculture, to education, gaming, chatbots and the like. Recently, AI / ML techniques were embraced by the telecommunication sector as well. For a telecom network, on the one hand, AI / ML can help to improve network operation, anomality detection and so on. On the other hand, a telecom network also aims to provide AI / ML capability for 3rd-party services.

[0006] Though undoubtfully AI / ML technology shows its significant productivity, creativity and efficiency in many application scenarios, due to its black box nature of a trained deep neural network (DNN), in which a complicated network structure with a multitude of parameters on its directed edges, its explainability and resilience issues concern its wide application in mission- critical scenarios. In fact, many existing studies already reveal the vulnerability of DNN. For example, with slight manipulations on the input images, a DNN for image recognition may infer a totally unreasonable outcome, which very unlikely to a normal human being. The unexpected behaviors are not acceptable for business use cases. Due to this concern, even if the performance with an Al copilot is normally good, for making a final decision, a manual final check by a human is still required. Similar requirements concerning the trustworthiness of ML models have been identified for ML models implemented in mobile networks, in particular 3GPP network, for implementing, for instance, analytics tasks.

[0007] SUMMARY

[0008] It is an objective of the present disclosure to provide improved devices and methods for machine learning, ML, model formal verification, i.e. for determining the trustworthiness of a ML model in a mobile network, in particular a 3GPP mobile network.

[0009] The foregoing and other objectives are achieved by the subject matter of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures. According to a first aspect a control plane network entity is provided for formal verification of a machine learning, ML, model implementing a task, in particular an analytics task, in a mobile network, in particular a 3GPP mobile network, such as a 5G or 6G network. As used herein, formal verification refers to a process that takes a ML model and a property as input and determines if the ML model satisfies the property.

[0010] The control plane network entity according to the first aspect is configured to obtain an ML model property set defining one or more input constraints, such as input value ranges, and / or one or more output constraints, such as output value ranges, for the ML model. Moreover, the control plane network entity according to the first aspect is configured to obtain information about one or more ML model structure features indicative of the architecture of the ML model. The control plane network entity according to the first aspect is further configured to determine an indicator indicative of a trustworthiness of the ML model based on the ML model property set and the information about the one or more ML model structure features. Thus, the control plane network entity according to the first aspect allows for an accurate formal verification of an ML model implementing a task in a mobile network.

[0011] In a further possible implementation form, the one or more input constraints and / or one or more output constraints defined by the ML model property set comprise one or more ranges for input values of the ML model and / or one or more ranges for output values of the ML model. Thus, the control plane network entity according to the first aspect allows for an accurate formal verification of an ML model implementing a task in a mobile network based on an easily definable ML model property set.

[0012] In a further possible implementation form, the control plane network entity according to the first aspect is configured to obtain the ML model property set from a consumer network entity. This allows a consumer network entity to provide the ML model property set for the formal verification of an ML model implementing a task in a mobile network.

[0013] In a further possible implementation form, the control plane network entity according to the first aspect is configured to receive the ML model property set from the consumer network entity as part of a request for formal verification of the ML model implementing the task. This allows a consumer network entity to request the formal verification of an ML model implementing a task in a mobile network.

[0014] In a further possible implementation form, the request for formal verification of the ML model implementing the task comprises a task identifier and / or a ML model identifier. This allows the control plane network entity according to the first aspect to efficiently identify the ML model and / or the task implemented by the ML model.

[0015] In a further possible implementation form, the control plane network entity according to the first aspect is configured to provide the indicator indicative of the trustworthiness of the ML model to the consumer network entity. This allows the consumer network entity to obtain a quantitative indicator of the trustworthiness of the ML model and to take an informed decision based on the indicator.

[0016] In a further possible implementation form, the information about the one or more ML model structure features indicative of the ML model architecture comprise information about: one or more activation functions of one or more layers of the ML model, one or more weight matrices of one or more layers of the ML model, one or more kernel matrices of one or more layers of the ML model, and / or one or more regularizer vectors of one or more layers of the ML model. Thus, the control plane network entity according to the first aspect allows for an accurate formal verification of an ML model implementing a task in a mobile network based on an easily definable ML model structure features indicative of the ML model architecture.

[0017] In a further possible implementation form, the control plane network entity according to the first aspect is configured to obtain the information about the one or more ML model structure features from a further control plane network entity, in response to sending a request to the further control plane network entity, wherein the request comprises a task identifier and / or a ML model identifier. The further control plane entity may be the entity deploying the task implemented by the ML model in the mobile network. This allows the control plane network entity according to the first aspect to efficiently obtain the information about the one or more ML model structure features indicative of the ML model architecture.

[0018] In a further possible implementation form, the task implemented by the ML model is an analytics task and the further control plane network entity is a network data analytics function, NWDAF, of the mobile network. Thus, the control plane network entity according to the first aspect allows for an accurate formal verification of an ML model implementing an analytics task implemented by a NWDAF in a mobile network.

[0019] In a further possible implementation form, the indicator indicative of the trustworthiness of the ML model indicates that the ML model satisfies the ML model property set, the ML model does not satisfy the ML model property set and / or the ML model satisfies a relaxed ML model property set. Thus, the control plane network entity according to the first aspect allows providing a quantitative indicator of the trustworthiness of the ML model that allows taking an informed decision based on the indicator.

[0020] In a further possible implementation form, for determining the indicator indicative of the trustworthiness of the ML model based on the ML model property set and the one or more ML model structure features indicative of the ML model architecture the control plane network entity according to the first aspect is configured to formulate a non-convex ML model verification problem based on the model property set and the one or more ML model structure features, to relax the non-convex ML model verification problem to a quasi-convex ML model verification problem and to determine the indicator indicative of the trustworthiness of the ML model as a solution of the quasi-convex ML model verification problem. This allows the control plane network entity according to the first aspect to determine the indicator indicative of the trustworthiness of the ML model in a computationally efficient way.

[0021] In a further possible implementation form, the control plane network entity according to the first aspect is configured to relax the non-convex ML model verification problem to the quasi- convex ML model verification problem by relaxing one or more activation functions of one or more layers of the ML model to one or more piece-wise smooth functions. This allows the control plane network entity according to the first aspect to determine the indicator indicative of the trustworthiness of the ML model in a computationally feasible way.

[0022] According to a second aspect a method is provided for operating a control plane network entity for formal verification of a machine learning, ML, model implementing a task, in particular an analytics task, in a mobile network, in particular a 3GPP mobile network, such as a 5G or 6G network. The method according to the second aspect comprises: obtaining an ML model property set defining one or more input constraints and / or one or more output constraints for the ML model; obtaining information about one or more ML model structure features indicative of the ML model architecture; and determining an indicator indicative of a trustworthiness of the ML model based on the ML model property set and the information about the one or more ML model structure features.

[0023] By means of the method according to the second aspect an accurate formal verification of an ML model implementing a task in a mobile network is provided. The method according to the second aspect can be performed by the control plane network entity according to the first aspect. Thus, further features of the method according to the second aspect result directly from the functionality of the control plane network entity according to the first aspect as well as its different implementation forms described above and below.

[0024] According to a third aspect, a computer program product is provided, comprising a computer- readable storage medium for storing program code which causes a computer or a processor to perform the method according to the second aspect, when the program code is executed by the computer or the processor.

[0025] Details of one or more embodiments are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description, drawings, and claims.

[0026] BRIEF DESCRIPTION OF THE DRAWINGS

[0027] In the following, embodiments of the present disclosure are described in more detail with reference to the attached figures and drawings, in which:

[0028] Fig. 1 shows a schematic diagram illustrating a mobile network including a control plane network entity according to an example for formal verification of a ML model implemented in the mobile network;

[0029] Fig. 2 shows a table illustrating parameters used by a control plane network entity according to an example for formal verification of a ML model implemented in the mobile network;

[0030] Fig. 3 shows a signalling diagram illustrating the interaction between a control plane network entity according to an example and other entities of the mobile network for formal verification of a ML model to be implemented in the mobile network;

[0031] Fig. 4 shows a signalling diagram illustrating the interaction between a control plane network entity according to an example and other entities of the mobile network for formal verification of a ML model implemented in the mobile network; and

[0032] Fig. 5 shows a flow diagram illustrating a method of operating a control plane network entity according to an example in a mobile network.

[0033] In the following, identical reference signs refer to identical or at least functionally equivalent features.

[0034] DETAILED DESCRIPTION OF THE EMBODIMENTS

[0035] In the following description, reference is made to the accompanying figures, which form part of the disclosure, and which show, by way of illustration, specific aspects of embodiments of the present disclosure or specific aspects in which embodiments of the present disclosure may be used. It is understood that embodiments of the present disclosure may be used in other aspects and comprise structural or logical changes not depicted in the figures. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims.

[0036] For instance, it is to be understood that a disclosure in connection with a described method may also hold true for a corresponding device or system configured to perform the method and vice versa. For example, if one or a plurality of specific method steps are described, a corresponding device may include one or a plurality of units, e.g. functional units, to perform the described one or plurality of method steps (e.g. one unit performing the one or plurality of steps, or a plurality of units each performing one or more of the plurality of steps), even if such one or more units are not explicitly described or illustrated in the figures. On the other hand, for example, if a specific apparatus is described based on one or a plurality of units, e.g. functional units, a corresponding method may include one step to perform the functionality of the one or plurality of units (e.g. one step performing the functionality of the one or plurality of units, or a plurality of steps each performing the functionality of one or more of the plurality of units), even if such one or plurality of steps are not explicitly described or illustrated in the figures. Further, it is understood that the features of the various exemplary embodiments and / or aspects described herein may be combined with each other, unless specifically noted otherwise.

[0037] Figure 1 shows a schematic diagram illustrating a portion of the control plane, CP, of a mobile network 100 configured to provide mobile communication services. In an embodiment, the mobile network 100 may be a current or future 3rd Generation Partnership Project (3GPP) mobile network 100, for instance, a 5G or a 6G network. As illustrated in figure 1 and will be described in more details in the following, a control plane network entity 110 according to an embodiment in the form of a machine learning, ML, model formal verification function, ML- MFVF 110 is provided for formal verification of a ML model implementing a task in the mobile network 100. In the embodiment shown in figure 1 the task implemented by the ML model is an analytics task deployed or to be deployed by a network data analytics function, NWDAF, 130 of the mobile network 100. As used herein and described in more details in the following, formal verification refers to a process that takes a ML model and a property as input and determines if the ML model satisfies the property.

[0038] As will be described in more details in the following, the control plane network entity 110, e.g. ML-MFVF 110 is configured to obtain an ML model property set defining one or more input constraints, such as input value ranges, and / or one or more output constraints, such as output value ranges, for the ML model, and to obtain information about one or more ML model structure features indicative of the architecture of the ML model. Based on the model property set, MPS, and the information about the one or more ML model structure features, the control plane network entity 110, e.g. ML-MFVF 110 is configured to determine an indicator (referred to as TRUSTJDCT in figure 1) indicative of a trustworthiness of the ML model.

[0039] As illustrated in figure 1 , in an embodiment, the formal verification of the ML model by the control plane network entity 110, e.g. ML-MFVF 110 may be triggered by a model formal verification (MFV) request from an analytics task consumer 120 (see step 1 of figure 1). In an embodiment, the analytics task consumer 120 may be a network function, NF, 120 of the mobile network 100. The ML model may already be at least partially trained but may or may not be deployed yet in the mobile network 100, e.g., within the NWDAF 130. Though the ML model has been validated with a test dataset or even emulated, the possible outputs are not exhausted for all possible inputs. In other words, there might be still an unexpected output provided by the selected ML model given an input not tested from the consumer NF 120. In order to make sure for any inputs the selected ML model will not give an output that is outside of the predefined scope, the ML-MFVF 110 is responsible for calculating the TRUSTJDCT for this selected ML model, based on the MPS, and the information about the one or more ML model structure features indicative of the ML model architecture.

[0040] As illustrated in step 2 of figure 1 , in response to the MFV request from the analytics task consumer 120, which may contain a task and / or ML model identifier, the ML-MFVF 110 may request from the NWDAF 130 implementing the ML model the information about the one or more ML model structure features indicative of the ML model architecture. In an embodiment, the request may contain a task and / or ML model identifier.

[0041] In step 3 of figure 1 , the NWDAF 130 implementing the ML model responds to the request of step 2 of figure 1 by providing the information about the one or more ML model structure features indicative of the ML model architecture to the ML-MFVF 110. This response may contain in addition to the information about the one or more ML model structure features indicative of the ML model architecture a ML model identifier.

[0042] In step 4 of figure 1 , as will be described in more detail below, the ML-MFVF 110 is configured to determine the indicator TRUSTJDCT indicative of the trustworthiness of the ML model based on the MPS obtained from the consumer NF 120 in step 1 of figure 1 and based on the information about the one or more ML model structure features obtained from the NWDAF 130 in step 3 of figure 1. In step 5 of figure 1 , the ML-MFVF 110 is configured to send the indicator TRUSTJDCT indicative of the trustworthiness of the ML model to the consumer NF 120.

[0043] As already described above, the control plane network entity 110, e.g. ML-MFVF 110 is configured to determine the indicator TRUST DCT indicative of the trustworthiness of the ML model based on the MPS obtained, for instance, from the consumer NF 120 and based on the information about the one or more ML model structure features obtained, for instance, from the NWDAF 130. Figure 2 shows a table listing different parameters that according to different embodiments might be part of the MPS and / or the ML model structure features indicative of the ML model architecture. For instance, the MPS may comprise one or more ranges for input values of the ML model and / or one or more ranges for output values of the ML model.

[0044] In an embodiment, the ML model may comprise one or more deep neural networks, DNN, wherein each DNN comprises a plurality of neural layers. As will be appreciated, a DNN may consist of several to hundreds of neural layers, where two consecutive layers are connected by forwarding paths each of which has a weight parameter. This special layer-to-layer structure can be well represented by matrix operations (e.g., multiplications and / or convolutions) concatenating with an activation operation.

[0045] As can be further taken from the table of figure 2, the information about the one or more ML model structure features indicative of the ML model architecture may comprise, for instance, information about: one or more activation functions of one or more layers of the ML model; one or more weight matrices of one or more layers of the ML model, one or more kernel matrices of one or more layers of the ML model; and / or one or more regularizer vectors of one or more layers of the ML model.

[0046] In an embodiment illustrated in figure 3, the NWDAF service consumer 120 may want to check the TRUSTJDCT of the selected ML model before the model is deployed and activated for an analytic task on an NWDAF 130 with Model Training Logic Function (MTLF) 130a. In an embodiment, the ML-MFVF 110 and the MTLF 130a may be implemented as components of a network function 150.

[0047] In step 1 of figure 3, the NWDAF service consumer 120 sends a request over the interface Nwdaf_MLModelProvision_Subscribe / Request to the NWDAF 130 with MTLF 130a. This message requests an ML model provisioning for an analytics task. In addition to the standard parameters, this message may contain an expected MPS, as illustrated in the table of figure 2. In an embodiment, the NWDAF service consumer 120 may be responsible for translating semantic properties into properties that are represented in a mathematical way.

[0048] In step 2 of figure 3, the NWDAF 130 with the MTLF 130a sends the MFV request to the ML- MFVF 110. In an embodiment, the MTLF 130a, as the host of the prospective ML model, sends the MFV request over the interface Nmfvf_MLModelVerification_Request with the MPS parameters, as illustrated in the table shown in figure 2. As will be appreciated, in a conventional mobile network the MTLF would directly send the request to an Analytics Data Repository Function (ADRF) and retrieve the ML model that can accommodate the analytics tasks.

[0049] In step 3 of figure 3, the ML-MFVF 110 sends a query request to an Analytics Data Repository Function (ADRF) 140 over the Nadrf_MLModelManagement_Retrival_Request interface. The request contains not only the parameters needed for selecting an ML model, but also the MPS parameters needed for MFV.

[0050] In step 4 of figure 3, the ADRF 140 sends a response to the ML-MFVF 110 over the Nadrf_MLModelManagement_Retrival_Response interface. The response contains the location where the ML model can be retrieved (e.g., URL or FQDN of the ML model file). In addition, the response may also provide a batch of historical MPSs and their corresponding TRUSTJDCTs that have been verified against the selected ML model.

[0051] In step 5 of figure 3, the ML-MFVF 110 calculates the TRUSTJDCT forthe retrieved ML model. In an embodiment, the ML-MFVF 110 first checks if the MPS, which is desired by the NWDAF service consumer 120, is a subset of any of the historical MPSs returned from the ADRF 140 in the previous step. If this is the case, it means that there was another MPS already covering the desirable MPS, therefore another calculation of the TRUSTJDCT is not necessary and the TRUSTJDCT of the historical MPS can be used. Otherwise, the ML-MFVF 110 calculates a TRUSTJDCT by solving the mathematically formulated optimization problem based on at least some of the parameters listed in the table of figure 2. The specific algorithm to solve this optimization is out of the scope of this invention. However, in the initial request, the NWDAF Service Consumer can specify a particular algorithm in terms of any particular interests (e.g., convergence speed, tightness and so on).

[0052] In step 6a of figure 3, the ML-MFVF 110 sends a response to NWDAF 130 with MTLF 130a with the retrieval location of the selected ML model and its TRUSTJDCT over the Nmfvf_MLModelVerification_Response interface. In optional step 6b of figure 3, the ML-MFVF 110 may send a request to the ADRF 140 over the interface Nadrf_MLModelManagement_Storage_Request for storing the calculated TRUSTJDCT as a historical model verification result for the MPS provided by the consumer 120.

[0053] In step 7 of figure 3, the NWDAF 130 with the MTLF 130a sends a response to the NWDAF service consumer 120 with the calculated TRUSTJDCT over the Nnwdaf_MLModelProvision_Notify interface. This response may contain the retrieval location of the selected ML model that can accommodate the analytic tasks. In addition, the response also contains the TRUST DCT according to the desirable MPS.

[0054] In optional step 8 of figure 3, the NWDAF service consumer 120 may take some further actions based on the TRUSTJDCT received in the previous step, such as triggering the deployment of the ML model, unsubscribing, and / or relaxing the MPS(s).

[0055] In an embodiment, the TRUSTJDCT may indicate the following results (obtained by the ML- MFVF 110 in step 5 of figure 3: (a) the ML model fully satisfies the MPS, e.g., TRUSTJDCT = 1 ; (b) the ML model fails to satisfy the MPS, e.g., TRUST_IDCT=0; and (c) the model only satisfies a relaxed MPS comparing to its original MPS, e.g., TRUST_IDCT=-1. If TRUST_IDCT=1 , the consumer 120 can safely use the selected ML model. The consumer 120 can further instruct the NWDAF 130 with MTLF 130a to retrieve and deploy the selected model with the address provided from the ADRF 140. If TRUST_IDCT=0, the consumer 120 may decide if a new model is needed. In an embodiment, this may trigger a re-training of the ML model. If TRUST_IDCT=-1 , the consumer 120 may consider whether a relaxed MPS could be acceptable. If so, the consumer 120 may proceed to use the selected model. Otherwise, the consumer 120 may trigger a new model training.

[0056] In a further embodiment shown in figure 4, the NWDAF service consumer 120 may want to check the TRUSTJDCT of a selected ML model that is already deployed within an Analytic Logic Function (AnLF) 130b of the NWDAF 130 before the consumer 120 starts using the model by sending ML model inputs for inference.

[0057] In step 1 of figure 4, the NWDAF service consumer 120 sends a request over the Nwdaf_MLModelProvision_Subscribe / Request interface to the NWDAF 130 with the AnLF 130b. This message requests an ML model provisioning for an analytics task. In addition to the standard parameters, this message may contain an expected MPS, as illustrated in the table of figure 2. In an embodiment, the NWDAF service consumer 120 may be responsible for translating semantic properties into properties that are represented in a mathematical way.

[0058] In step 2 of figure 4, the NWDAF 130 with AnLF 130b sends the MFV request to the ML-MFVF 110. The AnLF 130b, as the host of the deployed ML model, sends the MFV request over the interface Nmfvf_MLModelVerification_Request with the MPS parameters, as illustrated in the table of figure 2.

[0059] In step 3 of figure 4, the ML-MFVF 110 sends a query request to the Analytics Data Repository Function (ADRF) 140 over the Nadrf_MLModelManagement_Retrival_Request interface. The request may contain not only the parameters needed for selecting an ML model, but also the new MPS parameters needed for MFV. The request may serve the purpose to retrieve the historical MPS(s) and their TRUSTJDCTs of the deployed ML model, instead of the location address of the model.

[0060] In step 4 of figure 4, the ADRF 140 sends a response to the ML-MFVF 110 over the Nadrf_MLModelManagement_Retrival_Response interface. The response contains historical MPSs and their corresponding TRUSTJDCTs that have been verified against the selected ML model identified with Analytics J D#.

[0061] In step 5 of figure 4, the ML-MFVF 110 calculates the TRUSTJDCT forthe retrieved ML model. In an embodiment, the ML-MFVF 110 may first check if the MPS, which is desired by the NWDAF service consumer 120, is a subset of any of the historical MPSs returned from the ADRF 140 in the previous step of figure 4. If this is the case, this means that there was another MPS already containing the desirable MPS. Therefore, in this case a re-calculation of the TRUSTJDCT is not needed and the TRUSTJDCT of the historical MPS may be used. Otherwise, the ML-MFVF 110 calculates a TRUSTJDCT by solving the mathematically formulated optimization problem based on at least some of the parameters listed in the table of figure 2. The specific algorithm to solve this optimization is out of the scope of this invention. However, in the initial request, the NWDAF service consumer 120 may specify a particular algorithm in terms of any particular interests (e.g., convergence speed, tightness and so on).

[0062] In step 6a of figure 4, the ML-MFVF 110 sends a response to the NWDAF 130 with the AnLF 130b with the retrieval location of the selected ML model and its TRUSTJDCT over the Nmfvf_MLModelVerification_Response interface. In optional step 6b of figure 4, the ML-MFVF 110 sends a request to the ADRF 140 over the Nadrf_MLModelManagement_Storage_Request interface for storing the calculated TRUSTJDCT as a historical model verification result for the MPS from the consumer 120.

[0063] In step 7 of figure 4, the NWDAF 130 with AnLF 130b sends a response to the NWDAF service consumer 120 with the calculated TRUSTJDCT over the interface Nnwdaf_MLModelProvision_Notify. This response may contain the retrieval location of the selected ML model that can accommodate the analytic tasks. In addition, the response also contains the TRUSTJDCT according to the desirable MPS.

[0064] In optional step 8 of figure 4, the NWDAF service consumer 120 may take some further actions based on the TRUSTJDCT received in the previous step, such as triggering the deployment of the ML model, unsubscribing, and / or relaxing the MPS(s).

[0065] In an embodiment, the TRUSTJDCT may indicate the following results (obtained by the ML- MFVF 110 in step 5 of figure 4: (a) the ML model fully satisfies the MPS, e.g., TRUSTJDCT = 1 ; (b) the ML model fails to satisfy the MPS, e.g., TRUST_IDCT=0; and (c) the model only satisfies a relaxed MPS comparing to its original MPS, e.g., TRUST_IDCT=-1. If TRUST_IDCT=1 , the consumer 120 can safely use the selected ML model. The consumer 120 can further instruct the NWDAF 130 with MTLF 130a to retrieve and deploy the selected model with the address provided from the ADRF 140. If TRUST_IDCT=0, the consumer 120 may decide if a new model is needed. In an embodiment, this may trigger a re-training of the ML model. If TRUST_IDCT=-1 , the consumer 120 may consider whether a relaxed MPS could be acceptable. If so, the consumer 120 may proceed to use the selected model. Otherwise, the consumer 120 may trigger a new model training.

[0066] As already described above, in an embodiment, the ML model formally verified by the ML- MFVF 110 may comprise one or more deep neural networks, DNN, wherein each DNN comprises a plurality of neural layers. As will be appreciated, with a vector input, the output of a DNN can be represented recursively in a closed-form formula. To verify if this DNN satisfies a property, the original mathematical representation of the DNN may be augmented with the desirable properties that are also translated to closed-form equation. Using this augmented function as an objective function, an optimization (usually minimization) problem may be solved over a domain defined by the possible input values to the DNN. The minimizer(s) and its value of the augmented function may tell if the desirable properties would be violated. However, solving the optimization problem is not a trivial task because the objective function is usually not a (quasi-)convex function due to the activation functions recursively included in the objective function. However, the ML-MFVF 110 according to an embodiment may be configured to use various relaxation techniques replacing the activation functions (e.g., ReLU, tanh, sigmoid and arctan) with a smooth and continuous alternative. Thereafter, the ML-MFVF 110 according to an embodiment may be configured to use existing optimization algorithms, in particular candidate solvers, such as Bound propagation, bound and branch, gradient propagation and the like. In other words, in an embodiment, for determining the indicator indicative of the trustworthiness of the ML model based on the ML model property set and the one or more ML model structure features the control plane network entity 110, e.g. ML-MFVF 110 is configured to formulate a non-convex ML model verification problem based on the MPS and the one or more ML model structure features, to relax the non-convex ML model verification problem to a quasi-convex ML model verification problem and to determine the indicator indicative of the trustworthiness of the ML model as a solution of the quasi-convex ML model verification problem. As already described above, the non-convex ML model verification problem may be relaxed to the quasi-convex ML model verification problem by relaxing one or more activation functions of one or more layers of the ML model to one or more piece-wise smooth functions.

[0067] Figure 5 shows a flow diagram illustrating a method 500 the control plane network entity 110, e.g. ML-MFVF 110 for formal verification of a ML model implementing a task, in particular an analytics task in the mobile network 100. The method 500 comprises a step 501a of obtaining an ML model property set, MPS, defining one or more input constraints and / or one or more output constraints for the ML model and a step 501b of obtaining one or more ML model structure features indicative of the ML model architecture. Moreover, the method 500 comprises a step 503 of determining an indicator, e.g. the TRUSTJDCT indicative of the trustworthiness of the ML model based on the ML model property set and the one or more ML model structure features. As will be appreciated, steps 501a and 501 b may be performed in any possible order and / or at least partially overlapping.

[0068] The method 500 can be performed by the control plane network entity 110, e.g. the ML-MFVF. Thus, further features of the method 500 result directly from the functionality of the control plane network entity 110, e.g. the ML-MFVF 110 as well as the different embodiments thereof described above and below.

[0069] The person skilled in the art will understand that the "blocks" ("units") of the various figures (method and apparatus) represent or describe functionalities of embodiments of the present disclosure (rather than necessarily individual "units" in hardware or software) and thus describe equally functions or features of apparatus embodiments as well as method embodiments (unit = step).

[0070] In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus, and method may be implemented in other manners. For example, the described embodiment of an apparatus is merely exemplary. For example, the unit division is merely a logical function division and may be another division in an actual implementation. For example, a plurality of units or components may be combined or integrated into another system, or some features may be ignored or not performed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections may be implemented by using some interfaces. The indirect couplings or communication connections between the apparatuses or units may be implemented in electronic, mechanical, or other forms.

[0071] The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one position, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.

[0072] In addition, functional units in the embodiments of the disclosure may be integrated into one processing unit, or each of the units may exist alone physically, or two or more units may be integrated into one unit.

Claims

CLAIMS1. A control plane network entity (110) for formal verification of a machine learning, ML, model implementing a task in a mobile network (100), wherein the control plane network entity (110) is configured to: obtain an ML model property set defining one or more input constraints and / or one or more output constraints for the ML model; obtain one or more ML model structure features; and determine an indicator indicative of a trustworthiness of the ML model based on the ML model property set and the one or more ML model structure features.

2. The control plane network entity (110) of claim 1 , wherein the one or more input constraints and / or one or more output constraints defined by the ML model property set comprise one or more ranges for input values of the ML model and / or one or more ranges for output values of the ML model.

3. The control plane network entity (110) of claim 1 or 2, wherein the control plane network entity (110) is configured to obtain the ML model property set from a consumer network entity (120).

4. The control plane network entity (110) of claim 3, wherein the control plane entity (110) is configured to receive the ML model property set from the consumer network entity (120) as part of a request for formal verification of the ML model implementing the task.

5. The control plane network entity (110) of claim 4, wherein the request for formal verification of the ML model implementing the task comprises a task identifier and / or a ML model identifier.

6. The control plane network entity (110) of any one of claims 2 to 5, wherein the control plane network entity (110) is configured to provide the indicator indicative of the trustworthiness of the ML model to the consumer network entity (120).

7. The control plane network entity (110) of any one of the preceding claims, wherein the one or more ML model structure features comprise information about: one or more activation functions of one or more layers of the ML model, one or more weight matrices of one or more layers of the ML model, one or more kernel matrices of one or more layers of the ML model, and / or one or more regularizer vectors of one or more layers of the ML model.

8. The control plane network entity (110) of claim 7, wherein the control plane network entity (110) is configured to obtain the one or more ML model structure features from a further control plane network entity (130) providing the task implemented by the ML model, in response to sending a request to the further control plane network entity (130), wherein the request comprises a task identifier and / or a ML model identifier.

9. The control plane network entity (110) of claim 8, wherein the task implemented by the ML model is an analytics task and wherein the further control plane network entity (130) is a network data analytics function, NWDAF, (130) of the mobile network (100).

10. The control plane network entity (110) of any one of the preceding claims, wherein the indicator indicative of the trustworthiness of the ML model indicates that the ML model satisfies the ML model property set, that the ML model does not satisfy the ML model property set and / or that the ML model satisfies a relaxed ML model property set.11 . The control plane network entity (110) of any one of the preceding claims, wherein for determining the indicator indicative of the trustworthiness of the ML model based on the ML model property set and the one or more ML model structure features the control plane network entity (110) is configured to formulate a non-convex ML model verification problem based on the model property set and the one or more ML model structure features, to relax the non- convex ML model verification problem to a quasi-convex ML model verification problem and to determine the indicator indicative of the trustworthiness of the ML model as a solution of the quasi-convex ML model verification problem.

12. The control plane network entity (110) of claim 11 , wherein the control plane network entity (110) is configured to relax the non-convex ML model verification problem to the quasi- convex ML model verification problem by relaxing one or more activation functions of one or more layers of the ML model to one or more piece-wise smooth functions.

13. A method (500) for operating a control plane network entity (110) for formal verification of a machine learning, ML, model implementing a task in a mobile network (100), wherein the method (500) comprises: obtaining (501a) an ML model property set defining one or more input constraints and / or one or more output constraints for the ML model; obtaining (501b) one or more ML model structure features; and determining (503) an indicator indicative of a trustworthiness of the ML model based on the ML model property set and the one or more ML model structure features.

14. A computer program product comprising a computer-readable storage medium for storing program code which causes a computer or a processor to perform the method (500) of claim 13 when the program code is executed by the computer or the processor.

Images