5G
Introduction
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.
Evolution of inter-carrier signaling
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.
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.
Securing 5G roaming signaling
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.
Private Network Challenges
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.
Scaling signaling on the internet
|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.
Adapting N32 transport for adoption by private networks
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.
Demonstration of 3GPP roaming interfaces transported over WebSocket
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.
Reducing complexity and increasing scale
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.
