Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
  • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W48/00—Access restriction; Network selection; Access point selection
  • H04W48/18—Selecting a network or a communication service
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L43/00—Arrangements for monitoring or testing data switching networks
  • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
  • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/50—Network services
  • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/28—Timers or timing mechanisms used in protocols
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W24/00—Supervisory, monitoring or testing arrangements
  • H04W24/02—Arrangements for optimising operational condition
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W48/00—Access restriction; Network selection; Access point selection
  • H04W48/16—Discovering, processing access restriction or access information
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W84/00—Network topologies
  • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
  • H04W84/04—Large scale networks; Deep hierarchical networks
  • H04W84/042—Public Land Mobile systems, e.g. cellular systems

Definitions

• the subject matter described herein relates to improving communications in fifth generation (5G) and subsequent generation communications 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 subsequent generation communications networks.
• a network node that provides service is referred to as a producer network function (NF).
• a network node that consumes services is referred to as a consumer NF.
• a network function can be both a producer NF and a consumer NF depending on whether it is consuming or providing service.
• a given producer NF may have many service endpoints, where a service endpoint is the point of contact for one or more NF instances hosted by the producer NF.
• the service endpoint is identified by a combination of Internet protocol (IP) address and port number or a fully qualified domain name that resolves to an IP address and port number on a network node that hosts a producer NF.
• IP Internet protocol
• An NF instance is an instance of a producer NF that provides a service.
• a given producer NF may include more than one NF instance. It should also be noted that multiple NF instances can share the same service endpoint.
• Producer NFs register with an NF repository function (NRF).
• the NRF maintains service profiles of available NF instances identifying the services supported by each NF instance.
• Consumer NFs can subscribe to receive information about producer NF instances that have registered with the NRF.
• another type of network node that can subscribe to receive information about NF service instances is a service communication proxy (SCP).
• SCP subscribes with the NRF and obtains reachability and service profile information regarding 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 directly routes the traffic to the destination producer NF instance.
• SEPP security edge protection proxy
• PLMNs 5G public land mobile networks
• API application programming interface
• timing issues can affect connectivity and usability. For example, if an access token or a subscription expires too soon, then an NF may not receive an expected or desired response. Flence, there exists a need for improving a communications network by reducing or mitigating timing issues.
• One method for determining time related parameter values for a communications network occurs at a network function (NF) repository function (NRF) comprising at least one processor.
• the method comprises: receiving, from a first NF, a service request message; determining, using network information and/or NF information, a time related parameter value associated with the service request message; and generating and sending, to the first NF, a service response message indicating the time related parameter value.
• NF network function
• NRF network function repository function
• One example system for determining time related parameter values for a communications network includes an NRF comprising at least one processor and a memory.
• the NRF is configured for: receiving, from a first NF, a service request message; determining, using network information and/or NF information, a time related parameter value associated with the service request message; and generating and sending, to the first NF, a service response message indicating the time related parameter value.
• One example non-transitory computer readable medium comprising computer executable instructions embodied in the non-transitory computer readable medium that when executed by at least one processor of at least one computer cause the at least one computer to perform steps comprising: at an NRF comprising at least one processor: receiving, from a first NF, a service request message; determining, using network information and/or NF information, a time related parameter value associated with the service request message; and generating and sending, to the first NF, a service response message indicating the time related parameter value.
• At least some network information or NF information may be obtained periodically or aperiodically from one or more data sources.
• one or more data sources may include a local data store, a remote data source, a network data analytics function (NWDAF), or an NF data provider.
• NWDAF network data analytics function
• At least some network information may be obtained using an Nnwdaf_EventsSubscription service or an Nnwdaf_Analyticslnfo service.
• determining a time related parameter value may include determining that an NRF, a first NF, or a network entity may be experiencing a congestion status change, a change in workload amount, or an operational status change; and, in response to the determination, adjusting the time related parameter value from a default value or a prior value.
• a default value or a prior value may be predetermined by a network operator or may be generated using a predetermined policy or rule.
• determining a time related parameter value may include determining that a service request message or a related message requires NRF to NRF forwarding; and, in response to the determination, increasing the time related parameter value from an initial or default value.
• determining a time related parameter value may include determining that a service request message or a related message may 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.
• PLMN public land mobile network
• a 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.
• a time related parameter value may indicate an NF heartbeat interval, an NF subscription validity time, an NF discovery validity time, an NF access token expiry time, or a hypertext transfer protocol (HTTP) header retry timer.
• HTTP hypertext transfer protocol
• the subject matter described herein may be implemented in hardware, software, firmware, or any combination thereof.
• the terms “function” “node” or “module” as used herein refer to hardware, which may also include software and/or firmware components, for implementing the feature being described.
• the subject matter described herein may be implemented using a computer readable medium having stored thereon computer executable instructions that when executed by the processor of a computer control the computer to perform steps.
• Example 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.
• a computer readable medium that implements the subject matter described herein may be located on a single device or computing platform or may be distributed across multiple devices or computing platforms.
• Figure 1 is a network diagram illustrating an example fifth generation (5G) network architecture
• Figure 2 is a diagram illustrating an example network node for determining time related parameter values for a communications network
• Figure 3 is a message flow diagram illustrating an example NRF dynamically determining time related parameter values using network information and/or NF information
• Figure 4 is a diagram illustrating example rule data indicating rule IDs and related time related parameter value determination rules ;
• Figure 5 is a diagram illustrating example default value information for various time related parameters.
• Figure 6 is a flow chart illustrating an example process for determining time related parameter values for a communications network.
• NF network function repository function
• NF heartbeat interval e.g., a 3GPP heart-beat timer
• NF subscription validity time e.g., an NF discovery validity time
• NF access token expiry time e.g., an HTTP header retry timer
• HTTP header retry timer e.g., a value in a "Retry-After" HTTP header parameter field
• time related parameter values are not appropriate for relevant use-cases or scenarios (e.g., current network conditions or other factors affecting one or more NFs).
• statically configured time related parameter values may not allow effective communications between NFs or other network elements, e.g., since some network use-cases or scenarios (e.g., communications that traverse different localities and PLMNs) can cause various delays.
• an NRF in accordance with various aspects described herein may be configured for receiving, from a first NF, a service request message; determining, using network information and/or NF information, a time related parameter value associated with the service request message; and generating and sending, to the first NF, a service response message indicating the time related parameter value.
• the network information and/or NF information used in the determination may be periodically or aperiodically obtained from various data sources, such as a network data analytics function (NWDAF) or another NF data provider (e.g., an NF metrics server).
• NWDAAF network data analytics function
• NF metrics server another NF data provider
• a NRF or other entity may determine time related parameter values based on various information, e.g., dynamic network conditions and/or NF health or performance metrics. Further, since some time related parameters values (e.g., an NF heartbeat interval value and/or an HTTP header retry timer value) can directly affect the amount and/or frequency of some traffic sent by NFs, dynamic determination of time related parameter values can reduce traffic processing load at NFs and NRF or improve resource utilization. For example, by increasing the allowed time between consecutive heartbeat message when network congestion is detected, an NF can spend less time sending such messages and an NRF can spend less time processing such message.
• time related parameters values e.g., an NF heartbeat interval value and/or an HTTP header retry timer value
• an example NRF may increase 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.
• time related parameter values e.g., optimized and/or use case based timer values
• an example NRF in accordance with 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.
• FIG. 1 is a block diagram illustrating an example 5G system network architecture, e.g., a home 5G core (5GC) network.
• the architecture in Figure 1 includes an NRF 100 and an SCP 101, which may be located in the same home public land mobile network (PLMN).
• NRF 100 may maintain profiles of available producer NF service instances and their supported services and allow consumer NFs or SCPs to subscribe to and be notified of the registration of new/updated producer NF service instances.
• SCP 101 may also support service discovery and selection of producer NF instances.
• SCP 101 may perform load balancing of connections between consumer and producer NFs.
• SCP 101 may perform preferred NF location based selection and routing.
• NRF 100 is a repository for NF or service profiles of producer NF instances.
• a consumer NF or an SCP In order to communicate with a producer NF instance, a consumer NF or an SCP must obtain the NF or service profile or the producer NF instance from NRF 100.
• the NF or service profile may a JavaScript object notation (JSON) data structure defined in 3GPP TS 29.510.
• JSON JavaScript object notation
• 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.
• FQDN fully qualified domain name
• IPv4 Internet protocol version 4
• IPv6 IP version 6
• the nodes include a policy control function (PCF) 102 that performs policy related operations in a network, a unified data management (UDM) function 104 that manages user data, and an application function (AF) 106 that provides application services.
• PCF policy control function
• UDM unified data management
• AF application function
• the nodes illustrated in Figure 1 further include a session management function (SMF) 108 that manages sessions 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 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.
• MME mobility management entity
• AUSF authentication server function
• a network slice selection function (NSSF) 116 provides network slicing services for devices seeking to access specific network capabilities and characteristics associated with a network slice.
• a network exposure function (NEF) 118 provides application programming interfaces (APIs) for application functions seeking to obtain information about Internet of things (loT) devices and other UEs attached to the network. NEF 118 performs similar functions to the service capability exposure function (SCEF) in 4G networks.
• SCEF service capability exposure function
• a radio access network (RAN) 120 connects UE 114 to the network via a wireless link.
• RAN 120 may be accessed using a g-Node B (gNB) (not shown in Figure 1 ) or other wireless access point.
• gNB g-Node B
• a user plane function (UPF) 122 can support various proxy functionality for user plane services.
• proxy functionality is multipath transmission control protocol (MPTCP) proxy functionality.
• MPTCP multipath transmission control protocol
• UPF 122 may also support performance measurement functionality, which may be used by UE 114 to obtain network performance measurements.
• DN data network
• DN data network
• SEPP Security edge protection proxy
• SEPP 126 filters incoming traffic from another PLMN and performs topology hiding for traffic exiting the home PLMN.
• SEPP 126 may communicate with an SEPP in a foreign PLMN which manages security for the foreign PLMN.
• traffic between NFs in different PLMNs may traverse two SEPP functions, one for the home PLMN and the other for the foreign PLMN.
• SEPP 126 may utilize an N32-c interface and an N32-f interface.
• An N32-C interface is a control plane interface between two SEPPs usable for performing an initial handshake (e.g., a TLS handshake) and negotiating various parameters for an N32-f interface connection and related message forwarding.
• An N32-f interface is a forwarding interface between two SEPPs usable for forwarding various communications (e.g., 5GC request messages) between a consumer NF and a producer NF after applying application level security protection.
• Figure 1 is for illustrative purposes and that various nodes and/or modules, locations, and/or functionality described above in relation to Figure 1 may be changed, altered, added, or removed.
• FIG. 2 is a diagram illustrating 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., determining appropriate time related parameter values using relevant network information and/or NF information.
• node 200 may represent or include one or more 5GC NFs, e.g., NRF 100.
• node 200 may represent or include a consumer NF or a producer NF.
• node 200 may represent or include an authorization server, a data repository, a network gateway, a network proxy, an edge security device, or other functionality.
• node 200 ora related module may be configured (e.g., via programming logic) for determining time related parameter values (e.g., 3GPP network parameters values) using network information and/or NF information (e.g., obtained periodically or aperiodically from NWDAF 210 and/or NF data provider(s) 212.
• time related parameter values e.g., 3GPP network parameters values
• NF information e.g., obtained periodically or aperiodically from NWDAF 210 and/or NF data provider(s) 212.
• node 200 or a related module may communicate with a NWDAF 210 and/or an NF data provider(s) 212 to periodically or periodically obtain current network information or NF information.
• node 200 or a related 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 values indicating an NF heartbeat interval (e.g., a 3GPP heart-beat timer), an NF subscription validity time, an NF discovery validity time, an NF access token expiry time, or an FITTP header retry timer (e.g., a value in a "Retry-After" HTTP header parameter field).
• NWDAF 210 may represent a network node or device configured for performing various network analytics functions.
• NWDAF 210 may include at least some NWDAF functionality defined in 3GPP TS 29.520.
• NWDAF 210 may provide an Nnwdaf_EventsSubscription service for enabling NF service consumers to subscribe to/unsubscribe from notifications for different analytics 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) sustainability.
• QoS quality of service
• NWDAF 210 may provide an Nnwdaf_Analyticslnfo service for enabling NF service consumers to request and get specific analytics information from NWDAF 210.
• Example analytics information available from NWDAF 210 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) sustainability.
• QoS quality of service
• NF data provider(s) 212 may represent one or more network nodes or devices configured for generating and/or providing NF metrics or other related NF information.
• NF data provider(s) 212 may provide various types of metrics and/or data usable for determining appropriate time related parameter values to node 200, a module for determining time related parameter values, and/or a data store accessible to node 200 or module(s) for determining time related parameter values.
• Example NF metrics or related information may include a congestion or overload status, message queue information, connectivity issue information, or various performance metrics, such as an nf-name_message_processing_time for indicating the time taken (in milliseconds) by an NF’s specific microservice to process a service operation.
• NF data provider(s) 212 may include an NF or related node providing performance metrics, state information, or other relevant data about itself to one or more entities, e.g., node 200 (e.g., NRF 100) or a data store.
• 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.
• node 200 may include one or more communications interface(s) 202 for communicating messages via a communications environment, e.g., a home 5GC network.
• communications interface(s) 202 may include a first communication interface for communicating with a first set of SEPPs 126 in a home network, a second communications interface for communicating with a second set of SEPPs 126 in a home network, and a third communications interface for communicating with other entities in a home network.
• 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.
• TVDM 204 may be configured for communicating with NWDAF 210 and/or NF data provider(s) 212 to periodically or periodically obtain relevant (e.g., current or recent) network information or NF information for determining appropriate time related parameter values for various scenarios and/or service operations.
• NWDAF 210 and/or NF data provider(s) 212 may subscribe to various events and may receive notifications of such events from NWDAF 210 and/or NF data provider(s) 212. In this example, such event notifications and/or data therein may be used by TVDM 204 when determining appropriate time related parameter values.
• TVDM 204 may be configured for using obtained network information and/or NF information when determining one or more time related parameter values.
• TVDM 204 may be configured for receiving, from NF3 209, a service request message (e.g., an NFUpdate message); determining, using network information and/or NF information, a time related parameter value associated with the service request message; and generating and sending, to NF3 209, a service response message (e.g., an "200 OK" response message) indicating the time related parameter value.
• a service request message e.g., an NFUpdate message
• determining, using network information and/or NF information a time related parameter value associated with the service request message
• a service response message e.g., an "200 OK" response message
• NRF 100 may determine that NRF 100 and/or another NF (or a related transmission path) is experiencing congestion or operational issues, and, to alleviate congestion and/or mitigate one or more negative affects associated with the detected issue(s), NRF 100 may determine to temporarily increase (e.g., relative to a prior used value) an NF heartbeat interval (e.g., a 3GPP heart-beat timer) associated with NF3 209, thereby reducing the number and frequency of heartbeat messages need to be sent by NF3 209 to be deemed operational (or “alive”), e.g., by NRF 100.
• an NF heartbeat interval e.g., a 3GPP heart-beat timer
• NRF 100 may determine to decrease the NF heartbeat interval associated with NF3 209 (e.g., back to a default or pre issue value) when NF3 209 sends another service request message (e.g., an NFUpdate message).
• TVDM 204 may be configured for accessing or utilizing one or more data stores (e.g., in data storage 206) containing rules for determining time related parameters based on various scenarios (e.g., use-cases, network conditions, NRF and/or NF congestion, communications path related delays like inter-PLMN communications and/or geo-redundant sites, etc.) and/or default values for various time related parameters.
• 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 NF data provider(s) 212.
• a relevant rule may indicate an acceptable value, an acceptable range of values or may provide a formula, an algorithm, or other way for determining one or more acceptable time parameter values.
• TVDM 204 may be configured for accessing or utilizing one or more data stores (e.g., in data storage 206) containing time value information, e.g., default, historical, and/or acceptable values (or ranges of values) for various time related parameters.
• time value information e.g., default, historical, and/or acceptable values (or ranges of values) for various time related parameters.
• TVDM 204 may use stored time value information along with relevant rules to determine appropriate time related parameter values. For example, TVDM 204 may determine, using recently obtained network information and/or NF information, that a network element or NF is experiencing congestion, and may select a relevant rule for this scenario.
• the relevant rule may indicate that a default value or a prior used value associated with a particular time related parameter value (e.g., located in a time value information data store) is to be increased by 100%, e.g., an FITTP header retry timer is increased to 60 seconds from 30 seconds.
• Node 200 and/or TVDM 204 may access (e.g., read from and/or write information to) data storage 206.
• Data storage 206 may be any suitable entity (e.g., a computer readable medium or memory) for storing various data.
• data storage 206 may include network information, NF metrics, time value determination rules, default values, and/or related information used in dynamically determining or deriving time related parameter values.
• data storage 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.
• data storage 206 may include logic or rules for detecting or determining one or more scenarios (e.g., network use cases) for adjusting a time related parameter value. In some embodiments, data storage 206 may include logic or rules for determining a time related parameter value based on detected or determined scenarios.
• scenarios e.g., network use cases
• data storage 206 may include logic or rules for determining a time related parameter value based on detected or determined scenarios.
• node 200 may include additional and/or different modules, components, or functionality.
• FIG. 3 is a message flow diagram illustrating an example NRF 100 comprising functionality (e.g., TVDM 204) for dynamically determining time related parameter values using network information and/or NF information.
• NRF 100 or TVDM 204 therein may utilize recent or current network information (e.g., analytics information from 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 a default or prior value.
• NWDAF 2 analytics information from NWDAF 2
• NF information e.g., NF related metrics from NF data provider(s) 212
• NRF 100 or TVDM 204 therein can dynamically determine time related parameter values (e.g., an NF heartbeat interval value) depending on a routing scenario associated with a requesting entity or current network conditions learned from data obtained from one or more data sources.
• NF metrics or other NF related information may be sent from NF data provider(s) 212 to NRF 100 or a related entity (e.g., data storage 206).
• NF data provider(s) 212 may provide message processing time metrics associated with multiple NFs, e.g., NF1 207, NF2 208 and NF3 209.
• network information may be sent from NWDAF 210 to NRF 100 or a related entity (e.g., data storage 206).
• NRF 100 or TVDM 204 may subscribe to various events via an Nnwdaf_EventsSubscription service provided by NWDAF 210 and may receive notifications (along with network information) when subscribed events occur.
• NRF 100 or TVDM 204 may request analytics information at periodic or aperiodic intervals using an Nnwdaf_Analyticslnfo service provided by NWDAF 210
• an NF registration related request message (e.g., an NFRegister or NFUpdate message) may be sent to NRF 100 from NF1 207.
• an NFRegister message may originate from NF1 207 and may traverse SEPPs 126 before reaching NRF 100.
• 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 an NF heartbeat interval (e.g., a 3GPP heart-beat timer value), associated with the NF registration related request message.
• an NF heartbeat interval e.g., a 3GPP heart-beat timer value
• an NF heartbeat interval may represent a parameter or setting indicating an amount of time (e.g., in seconds) expected between two consecutive heart-beat messages, e.g., from an NF instance (e.g., NF1 207) to NRF 100.
• an NF heartbeat interval may be determined and provided during an NF registration or an NF update procedure using a “heart-beat timer” parameter. For example, a proposed value for an NF heart-beat timer parameter may be provided in an NFRegister request message by NF1 207 to NRF 100.
• NRF 100 may confirm the value in an NFRegister response message. If the proposed heart-beat 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 a different time related parameter value (e.g., by adjusting a default value in response to network and/or NF conditions) and provide the different time related parameter value in an NFRegister response message to NF1 207. In step 304, an NF registration related response message indicating one or more time related parameters may be sent from NRF 100 to NF1 207.
• a different time related parameter value e.g., by adjusting a default value in response to network and/or NF conditions
• a response to an NFRegister message associated with NF1 207 may indicate a 3GPP heart-beat timer value that is based on learned information or factors associated with NF1 207.
• the 3GPP heart-beat timer value associated with NF1 207 may be different from a 3GPP heart-beat timer value associated with a different NF (e.g., NF2 208) or a standard or default value.
• an NF subscription request message (e.g., an NFStatusSubscribe message) may be sent to NRF 100 from NF1 207.
• NRF 100 or TVDM 204 may analyze characteristics of a received NFStatusSubscribe message along with learned network information and/or NF information and determine that the NF being subscribed to is overloaded or congested and may dynamically determine one or more time related parameters, such as an NF subscription validity time value, associated with the NF subscription request message.
• an NF subscription validity time may represent a parameter or setting indicating an amount of time (e.g., in hours) that a related subscription is active, e.g., after which the subscription may be deemed inactive and/or deleted at NRF 100.
• an NF subscription validity time may be determined and provided during an NF subscription procedure using a “validity time” parameter. For example, a proposed value for a subscription validity time parameter may be provided in an NFStatusSubscribe request (e.g., subscription creation request) message by NF1 207 to NRF 100.
• NRF 100 may confirm the value in an NFStatusSubscribe response message. If the proposed 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 a different time related parameter value (e.g., by adjusting a default value in response to network and/or NF conditions) and provide the different time related parameter value in an NFStatusSubscribe response message to NF1 207. In step 306, an NF subscription response message indicating one or more time related parameters may be sent from NRF 100 to NF1 207.
• a different time related parameter value e.g., by adjusting a default value in response to network and/or NF conditions
• a response to an 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.
• the NF subscription validity time value associated with NF1 207 may be different from an NF subscription validity time value associated with a different NF (e.g., NF2 208) or a standard or default value.
• an NF discovery request message (e.g., an NFDiscover message) may be sent to NRF 100 from NF1 207.
• NRF 100 or TVDM 204 may analyze characteristics of a received NFDiscover message along with learned network information and/or NF information and determine that the NF being discovered is overloaded or congested and may dynamically determine one or more time related parameters, such as an NF discover validity time value, associated with the NF discovery request message.
• an NF discovery validity time may represent a parameter or setting indicating an amount of time (e.g., in hours) that search results from a discovery or search is valid, e.g., after which the search results may be deemed invalid and/or deleted from a cache at an NF service consumer, e.g., NF1 207.
• an NF discovery validity time may be determined and provided during an NF discovery procedure using a “validity time” parameter. For example, a proposed value for a discovery validity time parameter may be provided in an NFDiscover request message by NF1 207 to NRF 100.
• NRF 100 may confirm the value in an NFDiscover response message. If the proposed 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 a different time related parameter value (e.g., by adjusting a default value in response to network and/or NF conditions) and provide the different time related parameter value in an NFDiscover response message to NF1 207. In step 308, an NF discovery response message indicating one or more time related parameters may be sent from NRF 100 to NF1 207.
• a different time related parameter value e.g., by adjusting a default value in response to network and/or NF conditions
• a response to an NFDiscover message associated with NF1 207 may indicate an NF discovery validity time value that is based on learned information or factors associated with NF1 207.
• the NF discovery validity time value associated with NF1 207 may be different from an NF discovery validity time value associated with a different NF (e.g., NF2 208) or a standard or default value.
• an NF access token request message (e.g., an NFAccessToken request message) may be sent to NRF 100 from NF1 207.
• NRF 100 or TVDM 204 may analyze characteristics of a received NFAccessToken request message along with learned network information and/or NF information and determine that the 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 expiry time value, associated with the NF access token request message.
• an NF access token expiry 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 deemed invalid.
• an NF access token expiry time may be determined and provided during an NF access token request procedure using a “expiration time” parameter. For example, an NFAccessToken request message may be sent from NF1 207 to NRF 100.
• NRF 100 and/or TVDM 204 therein may determine an expiration time related parameter value (e.g., by adjusting a default value in response to network and/or NF conditions) and provide the time related parameter value in an NFAccessToken response message to NF1 207.
• an expiration time related parameter value e.g., by adjusting a default value in response to network and/or NF conditions
• an NF subscription response message indicating one or more time related parameters may be sent from NRF 100 to NF1 207.
• a response to an NFAccessToken request message associated with NF1 207 may indicate an NF access token expiry time value that is based on learned information or factors associated with NF1 207.
• the access token expiry time value associated with NF1 207 may be different from an access token expiry time value associated with a different NF (e.g., NF2 208) or a standard or default value.
• Figure 3 is for illustrative purposes and that different and/or additional messages and/or actions may be used. It will also be appreciated that various messages and/or actions described herein may occur in a different order or sequence.
• Figure 4 is a diagram illustrating example rule data 400 indicating rule IDs and related time related parameter value determination rules for determining time related parameter values for one or more time related parameters (e.g., based on network conditions, NF performance metrics, and/or other factors).
• rule data 400 may indicate mappings (e.g., associations) between a rule ID and a related time related parameter value determination rule.
• a rule mapping or association may be statically configured by an operator or may be dynamically generated by NRF 100, e.g., using historical data and user-provided preferences.
• NRF 100 may receive a set of rules for different scenarios from a network operator and expected performance information for NRF 100.
• NRF 100 may dynamically adjust the rule (e.g., increase time related parameter value by 15%) in an attempt to achieve the expected result.
• node 200, NRF 100, or TVDM 204 may be configured for selecting time related parameter value determination rules and/or logic based on characteristics or scenarios associated with a received message or a related entity, e.g., an NF service consumer or an NF service producer.
• NRF 100 may analyze a received message to determine whether the message has originated or been forwarded from a different PLMN (e.g., by a visitor NRF 100 or NF1 207).
• NRF 100 may determine using various data (e.g., periodically fetched network information and/or NF information) whether itself or another network entity (e.g., the requesting entity) is experience a congestion event or other issue that may effect processing or communications.
• NRF 100 may select a relevant time related parameter value determination rule, wherein the time related parameter value determination rule may indicate a formula or logic for determining an appropriate value for a particular time related parameter.
• a time related parameter value determination rule ‘ID4’ may be selected that double or triples a predetermined default value for a particular short term parameter (e.g., NF heartbeat interval or FITTP header retry timer).
• a time related parameter value determination rule ‘IDT may be selected that increasing a predetermined or proposed default value by 25% or increasing a predetermined default value such that the new time related parameter value is greater than a derived or estimated one-way delay or other metric.
• a table representing rule data 400 comprises columns and/or fields for rule IDs and corresponding time related parameter value determination rules.
• a rule ID field may store information for representing an identifier that identifies a time related parameter value determination rules.
• each rule ID may be globally unique inside a PLMN, e.g., a unique number or alphanumeric value.
• rule IDs may be hierarchical or provide insights into related rules.
• rule IDs may be non-hierarchical or opaque regarding insights into related rules.
• a time related parameter value determination rule field may represent one or more rules or logic for determining a time related parameter value for one or more time related parameters.
• a rule may be based on a network or NF scenario and/or discernible characteristics associated with a received message, a requesting entity, or a related service.
• Example scenario-based rules may include one or more time related parameter value determination rules for an NRF to NRF forwarding scenario, a geo-redundant scenario, an NF congestion rule, and an NRF congestion scenario.
• node 200, NRF 100, or TVDM 204 may be configured for determining that a received message or related entity is associated with an NRF to NRF forwarding scenario and, using one or more related rules, may adjust one or more time related parameters according to various information, e.g., obtained via NWDAF 210 and/or NF data provider(s) 212.
• 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 for a relevant producer NF associated with a received message and, as such, may involve various messages traversing PLMN boundaries and localities.
• node 200, NRF 100, or TVDM 204 may determine an appropriate value for one or more time related parameters (e.g., an NF subscription validity time, an NF discovery validity time, or an NF access token expiry time), e.g., for reducing traffic crossing PLMN boundaries and different localities and/or for allowing additional time for expected or possible packet delays.
• time related parameters e.g., an NF subscription validity time, an NF discovery validity time, or an NF access token expiry time
• node 200, NRF 100, or TVDM 204 may be configured for determining that a received message or related entity is associated with a geo-redundant scenario and, using one or more related rules, may adjust one or more time related parameters according to various information, e.g., obtained via NWDAF 210 and/or NF data provider(s) 212.
• node 200, NRF 100, or TVDM 204 may determine that a received message is associated with a geo-redundant scenario when the received message or a related message traverses one or more geo-redundant sites and, as such, may involve various messages being handled from NFs of a mate or peer NRF 100.
• node 200, NRF 100, or TVDM 204 may determine an appropriate value for one or more time related parameters (e.g., an NF heartbeat interval, an NF subscription validity time, an NF discovery validity time, or an NF access token expiry time), e.g., for reducing traffic crossing geo-redundant sites and/or for allowing additional time for expected or possible packet delays.
• time related parameters e.g., an NF heartbeat interval, an NF subscription validity time, an NF discovery validity time, or an NF access token expiry time
• node 200, NRF 100, or TVDM 204 may be configured for determining that NRF 100 is experiencing an operational issue (e.g., overloaded, handling peak traffic, under maintenance, etc.) based on obtained network information and/or NF information and, using one or more related rules, may adjust one or more time related parameters according to such issue.
• an operational issue e.g., overloaded, handling peak traffic, under maintenance, etc.
• node 200, NRF 100, or TVDM 204 may determine that an NRF 100 is experiencing congestion or is under maintenance based on various information (e.g., via a subscribed event notification from NWDAF 210).
• node 200, NRF 100, or TVDM 204 may determine an appropriate value for one or more time related parameters (e.g., an NF heartbeat interval, an FITTP header retry timer, an NF subscription validity time, an NF discovery validity time, or an NF access token expiry time), e.g., for reducing traffic handled by NRF 100 and/or for allowing additional time for expected or probable packet delays.
• time related parameters e.g., an NF heartbeat interval, an FITTP header retry timer, an NF subscription validity time, an NF discovery validity time, or an NF access token expiry time
• node 200, NRF 100, or TVDM 204 may be configured for determining that an NF (e.g., a requested or appropriate producer NF for handling a particular service request) is experiencing an operational issue (e.g., overloaded, handling peak traffic, under maintenance, etc.) based on obtained network information and/or NF information and, using one or more related rules, may adjust one or more time related parameters according to such issue.
• an NF e.g., a requested or appropriate producer NF for handling a particular service request
• an operational issue e.g., overloaded, handling peak traffic, under maintenance, etc.
• node 200, NRF 100, or TVDM 204 may determine that a producer NF is experiencing congestion or is under maintenance based on various information (e.g., an nf- name_message_processing_time metric or related data from NF data provider(s) 212).
• node 200, NRF 100, or TVDM 204 may determine an appropriate value for one or more time related parameters (e.g., an NF heartbeat interval, an HTTP header retry timer, an NF subscription validity time, an NF discovery validity time, or an NF access token expiry time), e.g., for reducing less important traffic and/or for allowing additional time for expected or possible packet delays.
• time related parameters e.g., an NF heartbeat interval
• an HTTP header retry timer e.g., an NF subscription validity time, an NF discovery validity time, or an NF access token expiry time
• an overloaded NF may reduce its heartbeat related traffic towards NRF 100 and instead use its resources for processing requests during overload conditions.
• node 200, NRF 100, orTVDM 204 may use one or more determined time related parameter values for subsequent requests or operations. For example, after an NRF 100 is determined to be congested, an NF heartbeat interval (e.g., a heart-beat timer value) used by NFs may be increased from 30 seconds to 90 seconds and the NFs can be informed of the new value in response to subsequent 3GPP operations, e.g., NF registrations and NF updates. In this example, after an NRF 100 is determined to be no longer be congested, the NF heartbeat interval used by NFs may be decreased back to 30 seconds and the NFs may be informed of the new value in response to subsequent 3GPP operations.
• an NF heartbeat interval e.g., a heart-beat timer value
• rule data 400 is for illustrative purposes and that different and/or additional data than the data depicted in Figure 4 may be usable for determining time related parameter values.
• rule data 400 may include various scenarios not depicted, including combination scenarios, such as NRF and NF congestion.
• rule data 400 may include priority values for indicating which rule(s) are to be selected or used.
• rule data 400 may include one or more rules for different time related parameters for the same scenario.
• rule data 400 may be stored (e.g., in data storage 206 using various data structures and/or computer readable media.
• Figure 5 is a diagram illustrating example default value information 500 for various time related parameters in a communications network.
• default value information 500 may indicate values associated with various time related parameters.
• NRF 100 may utilize default value information 500 for selecting time related parameters regardless of situation or scenario before adjustment based on network information, NF metrics or other information.
• default values may be predetermined, e.g., by a network operator or a time related parameter value determination rule (e.g., in rule data 400).
• time related parameter values may be determined by adjusting (e.g., increasing or decreasing) default values in response to or based on at least part of current network information and/or NF information, e.g., information indicating network congestion, NRF maintenance, inter-PLMN communications, high NF load, etc.
• NF information e.g., information indicating network congestion, NRF maintenance, inter-PLMN communications, high NF load, etc.
• node 200, NRF 100, or TVDM 204 may be configured for identifying characteristics of a received message (e.g., determining that a received message is an inter-PLMN message or that a received message is forwarded from a visitor PLMN) and using those characteristics along with current (or recent) network conditions and/or NF metrics to dynamically determining values for time related parameters and may determine, using default value information 500, a default or initial time related parameter value for a particular time related parameter and may use a relevant rule (e.g., from rule data 400) to determine an appropriate time related parameter value for a requesting NF or related service, e.g., by increasing or decreasing the initial time related parameter value.
• a relevant rule e.g., from rule data 400
• node 200 or TVDM 204 may determine that NRF or a related network portion is experiencing congestion and may determine that increasing an initial or default value for an NF heart-beat timer or interval value from 30 seconds to 60 seconds would improve congestion and/or related issues significantly.
• adjustment from 30 seconds to 60 seconds may be based on a formula or a percentage amount.
• time adjustments may be based on historical data, e.g., prior congestion events and/or related connectivity or heartbeat issues during those events.
• a table representing default value information 500 comprises columns and/or fields for time related parameters and corresponding default values.
• default values may be predetermined, e.g., by a network operator or a time related parameter value determination rule (e.g., in rule data 400).
• a time related parameter field may store information for representing a time related parameter (e.g., 3GPP network parameters) indicating or representing or indicating a time amount or a period of time.
• Example time related parameters depicted in Figure 5 include an NF heartbeat interval (e.g., a 3GPP “heart-beat timer”), an NF subscription validity time, an NF discovery validity time, an NF access token expiry time, or an FITTP header retry timer (e.g., a value in a "Retry-After" HTTP header parameter field).
• an NF heartbeat interval e.g., a 3GPP “heart-beat timer”
• an NF subscription validity time e.g., an NF discovery validity time
• an NF access token expiry time e.g., a value in a "Retry-After" HTTP header parameter field.
• FITTP header retry timer e.g., a value in a "Retry-After" HTTP header parameter field
• a default value field may indicate a default value (e.g., an initial value) associated with a particular time related parameter.
• default values may be in seconds, minutes, hours, or days and/or may be based on a percentage or a formula that utilizes a proposed time from an NF and/or other data (e.g., a default value for heartbeat interval parameter may 10% less than a proposed time but not to exceed 70 seconds).
• a default value for an NF heartbeat interval parameter may be 30 seconds; a default value for an NF subscription validity time parameter may be 6 hours; a default value for an NF discovery validity time parameter may be 1 hours; a default value for an NF access token expiry time parameter may be 1 hour; and a default value for an HTTP header retry timer parameter may be 30 seconds.
• an HTTP header retry timer may represent a parameter or setting indicating an amount of time (e.g., in seconds) that an NF waits to retry a service operation at NRF 100.
• an HTTP header retry timer may be determined when NRF 100 is to send an HTTP 503 error message indicating a service is unavailable and may be provided to an NF service consumer (e.g., NF1 207) in an “Retry-After" HTTP header field.
• NRF 100 may reject some HTTP requests by sending an HTTP 503 message including an HTTP header field "Retry-After" for indicating an estimated time (in number of seconds) for the recovery of the service.
• NRF 100 and/or TVDM 204 therein may determine the HTTP retry timer value (e.g., by adjusting a default value in response to network and/or NF conditions).
• default value information 500 are for illustrative purposes and that different and/or additional data than the data depicted in Figure 5 may be usable for indicating default values for various time related parameters. Further, default value information 500 may be stored (e.g., in data storage 206) using various data structures and/or computer readable media.
• Figure 6 is a diagram illustrating an example process 600 for determining time related parameter values a communications network. In some embodiments, example process 600 described herein, or portions thereof, may be performed at or performed by a network node, e.g., NRF 100, node 200, TVDM 204, and/or another module, NF, or node.
• a network node e.g., NRF 100, node 200, TVDM 204, and/or another module, NF, or node.
• a service request message may be received from a first NF.
• a 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.
• a time related parameter value may indicate an NF heartbeat interval (e.g., a 3GPP heart-beat timer), an NF subscription validity time, an NF discovery validity time, an NF access token expiry time, or an FITTP header retry timer (e.g., a value in a "Retry-After" HTTP header parameter field).
• NF heartbeat interval e.g., a 3GPP heart-beat timer
• an NF subscription validity time e.g., an NF discovery validity time
• an NF access token expiry time e.g., a value in a "Retry-After" HTTP header parameter field.
• At least some network information or NF information may be obtained periodically or aperiodically (e.g., dynamically) from one or more data sources, e.g., local data store (e.g., relative to NRF 100), a remote data source (e.g., relative to NRF 100), NWDAF 210, or NF data provider(s) 212.
• data sources e.g., local data store (e.g., relative to NRF 100), a remote data source (e.g., relative to NRF 100), NWDAF 210, or NF data provider(s) 212.
• At least some network information may be obtained using an Nnwdaf_EventsSubscription service or an Nnwdaf_Analyticslnfo service. For example, every 60 seconds or so, NRF 100 or another entity may send one or more Nnwdaf_Analyticslnfo service request messages to NWDAF 210 for obtaining load level information for one or more network slice instances associated with a 5G communications network.
• NRF 100 or another entity may send an Nnwdaf_EventsSubscription service request message to subscribe to and receive an network slice specific congestion events notification from NWDAF 210
• determining a time related parameter value may include determining that an NRF, a first NF, or a network entity may be experiencing a congestion status change, a change in workload amount, or an operational status change; and in response adjusting the time related parameter value from a default value or a prior value.
• a default value or a prior value may be predetermined by a network operator or generated using a predetermined policy or rule.
• determining a time related parameter value may include determining that a service request message or a related message requires NRF to NRF forwarding; and in response increasing the time related parameter value from an initial or default value.
• determining a time related parameter value may include determining that a service request message or a related message may be an inter public land mobile network (PLMN) message; and in response increasing the time related parameter value from an initial or default value.
• PLMN public land mobile network
• a service response message indicating the time related parameter value may be generated and sent to the first NF.
• a service response message may include an NF registration response message, an NF update response message, an NF status subscription response message, an NF discovery response message, or an NF access token response message.
• process 600 is for illustrative purposes and that different and/or additional actions may be used. It will also be appreciated that various actions described herein may occur in a different order or sequence.
• any network that can 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.
• node 200, TVDM 204, and/or functionality described herein may constitute a special purpose computing device. Further, node 200, TVDM 204, and/or functionality described herein can improve the technological field of network communications. For example, by determining time related parameter values using current network information and/or NF information, communications between NFs or other entities can be improved and timing issues can be reduced. In this example, by utilizing one or more techniques and/or methods described herein, NRF 100 or TVDM 204 therein can determine time related parameter values based on network conditions, NF related metrics, and/or other factors.
• nudm-sdm nudm-uecm
• npcf-uepolicy nsmf-pdusession
• nssf-nsselection nnrf-disc
• nnrf-nfm 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.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computer Security & Cryptography (AREA)
• Computer Hardware Design (AREA)
• Computing Systems (AREA)
• General Engineering & Computer Science (AREA)
• Environmental & Geological Engineering (AREA)
• Mobile Radio Communication Systems (AREA)

Priority Applications (3)

Applications Claiming Priority (2)

Publications (1)

Family

ID=82399320

Family Applications (1)

Country Status (5)

Families Citing this family (11)

Citations (4)

Family Cites Families (51)

• 2021
  • 2021-05-26 US US17/331,620 patent/US12028800B2/en active Active
• 2022
  • 2022-05-25 JP JP2023572848A patent/JP2024520440A/ja active Pending
  • 2022-05-25 EP EP22737680.3A patent/EP4348965A1/en active Pending
  • 2022-05-25 WO PCT/US2022/030887 patent/WO2022251334A1/en not_active Ceased
  • 2022-05-25 CN CN202280037810.7A patent/CN117441326A/zh active Pending

Patent Citations (4)

Non-Patent Citations (4)

Also Published As

Similar Documents

Legal Events