Method, system, and computer readable medium for determining time-related parameter values ​​for a communication network - Patents.com

Abstract

A method, system, and computer-readable medium for determining time-related parameter values ​​for a communication network are disclosed. One method for determining time-related parameter values ​​for a communication network is performed in a Network Function (NF) Repository Function (NRF) that comprises at least one processor. The method includes receiving a service request message from a first Network Function (NF), determining a time-related parameter value associated with the service request message using network information and / or NF information, and generating and transmitting a service response message to the first NF indicating the time-related parameter value.

Description

[Technical field]

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

[0002] Technical Field The subject matter described herein relates to improved communications in fifth generation (5G) and next generation communication networks. More particularly, the subject matter described herein relates to methods, systems, and computer-readable media for determining time-related parameter values ​​for 5G and next generation communication networks. [Background technology]

[0003] background In fifth generation (5G) communication networks, a network node that provides a service is called a producer Network Function (NF). A network node that consumes a service is called a consumer NF. A network function can be both a producer NF and a consumer NF depending on whether it is consuming or providing a service.

[0004] A given producer NF may have multiple service endpoints, which are the contact points of one or more NF instances hosted by the producer NF. A service endpoint is identified by a combination of an Internet Protocol (IP) address and a port number, or a fully qualified domain name that resolves to an IP address and a 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 may include multiple NF instances. Note also that multiple NF instances may share the same service endpoint.

[0005] Producer NFs register with an NF Repository Function (NRF). The NRF maintains service profiles of available NF instances that identify the services supported by each NF instance. Consumer NFs may subscribe to receive information about producer NF instances registered with the NRF. In addition to consumer NFs, another type of network node that may subscribe to receive information about NF service instances is the Service Communication Proxy (SCP). An SCP subscribes to the NRF to obtain reachability and service profile information about producer NF service instances. Consumer NFs connect to the Service Communication Proxy, and the Service Communication Proxy load balances traffic among producer NF service instances that provide the required service or route traffic directly to the destination producer NF instance.

[0006] In addition to SCPs, other examples of intermediate proxy nodes or groups of network nodes that route traffic between producer and consumer NFs include security edge protection proxies (SEPPs), service gateways, and nodes in a 5G service mesh. SEPPs are network nodes used to protect control plane traffic exchanged between different 5G public land mobile networks (PLMNs). As such, SEPPs perform varying amounts of message filtering, policing, and topology hiding for application programming interface (API) messages.

[0007] In 5G and various other communication networks, timing issues can affect connectivity and usability. For example, if an access token or subscription expires too soon, the NF may not receive an expected or desired response. Therefore, there is a need to improve communication networks by reducing or mitigating timing issues. Summary of the Invention [Means for solving the problem]

[0008] overview A method, system, and computer-readable medium for determining time-related parameter values ​​for a communication network are disclosed. One method for determining time-related parameter values ​​for a communication network is performed in a Network Function (NF) Repository Function (NRF) that comprises at least one processor. The method includes 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 transmitting a service response message to the first NF indicating the time-related parameter value.

[0009] One example system for determining time-related parameter values ​​for a communications network includes an NRF with at least one processor and memory configured to receive a service request message from a first NF, determine a time-related parameter value associated with the service request message using network information and / or NF information, and generate and transmit a service response message to the first NF indicating the time-related parameter value.

[0010] One exemplary non-transitory computer-readable medium including computer-executable instructions embodied therein that, when executed by at least one processor of at least one computer, cause the at least one computer to perform steps including: receiving, at an NRF comprising the at least one processor, a service request message from a first NF; determining, using network information and / or NF information, a time-related parameter value associated with the service request message; and generating and transmitting, to the first NF, a service response message indicating the time-related parameter value.

[0011] In accordance with one aspect of the subject matter described herein, at least some network or NF information (e.g., used in determining time-related parameter values) may be obtained periodically or aperiodically from one or more data sources.

[0012] According to one aspect of the subject matter described herein, the one or more data sources may include a local data store, a remote data source, a network data analysis function (NWDAF), or a NF data provider.

[0013] According to one aspect of the subject matter described herein, at least some of the network information may be obtained using the Nnwdaf_EventsSubscription service or the Nnwdaf_AnalyticsInfo service.

[0014] According to one aspect of the subject matter described herein, determining the time-related parameter value may include determining that the NRF, the first NF, or the network entity may be experiencing a congestion state change, a workload amount change, or an operational state change, and adjusting the time-related parameter value from a default value or a previous value in response to the determination.

[0015] According to one aspect of the subject matter described herein, the default values ​​or previous values ​​(e.g., values ​​of time-related parameters) may be predetermined by a network operator or may be generated using a predetermined policy or rule.

[0016] According to one aspect of the subject matter described herein, determining the time-related parameter value may include determining that a service request message or an associated message requires forwarding from an NRF to an NRF, and in response to the determination, increasing the time-related parameter value from an initial or default value.

[0017] According to one aspect of the subject matter described herein, determining the time-related parameter value may include determining that the service request message or the associated message is likely to be an inter-public land mobile network (PLMN) message and, in response to the determination, increasing the time-related parameter value from an initial or default value.

[0018] According to one aspect of the subject matter described herein, the service request message may include a NF registration request message, a NF update request message, a NF status subscription request message, a NF discovery request message, or a NF access token request message.

[0019] According to one aspect of the subject matter described herein, the time-related parameter value may indicate a NF heartbeat interval, an NF subscription validity time, an NF discovery validity time, an NF access token expiration time, or a HyperText Transfer Protocol (HTTP) header retry timer.

[0020] The subject matter described herein may be implemented in hardware, software, firmware, or any combination thereof. Thus, the terms "function," "node," or "module" as used herein refer to hardware that may also include software and / or firmware components for implementing the described functions. In one exemplary implementation, the subject matter described herein may be implemented using a computer-readable medium having computer-executable instructions stored thereon, which, when executed by a processor of a computer, control the computer to perform steps. Exemplary computer-readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media, such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. Furthermore, computer-readable media implementing the subject matter described herein may be located on a single device or computing platform, or distributed across multiple devices or computing platforms.

[0021] The subject matter described herein will now be described with reference to the accompanying drawings, in which: [Brief description of the drawings]

[0022] [Figure 1] FIG. 1 is a network diagram illustrating an example fifth generation (5G) network architecture. [Diagram 2] FIG. 2 illustrates an example network node for determining time-related parameter values ​​for a communication network. [Diagram 3] FIG. 13 is a message flow diagram illustrating an example NRF that dynamically determines time-related parameter values ​​using network information and / or NF information. [Figure 4] FIG. 13 illustrates example rule data showing rule IDs and associated time-related parameter value determination rules. [Diagram 5]FIG. 11 illustrates example default value information for various time-related parameters. [Figure 6] 5 is a flow chart illustrating an example process for determining time-related parameter values ​​for a communication network. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0023] Detailed Description The subject matter described herein relates to a method, system, and computer-readable medium for determining time-related parameter values ​​in a communication network. In a 5G communication network defined in the 3rd Generation Partnership Project (3GPP®), a Network Function (NF) Repository Function (NRF) may determine various time-related parameter values ​​(e.g., timer values ​​and validity period values) for various service operations. However, current NRF implementations use statically set or congruently agreed values ​​for various time-related parameters, such as NF heartbeat intervals (e.g., 3GPP heartbeat timers), NF subscription validity times, NF discovery validity times, NF access token expiration times, or HTTP header retry timers (e.g., values ​​in the "Retry-After" HTTP header parameter field). Furthermore, there is no mechanism in 3GPP Technical Specification (TS) 29.510 that defines NRF functionality for determining time-related parameter values ​​by considering dynamic network and / or deployment conditions. Various problems, such as connectivity and / or timing problems, may occur when time-related parameter values ​​are not suitable for an associated use case or scenario (e.g., current network conditions or another factor affecting one or more NFs). For example, statically configured time-related parameter values ​​may not enable effective communication between NFs or other network elements, for example, because some network use cases or scenarios (e.g., communications across different regions and PLMNs) may cause various delays.

[0024] In accordance with certain aspects of the subject matter described herein, methods, systems, mechanisms, and / or techniques are disclosed for determining a time-related parameter value for a communication network using obtained network information and / or NF information. For example, an NRF according to various aspects described herein may be configured to receive a service request message from a first NF, determine a time-related parameter value associated with the service request message using the network information and / or NF information, and generate and transmit a service response message to the first NF indicating the time-related parameter value. In this example, the network information and / or NF information used in the determination may be obtained periodically or aperiodically from various data sources, such as, for example, a network data analysis function (NWDAF) or another NF data provider (e.g., an NF metric server).

[0025] Advantageously, by utilizing one or more techniques, systems, and / or methods described herein, the NRF or another entity may determine time-related parameter values ​​based on various information, e.g., dynamic network conditions and / or NF health or performance metrics. Furthermore, some time-related parameter values ​​(e.g., NF heartbeat interval value and / or HTTP header retry timer value) may directly affect the amount and / or frequency of some traffic transmitted by the NF, so that dynamic determination of time-related parameter values ​​may reduce traffic processing load or improve resource utilization at the NF and NRF. For example, by increasing the allowed time between successive heartbeat messages when network congestion is detected, the NF may reduce the time spent transmitting such messages, and the NRF may reduce the time spent processing such messages. In this example, the reduction in heartbeat messages may also help reduce congestion in the network. Similar effects may also be seen by increasing some other time-related parameter values, e.g., NF subscription validity time, NF discovery validity time, NF access token expiration time. Furthermore, by utilizing one or more aspects described herein, an example NRF may improve overall core network performance by using current or recent network and / or NF information to determine time-related parameter values ​​(e.g., optimized and / or use case-based timer values). Furthermore, an example NRF according to various aspects described herein may be fully backward compatible, may not impact NFs from various vendors, and may not require changes to existing 3GPP-defined 5GC call flows.

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

[0027] FIG. 1 is a block diagram illustrating an example 5G system network architecture, e.g., a Home 5G Core (5GC) network. The architecture of FIG. 1 includes an NRF 100 and an SCP 101, which may be located in the same home public land mobile network (PLMN). As described above, the NRF 100 may maintain a profile of available producer NF service instances and their supported services, and may allow consumer NFs or SCPs to subscribe and be notified of new / updated producer NF service instance registrations. The SCP 101 may also support service discovery and selection of producer NF instances. The SCP 101 may perform load balancing of connections between consumer NFs and producer NFs. In addition, using the methodologies described herein, the SCP 101 may perform preferred NF location-based selection and routing.

[0028] The NRF 100 is a repository of NF or service profiles of producer NF instances. To communicate with a producer NF instance, a consumer NF or SCP must obtain the NF or service profile or producer NF instance from the NRF 100. The NF or service profile may be a Java Script Object Notation (JSON) data structure defined in 3GPP TS 29.510. The NF or service profile definition includes 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. In FIG. 1, any of the nodes (other than the NRF 100) can be either a consumer NF or a producer NF based on whether it is requesting or providing a service. 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. 1 further includes an Access and Mobility Management Function (AMF) 110 and a Session Management Function (SMF) 108 that manages sessions between the PCF 102. The AMF 110 performs mobility management operations similar to those performed by a Mobility Management Entity (MME) in 4G networks. An Authentication Server Function (AUSF) 112 performs authentication services for user devices, such as User Equipment (UE) 114, seeking access to the network.

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

[0030] The Radio Access Network (RAN) 120 connects the UE 114 to the network via a wireless link. The RAN 120 may be accessed using a g-Node B (gNB) (not shown in FIG. 1) or another wireless access point. The User Plane Function (UPF) 122 may support various proxy functionalities for user plane services. One example of such proxy functionality is a Multi-Path Transmission Control Protocol (MPTCP) proxy functionality. The UPF 122 may also support performance measurement functionality, which may be used by the UE 114 to obtain network performance measurements. Also shown in FIG. 1 is a Data Network (DN) 124, which allows the UE to access data network services, such as Internet services.

[0031] A security edge protection proxy (SEPP) 126 filters incoming traffic from another PLMN and performs topology hiding for traffic egressing from the home PLMN. The SEPP 126 may communicate with a SEPP in a foreign PLMN that manages security for the foreign PLMN. Thus, traffic between NFs in different PLMNs may traverse two SEPP functions, one for the home PLMN and another for the foreign PLMN.

[0032] The SEPP 126 may utilize an N32-c interface and an N32-f interface. The N32-c interface is a control plane interface between the two SEPPs that can be used to perform an initial handshake (e.g., a TLS handshake) and to negotiate various parameters for the N32-f interface connection and associated message transfer. The N32-f interface is a transport interface between the two SEPPs that can be used to transport various communications (e.g., 5GC request messages) between consumer and producer NFs after applying application-level security protections.

[0033] One problem with existing 5G architectures is that current NRF implementations use statically configured or unanimously agreed upon values ​​for various time-related parameters. However, connectivity and / or timing issues can arise when the time-related parameter values ​​are not suitable for the relevant use case or scenario (e.g., due to current network conditions or another factor affecting one or more NFs).

[0034] It will be understood that FIG. 1 is for illustrative purposes and that the various nodes and / or modules, locations and / or functionality described above in connection with FIG. 1 may be changed, modified, added, or removed.

[0035] FIG. 2 illustrates an example network node 200 for determining time-related parameter values ​​for a communications network (e.g., a 5G communications network). Node 200 may represent any suitable entity or entities for performing various aspects of authorization, registration, and / or configuration functions, e.g., for determining appropriate time-related parameter values ​​using relevant network and / or NF information. In some embodiments, node 200 may represent or include one or more 5G CNFs, e.g., 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, a data repository, a network gateway, a network proxy, an edge security device, or another functionality.

[0036] In some embodiments, node 200 or an associated module (e.g., a parameter configuration module) may be configured (e.g., via programming logic) to use network information and / or NF information (e.g., obtained periodically or aperiodically from NWDAF 210 and / or NF data provider(s) 212) to determine time-related parameter values ​​(e.g., 3GPP network parameter values). For example, node 200 or an associated module may communicate with NWDAF 210 and / or NF data provider(s) 212 to obtain current network or NF information periodically or periodically. In this example, node 200 or an associated module may use this 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 a value indicating a NF heartbeat interval (e.g., a 3GPP heartbeat timer), an NF subscription validity time, an NF discovery validity time, an NF access token expiration time, or an HTTP header retry timer (e.g., a value in a “Retry-After” HTTP header parameter field).

[0037] The NWDAF 210 may represent a network node or device configured to perform various network analysis functions. For example, the NWDAF 210 may include at least some NWDAF functionality defined in 3GPP TS 29.520. In some embodiments, the NWDAF 210 may provide a Nnwdaf_EventsSubscription service to enable NF service consumers to subscribe / unsubscribe to notifications about different analysis information. Example notification events may include slice load level information, network slice instance load level information, service experience, NF load, network performance, abnormal behavior, UE mobility, UE communication, user data congestion, or quality of service (QoS) persistence. In some embodiments, the NWDAF 210 may provide a Nnwdaf_AnalyticsInfo service to enable NF service consumers to request and obtain analysis information from a particular NWDAF 210. Analysis information available from an example NWDAF210 may include slice load level information, network slice instance load level information, service experience, NF load, network performance, abnormal behavior, UE mobility, UE communications, user data congestion, or quality of service (QoS) persistence.

[0038] NF data provider(s) 212 may represent one or more network nodes or devices configured to generate and / or provide NF metrics or other related NF information. For example, NF data provider(s) 212 may provide various types of metrics and / or data usable to determine appropriate time-related parameter values ​​to node 200, modules that determine time-related parameter values, and / or data stores accessible to node 200 or module(s) that determine time-related parameter values. Example NF metrics or related information may include congestion or overload conditions, message queue information, connection problem information, or various performance metrics, such as nf-name_message_processing_time, which indicates the time (in milliseconds) taken by a particular microservice of the NF to process a service operation.

[0039] In some embodiments, the NF data provider(s) 212 may include an NF or associated node that provides performance metrics, state information, or other related data about itself to one or more entities, such as the node 200 (e.g., the NRF 100) or a data store. In some embodiments, the NF data provider(s) 212 may include a network management system, a network tap, or a data aggregator that receives, intercepts, or derives various NF information and uses that information to generate and / or provide NF metrics and / or other data to one or more entities.

[0040] 2, node 200 may include one or more communication interface(s) 202 for communicating messages over a communication environment, e.g., a home 5GC network. For example, communication interface(s) 202 may include a first communication interface for communicating with a first set of SEPPs 126 in the home network, a second communication interface for communicating with a second set of SEPPs 126 in the home network, and a third communication interface for communicating with another entity in the home network.

[0041] The node 200 may include a time value determination module (TVDM) 204. The 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, the TVDM 204 may be configured to communicate with the NWDAF 210 and / or NF data provider(s) 212 to periodically or periodically 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, the TVDM 204 may subscribe to various events and may receive notifications of such events from the NWDAF 210 and / or NF data provider(s) 212. In this example, such event notifications and / or data therein may be used by the TVDM 204 when determining appropriate time-related parameter values.

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

[0043] In some embodiments, the TVDM 204 may be configured to access or utilize one or more data stores (e.g., in the data storage 206) that include 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 ​​for various time-related parameters. For example, the TVDM 204 may identify and / or use an associated rule based on various information, including, for example, network information and / or NF information obtained from or via one or more data sources, such as, for example, the NWDAF 210 and / or the NF data provider(s) 212. In this example, the associated rule may indicate an acceptable value, an acceptable range of values, or may provide a formula, algorithm, or another method for determining one or more acceptable time parameter values.

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

[0045] The node 200 and / or the TVDM 204 may access (e.g., read information from and / or write information to) the data storage 206. The data storage 206 may be any suitable entity (e.g., computer-readable medium or memory) for storing various data. In some embodiments, the data storage 206 may include network information, NF metrics, time value determination rules, default values, and / or related information used to dynamically determine or derive time-related parameter values. In some embodiments, the data storage 206 may include logic for obtaining or requesting related network information and / or NF information (e.g., NF performance metrics) from one or more data sources. In some embodiments, the data storage 206 may include logic or rules for detecting or determining one or more scenarios (e.g., network use cases) for adjusting the time-related parameter values. In some embodiments, the data storage 206 may include logic or rules for determining the time-related parameter values ​​based on the detected or determined scenarios.

[0046] It will be understood that FIG. 2 and its associated description are for illustrative purposes only, and that node 200 may include additional and / or different modules, components, or functionality.

[0047] 3 is a message flow diagram illustrating an example NRF 100 including 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 the TVDM 204 therein may utilize recent or current network information (e.g., analytical information from the NWDAF 210) and / or NF information (e.g., NF-related metrics from NF data provider(s) 212) to determine appropriate time-related parameter values, e.g., by adjusting default or previous values. For example, the NRF 100 or the TVDM 204 therein may dynamically determine time-related parameter values ​​(e.g., NF heartbeat interval values) based on a routing scenario associated with a requesting entity or current network conditions learned from data obtained from one or more data sources.

[0048] 3, in step 301, NF metrics or other NF-related information may be transmitted from NF data provider(s) 212 to the NRF 100 or an associated entity (e.g., data storage 206). For example, NF data provider(s) 212 may provide message processing time metrics associated with multiple NFs, e.g., NF1 207, NF2 208, and NF3 209.

[0049] In step 302, network information (e.g., analytical information) may be sent from the NWDAF 210 to the NRF 100 or an associated entity (e.g., data storage 206). In some examples, the NRF 100 or TVDM 204 may subscribe to various events via the Nnwdaf_EventsSubscription service provided by the NWDAF 210 and may receive notifications (along with the network information) when the subscribed events occur. In some examples, the NRF 100 or TVDM 204 may request analytical information at periodic or aperiodic intervals using the Nnwdaf_AnalyticsInfo service provided by the NWDAF 210.

[0050] In step 303, an NF registration related request message (e.g., an NFRegister or NFUpdate message) may be transmitted from NF1 207 to the NRF 100. For example, assuming NF1 207 is a visitor PLMN (different from the NRF 100), the NFRegister message may originate from NF1 207 and may pass through the SEPP 126 before reaching the NRF 100. In this example, the NRF 100 or TVDM 204 may analyze 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, such as, for example, an NF heartbeat interval (e.g., a 3GPP heartbeat timer value) associated with the NF registration related request message.

[0051] In some embodiments, the NF heartbeat interval may represent a parameter or setting indicating the amount of time (e.g., in seconds) expected between two consecutive heartbeat messages, e.g., from an NF instance (e.g., NF1 207) to the NRF 100. In some embodiments, the NF heartbeat interval may be determined and provided during the NF registration or NF update procedure using a "heartbeat timer" parameter. For example, a proposed value for the NF heartbeat timer parameter may be provided by NF1 207 to the NRF 100 in an NFRegister request message. In this example, if the proposed heartbeat timer value is acceptable (e.g., as determined by the NRF 100 and / or the TVDM 204 therein), the NRF 100 may confirm the value in the NFRegister response message. If the proposed heartbeat timer value is unacceptable (e.g., as determined by the NRF 100 and / or the TVDM 204 therein), the NRF 100 and / or the TVDM 204 therein may determine different time-related parameter values ​​(e.g., by adjusting default values ​​depending on network and / or NF conditions) and provide the different time-related parameter values ​​in an NFRegister response message to NF1 207.

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

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

[0054] In some embodiments, the NF subscription validity time may represent a parameter or setting that indicates the amount of time (e.g., in hours) for which the associated subscription is active, e.g., after which the subscription may be considered inactive and / or deleted at the NRF 100. In some embodiments, the validity time of the NF subscription may be determined and provided during the NF subscription procedure using a "validity time" parameter. For example, a proposed value for the subscription validity time parameter may be provided to the NRF 100 in an NFStatusSubscribe request (e.g., subscription creation request) message by the NF1 207. In this example, if the proposed subscription validity value is acceptable (e.g., as determined by the NRF 100 and / or TVDM 204 therein), the NRF 100 may confirm the value in the NFStatusSubscribe response message. If the proposed subscription validity value is not acceptable (e.g., as determined by the NRF 100 and / or TVDM 204 therein), the NRF 100 and / or TVDM 204 therein may determine different time-related parameter values ​​(e.g., by adjusting default values ​​depending on network and / or NF conditions) and provide the different time-related parameter values ​​in an NFStatusSubscribe response message to NF1 207.

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

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

[0057] In some embodiments, the NF discovery validity period may represent a parameter or setting that indicates the amount of time (e.g., in hours) that a discovery or search-derived search result is valid, e.g., after which the search result may be considered invalid and / or deleted from the cache of an NF service consumer, e.g., NF1 207. In some embodiments, the NF discovery validity period may be determined and provided during the NF discovery procedure using a "validity period" parameter. For example, a proposed value for the discovery validity period parameter may be provided to the NRF100 in an NFDiscover request message by NF1 207. In this example, if the proposed discovery validity value is acceptable (e.g., as determined by the NRF100 and / or the TVDM 204 therein), the NRF100 may confirm the value in the NFDiscover response message. If the proposed discovery validity value is not acceptable (e.g., as determined by the NRF 100 and / or the TVDM 204 therein), the NRF 100 and / or the TVDM 204 therein may determine different time-related parameter values ​​(e.g., by adjusting default values ​​depending on network and / or NF conditions) and provide the different time-related parameter values ​​to NF1 207 in an NFDiscover response message.

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

[0059] In step 309, an NF access token request message (e.g., an NFAccessToken request message) may be transmitted from NF1 207 to NRF 100. For example, NRF 100 or TVDM 204 may analyze characteristics of the received NFAccessToken request message along with learned network information and / or NF information and determine that an NF associated with the access token request is overloaded or congested and may dynamically determine one or more time-related parameters, such as an NF access token expiration time value, associated with the NF access token request message.

[0060] In some embodiments, the NF access token expiration time may represent a parameter or setting indicating an amount of time (e.g., in hours) that an NF access token is valid, e.g., after which the access token may be considered invalid. In some embodiments, the NF access token expiration time may be determined and provided during the NF access token request procedure using an "expiry time" parameter. For example, an NFAccessToken request message may be sent from NF1 207 to NRF100. In this example, NRF100 and / or the TVDM 204 therein may determine the expiration time related parameter value (e.g., by adjusting a default value depending on network and / or NF conditions) and may provide the time related parameter value in an NFAccessToken response message to NF1 207.

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

[0062] It will be understood that Figure 3 is for illustrative purposes and that different and / or additional messages and / or actions may be used. It will also be understood that the various messages and / or actions described herein may occur in different orders or sequences.

[0063] FIG. 4 illustrates example rule data 400 illustrating rule IDs and associated time-related parameter value determination rules for determining a time-related parameter value for one or more time-related parameters (e.g., based on network conditions, NF performance metrics, and / or another factor). For example, rule data 400 may indicate a mapping (e.g., correlation) between rule IDs and associated time-related parameter value determination rules. In some embodiments, the rule mapping or correlation may be statically configured by an operator or may be dynamically generated by NRF 100, e.g., using historical data and user-provided preferences. For example, NRF 100 may receive from a network operator a set of rules for different scenarios and expected performance information for NRF 100. In this example, if a rule for a given scenario does not have an expected result (e.g., NRF is still experiencing congestion), NRF 100 may dynamically adjust the rule (e.g., increase the time-related parameter value by 15%) in an attempt to achieve the expected result.

[0064] In some embodiments, the node 200, the NRF 100, or the TVDM 204 may be configured to select a time-related parameter value determination rule and / or logic based on a characteristic or scenario associated with the received message or an associated entity, e.g., an NF service consumer or an NF service producer. For example, the NRF 100 may analyze the received message to determine whether the message originated or was forwarded from a different PLMN (e.g., by the visitor NRF 100 or the NF1 207). In addition to or instead of where the received message originated, the NRF 100 may use various data (e.g., periodically retrieved network information and / or NF information) to determine whether itself or another network entity (e.g., the requesting entity) is experiencing a congestion event or another problem that may affect processing or communications. In this example, using various information available to the NRF 100, the NRF 100 may select an associated time-related parameter value determination rule, which may indicate a formula or logic for determining an appropriate value for a particular time-related parameter. For example, if node 200, NRF 100, or TVDM 204 determines that NRF 100 is experiencing congestion, time-related parameter value determination rule "ID4" may be selected to double or triple a predetermined default value for a particular short-term parameter (e.g., NF heartbeat interval or HTTP header retry timer). In another example, node 200, NRF 100, or TVDM 204 determines that the requesting entity is located in a different network, and time-related parameter value determination rule "ID1" may be selected to increase a predetermined or proposed default value by 25%, or to increase a predetermined default value such that the new time-related parameter value is greater than the derived or estimated one-way delay or another metric.

[0065] 4, a table representing rule data 400 includes columns and / or columns for rule IDs and corresponding time-related parameter value determination rules. The rule ID column may store information to represent an identifier that identifies a time-related parameter value determination rule. In some embodiments, each rule ID may be globally unique within a PLMN, such as a unique number or alphanumeric value. In some embodiments, the rule ID may be hierarchical or may provide insight into associated rules. In some embodiments, the rule ID may be non-hierarchical or opaque with respect to insight into associated rules.

[0066] The time-related parameter value determination rules field may represent one or more rules or logic for determining a time-related parameter value for one or more time-related parameters. In some embodiments, the rules may be based on a network or NF scenario and / or an identifiable characteristic associated with a received message, a requesting entity, or an associated service. Example scenario-based rules may include one or more time-related parameter value determination rules for an NRF-to-NRF transfer scenario, a geo-redundancy scenario, an NF congestion rule, and an NRF congestion scenario.

[0067] In some embodiments, node 200, NRF 100, or TVDM 204 may be configured to determine that a received message or associated entity is associated with an NRF-to-NRF forwarding scenario using one or more association rules and may adjust one or more time-related parameters depending on various information, such as information obtained via NWDAF 210 and / or NF data provider(s) 212. For example, node 200, NRF 100, or TVDM 204 may determine that a received message is associated with an NRF-to-NRF forwarding scenario when NRF 100 lacks information regarding an associated producer NF associated with the received message, and thus may include various messages that cross PLMN boundaries and regions. In this example, after detecting an NRF-to-NRF transfer scenario, the node 200, NRF 100, or TVDM 204 may 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), e.g., to reduce traffic crossing PLMN boundaries and different regions and / or to allow additional time for expected or possible packet delays.

[0068] In some embodiments, node 200, NRF 100, or TVDM 204 may be configured to determine that a received message or associated entity is associated with a geo-redundancy scenario and may use one or more association rules to adjust one or more time-related parameters depending on various information, e.g., information obtained via NWDAF 210 and / or NF data provider(s) 212. For example, node 200, NRF 100, or TVDM 204 may determine that a received message is associated with a geo-redundancy scenario when the received message or associated message traverses one or more geo-redundancy sites, and so may include various messages being processed from NFs of mate or peer NRF 100. In this example, after detecting a geo-redundant scenario, the node 200, NRF 100, or TVDM 204 may 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), e.g., to reduce traffic traversing the geo-redundant site and / or to allow additional time for expected or possible packet delays.

[0069] In some embodiments, node 200, NRF 100, or TVDM 204 may be configured to determine that NRF 100 is experiencing operational issues (e.g., overloading, handling peak traffic, under maintenance, etc.) based on acquired network and / or NF information and may adjust one or more time-related parameters due to such issues using one or more associated rules. For example, node 200, NRF 100, or TVDM 204 may determine that NRF 100 is experiencing congestion or under maintenance based on various information (e.g., via subscribed event notifications from NWDAF 210). In this example, after detecting that NRF100 is congested or undergoing maintenance, node 200, NRF100, or TVDM204 may 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), e.g., to reduce traffic processed by NRF100 and / or to allow additional time for expected or possible packet delays.

[0070] In some embodiments, node 200, NRF 100, or TVDM 204 may be configured to determine that a NF (e.g., a required or suitable producer NF for processing a particular service request) is experiencing an operational issue (e.g., an overload condition, peak traffic handling, under maintenance, etc.) based on obtained network and / or NF information, and may adjust one or more time-related parameters due to such issue using one or more associated rules. For example, node 200, NRF 100, or TVDM 204 may determine that a producer NF is experiencing congestion or under maintenance based on various information (e.g., nf-name_message_processing_time metric or associated data from NF data provider(s) 212). In this example, after detecting that a producer NF is in a congested state or undergoing maintenance, the node 200, NRF 100, or TVDM 204 may 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), e.g., to reduce non-critical traffic and / or to allow additional time for expected or possible packet delays. In some embodiments, by increasing a value associated with a time-related parameter (e.g., NF heartbeat interval), the overloaded NF may reduce its heartbeat-related traffic to the NRF 100 and may instead use its resources to process requests during the overload state.

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

[0072] It will also be appreciated that the rules data 400 is for illustrative purposes and that data different from and / or in addition to the data shown in FIG. 4 may be available for determining time-related parameter values. For example, the rules data 400 may include various scenarios not shown, including combination scenarios, such as NRF and NF congestion. In this example, the rules data 400 may include a priority value to indicate which rule(s) is selected or used. In another example, the rules data 400 may include one or more rules for different time-related parameters for the same scenario. Additionally, the rules data 400 may be stored (e.g., in the data storage 206) using various data structures and / or computer-readable media.

[0073] FIG. 5 illustrates an example default value information 500 for various time-related parameters in a communication network. For example, the default value information 500 may indicate values ​​associated with various time-related parameters. In some embodiments, for example, if the NRF 100 does not determine the time-related parameters based on recent network and / or NF information, the NRF 100 may utilize the default value information 500 to select the time-related parameters regardless of the situation or scenario before adjusting them based on network information, NF metrics, or another information. In this example, the default values ​​may be predetermined, for example, by a network operator or by time-related parameter value determination rules (e.g., rules in the rule data 400). Continuing with this example, the time-related parameter values ​​may be determined by adjusting (e.g., increasing or decreasing) the default values ​​in response to or based at least in part on current network and / or NF information, e.g., information indicative of network congestion, NRF maintenance, inter-PLMN communication, high NF load, etc.

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

[0075] 5, a 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 a time-related parameter value determination rule (e.g., in rule data 400). The time-related parameter field may store information for representing a time-related parameter (e.g., a 3GPP network parameter) that indicates or represents an amount or duration of time. Example time-related parameters shown in FIG. 5 include a NF heartbeat interval (e.g., a 3GPP "heartbeat timer"), an NF subscription validity time, an NF discovery validity time, an NF access token expiration time, or an HTTP header retry timer (e.g., a value in a "Retry-After" HTTP header parameter field).

[0076] The default value column may indicate a default value (e.g., an initial value) associated with a particular time-related parameter. In some embodiments, the default value may be in seconds, minutes, hours, or days, and / or may be based on a percentage or formula utilizing a suggested time from the NF and / or other data (e.g., the default value for the heartbeat interval parameter may be 10% less than the suggested time, but not to exceed 70 seconds).

[0077] As shown in FIG. 5, a default value for the NF heartbeat interval parameter may be 30 seconds, a default value for the NF subscription validity parameter may be 6 hours, a default value for the NF discovery validity parameter may be 1 hour, a default value for the NF access token expiration time parameter may be 1 hour, and a default value for the HTTP header retry timer parameter may be 30 seconds.

[0078] For example, the HTTP header retry timer may represent a parameter or setting indicating the amount of time (e.g., in seconds) that the NF waits to retry a service operation at the NRF 100. In some embodiments, the HTTP header retry timer may be determined when the NRF 100 should send an HTTP 503 error message indicating that the service is unavailable and provided to the NF service consumer (e.g., NF1 207) in a "Retry-After" HTTP header field. For example, when the NRF 100 experiences an overload condition, the NRF 100 may reject some HTTP requests by sending an HTTP 503 message including an HTTP header field "Retry-After" to indicate an estimated time (in seconds) for recovery of the service. In this example, the NRF 100 and / or the TVDM 204 therein may determine the HTTP retry timer value (e.g., by adjusting a default value depending on the network and / or NF conditions).

[0079] It will also be understood that default value information 500 is for illustrative purposes, and that different and / or additional data than that shown in Figure 5 may be used to indicate default values ​​for various time-related parameters. Additionally, default value information 500 may be stored (e.g., within data store 206) using various data structures and / or computer-readable media.

[0080] 6 illustrates an example process 600 for determining time-related parameter values ​​in a communications network. In some embodiments, the example process 600 described herein, or portions thereof, may be performed in or by a network node, such as the NRF 100, node 200, TVDM 204, and / or another module, NF, or node.

[0081] Referring to process 600, at step 602, a service request message may be received from a first NF. In some embodiments, the service request message may include an NF registration request message, an NF update request message, an NF status subscription request message, an NF discovery request message, or an NF access token request message.

[0082] In step 604, a time-related parameter value associated with the service request message may be determined using the network information and / or the NF information. In some embodiments, the time-related parameter value may indicate a NF heartbeat interval (e.g., a 3GPP heartbeat timer), an NF subscription validity time, an NF discovery validity time, an NF access token expiration time, or an HTTP header retry timer (e.g., a value in a “Retry-After” HTTP header parameter field).

[0083] In some embodiments, at least some network or NF information may be obtained periodically or aperiodically (e.g., dynamically) from one or more data sources, such as a local data store (e.g., relative to the NRF 100), a remote data source (e.g., relative to the NRF 100), the NWDAF 210, or the NF data provider(s) 212.

[0084] In some embodiments, at least some network information may be obtained using the Nnwdaf_EventsSubscription service or the Nnwdaf_AnalyticsInfo service. For example, such as every 60 seconds, the NRF 100 or another entity may send one or more Nnwdaf_AnalyticsInfo service request messages to the NWDAF 210 to obtain load level information for one or more network slice instances associated with the 5G communication network. In another example, the 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 the NWDAF 210.

[0085] In some embodiments, determining the time-related parameter value may include determining that the NRF, the first NF, or the network entity may be experiencing a congestion state change, a workload amount change, or an operational state change, and adjusting the time-related parameter value from a default value or a previous value accordingly. For example, the default value or previous value may be predetermined by a network operator or may be generated using a predetermined policy or rule.

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

[0087] In some embodiments, determining the time-related parameter value may include determining that the service request message or the associated message is likely to be an inter-public land mobile network (PLMN) message and, in response, increasing the time-related parameter value from an initial or default value.

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

[0089] It will be understood that process 600 is for illustrative purposes and that different and / or additional actions may be used. It will also be understood that the various actions described herein may occur in a different order or sequence.

[0090] Although certain aspects of the subject matter described herein have been discussed with reference to 5G networks, it will be appreciated that a variety of other networks may utilize certain aspects of the subject matter described herein. For example, any network may benefit from dynamically determined time-related parameter values, e.g., time-related parameter values ​​based on network conditions, NF-related metrics, and / or other information.

[0091] It should be noted that the node 200, the TVDM 204, and / or the functionality described herein may constitute a special purpose computing device. Furthermore, the node 200, the TVDM 204, and / or the functionality described herein may 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 may be improved and timing issues may be reduced. In this example, by utilizing one or more techniques and / or methods described herein, the NRF 100 or the TVDM 204 therein may determine time-related parameter values ​​based on network conditions, NF-related metrics, and / or other factors. Furthermore, such techniques and / or methods described herein may be applicable 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.

[0092] The disclosure of each of the following references is incorporated herein by reference in its entirety to the extent that it is not inconsistent with the present specification and to the extent that it supplements, explains, provides background to, or teaches the methods, techniques, and / or systems employed herein. References 1. 3GPP TS 29.510; 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 17), V17.1.0 (2021-03). 2. 3GPP TS 33.501; 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security Architecture and Procedures for the 5G System; (Release 17), V17.1.0 (2021-03). 3. 3GPP TS 29.520; 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Data Analytics Services; Stage 3 (Release 17), V17.2.0 (2021-03) It will be understood that various details of the presently disclosed subject matter may be changed without departing from the scope of the presently disclosed subject matter. Further, the foregoing description is by way of example only and not by way of limitation.

Claims

1. 1. A method for determining a time-related parameter value for a communications network, comprising the steps of: A Network Function (NF) Repository Function (NRF) comprising at least one processor, receiving a service request message from a first network function (NF); determining a time-related parameter value associated with said service request message using network information and / or NF information; generating and transmitting to the first NF a service response message indicating the time-related parameter value; A method comprising:

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

3. The method of claim 2 , wherein the one or more data sources include a local data store, a remote data source, a network data analysis facility (NWDAF), or a NF data provider.

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

5. The method of any of claims 1 to 3, wherein determining the time-related parameter value comprises determining that the NRF, the first NF, or a network entity is experiencing a congestion state change, a workload amount change, or an operational state change, and adjusting the time-related parameter value from a default value or a previous value accordingly.

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

7. 4. The method of claim 1, wherein determining the time-related parameter value comprises determining that the service request message or an associated message requires forwarding from an NRF to an NRF, and adjusting the time-related parameter value from an initial or default value accordingly.

8. 4. The method of claim 1, wherein determining the time-related parameter value comprises determining that the service request message or an associated message is an inter-Public Land Mobile Network (PLMN) message, and adjusting the time-related parameter value accordingly from an initial or default value.

9. The method according to any one of claims 1 to 3, wherein the service request message comprises an NF registration request message, an NF update request message, an NF status subscription request message, an NF discovery request message, or an NF access token request message.

10. The method according to any one of claims 1 to 3, wherein the time-related parameter value indicates a NF heartbeat interval, a NF subscription validity time, a NF discovery validity time, a NF access token expiration time, or a HyperText Transfer Protocol (HTTP) header retry timer.

11. 1. A system for determining a time-related parameter value for a communication network, comprising: At least one processor; and Memory A network function (NF) repository function (NRF) comprising: The NRF is receiving a service request message from a first network function (NF); determining a time-related parameter value associated with said service request message using network information and / or NF information; and generating and transmitting to the first NF a service response message indicating the time-related parameter value. system.

12. The system of claim 11 , wherein the NRF is configured to periodically or aperiodically obtain at least a portion of the network information or the NF information from one or more data sources.

13. The system of claim 12 , wherein the one or more data sources include a local data store, a remote data source, a network data analysis facility (NWDAF), or a NF data provider.

14. The system according to any one of claims 11 to 13, wherein the NRF is configured to obtain at least a portion of the network information using a Nnwdaf_EventsSubscription service or a Nnwdaf_AnalyticsInfo service.

15. The system of any of claims 11 to 13, wherein determining the time-related parameter value includes determining that the NRF, the first NF, or a network entity is experiencing a congestion state change, a workload amount change, or an operational state change, and adjusting the time-related parameter value from a default value or a previous value accordingly.

16. The system of any of claims 11 to 13, wherein determining the time-related parameter value comprises determining that the service request message or an associated message requires forwarding from an NRF to an NRF, and adjusting the time-related parameter value accordingly from a default value or a previous value.

17. 14. The system of claim 11, wherein determining the time-related parameter value comprises determining that the service request message or an associated message is an inter-Public Land Mobile Network (PLMN) message, and adjusting the time-related parameter value accordingly from a default or previous value.

18. The system according to any one of claims 11 to 13, wherein the service request message comprises an NF registration request message, an NF update request message, an NF status subscription request message, an NF discovery request message, or an NF access token request message.

19. The system of any one of claims 11 to 13, wherein the time-related parameter value indicates a NF heartbeat interval, a NF subscription validity time, a NF discovery validity time, a NF access token expiration time, or a HyperText Transfer Protocol (HTTP) header retry timer.

20. A program, When executed by a computer, A Network Function (NF) Repository Function (NRF) comprising at least one processor, receiving a service request message from a first network function (NF); determining a time-related parameter value associated with said service request message using network information and / or NF information; generating and transmitting to the first NF a service response message indicating the time-related parameter value; A program causing the computer to execute steps including the steps of:

Images