Method for network node reselection, network node and computer-readable medium

Abstract

The present disclosure provides a method (200, 300), a network node (500, 600, 700, 800), and a computer-readable medium for network node reselection for a context related to a service. The method (200) in a first network node includes determining (S201) to reselect a third network node that can provide a service for the context that was being provided by a second network node, and sending (S203) a request message for the context to the third network node, where the request message includes property information for the request message.

Description

[Technical field]

[0001] The present disclosure relates generally to the technical field of communications technology, and more particularly to a method, a network node, and a computer-readable medium for network node reselection. [Background technology]

[0002] This section is intended to provide background for various embodiments of the technology described in this disclosure. The description in this section may include concepts that could be pursued, but not necessarily concepts that have been previously conceived or pursued. Thus, 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 mere inclusion in this section.

[0003] NF Service Set and NF Set According to 3GPP TS 23.501 V16.7.0, section 5.21.3.2 (incorporated herein by reference in its entirety), an NF service set is defined as a group of interchangeable NF service instances of the same service type within an NF instance, where NF service instances within the same NF service set have access to the same context data. Also, an NF set is defined as a group of interchangeable NF instances of the same type that support the same service and the same network slice, where NF instances within the same NF set may be geographically distributed but have access to the same context.

[0004] When a Network Function (NF) set or an NF service set is deployed in a network as specified in 3GPP TS23.501 V16.7.0 clauses 5.21.3 and 6.3.1.0, the NF service producer of the NF set creates a resource context, which is shared by all NF instances belonging to the same NF set, i.e., the resource context is bound to the NF set. Therefore, a request targeting a resource can be processed by any NF instance in the NF set, as long as the shared context is not lost.

[0005] For example, as shown in Figure 1, Server 1 and Server 2 are in the same set. If the context is processed by Server 1, the context can be smoothly processed by Server 2 while Server 1 cannot process the context at some point for some reason because the context is stored in a common central database, e.g., an Unstructured Data Storage Network Facility (UDSF) for the set, which can be accessed by all the servers in the same set, e.g., Server 1, Server 2, etc.

[0006] In a network, an NF may select another NF that may provide a required service and send a request message (e.g., a Hypertext Transfer Protocol (HTTP) request message) for that service to the other NF. Here, the NF that sends the request message is called a "client", which may refer to an NF service consumer, a service communication proxy (SCP) in the case of a normal request message, or an NF service producer in the case of a notification request message. Correspondingly, the NF that receives the request message is called a "server", which may refer to an NF service producer, an SCP, or an NF service consumer in any suitable scenario. For example, an NF service consumer (as a client) may use a service provided by an NF service producer (as a server).

[0007] For some reason, such as overload, temporary causes, unreachability, etc., the client determines that the selected server cannot provide the service requested by the client, in which case the client can reselect another server in the same set that can provide the requested service.

[0008] FIG. 1 illustrates diagrammatically an exemplary reselection process triggered, for example, by an overload of a server 1 previously selected by a client.

[0009] Although overload of server 1 is shown here as an exemplary reason for triggering the reselection process, there are other reasons for triggering the reselection process, such as server 1 being unreachable, server 1 rejecting the client's request message for temporary reasons, etc., and are not limited to this disclosure.

[0010] In S1_1, the client first selects a server instance (Server 1 in this example) based on selection criteria such as locality, priority, load, etc.

[0011] At S1_2, the client sends a request message for service A to the server 1 to establish a (resource) context X associated with the service A. In particular, the request message is sent for each context associated with the service (e.g., for each UE or for each packet data unit (PDU) session), and a service may be associated with at least one context.

[0012] At S1_3, Server 1 creates a context X related to Service A.

[0013] In this example, Server 1 is overloaded with S1_4.

[0014] At S1_5, the client may send a request message for service A to server 1, for example, to establish a context Y related to service A.

[0015] In S1_6, the server 1 may indicate to the client 1 that the server 1 is overloaded by providing overload control information (OCI) indicating the overload information of the server 1, or by providing a status code such as 429 / 503 indicating that the request messages have been rejected by the server 1. It should be noted that by using the status code 429 / 503, the client can obtain the overload information of the server 1 as OCI based on the ratio of the number of rejected request messages (together with the status code 429 / 503) to the total number of request messages. For example, the server 1 may indicate in the OCI the exact percentage by which it would like the client to reduce the number of request messages.

[0016] At S1_7, the client may store relevant information about the overloaded server 1 together with the OCI. The client needs to reduce the signaling messages sent to the server 1, which may be achieved by rejecting the original request message received at the client from the upstream NF or user equipment (UE), or by reselecting an alternative NF, for example based on the context restoration information, e.g., the context binding information.

[0017] At S1_8, the client receives a request for context X, e.g., from an upstream NF or UE, which causes the client to consume service A to update the context on Server 1. The client knows that Server 1 is overloaded and may therefore decide to reselect an alternative NF in the set where Server 1 is located (Server 2 in this example). As mentioned before, servers in the same set can provide the same service for a context, and therefore a context related to a service can be processed by any server in the set.

[0018] At S1_9, the client may send a request message for context X to server 2 in the set in which server 1 is located.

[0019] At S1_10, Server 2 may accept the request message. However, such acceptance may result in further overloading Server 1. For example: In case of an overloaded Access and Mobility Management Function (AMF), if an alternative AMF is selected for a Namf_communication service, e.g., service action, N1N2MessageTransfer, the alternative AMF may page the UE. However, when the UE responds to the paging, the UE initiates a service request to the overloaded AMF. As another example, an overloaded Session Management Function (SMF), i.e. SMF1, may be processing a request message for a session from a peer NF, e.g. Policy Control Function (PCF), and a context (for that session) in the UDSF may be locked by this SMF1, and at the same time another peer NF, e.g. AMF, may try to contact this overloaded SMF1 for the same context. In such a scenario, the AMF may decide to reselect an alternative SMF, i.e. SMF2, since it knows that SMF1 is overloaded. However, when the alternative SMF2 receives the request message and sees that the corresponding context is locked by SMF1, it still redirects the request to the overloaded SMF1.

[0020] Therefore, Server 2 may accept request messages during reselection, but may not be able to process client request messages for Context X.

[0021] There is no mechanism that allows the (reselected) alternative server to appropriately take different actions upon receiving a request message from the client for an existing context. Summary of the Invention [Problem to be solved by the invention]

[0022] Embodiments of the present disclosure provide a mechanism to enable the (reselected) alternative server to appropriately perform different actions upon receiving a request message for an existing context from a client, and to enable the client to receive and store the rejection cause if the request message is rejected by the (reselected) alternative server to avoid further reselection for the same rejection cause. [Means for solving the problem]

[0023] According to a first aspect of the present disclosure, a method in a first network node (i.e., a client) for network node reselection for a context related to a service is provided, where the first network node has selected a second network node (i.e., a previously selected server) for providing a service consumed by the first network node, and a context related to the service is created. The method includes determining to reselect a third network node (i.e., an alternative server) capable of providing a service for the context that was provided by the second network node, where the request message includes property information related to the request message.

[0024] In an exemplary embodiment, the property information for the request message is: information indicating that the request message relates to reselection due to failure to reach the second network node; information indicating that the request message relates to a reselection due to overload control of the second network node; information indicating that the request message relates to a reselection due to a temporary rejection by the second network node during a last attempt to the second network node; Contains at least one of the following:

[0025] In an exemplary embodiment, overload control of the second network node is performed by the first network node based on overload information of the second network node, the overload information being indicated by an OCI received from the second network node; or the overload information being derived from a ratio of the number of request messages with a status code rejected by the second network node to the total number of request messages, the status code being received from the second network node indicating that the request message was rejected by the second network node.

[0026] In an exemplary embodiment, the property information regarding the request message further includes retransmission information indicating that the request message associated with the reselection was previously transmitted to the second network node.

[0027] In an exemplary embodiment, the retransmission information further includes a number of attempts to a second network node, where the first network node has sent a request message to the second network node, but the request message has been rejected by the second network node with a temporary cause code.

[0028] In an exemplary embodiment, property information about a request message is included in a new or existing custom header of the request message or in the message body of the request message.

[0029] In an exemplary embodiment, the first network node comprises: a fact that the first network node cannot reach the second network node; a first network node determining that a second network node is overloaded; a fact that the first network node has sent a request message to the second network node as an attempt, but the request message has been rejected by the second network node with a temporary cause code; and determining to reselect a third network node based on at least one of:

[0030] In an exemplary embodiment, the method further includes receiving a response message from the third network node corresponding to the request message, the response message including an indication of whether the request message was rejected or accepted by the third network node.

[0031] In an exemplary embodiment, if a response message is received including an indication that the request message has been rejected by the third network node, the response message further includes rejection cause information, and the rejection cause information is: the request message is currently rejected based on the fact that property information relating to the request message indicates that the request message relates to a reselection due to overload control of at least the second network node and / or the fact that the third network node is unable to retrieve the context from a database in which the context is stored; or the request message is rejected and subsequent request messages for a context related to the same service will be rejected based at least on the nature of the implementation of the service; Shows.

[0032] In an exemplary embodiment, the method further includes storing the rejection cause information contained in the received response message for later reselection decisions.

[0033] In an exemplary embodiment, the request message is an HTTP request message.

[0034] In an exemplary embodiment, the first network node acts as an HTTP client sending a request message; An NF service consumer; SCP and NF service producers; Contains at least one of the following:

[0035] In an exemplary embodiment, the second network node or the third network node acts as an HTTP server that responds to request messages; An NF service consumer; SCP and NF service producers; Contains at least one of the following:

[0036] According to a second aspect of the present disclosure, a method is provided in a third network node (i.e., an alternative server) for reselecting a network node for a context related to a service, wherein a first network node (i.e., a client) selects a second network node (i.e., a previously selected server) for providing a service consumed by the first network node and a context related to the service has been created. The method includes receiving a request message for the context from the first network node, the request message including property information related to the request message, determining whether to reject or accept the request message based at least on the property information related to the request message, and sending a response message to the first network node including an indication of whether the request message was rejected or accepted.

[0037] In an exemplary embodiment, the property information for the request message is: information indicating that the request message relates to reselection due to failure to reach the second network node; information indicating that the request message relates to a reselection due to overload control of the second network node; information indicating that the request message relates to a reselection due to a temporary rejection by the second network node during a last attempt to the second network node; Contains at least one of the following:

[0038] In an exemplary embodiment, overload control of the second network node is performed by the first network node based on overload information of the second network node, the overload information being indicated by an OCI received from the second network node; or the overload information being derived from a ratio of the number of request messages rejected by the second network node with a status code to the total number of request messages, the status code being received from the second network node indicating that the request message was rejected by the second network node.

[0039] In an exemplary embodiment, the property information regarding the request message further includes retransmission information indicating that the request message associated with the reselection was previously transmitted.

[0040] In an exemplary embodiment, the retransmission information further includes a number of attempts to a second network node where the first network node has sent a request message to the second network node, but the request message has been rejected by the second network node with a temporary cause code.

[0041] In an exemplary embodiment, property information about a request message is included in a new or existing custom header of the request message or in the message body of the request message.

[0042] In an exemplary embodiment, the third network node further comprises: The nature of the implementation of the requested service; the fact that the third network node is unable to retrieve the context from the database in which it is stored; The request message is rejected or accepted based on at least one of the following:

[0043] In an exemplary embodiment, if the third network node decides to reject the request message, it transmits a response message indicating that the request message has been rejected.

[0044] In an exemplary embodiment, the response message further includes rejection cause information, the rejection cause information being: the request message is currently rejected based on the fact that property information relating to the request message indicates that the request message relates to a reselection due to overload control of at least the second network node and / or the fact that the third network node is unable to retrieve the context from a database in which the context is stored; or the request message is rejected and subsequent request messages for a context related to the same service will be rejected based at least on the nature of the implementation of the service; Shows.

[0045] In an exemplary embodiment, the request message is an HTTP request message.

[0046] In an exemplary embodiment, the first network node acts as an HTTP client sending a request message; An NF service consumer; SCP and NF service producers; Contains at least one of the following:

[0047] In an exemplary embodiment, the second network node or the third network node acts as an HTTP server that responds to request messages; An NF service consumer; SCP and NF service producers; Contains at least one of the following:

[0048] According to a third aspect of the present disclosure, there is provided a first network node (i.e., client), comprising at least one processor and at least one memory storing instructions that, when executed on the at least one processor, cause the first network node to perform any of the methods according to the first aspect of the present disclosure.

[0049] According to a fourth aspect of the present disclosure, there is provided a third network node (i.e., an alternative server), the third network node including at least one processor and at least one memory storing instructions that, when executed on the at least one processor, cause the third network node to perform any of the methods according to the third aspect of the present disclosure.

[0050] According to a fifth aspect of the present disclosure, there is provided a computer readable storage medium storing computer program instructions which, when executed by at least one processor, cause the at least one processor to perform a method according to either the first or second aspect of the present disclosure.

[0051] The technical solutions of the embodiments of the present disclosure may achieve at least the following advantages: - if the third network node (i.e. the reselected server) is unable to proceed with the request message, the third network node is able to reject the received request message (as a result of the reselection) based at least on the reason triggering the reselection, e.g. failure to reach the second network node (i.e. the previously selected server), overload control of the second network node, or a temporary refusal from the second network node during the last attempt to reach the second network node; and - Providing a rejection cause for a third network node (i.e., a reselected server) rejecting a request message of the first network node (i.e., a client), thereby enabling the first network node to avoid further reselections due to the same rejection cause.

[0052] The objects, advantages and features of the present disclosure will become more apparent following the description of the preferred embodiments in conjunction with the drawings. [Brief description of the drawings]

[0053] [Figure 1] FIG. 2 shows a schematic diagram of an exemplary reselection process according to prior art solutions, triggered for example by an overload of a server 1 previously selected by a client. [Diagram 2] FIG. 2 illustrates a schematic diagram of a method at a first network node (i.e., a client) for network node reselection for an existing context, according to an exemplary embodiment of the present disclosure. [Diagram 3] FIG. 2 illustrates a schematic diagram of a method at a third network node (i.e., a reselected server) for network node reselection for an existing context, according to an exemplary embodiment of the present disclosure. [Figure 4] FIG. 2 illustrates a schematic diagram of an exemplary reselection process according to an exemplary embodiment of the present disclosure. [Diagram 5] 2 is a schematic block diagram of a first network node (i.e., a client) according to an exemplary embodiment of the present disclosure. [Figure 6] 4 is a schematic block diagram of a first network node (i.e., a client) according to another exemplary embodiment of the present disclosure. [Figure 7] 4 is a schematic block diagram of a third network node (i.e., a reselected server) according to an exemplary embodiment of the present disclosure. [Figure 8] 4 is a schematic block diagram of a third network node (i.e., a reselected server) according to another exemplary embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0054] It should be noted that the same or similar reference numbers are used throughout the drawings to denote the same or similar elements. The various portions of the drawings are not drawn to scale and are for illustrative purposes only, and therefore should not be understood as any limitation or restriction on the scope of the present disclosure.

[0055] The principles and spirit of the present invention will now be described with reference to exemplary embodiments. Some of the embodiments contemplated herein will be described more fully with reference to the accompanying drawings. However, other embodiments are included within the scope of the subject matter disclosed herein, and the subject matter disclosed should not be construed as being limited to only the embodiments described herein, but rather, these embodiments are provided as examples to convey the scope of the subject matter to those skilled in the art.

[0056] Those skilled in the art will appreciate that the term "exemplary" is used herein to mean "exemplary" or "serving as an example" and is not intended to suggest that a particular embodiment is preferred over other embodiments or that a particular feature is essential. Similarly, the terms "first" and "second" and similar terms are used merely to distinguish one particular instance of an item or function from another and do not imply a particular order or arrangement unless the context clearly indicates otherwise. Furthermore, the term "step" as used herein is meant to be synonymous with "operation" or "action." The description of a sequence of steps herein does not imply that these operations must be performed in a particular order, and these operations may be performed in any order unless the context or details of the described operations clearly dictate otherwise.

[0057] References herein to "one embodiment," "an embodiment," "an exemplary embodiment," or the like indicate that the described embodiment may include a particular feature, structure, or characteristic, but not all embodiments need include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Moreover, when a particular feature, structure, or characteristic is described in connection with an embodiment, implementing such feature, structure, or characteristic in connection with other embodiments is presented as being within the knowledge of one of ordinary skill in the art, whether or not explicitly stated.

[0058] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. The singular forms are intended to include the plural forms unless the context clearly indicates otherwise. As used herein, the terms "including," "having," "comprising," and the like specify the presence of stated features, elements, and / or components, but do not exclude the presence of one or more other features, elements, components, and / or combinations thereof.

[0059] As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed terms.

[0060] In the following description and claims, unless defined otherwise, all technical and scientific terms used have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.

[0061] As used herein, the term "network" refers to a network conforming to any suitable (wireless or wired) communications standard. For example, wireless communications standards may include New Radio (NR), Long Term Evolution (LTE), LTE Advanced, Wideband Code Division Multiple Access (WCDMA), High Speed ​​Packet Access (HSPA), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single Carrier Frequency Division Multiple Access (SC-FDMA), and other wireless networks. A CDMA network may implement a radio technology such as Universal Terrestrial Radio Access (UTRA). UTRA includes WCDMA and other variants of CDMA. A TDMA network may implement a radio technology such as Global System for Mobile Communications (GSM). An OFDMA network may implement wireless technologies such as Evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDMA, ad-hoc networks, wireless sensor networks, etc. In the following description, the terms "network" and "system" may be used interchangeably.

[0062] Furthermore, communication between two devices in a network may be performed according to any suitable communication protocol, including, but not limited to, a wired communication protocol or a wireless communication protocol defined by a standards organization such as 3GPP. For example, the wireless communication protocol may include first generation (1G), 2G, 3G, 4G, 4.5G, 5G communication protocols, and / or other protocols now known or developed in the future.

[0063] The term "network node" as used herein refers to a device in a wireless communication network through which a terminal device or another network node accesses the network and receives services therefrom. A network node may refer to a NF, a base station (BS), an access point (AP), or any other suitable device in a wireless communication network. A BS may be, for example, a Node B (Node B or NB), an evolved Node B (eNode B or eNB), a gNB, a remote radio unit (RRU), a radio header (RH), a remote radio head (RRH), a relay, a femto, a pico, or other low power node. Further examples of network nodes may include multi-standard radio (MSR) radio equipment such as an MSR BS, a network controller such as a radio network controller (RNC) or a base station controller (BSC), a base transceiver station (BTS), a transmission point, a transmitting node, or the like. However, more generally, a network device may refer to any suitable device (or group of devices) operable to configure, arrange, enable, and / or provide terminal device access to a wireless communication network or provide some service to a terminal device accessing a wireless communication network.

[0064] The term UE refers to any end device that can access and be served by a wireless communication network. By way of non-limiting example, UE refers to a mobile terminal, a terminal device, or other suitable device. A UE may be, for example, a subscriber station (SS), a mobile subscriber station (MS), or an access terminal (AT), a relay node. A UE may include, but is not limited to, a portable computer, an image capture terminal device such as a digital camera, a gaming terminal device, a music storage and playback device, a mobile phone, a cellular phone, a smartphone, a voice over IP (VoIP) phone, a wireless local loop phone, a tablet, a wearable device, a personal digital assistant (PDA), a portable computer, a desktop computer, an image capture terminal device such as a digital camera, a gaming terminal device, a music storage and playback device, a wearable terminal device, a vehicle-mounted wireless terminal device, a wireless endpoint, a mobile station, a laptop embedded equipment (LEE), a laptop mounted equipment (LME), a USB dongle, a smart device, a wireless customer premises equipment (CPE), and the like. In the following description, the terms "terminal device", "terminal", "user equipment" and "UE" may be used interchangeably. As an example, a terminal device may represent a UE configured to communicate according to one or more communications standards promulgated by the 3rd Generation Partnership Project (3GPP), such as 3GPP's GSM, UMTS, LTE, and / or 5G standards. As used herein, "user equipment" or "UE" does not necessarily have a "user" in the sense of a human user who owns and / or operates the associated device. In some embodiments, a terminal device may be configured to transmit and / or receive information without direct human interaction. For example, a terminal device may be designed to transmit information to a network on a predefined schedule, when triggered by an internal or external event, or upon request from a wireless communication network. Instead, a UE may represent a device intended for sale to or operation by a human user, but not initially associated with a particular human user.

[0065] As yet another example, in an Internet of Things (IoT) scenario, a UE may represent an appliance or other device that performs monitoring and / or measurements and transmits results of such monitoring and / or measurements to another terminal device and / or network equipment. In this case, the UE is a machine-to-machine (M2M) device, which may be referred to as an MTC device in the 3GPP context. As one particular example, the UE may be a terminal device that implements the 3GPP NB-IoT standard. Particular examples of such appliances or devices are sensors, metering devices such as power meters, industrial machines, or household appliances such as refrigerators, televisions, personal wearables such as watches, etc. In other scenarios, the UE may represent a vehicle or other appliance that can monitor and / or report its operating state or other functions related to its operation.

[0066] The present disclosure applies to a scenario in which a client selects a server (e.g., Server 1) to provide a service consumed by the client and a context related to that service is created, but due to some reason on Server 1, the client needs to reselect an alternative server (e.g., Server 2) that is located in the same set as the location of Server 1.

[0067] In conjunction with the exemplary reselection process of Fig. 1, the embodiment of the present disclosure may be considered to be applied under the condition that steps S1_1 to S1_7 of the reselection process shown in Fig. 1 are performed. In particular, the embodiment of the present disclosure may improve steps S1_9 to S1_10 of the reselection process shown in Fig. 1.

[0068] As mentioned above, it should be noted that although Fig. 1 only shows the overload of server 1 as an exemplary reason for triggering the re-selection process, there may be other reasons for triggering the re-selection process, such as server 1 being unreachable, or server 1 rejecting the client's request message for a temporary reason, etc. Any suitable reason for triggering the re-selection process is applicable to the embodiments of the present disclosure.

[0069] The basic idea of ​​this disclosure is mainly: 1) Include property information in a request message (e.g., an HTTP request message) from the client to the alternative server 2. The property information regarding the request message may include information indicating that the request message is related to context reselection due to failure to reach server 1, information indicating that the request message is related to context reselection due to overload control of server 1, information indicating that the request message is related to context reselection due to being temporarily rejected by server 1 during a last attempt to reach server 1, retransmission information indicating that the request message related to the reselection has been resent, etc. Thus, server 2 can reject a received request message based at least on the property information regarding the request message. 2) If the request message is rejected by the server 2, the server 2 includes rejection cause information in the response message to the client. The rejection cause information may indicate that the request message related to server reselection for the context is not supported due to the nature of the implementation of the requested service, or that the server 2 cannot retrieve the context from the database where the context is stored. Therefore, the client can store the received rejection cause information to avoid further reselection for the same rejection cause.

[0070] An embodiment of the present invention will now be described by way of example with reference to FIGS.

[0071] A method 200 for network node reselection for an existing context in a first network node (i.e., a client) according to an exemplary embodiment of the present disclosure will now be described with reference to Fig. 2. It should be understood that the first network node as a client may be an NF service consumer, e.g., an SCP for a normal request message, an NF service producer for a notification request message, or the like in other future developments that send a request message (such as an HTTP request message).

[0072] As described above, method 200 is performed in a scenario where a first network node (i.e. a client) has selected a second network node (i.e. a previously selected server, e.g. Server 1) for providing a service consumed by the first network node and a context associated with the service has been created, but due to some reason at the second network node (described below), the first network node needs to reselect an (alternative) third network node (e.g. Server 2) within the same set as the second network node.

[0073] Accordingly, the second or third network node that receives the request message is referred to as a "server", which may refer to an NF service producer, an SCP, an NF service consumer, or the like in other future developments in appropriate scenarios. For example, an NF service consumer (as a client) can use a service provided by an NF service producer (as a server).

[0074] As shown in FIG. 2, the method 200 may include at least steps S201 and S203.

[0075] In step S201, the first network node (i.e., the client) may decide to reselect a third network node within the set in which the second network node is located that can provide services for the context that was being provided by the second network node.

[0076] In an exemplary embodiment, in order to address an existing context related to a service provided by a second network node, e.g. upon receiving a request message from an upstream network node or a UE, a first network node may: The fact that a first network node, which can for example be probed using "PING", is unable to reach a second network node, e.g. the fact that the first network node is unable to reach the original resource Uniform Resource Identifier (URI) if the second network node is an NF producer, or the fact that the notification / callback URI is unable to be reached if the second network node is an NF consumer, the first network node has determined that the second network node is overloaded, for example by receiving from the second network node an OCI indicating overload information of the second network node, as specified in "Client side adaptive throttling for overload control" in Annex A of 3GPP TS 29.500 V17.1.0, which is incorporated herein by reference in its entirety, or by receiving from the second network node a status code (e.g. 429 / 503) indicating that a request message has been rejected by the second network node and deriving the overload information of the second network node from a ratio of the number of request messages rejected by the second network node with a status code to the total number of request messages, - the fact that the first network node has sent a request message to the second network node as an attempt, but the request message has been rejected by the second network node with a temporary cause code; The method may determine that reselection is necessary based on at least one of:

[0077] Because the context is stored in a common central database, e.g., a UDSF for the same set, that can be accessed by all network nodes of the set, the first network node may reselect a third network node that is located in the same set where the second network node is located.

[0078] Then, in step S203, the first network node may send a request message for a context associated with the service to the third network node. In particular, a request message may be sent for each context associated with the service (e.g., per UE or per Packet Data Unit (PDU) session), and a service may be associated with at least one context. References to "a context" or "the context" throughout this disclosure do not exclude multiple contexts.

[0079] The request message may include property information regarding the request message.

[0080] Preferably, the property information regarding the request message is: -information indicating that the request message relates to a reselection due to failure to reach the second network node; -information indicating that the request message relates to a reselection due to overload control of the second network node; - information indicating that the request message relates to a reselection resulting from a temporary rejection by the second network node during a last attempt to the second network node; It may include at least one of the following:

[0081] If the property information on the request message includes information indicating that the request message is related to a reselection due to overload control for the second network node, the overload control for the second network node may be performed by the first network node based on the overload information of the second network node. The overload information may be indicated by an OCI received from the second network node, or the overload information may be derived from a ratio of the number of request messages rejected by the second network node with a status code (e.g., 429 / 503) to the total number of request messages. The status code (e.g., 429 / 503) may be received from the second network node and indicate that the request message was rejected by the second network node.

[0082] Alternatively or additionally, the property information regarding the request message may further include retransmission information indicating whether a request message related to the reselection has been previously transmitted to the second network node, i.e., whether the first network node has attempted to transmit the request message. For example, a Boolean parameter ("true" or "false") may be used.

[0083] If the retransmission information is, for example, true, i.e. indicating that a request message related to the reselection was previously sent to the second network node, the retransmission information further includes a number of attempts to the second network node, in which case the first network node sent a request message to the second network node, but the request message was rejected by the second network node with a temporary cause code.

[0084] For example, as a first attempt, the first network node as a client may send a request message for context to a second network node, e.g., Server 1, and as a second attempt, may send a request message for context to a third network node, e.g., Server 2. Then, the first network node may make a third attempt, e.g., send a request message for context to the third network node or another network node. Here, since the first network node has tried twice, the request message may include a retry count ("2" in this example) in the property information.

[0085] The property information about the request message may be included in a new or existing custom header of the request message or in the message body of the request message.

[0086] The request message including the associated property information as described above may be received by a third network node which may determine, based at least on the property information received in the request message, whether the request message should be rejected or accepted and may send a response message to the first network node including an indication as to whether the request message was rejected or accepted, as will be described in more detail below with reference to FIG.

[0087] Thus, in the method 200, the first network node may receive a response message from the third network node corresponding to the request message. The response message may include an indication of whether the request message was rejected or accepted by the third network node.

[0088] When a response message is received including an indication that the request message is rejected by the third network node, the response message may further include rejection cause information, for example, the rejection cause information may be defined as a specific format of a cause code.

[0089] The rejection cause information received in the response message indicates to the first network node that the request message for the context is currently rejected and that the first network node may try again later, based on facts indicated by, for example, property information regarding the request message, which indicates that the request message relates to a reselection due to overload control of at least the second network node and / or that, for example, the context is locked by the second network node and therefore the third network node cannot retrieve the context from the database in which it is stored, i.e. the rejection is only valid for this request message.

[0090] For example, a (session) context in the UDSF may be locked by SMF1 while SMF1 is processing a request message for a session from a peer NF, e.g., PCF, and at the same time, another peer NF, e.g., AMF, may try to connect to this overloaded SMF1 for the same context. In such a scenario, AMF (as an example of a first network node) may decide to reselect an alternative SMF, i.e., SMF2 (as an example of a third network node), since it knows that SMF1 (as an example of a second network node) is overloaded. Thus, when the alternative SMF2 (as an example of a third network node) receives the request message and knows that the corresponding context is locked by SMF1 (as an example of a second network node), SMF2 (as an example of a third network node) rejects the request message and sends such rejection cause information based on the above facts in order to prevent AMF from redirecting the request message to the overloaded SMF1 (as an example of a second network node).

[0091] Alternatively or additionally, the rejection cause information received in the response message may indicate to the first network node that the request message is rejected and that subsequent request messages for contexts related to the same service are rejected based at least on the nature of the implementation of the service, i.e. the first network node should essentially not reselect the third network node for request messages for contexts related to the same service based on the nature of the implementation of the requested service.

[0092] For example, in case of an overloaded AMF (as an example of a second network node), if an alternative AMF (as an example of a third network node) is selected for a Namf_communication service, such as N1N2 message forwarding as a service action, the alternative AMF (as an example of a third network node) may page the UE. However, when the UE responds to the paging, the UE still initiates a service request towards the overloaded AMF (as an example of a second network node). Thus, the alternative AMF (as an example of a third network node) rejects the request message and sends such rejection cause information based on the nature of the implementation of the requested service.

[0093] Preferably, the first network node may store the rejection cause information included in the received response message for later reselection decisions.

[0094] A method 300 for network node reselection for an existing context in a third network node (i.e., a reselected server) according to an exemplary embodiment of the present disclosure will now be described with reference to FIG. 3. It should be understood that the first network node as a client may be an NF service consumer, e.g., an SCP for a normal request message, an NF service producer for a notification request message, or the like in other future developments that send a request message (such as an HTTP request message), and accordingly, the second or third network node that receives the request message is referred to as a "server", which may refer to an NF service producer, an SCP, an NF service consumer, or the like in other future developments in appropriate scenarios. For example, an NF service consumer (as a client) can use a service provided by an NF service producer (as a server).

[0095] It should also be understood that the method 300 in the third network node corresponds to the method 200 in the first network node described above. Therefore, some of the description of the method 300 will be omitted for brevity, with reference to the description of the method 200.

[0096] As mentioned above, the method 300 is performed in a scenario where a first network node (i.e. a client) selects a second network node (i.e. a previously selected server, e.g. Server 1) for providing a service consumed by the first network node, and a context related to the service has been created, but due to some reason at the second network node (as described above with reference to FIG. 2 ), the first network node needs to reselect an (alternative) third network node (e.g. Server 2) in the same set as the second network node, and the first network node then decides to select a third network node that can provide the service for the context that was being provided by the second network node.

[0097] As shown in FIG. 3, the method 300 may include at least steps S301, S303, and S305.

[0098] In step S301, the third network node may receive a request message for a context from the first network node, The request message may include property information related to the request message.

[0099] Preferably, the property information regarding the request message is: - information indicating that the request message relates to a reselection due to failure to reach the second network node; - information indicating that the request message relates to a reselection due to overload control of the second network node; - information indicating that the request message relates to a reselection due to a temporary rejection by the second network node during a last attempt to the second network node; It may include at least one of the following:

[0100] Alternatively or additionally, the property information regarding the request message may further include retransmission information indicating whether a request message related to the reselection has been previously transmitted to the second network node, i.e., whether the first network node has attempted to transmit the request message. For example, a Boolean parameter ("true" or "false") may be used.

[0101] If the retransmission information is, for example, "true", i.e. indicating that a request message related to the reselection was previously sent to the second network node, the retransmission information further includes a number of attempts to the second network node, in which case the first network node sent a request message to the second network node, but the request message was rejected by the second network node with a temporary cause code.

[0102] For example, a first network node as a client may send a request message for context to a second network node, e.g., Server 1, as a first attempt, and send a request message for context to a third network node, e.g., Server 2, as a second attempt. Then, the first network node may send a third attempt, e.g., a request message for context to the third network node or another network node. Here, since the first network node has already tried twice, the request message may include the number of retries ("2" in this example) in the property information.

[0103] The property information about the request message may be included in a new or existing custom header of the request message or in the message body of the request message.

[0104] In step S303, the third network node may determine whether to reject or accept the request message based at least on the property information regarding the request message.

[0105] Preferably, the third network node may decide whether to reject or accept the request message based on at least one of property information regarding the request message, the nature of the implementation of the requested service, and the fact that the third network node is unable to retrieve the context from a database in which the context is stored.

[0106] For example, the third network node may decide to reject the request message based on the received property information indicating that the request message is related to a reselection due to overload control of the second network node and based on the fact that the third network node cannot retrieve the context from the database in which the context is stored because the context is locked by the second network node, i.e. the rejection is only valid for this request message. As a specific example of this case, it is possible that SMF1 is processing a request message for a session from a peer NF, e.g. PCF, so that the (session) context in the UDSF is locked by this SMF1, and at the same time another peer NF, e.g. AMF, tries to connect to this overloaded SMF1 for the same context. In such a scenario, the AMF (as an example of the first network node) may decide to reselect an alternative SMF, i.e. SMF1 (as an example of the third network node), since it knows that SMF1 (as an example of the second network node) is overloaded. Therefore, if an alternative SMF2 (as an example of a third network node) receives a request message and knows that the corresponding context is locked by SMF1 (as an example of a second network node), SMF2 (as an example of a third network node) will reject the request message and send such rejection cause information based on the above facts in order to prevent the AMF from redirecting the request message to the overloaded SMF1 (as an example of a second network node).

[0107] In another example, the third network node may decide to reject the request message based on the received property information indicating that the request message is related to reselection due to overload control of the second network node and the nature of the implementation of the service. Thus, the third network node always rejects the request message for a context related to the same service due to the nature of the implementation of the requested service. As a specific example of this case, in case of an overloaded AMF (as an example of the second network node), if an alternative AMF (as an example of the third network node) is selected for, for example, a Namf_communication service with N1N2Message forwarding as a service action, the alternative AMF (as an example of the third network node) may page the UE. However, when the UE responds to the paging, the UE still initiates a service request towards the overloaded AMF (as an example of the second network node). Thus, the alternative AMF (as an example of the third network node) always rejects the request message for a context related to the same service due to the nature of the implementation of the requested service.

[0108] In step S305, the third network node may send a response message to the first network node including an indication of whether the request message was rejected or accepted.

[0109] As discussed above in step S303, if the third network node determines to reject the request message, the third network node may send a response message including an indication of the rejection of the request message.

[0110] In this case, the response message may further include rejection cause information, which may be defined as a specific format of a cause code, for example.

[0111] As mentioned above with reference to figure 2, the rejection cause information indicates to the first network node that the request message for the context is currently rejected and that the first network node may try again later, based for example on facts indicated by property information regarding the request message that the request message relates to a reselection due at least to overload control of the second network node and / or that the third network node cannot retrieve the context from the database in which it is stored, for example because the context is locked by the second network node, i.e. the rejection is only valid for this request message.

[0112] Alternatively or additionally, the rejection cause information may indicate to the first network node that the request message is rejected and that subsequent request messages for contexts related to the same service are rejected based at least on the nature of the implementation of the service, i.e., the rejection cause information may indicate to the first network node that the first network node should essentially not reselect the third network node for request messages for contexts related to the same service based on the nature of the implementation of the requested service.

[0113] Hereinafter, with reference to FIG. 4, a signaling sequence diagram of a reselection process according to an embodiment of the present invention will be described, in which the method 200 in a first network node and the method 300 in a third network node for network node reselection according to an exemplary embodiment of the present disclosure are applied.

[0114] It should be noted that the following description focuses primarily on the signaling associated with methods 200 and 300, and other signaling, such as steps S4_1 to S4_7, which may be similar to steps S1_1 to S1_7 of the reselection process shown in Figure 1, is not described in detail to avoid obscuring the principles of the present disclosure. In Figure 4, modifications of the signaling associated with methods 200 and 300 are shown in bold italics and include steps S4_9 to S4_11.

[0115] During steps S4_1 to S4_7, the client has selected, in this example, server 1 for providing service A consumed by the client, and a context related to service A has been created. However, some events related to server 1 occur, e.g., server 1 is overloaded, server 1 is unreachable, or server 1 rejects the client's request message due to temporary causes, etc.

[0116] At S4_8, the client may receive a request message for a (resource) context related to Server 1, for example from an upstream NF or UE. The client may determine that reselection of an alternative server is necessary based on at least one of the following facts: - The fact that the client cannot reach Server1, this can be probed using for example "PING". For example, if Server1 is an NF producer, the client cannot reach the original resource integration resource identifier (URI), and if Server1 is an NF consumer, the notification / callback URI is not reachable. the fact that the client 1 has determined that the server 1 is overloaded, for example by receiving from the second network node an OCI indicating the overload information of the second network node, or by receiving from the second network node a status code (e.g., 429 / 503) indicating that a request message has been rejected by the second network node, and deriving the overload information of the second network node from the ratio of the number of request messages rejected by the second network node with a status code to the total number of request messages, as specified in "Client-side Adaptive Throttle for Overload Control" in Appendix A of 3GPP TS 29.500 V17.1.0, which is incorporated herein by reference in its entirety; - The fact that the client sent a request message to Server 1 as an attempt, but the request message was rejected by Server 1 with a temporary cause code

[0117] Because the context is stored in a common central database, e.g., a UDSF for the same set that can be accessed by all servers in the set, the client can reselect server 2 that is located in the same set where server 1 is located.

[0118] At S4_9, the client may send a request message for the context (e.g., an Nnfp_serviceA operation request) to the server 2. The request message may include property information about the context, which may include: - information indicating that the request message relates to a reselection due to failure to reach server 1; - information indicating that the request message relates to a reselection due to overload control of server 1; - information indicating that the request message relates to a reselection due to a temporary rejection by server 1 during a last attempt to contact server 1; It may include at least one of the following:

[0119] The property information regarding the request message may further include retransmission information indicating whether the request message associated with the reselection has been previously sent to the server 1, i.e., whether the client has attempted to send the request message. For example, a Boolean parameter ("true" or "false") may be used.

[0120] If the retransmission information is, for example, true, i.e., indicates that a request message related to the reselection was previously sent to server 1, the retransmission information further includes the number of attempts to server 1, in which case the client sent a request message to server 1, but the request message was rejected by server 1 with a temporary cause code.

[0121] Server 2 may decide to reject or accept the request message based at least on property information about the request message, based on at least one of the following: property information about the request message, the nature of the implementation of the requested service A, or the fact that Server 2 is unable to obtain the context from the database in which the context is stored.

[0122] For example, Server 2 may decide to reject the request message based on received property information indicating that the request message is related to a reselection due to overload control of Server 1 and the fact that Server 2 cannot retrieve the context from the database where it is stored, for example because the context is locked by Server 1. That is, the rejection is only valid for this request message.

[0123] As another example, Server 2 may decide to reject the request message based on the received property information indicating that the request message is related to reselection due to overload control of Server 1 and the nature of the implementation of Service A. That is, Server 2 always rejects request messages for contexts related to the same Service A due to the nature of the implementation of the requested Service A.

[0124] If the server 2 decides to reject the request message, the server 2 may include corresponding rejection cause information in the response message.

[0125] The rejection cause information indicates to the client that the request message for the context is currently rejected and that the client may try later based on facts indicated by the property information about the request message that indicate that the request message is related to a reselection due to at least Server 1's overload control and / or that Server 2 cannot retrieve the context from the database in which it is stored because the context is locked by Server 1. In other words, the rejection is only valid for this request message.

[0126] Alternatively or additionally, the rejection cause information may indicate to the client that the request message was rejected and that subsequent request messages for contexts related to the same service A will be rejected based at least on the nature of the implementation of service A. That is, the rejection cause information may indicate to the client that the client should essentially not reselect server 2 for request messages for contexts related to the same service A based on the nature of the implementation of the requested service A.

[0127] Next, at S4_10, the server 2 may send a response message (such as Nnfp_service_operation_response) to the client. The response message may include an indication that the request message was accepted (e.g., "accepted"). Alternatively, the response message may include an indication that the request message was rejected (e.g., "rejected") and a corresponding reason for the rejection, as described above.

[0128] After the request message is rejected and a response message is received with an indication of the corresponding rejection cause, at S4_11, the client may store the rejection cause information included in the received response message to avoid further reselection of server 2 with the same rejection cause.

[0129] The exemplary procedure as shown in FIG. 4 is related to changes in the following sections of, for example, 3GPP TS29.500 V17.1.0, where the changes are underlined:

[0130] [Table 1]

[0131] 5.2.3.3 Options for supporting custom headers 5.2.3.3.1 General 3GPP NF services may support the HTTP custom headers specified in Table 5.2.3.3-1 below, which provides a description of each custom header and normative requirements regarding when they may be included.

[0132] [Table 2]

[0133] [Table 3]

[0134] 5.2.3.2.x 3gpp-Sbi-Request-Property The header contains additional information related to the HTTP request message, for example, if the HTTP request message is to address an existing resource / session context and if the HTTP request is to be redirected towards an alternative NF. The encoding of the header follows the ABNF defined in IETF RFC7230

[12] . 3gpp-Sbi-Request-Property = "3gpp-Sbi-Request-Property”":”OWS"retrans=” retransvalue1*(";”OWSparameter[(";”OWSreceivedrejectioncause]) Retransvalue = "true” / "false” parameter "=” parametername"=”token Parametername = "reason” Reason = "reason” = OWScause The following parameters are defined: Reason: indicates the reason why the NF retransmits or redirects the HTTP request message. It can have one of the following values: - "unreachable": indicates that the requested URI (e.g., resource URI or notification / callback URI) is unreachable and the HTTP request is redirected to an alternative NF; - "overlarded": indicates that the HTTP request is redirected to an alternative NF as a result of the application of overload controls by performing a redirection to an alternative NF (see Section 6.4.3.5.1); - "temporary-rejection-cause": indicates that due to a temporary rejection the HTTP request will be resent to the same or an alternative NF. -receivedrejectioncause: When retransvalue is set to "true" and reason is set to "temporary-rejection-cause", it indicates the temporary rejection cause (last attempt) received from the NF, as defined in clause 5.2.7.2. The cause data type is specified in clause 5.2.4.1 of 3GPP TS 29.571

[13] .

[0135] [Table 4]

[0136] The service-based interface uses HTTP / 2 over TCP for communication between NF services. TCP provides transport-level congestion control mechanisms as specified in IETF RFC5681

[16] , which can be used for congestion control between two TCP endpoints (i.e., per-hop). HTTP / 2 also provides configurable flow control mechanisms and stream concurrency limits for connection-level congestion control, as specified in IETF RFC7540[7]. In addition to the TCP and HTTP / 2 congestion control mechanisms, the following end-to-end application-level overload control mechanisms are defined: The overload control can gracefully reduce the receiving signalling load of an overloaded NF service producer, NF service consumer or SCP by instructing NF service consumers to reduce the sending of service requests or instructing NF service producers to reduce the sending of notification requests, respectively, depending on the signalling capacity available to successfully process the requests. An NF service producer, NF service consumer or SCP becomes overloaded when it operates beyond its signalling capacity. When instructed by an NF service consumer to apply overload control, signaling reduction should be performed only for notifications or callback requests that correspond to the overload range to the NF service consumer, not for NF services that may be generated by the same NF (different OCIs may be advertised by the NF when acting as an NF producer), even if the overload range is at the NF instance level or NF set level. Overload control generally aims to block incoming traffic as close as possible to the traffic source when an overload occurs (reactive), thus avoiding the problem propagating within the network and avoiding the resources of intermediate entities in the network being used for signaling that cannot be serviced by the overloaded entity. Overload control should continue to allow preferential treatment for priority users (such as MPS) and emergency services. Overload control can be performed based on the HTTP status code (defined in Section 6.4.2) returned in an HTTP response, or based on the Overload Control Information (OCI) (defined in Section 6.4.2) signaled in an HTTP request or response. An overload control enforcing NF will throttle some of the request messages or redirect some of them to alternative NFs if possible in order to reduce the transmission of HTTP requests to an overloaded NF (see clause 6.4.3.5).

[0137] [Table 5]

[0138] As part of the overload relief, Overload control implementation NF, i.e., An entity receiving an OCI (with a non-null overload reduction metric) reduces the total number of request messages that would be sent towards overloaded peers corresponding to the receiving range, e.g., towards all NF instances of the NF set if the range indicates an NF set ID, and does not redirect requests to another entity belonging to the same range. This is proportional to the peer's overload level. Need This is achieved by discarding some of the request messages, called throttling of request messages. Alternatively, if the reselection binding entity is larger than the overload range, it may redirect part of the request message to an alternative NF if possible. When redirecting a request to an alternative NF to address existing resources / session context, the NF may include a 3gpp-Sbi-Request-Property header indicating that the request is redirected to an alternative NF as a result of an overload enforcement, see clause (5.2.3.2.x). Message throttling applies only to HTTP requests (any service request, including notification requests). Network functions shall support and use the "lossy" algorithm specified in Section 6.4.3.5.2.

[0139] [Table 6]

[0140] 6.4.3.5.2 Loss Algorithm An overloaded NF service producer / consumer / SCP may request its peers to reduce the number of HTTP requests they send, or may convey the requested traffic reduction percentage in the Overload Reduction Metric parameter in the OCI header as specified in 6.4.3.4.3. The receiver of the overload reduction metric SHOULD reduce the number of request messages by that percentage, if possible, by redirecting to an alternate destination, or by failing the request and treating it as if it had been rejected by the destination entity (e.g., if the olcScope is at the NF instance level and the service resource binding indication is for an SMF set, then an HTTP POST request for the Nsmf_PDUSession_CreateSMContext service operation can be sent to an alternative SMF in the same SMF set). NOTE: For example, if an NF service producer / consumer / SCP requests a peer to reduce its traffic by 10%, the peer will throttle 10% of the traffic that would otherwise be sent to this NF service producer / consumer / SCP.

[0141] [Table 7]

[0142] Hereinafter, the structure of a first network node according to an exemplary embodiment of the present disclosure will be described with reference to Fig. 5. Fig. 5 is a schematic block diagram of a node 500 according to an exemplary embodiment of the present disclosure. The first network node 500 in Fig. 5 may execute the method 200 described above with reference to Fig. 2. Therefore, a detailed description of the first network node 500 may refer to the corresponding description of the method 200 in Fig. 2 and the signaling sequence diagram in Fig. 4 described above, and thus will be omitted here for brevity.

[0143] As mentioned above, it should be understood that the first network node as a client may be an NF service consumer, e.g., an SCP for normal request messages, an NF service producer for notification request messages, or the like in other future developments that send a request message (such as an HTTP request message), and accordingly, the second or third network node that receives the request message is referred to as a "server", which may refer to an NF service producer, an SCP, an NF service consumer, or the like in other future developments in appropriate scenarios. For example, an NF service consumer (as a client) can use a service provided by an NF service producer (as a server).

[0144] As shown in FIG. 5 , the first network node 500 may include: a determining unit 501 and a sending unit 503.

[0145] The determining unit 501 may be configured to determine to reselect a third network node that can provide services for the context that was being provided by the second network node.

[0146] Preferably, the determining unit 501 comprises: the fact that the first network node 500 is unable to reach the second network node; and the first network node 500 has determined that the second network node is overloaded; and the fact that the first network node 500 has sent a request message to the second network node as an attempt, but the request message has been rejected by the second network node with a temporary cause code; The network may be configured to determine to reselect the third network node based on at least one of:

[0147] The sending unit 503 is configured to send a request message for the context to a third network node, where the request message may include property information related to the request message.

[0148] As mentioned above, the property information for the request message is - information indicating that the request message relates to a reselection due to failure to reach the second network node; - information indicating that the request message relates to a reselection due to overload control of the second network node; - information indicating that the request message relates to a reselection resulting from a temporary rejection by the second network node during a last attempt to the second network node; Contains at least one of the following:

[0149] In one embodiment, the first network node 500 may further include an overload control unit (not shown) for performing overload control of the second network node based on the overload information of the second network node.

[0150] The overload information may be indicated by an OCI received from the second network node, or may be derived from a ratio of the number of request messages rejected by the second network node to the total number of request messages, the status code being received from the second network node indicating that the request messages were rejected by the second network node.

[0151] In an example embodiment, the property information regarding the request message may further include retransmission information indicating that the request message related to the reselection was previously transmitted to the second network node.

[0152] Alternatively or alternatively, the retransmission information further includes a number of attempts to the second network node where the first network node 500 has sent a request message to the second network node but the request message has been rejected by the second network node with a temporary cause code.

[0153] In an exemplary embodiment, the first network node 500 further comprises a receiving unit (not shown) which may be configured to receive a response message corresponding to the request message from the third network node, the response message including an indication of whether the request message has been rejected or accepted by the third network node.

[0154] If a response message is received that includes an indication that the request message has been rejected by the third network node, the response message may further include rejection cause information. the request message is currently rejected based on the fact that property information relating to the request message indicates that the request message relates to a reselection due at least to overload control of the second network node and / or the fact that the third network node is unable to retrieve the context from a database in which the context is stored, or - the request message is rejected and subsequent request messages for a context related to the same service will be rejected based at least on the nature of the implementation of the service; Shows.

[0155] Alternatively or additionally, the first network node 500 may further comprise a storage unit (not shown) configured to store the rejection cause information included in the received response message for subsequent reselection decisions.

[0156] Hereinafter, a structure of a first network node according to another embodiment of the present disclosure will be described with reference to Fig. 6. Fig. 6 is a schematic block diagram of a first network node 600 according to an exemplary embodiment of the present disclosure. The first network node 600 in Fig. 6 may execute the method 200 described above with reference to Fig. 2. Therefore, a detailed description of the first network node 600 may refer to the corresponding description of the method 200 in Fig. 2 and the signaling sequence diagram in Fig. 4 described above, and thus will be omitted here for brevity.

[0157] As mentioned above, it should be understood that the first network node as a client may be an NF service consumer, e.g., an SCP for normal request messages, an NF service producer for notification request messages, or the like in other future developments that send a request message (such as an HTTP request message), and accordingly, the second or third network node that receives the request message is referred to as a "server", which may refer to an NF service producer, an SCP, an NF service consumer, or the like in other future developments in appropriate scenarios. For example, an NF service consumer (as a client) can use a service provided by an NF service producer (as a server).

[0158] As shown in Figure 6, the first network node 600 includes at least one processor 601 and at least one memory 603. The at least one processor 601 includes, for example, any suitable CPU (Central Processing Unit), microcontroller, DSP (Digital Signal Processor), etc. capable of executing computer program instructions. The at least one memory 603 may be any combination of RAM (Random Access Memory) and ROM (Read Only Memory). The at least one memory 603 may also include persistent storage, which may be, for example, any one or combination of magnetic, optical, solid state, or remotely mounted memory.

[0159] The at least one memory 603 stores instructions executable by the at least one processor 601. The instructions, when loaded from the at least one memory 603 and executed on the at least one processor 601, may cause the first network node 600 to perform actions of procedures, such as those described above in relation to Figures 2 and 4, respectively, which are omitted here for the sake of brevity.

[0160] Hereinafter, the structure of a third network node according to an embodiment of the present invention will be described with reference to Fig. 7. Fig. 7 is a schematic block diagram of a third network node 700 according to an exemplary embodiment of the present disclosure. The third network node 700 in Fig. 7 may perform the method 300 described above with reference to Fig. 3. Therefore, a detailed description of the third network node 700 may refer to the corresponding description of the method 300 in Fig. 3 and the signaling sequence diagram in Fig. 4 described above, and thus will be omitted here for brevity.

[0161] As mentioned above, it should be understood that the first network node as a client may be an NF service consumer, e.g., an SCP for normal request messages, an NF service producer for notification request messages, or the like in other future developments that send a request message (such as an HTTP request message), and accordingly, the second or third network node that receives the request message is referred to as a "server", which may refer to an NF service producer, an SCP, an NF service consumer, or the like in other future developments in appropriate scenarios. For example, an NF service consumer (as a client) can use a service provided by an NF service producer (as a server).

[0162] As shown in FIG. 7, the third network node 700 may include: a receiving unit 701, a determining unit 703, and a sending unit 705.

[0163] The receiving unit 701 is configured to receive a request message for a context from a first network node, where the request message includes property information relating to the request message.

[0164] As mentioned above, the property information for the request message is - information indicating that the request message relates to a reselection due to failure to reach the second network node; - information indicating that the request message relates to a reselection due to overload control of the second network node; - information indicating that the request message relates to a reselection due to a temporary rejection by the second network node during a last attempt to the second network node; Contains at least one of the following:

[0165] In an example embodiment, the property information regarding the request message may further include retransmission information indicating that the request message related to the reselection was previously transmitted to the second network node.

[0166] Alternatively or alternatively, the retransmission information further includes a number of attempts to the second network node where the first network node 500 has sent a request message to the second network node but the request message has been rejected by the second network node with a temporary cause code.

[0167] The determining unit 703 may be configured to determine whether to reject or accept the request message based at least on the property information related to the request message.

[0168] Preferably, the determining unit 703 may be further configured to determine whether to reject or accept the request message based on at least one of the property information regarding the request message, the nature of the implementation of the requested service, and the fact that the third network node is unable to retrieve the context from a database in which the context is stored.

[0169] The sending unit 705 may be configured to send a response message to the first network node, the response message including an indication of rejecting or accepting the request message.

[0170] As mentioned above, if the determining unit 703 rejects the request message, the sending unit 705 may be further configured to send a response message including an indication of the rejection of the request message.

[0171] In this case, the response message may further include rejection cause information, which may be defined as a specific format of a cause code, for example.

[0172] The rejection cause information indicates to the first network node that the request message for the context is currently rejected and that the first network node may retry later, e.g. based on facts indicated by the property information regarding the request message that the request message relates to a reselection due at least to overload control of the second network node and / or that the third network node cannot retrieve the context from the database in which it is stored, e.g. because the context is locked by the second network node, i.e. the rejection is only valid for this request message.

[0173] Alternatively or additionally, the rejection cause information may indicate to the first network node that the request message is rejected and that subsequent request messages for contexts related to the same service are rejected based at least on the nature of the implementation of the service, i.e., the rejection cause information may indicate to the first network node that the first network node should essentially not reselect the third network node for request messages for contexts related to the same service based on the nature of the implementation of the requested service.

[0174] Hereinafter, a structure of a third network node according to another embodiment of the present disclosure will be described with reference to Figure 8. Figure 8 is a schematic block diagram of a third network node 800 according to an exemplary embodiment of the present disclosure. The third network node 800 in Figure 8 may perform the method 300 described above with reference to Figure 3. Therefore, a detailed description of the third network node 800 may refer to the corresponding description of the method 300 in Figure 3 and the signaling sequence diagram in Figure 4 described above, and thus will be omitted here for brevity.

[0175] As mentioned above, it should be understood that the first network node as a client may be an NF service consumer, e.g., an SCP for normal request messages, an NF service producer for notification request messages, or the like in other future developments that send a request message (such as an HTTP request message), and accordingly, the second or third network node that receives the request message is referred to as a "server", which may refer to an NF service producer, an SCP, an NF service consumer, or the like in other future developments in appropriate scenarios. For example, an NF service consumer (as a client) can use a service provided by an NF service producer (as a server).

[0176] As shown in Figure 8, the third network node 800 includes at least one processor 801 and at least one memory 803. The at least one processor 801 includes, for example, any suitable CPU (Central Processing Unit), microcontroller, DSP (Digital Signal Processor), etc. capable of executing computer program instructions. The at least one memory 803 may be any combination of RAM (Random Access Memory) and ROM (Read Only Memory). The at least one memory 803 may also include persistent storage, which may be, for example, any one or combination of magnetic memory, optical memory, solid state memory, or remotely mounted memory.

[0177] The at least one memory 803 stores instructions executable by the at least one processor 801. The instructions, when loaded from the at least one memory 803 and executed on the at least one processor 801, may cause the third network node 800 to perform actions of procedures, such as those described above in relation to Figures 3 and 4, respectively, which are omitted here for the sake of brevity.

[0178] The present disclosure also provides at least one computer program product in the form of a non-volatile or volatile memory, such as a non-transitory computer-readable storage medium, an EEPROM (Electrically Erasable Programmable Read Only Memory), a flash memory, or a hard drive. The computer program product comprises a computer program.

[0179] The computer program includes code / computer readable instructions which, when executed by at least one processor 601, cause the first network node 600 to perform actions of the procedures, e.g. as described above in relation to Figures 2 and 4, or which, when executed by at least one processor 801, cause the third network node 800 to perform actions of the procedures, e.g. as described above in relation to Figures 3 and 4.

[0180] The computer program product may be configured as a computer program code configured with computer program modules. The computer program modules basically execute the operations of the flow shown in any one of Figures 2 to 4.

[0181] The processor may be a single CPU (Central Processing Unit), but may include two or more processing units. For example, the processor may include a general purpose microprocessor, an instruction set processor, and / or related chipsets, and / or a specialized microprocessor such as an application specific integrated circuit (ASIC). The processor may include on-board memory for cache purposes. The computer program may be carried by a computer program product connected to the processor. The computer program product may include a non-transitory computer readable storage medium that stores the computer program. For example, the computer program product may include a flash memory, a random access memory (RAM), a read only memory (ROM) or an EEPROM, and the computer program modules described above may be distributed in various computer program products of memory type in other embodiments.

[0182] The present disclosure has been described with reference to the embodiments. It should be understood that various modifications, substitutions and additions may be made by those skilled in the art without departing from the scope of the present disclosure. Therefore, the scope of the present disclosure is not limited to the specific embodiments described above, but is only defined by the appended claims.

Claims

1. A method (200) in a first network node for network node reselection for a service related context, comprising: the first network node has selected a second network node for providing the service consumed by the first network node, and the context associated with the service is created; The method (200) comprises: determining (S201) to reselect a third network node capable of providing the service for the context provided by the second network node; sending (S203) a request message for the context to the third network node, the request message including property information relating to the request message; Including, The property information regarding the request message includes: information indicating that the request message relates to reselection due to failure to reach the second network node; information indicating that the request message relates to a reselection due to overload control of the second network node; information indicating that the request message relates to a reselection due to a temporary rejection by the second network node during a last attempt to the second network node; and The method includes at least one of the following:

2. 2. The method (200) of claim 1, comprising: the overload control of the second network node is performed by the first network node based on overload information of the second network node; the overload information is indicated by overload control information (OCI) received from the second network node; or The method, wherein the overload information is derived from a ratio of a number of request messages rejected by the second network node with a status code to a total number of request messages, the status code being received from the second network node and indicating that a request message was rejected by the second network node.

3. 3. A method (200) according to any one of claims 1 to 2, comprising: The method of claim 1, wherein the property information relating to the request message further comprises retransmission information indicating that the request message associated with the reselection was previously transmitted to the second network node.

4. 4. The method (200) of claim 3, comprising: The method, wherein the retransmission information further includes a number of attempts to the second network node, in which the first network node has sent the request message to the second network node, but the request message has been rejected by the second network node with a temporary cause code.

5. 5. The method (200) of any one of claims 1 to 4, comprising: The first network node: the fact that the first network node is unable to reach the second network node; the first network node determining that the second network node is overloaded; the fact that the first network node has sent the request message to the second network node as an attempt, but the request message has been rejected by the second network node with a temporary cause code; determining to reselect the third network node based on at least one of:

6. The method (200) of any one of claims 1 to 5, further comprising: receiving a response message from the third network node corresponding to the request message, the response message including an indication of whether the request message is rejected or accepted by the third network node.

7. 7. The method (200) of claim 6, comprising: if a response message is received including an indication that the request message has been rejected by the third network node, the response message further including rejection cause information; The rejection cause information is indicating that the request message is currently rejected based on the fact that the property information on the request message indicates that the request message relates to the reselection due at least to overload control of the second network node and / or the fact that the third network node is unable to retrieve the context from a database in which the context is stored, or indicating that the request message is rejected and that subsequent request messages for a context related to the same service will be rejected based at least on properties of an implementation of the service.

8. 8. The method (200) of claim 7, further comprising: storing the rejection cause information contained in the received response message for later reselection decisions.

9. 9. The method (200) of any one of claims 1 to 8, comprising: The method, wherein the request message is a HyperText Transfer Protocol (HTTP) request message.

10. 10. The method (200) of any one of claims 1 to 9, comprising: the first network node acts as an HTTP client sending the request message; A network function (NF) service consumer; A service communication proxy (SCP); An NF service producer; The method includes at least one of the following:

11. 11. The method (200) of any one of claims 1 to 10, comprising: the second network node or the third network node acts as an HTTP server that responds to the request message; An NF service consumer; SCP and An NF service producer; The method includes at least one of the following:

12. A method (300) in a third network node for network node reselection for a service related context, comprising: a first network node selecting a second network node for providing the service consumed by the first network node, the context associated with the service being created; The method (300) comprises: receiving a request message for the context from the first network node (S301), the request message including property information relating to the request message; determining (S303) whether to reject or accept the request message based at least on the property information relating to the request message; sending (S305) a response message to the first network node including an indication of rejecting or accepting the request message; Including, The property information regarding the request message includes: information indicating that the request message relates to reselection due to failure to reach the second network node; information indicating that the request message relates to a reselection due to overload control of the second network node; information indicating that the request message relates to a reselection due to a temporary rejection by the second network node during a last attempt to the second network node; and The method includes at least one of the following:

13. 13. The method (300) of claim 12, comprising: The third network node: the nature of the requested implementation of said service; the fact that the third network node is unable to obtain the context from a database in which the context is stored; determining whether to reject or accept the request message based further on at least one of:

14. 13. The method (300) of claim 12, comprising: If the third network node decides to reject the request message, the third network node sends the response message including an indication that the request message has been rejected.

15. A first network node (600) configured for network node reselection for a service related context, comprising: the first network node has selected a second network node for providing the service consumed by the first network node, and the context associated with the service is created; The first network node (600) At least one processor (601); At least one memory (603) for storing instructions; The instructions, when executed by the at least one processor (601), cause the first network node (600) to: determining to reselect a third network node capable of providing the service for the context provided by the second network node; sending a request message for the service to the third network node, the request message including property information relating to the request message; The system is configured to: The property information regarding the request message includes: information indicating that the request message relates to reselection due to failure to reach the second network node; information indicating that the request message relates to a reselection due to overload control of the second network node; information indicating that the request message relates to a reselection due to a temporary rejection by the second network node during a last attempt to the second network node; and A first network node comprising at least one of:

16. A first network node (600) according to claim 15, comprising: The instructions, when executed by the at least one processor (601), further cause the first network node (600) to perform a method according to any one of claims 2 to 11.

17. A third network node (800) configured for network node reselection for a service related context, comprising: a first network node selecting a second network node for providing the service consumed by the first network node, the context associated with the service being created; The third network node (800) At least one processor (801); At least one memory (803) for storing instructions; The instructions, when executed by the at least one processor (801), cause the third network node (800) to: receiving a request message for the context from the first network node, the request message including property information relating to the request message; determining whether to reject or accept the request message based at least on the property information regarding the request message; sending a response message to the first network node including an indication of rejecting or accepting the request message; The system is configured to: The property information regarding the request message includes: information indicating that the request message relates to reselection due to failure to reach the second network node; information indicating that the request message relates to a reselection due to overload control of the second network node; information indicating that the request message relates to a reselection due to a temporary rejection by the second network node during a last attempt to the second network node; and A third network node, comprising at least one of:

18. A third network node (800) according to claim 17, comprising: The instructions, when executed by the at least one processor (801), further cause the third network node (800) to perform a method according to any one of claims 13 to 14.

19. 12. A computer readable storage medium having stored thereon computer program instructions which, when executed by at least one processor, cause the at least one processor to perform a method according to any one of claims 1 to 11.

20. 15. A computer readable storage medium having computer program instructions stored thereon, the computer program instructions, when executed by at least one processor, causing the at least one processor to perform a method according to any one of claims 12 to 14.

Images