Patent Description:
There exist various techniques for handling a request for a service in a network. A service request is generally from a consumer of the service ("service consumer") to a producer of the service ("service producer"). For example, a service request may be from a network function (NF) node of a service consumer to an NF node of a service producer. The NF node of the service consumer and the NF node of the service producer can communicate directly or indirectly. This is referred to as direct communication and indirect communication respectively. In the case of indirect communication, the NF node of the service consumer and the NF node of the service producer may communicate via a service communication proxy (SCP) node.

<FIG>illustrates different existing systems for handling service requests, as set out in 3GPP TS <NUM> v16. In more detail, <FIG> illustrates a system that uses direct communication, while <FIG> illustrates a system that uses indirect communication.

In the systems illustrated in <FIG>, a service request is sent directly from the NF node of the service consumer to the NF node of the service producer. A response to the service request is sent directly from the NF node of the service producer to the NF node of the service consumer. Similarly, any subsequent service requests are sent directly from the NF node of the service consumer to the NF node of the service producer. The system illustrated in <FIG> also comprises a network repository function (NRF). Thus, in the system illustrated in <FIG>, the NF node of the consumer can query the NRF to discover suitable NF nodes of the service producer to which to send the service request. In response to such a query, the NF node of the consumer can receive an NF profile for one or more NF nodes of the service producer and, based on the received NF profile(s) can select an NF node of the service producer to which to send the service request. In the system illustrated in <FIG>, the NRF is not used and instead the NF node of the consumer may be configured with the NF profile(s) of the NF node(s) of the service producer.

In the systems illustrated in <FIG>, a service request is sent indirectly from the NF node of the service consumer to the NF node of the service producer via a service communication proxy (SCP) node. A response to the service request is sent indirectly from the NF node of the service producer to the NF node of the service consumer via the SCP. Similarly, any subsequent service requests are sent indirectly from the NF node of the service consumer to the NF node of the service producer via the SCP. The systems illustrated in <FIG> also comprise an NRF.

In the system illustrated in <FIG>, the NF node of the consumer can query the NRF to discover suitable NF nodes of the service producer to which to send the service request. In response to such a query, the NF node of the consumer can receive an NF profile for one or more NF nodes of the service producer and, based on the received NF profile(s) can select an NF node of the service producer to which to send the service request. In this case, the service request sent from the NF node of the service consumer to the SCP comprises the address of the selected NF node of the service producer. The NF node of the service consumer can forward the service request without performing any further discovery or selection. In case the selected NF node of the service producer is not accessible for any reason, it may be up to the NF node of the service consumer to find an alternative. In other cases, the SCP may communicate with the NRF to acquire selection parameters (e.g. location, capacity, etc.) and the SCP may select an NF node of the service producer to which to send the service request.

In the system illustrated in <FIG>, the NF node of the consumer does not carry out the discovery or selection process. Instead, the NF node of the consumer adds any necessary discovery and selection parameters (required to find a suitable NF node of the service producer) to the service request that it sends via the SCP. The SCP uses the request address and the discovery and selection parameters in the service request to route the service request to a suitable NF node of the service producer. The SCP can perform discovery with the NRF.

For the fifth generation core (5GC), from Release <NUM>, the SCP is included as a network element to allow indirect communication between an NF node of a service consumer and an NF node of a service producer. The indirect communication that is used can be either of the two indirect communications options described earlier with reference to <FIG>.

<FIG> is a signalling diagram illustrating an exchange of signals in an existing system, such as the system illustrated in <FIG> but it will be understood the issue described can also apply to the system illustrated in <FIG>. The system illustrated in <FIG> comprises a first SCP node <NUM>, a second SCP node <NUM>, a first NF node <NUM> of a service consumer ("NFc"), a second NF node <NUM> of a service producer ("NFp1"), and a third NF node <NUM> of a service producer ("NFp2"). The first SCP node <NUM> is configured to operate as an SCP between the first NF node <NUM> and the second NF node <NUM>. The second SCP node <NUM> is configured to operate as an SCP between the first NF node <NUM> and the third NF node <NUM>.

In the system illustrated in <FIG>, the second SCP node <NUM> is an SCP node that is in the same SCP domain <NUM> as the first SCP node <NUM>. The second SCP node <NUM> is a different SCP node to the first SCP node <NUM>. The second NF node <NUM> can be configured to run a service <NUM> and the third NF node <NUM> can be configured to run a service <NUM>. The second NF node <NUM> and the third NF node <NUM> can be configured to run the same service or a different service. The second NF node <NUM> and the third NF node <NUM> can be part of a set <NUM> of NF nodes of a service producer. The system illustrated in <FIG> also comprises a network repository function <NUM>.

In <FIG>, steps <NUM>-<NUM> relate to a first request for a user equipment (UE)/session context. As illustrated by block <NUM> of <FIG>, the UE/session context may be stored. In more detail, as illustrated by block <NUM> of <FIG>, the first NF node <NUM> determines what discovery and selection parameters to use. The parameters can be associated with a certain service in a received request, which is not illustrated in <FIG>. As illustrated by blocks <NUM> and <NUM> of <FIG>, the first NF node <NUM> stores the UE/session context for the request received. This storage may be cached or externally stored.

As illustrated by arrow <NUM> of <FIG>, the first NF node <NUM> initiates transmission of a service request towards the first SCP node <NUM>. The first NF node <NUM> may know via which SCP to route the service request by configuration or other means. The service request can comprise information identifying the selected second NF node <NUM>, such as a hypertext transfer protocol (HTTP) header that identifies the parameters to be used for discovery and selection. As illustrated by blocks <NUM> and <NUM> of <FIG>, the first SCP node <NUM> can store the received parameters.

As illustrated by arrow <NUM> of <FIG>, the first SCP node <NUM> initiates transmission of a discovery request to the NRF <NUM> to obtain NF profile(s) of one or more NF nodes of the service producer for the service that needs to be executed. As illustrated by arrow <NUM> of <FIG>, the first SCP node <NUM> receives a response from the NRF <NUM> comprising the NF profile(s) of one or more NF nodes of the service producer. As illustrated by blocks <NUM> and <NUM> of <FIG>, the first SCP node <NUM> can store the discovered NF profile(s) in the corresponding UE/session context. As illustrated by block <NUM> of <FIG>, the first SCP node <NUM> selects one NF node of the service producer from the one(s) discovered using, for example, functional criteria (e.g. subscription permanent identifier (SUPI), network slice selection assistance information (NSSAI), data network name (DNN), etc.) or non-functional criteria (e.g. load, capacity, etc.). For the purpose of the illustration, it is assumed that the first SCP node <NUM> selects the second NF node <NUM>.

As illustrated by block <NUM> of <FIG>, the first SCP node <NUM> replaces its own address in the host part of the uniform resource identifier (URI) by the one included in service request (the target Application Programming Interface, API, root). As illustrated by block <NUM> of <FIG>, the first SCP node <NUM> may perform any extra functionality, such as monitoring/tracing. As illustrated by arrow <NUM> of <FIG>, the first SCP node <NUM> initiates transmission of the service request towards the selected second NF node <NUM>. As illustrated by arrow <NUM> of <FIG>, the first SCP node <NUM> receives a response comprising the result. The result may comprise some business logic (BL) information, e.g. as a result of the service execution. As illustrated by arrow <NUM> of <FIG>, the first SCP node <NUM> initiates transmission of the response comprising the result towards the first NF node <NUM>. As illustrated by blocks <NUM> and <NUM> of <FIG>, the first NF node <NUM> can store the result.

In <FIG>, steps <NUM>-<NUM> relate to subsequent service requests for an existing UE/Session context. As illustrated by block <NUM> of <FIG> another request (not illustrated) to execute a service is received by the first NF node <NUM> and this service request is identified to correspond to the same UE/session context in respect of which the earlier request was received. As illustrated by block <NUM> of <FIG>, the first NF node <NUM> takes the discovery parameters stored in corresponding UE/session context. As illustrated by block <NUM> of <FIG>, the first NF node <NUM> selects an NF node of the service producer based on discovery parameters from the cached information and repeats steps <NUM> of <FIG> onwards are repeated. If the information is not cached, steps <NUM> of <FIG> onwards are repeated.

In <FIG>, steps <NUM>-<NUM> relate to subsequent service requests for an existing UE/Session context where reselection is required, where steps <NUM>-<NUM> are the same as steps <NUM>-<NUM>, step <NUM> is the same as step <NUM>, and steps <NUM>-<NUM> are the same as steps <NUM>-<NUM>. However, as illustrated by arrow <NUM> of <FIG>, there is a lack of response from the second NF node <NUM>. As illustrated by block <NUM> of <FIG>, the first SCP node <NUM> determines that a reselection is needed based on the error. That is, the first SCP node <NUM> identifies that an alternative NF node of the service producer needs to be selected. As illustrated by block <NUM> of <FIG>, the first SCP node <NUM> selects an alternative NF node of the service producer from the discovered results (e.g. based on parameters, such as set belonging, locality, etc.). For the purpose of the illustration, it is assumed that the first SCP node <NUM> selects the third NF node <NUM>.

As illustrated by arrow <NUM> of <FIG>, the first SCP node <NUM> initiates transmission of the service request towards the selected third NF node <NUM>. As illustrated by arrow <NUM> of <FIG>, there is a lack of response from the third NF node <NUM>. It may be that there are a limited number of NF nodes of the service producer available and/or the first SCP node <NUM> may be restricted to a maximum number of reselection attempts. The first SCP node <NUM> is unable to proceed with the service request. Thus, as illustrated by arrow <NUM> of <FIG>, if no response is received by the first SCP node <NUM>, the first SCP node <NUM> initiates transmission of a response to the first NF node <NUM>. The response comprises information (e.g. an existing HTTP error, such as a <NUM> error) indicative that there is an error situation. Regardless of the error sent back, the first NF node <NUM> delegated reselection to the first SCP node <NUM>. Thus, as illustrated by block <NUM> of <FIG>, the procedure fails.

Thus, even though NF nodes (e.g. the second NF node <NUM> and/or third NF node <NUM>) of the service producer may be available and operational (e.g. up and running), the procedure can still fail, for example, due to an SCP connectivity issue. A redundant SCP deployment will be common in most cases.

<NPL>" discloses deployment scenarios of multiple SCPs.

It is an object of the disclosure to obviate or eliminate at least some of the above-described disadvantages associated with existing techniques.

Thus, an improved technique for handling service requests in a network is provided.

For a better understanding of the technique, and to show how it may be put into effect, reference will now be made, by way of example, to the accompanying drawings, in which:.

Herein, techniques for handling a service request in a network are described. A service request can also be referred to as a request for a service. Generally, a service is software intended to be managed for users. Herein, a service can be any type of service, such as a communication service (e.g. a notification service or a callback service), a context management (e.g. user equipment context management (UECM)) service, a data management (DM) service, or any other type of service. The techniques described herein can be used in respect of any network, such as any communications or telecommunications network, e.g. cellular network. The network may be a fifth generation (<NUM>) network or any other generation network. In some embodiments, the network may be a core network or a radio access network (RAN). The techniques described herein are implemented by a first service communication proxy (SCP) node and a second SCP node.

<FIG> illustrates a first SCP node <NUM> in accordance with an embodiment. The first SCP node <NUM> is for handling a service request in a network. The first SCP node <NUM> is configured to operate as an SCP between a first NF node of a service consumer and a second NF node of a service producer in the network. In some embodiments, the first SCP node <NUM> can be, for example, be a physical machine (e.g. a server) or a virtual machine (VM). In some embodiments, the first NF node can be, for example, be a physical machine (e.g. a server) or a virtual machine (VM). The first NF node can be, for example, a user equipment (UE).

An NF is a third generation partnership project (3GPP) adopted or 3GPP defined processing function in a network, which has defined functional behaviour and 3GPP defined interfaces. An NF can be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualised function instantiated on an appropriate platform, e.g. on a cloud infrastructure. Herein, the term "node" in relation to an "NF node" will be understood to cover each of these scenarios.

As illustrated in <FIG>, the first SCP node <NUM> comprises processing circuitry (or logic) <NUM>. The processing circuitry <NUM> controls the operation of the first SCP node <NUM> and can implement the method described herein in respect of the first SCP node <NUM>. The processing circuitry <NUM> can be configured or programmed to control the first SCP node <NUM> in the manner described herein. The processing circuitry <NUM> can comprise one or more hardware components, such as one or more processors, one or more processing units, one or more multi-core processors and/or one or more modules. In particular implementations, each of the one or more hardware components can be configured to perform, or is for performing, individual or multiple steps of the method described herein in respect of the first SCP node <NUM>. In some embodiments, the processing circuitry <NUM> can be configured to run software to perform the method described herein in respect of the first SCP node <NUM>. The software may be containerised according to some embodiments. Thus, in some embodiments, the processing circuitry <NUM> may be configured to run a container to perform the method described herein in respect of the first SCP node <NUM>.

Briefly, the processing circuitry <NUM> of the first SCP node <NUM> is configured to, if no positive response is received from a second NF node of a service producer to a first request, initiate transmission of the first request towards a third NF node of a service producer via a second SCP node. The first request is transmitted towards the second NF node via the first SCP node <NUM> and is for the second NF node to execute (or provide) a service requested by the first NF node. The first request is transmitted towards the third NF node for the third NF node to execute (or provide) the service. The second SCP node is configured to operate as an SCP between the first NF node and the third NF node in the network. The second SCP node is a different SCP node to the first SCP node.

As illustrated in <FIG>, in some embodiments, the first SCP node <NUM> may optionally comprise a memory <NUM>. The memory <NUM> of the first SCP node <NUM> can comprise a volatile memory or a non-volatile memory. In some embodiments, the memory <NUM> of the first SCP node <NUM> may comprise a non-transitory media. Examples of the memory <NUM> of the first SCP node <NUM> include, but are not limited to, a random access memory (RAM), a read only memory (ROM), a mass storage media such as a hard disk, a removable storage media such as a compact disk (CD) or a digital video disk (DVD), and/or any other memory.

The processing circuitry <NUM> of the first SCP node <NUM> can be connected to the memory <NUM> of the first SCP node <NUM>. In some embodiments, the memory <NUM> of the first SCP node <NUM> may be for storing program code or instructions which, when executed by the processing circuitry <NUM> of the first SCP node <NUM>, cause the first SCP node <NUM> to operate in the manner described herein in respect of the first SCP node <NUM>. For example, in some embodiments, the memory <NUM> of the first SCP node <NUM> may be configured to store program code or instructions that can be executed by the processing circuitry <NUM> of the first SCP node <NUM> to cause the first SCP node <NUM> to operate in accordance with the method described herein in respect of the first SCP node <NUM>. Alternatively or in addition, the memory <NUM> of the first SCP node <NUM> can be configured to store any information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. The processing circuitry <NUM> of the first SCP node <NUM> may be configured to control the memory <NUM> of the first SCP node <NUM> to store information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

In some embodiments, as illustrated in <FIG>, the first SCP node <NUM> may optionally comprise a communications interface <NUM>. The communications interface <NUM> of the first SCP node <NUM> can be connected to the processing circuitry <NUM> of the first SCP node <NUM> and/or the memory <NUM> of first SCP node <NUM>. The communications interface <NUM> of the first SCP node <NUM> may be operable to allow the processing circuitry <NUM> of the first SCP node <NUM> to communicate with the memory <NUM> of the first SCP node <NUM> and/or vice versa. Similarly, the communications interface <NUM> of the first SCP node <NUM> may be operable to allow the processing circuitry <NUM> of the first SCP node <NUM> to communicate with the second SCP node and/or any other node. The communications interface <NUM> of the first SCP node <NUM> can be configured to transmit and/or receive information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. In some embodiments, the processing circuitry <NUM> of the first SCP node <NUM> may be configured to control the communications interface <NUM> of the first SCP node <NUM> to transmit and/or receive information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

Although the first SCP node <NUM> is illustrated in <FIG> as comprising a single memory <NUM>, it will be appreciated that the first SCP node <NUM> may comprise at least one memory (i.e. a single memory or a plurality of memories) <NUM> that operate in the manner described herein. Similarly, although the first SCP node <NUM> is illustrated in <FIG> as comprising a single communications interface <NUM>, it will be appreciated that the first SCP node <NUM> may comprise at least one communications interface (i.e. a single communications interface or a plurality of communications interface) <NUM> that operate in the manner described herein. It will also be appreciated that <FIG> only shows the components required to illustrate an embodiment of the first SCP node <NUM> and, in practical implementations, the first SCP node <NUM> may comprise additional or alternative components to those shown.

<FIG> is a flowchart illustrating a method performed by a first SCP node <NUM> in accordance with an embodiment. The first SCP node <NUM> is configured to operate as an SCP between a first NF node of a service consumer and a second NF node of a service producer in the network. The method of <FIG> is for handling a service request in the network. The first SCP node <NUM> described earlier with referenced to <FIG> is configured to operate in accordance with the method of <FIG>. The method can be performed by or under the control of the processing circuitry <NUM> of the first SCP node <NUM>.

The method of <FIG> is performed if no positive response is received from the second NF node to a first request transmitted towards the second NF node via the first SCP node. The first request is for the second NF node to execute (or provide) a service requested by the first NF node. As illustrated at block <NUM> of <FIG>, transmission of the first request is initiated towards a third NF node of a service producer via a second SCP node for the third NF node to execute (or provide) the service. The second SCP node is configured to operate as an SCP between the first NF node and the third NF node in the network. The second SCP node is a different SCP node to the first SCP node.

Herein, any references to "no positive response" being received can be understood to mean that no response is received at all (i.e. there is a lack of, or absence of, any response) or that an error (e.g. an error code) is received. The fact that no positive response is received can mean that the corresponding request to execute a service is not served, e.g. is not executed or not executed successfully. In this case, there may be a failure between the SCP node that initiated transmission of the request and the NF node of the service producer towards which the request is transmitted. On the other hand, a positive response may be received where the corresponding request to execute a service can be served, e.g. can be executed successfully. In this case, there may be no failure between the SCP node that initiated transmission of the request and the NF node of the service producer towards which the request is transmitted.

Herein, the term "initiate" can mean, for example, cause or establish. Thus, the processing circuitry <NUM> of the first SCP node <NUM> can be configured to itself transmit the first request (e.g. via a communications interface <NUM> of the first SCP node <NUM>) or can be configured to cause another node to transmit the first request. In some embodiments, the first request can be a hypertext transfer protocol (HTTP) request.

<FIG> illustrates a second SCP node <NUM> in accordance with an embodiment. The second SCP node <NUM> is for handling a service request in a network. The second SCP node <NUM> is configured to operate as an SCP between a first NF node of a service consumer and a second NF node of a service producer in the network. In some embodiments, the second SCP node <NUM> can be, for example, be a physical machine (e.g. a server) or a virtual machine (VM).

As illustrated in <FIG>, the second SCP node <NUM> comprises processing circuitry (or logic) <NUM>. The processing circuitry <NUM> controls the operation of the second SCP node <NUM> and can implement the method described herein in respect of the second SCP node <NUM>. The processing circuitry <NUM> can be configured or programmed to control the second SCP node <NUM> in the manner described herein. The processing circuitry <NUM> can comprise one or more hardware components, such as one or more processors, one or more processing units, one or more multi-core processors and/or one or more modules. In particular implementations, each of the one or more hardware components can be configured to perform, or is for performing, individual or multiple steps of the method described herein in respect of the second SCP node <NUM>. In some embodiments, the processing circuitry <NUM> can be configured to run software to perform the method described herein in respect of the second SCP node <NUM>. The software may be containerised according to some embodiments. Thus, in some embodiments, the processing circuitry <NUM> may be configured to run a container to perform the method described herein in respect of the second SCP node <NUM>.

Briefly, the processing circuitry <NUM> of the second SCP node <NUM> is configured to, if no positive response is received from a second NF node of a service producer to a first request, initiate transmission of the first request towards a third NF node of a service producer via a second SCP node. The first request is transmitted towards the second NF node via the second SCP node <NUM> and is for the second NF node to execute (or provide) a service requested by the first NF node. The first request is transmitted towards the third NF node for the third NF node to execute (or provide) the service. The second SCP node is configured to operate as an SCP between the first NF node and the third NF node in the network. The second SCP node is a different SCP node to the first SCP node.

As illustrated in <FIG>, in some embodiments, the second SCP node <NUM> may optionally comprise a memory <NUM>. The memory <NUM> of the second SCP node <NUM> can comprise a volatile memory or a non-volatile memory. In some embodiments, the memory <NUM> of the second SCP node <NUM> may comprise a non-transitory media. Examples of the memory <NUM> of the second SCP node <NUM> include, but are not limited to, a random access memory (RAM), a read only memory (ROM), a mass storage media such as a hard disk, a removable storage media such as a compact disk (CD) or a digital video disk (DVD), and/or any other memory.

The processing circuitry <NUM> of the second SCP node <NUM> can be connected to the memory <NUM> of the second SCP node <NUM>. In some embodiments, the memory <NUM> of the second SCP node <NUM> may be for storing program code or instructions which, when executed by the processing circuitry <NUM> of the second SCP node <NUM>, cause the second SCP node <NUM> to operate in the manner described herein in respect of the second SCP node <NUM>. For example, in some embodiments, the memory <NUM> of the second SCP node <NUM> may be configured to store program code or instructions that can be executed by the processing circuitry <NUM> of the second SCP node <NUM> to cause the second SCP node <NUM> to operate in accordance with the method described herein in respect of the second SCP node <NUM>. Alternatively or in addition, the memory <NUM> of the second SCP node <NUM> can be configured to store any information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. The processing circuitry <NUM> of the second SCP node <NUM> may be configured to control the memory <NUM> of the second SCP node <NUM> to store information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

In some embodiments, as illustrated in <FIG>, the second SCP node <NUM> may optionally comprise a communications interface <NUM>. The communications interface <NUM> of the second SCP node <NUM> can be connected to the processing circuitry <NUM> of the second SCP node <NUM> and/or the memory <NUM> of second SCP node <NUM>. The communications interface <NUM> of the second SCP node <NUM> may be operable to allow the processing circuitry <NUM> of the second SCP node <NUM> to communicate with the memory <NUM> of the second SCP node <NUM> and/or vice versa. Similarly, the communications interface <NUM> of the second SCP node <NUM> may be operable to allow the processing circuitry <NUM> of the second SCP node <NUM> to communicate with the first SCP node <NUM> and/or any other node. The communications interface <NUM> of the second SCP node <NUM> can be configured to transmit and/or receive information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. In some embodiments, the processing circuitry <NUM> of the second SCP node <NUM> may be configured to control the communications interface <NUM> of the second SCP node <NUM> to transmit and/or receive information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

Although the second SCP node <NUM> is illustrated in <FIG> as comprising a single memory <NUM>, it will be appreciated that the second SCP node <NUM> may comprise at least one memory (i.e. a single memory or a plurality of memories) <NUM> that operate in the manner described herein. Similarly, although the second SCP node <NUM> is illustrated in <FIG> as comprising a single communications interface <NUM>, it will be appreciated that the second SCP node <NUM> may comprise at least one communications interface (i.e. a single communications interface or a plurality of communications interface) <NUM> that operate in the manner described herein. It will also be appreciated that <FIG> only shows the components required to illustrate an embodiment of the second SCP node <NUM> and, in practical implementations, the second SCP node <NUM> may comprise additional or alternative components to those shown.

<FIG> is a flowchart illustrating a method performed by a second SCP node <NUM> in accordance with an embodiment. The second SCP node <NUM> is configured to operate as an SCP between a first NF node of a service consumer and a third NF node of a service producer in the network. The method of <FIG> is for handling a service request in the network. The second SCP node <NUM> described earlier with referenced to <FIG> is configured to operate in accordance with the method of <FIG>. The method can be performed by or under the control of the processing circuitry <NUM> of the second SCP node <NUM>.

The method of <FIG> is performed in response to receiving a first request for the third NF node to execute (or provide) a service requested by the first NF node. The transmission of the first request is initiated from a first SCP node <NUM> that is configured to operate as an SCP between the first NF node and a second NF node. As illustrated at block <NUM> of <FIG>, transmission of the first request is initiated towards the third NF node for the third NF node to execute (or provide) the service. The second SCP node <NUM> is a different SCP node to the first SCP node <NUM>.

There is also provided a system. The system can comprise at least one first SCP node <NUM> as described herein and/or at least one second SCP node <NUM> as described herein. The system may also comprise any one or more of the other nodes mentioned herein.

<FIG> is a signalling diagram illustrating an exchange of signals in a system according to an embodiment. The system illustrated in <FIG> comprises a first SCP node <NUM> and a second SCP node <NUM>. In the system illustrated in <FIG>, the second SCP node <NUM> is an SCP node that is in the same SCP domain <NUM> as the first SCP node <NUM>. The second SCP node <NUM> is a different SCP node to the first SCP node <NUM>. The first SCP node <NUM> can be as described earlier with reference to <FIG>. The second SCP node <NUM> can be as described earlier with reference to <FIG>.

The system illustrated in <FIG> comprises a first NF node <NUM> of a service consumer ("NFc"), a second NF node <NUM> of a service producer ("NFp1"), and a third NF node <NUM> of a service producer ("NFp2"). The first SCP node <NUM> is configured to operate as an SCP between the first NF node <NUM> and the second NF node <NUM>. The second SCP node <NUM> is configured to operate as an SCP between the first NF node <NUM> and a third NF node <NUM>, <NUM> of a service producer, which may be the second NF node <NUM> or another NF node <NUM> of a service producer. The second NF node <NUM> and this third NF node <NUM> may thus be the same NF node, or the second NF node <NUM> and this third NF node <NUM> may be different NF nodes.

The second NF node <NUM> can be configured to run (or provide) a service <NUM>. The third NF node <NUM> can be configured to run (or provide) a service <NUM>. The second NF node <NUM> and the third NF node <NUM> can be configured to run (or provide) the same service or a different service. The second NF node <NUM> and the third NF node <NUM> can be part of a set (or group) <NUM> of NF nodes of a service producer. The system illustrated in <FIG> comprises a network repository function <NUM>. In some embodiments, an entity may comprise the NRF <NUM> and one or both of the first SCP node <NUM> and the second SCP node <NUM>. That is, in some embodiments, the first SCP node <NUM> and/or the second SCP node <NUM> can be merged with the NRF <NUM> in a combined entity.

In some embodiments, the first SCP node <NUM> and the first NF node <NUM> may be deployed in independent deployment units, the first SCP node <NUM> and the second NF node <NUM> may be deployed in independent deployment units, and/or the first SCP node <NUM> and the third NF node may be deployed in independent deployment units. Thus, a first SCP node <NUM> based on independent deployment units is possible, as described in 3GPP TS <NUM> V16. In other embodiments, the first SCP node <NUM> may be deployed as a distributed network element. For example, in some embodiments, part (e.g. a service agent) of the first SCP node <NUM> may be deployed in the same deployment unit as the first NF node <NUM>, part (e.g. a service agent) of the first SCP node <NUM> may be deployed in the same deployment unit as the second NF node <NUM>, and/or part of the first SCP node <NUM> may be deployed in the same deployment unit as the third NF node. Thus, a first SCP node <NUM> based on service mesh is possible, as described in 3GPP TS <NUM> V16.

In some embodiments, the second SCP node <NUM> and the first NF node <NUM> may be deployed in independent deployment units, the second SCP node <NUM> and the second NF node <NUM> may be deployed in independent deployment units, and/or the second SCP node <NUM> and the third NF node may be deployed in independent deployment units. Thus, a second SCP node <NUM> based on independent deployment units is possible, as described in 3GPP TS <NUM> V16. In other embodiments, the second SCP node <NUM> may be deployed as a distributed network element. For example, in some embodiments, part (e.g. a service agent) of the second SCP node <NUM> may be deployed in the same deployment unit as the first NF node <NUM>, part (e.g. a service agent) of the second SCP node <NUM> may be deployed in the same deployment unit as the second NF node <NUM>, and/or part of the second SCP node <NUM> may be deployed in the same deployment unit as the third NF node. Thus, a second SCP node <NUM> based on service mesh is possible, as described in 3GPP TS <NUM> V16.

In some embodiments, at least one third SCP node may be configured to operate as an SCP between the first SCP node <NUM> and the second NF node <NUM> and/or at least one fourth SCP node may be configured to operate as an SCP between the first NF node <NUM> and the first SCP node <NUM>. The at least one third SCP node is a different SCP node to the second SCP node <NUM>. The at least one fourth SCP node is a different SCP node to the second SCP node <NUM>. Thus, a multipath of SCP nodes is possible. In some of these embodiments, the at least one third SCP node and/or the at least one fourth SCP node may be deployed in independent deployment units. In some embodiments, the at least one third SCP node and/or the at least one fourth SCP node may be deployed as distributed network elements.

Steps <NUM>-<NUM> and <NUM>-<NUM> of are as described earlier with reference to <FIG>. As illustrated by arrow <NUM> of <FIG>, if no positive response is received from the second NF node <NUM> to the first request transmitted towards the second NF node <NUM> via the first SCP node <NUM>, based on this lack of positive response (e.g. no response at all or an error response), the first SCP node <NUM> can identify that reselection of an SCP node is required. That is, the first SCP node <NUM> can identify that the first request is to be transmitted via a different SCP node. In some embodiments, the method may be performed if no positive response is received from the second NF node <NUM> to a first request transmitted towards at least two second NF nodes <NUM>) via the first SCP node <NUM>. Thus, the first SCP node <NUM> may identify that reselection of an SCP node is required after a lack of positive response (e.g. no response at all or an error response) from one or a plurality of NF nodes of a service provider.

As illustrated by block <NUM>, the first SCP node <NUM> selects an alternative SCP node. That is, the first SCP node <NUM> is able to select an alternative SCP node instead of continually trying to reach another NF node of the service producer via the same first SCP node <NUM>, which may cause a request failure or even multiple requests failures, depending on the available NF nodes of the service producer. Having the ability to select an alternative SCP node prevents the first SCP node <NUM> from continually selecting (in a loop) NF nodes of the service producer all with same wrong results and also prevents the first SCP node <NUM> from having to abort the procedure. Thus, providing the first SCP node <NUM> with the ability to select an alternative SCP node provides advantageous results in that service requests are more likely to be executed successfully.

For the purpose of this illustration, the first SCP node <NUM> is assumed to select the second SCP node <NUM> as the alternative. As illustrated in <FIG>, the second SCP node <NUM> is an SCP node that is in the same SCP domain <NUM> as the first SCP node <NUM>. This means that the second SCP node <NUM> is able to reach (or capable of reaching) the same NF nodes (e.g. the second NF node <NUM>) as the first SCP node <NUM>. Generally, an SCP domain is a group of one or more SCPs that can reach certain NF nodes (or NF node instances) or SCPs directly, i.e. without passing through an intermediate SCP.

As illustrated by arrow <NUM> of <FIG>, the first SCP node <NUM> initiates transmission of the first request towards a third NF node of a service producer via the second SCP node <NUM> for the third NF node to execute (or provide) the service <NUM>. Thus, if no positive response is received from the second NF node <NUM> to a first request transmitted towards the second NF node <NUM> via the first SCP node <NUM>, the first SCP node <NUM> initiated transmission of this first request towards the third NF node via the second SCP node <NUM>. That is, the first request is forwarded via the second SCP node <NUM>. The second NF node <NUM> and the third NF node may be the same NF node (i.e. the third NF node may be the same as the last NF node), or the second NF node <NUM> and the third NF node may be different NF nodes. In some embodiments, the third NF node may be a preferred NF node. For the purpose of the illustration, it is assumed that the second NF node <NUM> and the third NF node are the same NF node. That is, the first SCP node <NUM> initiates transmission of the first request towards the same second NF node <NUM> via the second SCP node <NUM>.

In some embodiments, initiating transmission of the first request towards the third NF node via the second SCP node <NUM> may comprise initiating transmission of the first request towards the third NF node via the second SCP node <NUM> with information identifying the third NF node. In this way, the second SCP node <NUM> is able to identify the final destination for the first request in order to send it there. In some embodiments, the information identifying the third NF node can be included in a header of the first request, e.g. an existing header 3gpp-sbi-target-apiroot may be used. The first SCP node <NUM> may use the address of the second SCP node <NUM> in an Application Programming Interface (API) root of the first request.

In some embodiments, the first SCP node <NUM> may initiate transmission of the first request towards the third NF node (which in this illustration is the same second NF node <NUM>) via the second SCP node <NUM> (e.g. only) if no positive response is received from the second NF node <NUM> to the first request due to the first SCP node <NUM> failing to connect to the second NF node <NUM>. Although not illustrated in <FIG>, in some embodiments, the first SCP node <NUM> may check whether the first SCP node <NUM> failed to connect to the second NF node <NUM>. The first SCP node <NUM> failing to connect to the second NF node <NUM> can be the first SCP node <NUM> itself failing to connect to the second NF node <NUM> or at least one third SCP node failing to connect to the second NF node <NUM>, where the at least one third SCP node is configured to operate as an SCP between the first SCP node <NUM> and the second NF node <NUM>.

In some embodiments, checking whether the at least one third SCP node failed to connect to the second NF node <NUM> may comprise checking a status of the at least one third SCP node to identify whether the at least one third SCP node failed to connect to the second NF node <NUM>. For example, the status may be checked with the at least one third SCP node or the NRF <NUM>. In some embodiments, checking the status with the at least one third SCP node may comprise initiating transmission of a second request towards the third SCP node, where the second request is a request for the status of the third SCP node. In these embodiments, if no positive response to the second request is received from the third SCP node, the third SCP node failed to connect to the second NF node <NUM>. On the other hand, if a positive response to the second request is received from the third SCP node, the third SCP node succeeded to connect to the second NF node <NUM>. The second request may, for example, be a HTTP request, such as a HTTP ping request or a HTTP head request.

Alternatively or in addition, in some embodiments, the first SCP node <NUM> may initiate transmission of the first request towards the third NF node (which in this illustration is the same second NF node <NUM>) via the second SCP node <NUM> (e.g. only) if the second NF node <NUM> is operative. Although not illustrated in <FIG>, in some embodiments, the first SCP node <NUM> may check whether the second NF node <NUM> is operative. In some embodiments, checking whether the second NF node <NUM> is operative may comprise checking a status of the second NF node <NUM> to identify whether the second NF node <NUM> is operative. For example, the status may be checked with the second NF node <NUM> or the NRF <NUM>.

In some embodiments, checking the status with the second NF node <NUM> may comprise initiating transmission of a third request towards the second NF node <NUM>, where the third request is a request for the status of the second NF node <NUM>. In these embodiments, if a positive response to the third request is received from the second NF node <NUM>, the second NF node <NUM> is operative. On the other hand, if no positive response to the third request is received from the second NF node <NUM>, the second NF node <NUM> is inoperative. The third request may, for example, be a HTTP, request, such as a HTTP ping request or a HTTP head request.

The second SCP node <NUM> receives the first request for the third NF node (which in this illustration is the same second NF node <NUM>) to execute (or provide) a service <NUM> requested by the first NF node <NUM>. That is, the second SCP node <NUM> receives the first request forwarded from the first SCP node <NUM>. Returning back to <FIG>, as illustrated by arrow <NUM>, in response to receiving the first request for the third NF node (which in this illustration is the same second NF node <NUM>) to execute (or provide) a service <NUM> requested by the first NF node <NUM>, the second SCP node <NUM> initiates transmission of the first request towards the third NF node (which in this illustration is the same second NF node <NUM>) for the third NF node to execute (or provide) the service <NUM>. As illustrated by arrow <NUM> of <FIG>, some embodiments, the third NF node (which in this illustration is the same second NF node <NUM>) may initiate transmission of a response towards the second SCP node <NUM> indicative that the first request is executed successfully. The response may comprise some business logic (BL) information, e.g. as a result of the service execution.

As illustrated by arrow <NUM> of <FIG>, in some embodiments, the second SCP node <NUM> may initiate transmission of the response indicative that the first request is executed successfully to the first SCP node <NUM>. Thus, in some embodiments, the first SCP node <NUM> can receive a response to the first request from the third NF node (which in this illustration is the same second NF node <NUM>) via the second SCP node <NUM>. The first request may be executed successfully, for example, where the first SCP node <NUM> suffers a connectivity issue (e.g. outside the SCP domain) that the second SCP node <NUM> does not.

As illustrated by arrow <NUM> of <FIG>, in some embodiments, the first SCP node <NUM> may initiate transmission of the response indicative that the first request is executed successfully to the first NF node <NUM>. In some embodiments, the response may comprise information indicative that the first SCP node <NUM> initiated transmission of the first request towards the third NF node via another SCP node (e.g. an indication of the forwarding performed), or information indicative that the first SCP node <NUM> initiated transmission of the first request towards the third NF node via the second SCP node <NUM> (e.g. an indication that the destination is reached due to a redirection via the second SCP node <NUM>). As illustrated by blocks <NUM> and <NUM> of <FIG>, in some embodiments, the first NF node <NUM> may store the response. As illustrated by block <NUM> of <FIG>, in some embodiments, the first NF node <NUM> may mark the second SCP node <NUM> as the preferred SCP node for subsequent service requests. In other embodiments, another SCP node may be chosen as the preferred SCP node for subsequent service requests, such as another SCP node in the same domain.

Although not illustrated in <FIG>, in some embodiments, the first SCP node <NUM> may initiate transmission of one or more subsequent first requests for the execution of a service <NUM>, where the transmission of the one or more subsequent first requests is initiated towards the third NF node via the second SCP node <NUM> or via a fifth SCP node for the third NF node to execute (or provide) the service <NUM>. The fifth SCP node is a different SCP node to the second SCP node <NUM>. In some embodiments, the fifth SCP node may be in the same SCP domain as the second SCP node <NUM>.

In some embodiments, the transmission of the one or more subsequent first requests may be initiated towards the third NF node via the second SCP node <NUM> if the second SCP node <NUM> is marked at the first NF node <NUM> as a preferred SCP node for subsequent first requests or as having a highest priority for subsequent first requests. Alternatively, the transmission of the one or more subsequent first requests may be initiated towards the third NF node via the fifth SCP node if the fifth SCP node is marked at the first NF node <NUM> as a preferred SCP node for subsequent first requests or as having a highest priority for subsequent first requests.

Thus, in some embodiments, the second SCP node <NUM> may receive one or more subsequent first requests for the execution of a service <NUM>. In some embodiments, the second SCP node <NUM> may initiate transmission of the one or more subsequent first requests towards the third NF node for the third NF node to execute (or provide) the service <NUM>. In some embodiments, the first SCP node <NUM> may avoid initiating transmission of the one or more subsequent first requests towards the third NF node via the first SCP node <NUM> if the first SCP node is marked at the first NF node <NUM> as not preferred for subsequent first requests or as not having a highest priority for subsequent first requests. The first SCP node <NUM> may be only temporarily marked at the first NF node <NUM> as not preferred for subsequent first requests or as not having a highest priority for subsequent first requests.

<FIG> is a block diagram illustrating a first SCP node <NUM> in accordance with an embodiment. The first SCP node <NUM> can handle a service request in a network. The first SCP node <NUM> can operate as an SCP between a first NF node of a service consumer and a second NF node of a service producer in the network. The first SCP node <NUM> comprises a transmission initiating module <NUM> configured to, if no positive response is received from the second NF node to a first request transmitted towards the second NF node via the first SCP node <NUM> (where the first request is for the second NF node to execute a service requested by the first NF node), initiate transmission of the first request towards a third NF node of a service producer via a second SCP node for the third NF node to execute the service. The second SCP node can operate as an SCP between the first NF node and the third NF node in the network. The second SCP node is a different SCP node to the first SCP node8700. The first SCP node <NUM> may operate in the manner described herein in respect of the first SCP node.

<FIG> is a block diagram illustrating a second SCP node <NUM> in accordance with an embodiment. The second SCP node <NUM> can handle a service request in a network. The second SCP node <NUM> can operate as an SCP between a first NF node of a service consumer and a third NF node of a service producer in the network. The second SCP node <NUM> comprises a first transmission initiating module <NUM> configured to, in response to receiving a first request for the third NF node to execute a service requested by the first NF node (where transmission of the first request is initiated from a first SCP node <NUM> that is configured to operate as an SCP between the first NF node and a second NF node), initiate transmission of the first request towards the third NF node for the third NF node to execute the service. The second SCP node <NUM> is a different SCP node to the first SCP node <NUM>. The second SCP node <NUM> may operate in the manner described herein in respect of the second SCP node.

There is also provided a computer program comprising instructions which, when executed by processing circuitry (such as the processing circuitry <NUM> of the first SCP node <NUM> described earlier and/or the processing circuitry <NUM> of the second SCP node <NUM> described earlier), cause the processing circuitry to perform at least part of the method described herein. There is provided a computer program product, embodied on a non-transitory machine-readable medium, comprising instructions which are executable by processing circuitry (such as the processing circuitry <NUM> of the first SCP node <NUM> described earlier and/or the processing circuitry <NUM> of the second SCP node <NUM> described earlier) to cause the processing circuitry to perform at least part of the method described herein. There is provided a computer program product comprising a carrier containing instructions for causing processing circuitry (such as the processing circuitry <NUM> of the first SCP node <NUM> described earlier and/or the processing circuitry <NUM> of the second SCP node <NUM> described earlier) to perform at least part of the method described herein. In some embodiments, the carrier can be any one of an electronic signal, an optical signal, an electromagnetic signal, an electrical signal, a radio signal, a microwave signal, or a computer-readable storage medium.

In some embodiments, the first SCP node functionality and/or the second SCP node functionality described herein can be performed by hardware. Thus, in some embodiments, any one or more of the first SCP node <NUM> and the second SCP node <NUM> described herein can be a hardware node. However, it will also be understood that optionally at least part or all of the first SCP node functionality and/or the second SCP node functionality described herein can be virtualized. For example, the functions performed by any one or more of the first SCP node <NUM> and the second SCP node <NUM> described herein can be implemented in software running on generic hardware that is configured to orchestrate the node functionality. Thus, in some embodiments, any one or more of the first SCP node <NUM> and the second SCP node <NUM> described herein can be a virtual node. In some embodiments, at least part or all of the first SCP node functionality and/or the second SCP node functionality described herein may be performed in a network enabled cloud. The first SCP node functionality and/or the second SCP node functionality described herein may all be at the same location or at least some of the node functionality may be distributed.

It will be understood that at least some or all of the method steps described herein can be automated in some embodiments. That is, in some embodiments, at least some or all of the method steps described herein can be performed automatically. The method described herein can be a computer-implemented method.

Thus, in the manner described herein, there is advantageously provided an improved technique for handling service requests in a network. A first SCP node <NUM> having a connectivity issue (e.g. outside its SCP domain) can forward a service request to a second SCP node (e.g. in the same SCP domain) to overcome the connectivity issue. The first NF node <NUM> of the service consumer that made the request may be updated of the need to reselect an alternative SCP node. The forwarding of the service request to another SCP node for it to be transmitted again but this time by a different SCP node avoids the need for the original SCP node to unsuccessfully keep trying to transmit the service request and also avoids the method simply failing.

Claim 1:
A method for handling a service request in a network, wherein the method is performed by a first service communication proxy, SCP, node (<NUM>) that is configured to operate as an SCP between a first network function, NF, node (<NUM>) of a service consumer and a second NF node (<NUM>) of a service producer in the network, the method comprising:
initiating (<NUM>, <NUM>, <NUM>) transmission of a first request towards a third NF node of a service producer via a second SCP node (<NUM>) if no positive response is received from the second NF node (<NUM>) to the first request (<NUM>, <NUM>) transmitted towards the second NF node (<NUM>) via the first SCP node (<NUM>),
wherein the first request (<NUM>, <NUM>) is transmitted towards the second NF node (<NUM>) for the second NF node (<NUM>) to execute a service (<NUM>) requested by the first NF node (<NUM>) and transmission of the first request is initiated towards the third NF node for the third NF node to execute the service (<NUM>), wherein the second SCP node (<NUM>) is configured to operate as an SCP between the first NF node (<NUM>) and the third NF node in the network, and wherein the second SCP node (<NUM>) is a different SCP node to the first SCP node (<NUM>).