Patent Description:
Using the fifth generation (<NUM>) network, not only more humans are getting connected for their private and/or public uses, but also machines, robots, cars and/or devices will use the <NUM> network for their critical communications. To meet all of the requirements, the <NUM> core network (5GC) is designed to be extremely secure.

A network function (NF) acting as a service consumer (which may be referred to as "NF service consumer" or "NFc" in the following) may request a service from a NF acting as a service producer (also referred to as "NF service producer" or "NFp" in the following). To access the requested service, an access token is provided by a network repository function (NRF) to the NFc to prevent unauthorized access. If the NFc and the NFp are located in different networks, obtaining of the access token involves communication between NRFs in different networks.

<CIT> discloses a method for network function authentication using a digitally signed service request in a communication system. A service request to access at least one service of a service producer is generated at a service consumer. The service request comprises an access token with a public key of the service consumer bound thereto. The service consumer digitally signs the service request to form a digital signature using a private key of the service consumer that corresponds to the public key bound to the access token. The service request and the digital signature are sent from the service consumer to the service producer.

<CIT> discloses a method for inter-mobile network communication authorization, the method comprising: receiving, by a resource request authorization service, a protected first message from a service-consuming second network entity in a second mobile network for a service-providing first network entity in a first mobile network, the first message comprising a request for a resource of the first network entity, performing an authorization procedure comprising verification of authority of the service- consuming second network entity identified in the first message to obtain requested service indicated by the request, and generating a signed second message comprising the request for the first network entity in response to the authorization procedure being successfully performed.

<NUM>rd Generation Partnership Project (3GPP) Technical Specification <NUM> v. <NUM> specifies security architecture, that is, the security features and the security mechanism for the <NUM> system and the <NUM> Core, and the security procedures performed within the <NUM> System including the <NUM> Core and the <NUM> New Radio.

In general, example embodiments of the present disclosure provide apparatuses, methods and computer readable storage media for inter-network communication. The scope of protection sought for various example embodiments is set out by the independent claims.

Through the more detailed description of some example embodiments of the present disclosure in the accompanying drawings, the above and other objects, features and advantages of the present disclosure will become more apparent, wherein:.

Further, when a particular feature, structure, or characteristic is described in connection with an example embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

As used herein, the term "communication network" refers to a network following any suitable communication standards, such as Long Term Evolution (LTE), LTE-Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), High-Speed Packet Access (HSPA), Narrow Band Internet of Things (NB-IoT), New Radio (NR) and so on. Furthermore, the communications between a terminal device and a network device in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the first generation (<NUM>), the second generation (<NUM>), <NUM>, <NUM>, the third generation (<NUM>), the fourth generation (<NUM>), <NUM>, the fifth generation (<NUM>) communication protocols, and/or any other protocols either currently known or to be developed in the future. Embodiments of the present disclosure may be applied in various communication systems. Given the rapid development in communications, there will of course also be future type communication technologies and systems with which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system.

As used herein, the NRF is a network function which maintains NF profiles and available NF instances. The NRF can also provide service registration and discovery functionalities such that NFs can discover each other.

Principle and implementations of the present disclosure will be described in detail below with reference to the accompanying drawings. Reference is now made to <FIG> illustrates a block diagram of an environment <NUM> in which some example embodiments of the present disclosure can be implemented. <FIG> illustrates an example environment <NUM> for a Service Based Architecture (SBA) roaming scenario.

Generally, the environment <NUM> includes two networks <NUM> and <NUM>, which may be two Public Land Mobile Networks (PLMNs). For example, the networks <NUM> and <NUM> may be operated by different operators. The network <NUM> (also referred to as "first network <NUM>") includes a NF <NUM>, a NRF <NUM> and a Security Edge Protection Proxy (SEPP) <NUM>. The NRF <NUM> maintains a NF profile of the NF <NUM> and also provides service registration and discovery functionalities to the NF <NUM>. The SEPP <NUM> is located at the edge of the network <NUM> and protects the network <NUM> against unwanted traffic from other networks.

Similarly, the network <NUM> (also referred to as "second network <NUM>") includes a NF <NUM>, a NRF <NUM> and a SEPP <NUM>. The NRF <NUM> maintains a NF profile of the NF <NUM> and also provides service registration and discovery functionalities to the NF <NUM>. The SEPP <NUM> is located at the edge of the network <NUM> and protects the network <NUM> against unwanted traffic from other networks.

In some example embodiments, the SEPPs <NUM> and <NUM> can communicate with each other via a N32 interface, for example, a N32-c connection or a N32-f connection. Alternatively, or in addition, the SEPPs <NUM> and <NUM> can communicate with each other via one or more Internet Protocol exchange Service (IPX) node(s) <NUM>.

In some example embodiments, the NF <NUM> may act as a service consumer, which may request a service from the NF <NUM> acting as a service producer. Only for the purpose of illustration, in the following, the NF <NUM> is also referred to as "NFc <NUM>" or "first NF <NUM>", and the NF <NUM> is also referred to as "NFp <NUM>" or "second NF <NUM>".

In the roaming scenario, the network <NUM> may be a visited or serving PLMN and thus may also be referred to as "vPLMN <NUM>" merely for the purpose of illustration. The network <NUM> may be a home PLMN or a service request receiving and processing PLMN and thus may also be referred to as "hPLMN <NUM>" merely for the purpose of illustration. Accordingly, the NRF <NUM> in the network <NUM> may also be referred to as "vNRF <NUM>" and the NRF <NUM> in the network <NUM> may also be referred to as "hNRF <NUM>".

As mentioned above, unauthorized service access needs to be prevented for the purpose of security. OAuth <NUM> is a key technology and widely used for NF service access authorization in <NUM> SBA. It allows NF service producers to authorize service requests from NF service consumers. When a NFc requests to access or consume a service provided by a NFp, the NFc needs to request an access token from an OAuth <NUM> authorization server (for example, a NRF). If the NFc is authorized to access the service of the NFp, the OAuth <NUM> authorization server returns an access token. The NFc then includes the access token in its service request towards the NFp. The NFp will verify the access token received from the NFc.

In the roaming scenario, if a NFc in a vPLMN expects to access a service provided by a NFp in a hPLMN, the NFc needs to obtain an access token independently before accessing the service. Reference is now made to <FIG> illustrates an interaction diagram of a process <NUM> for obtaining an access token before NF service access in the roaming scenario.

As shown in <FIG>, a registration procedure is performed <NUM> between a NFc <NUM> and a vNRF <NUM>, which is located in the same PLMN as the NFc <NUM>. As such, the NFc <NUM> acting as an OAuth2. <NUM> client is registered with the vNRF <NUM> acting as an authorization server in the vPLMN. In some scenarios, this (client) registration is optional. Similarly, a NFp (not shown in <FIG>) acting as an OAuth2. <NUM> resource server is registered with the hNRF <NUM> acting as an authorization server in the hPLMN. The vNRF <NUM> and vNRF <NUM> may mutually authenticate <NUM> each other.

The NFc <NUM> expects to access a service provided by the NFp in the hPLMN. The NFc <NUM> transmits <NUM> a request for an access token (which is also referred to as "access token request") to the vNRF <NUM>. The access token request includes information related to the NFc <NUM> and the expected service. For example, the NFc <NUM> may invoke Nnrf_ AccessToken_Get Request. The Nnrf_ AccessToken_Get Request may include NF Instance ID of the NFc <NUM>, the requested "scope" including the expected NF Service Name(s) and optionally "additional scope" information (i.e. requested resources and requested actions (service operations) on the resources, NF Type of the expected NFp instance, NF type of the NFc <NUM>, home and serving PLMN IDs, optionally list of Network Slice Selection Assistance Information (NSSAIs) or list of network slice instance (NSI) IDs for the expected NF Service Producer instances, optionally NF Set ID of the expected NFp.

The vNRF <NUM> authenticates <NUM> the NFc <NUM> acting as the OAuth2. <NUM> client. Then, the vNRF <NUM> identifies the hNRF <NUM> in the hPLMN based on the home PLMN ID included in the access token request. The vNRF <NUM> transmits <NUM> the access token request to the hNRF <NUM> to request an access token from hNRF <NUM>.

The hNRF <NUM> authorizes <NUM> the NFc <NUM>. Specifically, the hNRF <NUM> may check whether the NFc <NUM> is authorized to access the requested service(s). If the NFc <NUM> is authorized, the hNRF <NUM> generates <NUM> an access token with appropriate claims. The hNRF <NUM> may digitally sign the generated access token based on a shared secret or private key. That is, the authorization is successful.

The hNRF <NUM> transmits <NUM> an access token response including the generated access token to the vNRF <NUM>. For example, Nnrf_ AccessToken_Get Respone including the access token is transmitted to the vNRF <NUM>. The vNRF <NUM> then transmits the access token response to the NFc <NUM>. The NFc <NUM> may store the received access token(s) for accessing service(s) from the NFp.

If the authorization by the hNRF <NUM> is unsuccessful, or in other words, if the NFc <NUM> is not authorized, the hNRF <NUM> may not issue an access token to the NFc <NUM>. In this case, the hNRF <NUM> transmits an OAuth <NUM> error response to the vNRF <NUM>, which forwards the OAuth <NUM> error response to the NFc <NUM>.

The NFc <NUM> is connected or registered to the NRFc, which is the vNRF <NUM> in <FIG>. Therefore, the vNRF <NUM> knows the details of the NFc <NUM>. The vNRF <NUM> can validate the requester (the NFc <NUM>) side parameters provided in the access token request.

Table <NUM> shows an example of the Access Token application programing interface (API) where the requester side parameters are available. In Table <NUM>, the abbreviation "S-NSSAI" is short for "single NSSAI". The abbreviation "FQDN" is short for "Fully Qualified Domain Name" and the abbreviation "SNPN" is short for "Standalone Non-Public Network".

However, the Access Token API is served by the NRFp where NFp profile is provisioned. In the roaming scenario, the NRFp, which is the hNRF <NUM> is located in a different PLMN.

As can be seen from the above process <NUM>, the NFc <NUM> adds parameters related to the NFc <NUM> in the access token request transmitted <NUM> to the hNRF <NUM> via vNRF <NUM>. The parameters related to the NFc <NUM> include for example NF instance ID, requester PLMN list, requester SNPN list, etc. However, when the hNRF <NUM> authorize <NUM> the NFc <NUM>, there is no NF profile of the NFc <NUM> in the hNRF <NUM>. Therefore, the hNRF <NUM> cannot validate the parameters related to the NFc <NUM>. For example, the hNRF <NUM> cannot validate the following parameters of the NFc <NUM> available in the access token request: the NF type, PLMN ID, SNPN ID, Requester NF Set ID, Requester NF Service Set ID, Vendor ID, and Domain ID, etc..

In view of the foregoing, when a NFc in a network expects to access a service from a NFp in another network, inter-network communication such as inter-PLMN communication is involved. In this case, a problem that the NRFp (that is, the hNRF) cannot validate the requester (that is the NFc) side parameters available in the Access Token API, which is in a different network needs to be solved. In other words, there is a need for a mechanism to enable the hNRF to trust the requester side parameters provided by the vNRF.

Embodiments of the present disclosure provide a solution for communication between NRFs in different networks. In this solution, a NFc located in a first network expects to access a service provided by a NFp in a second network different from the first network. The NFc transmits a request for an access token (which is also referred to as an access token request) to a vNRF in the first network. The access token is to be used by the NFc to request the service from the NFp. The vNRF forwards the request to a vSEPP in the first network. The request includes information concerning the NFc. At least one of the vNRF and the vSEPP verifies the information and adds the verified information into the request. For example, a custom header including the verified information may be inserted into the request. After successful validation of the request by the vSEPP, the request including the verified information concerning the NFc is transmitted to a hSEPP in the second network. After successful validation of the request by the hSEPP, the request is forwarded to a hNRF in the second network where the NFp is registered. The hNRF serves the NFp. The hNRF authorizes the NFc based on the verified information in the request. If the NFc is authorized, the hNRF generates the access token and provide the access token to the NFc.

According to the embodiments of the present disclosure, the hNRF can trust the NFc related information available in the access token request coming from the vNRF and vSEPP without knowing the NF profile of the NFc. In this way, the NFc can be authorized to the NFp in inter-network scenario.

<FIG> illustrates an interaction diagram of an example process <NUM> for obtaining an access token through inter-network communication according to some example embodiments of the present disclosure. As shown in <FIG>, the process <NUM> may involve the NFc <NUM>, the vNRF <NUM>, the vSEPP <NUM>, the hSEPP <NUM>, and the hNRF <NUM> as shown in <FIG>.

In some example embodiments, a registration procedure may be performed <NUM> between the NFc <NUM> and the vNRF <NUM>, which is located in the same network as the NFc <NUM>. In other words, the NFc <NUM> acting as an OAuth2. <NUM> client is registered with the vNRF <NUM> acting as an authorization server in the first network <NUM>. Alternatively, in some example embodiments, the NFc <NUM> may not register in the vNRF <NUM>.

The NFc <NUM> expects to access a service provided by the NFp <NUM> in the network <NUM>. Accordingly, the NFc <NUM> transmits <NUM> a request for an access token (which is also referred to as "access token request") to the vNRF <NUM>. The access token request includes information concerning the NFc <NUM> and information concerning the expected service from the NFp <NUM>. The information concerning the NFc <NUM> may comprise one or more parameters related to the NFc <NUM>, including but not limited to, a NF type, a PLMN ID, a SNPN ID, a NF set ID, a vendor ID, and a domain ID of the NFc <NUM>. The information concerning the expected service from the NFp <NUM> may include, but not limited to, the requested "scope", a NF Type, and a PLMN ID of the NFp <NUM>.

As an example, the NFc <NUM> may transmit the Nnrf_AccessToken_Get Request to the vNRF <NUM>. The Nnrf_ AccessToken_Get Request may include a NF Instance ID of the NFc <NUM>, the requested "scope" including the expected NF Service Name(s), a NF type of the NFc <NUM>, a home PLMN ID which is the PLMN ID of the NFp <NUM>, and a serving PLMN ID which is the PLMN ID of the NFc <NUM>, a vendor ID of the NFc <NUM>, and a domain ID (e.g., FQDN) of the NFc <NUM>. The Nnrf_AccessToken_Get Request may optionally include "additional scope" information (i.e. requested resources and requested actions (service operations) on the resources, a list of NSSAIs or a list of NSI IDs for the expected NF Service Producer instances, NF Set ID of the expected NFp, and a NF Type of the expected NFp instance.

Upon receiving the access token request, the vNRF <NUM> authenticates <NUM> the NFc <NUM> acting as the OAuth2. <NUM> client. Then, the vNRF <NUM> verifies <NUM> the information concerning the NFc <NUM> based on a NF profile of the NFc <NUM>. For example, the vNRF <NUM> may read the one or more parameters related to the NFc <NUM> from the access token request. The vNRF <NUM> may further verify whether the one or more parameters available in the access token request are matched with corresponding parameters in the NF profile of the NFc <NUM>.

The vNRF <NUM> adds the verified information concerning the NFc <NUM> into the access token request. The verified information may comprise the one or more parameters related to the NFc <NUM> and corresponding verification result. If a specific parameter in the access token request is matched with a corresponding parameter in the NF profile of the NFc <NUM>, the verification result can be represented by "true" or "yes". If the specific parameter in the access token request is not matched with the corresponding parameter in the NF profile of the NFc <NUM>, the verification result can be represented by "false" or "no".

The verified information concerning the NFc <NUM> may comprise the NF type of the NFc <NUM> and a verification result of the NF type. Alternatively, or in addition, the verified information may comprise the PLMN ID of the NFc <NUM> and a verification result of the PLMN ID. For example, the PLMN ID may be an ID of the first network <NUM>. Alternatively, or in addition, the verified information may comprise the SNPN ID of the NFc <NUM> and a verification result of the SNPN ID. Alternatively, or in addition, the verified information may comprise the NF set ID of the NFc <NUM> and a verification result of the NF set ID. Alternatively, or in addition, the verified information may comprise the service set ID of the NFc <NUM> and a verification result of the service set ID. Alternatively, or in addition, the verified information may comprise the vendor ID of the NFc <NUM> and a verification result of the vendor ID. Alternatively, or in addition, the verified information may comprise the domain ID of the NFc <NUM> and a verification result of the domain ID. For example, the domain ID may be a FQDN of the NFc <NUM>.

It is to be understood that the above parameters related to the NFc <NUM> are given for the purpose of illustration without any limitation, and there can be more parameters of the NFc <NUM> which can be added here. The verified information concerning the NFc <NUM> can comprise any suitable parameter related to the NFc <NUM> and a respective verification result. The verification results indicate that the vNRF <NUM> has validated the parameters via the NF profile of the NFc <NUM>. In this way, a higher level of confidence can be provided to the vSEPP <NUM>.

In some example embodiments, the vNRF <NUM> may generate a header comprising the verified information and add the header into the access token request. For example, a custom header named "3GPP_SBI_NFc" may be added into the access token request by the vNRF <NUM>. The custom header may include one or more fields representing the one or more parameters related to the NFc <NUM> and corresponding verification results. Table <NUM> shows example fields of the custom header.

As shown in Table <NUM>, the "3GPP_SBI_NFc_Requester_PLMNID" field represents a value "xyz" of the PLMN ID of the NFc <NUM> and its verification result "True" or "False". The "3GPP_SBI_NFc_Requester_SNPN_ID" field represents a value "ijk" of the SNPN ID of the NFc <NUM> and its verification result "True" or "False". The "3GPP_SBI_NFc_Requester_NFtype" field represents a value "nft" of the NF type of the NFc <NUM> and its verification result "True" or "False". The "3GPP_SBI_NFc_Requester_RequestSetId" field represents a value "abc" of the NF set ID of the NFc <NUM> and its verification result "True" or "False". The "3GPP_SBI_NFc_Requester_RequestServiceSetId" field represents a value "bcd" of the service set ID of the NFc <NUM> and its verification result "True" or "False". The "3GPP_SBI_NFc_Requester_Vendor_ID" field represents a value "jkl" of the vendor ID of the NFc <NUM> and its verification result "True" or "False". The "3GPP_SBI_NFc_Requester_Domain_ID" field represents a value "klm" of the domain ID of the NFc <NUM> and its verification result "True" or "False".

It is to be understood that the above field shown in Table <NUM> are given for the purpose of illustration without any limitation. The header can comprise any suitable field to represent the one or more parameters related to the NFc <NUM>. It is also to be understood that more than one header may be used.

Continuing with the process <NUM>, the vNRF <NUM> transmits <NUM> the access token request with the verified information concerning the NFc <NUM> to the vSEPP <NUM> located at the edge of the first network <NUM>. For example, the vNRF <NUM> may transmit the access token request comprising the header "3GPP_SBI_NFc" to the vSEPP <NUM>.

The vSEPP <NUM> validates <NUM> the access token request received from the vNRF <NUM>. Specifically, the vSEPP <NUM> validates the verified information in the access token request based on configurations allowed to access services provided by other networks. For example, the allowed configurations may be specified by an operator policy for the first network <NUM>.

In some example embodiments, the operator policy may specify a configuration of allowed NF types. That is, a NFc of an allowed NF type can access services from another network. For example, the operator policy may specify that an Access and Mobility Management Function (AMF) in the local network (which is the first network <NUM>) is allowed to access a Unified Data Management (UDM) in a remote network, for example, the second network <NUM>. As another example, the operator policy may specify that an Authentication Server Function (AUSF) in the local network is not allowed to access the UDM in the remote network.

Alternatively, or in addition, in some example embodiments, the operator policy may specify a configuration of allowed home PLMN IDs. For example, a list of the allowed home PLMN IDs may be maintained by the vSEPP <NUM>. If the home PLMN ID comprised in the access token request is matched with an entry in the list of the allowed home PLMN IDs, the NFc <NUM> may be allowed to access the service of the NFp <NUM>.

Alternatively, or in addition, in some example embodiments, the operator policy may specify a configuration of allowed home SNPN IDs. For example, a list of the allowed home SNPN IDs may be maintained by the vSEPP <NUM>. If the home SNPN ID comprised in the access token request is matched with an entry in the list of the allowed home SNPN IDs, the NFc <NUM> may be allowed to access the service of the NFp <NUM>.

Alternatively, or in addition, in some example embodiments, the operator policy may specify a configuration of allowed NF set IDs. For example, in the case where the access token request comprises a NF set ID of the NFc <NUM>, a list of the allowed NF set IDs may be maintained by the vSEPP <NUM>. If the NF set ID of the NFc <NUM> comprised in the access token request is matched with an entry in the list of the allowed NF set IDs, the NFc <NUM> may be allowed to access the service of the NFp <NUM>.

Alternatively, or in addition, in some example embodiments, the operator policy may specify a configuration of allowed service set IDs. For example, in the case where the access token request comprises a service set ID of the NFc <NUM>, a list of the allowed service set IDs may be maintained by the vSEPP <NUM>. If the service set ID of the NFc <NUM> comprised in the access token request is matched with an entry in the list of the allowed service set IDs, the NFc <NUM> may be allowed to access the service of the NFp <NUM>.

Alternatively, or in addition, in some example embodiments, the operator policy may specify a configuration of allowed vendor IDs. For example, in the case where the access token request comprises a vendor ID of the NFc <NUM>, a list of the allowed vendor IDs may be maintained by the vSEPP <NUM>. If the vendor ID of the NFc <NUM> comprised in the access token request is matched with an entry in the list of the allowed vendor IDs, the NFc <NUM> may be allowed to access the service of the NFp <NUM>.

Alternatively, or in addition, in some example embodiments, the operator policy may specify a configuration of allowed domain IDs. For example, in the case where the access token request comprises a domain ID of the NFc <NUM>, a list of the allowed domain IDs may be maintained by the vSEPP <NUM>. If the domain ID of the NFc <NUM> comprised in the access token request is matched with an entry in the list of the allowed domain IDs, the NFc <NUM> may be allowed to access the service of the NFp <NUM>.

It is to be understood that the above allowed configurations are given for the purpose of illustration without any limitation. The vSEPP <NUM> can validate the access token request based on any suitable allowed configuration, for example, as specified by the operator policy. Alternatively, to validate the access token request, the vSEPP <NUM> can read a required parameter (for example, the home PLMN ID, home SNPN ID, etc.) from the access token request. A parameter required to validate the access token request can be obtained from the customer header, or a body of the request, or both.

A successful validation of the access token request by the vSEPP <NUM> can be defined in any suitable manner. As an example, if all configurations indicated by the parameters in the access token request belong to the allowed configurations specified by the operator policy, the validation of the access token request is successful. In other words, in this case, if a configuration indicated by indicated by the parameters in the access token request does not belong to the allowed configurations, the validation of the access token request is unsuccessful. As another example, if a threshold number of configurations indicated by the parameters in the access token request belong to the allowed configurations the validation of the access token request is successful. The protection scope of the present disclosure is not limited in the definition of successful validation of the access token request.

If the validation of the access token request by the vSEPP <NUM> is unsuccessful, it means that the NFc <NUM> is not allowed to access the expected service. In this case, the vSEPP <NUM> may provide a rejection response to the NFc <NUM> to indicate that the access token request is rejected. Specifically, the vSEPP <NUM> may transmit the rejection response to the vNRF <NUM>, which forwards the rejection response to the NFc <NUM>.

If the validation of the access token request by the vSEPP <NUM> is successful, the vSEPP <NUM> transmits <NUM> the access token request with the verified information concerning the NFc <NUM> to the hSEPP <NUM> located at the edge of the second network <NUM>. For example, the vSEPP <NUM> may transmit the access token request comprising the header "3GPP_SBI_NFc" to the hSEPP <NUM>.

In some example embodiments, the vSEPP <NUM> may sign the verified information. For example, the vSEPP <NUM> may generate a signature based on the verified information and transmit the access token request comprising the verified information and the signature of the vSEPP <NUM>. In the case where the verified information is comprised in the custom header, the vSEPP <NUM> may sign the custom header.

Signing the verified information by the vSEPP <NUM> ensures that the content provided by the vNRF <NUM> is validated by the vSEPP <NUM>. Since the vSEPP <NUM> and the hSEPP <NUM> have a trust relation by N32 security, the vSEPP <NUM> and the hSEPP <NUM> are the end-to-end security points in the roaming scenario. Thus, information received from the vSEPP <NUM> is to be trusted by the hSEPP <NUM>.

In some example embodiments, upon receiving the access token request, the hSEPP <NUM> may validate <NUM> the access token request. Specifically, the hSEPP <NUM> validates the verified information in the access token request based on configurations allowed to access services provided by the second network <NUM>. For example, the allowed configurations may be specified by an operator policy for the second network <NUM>.

In some example embodiments, the operator policy may specify a configuration of allowed NF types. That is, a NFc of an allowed NF type can access the services provided by the second network <NUM>. For example, the operator policy may specify that an AMF in another network (which is the first network <NUM>) is allowed to access a UDM in the second network <NUM>. As another example, the operator policy may specify that an AUSF in the other network is not allowed to access the UDM in the second network <NUM>.

Alternatively, or in addition, in some example embodiments, the operator policy may specify a configuration of allowed visited PLMN IDs. For example, a list of the allowed visited PLMN IDs may be maintained by the hSEPP <NUM>. If the PLMN ID of the NFc <NUM> comprised in the access token request is matched with an entry in the list of the allowed visited PLMN IDs, the NFc <NUM> may be allowed to access the service of the NFp <NUM>.

Alternatively, or in addition, in some example embodiments, the operator policy may specify a configuration of allowed visited SNPN IDs. For example, a list of the allowed home SNPN IDs may be maintained by the hSEPP <NUM>. If the SNPN ID of the NFc <NUM> comprised in the access token request is matched with an entry in the list of the allowed visited SNPN IDs, the NFc <NUM> may be allowed to access the service of the NFp <NUM>.

Alternatively, or in addition, in some example embodiments, the operator policy may specify a configuration of allowed NF set IDs. For example, in the case where the access token request comprises a NF set ID of the NFc <NUM>, a list of the allowed NF set IDs may be maintained by the hSEPP <NUM>. If the NF set ID of the NFc <NUM> comprised in the access token request is matched with an entry in the list of the allowed NF set IDs, the NFc <NUM> may be allowed to access the service of the NFp <NUM>.

Alternatively, or in addition, in some example embodiments, the operator policy may specify a configuration of allowed service set IDs. For example, in the case where the access token request comprises a service set ID of the NFc <NUM>, a list of the allowed service set IDs may be maintained by the hSEPP <NUM>. If the service set ID of the NFc <NUM> comprised in the access token request is matched with an entry in the list of the allowed service set IDs, the NFc <NUM> may be allowed to access the service of the NFp <NUM>.

Alternatively, or in addition, in some example embodiments, the operator policy may specify a configuration of allowed vendor IDs. For example, in the case where the access token request comprises a vendor ID of the NFc <NUM>, a list of the allowed vendor IDs may be maintained by the hSEPP <NUM>. If the vendor ID of the NFc <NUM> comprised in the access token request is matched with an entry in the list of the allowed vendor IDs, the NFc <NUM> may be allowed to access the service of the NFp <NUM>.

Alternatively, or in addition, in some example embodiments, the operator policy may specify a configuration of allowed domain IDs. For example, in the case where the access token request comprises a domain ID of the NFc <NUM>, a list of the allowed domain IDs may be maintained by the hSEPP <NUM>. If the domain ID of the NFc <NUM> comprised in the access token request is matched with an entry in the list of the allowed domain IDs, the NFc <NUM> may be allowed to access the service of the NFp <NUM>.

It is to be understood that the above allowed configurations are given for the purpose of illustration without any limitation. The hSEPP <NUM> can validate the access token request based on any suitable allowed configuration, for example, as specified by the operator policy.

Similar to the vSEPP <NUM>, a successful validation of the access token request by the hSEPP <NUM> can be defined in any suitable manner. The protection scope of the present disclosure is not limited in this regard.

If the validation of the access token request by the hSEPP <NUM> is unsuccessful, it means that the NFc <NUM> is not allowed to access the expected service. In this case, the hSEPP <NUM> may provide a rejection response to the NFc <NUM> to indicate that the access token request is rejected. Specifically, the rejection response can be forwarded to the NFc <NUM> via the hSEPP <NUM> and the vNRF <NUM>.

If the validation of the access token request by the hSEPP <NUM> is successful, the hSEPP <NUM> transmits <NUM> the access token request with the verified information concerning the NFc <NUM> to the hNRF <NUM> in the second network <NUM>. For example, the hSEPP <NUM> may transmit the access token request comprising the custom header "3GPP_SBI_NFc" to the hNRF <NUM>. Alternately, in some example embodiments, the hSEPP <NUM> may transmit the access token request to the hNRF <NUM> without validation. For example, if the custom header is not used, the hSEPP <NUM> allows the access token request to the hNRF <NUM>.

In the example embodiments where the vSEPP <NUM> signs the verified information, the hSEPP <NUM> may validate the signature of the vSEPP <NUM>. In some example embodiments, if the signature of the vSEPP <NUM> is successfully validated, the hSEPP <NUM> may transmit the access token request without any signature to the hNRF <NUM>. That is, the hSEPP <NUM> may remove the signature of the vSEPP <NUM> from the access token request and rewrite the verified information without any signature. Such example embodiments are feasible because any element in the second network <NUM> trusts that data coming from the hSEPP <NUM> has been verified.

Alternatively, in some example embodiments, if the signature of the vSEPP <NUM> is successfully validated, the hSEPP <NUM> may sign the verified information. For example, the hSEPP <NUM> may generate another signature based on the verified information and transmit the access token request comprising the verified information and the signature of the hSEPP <NUM>. In the case where the verified information is comprised in the custom header, the hSEPP <NUM> may sign the custom header. In such example embodiments, signing the verified information by the hSEPP <NUM> can provide additional authenticity to the hNRF <NUM> receiving the access token request.

Upon receiving the access token request from the hSEPP <NUM>, the hNRF <NUM> authorizes the NFc <NUM> base on the verified information concerning the NFc <NUM> comprised in the access token request. In the example embodiments where the hSEPP <NUM> signs the verified information, the hNRF <NUM> may validate the signature of the hSEPP <NUM>. If the signature of the hSEPP <NUM> is successfully validated, the hNRF <NUM> authorizes the NFc <NUM>.

The hNRF <NUM> determines whether the NFc <NUM> is authorized to access the expected service from the NFp <NUM> based on the verified information concerning the NFc <NUM>. In this way, the NFc <NUM> even if located in a different network from the NFp <NUM> can be authorized without the NF profile of the NFc <NUM>.

If the NFc <NUM> is authorized to access the expected service, the hNRF <NUM> generates the access token and provides <NUM> the access token to the NFc <NUM>. For example, the hNRF <NUM> may transmit to the hSEPP <NUM> an access token response including the generated access token, which is then forwarded to the NFc <NUM> via the vSEPP <NUM> and the vNRF <NUM>. Although not shown, it is to be understood that if the NFc <NUM> is not authorized to access the expected service, the hNRF <NUM> may provide a rejection response or an error response to the NFc <NUM>.

In the example process <NUM>, the information concerning the NFc <NUM> is verified by the vNRF <NUM> and the verified information is added into the access token request by the vNRF <NUM>. In other words, the vNRF <NUM> modifies the access token request.

<FIG> illustrates an interaction diagram of another example process <NUM> for obtaining an access token through inter-network communication according to some example embodiments of the present disclosure. As shown in <FIG>, the process <NUM> may involve the NFc <NUM>, the vNRF <NUM>, the vSEPP <NUM>, the hSEPP <NUM>, and the hNRF <NUM> as shown in <FIG>. It is to be understood that acts with the same reference signs as in <FIG> are same as those described with reference to <FIG> and thus are not repeatedly described here.

In the example process <NUM>, the vNRF <NUM> does not verify the information concerning the NFc <NUM>. Instead, the vNRF <NUM> transmits <NUM> the access token request to the vSEPP <NUM>. That is, in the example process <NUM>, the vNRF <NUM> does not modify the access token request.

Upon receiving the access token request, the vSEPP <NUM> verifies <NUM> the information concerning the NFc <NUM> based on a NF profile of the NFc <NUM>. The NF profile of the NFc <NUM> can be obtained by any suitable manner, for example, received from the vNRF <NUM>. The information concerning the NFc <NUM> may comprise the one or more parameters related to the NFc <NUM>, as described above with reference to <FIG>. The vSEPP <NUM> may read the one or more parameters related to the NFc <NUM> from the access token request. The vSEPP <NUM> may further verify whether the one or more parameters available in the access token request are matched with corresponding parameters in the NF profile of the NFc <NUM>.

The vSEPP <NUM> adds the verified information concerning the NFc <NUM> into the access token request. As described with reference to <FIG>, the verified information may comprise the one or more parameters related to the NFc <NUM> and corresponding verification result and thus is not repeated here.

In some example embodiments, the vSEPP <NUM> may generate a header comprising the verified information and add the header into the access token request. For example, the custom header named "3GPP_SBI_NFc" as described above may be added into the access token request by the vSEPP <NUM>.

The vSEPP <NUM> validates <NUM> the access token request received from the vNRF <NUM>. Specifically, the vSEPP <NUM> validates the information concerning the NFc <NUM> comprised in the access token request based on configurations allowed to access services provided by other networks. For example, the allowed configurations may be specified by an operator policy for the first network <NUM>, as described with reference to <FIG>.

In the example process <NUM>, the information concerning the NFc <NUM> is verified by the vSEPP <NUM> and the verified information is added into the access token request by the vSEPP <NUM>. In other words, the vSEPP <NUM> modifies the access token request.

It is to be understood that in the processes <NUM> and <NUM>, the hSEPP <NUM> and the vSEPP <NUM> may communicate with each other via the N32 interface or the IPX node(s) <NUM>. In the case where the hSEPP <NUM> and the vSEPP <NUM> communicate with each other via the IPX node(s) <NUM>, the IPX node(s) <NUM> may merely forward the access token request without any modification.

As can be seen from the example processes <NUM> and <NUM>, information concerning the NFc is verified by the vNRF or the vSEPP and the verified information is added into the access token request to be received by the hNRF. Only after successful verification and validation, the access token request is forwarded to the hNRF. Such verification enables the hNRF to trust the NFc related information available in the access token request coming from the vNRF and the vSEPP without knowing the NF profile of the NFc. In this way, the NFc can be authorized to the NFp in the inter-network scenario.

More details of the example embodiments in accordance with the present disclosure will be described with reference to <FIG>.

<FIG> illustrates a flowchart of an example method <NUM> according to some example embodiments of the present disclosure. The method <NUM> can be implemented at a first edge protection proxy, for example, the vSEPP <NUM> as shown in <FIG>. It is to be understood that the method <NUM> may include additional blocks not shown and/or may omit some shown blocks, and the scope of the present disclosure is not limited in this regard.

At block <NUM>, the first edge protection proxy receives, in a first network <NUM>, a request for an access token from a NRF (for example, the vNRF <NUM>) in the first network <NUM>. The access token is to be used by a first NF (for example, the NFc <NUM>) in the first network <NUM> to request a service from a second NF (for example, the NFp <NUM>) in a second network <NUM>.

At block <NUM>, the first edge protection proxy validates the request based on configurations allowed to access services provided by networks different from the first network <NUM>. At block <NUM>, in accordance with a successful validation of the request, the first edge protection proxy transmits the request to a second edge protection proxy (for example, the hSEPP <NUM>) in the second network <NUM>. The transmitted request comprises verified information concerning the first NF.

In some example embodiments, validating the request comprises: determining, from the request, the verified information generated by the NRF; and validating the request based on the verified information and the configurations allowed to access services provided by networks different from the first network.

In some example embodiments, the method <NUM> further comprises: determining, from the request, information concerning the first NF; verifying the information concerning the first NF; and adding the verified information concerning the first NF into the request.

In some example embodiments, validating the request comprises: validating the request based on the information determined from the request and the configurations allowed to access services provided by networks different from the first network.

In some example embodiments, transmitting the request comprises: generating a signature of the first edge protection proxy based on the verified information; and transmitting the request comprising the verified information and the signature to the second edge protection proxy.

In some example embodiments, the verified information comprises at least one of: a NF type of the first NF and a verification result of the NF type, a PLMN identifier of the first NF and a verification result of the PLMN identifier, a SNPN identifier of the first NF and a verification result of the SNPN identifier, a NF set identifier of the first NF and a verification result of the NF set identifier, a service set identifier of the first NF and a verification result of the service set identifier, a vendor identifier of the first NF and a verification result of the vendor identifier, or a domain identifier of the first NF and a verification result of the domain identifier.

In some example embodiments, the configurations allowed to access services provided by networks different from the first network comprise at least one of: allowed NF types, allowed PLMN identifiers, allowed SNPN identifiers, allowed NF set identifiers, allowed service set identifiers, allowed vendor identifiers, or allowed domain identifiers.

In some example embodiments, the method <NUM> further comprises: in accordance with an unsuccessful validation of the request, transmitting to the NRF a response indicating a rejection of the request.

In some example embodiments, the verified information is comprised in a header of the request.

<FIG> illustrates a flowchart of an example method <NUM> according to some example embodiments of the present disclosure. The method <NUM> can be implemented at a second edge protection proxy, for example, the hSEPP <NUM> as shown in <FIG>. It is to be understood that the method <NUM> may include additional blocks not shown and/or may omit some shown blocks, and the scope of the present disclosure is not limited in this regard.

At block <NUM>, the second edge protection proxy receives, in a second network <NUM>, a request for an access token from a first edge protection proxy (for example, the vSEPP <NUM>) in a first network <NUM>. The access token is to be used by a first NF (for example, the NFc <NUM>) in the first network <NUM> to request a service from a second NF (for example, the NFp <NUM>) in the second network <NUM>. The request comprises verified information concerning the first NF.

At block <NUM>, the second edge protection proxy transmits the request to a NRF in the second network <NUM>. In some example embodiments, transmitting the request comprises: validating a first signature of the first edge protection proxy in the request; and in accordance with a successful validation of the first signature, transmitting the request without the first signature to the NRF.

In some example embodiments, transmitting the request without the first signature to the NRF comprises: generating a second signature of the second edge protection proxy based on the verified information; and transmitting the request comprising the verified information and the second signature to the NRF.

In some example embodiments, the second edge protection proxy validates the request based on verified information concerning the first NF and configurations allowed to access services provided by the second network <NUM>. In accordance with a successful validation of the request, the second edge protection proxy transmits the request to the NRF. In accordance with an unsuccessful validation of the request, the second edge protection proxy transmits to the first edge protection proxy a response indicating a rejection of the request.

<FIG> illustrates a flowchart of an example method <NUM> according to some example embodiments of the present disclosure. The method <NUM> can be implemented at a NRF, for example, the hNRF <NUM> as shown in <FIG>. It is to be understood that the method <NUM> may include additional blocks not shown and/or may omit some shown blocks, and the scope of the present disclosure is not limited in this regard.

At block <NUM>, the NRF receives, in a second network <NUM>, a request for an access token from an edge protection proxy (for example, the hSEPP <NUM>) in the second network <NUM>. The access token is to be used by a first NF (for example, the NFc <NUM>) in a first network <NUM> to request a service from a second NF (for example, the NFp <NUM>) in the second network <NUM>.

At block <NUM>, the NRF determines whether the first NF is authorized to access the requested service based on verified information concerning the first NF comprised in the request. At block <NUM>, in accordance with a determination that the first NF is authorized, the NRF provides the access token to the first NF.

In some example embodiments, the method <NUM> further comprises: validating a signature of the edge protection proxy in the request.

<FIG> illustrates a flowchart of an example method <NUM> according to some example embodiments of the present disclosure. The method <NUM> can be implemented at a NRF, for example, the vNRF <NUM> as shown in <FIG>. It is to be understood that the method <NUM> may include additional blocks not shown and/or may omit some shown blocks, and the scope of the present disclosure is not limited in this regard.

At block <NUM>, the NRF receives, in a first network <NUM>, a request for an access token from a first NF (for example, the NFc <NUM>) in the first network <NUM>. The access token is to be used by the first NF to request a service from a second NF (for example, the NFp <NUM>) in a second network <NUM>.

At block <NUM>, the NRF verifies information concerning the first NF comprised in the request based on a profile of the first NF. At block <NUM>, the NRF adds the verified information concerning the first NF into the request. At block <NUM>, the NRF transmits the request comprising the verified information to an edge protection proxy (for example, the vSEPP <NUM>) in the first network <NUM>.

In some example embodiments, an apparatus capable of performing the method <NUM> may comprise means for performing the respective steps of the method <NUM>. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

In some example embodiments, the apparatus capable of performing the method <NUM> comprises: means for receiving, at a first edge protection proxy in a first network, a request for an access token from a network repository function in the first network, the access token to be used by a first network function in the first network to request a service from a second network function in a second network; means for validating the request based on configurations allowed to access services provided by networks different from the first network; and means for in accordance with a successful validation of the request, transmitting the request to a second edge protection proxy in the second network, the transmitted request comprising verified information concerning the first network function.

In some example embodiments, the means for validating the request comprises: means for determining, from the request, the verified information generated by the network repository function; and means for validating the request based on the verified information and the configurations allowed to access services provided by networks different from the first network.

In some example embodiments, the apparatus capable of performing the method <NUM> further comprises: means for determining, from the request, information concerning the first network function; means for verifying the information concerning the first network function based on a profile of the first network function; and means for adding the verified information concerning the first network function into the request.

In some example embodiments, the means for validating the request comprises: means for validating the request based on the information determined from the request and the configurations allowed to access services provided by networks different from the first network.

In some example embodiments, the means for transmitting the request comprises: means for generating a signature of the first edge protection proxy based on the verified information; and means for transmitting the request comprising the verified information and the signature to the second edge protection proxy.

In some example embodiments, the apparatus capable of performing the method <NUM> further comprises means for in accordance with an unsuccessful validation of the request, transmitting to the network repository function a response indicating a rejection of the request.

In some example embodiments, the apparatus capable of performing the method <NUM> comprises: means for receiving, at a second edge protection proxy in a second network, a request for an access token from a first edge protection proxy in a first network, the access token to be used by a first network function in the first network to request a service from a second network function in the second network, the request comprising verified information concerning the first network function; and means for transmitting the request to a network repository function in the second network.

In some example embodiments, the means for transmitting the request comprises: means for validating a first signature of the first edge protection proxy in the request; and means for in accordance with a successful validation of the first signature, transmitting the request without the first signature to the network repository function.

In some example embodiments, the means for transmitting the request without the first signature to the network repository function comprises: means for generating a second signature of the second edge protection proxy based on the verified information; and means for transmitting the request comprising the verified information and the second signature to the network repository function.

In some example embodiments, the means for transmitting the request comprises: means for validating the request based on the verified information and configurations allowed to access services provided by the second network; and means for in accordance with a successful validation of the request, transmitting the request to the network repository function in the second network.

In some example embodiments, the apparatus capable of performing the method <NUM> further comprises means for in accordance with an unsuccessful validation of the request, transmitting to the first edge protection proxy a response indicating a rejection of the request.

In some example embodiments, the apparatus capable of performing the method <NUM> comprises: means for receiving, at a network repository function in a second network, a request for an access token from an edge protection proxy in the second network, the access token to be used by a first network function in a first network to request a service from a second network function in the second network; means for determining whether the first network function is authorized to access the requested service based on verified information concerning the first network function comprised in the request; and means for in accordance with a determination that the first network function is authorized, providing the access token to the first network function.

In some example embodiments, the apparatus capable of performing the method <NUM> further comprises: validating a signature of the edge protection proxy in the request.

In some example embodiments, the apparatus capable of performing the method <NUM> comprises: means for receiving, at a network repository function in a first network, a request for an access token from a first network function in the first network, the access token to be used by the first network function to request a service from a second network function in a second network; means for verifying information concerning the first network function comprised in the request based on a profile of the first network function; means for adding the verified information concerning the first network function into the request; and means for transmitting the request comprising the verified information to an edge protection proxy in the first network.

<FIG> is a simplified block diagram of a device <NUM> that is suitable for implementing embodiments of the present disclosure. For example, the NFc <NUM>, the NFp <NUM>, the vNRF <NUM>, the hNRF <NUM>, the vSEPP <NUM> and/or the hSEPP <NUM> can be implemented by the device <NUM>. As shown, the device <NUM> includes one or more processors <NUM>, one or more memories <NUM> coupled to the processor <NUM>, and one or more communication modules <NUM> coupled to the processor <NUM>.

In some embodiments, the program <NUM> may be tangibly contained in a computer readable medium which may be included in the device <NUM> (such as in the memory <NUM>) or other storage devices that are accessible by the device <NUM>.

It should be appreciated that future networks may utilize network functions virtualization (NFV) which is a network architecture concept that proposes virtualizing network node functions into "building blocks" or entities that may be operationally connected or linked together to provide services. A virtualized network function (VNF) may comprise one or more virtual machines running computer program codes using standard or general type servers instead of customized hardware. Cloud computing or data storage may also be utilized. In radio communications, this may mean node operations to be carried out, at least partly, in a central/centralized unit, CU, (e.g. server, host or node) operationally coupled to distributed unit, DU, (e.g. a radio head/node). It should also be understood that the distribution of labour between core network operations and base station operations may vary depending on implementation.

In an embodiment, the server may generate a virtual network through which the server communicates with the distributed unit. In general, virtual networking may involve a process of combining hardware and software network resources and network functionality into a single, software-based administrative entity, a virtual network. Such virtual network may provide flexible distribution of operations between the server and the radio head/node. In practice, any digital signal processing task may be performed in either the CU or the DU and the boundary where the responsibility is shifted between the CU and the DU may be selected according to implementation.

Therefore, in an embodiment, a CU-DU architecture is implemented. In such case the device <NUM> may be comprised in a central unit (e.g. a control unit, an edge cloud server, a server) operatively coupled (e.g. via a wireless or wired network) to a distributed unit (e.g. a remote radio head/node). That is, the central unit (e.g. an edge cloud server) and the distributed unit may be stand-alone apparatuses communicating with each other via a radio path or via a wired connection. Alternatively, they may be in a same entity communicating via a wired connection, etc. The edge cloud or edge cloud server may serve a plurality of distributed units or a radio access networks. In an embodiment, at least some of the described processes may be performed by the central unit. In another embodiment, the device <NUM> may be instead comprised in the distributed unit, and at least some of the described processes may be performed by the distributed unit.

In an embodiment, the execution of at least some of the functionalities of the device <NUM> may be shared between two physically separate devices (DU and CU) forming one operational entity. Therefore, the apparatus may be seen to depict the operational entity comprising one or more physically separate devices for executing at least some of the described processes. In an embodiment, such CU-DU architecture may provide flexible distribution of operations between the CU and the DU. In practice, any digital signal processing task may be performed in either the CU or the DU and the boundary where the responsibility is shifted between the CU and the DU may be selected according to implementation. In an embodiment, the device <NUM> controls the execution of the processes, regardless of the location of the apparatus and regardless of where the processes/functions are carried out.

The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer readable storage medium. The computer program product includes computer-executable instructions, such as those included in program modules, being executed in a device on a target real or virtual processor, to carry out the method <NUM>, <NUM>, <NUM> or <NUM> as described above with reference to <FIG>. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.

Claim 1:
An apparatus (<NUM>) comprising:
at least one processor; and
at least one memory including computer program code;
the at least one memory and the computer program codes are configured to, with the at least one processor, cause the apparatus comprising a first edge protection proxy in a first network (<NUM>) to:
receive (<NUM>) a request for an access token from a network repository function (<NUM>) in the first network, the access token to be used by a first network function (<NUM>) in the first network to request a service from a second network function (<NUM>) in a second network (<NUM>);
validate (<NUM>) the request based on configurations allowed to access services provided by networks different from the first network; and
in accordance with a successful validation of the request, transmit (<NUM>) the request to a second edge protection proxy (<NUM>) in the second network, the transmitted request comprising verified information concerning the first network function (<NUM>).