Apparatus and method for dynamic discovery and redirection of security gateways in mobile communication networks

Abstract

This invention provides a method for dynamic discovery and redirection of security gateways in mobile communication networks. [Solution] This method includes initiating communication between a first security gateway in a first mobile communication network and a second security gateway in a second mobile communication network based on a first domain name. A redirection response is received from the second security gateway, which indicates a second domain name used for DNS-based discovery of another security gateway in the second mobile communication network. Based on the second domain name, the communication is redirected from the first security gateway in the first mobile communication network to a third security gateway in the second mobile communication network. This method may enable flexible and efficient routing of inter-network communication.

Description

Technical Field

[0001] This disclosure relates to the field of mobile communication networks, and in particular, to methods and apparatuses for the dynamic discovery and redirection of security gateways to manage inter-network communication and ensure secure and efficient traffic routing.

Background Art

[0002] The evolution of mobile networks has led to the deployment of 5G Standalone (SA) networks, which represent a significant leap from previous technologies. Unlike 5G Non-Standalone (NSA) networks that rely on existing 4G LTE infrastructure, 5G SA networks operate with a dedicated 5G Core (5GC) and fully utilize the capabilities of 5G technology. This brings enhancements such as ultra-low latency, high throughput, and support for a large number of Internet of Things (IoT) applications. In this context, a Security Edge Protection Proxy (SEPP) plays a crucial role in ensuring secure communication between different mobile network operators, especially in roaming scenarios where multiple Public Land Mobile Networks (PLMNs) interact.

[0003] A Security Edge Protection Proxy (SEPP) is a security gateway that can ensure the confidentiality, integrity, and authenticity of signaling messages exchanged between networks in a 5G environment. Since 5G networks facilitate communication between various Public Land Mobile Networks (PLMNs), SEPP can be deployed at the edge of each network to secure inter-network exchanges. These exchanges can be facilitated via the inter-PLMN interface N32, which enables two SEPPs from different PLMNs to interact securely, protect confidential data, and maintain network integrity. SEPP prevents unauthorized access, tampering, or data leakage by encrypting communication between networks.

[0004] However, current standards governing SEPP operation in 5G, such as those defined by the 3rd Generation Partnership Project (3GPP), face limitations in dynamically directing traffic between multiple SEPPs within the same PLMN. In some situations, operators may deploy multiple SEPPs for various reasons, including load balancing, failover mechanisms, or routing based on specific network functionality or roaming partner requirements. However, existing standards do not provide a clear mechanism for dynamically discovering and routing traffic to different SEPPs based on these needs. The process of selecting a SEPP is currently constrained by Domain Name System (DNS) queries that always return the same SEPP for a given PLMN, limiting the flexibility required for dynamic traffic management.

[0005] This limitation can be particularly problematic in 5G SA networks, where flexibility in routing roaming traffic may be essential for optimizing network performance and ensuring seamless communication between partners. In roaming scenarios where multiple SEPPs may be deployed within a single PLMN, the inability to dynamically select and redirect traffic to different SEPPs can hinder the network's ability to adapt to changing conditions and traffic demands. This can impact load balancing and failover capabilities, as well as reduce the network's efficiency when handling complex roaming use cases that require targeted routing.

[0006] The problem to be solved lies in the lack of a mechanism to enable dynamic redirection of SEPP traffic within and between PLMNs. Existing specifications provide some redirection capabilities through Hypertext Transfer Protocol (HTTP) responses, but these are unsuitable for scenarios where multiple SEPPs must be dynamically discovered and selected based on specific operational requirements. Current reliance on static DNS responses and limited redirection options prevents operators from achieving the full flexibility designed to be provided by 5G SA networks, creating a need for a more adaptive approach to SEPP discovery and redirection. [Overview of the project]

[0007] This need is addressed by the methods and apparatus described in the attached independent claims. Advantageous possible embodiments are addressed by the dependent claims.

[0008] According to a first aspect of this disclosure, a method for dynamic discovery and redirection of security gateways in a mobile communication network is proposed. The method includes the step of initiating communication between a first security gateway in a first mobile communication network and a second security gateway in a second mobile communication network based on a first domain name. The method further includes the step of receiving a redirection response from the second security gateway. The redirection response indicates a second domain name used for DNS-based discovery of another security gateway in the second mobile communication network. The method further includes the step of redirecting communication from the first security gateway in the first mobile communication network to a third security gateway in the second mobile communication network based on the second domain name. The proposed method can dynamically discover security gateways in different mobile networks. By initiating communication between gateways and using redirection responses, the system can enable flexible routing of traffic. This can ensure optimized communication paths and load balancing, benefiting roaming scenarios in mobile networks.

[0009] According to some embodiments, redirection responses are received via an inter-mobile communications network interface. This can enable seamless inter-network communication and is particularly useful in roaming scenarios involving different PLMNs. According to some embodiments, the inter-mobile communications network interface is an inter-PLMN interface. One commonly known inter-PLMN interface is the N32 interface, which is particularly used in 5G networks for secure communication between SEPPs. The N32 interface ensures that signaling messages exchanged between different mobile operators are protected during roaming scenarios. Another well-known inter-PLMN interface is the S8 interface, which is part of the 4G LTE architecture and enables user plane data transfer between a serving gateway (SGW) at a visited PLMN and a packet data network gateway (PGW) at a home PLMN during roaming. These interfaces can facilitate secure and efficient communication between networks operated by different mobile providers. Using inter-PLMN interfaces can facilitate communication between security gateways of different mobile operators, improve roaming capabilities, and enable dynamic traffic redirection between networks. This can support a more flexible and resilient network architecture.

[0010] According to some embodiments, the step of initiating communication between a first security gateway and a second security gateway includes the step of constructing a first domain name for the target security gateway in the second mobile communication network based on the network ID of the second mobile communication network. The step of constructing a domain name based on the network ID may provide a clear and organized method for identifying and addressing security gateways in the second mobile communication network. This helps to route traffic accurately to the correct gateway and can improve communication efficiency. In another example, the domain name may be generated based on a predetermined naming convention that incorporates additional factors such as the gateway's location, the type of service being accessed, or specific security requirements. Another technique may include dynamically constructing the domain name based on load balancing or performance metrics of available security gateways to ensure optimal traffic routing. Furthermore, the domain name may be created by utilizing a hierarchical naming scheme, where different components of the domain reflect various levels of the network architecture, such as the operator's name, geographical region, or service-specific identifier.

[0011] According to some embodiments, the step of initiating communication between a first security gateway and a second security gateway includes the step of performing a DNS query using the first domain name to obtain a list of security gateways in the second mobile communication network. Using DNS queries can enable the dynamic discovery of available security gateways in the second network. This can enable more efficient and real-time identification of potential gateways for communication, increasing flexibility and resilience in network management. In another example, a centralized registry or database can be used in which security gateways are pre-registered, and the initiating gateway can query this registry directly to obtain relevant information. Alternatively, communication between security gateways can utilize dynamic service discovery protocols such as Service Location Protocol (SLP) or Universal Plug and Play (UPnP) to discover available gateways. In addition, peer-to-peer communication between gateways can enable direct gateway advertisement, where each security gateway periodically broadcasts its availability to other network nodes without requiring DNS lookups.

[0012] According to some embodiments, the method further includes the steps of selecting a security gateway from a list and initiating communication between a first security gateway and the selected second security gateway in a second mobile communication network. The selection of a security gateway from the list may be based on several criteria. One common criterion may be load balancing, selecting the gateway with the least traffic or the gateway with optimal capacity to prevent overloading any single gateway. Another criterion may be geographical proximity, selecting the gateway that is physically closest to the user or source of traffic to minimize latency. Security policy may also influence the selection, taking precedence over gateways that meet certain encryption or data protection standards. Furthermore, the selection may ensure the best quality of service based on network performance metrics such as response time, bandwidth availability, or packet loss rate. Gateway availability and redundancy may also play a role, with the system selecting a gateway with high availability or one that provides failover support in the event of a network failure. Such criteria may allow for the selection of the most suitable security gateway, maintaining optimal performance and security. The selection of a particular gateway from the list may allow traffic to be optimally routed through the most suitable gateway, potentially based on factors such as load or geographical location. This could contribute to improved network performance and resource management.

[0013] According to some embodiments, the step of initiating communication between a first security gateway and a third security gateway includes the step of dynamically discovering a new target security gateway by performing a second DNS query using a second domain name. By performing a second DNS query, the method can further enhance dynamic discovery by enabling real-time adjustment of the communication path when a new gateway is discovered. This flexibility can ensure optimized network routing. In another example, a centralized registry or database may be used where security gateways are pre-registered, and the initiating gateway can query this registry directly to obtain relevant information. Alternatively, communication between security gateways may utilize a dynamic service discovery protocol such as SLP or UPnP to discover available gateways.

[0014] According to some embodiments, the method further includes the step of redirecting communications to a new target security gateway based on the result of a second DNS query. The second DNS query may return a second list of target security gateways in a second mobile communications network, similar to how the first DNS query provided an initial list. This second list includes available security gateways suitable for handling redirected communications. The list may include multiple gateways that meet specific criteria such as location, capacity, or service type. Based on this second list, the system may then dynamically select the most appropriate target security gateway for the redirected communications, ensuring that communications are efficiently routed through the best available gateway in the network. Redirecting communications based on a second DNS query may allow the method to dynamically adjust the communications flow, ensuring that traffic is directed through the most efficient or available security gateway. This can improve both reliability and scalability in the network.

[0015] In some embodiments, a DNS query includes a DNS Naming Authority Pointer (NAPTR) query. Using NAPTR queries as part of the DNS process can enable more complex and flexible service discovery, allowing the network to resolve not only the gateway address but also the services it provides. This can enhance the system's ability to adapt to diverse network needs. In another example, an SRV (Service) query may be used to locate a specific service within the network by identifying the hostname and port number of the server providing the desired service. In addition, an A (Address) query or AAAA (IPv6 Address) query may be used to bypass service discovery and directly resolve a domain name to its corresponding IPv4 or IPv6 address. A CNAME (Canonical Name) query may also be used to map an alias name to a canonical domain name, facilitating flexible redirection.

[0016] According to some embodiments, a security gateway includes its respective SEPP. Using an SEPP as a security gateway can ensure secure communication between different mobile networks, particularly in roaming scenarios. SEPPs can protect the integrity of signaling messages between networks and provide a critical layer of security. Several other types of security gateways are used in mobile and telecommunications networking. One example is a security gateway (SEG) used in IP-based networks, particularly to secure IPsec tunnels between different network segments or between users and networks. Another example is a border gateway function (BGF) that may be used in telecommunications networks to manage and secure traffic at the boundaries of a service provider's network. Furthermore, in 4G LTE networks, a Diameter Edge Agent (DEA) acts as a security gateway to control and secure diagrammatic signaling traffic between networks. These gateways, like SEPPs, are responsible for ensuring inter-network communication, privacy, and managing access between different network domains or operators.

[0017] According to several embodiments, the first and second mobile communication networks include their respective 5G standalone (SA) networks. Applying the proposed method to a 5G SA network can enhance the performance and flexibility of next-generation mobile networks and enable better handling of security and communications in advanced mobile architectures. This can result in improved network slicing and security. Those skilled in the art who benefit from this disclosure will understand that embodiments of the disclosure may be applicable not only to 5G SA networks but also to other communication networks employing security gateways. By utilizing domain names and redirection responses, embodiments of the disclosure can be adapted to manage secure communications across various network architectures and enable dynamic discovery and redirection of gateways in networks requiring secure and efficient routing of traffic between different operators or territories. This flexibility allows embodiments of the invention to optimize communication paths and load balancing in both next-generation and legacy mobile networks, thereby improving overall network performance and security.

[0018] In some embodiments, a domain name includes its respective fully qualified domain name (FQDN). Using an FQDN to address a security gateway can ensure clarity and accuracy in the communication process, allowing the network to easily resolve and communicate with the correct endpoint. This can improve reliability and reduce routing errors. In another example, a partially qualified domain name (PQDN) may be used, specifying only a portion of the domain, with the missing portion being inferred based on the local network context. In addition, relative domain names may be used, which may typically be interpreted for predefined domains within the same network or organization. In certain closed network environments, custom domain naming schemes may also be applied, where domain names are structured differently to meet specific security or operational requirements.

[0019] According to some embodiments, redirection responses include hypertext transport protocol (HTTP) redirection responses. HTTP redirection responses allow the method to leverage widely used protocols for directing communications, ensuring compatibility with and ease of integration into existing network infrastructure. This can simplify the process and increase scalability. In another example, SIP (Session Initiation Protocol) redirection responses can be used in networks involving voice, video, or messaging services, enabling the redirection of communication sessions to alternative endpoints. In IP-based networks, DNS-based redirection responses can also be used, where DNS redirects traffic by providing alternative IP addresses or domain names. Furthermore, application layer redirection protocols such as Diameter or GTP (GPRS Tunneling Protocol) can be employed in telecommunications networks to handle signaling between nodes or redirection of data traffic.

[0020] In another aspect of this disclosure, a device for dynamic discovery and redirection of security gateways in a mobile communication network is proposed. The device includes a processing circuit configured to perform the following steps: initiating communication between a first security gateway in a first mobile communication network and a second security gateway in a second mobile communication network based on a first domain name; receiving a redirection response from the second security gateway, wherein the redirection response indicates a second domain name to be used for DNS-based discovery of another security gateway in the second mobile communication network; and redirecting communication from the first security gateway in the first mobile communication network to a third security gateway in the second mobile communication network based on the second domain name. The proposed device enables dynamic discovery and redirection of communication paths between security gateways and can facilitate seamless communication across mobile networks. This can lead to a flexible and efficient system for managing inter-network traffic, improving both security and performance.

[0021] In another aspect of this disclosure, a method is proposed for dynamic discovery and redirection of security gateways in a mobile communications network. The method includes the steps of: initiating communication between a first security gateway in a first mobile communications network and a second security gateway in a second mobile communications network based on a first domain name; and sending a redirection response from the second security gateway to the first security gateway, wherein the redirection response indicates a second domain name to be used for DNS-based discovery of another security gateway in the second mobile communications network. The method enables the first gateway to redirect traffic accordingly from the perspective of the second security gateway that actively sends the redirection response. This approach may enable the second gateway to influence traffic routing, provide more control over network paths, and improve traffic distribution.

[0022] In another aspect of this disclosure, a device for dynamic discovery and redirection of security gateways in a mobile communication network is proposed. The device includes processing circuitry configured to perform the steps of: initiating communication between a first security gateway in a first mobile communication network and a second security gateway in a second mobile communication network based on a first domain name; and sending a redirection response from the second security gateway to the first security gateway, wherein the redirection response indicates a second domain name. The device can optimize network resource utilization by enabling the second security gateway to play an active role in the redirection process and guiding the first security gateway toward the best available communication path. This can improve load balancing and network management.

[0023] Embodiments of the present disclosure focus on optimizing inter-network traffic and propose methods and apparatuses for dynamic discovery and redirection of security gateways in mobile communication networks. The proposed concept includes initiating communication between security gateways based on domain names and utilizing DNS queries to dynamically discover available security gateways. The proposed concept supports seamless redirection to more appropriate gateways, enabling flexible routing and load distribution that are particularly beneficial in roaming scenarios. Using a Security Edge Protection Proxy (SEPP), DNS NAPTR queries, and FQDNs for addressing can ensure security and efficiency. Redirection responses, the HTTP protocol, and the PLMN-to-PLMN interface enable the proposed concept to dynamically adjust the communication path and improve performance and resilience in 5G standalone networks.

[0024] Some examples of the apparatus and / or method are described below by way of example only, with reference to the accompanying drawings.

Brief Description of the Drawings

[0025] [Figure 1] FIG. is a diagram showing a network architecture for a mobile communication network according to an aspect of the present disclosure. [Figure 2] FIG. is a flowchart showing a method for dynamic discovery and redirection of a security gateway according to an embodiment. [Figure 3] FIG. is a block diagram showing an apparatus for dynamic discovery and redirection of a security gateway according to an embodiment. [Figure 4] FIG. is a sequence diagram showing a dynamic discovery and redirection process for a security gateway according to an exemplary embodiment.

Modes for Carrying Out the Invention

[0026] Next, several examples will be described in more detail with reference to the accompanying drawings. However, other possible examples are not limited to the features of these embodiments described in detail. Other examples may include modifications of features, as well as equivalents and alternatives of features. Furthermore, the terms used herein to describe specific examples should not limit further possible examples.

[0027] Throughout the description of the drawings, the same or similar reference numerals refer to the same or similar elements and / or features, which may be the same or implemented in a modularized form while providing the same or similar functions. The thickness of lines, layers, and / or regions in the drawings may also be exaggerated for clarity.

[0028] When two elements A and B are combined using "or", this should be understood to disclose all possible combinations, i.e., only A, only B, and A and B, unless otherwise clearly defined in individual cases. As an alternative representation of the same combination, "at least one of A and B" or "A and / or B" may be used. This also applies to combinations of more than two elements.

[0029] When singular forms such as "a", "an", and "the" are used and the use of only one element is not defined as explicitly or implicitly essential, further examples may also use several elements to achieve the same function. When a function is described below as being implemented using multiple elements, further examples may implement the same function using a single element or a single processing entity. Furthermore, the terms "include", "including", "comprise", and / or "comprising", when used, describe the presence of the specified features, integers, steps, operations, processes, elements, components, and / or groups thereof, but it is understood that they do not exclude the presence or addition of one or more other features, integers, steps, operations, processes, elements, components, and / or groups thereof.

[0030] PLMN operators are organizations that deploy and operate mobile networks. The technologies for these networks may be defined in 3GPP (3rd Generation Partnership Project) specifications, and their operating modes may be defined by the GSMA (GSM Association). This applies to 5G networks and earlier generations.

[0031] The 5G specification defines the use of a non-transparent proxy, a Security Edge Protected Proxy (SEPP), for inter-PLMN communication, i.e., roaming. A SEPP can establish communication between two PLMNs and protect the network edge of the PLMNs. Inter-PLMN communication refers to communication between two different PLMNs, typically occurring in roaming scenarios when a mobile user connects to a network outside of their home operator's network. SEPPs can be used to secure and manage this communication. A SEPP can act as a security gateway in a 5G network, specifically designed to protect communication between different PLMNs during inter-network interactions such as roaming. Acting as a secure intermediary, a SEPP can ensure that all signaling traffic exchanged between two networks remains protected and confidential. This can effectively protect the network periphery from potential threats by preventing the disclosure of sensitive network details through encryption and integrity protection. As a gateway, a SEPP can enable the secure and efficient exchange of messages while preventing unauthorized access to or manipulation of network resources. This role is particularly necessary to maintain the security and integrity of 5G communications in scenarios where multiple mobile operators must collaborate without compromising their internal network structures.

[0032] The inter-PLMN interface between two SEPPs is called N32. The N32 interface allows SEPPs to securely exchange signaling messages between networks and ensure that communications during roaming or other inter-network activities are protected. This enables SEPPs to establish and maintain secure connections and apply encryption and other security mechanisms to protect the integrity and confidentiality of data transmitted between the two PLMNs. By using N32, SEPPs can securely manage and route traffic across mobile networks of different entities without exposing sensitive information to external parties.

[0033] In the case of roaming, each PLMN may be identified by a globally unique PLMN identifier (ID). A global registry may exist for these IDs. PLMN IDs can be used to identify and distinguish networks, particularly when a user connects to an external network while roaming. This unique identification can help ensure that the device is properly authenticated and establishes a connection to the appropriate network. Furthermore, a global registry may exist to maintain and manage these PLMN IDs, ensure their uniqueness, and avoid confusion between network operators across different countries and regions. This registry can enable the smooth operation of international mobile communications.

[0034] A well-known fully qualified domain name (FQDN) can be constructed for one SEPP to establish communication with another. A well-known FQDN includes the PLMN ID and the domain "3gppnetwork.org". As soon as the PLMN ID is known, a well-known FQDN can be constructed. This explains how one SEPP can communicate with another across different mobile networks. To initiate this communication, the SEPP constructs a well-known FQDN, which is essentially a structured web address used to identify the target SEPP. This FQDN is constructed by combining the unique identifier of the target network, known as the PLMN ID, with the standard domain name "3gppnetwork.org", which is universally used for 5G networks. This approach can enable SEPPs to accurately identify and locate each other across different PLMNs.

[0035] To discover a SEPP, a well-known FQDN can be used in a DNS NAPTR (Naming Authority Pointer) query to obtain a list of desired services. A NAPTR query is a type of DNS query that can resolve a domain name to a service or specific function. By using this query, a SEPP can retrieve a list of services or available services provided by the target SEPP. This allows the initiating SEPP to understand the capabilities of other SEPPs and select the correct one for communication, ensuring proper signaling and inter-network security.

[0036] From the list, the initiating SEPP can select its intended purpose and execute an SRV (Service) request for the selected entry. That is, after receiving a list of purposes or services from a DNS NAPTR query, the initiating SEPP can select the appropriate one based on its intended communication purpose. Once the correct service or function is identified, the SEPP executes an SRV request for that selected entry. An SRV request is a type of DNS query used to find a specific server or service capable of handling communication. This allows the initiating SEPP to find the exact SEPP instance that can meet its communication needs, ensuring accurate and efficient connectivity between networks.

[0037] A DNS server can respond with a prioritized and weighted list of SEPP FQDNs. The initiating SEPP can select one of them, send a DNS query to obtain an IP address (A or AAAA), and finally communicate with the IP address belonging to the selected destination SEPP. That is, after the initiating SEPP has performed an SRV request, the DNS server may respond with a list of FQDNs representing available SEPPs, along with priority and weight values. These values ​​can help the initiating SEPP determine the best SEPP to communicate with, based on factors such as load balancing or proximity. Once a SEPP is selected from this list, the initiating SEPP can send a DNS query to resolve the FQDN to an IP address that may be either an IPv4(A) or IPv6(AAAA) address. The initiating SEPP can then use this IP address to establish direct communication with the selected SEPP in the destination network.

[0038] This method could allow a SEPP to discover the IP address of a roaming partner's peer SEPP by knowing only the PLMN ID. No further prior knowledge or configuration is required.

[0039] The 3GPP specification defines an HTTP redirection for a SEPP to inform the initiating entity that a different SEPP should be used. This redirection response includes the Fully Qualified Domain Name (FQDN) of the intended new target SEPP. This FQDN can be resolved to an IP address via a DNS A or AAAA query. This means that if an initiating SEPP attempts to communicate with a target SEPP that is not best suited for the task, the target SEPP can send an HTTP redirection response to inform the initiating SEPP to use a different SEPP instead. This redirection response may include the FQDN of the new target SEPP. The initiating SEPP can then resolve this FQDN to an IP address via a DNS query using either an A record for IPv4 or an AAAA record for IPv6. This process allows the initiating SEPP to redirect its communication to the appropriate SEPP, ensuring optimized routing and network efficiency.

[0040] The limitation is that DNS always responds with the same answer. If a PLMN wants to direct a particular roaming partner to a dedicated SEPP, the current standard does not allow this. When a DNS query is made, the DNS query can always provide the same set of responses for a given request, without considering any specific conditions or choices. This means that if a mobile network operator (PLMN) wants to route traffic from a certain roaming partner to a particular dedicated SEPP, the existing standard does not support this level of customization. Because DNS responses lack the flexibility to direct different partners to different SEPPs based on their identification information or other factors, operators cannot control which SEPP a roaming partner connects to. This limits the ability to optimize routing and load balancing in a roaming cellario.

[0041] Currently, a SEPP can redirect HTTP requests to a different SEPP via a non-N32 interface by sending a 307 Temporary Redirect or 308 Permanent Redirect response to an HTTP client containing a RedirectResponse data structure. The Location header is ignored, and the contents of the RedirectResponse (targetSepp Information Element (IE)) are used. In such cases, the SEPP can send an HTTP redirection response, specifically a 307 Temporary Redirect or 308 Permanent Redirect, to the HTTP client. Instead of using the standard HTTP Location header for redirection, which is typically used in other types of web redirection, the SEPP contains a special data structure called RedirectResponse. This structure contains a specific information element known as the targetSepp Information Element (IE) that directs the client to the new SEPP. The Location header is ignored in this process, and only the information in the RedirectResponse is used to handle the redirection, ensuring that the traffic is properly routed to the intended SEPP.

[0042] This technique can be used when an element within a PLMN, a so-called network function (NF), wishes to communicate with another PLMN. The NF sends its message to its own PLMN's SEPP for delivery. This SEPP can then tell the NF to use another SEPP for transmission instead. This is intra-PLMN communication and therefore irrelevant to roaming.

[0043] Conversely, an N32 HTTP request may be redirected to a different SEPP service instance located within the same PLMN. An exemplary scenario is shown in Figure 1.

[0044] Referring to Figure 1, a network architecture 100 for a mobile communication network is shown. The depicted architecture 100 includes multiple PLMNs 110A, 110B, and 110C, specifically PLMN A, PLMN B, and PLMN C. Each PLMN may be a 5G standalone (SA) network, and each may include at least one SEPP 112. The SEPP 112, which may be implemented as a processing circuit, functions as a security gateway for inter-PLMN communication.

[0045] In the illustrated example, PLMN A includes two SEPPs (SEPP112A1 and SEPP112A2). SEPP112A1 is connected to PLMN B via inter-mobile communication network interfaces 120 and 130, such as inter-PLMN interfaces represented by N32 connections. Similarly, SEPP112A2 is connected to PLMN C via another inter-PLMN (N32) interface 120 and 130. PLMN B and PLMN C each have their own SEPPs, namely SEPP112B and SEPP112C, to connect to PLMN A.

[0046] PLMN A includes various network functions (NF) 116A, such as the Network Repository Function (NRF) 114A and the Network Exposure Function (NEF) 118A, as part of the 5G Service-Based Architecture (SBA). These network functions can interact with SEPP 112A1 and SEPP 112A2 via Service-Based Interface (SBI) connections 111A, which can handle internal communications within PLMN A. SEPP 112A1 and SEPP 112A2 can then establish secure external communications with SEPPs in PLMN B and PLMN C via N32 connections 120 and 130. The N32 interface is divided into two parts: N32-c connections 120 and N32-f connections 130. N32-c connections 120 may be used for control plane signaling between SEPPs, including security negotiation and parameter exchange, while N32-f connections 130 may handle the transfer of protected application layer messages between networks. The cloud within the center represents a broader internet or IP-switched network through which SEPP communicates across different PLMNs, ensuring the security of signaling and data between networks, especially in roaming scenarios. This also includes a central domain represented by the "mnc001.mcc001.3gppnetwork.org" domain. This domain can be used for DNS-based SEPP discovery, facilitating inter-PLMN communication.

[0047] In some embodiments, multiple SEPPs within PLMN A, specifically SEPP112A1 and SEPP112A2, may serve different purposes. For example, a PLMN operator may choose to connect to a particular roaming partner via one SEPP and use a different SEPP for another roaming partner. This approach allows the operator to route a particular roaming partner to a particular SEPP based on its selection. For example, SEPP112A1 may be used to connect to PLMN B, and SEPP112A2 may be used to connect to PLMN C.

[0048] In some cases, deploying multiple SEPPs within a single PLMN, such as PLMN A, can facilitate load balancing. Load balancing can be achieved by distributing network traffic across multiple SEPPs to prevent a single SEPP from being overwhelmed by traffic. This can improve network efficiency and reliability by preventing any single point of failure and ensuring optimal utilization of network resources.

[0049] In some embodiments, multiple SEPP112A1, SEPP112A2 within PLMN A can also facilitate a failover mechanism. A failover mechanism is a backup operating mode assumed by a secondary system component when the primary component becomes unavailable, where the functionality of a system component such as a SEPP is maintained. In the context of this disclosure, if one SEPP within PLMN A becomes unavailable or stops, other SEPPs can take over its functionality, thereby ensuring uninterrupted service.

[0050] Furthermore, multiple SEPP112A1 and SEPP112A2 within PLMN A can be used to implement traffic prioritization and routing based on target network functions (NFs). In some cases, certain types of traffic or groups of NFs may take precedence and be routed through specific SEPPs. For example, traffic related to emergency services or critical infrastructure may be prioritized and routed through specific SEPPs to ensure reliable and timely communication.

[0051] For example, SEPP112A1 in PLMN A may receive an N32 HTTP request from another SEPP112B, for example, in PLMN B, and redirect that request to another SEPP112A2 in PLMN A. For example, SEPP112A1 may send a 307 Temporary Redirect response to SEPP112B, which may contain a RedirectResponse data structure. The location header is used, and the contents of RedirectResponse(targetSepp IE) are ignored.

[0052] The HTTP RFC defines the HTTP Location Header. The RFC states that the Location Header consists of a URI containing a Fully Qualified Domain Name (FQDN). This FQDN can be interpreted as the Host FQDN. The RFC leaves no room for other interpretations.

[0053] Notifying the initiating SEPP112B of this approach for the new target SEPP112A2 only allows PLMN A to respond with a dedicated SEPP FQDN. This reduces flexibility because DNS-based SEPP discovery cannot be performed again for the new target SEPP112A2.

[0054] This disclosure provides methods, apparatus, and systems for dynamic discovery and redirection of security gateways in mobile communications networks. This may be particularly relevant in the context of 5G networks, where SEPPs play a role in securely protecting the edge of the mobile network and facilitating secure inter-network communications. The disclosed methods and apparatus address the need for more flexible and dynamic routing of traffic to specific SEPPs based on various criteria or selections, a capability lacking in current existing standards. This is particularly beneficial in scenarios where a PLMN operator directs a specific roaming partner to a dedicated SEPP and uses a different SEPP for another roaming partner. The disclosed methods and apparatus also overcome the limitations of the static nature of DNS responses in current setups, enabling a new round of DNS-based SEPP discovery during redirection, thereby facilitating advanced load balancing or failover strategies. Furthermore, the disclosed methods and apparatus eliminate the need for pre-configuration or knowledge by the initiating network, thereby reducing complexity in network management and enhancing agility in responding to changing network conditions or security requirements.

[0055] Referring to Figure 2, a flowchart of Method 200 for dynamic discovery and redirection of security gateways in a mobile communication network is shown.

[0056] Method 200 includes initiating communication between a first security gateway in a first mobile communication network and a second security gateway in a second mobile communication network based on a first domain name (210).

[0057] In some embodiments, the first security gateway may be a SEPP in a PLMN such as PLMN B (Figure 1). The second security gateway may be another SEPP in a different PLMN such as PLMN A. The first domain name may be constructed based on the network ID of the second mobile communications network (e.g., PLMN A). The network ID may be a globally unique PLMN ID, and the first domain name may be an FQDN that includes the PLMN ID and a domain such as "3gppnetwork.org".

[0058] In some cases, action 210, which initiates communication between the first security gateway and the second security gateway, may involve performing a DNS query using the first domain name to obtain a list of security gateways in the second mobile communication network (e.g., PLMN A). The DNS query may be a DNS NAPTR query. The first security gateway (e.g., in PLMN B) can then select a security gateway from the list as described above and initiate communication with the selected second security gateway in the second mobile communication network (e.g., PLMN A).

[0059] Action 220 in Method 200 includes receiving a redirection response from a second security gateway (e.g., in PLMN A) indicating a second domain name to be used for DNS-based discovery of another security gateway in the second mobile communication network. The redirection response may be received via an inter-mobile communication network interface, such as an inter-PLMN (N32) interface 120, 130. The redirection response may be an HTTP redirection response. In some embodiments, the redirection response may inform the first security gateway (e.g., in PLMN B) that another security gateway (e.g., in PLMN A) should be used for communication. The redirection response may include a new information element (IE) containing a data structure representing a fully qualified domain name (FQDN). This FQDN may be interpreted as being used for a DNS NAPTR query.

[0060] Finally, based on the second domain name from the redirection response, method 200 redirects the communication from the first security gateway (e.g., in PLMN B) to the third security gateway in the second mobile communication network (e.g., in PLMN A) (230). The redirection of the communication 230 may involve dynamically discovering the new target security gateway in the second mobile communication network (e.g., in PLMN A) by performing a second DNS query using the second domain name. The second DNS query may also be a DNS NAPTR query. The first security gateway (e.g., in PLMN B) can then redirect the communication to the new target security gateway (e.g., in PLMN A) based on the result of the second DNS query.

[0061] In some cases, a third security gateway (for example, within PLMN A) could be another SEPP (for example, SEPP112A2) within the same PLMN as the second security gateway (for example, SEPP112A1). For example, if the second security gateway is within PLMN A, the third security gateway could also be within PLMN A. This allows the PLMN to direct specific roaming partners to dedicated SEPPs, increasing flexibility in network management and traffic routing.

[0062] Referring to Figure 3, the figure schematically shows a device 300 for implementing a method 200 for dynamic discovery and redirection of security gateways in a mobile communication network. The device 300 includes a processing circuit 310 configured to perform various operations.

[0063] In some embodiments, the processing circuit 310 is configured to initiate communication between a first security gateway in a first mobile communication network (e.g., PLMN B) and a second security gateway in a second mobile communication network (e.g., PLMN A) based on a first domain name. The first and second security gateways may be SEPP groups within their respective PLMNs. The first domain name may be an FQDN constructed based on the network ID of the second mobile communication network (e.g., PLMN A). The network ID may be a globally unique PLMN ID, and the first domain name may include the PLMN ID and a domain such as "3gppnetwork.org".

[0064] In an implementation from the perspective of the initiating (first) security gateway, the processing circuit 310 is further configured to receive a redirection response from a second security gateway (e.g., in PLMN A). In another implementation from the perspective of the rejecting (second) security gateway, the processing circuit 310 is configured to send a redirection response to the first security gateway (e.g., in PLMN B). The redirection response may indicate a second domain name to be used for DNS-based discovery of another security gateway in the second mobile communication network. The redirection response may be received via an inter-mobile communication network interface such as the inter-PLMN interfaces 120, 130. The redirection response may be an HTTP redirection response informing the first security gateway (e.g., in PLMN B) that another security gateway (e.g., in PLMN A) should be used for communication. The redirection response may include a new IE containing a data structure representing an FQDN. This FQDN may be interpreted as being used for a DNS NAPTR query.

[0065] In some embodiments, based on a second domain name, the processing circuit 310 is configured to redirect communications from a first security gateway in a first mobile communication network (e.g., PLMN B) to a third security gateway in a second mobile communication network (e.g., PLMN A). The redirection of communications may include performing a second DNS query using the second domain name to dynamically discover a new target security gateway. The second DNS query may also be a DNS NAPTR query. The first security gateway (e.g., in PLMN B) can then redirect communications to a new target security gateway (e.g., in PLMN A) based on the result of the second DNS query.

[0066] In some cases, a third security gateway (for example, within PLMN B) could be a different SEPP within the same PLMN as the second security gateway. For example, if the second security gateway is in PLMN A, the third security gateway could also be in PLMN A. This allows PLMNs to direct specific roaming partners to dedicated SEPPs, increasing flexibility in network management and traffic routing.

[0067] Those skilled in the art who benefit from this disclosure will understand that device 300 can be implemented within a SEPP to support dynamic discovery and redirection of security gateways in a mobile communications network. Device 300 includes a processing circuit 310 that initiates communication between security gateways based on a domain name constructed from a network identifier such as a PLMN ID. The processing circuit 310 can also process redirection responses from the SEPP and interpret these responses to dynamically redirect communication to a more appropriate security gateway. With respect to hardware and software, the processing circuit 310 may be used to perform DNS NAPTR queries and process HTTP redirection responses. This circuit may be a combination of a processor and software modules that manage DNS queries, FQDN resolution, and communication routing. Device 300 can dynamically redirect traffic to another SEPP on the same network if the SEPP is not the optimal target for communication, thereby increasing the flexibility and efficiency of the network. This redirection mechanism may be implemented using standard networking hardware combined with software that conforms to the 3GPP protocol, such as that defined for the N32 interface.

[0068] Referring to Figure 4, a more detailed sequence diagram 400 of the dynamic discovery and redirection process for security gateway 112 in a mobile communication network is shown. The illustrated process involves four main entities: the first security gateway 112B, the DNS server 410, the second security gateway 112A1, and the third security gateway 112A2.

[0069] The sequence begins with the first security gateway 112B (e.g., PLMN B) constructing a first domain name for the target security gateway in the second mobile communication network (e.g., PLMN A) based on the network ID of the second mobile communication network (step 211). This construction of the first domain name may be based on a globally unique PLMN ID, and the first domain name may be a well-known FQDN containing the PLMN ID and a domain such as "3gppnetwork.org". The well-known FQDN is an initial domain name constructed based on information of the target mobile network (e.g., PLMN A). It is called "well-known" because it follows standardized naming conventions and allows any network to locate a security gateway (SEPP) in another network. This FQDN is generated using the PLMN ID of the second mobile communication network (e.g., PLMN A). The PLMN ID may consist of a mobile country code (MCC) and a mobile network code (MNC) that uniquely identifies the network.

[0070] Next, the first security gateway 112B performs a DNS query using the first domain name (well-known FQDN) to obtain a list of security gateways in the second mobile communication network (step 212). The DNS query may be a NAPTR query, which is a specific type of DNS query used for service discovery. The well-known FQDN may be used in the first DNS query to discover SEPPs in the target network (e.g., PLMN A). This domain name acts as a unique identifier for the target network, enabling the security gateway to perform the DNS lookup itself. The NAPTR query resolves the well-known FQDN to a list of potential SEPPs in the target network. These SEPPs are security gateways that manage secure communication between different PLMNs. The response to this query may provide a preferred list of SEPPs, including their capabilities and services, which the initiating SEPP (112B) can use to establish secure communication with the most appropriate SEPP in PLMN A. By using NAPTR queries, the primary security gateway can dynamically discover available SEPPs in the target network, enabling real-time decisions about routing traffic through the optimal gateway.

[0071] DNS server 410 responds with a list of target security gateways (step 213). When DNS server 410 receives a DNS query from the first security gateway 112B, it can process the request by looking up records associated with the well-known FQDNs provided in advance in the query. DNS server 410 may be responsible for maintaining a database of domain names, including security gateways or SEPPs available in the target network, and their corresponding network services. After resolving the query, DNS server 410 responds by returning a list of target security gateways, for example, in the form of FQDNs. Each FQDN may represent a SEPP in the second mobile communications network (e.g., PLMN A). This response may also include additional details such as priority and weight values ​​for each SEPP, enabling the initiating security gateway to select the most appropriate SEPP for communication. If the query is a NAPTR query, DNS server 410 may return not only the FQDNs of the available SEPPs, but also service records indicating the specific functions or services that each SEPP is configured to handle. This may allow the initiating security gateway 112B to resolve the appropriate SEPP for the type of communication or traffic being handled.

[0072] Upon receiving the list, the first security gateway 112B selects a security gateway from the list (step 214) and initiates communication with the selected second security gateway 112A1 in the second mobile communication network (step 215). When the first security gateway 112B receives a list of SEPPs from the DNS server 410, it can proceed to select one of the SEPPs based on several potential criteria, such as priority, load, geographical location, or service type. The list returned by the DNS server 410 may include additional metadata, such as priority and weight, to help the gateway determine which SEPP is best suited for communication.

[0073] After selecting an appropriate SEPP112A1 in the second network, the first security gateway 112B initiates communication. To do this, the FQDN of the selected SEPP may need to be further resolved to an IP address using another DNS query, such as an A or AAAA query for IPv4 or IPv6 addresses, respectively. Once the IP address is obtained, the first security gateway 112B can establish a secure communication link to the selected SEPP112A1 in the second mobile communication network. This communication initiation 215 may involve exchanging signaling messages over an encrypted channel, possibly such as TLS, since SEPPs are designed to protect the edge of the network. Traffic between the two SEPPs can now be secured, typically ensuring that sensitive data remains protected while it travels between the two mobile networks, in scenarios such as roaming or inter-network communication. The SEPP112A1 in the second mobile network can then handle routing and security of traffic within its own network.

[0074] However, the second security gateway 112A1 responds with a redirection response containing a second domain name to be used for DNS-based discovery of another security gateway in the second mobile communication network (step 220). This redirection response may be an HTTP redirection response informing the first security gateway 112B that another security gateway should be used for communication. The redirection response may contain an IE containing a data structure representing an FQDN, which may be interpreted as being used for DNS NAPTR queries. When the first security gateway 112B initiates communication with the selected second security gateway 112A1 in the target network (PLMN A), the second gateway 112A1 may determine that it is not the most suitable SEPP to handle the traffic. In response, the second security gateway 112A1 issues an HTTP redirection response informing the initiating SEPP 112B that the communication should be directed to a different security gateway within the same network. The first security gateway 112B can interpret the second FQDN from the HTTP redirection response and use it to initiate a new DNS discovery process.

[0075] SEPP-A1 within PLMN-A receives an HTTP request (N32 interface) from SEPP-B within PLMN-B. However, SEPP-A1 decides that SEPP-B should communicate with a different entity SEPP within PLMN-A and therefore redirects the request. To redirect SEPP-B to the correct SEPP within PLMN-A, SEPP-A1 sends an HTTP 307 Temporary Redirect response. This response may contain a data structure called ExtRedirectResponse, which may contain attributes. The first attribute ("cause" attribute) may specify the reason or trigger for the redirection. The first attribute may provide the receiving entity (in this case, SEPP-B) with information about why the redirection is occurring. In this context, the first attribute may signal that the redirection involves a discovery process and instruct SEPP-B to look for another service or entity in the network. The second attribute ("seppFqdnForDiscovery" attribute) may contain an Fully Qualified Domain Name (FQDN) that serves as a reference for the receiving entity (SEPP-B) to initiate a new discovery process. The second attribute may point to a target or service that the receiving entity should locate, typically by performing a DNS query. The FQDN can act as a dynamic address that the system can use to find the most appropriate resource without pre-configuring a specific target. • The "cause" attribute is set to a value such as "SEPP_REDIRECTION_WITH_DISCOVERY" to indicate that the redirection should be accompanied by a discovery procedure. • The "seppFqdnForDiscovery" attribute contains the fully qualified domain name (FQDN) that SEPP-B uses to discover new SEPPs via DNS-based discovery.

[0076] SEPP-B may ignore the standard HTTP location header in the response. Instead, it may use the FQDN provided in the "seppFqdnForDiscovery" attribute. Using this FQDN, SEPP-B can perform a DNS NAPTR query to automatically discover the appropriate SEPP within PLMN-A.

[0077] Therefore, upon receiving a redirection response from the second gateway 112A1, the first security gateway 112B dynamically discovers the new target security gateway by performing a second DNS query using the second domain name (second FQDN) (step 232). The second DNS query may be a second NAPTR query. The second FQDN may be used in the second DNS query to discover a new SEPP in the target network (e.g., PLMN A).

[0078] DNS server 410 responds with a list of new target security gateways (step 233). The first security gateway 112B then selects a new security gateway from this updated list based on several potential criteria such as priority, load, geographical location, or service type (step 234). In this case, the new security gateway is the third security gateway 112A2.

[0079] After selecting a new target SEPP112A2 in the second network, the first security gateway 112B initiates redirect communication with the newly selected third security gateway 112A2 (step 235). To do this, the FQDN of the new target SEPP selected from the list may need to be further resolved to an IP address using another DNS query, such as an A or AAAA query for IPv4 or IPv6 addresses, respectively. Once the IP address is obtained, the first security gateway 112B can establish a secure communication link to the selected new target SEPP112A2 in the second mobile communication network. This communication initiation 235 may include exchanging signaling messages over an encrypted channel such as TLS, as SEPPs are designed to protect the edge of the network. Traffic between the two SEPPs 112B, SEPP112A2 is protected, ensuring that sensitive data remains protected while it travels between the two mobile networks, typically in scenarios such as roaming or inter-network communication. Next, the SEPP112A2 in the second mobile network can handle the routing and security of traffic within its own network.

[0080] Embodiments of this disclosure can handle all SEPP-to-SEPP communication initiations similarly, regardless of whether there is redirection or not. When initiating the resolution of a well-known FQDN, a list of SEPP FQDNs is obtained. Communication is made with the SEPP, and the SEPP sends a redirect. The new target FQDN from the redirect can then be resolved again through a similar discovery procedure, namely, performing NAPTR resolution on that FQDN received in the redirect. In this way, the initiating SEPP can learn a list of possible new target SEPPs. In the case of redirects within the same PLMN, i.e., when a redirect occurs to another SEPP where the FQDN is already in the list received via DNS discovery, the new NAPTR request is of little value. However, there is a use case where the FQDN received in the redirect is a different generic FQDN, and the list of SEPP FQNDs received from the NAPTR request based on this new generic FQDN is different. It may be possible for a PLMN to have multiple SEPPs for the same PLMN ID. There may be cases where it is not necessary to notify the roaming partner in advance about the intended destination SEPP, and only dynamic discovery is intended.

[0081] Embodiments of this disclosure define a new mechanism for SEPP HTTP redirection responses by introducing new API attributes, ensuring that the RedirectionResponse data type yields a fully qualified domain name (FQDN) that can be used for a new SEPP discovery procedure, and a new NAPTR query that helps retrieve a list of possible new target SEPPs. This new mechanism ensures dynamic discovery of destination SEPPs and avoids the need to notify roaming partners in advance about the expected response SEPPs. The proposed solution involves using HTTP redirects and defining a new IE for redirect response messages that includes a data structure representing the FQDN. This FQDN can be interpreted as being used for DNS NAPTR queries (as opposed to the HTTP location header, which is defined as the host FQDN).

[0082] The proposed solution allows the use of HTTP redirects for N32 interfaces, as specified in TS29.500 for non-N32 interfaces, and the HTTP location header may be ignored. Instead of the location header, a new IE (different from the already defined IE) may be defined to be used. The new IE may contain a data structure representing the Fully Qualified Domain Name (FQDN). This FQDN may be used by the SEPP to receive the redirect response in order to issue a DNS NAPTR query for SEPP discovery.

[0083] This disclosure provides methods, apparatus, and systems for dynamic discovery and redirection of security gateways in mobile communications networks. This may be particularly relevant in the context of 5G networks, where security edge protected proxies (SEPPs) play a crucial role in protecting the edge of mobile networks and facilitating secure inter-network communications. The disclosed methods and apparatus address the need for more flexible and dynamic routing of traffic to specific SEPPs based on various criteria or selections, a capability lacking in current existing standards. This may be particularly beneficial in scenarios where public land mobile network (PLMN) operators direct certain roaming partners to a dedicated SEPP and use different SEPPs for other roaming partners. The disclosed methods and apparatus also overcome the limitations of the static nature of DNS responses in current setups, enabling a new round of DNS-based SEPP discovery during redirection, thereby facilitating advanced load balancing or failover strategies. Furthermore, the disclosed methods and apparatus eliminate the need for pre-configuration or knowledge by the initiating network, thereby reducing complexity in network management and enhancing agility in responding to changing network conditions or security requirements.

[0084] The aspects and features described in relation to one particular example above may also be combined with one or more further examples to replace identical or similar features in further examples, or to introduce additional features to further examples.

[0085] Examples may further include (computer) programs that contain program code for performing one or more of the methods described above when the program is executed on a computer, processor, or other programmable hardware component, or related thereto. Thus, steps, actions, or processes of different methods of the methods described above may also be performed by a programmed computer, processor, or other programmable hardware component. Examples may also include program storage devices such as digital data storage media that are machine-readable, processor-readable, or computer-readable and encode and / or contain machine-executable, processor-executable, or computer-executable programs and instructions. Program storage devices may include, or may be, digital storage devices, magnetic storage media such as magnetic disks and magnetic tapes, hard disk drives, or optically readable digital data storage media. Other examples may also include computers, processors, control units, (field)programmable logic arrays ((F)PLAs), (field)programmable gate arrays ((F)PGAs), graphics processor units (GPUs), application-specific integrated circuits (ASICs), integrated circuits (ICs), or system-on-a-chip (SoC) systems programmed to perform the steps of the method described above.

[0086] Furthermore, it should be understood that any disclosure of steps, processes, actions, or functions disclosed herein or in the claims should not be construed as implying that these actions necessarily depend on the order in which they are described, unless otherwise explicitly stated in each case or required for technical reasons. Therefore, the foregoing descriptions do not limit the execution of any steps or functions to a specific order. Furthermore, in further examples, a single step, function, process, or action may include and / or be broken down into several substeps, functions, processes, or actions.

[0087] When several embodiments are described in relation to a device or system, these embodiments should also be understood as descriptions of the corresponding methods. For example, blocks, devices, or functional embodiments of a device or system may correspond to features such as method steps of the corresponding method. Therefore, embodiments described in relation to a method should also be understood as descriptions of the characteristics or functional features of the corresponding blocks, corresponding elements, corresponding devices, or corresponding systems.

[0088] The following claims are incorporated into the detailed description, and each claim may stand alone as a distinct example. It should also be noted that, while in a claim a dependent claim refers to a specific combination with one or more other claims, other embodiments may also include combinations of dependent claims with the subject matter of any other dependent or independent claim. Such combinations are expressly proposed herein unless it is stated that no particular combination is intended in any given case. Furthermore, features of a claim should also be included in any other independent claim, even if the claim is not directly defined as depending on any other independent claim.

Claims

1. A method (200) for dynamic discovery and redirection of a security gateway (112) in a mobile communication network, Step (210) of initiating communication between a first security gateway (112B) in a first mobile communication network and a second security gateway (112A1) in a second mobile communication network based on a first domain name, Step (220) of receiving a redirection response from the second security gateway, wherein the redirection response indicates a second domain name used for DNS-based discovery of another security gateway in the second mobile communication network, A method characterized by including the step (230) of redirecting the communication from the first security gateway (112B) in the first mobile communication network to the third security gateway (112A2) in the second mobile communication network based on the second domain name.

2. The method according to claim 1, characterized in that the inter-mobile communication network interface (120, 130) is an inter-PLMN interface.

3. Step (210) of initiating communication between the first security gateway (112B) and the second security gateway (112A1) is: The method according to claim 1, further comprising the step (211) of constructing the first domain name for a target security gateway in the second mobile communication network based on the network ID of the second mobile communication network.

4. Step (210) of initiating communication between the first security gateway and the second security gateway is, The method according to claim 1, further comprising the step of performing a DNS query using the first domain name (212) to obtain a list of security gateways in the second mobile communication network.

5. The method according to 4, further comprising the steps of selecting a security gateway from the list (214) and initiating communication between the first security gateway and the selected second security gateway in the second mobile communication network.

6. Step (230) of initiating communication between the first security gateway and the third security gateway is, The method according to claim 1, further comprising the step of performing a second DNS query using the second domain name (232) to dynamically discover a new target security gateway.

7. The method according to 6, further comprising the step (235) of redirecting the communication to the new target security gateway based on the result of the second DNS query.

8. The method according to 4, characterized in that the DNS queries include each DNS naming authority pointer (NAPTR) query.

9. The method according to claim 1, characterized in that the security gateway includes each security edge protection proxy (SEPP).

10. The method according to claim 1, characterized in that the first mobile communication network and the second mobile communication network each include a 5G standalone (SA) network.

11. The method according to claim 1, characterized in that the plurality of domain names include their respective fully qualified domain names (FQDNs).

12. The method according to claim 1, characterized in that the redirection response includes a hypertext transfer protocol (HTTP) redirection response.

13. A device (300) for dynamic discovery and redirection of security gateways in a mobile communication network, The steps include: initiating communication between a first security gateway in a first mobile communication network and a second security gateway in a second mobile communication network based on a first domain name; A step of receiving a redirection response from the second security gateway, wherein the redirection response indicates a second domain name used for DNS-based discovery of another security gateway in the second mobile communication network, The apparatus is characterized by including a processing circuit (310) configured to perform the step of redirecting the communication from the first security gateway in the first mobile communication network to the third security gateway in the second mobile communication network based on the second domain name.

14. A method for dynamic discovery and redirection of security gateways in a mobile communication network, The steps include: initiating communication between a first security gateway in a first mobile communication network and a second security gateway in a second mobile communication network based on a first domain name; A method comprising the step of transmitting a redirection response from the second security gateway to the first security gateway, wherein the redirection response indicates a second domain name used for DNS-based discovery of another security gateway in the second mobile communication network.

15. A device for dynamic discovery and redirection of security gateways in a mobile communication network, The steps include: initiating communication between a first security gateway in a first mobile communication network and a second security gateway in a second mobile communication network based on a first domain name; The apparatus is characterized by including a processing circuit configured to perform the steps of: transmitting a redirection response from the second security gateway to the first security gateway, wherein the redirection response indicates a second domain name used for DNS-based discovery of another security gateway in the second mobile communication network.

Images