User consent checking for a ue privacy related information exposure

Abstract

A method implemented in a core network (CN) of a wireless communication system includes receiving, from an application function (AF), a request (i) related to an exposure of a CN function (1510), and / or (ii) including a member selection indication; determining, for a user equipment (UE) and based on the request, user consent information (1540); and transmitting, to the AF, a result of the determining (1520).

Description

USER CONSENT CHECKING FOR A UE PRIVACY RELATED INFORMATIONEXPOSURECROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to and the benefit of the filing date of provisional U.S. Patent Application No. 63 / 483,264, titled “User Consent Checking for UE Privacy Related Information Exposure,” filed on February 3, 2023. The entire contents of the provisional application are hereby expressly incorporated herein by reference.FIELD OF THE DISCLOSURE

[0002] This disclosure relates generally to wireless communications and, more particularly, to checking consent settings for information exposure at a core network.BACKGROUND

[0003] This background description is provided for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0004] The 3rd Generation Partnership Project (3GPP) recently has begun studying support for Artificial Intelligence (AI) / Machine Learning (AI / ML) based services. In particular, the 3GPP proposes to enable 5G system (5GS) support for assisting AI / ML-enabled applications such as video / speech recognition, robot control, automotive services, etc. Some of these services require AI / ML model distribution to UEs via a 5G network.

[0005] According to a scheme which can be referred to as 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 model to the UEs joining the federated learning scheme as FL members. The UEs also can upload relatively small updates to the local version of the AI / ML models to the application server, for further integration into the model the application server manages.

[0006] The 3GPP recently considered whether and how a 5GS provides assistance to an AI / ML enabled application, which facilitates an FL operation and model distribution / redistribution (e.g., FL members selection, group performance monitoring, adequate network resources allocation and guarantee) between the application clients running on the UEs and the application servers. The 3GPP also considered what information a 5GC requires to assist an application function (AF) in selecting and managing a group of UEs that participate in an FL operation.

[0007] However, these developments fail to address the issue of user privacy. According to 3GPP ETSI TS 123.288, v. 17.4.0 (2022-05), the network data analytics function (NWDAF) simply excludes the corresponding Subscription Permanent Identifier (SUP I) from the request to collect data and generate analytics or ML model on the other users for which user consent is granted, if the request is for a group of UE or "any UE.” There are currently no mechanisms for assisting an application with user selection for an application server that relies on analytic and / or event information from the 5GC.

[0008] Moreover, there is a lack of solutions for user privacy protection in a 5G network for different deployment scenarios, e.g., when the an AF operates in a trusted domain (internal to the 5G network or outside the trusted domain, i.e., in a non-trusted domain (external to the 5G network).SUMMARY

[0009] An example embodiment of the techniques of this disclosure is a method implemented in a core network (CN) of a wireless communication system. The method comprises receiving, from an application function (AF), a request (i) related to an exposure of a CN function, and / or (ii) including a member selection indication; determining, for a user equipment (UE) and based on the request, user consent information; and transmitting, to the AF, a result of the determining.

[0010] Another example embodiment of these techniques is a component in a core network (CN) of a wireless communication system, comprising processing hardware and configured to implement a method of any of the preceding claims.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Fig. 1 is a block diagram of an example wireless communication system, such as 5GS, that supports PDU set handling in the uplink direction using the techniques of this disclosure;

[0012] Fig. 2 is a block diagram of an example protocol stack according to which the UE of Fig. 1 can communicate with the RAN of Fig. 1;

[0013] Fig. 3 is a service-based representation of the 5GS architecture, including the overall non-roaming reference architecture of the policy and charging control framework for the 5GS;

[0014] Fig. 4 is a reference-point based representation of the 5GS architecture, including overall non-roaming reference architecture of the policy and charging control framework for the 5GS;

[0015] Fig. 5 is a high-level messaging diagram of an example scenario in which a UE uses XRM services using PDU set handling;

[0016] Fig. 6 is a messaging diagram of an example scenario in which an Application Function (AF) operating in a non-trusted domain requests event exposure via a Network Exposure Function (NEF) and includes a member selection indication in the request;

[0017] Fig. 7 is a messaging diagram of an example scenario in which an AF operating in a non-trusted domain requests analytics information exposure via an NEF and includes a member selection indication in the request;

[0018] Fig. 8 is a messaging diagram of an example scenario in which an AF, operating in a trusted or non-trusted domain, requests member selection assistance exposure via an NEF;

[0019] Fig. 9 is a messaging diagram of an example scenario in which an AF operating in a trusted domain requests event exposure directly from a Unified Data Management (UDM) or a Policy Control Function (PCF);

[0020] Fig. 10 is a messaging diagram of an example scenario in which an AF operating in a trusted domain requests analytics information exposure directly from a Network Data Analytics Function (NWDAF) and includes a member selection indication in the request;

[0021] Fig. 11 is a messaging diagram of an example scenario in which an AF operating in a non-trusted domain requests event exposure via an NEF, and in which the core network (CN)uses a purpose indicator corresponding to event exposure to manage user consent information in a database;

[0022] Fig. 12 is a messaging diagram of an example scenario in which an AF operating in a trusted domain requests event exposure directly from an UDM or PCF, and in which the CN uses a purpose indicator corresponding to event exposure to manage user consent information in a database;

[0023] Fig. 13 is a messaging diagram of an example scenario in which an AF operating in a non-trusted domain requests analytics information exposure via an NEF, and in which the CN uses a purpose indicator corresponding to analytics information exposure to manage user consent information in a database;

[0024] Fig. 14 is a messaging diagram of an example scenario in which an AF operating in a trusted domain requests analytics information exposure directly from an NWDAF, and in which the CN uses a purpose indicator corresponding to analytics information exposure to manage user consent information in a database; and

[0025] Fig. 15 is a flow diagram of an example method for user consent checking, which can be implemented in one or more network functions of a core network.DETAILED DESCRIPTION OF THE DRAWINGS

[0026] The techniques discussed below address the need for user privacy protection when a core network (CN) of a 5G system (5GS) processes a request for exposing information related to UE privacy. The relevant request can be for UE member selection assistance or general information exposure. One or more network functions operating in the CN can process such requests based on the subscription data for a UE and, at least in some cases, in view of local policy or regulation requirements. The techniques enhance user privacy protection for different deployment scenarios such as an application function (AF), which originates a request for information related to UE privacy for an application provider, operating within a trusted domain or outside the trusted domain.

[0027] As discussed in more detail below, some of the techniques include associating user consent in UE subscription data with member selection assistance. Currently, an operator bindsuser consent, which is subscription information stored in a Unified Data Management (UDM), to a purpose such as analytics or ML model training. In particular, this information includes an indication of whether the user authorizes collection and usage of data for a particular purpose, and whether the purpose of data collection is analytics or model training. A CN of this disclosure additionally uses the purpose of member selection assistance. In one example scenario, an AF requests event exposure via an NEF and includes a member selection indication in the request. In another example scenario, an AF requests analytics exposure via an NEF and includes a member selection indication in the request. In yet another example scenario, an AF sends, a request for a service operation to an NEF, where the service operation is member select assistance exposure.

[0028] In some implementations, an AF operating in a trusted domain requests event exposure directly from an UDM or PCF, and the UDM uses member selection assistance as a purpose, and uses the event identifier (ID) as a data sub-key to retrieve the relevant subscription data. In another scenario, the AF operating in a trusted domain requests analytics exposure directly from the NWDAF, and the UDM uses member selection assistance as a purpose, and uses the analytics identifier as a sub-key to retrieve the relevant subscription data.

[0029] In some implementations, a CN does not rely on a member selection indication. The subscription data for user consent stores event exposure as a purpose, and the event identifier operates as a data sub-key. In one scenario, an AF requests event exposure via an NEF. In another scenario, an AF operating a trusted domain requests event exposure directly from an UDM or PCF.

[0030] In some implementations, a CN uses the purpose of analytic exposure or extended analytics to retrieve user consent information, or uses a subscription type of extended user consent (distinct from user consent) with an analytics identifier operating as a data sub-key. In one such scenario, an AF requests analytics exposure via an AF and indicates the purpose of analytics exposure. In another scenario, an AF operates in a trusted domain and requests analytics exposure directly from an NWDAF.Example system and protocol stack

[0031] Referring first to Fig. 1, an example wireless communication system 100 can implement one or more of the techniques of this disclosure for supporting user handling of traffic, particularly the uplink traffic from a UE. 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 can operate in a RAN 105 connected to the CN 110. The CN 110 can also be implemented as a sixth generation (6G) core or another suitable core network.

[0032] The base station 104 covers a cell 124, and the base station 106 covers a cell 126. If the base station 104 is a gNB, the cell 124 is an NR cell. If the base station 124 is an ng-eNB, the cell 124 is an evolved universal terrestrial radio access (E-UTRA) cell. Similarly, if the base station 106 is a gNB, the cell 126 is an NR cell, and if the base station 126 is an ng-eNB, the cell 126 is an E-UTRA cell. The cells 124 and 126 can be in the same Radio Access Network Notification Areas (RNA) or different RNAs. The cells 124 and 126 can partially overlap, so that the UE 102A or 102B can select, reselect or hands over from one of the cells 124 and 126 to the other. In general, the RAN 105 can include any number of base stations, and each of the base stations can cover one, two, three, or any other suitable number of cells. The UE 102 can support at least a 5GNR (or simply, “NR”) air interface to communicate with the base stations 104 and 106. Each of the base stations 104, 106 can connect to the CN 110 via an interface (e.g., SI or NG interface). The base stations 104 and 106 also can be interconnected via an interface (e.g., X2 or Xn interface) for interconnecting NG RAN nodes.

[0033] Several NFs that make up the CN 110 are discussed below with reference to Figs. 3 and 4. One or more of the NFs of the CN 110 implement the user consent checking techniques discussed below, for the UE 102A and / or the UE 102B.

[0034] While not shown in Fig. 1 to avoid clutter, the CN 110 may include processing hardware, which may include one or more general -purpose processors (e.g., CPUs) and a non- transitory computer-readable memory storing instructions that the one or more general-purpose processors execute. Additionally or alternatively, the processing hardware can include specialpurpose processing units. The processing hardware may be configured to implement the techniques of this disclosure for enabling 5GS support of advanced media services.

[0035] The base station 104 is equipped with processing hardware that can include one or more general -purpose processors (e g., CPUs) and a non-transitory computer-readable memory storing instructions that the one or more general-purpose processors execute (not shown). Additionally or alternatively, the processing hardware can include special-purpose processing units.

[0036] The UE 102A is equipped with processing hardware 130A that can include one or more general-purpose processors such as CPUs and non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and / or special -purpose processing units. The UE 102A also includes a transceiver 132A to communicate with the RAN 105 over a radio interface. Further, the UE 102A includes a memory 134A storing a PDU controller 140A. The UE 102B can have a similar implementation. Further, the UE 102A also can execute various applications (not shown) to which the PDU controller 140A provides downlink data, and from which the PDU set controller 140 A efficiently receives, and forwards to the CN 110 via the RAN 105, uplink data.

[0037] The CN 110 can connect to various services, including data servers (now shown) that transmit PDUs to the UEs 102A and 102B, and receive PDUs from the UEs 102A and 102B, as well as a 3rd party application 150 that can request information related specifically to the UE 102A and 102B, or a group of UEs including the UE 102A and 102B, which is subject to privacy control. The CN 110 implements one or more user privacy protection techniques discussed in more detail below to determine whether to provide the requested information to the 3rd party application 150. Further, requests for information related to UE privacy in some cases originate within the CN 110, i.e., from an AF operating in the CN 110.

[0038] Fig. 2 illustrates, in a simplified manner, an example protocol stack 200 according to which the UE 102A or 102B can communicate with an eNB / ng-eNB 230 or a gNB 232 (e.g., one or more of the base stations 104, 106). In the example stack 200, a physical layer (PHY) 202A of EUTRA provides transport channels to the EUTRA MAC sublayer 204 A, which in turn provides logical channels to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A in turn provides RLC channels to a EUTRA PDCP sublayer 208 and, in some cases, to an NR PDCP sublayer 210. Similarly, the NR PHY 202B provides transport channels to the NR MAC sublayer 204B, which in turn provides logical channels to the NR RLC sublayer 206B. The NRRLC sublayer 206B in turn provides data transfer services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 in turn can provide data transfer services to Service Data Adaptation Protocol (SDAP) 212 or a radio resource control (RRC) sublayer (not shown in Fig. 2). The UE 102A or 102B, in some implementations, supports both the EUTRA and the NR stack as shown in Fig. 2, to support handover between EUTRA and NR base stations and / or to support DC over EUTRA and NR interfaces. Further, as illustrated in Fig. 2, the UE 102A or 102B can support layering of NR PDCP 210 over EUTRA RLC 206 A, and SDAP sublayer 212 over the NR PDCP sublayer 210.

[0039] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets (e.g., from an Internet Protocol (IP) layer, layered directly or indirectly over the PDCP layer 208 or 210) that can be referred to as service data units (SDUs), and output packets (e.g., to the RLC layer 206A or 206B) that can be referred to as protocol data units (PDUs). Except where the difference between SDUs and PDUs is relevant, this disclosure for simplicity refers to both SDUs and PDUs as “packets.”

[0040] On a control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide signaling radio bearers (SRBs) or RRC sublayer (not shown in Fig. 2) to exchange RRC messages or non-access-stratum (NAS) messages, for example. On a user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide data radio bearers (DRBs) to support data exchange. Data exchanged on the NR PDCP sublayer 210 can be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.Example network architecture

[0041] Fig. 3 is a service-based representation 300 of an example CN architecture, which the system of Fig. 1 can implement. In the representation 300, the overall non-roaming reference architecture of the policy and charging control (PCC) framework for the 5GS includes components illustrated using solid lines, and the other components are illustrated using dashed lines. According to this representation, network functions enable other authorized network functions to access their services. The components that are outside the PCC framework include a Network Slicing 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 Proxy (SCP) 316, and a Network Slice Admission Control Function (NSACF) 318. The non-PCC architecture further includes the UE 102, the RAN 105, and a data network (DN) 330.

[0042] The PCC framework in the architecture 300 includes a Unified Data Repository (UDR) 352, a Network Exposure Function (NEF) 354, a network data analytics function (NWDAF) 356, an Application Function (AF) 358, a Policy Control Function (PCF) 360, a Charging Function (CHF) 362, an Access & Mobility Management Function (AMF) 364, a Session Management Function (SMF) 366, and a User Plane Function (UPF) 370.

[0043] The AF 358 in some deployment operates in a trusted domain 311 or outside the trusted domain 311, i.e., in a non-trusted domain. The trusted domain 311 is generally internal to the CN 110 and includes such components as the UDM 308, the UDR 352, the PCF 360, the AMF 364, the SMF 366, and the UPF 370. Generally speaking, an AF operating outside the trusted domain 311 can access the network functions of the CN 110 only via the NEF 354, whereas an AF operating within the trusted domain 311 can access at least some of the network functions of the CN 110 directly, or may access these functions via the NEF 354 in some deployments.

[0044] Fig. 4 is a reference-point based representation 400 of the 5GS architecture. In Fig. 4, the non-roaming reference architecture of the PCC framework for the 5GS is illustrated as blocks and connections with solid lines, and components and connections outside the PCC framework are illustrated using dashed lines.

[0045] For clarity, Fig. 5 illustrates a high-level scenario in which the UE 102A or 102B obtains data services. During the registration procedure, the AMF determines 510 whether the UE 102 is authorized to use the data services based on the service capability of the UE and the service authorization included in the subscription data received from the UDM 308 (e.g., as specified in TS 23.501 clause 5.7). After successful registration, the UE 102A or 102B performs 520 a PDU Session Establishment procedure (e.g., as described in TS23.502 clause 4.3.2.2). The UE 102A or 102B or the network can initiate 530 a PDU Session Modification Procedure for the existing PDU Session (e.g., as described in TS23.502 clauses 4.3.3.2 and 4.3.3.3). The UE 102A or 102B may repeat procedure 530 for multiple PDU Sessions that are associated with the same or different DNN and S-NSSAI.

[0046] Several example techniques for checking user consent in connection with information exposure are discussed next. Generally speaking, events in Figs. 6-14 that are similar are labeled with similar reference numbers (c.g., event 628 of Fig. 6 is similar to event 728 of Fig. 7, and event 730 of Fig. 7 is similar to event 830 of Fig. 8), with differences discussed below where appropriate. With the exception of the differences shown in the figures and discussed below, any of the alternative implementations discussed with respect to a particular event (e g., for messaging and processing) may apply to events labeled with similar reference numbers in other figures.Example user consent checking techniques

[0047] Referring first to Figs. 6-8, the NEF 354 in these implementations recognizes a request from the AF 358 that indicates member selection assistance. Generally speaking, similar events in Figs. 6-8 are labeled with the similar reference numbers (e g., event 628 in Fig. 6 is similar to event 728 in Fig. 7, and event 690 in Fig. 6 is similar to event 790 in Fig. 7 and event 890 in Fig. 8), with differences discussed below where appropriate. With the exception of the differences shown in the figures and discussed below, any of the alternative implementations discussed with respect to a particular event (e.g., for messaging and processing) may apply to events labeled with similar reference numbers in other figures and also to both integrated and distributed base stations.

[0048] Referring to Table 1 below, the subscription data type “user consent” corresponds to a particular purpose in the UDM 308. In addition to the purposes of analytics and ML model generation, the CN 110 supports the purpose of “member selection assistance.” Thus, the purpose field in the data record of Table 1 can include a value selected from the set of {analytics, ML model generation, member selection assistance}.Subscription Data T ata Ke ata Sub-KUser ConsentSUPIPurposeTable 1

[0049] The CN 110 use the SUPI as the data key and the purpose as the data sub-key to identify subscription data for the privacy-related information, for the UE. In various scenarios, the purpose of member selection assistance corresponds to event exposure, analytics exposure, ormember selection assistance exposure (which can be a type of exposure discussed with reference to Fig. 8).

[0050] In one implementation, the CN 110 uses the purpose of “analytics,” generally associated with data collection in a 5GC, with a request for analytics exposure, to expose information related to UE privacy to the AF 358. In another implementation, the CN 110 uses the purpose of “analytics exposure” rather than the purpose “analytics” to differentiate a request for exposure of information related to UE privacy from use internal to the CN 110.

[0051] According to another approach illustrated in Table 2 below, the subscription data type “extended user consent” is a subscription data type defined specifically for identifying, for information exposure that requires user consent, information related to UE privacy. The CN 110 provides exposure of such information using SUPI as the data key and an event identifier (ID) or analytics identifier (ID) as the data sub-key.S. Table

[0052] The event IDs which the CN 110 can use to retrieve extended user consent information according to Table 2 can correspond to, for example, UE reachability for UE reachability state based on AMF detection, Loss of Connectivity for UE connectivity state based on AMF detection, Roaming Status based on UDM detection, or Location Reporting for UE Tracking Area Identifier (TAI) Location information based on AMF / GMLC detection.

[0053] The analytics identifier which the CN 110 can use to retrieve extended user consent information according to Table 2 can correspond to, for example, UE mobility analytics, UE communication analytics, expected-UE-behavioral-parameters-related network data analytics, or abnormal-behavior-related network data analytics.

[0054] In a scenario 600 of Fig. 6, the UDM 308 receives a request for subscription data related to user consent from the NEF 354, which is configured to perform user consent checking with the UDM 308 based on (i) local policy and regulation requirements for event exposure and(ii) member selection indication included in the request from the AF 358 operating in an untrusted domain.

[0055] To support event exposure for the purpose of member selection assistance from the 5GC, the NEF 354 can implement at least the following functionality: (i) determine whether to perform user consent checking with the UDM 308 for UE-related privacy information exposure, and (ii) provide a list of recommended UEs to the AF 358 based on UE member filtering criteria and user consent results, if required by the local policy or regulation.

[0056] In particular, at the beginning of the scenario 600, the NEF 354 controls 601 event exposure. The AF 358, operating outside the trusted domain of the CN 110, requests 610 event exposure via the NEF 354. The NneJ ' EventExposure Subscribe / Unsubscribe request message can include one or more of the following information: (i) a (first) set or list of one or more target UE IDs identifying respective one more candidate UEs for UE member selection, (ii) a first set of one or more event IDs, (iii) a member selection indication, (iv) UE member filtering criteria, or (v) validity criteria.

[0057] In response to receiving 610 the request for event exposure, the NEF 354 determines 628 whether to perform user consent checking. In some implementations, when the NEF 354 receives a request for event exposure that does not include a member selection indication or UE member filtering criteria, the NEF 354 applies the legacy processing for event exposure.Further, in some cases, the NEF 354 applies the legacy processing for event exposure when there is no local policy or regulation requirements for user consent checking.

[0058] The NEF 354 checks 628 the local policy and regulation requirements and performs 630, 632 user consent checking via the UDM 308. The NEF 354 can transmits 630 aNudm SDM Get message to the UDM 308 and include one or more of the following information in the message: (i) the first set of one or more target UE IDs (received 610 from the AF 358), (ii) an indication that the purpose of the user consent checking is member selection, or (iii) a second set of one or more event IDs.

[0059] When the NEF 354 is configured locally with a third set of event IDs related to UE privacy, the NEF 354 can select a second set of event IDs from the first set of event IDs, such that the event IDs in the second set are related to UE privacy and require user consent checking.The NEF 354 includes only the second set of event IDs in the request transmitted 630 to the UDM 308. However, when the NEF 354 is configured to perform user consent checking without checking which event IDs are related to UE privacy, the NEF 354 can simply transmit 630 the first set of event IDs, if received 610 from the AF 358.

[0060] With continued reference to Fig. 6, the UDM 308 can check 640 the subscription data type of user consent based on the SUPI, the purpose of the data set to “member selection,” and the third set of event ID(s). When the NEF 354 does not indicate 630 the second set of event IDs, the UDM 308 can check the user consent for purpose of member selection using the SUPI as a master key, as illustrated in Table 1 above for example. When the NEF 354 indicates 630 the second set of event IDs, the UDM 308 can check the user consent for the purpose of member selection using the SUPI as a master key, and the event ID(s) as the data sub-key(s), as illustrated in Table 2 for example.

[0061] The UDM 308 can determine 640 a fourth set of event IDs for which user consent is granted. The UDM 308 then responds 632 to the NEF 354 with Nudm SDM Reply message, to indicate the results of the user consent checking 640. The Nudm SDM Reply message can include a second list or set of UE IDs, in accordance with the fourth set of event IDs, for which user consent is granted.

[0062] Next, using the information received 632 from the UDM 308, the NEF 354 can authorize the request (see event 610) from the AF 358, for data exposure related to the fourth set of event IDs. In particular, when the second list of UE IDs received 632 from the UDM 308 includes no UE IDs for the fourth set of event IDs, the NEF 354 can respond 611 A to the AF 358, without performing 650, 652 an event exposure procedure for the corresponding event ID(s).

[0063] Otherwise, for each event ID within the fourth set of event IDs, the NEF 354 transmits 650, to one or more network functions such as the PCF 360, the AMF 364, the SMF 366, or the UPF 370, an Nnj ’ EventExposure Subsen be Unsubscribe message including information for a related event exposure service operation. This information can include one or more of: (i) an event ID for which there is a granted user consent, (ii) the second list of UE IDs, (iii) the member selection indication, (iv) the UE member fdtering criteria, or (v) user consent checked indication, so as to notify the NF(s) that user consent is granted for the target UEs.

[0064] For roaming scenarios in which a certain serving NF may have requirements different from those of the NEF 354 or the Home UDM 308, the NF needs to check whether the NEF 354 included 650 user consent checked indication is included, before responding 652 with event results to the NEF 354.

[0065] When there is no user consent checked indication, and when user consent is required based on the local policy or regulation, the NF 360, 364, 366, 370, etc. rejects (not shown) the event exposure request of the event 650 with a proper cause of rejection, e.g. lack of user consent. Otherwise, when the user consent checked indication is present, and when user consent is required based on the local policy or regulation, the NF 360, 364, 366, 370, etc. implements the corresponding event exposure procedure.

[0066] The NF 360, 364, 366, 370, etc. transmits 652 an Nnf EventExposure Notify message that can include, when the member selection indication is included in theNnf EventExposure Subscribe Unsubscribe message, (i) an event ID, and (ii) one or more recommended UE ID(s). The NEF 354 then responds 61 IB to the AF 358 with (i) the event ID, and (ii) the one or more recommended UE ID(s), if the NEF 354 included 650 the member selection indication in the Nnf EventExposure Subscribe / Unsubscribe message. The response the NEF 354 transmits 61 IB can be an Nnef EventExposure Subscribe Unsubscribe Response message or Nnef EventExposure Notify message.

[0067] After receiving 611A a response including recommended UE ID(s), the AF 358 determines 690 UEs for the corresponding application operation.

[0068] Now referring to Fig. 7, a scenario 700 is generally similar to the scenario 600 discussed above. Here, however, the NEF 354 processes a request for analytics exposure rather than event exposure. The UDM 308 receives a request for subscription data related to user consent from the NEF 354, which is configured to perform user consent checking with the UDM 308 based on (i) local policy and regulation requirements for analytics exposure and (ii) member selection indication included in the request from the AF 358 operating in an untrusted domain. Similar to the support of event exposure discussed above, to support analytics exposure for the purpose of member selection assistance from the 5GC, the NEF 354 can implement at least the following functionality: (i) determine whether to perform user consent checking with the UDM 308 for UE-related privacy information exposure, and (ii) provide a list of recommended UEs tothe AF 358 based on UE member filtering criteria and user consent results, if required by the local policy or regulation.

[0069] In particular, the NEF 354 controls 702 analytics exposure. The AF 358, operating outside the trusted domain of the CN 110, requests 712 analytics exposure via the NEF 354. The Nnef AnalyticsExposure Subscribe / Unsubscribe request message can include one or more of the following information: (i) a (first) set or list of one or more target UE IDs identifying respective one more candidate UEs for UE member selection, (ii) a first set of one or more analytics IDs, (iii) a member selection indication, (iv) UE member filtering criteria, or (v) validity criteria.

[0070] In response to receiving 712 the request for analytics exposure, the NEF 354 determines 728 whether to perform user consent checking.

[0071] The NEF 354 checks 728 the local policy and regulation requirements and performs 730, 732 user consent checking via the UDM 308. The NEF 354 can transmit 730 a Nudm SDM Get message to the UDM 308 and include one or more of the following information in the message: (i) the first set of one or more target UE IDs (received 610 from the AF 358), (ii) an indication that the purpose of the user consent checking is member selection, or (iii) a second set of one or more analytics IDs.

[0072] When the NEF 354 is configured locally with a third set of analytics IDs related to UE privacy, the NEF 354 can select a second set of analytics IDs from the first set of event IDs, such that the analytics IDs in the second set are related to UE privacy and require user consent checking. The NEF 354 includes only the second set of analytics IDs in the request transmitted 730 to the UDM 308. However, when the NEF 354 is configured to perform user consent checking without checking which analytics IDs are related to UE privacy, the NEF 354 can simply transmit 730 the first set of analytics IDs, if received 712 from the AF 358.

[0073] The UDM 308 can check 741 the subscription data type of user consent based on the SUP1, the purpose of the data set to “member selection,” and the third set of analytics ID(s).

[0074] When the NEF 354 does not indicate 730 the second set of analytics IDs, the UDM 308 can check the user consent for purpose of member selection using the SUPI as a master key, as illustrated in Table 1 above for example. When the NEF 354 indicates 730 the second set of event IDs, the UDM 308 can check the user consent for the purpose of member selection usingthe SUPI as a master key, and the analytics ID(s) as the data sub-key(s), as illustrated in Table 2 for example.

[0075] The UDM 308 can determine 741 a fourth set of analytics IDs for which user consent is granted. The UDM 308 then responds 732 to the NEF 354 with Nudm SDM Reply message, to indicate the results of the user consent checking 741. The Nudm SDM Reply message can include a second list or set of UE IDs, in accordance with the fourth set of analytics IDs, for which user consent is granted.

[0076] Next, using the information received 732 from the UDM 308, the NEF 354 can authorize the request (see event 712) from the AE 358, for data exposure related to the fourth set of analytics IDs. In particular, when the second list of UE IDs received 732 from the UDM 308 includes no UE IDs for the fourth set of analytics IDs, the NEF 354 can respond 713A to the AF 358, without performing 760, 762 an analytics exposure procedure for the corresponding analytics ID(s).

[0077] Otherwise, for each analytics ID within the fourth set of analytics IDs, the NEF 354 transmits 760, to the NWDAF 356, an Nnwdctf ’ Analyticsinfo Request message including information for a related analytics service operation. This information can include one or more of: (i) an analytics ID for which there is a granted user consent, (ii) the second list of UE IDs, (iii) the member selection indication, (iv) the UE member filtering criteria, or (v) user consent checked indication, so as to notify the NWDAF 356 that user consent is granted for the target UEs.

[0078] With continued reference to Fig. 7, the NWDAF 356 performs 770 event exposure subscription with one or more network functions such as the PCF 360, the AMF 364, the SMF 366, or the UPF 370. More specifically, for each analytics ID within the fourth set of analytics IDs, the NWDAF 356 requests 770 event exposure only for the UEs with a granted user consent of analytics for data collection and / or analytics. The NWDAF 356 can provide 770 one or more of: (i) an event ID for which there is a granted user consent, which can be an event ID within the fourth set of event IDs, (ii) the second list of UE IDs, (iii) the UE member filtering criteria if the NEF 354 included the member selection indication in theNnef AnalyticsExposure Subscribe / Unsubscribe request message, or (iv) user consent checked indication, so as to notify the NF(s) that user consent is granted for the target UEs.

[0079] For roaming scenarios in which a certain serving NF may have requirements different from those of the NEF 354 or the Home UDM 308, the NF needs to check whether the NEF 354 included 760 the user consent checked indication, before providing 770 event results to the NWDAF 356.

[0080] When there is no user consent checked indication, and when user consent is required based on the local policy or regulation, the NF 360, 364, 366, 370, etc. rejects the event exposure request during the procedure 770 with a proper cause of rejection, e g. lack of user consent. Otherwise, when the user consent checked indication is present, and when user consent is required based on the local policy or regulation, the NF 360, 364, 366, 370, etc. implements the corresponding event exposure procedure.

[0081] The NWDAF 356 transmits 762 an Nnw daf ' Analyticsinfo Response message that can include (i) an analytics ID, and (ii) one or more recommended UE ID(s). The NEF 354 then responds 713B to the AF 358 with (i) the analytics ID, and (ii) the one or more recommended UE ID(s). After receiving 713B a response including recommended UE ID(s), the AF 358 determines 790 UEs for the corresponding application operation.

[0082] Now referring to Fig. 8, the AF 358 in a scenario 800 can operate in a trusted domain or outside the trusted domain. Unlike the scenario 600, where the NEF 354 performs user consent checking based (in part) on local policy and regulation requirements for event exposure, or the scenario 700, where the NEF 354 performs user consent checking based (in part) on local policy and regulation requirements for analytics exposure, here the NEF 354 is configured to perform user consent checking with the UDM 308 based on local policy and regulation requirements for member selection assistance exposure.

[0083] According to the implementation of Fig. 8, when the AF 358 operates in an untrusted domain and requests a service operation for member selection assistance exposure via the NEF 354, the NEF 354 performs user consent checking if the request is for member selection assistance referencing an event ID or analytics ID that is locally configured as related to UE privacy.

[0084] To support member selection assistance exposure for the purpose of member selection assistance from the 5GC, the NEF 354 can implement at least the following functionality: (i)determine whether to perform user consent checking with the UDM 308 for UE-related privacy information exposure, and (ii) provide a list of recommended UEs to the AF 358 based on UE member filtering criteria and user consent results, if required by the local policy or regulation.

[0085] At the beginning of a scenario 800, the NEF 354 controls 803 event exposure and analytics exposure. The AF 358, operating inside or outside the trusted domain of the CN 110, requests 814 member selection assistance exposure via the NEF 354. TheNnef MemberSelectAssistance Subscribe / Unsubscribe message can include one or more of the following information: (i) a (first) set or list of one or more target UE IDs identifying respective one more candidate UEs for UE member selection, (ii) a first set of one or more event IDs and the respective UE member filtering criteria for these event IDs, (iii) a first set of one or more analytics IDs and the respective UE member filtering criteria for these analytics IDs, or (iv) validity criteria.

[0086] If the AF 358 does not provide 814 the first set of event IDs or the first set of analytics ID(s), and indicates only the UE member filtering criteria, the NEF 354 can determine the first set of event IDs and / or the first set of analytics ID(s)based on the UE member filtering criteria.

[0087] The NEF 354 checks 829 the local policy and regulation requirements and performs 830, 832 user consent checking via the UDM 308. The NEF 354 can transmit 830 aNudm SDM Get message to the UDM 308 and include one or more of the following information in the message: (i) the first set of one or more target UE IDs (received 610 from the AF 358), (ii) an indication that the purpose of the user consent checking is member selection, or (iii) a second set of one or more event IDs, or (iv) a second set of one or more analytics IDs.

[0088] When the NEF 354 is configured locally with a third set of event IDs related to UE privacy, the NEF 354 can select a second set of event IDs from the first set of event IDs, such that the event IDs in the second set are related to UE privacy and require user consent checking. The NEF 354 includes only the second set of event IDs in the request transmitted 830 to the UDM 308. However, when the NEF 354 is configured to perform user consent checking without checking which event IDs are related to UE privacy, the NEF 354 can simply transmit 830 the first set of event IDs, if received 814 from the AF 358.

[0089] The UDM 308 can check 842 the subscription data type of user consent based on the SUPI, the purpose of the data set to “member selection,” and the third set of event ID(s) or the third set of analytics ID(s). More particularly, when the AF 358 includes 814 event ID(s) in the member selection assistance exposure, the operation 842 is similar to the operation 640 discussed in connection with Fig. 6 (for event exposure); when the AF 358 includes 814 analytics ID(s) in the member selection assistance exposure (for analytics exposure), the operation 842 is similar to the operation 741 discussed in connection with Fig. 7.

[0090] The UDM 308 can determine 842 a fourth set of event IDs for which user consent is granted, and / or a fourth set of analytics IDs for which user consent is granted.

[0091] When the AF 358 includes 814 event ID(s), the events 815A and 815B are generally similar to the events 611A and 61 IB of Fig. 6, respectively, and events 850, 852 are implemented similar to the events 650, 652 of Fig. 6. When the AF 358 includes 814 analytics ID(s), the events 815A and 815B are generally similar to the events 713 A and 713B of Fig. 6, respectively, events 860, 862 are implemented similar to the events 760, 762 of Fig. 7, and event 870 is similar to the event 770 of Fig. 7. However, the NEF 354 in some implementations does not include 815B an event ID or the analytics ID in the Nnef j temberSelectAssistance response message.

[0092] In any case, using the information received 832 from the UDM 308, the NEF 354 can authorize the request (see event 814) from the AF 358, for data exposure related to the fourth set of event ID(s) or analytics ID(s). When the second list of UE IDs received 832 from the UDM 308 includes no UE ID(s) for the fourth set of event IDs or analytics IDs, the NEF 354 can respond 815A to the AF 358, without performing 650, 652 an event exposure procedure for the corresponding event ID(s) or performing 860, 862 the analytics information request procedure for the corresponding analytics ID(s). After receiving 815B a response including recommended UE ID(s), the AF 358 determines 890 UEs for the corresponding application operation.

[0093] Referring next to Figs. 9 and 10, the AF 358 in these scenarios operates within the trusted domain, and accordingly can access certain NFs in the CN 110 directly. In these implementations, the UDM 308 also can support the purpose of “member selection assistance” (see Table 1 above for example).

[0094] In some of these implementations, the UDM 308 receives a request for subscription data of data type “user consent” from the AF 358 or the PCF 360. The AF 358 operating in the trusted domain can indicate member selection assistance in a request to the PCF 360 for event exposure, and the PCF 360 can perform user consent checking with the UDM 308 based on the local policy and regulation requirements for member selection assistance.

[0095] When the event exposure is for the purpose of member selection assistance from the 5GC, the AF 358 request includes an member selection assistance indication. An NF such as the PCF 360 for example can provide the following functionality to support the member selection assistance indication: (i) determine whether to perform user consent checking with the UDM 308 for UE-related privacy information exposure, and (ii) provide a list of recommended UEs to the AF 358.

[0096] In a scenario 900 illustrated in Fig. 9, the UDM 308 and / or the UDR 352 control 904 event exposure mapping, and the PCF 360 controls 905 event exposure mapping. The AF 358 requests 916 event exposure via the UDM 308 and / or requests 917 event exposure via the PCF 316. The request to the UD 308 can be an Nudm EventExposure Subscribe Unsubscribe request message, and the request to the PCF 360 can beNpcf Event Exposure Subscribe / Unsubscribe request message. The request can include one or more of the following information: (i) a (first) set or list of one or more target UE IDs identifying respective one more candidate UEs for UE member selection, (ii) a first set of one or more event IDs, (iii) a member selection indication, (iv) UE member filtering criteria, or (v) validity criteria.

[0097] When the AF 358 transmits 917 the Npcf EventExposure Subscribe Unsubscribe request message in the trusted domain, the PCF 360 determines 929 whether to perform user consent checking in view of the member selection indication and based on local policy and regulation requirements. The PCF 360 performs 930, 932 user consent checking via the UDM 308. The Nudm SDM Get message to the UDM 308 can include one or more of the following information in the message: (i) the first set of one or more target UE IDs (received 917 from the AF 358), (ii) an indication that the purpose of the user consent checking is member selection, or (iii) a second set of one or more event IDs.

[0098] When the PCF 360 is configured locally with a third set of event IDs related to UE privacy, the PCF 360 can select a second set of event IDs from the first set of event IDs, suchthat the event IDs in the second set are related to UE privacy and require user consent checking. The PCF 360 includes only the second set of event IDs in the request transmitted 930 to the UDM 308. However, when the PCF 360 is configured to perform user consent checking without checking which event IDs are related to UE privacy, the PCF 360 can simply transmit 930 the first set of event IDs, if received 917 from the AF 358.

[0099] When the AF 358 transmits 916 the Nudm EventExposure Subscribe / Unsubscribe request message in the trusted domain, and when the UDM 308 is configured locally with a third set of event IDs related to UE privacy, the UDM 308 can select a second set of event IDs from the first set of event IDs, such that the event IDs in the second set are related to UE privacy and require user consent checking. When the UDM 308 is configured to perform user consent checking without checking which analytics IDs are related to UE privacy, the UDM 308 can consider the second set of event IDs and the first set of event IDs to be the same (i.e., the first and the second sets of events IDs are identical in this case).

[0100] Similar to the event 640 discussed with reference to Fig. 6, the UDM 308 can check 940 the subscription data type of user consent based on the SUPI, the purpose of the data set to “member selection,” and the third set of event ID(s). When the PCF 360 does not indicate 917 the second set of event IDs, and when the UDM 308 does not have a local configuration of the second set of event IDs, the UDM 308 can check the user consent for purpose of member selection using the SUPI as a master key. When the PCF 360 indicates 917 the second set of event IDs, or when the UDM 308 has a local configuration of the second set of event IDs, the UDM 308 can check the user consent for the purpose of member selection using the SUPI as a master key, and the event ID(s) as the data sub-key(s). The UDM 308 can determine 940 a fourth set of event IDs for which user consent is granted.

[0101] The UDM 308 can transmit 932 the results of user consent checking to the PCF 360, which can include a second of UE IDs for which event IDs in the fourth set of event IDs have granted user consent. Based on the receiving 932 of the results, the PCF 360 can authorize the request from the AF 358.

[0102] When the second list of UE IDs includes no UE IDs for the fourth set of event IDs, the UDM 308 can respond 918A and / or the PCF 360 can respond 919A to the AF 358, without performing 953, 954, 955, 957 an event exposure procedure for the corresponding event ID(s).

[0103] Otherwise, for each event ID within the fourth set of event IDs, the UDM 308 or the PCF 360 transmits 953, 955 respectively, to one or more network functions such as the PCF 360, the AMF 364, the SMF 366, or the UPF 370, m Nnf EventExposure Subscribe Unsubscribe message including information for a related event exposure service operation. This information can include one or more of: (i) an event ID for which there is a granted user consent, (ii) the second list of UE IDs, (iii) the member selection indication, (iv) the UE member filtering criteria, or (v) user consent checked indication, so as to notify the NF(s) that user consent is granted for the target UEs.

[0104] For roaming scenarios in which a certain serving NF may have requirements different from those of the NEF 354 or the Home UDM 308, the NF needs to check whether it received 953, 955 the user consent checked indication, before responding 954, 957 with event results to the UDM 308, PCF 360, respectively. When there is no user consent checked indication, and when user consent is required based on the local policy or regulation, the NF 364, 366, 370, etc. rejects (not shown) the event exposure request of the event 953 or 955 with a proper cause of rejection, e g. lack of user consent. Otherwise, when the user consent checked indication is present, and when user consent is required based on the local policy or regulation, the NF 364, 366, 370, etc. implements the corresponding event exposure procedure.

[0105] The NF 364, 366, 370, etc. transmits 955, 957 an Nnf EventExposure Notify message to the UDM 308, the PCF 360, respectively. The message can include, when the member selection indication is included in the Nnf EventExposure Subscribe / Unsubscribe message, (i) an event ID, and (ii) one or more recommended UE ID(s). The UDM 308 and / or the PCF 360 then responds 918B, 919B to the AF 358 with (i) the event ID, and (ii) the one or more recommended UE ID(s). After receiving 918B, 919B a response including recommended UE ID(s), the AF 358 determines 990 UEs for the corresponding application operation.

[0106] Next, Fig. 10 illustrates a scenario 1000 that in which the UDM 308 receives a request for subscription data of type “user consent” from the NWDAF 356, which is configured to perform user consent checking with the UDM 308 based on local policy and regulation requirements for member selection assistance for an analytics exposure, as the AF 358 operating in the trusted domain indicates.

[0107] When the analytics information exposure is for the purpose of member selection assistance from the 5GC (e.g., the CN 110), the request from the AF 358 includes a member selection assistance indication. In view of the member selection assistance indication, the CN 110 can determine whether to perform user consent checking for privacy information related to a UE in procedures related to data collection, analytics generation, and information exposure. The application server can further determine the application member selection based on the information exposed by the CN 110. The NWDAF 356 can implement at least the following functionality: (i) determine whether to perform user consent checking with the UDM 308 for UE-related privacy information exposure, and (ii) provide a list of recommended UEs to the AF 358.

[0108] The NWDAF 356 in the scenario 1000 controls 1007 analytics exposure. The AF 358, operating within the trusted domain, requests 1020 analytics exposure via the NWDAF 356. The Nnf AnalyticsExposure Subscribe / Unsubscribe request message can include one or more of the following information: (i) a (first) set or list of one or more target UE IDs identifying respective one more candidate UEs for UE member selection, (ii) a first set of one or more analytics IDs, (iii) a member selection indication, (iv) UE member filtering criteria, or (v) validity criteria.

[0109] In response to receiving 1020 the request for analytics exposure, the NWDAF 356 determines 1028 whether to perform user consent checking. The NWDAF 356 checks 1028 the local policy and regulation requirements and performs 1030, 1032 user consent checking via the UDM 308. The NWDAF 356 can transmit 1030 a Nudm SDM Get message to the UDM 308 and include one or more of the following information in the message: (i) the first set of one or more target UE IDs (received 1020 from the AF 358), (ii) an indication that the purpose of the user consent checking is member selection, or (iii) a second set of one or more analytics IDs.

[0110] When the AF 358 does not transmit 1020 the member selection indication, the NWDAF 356 can perform user consent checking with the purpose set to “analytics” (in accordance with TS 23.288 clause 6.2.9), based on the local configuration and regulation related to data collection and analytics generation.[0U1] When the AF 358 transmits 1020 the member selection indication, and the NWDAF 356 is configured locally with a third set of analytics IDs related to UE privacy, the NWDAF 356 can select a second set of analytics IDs from the first set of event IDs, such that the analytics IDsin the second set are related to UE privacy and require user consent checking. The NWDAF 356 includes only the second set of analytics IDs in the request transmitted 1030 to the UDM 308. However, when the NWDAF 356 is configured to perform user consent checking without checking which analytics IDs are related to UE privacy, the NWDAF 356 can simply transmit 1030 the first set of analytics IDs, if received 1020 from the AF 358. The UDM 308 can check 1041 the subscription data type similar to the checking 741 in the scenario 700.

[0112] The UDM 308 responds 1032 to the NWDAF 356 with aNudm SDM Reply message, to indicate the results of the user consent checking 1041. The Nudm SDM Reply message can include a second list or set of UE IDs, in accordance with the fourth set of analytics IDs, for which user consent is granted.

[0113] Using the information received 1032 from the UDM 308, the NWDAF 356 can authorize the request (see event 1020) from the AF 358, for data exposure related to the fourth set of analytics IDs. When the second list of UE IDs received 1032 from the UDM 308 includes no UE IDs for the fourth set of analytics IDs, the NWDAF 356 can respond 1021A to the AF 358, without performing 1071, 1072 an event exposure information request for analytics, for the corresponding analytics ID(s).

[0114] Otherwise, for each analytics ID within the fourth set of analytics IDs, the NWDAF 356 transmits 1071, to the NFs such as the AMF 364, the SMF 366, the UPF 370, etc., anNnf RveniRxposure Subscribe Unsubscribe message to request event exposure for analytics data collection and analytics, for those UEs for which the corresponding user consent is granted. The NWDAF 356 can include 1071 one or more of (i) an event ID for which there is a granted user consent, (ii) the second list of UE IDs, (iii) the member selection indication, (iv) the UE member filtering criteria, or (v) the user consent checked indication, so as to notify the NWDAF 356 that user consent is granted for the target UEs.

[0115] For roaming scenarios in which a certain serving NF may have requirements different from those of the NEF 354 or the Home UDM 308, the NF needs to check whether the user consent checked indication is included, before providing 1072 event results to the NWDAF 356.

[0116] When there is no user consent checked indication, and when user consent is required based on the local policy or regulation, the NF 360, 364, 366, 370, etc. rejects the event exposurerequest during the procedure 1071 with a proper cause of rejection, e.g. lack of user consent. Otherwise, when the user consent checked indication is present, and when user consent is required based on the local policy or regulation, the NF 360, 364, 366, 370, etc. implements the corresponding event exposure procedure.

[0117] The NF 364, 366, 370, etc. transmits 1072 x Nnf EventExposure Notify message that can include (i) an event ID, and (ii) one or more recommended UE ID(s). The NWDAF 356 then responds 102 IB to the AF 358 with (i) the analytics ID, and (ii) the one or more recommended UE ID(s). After receiving 1021B a response including recommended UE ID(s), the AF 358 determines 1090 UEs for the corresponding application operation.

[0118] Referring next to Figs. 11 and 12, the CN 110 can manage subscription data for user consent using event exposure as a purpose, without relying on a member selection indication.

[0119] As discussed above with reference to Figs. 6-8, the subscription data type “user consent” corresponds to a particular purpose in the UDM 308. In addition to the purposes of analytics and ML model generation, the CN 110 in the scenarios 1100 and 1200 supports the purpose of “event exposure.” Thus, the purpose field in the data record of Table 1 above can include a value selected from the set of {analytics, ML model generation, event exposure). If desired, a CN can support both the techniques of Figs. 6-8 and the techniques of Figs. 11 and 12, and the purpose can be selected from the set of {analytics, ML model generation, member selection assistance, event exposure).

[0120] The CN 110 can implement the data structure of Table 1 and use the SUPI as the data key and the purpose as the data sub-key to identify subscription data for the privacy-related information, for a UE.

[0121] According to another approach consistent with Table 2 above, the subscription data type “extended user consent” is a subscription data type defined specifically for identifying, for information exposure that requires user consent, information related to UE privacy. The CN 110 provides exposure of such information using SUPI as the data key and an event ID as the data sub-key. The example event IDs can correspond to UE reachability, Loss of Connectivity, Roaming Status, o Location Reporting as discussed above with reference to Table 2.

[0122] In the scenario 1100 of Fig. 11, events 1102, 1128, 1130, 1132, 1140, 1150, and 1152 are generally similar to events 602, 628, 630, 632, 640, 650, and 652, respectively. Unlike the scenario 600, however, this scenario includes the AF 358 transmitting 1122 aNnef EventExposure Subscribe / Unsubscribe request message without a member selection indication. The message can include one or more of (i) a (first) set or list of one or more target UE IDs identifying respective one more candidate UEs for UE member selection, (ii) a first set of one or more event IDs, or (iii) validity criteria. Further, when checking the user consent with the UDM 308, the AF 358 transmits 1130 a Nudm _SDM Get message in which the purpose of the user consent checking identifies event exposure rather than member selection.

[0123] Similar to the scenario 600, when the NEF 354 is configured locally with a third set of event IDs related to UE privacy, the NEF 354 can select a second set of event IDs from the first set of event IDs, such that the event IDs in the second set are related to UE privacy and require user consent checking. The NEF 354 includes only the second set of event IDs in the request transmitted 630 to the UDM 308. When the NEF 354 is configured to perform user consent checking without checking which event IDs are related to UE privacy, the NEF 354 can simply transmit 1130 the first set of event IDs, if received 1122 from the AF 358.

[0124] Still further, the UDM 308 checks 1140 the subscription data type of user consent based on the SUPI, the purpose of the data set to “event exposure,” and the third set of event ID(s), unlike the scenario 600 in which the UDM 308 uses “member selection” as the purpose. When the NEF 354 does not indicate 1130 the second set of event IDs, and when the NEF 354 lacks a local configuration of the second set of event IDs, the UDM 308 can check the user consent for purpose of event exposure using the SUPI as a master key. When the NEF 354 indicates 1130 the second set of event IDs or stores the second set of event IDs locally, the UDM 308 can check the user consent for the purpose of event exposure using the SUPI as a master key, and the event ID(s) as the data sub-key(s).

[0125] Event 1123 A is similar to the event 611 A, and the NEF 354 transmits 1123 A this message when the second list of UE IDs received 1132 from the UDM 308 includes no UE IDs for the fourth set of event IDs.

[0126] Event 1150 is similar to the event 1150, but here the NEF 354 omits (refrains from including) a member selection indication from a message to the PCF 360, the AMF 364, theSMF 366, the UPF 370, or another suitable NF. In some cases, the NEF 354 also omits the UE member filtering criteria from this message.

[0127] With continued reference to Fig. 11 and Fig. 6, event 1152 is similar to the event 650, but here the NF such as the PCF 360, the AMF 364, the SMF 366, the UPF 370, etc. can include an event ID and event results for the second list or set of target UEs. In one implementation, the NEF 254 indicates the event results for the UEs that do not grant user consent for the event exposure.

[0128] The NEF 354 responds 1123B to the AF 358 with the event ID and the event results received 1152 from the NF. For a target UE with no granted user consent, the NEF 354 can set the event result value to an indication of no user consent. For the Target UE that does not grant user consent, the Event result indicates no user consent.

[0129] Now referring to Fig. 12, the AF 358 in a scenario 1200 operates in the trusted domain, and the UDM 308 receives a request for subscription data of user consent from the AF 358 or the PCF 360, which is configured to perform user consent checking with the UDM 308 based on local policy and regulation requirements for event exposure. Similar to the scenario 11, the purpose corresponds to event exposure, and one or more NFs in the CN 110 can provide the following functionality: (i) determine whether to perform user consent checking with the UDM 308 for UE-related privacy information exposure, and (ii) provide event information, for a requested target UE list, to the AF 258. The event information can include a result of user consent checking, when required by the local policy or regulation.

[0130] The UDM 308 and / or the UDR 352 control 1204 event exposure mapping, and the PCF 360 controls 1205 event exposure mapping. Generally similar to the scenario 900 discussed above, the AF 358 requests 1224 event exposure via the UDM 308 and / or requests 1225 requests event exposure via the PCF 316. The request to the UD 308 can be anNudm EventExposure Subscribe / Unsubscribe request message, and the request to the PCF 360 can be Npcf EventExposure Subscribe / Unsubscribe request message. Here, however, the request does not include a member selection indication and, in some cases, the request does not include UE member filtering criteria. The request can include (i) a (first) set or list of one or more target UE IDs identifying respective one more candidate UEs for UE member selection, (ii) a first set of one or more event IDs, or (iii) validity criteria.

[0131] When the AF 358 transmits 1225 the Npcf ' EventExposure Subscribe Unsubscribe request message in the trusted domain, the PCF 360 determines 1129 whether to perform user consent checking in view of the member selection indication and based on local policy and regulation requirements. The PCF 360 performs 1230, 1232 user consent checking via the UDM 308. The Nudtn SDM Get message to the UDM 308 can include one or more of the following information in the message: (i) the first set of one or more target UE IDs (received 917 from the AF 358), (ii) an indication that the purpose of the user consent checking is event exposure, or (iii) a second set of one or more event IDs.

[0132] When the PCF 360 is configured locally with a third set of event IDs related to UE privacy, the PCF 360 can select a second set of event IDs from the first set of event IDs, such that the event IDs in the second set are related to UE privacy and require user consent checking. The PCF 360 includes only the second set of event IDs in the request transmitted 1230 to the UDM 308. However, when the PCF 360 does not store configured to perform user consent checking without checking which event IDs are related to UE privacy, the PCF 360 can simply transmit 1230 the first set of event IDs, if received 1225 from the AF 358. In other words, here the second set event IDs is identical to the first set of event IDs.

[0133] When the AF 358 transmits 1224 the Nudm EventExposure Subscribe / Unsubscribe request message in the trusted domain, and when the UDM 308 is configured locally with a third set of event IDs related to UE privacy, the UDM 308 can select a second set of event IDs from the first set of event IDs, such that the event IDs in the second set are related to UE privacy and require user consent checking. When the UDM 308 is configured to perform user consent checking without checking which analytics IDs are related to UE privacy, the UDM 308 can consider the second set of event IDs and the first set of event IDs to be the same (i.e., the first and the second sets of events IDs are identical in this case).

[0134] The UDM 308 can check 1240 the subscription data type of user consent based on the SUPI, the purpose of the data set to “event exposure,” and the third set of event ID(s). When the PCF 360 does not indicate 1230 the second set of event IDs, and when the UDM 308 does not have a local configuration of the second set of event IDs, the UDM 308 can check the user consent for purpose of event exposure using the SUPI as a master key. When the PCF 360 indicates 1230 the second set of event IDs, or when the UDM 308 has a local configuration ofthe second set of event IDs, the UDM 308 can check the user consent for the purpose of event exposure using the SUPI as a master key, and the event ID(s) as the data sub-key(s). The UDM 308 can determine 1240 a fourth set of event IDs for which user consent is granted.

[0135] The UDM 308 can transmit 1232 the results of user consent checking to the PCF 360, which can include a second of UE IDs for which event IDs in the fourth set of event IDs have granted user consent. Based on the receiving 1232 of the results, the PCF 360 can authorize the request from the AF 358 for data exposure related to the fourth set of event IDs.

[0136] When the second list of UE IDs includes no UE IDs for the fourth set of event IDs, the UDM 308 can respond 1226A and / or the PCF 360 can respond 1227A to the AF 358, without performing 1253, 1254, 1255, 1257 an event exposure procedure for the corresponding event ID(s).

[0137] Otherwise, for each event ID within the fourth set of event IDs, the UDM 308 or the PCF 360 transmits 1253, 1255 respectively, to one or more network functions such as the PCF 360, the AMF 364, the SMF 366, or the UPF 370, anNnf EventExposure Subscribe Unsubscribe message including information for a related event exposure service operation. This information can include one or more of: (i) an event ID for which there is a granted user consent, (ii) the second list of UE IDs, or (iii) user consent checked indication, so as to notify the NF(s) that user consent is granted for the target UEs.

[0138] For roaming scenarios in which a certain serving NF may have requirements different from those of the NEF 354 or the Home UDM 308, the NF needs to check whether it received 1253, 1255 the user consent checked indication, before responding 1254, 1257 with event results to the UDM 308, PCF 360, respectively. When there is no user consent checked indication, and when user consent is required based on the local policy or regulation, the NF 364, 366, 370, etc. rejects (not shown) the event exposure request of the event 1253 or 1255 with a proper cause of rejection, e.g. lack of user consent. Otherwise, when the user consent checked indication is present, and when user consent is required based on the local policy or regulation, the NF 364, 366, 370, etc. implements the corresponding event exposure procedure.

[0139] The NF 364, 366, 370, etc. transmits 1255, 1257 an Nnf EventExposure Notify message to the UDM 308, the PCF 360, respectively. The message can include, for the secondlist or set of targeted UE IDs, (i) an event ID, and (ii) the event results. The PCF 360 and / or the UDM 308 can indicate the event results for the UEs that do not grant user consent for event exposure.

[0140] The UDM 308 and / or he PCF 360 then responds 1226B, 1227B to the AF 358 with (i) the event ID, and (ii) event results. For a target UE that does not grant user consent, the event result can indicate that no user consent is granted.

[0141] Next, Fig. 13 and 14 illustrate an approach according to which the CN 110 manages subscription data for user consent using analytics information exposure as a purpose, without relying on a member selection indication.

[0142] As discussed above with reference to Figs. 6-8 and 11-12, the subscription data type “user consent” corresponds to a particular purpose in the UDM 308. In addition to the purposes of analytics and ML model generation, the CN 110 in the scenarios 1300 and 1400 supports the purpose of “analytics exposure.” Thus, the purpose field in the data record of Table 1 above can include a value selected from the set of {analytics, ML model generation, analytics exposure}. If desired, a CN can support the techniques of Figs. 6-8 and 11-12 as well as the techniques of Figs. 13 and 14, and the purpose can be selected from the set of {analytics, ML model generation, member selection assistance, event exposure, analytics exposure}.

[0143] The CN 110 can implement the data structure of Table 1 and use the SUPI as the data key and the purpose as the data sub-key to identify subscription data for the privacy-rel ted information, for a UE. In the scenarios 1300 and 1400, the purpose can be “analytics exposure.” Further, in some implementations, the CN 110 can utilize the purpose of “analytics” (associated with data collection in 5GC) rather than “analytics exposure,” dedicated to analytic information exposure.

[0144] According to another approach consistent with Table 2 above, the subscription data type “extended user consent” is a subscription data type defined specifically for identifying, for information exposure that requires user consent, information related to UE privacy. The CN 110 provides exposure of such information using SUPI as the data key and an analytics ID as the data sub-key. The example analytics IDs can correspond to UE network data analytics related to UE privacy, such as for example UE mobility analytics, UE communication analytics, Expected UEbehavioral parameters related network data analytics, or Abnormal behavior related network data analytics.

[0145] In a scenario 1300 of Fig. 13, the AF 358 operates outside the trusted domain, and the NEF 354 processes a request for analytics information exposure. The UDM 308 receives a request for subscription data related to user consent from the NEF 354, which is configured to perform user consent checking with the UDM 308 based on (i) local policy and regulation requirements for analytics (information) exposure and (ii) member selection indication included in the request from the AF 358 operating in an untrusted domain.

[0146] When the analytics exposure is associated with a purpose of “extended analytics,” with more granular user consent data corresponding to a particular analytics ID, the CN 110 can implement at least the following functionality: (i) determine whether to perform user consent checking with the UDM 308 for UE-related privacy information exposure, and (ii) provide analytics information for a UEs included in a requested target UE list to the AF 358. The analytics information can include the result of user consent checking result for analytics, if required by the local policy or regulation. When the CN 110 uses the purpose of “analytics” rather than “analytics exposure,” the CN 110 also can provide analytics information for a UEs included in a requested target UE list to the AF 358, where the analytics information includes the result of user consent checking result for analytics, if required by the local policy or regulation

[0147] As illustrated in Fig. 13, the NEF 354 controls 1302 analytics exposure. The AF 358, operating outside the trusted domain of the CN 110, requests 1312 analytics exposure via the NEF 354. Unlike the Nnef AnalyticsExposure Subscribe / Unsubscribe request message of event 712 (see Fig. 7), here the request does not include a member selection indication and, in soe cases, does not include a UE member filtering criteria. The message can include one or more of the following information: (i) a (first) set or list of one or more target UE IDs identifying respective one more candidate UEs for UE member selection, (ii) a first set of one or more analytics IDs, or (iii) validity criteria.

[0148] In response to receiving 1312 the request for analytics exposure, the NEF 354 determines 1328 whether to perform user consent checking. The NEF 354 checks 1328 the local policy and regulation requirements and performs 1330, 1332 user consent checking via the UDM 308. The NEF 354 can transmit 1330 a Nudm SDM Get message to the UDM 308 and includeone or more of the following information in the message: (i) the first set of one or more target UE IDs (received 1312 from the AF 358), (ii) an indication that the purpose of the user consent checking is analytics exposure, or (iii) a second set of one or more analytics IDs.

[0149] When the NEF 354 is configured locally with a third set of analytics IDs related to UE privacy, the NEF 354 can select a second set of analytics IDs from the first set of event IDs, such that the analytics IDs in the second set are related to UE privacy and require user consent checking. The NEF 354 includes only the second set of analytics IDs in the request transmitted 1330 to the UDM 308. However, when the NEF 354 is configured to perform user consent checking without checking which analytics IDs are related to UE privacy, the NEF 354 can simply transmit 1330 the first set of analytics IDs, if received 712 from the AF 358.

[0150] The UDM 308 can check 1341 the subscription data type of user consent based on the SUPI, the purpose of the data set to “extended analytics,” and the third set of analytics ID(s).

[0151] When the NEF 354 does not indicate 1330 the second set of analytics IDs, the UDM 308 can check the user consent for purpose of extended analytics using the SUPI as a master key, as illustrated in Table 1 above for example. When the NEF 354 indicates 1330 the second set of event IDs, the UDM 308 can check the user consent for the purpose of member selection using the SUPI as a master key, and the analytics ID(s) as the data sub-key(s).

[0152] The UDM 308 can determine 1341 a fourth set of analytics IDs for which user consent is granted. The UDM 308 then responds 1332 to the NEF 354 with a Nudm SDM Reply message, to indicate the results of the user consent checking 1341. The Nudm SDM Reply message can include a second list or set of UE IDs, in accordance with the fourth set of analytics IDs, for which user consent is granted.

[0153] Next, using the information received 1332 from the UDM 308, the NEF 354 can authorize the request (see event 1312) from the AF 358, for data exposure related to the fourth set of analytics IDs. When the second list of UE IDs received 1332 from the UDM 308 includes no UE IDs for the fourth set of analytics IDs, the NEF 354 can respond 1313 A to the AF 358, without performing 1360, 1362 an analytics exposure procedure for the corresponding analytics ID(s).

[0154] Otherwise, for each analytics ID within the fourth set of analytics IDs, the NEF 354 transmits 1360, to the NWDAF 356, an Nnwda ' Analyticsinfo Request message including information for a related analytics service operation. This information can include one or more of: (i) an analytics ID for which there is a granted user consent, (ii) the second list of UE IDs, or (iii) user consent checked indication, so as to notify the NWDAF 356 that user consent is granted for the target UEs. Unlike the event 760 (see Fig. 7), here the Nnwdaf Analyticsinfo Request message does not include a member selection indication or, in at least some of the implementations, UE member fdtering criteria.

[0155] The NWDAF 356 performs 1370 event exposure subscription with one or more network functions such as the PCF 360, the AMF 364, the SMF 366, or the UPF 370. More specifically, for each analytics ID within the fourth set of analytics IDs, the NWDAF 356 requests 1370 event exposure only for the UEs with a granted user consent of analytics for data collection and / or analytics. The NWDAF 356 can provide 1370 one or more of: (i) an event ID for which there is a granted user consent, which can be an event ID within the fourth set of event IDs, (ii) the second list of UE IDs, or (iii) user consent checked indication, so as to notify the NF(s) that user consent is granted for the target UEs.

[0156] For roaming scenarios in which a certain serving NF may have requirements different from those of the NEF 354 or the Home UDM 308, the NF needs to check whether the NEF 354 included 1360 the user consent checked indication, before providing 1370 event results to the NWDAF 356.

[0157] When there is no user consent checked indication, and when user consent is required based on the local policy or regulation, the NF 360, 364, 366, 370, etc. rejects the event exposure request during the procedure 1370 with a proper cause of rejection, e.g. lack of user consent. Otherwise, when the user consent checked indication is present, and when user consent is required based on the local policy or regulation, the NF 360, 364, 366, 370, etc. implements the corresponding event exposure procedure.

[0158] The NWDAF 356 transmits 1362, to the NEF 354, an Nnwdaf Analyticsinfo Response message that can include (i) an analytics ID, and (ii) analytics results. The NEF 354 then responds 1313B to the AF 358, for the UEs in the first list or set of UE IDs, with (i) the analyticsID, and (ii) the analytics results. For a target UE that does not have a granted user consent, the analytics result indicates no user consent.

[0159] Referring to Fig. 14, the AF 358 in this scenario operates in the trusted domain and directly requests analytics (information) exposure from the NWDAF 356. The UDM 308 receives, from the NWDAF 356, a request for subscription data of type user consent. The NWDAF 356 is configured to perform user consent checking with the UDM 308 based on local policy and regulation requirements for analytics information exposure from the AF 358 operating in the trusted domain.

[0160] When the analytics information exposure is for the purpose of extended analytics, the NWDAF 356 can implement at least the following functionality: (i) determine whether to perform user consent checking with the UDM 308 for UE-related privacy information exposure, and (ii) provide analytics information for UEs in a requested target UEs to the AF 358, including the results of user consent checking for the analytics, when require by the local policy or regulation. Further, when the CN 110 provides this information using the purpose of analytics, the CN 110 also can provide analytics information for UEs in a requested target UEs to the AF 358, including the results of user consent checking for the analytics, when require by the local policy or regulation.

[0161] The NWDAF 356 in the scenario 1400 controls 1407 analytics exposure. The AF 358, operating within the trusted domain, requests 1420 analytics exposure via the NWDAF 356. The Nnf AnalyticsExposure Subscribe / Unsubscribe request message can include one or more of the following information: (i) a (first) set or list of one or more target UE IDs identifying respective one more candidate UEs for UE member selection, (ii) a first set of one or more analytics IDs, or (iii) validity criteria.

[0162] In response to receiving 1420 the request for analytics exposure, the NWDAF 356 determines 1428 whether to perform user consent checking. The NWDAF 356 checks 1428 the local policy and regulation requirements and performs 1430, 1432 user consent checking via the UDM 308. The NWDAF 356 can transmit 1430 a Nudm SDM Get message to the UDM 308 and include one or more of the following information in the message: (i) the first set of one or more target UE IDs (received 1410 from the AF 358), (ii) an indication that the purpose of the user consent checking is analytics exposure, or (iii) a second set of one or more analytics IDs.

[0163] The NWDAF 356 can perform user consent checking with the purpose set to “analytics” (in accordance with TS 23.288 clause 6.2.9), based on the local configuration and regulation related to data collection and analytics generation.

[0164] When the NWDAF 356 is configured locally with a third set of analytics IDs related to UE privacy, the NWDAF 356 can select a second set of analytics IDs from the first set of event IDs, such that the analytics IDs in the second set are related to UE privacy and require user consent checking. The NWDAF 356 includes only the second set of analytics IDs in the request transmitted 1430 to the UDM 308. However, when the NWDAF 356 is configured to perform user consent checking without checking which analytics IDs are related to UE privacy, the NWDAF 356 can simply transmit 1430 the first set of analytics IDs, if received 1420 from the AF 358.

[0165] The UDM 308 checks 1441 the subscription data type of user consent based on the SUPI, the purpose of the data set to “extended analytics,” and the third Analytics ID(s). If the UDM 308 has not received the second set of analytics ID(s), the UDM 308 checks the User consent for purpose of extended Analytics using the SUPI as a master key. If the UDM has received the second set of analytics ID(s), the UDM 308 checks 1441 the user consent for the purpose of extended analytics using the SUPI as master key, and the analytics ID(s) as the data sub-key(s). The UDM 308 determines a fourth set of analytics ID(s) for which user consent is granted.

[0166] The UDM 308 responds 1432 to the NWDAF 356 with a Nudm SDM Reply message, to indicate the results of the user consent checking 1441. The Nudm SDM Reply message can include a second list or set of UE IDs, in accordance with the fourth set of analytics IDs, for which user consent is granted.

[0167] Using the information received 1432 from the UDM 308, the NWDAF 356 can authorize the request (see event 1420) from the AF 358, for data exposure related to the fourth set of analytics IDs.

[0168] When the second list of UE IDs received 1432 from the UDM 308 includes no UE IDs for the fourth set of analytics IDs, the NWDAF 356 can respond 1421 A to the AF 358, withoutperforming 1471, 1472 an event exposure information request for analytics, for the corresponding analytics ID(s).

[0169] Otherwise, for each analytics ID within the fourth set of analytics IDs, the NWDAF 356 transmits 1471, to the NFs such as the AMF 364, the SMF 366, the UPF 370, etc., anNnf EventExposure Subscribe / Unsubscribe message to request event exposure for analytics data collection and analytics, for those UEs for which the corresponding user consent is granted. The NWDAF 356 can include 1471 one or more of: (i) an event ID for which there is a granted user consent, (ii) the second list or set of UE IDs, or (iii) the user consent checked indication, so as to notify the NWDAF 356 that user consent is granted for the target UEs.

[0170] For roaming scenarios in which a certain serving NF may have requirements different from those of the NEF 354 or the Home UDM 308, the NF needs to check whether the user consent checked indication is included, before providing 1472 event results to the NWDAF 356.

[0171] When there is no user consent checked indication, and when user consent is required based on the local policy or regulation, the NF 360, 364, 366, 370, etc. rejects the event exposure request during the procedure 1471 with a proper cause of rejection, e.g. lack of user consent.Otherwise, when the user consent checked indication is present, and when user consent is required based on the local policy or regulation, the NF 360, 364, 366, 370, etc. implements the corresponding event exposure procedure.

[0172] The NF 364, 366, 370, etc. transmits 1472 an Nnf EventExposure Notify message that can include (i) an event ID, and (ii) analytics results. The NWDAF 356 then responds 1421B to the AF 358 with (i) the analytics ID, and (ii) the analytics results. For a target UE that does not have a granted user consent, the analytics result can indicate no user consent.

[0173] Fig. 15 is a flow diagram of an example method 1500 for checking user consent. The method 1500 begins at block 1510, where an NF receives a request related to exposure of a CN function (see, e.g., events 610, 712, 813, 916, 917, 1020, 1122, 1224, 1312, 1420) and, optionally at block 1511, a member selection indication (see, e.g., events 610, 712, 916, 917, 1020). Next, at block 1540, the CN determines user consent information based on the request (see, e.g., 640, 741, 840, 940, 1041, 1140, 1240, 1341, 1441). At block 1520, the CN transmits, to the AF, a result of the determining (see, e.g., events 611A, 61 IB, 713A, 713B, 815A, 815B,918A, 918B, 919A, 919B, 1021A, 1021B, 1123A, 1123B, 1226A, 1226B, 1227A, 1227B, 1313A, 1313B, 1421A, 1421B).

[0174] The following list of examples reflects a variety of the embodiments explicitly contemplated by the present disclosure.

[0175] Example 1. A method implemented in a core network (CN) of a wireless communication system, the method comprising: receiving, from an application function (AF), a request (i) related to an exposure of a CN function, and / or (ii) including a member selection indication; determining, for a user equipment (UE) and based on the request, user consent information; and transmitting, to the AF, a result of the determining.

[0176] Example 2. The method of example 1, wherein the determining includes: retrieving, from a database, the user consent information using (i) an identity of the UE as a key and (ii) a purpose indicator indicating the member selection assistance as a subkey.

[0177] Example 3. The method of example 1, wherein the determining includes retrieving, from a database, the user consent information using (i) an identity of the UE as a key and (ii) a purpose indicator indicating event exposure as a subkey.

[0178] Example 4. The method of example 1, wherein the determining includes retrieving, from a database, the user consent information using (i) an identity of the UE as a key and (ii) a purpose indicator indicating analytics exposure as a subkey.

[0179] Example 5. The method of example 1, wherein the determining includes retrieving, from a database, the user consent information using (i) an identity of the UE as a key and (ii) an event identifier or an analytics identifier as a subkey.

[0180] Example 6. The method of example 5, further comprising storing, in the database, a first user consent indication for a first value of the event identifier, and a second user consent indication for a second value of the event identifier.

[0181] Example 7. The method of example 5s, further comprising storing, in the database, a first user consent indication for a first value of the analytics identifier, and a second user consent indication for a second value of the analytics identifier.

[0182] Example 8. The method of any of examples 2-7, wherein the identity of the UE includes a Subscription Permanent Identifier (SUP I).

[0183] Example 9. The method of any of examples 2-8, wherein the determining of the user consent information includes sending a message to a Unified Data Management (UDM) function of the CN, the message including a key and a subkey; and receiving the user consent information from the UDM function.

[0184] Example 10. The method of any of examples 2-9, wherein the database stores user subscription information.

[0185] Example 11. The method of any of the preceding examples, wherein the receiving of the request from the AF is implemented in a network exposure function (NEF).

[0186] Example 12. The method of example 6, wherein the AF operates outside a trusted domain of the CN.

[0187] Example 13. The method of any of examples 1-3 or 5, wherein the receiving of the request from the AF is implemented in an NEF; and the request includes an event exposure subscribe request.

[0188] Example 14. The method of example 13, further comprising mapping, at the NEF, an event identifier included in the event exposure subscribe request to a second event identifier used by a UDM.

[0189] Example 15. The method of any of examples 1, 2, or 4, wherein the receiving of the request from the AF is implemented in an NEF; and the request includes an analytics exposure request.

[0190] Example 16. The method of example 13 or 14, wherein the request includes the member selection indication.

[0191] Example 17. The method of example 1 or 2, wherein the receiving of the request from the AF is implemented in an NEF; and the request includes a member select assistance exposure request.

[0192] Example 18. The method of any of examples 12-17, further comprising checking, at the NEF, whether to perform the determining of the user consent information at a unified data management (UDM) function.

[0193] Example 19. The method of example 18, wherein the checking includes applying a local policy and regulation requirements.

[0194] Example 20. The method of example 19, further comprising providing, to the AF, a list of recommended UEs consistent with the local policy and regulation requirements.

[0195] Example 21. The method of any of examples 11-20, wherein the request includes a member selection indication.

[0196] Example 22. The method of any of examples 11-21, wherein the request includes one or more UE member filtering criteria.

[0197] Example 23. The method of any of examples 6-21, wherein the request includes one or more validity criteria.

[0198] Example 24. The method of any of examples 1-5, wherein the receiving of the request from the AF is implemented in a unified data management (UDM) function and / or policy control function (PCF).

[0199] Example 25. The method of any of examples 1-5, wherein the receiving of the request from the AF is implemented in a network data analytics function (NWDAF).

[0200] Example 26. The method of examples 24 or 25, wherein the AF operates within a trusted domain of the CN.

[0201] Example 27. A component in a core network (CN) of a wireless communication system, comprising processing hardware and configured to implement a method of any of the preceding examples.

[0202] The following description may be applied to the description above.

[0203] A user device in which the techniques of this disclosure can be implemented (e.g., the UE 102) can be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a mobile gaming console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a media-streaming dongle or another personalmedia device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an intemet-of-things (loT) device or a mobile-internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0204] Certain embodiments are described in this disclosure as including logic or a number of components or modules. Modules may can be software modules (e.g., code stored on non- transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module can comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose 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 comprise programmable logic or circuitry (e g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

[0205] The term “or” as used herein is to be interpreted as an inclusive or meaning any one or any combination, unless expressly indicated otherwise, mutually exclusive, or indicated otherwise by context. Therefore, herein, the expression “A or B” means “A, B, or both A and B.”

[0206] When implemented in software, the techniques can be provided as part of the operating system, a library used by multiple applications, a particular software application, etc. The software can be executed by one or more general-purpose processors or one or more specialpurpose processors.

Claims

What is claimed is:

1. A method implemented in a core network (CN) of a wireless communication system, the method comprising: receiving, from an application function (AF), a request (i) related to an exposure of a CN function, and / or (ii) including a member selection indication; determining, for a user equipment (UE) and based on the request, user consent information; and transmitting, to the AF, a result of the determining.

2. The method of claim 1, wherein the determining includes: retrieving, from a database, the user consent information using (i) an identity of the UE as a key and (ii) a purpose indicator indicating the member selection assistance as a subkey.

3. The method of claim 1, wherein the determining includes: retrieving, from a database, the user consent information using (i) an identity of the UE as a key and (ii) a purpose indicator indicating event exposure as a subkey.

4. The method of claim 1, wherein the determining includes: retrieving, from a database, the user consent information using (i) an identity of the UE as a key and (ii) a purpose indicator indicating analytics exposure as a subkey.

5. The method of claim 1, wherein the determining includes: retrieving, from a database, the user consent information using (i) an identity of the UE as a key and (ii) an event identifier or an analytics identifier as a subkey.

6. The method of any of the preceding claims, wherein: the receiving of the request from the AF is implemented in a network exposure function (NEF).

7. The method of any of claims 1-3 or 5, wherein: the receiving of the request from the AF is implemented in an NEF; andthe request includes an event exposure subscribe request.

8. The method of any of claims 1, 2, or 4, wherein: the receiving of the request from the AF is implemented in an NEF; and the request includes an analytics exposure request.

9. The method of claim 1 or 2, wherein: the receiving of the request from the AF is implemented in an NEF; and the request includes a member select assistance exposure request.

10. The method of any of claims 6-9, further comprising: checking, at the NEF, whether to perform the determining of the user consent information at a unified data management (UDM) function.

11. The method of claim 10, wherein the checking includes applying a local policy and regulation requirements.

12. The method of claim 11, further comprising: providing, to the AF, a list of recommended UEs consistent with the local policy and regulation requirements.

13. The method of any of claims 1-5, wherein: the receiving of the request from the AF is implemented in a unified data management (UDM) function and / or policy control function (PCF).

14. The method of any of claims 1-5, wherein: the receiving of the request from the AF is implemented in a network data analytics function (NWDAF).

15. A component in a core network (CN) of a wireless communication system, comprising processing hardware and configured to implement a method of any of the preceding claims.

Images