Patent Description:
Future mobile networks including <NUM> and beyond are expected to support many new types of connections between various devices such as cars, wearables, sensors and actuators from both private and industrial environment. These new types of connections usually imply very distinct requirements of service requests, and thereby pose challenges to the management and control of the mobile networks.

In particular, supporting various new types of services may have a deep impact on the mobile network architecture, in particularly core network (CN). In today's mobile network, services mainly refer to providing data and voice services for different type of terminals which can access the network. The CN provides the same treatment to different terminals following the best-effort principle. Hence, those services are predictable, and how to respond to them is be well pre-planned.

In order to adapt to various potential services, the network architecture has to be more flexible, dynamic and agile. Therefore, 3GPP SA2 defines the architecture as service-based architecture (SBA), wherein network functions (NFs) are modularized so that network services can be composed with several standardized NFs. Each NF may be instantiated by one or more NF instances.

In this document, the terms "NF" and "NF instance" are not strictly distinguished, i.e. may be used interchangeably. With enabling technologies, e.g. software defined networking (SDN), NF virtualization (NFV) etc., any virtual network may be composed. <NUM> clearly defines technical specifications on architectural support of virtualized deployment, which is a coincidence with the current technology trend.

In addition, with edge-computing the architecture of future mobile networks could be fully distributed, redundant, stateless, and scalable software-defined, which provides services by multiple NFs from several locations.

According to 3rd Generation Partnership Project (3GPP) specifications, every NF first has to register at a repository (called the NRF in <NUM> GPP). After that, the NF can be discovered and can provide its services. The registration procedure was recently extended to contain a certification procedure, wherein an NRF will issue a certificate (NF-cert) to an NF with the signature of the NRF for authentication.

In the future it is expected that many NFs could be deployed closer to the edge of the mobile network. Thus, it will be inefficient, if those NFs at the edge still contact one single NRF for registration, due to a longer latency and the bottleneck effect at a centralized NRF.

Considering huge amount of NFs in the edge which can provide different kind of service in the future, the current authentication architecture may not satisfy future requirements.

<CIT> discloses a security management for service authorization in communication systems with service-based architecture.

<CIT> discloses systems and methods for managing public key certificates and supporting users thereof.

'<NPL>' discloses security aspects of the <NUM> service-based architecture.

The inventors of the present disclosure considered that authentication between two NFs could be done in a distributed way, but that a root of trust is required. A typical solution would be Public Key Infrastructure (PKI). In a PKI, a Certificate Authority (CA) issues a certificate to a client, by signing the certificate with a signing key of the CA. The signing key is usually a private key that is kept confidentially by the CA. The certificate then can be verified by using the counter-part of the signing key (i.e., a public key). Specifically, the signature of the CA in the certificate is verified with the public key of the CA. In this way, a client can verify the certificate of another client, if the client possesses the public key of the CA.

Conventionally, the CA's certificates containing their public keys are pre-installed on the entities. A typical example is the certificates contained in web browsers, which will be used to verify the certificate of a website. Note that the CA can be built in a tree-like structure, wherein a CA at a higher layer can issue certificates to CA at lower layer. Similarly, the public key of a CA at a higher level can be used to verify the certificate issued by a CA at a lower level.

The main disadvantages thereby are identified by the inventors as follows:.

The conclusion of the inventors in view of the above is that a decentralized authentication solution is needed for a distributed setting with multiple NRFs. However, the observed deficiencies need to be overcome.

Accordingly, embodiments of the present disclosure aim to provide a solution for decentralized network entity authentication, particularly for NF authentication, which solution does not have the observed deficiencies. In particular, an objective is to provide a more efficient decentralized authentication procedure. The solution should not require repeated work to configure every new NF (instance).

In particular, it is considered that when an NF needs to authenticate another NF, if a certificate of the second NF has to be verified, the first NF has to possess a verification tool (e.g. a public key) of the NRF that issues the certificate to the second NF.

Further, it is considered that in the future mobile networks, there will be many NFs, which dynamically come and go. Therefore, pre-installing the verification tools of every NRF to every single NF is unrealistic. In addition, not every verification tool will be immediately required by a NF, thus it is also not necessary to pre-install all the verification tools. Moreover, even if there is a fixed number of NFs, there would be a dynamic number of NRFs, which could be added, removed and migrated at run-time happening everywhere in the network, so such a change will also cause a significant amount of updates to the NFs. Last but not least, if a common CA certifying NRFs from different domains is not available, pre-installing the verification tools does not support interoperability scenarios, in which NRFs belong to different domains (e.g. different operators).

The objective is achieved by the embodiments as described in the enclosed independent claims. Advantageous implementations of the embodiments are further defined in the dependent claims. In the following, parts of the description and drawings referring to embodiments not covered by the claims, are not part of the invention, but are illustrative examples necessary for understanding the invention.

A first aspect of this disclosure provides a first network entity for decentralized network entity authentication, wherein the first network entity comprises a processor being configured to: receive a request from a second network entity, wherein the request comprises an identification (ID) of a third network entity; and send a response to the second network entity, wherein the response comprises a verification tool of the third network entity.

In the first aspect, wherein the request comprises more than one ID, and each of the ID corresponds to a different third network entities. The third network entity in the following may mean one or more third network entity, and each of third network entity corresponds to different ID.

In the first aspect, the first network entity and the third network entity are each an NRF. Further, the second network entity is an NF. The first network entity ( the first NRF) may manage the second network entity ( the first NF).

Nevertheless, the first network entity may provide the verification tool of the third network entity (the second NRF) to the second network entity. This enables the second network entity to authenticate a fourth network entity (a second NF) that is managed by the third network entity. Accordingly, an efficient decentralized network entity authentication solution can be provided. The ID of the third network entity may be an NRF-ID.

In an implementation form of the first aspect, the processor is further configured to: receive a registration request from the second network entity, wherein the registration request comprises a profile of the second network entity; and send a response of the registration result to the second network entity, wherein the registration result comprises an ID of the first network entity.

Notably, there may be multiple network entities that provide registration results (e.g. multiple NRFs at which NFs register), and the second network entity can use the ID of the first network entity to distinguish it from those other network entities.

In an implementation form of the first aspect, the processor is further configured to: receive a first verification tool publishing request from the third network entity, wherein the first verification tool publishing request comprises the verification tool of the third network entity; and/or send a second verification tool publishing request to the third network entity, wherein the second verification tool publishing request comprises a verification tool of the first network entity.

In this way, the third network entity and the third network entity can initiate a procedure that shares the verification tools.

In an implementation form of the first aspect, the processor is further configured to: publish a transaction block to the third network entity, wherein the transaction block comprises the verification tool of the first network entity and/or the third network entity; or receive a transaction block published by the third network entity, wherein the transaction block comprises the verification tool of the third network entity and/or first network entity.

For instance, the transaction blocks may be transaction blocks used in a blockchain technology. The verification tools may be transactions. These transaction blocks may be verified in a distributed manner by network entities (e.g. NRFs) to establish a mutually trusted relationship and make them secure against forgery.

In an implementation form of the first aspect, the processor is further configured to: participate in a competition with the third network entity, in order to determine who publishes the transaction block.

In particular, the winner of the competition may publish the transaction block. For example, a distributed consensus protocol used in blockchain technology may provide a basis for this competition.

In an implementation form of the first aspect, the processor is further configured to: update the verification tool of the first network entity with the verification tool included in the transaction block published by the third network entity, if the published transaction block is validated.

In particular, both the transaction block and every transaction (verification tool) in the transaction block may be validated. The validation may happen at two places. First, before including a transaction (a received verification tool) into a transaction block, and second, after the transaction block is published from a winner of the competition.

In an implementation form of the first aspect, the first network entity and the third network entity are arranged in a hierarchical structure of network entities, the hierarchical structure comprising multiple hierarchical parallel trees; and the first network entity and the third network entity are root network entities arranged, respectively, on a highest hierarchy level of a different tree.

In an implementation form of the first aspect, the first network entity and the third network entity are arranged in a hierarchical structure of network entities; the first network entity and the third network entity are arranged on different hierarchy levels; and the processor is further configured to forward the request received from the second network entity to the parent network entity of the first network entity.

In particular, the first and the third network entity may be on different hierarchy levels of the same tree, or may be on different hierarchy levels of different trees. Notably, forwarding the request to the parent network entity does not depend on where the target network entity is. The target network entity could belong to a sibling network entity.

In an implementation form of the first aspect, the verification tool of the third network entity is a verification tool of a lowest common ancestor (LCA) network entity of the first network entity and the third network entity.

In an implementation form of the first aspect, the processor is further configured to: send a request to the parent network entity of the first network entity to identify a LCA network entity of the first network entity and the third network entity.

In an implementation form of the first aspect, the verification tool of a the first network entity and/or a verification tool of the third network entity given network entity comprises, respectively, a public key, a profile, and a signature, of the first network entity and/or the third network given network entity.

In an implementation form of the first aspect, the verification tool of the first network entity and/or the third network entity comprises a public key pair, wherein the public key pair comprises, respectively, the public key of the first network entity or the third network entity, and a public key of an NF.

In this implementation form, the request received by the first network entity from the second network entity may comprise, in addition to the ID of the third network entity, an ID of an NF, particularly of the above-mentioned NF, for which there is a public key in the verification tool.

In an implementation form of the first aspect, the ID comprises one of: IP address, MAC address, URL.

A second aspect of this disclosure provides a second network entity for decentralized network entity authentication, wherein the second network entity comprises a processor being configured to: send a request to a first network entity, wherein the request comprises an ID of a third network entity; and receive a response from the first network entity, wherein the response comprises a verification tool of the third network entity.

In the second aspect, wherein the request comprises more than one ID, and each of the ID corresponds to a different third network entity. Similarly, the third network entity in the following may mean one or more third network entities, and each of third network entity corresponds to different ID.

In the second aspect, the first network entity and the third network entity are each an NRF. Further, the second network entity is an NF. The first network entity (the first NRF) may manage the second network entity (the first NF). Nevertheless, the second network entity may receive the verification tool of the third network entity (the second NRF) from the first network entity. This enables the second network entity to authenticate a fourth network entity (the second NF) managed by the third network entity. Accordingly, an efficient decentralized network entity authentication solution can be provided.

In an implementation form of the second aspect, the processor is further configured to: receive a service request from a fourth network entity, wherein the service request comprises a certificate of the fourth network entity, wherein the certificate of the fourth network entity is signed by the third network entity; and verify the certificate with the verification tool of the third network entity.

In an implementation form of the second aspect, the processor is further configured to: receive a service request from a fourth network entity, wherein the service request comprises a certificate of the fourth network entity, wherein the certificate of the fourth network entity is signed by the third network entity; and determine the ID of the third network entity from the certificate.

The fourth network entity is an NF like the second network entity. This implementation form provides an efficient way for the second network entity to obtain the ID, which it can then use to send the request to the first network entity. The ID of the third network entity may be an NRF-ID. However, other way to determine the ID of the third network entity by the second network entity are also possible.

In an implementation form of the second aspect, the processor is further configured to: verify the certificate with the verification tool of the third network entity.

That is, the second network entity can verify the fourth network entity, even if the fourth network entity is managed (registered at) by another network entity (i.e., the third network entity, i.e.. the second NRF) than the second network entity (i.e., the first network entity, i.e., the first NRF).

In an implementation form of the second aspect, the processor is further configured to: send a registration request to the first network entity, wherein the registration request comprises a profile of the second network entity; and receive a response of the registration result from the first network entity, wherein the registration result comprises a certificate issued by the first network entity for the second network entity.

In this way, the second network entity can register with the first network entity, i.e., it may then be managed by the first network entity.

It has to be noted that all network entities and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof.

Some abbreviations and terms, which are used in this disclosure, are defined in the following:.

Some notations are further defined in the following table:.

The above described aspects and implementation forms of the present disclosure will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which.

<FIG> shows a first network entity <NUM> according to an embodiment, and a second network entity <NUM> according to an embodiment. The network entities <NUM> and <NUM> may support a decentralized network entity authentication, in particular decentralized NF authentication. The first network entity <NUM> is a first NRF, and the second network entity <NUM> is a first NF. The second network entity <NUM> may be registered at the first network entity <NUM>, e.g., the first network entity <NUM> may manage the second network entity <NUM>. The first network entity <NUM> and the second network entity <NUM> each comprises a processor, which is configured to perform the functions/actions described for the first network entity <NUM> and second network entity <NUM>, respectively, in the present disclosure.

The second network entity <NUM> is configured to send a request <NUM> to the first network entity <NUM>. Accordingly, the first network entity <NUM> is configured to receive the request <NUM> from the second network entity <NUM>. The request <NUM> comprises an ID <NUM> of a third network entity <NUM>. The third network entity <NUM> comprises a processor, which is configured to perform the functions/actions described for the third network entity <NUM> in the present disclosure. The third network entity <NUM> is a second NRF, and the ID <NUM> may be an NRF-ID of the second NRF that is the third network entity <NUM>. The third network entity <NUM> may manage another (fourth) network entity which is different from the second network entity <NUM>.

In one possible implementation, the request <NUM> may comprises more than one IDs <NUM> of different third network entities <NUM>, and each third network entities <NUM> corresponds to each ID, or each ID corresponds to a different third network entities. It should be noted that, the third network entity in this disclosure may mean one or more third network entities, and each of third network entity corresponds to a different ID. It will not be elaborated in order to avoid redundancy.

The first network entity <NUM> is further configured to send a response <NUM> to the second network entity <NUM>, wherein the response <NUM> comprises a verification tool <NUM> of the third network entity <NUM>. The verification tool <NUM> may comprise a public key of the third network entity <NUM> or may comprise a public key pair comprising the public key of the third network entity <NUM> and a public key of an NF. Accordingly, the second network entity <NUM> may be configured to receive the response <NUM> including the verification tool <NUM> from the first network entity <NUM>.

The second network entity <NUM> may be further configured to receive a service request <NUM> (not shown in <FIG>, but shown in <FIG>) from a fourth network entity <NUM> (not shown in <FIG>, but shown in <FIG>), wherein the service request <NUM> comprises a certificate of the fourth network entity <NUM>, and wherein the certificate of the fourth network entity <NUM> may be signed by the third network entity <NUM>. The fourth network entity <NUM> comprises a processor, which is configured to perform the functions/actions described for the fourth network entity <NUM> in the present disclosure.

For example, the fourth network entity <NUM> may be registered at the third network entity <NUM>, i.e., the third network entity <NUM> may manage the fourth network entity <NUM>. The second network entity <NUM> may then verify the certificate of the fourth network entity <NUM> with the verification tool <NUM> of the third network entity <NUM> (as obtained with the response <NUM> from the first network entity <NUM>).

In one possible implementation, the second network entity <NUM> may proactively send a service request to a fourth network entity <NUM> to authenticate the certificate of the fourth network entity, and the second entity <NUM> may use this request to obtain the certificate of the fourth entity. The service request may comprises at least an identity, ID, of the fourth network entity <NUM>.

Notably, the above-described procedures may likewise applicable for the third network entity <NUM> and the fourth network entity <NUM>, e.g., the fourth network entity <NUM> may obtain the verification tool <NUM> of, for instance, the first network entity <NUM> from the third network entity <NUM>. Further, the fourth network entity <NUM> may then verify a certificate of the second network entity <NUM> when the second network entity <NUM> sends a service request <NUM> to the fourth network entity <NUM>.

Similarly, in proactive authentication case, the second network entity <NUM> may receive response from the fourth network entity <NUM> which includes certificate of the fourth network entity. The second network entity <NUM> obtains the ID of the third network entity <NUM> based on the certificate of the fourth network entity <NUM>.

In this way, authentication between the two network entities <NUM> and <NUM>, in particular NFs, may be performed in a decentralized manner, i.e., even if the two network entities <NUM> and <NUM> are registered/managed at/by different network entities <NUM> and <NUM>, in particular NRFs.

Any network entity in the present disclosure may be implemented by a device that comprises processing circuitry (not shown) configured to perform, conduct or initiate the various operations of the network entity described herein. The processing circuitry may comprise hardware and/or software. The hardware may comprise analog circuitry and/or digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multi-purpose processors. In one embodiment, the processing circuitry comprises one or more processors and a non-transitory memory coupled to the one or more processors. The non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the device implementing the network entity to perform, conduct or initiate the operations or methods described herein.

In the following, the embodiments shown in <FIG> are described in more detail, in particular, the network entities <NUM>, <NUM>, <NUM>, and <NUM> mentioned above. For the following description the first network entity <NUM> and the third network entity <NUM> are NRFs. In this disclosure, the network entities <NUM> and <NUM> could be interchanged. The second network entity <NUM> and the fourth network entity <NUM> are NFs. In this disclosure these network entities <NUM> and <NUM> could be interchanged.

Further, in this disclosure a distributed NRF environment is considered, in which multiple NRFs may exist. An NRF may, for instance, be assigned to manage one domain, wherein all NFs in one such domain registers at the same NRF. The NFs that register at one NRF may be called the "managed NFs" of the NRF. The domain here may be a geography location, or an operator's network, or one management area, or an autonomous are, or specific technical field etc. For example, one domain may be a network of an operator, or may be a tracking area of a mobile network, or may be subnet of a mobile network.

It is further considered that there is no centralized control of the NFs, in particular, there is no centralized NRF. It is not assumed that the NRFs have the same owner, which represents a typical multi-operator scenario, in which every operator only controls its own NRF.

Based on these settings, the decentralized authentication solution is proposed based on the embodiments, for one, by extending the traditional NRF to the NRF <NUM> (or NRF <NUM>). Such an extended NRF <NUM>/<NUM> may act as a peer node interacting with other NRFs, and provides authentication services to its managed NFs <NUM>/<NUM>. In the embodiments, two new features are introduced to the traditional NRF.

The first feature is the capability of the NRF <NUM> to share its own verification tool <NUM> to another NRF <NUM>, and all NRFs <NUM>/<NUM> together maintain an identical copy of all shared verification tools <NUM>.

The second feature is to provide a verification tool <NUM> of a particular NRF <NUM> in response to a verification tool retrieval request <NUM> from its managed NF <NUM>. This is shown in <FIG>.

The present disclosure also considers two different scenarios. The first scenario is that all NRFs are completely equal. They are peers in the distributed NRF system to share their verification tools <NUM> with each other. The goal is to guarantee a same copy of the verification tools <NUM> on every NRF. For an NF under the domain of an NRF, the NRF is responsible for providing the verification tool <NUM> of a particular NRF from another domain that is on-demand requested by the managed NF. The general architecture of this scenario is shown in <FIG>.

In particular, in <FIG> the NRF1 <NUM> manages the NF1 <NUM>, and the NRF2 <NUM> manages the NF2 <NUM>. Further, additional NRFs <NUM> may manage additional NFs <NUM>. The NRFs <NUM>, <NUM>, <NUM> may share their verification tools <NUM>.

The second scenario is that the topology of the NRFs presents a hierarchical architecture/structure <NUM>, which is shown in <FIG>. Here, the NRFs are arranged in different layers (hierarchical levels). The hierarchical structure <NUM> may comprise one or more hierarchical parallel trees (could be the same as domains). At the top level, i.e. <NUM>-th layer, each NRF represents a root NRF of one tree. Child NRFs arranged at the i+<NUM>-th layer (i≥<NUM>) are controlled by one of NRF at the i-th layer. This scenario is different to the flat NRF architecture of <FIG>, wherein trust among the NRFs is not assumed.

In particular, in <FIG>, as an example, two NRF branches exist, rooted respectively at NRF0. <NUM> and NRF0. NF1 <NUM> is under NRF2. <NUM>'s (NRF <NUM>) management, while NF2 <NUM> is under NRF <NUM>. m's (NRF <NUM>) management. The present disclosure considers how the verification tools <NUM> would be retrieved, so that the two NFs <NUM> and <NUM> can authenticate each other.

The distributed NRF system of <FIG> or <FIG> could have a certain network topology. The distributed NRF system can be formed with NRFs deployed ranging at the edge (e.g. close to the base station with edge computing) to the core network (e.g. in a data center). An NRF can be either a physical equipment as conventional devices or a virtualized NF that may be controlled in run-time whenever an update, a migration, a removal is needed. NRFs may be considered to be in different domains, among which a trusted relationship cannot be achieved easily.

A full procedure for decentralized NF authentication is depicted - with respect to the flat architecture shown in <FIG> - in <FIG>, and is described below.

The NF1 <NUM> sends a registration request <NUM> to register at the NRF1 <NUM>. In the registration request <NUM>, the NF1 <NUM> provides its profile data to the NRF1 <NUM>. The parameters of the registration request <NUM> comprise at least the ones listed in the table below:.

Notably, the above-listed parameters are basic parameters for registration, and the list can be extended, if other profile information is to be added. The NF2 <NUM> will follow the same procedure as the NF1 <NUM> does, in order to register at the NRF2 <NUM>. The NRF1 <NUM> receives the registration request <NUM> from the NF1 <NUM>. NRF1 may create an NF entry, if all information of NF1's profile is verified. If NF I's profile is not verified successfully, the NF1 <NUM> registers failed. The registration response message <NUM> of the NRF <NUM> to the NF1 <NUM> may include parameters as listed in the table below:.

The NRF1 <NUM> then issues a certificate for the NF1 <NUM>, and parameters that may be used therefore are listed in the table below:.

The NRF1's profile data may comprise parameters as listed in the table below:.

The listed parameters in all tables may be basic parameters, and may be extended if more information has to be added. The NRF2 <NUM> follows the same procedure as in step <NUM>, wherein the NRF2 <NUM> replies to the NF2 <NUM> with a NF2-cert, e.g., with a certificate for the NF2 <NUM>. The NRF1 <NUM> may send the NRF2 <NUM> its verification tool <NUM>, (i.e. NRF2-VerTool).

The verification tool <NUM> may comprise the parameters listed in the table below:.

The listed parameters can be further extended, if more parameters are to be added, in order to define a more specific verification tool <NUM>. The received verification tool <NUM> (e.g. NRF1-VerTool) will be validated (by NRF2 <NUM>), for example, first by checking the signature in the response <NUM>. If the verification tool <NUM> is valid, it will be kept, otherwise, it will be dropped. Notably, this step only decides, whether the received data matches the validation information. Whether the verification tool <NUM> should be stored as the verification tool <NUM> of the NRF1 <NUM>, indicated by the NRF-ID in the NRF profile, will be decided later. The NRF2 <NUM> periodically creates a transaction block (VerTool Block) with all the verification tools <NUM> passing the validation check. Elements that a transaction block may comprise are shown in the table below:.

If the NRF2 <NUM> wins the competition, the NRF2 <NUM> broadcasts/publishes the transaction block (VerTool Block) to the NRF1 <NUM>. When the NRF1 <NUM> receives the broadcast transaction block from the NRF2 <NUM>, it will validate the received block with one or more of the following procedure.

If the transaction block is verified as a valid proposal, the NRF1 <NUM> updates its local verification tool information (NRF1-ID and its corresponding NRF1-VerTool) with the list of verification tools <NUM> contained in the Block Body. The NF2 <NUM> sends a service request <NUM> to the NF1 <NUM>, wherein the service request <NUM> comprises the following parameters listed in the table below:.

The "Service Requirements" depend on the type of the NF (NF2 <NUM>) and the available service types that can be provided from the NF service producer (NF1 <NUM>). Therefore, they can be extended according to concrete service request scenarios. The NF certificate field (NF2-cert) provides NF Profile, NF2-PubKey and NRF2's Profile. The service request <NUM> will be signed by NF2-PrivKey;
<NUM>. The NF1 <NUM> receives the service request <NUM> from the NF2 <NUM>, and gets the NF2-cert from the service request <NUM> after checking the NF signature. In the NF2-cert, the NF1 <NUM> retrieves the NRF2-ID <NUM>. After that, the NF1 <NUM> sends the request <NUM> to the NRF1 <NUM> for retrieving the NRF2-VerTool <NUM> indicated by the NRF2-ID <NUM> as a parameter comprised in the request <NUM>. For the proactive authentication disclosed previously, The NF1 <NUM> sends the service request <NUM> to the NF2 <NUM>, and gets the NF2-cert from the service response. It will not be elaborated here for simplicity. The NRF1 <NUM> receives the request <NUM> from the NF1 <NUM> and locally looks up with the parameter NRF2-ID <NUM>. If found, the NRF1 <NUM> replies to the NF1 <NUM> with a response <NUM> with the NRF2-VerTool <NUM> of NRF2 <NUM>. The NF1 <NUM> verifies the NF2-cert by using the received verification tool <NUM> of NRF2 <NUM>. If authentication is successful, the NF1 <NUM> replies to the NF2 <NUM> with a message to provide a response <NUM> of either accepting or rejecting the service request depending on the authentication result.

The procedure of <FIG> is described in the following for the hierarchical structure <NUM> shown in <FIG>.

Notably, in the hierarchical structure <NUM>, an NF registers at one NRF and gets a certificate from the NRF as well. However, a child NRF is certified by its parent NRF. Therefore, the verification tool <NUM> of an NRF may be derivative. An NF-cert may be verified by two types of NRF-VerTools, which are the NRF-VerTool where the NF registers and the parent NRF-VerTool.

In this embodiment, when an NF (here the NF1 <NUM>) needs to verify another NF (here the NF2 <NUM>), the verification tool <NUM> that the NF1 <NUM> has to obtain is determined by a relationship of the two NRFs (here the NRF1 <NUM> and the NRF2 <NUM>). Specifically, there could be following cases:.

The decentralized authentication solution for a hierarchical NRF architecture <NUM> may generally follow the same procedure as depicted in <FIG>. For simplicity, in the following only operations that are different to those in the flat architecture are described in more detail.

The NF1 <NUM> registers at the NRF1 <NUM> (same as in the flat NRF case). The NF2 <NUM> registers at the NRF2 <NUM> (same as in the flat NRF case). The NRF1 <NUM> may send to the NRF2 <NUM> its verification tool <NUM> (i.e. NRF1-VerTool) (same as in the flat NRF case).

For Case <NUM>, there is no verification toll <NUM> exchange operation because they are the same NRF. For Case <NUM>, the NRF2 <NUM> may send a request to its parent NRF <NUM>, to identify a lowest common ancestor (LCA) NRF with the NRF1 <NUM> in the NRF tree/domain, and sends a request to retrieve the LCA-NRF-VerTool. The request may comprise parameters as shown in the table below:.

For Case <NUM>, there are several sub-cases in further as follows.

The NF2 <NUM> may send a service request <NUM> to the NF1 <NUM> (same as in the flat NRF case). The NF1 <NUM> may get the NRF2-ID <NUM> from NF2's service request <NUM> (same as in the flat NRF case). The NRF1 <NUM> may receive the request from the NF1 <NUM>, and decide where to retrieve the verification tool <NUM> that can verify NF2-cert based on the parsed NRF2-ID <NUM>.

The NF1 <NUM> verifies NF2-cert by using NRF2-VerTool <NUM> (same as in the flat NRF case). The NF1 <NUM> replies to the NF2 <NUM> with a message to provide a service response <NUM> (same as in the flat NRF case).

<FIG> shows a method <NUM> according to an embodiment. The method <NUM> is for decentralized network entity authentication, in particular NF authentication. The method <NUM> may be performed by the first network entity <NUM> of FIG. The method <NUM> comprises receiving <NUM> a request <NUM> from a second network entity <NUM>, wherein the request <NUM> comprises an ID <NUM> of a third network entity <NUM>. The method <NUM> may further comprise sending <NUM> a response <NUM> to the second network entity <NUM>, wherein the response <NUM> comprises a verification tool <NUM> of the third network entity <NUM>.

<FIG> shows a method <NUM> according to an embodiment. The method <NUM> may be for decentralized network entity authentication, in particular NF authentication. The method <NUM> may be performed by the second network entity <NUM> of <FIG>. The method <NUM> comprises sending <NUM> a request <NUM> to a first network entity <NUM>, wherein the request <NUM> comprises an ID <NUM> of a third network entity <NUM>. The method <NUM> may further comprise receiving <NUM> a response <NUM> from the first network entity <NUM>, wherein the response <NUM> comprises a verification tool <NUM> of the third network entity <NUM>.

The proposed embodiments implementing a distributed network entity authentication based on the introduced NRF-ID related information provides some key benefits that are summarized as follows.

Claim 1:
A first network repository function, NRF, (<NUM>) for decentralized network entity authentication in a mobile network, wherein the first NRF comprises
a processor being configured to:
receive a request (<NUM>) from a first network function, NF, (<NUM>), wherein the request (<NUM>) comprises an identification, ID, (<NUM>) of a second NRF (<NUM>); and
send a response (<NUM>) to the first NF (<NUM>), wherein the response (<NUM>) comprises a verification tool (<NUM>) of the second NRF (<NUM>).