Authorization device, communication system, and authorization method
The authorization device in the 5G system addresses user experience issues in ID federation by authenticating terminals and managing dynamic user information, ensuring seamless authentication and personalized service delivery.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- NTT DOCOMO INC
- Filing Date
- 2022-10-11
- Publication Date
- 2026-07-08
AI Technical Summary
Conventional ID federation mechanisms, such as OpenID® Connect, often result in deteriorated user experience due to errors when handling authentication requests with specific parameters, particularly during user migration between applications, and lack the capability to manage dynamic user information effectively.
The introduction of an authorization device that checks terminal authentication status within the 5G communication system, generates authorization codes, and includes a user information disclosure function to handle dynamic user information, enabling proper processing of authentication requests and ID linking.
Enables smooth user experience by handling authentication requests without errors and facilitates tailored services based on dynamic user information within the 5G system, enhancing ID federation capabilities.
Smart Images

Figure 0007886959000001 
Figure 0007886959000002 
Figure 0007886959000003
Abstract
Description
Technical Field
[0004]
[0001] The present invention relates to a technology for ID association.
Background Art
[0002] In 3GPP (registered trademark) (3rd Generation Partnership Project), in order to achieve further increase in system capacity, further increase in data transmission speed, further reduction in latency in the radio section, etc., a radio communication method called 5G or NR (New Radio) (hereinafter, this radio communication method is referred to as "5G" or "NR") is being studied. In 5G, in order to meet the requirement of achieving a throughput of 10 Gbps or more and reducing the latency in the radio section to 1 ms or less, various radio technologies are being studied.
[0003] In NR, a network architecture including 5GC (5G Core Network) corresponding to EPC (Evolved Packet Core), which is the core network in the network architecture of LTE (Long Term Evolution), and NG-RAN (Next Generation - Radio Access Network) corresponding to E-UTRAN (Evolved Universal Terrestrial Radio Access Network), which is the RAN (Radio Access Network) in the network architecture of LTE, is being studied (for example, Non-Patent Document 1).
[0004] Also, for example, an architecture in which the Northbound interface between NEF (Network Exposure Function) and AF (Application Function) in a 5G system is configured by CAPIF (Common API Framework) is being studied (for example, Non-Patent Document 2, Non-Patent Document 3, and Non-Patent Document 4).
Prior Art Documents
[0005] [Non-Patent Document 1] 3GPP TS 23.501 V17.6.0(2022-09) [Non-Patent Document 2] 3GPP TS 23.222 V17.7.0(2022-09) [Non-Patent Document 3] 3GPP TS 33.122 V17.0.0(2022-03) [Non-Patent Document 4] 3GPP TR 23.700-95 V1.5.0(2022-09) [Overview of the Initiative] [Problems that the invention aims to solve]
[0006] ID linking technology, which allows for the centralized management of ID information that users previously registered separately on each site, is attracting attention. In recent IT technologies, OpenID(registered trademark) Connect is commonly used for ID linking.
[0007] In conventional technologies using OpenID® Connect, the authorization server (authorization device) may have to return an error when it receives an authentication request containing certain parameters. Therefore, in conventional technologies, for example, when a user migrates between applications via ID federation, the user experience may deteriorate. It should be noted that this issue is not limited to OpenID® Connect but can occur in any ID federation mechanism.
[0008] The present invention has been made in view of the above points, and aims to provide a technology for an authorization device to appropriately process an authentication request that includes specific parameters. [Means for solving the problem]
[0009] According to the disclosed technology, a receiving unit receives an authentication request from an application server that has received access from a terminal, A control unit, when the authentication request includes specific parameters, checks whether specific registration information about the terminal is stored in the network node device of the communication system used by the terminal, and determines whether the terminal is authenticated based on the result of that check. The control unit includes, at a minimum, a transmission unit that sends an authorization code to the application server when it is determined that the terminal is authenticated. An authorization device equipped with the following is provided. [Effects of the Invention]
[0010] According to the disclosed technology, a technology is provided for an authorization device to appropriately process an authentication request that includes specific parameters. [Brief explanation of the drawing]
[0011] [Figure 1] This is a diagram illustrating an example of a communication system. [Figure 2] This diagram illustrates an example of a communication system in a roaming environment. [Figure 3] This figure shows an example of an API call. [Figure 4] This figure shows an example of a communication system in an embodiment of the present invention. [Figure 5] This is a sequence diagram of the first embodiment. [Figure 6] This is a sequence diagram of the first embodiment. [Figure 7] This is a sequence diagram of the first embodiment. [Figure 8] This is a sequence diagram of the second embodiment. [Figure 9] This is a sequence diagram of the third embodiment. [Figure 10] This figure shows an example of the functional configuration of the authorization device 40 in an embodiment of the present invention. [Figure 11]It is a diagram showing an example of the functional configuration of the user information disclosure device 50 in the embodiment of the present invention. [Figure 12] It is a diagram showing an example of the hardware configuration of the device in the embodiment of the present invention. [Figure 13] It is a diagram showing an example of the configuration of the vehicle in the embodiment of the present invention.
Embodiments for Carrying Out the Invention
[0012] Hereinafter, embodiments of the present invention will be described with reference to the drawings. Note that the embodiments described below are examples, and the embodiments to which the present invention is applied are not limited to the following embodiments.
[0013] In the operation of the wireless communication system according to the embodiment of the present invention, existing technologies are appropriately used. The existing technology is, for example, existing LTE or existing NR (5G), but is not limited to existing LTE or existing NR.
[0014] Also, in the present embodiment, as a mechanism for ID linkage, OIDC (OpenID (registered trademark) Connect) is used, but using OIDC is an example, and other mechanisms may be used as the ID linkage mechanism.
[0015] Also, in the embodiment of the present invention, that the radio parameters etc. are "configured" may mean that predetermined values are pre-configured, or that the radio parameters notified from the network node device 30 or the terminal 20 are configured.
[0016] Figure 1 is a diagram illustrating an example of a communication system. As shown in Figure 1, the communication system consists of a terminal 20 (UE) and multiple network node devices. Hereafter, one network node device will be assigned to each function, however, one network node device may implement multiple functions, or multiple network node devices may implement one function. Furthermore, the "connection" described below may be a logical connection or a physical connection.
[0017] The RAN (Radio Access Network) is a network node device having wireless access functionality, which may include a base station, and is connected to the UE, AMF (Access and Mobility Management Function), and UPF (User plane function). The AMF is a network node device that has functions such as terminating the RAN interface, terminating the NAS (Non-Access Stratum), registration management, connection management, reachability management, and mobility management. The UPF is a network node device that interconnects with the DN (Data Network) and has functions such as PDU (Protocol Data Unit) session point to the outside, packet routing and forwarding, and user plane QoS (Quality of Service) handling. The UPF and DN constitute a network slice. In the wireless communication network in the embodiment of the present invention, multiple network slices are constructed.
[0018] AMF is connected to UE, RAN, SMF (Session Management function), NSSF (Network Slice Selection Function), NEF (Network Exposure Function), NRF (Network Repository Function), UDM (Unified Data Management), UDR (Unified Data Repository), AUSF (Authentication Server Function), PCF (Policy Control Function), and AF (Application Function). AMF, SMF, NSSF, NEF, NRF, UDM, UDR, AUSF, PCF, and AF are network node devices that are interconnected via interfaces based on their respective services: Namf, Nsmf, Nnssf, Nnef, Nnrf, Nudm, Nudr, Nausf, Npcf, and Naf.
[0019] SMF is a network node device that has functions such as session management, IP (Internet Protocol) address allocation and management for UEs, DHCP (Dynamic Host Configuration Protocol) functionality, ARP (Address Resolution Protocol) proxy, and roaming functionality. NEF is a network node device that has the function of notifying other NFs (Network Functions) of capabilities and events. NSSF is a network node device that has functions such as selecting the network slice to which the UE connects, determining the allowed NSSAI (Network Slice Selection Assistance Information), determining the NSSAI to be set, and determining the AMF set to which the UE connects. PCF is a network node device that has the function of controlling network policy. AF is a network node device that has the function of controlling application servers. NRF is a network node device that has the function of discovering NF instances that provide services. UDM is a network node device that manages subscriber data and authentication data, etc. Dynamic information according to the connection status of terminal 20 is also stored (managed) in the UDM. UDM is connected to UDR (User Data Repository) which holds data.
[0020] Figure 2 illustrates an example of a communication system in a roaming environment. As shown in Figure 2, the network consists of a UE (User Interface Device) which is terminal 20, and multiple network node devices. SEPP is an opaque proxy that filters control plane messages between PLMNs (Public Land Mobile Networks). vSEPP shown in Figure 2 is the SEPP in the visited network, and hSEPP is the SEPP in the home network.
[0021] As shown in Figure 2, the UE is in a roaming environment connected to the RAN and AMF in the VPLMN (Visited PLMN). The VPLMN and HPLMN (Home PLMN) are connected via vSEPP and hSEPP. The UE can communicate with the HPLMN's UDM, for example, via the VPLMN's AMF.
[0022] The operation in this embodiment may be performed using either the configuration shown in Figure 1 or Figure 2. Furthermore, the operation in this embodiment may be performed using a configuration other than those shown in Figures 1 and 2. In other words, although the authorization device 40, user information disclosure device 50, etc., described later are assumed to be network node devices in 5GS, this assumption is not limited, and the authorization device 40, user information disclosure device 50, etc., may be devices in communication systems other than 5GS.
[0023] In the aforementioned NEF, it is possible to implement an API (Application Programming Interface) that can be called from the AF by applying the CAPIF (Common API Framework) architecture. The CAPIF architecture provides a mechanism to support service API operation, for example, by allowing the API caller (invoker) to discover service APIs provided by the API provider (provider) and enabling communication using those service APIs.
[0024] The application server 60 that calls the API (hereinafter referred to as app server 60) described below may be provided on the AF, and the API provisioning function (AEF) may be provided on the NEF, or it may not be limited to this arrangement; app server 60 and AEF may be provided on any network node device, respectively. Also, app server 60 may be provided on a terminal or a base station. App server 60 may also be referred to as the API caller (invoker).
[0025] Furthermore, the resource owner may be a network node device, terminal 20, base station, or any other device. In this embodiment, it is assumed that terminal 20 is the resource owner.
[0026] Figure 3 shows an example of an API call. The 3GPP® core network opens up APIs to external applications, allowing third-party application servers 60 to call APIs from network node devices.
[0027] As shown in Figure 3, the application calling the API is pre-registered with the CAPIF core device 30 from the application server 60 using the CAPIF-API. The CAPIF core device 30 authenticates and authorizes the application. Also, as shown in Figure 3, the API Exposing Function (also referred to as AEF) 91 opens the service API for the authenticated and authorized application, and the application calling the API can use the functions of the API by calling the API.
[0028] The APF (API Publishing Function) 92 has the function of publishing the API provider's service API information to the CAPIF core device 30. The AMF (API Management Function) 91 has various management functions related to API calls.
[0029] Furthermore, by extending CAPIF, it becomes possible for terminal 20 (resource owner) to authorize API calls to application server 60 via authorization device 40. For example, authorization can be achieved using the OAuth 2.0 mechanism.
[0030] The first, second, and third embodiments are described below. The first embodiment is the basic embodiment. The second and third embodiments are variations of the first embodiment. However, the second and third embodiments may be implemented independently of the first embodiment. Furthermore, the first, second, and third embodiments may be implemented in combination.
[0031] Furthermore, in the following explanation, unless otherwise specified, "user" refers to the entity (typically a person) using the terminal, and "terminal" refers to a device such as a smartphone. However, "terminal" may also be referred to as "user."
[0032] (Regarding the problems of the first embodiment) As mentioned earlier, ID linking technology, which allows for the centralized management of ID information that users have previously registered separately on each site, is attracting attention. In recent IT technologies, OpenID(registered trademark) Connect is commonly used for ID linking.
[0033] However, the 5GS (5G system), which is the communication system intended for use in this embodiment, does not implement either ID linking or OpenID® Connect.
[0034] Instead of introducing ID linking in 5GS, it's also possible to implement ID linking at the application layer. However, in that case, the user information linking that constitutes ID linking tends to only handle static user information.
[0035] On the other hand, by providing ID linkage with 5GS, dynamic user information obtainable from 5GS can also be handled, and as a result, users can receive services that are more tailored to their preferences and status from the application server 60 they log into.
[0036] Since 5GS incorporates OAuth 2.0, the authorization endpoint function of OIDC (OpenID Connect) OP (OpenID Provider) and the token endpoint function of OIDC OP can be included by slightly extending the CAPIF authorization function (authorization device 40) and the CAPIF core function (CAPIF core device 30), respectively. However, 5GS does not have a function corresponding to the user information endpoint function of OIDC OP. Therefore, there is a problem that conventional technology cannot properly perform ID federation based on OIDC.
[0037] (Summary of the first embodiment) In this embodiment, OIDC is introduced into the communication system (5GS is assumed here) so that the communication system can provide ID linking, including the linking of dynamic user information.
[0038] Specifically, the CAPIF authorization function (referred to as authorization device 40) will include the authorization endpoint function of the OIDC OP.
[0039] Furthermore, an interface with the authorization device 40 is provided in the CAPIF core function (referred to as the CAPIF core device 30) to enable the generation of ID tokens. This allows the CAPIF core device 30 to perform the token termination function of the OIDC OP.
[0040] Furthermore, a new user information disclosure device 50 will be introduced in the communication system as a "user information disclosure function" to enable the execution of the OIDC OP's user information termination function.
[0041] In OIDC, user information is transmitted from the OIDC OP to the OIDC RP (Relying Party). In this embodiment, the user information is defined as information that characterizes each user identifier (i.e., for each of the multiple identifiers for a single SUPI (Subscription Permanent Identifier)). However, the user information is not limited to this, and user information independent of the identifier may be used.
[0042] In this embodiment, user information consists of one, more, or all of the following: static information, dynamic information, and a URI for obtaining dynamic information. The following embodiments use user information that includes all three of these elements.
[0043] The user information disclosure device 50 needs to acquire (generate) user information to be disclosed. Any method may be used to acquire user information, but in this embodiment, the UDR (corresponding to the data storage device 70 described later) stores the information necessary for the user information disclosure device 50 to generate user information.
[0044] More specifically, the following information (1) to (3) is stored in the relevant area of the UDR either via offline input or using Nnef_UserInfoProvision.
[0045] (1) Static information (2) Dynamic information to be acquired (information indicating dynamic information) (3) URI to send to the OIDC RP to obtain dynamic information With respect to (2) above, the user information disclosure device 50 can, for example, use SUPI to access the UDM (corresponding to the data management device 80 described later) to obtain information indicating the user's current status (e.g., AMF registration information), and include such information (or a part of such information) as dynamic information in the user information.
[0046] (System Configuration) Figure 4 shows an example of the communication system configuration in the first embodiment. The configuration shown in Figure 4 is basically applicable to the second and third embodiments as well.
[0047] As shown in Figure 4, the communication system in this embodiment includes a terminal 20 (user terminal 20), a CAPIF core device 30, an authorization device 40, a user information disclosure device 50, an application server 60, an information server 65, a data storage device 70, a data management device 80, and an NEF 90. In Figure 4, each device can communicate with other devices connected by at least the lines shown.
[0048] In these embodiments (the first to third embodiments), it is assumed that the data storage device 70 corresponds to a UDR and the data management device 80 corresponds to a UDM, but the invention is not limited to this. Furthermore, the "data storage device 70 and data management device 80" may be composed of a single device (which may also be called the data storage device). Also, the "CAPIF core device 30 and authorization device 40" may be a single device. This single device may be called the core device, the authorization device, or the network node device.
[0049] Furthermore, in this embodiment, it is assumed that terminal 20 is equipped with a browser and the device communicating with terminal 20 is equipped with a web server function, and terminal 20 sends information to the other device as an HTTP request and receives information from the other device as an HTTP response. However, this assumption is just one example and is not limited to this assumption.
[0050] Furthermore, in the following explanation, communication between the application server 60 and the authorization device 40 is performed via redirection through a terminal (browser), but this is just one example. Direct communication between the application server 60 and the authorization device 40 is also possible.
[0051] (First embodiment: Dynamic information setting) Referring to Figure 5, an example sequence for setting the dynamic information described above will be explained. Here, as an example, an example of setting via NEF90 is shown.
[0052] The data storage device 70 is assumed to store "SUPI=a, [Identifier: User Information]=[a1: Phone Number, Email Address]" based on the offline settings at the time of the user's contract. This indicates that the SUPI of the user's terminal 20 is a, the identifier a1 corresponds to SUPI=a, and the user information corresponding to a1 is "Phone Number, Email Address".
[0053] In step 11 (S11), terminal 20 sends a user information addition request to NEF90. The user information addition request is, for example, an Nnef_UserInfoProvision request. The user information addition request here is assumed to include the following information.
[0054] "GPSI=A, Additional Information([Identifier:User Information]=[a2: Phone Number, Email Address, "In-Use Access Confirmation", "In-Use RAT Confirmation", Access Confirmation URI, RAT Confirmation URI])" The above information is for adding the user information with identifier a2.
[0055] NEF90 queries the data management device 80 (S12) to obtain SUPI=a corresponding to GPSI=A (S13), thereby converting GPSI=A to SUPI=a.
[0056] In S14, NEF90 writes the above additional information to the data SUPI=a in the data storage device 70.
[0057] (First Embodiment: OIDC Procedure) The OIDC procedure in the first embodiment will be described with reference to the flowcharts in Figures 6 and 7.
[0058] In S101, terminal 20 accesses application server 60 (=RP) and makes a login request. Since application server 60 cannot directly handle this login, the subsequent OIDC procedure is executed.
[0059] In steps S102-S103, the application server 60 sends an authentication request to the authorization device 40 via the browser of the terminal 20 (by redirection).
[0060] In S104, the authorization device 40 authenticates terminal 20 (or the user) via the browser on terminal 20 or through a mechanism within 5GS, and obtains authorization from the user for "application server 60 to access user information". In this process, for example, an input screen is displayed on terminal 20 via the browser, and the user enters information from the input screen indicating that they authorize "application server 60 to access user information". Information indicating authorization (authorization permission information) is sent to the authorization device 40. For example, at this time, the user enters user identifier = a2 from the input screen. That is, in S104, the authorization device 40 obtains user identifier = a2.
[0061] The above description of "authorization" is merely an example. "Authorization" could be user authorization for "the application server 60 to use a specific API," or it could be authorization for other specific processes performed by the application server 60. The content of "authorization" is the same in the second and third embodiments.
[0062] In steps S105-S106, the authorization device 40 sends an authorization code to the application server 60 via the browser in the terminal 20, indicating that the user has authorized access to the user information.
[0063] In S107, the application server 60 presents (sends) an authorization code to the CAPIF core device 30. In S108-S109, the CAPIF core device 30 accesses the authorization device 40 and obtains information regarding authentication (e.g., authentication time and authentication method). In S109, the authorization device 40 may notify the CAPIF core device 30 of the user identifier = a2.
[0064] In S110, the CAPIF core device 30 generates an ID token based on the information obtained from the authorization device 40. The CAPIF core device 30 also generates an access token.
[0065] In S111 of Figure 7, the CAPIF core device 30 sends an ID token and an access token to the application server 60. In S112, the application server 60 sends a user information request to the user information disclosure device 50. This user information request includes the user identifier = a2 and the access token. The application server 60 may obtain the user identifier = a2 in S105 and S106, or in S111, or at any other time. For example, the ID token in S111 may contain the user identifier = a2.
[0066] In S113-S114, the user information disclosure device 50 accesses the data storage device 70, obtains information corresponding to user identifier = a2, and confirms that SUPI = a corresponds to user identifier = a2.
[0067] The user information disclosure device 50 detects that the information contains "In-Use Access Confirmation" and "In-Use RAT Confirmation". Therefore, in S115-S116, it queries the data management device 80 using SUPI=a and obtains "3GPP access" and "NR" as the in-use access method and RAT for the terminal 20 (user).
[0068] In S117, the user information disclosure device 50 generates user information including "telephone number, email address, 'currently using access = 3GPP access', 'currently using RAT = NR', access confirmation URI, and RAT confirmation URI," and transmits this user information to the application server 60.
[0069] In S118, the application server 60, based on the ID token received from the CAPIF core device 30, grants permission for user identifier = a2 to log in, and provides services to the user (terminal 20) based on the user information.
[0070] Here, both the access confirmation URI and the RAT confirmation URI are assumed to be URIs on the information server 65. Note that the information server 65 may be the data management device 80, in which case the access confirmation URI and the RAT confirmation URI may be URIs disclosed by the NEF 90. In S119, the application server 60 monitors the access confirmation URI and the RAT confirmation URI (i.e., the information server 65) and prepares for changes in the state of the terminal 20 corresponding to the user identifier = a2.
[0071] The technology according to the first embodiment described above enables the implementation of OIDC in 5GS. Furthermore, since dynamic information can be handled as user information in OIDC, services can be flexibly adapted to the status of the terminal 20.
[0072] In the above example, information on active access and active RAT were obtained as dynamic information from the communication system, but these are just examples and are not limited to these. For example, it is also possible to obtain the location information of terminal 20 as dynamic information by utilizing the positioning mechanism in the communication system.
[0073] (Issues of the second embodiment) Next, we will describe the second embodiment. First, we will explain the challenges of the second embodiment. In OIDC, when the OP's authorization endpoint authenticates the end user, the operation is finely controlled by the prompt parameter.
[0074] In other words, the OIDC specification (OpenID Connect Core 1.0 incorporating errata set 1) states the following: The authorization server below corresponds to authorization device 40. Also, "none" can be replaced with "none".
[0075] The authorization server must attempt end-user authentication in the following cases: • The end user has not yet been authenticated.
[0076] • The authentication request includes a prompt parameter with the value "login". In this case, even if the end user is already authenticated, the authorization server must re-authenticate the end user.
[0077] The authorization server must not interact with end users in the following cases:
[0078] • The authentication request includes a prompt parameter with the value "None". In this case, if the end user is not yet authenticated or cannot be authenticated silently, the authorization server must return an error. In the authorization device 40, properly handling cases where "the authentication request includes a prompt parameter with the value 'none'" is important for users to experience a smooth transition between applications.
[0079] The second embodiment primarily describes the processing of cases where "the authentication request includes a prompt parameter with a value of "none". In the following, an authentication request that includes a prompt parameter with a value of "none" may be referred to as a "no-prompt authentication request".
[0080] (Summary of the second embodiment) In the second embodiment, when the authorization device 40 receives an authentication request without prompting, it verifies that the terminal 20 (or the user, or both the terminal 20 and the user) is authenticated based on the 5GS authentication result / FIDO authentication result. Furthermore, the authorization device 40 verifies whether automatic login is permitted for the terminal 20 (user). If these verifications are successful, the authorization device 40 issues an authorization code to the application server 60.
[0081] In the second embodiment, the terminal 20 registers information about its terminal authenticator capabilities (such as FIDO) with the data management device 80 during the registration procedure for registering with the communication system (in this case, 5GS). FIDO stands for Fast Identity Online. FIDO authentication achieves high security by performing user authentication (such as biometric authentication) in the terminal 20's local environment and authentication using a public key authentication method.
[0082] In the second embodiment, if the authentication request includes a prompt parameter with the value "none", and the user (terminal 20) has not yet been authenticated (at the application layer), the authorization device 40 performs the following processing at the authentication stage and the login authorization stage. Note that the condition for the user (terminal 20) not yet being authenticated (at the application layer) may be omitted.
[0083] [Authentication stage] The authorization device 40 first checks with the data management device 80 to confirm the existence of AMF registration information. The presence of AMF registration information for terminal 20 in the data management device 80 means that terminal 20 has been authenticated in the communication system (authentication was successful).
[0084] Subsequently, the authorization device 40 performs the following (i) and (ii) to confirm the result of the authentication (e.g., biometric authentication) performed between the user and the terminal 20.
[0085] (i) When it is detected that terminal 20 has terminal authenticator capability based on the terminal authenticator capability information in the AMF registration information, the system accesses the FIDO server and determines that terminal 20 (and the user) is authenticated if stored information indicating that it is authenticated is found there.
[0086] (ii) If there is no information on terminal authenticator capability in the AMF registration information, or if it is detected from such information that terminal 20 does not have terminal authenticator capability, it is determined that terminal 20 is authenticated.
[0087] [Login authorization stage] The authorization device 40 confirms that the subscriber information in the data management device 80 contains information indicating that automatic login is permitted.
[0088] The authorization device 40 sends an authorization code to the application server 60 without re-authentication at the application layer after the verification at the authentication stage and the login authorization stage described above. Alternatively, the verification at the login authorization stage may be omitted.
[0089] Furthermore, with respect to (ii) above, if terminal 20 does not have terminal authentication capabilities, the authorization device 40 may determine that terminal 20 (or user) is not authenticated and refrain from issuing an authorization code.
[0090] (Processing procedure of the second embodiment) <Device Registration> Terminal 20 includes information about its terminal authenticator capability in its registration request during its registration procedure. AMF includes this terminal authenticator capability information when registering terminal 20 with the data management device 80. In other words, the terminal registration process stores information about terminal 20's terminal authenticator capability in the data management device 80. It is assumed that if terminal 20 has terminal authenticator capability, FIDO authentication is possible on terminal 20; if it does not, FIDO authentication cannot be performed on terminal 20.
[0091] <OIDC Procedure> Next, the OIDC procedure will be described with reference to the sequence diagram of FIG. 8. In the following sequence, the FIDO server 100 is used. The FIDO server 100 may be a network node device in the communication system or a device outside the communication system. The FIDO server 100 may be called an authentication server.
[0092] In S201, the terminal 20 accesses the application server 60 (= RP) and makes a login request. Since the application server 60 cannot directly handle the login, the subsequent OIDC procedure is executed.
[0093] In S202 - S203, the application server 60 sends an authentication request to the authorization device 40 via the browser of the terminal 20. The authentication request includes the following parameters.
[0094] (a) client_id parameter: It has the identifier of the application server 60 as its value.
[0095] (i) prompt parameter: It has "none" as its value.
[0096] (u) login_hint parameter: It has the user email address as its value.
[0097] Note that the above "user email address" is used as the identification information of the terminal 20 (or the user) as follows. The "user email address" is an example, and information other than the "user email address" may be used.
[0098] ,In S204 - S205, the authorization device 40 queries the data storage device 70 using the user email address to obtain SUPI = b.
[0099] In steps S206-S207, the authorization device 40 obtains AMF registration information (specific registration information) corresponding to SUPI=b from the data management device 80 and confirms that the AMF registration information contains information about the terminal authenticator capability of terminal 20. If there is no AMF registration information corresponding to SUPI=b, for example, an error is returned to the application server 60.
[0100] In steps S208-S209, the authorization device 40 accesses the FIDO server 100 and obtains information indicating that authenticated stored information exists for the terminal 20. If authenticated stored information does not exist, it returns an error to the application server 60, for example.
[0101] In S210-S211, the authorization device 40 obtains CAPIF usage setting information for subscribers with SUPI=b from the data management device 80, and confirms that the identifier of the application server 60 is included in the "client_id parameter for which automatic login is permitted" in the said CAPIF usage setting information. In other words, it confirms that automatic login to the application server 60 is permitted.
[0102] In S212-S213, the authorization device 40 sends an authorization code to the application server 60 without performing authentication at the application layer. Authentication at the application layer refers to, for example, the authentication and authorization process in S104 described in the first embodiment. The subsequent processing is the same as the processing from S107 in the first embodiment.
[0103] According to the second embodiment described above, when an authentication request includes a prompt parameter with the value "none", it is possible to quickly issue an authorization code without returning an error.
[0104] (Issues related to the third embodiment) Next, I will describe the third embodiment. First, I will explain the challenges related to the third embodiment. In 3GPP (registered trademark), it is being considered that avatars that behave in accordance with human will can proactively participate in communication.
[0105] Avatars do not act completely freely, but rather obtain permission from humans as needed. The mechanism for avatars to obtain authorization from humans for their actions is provided by OAuth 2.0 for API access. However, conventional technologies do not have a mechanism for logging into other applications or providing ID information. Furthermore, in OIDC, in conventional technologies, the person granting permission to the avatar cannot be involved in the related flow.
[0106] (Summary of the third embodiment) To solve the above problem, in the third embodiment, the authorization device 40 sends an authorization code to the application server 60 after obtaining confirmation from both the avatar and the person.
[0107] Here, we will refer to the person as "Terminal 1 20A" and the avatar as "Terminal 2 20B". "Terminal 1 20A" is assumed to be a physical terminal such as a smartphone used by the user (person). "Terminal 2 20B" may be a physical terminal used by the avatar (software), or it may be software (a virtual terminal) on a computer (which may be a server or a terminal).
[0108] Furthermore, the user of the second terminal 20B in the third embodiment is not limited to an avatar. Both the "first terminal 20A" and the "second terminal 20B" may be used by human users. For example, the "first terminal 20A" may be used by a parent and the "second terminal 20B" by a child.
[0109] In the third embodiment, the first terminal 20A subscribes to Web push notifications from the authorization device 40 in advance. In other words, the authentication request for the second terminal 20B triggers the first terminal 20A to receive Web push notifications from the authorization device 40.
[0110] When the authorization device 40 receives an authentication request from the application server 60 via the second terminal 20B, it sends an authentication authorization request (which may also be called an authentication request or an authorization request) to both the second terminal 20B and the first terminal 20A. Note that the authorization device 40 sends the authentication authorization request to the first terminal 20A by means of a Web push notification.
[0111] The authorization device 40 authenticates both the second terminal 20B and the first terminal 20A. When it obtains authorization from both, it sends an authorization code for the access of the second terminal 20B to the application server 60.
[0112] (Processing procedure of the third embodiment) Hereinafter, the processing procedure in the third embodiment will be described with reference to the sequence diagram in FIG. 9.
[0113] <Web push notification subscription> In S300, the first terminal 20A notifies the authorization device 40 that it subscribes to a Web push notification regarding the authentication authorization of the second terminal 20B. At this time, the first terminal 20A notifies the authorization device 40 that the SUPI = c of the target second terminal 20B.
[0114] <OIDC procedure> Subsequently, the OIDC procedure will be described with reference to the sequence diagram in FIG. 9. In S301, the second terminal 20B accesses the application server 60 (= RP) and makes a login request. Since the application server 60 cannot directly handle the login, the subsequent OIDC procedure is executed.
[0115] In S302 to S303, the application server 60 sends an authentication request to the authorization device 40 via the browser of the second terminal 20B. The authentication request includes the following parameters.
[0116] · login_hint parameter: It has the email address of the second terminal 20B as its value. <s
[0117] The above "email address" will be used as identification information for the second terminal 20B, as described below. The "email address" is an example, and other information may be used.
[0118] In S304-S305, the authorization device 40 queries the data storage device 70 using the email address of the second terminal 20B to obtain SUPI=c. In S306, the authorization device 40 confirms that SUPI=c corresponds to the Web push notification requested by the first terminal 20A in S300.
[0119] In S307, the authorization device 40 performs authentication authorization processing with the second terminal 20B. That is, the authorization device 40 sends an authentication authorization request to the second terminal 20B. The authentication authorization processing based on the authentication authorization request is the same as the authentication authorization processing between terminal 20 and the authorization device 40 in the first embodiment.
[0120] In S308, the authorization device 40 sends an authentication authorization request to the first terminal 20A via Web push. The processing based on this authentication authorization request is the same as the authentication authorization processing between the terminal 20 and the authorization device 40 in the first embodiment.
[0121] In S309 and S310, the authorization device 40 obtains confirmation of authentication and authorization (information indicating that authorization has been obtained) from both the first terminal 20A and the second terminal 20B.
[0122] In S311, the authorization device 40, having obtained authorization from both the first terminal 20A and the second terminal 20B, decides to send an authorization code to the application server 60 and sends it. Specifically, the authorization device 40 returns an HTTP response to the second terminal 20B containing the authorization code and the RP's redirection endpoint. It returns an empty HTTP response to the first terminal 20A.
[0123] Thereafter, the OIDC procedure for the second terminal 20B is continued in the same manner as the processing from S106 onwards in the first embodiment.
[0124] In addition, in steps S309 to S310, if the authorization device 40 fails to obtain confirmation of authentication authorization from at least one of the first terminal 20A and the second terminal 20B, the authorization device 40 will not send an authorization code to the application server 60.
[0125] Furthermore, in the third embodiment, "authorization" is, as in the first embodiment, for example, authorizing the application server 60 to access the user information of the user (e.g., avatar) of the second terminal 20B. However, it is not limited to this, and "authorization" may also be authorization for processes other than authorizing access to user information.
[0126] According to the third embodiment described above, in the mechanism for ID linking, one terminal can be involved in the operation of other terminals. Therefore, for example, it is possible to prevent avatars from acting freely during the OIDC procedure.
[0127] (Device configuration) Next, we will describe an example of the functional configuration of the authorization device 40 and the user information disclosure device 50 that perform the processes and operations described above.
[0128] <Authorization device 40> Figure 10 shows an example of the functional configuration of the authorization device 40. As shown in Figure 10, the authorization device 40 has a transmitting unit 110, a receiving unit 120, a setting unit 130, and a control unit 140. The functional configuration shown in Figure 10 is merely an example. Any functional classification and functional unit names are acceptable as long as they enable the operation according to the embodiment of the present invention. Note that each network node device shown in Figure 4 also has the configuration shown in Figure 10.
[0129] The transmitting unit 110 includes the function of generating information to be transmitted to the terminal 20 or other network node devices and transmitting such information by wire or wireless. The receiving unit 120 receives various types of information transmitted from the terminal 20 or other network node devices.
[0130] The setting unit 130 stores various setting information in a storage device and reads it from the storage device as needed.
[0131] The control unit 140 controls the entire device. The functions related to information transmission in the control unit 140 may be included in the transmission unit 110, and the functions related to information reception in the control unit 140 may be included in the reception unit 120.
[0132] <User Information Disclosure Device 50> Figure 11 is a diagram showing an example of the functional configuration of the user information disclosure device 50. As shown in Figure 11, the user information disclosure device 50 has a transmitting unit 210, a receiving unit 220, a setting unit 230, and a control unit 240. The functional configuration shown in Figure 11 is merely an example. Any functional classification and functional unit names are acceptable as long as they enable the operation according to the embodiment of the present invention.
[0133] The transmitting unit 210 includes the function of generating information to be transmitted to the terminal 20 or other network node devices and transmitting such information by wire or wireless. The receiving unit 220 receives various types of information transmitted from the terminal 20 or other network node devices.
[0134] The setting unit 230 stores various setting information in a storage device and reads it from the storage device as needed.
[0135] The control unit 240 controls the entire device. The functions related to information transmission in the control unit 240 may be included in the transmission unit 210, and the functions related to information reception in the control unit 240 may be included in the reception unit 220.
[0136] This embodiment discloses at least the following appendices 1 to 3.
[0137] <Note 1> (Additional note 1) A receiving unit that receives a user information request, including a user identifier, from an application server authorized to perform specific processing, A control unit that acquires information corresponding to the user identifier from a data storage device in a communication system, A transmission unit that transmits user information created based on the aforementioned information to the application server. A user information disclosure device equipped with the following features. (Additional note 2) The user information transmitted to the application server includes information about the access destination for monitoring the status of the terminal corresponding to the user identifier. The user information disclosure device described in Appendix 1. (Additional note 3) The control unit acquires the dynamic information from the data management device that manages the dynamic information of the terminal, and includes the dynamic information in the user information. User information disclosure device as described in Appendix 1 or 2. (Additional note 4) When the control unit detects that specific information exists among the information acquired from the data storage device, it accesses the data management device to acquire the dynamic information. The user information disclosure device described in Appendix 3. (Additional note 5) A user information disclosure device described in any one of the appendices 1 to 4, and an authorization device that performs processing for authorizing the application server for the specific processing. A communication system equipped with [the following features]. (Additional note 6) The steps include receiving a user information request, including a user identifier, from an application server authorized to perform specific processing, A step of obtaining information corresponding to the user identifier from a data storage device in a communication system, The steps include: sending user information created based on the aforementioned information to the application server; A user information disclosure method performed by a user information disclosure device, comprising the above.
[0138] According to any of the appendices 1 through 6, a technology is provided that enables the provision of dynamic information to the application server within the mechanism for ID linking. According to appendice 2, the application server can continue to obtain dynamic user information even after the user has logged in. According to appendice 3, the application server can obtain dynamic user information when the user logs in. According to appendice 4, dynamic information can be obtained only when necessary.
[0139] <Note 2> (Additional note 1) A receiving unit that receives an authentication request from an application server that has received access from a terminal, A control unit, when the authentication request includes specific parameters, checks whether specific registration information about the terminal is stored in the network node device of the communication system used by the terminal, and determines whether the terminal is authenticated based on the result of that check. The control unit includes, at a minimum, a transmission unit that sends an authorization code to the application server when it is determined that the terminal is authenticated. An authorization device equipped with the following features. (Additional note 2) If the network node device has the specific registration information stored therein, the control unit will Based on the aforementioned specific registration information, it is confirmed whether the terminal has terminal authentication capabilities. The system determines that a terminal is authenticated if the terminal has the terminal authentication capability and the authentication server contains stored information indicating that the terminal is authenticated. Approved devices as described in Appendix 1. (Additional note 3) The control unit checks whether automatic login is permitted based on the subscriber information of the terminal user stored in the network node device. If the control unit determines that the terminal is authenticated and confirms that automatic login is permitted, the transmission unit transmits the authorization code to the application server. Approved devices as described in Appendix 1 or 2. (Additional note 4) The aforementioned specific parameter is a prompt parameter whose value is none. An authorized device as described in any one of the supplementary items 1 through 3. (Additional note 5) An authorization device described in any one of the appendices 1 to 4, and a user information disclosure device that transmits user information to the application server that has received the authorization code from the authorization device. A communication system equipped with [the following features]. (Additional note 6) The application server receives an authentication request from the terminal, and If the authentication request includes specific parameters, the step of checking whether specific registration information about the terminal is stored in the network node device of the communication system used by the terminal, and determining whether the terminal is authenticated based on the result of that check, At a minimum, the steps include sending an authorization code to the application server when it is determined that the terminal is authenticated. An authorization method performed by an authorization device, comprising the following features.
[0140] Any of the appendices 1 to 6 provides a technology for an authorization device to appropriately process an authentication request that includes specific parameters. According to appendice 2, appropriate processing can be performed depending on whether or not the device has terminal authenticator capabilities. According to appendice 3, appropriate processing can be performed depending on whether or not automatic login is permitted. According to appendice 4, specific parameters can be determined.
[0141] <Note 3> (Additional note 1) A receiving unit that, after receiving a notification request containing identification information from the first terminal, receives an authentication request concerning the second terminal from an application server accessed by the second terminal, A transmission unit that transmits an authentication authorization request to the first terminal and an authentication authorization request to the second terminal based on the aforementioned notification request, A control unit that, upon obtaining authorization from both the first terminal and the second terminal, decides to send an authorization code to the application server indicating that a specific process has been authorized. An authorization device equipped with the following features. (Additional note 2) The control unit obtains identification information of the second terminal from the network node device based on the parameters included in the authentication request, and determines that the notification request is a notification request relating to the second terminal based on the identification information. Approved devices as described in Appendix 1. (Additional note 3) The notification request is a request for a web push notification, and the transmission unit transmits the authentication authorization request to the first terminal via web push notification. Approved devices as described in Appendix 1 or 2. (Additional note 4) An authorization device described in any one of the appendices 1 to 3, and a user information disclosure device that transmits user information to the application server that has received the authorization code from the authorization device. A communication system equipped with [the following features]. (Additional note 5) The steps include: receiving a notification request containing identification information from the first terminal, and then receiving an authentication request regarding the second terminal from an application server accessed by the second terminal; The steps include sending an authentication authorization request to the first terminal and an authentication authorization request to the second terminal based on the aforementioned notification request, The steps include: If authorization is obtained from both the first terminal and the second terminal, deciding to send an authorization code to the application server indicating that a specific process has been authorized; An authorization method performed by an authorization device, comprising the following features.
[0142] According to any of the appendices 1 to 5, a technology is provided that allows one device to be involved in the operation of other devices within the mechanism for ID linking. According to appendice 2, the processing of notification requests can be carried out appropriately. According to appendice 3, rapid notification is possible by using web push notifications.
[0143] (Hardware configuration) The block diagrams (Figures 10-11) used in the description of the above embodiments show functional units. These functional blocks (components) are realized by any combination of at least one of hardware and software. Furthermore, the method of realizing each functional block is not particularly limited. That is, each functional block may be realized using one device that is physically or logically coupled, or it may be realized using two or more physically or logically separated devices that are directly or indirectly connected (for example, using wired or wireless connections). A functional block may be realized by combining the above one device or the above multiple devices with software.
[0144] Functions include, but are not limited to, judgment, decision, judgment, calculation, calculation, processing, derivation, investigation, exploration, confirmation, reception, transmission, output, access, resolution, selection, selection, establishment, comparison, assumption, expectation, assumption, broadcasting, notifying, communicating, forwarding, configuring, reconfiguring, allocating (mapping), and assigning. For example, a functional block (configuration part) that enables transmission is called a transmitting unit or transmitter. As mentioned above, the method of implementation is not particularly limited.
[0145] For example, the base station 10, terminal 20, etc. in one embodiment of the present disclosure may function as a computer that processes the wireless communication method of the present disclosure. Figure 12 is a diagram showing an example of the hardware configuration of the authorization device 40 and the user information disclosure device 50 according to one embodiment of the present disclosure. The authorization device 40 and the user information disclosure device 50 described above may be physically configured as a computer device including a processor 1001, a storage device 1002, an auxiliary storage device 1003, a communication device 1004, an input device 1005, an output device 1006, a bus 1007, etc. Network node devices other than the authorization device 40 and the user information disclosure device 50 also have the configuration shown in Figure 12.
[0146] In the following explanation, the term "device" can be replaced with "circuit," "device," "unit," etc. The hardware configuration of the base station 10 and terminal 20 may include one or more of the devices shown in the figure, or it may be configured without some of the devices.
[0147] Each function in the authorization device 40 and the user information disclosure device 50 is realized by loading predetermined software (programs) onto hardware such as the processor 1001 and the storage device 1002, which causes the processor 1001 to perform calculations, control communication by the communication device 1004, and control at least one of the reading and writing of data in the storage device 1002 and the auxiliary storage device 1003.
[0148] The processor 1001 controls the entire computer, for example, by running an operating system. The processor 1001 may consist of a central processing unit (CPU) that includes interfaces with peripheral devices, control devices, arithmetic units, registers, etc. For example, the control unit 140, control unit 240, etc., described above may be implemented by the processor 1001.
[0149] Furthermore, the processor 1001 reads programs (program code), software modules, or data, etc., from at least one of the auxiliary storage device 1003 and the communication device 1004 into the storage device 1002, and executes various processes accordingly. The program used is one that causes the computer to execute at least a part of the operations described in the above embodiment. For example, the control unit 140 of the authorization device 40 shown in Figure 10 may be implemented by a control program stored in the storage device 1002 and operated by the processor 1001. Also, for example, the control unit 240 of the user information disclosure device 50 shown in Figure 11 may be implemented by a control program stored in the storage device 1002 and operated by the processor 1001. Although the above-described processes have been explained as being executed by one processor 1001, they may be executed simultaneously or sequentially by two or more processors 1001. The processor 1001 may be implemented by one or more chips. The program may be transmitted from a network via a telecommunications line.
[0150] The storage device 1002 is a computer-readable recording medium and may consist of at least one of the following: ROM (Read Only Memory), EPROM (Erasable Programmable ROM), EEPROM (Electrically Erasable Programmable ROM), RAM (Random Access Memory), etc. The storage device 1002 may also be called a register, cache, main memory, etc. The storage device 1002 can store executable programs (program code), software modules, etc., for implementing a communication method according to one embodiment of this disclosure.
[0151] The auxiliary storage device 1003 is a computer-readable recording medium and may consist of at least one of the following: an optical disc such as a CD-ROM (Compact Disc ROM), a hard disk drive, a flexible disk, a magneto-optical disk (e.g., a compact disc, a digital multipurpose disc, a Blu-ray® disc), a smart card, flash memory (e.g., a card, a stick, a key drive), a floppy® disk, a magnetic strip, etc. The above-mentioned storage medium may also be a database, server, or other suitable medium that includes at least one of the storage device 1002 and the auxiliary storage device 1003.
[0152] The communication device 1004 is hardware (transmitting / receiving device) for communicating between computers via at least one of a wired network and a wireless network, and is also referred to as a network device, network controller, network card, communication module, etc. The communication device 1004 may be configured to include high-frequency switches, duplexers, filters, frequency synthesizers, etc., in order to implement at least one of frequency division duplex (FDD) and time division duplex (TDD). For example, the transmitting and receiving antennas, amplifier section, transmitting and receiving section, transmission path interface, etc., may be implemented by the communication device 1004. The transmitting and receiving section may be implemented in a physically or logically separated manner, with a transmitting section and a receiving section.
[0153] The input device 1005 is an input device that accepts input from an external source (e.g., a keyboard, mouse, microphone, switch, button, sensor, etc.). The output device 1006 is an output device that outputs to an external source (e.g., a display, speaker, LED lamp, etc.). The input device 1005 and the output device 1006 may be configured as an integrated unit (e.g., a touch panel).
[0154] Furthermore, each device, such as the processor 1001 and the storage device 1002, is connected by a bus 1007 for communicating information. The bus 1007 may be configured using a single bus, or different buses may be configured for each device.
[0155] Furthermore, the authorization device 40 and the user information disclosure device 50 may be configured to include hardware such as a microprocessor, a digital signal processor (DSP), an ASIC (Application Specific Integrated Circuit), a PLD (Programmable Logic Device), or an FPGA (Field Programmable Gate Array), and some or all of each functional block may be realized by such hardware. For example, the processor 1001 may be implemented using at least one of these hardware components.
[0156] Furthermore, the authorization device 40 or user information disclosure device 50 may be provided in the vehicle 2001. Figure 13 shows an example of the configuration of the vehicle 2001. As shown in Figure 13, the vehicle 2001 includes a drive unit 2002, a steering unit 2003, an accelerator pedal 2004, a brake pedal 2005, a shift lever 2006, front wheels 2007, rear wheels 2008, an axle 2009, an electronic control unit 2010, various sensors 2021 to 2029, an information service unit 2012, and a communication module 2013. The authorization device 40 or user information disclosure device 50 described in each aspect / embodiment of this disclosure may be applied to a communication device mounted on the vehicle 2001, for example, to the communication module 2013.
[0157] The drive unit 2002 consists of, for example, an engine, a motor, or a hybrid of an engine and a motor. The steering unit 2003 includes at least a steering wheel (also called a handle) and is configured to steer at least one of the front wheels and the rear wheels based on the operation of the steering wheel, which is operated by the user.
[0158] The electronic control unit 2010 consists of a microprocessor 2031, memory (ROM, RAM) 2032, and communication ports (IO ports) 2033. Signals from various sensors 2021 to 2029 installed in the vehicle 2001 are input to the electronic control unit 2010. The electronic control unit 2010 may also be called an ECU (Electronic Control Unit).
[0159] Signals from various sensors 2021-2029 include current signals from current sensor 2021 which senses motor current, front and rear wheel rotation speed signals obtained by rotation speed sensor 2022, front and rear wheel air pressure signals obtained by air pressure sensor 2023, vehicle speed signals obtained by vehicle speed sensor 2024, acceleration signals obtained by acceleration sensor 2025, accelerator pedal depression signals obtained by accelerator pedal sensor 2029, brake pedal depression signals obtained by brake pedal sensor 2026, shift lever operation signals obtained by shift lever sensor 2027, and detection signals obtained by object detection sensor 2028 for detecting obstacles, vehicles, pedestrians, etc.
[0160] The Information Services Unit 2012 consists of various devices for providing (outputting) various types of information such as driving information, traffic information, and entertainment information, including a car navigation system, audio system, speakers, television, and radio, and one or more ECUs that control these devices. The Information Services Unit 2012 uses information acquired from external devices via a communication module 2013, etc., to provide various multimedia information and multimedia services to the occupants of the vehicle 2001. The Information Services Unit 2012 may include input devices that accept input from the outside (e.g., keyboard, mouse, microphone, switch, button, sensor, touch panel, etc.) and output devices that perform output to the outside (e.g., display, speaker, LED lamp, touch panel, etc.).
[0161] The driver assistance system unit 2030 consists of various devices that provide functions to prevent accidents or reduce the driver's workload, such as millimeter-wave radar, LiDAR (Light Detection and Ranging), cameras, positioning locators (e.g., GNSS), map information (e.g., high-definition (HD) maps, autonomous vehicle (AV) maps, etc.), gyro systems (e.g., IMU (Inertial Measurement Unit), INS (Inertial Navigation System), etc.), AI (Artificial Intelligence) chips, and AI processors, as well as one or more ECUs that control these devices. The driver assistance system unit 2030 also sends and receives various information via the communication module 2013 to realize driver assistance functions or autonomous driving functions.
[0162] The communication module 2013 can communicate with the microprocessor 2031 and components of the vehicle 2001 via its communication port. For example, the communication module 2013 sends and receives data via its communication port 2033 to the drive unit 2002, steering unit 2003, accelerator pedal 2004, brake pedal 2005, shift lever 2006, front wheels 2007, rear wheels 2008, axle 2009, the microprocessor 2031 and memory (ROM, RAM) 2032 in the electronic control unit 2010, and sensors 2021-29 provided in the vehicle 2001.
[0163] The communication module 2013 is a communication device that can be controlled by the microprocessor 2031 of the electronic control unit 2010 and can communicate with external devices. For example, it can send and receive various types of information to and from external devices via wireless communication. The communication module 2013 may be located either inside or outside the electronic control unit 2010. The external device may be, for example, a base station or a mobile station.
[0164] The communication module 2013 may transmit at least one of the following to an external device via wireless communication: signals from the various sensors 2021-2028 input to the electronic control unit 2010, information obtained based on said signals, and information based on input from an external source (user) obtained via the information service unit 2012. The electronic control unit 2010, the various sensors 2021-2028, the information service unit 2012, etc., may also be called input units that accept input. For example, the PUSCH transmitted by the communication module 2013 may include information based on the above input.
[0165] The communication module 2013 receives various information (traffic information, signal information, inter-vehicle information, etc.) transmitted from an external device and displays it on the information service unit 2012 provided in the vehicle 2001. The information service unit 2012 may also be called an output unit, which outputs information (for example, outputs information to devices such as displays and speakers based on the PDSCH (or data / information decoded from the PDSCH) received by the communication module 2013). The communication module 2013 also stores the various information received from the external device in memory 2032, which is available to the microprocessor 2031. Based on the information stored in memory 2032, the microprocessor 2031 may control the drive unit 2002, steering unit 2003, accelerator pedal 2004, brake pedal 2005, shift lever 2006, front wheels 2007, rear wheels 2008, axles 2009, sensors 2021-2029, etc., provided in the vehicle 2001.
[0166] (Supplement to the embodiment) While embodiments of the present invention have been described above, the disclosed invention is not limited to such embodiments, and those skilled in the art will understand various modifications, alterations, alternatives, substitutions, etc. Specific numerical examples have been used to facilitate understanding of the invention, but unless otherwise specified, these numerical values are merely examples, and any appropriate values may be used. The division of items in the above description is not essential to the present invention, and matters described in two or more items may be combined as needed, and matters described in one item may be applied to matters described in another item (as long as they do not contradict each other). The boundaries of functional units or processing units in the functional block diagram do not necessarily correspond to the boundaries of physical parts. The operation of multiple functional units may be physically performed by one part, or the operation of one functional unit may be physically performed by multiple parts. Regarding the processing procedures described in the embodiments, the order of processing may be changed as long as it does not contradict each other. For the convenience of explaining the processing, the authorization device 40 and the user information disclosure device 50 have been described using functional block diagrams, but such devices may be implemented in hardware, software, or a combination thereof. The software operated by the processor of the base station 10 according to an embodiment of the present invention and the software operated by the processor of the terminal 20 according to an embodiment of the present invention may be stored in random access memory (RAM), flash memory, read-only memory (ROM), EPROM, EEPROM, registers, hard disk (HDD), removable disk, CD-ROM, database, server, or any other suitable storage medium.
[0167] Furthermore, the notification of information is not limited to the embodiments / models described herein and may be carried out by other methods. For example, the notification of information may be carried out by physical layer signaling (e.g., DCI (Downlink Control Information), UCI (Uplink Control Information)), upper layer signaling (e.g., RRC (Radio Resource Control) signaling, MAC (Medium Access Control) signaling), broadcast information (MIB (Master Information Block), SIB (System Information Block)), other signals, or combinations thereof. Also, RRC signaling may be called RRC messages, and may be, for example, RRC Connection Setup messages, RRC Connection Reconfiguration messages, etc.
[0168] Each aspect / embodiment described in this 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), 6th generation mobile communication system (6G), xth generation mobile communication system (xG) (xG (where x is, for example, an integer or decimal)), FRA (Future Radio Access), NR (new Radio), New radio access (NX), Future generation radio access (FX), W-CDMA (registered trademark), GSM (registered trademark), CDMA2000, UMB (Ultra Mobile Broadband), IEEE 802.11 (Wi-Fi (registered trademark)), IEEE 802.16 (WiMAX (registered trademark)), and IEEE This may apply to at least one system utilizing 802.20, UWB (Ultra-WideBand), Bluetooth®, or other appropriate systems, and to next-generation systems extended, modified, created, or defined based thereon. It may also apply to a combination of multiple systems (for example, a combination of at least one of LTE and LTE-A with 5G).
[0169] The processing procedures, sequences, flowcharts, etc., of each aspect / embodiment described herein may be reordered, provided they are consistent with each other. For example, the methods described herein present various step elements in an exemplary order and are not limited to that specific order.
[0170] In this specification, specific operations performed by the base station 10 may, in some cases, be performed by its upper node. In a network consisting of one or more network nodes having a base station 10, it is clear that various operations performed for communication with the terminal 20 can be performed by the base station 10 and at least one of the other network nodes (for example, an MME or S-GW, but not limited to these). Although the above example illustrates the case where there is one other network node besides the base station 10, the other network node may be a combination of multiple other network nodes (for example, an MME and an S-GW).
[0171] The information or signals described in this disclosure may be output from a higher layer (or lower layer) to a lower layer (or higher layer). They may also be input and output via multiple network nodes.
[0172] Input and output information may be stored in a specific location (e.g., memory) or managed using a management table. Input and output information may be overwritten, updated, or appended to. Output information may be deleted. Input information may be transmitted to other devices.
[0173] The determination in this disclosure may be made by a value represented by one bit (0 or 1), by a boolean value (true or false), or by a numerical comparison (for example, a comparison with a predetermined value).
[0174] Software should be broadly interpreted to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executable files, execution threads, procedures, functions, and so on, whether they are called software, firmware, middleware, microcode, hardware description languages, or by any other name.
[0175] Furthermore, software, instructions, information, etc., may be transmitted and received via a transmission medium. For example, if software is transmitted from a website, server, or other remote source using at least one of wired technology (such as coaxial cable, fiber optic cable, twisted pair, or digital subscriber line (DSL)) and wireless technology (such as infrared or microwave), then at least one of these wired and wireless technologies is included in the definition of a transmission medium.
[0176] The information, signals, etc. described in this disclosure may be represented using any of the various different techniques. For example, the data, instructions, commands, information, signals, bits, symbols, chips, etc. that may be referred to throughout the above description may be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, optical fields or photons, or any combination thereof.
[0177] In addition, terms used in this disclosure and terms necessary for understanding this disclosure may be replaced with terms having the same or similar meanings. For example, at least one of the channel and symbol may be a signal (signaling). Also, a signal may be a message. Furthermore, a component carrier (CC) may be called a carrier frequency, cell, frequency carrier, etc.
[0178] The terms “system” and “network” as used in this disclosure are interchangeable.
[0179] Furthermore, the information, parameters, etc., described in this disclosure may be expressed using absolute values, relative values from a given value, or other corresponding information. For example, wireless resources may be indicated by an index.
[0180] The names used for the parameters described above are not restrictive in any way. Furthermore, the formulas and other expressions using these parameters may differ from those expressly disclosed in this disclosure. Various channels (e.g., PUCCH, PDCCH, etc.) and information elements can be identified by any suitable name, and therefore, the various names assigned to these various channels and information elements are not restrictive in any way.
[0181] In this disclosure, terms such as "base station (BS)", "wireless base station", "base station", "fixed station", "NodeB", "eNodeB (eNB)", "gNodeB (gNB)", "access point", "transmission point", "reception point", "transmission / reception point", "cell", "sector", "cell group", "carrier", and "component carrier" may be used interchangeably. Base stations may also be referred to by terms such as macrocell, small cell, femtocell, and picocell.
[0182] A base station can house one or more (e.g., three) cells. If a base station houses multiple cells, the entire coverage area of the base station can be divided into several smaller areas, each of which may also be provided with communication services by a base station subsystem (e.g., a Remote Radio Head (RRH)). The terms “cell” or “sector” refer to part or all of the coverage area of at least one of the base station and / or base station subsystems that provide communication services in that coverage.
[0183] In this disclosure, the transmission of information by a base station to a terminal may be interpreted as the base station instructing the terminal to perform information-based control or operation.
[0184] In this disclosure, terms such as "Mobile Station (MS)," "user terminal," "User Equipment (UE)," and "terminal" may be used interchangeably.
[0185] A mobile station may also be referred to by those skilled in the art as a subscriber station, mobile unit, subscriber unit, wireless unit, remote unit, mobile device, wireless device, wireless communication device, remote device, mobile subscriber station, access terminal, mobile terminal, wireless terminal, remote terminal, handset, user agent, mobile client, client, or several other appropriate terms.
[0186] At least one of the base station and the mobile station may be called a transmitting device, a receiving device, a communication device, etc. At least one of the base station and the mobile station may also be a device mounted on a mobile body, the mobile body itself, etc. The mobile body refers to a movable object, and its speed of movement is arbitrary. This also includes the case when the mobile body is stationary. The mobile body includes, but is not limited to, vehicles, transport vehicles, automobiles, motorcycles, bicycles, connected cars, excavators, bulldozers, wheel loaders, dump trucks, forklifts, trains, buses, handcarts, rickshaws, ships and other watercraft, airplanes, rockets, satellites, drones (registered trademark), multicopters, quadcopters, balloons, and items mounted on them. The mobile body may also be a mobile body that moves autonomously based on operation commands. It may be a vehicle (e.g., a car, an airplane, etc.), an unmanned mobile body (e.g., a drone, an autonomous vehicle, etc.), or a robot (manned or unmanned). Furthermore, at least one of the base station and the mobile station may include devices that do not necessarily move during communication operations. For example, at least one of the base station and the mobile station may be an IoT (Internet of Things) device such as a sensor.
[0187] Furthermore, the term "base station" in this disclosure may be interpreted as "terminal." For example, the various aspects / embodiments of this disclosure may be applied to a configuration in which communication between a base station and a terminal is replaced with communication between multiple terminals 20 (which may be called, for example, D2D (Device-to-Device), V2X (Vehicle-to-Everything)). In this case, the terminals 20 may have the functions that the base station 10 has. Also, terms such as "uplink" and "downlink" may be interpreted as terms corresponding to terminal-to-terminal communication (for example, "side"). For example, uplink channel, downlink channel, etc., may be interpreted as side channel.
[0188] Similarly, the term "terminal" in this disclosure may be replaced with "base station." In this case, the base station may be configured to have the same functions as the terminal described above.
[0189] As used in this disclosure, the terms “determining” and “determining” may encompass a wide variety of actions. “Determining” may include, for example, judging, calculating, computing, processing, deriving, investigating, looking up, searching, inquiry (e.g., searching in a table, database, or other data structure), and ascertaining. “Determining” may also include, for example, receiving (e.g., receiving information), transmitting (e.g., sending information), input, output, and accessing (e.g., accessing data in memory). Furthermore, "judgment" and "decision" can include considering something as having been "judged" or "decided" after resolving, selecting, choosing, establishing, comparing, etc. In other words, "judgment" and "decision" can include considering something as having been "judged" or "decided" after some action. Also, "judgment (decision)" can be reinterpreted as "assuming," "expecting," or "considering."
[0190] The terms “connected,” “coupled,” or any variation thereof, mean any direct or indirect connection or coupling between two or more elements, and may include the presence of one or more intermediate elements between two elements that are “connected” or “coupled” with each other. The coupling or connection between elements may be physical, logical, or a combination thereof. For example, “connection” may be reinterpreted as “access.” As used in this disclosure, two elements may be considered to be “connected” or “coupled” with each other using at least one of one or more wires, cables, and printed electrical connections, and, in some non-limiting and non-exclusive examples, electromagnetic energy having wavelengths in the radio frequency domain, microwave domain, and optical (both visible and invisible) domain.
[0191] The reference signal can also be abbreviated as RS (Reference Signal), and may be called a pilot depending on the applicable standard.
[0192] In this disclosure, the phrase "based on" does not mean "based solely on" unless otherwise specified. In other words, the phrase "based on" means both "based solely on" and "based at least on."
[0193] Any reference to elements using the designations “first,” “second,” etc., as used in this disclosure does not generally limit the quantity or order of those elements. These designations may be used in this disclosure as a convenient way to distinguish between two or more elements. Accordingly, references to the first and second elements do not imply that only two elements may be employed, or that the first element must precede the second element in any way.
[0194] In the configuration of each of the above devices, "means" may be replaced with "part," "circuit," "device," etc.
[0195] Where the terms “include,” “including,” and variations thereof are used in this disclosure, these terms are intended to be inclusive, as is the term “comprising.” Furthermore, the term “or” as used in this disclosure is not intended to mean exclusive OR.
[0196] A wireless frame may consist of one or more frames in the time domain. Each of these frames in the time domain may be called a subframe. A subframe may further consist of one or more slots in the time domain. A subframe may have a fixed time length (e.g., 1 ms) that is independent of numerology.
[0197] Numerical logic may be communication parameters applied to at least one of the transmission and reception of a signal or channel. Numerical logic may include, for example, at least one of the following: subcarrier spacing (SCS), bandwidth, symbol length, cyclic prefix length, transmission time interval (TTI), number of symbols per TTI, radio frame configuration, specific filtering processes performed by the transceiver in the frequency domain, and specific windowing processes performed by the transceiver in the time domain.
[0198] A slot may consist of one or more symbols in the time domain (such as OFDM (Orthogonal Frequency Division Multiplexing) symbols, SC-FDMA (Single Carrier Frequency Division Multiple Access) symbols, etc.). A slot may also be a time unit based on neurology.
[0199] A slot may include multiple minislots. Each minislot may consist of one or more symbols in the time domain. Minislots may also be called subslots. Minislots may consist of fewer symbols than a slot. A PDSCH (or PUSCH) transmitted in a time unit larger than a minislot may be called PDSCH (or PUSCH) mapping type A. A PDSCH (or PUSCH) transmitted using a minislot may be called PDSCH (or PUSCH) mapping type B.
[0200] Wireless frames, subframes, slots, minislots, and symbols all represent units of time when transmitting a signal. Different names may be used for each of these terms.
[0201] For example, one subframe may be called a Transmission Time Interval (TTI), multiple consecutive subframes may be called a TTI, or one slot or one mini-slot may be called a TTI. In other words, at least one of a subframe and a TTI may be a subframe (1 ms) in existing LTE, a period shorter than 1 ms (e.g., 1-13 symbols), or a period longer than 1 ms. Note that the unit representing the TTI may be called a slot, mini-slot, etc., instead of a subframe. Also, one slot may be called a unit time. The unit time may differ from cell to cell depending on the neurology.
[0202] Here, TTI refers to, for example, the smallest unit of time for scheduling in wireless communication. For example, in an LTE system, the base station schedules each terminal 20 to allocate wireless resources (such as the frequency bandwidth and transmission power available to each terminal 20) in TTI units. However, the definition of TTI is not limited to this.
[0203] TTI may be a transmission time unit for channel-encoded data packets (transport blocks), code blocks, code words, etc., or it may be a processing unit for scheduling, link adaptation, etc. Given a TTI, the actual time interval (e.g., number of symbols) to which the transport block, code block, code word, etc. are mapped may be shorter than the given TTI.
[0204] Furthermore, if one slot or one mini-slot is referred to as TTI, then one or more TTIs (i.e., one or more slots or one or more mini-slots) may constitute the minimum time unit of scheduling. In addition, the number of slots (number of mini-slots) that constitute the minimum time unit of scheduling may be controlled.
[0205] A TTI with a time length of 1ms may also be called a normal TTI, long TTI, normal subframe, long subframe, slot, etc. A TTI shorter than a normal TTI may also be called a shortened TTI, short TTI, partial or fractional TTI, shortened subframe, short subframe, mini slot, sub slot, slot, etc.
[0206] Furthermore, long TTIs (e.g., normal TTIs, subframes, etc.) may be interpreted as TTIs with a time length exceeding 1 ms, and short TTIs (e.g., shortened TTIs, etc.) may be interpreted as TTIs with a TTI length less than that of a long TTI but 1 ms or more.
[0207] A resource block (RB) is a resource allocation unit in the time domain and frequency domain, and in the frequency domain, it may contain one or more consecutive subcarriers. The number of subcarriers in an RB may be the same regardless of the neurology, for example, 12. The number of subcarriers in an RB may be determined based on the neurology.
[0208] Furthermore, the time domain of RB may contain one or more symbols and may be the length of one slot, one minislot, one subframe, or one TTI. One TTI, one subframe, etc., may each consist of one or more resource blocks.
[0209] One or more RBs may also be called a Physical RB (PRB), Sub-Carrier Group (SCG), Resource Element Group (REG), PRB pair, RB pair, etc.
[0210] Furthermore, a resource block may consist of one or more resource elements (REs). For example, one RE may be a radio resource area comprising one subcarrier and one symbol.
[0211] A Bandwidth Part (BWP), also known as a partial bandwidth, may represent a subset of consecutive common resource blocks (RBs) for a particular neurology system in a given carrier. These common RBs may be identified by an index of the RBs relative to a common reference point of the carrier. A Bandwidth Part (PRB) may be defined and numbered within a given BWP.
[0212] A BWP may include BWPs for UL (UL BWP) and BWPs for DL (DL BWP). One or more BWPs may be configured within a single carrier for a UE.
[0213] At least one of the configured BWPs may be active, and the UE does not need to assume that it will send or receive a given signal / channel outside of the active BWP. In this disclosure, terms such as "cell" and "carrier" may be read as "BWP".
[0214] The structures described above, such as wireless frames, subframes, slots, minislots, and symbols, are merely illustrative. For example, the number of subframes included in a wireless frame, the number of slots per subframe or wireless frame, the number of minislots included in a slot, the number of symbols and RBs included in a slot or minislot, the number of subcarriers included in an RB, and the number of symbols, symbol length, and cyclic prefix (CP) length within a TTI can be varied in various ways.
[0215] In this disclosure, if articles are added through translation, such as a, an, and the in English, this disclosure may include the fact that the noun following these articles is plural.
[0216] In this disclosure, the term "A and B are different" may mean "A and B are different from each other." The term may also mean "A and B are each different from C." Terms such as "separate" and "combine" may be interpreted similarly to "different."
[0217] Each aspect / embodiment described herein may be used individually, in combination, or switched between as needed during implementation. Furthermore, notification of specific information (e.g., notification that "X is") is not limited to explicit notification, but may also be implicit (e.g., by not providing such notification).
[0218] Although the present disclosure has been described in detail above, it will be clear to those skilled in the art that the present disclosure is not limited to the embodiments described herein. The present disclosure can be implemented in modified and altered forms without departing from the intent and scope of the present disclosure as defined by the claims. Therefore, the descriptions in the present disclosure are illustrative and not intended to be restrictive in any way. [Explanation of Symbols]
[0219] 20 devices 30 CAPIF Core Device 40 Approved device 50 User Information Disclosure Device 60 application servers 65 Information Server 70 Data storage device 80 Data Management Device 90 NEF 100 FIDO servers 110 Transmitter 120 Receiver 130 Setting section 140 Control Unit 210 Transmitter 220 Receiver 230 Setting section 240 Control Unit 1001 Processor 1002 Storage device 1003 Auxiliary storage device 1004 Communication device 1005 Input device 1006 Output device 2001 Vehicle 2002 Drive Unit 2003 Steering Department 2004 Accelerator pedal 2005 Brake pedal 2006 Shift Lever 2007 Front Wheel 2008 Rear wheel 2009 Axle 2010 Electronic Control Unit 2012 Information Services Department 2013 Communication Module 2021 Current Sensor 2022 Rotation speed sensor 2023 Pneumatic Sensor 2024 Vehicle Speed Sensor 2025 Accelerometer 2026 Brake Pedal Sensor 2027 Shift lever sensor 2028 Object Detection Sensor 2029 Accelerator pedal sensor 2030 Driver Support Systems Department 2031 Microprocessor 2032 memory (ROM, RAM) 2033 Communication port (I / O port)
Claims
1. A receiving unit that receives an authentication request from an application server that has received access from a terminal, A control unit, when the authentication request includes specific parameters, checks whether specific registration information about the terminal is stored in the network node device of the communication system used by the terminal, and determines whether the terminal is authenticated based on the result of that check. The control unit includes, at a minimum, a transmission unit that sends an authorization code to the application server when it is determined that the terminal is authenticated. An authorization device equipped with the following features.
2. If the network node device has the specific registration information stored therein, the control unit will Based on the aforementioned specific registration information, it is confirmed whether the terminal has terminal authentication capabilities. The system determines that a terminal is authenticated if the terminal has the terminal authentication capability and the authentication server contains stored information indicating that the terminal is authenticated. The authorization device according to claim 1.
3. The control unit checks whether automatic login is permitted based on the subscriber information of the terminal user stored in the network node device. If the control unit determines that the terminal is authenticated and confirms that automatic login is permitted, the transmission unit transmits the authorization code to the application server. The authorization device according to claim 1.
4. The aforementioned specific parameter is a prompt parameter whose value is none. The authorization device according to claim 1.
5. An authorization device according to claim 1, and a user information disclosure device that transmits user information to the application server that has received the authorization code from the authorization device. A communication system equipped with [the following features].
6. The application server receives an authentication request from the terminal, and If the authentication request includes specific parameters, the step of checking whether specific registration information about the terminal is stored in the network node device of the communication system used by the terminal, and determining whether the terminal is authenticated based on the result of that check, At a minimum, the steps include sending an authorization code to the application server when it is determined that the terminal is authenticated. An authorization method performed by an authorization device, comprising the following features.