Automate IR.21 and IR.85 implementation now to meet the challenges of 5G SA and SEPP roaming

Managing IR.21 and IR.85 changes will become even more complicated as 5G roaming starts to take off – because customers will demand support for complex.

QoS-assured and SLA-backed services, requiring yet more changes to network configurations.

In this second of our series on automating the validation and implementation of changes to IR.21 and IR.85 (standards, we take a dive into the unique challenges that roaming between 5G SA (Standalone) networks bring to this task, including how operators can automate support for the Security Edge Protection Proxy (SEPP).

Automation of 5G roaming and security to support the implementation of IR.21 and IR.85 changes is the only viable option for operators. Not only is the “IR problem” is well known from previous network generations as a complicated, repetitive and resource-heavy, often manual, task prone to human error, but 5G roaming will bring a host of new challenges that will stretch your roaming teams.

Validating and implementing IR.21 and IR.85 changes is a time-consuming and resource-heavy task

Changes to IR.21 and IR.85 standards often take weeks to validate and implement throughout the network and share across the roaming partner (and hub) ecosystem. It also detracts from the focus on revenue-building and strategic operations due to the resources required.

Inconsistencies or mistakes can quickly have repercussions throughout the network, impacting customers and roaming partners (and their customers too). With the deployment of 5G SA networks, the complexity and sheer scale of supporting IR.21 and IR.85 changes have complicated the task.

The problem isn’t just limited to delivering experiences for classical mobile roamers. With 5G SA, new kinds of services with QoS-assured performance are enabled. And that means that B2B customers and service users will expect SLAs to be maintained, even while roaming. There’s no room for error in these scenarios.

Which is why, in this emerging environment, there is no option except to automate – manual implementation is simply unfeasible. Wherever you are with your full 5G roaming plans, you need to take stock and think about the implications of supporting a richer — more profitable — range of services that could be subject to complex changes and updates.

The service-based 5G SA network is dynamically orchestrated, cloud-native, and virtualised, which adds significantly more complexity and volume over previous mobile technologies. It requires rapid, automated updates and introduces network slicing and private networking, updates to the 5G Core, and new security protocols such as security edge protection proxy (SEPP).

The unique challenges of 5G SA roaming

It also brings protocol interworking challenges – interconnecting 5G HTTP/2 protocols with older Diameter (4G) or SS7 (3G) networks requires complex mapping and constant updates to roaming databases, which creates interoperability hurdles.

In addition, 5G will support billions of devices, including massive IoT estates and advanced use cases such as smart cities and connected vehicles). It means that manual management is not an option and would create a high risk of service degradation and signalling faults.

The GSMA is supporting the rollout of 5G SA roaming services and has defined several development models.  GSMA envisages that operators might combine these (outlined below) depending on business, security and operational requirements.

• Direct Bilateral– A basic 3GPP direct bilateral deployment model between a VPMN (visited public mobile network) and a HPMN (home public mobile network), in which the VPMN and HPMN each have their own SEPP deployed within their networks.
• SEPP Delegation– Delegates the 5G SA SEPP deployment to third-party service providers with three models defined:
  • Model 2.1 – Outsourced deployment model
  • Model 2.2 – Hosted deployment model
  • Model 2.3 Operator Group model
• Service Hub– Delegates 5G SA signalling management and connects the VPMN and HPMN via roaming intermediate signalling actors (service hub providers), based on a bilateral roaming agreement between the two networks.
• Roaming Hub – Intermediaries connect the VPMN and HPMN, based on a roaming hub contract.

The ‘thorny’ issue of managing SEPP interconnections

Another significant challenge for operators and service providers is the issue of swiftly integrating the SEPP node into the 5G SA network. The SEPP is crucial in ensuring the security of 5G roaming interconnections and is responsible for securing inter-PLMN (Public Land Mobile Network) signalling.

It’s essential for maintaining confidentiality and data integrity during 5G interconnection roaming message exchange. A major part of the problem is that not all suppliers are willing to share their SEPP nodes with other suppliers.

The SEPP uses the N32 interface to connect to other operators’ SEPPs and is split into N32-c (Control), which negotiates the initial handshake and capability negotiation, and N32-f (Forwarding) for sending secure messages.

To add a further layer of complexity, GSMA and 3GPP define two primary security approaches for the N32 interface between SEPPs:

• Transport Layer Security (TLS), which is used for “hop-by-hop” security
• Protocol for N32 Interconnect Security (PRINS, formerly N32-f), which is used for end-to-end security

TLS is mainly considered for SEPP connections between two networks, while PRINS is normally used by roaming hub partners. Many use a hybrid approach to cover both bases.

Automation of 5G SA and SEPP roaming is not an option, it’s imperative

All of this means that the automation of 5G SA and SEPP roaming is imperative. The We Are CORTEX Evolver Roaming automation platform can significantly lighten the burden, reducing validation and implementation of IR.21 and IR.85 changes from a matter of weeks to a matter of minutes.

To find out how CORTEX Roaming can automate 5G SA roaming end-to-end contact us today – or download our latest paper to learn more.