Network node

Abstract

A network node according to the present invention comprises: a transmission unit that transmits, to a first network node, a first message which includes data information indicating the content of data and information pertaining to the purpose of use of the data and which requests information pertaining to whether user permission has been given for the data information; and a reception unit that receives, from the first network node, a second message which includes information pertaining to whether the user permission has been given.

Description

Network node

[0001] The present invention relates to a network node in a communication system.

[0002] In 3GPP (registered trademark) (3rd Generation Partnership Project), a radio communication system called 5G or NR (New Radio) (hereinafter, this radio communication system is referred to as "5G" or "NR") is being studied to achieve further increase in system capacity, further higher data transmission rate, further lower latency in radio sections, and the like. In 5G, various radio technologies are being studied to satisfy the requirement that the latency in radio sections is reduced to 1 ms or less while achieving a throughput of 10 Gbps or more.

[0003] In addition, network architectures for 5GC (5G Core Network) or 5GS (5G System), which are 5G core networks, and 6GC (6G Core Network) or 6GS (6G System), which are successors to 5G, are also being studied (see, for example, Non-Patent Document 1).

[0004] In addition, in 3GPP, as a countermeasure against abnormal behavior of terminals and networks (abnormal behavior, for example, signalling storm caused by abnormally excessive control signals), a mechanism for optimization utilizing Artificial Intelligence is being studied. Utilization of AI requires various data (for example, signal amount of terminals, connection patterns, etc.) for machine learning model formation and AI inference.

[0005] 3GPP TS 23.501 V18.7.0 (2024-09) 3GPP TR 23.700-84 V2.0.0 (2024-09) 3GPP TS 23.288 V18.7.0 (2024-09) 3GPP TS 29.503 V18.7.0 (2024-09) 3GPP TS 29.520 V18.7.0 (2024-09)

[0006] In the use of data necessary for utilizing artificial intelligence (AI), user consent may be required. Non-patent document 3 here stipulates a mechanism in which users (subscriber information) grant permission for data use from the perspective of protecting personal information, depending on "for what purpose the data will be used" and "for what purpose the data will be collected."

[0007] However, this system makes it difficult to reflect the user's intentions and fails to achieve the purpose of user permission.

[0008] This invention has been made in view of the above points, and aims to introduce a mechanism that reflects the user's intentions in user permission for data use in wireless communication networks.

[0009] According to the disclosed technology, a network node is provided having a transmitting unit that transmits a first message to a first network node that includes data information indicating the content of the data and information regarding the purpose of use of the data, and requests information regarding whether user permission has been granted for the data information; and a receiving unit that receives a second message from the first network node that includes information regarding whether user permission has been granted.

[0010] According to the disclosed technology, a mechanism can be introduced to reflect the user's intentions in user permission for data use in wireless communication networks.

[0011] This is a diagram illustrating an example of a communication system. This is a diagram illustrating an example of a communication system in a roaming environment. This is a diagram illustrating an example of a first sequence diagram in an embodiment of the present invention. This is a diagram illustrating step 1 of the first sequence diagram in an embodiment of the present invention. This is a diagram illustrating step 2a of the first sequence diagram in an embodiment of the present invention. This is a diagram illustrating an example of a second sequence diagram in an embodiment of the present invention. This is a diagram illustrating step 1 of the second sequence diagram in an embodiment of the present invention. This is a diagram illustrating step 2 of the second sequence diagram in an embodiment of the present invention. This is a diagram illustrating an example of a third sequence diagram in an embodiment of the present invention. This is a diagram illustrating step 1 of the third sequence diagram in an embodiment of the present invention. This is a diagram illustrating an example of a fourth sequence diagram in an embodiment of the present invention. This is a diagram illustrating step 2a of the fourth sequence diagram in an embodiment of the present invention. This is a diagram illustrating step 1 of the fourth sequence diagram in an embodiment of the present invention. This is a diagram illustrating an example of a fifth sequence diagram in an embodiment of the present invention. This is a diagram illustrating step 1 of the fifth sequence diagram in an embodiment of the present invention. This is a diagram illustrating data (1) used in an embodiment of the present invention. This is a diagram illustrating data (2) used in an embodiment of the present invention. This is a diagram illustrating data (3) used in an embodiment of the present invention. This is a diagram illustrating data (4) used in an embodiment of the present invention. This is a diagram illustrating data (5) used in an embodiment of the present invention. This is a diagram illustrating data (6) used in an embodiment of the present invention. This is a diagram illustrating data (7) used in an embodiment of the present invention. This is a diagram illustrating data (8) used in an embodiment of the present invention. This is a diagram illustrating an example of the functional configuration of the base station 10 and network node 30 in an embodiment of the present invention. This is a diagram illustrating an example of the functional configuration of the terminal 20 in an embodiment of the present invention. This is a diagram illustrating an example of the hardware configuration of the base station 10, terminal 20, and network node 30 in an embodiment of the present invention. This is a diagram illustrating an example of the configuration of the vehicle 2001 in an embodiment of the present invention.

[0012] Embodiments of the present invention will be described below with reference to the drawings. The embodiments described below are examples, and the embodiments to which the present invention applies are not limited to those described below. Furthermore, in the following description, " / " means "and / or" unless otherwise specified, or unless it is clear from the context that it has a different meaning.

[0013] In the operation of the wireless communication system according to the embodiments of the present invention, existing technologies may be used as appropriate. However, such existing technologies include, for example, existing LTE, but are not limited to existing LTE. Furthermore, the term "LTE" as used herein has a broad meaning that includes LTE-Advanced, LTE-Advanced and later technologies (e.g., NR), or wireless LAN (Local Area Network), unless otherwise specified.

[0014] Furthermore, in the embodiments of the present invention, "configuring" wireless parameters means that predetermined values ​​are pre-configured, or that wireless parameters notified from the network node 30 or terminal 20 are configured.

[0015] Figure 1 is a diagram illustrating an example of a communication system. As shown in Figure 1, the communication system consists of a terminal 20 (UE) and multiple network nodes 30. Hereafter, one network node 30 will be assumed to correspond to each function, but one network node 30 may implement multiple functions, or multiple network nodes 30 may implement one function. Also, the "connection" described below may be a logical connection or a physical connection.

[0016] The RAN (Radio Access Network) is a network node 30 having wireless access functionality, which may include a base station 10, and is connected to a UE, AMF (Access and Mobility Management Function), and UPF (User plane function). The AMF is a network node 30 having functions such as terminating the RAN interface, terminating the NAS (Non-Access Stratum), registration management, connection management, reachability management, and terminal mobility management. The UPF is a network node 30 interconnected with the DN (Data Network) and having functions related to processing user plane data, such as a PDU (Protocol Data Unit) session point to the outside, packet routing and forwarding, and user plane QoS (Quality of Service) handling. The UPF and DN constitute a network slice. In the wireless communication network in the embodiment of the present invention, a plurality of network slices are constructed.

[0017] AMF is connected to UE, RAN, SMF (Session Management function), NSSF (Network Slice Selection Function), NEF (Network Exposure Function), NRF (Network Repository Function), UDM (Unified Data Management), AUSF (Authentication Server Function), PCF (Policy Control Function), and AF (Application Function). AMF, SMF, NSSF, NEF, NRF, UDM, AUSF, PCF, and AF are network nodes 30 that are interconnected via interfaces based on their respective services: Namf, Nsmf, Nnssf, Nnef, Nnrf, Nudm, Nausf, Npcf, and Naf.

[0018] The SMF is a network node 30 that has functions such as session management, IP (Internet Protocol) address allocation and management for UEs, DHCP (Dynamic Host Configuration Protocol) functionality, ARP (Address Resolution Protocol) proxy, and roaming functionality. The NEF is a network node 30 that has the function of notifying other NFs (Network Functions) of capabilities and events. The NSSF is a network node 30 that has functions such as selecting the network slice to which the UE connects, determining the allowed NSSAI (Network Slice Selection Assistance Information), determining the NSSAI to be set, and determining the AMF set to which the UE connects. The PCF is a network node 30 that has the function of controlling network policies. The AF is a network node 30 that has the function of controlling application servers. The NRF is a network node 30 that has the function of discovering NF instances that provide services. The UDM is a network node 30 that manages subscriber data and authentication data. The UDM is connected to the UDR (User Data Repository) that holds the said data.

[0019] Figure 2 is a diagram illustrating an example of a communication system in a roaming environment. As shown in Figure 2, the network consists of a terminal 20 (UE) and multiple network nodes 30. Hereafter, one network node 30 will be assigned to each function, but one network node 30 may implement multiple functions, or multiple network nodes 30 may implement one function. Also, the "connection" described below may be a logical connection or a physical connection.

[0020] The RAN is a network node 30 having wireless access functionality and is connected to the UE, AMF, and UPF. The AMF is a network node 30 having functions such as RAN interface termination, NAS termination, registration management, connection management, reachability management, and mobility management. The UPF is a network node 30 interconnected with the DN, having functions such as external PDU session point, packet routing and forwarding, and user plane QoS handling. The UPF and DN constitute a network slice. In the wireless communication network according to the embodiment of the present invention, multiple network slices are constructed.

[0021] AMF is connected to UE, RAN, SMF, NSSF, NEF, NRF, UDM, AUSF, PCF, AF, and SEPP (Security Edge Protection Proxy). AMF, SMF, NSSF, NEF, NRF, UDM, AUSF, PCF, and AF are network nodes 30 that are interconnected via interfaces based on their respective services: Namf, Nsmf, Nnssf, Nnef, Nnrf, Nudm, Nausf, Npcf, and Naf.

[0022] SMF is a network node 30 that has functions such as session management, IP address allocation and management for UEs, DHCP functionality, ARP proxy, and roaming functionality. NEF is a network node 30 that has the function of notifying other NFs of capabilities and events. NSSF is a network node 30 that has functions such as selecting the network slice to which the UE connects, determining which NSSAIs are allowed, determining which NSSAIs are configured, and determining which AMF set the UE connects to. PCF is a network node 30 that has the function of controlling network policies. AF is a network node 30 that has the function of controlling application servers. NRF is a network node 30 that has the function of discovering NF instances that provide services. SEPP is an opaque proxy that filters control plane messages between PLMNs (Public Land Mobile Networks). In Figure 2, vSEPP is the SEPP in the visited network, and hSEPP is the SEPP in the home network.

[0023] As shown in Figure 2, the UE is in a roaming environment connected to the RAN and AMF in the Visited PLMN. The Visited PLMN and Home PLMN are connected via vSEPP and hSEPP. The UE can communicate with the UDM of the Home PLMN, for example, via the AMF of the Visited PLMN.

[0024] The following describes how to implement a mechanism that reflects the user's wishes in user permission for data use in wireless communication networks.

[0025] In the existing specifications (Non-Patent Document 4), the purposes for which user consent can be specified include analysis, training of artificial intelligence / machine learning models, disclosure of network performance (NW_CAP_EXPOSURE), and generation of terminal location information by edge applications (EDGEAPP_UE_LOCATION).

[0026] In this case, if the granularity of information regarding user consent is too coarse, it may not be possible to accurately reflect the user's user consent requirements. For example, if the purpose of user consent is analytics, user consent is uniformly granted regardless of the type of UE data, regardless of the purpose of the analytics. Similarly, if the purpose of user consent is model training, user consent is uniformly granted regardless of the type of UE data, regardless of the purpose of the model training analysis.

[0027] Thus, it is not possible to accurately reflect the user's consent requirements. For example, a user may not like the idea of ​​their location information being collected and used to analyze / predict their behavioral patterns (e.g., the speed of the user experience as part of user behavior analysis), but may not mind if their data is used by AI to detect abnormal behavior from a hacked device (e.g., signaling storm analysis). However, existing specifications uniformly grant or deny permission in such cases.

[0028] The following describes methods for enabling more granular user consent, including methods for user consent requests and responses, feature negotiation, user consent category configuration, and user authentication (Enhance OAuth2.0 scope).

[0029] (Method 1) This section describes the method for enhancing user consent requests and responses.

[0030] The NF service consumer 30A, a network function that utilizes the service, sends a message to the UDM 30B requesting information regarding user permission from the terminal 20 for one or more pieces of information (whether or not to grant permission). The NF service consumer 30A may be, for example, an NWDAF (Network Data Analytics Function), DCCF (Data Collection Coordination Function), NEF, trusted AF (Trusted Application Function), AMF, SMF, and PCF. The message may include data information indicating the content of the data for the requested user permission (e.g., Service Experience, QoE metrics, UE Speed, State transition information, etc.) and analysis information indicating the purpose for which the data will be used (e.g., information indicating the content of the data analysis (e.g., SLICE_LOAD_LEVEL, NETWORK_PREFERENCE, SIGNALLING_STORM, etc.)).

[0031] Furthermore, the data information may include category information (such as COMMUNICATION, LOCATION, OTHERS, etc.). If multiple data items are included, category information may be set for each data item.

[0032] Furthermore, the analysis may include category information for the analysis data (e.g., Network Resource Utilization and Load, Service Experience and QoS, User Behavior and Mobility). If multiple analysis data are included, category information may be set for each analysis data.

[0033] Furthermore, the data information may include information regarding privacy (whether or not the information is related to privacy) (PRIVACY, NON PRIVACY). If multiple pieces of data information are included, privacy information may be set for each piece of data information.

[0034] Furthermore, the analysis information may include privacy-related information (PRIVACY, NON-PRIVACY). If multiple analysis pieces are included, privacy-related information may be set for each piece of analysis.

[0035] In response to the received message, UDM30B sends a message to NF service consumer30A containing information regarding the user permission of terminal 20 (whether permission is granted or not).

[0036] Figure 3 shows an example of a first sequence diagram in an embodiment of the present invention. The processing of each step will be described below.

[0037] In step 1, the NF service consumer 30A sends a message to the UDM 30B requesting information regarding user authorization for terminal 20 (whether or not to grant authorization). Figure 4 is a diagram illustrating step 1 of the first sequence diagram in an embodiment of the present invention. As shown in Figure 4, the message in step 1 may have the data structure shown in alt#1 to alt#4 below. Also in Figure 4, the correspondence between alt#1 to alt#4 and the behaviors 81 to 84 and the information 31 to 35 described later is shown.

[0038] (alt#1) The Step 1 message is an existing specification message for querying user permission for a user permission purpose (UcPurpose), which includes a newly defined data structure.

[0039] (alt#2) The Step 1 message is an existing specification message that queries the user for permission regarding the user's permission for the purpose of the user permission, including information about the category (UcCategory).

[0040] (alt#3) The Step 1 message is an existing specification message for querying the user's permission for the purpose of the user permission (UcPurpose), which includes information about the type of user permission (UcType) (PRIVACY or NON PRIVACY).

[0041] (alt#4) The message in step 1 is a message conforming to existing specifications for inquiring a user's consent for a user consent purpose (UcPurpose), and includes a user consent privacy indicator (UcPrivacyIndicator (True or False)).

[0042] (alt#5) The message in step 1 is a message for a newly defined endpoint or resource for inquiring a user's consent for a user consent purpose (UcPurpose).

[0043] Description will be given with reference back to FIG. 3. As a response to the message received in step 1, the UDM 30B transmits, to the NF service consumer 30A, a message including information (whether consent is given or not) related to the user consent of the terminal 20 to the NF service consumer 30A. Here, as step 2a, when the UDM 30B is able to acquire the requested information related to user consent (for example, when the information is included in subscriber information stored in the UDM 30B itself), the UDM 30B transmits a positive response (200 OK) including the information. Further, as step 2b, when the information cannot be acquired, the UDM 30B transmits a response (404 Not Found) indicating that the information cannot be found.

[0044] FIG. 5 is a diagram for explaining step 2a in the first sequence diagram according to the embodiment of the present invention. As shown in FIG. 5, as altA, for the messages of alt#1 to alt#4 in step 1, the message of step 2a is a message based on existing specifications including, for example, a list indicating information corresponding to user consent being "consent given". Details of the information included in this message will be described later in the information on the behaviors of 811, 821, 831, and 841.

[0045] Also, as altB, for the message in step 2a, the NF service consumer transmits a message based on existing specifications including a list indicating information corresponding to user consent being "consent", for example, in response to the message of alt#5 in step 1. Details of the newly defined information included in this message will be described later in the information on the 851st behavior.

[0046] (Method 1a) A method regarding requests for and responses to user consent that uses messages of multiple data sets request and response will be described.

[0047] Fig. 6 is a diagram showing an example of a second sequence diagram according to an embodiment of the present invention. The processing of each step will be described below.

[0048] In step 1, an NF service consumer 30A transmits a message including multiple data sets to a UDM 30B, where the message requests information related to user consent of the terminal 20 (whether consent is given or not). Fig. 7 is a diagram for explaining step 1 of the second sequence diagram according to an embodiment of the present invention. As shown in Fig. 7, the message of step 1 may adopt the data structures shown in alt#1 to alt#4 below. Further, Fig. 4 shows the correspondence between alt#1 to alt#4, the 81st to 84th behaviors described later, and the 31st to 35th information.

[0049] (alt#1) The message of step 1 is a message having a data structure that includes, for each data information category (UC_CATEGORY), information (uc_purpose) specifying the purpose of data use for which user consent is inquired.

[0050] (alt#2) The message of step 1 is a message having a data structure that includes, for each data information category (UC_CATEGORY), information (uc_purpose) specifying the purpose of data use for which user consent is inquired and information specifying the category of data use purpose (uc-purpose).

[0051] (alt#3) The message in Step 1 is a message with a data structure that includes information specifying the purpose of data use for which user consent is to be requested (uc_purpose) and information specifying the type of privacy of the data use purpose (uc_type) for each type of privacy related to the data information (UC_TYPE).

[0052] (alt#4) The message in Step 1 is a message with a data structure that includes information specifying the data usage purpose for which user consent is to be queried (uc_purpose) and information specifying the privacy indicator for the data usage purpose (uc_privacyindicator(true / false)) for each data information privacy indicator (UC_PRIVACY(true / false)).

[0053] (alt#5) The Step 1 message is a message that has a data structure that includes information (uc_purpose) specifying the purpose of data use for which user consent is to be sought, for each data information privacy directive (UC_PRIVACY).

[0054] Let's return to Figure 6 for explanation. In response to the message received in Step 1, UDM30B sends a message to NF service consumer30A containing information regarding user permission for terminal 20 (whether permission is granted or not). Here, UDM30B sends an acknowledgment (200 OK) containing the user permission information for the available datasets in response to the user permission information for the multiple datasets requested.

[0055] Figure 8 is a diagram illustrating step 2 of a second sequence diagram in an embodiment of the present invention. As shown in Figure 5, as altA, the message in step 2 sends a message containing a dataset containing information about the acquired user permission to the messages alt#1 to alt#4 of step 1.

[0056] Additionally, as altB, the message in step 2 sends a message to the alt#5 message in step 1 that includes a dataset containing information about the acquired user permission and a dataset containing information about the privacy of that information.

[0057] (Method 2) We will now describe a method related to feature negotiation (Enhance feature negotiation).

[0058] Figure 9 shows an example of a third sequence diagram in an embodiment of the present invention. The processing of each step will be described below.

[0059] In step 1, NF service consumer 30A sends a message to UDM 30B requesting information regarding user permission for terminal 20 (whether to grant or not). Figure 10 is a diagram illustrating step 1 of a third sequence diagram in an embodiment of the present invention. As shown in Figure 10, the message in step 1 may include information regarding the purpose of data use (uc-purpose) and information indicating that NF service consumer 30A supports a function related to user permission for said information. In step 2, UDM 30B does not send information regarding user permission (whether to grant or not) to NF service consumer 30A, and does not include information indicating that it supports a function related to user permission.

[0060] (Method 3) This section describes the method for configuring user consent categories.

[0061] Figure 11 shows an example of a fourth sequence diagram in an embodiment of the present invention. The processing of each step will be described below.

[0062] In step 1, the NF service consumer 30A sends a message to the UDM 30B requesting information regarding the user authorization of terminal 20 (whether or not to grant authorization).

[0063] In step 2a, UDM30B sends a message to NF service consumer30A containing information regarding user permission (permission granted) for terminal 20 as a response to the received message. Figure 12 is a diagram illustrating step 2a of the fourth sequence diagram in an embodiment of the present invention. As shown in Figure 12, if the message in step 1 does not contain category information for the user permission information (data information / information regarding purpose of use), UDM30B may send a message to NF service consumer30A that includes information regarding the category of the information in addition to the user permission information (permission granted). Details regarding this message will be described later in the behavior information in sections 812, 822, 832, 842, and 852. Also, if UDM30B receives a message from NF service consumer30A in step 1 that does not contain any category information, UDM30B may send a message to NF service consumer30A that includes information regarding all categories.

[0064] Figure 13 is a diagram illustrating step 1 of a fourth sequence diagram in an embodiment of the present invention. As shown in Figure 13, the NF service consumer 30A stores the received category information in its own device and, again in step 1, when sending a message to the UDM 30B requesting user permission information (whether or not to grant permission) for the terminal 20, it may send a message using the stored category information.

[0065] (Method 4) This section describes the method for user authentication (Enhance OAuth2.0 scope).

[0066] Figure 14 shows an example of a fifth sequence diagram in an embodiment of the present invention. The processing of each step will be described below.

[0067] In step 1, the NF service consumer 30A sends a message to the NRF 30C requesting an access token to use the application interface (Nudm_SDM API) for obtaining subscriber information from the UDM. Figure 15 is a diagram illustrating step 1 of the fifth sequence diagram in an embodiment of the present invention. As shown in Figure 15, in step 1, the NF service consumer 30A may set a newly defined parameter "nudm-sdm:uc-data-privacy:read" as scope information in the OAuth2 authentication protocol in order to access user consent privacy data. Details regarding step 1 and the parameter are shown in the information on behavior 91 and behavior 91 described later.

[0068] Let's return to Figure 14 for explanation. In step 2, NRF30C sends the NF service consumer30A, based on the authentication result, an acknowledgment including the access token as step 2a (200 OK), or an error (400 Bad Request) or other error (403 Forbidden) without the access token as step 2b.

[0069] (Data Details) The following describes the details of the data managed / configured by NF service consumer 30A in Method 1 and Method 1a.

[0070] Figure 16 is a diagram illustrating the data (1) used in an embodiment of the present invention. As shown in Figure 16, the NF service consumer 30A may associate data information (Data / Information) with category information (Category). The NF service consumer 30A may also perform operations such as adding, updating, and deleting elements of the information.

[0071] Figure 17 is a diagram illustrating the data (2) used in an embodiment of the present invention. As shown in Figure 17, the NF service consumer 30A may associate an identifier for analytical information (Analytics(ID)) with information about the category (Category). The NF service consumer 30A may also perform operations such as adding, updating, and deleting elements of the information.

[0072] Figure 18 is a diagram illustrating the data (3) used in an embodiment of the present invention. As shown in Figure 18, the NF service consumer 30A may associate data information (Data / Information) with information regarding the type of privacy (Type). The NF service consumer 30A may also perform additions, updates, and deletions on elements of the information.

[0073] Figure 19 is a diagram illustrating the data (4) used in an embodiment of the present invention. As shown in Figure 19, the NF service consumer 30A may associate an identifier for analytical information (Analytics(ID)) with information regarding the type of privacy (Type). The NF service consumer 30A may also perform additions, updates, and deletions on elements of the information.

[0074] Figure 20 is a diagram illustrating the data (5) used in an embodiment of the present invention. As shown in Figure 20, the NF service consumer 30A may associate data information (Data / Information) with information for determining privacy (privacy). The NF service consumer 30A may also perform additions, updates, and deletions on elements of the information.

[0075] Figure 21 is a diagram illustrating the data (6) used in an embodiment of the present invention. As shown in Figure 21, the NF service consumer 30A may associate an identifier for analytical information (Analytics(ID)) with information for determining privacy (privacy). The NF service consumer 30A may also perform additions, updates, and deletions on elements of the said information.

[0076] Figure 22 is a diagram illustrating the data (7) used in an embodiment of the present invention. As shown in Figure 22, the NF service consumer 30A may associate new information (new resource) for determining privacy with the data information (Data / Information). The NF service consumer 30A may also perform additions, updates, and deletions on elements of the said information.

[0077] Figure 23 is a diagram illustrating the data (8) used in an embodiment of the present invention. As shown in Figure 23, the NF service consumer 30A may associate an identifier for analytical information (Analytics(ID)) with new information for determining privacy (new resource). The NF service consumer 30A may also perform additions, updates, and deletions on elements of the information.

[0078] Details regarding the processing / data etc. shown in Method 1, Method 1a, Method 2, Method 3, and Method 4 will be explained below. Here, NF service consumer 30A may also be referred to as NF consumer.

[0079] (Behavior 81 to Behavior 85) The procedure for obtaining Nudm user authorization information by an NF consumer, including NWDAF, is described below. The NF consumer may be a Nudm consumer and may be, but is not limited to, NWDAF, DCCF, NEF, trusted AF, AMF, SMF, PCF, LMF, or EIF (Energy Information Function). Hereafter, for explanatory purposes, such an NF consumer will be referred to as an NF consumer. In this procedure, one or more of the behaviors 81 to 85 shown below may be performed.

[0080] (81st behavior) a) The 81st behavior in this embodiment is the behavior in which the NF consumer sends a GET request to the UDM to obtain user permission information. In the 81st behavior, the NF consumer sends a GET request to a resource representing the UE's user permission information (subscriber information) and specifies the 31st information in the query parameters. Furthermore, if the NF consumer supports user permission at the data collection category or analytics category granularity indicated by the 31st information, the NF consumer may include the 71st information in the GET request. In addition, the NF consumer may set multiple uc-purpose and / or multiple 33rd information in a single query. Note that the resource representing the UE's user permission information (subscriber information) may be UcSubscriptionData, and the resource URI is {apiRoot} / nudm-sdm / <apiversion>It can be / {supi} / uc-data.

[0081] b) The 811th behavior in this embodiment is the behavior of the UDM in which it sends a response to the 81st behavior, which includes user permission information, to the NF consumer. In the 811th behavior, when the GET request shown in the 81st behavior is successful, the UDM responds with "200 OK", and the message body includes the user permission information of the requesting UE. The UE's user permission information may be set in UcSubscriptionData. The UE's user permission information may be set to "CONSENT_GIVEN" if permission is granted, and to "CONSENT_NOT_GIVEN" if permission is not granted. When the UDM receives the GET request shown in the 81st behavior and determines whether permission has been granted, it uses the value set in the 31st information as a query key. At this time, if the 31st information is set to "ANALYTICS" and data collection category information is also set, the UDM may use "ANALYTICS" and the data collection category information as query keys. Here, using "ANALYTICS" and the data collection category information as a query key may also mean concatenating "ANALYTICS" and the data collection category information as a string and using that as the query key. For example, if the 31st piece of information is set to "ANALYTICS" and the data collection category information is set to "LOCATION", the query key may be "ANALYTICS-LOCATION". Here, for the purpose of explaining string concatenation, the format shown is "ANALYTICS" followed by "-" and the data collection category information, but it is not limited to this format. Similarly, if the 31st piece of information is set to "ANALYTICS" and analysis category information is also set, the UDM may concatenate "ANALYTICS" and the analysis category information as a string and use that as the query key. Furthermore, if the 31st piece of information is "MODEL_TRAINING", the UDM may similarly concatenate the information contained in the 31st piece of information as a string and use that as the query key.For example, if the information in item 31 is set to "MODEL_TRAINING" and the data collection category information is set to "LOCATION", the query key may be "MODEL_TRAINING-LOCATION". Here, for the purpose of explaining string concatenation, the format shown is "MODEL_TRAINING" followed by "-" and the data collection category information, but it is not limited to this format. Similarly, if the information in item 31 is set to "MODEL_TRAINING" and analysis category information is also set, the UDM may concatenate "MODEL_TRAINING" and the analysis category information as a string and use it as the query key. The UDM will respond with "200 OK" including the query key and the user permission information pair associated with that query key. Note that if multiple query keys are set in the behavior of item 81, "200 OK" may include multiple pairs (pairs of query key and user permission information). For example, if the first query key is set to "ANALYTICS-LOCATION" and the second query key is set to "MODEL_TRAINING-LOCATION", and user permission is granted for the first query key but not for the second query key, the UDM may include "ANALYTICS-LOCATION: CONSENT_GIVEN" and "MODEL_TRAINING-LOCATION: CONSENT_NOT_GIVEN" in the "200 OK" response.

[0082] c) The UDM may perform the action described in paragraph 811 if the GET request contains the information described in paragraph 71, or if the resource accessed by the GET request contains user permission category information related to data collection or analytics. On the other hand, if the GET request does not contain the information described in paragraph 71, or if the resource accessed by the GET request does not contain user permission category information related to data collection or analytics, the UDM will not perform the action described in paragraph 811. Instead, the UDM may, based on the operator policy, exclude user permission information at the data collection category and / or analytics category granularity from "200OK", and include user permission information linked to the user permission purpose of the information described in paragraph 31 in "200OK". For example, if UDM manages user permission information for "ANALYTICS-LOCATION: CONSENT_GIVEN" and "ANALYTICS-AIR_INTERFACE: CONSENT_GIVEN", the user permission information to set to "200OK" may be "ANALYTICS: CONSENT_GIVEN".

[0083] d) The 812th behavior in this embodiment is the behavior in which the UDM sets the configuration information shown in Table 1a of Figure 16 or Table 1b of Figure 17, as described in the 101st behavior, to the NF consumer via the "200OK" response in the 81st behavior. If one or more of the following conditions are met, the GET request shown in the 81st behavior contains the information of the 71st behavior, the resource accessed by the GET request contains the configuration information, and the NF consumer does not have the configuration information set, the UDM may include the configuration information in the "200OK" response to the 81st behavior. The UDM may determine whether or not the NF consumer has the configuration information set based on the information of the 31st behavior. For example, if "LOCATION" is set in the information of the 31st behavior and the resource accessed by the GET request contains "LOCATION" and "AIR_INTERFACE" as configuration information, the UDM may include "LOCATION" and "AIR_INTERFACE" as configuration information in "200OK". Furthermore, if nothing is set in the 31st piece of information (the query parameter value is empty), the UDM may determine that no configuration information is set for the NF consumer and include all the configuration information contained in that resource in "200 OK". Note that the UDM may only perform this behavior if the GET request contains the 71st piece of information.

[0084] e) The NF consumer that has received the configuration information described in the behavior of section 812 may perform the behavior of section 81 based on the configuration information in the subsequent user permission information acquisition procedure (it may constitute the information of section 31).

[0085] f) The UDM may manage (define) user permissions for each data collection category or analysis category.

[0086] g) Up to this point, we have described the behavior for obtaining a single dataset (user permission information), but the NF consumer may be able to obtain multiple datasets in a single request. The following describes how to obtain user permission information using the method of obtaining multiple datasets in a single request. The NF consumer sends a GET request to the resource representing supi and specifies the 41st piece of information in the query parameters. Furthermore, the NF consumer may also specify the 31st piece of information in the query parameters. For example, if the 41st piece of information is set to "UC_CATEGORY" and the 31st piece of information is "ANALYTICS", the query parameters may be expressed as dataset-names=UC_CATEGORY&uc-purpose=ANALYTICS. The resource accessed in the GET request is "Supi", and the resource URI is "{apiRoot} / nudm-sdm / <apiversion>It may be / {supi}". Upon successful GET request, the UDM responds with "200 OK", and the message body includes the user permission information of the requesting UE. The UE's user permission information may be set in UcPrivacySubscriptionData or UcSubscriptionData contained in SubscriptionDataSets. The UDM may configure the user permission information to be included in "200 OK" in the manner described in the behavior of section 811.

[0087] h) According to the aforementioned technology, users, network operators, and countries can flexibly change the granularity (category) of user licenses managed by the UDM, and furthermore, they can set these changes in the NF consumer. As a result, it becomes possible to flexibly and appropriately reflect the user's intentions regarding user licenses, network operator policies, and national regulations.

[0088] (82nd Behavior) a) The 82nd behavior in this embodiment is the behavior in which the NF consumer sends a GET request to the UDM to obtain user permission information. In the 82nd behavior, the NF consumer sends a GET request to the UE's resource representing user permission information (subscriber information) and specifies uc-purpose in the query parameters. uc-purpose is defined in the data structure of UcPurpose and may be information indicating the purpose of obtaining user permission. Furthermore, the NF consumer may also specify the 32nd piece of information (uc-category) in the query parameters. Furthermore, if the NF consumer supports user permission at the data collection category or analytics category granularity indicated by the 32nd piece of information, it may include the 71st piece of information in the GET request. In addition, the NF consumer may set multiple uc-purposes and / or multiple pieces of the 32nd piece of information in a single query. For example, if the first uc-purpose is "A", the second uc-purpose is "B", and the third uc-purpose is "C", and the information for the first uc-purpose is "X", the information for the second uc-purpose is "" (meaning no query parameter value), and the information for the third uc-purpose is "Y", then the query parameter can be expressed as uc-purpose=A,B,C&uc-category=X,,Y. Note that the resource representing the user permission information (subscriber information) of the UE is "UcSubscriptionData", and the resource URI is "{apiRoot} / nudm-sdm / <apiversion>It may be " / {supi} / uc-data". Also, the 32nd piece of information may be set if uc-purpose is set as a query parameter. In other implementations, the 32nd piece of information may be set even if uc-purpose is not set as a query parameter.

[0089] b) The 821st behavior in this embodiment is the behavior of the UDM in which it sends a response to the 82nd behavior, which includes user permission information, to the NF consumer. In the 821st behavior, when the GET request shown in the 82nd behavior is successful, the UDM responds with "200 OK", and the message body includes the user permission information of the requesting UE. The UE's user permission information may be set in UcSubscriptionData. The UE's user permission information may be set to "CONSENT_GIVEN" if permission is granted, and to "CONSENT_NOT_GIVEN" if permission is not granted. When the UDM receives the GET request shown in the 82nd behavior and determines whether permission has been granted, it uses uc-purpose and the value set in the 32nd information as query keys. At this time, the UDM may concatenate uc-purpose and the 32nd information as a string and use it as a query key. For example, if uc-purpose is set to "ANALYTICS" and the data collection category information in item 32 is set to "LOCATION", the query key may be "ANALYTICS-LOCATION". Here, for the purpose of explaining string concatenation, the format shown is "ANALYTICS" followed by "-" and the data collection category information, but it is not limited to this format. Similarly, if uc-purpose is set to "ANALYTICS" and the analysis category information is set in item 32, the UDM may concatenate "ANALYTICS" and the analysis category information as a string and use it as the query key. Furthermore, if uc-purpose is "MODEL_TRAINING", the UDM may similarly concatenate uc-purpose and the information contained in item 32 as a string and use it as the query key. For example, if uc-purpose is set to "MODEL_TRAINING" and the data collection category information in item 32 is set to "LOCATION", the query key may be "MODEL_TRAINING-LOCATION". Here, for the purpose of explaining string concatenation, we have provided an example format where "MODEL_TRAINING" is followed by "-" and data collection category information, but this format is not the only option.Similarly, if uc-purpose is set to "MODEL_TRAINING" and analysis category information is also set, the UDM may concatenate "MODEL_TRAINING" and the analysis category information as a string and use it as a query key. The UDM will respond with "200 OK" including the query key and the user permission information associated with that query key as a pair. Note that if multiple query keys are set in the behavior described in Section 82, "200 OK" may include multiple pairs (pairs of query key and user permission information). For example, if the query parameter is indicated as uc-purpose=ANALYTICS,MODEL_TRAINING,MODEL_TRAINING&uc-category= LOCATION,, LOCATION, the UDM may use "ANALYTICS-LOCATION" as the first query key, "MODEL_TRAINING" as the second query key, and "MODEL_TRAINING-LOCATION" as the third query key. In this case, if user authorization is granted for the first query key, user authorization is granted for the second query key, and user authorization is not granted for the third query key, the UDM may include "ANALYTICS-LOCATION:CONSENT_GIVEN", "MODEL_TRAINING:CONSENT_GIVEN", and "MODEL_TRAINING-LOCATION:CONSENT_NOT_GIVEN" in "200 OK".

[0090] c) UDM may perform the action described in paragraph 821 if the GET request contains the information described in paragraph 71, or if the resource accessed by the GET request contains user permission category information related to data collection or analytics. On the other hand, if the GET request does not contain the information described in paragraph 71, or if the resource accessed by the GET request does not contain user permission category information related to data collection or analytics, UDM will not perform the action described in paragraph 821. Instead, UDM may, based on the operator policy, exclude user permission information at the data collection category and / or analytics category granularity from "200OK", and include user permission information linked to the user permission purpose of uc-purpose in "200OK". For example, if UDM manages user permission information for "ANALYTICS-LOCATION: CONSENT_GIVEN" and "ANALYTICS-AIR_INTERFACE: CONSENT_GIVEN", the user permission information to set to "200OK" may be "ANALYTICS: CONSENT_GIVEN".

[0091] d) The 822nd behavior in this embodiment is the behavior in which the UDM sets the configuration information shown in Table 1a of Figure 16 or Table 1b of Figure 17, as described in the 101st behavior, to the NF consumer via the "200OK" response in the 82nd behavior. If one or more of the following conditions are met, the GET request shown in the 82nd behavior contains the information of the 71st behavior, the resource accessed by the GET request contains the configuration information, and the NF consumer does not have the configuration information set, the UDM may include the configuration information in the "200OK" response to the 82nd behavior. The UDM may determine whether or not the NF consumer has the configuration information set based on the information of the 32nd behavior. For example, if "LOCATION" is set in the information of the 32nd behavior and the resource accessed by the GET request contains "LOCATION" and "AIR_INTERFACE" as configuration information, the UDM may include "LOCATION" and "AIR_INTERFACE" as configuration information in "200OK". Furthermore, if no information is set in item 32 (the query parameter value is empty), the UDM may determine that no configuration information is set for the NF consumer and include all configuration information contained in that resource in "200 OK". Note that the UDM may only perform this behavior if the GET request contains information 71.

[0092] e) An NF consumer that has received the configuration information described in the behavior of section 822 may perform the behavior of section 822 based on the configuration information in the subsequent user permission information acquisition procedure (it may constitute the information of section 32).

[0093] f) The UDM may manage (define) user permissions for each data collection category or analysis category.

[0094] g) Up to this point, we have described the behavior for obtaining a single dataset (user permission information), but the NF consumer may be able to obtain multiple datasets in a single request. The following describes how to obtain user permission information using a method that obtains multiple datasets in a single request. The NF consumer sends a GET request to the resource representing supi and specifies the 41st piece of information in the query parameters. Furthermore, the NF consumer may specify the uc-purpose and 42nd pieces of information in the query parameters. uc-purpose is defined in the data structure of UcPurpose and may be information indicating the purpose of obtaining user permission. For example, if the 41st piece of information is set to "UC_CATEGORY", the uc-purpose is set to "ANALYTICS", and the 42nd piece of information is "LOCATION", the query parameters may be expressed as dataset-names=UC_CATEGORY&uc-purpose=ANALYTICS&uc-category=LOCATION. Note that the resource accessed in the GET request is "Supi", and the resource URI is "{apiRoot} / nudm-sdm / <apiversion>It may be / {supi}". Upon successful GET request, the UDM responds with "200 OK", and the message body includes the user permission information of the requesting UE. The UE's user permission information may be set in UcPrivacySubscriptionData or UcSubscriptionData contained in SubscriptionDataSets. The UDM may configure the user permission information to be included in "200 OK" in the manner described in the behavior of section 821.

[0095] h) According to the aforementioned technology, users, network operators, and countries can flexibly change the granularity (category) of user licenses managed by the UDM, and furthermore, they can set these changes in the NF consumer. As a result, it becomes possible to flexibly and appropriately reflect the user's intentions regarding user licenses, network operator policies, and national regulations.

[0096] (83rd behavior) a) The 83rd behavior in this embodiment is the behavior in which the NF consumer sends a GET request to the UDM in order to obtain user consent information. In the 83rd behavior, the NF consumer sends a GET request to the UE's resource representing user consent information (subscriber information) and specifies uc-purpose in the query parameters. uc-purpose is defined in the data structure of UcPurpose and may be information indicating the purpose of obtaining user consent. Furthermore, the NF consumer may also specify the 33rd piece of information (uc-type) in the query parameters. Furthermore, if the NF consumer supports user consent for each type of information, such as whether the data collection or analytics indicated by the 33rd piece of information handles privacy information, it may also include the 71st piece of information. In addition, the NF consumer may set multiple uc-purposes and / or multiple pieces of the 33rd piece of information in a single query. For example, if the first uc-purpose is "A", the second uc-purpose is "B", and the third uc-purpose is "C", and the information for the first uc-purpose is "X", the information for the second uc-purpose is "" (meaning no query parameter value), and the information for the third uc-purpose is "Y", then the query parameter can be expressed as uc-purpose=A,B,C&uc-type=X,,Y. Note that the resource representing the user permission information (subscriber information) of the UE is "UcSubscriptionData", and the resource URI is "{apiRoot} / nudm-sdm / <apiversion>It may be " / {supi} / uc-data". Also, the 33rd piece of information may be set if uc-purpose is set as a query parameter. In other implementations, the 33rd piece of information may be set even if uc-purpose is not set as a query parameter.

[0097] b) The 831st behavior in this embodiment is the behavior of the UDM in which it sends a response to the 83rd behavior, which includes user permission information, to the NF consumer. In the 831st behavior, when the GET request shown in the 83rd behavior is successful, the UDM responds with "200 OK", and the message body includes the user permission information of the requesting UE. The UE's user permission information may be set in UcSubscriptionData. The UE's user permission information may be set to "CONSENT_GIVEN" if permission is granted, and to "CONSENT_NOT_GIVEN" if permission is not granted. When the UDM receives the GET request shown in the 83rd behavior and determines whether permission has been granted, it uses uc-purpose and the value set in the 33rd information as query keys. At this time, the UDM may concatenate uc-purpose and the 33rd information as a string and use it as a query key. For example, if uc-purpose is set to "ANALYTICS" and the 33rd piece of information is set to "PRIVACY" in order to collect or analyze privacy-related data, the query key may be "ANALYTICS-PRIVACY". If the 33rd piece of information is set to "NONPRIVACY" in order to collect or analyze non-privacy-related data, the query key may be "ANALYTICS-NONPRIVACY" or, as an exception, "ANALYTICS" alone if it is non-privacy-related. Here, for the purpose of explaining string concatenation, the format shown is "ANALYTICS" followed by "-" and the 33rd piece of information, but it is not limited to this format. Furthermore, if uc-purpose is "MODEL_TRAINING", the UDM may similarly concatenate uc-purpose and the information contained in the 33rd piece of information as a string and use it as the query key. For example, if uc-purpose is set to "MODEL_TRAINING" and further, information item 33 is set to "PRIVACY" in order to collect or analyze privacy-related data, the query key may be "MODEL_TRAINING-PRIVACY".If the information in item 33 is set to "NONPRIVACY" for collecting or analyzing non-privacy-related data, the query key may be "MODEL_TRAINING-NONPRIVACY" or, as an exception, "MODEL_TRAINING" only if it is non-privacy-related. Here, for the purpose of explaining string concatenation, the format shown is "MODEL_TRAINING" followed by "-" and the information in item 33, but it is not limited to this format. The UDM responds with "200 OK" including the query key and the user permission information pair associated with that query key. Note that if multiple query keys are set in the behavior of item 83, "200 OK" may include multiple pairs (pairs of query key and user permission information). For example, if the query parameters are specified as uc-purpose=ANALYTICS,MODEL_TRAINING,MODEL_TRAINING&uc-type=PRIVACY,,NON PRIVACY, the UDM may use "ANALYTICS-PRIVACY" as the first query key, "MODEL_TRAINING" as the second query key, and "MODEL_TRAINING-PRIVACY" as the third query key. In this case, if user permission is granted for the first query key, for the second query key, and not for the third query key, the UDM may include "ANALYTICS-PRIVACY:CONSENT_GIVEN", "MODEL_TRAINING:CONSENT_GIVEN", and "MODEL_TRAINING-PRIVACY:CONSENT_NOT_GIVEN" in the "200 OK" response.

[0098] c) UDM may perform the action described in paragraph 831 if the GET request contains the information described in paragraph 71, or if the resource accessed by the GET request contains type information indicating whether or not data collection or analytics handles private information. On the other hand, if the GET request does not contain the information described in paragraph 71, or if the resource accessed by the GET request does not contain type information indicating whether or not data collection or analytics handles private information, UDM will not perform the action described in paragraph 831. Instead, UDM may, based on the operator policy, not include user permission information at the type granularity of whether or not data collection or analytics handles private information in "200OK", but instead include user permission information linked to the user permission purpose of uc-purpose in "200OK". For example, if UDM manages user permission information for "ANALYTICS-PRIVACY: CONSENT_GIVEN" and "ANALYTICS-PRIVACY: CONSENT_GIVEN", the user permission information to set to "200OK" can be "ANALYTICS: CONSENT_GIVEN".

[0099] d) The 832nd behavior in this embodiment is the behavior in which the UDM sets the configuration information shown in Table 1a of Figure 16 or Table 1b of Figure 17, as described in the 102nd behavior, to the NF consumer via the "200OK" response in the 83rd behavior. If one or more of the following conditions are met, the GET request shown in the 83rd behavior contains the information of the 71st behavior, the resource accessed by the GET request contains the configuration information, and the NF consumer does not have the configuration information set, the UDM may include the configuration information in the "200OK" response to the 83rd behavior. In addition, if nothing is set in the information of the 33rd behavior (the query parameter value is empty), the UDM may determine that no configuration information is set to the NF consumer and include all the configuration information contained in the resource in the "200OK" response. Note that the UDM may only perform this behavior if the GET request contains the information of the 71st behavior.

[0100] e) The NF consumer that has received the configuration information described in the behavior of section 832 may perform the behavior of section 83 based on the configuration information in the subsequent user permission information acquisition procedure (it may constitute the information of section 33).

[0101] f) UDM may classify and manage (define) user permissions into two categories: privacy-related user permissions and non-privacy-related user permissions.

[0102] g) Up to this point, we have described the behavior for obtaining a single dataset (user permission information), but the NF consumer may be able to obtain multiple datasets in a single request. The following describes how to obtain user permission information using a method that obtains multiple datasets in a single request. The NF consumer sends a GET request to the resource representing supi and specifies the 41st piece of information in the query parameters. Furthermore, the NF consumer may specify the uc-purpose and 43rd pieces of information in the query parameters. uc-purpose is defined in the data structure of UcPurpose and may be information indicating the purpose of obtaining user permission. For example, if the 41st piece of information is set to "UC_TYPE", the uc-purpose is set to "ANALYTICS", and the 43rd piece of information is "PRIVACY", the query parameters may be expressed as dataset-names=UC_CATEGORY&uc-purpose=ANALYTICS&uc-type=PRIVACY. Note that the resource accessed in the GET request is "Supi", and the resource URI is "{apiRoot} / nudm-sdm / <apiversion>It may be / {supi}". Upon successful GET request, the UDM responds with "200 OK", and the message body includes the user permission information of the requesting UE. The UE's user permission information may be set in UcPrivacySubscriptionData or UcSubscriptionData contained in SubscriptionDataSets. The UDM may configure the user permission information to be included in "200 OK" in the manner described in the behavior of Section 841.

[0103] h) According to the aforementioned technology, users, network operators, and countries can flexibly modify user permissions, which are categorized and managed in the UDM as either privacy-related or non-privacy-related (assigning each data collection and analytics category to either privacy-related or non-privacy-related), and can also set these changes in the NF consumer. As a result, it becomes possible to flexibly and appropriately reflect the user's intentions regarding user permissions, network operator policies, and national regulations.

[0104] (84th behavior) a) The 84th behavior in this embodiment is the behavior in which the NF consumer sends a GET request to the UDM in order to obtain user consent information. In the 84th behavior, the NF consumer sends a GET request to the UE's resource representing user consent information (subscriber information) and specifies uc-purpose in the query parameters. uc-purpose is defined in the data structure of UcPurpose and may be information indicating the purpose of obtaining user consent. Furthermore, the NF consumer may also specify the 34th piece of information (uc-privacyindicator) in the query parameters. Furthermore, if the NF consumer supports user consent for each identifier indicating whether the data collection or analytics indicated by the 34th piece of information handles privacy information, it may also include the 71st piece of information. In addition, the NF consumer may set multiple uc-purposes and / or multiple pieces of the 34th piece of information in a single query. For example, if the first uc-purpose is "A", the second uc-purpose is "B", and the third uc-purpose is "C", and the information for the 34th of the first is "X", the information for the 34th of the second is "" (meaning no query parameter value), and the information for the 34th of the third is "Y", then the query parameter can be expressed as uc-purpose=A,B,C&uc-privacyindicator=X,,Y. Note that the resource representing the user permission information (subscriber information) of the UE is "UcSubscriptionData", and the resource URI is "{apiRoot} / nudm-sdm / <apiversion>It may be " / {supi} / uc-data". Also, the 34th piece of information may be set if uc-purpose is set as a query parameter. In other implementations, the 34th piece of information may be set even if uc-purpose is not set as a query parameter.

[0105] b) The 841st behavior in this embodiment is the behavior of the UDM in which it sends a response to the 84th behavior, which includes user permission information, to the NF consumer. In the 841st behavior, when the GET request shown in the 84th behavior is successful, the UDM responds with "200 OK", and the message body includes the user permission information of the requesting UE. The UE's user permission information may be set in UcSubscriptionData. The UE's user permission information may be set to "CONSENT_GIVEN" if permission is granted, and to "CONSENT_NOT_GIVEN" if permission is not granted. When the UDM receives the GET request shown in the 84th behavior and determines whether permission has been granted, it determines whether uc-purpose intends to handle privacy-related information based on the information in the 34th, and uses uc-purpose as a query key. For example, the UDM may determine that uc-purpose intends to handle privacy-related information if the information in the 34th is set to "True". If the information in item 34 is set to "False", the UDM may determine that uc-purpose does not intend to handle privacy-related information. Based on the information in item 34, the UDM determines whether or not it intends to handle privacy-related information and responds with "200 OK" including the query key and the user permission information associated with that query key. In this case, if the determination based on the information in item 34 determines that it intends to handle privacy-related information, the user permission information associated with the query key may be user permission information related to the handling of privacy-related information. If the determination based on the information in item 34 determines that it does not intend to handle privacy-related information, the user permission information associated with the query key may be user permission information not limited to the handling of privacy-related information. The UDM responds with "200 OK" including the query key and the user permission information associated with that query key. Note that if multiple query keys are set in the behavior of item 84, "200 OK" may include multiple pairs (pairs of query key and user permission information).For example, if the query parameters are specified as uc-purpose=ANALYTICS,MODEL_TRAINING,MODEL_TRAINING&uc-privacyindicator=FALSE,,TRUE, the UDM may use "ANALYTICS" as the first query key, "MODEL_TRAINING" as the second query key, and "MODEL_TRAINING" as the third query key. Furthermore, the UDM determines that the first query key is a non-privacy-related user consent acquisition because uc-privacyindicator is FALSE, and that the third query key is a privacy-related user consent acquisition because uc-privacyindicator is TRUE. For the second query key, since uc-privacyindicator is empty, the UDM may determine whether it is privacy-related or not based on the operator policy (here, it is exemplified as non-privacy-related). In this case, if user permission is granted for the first query key, user permission is granted for the second query key, and user permission is not granted for the third query key, the UDM may include "ANALYTICS: CONSENT_GIVEN", "MODEL_TRAINING: CONSENT_GIVEN", and "MODEL_TRAINING: CONSENT_NOT_GIVEN" in "200 OK". At this time, the UDM may be configured to identify whether each user permission information is privacy-related or not. For example, user permission information for the first and second query keys may be included in the non-privacy attribute, and user permission information for the third query key may be included in the privacy attribute.

[0106] c) UDM may perform the action described in paragraph 841 if the GET request contains the information described in paragraph 71, or if the resource accessed by the GET request contains identification information indicating whether or not data collection or analytics handles private information. On the other hand, if the GET request does not contain the information described in paragraph 71, or if the resource accessed by the GET request does not contain identification information indicating whether or not data collection or analytics handles private information, UDM will not perform the action described in paragraph 841. Instead, UDM may, based on the operator policy, not include user permission information at the granularity of whether or not data collection or analytics handles private information in "200OK", but instead include user permission information linked to the user permission purpose of uc-purpose in "200OK". For example, if UDM manages user permission information for "ANALYTICS-PRIVACY: CONSENT_GIVEN" and "ANALYTICS-PRIVACY: CONSENT_GIVEN", the user permission information to set to "200OK" can be "ANALYTICS: CONSENT_GIVEN".

[0107] d) The 842nd behavior in this embodiment is the behavior in which the UDM sets the configuration information shown in Table 3a of Figure 20 or Table 3b of Figure 21, as described in the 103rd behavior, to the NF consumer via the "200OK" response in the 84th behavior. If one or more of the following conditions are met, the GET request shown in the 84th behavior contains the information of the 71st behavior, the resource accessed by the GET request contains the configuration information, and the NF consumer does not have the configuration information set, the UDM may include the configuration information in the "200OK" response to the 84th behavior. In addition, if nothing is set in the information of the 34th behavior (the query parameter value is empty), the UDM may determine that no configuration information is set to the NF consumer and include all the configuration information contained in the resource in the "200OK" response. Note that the UDM may only perform this behavior if the GET request contains the information of the 71st behavior.

[0108] e) The NF consumer that has received the configuration information described in the behavior of section 842 may perform the behavior of section 84 based on the configuration information in the subsequent user permission information acquisition procedure (it may constitute the information of section 34).

[0109] f) UDM may classify and manage (define) user permissions into two categories: privacy-related user permissions and non-privacy-related user permissions.

[0110] g) Up to this point, we have described the behavior for obtaining a single dataset (user permission information), but an NF consumer may be able to obtain multiple datasets in a single request. The following describes how to obtain user permission information using a method that obtains multiple datasets in a single request. The NF consumer sends a GET request to the resource representing supi and specifies the 41st piece of information in the query parameters. Furthermore, the NF consumer may specify the uc-purpose and 44th pieces of information in the query parameters. uc-purpose is defined in the data structure of UcPurpose and may be information indicating the purpose of obtaining user permission. For example, if the 41st piece of information is set to "UC_PRIVACY", uc-purpose is set to "ANALYTICS", and the 44th piece of information is "TRUE", the query parameters may be expressed as dataset-names=UC_CATEGORY&uc-purpose=ANALYTICS&uc-privacyindicator=TRUE. Note that the resource accessed in the GET request is "Supi", and the resource URI is "{apiRoot} / nudm-sdm / <apiversion>It may be / {supi}". Upon successful GET request, the UDM responds with "200 OK", and the message body includes the user permission information of the requesting UE. The UE's user permission information may be set in UcPrivacySubscriptionData or UcSubscriptionData contained in SubscriptionDataSets. The UDM may configure the user permission information to be included in "200 OK" in the manner described in the behavior of Section 851.

[0111] h) According to the aforementioned technology, users, network operators, and countries can flexibly modify user permissions, which are categorized and managed in the UDM as either privacy-related or non-privacy-related (assigning each data collection and analytics category to either privacy-related or non-privacy-related), and can also set these changes in the NF consumer. As a result, it becomes possible to flexibly and appropriately reflect the user's intentions regarding user permissions, network operator policies, and national regulations.

[0112] (Behavior 85) a) Behavior 85 in this embodiment is the behavior in which the NF consumer sends a GET request to the UDM in order to obtain user permission information. In behavior 85, the NF consumer sends a GET request to the resource representing the UE's user permission information (subscriber information) and specifies uc-purpose in the query parameters. uc-purpose is defined in the data structure of UcPurpose and may be information indicating the purpose of obtaining user permission. Furthermore, the NF consumer may include the information from section 71 in the GET request. Note that in the explanations of behaviors 81 to 84 so far, user permission information has been obtained using a single resource (UcSubscriptionData) regardless of whether it is privacy-related or not, but in behavior 85, privacy-related and non-privacy-related resources are defined separately, and this explanation will focus on privacy-related resources. The resource representing the UE's user permission information (subscriber information) is UcPrivacySubscriptionData as a resource for obtaining privacy-related user permission information, and the resource URI is {apiRoot} / nudm-sdm / <apiversion>It may be / {supi} / uc-privacy-data. UcPrivacySubscriptionData may be defined as a data structure called UcPrivacySubscriptionData. For example, UcPrivacySubscriptionData is an object that contains user consent data related to privacy, and has a property called consentCategoryList defined within it. consentCategoryList is an array that stores a list of privacy consent categories and must contain at least one category.

[0113] b) The 851st behavior in this embodiment is the behavior of the UDM in which it sends a response to the 85th behavior, which includes user permission information, to the NF consumer. In the 851st behavior, when the GET request shown in the 85th behavior is successful, the UDM responds with "200 OK", and the message body includes the user permission information of the requesting UE. The UE's user permission information may be set in UcPrivacySubscriptionData. The UE's user permission information may be set to "CONSENT_GIVEN" if permission is granted, and to "CONSENT_NOT_GIVEN" if permission is not granted. When the UDM receives the GET request shown in the 85th behavior and determines whether permission has been granted, it uses uc-purpose as the query key. The UDM responds with "200 OK", including the query key and the pair of user permission information associated with the query key. Furthermore, if multiple query keys are set in the behavior described in section 85, "200 OK" may include multiple pairs (pairs of query key and user permission information). For example, if the query keys are set to "ANALYTICS" and "MODEL_TRAINING", and user permission is granted for "ANALYTICS" but not for "MODEL_TRAINING", the UDM may include "ANALYTICS: CONSENT_GIVEN" and "MODEL_TRAINING: CONSENT_NOT_GIVEN" in "200 OK".

[0114] d) The 852nd behavior in this embodiment is the behavior in which the UDM sets the configuration information shown in Table 4a of Figure 22 or Table 4b of Figure 23, as described in the 104th behavior, to the NF consumer via the "200OK" response in the 85th behavior. The UDM may include the configuration information in the "200OK" response to the 85th behavior if one or more of the following conditions are met: the GET request shown in the 85th behavior contains the information of the 71st behavior, and the resource accessed by the GET request contains the configuration information. The UDM may perform this behavior only if the GET request contains the information of the 71st behavior.

[0115] e) An NF consumer that has received the configuration information described in the behavior of section 852 may perform the behavior of section 85 based on the configuration information in the subsequent user permission information acquisition procedure.

[0116] f) UDM may classify and manage (define) user permissions into two categories: privacy-related user permissions and non-privacy-related user permissions.

[0117] g) Up to this point, we have described the behavior for obtaining a single dataset (user permission information), but the NF consumer may be able to obtain multiple datasets in a single request. The following describes how to obtain user permission information using the method of obtaining multiple datasets in a single request. The NF consumer sends a GET request to the resource representing supi and specifies the 41st piece of information in the query parameters. Furthermore, the NF consumer may specify uc-purpose in the query parameters. For example, if the 41st piece of information is set to "UC_PRIVACY" and uc-purpos is "ANALYTICS", the query parameters may be expressed as dataset-names=UC_PRIVACY&uc-purpose=ANALYTICS. The resource accessed in the GET request is "Supi", and the resource URI is "{apiRoot} / nudm-sdm / <apiversion>It may be / {supi}". When a GET request is successful, the UDM responds with "200 OK", and the message body contains the user permission information of the requesting UE. The UE's user permission information may be set in UcPrivacySubscriptionData or UcSubscriptionData contained in SubscriptionDataSets. The UDM may configure the user permission information to be included in "200 OK" using any one of the methods described in behaviors 811 to 851.

[0118] h) According to the aforementioned technology, by separating and managing privacy-related resources in the UDM from non-privacy-related resources, it becomes possible to flexibly and appropriately reflect user consent regarding privacy-related user permissions, network operator policies, and national regulations.

[0119] (Behavior 91) Behavior 91 in this embodiment is the behavior in which the NF consumer obtains a "token" from the authorization server before using the services provided by the Nudm_SDM API. In Behavior 91, the NF consumer calls the access token request service using the procedure specified in Chapter 5.4.2.2 of 3GPP TS 29.510. At this time, the NF consumer may set "nudm-sdm:uc-data-privacy:read" as the scope information. Setting this scope information may mean obtaining authorization (token) to perform one or more of the behaviors 81 to 85, or it may mean access to read User Consent Privacy data. The NF consumer may be a Nudm consumer and may be, but is not limited to, NWDAF, DCCF, NEF, trusted AF, AMF, SMF, PCF, LMF, or EIF (Energy Information Function).

[0120] (Behavior 101 to Behavior 104): This section describes the procedure by which the NF collects data from other entities, which is the discrimination logic for obtaining user authorization information. An NF may be, for example, NWDAF, DCCF, NEF, trusted AF, AMF, SMF, or PCF. Hereafter, for explanatory purposes, such NFs will be referred to as NWDAF. Other entities may be other NFs, OAM, or UE Application. Other NFs may be any of AMF, SMF, PCF, UDM, NEF, AF, NRF, NSACF, UPF, SCP, and LMF, and are not limited to these.

[0121] NWDAF sends a subscribe request or data retrieval request to a Service provided by another Entity in order to collect data. In this case, NWDAF may specify the data to be collected (required data) in the subscribe request or data retrieval request. For example, if the data to be collected is "Average Speed," NWDAF sends a subscribe request or data retrieval request to another Entity, such as AF or NEF. In this case, NWDAF may specify "Average Speed" in the subscribe request or data retrieval request (23288 Table 6.5.2-4, 29517 Table 5.6.2.22-1: Definition of type PerUeAttribute).

[0122] When collecting data, NWDAF verifies whether the data to be collected is user-related (i.e., related to SUPI or GPSI) and obtains user consent information from the UDM.

[0123] In the procedure for obtaining the user's permission information, one or more of the following behaviors, from behavior 101 to behavior 104, may be performed.

[0124] (Behavior 101) Behavior 101 in this embodiment is the behavior in which NWDAF determines the information to be set in the query parameters when sending a GET request to the UDM in order to obtain user consent information. In behavior 101, NWDAF determines the category information of information 31 and information 32 based on the data to be collected and the Analytics ID when setting information 31 in behavior 81 and when setting information 31 in behavior 82. For example, if the data to be collected is "Average Speed", the category information may be information representing "Average Speed".

[0125] As an example of how category information can be determined, NWDAF checks whether the data to be collected is included in "Data" in Table 1a of Figure 16. If the data to be collected is included in "Data" in Table 1a, the "Category" in Table 1a for that data may be used to determine the category information of the data to be collected. For example, if the data to be collected is "Service Experience", the category information may be "COMMUNICATION".

[0126] Another example of how category information can be determined is that NWDAF checks if the Analytics ID specified by the Nnwdaf consumer is included in "Analytics (ID)" in Table 1b of Figure 17. If the Analytics ID is included in "Analytics (ID)" in Table 1b, the "Category" in Table 1b for that Analytics ID may be used to determine the category information for that Analytics ID. For example, if the data to be collected is "SLICE_LOAD_LEVEL", the category information may be "Network Resource Utilization and Load".

[0127] When NWDAF performs the 81st behavior or the 82nd behavior, it may set the category information determined here as the 31st information in the 81st behavior and as the 32nd information in the 82nd behavior.

[0128] Furthermore, Table 1a in Figure 16 and Table 1b in Figure 17, as described here, may be flexibly configured, modified / updated, and deleted, as explained in the behaviors described in section 81 and 82.

[0129] (Behavior 102) Behavior 102 in this embodiment refers to the behavior in which NWDAF determines the information to be set in the query parameters when sending a GET request to the UDM to obtain user consent information. In behavior 102, NWDAF determines the type of information for the third item based on the data to be collected and the Analytics ID, in setting the information for the third item in behavior 83. For example, if the data to be collected is "Average Speed" and is treated as privacy-related data, the type of information may be "PRIVACY".

[0130] As an example of how to determine type information, NWDAF checks whether the data to be collected is included in "Data" in Table 2a of Figure 18. If the data to be collected is included in "Data" in Table 2a, the "Type" in Table 2a for the corresponding data to be collected may be used to determine the type information of the data to be collected. For example, if the data to be collected is "Service Experience", the type information may be "PRIVACY".

[0131] Another example of how to determine type information is that NWDAF checks whether the Analytics ID specified by the Nnwdaf consumer is included in "Analytics (ID)" in Table 2b of Figure 19. If the Analytics ID is included in "Analytics (ID)" in Table 2b, the "Type" in Table 2b for that Analytics ID may be used to determine the type information of the Analytics ID. For example, if the data to be collected is "SLICE_LOAD_LEVEL", the type information may be "PRIVACY".

[0132] When NWDAF performs the 83rd action, it may set the type information determined here into the 33rd information.

[0133] Furthermore, Table 2a in Figure 18 and Table 2b in Figure 19, as described here, may be flexibly configured, modified / updated, and deleted, as explained in the behavior section 83.

[0134] (Behavior 103) Behavior 103 in this embodiment is the behavior in which NWDAF determines the information to be set in the query parameters when it sends a GET request to the UDM in order to obtain user consent information. In behavior 103, NWDAF determines the identification information of information 34 based on the data to be collected and the Analytics ID when setting information 34 in behavior 84. For example, if the data to be collected is "Average Speed" and is treated as privacy-related data, the identification information may be "TRUE".

[0135] As an example of how to determine the identification information, NWDAF checks whether the data to be collected is included in "Data" in Table 3a of Figure 20. If the data to be collected is included in "Data" in Table 3a, the "Privacy" column in Table 3a for the data to be collected may be used as the identification information for that data. For example, if the data to be collected is "Service Experience", the identification information may be "TRUE".

[0136] Another example of how to determine identification information is that NWDAF checks if the Analytics ID specified by the Nnwdaf consumer is included in "Analytics (ID)" in Table 3b of Figure 21. If the Analytics ID is included in "Analytics (ID)" in Table 3b, the "Privacy" column in Table 3b for that Analytics ID may be used as the identification information for the Analytics ID. For example, if the data to be collected is "SLICE_LOAD_LEVEL", the identification information may be "TRUE".

[0137] When NWDAF performs the 84th action, it may set the identification information determined here as the 34th information.

[0138] Furthermore, as explained in Figure 20, Table 3a, and Figure 21, Table 3b, can be flexibly configured, modified / updated, and deleted, as described in Section 84, Behavior.

[0139] (Behavior 104) Behavior 104 in this embodiment is the behavior in which the NWDAF determines the information to be set in the query parameters when sending a GET request to the UDM in order to obtain user consent information. In behavior 104, the NWDAF determines the data to be collected and the resources for obtaining user consent information as described in behavior 85, based on the Analytics ID. For example, if the data to be collected is "Average Speed" and is determined to be privacy-related, the NWDAF may access the privacy-related user consent information resources.

[0140] As an example of this determination method, NWDAF checks whether the data to be collected is included in Table 4a in Figure 22. If the data to be collected is included in Table 4a, it can be determined to be privacy-related.

[0141] Another example of this determination method is that NWDAF checks whether the Analytics ID specified by the Nnwdaf consumer is included in Table 4b. If the Analytics ID is included in Table 4b in Figure 23, it can be determined that it is privacy-related.

[0142] When performing the action described in section 85, NWDAF may perform the action described in section 85 based on the determination described above. For example, if it is determined that the action is privacy-related, NWDAF may specify UcPrivacySubscriptionData as the resource for obtaining user consent information, as described in the action described in section 85. On the other hand, if it is determined that the action is not privacy-related, NWDAF may specify UcSubscriptionData as the resource for obtaining user consent information.

[0143] Furthermore, Table 4a in Figure 22 and Table 4b in Figure 23, as described here, may be flexibly configured, modified / updated, and deleted, as explained in the behavior section 85.

[0144] (Information 31-34) This section describes the information used in the Nudm user authorization information acquisition procedure (Information 31-34, Information 41-44). Hereinafter, the NF consumer may be a Nudm cosnumer and may be, but is not limited to, any of NWDAF, DCCF, NEF, trusted AF, AMF, SMF, PCF, LMF, or EIF (Energy Information Function).

[0145] (Information No. 31) Information No. 31 in this embodiment is information indicating the user licensing purpose to be included when the NF consumer obtains user licensing information from the UDM. Information No. 31 may be denoted as uc-purpose and may be defined as a data structure called UcPurpose. UcPurpose may be defined as a data structure, for example, as follows. UcPurpose is an object that indicates the purpose of user licensing and may consist mainly of two elements. One is ucPurposeType, which is a string that identifies the purpose of user licensing. This corresponds to one of four types of purposes: ANALYTICS, MODEL_TRAINING, NW_CAP_EXPOSURE, and EDGEAPP_UE_LOCATION. The other element is purposeDetails, which is an object that contains detailed information for each purpose. Here, either AnalyticsCategories or ModelTrainingCategories can be specified, and category information corresponding to each purpose can be described. AnalyticsCategories defines categories specifically for analytical purposes and includes DataCategories (user data categories) and AnalyticIdCategories (analysis ID categories). On the other hand, ModelTrainingCategories relates to model training purposes and includes TrainingIdCategories in addition to DataCategories, indicating categories for the training process such as "neural network training" and "hyperparameter tuning." DataCategories are commonly used data categories and may represent Category information in Table 1a of Figure 16, such as user terminal (UE) location information, communication information, wireless interface information, and energy information. AnalyticIdCategories may represent Category information in Table 1b of Figure 17, such as "network resource usage," "user behavior and movement patterns," "quality of service and QoE," and "abnormal behavior and troubleshooting."By using the data structure definition described above, category information for data collection and analysis requiring user permission can be set. If the user permission purpose for the 31st piece of information is "ANALYTICS", then any of the values ​​defined in the data collection category definition (e.g., "DataCategories") may be set as the data collection category information. For example, "LOCATION" may be set to indicate a data classification related to user location information, and "AIR_INTERFACE" may be set to indicate a data classification related to wireless interface information. Furthermore, any of the values ​​defined in the analysis category definition (e.g., "AnalyticIdCategories") may be set as the analysis category information. For example, "User Behavior and Mobility" may be set to indicate an analysis of user behavior patterns and movement information. Similarly, if the user permission purpose for the 31st piece of information is "MODEL_TRAINING", then category information for data collection and analysis requiring user permission can also be set.

[0146] (Information No. 32) In this embodiment, Information No. 32 is category information related to user permission that the NF consumer includes when it obtains user permission information from the UDM. Information No. 32 may be denoted as uc-category and may be defined as UcCategory in its data structure. UcPurpose may be defined as follows, for example. UcCategory is an enumeration of strings representing categories subject to user permission and may represent the Data / Information information shown in Table 1a of Figure 16 and / or the Data / Information information shown in Table 1b of Figure 17. Note that UcCategory may be information that becomes valid when UcPurpose is specified. The above-described data structure definition may mean that category information for data collection and analytics that require user permission can be set using Information No. 32. If uc-purpose is "ANALYTICS", then the 32nd piece of information may also be set as data collection category information, using any of the values ​​defined by the data collection category definition (e.g., "DataCategories"). For example, "LOCATION" may be set to indicate data classification related to user location information, and "AIR_INTERFACE" may be set to indicate data classification related to wireless interface information. Furthermore, the 32nd piece of information may also be set as analysis category information, using any of the values ​​defined by the analysis category definition (e.g., "AnalyticIdCategories"). For example, "User Behavior and Mobility" may be set to indicate analysis of user behavior patterns and movement information. Similarly, if uc-purpose is "MODEL_TRAINING", the 32nd piece of information may also be set as category information for data collection and analysis that require user permission.Similarly, if uc-purpose is anything other than "ANALYTICS" or "MODEL_TRAINING," the category information for data collection and analysis requiring user permission can be set in the information in section 32.

[0147] (Information No. 33) Information No. 33 in this embodiment is type information regarding user permission to be included when the NF consumer obtains user permission information from the UDM. Information No. 33 may be denoted as uc-type and may be defined as UcType in the data structure. UcType may be defined as a data structure that allows for the specification of NONPRIVACY or PRIVACY as a value, for example. The above-described data structure definition may mean that information No. 33 can be used to set type information regarding whether data collection or analytics that require user permission will handle privacy information. For example, if uc-purpose is "ANALYTICS" and privacy-related data such as user location information is collected, Information No. 33 may be set to "PRIVACY". Similarly, if privacy-related analysis such as user behavior patterns or movement information is performed, Information No. 33 may also be set to "PRIVACY". Similarly, if uc-purpose is "MODEL_TRAINING", the type of data collection and analytics that require user consent may be set in the 33 information to indicate whether or not they handle private information. Similarly, if uc-purpose is anything other than "ANALYTICS" or "MODEL_TRAINING", the type of data collection and analytics that require user consent may be set in the 33 information.

[0148] (Information No. 34) Information No. 34 in this embodiment is user permission identification information to be included when the NF consumer obtains user permission information from the UDM. Information No. 34 may be denoted as uc-privacyindicator and may be defined as UcPrivacyIndicator in the data structure. UcPrivacyIndicator may be defined as a Boolean value (true or false) indicating whether the subject of user permission is privacy-related information. The above-described data structure definition may mean that whether or not to handle data collection or analytics privacy information that requires user permission can be set with Information No. 34. In other words, Information No. 34 may mean that user permission regarding the handling of privacy information in the user permission purpose set in uc-purpose can be obtained. For example, if uc-purpose is "ANALYTICS" and privacy-related data such as the user's location information is to be collected, Information No. 34 may be set to "True". Furthermore, if privacy-related analysis such as user behavior patterns and movement information is performed, the 34th piece of information may also be set to "True". Similarly, if uc-purpose is "MODEL_TRAINING", the 34th piece of information may be used to set whether data collection and analysis requiring user consent handle privacy information. Similarly, if uc-purpose is anything other than "ANALYTICS" or "MODEL_TRAINING", the 34th piece of information may be used to set whether data collection and analysis requiring user consent handle privacy information.

[0149] (Information No. 41) Information No. 41 in this embodiment may be information set as a query parameter when an NF consumer obtains user permission information by utilizing a method that obtains multiple datasets in a single request. The NF consumer specifies the names of the datasets to be obtained to be included in the GET request. The dataset name for user permission information described in behaviors No. 81 and No. 82 may be "UC_CATEGORY", the dataset name for user permission information described in behavior No. 83 may be "UC_TYPE" or "UC_PRIVACY", and the dataset name for user permission information described in behaviors No. 84 and No. 85 may be "UC_PRIVACY". For example, when specifying the dataset name representing UE access and mobility subscriber data and the dataset name for user permission information described in behavior No. 84 in the query parameters of a GET request, it may be expressed as dataset-names=AM,UC_PRIVACY. Information No. 41 may be defined in the data structure as DataSetName (dataset name). DataSetName may be a string indicating the name of the dataset to be retrieved, and may, for example, be a list of several values, including information such as UC_CATEGORY, UC_TYPE, and UC_PRIVACY. Note that the dataset name related to user consent information described in Behavior 81 to Behavior 85 may mean User Consent Data or User Consent Privacy Data.

[0150] (Information No. 42) Information No. 42 in this embodiment is category information regarding user consent to be included when the NF consumer obtains user consent information from the UDM. Information No. 42 may be denoted as uc-category. Information No. 42 may be set when the query parameter is set to "User Consent Data" and / or "User Consent Privacy Data" as indicated by Information No. 41. Information No. 42 may be defined in the data structure as DataSetName. For example, DataSetName may be a string indicating the name of the dataset to be obtained, and several values ​​may be listed, including the Category information of Table 1a in Figure 16 and / or the Category information of Table 1b in Figure 17. Note that the dataset name for "User Consent Data" may be "UC".

[0151] (Information No. 43) Information No. 43 in this embodiment is user consent type information to be included when the NF consumer obtains user consent information from the UDM. Information No. 43 may be denoted as uc-type. Information No. 43 may be set when "User Consent Data" and / or "User Consent Privacy Data" indicated by Information No. 41 are set in the query parameters. Information No. 43 may be defined in the data structure as DataSetName. For example, DataSetName may be a string indicating the name of the dataset to be obtained, and several values ​​may be listed, including NONPRIVACY and PRIVACY. Note that the dataset name for "User Consent Data" may be "UC".

[0152] (Information No. 44) Information No. 44 in this embodiment is user consent identification information to be included when the NF consumer obtains user consent information from the UDM. Information No. 44 may be denoted as uc-privacyindicator. Information No. 44 may be set when the query parameter is set to "User Consent Data" and / or "User Consent Privacy Data" as indicated by Information No. 41. Information No. 44 may be defined in the data structure as DataSetName. For example, DataSetName may be a string indicating the name of the dataset to be obtained, and may include a list of several values, including a boolean value (true and false) indicating whether or not it is privacy-related information. Note that the dataset name for "User Consent Data" may be "UC".

[0153] (Information No. 71) The information No. 71 in this embodiment may be user license-related feature support information ("Feature") that the NF consumer includes when obtaining user license information from the UDM, and may be specified in "supported-features" included in the GET request of the Nudm user license information acquisition procedure (behavior No. 81 to behavior No. 85), and the feature name may be displayed as "UCExt". For example, if the NF consumer supports the feature, the GET request may be set to "supported-features=UCExt". The NF consumer may be a Nudm cosnumer, and may be any of NWDAF, DCCF, NEF, trusted AF, AMF, SMF, PCF, LMF, or EIF (Energy Information Function), but is not limited to these.

[0154] By the method described above, a mechanism can be introduced to reflect the user's intentions in user permission for data use in wireless communication networks.

[0155] (Device Configuration) Next, an example of the functional configuration of the base station 10, network node 30, and terminal 20 that perform the processing and operations described above will be explained. The base station 10, network node 30, and terminal 20 include the functions to perform the embodiments described above. However, the base station 10, network node 30, and terminal 20 may each be equipped with only some of the functions in the embodiments.

[0156] <Base Station 10 and Network Node 30> Figure 24 shows an example of the functional configuration of a base station 10 and a network node 30. As shown in Figure 24, the base station 10 has a transmitting unit 110, a receiving unit 120, a setting unit 130, and a control unit 140. The functional configuration shown in Figure 24 is merely an example. The functional classifications and names of the functional units can be anything as long as they can perform the operations according to the embodiment of the present invention. The network node 30 may have the same functional configuration as the base station 10. Furthermore, a network node 30 having multiple different functions on the system architecture may be composed of multiple network nodes 30 separated by function.

[0157] The transmitting unit 110 includes the function of generating a signal to be transmitted to the terminal 20 or other network node 30 and transmitting the signal by wire or wireless. The receiving unit 120 includes the function of receiving various signals transmitted from the terminal 20 or other network node 30 and obtaining information from the received signal, for example, information from a higher layer. A communication unit including the transmitting unit 110 and the receiving unit 120 may be configured.

[0158] The setting unit 130 stores pre-configured setting information and various setting information to be transmitted to the terminal 20 in a storage device, and reads them from the storage device as needed.

[0159] The control unit 140 performs the processes described in the embodiment. The control unit 140 also performs processing related to communication with the terminal 20. The signal transmission function unit of the control unit 140 may be included in the transmission unit 110, and the signal reception function unit of the control unit 140 may be included in the reception unit 120.

[0160] <Terminal 20> Figure 25 is a diagram showing an example of the functional configuration of terminal 20. As shown in Figure 25, terminal 20 has a transmitting unit 210, a receiving unit 220, a setting unit 230, and a control unit 240. The functional configuration shown in Figure 25 is merely an example. Any functional classification and name of functional unit is acceptable as long as it can perform the operations according to the embodiment of the present invention. Furthermore, the communication device that becomes the resource holder 20 may have a functional configuration similar to that of terminal 20.

[0161] The transmitting unit 210 creates a transmission signal from the transmission data and transmits the transmission signal wirelessly. The receiving unit 220 wirelessly receives various signals and obtains signals from higher layers from the received physical layer signals. The receiving unit 220 also has the function of receiving control signals or reference signals transmitted from the network node 30. A communication unit including the transmitting unit 210 and the receiving unit 220 may be configured.

[0162] The setting unit 230 stores various setting information received from the network node 30 by the receiving unit 220 in its storage device and reads it from the storage device as needed. The setting unit 230 also stores pre-configured setting information.

[0163] The control unit 240 performs the processing described in the embodiment. The signal transmission function in the control unit 240 may be included in the transmission unit 210, and the signal reception function in the control unit 240 may be included in the reception unit 220.

[0164] (Hardware Configuration) The block diagrams (Figures 24 and 25) used in the description of the above embodiments show functional units. These functional blocks (components) are realized by any combination of at least one of hardware and software. Furthermore, the method of realizing each functional block is not particularly limited. That is, each functional block may be realized using one device that is physically or logically coupled, or it may be realized using two or more physically or logically separated devices that are directly or indirectly connected (for example, using wired or wireless connections). A functional block may be realized by combining the above one device or the above multiple devices with software.

[0165] Functions include, but are not limited to, judgment, decision, determination, calculation, calculation, processing, derivation, investigation, exploration, confirmation, reception, transmission, output, access, resolution, selection, selection, establishment, comparison, assumption, expectation, assumption, broadcasting, notifying, communicating, forwarding, configuring, reconfiguring, allocating (mapping), and assigning. For example, a functional block (configuration part) that enables transmission is called a transmitting unit or transmitter. In all cases, as mentioned above, the method of implementation is not particularly limited.

[0166] For example, the base station 10, network node 30, terminal 20, etc. in one embodiment of the present disclosure may function as a computer that processes the wireless communication method of the present disclosure. Figure 26 is a diagram showing an example of the hardware configuration of the base station 10 and terminal 20 according to one embodiment of the present disclosure. The network node 30 may have a hardware configuration similar to that of the base station 10. The above-mentioned base station 10 and terminal 20 may be physically configured as a computer device including a processor 1001, a storage device 1002, an auxiliary storage device 1003, a communication device 1004, an input device 1005, an output device 1006, a bus 1007, etc.

[0167] In the following explanation, the term "device" can be read as "circuit," "device," "unit," etc. The hardware configuration of the base station 10 and terminal 20 may include one or more of the devices shown in the figure, or it may be configured without some of the devices.

[0168] Each function in the base station 10 and terminal 20 is realized by loading predetermined software (programs) onto hardware such as the processor 1001 and storage device 1002, which allows the processor 1001 to perform calculations, control communication by the communication device 1004, and control at least one of data reading and writing in the storage device 1002 and auxiliary storage device 1003.

[0169] The processor 1001 controls the entire computer, for example, by running an operating system. The processor 1001 may consist of a central processing unit (CPU) that includes interfaces with peripheral devices, control devices, arithmetic units, registers, etc. For example, the control unit 140, control unit 240, etc., described above may be implemented by the processor 1001.

[0170] Furthermore, the processor 1001 reads programs (program code), software modules, or data from at least one of the auxiliary storage device 1003 and the communication device 1004 into the storage device 1002, and executes various processes accordingly. The program used is one that causes the computer to execute at least a part of the operations described in the above embodiment. For example, the control unit 140 of the base station 10 shown in Figure 24 may be implemented by a control program stored in the storage device 1002 and operated by the processor 1001. Also, for example, the control unit 240 of the terminal 20 shown in Figure 25 may be implemented by a control program stored in the storage device 1002 and operated by the processor 1001. Although the above-described processes have been explained as being executed by one processor 1001, they may be executed simultaneously or sequentially by two or more processors 1001. The processor 1001 may be implemented by one or more chips. The program may also be transmitted from the network via a telecommunications line.

[0171] The storage device 1002 is a computer-readable recording medium and may consist of at least one of the following: ROM (Read Only Memory), EPROM (Erasable Programmable ROM), EEPROM (Electrically Erasable Programmable ROM), RAM (Random Access Memory), etc. The storage device 1002 may also be called a register, cache, main memory, etc. The storage device 1002 can store executable programs (program code), software modules, etc., for implementing a communication method according to one embodiment of the present disclosure.

[0172] The auxiliary storage device 1003 is a computer-readable recording medium and may consist of at least one of the following: an optical disc such as a CD-ROM (Compact Disc ROM), a hard disk drive, a flexible disk, a magneto-optical disk (e.g., a compact disk, a digital multipurpose disk, a Blu-ray® disk), a smart card, flash memory (e.g., a card, a stick, a key drive), a floppy® disk, a magnetic strip, etc. The above-mentioned storage medium may also be a database, server, or other suitable medium that includes at least one of the storage device 1002 and the auxiliary storage device 1003.

[0173] The communication device 1004 is hardware (transmitting / receiving device) for communicating between computers via at least one of a wired network and a wireless network, and is also referred to as a network device, network controller, network card, communication module, etc. The communication device 1004 may be configured to include, for example, a high-frequency switch, duplexer, filter, frequency synthesizer, etc., in order to implement at least one of frequency division duplex (FDD) and time division duplex (TDD). For example, the transmitting and receiving antenna, amplifier section, transmitting and receiving section, transmission path interface, etc., may be implemented by the communication device 1004. The transmitting and receiving section may be implemented in a physically or logically separated manner, with a transmitting section and a receiving section.

[0174] The input device 1005 is an input device that accepts input from an external source (e.g., a keyboard, mouse, microphone, switch, button, sensor, etc.). The output device 1006 is an output device that outputs to an external source (e.g., a display, speaker, LED lamp, etc.). The input device 1005 and the output device 1006 may be configured as an integrated unit (e.g., a touch panel).

[0175] Furthermore, each device, such as the processor 1001 and the storage device 1002, is connected by a bus 1007 for communicating information. The bus 1007 may be configured using a single bus, or different buses may be configured for each device.

[0176] Furthermore, the base station 10 and terminal 20 may be configured to include hardware such as a microprocessor, a digital signal processor (DSP), an ASIC (Application Specific Integrated Circuit), a PLD (Programmable Logic Device), and an FPGA (Field Programmable Gate Array), and some or all of each functional block may be realized by such hardware. For example, the processor 1001 may be implemented using at least one of these hardware components.

[0177] Figure 27 shows an example of the configuration of vehicle 2001. As shown in Figure 27, vehicle 2001 includes a drive unit 2002, a steering unit 2003, an accelerator pedal 2004, a brake pedal 2005, a shift lever 2006, front wheels 2007, rear wheels 2008, an axle 2009, an electronic control unit 2010, various sensors 2021 to 2029, an information service unit 2012, and a communication module 2013. Each aspect / embodiment described in this disclosure may be applied to a communication device mounted on vehicle 2001, for example, to the communication module 2013.

[0178] The drive unit 2002 consists of, for example, an engine, a motor, or a hybrid of an engine and a motor. The steering unit 2003 includes at least a steering wheel (also called a handle) and is configured to steer at least one of the front wheels and the rear wheels based on the operation of the steering wheel, which is operated by the user.

[0179] The electronic control unit 2010 consists of a microprocessor 2031, memory (ROM, RAM) 2032, and communication ports (IO ports) 2033. Signals from various sensors 2021 to 2029 installed in the vehicle 2001 are input to the electronic control unit 2010. The electronic control unit 2010 may also be called an ECU (Electronic Control Unit).

[0180] Signals from various sensors 2021 to 2029 include current signals from current sensor 2021 for sensing motor current, front and rear wheel rotation speed signals acquired by rotation speed sensor 2022, front and rear wheel air pressure signals acquired by air pressure sensor 2023, vehicle speed signals acquired by vehicle speed sensor 2024, acceleration signals acquired by acceleration sensor 2025, accelerator pedal depression signals acquired by accelerator pedal sensor 2029, brake pedal depression signals acquired by brake pedal sensor 2026, shift lever operation signals acquired by shift lever sensor 2027, and detection signals acquired by object detection sensor 2028 for detecting obstacles, vehicles, pedestrians, etc.

[0181] The Information Service Unit 2012 consists of various devices for providing (outputting) various types of information such as driving information, traffic information, and entertainment information, including a car navigation system, audio system, speakers, television, and radio, and one or more ECUs that control these devices. The Information Service Unit 2012 uses information acquired from external devices via a communication module 2013, etc., to provide various multimedia information and multimedia services to the occupants of the vehicle 2001. The Information Service Unit 2012 may include input devices that accept input from the outside (e.g., keyboard, mouse, microphone, switch, button, sensor, touch panel, etc.) and output devices that perform output to the outside (e.g., display, speaker, LED lamp, touch panel, etc.).

[0182] The driver assistance system unit 2030 consists of various devices that provide functions to prevent accidents or reduce the driver's workload, such as millimeter-wave radar, LiDAR (Light Detection and Ranging), cameras, positioning locators (e.g., GNSS), map information (e.g., high-definition (HD) maps, autonomous vehicle (AV) maps), gyro systems (e.g., IMU (Inertial Measurement Unit), INS (Inertial Navigation System)), AI (Artificial Intelligence) chips, and AI processors, as well as one or more ECUs that control these devices. The driver assistance system unit 2030 also transmits and receives various information via the communication module 2013 to realize driver assistance functions or autonomous driving functions.

[0183] The communication module 2013 can communicate with the microprocessor 2031 and components of the vehicle 2001 via its communication port. For example, the communication module 2013 sends and receives data via the communication port 2033 between the drive unit 2002, steering unit 2003, accelerator pedal 2004, brake pedal 2005, shift lever 2006, front wheels 2007, rear wheels 2008, axle 2009, the microprocessor 2031 and memory (ROM, RAM) 2032 in the electronic control unit 2010, and sensors 2021-29 provided in the vehicle 2001.

[0184] The communication module 2013 is a communication device that can be controlled by the microprocessor 2031 of the electronic control unit 2010 and can communicate with external devices. For example, it can send and receive various types of information with external devices via wireless communication. The communication module 2013 may be located either inside or outside the electronic control unit 2010. The external device may be, for example, a base station or a mobile station.

[0185] The communication module 2013 may transmit at least one of the following to an external device via wireless communication: signals from the various sensors 2021-2028 input to the electronic control unit 2010, information obtained based on said signals, and information based on input from an external source (user) obtained via the information service unit 2012. The electronic control unit 2010, the various sensors 2021-2028, the information service unit 2012, etc., may also be called input units that accept input. For example, the PUSCH transmitted by the communication module 2013 may include the information based on the above input.

[0186] The communication module 2013 receives various information (traffic information, signal information, inter-vehicle information, etc.) transmitted from an external device and displays it on the information service unit 2012 provided in the vehicle 2001. The information service unit 2012 may also be called an output unit, which outputs information (for example, outputs information to devices such as displays and speakers based on the PDSCH (or data / information decoded from the PDSCH) received by the communication module 2013). The communication module 2013 also stores the various information received from the external device in a memory 2032 that can be used by the microprocessor 2031. Based on the information stored in the memory 2032, the microprocessor 2031 may control the drive unit 2002, steering unit 2003, accelerator pedal 2004, brake pedal 2005, shift lever 2006, front wheels 2007, rear wheels 2008, axles 2009, sensors 2021-2029, etc., provided in the vehicle 2001.

[0187] <Notes> (Note 1) A network node having: a transmitting unit that transmits a first message to a first network node that includes data information indicating the content of the data and information regarding the purpose of use of the data, and requests information regarding whether user permission has been granted for the data information; and a receiving unit that receives a second message from the first network node that includes information regarding whether user permission has been granted. (Note 2) The network node according to Note 1, wherein the data information includes information regarding a category and information regarding whether or not it relates to privacy. (Note 3) The network node according to Note 1, wherein the information regarding the purpose of use of the data includes information regarding a category and information regarding whether or not it relates to privacy. (Note 4) The network node according to Note 1, wherein the first message includes information indicating that it supports the information regarding the purpose of use of the data. (Note 5) The network node according to Note 1, wherein if the transmitting unit transmits the first message regarding the data information or the information regarding the purpose of use of the data, which does not include information regarding a category, the receiving unit receives the second message which includes information regarding a category. (Note 6) The network node as described in Note 1, wherein the transmitting unit transmits a third message to the second network node requesting an access token for accessing user permission data information regarding privacy, and the receiving unit receives a fourth message containing the access token from the second network node.

[0188] Any of the provisions of Appendix 1 to Appendix 6 can be used to introduce a mechanism that reflects the user's intentions in user permission for data use in wireless communication networks.

[0189] (Supplement to Embodiments) Embodiments of the present invention have been described above, but the disclosed invention is not limited to such embodiments, and those skilled in the art will understand various modifications, alterations, alternatives, substitutions, etc. Specific numerical examples have been used to facilitate understanding of the invention, but unless otherwise specified, these numerical values ​​are merely examples, and any appropriate values ​​may be used. The division of items in the above description is not essential to the present invention, and matters described in two or more items may be combined as needed, and matters described in one item may be applied to matters described in another item (as long as they do not contradict each other). The boundaries of functional units or processing units in the functional block diagram do not necessarily correspond to the boundaries of physical parts. The operation of multiple functional units may be physically performed by one part, or the operation of one functional unit may be physically performed by multiple parts. The processing procedures described in the embodiments may be rearranged as long as they do not contradict each other. For the convenience of explaining the processing, the base station 10 and terminal 20 have been described using functional block diagrams, but such devices may be realized in hardware, software, or a combination thereof. The software operated by the processor of the base station 10 according to an embodiment of the present invention and the software operated by the processor of the terminal 20 according to an embodiment of the present invention may be stored in any suitable storage medium such as random access memory (RAM), flash memory, read-only memory (ROM), EPROM, EEPROM, register, hard disk (HDD), removable disk, CD-ROM, database, server, or other appropriate storage medium.

[0190] Furthermore, notification of information is not limited to the embodiments described herein and may be carried out by other means. For example, notification of information may be carried out by physical layer signaling (e.g., DCI (Downlink Control Information), UCI (Uplink Control Information)), upper layer signaling (e.g., RRC (Radio Resource Control) signaling, MAC (Medium Access Control) signaling), broadcast information (MIB (Master Information Block), SIB (System Information Block)), other signals, or combinations thereof. Also, RRC signaling may be called RRC messages, and may be, for example, RRC Connection Setup messages, RRC Connection Reconfiguration messages, etc.

[0191] Each aspect / embodiment described in this disclosure refers to LTE (Long Term Evolution), LTE-A (LTE-Advanced), SUPER 3G, IMT-Advanced, 4G (4th generation mobile communication system), 5G (5th generation mobile communication system), 6th generation mobile communication system (6G), xth generation mobile communication system (xG) (xG (where x is, for example, an integer or decimal)), FRA (Future Radio Access), NR (new Radio), New radio access (NX), Future generation radio access (FX), W-CDMA (registered trademark), GSM (registered trademark), CDMA2000, UMB (Ultra Mobile Broadband), IEEE 802.11 (Wi-Fi (registered trademark)), IEEE 802.16 (WiMAX (registered trademark)), IEEE 802.20 may apply to at least one system utilizing UWB (Ultra-WideBand), Bluetooth®, or other appropriate systems, and to next-generation systems extended, modified, created, or defined based thereon. Alternatively, multiple systems may be applied in combination (e.g., a combination of at least one of LTE and LTE-A with 5G).

[0192] The processing procedures, sequences, flowcharts, etc., of each aspect / embodiment described herein may be reordered, provided they are consistent with each other. For example, the methods described herein present various step elements in an exemplary order and are not limited to that specific order.

[0193] In this specification, specific operations performed by the base station 10 may, in some cases, be performed by its upper node. In a network consisting of one or more network nodes having a base station 10, it is clear that various operations performed for communication with the terminal 20 can be performed by the base station 10 and at least one of the other network nodes (for example, an MME or S-GW, but not limited to these). Although the above example illustrates the case where there is one other network node besides the base station 10, the other network node may be a combination of multiple other network nodes (for example, an MME and an S-GW).

[0194] The information or signals described in this disclosure may be output from a higher layer (or lower layer) to a lower layer (or higher layer). They may also be input and output via multiple network nodes.

[0195] Input and output information may be stored in a specific location (e.g., memory) or managed using a management table. Input and output information may be overwritten, updated, or appended to. Output information may be deleted. Input information may be transmitted to other devices.

[0196] The determination in this disclosure may be made by a value represented by one bit (0 or 1), by a Boolean value (true or false), or by a numerical comparison (for example, a comparison with a predetermined value).

[0197] Software should be broadly interpreted to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executable files, execution threads, procedures, functions, and so on, whether they are called software, firmware, middleware, microcode, hardware description languages, or by any other name.

[0198] Furthermore, software, instructions, information, etc., may be transmitted and received via a transmission medium. For example, if software is transmitted from a website, server, or other remote source using at least one of wired technology (such as coaxial cable, fiber optic cable, twisted pair, or digital subscriber line (DSL)) and wireless technology (such as infrared or microwave), then at least one of these wired and wireless technologies is included in the definition of a transmission medium.

[0199] The information, signals, etc. described in this disclosure may be represented using any of the various different techniques. For example, the data, instructions, commands, information, signals, bits, symbols, chips, etc. that may be referred to throughout the above description may be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, optical fields or photons, or any combination thereof.

[0200] In addition, terms used in this disclosure and terms necessary for understanding this disclosure may be replaced with terms having the same or similar meanings. For example, at least one of the channel and symbol may be a signal (signaling). Also, a signal may be a message. Furthermore, a component carrier (CC) may be called a carrier frequency, cell, frequency carrier, etc.

[0201] The terms “system” and “network” as used in this disclosure are interchangeable.

[0202] Furthermore, the information, parameters, etc., described in this disclosure may be expressed using absolute values, relative values ​​from a given value, or other corresponding information. For example, wireless resources may be indicated by an index.

[0203] The names used for the parameters described above are not restrictive in any way. Furthermore, the formulas and other expressions using these parameters may differ from those expressly disclosed in this disclosure. Various channels (e.g., PUCCH, PDCCH, etc.) and information elements can be identified by any suitable name, and therefore, the various names assigned to these various channels and information elements are not restrictive in any way.

[0204] In this disclosure, terms such as "Base Station (BS)", "wireless base station", "base station equipment", "fixed station", "NodeB", "eNodeB (eNB)", "gNodeB (gNB)", "access point", "transmission point", "reception point", "transmission / reception point", "cell", "sector", "cell group", "carrier", and "component carrier" may be used interchangeably. Base stations may also be referred to by terms such as macrocell, small cell, femtocell, and picocell.

[0205] A base station can accommodate one or more (e.g., three) cells. If a base station accommodates multiple cells, the entire coverage area of ​​the base station can be divided into multiple smaller areas, each of which may also be provided with communication services by a base station subsystem (e.g., a Remote Radio Head (RRH)). The terms “cell” or “sector” refer to part or all of the coverage area of ​​at least one of the base station and / or base station subsystems that provide communication services in that coverage.

[0206] In this disclosure, the transmission of information by a base station to a terminal may be interpreted as the base station instructing the terminal to perform control or operation based on the information.

[0207] In this disclosure, terms such as "Mobile Station (MS)," "user terminal," "User Equipment (UE)," and "terminal" may be used interchangeably.

[0208] A mobile station may also be referred to by those skilled in the art as a subscriber station, mobile unit, subscriber unit, wireless unit, remote unit, mobile device, wireless device, wireless communication device, remote device, mobile subscriber station, access terminal, mobile terminal, wireless terminal, remote terminal, handset, user agent, mobile client, client, or several other appropriate terms.

[0209] At least one of the base station and the mobile station may be called a transmitting device, a receiving device, a communication device, etc. At least one of the base station and the mobile station may also be a device mounted on a mobile body, the mobile body itself, etc. The mobile body refers to a movable object, and its speed of movement is arbitrary. This also includes the case when the mobile body is stationary. The mobile body includes, but is not limited to, vehicles, transport vehicles, automobiles, motorcycles, bicycles, connected cars, excavators, bulldozers, wheel loaders, dump trucks, forklifts, trains, buses, handcarts, rickshaws, ships and other watercraft, airplanes, rockets, satellites, drones (registered trademark), multicopters, quadcopters, balloons, and items mounted on them. The mobile body may also be a mobile body that moves autonomously based on operation commands. It may be a vehicle (e.g., a car, an airplane, etc.), an unmanned mobile body (e.g., a drone, an autonomous vehicle, etc.), or a robot (manned or unmanned). Furthermore, at least one of the base station and the mobile station may include devices that do not necessarily move during communication operations. For example, at least one of the base station and the mobile station may be an IoT (Internet of Things) device such as a sensor.

[0210] Furthermore, the term "base station" in this disclosure may be interpreted as "user terminal." For example, the various aspects / embodiments of this disclosure may be applied to a configuration in which communication between a base station and a user terminal is replaced with communication between multiple terminals 20 (which may be called, for example, D2D (Device-to-Device), V2X (Vehicle-to-Everything), etc.). In this case, the terminals 20 may have the functions that the base station 10 has. Also, terms such as "uplink" and "downlink" may be interpreted as terms corresponding to terminal-to-terminal communication (for example, "side"). For example, uplink channel, downlink channel, etc., may be interpreted as side channel.

[0211] Similarly, the term "user terminal" in this disclosure may be replaced with "base station." In this case, the base station may be configured to have the same functions as the user terminal described above.

[0212] As used in this disclosure, the terms “determining” and “determining” may encompass a wide variety of actions. “Determining” may include, for example, judging, calculating, computing, processing, deriving, investigating, looking up, searching, or inquiring (e.g., searching in a table, database, or other data structure), or ascertaining. “Determining” may also include receiving (e.g., receiving information), transmitting (e.g., sending information), inputting, outputting, or accessing (e.g., accessing data in memory). Furthermore, "judgment" and "decision" can include considering something as having been "judged" or "decided" after resolving, selecting, choosing, establishing, comparing, etc. In other words, "judgment" and "decision" can include considering something as having been "judged" or "decided" after some action. Also, "judgment (decision)" can be reinterpreted as "assuming," "expecting," or "considering."

[0213] The terms “connected,” “coupled,” or any variation thereof, mean any direct or indirect connection or coupling between two or more elements, and may include the presence of one or more intermediate elements between two elements that are “connected” or “coupled” with each other. The coupling or connection between elements may be physical, logical, or a combination thereof. For example, “connection” may be reinterpreted as “access.” As used in this disclosure, two elements may be considered to be “connected” or “coupled” with each other using at least one of one or more wires, cables, and printed electrical connections, and, in some non-limiting and non-exclusive examples, electromagnetic energy having wavelengths in the radio frequency domain, microwave domain, and optical (both visible and invisible) domain.

[0214] The reference signal can also be abbreviated as RS (Reference Signal), and may be called a pilot depending on the applicable standard.

[0215] In this disclosure, the phrase "based on" does not mean "based solely on" unless otherwise specified. In other words, the phrase "based on" means both "based solely on" and "based at least on."

[0216] Any reference to elements using the designations “first,” “second,” etc., as used in this disclosure does not generally limit the quantity or order of those elements. These designations may be used in this disclosure as a convenient way to distinguish between two or more elements. Accordingly, references to the first and second elements do not imply that only two elements may be employed, or that the first element must precede the second element in any way.

[0217] In the configuration of each of the above devices, "means" may be replaced with "part," "circuit," "device," etc.

[0218] Where the terms “include,” “including,” and variations thereof are used in this disclosure, these terms are intended to be inclusive, as is the term “comprising.” Furthermore, the term “or” as used in this disclosure is not intended to mean exclusive OR.

[0219] In this disclosure, if articles are added through translation, such as a, an, and the in English, this disclosure may include the fact that the noun following these articles is plural.

[0220] In this disclosure, the term "A and B are different" may mean "A and B are different from each other." The term may also mean "A and B are each different from C." Terms such as "separate" and "combine" may be interpreted similarly to "different."

[0221] Each aspect / embodiment described in this disclosure may be used individually, in combination, or switched between as needed during implementation. Furthermore, notification of specific information (e.g., notification that "X is") is not limited to explicit notification, but may also be implicit (e.g., by not providing such notification).

[0222] Although the present disclosure has been described in detail above, it will be clear to those skilled in the art that the present disclosure is not limited to the embodiments described herein. The present disclosure can be implemented in modified and altered forms without departing from the intent and scope of the present disclosure as defined by the claims. Therefore, the descriptions in the present disclosure are illustrative and not intended to be restrictive in any way.

[0223] This patent application claims priority based on Japanese Patent Application No. 2025-056765, filed on 28 March 2025, and the entire contents of Japanese Patent Application No. 2025-056765 are incorporated herein by reference.

[0224] 10 Base station 110 Transmitting unit 120 Receiving unit 130 Setting unit 140 Control unit 20 Terminal 210 Transmitting unit 220 Receiving unit 230 Setting unit 240 Control unit 30 Network node 1001 Processor 1002 Storage device 1003 Auxiliary storage device 1004 Communication device 1005 Input device 1006 Output device 2001 Vehicle 2002 Drive unit 2003 Steering unit 2004 Accelerator pedal 2005 Brake pedal 2006 Shift lever 2007 Front wheel 2008 Rear wheel 2009 Axle 2010 Electronic control unit 2012 Information service unit 2013 Communication module 2021 Current sensor 2022 Rotation speed sensor 2023 Air pressure sensor 2024 Vehicle speed sensor 2025 Acceleration sensor 2026 Brake pedal sensor 2027 Shift lever sensor 2028 Object detection sensor 2029 Accelerator pedal sensor 2030 Driver assistance system unit 2031 Microprocessor 2032 Memory (ROM, RAM) 2033 Communication port (I / O port)< / apiversion> < / apiversion> < / apiversion> < / apiversion> < / apiversion> < / apiversion> < / apiversion> < / apiversion> < / apiversion> < / apiversion>

Claims

A transmission unit transmits a first message to a first network node that includes data information indicating the content of the data and information regarding the purpose of use of the data, and requests information regarding whether user permission has been granted for the data information. A receiving unit that receives a second message from the first network node containing information regarding whether the user permission has been granted, A network node that has 　 The aforementioned data information includes information about categories and information about whether or not it relates to privacy. The network node according to claim 1. 　 The information regarding the purpose of use of the aforementioned data includes category information and information regarding whether or not it relates to privacy. The network node according to claim 1. 　 The first message includes information indicating that it supports information regarding the purpose of use of the data, The network node according to claim 1. 　 If the transmitting unit transmits the first message which does not include category information regarding the data information or the information regarding the purpose of use of the data, The receiving unit receives the second message which includes information about the category. The network node according to claim 1. 　 The transmitting unit sends a third message to the second network node requesting an access token to access user permission data information regarding privacy. The receiving unit receives a fourth message, including the access token, from the second network node. The network node according to claim 1.

Images