WO2024033782A1

WO2024033782A1 - Sepp support of disaster roaming

Info

Publication number: WO2024033782A1
Application number: PCT/IB2023/057963
Authority: WO
Inventors: Saurabh Khare; Bruno Landais
Original assignee: Nokia Technologies Oy
Priority date: 2022-08-06
Filing date: 2023-08-07
Publication date: 2024-02-15

Abstract

Systems, methods, and software for supporting disaster roaming. In one embodiment, an initiating Security Edge Protection Proxy (SEPP) of a visited mobile network initiates N32 handshake procedures with a responding SEPP in another mobile network to establish an N32 connection with the responding SEPP regarding a disaster roaming service. The initiating SEPP sends an N32 handshake procedure request toward the responding SEPP with an indication that an intended usage purpose of the N32 connection is dedicated to the disaster roaming service.

Description

SEPP SUPPORT OF DISASTER ROAMING

Technical Field

This disclosure is related to the field of communication systems and, in particular, to next generation networks.

Background

Next generation networks, such as Fifth Generation (5G), denote the next major phase of mobile telecommunications standards beyond Fourth Generation (4G) standards. In comparison to 4G networks, next generation networks may be enhanced in terms of radio access and network architecture. Next generation networks intend to utilize new regions of the radio spectrum for Radio Access Networks (RANs), such as millimeter wave bands.

A user of a 5G network has a home Public Land Mobile Network (HPLMN), and the user may access services when located in the coverage area of the HPLMN. When a user roams onto another PLMN (i.e., a visited PLMN or VPLMN) different than their HPLMN, the 5G Core Network (5GC) of the HPLMN is able to interconnect or interwork with the 5GC of the VPLMN so that the user can access services even when roaming outside of their HPLMN.

Security can be an issue when a user roams into a VPLMN. The Third Generation Partnership Project (3GPP) has stated that a Security Edge Protection Proxy (SEPP) be implemented for secure interconnect between PLMNs in roaming scenarios. A SEPP is an entity sitting at the perimeter of a PLMN and is configured to protect control plane messages as is further described in 3GPP TS 33.501 (vl7.6.0), which is incorporated by reference as if fully included herein. In one example of a roaming scenario, a SEPP is implemented at the edge of a VPLMN, and another SEPP is implemented at the edge of the HPLMN. Control plane messages are exchanged between the SEPPs over the N32 interface.

The 3GPP has introduced a disaster roaming service (e.g., voice call and data service) in 3GPP TS 23.501 (vl7.5.0), which is incorporated by reference as if fully included herein. A mobile network may fail to provide service in the event of a disaster (e.g., a fire, natural disaster, etc.). The disaster roaming service may therefore enable User Equipment (UE) of a given PLMN to obtain connectivity service (e.g., voice call or mobile data service) from another PLMN for the area where a disaster condition applies. When a disaster condition applies, users may have the opportunity to mitigate service interruptions and failures through the disaster roaming service from a different PLMN that supports the disaster roaming service. However, the role and/or functions of a SEPP regarding disaster roaming has yet to be defined.

Summary

Described herein are enhancements to a SEPP and/or other network entities regarding disaster roaming. A SEPP, for example, is configured to initiate N32 handshake procedures with another SEPP to establish an N32 connection for secure interconnect. When disaster roaming applies, the SEPP is further configured to provide an N32 purpose indicator to the other SEPP indicating that an intended usage purpose of the N32 connection is dedicated to disaster roaming. Thus, an N32 connection may be established that is dedicated or limited to disaster roaming, and not used for other purposes (e.g., roaming traffic). One technical benefit is SEPPs are able to support secure interconnection for disaster roaming scenarios.

In one embodiment, a Security Edge Protection Proxy (SEPP) of a visited mobile network comprises at least one processor, and at least one memory including computer program code. The at least one memory and the computer program code configured to, with the at least one processor, cause the SEPP at least to initiate N32 handshake procedures with a responding SEPP in another mobile network to establish an N32 connection with the responding SEPP regarding a disaster roaming service, and send an N32 handshake procedure request toward the responding SEPP with an indication that an intended usage purpose of the N32 connection is dedicated to the disaster roaming service.

In one embodiment, the N32 handshake procedure request comprises a Hypertext Transfer Protocol (HTTP) POST request of a security capability negotiation procedure, and security negotiate request data of the HTTP POST request includes the indication of the intended usage purpose of the N32 connection.

In one embodiment, the indication in the N32 handshake procedure request comprises a disaster roaming enumeration value of an N32 purpose enumeration that indicates usage of the N32 connection is dedicated to disaster roaming, or indicates usage of the N32 connection is dedicated to a disaster roaming test. In one embodiment, the at least one processor causes the SEPP at least to send the N32 handshake procedure request toward the responding SEPP with an expiry time value for the N32 connection.

In one embodiment, the at least one processor causes the SEPP at least to receive an NF service message from a Network Function (NF), process the NF service message to identify a disaster roaming indicator included in the NF service message, and initiate the N32 handshake procedures with the responding SEPP in response to the disaster roaming indicator in the NF service message.

In one embodiment, the NF service message comprises a Hypertext Transfer Protocol (HTTP) request, and the at least one processor causes the SEPP at least to process a “3gpp-Sbi-Interplmn-Purpose” header of the HTTP request to identify the disaster roaming indicator.

In one embodiment, the at least one processor causes the SEPP at least to receive an N32 handshake procedure response from the responding SEPP with an indication that an allowed usage purpose of the N32 connection is dedicated to the disaster roaming service, and send an N32 traffic request toward the responding SEPP over the N32 connection with the disaster roaming indicator.

In one embodiment, the at least one processor causes the SEPP at least to format an NF management request to register an NF profile toward an NF Repository Function (NRF) with the NF profile including a disaster roaming support indicator indicating that the SEPP supports the disaster roaming service, and send the NF management request toward the NRF.

In one embodiment, the at least one processor causes the SEPP at least to select the responding SEPP in the other mobile network without a roaming agreement.

In one embodiment, the at least one processor causes the SEPP at least to construct a Fully-Qualified Domain Name (FQDN) for the responding SEPP based on a standardized format for SEPPs, and query a Domain Name Service (DNS) with the FQDN in the standardized format to acquire an address of the responding SEPP even though no roaming agreement exists with the other mobile network.

In one embodiment, a method of supporting disaster roaming is disclosed. The comprises initiating, at an initiating SEPP of a visited mobile network, N32 handshake procedures with a responding SEPP in another mobile network to establish an N32 connection with the responding SEPP regarding a disaster roaming service, and sending an N32 handshake procedure request from the initiating SEPP toward the responding SEPP with an indication that an intended usage purpose of the N32 connection is dedicated to the disaster roaming service.

In one embodiment, sending the N32 handshake procedure request comprises sending the N32 handshake procedure request from the initiating SEPP toward the responding SEPP with the indication and an expiry time value for the N32 connection.

In one embodiment, the method further comprises receiving, at the responding SEPP, the N32 handshake procedure request from the initiating SEPP, and sending an N32 handshake procedure response from the responding SEPP to the initiating SEPP with an indication that an allowed usage purpose of the N32 connection is dedicated to the disaster roaming service.

In one embodiment, the method further comprises sending an N32 traffic request from the initiating SEPP toward the responding SEPP over the N32 connection with a disaster roaming indicator.

In one embodiment, the method further comprises sending an N32 traffic response from the responding SEPP toward the initiating SEPP over the N32 connection with the disaster roaming indicator.

In one embodiment, the method further comprises selecting, at the initiating SEPP, the responding SEPP in the other mobile network without a roaming agreement.

In one embodiment, the method further comprises constructing, at the initiating SEPP, a Fully-Qualified Domain Name (FQDN) for the responding SEPP based on a standardized format for SEPPs, and querying, at the initiating SEPP, a Domain Name Service (DNS) with the FQDN in the standardized format to acquire an address of the responding SEPP even though no roaming agreement exists with the other mobile network.

In one embodiment, the method further comprises formatting, at the initiating SEPP, an NF management request to register an NF profile of the initiating SEPP toward an NF Repository Function (NRF) with the NF profile including a disaster roaming support indicator indicating that the initiating SEPP supports the disaster roaming service, and sending the NF management request from the initiating SEPP toward the NRF.

In one embodiment, the method further comprises receiving, at the NRF, the NF management request from the initiating SEPP, and registering the NF profile for the initiating SEPP that includes the disaster roaming support indicator. In one embodiment, the method further comprises formatting, at a Network Function (NF), an NF discovery message to discover services offered by SEPPs as registered in the NRF, where the NF discovery message indicates disaster roaming as a query parameter. The method further comprises sending the NF discovery request from the NF toward the NRF, receiving an NF discovery response from the NRF including search results indicating one or more SEPPs that support disaster roaming, and selecting the initiating SEPP that supports disaster roaming based on the search results.

In one embodiment, a SEPP of a mobile network comprises at least one processor, and at least one memory including computer program code. The at least one memory and the computer program code configured to, with the at least one processor, cause the SEPP at least to receive an N32 handshake procedure request from an initiating SEPP in another visited mobile network to establish an N32 connection with the initiating SEPP regarding a disaster roaming service, where the N32 handshake procedure request includes an indication that an intended usage purpose of the N32 connection is dedicated to the disaster roaming service. The at least one processes causes the SEPP at least to send an N32 handshake procedure response toward the initiating SEPP with an indication that an allowed usage purpose of the N32 connection is dedicated to the disaster roaming service.

In one embodiment, the at least one processor causes the SEPP at least to receive an N32 traffic request from the initiating SEPP over the N32 connection with a disaster roaming indicator, and send an N32 traffic response toward the initiating SEPP over the N32 connection with the disaster roaming indicator.

In one embodiment, the at least one processor causes the SEPP at least to receive the N32 handshake procedure request from the initiating SEPP with an expiry time value for the N32 connection, and send an N32 handshake procedure response to the initiating SEPP with an expiry time value for the N32 connection.

In one embodiment, an NF Repository Function (NRF) comprises at least one processor, and at least one memory including computer program code. The at least one memory and the computer program code configured to, with the at least one processor, cause the NRF at least to receive an NF management request from a Security Edge Protection Proxy (SEPP) to register an NF profile, and register the NF profile for the SEPP with a disaster roaming support indicator that indicates whether the SEPP supports a disaster roaming service.

In one embodiment, the at least one processor causes the NRF at least to receive an NF discovery request from a Network Function (NF) that includes disaster roaming as a query parameter, identify one or more SEPPs having a corresponding NF profile that contains the disaster roaming support indicator, and send an NF discovery response to the NF that indicates one or more SEPPs that support the disaster roaming service.

In one embodiment, a Network Function (NF) comprises at least one processor, and at least one memory including computer program code. The at least one memory and the computer program code configured to, with the at least one processor, cause the NF at least to format an NF discovery message to discover services offered by Security Edge Protection Proxies (SEPPs) as registered in an NF Repository Function (NRF), where the NF discovery message includes disaster roaming as a query parameter. The at least one processor causes the NF at least to send the NF discovery request toward the NRF, receive an NF discovery response from the NRF indicating one or more SEPPs that support disaster roaming, and select a SEPP that supports disaster roaming as an initiating SEPP based on the search results from the NRF.

In one embodiment, the at least one processor causes the NF at least to format an NF service message requesting an NF service offered by another NF in another mobile network, and send the NF service message to the initiating SEPP with a disaster roaming indicator.

In one embodiment, the NF service message comprises a Hypertext Transfer Protocol (HTTP) request, and the at least one processor causes the NF at least to insert the disaster roaming indicator in a “3gpp-Sbi-Interplmn-Purpose” header of the HTTP request.

In one embodiment, a SEPP of a visited mobile network comprises a means for initiating N32 handshake procedures with a responding SEPP in another mobile network to establish an N32 connection with the responding SEPP regarding a disaster roaming service, and a means for sending an N32 handshake procedure request toward the responding SEPP with an indication that an intended usage purpose of the N32 connection is dedicated to the disaster roaming service. Other embodiments may include computer readable media, other systems, or other methods as described below.

The above summary provides a basic understanding of some aspects of the specification. This summary is not an extensive overview of the specification. It is intended to neither identify key or critical elements of the specification nor delineate any scope of the particular embodiments of the specification, or any scope of the claims. Its sole purpose is to present some concepts of the specification in a simplified form as a prelude to the more detailed description that is presented later.

Description of the Drawings

Some embodiments of the invention are now described, by way of example only, and with reference to the accompanying drawings. The same reference number represents the same element or the same type of element on all drawings.

FIG. 1 illustrates a high-level architecture of a 5G system.

FIG. 2 illustrates a non-roaming architecture of a 5G system.

FIG. 3 illustrates a roaming architecture of a 5G system.

FIG. 4 illustrates another roaming architecture of a 5G system.

FIG. 5 illustrates inter-PLMN communications.

FIG. 6 illustrates inter-PLMN communications for a disaster roaming scenario in an illustrative embodiment.

FIG. 7 is a block diagram of a SEPP in an illustrative embodiment.

FIGS. 8A-8B are flow charts illustrating methods of supporting disaster roaming in SEPPs in an illustrative embodiment.

FIG. 9 is a signaling diagram of an N32 handshake procedure in an illustrative embodiment.

FIG. 10 is a signaling diagram of a security capability negotiation procedure in an illustrative embodiment.

FIG. 11 illustrates an enhanced N32 purpose enumeration in an illustrative embodiment.

FIG. 12 is a signaling diagram of a message forwarding procedure in an illustrative embodiment.

FIGS. 13A-13B are flow charts illustrating other methods of supporting disaster roaming in SEPPs in an illustrative embodiment. FIG. 14 is a signaling diagram of an N32 handshake procedure in another illustrative embodiment.

FIG. 15 is a flow chart illustrating a method of initiating N32 handshake procedures in an initiating SEPP in an illustrative embodiment.

FIGS. 16-17 are signaling diagrams of initiating an N32 handshake procedure in an illustrative embodiment.

FIGS. 18A-18B are flow charts illustrating methods of controlling disaster roaming in an illustrative embodiment.

FIG. 19 illustrates inter-PLMN communications for a disaster roaming scenario in another illustrative embodiment.

FIG. 20 is a flow chart illustrating a method of registering a SEPP toward an NRF in an illustrative embodiment.

FIG. 21 is a block diagram of an NRF in an illustrative embodiment.

FIG. 22 is a flow chart illustrating a method of registering an NF profile of a SEPP in an illustrative embodiment.

FIG. 23 is a block diagram of a network element in an illustrative embodiment.

FIG. 24 is a flow chart illustrating a method of discovering a SEPP that supports a disaster roaming service in an illustrative embodiment.

FIG. 25 is a flow chart illustrating another method of discovering a SEPP that supports a disaster roaming service in an illustrative embodiment.

FIG. 26 is a flow chart illustrating a method of initiating an NF service in an illustrative embodiment.

FIG. 27 is a flow chart illustrating a method of reaching a peer SEPP in an illustrative embodiment.

FIG. 28 is a signaling diagram illustrating SEPP support of disaster roaming in an illustrative embodiment.

Description of Embodiments

The figures and the following description illustrate specific exemplary embodiments. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the embodiments and are included within the scope of the embodiments. Furthermore, any examples described herein are intended to aid in understanding the principles of the embodiments, and are to be construed as being without limitation to such specifically recited examples and conditions. As a result, the inventive concept(s) is not limited to the specific embodiments or examples described below, but by the claims and their equivalents.

FIG. 1 illustrates a high-level architecture of a 5G system 100. A 5G system 100 is a communication system (e.g., a 3GPP system) comprising a 5G Access Network ((R)AN) 102, a 5G Core Network (CN) 104 (also referred to as 5GC), and 5G User Equipment (UE) 106. Access network 102 may comprise an NG-RAN and/or a non-3GPP access network connecting to a 5G core network 104. Access network 102 may support Evolved-UMTS Terrestrial Radio Access Network (E-UTRAN) access (e.g., through an eNodeB, gNodeB, and/or ng-eNodeB), Wireless Local Area Network (WLAN) access, fixed access, satellite radio access, new Radio Access Technologies (RAT), etc. Core network 104 interconnects access network 102 with a data network (DN) 108. Core network 104 is comprised of Network Functions (NF) 110, which may be implemented either as a network element on dedicated hardware, as a software instance running on dedicated hardware, as a virtualized function instantiated on an appropriate platform (e.g., a cloud infrastructure), etc. Data network 108 may be an operator external public or private data network, or an intra-operator data network (e.g., for IMS services). UE 106 is a 5G capable device configured to register with core network 104 to access services. UE 106 may be an end user device, such as a mobile phone (e.g., smartphone), a tablet or PDA, a computer with a mobile broadband adapter, etc. UE 106 may be enabled for voice services, data services, Machine-to-Machine (M2M) or Machine Type Communications (MTC) services, and/or other services.

FIG. 2 illustrates a non-roaming architecture 200 of a 5G system. The architecture 200 in FIG. 2 is a service-based representation, as is further described in 3GPP TS 23.501. Architecture 200 is comprised of Network Functions (NF) for a core network 104, and the NFs for the control plane (CP) are separated from the user plane (UP). The control plane of the core network 104 includes an Authentication Server Function (AUSF) 210, an Access and Mobility Management Function (AMF) 212, a Session Management Function (SMF) 214, a Policy Control Function (PCF) 216, a Unified Data Management (UDM) 218, a Network Slice Selection Function (NSSF) 220, and an Application Function (AF) 222. The control plane of the core network 104 further includes a Network Exposure Function (NEF) 224, an NF Repository Function (NRF) 226, a Service Communication Proxy (SCP) 228, a Network Slice Admission Control Function (NSACF) 230, a Network Slice-specific and SNPN Authentication and Authorization Function (NSSAAF) 232, and an Edge Application Server Discovery Function (EASDF) 234. The user plane of the core network 104 includes one or more User Plane Functions (UPF) 240 that communicate with data network 108. UE 106 is able to access the control plane and the user plane of the core network 104 through (R)AN 102.

Various network functions of 5G system 100 may also be referred to herein as “network elements” or “network entities”. A network element or network entity includes functions, operations, etc., and the underlying hardware or physical devices (e.g., processors) that are programmed to perform the functions.

A UE 106 of a 5G system has a home mobile network (i.e., HPLMN), and the UE 106 may access services when located in the coverage area of the HPLMN. An HPLMN is the PLMN in which the profile of a mobile subscriber is held. When a user roams onto another mobile network (i.e., VPLMN) different than their HPLMN, the 5G Core Network (5GC) 104 of the HPLMN is able to interconnect or interwork with the 5GC of the VPLMN so that the user can access services even when roaming outside of their HPLMN.

FIG. 3 illustrates a roaming architecture 300 of a 5G system. The roaming architecture 300 in FIG. 3 illustrates a local breakout scenario in a service-based representation, as is further described in 3GPP TS 23.501. A HPLMN 302 and a serving or visited PLMN (VPLMN 304) are shown for roaming architecture 300. A local breakout (LBO) is a roaming scenario for a Protocol Data Unit (PDU) Session where the PDU Session Anchor and its controlling SMF 214 are located in the serving PLMN (VPLMN 304). Data traffic is routed directly from the VPLMN 304 to the data network 108 while authentication and handling of subscription data is handled in HPLMN 302. Thus, only signaling is routed to HPLMN 302.

FIG. 4 illustrates another roaming architecture 400 of a 5G system. The roaming architecture 400 in FIG. 4 illustrates a home routed scenario in a service-based representation, as is further described in 3GPP TS 23.501. In a home routed scenario, data traffic from VPLMN 304 is routed to data network 108 via HPLMN 302. Along with the signaling data, bearer data is also routed to HPLMN 302.

Security can be an issue when a user roams into a VPLMN 304. The 3GPP has stated that a SEPP be implemented for secure interconnect between PLMNs in roaming scenarios. As discussed above, a SEPP is an apparatus, system, entity, etc., sitting at the perimeter of a PLMN and is configured to protect control plane messages. In FIGS. 3-4, a SEPP 312 (also referred to as hSEPP) is implemented at the edge of the HPLMN 302, and a SEPP 314 (also referred to as a vSEPP) is implemented at the edge of the VPLMN 304. Control plane messages are exchanged between SEPP 312 and SEPP 314 over an N32 interface 316.

The 5G architecture is based on a Service-Based Architecture (SBA), which is delivered by a set of interconnected Network Functions (NFs), with authorization to access each other’s services. The roles of NFs within the 5GC may be defined as a service consumer and a service producer. An NF service producer is an NF that exposes a service, and an NF service consumer is an NF that requests a service. The NRF 226 stores NF profiles of the NF service producers, and the NF service consumers are able to query the NRF 226 with a discovery function to obtain the NF profiles of the NF service producers.

FIG. 5 illustrates inter-PEMN communications between a PLMN 502 and PLMN 504. It may be assumed in FIG. 5 that there is a service agreement or roaming agreement between PLMN 502 and PLMN 504. An NF service producer 522 is shown in a PLMN 502 (e.g., HPLMN 302 of FIGS. 3-4), and an NF service consumer 524 is shown in another PLMN 504 (e.g., VPLMN 304 of FIGS. 3-4). To enable a secure interconnect between PLMN 502 and PLMN 504, a SEPP 512 is implemented in PLMN 502 and a SEPP 514 is implemented in PLMN 504.

The N32 interface 316 is used between a SEPP of one PLMN and a SEPP of another PLMN in roaming scenarios as is described in 3GPP TS 29.573 (vl7.5.0), which is incorporated by reference as if fully included herein. The SEPP that is on the NF service consumer side may be referred to as the c-SEPP, and the SEPP that is on the NF service producer side may be referred to as the p-SEPP. The NF service consumer 524 (or Service Communication Proxy (SCP)) may be configured with the c-SEPP or discover the c-SEPP by querying the NRF 226. The NF service producer 522 may be configured with the p- SEPP or discover the p-SEPP by querying the NRF 226. The N32 interface 316 can be logically considered as two separate interfaces: the N32-c interface 533 and the N32-f interface 534. The N32-c interface 533 is a control plane interface between the SEPPs that provides an initial handshake procedure, and negotiation and parameter exchange for the actual N32 message forwarding. The N32-f interface 534 is used to forward HTTP/2 messages of the NF service producers and the NF service consumers in different PLMNs, through the SEPPs of the respective PLMNs. The application layer security protection functionality of the N32-f interface 534 is used if the PRotocol for N32 INterconnect Security (PRINS) is negotiated between the SEPPs using the N32-c interface 533. The N32-f interface 534 provides message protection of the information exchanged between the NF service consumer and the NF service producer across PEMNs by applying application layer security mechanisms, and forwarding of application layer protected messages from a SEPP in one PLMN to a SEPP in another PLMN.

The N32 interface 316 uses Transmission Control Protocol (TCP) as the transport protocol as required by HTTP/2. The scope of the HTTP/2 connection used for the N32-c interface 533 is short-lived. When the initial handshake is completed, the connection is torn down. The scope of the HTTP/2 connection used for the N32-f interface 534 is long-lived. The procedures on the N32 interface 316 are split into two categories: (1) procedures that happen end-to-end between the SEPPs on the N32-c interface 533, and (2) procedures that are used for forwarding of messages on the service based interface between the NF service consumer 524 and the NF service producer 522 via the SEPPs across the N32-f interface 534. Handshake procedures (i.e., N32 Handshake Application Programming Interface (API)) for the N32-c interface 533 is used between the SEPPs in two PLMNs to mutually authenticate each other and negotiate the security mechanism to use over the N32-f interface 534 along with associated security configuration parameters. An HTTP/2 connection is established between the initiating SEPP (or sending SEPP) and the responding SEPP (or receiving SEPP) end-to-end over TLS. The handshake procedures include a security capability negotiation procedure, a parameter exchange procedure, an N32-f context termination procedure, and an N32-f error reporting procedure.

In an embodiment described herein, a SEPP supports disaster roaming within a 5G system. A UE 106 may attempt disaster roaming if there is no available PLMN which is allowable, the UE 106 is not in RM- REGISTERED and CM-CONNECTED state over non- 3GPP access, the UE 106 cannot get service over non-3GPP access, the UE 106 supports the disaster roaming service, the UE 106 has been configured by the HPLMN with an indication of whether disaster roaming is enabled in the UE 106, and a PLMN without a disaster condition is able to accept disaster inbound roamers from the PLMN with the disaster condition.

A UE 106 supporting disaster roaming may be configured with an indication of whether disaster roaming is enabled in the UE 106, an indication of the applicability of “lists of PLMN(s) to be used in disaster condition” provided by a VPLMN, and a list of PLMN(s) to be used in a disaster condition. Activation of disaster roaming is performed by the HPLMN by setting the indication of whether disaster roaming is enabled in the UE 106 to “disaster roaming is enabled in the UE” using the UE Parameters Update (UPU) Procedure. The optional list of PLMN(s) to be used in a disaster condition may be preconfigured in the UE 106 (i.e., USIM), or provided by the HPLMN during and after a successful registration procedure over 3GPP access or non-3GPP access via the Registration Request procedure or UE Configuration Update procedure. While roaming (i.e., not in the HPLMN), the Registered PLMN may provide the list of PLMN(s) to be used in a disaster condition during and after a successful registration procedure to the UE 106 via the Registration Request procedure or UE Configuration Update procedure. This list does not alter any list provided by the HPLMN and is only used if the UE 106 is configured by the HPLMN using the UE Parameters Update Procedure with the indication of applicability of “lists of PLMN(s) to be used in disaster condition” provided by a VPLMN set to “True”.

The NG-RAN in the PLMN that provides the disaster roaming service broadcasts an indication of accessibility for the disaster roaming service, and optionally provides a list of one or more PLMN(s) for which the disaster roaming service is offered by the available PLMN(s) in the impacted area. A UE 106 determines the disaster condition based on the information broadcasted from the NG-RAN providing the disaster roaming service, and performs the network selection and the access control for the disaster roaming.

For a UE 106 to receive the disaster roaming service from a PLMN that provides the disaster roaming service, the UE 106 sends a NAS Registration Request message with the Registration Type value “Disaster Roaming Initial Registration” or “Disaster Roaming Mobility Registration Update”. When the AMF 212 in the PLMN providing the disaster roaming service receives the NAS Registration Request, the AMF 212 controls if the UE 106 is allowed to access the disaster roaming service in the area with the disaster condition. To support the disaster roaming service, the PLMN is configured to support communication with the network entities in the HPLMN of the UE 106 (i.e., configurations related to roaming interfaces for communication between a serving PLMN and the HPLMN are deployed in the affected entities). This communication between the PLMNs need only be enabled during the disaster condition. The disaster roaming service is limited to the impacted geographic area with the disaster condition. The NG-RAN nodes and AMF 212 in the PLMN providing the disaster roaming service are configured with the area information (i.e., a list of Tracking Area Identities (TAIs) which can be formulated by the PLMN providing the disaster roaming service based on the geographic area with the disaster condition in the other PLMN(s)).

In disaster roaming as described above, a UE 106 (if allowed by the HPLMN) may reselect a VPLMN for disaster roaming that was earlier signaled to the UE 106 by the VPLMN experiencing the disaster condition. The VPLMN providing the disaster service may be a VPLMN with which the HPLMN may not necessarily have roaming or interconnect agreements.

FIG. 6 illustrates inter-PLMN communications for a disaster roaming scenario in an illustrative embodiment. Shown in FIG. 6 is a VPLMN 602 (not the HPLMN of UE 106) experiencing a disaster condition. The disaster roaming service may enable UE 106 of VPLMN 602 to obtain connectivity service (e.g., voice call or mobile data service) from another PLMN (i.e., VPLMN 604) supporting the disaster roaming service. In this embodiment, VPLMN 604 is shown to include a Network Function (NF) 612, an NRF 226- 1 (i.e., a local NRF), and a SEPP 614. Also shown in FIG. 6 is another PLMN 606, which may comprise another VPLMN or the HPLMN of UE 106. PLMN 606 is shown to include a Network Function (NF) 622, an NRF 226-2 (i.e., a local NRF), and a SEPP 624. In an SBA, VPLMN 604 may be considered on the service consumer side, and PLMN 606 may be considered on the service producer side. Thus, NF 612 may be considered an NF service consumer, and NF 622 may be considered an NF service producer. In this embodiment, there may or may not be a roaming or interconnect agreement between VPLMN 604 and PLMN 606.

A SEPP as described herein is enhanced to support disaster roaming. FIG. 7 is a block diagram of a SEPP 614 in an illustrative embodiment. In this embodiment, SEPP 614 includes the following subsystems: a network interface component 702, and a SEPP controller 704. Network interface component 702 is a hardware component that exchanges messages, signaling, or packets with other elements. Network interface component 702 may be configured to communicate over a variety of interfaces or reference points, including the N32 interface 316. SEPP controller 704 comprises circuitry, logic, hardware, means, etc., configured to act as a service relay between PLMNs for providing a secured connection.

One or more of the subsystems of SEPP 614 may be implemented on a hardware platform comprised of analog and/or digital circuitry. One or more of the subsystems of SEPP 614 may be implemented on one or more processors 730 that execute instructions 734 (i.e., computer readable code) for software that are loaded into memory 732. A processor 730 comprises an integrated hardware circuit configured to execute instructions 734 to provide the functions of SEPP 614. Processor 730 may comprise a set of one or more processors or may comprise a multi-processor core, depending on the particular implementation. Memory 732 is a non-transitory computer readable storage medium for data, instructions, applications, etc., and is accessible by processor 730. Memory 732 is a hardware storage device capable of storing information on a temporary basis and/or a permanent basis. Memory 732 may comprise a random-access memory, or any other volatile or non-volatile storage device. One or more of the subsystems of SEPP 614 may be implemented on a cloud-computing platform or another type of processing platform.

SEPP 614 may include various other components or sub-systems not specifically illustrated in FIG. 7. Also, other SEPPs (e.g., SEPP 624) of the 5G system may have a similar configuration as SEPP 614.

FIGS. 8A-8B are flow charts illustrating methods 800/850 of supporting disaster roaming in SEPPs in an illustrative embodiment. FIG. 8A illustrates a method 800 performed in an initiating SEPP, and FIG. 8B illustrates a method 850 performed in a responding SEPP. An initiating SEPP is a SEPP that initiates N32 handshake procedures toward another SEPP (i.e., a responding SEPP). The steps of methods 800/850 in FIGS. 8A-8B will be described with reference to a SEPP 614/624 as in FIG. 7, but those skilled in the art will appreciate that methods 800/850 may be performed in other systems or network entities. The steps of the flow charts described herein are not all inclusive and may include other steps not shown, and the steps may be performed in an alternative order.

For method 800 in FIG. 8 A, it is assumed that a UE 106 is roaming in a visited network (e.g., VPLMN 604) that supports a disaster roaming service. To support disaster roaming, initiating SEPP 614 (through network interface controller 702 and/or SEPP controller 704) initiates N32 handshake procedures with a responding SEPP in another mobile network (e.g., SEPP 624 of PLMN 606) to establish an N32 connection (e.g., N32-f connection) with the responding SEPP 624 regarding the disaster roaming service (step 802). Initiating SEPP 614 sends an N32 handshake procedure request (i.e., over the control plane interface or N32-c) toward the responding SEPP 624 with an indication (also referred to as an N32 purpose indicator) that an intended usage purpose of the N32 connection is for the disaster roaming service (step 804). FIG. 9 is a signaling diagram of an N32 handshake procedure in an illustrative embodiment. For the N32 handshake procedure, an initiating SEPP 614 sends an N32 handshake procedure request 901 toward a responding SEPP 624 over the N32-c interface. In one embodiment, the initiating SEPP 614 inserts, embeds, or includes an N32 purpose indicator 902 in the N32 handshake procedure request 901. An N32 purpose indicator 902 is a value (e.g., Boolean value, string, etc.) indicating that a requested, intended, or allowed usage purpose of the N32 connection is limited or dedicated to disaster roaming.

In FIG. 8B, responding SEPP 624 (i.e., through network interface controller 702 and/or SEPP controller 704) receives the N32 handshake procedure request 901 from initiating SEPP 614 (step 852). On successful processing of the N32 handshake procedure request 901, responding SEPP 624 responds by sending an N32 handshake procedure response toward initiating SEPP 614 with an indication (e.g., N32 purpose indicator) that an allowed usage purpose of the N32 connection is for the disaster roaming service (step 854). As shown in FIG. 9, responding SEPP 624 sends an N32 handshake procedure response 903 to initiating SEPP 614 in response to the N32 handshake procedure request 901. In one embodiment, responding SEPP 624 inserts, embeds, or includes an N32 purpose indicator 902 in the N32 handshake procedure response 903. The N32 purpose indicator 902 indicates that an allowed usage purpose of the N32 connection is limited or dedicated to disaster roaming.

In FIG. 8A, initiating SEPP 614 receives the N32 handshake procedure response 903 from responding SEPP 624 with an indication that an allowed usage purpose of the N32 connection is for the disaster roaming service (step 806). After successful N32 handshake procedures, an N32 connection 910 is established between SEPP 614 and SEPP 624 that is dedicated to disaster roaming, as shown in FIG. 9.

The N32 handshake procedures are performed using the N32-c interface, and the N32 connection 910 established after successful N32 handshake procedures may be referred to as an N32-f connection. Initiating SEPP 614 may then forward N32 traffic (e.g., JOSE protected messages) over the N32 connection 910. In FIG. 8A, initiating SEPP 614 sends an N32 traffic request over the N32 connection 910 toward responding SEPP 624 with a disaster roaming indicator (step 808). A disaster roaming indicator is a value (e.g., Boolean value, string, etc.) indicating that an NF service and/or interconnection (e.g., N32 connection 910) between mobile networks is for disaster roaming or a disaster roaming service. As shown in FIG. 9, initiating SEPP 614 sends an N32 traffic request 912 toward responding SEPP 624 over the N32 connection 910, and includes a disaster roaming indicator 914 in the N32 traffic request 912. In FIG. 8B, responding SEPP 624 receives the N32 traffic request 912 from the initiating SEPP 614 (step 856), and responds to initiating SEPP 614 by sending an N32 traffic response over the N32 connection 910 with a disaster roaming indicator (step 858). As shown in FIG. 9, responding SEPP 624 sends an N32 traffic response 916 toward initiating SEPP 614 over the N32 connection 910, and includes the disaster roaming indicator 914 in the N32 traffic response 916. In FIG. 8A, initiating SEPP 614 receives the N32 traffic response 916 from the responding SEPP 624 (step 810).

As discussed above, the N32 handshake procedures include a security capability negotiation procedure, a parameter exchange procedure, an N32-f context termination procedure, and an N32-f error reporting procedure. In one embodiment, initiating SEPP 614 may use the security capability negotiation procedure to provide the N32 purpose indicator 902 to responding SEPP 624. FIG. 10 is a signaling diagram of a security capability negotiation procedure in an illustrative embodiment. The N32 handshake procedures (N32-c) are performed over an HTTP/2 connection. Thus, the N32 handshake procedure request 901 may comprise a Hypertext Transfer Protocol (HTTP) POST request 1001. Initiating SEPP 614 initiates a security capability negotiation procedure towards responding SEPP 624 to agree on a security mechanism to use for protecting NF service- related signaling over the N32-f interface/connection. Initiating SEPP 614 issues an HTTP POST request 1001 towards responding SEPP 624 with the request body containing security negotiate request data 1002 (e.g., the “SecNegotiateReqData” Information Element (IE)). The security negotiate request data 1002 carries the supported security capabilities (i.e., PRINS and/or TLS), whether the 3gpp-Sbi-Target-apiRoot HTTP header is supported (if TLS security is supported), and the sender PLMN ID(s). In this embodiment, the security negotiate request data 1002 of the HTTP POST request 1001 may also include an N32 purpose indicator 902.

For example, the data model supported by the N32 handshake Application Programming Interface (API) includes multiple data types (see, for example, section 6.1.5 of 3GPP TS 29.573 (vl7.5.0)). One of the data types is the “SecNegotiateReqData” data type (see, for example, section 6.1.5.2.2 of 3GPP TS 29.573) that defines the security capabilities of a SEPP sent to a responding SEPP. The “SecNegotiateReqData” data type includes an intended usage purpose attribute (i.e., “intendedUsagePurpose”) that notifies a list of requested usage purpose of an N32 connection. The intended usage purpose attribute is an array of “IntendedN32Purpose” data types (see, for example, section 6.1.5.2.16 of 3GPP TS 29.573). The “IntendedN32Purpose” data type in turn refers to an N32 purpose enumeration (see, for example, the “N32Purpose” in section 6.1.5.3.9 of 3GPP TS 29.573). The data model of the N32 handshake API may be extended herein so that the N32 purpose enumeration includes one or more new enumeration values that comprise or represent an N32 purpose indicator 902.

FIG. 11 illustrates an enhanced N32 purpose enumeration 1100 in an illustrative embodiment. In this embodiment, the N32 purpose enumeration 1100 may further include a disaster roaming enumeration value 1102 (i.e., “DISASTER_ROAMING”) that indicates a requested, intended, or allowed usage purpose of the N32 connection is limited or dedicated to disaster roaming. The N32 purpose enumeration 1100 may further include a disaster roaming test enumeration value 1103 (i.e., “DISASTER_ROAMING_TEST”) that indicates a requested, intended, or allowed usage purpose of the N32 connection is limited or dedicated to disaster roaming, and allowed only for tests. FIG. 11 illustrates a non- exhaustive list of possible enumeration values, and others may be defined or standardized.

Upon successful processing of the HTTP POST request 1001 in FIG. 10, the responding SEPP 624 responds to the initiating SEPP 614 with a HTTP POST response 1003 with a “200 OK” status code and a POST response body that contains security negotiate response data 1004 (e.g., the “SecNegotiateRspData” IE). The security negotiate response data 1004 carries the selected security capability (i.e., PRINS or TLS), whether the 3gpp-Sbi-Target-apiRoot HTTP header is supported, and the sender PLMN ID(s). In this embodiment, the security negotiate response data 1004 of the HTTP POST response 1003 may also include an N32 purpose indicator 902. On failure, the responding SEPP 624 responds to the initiating SEPP 614 with an appropriate 4xx/5xx status code 1005.

FIG. 12 is a signaling diagram of a message forwarding procedure in an illustrative embodiment. Message forwarding over the N32-f interface involves the following steps at initiating SEPP 614: identification of the protection policy applicable for the API being invoked (i.e., either a request/response NF service API, a subscribe/unsubscribe service API, or a notification API), message reformatting as per the identified protection policy, and forwarding of the reformatted message over the N32 interface. Initiating SEPP 614 issues a HTTP POST request 1201 towards the responding SEPP 624 with the request body containing the “N32ReformattedReqMsg” IE 1202 carrying the reformatted HTTP/2 message. The request message 1201 contains the “n32fContextId” information provided by the responding SEPP 624 to the initiating SEPP 614 earlier during the parameter exchange procedure. In this embodiment, the HTTP POST request 1201 may also include the disaster roaming indicator 914, such as in the “N32ReformattedReqMsg” IE 1202.

Responding SEPP 624 uses the “n32fContextId” information to locate the agreed cipher suite and protection policy, and locate the n32ContextId to be used in the response. Upon successful processing of the HTTP POST request 1201, the responding SEPP 624 decompresses the N32-f HTTP request payload, if it is compressed, reconstructs the HTTP/2 message towards the NF service producer, compresses the reconstructed HTTP request if the reconstructed HTTP payload contains a Content-Encoding header indicating gzip compression, forwards the reconstructed HTTP/2 message to the NF service producer, and waits for the response from the NF service producer. When the response from the NF service producer is received, responding SEPP 624 responds to the initiating SEPP 614 with a HTTP POST response 1203 with a “200 OK” status code and a POST response body that contains the “N32ReformattedRspMsg” IE 1204. The “N32ReformattedRspMsg” IE contains the reformatted HTTP response message from the responding PLMN. The response message contains the “n32fContextId” information provided by the initiating SEPP 614 to the responding SEPP 624 earlier during the parameter exchange procedure. In one embodiment, the HTTP POST response 1203 may also include the disaster roaming indicator 914, such as in the “N32ReformattedRspMsg” IE 1204. On failure, the responding SEPP 624 responds to the initiating SEPP 614 with an appropriate 4xx/5xx status code 1205.

In one embodiment, initiating SEPP 614 may indicate or negotiate an expiry timer for the N32 connection 910 during the N32 handshake procedures. FIGS. 13A-13B are flow charts illustrating other methods 1300/1350 of supporting disaster roaming in SEPPs in an illustrative embodiment. FIG. 13A illustrates a method 1300 performed in an initiating SEPP, and FIG. 13B illustrates a method 1350 performed in a responding SEPP. Methods 1300/1350 are supplemental to methods 800/850 in FIGS. 8A-8B. As in FIG. 8A, initiating SEPP 614 sends an N32 handshake procedure request 901 toward a responding SEPP 624 with an indication that an intended usage purpose of the N32 connection 910 is for the disaster roaming service (see step 804 of FIG. 8A). In one embodiment, initiating SEPP 614 also sends the N32 handshake procedure request 901 with an expiry time value for the N32 connection 910 (step 1304). FIG. 14 is a signaling diagram of an N32 handshake procedure in another illustrative embodiment. For the N32 handshake procedure, initiating SEPP 614 transmits an N32 handshake procedure request 901 toward responding SEPP 624 with the N32 purpose indicator 902. In one embodiment, initiating SEPP 614 also inserts, embeds, or includes an expiry time value 1403 for the N32 connection 910 in the N32 handshake procedure request 901. An expiry time value 1403 is a value indicating a valid period of time for the N32 connection 910 during which the connection is valid for sending traffic for disaster roaming (e.g., 30 minutes, 1 hour, etc.). To avoid misuse, the N32 connection 910 will be open for a limited time. Therefore, initiating SEPP 614 may add the expiry time value 1403 to the N32 handshake procedure request 901.

In FIG. 13B, responding SEPP 624 receives the N32 handshake procedure request 901 from initiating SEPP 614 (step 1352). On successful processing of the N32 handshake procedure request 901, responding SEPP 624 responds to initiating SEPP 614 by sending an N32 handshake procedure response to initiating SEPP 614 with an indication that an allowed usage purpose of the N32 connection is for the disaster roaming service, and with an expiry time value (i.e., the same or another value) for the N32 connection 910 (step 1354). As shown in FIG. 14, responding SEPP 624 sends an N32 handshake procedure response 903 to initiating SEPP 614 in response to the N32 handshake procedure request 901. In one embodiment, responding SEPP 624 inserts, embeds, or includes an expiry time value 1403 in the N32 handshake procedure response 903.

In FIG. 13A, initiating SEPP 614 receives the N32 handshake procedure response 903 from responding SEPP 624 with the indication that an allowed usage purpose of the N32 connection is for the disaster roaming service, and also with an expiry time value 1403 for the N32 connection 910 (step 1306). Responding SEPP 624 may indicate the same or another expiry time value 1403 in the N32 handshake procedure response 903. If the expiry time values 1403 don’t match, the SEPPs may renegotiate a time period. SEPPs may also extend the expiry time of the N32 connection 910 by updating the N32 connection 910 with a new proposed expiry time value 1403.

There may be a variety of trigger conditions that cause initiating SEPP 614 to initiate N32 handshake procedures with a responding SEPP. For example, NF 612 (see FIG. 6) may initiate an NF service message to the initiating SEPP 614 for a “requestresponse” NF service, or a “subscribe-notify” NF service. NF 612 may be acting as an NF service consumer or an NF service producer.

FIG. 15 is a flow chart illustrating a method 1500 of initiating N32 handshake procedures in an initiating SEPP in an illustrative embodiment. The steps of method 1500 in FIG. 15 will be described with reference to a SEPP 614 as in FIG. 7, but those skilled in the art will appreciate that method 1500 may be performed in other systems or network entities.

For method 1500, initiating SEPP 614 receives the NF service message from an NF 612 regarding an NF service (step 1502). Initiating SEPP 614 processes the NF service message to identify a disaster roaming indicator 914 included in the NF service message (step 1504). Initiating SEPP 614 then initiates the N32 handshake procedures with the responding SEPP 624 in response to the disaster roaming indicator in the NF service message (step 1506), as described above.

FIGS. 16-17 are signaling diagrams of initiating an N32 handshake procedure in an illustrative embodiment. In FIG. 16, NF 612 transmits an NF service message 1601 toward initiating SEPP 614. NF 612 inserts, embeds, or includes a disaster roaming indicator 914 in the NF service message 1601 sent to initiating SEPP 614. Thus, initiating SEPP 614 is able to process the disaster roaming indicator 914 in the NF service message 1601, and determine that the N32 connection 910 being established will be dedicated to disaster roaming.

In FIG. 17, the NF service message 1601 may comprise an HTTP request 1701 (e.g., POST, GET, etc.). In one embodiment, NF 612 may include the disaster roaming indicator 914 in the “3gpp-Sbi-Interplmn-Purpose” header 1702 (see 3GPP TS 29.500 (vl7.7.0)) of the HTTP request 1701. The “3gpp-Sbi-Interplmn- Purpose” header 1702 is an HTTP custom header used in an HTTP request 1701 to indicate the intended purpose for inter- PEMN signaling, and may be included in an HTTP request when the target NF is in a different PLMN. Initiating SEPP 614 may therefore process the “3gpp-Sbi-Interplmn- Purpose” header 1702 to identify the disaster roaming indicator 914.

In one embodiment, SEPPs may be configured via Operations, Administration, and Maintenance (0AM) when disaster roaming should apply between two PLMNs. FIGS. 18A-18B are flow charts illustrating methods 1800/1850 of controlling disaster roaming in an illustrative embodiment. Method 1800 in FIG. 18A may be performed in an initiating SEPP 614. The initiating SEPP 614 receives configuration information from an 0AM entity or the like indicating whether disaster roaming is authorized with another mobile network (step 1802), such as PLMN 606. In response to receiving a service request message from an NF 612 (for an NF service offered by the other mobile network) that includes a disaster roaming indicator, initiating SEPP 614 determines whether the disaster roaming service is authorized (step 1804). If authorized, initiating SEPP 614 initiates N32 handshake procedures with a responding SEPP in the other mobile network (e.g., SEPP 624 of PLMN 606) to establish an N32 connection as described above (step 1806). If not, initiating SEPP 614 rejects the service request from the NF 612 (step 1808).

Method 1850 in FIG. 18B may be performed in a responding SEPP 624. The responding SEPP 624 receives configuration information from an 0AM entity or the like indicating whether disaster roaming is authorized with another mobile network (step 1852), such as PLMN 604. In response to receiving an N32 handshake procedure request from an initiating SEPP 614 with an indication that an intended usage purpose of the N32 connection is for the disaster roaming service (see step 804 of FIG. 8), responding SEPP 624 determines whether the disaster roaming service is authorized (step 1854). If authorized, responding SEPP 624 continues N32 handshake procedures with the initiating SEPP 614 to establish an N32 connection as described above (step 1856). If not, responding SEPP 624 rejects the N32 handshake procedure request from initiating SEPP 614 (step 1858) with a new cause code that disaster roaming is not activated. The initiating SEPP 614 will not retry.

If an N32 connection is established in either case, a SEPP 614/624 disaster roaming may be disabled by the 0AM entity. Thus, a SEPP 614/624 receives configuration information from the 0AM entity that the disaster roaming service is disabled for an N32 connection. In response, SEPP 614/624 tears down the N32 connection with a new cause “Disaster Roaming deactivated”. Thus, the peer SEPP will not retry establishing the N32 connection.

One potential issue may arise when multiple SEPPs are available in a PLMN that supports a disaster roaming service, as not all of the SEPPs need to be configured to support the disaster roaming service. FIG. 19 illustrates inter-PLMN communications for a disaster roaming scenario in another illustrative embodiment. In this embodiment, VPLMN 604 is shown to include NF 612, NRF 226-1, and a plurality of SEPPs 614 (i.e., SEPP 614-1, SEPP 614-2, and SEPP 614-3). PLMN 606 is shown to include NF 622, NRF 226-2, and a plurality of SEPPs 624 (i.e., SEPP 624-1, SEPP 624-2, and SEPP 624-3). In one embodiment, the disaster roaming service is enhanced by having a SEPP register in its local NRF 226 whether or not it supports the disaster roaming service.

FIG. 20 is a flow chart illustrating a method 2000 of registering a SEPP toward an NRF in an illustrative embodiment. The steps of method 2000 in FIG. 20 will be described with reference to a SEPP 614 as in FIG. 7, but those skilled in the art will appreciate that method 2000 may be performed in other systems or network entities.

For method 2000, SEPP 614 generates, creates, or formats an NF management request (e.g., HTTP PUT request) to register or update an NF profile of SEPP 614 toward NRF 226-1 (step 2002). The NF profile of SEPP 614 comprises general parameters of SEPP 614, and also the parameters of the different services exposed by SEPP 614. For example, SEPP 614 may invoke the Nnrf_NFManagement service as described in 3GPP TS 29.510 (vl7.6.0). The Nnrf_NFManagement service provides an NF register (“NFRegister”) service operation. The NF register service operation allows a SEPP 614 to register its NF profile in NRF 226-1, and includes the registration of the general parameters of SEPP 614 together with a list of services exposed by SEPP 614. The Nnrf_NFManagement service also provides an NF update (“NFUpdate”) service operation. The NF update service operation allows a SEPP 614 to replace, or update partially, the parameters of its NF profile (including the parameters of the associated services) in NRF 226-1, and to add or delete individual services offered by SEPP 614.

In this embodiment, SEPP 614 inserts, embeds, or includes a disaster roaming support indicator as a parameter in the NF profile of SEPP 614. A disaster roaming support indicator is a value (e.g., Boolean value, string, etc.) that indicates whether a SEPP supports a disaster roaming service. The disaster roaming support indicator may comprise an attribute or Information Element (IE) of an NF profile (e.g., attribute name “disasterRoaming” or the like), may comprise an attribute or IE of an NF service, or may otherwise be included in the NF profile. SEPP 614 then sends the NF management request toward NRF 226-1 (step 2004).

Each SEPP 614 of VPLMN 604 may register or update NF profiles in NRF 226-1 in a similar manner. Thus, other network entities may be able to query NRF 226-1 to determine the capabilities of the SEPPs 614. Other SEPPs (e.g., SEPPs 624) may register or update NF profiles in a local NRF in a similar manner.

FIG. 21 is a block diagram of an NRF 226 in an illustrative embodiment. NRF 226 is an apparatus, network element, network function (NF), or network entity of a 5G core network 104 that supports the following functionality: maintains an NF profile of available NF instances and their supported services, allows other NF instances to subscribe to, and get notified about, the registration of new NF instances of a given type, and supports a service discovery function. For example, NRF 226 may offer an Nnrf_NFManagement service, and an Nnrf_NFDiscovery service. The Nnrf_NFManagement service allows a Network Function Instance in the serving PLMN to register, update, or deregister its profile in NRF 226. The Nnrf_NFDiscovery service allows a Network Function Instance to discover services offered by other Network Function Instances, by querying the local NRF 226.

In one embodiment, NRF 226 includes the following subsystems: a network interface component 2102, an NF management controller 2104, and an NF discovery controller 2106 that operate on one or more platforms. Network interface component 2102 may comprise circuitry, logic, hardware, means, etc., configured to exchange control plane messages or signaling with other network elements or NFs. Network interface component 2102 may operate using a variety of protocols or reference points. NF management controller 2104 may comprise circuitry, logic, hardware, means, etc., configured to support an NF management service (e.g., Nnrf_NFManagement service) that allows NFs to register, update, or deregister NF profiles 2110 (e.g., NF profile 2110-1, NF profile 2110-2, NF profile 2110-3, etc.). NF discovery controller 2106 may comprise circuitry, logic, hardware, means, etc., configured to support an NF discovery service (e.g., Nnrf_NFDiscovery service) that allows NFs to discover services offered by other NFs, such as based on the services indicated in the NF profiles 2110.

One or more of the subsystems of NRF 226 may be implemented on a hardware platform comprised of analog and/or digital circuitry. For example, NF management controller 2104 and/or NF discovery controller 2106 may be implemented on one or more processors 2130 that execute instructions 2134 for software that are loaded into memory 2132. One or more of the subsystems of NRF 226 may be implemented on a cloudcomputing platform or another type of processing platform.

NRF 226 may include various other components not specifically illustrated in FIG. 21.

FIG. 22 is a flow chart illustrating a method 2200 of registering an NF profile of a SEPP in an illustrative embodiment. The steps of method 2200 in FIG. 22 will be described with reference to a NRF 226 as in FIG. 21, but those skilled in the art will appreciate that method 2200 may be performed in other systems or network entities.

For method 2200, NF management controller 2104 of NRF 226 receives an NF management request from a SEPP 614 (step 2202), such as through network interface component 2102 (see also, FIG. 20). NF management controller 2104 registers or updates an NF profile 2110 for SEPP 614 based on the NF management request (step 2204). In this embodiment, the NF profile 2110 of SEPP 614 as registered in NRF 226 includes a disaster roaming support indicator 2112 (see FIG. 21) that indicates whether SEPP 614 supports a disaster roaming service.

One or more network entities may then query NRF 226 to discover capabilities of SEPPs in a PEMN, such as for SEPPs that support disaster roaming. For example, an NF that originates traffic towards another PLMN for the disaster roaming service (e.g., an NF service consumer or NF service producer) may use the information stored in NRF 226 to select a SEPP 614 that supports the disaster roaming service (e.g., has registered a disaster roaming support indicator 2112 in its NF profile 2110).

FIG. 23 is a block diagram of a network element 2300 in an illustrative embodiment. Network element 2300 comprises a server, device, apparatus, equipment (including hardware), system, etc., that implements one or more network functions (NF) (e.g., NF 612 or another NF). In this embodiment, network element 2300 includes the following subsystems: a network interface component 2302, and a disaster roaming controller 2304 that operate on one or more platforms. Network interface component 2302 may comprise circuitry, logic, hardware, means, etc., configured to exchange control plane messages or signaling with other network elements and/or UEs. Network interface component 2302 may operate using a variety of protocols or reference points. Disaster roaming controller 2304 may comprise circuitry, logic, hardware, means, etc., configured to support a disaster roaming service.

One or more of the subsystems of network element 2300 may be implemented on a hardware platform comprised of analog and/or digital circuitry. One or more of the subsystems of network element 2300 may be implemented on one or more processors 2330 that execute instructions 2334 for software that are loaded into memory 2332. One or more of the subsystems of network element 2300 may be implemented on a cloud-computing platform or another type of processing platform.

Network element 2300 may include various other components not specifically illustrated in FIG. 23.

FIG. 24 is a flow chart illustrating a method 2400 of discovering a SEPP that supports a disaster roaming service in an illustrative embodiment. The steps of method 2400 in FIG. 24 will be described with reference to an NF 612 as in FIG. 23, but those skilled in the art will appreciate that method 2400 may be performed in other systems or network entities. For method 2400, disaster roaming controller 2304 of NF 612 generates, creates, or formats an NF discovery message to discover services offered by SEPPs 614 as registered in NRF 226 (step 2402). For example, disaster roaming controller 2304 may invoke the Nnrf_NFDiscovery service of NRF 226. The Nnrf_NFDiscovery service provides an NF discover (“NFDiscover”) service operation that allows an NF 612 to discover services offered by other Network Function Instances (e.g., SEPPs 614), by querying the local NRF 226. The NF discover service operation discovers a set of NF Instances (and their associated NF Service Instances), represented by their NF profile 2110, that are currently registered in NRF 226 and satisfy a number of input query parameters. The NF discover service operation provides, to the NF 612, the IP address(es) or Fully-Qualified Domain Name (FQDN) of the NF Instance(s) or NF Service(s) matching certain input criteria.

In this embodiment, disaster roaming controller 2304 includes an NF type (e.g., target-nf-type) for a “SEPP” in the NF discovery message as a query parameter. Disaster roaming controller 2304 also includes “disaster roaming” (e.g., a disaster roaming service name or indicator) in the NF discovery message as a query parameter. It is assumed that NF 612 (acting as an NF service consumer or NF service producer) is or will be involved in an NF service associated with a UE 106 invoking the disaster roaming service. Thus, disaster roaming controller 2304 attempts to discover one or more SEPPs that support disaster roaming by including disaster roaming as a query parameter. Disaster roaming controller 2304 of NF 612 then sends the NF discovery request toward NRF 226 (step 2404), such as through network interface component 2302.

FIG. 25 is a flow chart illustrating another method 2500 of discovering a SEPP that supports a disaster roaming service in an illustrative embodiment. The steps of method 2500 in FIG. 25 will be described with reference to an NRF 226 as in FIG. 21, but those skilled in the art will appreciate that method 2500 may be performed in other systems or network entities.

For method 2500, NF discovery controller 2106 of NRF 226 receives the NF discovery request from NF 612 (step 2502), such as through network interface component 2102. In response to the NF discovery request, NF discovery controller 2106 discovers or identifies one or more SEPPs 614 having a corresponding NF profile 2110 that satisfies one or more of the query parameters (step 2504). In other words, NF discovery controller 2106 searches for NF profiles 2110 of SEPPs 614 that contain a disaster roaming support indicator 2112 indicating the SEPP 614 supports the disaster roaming service. NF discovery controller 2106 then sends an NF discovery response to NF 612 that includes search results (step 2506). The search results indicate one or more SEPPs 614 having a corresponding NF profile 2110 that satisfies the query parameters. In other words, the search results indicate one or more SEPPs 614 having a corresponding NF profile 2110 indicating, via the disaster roaming support indicator 2112, that the SEPP(s) 614 supports disaster roaming.

In FIG. 24, disaster roaming controller 2304 of NF 612 receives the NF discovery response from NRF 226 indicating one or more SEPPs that support disaster roaming (step 2406), such as through network interface component 2302. Disaster roaming controller 2304 then selects a SEPP 614 that supports disaster roaming based on the search results from NRF 226 (step 2408). Other NFs 612 may discover SEPPs 614 by querying NRF 226 in a similar manner.

FIG. 26 is a flow chart illustrating a method 2600 of initiating an NF service in an illustrative embodiment. The steps of method 2600 in FIG. 26 will be described with reference to an NF 612 as in FIG. 23, but those skilled in the art will appreciate that method 2600 may be performed in other systems or network entities.

For method 2600, disaster roaming controller 2304 of NF 612 generates, creates, or formats an NF service message requesting an NF service offered by an NF 622 in another mobile network (step 2602), such as PLMN 606. Disaster roaming controller 2304 sends the NF service message to initiating SEPP 614 with a disaster roaming indicator 914 (step 2604). If authorized, initiating SEPP initiates the N32 handshake procedures with the responding SEPP 624 in response to the disaster roaming indicator in the NF service message as described above.

In one embodiment, the NF service message may comprise an HTTP request. NF 612 may include the disaster roaming indicator in the “3gpp-Sbi-Interplmn-Purpose” header of the HTTP request, as described above in FIG. 17. As discussed above, disaster roaming may apply between PLMNs with or without roaming agreements. To allow for disaster roaming between PLMNs without a roaming agreement or interconnect agreement, a FQDN format may be standardized by the 3GPP for a SEPP. The standardized format for an FQDN allows a SEPP to reach a peer SEPP from a given target PLMN that supports disaster roaming even without a roaming agreement. An example standardized format may be:

“sepp-disaster-roaming.5gc.nid<NID>.mnc<MNC>.mcc<MCC>.3gppnetwork.org” FIG. 27 is a flow chart illustrating a method 2700 of reaching a peer SEPP in an illustrative embodiment. For method 2700, SEPP 614 selects another SEPP 624 that supports the disaster roaming service in another mobile network without a roaming agreement (step 2702). Because there is no roaming agreement between the mobile networks, SEPP 614 is not configured with an address for SEPP 624. Thus, SEPP 614 constructs an FQDN for SEPP 624 based on the standardized format (step 2704). SEPP 614 then queries a Domain Name Service (DNS) with the FQDN in standardized format to acquire an address of the SEPP 624 (step 2706).

FIG. 28 is a signaling diagram illustrating SEPP support of disaster roaming in an illustrative embodiment. It is again assumed that a UE 106 is roaming in a visited network (e.g., VPLMN 604) that supports a disaster roaming service (see also, FIG. 19). It is also assumed that VPLMN 604 includes a plurality of SEPPs 614. Each of the SEPPs 614 is configured to register with its local NRF 226-1 whether or not it supports the disaster roaming service. For example, SEPP 614-1 transmits an NF management request to register (or update) an NF profile 2110 toward NRF 226-1. SEPP 614-1 supports disaster roaming in this example, so SEPP 614-1 includes a disaster roaming support indicator as a parameter in the NF profile 2110 indicating that SEPP 614-1 supports disaster roaming (e.g., disaster roaming support indicator = TRUE). Likewise, SEPP 614-2 transmits an NF management request to register (or update) an NF profile 2110 toward NRF 226-1. SEPP 614-1 does not support disaster roaming in this example, so SEPP 614-2 includes a disaster roaming support indicator as a parameter in the NF profile 2110 indicating that SEPP 614-1 does not support disaster roaming (e.g., disaster roaming support indicator = FALSE), or does not include the disaster roaming support indicator in the NF profile 2110. NRF 226-1 registers or updates an NF profile 2110 for SEPP 614-1 and SEPP 614-2 accordingly.

Assume further that NF 612 (acting as an NF service consumer) invokes a NF discover service (e.g., Nnrf_NFDiscovery) to discover a SEPP that supports disaster roaming. NF 612 sends an NF discovery request toward NRF 226-1 that includes disaster roaming (e.g., a disaster roaming service name or indicator) as a query parameter. In response to the NF discovery request, NRF 226-1 discovers or identifies one or more SEPPs 614 having a corresponding NF profile 2110 that satisfies the query parameters. In this example, SEPP 614-1 supports disaster roaming while SEPP 614-2 does not. Thus, NRF 226-1 transmits an NF discovery response to NF 612 indicating SEPP 614-1 satisfies the query parameters. With SEPP 614-1 identified, NF 612 sends an NF service request to SEPP 614-1 for an NF service offered by an NF 622 in PEMN 606. NF 612 includes a disaster roaming indicator in the NF service request sent to SEPP 614-1. SEPP 614-1 processes the NF service request to identify the disaster roaming indicator included in the NF service request. SEPP 614-1 (as an initiating SEPP) selects a responding SEPP 624 in another mobile network (e.g., PLMN 606) with or without a roaming agreement. SEPP 614-1 then initiates N32 handshake procedures with the responding SEPP 624 in PLMN 606 in response to the disaster roaming indicator in the NF service request. More particularly, initiating SEPP 614-1 transmits an N32 handshake procedure request toward responding SEPP 624 with an indication that an intended usage purpose of the N32 connection is for the disaster roaming service. Initiating SEPP 614-1 does so without checking if PLMN 606 is allowed for any existing purpose or not (like roaming, interconnect). Initiating SEPP 614-1 may also include an expiry time value in the N32 handshake procedure request. Initiating SEPP 614- 1 receives an N32 handshake procedure response from responding SEPP 624 with an N32 purpose indicator that an allowed usage purpose of the N32 connection is for the disaster roaming service. After successful N32 handshake procedures, an N32 connection is established between SEPP 614-1 and SEPP 624 that is dedicated to disaster roaming.

Any of the various elements or modules shown in the figures or described herein may be implemented as hardware, software, firmware, or some combination of these. For example, an element may be implemented as dedicated hardware. Dedicated hardware elements may be referred to as “processors”, “controllers”, or some similar terminology. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term “processor” or “controller” should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, a network processor, application specific integrated circuit (ASIC) or other circuitry, field programmable gate array (FPGA), read only memory (ROM) for storing software, random access memory (RAM), non-volatile storage, logic, or some other physical hardware component or module.

Also, an element may be implemented as instructions executable by a processor or a computer to perform the functions of the element. Some examples of instructions are software, program code, and firmware. The instructions are operational when executed by the processor to direct the processor to perform the functions of the element. The instructions may be stored on storage devices that are readable by the processor. Some examples of the storage devices are digital or solid-state memories, magnetic storage media such as a magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media.

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

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

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

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

(ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions); and

(c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

Although specific embodiments were described herein, the scope of the disclosure is not limited to those specific embodiments. The scope of the disclosure is defined by the following claims and any equivalents thereof.

Claims

What is claimed is:

1. A Security Edge Protection Proxy (SEPP) of a visited mobile network, the SEPP comprising: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the SEPP at least to: initiate N32 handshake procedures with a responding SEPP in another mobile network to establish an N32 connection with the responding SEPP regarding a disaster roaming service; and send an N32 handshake procedure request toward the responding SEPP with an indication that an intended usage purpose of the N32 connection is dedicated to the disaster roaming service.

2. The SEPP of claim 1, wherein: the N32 handshake procedure request comprises a Hypertext Transfer Protocol (HTTP) POST request of a security capability negotiation procedure; and security negotiate request data of the HTTP POST request includes the indication of the intended usage purpose of the N32 connection.

3. The SEPP of claim 2, wherein: the indication in the N32 handshake procedure request comprises a disaster roaming enumeration value of an N32 purpose enumeration that indicates usage of the N32 connection is dedicated to disaster roaming, or indicates usage of the N32 connection is dedicated to a disaster roaming test.

4. The SEPP of claim 1, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the SEPP at least to: send the N32 handshake procedure request toward the responding SEPP with an expiry time value for the N32 connection.

5. The SEPP of claim 1, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the SEPP at least to: receive an NF service message from a Network Function (NF); process the NF service message to identify a disaster roaming indicator included in the NF service message; and initiate the N32 handshake procedures with the responding SEPP in response to the disaster roaming indicator in the NF service message.

6. The SEPP of claim 5, wherein: the NF service message comprises a Hypertext Transfer Protocol (HTTP) request; and the at least one memory and the computer program code are further configured to, with the at least one processor, cause the SEPP at least to: process a “3gpp-Sbi-Interplmn-Purpose” header of the HTTP request to identify the disaster roaming indicator.

7. The SEPP of claim 5, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the SEPP at least to: receive an N32 handshake procedure response from the responding SEPP with an indication that an allowed usage purpose of the N32 connection is dedicated to the disaster roaming service; and send an N32 traffic request toward the responding SEPP over the N32 connection with the disaster roaming indicator.

8. The SEPP of claim 1, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the SEPP at least to: format an NF management request to register an NF profile toward an NF Repository Function (NRF) with the NF profile including a disaster roaming support indicator indicating that the SEPP supports the disaster roaming service; and send the NF management request toward the NRF.

9. The SEPP of claim 1, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the SEPP at least to: select the responding SEPP in the other mobile network without a roaming agreement.

10. The SEPP of claim 9, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the SEPP at least to: construct a Fully-Qualified Domain Name (FQDN) for the responding SEPP based on a standardized format for SEPPs; and query a Domain Name Service (DNS) with the FQDN in the standardized format to acquire an address of the responding SEPP even though no roaming agreement exists with the other mobile network.

11. A method of supporting disaster roaming, the method comprising: initiating, at an initiating Security Edge Protection Proxy (SEPP) of a visited mobile network, N32 handshake procedures with a responding SEPP in another mobile network to establish an N32 connection with the responding SEPP regarding a disaster roaming service; and sending an N32 handshake procedure request from the initiating SEPP toward the responding SEPP with an indication that an intended usage purpose of the N32 connection is dedicated to the disaster roaming service.

12. The method of claim 11, wherein sending the N32 handshake procedure request comprises: sending the N32 handshake procedure request from the initiating SEPP toward the responding SEPP with the indication and an expiry time value for the N32 connection.

13. The method of claim 11, further comprising: receiving, at the responding SEPP, the N32 handshake procedure request from the initiating SEPP; and sending an N32 handshake procedure response from the responding SEPP to the initiating SEPP with an indication that an allowed usage purpose of the N32 connection is dedicated to the disaster roaming service.

14. The method of claim 11, further comprising: sending an N32 traffic request from the initiating SEPP toward the responding SEPP over the N32 connection with a disaster roaming indicator.

15. The method of claim 14, further comprising: sending an N32 traffic response from the responding SEPP toward the initiating SEPP over the N32 connection with the disaster roaming indicator.

16. The method of claim 11, further comprising: selecting, at the initiating SEPP, the responding SEPP in the other mobile network without a roaming agreement.

17. The method of claim 16, further comprising: constructing, at the initiating SEPP, a Fully-Qualified Domain Name (FQDN) for the responding SEPP based on a standardized format for SEPPs; and querying, at the initiating SEPP, a Domain Name Service (DNS) with the FQDN in the standardized format to acquire an address of the responding SEPP even though no roaming agreement exists with the other mobile network.

18. The method of claim 11, further comprising: formatting, at the initiating SEPP, an NF management request to register an NF profile of the initiating SEPP toward an NF Repository Function (NRF) with the NF profile including a disaster roaming support indicator indicating that the initiating SEPP supports the disaster roaming service; and sending the NF management request from the initiating SEPP toward the NRF.

19. The method of claim 18, further comprising: receiving, at the NRF, the NF management request from the initiating SEPP; and registering the NF profile for the initiating SEPP that includes the disaster roaming support indicator.

20. The method of claim 19, further comprising: formatting, at a Network Function (NF), an NF discovery message to discover services offered by SEPPs as registered in the NRF, wherein the NF discovery message indicates disaster roaming as a query parameter; sending the NF discovery request from the NF toward the NRF; receiving, at the NF, an NF discovery response from the NRF including search results indicating one or more SEPPs that support disaster roaming; and selecting the initiating SEPP that supports disaster roaming based on the search results.

21. A non-transitory computer readable medium embodying programmed instructions executed by a processor of a Security Edge Protection Proxy (SEPP) of a visited mobile network, wherein the instructions direct the processor to implement a method of supporting disaster roaming, the method comprising: initiating, at the SEPP, N32 handshake procedures with a responding SEPP in another mobile network to establish an N32 connection with the responding SEPP regarding a disaster roaming service; and sending an N32 handshake procedure request toward the responding SEPP with an indication that an intended usage purpose of the N32 connection is dedicated to the disaster roaming service.

22. A Security Edge Protection Proxy (SEPP) of a mobile network, the SEPP comprising: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the SEPP at least to: receive an N32 handshake procedure request from an initiating SEPP in another visited mobile network to establish an N32 connection with the initiating SEPP regarding a disaster roaming service, wherein the N32 handshake procedure request includes an indication that an intended usage purpose of the N32 connection is dedicated to the disaster roaming service; and send an N32 handshake procedure response toward the initiating SEPP with an indication that an allowed usage purpose of the N32 connection is dedicated to the disaster roaming service.

23. The SEPP of claim 22, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the SEPP at least to: receive an N32 traffic request from the initiating SEPP over the N32 connection with a disaster roaming indicator; and send an N32 traffic response toward the initiating SEPP over the N32 connection with the disaster roaming indicator.

24. The SEPP of claim 22, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the SEPP at least to: receive the N32 handshake procedure request from the initiating SEPP with an expiry time value for the N32 connection; and send an N32 handshake procedure response to the initiating SEPP with an expiry time value for the N32 connection.

25. The SEPP of claim 22, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the SEPP at least to: formatting an NF management request to register an NF profile toward an NF Repository Function (NRF) with the NF profile including a disaster roaming support indicator indicating that the SEPP supports the disaster roaming service; and send the NF management request toward the NRF.

26. A NF Repository Function (NRF), comprising: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the NRF at least to: receive an NF management request from a Security Edge Protection Proxy (SEPP) to register an NF profile; and register the NF profile for the SEPP with a disaster roaming support indicator that indicates whether the SEPP supports a disaster roaming service.

27. The NRF of claim 26, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the NRF at least to: receive an NF discovery request from a Network Function (NF) that includes disaster roaming as a query parameter; identify one or more SEPPs having a corresponding NF profile that contains the disaster roaming support indicator; and send an NF discovery response to the NF that indicates one or more SEPPs that support the disaster roaming service.

28. A Network Function (NF), comprising: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the NF at least to: format an NF discovery message to discover services offered by Security Edge Protection Proxies (SEPPs) as registered in an NF Repository Function (NRF), wherein the NF discovery message includes disaster roaming as a query parameter; send the NF discovery request toward the NRF; receive an NF discovery response from the NRF indicating one or more

SEPPs that support disaster roaming; and select a SEPP that supports disaster roaming as an initiating SEPP based on search results from the NRF.

29. The NF of claim 28, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the NF at least to: format an NF service message requesting an NF service offered by another NF in another mobile network; and send the NF service message to the initiating SEPP with a disaster roaming indicator.

30. The NF of claim 29, wherein: the NF service message comprises a Hypertext Transfer Protocol (HTTP) request; and the at least one memory and the computer program code are further configured to, with the at least one processor, cause the NF at least to: insert the disaster roaming indicator in a “3gpp-Sbi-Interplmn-Purpose” header of the HTTP request.