Search

EP-4487552-B1 - SERVICE REQUEST PROCESSING

EP4487552B1EP 4487552 B1EP4487552 B1EP 4487552B1EP-4487552-B1

Inventors

  • BARTOLOME RODRIGO, MARIA CRUZ
  • LI, Songmao
  • LU, YUNJIE
  • Zhang, Xinyu

Dates

Publication Date
20260506
Application Date
20230302

Claims (15)

  1. A method (700) performed at a first Network Function, NF, node for requesting a service with a Service Communication Proxy, SCP, comprising: transmitting (S710) a request for the service to the SCP, the request comprising at least an indication indicating a required Application Program Interface, API, version for the service, wherein the required API version is other than an API version included in a Resource Uniform Resource Identifier, URI, in the request.
  2. The method of claim 1, further comprising: receiving (S720) from the SCP a response including an error message indicating that no second NF node provides the required API version for the service.
  3. The method of claim 2, wherein the response further includes information on an API version for the service of at least one second NF node that provides an API version different from the required API version for the service.
  4. The method of claim 3, further comprising: constructing (S730) a different request for the service by changing the required API version.
  5. The method of claim 4, wherein constructing a different request for the service is performed by taking the received information on the different API version into account.
  6. A method (800) performed at a Service Communication Proxy, SCP, the method comprising: receiving (S810) a request for a service from a first Network Function, NF, node, the request including an indication indicating a required Application Program Interface, API, version for the service, wherein the required API version is other than an API version included in a Resource Uniform Resource Identifier, URI, in the request; and searching (S820) for a second NF node that provides the service of the required API version.
  7. The method of claim 6, wherein searching for a second NF node comprises: transmitting, to a Network Repository Function, NRF, an NF discovery request for discovering a second NF node that provides the required API version for the service; or searching in a cache of the SCP for the second NF node.
  8. The method of claim 6 or 7, further comprising: transmitting (S830) a response to the first NF node, including an error message indicating that no second NF node provides the required API version for the service.
  9. The method of claim 8, further comprising: searching (S840) for at least one second NF node that provides the service of an API version different from the required API version, and, optionally, including (S850) information on the different API version for the service of the at least one second NF node, if any, in the response to the first NF node, particularly further comprising: extracting (S860) the information on the different API version from a profile of the at least one second NF node.
  10. The method of any of claims 1 to 9, wherein the required API version only indicates a major version.
  11. A first network function, NF node (1300) for requesting a service with a Service Communication Proxy, SCP, the first NF node being configured to: transmit (S710) a request for the service to the SCP, the request comprising at least an indication indicating a required Application Program Interface, API, version for the service, wherein the required API version is other than an API version included in a Resource Uniform Resource Identifier, URI, in the request.
  12. The first network function, NF node, according to claim 11, wherein the first NF node is configured to perform a method according to any one of claims 2 to 5 or 10, when dependent on any of claims 1 to 5.
  13. A Service Communication Proxy, SCP node, the node being configured to: receive (S810) a request for a service from a first Network Function, NF, node, the request including an indication indicating a required Application Program Interface, API, version for the service, wherein the required API version is other than an API version included in a Resource Uniform Resource Identifier, URI, in the request; and search (S820) for a second NF node that provides the service of the required API version.
  14. The Service Communication Proxy, SCP node, according to claim 13, wherein the SCP is configured to perform a method according to any one of claims 7 to 9 or 10, when dependent on any of claims 6 to 9.
  15. A computer program comprising instructions which, when executed by at least one processor, cause the at least one processor to perform the method according to: any of claims 1 to 5, or claim 10 when dependent on any of claims 1 to 5 ; any of claims 7 to 9 or claim 10 when dependent on any of claims 6 to 9 ;

Description

TECHNICAL FIELD The present disclosure generally relates to the technical field of telecommunication, and particularly to methods and Network Function (NF) nodes for processing a service request in a network comprising a set of NF nodes, and a corresponding computer readable medium. BACKGROUND This section is intended to provide a background to the various embodiments of the technology described in this disclosure. The description in this section may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and/or claims of this disclosure and is not admitted to be prior art by the mere inclusion in this section. In Fifth Generation (5G) networks, a Network Slice is introduced as a logical network that provides specific network capabilities and network characteristics. An instance of a network slice (e.g. a network slice instance (NSI)) is a set of Network Function (NF) instances and the required resources (e.g., computing, storage, and networking resources) which form a deployed Network Slice. An NF is a third generation partnership project (3GPP) adopted or 3GPP defined processing function in a network, which has defined functional behavior and 3GPP defined interfaces. An NF can be implemented either as a network element on dedicated hardware, a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., on a cloud infrastructure. The document WO2021083926A1 discloses sending a service discovery request from network entity, where the request includes a set of query parameters comprising a preferred application programming interface, API, version. Among the NFs, a Service Communication Proxy (SCP) is defined, which provides centralized capabilities such as Service Based Interface (SBI) routing, NF discovery and selection, failover, message screening, etc. An SCP is used in indirect routing scenarios and one of the options to deploy SCP is model D, as described in 3GPP technical standard (TS) 23.501 (see, for example, annex E of 3GPP TS 23.501). Figure 1 shows a communication model for NF/NF services interaction in model D, as described in 3GPP TS 23.501. As per the service definition in 3GPP 23.501, Model D can be defined as indirect communication with delegated discovery. That is, NF service consumers do not do (perform) any discovery or selection. The consumer adds any necessary discovery and selection parameters required to find a suitable producer to a service request. The SCP uses a request address and the discovery and selection parameters in a request message to route the request to a suitable producer instance. The SCP can perform discovery with a Network Repository Function (NRF) and obtain a discovery result. In this model, the SCP discovers the target NF service producer. As per the service definition in 3GPP 23.501, if indirect communication with delegated discovery is used, the NF service consumer sends the request to the SCP and provides, within the service request to the SCP, the discovery and selection parameters necessary to discover and select an NF service producer. Moreover, it is indicated in 3GPP TS 29.501 that an Application Program Interface (API) version is part of a resource Uniform Resource Identifier (URI). Clause 4.3.1.3 of 3GPP TS 29.501 relates to the visibility of the API version number fields. The API version can be indicated in the resource URI of every API, as described in clause 4.4.1 of 3GPP TS 29.501. The API version can be indicated as the concatenation of the letter "v" and the 1st field of the API version number. The other fields may not be included in the resource URI. Including these digits in the URI can force the NF service consumer to select a specific sub-version, at the risk of seeing the request rejected if the NF service provider does not support it, while the request may have been served by ignoring unknown elements. Clause 4.4.1 of 3GPP TS 29.501 relates to a resource URI structure. Resources are either individual resources, or structured resources that can contain child resources. It is commonly recommended to design each resource following one of the archetypes provided in Annex C of 3GPP TS 29.501. A URI uniquely identifies a resource. In the 5G core (5GC) SBI APIs, when a resource URI is an absolute URI, its structure can be specified as follows: {apiRoot}/<apiName>/<apiVersion>/<apiSpecificResourceUriPart> "apiName" defines the name of the API and "apiVersion" indicates the 1st Field (MAJOR) of the version of the API (see, for example, clause 4.3.1.3 and 4.4.1 of 3GPP TS 29.501). In clause 4.3.1.1 of 3GPP TS 29.501, an API version number format is also indicated. API version numbers can consist of at least 3 fields, following a MAJOR.MINOR.PATCH pattern (for example, according to the Semantic Versioning Specifica