FORM 2
THE PATENTS ACT, 1970 (39 OF
1970)
&
THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See section 10 and rule 13)
“METHOD AND SYSTEM FOR NOTIFICATION RETRY MANAGEMENT IN A
NETWORK”
We, Jio Platforms Limited, an Indian National, of Office - 101, Saffron, Nr. Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad - 380006, Gujarat, India.
The following specification particularly describes the invention and the manner in which it is to be performed.

METHOD AND SYSTEM FOR NOTIFICATION RETRY MANAGEMENT IN A
NETWORK
TECHNICAL FIELD
[0001] Embodiments of the present disclosure generally relate to a notification retry management system. More particularly, embodiments of the present disclosure relate to methods and systems for notification retry management in a network.
BACKGROUND
[0002] The following description of the related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section is used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of the prior art.
[0003] Wireless communication technology has rapidly evolved over the past few decades, with each generation bringing significant improvements and advancements. The first generation of wireless communication technology was based on analog technology and offered only voice services. However, with the advent of the second generation (2G) technology, digital communication and data services became possible, and text messaging was introduced. The third generation (3G) technology marked the introduction of high-speed internet access, mobile video calling, and location-based services. The fourth generation (4G) technology revolutionized wireless communication with faster data speeds, better network coverage, and improved security. Currently, the fifth generation (5G) technology is being deployed, promising even faster data speeds, low latency, and the ability to connect multiple devices simultaneously. With each generation, wireless communication technology has become more advanced, sophisticated, and capable of delivering more services to its users.
[0004] A Network Function (NF) is a fundamental element in a telecommunication network that provides a service or set of services, such as a Session Management Function (SMF). Further, the NF may subscribe to one or more notifications from a Network Resource Function (NRF) based on one or more conditions. The NRF is a network function that acts as a central

repository for information about available network functions and services. It facilitates the discovery and dynamic registration of network functions. The one or more conditions refer to one or more changes, one or more additions, or one or more removals of the NFs within a network. The NRF triggers a notification service operation towards the NF upon detection of the one or more conditions.
[0005] However, there are situations where the notification service is timed out or refused by the NF. In such conditions, an affected NF does not receive timely updates about one or more changes in the network conditions. Currently, there is no solution that addresses the issue when the notification service is timed out or refused by the NF, which leads to situations where the NF does not receive one or more notifications related to one or more changes in the conditions of the network in a timely manner. Due to this delay, an issue of service outages arises for the affected NF, which ultimately impacts overall network performance and reliability.
[0006] Further, when the notification service is timed out or refused by the NF, the NF does not receive an update regarding the one or more changes in the network, which may degrade the performance of one or more services that are reliant on real-time status. In addition to this, an inability of the NRF to ensure a successful delivery of the notification may lead to a service outage and cause an interruption in the service for one or more end users.
[0007] Hence, there is a need for methods and systems for notification retry management in a network.
SUMMARY
[0008] This section is provided to introduce certain aspects of the present disclosure in a simplified form that are further described below in the detailed description. This summary is not intended to identify the key features or the scope of the claimed subject matter.
[0009] An aspect of the present disclosure may relate to a method for notification retry management in a network. The method comprises transmitting, by a transceiver unit, from a Network Repository Function (NRF) to a target Network Function (NF) in the network, a first status message to notify a status change associated with the target NF. The method further comprises determining, by an analysis unit at the NRF in the network, at least one of a timeout

scenario and a response status within a preconfigured response time associated with the first status message, wherein the response status is at least one of a negative response and a positive response. The method further comprises identifying, by the analysis unit at the NRF, a predefined retry policy associated with at least one of the timeout scenario and the response status. Thereafter, the method comprises automatically initiating, by a processing unit from the NRF to the target NF, a second status message to notify the status change associated with the target NF based on the predefined retry policy.
[0010] In an exemplary aspect of the present disclosure, the automatically initiating the second status message is further based on determining, by the analysis unit at the NRF, a response code associated with the response status.
[0011] In an exemplary aspect of the present disclosure, the predefined retry policy comprises one or more predefined retry conditions associated with the response code and a current message retry count value associated with the first status message, and wherein the one or more predefined retry conditions is at least one of a message retry count threshold and a message retry timer.
[0012] In an exemplary aspect of the present disclosure, the timeout scenario is determined at the NRF in an event no response is detected at the NRF from the target NF associated with the first status message within the preconfigured response time.
[0013] In an exemplary aspect of the present disclosure, the negative response is determined at the NRF in an event an error response code associated with the first status message is detected at the NRF, from the target NF, within the preconfigured response time, wherein the error response code is determined based on a comparison of the response code with a list of pre-defined response codes.
[0014] In an exemplary aspect of the present disclosure, the positive response is determined at the NRF in an event a success response code associated with the first status message is detected at the NRF, from the target NF, within the preconfigured response time, wherein the success response code is determined based on a comparison of the response code with a list of pre¬defined response codes.

[0015] In an exemplary aspect of the present disclosure, the second status message is automatically initiated from the NRF in an event the NRF detects the error response code associated with the first status message, a positive threshold status associated with the current message retry count value, and a message retry timer status associated with the message retry timer.
[0016] In an exemplary aspect of the present disclosure, the positive threshold status associated with the current message retry count value is detected at the NRF in an event a number of the second status message automatically initiated by the NRF, to the target NF, is less than a predefined number of the second status message initiated by the NRF to the target NF.
[0017] In an exemplary aspect of the present disclosure, the message retry timer status, associated with the message retry timer, is a predefined minimum time duration between the first status message transmitted from the NRF to the target NF, and the second status message automatically initiated from the NRF to the target NF.
[0018] Another aspect of the present disclosure may relate to a system for notification retry management in a network. The system comprises a transceiver unit configured to transmit from a Network Repository Function (NRF) to a target Network Function (NF) in the network, a first status message to notify a status change associated with the target NF. The system further comprises an analysis unit connected to at least the transceiver unit. The analysis unit is configured to determine, at the NRF in the network, at least one of a timeout scenario and a response status within a preconfigured response time associated with the first status message, wherein the response status is at least one of a negative response and a positive response. The analysis unit is further configured to identify, at the NRF, a predefined retry policy associated with at least one of the timeout scenario and the response status. The system further comprises a processing unit connected to at least the analysis unit, wherein the processing unit is configured to automatically initiate, from the NRF to the target NF, a second status message to notify the status change associated with the target NF based on the predefined retry policy.
[0019] Yet another aspect of the present disclosure may relate to a non-transitory computer readable storage medium storing one or more instructions for notification retry management in a network, wherein the instructions include executable code which, when executed by a one or more units of a system, causes a transceiver unit of the system to transmit from a Network

Repository Function (NRF) to a target Network Function (NF) in the network, a first status message to notify a status change associated with the target NF. The instructions further executed by the one or more units of the system, causes an analysis unit of the system to determine, at the NRF in the network, at least one of a timeout scenario and a response status within a preconfigured response time associated with the first status message, wherein the response status is at least one of a negative response and a positive response. The instructions further executed by the one or more units of the system, causes the analysis unit to identify, at the NRF, a predefined retry policy associated with at least one of the timeout scenario and the response status. The instructions further executed by the one or more units of the system, causes a processing unit to automatically initiate, from the NRF to the target NF, a second status message to notify the status change associated with the target NF based on the predefined retry policy.
OBJECTS OF THE INVENTION
[0020] Some of the objects of the present disclosure, which at least one embodiment disclosed herein satisfies are listed herein below.
[0021] It is an object of the present disclosure to provide a method and system for notification retry management in a network.
[0022] Another object of the present disclosure is to provide a solution wherein the Network Resource Function (NRF) re-sends a message in case of time out or when a specific error code is received from a Service Communication Proxy (SCP) or Network Function (NF).
[0023] Another objective of the present disclosure is to maintain a certain delta time period between each re-sending of the message to ensure that the NF has sufficient time for recovery before the next retry.
[0024] Yet another objective of the present disclosure is to ensure that the NRF does not cause an overload of multiple retry messages in a network.

BRIEF DESCRIPTION OF THE DRAWINGS
[0025] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Also, the embodiments shown in the figures are not to be construed as limiting the disclosure, but the possible variants of the method and system according to the disclosure are illustrated herein to highlight the advantages of the disclosure. It will be appreciated by those skilled in the art that disclosure of such drawings includes disclosure of electrical components or circuitry commonly used to implement such components.
[0026] FIG. 1 illustrates an exemplary block diagram representation of 5th generation core (5GC) network architecture.
[0027] FIG. 2 illustrates an exemplary block diagram of a computing device upon which the features of the present disclosure may be implemented in accordance with exemplary implementation of the present disclosure.
[0028] FIG. 3 illustrates an exemplary block diagram of a system for notification retry management in a network, in accordance with exemplary implementations of the present disclosure.
[0029] FIG. 4 illustrates an exemplary flow diagram of a method for notification retry management in a network, in accordance with exemplary implementations of the present disclosure.
[0030] FIG. 5 illustrates an exemplary method flow diagram for notification retry management in a network in accordance with exemplary implementations of the present disclosure.
[0031] The foregoing shall be more apparent from the following more detailed description of the disclosure.

DETAILED DESCRIPTION
[0032] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter may each be used independently of one another or with any combination of other features. An individual feature may not address any of the problems discussed above or might address only some of the problems discussed above.
[0033] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.
[0034] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail.
[0035] Also, it is noted that individual embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations may be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure.
[0036] The word “exemplary” and/or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and/or “demonstrative” is not necessarily to be construed as preferred or

advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive—in a manner similar to the term “comprising” as an open transition word—without precluding any additional or other elements.
[0037] As used herein, a “processing unit” or “processor” or “operating processor” includes one or more processors, wherein processor refers to any logic circuitry for processing instructions. A processor may be a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor, a plurality of microprocessors, one or more microprocessors in association with a (Digital Signal Processing) DSP core, a controller, a microcontroller, Application Specific Integrated Circuits, Field Programmable Gate Array circuits, any other type of integrated circuits, etc. The processor may perform signal coding data processing, input/output processing, and/or any other functionality that enables the working of the system according to the present disclosure. More specifically, the processor or processing unit is a hardware processor.
[0038] As used herein, “a user equipment”, “a user device”, “a smart-user-device”, “a smart-device”, “an electronic device”, “a mobile device”, “a handheld device”, “a wireless communication device”, “a mobile communication device”, “a communication device” may be any electrical, electronic and/or computing device or equipment, capable of implementing the features of the present disclosure. The user equipment/device may include, but is not limited to, a mobile phone, smart phone, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, wearable device or any other computing device which is capable of implementing the features of the present disclosure. Also, the user device may contain at least one input means configured to receive an input from at least one of a transceiver unit, a processing unit, a storage unit, a detection unit and any other such unit(s) which are required to implement the features of the present disclosure.
[0039] As used herein, “storage unit” or “memory unit” refers to a machine or computer-readable medium including any mechanism for storing information in a form readable by a computer or similar machine. For example, a computer-readable medium includes read-only memory (“ROM”), random access memory (“RAM”), magnetic disk storage media, optical

storage media, flash memory devices or other types of machine-accessible storage media. The storage unit stores at least the data that may be required by one or more units of the system to perform their respective functions.
[0040] As used herein “interface” or “user interface refers to a shared boundary across which two or more separate components of a system exchange information or data. The interface may also be referred to a set of rules or protocols that define communication or interaction of one or more modules or one or more units with each other, which also includes the methods, functions, or procedures that may be called.
[0041] All modules, units, components used herein, unless explicitly excluded herein, may be software modules or hardware processors, the processors being a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASIC), Field Programmable Gate Array circuits (FPGA), any other type of integrated circuits, etc.
[0042] As used herein the transceiver unit includes at least one receiver and at least one transmitter configured respectively for receiving and transmitting data, signals, information or a combination thereof between units/components within the system and/or connected with the system.
[0043] As discussed in the background section, a Network Function (NF) plays a crucial role in providing a plurality of essential services, such as Session Management Functions (SMF). The NFs often subscribe to one or more notifications from Network Resource Functions (NRFs) based on specific conditions such as changes, additions, or removals within the network. Upon detecting these conditions, the NRF triggers one or more notification operations directed towards the NF. However, existing solutions do not adequately address scenarios where notification services are timed out or rejected by the NF. This failure results in delays at NFs while receiving notifications about one or more changes in network conditions in a timely manner. Such delays may lead to one or more issues, like service outages, for affected NFs; moreover, these issues significantly impact overall network performance and reliability. Additionally, when the notification services are timed out or rejected, NFs do not receive real¬time updates regarding network changes, which may degrade the performance of services

relying on up-to-date status information. Hence, the current known solutions have several shortcomings. The present disclosure aims to overcome the above-mentioned and other existing problems in this field of technology by providing a method and system for notification retry management in a network. The present disclosure provides a solution for notification retry management that involves the transmission of a status message to a target network function (NF) in the network to notify of a status change associated with the target NF. Thereafter, a timeout scenario along with a response status is determined with a preconfigured response time that is associated with the status message. Further, based on the response status and timeout scenario, a predefined retry policy is identified. Lastly, another status message is initiated automatically for notifying the status change that is associated with the target NF based on the predefined retry policy. Hence, the timeout scenario helps to ensure that a NF has sufficient time for recovery before the next retry and eliminates the chance of overloading a plurality of retry messages in a network.
[0044] FIG. 1 illustrates an exemplary block diagram representation of 5th generation core (5GC) network architecture, in accordance with exemplary implementation of the present disclosure. As shown in FIG. 1, the 5GC network architecture [100] includes a User Equipment (UE) [102], A Radio Access Network (RAN) [104], an Access And Mobility Management Function (AMF) [106], a Session Management Function (SMF) [108], a Service Communication Proxy (SCP) [110], an Authentication Server Function (AUSF) [112], a Network Slice Specific Authentication and Authorization Function (NSSAAF) [114], a Network Slice Selection Function (NSSF) [116], a Network Exposure Function (NEF) [118], a Network Repository Function (NRF) [120], a Policy Control Function (PCF) [122], a Unified Data Management (UDM) [124], An Application Function (AF) [126], a User Plane Function (UPF) [128], a data network (DN) [130], wherein all the components are assumed to be connected to each other in a manner as obvious to the person skilled in the art for implementing features of the present disclosure.
[0045] Radio Access Network (RAN) [104] is the part of a mobile telecommunications system that connects user equipment (UE) [102] to the core network (CN) and provides access to several types of networks (e.g., 5G network). It consists of radio base stations and the radio access technologies that enable wireless communication.

[0046] Access and Mobility Management Function (AMF) [106] is a 5G core network function responsible for managing access and mobility aspects, such as UE registration, connection, and reachability. It also handles mobility management procedures like handovers and paging.
[0047] Session Management Function (SMF) [108] is a 5G core network function responsible for managing session-related aspects, such as establishing, modifying, and releasing sessions. It coordinates with the User Plane Function (UPF) for data forwarding and handles IP address allocation and QoS enforcement.
[0048] Service Communication Proxy (SCP) [110] is a network function in the 5G core network that facilitates communication between other network functions by providing a secure and efficient messaging service. It acts as a mediator for service-based interfaces.
[0049] Authentication Server Function (AUSF) [112] is a network function in the 5G core responsible for authenticating UEs during registration and providing security services. It generates and verifies authentication vectors and tokens.
[0050] Network Slice Specific Authentication and Authorization Function (NSSAAF) [114] is a network function that provides authentication and authorization services specific to network slices. It ensures that UEs can access only the slices for which they are authorized.
[0051] Network Slice Selection Function (NSSF) [116] is a network function responsible for selecting the appropriate network slice for a UE based on factors such as subscription, requested services, and network policies.
[0052] Network Exposure Function (NEF) [118] is a network function that exposes capabilities and services of the 5G network to external applications, enabling integration with third-party services and applications.
[0053] Network Repository Function (NRF) [120] is a network function that acts as a central repository for information about available network functions and services. It facilitates the discovery and dynamic registration of network functions.

[0054] Policy Control Function (PCF) [122] is a network function responsible for policy control decisions, such as QoS, charging, and access control, based on subscriber information and network policies.
[0055] Unified Data Management (UDM) [124] is a network function that centralizes the management of subscriber data, including authentication, authorization, and subscription information.
[0056] Application Function (AF) [126] is a network function that represents external applications interfacing with the 5G core network to access network capabilities and services.
[0057] User Plane Function (UPF) [128] is a network function responsible for handling user data traffic, including packet routing, forwarding, and QoS enforcement.
[0058] Data Network (DN) [130] refers to a network that provides data services to user equipment (UE) in a telecommunications system. The data services may include but are not limited to Internet services, confidential data network related services.
[0059] FIG. 2 illustrates an exemplary block diagram of a computing device [200] upon which the features of the present disclosure may be implemented in accordance with exemplary implementation of the present disclosure. In an implementation, the computing device [200] may also implement a method for notification retry management in a network utilising the system. In another implementation, the computing device [200] itself implements the method for notification retry management in the network using one or more units configured within the computing device [200], wherein said one or more units are capable of implementing the features as disclosed in the present disclosure.
[0060] The computing device [200] may include a bus [202] or other communication mechanism for communicating information, and the processor [204] coupled with bus [202] for processing information. The processor [204] may be, for example, a general-purpose microprocessor. The computing device [200] may also include a main memory [206], such as a random-access memory (RAM), or other dynamic storage device, coupled to the bus [202] for storing information and instructions to be executed by the processor [204]. The main memory [206] also may be used for storing temporary variables or other intermediate

information during execution of the instructions to be executed by the processor [204]. Such instructions, when stored in non-transitory storage media accessible to the processor [204], render the computing device [200] into a special-purpose machine that is customized to perform the operations specified in the instructions. The computing device [200] further includes a read only memory (ROM) [208] or other static storage device coupled to the bus [202] for storing static information and instructions for the processor [204].
[0061] A storage device [210], such as a magnetic disk, optical disk, or solid-state drive is provided and coupled to the bus [202] for storing information and instructions. The computing device [200] may be coupled via the bus [202] to a display [212], such as a Cathode Ray Tube (CRT), Liquid Crystal Display (LCD), Light Emitting Diode (LED) display, Organic LED (OLED) display, etc. for displaying information to a computer user. An input device [214], including alphanumeric and other keys, touch screen input means, etc. may be coupled to the bus [202] for communicating information and command selections to the processor [204]. Another type of user input device may be a cursor controller [216], such as a mouse, a trackball, or cursor direction keys, for communicating direction information and command selections to the processor [204], and for controlling cursor movement on the display [212]. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allow the device to specify positions in a plane.
[0062] The computing device [200] may implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination with the computing device [200] causes or programs the computing device [200] to be a special-purpose machine. According to one implementation, the techniques herein are performed by the computing device [200] in response to the processor [204] executing one or more sequences of one or more instructions contained in the main memory [206]. Such instructions may be read into the main memory [206] from another storage medium, such as the storage device [210]. Execution of the sequences of instructions contained in the main memory [206] causes the processor [204] to perform the process steps described herein. In alternative implementations of the present disclosure, hard-wired circuitry may be used in place of or in combination with software instructions.
[0063] The computing device [200] also may include a communication interface [218] coupled to the bus [202]. The communication interface [218] provides a two-way data communication

coupling to a network link [220] that is connected to a local network [222] and the local network [222] is further connected to the host [224]. For example, the communication interface [218] may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, the communication interface [218] may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, the communication interface [218] sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing several types of information.
[0064] The computing device [200] can send messages and receive data, including program code, through the network(s), the network link [220] and the communication interface [218]. In the Internet example, a server [230] might transmit a requested code for an application program through the Internet [228], the ISP [226], the local network [222] and the communication interface [218]. The received code may be executed by the processor [204] as it is received, and/or stored in the storage device [210], or other non-volatile storage for later execution.
[0065] Referring to FIG. 3, an exemplary block diagram of a system [300] for notification retry management in a network, is shown, in accordance with the exemplary implementations of the present disclosure. The system [300] comprises at least one transceiver unit [302], at least one analysis unit [304], at least one processing unit [306], and at least one storage unit [308]. Also, all of the components/ units of the system [300] are assumed to be connected to each other unless otherwise indicated below. As shown in the figures all units shown within the system should also be assumed to be connected to each other. Also, in FIG. 3 only a few units are shown, however, the system [300] may comprise multiple such units or the system [300] may comprise any such numbers of said units, as required to implement the features of the present disclosure.
[0066] The system [300] is configured for notification retry management in the network, with the help of the interconnection between the components/units of the system [300].
[0067] Further, in accordance with the present disclosure, it is to be acknowledged that the functionality described for the various the components/units can be implemented

interchangeably. While specific embodiments may disclose a particular functionality of these units for clarity, it is recognized that various configurations and combinations thereof are within the scope of the disclosure. The functionality of specific units as disclosed in the disclosure should not be construed as limiting the scope of the present disclosure. Consequently, alternative arrangements and substitutions of units, provided they achieve the intended functionality described herein, are considered to be encompassed within the scope of the present disclosure.
[0068] In order to achieve notification, retry management in a network, the transceiver unit [302] is configured to transmit from a Network Repository Function (NRF) [120] to a target Network Function (NF) in the network, a first status message to notify a status change associated with the target NF.
[0069] The present disclosure encompasses that the status message refers to a message that is transmitted from the NRF [120] to the target NF within the network to notify about an existing status associated with the target NF, that is available at the NRF [120], wherein the target NF may be one of the one or more network functions associated with the network. The status message may include an identification data, a status change data, a timestamp data and an additional information.
[0070] The present disclosure encompasses that the status change may relate to an operational state change of the NF, a configuration change of the NF, a performance change of the NF, a service availability change of the NF and an event change of the NF.
[0071] As used herein “operational state change of the NF” may refer to alterations in the operational status or mode of the NF, such as, transition between starting, stopping, restarting, or switching between active and standby modes by the NT.
[0072] As used herein, “configuration change of the NF” refers to a modification associated with one or more parameters that govern an operation of the NF such as, a modification associated with adjustments to network interfaces, protocols, security policies, resource allocations, or any other configurable attributes.

[0073] As used herein, “performance change of the NF” signifies variations in an operational performance metric of the NF such as, alterations in a throughput, a latency, packet loss rates, a resource utilization such as CPU, memory, and/or key performance indicators (KPIs).
[0074] As used herein, “service availability change of the NF” refers to shifts in an ability of the NF to provide services as expected such as, changes in a service uptime, a service downtime, a service reliability, a service resilience, and fault tolerance mechanisms.
[0075] As used herein, “event change of the NF” refers to an event change that indicates an occurrence of significant events associated with the NF such as, an alarm event, event notifications, one or more triggers associated with an NF event, a state transitions that may impact operation of the NF, an event detection, an event notification, an event logging, and event appropriate response actions.
[0076] The analysis unit [304] is connected to at least the transceiver unit [302] and the analysis unit [304] is configured to determine, at the NRF [120] in the network, at least one of a timeout scenario and a response status within a preconfigured response time associated with the first status message. The response status is at least one of a negative response and a positive response.
[0077] Further, the timeout scenario is determined at the NRF [120] in an event no response is detected at the NRF [120] from the target NF associated with the first status message within the preconfigured response time.
[0078] The present disclosure encompasses that the analysis unit [304] may utilize one or more event determination techniques for determining the at least one of a timeout scenario and the response status within the preconfigured response time associated with the first status message. The one or more one or more event determination techniques may be a pre-defined technique, such as techniques pre-defined by an administrator that may be stored in the storage unit [308].
[0079] The present disclosure encompasses that the timeout scenario may refer to a situation where an expected response from the target NF does not arrive within a pre-defined timeframe (i.e., response time). For example, if the predefined timeframe is 100ms, in an event if the

response associated with the first status message is not received within the 100ms, in that event the analysis unit [304] may determine the timeout scenario associated with the first status message based on detecting no receipt of the response in predefined timeframe (i.e., a response time).
[0080] The present disclosure encompasses that the preconfigured response time may be pre-defined by the administrator in the storage unit [308].
[0081] In another example, when the NRF [120] transmits the first status message to the NF, then the NRF [120] waits for a response within the preconfigured response time such as, 20 minutes. Moreover, the analysis unit [304] waits for the response for 20 minutes, and if no response is received within the specified time (timeout scenario), the analysis unit [304] identifies this condition as a timeout scenario.
[0082] The present disclosure encompasses that upon receiving of the response within the preconfigured response time, an error response code is checked and further the error response code is compared with a list of pre-defined response code. The comparison of error response code with the list of pre-defined response code is made to determine whether the response is a negative response or a positive response.
[0083] The present disclosure encompasses that the negative response is determined at the NRF [120] in an event an error response code associated with the first status message is detected at the NRF [120] from the target NF within the preconfigured response time, wherein the error response code is determined based on a comparison of the response code with a list of pre-defined response codes.
[0084] The present disclosure encompasses that the error response code refers to a code which indicates an error or failure condition in response to the first status message. For instance, the error response code may include, but is not limited to, 400 Bad Request error code, 500 Internal Server Error code. Furthermore, in an implementation of the present solution, a set of response codes may be pre-defined as the negative response codes in the list pre-defined response codes associated with the target NF. For example, a response code A, a response code B, a response code D, and a response code Z are associated with a NF, M. In a scenario, the response code B is defined as an error code associated with the NF M, in the pre-defined response codes

associated with the NF M, and the response code A, the response code D, and the response
code Z are defined as a success code associated with the NF M, in the pre-defined response
codes associated with the NF M. Now, if a response received based on the first status message
comprises the response code B (i.e., the error code associated with the NF M in the pre-defined
5 response codes) then the received response is determined as the negative response at the NRF
[120].
[0085] The present disclosure encompasses that the list of pre-defined response codes may be pre-defined by the administrator and stored in the storage unit [308].
10
[0086] The present disclosure encompasses that the positive response is determined at the NRF [120] in an event where a success response code associated with the first status message is detected at the NRF [120], from the target NF, within the preconfigured response time such as 5 seconds, 10 seconds, 30 seconds, wherein the success response code is determined based on
15 a comparison of the response code with a list of pre-defined response codes.
[0087] Continuing from the above example, if the response received based on the first status
message comprises the response code A (i.e., the success code associated with the NF M in the
pre-defined response codes) then the received response is determined as the positive response
20 at the NRF [120].
[0088] Further, in a scenario the NRF [120] detects the negative response associated with the
first status message from the target NF within the preconfigured response time or if no response
is received within the preconfigured response time (i.e., the timeout scenario), then the
25 predefined retry policy associated with the detected negative response or the detected timeout
scenario is triggered at the NRF [120].
[0089] The present disclosure encompasses that the predefined retry policy comprises one or
more predefined retry conditions associated with the response code and a current message retry
30 count value associated with the first status message, and wherein the one or more predefined
retry conditions is at least one of a message retry count threshold and a message retry timer.
[0090] The present disclosure encompasses that the predefined retry policy refers to a predetermined set of rules or guidelines established within a configuration that help the network
19

to handle and manage a reinitiation of one or more status message transmission from the NRF
[120], to the target NF, in an event at least one of the timeout scenario, and the negative
response within the preconfigured response time associated with the first status message, is
detected at the NRF [120]. The predefined retry policy may be a policy comprising one or more
5 conditions pre-defined by the administrator to manage the reinitiation of the one or more status
message transmission from the NRF [120]. Further, the predefined retry policy may be stored in the storage unit [308].
[0091] The present disclosure encompasses that the message retry count threshold refers to the
10 maximum number of retry attempts for sending a successive status messages in an event at
least one of the timeout scenario and the negative response within the preconfigured response time associated with a previous status message is detected at the NRF [120]. For instance, the predefined retry policy may specify that only 20 attempts are allowed for sending the status message. 15
[0092] As used herein, “message retry timer” signifies intervals or delays between attempting
a retry of the successive status message in an event at least one of the timeout scenario and the
negative response within the preconfigured response time associated with the previous status
message is detected at the NRF [120]. Further, the message retry timer specifies a minimum
20 duration of time before initiating each retry attempt associated with the successive status
message from the NRF [120] to target NF.
[0093] The processing unit [306] is connected to at least the analysis unit [304]. The processing
unit [306] is configured to automatically initiate, from the NRF [120] to the target NF, a second
25 status message to notify the status change associated with the target NF based on the predefined
retry policy.
[0094] The present disclosure encompasses that, to automatically initiate the second status
message, the analysis unit [304] is further configured to determine, by the NRF [120], a
30 response code associated with the response status.
[0095] The present disclosure encompasses that the second status message is automatically initiated from the NRF [120] in an event the NRF [120] detects the error response code associated with the first status message, a positive threshold status associated with the current
20

message retry count value, and a message retry timer status associated with the message retry timer.
[0096] In other words, the NRF [120] sends the second status message in an event at least one
5 of the timeout scenario and the negative response within the preconfigured response time
associated with the first status message is detected at the NRF [120], the current message retry
count value (number of retry attempts) is still below a threshold value (a maximum number of
retry attempts possible), and the minimum duration of time before initiating each retry attempt
associated with the successive status message from the NRF [120] to target NF has been
10 breached.
[0097] The present disclosure encompasses that the positive threshold status associated with
the current message retry count value is detected at the NRF [120] in an event where a number
of the second status messages automatically initiated by the NRF [120], to the target NF, is less
15 than a predefined number of the second status messages initiated by the NRF [120], to the
target NF.
[0098] For example, if the current message retry count value is 10 and the threshold value is
20, then in that scenario the positive threshold status associated with the current message retry
20 count value is detected at the NRF [120].
[0099] The present disclosure encompasses that the message retry timer status associated with
the message retry timer is a predefined minimum time duration between the first status message
transmitted from the NRF [120] to the target NF and the second status message automatically
25 initiated from the NRF [120] to the target NF.
[0100] In other words, if the predefined minimum time duration is 10 seconds, then the minimum time duration that must have been elapsed between transmission of the first status message and the second status message should be at least 10 seconds. 30
[0101] Referring to FIG. 4, an exemplary flow diagram of a method [400] for notification retry management in a network, in accordance with exemplary implementations of the present disclosure is shown. In an implementation the method [400] is performed by the system [300]. Further, in an implementation, the system [300] may be present in a server device to implement
21

the features of the present disclosure. Also, as shown in FIG. 4, the method [400] starts at step [402].
[0102] At step [404], the method [400] comprises transmitting, by a transceiver unit [302] from
5 a Network Repository Function (NRF) [120] to a target Network Function (NF) in the network,
a first status message to notify a status change associated with the target NF.
[0103] The present disclosure encompasses that the status message refers to a message that is
transmitted from the NRF [120] to the target NF within the network, to notify about an existing
10 status associated with the target NF, that is available at the NRF [120], wherein the target NF
may be one of the one or more network function associated with the network. The status message may include an identification data, a status change data, a timestamp data and an additional information.
15 [0104] The present disclosure encompasses that the status change may be related to an
operational state change of the NF, a configuration change of the NF, a performance change of the NF, a service availability change of the NF and an event change of the NF.
[0105] As used herein, “operational state change of the NF” may refer to alterations in the
20 operational status or mode of the NF such as, transition between starting, stopping, restarting,
or switching between active and standby modes by the NT.
[0106] As used herein, “configuration change of the NF” refers to a modification associated
with one or more parameters that governs an operation of the NF such as, a modification
25 associated with adjustments to network interfaces, protocols, security policies, resource
allocations, or any other configurable attributes.
[0107] As used herein, “performance change of the NF” signifies variations in an operational
performance metrics of the NF such as, alterations in a throughput, a latency, packet loss rates,
30 a resource utilization such as CPU, memory, and/or key performance indicators (KPIs).
[0108] As used herein, “service availability change of the NF” refers to shifts in an ability of the NF to provide services as expected such as, changes in a service uptime, a service downtime, a service reliability, a service resilience, and fault tolerance mechanisms.
22

[0109] As used herein, “event change of the NF” refers to an event change that indicates an
occurrence of significant events associated with the NF such as, an alarm event, event
notifications, one or more triggers associated with an NF event, a state transitions that may
5 impact operation of the NF, an event detection, an event notification, an event logging, and
event appropriate response actions.
[0110] At step [406], the method [400] comprises determining, by an analysis unit [304] at the
NRF [120] in the network, at least one of a timeout scenario and a response status within a
10 preconfigured response time associated with the first status message, wherein the response
status is at least one of a negative response and a positive response.
[0111] Further, the timeout scenario is determined at the NRF [120] in an event no response is
detected at the NRF [120] from the target NF associated with the first status message within
15 the preconfigured response time.
[0112] The present disclosure encompasses that the analysis unit [304] may utilize one or more
event determination techniques for determining the at least one of a timeout scenario and the
response status within the preconfigured response time associated with the first status message.
20 The one or more one or more event determination techniques may be a pre-defined technique,
such as techniques pre-defined by an administrator that may be stored in the storage unit [308].
[0113] The present disclosure encompasses that the timeout scenario may refer to a situation
where an expected response from the target NF does not arrive within a pre-defined timeframe
25 (i.e., a response time). For example, if the predefined timeframe is 100ms, in an event if the
response associated with the first status message is not received within the 100ms, in that event the analysis unit [304] may determine the timeout scenario associated with the first status message based on detecting no receipt of the response in predefined timeframe (i.e., a response time).
30
[0114] The present disclosure encompasses that the preconfigured response time may be pre-defined by the administrator in the storage unit.
23

[0115] In another example, when the NRF [120] transmits the first status message to the NF,
then the NRF [120] waits for a response within the preconfigured response time such as, 20
minutes. Moreover, the analysis unit [304] waits for the response for 20 minutes, and if no
response is received within the specified time (timeout scenario), the analysis unit [304]
5 identifies this condition as a timeout scenario.
[0116] The present disclosure encompasses the timeout scenario is determined at the NRF
[120] in an event where no response is detected at the NRF [120] from the target NF associated
with the first status message within the preconfigured response time such as, 5 seconds, 10
10 seconds, 30 seconds. The error response code is determined based on a comparison of the
response code with a list of pre-defined response codes.
[0117] The present disclosure encompasses that the error response code refers a to code which indicates an error or failure condition in response to the first status message. 15
[0118] The present disclosure encompasses that the list of pre-defined response codes may be pre-defined by the administrator and stored in the storage unit [308].
[0119] The present disclosure encompasses that upon receiving of the response within the
20 preconfigured response time, an error response code is checked and further the error response
code is compared with a list of pre-defined response code. The comparison of error response code with the list of pre-defined response code is made to determine whether the response is a negative response or a positive response.
25 [0120] The present disclosure encompasses that the negative response is determined at the
NRF [120] in an event where an error response code associated with the first status message is detected at the NRF [120] from the target NF within the preconfigured response time, wherein the error response code is determined based on a comparison of the response code with a list of pre-defined response codes.
30
[0121] The present disclosure encompasses that the error response code refers to code which indicate an error or failure condition in response to the first status message. For instance, the error response code may include, but is not limited, to 400 Bad Request error code, 500 Internal Server Error code. Furthermore, in an implementation of the present solution, a set response
24

code may be pre-defined as the negative response in the list pre-defined response codes associated with the target NF. For example, a response code A, a response code B, a response code D, and a response code Z are associated with a NF M. In a scenario, the response code B is defined as an error code associated with the NF M, in the pre-defined response codes associated with the NF M, and the response code A, the response code D, and the response code Z are defined as a success code associated with the NF M in the pre-defined response codes associated with the NF M. Now, if a response received based on the first status message comprises the response code B (i.e., the error code associated with the NF M in the pre-defined response codes) then the received response is determined as the negative response at the NRF [120].
[0122] The present disclosure encompasses that the list of pre-defined response codes may be pre-defined by the administrator and stored in the storage unit [308].
[0123] The present disclosure encompasses that the positive response is determined at the NRF [120] in an event where a success response code associated with the first status message is detected at the NRF [120] from the target NF within the preconfigured response time, wherein the success response code is determined based on a comparison of the response code with a list of pre-defined response codes.
[0124] For instance, in the above example, if the response received based on the first status message comprises the response code A (i.e., the success code associated with the NF M in the pre-defined response codes) then the received response is determined as the positive response at the NRF [120].
[0125] At step [408], the method [400] comprises identifying, by the analysis unit [304] at the NRF [120], a predefined retry policy associated with at least one of the timeout scenario and the response status.
[0126] Further, in a scenario the NRF [120] detects the negative response associated with the first status message from the target NF within the preconfigured response time or if no response is received within the preconfigured response time (i.e., the timeout scenario), then the predefined retry policy associated with the detected negative response or the detected timeout scenario is triggered at the NRF [120].

[0127] The present disclosure encompasses that the predefined retry policy comprises one or more predefined retry conditions associated with the response code and a current message retry count value associated with the first status message, and wherein the one or more predefined retry conditions is at least one of a message retry count threshold and a message retry timer.
[0128] The present disclosure encompasses that the predefined retry policy refers to a predetermined set of rules or guidelines established within a configuration that helps the network to handle and manage a reinitiation of one or more status message transmission from the NRF [120], to the target NF, in an event at least one of the timeout scenario and the negative response within the preconfigured response time associated with the first status message is detected at the NRF [120]. The predefined retry policy may be a policy comprising one or more conditions pre-defined by the administrator to manage the reinitiation of the one or more status message transmission from the NRF [120]. Further, the predefined retry policy may be stored in the storage unit [308].
[0129] The present disclosure encompasses that the message retry count threshold refers to the maximum number of retry attempts for sending a successive status message in an event at least one of the timeout scenario and the negative response within the preconfigured response time associated with a previous status message is detected at the NRF [120]. For instance, the predefined retry policy may specify that only 20 attempts are allowed for sending the status message.
[0130] As used herein “message retry timer” defines the intervals or delays between attempting a retry of the successive status message in an event at least one of the timeout scenario and the negative response within the preconfigured response time associated with the previous status message is detected at the NRF [120]. Further, the message retry timer specifies a minimum duration of time before initiating each retry attempt associated with the successive status message from the NRF [120] to target NF.
[0131] At step [410], the method [400] comprises automatically initiating, by a processing unit [306] from the NRF [120] to the target NF, a second status message to notify the status change associated with the target NF, based on the predefined retry policy.

[0132] The present disclosure encompasses that the automatic initiation of the second status message is further based on determining, by the analysis unit [304], at the NRF [120], a response code associated with the response status.
[0133] The present disclosure encompasses that the second status message is automatically initiated from the NRF [120] in an event the NRF [120] detects the error response code associated with the first status message, a positive threshold status associated with the current message retry count value, and a message retry timer status associated with the message retry timer.
[0134] In other words, the NRF [120] sends the second status message in an event where at least one of the timeout scenario and the negative response within the preconfigured response time associated with the First status message is detected at the NRF [120], the current message retry count value (number of retry attempts) is still below a threshold value (a maximum number of retry attempts possible), and the minimum duration of time before initiating each retry attempt associated with the successive status message from the NRF [120] to target NF has been breached.
[0135] The present disclosure encompasses that the positive threshold status associated with the current message retry count value is detected at the NRF [120] in an event a number of the second status messages automatically initiated by the NRF [120] to the target NF is less than a predefined number of the second status messages initiated by the NRF [120] to the target NF.
[0136] For example, if the current message retry count value is 10 and the threshold value is 20, then in that scenario the positive threshold status associated with the current message retry count value is detected at the NRF [120].
[0137] The present disclosure encompasses that the message retry timer status associated with the message retry timer is a predefined minimum time duration between the first status message transmitted from the NRF [120] to the target NF, and the second status message automatically initiated from the NRF [120] to the target NF.

[0138] In other words, the predefined minimum time duration is 10 second, the minimum time duration that must have been elapsed between transmission of the first status message and the second status message should be at least 10 seconds.
[0139] The method [400] terminates at step [412].
[0140] Referring to FIG. 5, an exemplary method flow diagram [500] for notification retry management in a network, in accordance with exemplary implementations of the present disclosure is shown. In an implementation the method [500] is performed by the system [300]. Further, in an implementation, the system [300] may be present in a server device to implement the features of the present disclosure.
[0141] Also, as shown in FIG. 5, at step S1, due to a change in a network condition or a network function and an existing subscription, the Network Repository Function (NRF) [120] transmits a status message (i.e., a first status message) associated with a Network Function (NF) (i.e., a target NF).
[0142] Further at step S2, a status message notification associated with the status message is not delivered to the NF from the NRF [120], due to a failure such as a timeout scenario.
[0143] At step S3, the status message notification gets timeout at the NRF [120], or a negative response is received at the NRF [120]. The NRF [120] checks an internal retry counter (i.e., a message retry count threshold), a delta timer configuration (i.e., a message retry timer) and a current status ((i.e., a current message retry count value) to determine that a retry is needed after a specific time interval.
[0144] At step S4, after the specific time interval, the status message notification is transmitted to the NF.
[0145] At step S5, the NF responds with a no-content message which may indicate that the NF has received and processes the status message notification.
[0146] Thereafter, the method [500] terminates.

[0147] The present disclosure further discloses a non-transitory computer readable storage medium storing one or more instructions for notification retry management in a network, wherein the instructions include an executable code which, when executed by one or more units of a system, causes a transceiver unit [302] of the system [300] to transmit from a Network Repository Function (NRF) [120] to a target Network Function (NF) in the network, a first status message to notify a status change associated with the target NF. Further, the execution of the instructions by the one or more units of the system [300], causes an analysis unit [304] of the system to determine, at the NRF [120]in the network, at least one of a timeout scenario and a response status within a preconfigured response time associated with the first status message, wherein the response status is at least one of a negative response and a positive response. The instructions further executed by the one or more units of the system [300], causes the analysis unit [304] to identify, at the NRF [120], a predefined retry policy associated with at least one of the timeout scenario and the response status. The instructions further executed by the one or more units of the system [300], causes a processing unit [306] connected to at least the analysis unit [304], wherein the processing unit [306] is configured to automatically initiate, from the NRF [120] to the target NF, a second status message to notify the status change associated with the target NF based on the predefined retry policy.
[0148] The present solution may be utilized by a telecommunications organization wherein a Network Repository Function (NRF) [120] is responsible for managing various network functions (NFs), such as the Session Management Function (SMF). When a status change occurs for an NF, the NRF [120] is configured to notify the NF promptly. Due to potential network issues or NF failures, notifications might fail, which leads to situations where the NF does not receive one or more notifications related to one or more changes in the conditions of the network in a timely manner. Due to this delay, an issue of service outages arises for the affected NF, which ultimately impacts overall network performance and reliability. The telecommunications organization may use the present solution for notification retry management in the 5G network. The present solution involves the initiation of the transmission of a first status message from the NRF [120] to the SMF, wherein the first status message is related to a status change. The NRF [120] waits for a response according to a predefined response time, such as 20 minutes. Thereafter, based on the response status (success or error), the NRF [120] decides whether to initiate resending the status message. If a success response (for e.g., status code 200) is received, then the SMF has acknowledged the status message, and one or more normal operations proceed without further action. However, in scenarios where

no response is received within the allocated time or an error response (for e.g., status code 404) is detected that signifies a communication failure or NF unavailability, the NRF [120] activates a retry mechanism or retry approach of the present solution. The retry mechanism or retry approach of the present solution follows a predefined retry policy, such as a maximum of 3 retry attempts with a 10-second interval between each attempt. Consequently, the NRF [120] automatically retransmits the status message to the SMF. If all retry attempts fail, it logs the failure and may notify a network administrator or an operator for further action. Hence, the present solution ensures that network disruptions are minimized, service continuity is maintained, operational efficiency is maintained, and ultimately the overall resilience and reliability of the 5G telecommunications network are improved.
[0149] As is evident from the above, the present disclosure provides a technically
advanced solution for notification retry management in a network. The present disclosure provides a solution to address one or more timed out or refused requests from subscriber Network Functions (NF). The present solution enables a Network Resource Function (NRF) to re-send a status message in case the status message is timed out or a specific error code is received from a Service Communication Proxy (SCP) or the NF. Additionally, the solution ensures a designated delta time period between each message re-send to allow sufficient recovery time for the NF, thereby preventing the NRF from causing network overload due to excessive retry attempts. By restricting the status messages timely, the present solution solves the issue of indefinite notifications from the NRF towards the NF. The present solution helps avoid multiple unnecessary notifications in the network and ensures robustness and resilience in the status message delivery process, enabling effective communication between the NRF and the NF. The present solution optimizes the handling of failed requests, thereby enhancing the overall reliability and performance of the network.
[0150] While considerable emphasis has been placed herein on the disclosed
implementations, it will be appreciated that many implementations can be made and that many changes can be made to the implementations without departing from the principles of the present disclosure. These and other changes in the implementations of the present disclosure will be apparent to those skilled in the art, whereby it is to be understood that the foregoing descriptive matter to be implemented is illustrative and non-limiting.

We Claim:
1. A method [400] for notification retry management in a network, the method
comprising:
- transmitting, by a transceiver unit [302] from a Network Repository Function (NRF) [120] to a target Network Function (NF) in the network, a first status message to notify a status change associated with the target NF;
- determining, by an analysis unit [304] at the NRF [120] in the network, at least one of a timeout scenario and a response status within a preconfigured response time associated with the first status message, wherein the response status is at least one of a negative response and a positive response;
- identifying, by the analysis unit [304] at the NRF [120], a predefined retry policy associated with at least one of the timeout scenario and the response status; and
- automatically initiating, by a processing unit [306] from the NRF [120] to the target NF, a second status message to notify the status change associated with the target NF based on the predefined retry policy.

2. The method [400] as claimed in claim 1, wherein automatically initiating the second status message is further based on determining, by the analysis unit [304] at the NRF [120], a response code associated with the response status.
3. The method [400] as claimed in claim 2, wherein the predefined retry policy comprises one or more predefined retry conditions associated with the response code and a current message retry count value associated with the first status message, and wherein the one or more predefined retry conditions is at least one of a message retry count threshold and a message retry timer.
4. The method [400] as claimed in claim 1, wherein the timeout scenario is determined at the NRF [120] in an event no response is detected at the NRF [120] from the target NF associated with the first status message within the preconfigured response time.

5. The method [400] as claimed in claim 3, wherein the negative response is determined at the NRF [120] in an event an error response code associated with the first status message is detected at the NRF [120] from the target NF within the preconfigured response time, wherein the error response code is determined based on a comparison of the response code with a list of pre-defined response codes.
6. The method [400] as claimed in claim 2, wherein the positive response is determined at the NRF [120] in an event a success response code associated with the first status message is detected at the NRF [120] from the target NF within the preconfigured response time, wherein the success response code is determined based on a comparison of the response code with a list of pre-defined response codes.
7. The method [400] as claimed in claim 5, wherein the second status message is automatically initiated from the NRF [120] in an event the NRF [120] detects the error response code associated with the first status message, a positive threshold status associated with the current message retry count value, and a message retry timer status associated with the message retry timer.
8. The method [400] as claimed in claim 7, wherein the positive threshold status associated with the current message retry count value is detected at the NRF [120] in an event a number of the second status message automatically initiated by the NRF [120]to the target NF is less than a predefined number of the second status message initiated by the NRF [120] to the target NF.
9. The method [400] as claimed in claim 7, wherein the message retry timer status associated with the message retry timer is a predefined minimum time duration between the first status message transmitted from the NRF [120] to the target NF and the second status message automatically initiated from the NRF [120] to the target NF.
10. A system [300] for notification retry management in a network, the system comprises: - a transceiver unit [302] configured to transmit from a Network Repository Function
(NRF) [120] to a target Network Function (NF) in the network, a first status message to notify a status change associated with the target NF;

- an analysis unit [304] connected to at least the transceiver unit [302], wherein the
analysis unit [304] is configured to:
o determine, at the NRF [120] in the network, at least one of a timeout scenario and a response status within a preconfigured response time associated with the first status message, wherein the response status is at least one of a negative response and a positive response, and
o identify, at the NRF [120], a predefined retry policy associated with at least one of the timeout scenario and the response status; and
- a processing unit [306] connected to at least the analysis unit [304], wherein the
processing unit [306] is configured to automatically initiate, from the NRF [120] to
the target NF, a second status message to notify the status change associated with
the target NF based on the predefined retry policy.
11. The system [300] as claimed in claim 10, wherein to automatically initiate the second status message the analysis unit [304] is further configured to determine, at the NRF [120], a response code associated with the response status.
12. The system [300] as claimed in claim 11, wherein the predefined retry policy comprises one or more predefined retry conditions associated with the response code and a current message retry count value associated with the first status message, and wherein the one or more predefined retry conditions is at least one of a message retry count threshold and a message retry timer.
13. The system [300] as claimed in claim 10, wherein the timeout scenario is determined at the NRF [120] in an event no response is detected at the NRF [120] from the target NF associated with the first status message within the preconfigured response time.
14. The system [300] as claimed in claim 12, wherein the negative response is determined at the NRF [120] in an event an error response code associated with the first status message is detected at the NRF [120] from the target NF within the preconfigured response time, wherein the error response code is determined based on a comparison of the response code with a list of pre-defined response codes.

15. The system [300] as claimed in claim 11, wherein the positive response is determined at the NRF [120] in an event a success response code associated with the first status message is detected at the NRF [120] from the target NF within the preconfigured response time, wherein the success response code is determined based on a comparison of the response code with a list of pre-defined response codes.
16. The system [300] as claimed in claim 14, wherein the second status message is automatically initiated from the NRF [120] in an event the NRF [120] detects the error response code associated with the first status message, a positive threshold status associated with the current message retry count value, and a message retry timer status associated with the message retry timer.
17. The system [300] as claimed in claim 16, wherein the positive threshold status associated with the current message retry count value is detected at the NRF [120] in an event a number of the second status message automatically initiated by the NRF [120] to the target NF is less than a predefined number of the second status message initiated by the NRF [120] to the target NF.
18. The system [300] as claimed in claim 16, wherein the message retry timer status associated with the message retry timer is a predefined minimum time duration between the first status message transmitted from the NRF [120] to the target NF and the second status message automatically initiated from the NRF [120] to the target NF.