METHODS, NETWORK NODES, AND COMPUTER-READABLE MEDIA FOR NETWORK NODE RESELECTION

Abstract

The present invention provides methods (200, 300), network nodes (500, 600, 700, 800), and computer-readable means for reselecting network nodes for a service-related context. Method (200) at a first network node includes: determining (S201) to reselect a third network node that can provide a service for a context that was provided by the second network node; and transmitting (S203) a request message for the context to the third network node, wherein the request message comprises proprietary information about the request message.

Description

METHODS, NETWORK NODES AND COMPUTER-READABLE MEDIA FOR NETWORK NODE RESELECTION TECHNICAL FIELD The present invention relates generally to the technical field of communication technologies and, in particular, to methods, network nodes and computer-readable means for reselecting network nodes. BACKGROUND This section aims to provide background information on the various embodiments of the technology described in this invention. The description in this section may include concepts that could be developed, but are not necessarily concepts that have been previously conceived or pursued. Therefore, unless otherwise stated herein, what is described in this section is not prior art to the description and / or claims of this invention and is not admitted as prior art by mere inclusion in this section. NF service suite and NF suite In accordance with Clause 5.21.3.2 of 3GPP TS According to 23.501 V16.7.0 (which is incorporated herein in full by reference), an NF Service Set is defined as a group of interchangeable NF service instances of the same service type within an NF instance, where the NF service instances in the same NF service set have access to the same context data. An NF set is defined as a group of interchangeable NF instances of the same type, supporting the same services and network segments, where the NF instances in the same NF set may be geographically distributed but have access to the same context. When a Network Function Set (NF) or an NF Service Set is deployed on the network as specified in Clauses 5.21.3 and 6.3.1.0 of 3GPP TS 23.501 V16.7.0, an NF Service Producer in a An NF (Service) set creates a context resource (or resources), and the context (or contexts) is shared by all NF (Service) instances belonging to the same NF (Service) set; that is, the resource context is bound to the NF (Service) set. Therefore, requests directed to the resource can be serviced by any NF (Service) instance within the NF (Service) set, unless the shared contexts are lost. For example, as shown in Figure 1, Server 1 and Server 2 are in the same set. If a context like `anofr in / cznz / q / uli` is handled by Server 1, but Server 1 is unable to handle the context at some point for some reason, the context can be handled seamlessly by Server 2, since the context is stored in a common central database, for example, in an Unstructured Data Storage Facility (UDSF) network function for the set, which is accessible to all servers, such as Server 1 and Server 2, in the same set. In a network, a network entity (NF) can select another NF that can provide a service it needs and transmit a request message (for example, a Hypertext Transfer Protocol (HTTP) request message) for that service to the other NF. Here, the NF transmitting the request message can be called the Client, which can refer to an NF service consumer or a Service Communication Proxy (SCP), for example, for regular request messages, or an NF service producer, for example, for notification request messages. Accordingly, the NF receiving the request message can be called the Server, which can refer to an NF service producer, an SCP, or an NF service consumer in any appropriate scenario. For example, an NF service consumer (such as a Client) can consume a service provided by an NF service producer (such as a Server). For various reasons, such as overload, temporary or unavoidable issues, etc., the Client may determine that the selected Server cannot provide the requested service. In this case, the Client may select another Server from the same set, which will also be able to provide the requested service. Figure 1 schematically shows an exemplary reselection process that is triggered, for example, by overloading Server 1, which has been previously selected by the Client. It should be noted that the overload of Server 1 is illustrated here as an exemplary reason for triggering the reselection process; there may be other possible reasons for triggering the reselection process, such as Server 1 being unreachable or Server 1 rejecting the Client's request message for a temporary reason, etc., which are not limited in the present invention. In Sl_l, the Client initially selects a Server instance (Server 1 in this example), according to selection criteria such as location, priority, load, etc. In SI 2, the Client transmits a request message to Server 1 for Service A to establish a (resource) context X related to Service A. In particular, a request message is transmitted per context (for example, per UE or per packet data unit (PDU) session) related to a service, and a service can be related to at least one context. In Sl_3, Server 1 creates the context X related to Service A. In this example, in Sl_4, Server 1 is overloaded. In SI 5, the Client can transmit, to Server 1, for example, a request message so that, for example, Service A establishes a context Y related to Service A. In SL_6, Server 1 can inform the Client that it is overloaded by providing Overload Control Information (OCI), which indicates overload information from Server 1, or by providing a status code, such as 429 / 503, which indicates that the request message is rejected by Server 1. Note that, using status code 429 / 503, the Client can derive overload information from Server 1 as OCI based on the ratio between the number of rejected request messages (with status code 429 / 503) and the total number of request messages. For example, Server 1 can specify in the OCI an exact percentage of the number of request messages that it wants the Client to reduce. onofr in / eznz / q / uιλι In SI 7, the Client can store related information about the overload of Server 1, with the OCI. The Client needs to reduce the signaling messages sent to Server 1, which can be achieved by rejecting the original request message received by the Client, for example, from an upstream NF or a user equipment (UE), or by reselecting an alternative NF based on context resilience information, for example, context binding information. In SL_8, the Client may receive a request for context X, for example, from an upstream NF or a UE, leading the Client to consume Service A to update the context on Server 1. Since the Client knows that Server 1 is overloaded, it may decide to reselect an alternative NF (Server 2 in this example) in the set where Server 1 resides. As described earlier, servers in the same set can provide the same service for the context, and consequently, the context related to the service can be handled by any of the servers in the set. In Sl_9, the Client can transmit a request message for context X to Server 2 in the set where Server 1 is located. In Sl_10, Server 2 can accept the onofr in / eznz / q / uli request message. However, such acceptance can result in Server 1 becoming even more overloaded. For example, for an overloaded Access and Mobility Management (AMF) function, if an alternative AMF is selected for the Namf_communication service, for example, for the NlN2Message Transfer service operation, the alternative AMF may search for the UE. However, when the UE responds to the search, it will still initiate a service request to the overloaded AMF; • As another example, an overloaded session management function (SMF), i.e., SMF1, is serving a request message for a session from a peer NF, for example, a policy control function (PCF). Therefore, the context (for the session) in the UDSF might be blocked by this SMF1. At the same time, another peer NF, for example, an AMF, might attempt to contact this overloaded SMF1 for the same context. In such a scenario, the AMF might 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 knows that the corresponding context has been blocked by SMF1, it will also redirect the request to the overloaded SMF1. Therefore, Server 2 cannot serve the Client's request message anofr in / eznz / q / uli for context X, although Server 2 can accept the request message during reselection. There is no mechanism that allows an alternate (reselected) Server to take different actions appropriately upon receiving a request message from the Client for the existing context. BRIEF DESCRIPTION The embodiments of the present invention provide a mechanism that allows an alternate (reselected) Server to take different actions appropriately upon receiving a request message from the Client for the existing context; and allows the Client to receive and store a reason for rejection to prevent further selections for the same reason for rejection in case the request message is rejected by the alternate (reselected) Server. According to a first aspect of the present invention, a method is provided on a first network node (i.e., a Client) for reselecting network nodes for a service-related context. The first network node has selected a second network node (i.e., a previously selected server) to provide the service consumed by the first network node, and the service-related context has been created. The method includes: determining and reselecting a third network node (i.e., an alternate server) that can provide the service for the context that was provided by the second network node; and transmitting a request message for the context to the third network node, wherein the request message includes proprietary information. In an exemplary form, such proprietary information about the request message includes at least one of: Information indicating that the request message implies a reselection due to a failure to reach the second network node, information indicating that the request message implies a reselection due to overload control for the second network node, or information indicating that the request message implies a reselection due to a temporary rejection of the second network node during a last attempt to the second network node. In an exemplary mode, overload control for the second network node is carried out by the first network node based on overload information from the second network node, wherein the overload information is indicated by OCI received from the second network node, or the overload information is derived from a ratio between a number of request messages rejected by the second network node with a status code versus a total number of request messages, wherein the status code is received from the second network node, indicating that a request message is being rejected by the second network node. In one exemplary mode, this ownership information about the request message also includes relay information indicating that the request message involving reselection has been transmitted earlier to the second network node. In one exemplary mode, the relay information also includes a series of attempts to the second network node, in which case the first network node has transmitted the request message to the second network node, but the request message is rejected by the second network node with a temporary cause code. In one exemplary mode, such proprietary information about the request message is included in a new or existing custom header of the request message, or in a message body of the request message. onofr in / eznz / q / uιλι In an exemplary scenario, the first network node determines to re-select the third network node based on at least one of the following facts: The first network node cannot reach the second network node, the first network node determines that the second network node is overloaded, or the first network node has transmitted the request message to the second network node as an attempt, but the second network node rejects the request message with a temporary cause code. In an exemplary form, the method also includes: receiving, from the third network node, a response message corresponding to the request message, where the response message includes an indication of whether the third network node rejects or accepts the request message. In an exemplary scenario, in a case where a response message is received that includes an indication of the request message rejected by the third network node, the response message also includes information about the reason for rejection, indicating that: The request message is currently rejected based on the fact that the ownership information about the request message indicates that the request message involves reselection at least due to the onofr in / eznz / q / uli overhead for the second network node, and / or that the third network node cannot retrieve the context from a database where the context is stored, or the request message is rejected and any subsequent request messages for contexts related to the same service will be rejected at least in accordance with the nature of the service implementation. In one exemplary form, the method also includes: storing the rejection reason information included in the received response message for later determination of reselection. In an exemplary mode, the request message is an HTTP request message. In an exemplary configuration, the first network node functions as an HTTP client to transmit the request message and includes at least one of: a consumer of NF services; an SCP, or an NF service producer. In an exemplary configuration, the second or third network node functions as an HTTP server to respond to the request message and includes at least one of: a consumer of NF services; an SCP, or an NF service producer. According to a second aspect of the present invention, a method is provided on a third network node (i.e., an alternate Server) for reselecting network nodes for a service-related context, wherein a first network node (i.e., a Client) has selected a second network node (i.e., a previously selected Server) to provide the service consumed by the first network node, and the service-related context has been created. The method includes: receiving, from the first network node, a request message for the context, wherein the request message includes proprietary information about the request message; determining whether the request message is rejected or accepted at least based on the proprietary information about the request message; and transmitting, to the first network node, a response message that includes an indication of whether the request message is rejected or accepted. In an exemplary form, such proprietary information about the request message includes at least one of: information indicating that the request message implies a reselection due to a failure to reach the second network node, information indicating that the request message implies a reselection due to overload control for the second network node, or information indicating that the request message implies a reselection due to a temporary rejection of the second network node during a last attempt to the second network node. In an exemplary mode, overload control for the second network node is carried out by the first network node based on overload information from the second network node, where the overload information is indicated by OCI received from the second network node, or the overload information is derived from a ratio between a number of request messages rejected by the second network node with a status code versus a total number of request messages, where the status code is received from the second network node, indicating that a request message is being rejected by the second network node. In one exemplary instance, this proprietary information about the request message also includes relay information indicating that the request message involving reselection has been transmitted previously. In an exemplary mode, the relay information also includes a series of attempts to the second network node, in which case the first network node has transmitted the request message to the second network node, anofr in / cznz / q / uli but the request message is rejected by the second network node with a temporary cause code. In one exemplary mode, such proprietary information about the request message is included in a new or existing custom header of the request message, or in a message body of the request message. In an exemplary mode, the third network node determines whether the request message is rejected or accepted based on at least one of: nature of the implementation of the requested service, or a fact that the third network node cannot retrieve the context from a database where the context is stored. In an exemplary mode, the third network node transmits the response message which includes an indication of the request message being rejected, in a case where the third network node determines that the request message is rejected. In one exemplary instance, the response message also includes information on the reason for rejection, indicating that: The request message is currently rejected based on the fact that the ownership information about the request message indicates that the request message onofr in / eznz / q / uili implies reselection at least due to overload control for the second network node, and that the third network node cannot retrieve the context from a database where the context is stored, or the request message is rejected and any subsequent request messages for contexts related to the same service will be rejected at least in accordance with the nature of the service implementation. In an exemplary mode, the request message is an HTTP request message. In an exemplary configuration, the first network node functions as an HTTP client to transmit the request message and includes at least one of: a consumer of NF services; an SCP, or an NF service producer. In an exemplary configuration, the second or third network node functions as an HTTP server to respond to the request message and includes at least one of: a consumer of NF services; an SCP, or an NF service producer. According to a third aspect of the present invention, a first network node (i.e., a Client) is provided. The first network node includes: at least one processor, and at least one memory, which store instructions that, when executed on at least one processor, cause the first network node to carry out any of the methods according to the first aspect of the present invention. According to a fourth aspect of the present invention, a third network node (i.e., an alternate server) is provided. The third network node includes at least one processor and at least one memory, which store instructions that, when executed on at least one processor, cause the third network node to carry out any of the methods according to the second aspect of the present invention. According to a fifth aspect of the present invention, a computer-readable storage medium is provided. The computer-readable storage medium has computer program instructions stored therein, and the computer program instructions, when executed by at least one processor, cause the at least one processor to carry out the method according to either the first or second aspect of the present invention. The technical solutions of the modalities of the present invention can achieve at least the following benefits: - to allow the third network node (i.e., the reselected Server) to reject a received request message (such as as a result of the reselection) in a case where it cannot continue with the request message, based on at least one of the reasons that triggered the reselection, for example, a failure to reach the second network node (i.e., the previously selected Server), overload control for the second network node, or a temporary rejection by the second network node during a last attempt to the second network node; and - by providing a reason for rejection from the third network node (i.e., the reselected Server) that rejects the request message from the first network node (i.e., the Client), allowing the first network node to avoid further reselections for the same reason for rejection. anofr in / eznz / q / uιλι BRIEF DESCRIPTION OF THE DRAWINGS The objects, advantages, and features of the present invention will be more evident, according to the descriptions of preferred embodiments in relation to the drawings, in which: Figure 1 schematically shows an exemplary reselection process that is triggered, for example, by overloading of Server 1, which has been previously selected by the Client according to conventional technical solutions. Figure 2 schematically shows a method at a first network node (i.e., a Customer) for reselecting network nodes for the existing context according to an exemplary embodiment of the present invention. Figure 3 schematically shows a method at a third network node (i.e., a reselected server) for reselecting network nodes for the existing context according to an exemplary embodiment of the present invention. Figure 4 schematically shows an exemplary reselection process according to an exemplary embodiment of the present invention. Figure 5 schematically shows a structural block diagram of a first network node (i.e., a Customer) according to an exemplary embodiment of the present invention. Figure 6 schematically shows a structural block diagram of a first network node (i.e., a Customer) according to another exemplary embodiment of the present invention. Figure 7 schematically shows a structural block diagram of a third network node (i.e., a reselected Server) according to an exemplary embodiment of the present invention. Figure 8 schematically shows a structural block diagram of a third network node (i.e., a reselected Server) according to another exemplary embodiment of the present invention. It should be noted that in all the drawings, identical or similar reference numbers are used to indicate identical or similar elements; several parts of the drawings are not drawn to scale, but are for illustrative purposes only and should therefore not be understood as limitations or restrictions on the scope of the present invention. onofr in / eznz / q / uιλι DETAILED DESCRIPTION From this point forward, the principle and spirit of the present invention will be described with reference to illustrative embodiments. Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. However, other embodiments are contained within the scope of the subject matter disclosed herein; the subject matter disclosed should not be construed as being limited solely to the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art. Those skilled in the art will appreciate that the term "exemplary" is used herein to mean illustrative or serving as an example and is not intended to imply that one modality is preferred over another or that a particular feature is essential. Likewise, the terms "first" and "second," and similar terms, are used simply to distinguish one particular instance of an element or feature from another and do not indicate a particular order or arrangement unless the context clearly indicates otherwise. Furthermore, the term "step," as used herein, is intended to be synonymous with "operation" or "action." Any description here of a sequence of steps does not imply that these operations must be carried out in any particular order, or even that they are carried out in any order at all, unless the context or the details of the operation described clearly indicate otherwise. References in the specification to a modality, the modality, an example modality, etc., indicate that the described modality may include a particular function, structure, or feature, but it is not necessary for each modality to include that particular function, structure, or feature. Furthermore, such phrases do not necessarily refer to the same modality. Additionally, when a particular function, structure, or feature is described in relation to a modality, it is stated that it is within the knowledge of someone skilled in the art to affect that particular function, structure, or feature in connection with other modalities, whether or not it is explicitly described. The terminology used herein is intended to describe particular modalities only and is not intended to limit exemplary modalities. As used herein, the singular forms *un*, *una*, and *el* are intended to include the plural forms as well, unless the context clearly indicates otherwise. It is further understood that the terms *compras*, *que comprens*, *tiene*, *que tiene*, *includas*, and / or *que Incluye*, when used herein, specify the presence of the indicated characteristics, elements, and / or components, etc., but do not exclude the presence or addition of one or more characteristics, elements, components, and / or combinations thereof. As used in this document, the term and / or includes any and all combinations of one or more of the listed associated terms. In the following description and claims, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by a person skilled in the art to which this invention belongs. As used in this document, the term "network" refers to a network that adheres to any suitable communication standard (wireless or wired). For example, wireless communication 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 Address (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), etc. UTRA includes WCDMA and other variants of CDMA. A TDMA network may implement a radio technology such as the Global System for Mobile Communications (GSM).An OFDMA network can implement a radio technology such as Evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, FlashOFDMA, Ad-hoc network, wireless sensor network, etc. In the following description, the terms network and system can be used interchangeably. Furthermore, communication between two devices on the network can be carried out according to any suitable communication protocol, including, but not limited to, wireless communication protocols defined by a standards organization such as 3GPP or wired communication protocols. For example, wireless communication protocols may include first-generation (1G), 2G, 3G, 4G, 4.5G, 5G communication protocols and / or any other protocol currently known or that may be developed in the future. As used herein, the term network node refers to a device in a wireless communication network through which a terminal device or another network node accesses and receives services from the network. A network node refers to a network node (NF), a base station (BS), an access point (AP), or any other suitable device in the wireless communication network. The BS may be, for example, a B-node (NodeB or NB), an evolved B-node (eNodeB or eNB), or a gNB, a remote radio unit (RRU), a radio head (RH), a remote radio head (RRH), a relay, or a low-power node such as a femto, pico, etc.Still other examples of a network node can include multi-standard radio equipment (MSRs), such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmit points, and transmit nodes. More generally, however, a network node can represent any suitable device (or group of devices) capable, configured, arranged, and / or operable to enable and / or provide access to a wireless communication network for a terminal device or to provide some service to a terminal device that has accessed the wireless communication network. The term UE refers to any end device that can access and receive services from a wireless communication network. By way of example and without limitation, a UE refers to a mobile terminal, terminal device, or other suitable device. A UE can be, for example, a SS (subscriber station), a portable subscriber station, an MS (mobile station), or an AT (access terminal), or a relay node. A UE may include, among others, laptops, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback devices, a mobile phone, a cell phone, a smartphone, VoIP (Voice over IP) phones, cordless local loop phones, a tablet, a handheld device, a PDA (personal digital assistant), notebook computers, desktop computers,Image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback devices, portable terminal devices, wireless vehicle-mounted terminal devices, wireless endpoints, mobile stations, LEE (laptop embedded equipment), LME (laptop mounted equipment), USB dongles, smart devices, wireless CPE (customer premises equipment), 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 for communication in accordance with one or more communication standards promulgated by the Third Generation Partnership Project (3GPP), such as the 3GPP GSM, UMTS, LTE, and / or 5G standards. As used herein,A user equipment (UE) does not necessarily have a user in the sense of a human user who owns and / or operates the corresponding device. In some modalities, a terminal device can be configured to transmit and / or receive information without direct human interaction. For example, a terminal device can be designed to transmit information to a network on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the wireless communication network. Conversely, a UE can represent a device intended for sale or operation by a human user, but which may not initially be associated with a specific human user. As another example, in an IoT (Internet of Things) scenario, a UE (Enterprise Unit) can represent a machine or other device that performs monitoring and / or measurements and transmits the results of such monitoring and / or measurements to another terminal device and / or network equipment. In this case, the UE can be an M2M (machine-to-machine) device, which in a 3GPP context might be called an MTC (machine-to-cable) device. Specifically, the UE could be a terminal device that implements the 3GPP NB-IoT standard. Examples of such machines or devices include sensors, measuring devices such as energy meters, industrial machinery, or household appliances such as refrigerators, televisions, and personal wearable devices like watches. In other scenarios, a UE can represent a vehicle or other equipment capable of monitoring and / or reporting its operational status or other functions associated with its operation. The present invention applies in a scenario where the Client has selected a Server (for example, Server 1) to provide a service consumed by the onofr in / eznz / q / uili The client has created a service-related context, but the client needs to reselect an alternative server (e.g., Server 2) that is located in the same set as Server 1, due to some reasons on Server 1. Together with the exemplary reselection process of Figure 1, the embodiments of the present invention may be considered applicable on the condition that steps SI 1 to SI 7 of the reselection process are carried out as shown in Figure 1. In particular, the embodiments of the present invention may especially improve steps SI 9 and SI 10 of the reselection process as shown in Figure 1. As described above, it should be noted that the overload of Server 1 is illustrated in Figure 1 as the only exemplary reason for triggering the reselection process; however, there may be other possible reasons for triggering the reselection process, such as Server 1 being unreachable or Server 1 rejecting the Client's request message for a temporary reason, etc. The reasons for triggering the reselection process are applicable to the embodiments of the present invention. The basic ideas of the present invention consist mainly of 1) Include proprietary information in a request message from the Client to the alternate Server 2, for example, an HTTP request message. The proprietary information about the request message may include: information indicating that the request message implies a reselection for the context due to a failure to reach Server 1, information indicating that the request message implies a reselection for the context due to overload control for Server 1, information indicating that the request message implies a reselection for the context due to a temporary rejection by Server 1 during a last attempt to Server 1, retransmission information indicating that the request message implying the reselection has been retransmitted, etc. In this way, Server 2 can reject the received request message at least based on the proprietary information about the request message; and 2) Include rejection reason information in a response message from Server 2 to the Client, in case the request message is rejected by Server 2. The rejection reason information can indicate that any request message implies that reselecting the server for the context is not supported due to the nature of the requested service implementation, or that Server 2 cannot retrieve the context from a database where the context is stored. In this way, the Client can store the rejection reason information received to avoid reselections for the same reason. The embodiments of the present invention will be described illustratively together with Figures 2 to 4. Hereafter, a method 200 in a first network node (i.e., a Client) for network node reselection for the existing context according to an exemplary embodiment of the present invention will be described with reference to Figure 2. It is understood that the first network node, such as Client, may be an NF service consumer or an SCP, for example, for regular request messages, or an NF service producer, for example, for notification request messages, or similar in other future developments, transmitting a request message, for example, an HTTP request message. As described above, method 200 is carried out in a scenario such that the first network node (i.e., a Client) has selected a second network node (i.e., a previously selected Server, e.g., Server 1) to provide a service consumed by the first network node and a context related to the service has been created, but the first network node has to reselect a third (alternative) network node (e.g., Server 2) that is located in the same set as the second network node, for some reasons (which will be described later) in the second network node. Consequently, the second or third network node that receives the request message can be called the Server, which may refer to an NF service producer, an SCP, an NF service consumer, or similar entity in future developments and in any appropriate scenario. For example, an NF service consumer (such as a Client) may consume a service provided by an NF service producer (such as a Server). As shown in Figure 2, method 200 may include at least steps S201 and S203. In step S201, the first network node (i.e., a Client) can determine to reselect a third network node in the set where the second network node is located, which can provide the service for the context that was provided by the second network node. In an exemplary scenario, upon receiving a request message, for example, from an upstream network node or a UE, to address the existing context that is related to the service provided by the second network node, the first network node may determine that a reselection is required based on at least one of the following facts: the first network node cannot reach the second network node, which can be, for example, polled using PING; for example, the first network node cannot reach an original resource Unified Resource Identifier (URI) in a case where the second network node is an NF producer, or cannot reach a notification / callback URI in a case where the second network node is a consumer NF, - the first network node determines that the second network node is overloaded, for example, by receiving, from the second network node, OCI indicating overload information from the second network node; or by receiving, from the second network node, a status code (for example, 429 / 503) indicating that the second network node is rejecting a request message, and deriving overload information from the second network node from a proportion of the number of request messages that are rejected with the status code by the second network node versus a total number of request messages, as specified in Client-Side Adaptive Acceleration for Overload Control in Annex A of 3GPP TS 29.500 V17.1.0 (which is incorporated herein in full by reference), or - The first network node has transmitted the request message to the second network node as an attempt, but the second network node rejects the request message with a temporary cause code anofr in / cznz / q / uili. The first network node can re-select the third network node, which is located in the same set as the second network node, since the context is stored in the common central database, for example, in the UDSF for the set, which is accessible to all network nodes in the same set. Then, in step S203, the first network node can transmit a request message for the service-related context to the third network node. In particular, a request message is transmitted per context (e.g., per UE or per Packet Data Unit (PDU) session) related to a service, and a service can be related to at least one context. The context throughout the present invention does not exclude multiple contexts. The request message may include proprietary information about the request message. Preferably, the ownership information about the request message may include at least one of the following: information indicating that the request message implies a reselection due to a failure to reach the second network node; information indicating that the request message involves a reselection due to overload control for the second network node; or information indicating that the request message involves a reselection due to a temporary rejection of the second network node during a last attempt to the second network node. In a case where the proprietary information about the request message includes information indicating that the request message involves a reselection due to overload control for the second network node, the overload control for the second network node can be performed by the first network node based on the overload information from the second network node. The overload information can be indicated by the OCI received from the second network node, or it can be derived from the ratio of the number of request messages rejected by the second network node with the status code (e.g., 429 / 503) to the total number of request messages. The status code (e.g., 429 / 503) can be received from the second network node, indicating that the second network node is rejecting a request message. Alternatively, or in addition, the ownership information about the request message can also include retransmission information indicating whether the request message involving the reselection was previously transmitted to the second network node; that is, whether the first network node attempted to transmit the request message. For example, a Boolean parameter (True or False) can be used. In a case where the relay information indicates that the request message involving reselection has been previously transmitted to the second network node, for example, 'True', the relay information may further include the number of attempts to the second network node, in which case the first network node has transmitted the request message to the second network node but the second network node rejects the request message with a temporary cause code. For example, the first network node, as a Client, can transmit a request message to the context, for example, the second network node, such as Server 1, as the first attempt, and transmit a request message to the context, for example, the third network node, such as Server 2, as the second attempt. Then, the first network node can try a third time; for example, it can transmit a request message to the context to the third network node or to some other network nodes. Here, the request message can include the number of retries (2 in this example) in the property information, since the first network node has already tried two times. Proprietary information about the request message can be included in a new or existing custom header of the request message, or in a message body of the request message. The third network node can receive the request message, which includes the related ownership information as described above. Based at least on the ownership information received in the request message, the third network node can determine whether to reject or accept the request message and can transmit a response message to the first network node, indicating whether the request message was rejected or accepted. This process will be described in detail later with reference to Figure 3. Therefore, in method 200, the first network node can receive, from the third network node, the response message corresponding to the request message. The response message may include an indication of whether the request message is rejected or accepted by the third network node. In a case where a response message is received that includes an indication of the request message being rejected by the third network node, the response message may also include information about the reason for rejection. For example, the reason for rejection may be defined as certain types of cause codes. The rejection reason information received in the response message may indicate to the first network node that the request message for the context is currently rejected and the first network node can retry later. This could be based, for example, on the property information about the request message indicating that the request message implies reselection, at least due to overload control for the second network node, and / or that the third network node cannot retrieve the context from a database where the context is stored, for example, because the context is locked by the second network node. In other words, the rejection is ONLY valid for this request message. For example, SMF1 is serving a request message for a session from a peer NF, such as a PCF, so this SMF1 might be blocking the context (for the session) in the UDSF. At the same time, another peer NF, such as an AME, might try to contact this overloaded SMF1 for the same context. In such a scenario, the AME (as an example of the first network node) might decide to reselect an alternative SMF, i.e., SMF2 (as an example of the third network node), since it knows that SMF1 (as an example of the second network node) is overloaded.Thus, when the alternate SMF2 (such as anofr in / eznz / q / uili of the third network node) receives the request message and knows that the corresponding context has been blocked by SMF1 (such as the second network node), SMF2 (such as the third network node) rejects the request message and transmits such rejection cause information based on the above facts to prevent the AMF from redirecting the request message to the overloaded SMF1 (such as the second network node). Alternatively, or in addition, the rejection reason information received in the response message can indicate to the first network node that the request message is rejected, and any subsequent request messages for contexts related to the same service will also be rejected, at least based on the nature of the service implementation. In other words, the first network node should not re-select the third network node for request messages in contexts related to the same service, based on the implementation of the requested service. For example, for an overloaded AMF (such as the second network node), if an alternate AMF (such as the third network node) is selected for the Namf communication service, for example, for the NlN2 Message Transfer service operation, the alternate AMF (such as the third network node) can search for the UE. However, when the UE responds to the search, it will still initiate a service request to the overloaded AME (such as the second network node). Therefore, the alternate AME (such as the third network node) rejects the request message and transmits the reason for the rejection based on the nature of the requested service implementation. Preferably, the first network node can store the rejection cause information included in the received response message for later reselection determination. Hereafter, a method 300 in a third network node (i.e., a reselected server) for reselecting network nodes for the existing context according to an exemplary embodiment of the present invention will be described with reference to Figure 3. It is understood that the first network node, as a Client, may be an NF service consumer or an SCP, for example, for regular request messages, or an NF service producer, for example, for notification request messages, or similar in other future developments, transmitting a request message, for example, an HTTP request message, and accordingly, the second or third network node receiving the request message may be called a Server, which may refer to an NF service producer, an SCP, an NF service consumer, or similar in other future developments in any appropriate scenario.For example, an NF service consumer (such as a Client) can consume a service provided by an NF service producer (such as a Server). It should also be understood that method 300 at the third network node corresponds to method 200 at the first network node, as described above. Therefore, some descriptions of method 300 may refer to method 200 and will be omitted for simplicity. As described earlier, method 300 is carried out in a scenario where the first network node (i.e., a Client) has selected a second network node (i.e., a previously selected Server, for example, Server 1) to provide a service consumed by the first network node, and a context related to the service has been created. However, the first network node needs to reselect a third (alternative) network node (for example, Server 2) located in the same network set as the second network node, due to some reason (which have been previously described with reference to Figure 2). The first network node then determines which third network node can provide the service for the context provided by the second network node. As shown in Figure 3, Method 300 may include at least steps S301, S303, and S305. In step S301, the third network node can receive a context request message from the first network node. The request message can include proprietary information about the request message. Preferably, the ownership information about the request message may include at least one of the following: information indicating that the request message implies a reselection due to a failure to reach the second network node; Information indicating that the request message involves a reselection due to overload control for the second network node, or information indicating that the request message involves a reselection due to a temporary rejection of the second network node during a last attempt to the second network node. Alternatively, or in addition, the ownership information about the request message can also include retransmission information indicating whether the request message involving the reselection has been previously transmitted to the second network node—that is, whether the first network node attempted to transmit the request message. For example, a Boolean parameter can be used (True or False). In a case where the relay information indicates that the request message involving reselection has been previously transmitted to the second network node, for example, 'True', the relay information may further include the number of attempts to the second network node, in which case the first network node has transmitted the request message to the second network node but the second network node rejects the request message with a temporary cause code. For example, the first network node, acting as a Client, might send a request message to the second network node, such as Server 1, as the first attempt, and then send a request message to the third network node, such as Server 2, as the second attempt. The first network node might then attempt a third time, for example, by sending a request message to the third network node or to other network nodes. In this case, the request message might include the number of retries (2 in this example) in its property information, since the first network node has already attempted twice. Ownership information about the request message can be included in a custom header Qnown / eznz / q / Y new or existing from the request message, or in a message body of the request message. In step S303, the third network node can determine whether the request message is rejected or accepted at least based on ownership information about the request message. Preferably, the third network node can determine whether the request message is rejected or accepted based on at least one of: ownership information about the request message, the nature of the implementation of the requested service, or a fact that the third network node cannot retrieve the context from the database where the context is stored. For example, the third network node might decide to reject the request message based on ownership information indicating that the request message involves reselection due to overload control for the second network node, and the fact that the third network node cannot retrieve the context from the database where the context is stored—for example, because the context is locked by the second network node. That is, the rejection is ONLY valid for this specific request message. As a particular example, SMF1 is delivering a request message for a session from a peer NF, for example, a PCF, so this SMF1 might lock the context (for the session) in the UDSF; at the same time, another peer NF, for example, an AMF, might try to contact 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, namely SMF2 (as an example of the third network node), since it knows that SMF1 (as an example of the second network node) is overloaded. Thus, when the alternative SMF2 (as an example of the third network node) receives the request message and knows that the corresponding context has been blocked by SMF1 (as an example of the second network node), SMF2 (as an example of the third network node) rejects the request message and transmits the reason for rejection based on the above facts to prevent the AMF from redirecting the request message to the overloaded SMF1 (as an example of the second network node). As another example, the third network node might decide to reject the request message based on the received ownership information indicating that the request message implies reselection due to overload control for the second network node and the nature of the service implementation. That is, the third network node always rejects the request message for contexts related to the same service due to the implementation nature of the requested service. For example, in this particular case, for an overloaded AMF (as an example from the second network node), if an alternative AMF (as an example from the third network node) is selected for the Namf communication service, for example, for the NlN2 Message Transfer service operation, the alternative AMF (as an example from the third network node) might search for the UE.However, when the UE responds to the query, it will still initiate a service request to the overloaded AMF (such as the second network node). Thus, the alternate AMF (such as the third network node) always rejects the request message for contexts related to the same service due to the implementation nature of the requested service. In step S305, the third network node can transmit to the first network node a reply message that includes an indication of whether the request message is rejected or accepted. In the event that the third network node determines that the request message is rejected as described above in step S303, the third network node can transmit the response message which includes an indication that the request message is rejected. In this case, the response message may also include information about the reason for the rejection. For example, in onofr in / eznz / q / uili, the reason for rejection information can be defined as certain types of cause codes. As described earlier with reference to Figure 2, the rejection reason information can tell the first network code that the request message for the context is currently rejected, and the first network node can retry later. This could be based, for example, on the property information about the request message indicating that the request message implies reselection, at least due to overload control for the second network node, and / or that the third network node cannot retrieve the context from a database where the context is stored, for example, because the context is locked by the second network node. In other words, the rejection is ONLY valid for this specific request message. Alternatively, or in addition, the rejection reason information can instruct the first network code that the request message is rejected, and any subsequent request messages for contexts related to the same service will also be rejected, at least depending on the nature of the service implementation. In other words, the rejection reason information can instruct the first network node that it should not re-select the third network node for the request message for contexts related to the same service, based on the implementation nature of the requested service. From here on, an exemplary signaling sequence diagram of an exemplary reselection process according to an exemplary embodiment of the present invention will be described with reference to Figure 4, wherein method 200 is applied at the first network node and method 300 at the third network node for the reselection of the network node according to exemplary embodiments of the present invention. It should be noted that the following description focuses mainly on the signaling related to methods 200 and 300, and some other signals are not described in detail to avoid obscuring the principle of the present invention, such as steps S4_l to S4_7, which may be similar to steps SI 1 to SI 7 of the reselection process as shown in Figure 1. In Figure 4, the modification of the signaling related to methods 200 and 300 is shown in bold and italics, where steps S4_9 to S4_ll are involved. During steps S4 1 to S4 7, the Client has selected Server 1 in this example to provide, for example, Service A consumed by the Client, and a context related to Service A has been created. However, some events related to Server 1 occur, for example, Server 1 overload, or that the onofr in / eznz / q / uili Server 1 may be unreachable, or Server 1 may reject the Client's request message due to a temporary cause, etc. In S4_8, the Client may receive a request message for a context (resource) related to Server 1, for example, from an upstream NF or a UE. The Client may determine that a new selection of an alternative Server is required based on at least one of the following: - the Client cannot access Server 1, which may be, for example, polled by PING; for example, the Client cannot reach an original resource Unified Resource Identifier (URI) in a case where Server 1 is an NF producer, or cannot reach a notification / callback URI in a case where Server 1 is an NF consumer; the Client determines that Server 1 is overloaded, for example, by receiving, from the second network node, OCI indicating overload information from the second network node;or receiving, from the second network node, a status code (for example, 429 / 503) indicating that the second network node rejects a request message, and deriving overload information from the second network node from a proportion of the number of request messages that are rejected with the status code by the second network node versus a total number of request messages, as specified in Client-Side Adaptive Acceleration for Overload Control in Annex A of 3GPP TS 29.500 V17.1.0, or the Client has transmitted the request message to Server 1 as an attempt, but Server 1 rejects the request message with a temporary cause code. The Client can reselect Server 2, which is located in the same set as Server 1, since the context is stored in the common central database, for example, in the UDSF of the set, which can be accessed by all servers in the same set. In S4_9, the Client can transmit a request message for the context (for example, Nnfp_service, an operation request) to Server 2. The request message can include property information about the request message, which can include at least one of: information indicating that the request message involves a reselection due to a failure to reach Server 1; information indicating that the request message involves a reselection due to overload control for Server 1; or information indicating that the request message involves a reselection due to a temporary rejection of Server 1 during a last attempt to Server 1. The ownership information about the request message can also include relay information indicating whether the request message involving the reselection has been previously transmitted to Server 1, that is, whether the Client has attempted to transmit the request message. For example, a Boolean parameter (True or False) can be used. In a case where the relay information indicates that the request message involving reselection has been transmitted to Server 1 previously, e.g., True, the relay information may also include the number of attempts to Server 1, in which case the Client has transmitted the request message to Server 1 but Server 1 rejects the request message with a temporary cause code. Server 2 can determine whether the received request message is rejected or accepted based at least on proprietary information about the request message, based on at least one of: the proprietary information about the request message, the nature of the implementation of the Service A requested, or a fact that Server 2 cannot retrieve the database context where the context is stored. onofr in / eznz / q / uιλι For example, Server 2 may decide to reject the request message based on the ownership information received, which indicates that the request message involves reselection due to overload control for Server 1, and the fact that Server 2 cannot retrieve the context from the database where the context is stored, for example, because the context is locked by Server 1. That is, the rejection is ONLY valid for this request message. For another example, Server 2 may decide to reject the request message based on the ownership information received, which indicates that the request message implies reselection due to overload control for Server 1 and the implementation nature of Service A. That is, Server 2 always rejects the request message for contexts related to the same Service A due to the implementation nature of the requested Service A. If Server 2 determines that the request message is rejected, Server 2 may include the corresponding reason for rejection information in a response message. The rejection reason information can tell the Client that the request message for the context is currently rejected and the Client can retry it later, for example, based on the fact that the property information about the request message indicates that the request message involves at least reselection due to overload control for Server 1, and / or that Server 2 cannot retrieve the context from a database where the context is stored, for example, because the context is locked by Server 1. That is, the rejection is ONLY valid for this request message. Alternatively, or in addition, the rejection reason information can tell the Client that the request message is rejected and any subsequent request messages for contexts related to the same Service A will be rejected, at least according to the nature of the Service A implementation. That is, the rejection reason information can tell the Client that they should not reselect Server 2 for the request message for contexts related to the same Service A, based on the implementation nature of the requested Service A. Then, in S4_10, Server 2 can transmit the response message (for example, Nnfp serviceA operation response) to the Client. The response message can include an indication that the request message is accepted (for example, Accept). Alternatively, the response message can include an indication that the request message is rejected (for example, Reject) as well as the corresponding reason for rejection, as described above. After receiving the response message indicating that the request message is rejected and the corresponding reason for rejection, in S4_ll, the Client can store the reason for rejection information included in the received response message for later reselection determination to avoid further reselections of Server 2 for the same reason for rejection. The exemplary procedure as shown in Figure 4 relates to modifications, for example, in the following sections of 3GPP TS 29.500 V17.1.0, which are shown underlined. onofr in / eznz / q / uιλι 5.2.3.3 Optional to support custom headers 5.2.3.3.1 Generalities 3GPP NF Services can support the HTTP custom headers specified in Table 5.2.3.3-1 below. Table 5.2.3.3-1 also provides a description of each custom header and the regulatory requirements for when to include them. Table 5.2.3.3-1: Optional custom HTTP headers ano»? in / cznz / q / yi Name Reference Description 3gpp-Sbi-Sender-Timestamp Clause 5.2.3.3.2 This header can be used to indicate the date and time (with millisecond granularity) at which an HTTP request or response originates. This can be used, for example, to measure signaling delays between different NF service instances. 3gpp-Sbi-Max-RspTime Clause 5.2.3.2.3 This header can be used in an HTTP request to indicate the time during which the HTTP client waits for a response. See clause 6.11.2. 3gpp-Sbi-Alternate-Chof-ld Clause 5.2.3.2.3.4 This header can be used to indicate a primary or secondary CHF instance, for example, when using indirect communication with delegated discovery. See clause 6.10.3.x. 3qpp-Sbi-Request- Property Clause 5.2.3.2.This header can be used to indicate additional information related to an HTTP request, for example, whether the request involves a reselection to an alternate NF, and / or whether the request is a relay of a request to an (alternative) NF. *** Next change *** 5.2.3.2. x 3gpp-Sbi-Request-Property The header contains additional information related to an HTTP request message, for example, when the HTTP request message should address an existing resource / session context and if the HTTP request is redirected to an alternate NF. The header encoding follows ABNF as defined in IETF RFC 7230

[12] . 3gpp-Sbi-Request-Property = 3gpp-Sbi-RequestProperty OWS retrans= retransvalue !*(; OWS parameter OWS receivedrejectioncause]) retransvalue = true / false parameter = parametername = token parametername = reason reason = reason = OWS cause οποί? in / cznz / q / υιλι The following parameters are defined: - reason: indicates the reason why the NF forwards or redirects the HTTP request message. This can take one of the following values: - unreachable: indicates that the HTTP request is redirected to an alternate NF because the request URI (e.g., the resource URI or the notification / callback URI) is not reachable; - overloaded: indicates that the HTTP request is redirected to an alternate NF as a result of applying overload control, performing a redirect to an alternate NF (see clause 6.4.3.5.1) ; temporal-rejection-cause: indicates that the HTTP request is retransmitted to the same NF or to an alternative due to a temporary rejection. receivedrejectioncause: Indicates a temporary rejection cause received from the NF (for the last attempt) as defined in clause 5.2.7.2, when the retransmission value is set to true and the reason is set to temporary rejection cause. The cause data type is specified in clause 5.2.4.1 of 3GPP TS 29.571

[13] . anofr in / cznz / q / uili * * * Next change * * * * 6.4.1 General Service-based interfaces use HTTP / 2 over TCP for communication between NF services. TCP provides transport-level congestion control mechanisms as specified in IETF RFC 5681

[16] , which can be used for congestion control between two TCP endpoints (i.e., hop-to-hop). HTTP / 2 also provides flow control and flow concurrency limiting mechanisms that can be configured for connection-level congestion control, as specified in IETF RFC 7540 [7]. In addition to TCP and HTTP / 2 congestion control mechanisms, the following end-to-end application-level overload control mechanisms are defined. Overload control allows an NF Service Producer, NF Service Consumer, or SCP to be overloaded to gracefully reduce its incoming signaling load. This is achieved by instructing NF Service Consumers to reduce the number of service requests they send or by instructing NF Service Producers to reduce the number of notification requests they send, respectively, according to their available signaling capacity to successfully process the requests. An NF Service Producer, NF Service Consumer, or SCP is overloaded when it operates above its signaling capacity. When an NF Service Consumer instructs you to apply overload control, the NF Service Producer shall carry out signaling reduction to the NF Service Consumer only for notifications or callback requests in accordance with the scope of the overload, and not for any NF service that may be produced by the same NF (for which the NF may advertise OCI separately when acting as an NF producer), even when the scope of the overload is at the NF Instance level or the NF Set level. Overload control aims to divert incoming traffic as close as possible to the traffic source, usually when an overload has occurred (reactive action), to prevent the propagation of the problem within the network and avoid the use of resources by intermediate entities in the network to signal that it cannot be served by the overloaded entity. Overload control should continue to allow preferential treatment for priority users (e.g., MES) and emergency services. Overload control can be carried out based on the HTTP status codes returned in HTTP responses (as defined in clause 6.4.2) or based on the Overload Control Information (OCI) indicated in the HTTP request or response (as defined in clause 6.4.2). The NF that implements overload control may limit a fraction of the request messages or redirect some request messages to an alternative NF, if possible, to reduce the number of HTTP requests sent to an overloaded NF. (See clause 6.4.3.5) *** Next change *** Qnown / cznz / q / Y 6.4.3.5.1 Message Limitation As part of overload mitigation, the overload control application NF, i.e., an entity receiving OCI (with a non-zero overload reduction metric), shall reduce the total number of request messages that would otherwise have been sent to the overloaded peer(s) corresponding to the received scope, for example, to all NF instances of the NF Set when the scope indicates an NF Set ID, and shall not redirect its requests to another entity belonging to the same scope. This will be achieved by discarding a fraction of the service request messages in proportion to the peer's overhead level. This is called request message limiting; or by redirecting some of the request messages to an alternative NF if possible, for example, when the binding entity for reselection is larger than the scope of the overhead. When redirecting the request to an alternate NF to address an existing session / resource context, the NF can include a 3gpp-5bi-Request-Property header to indicate that the request is being redirected to an alternate NF as a result of applying overloading. (See clause 5.2.3.2.x) onofr in / eznz / q / uili Message limiting will apply only to HTTP requests (any service request, including notification requests). The network functions will support and use the Loss algorithm as specified in clause 6.4.3.5.2. * * * for information * * * * onofr in / cznz / q / uili 6.4.3.5.2 Loss Algorithm An overloaded NF Services producer / consumer / SCP will request its peers to reduce the number of HTTP requests they would otherwise send by transmitting in the OCI header the percentage of traffic reduction requested within the Overload Reduction Metric parameter, as specified in clause 6.4.3.4.3. Recipients of the Overhead Reduction Metric must reduce the number of request messages by that percentage, either by redirecting them to an alternate destination if possible (for example, an HTTP POST request for the Nsmf service operation PDUSession CreateSMContext can be sent to an alternate SMF in the same SMF set, if olcScope is at the NF instance level and the service resource binding indication is for an SMF set), or by failing the request and treating it as if it had been rejected by the target entity. NOTE: For example, if an NF services Producer / Consumer / SCP requests a peer to reduce traffic by 10%, then that peer limits 10% of the traffic that would otherwise have been sent to this NF services Producer / Consumer / SCP. *** End of change *** The structure of a first network node, according to an exemplary embodiment of the present invention, will now be described with reference to Figure 5. Figure 5 schematically shows a block diagram of node 500 according to an exemplary embodiment of the present invention. The first network node 500 in Figure 5 can implement Method 200 as described above with reference to Figure 2. Consequently, any detailed description of the first network node 500 could refer to the corresponding description of Method 200 in Figure 2 and the signaling sequence diagram in Figure 4, as discussed above, and will therefore be omitted here for simplicity. As described above, the first network node, such as a Client, can be an NF service consumer or an SCP (for example, for regular onofr in / eznz / q / uli request messages), or an NF service producer (for example, for notification request messages), or similar in future developments. This first node transmits a request message, such as an HTTP request message. Consequently, the second or third network node receiving the request message can be called a Server, which may refer to an NF service producer, an SCP, an NF service consumer, or similar in future developments, in any appropriate scenario. For example, an NF service consumer (such as a Client) can consume a service provided by an NF service producer (such as a Server). As shown in Figure 5, the first network node 500 can include a determination unit 501 and a transmission unit 503. The determination unit 501 can be configured to determine and reselect a third network node that can provide the service for the context that was provided by the second network node. Preferably, determination unit 501 can be further configured to determine the reselection of the third network node based on at least one of the following facts: - the first network node 500 cannot reach the second network node, onofr in / eznz / q / uli the first network node 500 determines that the second network node is overloaded, or - The first network node 500 transmitted the request message to the second network node as an attempt, but the second network node rejected the request message with a temporary cause code. The 503 transmission unit can be configured to transmit a context request message to the third network node, where the request message includes proprietary information about the request message. As described above, ownership information about the request message includes at least one of: Information indicating that the request message involves a reselection due to a failure to reach the second network node, - information indicating that the request message involves a reselection due to overload control for the second network node, or information indicating that the request message involves a reselection due to a temporary rejection of the second network node during a last attempt to the second network node. In an exemplary mode, the first 500 network node can also include an onofr in / eznz / q / uli overload control unit (not shown), which can be configured to perform overload control for the second network node based on overload information from the second network node. Overload information can be indicated by OCI received from the second network node, or it can be derived from the ratio of a number of request messages rejected by the second network node with a status code versus the total number of request messages, where the status code is received from the second network node, indicating that the second network node rejects a request message. In an exemplary mode, the ownership information about the request message may also include relay information indicating that the request message involving the reselection has been previously transmitted to the second network node. Alternatively or additionally, the relay information may also include the number of attempts to the second network node, in which case the first network node 500 has transmitted the request message to the second network node, but the second network node rejects the request message with a temporary cause code. In an exemplary mode, the first 500 network node may also include a receiving unit (not shown), which may be configured to receive, from the third network node, a reply message corresponding to the request message, wherein the reply message includes an indication of whether the request message is rejected or accepted by the third network node. In the event that a response message is received that includes an indication of the request message being rejected by the third network node, the response message may also include reason for rejection information, which may indicate that: - the request message is currently rejected based on the fact that the ownership information about the request message indicates that the request message involves reselection at least due to overload control for the second network node, and / or that the third network node cannot retrieve the context from a database where the context is stored, or - the request message is rejected and any subsequent request message for contexts related to the same service will be rejected at least based on the nature of the service implementation. Alternatively or additionally, the first 500 network node may also include a storage unit (not shown), which can be configured to store the rejection cause information included in the onofr in / eznz / q / uli response message received for a subsequent reselection determination. The structure of a first network node, according to another exemplary embodiment of the present invention, will now be described with reference to Figure 6. Figure 6 schematically shows a block diagram of a first network node 600 according to an exemplary embodiment of the present invention. The node 600 in Figure 6 can carry out Method 200 as described above with reference to Figure 2. Consequently, any detailed description of the first network node 600 could refer to the corresponding description of Method 200 in Figure 2 and the signaling sequence diagram in Figure 4, as described above, and will therefore be omitted here for simplicity. As described above, the first network node, such as a Client, can be an NF service consumer or an SCP, for example, for regular request messages, or an NF service producer, for example, for notification request messages, or similar in other future developments, that transmits a request message, for example, an HTTP request message, and consequently, the second or third network node that receives the request message can be called a Server, which can refer to an NF service producer, an SCP, an NF service consumer, or similar in other developments. Qnown / eznz / q / Y futures in any appropriate scenario. For example, an NF service consumer (such as a Client) can consume a service provided by an NF service producer (such as a Server). 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 CPU (central processing unit), microcontroller, DSP (digital signal processor), etc., suitable and capable of executing computer program instructions. The at least one memory 603 can be any combination of RAM (random access memory) and ROM (read-only memory). The at least one memory 603 can also include persistent storage, which, for example, can be any or a combination of magnetic memory, optical memory, solid-state memory, or even remotely mounted memory. 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, can cause the first network node 600 to carry out the actions, for example, of the procedures described above respectively along with figures 2 and 4, so they will be omitted here for simplicity. onofr in / eznz / q / uιλι The structure of a third network node, according to an exemplary embodiment of the present invention, will now be described with reference to Figure 7. Figure 7 schematically shows a block diagram of the third network node 700 according to an exemplary embodiment of the present invention. The third network node 700 in Figure 7 can implement Method 300 as described above with reference to Figure 3. Consequently, any detailed description of the third network node 700 could refer to the corresponding description of Method 300 in Figure 3 and the signaling sequence diagram in Figure 4 as discussed above, and will therefore be omitted here for simplicity. As described above, the first network node, such as a Client, can be an NF service consumer or SCP (for example, for regular request messages), or an NF service producer (for example, for notification request messages), or similar in future developments. This node transmits a request message, such as an HTTP request message. Consequently, the second or third network node receiving the request message can be called a Server, which may refer to an NF service producer, an SCP, an NF service consumer, or similar in future developments, in any appropriate scenario. For example, an NF service consumer (such as a Client) can consume a service provided by an NF service producer (such as a Server). As shown in Figure 7, the third network node 700 can include a receiving unit 701, a determining unit 703, and a transmitting unit 705. The 701 receiving unit can be configured to receive, from the first network node, a context request message, where the request message includes proprietary information about the request message. As described above, ownership information about the request message includes at least one of: Information indicating that the request message involves a reselection due to a failure to reach the second network node, - information indicating that the request message involves a reselection due to overload control for the second network node, or information indicating that the request message involves a reselection due to a temporary rejection of the second network node during a last attempt to the second network node. In an exemplary mode, the ownership information about the request message may also include retransmission information indicating that the request message involving reselection has been previously transmitted to the second network node. Alternatively or additionally, the relay information may also include the number of attempts to the second network node, in which case the first network node 500 has transmitted the request message to the second network node, but the second network node rejects the request message with a temporary cause code. The determination unit 703 can be configured to determine whether the request message is rejected or accepted at least based on the ownership information about the request message. Preferably, determination unit 703 can be further configured to determine whether the request message is rejected or accepted based on at least one of: ownership information about the request message, the nature of the implementation of the requested service, or a fact that the third network node cannot retrieve the context from the database where the context is stored. The 705 transmission unit can be configured to transmit, to the first network node, a reply message that includes an indication of whether the request message is rejected or accepted. onofr in / eznz / q / uιλι In a case where the determination unit 703 determines that the request message is rejected as described above, the transmission unit 705 can be further configured to transmit the response message which includes an indication that the request message is rejected. In this case, the response message may also include information about the reason for the rejection. For example, the reason for rejection information can be defined as certain types of cause codes. The rejection reason information can tell the first network node that the request message for the context is currently rejected, and the first network node can retry later. This could be based, for example, on the fact that the property information about the request message indicates that the request message is involving reselection, at least due to overload control for the second network node, and / or that the third network node cannot retrieve the context from a database where the context is stored, for example, because the context is locked by the second network node. In other words, the rejection is ONLY valid for this specific request message. Alternatively, or in addition, the rejection reason information can tell the first network node that the request message `anofr in / cznz / q / uli` is rejected, and any subsequent request messages for contexts related to the same service will also be rejected, at least based on the nature of the service implementation. In other words, the rejection reason information can tell the first network node that it should not re-select the third network node for request messages in contexts related to the same service, based on the implementation nature of the requested service. The structure of a third network node, according to another exemplary embodiment of the present invention, will now be described with reference to Figure 8. Figure 8 schematically shows a block diagram of a third network node 800 according to an exemplary embodiment of the present invention. The third network node 800 in Figure 8 can implement Method 300 as described above with reference to Figure 3. Consequently, any detailed description of the third network node 800 could refer to the corresponding description of Method 300 in Figure 3 and the signaling sequence diagram in Figure 4 as discussed above, and will therefore be omitted here for simplicity. As described above, the first node in the network, acting as a Client, can be an NF service consumer or an SCP (for example, for regular request messages), or an NF service producer (for example, for notification request messages), or similar in future developments. This node transmits a request message, such as an HTTP request message. Consequently, the second or third network node receiving the request message can be called a Server, which can refer to an NF service producer, an SCP, an NF service consumer, or similar in future developments, in any appropriate scenario. For example, an NF service consumer (such as a Client) can consume a service provided by an NF service producer (such as a Server). As shown in Figure 8, the third 800 network node includes at least one 801 processor and at least one 803 memory. The at least one 801 processor includes, for example, any CPU (central processing unit), microcontroller, DSP (digital signal processor), etc., suitable and capable of executing computer program instructions. The at least one 803 memory can be any combination of RAM (random access memory) and ROM (read-only memory). The at least one 803 memory can also include persistent storage, which, for example, can be any combination of magnetic, optical, or solid-state memory, or even remotely mounted memory. The at least one 803 memory stores instructions executable by the at least one 801 processor. The instructions, when loaded from the at least one 803 memory and executed on the at least one 801 processor, can cause the third 800 network node to carry out the actions, for example, of the procedures described above respectively along with figures 3 and 4, so they will be omitted here for simplicity. The present invention also provides at least one software product in the form of non-volatile or volatile memory, for example, a non-transient computer-readable storage medium, an electrically erasable programmable read-only memory (EEPROM), flash memory, and a hard disk. The software product includes a software program. The software program includes: computer-readable code / instructions, which when executed by at least one processor 601 cause the first network node 600 to carry out the actions, for example, of the procedure described above together with figures 2 and 4; or computer-readable code / instructions, which when executed by at least one processor 801 cause the third network node 800 to carry out the actions, for example, of the procedures described above respectively together with figures 3 and 4. The software product can be configured as software code structured into software modules. The software modules could essentially carry out the actions of the flow illustrated in any of Figures 2 to 4. The processor may be a single CPU (central processing unit), but it could also include two or more processing units. For example, the processor may include general-purpose microprocessors; instruction set processors and / or related chipsets; and / or special-purpose microprocessors such as application-specific integrated circuits (ASICs). The processor may also include on-board memory for caching purposes. The computer program may be carried by a software product connected to the processor. The software product may include a non-transient, computer-readable storage medium on which the computer program is stored.For example, the software product can be flash memory, random access memory (RAM), read-only memory (ROM), or an EEPROM, and the software modules described above could, in alternative ways, be distributed in different software products in the form of memories. The present invention has been described above with reference to specific embodiments thereof. It should be understood that those skilled in the art may make various modifications, alterations, and additions without departing from the spirit and scope of the present invention. Therefore, the scope of the present invention is not limited to the particular embodiments mentioned above but is defined only by the appended claims.

Claims

1. A method (200) on a first network node for reselecting a network node for a service-related context, wherein the first network node has selected a second network node to provide the service consumed by the first network node, and the service-related context has been created, wherein the method (200) comprises: determining (S201) to reselect a third network node that can provide the service for the context that was provided by the second network node; and transmitting (S203) a request message for the context to the third network node, wherein the request message comprises property information about the request message.

2. The method (200) according to claim 1, wherein said proprietary information about the request message comprises at least one of: information indicating that the request message involves a reselection due to a failure to reach the second network node, information indicating that the request message involves a reselection due to overload control for the second network node, or information indicating that the request message involves a reselection due to a temporary rejection of the second network node during a last attempt to the second network node.

3. The method (200) according to claim 2, wherein the overload control for the second network node is carried out by the first network node based on overload information from the second network node. The overload information is indicated by overload control information 'OCI' received from the second network node, or the overload information is derived from a ratio between the number of request messages rejected by the second network node with a status code and the total number of request messages, wherein the status code is received from the second network node, indicating that a request message is being rejected by the second network node.

4. The method (200) according to any of claims 1 to 3, wherein said proprietary information about the request message further comprises retransmission information indicating that the request message involving reselection has been previously transmitted to the second network node.

5. The method (200) according to claim 4, wherein the retransmission information further comprises a number of attempts to the second network node, in which case the first network node has transmitted the request message to the second network node, but the request message is rejected by the second network node with a temporary cause code.

6. The method (200) according to any one of claims 1 to 5, wherein said proprietary information about the request message is comprised in: a new or existing custom header of the request message, or a message body of the request message.

7. The method (200) according to any one of claims 1 to 6, wherein the first network node determines to reselect the third network node based on at least one of the following facts: the first network node cannot reach the second network node, the first network node determines that the second network node is overloaded, or the first network node has transmitted the request message to the second network node as an attempt, but the second network node rejects the request message with a temporary cause code.

8. The method (200) in accordance with any of claims 1 to 7, further comprising: receiving, from the third network node, a reply message corresponding to the request message, wherein the reply message comprises an indication of whether the request message is rejected or accepted by the third network node.

9. The method (200) according to claim 8, wherein in an instance where a reply message is received comprising an indication of the request message being rejected by the third network node, the reply message further comprises rejection cause information, indicating that: the request message is currently rejected based on the fact that proprietary information about the request message indicates that the request message involves reselection at least due to overload control for the second network node, and / or that the third network node cannot retrieve the context from a database where the context is stored, or the request message is rejected and any subsequent request messages for contexts related to the same service will be rejected at least in accordance with the nature of the service implementation.

10. The method (200) according to claim 9, further comprising: storing the rejection cause information contained in the received response message for subsequent reselection determination.

11. The method (200) according to any one of claims 1 to 10, wherein the request message is an 'HTTP' hypertext transfer protocol request message.

12. The method (200) according to any one of claims 1 to 11, wherein the first network node functions as an HTTP client to transmit the request message, and comprises at least one of: a network function service consumer 'NF'; a service communication proxy 'SCP'; or an NF service producer.

13. The method (200) according to any of claims 1 to 13, wherein the second network node or the third network node functions as an HTTP server to respond to the request message, and comprises at least one of: an NF services consumer; an SCP, or an NF services producer.

14. A method (300) on a third network node for reselecting a network node for a service-related context, wherein a first network node has selected a second network node to provide the service consumed by the first network node, and the service-related context has been created, wherein the method (300) comprises: receiving (S301), from the first network node, a request message for the context, wherein the request message comprises proprietary information about the request message; determining (S303) whether the request message is rejected or accepted at least on the basis of the proprietary information about the request message; and transmitting (S305), to the first network node, a response message comprising an indication of whether the request message is rejected or accepted.

15. The method (300) according to claim 14, wherein said proprietary information about the request message comprises at least one of: information indicating that the request message involves a reselection due to a failure to reach the second network node, information indicating that the request message involves a reselection due to overload control for the second network node, or information indicating that the request message involves a reselection due to a temporary rejection of the second network node during a last attempt to the second network node.

16. The method (300) according to claim 15, wherein the overload control for the second network node is carried out by the first network node based on overload information from the second network node, wherein the overload information is indicated by overload control information 'OCI' received from the second network node, or the overload information is derived from a ratio between a number of request messages rejected by the second network node with a status code versus a total number of request messages, wherein the status code is received from the second network node, indicating that a request message is being rejected by the second network node.

17. The method (300) according to any of claims 14 to 16, wherein said proprietary information about the request message further comprises retransmission information indicating that the request message involving reselection has been transmitted previously.

18. The method (300) according to claim 17, wherein the retransmission information further comprises a number of attempts to the second network node, in which case the first network node has transmitted the request message to the second network node, but the request message is rejected by the second network node with a temporary cause code.

19. The method (300) according to any of claims 14 to 18, wherein such proprietary information about the request message is comprised in: a new or existing custom header of the request message, or a message body of the request message.

20. The method (300) according to any of claims 14 to 19, wherein the third network node determines whether the request message is rejected or accepted based on at least one of: the nature of the implementation of the requested service, or a fact that the third network node cannot retrieve the context from a database where the context is stored.

21. The method (300) according to any of claims 14 to 19, wherein the third network node transmits the reply message comprising an indication that the request message is rejected, in an instance where the third network node determines that the request message anofr in / cznz / q / uili is rejected.

22. The method (300) according to claim 21, wherein the response message further comprises rejection cause information, indicating that: the request message is currently rejected based on the fact that proprietary information about the request message indicates that the request message involves reselection at least due to overload control for the second network node, and / or that the third network node cannot retrieve the context from a database where the context is stored, or the request message is rejected and any subsequent request message for contexts related to the same service will be rejected at least in accordance with the nature of the service implementation.

23. The method (300) according to any of claims 14 to 22, wherein the request message is an 'HTTP' hypertext transfer protocol request message.

24. The method (300) according to any of claims 14 to 23, wherein the first network node functions as an HTTP client to transmit the request message, and comprises at least one of: an NF network function service consumer; an 'SCP' service communication proxy; or an NF service producer.

25. The method (300) according to any of claims 14 to 24, wherein the second network node or the third network node functions as an HTTP server to respond to the request message, and comprises at least one of: an NF services consumer; an SCP; or an NF services producer.

26. A first network node (600) configured for network node reselection for a service-related context, wherein the first network node has selected a second network node to provide a service to be consumed by the first network node, and the service-related context has been created, wherein the first network node (600) comprises: at least one processor (601), and at least one memory (603), which stores instructions that, when executed on the at least one processor (601), cause the first network node (600): to determine to reselect a third network node that can provide the service for the context that was provided by the second network node; and to transmit a request message for the service to the third network node, wherein the request message comprises property information about the request message.

27. The first network node (600) according to claim 26, wherein the instructions, when executed on the at least one processor (601), further cause the first network node (600) to carry out the method according to any one of claims 2 to 13.

28. A third network node (800) configured for network node reselection for a service-related context, wherein a first network node has selected a second network node to provide the service consumed by the first network node, and the service-related context has been created, wherein the third network node (800) comprises: at least one processor (801), and at least one memory (803), which stores instructions that, when executed on at least one processor (801), cause the third network node (800): to receive, from the first network node, a request message for the context, wherein the request message comprises proprietary information about the request message, and to determine whether the request message is rejected or accepted at least on the basis of the proprietary information about the request message;and onofr in / eznz / q / uili transmit, to the first network node, a response message 88 comprising an indication of whether the request message is rejected or accepted.; 29. The third network node (800) according to claim 28, wherein the instructions, when executed on the at least one processor (801), further cause the third network node (800) to carry out the method according to any one of claims 15 to 25.

30. A computer-readable storage medium having computer program instructions stored therein, the computer program instructions, when executed by at least one processor, cause the at least one processor to carry out the method in accordance with any one of claims 1 to 14.

31. A computer-readable storage medium having computer program instructions stored therein, the computer program instructions, when executed by at least one processor, cause the at least one processor to carry out the method in accordance with any of claims 15 to 25.

Images