Method, system, and computer readable medium for determining time-dependent parameter values of a communication network

Abstract

Methods, systems, and computer-readable media for determining time-dependent parameter values for a communication network are disclosed. A method for determining time-dependent parameter values for a communication network occurs at a network function (NF) repository function (NRF) comprising at least one processor. The method comprises receiving a service request message from a first network function (NF), determining a time-dependent parameter value associated with the service request message using network information and / or NF information, and generating and sending a service response message to the first NF indicating the time-dependent parameter value.

Description

[0001] Priority Statement

[0002] This application claims priority to U.S. Patent Application Serial No. 17 / 331,620, filed May 26, 2021, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] The topics described herein relate to improving communications in fifth-generation (5G) and subsequent generation communication networks. More specifically, the topics described herein relate to methods, systems, and computer-readable media for determining time-related parameter values ​​for 5G and subsequent generation communication networks. Background Technology

[0004] In fifth-generation (5G) communication networks, network nodes that provide services are called producer network functions (NFs). Network nodes that consume services are called consumer NFs. Depending on whether a network function is consuming or providing services, it can be either a producer NF or a consumer NF.

[0005] A given producer NF can have multiple service endpoints, where a service endpoint is a contact point used for one or more NF instances hosted by the producer NF. A service endpoint is identified by a combination of Internet Protocol (IP) addresses and port numbers, or by a fully qualified domain name that resolves to the IP address and port number on the network node hosting the producer NF. An NF instance is an instance of a producer NF that provides a service. A given producer NF can include more than one NF instance. It should also be noted that multiple NF instances can share the same service endpoint.

[0006] Producer NFs register with the NF Repository Function (NRF). The NRF maintains service profiles of available NF instances that identify the services supported by each NF instance. Consumer NFs can subscribe to receive information about producer NF instances that have registered with the NRF. Besides consumer NFs, another type of network node that can subscribe to receive information about NF service instances is the Service Communication Agent (SCP). The SCP subscribes to the NRF and obtains reachability and service profile information about producer NF service instances. Consumer NFs connect to the Service Communication Agent, and the Service Communication Agent load balances traffic among producer NF service instances providing the required services, or routes traffic directly to the destination producer NF instance.

[0007] Besides SCPs, other examples of intermediate proxy nodes or groups of network nodes that route traffic between producer and consumer NFs include Secure Edge Protection Proxies (SEPPs), serving gateways, and nodes in 5G serving meshes. SEPPs are network nodes used to protect control plane traffic exchanged between different 5G Public Land Mobile Networks (PLMNs). Therefore, SEPPs perform various amounts of message filtering, policing, and topology hiding on Application Programming Interface (API) messages.

[0008] In 5G and various other communication networks, timing issues can impact connectivity and availability. For example, if access tokens or subscriptions expire too quickly, network application (NF) may fail to receive the expected or anticipated responses. Therefore, improving communication networks requires addressing or mitigating timing issues. Summary of the Invention

[0009] Methods, systems, and computer-readable media for determining time-related parameter values ​​of a communication network are disclosed. One method for determining time-related parameter values ​​of a communication network occurs at a network function (NF) store function (NRF) including at least one processor. The method includes: receiving a service request message from a first NF; determining time-related parameter values ​​associated with the service request message using network information and / or NF information; and generating and sending a service response message indicating the time-related parameter values ​​to the first NF.

[0010] An example system for determining time-related parameter values ​​of a communication network includes an NRF, which includes at least one processor and a memory. The NRF is configured to: receive a service request message from a first NF; determine time-related parameter values ​​associated with the service request message using network information and / or NF information; and generate and send a service response message indicating the time-related parameter values ​​to the first NF.

[0011] An example non-transitory computer-readable medium includes computer-executable instructions implemented therein, which, when executed by at least one processor of at least one computer, cause the at least one computer to perform the following steps at an NRF including at least one processor: receiving a service request message from a first NF; determining a time-related parameter value associated with the service request message using network information and / or NF information; and generating and sending a service response message indicating the time-related parameter value to the first NF.

[0012] Based on aspects of the subject matter described herein, at least some network information or NF information (e.g., for determining time-related parameter values) can be obtained periodically or non-periodically from one or more data sources.

[0013] Based on aspects of the subject matter described in this article, one or more data sources may include local data repositories, remote data sources, Network Data Analysis Functions (NWDAF), or NF data providers.

[0014] Based on the aspects of the topics described in this article, at least some network information can be obtained using the Nnwdaf_EventsSubscription service or the Nnwdaf_AnalyticsInfo service.

[0015] Based on aspects of the subject matter described herein, determining time-related parameter values ​​may include determining that an NRF, a first NF, or a network entity may be experiencing a change in congestion state, a change in workload, or a change in operational state; and, in response to such determination, adjusting the time-related parameter values ​​from default or previous values.

[0016] Depending on the aspects of the subject matter described in this article, (e.g., time-related parameters) default or previous values ​​may be predetermined by the network operator or may be generated using predetermined policies or rules.

[0017] Based on aspects of the subject matter described herein, determining time-related parameter values ​​may include determining that a service request message or related message requires NRF-to-NRF forwarding; and in response to that determination, increasing the time-related parameter value from an initial or default value.

[0018] Based on aspects of the subject matter described herein, determining time-related parameter values ​​may include determining that a service request message or related message may be an inter-PLMN message; and in response to such determination, increasing the time-related parameter value from an initial value or a default value.

[0019] Based on aspects of the subject matter described in this article, service request messages may include NF registration request messages, NF update request messages, NF state subscription request messages, NF discovery request messages, or NF access token request messages.

[0020] Based on the aspects of the topics described in this article, time-related parameter values ​​can indicate NF heartbeat intervals, NF subscription validity periods, NF discovery validity periods, NF access token expiration periods, or Hypertext Transfer Protocol (HTTP) header retry timers.

[0021] The subjects described herein can be implemented in hardware, software, firmware, or any combination thereof. Therefore, as used herein, the terms “function,” “node,” or “module” refer to hardware, which may also include software and / or firmware components for implementing the described features. In one example implementation, the subjects described herein can be implemented using a computer-readable medium having computer-executable instructions stored thereon, which, when executed by a computer’s processor, control the computer to perform steps. Example computer-readable media suitable for implementing the subjects described herein include non-transitory computer-readable media, such as disk storage devices, on-chip memory devices, programmable logic devices, and application-specific integrated circuits (ASICs). Furthermore, computer-readable media implementing the subjects described herein can reside on a single device or computing platform, or can be distributed across multiple devices or computing platforms. Attached Figure Description

[0022] The subject matter described in this article will now be explained with reference to the accompanying drawings, in which:

[0023] Figure 1 This is a network diagram illustrating the fifth-generation (5G) network architecture.

[0024] Figure 2 This is a diagram illustrating example network nodes used to determine the values ​​of time-related parameters in a communication network;

[0025] Figure 3 This is a message flow diagram of an example NRF that uses network information and / or NF information to dynamically determine the values ​​of time-related parameters.

[0026] Figure 4 This is a diagram illustrating example rule data used to determine rules based on rule ID and related time-related parameter values.

[0027] Figure 5 This is a diagram illustrating example default values ​​for various time-related parameters; and

[0028] Figure 6 This is a flowchart illustrating an example process for determining the values ​​of time-related parameters in a communication network. Detailed Implementation

[0029] The topics described in this document relate to methods, systems, and computer-readable media for determining time-related parameter values ​​in communication networks. In 5G communication networks defined by the 3rd Generation Partnership Project (3GPP), the Network Function (NF) Storehouse Function (NRF) can determine various time-related parameter values ​​(e.g., timer values ​​and validity time values) for various service operations. However, current NRF implementations use statically configured or consistently agreed-upon values ​​for various time-related parameters (e.g., NF heartbeat intervals (e.g., 3GPP heartbeat timers), NF subscription validity time, NF discovery validity time, NF access token expiration time, or HTTP header retry timers (e.g., values ​​in the "Retry-After" HTTP header parameter field)). Furthermore, 3GPP Technical Specification (TS) 29.510 does not define a mechanism for NRF functions to determine time-related parameter values ​​by considering dynamic network and / or deployment conditions. Various problems, such as connectivity issues and / or timing problems, can arise when time-related parameter values ​​are not suitable for the relevant use case or scenario (e.g., current network conditions or other factors affecting one or more NFs). For example, statically configured time-related parameter values ​​may not allow for effective communication between NFs or other network elements, for example, because some network use cases or scenarios (e.g., communication across different locations and PLMNs) may cause various delays.

[0030] Based on some aspects of the subject matter described herein, methods, systems, mechanisms, and / or techniques are disclosed for determining time-related parameter values ​​of a communication network using acquired network information and / or NF information. For example, an NRF according to various aspects described herein can be configured to receive a service request message from a first NF; determine time-related parameter values ​​associated with the service request message using network information and / or NF information; and generate and send a service response message indicating the time-related parameter values ​​to the first NF. In this example, the network information and / or NF information used in the determination can be obtained periodically or non-periodically from various data sources such as a Network Data Analysis Function (NWDAF) or another NF data provider (e.g., an NF measurement server).

[0031] Advantageously, by utilizing one or more techniques, systems, and / or methods described herein, NRFs or other entities can determine time-related parameter values ​​based on various information, such as dynamic network conditions and / or NF health or performance metrics. Furthermore, since some time-related parameter values ​​(e.g., NF heartbeat interval values ​​and / or HTTP header retry timer values) can directly affect the amount and / or frequency of traffic sent by NFs, dynamic determination of these values ​​can reduce traffic processing load or improve resource utilization at both the NF and the NRF. For example, by increasing the allowed time between consecutive heartbeat messages when network congestion is detected, the NF can spend less time sending such messages, and the NRF can spend less time processing them. In this example, the reduction in heartbeat messages can also help reduce congestion in the network. Similar effects can be seen by increasing other time-related parameter values, such as NF subscription validity time, NF discovery validity time, and NF access token expiration time. Furthermore, by leveraging one or more aspects described herein, the sample NRF can improve overall core network performance by determining time-related parameter values ​​(e.g., optimized and / or use-case-based timer values) using current or recent network information and / or NF information. Moreover, the sample NRF based on the aspects described herein is fully backward compatible, can operate without affecting NFs from various vendors, and does not require changes to existing 3GPP-defined 5GC call flows.

[0032] Reference will now be made in detail to various embodiments of the subject matter described herein, examples of which are shown in the accompanying drawings. Wherever possible, the same reference numerals will be used throughout the drawings to refer to the same or similar parts.

[0033] Figure 1 This is a block diagram illustrating an example 5G system network architecture (e.g., a home 5G core (5GC) network). Figure 1 The architecture includes NRF 100 and SCP 101, which can reside within the same Home Public Land Mobile Network (PLMN). As described above, NRF 100 can maintain profiles of available producer NF service instances and their supported services, and allows consumer NFs or SCPs to subscribe to and be notified of new / updated producer NF service instance registrations. SCP 101 can also support producer NF instance selection and service discovery. SCP 101 can perform load balancing of connections between consumer and producer NFs. Furthermore, using the methods described herein, SCP 101 can perform selection and routing based on preferred NF locations.

[0034] NRF 100 is a repository of service profiles or NFs for producer NF instances. To communicate with a producer NF instance, a consumer NF or SCP must obtain an NF or service profile or a producer NF instance from NRF 100. An NF or service profile can be a JavaScript Object Notation (JSON) data structure defined in 3GPP TS29.510. NF or service profile definitions include at least one of a Fully Qualified Domain Name (FQDN), an Internet Protocol (IP) version 4 (IPv4) address, or an IP version 6 (IPv6) address. Figure 1 In this context, any node (except NRF 100) can be either a consumer NF or a producer NF, depending on whether it is requesting or providing services. In the illustrated example, the nodes include a Policy Control Function (PCF) 102 that performs policy-related operations in the network, a Unified Data Management (UDM) function 104 that manages user data, and an Application Function (AF) 106 that provides application services. Figure 1 The node shown also includes a Session Management Function (SMF) 108, which manages the session between Access and Mobility Management Function (AMF) 110 and PCF 102. AMF 110 performs mobility management operations similar to those performed by a Mobility Management Entity (MME) in a 4G network. An Authentication Server Function (AUSF) 112 provides authentication services for user equipment (UE) seeking network access, such as UE 114.

[0035] The Network Slice Selection Function (NSSF) 116 provides network slicing services for devices seeking access to specific network capabilities and characteristics associated with a network slice. The Network Exposure Function (NEF) 118 provides an application programming interface (API) for application functions seeking information about Internet of Things (IoT) devices and other UEs attached to the network. NEF 118 performs functions similar to the Service Capability Exposure Function (SCEF) in 4G networks.

[0036] Radio Access Network (RAN) 120 connects UE 114 to the network via a radio link. This can be achieved using a g-Node B (gNB). Figure 1 (Not shown in the image) or other wireless access points to access RAN 120. User plane function (UPF) 122 can support various proxy functions for user plane services. An example of such proxy function is the Multipath Transmission Control Protocol (MPTCP) proxy function. UPF 122 can also support performance measurement functions, which UE 114 can use to obtain network performance measurements. Figure 1 The diagram also illustrates data network (DN) 124, through which the UE accesses data network services, such as Internet services.

[0037] The Secure Edge Protection Agent (SEPP) 126 filters incoming traffic from another PLMN and performs topology hiding for traffic leaving the home PLMN. SEPP 126 can communicate with the SEPP in the foreign PLMN that manages the security of the foreign PLMN. Therefore, traffic between NFs in different PLMNs can traverse two SEPP functions, one for the home PLMN and the other for the foreign PLMN.

[0038] SEPP 126 can utilize the N32-c and N32-f interfaces. The N32-c interface is the control plane interface between two SEPPs, used to perform initial handshakes (e.g., TLS handshakes) and negotiate various parameters for N32-f interface connections and related message forwarding. The N32-f interface is the forwarding interface between two SEPPs, used to forward various communications (e.g., 5GC request messages) between consumer NFs and producer NFs after application-level security protection.

[0039] One issue with existing 5G architectures is that current NRF implementations use statically configured or consistently agreed-upon values ​​for various time-related parameters. However, connectivity and / or timing problems can arise when these time-related parameter values ​​are not suitable for the relevant use case or scenario (e.g., current network conditions or other factors affecting one or more NFs).

[0040] It is important to recognize that, Figure 1 It is for illustrative purposes, and the above is about Figure 1 The various nodes and / or modules, locations and / or functions described can be changed, modified, added or removed.

[0041] Figure 2 This is a diagram illustrating an example network node 200 used to determine time-related parameter values ​​for a communication network (e.g., a 5G communication network). Node 200 may represent any suitable one or more entities for performing various aspects of authorization, registration, and / or configuration functions (e.g., using relevant network information and / or NF information to determine appropriate time-related parameter values). In some embodiments, node 200 may represent or include one or more 5GC NFs, such as NRF 100. In some embodiments, node 200 may represent or include a consumer NF or a producer NF. In some embodiments, node 200 may represent or include an authorization server, data repository, network gateway, network proxy, edge security device, or other functionality.

[0042] In some embodiments, node 200 or a related module (e.g., a parameter configuration module) may be configured (e.g., via programming logic) to determine time-related parameter values ​​(e.g., 3GPP network parameter values) using network information and / or NF information (e.g., obtained periodically or non-periodically from NWDAF 210 and / or (one or more) NF data providers 212). For example, node 200 or a related module may communicate with NWDAF 210 and / or (one or more) NF data providers 212 to obtain current network information or NF information periodically or periodically. In this example, node 200 or a related module may use the obtained information to determine one or more time-related parameter values ​​for various NF instances, NF1 207, NF2 208, or NF3 209. Example time-related parameter values ​​may include values ​​indicating NF heartbeat intervals (e.g., 3GPP heartbeat timers), NF subscription validity periods, NF discovery validity periods, NF access token expiration periods, or HTTP header retry timers (e.g., values ​​in the "Retry-After" HTTP header parameter field).

[0043] NWDAF 210 may represent a network node or device configured to perform various network analysis functions. For example, NWDAF 210 may include at least some of the NWDAF functions defined in 3GPP TS29.520. In some embodiments, NWDAF 210 may provide the Nnwdaf_EventsSubscription service, enabling NF service consumers to subscribe to / unsubscribe from notifications for different analytical information. Example notification events may include slice load level information, network slice instance load level information, service experience, NF load, network performance, anomalous behavior, UE mobility, UE communication, user data congestion, or quality of service (QoS) sustainability. In some embodiments, NWDAF 210 may provide the Nnwdaf_AnalyticsInfo service, enabling NF service consumers to request and obtain specific analytical information from NWDAF 210. Example analytical information obtainable from NWDAF 210 may include slice load level information, network slice instance load level information, service experience, NF load, network performance, anomalous behavior, UE mobility, UE communication, user data congestion, or quality of service (QoS) sustainability.

[0044] One or more NF data providers 212 may represent one or more network nodes or devices configured to generate and / or provide NF metrics or other relevant NF information. For example, one or more NF data providers 212 may provide various types of metrics and / or data accessible to node 200, modules for determining time-related parameter values, and / or data repositories accessible to node 200 or modules for determining time-related parameter values, which can be used to determine appropriate time-related parameter values. Example NF metrics or related information may include congestion or overload status, message queue information, connectivity problem information, or various performance metrics, such as nf-name_message_processing_time, which indicates the time (in milliseconds) taken for a specific microservice to process a service operation within an NF.

[0045] In some embodiments, one or more NF data providers 212 may include NFs or related nodes that provide performance metrics, status information, or other relevant data about themselves to one or more entities (e.g., node 200 (e.g., NRF 100) or data repositories). In some embodiments, one or more NF data providers 212 may include network management systems, network splitters, or data aggregators that receive, intercept, or export various NF information and use that information to generate and / or provide NF metrics and / or other data to one or more entities.

[0046] refer to Figure 2 Node 200 may include one or more communication interfaces 202 for transmitting messages via a communication environment (e.g., a home 5GC network). For example, the communication interfaces 202(s) may include a first communication interface for communicating with a first set of SEPP 126 in the home network, a second communication interface for communicating with a second set of SEPP 126 in the home network, and a third communication interface for communicating with other entities in the home network.

[0047] Node 200 may include a Time Value Determination Module (TVDM) 204. TVDM 204 may be any suitable entity (e.g., software executing on at least one processor) for performing one or more aspects associated with parameter configuration (e.g., determining time-related parameter values). In some embodiments, TVDM 204 may be configured to communicate with NWDAF 210 and / or (one or more) NF data providers 212 to periodically or sequentially obtain relevant (e.g., current or recent) network or NF information for determining appropriate time-related parameter values ​​for various scenarios and / or service operations. For example, TVDM 204 may subscribe to various events and may receive notifications of such events from NWDAF 210 and / or (one or more) NF data providers 212. In this example, such event notifications and / or the data therein may be used by TVDM 204 when determining appropriate time-related parameter values.

[0048] In some embodiments, TVDM 204 may be configured to use acquired network information and / or NF information when determining one or more time-related parameter values. For example, TVDM 204 may be configured to receive a service request message (e.g., an NFUpdate message) from NF3 209; determine the time-related parameter value associated with the service request message using the network information and / or NF information; and generate and send a service response message (e.g., a "200 OK" response message) indicating the time-related parameter value to NF3 209. In this example, using network information and / or NF information obtained via NWDAF 210 and / or (one or more) NF data providers 212 (e.g., stored in data storage device 206), NRF 100 can determine that NRF 100 and / or another NF (or associated transmission path) is experiencing congestion or operational problems, and in order to alleviate congestion and / or mitigate one or more negative effects associated with the detected problems, NRF 100 can determine (e.g., relative to previously used values) to temporarily increase the NF heartbeat interval (e.g., 3GPP heartbeat timer) associated with NF3 209, thereby reducing the number and frequency of heartbeat messages that need to be sent by NF3 209 to be considered operational (or “active”) by NRF 100, for example. Continuing with this example, after the detected problem is resolved or no longer relevant (e.g., as determined by NRF 100 using more recent network and / or NF information), when NF3 209 sends another service request message (e.g., an NFUpdate message), NRF 100 can determine to reduce the NF heartbeat interval associated with NF3 209 (e.g., return to the default or pre-released value).

[0049] In some embodiments, TVDM 204 may be configured to access or utilize (e.g., in data storage device 206) one or more data repositories containing rules for determining time-related parameters based on various scenarios (e.g., use cases, network conditions, NRF and / or NF congestion, communication path-related delays (such as inter-PLMN communication) and / or geographically redundant sites, etc.) and / or default values ​​of various time-related parameters. For example, TVDM 204 may identify and / or use relevant rules based on various information, including, for example, network information and / or NF information obtained from or via one or more data sources (e.g., NWDAF 210 and / or (one or more) NF data providers 212). In this example, the relevant rules may indicate acceptable values, a range of acceptable values, or may provide formulas, algorithms, or other methods for determining one or more acceptable time parameter values.

[0050] In some embodiments, TVDM 204 can be configured to access or utilize one or more data repositories (e.g., in data storage device 206) containing time value information (e.g., default, historical, and / or acceptable values ​​(or ranges of values)) for various time-related parameters. In such embodiments, TVDM 204 can use the stored time value information along with relevant rules to determine appropriate time-related parameter values. For example, TVDM 204 can use recently acquired network information and / or NF information to determine that a network element or NF is experiencing congestion, and can select relevant rules for that scenario. In this example, the relevant rule could indicate that a default value or previously used value associated with a specific time-related parameter value (e.g., located in the time value information data repository) will be increased by 100%, for example, an HTTP header retry timer is increased from 30 seconds to 60 seconds.

[0051] Node 200 and / or TVDM 204 can access data storage device 206 (e.g., read information from data storage device 206 and / or write information to data storage device 206). Data storage device 206 can be any suitable entity for storing various types of data (e.g., computer-readable media or memory). In some embodiments, data storage device 206 may include network information, NF metrics, time value determination rules, default values, and / or related information for dynamically determining or deriving time-related parameter values. In some embodiments, data storage device 206 may include logic for obtaining or requesting relevant network information and / or NF information (e.g., NF performance metrics) from one or more data sources. In some embodiments, data storage device 206 may include logic or rules for detecting or determining one or more scenarios (e.g., network usage) for adjusting time-related parameter values. In some embodiments, data storage device 206 may include logic or rules for determining time-related parameter values ​​based on detected or determined scenarios.

[0052] It is important to recognize that, Figure 2 The descriptions and related information are for illustrative purposes, and node 200 may include additional and / or different modules, components or functions.

[0053] Figure 3 This is a message flow diagram illustrating an example NRF 100, which includes functionality (e.g., TVDM 204) for dynamically determining time-related parameter values ​​using network information and / or NF information. In some embodiments, the NRF 100 or its TVDM 204 may utilize recent or current network information (e.g., analysis information from NWDAF 210) and / or NF information (e.g., NF-related metrics from one or more NF data providers 212) to determine appropriate time-related parameter values, for example, by adjusting default or previous values. For instance, the NRF 100 or its TVDM 204 may dynamically determine time-related parameter values ​​(e.g., NF heartbeat interval values) based on the routing scenario associated with the requesting entity or current network conditions learned from data obtained from one or more data sources.

[0054] refer to Figure 3 In step 301, NF metrics or other NF-related information can be sent from one or more NF data providers 212 to the NRF 100 or a related entity (e.g., data storage device 206). For example, one or more NF data providers 212 can provide message processing time metrics associated with multiple NFs (e.g., NF1 207, NF2 208, and NF3 209).

[0055] In step 302, network information (e.g., analytics information) can be sent from NWDAF 210 to NRF 100 or a related entity (e.g., data storage device 206). In some examples, NRF 100 or TVDM 204 can subscribe to various events via the Nnwdaf_EventsSubscription service provided by NWDAF 210 and can receive notifications (along with network information) when subscribed events occur. In some examples, NRF 100 or TVDM 204 can request analytics information at periodic or non-periodic intervals using the Nnwdaf_AnalyticsInfo service provided by NWDAF 210.

[0056] In step 303, an NF registration-related request message (e.g., an NFRegister or NFUpdate message) can be sent from NF1 207 to NRF 100. For example, assuming NF1 207 is a visitor PLMN (different from NRF 100), the NFRegister message can originate from NF1 207 and can pass through SEPP 126 before reaching NRF 100. In this example, NRF 100 or TVDM 204 can analyze the characteristics of the NFRegister message (e.g., its originating PLMN) along with learned network information and / or NF information to dynamically determine one or more time-related parameters associated with the NF registration-related request message, such as the NF heartbeat interval (e.g., a 3GPP heartbeat timer value).

[0057] In some embodiments, the NF heartbeat interval may represent a parameter or setting that indicates, for example, the expected amount of time (e.g., in seconds) between two consecutive heartbeat messages from an NF instance (e.g., NF1 207) to NRF 100. In some embodiments, a “heartbeat timer” parameter may be used to determine and provide the NF heartbeat interval during the NF registration or NF update process. For example, NF1 207 may provide NRF 100 with a suggested value for the NF heartbeat timer parameter in an NFRegister request message. In this example, if the suggested heartbeat timer value is acceptable (e.g., as determined by NRF 100 and / or TVDM 204 therein), NRF 100 may acknowledge the value in an NFRegister response message. If the suggested heartbeat timer value is unacceptable (e.g., as determined by NRF 100 and / or TVDM 204 therein), NRF 100 and / or TVDM 204 therein may determine different time-related parameter values ​​(e.g., by adjusting default values ​​in response to network and / or NF conditions) and provide different time-related parameter values ​​to NF1 207 in the NFRegister response message.

[0058] In step 304, an NF registration-related response message indicating one or more time-related parameters can be sent from NRF100 to NF1 207. For example, a response to an NFRegister message associated with NF1 207 can indicate a 3GPP heartbeat timer value based on learned information or factors associated with NF1 207. In this example, the 3GPP heartbeat timer value associated with NF1 207 can differ from the 3GPP heartbeat timer values ​​associated with a different NF (e.g., NF2 208) or from standard or default values.

[0059] In step 305, an NF subscription request message (e.g., an NFStatusSubscribe message) can be sent from NF1 207 to NRF 100. For example, NRF 100 or TVDM 204 can analyze the characteristics of the received NFStatusSubscribe message along with learned network information and / or NF information, determine whether the subscribed NF is overloaded or congested, and can dynamically determine one or more time-related parameters associated with the NF subscription request message, such as NF subscription validity time values.

[0060] In some embodiments, the NF subscription validity period can represent a parameter or setting indicating the amount of time (e.g., in hours) after which the relevant subscription may be considered inactive and / or deleted at NRF 100. In some embodiments, the "validity period" parameter can be used to determine and provide the NF subscription validity period during the NF subscription process. For example, NF1 207 can provide a suggested value for the subscription validity period parameter to NRF 100 in an NFStatusSubscribe request (e.g., subscription creation request) message. In this example, if the suggested subscription validity value is acceptable (e.g., as determined by NRF 100 and / or TVDM 204 therein), NRF 100 can confirm the value in the NFStatusSubscribe response message. If the suggested subscription validity value is unacceptable (e.g., as determined by NRF 100 and / or TVDM 204 therein), NRF 100 and / or TVDM 204 therein may determine different time-related parameter values ​​(e.g., by adjusting the default values ​​in response to network and / or NF status) and provide different time-related parameter values ​​to NF1 207 in the NFStatusSubscribe response message.

[0061] In step 306, an NF subscription response message indicating one or more time-related parameters can be sent from NRF 100 to NF1 207. For example, a response to an NFStatusSubscribe message associated with NF1 207 can indicate an NF subscription validity time value based on information or factors learned associated with NF1 207. In this example, the NF subscription validity time value associated with NF1 207 can differ from the NF subscription validity time values ​​associated with a different NF (e.g., NF2 208) or a standard or default value.

[0062] In step 307, an NF discovery request message (e.g., an NFDiscover message) can be sent from NF1 207 to NRF 100. For example, NRF 100 or TVDM 204 can analyze the characteristics of the received NFDiscover message along with learned network information and / or NF information, determine if the discovered NF is overloaded or congested, and can dynamically determine one or more time-related parameters associated with the NF discovery request message, such as NF discovery validity time values.

[0063] In some embodiments, the NF discovery validity time may represent a parameter or setting indicating the amount of time (e.g., in hours) after which a search result from a discovery or search is valid, such as after which the search result may be considered invalid and / or removed from the cache at the NF service consumer (e.g., NF1 207). In some embodiments, the "validity time" parameter may be used to determine and provide the NF discovery validity time during the NF discovery process. For example, NF1 207 may provide a suggested value for the discovery validity time parameter to NRF 100 in an NFDiscover request message. In this example, if the suggested discovery validity value is acceptable (e.g., as determined by NRF 100 and / or TVDM 204 therein), NRF 100 may confirm the value in the NFDiscover response message. If the suggested discovery validity value is unacceptable (e.g., as determined by NRF 100 and / or TVDM 204 therein), NRF 100 and / or TVDM 204 therein may determine different time-related parameter values ​​(e.g., by adjusting default values ​​in response to network and / or NF conditions) and provide different time-related parameter values ​​to NF1 207 in the NFDiscover response message.

[0064] In step 308, an NF discovery response message indicating one or more time-related parameters can be sent from NRF 100 to NF1 207. For example, a response to an NFDiscover message associated with NF1 207 can indicate an NF discovery validity time value based on the learned information or factors associated with NF1 207. In this example, the NF discovery validity time value associated with NF1 207 can differ from the NF discovery validity time values ​​associated with a different NF (e.g., NF2 208) or a standard or default value.

[0065] In step 309, an NF access token request message (e.g., an NFAccessToken request message) can be sent from NF1207 to NRF 100. For example, NRF 100 or TVDM 204 can analyze the characteristics of the received NFAccessToken request message along with learned network information and / or NF information, determine NF overload or congestion associated with the access token request, and dynamically determine one or more time-related parameters associated with the NF access token request message, such as the NF access token expiration time value.

[0066] In some embodiments, the NF access token expiration time can represent a parameter or setting indicating the amount of time (e.g., in hours) after which the NF access token may be considered invalid. In some embodiments, the "expiration time" parameter can be used to determine and provide the NF access token expiration time during the NF access token request process. For example, an NFAccessToken request message can be sent from NF1 207 to NRF 100. In this example, NRF 100 and / or its TVDM 204 can determine the expiration time-related parameter value (e.g., by adjusting default values ​​in response to network and / or NF conditions) and provide the time-related parameter value to NF1 207 in an NFAccessToken response message.

[0067] In step 310, an NF subscription response message indicating one or more time-related parameters can be sent from NRF 100 to NF1 207. For example, a response to an NFAccessToken request message associated with NF1 207 can indicate an NF access token expiration time value based on information or factors learned associated with NF1 207. In this example, the access token expiration time value associated with NF1 207 can differ from the access token expiration time value associated with a different NF (e.g., NF2 208) or a standard or default value.

[0068] It is important to recognize that, Figure 3This is for illustrative purposes, and different and / or additional messages and / or actions may be used. It should also be recognized that the various messages and / or actions described herein may occur in different orders or sequences.

[0069] Figure 4 This is a diagram illustrating example rule data 400, which indicates rule IDs and associated time-related parameter value determination rules used to determine the values ​​of one or more time-related parameters (e.g., based on network conditions, NF performance metrics, and / or other factors). For example, rule data 400 may indicate a mapping (e.g., association) between rule IDs and associated time-related parameter value determination rules. In some embodiments, rule mappings or associations may be statically configured by the operator or dynamically generated by the NRF 100, for example, using historical data and user-provided preferences. For example, the NRF 100 may receive a set of rules for different scenarios from the network operator, along with expected performance information for the NRF 100. In this example, if a rule for a given scenario does not yield the expected results (e.g., the NRF is still experiencing congestion), the NRF 100 may dynamically adjust the rule (e.g., increasing the time-related parameter value by 15%) to attempt to achieve the expected results.

[0070] In some embodiments, node 200, NRF 100, or TVDM 204 can be configured to select time-related parameter value determination rules and / or logic based on characteristics or scenarios associated with the received message or related entities (e.g., NF service consumers or NF service producers). For example, NRF 100 can analyze a received message to determine whether the message originated from a different PLMN or was forwarded (e.g., by visitor NRF 100 or NF1207). In addition to or instead of determining the origin of the received message, NRF 100 can use various data (e.g., periodically acquired network information and / or NF information) to determine whether it or another network entity (e.g., the requesting entity) is experiencing congestion events or other problems that may affect processing or communication. In this example, using the various information available to NRF 100, NRF 100 can select relevant time-related parameter value determination rules, where the time-related parameter value determination rules can instruct formulas or logic for determining appropriate values ​​for a particular time-related parameter. For example, if node 200, NRF 100, or TVDM 204 determines that NRF 100 is experiencing congestion, they can choose to double or triple the predetermined default value of a specific short-term parameter (e.g., the NF heartbeat interval or the HTTP header retry timer) according to time-related parameter value determination rule "ID4". In another example, if node 200, NRF 100, or TVDM 204 determines that the requesting entity is located in a different network, they can choose to increase the predetermined or suggested default value by 25% or increase the predetermined default value such that the new time-related parameter value is greater than the derived or estimated one-way delay or other metric time-related parameter value determination rule "ID1".

[0071] refer to Figure 4 The table representing rule data 400 includes columns and / or fields for determining rules using rule IDs and corresponding time-related parameter values. The rule ID field may store information representing an identifier used to identify rules determined by time-related parameter values. In some embodiments, each rule ID may be globally unique within the PLMN, for example, a unique numeric or alphanumeric value. In some embodiments, rule IDs may be hierarchical or provide insight into related rules. In some embodiments, rule IDs may be non-hierarchical or opaque to insight into related rules.

[0072] The Time-Related Parameter Value Determination Rule field can represent one or more rules or logic used to determine the values ​​of one or more time-related parameters. In some embodiments, rules can be based on network or NF scenarios and / or identifiable characteristics associated with received messages, requesting entities, or related services. Example scenario-based rules may include one or more time-related parameter value determination rules for NRF-to-NRF forwarding scenarios, geographic redundancy scenarios, NF congestion rules, and NRF congestion scenarios.

[0073] In some embodiments, node 200, NRF 100, or TVDM 204 can be configured to determine that a received message or associated entity is associated with an NRF-to-NRF forwarding scenario, and can adjust one or more time-related parameters using one or more related rules based on various information, such as information obtained via NWDAF 210 and / or (one or more) NF data providers 212. For example, when NRF 100 lacks information about the associated producer NF with respect to a received message, node 200, NRF 100, or TVDM 204 can determine that the received message is associated with an NRF-to-NRF forwarding scenario, and therefore may involve various messages crossing PLMN boundaries and locations. In this example, after detecting an NRF-to-NRF forwarding scenario, node 200, NRF 100, or TVDM 204 can determine appropriate values ​​for one or more time-related parameters (e.g., NF subscription validity time, NF discovery validity time, or NF access token expiration time), for example, to reduce traffic across PLMN boundaries and different locations and / or to allow additional time for anticipated or potential packet delays.

[0074] In some embodiments, node 200, NRF 100, or TVDM 204 can be configured to determine that a received message or related entity is associated with a georedundancy scenario, and can adjust one or more time-related parameters using one or more related rules based on various information obtained, for example, via NWDAF 210 and / or (one or more) NF data providers 212. For example, when a received message or related message traverses one or more georedundancy sites, node 200, NRF 100, or TVDM 204 can determine that the received message is associated with a georedundancy scenario, and therefore may involve various messages handled by NFs from partner or peer NRF 100. In this example, after detecting a georedundancy scenario, node 200, NRF 100, or TVDM 204 can determine appropriate values ​​for one or more time-related parameters (e.g., NF heartbeat interval, NF subscription validity time, NF discovery validity time, or NF access token expiration time), for example, to reduce traffic across georedundancy sites and / or to allow additional time for anticipated or possible packet delays.

[0075] In some embodiments, node 200, NRF 100, or TVDM 204 can be configured to determine, based on obtained network information and / or NF information, that NRF 100 is experiencing operational problems (e.g., overload, handling peak traffic, maintenance, etc.), and can use one or more relevant rules to adjust one or more time-related parameters according to such problems. For example, node 200, NRF 100, or TVDM 204 can determine that NRF 100 is experiencing congestion or maintenance based on various information (e.g., via subscribed event notifications, from NWDAF 210). In this example, after detecting NRF 100 congestion or maintenance, node 200, NRF 100, or TVDM 204 can determine appropriate values ​​for one or more time-related parameters (e.g., NF heartbeat interval, HTTP header retry timer, NF subscription validity time, NF discovery validity time, or NF access token expiration time), for example, to reduce traffic handled by NRF 100 and / or to allow additional time for anticipated or possible packet delays.

[0076] In some embodiments, node 200, NRF 100, or TVDM 204 can be configured to determine, based on obtained network information and / or NF information, that an NF (e.g., a requested or appropriate producer NF for handling a specific service request) is experiencing operational problems (e.g., overload, handling peak traffic, maintenance, etc.), and can use one or more relevant rules to adjust one or more time-related parameters based on such problems. For example, node 200, NRF 100, or TVDM 204 can determine, based on various information (e.g., the nf-name_message_processing_time metric or relevant data from one or more NF data providers 212), that a producer NF is experiencing congestion or is undergoing maintenance. In this example, after detecting congestion or maintenance in a producer NF, node 200, NRF 100, or TVDM 204 can determine appropriate values ​​for one or more time-related parameters (e.g., NF heartbeat interval, HTTP header retry timer, NF subscription validity time, NF discovery validity time, or NF access token expiration time), for example, to reduce less critical traffic and / or to allow additional time for anticipated or potential packet delays. In some embodiments, by increasing the value associated with the time-related parameter (e.g., NF heartbeat interval), an overloaded NF can reduce its heartbeat-related traffic to NRF 100 and instead use its resources to process requests during the overload condition.

[0077] In some embodiments, node 200, NRF 100, or TVDM 204 may use one or more defined time-related parameter values ​​for subsequent requests or operations. For example, after NRF 100 is determined to be congested, the NF heartbeat interval used by the NF (e.g., a heartbeat timer value) may be increased from 30 seconds to 90 seconds, and the new value may be notified to the NF in response to subsequent 3GPP operations (e.g., NF registration and NF update). In this example, after NRF 100 is determined to no longer be congested, the NF heartbeat interval used by the NF may be reduced back to 30 seconds, and the new value may be notified to the NF in response to subsequent 3GPP operations.

[0078] It should also be recognized that rule data 400 is for illustrative purposes, and in addition to... Figure 4Different and / or additional data beyond the data depicted can be used to determine time-related parameter values. For example, rule data 400 may include various scenarios not depicted, including combined scenarios such as NRF and NF congestion. In this example, rule data 400 may include priority values ​​indicating which rule(s) to select or use. In another example, rule data 400 may include one or more rules for different time-related parameters of the same scenario. Furthermore, rule data 400 may be stored using various data structures and / or computer-readable media (e.g., in data storage device 206).

[0079] Figure 5 This is a diagram illustrating example default value information 500 for various time-related parameters in a communication network. For example, default value information 500 may indicate values ​​associated with various time-related parameters. In some embodiments, such as when NRF 100 does not determine time-related parameters based on recent network and / or NF information, NRF 100 may utilize default value information 500 to select time-related parameters regardless of the situation or scenario. This is before adjustments based on network information, NF metrics, or other information. In this example, the default value may be predetermined, for example, by the network operator or (e.g., in rule data 400) a time-related parameter value determination rule. Continuing this example, time-related parameter values ​​can be determined by adjusting (e.g., increasing or decreasing) the default value in response to or based on at least a portion of current network information and / or NF information (e.g., information indicating network congestion, NRF maintenance, PLMN inter-communication, high NF load, etc.).

[0080] In some embodiments, node 200, NRF 100, or TVDM 204 can be configured to identify characteristics of received messages (e.g., determine whether the received message is an inter-PLMN message or whether the received message is forwarded from a visiting PLMN) and use these characteristics in conjunction with current (or recent) network conditions and / or NF metrics to dynamically determine the values ​​of time-related parameters. Default value information 500 can be used to determine default or initial time-related parameter values ​​for specific time-related parameters, and relevant rules (e.g., from rule data 400) can be used to determine appropriate time-related parameter values ​​for the requesting NF or related service, such as by increasing or decreasing the initial time-related parameter value. For example, node 200 or TVDM 204 can determine that an NRF or related network segment is experiencing congestion and can determine that increasing the initial or default value of the NF heartbeat timer or interval value from 30 seconds to 60 seconds will significantly improve congestion and / or related problems. In this example, the adjustment from 30 seconds to 60 seconds can be based on a formula or a percentage amount. In another example, time adjustments could be based on historical data, such as previous congestion events and / or associated connectivity or heartbeat issues during those events.

[0081] refer to Figure 5 The table representing default value information 500 includes columns and / or fields for time-related parameters and their corresponding default values. In some embodiments, the default values ​​may be predetermined, for example, by a network operator or (e.g., in rule data 400) a time-related parameter value determination rule. The time-related parameter field may store information for representing time-related parameters (e.g., 3GPP network parameters) that indicate or represent a time quantity or time period. Figure 5 The example time-related parameters described include NF heartbeat intervals (e.g., 3GPP “heartbeat timers”), NF subscription validity periods, NF discovery validity periods, NF access token expiration periods, or HTTP header retry timers (e.g., values ​​in the “Retry-After” HTTP header parameter field).

[0082] The default value field can indicate a default value (e.g., an initial value) associated with a specific time-related parameter. In some embodiments, the default value can be in seconds, minutes, hours, or days and / or can be based on a percentage or formula of a suggested time using data from NF and / or other data (e.g., the default value for the heart rate interval parameter can be 10% smaller than the suggested time, but not exceeding 70 seconds).

[0083] like Figure 5As described in the document, the default value for the NF heartbeat interval parameter can be 30 seconds; the default value for the NF subscription validity period parameter can be 6 hours; the default value for the NF discovery validity period parameter can be 1 hour; the default value for the NF access token expiration period parameter can be 1 hour; and the default value for the HTTP header retry timer parameter can be 30 seconds.

[0084] For example, an HTTP header retry timer can represent a parameter or setting that instructs the NF to wait to retry a service operation at NRF 100 for an amount of time (e.g., in seconds). In some embodiments, the HTTP header retry timer can be determined when NRF 100 wants to send an HTTP 503 error message indicating that the service is unavailable, and can be provided to the NF service consumer (e.g., NF1 207) in a “Retry-After” HTTP header field. For example, when NRF 100 is overloaded, NRF 100 can reject some HTTP requests by sending an HTTP 503 message that includes an HTTP header field “Retry-After” indicating an estimated time (in seconds) for service recovery. In this example, NRF 100 and / or its TVDM 204 can determine the HTTP retry timer value (e.g., by adjusting a default value in response to network and / or NF conditions).

[0085] It should also be recognized that the default value information 500 is for illustrative purposes, and in addition to... Figure 5 Different and / or additional data beyond the data depicted can be used to indicate default values ​​for various time-related parameters. Furthermore, various data structures and / or computer-readable media can be used to store the default value information 500 (e.g., in data storage device 206).

[0086] Figure 6 This is a diagram illustrating an example process 600 for determining time-related parameter values ​​for a communication network. In some embodiments, the example process 600 or portions thereof described herein may be performed at or by a network node (e.g., NRF 100, node 200, TVDM 204 and / or another module, NF, or node).

[0087] In reference processing 600, in step 602, a service request message can be received from the first NF. In some embodiments, the service request message may include an NF registration request message, an NF update request message, an NF state subscription request message, an NF discovery request message, or an NF access token request message.

[0088] In step 604, network information and / or NF information can be used to determine time-related parameter values ​​associated with the service request message. In some embodiments, time-related parameter values ​​may indicate NF heartbeat intervals (e.g., 3GPP heartbeat timers), NF subscription validity periods, NF discovery validity periods, NF access token expiration periods, or HTTP header retry timers (e.g., values ​​in the “Retry-After” HTTP header parameter field).

[0089] In some embodiments, at least some network information or NF information may be obtained periodically or non-periodically (e.g., dynamically) from one or more data sources (e.g., a local data repository (e.g., relative to NRF 100), a remote data source (e.g., relative to NRF 100), NWDAF 210, or (one or more) NF data providers 212).

[0090] In some embodiments, at least some network information can be obtained using the Nnwdaf_EventsSubscription service or the Nnwdaf_AnalyticsInfo service. For example, approximately every 60 seconds, NRF 100 or another entity may send one or more Nnwdaf_AnalyticsInfo service request messages to NWDAF 210 to obtain load level information for one or more network slice instances associated with the 5G communication network. In another example, NRF 100 or another entity may send an Nnwdaf_EventsSubscription service request message to subscribe to and receive network slice-specific congestion event notifications from NWDAF 210.

[0091] In some embodiments, determining time-related parameter values ​​may include determining that the NRF, the first NF, or the network entity may be experiencing a change in congestion state, a change in workload, or a change in operational state; and in response, adjusting the time-related parameter values ​​from default values ​​or previous values. For example, default values ​​or previous values ​​may be predetermined by the network operator or generated using predetermined policies or rules.

[0092] In some embodiments, determining the time-related parameter value may include determining that a service request message or related message requires NRF-to-NRF forwarding; and in response, increasing the time-related parameter value from an initial value or a default value.

[0093] In some embodiments, determining the time-related parameter value may include determining that the service request message or related message may be an inter-PLMN message; and in response, increasing the time-related parameter value from the initial value or the default value.

[0094] In step 606, a service response message indicating time-related parameter values ​​may be generated and sent to the first NF. In some embodiments, the service response message may include an NF registration response message, an NF update response message, an NF state subscription response message, an NF discovery response message, or an NF access token response message.

[0095] It should be recognized that the treatment of 600 is for illustrative purposes and different and / or additional actions may be used. It should also be recognized that the various actions described herein may occur in different orders or sequences.

[0096] It should be recognized that while some aspects of the topics described in this paper have been discussed with reference to 5G networks, various other networks can utilize aspects of the topics described in this paper. For example, any network can benefit from dynamically determined time-related parameter values, such as those based on network conditions, NF-related metrics, and / or other information.

[0097] It should be noted that node 200, TVDM 204, and / or the functions described herein can constitute a dedicated computing device. Furthermore, node 200, TVDM 204, and / or the functions described herein can improve the technical field of network communication. For example, by using current network information and / or NF information to determine time-related parameter values, communication between NFs or other entities can be improved and timing problems can be reduced. In this example, by utilizing one or more techniques and / or methods described herein, NRF 100 or its TVDM 204 can determine time-related parameter values ​​based on network conditions, NF-related metrics, and / or other factors. Moreover, such techniques and / or methods described herein can be applied to multiple services or related interfaces, including, for example, nudm-sdm, nudm-uecm, npcf-uepolicy, nsmf-pdusession, nssf-nsselection, nnrf-disc, and / or nnrf-nfm.

[0098] To the extent that they do not contradict this document and to supplement, explain, teach, or provide background on the methods, techniques, and / or systems used herein, the entire contents of each of the following references are incorporated herein by reference.

[0099] References:

[0100] 1.3GPP TS29.510; 3 rdGeneration Partnership Project; TechnicalSpecification Group Core Network and Terminals; 5G System; Network FunctionRepository Services; Stage 3(Release 17),V17.1.0(2021-03).

[0101] 2.3GPP TS 33.501; 3 rd Generation Partnership Project; TechnicalSpecification Group Services and System Aspects; Security Architecture and Procedures for the 5G System; (Release 17), V17.1.0 (2021-03).

[0102] 3.3GPP TS29.520; 3 rd Generation Partnership Project; TechnicalSpecification Group Core Network and Terminals; 5G System; Network DataAnalytics Services; Stage 3(Release 17),V17.2.0(2021-03)

[0103] It should be understood that various details of the currently disclosed subject matter can be changed without departing from the scope of the currently disclosed subject matter. Furthermore, the foregoing description is for illustrative purposes only and not for limiting purposes.

Claims

1. A method for determining time-related parameter values ​​of a communication network, the method comprising: At the Network Function (NF) Storage Function (NRF) that includes at least one processor: Receive service request messages from a first network function (NF), wherein the service request messages include NF registration request messages, NF update request messages, NF state subscription request messages, NF discovery request messages, or NF access token request messages; Network information and / or NF information are used to determine time-related parameter values ​​associated with service request messages, wherein the time-related parameter values ​​indicate NF heartbeat intervals, NF subscription validity periods, NF discovery validity periods, NF access token expiration periods, or Hypertext Transfer Protocol (HTTP) header retry timers, wherein determining the time-related parameter values ​​includes the NRF determining that there are conditions for adjusting the time-related parameter values ​​from default values ​​or previous values ​​that the NRF can determine; In response and before providing time-related parameter values ​​to the first NF, the NRF adjusts the time-related parameter values ​​from their default or previous values; and Generate and send a service response message indicating the time-related parameter values ​​to the first NF.

2. The method of claim 1, wherein at least some of the network information or NF information is obtained periodically or non-periodically from one or more data sources.

3. The method of claim 2, wherein the one or more data sources include a local data repository, a remote data source, a Network Data Analysis Function (NWDAF), or an NF data provider.

4. The method according to any one of claims 1, 2 or 3, wherein at least some of the network information is obtained using the Nnwdaf_EventsSubscription service or the Nnwdaf_AnalyticsInfo service.

5. The method according to any one of claims 1, 2 or 3, wherein determining the existence of conditions for adjusting time-related parameter values ​​includes determining that the NRF, the first NF or the network entity is experiencing a congestion state change, a workload change or an operational state change.

6. The method of claim 5, wherein the default value or previous value is predetermined by the network operator or generated using predetermined policies or rules.

7. The method according to any one of claims 1, 2 or 3, wherein determining the existence of conditions for adjusting time-related parameter values ​​includes determining that a service request message or related message requires NRF-to-NRF forwarding.

8. The method according to any one of claims 1, 2 or 3, wherein determining the existence of conditions for adjusting time-related parameter values ​​includes determining that the service request message or related message is an inter-Public Land Mobile Network (PLMN) message.

9. A system for determining time-related parameter values ​​of a communication network, the system comprising: Network Function (NF) Storage Function (NRF) includes: At least one processor; and memory, NRF is configured to be used for: Receive service request messages from a first network function (NF), wherein the service request messages include NF registration request messages, NF update request messages, NF state subscription request messages, NF discovery request messages, or NF access token request messages; Network information and / or NF information are used to determine time-related parameter values ​​associated with the service request message, wherein the time-related parameter values ​​indicate NF heartbeat intervals, NF subscription validity periods, NF discovery validity periods, NF access token expiration periods, or Hypertext Transfer Protocol (HTTP) header retry timers. Determining the time-related parameter values ​​includes the NRF determining that conditions exist for adjusting the time-related parameter values ​​from default values ​​or previous values ​​that the NRF can determine; and, in response and before providing the time-related parameter values ​​to the first NF, the NRF adjusts the time-related parameter values ​​from default values ​​or previous values. Generate and send a service response message indicating the time-related parameter values ​​to the first NF.

10. The system of claim 9, wherein the NRF is configured to periodically or non-periodically obtain at least some of network information or NF information from one or more data sources.

11. The system of claim 10, wherein the one or more data sources include a local data repository, a remote data source, a network data analytics function (NWDAF), or an NF data provider.

12. The system according to any one of claims 9, 10 or 11, wherein the NRF is configured to use the Nnwdaf_EventsSubscription service or the Nnwdaf_AnalyticsInfo service to obtain at least some of the network information.

13. The system according to any one of claims 9, 10 or 11, wherein determining the existence of conditions for adjusting time-related parameter values ​​includes determining that the NRF, the first NF or the network entity is experiencing a congestion state change, a workload change or an operational state change.

14. The system according to any one of claims 9, 10 or 11, wherein determining the existence of conditions for adjusting time-related parameter values ​​includes determining that a service request message or related message requires NRF-to-NRF forwarding.

15. The system according to any one of claims 9, 10 or 11, wherein determining the existence of conditions for adjusting time-related parameter values ​​includes determining that the service request message or related message is an inter-PLMN message.

16. At least one non-transitory computer-readable medium having executable instructions stored thereon, the executable instructions, when executed by at least one processor of a computer, causing the computer to perform the following steps: At the Network Function (NF) Storage Function (NRF) that includes at least one processor: Receive service request messages from a first network function (NF), wherein the service request messages include NF registration request messages, NF update request messages, NF state subscription request messages, NF discovery request messages, or NF access token request messages; Network information and / or NF information are used to determine time-related parameter values ​​associated with service request messages, wherein the time-related parameter values ​​indicate NF heartbeat intervals, NF subscription validity periods, NF discovery validity periods, NF access token expiration periods, or Hypertext Transfer Protocol (HTTP) header retry timers, wherein determining the time-related parameter values ​​includes the NRF determining that there are conditions for adjusting the time-related parameter values ​​from default values ​​or previous values ​​that the NRF can determine; In response and before providing time-related parameter values ​​to the first NF, the NRF adjusts the time-related parameter values ​​from their default or previous values; and Generate and send a service response message indicating the time-related parameter values ​​to the first NF.

Images