JP7613818B2 - Network node and communication method - Google Patents

Description

The present invention relates to a network node and a communication method in a communication system.

3GPP (3rd Generation Partnership Project) is studying a wireless communication method called 5G or NR (New Radio) (hereinafter, the wireless communication method 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 reducing the latency in wireless sections to 1 ms or less.

In NR, a network architecture is being considered that includes 5GC (5G Core Network), which corresponds to EPC (Evolved Packet Core), the 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), the RAN (Radio Access Network) in the network architecture of LTE (for example, non-patent document 1).

In addition, for example, an architecture is being considered in which the northbound interface between the NEF (Network Exposure Function) and the AF (Application Function) in a 5G system is configured using CAPIF (Common API Framework) (for example, Non-Patent Document 2 and Non-Patent Document 3).

3GPP TS 23.501 V16.7.0 (2020-12) 3GPP TS 29.522 V16.6.0 (2020-12) 3GPP TS 23.222 V16.9.0 (2020-09)

The 3GPP core network exposes APIs (Application Programming Interfaces) for external applications, allowing third-party applications to call the APIs. 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 appropriate services.

The present invention has been made in consideration of the above points and aims to provide an interface that enables subscriber information to be identified in a network.

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.

The disclosed technology provides an interface that enables subscriber information to be identified in a network.

FIG. 1 is a diagram illustrating an example of a communication system. FIG. 1 is a diagram illustrating an example of a communication system in a roaming environment. FIG. 1 is a diagram showing an example of an API call (1). A figure showing an example of an API call (2-1). A figure showing an example of an API call (2-2). A figure showing an example of an API call (3-1). A figure showing an example of an API call (3-2). FIG. 13 is a diagram showing an example of an API call (4). FIG. 1 is a diagram for explaining an example (1) of an API call by a UE in an embodiment of the present invention. FIG. 13 is a diagram for explaining an example (2) of an API call by a UE in an embodiment of the present invention. FIG. 13 is a diagram for explaining an example (3) of an API call by a UE in an embodiment of the present invention. FIG. 1 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. FIG. 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. FIG. 13 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. FIG. 13 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. FIG. 13 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. FIG. 2 is a diagram for explaining the scope of an API according to an embodiment of the present invention. A diagram showing an example of a system including a UE and an AF in an embodiment of the present invention. FIG. 1 is a diagram illustrating an example of a system including a UE according to an embodiment of the present invention. FIG. 11 is a sequence diagram for explaining an example of an API call by a UE in an embodiment of the present invention. FIG. 13 is a sequence diagram (1) for explaining an example of an API call by a UE and an AF in an embodiment of the present invention. FIG. 13 is a sequence diagram (2) for explaining an example of an API call by a UE and an AF in an embodiment of the present invention. FIG. 2 is a diagram illustrating an example of a functional configuration of a base station 10 according to an embodiment of the present invention. FIG. 2 is a diagram illustrating an example of a functional configuration of a terminal 20 according to an embodiment of the present invention. 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.

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 applicable is not limited to the following embodiment.

Existing technology is used as appropriate in the operation of the wireless communication system of the embodiment of the present invention. However, the existing technology is, for example, the existing LTE, but is not limited to the existing LTE. Furthermore, the term "LTE" used in this specification has a broad meaning including LTE-Advanced and systems subsequent to LTE-Advanced (e.g., NR), or wireless LAN (Local Area Network), unless otherwise specified.

In addition, in an embodiment of the present invention, "configuring" radio parameters, etc. may mean that predetermined values are pre-configured, or that radio parameters notified from the network node 30 or the terminal 20 are configured.

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

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 a UE, an AMF (Access and Mobility Management Function), and a 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 a 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 in the embodiment of the present invention, multiple network slices are constructed.

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.

The SMF is a network node 30 having functions such as session management, UE IP (Internet Protocol) address allocation and management, 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 an allowed 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 controlling the policy of the network. 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.

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

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 to 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 in the embodiment of the present invention, multiple network slices are constructed.

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.

The SMF is a network node 30 having functions such as session management, UE IP address allocation and management, 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 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 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 the visited network, and the hSEPP is a SEPP in the home network.

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

It is being considered to implement the above-mentioned NEF by applying the Common API Framework (CAPIF) 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 the service API from outside the PLMN trust domain.

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

As shown in FIG. 3, an API calling application 30A is pre-registered with 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 API calling application 30A calls an API of the core network, a service API is released by an API exposing function (also referred to as an AEF) 30C for the authenticated and/or authorized external application.

Figure 4 is a diagram showing an example of an API call (2-1). Figure 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 the desired timing according to the contract. As shown in Figure 4, a QoS change request is sent from the user's application to a NEF included in 5GS (5G System) as an API call of the core network, and the QoS change is executed.

However, in the conventional technology, it is not possible to determine which user can change the QoS of which user, and it becomes 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 subscriber 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 the end user's smartphone, etc.

In the following, this embodiment will explain the proposal 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 that the operator provides 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 also be applied when the end user uses that API himself.

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

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 who does not have a QoS change option (or generally does not have 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 UE 20A corresponding to a game player with a QoS change option and to reject a QoS change request from UE 20B corresponding to a game player without a QoS change option. In FIG. 7, the API caller is a third-party game server, etc.

Therefore, the CAPIF core function 30B may authenticate each terminal and authorize the use of the API. It may also manage a scope that specifies which API each terminal may call. It may also be possible to change only the QoS of a specified UE within that scope.

Figure 8 is a diagram showing an example of an API call (4). Figure 8 shows an example of an AF calling an API in the prior art. As shown in Figure 8, the API caller 30A onboards the CAPIF core function 30B. "Onboarding" here refers to the operation in which the CAPIF core function 30B authenticates the API caller 30A, performs a one-time registration, and allows the API caller 30A to access the 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.

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

Figure 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, enabling the UE 20 and the CAPIF core function 30B to communicate directly. 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.

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

In the following step 4, CCF 30B identifies the subscriber from the temporary identifier and confirms the subscriber information with UDM 30G. In the following step 5, UDM 30G returns the subscriber information. UDM 30G may return to CCF 30B as subscriber information a table associated with the authorized APIs, methods, and target users shown in FIG. 10.

In the next step 6, if CCF 30B determines that UE 20 is permitted to call the target API based on the permitted APIs and methods in the table, CCF 30B issues an access token to the UE. In the example shown in Figure 10, for example, when AsSessionWithQoS is called from UE 20, since it is a permitted API, an access token is issued from CCF 30B.

In the next step 7, UE 20 uses the received access token to call a service API addressed to AEF 30C. For example, as shown in FIG. 10, 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 AEF 30C.

Figure 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 approved. 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 to CCF 30B as subscriber information a table in which the permitted APIs, methods, and target users shown in Figure 11 are associated. In the following step 11, CCF 30B determines whether the API request may be approved based on the subscriber information and the API request, and returns the result to AEF 30C.

For example, CCF30B may compare the request "API:AsSessionWithQoS, IP address of user to be changed is xxx.xxx.xxx.xxx" with the "Target User" in the subscriber information shown in Figure 11, and determine that use of the API may be approved if the QoS change to the target user is permitted in the subscriber information. In the subsequent step 12, if use of the API is approved in CCF30B, AEF30C executes processing according to the request and returns the result of whether or not the API can be used to UE20.

Figure 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 the CAPIF core function 30B. This onboarding may be similar to the conventional technology. In step 1', in parallel with step 1, the BSF 30F and the UDM 30G authenticate the UE 20 by executing a Bootstrapping procedure, enabling the UE 20 and the CAPIF core function 30B to communicate directly. The UE 20 receives a temporary identifier from the CCF 30B. The temporary identifier may be, for example, NA-GUTI.

Figure 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 due to a request from the UE 20, etc. 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 may determine that the QoS needs to be changed for the user.

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

Figure 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 CCF 30B, specifying the temporary identifier of UE 20 and the API to be called. In the following step 6, CCF 30B identifies the target UE (contractor) from the temporary identifier and confirms the subscriber information of the contractor with UDM 30G.

In the following step 7, UDM30G returns the subscriber information. UDM30G may return to CCF30B as the subscriber information a table in which the permitted APIs, methods, and target users shown in FIG. 12 are associated. In the following step 8, CCF30B determines whether the contract is permitted to call the target API based on the subscriber information, and notifies UE20 of the result. Here, UE20 may authorize API use by entering a password, etc., if necessary. In the following step 9, CCF30B issues an Authorization Code to API caller 30A indicating that API use has been authorized.

Figure 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 requests an access token for the API call using the authorization code and receives the access token from the CCF 30B. In the following step 11, the API caller 30A accesses the service API using the access token.

Figure 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, AEF 30C confirms with CCF 30B whether the API request may be authorized. In the following step 13, CCF 30B requests subscriber information of the subscriber who made the API call from UDM 30G. In the following step 14, UDM 30G returns the subscriber information. UDM 30G may return to CCF 30B as subscriber information a table in which the permitted APIs, methods, and target users shown in Figure 16 are associated.

In the following step 15, CCF 30B determines whether the API request is acceptable based on the subscriber information and the API request, and returns the result to AEF 30C. In the following step 16, if CCF 30B approves the API usage, AEF 30C executes processing according to the request and returns the result of whether the API usage is acceptable to API caller 30A.

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

Also, for example, UDM30G may predefine a role correspondence table as a typical scope setting by associating a role, a method, and a target user as one entry, as in option 2 shown in Figure 17, and return information indicating the permitted API and the role to CCF30B. In other words, CCF30B may identify the operations permitted by each API by associating each subscriber with a role.

Figure 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 Figure 18, the CCF 30B including the CAPIF-API, the AEF 30C including the service API, the APF (API Publishing Function) 30D, the AMF (API Management Function) 30E, the core network, and the access network belong to the PLMN (PLMN Trust domain), which is a trusted domain. On the other hand, outside the PLMN, there exist an API caller 30A (e.g., a game server) and a UE 20.

As shown in FIG. 18, the API caller 30A may be connected to the AEF 30C via a core network and may be capable of calling 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.

Figure 19 is a diagram showing an example of a system including a UE in an embodiment of the present invention. As shown in Figure 18, the PLMN, which is a trusted domain, includes CCF30B including CAPIF-API, AEF30C including a service API, APF30D, AMF30E, a core network, and an access network. On the other hand, UE20 exists outside the PLMN.

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

18 and 19 show an example of a system configuration, and are not limited to this. For example, AEF30C, APF30D, and AMF30E may be outside the trusted PLMN domain.

Figure 20 is a sequence diagram for explaining an example of an API call by a UE in an embodiment of the present invention. Using Figure 20, detailed operations of the example of an API call by a UE in Figures 8 to 11 described above will be explained.

In step S101, UE 20 executes a Bootstrapping procedure with BSF 30F and UDM 30G. In the following step S102, UE 20 executes an application request/response with CCF 20B, and CCF 20B executes an authentication request/response with BSF 30F. In the following step S103, UE 20 acquires NA-GUTI. In the following step S104, UE 20 subscribes to CCF 30B so as to receive necessary notifications from CCF 30B. In the following step S105, a Transport Layer Security (TLS) connection is established between UE 20 and CCF 30B. 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 CCF. Note that step S104 may or may not be executed.

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

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

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

Figure 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. Figure 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. Using Figures 21 and 22, detailed operations of the examples of API calls by the UE and the AF in Figures 12 to 16 described above will be explained.

In step S201, AMF30E sends Onboarding registration information (with CCF information and OAuth 2.0 access token) to AF30A. Step S201 may be AF30A obtaining the Onboarding registration information in some offline manner. In step S202, a TLS connection is established between AF30A and CCF30B. In the following step S203, AF30A sends an Onboard API call request (with OAuth 2.0 access token and API call public key) to CCF30B. In the following step S204, CCF30B sends an Onboard API call response (with API call ID, API call certificate, and Onboard secret) to AF30A. Through the operations from step S201 to step S204, AF onboarding (registration) is completed.

In step S205, UE 20 executes the Bootstrapping procedure with BSF 30F and UDM 30G. In the following step S206, UE 20 executes an application request/response with CCF 20B, and CCF 20B executes an authentication request/response with BSF 30F. In the following step S207, UE 20 acquires NA-GUTI. In the following step S208, UE 20 subscribes to CCF 30B so as to receive necessary notifications from CCF 30B. Bootstrapping is completed by the procedures from step S205 to step S208. That is, AF 30A executes Onboarding, and UE 20 executes Bootstrapping.

In step S209, CCF 30B detects the trigger of the 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 Automation Code Flow to AF 30A. The security method to be used for the API call is determined by the procedure from step S209 to step S212.

In step S213, AF30A confirms with the user whether or not the API can be used. UE20 sends a response to AF30A as necessary. In the following step S214, AF30A sends a CAPIF security request and an authentication request (with NA-GUTI) to CCF30B. In the following step S215, CCF30B confirms the subscriber information with UDM30G. In the following step S216, a TLS connection is established between UE20 and CCF30B. In the following step S217, a CAPIF security request and an authentication notification request/response are executed between UE20 and CCF30B. In the following step S218, CCF30B issues an Authorization Code and sends it to AF30A. Through the procedures from step S213 to step S218, permission is obtained from the user and an authorization code is issued.

In step S219, AF30A sends an access token request by OAuth 2.0 using the authorization code to CCF30B. In the following step S220, CCF30B verifies the access token request. In the following step S221, it responds to AF30A with an access token by OAuth 2.0 (with the access token, expiration date, and scope). The procedure from step S219 to step S221 allows an access token for an API call to be obtained.

In step S222, a TLS connection is established between AF30A and AEF30C. In the following step S223, AF30A calls the Northbound API to AEF30C using the access token by OAuth 2.0. In the following step S224, CCF30B confirms the subscriber information with UDM30G. In the following step S225, AEF30C verifies the access token. In the following step S226, AEF30C sends a response to the Northbound API call to AF30A. The API call is executed in the procedure from step S222 to step S226.

From the perspective 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 perspective of operators, by managing the granularity of APIs that each subscriber can use among the APIs released by the network based on subscriber information, it is possible to release only the minimum necessary APIs to users.

In addition, as a preliminary step for an API call, 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 an API call.

In addition, the range of APIs that each subscriber 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.

In addition, in the case of API calls by UE20 and AF30A, by using the OAuth 2.0 Authorization Code Flow method, third-party AFs and operator network nodes can securely obtain the subscriber's consent and use APIs permitted for individual subscribers.

In other words, it is possible to provide an interface that makes it possible to identify subscriber information in the network.

(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-described 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.

<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.

The transmitting unit 110 has 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 receiving unit 120 has 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.

The setting unit 130 stores in a storage device the setting information that is set in advance and various setting information to be transmitted to the terminal 20, and reads it from the storage device as necessary. The contents of the setting information include, for example, profile information of subscribers in the network.

The control unit 140 performs processing related to updating the profile information of subscribers in the network, as described in the embodiments. 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.

<Terminal 20>
Fig. 24 is a diagram showing an example of the functional configuration of the terminal 20. As shown in Fig. 24, the 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 Fig. 24 is merely an example. As long as the operation related to the embodiment of the present invention can be performed, the names of the functional divisions and functional units may be any names.

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

The setting unit 230 stores various setting information received from the network node 30 by the receiving unit 220 in a storage device, and reads it 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 the network to which connection is permitted.

The control unit 240 performs processing related to connection control to the network and network slices as described in the embodiments. 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.

(Hardware configuration)
The block diagrams (FIGS. 23 and 24) used in the description of the above embodiments show functional blocks. These functional blocks (components) are realized by any combination of at least one of hardware and software. 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 may be realized using two or more devices that are physically or logically separated and directly or indirectly connected (for example, using wires, wirelessly, etc.) and these multiple devices. The functional block may be realized by combining the one device or the multiple devices with software.

Functions include, but are not limited to, judgement, determination, judgment, calculation, computation, processing, derivation, investigation, search, confirmation, reception, transmission, output, access, resolution, selection, election, establishment, comparison, assumption, expectation, regard, broadcasting, notifying, communicating, forwarding, configuring, reconfiguring, allocating, mapping, and assignment. For example, a functional block (component) that performs the transmission function is called a transmitting unit or transmitter. As mentioned above, there are no particular limitations on the method of realization for either of these.

For example, the network node 30, terminal 20, etc. in one 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 the hardware configuration of the base station 10 and terminal 20 in 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 memory device 1002, an auxiliary memory device 1003, a communication device 1004, an input device 1005, an output device 1006, a bus 1007, etc.

In the following description, the term "apparatus" may be interpreted as a circuit, device, 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.

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

The processor 1001, for example, operates an operating system to control the entire computer. 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.

The processor 1001 reads out a program (program code), a software module, or data, etc., 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. A program that causes a computer to execute at least a part of the operations described in the above-mentioned embodiment is used as the program. 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. 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 simultaneously or sequentially by two or more processors 1001. The processor 1001 may be implemented by one or more chips. The program may be transmitted from a network via a telecommunication line.

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

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.

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 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., to realize at least one of, for example, Frequency Division Duplex (FDD) and Time Division Duplex (TDD). For example, a transmitting/receiving antenna, an amplifier unit, a transmitting/receiving unit, a transmission line interface, etc. may be realized by the communication device 1004. The transmitting/receiving unit may be implemented as a transmitting unit and a receiving unit that are physically or logically separated.

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. Note that the input device 1005 and the output device 1006 may be integrated into one configuration (e.g., a touch panel).

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.

In addition, 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), or a field programmable gate array (FPGA), 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.

(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.

From the viewpoint of line users, the above configuration allows end users to control the network by using the 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 the 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, bootstrapping is used to authenticate each subscriber using the SIM information of the terminal, thereby making it possible to identify each subscriber who triggers an API call. In addition, the range of APIs that each subscriber can use is stored in the subscriber information, and the authority to use the API can be managed at the individual granularity by checking the subscriber information. In addition, in the case of an API call by the UE 20 and the AF 30A, by using the Authorization Code Flow method of OAuth 2.0, a third-party AF and a network node of an operator can safely obtain consent from a subscriber and use an API permitted to each subscriber. In other words, an interface that makes it possible to identify subscriber information in a network can be provided.

The receiving unit may receive a request for 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.

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

When the transmission unit transmits the access token to the external application, the control unit may issue the access token after confirming with the user whether or not the API can be used. 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.

When determining whether the API invocation request is authorized, the control unit may refer to at least permitted APIs and permitted methods for which a per-user scope is set. With this configuration, the network node can control API invocations with a per-user granularity scope.

In addition, according to an embodiment of the present invention, a communication method is provided in which a network node executes the following steps: 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 executing processing based on the API call request if it is determined that the API call request is authorized.

From the viewpoint of line users, the above configuration allows end users to control the network by using the 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 the 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, bootstrapping is used to authenticate each subscriber using the SIM information of the terminal, thereby making it possible to identify each subscriber who triggers an API call. In addition, the range of APIs that each subscriber can use is stored in the subscriber information, and the authority to use the API can be managed at the individual granularity by checking the subscriber information. In addition, in the case of an API call by the UE 20 and the AF 30A, by using the Authorization Code Flow method of OAuth 2.0, a third-party AF and a network node of an operator can safely obtain consent from a subscriber and use an API permitted to each subscriber. In other words, an interface that makes it possible to identify subscriber information in a network can be provided.

(Supplementary description of the 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 value 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 the processor of the network node 30 in accordance with an embodiment of the present invention and the software operated by the processor of the terminal 20 in accordance with an embodiment of the present invention may each 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 the like.

In addition, 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., DCI (Downlink Control Information), UCI (Uplink Control Information)), higher 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. In addition, the RRC signaling may be called an RRC message, and may be, for example, an RRC Connection Setup message, an RRC Connection Reconfiguration message, etc.

Each aspect/embodiment described in this disclosure may be applied to at least one of systems utilizing LTE (Long Term Evolution), LTE-Advanced (LTE-A), 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), or other suitable systems, and next generation systems enhanced based on these. In addition, multiple systems may be applied in combination (for example, a combination of at least one of LTE and LTE-A with 5G, etc.).

The processing 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.

In this specification, a particular operation that is described as being performed by the network node 30 may in some cases be performed by its upper node. In a network consisting of one or more network nodes having the network node 30, it is clear that various operations performed for communication with the terminal 20 may be performed by the network node 30 and at least one of 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 shows 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).

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

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

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

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.

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

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.

Note that 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 the channel and the symbol may be a signal (signaling). Also, the signal may be a message. Also, a component carrier (CC) may be called a carrier frequency, a cell, a frequency carrier, etc.

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

In addition, the information, parameters, etc. described in this disclosure may be expressed using absolute values, may be expressed using relative values from a predetermined value, or may be expressed using other corresponding information. For example, radio resources may be indicated by an index.

The names used for the above-mentioned parameters are not limiting in any way. Moreover, the formulas etc. 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.

In this disclosure, terms such as "base station (BS)", "radio 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", and "component carrier" may be used interchangeably. A base station may also be referred to by terms such as macrocell, small cell, femtocell, and picocell.

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 provide 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 at least one of the base station and base station subsystem that provides communication services in this coverage.

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

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.

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.

In addition, 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 multiple terminals 20 (which may be called, for example, D2D (Device-to-Device), V2X (Vehicle-to-Everything), etc.). In this case, the terminal 20 may be configured to have the functions possessed by 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, the uplink channel, downlink channel, etc. may be read as a side channel.

Similarly, the user terminal in this disclosure may be interpreted as a base station. In this case, the base station may be configured to have the functions of the user terminal described above.

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, searching, inquiring (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 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." Furthermore, "judgment (decision)" can be interpreted as "assuming," "expecting," "considering," etc.

The terms "connected" and "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 light (both visible and invisible) range, as some non-limiting and non-exhaustive examples.

The reference signal may also be abbreviated as RS (Reference Signal) or may be called a pilot depending on the applicable standard.

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."

Any reference to elements using designations 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 way to distinguish 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.

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

When used in this disclosure, the terms "include," "including," and variations thereof are intended to be inclusive, similar to the term "comprising." Additionally, the term "or," as used in this disclosure, is not intended to be an exclusive or.

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

In this disclosure, the term "A and B are different" may mean "A and B are different from each other." In addition, the term may mean "A and B are each different from C." Terms such as "separate" and "combined" may also be interpreted in the same way as "different."

Each aspect/embodiment described in this disclosure may be used alone, in combination, or switched depending on the 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).

Note that AF in this disclosure is an example of an external application. NA-GUTI is an example of a temporary identifier.

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 herein. 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.

10 Base station 110 Transmitter 120 Receiver 130 Setting unit 140 Control unit 20 Terminal 210 Transmitter 220 Receiver 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

Claims (6)

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. 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. A network node as described in claim 1, wherein when the transmission unit transmits the access token to the external application, the control unit pre-authenticates and registers the external application. A network node as described in 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 the user whether or not the API can be used. A network node as described in claim 1, wherein the control unit, when determining whether the API call request is authorized, refers to at least permitted APIs and permitted methods, for which a scope is set for each user. 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.

Images