This use case relates only to SNPNs that provide services in a similar way as provided by WLAN hotspots. Today's PLMNs have a centralized database of IP addresses of all operator nodes that connect to the inter-PLMN IP backbone network, including AAA Servers/Proxies. This information is used for firewall and Border Gateway configuration. Signalling connections between VPLMN and HPLMN are long-lived (Diameter and HTTP-based N32f) and support bidirectional (inbound and outbound) signalling. In contrast, there is no administrative entity that manages the interconnect of SNPNs on one hand and SNPN Credential Providers on the other hand. In addition, the number of interconnected SNPNs and SNPN Credential Providers is expected to be considerably greater than the number of PLMNs today. Given the large number of SNPN Credential Providers with which a SNPN needs to interconnect, it is not feasible to maintain permanently established signalling connections between them. Instead, the signalling connection needs to be established dynamically. Ideally, a signalling connection between SNPN A and SNPN Credential Provider B should be established only when a subscriber of SNPN Credential Provider B attempts to connect to SNPN A, and should be released when the last subscriber of SNPN Credential Provider B disconnects from SNPN A. The dynamic establishment of a signalling connection between the SNPN and the SNPN Credential Provider raises several new issues, as follows:

• Outbound signalling issue: The SNPN might not know the IP address of the SNPN Credential Provider's signalling endpoints and vice versa. In some cases, the SNPN Credential Provider may be operated using a cloud provider using dynamic IP address assignment.
• Inbound signalling issue: The SNPN and/or the SNPN Credential Provider may reside behind a firewall or a Network Address Translation (NAT) device.
• End-to-end signalling issue: The SNPN and/or the SNPN Credential Provider need to have assurance that they are indeed establishing a signalling connection with each other, and that the signalling connection is secure.

The issues related to dynamic establishment of a signalling connection between the SNPN and the SNPN Credential Provider are illustrated in Figure 5.1.1-1.

1. NetAbove is an Internet service provider that operates SNPNs and serves as a SNPN Credential Provider. As part of the subscription contract, NetAbove allows its subscribers to connect to SNPNs owned by a variety of companies (e.g., hospitality and convention centres, airports, government institutions, schools, restaurants, coffee shops, etc.).
2. NetAbove serves as a SNPN Credential Provider that can authenticate and authorize its subscriber when the subscriber attempts to connect to a SNPN.
3. NetAbove does not have a direct agreement with any of these SNPNs and instead relies on a third party that assists the interconnect of entities affiliated with this third party for the purpose of subscriber authentication and authorization.
4. Kaffa Koffee has launched a chain of coffee shops across the country. Each coffee shop is equipped with a small SNPN allowing customers to access Kaffa Koffee's private entertainment system, in addition to providing Internet access.
5. Kaffa Koffee's customers get free access to the entertainment system on the condition that they can assert an identity that can be authenticated by a supported SNPN Credential Provider.
6. A wide variety of companies can take the role of SNPN Credential Providers (e.g., mobile operators, other SNPNs). Kaffa Koffee does not have a direct agreement with any of these SNPN Credential Providers and instead relies on a third party that assists the interconnect of entities affiliated with this third party for the purpose of subscriber authentication and authorization.
7. BananaFed is a third party that assists the interconnect of entities affiliated with this third party for the purpose of subscriber authentication and authorization.
8. NetAbove and Kaffa Koffee both are affiliated with BananaFed.

1. Roy is a subscriber of NetAbove.
2. Roy is visiting a Kaffa Koffee shop and wants to access Kaffa Koffee's famous entertainment system using his 5G-capable laptop.
3. Using the connection manager on his laptop, Roy selects his NetAbove subscription credentials for connection to Kaffa Koffee's SNPN.
4. Kaffa Koffee's SNPN has no direct signalling connection with NetAbove. In order to authenticate the request coming from Roy's laptop, Kaffa Koffee's SNPN turns to BananaFed, a third party, for assistance. Both NetAbove and Kaffa Koffee are affiliated with BananaFed.
5. NetAbove's SNPN Credential Provider server resides in NetAbove's administrative IP domain and is located behind a firewall.
6. With BananaFed's assistance, the Kaffa Koffee's SNPN is able to forward the outbound authentication request to a SNPN Credential Provider server that is owned by NetAbove, even though Kaffa Koffee's SNPN has no prior knowledge of the IP address of any NetAbove's SNPN Credential Provider servers.
7. With BananaFed's assistance, the NetAbove's SNPN Credential Provider server is able to receive the inbound authentication request originated by Kaffa Koffee's SNPN even though it is located behind a firewall.
8. With BananaFed's assistance, the Kaffa Koffee's SNPN and NetAbove's SNPN Credential Provider server get assurance that they are establishing a secure connection with the intended remote party.
9. Kaffa Koffee's SNPN succeeds in authenticating Roy with the SNPN Credential Provider server at NetAbove.
10. NetAbove's SNPN Credential Provider server desires to be informed when Roy disconnects from Kaffa Koffee's SNPN. With BananaFed's assistance, NetAbove's SNPN Credential Provider server is able to forward the outbound subscription request to the SNPN operated by Kaffa Koffee, even though Kaffa Koffee's SNPN is located behind a NAT device.

1. Once Roy's laptop is connected to the Kaffa Koffee's SNPN network, Roy can enjoy access to Kaffa Koffee's entertainment system and access to the Internet.
2. After some time, Roy disconnects gracefully from Kaffa Koffee's SNPN and the disconnection event is signalled to NetAbove's SNPN Credential Provider server.

None. The existing interface for interconnect between SNPN and SNPN Credential Provider (aka Credentials Holder) relies on permanent signalling connection between the SNPN and the SNPN Credential Provider.

[PR 5.1.6-001] [PR 5.1.6-002] [PR 5.1.6-003] [PR 5.1.6-004] [PR 5.1.6-005]