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 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>. Herein, this service request may be referred to as the "first request" <NUM>. The service request <NUM> 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), location information, and/or binding 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>. The second NF node <NUM> supports binding and thus includes binding information in the response, e.g. in a header of the response. The binding information is intended to be used by the first NF node <NUM> in subsequent requests. As illustrated by block <NUM> of <FIG>, the first SCP node <NUM> has no means to check whether the first NF node <NUM> actually supports binding or not. As such, the first SCP node <NUM> needs to act in the same way irrespective of whether the first NF node <NUM> actually supports binding or not.

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, the location information, and/or the binding 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>, if the first NF node <NUM> supports binding, the first NF node <NUM> retrieves the binding information for the UE/session context. The first NF node <NUM> copies the binding information to routing binding, which is included in a subsequent service request. On the other hand, if the first NF node <NUM> does not support binding, the binding information will be lost. As also illustrated by block <NUM> of <FIG>, the first NF node <NUM> extracts, from the location information, an address of the second NF node <NUM>. The address of the second NF node <NUM> 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). The first NF node <NUM> includes, in a subsequent service request, the binding information (if the first NF node <NUM> actually supports binding) and the address of the second NF node <NUM>.

As illustrated by arrow <NUM> of <FIG>, the first NF node <NUM> initiates transmission of the 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. As mentioned earlier, 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. As illustrated by block <NUM> of <FIG>, if the subsequent service request comprises binding information, the first SCP node <NUM> is able to perform a reselection. Thus, in this case, the first SCP node <NUM> uses the binding information to select another NF node of the service producer, e.g. in the same set as the second NF node <NUM>. The selection can either be made using discovery (in a similar manner as described earlier with reference to steps <NUM>-<NUM>) or from discovery results previously stored at the first SCP node <NUM>. On the other hand, if the subsequent service request does not comprise binding information (because the first NF node <NUM> does not support binding), the first SCP node <NUM> will be unable to perform a reselection, since it does not have the information (e.g. an identifier of the NF set comprising the second NF node <NUM>) available to it in order to do so. For the purpose of the illustration, it is assumed that the subsequent service request comprises binding information and 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 second request towards the third NF node <NUM> for the third NF node <NUM> to provide the service <NUM>. As illustrated by arrow <NUM> of <FIG>, the first SCP node <NUM> receives a response to the second request from the third NF node <NUM>. As in the illustration, the response can be indicative that the result is 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 the response to the first NF node <NUM>. As illustrated by blocks <NUM> and <NUM> of <FIG>, the first NF node <NUM> stores the information comprised in the response.

Thus, the procedure is successful when the first NF node <NUM> supports binding, but unsuccessful when the first NF node <NUM> does not support binding. <CIT> discloses an architecture according to which a first service instance (service consumer) registers in the NRF whether the ability to select a service instance from a service set is supported, so that a second service instance (service producer) can obtain from the NRF whether the first service instance supports load balancing based on the service set.

As mentioned earlier, the procedure illustrated in <FIG> is unsuccessful when the first NF node <NUM> does not support binding. In particular, the first SCP node <NUM> does not have the means to select a different NF node of the service producer to be able to fulfil the subsequent second service request. The subsequent second service request is thus unsuccessful in this case. The first SCP node <NUM> or the second NF node <NUM> need to behave differently depending on the behaviour of the first NF node <NUM> to be able to counteract this. However, the first NF node <NUM> does not register its behaviour or any NF profile with the NRF node <NUM> if it is only acting as an NF node of the service consumer and not also acting as an NF node of the service producer. As such, the first SCP node <NUM> and the second NF node <NUM> are unable to determine the features that are supported by the first NF node <NUM>.

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

Therefore, objects of the present invention are methods and apparatuses according to the appended independent claims. Preferred embodiments are covered by the appended dependent claims.

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 network node <NUM>, <NUM> in accordance with an embodiment. The first network node <NUM>, <NUM> can be a first service communication proxy (SCP) node <NUM> 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. Alternatively, the first network node <NUM>, <NUM> can be the second NF node <NUM>. In some embodiments, the first network node <NUM>, <NUM> can be, for example, be a physical machine (e.g. a server) or a virtual machine (VM).

As illustrated in <FIG>, the first network node <NUM>, <NUM> comprises processing circuitry (or logic) <NUM>. The processing circuitry <NUM> controls the operation of the first network node <NUM>, <NUM> and can implement the method described herein in respect of the first network node <NUM>, <NUM>. The processing circuitry <NUM> can be configured or programmed to control the first network node <NUM>, <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 network node <NUM>, <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 network node <NUM>, <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 network node <NUM>, <NUM>.

Briefly, the processing circuitry <NUM> of the first network node <NUM>, <NUM> is configured to, in response to receiving a first request transmitted towards the second NF node via the first SCP node, acquire information indicative of a functionality supported by the first NF 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 network node <NUM>, <NUM> is configured to operate based on the functionality supported by the first NF node.

As illustrated in <FIG>, in some embodiments, the first network node <NUM>, <NUM> may optionally comprise a memory <NUM>. The memory <NUM> of the first network node <NUM>, <NUM> can comprise a volatile memory or a non-volatile memory. In some embodiments, the memory <NUM> of the first network node <NUM>, <NUM> may comprise a non-transitory media. Examples of the memory <NUM> of the first network node <NUM>, <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 network node <NUM>, <NUM> can be connected to the memory <NUM> of the first network node <NUM>, <NUM>. In some embodiments, the memory <NUM> of the first network node <NUM>, <NUM> may be for storing program code or instructions which, when executed by the processing circuitry <NUM> of the first network node <NUM>, <NUM>, cause the first network node <NUM>, <NUM> to operate in the manner described herein in respect of the first network node <NUM>, <NUM>. For example, in some embodiments, the memory <NUM> of the first network node <NUM>, <NUM> may be configured to store program code or instructions that can be executed by the processing circuitry <NUM> of the first network node <NUM>, <NUM> to cause the first network node <NUM>, <NUM> to operate in accordance with the method described herein in respect of the first network node <NUM>, <NUM>. Alternatively or in addition, the memory <NUM> of the first network node <NUM>, <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 network node <NUM>, <NUM> may be configured to control the memory <NUM> of the first network node <NUM>, <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 network node <NUM>, <NUM> may optionally comprise a communications interface <NUM>. The communications interface <NUM> of the first network node <NUM>, <NUM> can be connected to the processing circuitry <NUM> of the first network node <NUM>, <NUM> and/or the memory <NUM> of first network node <NUM>, <NUM>. The communications interface <NUM> of the first network node <NUM>, <NUM> may be operable to allow the processing circuitry <NUM> of the first network node <NUM>, <NUM> to communicate with the memory <NUM> of the first network node <NUM>, <NUM> and/or vice versa. Similarly, the communications interface <NUM> of the first network node <NUM>, <NUM> may be operable to allow the processing circuitry <NUM> of the first network node <NUM>, <NUM> to communicate with a second network node and/or any other node. The communications interface <NUM> of the first network node <NUM>, <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 network node <NUM>, <NUM> may be configured to control the communications interface <NUM> of the first network node <NUM>, <NUM> to transmit and/or receive information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

Although the first network node <NUM>, <NUM> is illustrated in <FIG> as comprising a single memory <NUM>, it will be appreciated that the first network node <NUM>, <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 network node <NUM>, <NUM> is illustrated in <FIG> as comprising a single communications interface <NUM>, it will be appreciated that the first network node <NUM>, <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 network node <NUM>, <NUM> and, in practical implementations, the first network node <NUM>, <NUM> may comprise additional or alternative components to those shown.

<FIG> is a flowchart illustrating a method performed by a first network node <NUM>, <NUM> in accordance with an embodiment. The method is for operating the first network node <NUM>, <NUM>. As mentioned earlier, the first network node <NUM>, <NUM> can be a first SCP node <NUM> 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. Alternatively, the first network node <NUM>, <NUM> can be the second NF node <NUM>. The first network node <NUM>, <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 network node <NUM>, <NUM>.

The method is performed in response to receiving 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>, information indicative of a functionality supported by the first NF node is acquired. As illustrated at block <NUM> of <FIG>, the first network node operates based on the functionality supported by the first NF node. The information can be acquired in a variety of ways. For example, the information may be acquired from a network repository function (NRF) node, the first NF node, and/or a memory (e.g. a memory <NUM> of the first network node <NUM>, <NUM> or another memory).

In some embodiments where the information is acquired from an NRF node, the first request received at the first network node <NUM>, <NUM> may comprise one or more identifiers that allow the first NF node <NUM> to be (e.g. uniquely) identified and acquiring the information from the NRF node may comprise acquiring the information from the NRF node <NUM> using the one or more identifiers. In some embodiments, acquiring the information from the NRF node may comprise acquiring the information from a profile of the first NF node stored at the NRF node. In some embodiments, acquiring the information from the NRF node may comprise initiating transmission of a second request for the information towards the NRF node. In some embodiments, acquiring the information from the NRF node may comprise receiving the information from the NRF node.

In some embodiments where the information is acquired from the first NF node, the first request received at the first network node <NUM>, <NUM> may comprise the information and acquiring the information from the first NF node may comprise acquiring the information from the first request. In some embodiments, a header of the first request received at the first network node <NUM>, <NUM> may comprise the information. In some embodiments, the header of the first request may be a hypertext transfer protocol (HTTP) header. This header is a new header, i.e. a header that is not currently included in the first request according to existing techniques. The header can be a custom header.

In some embodiments where the information is acquired from a memory, the information stored in the memory may be from a third request transmitted towards the second NF node <NUM> via the first SCP node <NUM>. The third request can be for the second NF node <NUM> to provide the first service requested by the first NF node. The third request is received at the first network node <NUM>, <NUM> prior to the first request. In some embodiments, in response to receiving the third request comprising the information, the method may comprise controlling the memory to store the information from the third request. In some embodiments, a header of the third request may comprise the information. In some embodiments, the header of the third request may be a hypertext transfer protocol (HTTP) header. This header is a new header, i.e. a header that is not currently included in the third request according to existing techniques. The header can be a custom header.

In some embodiments, the first SCP node <NUM> may acquire the information in any of the ways described earlier and the second NF node <NUM> may acquire the information from the first SCP node <NUM>. For example, the first SCP node <NUM> may initiate transmission of the information towards the second NF node <NUM> according to some embodiments. In these embodiments, the second NF node <NUM> acquires the information by receiving the information from the first SCP node <NUM>.

In an example, the acquired information referred to herein may be indicative of whether or not the first NF node <NUM> supports binding and the first network node <NUM>, <NUM> can operate based on whether or not binding is supported by the first NF node <NUM>. For example, the first network node <NUM>, <NUM> may include binding information in a response to a request received from the first NF node <NUM> if the acquired information is indicative that the first NF node <NUM> supports binding and/or may omit binding information from the response to the request received from the first NF node <NUM> if the acquired information is indicative that the first NF node <NUM> does not support binding. Thus, more generally, the first network node <NUM>, <NUM> may provide the first NF node <NUM> with information that the first NF node <NUM> can actually use.

In another example, the acquired information referred to herein may be indicative of whether or not the first NF node <NUM> supports management of load provided by one or more NF nodes of the service producer (e.g. the second NF node <NUM>, the third NF node <NUM>, and/or any other NF nodes of the service producer) and the first network node <NUM>, <NUM> can operate based on whether or not load management is supported by the first NF node <NUM>. For example, the first network node <NUM>, <NUM> may handle the load management (e.g. load balancing) if the acquired information is indicative that the first NF node <NUM> does not support load management.

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

As illustrated in <FIG>, the second network node <NUM>, <NUM> comprises processing circuitry (or logic) <NUM>. The processing circuitry <NUM> controls the operation of the second network node <NUM>, <NUM> and can implement the method described herein in respect of the second network node <NUM>, <NUM>. The processing circuitry <NUM> can be configured or programmed to control the second network node <NUM>, <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 network node <NUM>, <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 network node <NUM>, <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 network node <NUM>, <NUM>.

Briefly, the processing circuitry <NUM> of the second network node <NUM>, <NUM> is configured to, provide the first network node <NUM>, <NUM> with access to information indicative of a functionality supported by the first NF node to allow the first network node <NUM>, <NUM> to operate based on the functionality supported by the first NF node.

As illustrated in <FIG>, in some embodiments, the second network node <NUM>, <NUM> may optionally comprise a memory <NUM>. The memory <NUM> of the second network node <NUM>, <NUM> can comprise a volatile memory or a non-volatile memory. In some embodiments, the memory <NUM> of the second network node <NUM>, <NUM> may comprise a non-transitory media. Examples of the memory <NUM> of the second network node <NUM>, <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 network node <NUM>, <NUM> can be connected to the memory <NUM> of the second network node <NUM>, <NUM>. In some embodiments, the memory <NUM> of the second network node <NUM>, <NUM> may be for storing program code or instructions which, when executed by the processing circuitry <NUM> of the second network node <NUM>, <NUM>, cause the second network node <NUM>, <NUM> to operate in the manner described herein in respect of the second network node <NUM>, <NUM>. For example, in some embodiments, the memory <NUM> of the second network node <NUM>, <NUM> may be configured to store program code or instructions that can be executed by the processing circuitry <NUM> of the second network node <NUM>, <NUM> to cause the second network node <NUM>, <NUM> to operate in accordance with the method described herein in respect of the second network node <NUM>, <NUM>. Alternatively or in addition, the memory <NUM> of the second network node <NUM>, <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 network node <NUM>, <NUM> may be configured to control the memory <NUM> of the second network node <NUM>, <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 network node <NUM>, <NUM> may optionally comprise a communications interface <NUM>. The communications interface <NUM> of the second network node <NUM>, <NUM> can be connected to the processing circuitry <NUM> of the second network node <NUM>, <NUM> and/or the memory <NUM> of second network node <NUM>, <NUM>. The communications interface <NUM> of the second network node <NUM>, <NUM> may be operable to allow the processing circuitry <NUM> of the second network node <NUM>, <NUM> to communicate with the memory <NUM> of the second network node <NUM>, <NUM> and/or vice versa. Similarly, the communications interface <NUM> of the second network node <NUM>, <NUM> may be operable to allow the processing circuitry <NUM> of the second network node <NUM>, <NUM> to communicate with the first network node <NUM>, <NUM> and/or any other node. The communications interface <NUM> of the second network node <NUM>, <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 network node <NUM>, <NUM> may be configured to control the communications interface <NUM> of the second network node <NUM>, <NUM> to transmit and/or receive information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

Although the second network node <NUM>, <NUM> is illustrated in <FIG> as comprising a single memory <NUM>, it will be appreciated that the second network node <NUM>, <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 network node <NUM>, <NUM> is illustrated in <FIG> as comprising a single communications interface <NUM>, it will be appreciated that the second network node <NUM>, <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 network node <NUM>, <NUM> and, in practical implementations, the second network node <NUM>, <NUM> may comprise additional or alternative components to those shown.

<FIG> is a flowchart illustrating a method performed by a second network node <NUM>, <NUM> in accordance with an embodiment. The method of <FIG> is for providing information to the first network node <NUM>, <NUM>. The second network node <NUM>, <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 second network node <NUM>, <NUM>.

As illustrated at block <NUM> of <FIG>, the first network node <NUM>, <NUM> is provided with access to information indicative of a functionality supported by the first NF node to allow the first network node <NUM>, <NUM> to operate based on the functionality supported by the first NF node. The information can be provided in a variety of ways.

For example, in an embodiment where the second network node <NUM>, <NUM> is an NRF node <NUM>, the NRF node <NUM> may provide the first network node <NUM>, <NUM> with access to the information by providing the first network node <NUM>, <NUM> with access to a profile of the first NF node stored at the NRF node <NUM>. In this embodiment, the profile of the first NF node comprises the information. Thus, the profile of the first NF node comprises a new attribute by way of this information, i.e. an attribute that is not currently included in the profile of an NF node of a consumer according to existing techniques.

In some embodiments, the NRF node <NUM> may provide the first network node <NUM>, <NUM> with access to the information in response to receiving a second request for the information. In some embodiments, the NRF node <NUM> may provide the first network node <NUM>, <NUM> with access to the information by initiating transmission of the information towards first network node <NUM>, <NUM>. In some embodiments, the method performed by the NRF node <NUM> may comprise receiving a registration request from the first NF node and the registration request can comprise the information.

In an embodiment where the second network node <NUM>, <NUM> is the first NF node <NUM>, the method performed by the first NF node <NUM> may comprise initiating transmission of a first request towards the second NF node <NUM> via the first SCP node <NUM>. The first request can be for the second NF node <NUM> to provide (e.g. execute or run) a first service requested by the first NF node <NUM>. In some embodiments, the first NF node <NUM> may provide the first network node <NUM>, <NUM> with access to the information by the first request comprising the information. In some embodiments, a header of the first request may comprise the information. In some embodiments, the header of the first request may be a hypertext transfer protocol (HTTP) header, such as a new 3GPP specific HTTP header. Alternatively or in addition, in some embodiments, the first NF node <NUM> may provide the first network node <NUM>, <NUM> with access to the information by the first request comprising one or more identifiers that allow the first NF node <NUM> to be (e.g. uniquely) identified. In these embodiments, the one or more identifiers are for use by the first network node <NUM>, <NUM> to acquire the information from the NRF node <NUM>.

The first request referred to herein may be an initial request or a subsequent request. In some embodiments, the information may be comprised in the initial request only. In these embodiments, the first network node <NUM>, <NUM> may store the information. Alternatively, in some embodiments, the information may be comprised in all requests, i.e. the initial request and all subsequent requests.

In some embodiments, the first NF node <NUM> may provide the first network node <NUM>, <NUM> with access to the information by, prior to initiating transmission of the first request, initiating transmission of a third request towards the second NF node <NUM> via the first SCP node <NUM>. In these embodiments, the third request comprises the information. The third request can be for the second NF node <NUM> to provide (e.g. execute or run) a first service requested by the first NF node <NUM>. In some embodiments, a header of the third request may comprise the information. In some embodiments, the header of the third request may be a hypertext transfer protocol (HTTP) header. In embodiments involving a third request, the third request referred to herein may be the initial request and the first request may be a subsequent request, such that all requests comprise the information.

There is also provided a system. The system can comprise at least one first network node <NUM>, <NUM> as described herein and/or at least one second network node <NUM>, <NUM> as described herein. For example, the system can comprise at least one first SCP node <NUM> configured to operate in the manner described herein in respect of the first network node, at least one second NF node <NUM> configured to operate in the manner described herein in respect of the first network node, at least one first NF node <NUM> as described herein in respect of the second network node, and/or at least one NRF node <NUM> as described herein in respect of the second network node. 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 an NRF node <NUM>. The first SCP node <NUM> can be as described earlier with reference to <FIG>. The NRF node <NUM> can be as described earlier with reference to <FIG>. 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.

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 provide (e.g. execute or run) a service <NUM>. The third NF node <NUM> can be configured to provide (e.g. 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 (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.

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 mentioned earlier, the first response <NUM> can comprise binding information according to some embodiments.

Herein, binding information can be 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. The subsequent second request can be a subsequent second request that follows the first (or third) request directly, or a subsequent second request that follows the first (or third) request indirectly, e.g. it may be a request that follows another one or more requests that follow the first (or third) request. 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, 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. 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 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 comprises an identifier that (e.g. uniquely) identifies the set <NUM> of NF nodes. In some embodiments, 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.

Returning back to <FIG>, in the embodiment illustrated, features supported by the first NF node <NUM> acting as a service consumer are defined at NF level. The features may be referred to in the art as "supported features". The supported features identify the functionality that is supported by the first NF node <NUM> acting as a service consumer. The supported features can be included in an NF profile of the first NF node <NUM> acting as a service consumer. The same supported features attribute is used in existing techniques at the service level only to indicate the features that are supported by an NF node acting as a service producer.

Thus, with reference to <FIG>, as illustrated by block <NUM> and arrows <NUM>-<NUM>, the first SCP node <NUM> acquires information indicative of a functionality supported by the first NF node <NUM>. That is, the first SCP node <NUM> acquires information on the supported features mentioned earlier. The information is acquired in response to receiving the first request <NUM> transmitted towards the second NF node <NUM> via the first SCP node <NUM>. As mentioned previously, the first request <NUM> is for the second NF node <NUM> to provide (e.g. execute or run) a first service <NUM> requested by the first NF node <NUM>. In the illustrated embodiment of <FIG>, the information is acquired from the NRF node <NUM>. The NRF node <NUM> may, for example, have received a registration request from the first NF node <NUM>, which comprised the information. The NRF node <NUM> may store the information.

In more detail, the first request <NUM> received at the first SCP node <NUM> comprises one or more identifiers (e.g. the NF instance Id of the first NF node <NUM>) that allow the first NF node <NUM> to be (e.g. uniquely) identified. It can be mandatory for the first request <NUM> to comprise the one or more identifiers. As illustrated by block <NUM> of <FIG>, the first SCP node <NUM> retrieves the one or more identifiers from the first request <NUM> received at the first SCP node <NUM>. For example, the one or more identifiers may be retrieved from the discovery parameters comprised in the first request <NUM> received at the first SCP node <NUM>. The first SCP node <NUM> can then acquire the information from the NRF node <NUM> using the one or more identifiers.

In particular, as illustrated by arrow <NUM> of <FIG>, the first SCP node <NUM> initiates transmission of a second request <NUM> for the information towards the NRF node <NUM>. The NRF node <NUM> can provide the first SCP node <NUM> with access to the information in response to receiving this second request <NUM> for the information. The second request <NUM> may comprise the one or more identifiers that allow the first NF node <NUM> to be identified. In this way, the NRF node <NUM> can retrieve the information that corresponds to the one or more identifiers and that thus corresponds to the first NF node <NUM>. As illustrated by arrow <NUM> of <FIG>, the NRF node <NUM> provides the first SCP node <NUM> with access to the information by initiating transmission of the information towards first network node <NUM>. The first SCP node <NUM> receives the information from the NRF node <NUM>. Thus, in some embodiments, the first SCP node <NUM> can acquire the information through discovery.

In some embodiments, the information can be comprised in a profile of the first NF node <NUM> stored at the NRF node <NUM>. Thus, in some embodiments, the NRF node <NUM> can provide the first SCP node <NUM> with access to the information by providing the first SCP node <NUM> with access to the profile of the first NF node. The profile of the first NF node <NUM> may comprise the one or more identifiers, such that the NRF node <NUM> can identify the profile that belongs to the first NF node <NUM>. It may then be the profile of the first NF node <NUM> comprising the information that is received by the first SCP node <NUM>. In these embodiments, as illustrated by block <NUM> of <FIG>, the first SCP node <NUM> can check the profile of the first NF node <NUM> to identify the functionality that is supported by the first NF node <NUM>. That is, the first SCP node <NUM> checks the supported features in the profile of the first NF node <NUM>. The supported features are thus checked at the NF profile level and, more specifically, at NF consumer level.

As illustrated by block <NUM> of <FIG>, the first SCP node <NUM> operates (e.g. selects its behaviour) based on the functionality supported by the first NF node <NUM>. That is, the first SCP node <NUM> operates based on whether or not certain features are supported by the first NF node <NUM>. Steps <NUM> and <NUM>-<NUM> of <FIG> are as described earlier with reference to <FIG>.

Although the embodiment illustrated in <FIG> is directed to the first SCP node <NUM>, it will be understood that the method described with reference to <FIG> may equally be performed in respect of the second NF node <NUM>.

<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 NF node <NUM> of a service consumer ("NFc") and a first SCP node <NUM>. The first SCP node <NUM> can be as described earlier with reference to <FIG>. The first NF node <NUM> can be as described earlier with reference to <FIG>.

The system illustrated in <FIG> comprises 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 provide (e.g. execute or run) a service <NUM>. The third NF node <NUM> can be configured to provide (e.g. 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 (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 an 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.

Steps <NUM>-<NUM> and <NUM>-<NUM> of <FIG> are as described earlier with reference to <FIG>. In the embodiment illustrated in <FIG>, new information is included in the first request from the first NF node <NUM>, which indicates the features/functionality supported by the first NF node <NUM>. Thus, in the illustrated embodiment of <FIG>, the information is acquired from the first NF node <NUM>. In more detail, as illustrated by arrow <NUM> of <FIG>, the first NF node <NUM> initiates transmission of the first request towards the second NF node <NUM> via the first SCP node <NUM>. As mentioned earlier, the first request is for the second NF node <NUM> to provide (e.g. execute or run) a first service <NUM> requested by the first NF node <NUM>. The first NF node <NUM> provides the first SCP node <NUM> with access to the information indicative of a functionality supported by the first NF node <NUM> by the first request <NUM> comprising the information. In some embodiments, a header (e.g. a HTTP header, such as a new 3GPP specific HTTP header) of the first request <NUM> can comprise the information. Thus, the first SCP node <NUM> acquires the information on the supported features from the first request <NUM>.

Steps <NUM>-<NUM> of <FIG> are as described earlier with reference to <FIG>. As illustrated by block <NUM> of <FIG>, the first SCP node <NUM> checks the information received in the first request <NUM> to identify the functionality that is supported by the first NF node <NUM>. That is, the first SCP node <NUM> checks the supported features. In an embodiment where a header comprises the information, the first SCP node <NUM> may check a value of the header to identify whether a functionality is supported by the first NF node <NUM>, or the mere presence of the header may indicate that the feature is supported. For example, the header may only be included if the feature is supported.

<FIG> is a block diagram illustrating a first network node <NUM> in accordance with an embodiment. The first network node <NUM> can be a first SCP node that 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, or the first network node <NUM> can be the second NF node. The first network node <NUM> comprises an acquiring module <NUM> configured to, in response to receiving a first request transmitted towards the second NF node via the first SCP node, acquire information indicative of a functionality supported by the first NF node. The first request is for the second NF node to provide a first service requested by the first NF node. The first network node <NUM> comprises an operating module <NUM> configured to operate based on the functionality supported by the first NF node. The first network node <NUM> may operate in the manner described herein in respect of the first network node.

<FIG> is a block diagram illustrating a second network node <NUM> in accordance with an embodiment. The second network node <NUM> can be an NRF node or a first NF node of a service consumer. The second network node <NUM> can provide information to the first network node <NUM>. The first network node <NUM> can be a first SCP node configured to operate as an SCP between the first NF node and a second NF node of a service producer in the network, or the first network node <NUM> can be the second NF node. The second network node <NUM> comprises a providing module <NUM> configured to provide the first network node <NUM> with access to information indicative of a functionality supported by the first NF node to allow the first network node <NUM> to operate based on the functionality supported by the first NF node. The second network node <NUM> may operate in the manner described herein in respect of the second network 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 network node <NUM>, <NUM> described earlier and/or the processing circuitry <NUM> of the second network node <NUM>, <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 network node <NUM>, <NUM> described earlier and/or the processing circuitry <NUM> of the second network node <NUM>, <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 network node <NUM>, <NUM> described earlier and/or the processing circuitry <NUM> of the second network node <NUM>, <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 network node functionality and/or the second network node functionality described herein can be performed by hardware. Thus, in some embodiments, any one or more of the first network node <NUM>, <NUM> and the second network node <NUM>, <NUM> described herein can be a hardware node. However, it will also be understood that optionally at least part or all of the first network node functionality and/or the second network node functionality described herein can be virtualized. For example, the functions performed by any one or more of the first network node <NUM>, <NUM> and the second network node <NUM>, <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 network node <NUM>, <NUM> and the second network node <NUM>, <NUM> described herein can be a virtual node. In some embodiments, at least part or all of the first network node functionality and/or the second network node functionality described herein may be performed in a network enabled cloud. The first network node functionality and/or the second network 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 improved techniques for network node operation. In particular, by way of the technique described herein, it is possible for the first network node (e.g. the first SCP node <NUM> and/or the second NF node <NUM>) to know if the first NF node supports a certain functionality. The first network node <NUM>, <NUM> can thus adapt its behaviour depending on whether the first NF node <NUM> supports a certain functionality. In some cases, this may be crucial for some functionality to work and thus the network node operation is advantageously improved.

Claim 1:
A method for operating a first network node (<NUM>, <NUM>), wherein the method is performed by the first network node (<NUM>, <NUM>), wherein the first network node (<NUM>, <NUM>) is 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:
acquiring (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) information indicative of a functionality supported by the first NF node (<NUM>) in response to receiving a first request (<NUM>, <NUM>, <NUM>) transmitted towards the second NF node (<NUM>) via the first SCP node (<NUM>), wherein the first request (<NUM>, <NUM>, <NUM>) is for the second NF node (<NUM>) to provide a first service (<NUM>) requested by the first NF node (<NUM>); and
operating (<NUM>, <NUM>, <NUM>) based on the functionality supported by the first NF node (<NUM>).