Patent Description:
The <NUM>rd Generation Partnership Project (3GPP) is a collaboration between groups of telecommunications standards associations. The 3GPP defined mobile phone system specifications for telecommunications networks including <NUM>, <NUM>, and Long Term Evolution (LTE) networks. The next generation network for 3GPP is the <NUM> network. The <NUM> specifications target high data rates, reduced latency, energy saving, cost reduction, higher system capacity, and increasing numbers of connected devices.

The 3GPP has defined a service-based architecture for its next generation <NUM> core network. In a service-based architecture, services are provided to software components by application components, typically through a communication protocol over a data communications network. A service can be, e.g., a discrete function that can be accessed remotely and consumed and updated independently of other services in the system. Different services can be used together to provide the functionality of a larger functional system such as a software application. The service-based architecture can integrate distributed and separately-maintained software components.

In order to enable service consumers to communicate with service producers, consumers are expected to discover producers via a discovery service and then directly communicate with the producers. For example, in the <NUM> core network, services perform these functions using RESTful APIs over HTTP/<NUM>. While the approach defined by 3GPP works, it places a lot of the burden on the service consumers and producers to implement networking functionality such as service discovery, load balancing, overload control, circuit breaker, retries, timeouts, and the like.

Accordingly, there exists a need for methods, systems, and computer readable media for providing a service proxy function in a telecommunications network core using a service-based architecture.

<CIT> describes scalable proxy clusters for API computing and API ecosystems.

ERICSSON: "Pseudo-CR on Service Discovery and Registration using NRF service", vol. CT WG4, XP <NUM> describes service discovery and registration using NRF service.

"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on Enhancements to the Service-Based Architecture (Release <NUM>)", 3GPP STANDARD; TECHNICAL REPORT; 3GPP TR <NUM>, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; <NUM>, ROUTE DES LUCIOLES ; F-<NUM> SOPHIA-ANTIPOLIS CEDEX ; FRANCE, no. <NUM>, XP051451682 describes a study on enhancements to the service-based architecture.

<CIT> describes a mobile telecommunications network including a core network and a radio access network. The radio access network has a network node that wirelessly communicates with a mobile terminal registered with the radio access network. The radio access network includes a controller that controls the use of network resources by the mobile terminal and processes control plane signaling. The controller includes an applicator that receives policy information and/or routing information from the core network and provides instructions to the network node to act in accordance with the received information. The network node includes an enforcer that enforces the instructions received from the controller so as to control whether the terminal uplink user plane traffic and control plane signalling messages are passed to the core network, routed to the controller, or duplicated and provided to both the core network and the controller.

The invention relates to a system, as further defined in claim <NUM>, a method, as further defined in claim <NUM>, and a computer readable medium, as further defined in claim <NUM>, for providing a service proxy function in a a telecommunications network core.

The subject matter described herein may be implemented in hardware, software, firmware, or any combination thereof. As such, the terms "function" "node" or "engine" as used herein refer to hardware, which may also include software and/or firmware components, for implementing the feature being described. In one exemplary implementation, the subject matter described herein may be implemented using a non-transitory computer readable medium having stored thereon computer executable instructions that when executed by the processor of a computer control the computer to perform steps. Exemplary computer readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media, such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. In addition, a computer readable medium that implements the subject matter described herein may be located on a single device or computing platform or may be distributed across multiple devices or computing platforms.

Methods, systems, and computer readable media for providing a service proxy function in a telecommunications network core using a service-based architecture are disclosed. In particular, the disclosed subject matter presents a distributed service proxy function using at least one service proxy controller and a number of service proxy workers.

The 3GPP <NUM> specifications significantly change the way that components in the telecommunication network core communicate with each other. The core network in <NUM> follows a service-based architecture where network elements advertise and provide services which can be consumed using REST APIs by other network elements in the telecommunications network core. This allows for the adoption of web scale technologies and software in telecommunications networks.

In the <NUM> architecture, the focus is on loosely coupled services as opposed to tightly coupled functions and point-to-point interfaces. HTTP/<NUM> is used as a service-based application layer protocol. The <NUM> architecture supports native control and user plane separation. The <NUM> architecture supports the unified data management framework, an expanded and unified policy framework, and an expanded network exposure functionality.

Web scale technologies often rely primarily on open source software and bring in significant amount of automation, e.g., especially in the deployment and operational aspects of implementing a system. Web scale technology solutions are based on informational elements present in messages below the telecommunications network core layer. The service proxy function described in this specification brings telecommunications-awareness to networking components in a telecommunications network core and can help to resolve issues such as congestion control, traffic prioritization, overload control, optimized routing, and others.

<FIG> is a block diagram illustrating an example telecommunications network core <NUM> that uses a service-based architecture. Telecommunications network core <NUM> can be, e.g., a 3GPP <NUM> telecommunications network core. As shown in <FIG>, telecommunications network core <NUM> includes a service proxy function <NUM> and a number of network functions communicating with each other using service proxy function <NUM>.

The networks functions illustrated in <FIG> are examples of network functions in telecommunications network core <NUM>. Other types of appropriate network functions can be included, and in some examples, telecommunications network core <NUM> will include fewer network functions. As shown in <FIG>, telecommunications network core <NUM> includes a network slice selection function (NSSF) <NUM>, a network exposure function (NEF) <NUM>, a network function repository function (NRF) <NUM>, a policy control function (PCF) <NUM>, a unified data management (UDM) function <NUM>, an application function (AF) <NUM>, a security edge protection proxy (SEPP) <NUM>, an EIR <NUM>, an interworking function (IWF) <NUM>, an access and mobility management function (AMF) <NUM>, an authentication server function (AUSF), a bootstrapping server function (BSF) <NUM>, and a session management function (SMF) <NUM>.

Some of the network functions shown in <FIG> are used for <NUM>-<NUM> interworking. For example, NSSF <NUM>, NEF <NUM>, NRF <NUM>, SEPP <NUM>, EIR <NUM>, IWF <NUM>, and BSF <NUM> can be used to facilitate <NUM>-<NUM> interworking.

Service proxy function <NUM> can be deployed in a cloud computing environment along side of the network functions to provide various services to facilitate a service-based architecture, e.g., routing control, resiliency, and observability to telecommunications network core <NUM>. Service proxy function <NUM> provides, generally, a service mesh solution to telecommunications network core <NUM>, thereby alleviating various computation burdens from the network functions and reducing the risk of network errors resulting from compliance with the service-based architecture.

In general, service proxy function <NUM> is a dedicated common service for handling communication between network functions. Service proxy function <NUM> can be implemented as a software layer that is separate and shared by other services deployed in a cloud computing environment. Service proxy function <NUM> offloads inter-service communication concerns from network functions and makes inter-service communication safe, fast, and reliable.

In some examples, service proxy function <NUM> provides one or more of the following advantages to services in telecommunications network core <NUM>:.

In some examples, NRF <NUM> and service proxy function <NUM> are combined or configured to communicate with one another to facilitate certain tasks such as load balancing. NRF <NUM> can store real-time information on, for example:.

Storing such information at NRF <NUM> can lead to better network function selection decision making at NRF <NUM>. NRF <NUM> can also use such information to reduce initial service requests, e.g., by eliminating separate NRF queries. In some examples, combining NRF <NUM> and service proxy function <NUM> can enable dynamic re-routing of messages.

Service proxy function <NUM> can provide improved visibility of the overall health of telecommunications network core <NUM>. It is critical for operators to have visibility into the health of the network. Some functions partially fulfill this need, e.g., in a limited capacity by providing the health of a slice. Service proxy function <NUM> can alleviate the need for additional monitoring functions to identify the failed or degraded network functions.

Service proxy function <NUM> can provide improved load balancing across available network functions by virtue of having a complete view of all the messages arriving for a given type of network function. Service proxy function <NUM> can support technology such as round robin, weighted round robin, transaction latency, and other appropriate load balancing based on current load and network function availability.

By leveraging its position in the network, service proxy function <NUM> can provide better routing control and bring resiliency to telecommunications network core <NUM>. Service proxy function <NUM> relieves consumer network functions of remembering and interpreting complex routing rules associated with next hop selection and at the same time making re-routing decisions based on load conditions and health status of network functions.

In the absence of an alternate route, service proxy function <NUM> can quickly reject requests destined to a failed or degraded network function, thereby acting as a circuit breaker. This can prevent valuable resources at the consumer network functions from being tied up waiting for responses from providers. Service proxy function <NUM> can also attempt retries on behalf of the service consumer thereby relieving the service consumer of this burden and leaving it to focus on the application.

Service proxy function <NUM> can be useful to reduce connections to and from network functions. In the absence of service proxy function <NUM>, network function instances would typically setup connections with every other network function instance. By being deployed along side network function instances and acting as an outbound proxy for the network function instances, service proxy function <NUM> eliminates the need for network function instances to setup direct connections between each other. Connections can be optimized such that each network function instance maintains a set of redundant connections to service proxy function <NUM> and uses those connections for all out bound requests.

<FIG> is a block diagram illustrating an example implementation of the service proxy function <NUM>. Service proxy function <NUM> includes a service proxy controller <NUM> and a number of service proxy workers <NUM>, <NUM>, <NUM>, and <NUM>. Service proxy function <NUM> includes a control plane and a data plane as indicated in <FIG>. Service proxy workers <NUM>, <NUM>, <NUM>, and <NUM> using the control plane, and service proxy workers <NUM>, <NUM>, <NUM>, and <NUM> communicate with each other to route telecommunications network core messages using the data plane.

Service proxy controller <NUM> can be implemented as a number of different instances of a service proxy controller function. In some examples, the functions of service proxy controller <NUM> are divided across a multitude of controller microservices.

Each service proxy worker is coupled to one or more network functions. Service proxy worker <NUM> is coupled to a first AMF instance <NUM>, a second AMF instance <NUM>, and a SMF instance <NUM>. Service proxy worker <NUM> is coupled to an AUSF <NUM> instance and a PCF instance <NUM>. Service proxy worker <NUM> is coupled to a first SMF instance <NUM> and a second SMF instance <NUM>. Service proxy worker <NUM> is coupled to a UDM instance <NUM>.

In some examples, service proxy function <NUM> is implemented such that no service proxy worker is coupled to any particular network function, and instead all service proxy workers collectively share a network identity and are used collectively as a default proxy by all network functions in the domain of the service proxy function instance. Cloud load balancer functions may be used to distribute network function consumer loads across the set of service proxy workers.

In operation, service proxy workers <NUM>, <NUM>, <NUM>, and <NUM> facilitate communications between the network functions in accordance with the service-based architecture of telecommunications network core <NUM>. Service proxy controller <NUM> is configured, by virtue of appropriate programming, for providing routing policies for telecommunications network core <NUM> to service proxy workers <NUM>, <NUM>, <NUM>, and <NUM>.

Each of service proxy workers <NUM>, <NUM>, <NUM>, and <NUM> is configured, by virtue of appropriate programming, for routing telecommunications network core messages between network functions by consuming the routing policies from service proxy controller <NUM> and enforcing the routing policies from service proxy controller <NUM>. Each of service proxy workers <NUM>, <NUM>, <NUM>, and <NUM> is also configured for providing network status reports to service proxy controller <NUM> based on the telecommunications network core messages. Typically, a network function comprises a collection of services, and the network status is reported for each network function and each network function service. Service proxy controller <NUM> can use the network status reports to generate and push new routing policies.

The network status reports can include, e.g., notifications that network functions have failed or degraded, or other appropriate metrics, key performance indicators (KPIs), and reports related to message processing. For example, the network status reports can include request and response counts for each network function instance, or message rates or average transaction latency for each network function instance. The network status reports can include success and error counts. With this information service proxy controller <NUM> is in a unique position to provide a view of the network health and to provide routing policies based on current information.

Service proxy controller <NUM> and service proxy workers <NUM>, <NUM>, <NUM>, and <NUM> are implemented using at least one processor and, in general, are implemented using a distributing computing system, e.g., a cloud computing system or other appropriate computing system. Service proxy function <NUM> can be deployed, e.g., as a default outbound proxy to network functions instances or as a side car in cloud native environments. Service proxy function <NUM> can provide one or more of the following benefits to telecommunications network core <NUM>:.

In some examples, providing routing policies includes performing load balancing between at least a first subset of network functions based on the network status reports from service proxy workers <NUM>, <NUM>, <NUM>, and <NUM>. In some examples, routing telecommunications network core messages includes re-routing, at a service proxy worker, at least a first telecommunications network core message destined for a first network function based on a health status indicator for the first network function. In some examples, routing telecommunications network core messages includes re-trying, at a service proxy worker, a failed transmission of a first telecommunications network core message from a first network function to a second network function.

In some examples, service proxy workers <NUM>, <NUM>, <NUM>, and <NUM> are deployed alongside instances of the network functions in a distributed computing system, and routing telecommunications network core messages includes acting as a default outbound proxy for the instances of the network functions. Alternatively, the network functions can configure service proxy workers <NUM>, <NUM>, <NUM>, and <NUM> as an outbound proxy for inter-network function communications but not as the default proxy for all possible flows. In some examples, providing routing policies for telecommunications network core <NUM> includes providing a traffic prioritization policy, and enforcing the routing policies includes shedding lower priority network traffic in response to detecting an overload condition according to the traffic prioritization policy.

In some examples, providing network status reports includes providing one or more of: request and response counts for each network function; a message rate for each network function; and an average transmission latency for each network function. In some examples, service proxy controller <NUM> is configured for determining a network load for at least a first network function based on: capacity information published by the first network function during registration; load information published by the first network function; and a first network status report characterizing the network load of the first network function.

<FIG> is a signaling diagram illustrating an example message exchange <NUM> for load-aware discovery and request routing. <FIG> shows an AMF instance <NUM>, a service proxy worker <NUM>, the NRF <NUM>, the service proxy controller <NUM>, another service proxy worker <NUM>, and a PCF instance <NUM>.

Load balancing across the available network functions in a service-based <NUM> core is primarily a function of NRF <NUM> and the logic implemented at the consumer network function. NRF <NUM> factors in the relative capacity and load information provided by the network functions during the network function discovery process.

Based on the above information, NRF <NUM> can return (in response to a discovery request) multiple results in an ordered list based on the most preferred to the least preferred. However, the order loses value if the consumer network function cache this information for a significant amount of time as load information can change quickly by the second. There is also no standard around what kind of the load balancing strategy a consumer NF should use when it sees multiple results and this will result in vendors implementing their own strategies their by making is hard to achieve load balancing of the providers.

Service proxy controller <NUM> can provide valuable information to NRF <NUM> that may otherwise not be available to NRF <NUM>. For example, service proxy controller <NUM> can report additional metrics and a more up to date status information of the network functions. The metrics reported by service proxy function <NUM> combined with view of the data at NRF <NUM> reported by the network functions provides a current load, i.e., a "true load" on the network function, which can lead to better network function selection (for discovery requests) as well as avoid providing stale results in response to discovery requests.

The "true load" factors in the following information for a given network function instance:.

Message exchange <NUM> begins with service proxy controller <NUM> sending messages <NUM> to push routing policies to service proxy workers <NUM> and <NUM>. Service proxy controller <NUM> also exchanges messages <NUM> with NRF <NUM> to continuously update NRF <NUM> of current load information of network function instances.

AMF <NUM> sends a message <NUM> to service proxy worker <NUM> to discover an network service. For example, message <NUM> can specify NRF <NUM> as a destination and specify the type of network service as PCF. Service proxy worker <NUM> routes the message <NUM> to NRF <NUM>.

NRF <NUM> selects an appropriate network function based on network loads determined in conjunction with service proxy controller <NUM>. For example, NRF <NUM> can select PCF <NUM> because it currently is experiencing the lowest load among a pool of available PCFs. NRF <NUM> responds by sending a message <NUM> to service proxy worker <NUM> identifying PCF <NUM>. Service proxy worker <NUM> routes the message <NUM> to AMF <NUM>.

AMF <NUM> can then send a message <NUM> requesting service from PCF <NUM> to service proxy worker <NUM>. Service proxy worker <NUM> routes the message <NUM> to service proxy worker <NUM>. Service proxy worker <NUM> routes the message <NUM> to PCF <NUM>.

<FIG> is a signaling diagram illustrating an example message exchange <NUM> for telecommunications-aware alternate routing. <FIG> shows an SMF instance <NUM>, a service proxy worker <NUM>, the NRF <NUM>, the service proxy controller <NUM>, another service proxy worker <NUM>, a first PCF instance <NUM>, and a second PCF instance <NUM>.

Typically, the next hop selection is a function of NRF <NUM>. Sometimes, NRF <NUM> may provide complex routing rules that a consumer network function has to interpret and process. Similarly, a consumer network function has to implement logic associated with alternate routing in the case of an error message from the provider or retry the request with the same provider in the case of a timeout.

To support these aspects of a service-based architecture, consumer network functions would have to implement logic that is not associated with the application or service the network function is providing but purely to handle the various routing issues. Service proxy function <NUM> can alleviate these concerns by handling routing, alternate routing, and/or retries, for example, as illustrated by message exchange <NUM>.

Message exchange <NUM> begins with service proxy controller <NUM> sending messages <NUM> to push routing policies to service proxy workers <NUM> and <NUM>. SMF <NUM> has discovered PCF <NUM>; the discovery of PCF <NUM> is not shown. Then, PCF <NUM> fails.

Service proxy worker <NUM> detects the failure. Service proxy worker <NUM> and service proxy controller <NUM> exchange messages <NUM> in response to the failure. Messages <NUM> inform service proxy controller <NUM> of the failure and provide service proxy worker <NUM> with alternates from service proxy controller <NUM>.

SMF <NUM> then sends a session creation request message <NUM> to create a session with PCF <NUM>. Service proxy worker <NUM> routes the message <NUM> to service proxy worker <NUM>. Service proxy worker <NUM> re-targets the creation request <NUM> to PCF <NUM>.

In some cases, SMF <NUM> then sends a session update request message <NUM> to service proxy worker <NUM>, addressed for PCF <NUM>. Service proxy worker <NUM> routes the message <NUM> to service proxy worker <NUM>. Service proxy worker <NUM> can, in response, reject the update request or route, e.g., by sending a service unavailable message <NUM> to service proxy worker <NUM>. Service proxy worker <NUM> then routes the message <NUM> to SMF <NUM>. Alternatively, service proxy worker <NUM> can route to another destination.

<FIG> is a signaling diagram illustrating an example message exchange <NUM> for routing optimization carried out with the NRF. <FIG> shows an SMF instance <NUM>, a service proxy worker <NUM>, the NRF <NUM>, the service proxy controller <NUM>, another service proxy worker <NUM>, and a PCF instance <NUM>. The routing optimization can be performed, e.g., on a per-service basis.

Message exchange <NUM> begins with service proxy controller <NUM> exchanging messages <NUM> with NRF <NUM> for the purpose of routing optimization, e.g., without discovery. Service proxy controller <NUM> sends messages <NUM> to push routing policies to service proxy workers <NUM> and <NUM>. The routing policies can be specific to the network functions attached to the given service proxy workers. For example, the routing policies for service proxy worker <NUM> are specific to SMF <NUM>, and the routing policies for service proxy worker <NUM> are specific to PCF <NUM>.

SMF <NUM> sends a service request message <NUM> without PCF discovery. Service proxy worker <NUM> inspects the service request and routes the request <NUM> to service proxy worker <NUM>, addressed to PCF <NUM>. Service proxy worker <NUM> routes the message <NUM> to PCF <NUM>.

<FIG> is a signaling diagram illustrating an example message exchange <NUM> for overload/egress congestion control. <FIG> shows an SMF instance <NUM>, a service proxy worker <NUM>, the NRF <NUM>, the service proxy controller <NUM>, another service proxy worker <NUM>, and a PCF instance <NUM>.

Message exchange <NUM> begins with service proxy controller <NUM> exchanging messages <NUM> with service proxy workers <NUM> and <NUM> to push routing policies. Then, PCF <NUM> becomes congested <NUM>.

Service proxy worker <NUM> determines that PCF <NUM> is congested by monitoring telecommunications network core messages exchanged with PCF <NUM>. Service proxy worker <NUM> exchanges messages <NUM> with service proxy controller <NUM> to inform the service proxy controller <NUM> that PCF <NUM> is congested and to send prioritization policies from service proxy controller <NUM> to service proxy worker <NUM>.

Message exchange <NUM> continues with multiple service requests <NUM> being sent to service proxy worker <NUM> that are addressed to PCF <NUM>. Service proxy worker <NUM> routes high priority requests <NUM> and <NUM> to PCF <NUM>. Service proxy worker <NUM> rejects low priority requests <NUM> and <NUM> when no alternate servers are available, e.g., with <NUM> status, or service proxy worker <NUM> can divert some requests to alternate PCFs when available.

Egress can be based on capacity published during network function registration. Ingress controls can be based on, e.g., sudden increases in traffic rate.

<FIG> is a signaling diagram illustrating an example message exchange <NUM> for handling a network function failure or degradation. <FIG> shows an SMF instance <NUM>, a service proxy worker <NUM>, the NRF <NUM>, the service proxy controller <NUM>, another service proxy worker <NUM>, and a PCF instance <NUM>.

In the <NUM> architecture, for example, network functions are expected to be designed as cloud native microservices and when one consumer service synchronously invokes a service on the provider, there is a possibility that the provider service is unavailable or is exhibiting high latency. This may lead to resource exhaustion at the consumer, which would make the consumer service unable to handle other requests. The failure of one service can potentially cascade to other services within the network. Service proxy function <NUM> can potentially avoid such cascading failures by considering telecommunications network core messages, for example, as illustrated by message exchange <NUM>.

Message exchange <NUM> begins with service proxy controller <NUM> exchanging messages <NUM> with NRF <NUM> to push routing policies. SMF <NUM> discovers PCF <NUM>. Then, PCF <NUM> fails.

Service proxy worker <NUM> determines that PCF <NUM> has failed by monitoring telecommunications network core messages exchanged with PCF <NUM>. Service proxy worker <NUM> exchanges messages <NUM> with service proxy controller <NUM> to inform the service proxy controller <NUM> that PCF <NUM> is congested, and service proxy controller <NUM> responds with no alternates.

Then, SMF <NUM> sends a message <NUM> to service proxy worker <NUM> requesting a service from PCF <NUM>. Service proxy worker <NUM> routes the message <NUM> to service proxy worker <NUM>. Service proxy worker <NUM> "opens circuit. " Service proxy worker <NUM> responds to the request by sending a rejection message <NUM> to service proxy worker <NUM>, e.g., with <NUM> status. Service proxy worker <NUM> routes the message <NUM> to SMF <NUM>. If service proxy controller <NUM> determines alternate PCF instances, service proxy controller <NUM> can identify the alternate PCF instances to service proxy worker <NUM>, and service proxy worker <NUM> can divert requests addressed to PCF <NUM> to the alternates.

<FIG> is a signaling diagram illustrating an example message exchange <NUM> for implementing canary releases. <FIG> shows an SMF instance <NUM>, a service proxy worker <NUM>, the NRF <NUM>, the service proxy controller <NUM>, another service proxy worker <NUM>, a first PCF instance <NUM>, and a second PCF instance <NUM>.

Service proxy function <NUM> can play an important role in the roll out of new network function releases. Service proxy function <NUM> can support mechanisms that allow for a new release to be exposed to a fraction of the users or friendly users. Once successful, service proxy function <NUM> can slowly open up additional users to the new release in a controlled manner, providing confidence to the operator during the roll out. Service proxy function <NUM> can also facilitate blue-green deployments where operators can quickly stage a new network function release and after thorough testing, can roll over traffic in an instant to the newer release.

Message exchange <NUM> begins with service proxy controller <NUM> exchanging messages <NUM> with service proxy workers <NUM> and <NUM> to push routing policies. Service proxy controller <NUM> also exchanges messages <NUM> with NRF <NUM> to apply any appropriate NRF updates.

Then, a network operator configures a canary policy at service proxy controller <NUM>. Policies can be, for example, static or based on supported versions. Service proxy controller <NUM> exchanges messages <NUM> with service proxy worker <NUM> to push the appropriate portions of the canary policy to service proxy worker <NUM>.

In this example, the canary policy specifies that service proxy worker <NUM> is to distribute traffic addressed to PCF <NUM> across PCF <NUM> and PCF <NUM> in, e.g., a <NUM>-<NUM> ratio or other appropriate ratio. Service proxy worker <NUM> then receives multiple service requests <NUM> addressed to PCF <NUM>. Service proxy worker <NUM> routes some of the service requests <NUM> to PCF <NUM> and the remaining service requests to PCF <NUM> in accordance with the canary policy.

<FIG> is a flow diagram illustrating an example method <NUM> for providing a service proxy function in a telecommunications network core using a service-based architecture. Method <NUM> can be performed, e.g., by the service proxy controller <NUM> and service proxy workers <NUM>, <NUM>, <NUM>, and <NUM> of <FIG>.

Method <NUM> includes providing, from a service proxy controller implemented on at least one processor, routing policies for a telecommunications network core, e.g., the telecommunications network core <NUM> of <FIG> (<NUM>). The telecommunications network core includes network functions communicating using a service-based architecture. For example, the telecommunications network core can be a 3GPP <NUM> telecommunications network core, and the network functions include at least an AMF, a PCF, a UDM function, a SMF, and a NSSF. In some examples, the network functions include one or more of: a unified data repository (UDR), an authentication server function (ASF), and a network repository function (NRF).

Method <NUM> includes routing, at each service proxy worker of a number of service proxy workers implemented on the at least one processor, telecommunications network core messages between a respective subset of the network functions (<NUM>). Routing the telecommunications network messages includes consuming the routing policies from the service proxy controller and enforcing the routing policies from the service proxy controller while routing the telecommunications network core messages (<NUM>).

Method <NUM> includes providing, at each service proxy worker, network status reports to the service proxy controller based on the telecommunications network core messages (<NUM>). Method <NUM> can include receiving topology information, e.g., from the NRF and providing routing policies based on the topology information.

In some examples, providing routing policies includes performing load balancing between at least a first subset of network functions based on the network status reports from the service proxy workers. In some examples, routing telecommunications network core messages includes re-routing, at the service proxy worker, at least a first telecommunications network core message destined for a first network function based on a health status indicator for the first network function. In some examples, routing telecommunications network core messages includes re-trying, at the service proxy worker, a failed transmission of a first telecommunications network core message from a first network function to a second network function.

In some examples, the service proxy workers are deployed alongside instances of the network functions in a distributed computing system, and routing telecommunications network core messages includes acting as a default outbound proxy for the instances of the network functions. In some examples, providing routing policies for the telecommunications network core includes providing a traffic prioritization policy, and enforcing the routing policies includes shedding lower priority network traffic in response to detecting an overload condition according to the traffic prioritization policy.

Claim 1:
A system for providing a service proxy function (<NUM>) in a telecommunications network core (<NUM>), the system comprising:
a service proxy controller (<NUM>) implemented on at least one processor, wherein the service proxy controller is configured to provide a plurality of routing policies for the telecommunications network core (<NUM>), the telecommunications network core comprising a plurality of network functions communicating using a service-based architecture; and
a plurality of service proxy workers (<NUM>, <NUM>, <NUM>, <NUM>) implemented on the at least one processor, wherein each service proxy worker of the service proxy workers is configured to:
route telecommunications network core messages between a respective subset of the network functions in the telecommunications network core by consuming the routing policies from the service proxy controller and enforcing the routing policies from the service proxy controller; and
provide network status reports to the service proxy controller based on the telecommunications network core messages, wherein to provide network status reports comprises to provide one or more of: request and response counts for each network function; a message rate for each network function; and an average transmission latency for each network function.