Network node and communication method

By authenticating terminals and managing access tokens based on subscriber information, the network node addresses the challenge of unauthorized API access in the 3GPP core network, ensuring secure and appropriate service provision.

JP7613818B2Active Publication Date: 2025-01-15NTT DOCOMO INC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
JP2023506691
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Filing Date
2021-03-19
Publication Date
2025-01-15
Estimated Expiration
2041-03-19

AI Technical Summary

Technical Problem

The 3GPP core network faces challenges in identifying the user of third-party applications accessing APIs, leading to inappropriate service provision due to the inability to authenticate and authorize these applications effectively.

Method used

A network node that authenticates terminals, issues provisional identifiers, and manages access tokens based on subscriber information to authorize API calls, ensuring appropriate service provision.

Benefits of technology

This solution enables accurate identification of subscribers, allowing authorized API calls and preventing unauthorized access, thereby enhancing network security and service management.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007613818000001
    Figure 0007613818000001
  • Figure 0007613818000002
    Figure 0007613818000002
  • Figure 0007613818000003
    Figure 0007613818000003
Patent Text Reader

Abstract

This network node has: a transmission unit that authenticates a terminal and transmits a provisional identifier to the terminal; a reception unit that receives a request including the provisional identifier, or receives an authentication code based on the provisional identifier; and a control unit that issues an access token on the basis of the request including the provisional identifier or the authentication code. The transmission unit transmits the access token to the terminal or to an external application. The reception unit receives, from the terminal or the external application, an application programming interface (API) call request based on the access token. The control unit verifies the access token and, when it is assessed that the API call request is approved, executes a process on the basis of the API call request.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] The present invention relates to a network node and a communication method in a communication system. [Background technology]

[0002] 3GPP (3rd Generation Partnership Project) is currently studying a wireless communication system called 5G or NR (New Radio) (hereinafter, the wireless communication system is referred to as "5G" or "NR") in order to realize a larger system capacity, a higher data transmission speed, and a lower latency in wireless sections. In 5G, various wireless technologies are being studied to meet the requirements of achieving a throughput of 10 Gbps or more while keeping the latency in wireless sections to 1 ms or less.

[0003] In NR, a network architecture is being considered that includes 5GC (5G Core Network), which corresponds to EPC (Evolved Packet Core), which is a core network in the network architecture of LTE (Long Term Evolution), and NG-RAN (Next Generation - Radio Access Network), which corresponds to E-UTRAN (Evolved Universal Terrestrial Radio Access Network), which is a RAN (Radio Access Network) in the network architecture of LTE (for example, Non-Patent Document 1).

[0004] Also, for example, an architecture is being considered in which a northbound interface between a network exposure function (NEF) and an application function (AF) in a 5G system is configured using a common API framework (CAPIF) (for example, Non-Patent Documents 2 and 3). [Prior art documents] [Non-patent literature]

[0005] [Non-Patent Document 1] 3GPP TS 23.501 V16.7.0(2020-12) [Non-Patent Document 2] 3GPP TS 29.522 V16.6.0(2020-12) [Non-Patent Document 3] 3GPP TS 23.222 V16.9.0(2020-09) Summary of the Invention [Problem to be solved by the invention]

[0006] The 3GPP core network provides an API (Application Programming Interface) for external applications, allowing third-party applications to call the API. However, when a third-party application calls the API, the core network has difficulty identifying the user who uses the third-party application, and is therefore unable to provide an appropriate service.

[0007] The present invention has been made in view of the above-mentioned points, and an object of the present invention is to provide an interface that makes it possible to identify subscriber information in a network. [Means for solving the problem]

[0008] According to the disclosed technology, a network node is provided that has a transmitting unit that authenticates a terminal and transmits a temporary identifier to the terminal, a receiving unit that receives a request including the temporary identifier or an authentication code based on the temporary identifier, and a control unit that issues an access token based on the request including the temporary identifier or the authentication code, wherein the transmitting unit transmits the access token to the terminal or an external application, the receiving unit receives an API (Application Programming Interface) call request based on the access token from the terminal or the external application, and the control unit verifies the access token and, if it determines that the API call request is authorized, executes processing based on the API call request. Effect of the Invention

[0009] The disclosed technology can provide an interface that allows subscriber information to be identified in a network. [Brief description of the drawings]

[0010] [Figure 1] FIG. 1 is a diagram illustrating an example of a communication system. [Diagram 2] FIG. 1 is a diagram illustrating an example of a communication system in a roaming environment. [Diagram 3] FIG. 1 is a diagram illustrating an example (1) of an API call. [Figure 4] FIG. 2 is a diagram showing an example of an API call (2-1). [Diagram 5] FIG. 13 is a diagram showing an example of an API call (2-2). [Figure 6] FIG. 13 is a diagram showing an example of an API call (3-1). [Figure 7] FIG. 13 is a diagram showing an example of an API call (3-2). [Figure 8] FIG. 13 is a diagram illustrating an example (4) of an API call. [Figure 9] FIG. 2 is a diagram for explaining an example (1) of an API call by a UE in the embodiment of the present invention. [Figure 10] FIG. 13 is a diagram for explaining an example (2) of an API call by a UE in the embodiment of the present invention. [Figure 11] FIG. 11 is a diagram for explaining an example (3) of an API call by a UE in the embodiment of the present invention. [Figure 12] FIG. 2 is a diagram for explaining an example (1) of an API call by a UE and an AF in an embodiment of the present invention. [Figure 13] FIG. 13 is a diagram for explaining an example (2) of an API call by the UE and the AF in the embodiment of the present invention. [Figure 14] FIG. 11 is a diagram for explaining an example (3) of an API call by the UE and the AF in the embodiment of the present invention. [Figure 15] FIG. 11 is a diagram for explaining an example (4) of an API call by the UE and the AF in the embodiment of the present invention. [Figure 16] FIG. 5 is a diagram for explaining an example (5) of an API call by the UE and the AF in the embodiment of the present invention. [Figure 17] FIG. 2 is a diagram for explaining the scope of an API according to the embodiment of the present invention. [Figure 18] FIG. 1 is a diagram illustrating an example of a system including a UE and an AF according to an embodiment of the present invention. [Figure 19] FIG. 1 is a diagram illustrating an example of a system including a UE according to an embodiment of the present invention. [Figure 20] 4 is a sequence diagram for explaining an example of an API call by a UE in the embodiment of the present invention. FIG. [Figure 21] FIG. 2 is a sequence (1) diagram for explaining an example of an API call by a UE and an AF in the embodiment of the present invention. [Figure 22] FIG. 13 is a sequence diagram (2) for explaining an example of an API call by the UE and the AF in the embodiment of the present invention. [Diagram 23] 2 is a diagram illustrating an example of a functional configuration of a base station 10 according to an embodiment of the present invention. [Figure 24]2 is a diagram illustrating an example of a functional configuration of a terminal 20 according to an embodiment of the present invention. [Diagram 25] 2 is a diagram illustrating an example of a hardware configuration of a base station 10 and a terminal 20 according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. Note that the embodiment described below is an example, and the embodiment to which the present invention is applied is not limited to the following embodiment.

[0012] In the operation of the wireless communication system according to the embodiment of the present invention, existing technologies are used as appropriate. However, the existing technologies are, for example, existing LTE, but are not limited to existing LTE. In addition, the term "LTE" used in this specification has a broad meaning including LTE-Advanced and systems after LTE-Advanced (e.g., NR), or wireless LAN (Local Area Network), unless otherwise specified.

[0013] Furthermore, in an embodiment of the present invention, when radio parameters, etc. are "configured," this may mean that predetermined values ​​are pre-configured, or that radio parameters notified from the network node 30 or the terminal 20 are configured.

[0014] Fig. 1 is a diagram for explaining an example of a communication system. As shown in Fig. 1, the communication system is composed of a UE, which is a terminal 20, and a plurality of network nodes 30. In the following, it is assumed that one network node 30 corresponds to each function, but a single network node 30 may realize a plurality of functions, or a single function may be realized by a plurality of network nodes 30. In addition, the "connection" described below may be a logical connection or a physical connection.

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

[0016] The AMF is connected to the 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). The AMF, SMF, NSSF, NEF, NRF, UDM, AUSF, PCF, and AF are network nodes 30 that are mutually connected via interfaces, Namf, Nsmf, Nnssf, Nnef, Nnrf, Nudm, Nausf, Npcf, and Naf, based on their respective services.

[0017] The SMF is a network node 30 having functions such as session management, IP (Internet Protocol) address allocation and management of UE, DHCP (Dynamic Host Configuration Protocol) function, ARP (Address Resolution Protocol) proxy, and roaming function. The NEF is a network node 30 having a function of notifying other NFs (Network Functions) of capabilities and events. The NSSF is a network node 30 having functions such as selecting a network slice to which the UE connects, determining permitted NSSAI (Network Slice Selection Assistance Information), determining an NSSAI to be set, and determining an AMF set to which the UE connects. The PCF is a network node 30 having a function of performing network policy control. The AF is a network node 30 having a function of controlling an application server. The NRF is a network node 30 having a function of discovering an NF instance that provides a service. The UDM is a network node 30 that manages subscriber data and authentication data. The UDM is connected to a UDR (User Data Repository) that holds the data.

[0018] Fig. 2 is a diagram for explaining an example of a communication system in a roaming environment. As shown in Fig. 2, the network is composed of a UE, which is a terminal 20, and a plurality of network nodes 30. In the following, it is assumed that one network node 30 corresponds to each function, but a single network node 30 may realize a plurality of functions, or a plurality of network nodes 30 may realize a single function. In addition, the "connection" described below may be a logical connection or a physical connection.

[0019] The RAN is a network node 30 having a radio access function, and is connected to the UE, the AMF, and the 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 having functions such as a PDU session point for the outside that interconnects with the DN, packet routing and forwarding, and user plane QoS handling. The UPF and the DN constitute a network slice. In the wireless communication network according to the embodiment of the present invention, a plurality of network slices are constructed.

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

[0021] The SMF is a network node 30 having functions such as session management, IP address allocation and management for UE, DHCP function, ARP proxy, and roaming function. The NEF is a network node 30 having a function of notifying other NFs of capabilities and events. The NSSF is a network node 30 having functions such as selecting a network slice to which the UE connects, determining an allowed NSSAI, determining an NSSAI to be configured, and determining an AMF set to which the UE connects. The PCF is a network node 30 having a function of performing network policy control. The AF is a network node 30 having a function of controlling an application server. The NRF is a network node 30 having a function of discovering an NF instance that provides a service. The SEPP is a non-transparent proxy that filters control plane messages between PLMNs (Public Land Mobile Networks). The vSEPP shown in FIG. 2 is a SEPP in a visited network, and the hSEPP is a SEPP in a home network.

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

[0023] The above-mentioned NEF is being considered to be implemented by applying the CAPIF (Common API Framework) architecture to an API (Application Programming Interface) that can be called from an AF. The CAPIF architecture provides a mechanism to support service API operations, for example, allowing an API invoker to discover a service API provided by an API provider and enabling communication using the service API. The CAPIF architecture also has a mechanism to hide the topology of the PLMN trust domain from an API invoker that accesses a service API from outside the PLMN trust domain.

[0024] Figure 3 is a diagram showing an example of an API call (1). The 3GPP core network opens up APIs for external applications, and third-party applications can call the APIs. When an API is called, the CAPIF Core Function (also referred to as CCF) in the core network authenticates and / or authorizes the calling application (API invoker) and manages which applications can call the API.

[0025] As shown in Fig. 3, an application 30A that is an API caller is preregistered in a CAPIF core function 30B using the CAPIF-API. The CAPIF core function 30B authenticates and / or authorizes the third-party application 30A. Also, as shown in Fig. 3, when the application 30A that is an API caller calls an API of the core network, an API providing function (also referred to as an API Exposing Function, AEF) 30C releases a service API for the authenticated and / or authorized external application.

[0026] FIG. 4 is a diagram showing an example of an API call (2-1). FIG. 5 is a diagram showing an example of an API call (2-2). As a specific use case, a QoS change option is assumed. A user can obtain a comfortable communication environment by sending a QoS change request at a desired timing according to a contract. As shown in FIG. 4, a QoS change request is sent from a user's application to a NEF included in a 5GS (5G System) as an API call of a core network, and the QoS change is executed.

[0027] However, in the conventional technology, it is not possible to determine which user can change the QoS of which user, and it is possible to change the QoS of an inappropriate user. For example, as shown in FIG. 5, the CAPIF core function 30B does not know which user is permitted to change the QoS, and the API providing function 30C allows a contractor who can change the QoS to change the QoS of a user who cannot change the QoS. In addition, even for services other than QoS, it is not possible to determine which user's resources can be accessed. In FIG. 5, the API caller is an end user's smartphone, etc.

[0028] In the following, in this embodiment, the proposal will be explained using QoS change as a specific example, but the API used by the user is not limited to QoS control, and may be any API provided by the operator to users. For example, there is an API that changes the U-plane communication path of a specific user, and the method described in this embodiment may be applied when the end user uses the API himself.

[0029] FIG. 6 is a diagram showing an example of an API call (3-1). FIG. 7 is a diagram showing an example of an API call (3-2). As a specific use case, a case where a smartphone game made by a third party is played is assumed. It is assumed that a user can obtain a comfortable communication environment by sending a QoS change request at a desired timing according to a fee, i.e., a contract. As shown in FIG. 6, a QoS change request is sent from a user's application to a NEF included in a 5GS via a game server as an API call of a core network, and the QoS change is executed.

[0030] However, in the conventional technology, it is not possible to determine which user can change the QoS of which user, and it is not possible to reject a QoS change request from a user without a QoS change option (or generally without an appropriate contract). For example, as shown in FIG. 7, the CAPIF core function 30B does not know which user the request is from, and the API providing function 30C can call the API if the game server itself is authenticated and authorized. As shown in FIG. 7, the operation intended by the network side is to allow a QoS change request from a UE 20A corresponding to a game player with a QoS change option and to reject a QoS change request from a UE 20B corresponding to a game player without a QoS change option. In FIG. 7, the API caller is a third-party game server or the like.

[0031] Therefore, the CAPIF core function 30B may authenticate each terminal and authorize the use of the API. Also, the CAPIF core function 30B may manage a scope that specifies which API each terminal may call. Also, the QoS of only the specified UE may be changed within the scope.

[0032] FIG. 8 is a diagram showing an example of an API call (4). FIG. 8 shows an example of an AF calling an API in the prior art. As shown in FIG. 8, the API caller 30A onboards the CAPIF core function 30B. Here, "onboarding" refers to an operation in which the CAPIF core function 30B authenticates the API caller 30A, performs a one-time registration, and permits the API caller 30A to access CAPIF and the service API. Next, the API caller 30A and the CAPIF core function 30B agree on a security method. Next, the API caller 30A requests an access token from the CAPIF core function 30B, and the CAPIF core function 30B issues the access token.

[0033] The above security method agreement uses the OAuth 2.0 Client Credential method, and API calls are authorized with just the authentication of the client (the API caller in Figure 8) without the permission of the resource owner.

[0034] 9 is a diagram for explaining an example (1) of an API call by a UE in an embodiment of the present invention. In step 1, the BSF (Bootstrapping Server Function) 30F and the UDM 30G authenticate the UE 20 by executing a Bootstrapping procedure, and enable the UE 20 and the CAPIF core function 30B to directly communicate with each other. The UE 20 receives a temporary identifier from the CCF 30B. The temporary identifier may be, for example, a Northbound Access Globally Unique Temporary Identifier (NA-GUTI). In the following step 2, a security method is agreed upon between the UE 20 and the CCF 30B.

[0035] 10 is a diagram for explaining an example (2) of an API call by a UE in the embodiment of the present invention. In the following step 3, UE 20 requests CCF 30B to issue an access token by clearly indicating a temporary identifier and an API to be called. Note that at the time of step 3, user information to be changed, etc. may be transmitted to CCF 30B, and an access token may be issued from CCF 30B based on the user information.

[0036] In the next step 4, CCF 30B identifies the subscriber from the temporary identifier and confirms the subscriber information with UDM 30G. In the next step 5, UDM 30G returns the subscriber information. UDM 30G may return a table in which the permitted API, the method, and the target user shown in Fig. 10 are associated with each other as the subscriber information to CCF 30B.

[0037] In the next step 6, if CCF 30B determines that UE 20 is permitted to call the target API based on the permitted API and method in the table, CCF 30B issues an access token to the UE. In the example shown in Fig. 10, for example, when AsSessionWithQoS is called from UE 20, the API is permitted, so that an access token is issued from CCF 30B.

[0038] In the next step 7, the UE 20 uses the received access token to call a service API addressed to the AEF 30C. For example, as shown in Fig. 10, the UE 20 may call the service API by sending information indicating that the access token is @@@@@@, the API is AsSessionWithQoS, and the IP address of the user to be changed is xxx.xxx.xxx.xxx to the AEF 30C.

[0039] Fig. 11 is a diagram for explaining an example (3) of an API call by a UE in an embodiment of the present invention. In the following step 8, AEF 30C confirms with CCF 30B whether the API request may be authorized. In the following step 9, CCF 30B requests subscriber information of the subscriber who made the API call from UDM 30G. In the following step 10, UDM 30G returns the subscriber information. UDM 30G may return a table in which the permitted API, the method, and the target user shown in Fig. 11 are associated to CCF 30B as the subscriber information. In the following step 11, CCF 30B determines whether the API request may be authorized based on the subscriber information and the API request, and returns the result to AEF 30C.

[0040] For example, CCF 30B may compare the request "API:AsSessionWithQoS, IP address of change target user is xxx.xxx.xxx.xxx" with the "target user" of the subscriber information shown in Fig. 11, and determine that use of the API may be authorized if the QoS change for the target user is permitted in the subscriber information. In the following step 12, if CCF 30B authorizes use of the API, AEF 30C executes processing according to the request and returns the result of API availability to UE 20.

[0041] FIG. 12 is a diagram for explaining an example (1) of an API call by a UE and an AF in an embodiment of the present invention. In step 1, an API caller 30A (e.g., a game server) onboards to a CAPIF core function 30B. The onboarding may be the same as in the prior art. In step 1′, in parallel with step 1, the BSF 30F and the UDM 30G authenticate the UE 20 by executing a bootstrap procedure, so that the UE 20 and the CAPIF core function 30B can directly communicate with each other. The UE 20 receives a temporary identifier from the CCF 30B. The temporary identifier may be, for example, NA-GUTI.

[0042] 13 is a diagram for explaining an example (2) of an API call by a UE and an AF in an embodiment of the present invention. In the following step 2, the API caller 30A detects that a UE-triggered API call is necessary based on a request from the UE 20. For example, the UE trigger may be the transmission of information indicating a QoS change request from the UE 20 to the game server, or the game server determining that the QoS needs to be changed for the user.

[0043] In the next step 3, when it is necessary to call an API related to the contract contents of an individual subscriber, an agreement is reached between API caller 30A and CCF 30B that authorization will be performed using OAuth 2.0 Authorization Code Flow as a security method.

[0044] 14 is a diagram for explaining an example (3) of an API call by a UE and an AF in an embodiment of the present invention. In the following step 4, the API caller 30A confirms with the user whether it is OK to call the API. In the following step 5, if permission to call the API is obtained from the user, an authorization request is sent to the CCF 30B, specifying the temporary identifier of the UE 20 and the API to be called. In the following step 6, the CCF 30B identifies the target UE (contractor) from the temporary identifier, and confirms the subscriber information of the contractor with the UDM 30G.

[0045] In the next step 7, UDM 30G returns the subscriber information. UDM 30G may return a table in which permitted APIs, methods, and target users shown in FIG. 12 are associated to CCF 30B as the subscriber information. In the next step 8, CCF 30B determines whether the contract is permitted to call the target API based on the subscriber information, and notifies UE 20 of the result. Here, UE 20 may permit API use by inputting a password or the like as necessary. In the next step 9, CCF 30B issues an Authorization Code to API caller 30A indicating that API use is permitted.

[0046] 15 is a diagram for explaining an example (4) of an API call by a UE and an AF in an embodiment of the present invention. In the following step 10, the API caller 30A uses the authorization code to request an access token for the API call and receives the access token from the CCF 30B. In the following step 11, the API caller 30A uses the access token to access the service API.

[0047] Fig. 16 is a diagram for explaining an example (5) of an API call by a UE and an AF in an embodiment of the present invention. In the following step 12, the AEF 30C confirms with the CCF 30B whether the API request may be authorized. In the following step 13, the CCF 30B requests the subscriber information of the subscriber who made the API call from the UDM 30G. In the following step 14, the UDM 30G returns the subscriber information. The UDM 30G may return to the CCF 30B, as the subscriber information, a table in which the permitted API, the method, and the target user shown in Fig. 16 are associated.

[0048] In the next step 15, CCF 30B determines whether the API request is to be approved based on the subscriber information and the API request, and returns the result to AEF 30C. In the next step 16, if CCF 30B approves the API usage, AEF 30C executes processing according to the request and returns the result of API usage approval to API caller 30A.

[0049] Fig. 17 is a diagram for explaining the scope of an API in an embodiment of the present invention. As shown in Fig. 17, in response to an inquiry for subscriber information based on a subscriber identifier from CCF 30B, UDM 30G may return to CCF 30B a list of APIs permitted by the subscriber, permitted methods, and permitted users for each piece of subscriber information. For example, UDM 30G may return to CCF 30B one entry by associating permitted APIs, methods, and target users, as in option 1 shown in Fig. 17.

[0050] Also, for example, UDM30G may define in advance a role correspondence table in which a role, a method, and a target user are associated as one entry as a typical scope setting, and return information indicating the permitted API and the role to CCF30B, as in option 2 shown in Fig. 17. In other words, CCF30B may specify the operation permitted by each API by associating each subscriber with a role.

[0051] Fig. 18 is a diagram showing an example of a system including a UE and an AF in an embodiment of the present invention. As shown in Fig. 18, a CCF 30B including a CAPIF-API, an AEF 30C including a service API, an APF (API Publishing Function) 30D, an AMF (API Management Function) 30E, a core network, and an access network belong to a PLMN (PLMN Trust domain) which is a trusted domain. On the other hand, an API caller 30A (e.g., a game server) and a UE 20 exist outside the PLMN.

[0052] 18, the API caller 30A may be connected to the AEF 30C via a core network and may be able to call the CAPIF-API and the service API. The UE 20 may be connected to the API caller 30A and the AEF 30C via an access network and a core network.

[0053] Fig. 19 is a diagram showing an example of a system including a UE according to an embodiment of the present invention. As shown in Fig. 18, a CCF 30B including a CAPIF-API, an AEF 30C including a service API, an APF 30D, an AMF 30E, a core network, and an access network belong to a PLMN which is a trusted domain. On the other hand, a UE 20 exists outside the PLMN.

[0054] As shown in FIG. 18, the UE 20 may be connected to the CCF 30B and the AEF 30C via an access network and a core network, and may be capable of calling the CAPIF-API and the service API.

[0055] 18 and 19 show an example of the system configuration, and the system configuration is not limited to this. For example, the AEF 30C, the APF 30D, and the AMF 30E may be outside the trusted PLMN domain.

[0056] Fig. 20 is a sequence diagram for explaining an example of an API call by a UE in the embodiment of the present invention. Using Fig. 20, detailed operations of the examples of API calls by a UE in the above-mentioned Figs. 8 to 11 will be explained.

[0057] In step S101, the UE 20 executes a bootstrap procedure with the BSF 30F and the UDM 30G. In the following step S102, the UE 20 executes an application request / response with the CCF 20B, and the CCF 20B executes an authentication request / response with the BSF 30F. In the following step S103, the UE 20 acquires an NA-GUTI. In the following step S104, the UE 20 subscribes to the CCF 30B so as to receive necessary notifications from the CCF 30B. In the following step S105, a Transport Layer Security (TLS) connection between the UE 20 and the CCF 30B is established. Through the procedures from step S101 to step S105, the terminal 20 is authenticated by bootstrapping instead of the existing onboarding, and then communication is performed between the UE and the CCF. Note that step S104 may or may not be executed.

[0058] In step S106, the UE 20 transmits a security method request to the CCF 30B. In the following step S107, the CCF 30B selects a security method. In the following step S108, a security method response that is an OAuth 2.0 Client Credential is transmitted from the CCF 30B to the UE 20. The security method to be used for the API call is determined by the procedure from step S106 to step S108.

[0059] In step S109, the UE 20 uses the NA-GUTI to transmit an access token request based on OAuth 2.0 to the CCF 30B. In the following step S110, the CCF 30B checks the subscriber information with the UDM 30G. In the following step S111, the CCF 30B verifies the access token request. In the following step S112, the CCF 30B responds with an access token based on OAuth 2.0 to the UE 20. Through the procedures from step S109 to step S112, an access token is issued using the NA-GUTI, and the terminal 20 acquires the access token for API calls.

[0060] In step S113, a TLS connection is established between the UE 20 and the AEF 30C. In the following step S114, the UE 20 calls the Northbound API for the AEF 30C by the access token by OAuth 2.0. In the following step S115, the CCF 30B checks the subscriber information for the UDM 30G. In the following step S116, the AEF 30C verifies the access token. In the following step S117, the AEF 30C transmits a response to the Northbound API call to the UE 20. The API call is executed in the procedure from step S113 to step S117.

[0061] Fig. 21 is a sequence (1) diagram for explaining an example of an API call by a UE and an AF in an embodiment of the present invention. Fig. 22 is a sequence (2) diagram for explaining an example of an API call by a UE and an AF in an embodiment of the present invention. Detailed operations of the examples of API calls by the UE and the AF in Figs. 12 to 16 described above will be explained using Figs. 21 and 22.

[0062] In step S201, the AMF 30E sends onboarding registration information (including CCF information and an OAuth 2.0 access token) to the AF 30A. In step S201, the AF 30A may obtain the onboarding registration information by some offline method. In step S202, a TLS connection is established between the AF 30A and the CCF 30B. In the following step S203, the AF 30A sends an onboard API call request (including an OAuth 2.0 access token and an API call public key) to the CCF 30B. In the following step S204, the CCF 30B sends an onboard API call response (including an API call ID, an API call certificate, and an onboard secret) to the AF 30A. Through the operations from step S201 to step S204, onboarding (registration) of the AF is completed.

[0063] In step S205, the UE 20 executes a bootstrap procedure with the BSF 30F and the UDM 30G. In the following step S206, the UE 20 executes an application request / response with the CCF 20B, and the CCF 20B executes an authentication request / response with the BSF 30F. In the following step S207, the UE 20 acquires an NA-GUTI. In the following step S208, the UE 20 subscribes to the CCF 30B so as to receive necessary notifications from the CCF 30B. The procedures from step S205 to step S208 complete the bootstrap procedure. That is, the AF 30A executes onboarding, and the UE 20 executes bootstrap.

[0064] In step S209, CCF 30B detects a trigger for an API call. In the following step S210, AF 30A sends a security method request to CCF 30B. In the following step S211, CCF 30B selects a security method. In the following step S212, CCF 30B sends a security method response by OAuth 2.0 Autorization Code Flow to AF 30A. The security method to be used for the API call is determined through the procedure from step S209 to step S212.

[0065] In step S213, the AF 30A confirms with the user whether or not the API can be used. The UE 20 transmits a response to the AF 30A as necessary. In the following step S214, the AF 30A transmits a CAPIF security request and an authentication request (with NA-GUTI) to the CCF 30B. In the following step S215, the CCF 30B confirms the subscriber information with the UDM 30G. In the following step S216, a TLS connection is established between the UE 20 and the CCF 30B. In the following step S217, a CAPIF security request and an authentication notification request / response are executed between the UE 20 and the CCF 30B. In the following step S218, the CCF 30B issues an authorization code and transmits it to the AF 30A. Through the procedures from step S213 to step S218, permission is obtained from the user and an authorization code is issued.

[0066] In step S219, the AF 30A transmits an access token request by OAuth 2.0 using the authorization code to the CCF 30B. In the following step S220, the CCF 30B verifies the access token request. In the following step S221, the CCF 30B responds with an access token (with an access token, expiration date, and scope) by OAuth 2.0 to the AF 30A. The access token for calling the API is acquired by the procedure from step S219 to step S221.

[0067] In step S222, a TLS connection is established between AF 30A and AEF 30C. In the following step S223, AF 30A calls the Northbound API for AEF 30C by the access token by OAuth 2.0. In the following step S224, CCF 30B checks the subscriber information for UDM 30G. In the following step S225, AEF 30C verifies the access token. In the following step S226, AEF 30C transmits a response related to the Northbound API call to AF 30A. The API call is executed in the procedure from step S222 to step S226.

[0068] From the viewpoint of line users, the above-mentioned embodiment allows end users to control the network by using APIs of the core network from their terminals based on the contract information of each subscriber. From the viewpoint of operators, by managing the granularity of APIs that each subscriber can use based on the subscriber information among the APIs released by the network, it is possible to release only the minimum necessary APIs to users.

[0069] In addition, as a preliminary step for API calls, instead of the existing Onboarding, Bootstrapping can be used to authenticate individual subscribers using the SIM information of the terminal, making it possible to identify individual subscribers who will trigger API calls.

[0070] In addition, the range of APIs that each contract holder can use can be stored in the subscriber information, and by checking that subscriber information, it is possible to manage API usage authority at an individual granularity.

[0071] In addition, when an API is called by UE 20 and AF 30A, by using the OAuth 2.0 Authorization Code Flow method, a third-party AF and an operator's network node can securely obtain the subscriber's consent and use the API permitted for each subscriber.

[0072] That is, it is possible to provide an interface that allows subscriber information to be identified in the network.

[0073] (Device configuration) Next, examples of functional configurations of the base station 10, the network node 30, and the terminal 20 that perform the processes and operations described above will be described. The base station 10, the network node 30, and the terminal 20 each include functions for performing the above-mentioned embodiments. However, the base station 10, the network node 30, and the terminal 20 may each include only a part of the functions in the embodiments.

[0074] <Base Station 10 and Network Node 30> FIG. 23 is a diagram showing an example of the functional configuration of the base station 10. As shown in FIG. 23, 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 FIG. 23 is merely an example. As long as the operation according to the embodiment of the present invention can be performed, the names of the functional divisions and the functional units may be any. The network node 30 may have the same functional configuration as the base station 10. In addition, the network node 30 having a plurality of different functions in the system architecture may be composed of a plurality of network nodes 30 separated by function. In addition, the network node 30 is not limited to a network node existing in a core network or an access network, and may correspond to a network node belonging to a PLMN domain.

[0075] The transmitter 110 includes a function of generating a signal to be transmitted to the terminal 20 or another network node 30, and transmitting the signal by wire or wirelessly. The receiver 120 includes a function of receiving various signals transmitted from the terminal 20 or another network node 30, and acquiring, for example, information of a higher layer from the received signal.

[0076] The setting unit 130 stores in a storage device preset setting information and various setting information to be transmitted to the terminal 20, and reads out from the storage device as necessary. The contents of the setting information are, for example, profile information of subscribers in the network.

[0077] As described in the embodiment, the control unit 140 performs processing related to updating profile information of a subscriber in the network. The control unit 140 also performs processing related to communication with the terminal 20. A functional unit in the control unit 140 related to signal transmission may be included in the transmitting unit 110, and a functional unit in the control unit 140 related to signal reception may be included in the receiving unit 120.

[0078] <Terminal 20> Fig. 24 is a diagram showing an example of the functional configuration of terminal 20. As shown in Fig. 24, terminal 20 has transmitting unit 210, receiving unit 220, setting unit 230, and control unit 240. The functional configuration shown in Fig. 24 is merely an example. The names of the functional divisions and functional units may be any as long as they can perform the operations related to the embodiment of the present invention.

[0079] The transmitter 210 creates a transmission signal from the transmission data and transmits the transmission signal wirelessly. The receiver 220 wirelessly receives various signals and acquires a higher layer signal from the received physical layer signal. The receiver 220 also has a function of receiving NR-PSS, NR-SSS, NR-PBCH, DL / UL control signals, reference signals, and the like transmitted from the network node 30.

[0080] The setting unit 230 stores various pieces of setting information received from the network node 30 by the receiving unit 220 in a storage device, and reads them out from the storage device as necessary. The setting unit 230 also stores setting information that is set in advance. The contents of the setting information include, for example, information related to a network to which a connection is permitted.

[0081] The control unit 240 performs processing related to connection control to the network and the network slices as described in the embodiment. A functional unit related to signal transmission in the control unit 240 may be included in the transmitting unit 210, and a functional unit related to signal reception in the control unit 240 may be included in the receiving unit 220.

[0082] (Hardware configuration) The block diagrams (FIGS. 23 and 24) used to explain the above embodiments show functional blocks. 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 combined, or may be realized using two or more devices that are physically or logically separated and directly or indirectly connected (e.g., using wires, wirelessly, etc.) and these multiple devices. The functional blocks may be realized by combining the one device or the multiple devices with software.

[0083] Functions include, but are not limited to, judgment, determination, judgment, calculation, computation, processing, derivation, investigation, search, confirmation, reception, transmission, output, access, resolution, selection, selection, establishment, comparison, assumption, expectation, consideration, broadcasting, notifying, communicating, forwarding, configuring, reconfiguring, allocation, mapping, assignment, etc. For example, a functional block (component) that performs the function of transmission is called a transmitting unit or a transmitter. In either case, as described above, there is no particular limitation on the method of realization.

[0084] For example, the network node 30, the terminal 20, etc. in an embodiment of the present disclosure may function as a computer that performs processing of the wireless communication method of the present disclosure. FIG. 25 is a diagram showing an example of a hardware configuration of the base station 10 and the terminal 20 according to an embodiment of the present disclosure. The network node 30 may have the same hardware configuration as the base station 10. The above-mentioned base station 10 and the 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.

[0085] In the following description, the term "apparatus" can be interpreted as a circuit, a device, a unit, etc. The hardware configuration of the base station 10 and the terminal 20 may be configured to include one or more of the devices shown in the figure, or may be configured to exclude some of the devices.

[0086] Each function in the base station 10 and the terminal 20 is realized by loading a specific software (program) onto hardware such as a processor 1001, a memory device 1002, etc., so that the processor 1001 performs calculations, controls communications by the communication device 1004, and controls at least one of reading and writing of data in the memory device 1002 and the auxiliary memory device 1003.

[0087] The processor 1001 controls the entire computer by running, for example, an operating system. The processor 1001 may be configured as a central processing unit (CPU) including an interface with peripheral devices, a control device, an arithmetic unit, a register, etc. For example, the above-mentioned control unit 140, control unit 240, etc. may be realized by the processor 1001.

[0088] Moreover, the processor 1001 reads out a program (program code), a software module, data, or the like from at least one of the auxiliary storage device 1003 and the communication device 1004 to the storage device 1002, and executes various processes according to the program. As the program, a program that causes a computer to execute at least a part of the operations described in the above-mentioned embodiment is used. For example, the control unit 140 of the base station 10 shown in FIG. 23 may be realized 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 FIG. 24 may be realized by a control program stored in the storage device 1002 and operated by the processor 1001. Although the above-mentioned various processes have been described as being executed by one processor 1001, they may be executed by two or more processors 1001 simultaneously or sequentially. The processor 1001 may be implemented by one or more chips. The program may be transmitted from a network via a telecommunication line.

[0089] The storage device 1002 is a computer-readable recording medium, and may be configured by at least one of, for example, a Read Only Memory (ROM), an Erasable Programmable ROM (EPROM), an Electrically Erasable Programmable ROM (EEPROM), a Random Access Memory (RAM), etc. The storage device 1002 may also be called a register, a cache, a main memory (primary storage device), etc. The storage device 1002 can store a program (program code), software modules, etc. that are executable to implement a communication method according to an embodiment of the present disclosure.

[0090] The auxiliary storage device 1003 is a computer-readable recording medium, and may be, for example, at least one of an optical disk 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 versatile disk, a Blu-ray (registered trademark) disk), a smart card, a flash memory (e.g., a card, a stick, a key drive), a floppy (registered trademark) disk, a magnetic strip, etc. The above-mentioned storage medium may be, for example, a database, a server, or other suitable medium including at least one of the storage device 1002 and the auxiliary storage device 1003.

[0091] The communication device 1004 is hardware (transmission and reception device) for performing communication between computers via at least one of a wired network and a wireless network, and is also called, for example, a network device, a network controller, a network card, a communication module, etc. The communication device 1004 may be configured to include a high-frequency switch, a duplexer, a filter, a frequency synthesizer, etc., in order to realize at least one of, for example, Frequency Division Duplex (FDD) and Time Division Duplex (TDD). For example, a transmission and reception antenna, an amplifier unit, a transmission and reception unit, a transmission line interface, etc. may be realized by the communication device 1004. The transmission and reception unit may be implemented as a transmission unit and a reception unit that are physically or logically separated from each other.

[0092] The input device 1005 is an input device (e.g., a keyboard, a mouse, a microphone, a switch, a button, a sensor, etc.) that accepts input from the outside. The output device 1006 is an output device (e.g., a display, a speaker, an LED lamp, etc.) that performs output to the outside. The input device 1005 and the output device 1006 may be integrated into one device (e.g., a touch panel).

[0093] In addition, 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 may be configured using different buses between each device.

[0094] Furthermore, the base station 10 and the terminal 20 may be configured to include hardware such as a microprocessor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable gate array (FPGA), etc., and some or all of the functional blocks may be realized by the hardware. For example, the processor 1001 may be implemented using at least one of these pieces of hardware.

[0095] (Summary of the embodiment) As described above, according to an embodiment of the present invention, there is provided a network node having a transmitting unit that authenticates a terminal and transmits a temporary identifier to the terminal, a receiving unit that receives a request including the temporary identifier or an authentication code based on the temporary identifier, and a control unit that issues an access token based on the request including the temporary identifier or the authentication code, wherein the transmitting unit transmits the access token to the terminal or an external application, the receiving unit receives an API (Application Programming Interface) call request based on the access token from the terminal or the external application, and the control unit verifies the access token and, if it determines that the API call request is authorized, executes processing based on the API call request.

[0096] With the above configuration, from the viewpoint of line users, end users themselves can use the API of the core network from their terminals and control the network based on the contract information of each subscriber. From the viewpoint of operators, by managing the granularity of APIs that each subscriber can use among the APIs released by the network based on the subscriber information, it is possible to release only the minimum necessary APIs to users. In addition, as a preparatory step for API calls, instead of the existing Onboarding, by using Bootstrapping that authenticates each subscriber using the SIM information of the terminal, it is possible to identify each subscriber who triggers an API call. In addition, by holding the range of APIs that each subscriber can use in the subscriber information and checking the subscriber information, it is possible to manage the authority to use the API at the individual granularity. In addition, in the case of API calls by the UE 20 and the AF 30A, by using the Authorization Code Flow method of OAuth 2.0, a third-party AF and the network node of the operator can safely obtain the consent of the subscriber and use the API permitted to each subscriber. In other words, it is possible to provide an interface that makes it possible to identify subscriber information in the network.

[0097] The receiving unit may receive a request related to a security method to be used for an API call from the terminal or the external application, the control unit may select a security method, and the transmitting unit may transmit a response indicating the selected security method to the terminal or the external application. With this configuration, the network node can select and set a security method to be used for an API call.

[0098] When the transmission unit transmits the access token to the external application, the control unit may authenticate and register the external application in advance. With this configuration, the network node can receive an API call related to the UE from the authenticated external application.

[0099] When the transmission unit transmits the access token to the external application, the control unit may issue the access token after confirming with a user whether or not the user can use an API. With this configuration, when an external application executes an API call, the network node can execute the API call after confirming the user's intention in advance.

[0100] When determining whether the API call request is authorized, the control unit may refer to at least permitted APIs and permitted methods for which a scope for each user is set. With this configuration, the network node can control API calls with a granularity of a scope for each user.

[0101] Furthermore, according to an embodiment of the present invention, there is provided a communication method in which a network node executes the following procedures: a transmission procedure for authenticating a terminal and transmitting a temporary identifier to the terminal; a reception procedure for receiving a request including the temporary identifier or an authentication code based on the temporary identifier; a control procedure for issuing an access token based on the request including the temporary identifier or the authentication code; a procedure for transmitting the access token to the terminal or an external application; a procedure for receiving an API (Application Programming Interface) call request based on the access token from the terminal or the external application; and a procedure for verifying the access token and, if it is determined that the API call request is authorized, executing processing based on the API call request.

[0102] With the above configuration, from the viewpoint of line users, end users themselves can use the API of the core network from their terminals and control the network based on the contract information of each subscriber. From the viewpoint of operators, by managing the granularity of APIs that each subscriber can use among the APIs released by the network based on the subscriber information, it is possible to release only the minimum necessary APIs to users. In addition, as a preparatory step for API calls, instead of the existing Onboarding, by using Bootstrapping that authenticates each subscriber using the SIM information of the terminal, it is possible to identify each subscriber who triggers an API call. In addition, by holding the range of APIs that each subscriber can use in the subscriber information and checking the subscriber information, it is possible to manage the authority to use the API at the individual granularity. In addition, in the case of API calls by the UE 20 and the AF 30A, by using the Authorization Code Flow method of OAuth 2.0, a third-party AF and the network node of the operator can safely obtain the consent of the subscriber and use the API permitted to each subscriber. In other words, it is possible to provide an interface that makes it possible to identify subscriber information in the network.

[0103] (Supplementary embodiment) Although the embodiment of the present invention has been described above, the disclosed invention is not limited to such an embodiment, and those skilled in the art will understand various modifications, modifications, alternatives, replacements, and the like. Although the description has been given using specific numerical examples to facilitate understanding of the invention, unless otherwise specified, those 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 used in combination as necessary, and matters described in one item may be applied to matters described in another item (as long as there is no contradiction). The boundaries of functional units or processing units in the functional block diagram do not necessarily correspond to the boundaries of physical parts. The operations of multiple functional units may be physically performed by one part, or the operations of one functional unit may be physically performed by multiple parts. The order of the processing procedures described in the embodiment may be changed as long as there is no contradiction. For convenience of the processing description, the network node 30 and the terminal 20 have been described using functional block diagrams, but such devices may be realized by hardware, software, or a combination thereof. The software operated by a processor contained in the network node 30 in accordance with an embodiment of the present invention and the software operated by a processor contained in the terminal 20 in accordance with an embodiment of the present invention may each be stored in a random access memory (RAM), flash memory, read only memory (ROM), EPROM, EEPROM, registers, hard disk (HDD), removable disk, CD-ROM, database, server or any other suitable storage medium.

[0104] Furthermore, the notification of information is not limited to the aspects / embodiments described in the present disclosure, and may be performed using other methods. For example, the notification of information may be performed by physical layer signaling (e.g., Downlink Control Information (DCI), Uplink Control Information (UCI)), higher layer signaling (e.g., Radio Resource Control (RRC) signaling, Medium Access Control (MAC) signaling, broadcast information (Master Information Block (MIB), System Information Block (SIB)), other signals, or a combination of these. Furthermore, the RRC signaling may be called an RRC message, and may be, for example, an RRC Connection Setup message, an RRC Connection Reconfiguration message, or the like.

[0105] Each aspect / embodiment described in the present disclosure may be applied to at least one of systems using LTE (Long Term Evolution), LTE-A (LTE-Advanced), SUPER 3G, IMT-Advanced, 4G (4th generation mobile communication system), 5G (5th generation mobile communication system), FRA (Future Radio Access), NR (new Radio), 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, UWB (Ultra-WideBand), Bluetooth (registered trademark), and other suitable systems, and next-generation systems extended based on these. In addition, a combination of multiple systems (e.g., a combination of at least one of LTE and LTE-A and 5G, etc.) may be applied.

[0106] The steps, sequences, flow charts, etc. of each aspect / embodiment described herein may be reordered unless inconsistent. For example, the methods described in this disclosure present elements of various steps using an example order, and are not limited to the particular order presented.

[0107] In this specification, a specific operation performed by the network node 30 may be performed by its upper node in some cases. In a network consisting of one or more network nodes including the network node 30, it is clear that various operations performed for communication with the terminal 20 may be performed by at least one of the network node 30 and other network nodes other than the network node 30 (e.g., MME or S-GW, etc., but are not limited to these). Although the above example illustrates a case where there is one other network node other than the network node 30, the other network node may be a combination of multiple other network nodes (e.g., MME and S-GW).

[0108] The information or signals described in the present disclosure may be output from a higher layer (or a lower layer) to a lower layer (or a higher layer), or may be input / output via multiple network nodes.

[0109] The input and output information may be stored in a specific location (e.g., memory) or may be managed using a management table. The input and output information may be overwritten, updated, or added to. The output information may be deleted. The input information may be transmitted to another device.

[0110] In the present disclosure, the determination may be made based on a value represented by one bit (0 or 1), a Boolean value (true or false), or a numerical comparison (e.g., comparison with a predetermined value).

[0111] Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executable files, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise.

[0112] Additionally, software, instructions, information, etc. may be transmitted or received over a transmission medium. For example, if the software is transmitted from a website, server, or other remote source using wired and / or wireless technologies (such as coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL)), and / or wireless technologies (such as infrared, microwave, etc.), then these wired and / or wireless technologies are included within the definition of transmission media.

[0113] The information, signals, etc. described in this disclosure may be represented using any of a variety of different technologies. 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 voltages, currents, electromagnetic waves, magnetic fields or magnetic particles, optical fields or photons, or any combination thereof.

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

[0115] As used in this disclosure, the terms "system" and "network" are used interchangeably.

[0116] In addition, the information, parameters, etc. described in the present disclosure may be represented using absolute values, may be represented using relative values ​​from a predetermined value, or may be represented using other corresponding information. For example, a radio resource may be indicated by an index.

[0117] The names used for the above-mentioned parameters are not limiting in any way. Moreover, the formulas using these parameters may differ from those explicitly disclosed in this disclosure. The various channels (e.g., PUCCH, PDCCH, etc.) and information elements may be identified by any suitable names, and therefore the various names assigned to these various channels and information elements are not limiting in any way.

[0118] In the present disclosure, terms such as "base station (BS)", "wireless base station", "base station device", "fixed station", "NodeB", "eNodeB (eNB)", "gNodeB (gNB)", "access point", "transmission point", "reception point", "transmission / reception point", "cell", "sector", "cell group", "carrier", "component carrier", etc. may be used interchangeably. A base station may also be referred to by terms such as a macro cell, a small cell, a femto cell, a pico cell, etc.

[0119] A base station can accommodate one or more (e.g., three) cells. When a base station accommodates multiple cells, the entire coverage area of ​​the base station can be divided into multiple smaller areas, and each smaller area can also be provided with communication services by a base station subsystem (e.g., a small indoor base station (RRH: Remote Radio Head). The term "cell" or "sector" refers to a part or the entire coverage area of ​​a base station and / or a base station subsystem that provides communication services in this coverage.

[0120] In this disclosure, the terms "Mobile Station (MS)", "user terminal", "User Equipment (UE)", "terminal", etc. may be used interchangeably.

[0121] 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 some other suitable terminology.

[0122] 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 be a device mounted on a moving body, the moving body itself, etc. The moving body may be a vehicle (e.g., a car, an airplane, etc.), an unmanned moving body (e.g., a drone, an autonomous vehicle, etc.), or a robot (manned or unmanned). At least one of the base station and the mobile station may include a device that does not necessarily move during communication operation. 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.

[0123] Furthermore, the base station in the present disclosure may be read as a user terminal. For example, each aspect / embodiment of the present disclosure may be applied to a configuration in which communication between a base station and a user terminal is replaced with communication between a plurality of terminals 20 (which may be called, for example, D2D (Device-to-Device) or V2X (Vehicle-to-Everything)). In this case, the terminal 20 may be configured to have the functions of the above-mentioned network node 30. Furthermore, terms such as "uplink" and "downlink" may be read as terms corresponding to terminal-to-terminal communication (for example, "side"). For example, an uplink channel, a downlink channel, etc. may be read as a side channel.

[0124] Similarly, a user terminal in the present disclosure may be read as a base station. In this case, the base station may be configured to have the functions of the above-mentioned user terminal.

[0125] As used in this disclosure, the terms "determining" and "determining" may encompass a wide variety of actions. "Determining" and "determining" may include, for example, judging, calculating, computing, processing, deriving, investigating, looking up, search, inquiry (e.g., searching in a table, database, or other data structure), ascertaining, and the like. "Determining" and "determining" may also include receiving (e.g., receiving information), transmitting (e.g., sending information), input, output, accessing (e.g., accessing data in a memory), and the like. In addition, "judgment" and "decision" can include considering resolving, selecting, choosing, establishing, comparing, etc., to be a "judgment" or "decision." In other words, "judgment" and "decision" can include considering some action to be a "judgment" or "decision." In addition, "judgment" can be interpreted as "assuming," "expecting," "considering," etc.

[0126] The terms "connected," "coupled," or any variation thereof, refer to 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" to each other. The coupling or connection between elements may be physical, logical, or a combination thereof. For example, "connected" may be read as "access." As used in this disclosure, two elements may be considered to be "connected" or "coupled" to each other using at least one of one or more wires, cables, and printed electrical connections, as well as electromagnetic energy having wavelengths in the radio frequency range, microwave range, and optical (both visible and invisible) range, as some non-limiting and non-exhaustive examples.

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

[0128] As used in this disclosure, the phrase "based on" does not mean "based only on," unless expressly stated otherwise. In other words, the phrase "based on" means both "based only on" and "based at least on."

[0129] Any reference to an element using a designation such as "first," "second," etc., 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 method of distinguishing between two or more elements. Thus, a reference to a first and a second element does not imply that only two elements may be employed or that the first element must precede the second element in some way.

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

[0131] When the terms "include," "including," and variations thereof are used in this disclosure, these terms are intended to be inclusive, similar to the term "comprising." Further, when used in this disclosure, the term "or" is not intended to be an exclusive or.

[0132] In this disclosure, where articles have been added due to translation, such as a, an, and the in English, the disclosure may include that the nouns following these articles are in the plural form.

[0133] In the present 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 "coupled" may also be interpreted in the same way as "different."

[0134] Each aspect / embodiment described in this disclosure may be used alone, in combination, or switched according to execution. In addition, notification of specific information (e.g., notification that "X is the case") is not limited to being done explicitly, but may be done implicitly (e.g., not notifying the specific information).

[0135] In addition, in the present disclosure, the AF is an example of an external application, and the NA-GUTI is an example of a temporary identifier.

[0136] Although the present disclosure has been described in detail above, it is clear to those skilled in the art that the present disclosure is not limited to the embodiments described in the present disclosure. The present disclosure can be implemented in modified and altered forms without departing from the spirit and scope of the present disclosure as defined by the claims. Therefore, the description of the present disclosure is intended to be illustrative and does not have any limiting meaning on the present disclosure. [Explanation of symbols]

[0137] 10 base station 110 Transmitter 120 Receiving unit 130 Setting section 140 Control section 20 Terminals 210 Transmitter 220 Receiving unit 230 Setting section 240 Control Unit 30 Network Nodes 1001 Processor 1002 Storage device 1003 Auxiliary storage device 1004 Communication equipment 1005 Input Device 1006 Output device

Claims

1. a transmission unit that authenticates the terminal and transmits a temporary identifier to the terminal; a receiving unit for receiving a request including the temporary identifier or an authentication code based on the temporary identifier; a control unit that issues an access token based on a request including the temporary identifier or the authentication code, The transmission unit transmits the access token to the terminal or an external application, The receiving unit receives an API (Application Programming Interface) call request based on the access token from the terminal or the external application, The control unit is a network node that executes processing based on the API call request if it verifies the access token and determines that the API call request is authorized.

2. The receiving unit receives a request related to a security method used for an API call from the terminal or the external application, The control unit selects a security method, The network node of claim 1 , wherein the sending unit is configured to send a response indicating the selected security method to the terminal or an external application.

3. The network node according to claim 1 , wherein when the transmission unit transmits the access token to the external application, the control unit authenticates and registers the external application in advance.

4. The network node according to claim 3 , wherein when the transmission unit transmits the access token to the external application, the control unit issues the access token after confirming with a user whether or not API usage is permitted.

5. 2. The network node according to claim 1, wherein the control unit, when determining whether the API call request is authorized, refers to at least an allowed API and an allowed method, for which a scope is set for each user.

6. a transmission step of authenticating the terminal and transmitting a temporary identifier to the terminal; a receiving step of receiving a request including the temporary identifier or an authentication code based on the temporary identifier; a control procedure for issuing an access token based on a request including the temporary identifier or the authentication code; sending the access token to the terminal or an external application; receiving an API (Application Programming Interface) call request based on the access token from the terminal or the external application; a step of verifying the access token and, if it is determined that the API call request is authorized, executing processing based on the API call request.