Making private 5G interconnect easy to configure, simple to operate, and widely adopted

This is the follow up blog to an earlier post titled “scaling the adoption of private cellular networks” where the challenges of how to scale interconnect between private 3GPP networks are described. Compared to the current inter-network signaling that serves around 800 public cellular operators, there are forecasts of a 1000 fold increase in the number of private cellular networks. Critically, each private network may experience perhaps a thousandth of the signaling load of a conventional public carrier network.

The full potential of 5G will only be harnessed if the scalable deployment of private 5G solutions can be simplified. The 5G DRIVE (Diversified oRAN Integration & Vendor Evaluation) project led by Virgin Media O2 and part-funded by the UK Government’s Department for Culture Media and Sport (DCMS), Cisco and co-partners is targeted at defining the use of the new 5G Security Edge Protection Proxy (SEPP) roaming interface to connect public and private 5G networks. How best to integrate private 3GPP Non-Public Networks with established public cellular networks, affordably, securely and at scale is a problem that Cisco is invested in solving.

In this post we share details of a recent demonstration Cisco gave to UK DCMS and other 5G DRIVE partners. The demonstration highlights an approach that may facilitate the simplification of 5G roaming interconnect with private wireless networks.

The first cellular networks were interconnected using the same SS7 based signaling used on the public switched telephone network. The 2G cellular standard defines enhancements to SS7 messages. These enhancements support concepts of mobility as well as the newly introduced short message service. The introduction of 4G/LTE saw the introduction of IP based Diameter signaling between carrier networks. However, the structure of the SS7-defined exchanges was preserved to facilitate the interworking with earlier systems. Importantly, these Diameter-based systems are responsible for transporting the inter-carrier roaming signaling and not the roaming data used by the end-users. This roaming data can either be tunneled back to the home network or routed locally by the visited access network.

Now, 5G sees the most significant change in how to carry signaling between networks since the inception of cellular. 5G defines a “service based architecture” (SBA) that avoids strict signaling hierarchies. Instead, SBA allows signaling consumers to communicate with different signaling producers. SBA defines the use of RESTful APIs transported using HTTP2 defined methods like GET, POST and PATCH. These APIs are more familiar to web developers compared to the telco-focused SS7 and Diameter.

As described in the earlier post, the GSM Association is responsible for the services and solutions that underpin public roaming systems. This enables subscribers to experience seamless roaming across the world. As expected, GSMA is currently enhancing these services and solutions to be able to interconnect 5G Systems and enable users to seamlessly roam onto 5G public cellular systems using SBA-defined interfaces.

Just like in earlier Gs, the roaming signaling defined in 5G architecture is bidirectional. HTTP2 Request messages originate from both the visited network and the home network. These are then responded to by the other party, as illustrated below. The signaling transits the IPX network which is a private IP backbone used between public cellular operators. The IPX is isolated from the public Internet with security rules defined to prevent unauthorized access to/from it.

The figure above illustrates that each operator is responsible for their own perimeter security including configuration of firewalls and border gateways. GSMA defines procedures for exchanging IP address information for all operator nodes that connect to the IPX in its permanent reference document (PRD) IR.21. Operators configure firewall rules using this information to ensure that only signaling connections originating from registered IP addresses are permitted. The figure below illustrates how this firewall configuration is essential for the visited access network to permit inbound signaling flows from the home network.

The 5G System introduces the Security Edge Protection Proxy (SEPP). The SEPP sits at the perimeter of the 5G public cellular network and is the focus of the 5G DRIVE project.

The N32 interface is defined by 3GPP for use between two SEPPs to ensure the HTTP2 messages can be securely exchanged. First, N32 control signaling is exchanged to establish N32 forwarding. The N32 forwarding operates by taking the HTTP2 Request or Response messages that need to be exchanged between operators and encoding the HTTP2 header frames and data frames in JSON. This JSON is transported in another set of HTTP2 messages which are exchanged between the two SEPPS. 3GPP defines two options for securing signaling between SEPPs. Either TLS protects the communication of these HTTP2 messages using the transport layer, or JSON Web Encryption (JWE) protects the communication at the application layer.

Unlike GSMA, which defines the operation of roaming signaling and the IP backbone between public cellular operators, there is no equivalent system between private 5G networks. This is one of the reasons why 3GPP has defined two separate approaches to deploying private networks, a standalone approach that simply interconnects credential holders with access networks and a public network integrated approach that integrates the private network with the systems of a public cellular operator.

Interestingly, credential holders and private Wi-Fi access networks are increasingly using OpenRoaming (www.openroaming.org) to interconnect. OpenRoaming is a federation of identity providers and access providers targeted at lowering the barriers to adoption of roaming between Wi-Fi credential holders and Wi-Fi hotspot providers. Cisco was responsible for incubating the OpenRoaming system before transferring the operation of the federation to the Wireless Broadband Alliance (www.wballiance.com).

Prior to OpenRoaming, using Wi-Fi while on the go was a hassle. Most of the time, the Wi-Fi operator requires users to accept specific end-user terms and conditions using an intrusive browser pop-up. There were some deployments that delivered a more seamless experience using SIM-based authentication by interconnecting with mobile operators, but the access network configuration was complicated and agreements time consuming. The private enterprise’s InfoSec policies typically prohibit inbound sockets from unknown hosts on the Internet. This means each inbound roaming relationship requires a specific firewall configuration to permit signaling to transition across the enterprise’s perimeter. Without such configuration, the inbound signaling originated by the credential holder will be dropped by the firewall, as illustrated below.

Instead of sharing IP addresses, the OpenRoaming federation makes extensive use of DNS to enable the visited access providers to dynamically discover signaling systems operated by different credential holders. WBA’s Public Key Infrastructure (PKI) issues certificates to OpenRoaming providers. The roaming signaling endpoints authenticate and authorize each other using these certificates. The visited access network establishes a single TLS-secured outbound socket towards the credential holder. All signaling between the providers uses this single socket.

OpenRoaming’s use of DNS and a single secure outbound socket means that the enterprise can configure a single firewall rule for all OpenRoaming signaling originating from their own systems. This significantly simplifies and streamlines the procedures required to enable roaming onto the enterprise’s wireless network.

As part of our 5G DRIVE participation, Cisco revisited how “server-initiated signaling” is supported on today’s Internet. The aim was to understand whether future roaming systems can be enhanced with similar capabilities.

The challenge of how to support server push based signaling is well understood. The Internet has seen the deployment of a number of different solutions. 5G signaling is based on HTTP2 and this includes a capability termed Server Sent Events (SSE). SSE is used to send web server initiated events to the client over an already established socket. SSE is designed to reduce the number of client requests and deliver faster web page load times. However, SSE is unsuitable for supporting the reverse direction 5G roaming signaling as this necessitates full bidirectional signaling.

Prior to HTTP2 SSE, other solutions for server initiated signaling focused on polling-based solutions. With short polling, the client continuously sends HTTP requests to enable any server-initiated signaling to be returned to the client. As a consequence, short polling solutions place a significant load on the server which limits their scalability. To reduce this impact, alternative long-polling solutions have been developed. Using long polling, the client opens an HTTP request which then remains open until a server initiated message needs to be returned. As soon as the client receives the server initiated message in the HTTP response, it immediately opens another HTTP request. As with HTTP2 SSE, polling solutions are useful for sending individual events back to the client but are poorly suited when the server sent information is expected to be responded to by the client.

Some perceive the use of polling solutions by web applications as an abuse of the HTTP protocol. Consequently, the WebSockets protocol was specified to enable full two-way communications between clients and servers. The WebSocket connection starts off as an HTTP connection. The client includes an HTTP Upgrade header in the request to change the protocol from HTTP to WebSocket. The HTTP request header also includes a subprotocol field. This is used to indicate the upper layer application intended to be exchanged using the WebSocket.

As described above, the existing HTTP2-based SEPP solution takes the HTTP2 Request and Response messages that need to be exchanged between operators and encodes the HTTP2 header frames and data frames in JSON. This approach is adapted to enable a WebSocket-based SEPP to transport the same JSON encoded information. Because WebSocket transport is designed to support bi-directional communications, a single WebSocket is used to transport signaling generated from the visited network and that generated from the home network.

The 3GPP-defined N32 interface between SEPPs is split into a setup phase using control signaling and a forwarding phase. However, the current HTTP2-based system assumes fully decoupled signaling between those exchanges when the SEPP-initiator is in the visited access network and those when the SEPP-initiator is in the home network. This means that bidirectional forwarding requires separate N32 control exchanges. The HTTP2-SEPP uses a HTTP2 POST to a specific “/exchange-capability” path as part of the N32 control exchange.

In contrast, WebSockets enable bi-directional communications over a single socket. This means the visited access network is able to trigger the establishment of bidirectional forwarding. The WebSocket-SEPP signals a specific sub-protocol indicating that N32 service is being requested. In the demonstration, “n32proxy.openroaming.org” was used as an example sub-protocol. Following setup of the WebSocket, the WebSocket SEPP in the visited network sends a JSON object over the WebSocket requesting to establish the N32 forwarding service. The information exchanged in this setup message closely matches that defined in 3GPP N32c messages, including identities, public land mobile network (PLMN) information and security parameters.

After forwarding is established, the conventional HTTP2 SEPP maps the headers and data fields from received HTTP requests and responses into JSON objects that are then transported using HTTP2. The WebSocket SEPP maps the headers and data fields from received HTTP requests and responses into JSON objects that are transported using the WebSocket message syntax.

The WebSocket solution enables private networks to configure simplified firewall rules. All outbound and inbound signaling exchanges between the private 5G access network and the remote credential holder are transported on a single socket. The credential holder’s WebSocket SEPP rewrites the authority of any callBackUris it receives from the visited access network using a SEPP fully qualified domain name (FQDN) suffix. For example, a 5G Access Management Function (AMF) located in a visited network may signal a deregistration callback URI to the home network of:

http://24.208.229.196:7777/namf-callback/v1/imsi-234600000055531/dereg-notify

The WebSocket SEPP located in the home network rewrites the URI to a value that will always resolve to the IP address of the SEPP in the home network, e.g.,

http://24.208.229.196.sepp.operator.com:7777/namf-callback/v1/imsi-234600000055531/dereg-notify

This means that any HTTP requests originating in the credential holder’s network will use the rewritten URI in their HTTP2 Request messages. This ensures that all messages will be routed via the SEPP and the bidirectional N32 forwarding service towards the visited access network.

Cisco has built a proof of concept based on the WebSocket approach described above and demonstrated the system to UK DCMS and other 5G DRIVE partners. We adopted a similar approach to how OpenRoaming enables scale by using a cloud federation as the authority to connect access network providers with identity providers. Private 5G systems can then benefit from the same simplification and streamlining of procedures that have accelerated interconnection between private Wi-Fi networks and different credential holders.

A fictitious cellular carrier is assumed to have joined a roaming federation, has been issued a certificate by the federation to use in securing signaling with other federation members and has configured their DNS records to enable their signaling systems to be discoverable from the public Internet. In the demonstration, the signaling systems of this fictitious cellular network are hosted by a cloud provider. A SIM card was provisioned in the 5G User Data Repository (UDR) of the fictitious cellular carrier, identified with a corresponding Mobile Country Code of 234 and a Mobile Network Code of 60. The demonstration focuses on the use case of a subscriber from the fictitious cellular carrier roaming onto the private 5G network operated by “Acme-Industrial” who has similarly joined the roaming federation. Acme-Industrial has configured its local private 5G network to support N32 signaling over WebSockets and operates a firewall that only permits outbound sockets to the Internet.

A UE with the SIM card attempts to register on the local private 5G network. There are a number of ways that the registration can be triggered. In one approach, the federation specifies the use of a Group Identity for Network Selection (GIN) that is broadcast from the private network. As part of the registration, the UE provides its identity to the network. The private 5G network performs a dynamic discovery to identify the home network using the 5G UE identifier.

The private 5G network contacts the UE’s home network through an API-Gateway, establishing a websocket connection.  Then, to keep things efficient and simple, we automated the implementation of logic for the WebSocket-based N32 forwarding using the cloud provider’s function-as-a-service. Finally, the 5G Core Services for the Authentication Server Function (AUSF), Unified Data Management (UDM) and User Data Repository (UDR) are hosted on cloud service’s compute platform.

The proof of concept demonstrates signaling associated with a typical roaming scenario. The different phases are described together with signaling logs from the demo.

• A private 5G access network is setup and awaits inbound roamers.
• The firewall rules in the private 5G network permit outbound signaling originating from the WebSocket-based SEPP function.
• An inbound roaming UE attempts to register with the private network.
• The private network recovers the home PLMN from the UE identifier and uses DNS to discover the WebSocket signaling peer.

2022.09.06 18:32:48: [INFO] Waiting for SUPI or SUCI from in-bound roaming UE 
2022.09.06 18:33:41: [INFO] In-bound SUPIorSUCI detected: suci-0-234-60-0000-0-0-0000055531

• The WebSocket SEPP establishes a bi-directional N32forwarding service for the home PLMN.

2022.09.06 18:33:41: >>>> {"n32Service": "subscribeRequest", "accessProvider": "ACME-INDUSTRIAL.CISCO:US", "plmnIdList": ["23460"], "3GppSbiTargetRootApiRootSupported": "False", "jwsCipherSuiteList": ["ES256", "none"]} 
2022.09.06 18:33:41: <<<< {"n32Service": "subscribeAccept", "identityProvider": "MNC60MCC234.3GPPBROKER.GB", "3GppSbiTargetRootApiRootSupported": "False", "plmnIdList": ["23460"], "jwsCipherSuite": "none"} 
2022.09.06 18:33:41: [INFO] WebSocket forwarding established and serving suci-0-234-60-0000-0-0-0000055531

• The UE registers onto the private network using standard 5G service-based architecture and signalling. The WebSocket transports bi-directional signalling exchanges between the private access network and the home network.

2022.09.06 18:33:43: >>>> {"n32Service": "http2Message", "messageId": "2785087321A", "n32MessageSigned": {"payload": {"reformattedReq": {"requestLine": {":method": "POST", ":path": "/nausf-auth/v1/ue-authentications", ":scheme": "http", ":authority": "172.31.14.141:7777"}, "headers": {"accept": "application/3gppHal+json:application/problem+json", "content-type": "application/json"}, "payload": {"supiOrSuci": "suci-0-234-60-0000-0-0-0000055531", "servingNetworkName": "5G:mnc060.mcc234.3gppnetwork.org"}}}, "protected": "eyJhbGciOiJub25lIiwiYjY0IjpmYWxzZSzigJxjcml0IjpbImI2NCJdfQ==", "signature": ""}} 
2022.09.06 18:33:43: <<<< {"n32Service": "http2Message", "messageId": "2785087321A", "n32MessageSigned": {"payload": {"reformattedRsp": {"statusLine": {":status": "201"}, "headers": {"server": "Open5GS v2.4.9", "date": "Tue, 06 Sep 2022 17:33:43 GMT", "content-length": "318", "location": "http://172.31.14.141:7777/nausf-auth/v1/ue-authentications/1", "content-type": "application/3gppHal+json"}, "payload": "{nt"authType":t"5G_AKA",nt"5gAuthData":t{ntt"rand":t"50d05393a459af7786bb96b38f4ebf12",ntt"hxresStar":t"4d332c90989aa127a9c86a96a8978379",ntt"autn":t"7ee4c1f4ee8f8000c459a0a203065874"nt},nt"_links":t{ntt"5g-aka":t{nttt"href":t"http://172.31.14.141:7777/nausf-auth/v1/ue-authentications/1/5g-aka-confirmation"ntt}nt}n}"}}, "protected": "eyJhbGciOiJub25lIiwiYjY0IjpmYWxzZSzigJxjcml0IjpbImI2NCJdfQ==", "signature": ""}}

• The UE uses the resources of the private 5G network.
• The home network triggers a de-registration of the UE. This will typically be due to the UE registering on another network, which could be when it returns to coverage of its home network or registers on another federated private 5G network. As we didn’t have a second access network in the demonstration, we triggered a deregistration by withdrawing the subscription of the UE in the UDR. The WebSocket SEPP in the home network translates the network initiated HTTP2 Request to de-register the UE into JSON. The JSON is transported to the private network using the already established WebSocket.

2022.09.06 18:37:53: <<<< {"n32Service": "http2Message", "messageId": "4043366907D", "n32MessageSigned": {"payload": {"reformattedReq": {"requestLine": {":method": "POST", ":path": "/namf-callback/v1/imsi-234600000055531/dereg-notify", ":scheme": "http"}, "headers": {"content-type": "application/json","accept": "application/json,application/problem+json", "host": "192.168.128.145:7777"}, "payload": {"deregReason": "SUBSCRIPTION_WITHDRAWN", "accessType": "3GPP_ACCESS"}}}, "protected": "eyJhbGciOiJub25lIiwiYjY0IjpmYWxzZSzigJxjcml0IjpbImI2NCJdfQ==", "signature": ""}}

• The WebSocket SEPP in the private 5G network recovers the JSON and re-creates the HTTP2 Request to de-registers the UE. The HTTP2 message is forwarded on to the private 5G Network’s Access and Mobility Management Function (AMF) which processes the message and deregisters the UE. The AMF then signals back to the UDR that the UE has been successfully deregistered.

2022.09.06 18:37:53: >>>> {"n32Service": "http2Message", "messageId": "4043366907D", "n32MessageSigned": {"payload": {"reformattedRsp": {"statusLine": {":status": "204"}, "headers": {"server": "Open5GS v2.4.9", "date": "Tue, 06 Sep 2022 17:37:53 GMT"}, "payload": ""}}, "protected": "eyJhbGciOiJub25lIiwiYjY0IjpmYWxzZSzigJxjcml0IjpbImI2NCJdfQ==", "signature": ""}} 
2022.09.06 18:37:53: [INFO] suci-0-234-60-0000-0-0-0000055531 successfully deregistered

• The home PLMN no longer serves any UEs in the visited network. The private network automatically triggers the deactivation of the WebSocket-based N32forwarding service towards the home PLMN.

2022.09.06 18:37:53: [INFO] terminating WebSocket forwarding for mnc60.mcc234 
2022.09.06 18:37:53: >>>> {"n32Service": "terminateRequest", "accessProvider": "ACME-INDUSTRIAL.CISCO:US"} 
2022.09.06 18:37:53: <<<< {"n32Service": "terminateAccept", "identityProvider": "MNC60MCC234.3GPPBROKER.GB"}

Cisco is investing in taking the complexity out of private 5G with its 5G-as-a-service offer. With WBA already reporting that over 1 million private wireless hotspots have embraced OpenRoaming, it is clear that simplifying roaming systems can lead to the transformation of roaming, from serving 100s of public cellular operators towards supporting millions of private 5G networks. Importantly, the WBA Board has committed to expanding the use of OpenRoaming to address alternative wireless technologies used in private networks. As part of this expansion, WBA has exchanged liaison statements with 3GPP regarding facilitating the adoption of roaming onto 3GPP Non Public Networks.

Re-using the newly introduced SEPP functionality to enable new deployments of roaming between public and private networks is a focus of the 5G Drive project. The proof of concept demonstrated by Cisco points to how established public cellular roaming interfaces can be adapted to facilitate adoption between private 5G networks and credential holders.

Cisco looks forward to working with others in WBA and 3GPP to help specify new capabilities that ensure that roaming between private and public cellular networks becomes as easy to configure, as simple to operate, and as widely adopted as traditional Wi-Fi-based OpenRoaming.

Want to find out more?

Click here to learn more about how OpenRoaming is already lowering barriers to adoption for roaming onto private Wi-Fi networks.

Click here to learn more about Cisco’s private 5G-as-a-service offering.

Click here to learn more about the 5G DRIVE project

Share: