Patent Description:
Examples of the present disclosure are generally directed to a distributed security architecture that uses different nodes to securely protect control signaling at the network edge.

Particular examples of the present disclosure include a method implemented by a security relay node in a Public Land Mobile Network (PLMN). The method comprises receiving, from a Network Function, NF, within the PMLN, a control packet to be provided to a further PLMN and relaying the control packet to a remote security node for delivery of the control packet to the further PLMN. The remote security node is outside of both the PLMN and the further PLMN. The method further comprises relaying inbound control plane traffic, received from the further PLMN via the remote security node, to a destination within the PLMN.

In some examples, the method comprises the step of establishing a secure interface between the security relay node and the remote security relay node, preferably based on a standardized N32 interface, and wherein the step of relaying comprises relaying the control packet over the established secure interface.

In some examples, relaying the inbound and outbound data plane traffic comprises relaying using Transport Layer Security (TLS).

In some examples, the method further comprises, prior to the step of relaying the control packet, the step of encrypting at least an Information Element, IE, in the control packet.

The encrypting step may be performed using an encryption key of a peer security node of the further PLMN obtained via the remote security node. The peer security node may thus be comprised by the further PLMN.

The method may comprise the step of obtaining the encryption key of the peer security node from the remote security node.

In some example, the method further comprises exchanging, with the remote security node, control signaling associated with the secure interface. In some such embodiments, the secure interface is an N32-f interface and exchanging the control signaling comprises exchanging the control signaling via an N32 c interface to set up the N32-f interface. In other such embodiments, relaying the outbound and inbound control plane traffic via the secure interface comprises relaying the outbound and inbound control plane traffic via a TLS connection and exchanging the control signaling comprises exchanging the control signaling via the TLS connection.

In some examples, the method further comprises enabling discovery of the security relay node by at least one network function of the PLMN by registering with a Network Repository Function (NRF) of the PLMN as a Security Edge Protection Proxy (SEPP).

In some examples, the method further comprises hiding a topology of the PLMN from the further PLMN.

In some examples, the method further comprises using a telescopic fully qualified domain name of a network function in the PLMN to hide an address of the network function from the further PLMN.

In some examples, the method further comprises exchanging security certificates with the remote security node and relaying the inbound and outbound control plane traffic is responsive to authenticating the remote security node using a security certificate of the remote security node.

In some examples, the method further comprises encrypting an information element (IE) using an encryption key of a peer security node of the further PLMN obtained via the remote security node. The method further comprises transmitting the encrypted IE to the peer security node via the remote security node. In some such examples, the method further comprises obtaining the encryption key of the peer security node from the remote security node.

In some examples, the remote security node is comprised in an Internet Protocol Exchange (IPX) network. In some other embodiments, the remote security node is comprised in a roaming hub network.

Other examples include a security relay node comprising processing circuitry and a memory. The memory contains instructions executable by the processing circuitry whereby the security relay node is configured to, from within a Public Land Mobile Network (PLMN), relay outbound control plane traffic, received from a source within the PLMN, to a remote security node via a secure interface for delivery of the outbound control plane traffic to a further PLMN. The remote security node is outside of both the PLMN and the further PLMN. The security relay node is further configured to relay inbound control plane traffic, received from the further PLMN via the remote security node over the secure interface, to a destination within the PLMN.

In another example, security relay node comprising processing circuitry and a memory, the memory containing instructions executable by the processing circuitry whereby the security relay node is configured for, from within a Public Land Mobile Network, PLMN; receiving, from a Network Function, NF, within the PLMN, a control packet to be provided to a further PLMN; relaying said control packet to a remote security node for delivery of the control packet to the further PLMN, the remote security node being outside of both the PLMN and the further PLMN.

In some examples, the security relay node is further configured to perform any of the methods described above.

Other examples include a computer program, comprising instructions which, when executed on processing circuitry of a security relay node, cause the processing circuitry to carry out any of the methods described above.

Other embodiments include a carrier containing such a computer program. The carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

Yet other examples include a method implemented by a remote security node. The method comprises receiving, from a security relay node in a Public Land Mobile Network, PLMN, a control packet to be provided to a further PLMN, and relaying the control packet to the further PLMN, wherein the remote security node being outside of both the PLMN and the further PLMN.

IN some example, the method comprises the step of establishing a secure interface between the security relay node and the remote security relay node, preferably based on a standardized N32 interface, and wherein the step of receiving comprises receiving the control packet over the established secure interface.

In some examples, relaying any inbound and outbound control plane traffic comprises relaying using TLS.

In some example, the method comprises the step of receiving, the control packet in which at least an Information Element, IE, is encrypted.

The encryption may be performed using an encryption key of a peer security node of the further PLMN such that the remote security node is unable to decrypt it. The encryption key may be obtained from the peer security node of the further PLMN, and may be provided to the remote security node.

In some examples, the method further comprises exchanging, with the security relay node, control signaling associated with the secure interface. In some such embodiments, the secure interface is an N32-f interface and exchanging the control signaling comprises exchanging the control signaling via an N32-c interface to set up the N32-f interface. In other such embodiments, relaying the outbound and inbound control plane traffic via the secure interface comprises relaying the outbound and inbound control plane traffic via a TLS connection and exchanging the control signaling comprises exchanging the control signaling via the TLS connection.

In some examples, the method further comprises relaying further control plane traffic between the PLMN and an additional PLMN. The method further comprises isolating the inbound and outbound control plane traffic relaying between PLMN and the further PLMN from the further control plane traffic relayed between the PLMN and the additional PLMN.

In some examples, the method further comprises exchanging security certificates with the security relay node and relaying the inbound and outbound control plane traffic is responsive to authenticating the security relay node using a security certificate of the security relay node.

In some examples, the method further comprises receiving, from the security relay node, an information element (IE) encrypted with an encryption key of a peer security node of the further PLMN. The method further comprises forwarding the encrypted IE to the peer security node. In some such examples, the method further comprises encrypting a further IE with the encryption key of the peer security node and forwarding the encrypted further IE along with the encrypted IE to the peer security node. In some examples, the method additionally or alternatively comprises obtaining the encryption key of the peer security node from the peer security node and providing the encryption key of the peer security node to the security relay node.

In some embodiments, the remote security node is comprised in an Internet Protocol Exchange (IPX) network. In some other examples the remote security node is comprised in a roaming hub network.

Other examples include a remote security node comprising processing circuitry and a memory. The memory contains instructions executable by the processing circuitry whereby the security relay node is configured to relay outbound control plane traffic, received from a security relay node within a PLMN via a secure interface, to a further PLMN. The remote security node is outside of both the PLMN and the further PLMN. The security relay node is further configured to relay inbound control plane traffic, received from a source within the further PLMN, to the security relay node via the secure interface.

In some examples, the remote security node is further configured to perform any of the methods implemented by a remote security node described above.

Other examples include a computer program comprising instructions which, when executed on processing circuitry of a remote security node, cause the processing circuitry to carry out any one of the remote security node methods described above.

Other examples include a carrier containing such a computer program. The carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

Other examples are described in further detail below with respect to the accompanying figures.

Aspects of the present disclosure are illustrated by way of example and are not limited by the accompanying figures with like references indicating like elements. In general, the use of a reference numeral should be regarded as referring to the depicted subject matter according to one or more embodiments, whereas discussion of a specific instance of an illustrated element will append a letter designation thereto (e.g., discussion of a Public Land Mobile Network (PLMN) <NUM>, generally, as opposed to discussion of particular instances of PLMNs 10a, 10b).

In general, the discussion below is provided in the context of a <NUM> wireless communication network. Notwithstanding, those skilled in the art will appreciate that the techniques and solutions provided below are not limited in their applicability to <NUM> networks. Indeed, many of the teachings provided below may also be used in wireless communication networks operating according to other standards. In particular, the examples described below may be particularly well suited for (but not limited to) derivatives of, and/or successors to, <NUM> networks, for example. Other examples may additionally or alternatively be used in predecessor Third Generation Partnership Project (3GPP) networks.

<FIG> illustrates an example wireless communication network that is consistent with the 3GPP <NUM> system architecture. The wireless communication network comprises a radio access network (RAN) <NUM> and a core network <NUM> employing a service-based architecture. The RAN <NUM> and the core network <NUM>, when operated by the same operator, are sometimes collectively referred to as a Public Land Mobile Network (PLMN) <NUM> of the operator.

The RAN <NUM> comprises one or more base stations <NUM> that are configured to provide radio access to one or more UEs <NUM> operating within a coverage area of the PLMN <NUM>. The base stations <NUM> may be referred to as gNodeBs (gNBs). The core network <NUM> provides a connection between the RAN <NUM> and one or more data networks (DNs) <NUM>, such as the Internet, for example. In this example, the PLMN <NUM> is a Visited PLMN (VPLMN) that provides a local breakout to the DN <NUM>. That said, in other examples to be discussed in greater detail below, the PLMN <NUM> of particular embodiments may instead provide a home-routed user plane to the Home PLMN (HPLMN).

The core network <NUM> comprises a plurality of network functions (NFs). These NFs may be in either the user plane <NUM> or the control plane <NUM> of the core network <NUM>. The user plane <NUM> (sometimes referred to as the data plane) typically carries user data traffic. The control plane <NUM> typically carries signaling traffic (e.g., control packets).

In this example, the NFs of the user plane <NUM> comprise a User Plane Function (UPF) <NUM>. The NFs of the control plane <NUM> comprise an Access and Mobility Management Function (AMF) <NUM>, a Session Management Function (SMF) <NUM>, a Policy Control Function (PCF) <NUM>, a Unified Data Management (UDM) function <NUM>, a Unified Data Repository (UDR) function <NUM>, an Authentication Server function (AUSF) <NUM>, a Network Data Analytics Function (NWDAF) <NUM>, a Network Exposure Function (NEF) <NUM>, a Network Repository Function (NRF) <NUM>, and a Network Slice Selection Function (NSSF) <NUM>. The control plane <NUM> of the core network <NUM> also includes an Application Function (AF) <NUM>, and a Security Edge Protection Proxy (SEPP) <NUM>.

The NFs of the core network <NUM> comprise logical entities that reside in one or more core network nodes, which may be implemented using computing hardware, such as one or more processors, memory, network interfaces, or a combination thereof. The functions may reside in a single core network node or may be distributed among a plurality of core network nodes. The NFs may communicate with one another using predefined interfaces. Some of the interfaces are referred to by standardized reference points within the network, whereas other interfaces are simply named.

N1 is a reference point between a UE <NUM> and the AMF <NUM>. N2 is a reference point between the RAN <NUM> and the AMF <NUM>. The N3 is a reference point between the RAN <NUM> and the UPF <NUM>. N4 is a reference point between the SMF <NUM> and the UPF <NUM>. N6 is a reference point between the UPF <NUM> and the DN <NUM>. N9 is a reference point between UPFs <NUM>. Several of the NFs expose a service-based interface named after them in the format Nxxx, wherein xxx is the name of the NF. For example, the NEF <NUM> provides an Nnef interface, the NRF <NUM> provides an Nnrf interface, and so on.

The SEPP <NUM> is a proxy for control plane messages configured to protect the edge of an operator network. <FIG> illustrates an example of a UE <NUM> that has roamed away from its Home PLMN (HPLMN) <NUM> and is currently attached to a VPLMN <NUM>. In contrast to <FIG>, <FIG> illustrates a home-routed scenario in which break out to the DN <NUM> occurs at an HPLMN <NUM>. For clarity of explanation, the involved control plane nodes other than the SEPPs are not depicted. The VPLMN <NUM> and the HPLMN <NUM> use a Visited SEPP (vSEPP) 95a and a Home SEPP (hSEPP) 95b, respectively, to provide security functions at the edge <NUM> between the PLMNs <NUM>, <NUM>. The vSEPP 95a and the hSEPP 95b communicate with each other over an N32 interface. These SEPP 95a, 95b may alternatively be referred to based on whether the SEPP <NUM> is on the service consumer side or the service provider side. A SEPP <NUM> on the service consumer side may be referred to as a c-SEPP whereas a SEPP <NUM> on the service provider side may be referred to as a p-SEPP.

The SEPP <NUM> of a given network may be required to provide security functions for a great many roaming relations that the operator has with other networks, which may be hundreds, for example. Supporting such a significant number of roaming relations can place a substantial computational burden on the SEPP <NUM> and a substantial management burden on the PLMN <NUM>.

To avoid having an overburdened SEPP <NUM> in the network <NUM>, embodiments of the present disclosure delegate some aspects of the SEPP <NUM> to a provider that is outside of the network <NUM>. For example, certain functions that might otherwise be performed by the SEPP <NUM> may instead be delegated from a security NF in the PLMN <NUM> to a security NF outside of the PLMN <NUM> (e.g., operated by an Internet Protocol (IP) Exchange (IPX) <NUM> provider), as shown in <FIG>. In the example of <FIG>, certain functions that ordinarily might be provided by a SEPP <NUM> are instead provided using a distributed SEPP architecture that comprises a Relay SEPP (R-SEPP) <NUM> in the PLMN <NUM> and a Delegated SEPP (D-SEPP) <NUM> outside of the PLMN <NUM> (e.g., in the IPX <NUM>).

The R-SEPP <NUM> and D-SEPP <NUM> may exchange information between themselves over one or more secure interfaces. In this regard, the R-SEPP <NUM> and D-SEPP <NUM> may use any appropriate protocol for ensuring the security of the interface(s) between them, including (but not limited to) Transport Layer Security (TLS). Particular examples of interfaces and protocols used in accordance with particular embodiments will be discussed in greater detail below.

According to particular embodiments of the present disclosure, the R-SEPP <NUM> may be responsible for relaying signaling between NFs and Service Communication Proxies (SCPs) to and/or from the D-SEPP <NUM>. In some embodiments, the R-SEPP may be included in signaling as standardized in 3GPP (e.g., by specific configuration or by NRF discovery). In at least some such embodiments, the R-SEPP <NUM> may register as a SEPP <NUM> in an NRF <NUM>, e.g., so that the R-SEPP <NUM> may be discovered by one or more NFs.

Additionally or alternatively, in some embodiments (and to the extent such is not delegated to the D-SEPP <NUM>), the R-SEPP <NUM> may perform topology hiding, provide certain roaming related security functions, perform telescopic Fully Qualified Domain Name (FQDN) handling, and/or provide firewalling for its own PLMN <NUM>.

Correspondingly, the D-SEPP <NUM> interacts with the R-SEPP <NUM> (e.g., by receiving and forwarding messages received from the R-SEPP <NUM>) and may handle some or all roaming relations and/or N32 connections (e.g., Protocol for N32 Interconnect Security (PRINS) and/or Transport Layer Security (TLS) connections) to roaming partners. In fulfilling its role, the D-SEPP <NUM> of particular embodiments may support interaction with multiple R-SEPPs <NUM>, and may select the appropriate R-SEPP for incoming and/or forwarded requests.

The D-SEPP <NUM> may support the networks of roaming partners regardless of whether or not they have also adopted a distributed SEPP architecture. That is, in some embodiments, one or more of these roaming partners may adopt a similar distributed SEPP architecture that includes an R-SEPP <NUM> and a D-SEPP. Additionally or alternatively, one or more of these roaming partners may use a conventional SEPP <NUM> for security at the network edge.

The PLMN <NUM> may require that the D-SEPP <NUM> use certain secure protocols. For example, the PLMN <NUM> may require that PRINS be used on an N32-f interface. Additionally or alternatively, the PLMN <NUM> may require that TLS be used on N32-f and/or N32-c connections. In this regard, the D-SEPP <NUM> may, e.g., be configured in this way due to a contractual agreement between operators. In at least some such scenarios, the D-SEPP <NUM> interacts with SEPPs <NUM> in other PLMNs, whereas the R-SEPP <NUM> does not. Further, in at least some embodiments, the D-SEPP <NUM> performs firewalling unique to one or more roaming partners.

In at least some embodiments, the D-SEPP further maintains proper bindings between R-SEPPs and roaming agreements, may perform topology hiding (to the extent not performed by the R-SEPP <NUM>) and/or isolates the traffic of different PLMNs <NUM> from each other.

Particular embodiments may include more than one D-SEPP <NUM>, as illustrated in the example of <FIG> illustrates an example of in which two PLMNs 10a, 10b communicate with each other using a distributed SEPP architecture. In particular, PLMN 10a comprises R-SEPPs 150a-c, whereas PLMN 10b comprises R-SEPPs 150d-f.

Each R-SEPP 150a-f is associated with a corresponding D-SEPP 160a-f. In particular, R-SEPP 150a uses corresponding D-SEPP 160a to communicate with PLMN 10b. In this example, PLMN 10b comprises an R-SEPP 150d that similarly uses a corresponding D-SEPP 160b to communicate with PLMN 10a. The D-SEPPs 160a, 160b are in respective IPXs 140a, 140b and communicate with each other using the N32-c interface and the N32-f interface. The N32-c interface is a control plane interface, e.g., for performing initial handshaking and negotiating parameters to be applied for N32 message forwarding. The N32-f interface is a forwarding interface, e.g., for forwarding communication between NFs in the different PLMNs 10a, 10b.

R-SEPP 150b uses corresponding D-SEPP 160c to communicate with R-SEPP 150e via its corresponding D-SEPP 160d. The D-SEPPs 160c, 160d are comprised in the same Roaming Hub (RH) 170a and communicate with each other using their own N32-c and N32-f interfaces.

R-SEPP 150c uses corresponding D-SEPP 160e to communicate with R-SEPP 150f via its corresponding D-SEPP 160f. The D-SEPPs 160e, 160f are comprised in the same Roaming Hub (RH) 170b and communicate with each other using TLS.

Accordingly, if two D-SEPPs <NUM> are in distinct deployments (e.g., as in IPXs 140a, 140b), they may, in some embodiments, interact in accordance with a standard N32 interface. If the two D-SEPPs <NUM> are operated by a single company in the same deployment (e.g., without a national or international interconnect in between, such as in a roaming hub 170a or 170b), then the communication between the D-SEPPs may be comprised within that deployment.

Moreover, either PRINS or TLS can be used in between D-SEPPs. When TLS is used, each D-SEPP <NUM> may be required to find the right target D-SEPP <NUM> in order to establish a TLS connection. For example, D-SEPP 160e may be required to discover D-SEPP 160f, and/or vice versa.

<FIG> illustrates an example of embodiments that include communication between multiple PLMNs 10c-f. Each of the PLMNs 10c-f comprises its own R-SEPP <NUM>-j, each of which interacts with a respective D-SEPP <NUM>-j. Although D-SEPP <NUM> and D-SEPP 160i are operated by the same IPX 140c provider, the D-SEPPs <NUM> and 160i are isolated from each other. D-SEPP 160j is operated by a different IPX 170d provider than that of D-SEPPs <NUM>, 160i. In this example, each of the PLMNs 10c-e has a roaming relation with PLMN 10f.

In the context of the present disclosure the R-SEPP 150a may, for example, be referred to as the security relay node and the R-SEPP 150d may, for example, be referred to as the peer security node of the PMLN. The D-SEPP's 160a-f may be referred to as the remote security node.

Among other things, the above examples illustrate that particular embodiments split SEPP functionality into two roles, with a transport solution in between. In some embodiments, the D-SEPP <NUM> may select the R-SEPP <NUM> (e.g., for outgoing requests). Additionally or alternatively, in some embodiments, different R-SEPPs <NUM>, <NUM> may connect to the same D-SEPP <NUM>, as shown in <FIG>. One or more of the embodiments described herein may be used for roaming hub deployments, e.g., without negatively impacting roaming partners. In particular, one or more embodiments securely expands the "Service Based Interface (SBI) domain" of an operator to include both the R-SEPP <NUM> and D-SEPP <NUM> while allowing the D-SEPP <NUM> to be operated by a different company (e.g. an IPX provider).

As mentioned above, the protocol used between R-SEPP <NUM> and D-SEPP <NUM> may, in some particular embodiments, use a TLS connection (through there may be no need for a specific protocol unless, e.g., the R-SEPP <NUM> needs to provide certain additional information to the D-SEPP <NUM> that cannot be otherwise be derived from forwarded messages). Although particular embodiments include an R-SEPP <NUM> that uses multiple D-SEPPs <NUM>, <NUM> (as shown in <FIG>), it is expected that under most circumstances, any additional D-SEPPs <NUM> in a multiple D-SEPP <NUM> scenario would be used by the R-SEPP <NUM> purely for redundancy purposes. Should there be a need to provide additional information to the D-SEPP <NUM> that cannot be derived from forwarded messages, the N32 may be used in certain embodiments.

Embodiments of the present disclosure may adopt a variety of security and trust models with respect to the various network nodes described herein. For example, in some embodiments, the D-SEPP <NUM> may belong to the security domain of the PLMN <NUM> of its corresponding R-SEPP <NUM>. That said, according to other embodiments, the D-SEPP <NUM> and R-SEPP <NUM> may be deployed like an intranet/extranet/internet trust model, in which the D-SEPP <NUM> is treated analogously to an extranet device and the R-SEPP <NUM> is treated analogously to an intranet device. In particular, in at least some embodiments, the D-SEPP <NUM> only connects to the PLMN <NUM> through the R-SEPP <NUM>, and cannot connect directly to any other NF in the PLMN <NUM>.

Although certain embodiments may use a standard N32 interface between the R-SEPP <NUM> and D-SEPP <NUM>, other embodiments may simply support TLS between the R-SEPP <NUM> and D-SEPP <NUM>. In this regard, the D-SEPP <NUM> essentially represents the PLMN <NUM> among its neighbors, and the R-SEPP <NUM> should not be visible outside the PLMN <NUM>. That said, other interfaces may be suitable between the R-SEPP <NUM> and D-SEPP <NUM>. For example, some derivation of the N32 interface may be appropriate between the R-SEPP <NUM> and D-SEPP <NUM> (e.g., a streamlined or reduced N32 interface). In some particular embodiments, the D-SEPP <NUM> supports both an interface to the R-SEPP <NUM> as well as a standardized N32 interface to other SEPPs <NUM>. The latter may imply to support TLS, PRINS, or even both on N32-f. Additionally or alternatively, Remote Value Added Services (RVAS) may be provided by either the R-SEPP <NUM> or the D-SEPP <NUM>. Such embodiments may be advantageous if, e.g., the Global System for Mobile communications Association (GSMA) begins to support RVAS in SEPP <NUM> scenarios. In particular, should RVAS be provided by an IPX <NUM> provider hosting a D-SEPP <NUM>, that D-SEPP <NUM> may be particularly appropriate.

As mentioned above, TLS (and/or other security protocol) may be used to protect the interface between the R-SEPP <NUM> and the D-SEPP <NUM>. Accordingly, the R-SEPP <NUM> and D-SEPP <NUM> may need to exchange certificates by which to mutually authenticate each other, as well as to protect the confidentiality and integrity of the interface. Delegating SEPP <NUM> functionality to a D-SEPP <NUM> may, in some embodiments, require that the D-SEPP <NUM> holds a certificate on behalf of the PLMN <NUM> that is used for securely connecting to the SEPPs <NUM> in the other PLMNs <NUM>.

The security of the interface between PLMNs <NUM> may also be quite important. Consider, for example, embodiments in which a D-SEPP <NUM> uses PRINS on an N32-f interface with a peer SEPP <NUM> or peer D-SEPP <NUM> of another PLMN <NUM>. As discussed above, the D-SEPP <NUM> (and not the R-SEPP <NUM>) may be responsible for maintain roaming relations with other PLMNs <NUM> in certain embodiments of the distributed SEPP architecture disclosed herein. Accordingly, the R-SEPP <NUM> may not have a secure connection with the peer SEPP <NUM> or peer D-SEPP <NUM>. In such embodiments, without some form of security between PLMNs <NUM>, Information Elements (IEs) sent from the R-SEPP <NUM> to the D-SEPP <NUM> (e.g., via TLS) may be entirely in the clear before they are forwarded by the D-SEPP <NUM> to the other PLMN <NUM>. Thus, without some form of security, PLMNs <NUM> adopting a distributed SEPP architecture may be unable to protect certain IEs that should only be readable by a PLMN <NUM> and/or its peer PLMN <NUM>.

In view of the above, embodiments of the present disclosure take steps to protect certain information (e.g., IEs) that are transferred between PLMNs <NUM>. In some such embodiments, the R-SEPP <NUM> requests, from the D-SEPP <NUM>, a security credential (e.g., a public encryption key, a digital certificate) of the peer SEPP <NUM> / D-SEPP <NUM>. The security credential may be used, for example, to encrypt one or more IEs.

The request for the security credential is performed via the secure interface (e.g., a TLS connection) between the R-SEPP <NUM> and D-SEPP <NUM>. Accordingly, embodiments of the present disclosure may require that the D-SEPP <NUM> already has the requested security credential when the security credential request is received, e.g., after the D-SEPP <NUM> has set up a further TLS connection to the SEPP/D-SEPP of the peer PLMN (hereinafter simply referred to as a peer SEPP).

For example, the D-SEPP <NUM> may perform a credential exchange with the peer SEPP over a secure interface, and provide the security credential of the peer SEPP to the R-SEPP <NUM> upon request via the TLS or PRINS connection between the D-SEPP <NUM> and R-SEPP <NUM>. If the security credential is a digital certificate, the R-SEPP <NUM> may validate the certificate of the peer SEPP, and responsive to the certificate being valid, the R-SEPP <NUM> may extract the public key of the peer SEPP from the certificate. The public key may be used to encrypt one or more IEs and send them to the D-SEPP <NUM> (e.g., using PRINS, using JavaScript Object Notation (JSON) Web Encryption (JWE), or the like). The D-SEPP <NUM> may then send the encrypted IEs to the peer SEPP using PRINS (or other secure protocol).

Moreover, the D-SEPP may, in some embodiments, encrypt one or more other IEs (e.g., as described by a protection policy of the PLMN <NUM>). In this regard, it may be advantageous for encrypted IEs to generally be comprised in the protection policy. Notwithstanding, the D-SEPP <NUM> of particular embodiments may put R-SEPP encrypted IEs into outgoing messages via the N32-f interface to the other PLMN.

<FIG> illustrates an example in which IEs are sent from an R-SEPP <NUM> to a D-SEPP <NUM>. The R-SEPP may use any appropriate mechanism by which to protect the IEs, e.g., by encrypting the IEs using JWE or PASETO. The IEs received by the D-SEPP <NUM> are then sent from the D-SEPP <NUM> to a peer SEPP <NUM> via an N32-f interface, i.e., in encrypted form. In this way, IEs sent by the R-SEPP <NUM> via the D-SEPP <NUM> to the peer SEPP <NUM> are protected. In some embodiments, IEs may also be sent by the peer SEPP <NUM> back to the D-SEPP <NUM>. In such embodiments, the D-SEPP <NUM> may decrypt the IEs and send them to the R-SEPP <NUM>.

Although the D-SEPP in this example uses PRINS to support the N32-f interface to the peer SEPP <NUM>, the D-SEPP <NUM> may additionally or alternatively support one or more TLS connections to the peer SEPP <NUM> and/or R-SEPP <NUM>. In particular, the D-SEPP <NUM> may support an N32-c interface to the peer SEPP <NUM> that may be used to set up the N32-f interface. In some embodiments, one or more of the interfaces from the D-SEPP <NUM> passes through an HTTP Proxy <NUM>. Additionally or alternatively, one or more of the interfaces from the D-SEPP <NUM> is based on a connection to the HTTP proxy <NUM> and the HTTP proxy <NUM> has a corresponding secure connection to the peer SEPP <NUM>.

<FIG> illustrates an example call flow in which the certificate and/or public key of the peer SEPP <NUM> is fetched by the R-SEPP <NUM> from the D-SEPP <NUM>. In this example, both the R-SEPP <NUM> and the D-SEPP <NUM> are capable of encrypting IEs to be sent to the peer SEPP <NUM>.

According to the example of <FIG>, the R-SEPP <NUM> receives a request, e.g., from a node or NF in a PLMN <NUM> of the R-SEPP <NUM> (step <NUM>). This request may, e.g., be a service request for a service provided by an entity outside of the PLMN <NUM>. In response to the request, the R-SEPP <NUM> requests that the D-SEPP <NUM> provide a security credential (e.g., a certificate and/or public key) of the peer SEPP <NUM> (step <NUM>). The D-SEPP <NUM> may (in some embodiments) establish a TLS connection to the peer SEPP <NUM> in response to having received the request for the security credential (step <NUM>). For example, the D-SEPP <NUM> may establish the TLS connection to the peer SEPP <NUM> in order to obtain the requested security credential, to set up a secure channel over which to later forward the service request. Alternatively, the D-SEPP <NUM> may already have a TLS connection to the peer SEPP <NUM>, in which case no new TLS connection may need to be established.

The D-SEPP <NUM> provides the requested security credential to the R-SEPP <NUM> (step <NUM>), and the R-SEPP <NUM> encrypts one or more IEs using the security credential as discussed above (step <NUM>). The R-SEPP <NUM> sends the service request along with the encrypted IEs to the D-SEPP <NUM> (step <NUM>).

In response to receiving the service request with the encrypted IEs, the D-SEPP <NUM> may, in some embodiments, encrypt one or more additional IEs using the security credential of the peer SEPP <NUM> (step <NUM>). The D-SEPP <NUM> sends the request with the encrypted IEs (and the additional encrypted IEs, if any) to the peer SEPP <NUM> (step <NUM>).

In response to receiving the request with encrypted IEs, the peer SEPP <NUM> decrypts the IEs (and the additional IEs, if any) (step <NUM>) and sends the service request towards its destination without the IEs included. Thus, one or more IEs are provided to the peer SEPP in a secure manner. It should be noted that once the D-SEPP <NUM> and the R-SEPP <NUM> have obtained the security credential of the peer SEPP <NUM>, they may each retain that security credential for future use. For example, in response to a subsequent request arriving at the R-SEPP <NUM>, steps <NUM>, <NUM>, and <NUM> may be omitted.

In view of all of the above, particular embodiments may split a standardized SEPP <NUM> into two roles, with a secure transport solution in between, and extend the SBI domain of the operator such that the D-SEPP <NUM> is permitted to be operated by another company without visibility of the D-SEPP deployment to other operators. In some such embodiments, the need to handle all roaming relations may be delegated to the D-SEPP <NUM> while the R-SEPP <NUM> (together with the D-SEPP <NUM>) protects the operator border. In particular, the R-SEPP <NUM> may only allow traffic from known D-SEPPs <NUM>.

Accordingly, embodiments of the present disclosure include a method <NUM> implemented by a security relay node (e.g., an R-SEPP <NUM>) in a PLMN 10a-f, as illustrated in <FIG>. The method <NUM> comprises relaying outbound control plane traffic, received from a source within the PLMN 10a-f, to a remote security node (e.g., a D-SEPP 160a-m) via a secure interface for delivery of the outbound control plane traffic to a further PLMN 10a-f (block <NUM>). The remote security node is outside of both the PLMN 10a-f and the further PLMN 10a-f. The method <NUM> further comprises relaying inbound control plane traffic, received from the further PLMN 10a-f via the remote security node over the secure interface, to a destination within the PLMN 10a-f (block <NUM>).

Other embodiments of the present disclosure include a method <NUM> implemented by a remote security node (e.g., a D-SEPP <NUM>), as illustrated in <FIG>. The method <NUM> comprises relaying outbound control plane traffic, received from a security relay node (e.g., an R-SEPP <NUM>) within a PLMN 10a-f via a secure interface, to a further PLMN 10a-f (block <NUM>). The remote security node is outside of both the PLMN 10a-f and the further PLMN 10a-f. The method <NUM> further comprises relaying inbound control plane traffic, received from a source within the further PLMN 10a-f, to the security relay node via the secure interface (block <NUM>).

Yet other embodiments of the present disclosure include the security relay node <NUM> and the remote security node <NUM> implemented according to the hardware illustrated in <FIG>, respectively. The example hardware of <FIG> each comprise processing circuitry 910a, 910b, memory circuitry 920a, 920b, and interface circuitry 930a, 930b. In each respective node, the processing circuitry 910a, 910b is communicatively coupled to the memory circuitry 920a, 920b and the interface circuitry 930a, 930b, e.g., via one or more buses. The processing circuitry 910a, 910b may comprise one or more microprocessors, microcontrollers, hardware circuits, discrete logic circuits, hardware registers, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or a combination thereof. For example, the processing circuitry 910a, 910b may be programmable hardware capable of executing software instructions 960a, 960b stored, e.g., as a machine-readable computer program in the memory circuitry 920a, 920b. The memory circuitry 920a, 920b of the various embodiments may comprise any non-transitory machine-readable media known in the art or that may be developed, whether volatile or non-volatile, including but not limited to solid state media (e.g., SRAM, DRAM, DDRAM, ROM, PROM, EPROM, flash memory, solid state drive, etc.), removable storage devices (e.g., Secure Digital (SD) card, miniSD card, microSD card, memory stick, thumb-drive, USB flash drive, ROM cartridge, Universal Media Disc), fixed drive (e.g., magnetic hard disk drive), or the like, wholly or in any combination.

The interface circuitry 930a, 930b may be a controller hub configured to control the input and output (I/O) data paths of its respective node <NUM>, <NUM>. Such I/O data paths may include data paths for exchanging signals over a communications network (e.g., a PLMN <NUM>, an IPX <NUM>, a Roaming Hub <NUM>). For example, the interface circuitry 930a, 930b may comprise a transceiver configured to send and receive communication signals over a cellular network, Ethernet network, and/or an optical network.

The interface circuitry 930a, 930b may be implemented as a unitary physical component, or as a plurality of physical components that are contiguously or separately arranged, any of which may be communicatively coupled to any other, or may communicate with any other via the processing circuitry 910a, 910b of its respective node <NUM>, <NUM>. For example, the interface circuitry 930a, 930b may comprise output circuitry (e.g., transmitter circuitry configured to send communication signals over the communications network) and input circuitry (e.g., receiver circuitry configured to receive communication signals over the communications network).

According to embodiments of the hardware illustrated in <FIG>, the processing circuitry 910a of the security relay node <NUM> is configured to, from within the PLMN 10a-f, relay outbound control plane traffic, received from a source within the PLMN 10a-f, to a remote security node <NUM> via a secure interface for delivery of the outbound control plane traffic to a further PLMN 10a-f. The remote security node <NUM> is outside of both the PLMN 10a-f and the further PLMN 10a-f. The processing circuitry 910a is further configured to relay inbound control plane traffic, received from the further PLMN 10a-f via the remote security node <NUM> over the secure interface, to a destination within the PLMN 10a-f.

According to embodiments of the hardware illustrated in <FIG>, the processing circuitry 910b of the remote security node <NUM> is configured to relay outbound control plane traffic, received from a security relay node <NUM> within a PLMN 10a-f via a secure interface, to a further PLMN 10a-f. The remote security node <NUM> is outside of both the PLMN 10a-f and the further PLMN 10a-f. The processing circuitry 910b is further configured to relay inbound control plane traffic, received from a source within the further PLMN 10a-f, to the security relay node <NUM> via the secure interface.

Claim 1:
A method, implemented by a security relay node in a Public Land Mobile Network, PLMN, the method comprising the steps of:
- receiving, from a Network Function, NF, within the PLMN, a control packet to be provided to a further PLMN;
- delegating, to a remote security node, a setup of a N32-c interface towards the further PLMN such that said N32-c interface terminates at said remote security node;
- relaying said control packet to the remote security node for delivery of the control packet, over the N32-C interface, towards the further PLMN, the remote security node being outside of both the PLMN and the further PLMN.