Managing user agreement to analytics and event monitoring operations in core network

Abstract

In order to configure analysis or event monitoring in a mobile communication system, a first network function (NF) of a core network (CN) sends (1002) a request related to an operation involving analysis and / or event monitoring to a second NF, the request indicating that the operation requires user agreement; and receiving (1004) a response to the request from the second NF, the response comprising user agreement information for one or more user equipment units (UEs).

Description

Technical Field

[0001] The present disclosure relates generally to wireless communications, and more particularly to managing user consent for analytics and event monitoring operations in cellular communication networks. Background Art

[0002] This background description is provided for the purpose of generally presenting the context of the present disclosure. The work of the presently named inventors, to the extent that it is described in this background section, and aspects of the specification that otherwise may not be considered prior art at the time of filing, are neither explicitly nor implicitly admitted to be prior art to the present disclosure.

[0003] The 3rd Generation Partnership Project (3GPP) has recently begun studying support for services based on artificial intelligence (AI) / machine learning (AI / ML). Specifically, 3GPP proposes to enable 5G system (5GS) support to assist AI / ML-enabled applications such as video / speech recognition, robot control, automotive services, etc. Some of these services require the distribution of AI / ML models to UEs via the 5G network.

[0004] According to a scheme that can be called federated learning (FL), participating UEs collaboratively share locally trained AI / ML models and upload these models to an application server via a 5G network. The AS then aggregates the AI / ML models and distributes the aggregated AI / ML models to UEs that have joined the federated learning scheme as FL members. The UE can also upload relatively small updates to the local version of the AI / ML model to the application server for further integration into the model managed by the application server.

[0005] 3GPP has recently considered whether and how 5GS can provide assistance to AI / ML-enabled applications, which facilitates FL operations and model distribution / redistribution between application clients and application servers running on UEs (e.g., FL member selection, group performance monitoring, adequate network resource allocation and assurance). 3GPP has also considered what information 5GC needs to assist the Application Function (AF) in selecting and managing a group of UEs participating in FL operations.

[0006] However, these developments fail to address user privacy concerns. According to 3GPP ETSI TS 123.288 Version 17.4.0 (2022-05), the Network Data Analysis Function (NWDAF) only excludes the corresponding SUPI [Subscription Permanent Identifier] from requests to collect data if the request is for a group of UEs or "any UE" and generates analytics or ML models for other users who have granted user consent. There is currently no mechanism to assist applications in making user choices about application servers that rely on analytics and / or event information from 5GC. Summary of the invention

[0007] An example embodiment of the technology disclosed herein is a method for configuring analysis or event monitoring in a mobile communication system. The method is implemented in a first network function (NF) of a core network (CN) and includes: sending a request related to an operation involving analysis and / or event monitoring from the first NF to a second NF, the request indicating that the operation requires user consent; and receiving a response to the request from the second NF, the response including user consent information of one or more user equipment units (UEs).

[0008] Another example embodiment of these technologies is a method for managing analysis or event monitoring in a mobile communication system, which is implemented in a first NF of a CN and includes: subscribing to notifications related to changes in user consent of one or more user equipment units (UEs); and in response to receiving a notification that user consent of one or more UEs has changed, notifying at least a second network function (NF) to provide a service involving analysis exposure or event exposure, which service is related to the one or more UEs.

[0009] Yet another example embodiment of the techniques is a NF implemented in a CN, the CN comprising processing hardware, the NF configured to perform one of the above methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 is a block diagram of an example wireless communication system in which a user equipment unit (UE) participates in federated learning controlled by an application server and a core network (CN) manages user consent associated with the federated learning;

[0011] Figure 2 is a block diagram of an example protocol stack, according to which, Figure 1 The UE can be connected with Figure 1 Communicate with the RAN;

[0012] Figure 3 It is a service-based representation of the 5GS architecture, including the overall non-roaming reference architecture of the 5GS policy and charging control framework;

[0013] Figure 4 It is a 5GS architecture representation based on reference points, including the overall non-roaming reference architecture of the 5GS policy and charging control framework;

[0014] Figure 5 is a messaging diagram for an example scenario in which a network function sends a user consent indicator to another network function to indicate that user consent is required for an operation involving analytics and / or event monitoring;

[0015] Fig. 6Ais a messaging diagram for an example scenario of a network function subscribing to notifications regarding changes in user consent related to an operation involving analytics;

[0016] Figure 6B is a messaging diagram for an example scenario of a network function subscribing to notifications regarding changes in user consent associated with an operation involving event monitoring;

[0017] Figure 7 is a messaging diagram for an example scenario in which a network function subscribes to notifications of events associated with mandatory user consent checks;

[0018] Figure 8 is a messaging diagram for an example scenario of a network function providing a service associated with a mandatory user consent check;

[0019] Fig. 9 Yes, you can Figure 1 , Figure 3 or Figure 4 A flowchart for managing user consent information on a per-application basis implemented in a unified data management (UDM) of a core network of;

[0020] Fig.10 Yes, you can Figure 1 , Figure 3 or Figure 4 A flowchart of an example method for configuring analysis or event monitoring in a mobile communication system implemented in a network function (NF) of a core network of; and

[0021] Fig.11 Yes, you can Figure 1 , Figure 3 or Figure 4 Flowchart of an example method for management analysis or event monitoring implemented in a network function (NF) of a core network of FIG. DETAILED DESCRIPTION

[0022] Third-party applications can select UE as a FL member for FL operation to support AI / ML-enabled applications. To protect user privacy, it is important to ensure that the UE grants user consent to expose some UE data to third-party applications as part of analytics information.

[0023] A network function (NF) operates in a core network (CN) of a cellular communication system and indicates to another NF that an operation involving analysis and / or event monitoring requires user consent. Other NFs may provide user consent information in response to the indication or in response to different triggering events. In this way, an application function (AF), for example, may select a UE for a federated learning operation, an AI / ML learning operation, etc. in view of user consent. In addition, in some implementations, the NF may subscribe to notifications about changes in user consent and notify another NF of the change.

[0024] Example systems and protocol stacks

[0025] First reference Figure 1 , the techniques of the present disclosure may be performed by an example wireless communication system 100. The example wireless communication system 100 includes UEs 102A and 102B, a base station (BS) 104, a base station 106, and a core network (CN) 110, such as a fifth generation (5G) core (5GC). The base stations 104 and 106 may operate in a RAN 105 connected to the CN 110. The CN 110 may also be implemented as a sixth generation (6G) core or another suitable core network.

[0026] Base station 104 covers cell 124, and base station 106 covers cell 126. If base station 104 is a gNB, cell 124 is an NR cell. If base station 124 is an ng-eNB, cell 124 is an evolved universal terrestrial radio access (E-UTRA) cell. Similarly, if base station 106 is a gNB, cell 126 is an NR cell, and if base station 126 is an ng-eNB, cell 126 is an E-UTRA cell. Cells 124 and 126 may be located in the same radio access network notification area (RNA) or in different RNAs. Cells 124 and 126 may partially overlap, so that UE 102A or 102B may select, reselect, or switch from one of the cells 124 and 126 to another. In general, RAN 105 may include any number of base stations, and each of the base stations may cover one, two, three, or any other suitable number of cells. UE 102 may support at least a 5G NR (or simply “NR”) air interface to communicate with base stations 104 and 106. Each of base stations 104, 106 may be connected to CN 110 via an interface (e.g., S1 or NG interface). Base stations 104 and 106 may also be interconnected via an interface (e.g., X2 or Xn interface) for interconnecting NG RAN nodes.

[0027] Reference below Figure 3 and Figure 4 Several NFs that constitute CN 110 are discussed. One or more NFs of CN 110 implement reference Figures 5 to 11 The user consent control logic 112 is discussed.

[0028] Although Figure 1Although not shown in the figure to avoid clutter, CN 110 may include processing hardware, which may include one or more general-purpose processors (e.g., CPUs) and non-transitory computer-readable memory storing instructions executed by the one or more general-purpose processors. Additionally or alternatively, the processing hardware may include a dedicated processing unit. The processing hardware may be configured to implement the techniques of the present disclosure to enable 5GS support for advanced media services.

[0029] Base station 104 is equipped with processing hardware, which may include one or more general-purpose processors (e.g., CPUs) and non-transitory computer-readable memory (not shown) storing instructions executed by one or more general-purpose processors. Additionally or alternatively, the processing hardware may include a dedicated processing unit.

[0030] UE 102A is equipped with processing hardware 130A, which may include one or more general-purpose processors such as CPUs, and non-transitory computer-readable memory storing machine-readable instructions executable on one or more general-purpose processors, and / or dedicated processing units. UE 102A also includes a transceiver 132A to communicate with RAN 105 over a radio interface. In addition, UE 102A includes a memory 134A storing an ML model 140A. UE 102B has a similar implementation and stores an ML model 140B.

[0031] UEs 102A and 102B participate in FL operations, which are controlled by application server 150 via CN 110. To this end, application server 150 implements ML model aggregation / distribution logic 152. In operation, application server 150 aggregates ML models 140A and 140B and / or updates these models to maintain ML model 160. Application server 150 also distributes the current version of ML model 160 to UEs 102A and 102B.

[0032] Figure 2An example protocol stack 200 is shown in a simplified manner, according to which a UE 102 can communicate with an eNB / ng-eNB or gNB (e.g., one or more of base stations 104, 106). In the example stack 200, a physical layer (PHY) 202A of EUTRA provides transport channels to an EUTRA MAC sublayer 204A, which in turn provides logical channels to an EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A in turn provides RLC channels to an EUTRA PDCP sublayer 208 and, in some cases, to an NR PDCP sublayer 210. Similarly, an NR PHY 202B provides transport channels to an NR MAC sublayer 204B, which in turn provides logical channels to an NR RLC sublayer 206B. The NR RLC sublayer 206B in turn provides data delivery services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 may in turn provide a service data adaptation protocol (SDAP) 212 or a radio resource control (RRC) sublayer ( Figure 2 In some implementations, UE 102 supports the following: Figure 2 Both the EUTRA and NR stacks shown are provided to support switching between EUTRA and NR base stations and / or to support DC via EUTRA and NR interfaces. Figure 2 As shown, the UE 102 may support the layering of the NR PDCP 210 on the EUTRA RLC 206A, and the layering of the SDAP sublayer 212 on the NR PDCP sublayer 210.

[0033] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets, which may be referred to as service data units (SDUs) (e.g., from an Internet Protocol (IP) layer layered directly or indirectly on the PDCP layer 208 or 210), and output packets, which may be referred to as protocol data units (PDUs) (e.g., to the RLC layer 206A or 206B). For simplicity, this disclosure refers to both SDUs and PDUs as "packets", except where the distinction between SDUs and PDUs is relevant.

[0034] For example, on the control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 may provide a signaling radio bearer (SRB) or an RRC sublayer ( Figure 2(not shown) to exchange RRC messages or non-access stratum (NAS) messages. On the user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 may provide data radio bearers (DRBs) to support data exchange. The data exchanged on the NR PDCP sublayer 210 may be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.

[0035] Figure 3 yes Figure 1 A service-based 5GS architecture representation 300 of a system that can be implemented. In representation 300, the overall non-roaming reference architecture of the policy and charging control (PCC) framework of the 5GS includes components shown using solid lines, and other components are shown using dashed lines. According to the representation, a network function enables other authorized network functions to access the services of the network function. Components outside the PCC framework include a network slice selection function (NSSF) 302, a network repository function (NRF) 306, a unified data management (UDM) 308, an edge application server discovery function (EASDF) 310, a network slice specific authentication and authorization function (NSAAF) 312, an authentication server function (AUSF) 314, a service communication agent (SCP) 316, and a network slice admission control function (NSACF) 316. The non-PCC architecture further includes a UE 102, a RAN 105, and a data network (DN) 330.

[0036] The PCC framework in architecture 300 includes a unified data repository (UDR) 352, a network exposure function (NEF) 354, a network data analysis function (NWDAF) 356, an application function (AF) 357, a policy control function (PCF) 360, a charging function (CHF) 362, an access and mobility management function (AMF) 364, a session management function (SMF) 366 and a user plane function (UPF) 370.

[0037] In an example implementation, AF 358 includes a user consent controller 112A, and NEF 354 includes a user consent controller 112B. In various implementations, CN 110 may include only user consent controller 112A, only user consent controller 112B, or both. User consent controllers 112A and 112B may be collectively referred to as user consent control logic 112 of CN 110.

[0038] Figure 4 The 5GS architecture is based on reference point representation 400. Figure 4 In the figure, the non-roaming reference architecture of the PCC framework of 5GS is shown as blocks and connections using solid lines, and components and connections outside the PCC framework are shown using dashed lines.

[0039] Several example techniques for assisting an application in selecting a UE based on user consent are discussed below. Figures 5 to 11 Similar events in the Fig. 6A and 6B Event 640 with Figure 5 540 of ), differences will be discussed below where appropriate. In addition to the differences shown in the figures and discussed below, any of the alternative implementations discussed with respect to a particular event (e.g., for message delivery and processing) can be applied to events marked with similar reference numbers in other figures.

[0040] Figure 5 A message passing diagram of an example scenario 500 in which an NF (such as AF 358 and / or NEF 354) sends a user consent indicator to another NF (such as NEF 354 or NWDAF 356) to indicate that an operation involving analysis and / or event monitoring requires user consent. For simplicity, operations requiring analysis and / or event monitoring may be simply referred to as "analysis operations" hereinafter. The other NF may then provide user consent information, such as a list of UEs granted user consent and / or a list of UEs without user consent, to the original NF to configure the analysis operation.

[0041] In general, the AF may send a request similar to an analysis request procedure performed by the AF via the NEF, a network data analysis request, or an analysis subscription / unsubscription procedure performed by the AF via the NEF, but here the request includes a user consent indicator to the NEF / NWDAF. In view of the user consent indicator, the NWDAF retrieves the user consent for the purpose of data collection from the UDM for the target UE identifier. In addition, if the user consent changes, the NWDAF may subscribe to the UDM service. If the user consent is terminated, the NWDAF terminates the event exposure service provided by other NFs.

[0042] Specifically, in scenario 500, NEF 354 controls 502 analytics and event exposure mapping. For example, AF 358 sends 510 a Nnef_AnalyticsExposure_Fetch message with a user consent indication as an information element (IE) to NEF 354. In another scenario, AF 358 sends 510 a Nnef_AnalyticsExposure_Subscribe message to NEF 354. Thus, AF 358 may send 510 a request similar to the analytics request procedure performed by AF via NEF, which involves Nnef_AnalyticsExposure_Fetch / Fetch response and Nnwdaf_AnalyticsInfo_Request / Request response messages (see TS 23.288, clauses 6.1.2.1 and 6.1.2.2).

[0043] In addition to the user consent indication, the Nnef_AnalyticsExposure_Subscribe message may also include the analysis ID, the target UE identifier, and the validity criteria (e.g., the minimum number of valid UEs for operation and the validity duration). The AF 358 sends 510 this message with the user consent indicator to trigger a user consent check at the NWDAF 356 (see below) and to cause the NWDAF 356 to provide the AF 358 with a list of UEs that have granted user consent (and / or a list of UEs that do not have user consent) via the NEF 354. In some implementations, the NWDAF 356 provides these UE lists to the NEF 354 / AF 356 along with the analysis results.

[0044] The NEF 354 sends 520 a Nnwdaf_AnalyticsInfo_Request message with a user consent indicator to the NWDAF 356. In another scenario, the NEF 354 sends 520 a Nnwdaf_AnalyticsSubscription_Subscribe message to the NWDAF 356. The message sent 520 by the NEF 354 may also include the validity criteria received from the AF 358.

[0045] In response to receiving 520 the Nnwdaf_AnalyticsInfo_Request message or the Nnwdaf_AnalyticsSubscription_Subscribe message, the NWDAF 356 may check user consent via the UDM 308. The NWDAF 356 may check user consent using a subscription permanent identifier (SUPI) in the target UE identifier. The NWDAF 356 may further store and / or maintain a list of UEs that have granted user consent and apply the list to the rest of the related procedures.

[0046] In one implementation, when the request from AF 358 (event 510) indicates a minimum number of valid UEs, NWDAF 356 checks how many UEs are associated with granting user consent. If the number of UEs granted user consent meets the minimum number of valid UEs, NWDAF 356 continues to serve the analysis request. Otherwise, NWDAF 356 may wait until the number of UEs granted user consent reaches the minimum number of valid UEs and then continue to serve the analysis request. In another implementation, NWDAF 356 sends a rejection message to NEF 354 / AF 358. The rejection message may include a list of UEs granted user consent. The rejection message may also indicate the reason for the rejection.

[0047] The NWDAF 356 sends 530 a Nudm_SDM_Get 530 message to the UDM 308. The UDM 308 and the UDR 352 communicate 540 as part of the Nudr_DM_Query process. The UDM 308 then sends 532 a Nudm_SDM_Reply message to the NWDAF 356. When the NWDAF 356 sends 530 the APP_ID to the UDM 308, the UDM 308 queries the UDR 352 to check for user consent for the application corresponding to the APP_ID. If the user consent changes, the NWDAF 356 may also subscribe to the UDM service. Subsequently, if the user consent is terminated, the NWDAF 356 may terminate the subscribed event exposure services provided by other NFs (e.g., services requested during procedure 550 discussed below).

[0048] Continue to refer Figure 5 , AMF / SMF / PCF 364 / 366 / 360 and NWDAG 356 execute 550Nnf_EventExposureSubscribe / Notify / Unsubscribe procedure. In this procedure, NWDAF 356 subscribes to the event exposure service provided by NF, and the user agrees that the changes may have an impact on the service.

[0049] The NWDAF 356 sends 522 a Nnwdaf_AnalyticsInfo_Response message to the NEF 354. In another scenario, the NWDAF 356 sends 522 a Nnwdaf_AnalyticsSubscription_Notify message to the NEF 354. The NWDAF 356 returns 522 a result of the analysis, which may include the analysis result and, depending on the implementation, may include a list of UEs that have not granted user consent or a list of UEs that have granted user consent. The NWDAF 356 may include 522 a reason value and a list of UEs that have not granted user consent.

[0050] The NEF 354 then sends 515 a Nnef_AnalyticsExposure_Fetch_Response message or a Nnef_AnalyticsExposure_Notify message to the AF 358. The message may include a list of UEs that have granted user consent. More generally, the NEF 254 may send 515 any suitable user consent information. The AF 358 may select 590 the UEs that have granted consent for an analysis operation. The operation may be, for example, a FL operation, and the AF 358 may therefore select a FL member in view of the user consent information.

[0051] according to Fig. 6A and Figure 6B The technology shown, for event exposure or analysis exposure scenarios, NEF can subscribe to the UDM service to detect whether the user consent changes. When the user consent is terminated, the NEF can terminate the event exposure service provided by other NFs.

[0052] Fig. 6A 6 is a message passing diagram of an example scenario 600A in which a network function subscribes to notifications of changes in user consent related to operations involving analysis. More specifically, NEF 354 can subscribe to the UDM service to receive notifications of changes in user consent. If user consent is terminated, NEF 354 can terminate the event exposure service provided by other NFs, similar to the corresponding steps in scenario 500 discussed above.

[0053] AF 358 sends 611 Nnef_AnalyticsExposure_Fetch message to NEF 354, or in another scenario, sends Nnef_AnalyticsExposure_Subscribe message. The message may include an analysis ID, a target UE identifier, a user consent indicator, and validity criteria (e.g., a minimum number of valid UEs and a validity duration). Similar to scenario 500, the user consent indicator causes 5GC 110 to force a user consent check at NEF 354 and / or NWDAF 356, and provide analysis results and a list of UEs that have granted user consent (or another type of user consent information).

[0054] When the NEF 354 receives 611 the Nnef_AnalyticExposure Fetchrequest message including the user consent indicator, the NEF 354 may check the user consent of the UE according to the SUPI in the target UE identifier via the UDM 308 and store a list of UEs that have granted the user consent.

[0055] If the NEF 354 provides the APP_ID in the request message, the UDM 308 checks the user consent for the indicated application via the UDR 352. The NEF 354 subscribes 634 to the UDM service to obtain notifications about changes in user consent. If the user consent is terminated, the NEF 354 terminates the subscribed analysis exposure or event exposure service provided by other NFs. In some implementations, the NEF 354 subscribes using a dedicated event code, such as "Change of User Consent". Specifically, the code is defined specifically for the purpose of monitoring changes in user consent and is different from other events, as shown in the last row of Table 1 below.

[0056] event The NF that detected the event Connectivity loss AMF UE reachability AMF、UDM Location Report AMF、GMLC Changes in SUPI-PEI association UDM Roaming status UDM Communication failure AMF Availability of downlink data notification after failure AMF Changes in User Consent UDM

[0057] Table 1.

[0058] If the number of UEs granted user consent is less than the minimum number of valid UEs corresponding to the validity criteria of the target UE identifier, the NEF 354 sends 616 a Nnef_AnalyticsExposure_Fetch_reject message to the AF 358. The NEF 354 may also send a corresponding cause value.

[0059] The NEF 354 sends 621 Nnwdaf_AnalyticsInfo_Request to the NWDAF 356. If the validity criteria indicates a minimum number of valid UEs in the target UE identifier, the NEF 354 may proceed with the analysis if the number of UEs granted user consent for analytics exposure purposes meets the minimum number of valid UEs.

[0060] Continue to refer Fig. 6A , the NWDAF 356 subscribes 650 to the event exposure service provided by the affected NF. The NWDAF 356 sends 623 a Nnwdaf_AnalyticsInfo_Response message to the NEF 354 to return the analysis result. In another scenario, the NWDAF 356 sends 623 a Nnwdaf_Analytics Subscription_Notify message with the analysis result.

[0061] The NEF 354 sends 615 a Nnef_AnalyticsExposure_Fetch_Response message (or, in another scenario, Nnef_AnalyticsExposure_Notify) to the AF 358 and includes the analysis result and the list of UEs that have granted user consent.

[0062] Figure 6B is a message passing diagram of an example scenario 600B, which is similar to Fig. 6A Scenario 600A is substantially similar, except that here AF 358 sends 612 Nnef_EventExposure_Subscribe / Unsubscribe_request message to NEF 354. NEF 354 optionally sends 617 Nnef_EventExposure_Subscribe / Unsubscribe_response / reject message and sends 618 Nnef_EventExposure_Subscribe / Unsubscribe_response or Nnef_EventExposure_Notify message to AF 358 in response to the message of event 612.

[0063] Next, Figure 7is a messaging diagram for an example scenario 700 in which a NF subscribes to notifications of events associated with a mandatory user consent check. To this end, the NF may use the event ID specified in the last row of Table 1 above. More specifically, the event exposure procedure may expose this event ID to the AF 358. The NEF 354 may further subscribe to the UDM service to obtain notifications related to user consent changes, similar to the example discussed above. If the user consent is terminated, the NEF 354 may terminate the event exposure service provided by other NFs.

[0064] Therefore, for a target UE identifier corresponding to a UE or a group of UEs, the AF can effectively operate as a service consumer using the NEF services.

[0065] AF 358 sends 712 Nnef_EventExposure_Subscribe / Unsubscribe_request message to NEF 354. The message may include a dedicated event ID (e.g., "Change of user consent") to request the event exposure procedure. The message may also include a target UE identifier and validity criteria (e.g., minimum number of valid UEs and validity duration). The event identifier in the message causes 5GC 110 to force a user consent check at NEF 354. Therefore, AF 358 indicates that user consent is required for the analysis operation by including the dedicated event identifier in the subscription message.

[0066] When the NEF 354 receives a dedicated event identifier corresponding to the user consent check, the NEF 354 checks the user consent of the UE via the UDM 308, which may be based on the SUPI in the target UE identifier. The NEF 354 may store a list of UEs that have granted user consent.

[0067] If the NAF provides 733 APP_ID in the request message, the UDM 308 may also check 740 the user consent for the indicated application via the UDR 352. The NEF 354 may subscribe to the UDM service to monitor changes in user consent. If the user consent is terminated, the NEF 354 may terminate the subscribed analysis exposure or event exposure service provided by other NFs.

[0068] If the number of UEs granted user consent is less than the number included in the validity criteria of the valid UEs specified in the target UE identifier, the NEF 354 may return a rejection message to the AF 358 and include a list of UEs granted user consent and corresponding reasons.

[0069] The NEF 354 may send 718 a Nnef_EventExposure_Subscribe / Unsubscribe_response message to the AF 358 , which includes a list of UEs that have granted user consent to the AF 358 .

[0070] AF 358 may maintain 780 a list of UEs to which user consent has been granted and apply this list to the remaining steps of the procedure. If the number of UEs to which user consent has been granted for event exposure and analysis exposure purposes meets the minimum number of valid UEs required, AF 358 proceeds with the analysis. Otherwise, in some implementations, AF 358 waits until NEF 354 notifies AF 358 of the required number of UEs to which user consent has been granted.

[0071] The AF 358 may then perform procedures with the NEF 354 for analyzing exposure, event exposure, or both based on the list of UEs that the AF 358 maintains 780 that have been granted user consent.

[0072] Next, Figure 8 A technique is shown according to which the AF can request information exposure of the UE for event exposure using event identifiers, analysis exposure via exposure identifiers, or both. As part of the procedure, the NEF checks the user consent for the target UE identifier (which can correspond to a single UE or multiple UEs) and then proceeds to request data exposure from other NFs (including AMF / SMF / PCF / NWDAF). This procedure can be understood as a general information exposure procedure for NFs (including NWDAF and NF (AMF / SMF / PCF)), where the NEF service is dedicated to checking user consent

[0073] Specifically, AF 358 sends 813 a message dedicated to the purpose of this scenario to NEF 354. For example, the message may be called Nnef_InfoExposureSubscribe / Unsubscribe_request. AF 358 indicates 813 one or more event identifiers, analysis identifiers, or both in this message. AF 358 may further indicate 813 a UE identifier and an APP_ID. AF 358 may also indicate validity criteria (e.g., a minimum number of valid UEs and a validity duration). The dedicated message InfoExposureSubscribe enables 5GC 110 to enforce a user consent check at NEF 354.

[0074] In response to receiving 813 the Nnef_InfoExposureSubscribe / Unsubscribe_request message, the NEF 354 may initiate a user consent check via the UDM 308, which may be based on the SUPI in the target UE identifier. The NEF 354 may store a list of UEs that have granted user consent.

[0075] If the NEF provides 843APP_ID, the UDM 308 also checks the user consent for the indicated application via the UDR 352. The NEF 354 can subscribe to the UDM service to get notifications about changes in user consent. If the user consent is terminated, the NEF 354 can terminate the subscribed analysis exposure or event exposure service provided by other NFs.

[0076] If the number of UEs granted user consent is less than the minimum number of valid UEs associated with the validity criteria in the target UE identifier, the NEF 354 may wait according to the validity time indicated 813 in the AF request until the UDM 308 notifies the NEF 354 of the required number of valid UEs and then continue the analysis.

[0077] The NEF 254 may skip procedures 874 and 876 and send 814 a Nnef_InfoExposureSubscribe response message to the AF 358. The message may indicate the result of exposing the service subscription and, if the number of UEs granted user consent is insufficient, the corresponding reason.

[0078] If the number of UEs granted user consent is equal to or greater than the minimum number of valid UEs, the NEF 354 may maintain a list of UEs granted user consent and apply this list in procedures 874 and 876 .

[0079] If the NEF 354 receives a notification from a subscription service of a NF including the NWDAF 356, AMF 364, UDM 308, SMF 366, or PCF 360, the NEF 354 responds 819 to the AF 358 in a Nnef_InfoExposureNotify message.

[0080] Fig. 9 is a flow diagram for managing user consent information on a per-application basis, such as may be implemented in UDM 308. This technique may be used with the technique discussed above, according to which user consent is associated with an application identifier.

[0081] At block 902, the UDM 308 may receive subscription information including an APP_ID. At block 904, the UDM 308 stores user consent for each application identifier via the UDR 352 as part of the application subscription. In this implementation, the user consent field may indicate whether user consent is granted for a certain application, and in this case the sub-data key is the application identifier (or APP_ID). In addition, the UE's user consent may also be stored in the UDM 308 / UDR 252 as part of the UE subscription based on the application identifier for purposes other than exposing UE data to third parties.

[0082] Fig.10 1 is a flow chart of an example method 1000 for configuring analysis or event monitoring in a mobile communication system, which can be implemented in a NF (such as AF 358 of NEF 354). At block 1002, a first NF sends a request related to an operation requiring user consent to a second NF (see, e.g., events 510, 520, 611, 612, 630, 712, 733, 813, 836). At block 1004, the first NF receives a response including user consent information from the second NF (see, e.g., events 515, 522, 615, 618, 632, 735, 718, 819, 837).

[0083] Fig.11 1 is a flow chart of an example method 1100 for managing analysis or event monitoring that may be implemented in NEF 354 or another suitable NF. At block 1102, the NF subscribes to notifications related to changes in user consent of one or more UEs (see, e.g., event 630). At block 1104, the NF receives notifications of changes in user consent of one or more UEs related to analysis functions (see, e.g., event 632). At block 1106, the NF notifies at least one other NF of the change in user consent (see, e.g., events 615, 616).

[0084] As discussed below, various techniques of the present disclosure relate to message passing between network functions of 5GS (e.g., network functions of CN 110) and between the CN (e.g., CN 110), RAN (e.g., RAN 105) and UE (e.g., 102) of 5GS.

[0085] The following list of examples reflects various embodiments expressly contemplated by the present disclosure:

[0086] Example 1. A method for managing analysis or event monitoring in a mobile communication system, the method being implemented in a first network function (NF) of a core network (CN) and comprising: subscribing to notifications related to changes in user consent of one or more user equipment units (UEs); and in response to receiving a notification that the user consent of the one or more UEs has changed, notifying at least a second network function (NF) to provide a service involving analysis exposure or event exposure, the service being related to the one or more UEs.

[0087] Example 2. The method as described in Example 1 further includes: when the notification indicates termination of the user consent, terminating the service provided by the second NF.

[0088] Example 2. The method of Example 1, further comprising: in response to determining that the number of UEs that have granted user consent is lower than a minimum number associated with a validity criterion for the service, sending a rejection message to the second NF.

[0089] Example 4. The method of Example 3, wherein the rejection message includes a list of UEs to which the user consent is granted.

[0090] Example 5. A method as described in Example 3, wherein the rejection message includes a rejection reason related to the change agreed to by the user.

[0091] Example 6. A method as described in any of the preceding examples, wherein: the first NF is a network open function (NEF); and the subscription includes configuring a unified data management function (UDM) to send the notification to the NEF.

[0092] Example 7. The method as described in any of the preceding examples, further comprising: receiving a request related to the service from the second NF; wherein the subscription is a response to the request from the second NF.

[0093] Example 8. The method of Example 7, wherein the request is a Nnef_AnalyticExposure_Fetch request.

[0094] Example 9. The method of Example 7 or 8, wherein the request indicates that the service requires the user's consent.

[0095] Example 10. The method as described in any one of Examples 7 to 9, further comprising, in response to receiving the request from the second NF: checking the user consent using the UDM; and storing a list of UEs that have granted user consent.

[0096] Example 11. The method of Example 10, wherein the checking is based on a target UE identifier associated with a subscription permanent identifier (SUPI).

[0097] Example 12. A method as described in any of the preceding examples, wherein the second NF is an application function (AF).

[0098] Example 13. A method as described in any of the preceding examples, wherein the notification is associated with an event identifier specifically indicating a change in the user's consent.

[0099] Example 14. A method as described in any of the preceding examples, wherein: the subscription includes indicating an application associated with the service to which the user consents.

[0100] Example 15. A method for configuring analysis or event monitoring in a mobile communication system, the method being implemented in a first network function (NF) of a core network (CN) and comprising: sending a request related to an operation involving analysis and / or event monitoring from the first NF to a second NF, the request indicating that the operation requires user consent; and receiving a response to the request from the second NF, the response including user consent information of one or more user equipment units (UEs).

[0101] Example 16. The method of Example 15, wherein the request associated with the operation includes a field dedicated to conveying a user consent indicator.

[0102] Example 17. A network function (NF) implemented in a core network (CN), the NF comprising processing hardware, the NF being configured to perform a method as described in any of the preceding examples.

[0103] The following description can be applied to the above description.

[0104] The user device (e.g., UE 102) in which the technology of the present disclosure may be implemented may be any suitable device capable of wireless communication, such as a smart phone, a tablet computer, a laptop computer, a mobile game console, a point of sale (POS) terminal, a health monitoring device, a drone, a camera, a media streaming dongle or another personal media device, a wearable device (such as a smart watch), a wireless hotspot, a femtocell, or a broadband router. Further, in some cases, the user device may be embedded in an electronic system such as a head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device may operate as an Internet of Things (IoT) device or a mobile Internet device (MID). Depending on the type, the user device may include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0105] Certain embodiments are described in the present disclosure as including logic or multiple components or modules. A module may be a software module (e.g., code stored on a non-transitory machine-readable medium) or a hardware module. A hardware module is a tangible unit that is capable of performing certain operations and may be configured or arranged in a particular manner. A hardware module may include a dedicated circuit system or logic that is permanently configured (e.g., as a dedicated processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also include programmable logic or circuit systems (e.g., contained within a general-purpose processor or other programmable processor) that are temporarily configured by software to perform certain operations. The decision to implement a hardware module in a dedicated and permanently configured circuit system or in a temporarily configured circuit system (e.g., configured by software) may be driven by cost and time considerations.

[0106] When implemented in software, the techniques may be provided as part of an operating system, a library used by multiple applications, a specific software application, etc. The software may be executed by one or more general-purpose processors or one or more special-purpose processors.

Claims

1. A method for configuring analysis or event monitoring in a mobile communication system, the method being implemented in a first network function (NF) of a core network (CN) and comprising: sending, from the first NF to the second NF, a request related to an operation involving analysis and / or event monitoring, the request indicating that the operation requires user consent; as well as A response to the request is received from the second NF, the response including user consent information of one or more user equipment units (UEs).

2. The method of claim 1, wherein: The first NF is an application function (AF); and The second NF is a network open function (NEF).

3. The method according to claim 1 or 2, further comprising: A group of UEs is selected to perform the operation based on the response.

4. A method as claimed in any one of the preceding claims, wherein the operation involves federated learning.

5. A method as claimed in any one of the preceding claims, wherein: The request associated with the operation is an event notification request including an event identifier corresponding to a program having a mandatory event.

6. A method as claimed in any one of the preceding claims, wherein: The request related to the operation is associated with a procedure for enforcing verification of user consent at the NEF.

7. The method of claim 1, wherein: The first NF is a NEF; and The second NF is a network data analysis function (NWDAF).

8. The method of any one of the preceding claims, wherein the request related to the operation comprises one of: (i) receive a request for analytical information, or (ii) Request to subscribe to analytical information.

9. The method of any one of the preceding claims, wherein the response comprises at least one of: (i) a list of UEs that have granted user consent, or (ii) List of UEs for which user consent has not been granted.

10. The method of claim 1, 2 or 7, further comprising: Subscribing to notifications related to changes in user consent of the one or more UEs.

11. The method of claim 10, wherein: The subscribing includes configuring a unified data management function (UDM) to send the notification to the first NF.

12. The method of claim 10 or 11, wherein: The subscription includes an indication of an application associated with the operation associated with the user consent.

13. The method of any one of claims 10 to 12, further comprising: Receive requests for analytics extraction or subscriptions, wherein said subscribing is in response to said receiving of said request.

14. The method of any one of claims 10 to 12, further comprising: Receive requests for event monitoring extraction or subscription, wherein said subscribing is in response to said receiving of said request.

15. A network function (NF) implemented in a core network (CN), the NF comprising processing hardware, the NF being configured to perform the method as claimed in any one of the preceding claims.

Images