FIELD

The present invention relates to inter-mobile network communications security, and in particular authentication of service entities in inter-mobile communications.

BACKGROUND

Network elements or functions located in different Public Land Mobile Networks (PLMNs) may need to communicate for roaming mobile devices. There may be various actors in interconnection network trying to track users, listen to traffic, etc. Specific edge security network entities, such as security proxies, may be arranged at the perimeter of a PLMN network to protect the PLMN from outside messages (inbound) and provide additional security services for the inter-PLMN communication between the network elements or functions at the different PLMNs. Web-based communication, such as Hypertext Transfer Protocol Secure (HTTP(S)), may be applied between the network entities in the different PLMNs, as well as between the network functions and the edge security entities. Security of the messages needs to be ensured for various inter-PLMN service scenarios. Network function service logic may need to perform authorization of a network function resource request from another PLMN.

SUMMARY

The invention is defined by the features of the independent claims. Some specific embodiments are defined in the dependent claims.

According to a first aspect, there is provided a method, comprising: receiving a first request from a service-consuming first network entity in the first mobile network or a proxy entity acting on behalf of the first network entity in the first mobile network, generating, in response to the first request and authentication of the first network entity, a security token comprising information for authenticating the first network entity in the second mobile network for accessing a service-providing second network entity in the second mobile network, and transmitting, to the first network entity or the proxy entity, the security token for requesting access to the second network entity. According to a second aspect, there is provided a method, comprising: transmitting a first request to a first discovery entity of a first mobile network, receiving a security token comprising information for authenticating the first network entity in a second mobile network for accessing a service-providing second network entity in the second mobile network, and transmitting an access request for accessing the second network entity, the access request comprising the security token.

According to a third aspect, there is provided a method, comprising: receiving an access request for a service-providing second network entity in the second mobile network by a service-consuming first network entity in a first mobile network, the access request comprising a security token generated by a first discovery entity in the first mobile network, the security token comprising information for authenticating the first network entity in the second mobile network for accessing the second network entity, authenticating the first network entity on the basis of the security token, and transmitting a response message indicative of the authentication to the first mobile network.

According to some further aspects, there is provided an apparatus, comprising at least one processor, at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processor, cause the apparatus at least to perform the method of the first aspect, the second aspect, or the third aspect, or an embodiment thereof.

According to a third aspect, there is provided a computer program product, a computer readable medium, or a non-transitory computer readable medium comprising program instructions for causing an apparatus to perform the method according to any one of the above aspects or embodiments thereof.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGURE 1 illustrates an example system capable of supporting at least some embodiments of the present invention;

FIGURES 2 to 4 illustrate methods in accordance with at least some embodiments; FIGURE 5 is a signalling example in accordance with some embodiments; and

FIGURE 6 illustrates an apparatus in accordance with at least some embodiments.

EMBODIMENTS

FIGURE 1 illustrates a system 100 of an example embodiment. The system comprises two PLMNs 110, 112 equipped with a Network Function (NF) 120, 122. A network function may refer to an operational and/or physical entity. The network function may be a specific network node or element, or a specific function or set of functions carried out by one or more entities, such as virtual network elements. Examples of such network functions include a (radio) access or resource control or management function, session management or control function, interworking, data management or storage function, authentication function or a combination of one or more of these functions.

In case of a Third Generation Partnership Project (3GPP) 5G system Service Based Architecture (SBA), core network NFs may comprise at least some of an Access and Mobility Function (AMF), a Session Management Function (SMF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Repository Function (NRF), Unified Data Management (UDM), Authentication Server Function (AUSF), Policy Control Function (PCF), and Application Function (AF). The PFMNs each further comprise a Security Edge Protection Proxy (SEPP) 130, 132 configured to operate as a security edge node or gateway.

The SEPP 130, 132 is a network node at the boundary of an operator's network that receives a message, such as an HTTP request or HTTP response from the NF, applies protection for sending, and forwards the reformatted message through a chain of intermediate nodes, such as IP exchanges (IPX) towards a receiving SEPP. The receiving SEPP receives a message sent by the sending SEPP and forwards the message towards an NF within its operator’s network, e.g. the AUSF. The message can alternatively be sent towards another network function of the second network. The two SEPPs 130, 132 may also communicate with each other, e.g., regarding their mutual connections. The SEPP 130, 132 may be configured to act as a non-transparent proxy node. The SEPP may be configured to protect application layer control plane messages between the NFs 120, 122 belonging to the different PLMNs and use the N32 interface to communicate with each other.

The inter-PLMN interconnect allows secure communication between a service-consuming NF e.g. in a visited PLMN (VPLMN) and a service-producing NL e.g. in a home PLMN (HPLMN), henceforth referred to as cNL 120 and pNL 122 (could also be NLc and NLp), respectively. Security is enabled by the SEPPs of both networks, which may be referred to as cSEPP and pSEPP, respectively.

If there are no IPX entities between the pSEPP 132 and the cSEPP 130, TLS may be used between the SEPPs. If there are IPX entities between the pSEPP and the cSEPP, application layer security on the N32 interface between SEPPs may be applied for protection between the pSEPP and the cSEPP, referred also to as PRotocol for N32 INterconnect Security (PRINS). An N32-c connection is a TLS based connection for N32 interface management and may be established between the pSEPP and the cSEPP for security capability negotiation by N32 handshake procedure and exchange of protected HTTP messages.

A Service Communication Proxy (SCP) may be deployed for indirect communication between network functions. An SCP may be deployed in VPLMN and/or in home HPLMN) or in within both VPLMN and HPLMN. For simplicity, the SCP 150 is illustrated only in PLMN 110. SCP does not expose services itself.

Direct communication may be applied between cNF 120 and pNF 122 for an NF service, or NF service communication may be performed indirectly via SCP(s). In Direct Communication, the cNF 120 performs discovery of the target pNF 122 by local configuration or via local NRF, cNRF 140. The cNF 120 may delegate the discovery of the target NFp 122 to the SCP 150 used for Indirect Communication. In the latter case, the SCP uses the parameters provided by NFc 120 to perform discovery and/or selection of the target NF Service producer. The SCP address may be locally configured in cNF 120.

NF discovery and NF service discovery enable core network entities (cNF or SCP) to discover a set of NF instance(s) and NF service instance(s) for a specific NF service or an NF type. Network Repository Function (NRF) is a function that is used to support the functionality of NF and NF service discovery and status notification. The NRF maintains NF profile of available NF instances and their supported services. The NRF may notify about newly registered, updated, or deregistered NF instances along with its NF services to a subscribed cNF or SCP.

In order for the cNF 120 or SCP 150 to obtain information about the NF and/or NF service(s) registered or configured in a PLMN/slice, the cNF 120 or SCP 150 may initiate, based on local configuration, a discovery procedure with the cNRF 140. The discovery procedure may be initiated by providing the type of the NF and optionally a list of the specific service(s) it is attempting to discover. The cNF 120 or SCP 150 may also provide other service parameters, such as slicing related information.

During an NF service discovery in inter-PLMN (roaming) communication, the cNF 120 may request service discovery from aNRF in its PLMN 110, i.e. the cNRF 140. The cNRF may send a discovery request to an NRF, referred herein as pNRF 142, in another PLMN 112, e.g. the home PLMN. The pNRF 142 in the other network 112 may respond with a discovery response which may be forwarded to the cNF via the cNRF 140 in the PLMN 110 of the cNF. Then the cNF may trigger service requests to the pNF via the cSEPP 130 and the pSEPP 132.

It is to be noted that at least some of the entities or nodes 120, 122, 130, 132, 140, 142 may act in both service-consuming and service-providing roles and that their structure may also be similar or identical, while their role in the present examples in delivery of a particular message is identified by use of the prefix “c” or “p” indicating whether they are acting for the service-consuming or service-producing NF. It is to be noted that instead of “c” and “p”, “v” for visited and “h” for home can be used to refer to respective entities in the visited and home PLMNs.

There is no direct authentication for a discovery entity in the service providing mobile network that can be utilized over the interconnection link between operators and PLMNs. A local network entity, in the example of Figure 1 the cNRF 140 providing service registration, authenticates a service consuming client or network entity, e.g. the cNF 120 in the same PLMN, and access to the service-providing network function pNF is controlled in the other PLMN (e.g. by the pNRF 142) based on implicit authentication, based on established trust between roaming partners/operators. There are now provided methods and apparatuses facilitating improved security level for inter-mobile network function service access between service-consuming network entity in a first mobile network and service-providing network entity in a second mobile network.

FIGURE 2 illustrates a method according to some embodiments. The method may be implemented by an apparatus performing a (first) discovery entity in a first mobile network, such as the cNRF of the PLMN 110. The discovery entity may refer to a network entity configured at least to facilitate discovery of network services, such as 5G SBA NF services.

The method comprises receiving 200 a first request from a service-consuming first network entity in the first mobile network, such as the cNRF 120, or a proxy entity acting on behalf of the first network entity in the first mobile network, such as the SCP 150.

Block 210 comprises generating, in response to the first request and authentication of the first network entity, a security token. The security token refers to an information element comprising information for authenticating the first network entity in the second mobile network for accessing a service-providing second network entity in the second mobile network, such as the pNF 122. The security token could alternatively be referred to as an authentication token or ID token, for example.

There may be one or more subsequent blocks between blocks 200 and 210, comprising verifying authentication credentials received from the first network entity in the first request or another message, and entering block 210 only upon successful verification of the authentication credentials. In some embodiments, the first network entity may already be earlier (pre-)authenticated, and an indication of such successfully performed (and still valid) authentication to the entity performing block 210 may suffice to allow generating the security token in block 210.

The security token for requesting access to the second network entity is transmitted 220, to the first network entity or the proxy entity. The security token may be transmitted in a message comprising information on target NF producer(s), such as identification information regarding the second network entity and/or the second discovery entity. The security token may be cryptographically protected before the transmission. It is preferable that the security token is at least integrity protected to prevent other parties from changing the contents. Further security level improvement can be achieved by encryption.

FIGURE 3 illustrates a method according to some embodiments. The method may be implemented by an apparatus performing a service-consuming first network entity or a proxy entity acting on behalf of the service-consuming first network entity in a first mobile network, such as the cNF 140 or a SCP (cSCP) 150 for the cNF of the PLMN 110.

The method comprises transmitting 300 a first request to a first discovery entity of a first mobile network, such as the cNRF 140. Block 310 comprises receiving a security token comprising information for authenticating the first network entity in a second mobile network for accessing a service-providing second network entity in the second mobile network. The security token may be received from the first discovery entity in response to the first request, in some embodiments in an NF discovery request response. An access request is transmitted 320 to the second mobile network for accessing the second network entity, the access request comprising the security token.

FIGURE 4 illustrates a method according to some embodiments. The method may be implemented by an apparatus performing a second discovery entity in a second mobile network, such as the pNRF of the PLMN 112.

The method comprises receiving 400 an access request for a service providing second network entity in the second mobile network by a service-consuming first network entity in a first mobile network. For example, the pNRF 142 may receive the access request from the cNF 120. The access request comprises a security token generated by a first discovery entity in the first mobile network. The security token comprises information for authenticating the first network entity in the second mobile network for accessing the second network entity.

The first network entity is authenticated 410 on the basis of the security token. The authentication may be preceded by one or more cryptographic validation or verification operations, in some embodiments integrity check, signature verification, and/or decryption. The first network entity may be authenticated 410 on the basis of validating or verifying one or more information elements of the security token. The authentication of the first network entity may comprise one or more security checks, which may include identifying the requesting first network entity, verifying one or more identification information elements in the security token and/or performing verification of an authentication code in the security token, for example.

A response message indicative of the authentication is transmitted 420 to the first mobile network. The response message may thus indicate if the authentication was successful or not. The response message may comprise an access token or other type of authorization information element for accessing the second network entity and some or all NF services thereof.

Presently disclosed features are applicable for direct and indirect communication scenarios. With reference to the example of Figure 1, in indirect communication scenario, a proxy entity, e.g. the SCP 150 may obtain access authorization on behalf of the first network entity, e.g. the cNF 120. The response message may be transmitted to the first network entity, the proxy entity acting on behalf of the first network entity in the first mobile network, or the first discovery entity, depending from which of these the access request was received.

Thus, by applying the security token, an NF consumer in a roaming partner network requesting an access for inter-PLMN service from an NF producer may be authenticated. It is to be appreciated that various modifications and additions may be implemented to the methods within the scope of the present claims. Some further example embodiments are illustrated below.

In addition to the authentication, an authorization procedure may be performed for the first request 200, 300 by the first discovery entity in response to receiving 200 the request. The authorization procedure may comprise operations to validate the request and confirming authority of the first network entity to obtain requested service indicated in the first request. The authorization may be based on an authorization policy and/or profile of requested NF/NF service. The policy/profile may identify available resources, allowed actions, and further scope of access restrictions or permissions, for example. The security token may be generated 210 for the first network entity in response to the authorization procedure being successfully performed. The authorization procedure may comprise performing or detecting authentication of the first network entity based on authentication credentials from the first network entity. The authentication may be based on lower-layer security procedures, such as transport layer authentication. For example, in the example of Figure 1, the cNRF 140 may authenticate the cNF 120 based on TLS procedure and a TLS certificate from the cNF, i.e. during TLS setup. If transport layer protection is not applied in the PLMN 110, the authentication may be implicit by Network Domain Security/IP (NDS/IP) or physical security procedure. However, it is to be appreciated that a specific, independent authentication may be arranged between the cNF 120 and the cNRF 140.

In some embodiments, the first request 200, 300 is a registration request for registering the first network entity to the first discovery entity. The security token may be generated 210 in response to successful registration of the first network entity. The security token may be included in a registration response from the first discovery entity to the first network entity. In this case, the security token may be more generic and not specific or associated to any particular network function/resource or discovery entity, such as a network slice or OAuth server in the second mobile network.

The security token may be specific to the first request, or a single request for discovering or accessing the service-providing second network entity. In another example embodiment, the security token may be used for multiple requests for accessing the second network entity, such as requests to the second discovery entity in the second mobile network.

The security token may comprise timing information indicative of issuance and/or expiry of security token. The security token may be short-lived, i.e. have a pre configured validity period, after which it is rejected. For example, validity of the security token may be bound to the lifetime of a TLS tunnel between the mobile networks. In another example embodiment, lifetime of the security token is dependent on lifetime of N32 interface handshake on security capability negotiation. The authenticating in block 410 may comprise verifying that the security token is not expired.

In some embodiments, the security token comprises audience identification information indicative of at least some of: the second discovery entity, the second network entity, one or more associated services of the second network entity, and associated network slice. For example, the security token may comprise a network function instance identifier of the first network entity and/or a node identifier, such as a fully qualified domain name (FQDN), of the first network entity. The audience may be thus an entity generating the access token, such as the pNRF 142 or an OAuth server. The authenticating in block 410 may thus comprise that the security token is associated with the first network entity and/or verifying that the security token is addressed to the second discovery entity and/or the second network entity.

For example, the security token may comprise at least some of the fields illustrated in the example token below:

It is to be appreciated that the security token and/or the messages comprising the security token may comprise further information in addition to some or all of the information elements indicated above. For example, the security token or the message carrying the security token may indicate requested or issued token type. The security token may be cryptographically protected (by the token-issuing first discovery entity) by one or more cryptographic methods. The token-receiving entity, such as the second discovery entity, e g. the pNRF 142, is configured to access and remove the protection to ensure validity of the security token.

In some embodiments, the security token is integrity-protected by the first discovery entity. The authentication procedure in 410 may thus comprise verifying integrity of the security token. In response to confirming that the integrity of the security token is not compromised, the second discovery entity may approve the access request, and e.g. generate an access token and transmit the response message comprising the access token.

In some embodiments, the security token is encrypted, e.g. by a secret key of the cNRF (or a key shared by cNRF and pNRF). When protected, it is assumed that the entity that processes the security token has an appropriate cryptographic key to verify the integrity of the token, or when encrypted, decrypt the security token. The security token transmitted 320, 400 between the mobile networks may be secured by applying at least some features applied for protecting access token via N32 interface when PRINS is applied or when IPX nodes are applied between SEPPs. It is to be noted that the security token may be further encrypted in the inter-mobile network interface, in the embodiment of Figure 1 by encryption applied over the N32 interface between the SEPPs 130, 132.

In a still further example embodiment, the authentication token comprises or is transmitted with a digital signature of the token-issuing first discovery entity. The authenticating in block 410 may thus comprise verifying a digital signature of the first discovery entity in the security token. In another embodiment, token introspection procedure may be applied for the security token. The second access node may be configured to use token introspection to verify and/or check validity of the security token in (or before) block 410.

However, it is to be appreciated that some or all of the cryptographic measures may be avoided, or selectively applied, depending on the trust level and potential further security mechanisms between the mobile networks in question.

In some embodiments, the first request in block 200, 300 is a discovery request for discovering the service-providing second network entity in the second mobile network for the first network entity, and the security token is included in a discovery response from the first discovery entity to the first network entity.

In some embodiments, the access request is an access token request and the response message is an access token response message. An access token is generated for accessing a resource of the second network entity in response to verifying the security token. The access token may be included in the access token response message. The access token may comprise, or enable the receiving first network entity to obtain, appropriate access credentials for NF resources of the second network entity.

Reference is now made to signaling example of Figure 5, with references to 3GPP 5G SBA system, such as a system comprising the entities of Figure 1. The example procedure comprises (at least) two stages which may be separately performed.

In the first stage the cNF (120) or SCP (150) obtains a security token/ID token from the local NRF cNRF (140), which may be referred to as local caching. Thus, the cNF/SCP transmits an NF discovery request 510 (as the first request of block 200, 300) to the cNRF, such as a Nnrf NFDiscovery Request. The request 510 may be transmitted upon an incoming trigger 500, such as a request from another network node or function regarding a roaming UE, or in the case of SCP upon trigger from the cNF.

The cNRF performs authorization procedure 512 for the requested NF (service) discovery. The cNRF may thus further define a set of NF instance(s) matching the discovery request 510. Based on a profile of the expected NF/NF service and the type of the cNF, the cNRF may thus determine whether the cNF is allowed to discover the expected NF instance(s). Block 512 may comprise authentication of the cNF, which may comprise checking that the cNF has been validly authenticated e.g. by lower-layer security procedure, as indicated earlier. For example, the cNRF 140 may perform cNF authentication at (or before) block 512, as a precondition for generating 514 the security token (and authorizing the discovery).

If the service discovery is authorized/allowed, the cNRF generates 514 the security token, by applying at least some of the features illustrated above. The cNRF transmits an NF discovery response 516, such as Nnrf_NFDiscovery_Response, comprising the security token and discovered NF information to the cNF/SCP. The security token or the discovery response 516 may be indicative of the authentication by the first network entity. The discovery response 516 may comprise further information regarding the NF discovery, such as an IP address or FQDN of the pNRF. The discovery response may comprise NF profiles of the pNRF. It is to be noted that in some embodiments the cNRF may need to communicate (not shown) with the other PLMN 120 and the pNRF thereof to obtain the required NF information. Thus, the cNRF may request NF discovery from the pNRF.

In some embodiments OAuth based authorization and token exchange is applied between the mobile networks. Thus, the second network entity, such as the pNRF, may be or perform an OAuth server. The cNF may be an OAuth client and the pNF may operate as OAuth resource server, and they may be configured to support OAuth authorization framework as defined in RFC 6749. At least some of the presently disclosed token exchange related operations may be based on OAuth token exchange, e.g. as defined in version 2.0 as disclosed in Ch. 2 of IETF Internet Draft, OAuth 2.0 Token Exchange draft- ietf-oauth-token-exchange-19, M. Jones et al, July 20, 2019. The access token may be an OAuth 2.0 access token. The security token may be specific to a particular OAuth server (which may be IdM Identity Management server) in the PLMN 120 in which the target NF producer pNRF is offering service. The cNRF may provide information on how to access the remote OAuth server in the PLMN 112, such as FQDN of the OAuth server, in the discovery response 516. OAuth token introspection may be applied for validating the security token by the pNRF.

In the second stage, the cNF or SCP requests access token from the remote NRF pNRF by an NF access token request 518, such as an Nnrf NFAccessToken Get Request. The security token may be included in a subject-token information element of the request 518, for example. The request may comprise further related NF information, such as the NF Instance Id(s) of the cNF, expected NF service name(s), NF type of the expected NF producer instance and NF consumer.

The cNRF authenticates 520 the cNF by validating the security token, by applying at least some of the features illustrated above. Upon successful authentication and authorization, the cNRF generates 522 an access token for the cNF to access the pNF service. The access token is transmitted to the cNF in an access token response, such as Nnrf NFAccessToken Get Response. Otherwise, it may respond by an error response, such as OAuth error response. The response may comprise further parameters, such as expiration time and allowed scope.

The cNF may store the received access token and transmit an NF service request 526 to the pNF to initiate inter-PLMN NF communication and service. The service request may comprise the access token. Stored access tokens may be re-used for accessing service(s) from producer NF type listed in claims (scope, audience) during their validity time. In an example embodiment, notifications are applied between NFs. At least some of the above disclosed features may be applied similarly in connection with other types of communications, in some embodiments inter-mobile network notifications. For example, a notification from the NFc to NFc (or vice versa) may be applied for indicating or comprising a security token and/or access token. A notification may be applied as a trigger for an action in a receiving NF. It is to be appreciated that there may be various alterations and other embodiments for the above-illustrated example procedures. For example, the cNF may transmit the access token request to the cNRF, which may forward the request to the pNRF.

In some embodiments, JSON Web Encryption, JWE, is applied between the mobile networks 110, 112. In case of 3GPP -based system, the JWE may be applied (at least) between cSEPP 130 and pSEPP 132 for protecting messages on the N32 interface. An N32- f connection may be established for transmitting JWE and JWS protected messages between the cSEPP 130 and pSEPP 132. A JSON Object Signing and Encryption (JOSE) header may thus comprise parameters describing cryptographic operations and parameters applied. In some embodiments, the security token is a JSON web token (JWT). Such JWT token may comprise at least some of the parameters disclosed in Ch. 4 of the OAuth 2.0 Token Exchange draft-ietf-oauth-token-exchange-19, M. Jones et al, July 20, 2019. However, it will be appreciated that various other token formats may be applied.

The NFs 120, 122 may be configured to support TLS, both server-side and client-side certificates. In direct communication scenario, the cNF 120 may setup a TLS connection with the cSEPP 130. The connection between the SEPPs 130, 132 and the respective NFs 120, 122 may be protected by TLS. Thus, the NFs may be configured to use HTTPS to send HTTP based messages to the remote NF in the other PLMN. HTTPS uses TLS to securely transmit HTTP messages between the NF and the SEPP. The messages may comprise HTTP Representational State Transfer (REST) Application Programming Interface (API) requests to an NF resource. The pSEPP 132 channels the HTTP REST API messages to the corresponding pNF 122. In the indirect communication scenario, the cNF 120 communicates via the SCP 150, which may act like a HTTPS proxy and does not break the tunnel.

As already indicated above, at least some of the above illustrated inter-mobile network authentication related features may be applied in systems applying network virtualization. Hence, network functions or nodes illustrated above may be shared between two physically separate devices forming one operational entity. 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. Network virtualization may involve platform virtualization, often combined with resource virtualization. Network virtualization may be categorized as external virtual networking which combines many networks, or parts of networks, into the server computer or the host computer. External network virtualization is targeted to optimized network sharing. Another category is internal virtual networking which provides network-like functionality to software containers on a single system. For example, instances of the 5G network functions can be instantiated as virtual network functions (VNFs) in network function virtualization (NFV) architecture. In a virtualized environment NFs are instantiated and when no longer needed ramped down. Each NF instance has an instance ID. At least some of the above-illustrated NFs may be applied as cloud-native VNFs with containers.

However, although references have been made above to 3 GPP 5G and SB A thereof, it will be appreciated that at least some of the above-illustrated features may be applied for communication between other types of mobile networks, such as future 6G or beyond generation PFMN core networks.

An electronic device comprising electronic circuitries may be an apparatus for realizing at least some embodiments of the present invention. The apparatus may be or may be comprised in a computer, a server, a proxy device, a network function hosting device, a network access device, network management device or another appropriately configured communications apparatus. In another embodiment, the apparatus carrying out the above- described functionalities is comprised in such a device, e.g. the apparatus may comprise a circuitry, such as a chip, a chipset, a microcontroller, or a combination of such circuitries configured to perform at least some of the above illustrated features.

As used in this application, the term “circuitry” may refer to one or more or all of the following:

(a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry) and

(b) combinations of hardware circuits and software, such as (as applicable):

(i) a combination of analog and/or digital hardware circuit(s) with software/firmware and

(ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.” This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

FIGURE 6 illustrates an example apparatus capable of supporting at least some embodiments of the present invention. Illustrated is a device 600, which may be arranged to carry out at least some of the embodiments related to arranging inter-PLMN communication as illustrated above. The device may include one or more controllers configured to carry out operations in accordance with at least some of the embodiments illustrated above, such as some or more of the features illustrated above in connection with Figures 2 to 5. The device may operate as the apparatus performing the first discovery entity and the method of Figure 2, the service-consuming first network entity or the proxy entity acting on behalf of the service-consuming first network entity and performing the method of Figure 3, or the second discovery entity, such as the cNRF 140, the cNF 120/SCP 150, or the pNRF 142, respectively.

Comprised in the device 600 is a processor 602, which may comprise, for example, a single- or multi-core processor wherein a single-core processor comprises one processing core and a multi-core processor comprises more than one processing core. The processor 602 may comprise more than one processor. The processor may comprise at least one application-specific integrated circuit, ASIC. The processor may comprise at least one field-programmable gate array, FPGA. The processor may be means for performing method steps in the device. The processor may be configured, at least in part by computer instructions, to perform actions. The device 600 may comprise memory 604. The memory may comprise random-access memory and/or permanent memory. The memory may comprise at least one RAM chip. The memory may comprise solid-state, magnetic, optical and/or holographic memory, for example. The memory may be at least in part accessible to the processor 602. The memory may be at least in part comprised in the processor 602. The memory 604 may be means for storing information. The memory may comprise computer instructions that the processor is configured to execute. When computer instructions configured to cause the processor to perform certain actions are stored in the memory, and the device in overall is configured to run under the direction of the processor using computer instructions from the memory, the processor and/or its at least one processing core may be considered to be configured to perform said certain actions. The memory may be at least in part comprised in the processor. The memory may be at least in part external to the device 600 but accessible to the device. For example, control parameters affecting operations related to the credentials management and associated information may be stored in one or more portions of the memory and used to control operation of the apparatus. Further, the memory may comprise device-specific cryptographic information, such as secret and public key of the device 600.

The device 600 may comprise a transmitter 606. The device may comprise a receiver 608. The transmitter and the receiver may be configured to transmit and receive, respectively, information in accordance with at least one wired or wireless, cellular or non- cellular standard. The transmitter may comprise more than one transmitter. The receiver may comprise more than one receiver. The transmitter and/or receiver may be configured to operate in accordance with global system for mobile communication, GSM, wideband code division multiple access, WCDMA, LTE, 5G, wireless local area network, WLAN, and/or Ethernet, for example. The device 600 may comprise a near-field communication, NFC, transceiver 610.

The device 600 may comprise user interface, UI, 612. The UI may comprise at least one of a display, a keyboard, a touchscreen, a speaker and a microphone. A user may be able to operate the device via the UI, for example to cause the device to perform at least some functions illustrated above, configure the operation of the device, and/or to manage digital files stored in the memory 604 or on a cloud accessible via the transmitter 606 and the receiver 608, or via the NFC transceiver 610. The device 600 may comprise or be arranged to accept a memory module 614, such as a user identity module or other type of memory module. The user identity module may comprise, for example, a personal identification IC card installable in the device 600.

The processor 602 may be furnished with a transmitter arranged to output information from the processor, via electrical leads internal to the device 600, to other devices comprised in the device. Such a transmitter may comprise a serial bus transmitter arranged to, for example, output information via at least one electrical lead to memory 604 for storage therein. Alternatively to a serial bus, the transmitter may comprise a parallel bus transmitter. Likewise the processor may comprise a receiver arranged to receive information in the processor, via electrical leads internal to the device 600, from other devices comprised in the device 600. Such a receiver may comprise a serial bus receiver arranged to, for example, receive information via at least one electrical lead from the receiver 608 for processing in the processor. Alternatively to a serial bus, the receiver may comprise a parallel bus receiver.

The device 600 may comprise further devices not illustrated in Figure 6. For example, some devices may lack the NFC transceiver 610 and/or the user identity module

614.

The processor 602, the memory 604, the transmitter 606, the receiver 608, the NFC transceiver 610, the UI 612 and/or the user identity module 614 may be interconnected by electrical leads internal to the device 600 in a multitude of different ways. For example, each of the aforementioned devices may be separately connected to a master bus internal to the device, to allow for the devices to exchange information. However, as the skilled person will appreciate, this is only one example and depending on the embodiment various ways of interconnecting at least two of the aforementioned devices may be selected without departing from the scope of the present invention.

It is to be understood that the embodiments of the invention disclosed are not limited to the particular structures, process steps, or materials disclosed herein, but are extended to equivalents thereof as would be recognized by those ordinarily skilled in the relevant arts. It should also be understood that terminology employed herein is used for the purpose of describing particular embodiments only and is not intended to be limiting. References throughout this specification to one embodiment or an embodiment means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. The skilled person will appreciate that above-illustrated embodiments may be combined in various ways. Embodiments illustrated in connection with Figures 2 to 6 may be taken in isolation or further combined together.

Various embodiments and examples of the present invention may be referred to herein along with alternatives for the various components thereof. It is understood that such embodiments, examples, and alternatives are not to be construed as de facto equivalents of one another, but are to be considered as separate and autonomous representations of the present invention.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the preceding description, numerous specific details are provided, such as examples of lengths, widths, shapes, etc., to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.

While the forgoing examples are illustrative of the principles of the present invention in one or more particular applications, it will be apparent to those of ordinary skill in the art that numerous modifications in form, usage and details of implementation can be made without the exercise of inventive faculty, and without departing from the principles and concepts of the invention. Accordingly, it is not intended that the invention be limited, except as by the claims set forth below.

The verbs “to comprise” and “to include” are used in this document as open limitations that neither exclude nor require the existence of also un-recited features. The features recited in depending claims are mutually freely combinable unless otherwise explicitly stated. Furthermore, it is to be understood that the use of "a" or "an", that is, a singular form, throughout this document does not exclude a plurality.