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 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 NF node <NUM> can provide (e.g. be configured to execute or run) a service <NUM> and the third NF node <NUM> can provide (e.g. be configured to execute or run) a service <NUM>. The second NF node <NUM> and the third NF node <NUM> can provide (e.g. be configured to execute or 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 node <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. As illustrated by block <NUM> of <FIG>, the first NF node <NUM> determines what discovery (and selection) parameters to use. More specifically, the first NF node <NUM> identifies the discovery parameters to include in the request. The discovery parameters are those that allow the first SCP node <NUM> to select the required NF node of the service producer. The discovery parameters can be associated with a certain service in a received request, which is not illustrated in <FIG>. As illustrated by block <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>. Herein, this service request may be referred to as the "first request" <NUM>. The service request is for an NF node to provide a first service <NUM> requested by the first NF node <NUM>. The first NF node <NUM> may know via which SCP node to route the service request by configuration or other means. The first request comprises the address of this SCP node. In this illustration, this SCP node is the first SCP node <NUM>. The discovery parameters are included in the service request. For example, the service request can comprise a hypertext transfer protocol (HTTP) header that identifies the parameters to be used for discovery and selection.

As illustrated by arrow <NUM> of <FIG>, the first SCP node <NUM> initiates transmission of a discovery request to the NRF node <NUM> to obtain NF profile(s) of one or more NF nodes of the service producer for the service that needs to be executed. The discovery request comprises the received discovery parameters. As illustrated by arrow <NUM> of <FIG>, the first SCP node <NUM> receives a response from the NRF node <NUM> comprising the NF profile(s) of one or more NF nodes of the service producer. 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.) and/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 (namely, the scp-address) in the received service request with the address of the selected second NF node <NUM>. As illustrated by block <NUM> of <FIG>, the first SCP node <NUM> may perform any extra functionality, such as monitoring and/or 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>. Here, the service request is for the second NF node <NUM> to provide the first service <NUM> requested by the first NF node <NUM>.

As illustrated by arrow <NUM> of <FIG>, the first SCP node <NUM> receives a response. Herein, this response may be referred to as the "first response" <NUM>. The response <NUM> can comprise the result (e.g. that the service request is successful), some business logic (BL) information (e.g. as a result of providing the service), and/or location information. The location information is information indicative of a location of the resource in the second NF node <NUM> used when providing the first service <NUM>. As illustrated by arrow <NUM> of <FIG>, the first SCP node <NUM> initiates transmission of the response towards the first NF node <NUM>. As illustrated by blocks <NUM> and <NUM> of <FIG>, the first NF node <NUM> can store the information comprised in the response, e.g. the result, the BL information, and/or the location information. The information comprised in the response can be stored with the UE/session context.

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. The first NF node <NUM> can, for example, determine the corresponding UE/session context based on the BL information. As illustrated by block <NUM> of <FIG>, the first NF node <NUM> extracts, from the location information, an address of the second NF node <NUM>, which may be an application programming interface (API) root of a uniform resource identifier (URI) used to reach of the second NF node <NUM> (i.e. the sbi-target-apiroot).

As illustrated by arrow <NUM> of <FIG>, the first NF node <NUM> initiates transmission of a subsequent service request towards the first SCP node <NUM>. Herein, this subsequent service request may be referred to as the "subsequent second request". The subsequent service request is for an NF node to provide a second service <NUM>, <NUM> requested by the first NF node <NUM>, which may be the same or a different service to the first service <NUM>. The first NF node <NUM> may know via which SCP (e.g. in this illustration, the first SCP node <NUM>) to route the service request by configuration or other means. The subsequent service request can comprise the address of the second NF node <NUM> (e.g. the sbi-target-apiroot). A hypertext transfer protocol (HTTP) header can comprise this address. As illustrated by block <NUM> of <FIG>, the first SCP node <NUM> replaces its own address (namely, the scp-address) in the received subsequent service request with the address of the second NF node <NUM> (e.g. the sbi-target-apiroot). As illustrated by block <NUM> of <FIG>, the first SCP node <NUM> may perform any extra functionality, such as monitoring and/or tracing.

As illustrated by arrow <NUM> of <FIG>, the first SCP node <NUM> initiates transmission of the subsequent service request towards the second NF node <NUM>. Here, the service request is for the second NF node <NUM> to provide the second service <NUM>, <NUM> requested by the first NF node <NUM>. As illustrated by arrow <NUM> of <FIG>, there is an error response or a lack of response from the second NF node <NUM>. As illustrated by block <NUM> of <FIG>, the first SCP node <NUM> identifies that a reselection of NF node is required, e.g. based on the error. However, as illustrated by block <NUM> of <FIG>, the first SCP node <NUM> has no means to select an alternative NF node. In particular, the first SCP node <NUM> does not have any information to be able to find an alternative NF node to be able to fulfil the subsequent service request. As illustrated by arrow <NUM> of <FIG>, 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. As illustrated by block <NUM> of <FIG>, the procedure fails.

Moreover, as binding is not supported by the second NF node <NUM> (even though it may be supported by the first NF node <NUM> and the first SCP node <NUM>), the first SCP node <NUM> is required to cache UE/session data. As the first SCP node <NUM> is the intermediary in all the communications, this uses up storage resources unnecessarily. <NPL>, is a standard document disclosing the provision, by an SCP node, of binding information to a consumer NF irrespective of whether the binding information is present in a first response received from an NF producer, hence enabling deployments where not all NF Service Producers have been upgraded to support the binding procedures.

It is an object of the disclosure to obviate or eliminate at least some of the above-described disadvantages associated with existing techniques. Objects of the invention are a method, a node, a computer program and a computer program product as in the appended independent claims. Preferred embodiments are covered by the appended dependent claims.

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 first network function (NF) node.

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.

<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 network function (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).

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 operate in response to receiving, from the second NF node, a first response 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 provide (e.g. execute or run) a first service requested by the first NF node. The processing circuitry <NUM> of the first SCP node <NUM> is configured to initiate transmission of a second response towards the first NF node. The second response comprises binding information irrespective of whether the binding information is present in the first response. The binding information is indicative of one or more parameters by which the first NF node is bound when selecting a second service in an NF node of a service producer for a subsequent second request.

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 first NF 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 is for handling a service request in the network. The first SCP node <NUM> described earlier with reference 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 in response to receiving, from the second NF node, a first response 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 provide (e.g. execute or run) a first service requested by the first NF node. As illustrated at block <NUM> of <FIG>, transmission of a second response is initiated towards the first NF node. The second response comprises binding information irrespective of whether the binding information is present in the first response. The binding information is indicative of one or more parameters by which the first NF node is bound when selecting a second service in an NF node of a service producer for a subsequent second request.

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 second response (e.g. via a communications interface <NUM> of the first SCP node <NUM>) or can be configured to cause another node to transmit the second response.

<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>. The first 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 first SCP node <NUM> is also configured to operate as an SCP between the first NF node <NUM> and the third NF node <NUM>. The second NF node <NUM> can be configured to run a service <NUM>. The third NF node <NUM> can provide (e.g. can be configured to execute or run) a service <NUM>. The second NF node <NUM> and the third NF node <NUM> can provide (e.g. can be configured to execute or run) the same service (e.g. different instances of 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> comprises a network repository function (NRF) node <NUM>. In some embodiments, an entity may comprise the first SCP node <NUM> and the NRF node <NUM>. That is, in some embodiments, the first SCP node <NUM> can be merged with the NRF node <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 <NUM> may be deployed in independent deployment units. Thus, an SCP node 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 (e.g. a service agent) of the first SCP node <NUM> may be deployed in the same deployment unit as the third NF node <NUM>. Thus, an SCP node based on service mesh is possible, as described in 3GPP TS <NUM> V16.

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

Steps <NUM>-<NUM> and <NUM>-<NUM> of <FIG> are as described earlier with reference to <FIG>. As illustrated by block <NUM> of <FIG>, in some embodiments, the first SCP node <NUM> may check whether the first NF node <NUM> supports being bound by the one or more parameters. That is, the first SCP node <NUM> checks whether the first NF node <NUM> supports binding.

In some embodiments, the first SCP node <NUM> may check an NF profile of the first NF node <NUM> to check whether the first NF node <NUM> supports being bound by the one or more parameters. The NF profile of the first NF node <NUM> may be stored in a memory <NUM> of the first SCP node <NUM> (e.g. it may be a cached result from previous discovery) and/or stored at the NRF node <NUM>. Where the NF profile of the first NF node <NUM> is stored at the NRF node <NUM>, the first SCP node <NUM> may use discovery to check the NF profile. For example, the first SCP node <NUM> may initiate transmission of a request towards the NRF node <NUM> to check the NF profile of the first NF node <NUM>. The first SCP node <NUM> may use an identifier that (e.g. uniquely) identifies the first NF node <NUM> for this purpose, such as an NF instance Id. The identifier that identifies the first NF node <NUM> may be included in the first request <NUM>. Thus, the first SCP node <NUM> may acquire the identifier that identifies the first NF node <NUM> from the first request <NUM>. In this way, the first SCP node <NUM> is able to find the NF profile of the first NF node <NUM>. In some embodiments, the first SCP node <NUM> may receive the NF profile from the NRF node <NUM>. In some embodiments, the first SCP node <NUM> check whether the first NF node <NUM> supports binding by checking the supported features in the NF profile.

In some embodiments, the first SCP node <NUM> may check whether the first NF node <NUM> supports being bound by the one or more parameters only if the binding information is absent from (i.e. not included in) the first response <NUM> from the second NF node <NUM>. If the first response <NUM> from the second NF node <NUM> does not include binding information, it may mean that the second NF node <NUM> does not support binding or that the second NF node <NUM> has decided not to include binding information.

As illustrated by block <NUM> of <FIG>, the first SCP node <NUM> includes binding information in a second response <NUM> to the first request <NUM>, which is to be transmitted to the first NF node <NUM>. Thus, the second response <NUM> referred to herein comprises binding information. In effect, the first SCP node <NUM> can insert its own binding information, as if it received it from the second NF node <NUM>. This is possible since the first SCP node <NUM> has all the binding information to be included, e.g. an identifier that (e.g. uniquely) identifies the second NF node <NUM> (or the selected instance of the second NF node <NUM>, e.g. NFp instance Id), an identifier that (e.g. uniquely) identifies the set <NUM> of NF nodes that comprises the second NF node <NUM> (e.g. NFp Set X Id), and a name of the first service <NUM> (e.g. Service A). The identifier that identifies the set <NUM> of NF nodes that comprises the second NF node <NUM> can be acquired from the NF profile of the second NF node <NUM>. The name of the first service <NUM> may be included in the discovery parameters received in the first request <NUM>.

In some embodiments, the first SCP node <NUM> may acquire the binding information from a memory <NUM> of the first SCP node <NUM> and/or from the NRF node <NUM>. In some embodiments, the first SCP node <NUM> may initiate transmission of a third request towards the NRF node <NUM> for the binding information. The binding information stored in the memory <NUM> of the first SCP node <NUM> may be local binding information (e.g. the same binding information stored in the NRF node <NUM> may also be stored at the first SCP node <NUM>), or cached binding information from previous interactions with the NRF node <NUM>.

The first SCP node <NUM> includes the binding information in the second response <NUM> irrespective of whether the binding information is present in the first response <NUM>. Thus, the second response <NUM> comprises binding information irrespective of whether the binding information is present in the first response <NUM>. In some embodiments, the first SCP node <NUM> may check whether the binding information is present in or absent from the first response <NUM>. If binding information is present in the first response <NUM>, the second response <NUM> is the same as the first response <NUM>, or the second response <NUM> may be the first response <NUM> updated to comprise modified binding information. For example, it may be the case that the second NF node <NUM> is programmed to send binding information that does not specify an alternative NF node of the service producer to be used when a subsequent second transmitted to the second NF node <NUM> is unsuccessful. This may be the case, for example, where only the second NF node <NUM> is deployed at the time the second NF node <NUM> sent the binding information. However, the third NF node <NUM> may be added later, e.g. to the set <NUM> of NF nodes. Then, even though the second NF node <NUM> did not send binding information relating to the third NF node <NUM>, the first SCP node <NUM> can modify the binding information to comprise binding information relating to the third NF node <NUM>. In this way, if an NF node reselection is required in the future, the first SCP node <NUM> has the information available to select an alternative.

On the other hand, if the binding information is absent from the first response <NUM>, the second response <NUM> is the first response <NUM> updated to comprise the binding information. In some embodiments, the first SCP node <NUM> may include binding information in the second response <NUM> only if the first NF node <NUM> supports binding. Thus, in some embodiments, the second response <NUM> may comprise the binding information only if the first NF node <NUM> supports being bound by the one or more parameters. In some embodiments, when the second NF node <NUM> does not support binding but the first NF node <NUM> does support binding, the first SCP node <NUM> may include the binding information in the second response <NUM>, since the second NF node <NUM> does not.

Herein, binding information is any information that is indicative of one or more parameters by which the first NF node <NUM> is bound when selecting a second service <NUM>, <NUM> in an NF node <NUM>, <NUM> of a service producer for a subsequent second request <NUM>, <NUM>. The subsequent second request <NUM>, <NUM> can be a subsequent second request that follows the first request <NUM>, <NUM> directly, or a subsequent second request that follows the first request <NUM>, <NUM> indirectly, e.g. it may be a request that follows another one or more requests that follow the first request <NUM>, <NUM>. In some embodiments, the subsequent second request may be linked to the first service <NUM>. For example, the subsequent second request may be associated with a resource used to provide the first service <NUM>. The first service <NUM> and the second service <NUM> may be the same service, or the first service <NUM> and the second service <NUM> may be different services. The term "binding information" is well-recognised in the art and thus a person skilled in the art will be aware of various parameters that may be indicated by the binding information referred to herein. Nevertheless, some examples will be provided for completeness.

For example, in some embodiments, the one or more parameters may comprise a parameter that binds the first NF node <NUM> to selecting the second service <NUM>, <NUM> in the second NF node <NUM> for the subsequent second request <NUM>, <NUM>, or a parameter that binds the first NF node <NUM> to selecting the second service <NUM>, <NUM> in a third NF node <NUM> for the subsequent second request <NUM>, <NUM>. In some embodiments, the parameter that binds the first NF node <NUM> to selecting the second service <NUM>, <NUM> in the second NF node <NUM> for the subsequent second request <NUM>, <NUM> comprises an identifier that (e.g. uniquely) identifies the second NF node <NUM> and/or the parameter that binds the first NF node <NUM> to selecting the second service <NUM>, <NUM> in the third NF node <NUM> for the subsequent second request <NUM>, <NUM> comprises an identifier that (e.g. uniquely) identifies the set <NUM> of NF nodes. In some embodiments, as mentioned earlier, the binding information can comprise an identifier that (e.g. uniquely) identifies the second NF node <NUM> (or the selected instance of the second NF node <NUM>, e.g. NFp instance Id), an identifier that (e.g. uniquely) identifies the set <NUM> of NF nodes that comprises the second NF node <NUM> (e.g. NFp Set X Id), and a name of the first service <NUM> (e.g. Service A). Other examples of one or more parameters that the binding information may comprise are those in Table <NUM>. <NUM>-<NUM> of 3GPP TS <NUM> V16.

As illustrated by arrow <NUM> of <FIG>, the first SCP node <NUM> initiates transmission of the second response <NUM> towards the first NF node <NUM>. Thus, in response to receiving, from the second NF node <NUM>, a first response <NUM> to the first request <NUM>, <NUM> transmitted towards the second NF node <NUM> via the first SCP node <NUM>, the first SCP node <NUM> initiates transmission of the second response <NUM> towards the first NF node <NUM>. The second response <NUM> comprises the binding information indicative of the one or more parameters by which the first NF node <NUM> is bound when selecting a second service <NUM>, <NUM> in an NF node <NUM>, <NUM> of a service producer for a subsequent second request <NUM>, <NUM>. In embodiments where the first SCP node <NUM> initiates transmission of the third request towards the NRF node <NUM> for the binding information, the first SCP node <NUM> may initiate transmission of the second response <NUM> towards the first NF node <NUM> in response to receiving the binding information from the NRF node <NUM>. In some embodiments, the second response <NUM> can also comprise information (e.g. one or more values) corresponding to the NFp selection.

As illustrated by blocks <NUM> and <NUM> of <FIG>, in some embodiments, the first NF node <NUM> may control a memory (such as the memory <NUM> of the first NF node or another memory) to store the received binding information. The first NF node <NUM> may control the memory to store the received binding information, e.g. with the UE/session context.

Step <NUM> of <FIG> is as described earlier with reference to <FIG>. As illustrated by block <NUM> of <FIG>, like block <NUM> of <FIG>, the first NF node <NUM> extracts the first NF node <NUM>, from the location information, an address of the second NF node <NUM>, which may be an application programming interface (API) root of a uniform resource identifier (URI) used to reach of the second NF node <NUM> (i.e. the sbi-target-apiroot). However, as illustrated by block <NUM> of <FIG>, the first NF node <NUM> also retrieves, from the memory, the stored binding information and includes this binding information in the subsequent second request. As illustrated by arrow <NUM> of <FIG>, the first NF node <NUM> initiates transmission of the subsequent second request, which comprises the binding information, towards the first SCP node <NUM>. The subsequent service request can also comprise the address of the second NF node <NUM> (e.g. the sbi-target-apiroot).

Steps <NUM>-<NUM> of <FIG> are as described earlier with reference to <FIG>. However, the first SCP node <NUM> now has the means (by way of the binding information) to take action to fulfil the subsequent second request. For example, the binding information may comprise a parameter that binds the first NF node <NUM> to selecting the second service <NUM>, <NUM> in a third NF node <NUM> for the subsequent second request <NUM>, <NUM> if reselection of an NF node of the service producer is required. In some embodiments, this parameter may comprise an identifier that (e.g. uniquely) identifies the set <NUM> of NF nodes, such that an NF node in the same set <NUM> can be selected. Thus, as illustrated by block <NUM> of <FIG>, the first SCP node <NUM> can select another NF node of the service producer. For example, the first SCP node <NUM> may check NF profiles to find those that comprise the identifier that identifies the set <NUM> of NF nodes, such that an NF node in the same set <NUM> can be selected. The NF profiles may be stored in a memory <NUM> of the first SCP node <NUM> (e.g. from earlier discovery) and/or at the NRF node <NUM>.

For the purpose of the illustration, it is assumed that the first SCP node <NUM> selects the third NF node <NUM>. Thus, as illustrated by arrow <NUM> of <FIG>, the first SCP node <NUM> initiates transmission of the subsequent second request towards the third NF node <NUM>. As illustrated by arrow <NUM> of <FIG>, the third NF node <NUM> initiates transmission of a response to the subsequent second request towards the first SCP node <NUM>. As in the illustration, the response can be indicative that the subsequent second request is successful. The response can comprise some business logic (BL) information and/or binding information. As illustrated by arrow <NUM> of <FIG>, the first SCP node <NUM> initiates transmission of a response to the subsequent second request towards the first NF node <NUM>. The response comprises the result that the subsequent second request is successful and optionally also the BL information and/or the binding information. As illustrated by blocks <NUM> and <NUM> of <FIG>, the first NF node <NUM> may store the result, the BL information, and/or the binding information e.g. with the UE/session context.

<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> can operate in response to receiving, from the second NF node, a first response 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 provide a first service requested by the first NF node. The first SCP node <NUM> comprises a transmission initiating module <NUM> configured to initiate transmission of a second response towards the first NF node. The second response comprises binding information irrespective of whether the binding information is present in the first response. The binding information is indicative of one or more parameters by which the first NF node is bound when selecting a second service in an NF node of a service producer for a subsequent second request. The first SCP node <NUM> may operate in the manner described herein in respect of the first 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), 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) 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) 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 described herein can be performed by hardware. Thus, in some embodiments, the first 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 described herein can be virtualized. For example, the functions performed by the first 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, the first SCP node <NUM> described herein can be a virtual node. In some embodiments, at least part or all of the first SCP node functionality described herein may be performed in a network enabled cloud. The first 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. The first SCP node <NUM> includes binding information in the second response <NUM>, e.g. on behalf of the second NF node <NUM> when the second NF node <NUM> does not provide such binding information. In this way, binding will be possible irrespective of whether it is supported by the second NF node <NUM>. Moreover, even when the second NF node <NUM> does not support binding, the first SCP node <NUM> still does not need to store the UE/session context. In this way, storage resources can be conserved.

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:
checking whether the first NF node supports being bound by one or more parameters; and
initiating (<NUM>) transmission of a second response (<NUM>) towards the first NF node (<NUM>) in response to receiving, from the second NF node (<NUM>), a first response (<NUM>) to a first request (<NUM>, <NUM>) transmitted towards the second NF node (<NUM>) via the first SCP node (<NUM>), wherein the first request (<NUM>, <NUM>) is for the second NF node (<NUM>) to provide a first service (<NUM>) requested by the first NF node (<NUM>),
wherein the second response (<NUM>) comprises binding information irrespective of whether the binding information is present in the first response (<NUM>), wherein the second response (<NUM>) comprises the binding information only if the first NF node supports being bound by the one or more parameters, and wherein the binding information is indicative of the one or more parameters by which the first NF node (<NUM>) is bound when selecting a second service (<NUM>, <NUM>) in an NF node (<NUM>, <NUM>) of a service producer for a subsequent second request (<NUM>, <NUM>).