Patent Description:
In the context of 5th generation core network (5GC), a network element called SCP (Service Communication Proxy) is defined that allows establishing an indirect communication between a consumer and a producer.

It is expected that the client (e.g., normally a consumer, except for notifications where the client is the producer) is configured with the SCP address for indirect communication. Therefore, a client is configured to use direct or indirect communication as described, for example in <NPL>, and <NPL>.

In 3GPP Release <NUM> for <NUM>, two communication modes exist, as described in aforementioned 3GPP TS <NUM> or in 3GPP Document <NPL>". A first mode is referred to as a direct mode, where a consumer communicates directly to a producer; and a mode referred to as an indirect mode, where a service communication proxy, SCP, is included as an intermediate element between a producer and a consumer. Further, with so-called delegated service discovery the SCP can discover services provided by the service producer on behalf of the NF service consumer by sending an according request to a network repository function, NRF.

3GPP document <NPL>" describes that multiple SCPs can be deployed in a PLMN, each of them in a region, e.g. a data center. Therein, a NF/NF service is associated with a certain SCP and served by this SCP.

3GPP Release <NUM>, however, does not explicitly describe how multiple SCP deployments should be handled, including in the case of multiple SCPs in line or of SCP redundancy.

The invention provides methods performed by a network repository function and by an SCP as well as corresponding network nodes according to the independent claims. Further, computer programs performing these methods are provided.

Further embodiments are defined in the respective dependent claims.

Potential advantages may include that deployment and routing path configuration are centralized in a function in a network node such as an NRF. The aggregation of NF and SCP per region allows route decisions to be taken on region level, which simplifies configuration and is less error prone, without requiring distributed configuration changes in multiple NFs/SCPs.

In 3GPP Release <NUM> for <NUM>, two communication modes exist. A mode referred to as a direct mode, where a consumer communicates directly to a producer; and a mode referred to as an indirect mode, where a SCP is included as an intermediate element between a producer and a consumer. 3GPP Release <NUM>, however, does not explicitly describe how multiple SCP deployments should be handled, including in the case of multiple SCPs in line or of SCP redundancy.

Potential solutions for handling multiple SCP deployments may include the following.

In the case of SCP redundancy where alternative SCPs are configured in a client, a potential solution may be as follows. If a first SCP (e.g., SCP1-a) is not reachable, then a second SCP (e.g., SCP1-b) is chosen. Load balancing can be applied between available SCPs. Such a potential solution is not described in 3GPP Release <NUM>, and may be implementation specific.

In the case of multiple SCPs in a routing path, a potential solution may be as follows. Sometimes, a producer can only be reached by a consumer via multiple SCPs. For example, two SCPs, where one SCP is closer to the consumer and another SCP is closer to the producer and it is not precluded to have more SCPs in the routing path. In some cases, it may make sense to have multiple SCPs in a routing path such as, for example, in a transit network. That is, a network is traversed between the producer network and the consumer network. In another example, there may be an SCP per public land mobile network (PLMN) having different "groups" of network functions (NFs) that may be accessed by an SCP, such as multiple trust domains in the same PLMN, different vendor "platforms" isolated by an SCP, and/or different (entry) PLMN SCP depending on the visited PLMN (V-PLMN).

If there are multiple SCPs in a routing path (e.g. SCP1, SCP2, etc.), 3GPP Release <NUM> appears to assume that SCP1 is configured to reach SCP2, while SCP2 is configured to reach SCP3, etc. However, nothing is specified in 3GPP Release <NUM>.

The following explanation of potential problems is a present realization as part of the present disclosure and is not to be construed as previously known by others. As described above, a solution for handling multiple SCP deployments is not described in 3GPP Release <NUM>. Rather, 3GPP Release <NUM> only indicates that each NF configures an address of the SCP, which has potential limitations including, for example:.

Various embodiments described herein may operate to provide solutions to these and other potential problems.

In various embodiments, deployment information may be registered/stored in a network repository function (NRF) (also referred to herein as a network repository node) which may be used by a NF and an SCP to determine a route(s) for a service request. In this way, deployment information is centralized in the NRF, and the client NF/SCP is able to get the next hop in a routing path.

The NF may be any of an AMF(Access and Mobility Management Function), a SMF (Session Management Function), a PCF (Policy Charging Function), a NEF (Network Exposure Function), a NSSF (Network Slice Selection Function), a SMSF (Short Message Service Function), an AUSF (Authentication Server Function), a CHF (Charging Function), a NRF, a NWDAF (Network Data Analytics Function), an I-CSCF (Interrogating - Call Session Control Function), a S-CSCF (Serving- Call Session Control Function), an IMS-AS (IP Multimedia Subsystem - Application Server), a UDM (Unified Data Management), a UDR (User Data Repository), an AF (Application Function), etc..

<FIG> depicts an example deployment in a telecommunications network <NUM> including NRF <NUM> and three regions (regions A, B, and C). Referring to <FIG>, region A includes "Consumer <NUM>" <NUM>, "SCP 1a" 107a and SCP 1b (shown beneath 107a), region B includes "Producer <NUM>" <NUM>, "SCP 2a" 107b and SCP 2b (shown beneath 107b). Region C includes "SCP3a" 107c and SCP 3b (shown beneath 107c).

The SCP can be deployed at PLMN level, at shared-slice level, and at slice-specific level. It is left to operator deployment to ensure that SCPs can communicate with relevant NRFs.

In various embodiments of inventive concepts, information stored/registered in the NRF (e.g., NRF <NUM>) includes, without limitation, an SCP profile for each of one or more SCPs. An SCP profile includes, without limitation, SCP information such as, e.g., availability, priority, capacity, locality, etc. An SCP profile may further include a region in which the SCP belongs. This allows determining a list of SCPs per region. Alternatively, in some embodiments, this could be a region profile. Referring to the example deployment in <FIG>, an SCP profile or region profile includes the following for each region: Region A includes "SCP 1a" 107a and SCP 1b; Region B includes "SCP 2a" 107b and SCP 2a; and Region C includes "SCP 3a" 107c and SCP 3b. The SCP profile or region profile can be initially configured but can be modified or updated dynamically by each SCP in the telecommunications network (e.g., SCP registration in NRF).

In various embodiments of inventive concepts, information stored/registered in the NRF (e.g., NRF <NUM>) further includes, without limitation, a NF profile updated with region information; and a region path configuration. The region path configuration includes, without limitation, an identity of the regions a consumer needs to traverse to reach a producer. For example, referring to <FIG>, to reach "Producer <NUM>" <NUM>, "Consumer <NUM>" <NUM> needs to be routed via region C. That is, routed from region A to region C to region B as shown in <FIG>. Such routing may require some configuration in NRF <NUM>. Alternatively, depending on the routing complexity, in some cases, the region path configuration can be part of the SCP profile (e.g., if there is only one SCP per region).

In various embodiments of inventive concepts, an NF and SCPs register their profiles with region information in the NRF, and each NF and SCP discovers from the NRF the NF and SCP region relation. This allows each consumer/client NF to discover from the NRF information for whether the consumer/client NF has to establish a direct or indirect communication. In the case of indirect communication, the next (region) hop, that may be served by one SCP or a list of SCPs is discovered, and then selection is performed by the consumer/client. Each SCP may perform a discovery for the corresponding next region as well.

That is, once the deployment information (including region) is centralized in the NRF, each NF/SCP is able to discover the next hop address.

The routing logic also can use other information known from application processing (e.g. message parameters in service requests) and combine this information with deployment information to determine a route.

In some embodiments of inventive concepts, alternatively, the region path configuration is not stored in the NRF, but is inferred. An NF consumer and the SCP can use the region information as additional information for selecting a NF producer or an SCP to route to. Depending on the network topology and services to be invoked, the region information obtained from the NRF can be completely sufficient to route service requests. The SCP/NF can select the next hop (region) based, e.g., on location or availability.

Potential advantages of presently disclosed embodiments may include that deployment and routing path configuration are centralized in a NRF. The aggregation of NF and SCP per region allows route decisions to be taken on region level, what simplifies configuration and is less error prone, without requiring distributed configuration changes in multiple NFs/SCPs.

Additional potential advantages of presently disclosed embodiments may include that a region in which an SCP is deployed may be changed dynamically by updating each SCP profile (by configuration or by registering an updated SCP profile). Region routing path can be changed in the NRF as well, e.g. for providing a new service or by configuration. Alternatively, for a simple enough deployment (e.g. if the routing path is defined for each region, without having a granularity of e.g. services), the routing path can be part of the SCP profile, including a field to consider next Region.

Additional potential advantages of presently disclosed embodiments may include that regions are defined, where each region contains multiple SCPs (that may have very different capabilities). Then, routing can be fully dynamic within a region, while the only need for a static configuration may be limited to the region path from a consumer to a producer. When there is no more than one or two regions in between the region (of producer and/or consumer), then the need of static configuration is very limited for, e. g, deployment needs that will not change easily (e.g. definition of a transit SCP for a PLMN).

Additional potential advantages of presently disclosed embodiments may include that each NF/SCP (client) does not need to be configured with the SCP to be used, nor with the indication to use direct or indirect communication, but the client discovers that information. That is, the NF/SCP is able to get dynamically the next hop (i.e. either direct or indirect communication, and for indirect the SCP(s) that may be used). This may simplify deployment and routing path modifications. This also may optimize or improve communication in a region, since the communication from a consumer to a producer in the same region can be identified as direct, based on NRF information, avoiding the need to configure that in the client (each client may need to be configured with a list of the producers in the same region).

Additional potential advantages of presently disclosed embodiments may include that the region routing path is not configured, but in a case of multiple regions available to reach the same producer, the next Region can be selected based on availability or other available information, e.g. location.

Region path configuration may include, without limitation, routing path definitions. Routing paths may be defined with different granularities: e.g. per NF type, per NF instance, per NF service type, per NF service instance, per NF Set, per NF service Set, per NF service operation, per Group (partitions), etc..

Utility may depend on an operator's deployments. For example, different NF Sets may be provided by different vendors in different trust domains. Each trust domain could deploy a different SCP.

<FIG> depicts an example of SCP registration and discovery by SCPs in the example telecommunications network of <FIG>. In the SCP registration, all SCPs (e.g., SCP 107a, SCP 107v, and SCP 107c) register its profile in the NRF <NUM> in block <NUM>.

In SCP discovery, an SCP can identify if there are other SCPs in a routing path by sending a request to the NRF. For example, SCP 107b in block <NUM> transmits a NRF operation Next hop message to the NRF <NUM>. The SCP 107b receives a list identifying SCPs in a next hop of the SCP 107b from the NRF <NUM>. In <FIG>, the list for SCP 107b contains SCP 107C and other SCPs in Region C. In block <NUM>, SCP 107c transmits a NRF operation Next hop message to the NRF <NUM>. The SCP 107c receives a list identifying SCPs in a next hop of the SCP 107c from the NRF <NUM> in block <NUM>, where the list of SCPs contains SCP 107a and other SCPs in region A and SCP 107b and other SCPS in Region B. In block <NUM>, SCP 107a transmits a NRF operation Next hop message to the NRF <NUM>. The SCP 107a receives a list identifying SCPs in a next hop of the SCP 107a from the NRF <NUM> in block <NUM>, where the list of SCPs contains SCP 107c and other SCPs in region C.

In some embodiments of inventive concepts, the region path (e.g., routing path) configuration is per NF. The SCPs may discover the next hop independently of the producer that needs to be reached. For example, the region path to reach producer <NUM> from consumer <NUM> is not the same as the path to reach producer <NUM> from consumer <NUM>. In these embodiments, the NRF <NUM> has Region and SCP information, and deployment information for each consumer-producer path. <FIG> depicts direct communication within a region. In block <NUM>, the consumer <NUM> performs producer <NUM> service discovery via NRF <NUM>. The NRF <NUM> provides a direct communication path to the consumer <NUM> in a service discovery result in block <NUM>. In block <NUM>, the consumer <NUM> selects producer <NUM> instances. In block <NUM>, the consumer <NUM> transmits a producer service request to producer <NUM> using direct communication.

<FIG> depicts indirect communication via next hop SCP discovery. The NRF <NUM> has Region and SCP information, and deployment information for each consumer-producer path. In <FIG>, the Region path configuration is per NF, so the SCPs have already discovered next hop independently of the producer that needs to be reached, as described in <FIG> above. Thus, the SCPs do not have to perform service discovery to determine next hop paths. In block <NUM>, the consumer <NUM> performs producer <NUM> service discovery via NRF <NUM>. The consumer <NUM> in block <NUM> receives a service discover request that lists next hop: SCP 107b instances. The consumer <NUM> selects an SCP 107b instance in block <NUM> and sends a producer <NUM> service request via the selected SCP 107b instance. In block <NUM>, the SCP 107b instance transmits the producer <NUM> service request to the next hop in region C after selecting an SCP 107c. In block <NUM>, the next hop for the SCP 107c selected is an SCP in Region A. The SCP 107c that was selected chooses an SCP 107a and transmits the producer <NUM> service request to the selected SCP 107a in block <NUM>. The selected SCP 107a sends the producer <NUM> service request to producer <NUM>, receives a response to the producer <NUM> service request, and sends the response back to an SCP 107c in Region C. The SCP 107c in Region C sends the response back to an SCP 107b in Region B. The SCP 107b in Region B sends the response to consumer <NUM>.

If Region path is defined per service granularity, then even though discovery per NF granularity may be done (see <FIG>),a discovery for a specific producer is required to be performed, which is depicted in <FIG>. The NRF <NUM> has Region and SCP information, and deployment information for each consumer-producer path. In block <NUM>, consumer <NUM> performs producer <NUM> service discovery by sending a service discovery request to the NRF <NUM>. The NRF <NUM> transmits a service discovery response to the consumer <NUM> in block <NUM> where the service discovery response lists a next hop indicating an instance of SCP 107b is the next hop to reach producer <NUM>. The consumer <NUM> selects an SCP 107b instance in block <NUM> where the selection may be based on e.g., locality. The consumer <NUM> transmits a producer <NUM> service request via the selected SCP 107b instance in block <NUM>.

The selected SCP 107b instance identifies if there are other SCPs in the region path in block <NUM>. This may be done by sending a next hop discovery request to the NRF <NUM>. In block <NUM>, the selected SCP 107b instance receives a discovery response from NRF <NUM>. The discovery response indicates the next hop to reach producer <NUM> is Region C. The discovery response has a list of SCPs, which lists SCP 107c instances. In block <NUM>, the selected SCP 107b instance selects an SCP 107c instance and transmits the producer <NUM> service request to the selected SCP 107c instance.

In block <NUM>, the selected SCP 107c instance identifies if there are other SCPs in the region path to producer <NUM>. This may be done by sending a next hop discovery request to the NRF <NUM>. In block <NUM>, the selected SCP 107c instance receives a discovery response from NRF <NUM>. The discovery response indicates the next hop to reach producer <NUM> is Region A. The discovery response has a list of SCPs, which lists SCP 107a instances. In block <NUM>, the selected SCP 107c instance selects an SCP 107a instance and transmits the producer <NUM> service request to the selected SCP 107a instance.

The selected SCP 107a instance sends the producer <NUM> service request to producer <NUM>, receives a response to the producer <NUM> service request, and sends the response back to an SCP 107c instance in Region C. The SCP 107c instance in Region C sends the response back to an SCP 107b instance in Region B. The SCP 107b instance in Region B sends the response to consumer <NUM>.

In <FIG>, a discovery request is sent to the NRF <NUM> to find the routing path between a consumer and a producer when there are multiple SCPs to determine the next hop. In some embodiments, the complete routing path is returned in the discovery response.

Turning to <FIG>, non-delegated discovery is depicted to receive a whole routing path. In block <NUM>, the consumer <NUM> transmits a producer <NUM> service discovery request to the NRF <NUM>. The discovery request may in include a target service (e.g., producer <NUM>), an NF identifier, a slice identifier, a plmn identifier, etc. The response to the discovery request is transmitted to the consumer <NUM> in block <NUM>. The response includes the address of each SCP in the path from consumer <NUM> to producer <NUM> (i.e., SCP 107a, SCP 107c, and SCP 107b (not shown)). The consumer <NUM> transmits a producer <NUM> service request to SCP 107a in block <NUM>. The producer <NUM> service request may include concatenated SCP addresses of SCPs in the path from SCP 107a to producer <NUM> (e.g., SCP 107c and SCP107b).

The SCP 107a receives the producer <NUM> service request and sends the producer <NUM> service request to the next SCP in the path (e. g, SCP 107c) to producer <NUM> in block <NUM>. The next SCP in the path (SCP 107c) then sends the producer <NUM> service request to the next SCP in the path if there are additional SCPs in the path. The last SCP in the path send the producer <NUM> service request to the producer <NUM>.

Turning to <FIG>, a delegated discovery is depicted to receive a whole routing path. In block <NUM>, the consumer <NUM> transmits a producer <NUM> service discovery request to an SCP in the consumer's region, which in <FIG> is SCP 107a. The discovery request may include a target service (e.g., producer <NUM>), an NF identifier, a slice identifier, a plmn identifier, etc. In block <NUM>, the SCP 107a transmits a producer <NUM> service discovery request to the NRF <NUM>.

The service discovery request may include additional information based on the target service. Examples of the additional information are:.

The response to the discovery request is transmitted to the SCP 107a in block <NUM>. The response includes the address of each SCP in the path from the SCP 107a to producer <NUM> (e.g., SCP 107c and SCP 107b (not shown)).

The response to the discovery request can include further information that relates to the target service. Examples of the further information include:.

The SCP 107a transmits a producer <NUM> service request to SCP 107c in block <NUM>. The producer <NUM> service request may include concatenated SCP addresses of SCPs in the path from SCP 107a to producer <NUM> (e.g., SCP 107c and SCP107b).

The SCP 107c receives the producer <NUM> service request and sends the producer <NUM> service request to the producer <NUM> in block <NUM> if there are no other SCPs in the path. If there are additional SCPs in the path, the SCP 107c sends the producer <NUM> service request to the next SCP in the path.

The SCPs that receive a service request have to identify that the request needs to reach a producer in its Region. There are a few ways that this identification may be done.

In a first way, 3GPP TS <NUM> v16. <NUM>, the usage of the 3gpp-Sbi-Target-apiRoot header for indirect communication via SCP, to allow the SCP to identify the real (service) target is described.

A client may use the 3GPP-Sbi-Target-apiRoot in a different way in that each SCP that receives a request that includes this header should check whether this target is within the Region (each NF includes the Region it belong to, as commented above). If the target is not within the Region the SCP is within, the SCP should find next (Region) hop.

In a second way, each SCP in the middle of a path is only considered a transit SCP (without local NFs). A transit SCP should always find the next (Region) hop and then forward 3gpp-Sbi-Target-apiRoot header.

Either of the two ways may be applied. The address of SCP(s) may be included in the existing, but modified HTTP custom header sbi-target-apiroot as described above, or as an alternative a new custom header could be defined to convey the routing path.

The SCP in each hop is responsible to remove the next hop SCP URI from the custom header, and route to that URI. This is depicted in <FIG>.

Turning to <FIG>, in NRF discovery block <NUM>, the NRF <NUM> determines the request routing path as: cons->SCP1->SCP2->SCP3->Producer. The NRF <NUM> constructs the cascading URI: SCP1. com/xxx/svcA. The discovery result provided in the NF profile is generated:.

In service request block <NUM>, the consumer <NUM> generates a service request based on the cascading URI and constructs the next hop http2 headers:.

The consumer <NUM> sends the service request to the first SCP (e.g., SCP 107a).

In service request block <NUM>, the SCP 107a receives the service request from the consumer <NUM>. The SCP 107a updates the cascading URI by removing the SCP 107a address: cascading URI: SCP2. com/xxx/svcA. The SCP 107a constructs the next hop http2 headers:.

The SCP 107a sends a service request to the next hop (e.g., SCP 107c).

In service block <NUM>, the SCP 107c receives the service request from SCP 107a. The SCP 107c updates the cascading URI by removing the SCP 107c address: cascading URI: SCP3. com/xxx/svcA. The SCP 107c constructs the next hop http2 headers:.

The SCP 107c sends a service request to the next hop (e.g., SCP 107b).

In service block <NUM>, the SCP 107b receives the service request from SCP 107c. The SCP 107b updates the cascading URI by removing the SCP 107b address: cascading URI: Prod. com/xxx/svcA. The SCP 107b constructs the next hop http2 headers:.

The SCP 107b sends a service request to the producer <NUM>.

The producer <NUM> receives the service request with the received http2 headers:.

The above figures describe the various embodiments in signaling diagrams. Each of the producers <NUM>, <NUM> and consumers <NUM>, 111may be implemented as network nodes. The NRF <NUM> may be implemented as a network repository node and the service communication proxies 104a, 107b, 107c may be implemented as a separate node.

<FIG> is a block diagram illustrating elements of a network repository node <NUM> (also referred to as network node/terminal/device, etc.) configured to provide communication according to embodiments of inventive concepts. As shown, network repository node <NUM> may include a network interface <NUM> configured to provide communications with base station(s) of a network, SCPs, and other network nodes such as consumer nodes and producer nodes. Network repository node <NUM> may also include processing circuitry <NUM> coupled to the network interface circuitry <NUM>, and memory circuitry <NUM> (also referred to as memory) coupled to the processing circuitry <NUM>. The memory circuitry <NUM> may include computer readable program code that when executed by the processing circuitry <NUM> causes the processing circuitry to perform operations according to embodiments disclosed herein. According to other embodiments, processing circuitry <NUM> may be defined to include memory so that separate memory circuitry is not required. Network repository node <NUM> may also include an interface (such as a user interface) coupled with processing circuitry <NUM>, and/or network repository node <NUM> may be incorporated in a vehicle.

As discussed herein, operations of network repository node <NUM> may be performed by processing circuitry <NUM>. Moreover, modules may be stored in memory circuitry <NUM>, and these modules may provide instructions so that when instructions of a module are executed by processing circuitry <NUM>, processing circuitry <NUM> performs respective operations (e.g., operations discussed below with respect to Example Embodiments relating to network repository nodes).

<FIG> is a block diagram illustrating elements of a first network node <NUM> (also referred to as a consumer network node, a producer network node, network node/terminal/device, etc.) configured to provide communication according to embodiments of inventive concepts. As shown, first network node <NUM> may include a network interface <NUM> configured to provide communications with base station(s) of a network, SCPs, and other network nodes such as consumer nodes and producer nodes. First network node <NUM> may also include processing circuitry <NUM> coupled to the network interface circuitry <NUM>, and memory circuitry <NUM> (also referred to as memory) coupled to the processing circuitry <NUM>. The memory circuitry <NUM> may include computer readable program code that when executed by the processing circuitry <NUM> causes the processing circuitry to perform operations according to embodiments disclosed herein. According to other embodiments, processing circuitry <NUM> may be defined to include memory so that separate memory circuitry is not required. First network node <NUM> may also include an interface (such as a user interface) coupled with processing circuitry <NUM>, and/or first network node <NUM> may be incorporated in a vehicle.

As discussed herein, operations of first network node <NUM> may be performed by processing circuitry <NUM>. Moreover, modules may be stored in memory circuitry <NUM>, and these modules may provide instructions so that when instructions of a module are executed by processing circuitry <NUM>, processing circuitry <NUM> performs respective operations (e.g., operations discussed below with respect to Example Embodiments relating to first network nodes).

<FIG> is a block diagram illustrating elements of a second network node <NUM> (also referred to as network node/terminal/device, etc.) configured to provide communication according to embodiments of inventive concepts. As shown, second network node <NUM> may include a network interface <NUM> configured to provide communications with base station(s) of a network, SCPs, and other network nodes such as consumer nodes and producer nodes. Second network node <NUM> may also include processing circuitry <NUM> coupled to the network interface circuitry <NUM>, and memory circuitry <NUM> (also referred to as memory) coupled to the processing circuitry <NUM>. The memory circuitry <NUM> may include computer readable program code that when executed by the processing circuitry <NUM> causes the processing circuitry to perform operations according to embodiments disclosed herein. According to other embodiments, processing circuitry <NUM> may be defined to include memory so that separate memory circuitry is not required. Network repository node <NUM> may also include an interface (such as a user interface) coupled with processing circuitry <NUM>, and/or network repository node <NUM> may be incorporated in a vehicle.

As discussed herein, operations of a second network node <NUM> may be performed by processing circuitry <NUM>. Moreover, modules may be stored in memory circuitry <NUM>, and these modules may provide instructions so that when instructions of a module are executed by processing circuitry <NUM>, processing circuitry <NUM> performs respective operations (e.g., operations discussed below with respect to Example Embodiments relating to second network nodes).

<FIG> is a block diagram illustrating elements of a service communication proxy <NUM> (also referred to as SPC node/terminal/device, etc.) configured to provide communication according to embodiments of inventive concepts. As shown, SCP node <NUM> may include a network interface <NUM> configured to provide communications with base station(s) of a network, other SCPs, and other network nodes such as consumer nodes and producer nodes. SCP <NUM> may also include processing circuitry <NUM> coupled to the network interface circuitry <NUM>, and memory circuitry <NUM> (also referred to as memory) coupled to the processing circuitry <NUM>. The memory circuitry <NUM> may include computer readable program code that when executed by the processing circuitry <NUM> causes the processing circuitry to perform operations according to embodiments disclosed herein. According to other embodiments, processing circuitry <NUM> may be defined to include memory so that separate memory circuitry is not required. SCP <NUM> may also include an interface (such as a user interface) coupled with processing circuitry <NUM>, and/or SCP <NUM> may be incorporated in a distributed network where functions of the SCP are distributed across network nodes.

As discussed herein, operations of SCP <NUM> may be performed by processing circuitry <NUM>. Moreover, modules may be stored in memory circuitry <NUM>, and these modules may provide instructions so that when instructions of a module are executed by processing circuitry <NUM>, processing circuitry <NUM> performs respective operations (e.g., operations discussed below with respect to Example Embodiments relating to SCPs).

Operations of a network function that may be implemented in the network repository node <NUM> (implemented using the structure of the block diagram of <FIG>) or in the SCP <NUM> (implemented using the structure of the block diagram of <FIG>) or in another network node will now be discussed with reference to the flow chart of <FIG> according to some embodiments of inventive concepts. For example, modules may be stored in memory <NUM> of <FIG> or memory <NUM> of <FIG>, and these modules may provide instructions so that when the instructions of a module are executed by respective communication device processing circuitry <NUM> (or <NUM>), processing circuitry <NUM> (or <NUM>) performs respective operations of the flow chart.

In the description that follows, processing circuitry <NUM> shall be used to describe the flow chart of <FIG>. Turning now to <FIG>, in block <NUM>, processing circuitry <NUM> receives a request for routing information to signal a message from a first network node <NUM> to a second network node <NUM>. The first network node may be a first SCP and the second network node may be a second SCP in some embodiments. In other embodiments, the first network node is one of a first SCP and a first network function in a network node in the second network node is one of a second SCP and a second function in a second network node. The request may be received from the first network node <NUM> or from a SCP node <NUM>.

In block <NUM>, the processing circuitry, responsive to the request for routing information, provides a response to the network node that sent the request wherein the response identifies at least a portion of a routing path for the message based on a routing path configuration that identifies at least a portion of a routing path for the message based on a routing path configuration. In some embodiments, identifying the at least a portion of the routing path for the message based on the routing path configuration includes identifying at least a portion of a routing path for the message based on the routing path configuration, a profile of at least one of the at least one SCP, and a profile of the second network node.

The routing path configuration in some embodiments includes an identity of a plurality of regions in at least one routing path for the message between the first network node and the second network node. Each of the plurality of regions includes at least one SCP, and the identity of the plurality of regions in the at least one routing path are correlated to the identity of the at least one SCP included in each of the plurality of regions.

The profile of the at least one SCP includes information about the SCP in a region in which the SCP is deployed. The profile of the second network node includes a region in which the second network node is deployed. Additionally, in some embodiments, the portion of the routing path for the message may be further based on the profile of the first network node.

In various embodiments, the request is a request for a next Identity for signaling the message from the first network node to the second network node. The response to the first network node identifies at least a portion of a routing path that includes the identity of a first SCP from the at least one SCP.

In block <NUM>, the processing circuitry <NUM> receives a request from the first SCP for a next hop identity for signaling the message from a first network node to the second network node. Responsive to the request from the first SCP, the processing circuitry <NUM> provides a response to the first SCP including the identity of a second SCP from the at least one SCP.

In block <NUM>, the processing circuitry <NUM> receives a request from a subsequent SCP from the at least one SCP for a next hop identity for signaling the message from the first network node to the second network node. Responsive to the request from the subsequent SCP the processing node in block <NUM> provides a response to the set subsequent SCP that includes at least one of the identity of a next SCP from the at least one SCP in the routing path or a null response or a network function identity.

In some embodiments, each of the next hop identity and the identity of the next SCP may be an address. In some embodiments, the routing path configuration and the profile of at least one of the last at least one SCP and the second network node are stored in a network repository node. In some of these embodiments, the routing path configuration is included in the profile of the at least one of the at least one SCP. The routing path configuration in some embodiments may be routing path defined by at least one of a per network node configuration or a per service granularity. The routing path configuration and the profile of the at least one of the at least one SCP and the second network node may be dynamically updated.

In yet other embodiments, the request is a request for discovering an identity of the routing path to signal the message from the first network node to the second network node. The response to the network node that sent the request identifies at least a portion of the routing path and includes the identity of the SCPs in the routing path from the first network node to the second network node. In some of these embodiments, the routing path includes a plurality of hops. Each hop of the routing path includes an address for an SCP or an address for each SCP when redundant SCPs are included in a hop.

In other embodiments, the routing path includes a plurality of hops. Each have in the routing path includes an indication of priority for selection or reselection of each of the SCP's included in the routing path.

Various operations from the flow chart of <FIG> may be optional with respect to some embodiments of network nodes and related methods. Regarding, for example, operations of blocks <NUM><NUM>, <NUM>, and <NUM> of <FIG> may be optional.

Turning now to <FIG>, operations of a SCP <NUM> (implemented using the structure of the block diagram of <FIG>) will now be discussed with reference to the flow chart of <FIG> according to some embodiments of inventive concepts. For example, modules may be stored in memory <NUM> of <FIG>, and these modules may provide instructions so that when the instructions of a module are executed by respective SCP processing circuitry <NUM>, processing circuitry <NUM> performs respective operations of the flow chart.

In block <NUM>, the processing circuitry <NUM> signals a request to a function in a network node to discover an identity of each SCP in a plurality of SCPs deployed in a routing path between the first network node and the second network node. The identity may be an address.

In block <NUM>, responsive to the signal on, the processing circuitry receives an identification of the identities of each SCP in the plurality of SCP's deployed in the routing path between the first network node and the second network node. In some embodiments, the identification includes information about each SCP in the plurality of SCPs and a region in which each SCP is deployed. In other embodiments, the information about each SCP in the plurality of SCPs includes an availability of each SCP.

In block <NUM>, the processing circuitry <NUM> discovers at least a next hop in the routing path based on the identification. In block <NUM>, the processing circuitry <NUM> registers a profile of the SCP in a network repository node. The registering includes information about the SCP and a region in which the SCP is deployed.

In block <NUM>, the processing circuitry <NUM> receives a request from a first SCP for an identity of a next hop for signaling a message from the first network node to the second network node. In block <NUM>, responsive to the request from the first SCP, the processing circuitry <NUM> provides a response to the first SCP that includes the identity of a second SCP from the plurality of SCPs.

In block <NUM>, the processing circuitry <NUM> receives from the first network node a first request that includes an indication that the first request is directed to the second network node. In block <NUM>, the processing circuitry signals a second request to a network repository node for an identity of a next hop for signaling the first request to the second network node.

In block <NUM>, responsive to signaling the second request, the processing circuitry <NUM> receives a response from the network repository node that includes at least one of the identity of a next SCP from the plurality of SCPs in the routing path, a null response, or a network function identity.

In some embodiments, the processing circuitry <NUM> receives from the first network node a first request comprising an indication that the first request is directed to the second network node where the first request further includes an identity of at least a next hop in the routing path for signaling the first request to the second network node. Responsive to receiving the first request, the processing circuitry signals the first request to the second network node. The indication in some embodiment includes a header in the first request indicating an identity of the second network node.

Claim 1:
A method performed by a network repository function (<NUM>, <NUM>) of a telecommunications network (<NUM>) having a plurality of service communication proxies, SCPs (<NUM>), deployed between a first network node (<NUM>) and a second network node (<NUM>), the method comprising:
receiving (<NUM>), from a first SCP of the plurality of SCPs, a request for a next hop identity to signal a message from the first network node to the second network node; and
responsive to the request from the first SCP, providing (<NUM>) a response to the first SCP wherein the response identifies at least a portion of a routing path for the message based on a routing path configuration, wherein the response includes the identity of a second SCP of the plurality of SCPs.