WO2022195878A1 - ネットワークノード及び通信方法 - Google Patents

ネットワークノード及び通信方法 Download PDF

Info

Publication number
WO2022195878A1
WO2022195878A1 PCT/JP2021/011495 JP2021011495W WO2022195878A1 WO 2022195878 A1 WO2022195878 A1 WO 2022195878A1 JP 2021011495 W JP2021011495 W JP 2021011495W WO 2022195878 A1 WO2022195878 A1 WO 2022195878A1
Authority
WO
WIPO (PCT)
Prior art keywords
api
terminal
access token
network
network node
Prior art date
Application number
PCT/JP2021/011495
Other languages
English (en)
French (fr)
Inventor
悠司 鈴木
淳 巳之口
Original Assignee
株式会社Ｎｔｔドコモ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社Ｎｔｔドコモ filed Critical 株式会社Ｎｔｔドコモ
Priority to JP2023506691A priority Critical patent/JPWO2022195878A1/ja
Priority to PCT/JP2021/011495 priority patent/WO2022195878A1/ja
Publication of WO2022195878A1 publication Critical patent/WO2022195878A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication

Definitions

  • the present invention relates to a network node and communication method in a communication system.
  • 5G or NR New Radio
  • NR New Radio
  • 5G A wireless communication system called “5G” (hereinafter, the wireless communication system is referred to as “5G” or "NR”) is under study.
  • 5G various radio technologies are being studied in order to meet the requirements of realizing a throughput of 10 Gbps or more and keeping the delay in the radio section to 1 ms or less.
  • 5GC 5G Core Network
  • EPC Evolved Packet Core
  • LTE Long Term Evolution
  • E-UTRAN Radio Access Network
  • NG-RAN Next Generation-Radio Access Network
  • Evolved Universal Terrestrial Radio Access Network A network architecture including NG-RAN (Next Generation-Radio Access Network) corresponding to Evolved Universal Terrestrial Radio Access Network
  • NEF Network Exposure Function
  • AF Application Function
  • CAPIF Common API Framework
  • the 3GPP core network has released an API (Application Programming Interface) for external applications, which can be called from third-party applications.
  • API Application Programming Interface
  • the core network cannot provide an appropriate service because it is difficult to identify the user who uses the third-party application.
  • the present invention has been made in view of the above points, and an object of the present invention is to provide an interface that enables identification of subscriber information in a network.
  • a transmitting unit that authenticates a terminal and transmits a temporary identifier to the terminal, a receiving unit that receives a request containing the temporary identifier or an authentication code based on the temporary identifier, and a request containing the temporary identifier or a control unit that issues an access token based on the authentication code, the transmission unit transmits the access token to the terminal or an external application, and the reception unit uses an API based on the access token ( Application Programming Interface) call request is received from the terminal or the external application, and the control unit verifies the access token and determines that the API call request is authorized.
  • a network node is provided for performing processing based on.
  • FIG. 1 is a diagram for explaining an example of a communication system;
  • FIG. 1 is a diagram for explaining an example of a communication system in a roaming environment;
  • FIG. FIG. 4 is a diagram showing an example (1) of API calls;
  • FIG. 10 is a diagram showing an example (2-1) of API calls;
  • FIG. 10 is a diagram showing an example (2-2) of API calls;
  • FIG. 10 is a diagram showing an example (3-1) of API calls;
  • FIG. 10 is a diagram showing an example (3-2) of API calls;
  • FIG. 10 is a diagram showing an example (4) of API calls;
  • FIG. 4 is a diagram for explaining example (1) of API call by UE in the embodiment of the present invention;
  • FIG. 4 is a diagram for explaining example (1) of API call by UE in the embodiment of the present invention;
  • FIG. 4 is a diagram for explaining example (1) of API call by UE in the embodiment of the present invention;
  • FIG. 4 is a diagram for explaining example (1) of API call by
  • FIG. 4 is a diagram for explaining an example (2) of an API call by a UE according to an embodiment of the present invention
  • FIG. 4 is a diagram for explaining an example (3) of an API call by a UE according to an embodiment of the present invention
  • FIG. 4 is a diagram for explaining an example (1) of API calls by UE and AF in the embodiment of the present invention
  • FIG. 4 is a diagram for explaining example (2) of API calls by UE and AF in the embodiment of the present invention
  • FIG. 4 is a diagram for explaining an example (3) of API calls by UE and AF in the embodiment of the present invention
  • FIG. 4 is a diagram for explaining an example (4) of API calls by UE and AF in the embodiment of the present invention
  • FIG. 4 is a diagram for explaining an example (5) of API calls by UE and AF in the embodiment of the present invention
  • FIG. 4 is a diagram for explaining scopes of APIs according to the embodiment of the present invention
  • 1 is a diagram showing an example of a system including UE and AF in an embodiment of the invention
  • FIG. 1 is a diagram showing an example of a system including UEs in an embodiment of the invention
  • FIG. 4 is a sequence diagram for explaining an example of API calls by the UE in the embodiment of the present invention
  • It is a sequence (1) figure for demonstrating the example of API call by UE and AF in embodiment of this invention.
  • It is a sequence (2) figure for demonstrating the example of API call by UE and AF in embodiment of this invention.
  • FIG. 2 is a diagram showing an example of the functional configuration of terminal 20 according to the embodiment of the present invention.
  • FIG. 2 is a diagram showing an example of hardware configurations of base station 10 and terminal 20 according to an embodiment of the present invention;
  • LTE Long Term Evolution
  • LTE-Advanced and LTE-Advanced and later systems eg: NR
  • wireless LAN Local Area Network
  • “configuring" the wireless parameters and the like may mean that predetermined values are set in advance (pre-configure), or the network node 30 or A wireless parameter notified from the terminal 20 may be set.
  • FIG. 1 is a diagram for explaining an example of a communication system.
  • a communication system consists of a UE, which is a terminal 20 , and a plurality of network nodes 30 .
  • one network node 30 corresponds to each function, but one network node 30 may realize a plurality of functions, or a plurality of network nodes 30 may realize one function.
  • the "connection" described below may be a logical connection or a physical connection.
  • a RAN Radio Access Network
  • AMF Access and Mobility Management Function
  • UPF User plane function
  • the AMF is a network node 30 having functions such as RAN interface termination, NAS (Non-Access Stratum) termination, registration management, connection management, reachability management, and mobility management.
  • the UPF is a network node 30 that has 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.
  • PDU Protocol Data Unit
  • DN Data Network
  • packet routing and forwarding and user plane QoS (Quality of Service) handling.
  • UPF and DN constitute a network slice.
  • a plurality of network slices are constructed in the wireless communication network according to the embodiment of the present invention.
  • AMF is 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) are connected.
  • AMF, SMF, NSSF, NEF, NRF, UDM, AUSF, PCF, AF are interconnected via respective service-based interfaces Namf, Nsmf, Nnssf, Nnef, Nnrf, Nudm, Nausf, Npcf, Naf. network node 30 .
  • the SMF is a network node 30 that has 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.
  • a NEF is a network node 30 that has the function of notifying other NFs (Network Functions) of capabilities and events. NSSF selects the network slice to which the UE connects, determines the allowed NSSAI (Network Slice Selection Assistance Information), determines the NSSAI to be set, determines the AMF set to which the UE connects. be.
  • a PCF is a network node 30 having a function of performing network policy control.
  • AF is a network node 30 having the function of controlling an application server.
  • An NRF is a network node 30 that has the ability to discover NF instances that provide services.
  • a 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.
  • UDR User Data Repository
  • FIG. 2 is a diagram for explaining an example of a communication system in a roaming environment.
  • the network consists of a UE, which is a terminal 20 , and a plurality of network nodes 30 .
  • one network node 30 corresponds to each function, but one network node 30 may realize a plurality of functions, or a plurality of network nodes 30 may realize one function.
  • the "connection" described below may be a logical connection or a physical connection.
  • RAN is a network node 30 with radio access functionality and is connected with UE, AMF and UPF.
  • the AMF is a network node 30 having functions such as RAN interface termination, NAS termination, registration management, connection management, reachability management, and mobility management.
  • a UPF is a network node 30 that has functions such as PDU session point to the outside world interconnecting DNs, packet routing and forwarding, user plane QoS handling, and so on.
  • UPF and DN constitute a network slice.
  • a plurality of network slices are constructed.
  • AMF is connected to UE, RAN, SMF, NSSF, NEF, NRF, UDM, AUSF, PCF, AF, and SEPP (Security Edge Protection Proxy).
  • AMF, SMF, NSSF, NEF, NRF, UDM, AUSF, PCF, AF are interconnected via respective service-based interfaces Namf, Nsmf, Nnssf, Nnef, Nnrf, Nudm, Nausf, Npcf, Naf. network node 30 .
  • the SMF is a network node 30 that has functions such as session management, UE IP address allocation and management, DHCP function, ARP proxy, roaming function, and the like.
  • a NEF is a network node 30 that has the function of notifying other NFs of capabilities and events.
  • the NSSF is a network node 30 that has functions such as selecting a network slice to which the UE connects, determining allowed NSSAIs, determining configured NSSAIs, determining the AMF set to which the UE connects, and so on.
  • a PCF is a network node 30 having a function of performing network policy control.
  • AF is a network node 30 having the function of controlling an application server.
  • An NRF is a network node 30 that has the ability to discover NF instances that provide services.
  • SEPP is a non-transparent proxy that filters control plane messages between PLMNs (Public Land Mobile Networks).
  • the vSEPP shown in FIG. 2 is the SEPP in the visited network, and the hSEPP is the SEPP in the home network.
  • the UE is in a roaming environment connected with RAN and AMF in VPLMN (Visited PLMN).
  • VPLMN and HPLMN are connected via vSEPP and hSEPP.
  • the UE can, for example, communicate with the HPLMN's UDM via the VPLMN's AMF.
  • the NEF mentioned above is being considered to implement APIs (Application Programming Interfaces) that can be called from AFs by applying the CAPIF (Common API Framework) architecture.
  • the CAPIF architecture provides mechanisms to support service API operations, for example, allowing API invokers to discover service APIs provided by API providers and to communicate using the service APIs. do.
  • the CAPIF architecture also has mechanisms to hide the topology of the PLMN trust domain, eg, from API callers accessing the service API from outside the PLMN trust domain.
  • FIG. 3 is a diagram showing an example (1) of an API call.
  • the 3GPP core network has released APIs for external applications, and the APIs can be called from third-party applications.
  • the calling application API invoker
  • the CAPIF core function also referred to as CCF
  • any application can call the API. Manage what you can do.
  • an API caller application 30A is pre-registered with the CAPIF core function 30B using the CAPIF-API.
  • CAPIF core functions 30B authenticate and/or authorize third party applications 30A.
  • the API caller application 30A calls the API of the core network, the API exposing function (also referred to as AEF .) Release the service API by 30C.
  • FIG. 4 is a diagram showing an example of an API call (2-1).
  • FIG. 5 is a diagram showing an example (2-2) of API calls.
  • a user can obtain a comfortable communication environment by sending a QoS change request at a desired timing according to a contract.
  • the user's application sends a QoS change request to the NEF included in the 5GS (5G System) as a core network API call, and the QoS change is executed.
  • the CAPIF core function 30B does not know which user's QoS change is permitted, and the API provision function 30C allows the QoS change permitted contractor to change the QoS of the QoS change disabled user. accept to change Moreover, even for services other than QoS, it is impossible to determine which user's resource can be accessed.
  • the API caller is the end user's smartphone or the like.
  • the API used by the user is not limited to QoS control, and may be any API provided by the operator for the user.
  • the API used by the user is not limited to QoS control, and may be any API provided by the operator for the user.
  • there is an API for changing the U-plane communication path of a specific user and the method described in this embodiment may also be applied when the end user himself/herself uses this API.
  • FIG. 6 is a diagram showing an example of an API call (3-1).
  • FIG. 7 is a diagram showing an example (3-2) of API calls.
  • a QoS change request is sent from the user's application to the NEF included in 5GS via the game server as a core network API call, and the QoS change is performed.
  • the prior art cannot determine which users can change the QoS of which users, and rejects QoS change requests from users without QoS change options (or generally without appropriate contracts). can't 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 cannot call the API if the game server itself is authenticated and authorized. becomes possible. As shown in FIG. 7, the operation of accepting a QoS change request from UE 20A corresponding to a game player with the QoS change option and rejecting a QoS change request from UE 20B corresponding to a game player without the QoS change option is This is the operation intended by the network side. In FIG. 7, the API caller is a third-party game server or the like.
  • the CAPIF core function 30B may authenticate individual terminals and authorize API usage. Also, a scope that defines which API each terminal can call may be managed. Also, within the scope, only the QoS of the specified UE may be changed.
  • FIG. 8 is a diagram showing an example (4) of an API call.
  • FIG. 8 shows an example of AF calling an API in the prior art.
  • API caller 30A onboards to CAPIF core function 30B.
  • "Onboarding" refers herein to the act of the CAPIF core function 30B authenticating and one-time registering the API caller 30A to authorize the API caller 30A to access the CAPIF and service APIs.
  • API caller 30A and CAPIF core function 30B agree on a security method.
  • API caller 30A requests an access token from CAPIF core function 30B, and CAPIF core function 30B issues the access token.
  • the above security method agreement uses the OAuth 2.0 Client Credential method, and API calls are authorized only with authentication of the client (API caller in FIG. 8) without the permission of the resource owner.
  • FIG. 9 is a diagram for explaining an example (1) of an API call by the UE according to the embodiment of the present invention.
  • BSF Bitstrapping Server Function
  • UDM 30G authenticate UE 20 by performing a Bootstrapping procedure, allowing UE 20 and CAPIF core function 30B to communicate directly.
  • UE 20 receives the temporary identifier from CCF 30B.
  • the temporary identifier may be, for example, NA-GUTI (Northbound Access Globally Unique Temporary Identifier).
  • NA-GUTI Northbound Access Globally Unique Temporary Identifier
  • FIG. 10 is a diagram for explaining example (2) of an API call by the UE according to the embodiment of the present invention.
  • the UE 20 specifies the temporary identifier and the API to be called, and requests the CCF 30B to issue an access token.
  • the user information to be changed or the like may be transmitted to the CCF 30B, and the access token may be issued from the CCF 30B based on the user information.
  • the CCF 30B identifies the subscriber from the temporary identifier and confirms the subscriber information with the UDM 30G.
  • the UDM 30G returns subscriber information.
  • the UDM 30G may return to the CCF 30B as subscriber information a table in which the permitted APIs, methods, and target users shown in FIG. 10 are associated.
  • the CCF 30B In the subsequent step 6, if the CCF 30B can determine that the UE 20 is permitted to call the target API based on the authorization API and method of the table, the CCF 30B issues an access token to the UE. In the example shown in FIG. 10, for example, when AssessionWithQoS is called from the UE 20, the access token is issued from the CCF 30B because it is an authorized API.
  • the UE 20 uses the received access token to call the service API addressed to the AEF 30C.
  • the access token is @@@@@@
  • the API is AsSessionWithQoS
  • the IP address of the change target user is xxx. xxx. xxx.
  • the UE 20 may call the service API by sending information indicating xxx to the AEF 30C.
  • FIG. 11 is a diagram for explaining example (3) of an API call by the UE according to the embodiment of the present invention.
  • AEF 30C confirms with CCF 30B whether to authorize the API request.
  • the CCF 30B requests the subscriber information of the subscriber calling the API from the UDM 30G.
  • the UDM 30G returns subscriber information.
  • the UDM 30G may return to the CCF 30B as subscriber information a table in which the permitted APIs, methods, and target users shown in FIG. 11 are associated.
  • the CCF 30B determines whether or not the API request may be authorized based on the subscriber information and the API request, and returns the result to the AEF 30C.
  • the CCF 30B compares the request "API:AsSessionWithQoS, the IP address of the user to be changed is xxx.xxx.xxx.xxx" with the subscriber information "target user" shown in FIG. If the QoS change to is permitted in the subscriber information, it may be determined that the use of the API may be authorized. In the following step 12, when the CCF 30B approves the use of the API, the AEF 30C executes processing according to the request and returns the result of the API use permission to the UE 20.
  • FIG. 12 is a diagram for explaining example (1) of API calls by UE and AF in the embodiment of the present invention.
  • an API caller 30A eg, game server
  • the onboarding may be similar to the prior art.
  • BSF 30F and UDM 30G authenticate UE 20 by performing a Bootstrapping procedure to allow UE 20 and CAPIF core function 30B to communicate directly.
  • UE 20 receives the temporary identifier from CCF 30B.
  • the temporary identifier may be NA-GUTI, for example.
  • FIG. 13 is a diagram for explaining example (2) of API calls by UE and AF in the embodiment of the present invention.
  • the API caller 30A detects from a request or the like from the UE 20 that a UE-triggered API call is required.
  • the UE trigger may be transmission of information indicating a QoS change request from the UE 20 to the game server, or the game server may determine that it is necessary to change the QoS for the user. It may be something that has been done.
  • step 3 when it is necessary to call an API related to the contract content of each contractor between the API caller 30A and the CCF 30B, OAuth2. 0 It is agreed to perform authorization using the Authorization Code Flow.
  • FIG. 14 is a diagram for explaining example (3) of API calls by UE and AF in the embodiment of the present invention.
  • the API caller 30A confirms with the user whether the API can be called.
  • an authorization request is transmitted to the CCF 30B specifying the temporary identifier of the UE 20 and the API to be called.
  • the CCF 30B identifies the target UE (contractor) from the temporary identifier, and confirms the subscriber information of the contractor with the UDM 30G.
  • the UDM 30G returns subscriber information.
  • the UDM 30G may return to the CCF 30B as subscriber information a table in which the permitted APIs, methods, and target users shown in FIG. 12 are associated.
  • the CCF 30B determines whether or not the contract may call the target API based on the subscriber information, and notifies the UE 20 of the result.
  • the UE 20 may permit the use of the API by entering a password or the like as necessary.
  • the CCF 30B issues an Authorization Code indicating that use of the API is authorized to the API caller 30A.
  • FIG. 15 is a diagram for explaining example (4) of API calls by UE and AF in the embodiment of the present invention.
  • 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.
  • the API caller 30A uses the access token to access the service API.
  • FIG. 16 is a diagram for explaining example (5) of API calls by UE and AF in the embodiment of the present invention.
  • AEF 30C confirms with CCF 30B whether it is okay to authorize the API request.
  • the CCF 30B requests the subscriber information of the subscriber calling the API from the UDM 30G.
  • the UDM 30G returns subscriber information.
  • the UDM 30G may return to the CCF 30B as subscriber information a table in which the permitted APIs, methods, and target users shown in FIG. 16 are associated.
  • the CCF 30B determines whether or not the API request may be approved based on the subscriber information and the API request, and returns the result to the AEF 30C.
  • the AEF 30C executes the processing according to the request and returns the API caller 30A with the result of whether or not the API can be used.
  • FIG. 17 is a diagram for explaining the scope of APIs according to the embodiment of the present invention.
  • the UDM 30G in response to the inquiry of subscriber information based on the subscriber identifier from the CCF 30B, the UDM 30G obtains the API for which the subscriber is authorized and the API for which the subscriber is authorized for each subscriber information. A list of methods and authorized users may be returned to the CCF 30B.
  • the UDM 30G may associate the authorization API, the method, and the target user and return one entry to the CCF 30, as in option 1 shown in FIG.
  • the UDM 30G predefines Roles, methods, and target users as one entry as typical scope settings as a Role correspondence table, as in option 2 shown in FIG. may be returned to the CCF 30B. That is, the CCF 30B may identify the permitted operations for each API by associating individual subscribers with Roles.
  • FIG. 18 is a diagram showing an example of a system including UEs and AFs according to the embodiment of the present invention.
  • the trusted domain PLMN PLMN Trust domain
  • CCF 30B including CAPIF-API
  • AEF 30C including service API
  • APF API Publishing Function
  • AMF API Management Function
  • core network and access network On the other hand, outside the PLMN, an API caller 30A (for example, game server) and UE 20 exist.
  • the API caller 30A may be connected to the AEF 30C via the core network, or may be able to call the CAPIF-API and the service API.
  • UE 20 may be connected to API callers 30A and AEF 30C via access networks and core networks.
  • FIG. 19 is a diagram showing an example of a system including UEs according to the embodiment of the present invention.
  • CCF 30B including CAPIF-API, AEF 30C, APF 30D, AMF 30E including service API, core network and access network belong to PLMN which is a trusted domain.
  • the UE 20 exists outside the PLMN.
  • the UE 20 may be connected to the CCF 30B and AEF 30C via the access network and core network, and may be able to call the CAPIF-API and service API.
  • FIGS. 18 and 19 show an example of the system configuration, and are not limited to this.
  • AEF 30C, APF 30D and AMF 30E may be outside the trusted PLMN domain.
  • FIG. 20 is a sequence diagram for explaining an example of API calls by the UE according to the embodiment of the present invention. Using FIG. 20, the detailed operation of the API call example by the UE from FIG. 8 to FIG. 11 described above will be described.
  • step S101 the UE 20 executes the Bootstrapping procedure with the BSF 30F and UDM 30G.
  • step S102 UE 20 performs application request/response with CCF 20B, and CCF 20B performs authentication request/response with BSF 30F.
  • step S103 the UE 20 acquires the NA-GUTI.
  • step S104 the UE 20 subscribes to the CCF 30B so as to receive necessary notifications from the CCF 30B.
  • subsequent step S105 a TLS (Transport Layer Security) connection is established between the UE 20 and the CCF 30B.
  • TLS Transport Layer Security
  • the UE 20 transmits a security method request to the CCF 30B.
  • CCF 30B selects a security method.
  • a security method response that is OAuth 2.0 Client Credential is sent from CCF 30B to UE 20.
  • a security method to be used for the API call is determined by the procedure from step S106 to step S108.
  • step S109 the UE 20 uses NA-GUTI to send an access token request based on OAuth 2.0 to the CCF 30B.
  • the CCF 30B confirms the subscriber information with the UDM 30G.
  • the CCF 30B verifies the access token request.
  • the CCF 30B responds to the UE 20 with an access token based on OAuth 2.0.
  • An access token is issued using NA-GUTI according to the procedure from step S109 to step S112, and the terminal 20 acquires the access token for calling the API.
  • a TLS connection is established between the UE 20 and the AEF 30C.
  • the UE 20 calls the Northbound API to the AEF 30C using the OAuth 2.0 access token.
  • the CCF 30B confirms the subscriber information with the UDM 30G.
  • the AEF 30C verifies the access token.
  • the AEF 30C transmits a response to the Northbound API call to the UE20.
  • An API call is executed in the procedure from step S113 to step S117.
  • FIG. 21 is a sequence (1) diagram for explaining an example of API calls by UE and AF in the embodiment of the present invention.
  • FIG. 22 is a sequence (2) diagram for explaining an example of API calls by the UE and AF in the embodiment of the present invention. 21 and 22, detailed operations of examples of API calls by the UE and AF shown in FIGS. 12 to 16 described above will be described.
  • step S201 AMF 30E sends Onboarding registration information (with CCF information and OAuth 2.0 access token) to AF 30A.
  • the AF 30A may acquire the Onboarding registration information by some off-line method.
  • step S202 a TLS connection is established between AF 30A and CCF 30B.
  • step S203 AF 30A sends an Onboard API call request (with OAuth 2.0 access token and API call public key) to CCF 30B.
  • CCF 30B sends an Onboard API call response (with API call ID, API call certificate, and Onboard secret) to AF 30A.
  • AF onboarding (registration) is completed by operations from step S201 to step S204.
  • step S205 the UE 20 executes the Bootstrapping procedure with the BSF 30F and UDM 30G.
  • step S206 the UE 20 performs an application request/response with the CCF 20B, and the CCF 20B performs an authentication request/response with the BSF 30F.
  • step S207 the UE 20 acquires the NA-GUTI.
  • step S208 the UE 20 subscribes to the CCF 30B so as to receive necessary notifications from the CCF 30B. Bootstrapping is completed by the procedure from step S205 to step S208. That is, the AF 30A performs Onboarding, and the UE 20 performs Bootstrapping.
  • the CCF 30B detects an API call trigger.
  • AF 30A transmits a security method request to CCF 30B.
  • the CCF 30B selects a security method.
  • CCF 30B transmits a security method response based on OAuth 2.0 Authorization Code Flow to AF 30A.
  • a security method to be used for API calls is determined in the procedure from step S209 to step S212.
  • step S213 the AF 30A confirms with the user whether the API can be used.
  • UE20 transmits a response to AF30A as needed.
  • AF 30A sends a CAPIF security request and authentication request (with NA-GUTI) to CCF 30B.
  • the CCF 30B confirms the subscriber information with the UDM 30G.
  • a TLS connection is established between the UE 20 and the CCF 30B.
  • CAPIF security request and authentication notification request/response are performed between UE 20 and CCF 30B.
  • CCF 30B issues an Authorization Code and transmits it to AF 30A. Acquisition of permission from the user and issuance of an Authorization Code are carried out by the procedure from step S213 to step S218.
  • step S219 the AF 30A transmits an access token request by OAuth 2.0 by Authorization Code to the CCF 30B.
  • step S220 the CCF 30B verifies the access token request.
  • step S221 an OAuth 2.0 access token (with access token, expiration date and scope) is returned to AF 30A.
  • An access token for calling the API is acquired by the procedure from step S219 to step S221.
  • a TLS connection is established between AF 30A and AEF 30C.
  • AF 30A calls Northbound API to AEF 30C with an access token based on OAuth 2.0.
  • the CCF 30B confirms the subscriber information with the UDM 30G.
  • the AEF 30C verifies the access token.
  • AEF 30C transmits a response to the Northbound API call to AF 30A. API calls are executed in the procedure from step S222 to step S226.
  • the end user himself/herself can use the API of the core network from the terminal and control the network based on the contract information of each contractor. From the operator's standpoint, among the APIs released by the network, by managing the granularity of APIs that can be used by individual contractors based on subscriber information, only the minimum required APIs can be released to users. can.
  • the base station 10, network node 30, and terminal 20 include functionality to implement the embodiments described above. However, each of the base station 10, network node 30, and terminal 20 may have only part of the functions in the embodiments.
  • FIG. 23 is a diagram showing an example of the functional configuration of the base station 10.
  • the base station 10 has a transmitting section 110, a receiving section 120, a setting section 130, and a control section 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 functional division and the names of the functional units may be arbitrary.
  • the network node 30 may have a functional configuration similar to that of the base station 10 .
  • the network node 30 having multiple different functions on the system architecture may be composed of multiple network nodes 30 separated for each function.
  • the network node 30 is not limited to a network node existing in the core network or the access network, and may correspond to a network node belonging to the PLMN domain.
  • the transmission unit 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 receiving unit 120 includes a function of receiving various signals transmitted from the terminal 20 or other network nodes 30 and acquiring, for example, higher layer information from the received signals.
  • the setting unit 130 stores preset setting information and various setting information to be transmitted to the terminal 20 in the storage device, and reads them from the storage device as necessary.
  • the content of the setting information is, for example, subscriber profile information in the network.
  • the control unit 140 performs processing related to update of profile information of subscribers in the network, as described in the embodiment. Also, the control unit 140 performs processing related to communication with the terminal 20 .
  • a functional unit related to signal transmission in control unit 140 may be included in transmitting unit 110
  • a functional unit related to signal reception in control unit 140 may be included in receiving unit 120 .
  • FIG. 24 is a diagram showing an example of the functional configuration of the terminal 20.
  • the terminal 20 has a transmitter 210 , a receiver 220 , a setter 230 and a controller 240 .
  • the functional configuration shown in FIG. 24 is merely an example. As long as the operation according to the embodiment of the present invention can be performed, the functional division and the names of the functional units may be arbitrary.
  • the transmission unit 210 creates a transmission signal from the transmission data and wirelessly transmits the transmission signal.
  • the receiving unit 220 wirelessly receives various signals and acquires a higher layer signal from the received physical layer signal.
  • the receiving unit 220 also has a function of receiving NR-PSS, NR-SSS, NR-PBCH, DL/UL control signals, reference signals, etc. transmitted from the network node 30 .
  • the setting unit 230 stores various types of setting information received from the network node 30 by the receiving unit 220 in the storage device, and reads them from the storage device as necessary.
  • the setting unit 230 also stores preset setting information.
  • the contents of the setting information are, for example, information related to networks to which connection is permitted.
  • the control unit 240 performs processing related to connection control to networks and network slices, as described in the embodiments.
  • a functional unit related to signal transmission in control unit 240 may be included in transmitting unit 210
  • a functional unit related to signal reception in control unit 240 may be included in receiving unit 220 .
  • each functional block may be implemented using one device that is physically or logically coupled, or directly or indirectly using two or more devices that are physically or logically separated (e.g. , wired, wireless, etc.) and may be implemented using these multiple devices.
  • a functional block may be implemented by combining software in the one device or the plurality of devices.
  • Functions include judging, determining, determining, calculating, calculating, processing, deriving, investigating, searching, checking, receiving, transmitting, outputting, accessing, resolving, selecting, choosing, establishing, comparing, assuming, expecting, assuming, Broadcasting, notifying, communicating, forwarding, configuring, reconfiguring, allocating, mapping, assigning, etc. can't
  • a functional block (component) that performs transmission is called a transmitting unit or transmitter.
  • the implementation method is not particularly limited.
  • FIG. 25 is a diagram illustrating an example of a hardware configuration of base station 10 and terminal 20 according to an embodiment of the present disclosure.
  • the network node 30 may have hardware configuration similar to that of the base station 10 .
  • the base station 10 and terminal 20 described above are 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, and the like. good too.
  • the term "apparatus” can be read as a circuit, device, unit, or the like.
  • the hardware configuration of the base station 10 and terminal 20 may be configured to include one or more of each device shown in the figure, or may be configured without some devices.
  • Each function of the base station 10 and the terminal 20 is performed by the processor 1001 performing calculations and controlling communication by the communication device 1004 by loading predetermined software (programs) onto hardware such as the processor 1001 and the storage device 1002. or by controlling at least one of data reading and writing in the storage device 1002 and the auxiliary storage device 1003 .
  • the processor 1001 for example, operates an operating system and controls the entire computer.
  • the processor 1001 may be configured with a central processing unit (CPU) including an interface with peripheral devices, a control device, an arithmetic device, registers, and the like.
  • CPU central processing unit
  • the control unit 140 , the control unit 240 and the like described above may be implemented by the processor 1001 .
  • the processor 1001 reads programs (program codes), software modules, 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 them.
  • programs program codes
  • software modules software modules
  • data etc.
  • the program a program that causes a computer to execute at least part of the operations described in the above embodiments is used.
  • control unit 140 of base station 10 shown in FIG. 23 may be implemented by a control program stored in storage device 1002 and operated by processor 1001 .
  • the control unit 240 of the terminal 20 shown in FIG. 24 may be implemented by a control program stored in the storage device 1002 and operated by the processor 1001.
  • FIG. Processor 1001 may be implemented by one or more chips. Note that the program may be transmitted from a network via an electric communication line.
  • the storage device 1002 is a computer-readable recording medium, for example, ROM (Read Only Memory), EPROM (Erasable Programmable ROM), EEPROM (Electrically Erasable Programmable ROM), RAM (Random Access Memory), etc. may be configured.
  • the storage device 1002 may also be called a register, cache, main memory (main storage device), or the like.
  • the storage device 1002 can store executable programs (program code), software modules, etc. for implementing a communication method according to an embodiment of the present disclosure.
  • the auxiliary storage device 1003 is a computer-readable recording medium, for example, an optical disk such as a CD-ROM (Compact Disc ROM), a hard disk drive, a flexible disk, a magneto-optical disk (for example, a compact disk, a digital versatile disk, a Blu -ray disk), smart card, flash memory (eg, card, stick, key drive), floppy disk, magnetic strip, and/or the like.
  • the storage medium described above may be, for example, a database, server, or other suitable medium including at least one of storage device 1002 and secondary 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 a network device, a network controller, a network card, a communication module, or the like.
  • the communication device 1004 includes 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).
  • FDD frequency division duplex
  • TDD time division duplex
  • the transceiver may be physically or logically separate implementations for the transmitter and receiver.
  • the input device 1005 is an input device (for example, keyboard, mouse, microphone, switch, button, sensor, etc.) that receives input from the outside.
  • the output device 1006 is an output device (for example, display, speaker, LED lamp, etc.) that outputs to the outside. Note that the input device 1005 and the output device 1006 may be integrated (for example, a touch panel).
  • 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 devices.
  • the base station 10 and the terminal 20 include hardware such as microprocessors, digital signal processors (DSPs), ASICs (Application Specific Integrated Circuits), PLDs (Programmable Logic Devices), and FPGAs (Field Programmable Gate Arrays). , and part or all of each functional block may be implemented by the hardware.
  • processor 1001 may be implemented using at least one of these pieces of hardware.
  • a transmission unit that authenticates a terminal and transmits a temporary identifier to the terminal, and a request that includes the temporary identifier or an authentication code based on the temporary identifier are received.
  • a receiving unit, and a control unit that issues an access token based on a request containing the temporary identifier or the authentication code, the transmitting unit transmitting the access token to the terminal or the external application.
  • a 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 the API call request is authorized. If so, a network node is provided that performs processing based on the API call request.
  • API Application Programming Interface
  • the end user himself/herself can use the API of the core network from the terminal and control the network based on the contract information of each contractor.
  • the operator's standpoint among the APIs released by the network, by managing the granularity of APIs that can be used by individual contractors based on subscriber information, only the minimum required APIs can be released to users. can.
  • As an advance preparation for API calls instead of existing Onboarding, using Bootstrapping that authenticates individual contractors using the SIM information of the terminal identifies individual contractors that trigger API calls. can do.
  • by storing the range of APIs that can be used by individual contractors in the subscriber information and checking the subscriber information it is possible to manage the authority to use APIs on an individual basis.
  • the receiving unit receives from the terminal or the external application a request related to a security method to be used for calling an API, the control unit selects a security method, and the transmitting unit responds indicating the selected security method. may be sent to the terminal or an external application.
  • the configuration allows network nodes to select and set the security method to use for API calls.
  • the control unit may authenticate and register the external application in advance. This configuration allows the network node to accept API calls for the UE from authenticated external applications.
  • the control unit may issue the access token after confirming whether or not the user can use the API.
  • the network node can confirm the user's intention in advance before executing the API call.
  • control unit may refer to permitted APIs and permitted methods for which at least a scope for each user is set. This configuration allows the network node to control API calls on a per-user granular scope.
  • a transmission procedure for authenticating a terminal and transmitting a temporary identifier to the terminal a reception procedure for receiving a request containing the temporary identifier or an authentication code based on the temporary identifier;
  • a communication method performed by a network node is provided.
  • the end user himself/herself can use the API of the core network from the terminal and control the network based on the contract information of each contractor.
  • the operator's standpoint among the APIs released by the network, by managing the granularity of APIs that can be used by individual contractors based on subscriber information, only the minimum required APIs can be released to users. can.
  • As an advance preparation for API calls instead of existing Onboarding, using Bootstrapping that authenticates individual contractors using the SIM information of the terminal identifies individual contractors that trigger API calls. can do.
  • by storing the range of APIs that can be used by individual contractors in the subscriber information and checking the subscriber information it is possible to manage the authority to use APIs on an individual basis.
  • the operations of a plurality of functional units may be physically performed by one component, or the operations of one functional unit may be physically performed by a plurality of components.
  • the processing order may be changed as long as there is no contradiction.
  • the network node 30 and terminal 20 have been described using functional block diagrams for convenience of process description, such devices may be implemented in hardware, software, or a combination thereof.
  • the software operated by the processor of the network node 30 according to the embodiment of the invention and the software operated by the processor of the terminal 20 according to the embodiment of the invention are respectively stored in random access memory (RAM), flash memory, read-only memory. (ROM), EPROM, EEPROM, register, hard disk (HDD), removable disk, CD-ROM, database, server, or any other appropriate storage medium.
  • notification of information is not limited to the aspects/embodiments described in the present disclosure, and may be performed using other methods.
  • notification of information includes 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, It may be implemented by broadcast information (MIB (Master Information Block), SIB (System Information Block)), other signals, or a combination thereof.
  • RRC signaling may also be called an RRC message, for example, RRC It may be a connection setup (RRC Connection Setup) message, an RRC connection reconfiguration message, or the like.
  • Each aspect/embodiment described in the present disclosure includes LTE (Long Term Evolution), LTE-A (LTE-Advanced), SUPER 3G, IMT-Advanced, 4G (4th generation mobile communication system), 5G (5th generation mobile communication system) 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 extended It may be applied to at least one of the next generation systems. Also, a plurality of systems may be applied in combination (for example, a combination of at least one of LTE and LTE-A and 5G, etc.).
  • a specific operation performed by the network node 30 in this specification may be performed by its upper node in some cases.
  • various operations performed for communication with terminal 20 may be network node 30 and other network nodes other than network node 30 (eg, but not limited to MME or S-GW).
  • MME Mobility Management Entity
  • S-GW Serving Mobility Management Entity
  • Information, signals, etc. described in the present disclosure may be output from a higher layer (or a lower layer) to a lower layer (or a higher layer). It may be input and output via multiple network nodes.
  • Input/output information may be stored in a specific location (for example, memory) or managed using a management table. Input/output information and the like can be overwritten, updated, or appended. The output information and the like may be deleted. The entered information and the like may be transmitted to another device.
  • the determination in the present disclosure may be performed by a value represented by 1 bit (0 or 1), may be performed by a boolean value (Boolean: true or false), or may be performed by comparing numerical values (e.g. , comparison with a predetermined value).
  • Software whether referred to as software, firmware, middleware, microcode, hardware description language or otherwise, includes instructions, instruction sets, code, code segments, program code, programs, subprograms, and software modules. , applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, and the like.
  • software, instructions, information, etc. may be transmitted and received via a transmission medium.
  • the software uses at least one of wired technology (coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), etc.) and wireless technology (infrared, microwave, etc.) to website, Wired and/or wireless technologies are included within the definition of transmission medium when sent from a server or other remote source.
  • wired technology coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), etc.
  • wireless technology infrared, microwave, etc.
  • data, instructions, commands, information, signals, bits, symbols, chips, etc. may refer to voltages, currents, electromagnetic waves, magnetic fields or magnetic particles, light fields or photons, or any of these. may be represented by a combination of
  • the channel and/or symbols may be signaling.
  • a signal may also be a message.
  • a component carrier may also be called a carrier frequency, a cell, a frequency carrier, or the like.
  • system and “network” used in this disclosure are used interchangeably.
  • information, parameters, etc. described in the present 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.
  • radio resources may be indexed.
  • base station BS
  • radio base station base station
  • base station device fixed station
  • NodeB NodeB
  • eNodeB eNodeB
  • gNodeB gNodeB
  • a base station can accommodate one or more (eg, three) cells.
  • the overall coverage area of the base station can be partitioned into multiple smaller areas, each smaller area being associated with a base station subsystem (e.g., an indoor small base station (RRH:
  • RRH indoor small base station
  • the term "cell” or “sector” refers to part or all of the coverage area of at least one of the base stations and base station subsystems serving communication in this coverage.
  • MS Mobile Station
  • UE User Equipment
  • a mobile station is defined 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 It may also be called a terminal, remote terminal, handset, user agent, mobile client, client, or some other suitable term.
  • At least one of the base station and mobile station may be called a transmitting device, a receiving device, a communication device, or the like.
  • At least one of the base station and the mobile station may be a device mounted on a mobile object, the mobile object itself, or the like.
  • the mobile object may be a vehicle (e.g., car, airplane, etc.), an unmanned mobile object (e.g., drone, self-driving car, etc.), or a robot (manned or unmanned ).
  • at least one of the base station and the mobile station includes devices that do not necessarily move during communication operations.
  • at least one of the base station and the mobile station may be an IoT (Internet of Things) device such as a sensor.
  • IoT Internet of Things
  • the base station in the present disclosure may be read as a user terminal.
  • communication between a base station and a user terminal is replaced with communication between a plurality of terminals 20 (for example, D2D (Device-to-Device), V2X (Vehicle-to-Everything), etc.)
  • the terminal 20 may have the functions of the network node 30 described above.
  • words such as "up” and “down” may be replaced with words corresponding to inter-terminal communication (for example, "side”).
  • uplink channels, downlink channels, etc. may be read as side channels.
  • user terminals in the present disclosure may be read as base stations.
  • the base station may have the functions that the above-described user terminal has.
  • determining and “determining” used in this disclosure may encompass a wide variety of actions.
  • “Judgement” and “determination” are, for example, judging, calculating, computing, processing, deriving, investigating, looking up, searching, inquiring (eg, lookup in a table, database, or other data structure), ascertaining as “judged” or “determined”, and the like.
  • "judgment” and “determination” are used for receiving (e.g., receiving information), transmitting (e.g., transmitting information), input, output, access (accessing) (for example, accessing data in memory) may include deeming that a "judgment” or “decision” has been made.
  • judgment and “decision” are considered to be “judgment” and “decision” by resolving, selecting, choosing, establishing, comparing, etc. can contain.
  • judgment and “decision” may include considering that some action is “judgment” and “decision”.
  • judgment (decision) may be read as “assuming”, “expecting”, “considering”, or the like.
  • connection means any direct or indirect connection or coupling between two or more elements, It can include the presence of one or more intermediate elements between two elements being “connected” or “coupled.” Couplings or connections between elements may be physical, logical, or a combination thereof. For example, “connection” may be read as "access”.
  • two elements are defined using at least one of one or more wires, cables, and printed electrical connections and, as some non-limiting and non-exhaustive examples, in the radio frequency domain. , electromagnetic energy having wavelengths in the microwave and optical (both visible and invisible) regions, and the like.
  • the reference signal can also be abbreviated as RS (Reference Signal), and may also be called Pilot depending on the applicable standard.
  • RS Reference Signal
  • any reference to elements using the "first,” “second,” etc. designations 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, reference to a first and second element does not imply that only two elements can be employed or that the first element must precede the second element in any way.
  • a and B are different may mean “A and B are different from each other.”
  • the term may also mean that "A and B are different from C”.
  • Terms such as “separate,” “coupled,” etc. may also be interpreted in the same manner as “different.”
  • notification of predetermined information is not limited to being performed explicitly, but may be performed implicitly (for example, not notifying the predetermined information). good too.
  • AF in the present disclosure is an example of an external application.
  • NA-GUTI is an example of a temporary identifier.
  • base station 110 transmitting unit 120 receiving unit 130 setting unit 140 control unit 20 terminal 210 transmitting unit 220 receiving unit 230 setting unit 240 control unit 30 network node 1001 processor 1002 storage device 1003 auxiliary storage device 1004 communication device 1005 input device 1006 output device

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

ネットワークノードは、端末を認証し暫定識別子を当該端末に送信する送信部と、前記暫定識別子を含む要求又は前記暫定識別子に基づく認証コードを受信する受信部と、前記暫定識別子を含む要求又は前記認証コードに基づいて、アクセストークンを発行する制御部とを有し、前記送信部は、前記アクセストークンを前記端末又は外部アプリケーションに送信し、前記受信部は、前記アクセストークンに基づくＡＰＩ（Application Programming Interface）呼び出し要求を前記端末又は前記外部アプリケーションから受信し、前記制御部は、前記アクセストークンを検証して前記ＡＰＩ呼び出し要求が認可されたものであると判定した場合、前記ＡＰＩ呼び出し要求に基づいて処理を実行する。

Description

ネットワークノード及び通信方法
　本発明は、通信システムにおけるネットワークノード及び通信方法に関する。
　３ＧＰＰ（3rd Generation Partnership Project）では、システム容量の更なる大容量化、データ伝送速度の更なる高速化、無線区間における更なる低遅延化等を実現するために、５ＧあるいはＮＲ（New Radio）と呼ばれる無線通信方式（以下、当該無線通信方式を「５Ｇ」あるいは「ＮＲ」という。）の検討が進んでいる。５Ｇでは、１０Ｇｂｐｓ以上のスループットを実現しつつ無線区間の遅延を１ｍｓ以下にするという要求条件を満たすために、様々な無線技術の検討が行われている。
　ＮＲでは、ＬＴＥ（Long Term Evolution）のネットワークアーキテクチャにおけるコアネットワークであるＥＰＣ（Evolved Packet Core）に対応する５ＧＣ（5G Core Network）及びＬＴＥのネットワークアーキテクチャにおけるＲＡＮ（Radio Access Network）であるＥ－ＵＴＲＡＮ（Evolved Universal Terrestrial Radio Access Network）に対応するＮＧ－ＲＡＮ（Next Generation - Radio Access Network）を含むネットワークアーキテクチャが検討されている（例えば非特許文献１）。
　また、例えば、５ＧシステムにおけるＮＥＦ（Network Exposure Function）とＡＦ（Application Function）間のＮｏｒｔｈｂｏｕｎｄインタフェースをＣＡＰＩＦ（Common API Framework）により構成するアーキテクチャが検討されている（例えば非特許文献２及び非特許文献３）。
３ＧＰＰ　ＴＳ　２３．５０１　Ｖ１６．７．０（２０２０－１２） ３ＧＰＰ　ＴＳ　２９．５２２　Ｖ１６．６．０（２０２０－１２） ３ＧＰＰ　ＴＳ　２３．２２２　Ｖ１６．９．０（２０２０－０９）
　３ＧＰＰコアネットワークでは外部のアプリケーション向けにＡＰＩ（Application Programming Interface）を解放しており、サードパーティのアプリケーションからＡＰＩを呼び出すことができる。ここで、サードパーティのアプリケーションからＡＰＩを呼び出すとき、コアネットワークは、サードパーティのアプリケーションを利用するユーザを識別することが困難であるため、適切なサービスを提供することができなかった。
　本発明は上記の点に鑑みてなされたものであり、ネットワークにおいて加入者情報を識別可能とするインタフェースを提供することを目的とする。
　開示の技術によれば、端末を認証し暫定識別子を当該端末に送信する送信部と、前記暫定識別子を含む要求又は前記暫定識別子に基づく認証コードを受信する受信部と、前記暫定識別子を含む要求又は前記認証コードに基づいて、アクセストークンを発行する制御部とを有し、前記送信部は、前記アクセストークンを前記端末又は外部アプリケーションに送信し、前記受信部は、前記アクセストークンに基づくＡＰＩ（Application Programming Interface）呼び出し要求を前記端末又は前記外部アプリケーションから受信し、前記制御部は、前記アクセストークンを検証して前記ＡＰＩ呼び出し要求が認可されたものであると判定した場合、前記ＡＰＩ呼び出し要求に基づいて処理を実行するネットワークノードが提供される。
　開示の技術によれば、ネットワークにおいて加入者情報を識別可能とするインタフェースを提供することができる。
通信システムの例を説明するための図である。 ローミング環境下の通信システムの例を説明するための図である。 ＡＰＩ呼び出しの例（１）を示す図である。 ＡＰＩ呼び出しの例（２－１）を示す図である。 ＡＰＩ呼び出しの例（２－２）を示す図である。 ＡＰＩ呼び出しの例（３－１）を示す図である。 ＡＰＩ呼び出しの例（３－２）を示す図である。 ＡＰＩ呼び出しの例（４）を示す図である。 本発明の実施の形態におけるＵＥによるＡＰＩ呼び出しの例（１）を説明するための図である。 本発明の実施の形態におけるＵＥによるＡＰＩ呼び出しの例（２）を説明するための図である。 本発明の実施の形態におけるＵＥによるＡＰＩ呼び出しの例（３）を説明するための図である。 本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例（１）を説明するための図である。 本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例（２）を説明するための図である。 本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例（３）を説明するための図である。 本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例（４）を説明するための図である。 本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例（５）を説明するための図である。 本発明の実施の形態におけるＡＰＩのスコープを説明するための図である。 本発明の実施の形態におけるＵＥ及びＡＦを含むシステムの例を示す図である。 本発明の実施の形態におけるＵＥを含むシステムの例を示す図である。 本発明の実施の形態におけるＵＥによるＡＰＩ呼び出しの例を説明するためのシーケンス図である。 本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例を説明するためのシーケンス（１）図である。 本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例を説明するためのシーケンス（２）図である。 本発明の実施の形態における基地局１０の機能構成の一例を示す図である。 本発明の実施の形態における端末２０の機能構成の一例を示す図である。 本発明の実施の形態における基地局１０及び端末２０のハードウェア構成の一例を示す図である。
　以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例であり、本発明が適用される実施の形態は、以下の実施の形態に限られない。
　本発明の実施の形態の無線通信システムの動作にあたっては、適宜、既存技術が使用される。ただし、当該既存技術は、例えば既存のＬＴＥであるが、既存のＬＴＥに限られない。また、本明細書で使用する用語「ＬＴＥ」は、特に断らない限り、ＬＴＥ－Ａｄｖａｎｃｅｄ、及び、ＬＴＥ－Ａｄｖａｎｃｅｄ以降の方式（例：ＮＲ）、又は無線ＬＡＮ（Local Area Network）を含む広い意味を有するものとする。
　また、本発明の実施の形態において、無線パラメータ等が「設定される（Configure）」とは、所定の値が予め設定（Pre-configure）されることであってもよいし、ネットワークノード３０又は端末２０から通知される無線パラメータが設定されることであってもよい。
　図１は、通信システムの例を説明するための図である。図１に示されるように、通信システムは、端末２０であるＵＥ、複数のネットワークノード３０から構成される。以下、機能ごとに１つのネットワークノード３０が対応するものとするが、複数の機能を１つのネットワークノード３０が実現してもよいし、複数のネットワークノード３０が１つの機能を実現してもよい。また、以下に記載する「接続」は、論理的な接続であってもよいし、物理的な接続であってもよい。
　ＲＡＮ（Radio Access Network）は、無線アクセス機能を有するネットワークノード３０であり、基地局１０を含んでもよく、ＵＥ、ＡＭＦ（Access and Mobility Management Function）及びＵＰＦ（User plane function）と接続される。ＡＭＦは、ＲＡＮインタフェースの終端、ＮＡＳ（Non-Access Stratum）の終端、登録管理、接続管理、到達性管理、モビリティ管理等の機能を有するネットワークノード３０である。ＵＰＦは、ＤＮ（Data Network）と相互接続する外部に対するＰＤＵ（Protocol Data Unit）セッションポイント、パケットのルーティング及びフォワーディング、ユーザプレーンのＱｏＳ（Quality of Service）ハンドリング等の機能を有するネットワークノード３０である。ＵＰＦ及びＤＮは、ネットワークスライスを構成する。本発明の実施の形態における無線通信ネットワークでは、複数のネットワークスライスが構築されている。
　ＡＭＦは、ＵＥ、ＲＡＮ、ＳＭＦ（Session Management function）、ＮＳＳＦ（Network Slice Selection Function）、ＮＥＦ（Network Exposure Function）、ＮＲＦ（Network Repository Function）、ＵＤＭ（Unified Data Management）、ＡＵＳＦ（Authentication Server Function）、ＰＣＦ（Policy Control Function）、ＡＦ（Application Function）と接続される。ＡＭＦ、ＳＭＦ、ＮＳＳＦ、ＮＥＦ、ＮＲＦ、ＵＤＭ、ＡＵＳＦ、ＰＣＦ、ＡＦは、各々のサービスに基づくインタフェース、Ｎａｍｆ、Ｎｓｍｆ、Ｎｎｓｓｆ、Ｎｎｅｆ、Ｎｎｒｆ、Ｎｕｄｍ、Ｎａｕｓｆ、Ｎｐｃｆ、Ｎａｆを介して相互に接続されるネットワークノード３０である。
　ＳＭＦは、セッション管理、ＵＥのＩＰ（Internet Protocol）アドレス割り当て及び管理、ＤＨＣＰ（Dynamic Host Configuration Protocol）機能、ＡＲＰ（Address Resolution Protocol）プロキシ、ローミング機能等の機能を有するネットワークノード３０である。ＮＥＦは、他のＮＦ（Network Function）に能力及びイベントを通知する機能を有するネットワークノード３０である。ＮＳＳＦは、ＵＥが接続するネットワークスライスの選択、許可されるＮＳＳＡＩ（Network Slice Selection Assistance Information）の決定、設定されるＮＳＳＡＩの決定、ＵＥが接続するＡＭＦセットの決定等の機能を有するネットワークノード３０である。ＰＣＦは、ネットワークのポリシ制御を行う機能を有するネットワークノード３０である。ＡＦは、アプリケーションサーバを制御する機能を有するネットワークノード３０である。ＮＲＦは、サービスを提供するＮＦインスタンスを発見する機能を有するネットワークノード３０である。ＵＤＭは、加入者データ及び認証データを管理するネットワークノード３０である。ＵＤＭは、当該データを保持するＵＤＲ（User Data Repository）と接続される。
　図２は、ローミング環境下の通信システムの例を説明するための図である。図２に示されるように、ネットワークは、端末２０であるＵＥ、複数のネットワークノード３０から構成される。以下、機能ごとに１つのネットワークノード３０が対応するものとするが、複数の機能を１つのネットワークノード３０が実現してもよいし、複数のネットワークノード３０が１つの機能を実現してもよい。また、以下に記載する「接続」は、論理的な接続であってもよいし、物理的な接続であってもよい。
　ＲＡＮは、無線アクセス機能を有するネットワークノード３０であり、ＵＥ、ＡＭＦ及びＵＰＦと接続される。ＡＭＦは、ＲＡＮインタフェースの終端、ＮＡＳの終端、登録管理、接続管理、到達性管理、モビリティ管理等の機能を有するネットワークノード３０である。ＵＰＦは、ＤＮと相互接続する外部に対するＰＤＵセッションポイント、パケットのルーティング及びフォワーディング、ユーザプレーンのＱｏＳハンドリング等の機能を有するネットワークノード３０である。ＵＰＦ及びＤＮは、ネットワークスライスを構成する。、本発明の実施の形態における無線通信ネットワークでは、複数のネットワークスライスが構築されている。
　ＡＭＦは、ＵＥ、ＲＡＮ、ＳＭＦ、ＮＳＳＦ、ＮＥＦ、ＮＲＦ、ＵＤＭ、ＡＵＳＦ、ＰＣＦ、ＡＦ、ＳＥＰＰ（Security Edge Protection Proxy）と接続される。ＡＭＦ、ＳＭＦ、ＮＳＳＦ、ＮＥＦ、ＮＲＦ、ＵＤＭ、ＡＵＳＦ、ＰＣＦ、ＡＦは、各々のサービスに基づくインタフェース、Ｎａｍｆ、Ｎｓｍｆ、Ｎｎｓｓｆ、Ｎｎｅｆ、Ｎｎｒｆ、Ｎｕｄｍ、Ｎａｕｓｆ、Ｎｐｃｆ、Ｎａｆを介して相互に接続されるネットワークノード３０である。
　ＳＭＦは、セッション管理、ＵＥのＩＰアドレス割り当て及び管理、ＤＨＣＰ機能、ＡＲＰプロキシ、ローミング機能等の機能を有するネットワークノード３０である。ＮＥＦは、他のＮＦに能力及びイベントを通知する機能を有するネットワークノード３０である。ＮＳＳＦは、ＵＥが接続するネットワークスライスの選択、許可されるＮＳＳＡＩの決定、設定されるＮＳＳＡＩの決定、ＵＥが接続するＡＭＦセットの決定等の機能を有するネットワークノード３０である。ＰＣＦは、ネットワークのポリシ制御を行う機能を有するネットワークノード３０である。ＡＦは、アプリケーションサーバを制御する機能を有するネットワークノード３０である。ＮＲＦは、サービスを提供するＮＦインスタンスを発見する機能を有するネットワークノード３０である。ＳＥＰＰは、非透過的なプロキシであり、ＰＬＭＮ（Public Land Mobile Network）間のコントロールプレーンのメッセージをフィルタリングする。図２に示されるｖＳＥＰＰは、ｖｉｓｉｔｅｄネットワークにおけるＳＥＰＰであり、ｈＳＥＰＰは、ｈｏｍｅネットワークにおけるＳＥＰＰである。
　図２に示されるように、ＵＥは、ＶＰＬＭＮ（Visited PLMN）においてＲＡＮ及びＡＭＦと接続されているローミング環境にある。ＶＰＬＭＮ及びＨＰＬＭＮ（Home PLMN）は、ｖＳＥＰＰ及びｈＳＥＰＰを経由して接続されている。ＵＥは、例えば、ＶＰＬＭＮのＡＭＦを介してＨＰＬＭＮのＵＤＭと通信が可能である。
　上述のＮＥＦは、ＡＦから呼び出し可能であるＡＰＩ（Application Programming Interface）を、ＣＡＰＩＦ（Common API Framework）アーキテクチャを適用して実装することが検討されている。ＣＡＰＩＦアーキテクチャは、サービスＡＰＩ運用をサポートするメカニズムを提供し、例えば、ＡＰＩ呼び出し元（invoker）にＡＰＩ提供者（provider）から提供されるサービスＡＰＩを発見させ、当該サービスＡＰＩを使用する通信を可能とする。また、ＣＡＰＩＦアーキテクチャは、例えば、ＰＬＭＮトラストドメインの外部からサービスＡＰＩにアクセスするＡＰＩ呼び出し元から、ＰＬＭＮトラストドメインの接続形態（topology）を隠蔽するメカニズムを有する。
　図３は、ＡＰＩ呼び出しの例（１）を示す図である。３ＧＰＰコアネットワークでは外部のアプリケーション向けにＡＰＩを解放しており、サードパーティのアプリケーションからＡＰＩを呼び出すことができる。ＡＰＩを呼び出すとき、コアネットワーク内にあるＣＡＰＩＦコア機能（CAPIF Core Function、ＣＣＦとも記載する。）によって、呼び出し元のアプリケーション（API invoker）を認証及び／又は認可し、いずれのアプリケーションがＡＰＩを呼び出すことができるかを管理する。
　図３に示されるように、ＡＰＩ呼び出し元のアプリケーション３０Ａが、ＣＡＰＩＦ－ＡＰＩを利用してＣＡＰＩＦコア機能３０Ｂに事前登録される。ＣＡＰＩＦコア機能３０Ｂでは、サードパーティのアプリケーション３０Ａを認証及び／又は認可する。また、図３に示されるように、ＡＰＩ呼び出し元のアプリケーション３０Ａが、コアネットワークのＡＰＩを呼び出すと、認証及び／又は認可された外部アプリケーション向けに、ＡＰＩ提供機能（API Exposing Function、ＡＥＦとも記載する。）３０ＣによってサービスＡＰＩを解放する。
　図４は、ＡＰＩ呼び出しの例（２－１）を示す図である。図５は、ＡＰＩ呼び出しの例（２－２）を示す図である。具体的なユースケースとして、ＱｏＳ変更オプションを想定する。ユーザは、契約により所望のタイミングでＱｏＳ変更リクエストを送ることにより、快適な通信環境が得られるものとする。図４に示されるように、ユーザのアプリケーションからＱｏＳ変更リクエストが５ＧＳ（5G System）に含まれるＮＥＦにコアネットワークのＡＰＩ呼び出しとして送信され、ＱｏＳ変更が実行される。
　しかしながら、従来技術では、いずれのユーザがいずれのユーザのＱｏＳを変更できるのか判断することができず、適切でないユーザのＱｏＳを変更することが可能となってしまう。例えば、図５に示されるように、ＣＡＰＩＦコア機能３０Ｂでは、どのユーザのＱｏＳ変更が許可されているかがわからず、ＡＰＩ提供機能３０Ｃでは、ＱｏＳ変更可の契約者が、ＱｏＳ変更不可ユーザのＱｏＳを変更することを受け入れてしまう。また、ＱｏＳ以外のサービスであっても、いずれのユーザのリソースにアクセスできるかを判断することができない。なお、図５では、ＡＰＩ呼び出し元はエンドユーザのスマホ等である。
　以降、本実施例ではＱｏＳ変更を具体例として案を説明するが、ユーザが利用するＡＰＩはＱｏＳ制御に限られず、オペレータがユーザ向けに提供しているすべてのＡＰＩとしてよい。例えば、特定のユーザのＵ－ｐｌａｎｅ通信路を変更するＡＰＩがあるが、エンドユーザが自ら当該ＡＰＩを利用する際にも、本実施例で説明する方式を適用してよい。
　図６は、ＡＰＩ呼び出しの例（３－１）を示す図である。図７は、ＡＰＩ呼び出しの例（３－２）を示す図である。具体的なユースケースとして、サードパーティ社製のスマートフォンゲームをプレイする場合を想定する。ユーザは課金すなわち契約により所望のタイミングでＱｏＳ変更リクエストを送ることにより、快適な通信環境が得られるものとする。図６に示されるように、ユーザのアプリケーションからＱｏＳ変更リクエストが、ゲームサーバを介して５ＧＳに含まれるＮＥＦにコアネットワークのＡＰＩ呼び出しとして送信され、ＱｏＳ変更が実行される。
　しかしながら、従来技術では、いずれのユーザがいずれのユーザのＱｏＳを変更できるのか判断することができず、ＱｏＳ変更オプションのない（又は一般に適切な契約のない）ユーザからのＱｏＳ変更リクエストを拒否することができない。例えば、図７に示されるように、ＣＡＰＩＦコア機能３０Ｂでは、どのユーザからの要求であるかがわからず、ＡＰＩ提供機能３０Ｃでは、ゲームサーバ自体が認証及び認可されていれば、ＡＰＩを呼び出すことが可能となってしまう。図７に示されるように、ＱｏＳ変更オプションありのゲームプレイヤーに対応するＵＥ２０ＡからのＱｏＳ変更リクエストを許容し、ＱｏＳ変更オプションなしのゲームプレイヤーに対応するＵＥ２０ＢからのＱｏＳ変更リクエストを拒否する動作が、ネットワーク側が意図する動作である。なお、図７では、ＡＰＩ呼び出し元はサードパーティのゲームサーバ等である。
　そこで、ＣＡＰＩＦコア機能３０Ｂが、個々の端末を認証してＡＰＩ利用を認可してもよい。また、個々の端末がいずれのＡＰＩを呼び出してよいかを規定するスコープを管理してもよい。また、当該スコープ内で、指定したＵＥのＱｏＳのみを変更できるようにしてもよい。
　図８は、ＡＰＩ呼び出しの例（４）を示す図である。図８は従来技術においてＡＦがＡＰＩを呼び出す例を示す。図８に示されるように、ＡＰＩ呼び出し元３０Ａは、ＣＡＰＩＦコア機能３０Ｂにｏｎｂｏａｒｄｉｎｇする。「ｏｎｂｏａｒｄｉｎｇ」とは、ここではＣＡＰＩＦコア機能３０ＢがＡＰＩ呼び出し元３０Ａを認証しワンタイム登録して、ＡＰＩ呼び出し元３０ＡにＣＡＰＩＦ及びサービスＡＰＩにアクセスすることを許可する動作をいう。続いて、ＡＰＩ呼び出し元３０ＡとＣＡＰＩＦコア機能３０Ｂはセキュリティメソッドを合意する。続いて、ＡＰＩ呼び出し元３０Ａは、アクセストークンをＣＡＰＩＦコア機能３０Ｂに要求し、ＣＡＰＩＦコア機能３０Ｂはアクセストークンを発行する。
　上記のセキュリティメソッドの合意は、ＯＡｕｔｈ　２．０　Ｃｌｉｅｎｔ　Ｃｒｅｄｅｎｔｉａｌ方式を用いており、リソースオーナーの許諾がなくてもクライアント（図８ではＡＰＩ呼び出し元）の認証のみでＡＰＩ呼び出しが認可される。
　図９は、本発明の実施の形態におけるＵＥによるＡＰＩ呼び出しの例（１）を説明するための図である。ステップ１において、ＢＳＦ（Bootstrapping Server Function）３０Ｆ及びＵＤＭ３０Ｇは、Ｂｏｏｔｓｔｒａｐｐｉｎｇ手順の実行によりＵＥ２０を認証し、ＵＥ２０とＣＡＰＩＦコア機能３０Ｂが直接通信できるようにする。ＵＥ２０は、ＣＣＦ３０Ｂから暫定識別子を受け取る。暫定識別子は、例えば、ＮＡ－ＧＵＴＩ（Northbound Access Globally Unique Temporary Identifier）であってもよい。続くステップ２において、ＵＥ２０とＣＣＦ３０Ｂとの間でセキュリティメソッドが合意される。
　図１０は、本発明の実施の形態におけるＵＥによるＡＰＩ呼び出しの例（２）を説明するための図である。続くステップ３において、ＵＥ２０は、暫定識別子及び呼び出したいＡＰＩを明示してＣＣＦ３０Ｂにアクセストークンの発行を要求する。なお、ステップ３の時点で、変更対象のユーザ情報等をＣＣＦ３０Ｂに送信し、当該ユーザ情報に基づいてアクセストークンがＣＣＦ３０Ｂから発行されてもよい。
　続くステップ４において、ＣＣＦ３０Ｂは暫定識別子から加入者を特定し、ＵＤＭ３０Ｇに加入者情報を確認する。続くステップ５において、ＵＤＭ３０Ｇは、加入者情報を返却する。図１０に示される許可ＡＰＩ、メソッド及び対象ユーザが関連付けられたテーブルを、ＵＤＭ３０Ｇは、加入者情報としてＣＣＦ３０Ｂに返却してもよい。
　続くステップ６において、ＣＣＦ３０Ｂは、当該テーブルの許可ＡＰＩ及びメソッドに基づいて、ＵＥ２０が目的のＡＰＩを呼び出すことが許容されるとＣＣＦ３０Ｂが判定できた場合、ＣＣＦ３０ＢはＵＥにアクセストークンを発行する。図１０に示される例では、例えば、ＡｓＳｅｓｓｉｏｎＷｉｔｈＱｏＳがＵＥ２０から呼び出されている場合、許可されているＡＰＩであるため、アクセストークンがＣＣＦ３０Ｂから発行される。
　続くステップ７において、ＵＥ２０は、受領したアクセストークンを用いて、ＡＥＦ３０Ｃ宛にサービスＡＰＩを呼び出す。例えば、図１０に示されるように、アクセストークンが＠＠＠＠＠＠、ＡＰＩがＡｓＳｅｓｓｉｏｎＷｉｔｈＱｏＳ及び変更対象ユーザのＩＰアドレスがｘｘｘ．ｘｘｘ．ｘｘｘ．ｘｘｘであることを示す情報をＵＥ２０はＡＥＦ３０Ｃに送ることで、サービスＡＰＩを呼び出してもよい。
　図１１は、本発明の実施の形態におけるＵＥによるＡＰＩ呼び出しの例（３）を説明するための図である。続くステップ８において、ＡＥＦ３０Ｃは、ＣＣＦ３０Ｂに対し、ＡＰＩ要求を認可してよいか確認する。続くステップ９において、ＣＣＦ３０Ｂは、ＵＤＭ３０ＧにＡＰＩ呼び出し元の加入者の加入者情報を要求する。続くステップ１０において、ＵＤＭ３０Ｇは、加入者情報を返却する。図１１に示される許可ＡＰＩ、メソッド及び対象ユーザが関連付けられたテーブルを、ＵＤＭ３０Ｇは、加入者情報としてＣＣＦ３０Ｂに返却してもよい。続くステップ１１において、ＣＣＦ３０Ｂは、加入者情報及びＡＰＩ要求に基づいて、認可してよいＡＰＩ要求か否かを判定し、結果をＡＥＦ３０Ｃに返却する。
　例えば、ＣＣＦ３０Ｂは、「ＡＰＩ：ＡｓＳｅｓｓｉｏｎＷｉｔｈＱｏＳ、変更対象ユーザのＩＰアドレスがｘｘｘ．ｘｘｘ．ｘｘｘ．ｘｘｘ」という要求と、図１１に示される加入者情報の「対象ユーザ」とを比較し、目的のユーザへのＱｏＳ変更が加入者情報にて許可されていれば、当該ＡＰＩの利用を認可してよいと判定してもよい。続くステップ１２において、ＣＣＦ３０Ｂにおいて当該ＡＰＩ利用が認可された場合、ＡＥＦ３０Ｃは要求に従って処理を実行し、ＡＰＩ利用可否の結果をＵＥ２０に返却する。
　図１２は、本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例（１）を説明するための図である。ステップ１において、ＡＰＩ呼び出し元３０Ａ（例えば、ゲームサーバ）は、ＣＡＰＩＦコア機能３０ＢにＯｎｂｏａｒｄｉｎｇする。当該Ｏｎｂｏａｒｄｉｎｇは、従来技術と同様であってもよい。ステップ１′において、ステップ１と並行して、ＢＳＦ３０Ｆ及びＵＤＭ３０Ｇは、Ｂｏｏｔｓｔｒａｐｐｉｎｇ手順の実行によりＵＥ２０を認証し、ＵＥ２０とＣＡＰＩＦコア機能３０Ｂが直接通信できるようにする。ＵＥ２０は、ＣＣＦ３０Ｂから暫定識別子を受け取る。暫定識別子は、例えば、ＮＡ－ＧＵＴＩであってもよい。
　図１３は、本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例（２）を説明するための図である。続くステップ２において、ＡＰＩ呼び出し元３０Ａは、ＵＥトリガのＡＰＩ呼び出しが必要であることを、ＵＥ２０からの要求等により検知する。例えば、当該ＵＥトリガは、ＵＥ２０からゲームサーバに対してＱｏＳの変更要求を示す情報を送信することであってもよいし、ゲームサーバ側で当該ユーザに対してＱｏＳを変更する必要があると判定されたことであってもよい。
　続くステップ３において、ＡＰＩ呼び出し元３０ＡとＣＣＦ３０Ｂとの間で、個々の契約者の契約内容に関わるＡＰＩの呼び出しが必要な場合、ＡＰＩ呼び出し元３０ＡとＣＣＦ３０Ｂとの間で、セキュリティメソッドとしてＯＡｕｔｈ　２．０　Ａｕｔｈｏｒｉｚａｔｉｏｎ　Ｃｏｄｅ　Ｆｌｏｗを用いた認可を行うことが合意される。
　図１４は、本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例（３）を説明するための図である。続くステップ４において、ＡＰＩ呼び出し元３０Ａは、ＡＰＩを呼び出してよいかユーザに確認する。続くステップ５において、ＡＰＩを呼び出す許可がユーザから得られた場合、ＵＥ２０の暫定識別子及び呼び出したいＡＰＩを明示してＣＣＦ３０Ｂに認可リクエストを送信する。続くステップ６において、ＣＣＦ３０Ｂは、暫定識別子から対象ＵＥ（契約者）を特定し、ＵＤＭ３０Ｇに対して当該契約者の加入者情報を確認する。
　続くステップ７において、ＵＤＭ３０Ｇは、加入者情報を返却する。図１２に示される許可ＡＰＩ、メソッド及び対象ユーザが関連付けられたテーブルを、ＵＤＭ３０Ｇは、加入者情報としてＣＣＦ３０Ｂに返却してもよい。続くステップ８において、ＣＣＦ３０Ｂは、加入者情報及に基づいて、当該契約書が目的のＡＰＩを呼び出してよいか否かを判定し、結果をＵＥ２０に通知する。ここで、ＵＥ２０は、必要に応じてパスワード入力等でＡＰＩ利用を許諾してもよい。続くステップ９において、ＣＣＦ３０Ｂは、ＡＰＩ呼び出し元３０Ａに対し、ＡＰＩの利用が認可されたことを示すＡｕｔｈｏｒｉｚａｔｉｏｎ　Ｃｏｄｅを発行する。
　図１５は、本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例（４）を説明するための図である。続くステップ１０において、ＡＰＩ呼び出し元３０Ａは、Ａｕｔｈｏｒｉｚａｔｉｏｎ　Ｃｏｄｅを用いて、ＡＰＩ呼び出しのアクセストークンを要求し、アクセストークンをＣＣＦ３０Ｂから受領する。続くステップ１１において、ＡＰＩ呼び出し元３０Ａは、アクセストークンを用いてサービスＡＰＩにアクセスする。
　図１６は、本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例（５）を説明するための図である。続くステップ１２において、ＡＥＦ３０Ｃは、ＣＣＦ３０Ｂに対し、ＡＰＩ要求を認可してよいか確認する。続くステップ１３において、ＣＣＦ３０Ｂは、ＵＤＭ３０ＧにＡＰＩ呼び出し元の加入者の加入者情報を要求する。続くステップ１４において、ＵＤＭ３０Ｇは、加入者情報を返却する。図１６に示される許可ＡＰＩ、メソッド及び対象ユーザが関連付けられたテーブルを、ＵＤＭ３０Ｇは、加入者情報としてＣＣＦ３０Ｂに返却してもよい。
　続くステップ１５において、ＣＣＦ３０Ｂは、加入者情報及びＡＰＩ要求に基づいて、認可してよいＡＰＩ要求か否かを判定し、結果をＡＥＦ３０Ｃに返却する。続くステップ１６において、ＣＣＦ３０Ｂにおいて当該ＡＰＩ利用が認可された場合、ＡＥＦ３０Ｃは要求に従って処理を実行し、ＡＰＩ利用可否の結果をＡＰＩ呼び出し元３０Ａに返却する。
　図１７は、本発明の実施の形態におけるＡＰＩのスコープを説明するための図である。図１７に示されるように、ＣＣＦ３０Ｂからの加入者識別子に基づく契約者情報の問い合わせに対して、ＵＤＭ３０Ｇは、個々の加入者情報に対して、当該加入者が許可されているＡＰＩ及び許可されたメソッド、許可されたユーザを一覧としてＣＣＦ３０Ｂに返却してもよい。例えば、ＵＤＭ３０Ｇは、図１７に示されるオプション１のように、許可ＡＰＩ、メソッド及び対象ユーザを関連付けて１エントリとしてＣＣＦ３０に返却してもよい。
　また、例えば、ＵＤＭ３０Ｇは、図１７に示されるオプション２のように、Ｒｏｌｅ対応表として、典型的なスコープの設定としてＲｏｌｅ、メソッド及び対象ユーザを１エントリとして関連付けて予め定義し、許可ＡＰＩといずれのＲｏｌｅかを示す情報を、ＣＣＦ３０Ｂに返却してもよい。すなわち、ＣＣＦ３０Ｂは、個々の加入者とＲｏｌｅを関連付けることで、各ＡＰＩで許可された動作を特定してもよい。
　図１８は、本発明の実施の形態におけるＵＥ及びＡＦを含むシステムの例を示す図である。図１８に示されるように、信頼済ドメインであるＰＬＭＮ（PLMN Trust domain）には、ＣＡＰＩＦ－ＡＰＩを含むＣＣＦ３０Ｂ、サービスＡＰＩを含むＡＥＦ３０Ｃ、ＡＰＦ（API Publishing Function）３０Ｄ、ＡＭＦ（API Management Function）３０Ｅ、コアネットワーク及びアクセスネットワークが属する。一方、ＰＬＭＮ外には、ＡＰＩ呼び出し元３０Ａ（例えばゲームサーバ）、ＵＥ２０が存在する。
　図１８に示されるように、ＡＰＩ呼び出し元３０Ａは、コアネットワークを介してＡＥＦ３０Ｃに接続されてもよいし、ＣＡＰＩＦ－ＡＰＩ及びサービスＡＰＩを呼び出し可能であってもよい。ＵＥ２０は、アクセスネットワーク及びコアネットワークを介して、ＡＰＩ呼び出し元３０Ａ、ＡＥＦ３０Ｃと接続されてもよい。
　図１９は、本発明の実施の形態におけるＵＥを含むシステムの例を示す図である。図１８に示されるように、信頼済ドメインであるＰＬＭＮには、ＣＡＰＩＦ－ＡＰＩを含むＣＣＦ３０Ｂ、サービスＡＰＩを含むＡＥＦ３０Ｃ、ＡＰＦ３０Ｄ、ＡＭＦ３０Ｅ、コアネットワーク及びアクセスネットワークが属する。一方、ＰＬＭＮ外には、ＵＥ２０が存在する。
　図１８に示されるように、ＵＥ２０は、アクセスネットワーク及びコアネットワークを介して、ＣＣＦ３０Ｂ、ＡＥＦ３０Ｃと接続されてもよいし、ＣＡＰＩＦ－ＡＰＩ及びサービスＡＰＩを呼び出し可能であってもよい。
　なお、図１８及び図１９はシステム構成の一例を示すものであり、これに限られない。例えば、ＡＥＦ３０Ｃ、ＡＰＦ３０Ｄ及びＡＭＦ３０Ｅが信頼済ＰＬＭＮドメイン外にあってもよい。
　図２０は、本発明の実施の形態におけるＵＥによるＡＰＩ呼び出しの例を説明するためのシーケンス図である。図２０を用いて、上述した図８から図１１までのＵＥによるＡＰＩ呼び出しの例の詳細な動作を説明する。
　ステップＳ１０１において、ＵＥ２０は、ＢＳＦ３０Ｆ及びＵＤＭ３０ＧとＢｏｏｔｓｔｒａｐｐｉｎｇ手順を実行する。続くステップＳ１０２において、ＵＥ２０は、ＣＣＦ２０Ｂとアプリケーション要求／応答を実行、ＣＣＦ２０Ｂは、ＢＳＦ３０Ｆと認証要求／応答を実行する。続くステップＳ１０３において、ＵＥ２０はＮＡ－ＧＵＴＩを取得する。続くステップＳ１０４において、ＵＥ２０はＣＣＦ３０Ｂから必要な通知を受けられるようＣＣＦ３０ＢにＳｕｂｓｃｒｉｂｅする。続くステップＳ１０５において、ＵＥ２０とＣＣＦ３０Ｂとの間のＴＬＳ（Transport Layer Security）接続が確立される。ステップＳ１０１からステップＳ１０５までの手順により、既存のＯｎｂｏａｒｄｉｎｇの代わりに、Ｂｏｏｔｓｔｒａｐｐｉｎｇにて端末２０を認証してからＵＥ－ＣＣＦ間で通信を行う。なお、ステップＳ１０４は、実行されてもよいし、実行されなくてもよい。
　ステップＳ１０６において、ＵＥ２０は、セキュリティメソッド要求をＣＣＦ３０Ｂに送信する。続くステップＳ１０７において、ＣＣＦ３０Ｂは、セキュリティメソッドを選択する。続くステップＳ１０８において、ＯＡｕｔｈ　２．０　Ｃｌｉｅｎｔ　Ｃｒｅｄｅｎｔｉａｌであるセキュリティメソッド応答が、ＣＣＦ３０ＢからＵＥ２０に送信される。ステップＳ１０６からステップＳ１０８までの手順により、ＡＰＩ呼び出しに使用するセキュリティメソッドが決定される。
　ステップＳ１０９において、ＵＥ２０は、ＮＡ－ＧＵＴＩを用いて、ＯＡｕｔｈ　２．０に基づいたアクセストークン要求をＣＣＦ３０Ｂに送信する。続くステップＳ１１０において、ＣＣＦ３０Ｂは、加入者情報の確認をＵＤＭ３０Ｇに対して行う。続くステップＳ１１１において、ＣＣＦ３０Ｂは、アクセストークン要求を検証する。続くステップＳ１１２において、ＣＣＦ３０Ｂは、ＯＡｕｔｈ　２．０によるアクセストークンをＵＥ２０に応答する。ステップＳ１０９からステップＳ１１２までの手順により、ＮＡ－ＧＵＴＩを用いてアクセストークンが発行され、ＡＰＩ呼び出しのためのアクセストークンを端末２０は取得する。
　ステップＳ１１３において、ＵＥ２０とＡＥＦ３０Ｃ間にＴＬＳ接続が確立される。続くステップＳ１１４において、ＵＥ２０は、ＯＡｕｔｈ　２．０によるアクセストークンによって、Ｎｏｒｔｈｂｏｕｎｄ　ＡＰＩをＡＥＦ３０Ｃに対して呼び出す。続くステップＳ１１５において、ＣＣＦ３０Ｂは、加入者情報の確認をＵＤＭ３０Ｇに対して行う。続くステップＳ１１６において、ＡＥＦ３０Ｃは、アクセストークンを検証する。続くステップＳ１１７において、ＡＥＦ３０Ｃは、Ｎｏｒｔｈｂｏｕｎｄ　ＡＰＩ呼び出しに係る応答をＵＥ２０に送信する。ステップＳ１１３からステップＳ１１７までの手順で、ＡＰＩ呼び出しが実行される。
　図２１は、本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例を説明するためのシーケンス（１）図である。図２２は、本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例を説明するためのシーケンス（２）図である。図２１及び図２２を用いて、上述した図１２から図１６までのＵＥ及びＡＦによるＡＰＩ呼び出しの例の詳細な動作を説明する。
　ステップＳ２０１において、ＡＭＦ３０Ｅは、Ｏｎｂｏａｄｉｎｇ登録情報（ＣＣＦ情報、ＯＡｕｔｈ　２．０アクセストークンを伴う）をＡＦ３０Ａに送信する。ステップＳ２０１はＡＦ３０Ａがオフラインの何らかの手法でＯｎｂｏａｄｉｎｇ登録情報を取得することでもよい。ステップＳ２０２において、ＡＦ３０ＡとＣＣＦ３０Ｂとの間にＴＬＳ接続が確立される。続くステップＳ２０３において、ＡＦ３０Ａは、Ｏｎｂｏａｒｄ　ＡＰＩ呼び出し要求（ＯＡｕｔｈ　２．０アクセストークン、ＡＰＩ呼び出しパブリックキーを伴う）をＣＣＦ３０Ｂに送信する。続くステップＳ２０４において、ＣＣＦ３０Ｂは、Ｏｎｂｏａｒｄ　ＡＰＩ呼び出し応答（ＡＰＩ呼び出しＩＤ、ＡＰＩ呼び出し証明書、Ｏｎｂｏａｒｄシークレットを伴う）をＡＦ３０Ａに送信する。ステップＳ２０１からステップＳ２０４までの動作で、ＡＦのＯｎｂｏａｒｄｉｎｇ（登録）が完了する。
　ステップＳ２０５において、ＵＥ２０は、ＢＳＦ３０Ｆ及びＵＤＭ３０ＧとＢｏｏｔｓｔｒａｐｐｉｎｇ手順を実行する。続くステップＳ２０６において、ＵＥ２０は、ＣＣＦ２０Ｂとアプリケーション要求／応答を実行、ＣＣＦ２０Ｂは、ＢＳＦ３０Ｆと認証要求／応答を実行する。続くステップＳ２０７において、ＵＥ２０はＮＡ－ＧＵＴＩを取得する。続くステップＳ２０８において、ＵＥ２０はＣＣＦ３０Ｂから必要な通知を受けられるようＣＣＦ３０ＢにＳｕｂｓｃｒｉｂｅする。ステップＳ２０５からステップＳ２０８までの手順により、Ｂｏｏｔｓｔｒａｐｐｉｎｇ完了する。すなわち、ＡＦ３０ＡはＯｎｂｏａｒｄｉｎｇを実施し、ＵＥ２０はＢｏｏｔｓｔｒａｐｐｉｎｇを実施する。
　ステップＳ２０９において、ＣＣＦ３０Ｂは、ＡＰＩ呼び出しのトリガを検知する。続くステップＳ２１０において、ＡＦ３０Ａは、セキュリティメソッド要求をＣＣＦ３０Ｂに送信する。続くステップＳ２１１において、ＣＣＦ３０Ｂは、セキュリティメソッドを選択する。続くステップＳ２１２において、ＣＣＦ３０Ｂは、ＯＡｕｔｈ　２．０　Ａｕｔｏｒｉｚａｔｉｏｎ　Ｃｏｄｅ　Ｆｌｏｗによるセキュリティメソッド応答をＡＦ３０Ａに送信する。ステップＳ２０９からステップＳ２１２までの手順でＡＰＩ呼び出しに使用するセキュリティメソッドが決定される。
　ステップＳ２１３において、ＡＦ３０Ａは、ユーザにＡＰＩ利用可否の確認を行う。ＵＥ２０は必要に応じて応答をＡＦ３０Ａに送信する。続くステップＳ２１４において、ＡＦ３０Ａは、ＣＡＰＩＦセキュリティ要求及び認証要求（ＮＡ－ＧＵＴＩを伴う）をＣＣＦ３０Ｂに送信する。続くステップＳ２１５において、ＣＣＦ３０Ｂは、加入者情報の確認をＵＤＭ３０Ｇに対して行う。続くステップＳ２１６において、ＵＥ２０とＣＣＦ３０Ｂとの間でＴＬＳ接続が確立される。続くステップＳ２１７において、ＵＥ２０とＣＣＦ３０Ｂとの間で、ＣＡＰＩＦセキュリティ要求及び認証通知要求／応答が実行される。続くステップＳ２１８において、ＣＣＦ３０Ｂは、Ａｕｔｈｏｒｉｚａｔｉｏｎ　Ｃｏｄｅを発行し、ＡＦ３０Ａに送信する。ステップＳ２１３からステップＳ２１８までの手順により、ユーザからの許可取得及びＡｕｔｈｏｒｉｚａｔｉｏｎ　Ｃｏｄｅの発行が実施される。
　ステップＳ２１９において、ＡＦ３０Ａは、Ａｕｔｈｏｒｉｚａｔｉｏｎ　ＣｏｄｅによるＯＡｕｔｈ　２．０によるアクセストークン要求をＣＣＦ３０Ｂに送信する。続くステップＳ２２０において、ＣＣＦ３０Ｂは、アクセストークン要求を検証する。続くステップＳ２２１において、ＯＡｕｔｈ　２．０によるアクセストークン（アクセストークン、有効期限、スコープを伴う）をＡＦ３０Ａに応答する。ステップＳ２１９からステップＳ２２１までの手順によって、ＡＰＩ呼び出しのためのアクセストークンが取得される。
　ステップＳ２２２において、ＡＦ３０ＡとＡＥＦ３０Ｃ間にＴＬＳ接続が確立される。続くステップＳ２２３において、ＡＦ３０Ａは、ＯＡｕｔｈ　２．０によるアクセストークンによって、Ｎｏｒｔｈｂｏｕｎｄ　ＡＰＩをＡＥＦ３０Ｃに対して呼び出す。続くステップＳ２２４において、ＣＣＦ３０Ｂは、加入者情報の確認をＵＤＭ３０Ｇに対して行う。続くステップＳ２２５において、ＡＥＦ３０Ｃは、アクセストークンを検証する。続くステップＳ２２６において、ＡＥＦ３０Ｃは、Ｎｏｒｔｈｂｏｕｎｄ　ＡＰＩ呼び出しに係る応答をＡＦ３０Ａに送信する。ステップＳ２２２からステップＳ２２６までの手順で、ＡＰＩ呼び出しが実行される。
　上述の実施例により、回線利用者の立場においては、個々の契約者の契約情報に基づいて、エンドユーザ自身が端末からコアネットワークのＡＰＩを利用し、ネットワークの制御ができるようになる。オペレータの立場においては、ネットワークが解放するＡＰＩのうち、個々の契約者が利用できるＡＰＩの粒度を加入者情報に基づいて管理することで、必要最低限のＡＰＩのみを利用者に開放することができる。
　また、ＡＰＩ呼び出しの事前準備として、既存のＯｎｂｏａｒｄｉｎｇに代替して、端末のＳＩＭ情報を使って、個々の契約者を認証するＢｏｏｔｓｔｒａｐｐｉｎｇを用いることにより、ＡＰＩ呼び出しのトリガとなる個々の契約者を識別することができる。
　また、個々の契約者が利用できるＡＰＩの範囲を加入者情報に保持しておき、当該加入者情報をチェックすることで、個人の粒度でＡＰＩ利用の権限を管理することができる。
　また、ＵＥ２０及びＡＦ３０ＡによるＡＰＩ呼び出しの場合、ＯＡｕｔｈ　２．０のＡｕｔｈｏｒｉｚａｔｉｏｎ　Ｃｏｄｅ　Ｆｌｏｗ方式を利用することで、サードパーティのＡＦ及びオペレータのネットワークノードが契約者の承諾を安全に取得しつつ、個々の契約者に許可されたＡＰＩを利用することができる。
　すなわち、ネットワークにおいて加入者情報を識別可能とするインタフェースを提供することができる。
　（装置構成）
　次に、これまでに説明した処理及び動作を実施する基地局１０、ネットワークノード３０及び端末２０の機能構成例を説明する。基地局１０、ネットワークノード３０及び端末２０は上述した実施例を実施する機能を含む。ただし、基地局１０、ネットワークノード３０及び端末２０はそれぞれ、実施例の中の一部の機能のみを備えることとしてもよい。
　＜基地局１０及びネットワークノード３０＞
　図２３は、基地局１０の機能構成の一例を示す図である。図２３に示されるように、基地局１０は、送信部１１０と、受信部１２０と、設定部１３０と、制御部１４０とを有する。図２３に示される機能構成は一例に過ぎない。本発明の実施の形態に係る動作を実施できるのであれば、機能区分及び機能部の名称はどのようなものでもよい。なお、ネットワークノード３０は、基地局１０と同様の機能構成を有してもよい。また、システムアーキテクチャ上で複数の異なる機能を有するネットワークノード３０は、機能ごとに分離された複数のネットワークノード３０から構成されてもよい。また、ネットワークノード３０は、コアネットワーク又はアクセスネットワークに存在するネットワークノードに限定されず、ＰＬＭＮドメインに属するネットワークノードに対応してもよい。
　送信部１１０は、端末２０又は他のネットワークノード３０に送信する信号を生成し、当該信号を有線又は無線で送信する機能を含む。受信部１２０は、端末２０又は他のネットワークノード３０から送信された各種の信号を受信し、受信した信号から、例えばより上位のレイヤの情報を取得する機能を含む。
　設定部１３０は、予め設定される設定情報、及び、端末２０に送信する各種の設定情報を記憶装置に格納し、必要に応じて記憶装置から読み出す。設定情報の内容は、例えば、ネットワークにおける加入者のプロファイル情報等である。
　制御部１４０は、実施例において説明したように、ネットワークにおける加入者のプロファイル情報の更新に係る処理を行う。また、制御部１４０は、端末２０との通信に係る処理を行う。制御部１４０における信号送信に関する機能部を送信部１１０に含め、制御部１４０における信号受信に関する機能部を受信部１２０に含めてもよい。
　＜端末２０＞
　図２４は、端末２０の機能構成の一例を示す図である。図２４に示されるように、端末２０は、送信部２１０と、受信部２２０と、設定部２３０と、制御部２４０とを有する。図２４に示される機能構成は一例に過ぎない。本発明の実施の形態に係る動作を実施できるのであれば、機能区分及び機能部の名称はどのようなものでもよい。
　送信部２１０は、送信データから送信信号を作成し、当該送信信号を無線で送信する。受信部２２０は、各種の信号を無線受信し、受信した物理レイヤの信号からより上位のレイヤの信号を取得する。また、受信部２２０は、ネットワークノード３０から送信されるＮＲ－ＰＳＳ、ＮＲ－ＳＳＳ、ＮＲ－ＰＢＣＨ、ＤＬ／ＵＬ制御信号又は参照信号等を受信する機能を有する。
　設定部２３０は、受信部２２０によりネットワークノード３０から受信した各種の設定情報を記憶装置に格納し、必要に応じて記憶装置から読み出す。また、設定部２３０は、予め設定される設定情報も格納する。設定情報の内容は、例えば、接続が許可されるネットワークに係る情報等である。
　制御部２４０は、実施例において説明したように、ネットワーク及びネットワークスライスへの接続制御に係る処理を行う。制御部２４０における信号送信に関する機能部を送信部２１０に含め、制御部２４０における信号受信に関する機能部を受信部２２０に含めてもよい。
　（ハードウェア構成）
　上記実施形態の説明に用いたブロック図（図２３及び図２４）は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及びソフトウェアの少なくとも一方の任意の組み合わせによって実現される。また、各機能ブロックの実現方法は特に限定されない。すなわち、各機能ブロックは、物理的又は論理的に結合した１つの装置を用いて実現されてもよいし、物理的又は論理的に分離した２つ以上の装置を直接的又は間接的に（例えば、有線、無線などを用いて）接続し、これら複数の装置を用いて実現されてもよい。機能ブロックは、上記１つの装置又は上記複数の装置にソフトウェアを組み合わせて実現されてもよい。
　機能には、判断、決定、判定、計算、算出、処理、導出、調査、探索、確認、受信、送信、出力、アクセス、解決、選択、選定、確立、比較、想定、期待、見做し、報知（broadcasting）、通知（notifying）、通信（communicating）、転送（forwarding）、構成（configuring）、再構成（reconfiguring）、割り当て（allocating、mapping）、割り振り（assigning）などがあるが、これらに限られない。たとえば、送信を機能させる機能ブロック（構成部）は、送信部（transmitting　unit）や送信機（transmitter）と呼称される。いずれも、上述したとおり、実現方法は特に限定されない。
　例えば、本開示の一実施の形態におけるネットワークノード３０、端末２０等は、本開示の無線通信方法の処理を行うコンピュータとして機能してもよい。図２５は、本開示の一実施の形態に係る基地局１０及び端末２０のハードウェア構成の一例を示す図である。ネットワークノード３０は、基地局１０と同様のハードウェア構成を有してもよい。上述の基地局１０及び端末２０は、物理的には、プロセッサ１００１、記憶装置１００２、補助記憶装置１００３、通信装置１００４、入力装置１００５、出力装置１００６、バス１００７などを含むコンピュータ装置として構成されてもよい。
　なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニット等に読み替えることができる。基地局１０及び端末２０のハードウェア構成は、図に示した各装置を１つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。
　基地局１０及び端末２０における各機能は、プロセッサ１００１、記憶装置１００２等のハードウェア上に所定のソフトウェア（プログラム）を読み込ませることによって、プロセッサ１００１が演算を行い、通信装置１００４による通信を制御したり、記憶装置１００２及び補助記憶装置１００３におけるデータの読み出し及び書き込みの少なくとも一方を制御したりすることによって実現される。
　プロセッサ１００１は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１００１は、周辺装置とのインタフェース、制御装置、演算装置、レジスタ等を含む中央処理装置（ＣＰＵ：Central Processing Unit）で構成されてもよい。例えば、上述の制御部１４０、制御部２４０等は、プロセッサ１００１によって実現されてもよい。
　また、プロセッサ１００１は、プログラム（プログラムコード）、ソフトウェアモジュール又はデータ等を、補助記憶装置１００３及び通信装置１００４の少なくとも一方から記憶装置１００２に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施の形態において説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。例えば、図２３に示した基地局１０の制御部１４０は、記憶装置１００２に格納され、プロセッサ１００１で動作する制御プログラムによって実現されてもよい。また、例えば、図２４に示した端末２０の制御部２４０は、記憶装置１００２に格納され、プロセッサ１００１で動作する制御プログラムによって実現されてもよい。上述の各種処理は、１つのプロセッサ１００１によって実行される旨を説明してきたが、２以上のプロセッサ１００１により同時又は逐次に実行されてもよい。プロセッサ１００１は、１以上のチップによって実装されてもよい。なお、プログラムは、電気通信回線を介してネットワークから送信されてもよい。
　記憶装置１００２は、コンピュータ読み取り可能な記録媒体であり、例えば、ＲＯＭ（Read Only Memory）、ＥＰＲＯＭ（Erasable Programmable ROM）、ＥＥＰＲＯＭ（Electrically Erasable Programmable ROM）、ＲＡＭ（Random Access Memory）等の少なくとも１つによって構成されてもよい。記憶装置１００２は、レジスタ、キャッシュ、メインメモリ（主記憶装置）等と呼ばれてもよい。記憶装置１００２は、本開示の一実施の形態に係る通信方法を実施するために実行可能なプログラム（プログラムコード）、ソフトウェアモジュール等を保存することができる。
　補助記憶装置１００３は、コンピュータ読み取り可能な記録媒体であり、例えば、ＣＤ－ＲＯＭ（Compact Disc ROM）等の光ディスク、ハードディスクドライブ、フレキシブルディスク、光磁気ディスク（例えば、コンパクトディスク、デジタル多用途ディスク、Ｂｌｕ－ｒａｙ（登録商標）ディスク）、スマートカード、フラッシュメモリ（例えば、カード、スティック、キードライブ）、フロッピー（登録商標）ディスク、磁気ストリップ等の少なくとも１つによって構成されてもよい。上述の記憶媒体は、例えば、記憶装置１００２及び補助記憶装置１００３の少なくとも一方を含むデータベース、サーバその他の適切な媒体であってもよい。
　通信装置１００４は、有線ネットワーク及び無線ネットワークの少なくとも一方を介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。通信装置１００４は、例えば周波数分割複信（ＦＤＤ：Frequency　Division　Duplex）及び時分割複信（ＴＤＤ：Time　Division　Duplex）の少なくとも一方を実現するために、高周波スイッチ、デュプレクサ、フィルタ、周波数シンセサイザなどを含んで構成されてもよい。例えば、送受信アンテナ、アンプ部、送受信部、伝送路インタフェース等は、通信装置１００４によって実現されてもよい。送受信部は、送信部と受信部とで、物理的に、または論理的に分離された実装がなされてもよい。
　入力装置１００５は、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサ等）である。出力装置１００６は、外部への出力を実施する出力デバイス（例えば、ディスプレイ、スピーカー、LEDランプ等）である。なお、入力装置１００５及び出力装置１００６は、一体となった構成（例えば、タッチパネル）であってもよい。
　また、プロセッサ１００１及び記憶装置１００２等の各装置は、情報を通信するためのバス１００７によって接続される。バス１００７は、単一のバスを用いて構成されてもよいし、装置間ごとに異なるバスを用いて構成されてもよい。
　また、基地局１０及び端末２０は、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）、ＦＰＧＡ（Field Programmable Gate Array）等のハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ１００１は、これらのハードウェアの少なくとも１つを用いて実装されてもよい。
　（実施の形態のまとめ）
　以上、説明したように、本発明の実施の形態によれば、端末を認証し暫定識別子を当該端末に送信する送信部と、前記暫定識別子を含む要求又は前記暫定識別子に基づく認証コードを受信する受信部と、前記暫定識別子を含む要求又は前記認証コードに基づいて、アクセストークンを発行する制御部とを有し、前記送信部は、前記アクセストークンを前記端末又は外部アプリケーションに送信し、前記受信部は、前記アクセストークンに基づくＡＰＩ（Application Programming Interface）呼び出し要求を前記端末又は前記外部アプリケーションから受信し、前記制御部は、前記アクセストークンを検証して前記ＡＰＩ呼び出し要求が認可されたものであると判定した場合、前記ＡＰＩ呼び出し要求に基づいて処理を実行するネットワークノードが提供される。
　上記の構成により、回線利用者の立場においては、個々の契約者の契約情報に基づいて、エンドユーザ自身が端末からコアネットワークのＡＰＩを利用し、ネットワークの制御ができるようになる。オペレータの立場においては、ネットワークが解放するＡＰＩのうち、個々の契約者が利用できるＡＰＩの粒度を加入者情報に基づいて管理することで、必要最低限のＡＰＩのみを利用者に開放することができる。また、ＡＰＩ呼び出しの事前準備として、既存のＯｎｂｏａｒｄｉｎｇに代替して、端末のＳＩＭ情報を使って、個々の契約者を認証するＢｏｏｔｓｔｒａｐｐｉｎｇを用いることにより、ＡＰＩ呼び出しのトリガとなる個々の契約者を識別することができる。また、個々の契約者が利用できるＡＰＩの範囲を加入者情報に保持しておき、当該加入者情報をチェックすることで、個人の粒度でＡＰＩ利用の権限を管理することができる。また、ＵＥ２０及びＡＦ３０ＡによるＡＰＩ呼び出しの場合、ＯＡｕｔｈ　２．０のＡｕｔｈｏｒｉｚａｔｉｏｎ　Ｃｏｄｅ　Ｆｌｏｗ方式を利用することで、サードパーティのＡＦ及びオペレータのネットワークノードが契約者の承諾を安全に取得しつつ、個々の契約者に許可されたＡＰＩを利用することができる。すなわち、ネットワークにおいて加入者情報を識別可能とするインタフェースを提供することができる。
　前記受信部は、前記端末又は前記外部アプリケーションからＡＰＩ呼び出しに使用するセキュリティメソッドに係る要求を受信し、前記制御部は、セキュリティメソッドを選択し、前記送信部は、前記選択したセキュリティメソッドを示す応答を前記端末又は外部アプリケーションに送信してもよい。当該構成により、ネットワークノードは、ＡＰＩ呼び出しに使用するセキュリティメソッドを選択し設定することができる。
　前記送信部が前記アクセストークンを前記外部アプリケーションに送信する場合、前記制御部は、前記外部アプリケーションを予め認証し登録してもよい。当該構成により、ネットワークノードは、認証された外部アプリケーションから、ＵＥに係るＡＰＩ呼び出しを受けることができる。
　前記送信部が前記アクセストークンを前記外部アプリケーションに送信する場合、前記制御部は、ユーザにＡＰＩ利用可否の確認を実施した後、前記アクセストークンを発行してもよい。当該構成により、ネットワークノードは、外部アプリケーションがＡＰＩ呼び出しを実行する場合、事前にユーザの意図を確認してからＡＰＩ呼び出しを実行することができる。
　前記制御部は、前記ＡＰＩ呼び出し要求が認可されたものであるかを判定するとき、少なくともユーザごとのスコープが設定される、許可されるＡＰＩ及び許可されるメソッドを参照してもよい。当該構成により、ネットワークノードは、ユーザごとの粒度のスコープで、ＡＰＩ呼び出しを制御することができる。
　また、本発明の実施の形態によれば、端末を認証し暫定識別子を当該端末に送信する送信手順と、前記暫定識別子を含む要求又は前記暫定識別子に基づく認証コードを受信する受信手順と、前記暫定識別子を含む要求又は前記認証コードに基づいて、アクセストークンを発行する制御手順と、前記アクセストークンを前記端末又は外部アプリケーションに送信する手順と、前記アクセストークンに基づくＡＰＩ（Application Programming Interface）呼び出し要求を前記端末又は前記外部アプリケーションから受信する手順と、前記アクセストークンを検証して前記ＡＰＩ呼び出し要求が認可されたものであると判定した場合、前記ＡＰＩ呼び出し要求に基づいて処理を実行する手順とをネットワークノードが実行する通信方法が提供される。
　上記の構成により、回線利用者の立場においては、個々の契約者の契約情報に基づいて、エンドユーザ自身が端末からコアネットワークのＡＰＩを利用し、ネットワークの制御ができるようになる。オペレータの立場においては、ネットワークが解放するＡＰＩのうち、個々の契約者が利用できるＡＰＩの粒度を加入者情報に基づいて管理することで、必要最低限のＡＰＩのみを利用者に開放することができる。また、ＡＰＩ呼び出しの事前準備として、既存のＯｎｂｏａｒｄｉｎｇに代替して、端末のＳＩＭ情報を使って、個々の契約者を認証するＢｏｏｔｓｔｒａｐｐｉｎｇを用いることにより、ＡＰＩ呼び出しのトリガとなる個々の契約者を識別することができる。また、個々の契約者が利用できるＡＰＩの範囲を加入者情報に保持しておき、当該加入者情報をチェックすることで、個人の粒度でＡＰＩ利用の権限を管理することができる。また、ＵＥ２０及びＡＦ３０ＡによるＡＰＩ呼び出しの場合、ＯＡｕｔｈ　２．０のＡｕｔｈｏｒｉｚａｔｉｏｎ　Ｃｏｄｅ　Ｆｌｏｗ方式を利用することで、サードパーティのＡＦ及びオペレータのネットワークノードが契約者の承諾を安全に取得しつつ、個々の契約者に許可されたＡＰＩを利用することができる。すなわち、ネットワークにおいて加入者情報を識別可能とするインタフェースを提供することができる。
　（実施形態の補足）
　以上、本発明の実施の形態を説明してきたが、開示される発明はそのような実施形態に限定されず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。発明の理解を促すため具体的な数値例を用いて説明がなされたが、特に断りのない限り、それらの数値は単なる一例に過ぎず適切な如何なる値が使用されてもよい。上記の説明における項目の区分けは本発明に本質的ではなく、２以上の項目に記載された事項が必要に応じて組み合わせて使用されてよいし、ある項目に記載された事項が、別の項目に記載された事項に（矛盾しない限り）適用されてよい。機能ブロック図における機能部又は処理部の境界は必ずしも物理的な部品の境界に対応するとは限らない。複数の機能部の動作が物理的には１つの部品で行われてもよいし、あるいは１つの機能部の動作が物理的には複数の部品により行われてもよい。実施の形態で述べた処理手順については、矛盾の無い限り処理の順序を入れ替えてもよい。処理説明の便宜上、ネットワークノード３０及び端末２０は機能的なブロック図を用いて説明されたが、そのような装置はハードウェアで、ソフトウェアで又はそれらの組み合わせで実現されてもよい。本発明の実施の形態に従ってネットワークノード３０が有するプロセッサにより動作するソフトウェア及び本発明の実施の形態に従って端末２０が有するプロセッサにより動作するソフトウェアはそれぞれ、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、読み取り専用メモリ（ＲＯＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、レジスタ、ハードディスク（ＨＤＤ）、リムーバブルディスク、ＣＤ－ＲＯＭ、データベース、サーバその他の適切な如何なる記憶媒体に保存されてもよい。
　また、情報の通知は、本開示で説明した態様／実施形態に限られず、他の方法を用いて行われてもよい。例えば、情報の通知は、物理レイヤシグナリング（例えば、ＤＣＩ（Downlink Control Information）、ＵＣＩ（Uplink Control Information））、上位レイヤシグナリング（例えば、ＲＲＣ（Radio Resource Control）シグナリング、ＭＡＣ（Medium Access Control）シグナリング、報知情報（ＭＩＢ（Master Information Block）、ＳＩＢ（System Information Block））、その他の信号又はこれらの組み合わせによって実施されてもよい。また、ＲＲＣシグナリングは、ＲＲＣメッセージと呼ばれてもよく、例えば、ＲＲＣ接続セットアップ（RRC Connection Setup）メッセージ、ＲＲＣ接続再構成（RRC Connection Reconfiguration）メッセージ等であってもよい。
　本開示において説明した各態様／実施形態は、ＬＴＥ（Long　Term　Evolution）、ＬＴＥ－Ａ（LTE-Advanced）、ＳＵＰＥＲ　３Ｇ、ＩＭＴ－Ａｄｖａｎｃｅｄ、４Ｇ（4th　generation　mobile　communication　system）、５Ｇ（5th　generation　mobile　communication　system）、ＦＲＡ（Future　Radio　Access）、ＮＲ（new　Radio）、Ｗ－ＣＤＭＡ（登録商標）、ＧＳＭ（登録商標）、ＣＤＭＡ２０００、ＵＭＢ（Ultra　Mobile　Broadband）、ＩＥＥＥ　８０２．１１（Ｗｉ－Ｆｉ（登録商標））、ＩＥＥＥ　８０２．１６（ＷｉＭＡＸ（登録商標））、ＩＥＥＥ　８０２．２０、ＵＷＢ（Ultra-WideBand）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の適切なシステムを利用するシステム及びこれらに基づいて拡張された次世代システムの少なくとも一つに適用されてもよい。また、複数のシステムが組み合わされて（例えば、ＬＴＥ及びＬＴＥ－Ａの少なくとも一方と５Ｇとの組み合わせ等）適用されてもよい。
　本明細書で説明した各態様／実施形態の処理手順、シーケンス、フローチャート等は、矛盾の無い限り、順序を入れ替えてもよい。例えば、本開示において説明した方法については、例示的な順序を用いて様々なステップの要素を提示しており、提示した特定の順序に限定されない。
　本明細書においてネットワークノード３０によって行われるとした特定動作は、場合によってはその上位ノード（upper node）によって行われることもある。ネットワークノード３０を有する１つ又は複数のネットワークノード（network nodes）からなるネットワークにおいて、端末２０との通信のために行われる様々な動作は、ネットワークノード３０及びネットワークノード３０以外の他のネットワークノード（例えば、ＭＭＥ又はＳ－ＧＷ等が考えられるが、これらに限られない）の少なくとも１つによって行われ得ることは明らかである。上記においてネットワークノード３０以外の他のネットワークノードが１つである場合を例示したが、他のネットワークノードは、複数の他のネットワークノードの組み合わせ（例えば、ＭＭＥ及びＳ－ＧＷ）であってもよい。
　本開示において説明した情報又は信号等は、上位レイヤ（又は下位レイヤ）から下位レイヤ（又は上位レイヤ）へ出力され得る。複数のネットワークノードを介して入出力されてもよい。
　入出力された情報等は特定の場所（例えば、メモリ）に保存されてもよいし、管理テーブルを用いて管理してもよい。入出力される情報等は、上書き、更新、又は追記され得る。出力された情報等は削除されてもよい。入力された情報等は他の装置へ送信されてもよい。
　本開示における判定は、１ビットで表される値（０か１か）によって行われてもよいし、真偽値（Boolean：true又はfalse）によって行われてもよいし、数値の比較（例えば、所定の値との比較）によって行われてもよい。
　ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能などを意味するよう広く解釈されるべきである。
　また、ソフトウェア、命令、情報などは、伝送媒体を介して送受信されてもよい。例えば、ソフトウェアが、有線技術（同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ：Digital　Subscriber　Line）など）及び無線技術（赤外線、マイクロ波など）の少なくとも一方を使用してウェブサイト、サーバ、又は他のリモートソースから送信される場合、これらの有線技術及び無線技術の少なくとも一方は、伝送媒体の定義内に含まれる。
　本開示において説明した情報、信号などは、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップなどは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。
　なお、本開示において説明した用語及び本開示の理解に必要な用語については、同一の又は類似する意味を有する用語と置き換えてもよい。例えば、チャネル及びシンボルの少なくとも一方は信号（シグナリング）であってもよい。また、信号はメッセージであってもよい。また、コンポーネントキャリア（ＣＣ：Component　Carrier）は、キャリア周波数、セル、周波数キャリアなどと呼ばれてもよい。
　本開示において使用する「システム」及び「ネットワーク」という用語は、互換的に使用される。
　また、本開示において説明した情報、パラメータなどは、絶対値を用いて表されてもよいし、所定の値からの相対値を用いて表されてもよいし、対応する別の情報を用いて表されてもよい。例えば、無線リソースはインデックスによって指示されるものであってもよい。
　上述したパラメータに使用する名称はいかなる点においても限定的な名称ではない。さらに、これらのパラメータを使用する数式等は、本開示で明示的に開示したものと異なる場合もある。様々なチャネル（例えば、ＰＵＣＣＨ、ＰＤＣＣＨなど）及び情報要素は、あらゆる好適な名称によって識別できるので、これらの様々なチャネル及び情報要素に割り当てている様々な名称は、いかなる点においても限定的な名称ではない。
　本開示においては、「基地局（ＢＳ：Base　Station）」、「無線基地局」、「基地局装置」、「固定局（fixed　station）」、「ＮｏｄｅＢ」、「ｅＮｏｄｅＢ（ｅＮＢ）」、「ｇＮｏｄｅＢ（ｇＮＢ）」、「アクセスポイント（access　point）」、「送信ポイント（transmission　point）」、「受信ポイント（reception　point）、「送受信ポイント（transmission/reception　point）」、「セル」、「セクタ」、「セルグループ」、「キャリア」、「コンポーネントキャリア」などの用語は、互換的に使用され得る。基地局は、マクロセル、スモールセル、フェムトセル、ピコセルなどの用語で呼ばれる場合もある。
　基地局は、１つ又は複数（例えば、３つ）のセルを収容することができる。基地局が複数のセルを収容する場合、基地局のカバレッジエリア全体は複数のより小さいエリアに区分でき、各々のより小さいエリアは、基地局サブシステム（例えば、屋内用の小型基地局（ＲＲＨ：Ｒｅｍｏｔｅ　Ｒａｄｉｏ　Ｈｅａｄ）によって通信サービスを提供することもできる。「セル」又は「セクタ」という用語は、このカバレッジにおいて通信サービスを行う基地局及び基地局サブシステムの少なくとも一方のカバレッジエリアの一部又は全体を指す。
　本開示においては、「移動局（ＭＳ：Mobile　Station）」、「ユーザ端末（user　terminal）」、「ユーザ装置（ＵＥ：User　Equipment）」、「端末」などの用語は、互換的に使用され得る。
　移動局は、当業者によって、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、又はいくつかの他の適切な用語で呼ばれる場合もある。
　基地局及び移動局の少なくとも一方は、送信装置、受信装置、通信装置などと呼ばれてもよい。なお、基地局及び移動局の少なくとも一方は、移動体に搭載されたデバイス、移動体自体などであってもよい。当該移動体は、乗り物（例えば、車、飛行機など）であってもよいし、無人で動く移動体（例えば、ドローン、自動運転車など）であってもよいし、ロボット（有人型又は無人型）であってもよい。なお、基地局及び移動局の少なくとも一方は、必ずしも通信動作時に移動しない装置も含む。例えば、基地局及び移動局の少なくとも一方は、センサなどのＩｏＴ（Internet of Things）機器であってもよい。
　また、本開示における基地局は、ユーザ端末で読み替えてもよい。例えば、基地局及びユーザ端末間の通信を、複数の端末２０間の通信（例えば、Ｄ２Ｄ（Device-to-Device）、Ｖ２Ｘ（Vehicle-to-Everything）などと呼ばれてもよい）に置き換えた構成について、本開示の各態様／実施形態を適用してもよい。この場合、上述のネットワークノード３０が有する機能を端末２０が有する構成としてもよい。また、「上り」及び「下り」などの文言は、端末間通信に対応する文言（例えば、「サイド（side）」）で読み替えられてもよい。例えば、上りチャネル、下りチャネルなどは、サイドチャネルで読み替えられてもよい。
　同様に、本開示におけるユーザ端末は、基地局で読み替えてもよい。この場合、上述のユーザ端末が有する機能を基地局が有する構成としてもよい。
　本開示で使用する「判断(determining)」、「決定(determining)」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、判定(judging)、計算(calculating)、算出(computing)、処理(processing)、導出(deriving)、調査(investigating)、探索(looking　up、search、inquiry)（例えば、テーブル、データベース又は別のデータ構造での探索）、確認(ascertaining)した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、受信(receiving)（例えば、情報を受信すること）、送信(transmitting)(例えば、情報を送信すること)、入力(input)、出力(output)、アクセス(accessing)（例えば、メモリ中のデータにアクセスすること）した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、解決(resolving)、選択(selecting)、選定(choosing)、確立(establishing)、比較(comparing)などした事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。また、「判断（決定）」は、「想定する（assuming）」、「期待する（expecting）」、「みなす（considering）」などで読み替えられてもよい。
　「接続された(connected)」、「結合された(coupled)」という用語、又はこれらのあらゆる変形は、２又はそれ以上の要素間の直接的又は間接的なあらゆる接続又は結合を意味し、互いに「接続」又は「結合」された２つの要素間に１又はそれ以上の中間要素が存在することを含むことができる。要素間の結合又は接続は、物理的なものであっても、論理的なものであっても、或いはこれらの組み合わせであってもよい。例えば、「接続」は「アクセス」で読み替えられてもよい。本開示で使用する場合、２つの要素は、１又はそれ以上の電線、ケーブル及びプリント電気接続の少なくとも一つを用いて、並びにいくつかの非限定的かつ非包括的な例として、無線周波数領域、マイクロ波領域及び光（可視及び不可視の両方）領域の波長を有する電磁エネルギーなどを用いて、互いに「接続」又は「結合」されると考えることができる。
　参照信号は、ＲＳ（Reference　Signal）と略称することもでき、適用される標準によってパイロット（Pilot）と呼ばれてもよい。
　本開示において使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。
　本開示において使用する「第１の」、「第２の」などの呼称を使用した要素へのいかなる参照も、それらの要素の量又は順序を全般的に限定しない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本開示において使用され得る。したがって、第１及び第２の要素への参照は、２つの要素のみが採用され得ること、又は何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。
　上記の各装置の構成における「手段」を、「部」、「回路」、「デバイス」等に置き換えてもよい。
　本開示において、「含む（include）」、「含んでいる（including）」及びそれらの変形が使用されている場合、これらの用語は、用語「備える（comprising）」と同様に、包括的であることが意図される。さらに、本開示において使用されている用語「又は（or）」は、排他的論理和ではないことが意図される。
　本開示において、例えば、英語でのa, an及びtheのように、翻訳により冠詞が追加された場合、本開示は、これらの冠詞の後に続く名詞が複数形であることを含んでもよい。
　本開示において、「ＡとＢが異なる」という用語は、「ＡとＢが互いに異なる」ことを意味してもよい。なお、当該用語は、「ＡとＢがそれぞれＣと異なる」ことを意味してもよい。「離れる」、「結合される」などの用語も、「異なる」と同様に解釈されてもよい。
　本開示において説明した各態様／実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的に行うものに限られず、暗黙的（例えば、当該所定の情報の通知を行わない）ことによって行われてもよい。
　なお、本開示におけるＡＦは、外部アプリケーションの一例である。ＮＡ－ＧＵＴＩは、暫定識別子の一例である。
　以上、本開示について詳細に説明したが、当業者にとっては、本開示が本開示中に説明した実施形態に限定されるものではないということは明らかである。本開示は、請求の範囲の記載により定まる本開示の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本開示の記載は、例示説明を目的とするものであり、本開示に対して何ら制限的な意味を有するものではない。
１０　　　　基地局
１１０　　　送信部
１２０　　　受信部
１３０　　　設定部
１４０　　　制御部
２０　　　　端末
２１０　　　送信部
２２０　　　受信部
２３０　　　設定部
２４０　　　制御部
３０　　　　ネットワークノード
１００１　　プロセッサ
１００２　　記憶装置
１００３　　補助記憶装置
１００４　　通信装置
１００５　　入力装置
１００６　　出力装置

Claims (6)

  1. 　端末を認証し暫定識別子を当該端末に送信する送信部と、
    　前記暫定識別子を含む要求又は前記暫定識別子に基づく認証コードを受信する受信部と、
    　前記暫定識別子を含む要求又は前記認証コードに基づいて、アクセストークンを発行する制御部とを有し、
    　前記送信部は、前記アクセストークンを前記端末又は外部アプリケーションに送信し、
    　前記受信部は、前記アクセストークンに基づくＡＰＩ（Application Programming Interface）呼び出し要求を前記端末又は前記外部アプリケーションから受信し、
    　前記制御部は、前記アクセストークンを検証して前記ＡＰＩ呼び出し要求が認可されたものであると判定した場合、前記ＡＰＩ呼び出し要求に基づいて処理を実行するネットワークノード。
  2. 　前記受信部は、前記端末又は前記外部アプリケーションからＡＰＩ呼び出しに使用するセキュリティメソッドに係る要求を受信し、
    　前記制御部は、セキュリティメソッドを選択し、
    　前記送信部は、前記選択したセキュリティメソッドを示す応答を前記端末又は外部アプリケーションに送信する請求項１記載のネットワークノード。
  3. 　前記送信部が前記アクセストークンを前記外部アプリケーションに送信する場合、前記制御部は、前記外部アプリケーションを予め認証し登録している請求項１記載のネットワークノード。
  4. 　前記送信部が前記アクセストークンを前記外部アプリケーションに送信する場合、前記制御部は、ユーザにＡＰＩ利用可否の確認を実施した後、前記アクセストークンを発行する請求項３記載のネットワークノード。
  5. 　前記制御部は、前記ＡＰＩ呼び出し要求が認可されたものであるかを判定するとき、少なくともユーザごとのスコープが設定される、許可されるＡＰＩ及び許可されるメソッドを参照する請求項１記載のネットワークノード。
  6. 　端末を認証し暫定識別子を当該端末に送信する送信手順と、
    　前記暫定識別子を含む要求又は前記暫定識別子に基づく認証コードを受信する受信手順と、
    　前記暫定識別子を含む要求又は前記認証コードに基づいて、アクセストークンを発行する制御手順と、
    　前記アクセストークンを前記端末又は外部アプリケーションに送信する手順と、
    　前記アクセストークンに基づくＡＰＩ（Application Programming Interface）呼び出し要求を前記端末又は前記外部アプリケーションから受信する手順と、
    　前記アクセストークンを検証して前記ＡＰＩ呼び出し要求が認可されたものであると判定した場合、前記ＡＰＩ呼び出し要求に基づいて処理を実行する手順とをネットワークノードが実行する通信方法。
PCT/JP2021/011495 2021-03-19 2021-03-19 ネットワークノード及び通信方法 WO2022195878A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2023506691A JPWO2022195878A1 (ja) 2021-03-19 2021-03-19
PCT/JP2021/011495 WO2022195878A1 (ja) 2021-03-19 2021-03-19 ネットワークノード及び通信方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/011495 WO2022195878A1 (ja) 2021-03-19 2021-03-19 ネットワークノード及び通信方法

Publications (1)

Publication Number Publication Date
WO2022195878A1 true WO2022195878A1 (ja) 2022-09-22

Family

ID=83322121

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/011495 WO2022195878A1 (ja) 2021-03-19 2021-03-19 ネットワークノード及び通信方法

Country Status (2)

Country Link
JP (1) JPWO2022195878A1 (ja)
WO (1) WO2022195878A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20240004671A1 (en) * 2022-06-29 2024-01-04 Microsoft Technology Licensing, Llc Centralized control of lighting-enabled peripheral devices

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
NEC: "Correction/enhancement in CAPIF TS", 3GPP DRAFT; S3-183341_CR_CAPIF_33122, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG3, no. Spokane (US); 20181112 - 20181116, 12 November 2018 (2018-11-12), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051564595 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20240004671A1 (en) * 2022-06-29 2024-01-04 Microsoft Technology Licensing, Llc Centralized control of lighting-enabled peripheral devices

Also Published As

Publication number Publication date
JPWO2022195878A1 (ja) 2022-09-22

Similar Documents

Publication Publication Date Title
CN111263334B (zh) 向移动无线设备配置电子用户身份模块
CN114128396A (zh) 蜂窝切片网络中的中继选择
WO2020145300A1 (ja) ユーザ装置、ネットワークノード及び通信システム
JP7412419B2 (ja) ネットワークノード
WO2020145299A1 (ja) ネットワークノード及び通知方法
WO2021232919A1 (zh) 一种网络的接入方法、装置及系统
WO2022159725A1 (en) Federated identity management in fifth generation (5g) system
JP7169827B2 (ja) 端末及び通信方法
WO2022195878A1 (ja) ネットワークノード及び通信方法
JP7341167B2 (ja) ネットワークノード、ユーザ装置、及び通信方法
WO2022113370A1 (ja) ネットワークノード及び通信方法
WO2022091188A1 (ja) ネットワークノード及び通信方法
KR20230130061A (ko) 셀룰러 통신 네트워크의 등록 영역 내 이기종 슬라이스배치
WO2023084635A1 (ja) ネットワークノード及び通信方法
WO2022029957A1 (ja) 端末、ネットワークノード及び通信方法
WO2023152800A1 (ja) 通信装置、ネットワークノード装置、システム、及び通信方法
WO2022239160A1 (ja) 端末及び通信方法
WO2023021583A1 (ja) ネットワークノード及び通信方法
WO2022172443A1 (ja) ネットワークノード及び通信方法
WO2022162920A1 (ja) ネットワークノード及び通信方法
WO2023275996A1 (ja) ネットワークノード及び通信方法
WO2022157899A1 (ja) ネットワークノード、無線通信システム及び通信方法
WO2023084606A1 (ja) ネットワークノード、リソースオーナー装置、システム、及び通信方法
CN114600487B (zh) 身份认证方法及通信装置
US20220377548A1 (en) Methods and apparatus for controlling permissions of a ue for accessing a network

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21931624

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2023506691

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21931624

Country of ref document: EP

Kind code of ref document: A1